* [PATCH for 4.6] x86/hvm.c: fix regression in guest destruction
@ 2015-07-29 16:39 Ravi Sahita
2015-07-29 16:44 ` Andrew Cooper
0 siblings, 1 reply; 9+ messages in thread
From: Ravi Sahita @ 2015-07-29 16:39 UTC (permalink / raw)
To: xen-devel
Cc: Ravi Sahita, wei.liu2, george.dunlap, andrew.cooper3, tim,
edmund.h.white, JBeulich
As reported by Wei Lu on July 27 2015
Signed-off-by: Ravi Sahita <ravi.sahita@intel.com>
---
xen/arch/x86/hvm/hvm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index ec1d797..6a56216 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2463,7 +2463,9 @@ void hvm_vcpu_destroy(struct vcpu *v)
{
hvm_all_ioreq_servers_remove_vcpu(v->domain, v);
- altp2m_vcpu_destroy(v);
+ if ( hvm_altp2m_supported() )
+ altp2m_vcpu_destroy(v);
+
nestedhvm_vcpu_destroy(v);
free_compat_arg_xlat(v);
--
1.9.1
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH for 4.6] x86/hvm.c: fix regression in guest destruction
2015-07-29 16:39 [PATCH for 4.6] x86/hvm.c: fix regression in guest destruction Ravi Sahita
@ 2015-07-29 16:44 ` Andrew Cooper
2015-07-29 16:51 ` Wei Liu
2015-07-30 9:21 ` Ian Campbell
0 siblings, 2 replies; 9+ messages in thread
From: Andrew Cooper @ 2015-07-29 16:44 UTC (permalink / raw)
To: Ravi Sahita, xen-devel
Cc: george.dunlap, tim, wei.liu2, edmund.h.white, JBeulich
On 29/07/15 17:39, Ravi Sahita wrote:
> As reported by Wei Lu on July 27 2015
Reported-by: Wei Liu <wei.liu2@citrix.com>
> Signed-off-by: Ravi Sahita <ravi.sahita@intel.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> xen/arch/x86/hvm/hvm.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index ec1d797..6a56216 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2463,7 +2463,9 @@ void hvm_vcpu_destroy(struct vcpu *v)
> {
> hvm_all_ioreq_servers_remove_vcpu(v->domain, v);
>
> - altp2m_vcpu_destroy(v);
> + if ( hvm_altp2m_supported() )
> + altp2m_vcpu_destroy(v);
> +
> nestedhvm_vcpu_destroy(v);
>
> free_compat_arg_xlat(v);
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH for 4.6] x86/hvm.c: fix regression in guest destruction
2015-07-29 16:44 ` Andrew Cooper
@ 2015-07-29 16:51 ` Wei Liu
2015-07-30 9:21 ` Ian Campbell
1 sibling, 0 replies; 9+ messages in thread
From: Wei Liu @ 2015-07-29 16:51 UTC (permalink / raw)
To: Andrew Cooper
Cc: Ravi Sahita, wei.liu2, george.dunlap, tim, edmund.h.white,
JBeulich, xen-devel
On Wed, Jul 29, 2015 at 05:44:38PM +0100, Andrew Cooper wrote:
> On 29/07/15 17:39, Ravi Sahita wrote:
> > As reported by Wei Lu on July 27 2015
>
> Reported-by: Wei Liu <wei.liu2@citrix.com>
>
> > Signed-off-by: Ravi Sahita <ravi.sahita@intel.com>
>
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
>
Tested-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> > xen/arch/x86/hvm/hvm.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> > index ec1d797..6a56216 100644
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -2463,7 +2463,9 @@ void hvm_vcpu_destroy(struct vcpu *v)
> > {
> > hvm_all_ioreq_servers_remove_vcpu(v->domain, v);
> >
> > - altp2m_vcpu_destroy(v);
> > + if ( hvm_altp2m_supported() )
> > + altp2m_vcpu_destroy(v);
> > +
> > nestedhvm_vcpu_destroy(v);
> >
> > free_compat_arg_xlat(v);
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH for 4.6] x86/hvm.c: fix regression in guest destruction
2015-07-29 16:44 ` Andrew Cooper
2015-07-29 16:51 ` Wei Liu
@ 2015-07-30 9:21 ` Ian Campbell
2015-07-30 9:32 ` Ian Campbell
1 sibling, 1 reply; 9+ messages in thread
From: Ian Campbell @ 2015-07-30 9:21 UTC (permalink / raw)
To: Andrew Cooper, Ravi Sahita, xen-devel
Cc: george.dunlap, wei.liu2, tim, edmund.h.white, JBeulich
On Wed, 2015-07-29 at 17:44 +0100, Andrew Cooper wrote:
> On 29/07/15 17:39, Ravi Sahita wrote:
> > As reported by Wei Lu on July 27 2015
>
> Reported-by: Wei Liu <wei.liu2@citrix.com>
Which leaves an effectively empty commit message:
x86/hvm.c: fix regression in guest destruction
Reported-by: Wei Liu < wei.liu2@citrix.com >
Signed-off-by: Ravi Sahita < ravi.sahita@intel.com >
Reviewed-by: Andrew Cooper < andrew.cooper3@citrix.com >
Tested-by: Wei Liu < wei.liu2@citrix.com >
If I were maintainer of this code I'd be very grumpy about the lack of a
commit log (What regression? What is the fix? Why is it correct?) for this
patch. I asked on IRC and Andy suggested instead:
x86/hvm.c: Don't tear down altp2m state if it was never set up
which I have applied with. I still don't think the commit message is very
satisfactory, but I'm not maintainer of any of this code so meh.
Ian.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH for 4.6] x86/hvm.c: fix regression in guest destruction
2015-07-30 9:21 ` Ian Campbell
@ 2015-07-30 9:32 ` Ian Campbell
2015-07-30 9:38 ` George Dunlap
2015-07-30 9:55 ` Andrew Cooper
0 siblings, 2 replies; 9+ messages in thread
From: Ian Campbell @ 2015-07-30 9:32 UTC (permalink / raw)
To: Andrew Cooper, Ravi Sahita, xen-devel
Cc: george.dunlap, tim, wei.liu2, edmund.h.white, JBeulich
On Thu, 2015-07-30 at 10:21 +0100, Ian Campbell wrote:
> which I have applied with. I still don't think the commit message is very
> satisfactory, but I'm not maintainer of any of this code so meh.
For the benefit of the archives perhaps someone could explain why gating a
per-vcpu teardown on a host level feature setting is correct?
In particular what ensures that altp2m_vcpu_initialise has been called,
given that this is only called from HVMOP_altp2m_set_domain_state. What
happens if that HVMOP is never touched?
Do things work both for altp2m disabled on the Xen command line and
disabled/enabled in the guest config? If so how?
Also how come HVMOP_altp2m_set_domain_state does not have a
hvm_altp2m_supported check?
Ian.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH for 4.6] x86/hvm.c: fix regression in guest destruction
2015-07-30 9:32 ` Ian Campbell
@ 2015-07-30 9:38 ` George Dunlap
2015-07-30 9:50 ` Ian Campbell
2015-07-30 9:55 ` Andrew Cooper
1 sibling, 1 reply; 9+ messages in thread
From: George Dunlap @ 2015-07-30 9:38 UTC (permalink / raw)
To: Ian Campbell, Andrew Cooper, Ravi Sahita, xen-devel
Cc: george.dunlap, tim, wei.liu2, edmund.h.white, JBeulich
On 07/30/2015 10:32 AM, Ian Campbell wrote:
> On Thu, 2015-07-30 at 10:21 +0100, Ian Campbell wrote:
>
>> which I have applied with. I still don't think the commit message is very
>> satisfactory, but I'm not maintainer of any of this code so meh.
>
> For the benefit of the archives perhaps someone could explain why gating a
> per-vcpu teardown on a host level feature setting is correct?
>
> In particular what ensures that altp2m_vcpu_initialise has been called,
> given that this is only called from HVMOP_altp2m_set_domain_state. What
> happens if that HVMOP is never touched?
>
> Do things work both for altp2m disabled on the Xen command line and
> disabled/enabled in the guest config? If so how?
>
> Also how come HVMOP_altp2m_set_domain_state does not have a
> hvm_altp2m_supported check?
So this was all acked & stuff before I had much of a chance to comment
on it, but on my to-do list for 4.7 is to rework a lot of the
initialization / teardown stuff. In particular:
- Always and only check for whether something has been initialized
(e.g., non-NULL, non-INVALID_MFN) before tearing it down
- Do *all* of the initialization for both altp2m and nestedhvm when
they're actually enabled for the domain, rather than doing a bunch of
the initialization unconditionally up front.
This is all part of the "technical debt" we were talking about when we
considered giving it a freeze exception.
-George
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH for 4.6] x86/hvm.c: fix regression in guest destruction
2015-07-30 9:38 ` George Dunlap
@ 2015-07-30 9:50 ` Ian Campbell
0 siblings, 0 replies; 9+ messages in thread
From: Ian Campbell @ 2015-07-30 9:50 UTC (permalink / raw)
To: George Dunlap, Andrew Cooper, Ravi Sahita, xen-devel
Cc: george.dunlap, tim, wei.liu2, edmund.h.white, JBeulich
On Thu, 2015-07-30 at 10:38 +0100, George Dunlap wrote:
> On 07/30/2015 10:32 AM, Ian Campbell wrote:
> > On Thu, 2015-07-30 at 10:21 +0100, Ian Campbell wrote:
> >
> > > which I have applied with. I still don't think the commit message is
> > > very
> > > satisfactory, but I'm not maintainer of any of this code so meh.
> >
> > For the benefit of the archives perhaps someone could explain why
> > gating a
> > per-vcpu teardown on a host level feature setting is correct?
> >
> > In particular what ensures that altp2m_vcpu_initialise has been called,
> > given that this is only called from HVMOP_altp2m_set_domain_state. What
> > happens if that HVMOP is never touched?
> >
> > Do things work both for altp2m disabled on the Xen command line and
> > disabled/enabled in the guest config? If so how?
> >
> > Also how come HVMOP_altp2m_set_domain_state does not have a
> > hvm_altp2m_supported check?
>
> So this was all acked & stuff before I had much of a chance to comment
> on it, but on my to-do list for 4.7 is to rework a lot of the
> initialization / teardown stuff. In particular:
>
> - Always and only check for whether something has been initialized
> (e.g., non-NULL, non-INVALID_MFN) before tearing it down
>
> - Do *all* of the initialization for both altp2m and nestedhvm when
> they're actually enabled for the domain, rather than doing a bunch of
> the initialization unconditionally up front.
>
> This is all part of the "technical debt" we were talking about when we
> considered giving it a freeze exception.
Thanks, I'm inferring that everything I asked about in the second from last
paragraph is somehow fine, just confusingly achieved in the current code...
I'm done grumping now...
Ian.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH for 4.6] x86/hvm.c: fix regression in guest destruction
2015-07-30 9:32 ` Ian Campbell
2015-07-30 9:38 ` George Dunlap
@ 2015-07-30 9:55 ` Andrew Cooper
2015-07-30 10:08 ` Ian Campbell
1 sibling, 1 reply; 9+ messages in thread
From: Andrew Cooper @ 2015-07-30 9:55 UTC (permalink / raw)
To: Ian Campbell, Ravi Sahita, xen-devel
Cc: george.dunlap, tim, wei.liu2, edmund.h.white, JBeulich
On 30/07/15 10:32, Ian Campbell wrote:
> Also how come HVMOP_altp2m_set_domain_state does not have a
> hvm_altp2m_supported check?
(For the benefit of not leaving this question unanswered)
There is an early exit at the top of do_altp2m_op(), ahead of even
reading the hypercall body from the guest.
~Andrew
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH for 4.6] x86/hvm.c: fix regression in guest destruction
2015-07-30 9:55 ` Andrew Cooper
@ 2015-07-30 10:08 ` Ian Campbell
0 siblings, 0 replies; 9+ messages in thread
From: Ian Campbell @ 2015-07-30 10:08 UTC (permalink / raw)
To: Andrew Cooper, Ravi Sahita, xen-devel
Cc: george.dunlap, tim, wei.liu2, edmund.h.white, JBeulich
On Thu, 2015-07-30 at 10:55 +0100, Andrew Cooper wrote:
> On 30/07/15 10:32, Ian Campbell wrote:
> > Also how come HVMOP_altp2m_set_domain_state does not have a
> > hvm_altp2m_supported check?
>
> (For the benefit of not leaving this question unanswered)
>
> There is an early exit at the top of do_altp2m_op(), ahead of even
> reading the hypercall body from the guest.
Thanks.
Ian.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-07-30 10:09 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-07-29 16:39 [PATCH for 4.6] x86/hvm.c: fix regression in guest destruction Ravi Sahita
2015-07-29 16:44 ` Andrew Cooper
2015-07-29 16:51 ` Wei Liu
2015-07-30 9:21 ` Ian Campbell
2015-07-30 9:32 ` Ian Campbell
2015-07-30 9:38 ` George Dunlap
2015-07-30 9:50 ` Ian Campbell
2015-07-30 9:55 ` Andrew Cooper
2015-07-30 10:08 ` Ian Campbell
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.