Re: [Xen-devel] [PATCH 2/2] memory: don't hand MFN info to translated guests

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.06.17 at 11:11, <george.dunlap@xxxxxxxxxx> wrote:
> On 19/06/17 09:15, Jan Beulich wrote:
>>>>> On 18.06.17 at 21:19, <tamas.k.lengyel@xxxxxxxxx> wrote:
>>> On Tue, Apr 4, 2017 at 1:04 PM, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 
>>> 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 <jbeulich@xxxxxxxx>
>>>>
>>>> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>>
>>> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel