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? Michal
