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
|
Home