Re: [Xen-devel] [PATCH] respin of mprotect performance patch

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

It's taken me a while to work out that MMU_ATOMIC_PT_UPDATE is actually
'atomic' in that it preserves the existing A/D bits (and should ignore the
ones specified in the given new value). Am I correct?

In which case:
 (1) The name and description in xen.h should be better. E.g.,
MMU_PT_UPDATE_PRESERVE_AD, with a corresponding comment explaining the
atomicity/consistency guarantee.
 (2) The implementation is actually wrong, as it only attempts to propagate
A/D bits into the 'new' value if the first cmpxchg attempt fails. Otherwise
the A/D values passed in by the guest are used, but the PTE might change
before Xen itself reads the ol1e.
 (3) In general, the hypercall implementation can probably be slimmed down a
bunch. There's lots of code duplication.

I can take a swing at the Xen side of this, if I haven't got the wrong end
of the stick?

 -- Keir

On 8/1/08 01:05, "Bruce Rogers" <brogers@xxxxxxxxxx> wrote:

> I've incorporated the comments of Jan and Keir into the attached patches, with
> the exception of moving mmu_ops related entries from public/xen.h into
> architecture specific headers.
> Thanks for your review.  Let me know if I've missed anything.
> 
> Signed-off-by: Bruce Rogers <brogers@xxxxxxxxxx>
> 
> - Bruce
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel