From: Anthony Liguori <aliguori@us.ibm.com>
To: mark.williamson@cl.cam.ac.uk
Cc: xen-devel@lists.xensource.com, Serge Dubrouski <sergeyfd@gmail.com>
Subject: Re: Re: [Xen-users] Xen + QEMU Accelerator
Date: Mon, 22 May 2006 13:22:05 -0500 [thread overview]
Message-ID: <4472014D.3050409@us.ibm.com> (raw)
In-Reply-To: <Prayer.1.0.16.0605221805010.21237@hermes-1.csi.cam.ac.uk>
M.A. Williamson wrote:
>> Has anybody tried to use QEMU Accelerator (kqemu) with Xen? Any luck
>> with improving performance then?
>
> I rather doubt that it'll work - it bangs the hardware direcly in a
> few ways that isn't allowed for Xen guests.
It won't. The kqemu docs mention this specifically.
> The most promising approach would probably be a port of the QVM86
> module (an open source accelerator for Qemu) but this is unable to
> accelerate kernel-mode code and is therefore limited compared to
> Fabrice's kqemu.
qvm86 has suffered a little bit of bit rot recently however Jim Brown
was attempting to port qvm86 to Xen at one point. It's definitely quite
possible although it would require a fair bit of work I think.
>> From a quick reading of the code, I suspect that more abstraction
>> would be
> necessary to encapsulate the direct hardware manipulations.
>
> I'm cc-ing xen-devel in case anybody there has looked at / thought
> about / talked abut this. Any further posters should remove xen-devel
> if they have usage-related queries, since we like to keep that list
> solely for development-related traffic.
There has been a lot of discussion lately about moving a new full
version of qemu into the Xen tree for HVM domains. One of the
advantages of this is that when IO exits are taken, a block of
instructions can be emulated to amortize the cost of a world switch when
exits occur back-to-back. You would essentially just always emulate
1000 instructions or something.
I think it becomes pretty obvious that if we do this for HVM domains,
it's quite simple to extend this idea to emulate instructions until you
transition back to ring 3. This would essentially give you qvm86-like
functionality. It also gives you the ability to run HVM domains in the
absence of VT/SVM which I think is a pretty useful feature (although you
would take a performance hit probably).
Regards,
Anthony Liguori
> Cheers,
> mark
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
prev parent reply other threads:[~2006-05-22 18:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <868cbbaa0605220945h6cf64baby828a7b79f28a8968@mail.gmail.com>
2006-05-22 17:05 ` Xen + QEMU Accelerator M.A. Williamson
2006-05-22 18:22 ` Anthony Liguori [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4472014D.3050409@us.ibm.com \
--to=aliguori@us.ibm.com \
--cc=mark.williamson@cl.cam.ac.uk \
--cc=sergeyfd@gmail.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.