virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Zachary Amsden <zach@vmware.com>
To: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@osdl.org>,
	Christoph Hellwig <hch@infradead.org>,
	xen-devel@lists.xensource.com, Greg KH <greg@kroah.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Chris Wright <chrisw@sous-sol.org>,
	virtualization@lists.osdl.org, Linus Torvalds <torvalds@osdl.org>,
	James.Bottomley@steeleye.com, pazke@donpac.ru
Subject: Re: A proposal - binary
Date: Fri, 04 Aug 2006 15:39:29 -0700	[thread overview]
Message-ID: <44D3CCA1.1040503@vmware.com> (raw)
In-Reply-To: <200608050001.52535.ak@suse.de>

Andi Kleen wrote:
>> In the Xen case, 
>> they may want to run a dom-0 hypervisor which is compiled for an actual 
>> hardware sub-arch, such as Summit or ES7000. 
>>     
>
> There is no reason Summit or es7000 or any other subarchitecture 
> would need to do different  virtualization. In fact these subarchitectures 
> are pretty much obsolete by the generic subarchitecture and could be fully
> done by runtime switching.
>   

For privileged domains that have hardware privileges and need to send 
IPIs or something it might make sense.  Othewsie, there is no issue.

>> I would expect to see these new sub-architectures 
>> begin to grow like a rash. 
>>     
>
> I hope not. The i386 subarchitecture setup is pretty bad already
> and mostly obsolete for modern systems.
>   

Yes, I hope not too.

>   
>> I'm now talking lightyears into the future
>>     
>
> tststs - please watch your units.
>   

I realized after I wrote it ;)

> I don't fully agree to move everything into paravirt ops. IMHO
> it should be only done for stuff which is performance critical
> or cannot be virtualized.

Yes, this is all just a crazy idea, not an actual proposal.

> And it's unlikely PCI will be ever a good fit for a Quantum computer @)
>   

Hmm, a quantum bus would only allow one reader of each quantum bit.  So 
you couldn't broadcast without daisy chaining everything.  Could be an 
issue.

>> Maybe someday Xen and VMware can share the same ABI interface and both 
>> use a VMI like layer. 
>>     
>
> The problem with VMI is that while it allows hypervisor side evolution
> it doesn't really allow Linux side evolution with its fixed spec.
>   

It doesn't stop Linux from using the provided primitives in any way is 
sees fit.  So it doesn't top evolution in that sense.  What it does stop 
is having the Linux hypervisor interface grow antlers and have new 
hooves grafted onto it.  What it sorely needed in the interface is a way 
to probe and detect optional features that allow it to grow independent 
of one particular hypervisor vendor.

Zach

  reply	other threads:[~2006-08-04 22:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <44D1CC7D.4010600@vmware.com>
     [not found] ` <20060803190605.GB14237@kroah.com>
     [not found]   ` <44D24DD8.1080006@vmware.com>
     [not found]     ` <20060803200136.GB28537@kroah.com>
     [not found]       ` <20060804183448.GE11244@sequoia.sous-sol.org>
     [not found]         ` <44D3B0F0.2010409@vmware.com>
2006-08-04 21:26           ` A proposal - binary Alan Cox
2006-08-05  1:14             ` James Bottomley
2006-08-05  5:37               ` Zachary Amsden
2006-08-05 10:42                 ` Adrian Bunk
2006-08-05 11:50                 ` Alan Cox
2006-08-04 22:01           ` Andi Kleen
2006-08-04 22:39             ` Zachary Amsden [this message]
2006-08-04 22:52               ` Andi Kleen
2006-08-04 22:43             ` David Lang
2006-08-05 10:47             ` Adrian Bunk
2006-08-05 11:57               ` Andi Kleen
2006-08-05  1:30           ` James Bottomley
2006-08-05  4:33             ` Zachary Amsden

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=44D3CCA1.1040503@vmware.com \
    --to=zach@vmware.com \
    --cc=James.Bottomley@steeleye.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=chrisw@sous-sol.org \
    --cc=greg@kroah.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pazke@donpac.ru \
    --cc=torvalds@osdl.org \
    --cc=virtualization@lists.osdl.org \
    --cc=xen-devel@lists.xensource.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).