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>
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. 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.

I am a bit confuse with the description of the problem. I understood "guest frame number" as GFN. But AFAICT, this hypercall was returning MFN even for HVM guests. So how this change is breaking altp2m remapping?


Julien Grall

Xen-devel mailing list

Reply via email to