Re: CVS commit: src/sys/arch/xen/x86

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

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