Thanks for the explanation! Btw, it was not criticism but a question.
- Jukka. On Mon, Nov 11, 2013 at 12:31:19PM -0800, John Nemeth wrote: > On Nov 11, 1:05pm, Jukka Ruohonen wrote: > } On Mon, Nov 11, 2013 at 02:52:30AM -0800, John Nemeth wrote: > } > My point is, if you want to know, go read the thread in port-xen@, > } > or the code. Also, what "trivial function for Xen"? > } > } The wrappers in cpufunc.S'es. > > So that would be sys/arch/amd64/amd64/cpufunc.S where the > function is wrapped with ifndef XEN, or sys/arch/i386/i386/i386func.S > which has a comment near the top that says, "These are _not_ shared > with NetBSD/xen." The Xen version of wbinvd() is located in > sys/arch/xen/x86/xenfunc.c and it is indeed a simple wrapper > function, containing the single line, xpq_flush_cache();, as I > alluded to earlier in text that you snipped. > > Xen domU kernels are essentially "userland applications" for > the Xen hypervisor. They do not have direct hardware access and > are not privileged. They must make a hypervisor "syscall" to > perform many normal kernel functions. xpq_flush_cache() did this. > However, it was using a privileged operation that only dom0 kernels > (or domU kernels that were specially granted the privilege) are > allowed to do. Even Xen dom0 kernels which are allowed direct > hardware access are basically a "userland application" for the Xen > hypervisor and must a hypervisor "syscall" for many things. Now, > I suppose I could have created a sys/arch/xen/xen/cpufunc.S with > the single function xen_wbinvd() that contains the single line > wbinvd, but why bother? > > It is apparent that you are completely unfamiliar with the > code that you are criticising, and as such this will be my last > post on the subject. I don't know if you are famailiar with > nxr.netbsd.org, but it is a great tool for chasing down things like > this. Putting wbinvd in the Definition box would have turned up > all this stuff. > > }-- End of excerpt from Jukka Ruohonen
