[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [Qemu-devel] VCPU hotplug on KVM/ARM
From: |
David Hildenbrand |
Subject: |
Re: [Qemu-arm] [Qemu-devel] VCPU hotplug on KVM/ARM |
Date: |
Tue, 31 Jul 2018 12:57:06 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 |
On 31.07.2018 12:27, Igor Mammedov wrote:
> On Wed, 25 Jul 2018 14:07:12 +0100
> Marc Zyngier <address@hidden> wrote:
>
>> 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).
> for x86 we allocate VCPUs dynamically (both QEMU and KVM)
> CCing ppc/s390 folks as I don't recall how it's implemented there.
s390x: also handled that way. Dynamically allocated.
Unplug: not supported by the architecture and fenced.
I remember a discussion where people said dynamically creating/deleting
VCPUs (and therefore threads) is preferred, because then there is no way
on earth a malicious guest could make use of such a CPU (in case there
would be a subtle BUG in QEMU).
--
Thanks,
David / dhildenb