[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path() |
Date: |
Mon, 14 Jun 2010 22:43:01 +0100 |
User-agent: |
KMail/1.13.3 (Linux/2.6.33-2-amd64; KDE/4.4.4; x86_64; ; ) |
> On Mon, 2010-06-14 at 18:49 +0200, Jan Kiszka wrote:
> > Alex Williamson wrote:
> > > On Mon, 2010-06-14 at 18:00 +0200, Jan Kiszka wrote:
> > >> And instead of introducing another hierarchy level with the bus
> > >> address, I would also prefer to add this as prefix or suffix to the
> > >> device name, e.g. <driver>.<busaddr>.
> > >
> > > That's what I had started with. The first post in this thread has
> > > "pci.0,addr=09.0" as a single hierarchy level. The "addr=" may be
> > > unnecessary there, but I also prefer something along those lines. For
> > > PCI it'd make sense to have <name>:<addr>, which comes out to
> > > "pci.0:09.0". (Maybe rather than flagging properties as being relevant
> > > to the path and printing them generically, we should extract specific
> > > properties based on the bus type.)
> >
> > Not bus.addr, driver.addr. We only have one PCI bus here, not as many as
> > there are slots on that bus.
>
> Ok, I can get it down to something like:
>
> /i440FX-pcihost/pci.0/virtio-blk-pci,09.0
>
> The addr on the device is initially a little non-intuitive to me since
> it's a property of the bus, but I guess it make sense if we think of
> that level as slot, which includes an address and driver.
That indicates you're thinking about things the wrong way.
The point of this path is to uniquely identify an entity.
/i440FX-pcihost/pci0 identifies a PCI bus attached to the i440FX-pcihost
device. To identify a device attached to that bus all you need to know is the
devfn of the device.
For an end-user it may be helpful to allow devices to be identified by the
device type (assuming only one device of a particular type on that bus), or
specify the device type as a crude error checking mechanism. However we're
talking about canonical addresses. These need not include the device type.
Verifying that the device is actually what you expect is a separate problem,
and the device type is not sufficient for that.
i.e. /i440FX-pcihost/pci.0/,09.0 Is an appropriate canonical address.
> > > I started down that path, but it still breaks for hotplug. If we start
> > > a VM with two e1000 NICs, then remove the first, we can no longer
> > > migrate because the target can't represent having a single e1000 with a
> > > non-zero instance ID.
> >
> > That's indeed a good point.
That's a feature. If you start with two NICs and remove the first, the chances
are that the second will be in a different place to the nice created in a
single-nic config. Allowing migration between these two will cause a PCI
device to suddenly change location. This is not physically or logically
possible, and everyone looses.
Hot-removing a nic and then hotplugging a new nic in the same location may
result in something that is reasonable to migrate.
Paul
- [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), (continued)
- [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Markus Armbruster, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Jan Kiszka, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Jan Kiszka, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(),
Paul Brook <=
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Markus Armbruster, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Jan Kiszka, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Jan Kiszka, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Jan Kiszka, 2010/06/15