On 11/29/21 17:13, Brijesh Singh wrote: >> >> That could work for the kmap() context. >> What to do for the userspace context (host userspace)? >> - shared->private transition - page has to be unmapped from all userspace, >> elevated refcount (gup() in progress) can block this unmap until it goes >> away - could be doable > > An unmap of the page from all the userspace process during the page state > transition will be great. If we can somehow store the state information in > the 'struct page' then it can be later used to make better decision. I am > not sure that relying on the elevated refcount is the correct approach. e.g > in the case of encrypted guests, the HV may pin the page to prevent it from > migration. > > Thoughts on how you want to approach unmaping the page from userspace page > table? After giving it more thought and rereading the threads here it seems I thought it would be easier than it really is, and it would have to be something at least like Kirill's hwpoison based approach. >> - still, what to do if host userspace then tries to access the unmapped >> page? SIGSEGV instead of SIGBUS and it can recover? >> > > Yes, SIGSEGV makes sense to me. OTOH the newer fd-based proposal also IIUC takes care of this part better - the host userspace controls the guest's shared->private conversion requests so it can't be tricked to access a page that's changed under it. >> >> >>> Thoughts ? >>> >>>> >>>> This should turn an RMP fault in the kernel which is not covered in the >>>> uaccess exception table into a fatal error. >>>> >>>> Regards, >>>> >>
