Carsten Otte wrote: > > >> 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? >
Write to a pipe, or send a signal (signals are quite fast if you mask them in userspace and use ppoll()). >> 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? The trick I mentioned (copying a pgd entry) means: - guest physical and host userspace are different (have different pgds) - guest physical (offset 0) is aliased to host userspace (offset $bignum) - guest address space is limited to 2^(12+9*3) - the pte dirty and accessed bits are shared so guest userspace is not exposed, but the guest ptes _are_ shared. In a way, this is similar to shared memory, if shared page tables are ever implemented. Think of a shared memory segment mapped at two different offsets, but aligned at a pud boundary so everything below the pgd entry is sharable. > > 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? Allowing the guest to hack the host userspace exposes the rest of the user's processes to a malicious guest, and allows the guest to open network connections through the host, no? -- 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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
