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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 18/07/16 16:18, Tamas K Lengyel wrote:
> On Mon, Jul 18, 2016 at 5:04 AM, George Dunlap <george.dunlap@xxxxxxxxxx> 
> wrote:
>> On Fri, Jul 15, 2016 at 3:59 PM, Tamas K Lengyel <tamas@xxxxxxxxxxxxx> 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.

~Andrew

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