All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Liang Li <liang.z.li@intel.com>, Tim Deegan <tim@xen.org>,
	Matt Leinhos <matt@starlab.io>,
	Tamas KLengyel <tamas.lengyel@zentific.com>,
	Yang Zhang <yang.z.zhang@intel.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen/p2m: Remove np2m-specific filter from generic p2m_flush_table
Date: Tue, 31 Jan 2017 13:58:19 +0000	[thread overview]
Message-ID: <7da63cb0-78e8-74a4-352e-c61e028c2a94@citrix.com> (raw)
In-Reply-To: <589078930200007800135547@prv-mh.provo.novell.com>

On 31/01/17 10:44, Jan Beulich wrote:
>>>> On 30.01.17 at 16:17, <george.dunlap@citrix.com> wrote:
>> Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of
>> nested p2m tables whenever the host p2m table changed.  Unfortunately
>> in the process, it added a filter to the generic p2m_flush_table()
>> function so that the p2m would only be flushed if it was being used as
>> a nested p2m.  This meant that the p2m was not being flushed at all
>> for altp2m callers.
>>
>> Instead do the nested p2m filtering in p2m_flush_nestedp2m().
>>
>> NB that this is not a security issue: The only time this codepath is
>> called is in cases where either nestedp2m or altp2m is enabled, and
>> neither of them are in security support.
>>
>> Reported-by: Matt Leinhos <matt@starlab.io>
>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
>> ---
>> I've smoke-tested this with nested virt and it seems to work fine.
>> Matt / Tamas, could you test this with altp2m and see if it fixes your
>> issue?
>>
>>
>> CC: Liang Li <liang.z.li@intel.com>
>> CC: Yang Zhang <yang.z.zhang@intel.com>
>> CC: Tim Deegan <tim@xen.org>
>> CC: Tamas K Lengyel <tamas.lengyel@zentific.com>
>> CC: Andrew Cooper <andrew.cooper3@citrix.com>
>> CC: Jan Beulich <jbeulich@suse.com>
>> CC: Matt Leinhos <matt@starlab.io>
>> ---
>>  xen/arch/x86/mm/p2m.c | 12 +++++-------
>>  1 file changed, 5 insertions(+), 7 deletions(-)
>>
>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>> index aa627d8..0849c6e 100644
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -2048,12 +2048,6 @@ p2m_flush_table(struct p2m_domain *p2m)
>>      ASSERT(page_list_empty(&p2m->pod.super));
>>      ASSERT(page_list_empty(&p2m->pod.single));
>>  
>> -    if ( p2m->np2m_base == P2M_BASE_EADDR )
>> -    {
>> -        p2m_unlock(p2m);
>> -        return;
>> -    }
>> -
>>      /* This is no longer a valid nested p2m for any address space */
>>      p2m->np2m_base = P2M_BASE_EADDR;
>>      
>> @@ -2088,7 +2082,11 @@ p2m_flush_nestedp2m(struct domain *d)
>>  {
>>      int i;
>>      for ( i = 0; i < MAX_NESTEDP2M; i++ )
>> -        p2m_flush_table(d->arch.nested_p2m[i]);
>> +    {
>> +        struct p2m_domain *p2m = d->arch.nested_p2m[i];
>> +        if ( p2m->np2m_base != P2M_BASE_EADDR )
>> +            p2m_flush_table(p2m);
>> +    }
>>  }
> 
> So the use of p2m_flush_table() in p2m_get_nestedp2m() is fine
> as is because the new np2m_base can't be P2M_BASE_EADDR (as
> a comment there says slightly indirectly). I think this may be worth
> clarifying in the commit message.
> 
> What about p2m_flush()'es use of p2m_flush_table() though?
> There in particular are uses from vvmx.c and hap.c, both of which
> suggest nested-virt context.

I think the "filter" is only an optimization: If it's not there you'll
just end up "clearing" an already clear table.  That's the way things
were before 71bb730.

We could add an nestedp2m-specific wrapper function do to the test
instead, and then have all nestedp2m-specific callers call it.  Might be
a worthwhile change.

 -George

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

  reply	other threads:[~2017-01-31 13:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-30 15:17 [PATCH] xen/p2m: Remove np2m-specific filter from generic p2m_flush_table George Dunlap
2017-01-30 17:07 ` Tamas K Lengyel
2017-01-30 19:06   ` Matt Leinhos
2017-01-31 10:24   ` George Dunlap
2017-01-31 18:32     ` Tamas K Lengyel
2017-01-31 10:44 ` Jan Beulich
2017-01-31 13:58   ` George Dunlap [this message]
2017-02-08 10:02   ` Tim Deegan
2017-02-08 16:36     ` George Dunlap

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=7da63cb0-78e8-74a4-352e-c61e028c2a94@citrix.com \
    --to=george.dunlap@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=liang.z.li@intel.com \
    --cc=matt@starlab.io \
    --cc=tamas.lengyel@zentific.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=yang.z.zhang@intel.com \
    /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.