* [Qemu-devel] VM can not boot after commit 235e898
@ 2013-06-04 3:47 Dunrong Huang
2013-06-04 6:41 ` Jordan Justen
2013-06-04 6:47 ` Paolo Bonzini
0 siblings, 2 replies; 20+ messages in thread
From: Dunrong Huang @ 2013-06-04 3:47 UTC (permalink / raw)
To: qemu-devel; +Cc: Jordan Justen
[-- Attachment #1: Type: text/plain, Size: 723 bytes --]
QEMU command:
~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 debian-append.img
git bisect tells that the following commit causes this bug:
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.
After reverting this commit, VM can boot normally.
Any information I should provide?
--
Best Regards,
Dunrong Huang
Homepage: http://mathslinux.org
[-- Attachment #2: Type: text/html, Size: 1584 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] VM can not boot after commit 235e898
2013-06-04 3:47 [Qemu-devel] VM can not boot after commit 235e898 Dunrong Huang
@ 2013-06-04 6:41 ` Jordan Justen
2013-06-04 7:46 ` Dunrong Huang
2013-06-04 6:47 ` Paolo Bonzini
1 sibling, 1 reply; 20+ messages in thread
From: Jordan Justen @ 2013-06-04 6:41 UTC (permalink / raw)
To: Dunrong Huang; +Cc: Jordan Justen, qemu-devel
Fixed in 651eb0f4?
On Mon, Jun 3, 2013 at 8:47 PM, Dunrong Huang <riegamaths@gmail.com> wrote:
>
> QEMU command:
> ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 debian-append.img
>
> git bisect tells that the following commit causes this bug:
>
> 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.
>
> After reverting this commit, VM can boot normally.
>
> Any information I should provide?
>
> --
> Best Regards,
>
> Dunrong Huang
>
> Homepage: http://mathslinux.org
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] VM can not boot after commit 235e898
2013-06-04 3:47 [Qemu-devel] VM can not boot after commit 235e898 Dunrong Huang
2013-06-04 6:41 ` Jordan Justen
@ 2013-06-04 6:47 ` Paolo Bonzini
2013-06-04 7:47 ` Dunrong Huang
1 sibling, 1 reply; 20+ messages in thread
From: Paolo Bonzini @ 2013-06-04 6:47 UTC (permalink / raw)
To: Dunrong Huang; +Cc: Jordan Justen, qemu-devel
Il 04/06/2013 05:47, Dunrong Huang ha scritto:
>
> QEMU command:
> ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 debian-append.img
>
> git bisect tells that the following commit causes this bug:
>
> commit 235e8982ad393e5611cb892df54881c872eea9e1
> Author: Jordan Justen <jordan.l.justen@intel.com
> <mailto: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.
>
> After reverting this commit, VM can boot normally.
A patch is queued for that. Using kernel 3.8 or reverting the commit
will both work.
Paolo
>
> Any information I should provide?
>
> --
> Best Regards,
>
> Dunrong Huang
>
> Homepage: http://mathslinux.org
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] VM can not boot after commit 235e898
2013-06-04 6:41 ` Jordan Justen
@ 2013-06-04 7:46 ` Dunrong Huang
0 siblings, 0 replies; 20+ messages in thread
From: Dunrong Huang @ 2013-06-04 7:46 UTC (permalink / raw)
To: Jordan Justen; +Cc: Jordan Justen, qemu-devel
[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]
On Tue, Jun 4, 2013 at 2:41 PM, Jordan Justen <jljusten@gmail.com> wrote:
> Fixed in 651eb0f4?
>
No, it still fails.
>
> On Mon, Jun 3, 2013 at 8:47 PM, Dunrong Huang <riegamaths@gmail.com>
> wrote:
> >
> > QEMU command:
> > ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 debian-append.img
> >
> > git bisect tells that the following commit causes this bug:
> >
> > 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.
> >
> > After reverting this commit, VM can boot normally.
> >
> > Any information I should provide?
> >
> > --
> > Best Regards,
> >
> > Dunrong Huang
> >
> > Homepage: http://mathslinux.org
> >
>
--
Best Regards,
Dunrong Huang
Homepage: http://mathslinux.org
[-- Attachment #2: Type: text/html, Size: 2067 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] VM can not boot after commit 235e898
2013-06-04 6:47 ` Paolo Bonzini
@ 2013-06-04 7:47 ` Dunrong Huang
2013-06-04 7:51 ` Gleb Natapov
0 siblings, 1 reply; 20+ messages in thread
From: Dunrong Huang @ 2013-06-04 7:47 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Jordan Justen, qemu-devel
[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]
On Tue, Jun 4, 2013 at 2:47 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 04/06/2013 05:47, Dunrong Huang ha scritto:
> >
> > QEMU command:
> > ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 debian-append.img
> >
> > git bisect tells that the following commit causes this bug:
> >
> > commit 235e8982ad393e5611cb892df54881c872eea9e1
> > Author: Jordan Justen <jordan.l.justen@intel.com
> > <mailto: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.
> >
> > After reverting this commit, VM can boot normally.
>
> A patch is queued for that. Using kernel 3.8 or reverting the commit
> will both work.
>
Ok, thanks for information, I will try it.
>
> Paolo
>
>
--
Best Regards,
Dunrong Huang
Homepage: http://mathslinux.org
[-- Attachment #2: Type: text/html, Size: 2036 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] VM can not boot after commit 235e898
2013-06-04 7:47 ` Dunrong Huang
@ 2013-06-04 7:51 ` Gleb Natapov
2013-06-04 8:26 ` Dunrong Huang
0 siblings, 1 reply; 20+ messages in thread
From: Gleb Natapov @ 2013-06-04 7:51 UTC (permalink / raw)
To: Dunrong Huang; +Cc: Paolo Bonzini, qemu-devel, Jordan Justen
On Tue, Jun 04, 2013 at 03:47:47PM +0800, Dunrong Huang wrote:
> On Tue, Jun 4, 2013 at 2:47 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> > Il 04/06/2013 05:47, Dunrong Huang ha scritto:
> > >
> > > QEMU command:
> > > ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 debian-append.img
> > >
> > > git bisect tells that the following commit causes this bug:
> > >
> > > commit 235e8982ad393e5611cb892df54881c872eea9e1
> > > Author: Jordan Justen <jordan.l.justen@intel.com
> > > <mailto: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.
> > >
> > > After reverting this commit, VM can boot normally.
> >
> > A patch is queued for that. Using kernel 3.8 or reverting the commit
> > will both work.
> >
> Ok, thanks for information, I will try it.
>
The fix is 651eb0f4 and you claim it is still fails for you. This is
strange because the commit fixed the problem for everyone else. Can you
double check that you are testing the right commit and you recompiled
and reinstalled?
--
Gleb.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] VM can not boot after commit 235e898
2013-06-04 7:51 ` Gleb Natapov
@ 2013-06-04 8:26 ` Dunrong Huang
2013-06-04 17:03 ` Jordan Justen
0 siblings, 1 reply; 20+ messages in thread
From: Dunrong Huang @ 2013-06-04 8:26 UTC (permalink / raw)
To: Gleb Natapov; +Cc: Paolo Bonzini, qemu-devel, Jordan Justen
[-- Attachment #1: Type: text/plain, Size: 3938 bytes --]
On Tue, Jun 4, 2013 at 3:51 PM, Gleb Natapov <gleb@redhat.com> wrote:
> On Tue, Jun 04, 2013 at 03:47:47PM +0800, Dunrong Huang wrote:
> > On Tue, Jun 4, 2013 at 2:47 PM, Paolo Bonzini <pbonzini@redhat.com>
> wrote:
> >
> > > Il 04/06/2013 05:47, Dunrong Huang ha scritto:
> > > >
> > > > QEMU command:
> > > > ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 debian-append.img
> > > >
> > > > git bisect tells that the following commit causes this bug:
> > > >
> > > > commit 235e8982ad393e5611cb892df54881c872eea9e1
> > > > Author: Jordan Justen <jordan.l.justen@intel.com
> > > > <mailto: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.
> > > >
> > > > After reverting this commit, VM can boot normally.
> > >
> > > A patch is queued for that. Using kernel 3.8 or reverting the commit
> > > will both work.
> > >
> > Ok, thanks for information, I will try it.
> >
> The fix is 651eb0f4 and you claim it is still fails for you. This is
> strange because the commit fixed the problem for everyone else. Can you
> double check that you are testing the right commit and you recompiled
> and reinstalled?
>
I am sure 651eb0f4 does not fix this problem.
My test environment is below:
* config.log:
# head -n 2 config.log
# QEMU configure log 2013年 06月 04日 星期二 16:12:59 CST
# Configured with: './configure' '--prefix=/root/usr' '--enable-kvm'
'--enable-werror' '--enable-debug' '--enable-debug-tcg'
'--enable-debug-info' '--enable-sdl' '--enable-gtk' '--enable-virtfs'
'--enable-vnc' '--enable-mixemu' '--enable-vnc-tls' '--enable-vnc-sasl'
'--enable-vnc-jpeg' '--enable-vnc-png' '--enable-vnc-ws' '--enable-curses'
'--enable-curl' '--enable-nptl' '--enable-system' '--enable-user'
'--enable-linux-user' '--enable-guest-base' '--enable-uuid' '--enable-vde'
'--enable-linux-aio' '--enable-cap-ng' '--enable-attr' '--enable-docs'
'--enable-vhost-net' '--enable-spice' '--enable-usb-redir'
'--enable-smartcard-nss' '--enable-tpm' '--enable-guest-agent'
'--target-list=x86_64-softmmu'
* kernel version:
# uname -a
Linux gentoo-company 3.8.2-gentoo #1 SMP Fri Mar 8 11:44:36 CST 2013 x86_64
Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux
* details of git tree:
# git log HEAD --oneline
1713924 gtk: don't use g_object_unref on GdkCursor
41686a9 gtk: don't resize window when enabling scaling
651eb0f fix double free the memslot in kvm_set_phys_mem
25b4833 configure: Report unknown target names more helpfully
6e92f82 configure: Autogenerate default target list
0ded1fe Merge remote-tracking branch 'pmaydell/arm-devs.next' into staging
95669e6 i.MX: Improve EPIT timer code.
6539ed2 exynos4210.c: register rom_mem for memory migration
* QEMU command line:
x86_64-softmmu/qemu-system-x86_64 -enable-kvm -cdrom
/mnt/nfs/Images/ISO/ubuntu-12.04-dvd-amd64.iso
After disable KVM_MEM_READONLY flag like below, VM can boot normally.
diff --git a/kvm-all.c b/kvm-all.c
index 405480e..c33ba6e 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -774,7 +774,7 @@ static void kvm_set_phys_mem(MemoryRegionSection
*section, bool add)
mem->memory_size = size;
mem->start_addr = start_addr;
mem->ram = ram;
- mem->flags = kvm_mem_flags(s, log_dirty, readonly_flag);
+ mem->flags = kvm_mem_flags(s, log_dirty, false);
err = kvm_set_user_memory_region(s, mem);
if (err) {
I can provide more details if needed.
> --
> Gleb.
>
--
Best Regards,
Dunrong Huang
Homepage: http://mathslinux.org
[-- Attachment #2: Type: text/html, Size: 6142 bytes --]
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] VM can not boot after commit 235e898
2013-06-04 8:26 ` Dunrong Huang
@ 2013-06-04 17:03 ` Jordan Justen
2013-06-05 2:44 ` Dunrong Huang
0 siblings, 1 reply; 20+ messages in thread
From: Jordan Justen @ 2013-06-04 17:03 UTC (permalink / raw)
To: Dunrong Huang; +Cc: Paolo Bonzini, qemu-devel, Gleb Natapov, Jordan Justen
On Tue, Jun 4, 2013 at 1:26 AM, Dunrong Huang <riegamaths@gmail.com> wrote:
> On Tue, Jun 4, 2013 at 3:51 PM, Gleb Natapov <gleb@redhat.com> wrote:
>> On Tue, Jun 04, 2013 at 03:47:47PM +0800, Dunrong Huang wrote:
>> > On Tue, Jun 4, 2013 at 2:47 PM, Paolo Bonzini <pbonzini@redhat.com>
>> > wrote:
>> >
>> > > Il 04/06/2013 05:47, Dunrong Huang ha scritto:
>> > > >
>> > > > QEMU command:
>> > > > ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 debian-append.img
>> > > >
>> > > > git bisect tells that the following commit causes this bug:
>> > > >
>> > > > commit 235e8982ad393e5611cb892df54881c872eea9e1
>> > > > Author: Jordan Justen <jordan.l.justen@intel.com
>> > > > <mailto: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.
>> > > >
>> > > > After reverting this commit, VM can boot normally.
>> > >
>> > > A patch is queued for that. Using kernel 3.8 or reverting the commit
>> > > will both work.
>> > >
>> > Ok, thanks for information, I will try it.
>> >
>> The fix is 651eb0f4 and you claim it is still fails for you. This is
>> strange because the commit fixed the problem for everyone else. Can you
>> double check that you are testing the right commit and you recompiled
>> and reinstalled?
>
>
> I am sure 651eb0f4 does not fix this problem.
>
> My test environment is below:
>
> * config.log:
> # head -n 2 config.log
> # QEMU configure log 2013年 06月 04日 星期二 16:12:59 CST
> # Configured with: './configure' '--prefix=/root/usr' '--enable-kvm'
> '--enable-werror' '--enable-debug' '--enable-debug-tcg'
> '--enable-debug-info' '--enable-sdl' '--enable-gtk' '--enable-virtfs'
> '--enable-vnc' '--enable-mixemu' '--enable-vnc-tls' '--enable-vnc-sasl'
> '--enable-vnc-jpeg' '--enable-vnc-png' '--enable-vnc-ws' '--enable-curses'
> '--enable-curl' '--enable-nptl' '--enable-system' '--enable-user'
> '--enable-linux-user' '--enable-guest-base' '--enable-uuid' '--enable-vde'
> '--enable-linux-aio' '--enable-cap-ng' '--enable-attr' '--enable-docs'
> '--enable-vhost-net' '--enable-spice' '--enable-usb-redir'
> '--enable-smartcard-nss' '--enable-tpm' '--enable-guest-agent'
> '--target-list=x86_64-softmmu'
>
> * kernel version:
> # uname -a
> Linux gentoo-company 3.8.2-gentoo #1 SMP Fri Mar 8 11:44:36 CST 2013 x86_64
> Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux
You were using a >3.8 kernel originally? (Someone mentioned trying a
3.8 kernel, and I think that is when you went to 3.8.)
> * details of git tree:
> # git log HEAD --oneline
> 1713924 gtk: don't use g_object_unref on GdkCursor
> 41686a9 gtk: don't resize window when enabling scaling
> 651eb0f fix double free the memslot in kvm_set_phys_mem
> 25b4833 configure: Report unknown target names more helpfully
> 6e92f82 configure: Autogenerate default target list
> 0ded1fe Merge remote-tracking branch 'pmaydell/arm-devs.next' into staging
> 95669e6 i.MX: Improve EPIT timer code.
> 6539ed2 exynos4210.c: register rom_mem for memory migration
>
>
> * QEMU command line:
> x86_64-softmmu/qemu-system-x86_64 -enable-kvm -cdrom
> /mnt/nfs/Images/ISO/ubuntu-12.04-dvd-amd64.iso
FWIW, I've been able to boot the 11.10 iso when booted to a 3.9 kernel.
Does it only fail after you boot the OS? If you just run KVM without a
disk, so only seabios runs, is it okay?
> After disable KVM_MEM_READONLY flag like below, VM can boot normally.
> diff --git a/kvm-all.c b/kvm-all.c
> index 405480e..c33ba6e 100644
> --- a/kvm-all.c
> +++ b/kvm-all.c
> @@ -774,7 +774,7 @@ static void kvm_set_phys_mem(MemoryRegionSection
> *section, bool add)
> mem->memory_size = size;
> mem->start_addr = start_addr;
> mem->ram = ram;
> - mem->flags = kvm_mem_flags(s, log_dirty, readonly_flag);
> + mem->flags = kvm_mem_flags(s, log_dirty, false);
>
> err = kvm_set_user_memory_region(s, mem);
> if (err) {
>
> I can provide more details if needed.
I don't think you mentioned how it fails. Does KVM crash? Is an error
message printed? Does the VM reset, or just hang?
-Jordan
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] VM can not boot after commit 235e898
2013-06-04 17:03 ` Jordan Justen
@ 2013-06-05 2:44 ` Dunrong Huang
2013-06-05 7:34 ` Dunrong Huang
2013-07-24 9:58 ` Alexander Graf
0 siblings, 2 replies; 20+ messages in thread
From: Dunrong Huang @ 2013-06-05 2:44 UTC (permalink / raw)
To: Jordan Justen; +Cc: Paolo Bonzini, qemu-devel, Gleb Natapov, Jordan Justen
[-- Attachment #1: Type: text/plain, Size: 5894 bytes --]
On Wed, Jun 5, 2013 at 1:03 AM, Jordan Justen <jljusten@gmail.com> wrote:
> On Tue, Jun 4, 2013 at 1:26 AM, Dunrong Huang <riegamaths@gmail.com>
> wrote:
> > On Tue, Jun 4, 2013 at 3:51 PM, Gleb Natapov <gleb@redhat.com> wrote:
> >> On Tue, Jun 04, 2013 at 03:47:47PM +0800, Dunrong Huang wrote:
> >> > On Tue, Jun 4, 2013 at 2:47 PM, Paolo Bonzini <pbonzini@redhat.com>
> >> > wrote:
> >> >
> >> > > Il 04/06/2013 05:47, Dunrong Huang ha scritto:
> >> > > >
> >> > > > QEMU command:
> >> > > > ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 debian-append.img
> >> > > >
> >> > > > git bisect tells that the following commit causes this bug:
> >> > > >
> >> > > > commit 235e8982ad393e5611cb892df54881c872eea9e1
> >> > > > Author: Jordan Justen <jordan.l.justen@intel.com
> >> > > > <mailto: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.
> >> > > >
> >> > > > After reverting this commit, VM can boot normally.
> >> > >
> >> > > A patch is queued for that. Using kernel 3.8 or reverting the
> commit
> >> > > will both work.
> >> > >
> >> > Ok, thanks for information, I will try it.
> >> >
> >> The fix is 651eb0f4 and you claim it is still fails for you. This is
> >> strange because the commit fixed the problem for everyone else. Can you
> >> double check that you are testing the right commit and you recompiled
> >> and reinstalled?
> >
> >
> > I am sure 651eb0f4 does not fix this problem.
> >
> > My test environment is below:
> >
> > * config.log:
> > # head -n 2 config.log
> > # QEMU configure log 2013年 06月 04日 星期二 16:12:59 CST
> > # Configured with: './configure' '--prefix=/root/usr' '--enable-kvm'
> > '--enable-werror' '--enable-debug' '--enable-debug-tcg'
> > '--enable-debug-info' '--enable-sdl' '--enable-gtk' '--enable-virtfs'
> > '--enable-vnc' '--enable-mixemu' '--enable-vnc-tls' '--enable-vnc-sasl'
> > '--enable-vnc-jpeg' '--enable-vnc-png' '--enable-vnc-ws'
> '--enable-curses'
> > '--enable-curl' '--enable-nptl' '--enable-system' '--enable-user'
> > '--enable-linux-user' '--enable-guest-base' '--enable-uuid'
> '--enable-vde'
> > '--enable-linux-aio' '--enable-cap-ng' '--enable-attr' '--enable-docs'
> > '--enable-vhost-net' '--enable-spice' '--enable-usb-redir'
> > '--enable-smartcard-nss' '--enable-tpm' '--enable-guest-agent'
> > '--target-list=x86_64-softmmu'
> >
> > * kernel version:
> > # uname -a
> > Linux gentoo-company 3.8.2-gentoo #1 SMP Fri Mar 8 11:44:36 CST 2013
> x86_64
> > Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux
>
> You were using a >3.8 kernel originally? (Someone mentioned trying a
> 3.8 kernel, and I think that is when you went to 3.8.)
>
> yes, I have been using kernel 3.8.2 lately, not because of Paolo's
suggestion.
> > * details of git tree:
> > # git log HEAD --oneline
> > 1713924 gtk: don't use g_object_unref on GdkCursor
> > 41686a9 gtk: don't resize window when enabling scaling
> > 651eb0f fix double free the memslot in kvm_set_phys_mem
> > 25b4833 configure: Report unknown target names more helpfully
> > 6e92f82 configure: Autogenerate default target list
> > 0ded1fe Merge remote-tracking branch 'pmaydell/arm-devs.next' into
> staging
> > 95669e6 i.MX: Improve EPIT timer code.
> > 6539ed2 exynos4210.c: register rom_mem for memory migration
> >
> >
> > * QEMU command line:
> > x86_64-softmmu/qemu-system-x86_64 -enable-kvm -cdrom
> > /mnt/nfs/Images/ISO/ubuntu-12.04-dvd-amd64.iso
>
> FWIW, I've been able to boot the 11.10 iso when booted to a 3.9 kernel.
>
> Does it only fail after you boot the OS? If you just run KVM without a
> disk, so only seabios runs, is it okay?
>
It fails even runing without any parameters, like:
x86_64-softmmu/qemu-system-x86_64 -enable-kvm
No BIOS information printed, just a black screen is shown.
> > After disable KVM_MEM_READONLY flag like below, VM can boot normally.
> > diff --git a/kvm-all.c b/kvm-all.c
> > index 405480e..c33ba6e 100644
> > --- a/kvm-all.c
> > +++ b/kvm-all.c
> > @@ -774,7 +774,7 @@ static void kvm_set_phys_mem(MemoryRegionSection
> > *section, bool add)
> > mem->memory_size = size;
> > mem->start_addr = start_addr;
> > mem->ram = ram;
> > - mem->flags = kvm_mem_flags(s, log_dirty, readonly_flag);
> > + mem->flags = kvm_mem_flags(s, log_dirty, false);
> >
> > err = kvm_set_user_memory_region(s, mem);
> > if (err) {
> >
> > I can provide more details if needed.
>
> I don't think you mentioned how it fails. Does KVM crash? Is an error
> message printed? Does the VM reset, or just hang?
>
No QEMU or kvm crashes, no error message printed, I mean it just hangs,
even no BIOS information are printed.
And "top" shows QEMU consumes 100% cpu.
When I define DEBUG_KVM in kvm-all.c, and run QEMU(this time I boot a
normal OS disk),
# x86_64-softmmu/qemu-system-x86_64 -enable-kvm -hda
/mnt/nfs/Images/debian-append.img
kvm_init_vcpu
kvm_cpu_exec()
handle_io
handle_io
handle_io
handle_io
Only 4 debug messages(handle_io) are printed, then nothing is shown, and
"top" shows QEMU process uses 100% CPU.
Another strange thing is that VM can boot normally on my laptop(with a
gentoo kernel 3.8.1 installed and same QEMU binary).
So I suspect the kernel is the root cause of this problem. I will try again
after upgrading kernel to 3.9.
> -Jordan
>
--
Best Regards,
Dunrong Huang
Homepage: http://mathslinux.org
[-- Attachment #2: Type: text/html, Size: 8901 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] VM can not boot after commit 235e898
2013-06-05 2:44 ` Dunrong Huang
@ 2013-06-05 7:34 ` Dunrong Huang
2013-07-24 9:58 ` Alexander Graf
1 sibling, 0 replies; 20+ messages in thread
From: Dunrong Huang @ 2013-06-05 7:34 UTC (permalink / raw)
To: Jordan Justen; +Cc: Paolo Bonzini, qemu-devel, Gleb Natapov, Jordan Justen
[-- Attachment #1: Type: text/plain, Size: 6323 bytes --]
On Wed, Jun 5, 2013 at 10:44 AM, Dunrong Huang <riegamaths@gmail.com> wrote:
>
>
> On Wed, Jun 5, 2013 at 1:03 AM, Jordan Justen <jljusten@gmail.com> wrote:
>
>> On Tue, Jun 4, 2013 at 1:26 AM, Dunrong Huang <riegamaths@gmail.com>
>> wrote:
>> > On Tue, Jun 4, 2013 at 3:51 PM, Gleb Natapov <gleb@redhat.com> wrote:
>> >> On Tue, Jun 04, 2013 at 03:47:47PM +0800, Dunrong Huang wrote:
>> >> > On Tue, Jun 4, 2013 at 2:47 PM, Paolo Bonzini <pbonzini@redhat.com>
>> >> > wrote:
>> >> >
>> >> > > Il 04/06/2013 05:47, Dunrong Huang ha scritto:
>> >> > > >
>> >> > > > QEMU command:
>> >> > > > ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024
>> debian-append.img
>> >> > > >
>> >> > > > git bisect tells that the following commit causes this bug:
>> >> > > >
>> >> > > > commit 235e8982ad393e5611cb892df54881c872eea9e1
>> >> > > > Author: Jordan Justen <jordan.l.justen@intel.com
>> >> > > > <mailto: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.
>> >> > > >
>> >> > > > After reverting this commit, VM can boot normally.
>> >> > >
>> >> > > A patch is queued for that. Using kernel 3.8 or reverting the
>> commit
>> >> > > will both work.
>> >> > >
>> >> > Ok, thanks for information, I will try it.
>> >> >
>> >> The fix is 651eb0f4 and you claim it is still fails for you. This is
>> >> strange because the commit fixed the problem for everyone else. Can you
>> >> double check that you are testing the right commit and you recompiled
>> >> and reinstalled?
>> >
>> >
>> > I am sure 651eb0f4 does not fix this problem.
>> >
>> > My test environment is below:
>> >
>> > * config.log:
>> > # head -n 2 config.log
>> > # QEMU configure log 2013年 06月 04日 星期二 16:12:59 CST
>> > # Configured with: './configure' '--prefix=/root/usr' '--enable-kvm'
>> > '--enable-werror' '--enable-debug' '--enable-debug-tcg'
>> > '--enable-debug-info' '--enable-sdl' '--enable-gtk' '--enable-virtfs'
>> > '--enable-vnc' '--enable-mixemu' '--enable-vnc-tls' '--enable-vnc-sasl'
>> > '--enable-vnc-jpeg' '--enable-vnc-png' '--enable-vnc-ws'
>> '--enable-curses'
>> > '--enable-curl' '--enable-nptl' '--enable-system' '--enable-user'
>> > '--enable-linux-user' '--enable-guest-base' '--enable-uuid'
>> '--enable-vde'
>> > '--enable-linux-aio' '--enable-cap-ng' '--enable-attr' '--enable-docs'
>> > '--enable-vhost-net' '--enable-spice' '--enable-usb-redir'
>> > '--enable-smartcard-nss' '--enable-tpm' '--enable-guest-agent'
>> > '--target-list=x86_64-softmmu'
>> >
>> > * kernel version:
>> > # uname -a
>> > Linux gentoo-company 3.8.2-gentoo #1 SMP Fri Mar 8 11:44:36 CST 2013
>> x86_64
>> > Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux
>>
>> You were using a >3.8 kernel originally? (Someone mentioned trying a
>> 3.8 kernel, and I think that is when you went to 3.8.)
>>
>> yes, I have been using kernel 3.8.2 lately, not because of Paolo's
> suggestion.
>
>> > * details of git tree:
>> > # git log HEAD --oneline
>> > 1713924 gtk: don't use g_object_unref on GdkCursor
>> > 41686a9 gtk: don't resize window when enabling scaling
>> > 651eb0f fix double free the memslot in kvm_set_phys_mem
>> > 25b4833 configure: Report unknown target names more helpfully
>> > 6e92f82 configure: Autogenerate default target list
>> > 0ded1fe Merge remote-tracking branch 'pmaydell/arm-devs.next' into
>> staging
>> > 95669e6 i.MX: Improve EPIT timer code.
>> > 6539ed2 exynos4210.c: register rom_mem for memory migration
>> >
>> >
>> > * QEMU command line:
>> > x86_64-softmmu/qemu-system-x86_64 -enable-kvm -cdrom
>> > /mnt/nfs/Images/ISO/ubuntu-12.04-dvd-amd64.iso
>>
>> FWIW, I've been able to boot the 11.10 iso when booted to a 3.9 kernel.
>>
>> Does it only fail after you boot the OS? If you just run KVM without a
>> disk, so only seabios runs, is it okay?
>>
>
> It fails even runing without any parameters, like:
> x86_64-softmmu/qemu-system-x86_64 -enable-kvm
>
> No BIOS information printed, just a black screen is shown.
>
>
>> > After disable KVM_MEM_READONLY flag like below, VM can boot normally.
>> > diff --git a/kvm-all.c b/kvm-all.c
>> > index 405480e..c33ba6e 100644
>> > --- a/kvm-all.c
>> > +++ b/kvm-all.c
>> > @@ -774,7 +774,7 @@ static void kvm_set_phys_mem(MemoryRegionSection
>> > *section, bool add)
>> > mem->memory_size = size;
>> > mem->start_addr = start_addr;
>> > mem->ram = ram;
>> > - mem->flags = kvm_mem_flags(s, log_dirty, readonly_flag);
>> > + mem->flags = kvm_mem_flags(s, log_dirty, false);
>> >
>> > err = kvm_set_user_memory_region(s, mem);
>> > if (err) {
>> >
>> > I can provide more details if needed.
>>
>> I don't think you mentioned how it fails. Does KVM crash? Is an error
>> message printed? Does the VM reset, or just hang?
>>
>
> No QEMU or kvm crashes, no error message printed, I mean it just hangs,
> even no BIOS information are printed.
> And "top" shows QEMU consumes 100% cpu.
>
> When I define DEBUG_KVM in kvm-all.c, and run QEMU(this time I boot a
> normal OS disk),
> # x86_64-softmmu/qemu-system-x86_64 -enable-kvm -hda
> /mnt/nfs/Images/debian-append.img
> kvm_init_vcpu
> kvm_cpu_exec()
> handle_io
> handle_io
> handle_io
> handle_io
>
> Only 4 debug messages(handle_io) are printed, then nothing is shown, and
> "top" shows QEMU process uses 100% CPU.
>
>
> Another strange thing is that VM can boot normally on my laptop(with a
> gentoo kernel 3.8.1 installed and same QEMU binary).
> So I suspect the kernel is the root cause of this problem. I will try
> again after upgrading kernel to 3.9.
>
After upgrading kernel from 3.8.2 to 3.9.4, this problem goes way. So this
bug must have been fixed in kernel 3.9.
Thank you all for replies!
>
>
>> -Jordan
>>
>
>
>
>
--
Best Regards,
Dunrong Huang
Homepage: http://mathslinux.org
[-- Attachment #2: Type: text/html, Size: 9844 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] VM can not boot after commit 235e898
2013-06-05 2:44 ` Dunrong Huang
2013-06-05 7:34 ` Dunrong Huang
@ 2013-07-24 9:58 ` Alexander Graf
2013-07-24 15:16 ` Paolo Bonzini
1 sibling, 1 reply; 20+ messages in thread
From: Alexander Graf @ 2013-07-24 9:58 UTC (permalink / raw)
To: Dunrong Huang
Cc: Anthony Liguori, Gleb Natapov, Jordan Justen,
qemu-devel Developers, Hannes Reinecke, Paolo Bonzini,
Jordan Justen
On 05.06.2013, at 04:44, Dunrong Huang wrote:
>
>
> On Wed, Jun 5, 2013 at 1:03 AM, Jordan Justen <jljusten@gmail.com> wrote:
> On Tue, Jun 4, 2013 at 1:26 AM, Dunrong Huang <riegamaths@gmail.com> wrote:
> > On Tue, Jun 4, 2013 at 3:51 PM, Gleb Natapov <gleb@redhat.com> wrote:
> >> On Tue, Jun 04, 2013 at 03:47:47PM +0800, Dunrong Huang wrote:
> >> > On Tue, Jun 4, 2013 at 2:47 PM, Paolo Bonzini <pbonzini@redhat.com>
> >> > wrote:
> >> >
> >> > > Il 04/06/2013 05:47, Dunrong Huang ha scritto:
> >> > > >
> >> > > > QEMU command:
> >> > > > ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 debian-append.img
> >> > > >
> >> > > > git bisect tells that the following commit causes this bug:
> >> > > >
> >> > > > commit 235e8982ad393e5611cb892df54881c872eea9e1
> >> > > > Author: Jordan Justen <jordan.l.justen@intel.com
> >> > > > <mailto: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.
> >> > > >
> >> > > > After reverting this commit, VM can boot normally.
> >> > >
> >> > > A patch is queued for that. Using kernel 3.8 or reverting the commit
> >> > > will both work.
> >> > >
> >> > Ok, thanks for information, I will try it.
> >> >
> >> The fix is 651eb0f4 and you claim it is still fails for you. This is
> >> strange because the commit fixed the problem for everyone else. Can you
> >> double check that you are testing the right commit and you recompiled
> >> and reinstalled?
> >
> >
> > I am sure 651eb0f4 does not fix this problem.
> >
> > My test environment is below:
> >
> > * config.log:
> > # head -n 2 config.log
> > # QEMU configure log 2013年 06月 04日 星期二 16:12:59 CST
> > # Configured with: './configure' '--prefix=/root/usr' '--enable-kvm'
> > '--enable-werror' '--enable-debug' '--enable-debug-tcg'
> > '--enable-debug-info' '--enable-sdl' '--enable-gtk' '--enable-virtfs'
> > '--enable-vnc' '--enable-mixemu' '--enable-vnc-tls' '--enable-vnc-sasl'
> > '--enable-vnc-jpeg' '--enable-vnc-png' '--enable-vnc-ws' '--enable-curses'
> > '--enable-curl' '--enable-nptl' '--enable-system' '--enable-user'
> > '--enable-linux-user' '--enable-guest-base' '--enable-uuid' '--enable-vde'
> > '--enable-linux-aio' '--enable-cap-ng' '--enable-attr' '--enable-docs'
> > '--enable-vhost-net' '--enable-spice' '--enable-usb-redir'
> > '--enable-smartcard-nss' '--enable-tpm' '--enable-guest-agent'
> > '--target-list=x86_64-softmmu'
> >
> > * kernel version:
> > # uname -a
> > Linux gentoo-company 3.8.2-gentoo #1 SMP Fri Mar 8 11:44:36 CST 2013 x86_64
> > Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux
>
> You were using a >3.8 kernel originally? (Someone mentioned trying a
> 3.8 kernel, and I think that is when you went to 3.8.)
>
> yes, I have been using kernel 3.8.2 lately, not because of Paolo's suggestion.
> > * details of git tree:
> > # git log HEAD --oneline
> > 1713924 gtk: don't use g_object_unref on GdkCursor
> > 41686a9 gtk: don't resize window when enabling scaling
> > 651eb0f fix double free the memslot in kvm_set_phys_mem
> > 25b4833 configure: Report unknown target names more helpfully
> > 6e92f82 configure: Autogenerate default target list
> > 0ded1fe Merge remote-tracking branch 'pmaydell/arm-devs.next' into staging
> > 95669e6 i.MX: Improve EPIT timer code.
> > 6539ed2 exynos4210.c: register rom_mem for memory migration
> >
> >
> > * QEMU command line:
> > x86_64-softmmu/qemu-system-x86_64 -enable-kvm -cdrom
> > /mnt/nfs/Images/ISO/ubuntu-12.04-dvd-amd64.iso
>
> FWIW, I've been able to boot the 11.10 iso when booted to a 3.9 kernel.
>
> Does it only fail after you boot the OS? If you just run KVM without a
> disk, so only seabios runs, is it okay?
>
> It fails even runing without any parameters, like:
> x86_64-softmmu/qemu-system-x86_64 -enable-kvm
>
> No BIOS information printed, just a black screen is shown.
>
>
> > After disable KVM_MEM_READONLY flag like below, VM can boot normally.
> > diff --git a/kvm-all.c b/kvm-all.c
> > index 405480e..c33ba6e 100644
> > --- a/kvm-all.c
> > +++ b/kvm-all.c
> > @@ -774,7 +774,7 @@ static void kvm_set_phys_mem(MemoryRegionSection
> > *section, bool add)
> > mem->memory_size = size;
> > mem->start_addr = start_addr;
> > mem->ram = ram;
> > - mem->flags = kvm_mem_flags(s, log_dirty, readonly_flag);
> > + mem->flags = kvm_mem_flags(s, log_dirty, false);
> >
> > err = kvm_set_user_memory_region(s, mem);
> > if (err) {
> >
> > I can provide more details if needed.
>
> I don't think you mentioned how it fails. Does KVM crash? Is an error
> message printed? Does the VM reset, or just hang?
>
> No QEMU or kvm crashes, no error message printed, I mean it just hangs, even no BIOS information are printed.
> And "top" shows QEMU consumes 100% cpu.
>
> When I define DEBUG_KVM in kvm-all.c, and run QEMU(this time I boot a normal OS disk),
> # x86_64-softmmu/qemu-system-x86_64 -enable-kvm -hda /mnt/nfs/Images/debian-append.img
> kvm_init_vcpu
> kvm_cpu_exec()
> handle_io
> handle_io
> handle_io
> handle_io
>
> Only 4 debug messages(handle_io) are printed, then nothing is shown, and "top" shows QEMU process uses 100% CPU.
After this we're running in an endless loop of:
qemu-system-x86-9298 [003] ...1 162090.918845: kvm_emulate_insn: f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
qemu-system-x86-9298 [003] d..2 162090.918846: kvm_entry: vcpu 0
(qemu) x /i $pc
0x00000000000fc489: ljmpl $0x8,$0xfc491
With current master, qemu-system-x86_64 -enable-kvm is broken on at least 3.7 kernels (openSUSE 12.3).
Gleb, I don't remember all the glorious details of ljmpl, but would it have to raise an MMIO request for a read-only memory slot which it fails to do?
Alex
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] VM can not boot after commit 235e898
2013-07-24 9:58 ` Alexander Graf
@ 2013-07-24 15:16 ` Paolo Bonzini
2013-07-24 15:21 ` Gleb Natapov
0 siblings, 1 reply; 20+ messages in thread
From: Paolo Bonzini @ 2013-07-24 15:16 UTC (permalink / raw)
To: Alexander Graf
Cc: Anthony Liguori, Gleb Natapov, Jordan Justen,
qemu-devel Developers, Dunrong Huang, Hannes Reinecke,
Jordan Justen
Il 24/07/2013 11:58, Alexander Graf ha scritto:
>> > No QEMU or kvm crashes, no error message printed, I mean it just hangs, even no BIOS information are printed.
>> > And "top" shows QEMU consumes 100% cpu.
>> >
>> > When I define DEBUG_KVM in kvm-all.c, and run QEMU(this time I boot a normal OS disk),
>> > # x86_64-softmmu/qemu-system-x86_64 -enable-kvm -hda /mnt/nfs/Images/debian-append.img
>> > kvm_init_vcpu
>> > kvm_cpu_exec()
>> > handle_io
>> > handle_io
>> > handle_io
>> > handle_io
>> >
>> > Only 4 debug messages(handle_io) are printed, then nothing is shown, and "top" shows QEMU process uses 100% CPU.
> After this we're running in an endless loop of:
>
> qemu-system-x86-9298 [003] ...1 162090.918845: kvm_emulate_insn: f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
> qemu-system-x86-9298 [003] d..2 162090.918846: kvm_entry: vcpu 0
>
> (qemu) x /i $pc
> 0x00000000000fc489: ljmpl $0x8,$0xfc491
>
> With current master, qemu-system-x86_64 -enable-kvm is broken on at least 3.7 kernels (openSUSE 12.3).
>
> Gleb, I don't remember all the glorious details of ljmpl, but would it have to raise an MMIO request for a read-only memory slot which it fails to do?
The point of KVM_CAP_READONLY_MEM should be that it doesn't.
So, even without debugging it, I guess we need a KVM_CAP_READONLY_MEM2
or something like that.
Paolo
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] VM can not boot after commit 235e898
2013-07-24 15:16 ` Paolo Bonzini
@ 2013-07-24 15:21 ` Gleb Natapov
2013-07-24 15:31 ` Alexander Graf
0 siblings, 1 reply; 20+ messages in thread
From: Gleb Natapov @ 2013-07-24 15:21 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Anthony Liguori, Jordan Justen, Alexander Graf, Dunrong Huang,
qemu-devel Developers, Hannes Reinecke, Jordan Justen
On Wed, Jul 24, 2013 at 05:16:09PM +0200, Paolo Bonzini wrote:
> Il 24/07/2013 11:58, Alexander Graf ha scritto:
> >> > No QEMU or kvm crashes, no error message printed, I mean it just hangs, even no BIOS information are printed.
> >> > And "top" shows QEMU consumes 100% cpu.
> >> >
> >> > When I define DEBUG_KVM in kvm-all.c, and run QEMU(this time I boot a normal OS disk),
> >> > # x86_64-softmmu/qemu-system-x86_64 -enable-kvm -hda /mnt/nfs/Images/debian-append.img
> >> > kvm_init_vcpu
> >> > kvm_cpu_exec()
> >> > handle_io
> >> > handle_io
> >> > handle_io
> >> > handle_io
> >> >
> >> > Only 4 debug messages(handle_io) are printed, then nothing is shown, and "top" shows QEMU process uses 100% CPU.
> > After this we're running in an endless loop of:
> >
> > qemu-system-x86-9298 [003] ...1 162090.918845: kvm_emulate_insn: f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
> > qemu-system-x86-9298 [003] d..2 162090.918846: kvm_entry: vcpu 0
> >
> > (qemu) x /i $pc
> > 0x00000000000fc489: ljmpl $0x8,$0xfc491
> >
> > With current master, qemu-system-x86_64 -enable-kvm is broken on at least 3.7 kernels (openSUSE 12.3).
> >
> > Gleb, I don't remember all the glorious details of ljmpl, but would it have to raise an MMIO request for a read-only memory slot which it fails to do?
>
> The point of KVM_CAP_READONLY_MEM should be that it doesn't.
>
Yes, it should not. Can you provide complete trace of kvm and kvmmmu
event up until failure?
--
Gleb.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] VM can not boot after commit 235e898
2013-07-24 15:21 ` Gleb Natapov
@ 2013-07-24 15:31 ` Alexander Graf
2013-07-24 16:17 ` Gleb Natapov
0 siblings, 1 reply; 20+ messages in thread
From: Alexander Graf @ 2013-07-24 15:31 UTC (permalink / raw)
To: Gleb Natapov
Cc: Anthony Liguori, Jordan Justen, qemu-devel Developers,
Dunrong Huang, Hannes Reinecke, Paolo Bonzini, Jordan Justen
On 07/24/2013 05:21 PM, Gleb Natapov wrote:
> On Wed, Jul 24, 2013 at 05:16:09PM +0200, Paolo Bonzini wrote:
>> Il 24/07/2013 11:58, Alexander Graf ha scritto:
>>>>> No QEMU or kvm crashes, no error message printed, I mean it just hangs, even no BIOS information are printed.
>>>>> And "top" shows QEMU consumes 100% cpu.
>>>>>
>>>>> When I define DEBUG_KVM in kvm-all.c, and run QEMU(this time I boot a normal OS disk),
>>>>> # x86_64-softmmu/qemu-system-x86_64 -enable-kvm -hda /mnt/nfs/Images/debian-append.img
>>>>> kvm_init_vcpu
>>>>> kvm_cpu_exec()
>>>>> handle_io
>>>>> handle_io
>>>>> handle_io
>>>>> handle_io
>>>>>
>>>>> Only 4 debug messages(handle_io) are printed, then nothing is shown, and "top" shows QEMU process uses 100% CPU.
>>> After this we're running in an endless loop of:
>>>
>>> qemu-system-x86-9298 [003] ...1 162090.918845: kvm_emulate_insn: f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
>>> qemu-system-x86-9298 [003] d..2 162090.918846: kvm_entry: vcpu 0
>>>
>>> (qemu) x /i $pc
>>> 0x00000000000fc489: ljmpl $0x8,$0xfc491
>>>
>>> With current master, qemu-system-x86_64 -enable-kvm is broken on at least 3.7 kernels (openSUSE 12.3).
>>>
>>> Gleb, I don't remember all the glorious details of ljmpl, but would it have to raise an MMIO request for a read-only memory slot which it fails to do?
>> The point of KVM_CAP_READONLY_MEM should be that it doesn't.
>>
> Yes, it should not. Can you provide complete trace of kvm and kvmmmu
> event up until failure?
Sure! These are all trace events up to the loop that I was able to fetch
from the "kvm" and "kvmmmu" event bucket in /sys/kernel/debug/tracing.
qemu-system-x86-13149 [001] ...1 185370.437938: kvm_set_irq: gsi 8
level 0 source 0
qemu-system-x86-13149 [001] ...2 185370.437942: kvm_pic_set_irq: chip
1 pin 0 (edge)
qemu-system-x86-13149 [001] ...2 185370.437943: kvm_ioapic_set_irq:
pin 8 dst 0 vec=0 (Fixed|physical|edge|masked)
qemu-system-x86-13149 [001] ...1 185370.437945: kvm_set_irq: gsi 4
level 0 source 0
qemu-system-x86-13149 [001] ...2 185370.437946: kvm_pic_set_irq: chip
0 pin 4 (edge)
qemu-system-x86-13149 [001] ...2 185370.437946: kvm_ioapic_set_irq:
pin 4 dst 0 vec=0 (Fixed|physical|edge|masked)
qemu-system-x86-13149 [001] ...1 185370.437947: kvm_set_irq: gsi 1
level 0 source 0
qemu-system-x86-13149 [001] ...2 185370.437947: kvm_pic_set_irq: chip
0 pin 1 (edge)
qemu-system-x86-13149 [001] ...2 185370.437948: kvm_ioapic_set_irq:
pin 1 dst 0 vec=0 (Fixed|physical|edge|masked)
qemu-system-x86-13149 [001] ...1 185370.437948: kvm_set_irq: gsi 12
level 0 source 0
qemu-system-x86-13149 [001] ...2 185370.437948: kvm_pic_set_irq: chip
1 pin 4 (edge)
qemu-system-x86-13149 [001] ...2 185370.437949: kvm_ioapic_set_irq:
pin 12 dst 0 vec=0 (Fixed|physical|edge|masked)
qemu-system-x86-13149 [001] ...1 185370.437949: kvm_set_irq: gsi 1
level 0 source 0
qemu-system-x86-13149 [001] ...2 185370.437949: kvm_pic_set_irq: chip
0 pin 1 (edge)
qemu-system-x86-13149 [001] ...2 185370.437949: kvm_ioapic_set_irq:
pin 1 dst 0 vec=0 (Fixed|physical|edge|masked)
qemu-system-x86-13149 [001] ...1 185370.437950: kvm_set_irq: gsi 12
level 0 source 0
qemu-system-x86-13149 [001] ...2 185370.437950: kvm_pic_set_irq: chip
1 pin 4 (edge)
qemu-system-x86-13149 [001] ...2 185370.437950: kvm_ioapic_set_irq:
pin 12 dst 0 vec=0 (Fixed|physical|edge|masked)
qemu-system-x86-13149 [001] ...1 185370.438050: kvm_set_irq: gsi 0
level 0 source 0
qemu-system-x86-13149 [001] ...2 185370.438051: kvm_pic_set_irq: chip
0 pin 0 (edge)
qemu-system-x86-13149 [001] ...2 185370.438051: kvm_ioapic_set_irq:
pin 2 dst 0 vec=0 (Fixed|physical|edge|masked)
qemu-system-x86-13149 [001] ...1 185370.438052: kvm_set_irq: gsi 0
level 0 source 0
qemu-system-x86-13149 [001] ...2 185370.438052: kvm_pic_set_irq: chip
0 pin 0 (edge)
qemu-system-x86-13149 [001] ...2 185370.438052: kvm_ioapic_set_irq:
pin 2 dst 0 vec=0 (Fixed|physical|edge|masked)
qemu-system-x86-13149 [001] ...1 185370.438052: kvm_set_irq: gsi 0
level 0 source 0
qemu-system-x86-13149 [001] ...2 185370.438053: kvm_pic_set_irq: chip
0 pin 0 (edge)
qemu-system-x86-13149 [001] ...2 185370.438053: kvm_ioapic_set_irq:
pin 2 dst 0 vec=0 (Fixed|physical|edge|masked)
qemu-system-x86-13150 [000] ...2 185370.441730: kvm_mmu_get_page: sp
gfn 0 4 q0 direct wux !nxe root 0 sync new
qemu-system-x86-13150 [000] ...2 185370.441734: kvm_fpu: load
qemu-system-x86-13150 [000] d..2 185370.441734: kvm_entry: vcpu 0
qemu-system-x86-13150 [000] d..2 185370.441738: kvm_exit: reason
EPT_VIOLATION rip 0xfff0 info 81 0
qemu-system-x86-13150 [000] ...1 185370.441739: kvm_page_fault:
address feffc000 error_code 81
qemu-system-x86-13150 [000] ...2 185370.441746: kvm_mmu_get_page: sp
gfn 0 3 q0 direct wux !nxe root 0 sync new
qemu-system-x86-13150 [000] ...2 185370.441748: kvm_mmu_get_page: sp
gfn c0000 2 q0 direct wux !nxe root 0 sync new
qemu-system-x86-13150 [000] ...2 185370.441749: kvm_mmu_get_page: sp
gfn fee00 1 q0 direct wux !nxe root 0 sync new
qemu-system-x86-13150 [000] d..2 185370.441752: kvm_entry: vcpu 0
qemu-system-x86-13150 [000] d..2 185370.441757: kvm_exit: reason
EPT_VIOLATION rip 0xfff0 info 184 0
qemu-system-x86-13150 [000] ...1 185370.441757: kvm_page_fault:
address ffff0 error_code 184
qemu-system-x86-13150 [000] ...2 185370.441760: kvm_mmu_get_page: sp
gfn 0 2 q0 direct wux !nxe root 0 sync new
qemu-system-x86-13150 [000] ...2 185370.441761: kvm_mmu_get_page: sp
gfn 0 1 q0 direct wux !nxe root 0 sync new
qemu-system-x86-13150 [000] d..2 185370.441762: kvm_entry: vcpu 0
qemu-system-x86-13150 [000] d..2 185370.441763: kvm_exit: reason
EPT_VIOLATION rip 0xe05b info 184 0
qemu-system-x86-13150 [000] ...1 185370.441763: kvm_page_fault:
address fe05b error_code 184
qemu-system-x86-13150 [000] d..2 185370.441764: kvm_entry: vcpu 0
qemu-system-x86-13150 [000] d..2 185370.441765: kvm_exit: reason
EPT_VIOLATION rip 0xe05b info 181 0
qemu-system-x86-13150 [000] ...1 185370.441765: kvm_page_fault:
address fd094 error_code 181
qemu-system-x86-13150 [000] d..2 185370.441766: kvm_entry: vcpu 0
qemu-system-x86-13150 [000] d..2 185370.441767: kvm_exit: reason
EPT_VIOLATION rip 0xc45e info 184 0
qemu-system-x86-13150 [000] ...1 185370.441767: kvm_page_fault:
address fc45e error_code 184
qemu-system-x86-13150 [000] d..2 185370.441768: kvm_entry: vcpu 0
qemu-system-x86-13150 [000] d..2 185370.441769: kvm_exit: reason
EPT_VIOLATION rip 0xc469 info 181 0
qemu-system-x86-13150 [000] ...1 185370.441769: kvm_page_fault:
address feffd066 error_code 181
qemu-system-x86-13150 [000] d..2 185370.441771: kvm_entry: vcpu 0
qemu-system-x86-13150 [000] d..2 185370.441772: kvm_exit: reason
IO_INSTRUCTION rip 0xc469 info 700040 0
qemu-system-x86-13150 [000] ...1 185370.441773: kvm_pio: pio_write at
0x70 size 1 count 1
qemu-system-x86-13150 [000] ...1 185370.441775: kvm_userspace_exit:
reason KVM_EXIT_IO (2)
qemu-system-x86-13150 [000] ...2 185370.441776: kvm_fpu: unload
qemu-system-x86-13150 [000] d..2 185370.441787: kvm_entry: vcpu 0
qemu-system-x86-13150 [000] d..2 185370.441788: kvm_exit: reason
IO_INSTRUCTION rip 0xc46b info 710048 0
qemu-system-x86-13150 [000] ...1 185370.441794: kvm_emulate_insn:
f0000:c46b:e4 71 (real)
qemu-system-x86-13150 [000] ...1 185370.441796: kvm_pio: pio_read at
0x71 size 1 count 1
qemu-system-x86-13150 [000] ...1 185370.441797: kvm_userspace_exit:
reason KVM_EXIT_IO (2)
qemu-system-x86-13150 [000] d..2 185370.441804: kvm_entry: vcpu 0
qemu-system-x86-13150 [000] d..2 185370.441805: kvm_exit: reason
IO_INSTRUCTION rip 0xc46d info 920048 0
qemu-system-x86-13150 [000] ...1 185370.441806: kvm_emulate_insn:
f0000:c46d:e4 92 (real)
qemu-system-x86-13150 [000] ...1 185370.441807: kvm_pio: pio_read at
0x92 size 1 count 1
qemu-system-x86-13150 [000] ...1 185370.441807: kvm_userspace_exit:
reason KVM_EXIT_IO (2)
qemu-system-x86-13150 [000] d..2 185370.441810: kvm_entry: vcpu 0
qemu-system-x86-13150 [000] d..2 185370.441811: kvm_exit: reason
IO_INSTRUCTION rip 0xc471 info 920040 0
qemu-system-x86-13150 [000] ...1 185370.441811: kvm_pio: pio_write at
0x92 size 1 count 1
qemu-system-x86-13150 [000] ...1 185370.441811: kvm_userspace_exit:
reason KVM_EXIT_IO (2)
qemu-system-x86-13150 [000] d..2 185370.441813: kvm_entry: vcpu 0
qemu-system-x86-13150 [000] d..2 185370.441814: kvm_exit: reason
EXCEPTION_NMI rip 0xc473 info 0 80000b0d
qemu-system-x86-13150 [000] ...1 185370.441817: kvm_emulate_insn:
f0000:c473:2e 0f 01 1e e0 d3 (real)
qemu-system-x86-13150 [000] d..2 185370.441819: kvm_entry: vcpu 0
qemu-system-x86-13150 [000] d..2 185370.441820: kvm_exit: reason
EXCEPTION_NMI rip 0xc479 info 0 80000b0d
qemu-system-x86-13150 [000] ...1 185370.441821: kvm_emulate_insn:
f0000:c479:2e 0f 01 16 a0 d3 (real)
qemu-system-x86-13150 [000] d..2 185370.441822: kvm_entry: vcpu 0
qemu-system-x86-13150 [000] d..2 185370.441823: kvm_exit: reason
EXCEPTION_NMI rip 0xc47f info 0 80000b0d
qemu-system-x86-13150 [000] ...1 185370.441824: kvm_emulate_insn:
f0000:c47f:0f 20 c0 (real)
qemu-system-x86-13150 [000] d..2 185370.441825: kvm_entry: vcpu 0
qemu-system-x86-13150 [000] d..2 185370.441826: kvm_exit: reason
EXCEPTION_NMI rip 0xc486 info 0 80000b0d
qemu-system-x86-13150 [000] ...1 185370.441826: kvm_emulate_insn:
f0000:c486:0f 22 c0 (real)
qemu-system-x86-13150 [000] d..2 185370.441829: kvm_entry: vcpu 0
qemu-system-x86-13150 [000] ...1 185370.441830: kvm_emulate_insn:
f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
qemu-system-x86-13150 [000] d..2 185370.441833: kvm_entry: vcpu 0
qemu-system-x86-13150 [000] ...1 185370.441833: kvm_emulate_insn:
f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
qemu-system-x86-13150 [000] d..2 185370.441834: kvm_entry: vcpu 0
qemu-system-x86-13150 [000] ...1 185370.441835: kvm_emulate_insn:
f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
qemu-system-x86-13150 [000] d..2 185370.441835: kvm_entry: vcpu 0
qemu-system-x86-13150 [000] ...1 185370.441836: kvm_emulate_insn:
f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
qemu-system-x86-13150 [000] d..2 185370.441836: kvm_entry: vcpu 0
[...]
Alex
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] VM can not boot after commit 235e898
2013-07-24 15:31 ` Alexander Graf
@ 2013-07-24 16:17 ` Gleb Natapov
2013-07-24 16:26 ` Alexander Graf
0 siblings, 1 reply; 20+ messages in thread
From: Gleb Natapov @ 2013-07-24 16:17 UTC (permalink / raw)
To: Alexander Graf
Cc: Anthony Liguori, Jordan Justen, qemu-devel Developers,
Dunrong Huang, Hannes Reinecke, Paolo Bonzini, Jordan Justen
On Wed, Jul 24, 2013 at 05:31:14PM +0200, Alexander Graf wrote:
> On 07/24/2013 05:21 PM, Gleb Natapov wrote:
> >On Wed, Jul 24, 2013 at 05:16:09PM +0200, Paolo Bonzini wrote:
> >>Il 24/07/2013 11:58, Alexander Graf ha scritto:
> >>>>>No QEMU or kvm crashes, no error message printed, I mean it just hangs, even no BIOS information are printed.
> >>>>>And "top" shows QEMU consumes 100% cpu.
> >>>>>
> >>>>>When I define DEBUG_KVM in kvm-all.c, and run QEMU(this time I boot a normal OS disk),
> >>>>># x86_64-softmmu/qemu-system-x86_64 -enable-kvm -hda /mnt/nfs/Images/debian-append.img
> >>>>>kvm_init_vcpu
> >>>>>kvm_cpu_exec()
> >>>>>handle_io
> >>>>>handle_io
> >>>>>handle_io
> >>>>>handle_io
> >>>>>
> >>>>>Only 4 debug messages(handle_io) are printed, then nothing is shown, and "top" shows QEMU process uses 100% CPU.
> >>>After this we're running in an endless loop of:
> >>>
> >>> qemu-system-x86-9298 [003] ...1 162090.918845: kvm_emulate_insn: f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
> >>> qemu-system-x86-9298 [003] d..2 162090.918846: kvm_entry: vcpu 0
> >>>
> >>> (qemu) x /i $pc
> >>> 0x00000000000fc489: ljmpl $0x8,$0xfc491
> >>>
> >>>With current master, qemu-system-x86_64 -enable-kvm is broken on at least 3.7 kernels (openSUSE 12.3).
> >>>
> >>>Gleb, I don't remember all the glorious details of ljmpl, but would it have to raise an MMIO request for a read-only memory slot which it fails to do?
> >>The point of KVM_CAP_READONLY_MEM should be that it doesn't.
> >>
> >Yes, it should not. Can you provide complete trace of kvm and kvmmmu
> >event up until failure?
>
> Sure! These are all trace events up to the loop that I was able to
> fetch from the "kvm" and "kvmmmu" event bucket in
> /sys/kernel/debug/tracing.
>
You should start using trace-cmd :) It even disassembles for you.
> qemu-system-x86-13150 [000] d..2 185370.441825: kvm_entry: vcpu 0
> qemu-system-x86-13150 [000] d..2 185370.441826: kvm_exit: reason EXCEPTION_NMI rip 0xc486 info 0 80000b0d
> qemu-system-x86-13150 [000] ...1 185370.441826: kvm_emulate_insn: f0000:c486:0f 22 c0 (real)
This mov CR0 that sets PE bit.
> qemu-system-x86-13150 [000] d..2 185370.441829: kvm_entry: vcpu 0
> qemu-system-x86-13150 [000] ...1 185370.441830: kvm_emulate_insn: f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
Here jmp is emulated because vcpu state is invalid, but for some reason
emulation does not fail and does not succeed. Never saw such thing
before. Are you saying configuring BIOS memslot differently solves the
problem?
> qemu-system-x86-13150 [000] d..2 185370.441833: kvm_entry: vcpu 0
> qemu-system-x86-13150 [000] ...1 185370.441833: kvm_emulate_insn: f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
> qemu-system-x86-13150 [000] d..2 185370.441834: kvm_entry: vcpu 0
> qemu-system-x86-13150 [000] ...1 185370.441835: kvm_emulate_insn: f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
> qemu-system-x86-13150 [000] d..2 185370.441835: kvm_entry: vcpu 0
> qemu-system-x86-13150 [000] ...1 185370.441836: kvm_emulate_insn: f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
> qemu-system-x86-13150 [000] d..2 185370.441836: kvm_entry: vcpu 0
--
Gleb.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] VM can not boot after commit 235e898
2013-07-24 16:17 ` Gleb Natapov
@ 2013-07-24 16:26 ` Alexander Graf
2013-07-24 16:53 ` Gleb Natapov
0 siblings, 1 reply; 20+ messages in thread
From: Alexander Graf @ 2013-07-24 16:26 UTC (permalink / raw)
To: Gleb Natapov
Cc: Anthony Liguori, Jordan Justen, qemu-devel Developers,
Dunrong Huang, Hannes Reinecke, Paolo Bonzini, Jordan Justen
On 07/24/2013 06:17 PM, Gleb Natapov wrote:
> On Wed, Jul 24, 2013 at 05:31:14PM +0200, Alexander Graf wrote:
>> On 07/24/2013 05:21 PM, Gleb Natapov wrote:
>>> On Wed, Jul 24, 2013 at 05:16:09PM +0200, Paolo Bonzini wrote:
>>>> Il 24/07/2013 11:58, Alexander Graf ha scritto:
>>>>>>> No QEMU or kvm crashes, no error message printed, I mean it just hangs, even no BIOS information are printed.
>>>>>>> And "top" shows QEMU consumes 100% cpu.
>>>>>>>
>>>>>>> When I define DEBUG_KVM in kvm-all.c, and run QEMU(this time I boot a normal OS disk),
>>>>>>> # x86_64-softmmu/qemu-system-x86_64 -enable-kvm -hda /mnt/nfs/Images/debian-append.img
>>>>>>> kvm_init_vcpu
>>>>>>> kvm_cpu_exec()
>>>>>>> handle_io
>>>>>>> handle_io
>>>>>>> handle_io
>>>>>>> handle_io
>>>>>>>
>>>>>>> Only 4 debug messages(handle_io) are printed, then nothing is shown, and "top" shows QEMU process uses 100% CPU.
>>>>> After this we're running in an endless loop of:
>>>>>
>>>>> qemu-system-x86-9298 [003] ...1 162090.918845: kvm_emulate_insn: f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
>>>>> qemu-system-x86-9298 [003] d..2 162090.918846: kvm_entry: vcpu 0
>>>>>
>>>>> (qemu) x /i $pc
>>>>> 0x00000000000fc489: ljmpl $0x8,$0xfc491
>>>>>
>>>>> With current master, qemu-system-x86_64 -enable-kvm is broken on at least 3.7 kernels (openSUSE 12.3).
>>>>>
>>>>> Gleb, I don't remember all the glorious details of ljmpl, but would it have to raise an MMIO request for a read-only memory slot which it fails to do?
>>>> The point of KVM_CAP_READONLY_MEM should be that it doesn't.
>>>>
>>> Yes, it should not. Can you provide complete trace of kvm and kvmmmu
>>> event up until failure?
>> Sure! These are all trace events up to the loop that I was able to
>> fetch from the "kvm" and "kvmmmu" event bucket in
>> /sys/kernel/debug/tracing.
>>
> You should start using trace-cmd :) It even disassembles for you.
>
>> qemu-system-x86-13150 [000] d..2 185370.441825: kvm_entry: vcpu 0
>> qemu-system-x86-13150 [000] d..2 185370.441826: kvm_exit: reason EXCEPTION_NMI rip 0xc486 info 0 80000b0d
>> qemu-system-x86-13150 [000] ...1 185370.441826: kvm_emulate_insn: f0000:c486:0f 22 c0 (real)
> This mov CR0 that sets PE bit.
>
>> qemu-system-x86-13150 [000] d..2 185370.441829: kvm_entry: vcpu 0
>> qemu-system-x86-13150 [000] ...1 185370.441830: kvm_emulate_insn: f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
> Here jmp is emulated because vcpu state is invalid, but for some reason
> emulation does not fail and does not succeed. Never saw such thing
It works just fine with older QEMU:
qemu-system-x86-9448 [001] d..2 162748.223935: kvm_exit: reason
IO_INSTRUCTION rip 0xc471 info 920040 0
qemu-system-x86-9448 [001] ...1 162748.223936: kvm_pio: pio_write at
0x92 size 1 count 1
qemu-system-x86-9448 [001] ...1 162748.223936: kvm_userspace_exit:
reason KVM_EXIT_IO (2)
qemu-system-x86-9448 [001] d..2 162748.223939: kvm_entry: vcpu 0
qemu-system-x86-9448 [001] d..2 162748.223940: kvm_exit: reason
EXCEPTION_NMI rip 0xc473 info 0 80000b0d
qemu-system-x86-9448 [001] ...1 162748.223942: kvm_emulate_insn:
f0000:c473:2e 0f 01 1e e0 d3 (real)
qemu-system-x86-9448 [001] d..2 162748.223945: kvm_entry: vcpu 0
qemu-system-x86-9448 [001] d..2 162748.223946: kvm_exit: reason
EXCEPTION_NMI rip 0xc479 info 0 80000b0d
qemu-system-x86-9448 [001] ...1 162748.223947: kvm_emulate_insn:
f0000:c479:2e 0f 01 16 a0 d3 (real)
qemu-system-x86-9448 [001] d..2 162748.223948: kvm_entry: vcpu 0
qemu-system-x86-9448 [001] d..2 162748.223948: kvm_exit: reason
EXCEPTION_NMI rip 0xc47f info 0 80000b0d
qemu-system-x86-9448 [001] ...1 162748.223950: kvm_emulate_insn:
f0000:c47f:0f 20 c0 (real)
qemu-system-x86-9448 [001] d..2 162748.223951: kvm_entry: vcpu 0
qemu-system-x86-9448 [001] d..2 162748.223951: kvm_exit: reason
EXCEPTION_NMI rip 0xc486 info 0 80000b0d
qemu-system-x86-9448 [001] ...1 162748.223952: kvm_emulate_insn:
f0000:c486:0f 22 c0 (real)
qemu-system-x86-9448 [001] d..2 162748.223955: kvm_entry: vcpu 0
qemu-system-x86-9448 [001] ...1 162748.223956: kvm_emulate_insn:
f0000:c489:66 ea 91 c4 0f 00 08 00 (prot16)
qemu-system-x86-9448 [001] d..2 162748.223959: kvm_entry: vcpu 0
qemu-system-x86-9448 [001] ...1 162748.223960: kvm_emulate_insn:
0:fc491:b8 10 00 00 00 (prot32)
qemu-system-x86-9448 [001] d..2 162748.223961: kvm_entry: vcpu 0
qemu-system-x86-9448 [001] ...1 162748.223961: kvm_emulate_insn:
0:fc496:8e d8 (prot32)
qemu-system-x86-9448 [001] d..2 162748.223963: kvm_entry: vcpu 0
qemu-system-x86-9448 [001] ...1 162748.223964: kvm_emulate_insn:
0:fc498:8e c0 (prot32)
qemu-system-x86-9448 [001] d..2 162748.223965: kvm_entry: vcpu 0
[...]
> before. Are you saying configuring BIOS memslot differently solves the
> problem?
Git bisect pointed to the commit mentioned in this email. The following
patch also gets me a working guest again:
diff --git a/kvm-all.c b/kvm-all.c
index 4fb4ccb..deca9e5 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -1455,7 +1455,7 @@ int kvm_init(void)
s->irq_set_ioctl = KVM_IRQ_LINE_STATUS;
}
-#ifdef KVM_CAP_READONLY_MEM
+#if 0 //def KVM_CAP_READONLY_MEM
kvm_readonly_mem_allowed =
(kvm_check_extension(s, KVM_CAP_READONLY_MEM) > 0);
#endif
Alex
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] VM can not boot after commit 235e898
2013-07-24 16:26 ` Alexander Graf
@ 2013-07-24 16:53 ` Gleb Natapov
2013-07-24 20:25 ` Alexander Graf
2013-07-24 20:34 ` Andreas Färber
0 siblings, 2 replies; 20+ messages in thread
From: Gleb Natapov @ 2013-07-24 16:53 UTC (permalink / raw)
To: Alexander Graf
Cc: Anthony Liguori, Jordan Justen, qemu-devel Developers,
Dunrong Huang, Hannes Reinecke, Paolo Bonzini, Jordan Justen
On Wed, Jul 24, 2013 at 06:26:41PM +0200, Alexander Graf wrote:
> >before. Are you saying configuring BIOS memslot differently solves the
> >problem?
>
> Git bisect pointed to the commit mentioned in this email. The
> following patch also gets me a working guest again:
>
> diff --git a/kvm-all.c b/kvm-all.c
> index 4fb4ccb..deca9e5 100644
> --- a/kvm-all.c
> +++ b/kvm-all.c
> @@ -1455,7 +1455,7 @@ int kvm_init(void)
> s->irq_set_ioctl = KVM_IRQ_LINE_STATUS;
> }
>
> -#ifdef KVM_CAP_READONLY_MEM
> +#if 0 //def KVM_CAP_READONLY_MEM
> kvm_readonly_mem_allowed =
> (kvm_check_extension(s, KVM_CAP_READONLY_MEM) > 0);
> #endif
>
Can you disable emulate_invalid_state on 3.7? What happens on upstream kernel
(works for me obviously :)).
--
Gleb.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] VM can not boot after commit 235e898
2013-07-24 16:53 ` Gleb Natapov
@ 2013-07-24 20:25 ` Alexander Graf
2013-07-25 11:30 ` Gleb Natapov
2013-07-24 20:34 ` Andreas Färber
1 sibling, 1 reply; 20+ messages in thread
From: Alexander Graf @ 2013-07-24 20:25 UTC (permalink / raw)
To: Gleb Natapov
Cc: Anthony Liguori, Jordan Justen, qemu-devel Developers,
Dunrong Huang, Hannes Reinecke, Paolo Bonzini, Jordan Justen
On 07/24/2013 06:53 PM, Gleb Natapov wrote:
> On Wed, Jul 24, 2013 at 06:26:41PM +0200, Alexander Graf wrote:
>>> before. Are you saying configuring BIOS memslot differently solves the
>>> problem?
>> Git bisect pointed to the commit mentioned in this email. The
>> following patch also gets me a working guest again:
>>
>> diff --git a/kvm-all.c b/kvm-all.c
>> index 4fb4ccb..deca9e5 100644
>> --- a/kvm-all.c
>> +++ b/kvm-all.c
>> @@ -1455,7 +1455,7 @@ int kvm_init(void)
>> s->irq_set_ioctl = KVM_IRQ_LINE_STATUS;
>> }
>>
>> -#ifdef KVM_CAP_READONLY_MEM
>> +#if 0 //def KVM_CAP_READONLY_MEM
>> kvm_readonly_mem_allowed =
>> (kvm_check_extension(s, KVM_CAP_READONLY_MEM)> 0);
>> #endif
>>
> Can you disable emulate_invalid_state on 3.7?
I could only find emulate_invalid_guest_state. I suppose you mean that
one? :)
$ rmmod kvm-intel
$ modprobe kvm-intel emulate_invalid_guest_state=n
$ ./x86_64-softmmu/qemu-system-x86_64 -nographic -kernel /boot/vmlinuz
-append console=ttyS0 -bios pc-bios/bios.bin -enable-kvm
QEMU 1.5.50 monitor - type 'help' for more information
(qemu)
KVM: entry failed, hardware error 0x80000021
If you're running a guest on an Intel machine without unrestricted mode
support, the failure can be most likely due to the guest entering an invalid
state for Intel VT. For example, the guest maybe running in big real mode
which is not supported on less recent Intel processors.
EAX=00000011 EBX=18ae1000 ECX=00006a12 EDX=000fffa9
ESI=07feb50d EDI=00000000 EBP=000069d2 ESP=000069d2
EIP=0000c489 EFL=00010006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =fd39 000fd390 ffffffff 00809300 DPL=0 DS16 [-WA]
CS =f000 000f0000 0000ffff 00009b00 DPL=0 CS16 [-RA]
SS =0000 00000000 0000ffff 00009300 DPL=0 DS16 [-WA]
DS =0030 00000000 ffffffff 00809300 DPL=0 DS16 [-WA]
FS =0030 00000000 ffffffff 00809300 DPL=0 DS16 [-WA]
GS =c900 000c9000 ffffffff 00809300 DPL=0 DS16 [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT= 000fd3a8 00000037
IDT= 000fd3e6 00000000
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000
DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000000
Code=01 1e e0 d3 2e 0f 01 16 a0 d3 0f 20 c0 66 83 c8 01 0f 22 c0 <66> ea
91 c4 0f 00 08 00 b8 10 00 00 00 8e d8 8e c0 8e d0 8e e0 8e e8 89 c8 ff
e2 89 c1 b8
QEMU: Terminated
> What happens on upstream kernel
> (works for me obviously :)).
kvm-kmod from 3.9 works.
Alex
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] VM can not boot after commit 235e898
2013-07-24 16:53 ` Gleb Natapov
2013-07-24 20:25 ` Alexander Graf
@ 2013-07-24 20:34 ` Andreas Färber
1 sibling, 0 replies; 20+ messages in thread
From: Andreas Färber @ 2013-07-24 20:34 UTC (permalink / raw)
To: Gleb Natapov
Cc: Anthony Liguori, Jordan Justen, Alexander Graf, Dunrong Huang,
qemu-devel Developers, Hannes Reinecke, Paolo Bonzini,
Jordan Justen
Am 24.07.2013 18:53, schrieb Gleb Natapov:
> What happens on upstream kernel
> (works for me obviously :)).
3.10.x has been working fine for me on openSUSE 12.3.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Qemu-devel] VM can not boot after commit 235e898
2013-07-24 20:25 ` Alexander Graf
@ 2013-07-25 11:30 ` Gleb Natapov
0 siblings, 0 replies; 20+ messages in thread
From: Gleb Natapov @ 2013-07-25 11:30 UTC (permalink / raw)
To: Alexander Graf
Cc: Anthony Liguori, Jordan Justen, qemu-devel Developers,
Dunrong Huang, Hannes Reinecke, Paolo Bonzini, Jordan Justen
On Wed, Jul 24, 2013 at 10:25:49PM +0200, Alexander Graf wrote:
> On 07/24/2013 06:53 PM, Gleb Natapov wrote:
> >On Wed, Jul 24, 2013 at 06:26:41PM +0200, Alexander Graf wrote:
> >>>before. Are you saying configuring BIOS memslot differently solves the
> >>>problem?
> >>Git bisect pointed to the commit mentioned in this email. The
> >>following patch also gets me a working guest again:
> >>
> >>diff --git a/kvm-all.c b/kvm-all.c
> >>index 4fb4ccb..deca9e5 100644
> >>--- a/kvm-all.c
> >>+++ b/kvm-all.c
> >>@@ -1455,7 +1455,7 @@ int kvm_init(void)
> >> s->irq_set_ioctl = KVM_IRQ_LINE_STATUS;
> >> }
> >>
> >>-#ifdef KVM_CAP_READONLY_MEM
> >>+#if 0 //def KVM_CAP_READONLY_MEM
> >> kvm_readonly_mem_allowed =
> >> (kvm_check_extension(s, KVM_CAP_READONLY_MEM)> 0);
> >> #endif
> >>
> >Can you disable emulate_invalid_state on 3.7?
>
> I could only find emulate_invalid_guest_state. I suppose you mean
> that one? :)
>
That one will do :)
> $ rmmod kvm-intel
> $ modprobe kvm-intel emulate_invalid_guest_state=n
> $ ./x86_64-softmmu/qemu-system-x86_64 -nographic -kernel
> /boot/vmlinuz -append console=ttyS0 -bios pc-bios/bios.bin
> -enable-kvm
> QEMU 1.5.50 monitor - type 'help' for more information
> (qemu)
> KVM: entry failed, hardware error 0x80000021
>
Yeah, emulate_invalid_guest_state=0 was broken for a while. Can you try
applying a4d3326c2de46fd7bcc47d1e8786efccfc152f81 on top of 3.7
and try again with emulate_invalid_guest_state=0?
> >What happens on upstream kernel
> >(works for me obviously :)).
>
> kvm-kmod from 3.9 works.
>
Doing backwards bisect to see where it was fixed would be interesting.
--
Gleb.
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2013-07-25 11:30 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-04 3:47 [Qemu-devel] VM can not boot after commit 235e898 Dunrong Huang
2013-06-04 6:41 ` Jordan Justen
2013-06-04 7:46 ` Dunrong Huang
2013-06-04 6:47 ` Paolo Bonzini
2013-06-04 7:47 ` Dunrong Huang
2013-06-04 7:51 ` Gleb Natapov
2013-06-04 8:26 ` Dunrong Huang
2013-06-04 17:03 ` Jordan Justen
2013-06-05 2:44 ` Dunrong Huang
2013-06-05 7:34 ` Dunrong Huang
2013-07-24 9:58 ` Alexander Graf
2013-07-24 15:16 ` Paolo Bonzini
2013-07-24 15:21 ` Gleb Natapov
2013-07-24 15:31 ` Alexander Graf
2013-07-24 16:17 ` Gleb Natapov
2013-07-24 16:26 ` Alexander Graf
2013-07-24 16:53 ` Gleb Natapov
2013-07-24 20:25 ` Alexander Graf
2013-07-25 11:30 ` Gleb Natapov
2013-07-24 20:34 ` Andreas Färber
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).