All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keir Fraser <keir@xensource.com>
To: Anthony Liguori <aliguori@linux.vnet.ibm.com>,
	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: Re: V2E tree on xenbits update
Date: Tue, 16 Jan 2007 09:56:21 +0000	[thread overview]
Message-ID: <C1D251C5.73B0%keir@xensource.com> (raw)
In-Reply-To: <45ABDE3F.1000805@linux.vnet.ibm.com>

On 15/1/07 8:04 pm, "Anthony Liguori" <aliguori@linux.vnet.ibm.com> wrote:

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

My suspicion is that we may need to make shadow mode aware of this foreign
mapping of HVM pages, and allow it (somehow) to keep write protection in
sync. Other techniques are likely to either be racey or slow in the common
case. We have to be able to do atomic RMW instructions on shadowed
pagetables which as you say is troublesome in two ways: qemu doesn't do true
atomic instructions and, even if it did, the update would not synchronise
with other vcpus on the shadow_lock (consider XCHG(ptep, 0) racing with
another vcpu about to dirty the mapped page for the first time -- we could
lose the dirty bit and/or fail to remove the ptep mapping).

I wonder if shadow awareness would be easier if we had the 'stub domain'
functionality, so a tighter binding between HVM and qemu, recognised by Xen.

 -- Keir

      reply	other threads:[~2007-01-16  9:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-15 20:04 V2E tree on xenbits update Anthony Liguori
2007-01-16  9:56 ` Keir Fraser [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=C1D251C5.73B0%keir@xensource.com \
    --to=keir@xensource.com \
    --cc=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.