On 08/10/2011 02:26 PM, Paul Mackerras wrote:
On Wed, Aug 10, 2011 at 09:59:41AM +0200, Alexander Graf wrote:
Am 10.08.2011 um 06:42 schrieb Paul Mackerras<paulus@xxxxxxxxx>:
On Tue, Aug 09, 2011 at 06:31:48PM +0200, Alexander Graf wrote:
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.
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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
