Re: [kvm-devel] [BUG] Oops with KVM-27

[Luca <kronos.it@gmail.com>]

On 6/15/07, Luca Tettamanti <kronos.it@gmail.com> wrote:
> Il Fri, Jun 15, 2007 at 12:53:24AM +0200, Luca Tettamanti ha scritto:
> > Il Thu, Jun 14, 2007 at 11:26:29AM +0300, Avi Kivity ha scritto:
> > > Luca Tettamanti wrote:
> > > >With GOOD_APIC apic_read_around is a nop, while apic_write_around is a
> > > >normal write. With !GOOD_APIC apic_write_around writes to the APIC reg
> > > >using xchg. With !GOOD_APIC and this patch:
> > > >
> > > >--- include/asm-i386/apic.h~       2007-04-26 05:08:32.000000000 +0200
> > > >+++ include/asm-i386/apic.h        2007-06-13 22:35:00.000000000 +0200
> > > >@@ -56,7 +56,8 @@
> > > > static __inline fastcall void native_apic_write_atomic(unsigned long reg,
> > > >                                                  unsigned long v)
> > > > {
> > > >-  xchg((volatile unsigned long *)(APIC_BASE+reg), v);
> > > >+//        xchg((volatile unsigned long *)(APIC_BASE+reg), v);
> > > >+  *((volatile unsigned long *)(APIC_BASE+reg)) = v;
> > > > }
> > > >
> > > > static __inline fastcall unsigned long native_apic_read(unsigned long reg)
> > > >
> > > >The kernel boots fine.
> > > >
> > >
> > > Looking at the xchg emulation code, it seems fine, but clearly it
> > > isn't.
> >
> > Btw, I've put a printk in x86_emulate.c, where it prepares the operands
> > for the xchg operations: all the write_atomic are hitting this point,
> > so the write is lost somewhere in cmpxchg_emulated->write_emulated.
>
> Got it!
> The emulator skips the writeback if the old value is unchanged, so the
> apic doesn't see the write.
>
> Forcing the writeback:
>
> -      if ((d & Mov) || (dst.orig_val != dst.val)) {
> -      if ((d & Mov) || (dst.orig_val != dst.val) || isxchg) {
>
> seems to fix the issue :D I'm not sure that fix is correct though.

After a bit of thinking: it's correct but removes an optimization;
furthermore it may miss other instructions that write to memory mapped
areas.
A more proper fix should be "force the writeback if dst.ptr is in some
kind of mmio area".

Ok, enough of reply-to-self. I'll go to sleep...
Luca