From: Laszlo Ersek <lersek@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "edk2-devel@ml01.01.org" <edk2-devel@ml01.01.org>,
"KVM devel mailing list" <kvm@vger.kernel.org>,
"Radim Krčmář" <rkrcmar@redhat.com>
Subject: Re: [edk2] apparent SMBASE relocation issue with noexec enabled [was: MdeModulePkg DxeIpl: Add stack NX support]
Date: Fri, 7 Aug 2015 15:12:08 +0200 [thread overview]
Message-ID: <55C4AEA8.1040507@redhat.com> (raw)
In-Reply-To: <55C48AAA.80001@redhat.com>
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
>
prev parent reply other threads:[~2015-08-07 13:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1438345360-7076-1-git-send-email-star.zeng@intel.com>
[not found] ` <55C22EC0.2030400@redhat.com>
[not found] ` <43260721-AB29-4182-8961-D33A70C5377B@apple.com>
[not found] ` <55C23994.4000804@redhat.com>
[not found] ` <0C09AFA07DD0434D9E2A0C6AEB04831002175554@shsmsx102.ccr.corp.intel.com>
[not found] ` <55C31D59.6060400@redhat.com>
[not found] ` <0C09AFA07DD0434D9E2A0C6AEB04831002175A03@shsmsx102.ccr.corp.intel.com>
[not found] ` <55C36446.1030904@redhat.com>
2015-08-06 14:31 ` [edk2] apparent SMBASE relocation issue with noexec enabled [was: MdeModulePkg DxeIpl: Add stack NX support] Laszlo Ersek
2015-08-06 14:55 ` Paolo Bonzini
2015-08-06 22:38 ` Laszlo Ersek
2015-08-06 23:02 ` Laszlo Ersek
2015-08-07 10:38 ` Paolo Bonzini
2015-08-07 13:12 ` Laszlo Ersek [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55C4AEA8.1040507@redhat.com \
--to=lersek@redhat.com \
--cc=edk2-devel@ml01.01.org \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.