>>> On 19.06.17 at 11:11, <george.dun...@citrix.com> wrote: > On 19/06/17 09:15, Jan Beulich wrote: >>>>> On 18.06.17 at 21:19, <tamas.k.leng...@gmail.com> wrote: >>> On Tue, Apr 4, 2017 at 1:04 PM, Andrew Cooper <andrew.coop...@citrix.com> >>> wrote: >>>> On 04/04/17 14:14, Jan Beulich wrote: >>>>> We shouldn't hand MFN info back from increase-reservation for >>>>> translated domains, just like we don't for populate-physmap and >>>>> memory-exchange. For full symmetry also check for a NULL guest handle >>>>> in populate_physmap() (but note this makes no sense in >>>>> memory_exchange(), as there the array is also an input). >>>>> >>>>> Signed-off-by: Jan Beulich <jbeul...@suse.com> >>>> >>>> Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com> >>> >>> Unfortunately I just had time to do testing with this change and I >>> have to report that introduces a critical regression for my tools. >>> With this change in-place performing increase_reservation on a target >>> domain no longer reports the guest frame number for external tools, >>> thus completely breaking advanced use-cases that require this >>> information to be able to do altp2m gfn remapping. This is a critical >>> step in being able to introduce shadow-pages that are used to hide >>> breakpoints and other memory modifications from the guest. >> >> While I can see your point, I'm afraid that's not how the >> interface was meant to be used. > > Well the first question to ask is, is that hypercall part of the stable > interface? If so, then the standard should be, "Don't break people who > call it unless there is really no other way around it." Sure, it was a > mistake whoever introduced that, but if Tamas is building on a "stable" > interface he should be able to rely on that interface being maintained, > at least until we can find a suitable replacement.
Tool stack use of interfaces has never really been considered stable, i.e. the interfaces here are "stable" for a domain to use on itself, but fall in the same group as tool-stack only interfaces when using them on a foreign domain. At least that's the way I view it. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
