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

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

On Mon, Jun 19, 2017 at 8:54 AM, George Dunlap <george.dunlap@xxxxxxxxxx> wrote:
> 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?
>

Well, it would certainly appear so as I  have been using it to add
memory to a guest and then map it into the guest physmap as a new gfn.
I've been using it like that since Xen 4.6 without any problems.

Tamas

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