Re: [Xen-devel] [rfc 00/18] ioemu: use devfn instead of slots as the unit for passthrough

[Simon Horman <horms@xxxxxxxxxxxx>]

On Tue, Mar 03, 2009 at 02:57:15PM +0900, Yuji Shimada wrote:
> On Mon, 02 Mar 2009 11:33:41 +0000
> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote:
> 
> > On 02/03/2009 11:25, "Simon Horman" <horms@xxxxxxxxxxxx> wrote:
> > 
> > >> I mean that xend can pick a virtual devfn for the device that it knows 
> > >> has a
> > >> non-conflicting GSI. This avoids any need for dynamic mapping between 
> > >> devfn
> > >> and GSI (which would be more of a pain in the neck -- for example, your
> > >> patch doesn't work because certain parts of BIOS info tables need to be
> > >> dynamically generated, as currently they hardcode the devfn-GSI
> > >> relationship).
> > > 
> > > Thanks for the clarification. I suspect that scheme could easily run into
> > > allocation problems when multi-function devices are passed-through as
> > > multi-function devices.  Especially in the case of hot-plug. Buy which I
> > > mean, it might be hard to find a device with the GSI for INTA + one or 
> > > more
> > > of INTB, C and D are free. But I'll take a look into it and see how it
> > > goes.
> > 
> > Well, it depends how many devices you want to pass through. I bet you're
> > good up to at least half dozen, and likely more.
> > 
> > > In any case, could you be more specific about which areas my approach 
> > > break?
> > 
> > Mainly, virtual firmware and (possibly) save/restore. The latter depends on
> > whether a guest with dynamically assigned devfn<->GSI relationship is ever
> > allowed to be saved/restored.
> > 
> > Your approach is also no good for PCI hotplug, since I'm pretty sure you
> > cannot update GSI bindings after the guest has booted. Unless there's some
> > ACPI magic that could be employed in this case.
> 
> If you want to assign many devices to guest, it is one of approaches
> to expand GSIs statically.  You can support hot-plug easily.
> 
>     dev 0  INTA -> GSI  16
>     dev 0  INTB -> GSI  17
>     dev 0  INTC -> GSI  18
>     dev 0  INTD -> GSI  19
>     dev 1  INTA -> GSI  20
>     dev 1  INTB -> GSI  21
>     dev 1  INTC -> GSI  22
>     dev 1  INTD -> GSI  23
>     dev 2  INTA -> GSI  24
>     dev 2  INTB -> GSI  25
>     dev 2  INTC -> GSI  26
>     dev 2  INTD -> GSI  27
>     ...
>     dev 31 INTA -> GSI 140
>     dev 31 INTB -> GSI 141
>     dev 31 INTC -> GSI 142
>     dev 31 INTD -> GSI 143
> 
> Please note that _PRT method in ACPI AML should reflect GSIs. If you expand
> GSIs, it will be necessary to change the _PRT method. Please see
> tools/firmware/hvmloader/acpi/dsdt.asl.

Could someone explain why the current code uses 32 GSIs rather than using 128?

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en


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