Re: [Xen-devel] xen: generic instruction re-execution mechanism for execute faults

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 09/09/2014 04:01, Mihai DonÈu wrote:
> Hi,
>
> This is another patch from which we stepped back for a while in order
> to give it a better thought:
>
> http://lists.xenproject.org/archives/html/xen-devel/2014-07/msg00309.html
>
> Our argument for it is that memory introspection technologies can cause
> a VMEXIT practically at any point during the guest execution, even
> without any 'malicious' activity going on in it. If the instruction
> that caused the exit is well within a protected page, we would need to:
>
>   a) emulate it
>   b) single step it
>
> The emulation part would be the desired option, but unfortunately it
> requires a full blown emulator which I believe is beyond the scope of
> Xen.

As I said on the thread before, the current emulator in Xen is all Xen
has needed in the past.

I think it is perfectly reasonable to extend the emulator if a plausible
use (such as this) arises, but we would specifically want to avoid is
having multiple emulators in Xen.

>  One would rather have to somehow tap into qemu (if at all
> possible).

It is technically possible, but the overheads would be massive.

>
> The other option, which is permanent in that it does not need to be
> maintained like an emulator, is to suspend all vCPU's, grant
> permissions to the fault page, single step the guest, return to Xen and
> then resume. It has a bit of overhead, but the fact that this code path
> is seldom taken and cumulated with the efficiency of latest hardware
> makes it the better choice. Also, the tests we have conducted show no
> observable slowdown.

No observable slowdown from whose point of view? How often are
instructions trapped and replayed like this?

>
> In conclusion: is there any way we can bring this idea (either in the
> proposed form by the patch or any other) into Xen?

A proposition email like this with a clear high level goal is certainly
a good start.

~Andrew


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