thr3ads.net - Xen devel - [Xen-devel] [PATCH] make HVM PIC emulation code SMP-safe [May 2006]

If this information is useful, please help other people find it:
Share via:

David Lively

2006-May-15 19:11 UTC

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

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@lists.xensource.com
http://lists.xensource.com/xen-devel

Dave Lively

2006-May-16 00:29 UTC

head link

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@virtualiron.com>
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@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
>
>


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

Dong, Eddie

2006-May-16 01:58 UTC

head link

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

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@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Dave Lively
Sent: 2006年5月16日 8:29
To: xen-devel@lists.xensource.com
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@virtualiron.com
<mailto:dlively@virtualiron.com> > 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@lists.xensource.com
	http://lists.xensource.com/xen-devel
	
	
	
	




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

Dong, Eddie

2006-May-16 05:20 UTC

head link

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

For the PIC I/O access, do we need lock protect? But for IRQ generation, i.e.
cpu_get_interrupt, how about following for simplicity (not tested)?
 
diff -r 1e3977e029fd xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c    Mon May 08 19:21:41 2006 +0100
+++ b/xen/arch/x86/hvm/hvm.c    Tue May 16 13:18:04 2006 +0800
@@ -248,7 +248,7 @@ int cpu_get_interrupt(struct vcpu *v, in
         return intno;
     }
     /* read the irq from the PIC */
-    if ( (intno = cpu_get_pic_interrupt(v, type)) != -1 )
+    if ( v->vcpu_id == 0 && (intno = cpu_get_pic_interrupt(v, type))
!= -1 )
         return intno;
 
     return -1;

________________________________

From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Dong, Eddie
Sent: 2006年5月16日 9:58
To: Dave Lively; xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] [PATCH] make HVM PIC emulation code SMP-safe


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@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Dave Lively
Sent: 2006年5月16日 8:29
To: xen-devel@lists.xensource.com
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@virtualiron.com
<mailto:dlively@virtualiron.com> > 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@lists.xensource.com
	http://lists.xensource.com/xen-devel
	
	
	
	




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

Keir Fraser

2006-May-16 07:56 UTC

head link

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

Well, that would make it behave like a *real* PIC, wired through to 
CPU0''s INT pin, right? So it sounds good to me, especially if we are 
currently spraying PIC interrupts across all VCPUs. And it''s even 
better if it avoids requiring locking on the vmentry path.

  -- Keir

On 16 May 2006, at 06:20, Dong, Eddie wrote:
>  For the PIC I/O access, do we need lock protect? But for IRQ 
> generation, i.e. cpu_get_interrupt, how about following for simplicity 
> (not tested)?
>  
> diff -r 1e3977e029fd xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c    Mon May 08 19:21:41 2006 +0100
> +++ b/xen/arch/x86/hvm/hvm.c    Tue May 16 13:18:04 2006 +0800
> @@ -248,7 +248,7 @@ int cpu_get_interrupt(struct vcpu *v, in
>          return intno;
>      }
>      /* read the irq from the PIC */
> -    if ( (intno = cpu_get_pic_interrupt(v, type)) != -1 )
> +    if ( v->vcpu_id == 0 && (intno = cpu_get_pic_interrupt(v,
type))
> != -1 )
>          return intno;
>  
>      return -1;

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

Dave Lively

2006-May-16 15:05 UTC

head link

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

Hi Keir / Eddie -

  I was also thinking cpu_get_pic_interrupt() should be called only on
VCPU 0 (and in fact, originally tested with restriction).  But since I
wasn''t sure the restriction was necessary (and things worked fine
without it), I removed it.  I''ll put it back in now, in light of these
comments.  (Revised patch attached.)

  However, that doesn''t remove the need for locking (or some sort
of PIC concurrency control).  First (and most importantly), the guest
can access the PIC from *any* VCPU, though it must be careful to
access it from at most one VCPU at once.  This alone means it can
conflict with hypervisor PIC access from VCPU 0.  (Note that the
"APIC kludge" causes PIC acccess from arbitrary VCPUs.  So this
patch fixes that as well.  But the patch would be necessary even without
this kludge.)

  I''m not wild about having locks on this path either.  A safe lockless
