From: Jamie Lokier <jamie@shareable.org>
To: Avi Kivity <avi@redhat.com>
Cc: Andre Przywara <andre.przywara@amd.com>,
aliguori@us.ibm.com, Paul Brook <paul@codesourcery.com>,
kvm@vger.kernel.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [PATCH 1/2] allow hypervisor CPUID bit to be overriden
Date: Wed, 24 Jun 2009 22:20:41 +0100 [thread overview]
Message-ID: <20090624212041.GB14121@shareable.org> (raw)
In-Reply-To: <4A40BE07.5080906@redhat.com>
Avi Kivity wrote:
> On 06/23/2009 02:31 PM, Paul Brook wrote:
> >On Tuesday 23 June 2009, Avi Kivity wrote:
> >
> >>On 06/23/2009 12:47 AM, Andre Przywara wrote:
> >>
> >>>KVM defaults to the hypervisor CPUID bit to be set, whereas pure QEMU
> >>>clears it. On some occasions one want to set or clear it the other way
> >>>round (for instance to get HyperV running inside a guest).
> >>>Allow the default to be overridden on the command line and fix some
> >>>whitespace damage on the way.
> >>>
> >>It makes sense for qemu to set the hypervisor bit unconditionally. A
> >>guest running under qemu is not bare metal.
> >>
> >
> >I see no reason why a guest has to be told that it's running inside a VM.
> >In principle an appropriately configured qemu should be indistinguishable
> >from
> >real hardware. In practice it's technically infeasible to cover absolutely
> >everything, but if we set this bit we're not even trying.
> >
> >I have no objection to the bit being set by default for the QEMU CPU types.
> >
>
> I agree it's pointless, but it is a Microsoft requirement for passing
> their SVVP tests. Enabling it by default makes life a little easier for
> users who wish to validate their hypervisor and has no drawbacks.
Hold on.
Do the SVVP tests fail on a real (non-virtal) machine then?
Or is QEMU's machine emulation insufficiently accurate?
I see a drawback in setting the bit by default.
Something I expect from an emulator is that it behaves like a real
machine to the extent possible. In particular, guest code which
attempts to check if it's running on a real machine should get the
answer "yes". Unfriendly guest code which pops up a message like
"Sorry I refuse to work for you after 100 hours/ because you are
attempting to run me in a virtual machine, and don't even think of
trying to hide this from me now you know I look for it" should never
do so.
-- Jamie
next prev parent reply other threads:[~2009-06-24 21:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-22 21:47 [Qemu-devel] [PATCH 1/2] allow hypervisor CPUID bit to be overriden Andre Przywara
2009-06-23 10:01 ` [Qemu-devel] " Avi Kivity
2009-06-23 11:31 ` Paul Brook
2009-06-23 11:35 ` Avi Kivity
2009-06-23 11:43 ` Paul Brook
2009-06-24 21:20 ` Jamie Lokier [this message]
2009-06-25 5:23 ` Gleb Natapov
2009-06-23 12:37 ` [Qemu-devel] [PATCH 1/2 v2] " Andre Przywara
2009-06-23 14:17 ` [Qemu-devel] " Anthony Liguori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090624212041.GB14121@shareable.org \
--to=jamie@shareable.org \
--cc=aliguori@us.ibm.com \
--cc=andre.przywara@amd.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).