WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 0/3][RFC] PV Passthrough PCI Device Hotplug Suppo

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/3][RFC] PV Passthrough PCI Device Hotplug Support
From: Yosuke Iwamatsu <y-iwamatsu@xxxxxxxxxxxxx>
Date: Fri, 22 Feb 2008 11:03:30 +0900
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 22 Feb 2008 08:06:47 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C3E330F4.1CCAC%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C3E330F4.1CCAC%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.6 (Windows/20070728)
Keir Fraser wrote:
On 21/2/08 13:25, "Yosuke Iwamatsu" <y-iwamatsu@xxxxxxxxxxxxx> wrote:
dev-#, vdev-# and state-# are all backend nodes.
Xend writes physical names on dev-# to let pciback know which device
should be exported (This is the original behaviour).
Then pciback publishes the corresponding virtul name on vdev-#.
At the time of detachment, pcifront scans backend nodes and finds
which device should be removed by seeing vdev-#.
pcifront doesn't need to know the physical name indeed.

This seems a bit different from how initial probe happens (by reading the
root-%d xenstore nodes). Could we not just watch those in pcifront and
re-parse them for changes?

Your state machine was also quite complicated, perhaps primarily so that
pcifront could handshake when devices are removed. Is this handshake
necessary? (e.g., in particular, is there any equivalent notion for real PCI
hot-unplug?). If not, we can get equivalent hotplug functionality between
HVM and PV without needing a complicated xend->frontend->backend->xend
handshaking ring:
 * xend updates dev-% nodes
 * pciback sees this and updates root-%d nodes
 * pcifront sees this and re-parses root-%d nodes

When hot add, this method (xend->pciback->pcifront) works.
And I did that way in my patch.

When hot remove, however, I'm afraid it's not safe.
xend->pciback->pcifront means that we first disable io/mmio port access,
destroy backend config space emulation and then notify the guest OS of
the removal. The guest OS would see something like a virtual
surprise-style removal, that is, a device suddenly disappears
while it is in use.

I confess that I have never done a real PCI hot-unplug myself, but
several specs (acpi spec 3.0b 6.3, pcihp spec 1.1) say that a
recommended hot removal sequence is like:
  1. the user notifys the OS of the desire to remove a slot
  2. the OS logicaly removes the device (unload driver, poweroff, etc)
     and report the user it's ready
  3. the user removes the slot
So the reason I added vdev-# and I chose xend->frontend->backend->xend
cicle is the same; let the guest OS cleanly shutdown the device first
and then actually remove it. I think it's quite essential.

Thanks,
  Yosuke


 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel