From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 15198AC0ACB for ; Tue, 23 Jan 2024 10:52:23 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=npmSXEGE3LkKVD+Yy0rbSNwBcxCDJVvHZweyoFQJr+I=; c=relaxed/simple; d=groups.io; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Disposition; s=20140610; t=1706007142; v=1; b=oGpVEjvsze9GFFWCy9nngH5GR58GEuZY0u1heRpvzPVxLFNQ5rkfiPspZ5ZJVxbnF83P+fIX uO78RJvCiK7a2UZuzVz/YjSmi0JIpOtZ/5oOQUJleQrIRR2iaxRv4pUfz58ezG4tcVjR+jDSww1 2M+Xq4vED1QicHJkR7yfuaZg= X-Received: by 127.0.0.2 with SMTP id rOcBYY7687511xi0flBCYV6u; Tue, 23 Jan 2024 02:52:22 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web10.9382.1706007141936363952 for ; Tue, 23 Jan 2024 02:52:22 -0800 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-212-6YNc8YhIP5C6nxR4WBxDZQ-1; Tue, 23 Jan 2024 05:52:17 -0500 X-MC-Unique: 6YNc8YhIP5C6nxR4WBxDZQ-1 X-Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D2462185A780; Tue, 23 Jan 2024 10:52:16 +0000 (UTC) X-Received: from sirius.home.kraxel.org (unknown [10.39.193.66]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9B442C0FDCC; Tue, 23 Jan 2024 10:52:16 +0000 (UTC) X-Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 0DBD7180038B; Tue, 23 Jan 2024 11:52:15 +0100 (CET) Date: Tue, 23 Jan 2024 11:52:15 +0100 From: "Gerd Hoffmann" To: "Brian J. Johnson" Cc: devel@edk2.groups.io, "West, Catharine" , "Xu, Min M" , "Ni, Ray" , "Wu, MingliangX" , "Yao, Jiewen" , "Xue, Shengfeng" , "Dong, Eric" , "Kumar, Rahul R" , "De, Debkumar" Subject: Re: [edk2-devel] [PATCH V1 1/1] UefiCpuPkg/ResetVector: Cache Disable should not be set by default in CR0 Message-ID: <3lxerlg6g5gbzsxyh2v4qqqxru34ewytbge2wm6s7quyx3itx6@xlajojgm73qe> References: <20230726094754.171-1-xueshengfeng@byosoft.com.cn> <177562550EF0534C.27380@groups.io> <3505f62e-cc54-490e-983f-7b4312e41509@hpe.com> MIME-Version: 1.0 In-Reply-To: <3505f62e-cc54-490e-983f-7b4312e41509@hpe.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,kraxel@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: 8iuMnPGwTkhsq1q9SdkVcSfnx7686176AA= Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=oGpVEjvs; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On Mon, Jan 22, 2024 at 01:11:52PM -0600, Brian J. Johnson wrote: > 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. It happens very early at boot, before MTRRs are setup, running on the initial page tables created by the OVMF reset vector. The initial page tables have just 'accessed', 'dirty', 'read/write' and 'present' bits set for the 0-4G identity mapping. It seems to have something to do with EPT. It does not happen on AMD processors. It also does not happen when disabling EPT support in kvm on the host machine. looked at kvm kernel traces, I don't see excessive vmexits. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#114193): https://edk2.groups.io/g/devel/message/114193 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] -=-=-=-=-=-=-=-=-=-=-=-