On Wed, Mar 01, 2017 at 04:02:53PM +0100, Viktor Mihajlovski wrote:> On 01.03.2017 04:30, Zbigniew J?drzejewski-Szmek wrote: > > On Tue, Feb 28, 2017 at 09:47:42AM +0100, Viktor Mihajlovski wrote: > >>>>>> One could argue about back-level compatibility, but virtio by-path > >>>>>> naming has changed multiple times. We have seen virtio-pci-virtio<n> > >>>>>> (not predictable), pci-<busid> and virtio-pci-<busid> already. It > >>>>>> might be a good time now to settle on a common approach for all > >>>>>> virtio types. > >>>>>> > >>>>>> For the reasons above, I'd vote for <subsystem>-<busid>, which > >>>>>> would work for PCI and CCW, not sure about ARM MMIO though. > > > > It seems that there's agreement that <subsystem>-<busid> is the right > > approach. > > > > Ideally we would keep the virtio-pci-<busid> links as they appear > > right now, for backwards compatibility, just for the pci devices, and > > mark them as deprecated (dunno where, maybe just in NEWS), and add the > > code to make the links. > > > > I haven't looked at the code, maybe we just do this with the right > > udev rule, and also stick the deprecation comment there? > > > > Zbyszek > > > I've posted a github pull request [1], and would appreciate review > feedback. As I am lacking an ARM setup, it would also be nice if someone > with ARM skills could have a look as well.FYI you can install ARM7 guests on an x86_64 host, using pre-built Fedora images https://fedoraproject.org/wiki/QA:Testcase_Virt_ARM_on_x86 NB, this will install the guest using virtio-pci. So if you want to see virtio-mmio in action, you'll need to edit the libvirt XML config afterwards to add another disk, eg <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/data.qcow2'/> <target dev='vda' bus='virtio'/> <address type='virtio-mmio'/> </disk>> If wanted, I can take a stab at virtio-mmio, but would need the output > of udevadm -a /dev/vda from a virtio-mmio system.Presumably you mean 'udevadm info -a /dev/vda' ? That reports the following, given a basic Fedora 25 guest, with a virtio-mmio disk added as per the guide above... looking at device '/devices/platform/a003e00.virtio_mmio/virtio3/block/vda': KERNEL=="vda" SUBSYSTEM=="block" DRIVER=="" ATTR{alignment_offset}=="0" ATTR{badblocks}=="" ATTR{cache_type}=="write back" ATTR{capability}=="50" ATTR{discard_alignment}=="0" ATTR{ext_range}=="256" ATTR{inflight}==" 0 0" ATTR{range}=="16" ATTR{removable}=="0" ATTR{ro}=="0" ATTR{serial}=="" ATTR{size}=="2097152" ATTR{stat}==" 94 0 4208 285 0 0 0 0 0 100 280" looking at parent device '/devices/platform/a003e00.virtio_mmio/virtio3': KERNELS=="virtio3" SUBSYSTEMS=="virtio" DRIVERS=="virtio_blk" ATTRS{device}=="0x0002" ATTRS{features}=="0010101101110000000000000000110000000000000000000000000000 000000" ATTRS{status}=="0x00000007" ATTRS{vendor}=="0x554d4551" looking at parent device '/devices/platform/a003e00.virtio_mmio': KERNELS=="a003e00.virtio_mmio" SUBSYSTEMS=="platform" DRIVERS=="virtio-mmio" ATTRS{driver_override}=="(null)" looking at parent device '/devices/platform': KERNELS=="platform" SUBSYSTEMS=="" DRIVERS=="" Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
On Wed, Mar 01, 2017 at 03:58:12PM +0000, Daniel P. Berrange wrote:> On Wed, Mar 01, 2017 at 04:02:53PM +0100, Viktor Mihajlovski wrote: > > If wanted, I can take a stab at virtio-mmio, but would need the output > > of udevadm -a /dev/vda from a virtio-mmio system. > > Presumably you mean 'udevadm info -a /dev/vda' ? That reports the following, > given a basic Fedora 25 guest, with a virtio-mmio disk added as per the > guide above... > > looking at device '/devices/platform/a003e00.virtio_mmio/virtio3/block/vda':BTW, the hex digits in here are the virtio mmio address which changes per device eg if i have 3 virtio-mmio backed disks, I get looking at device '/devices/platform/a003a00.virtio_mmio/virtio3/block/vda': looking at device '/devices/platform/a003c00.virtio_mmio/virtio4/block/vdb': looking at device '/devices/platform/a003e00.virtio_mmio/virtio5/block/vdc': Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
On 01.03.2017 16:58, Daniel P. Berrange wrote:> On Wed, Mar 01, 2017 at 04:02:53PM +0100, Viktor Mihajlovski wrote: >> On 01.03.2017 04:30, Zbigniew J?drzejewski-Szmek wrote: >>> On Tue, Feb 28, 2017 at 09:47:42AM +0100, Viktor Mihajlovski wrote: >>>>>>>> One could argue about back-level compatibility, but virtio by-path >>>>>>>> naming has changed multiple times. We have seen virtio-pci-virtio<n> >>>>>>>> (not predictable), pci-<busid> and virtio-pci-<busid> already. It >>>>>>>> might be a good time now to settle on a common approach for all >>>>>>>> virtio types. >>>>>>>> >>>>>>>> For the reasons above, I'd vote for <subsystem>-<busid>, which >>>>>>>> would work for PCI and CCW, not sure about ARM MMIO though. >>> >>> It seems that there's agreement that <subsystem>-<busid> is the right >>> approach. >>> >>> Ideally we would keep the virtio-pci-<busid> links as they appear >>> right now, for backwards compatibility, just for the pci devices, and >>> mark them as deprecated (dunno where, maybe just in NEWS), and add the >>> code to make the links. >>> >>> I haven't looked at the code, maybe we just do this with the right >>> udev rule, and also stick the deprecation comment there? >>> >>> Zbyszek >>> >> I've posted a github pull request [1], and would appreciate review >> feedback. As I am lacking an ARM setup, it would also be nice if someone >> with ARM skills could have a look as well. > > FYI you can install ARM7 guests on an x86_64 host, using pre-built Fedora > images > > https://fedoraproject.org/wiki/QA:Testcase_Virt_ARM_on_x86 > > NB, this will install the guest using virtio-pci. So if you want to > see virtio-mmio in action, you'll need to edit the libvirt XML config > afterwards to add another disk, eg > > <disk type='file' device='disk'> > <driver name='qemu' type='qcow2'/> > <source file='/var/lib/libvirt/images/data.qcow2'/> > <target dev='vda' bus='virtio'/> > <address type='virtio-mmio'/> > </disk> > >I might be stuck with a too old QEMU binary, the guest panics as soon as the virtio-mmio module is loaded. If I drop to the dracut debug shell I can see at least a number of mmio address slots(?) ranging from a000000.virtio_mmio to a003e00.virtio_mmio.>> If wanted, I can take a stab at virtio-mmio, but would need the output >> of udevadm -a /dev/vda from a virtio-mmio system. > > Presumably you mean 'udevadm info -a /dev/vda' ? That reports the following,yes, I always have to type the command twice :-(> given a basic Fedora 25 guest, with a virtio-mmio disk added as per the > guide above... > > looking at device '/devices/platform/a003e00.virtio_mmio/virtio3/block/vda': > KERNEL=="vda" > SUBSYSTEM=="block" > DRIVER=="" > ATTR{alignment_offset}=="0" > ATTR{badblocks}=="" > ATTR{cache_type}=="write back" > ATTR{capability}=="50" > ATTR{discard_alignment}=="0" > ATTR{ext_range}=="256" > ATTR{inflight}==" 0 0" > ATTR{range}=="16" > ATTR{removable}=="0" > ATTR{ro}=="0" > ATTR{serial}=="" > ATTR{size}=="2097152" > ATTR{stat}==" 94 0 4208 285 0 0 0 > 0 0 100 280" > > looking at parent device '/devices/platform/a003e00.virtio_mmio/virtio3': > KERNELS=="virtio3" > SUBSYSTEMS=="virtio" > DRIVERS=="virtio_blk" > ATTRS{device}=="0x0002" > ATTRS{features}=="0010101101110000000000000000110000000000000000000000000000 > 000000" > ATTRS{status}=="0x00000007" > ATTRS{vendor}=="0x554d4551" > > looking at parent device '/devices/platform/a003e00.virtio_mmio': > KERNELS=="a003e00.virtio_mmio" > SUBSYSTEMS=="platform" > DRIVERS=="virtio-mmio" > ATTRS{driver_override}=="(null)"Since I can't do that on my box, would you be so kind to run ls -l /dev/disk/by-path If it returns ids like virtio-pci-a003e00.virtio_mmio[-partn] my suggested patch should be OK for ARM in that it will produce ids in the format platform-a003e00.virtio_mmio[-partn]> > looking at parent device '/devices/platform': > KERNELS=="platform" > SUBSYSTEMS=="" > DRIVERS=="" > > > > Regards, > Daniel >-- Mit freundlichen Gr??en/Kind Regards Viktor Mihajlovski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina K?deritz Gesch?ftsf?hrung: Dirk Wittkopp Sitz der Gesellschaft: B?blingen Registergericht: Amtsgericht Stuttgart, HRB 243294
On Wed, Mar 01, 2017 at 07:28:46PM +0100, Viktor Mihajlovski wrote:> On 01.03.2017 16:58, Daniel P. Berrange wrote: > > given a basic Fedora 25 guest, with a virtio-mmio disk added as per the > > guide above... > > > > looking at device '/devices/platform/a003e00.virtio_mmio/virtio3/block/vda': > > KERNEL=="vda" > > SUBSYSTEM=="block" > > DRIVER=="" > > ATTR{alignment_offset}=="0" > > ATTR{badblocks}=="" > > ATTR{cache_type}=="write back" > > ATTR{capability}=="50" > > ATTR{discard_alignment}=="0" > > ATTR{ext_range}=="256" > > ATTR{inflight}==" 0 0" > > ATTR{range}=="16" > > ATTR{removable}=="0" > > ATTR{ro}=="0" > > ATTR{serial}=="" > > ATTR{size}=="2097152" > > ATTR{stat}==" 94 0 4208 285 0 0 0 > > 0 0 100 280" > > > > looking at parent device '/devices/platform/a003e00.virtio_mmio/virtio3': > > KERNELS=="virtio3" > > SUBSYSTEMS=="virtio" > > DRIVERS=="virtio_blk" > > ATTRS{device}=="0x0002" > > ATTRS{features}=="0010101101110000000000000000110000000000000000000000000000 > > 000000" > > ATTRS{status}=="0x00000007" > > ATTRS{vendor}=="0x554d4551" > > > > looking at parent device '/devices/platform/a003e00.virtio_mmio': > > KERNELS=="a003e00.virtio_mmio" > > SUBSYSTEMS=="platform" > > DRIVERS=="virtio-mmio" > > ATTRS{driver_override}=="(null)" > Since I can't do that on my box, would you be so kind to run > ls -l /dev/disk/by-path > If it returns ids like > virtio-pci-a003e00.virtio_mmio[-partn] > my suggested patch should be OK for ARM in that it will produce ids in > the format > platform-a003e00.virtio_mmio[-partn]Ok, my guest has 4 disks - sda - virtio-scsi, over virtio-pci transport - sdb - virtio-scsi, over virtio-mmio transport - vda - virtio-scsi, over virtio-pci transport - vdb - virtio-scsi, over virtio-mmio transport with systemd 231 I get these links platform-3f000000.pcie-pci-0000:00:01.1-virtio-pci-0000:02:00.0-scsi-0:0:0:0 -> ../../sda platform-3f000000.pcie-pci-0000:00:01.3-virtio-pci-0000:04:00.0 -> ../../vda virtio-pci-a003c00.virtio_mmio -> ../../vdb virtio-pci-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb after applying your patch I get these links: platform-3f000000.pcie-pci-0000:00:01.1-virtio-pci-0000:02:00.0-scsi-0:0:0:0 -> ../../sda platform-3f000000.pcie-pci-0000:00:01.3-virtio-pci-0000:04:00.0 -> ../../vda platform-3f000000.pcie-pci-0000:02:00.0-scsi-0:0:0:0 -> ../../sda platform-3f000000.pcie-pci-0000:04:00.0 -> ../../vda platform-a003c00.virtio_mmio -> ../../vdb platform-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb virtio-pci-a003c00.virtio_mmio -> ../../vdb virtio-pci-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb So that appears to be working as designed - the 4 backcompat symlinks are still there, and the new symlinks all live under the platform- prefix and don't have a bogus 'pci' in the name for mmio links Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|