From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: V2E tree on xenbits update Date: Tue, 16 Jan 2007 09:56:21 +0000 Message-ID: References: <45ABDE3F.1000805@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <45ABDE3F.1000805@linux.vnet.ibm.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Anthony Liguori , xen-devel Cc: Ian Pratt , Daniel Stekloff , Guillaume Thouvenin , "Nakajima, Jun" List-Id: xen-devel@lists.xenproject.org On 15/1/07 8:04 pm, "Anthony Liguori" 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