All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.