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

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

> On 26/12/2008 10:54, "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
wrote:
> 
> > How many interrupts do we have to choose from here? I was able to
get
> > Windows to use up to (I think) IRQ31.
> 
> If going via the virtual PIC, then there are as many interrupts as
there
> are
> non-legacy IO-APIC pins. I think currently we have 32 of them.
> 
> > As I understand it, most of the 'protocol' we are talking about is
based
> > around the shared_info_t structure, which appears to make the
assumption
> > that there is a single point of entry for event delivery into a
domain.
> > To make use of multiple IRQ's we'd have to check every single event
bit
> > right? Is that a performance problem.
> 
> No, currently we call into HVM interrupt emulation code to assert an
IO-
> APIC
> pin when CPU0's event_pending flag is asserted. We could do that also
when
> other CPU's event_pending flags become asserted, or when individual
event
> channels become asserted. We just have to hook into event-channel code
in
> a
> different place. Or indeed we can just send 'messages' to HVM virtual
> local
> APICs to trigger interrupts on the virtual CPUs directly, without any
> integration with the virtual PCI or PIC subsystems.
> 

What about when we are running on a non-APIC HAL? People keep telling me
that the 'Standard PC' HAL (all IRQ's < 16) under Windows 2003 is higher
performance under Xen, but I've only done a quick test via iperf and
maybe there is 10% higher throughput with 'Standard PC', but that could
easily be within the level of background noise on that machine.

The original problem I am having is that Windows (NDIS actually) doesn't
always call my ISR when an interrupt is shared if it suspects that the
interrupts might be spurious. To work around that I would need for the
interrupt to be triggered if the 'pending' flag for that event wasn't
cleared, which is the 'check each event bit' that I was talking about.
This would also happen if two events are bound to the same IRQ and are
both triggered at the same time, eg:

. Event channels 2, 5, and 8 are bound to IRQ 29
. Event channels 2 and 8 are both triggered simultaneously (or close
enough that by the time the ISR happens they are both set)
. Windows will call the ISR for the device using event channel 2
. The device will see that its event is responsible for the interrupt,
clear the 'pending' flag _for that port only_ and then schedule a DPC to
do the work. It will return TRUE from its ISR and windows will not call
any other ISR for that interrupt
. Xen/qemu will need to notice that there is still an outstanding
interrupt for that event and will trigger the ISRs again
. ISR for the device using event channel 2 will get called again, but
will return FALSE this time meaning 'interrupt was not for me'
. ditto for the device using event channel 5
. Finally, the ISR for the device using event channel 8 will be called
and will do its thing

So instead of checking for one 'pending' flag, I think the pending flags
for each port will need to be called. If that's not a problem for
performance (only need to do it when returning from the interrupt I
think...) then I think we can proceed...

I can think of the following pieces of the puzzle:
. A mechanism to assign an event channel to an IRQ - a new type of
parameter for HYPERVISOR_hvm_op?
. At the end of each interrupt, re-trigger the interrupt if the event
bits are set rather than if the 'evtchn_upcall_pending' flag is set
(where is this done currently? I couldn't find it)
. Some way to make this backwards compatible... maybe assume the old
behaviour until the new HYPERVISOR_hvm_op parameter is set?

What else would be required?

Thanks

James


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