Re: [edk2] apparent SMBASE relocation issue with noexec enabled [was: MdeModulePkg DxeIpl: Add stack NX support]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/07/15 12:38, Paolo Bonzini wrote:
> 
> 
> On 07/08/2015 01:02, Laszlo Ersek wrote:
>>>> The trace covers the full lifetime of the guest (I started tracing
>>>> before launching the guest, and I passed -no-reboot to qemu, so when the
>>>> guest crashed, QEMU exited.)
>>>>
>>>> This was on 3.10.0-299.el7.x86_64.
>> I repeated the test with EPT off. The guest doesn't crash this way, it spins in a busy loop.
>>
>>  qemu-system-i38-32767 [002] 55142.911133: kvm_emulate_insn:     0:7ffd790b: 0f aa
>>  qemu-system-i38-32767 [002] 55142.911139: kvm_cpuid:            func 80000001 rax 6e8 rbx 0 rcx 0 rdx 100000
>>  qemu-system-i38-32767 [002] 55142.911148: kvm_enter_smm:        vcpu 0: leaving SMM, smbase 0x7ffc0000
>>  qemu-system-i38-32767 [002] 55142.911150: kvm_mmu_get_page:     existing sp gfn 7fe65 1/2 q3 --- !pge !nxe root 0 sync
>>  qemu-system-i38-32767 [002] 55142.911151: kvm_mmu_get_page:     existing sp gfn 7fe66 1/2 q3 --- !pge !nxe root 0 sync
>>  qemu-system-i38-32767 [002] 55142.911151: kvm_mmu_get_page:     existing sp gfn 7fe67 1/2 q3 --- !pge !nxe root 0 sync
>>  qemu-system-i38-32767 [002] 55142.911151: kvm_mmu_get_page:     existing sp gfn 7fe68 1/2 q3 --- !pge !nxe root 0 sync
>>  qemu-system-i38-32767 [002] 55142.911152: kvm_entry:            vcpu 0
>>  qemu-system-i38-32767 [002] 55142.911152: kvm_exit:             reason EXCEPTION_NMI rip 0x7ffdb6b2 info 7fe88760 80000b0e
>>  qemu-system-i38-32767 [002] 55142.911153: kvm_page_fault:       address 7fe88760 error_code b
>>
>> And then the last triplet is repeated infinitely.
>>
>> 0x7ffdb6b2 is the address of the same first instruction executed after the RSM.
>>
>> The address 0x7fe88760 seems to fall into an EfiBootServicesData allocation, made in PEI (via a suitable HOB):
>>
>> Memory Allocation 0x00000004 0x7FE69000 - 0x7FE88FFF
> 
> You probably should use "-cpu model,-lm,-nx".  EFER is not part of the
> 32-bit state save map, so the EFER.NXE bit is not restored correctly on
> exit from SMM if you emulate a 32-bit CPU.

That did the trick, thank you! I added

    <feature policy='disable' name='nx'/>

under /domain/cpu in the libvirt XML, and the SMM stuff works fine again.

I'm going to update

  [edk2] [PATCH 58/58] OvmfPkg: README: document SMM status
  http://thread.gmane.org/gmane.comp.bios.edk2.devel/329/focus=382

with the -nx feature flag.

Thanks!
Laszlo

> I have not debugged yet why it works without KVM, nor why the symptoms
> are different between EPT and non-EPT.
> 
> Paolo
> 

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux