All of lore.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: 4+ 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 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.