Re: [Xen-devel] Followup: HVMOP_altp2m_vcpu_enable_notify code example usage

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

On Thu, Oct 27, 2016 at 12:45 AM, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:

On 26/10/2016 20:37, Matt Leinhos wrote:
> A while ago there was a thread by the same name in this group (see
> https://lists.xen.org/archives/html/xen-devel/2016-08/msg02591.html).
>
> I've looked through the thread and did not see a resolution: do we have
> an example handler for #VE - preferably on x86_64? I haven't found such
> a handler in the xen code or through searches.
>
> I am attempting to use the altp2m API from a domU and need to handle #VE.

A #VE handler is only interesting for a domU, knowing it is running
under an altp2m-capable hypervisor.

The hypervisor itself won't ever receive #VE from real hardware, which
is why there is no example code in Xen.

Well, unless Xen is running in a nested setting ;)

 

I don't know if there is any public example code, but a #VE handler in
domU is intended to work very similarly to a plain #PF handler.  #VE
specifically means "there is an EPT translation but the access failed
for permission reasons, and the guest has elected to handle this fault
itself".  It is then up to the domU kernel to decide what to do; whether
to terminate the process/thread which cause the violation, or to alter
the permissions and rerun the instruction.

Correct. The guest itself needs to issue the appropriate HVMOP hypercalls to enable #VE and register the memory location where the trap info should be stored at. The only caveat is that only permission faults in altp2m view 1-10 will generate a #VE in the domU, view 0 won't (at least when it is emulated on hw without real #VE support).

Tamas

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