On Wed, Oct 23, 2019 at 03:17:54PM +1100, Paul Mackerras wrote: > On Tue, Oct 22, 2019 at 11:59:35AM +0530, Bharata B Rao wrote: > The mapping of pages in userspace memory, and the mapping of userspace > memory to guest physical space, are two distinct things. The memslots > describe the mapping of userspace addresses to guest physical > addresses, but don't say anything about what is mapped at those > userspace addresses. So you can indeed get a page fault on a > userspace address at the same time that a memslot is being deleted > (even a memslot that maps that particular userspace address), because > removing the memslot does not unmap anything from userspace memory, > it just breaks the association between that userspace memory and guest > physical memory. Deleting the memslot does unmap the pages from the > guest but doesn't unmap them from the userspace process (e.g. QEMU). > > It is an interesting question what the semantics should be when a > memslot is deleted and there are pages of userspace currently paged > out to the device (i.e. the ultravisor). One approach might be to say > that all those pages have to come back to the host before we finish > the memslot deletion, but that is probably not necessary; I think we > could just say that those pages are gone and can be replaced by zero > pages if they get accessed on the host side. If userspace then unmaps > the corresponding region of the userspace memory map, we can then just > forget all those pages with very little work. There are 5 scenarios currently where we are replacing the device mappings: 1. Guest reset 2. Memslot free (Memory unplug) (Not present in this version though) 3. Converting secure page to shared page 4. HV touching the secure page 5. H_SVM_INIT_ABORT hcall to abort SVM due to errors when transitioning to secure mode (Not present in this version) In the first 3 cases, we don't need to get the page to HV from the secure side and hence skip the page out. However currently we do allocate fresh page and replace the mapping with the new one. > > However if that sounds fragile, may be I can go back to my initial > > design where we weren't using rmap[] to store device PFNs. That will > > increase the memory usage but we give us an easy option to have > > per-guest mutex to protect concurrent page-ins/outs/faults. > > That sounds like it would be the best option, even if only in the > short term. At least it would give us a working solution, even if > it's not the best performing solution. Sure, will avoid using rmap[] in the next version. Regards, Bharata.
