Re: [PATCH 10/10] KVM: PPC: Enable the PAPR CAP for Book3S
From: Alexander Graf <hidden>
Date: 2011-08-10 12:29:31
Also in:
kvm
On 08/10/2011 02:26 PM, Paul Mackerras wrote:
On Wed, Aug 10, 2011 at 09:59:41AM +0200, Alexander Graf wrote:quoted
Am 10.08.2011 um 06:42 schrieb Paul Mackerras[off-list ref]:quoted
On Tue, Aug 09, 2011 at 06:31:48PM +0200, Alexander Graf wrote:quoted
Now that Book3S PV mode can also run PAPR guests, we can add a PAPR cap and enable it for all Book3S targets. Enabling that CAP switches KVM into PAPR mode.Don't we want to enable it only for 64-bit hosts? Trying to run a PAPR guest on a 32-bit Book 3S host won't work very well, unless I am missing something...I agree that it doesn't make sense, but if anything we should restrict it to 64-bit _guests_. you can also run 32-bit guests on 64-bit hosts.I had a look in PAPR and I didn't find anything that says the processor has to be 64-bit, so I guess a 32-bit PAPR guest is possible in theory. However, I don't think there are currently any 32-bit PAPR operating systems that would use hcalls.
That's what I figured :). The code flow we're affecting here is pretty much generic.
quoted
And so far, we don't have a single interface setting PVR and PAPR mode at the same time, so you could still enable PAPR with a 64-bit guest CPU and then switch to a 32-bit CPU. It'd be a nightmare to check all configurations on every setter function. Unless... We could introduce a sanity check function that gets executed every time we change PVR or enable PAPR. That could set a variable in the vcpu struct to indicate that the config is ok. We could then check that on vcpu_run.It's probably not worth worrying about it.
Too late, already implemented it :). It really does make sense to have some sort of checking here - even if it only means that our hypercall implementation can't handle it yet or that we didn't test it. And we can put the "HV KVM can only run PAPR" check in there as well. Alex