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

[Razvan Cojocaru <rcojocaru@bitdefender.com>]

On 07/06/2015 06:00 PM, Wei Liu wrote:
> On Fri, Jun 26, 2015 at 06:23:02PM +0300, Razvan Cojocaru wrote:
>> On 06/26/2015 02:16 PM, wei.liu2@citrix.com 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.
>>
> 
> Not speaking from technical point of view but from the time scale point
> of view, I don't think you should rush your 3 new patches at this stage.
> 
> You sent several patch series. I don't have the expertise or time to
> keep track of all of them so I couldn't tell how feasible it is for them
> to be ready for 4.6. I tend to say if they are not nearly all acked,
> they would need to wait until 4.7.

Of course. Thanks for the reply! Will keep the current series as it is,
and not add anything new (I'll just keep addressing reviews).


Thanks,
Razvan