[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] make HVM PIC emulation code SMP-safe
On 5/17/06, Dong, Eddie <eddie.dong@xxxxxxxxx> wrote: Dave: Looks like this patch is just using "BUG_ON" for APIs like pic_ioport_read. Note that pic_ioport_read/write are internal to the PIC emulation. But I see your point. The locking could be moved inside pic_ioport_read/write. This would make sense because a read/write to a PIC I/O port is certainly at atomic event (from the CPUs' perspective) on real hardware. (The current implementation accomplishes the same thing by locking in intercept_pic_io, the only caller of pic_ioport_read/write. But I think your suggestion makes the code easier to understand.) Also let me share something about 1) HVM virtual Interrupt Controller movement in consideration. When APIC is enabled for SMP, guest software need to disable PIC for correct interrupt generation mechanism. If guest bios is presenting MPS, then we can know this through IMCR base on MPS spec when guest switch from PIC mode to Symmetric I/O Mode. If guest bios is presenting ACPI, the guest software will disable PIC by writing 0xff to master PIC IMR. Current VMX guest implements ACPI. Right. Currently I tell our guest OS (Linux 2.6) *not* to use the I/O APIC, because I end up losing hd interrupts on SMP guests when I use the I/O APIC. (But I do enable APIC in the hvm builder because SMP Linux needs the local APICs for IPIs,) So because of this, our guest software is never disabling the (8259) PIC. In either way, when Xen detects the guest has disabled PIC, the PIC IRQ generation logic can be removed for both performance and simplicity. So even VP0 doesn't need to get/queue interrupt from PIC. The ideal solution may be that we need to define some registable APIs in HVM virtual weired interrupt controller logic. At startup time, we regieter PIC APIs, and later on replace it with APIC's (the transition time need special concern while it is non performance critical path). I like this idea. Anyway, 2) PIC I/O access may need to be SMP safe (maybe a big lock for simplicity), 3) IOAPIC needs to be SMP safe. Then we try to keep minimal changes to device models with that in Qemu (yes we already have some) for future maintain effort. You are very welcome here. As I mentioned, I have a very similar patch to make the IOAPIC code SMP safe. But since (even with these changes) I still see a huge number of lost hda interrupts when using the IOAPIC on SMP guests, I haven't been able to test it yet. I assume others see the same problems with the IOAPIC?? (I'll be diving into this soon -- probably tonight or tomorrow. At this point I have no clue what's going wrong.) Dave _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |