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

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On Mon, 22 Aug 2011 12:47:40 +0200, Manuel Bouyer wrote:
> > 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 ?

Nope, PTE are directly obtained from the recursive mappings 
(vtopte/kvtopte).

Content is "obviously" only writable by hypervisor (so it can keep 
control of his mapping alone).

> I think this is similar to a tlb flush but the other way round,
> I guess we could use a IPI for this too.

IIRC that's what the current native x86 code does: it uses an IPI to 
signal other processors that a shootdown is necessary.

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

--
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost