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, RFC]: qemu: hang-free/error-tolerant PCI hot-plu

To: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH, RFC]: qemu: hang-free/error-tolerant PCI hot-plug protocol
From: Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>
Date: Thu, 29 Jul 2010 18:58:42 +0100
Delivery-date: Thu, 29 Jul 2010 11:08:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1280426058.1723.2266.camel@xxxxxxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1280426058.1723.2266.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, 2010-07-29 at 18:54 +0100, Gianni Tedesco wrote:
> Hi,
> 
> The interface for PCI hotplug is flexible enough to shoot ones-self in
> the foot. It is possible to try to insert a PCI device in to a slot
> already occupied by a qemu emulated device (NIC, PIIX, ISA-bridge, etc.)
> In this case qemu (wisely) refuses to do the hotplug. Since there is no
> way for a toolstack to query qemu's pci device layout there is no way to
> check for this ahead of time. In this case the toolstack must wait for
> device-model state to change to pci-inserted which never happens.
> 
> I propose that when qemu decides not to hot-plug a device that it raise
> the "pci-inserted" status anyway. The tools must then check the
> "parameter" key in xenbus for a non-error string. In other words:
> 
> send_command("pci-ins")
> wait_for_device_model("pci-inserted")
> if parameter[0-2] == "0x" {
>       /* success */
> }else{
>       /* fail */
> }

FYI: The corresponding patch I am proposing is actually this (should
apply cleanly albeit with offsets):

diff -r 414e906dd623 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c   Thu Jul 29 17:58:38 2010 +0100
+++ b/tools/libxl/libxl_pci.c   Thu Jul 29 18:59:32 2010 +0100
@@ -404,6 +479,12 @@ static int do_pci_add(libxl_ctx *ctx, ui
             XL_LOG(ctx, XL_LOG_ERROR, "Device Model didn't respond in time");
         path = libxl_sprintf(ctx, "/local/domain/0/device-model/%d/parameter", 
domid);
         vdevfn = libxl_xs_read(ctx, XBT_NULL, path);
+        if ( strncmp(vdevfn, "0x", 2) ) {
+            XL_LOG(ctx, XL_LOG_ERROR, "qemu refused to add device: %s", 
vdevfn);
+            path = libxl_sprintf(ctx, "/local/domain/0/device-model/%d/state", 
domid);
+            xs_write(ctx->xsh, XBT_NULL, path, "running", strlen("running"));
+            return ERROR_FAIL;
+        }
         sscanf(vdevfn + 2, "%x", &pcidev->vdevfn);
         path = libxl_sprintf(ctx, "/local/domain/0/device-model/%d/state", 
domid);
         xs_write(ctx->xsh, XBT_NULL, path, state, strlen(state));



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