[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v2 7/7] hw/arm/virt: Register two redistributor re
Re: [Qemu-devel] [RFC v2 7/7] hw/arm/virt: Register two redistributor regions when necessary
Tue, 29 May 2018 15:16:46 +0100
On 29 May 2018 at 14:43, Auger Eric <address@hidden> wrote:
> I just noticed virt_machine_class_init still clamps the max_cpus to 255.
> This is checked in vl.c
> Do we want the 3.0 machine expose more than 255 vcpus, 512 for instance?
> I understand this mc->max_cpus is something rather static, that is
> refined afterwards.
Mmm. It's mostly used by the option checking code in vl.c, which
runs before the board init function. So really what we're doing by
setting it to some high number is disabling those checks; we then
have to mess around with checking manually later. Unfortunately
I don't think we have enough info to set the real maximum early
enough to avoid this.
We should probably set max_cpus here to whatever is the maximum the
board can handle in any configuration.
> Note the comment in virt_machine_class_init suggest 255 is the max QEMU
> supports but I can see that pc_q35.c sets the max_cpus to 288 already.
I think that's out of date, yes -- probably when the code was written
255 was the maximum.
[Qemu-devel] [RFC v2 4/7] hw/intc/arm_gicv3_kvm: Get prepared to handle multiple redist regions, Eric Auger, 2018/05/13
[Qemu-devel] [RFC v2 6/7] hw/arm/virt-acpi-build: Advertise one or two GICR structures, Eric Auger, 2018/05/13
[Qemu-devel] [RFC v2 5/7] hw/arm/virt: GICv3 DT node with one or two redistributor regions, Eric Auger, 2018/05/13
[Qemu-devel] [RFC v2 7/7] hw/arm/virt: Register two redistributor regions when necessary, Eric Auger, 2018/05/13
- Re: [Qemu-devel] [RFC v2 3/7] hw/intc/arm_gicv3: Introduce redist-region-count array property, (continued)