HP Disables VT On Some Intel Laptops

snoukka writes "I just bought a new HP nx9420 laptop in order to use it with Linux, XEN, and windows on XEN. I was very disappointed when I noticed that the processor had this feature but VT is disabled in BIOS by HP and cannot be enabled! Disabled!? It's like buying a car with turbo and finding out after buying it that this turbo 'feature' was disabled." The forum thread goes back to last August and is still live. The latest post from an HP rep indicates that new firmware for the nx9420 should be available later this week in which the ability to switch on VT is enabled. It's not clear whether other HP products, in which VT was also disabled, will also get new firmware.

Re:VT?

[LunaticTippy]

Virtualization Technology

So does Lenovo...

[mrchaotica]

...on some of their newer Thinkpads [thinkwiki.org]. You'd think that when you're spending $2000 on a "business-class" laptop, you'd get it without any artificial limitations...

Re:VT?

[solevita]

Wikipedia is pretty bad, but with a bit of common sense, you can work out things you didn't know before:

VT [wikipedia.org]!

Re:VT?

[Ironica]

What is VT? That'd be nice to know.

Yes, it would be nice for them to put it right in the /. post, since if you RTFA, you have to get all the way to the *fourth* post in the forum before it's spelled out for you!

(BTW, Virtualization Technology, for those whose browsers are incapable of leaving the slashdot domain.)

VT provides no perf advantage.

[Utopia]

I tried to compare the perf difference with VT enabled & disabled using Virtual PC 2007 RC2 & Vmware Latest Beta.
I was pretty disappointed to find that there is no perf. difference with VT enabled or disabled.

Re:So does Lenovo...

[Utopia]

I brought a Lenovo T60p recently. VT was off by default but can be turned on in the BIOS.

Re:Is this news or a whine?

[mandelbr0t]

Disabled!? It's like buying a car with turbo and finding out after buying it that this turbo 'feature' was disabled.

What's not clear about that? It's accurate, too, since VT is listed as a feature of the chip they were buying and was specifically disabled by HP. If you read the linked forum thread, you will see that the people who got screwed over by this did their research and knew what they wanted. Calling these complaints "whining" really trivializes HP's screw-up.

mandelbr0t

Re:VT provides no perf advantage.

[innosent]

This is not a performance issue. The only "performance" difference here is that with VT, you can run Windows under Xen. Without VT, you cannot, but can still run kernels (Linux/BSD/etc.) which are built to run on the Xen hypervisor. The OP wanted to use it to run Windows and Linux/BSD/etc. under Xen. As Virtual PC and VMWare both do full virtualization, VT will not make a difference, but with Xen's (faster) paravirtualization (which requires cooperation between the VMM and the guest OS), it means that VT can keep Windows in its own domain, so that interrupts and syscalls don't interfere with the hypervisor and other guest OS(s).

Re:So does Lenovo...

[mrchaotica]

After having taken a closer look at the page I linked (because it's been changed since I read it last), I've discovered that my particular model (X60t) at least has a new BIOS out that fixes the problem. : )

This leads me to believe that, at least for Lenovo, it's just that they were presumably in a hurry to get the model released, not that it was intentional crippleware.

One Simple Solution

[Skewray]

Perhaps not quite ready for prime time, but http://freebios.sourceforge.net/ [sourceforge.net] is a nice way to solve this problem. Then if VT doesn't work, you can fix it yourself.

Re:VT provides no perf advantage.

[myowntrueself]

1. I'm not sure that VMWare other than the higher end versions (ie not the free 'server' edition) would be capable of using VT at all; it isn't exactly a hypervisor...

2. From the Xen mailing list re why disk IO (for one thing) *will* be slower in a HVM domain than in a paravirtualised domain:

The reason the emulated IDE controller is quite slow is a consequence of
the emulation. The way it works is that the driver in the HVM domain
writes to the same IO ports that the real device would use. These writes
are intercepted by the hardware support in the processor and a VMEXIT is
issued to "exit the virtual machine" back into the hypervisor. The HV
looks at the "exit reason", and sees that it's an IO WRITE operation.
This operation is then encoded into a small packet and sent to QEMU.
QEMU processes this packet and responds back to HV to say "OK, done
that, you may continue". HV then does a VMRUN (or VMRESUME in the Intel
case) to continue the guest execution, which is probably another IO
instruction to write to the IDE controller. There's a total of 5-6 bytes
written to the IDE controller per transaction, and whilst it's possible
to combine some of these writes into a single write, it's not always
done that way. Once all writes for one transaction are completed, the
QEMU ide emulation code will perform the requested operation (such as
reading or writing a sector). When that is complete, a virtual interrupt
is issued to the guest, and the guest will see this as a "disk done"
interrupt, just like real hardware.

All these steps of IO intercepts takes several thousand cycles, which is
a bit longer than a regular IO write operation would take on the real
hardware, and the system will still need to issue the real IO operations
to perform the REAL hardware read/write corresponding to the virtual
disk (such as reading a file, LVM or physical partition) at some point,
so this is IN ADDITION to the time used by the hypervisor.

Unfortunately, the only possible improvement on this scenario is the
type "virtual-aware" driver that is described below.

[Using a slightly more efficient model than IDE may also help, but
that's going to be marginal compared to the benefits of using a
virtual-aware driver].


(Credit goes to Mats Petersson).

Re:Not surprised...

[spotter]

serious risk? you are probably referring to the "Blue Pill", the Blue is way overblown, wikipedia has a short summary, http://en.wikipedia.org/wiki/Blue_Pill_(malware) [wikipedia.org]

Re: Nothing new...

[Speed Pour]

A little over a year ago I bought an HP laptop (I've forgotten the model) as a gift for my mother. First thing I did after getting it out of the box was wipe it clean of the pre-installed xp home edition and tons of advertising. With a new OS installed, I discovered that the processor, optical drive, and something else (I forget the 3rd item) were scaled down to barely functional speeds. After investigation, I discovered that those bits would not operate without specialized drivers that were not available for download. Further investigation suggests that the drivers may have existed for xp home only, even excluding pro.

Needless to say, the laptop was returned and I called alienware the next day.

Nothing to see here.

[Khyber]

I work as an HP repair tech (currently.) We've had HUNDREDS of laptops sent in for repair for this reason.

It's really sad how HP features things, but disables them. I had to repair a DV9000 with the webcam built-in, because the webcam wasn't seen.

The spot for the webcam to hook up wasn't even tere. HP had installed a de-featured board instead of a fully-featured board.

This is everyday at HP. Nothing to see here, move along.

what most of you don t get about VT security issue

[Anonymous Coward]

As a long time Xen user and one of the very first non Xen developer to run hardware virtualized OS under Xen on Intel hardware, I can say something that most here are missing: if you install Xen as the hypervisor and then launch an unmodified OS, like Windows, using hardware virtualization (you ain't launching an unmodified OS under Xen without hardware virtualization anyway), the unmodified OS will *not* see a VT-capable system. Which means that if you install Xen in the first place, as a knowledgeable Xen/Linux user, it's gonna be *very* hard for a Windows virus to be able to attack Xen/Linux. You can run Xen under Xen (that's an indisputable fact, I've done it) but you fscking can NOT run an hardware virtualized system under another hardware virtualized system (that is another undisputable fact). Now conceptually there may be an workable exploit one day, but being able to attack the hypervisor from an OS seeing a non-VT system would be one heck of a hack (a bit like being able to crash a computer configured as a completely passive sniffer behind a one-way ethernet cable or a shomiti tap). In other words, it is very unlikely to happen anytime soon.

Moreover saying that an hypotetical "hypervisor exploit" would be undetectable is complete rubbish bullshit: it's not any more difficult to detect than to detect a root exploit. Anyone who consider that scanning a machine from itself is a safe way of detecting malware is a fool anyway. You take the system offline, hook it's hard disk to a known good system (or boot it using a live CD) and voila... Gameover rootkit, game over hypervisor "undetectable" malware.
(and if you want to play the "my servers can't be taken down" I'll fire back with a "what punk, you're telling me you've got a SPOF?").

What Xen buys you if you want, though, is free (from Linux) scanning / SHA1-summing / etc. of Windows systems without the Windows systems even *knowing* it is happening. Game over Windows "rootkits". Plain and simple.

I hope that by now you realize that if you run Xen/Linux then Windows under Xen using VT, it is *impossible* for a virus to act as the hypervisor and then to present you with a 'fake' Xen/Linux hypervisor that would allow you to run Windows. That's how VT in this day and Intel age works. It may change, but as of now: move along, nothing to see here.

(OK, OK, a *really* incredible virus could make you think you're running Windows using HVM though Windows would actually be running under QEMU... But that would be one heck of a hack and you'd notice QEMU's extreme slowness in emulation mode... No accelerated QEMU under Xen).

Hypervisor rootkits can't counter timing-attacks based detection either.

Windows running under Xen is way more secure than running on the bare metal. Dot.

So please, stop all the uninformed "oh my god VT is teh insecure tech!".

To me running Windows under Xen is the most secure thing that happened to Windows in ages (and, no, I wasn't that much of a VMWare fan).

     

Re:So does Lenovo...

[mrchaotica]

According to the page, it's the Z and X series that are affected, not the T series.

A solution exists

[tyler_larson]

I've been running bios version f.22 (12/11/2006) on my intel HP dv2000, and it allows you to enable VT in bios. I had to reboot a few times, but it works correctly now. The download link for this bios ver is listed in TFA near the bottom. It's not an "offical" release from HP, probably an internal testing release, and it's not linked from HP's site.

It's nice to know that they're working on it, though, and they do have a preliminary solution for those of us who REALLY need it.

HA

[Anonymous Coward]

That's nothing. HP sold the ZV6000 laptops as "fully featured" amd64 laptops, but the BIOS disabled Dual Channel memory, and limited it to DDR333 unless you only used 1GB stick of DDR400. They also NEVER provided any x64 drivers for the machine. They also underclocked the Video card, and made the laptop downclock the memory by 5MHz when it was pluged into the outlet(why I will never understand). They also sold x4 DVD burners as x6 and their lightscribe drives had issues with writing CD's at advertised speed.

After that I will never buy another HP.

Re:So does Lenovo...

[jrockway]

You can't blame Lenovo for this. Intel had major problems with making VT work early on, and there are a lot of steppings where it's just plain broken. These companies decided to turn it off for everyone because they don't want to handle all the users complaining that Lenovo sucks because VT is broken. Blame Intel for this one.