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

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


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 19 Oct 2021 15:14:25 +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=Kd3PzkoGE/6GBdKf/jroNS9Vl2nsZIfpfqb68T2MbZU=; b=HVBmlCpRPOkK4IST0xa6XT2M8IOAnaq8b5GIa1txzKfr6neMoy9sfLYKPLKa8RjBSLQLuuzEk1kpYnxm3cSVmSbd4U2Jmqckj8DiTMvG1A9u+QRcyJqVVRixWri+hDx3GumK1DbXfEUfT0Qqyiq7cSCOpihmSHLFgJE+OBjki2ocDDzZLp8AnRWJCbi9Du000vcn0gUOTsGITBe+qJ+7kPBw/Pqb4ODRPKWsfxcoRZYkapS6YD6KjcfJdaTjTyINhQtpaxCu/0v+XL8DhdFOfGpUqyo91YdXUMqhPF8Up55MPfXK1WQj0wj9GbgviuK/fGmRcagoroRg4s9DzmUadQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=esrU5CZGZC52Go8ArxKlsCCPLgRiojb97vdzCYTL/X3wm+I3fCpJgMIKXjZA5lIzQbJiT5S5aCEeeFKatc2ol/Cp/yu+4H6Q9chmaywIL4zFQ9IUpP97bBsiS+2qRZIdwvZUS5PSDgUR9ks3GwYwP5uuHzyyrUxwkwBQKbX7+LiNzI6HBFu3xaLb0GpllfqQ5G0kv6/vnH+fQTfgUqaqYxE6vbVHR2qRXA39/oNcEwPL9J0wAPjBoT1/rZ2fmeZ1sru02ttD6ko6NnWMmbkg4oE2b7PFxnCm0BWlyqHBvhkXdKCVOdF/NrofODKrsJqVTtGXui6Dr7hDhc0/KBXssw==
  • Authentication-results: citrix.com; dkim=none (message not signed) header.d=none;citrix.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>
  • Delivery-date: Tue, 19 Oct 2021 13:14:34 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 19.10.2021 14:59, Roger Pau Monné wrote:
> On Tue, Oct 19, 2021 at 01:58:38PM +0200, Jan Beulich wrote:
>> On 19.10.2021 12:41, Roger Pau Monné wrote:
>>> On Mon, Oct 11, 2021 at 10:17:08AM +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().
>>>>
>>>> Similarly for EPT I think ept_set_entry() -> ept_sync_domain() ->
>>>> ept_sync_domain_prepare() -> p2m_flush_nestedp2m() is affected.
>>>
>>> I'm slightly worried by this path because it doesn't seem to
>>> acknowledge defer_nested_flush.
>>
>> Oh, yes. Iirc I did look at that logic, write down the remark, and
>> then forgot to add the conditional to ept_sync_domain_prepare().
>> The interactions with the real (host) flush are kind of ugly there,
>> though - we then further depend on the ->defer_flush / ->need_flush
>> logic, which is EPT-only. But I think I've convinced myself that
>> this ought to work out.
>>
>>> Maybe the flag should be checked by
>>> p2m_flush_nestedp2m instead of leaving it to the callers?
>>
>> I'm not sure this would be a good idea, as there are more callers.
> 
> We should maybe add an ASSERT to p2m_flush_nestedp2m to make sure it's
> not called with defer_nested_flush being set then, or else it's
> possible for new callers of p2m_flush_nestedp2m to forget checking
> defer_nested_flush.

I'm afraid we can't do that, or at least not this easily: The flag
assumes the p2m lock to be held when it gets set. Hence callers not
holding the lock (hvm_set_efer(), nvmx_handle_invept()) may trigger
such an assert just because another CPU set the flag.

Jan




 


Rackspace

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