Re: [systemd-devel] udev virtio by-path naming
On 01.03.2017 20:23, Viktor Mihajlovski wrote: > On 01.03.2017 19:44, Daniel P. Berrange wrote: > [...] > replying on the list, a bit lengthy >> >> 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-3f00.pcie-pci-:00:01.1-virtio-pci-:02:00.0-scsi-0:0:0:0 >> -> ../../sda >> platform-3f00.pcie-pci-:00:01.3-virtio-pci-:04:00.0 -> >> ../../vda > this is somewhat suprising (the pcie-pci- part), could you once more > do me a favor and run > udevadm info -a /dev/vda > and paste the output? nevermind, I think I get it now, the PCI bus is a child to the platform bus, and the virtio PCI functions are connected via PCI bridges :00:01.1 and :00:01.3 >> 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-3f00.pcie-pci-:00:01.1-virtio-pci-:02:00.0-scsi-0:0:0:0 >> -> ../../sda >> platform-3f00.pcie-pci-:00:01.3-virtio-pci-:04:00.0 -> ../../vda > well, these are probably stale links from the old systemd baked into > your initrd >> platform-3f00.pcie-pci-:02:00.0-scsi-0:0:0:0 -> ../../sda >> platform-3f00.pcie-pci-:04:00.0 -> ../../vda > I don't yet understand these, especially why the intermediate pci- > id has vanished that is then correct as well, because the PCI bridges don't contribute to the path id, which is a bonus effect of removing the special virtio handling I think we're good with the patch as is. [...] -- 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev virtio by-path naming
On 01.03.2017 19:44, Daniel P. Berrange wrote: [...] replying on the list, a bit lengthy > > 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-3f00.pcie-pci-:00:01.1-virtio-pci-:02:00.0-scsi-0:0:0:0 > -> ../../sda > platform-3f00.pcie-pci-:00:01.3-virtio-pci-:04:00.0 -> ../../vda this is somewhat suprising (the pcie-pci- part), could you once more do me a favor and run udevadm info -a /dev/vda and paste the output? > 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-3f00.pcie-pci-:00:01.1-virtio-pci-:02:00.0-scsi-0:0:0:0 > -> ../../sda > platform-3f00.pcie-pci-:00:01.3-virtio-pci-:04:00.0 -> ../../vda well, these are probably stale links from the old systemd baked into your initrd > platform-3f00.pcie-pci-:02:00.0-scsi-0:0:0:0 -> ../../sda > platform-3f00.pcie-pci-:04:00.0 -> ../../vda I don't yet understand these, especially why the intermediate pci- id has vanished > platform-a003c00.virtio_mmio -> ../../vdb > platform-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb these look as expected > virtio-pci-a003c00.virtio_mmio -> ../../vdb > virtio-pci-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb stale > > 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 the patch only provide compat symlinks for the pci path ids traditionally seen on x86 systems, but I think we don't want those for platforms other than x86, right? > > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev virtio by-path naming
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
>>>>>>>> (not predictable), pci- and virtio-pci- 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 -, which
>>>>>>>> would work for PCI and CCW, not sure about ARM MMIO though.
>>>
>>> It seems that there's agreement that - is the right
>>> approach.
>>>
>>> Ideally we would keep the virtio-pci- 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
>
>
>
>
>
>
>
>
>
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 a00.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}==" 00"
> ATTR{range}=="16"
> ATTR{removable}=="0"
> ATTR{ro}=="0"
> ATTR{serial}==""
> ATTR{size}=="2097152"
> ATTR{stat}==" 940 4208 28500
> 0
>00 100 280"
>
> looking at parent device '/devices/platform/a003e00.virtio_mmio/virtio3':
> KERNELS=="virtio3"
> SUBSYSTEMS=="virtio"
> DRIVERS=="virtio_blk"
> ATTRS{device}=="0x0002"
>
> ATTRS{features}=="00101011011111
> 00"
> ATTRS{status}=="0x0007"
> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev virtio by-path naming
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 >>>>>> (not predictable), pci- and virtio-pci- 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 -, which >>>>>> would work for PCI and CCW, not sure about ARM MMIO though. > > It seems that there's agreement that - is the right > approach. > > Ideally we would keep the virtio-pci- 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev virtio by-path naming
On 27.02.2017 12:22, Michal Sekletar wrote: > On Fri, Feb 24, 2017 at 10:56 AM, Viktor Mihajlovski > <mihaj...@linux.vnet.ibm.com> wrote: >> On 20.02.2017 17:00, Cornelia Huck wrote: >>> On Mon, 20 Feb 2017 15:34:49 +0100 >>> Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> wrote: >>> >>>> Hi, >>>> >>>> with systemd > v229 all virtio block devices will receive persistent >>>> device names in the format /dev/disk-by/virtio-pci-, the >>>> last component being the udev built-in path_id. >>>> >>>> This naming introduces some issues. >>>> >>>> First and obvious, there are virtio implementations not based >>>> on PCI, like virtio-ccw (currently only on s390) and virtio-mmio >>>> (for which I can't speak). This results in persistent names like >>>> /dev/disk-by/virtio-pci-0.0.0001, where the bus id is a CCW id. >>>> One seemingly obvious remedy would be to make the path_id return >>>> virtio-ccw- or more generally virtio--, >>>> both easily done with small patches to systemd-udev. >>>> >>>> But then, I find this naming scheme somewhat weird. >>>> A virtio disk shows up as a regular PCI function on the PCI >>>> bus side by side with other (non-virtio) devices. The naming otoh >>>> suggests that virtio-pci is a subsystem of its own, which is simply >>>> incorrect from a by-path perspective. >>> >>> From the ccw perspective, this is quite similar: The virtio proxy >>> device shows up on the ccw bus, just like e.g. a dasd device shows up >>> on the ccw bus. >>> >>>> >>>> Using just the plain PCI path id is actually sufficient to identify >>>> a virtio disk by its path. This would be in line with virtio >>>> network interface path names which use the plain PCI naming. >>> >>> Same for ccw: The id on the ccw bus (devno) is already unique and >>> persistent. >>> >>>> >>>> One could argue about back-level compatibility, but virtio by-path >>>> naming has changed multiple times. We have seen virtio-pci-virtio >>>> (not predictable), pci- and virtio-pci- 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 -, which >>>> would work for PCI and CCW, not sure about ARM MMIO though. >>>> Opinions? >>> >>> I'm not sure whether there is any reason to make virtio special, >>> although this depends upon what virtio-mmio looks like in the Linux >>> device model (any arm folks here?) >>> >>> In the end, I'd be happy with any naming scheme that does not include >>> 'pci' for non-pci devices. >>> >> Michal, as author of commit f073b1b3c0f4f0df1b0bd61042ce85fb5d27d407 >> that introduced this behavior: can you comment on the reasoning for >> prepending virtio- to the bus, i.e. why would pci- not >> sufficiently identify the device? > > As with many things, it looked like a good idea at the time. In commit > message I referenced discussion on upstream mailing list. In that > thread we got reassured that there is one-to-one correspondence > between virtio and pci devices. IIRC, we had bugs for RHEL and CentOS > 7 were users requested these symlinks. Hence we went ahead with above > naming scheme. > > Your argument about virtio being first component of the path makes > sense to me, but then again, we wanted to distinguish these devices > (because of user demands). > > In retrospect what we did wasn't probably the best we could. > Nevertheless, I'd not change the naming. After all, these symlinks are > for users and since then I didn't hear complains about them. I'd only > adjust the code so that we produce correctly named symlinks for > different parent buses (pci, ccw, mmio). IOW we would remove hardcoded > "pci" string. Thanks for taking the time to explain the background. As it happens, I have a local patch to produce virtio-- symlinks as you suggested. However, I wasn't really happy about that for two reasons: 1. The s390x architecture has native disks that show up as devices on the bus, so it is possible to create persistent symlinks based solely on the bus id, irrespective of the disk type (virtio or dasd). This helps in defining OS images that can run on native and paravirtualized disk setups. Which is broken now. This might be considered an architecture one-off, but 2. SCSI disk pathids are generally represented as - (the lun i
Re: [systemd-devel] udev virtio by-path naming
On 20.02.2017 17:00, Cornelia Huck wrote: > On Mon, 20 Feb 2017 15:34:49 +0100 > Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> wrote: > >> Hi, >> >> with systemd > v229 all virtio block devices will receive persistent >> device names in the format /dev/disk-by/virtio-pci-, the >> last component being the udev built-in path_id. >> >> This naming introduces some issues. >> >> First and obvious, there are virtio implementations not based >> on PCI, like virtio-ccw (currently only on s390) and virtio-mmio >> (for which I can't speak). This results in persistent names like >> /dev/disk-by/virtio-pci-0.0.0001, where the bus id is a CCW id. >> One seemingly obvious remedy would be to make the path_id return >> virtio-ccw- or more generally virtio--, >> both easily done with small patches to systemd-udev. >> >> But then, I find this naming scheme somewhat weird. >> A virtio disk shows up as a regular PCI function on the PCI >> bus side by side with other (non-virtio) devices. The naming otoh >> suggests that virtio-pci is a subsystem of its own, which is simply >> incorrect from a by-path perspective. > > From the ccw perspective, this is quite similar: The virtio proxy > device shows up on the ccw bus, just like e.g. a dasd device shows up > on the ccw bus. > >> >> Using just the plain PCI path id is actually sufficient to identify >> a virtio disk by its path. This would be in line with virtio >> network interface path names which use the plain PCI naming. > > Same for ccw: The id on the ccw bus (devno) is already unique and > persistent. > >> >> One could argue about back-level compatibility, but virtio by-path >> naming has changed multiple times. We have seen virtio-pci-virtio >> (not predictable), pci- and virtio-pci- 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 -, which >> would work for PCI and CCW, not sure about ARM MMIO though. >> Opinions? > > I'm not sure whether there is any reason to make virtio special, > although this depends upon what virtio-mmio looks like in the Linux > device model (any arm folks here?) > > In the end, I'd be happy with any naming scheme that does not include > 'pci' for non-pci devices. > Michal, as author of commit f073b1b3c0f4f0df1b0bd61042ce85fb5d27d407 that introduced this behavior: can you comment on the reasoning for prepending virtio- to the bus, i.e. why would pci- not sufficiently identify the device? -- 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] udev virtio by-path naming
Hi, with systemd > v229 all virtio block devices will receive persistent device names in the format /dev/disk-by/virtio-pci-, the last component being the udev built-in path_id. This naming introduces some issues. First and obvious, there are virtio implementations not based on PCI, like virtio-ccw (currently only on s390) and virtio-mmio (for which I can't speak). This results in persistent names like /dev/disk-by/virtio-pci-0.0.0001, where the bus id is a CCW id. One seemingly obvious remedy would be to make the path_id return virtio-ccw- or more generally virtio--, both easily done with small patches to systemd-udev. But then, I find this naming scheme somewhat weird. A virtio disk shows up as a regular PCI function on the PCI bus side by side with other (non-virtio) devices. The naming otoh suggests that virtio-pci is a subsystem of its own, which is simply incorrect from a by-path perspective. Using just the plain PCI path id is actually sufficient to identify a virtio disk by its path. This would be in line with virtio network interface path names which use the plain PCI naming. One could argue about back-level compatibility, but virtio by-path naming has changed multiple times. We have seen virtio-pci-virtio (not predictable), pci- and virtio-pci- 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 -, which would work for PCI and CCW, not sure about ARM MMIO though. Opinions? -- 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
