xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien@xen.org>
To: Luca Fancellu <luca.fancellu@arm.com>
Cc: xen-devel@lists.xenproject.org,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	wei.chen@arm.com, Stefano Stabellini <sstabellini@kernel.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Rahul Singh <rahul.singh@arm.com>
Subject: Re: [PATCH v4 2/4] xen/arm: Handle cases when hardware_domain is NULL
Date: Wed, 14 Apr 2021 14:45:52 +0100	[thread overview]
Message-ID: <269e20a7-9f2c-f989-0ea0-7ab6c6bb9c11@xen.org> (raw)
In-Reply-To: <04326BA4-6E73-44BA-AB19-8F2B99000D8B@arm.com>

Hi Luca,

On 14/04/2021 12:29, Luca Fancellu wrote:
>> On 14 Apr 2021, at 12:16, Julien Grall <julien@xen.org> wrote:
>>
>> Hi Luca,
>>
>> On 14/04/2021 10:14, Luca Fancellu wrote:
>>> Among the common and arm codebase there are few cases where
>>> the hardware_domain variable is checked to see if the current
>>> domain is equal to the hardware_domain, change this cases to
>>> use is_hardware_domain() function instead. >
>>> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
>>> ---
>>> v4 changes:
>>> - removed unneeded check for domain NULL from is_hardware_domain
>>>    introduced in v3
>>
>> After this change, this patch is only avoid to open-code is_hardware_domain(). Although, it adds an extra speculation barrier.
>>
>> I am not against the change, however I think the commit message needs to updated to match what the patch is doing.
>>
>> Can you propose a new commit message?
> 
> Hi Julien,
> 
> Yes I agree, what about:
> 
> xen/arm: Reinforce use of is_hardware_domain
> 
> Among the common and arm codebase there are few cases where

I would drop 'common' because you are only modifying the arm codebase.

> the hardware_domain variable is checked to see if the current
> domain is equal to the hardware_domain, change this cases to
> use is_hardware_domain() function instead.


> In the eventuality that hardware_domain is NULL, is_hardware_domain
> will return false because an analysis of the common and arm codebase
> shows that is_hardware_domain is called always with a non NULL
> domain pointer.

This paragraph seems to come out of the blue. I would drop it.

How about:

"
There are a few places on Arm where we use pretty much an open-coded 
version of is_hardware_domain(). The main difference, is the helper will 
also block speculation (not yet implemented on Arm).

The existing users are not in hot path, so blocking speculation would 
not hurt when it is implemented. So remove the open-coded version within 
the arm codebase.
"

If you are happy with the commit message, I will commit it the series 
tomorrow (to give an opportunity to Stefano to review).

Cheers,

-- 
Julien Grall


  reply	other threads:[~2021-04-14 13:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-14  9:14 [PATCH v4 0/4] xen/arm: Prevent Dom0 to be loaded when using dom0less Luca Fancellu
2021-04-14  9:14 ` [PATCH v4 1/4] xen/arm: Move dom0 creation in domain_build.c Luca Fancellu
2021-04-14 10:14   ` Bertrand Marquis
2021-04-14  9:14 ` [PATCH v4 2/4] xen/arm: Handle cases when hardware_domain is NULL Luca Fancellu
2021-04-14 10:14   ` Bertrand Marquis
2021-04-14 11:16   ` Julien Grall
2021-04-14 11:29     ` Luca Fancellu
2021-04-14 13:45       ` Julien Grall [this message]
2021-04-14 13:47         ` Luca Fancellu
2021-04-14 20:35           ` Stefano Stabellini
2021-04-15 17:17             ` Julien Grall
2021-04-14  9:14 ` [PATCH v4 3/4] xen/arm: Clarify how the domid is decided in create_domUs() Luca Fancellu
2021-04-14 10:14   ` Bertrand Marquis
2021-04-14 11:17   ` Julien Grall
2021-04-14  9:14 ` [PATCH v4 4/4] xen/arm: Prevent Dom0 to be loaded when using dom0less Luca Fancellu
2021-04-14 10:14   ` Bertrand Marquis

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=269e20a7-9f2c-f989-0ea0-7ab6c6bb9c11@xen.org \
    --to=julien@xen.org \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=bertrand.marquis@arm.com \
    --cc=luca.fancellu@arm.com \
    --cc=rahul.singh@arm.com \
    --cc=sstabellini@kernel.org \
    --cc=wei.chen@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).