On 21.08.2011 21:39, Cherry G. Mathew wrote:
>     JM> An alternative would be to have per-CPU xpq_queue[] also. This
>     JM> is not completely stupid, xpq_queue is meant as a way to put
>     JM> multiple MMU operations in a queue asynchronously before issuing
>     JM> only one hypercall to handle them all.
> 
> This is slightly more complicated than it appears. Some of the "ops" in
> a per-cpu queue may have ordering dependencies with other cpu queues,
> and I think this would be hard to express trivially. (an example would
> be a pte update on one queue, and reading the same pte read on another
> queue - these cases are quite analogous (although completely unrelated)
> to classic RAW and other ordering dependencies in out-of-order execution
> scenarios due to pipelining, etc.).

Yes; however this should be handled by the pmap layer. xpq_queue is
fairly low level and has no access to all the knowledge/semantic
required to ensure proper PT/PD synchronization.

It is rather a way to handle multiple MMU operations into one hypercall,
like readv/writev can do for multiple read/write(s).

Mapping different pmaps in the same VA space requires to lock them, so
you should not see multiple CPUs concurrently reading/writing shared
entries. One thing remains with the old => new PTE updates that need
CAS, but this is Xen's mission to do that correctly as it manages the
MMU for us. All we have to ensure is that there's no stale operation in
the queue before leaving pmap.

> I'm thinking that it might be easier and more justifiable to nuke the
> current queue scheme and implement shadow page tables, which would fit
> more naturally and efficiently with CAS pte updates, etc.

Beware with those; shadow page tables were mainly designed with Linux in
mind, and the way it manages virtual memory is completely different to
ours: it maps the entire physical memory in the kernel virtual space
(with tricks when there's more than 1GiB involved), while we use
recursive mappings. And Xen has problems validating these.

-- 
Jean-Yves Migeon
jeanyves.mig...@free.fr

Reply via email to