All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zachary Amsden <zach@vmware.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Andi Kleen <ak@suse.de>,
	linux-kernel@vger.kernel.org, Rik van Riel <riel@redhat.com>,
	Chris Wright <chrisw@osdl.org>,
	Pratap Subrahmanyam <pratap@vmware.com>
Subject: Re: [PATCH] 8/8 Create MMU 2/3 level accessors in the sub-arch layer (i386)
Date: Sat, 06 Aug 2005 11:28:58 -0700	[thread overview]
Message-ID: <42F5016A.2020900@vmware.com> (raw)
In-Reply-To: <20050806120141.GA1827@infradead.org>

Christoph Hellwig wrote:

>On Sat, Aug 06, 2005 at 01:58:36PM +0200, Andi Kleen wrote:
>  
>
>>>>I think that patch is really ugly - it makes hacking VM on i386
>>>>even more painful than it already is because the convolutes the file
>>>>structure even more. Hope it is not applied.
>>>>        
>>>>
>>>Especially as there's been no user shown for it, similar to all the other
>>>ugly patches from vmware.
>>>      
>>>
>>Well, some of it can be counted as cleanup or even tuning like the excellent
>>switch_to patch. But not that one and some of the more intrusive patches.
>>    
>>
>
>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.  
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.

That said, I am definitely seeking any feedback you have on how to 
achieve this goal while being as clean and maintainable as possible - if 
the Linux community is indeed interested in adopting a 
paravirtualization approach.  Looking from the most general view 
possible, there are a couple of ways to do this in Linux:

1) Create a new architecture.  This is the UML approach, and while it 
has been successful there, it is difficult to maintain closeness to the 
hardware architecture without introducing a maintenance burden.  This 
closeness is desirable if one is to achieve high performance and take 
advantage of more processor specific features.

2) Use the sub-architecture strategy of x86.  This approach has a 
relatively small set of code movement to allow a new virtualized 
sub-architecture to redefine the privileged and sensitive operations of 
the processor, as well as to implement easily defined architectural 
hints which employ higher level virtualization strategies.

3) Use #ifdef'd include/asm-i386 header files.  While workable, this has 
flaws - it is ugly, and it causes the hypervisor header files to sneak 
into include/asm-i386 rather rapidly destroying maintainability for the 
native code.  This has been attempted before, but if someone were to 
send those patches to LKML, I would expect them to be rapidly tarred and 
feathered.

4) Clone entire asm-i386 header files and replace them using an include 
path, potentially in the sub-architecture level.  While this avoids any 
diffs at all to the native asm-i386 headers, it needlessly duplicates a 
lot of code, and this creates a greater maintenance burden for 
somebody.  Who that body is can be determined later, but this creates a 
lot of extra work for that unfortunate person that is wasted time that 
could easily be spent bettering Linux!

5) Use the HAVE_SUBARCH_PTE_ACCESSOR type approach (similar to the way 
generic optimizable PTE operations are defined in asm-generic).  I have 
not yet investigated the feasibility of this type of approach, but it 
seems workable.  At least for the MMU patch, some combination of this 
and other techniques might help make things a lot cleaner.

Do you have ideas?  I'm open to all suggestions here.  The only goal I 
have is to make high performance virtualization support in Linux the 
least disruptive event possible for all parties.  Although I'm a bit 
biased towards i386 from a coding point of view, some of these ideas can 
cross architecture boundaries as well, so I'm open to feedback from all 
parties.

Thanks,
Zach

  reply	other threads:[~2005-08-06 18:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <42F46558.9010202@vmware.com.suse.lists.linux.kernel>
2005-08-06 11:37 ` [PATCH] 8/8 Create MMU 2/3 level accessors in the sub-arch layer (i386) Andi Kleen
2005-08-06 11:56   ` Christoph Hellwig
2005-08-06 11:58     ` Andi Kleen
2005-08-06 12:01       ` Christoph Hellwig
2005-08-06 18:28         ` Zachary Amsden [this message]
2005-08-06 22:58           ` Andrew Morton
2005-08-06 23:02             ` Chris Wright
2005-08-07 10:39             ` Zachary Amsden
2005-08-06  7:23 Zachary Amsden
2005-08-07  1:16 ` Chris Wright

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42F5016A.2020900@vmware.com \
    --to=zach@vmware.com \
    --cc=ak@suse.de \
    --cc=chrisw@osdl.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pratap@vmware.com \
    --cc=riel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.