* Is it safe to assume that v == current in hvm_do_resume()?
@ 2014-10-22 8:11 Razvan Cojocaru
2014-10-22 9:04 ` Andrew Cooper
0 siblings, 1 reply; 3+ messages in thread
From: Razvan Cojocaru @ 2014-10-22 8:11 UTC (permalink / raw)
To: xen-devel@lists.xen.org
Hello,
As far as I've understood the code, and based on several tests, it would
appear that in xen/arch/x86/hvm/hvm.c, the struct vcpu *v parameter to
hvm_do_resume() is always equal to current.
Is that a reasonable assumption to make? I could have missed some use
cases for the function.
Thanks,
Razvan
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Is it safe to assume that v == current in hvm_do_resume()?
2014-10-22 8:11 Is it safe to assume that v == current in hvm_do_resume()? Razvan Cojocaru
@ 2014-10-22 9:04 ` Andrew Cooper
2014-10-22 9:10 ` Razvan Cojocaru
0 siblings, 1 reply; 3+ messages in thread
From: Andrew Cooper @ 2014-10-22 9:04 UTC (permalink / raw)
To: Razvan Cojocaru, xen-devel@lists.xen.org
On 22/10/14 09:11, Razvan Cojocaru wrote:
> Hello,
>
> As far as I've understood the code, and based on several tests, it would
> appear that in xen/arch/x86/hvm/hvm.c, the struct vcpu *v parameter to
> hvm_do_resume() is always equal to current.
>
> Is that a reasonable assumption to make? I could have missed some use
> cases for the function.
The calls look like this:
{vmx,svm}_do_resume is the schedule_tail function pointer, which is a
no-return function and called on the way out of a context switch.
They call hvm_do_resume() followed by a reset_stack_and_jump() to
{vmx,svm}_asm_do_vmentry.
So yes - you can be guaranteed that the v in hvm_do_resume() is current.
If you do come to explicitly rely on this behaviour, and it is in any
way unclear, it might be worth introducing an ASSERT(v == current) near
to the expectation.
~Andrew
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Is it safe to assume that v == current in hvm_do_resume()?
2014-10-22 9:04 ` Andrew Cooper
@ 2014-10-22 9:10 ` Razvan Cojocaru
0 siblings, 0 replies; 3+ messages in thread
From: Razvan Cojocaru @ 2014-10-22 9:10 UTC (permalink / raw)
To: Andrew Cooper, xen-devel@lists.xen.org
On 10/22/2014 12:04 PM, Andrew Cooper wrote:
> On 22/10/14 09:11, Razvan Cojocaru wrote:
>> Hello,
>>
>> As far as I've understood the code, and based on several tests, it would
>> appear that in xen/arch/x86/hvm/hvm.c, the struct vcpu *v parameter to
>> hvm_do_resume() is always equal to current.
>>
>> Is that a reasonable assumption to make? I could have missed some use
>> cases for the function.
>
> The calls look like this:
>
> {vmx,svm}_do_resume is the schedule_tail function pointer, which is a
> no-return function and called on the way out of a context switch.
>
> They call hvm_do_resume() followed by a reset_stack_and_jump() to
> {vmx,svm}_asm_do_vmentry.
>
> So yes - you can be guaranteed that the v in hvm_do_resume() is current.
>
> If you do come to explicitly rely on this behaviour, and it is in any
> way unclear, it might be worth introducing an ASSERT(v == current) near
> to the expectation.
Thanks for the confirmation!
Indeed, I had placed an ASSERT() before the code that needs v == current.
Thanks,
Razvan
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-10-22 9:10 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-10-22 8:11 Is it safe to assume that v == current in hvm_do_resume()? Razvan Cojocaru
2014-10-22 9:04 ` Andrew Cooper
2014-10-22 9:10 ` Razvan Cojocaru
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.