All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Razvan Cojocaru <rcojocaru@bitdefender.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH V7 2/5] x86/mm: allocate logdirty_ranges for altp2ms
Date: Tue, 20 Nov 2018 03:27:35 -0700	[thread overview]
Message-ID: <5BF3E19702000078001FDE75@prv1-mh.provo.novell.com> (raw)
In-Reply-To: <286c5d63-3964-9587-f67e-16fb86da5970@bitdefender.com>

>>> On 20.11.18 at 11:02, <rcojocaru@bitdefender.com> wrote:
> On 11/20/18 11:05 AM, Jan Beulich wrote:
>>>>> On 19.11.18 at 18:26, <rcojocaru@bitdefender.com> wrote:
>>> For now, only do allocation/deallocation; keeping them in sync
>>> will be done in subsequent patches.
>>>
>>> Logdirty synchronization will only be done for active altp2ms;
>>> so allocate logdirty rangesets (copying the host logdirty
>>> rangeset) when an altp2m is activated, and free it when
>>> deactivated.
>>>
>>> Write a helper function to do altp2m activiation (appropriately
>>> handling failures). Also, refactor p2m_reset_altp2m() so that it
>>> can be used to remove redundant codepaths, fixing the locking
>>> while we’re at it.
>> 
>> Perhaps this should have been a separate patch again, such
>> that e.g. ...
>> 
>>> +static void p2m_reset_altp2m(struct domain *d, unsigned int idx,
>>> +                             enum altp2m_reset_type reset_type)
>>> +{
>>> +    struct p2m_domain *p2m;
>>> +
>>> +    ASSERT(idx < MAX_ALTP2M);
>>> +    p2m = d->arch.altp2m_p2m[idx];
>>> +
>>> +    p2m_lock(p2m);
>>> +
>>> +    p2m_flush_table_locked(p2m);
>>> +
>>> +    if ( reset_type == ALTP2M_DEACTIVATE )
>>> +        p2m_free_logdirty(p2m);
>>> +
>>> +    /* Uninit and reinit ept to force TLB shootdown */
>>> +    ept_p2m_uninit(p2m);
>>> +    ept_p2m_init(p2m);
>>> +
>>> +    p2m->min_remapped_gfn = gfn_x(INVALID_GFN);
>>> +    p2m->max_remapped_gfn = 0;
>> 
>> ... the addition of these can be properly associated with either
>> part of the change. Looking at the code you remove from e.g.
>> p2m_flush_altp2m() it's not part of the refactoring, but of what
>> this patch's actual purpose is. But this is guesswork of mine
>> without the split and without the addition getting explained,
>> not the least because this getting moved here from the original
>> instance of the function might also mean that it's part of the
>> refactoring, but would then need to be done only in the
>> ALTP2M_RESET case.
> 
> If you mean that p2m->min_remapped_gfn = gfn_x(INVALID_GFN); and
> p2m->max_remapped_gfn = 0; should only happen on the ALTP2M_RESET case,
> while that is technically true (and should follow from a verbatim
> refactoring), George has pointed out that the assignments are in that
> case unnecessary but harmless, and so the conditional is not worth it.
> 
> I can add the if and treat the RESET case explicitly if that's required.

No, I'm specifically not requiring this. What I'm requiring is that the
description match the changes. Which in turn would be easier if
the refactoring was a separate patch.

Jan


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

  reply	other threads:[~2018-11-20 10:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-19 17:26 (no subject) Razvan Cojocaru
2018-11-19 17:26 ` [PATCH V7 1/5] x86/mm: introduce p2m_{init, free}_logdirty() Razvan Cojocaru
2018-11-19 17:26 ` [PATCH V7 2/5] x86/mm: allocate logdirty_ranges for altp2ms Razvan Cojocaru
2018-11-20  9:05   ` Jan Beulich
2018-11-20 10:02     ` Razvan Cojocaru
2018-11-20 10:27       ` Jan Beulich [this message]
2018-11-20 10:29         ` Razvan Cojocaru
2018-11-19 17:26 ` [PATCH V7 3/5] x86/altp2m: fix display frozen when switching to a new view early Razvan Cojocaru
2018-11-20  9:12   ` Jan Beulich
2018-11-20  9:30     ` Razvan Cojocaru
2018-11-20  9:43     ` George Dunlap
2018-11-20 10:03       ` Jan Beulich
2018-11-19 17:26 ` [PATCH V7 4/5] p2m: Always use hostp2m when clipping rangesets Razvan Cojocaru
2018-11-19 17:26 ` [PATCH V7 5/5] p2m: change_range_type: Only invalidate mapped gfns Razvan Cojocaru
2018-11-19 17:34 ` (no subject) Razvan Cojocaru

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=5BF3E19702000078001FDE75@prv1-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=rcojocaru@bitdefender.com \
    --cc=wei.liu2@citrix.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.