On Thu, Aug 25, 2022, Michal Luczaj wrote: > On 8/25/22 19:03, Sean Christopherson wrote: > > On Wed, Aug 24, 2022, Michal Luczaj wrote: > >> \ > >> n = 0; \ > >> asm volatile(/* jump to 32-bit code segment */ \ > >> "ljmp *1f\n\t" \ > >> "1:\n\t" \ > >> " .long 2f\n\t" \ > >> " .word " xstr(KERNEL_CS32) "\n\t" \ > >> /* exercise POP SS blocking */ \ > >> ".code32\n\t" \ > >> "2: lea 3f, %0\n\t" \ > >> "mov %0, %%dr0\n\t" \ > >> "push %%ss\n\t" \ > >> fep1 "pop %%ss\n\t" \ > >> fep2 "3: xor %0, %0\n\t" \ > >> /* back to long mode */ \ > >> "ljmp %[cs64], $4f\n\t" \ > >> ".code64\n\t" \ > > > > Ooh, I see what you meant by temporarily switching to 32-bit mode. I was thinking > > we could just make the POP SS testcase 32-bit only, but I didn't realize this test > > is 64-bit only. Argh, and so is emulate.c. And now I get why you added a brand > > new test. > > > > Let's just add a new test. The above can work, but it relies on the code and > > stack being mapped with a 32-bit address, e.g. will break if KUT is ever changed > > to not map everything low in the virtual address space. > > Yeah, it is fragile in that sense. But does it mean code such as > vmx_tests.c:into_guest_main() or svm_tests.c:svm_of_test_guest() should be moved > to 32-bit binaries? Ideally? Yeah. In practice, it's just not worth replicating all the nSVM/nVMX setup for 32-bit binaries.