protocol may be possible, but I don''t have the time to try to work one
out now.  In our experience, this patch greatly improves the stability
of SMP guests.  (But note we currently tell SMP guest kernels to
ignore the I/O APIC, otherwise we lose too many hda interrupts.)

Dave

P.S. The I/O APIC code has similar issues, for mostly the same
reasons (guests can access from any VCPU).  I have a similar patch
for it, but haven''t been able to test it yet (due to other I/O APIC
problems).

On 5/16/06, Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
wrote:>
>
> Well, that would make it behave like a *real* PIC, wired through to
> CPU0''s INT pin, right? So it sounds good to me, especially if we
are
> currently spraying PIC interrupts across all VCPUs. And it''s even
> better if it avoids requiring locking on the vmentry path.
>
>   -- Keir
>
> On 16 May 2006, at 06:20, Dong, Eddie wrote:
>
> > For the PIC I/O access, do weneed lock protect? But for IRQ
> > generation, i.e. cpu_get_interrupt, how about following for simplicity
> > (not tested)?
> >
> > diff -r 1e3977e029fd xen/arch/x86/hvm/hvm.c
> > --- a/xen/arch/x86/hvm/hvm.c Mon May 08 19:21:41 2006 +0100
> > +++ b/xen/arch/x86/hvm/hvm.c Tue May 16 13:18:04 2006 +0800
> > @@ -248,7 +248,7 @@ int cpu_get_interrupt(struct vcpu *v, in
> > return intno;
> > }
> > /* read the irq from the PIC */
> > - if ( (intno = cpu_get_pic_interrupt(v, type)) != -1 )
> > + if ( v->vcpu_id == 0 && (intno = cpu_get_pic_interrupt(v,
type))
> > != -1 )
> > return intno;
> >
> > return -1;
>
>

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

Dong, Eddie

2006-May-17 06:01 UTC

head link

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

Dave:
    Looks like this patch is just using "BUG_ON" for APIs like
pic_ioport_read.
    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.
    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).
    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.
    thx,eddie

________________________________

From: Dave Lively [mailto:dave.lively@gmail.com] 
Sent: 2006年5月16日 23:06
To: Keir Fraser
Cc: Dong, Eddie; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] make HVM PIC emulation code SMP-safe

Hi Keir / Eddie -

  I was also thinking cpu_get_pic_interrupt() should be called only on
VCPU 0 (and in fact, originally tested with restriction).  But since I
wasn''t sure the restriction was necessary (and things worked fine
without it), I removed it.  I''ll put it back in now, in light of these
comments.  (Revised patch attached.)

  However, that doesn''t remove the need for locking (or some sort
of PIC concurrency control).  First (and most importantly), the guest
can access the PIC from *any* VCPU, though it must be careful to
access it from at most one VCPU at once.  This alone means it can
conflict with hypervisor PIC access from VCPU 0.  (Note that the
"APIC kludge" causes PIC acccess from arbitrary VCPUs.  So this
patch fixes that as well.  But the patch would be necessary even without
this kludge.)

  I''m not wild about having locks on this path either.  A safe lockless
protocol may be possible, but I don''t have the time to try to work one
out now.  In our experience, this patch greatly improves the stability 
of SMP guests.  (But note we currently tell SMP guest kernels to 
ignore the I/O APIC, otherwise we lose too many hda interrupts.)

Dave

P.S. The I/O APIC code has similar issues, for mostly the same
reasons (guests can access from any VCPU).  I have a similar patch
for it, but haven''t been able to test it yet (due to other I/O APIC 
problems).

