Re: Enabling Virtual Machine support
Thank you very much for your advice and interest. HP sales support has yet to get back to me with a list of models that support virtualization. I assume the T9550 model at nearly $2K would do the trick, but that's beyond my budget. I'm simply going to stick with what I bought. My old winXp (to handle payroll) partition could not be booted with my SATA drive. Rather than struggle with drivers, I'm using virtualbox and things seem to be working well. Virtualbox was a great recommendation. -- Lloyd Kvam Venix Corp DLSLUG/GNHLUG library http://dlslug.org/library.html http://www.librarything.com/catalog/dlslug http://www.librarything.com/rsshtml/recent/dlslug http://www.librarything.com/rss/recent/dlslug ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
On 09/28/2009 09:58 AM, Lloyd Kvam wrote: > I was hoping to get myself a laptop where I could simply try VMMs > without having to cross-check my cpuflags against the hardware > requirements of each VMM. The Macbook lines are pretty good in this respect. My about-to-be-sold 2006 MBP has been doing hw-virt for a couple years. One of the situations where the "yes, but they use better components" argument is actually true. Fedora 11 broke EFI-compatible installs, F12 may get it back if it's feature complete by yesterday (didn't check). KVM is pretty nice if you have the hardware - on a Core2Quad with the Redhat VirtIO drivers, Vista is pretty usable: http://blog.bfccomputing.com/articles/2009/09/14/converting-a-windows-vista-kvm-virtual-machine-to-redhat-virtio-drivers But 'small' things like sound, live snapshots, etc. are still very missing. Xen PV is good for all-free solutions but is just now catching up with kernels that aren't 3-years old, non-KVM-Qemu is slow, VirtualBox is nice, and I agree, VMWare Server 2 is a total turkey (I've used it forever, and switched to KVM because of v2). -Bill -- Bill McGonigle, Owner BFC Computing, LLC http://bfccomputing.com/ Telephone: +1.603.448.4440 Email, IM, VOIP: b...@bfccomputing.com VCard: http://bfccomputing.com/vcard/bill.vcf Social networks: bill_mcgonigle/bill.mcgonigle ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
> There was a study published a couple years back that showed > enabling the VT instructions can result in lower performance Heh. The x86 instruction set offers some fancy instructions that are supposed to help you implement an OS by doing (in one swell foop) some fairly involved stuff like dumping all the CPU registers into memory as is common during task switches. I don't know if it's still true but early on some of them were remarkably slower - IIRC sometimes something like an order of magnitude slower - than an equivalent series of well chosen "normal" instructions. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
That's a good clarification. I thought it was important to stress that there are well-performing 32bit x86 guest virtualization hypervisors out there that do not require intel VT or AMD-V, such as VMware's ESX 3.5, ESXi 3.5, workstation products, and current versions of Sun's Virtualbox. For something like a laptop, this may be plenty of support. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
On Mon, Sep 28, 2009 at 2:13 PM, Darrell Michaud wrote: > Just to round out the thread.. > > As people have already stated, the intel VT optimizations are not required > to support virtualization, or even hypervisors. Vmware ESX is an example > of a decent hypervisor that does not require these CPU capabilities to be > present. KVM on the other hand requires either VT or AMD-V to run. > > Just to clarify re: ESX. As of ESX (and ESXi) 4.0 (aka the vSphere suite of products), minimum system requirements are that you must have a 64-bit capable CPU and a minimum of 2GB of RAM. To the point of this thread, if you want to run a 64-bit guest operating system, ESX (and ESXi) *do* require VT extensions. See "Support for 64-Bit Guest Operating Systems" in either the "ESX and vCenter Server Installation Guide" or "ESXi Installable and vCenter Server Setup Guide" available http://www.vmware.com/support/pubs/vs_pages/vsp_pubs_esx40_vc40.html and http://www.vmware.com/support/pubs/vs_pages/vsp_pubs_esxi40_i_vc40.htmlrespectively. -Shawn ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
Just to round out the thread.. As people have already stated, the intel VT optimizations are not required to support virtualization, or even hypervisors. Vmware ESX is an example of a decent hypervisor that does not require these CPU capabilities to be present. KVM on the other hand requires either VT or AMD-V to run. Even when they are enabled, it is not always true that they are a performance win. There was a study published a couple years back that showed enabling the VT instructions can result in lower performance for some use cases, specificallly heavy use of non-memory I/O if I remember clearly. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
> I did not want to eat up people's time with this thread. This thread is interesting and something that I've been meaning to learn more about so I was pleased to have an excuse to dig an old CPU manual out of my desk midden. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
On Mon, 2009-09-28 at 11:25 -0400, Michael ODonnell wrote: > On this busy morning I've only had time to glance at some docs I did not want to eat up people's time with this thread. I've wasted far too much of my own time on this. -- Lloyd Kvam Venix Corp DLSLUG/GNHLUG library http://dlslug.org/library.html http://www.librarything.com/catalog/dlslug http://www.librarything.com/rsshtml/recent/dlslug http://www.librarything.com/rss/recent/dlslug ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
On this busy morning I've only had time to glance at some docs for SVM (Secure Virtual Machine) support but it does appear that in some cases external hardware (in the form of a TPM - the dread Trusted Platform Module) can be involved in the prep and execution of the Secure Loader and, therefore, any subsequent use of (some? all?) VM capabilities. They (AMD Sys Prog Manual circa 2006) also show some pseudocode that seems to indicate that the BIOS (by means I don't yet understand) does have the ability to prevent later use of (some? all?) VM capabilities, with or without a TPM: 15.4 Enabling SVM The VMRUN, VMLOAD, VMSAVE, CLGI, VMMCALL, and INVLPGA instructions can be used when the EFER.SVME is set to 1; otherwise, these instructions generate a #UD exception. The SKINIT and STGI instructions can be used when either the EFER.SVME bit is set to 1 or the ECX.SKINIT bit, as returned by CPUID function 8000_0001h, is set to 1; otherwise, these instructions generate a #UD exception. Before enabling SVM, software should detect whether SVM can be enabled using the following algorithm: if (CPUID 8000_0001.ECX[SVM] == 0) return SVM_NOT_AVAIL; if (VM_CR.SVMDIS == 0) return SVM_ALLOWED; if (CPUID 8000_000A.EDX[SVM_LOCK]==0) return SVM_DISABLED_AT_BIOS_NOT_UNLOCKABLE // the user must change a BIOS setting to enable SVM else return SVM_DISABLED_WITH_KEY; // SVMLock may be unlockable; consult the BIOS or TPM to obtain the key. So I've learned something: it appears that the BIOS can indeed have the final word re: VM regardless of what any subsequent OS or would-be hypervisor might wish, but I don't yet understand the details. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
On Mon, Sep 28, 2009 at 9:06 AM, Tom Buskey wrote: > Ben brings up a good point about a > possible security risk, but motherboard manufactures haven't worried about > it much in the past. I believe it was Intel who crafted that design feature, not the mobo mfgs. So inaction on the part of the mobo and/or BIOS provider means no virtualization. They have to do something to enable it. Beyond that foggy recollection, my knowledge is zero, so I can't say more on this topic in particular. But I will make this general observation: The processor does not exist in a vacuum. A working computer is a system, of which the processor is but one part. If one needs/wants virtualization but one is shopping solely by processor, I wouldn't be surprised to hear things don't work as expected. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
Ben Scott wrote: > On Sun, Sep 27, 2009 at 7:59 PM, Thomas Charron wrote: > >> Intel's VT-x extensions *MUST* be enabled and supported by BIOS. >> I'm not sure why ... >> > > I seem to recall this facet of the design being sold as a security > feature. The scenario given was the entire nominal installed OS > running inside a hostile VM which installed itself as part of some > malware attack. So at boot, the virtualization stuff is disabled by > default. Or something like that. > > FWIW, YMMV, I may be wrong, etc. > > -- Ben > > ___ > gnhlug-discuss mailing list > gnhlug-discuss@mail.gnhlug.org > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/ > > Ok, for the fun of it I ran cpuid on my Acer Aspire 5100 laptop. I'm running Ubuntu 8.10 (32 bit) and VirtualBox 2.2.4 r47978. Here's the output: $ cpuid eax ineax ebx ecx edx 0001 68747541 444d4163 69746e65 0001 00040f82 01020800 2001 178bfbff 8000 8018 68747541 444d4163 69746e65 8001 00040f82 0595 001f ebd3fbff 8002 20444d41 69727554 74286e6f 3620296d 8003 32582034 626f4d20 20656c69 68636554 8004 6f6c6f6e 54207967 30352d4c 8005 ff08ff08 ff20ff20 40020140 40020140 8006 42004200 01008140 8007 003f 8008 3028 0001 8009 800a 0001 0040 800b 800c 800d 800e 800f 8010 8011 8012 8013 8014 8015 8016 8017 8018 Vendor ID: "AuthenticAMD"; CPUID level 1 AMD-specific functions Version 00040f82: Family: 15 Model: 8 [] Standard feature flags 178bfbff: Floating Point Unit Virtual Mode Extensions Debugging Extensions Page Size Extensions Time Stamp Counter (with RDTSC and CR4 disable bit) Model Specific Registers with RDMSR & WRMSR PAE - Page Address Extensions Machine Check Exception COMPXCHG8B Instruction APIC SYSCALL/SYSRET or SYSENTER/SYSEXIT instructions MTRR - Memory Type Range Registers Global paging extension Machine Check Architecture Conditional Move Instruction PAT - Page Attribute Table PSE-36 - Page Size Extensions 19 - reserved MMX instructions FXSAVE/FXRSTOR 25 - reserved 26 - reserved 28 - reserved Generation: 15 Model: 8 Extended feature flags ebd3fbff: Floating Point Unit Virtual Mode Extensions Debugging Extensions Page Size Extensions Time Stamp Counter (with RDTSC and CR4 disable bit) Model Specific Registers with RDMSR & WRMSR PAE - Page Address Extensions Machine Check Exception COMPXCHG8B Instruction APIC SYSCALL/SYSRET or SYSENTER/SYSEXIT instructions MTRR - Memory Type Range Registers Global paging extension Machine Check Architecture Conditional Move Instruction PAT - Page Attribute Table PSE-36 - Page Size Extensions 20 - reserved AMD MMX Instruction Extensions MMX instructions FXSAVE/FXRSTOR 25 - reserved 27 - reserved 29 - reserved 3DNow! Instruction Extensions 3DNow instructions Processor name string: AMD Turion(tm) 64 X2 Mobile Technology TL-50 L1 Cache Information: 2/4-MB Pages: Data TLB: associativity 255-way #entries 8 Instruction TLB: associativity 255-way #entries 8 4-KB Pages: Data TLB: associativity 255-way #entries 32 Instruction TLB: associativity 255-way #entries 32 L1 Data cache: size 64 KB associativity 2-way lines per tag 1 line size 64 L1 Instruction cache: size 64 KB associativity 2-way lines per tag 1 line size 64 L2 Cache Information: 2/4-MB Pages: Data TLB: associativity L2 off #entries 0 Instruction TLB: associativity L2 off #entries 0 4-KB Pages: Data TLB: associativity 2-way #entries 0 Instruction TLB: associativity 2-way #entries 0 size 1 KB associativity L2 off lines per tag 129 line size 64 Advanced Power Management Feature Flags Has temperature sensing diode Supports Frequency ID control Supports Voltage ID control Maximum linear address: 48; maximum phys address 40 This machine is using kvm with VirtualBox and the performance of virtual machines is quite good. Can I assume the virtual mode extension is turned on? -Alex ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
On Mon, Sep 28, 2009 at 9:39 AM, Thomas Charron wrote: > On Mon, Sep 28, 2009 at 9:06 AM, Tom Buskey wrote: > > On Mon, Sep 28, 2009 at 8:17 AM, Jerry Feldman wrote: > > Of all the hypervisors, I feel VirtualBox is the easiest to maintain. > I've > > done VMware Server, ESXi and played with KVM. I wonder about the > > performance differences but not enough to test :-) > > I loved VMWare until the latest free version of VMWare Server 2.x. > I was highly annoyed by the fact that they went over to a Tomcat based > manager. Specifically, if they wanted to do it, for GODS sake change > the ports they're using. I literally gave up trying to get it to > function on my development systems which where running two versions of > Tomcat already. This was on Windows hosts with Linux guests. > FWIW, it looks just like ESX. VMware Server is an advertisement to get you to buy ESX :-) It's very easy to transition VMs between the two. That advantage is diminishing as the VM vendors standardize on OVF or add support for the competitor's formats. > So after my frustration I tried VirtualBox again. I'd tried it in > the past and found it unstable, but the latest versions feel rock > solid, and much faster. Add in the native graphics acceleration, and > it's a win for us at least. > I really like the RDP support in VirtualBox. Right to the BIOS if you need it. With VMware, I need to run the console to get to the BIOS. This ins't in the GPL version though. > Now if only VirtualBox had the same management capabilities, I'd > consider using it on the servers as well. > ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
On Monday 28 September 2009 08:17:38 am Jerry Feldman wrote: > needed because, in general, performance is more critical. I'm not sure > if Virtualbox supports 64-bit guests, but KVM/QEMU and VMWare certainly > do. Both KVM, QEMU, and Virtualbox are released via the GPL license. I'm > not sure about Xen since Citrix bought it, but you need a Xen-enabled > kernel to run Xen. Xen can also run 64-bit guests. And Xen can also run systems without a Xen-enabled kernel using the virtualization instructions and the HVM (hardware virtual machine) loader. I believe the HVM loader is based on QEMU. -N ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
On Mon, 2009-09-28 at 08:17 -0400, Jerry Feldman wrote: > 2. Under Linux your choices for VMMs (Virtual Machine Managers) are > basically KVM/QEMU, QEMU(software), Xen, Virtualbox, and VMWare. Xen > and KVM do use the virtualization hardware. I was hoping to get myself a laptop where I could simply try VMMs without having to cross-check my cpuflags against the hardware requirements of each VMM. -- Lloyd Kvam Venix Corp DLSLUG/GNHLUG library http://dlslug.org/library.html http://www.librarything.com/catalog/dlslug http://www.librarything.com/rsshtml/recent/dlslug http://www.librarything.com/rss/recent/dlslug ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
On Mon, Sep 28, 2009 at 9:06 AM, Tom Buskey wrote: > On Mon, Sep 28, 2009 at 8:17 AM, Jerry Feldman wrote: > Of all the hypervisors, I feel VirtualBox is the easiest to maintain. I've > done VMware Server, ESXi and played with KVM. I wonder about the > performance differences but not enough to test :-) I loved VMWare until the latest free version of VMWare Server 2.x. I was highly annoyed by the fact that they went over to a Tomcat based manager. Specifically, if they wanted to do it, for GODS sake change the ports they're using. I literally gave up trying to get it to function on my development systems which where running two versions of Tomcat already. This was on Windows hosts with Linux guests. So after my frustration I tried VirtualBox again. I'd tried it in the past and found it unstable, but the latest versions feel rock solid, and much faster. Add in the native graphics acceleration, and it's a win for us at least. Now if only VirtualBox had the same management capabilities, I'd consider using it on the servers as well. -- -- Thomas ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
On 09/28/2009 09:06 AM, Tom Buskey wrote: > Of all the hypervisors, I feel VirtualBox is the easiest to maintain. > I've done VMware Server, ESXi and played with KVM. I wonder about the > performance differences but not enough to test :-) I agree. My company uses VMWare Workstation running under a Windows XP host and a RHEL 5.2 guest so that our Financial Engineers can demo our products. One of my coworkers, on my recommendation installed Virtualbox on his home system so his wife could access her company's Intranet (the host OS in this case is Vista with a Windows XP guest). He likes VBox better than VMWare because of the ease of installation and management. -- Jerry Feldman Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846 signature.asc Description: OpenPGP digital signature ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
On Mon, Sep 28, 2009 at 8:17 AM, Jerry Feldman wrote: > > 1. Most systems disable the VT extensions in the BIOS by default (AMD > and Intel)> I have an AMD quad core Opteron with VMX, with a Tyan mother > board. The VMX bit shoed up in the processor flags (/proc/cpuinfo), but > I found it was disabled in the BIOS until I manually turned it on. > > I've always been annoyed by that. By default hyperthreading is usually turned off as well. I know of a few cases where hyperthreading caused problems. I haven't heard of anything where the VT-x/AMD's hardware Virtualization support causes problems. Ben brings up a good point about a possible security risk, but motherboard manufactures haven't worried about it much in the past. > 2. Under Linux your choices for VMMs (Virtual Machine Managers) are > basically KVM/QEMU, QEMU(software), Xen, Virtualbox, and VMWare. Xen and > KVM do use the virtualization hardware. So far, I don't see any need > for virtualization hardware for Virtualbox or the free versions of > VMWare. If you are using virtualization on a server, more homework is > I've found the hardware support speeds up VMware Server and VirtualBox quite a bit. It's definitely worth spending more on the system for. Of course, most recent CPUs have it built in. I think there's also something about the hardware virtualization that enables non XEN kernels (Windows) to run on a XEN server but I'm not sure on that point. There might be something about KVM that requires the hardware too. > needed because, in general, performance is more critical. I'm not sure > if Virtualbox supports 64-bit guests, but KVM/QEMU and VMWare certainly > do. Both KVM, QEMU, and Virtualbox are released via the GPL license. I'm > VirtualBox will support a 64 bit guest with 1 or more CPUs on a 32 bit single CPU host. It will also do OpenGL amd DirectX. It gets updated every month or so with capabilities. > not sure about Xen since Citrix bought it, but you need a Xen-enabled > kernel to run Xen. The KVM modules are bundled with all the recent 2.6 > kernels. The Virtualbox modules generally keep up, but I have had a > kernel update where the VBox module was not updated, but that usually > required a quick yum or apt update. > Of all the hypervisors, I feel VirtualBox is the easiest to maintain. I've done VMware Server, ESXi and played with KVM. I wonder about the performance differences but not enough to test :-) ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
On 09/27/2009 07:36 PM, Michael ODonnell wrote: > Not certain I understand what you're saying but processors in this family > come out of their power-on Reset state in their simplest, least capable > mode - interrupts disabled, MMU disabled, 20bit Real Mode addressing, > etc - and each increase in capability requires a deliberate action on the > part of the system code (typically the BIOS at first, then later the OS). > > Virtual Machine mode is like Virtual 8086 mode in that it's a capability > that must be explicitly enabled once the OS has rigged itself to manage > it; this as opposed to somehow being a permanent, static feature of the > platform or CPU. And also, AFAIK, no external HW support is required > of the platform for VM capabilities to be utilized - if the OS is coded > to support it and the CPU provides it, that's all you (should!) need. > > 1. Most systems disable the VT extensions in the BIOS by default (AMD and Intel)> I have an AMD quad core Opteron with VMX, with a Tyan mother board. The VMX bit shoed up in the processor flags (/proc/cpuinfo), but I found it was disabled in the BIOS until I manually turned it on. 2. Under Linux your choices for VMMs (Virtual Machine Managers) are basically KVM/QEMU, QEMU(software), Xen, Virtualbox, and VMWare. Xen and KVM do use the virtualization hardware. So far, I don't see any need for virtualization hardware for Virtualbox or the free versions of VMWare. If you are using virtualization on a server, more homework is needed because, in general, performance is more critical. I'm not sure if Virtualbox supports 64-bit guests, but KVM/QEMU and VMWare certainly do. Both KVM, QEMU, and Virtualbox are released via the GPL license. I'm not sure about Xen since Citrix bought it, but you need a Xen-enabled kernel to run Xen. The KVM modules are bundled with all the recent 2.6 kernels. The Virtualbox modules generally keep up, but I have had a kernel update where the VBox module was not updated, but that usually required a quick yum or apt update. -- Jerry Feldman Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846 signature.asc Description: OpenPGP digital signature ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
On Sun, Sep 27, 2009 at 7:59 PM, Thomas Charron wrote: > Intel's VT-x extensions *MUST* be enabled and supported by BIOS. > I'm not sure why ... I seem to recall this facet of the design being sold as a security feature. The scenario given was the entire nominal installed OS running inside a hostile VM which installed itself as part of some malware attack. So at boot, the virtualization stuff is disabled by default. Or something like that. FWIW, YMMV, I may be wrong, etc. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
On Sun, Sep 27, 2009 at 7:59 PM, Thomas Charron wrote: > On Sun, Sep 27, 2009 at 7:36 PM, Michael ODonnell > wrote: >> Not certain I understand what you're saying but processors in this family >> come out of their power-on Reset state in their simplest, least capable >> mode - interrupts disabled, MMU disabled, 20bit Real Mode addressing, >> etc - and each increase in capability requires a deliberate action on the >> part of the system code (typically the BIOS at first, then later the OS). >> Virtual Machine mode is like Virtual 8086 mode in that it's a capability >> that must be explicitly enabled once the OS has rigged itself to manage >> it; this as opposed to somehow being a permanent, static feature of the >> platform or CPU. And also, AFAIK, no external HW support is required >> of the platform for VM capabilities to be utilized - if the OS is coded >> to support it and the CPU provides it, that's all you (should!) need. > Intel's VT-x extensions *MUST* be enabled and supported by BIOS. > I'm not sure why, I read it someplace after I bought my laptop and was > trying to find a way around it. Not sure about VT-d. In a quick search, it has something to do with the BIOS setting certain flags within the processor, and then 'locking' the processor, which cannot be undone without a restart. Even enabling the VT bit ion the BIOS requires a hard reset of the system to actually take. -- -- Thomas ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
On Sun, Sep 27, 2009 at 7:36 PM, Michael ODonnell wrote: > Not certain I understand what you're saying but processors in this family > come out of their power-on Reset state in their simplest, least capable > mode - interrupts disabled, MMU disabled, 20bit Real Mode addressing, > etc - and each increase in capability requires a deliberate action on the > part of the system code (typically the BIOS at first, then later the OS). > Virtual Machine mode is like Virtual 8086 mode in that it's a capability > that must be explicitly enabled once the OS has rigged itself to manage > it; this as opposed to somehow being a permanent, static feature of the > platform or CPU. And also, AFAIK, no external HW support is required > of the platform for VM capabilities to be utilized - if the OS is coded > to support it and the CPU provides it, that's all you (should!) need. Intel's VT-x extensions *MUST* be enabled and supported by BIOS. I'm not sure why, I read it someplace after I bought my laptop and was trying to find a way around it. Not sure about VT-d. -- -- Thomas ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
>> So if VM support is enabled by flipping some bit(s) in some CPU >> Control Register(s) I'd assume that a VM-capable OS could flip those >> bits as well as any BIOS code. I suppose it's possible that the CPU >> might first insist on seeing a certain logic level on a certain input >> pin before allowing VM support to be enabled, and only the BIOS >> authors might know how to poke the appropriate values into some secret >> I/O port to do that, but in principle the OS would still be capable of >> doing that if only those magic locations and values were known, yes? > >I believe that the vmx capabilities need to be enabled at power-up. >Once the processor gets to its "normal" state, it is too late. Not certain I understand what you're saying but processors in this family come out of their power-on Reset state in their simplest, least capable mode - interrupts disabled, MMU disabled, 20bit Real Mode addressing, etc - and each increase in capability requires a deliberate action on the part of the system code (typically the BIOS at first, then later the OS). Virtual Machine mode is like Virtual 8086 mode in that it's a capability that must be explicitly enabled once the OS has rigged itself to manage it; this as opposed to somehow being a permanent, static feature of the platform or CPU. And also, AFAIK, no external HW support is required of the platform for VM capabilities to be utilized - if the OS is coded to support it and the CPU provides it, that's all you (should!) need. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Enabling Virtual Machine support
On Sun, 2009-09-27 at 12:43 -0400, Michael ODonnell wrote: > So if VM support is enabled by flipping some bit(s) in some CPU > Control Register(s) I'd assume that a VM-capable OS could flip those > bits as well as any BIOS code. I suppose it's possible that the CPU > might first insist on seeing a certain logic level on a certain input > pin before allowing VM support to be enabled, and only the BIOS > authors might know how to poke the appropriate values into some secret > I/O port to do that, but in principle the OS would still be capable of > doing that if only those magic locations and values were known, yes? > I believe that the vmx capabilities need to be enabled at power-up. Once the processor gets to its "normal" state, it is too late. However, most info that I have found suggests that the vmx flag from /proc/cpuinfo will show even if disabled. I have no vmx flag in cpuinfo. The link I posted earlier suggested that Intel had mislabeled some of their processor capabilities (e.g. P7350, now corrected) on the website to indicate that they supported virtualization when in fact they did not. So I am expecting to find out that the P7550 was another improperly labeled processor. Today's listing indicates virtualization support. Once they get enough grumbles the site will be changed as it was for the P7350 to show . > I, too, would be irritated if I discovered that my mobo designers or > BIOS authors had decided that I was not entitled to enable a perfectly > usable feature that my CPU supported... >-/ So far HP has been responsive, if not yet helpful. I'm hoping I can negotiate some kind of processor exchange if that would solve the issue. -- Lloyd Kvam Venix Corp DLSLUG/GNHLUG library http://dlslug.org/library.html http://www.librarything.com/catalog/dlslug http://www.librarything.com/rsshtml/recent/dlslug http://www.librarything.com/rss/recent/dlslug ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
