Re: [RFC/PATCH 01/15] preparation: provide hook to enable pgstes in user pagetable

Avi Kivity
2008-03-24T06:57:49Z

Martin Schwidefsky wrote:
> On Sun, 2008-03-23 at 12:15 +0200, Avi Kivity wrote:
>
>>>> Can you convert the page tables at a later time without doing a
>>>> wholesale replacement of the mm? It should be a bit easier to keep
>>>> people off the pagetables than keep their grubby mitts off the mm
>>>> itself.
>>>>
>>>>
>>> Yes, as far as I can see you're right. And whatever we do in arch code,
>>> after all it's just a work around to avoid a new clone flag.
>>> If something like clone() with CLONE_KVM would be useful for more
>>> architectures than just s390 then maybe we should try to get a flag.
>>>
>>> Oh... there are just two unused clone flag bits left. Looks like the
>>> namespace changes ate up a lot of them lately.
>>>
>>> Well, we could still play dirty tricks like setting a bit in current
>>> via whatever mechanism which indicates child-wants-extended-page-tables
>>> and then just fork and be happy.
>>>
>>>
>> How about taking mmap_sem for write and converting all page tables
>> in-place? I'd rather avoid the need to fork() when creating a VM.
>>
>
> That was my initial approach as well. If all the page table allocations
> can be fullfilled the code is not too complicated. To handle allocation
> failures gets tricky. At this point I realized that dup_mmap already
> does what we want to do. It walks all the page tables, allocates new
> page tables and copies the ptes. In principle I would reinvent the wheel
> if we can not use dup_mmap

Well, dup_mm() can't work (and now that I think about it, for more
reasons -- what if the process has threads?).

I don't think conversion is too bad. You'd need a four-level loop to
allocate and convert, and another loop to deallocate in case of error.
If, as I don't doubt, s390 hardware can modify the ptes, you'd need
cmpxchg to read and clear a pte in one operation.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.