On 5/16/06, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote: 

	Well, that would make it behave like a *real* PIC, wired through to
	CPU0''s INT pin, right? So it sounds good to me, especially if we are
	currently spraying PIC interrupts across all VCPUs. And it''s even
	better if it avoids requiring locking on the vmentry path. 

	  -- Keir

	On 16 May 2006, at 06:20, Dong, Eddie wrote:

	> For the PIC I/O access, do weneed lock protect? But for IRQ
	> generation, i.e. cpu_get_interrupt, how about following for simplicity
	> (not tested)?
	> 
	> diff -r 1e3977e029fd xen/arch/x86/hvm/hvm.c
	> --- a/xen/arch/x86/hvm/hvm.c Mon May 08 19:21:41 2006 +0100
	> +++ b/xen/arch/x86/hvm/hvm.c Tue May 16 13:18:04 2006 +0800
	> @@ -248,7 +248,7 @@ int cpu_get_interrupt(struct vcpu *v, in 
	> return intno;
	> }
	> /* read the irq from the PIC */
	> - if ( (intno = cpu_get_pic_interrupt(v, type)) != -1 )
	> + if ( v->vcpu_id == 0 && (intno = cpu_get_pic_interrupt(v,
type))
	> != -1 )
	> return intno;
	> 
	> return -1;

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

Keir Fraser

2006-May-17 07:07 UTC

head link

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

On 17 May 2006, at 07:01, Dong, Eddie wrote:
>     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).
Don;t some OSes (e.g., older Linux) expect to be able to keep some 
interrupts routed through 8259 and then have the output of that plumbed 
to an IOAPIC pin? Or can they always fall back from that (is there real 
hardware that isn''t able to route 8259 via an IOAPIC)?

  -- Keir
>     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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Dave Lively

2006-May-18 15:16 UTC

head link

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

On 5/17/06, Dong, Eddie <eddie.dong@intel.com>
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@lists.xensource.com
http://lists.xensource.com/xen-devel

Jiang, Yunhong

2006-May-18 15:50 UTC

head link

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

>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.)
On which situation will the IOAPIC has a lot of hd lost interrupt?

What''s the guest kernel version are you using? I remember some old
version kernel has problem.

Also there is a bug on the round robin code.Current code will always
leads interrupt to vcpu 0.
Followed is the fix for it. But this fix cause problem for timer
interrupt, I''m not sure the cause, but I suspect it is because the
timer
is injected in flood.

The below fix is based one of my another APIC patch , so not sure if you
can apply it directly, but I think you can figure out the changes
easily.

Thanks
Yunhong Jiang 

diff -r 86d8246c6aff xen/arch/x86/hvm/vlapic.c
--- a/xen/arch/x86/hvm/vlapic.c Wed May 17 23:15:36 2006 +0100
+++ b/xen/arch/x86/hvm/vlapic.c Thu May 18 22:30:06 2006 +0800
@@ -308,8 +308,15 @@ struct vlapic* apic_round_robin(struct d

     old = next = d->arch.hvm_domain.round_info[vector];

-    do {
-        /* the vcpu array is arranged according to vcpu_id */
+    /* the vcpu array is arranged according to vcpu_id */
+    do
+    {
+        next ++;
+        if ( !d->vcpu[next] ||
+          !test_bit(_VCPUF_initialised, &d->vcpu[next]->vcpu_flags)
||
+          next == MAX_VIRT_CPUS )
+            next = 0;
+
         if ( test_bit(next, &bitmap) )
         {
             target = d->vcpu[next]->arch.hvm_vcpu.vlapic;
@@ -321,12 +328,6 @@ struct vlapic* apic_round_robin(struct d
             }
             break;
         }
-
-        next ++;
-        if ( !d->vcpu[next] ||
-             !test_bit(_VCPUF_initialised,
&d->vcpu[next]->vcpu_flags)
||
-             next == MAX_VIRT_CPUS )
-            next = 0;
     } while ( next != old );

     d->arch.hvm_domain.round_info[vector] = next;
~

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

Xen devel - May 2006 - [PATCH] make HVM PIC emulation code SMP-safe

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

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

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

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

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

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

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

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

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

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