From: Anthony Liguori <aliguori@us.ibm.com>
To: Zachary Amsden <zach@vmware.com>
Cc: Chuck Ebbert <76306.1226@compuserve.com>,
Chris Wright <chrisw@sous-sol.org>,
Xen-devel <xen-devel@lists.xensource.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Christoph Hellwig <hch@infradead.org>,
Virtualization Mailing List <virtualization@lists.osdl.org>,
Linus Torvalds <torvalds@osdl.org>,
Arjan van de Ven <arjan@infradead.org>
Subject: Re: [Xen-devel] Re: [RFC, PATCH 0/24] VMI i386 Linux virtualization interface proposal
Date: Fri, 17 Mar 2006 12:43:27 -0600 [thread overview]
Message-ID: <441B034F.7020102@us.ibm.com> (raw)
In-Reply-To: <441AF747.5000400@vmware.com>
Zachary Amsden wrote:
> 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's very practical to just patch Qemu to load a VMI rom as an option
ROM. That makes such an example VMI ROM very practical without having
to build a special PCI device.
Regards,
Anthony Liguori
> 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
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
prev parent reply other threads:[~2006-03-17 18:43 UTC|newest]
Thread overview: 3+ 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
2006-03-17 18:43 ` Anthony Liguori [this message]
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=441B034F.7020102@us.ibm.com \
--to=aliguori@us.ibm.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 \
--cc=zach@vmware.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