On 11/29/21 17:13, Brijesh Singh wrote:

quoted

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.

quoted

- 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.

quoted

quoted

Thoughts ?

quoted

This should turn an RMP fault in the kernel which is not covered in the
uaccess exception table into a fatal error.

Regards,