All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Julien Grall <julien.grall@arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xen.org
Subject: Re: [PATCH v3 7/8] xen/arm: Rework the interface of p2m_lookup and use typesafe gfn and mfn
Date: Fri, 24 Jun 2016 15:03:31 +0100	[thread overview]
Message-ID: <11bd382d-9a7b-868f-d809-dd18da57f118@citrix.com> (raw)
In-Reply-To: <576D3C6E.70800@arm.com>

On 24/06/16 14:58, Julien Grall wrote:
> Hi Stefano,
>
> On 23/06/16 15:14, Stefano Stabellini wrote:
>> On Tue, 21 Jun 2016, Julien Grall wrote:
>>> The prototype and the declaration of p2m_lookup disagree on how the
>>> function should be used. One expect a frame number whilst the other
>>> an address.
>>>
>>> Thankfully, everyone is using with an address today. However, most of
>>> the callers have to convert a guest frame to an address. Modify
>>> the interface to take a guest physical frame in parameter and return
>>> a machine frame.
>>>
>>> Whilst modifying the interface, use typesafe gfn and mfn for clarity
>>> and catching possible misusage.
>>>
>>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>>> ---
>>>   xen/arch/arm/p2m.c        | 37 ++++++++++++++++++++-----------------
>>>   xen/arch/arm/traps.c      | 21 +++++++++++----------
>>>   xen/include/asm-arm/p2m.h |  7 +++----
>>>   3 files changed, 34 insertions(+), 31 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
>>> index 47cb383..f3330dd 100644
>>> --- a/xen/arch/arm/p2m.c
>>> +++ b/xen/arch/arm/p2m.c
>>> @@ -140,14 +140,15 @@ void flush_tlb_domain(struct domain *d)
>>>   }
>>>
>>>   /*
>>> - * Lookup the MFN corresponding to a domain's PFN.
>>> + * Lookup the MFN corresponding to a domain's GFN.
>>>    *
>>>    * There are no processor functions to do a stage 2 only lookup
>>> therefore we
>>>    * do a a software walk.
>>>    */
>>> -static paddr_t __p2m_lookup(struct domain *d, paddr_t paddr,
>>> p2m_type_t *t)
>>> +static mfn_t __p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
>>>   {
>>>       struct p2m_domain *p2m = &d->arch.p2m;
>>> +    const paddr_t paddr = pfn_to_paddr(gfn_x(gfn));
>>>       const unsigned int offsets[4] = {
>>>           zeroeth_table_offset(paddr),
>>>           first_table_offset(paddr),
>>> @@ -158,7 +159,7 @@ static paddr_t __p2m_lookup(struct domain *d,
>>> paddr_t paddr, p2m_type_t *t)
>>>           ZEROETH_MASK, FIRST_MASK, SECOND_MASK, THIRD_MASK
>>>       };
>>>       lpae_t pte, *map;
>>> -    paddr_t maddr = INVALID_PADDR;
>>> +    mfn_t mfn = _mfn(INVALID_MFN);
>>
>> It might be worth defining INVALID_MFN_T and just assign that to mfn.
>
> Good idea. It will be useful in other places too.
>
>>
>>>       paddr_t mask = 0;
>>>       p2m_type_t _t;
>>>       unsigned int level, root_table;
>
>
> [...]
>
>>> @@ -1561,11 +1565,10 @@ p2m_mem_access_check_and_get_page(vaddr_t
>>> gva, unsigned long flag)
>>>        * We had a mem_access permission limiting the access, but the
>>> page type
>>>        * could also be limiting, so we need to check that as well.
>>>        */
>>> -    maddr = __p2m_lookup(current->domain, ipa, &t);
>>> -    if ( maddr == INVALID_PADDR )
>>> +    mfn = mfn_x(__p2m_lookup(current->domain, gfn, &t));
>>> +    if ( mfn == INVALID_MFN )
>>
>> The conversion would go away if we had an INVALID_MFN which is mfn_t

Be careful.

INVALID_MFN_T is fine for assignment, but you can't do plain equality
tests of opaque structures.

mfn_t m = _mfn(0);
mfn_t inval = INVALID_MFN_T; // Ok
mfn_equal(m, INVALID_MFN_T); // Ok
mfn_equal(m, inval); // Ok
m == inval; // Compilation error

This was the reason that I didn't previously introduce INVALID_MFN_T,
although with mfn_equal(), perhaps the time has come.

~Andrew

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

  reply	other threads:[~2016-06-24 14:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-21 13:20 [PATCH v3 0/8] xen/arm: Use the typesafes gfn and mfn Julien Grall
2016-06-21 13:20 ` [PATCH v3 1/8] xen/arm: Rename gmfn_to_mfn to gfn_to_mfn and use gfn/mfn typesafe Julien Grall
2016-06-23 10:06   ` Stefano Stabellini
2016-06-21 13:20 ` [PATCH v3 2/8] xen/mm: Introduce a bunch of helpers for the typesafes mfn and gfn Julien Grall
2016-06-22  7:03   ` Jan Beulich
2016-06-21 13:20 ` [PATCH v3 3/8] xen: Use typesafe gfn/mfn in guest_physmap_* helpers Julien Grall
2016-06-23 10:11   ` Stefano Stabellini
2016-06-21 13:20 ` [PATCH v3 4/8] xen: Use typesafe gfn in xenmem_add_to_physmap_one Julien Grall
2016-06-23 10:20   ` Stefano Stabellini
2016-06-23 10:43     ` Julien Grall
2016-06-23 13:06       ` Stefano Stabellini
2016-06-23 13:33         ` Julien Grall
2016-06-23 13:41           ` Stefano Stabellini
2016-06-23 13:58   ` Stefano Stabellini
2016-06-21 13:20 ` [PATCH v3 5/8] xen/arm: Rename grant_table_gfpn into grant_table_gfn and use the typesafe gfn Julien Grall
2016-06-23 14:00   ` Stefano Stabellini
2016-06-21 13:20 ` [PATCH v3 6/8] xen: Use the typesafe mfn and gfn in map_mmio_regions Julien Grall
2016-06-23 14:05   ` Stefano Stabellini
2016-06-23 14:08     ` Julien Grall
2016-06-23 14:15       ` Stefano Stabellini
2016-06-23 14:58         ` Julien Grall
2016-06-21 13:20 ` [PATCH v3 7/8] xen/arm: Rework the interface of p2m_lookup and use typesafe gfn and mfn Julien Grall
2016-06-23 14:14   ` Stefano Stabellini
2016-06-24 13:58     ` Julien Grall
2016-06-24 14:03       ` Andrew Cooper [this message]
2016-06-21 13:20 ` [PATCH v3 8/8] xen/arm: p2m_cache_flush: Use the correct terminology and typesafe gfn Julien Grall

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=11bd382d-9a7b-868f-d809-dd18da57f118@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=julien.grall@arm.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xen.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.