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

2013-07-25 Thread Gleb Natapov 
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 0x8021
 
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.

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

2013-07-24 Thread Alexander Graf 

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

 
 
 On Wed, Jun 5, 2013 at 1:03 AM, Jordan Justen jljus...@gmail.com wrote:
 On Tue, Jun 4, 2013 at 1:26 AM, Dunrong Huang riegama...@gmail.com wrote:
  On Tue, Jun 4, 2013 at 3:51 PM, Gleb Natapov g...@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 pbonz...@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.jus...@intel.com
 mailto:jordan.l.jus...@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

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

2013-07-24 Thread Paolo Bonzini 
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: 
 f: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
   0x000fc489:  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

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

2013-07-24 Thread Gleb Natapov 
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: 
  f: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
0x000fc489:  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.

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

2013-07-24 Thread Alexander Graf 

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: 
f: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
   0x000fc489:  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 c 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

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

2013-07-24 Thread Gleb Natapov 
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: 
  f: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
0x000fc489:  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 8b0d
  qemu-system-x86-13150 [000] ...1 185370.441826: kvm_emulate_insn: 
 f: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: 
 f: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: 
 f: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: 
 f: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: 
 f:c489:66 ea 91 c4 0f 00 08 00 (prot16)
  qemu-system-x86-13150 [000] d..2 185370.441836: kvm_entry: vcpu 0

--
Gleb.

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

2013-07-24 Thread Alexander Graf 

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: 
f: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
   0x000fc489:  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 8b0d
  qemu-system-x86-13150 [000] ...1 185370.441826: kvm_emulate_insn: 
f: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: 
f: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 8b0d
 qemu-system-x86-9448  [001] ...1 162748.223942: kvm_emulate_insn: 
f: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 8b0d
 qemu-system-x86-9448  [001] ...1 162748.223947: kvm_emulate_insn: 
f: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 8b0d
 qemu-system-x86-9448  [001] ...1 162748.223950: kvm_emulate_insn: 
f: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 8b0d
 qemu-system-x86-9448  [001] ...1 162748.223952: kvm_emulate_insn: 
f: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: 
f: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 =

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

2013-07-24 Thread Gleb Natapov 
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.

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

2013-07-24 Thread Alexander Graf 

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 0x8021

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=0011 EBX=18ae1000 ECX=6a12 EDX=000fffa9
ESI=07feb50d EDI= EBP=69d2 ESP=69d2
EIP=c489 EFL=00010006 [-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =fd39 000fd390  00809300 DPL=0 DS16 [-WA]
CS =f000 000f  9b00 DPL=0 CS16 [-RA]
SS =   9300 DPL=0 DS16 [-WA]
DS =0030   00809300 DPL=0 DS16 [-WA]
FS =0030   00809300 DPL=0 DS16 [-WA]
GS =c900 000c9000  00809300 DPL=0 DS16 [-WA]
LDT=   8200 DPL=0 LDT
TR =   8b00 DPL=0 TSS32-busy
GDT= 000fd3a8 0037
IDT= 000fd3e6 
CR0=0011 CR2= CR3= CR4=
DR0= DR1= DR2= 
DR3=

DR6=0ff0 DR7=0400
EFER=
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

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

2013-07-24 Thread Andreas Färber 
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

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

2013-06-05 Thread Dunrong Huang 
On Wed, Jun 5, 2013 at 10:44 AM, Dunrong Huang riegama...@gmail.com wrote:



 On Wed, Jun 5, 2013 at 1:03 AM, Jordan Justen jljus...@gmail.com wrote:

 On Tue, Jun 4, 2013 at 1:26 AM, Dunrong Huang riegama...@gmail.com
 wrote:
  On Tue, Jun 4, 2013 at 3:51 PM, Gleb Natapov g...@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 pbonz...@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.jus...@intel.com
 mailto:jordan.l.jus...@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

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

2013-06-04 Thread Jordan Justen 
Fixed in 651eb0f4?

On Mon, Jun 3, 2013 at 8:47 PM, Dunrong Huang riegama...@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.jus...@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

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

2013-06-04 Thread Paolo Bonzini 
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.jus...@intel.com
 mailto:jordan.l.jus...@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

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

2013-06-04 Thread Dunrong Huang 
On Tue, Jun 4, 2013 at 2:41 PM, Jordan Justen jljus...@gmail.com wrote:

 Fixed in 651eb0f4?

No, it still fails.


 On Mon, Jun 3, 2013 at 8:47 PM, Dunrong Huang riegama...@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.jus...@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

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

2013-06-04 Thread Dunrong Huang 
On Tue, Jun 4, 2013 at 2:47 PM, Paolo Bonzini pbonz...@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.jus...@intel.com
  mailto:jordan.l.jus...@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

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

2013-06-04 Thread Gleb Natapov 
On Tue, Jun 04, 2013 at 03:47:47PM +0800, Dunrong Huang wrote:
 On Tue, Jun 4, 2013 at 2:47 PM, Paolo Bonzini pbonz...@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.jus...@intel.com
   mailto:jordan.l.jus...@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.

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

2013-06-04 Thread Dunrong Huang 
On Tue, Jun 4, 2013 at 3:51 PM, Gleb Natapov g...@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 pbonz...@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.jus...@intel.com
mailto:jordan.l.jus...@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

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

2013-06-04 Thread Jordan Justen 
On Tue, Jun 4, 2013 at 1:26 AM, Dunrong Huang riegama...@gmail.com wrote:
 On Tue, Jun 4, 2013 at 3:51 PM, Gleb Natapov g...@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 pbonz...@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.jus...@intel.com
mailto:jordan.l.jus...@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

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

2013-06-04 Thread Dunrong Huang 
On Wed, Jun 5, 2013 at 1:03 AM, Jordan Justen jljus...@gmail.com wrote:

 On Tue, Jun 4, 2013 at 1:26 AM, Dunrong Huang riegama...@gmail.com
 wrote:
  On Tue, Jun 4, 2013 at 3:51 PM, Gleb Natapov g...@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 pbonz...@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.jus...@intel.com
 mailto:jordan.l.jus...@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