Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sun, 18 Aug 2019 18:32:29 +0200 (CEST)
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Andrew Cooper <andrew.cooper3@citrix.com>
cc:     Borislav Petkov <bp@alien8.de>,
        "Lendacky, Thomas" <Thomas.Lendacky@amd.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
        "x86@kernel.org" <x86@kernel.org>, Ingo Molnar <mingo@redhat.com>,
        "Rafael J . Wysocki" <rjw@rjwysocki.net>,
        Pavel Machek <pavel@ucw.cz>, Chen Yu <yu.c.chen@intel.com>,
        Jonathan Corbet <corbet@lwn.net>
Subject: Re: [PATCH] x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family
 15h/16h
In-Reply-To: <919c80f1-53a5-44d2-d785-88890e449b38@citrix.com>
Message-ID: <alpine.DEB.2.21.1908181831340.1923@nanos.tec.linutronix.de>
References: <776cb5c2d33e7fd0d2893904724c0e52b394f24a.1565817448.git.thomas.lendacky@amd.com> <a24a2c7d-cfab-a049-37e8-7260a9063a7c@citrix.com> <20190815210547.GL15313@zn.tnic> <312b307b-19cc-84f8-97e6-07dbdf07dd12@citrix.com> <20190817084410.GA15364@zn.tnic>
 <919c80f1-53a5-44d2-d785-88890e449b38@citrix.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sat, 17 Aug 2019, Andrew Cooper wrote:
> On 17/08/2019 09:44, Borislav Petkov wrote:
> > On Thu, Aug 15, 2019 at 10:25:24PM +0100, Andrew Cooper wrote:
> >> I'm afraid that a number of hypervisors do write-discard, given the
> >> propensity of OSes (certainly traditionally) to go poking at bits like
> >> this without wrmsr_safe().
> >>
> >> You either need to read the MSR back and observe that the bit has really
> >> changed, or in this case as Thomas suggests, look at CPUID again (which
> >> will likely be the faster option for the non-virtualised case).
> > One thing I didn't think of when we talked about this: this happens only
> > after you resume the hypervisor.
> 
> :) It hadn't escaped my notice, hence the intervention on this thread.
> 
> > And the words "resume the hypervisor" already means an improbable use case.
> 
> Qubes and OpenXT are two laptop+hypervisor oriented distros where
> suspend/resume is a big deal, and these will have to follow AMD's
> recommendation here.
> 
> However, for servers which don't do S3/S4, we can reason about safely
> leaving RDRAND enabled, irrespective of guest configuration.

Let the administrator reason about it. Default is off for sanity sake.

Thanks,

	tglx