Re: [Xen-devel] [PATCH] x86/vm_event: fix race between vmx_vmexit_handler() and vm_event_resume()

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 04/27/17 11:18, Jan Beulich wrote:
>>>> On 27.04.17 at 10:11, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> On 04/27/17 11:01, Jan Beulich wrote:
>>>>>> On 27.04.17 at 09:22, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>>> --- a/xen/arch/x86/hvm/hvm.c
>>>> +++ b/xen/arch/x86/hvm/hvm.c
>>>> @@ -473,6 +473,39 @@ static bool hvm_get_pending_event(struct vcpu *v, 
>>>> struct x86_event *info)
>>>>      return hvm_funcs.get_pending_event(v, info);
>>>>  }
>>>>  
>>>> +static void hvm_vm_event_set_registers(struct vcpu *v)
>>>> +{
>>>> +    ASSERT(v == current);
>>>> +
>>>> +    if ( v->arch.vm_event->set_gprs )
>>>
>>> I think we will want an unlikely() here. We anyway can only hope for
>>> the compiler to always inline this function, such that non-VM-event
>>> setups don't get penalized by the extra call here. Strictly speaking
>>> the function doesn't belong into this file ...
>>
>> Should I move it to the x86 vm_event code?
> 
> If you do, then you'll want to have an inline wrapper with the if()
> in it, so the actual call at the machine level would be avoided in the
> common case.

Sorry, I'm not sure I understand: if moving it is not required, I'd
prefer to leave it where it is, as we already have
vm_event_set_registers() in arch/x86/vm_event.c and I feel it would
complicate matters there (I'd have to perhaps prepend "hvm_" to it in
which case it wouldn't really belong in vm_event.c either). But if it's
necessary, I'll move it - do you want me to move it?


Thanks,
Razvan

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