Re: Xen modules

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Nov 10,  1:58am, Jean-Yves Migeon wrote:
} Le 08/11/2013 04:08, John Nemeth a écrit :
} >       There's basically two choices.  wbinvd() calls xpq_flush_cache().
} > It's the only caller.  So, the first choice is to change wbinvd()
} > to do the WBINVD and delete xpq_flush_cache().  The second option
} > is to modify xpq_flush_cache() to do the WBINVD instead of making
} > the hypercall, which is the method I tested since that's the smallest
} > change.  Right now, xpq_flush_cache() looks like:
} 
} The latter. Keep xpq_flush_cache() for now and replace the MMU flush by 
} the asm stub. That is the least intrusive. Otherwise that's good for me. 
} Thanks.

     Okay, this one has been done.

} >       The only modifications are to fix the issue above, set the
} > module loading path, and adding "options MODULAR" to the kernel
} > config file.  In other words, no significant changes.
} 
} Alright. I am currently looking at the Makefiles, but nothing seems to 
} alter symbol lookup (like visibility flags to ld(1)).
} 
} > } It's been a while since I looked at the Makefiles (under
} > } arch/xen/conf/), however Xen kernels are not built with OPT_MODULAR
} > } turned on IIRC.
} > }
} > } ldscripts should not differ much though (between i386/amd64 and xen).
} > }
} > } Sorry for not being more specific :/
} > }
} > } > # modload cd9660
} > } > kobj_checksyms, 881: [cd9660]: linker error: symbol `pool_destroy' not 
found
} > } > kobj_checksyms, 881: [cd9660]: linker error: symbol `brelse' not found
} > } > kobj_checksyms, 881: [cd9660]: linker error: symbol 
`uio_setup_sysspace' not found
} > } > kobj_checksyms, 881: [cd9660]: linker error: symbol `mutex_destroy' not 
found
} > } > WARNING: module error: unable to affix module `cd9660', error 8
} > }
} > } Difference in nm output between the two kernels for those symbols?
} >
} >       Other then the address, they look the same:
} >
} > P4-3679GHz: {194} nm netbsd-XEN3PAE_DOMU | grep pool_destroy
} > c038d960 T pool_destroy
} > P4-3679GHz: {195} nm netbsd-GENERIC | grep pool_destroy
} > c0814d07 T pool_destroy
} >
} > Same for the other symbols.
} 
} Indeed. However something to note: dom0 kernels are loaded as multiboot 
} components to the hypervisor, and I don't know how it behaves in regards 
} to ELF. A good test would be to load a domU and attempt a modload in the 
} domain.

     I am doing these tests in a domU.  Much easier to test things
that way.  Although if I was running in a dom0 I wouldn't have run
across the problem with xpq_flush_cache().

} Did you build the kernel with "options KSYMS_DEBUG"?

     I hadn't, but I tried now.  It didn't give any additional
output for the failure case or at boot time.  When successfully
loading a module (i.e. the example) module, it outputed a line
showing the symbol table addition.

     I tried uncommenting the makeoptions line that adds -g to the
compilation.  That resulted in more missing symbols.

}-- End of excerpt from Jean-Yves Migeon