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

Re: [PATCH RFC v2 3/3] x86/altp2m: p2m_altp2m_propagate_change() should honor present page order


  • To: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 5 Jan 2022 09:59:39 +0100
  • 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=f4uOLk1yA8ftDIHqA7szN7tOuXuu/j2/qWBba+c54n8=; b=RXh43SsxrIfCRdFoI7qxDf2WyHgxY7yaI/xE5m6XJdkO5OBRfqVw0DmHv7Q6h47Xv/CRTL7Qi/vLnmIHPG/QqsTfK4O6EoKJMjP9LZoV9AquDoEfW7wR40Q8hlh+7GpEVw22TVZltAJzOCywUntWmR5TJmFLyjVTQMudM2U2+pd5zg3Ea6nmSHhwnvMhByIZkhlmj0u4KbAb9hd787vyAyJlH1tTd0/VMbf3MleXhLGBjYUzpAxqY6tmPE1k4CmuvALXtBqXKPt5iVO7Sw5AdtyWht0rdh1NWaiAHoIUpCTtXd8B1NNcvimpjsWe2TbrfF4U57Jg1os3e2o53rWzoQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LNk7Wg5M6tHbUzJ3eBt4OUF/L9QNEuoxp61gZTlv92PKrE8WRSvIewTsk552TeyL8G3n/ylDR2qcKfdKmM2+BtzgUZ+CZeOPz6qwh0EOKz55aBzUds+AFOuKXZuj6JzeXlUDup8CaVIENlZlpUWlRG97VrCdcK1TksscEVLyzXYDIzJ0pSIpWaAjgVTT8Yt/N9Ykr5uXttQsbsWPSBX46UP0HWqM4vqlBlQCFOyjifjoLAXihTGA1lD2lnn/Q9tICCpnLF8XFgoZQ2E36YGoYh3RMSZqeaE5mPwyg5/oLVkThs/Deh+8N2pW42rW/75NMHDwkYaRAUKJYx6zt1/8+A==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx>, Petre Pircalabu <ppircalabu@xxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 05 Jan 2022 09:00:20 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 04.01.2022 18:48, Tamas K Lengyel wrote:
>> I may be entirely wrong and hence that part of the change may also be
>> wrong, but I'm having trouble seeing why the original
>> "!mfn_eq(m, INVALID_MFN)" wasn't "mfn_eq(m, INVALID_MFN)". Isn't the
>> goal there to pre-fill entries that were previously invalid, instead of
>> undoing prior intentional divergence from the host P2M? (I have
>> intentionally not reflected this aspect in the description yet; I can't
>> really write a description of this without understanding what's going on
>> in case the original code was correct.)
> 
> This function only gets called from p2m-ept when the hostp2m gets an
> update. In that case this check goes through all altp2m's to see if
> any of them has an entry for what just got changed in the host, and
> overwrites the altp2m with that from the host. If there is no entry in
> the altp2m it doesn't pre-populate. That should only happen if the
> altp2m actually needs it and runs into a pagefault. So it is correct
> as-is, albeit being a subtle (and undocumented) behavior of the
> hostp2m and its effect on the altp2m's. But that's why we never
> actually make any changes on the hostp2m, we always create an altp2m
> and apply changes (mem_access/remapping) there.

Thanks for the explanation. Effectively this means that the call to
get_gfn_type_access() can simply be get_gfn_query(). For the patch
this means that I shouldn't check its return value and also continue
to pass the new order rather than the minimum of the two (as was the
case before), as all we're after is the locking of the GFN. It would
be nice if you could confirm this before I submit a non-RFC v3.

What I still don't understand is why the function blindly replaces
any possible entry in the altp2m, i.e. any possible override
mapping, not even taking into account the original p2m_access_t.

Jan




 


Rackspace

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