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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

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.

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel