qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] VM can not boot after commit 235e898


From: Alexander Graf
Subject: Re: [Qemu-devel] VM can not boot after commit 235e898
Date: Wed, 24 Jul 2013 11:58:32 +0200

On 05.06.2013, at 04:44, Dunrong Huang wrote:

> 
> 
> On Wed, Jun 5, 2013 at 1:03 AM, Jordan Justen <address@hidden> wrote:
> On Tue, Jun 4, 2013 at 1:26 AM, Dunrong Huang <address@hidden> wrote:
> > On Tue, Jun 4, 2013 at 3:51 PM, Gleb Natapov <address@hidden> 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 <address@hidden>
> >> > 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 <address@hidden
> >> > > > <mailto:address@hidden>>
> >> > > > 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]