[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/arch/xen/x86
Thanks for the explanation!
Btw, it was not criticism but a question.
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
Main Index |
Thread Index |