[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
  • From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
  • Date: Thu, 18 May 2006 11:33:36 +0200
  • Cc: Xen devel list <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 18 May 2006 02:33:11 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcZ6A9iVdGwJhMJ1SDWPpRMYcE0sCwAUgmYg
  • Thread-topic: [Xen-devel] Re: X86_emulate to be moved into qemu...

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Keir Fraser
> Sent: 17 May 2006 21:15
> To: Petersson, Mats
> Cc: Xen devel list
> Subject: [Xen-devel] Re: X86_emulate to be moved into qemu...
> 
> 
> On 17 May 2006, at 21:17, Petersson, Mats wrote:
> 
> > When using x86_emulate.c inside qemu, we'd need to feed in 
> the virtual 
> > address, but we also need to translate to (guest-)physical address. 
> > Any hints or tricks for this, or do I need to read the 
> page-table and 
> > get the info that way [and CAN I even do that]? [And I'm 
> sorry if this 
> > shows my complete and utter ignorance of how Xen and QEMU operates 
> > together, but I'm afraid that I'm still learning these things].
> 
> 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] 

> 
> > Another interesting question is what we do with the dozen 
> or so "new"
> > include-files that are needed to make x86_emulate.c compile 
> inside the 
> > tools/ioemu directory. At the moment, I've just created directories 
> > inside tools/libxc and linked the necessary header files into those 
> > directories... Is that the proper solution?
> 
> What header files are those? It builds in tools/test/ without 
> so many header files.
'hg status' says:
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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.