[Top][All Lists]

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

[Bug 1563152] Re: general protection fault running VirtualBox in KVM gue

From: Thomas Huth
Subject: [Bug 1563152] Re: general protection fault running VirtualBox in KVM guest
Date: Thu, 19 Nov 2020 16:17:26 -0000

The QEMU project is currently considering to move its bug tracking to another 
system. For this we need to know which bugs are still valid and which could be 
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state 
back to "New" within the next 60 days, otherwise this report will be marked as 
"Expired". Or mark it as "Fix Released" if the problem has been solved with a 
newer version of QEMU already. Thank you and sorry for the inconvenience.

** Changed in: qemu
       Status: New => Incomplete

** Changed in: qemu (Ubuntu)
       Status: Confirmed => Incomplete

You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

  general protection fault running VirtualBox in KVM guest

Status in QEMU:
Status in qemu package in Ubuntu:

Bug description:
  I'm trying to run nested VMs using qemu-kvm on the physical host and 
VirtualBox on the guest host:
    * physical host: Ubuntu 14.04 running Linux 4.2.0, qemu-kvm 2.0.0
    * guest host: Ubuntu 16.04 beta 2 running Linux 4.4.0, VirtualBox 5.0.16

  When I try to start up a VirtualBox VM in the guest host, I get a
  general protection fault (see below for dmesg output).  According to
  https://www.virtualbox.org/ticket/14965 this is caused by a bug in

      The problem in more detail:  As written above, VirtualBox tries to
      read the MSR 0x9B (IA32_SMM_MONITOR_CTL).  This is an
      architectural MSR which is present if CPUID.01 / ECX bit 5 or bit
      6 are set (VMX or SMX).  As KVM has nested virtualization enabled
      and therefore pretends to support VT-x, this MSR must be
      accessible and reading from this MSR must not raise a
      #GP.  KVM/QEmu does not behave like real hardware in this case.

  dmesg output:

  SUPR0GipMap: fGetGipCpu=0x3
  general protection fault: 0000 [#1] SMP
  Modules linked in: pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) 
vboxdrv(OE) xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 
iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack 
xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables ppdev kvm_intel kvm 
irqbypass snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core 
snd_hwdep snd_pcm snd_timer i2c_piix4 snd input_leds soundcore joydev 
8250_fintek mac_hid serio_raw pvpanic parport_pc parport ib_iser rdma_cm iw_cm 
ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi 
scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov 
async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 
multipath linear crct10dif_pclmul crc32_pclmul qxl ttm drm_kms_helper 
syscopyarea sysfillrect aesni_intel sysimgblt fb_sys_fops aes_x86_64 lrw 
gf128mul glue_helper ablk_helper cryptd psmouse floppy drm pata_acpi
  CPU: 0 PID: 31507 Comm: EMT Tainted: G           OE   4.4.0-15-generic 
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  task: ffff880034c0a580 ti: ffff880002e00000 task.ti: ffff880002e00000
  RIP: 0010:[<ffffffffc067e506>]  [<ffffffffc067e506>] 0xffffffffc067e506
  RSP: 0018:ffff880002e03d70  EFLAGS: 00010206
  RAX: 00000000000006f0 RBX: 00000000ffffffdb RCX: 000000000000009b
  RDX: 0000000000000000 RSI: ffff880002e03d00 RDI: ffff880002e03cc8
  RBP: ffff880002e03d90 R08: 0000000000000004 R09: 00000000000006f0
  R10: 0000000049656e69 R11: 000000000f8bfbff R12: 0000000000000020
  R13: 0000000000000000 R14: ffffc9000057407c R15: ffffffffc0645260
  FS:  00007f89b8f6b700(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f89b8d10000 CR3: 0000000035ae1000 CR4: 00000000000006f0
   0000000000000000 ffffffff00000000 0000000000000000 0000000000000000
   ffff880002e03db0 ffffffffc0693e93 ffffc90000574010 ffff880035aae550
   ffff880002e03e30 ffffffffc060a3e7 ffff880002e03e10 0000000000000282
  Call Trace:
   [<ffffffffc060a3e7>] ? supdrvIOCtl+0x2de7/0x3250 [vboxdrv]
   [<ffffffffc06035b0>] ? VBoxDrvLinuxIOCtl_5_0_16+0x150/0x250 [vboxdrv]
   [<ffffffff8121e7df>] ? do_vfs_ioctl+0x29f/0x490
   [<ffffffff8106a554>] ? __do_page_fault+0x1b4/0x400
   [<ffffffff8121ea49>] ? SyS_ioctl+0x79/0x90
   [<ffffffff81821ff2>] ? entry_SYSCALL_64_fastpath+0x16/0x71
  Code: 88 e4 fc ff ff b9 3a 00 00 00 0f 32 48 c1 e2 20 89 c0 48 09 d0 48 89 05 
f9 db 0e 00 0f 20 e0 b9 9b 00 00 00 48 89 05 d2 db 0e 00 <0f> 32 48 c1 e2 20 89 
c0 b9 80 00 00 c0 48 09 d0 48 89 05 cb db
  RIP  [<ffffffffc067e506>] 0xffffffffc067e506
   RSP <ffff880002e03d70>
  ---[ end trace b3284b6520f49e0d ]---

To manage notifications about this bug go to:

reply via email to

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