From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.88, mailfrom: jordan.l.justen@intel.com) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by groups.io with SMTP; Thu, 22 Aug 2019 13:44:25 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Aug 2019 13:44:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,418,1559545200"; d="scan'208";a="379472348" Received: from smmullen-mobl.amr.corp.intel.com (HELO localhost) ([10.251.1.161]) by fmsmga006.fm.intel.com with ESMTP; 22 Aug 2019 13:44:24 -0700 MIME-Version: 1.0 In-Reply-To: <9659350e-fb81-fa3a-d86a-5a76d73c3ce1@redhat.com> References: <6a37c84f4989304b21205d6263c6491f81da3233.1566250534.git.thomas.lendacky@amd.com> <6d3442d5-46ab-2b99-6100-0e5c56477735@redhat.com> <156642425970.26211.8321620974236559246@jljusten-skl> <9659350e-fb81-fa3a-d86a-5a76d73c3ce1@redhat.com> From: "Jordan Justen" To: Laszlo Ersek , devel@edk2.groups.io, thomas.lendacky@amd.com Subject: Re: [edk2-devel] [RFC PATCH 01/28] OvmfPkg/Sec: Enable cache early to speed up booting Cc: Ard Biesheuvel , Michael D Kinney , Liming Gao , Eric Dong , Ray Ni , "Singh, Brijesh" , "Fang, Peter" , D Scott Phillips Message-ID: <156650666283.13750.10666423055754200944@jljusten-skl> User-Agent: alot/0.8 Date: Thu, 22 Aug 2019 13:44:23 -0700 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2019-08-22 06:46:07, Laszlo Ersek wrote: > On 08/21/19 23:51, Jordan Justen wrote: > > On 2019-08-21 07:21:25, Laszlo Ersek wrote: > >> On 08/19/19 23:35, Lendacky, Thomas wrote: > >>> From: Tom Lendacky > >>> > >>> + // > >>> + // Enable caching > >>> + // > >>> + AsmEnableCache (); > >>> + > >>> DEBUG ((EFI_D_INFO, > >>> "SecCoreStartupWithStack(0x%x, 0x%x)\n", > >>> (UINT32)(UINTN)BootFv, > >>> > >> > >> This makes me uncomfortable. There used to be problems related to > >> caching when VFIO device assignment were used. My concern is admittedly > >> vague, but this is a very brittle area of OVMF-on-KVM. If you asked me > >> "well what could break here", I'd answer "you never know, and the burd= en > >> of proof is not on me". :) Can we make this change conditional on SEV-= ES? > >=20 > > This was also raised as an issue by Peter for the ACRN hypervisor and > > Scott for the bhyve hypervisor. > >=20 > > I think it is rare for a platform to enable cache at this early of a > > stage, but it is also rare to decompress a firmware volume at this > > point. > >=20 > > It appears that it could be helpful to figure out how to safely enable > > cache by default here, since it does seem to be impacting several > > hypervisors. >=20 > I can't think of anything better than "trial and error". Maybe we could try to detect kvm, and enable caching if !kvm. Maybe we could enable it during the decompress of the PEI FV and disable it afterward? > The issues that > used to pop up in the past, due to host kernel (KVM) changes, > particularly in connection with VFIO device assignment, have been > completely obscure and unpenetrable to me. Don't we eventually enable caching during the boot, so how is VFIO not affected by that? > Even though I've contributed > at least one KVM patch to mitigate those problems, they remain a mistery > to me, and I remain unable to *reason* about the problems or the fixes. If VFIO requires uncached access, then what mechanisms does kvm support for accessing memory ranges uncached? I thought kvm simply ignored the cache setting and always enabled caching, because this section of boot is not particularly slow with kvm. But, if enabling caching causes issues, then I guess it does something. Does kvm support mtrr to uncache i/o ranges? I didn't think kvm supported mtrrs in the past. I hope we wouldn't have to use paging to disable caching for the affected regions. -Jordan > So I think we could only flip the behavior (enable cache by default) and > collect bug reports. But that's extremely annoying for end-users, and I > see "no regressions" as one of my top responsibilities. >=20 > Even if we provided an fw_cfg knob to disable the change, using > QemuFwCfgSecLib, similarly to commit ab081a50e565 ("OvmfPkg: > PlatformPei: take no-exec DXE settings from the QEMU command line", > 2015-09-15), such fw_cfg knobs are difficult to use through layered > products, such as libvirt, proxmox, etc. And of course fw_cfg is only > available on QEMU. >=20 > Laszlo