Re: [edk2-devel] [PATCH v3 1/4] OvmfPkg/Sec: Setup MTRR early in the boot process.

["Corvin Köhne" <corvink@FreeBSD.org>]

[-- Attachment #1: Type: text/plain, Size: 3789 bytes --]

On Tue, 2024-02-20 at 09:15 +0100, Gerd Hoffmann wrote:
> On Tue, Feb 20, 2024 at 06:27:21AM +0000, Min Xu wrote:
> > On Monday, February 12, 2024 11:22 PM, Gerd Hoffmann wrote:
> > > On Thu, Feb 01, 2024 at 10:38:43AM +0100, Gerd Hoffmann wrote:
> > > >   Hi,
> > > > 
> > > > > > Can you confirm (a) this patch is OK for
> > > > > > "OvmfPkg/IntelTdx/Sec/SecMain.c", and (b) this series fixes
> > > > > > the slowdown
> > > you had encountered?
> > > > > > 
> > > > > > (that's what's left before we can merge this series)
> > > > > > 
> > > > > We test the patch in TDX and find EXIT_REASON_CR_ACCESS is
> > > > > triggered in
> > > DXE phase.
> > > > 
> > > > Hmm.  Sure this caused by this patch series?  For the PEI-less
> > > > TDX
> > > > build this series moves the MTRR setup to a different place in
> > > > SEC.
> > > > Once the DXE phase started the MTRR configuration should be
> > > > identical
> > > > with and without this patch series, and the series also doesn't
> > > > touch
> > > > any control register.
> > > 
> > > Ping.  Can you double-check please?  Our QE ran a test build with
> > > this series
> > > applied through regression testing (including TDX) and has not
> > > found any
> > > issues.
> > 
> > We double check the patch-set (v3) for both OvmfPkgX64 and
> > IntelTdx.
> > It triggered EXIT_REASON_CR_ACCESS in DXE phase when launching a
> > td-guest.
> 
> Have you been able to figure which control register access caused the
> EXIT_REASON_CR_ACCESS?
> 
> > @Gerd, what's the qemu command and test environment your QE
> > run the case? We'd like run it in our side.
> 
> <quote>
> 
> Tested edk2-ovmf-20231122-1.el9.rhel21704.20240202.1130.noarch with
> TDX guest, no issue found
> 
> Version:
> 
> edk2-ovmf-20231122-1.el9.rhel21704.20240202.1130.noarch
> 
> guest kernel: 5.14.0-415.el9.x86_64
> 
> qemu-kvm-8.0.0-15.el9s.x86_64
> host kernel-5.14.0-411.test.el9s.x86_64
> 
> Steps:
> 
> $ sudo /usr/libexec/qemu-kvm  -accel kvm   -drive
> file=/home/zixchen/rhel94_tdx.qcow2,if=none,id=virtio-disk0   -device
> virtio-blk-pci,drive=virtio-disk0   -cpu host -smp 16 -m 10240 -
> object tdx-guest,id=tdx,debug=on   -machine
> q35,hpet=off,kernel_irqchip=split,memory-encryption=tdx,confidential-
> guest-support=tdx,memory-backend=ram1   -object memory-backend-
> ram,id=ram1,size=10240M,private=on  -nographic -vga none   -
> nodefaults -bios /usr/share/edk2/ovmf/OVMF.inteltdx.secboot.fd  -
> serial stdio  -netdev user,id=user.0 -device e1000,netdev=user.0
> 
> $ dmesg|grep -i tdx
> [    0.000000] tdx: Guest detected
> [    0.719122] TECH PREVIEW: Intel Trusted Domain Extensions (TDX)
> may not be fully supported.
> [    0.719122]  Intel TDX
> [    0.719122] process: using TDX aware idle routine
> 
> </quote>
> 
> Host configuration with the tdx test packages:
> https://sigs.centos.org/virt/tdx/host/
> 
> Latest edk2 build (stable202311 + patches) has the patch series
> included:
> 
> https://kojihub.stream.centos.org/koji/buildinfo?buildID=56985
> 
> take care,
>   Gerd
> 
> 
> 
> 
> 
> 

Hi,

any progress on that patch?

I'm currently trying to passthrough the integrated GPU of an Intel
CPUs. When I add the GPU to the qemu command, I'm faced with the
descripted issue. This patch solves the issue.


-- 
Kind regards,
Corvin


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



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]