Re: CVS commit: src/sys/arch/xen

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sun, Aug 21, 2011 at 09:39:14PM +0200, 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)

read don't go through the xpq queue, don't they ?
I think this is similar to a tlb flush but the other way round,
I guess we could use a IPI for this too.

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

I'm not sure this would completely fis the issue: with shadow page tables
you can't use a CAS to assure atomic operation with the hardware TLB, as
this is, precisely, a shadow PT and not the one used by hardware.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--