On Wed, Jun 27, 2007 at 01:49:08AM +0900, Kazushi Marukawa wrote:
> Hi,
> 
> Following patch fixed hvm KASSERT issue for me.  Not have a
> concrete scenario when or how the race condition broke.

Does it still happens with yesterday's commit which did fix a race in
cpu_idle() ? I can't see how this commit could fix the KASSERT issue, but
who knows ...

your patch may be the fix because of the way Xen interrupts work; an hypercall
(i386_switch_context will make 2) may return to hypervisor_callback()
instead of the code that called it; and the iret will return to where
the hypercall was done.
I wonder if when this happens within i386_switch_context() the iret could
return at the wrong place (e.g. in userland code with a process switch to
fully completed yet). 

Also your patch may cause interrupts that occured while they were
disabled to be deferred until the next interrupt happens (usually next clock
tick). This may be easily fixed though.

> 
> However, the related issue, slow hvm is not solved yet.
> When I use WinXP with recent kernel, I feel it is much
> slower than 4.99.18.  I feel something like below.
> e.g. 4.99.21 Xen3.1.0 took 30 sec to open empty start menu.
> 
> 4.99.18 Xen3.0.4 hvm WinXP(4/30 source)          base 1x slow
> 4.99.20 Xen3.0.4 hvm WinXP(5/18 src with this patch)  5x slow
> 4.99.21 Xen3.0.4 hvm WinXP(6/24 src with this patch)  5x slow
> 4.99.21 Xen3.1.0 hvm WinXP(6/24 src with this patch)  20x slow

again, maybe yesterday commits fixed it ... please try !

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--