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.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
