Re: [edk2-devel] [PATCH V1 1/1] UefiCpuPkg/ResetVector: Cache Disable should not be set by default in CR0

["Min Xu" <min.m.xu@intel.com>]

Thanks much Johnson! We will investigate it based on your comments.

> -----Original Message-----
> From: Brian J. Johnson <brian.johnson@hpe.com>
> Sent: Tuesday, January 23, 2024 3:12 AM
> To: devel@edk2.groups.io; kraxel@redhat.com; West, Catharine
> <catharine.west@intel.com>
> Cc: Xu, Min M <min.m.xu@intel.com>; Ni, Ray <ray.ni@intel.com>; Wu,
> MingliangX <mingliangx.wu@intel.com>; Yao, Jiewen
> <jiewen.yao@intel.com>; Xue, Shengfeng <xueshengfeng@byosoft.com.cn>;
> Dong, Eric <eric.dong@intel.com>; Kumar, Rahul R
> <rahul.r.kumar@intel.com>; De, Debkumar <debkumar.de@intel.com>
> Subject: Re: [edk2-devel] [PATCH V1 1/1] UefiCpuPkg/ResetVector: Cache
> Disable should not be set by default in CR0
> 
> On 1/18/24 09:46, Gerd Hoffmann wrote:
> > On Wed, Jan 10, 2024 at 04:43:47PM +0000, West, Catharine wrote:
> >> Disabling cache by default results in violation of BTG protections (if BTG
> enabled).
> >>
> >> BIOS cannot assume that cache is disabled before it executes as ACM may
> be required to enable NEM.
> >>
> >> Whatever solution needs to be done here cannot evict ACM-enabled
> NEM.
> >
> > Well, it's OVMF in a virtual machine.  No boot guard involved.
> > So we could probably go for a OVMF-specific patch here.
> >
> > But I'd prefer to figure what exactly is happening here before going
> > down that route.  An extreme slowdown just because we flip that bit
> > doesn't make sense to me.
> >
> >> Why is boot time increasing?
> >
> > Not clear.  It seems to be the lzma uncompress of the firmware volume
> > in rom / pflash which is very slow.  Also it is apparently only
> > triggered in case pci device assignment is used.
> 
> I've seen extreme slowness on physical platforms when we've mixed up the
> MTRRs or page tables, causing code to be mapped uncached.
> 
> Lzma uncompress of ROM could be pretty slow as well, if the ROM is being
> read uncached.  Lzma probably reads the data a byte at a time, which is the
> worst case for uncached accesses.  Since this is a VM, it's not actually
> uncached at the hardware level, but I don't know how QEMU/KVM handles
> uncached guest mappings.... It may be doing a VMEXIT for every byte.
> 
> Anyway, I suggest double-checking your page tables and MTRRs.
> --
> Brian J. Johnson
> Enterprise X86 Lab
> Hewlett Packard Enterprise


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114173): https://edk2.groups.io/g/devel/message/114173
Mute This Topic: https://groups.io/mt/100367559/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-