All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <aliguori@linux.vnet.ibm.com>
To: xen-devel <xen-devel@lists.xensource.com>
Cc: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>,
	Daniel Stekloff <dsteklof@us.ibm.com>,
	Guillaume Thouvenin <guillaume.thouvenin@bull.net>,
	"Nakajima, Jun" <jun.nakajima@intel.com>
Subject: V2E tree on xenbits update
Date: Mon, 15 Jan 2007 14:04:15 -0600	[thread overview]
Message-ID: <45ABDE3F.1000805@linux.vnet.ibm.com> (raw)

Howdy,

I've got the V2E tree on xenbits updated to tip (as of this weekend).  
There are a couple interesting issues that have cropped up based on some 
changes that have occurred since 3.0.3:

 * The map cache is incompatible with V2E.  This isn't that big of a 
problem since we can use the virtual TLB to simulate the map cache.  At 
the moment, we just disable the map cache.

 * OpenSuSE works quite happily (including gfxboot) provided we disable 
the APIC.  Recently the APIC was enabled unconditionally which means 
that OpenSuSE no longer will boot properly.  If I patch out the APIC, 
things work again.  To address this, we need some more infrastructure in 
V2E to handle device synchronization between the emulator and the 
hypervisor.  FC5 works just fine even with the APIC enabled.

There are still some larger issues (mostly SMP related):

 * There's no guarantee ATM that QEMU's dynamic translator will preserve 
the atomicity of instructions.  For SMP guests, this would be a problem 
if one VCPU is running on bare metal while another VCPU is running in 
the emulator.

 * It's unclear what the best strategy is for addressing page table 
updates while in the emulator.  There has to be some notification to the 
hypervisor so that the shadow code knows to invalidate any PT changes 
made during emulation.

 * We aren't invalidating the TB cache ATM in QEMU.  Strictly speaking, 
this isn't correct as the hypervisor could change pages that contain 
code that are currently in the TB cache.  To make matters worse, there's 
some rather strange results that could occur if one VCPU is running on 
bare metal and modifying a page that's currently present in the TB cache.

Presumably, the SMP issues aren't really that important while simply 
replacing vmxassist but I'm not entirely clear on how long it will take 
after the initial transfer from 16 bit until SMP processors are brought 
online.

The current bits are available at:

http://xenbits.xensource.com/ext/xen-unstable-hvm.hg

Regards,

Anthony Liguori

             reply	other threads:[~2007-01-15 20:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-15 20:04 Anthony Liguori [this message]
2007-01-16  9:56 ` V2E tree on xenbits update Keir Fraser

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=45ABDE3F.1000805@linux.vnet.ibm.com \
    --to=aliguori@linux.vnet.ibm.com \
    --cc=dsteklof@us.ibm.com \
    --cc=guillaume.thouvenin@bull.net \
    --cc=jun.nakajima@intel.com \
    --cc=m+Ian.Pratt@cl.cam.ac.uk \
    --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.