Followup: HVMOP_altp2m_vcpu_enable_notify code example usage

Followup: HVMOP_altp2m_vcpu_enable_notify code example usage

[Matt Leinhos]

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.

Thank you,
Matt Leinhos
Star Lab, San Antonio, TX


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

Re: Followup: HVMOP_altp2m_vcpu_enable_notify code example usage

[Andrew Cooper]

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.

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.

~Andrew

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

Re: Followup: HVMOP_altp2m_vcpu_enable_notify code example usage

[Tamas K Lengyel]

[-- Attachment #1.1: Type: text/plain, Size: 1676 bytes --]

On Thu, Oct 27, 2016 at 12:45 AM, Andrew Cooper <andrew.cooper3@citrix.com>
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

[-- Attachment #1.2: Type: text/html, Size: 2475 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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