public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


      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