[edk2-devel] [RFC PATCH 01/28] OvmfPkg/Sec: Enable cache early to speed up booting

[Laszlo Ersek]

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 <thomas.lendacky at amd.com>
>>>
>>> Currently, the OVMF code relies on the hypervisor to enable the cache
>>> support on the processor in order to improve the boot speed. However,
>>> with SEV-ES, the hypervisor is not allowed to change the CR0 register
>>> to enable caching.
>>>
>>> Update the OVMF Sec support to enable caching in order to improve the
>>> boot speed.
>>>
>>> Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com>
>>> ---
>>>  OvmfPkg/Sec/SecMain.c | 5 +++++
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
>>> index 3914355cd17b..2448be0cd408 100644
>>> --- a/OvmfPkg/Sec/SecMain.c
>>> +++ b/OvmfPkg/Sec/SecMain.c
>>> @@ -739,6 +739,11 @@ SecCoreStartupWithStack (
>>>  
>>>    ProcessLibraryConstructorList (NULL, NULL);
>>>  
>>> +  //
>>> +  // 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 burden
>> of proof is not on me". :) Can we make this change conditional on SEV-ES?
> 
> This was also raised as an issue by Peter for the ACRN hypervisor and
> Scott for the bhyve hypervisor.
> 
> 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.
> 
> 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.

I can't think of anything better than "trial and error". 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. 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.

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.

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.

Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#46211): https://edk2.groups.io/g/devel/message/46211
Mute This Topic: https://groups.io/mt/32966275/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-