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. 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. > > + /* > > + * 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. Paul. -- 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
