From: "Andreas Färber" <afaerber@suse.de>
To: Laszlo Ersek <lersek@redhat.com>,
Gary Ching-Pang Lin <glin@suse.com>,
Ludwig Nussel <lnussel@suse.de>
Cc: Jordan Justen <jordan.l.justen@intel.com>,
edk2-devel@lists.sourceforge.net,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] [edk2] OVMF hung on qemu 1.6.0 with KVM
Date: Wed, 28 Aug 2013 14:55:26 +0200 [thread overview]
Message-ID: <521DF33E.4090205@suse.de> (raw)
In-Reply-To: <521DE8C7.1010903@redhat.com>
Am 28.08.2013 14:10, schrieb Laszlo Ersek:
> On 08/28/13 13:49, Andreas Färber wrote:
>> Am 28.08.2013 13:45, schrieb Laszlo Ersek:
>>> (qemu-devel CC'd)
>>>
>>> On 08/28/13 12:35, Gary Ching-Pang Lin wrote:
>>>> Hi,
>>>>
>>>> I recently updated qemu to 1.6.0 and found OVMF just showed a blank
>>>> screen when kvm was enabled. I tried to dump OVMF log with the
>>>> following commond but nothing was stored in debug.log.
>>>>
>>>> qemu-system-x86_64 -s -enable-kvm -bios OVMF.fd -debugcon file:debug.log -global isa-debugcon.iobase=0x402
>>>>
>>>> The kvm trace was recorded with "trace-cmd record -b 20000 -e kvm"
>>>> and uploaded to the following link:
>>>> https://docs.google.com/file/d/0B9hbtlc_aK_gcGh2TDZLUVlzWWc/edit?usp=sharing
>>>>
>>>> I found a similar case with kernel < 3.9, but I already upgraded linux
>>>> kernel to 3.10.5, so this may be another bug.
>>>
>>> Well, the usual first response in cases like this is...
>>>
>>> Can you bisect qemu? :)
>>
>> We had a similar report:
>> https://bugzilla.novell.com/show_bug.cgi?id=835895
>
> Well that's sorta the same report, considering you and Gary both work
> for SUSE, and the Novell BZ seems to imply the build in question was Gary's:
>
>> qemu 1.6.0 fails to run the tianocore firmware
>> (home:gary_lin:UEFI/OVMF) properly. This worked with previous qemu
> ^^^^^^^^
>> versions:
>
> :)
Different reporters, so who knows if the setups are the same. ;)
>> git-bisect said:
>> 235e8982ad393e5611cb892df54881c872eea9e1 is the first bad commit
>> commit 235e8982ad393e5611cb892df54881c872eea9e1
>> Author: Jordan Justen <jordan.l.justen@intel.com>
>> Date: Wed May 29 01:27:26 2013 -0700
>>
>> kvm: support using KVM_MEM_READONLY flag for regions
>>
>> For readonly memory regions and rom devices in romd_mode,
>> we make use of the KVM_MEM_READONLY. A slot that uses
>> KVM_MEM_READONLY can be read from and code can execute from the
>> region, but writes will exit to qemu.
>>
>> For rom devices with !romd_mode, we force the slot to be
>> removed so reads or writes to the region will exit to qemu.
>> (Note that a memory region in this state is not executable
>> within kvm.)
>>
>> v7:
>> * Update for readable => romd_mode rename (5f9a5ea1)
>>
>> Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
>> Reviewed-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> (v4)
>> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> (v5)
>> Message-id: 1369816047-16384-4-git-send-email-jordan.l.justen@intel.com
>> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
>>
>>
>> Any hints or patches welcome. :)
>
> Hm. LP 1212402 <https://bugs.launchpad.net/qemu/+bug/1212402> probably
> concerns the "similar case with kernel < 3.9" mentioned by Gary, and is
> likely not revelant here.
>
>
> Gary & Ludwig, can you confirm that your OVMF build includes SVN r14494?
>
> Author: Jordan Justen <jordan.l.justen@intel.com>
> Date: Thu Jul 18 22:51:27 2013 +0000
>
> OvmfPkg/Sec: Build identity mapped pages in RAM for X64
>
> This is based on MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c.
>
> Previously we would run using page tables built into the
> firmware device.
>
> If a flash memory is available, it is unsafe for the page
> tables to be stored in memory since the processor may try
> to write to the page table data structures.
>
> Additionally, when KVM ROM support is enabled for the
> firmware device, then PEI fails to boot when the page
> tables are in the firmware device.
https://build.opensuse.org/package/show/Virtualization/OVMF
is at r14547 and that one works for me.
Gary/Ludwig, can you confirm that this is resolved?
Thanks,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2013-08-28 12:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20130828103552.GC2038@GaryOffice.site>
2013-08-28 11:45 ` [Qemu-devel] [edk2] OVMF hung on qemu 1.6.0 with KVM Laszlo Ersek
2013-08-28 11:49 ` Andreas Färber
2013-08-28 12:10 ` Laszlo Ersek
2013-08-28 12:55 ` Andreas Färber [this message]
2013-08-28 14:09 ` Ludwig Nussel
2013-08-29 8:23 ` Gary Ching-Pang Lin
2013-08-29 16:04 ` Bruce Rogers
[not found] ` <521F1CB802000048000E30E0@suse.com>
2013-08-30 3:28 ` Gary Ching-Pang Lin
2013-08-30 5:59 ` Paolo Bonzini
2013-08-30 9:37 ` Laszlo Ersek
2013-08-30 11:58 ` Paolo Bonzini
2013-08-30 12:10 ` Gleb Natapov
2013-08-30 12:42 ` Paolo Bonzini
2013-08-30 17:33 ` Jordan Justen
2013-08-30 17:39 ` Jordan Justen
2013-08-30 18:44 ` Paolo Bonzini
2013-08-30 19:05 ` Jordan Justen
2013-08-31 7:00 ` Paolo Bonzini
2013-08-31 7:16 ` Jordan Justen
2013-09-02 2:58 ` Gary Ching-Pang Lin
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=521DF33E.4090205@suse.de \
--to=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=edk2-devel@lists.sourceforge.net \
--cc=glin@suse.com \
--cc=jordan.l.justen@intel.com \
--cc=lersek@redhat.com \
--cc=lnussel@suse.de \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).