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

Re: [PATCH 1/2][4.15?] x86/shadow: suppress "fast fault path" optimization when running virtualized


  • To: Jan Beulich <jbeulich@xxxxxxxx>, Tim Deegan <tim@xxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Mon, 8 Mar 2021 13:59:50 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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-SenderADCheck; bh=2QFGUf0NpAEB3q315oWeky3tTb0uY9yxwUgU4ec7utY=; b=KGuyGsQICWM7NoTf5T7RIrGbG685IphSwc2VxEQfml/HY73brTEuhuxN7tXZcGU+LtDGCZnkRXZL8hpzFK2/CmMAVrVkEod9a//nU9haSFW9JwyvjHYYCKo6DPEQZ9JPYzMBcIxSLxDbG2ilP2cQEwTYFXPZgOvqVUWDphFuHaN+mMTWoRGBrKgKJouIO3w307HdXtN+ner0WOPUY8ax8tLN8utNddbFRiWlQal7QTQle5DdnE0MPipoJ+uO4ejsYJgXC8MttkfWJAMtKuRcGAX6IWlKMZ86TsSHVVNfyk4NQKWtiAVKvnESGgSG+0SFiv4Rvepk1EiQx5DPoubeOA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dDKxjfpjwMoKs29JOOatnt9Kvzgb5NX4tyT0kaOzhOrpoIwWOHXMb91aNjPGgjvLkuXwnFxNNnh5/rcWTDVhWvjMk7votHyGre6O2dwIO02nXdbe42K40Vu79/3acrhGW+aO7YD6tBA5mzknGCpU7JCwtyVxBWdZL0TBmCbcjkz7qId4nogLK51mjydhPRg4p+Dfa4l0IzxcWjQWtxeNncYkvmdEsD2lxeL2YJ3F9MOTyiIb47WhWihX9LGNz65lnTxsxrAA6L0mx/FuFbnnyhLdDRsvfkoTrKN17FWRMtyGJZAOJnwKCfKw5g7cY+wi2zUMkQlBtoAyv8I7SO3Nvw==
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "George Dunlap" <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>
  • Delivery-date: Mon, 08 Mar 2021 14:00:12 +0000
  • Ironport-sdr: v1rgk1PRTuGbetZpADjWPOsR3NiEVkDPUiMbeLw9jOEY/oNCtQ57jV/iJzUvOGHjt5Vn9bBT/F CDpHZCTaAytcki2wdNY1DOuxqJg39F4GhsY0l5cYz6I9OMtW7vHB8/pMcxKFNnicwfexHwMluN GGHRV680Dubto8WrvvTiOn3P4FS37UrIA8Z55pI83J82axNFawDcpOOYKQDIx18JSI6Cb90aQ7 HPgCigU7FXffgF2zx78901XWHERwXnywrH+U47EBL8In2J16YNsZ+R+TVjHHC9lr0F2lrNZc9a 44s=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 08/03/2021 13:51, Jan Beulich wrote:
> On 08.03.2021 14:47, Andrew Cooper wrote:
>> On 08/03/2021 09:25, Tim Deegan wrote:
>>> At 16:37 +0100 on 05 Mar (1614962224), Jan Beulich wrote:
>>>> We can't make correctness of our own behavior dependent upon a
>>>> hypervisor underneath us correctly telling us the true physical address
>>>> with hardware uses. Without knowing this, we can't be certain reserved
>>>> bit faults can actually be observed. Therefore, besides evaluating the
>>>> number of address bits when deciding whether to use the optimization,
>>>> also check whether we're running virtualized ourselves.
>>>>
>>>> Requested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>> Acked-by: Tim Deegan <tim@xxxxxxx>
>>>
>>> I would consider this to be a bug in the underlying hypervisor, but I
>>> agree than in practice it won't be safe to rely on it being correct.
>> I'd argue against this being a hypervisor bug.  If anything, it is a
>> weakness in how x86 virtualisation works.
>>
>> For booting on a single host, then yes - vMAXPHYSADDR really ought to be
>> the same as MAXPHYSADDR, and is what happens in the common case.
>>
>> For booting in a heterogeneous pool, the only safe value is the min of
>> MAXPHYSADDR across the resource pool.  Anything higher, and the VM will
>> malfunction (get #PF[rsvd] for apparently-legal PTEs) on the smallest
>> pool member(s).
> Except that min isn't safe either - the guest may then expect reserved
> bit faults where none surface.

Such a guest is buggy, and in clear violation of the rules set out in
the architecture.  All reserved behaviour is subject to change in the
future.

Any software (Xen included) deliberately choosing to depend on the
specifics of reserved behaviour, get to keep all resulting pieces.

~Andrew




 


Rackspace

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