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

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Sat, Apr 28, 2018 at 12:13 AM, Razvan Cojocaru
<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). Furthermore, with SVM the GLA is not
> available for page faults (although that's fixable by comparing GPAs).
>
> If there's a better way to do this optimization that we haven't seen we'd be
> happy to switch the implementation. Suggestions are welcome.

My only worry is that this interface as-is will give someone the false
impression that this will "just work" all the time. Which is not the
case. If it needs the UNIMPLEMENTED event to be enabled as well I
would either make that a requirement for enabling this feature, or at
the minimum extensively documenting how that should be setup,
including an example in xen-access.c

Tamas

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