From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: RFC/patch portability: split kvm_vm_ioctl Date: Fri, 12 Oct 2007 10:08:45 -0500 Message-ID: <470F8DFD.6030205@codemonkey.ws> References: <1192192452.7630.16.camel@cotte.boeblingen.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" , Avi Kivity To: Carsten Otte Return-path: In-Reply-To: <1192192452.7630.16.camel-WIxn4w2hgUz3YA32ykw5MLlKpX0K8NHHQQ4Iyu8u01E@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: > This patch splits kvm_vm_ioctl into archtecture independent parts, and > x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c. > > Common ioctls for all architectures are: > KVM_CREATE_VCPU, KVM_GET_DIRTY_LOG > > I'd really like to see more commonalities, but all others did not fit > our needs. I would love to keep KVM_GET_DIRTY_LOG common, so that the > ingenious migration code does not need to care too much about different > architectures. > > x86 specific ioctls are: > KVM_SET_MEMORY_REGION, KVM_SET_USER_MEMORY_REGION, > KVM_GET/SET_NR_MMU_PAGES, KVM_SET_MEMORY_ALIAS, KVM_CREATE_IRQCHIP, > KVM_CREATE_IRQ_LINE, KVM_GET/SET_IRQCHIP > > While the pic/apic related functions are obviously x86 specific, some > other ioctls seem to be common at a first glance. > KVM_SET_(USER)_MEMORY_REGION for example. We've got a total different > address layout on s390: we cannot support multiple slots, and a user > memory range always equals the guest physical memory [guest_phys + vm > specific offset = host user address]. We don't have nor need dedicated > vmas for the guest memory, we just use what the memory managment has in > stock. This is true, because we reuse the page table for user and guest > mode. > You still need to tell the kernel about vm specific offset right? So doesn't KVM_SET_USER_MEMORY_REGION for you just become that? There's nothing wrong with s390 not supporting multiple memory slots, but there's no reason the ioctl interface can't be the same. Regards, Anthony Liguori > Looks to me like the s390 might have a lot in common with a future AMD > nested page table implementation. If AMD choose to reuse the page table > too, we might share the same ioctl to set up guest addressing with them. > > signed-off-by: Carsten Otte > reviewed-by: Christian Borntraeger > reviewed-by: Christian Ehrhardt > --- > ------------------------------------------------------------------------- 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/