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

[David Gibson]

On Thu, Oct 20, 2011 at 11:49:40PM -0700, Alexander Graf wrote:
> 
> On 20.10.2011, at 22:06, David Gibson wrote:
> 
> > 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.
> 
> I disagree :). This is what x86 does:
> 
>   * -cpu host fetches CPUID info from host, puts it into vcpu
>   * vcpu CPUID info gets ANDed with KVM capability CPUIDs
> 
> I want basically the same thing. I want to have 2 different layers
> for 2 different semantics. One for what the host CPU would be able
> to do and one for what we can emulate, and two different steps to
> ensure control over them.
> 
> The thing I think I'm apparently not bringing over yet is that I'm
> more than happy to get rid of the PVR searching step for -cpu host
> and instead use a full host capability inquiry mechanism. But that
> inquiry should indicate what the host CPU can do. It has nothing to
> do with KVM yet. The masking with KVM capabilities should be the
> next separate step.
> 
> My goal is really to separate different layers into actual different
> layers :).

Hrm.  I think I see what you're getting at.  Although nothing in that
patch is about kvm capabilities - it's all about working out what the
host's cpu can do.

> > 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.
> 
> Yup, so we'd read out the host dt to find the host possible
> encodings (probably a bad idea, but that's a different story)

Um, a different story perhaps, but one I kind of need an answer to in
the near future...  I can query the host cpu's page sizes easily
enough, but I'm really not sure where this should be stashed before
filtering as suggested below.

> and
> then ask KVM what encodings it supports and expose the ANDed product
> of them 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?
> 
> I suggest doing that in translate_init.c where we actually build the
> env->insn_flags from the spec.

Ok, that makes sense.

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