[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
  • Date: Sat, 27 Dec 2008 21:03:17 +1100
  • Cc:
  • Delivery-date: Sat, 27 Dec 2008 02:03:46 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-topic: [Xen-devel] Multiple IRQ's in HVM for Windows

> On 27/12/2008 09:35, "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
> > I'm not sure if I understand the question. Under my drivers I just
> >
> > hvm_set_parameter(HVM_PARAM_CALLBACK_IRQ, irq_number);
> >
> > where irq_number is what Windows assigns the platform PCI device,
and is
> > normally 28 when the HAL is APIC, otherwise it is 5, assuming no
> > network adapters or passed through PCI devices.
> >
> > I think there is another way of setting the IRQ using the PCI
> > but that doesn't appear to be required here.
> So where will irq_number come from when every event channel needs one?

The driver for the xen platform PCI device is a 'bus driver' under
windows, and enumerates child devices. When it enumerates a child
device, I can say 'and allocate me an interrupt line'. During past
experimentation I did this with the criteria 'allocate me an interrupt
line somewhere between 16 and 31', and then I would call that interrupt
via a software interrupt mechanism (asm {int 0xXX} ), so I know that the
allocation and setup side of things work. What I don't know is if
Windows is programming the APIC correctly to match that physical IRQ
number with the vector... the 'int 0xXX' instruction just calls the

With enough devices, event channels are going to end up having to share
interrupts, but the number of event channels would be around 15 before
this would be required I think (windows would never allocate me an IRQ >
31), which I don't think is an unreasonable limitation.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.