Re: [Xen-devel] [PATCH v2 00/12] Alternate p2m: support multiple copies of host p2m

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 06/24/2015 04:32 PM, Lengyel, Tamas wrote:
> 
> 
> On Wed, Jun 24, 2015 at 1:39 AM, Razvan Cojocaru
> <rcojocaru@xxxxxxxxxxxxxxx <mailto:rcojocaru@xxxxxxxxxxxxxxx>> wrote:
> 
>     On 06/24/2015 12:27 AM, Lengyel, Tamas wrote:
>     > I've extended xen-access to exercise this new feature taking into
>     > account some of the current limitations. Using the altp2m_write|exec
>     > options we create a duplicate view of the default hostp2m, and instead
>     > of relaxing the mem_access permissions when we encounter a violation, we
>     > swap the view on the violating vCPU while also enabling MTF
>     > singlestepping. When the singlestep event fires, we use the response to
>     > that event to swap the view back to the restricted altp2m view.
> 
>     That's certainly very interesting. I wonder what the benefits are in
>     this case over emulating the fault-causing instruction (other than
>     obviously not going through the emulator)? The altp2m method would
>     certainly be slower, since you need more round-trips from userspace to
>     the hypervisor (the EPT vm_event handling + the singlestep event,
>     whereas with emulation you just reply to the original vm_event).
> 
> 
>     Regards,
>     Razvan
> 
> 
> Certainly, this is pretty slow right now, especially for the altp2m_exec
> case. However, sometimes you simply cannot emulate. For example if you
> write breakpoints into target locations, the original instruction has
> been overwritten with 0xCC. If you have a duplicate of the page without
> the breakpoint, this is an easy way to make the guest fetch the original
> instruction. Of course, if you extend the emulation routine where you
> can provide the instruction to emulate, instead of it being fetched from
> guest memory, that would be equally useful ;)

Makes sense, thanks for the explanation! Sure, sending back the
instruction to emulate could be something to consider for the future.


Thanks,
Razvan

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