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

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


  • To: "Dave Lively" <dave.lively@xxxxxxxxx>
  • From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
  • Date: Fri, 19 May 2006 15:51:16 +0200
  • Cc: Xen devel list <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 19 May 2006 06:50:37 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcZ7SOMYpKZFbWj0SWyCHU32vQ08cgAANxow
  • Thread-topic: [Xen-devel] X86_emulate to be moved into qemu...

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Dave Lively
> Sent: 19 May 2006 14:32
> To: Petersson, Mats
> Cc: Xen devel list
> Subject: Re: [Xen-devel] X86_emulate to be moved into qemu...
> 
> Hi --
> 
>   Please excuse me jumping in late on this thread.  I'm 
> missing a bit of context, so maybe I'm misunderstanding 
> something.  But ...
> 
>   Since QEMU is single-threaded, won't moving the x86_emulate 
> code into there be a huge SMP performance bottleneck?  What's 
> the rationale for doing this?

It's not ADDING (much of) a bottleneck, as the code that is in HVM at
the moment is calling QEMU anyways - the only difference is that we'd be
calling QEMU with a slightly less decoded instruction format, in order
to re-use the x86_emulate's ability to decode instructions - and when
expanding on the instruction set, we only need to do it once, rather
than the current scenario where we two different decoding sets, that use
very different format [actually, there's a third copy of decoding-logic,
which is a stripped down copy of x86_emulate.c, which is the instrlen.c
in svm, which we also would like to remove...]

I already looked at using the x86_emulate code inside the HVM code, but
that doesn't work since we have to task-switch to QEMU to get the
hardware data (say we're doing a RMW operation on the video memory - we
need to read video memory, then modify it, then write it back). Even if
it was possible to do a task-switch and actually return where the code
was called from, it would still require a SECOND task-switch to write
the modified data back... Although I guess it would be ever so slightly
less bothersome from a SMP perspective, perhaps... 

Your point is very valid, but I don't see any other (sane) solution.
Making QEMU multi-threaded would of course make it a bit better... Not
sure how easy that would be, and how to deal with multiple accesses to
the same device from multiple processors - not that the real hardware is
any good at that either... ;-) 

--
Mats


> 
> Thanks,
> Dave
> 
> 
> On 5/17/06, Petersson, Mats <Mats.Petersson@xxxxxxx> wrote:
> > When using x86_emulate.c inside qemu, we'd need to feed in 
> the virtual
> 
> _______________________________________________
> 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®.