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
next 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.