From: "Gerd Hoffmann" <kraxel@redhat.com>
To: Michael Roth <michael.roth@amd.com>
Cc: devel@edk2.groups.io, Tom Lendacky <thomas.lendacky@amd.com>,
Ard Biesheuvel <ardb@kernel.org>,
Erdem Aktas <erdemaktas@google.com>,
Jiewen Yao <jiewen.yao@intel.com>, Min Xu <min.m.xu@intel.com>,
Jianyong Wu <jianyong.wu@arm.com>,
Anatol Belski <anbelski@linux.microsoft.com>
Subject: Re: [edk2-devel] [PATCH] OvmfPkg: Don't make APIC MMIO accesses with encryption bit set
Date: Wed, 24 Apr 2024 18:09:25 +0200 [thread overview]
Message-ID: <c753xatjflziviqm6aszmvbrea2ruoo2uiixlieupyaqln5wzs@j2ioafvmna54> (raw)
In-Reply-To: <20240424145010.zgi2rtgfky6chly4@amd.com>
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]
-=-=-=-=-=-=-=-=-=-=-=-
prev parent reply other threads:[~2024-04-24 16:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-23 20:59 [edk2-devel] [PATCH] OvmfPkg: Don't make APIC MMIO accesses with encryption bit set Roth, Michael via groups.io
2024-04-24 11:54 ` Gerd Hoffmann
2024-04-24 14:05 ` Lendacky, Thomas via groups.io
2024-04-24 14:45 ` Gerd Hoffmann
2024-04-24 16:38 ` Lendacky, Thomas via groups.io
2024-04-24 14:50 ` Roth, Michael via groups.io
2024-04-24 16:09 ` Gerd Hoffmann [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c753xatjflziviqm6aszmvbrea2ruoo2uiixlieupyaqln5wzs@j2ioafvmna54 \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox