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

[Tom Rotenberg <tom.rotenberg@xxxxxxxxx>]

Simon,

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?

Tom

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel