xen: generic instruction re-execution mechanism for execute faults

xen: generic instruction re-execution mechanism for execute faults

[Mihai Donțu]

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. One would rather have to somehow tap into qemu (if at all
possible).

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.

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

Thanks,

-- 
Mihai Donțu

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

Re: xen: generic instruction re-execution mechanism for execute faults

[Andrew Cooper]

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@lists.xen.org
http://lists.xen.org/xen-devel