From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Otte Subject: Re: [PATCH/PFC 0/2] s390 host support Date: Sun, 29 Apr 2007 13:15:57 +0200 Message-ID: <46347E6D.90409@de.ibm.com> References: <1177681224.5770.20.camel@cotte.boeblingen.de.ibm.com> <4632E94C.20904@qumranet.com> <4633099D.3020709@de.ibm.com> <463461B1.7060406@qumranet.com> <4634726F.10705@de.ibm.com> <463477EE.3000406@qumranet.com> Reply-To: carsteno-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: carsteno-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org, "kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org" , Christian Borntraeger , mschwid2-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org To: Avi Kivity Return-path: In-Reply-To: <463477EE.3000406-atKUWr5tajBWk0Htik3J/w@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 Avi Kivity wrote: > In both cases you wait in the kernel; with an fd you wait in the kernel > and with pthread_cond_wait you wait in futex(FUTEX_WAIT) or a close > relative. That is a good point indeed ;-). > Can one do the equivalent of a futex wakeup from the kernel easily? No, we did not have the need to do that. Now that you mention it, we'd want to move interprocessor signal handling into the kernel anyway for performance reasons. That would rise the need to wake up from kernel. The other way round, how do you intend to wake a thread that uses poll() or similar from userspace? > Nested page tables/extended page tables also provide this facility, with > some caveats: > > - on 32-bit hosts (or 64-bit hosts with 32-bit userspace), host > userspace virtual address space is not enough to contain the guest > physical address space. > - there is no way to protect the host userspace from the guest > - some annoying linker scripts need to be used to compile the host > userspace to move it out of the guest userspace area, making it more > difficult to write kvm userspace > > I think there's a way to work around these issues on 64-bit npt > hardware: allocate a pgd entry (at a non-zero offset) to hold guest > physical memory, and copy this pgd entry into a guest-only pgd at offset > zero. > > Of course, there are many millions of non-npt/ept processors out there, > and we can't leave them out in the cold, so we'll have to work something > out for classical shadow page tables. No, of course not. The nested pagetable approach sounds neat to me. Does'nt the fact that there will be no security barrier between guest userspace and virtual machine require running kvm as non privileged user in the end? Our implementation does use action bits preseted to sys_s390host_sie to update the hardware control blocks for the virutal machine. The hardware control blocks would be mapped read-only to user address space. This way, the kernel can enforce the user not to mess things up, which allows to run non-privileged user code (userid johndoe instead of root). Would this approach be reasonable on x86 too? so long, Carsten ------------------------------------------------------------------------- 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/