Re: [Xen-devel] Vmx_vmenter_helper() and hvm_inject_page_fault()

[Tim Deegan <tim@xxxxxxx>]

At 17:09 +0200 on 06 Nov (1383754147), Razvan Cojocaru wrote:
> >> OK, let's assume that I need it for debugging purposes. Should the
> >> call, assuming that I check for usermode as explained above before
> >> calling hvm_inject_page_fault(ec | PFEC_user_mode, address), work as
> >> advertised?
> >
> > I'm not sure, which is why I'd recommend against it. As said, I
> > could see you use the usermode check for debugging purposes,
> > but I can't see what use injection of a #PF there would have.
> >
> >> If not, what would be a better place to put this page
> >> fault injection assuming I'd like to trigger it at VMENTER time?
> >
> > You ought to do all this in the context of handling the
> > corresponding VMEXIT.
> 
> Well, the scenario would be this (bear with me here): there'd be a
> hypercall setting up pagefault injection in the HV. This hypercall
> would be called from dom0 userspace as part as handing a mem_event.
> Now, when the guest gets control again, it would inject a page fault
> based on the information previously sent to the HV. The only obvious
> place (to me) where this could happen correctly would be somewhere in
> the VMENTRY code - it might be too late by the time the next VMEXIT is
> reached. So I'm looking for a safe and robust way to do that.

If you need to get back into the vmexit handler you could deliberately
set the VMCS to an invalid state, and detect/fix up in the vmexit
handler routine.

Or, even easier, just leave the EPT state that caused the mem_event in
the first place -- if the guest retries the instruction it will exit
again with the same fault and you can have some state in the EPT fault
handler to say 'next time, inject a pagefault'.

Cheers,

Tim.

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