All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ravi Sahita <ravi.sahita@intel.com>,
	xen-devel@lists.xenproject.org
Cc: george.dunlap@eu.citrix.com, tim@xen.org, wei.liu2@citrix.com,
	edmund.h.white@intel.com, JBeulich@suse.com
Subject: Re: [PATCH for 4.6] x86/hvm.c: fix regression in guest destruction
Date: Thu, 30 Jul 2015 10:38:56 +0100	[thread overview]
Message-ID: <55B9F0B0.1020209@citrix.com> (raw)
In-Reply-To: <1438248776.11600.270.camel@citrix.com>

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

  reply	other threads:[~2015-07-30  9:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2015-07-30  9:50         ` Ian Campbell
2015-07-30  9:55       ` Andrew Cooper
2015-07-30 10:08         ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55B9F0B0.1020209@citrix.com \
    --to=george.dunlap@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=edmund.h.white@intel.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=ravi.sahita@intel.com \
    --cc=tim@xen.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.