Date: Mon, 28 Jul 2008 17:11:23 +0200
From: Ingo Molnar <mingo@elte.hu>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86: fix pte_flags() to only return flags, fix lguest
	(updated)
Message-ID: <20080728151122.GE32111@elte.hu>
References: <200807221431.58991.rusty@rustcorp.com.au> <200807231059.20810.rusty@rustcorp.com.au> <20080724113122.GB23262@elte.hu> <200807251155.49606.rusty@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200807251155.49606.rusty@rustcorp.com.au>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3401
Lines: 69


* Rusty Russell <rusty@rustcorp.com.au> wrote:

> On Thursday 24 July 2008 21:31:22 Ingo Molnar wrote:
> > * Rusty Russell <rusty@rustcorp.com.au> wrote:
> > > On Tuesday 22 July 2008 19:04:32 Ingo Molnar wrote:
> > > > i'm wondering. My randconfig tests boot up an lguest enabled kernel
> > > > every 30 minutes or so:
> > > >
> > > >  config-Mon_Jul_21_19_05_54_CEST_2008.good:CONFIG_LGUEST=y
> > > >  config-Mon_Jul_21_19_43_13_CEST_2008.good:CONFIG_LGUEST=y
> > > >  config-Mon_Jul_21_19_47_40_CEST_2008.good:CONFIG_LGUEST=y
> > > >  config-Mon_Jul_21_20_37_41_CEST_2008.good:CONFIG_LGUEST=y
> > > >  config-Mon_Jul_21_22_11_42_CEST_2008.good:CONFIG_LGUEST=y
> > > >  config-Mon_Jul_21_22_16_59_CEST_2008.good:CONFIG_LGUEST=y
> > > >  config-Mon_Jul_21_22_32_22_CEST_2008.good:CONFIG_LGUEST=y
> > > >  config-Mon_Jul_21_23_25_55_CEST_2008.good:CONFIG_LGUEST=y
> > > >  config-Mon_Jul_21_23_51_29_CEST_2008.good:CONFIG_LGUEST=y
> > > >
> > > > Would it be possible to have some really stupid lguest self-test which
> > > > would complain spectacularly in the host kernel if it fails to reach
> > > > some minimal user-space?
> > > >
> > > > Something that could be self-contained within a single bzImage. (i.e.
> > > > it would contain a minimalistic image of some sort with a very
> > > > minimalistic userspace component as well - or something like that)
> > >
> > > Well, adding "make -C Documentation/lguest" to the build is a good start
> > > (this finds those "e820.h not longer includable from userspace" bugs).
> > >
> > > Secondly, if you put the resulting Documentation/lguest/lguest somewhere
> > > on your booting test machine, it can just do something like
> > >
> > > 	./lguest 64 /boot/vmlinuz-`uname -r` | grep 'VFS: Unable to mount root'
> >
> > stupid question: what's the easiest way to filter out the case where
> > there's not sufficient kernel support in the bzImage to actually run
> > lguest?
> >
> > I.e. if i extend the "is this bzImage working fine" check with the above
> > lguest bootup test - with the expectation of it getting down to the
> > "VFS: Unable to mount root" message [success case], how do i filter out
> > the case where it doesnt get to that message not due to some lguest
> > breakage, but because there's not enough lguest support there.
> 
> Easiest to check config: CONFIG_LGUEST and CONFIG_LGUEST_GUEST.
> 
> Well, there may be no host-for-lguest support, modular or builtin.  
> "modprobe lg" to be sure, then if lguest says: "lguest: Failed to open 
> /dev/lguest: No such file or directory" your host doesn't support it.
> 
> If there's no guest support, it's trickier.  The boot will fail in 
> some non-obvious way depending on config options....

that's why i'm lazily relying on in-kernel tests as much as possible. 
Within the kernel we always know whether it's OK. Could we load an 
lguest test-image via the firmware loader or something? That would make 
automated testing really, really self-contained.

plus "make Documentation/lguest/" could be bound into the random-testing 
environment as well. Would be glad to test-drive patches (even if just 
half-cooked), if you send any ...

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/