All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@citrix.com>
To: Tamas K Lengyel <tamas@tklengyel.com>
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"rcojocaru@bitdefender.com" <rcojocaru@bitdefender.com>,
	"george.dunlap@eu.citrix.com" <george.dunlap@eu.citrix.com>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	Alexandru Stefan ISAILA <aisaila@bitdefender.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"roger.pau@citrix.com" <roger.pau@citrix.com>
Subject: Re: [PATCH v5] x86/altp2m: Aggregate get entry and populate into common funcs
Date: Tue, 16 Apr 2019 16:07:47 +0100	[thread overview]
Message-ID: <d0f438e1-fe1e-dd44-bcdb-f77c5949c7de@citrix.com> (raw)
In-Reply-To: <CABfawhmsbH_9zByK6XoZfVT2BCVf73Wv9PrXbHMm-eXUqKnjxA@mail.gmail.com>

On 4/16/19 3:19 PM, Tamas K Lengyel wrote:
> On Tue, Apr 16, 2019 at 8:02 AM George Dunlap <george.dunlap@citrix.com> wrote:
>>
>> On 4/16/19 2:44 PM, Tamas K Lengyel wrote:
>>> On Tue, Apr 16, 2019 at 2:45 AM Alexandru Stefan ISAILA
>>> <aisaila@bitdefender.com> wrote:
>>>>
>>>> The code for getting the entry and then populating was repeated in
>>>> p2m_change_altp2m_gfn() and in p2m_set_altp2m_mem_access().
>>>>
>>>> The code is now in one place with a bool param that lets the caller choose
>>>> if it populates after get_entry().
>>>>
>>>> If remapping is being done then both the old and new gfn's should be
>>>> unshared in the hostp2m for keeping things consistent. The page type
>>>> of old_gfn was already checked whether it's p2m_ram_rw and bail if it
>>>> wasn't so functionality-wise this just simplifies things as a user
>>>> doesn't have to request unsharing manually before remapping.
>>>> Now, if the new_gfn is invalid it shouldn't query the hostp2m as
>>>> that is effectively a request to remove the entry from the altp2m.
>>>> But provided that scenario is used only when removing entries that
>>>> were previously remapped/copied to the altp2m, those entries already
>>>> went through P2M_ALLOC | P2M_UNSHARE before, so it won't have an
>>>> affect so the core function get_altp2m_entry() is calling
>>>> __get_gfn_type_access() with P2M_ALLOC | P2M_UNSHARE.
>>>>
>>>> altp2m_get_entry_direct() is also called in p2m_set_suppress_ve()
>>>> because on a new altp2m view the function will fail with invalid mfn if
>>>> p2m->set_entry() was not called before.
>>>>
>>>> Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com>
>>>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
>>>> Reviewed-by: George Dunlap <george.dunlap@citrix.com>
>>>>
>>>> ---
>>>> Changes since V4:
>>>>         - Add altp2m to patch name
>>>>         - Change func name from get_altp2m_entry() to
>>>> altp2m_get_entry().
>>>> ---
>>>>  xen/arch/x86/mm/mem_access.c | 30 ++-----------
>>>>  xen/arch/x86/mm/p2m.c        | 84 ++++++++++++++++++++----------------
>>>>  xen/include/asm-x86/p2m.h    | 17 ++++++++
>>>>  3 files changed, 66 insertions(+), 65 deletions(-)
>>>>
>>>> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
>>>> index a144bb0ce4..ddfe0169c0 100644
>>>> --- a/xen/arch/x86/mm/mem_access.c
>>>> +++ b/xen/arch/x86/mm/mem_access.c
>>>> @@ -262,35 +262,11 @@ int p2m_set_altp2m_mem_access(struct domain *d, struct p2m_domain *hp2m,
>>>>      mfn_t mfn;
>>>>      p2m_type_t t;
>>>>      p2m_access_t old_a;
>>>> -    unsigned int page_order;
>>>> -    unsigned long gfn_l = gfn_x(gfn);
>>>>      int rc;
>>>>
>>>> -    mfn = ap2m->get_entry(ap2m, gfn, &t, &old_a, 0, NULL, NULL);
>>>> -
>>>> -    /* Check host p2m if no valid entry in alternate */
>>>> -    if ( !mfn_valid(mfn) )
>>>> -    {
>>>> -
>>>> -        mfn = __get_gfn_type_access(hp2m, gfn_l, &t, &old_a,
>>>> -                                    P2M_ALLOC | P2M_UNSHARE, &page_order, 0);
>>>> -
>>>> -        rc = -ESRCH;
>>>> -        if ( !mfn_valid(mfn) || t != p2m_ram_rw )
>>>> -            return rc;
>>>> -
>>>> -        /* If this is a superpage, copy that first */
>>>> -        if ( page_order != PAGE_ORDER_4K )
>>>> -        {
>>>> -            unsigned long mask = ~((1UL << page_order) - 1);
>>>> -            gfn_t gfn2 = _gfn(gfn_l & mask);
>>>> -            mfn_t mfn2 = _mfn(mfn_x(mfn) & mask);
>>>> -
>>>> -            rc = ap2m->set_entry(ap2m, gfn2, mfn2, page_order, t, old_a, 1);
>>>> -            if ( rc )
>>>> -                return rc;
>>>> -        }
>>>> -    }
>>>> +    rc = altp2m_get_entry_prepopulate(ap2m, gfn, &mfn, &t, &old_a);
>>>> +    if ( rc )
>>>> +        return rc;
>>>>
>>>>      /*
>>>>       * Inherit the old suppress #VE bit value if it is already set, or set it
>>>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>>>> index 9e81a30cc4..7bedfd593b 100644
>>>> --- a/xen/arch/x86/mm/p2m.c
>>>> +++ b/xen/arch/x86/mm/p2m.c
>>>
>>> Wouldn't it make more sense to start adding new altp2m functions to
>>> mm/altp2m.c instead? Probably the altp2m functions from mm/p2m.c could
>>> also be relocated there at some point in the future.
>>>
>>>> @@ -478,6 +478,43 @@ void p2m_unlock_and_tlb_flush(struct p2m_domain *p2m)
>>>>          mm_write_unlock(&p2m->lock);
>>>>  }
>>>>
>>>> +int altp2m_get_entry(struct p2m_domain *ap2m,
>>>> +                            gfn_t gfn, mfn_t *mfn, p2m_type_t *t,
>>>> +                            p2m_access_t *a, bool prepopulate)
>>>> +{
>>>> +    *mfn = ap2m->get_entry(ap2m, gfn, t, a, 0, NULL, NULL);
>>>> +
>>>> +    /* Check host p2m if no valid entry in alternate */
>>>> +    if ( !mfn_valid(*mfn) && !p2m_is_hostp2m(ap2m) )
>>>> +    {
>>>> +        struct p2m_domain *hp2m = p2m_get_hostp2m(ap2m->domain);
>>>> +        unsigned int page_order;
>>>> +        int rc;
>>>> +
>>>> +        *mfn = __get_gfn_type_access(hp2m, gfn_x(gfn), t, a,
>>>> +                                     P2M_ALLOC | P2M_UNSHARE, &page_order, 0);
>>>
>>> So despite the name being altp2m_get_entry you now return an entry
>>> from the hostp2m, even if prepopulate is false. If the caller knows it
>>> doesn't want that entry to be copied into the altp2m, why not have it
>>> call __get_gfn_type_access itself for the hostp2m? IMHO this is just
>>> confusing and doesn't help readability of the altp2m code.
>>
>> You return the ap2m entry if it's present, or the hp2m entry if it's
>> not.  It's not a lot of duplication, but it makes the logic cleaner I
>> think; why not deduplicate it?
> 
> I have no problem with making the code more streamlined. The problem I
> have is that the function's name doesn't suggest it would get you
> anything but the entry from the specified altp2m. So you could be
> reading the code assuming you are dealing with an entry from that
> specified table when in fact you are not. That is not an expected
> behavior based on just the name of the function. This is going to make
> reading the altp2m code that much harder in the future.

Right -- I wasn't a huge fan of 'direct' either; it didn't really convey
to me 100% what the function did.  My PoC had "seethrough", but that
wasn't that great either.  "Peek"?  Any other suggestions?

Other options:

* If we have a single function with a #define, this might get a bit
easier;  we could have one be AP2MGET_dont_prepopulate or something.

( We could have the "core" function named _altp2m_get_entry, and have
altp2m_get_entry() call with prepopulate = false, and
altp2m_get_entry_prepopulate() call it with prepopulate = true.

Thoughts?

 -George

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

WARNING: multiple messages have this Message-ID (diff)
From: George Dunlap <george.dunlap@citrix.com>
To: Tamas K Lengyel <tamas@tklengyel.com>
Cc: "wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"rcojocaru@bitdefender.com" <rcojocaru@bitdefender.com>,
	"george.dunlap@eu.citrix.com" <george.dunlap@eu.citrix.com>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	Alexandru Stefan ISAILA <aisaila@bitdefender.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"roger.pau@citrix.com" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v5] x86/altp2m: Aggregate get entry and populate into common funcs
Date: Tue, 16 Apr 2019 16:07:47 +0100	[thread overview]
Message-ID: <d0f438e1-fe1e-dd44-bcdb-f77c5949c7de@citrix.com> (raw)
Message-ID: <20190416150747.1F4t9a9wlGh4E2Z4m1V0GSoYK3N6vXZVvoWvot7T840@z> (raw)
In-Reply-To: <CABfawhmsbH_9zByK6XoZfVT2BCVf73Wv9PrXbHMm-eXUqKnjxA@mail.gmail.com>

On 4/16/19 3:19 PM, Tamas K Lengyel wrote:
> On Tue, Apr 16, 2019 at 8:02 AM George Dunlap <george.dunlap@citrix.com> wrote:
>>
>> On 4/16/19 2:44 PM, Tamas K Lengyel wrote:
>>> On Tue, Apr 16, 2019 at 2:45 AM Alexandru Stefan ISAILA
>>> <aisaila@bitdefender.com> wrote:
>>>>
>>>> The code for getting the entry and then populating was repeated in
>>>> p2m_change_altp2m_gfn() and in p2m_set_altp2m_mem_access().
>>>>
>>>> The code is now in one place with a bool param that lets the caller choose
>>>> if it populates after get_entry().
>>>>
>>>> If remapping is being done then both the old and new gfn's should be
>>>> unshared in the hostp2m for keeping things consistent. The page type
>>>> of old_gfn was already checked whether it's p2m_ram_rw and bail if it
>>>> wasn't so functionality-wise this just simplifies things as a user
>>>> doesn't have to request unsharing manually before remapping.
>>>> Now, if the new_gfn is invalid it shouldn't query the hostp2m as
>>>> that is effectively a request to remove the entry from the altp2m.
>>>> But provided that scenario is used only when removing entries that
>>>> were previously remapped/copied to the altp2m, those entries already
>>>> went through P2M_ALLOC | P2M_UNSHARE before, so it won't have an
>>>> affect so the core function get_altp2m_entry() is calling
>>>> __get_gfn_type_access() with P2M_ALLOC | P2M_UNSHARE.
>>>>
>>>> altp2m_get_entry_direct() is also called in p2m_set_suppress_ve()
>>>> because on a new altp2m view the function will fail with invalid mfn if
>>>> p2m->set_entry() was not called before.
>>>>
>>>> Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com>
>>>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
>>>> Reviewed-by: George Dunlap <george.dunlap@citrix.com>
>>>>
>>>> ---
>>>> Changes since V4:
>>>>         - Add altp2m to patch name
>>>>         - Change func name from get_altp2m_entry() to
>>>> altp2m_get_entry().
>>>> ---
>>>>  xen/arch/x86/mm/mem_access.c | 30 ++-----------
>>>>  xen/arch/x86/mm/p2m.c        | 84 ++++++++++++++++++++----------------
>>>>  xen/include/asm-x86/p2m.h    | 17 ++++++++
>>>>  3 files changed, 66 insertions(+), 65 deletions(-)
>>>>
>>>> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
>>>> index a144bb0ce4..ddfe0169c0 100644
>>>> --- a/xen/arch/x86/mm/mem_access.c
>>>> +++ b/xen/arch/x86/mm/mem_access.c
>>>> @@ -262,35 +262,11 @@ int p2m_set_altp2m_mem_access(struct domain *d, struct p2m_domain *hp2m,
>>>>      mfn_t mfn;
>>>>      p2m_type_t t;
>>>>      p2m_access_t old_a;
>>>> -    unsigned int page_order;
>>>> -    unsigned long gfn_l = gfn_x(gfn);
>>>>      int rc;
>>>>
>>>> -    mfn = ap2m->get_entry(ap2m, gfn, &t, &old_a, 0, NULL, NULL);
>>>> -
>>>> -    /* Check host p2m if no valid entry in alternate */
>>>> -    if ( !mfn_valid(mfn) )
>>>> -    {
>>>> -
>>>> -        mfn = __get_gfn_type_access(hp2m, gfn_l, &t, &old_a,
>>>> -                                    P2M_ALLOC | P2M_UNSHARE, &page_order, 0);
>>>> -
>>>> -        rc = -ESRCH;
>>>> -        if ( !mfn_valid(mfn) || t != p2m_ram_rw )
>>>> -            return rc;
>>>> -
>>>> -        /* If this is a superpage, copy that first */
>>>> -        if ( page_order != PAGE_ORDER_4K )
>>>> -        {
>>>> -            unsigned long mask = ~((1UL << page_order) - 1);
>>>> -            gfn_t gfn2 = _gfn(gfn_l & mask);
>>>> -            mfn_t mfn2 = _mfn(mfn_x(mfn) & mask);
>>>> -
>>>> -            rc = ap2m->set_entry(ap2m, gfn2, mfn2, page_order, t, old_a, 1);
>>>> -            if ( rc )
>>>> -                return rc;
>>>> -        }
>>>> -    }
>>>> +    rc = altp2m_get_entry_prepopulate(ap2m, gfn, &mfn, &t, &old_a);
>>>> +    if ( rc )
>>>> +        return rc;
>>>>
>>>>      /*
>>>>       * Inherit the old suppress #VE bit value if it is already set, or set it
>>>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>>>> index 9e81a30cc4..7bedfd593b 100644
>>>> --- a/xen/arch/x86/mm/p2m.c
>>>> +++ b/xen/arch/x86/mm/p2m.c
>>>
>>> Wouldn't it make more sense to start adding new altp2m functions to
>>> mm/altp2m.c instead? Probably the altp2m functions from mm/p2m.c could
>>> also be relocated there at some point in the future.
>>>
>>>> @@ -478,6 +478,43 @@ void p2m_unlock_and_tlb_flush(struct p2m_domain *p2m)
>>>>          mm_write_unlock(&p2m->lock);
>>>>  }
>>>>
>>>> +int altp2m_get_entry(struct p2m_domain *ap2m,
>>>> +                            gfn_t gfn, mfn_t *mfn, p2m_type_t *t,
>>>> +                            p2m_access_t *a, bool prepopulate)
>>>> +{
>>>> +    *mfn = ap2m->get_entry(ap2m, gfn, t, a, 0, NULL, NULL);
>>>> +
>>>> +    /* Check host p2m if no valid entry in alternate */
>>>> +    if ( !mfn_valid(*mfn) && !p2m_is_hostp2m(ap2m) )
>>>> +    {
>>>> +        struct p2m_domain *hp2m = p2m_get_hostp2m(ap2m->domain);
>>>> +        unsigned int page_order;
>>>> +        int rc;
>>>> +
>>>> +        *mfn = __get_gfn_type_access(hp2m, gfn_x(gfn), t, a,
>>>> +                                     P2M_ALLOC | P2M_UNSHARE, &page_order, 0);
>>>
>>> So despite the name being altp2m_get_entry you now return an entry
>>> from the hostp2m, even if prepopulate is false. If the caller knows it
>>> doesn't want that entry to be copied into the altp2m, why not have it
>>> call __get_gfn_type_access itself for the hostp2m? IMHO this is just
>>> confusing and doesn't help readability of the altp2m code.
>>
>> You return the ap2m entry if it's present, or the hp2m entry if it's
>> not.  It's not a lot of duplication, but it makes the logic cleaner I
>> think; why not deduplicate it?
> 
> I have no problem with making the code more streamlined. The problem I
> have is that the function's name doesn't suggest it would get you
> anything but the entry from the specified altp2m. So you could be
> reading the code assuming you are dealing with an entry from that
> specified table when in fact you are not. That is not an expected
> behavior based on just the name of the function. This is going to make
> reading the altp2m code that much harder in the future.

Right -- I wasn't a huge fan of 'direct' either; it didn't really convey
to me 100% what the function did.  My PoC had "seethrough", but that
wasn't that great either.  "Peek"?  Any other suggestions?

Other options:

* If we have a single function with a #define, this might get a bit
easier;  we could have one be AP2MGET_dont_prepopulate or something.

( We could have the "core" function named _altp2m_get_entry, and have
altp2m_get_entry() call with prepopulate = false, and
altp2m_get_entry_prepopulate() call it with prepopulate = true.

Thoughts?

 -George

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

  reply	other threads:[~2019-04-16 15:08 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-16  8:45 [PATCH v5] x86/altp2m: Aggregate get entry and populate into common funcs Alexandru Stefan ISAILA
2019-04-16  8:45 ` [Xen-devel] " Alexandru Stefan ISAILA
2019-04-16 13:44 ` Tamas K Lengyel
2019-04-16 13:44   ` [Xen-devel] " Tamas K Lengyel
2019-04-16 13:51   ` Andrew Cooper
2019-04-16 13:51     ` [Xen-devel] " Andrew Cooper
2019-04-16 13:58     ` George Dunlap
2019-04-16 13:58       ` [Xen-devel] " George Dunlap
2019-04-16 14:25       ` Tamas K Lengyel
2019-04-16 14:25         ` [Xen-devel] " Tamas K Lengyel
2019-04-16 14:01   ` George Dunlap
2019-04-16 14:01     ` [Xen-devel] " George Dunlap
2019-04-16 14:19     ` Tamas K Lengyel
2019-04-16 14:19       ` [Xen-devel] " Tamas K Lengyel
2019-04-16 15:07       ` George Dunlap [this message]
2019-04-16 15:07         ` George Dunlap
2019-04-17  7:15         ` Alexandru Stefan ISAILA
2019-04-17  7:15           ` [Xen-devel] " Alexandru Stefan ISAILA
2019-04-17 18:22           ` Tamas K Lengyel
2019-04-17 18:22             ` [Xen-devel] " Tamas K Lengyel
2019-04-18  9:53             ` George Dunlap
2019-04-18  9:53               ` [Xen-devel] " George Dunlap
2019-04-18 13:59               ` Tamas K Lengyel
2019-04-18 13:59                 ` [Xen-devel] " Tamas K Lengyel
2019-04-18 17:02                 ` George Dunlap
2019-04-18 17:02                   ` [Xen-devel] " George Dunlap
2019-04-18 18:42                   ` Tamas K Lengyel
2019-04-18 18:42                     ` [Xen-devel] " Tamas K Lengyel
2019-04-19  8:32                     ` Alexandru Stefan ISAILA
2019-04-19  8:32                       ` [Xen-devel] " Alexandru Stefan ISAILA
2019-04-23 10:49                       ` Alexandru Stefan ISAILA
2019-04-23 10:49                         ` [Xen-devel] " Alexandru Stefan ISAILA
2019-04-23 11:44                       ` George Dunlap
2019-04-23 11:44                         ` [Xen-devel] " George Dunlap
2019-04-23 13:26                         ` Tamas K Lengyel
2019-04-23 13:26                           ` [Xen-devel] " 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=d0f438e1-fe1e-dd44-bcdb-f77c5949c7de@citrix.com \
    --to=george.dunlap@citrix.com \
    --cc=aisaila@bitdefender.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=rcojocaru@bitdefender.com \
    --cc=roger.pau@citrix.com \
    --cc=tamas@tklengyel.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.