From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail05.groups.io (mail05.groups.io [45.79.224.7]) by spool.mail.gandi.net (Postfix) with ESMTPS id D0E5D7803CF for ; Wed, 24 Apr 2024 16:09:34 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=7jrvgGesDrIVLuIESv/lTcwfVkibzp+TQmG24ozLhdU=; 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:Resent-Date:Resent-From:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Disposition; s=20240206; t=1713974973; v=1; b=wdJnyf3USqauHtew2R0pJicEe1FwvJHtimv9DrOu7AfwG2DfcZCmyrQsnyCLl/G550hWardw SUq3AOapR/e96utpOe7uc1UrADy4mpC8wY+5Ll+j12tsJPZDQ9MYNBuwtYHE6BBUNZmAkYIhoPl JKxnc7HvOm9jlXRVWlzrtLIFa+7sVSWfDD9Sqah7T+6O7jjkuC1yxryutGTBwmWJUJKV9W0aB4+ 5KdNyx2oLHdG2ImX5T1vITfgyqsRG97rGCvrzVa3CO2AfnsJosivjtLnq/l0Ozxwjn5ifQIG/oR sx8eT1/hjyi1tSCBYxKqkRZ2BkTlF63otOXWKG1aV77sQ== X-Received: by 127.0.0.2 with SMTP id MedUYY7687511x2XzI7wLrzw; Wed, 24 Apr 2024 09:09:33 -0700 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web10.602.1713974972557618672 for ; Wed, 24 Apr 2024 09:09:32 -0700 X-Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-633-_LnZ2zsZPP2mMZWQvTU2sA-1; Wed, 24 Apr 2024 12:09:28 -0400 X-MC-Unique: _LnZ2zsZPP2mMZWQvTU2sA-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 4C0B51C05AA1; Wed, 24 Apr 2024 16:09:27 +0000 (UTC) X-Received: from dobby.home.kraxel.org (unknown [10.39.192.254]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E10D7C01595; Wed, 24 Apr 2024 16:09:26 +0000 (UTC) X-Received: by dobby.home.kraxel.org (Postfix, from userid 1000) id 9DD33F666B; Wed, 24 Apr 2024 18:09:25 +0200 (CEST) Date: Wed, 24 Apr 2024 18:09:25 +0200 From: "Gerd Hoffmann" To: Michael Roth Cc: devel@edk2.groups.io, Tom Lendacky , Ard Biesheuvel , Erdem Aktas , Jiewen Yao , Min Xu , Jianyong Wu , Anatol Belski Subject: Re: [edk2-devel] [PATCH] OvmfPkg: Don't make APIC MMIO accesses with encryption bit set Message-ID: References: <20240423205958.1791780-1-michael.roth@amd.com> <20240424145010.zgi2rtgfky6chly4@amd.com> MIME-Version: 1.0 In-Reply-To: <20240424145010.zgi2rtgfky6chly4@amd.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 Resent-Date: Wed, 24 Apr 2024 09:09:32 -0700 Resent-From: kraxel@redhat.com Reply-To: devel@edk2.groups.io,kraxel@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: UAnYCGuoU9p1M0642tzwaKsYx7686176AA= 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=20240206 header.b=wdJnyf3U; 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 45.79.224.7 as permitted sender) smtp.mailfrom=bounce@groups.io Hi, > > That is incompatible with 5-level paging. The current reset vector will > > never turn on 5-level paging in case SEV is active because we have more > > incompatibilities elsewhere (BaseMemEncryptSevLib IIRC). But still, > > it's moving things into the wrong direction ... > > Tom had mentioned this eventuality and we discussed it to an extent. AIUI > once we make that switch then most of this function could be replaced with > a call into the library to handle the splitting, and similar re-work would > need to be done for handling splitting the area for the GHCB page which is > also currently done with direct page table manipulation. So while it > does sort of move in the wrong direction, I don't think it would > significantly complicate things as far as making that transition. GHCB page is handled with asm code in the reset vector and I'm not sure it can be moved out there as the page will be needed quite early in firmware boot. > > Ideally CpuPageTableLib should be used for this. > > What's the outlook for moving CpuPageTableLib before the next OVMF release? > My concern is that once SNP KVM support goes upstream (which is currently > looking to be within kernel 6.10 timeframe), SNP guest support in OVMF will > be completely broken without a fix like this for APIC MMIO accesses. Fixing this surely should be done before the may stable tag. If CpuPageTableLib changes are needed, then going the CpuPageTableLib route is a bit risky indeed. I don't think we need CpuPageTableLib changes though. At least not for the reason (page table memory allocation) mentioned by Tom. The patch reserves a page in MEMFD, and simply giving that page to CpuPageTableLib should work just fine. > One thing to maybe get ahead of is the fact that splitting pages with > 5-level paging will require having 2 pages reserved for GHCB instead of > the 1 we have currently, and 2 pages reserved for APIC range instead of > the 1 proposed by this patch (since we'd need to not only split a 2MB PTE > to 4KB, but the upper 1GB PTE to 2MB). The first GB is covered by 2M pages even with 5-level paging, exactly to simplify the GHCB setup. For APIC + 5-level paging we'll indeed need a second page table page. > Do we know enough about what that sort of allocation/reserve logic would > look to start modifying PcdOvmfSecPageTablesBase, > PcdOvmfSecGhcbPageTableBase, and PcdOvmfSecApicPageTableBase to start > preping for such a change? Well, CpuPageTableLib simply expects getting a buffer passed in with page table memory. So allocation is fully in the hands of the caller. It's also possible to call the library without buffer and get back the number of pages which will be needed to apply the changes, so the caller can allocate exactly what will be needed. That would not be needed here given we need a big enough pool of pages in MEMFD anyway. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#118218): https://edk2.groups.io/g/devel/message/118218 Mute This Topic: https://groups.io/mt/105698125/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-