* Vmx_vmenter_helper() and hvm_inject_page_fault()
@ 2013-11-06 9:31 Razvan Cojocaru
2013-11-06 9:49 ` Jan Beulich
0 siblings, 1 reply; 8+ messages in thread
From: Razvan Cojocaru @ 2013-11-06 9:31 UTC (permalink / raw)
To: xen-devel
Hello,
is it safe to call hvm_inject_page_fault() (with PFEC_user_mode set)
in vmx_vmenter_helper()?
A related question: is it OK to check that we're in user mode there
with "!guest_kernel_mode(current, guest_cpu_user_regs())"?
Thanks.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Vmx_vmenter_helper() and hvm_inject_page_fault()
2013-11-06 9:31 Vmx_vmenter_helper() and hvm_inject_page_fault() Razvan Cojocaru
@ 2013-11-06 9:49 ` Jan Beulich
[not found] ` <CAM-wkEsVZx4AxqYEz5UxuteiMkLNA9Ngq+6dj1bwjA-ZB3rFnQ@mail.gmail.com>
0 siblings, 1 reply; 8+ messages in thread
From: Jan Beulich @ 2013-11-06 9:49 UTC (permalink / raw)
To: Razvan Cojocaru; +Cc: xen-devel
>>> On 06.11.13 at 10:31, Razvan Cojocaru <rzvncj@gmail.com> wrote:
> is it safe to call hvm_inject_page_fault() (with PFEC_user_mode set)
> in vmx_vmenter_helper()?
At a first glance I would say "no" here, ...
> A related question: is it OK to check that we're in user mode there
> with "!guest_kernel_mode(current, guest_cpu_user_regs())"?
... and yes here, pointing out that in both cases this is likely
wrong anyway (as being too late in the process, and as being
bogus, since there shouldn't be anything [other than perhaps
logging for debugging purposes] at this point that could possibly
cause you to need to do either of the two).
Jan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Fwd: Vmx_vmenter_helper() and hvm_inject_page_fault()
[not found] ` <CAM-wkEsVZx4AxqYEz5UxuteiMkLNA9Ngq+6dj1bwjA-ZB3rFnQ@mail.gmail.com>
@ 2013-11-06 10:41 ` Razvan Cojocaru
2013-11-06 11:26 ` Jan Beulich
1 sibling, 0 replies; 8+ messages in thread
From: Razvan Cojocaru @ 2013-11-06 10:41 UTC (permalink / raw)
To: xen-devel
Thank you for your answer.
> ... and yes here, pointing out that in both cases this is likely
> wrong anyway (as being too late in the process, and as being
> bogus, since there shouldn't be anything [other than perhaps
> logging for debugging purposes] at this point that could possibly
> cause you to need to do either of the two).
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? If not, what would be a better place to put this page
fault injection assuming I'd like to trigger it at VMENTER time?
Thanks again.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Vmx_vmenter_helper() and hvm_inject_page_fault()
[not found] ` <CAM-wkEsVZx4AxqYEz5UxuteiMkLNA9Ngq+6dj1bwjA-ZB3rFnQ@mail.gmail.com>
2013-11-06 10:41 ` Fwd: " Razvan Cojocaru
@ 2013-11-06 11:26 ` Jan Beulich
2013-11-06 15:09 ` Razvan Cojocaru
1 sibling, 1 reply; 8+ messages in thread
From: Jan Beulich @ 2013-11-06 11:26 UTC (permalink / raw)
To: Razvan Cojocaru; +Cc: xen-devel
(re-adding xen-devel)
>>> On 06.11.13 at 11:00, Razvan Cojocaru <rzvncj@gmail.com> wrote:
>> ... and yes here, pointing out that in both cases this is likely
>> wrong anyway (as being too late in the process, and as being
>> bogus, since there shouldn't be anything [other than perhaps
>> logging for debugging purposes] at this point that could possibly
>> cause you to need to do either of the two).
>
> 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.
Jan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Vmx_vmenter_helper() and hvm_inject_page_fault()
2013-11-06 11:26 ` Jan Beulich
@ 2013-11-06 15:09 ` Razvan Cojocaru
2013-11-06 16:53 ` Tim Deegan
0 siblings, 1 reply; 8+ messages in thread
From: Razvan Cojocaru @ 2013-11-06 15:09 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel
>> 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.
Thanks.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Vmx_vmenter_helper() and hvm_inject_page_fault()
2013-11-06 15:09 ` Razvan Cojocaru
@ 2013-11-06 16:53 ` Tim Deegan
2013-11-07 11:43 ` Razvan Cojocaru
0 siblings, 1 reply; 8+ messages in thread
From: Tim Deegan @ 2013-11-06 16:53 UTC (permalink / raw)
To: Razvan Cojocaru; +Cc: xen-devel, Jan Beulich
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Vmx_vmenter_helper() and hvm_inject_page_fault()
2013-11-06 16:53 ` Tim Deegan
@ 2013-11-07 11:43 ` Razvan Cojocaru
2013-11-07 19:24 ` Tim Deegan
0 siblings, 1 reply; 8+ messages in thread
From: Razvan Cojocaru @ 2013-11-07 11:43 UTC (permalink / raw)
To: Tim Deegan; +Cc: xen-devel, Jan Beulich
Hello Tim, thank you for your answer!
> 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'.
Good suggestion, I'm exploring it as we speak.
But, I would also like to know what the dangers of doing this in the
VMENTRY helper function are. Is it that the VMCS information is not yet
fully there? Is guest_cpu_user_regs() not reliable at that point? What
exactly could go wrong there?
Thanks.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Vmx_vmenter_helper() and hvm_inject_page_fault()
2013-11-07 11:43 ` Razvan Cojocaru
@ 2013-11-07 19:24 ` Tim Deegan
0 siblings, 0 replies; 8+ messages in thread
From: Tim Deegan @ 2013-11-07 19:24 UTC (permalink / raw)
To: Razvan Cojocaru; +Cc: xen-devel, Jan Beulich
At 13:43 +0200 on 07 Nov (1383828227), Razvan Cojocaru wrote:
> Hello Tim, thank you for your answer!
>
> > 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'.
>
> Good suggestion, I'm exploring it as we speak.
>
> But, I would also like to know what the dangers of doing this in the
> VMENTRY helper function are. Is it that the VMCS information is not yet
> fully there? Is guest_cpu_user_regs() not reliable at that point? What
> exactly could go wrong there?
vmx_vmenter_helper() is called last thing on the VMENTER code path,
after all the other checks that happen before guest entry. Injecting
a trap can change vcpu state in ways that invalidate those checks
(e.g. by causing a nested-hvm guest to do an emulated VMEXIT, or by
triggering an emulated triple fault). It's also called with
interrupts disabled, though I don't see a specific example where that
would cause trouble.
Tim.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-11-07 19:24 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-06 9:31 Vmx_vmenter_helper() and hvm_inject_page_fault() Razvan Cojocaru
2013-11-06 9:49 ` Jan Beulich
[not found] ` <CAM-wkEsVZx4AxqYEz5UxuteiMkLNA9Ngq+6dj1bwjA-ZB3rFnQ@mail.gmail.com>
2013-11-06 10:41 ` Fwd: " Razvan Cojocaru
2013-11-06 11:26 ` Jan Beulich
2013-11-06 15:09 ` Razvan Cojocaru
2013-11-06 16:53 ` Tim Deegan
2013-11-07 11:43 ` Razvan Cojocaru
2013-11-07 19:24 ` Tim Deegan
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.