V2E tree on xenbits update

V2E tree on xenbits update

[Anthony Liguori]

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

Re: V2E tree on xenbits update

[Keir Fraser]

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