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
| 
Home