On 19/08/2019 08:41, Will Deacon wrote: > On Sun, Aug 18, 2019 at 03:07:10PM +0100, Marc Zyngier wrote: >> While parts of the VGIC support a large number of vcpus (we >> bravely allow up to 512), other parts are more limited. >> >> One of these limits is visible in the KVM_IRQ_LINE ioctl, which >> only allows 256 vcpus to be signalled when using the CPU or PPI >> types. Unfortunately, we've cornered ourselves badly by allocating >> all the bits in the irq field. >> >> Since the irq_type subfield (8 bit wide) is currently only taking >> the values 0, 1 and 2 (and we have been careful not to allow anything >> else), let's reduce this field to only 4 bits, and allocate the >> remaining 4 bits to a vcpu2_index, which acts as a multiplier: >> >> vcpu_id = 256 * vcpu2_index + vcpu_index >> >> With that, and a new capability (KVM_CAP_ARM_IRQ_LINE_LAYOUT_2) >> allowing this to be discovered, it becomes possible to inject >> PPIs to up to 4096 vcpus. But please just don't. > > Do you actually need a new capability for this? Older kernels reject > non-zero upper bits in the 'irq_type', so isn't that enough to probe > for this directly? 'Probing' is a bit of an overstatement. You'll get an error back when userspace will try to inject a PPI into a vcpu whose ID is in the new range. But nothing at VM creation time will indicate the interrupt injection API supports more than 256 vcpus. I think userspace should be able to fail the creation of such large VM immediately, before actually running it. M. -- Jazz is not dead, it just smells funny... _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
