Zbigniew Jędrzejewski-Szmek
2017-Mar-01 03:30 UTC
[systemd-devel] udev virtio by-path naming
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
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. 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. [1] https://github.com/systemd/systemd/pull/5500 -- 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 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/ :|