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/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
signature.asc
Description: This is a digitally signed message part
