[PATCH] ARM: KVM: drop arbitrary limitation to 4 CPU VMs

[Christoffer Dall]

On 16 October 2013 02:49, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 16/10/13 00:21, Christoffer Dall wrote:
>> On Mon, Oct 14, 2013 at 09:43:04AM +0100, Marc Zyngier wrote:
>>> On 13/10/13 02:09, Christoffer Dall wrote:
>>>> On Tue, Oct 08, 2013 at 06:17:08PM +0100, Marc Zyngier wrote:
>>>>> It appears we have an arbitrary limitation where we refuse to
>>>>> create more than 4 virtual A15 in a single VM.
>>>>>
>>>>> This limitation doesn't make much sense (the number 4 probably
>>>>> comes from the maximum number of CPUs in a A15 cluster, but
>>>>> KVM doesn't have any notion of cluster), and directly
>>>>> contradicts CONFIG_MAX_VCPUS.
>>>>
>>>> So this comes from the early days where I looked at the A15 TRM and the
>>>> MPIDR bit field for the CPU ID is limited to 2 bits.  Exactly because
>>>> I wasn't sure what remifications (if any) it would have to start
>>>> populating this register with cluster id = (vcpu_id / 4) and cpu id =
>>>> (vcpu_id % 4) I put this nice arbitrary restriction in there.
>>>>
>>>> I think we need to fix how we show this register to the guest
>>>> otherwise... No?
>>>
>>> I don't see this being an issue, but if we really want to be 100% true
>>> to the A15/A7 TRM, we can always compute MPIDR that way, and adjust
>>> L2CTLR as well.
>>
>> Even with mach-virt we're still pretending to be an A15/A7 right? I
>> think we should adhere to that.  Is there some other reason why people
>> shouldn't generally expect MPIDR to be correct (merging this code to KVM
>> and running in a VM notwithstanding)?
>
> Yes, it is probably better to adhere to the law of least surprise. I'm
> reworking this patch and will repost (slightly longer) the series.
>
>>>
>>> That will require some userspace change in kvmtool though (need to
>>> change the DT generator to cope with the cluster ID).
>>>
>> That would be the less fun part...
>
> Actually, it is surprisingly easy once the kernel does the right thing.
>
Great ;)