From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH/PFC 0/2] s390 host support Date: Sun, 29 Apr 2007 12:13:21 +0300 Message-ID: <463461B1.7060406@qumranet.com> References: <1177681224.5770.20.camel@cotte.boeblingen.de.ibm.com> <4632E94C.20904@qumranet.com> <4633099D.3020709@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" , Christian Borntraeger , mschwid2-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org To: carsteno-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org Return-path: In-Reply-To: <4633099D.3020709-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: > >> The address space and vcpu management are rather different from kvm's, >> however your approach is better and we'll want to move kvm in your >> direction rather than the other way round (specifically the tight vcpu >> <-> task coupling; mmu is more diffcult). > We have tried a file based approach for the cpus before too. We'll want to keep a vcpu fd. If the vcpu is idle we'll be asleep in poll() or the like, and we need some kind of wakeup mechanism. > > With regard to the memory, I do not quite understand why regular > pageable user space memory does'nt work with vt and svm. We would > definetly prefer to keep our virtual machine's memory pageable on > s390, therefore I guess we need some arch dependent plug that > allocates the memory. This would boil down to a regular anonymous > allocation on s390, and to specifically allocated memory on x86. I guess some of the difference stems from the fact that on x86, the Linux pagetables are actually the hardware pagetables. VT and SVM use a separate page table for the guest which cannot be shared with the host. This means that - we need to teach the Linux mm to look at shadow page tables when transferring dirty bits - when Linux wants to write protect a page, it has to modify the shadow page tables too (and flush the guest tlbs, which is again a bit different) - this means rmap has to be extended to include kvm I think that non-x86 have purely software page tables, maybe this make things easier. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/