Re: Xen modules

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

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.

>       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.

Did you build the kernel with "options KSYMS_DEBUG"?

Cheers,

--
Jean-Yves Migeon