On 04/28/2018 09:13 AM, Razvan Cojocaru wrote:
On 04/28/2018 12:30 AM, Tamas K Lengyel wrote:
On Mon, Apr 23, 2018 at 2:00 AM, Alexandru Isaila
<aisa...@bitdefender.com> 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.
The only surefire way we have here is to single-step with the monitor
trap flag set and with an unrestricted altp2m - or similar. We're doing
something like that with XenServer:
https://github.com/xenserver/xen.pg/blob/XS-7.1.x/master/xen-reexecute-instn-under-monitor-trap.patch
But IIRC that patch had basically been nacked at the time, and I don't
see a nice way of making the same logic work with alt2pm _without_
having vm_events triggered (which is what this optimization is about),
due to, mainly, the fact that hostp2m changes propagate into altp2ms.
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
