[Xen-devel] Status of VM event patches (Was: Re: Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble))

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 06/26/2015 02:16 PM, wei.liu2@xxxxxxxxxx wrote:
> *  VM event patches (none)
>    Add support for XSETBV vm_events,
>    Support hybernating guests
>    Support for VMCALL-based vm_events
>   -  Razvan Cojocaru

Since V2, there are now 3 more patches that we'd like to see in Xen
mainline at some point:

1. The patch we've originally submitted that computed the current
instruction length in order to be able to skip it completely (instead of
emulating it with dummy nop write operations) has been somewhat
controversial. To that end, we're now computing the instruction length
in the userspace application, and simply send the new EIP back to the HV
in the vm_event reply, so that skipping instructions can work without a
lot of code added to Xen.

2. In the past, we've aways disabled REP optimizations (forcing *reps to
1) when introspection is active. Tamas' work now gates this on
current->domain->arch.mem_access_emulate_enabled in
xen/arch/x86/hvm/emulate.c. A side effect of that is that Windows HVM
guests tend to boot much slower. We'd like to add a dedicated libxc
function that enables / disables this pessimization explicitly.

3. And finally, our ARM team is using the new VMCALL-based hypercall and
have provided a patch that enables the vm_event on ARM. This will
require some work with Tamas since it is my suspicion that there's code
there that should become common between x86 and ARM and has been, at the
moment, more or less copied from x86 (basically xen/arch/arm/event.c and
xen/arch/arm/monitor.c).

The question is, would it be appropriate to add those patches to V3? And
if that's not a problem, how likely is that to affect the current series
getting in before the 4.6 release (that is, assuming that's a realistic
goal, seeing how the feature freeze is two weeks away)? Just trying to
make sure that I go about this the right way.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel