On 11/21/2011 01:03 PM, Paul Mackerras wrote: > On Sun, Nov 20, 2011 at 02:23:52PM +0200, Avi Kivity wrote: > > > > There is no "the VMA". There could be multiple VMAs, or none (with the > > mmap() coming afterwards). You could do all the checks you want here, > > only to have host userspace remap it under your feet. This needs to be > > done on a per-page basis at fault time. > > OK, so that's a somewhat different mental model than I had in mind. I > can change the code to do almost everything on a per-page basis at > fault time on POWER7. There is one thing we can't do at fault time, > which is to tell the hardware the page size for the "virtual real mode > area" (VRMA), which is a mapping of the memory starting at guest > physical address zero. We can however work out that pagesize the > first time we run a vcpu. By that stage we must have some memory > mapped at gpa 0, otherwise the vcpu is not going to get very far. We > will need to look for the page size of whatever is mapped at gpa 0 at > that point and give it to the hardware. Ok. Do you need to check at fault time that your assumptions haven't changed, then? > On PPC970, which is a much older processor, we can't intercept the > page faults (at least not without running the whole guest in user mode > and emulating all the privileged instructions), so once we have given > the guest access to a page, we can't revoke it. We will have to take > and keep a reference to the page so it doesn't go away underneath us, > which of course doesn't guarantee that userland can continue to see > it, but does at least mean we won't corrupt memory. Yes, this is similar to kvm/x86 before mmu notifiers were added. > > > > + /* > > > + * We require read & write permission as we cannot yet > > > + * enforce guest read-only protection or no access. > > > + */ > > > + if ((vma->vm_flags & (VM_READ | VM_WRITE)) != > > > + (VM_READ | VM_WRITE)) > > > + goto err_unlock; > > > > This, too, must be done at get_user_pages() time. > > > > What happens if mmu notifiers tell you to write protect a page? > > On POWER7, we have to remove access to the page, and then when we get > a fault on the page, request write access when we do > get_user_pages_fast. Ok, so no ksm for you. Does this apply to kvm-internal write protection, like we do for the framebuffer and live migration? I guess you don't care much about the framebuffer (and anyway it doesn't need read-only access), but removing access for live migration is painful. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
