[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] x86/PoD: defer nested P2M flushes


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 19 Oct 2021 17:06:27 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Z8ke/QX7gNdmFCNySK5F3vO3xAjkZDmo+WEJy30JzYQ=; b=YO2PGdFs/w3IMj92+B493zz3dHTABbfC0Q0or9bv2N34/N6D6/PSj2G/AextrZf+ac4OedqEOvTb30HwvmCTuI9SkjmVfk2S9Y4CCEgkiZftWHW+q2UU6eF+QJu2xrF8XinJkUiUCYH1ENh6VR1rGYakQBVrE0IzQx/Vmmw98Hrf9V/Bhl9ESvbkXmeaGgah/173XEPu2GNnNaE0DY4LdsbIDYWbjN+EeAt7Fr6wQYaykc7V3mKf/aWq1tjFDbZOYFzbt19AdFUkpBe1z9/TX3zT32rYsOxUfQi7/1V+i1rUfkn7W6xBZVDU0/VixgaVR6OHo7safMtyS0DC6a9/kQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ofXZC/ApXws3hlT+TTYOLRWKwDeYR9urJexLKSZtArOG3mYspNiTc54xfx7getwzV3RlOtVmZyhCODVZXLn/15TIyOO/vtstzFwP74qCHzzk2yU4OO/KD73aS6QoICUTFJeCsv2fqeoLdut8x0WwT6qTCFPa1haUFNw2g4q1kGuaXQ/3zBGhhDVLGdlH52bUX2WYhCmEK6aBTNzFCh355/MGJ1SZnpOr9qW8Wlr5/aD7iI1FPmibBg7e9L9YaDwfeWchqcVj0duM7hcQACklqnGT+0PVyyOjt+p02StDm87clcbRYikVUJ00koJh2vxi3mlwkwyu8lOZnckXocnuCQ==
  • Authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>
  • Delivery-date: Tue, 19 Oct 2021 15:06:48 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 19.10.2021 15:53, Roger Pau Monné wrote:
> On Tue, Oct 19, 2021 at 02:52:27PM +0200, Jan Beulich wrote:
>> With NPT or shadow in use, the p2m_set_entry() -> p2m_pt_set_entry() ->
>> write_p2m_entry() -> p2m_flush_nestedp2m() call sequence triggers a lock
>> order violation when the PoD lock is held around it. Hence such flushing
>> needs to be deferred. Steal the approach from p2m_change_type_range().
>> (Note that strictly speaking the change at the out_of_memory label is
>> not needed, as the domain gets crashed there anyway. The change is being
>> made nevertheless to avoid setting up a trap from someone meaning to
>> deal with that case better than by domain_crash().)
>>
>> Similarly for EPT I think ept_set_entry() -> ept_sync_domain() ->
>> ept_sync_domain_prepare() -> p2m_flush_nestedp2m() is affected. Make its
>> p2m_flush_nestedp2m() invocation conditional. Note that this then also
>> alters behavior of p2m_change_type_range() on EPT, deferring the nested
>> flushes there as well. I think this should have been that way from the
>> introduction of the flag.
>>
>> Reported-by: Elliott Mitchell <ehem+xen@xxxxxxx>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

Thanks.

>> --- a/xen/arch/x86/mm/p2m-ept.c
>> +++ b/xen/arch/x86/mm/p2m-ept.c
>> @@ -1253,7 +1253,7 @@ static void ept_sync_domain_prepare(stru
>>      {
>>          if ( p2m_is_nestedp2m(p2m) )
>>              ept = &p2m_get_hostp2m(d)->ept;
>> -        else
>> +        else if ( !p2m->defer_nested_flush )
>>              p2m_flush_nestedp2m(d);
> 
> I find this model slightly concerning, as we don't actually notify the
> caller that a nested flush as been deferred, so we must make sure that
> whoever sets defer_nested_flush also performs a flush unconditionally
> when clearing the flag.

Well, this _is_ the model used for now. Until this change there was
just a single party setting the flag. And like here, any new party
setting the flag will also need to invoke a flush upon clearing it.
It's not clear to me what alternative model you may have in mind.

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.