From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 09 Aug 2018 10:47:27 -0000 Received: from smtp.eu.citrix.com ([185.25.65.24]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fniTV-0004Wt-Vs for speck@linutronix.de; Thu, 09 Aug 2018 12:47:26 +0200 Subject: [MODERATED] Re: [PATCH] SPTE masking References: <5d154d5b-182e-c1db-8c18-64b140dce133@redhat.com> From: Andrew Cooper Message-ID: Date: Thu, 9 Aug 2018 11:47:18 +0100 MIME-Version: 1.0 In-Reply-To: <5d154d5b-182e-c1db-8c18-64b140dce133@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-GB To: speck@linutronix.de List-ID: Content-Transfer-Encoding: 8bit On 09/08/18 11:01, speck for Paolo Bonzini wrote: > On 09/08/2018 11:33, speck for Andrew Cooper wrote: >>> in kvm_set_mmio_spte_mask should do, or alternatively the nicer patch after >>> my signature (untested and unthought). >> Setting bit 51 doesn't mitigate L1TF on any current processor. >> >> You need to set an address bit inside L1D-maxphysaddr, and isn't >> cacheable on the current system. > KVM currently sets all reserved bits, so it's safe as long as > l1d-maxphyaddr > cpuid-maxphyaddr. > > What remains is pre-Nehalem or high-end servers where L1D-maxphyaddr = > cpuid-maxphyaddr. So we could split the guest gfn in two so that > > bit 47-51 = bits MPA-5..MPA-1 of guest physical address > bit maxphyaddr-5..46 = all ones, or look it up using e820 > bit 12..maxphyaddr-6 = bits 12..MPA-6 of guest physical address. > > assuming all processors with maxphyaddr > 46 are safe. The equivalent path in Xen sets all the upper 32 bits, which makes this trick safe on any system which doesn't have cacheable mappings within the top 4G of system.  I've got some fixes pending for posting once I'm done with the more urgent L1TF bits. > >> and the CPUID maxphysaddr hasn't been >> levelled for heterogeneous migration safety > I don't know about Xen PV, but when using EPT you cannot do that, the > maxphyaddr is not virtualizable (obviously not to guest-maxphyaddr > > host-maxphyaddr, but guest-maxphyaddr < host-maxphyaddr cannot be > emulated either). There is nothing wrong with telling a guest it has maxphysaddr smaller than the real maxphysaddr.  Just like CPUID feature levelling, it says "don't go playing there". No software is permitted to rely on the behaviour of reserved bits. ~Andrew