Re: CVS commit: src/sys/arch/xen/x86
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
Re: CVS commit: src/sys/arch/xen/x86
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
Re: CVS commit: src/sys/arch/xen/x86
On Nov 11, 12:30pm, Jukka Ruohonen wrote: } On Sun, Nov 10, 2013 at 11:17:54AM -0800, John Nemeth wrote: } > } x86_wbind()? Which however appears to be (icorrectly?) #ifndef'd for Xen. } > } > Uh, the function for Xen would be wbinvd(), which would create } > a very nice infinite loop as all that function does is call } > xpq_flush_cache(). This change was fully discussed on tech-xen@. Oops, that should be port-xen@ } My point kind of was that why not fix the trivial function for Xen instead } of a direct asm() call? My point is, if you want to know, go read the thread in port-xen@, or the code. Also, what "trivial function for Xen"? }-- End of excerpt from Jukka Ruohonen
Re: CVS commit: src/sys/arch/xen/x86
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. - Jukka.
Re: CVS commit: src/sys/arch/xen/x86
On Sun, Nov 10, 2013 at 11:17:54AM -0800, John Nemeth wrote: > } x86_wbind()? Which however appears to be (icorrectly?) #ifndef'd for Xen. > > Uh, the function for Xen would be wbinvd(), which would create > a very nice infinite loop as all that function does is call > xpq_flush_cache(). This change was fully discussed on tech-xen@. My point kind of was that why not fix the trivial function for Xen instead of a direct asm() call? - Jukka.
