From: David Gibson <david@gibson.dropbear.id.au>
To: Alexander Graf <agraf@suse.de>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [0/3] pseries: RFC: Advertise host CPU capabilties to guest
Date: Fri, 30 Sep 2011 19:00:13 +1000 [thread overview]
Message-ID: <20110930090013.GI4512@yookeroo.fritz.box> (raw)
In-Reply-To: <79DDF028-E5CE-4FBE-8EFF-FD7784A6E182@suse.de>
On Fri, Sep 30, 2011 at 10:20:14AM +0200, Alexander Graf wrote:
>
> Am 30.09.2011 um 09:50 schrieb David Gibson <david@gibson.dropbear.id.au>:
>
> > This series contains some patches which, when using KVM, gather
> > information about the capabilities of the host CPU and advertise them
> > to the guest system when using the pseries machine. Specifically it
> > does this for whether the CPU supports VMX, VSX and/or DFP
> > instructions, and for the CPUs supported page sizes.
> >
> > The VSX and DFP portions of this were posted earlier, and I've fixed
> > the minor comments which people made. This leaves one objection from
> > Alex Graf, that whether the features are advertised should also depend
> > on the target CPU selected in qemu. A similar objection may apply to
> > the pagesizes patch. I guess the idea is to "clamp" the advertised
> > capabilities to those permitted by the selected target CPU, but I'm
> > not entirely sure what the logic here should be.
> >
> > Frankly, particularly in the case of KVM Book3S-HV, I'm not terribly
> > convinced that attempting to make the guest CPU appear different from
> > the host CPU is terribly meaningful. These patches as they stand have
> > the advantage that future, roughly compatible CPUs should Just Work
> > with these capabilities advertised in the correct cases. Alex, can
> > you advise what sort of logic you'd like here.
>
>
> Yes, very simple. I want you to create a CPU type 'host', similar to
> how x86 does it. That should be the default CPU type for KVM with
> the pseries machine.
Ah, ok. I didn't realize x86 did that, but I'd been thinking
something like that would make more sense. I'm away for the next
week, but I'll look at this when I get the chance.
> You can also add a check in-kernel that verifies if guest PVR ==
> host PVR for HV mode. That way you ensure that -cpu host is always
> used there. If you later add compat modes, you can check them there,
> but still have -cpu xxx available to tell all pieces of the kvm/qemu
> chain what to use.
Ok.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
prev parent reply other threads:[~2011-09-30 9:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-30 7:50 [Qemu-devel] [0/3] pseries: RFC: Advertise host CPU capabilties to guest David Gibson
2011-09-30 7:50 ` [Qemu-devel] [PATCH 1/3] ppc: Generalize the kvmppc_get_clockfreq() function David Gibson
2011-09-30 18:06 ` Alexander Graf
2011-10-11 4:29 ` David Gibson
2011-09-30 7:50 ` [Qemu-devel] [PATCH 2/3] pseries: Add device tree properties for VMX/VSX and DFP under kvm David Gibson
2011-09-30 7:50 ` [Qemu-devel] [PATCH 3/3] pseries: Correctly create ibm, segment-page-sizes property David Gibson
2011-10-07 7:20 ` Alexander Graf
2011-09-30 8:20 ` [Qemu-devel] [0/3] pseries: RFC: Advertise host CPU capabilties to guest Alexander Graf
2011-09-30 9:00 ` David Gibson [this message]
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=20110930090013.GI4512@yookeroo.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=agraf@suse.de \
--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).