On Mon, Jun 19, 2017 at 3:11 AM, George Dunlap <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. > > -George >
Of course if a suitable replacement can be made that gets me the information I need that would work too. At the moment I'm not aware of any other hypercall I could use for this purpose. Tamas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
