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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
