RE: [Xen-devel] [PATCH] make HVM PIC emulation code SMP-safe

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

Dave:

    I think we'd better to make sure cpu_get_interrupt be called only in VP0 too, but IOAPIC code may need sonsolidation for SMP safe. hvm_pic_assist is safe as it is only happen in VP0.

    When switching from PIC to APIC in SMP, the guest will disable PIC when IOAPIC/APIC is enabled.

thx,eddie

---

From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Dave Lively
Sent: 2006年5月16日 8:29
To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] [PATCH] make HVM PIC emulation code SMP-safe

Resubmit of same with signed-off-by tag ...

On 5/15/06, David Lively < dlively@xxxxxxxxxxxxxxx> wrote:

The current PIC emulation code for HVM (fully-virtualized) guests
is unsafe on SMP hosts.  Guests can access the PIC from any VCPU,
though they should be (and generally are) controlling access so that
at most a single VCPU is accessing the PIC at any time.  However,
there are two other paths that may access the PIC concurrently with
a guest VCPU:
(1) "the APIC kludge" - cpu_get_interrupt() calls pic_update_irq() to
      bump slave PIC intrs to the master PIC.  This is called from all
VCPUS.
(2) hvm_pic_assist() calls do_pic_irqs[_clear]() - from VCPU 0 only

With no PIC concurrency controls, SMP HVM guests[1] are unstable (tend
to hang) under high I/O loads (e.g., the LTP aio-stress & dio tests).
With the
PIC concurrency control introduced in the attached patch, SMP HVM guests
are considerably more stable.  I have yet to see a hang under heavy I/O
loads.
I've tested only 64-bit SMP guests (but this code is unchanged for 32
bits), always
passing "noapic" as explained below.

Dave

[1] Note we're passing "noapic" to the Linux kernels we're testing on SMP
guests.  This tells Linux to ignore the I/O APIC.  Without this, we lose too
many hda interrupts for Linux to boot.  The I/O APIC code has many of the
same issues as the PIC code.  I have a similar fix for the I/O APICs,
but since
it doesn't fix the "lost interrupt" problem I haven't been able to
adequately test
it yet.


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

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