Re: [PATCH v1] Add build-id to XENVER hypercall.

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Fri, Oct 09, 2015 at 09:14:00AM -0600, Jan Beulich wrote:
> >>> On 09.10.15 at 15:25, <konrad.wilk@oracle.com> wrote:
> > On Fri, Oct 09, 2015 at 01:15:42PM +0100, Andrew Cooper wrote:
> >> On 09/10/15 09:17, Jan Beulich wrote:
> >> >>>> On 09.10.15 at 04:56, <konrad.wilk@oracle.com> wrote:
> >> >> However they also change the behavior of the existing hypercall
> >> >> for XENVER_[compile_info|changeset|commandline] and make them
> >> >> dom0 accessible. This is if XSM is built in or not (though with
> >> >> XSM one can expose it to a guest if desired).
> >> > Wasn't the outcome of the previous discussion that we should not
> >> > alter default behavior for existing sub-ops?
> >> 
> >> I raised a worry that some guests might break if they suddenly have
> >> access to this information cut off.
> > 
> > Let me double-confirm that the guests are OK with this being
> > gone. I did ran tests to see if the worked, but hadn't actually tried
> > acessing (/sys/hypervisor/xen*) the values.
> 
> Well, this is the kind of thing you can't find out by testing _some_
> guest(s) - you'd need to test with all possible ones, which of course
> is not feasible. Hence we need to be very conservative when

I was thinking to test:

F19-64 F19-32 F17-64 F17-32 F16-32
F16-64 F15-32 F15-64 NetBSD FreeBSD RHEL5-64 RHEL5-32 SLES11-32 SLES12-32
OL6_X86_64_PVHVM OL6_X86_64_PV OL5_X86_64_PVHVM Win2K (with SuSE PV drivers)
WinXP (with Windows GPL drivers) and Windows 7 (with Windows GPL), SOL12

And see what happens when those are not available (poke in /sysfs or whatever
I can)

> deciding to restrict part of a so far guest-kind-indifferent ABI.

Right, so only three of them are off.

Perhaps an another option would be to return success and fill out the
value with an empty string?

That actually sounds nicer.
> 
> Jan
>