On 15/06/18 16:06, Jan Beulich wrote: >>>> On 15.06.18 at 15:26, <jgr...@suse.com> wrote: >> Add a new function to query whether hypercall buffers are always safe >> to access by the hypervisor or might result in EFAULT. >> >> Signed-off-by: Juergen Gross <jgr...@suse.com> >> --- >> tools/libs/call/Makefile | 2 +- >> tools/libs/call/freebsd.c | 5 +++++ >> tools/libs/call/include/xencall.h | 7 +++++++ >> tools/libs/call/libxencall.map | 5 +++++ >> tools/libs/call/linux.c | 5 +++++ >> tools/libs/call/minios.c | 5 +++++ >> tools/libs/call/netbsd.c | 5 +++++ >> tools/libs/call/solaris.c | 5 +++++ >> 8 files changed, 38 insertions(+), 1 deletion(-) > > Did you verify all of them to indeed be safe? If not, wouldn't it be better to > default to unsafe?
Minios is safe, Roger told me that BSDs are so, too. I don't think Solaris is critical, as I can't see how libxencall would even build there (osdep_hypercall() is misnamed). > For Linux, is there perhaps a way to figure out whether the problem > features don't exist (or are disabled) in the kernel, so that (especially > on older kernels, where the privcmd driver surely is an old one) you > don't needlessly do the retries? TBH, I think this would be overkill. Any EFAULT is either a bug in the tools, so a retry would not change anything, or it is due to the problem the patch is addressing. Adding additional coding to avoid retries in the case of a bug in the tools seems not to be appropriate. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
