RE: [Xen-devel] Multiple IRQ's in HVM for Windows

["James Harper" <james.harper@xxxxxxxxxxxxxxxx>]

> On 27/12/2008 10:28, "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
wrote:
> 
> > Well... the 'old' way would probably still have to work (or would
it?),
> > so we could just keep allocating IRQ's until we run out and any
leftover
> > devices just have to use the old way.
> 
> Yes, that did occur to me. Might be a nice fallback while still
allowing
> up to 16 or whatever devices to have their interrupts distributed
across
> VCPUs.
> The old mechanism does still need to work, so making it a fallback in
this
> new mechanism would be probably not too difficult.

Is Windows limited to 31 IRQ's? Linux appears to allow much more than
that, but maybe I'm not comparing apples with apples here.

Still... an average Windows system under Xen would have a few disks, a
few network adapters, and maybe a scsi passthrough. I think it would be
unusual to see a requirement for more than 6 IRQ's, so I don't think
that a limit of 16 is going to cripple anyone.

So are you suggesting that these interrupts be non-shareable? Would that
remove the need to check for a pending interrupt status in Xen, and for
the virtual device driver to clear any flags?

> 
> > I've mentioned the possibility of using MSI before... would that
work?
> > I'm not yet sure if they are supported across all windows versions,
but
> > we get lots more 'interrupt channels'...
> 
> Well, would Windows need to see more fake PCI devices (where these
MSIs
> would emanate from) for this to work? It would be nice, though perhaps
not
> essential, to avoid this since it needs backwards-compatible changes
to
> qemu-dm, and also possibly our vBIOS.
> 

Unfortunately I don't know enough about MSI and how Windows handles MSI
to be able to answer that. Lets give it a miss :)

James

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