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

RE: [Xen-ia64-devel] vIOSAPIC and IRQs delivery



Magenheimer, Dan (HP Labs Fort Collins) wrote:
> Hi Tristan --
> 
> Do you have any more design information?  I'm not very
> familiar with the x86 implementation but is it your intent
> for it to be (nearly) identical?  What would be different?
The difference is that should guest OS (para xen) still access the
IOSAPIC MMIO port?
If the guest OS keeps accessing the machine IOSAPIC MMIO address,
multiple driver domain share same IRQ has potential problem. The design
in my opnion is that hypervisor own the machine IOSAPIC resource
exclusively including reading IVR and issuing CR.EOI. All the guest is
working with a pure virtual IOSAPIC or virtual IO_APIC (actually doesn't
matter for guest). 

> 
> Would all hardware I/O interrupts require queueing by
> Xen in an event channel?  This seems like it could be
> a potential high overhead performance issue.
Mmm, I have different opnion here. With all guest physical IRQ queueing
by Xen event channel through a bitmap that is shared in para-guest, the
guest OS no longer needs to access IVR and EOI now, that means we don't
need to trap into hypervisor. Checking the bitmap is defenitely higher
performance than read IVR, in this way the performance is improved
actually.
In the meantime, we don't need to spend time to re-design the vIOSAPIC,
it could be same with X86 vIO_APIC (90%). Definitely somebody need to
write down the vIO_APIC design :-)

Tristan or me can do that, Tristan?

> 
> Perhaps a design document (or at least a few paragraphs)
> would be useful for the developers on the list.
> 
Yes.
> Thanks,
> Dan
> 
Eddie

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


 


Rackspace

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