Re: [Qemu-ppc] [PATCH] pseries: Correct vmx/dfp handling in both KVM and TCG cases

[David Gibson]

On Thu, Oct 20, 2011 at 07:40:00PM -0700, Alexander Graf wrote:
> On 20.10.2011, at 17:41, David Gibson <address@hidden> wrote:
> > On Thu, Oct 20, 2011 at 10:12:51AM -0700, Alexander Graf wrote:
> >> On 17.10.2011, at 21:15, David Gibson wrote:
[snip]
> > So, I really don't follow what the logic you want is.  It sounds more
> > like what I have already, so I'm not sure how -cpu host comes into
> > this.
> 
> Well, I want something very simple, layered:
> 
> -cpu host only searches for pvr matches and selects a different CPU
> -type based on this

Hrm, ok, well I can do this if you like, but note that this is quite
different from how -cpu host behaves on x86.  There it builds the CPU
spec from scratch based on querying the host cpuid, rather than
selecting from an existing list of cpus.  I selected from the existing
table based on host PVR because that was the easiest source for some
of the info in the cpu_spec, but my intention was that anything we
_can_ query directly from the host would override the table.

It seems to be your approach is giving up on the possibility of
allowing -cpu host to work (and give you full access to the host
features) when qemu doesn't recognize the precise PVR of the host cpu.

This gets further complicated in the case of the w-i-p patch I have to
properly advertise page sizes, where it's not just presence or absence
of a feature, but the specific SLB and HPTE encodings must be
advertised to the guest.

> We have 2 masks of available flags: TCG emulatable flags and KVM
> virtualizable flags. The KVM flags need to be generated dynamically,
> from the host dt for now. TCG flags are constant.
> 
> Then we always AND the inst feature bits with the mask. This tells
> every other layer what features are available. That way even running
> -cpu G5 on a p7 works properly by not exposing DFP for example.

That case was already fine.

Are you suggesting doing the AND in the per-machine code (so, as we
build the guest dt in the spapr case) or when we build the env->insn_flags
from the spec->insn_flags?

> 
> Based on the inst feature bits we now expose features in the guest dt.
> 
> 
> Simple, eh? :)
> 
> Alex
> 
> > 
> 

-- 
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