On 31.07.2018 12:27, Igor Mammedov wrote: > On Wed, 25 Jul 2018 14:07:12 +0100 > Marc Zyngier <marc.zyngier@xxxxxxx> 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 _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
