From: Marc Zyngier <marc.zyngier@arm.com>
To: Andrew Jones <drjones@redhat.com>
Cc: Maran Wilson <maran.wilson@oracle.com>,
kvmarm@lists.cs.columbia.edu, bthakur@codeaurora.org,
Christoffer Dall <cdall@cs.columbia.edu>,
Christoffer Dall <cdall@kernel.org>,
peter.maydell@linaro.org, david@redhat.com,
qemu-devel@nongnu.org,
Christoffer Dall <christofferdall@christofferdall.dk>,
qemu-arm@nongnu.org, imammedo@redhat.com
Subject: Re: [Qemu-devel] VCPU hotplug on KVM/ARM
Date: Wed, 25 Jul 2018 14:07:12 +0100 [thread overview]
Message-ID: <202a2c63-1a3e-7f01-850c-4fb5e48f43e7@arm.com> (raw)
In-Reply-To: <20180725122806.g2gpvdbrbdkriprg@kamzik.brq.redhat.com>
On 25/07/18 13:28, Andrew Jones wrote:
> On Wed, Jul 25, 2018 at 11:40:54AM +0100, Marc Zyngier wrote:
>> On 24/07/18 19:35, Maran Wilson wrote:
>>> It's been a few months since this email thread died off. Has anyone
>>> started working on a potential solution that would allow VCPU hotplug on
>>> KVM/ARM ? Or is this a project that is still waiting for an owner who
>>> has the time and inclination to get started?
>>
>> This is typically a project for someone who would have this particular
>> itch to scratch, and who has a demonstrable need for this functionality.
>>
>> Work wise, it would have to include adding physical CPU hotplug support
>> to the arm64 kernel as a precondition, before worrying about doing it in
>> KVM.
>>
>> For KVM itself, particular area of interests would be:
>> - Making GICv3 redistributors magically appear in the IPA space
>> - Live resizing of GICv3 structures
>> - Dynamic allocation of MPIDR, and mapping with vcpu_id
>
> I have CPU topology description patches on the QEMU list now[*]. A next
> step for me is to this MPIDR work. I probably won't get to it until the
> end of August though.
>
> [*] http://lists.nongnu.org/archive/html/qemu-devel/2018-07/msg01168.html
>
>>
>> This should keep someone busy for a good couple of weeks (give or take a
>> few months).
>
> :-)
>
>>
>> That being said, I'd rather see support in QEMU first, creating all the
>> vcpu/redistributors upfront, and signalling the hotplug event via the
>> virtual firmware. And then post some numbers to show that creating all
>> the vcpus upfront is not acceptable.
>
> I think the upfront allocation, allocating all possible cpus, but only
> activating all present cpus, was the planned approach. What were the
> concerns about that approach? Just vcpu memory overhead for too many
> overly ambitious VM configs?
I don't have any ARM-specific concern about that, and I think this is
the right approach. It has the good property of not requiring much
change in the kernel (other than actually supporting CPU hotplug).
vcpu memory overhead is a generic concern though, and not only for ARM.
We currently allow up to 512 vcpus per VM, which looks like a lot, but
really isn't. If we're to allow this to be bumped up significantly, we
should start accounting the vcpu-related memory against the user's
allowance...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2018-07-25 13:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <000e01d3afad$b9a13830$2ce3a890$@codeaurora.org>
[not found] ` <20180227104708.GA11391@cbox>
[not found] ` <ac329e1b1f5265a805916ab4f8708f9d@codeaurora.org>
[not found] ` <20180227124604.GA2373@cbox>
2018-02-27 13:21 ` [Qemu-devel] VCPU hotplug on KVM/ARM Andrew Jones
2018-03-01 9:50 ` Igor Mammedov
2018-03-01 10:05 ` [Qemu-devel] [Qemu-arm] " Peter Maydell
2018-03-01 13:32 ` David Hildenbrand
2018-03-07 12:47 ` Marc Zyngier
2018-07-24 18:35 ` [Qemu-devel] " Maran Wilson
2018-07-25 6:45 ` Igor Mammedov
2018-07-25 10:40 ` Marc Zyngier
2018-07-25 12:28 ` Andrew Jones
2018-07-25 13:07 ` Marc Zyngier [this message]
2018-07-25 17:26 ` Maran Wilson
2018-07-31 10:27 ` Igor Mammedov
2018-07-31 10:57 ` David Hildenbrand
2018-08-01 8:09 ` Bharata B Rao
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=202a2c63-1a3e-7f01-850c-4fb5e48f43e7@arm.com \
--to=marc.zyngier@arm.com \
--cc=bthakur@codeaurora.org \
--cc=cdall@cs.columbia.edu \
--cc=cdall@kernel.org \
--cc=christofferdall@christofferdall.dk \
--cc=david@redhat.com \
--cc=drjones@redhat.com \
--cc=imammedo@redhat.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=maran.wilson@oracle.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.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).