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/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
