This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Dave Lively" <dave.lively@xxxxxxxxx>
Subject: RE: [Xen-devel] X86_emulate to be moved into qemu...
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
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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... ;-) 


> 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