On Wed, Feb 22, 2012 at 10:15:50AM +0530, Cherry G. Mathew wrote:
> Hi Manuel,
>
> On 22 February 2012 00:40, Manuel Bouyer <bou...@netbsd.org> wrote:
> > Module Name: src
> > Committed By: bouyer
> > Date: Tue Feb 21 19:10:13 UTC 2012
> >
> > Modified Files:
> > src/sys/arch/x86/x86: pmap.c
> > src/sys/arch/xen/x86: cpu.c
> >
> > Log Message:
> > Avoid early use of xen_kpm_sync(); locks are not available at this time.
> > Don't call cpu_init() twice.
> >
> > Makes LOCKDEBUG kernels boot again
> >
> >
> > To generate a diff of this commit:
> > cvs rdiff -u -r1.166 -r1.167 src/sys/arch/x86/x86/pmap.c
>
> @@ -4183,14 +4183,30 @@
> pte = pmap_pa2pte(pa) | PG_k | PG_V | PG_RW;
> #ifdef XEN
> xpq_queue_pte_update(xpmap_ptetomach(&pdep[i]), pte);
> - if (level == PTP_LEVELS) {
> #if defined(PAE) || defined(__x86_64__)
> - if (i >= PDIR_SLOT_KERN) {
> + if (level == PTP_LEVELS && i >= PDIR_SLOT_KERN) {
> + if (__predict_true(
> + cpu_info_primary.ci_flags &
> CPUF_PRESENT)) {
>
>
> Can we use that as a canonical MI method in Xen to detect if the tls
> (gs/fs) has been setup ?
probably not; it works here because we want to know if we already
probed CPUs; I'm not sure CPUF_PRESENT will garantee that
curcpu() will work.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
