[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <44D23924.9040704@vmware.com>
Date: Thu, 03 Aug 2006 10:57:56 -0700
From: Zachary Amsden <zach@...are.com>
To: Antonio Vargas <windenntw@...il.com>
Cc: Arjan van de Ven <arjan@...radead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...l.org>, greg@...ah.com,
Andrew Morton <akpm@...l.org>,
Christoph Hellwig <hch@...radead.org>,
Rusty Russell <rusty@...tcorp.com.au>, Jack Lo <jlo@...are.com>
Subject: Re: A proposal - binary
Antonio Vargas wrote:
> If the essence of using virtual machines is precisely that the machine
> acts just as if it was a real hardware one, then we should not need
> any modifications to the kernel. So, it would be much better if the
> hypervirsor was completely transparent and just emulated a native cpu
> and a common native set of hardware, which would then work 100% with
> the native code in the kernel. This keeps the smarts of virtual
> machine management on the hypervisor.
You are basically arguing for full virtualization - which is fine. But
today as it stands it does not provide the highest level of performance
that paravirtualization does, and in the future, it does little to
provide more advanced virtualization features.
>
> For example, TBL and pagetable handling can be done with 2 interfaces,
> one standard via intercepting normal cpu instructions, and a batched
> one via a hardware driver with a FIFO on shared memory just like many
> graphics card do to send commands and data to the GPU. I recall this
> design was the one used in the mac-on-linux hypervisor for ppc
> architecture. Why not for x86 with vt/pacifica extensions? What about
> using the same design than on the Sparc T1 port?
You can't use a driver to do this in Linux today, because there are no
hooks you can use for pagetable handling. And you will always achieve
better performance and simplicity by changing the machine definition to
avoid the really nasty cases. Hardware virtualization is simply not
fast enough today. But it also doesn't leave room for the future -
proposals such as the abstract MMU interfaces for Linux which have been
floating around are extremely attractive from a hypervisor point of view
- but there can be no progress until there is some kind of consensus on
what those are, and having an interface in the kernel is a requirement
for any deeper level of paravirtualization.
Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists