[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Possible bug with pass-through hot-plug?

  • To: Simon Horman <horms@xxxxxxxxxxxx>
  • From: Tom Rotenberg <tom.rotenberg@xxxxxxxxx>
  • Date: Thu, 15 Oct 2009 11:38:39 +0200
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 15 Oct 2009 02:39:03 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TE09AG9X00axDZyM2PzXWyilaUQhx8v8M/oDEOQS2UZDuP2vxeIn3kcRBbq8MFUZgf oubeq/LmI8sWLG76E44NkwScQtpM2LTp0m9T1SzEqnQuGIeho5IDwEetBOQy0pTpQmI8 6dFTt/iawGVXbTaR+pc4F4ii6OrKKJsaZ8fUE=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>


i'm glad you were able to re-produce it :)

About the bug, i suspect that the code in the virtual DSDT, which
"checks" which device was hot-plugged, is really not efficient, as it
needs to go over all sltos prior to the new assigned slot before
notifying the device. This means that if the slot number is 0x14, then
the 'if' clause in the dsdt, needs about 20*8=160 if statements before
it's notifying, and this what i think is causing the problem.
Especially, because the GPE interrupt is defined as level interrupt.

This bug can be fixed, using one of the followings:
1. Improve the code in the virtual DSDT (e.g.: doing some sort of
'binary-search' to see which device should be notified. This will
reduce the number of 'if' clause to evaluate from 160 to ~5)
2. Change the interrupt to edge interrupt, and see if it helps

What do u say?


On Thu, Oct 15, 2009 at 11:31 AM, Simon Horman <horms@xxxxxxxxxxxx> wrote:
> Hi Tom,
> I have been able to produce the following behaviour using a
> 32bit XP SP2 guest:
> 1. Attach to a low slot: xm ok, appears in device manager
> 2. Detach              : xm ok, disappears from device manager
> 3. Attach to a high slot: xm seems ok,
>                          but the device doesn't appear in device manager
> 4. Detach:                xm fails (time-out waiting for response from BIOS)
> Where a high slot seems to be 8 or greater.
> This seems to be in line with the problem that you were reporting.
> i
> Unfortunately at this stage I'm not sure exactly how to fix it
> but I suspect either:
> a) A problem the way XP is dealing with ACPI events or;
> b) More likely a deficiency in the virtual BIOS that xen is supplying.
>   In particular, the code in tools/firmware/hvmloader/acpi/dsdt.asl

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.