From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: KVM: drop arbitrary limitation to 4 CPU VMs
Date: Wed, 16 Oct 2013 09:53:52 -0700 [thread overview]
Message-ID: <CAMJs5B9ezNiG8t_SPGHVf1AgSPTuFHzK5khmGgAHzGUsBw+-3w@mail.gmail.com> (raw)
In-Reply-To: <525E6144.3060004@arm.com>
On 16 October 2013 02:49, Marc Zyngier <marc.zyngier@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 ;)
prev parent reply other threads:[~2013-10-16 16:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-08 17:17 [PATCH] ARM: KVM: drop arbitrary limitation to 4 CPU VMs Marc Zyngier
2013-10-09 2:15 ` Peter Maydell
2013-10-09 6:40 ` Marc Zyngier
2013-10-13 1:09 ` Christoffer Dall
2013-10-14 8:43 ` Marc Zyngier
2013-10-15 23:21 ` Christoffer Dall
2013-10-16 9:49 ` Marc Zyngier
2013-10-16 16:53 ` Christoffer Dall [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMJs5B9ezNiG8t_SPGHVf1AgSPTuFHzK5khmGgAHzGUsBw+-3w@mail.gmail.com \
--to=christoffer.dall@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).