On 24.10.2011, at 10:25, Alexander Graf wrote: > > On 23.10.2011, at 22:29, David Gibson wrote: > >> 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. > > Reading through the patch again I think I see your point now :). Yes, the > kvmppc_host_cpu_def function only tries to fetch the host CPU capabilities. > > So yes, there is basically only the masking part with what we can actually > virtualize missing. But for now we can just assume that every feature the > host CPU supports is available. > > I'll apply your patch for now, as it certainly is better than what we had > before.
This breaks on 970mp (PowerStation). kvmppc_get_vmx returns -1 because ibm,vmx doesn't exist in the host dt, but the CPU still supports Altivec. Any alternative way to enumerate VMX availability? Alex
