Thanks David and Zalton for the awesome explanations. They're very helpful to us!
-Thanks, Wayne Li On Thu, Dec 12, 2019 at 9:49 PM David Gibson <da...@gibson.dropbear.id.au> wrote: > On Thu, Dec 12, 2019 at 10:40:44AM -0600, Wayne Li wrote: > > Dear David Gibson, > > > > I know you are under no obligation to respond, but if it's possible for > you > > to find the time to respond to my question, I would be extremely > grateful. > > My team at Boeing has been stuck trying to get KVM working for our > project > > for the last few months. A good explanation of why this isn't possible > > would be absolutely critical. > > As you can see from that diagram, the history ppc CPUs is quite a bit > more diverse than x86. Although they're all very similar from the > point of view of userspace code, they're quite different for > privileged kernel code: they have different MMUs, different privileged > registers amongst other things. > > Because of this there are several different KVM implementations. > > 1) KVM HV > > This one uses the virtualization facilities of BookS CPUs (present > since POWER4 / 970, but only well supported from POWER7 onwards). > Those don't allow much to virtualize the guest cpu model, so it > assumes the guest cpu is the same as the host. > > So, both your guest and host CPUs rule this one out. > > 2) Book3E KVM > > Uses the virtualization features of recent enough Freescale Book E > CPUs. I don't know a lot about this or its limitations. The e6500 > might well have these features, but I'm pretty sure it can only > emulate BookE cpus for the guest. > > So, your guest rules this one out. > > 3) KVM PR > > This one operates by running the entire guest in user mode, and > emulating all privileged instructions. It's slow (relative to > hardware assisted KVM models), but it's flexible. > > In theory, this one can do what you want, but there are a bunch of > caveats: > > * Emulating all the privileged instructions for a whole bunch of cpu > variants is a huge task, and KVM PR is now barely maintained. There > are lots of gaps in coverage. > > * I'm not sure if it was ever really implemented for BookE hosts. > > * Although there aren't many, there are a few differences between > userland instructions between cpu variants, mostly because of new > additions. I think 7457 is an old enough design that this probably > won't cause you troube, but I'm not certain. > > > > > > > -Thanks, Wayne Li > > > > On Thu, Dec 12, 2019 at 1:17 AM Paolo Bonzini <pbonz...@redhat.com> > wrote: > > > > > On 12/12/19 02:59, Wayne Li wrote: > > > > We wrote a project that is created on top of the QEMU source code; it > > > > calls functions from the QEMU code. I run the executable created by > > > > compiling that project/QEMU code. Anyway, looking at the following > 0> > > documentation: > > > > > > > > https://www.kernel.org/doc/Documentation/powerpc/cpu_families.txt > > > > > > > > It looks like the PowerPC 7457 is Book3S and the PowerPC e6500 is > > > > BookE. Is that why you think I require a Book3S KVM? Exactly why do > > > > you feel this way? Also would that mean my team would need to go and > > > > buy a board with a Book3S processor? > > > > > > CCing the PPC maintainer. There are aspects of BookE and Book3S that > > > are different and not really interchangeable in the privileged > interface. > > > > > > Paolo > > > > > > > -Thanks!, Wayne Li > > > > > > > > From my understanding > > > > > > > > On Wed, Dec 11, 2019 at 7:16 PM Paolo Bonzini <pbonz...@redhat.com > > > > <mailto:pbonz...@redhat.com>> wrote: > > > > > > > > On 11/12/19 22:23, Wayne Li wrote: > > > > > > > > > > Now I am fairly sure KVM is actually enabled on the system. > > > Finding > > > > > that out was another story that spanned a couple of months. > But > > > long > > > > > story short, lsmod doesn't show that the KVM kernel module is > > > > running. > > > > > But that's because KVM is built-in and it can't actually be > built > > > as a > > > > > loadable kernel module in this particular system. > > > > > > > > > > So I'm not really sure what could be the problem. Though I was > > > > thinking > > > > > if I understood the error better that might help? Following > the > > > > code I > > > > > see that the "Missing PVR setting capability." is called when a > > > > variable > > > > > called "cap_segstate" is 0: > > > > > > > > > > if (!cap_segstate) { > > > > > fprintf(stderr, "kvm error: missing PVR setting > > > > capability\n"); > > > > > return -ENOSYS; > > > > > } > > > > > > > > > > And the cap_segstate variable is set by the following function: > > > > > > > > > > cap_segstate = kvm_check_extension(s, KVM_CAP_PPC_SEGSTATE); > > > > > > > > You are not saying how you are running QEMU. I think you are > using a > > > > CPU model that requires a Book3S KVM. > > > > > > > > Paolo > > > > > > > > > > > > -- > 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 >
