RE: [Xen-devel] Re: X86_emulate to be moved into qemu...

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
> Sent: 18 May 2006 10:41
> To: Petersson, Mats
> Cc: Xen devel list
> Subject: Re: [Xen-devel] Re: X86_emulate to be moved into qemu...
> 
> 
> On 18 May 2006, at 10:33, Petersson, Mats wrote:
> 
> >> Yes, you could walk pagetables. But equally you can pass in your 
> >> translated CR2 value --- i.e., pass in a pseudophysical 
> address. That 
> >> address will then be passed to the special read/write hook 
> functions, 
> >> so you avoid needing to do the translation inside those.
> >
> > Hmm, yes. But we also want CS:rIP translated, which isn't 
> too bad. And 
> > for movs we have both the source and destination to take 
> into account.
> > ES:rDI isn't bad, but xS:rSI isn't as trivial, since we'd 
> have to scan 
> > for segment overrides in that case - and now we're starting to look 
> > like a bunch of decoding code in two places again... :-( 
> [Admittedly 
> > not quite as much]
> 
> The code should be passed in a buffer. This will be needed 
> for interfacing with VMX anyway, since it places the 
> instruction in a handy on-chip buffer for convenient readout. 
> That gets rid of any need for CS:RIP decoding.
> 
> Yes, we will need translation in a few places for 
> dual-memory-operand instructions (MOVS, stack instructions, 
> etc). So we will need to walk pagetables. It's just that the 
> *common* case will be to need no walk. 
> The segment override is no problem -- it's already implemented.

For the movs (in x86_emaulate.c) the segment override is currently
detected but ignored for protected mode operation (base is assumed to be
zero). This is why Minix doesn't work properly [or at all, really] -
admittedly, I don't think Minix is the most critical operating system in
the world, but one part of fixing this up is to avoid having to fix
furhter "weirdness" in various operating systems, right?

> 
>   -- Keir
> 
> 
> >> What header files are those? It builds in tools/test/ 
> without so many 
> >> header files.
> > 'hg status' says:
> 
> I'll fix that.

Ok, thanks. 

--
Mats
> 
>   -- Keir
> 
> > M ioemu/target-i386-dm/Makefile
> > M ioemu/target-i386-dm/helper2.c
> > ? ioemu/target-i386-dm/x86_emulate.c
> > ? libxc/asm-x86/bitops.h
> > ? libxc/asm-x86/cache.h
> > ? libxc/asm-x86/config.h
> > ? libxc/asm-x86/desc.h
> > ? libxc/asm-x86/mm.h
> > ? libxc/asm-x86/page.h
> > ? libxc/asm-x86/processor.h
> > ? libxc/asm-x86/regs.h
> > ? libxc/asm-x86/rwlock.h
> > ? libxc/asm-x86/spinlock.h
> > ? libxc/asm-x86/string.h
> > ? libxc/asm-x86/system.h
> > ? libxc/asm-x86/types.h
> > ? libxc/asm-x86/uaccess.h
> > ? libxc/asm-x86/x86_emulate.h
> > ? libxc/public/arch-x86_32.h
> > ? libxc/public/arch-x86_64.h
> > ? libxc/public/xen-compat.h
> > ? libxc/public/xen.h
> >
> > --
> > Mats
> >>
> >>   -- Keir
> >>
> >>
> >> _______________________________________________
> >> 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