All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <aliguori@us.ibm.com>
To: Joshua LeVasseur <jtl@ira.uka.de>
Cc: xen-devel@lists.xensource.com
Subject: Re: Automated para-virtualization
Date: Tue, 05 Apr 2005 22:56:42 -0500	[thread overview]
Message-ID: <42535DFA.10006@us.ibm.com> (raw)
In-Reply-To: <E1DIxxR-0007GW-TE@host-192-168-0-1-bcn-london>

Joshua LeVasseur wrote:

>Hello,
>  
>
Hi Joshua,

>We, University of Karlsruhe and UNSW/NICTA, have been working on a technique
>to automate para-virtualization, in the hopes of simplifying the maintenance
>of the various guest OSs, and would like to share our results to date.
>  
>
Very interesting...

>The basis of our solution is instruction substitution at the assembler level
>in order to replace the virtualization-sensitive operations of the guest OS.
>The virtualization-sensitive operations include instructions and memory
>accesses (such as to page tables or device registers).
>  
>
So you annotate access to mmio or page tables?  Was this for performance 
or was it not possible to emulate mmio operations and trap writes to the 
page table?

If you were able to avoid having to annotate these things, I presume you 
could virtualize Linux with no modifications?  Even if this resulted in 
performance degradation, I can imagine scenarios where having this 
option would be very useful (especially for supporting legacy 
distributions).

>annotations).  There are a few additional changes for the build process.
>  
>
Would it be possible to package your tools as a cross-compiler 
environment so that all you had to do is set CROSS_COMPILE appropriately?

>Our current research is to enable run-time migrations between incompatible
>hypervisors, or between different versions of the same hypervisor, by
>rewriting the instruction substitutions at time of migration.  Additionally,
>we envisage that one can install a hypervisor underneath an OS which runs on
>bare metal.
>  
>
Does this mean that you maintain the patch table and support unpatching 
a patched image or do you simply keep a copy of the unpatched kernel?

Any thoughts on supporting kernel modules?  Would you have to prepatch a 
module?

>We have a high speed network device emulation, for the DP83820 driver, based
>on the sensitive memory instruction substitution (an additional several line
>patch to enable manual annotations).  If the guest OS uses the DP83820
>device, then it has high-speed access to devices running in Dom0.  The speed
>is comparable to using a customized device driver.  By using the DP83820
>device, a guest OS can migrate between different hypervisors, since the
>state is encapsulated in a model, and not a driver.
>  
>
Have you implemented any other emulated devices?

>We will shortly release the code under a BSD license.
>  
>
Great!  Look forward to seeing the code.  Looks like you guys have been 
doing really cool stuff :-)

Regards,
Anthony Liguori

       reply	other threads:[~2005-04-06  3:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1DIxxR-0007GW-TE@host-192-168-0-1-bcn-london>
2005-04-06  3:56 ` Anthony Liguori [this message]
2005-04-06 15:08   ` Automated para-virtualization Joshua LeVasseur
2005-04-05 23:59 Joshua LeVasseur

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=42535DFA.10006@us.ibm.com \
    --to=aliguori@us.ibm.com \
    --cc=jtl@ira.uka.de \
    --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.