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

From: George Dunlap <george.dunlap@citrix.com>
To: Tamas K Lengyel <tamas.k.lengyel@gmail.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Julien Grall <julien.grall@arm.com>,
	Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 2/2] memory: don't hand MFN info to translated guests
Date: Mon, 19 Jun 2017 15:54:16 +0100	[thread overview]
Message-ID: <0d6fffef-fc0a-9843-8138-c20c898281f3@citrix.com> (raw)
In-Reply-To: <CABfawhnPZ5octUMx1rOvu2aCjaiCwOkHR-mdxJbkyATcZ6mpKA@mail.gmail.com>

On 19/06/17 15:48, Tamas K Lengyel wrote:
> On Mon, Jun 19, 2017 at 3:11 AM, George Dunlap <george.dunlap@citrix.com> wrote:
>> On 19/06/17 09:15, Jan Beulich wrote:
>>>>>> On 18.06.17 at 21:19, <tamas.k.lengyel@gmail.com> wrote:
>>>> On Tue, Apr 4, 2017 at 1:04 PM, Andrew Cooper <andrew.cooper3@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 <jbeulich@suse.com>
>>>>>
>>>>> Reviewed-by: Andrew Cooper <andrew.cooper3@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.

So actually -- it sounds like both Jan and I misunderstood the
situation.  The header file clearly says:

     * XENMEM_increase_reservation:
     *   OUT: MFN (*not* GMFN) bases of extents that were allocated

Are you saying that for HVM guests, that statement is false?

 -George

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