All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Xia, Hongyan" <hongyxia@amazon.com>
To: "jbeulich@suse.com" <jbeulich@suse.com>
Cc: "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"wl@xen.org" <wl@xen.org>,
	"roger.pau@citrix.com" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 6/9] x86/mm: add an end_of_loop label in map_pages_to_xen
Date: Thu, 5 Dec 2019 10:21:56 +0000	[thread overview]
Message-ID: <f13c0e4808e320a0233f82b9be005fe5b2679469.camel@amazon.com> (raw)
In-Reply-To: <3885863bfc54a5f5f05cddb3cd9afe24897f27b3.1575477921.git.hongyxia@amazon.com>

>On 02.10.2019 19:16, Hongyan Xia wrote:
>> We will soon need to clean up mappings whenever the out most loop is
>> ended. Add a new label and turn relevant continue's into goto's.
>
>I think already when this still was RFC I did indicate that I'm not
>happy about the introduction of these labels (including also patch 8).
>I realize it's quite a lot to ask, but both functions would benefit
>from splitting up into per-level helper functions, which - afaict -
>would avoid the need for such labels, and which would at the same
>time likely make it quite a bit easier to extend these to the
>5-level page tables case down the road.
>
>Thoughts?
>
>Jan

A common pattern I have found when mapping PTE pages on-demand (and I
think is the exact intention of these labels from Wei, also described
in the commit message) is that we often need to do:

map some pages - process those pages - error occurs or this iteration
of loop can be skipped - _clean up the mappings_ - continue or return

As long as cleaning up is required, these labels will likely be needed
as the clean-up path before skipping or returning, so I would say we
will see such labels even if we split it into helper functions
(virt_to_xen_l[123]e() later in the patch series is an example). I see
the labels more or less as orthogonal to modularising into helper
functions.

I would also like to see some helpers because these functions are
getting too long and convoluted, but I wonder if they could be another
mini-series outside the directmap-removal series.

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

  reply	other threads:[~2019-12-05 10:22 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-04 17:10 [Xen-devel] [PATCH v4 0/9] Add alternative API for Xen PTEs Hongyan Xia
2019-12-04 17:10 ` [Xen-devel] [PATCH v4 1/9] x86: move some xen mm function declarations Hongyan Xia
2019-12-04 17:10 ` [Xen-devel] [PATCH v4 2/9] x86: introduce a new set of APIs to manage Xen page tables Hongyan Xia
2019-12-04 17:54   ` Xia, Hongyan
2019-12-05  7:20     ` Jan Beulich
2019-12-11 16:33   ` Julien Grall
2019-12-04 17:10 ` [Xen-devel] [PATCH v4 3/9] x86/mm: introduce l{1, 2}t local variables to map_pages_to_xen Hongyan Xia
2019-12-04 18:01   ` Xia, Hongyan
2019-12-05  8:38     ` Jan Beulich
2019-12-04 17:10 ` [Xen-devel] [PATCH v4 4/9] x86/mm: introduce l{1, 2}t local variables to modify_xen_mappings Hongyan Xia
2019-12-12 14:34   ` Julien Grall
2019-12-04 17:10 ` [Xen-devel] [PATCH v4 5/9] x86/mm: map_pages_to_xen would better have one exit path Hongyan Xia
2019-12-04 17:10 ` [Xen-devel] [PATCH v4 6/9] x86/mm: add an end_of_loop label in map_pages_to_xen Hongyan Xia
2019-12-05 10:21   ` Xia, Hongyan [this message]
2019-12-05 10:25     ` Jan Beulich
2019-12-05 11:02       ` Durrant, Paul
2019-12-05 11:12         ` Jan Beulich
2019-12-05 13:22           ` Xia, Hongyan
2019-12-06 15:58           ` Xia, Hongyan
2019-12-04 17:10 ` [Xen-devel] [PATCH v4 7/9] x86/mm: make sure there is one exit path for modify_xen_mappings Hongyan Xia
2019-12-04 17:11 ` [Xen-devel] [PATCH v4 8/9] x86/mm: add an end_of_loop label in modify_xen_mappings Hongyan Xia
2019-12-04 17:11 ` [Xen-devel] [PATCH v4 9/9] x86/mm: change pl*e to l*t in virt_to_xen_l*e Hongyan Xia
2019-12-05  9:14 ` [Xen-devel] [PATCH v4 0/9] Add alternative API for Xen PTEs Jan Beulich
2019-12-05  9:41   ` Xia, Hongyan
2019-12-05  9:51     ` Jan Beulich
2019-12-05 10:45       ` Xia, Hongyan

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=f13c0e4808e320a0233f82b9be005fe5b2679469.camel@amazon.com \
    --to=hongyxia@amazon.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=wl@xen.org \
    --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.