VirtualBox

Ticket #3724 (closed defect: wontfix)

Opened 1 year ago

Last modified 3 months ago

Host crash: vboxdrv crashes, when run in VMX mode, together with coLinux

Reported by: Fenix*NBK* Assigned to:
Priority: major Component: other
Version: VirtualBox 2.2.0 Keywords:
Cc: Guest type: other
Host type: other

Description

Hello,

Host: Windows XP, SP2, 32-bit, Intel Core 2 Quad, VirtualBox 2.2.0

Guest: Ubuntu 8.04, 32-bit

I decided to try Ubuntu 8.04 - in both "coLinux" mode and "virtualized" mode side-by-side.

For "coLinux" mode I used "Portable Ubuntu for Windows" distro. (http://portableubuntu.demonccc.com.ar/)

For "virtualized" mode I used VirtualBox 2.2.0. with VT-x enabled.

Running those two solutions together at the same time results in Host Crash with BSOD, if VMX is used by VirtualBox. If running software virtualization, no crash occur.

I cannot blame VirtualBox for it, as I don't know who is responsible for crash, but it would be helpful if VirtualBox checked whenever it is safe to enter VMX mode.

Due to crash, no logs were generated.

-Technologov, 14.4.2009.

Attachments

colinux-0.7.4-log.txt (12.5 kB) - added by Fenix*NBK* on 2009-04-27 00:44:06.
coLinux 0.7.4 rc2 -- /var/log/messages -- before crash

Change History

2009-04-14 09:34:21 changed by sandervl73

We do check if it's safe to enable VT-x. I don't know what this coLinux does though.

2009-04-18 10:09:34 changed by Fenix*NBK*

Could we check what else could be of conflict ? which resources ? (assuming coLinux doesn't enters VMX mode)

2009-04-22 15:09:34 changed by frank

  • priority changed from blocker to major.

2009-04-27 00:43:20 changed by Fenix*NBK*

Host crash deserves higher priority in my opinion.

Added /var/log/messages from coLinux -0.7.4-rc2 before crash.

-Technologov

2009-04-27 00:44:06 changed by Fenix*NBK*

  • attachment colinux-0.7.4-log.txt added.

coLinux 0.7.4 rc2 -- /var/log/messages -- before crash

2009-04-27 00:53:13 changed by Fenix*NBK*

To summarize:

The Good news:

I have added /var/log/messages from coLinux -0.7.4-rc2 before crash.

The Bad news:

Crash is so hard that no core dumps get generated. Mini dumps generation is set, but there are no mini-dumps from year 2009 exists in "\WINDOWS\Minidump".

..and The ugly:

I have no idea what to do next.

-Technologov

2009-04-29 11:24:59 changed by Fenix*NBK*

We have opened a new bug report at coLinux bugzilla: coLinux bug report

-Technologov

2009-05-14 11:31:41 changed by sandervl73

  • status changed from new to closed.
  • resolution set to wontfix.

Same happens with MS VirtualPC apparently. See http://sourceforge.net/tracker/?func=detail&atid=622063&aid=1959846&group_id=98788

So it looks like it's their bug or the coLinux driver does things that are not allowed in VMX root mode. Either way not much we can do about it.

(follow-up: ↓ 9 ) 2009-05-14 11:33:30 changed by sandervl73

coLinux can easily see if VMX root is active on the CPU by checking X86_CR4_VMXE (bit 13 in CR4).

(in reply to: ↑ 8 ) 2009-05-17 13:48:21 changed by HenryN

Replying to sandervl73:

coLinux can easily see if VMX root is active on the CPU by checking X86_CR4_VMXE (bit 13 in CR4).

Thanks sandervl73 for pointing to this bit. Checking X86_CR4_VMXE would help to avoid crashing the host. But this does not help to running coLinux. While switching from Windows host to Linux Guest coLinux needs to clear CR4 and disable paging. Both would GP-fault the host, if VMX is running.

Can we disable VMX for short time while the coLinux machine is running, and can we restore the VMX running state later?

2009-05-17 13:54:27 changed by Fenix*NBK*

sandervl73: HenryN is a core developer of coLinux.

HenryN: sandervl73 is a core developer of VirtualBox.

I really hope two Open-Source drivers needs to "co"-exists together, and find status-quo. All-in-all that's where "co" in coLinux comes from in the first place, isn't it?

-Technologov

2009-05-17 15:47:03 changed by sandervl73

You can disable VMX root mode if you want to, but you'll have to restore it exactly as it was. Unfortunately Intel designed VT-x in this way; no such issues exist with AMD-V.

We perform similar checks to see if somebody else has activated VMX root mode and simply refuse to run in that case. VirtualBox only activates VMX root mode when it's running VMs, so refusing to run and issuing a warning might be sufficient.

2009-12-17 10:46:01 changed by sandervl73

VirtualBox 3.1.0 has changed the way VMX and AMD-V are used. (at least for Windows hosts) It only turns on VMX root mode on the cpu that is executing guest code and turns it back off again afterwards.

The above mentioned conflict should no longer exist as of 3.1.2. I strongly suggest you implement the VMX root mode check anyway to prevent crashes.

2009-12-17 10:53:04 changed by Fenix*NBK*

coLinux 0.7.5 check if someone uses VMX mode, and refuses to run.

See: http://colinux.wikia.com/wiki/Version_0.7.5

Anyway it may make sense to test VBox 3.1.2 together with problematic drivers (VirtualPC 5.1/2004, or coLinux 0.7.3/4)

-Technologov


Contact – Privacy policy