Re: [Xen-devel] [qemu-upstream-unstable test] 21375: regressions - FAIL

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.11.13 at 18:18, Anthony PERARD <anthony.perard@xxxxxxxxxx> wrote:
> An other update,
> 
> we had the idee of trying this on earlier versin of Xen, and it turns
> out that Xen 4.3 works fine. One bisect later, and a commit turns out.
> 
> commit 86781624f8df1d50eb4185cfc2ddce926798f7aa
> x86_emulate: PUSH <mem> must read source operand just once
> ... for the case of accessing MMIO.
> 
> So after this commit, syslinux stop working correctly with the last
> version of QEMU. This happen if QEMU is calling track_dirty_vram.
> 
> I also have use xentrace/xenalyze to try to grab more information about
> the issue, it did not really help, but it's tell me that the guest is
> stock on a specific instruction (it result in vmexit EPT_VIOLATION over
> and over on xentrace). And that were the guest is stock:
> 
>    0xa126:  mov    %eax,%cr0
>    0xa129:  ljmp   $0xf2e,$0xa12e
>    0xa130:  mov    $0x26,%dl
>    0xa132:  or     %bh,(%eax)
>    0xa134:  movzww %sp,%sp
>    0xa138:  mov    %edx,%ds
>    0xa13a:  mov    %edx,%es
>    0xa13c:  mov    %edx,%fs
>    0xa13e:  mov    %edx,%gs
>    0xa140:  jmp    *%ebx
>    0xa142:  pushf  
> => 0xa143:  lcall  *%cs:(%si)
>    0xa147:  mov    $0x0,%ch
> 
> Before trying on earlier version of Xen, I try to understand what when
> wrong on the Xen side, it turn out that, in the track_dirty_vram
> hypercall, a call to hap_enable_log_dirty() is all that needed to break
> the guest.
> 
> Jan, any idee of what the issue is?

Oh, indeed, I screwed this up without noticing. Please try the
attached patch.

Jan

Attachment: x86-emul-far-call.patch
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel