[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] V2E tree on xenbits update



On 15/1/07 8:04 pm, "Anthony Liguori" <aliguori@xxxxxxxxxxxxxxxxxx> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.