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 <da...@gibson.dropbear.id.au> 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