[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |