From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: RFC/patch portability: split kvm_vm_ioctl v3 Date: Tue, 30 Oct 2007 15:50:51 +0200 Message-ID: <472736BB.5090503@qumranet.com> References: <1192192452.7630.16.camel@cotte.boeblingen.de.ibm.com><1193327325.8345.9.camel@cotte.boeblingen.de.ibm.com> <1193400099.10970.8.camel@cotte.boeblingen.de.ibm.com> <10EA09EFD8728347A513008B6B0DA77A024CEC4D@pdsmsx411.ccr.corp.intel.com> <47270F9E.5080007@qumranet.com> <10EA09EFD8728347A513008B6B0DA77A024CEC54@pdsmsx411.ccr.corp.intel.com> <47271C9B.1050804@de.ibm.com> <4727204E.6000606@qumranet.com> <47272410.9020502@de.ibm.com> <47272556.1030901@qumranet.com> <47272D08.9080501@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, carsteno-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org, "Zhang, Xiantao" , Hollis Blanchard To: carsteno-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org Return-path: In-Reply-To: <47272D08.9080501-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org 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/