On Tue, 2014-08-12 at 01:53 +0200, Alexander Graf wrote:
>
> > Am 12.08.2014 um 01:36 schrieb Scott Wood <scottwood@xxxxxxxxxxxxx>:
> >
> >> On Wed, 2014-08-06 at 19:33 +0300, Mihai Caraman wrote:
> >> @@ -390,19 +400,30 @@ static void kvmppc_core_vcpu_free_e500mc(struct kvm_vcpu *vcpu)
> >>
> >> static int kvmppc_core_init_vm_e500mc(struct kvm *kvm)
> >> {
> >> - int lpid;
> >> + int i, lpid;
> >>
> >> - lpid = kvmppc_alloc_lpid();
> >> - if (lpid < 0)
> >> - return lpid;
> >> + /* The lpid pool supports only 2 entries now */
> >> + if (threads_per_core > 2)
> >> + return -ENOMEM;
> >> +
> >> + /* Each VM allocates one LPID per HW thread index */
> >> + for (i = 0; i < threads_per_core; i++) {
> >> + lpid = kvmppc_alloc_lpid();
> >> + if (lpid < 0)
> >> + return lpid;
> >> +
> >> + kvm->arch.lpid_pool[i] = lpid;
> >> + }
> >
> > Wouldn't it be simpler to halve the size of the lpid pool that the
> > allocator sees, and just OR in the high bit based on the low bit of the
> > cpu number?
>
> Heh, I wrote the same and then removed the section from my reply again. It wouldn't really make that much of a difference if you think it through completely.
>
> But yes, it certainly would be quite a bit more natural. I'm ok either way.
It's not a huge difference, but it would at least get rid of some of the
ifdeffing in the headers. It'd also be nicer when debugging to have the
LPIDs correlated.
-Scott
--
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
