All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Tim Deegan <tim@xen.org>
Cc: Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	Razvan Cojocaru <rcojocaru@bitdefender.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	xen-devel@lists.xen.org,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Tamas K Lengyel <tlengyel@novetta.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [PATCH v4] x86/arm/mm: use gfn instead of pfn in p2m_get_mem_access/p2m_set_mem_access
Date: Thu, 2 Jul 2015 12:38:11 +0100	[thread overview]
Message-ID: <559522A3.6040806@citrix.com> (raw)
In-Reply-To: <20150702112549.GA87948@deinos.phlegethon.org>

On 02/07/15 12:25, Tim Deegan wrote:
> At 12:09 +0100 on 02 Jul (1435838956), Andrew Cooper wrote:
>> On 02/07/15 11:48, George Dunlap wrote:
>>> Now in p2m_set_mem_access(), rather than just using an unsigned long in
>>> the loop iterating over gfns, you do this thing where you convert gfn_t
>>> to unsigned long, add one, and then convert it back to gfn_t again.
>>>
>>> I can't see any comments in v3 that suggest you doing that, and it seems
>>> a bit clunky.  Is that really necessary?  Wouldn't it be better to
>>> declare a local variable?
>>>
>>> I'm not strongly opinionated on this one, it just seems a bit strange.
>>>
>>> Everything else looks good, thanks.
>> Looping over {g,m,p}fn_t's is indeed awkward, as the compiler tricks for
>> typesafety don't allow for simply adding 1 to a typesafe variable.
>>
>> In a cases like this, I think it is acceptable to keep a unsigned long
>> shadow variable and manipulate it is a plain integer.  The eventual
>> _gfn() required to pass it further down the callchain will help to
>> visually re-enforce the appropriate type.
>>
>> After all, the entire point of these typesafes are to try and avoid
>> accidentally mixing up the different address spaces, but a function
>> which takes a typesafe, loops over a subset and passes the same typesafe
>> further down can probably be trusted to DTRT, catching errors at review
>> time. 
>>
>> Off the top of my head, the only functions which would normally expect
>> to mix and match the typesafes are the pagetable walking ones.
> It should be easy enough to extend the macros to define a
> gfn_inc(&gfn_t) operator for this kind of thing.

Very true.  I suspect inc and dec will cover the majority of the
unbox/modify/box bits we currently have.

OTOH, ideally I would prefer not to introduce even more magic which
cscope/tags can't spot, but introducing gfn_inc() does appear to be the
neater solution.

~Andrew

      parent reply	other threads:[~2015-07-02 11:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-29 15:45 [PATCH v4] x86/arm/mm: use gfn instead of pfn in p2m_get_mem_access/p2m_set_mem_access Vitaly Kuznetsov
2015-06-29 15:49 ` Andrew Cooper
2015-06-29 16:20 ` Razvan Cojocaru
2015-06-29 16:43 ` Ian Campbell
2015-07-02 10:48 ` George Dunlap
2015-07-02 11:09   ` Andrew Cooper
2015-07-02 11:25     ` Tim Deegan
2015-07-02 11:32       ` George Dunlap
2015-07-02 12:26         ` Vitaly Kuznetsov
2015-07-02 13:01           ` George Dunlap
2015-07-02 15:01         ` Tim Deegan
2015-07-02 11:38       ` Andrew Cooper [this message]

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=559522A3.6040806@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=keir@xen.org \
    --cc=rcojocaru@bitdefender.com \
    --cc=stefano.stabellini@citrix.com \
    --cc=tim@xen.org \
    --cc=tlengyel@novetta.com \
    --cc=vkuznets@redhat.com \
    --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.