Re: [Xen-devel] [PATCH v5] x86/mm: Suppresses vm_events caused by page-walks

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 04/30/2018 11:11 AM, Jan Beulich wrote:
>>>> On 28.04.18 at 08:13, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> On 04/28/2018 12:30 AM, Tamas K Lengyel wrote:
>>> On Mon, Apr 23, 2018 at 2:00 AM, Alexandru Isaila
>>> <aisaila@xxxxxxxxxxxxxxx> wrote:
>>>> This patch is adding a way to enable/disable inguest pagefault
>>>> events. It introduces the xc_monitor_inguest_pagefault function
>>>> and adds the inguest_pagefault_disabled in the monitor structure.
>>>> This is needed by the introspection so it will only get gla
>>>> faults and not get spammed with other faults.
>>>> In p2m_mem_access_check() we emulate so no event will get sent.
>>>
>>> This looks good to me, but is the emulator able to handle all
>>> instructions that may trigger it here?
>>
>> That's a very good question. We think not, but we now have the 
>> UNIMPLEMENTED emulator event. The thought here is that the emulator 
>> would be able to handle most cases, and then the ones it can't handle we 
>> can handle with altp2m.
>>
>> Of course, it's not ideal - we'd rather have a mechanism that's 
>> consistently foolproof, but I believe that Jan's objection is correct: 
>> we can't really be sure that the first time we get into access_check() 
>> with a specific [RIP:GLA] pair we need to set the A bit and the second 
>> time the D bit (interrupts may trip this logic up).
> 
> Interrupts are only one aspect. Insns sent back to guest context for
> retry (like AVX2 gathers would commonly do) are another afaict.
> 
>> Furthermore, with 
>> SVM the GLA is not available for page faults (although that's fixable by 
>> comparing GPAs).
> 
> I may not have enough context here, but is that true when multiple
> linear addresses are mapped to the same physical page?

No, you are right. Quite possibly a case like that can happen where
comparing GPAs is not enough.

So as far as I can tell, we can either do this best-effort thing with
trying to emulate the instruction and hope for the best (and handle
UNIMPLEMENTED when necessary), or A) know exactly when we need to set
the A bit and when the D bit - I've not been able to find a foolproof
way of doing that -, or B) single-step GPT page faults directly on
hardware _in_the_hypervisor_, for which there is currently no mechanism
- although one can be seen as doable on top of the altp2m infrastructure
in the future.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel