Re: [PATCH v4] altp2m: Allow the hostp2m entries to be of type p2m_ram_shared

From: Tamas K Lengyel <tamas@tklengyel.com>
To: George Dunlap <george.dunlap@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v4] altp2m: Allow the hostp2m entries to be of type p2m_ram_shared
Date: Mon, 18 Jul 2016 10:22:15 -0600	[thread overview]
Message-ID: <CABfawh=jrrN+ak0JAMQ8VEU2nKjBg3qsG98SurSbHU6ELYi=2A@mail.gmail.com> (raw)
In-Reply-To: <bd464397-c5d4-499d-3115-4d49437c8570@citrix.com>

On Mon, Jul 18, 2016 at 10:15 AM, George Dunlap
<george.dunlap@citrix.com> wrote:
> On 18/07/16 16:27, Andrew Cooper wrote:
>> On 18/07/16 16:18, Tamas K Lengyel wrote:
>>> On Mon, Jul 18, 2016 at 5:04 AM, George Dunlap <george.dunlap@citrix.com> wrote:
>>>> On Fri, Jul 15, 2016 at 3:59 PM, Tamas K Lengyel <tamas@tklengyel.com> wrote:
>>>>>> I could go on in the analysis, but the point is that there's a morass
>>>>>> of interactions here all of which need to be correct, which this patch
>>>>>> does not address.  You have a long way to go before sharing and altp2m
>>>>>> can be safely used on the same gfn ranges.
>>>>>>
>>>>> Hi George,
>>>>> certainly there are cornercases where if the user does not setup things in
>>>>> the right order things can still go out of whack. My goal with this patch is
>>>>> not to address all of them. The goal of this patch is to not crash the
>>>>> hypervisor when the user at least tries to experiment with it, which is the
>>>>> current state. So this patch improves the status quo. Also, both mem_sharing
>>>>> and altp2m is considered experimental/tech_preview, so the fact that their
>>>>> combination is also experimental should be assumed as well. As I explained,
>>>>> with this patch in place there is at least one way they can be safely used
>>>>> together if the user tracks unsharing requirements through mem_access and
>>>>> does unsharing and fixup of the altp2m views manually. There are other ways
>>>>> where it would not be safe as after unsharing we don't know how the user
>>>>> would want things to look in altp2ms. I don't think we want to start
>>>>> guessing about that either so I will not be looking to implement that. So I
>>>>> don't agree with this reasoning being grounds for rejecting this patch that
>>>>> does incrementally improve the current state.
>>>> So you keep saying "user"; I assume you mean whatever program is
>>>> sitting in domain 0, which is going to be doing memsharing, altp2m,
>>>> and memaccess stuff all at once?
>>>>
>>>> The altp2m code was not written for that purpose.  It was written for
>>>> *guest* administrators to use within the guest.
>>> That's simply not true. It was written specifically to allow both
>>> usecases - both internal *and* external. Mixing the use-cases was not
>>> envisioned.
>>
>> Tamas is correct here.  altp2m was specifically designed and implemented
>> usable by both internal and external entities, irrespective of hardware
>> support.
>>
>> Any modifications to the subsystem should maintain this property.
>
> Indeed; it was also designed to be robust when used with sharing
> (although it was apparently never tested, because it's currently broken
> in that respect).  And it is this property that I'm trying to maintain,
> both for internal and external users.
>

It was tested and the hypervisor crash was pointed out during the
merging process of altp2m, but it was let in anyway as both
mem_sharing and altp2m was considered experimental and thus this crash
in a cornercase was deemed acceptable.

Tamas

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