On 02/16/2018 02:39 PM, Razvan Cojocaru wrote:
> On 02/16/2018 02:37 PM, Roger Pau Monné wrote:
>> On Fri, Feb 16, 2018 at 02:30:55PM +0200, Razvan Cojocaru wrote:
>>> On 02/16/2018 02:10 PM, Roger Pau Monne wrote:
>>>> diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
>>>> index f229e69948..4317658c56 100644
>>>> --- a/xen/arch/x86/monitor.c
>>>> +++ b/xen/arch/x86/monitor.c
>>>> @@ -189,10 +189,11 @@ int arch_monitor_domctl_event(struct domain *d,
>>>> ad->monitor.write_ctrlreg_enabled &= ~ctrlreg_bitmask;
>>>> }
>>>>
>>>> - if ( VM_EVENT_X86_CR3 == mop->u.mov_to_cr.index )
>>>> + if ( VM_EVENT_X86_CR3 == mop->u.mov_to_cr.index ||
>>>> + VM_EVENT_X86_CR4 == mop->u.mov_to_cr.index )
>>>> {
>>>> struct vcpu *v;
>>>> - /* Latches new CR3 mask through CR0 code. */
>>>> + /* Latches new CR3 or CR4 mask through CR0 code. */
>>>> for_each_vcpu ( d, v )
>>>> hvm_update_guest_cr(v, 0);
>>>> }
>>>
>>> Did you, by any chance, test this code with xen-access.c (it already has
>>> a test for CR4 for the PGE stuff)? I'm not convinced the
>>> hvm_update_guest_cr(v, 0); call suffices to enable CR4 load exits.
>>
>> hvm_update_guest_cr is just a wrapper to vmx_update_guest_cr when
>> using vmx, which will unconditionally re-calculate the CR4 mask when
>> called with cr == 0 or cr == 4.
>>
>> I have not tested it with xen-access, but it seems quite
>> straightforward to me. Are you seeing any other path that could
>> enable CR4 load accesses without calling hvm_update_guest_cr?
>
> No, I thought I did but as it turns out it wasn't. I'll run a quick test
> on the patches just to make sure though. They should be alright.
Ran a few tests, and everything appears to be in order. For the monitor
/ vm_event parts:
Acked-by: Razvan Cojocaru <rcojoc...@bitdefender.com>
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
