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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 19/06/17 15:48, Tamas K Lengyel wrote:
> On Mon, Jun 19, 2017 at 3:11 AM, George Dunlap <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.
>>
>>  -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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel