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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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. The mere fact that
populate-physmap and memory-exchange didn't return the
MFN(s) suggests to me that you already need to have a way
to deal with having to find out another way. Or are you
suggesting you rely on guests not using these interfaces?

As to a solution, I could possibly see us relax the change to
return the MFN(s) when the current and subject domains differ,
or even check paging mode of the caller domain instead of the
subject one (which would mean PVH Dom0 still wouldn't get to
see them). But if we do, imo we should do this consistently for
all three operations, rather than just for increase-reservation.

> If at all possible, I would like to request this change not to be part
> of the 4.9 release.

Hmm, it's been there for all of the RCs, so I'm not really happy
to consider the option of reverting at this point in time. But
Julien will have the final say anyway.

Jan


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