From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [RFC PATCH] kvm: Enable -cpu option to hide KVM Date: Mon, 02 Jun 2014 07:30:21 -0600 Message-ID: <1401715821.9207.20.camel@ul30vt.home> References: <20140601162414.28708.22775.stgit@bling.home> <538C52AF.4010105@msgid.tls.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org To: Michael Tokarev Return-path: Received: from mx1.redhat.com ([209.132.183.28]:28497 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754351AbaFBNac (ORCPT ); Mon, 2 Jun 2014 09:30:32 -0400 In-Reply-To: <538C52AF.4010105@msgid.tls.msk.ru> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, 2014-06-02 at 14:32 +0400, Michael Tokarev wrote: > 01.06.2014 20:25, Alex Williamson =D1=86=D0=BA=D1=89=D0=B5=D1=83: > > The latest Nvidia driver (337.88) specifically checks for KVM as th= e > > hypervisor and reports Code 43 for the driver in a Windows guest wh= en > > found. Removing or changing the KVM signature is sufficient to all= ow > > the driver to load. >=20 > Hmm.. Why does it do such thing? Is it in order to prevent the drive= r > to work in a virtualized windows, ie to prevent vga passthough to wor= k? >=20 > If that's the case, I think it is a lost game. Because they'll be ad= ding > more, cleverer, checks in the next version. Then they'll be pissing off more users and driving them to AMD by doing so. In any case, having the ability to hide the hypervisor seems to stand on it's own. What if we want to test whether a guest behavior is the result of a paravirtual interface? What if a user wants to hide th= e hypervisor in order to further reduce the exposure surface to the VM? There are reasons beyond an arms race with Nvidia to want a feature lik= e this. Thanks, Alex