On 27/11/2018 10:16, Julien Grall wrote: > Hi, > > On 11/27/18 7:34 AM, Juergen Gross wrote: >> On 26/11/2018 17:51, Julien Grall wrote: >>> >>> >>> On 26/11/2018 16:17, Juergen Gross wrote: >>>> On 26/11/2018 17:01, Julien Grall wrote: >>>>> >>>>> >>>>> On 26/11/2018 15:29, Juergen Gross wrote: >>>>>> On 26/11/2018 15:58, Jan Beulich wrote: >>>>>>>>>> On 26.11.18 at 15:23, <jgr...@suse.com> wrote: >>>>>>>> On 26/11/2018 15:01, Jan Beulich wrote: >>>>>>>>>>>> On 26.11.18 at 14:52, <jgr...@suse.com> wrote: >>> Secondly, you are introducing an ABI change without explicitly telling >>> it. This should be clarified in the public interface and probably the >>> multicall code to avoid re-introducing the clobbering in the future. >> >> No, I don't think I'm introducing an ABI change. There is no guarantee >> Xen will clobber all multicall arguments. In fact a NDEBUG hypervisor >> never does. The guest must not rely on non-clobbered values, of course. > > The last sentence is what the ABI promises you. The rest is a > implementation decision to avoid performance impact. > > If you don't change the ABI, then how the guest will be able to know the > values are correct? Furthermore, as your change are not documented how > do you guarantee that this will not be reverted in the future?
This is for diagnostic purpose only. Common sense should be applied when interpreting the printed data, like e.g. in case of a stack backtrace. The guest doesn't have to know (and shouldn't) whether the data is clobbered or not. The person trying to locate a bug in the guest will be more capable to do so in case at least some of the additional data isn't clobbered. That's the reason for the patch. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
