[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200803041737.24988.rusty@rustcorp.com.au>
Date: Tue, 4 Mar 2008 17:37:24 +1100
From: Rusty Russell <rusty@...tcorp.com.au>
To: Ingo Molnar <mingo@...e.hu>
Cc: "Ahmed S. Darwish" <darwish.07@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
LKML <linux-kernel@...r.kernel.org>, lguest@...abs.org,
akpm <akpm@...ux-foundation.org>,
Jeremy Fitzhardinge <jeremy@...source.com>
Subject: Re: [BUG + PATCH/Bugfix] x86/lguest: fix pgdir pmd index calculation
On Saturday 01 March 2008 06:58:38 Ingo Molnar wrote:
> * Ahmed S. Darwish <darwish.07@...il.com> wrote:
> > On the lguest _guest_ side, 'cpu_has_tsc' is _always_ false (due to
> > lguest using his own clocksource ?), thus a guest with a pentium+ cpu
> > always panics with:
>
> does the "RDTSC" instruction work in an lguest guest? If not, then the
> lguest kernel is correct in not exposing it - and then the solution is
> to build a non-TSC guest kernel. Does the patch below help?
>
> but if the RDTSC instruction does work in an lguest guest, then the
> proper approach would be to expose it in the CPU features.
>
> Ingo
It does (assuming host support), but when I tried to use the normal TSC code
it poked at other things which a guest couldn't do.
Currently I've hit another issue, but revisiting this is on my TODO. The
cpu_has_tsc panic is overzealous, since we deal without it, but it'd be nice
to use the common TSC clock code.
Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists