From: Zachary Amsden <zach@vmware.com>
To: Chuck Ebbert <76306.1226@compuserve.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Arjan van de Ven <arjan@infradead.org>,
Linus Torvalds <torvalds@osdl.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Virtualization Mailing List <virtualization@lists.osdl.org>,
Xen-devel <xen-devel@lists.xensource.com>,
Chris Wright <chrisw@sous-sol.org>
Subject: Re: [RFC, PATCH 0/24] VMI i386 Linux virtualization interface proposal
Date: Fri, 17 Mar 2006 09:52:07 -0800 [thread overview]
Message-ID: <441AF747.5000400@vmware.com> (raw)
In-Reply-To: <200603171058_MC3-1-BADF-9E3F@compuserve.com>
Chuck Ebbert wrote:
> In-Reply-To: <20060315102522.GA5926@infradead.org>
>
> On Wed, 15 Mar 2006 10:25:22 +0000, Christoph Hellwig wrote:
>
> I'd like to see a test harness implementation that has no actual
> hypervisor functionality and just implements the VMI calls natively.
> This could be used to test the interface and would provide a nice
> starting point for those who want to write a VMI hypervisor.
>
I was going to make one yesterday. But Fry's electronics stopped
carrying flashable blank PCI cards. :) Anyone know of a vendor?
It is possible to do in a software layer, although it really is a lot
easier to have the BIOS take care of all the fuss of finding a place in
low memory for you to live, setting up the various memory maps and
everything else for you.
There is enormous benefit to having such a layer - you have a very power
test harness, not just to make sure VMI works, but even more
importantly, to inspect and verify the native kernel operation as well.
You have a plethora of imporant hooks into the system, which feed you
knowledge you can not otherwise gain about which page tables have been
made active, when you take IRQs, where the kernel stack lives.
All of this is ripe for a debug harness that can verify the kernel
doesn't overflow the kernel stack, doesn't write to active page table
entries without proper accessors and subsequent invalidations, and obeys
the rules that are required for correctness when running under a
hypervisor. You probably even want to do hypervisor like things - such
as write protecting the kernel page tables so that you can be confident
there are no stray raw PTE accesses.
We actually found one (harmless on native) in i386, which was enabling
NX bit.
Zach
next prev parent reply other threads:[~2006-03-17 17:52 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-17 15:56 [RFC, PATCH 0/24] VMI i386 Linux virtualization interface proposal Chuck Ebbert
2006-03-17 17:52 ` Zachary Amsden [this message]
2006-03-17 18:43 ` [Xen-devel] " Anthony Liguori
-- strict thread matches above, loose matches on Subject: below --
2006-03-20 22:03 Anne Holler
2006-03-13 17:58 Zachary Amsden
2006-03-13 18:09 ` Arjan van de Ven
2006-03-13 18:22 ` Zachary Amsden
2006-03-13 18:26 ` Arjan van de Ven
2006-03-13 18:30 ` Zachary Amsden
2006-03-13 18:42 ` Arjan van de Ven
2006-03-13 18:48 ` Zachary Amsden
2006-03-13 19:02 ` Chris Wright
2006-03-13 18:56 ` Joshua LeVasseur
2006-03-16 18:52 ` Jan Engelhardt
2006-03-13 18:56 ` Hollis Blanchard
2006-03-13 18:59 ` Zachary Amsden
2006-03-15 10:25 ` Christoph Hellwig
2006-03-15 15:57 ` Zachary Amsden
2006-03-15 17:38 ` Joshua LeVasseur
2006-03-15 20:02 ` Andrew Morton
2006-03-16 0:05 ` Joshua LeVasseur
2006-03-13 20:17 ` Sam Vilain
2006-03-14 0:39 ` Anthony Liguori
2006-03-14 4:01 ` Zachary Amsden
2006-03-14 4:04 ` Rik van Riel
2006-03-14 4:55 ` Zachary Amsden
2006-03-14 4:13 ` Anthony Liguori
2006-03-14 4:26 ` Zachary Amsden
2006-03-14 4:30 ` Rik van Riel
2006-03-14 5:46 ` Zachary Amsden
2006-03-14 12:44 ` Rik van Riel
2006-03-14 16:22 ` Zachary Amsden
2006-03-16 18:58 ` Jan Engelhardt
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=441AF747.5000400@vmware.com \
--to=zach@vmware.com \
--cc=76306.1226@compuserve.com \
--cc=arjan@infradead.org \
--cc=chrisw@sous-sol.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--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