Re: [PATCH] 8/8 Create MMU 2/3 level accessors in the sub-arch layer (i386)

[Andrew Morton <akpm@osdl.org>]

Zachary Amsden <zach@vmware.com> wrote:
>
> >Yeah, I said ugly ones specificly.  There's been some nice previous ones,
>  >but most in this series (all the move of stuff to subarches) are rather
>  >horrible and lack lots of explanation.
>  >  
>  >
> 
>  All of my previous patches have been aimed at fixing bugs, improving 
>  performance, reliability and maintinability of the i386 architecture.  

Yup, with one or two semi-exceptions, all the patches up to this series
seem to be good general cleanups - certainly it's good to move all those
open-coded asm statements into single-site inlines and macros: people keep
on screwing them up.

We do need to wake the Xen poeple up, make sure that these changes suit
them as well, or at least don't screw them over (hard to see how it could
though).

>  If you found something that didn't fit one of those categories in my 
>  previous patches, then it is either not well enough explained or perhaps 
>  inadvertently slipped through from one of my more radical trees - or it 
>  could be a bug.
> 
>  There is a simple explanation for all of this series.  The goal is to 
>  move all privileged instructions, sensitive instructions, and privilege 
>  awareness into a layer where it can be overridden by new code without 
>  disrupting the default architecture.  On x86, there are a lot of 
>  instructions - popf, iret, sgdt, and others which behave differently 
>  under different privilege levels, but do not trap.  These architectural 
>  features must be redefined by any architecture which virtualizes the 
>  x86, be it Xen, UML, or an alternative approach.  Similarly, certain 
>  privileged processor data structures (page tables, descriptor tables) 
>  must be protected and accessed in a different manner if one is to 
>  utilize the principles of paravirtualization to achieve high performance 
>  inside of a virtual machine.  I believe this series of patches is one 
>  almost clean solution to this.  There are obvious problems with the MMU 
>  patch, and I'm still trying to come up with a way to properly address that.

Yes this later series is in a different category and will require more
review/coordination/discussion/waking-up from the Xen team.