All of lore.kernel.org
 help / color / mirror / Atom feed
From: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: systemd-devel <systemd-devel@lists.freedesktop.org>,
	"Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl>,
	"Michal Sekletar" <msekleta@redhat.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [systemd-devel] udev virtio by-path naming
Date: Wed, 1 Mar 2017 19:28:46 +0100	[thread overview]
Message-ID: <f6dfe52a-4332-90fc-a426-712453a8c382__11846.2583552629$1488392951$gmane$org@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170301155812.GG10160@redhat.com>

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@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  parent reply	other threads:[~2017-03-01 18:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <de55b0f4-4582-cf06-4b0d-12c2282406a8@linux.vnet.ibm.com>
2017-02-20 15:14 ` [systemd-devel] udev virtio by-path naming Lennart Poettering
2017-02-20 16:00 ` Cornelia Huck
2017-02-24  9:56   ` Viktor Mihajlovski
2017-02-27 11:22     ` Michal Sekletar
     [not found]     ` <CALVzVJZhZTNbZp1EB9cT82YxUnbUZZ+ZPo7Od8CWz5C3faN1AA@mail.gmail.com>
2017-02-28  8:47       ` Viktor Mihajlovski
2017-03-01  3:30         ` [systemd-devel] " Zbigniew Jędrzejewski-Szmek
     [not found]         ` <20170301033007.GG29552@in.waw.pl>
2017-03-01 15:02           ` Viktor Mihajlovski
     [not found]           ` <7de4f313-d3a6-b50d-4e53-3b01d6f0f2a0@linux.vnet.ibm.com>
2017-03-01 15:58             ` Daniel P. Berrange
2017-03-01 16:24               ` Daniel P. Berrange
2017-03-01 18:28               ` Viktor Mihajlovski [this message]
     [not found]               ` <f6dfe52a-4332-90fc-a426-712453a8c382@linux.vnet.ibm.com>
2017-03-01 18:44                 ` Daniel P. Berrange
     [not found]                 ` <20170301184439.GS10160@redhat.com>
2017-03-01 19:23                   ` Viktor Mihajlovski
     [not found]                   ` <79e0b5c0-0860-81b2-cd4d-6efaca924bcc@linux.vnet.ibm.com>
2017-03-01 20:02                     ` Viktor Mihajlovski
     [not found] ` <20170220151432.GA15888@gardel-login>
2017-02-28 19:28   ` Daniel P. Berrange
     [not found]   ` <20170228192851.GC10067@redhat.com>
2017-02-28 19:39     ` Lennart Poettering
2017-03-01  3:43       ` Zbigniew Jędrzejewski-Szmek
     [not found]       ` <20170301034321.GH29552@in.waw.pl>
2017-03-01  3:51         ` Andrei Borzenkov
     [not found]         ` <559a5978-6957-49cd-2ec7-79897732be95@gmail.com>
2017-03-01  4:27           ` Zbigniew Jędrzejewski-Szmek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='f6dfe52a-4332-90fc-a426-712453a8c382__11846.2583552629$1488392951$gmane$org@linux.vnet.ibm.com' \
    --to=mihajlov@linux.vnet.ibm.com \
    --cc=berrange@redhat.com \
    --cc=msekleta@redhat.com \
    --cc=systemd-devel@lists.freedesktop.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=zbyszek@in.waw.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.