> This is the step that concerns me. "Relatively short time" is, well, relative. > Hmm, though I suppose if userspace managed to map a shared page into something > that pins the page, and can't force an unpin, e.g. by stopping I/O?, then either > there's a host userspace bug or a guest bug, and so effectively hanging the vCPU > that is waiting for the conversion to complete is ok. The whole entire point of FOLL_LONGTERM is to interact with ZONE_MOVABLE stuff such that only FOLL_LONGTERM users will cause unlimited refcount elevation. Blocking FOLL_LONGTERM is supposed to result result in pins that go to zero on their own in some entirely kernel controlled time frame. Userspace is not supposed to be able to do anything to prevent this. This is not necessarily guarenteed "fast", but it is certainly largely under the control of hypervisor kernel and VMM. ie if you do O_DIRECT to the shared memory then the memory will remain pinned until the storage completes. Which might be ms or it might be a xx second storage timeout. But putting it in the full context, if the guest tries to make a page private that is actively undergoing IO while shared, then I think it is misbehaving and it is quite reasonable to stall its call for private until the page refs drop to zero. If guests want shared to private to be fast then guests need to ensure there is no outstanding IO. In other words the page ref scheme would only be protective against hostile guests and in real workloads we'd never expect to have to wait. The same as ZONE_MOVABLE. Jason
