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 09:18:15 -0600 [thread overview]
Message-ID: <CABfawhmNw+hv0fxAj6NSbY2H8Ax+0eENTY98KXa8RPWPZ0hkGA@mail.gmail.com> (raw)
In-Reply-To: <CAFLBxZYhn9KUtVkwKC2LaaJmCsFL5c=E3NGtUjYsMHxFRYDQDw@mail.gmail.com>
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.
There's no problem
> with finding additional uses for it, as long as the *original* purpose
> doesn't get broken; and this patch most certainly does break things
> for that purpose.
This patch most certainly *does not break* the in-guest usecase by
itself. If the in-guest usecase is used without any mem_sharing going
on, this patch does not have any effect on that usecase.
Guests using altp2m should not have to know that
> sharing is happening behind their backs; nor should they be required
> to use mem_access to manually fix up what the hypervisor has allowed
> to be broken.
And they are not required. This requirement only applies if the user
mixes in in-guest and external usecases.
>
> If at the moment altp2m + memsharing just plain crashes, then that
> should be fixed; and if the lock-ordering parts of the patch fix that,
> then they should be applied.
Yes, that would be a start at least.
But the code which make sure that the
> same gfn range cannot both be shared and subject to altp2m must remain
> until they interact properly, with all the corner cases carefully
> thought out.
Well, I don't see that what you suggest is going to happen if
incremental improvements are not allowed in. Anyhow, at this point I'm
going to start carrying out-of-tree patches for Xen in my project and
just resign from my mem_sharing maintainership as I feel like it's
pretty pointless.
Tamas
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-07-18 15:18 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-26 3:55 [PATCH v4] altp2m: Allow the hostp2m entries to be of type p2m_ram_shared Tamas K Lengyel
2016-05-26 10:39 ` George Dunlap
2016-05-26 16:17 ` Tamas K Lengyel
2016-06-11 17:55 ` Tamas K Lengyel
2016-06-13 9:28 ` George Dunlap
2016-06-13 17:20 ` Tamas K Lengyel
2016-07-12 17:29 ` Tamas K Lengyel
2016-07-15 8:57 ` George Dunlap
2016-07-15 14:59 ` Tamas K Lengyel
2016-07-18 11:04 ` George Dunlap
2016-07-18 15:18 ` Tamas K Lengyel [this message]
2016-07-18 15:27 ` Andrew Cooper
2016-07-18 16:15 ` George Dunlap
2016-07-18 16:22 ` Tamas K Lengyel
2016-07-18 16:10 ` George Dunlap
2016-07-18 17:06 ` Tamas K Lengyel
2016-07-19 11:39 ` George Dunlap
2016-07-19 15:20 ` Tamas K Lengyel
2016-07-19 13:36 ` Ian Jackson
2016-07-19 15:31 ` Tamas K Lengyel
2016-07-19 17:11 ` George Dunlap
2016-07-19 19:12 ` Tamas K Lengyel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABfawhmNw+hv0fxAj6NSbY2H8Ax+0eENTY98KXa8RPWPZ0hkGA@mail.gmail.com \
--to=tamas@tklengyel.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=jbeulich@suse.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).