On 24.10.2011, at 16:08, David Gibson wrote: > [snip] >>>> 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? >> >> Thinking about it a bit more ... Why do we need to check the host's >> capability to do VMX/VSX/DFP? Shouldn't the PVR already tell us >> everything we need to know? > > Well.. not necessarily. First there's the possibility of a CPU that's > theoretically capable of VSX or DFP, but where the administrator has > disabled it in firmware.
Oh you can disable it in firmware? Then we should take it from the dt if available, yes. > Second, if we add approximate PVR matching > (which I'd like to do), then we should trust the host information over > the table, because we could actually be dealing with a diffferent > revision to the one we got from the table. Yeah, for fuzzy matching we want it. I agree. > >> We're still missing some way for KVM to tell us what it can >> virtualize to the guest, but for now we assume that anything we >> throw at it works anyways. > > Right. I think we'll hneed to do that on a feature by feature basis > as we discover things that can't be KVM virtualized. I will send a > patch that deals with the masking for features that TCG can't emulate. Thanks :). Alex
