Re: RFC/patch portability: split kvm_vm_ioctl v3

Avi Kivity
2007-10-30T13:50:51Z

Carsten Otte wrote:
> Avi Kivity wrote:
>> A bitmap would do it, but what size? Expandable ones are messy.
> We could have a #define KVM_CPU_BITMAP_SIZE in the arch specific
> header files that go to include/asm/. For s390, we have one of our
> rocket science virtualization accelerating facilities that limits us
> to 64 cpus per guest. This may well be extended later on, but for now
> that would be sufficient. Thinking about Christoph Lameter with his 4k
> CPU boxes, I believe ia64 would want faaaar more than that.
>

If there's a single variable length array (which is the case here) it
can be tucked on at the end:

struct kvm_ipi {
__u64 vector;
__u32 size; /* bytes, must be multiple of 8 */
__u32 pad;
__u64 cpuset[0];
};

We have this in a few places. Not pretty, but serviceable.

>> No, it's a command (mmio) to the APIC, you tell it which vector you
>> want and to which cpus you want it delivered. So you can have many
>> IPI interrupt vectors.
> I see. But the interrupt vector can be encoded in __u64?
>

The vector is just a u8.

The x86 interrupt path looks like this:

[devices] -- irq --> [interrupt controllers] ---- vector ---> [processor]

The interrupt controllers translate irq lines into vectors, which the
processor consumes. Before kvm-irqchip, the API taked about vectors
since the interrupt controller was in userspace. Nowadays userspace
talks irq lines to the kernel, which converts them into vectors.

If I uderstand correctly, s390 is interrupt vector oriented, no?

--
Any sufficiently difficult bug is indistinguishable from a feature.