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

[Alexander Graf]

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 :).

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


Alex