[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |