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

[Simon Horman <horms@xxxxxxxxxxxx>]

On Mon, Mar 02, 2009 at 10:08:29AM +0000, Keir Fraser wrote:
> On 02/03/2009 09:53, "Simon Horman" <horms@xxxxxxxxxxxx> wrote:
> 
> >> Not really what I had in mind. Xend can do the GSI->slot mapping, to ensure
> >> non-conflicting GSIs. I don't think any hypervisor changes are required, 
> >> let
> >> alone substantial ones.
> > 
> > Is the idea that xend would allocate a gsi to a device and
> > then pass that gsi along as part of the device configuration
> > to the device model?
> > 
> > If so, I think something similar to what I wrote, but moved
> > into xend could work quite well. But I sense that wasn't what
> > you had in mind either.
> 
> 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.

In any case, could you be more specific about which areas my approach break?

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