All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Julien Grall <julien@xen.org>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
	"Bertrand Marquis" <bertrand.marquis@arm.com>,
	"Michal Orzel" <michal.orzel@amd.com>,
	"Oleksii Kurochko" <oleksii.kurochko@gmail.com>,
	"Shawn Anastasio" <sanastasio@raptorengineering.com>,
	Xen-devel <xen-devel@lists.xenproject.org>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>
Subject: Re: [PATCH 1/2] xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation
Date: Mon, 4 Mar 2024 17:55:22 +0100	[thread overview]
Message-ID: <141ed8a2-df4f-492c-a192-4ffa7f4c8384@suse.com> (raw)
In-Reply-To: <5c06c437-b62c-4bee-8694-1be597887718@xen.org>

On 04.03.2024 17:46, Julien Grall wrote:
> On 04/03/2024 16:41, Jan Beulich wrote:
>> On 04.03.2024 17:31, Julien Grall wrote:
>>> On 04/03/2024 16:10, Andrew Cooper wrote:
>>>> It is daft to require all architectures to provide empty implementations of
>>>> this functionality.
>>>
>>> Oleksii recenlty sent a similar patch [1]. This was pushed back because
>>> from naming, it sounds like the helpers ought to be non-empty on every
>>> architecture.
>>>
>>> It would be best if asm-generic provides a safe version of the helpers.
>>> So my preference is to not have this patch. This can of course change if
>>> I see an explanation why it is empty on Arm (I believe it should contain
>>> csdb) and other arch would want the same.
>>
>> Except that there's no new asm-generic/ header here (as opposed to how
>> Oleksii had it). Imo avoiding the need for empty stubs is okay this way,
>> when introducing an asm-generic/ header would not have been. Of course
>> if Arm wants to put something there rather sooner than later, then
>> perhaps the functions better wouldn't be removed from there, just to then
>> be put back pretty soon.
> 
> I am confused. I agree the patch is slightly different, but I thought 
> the fundamental problem was the block_speculation() implementation may 
> not be safe everywhere. And it was best to let each architecture decide 
> how they want to implement (vs Xen decide for us the default).
> 
> Reading the original thread, I thought you had agreed with that 
> statement. Did I misinterpret?
Yes and no. Whatever is put in asm-generic/ ought to be correct and safe
by default, imo. The same doesn't apply to fallbacks put in place in
headers in xen/: If an arch doesn't provide its own implementation, it
indicates that the default (fallback) is good enough. Still I can easily
see that other views are possible here ...

Jan


  reply	other threads:[~2024-03-04 16:55 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-04 16:10 [PATCH 0/2] xen/nospec: Improvements Andrew Cooper
2024-03-04 16:10 ` [PATCH 1/2] xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation Andrew Cooper
2024-03-04 16:31   ` Julien Grall
2024-03-04 16:41     ` Jan Beulich
2024-03-04 16:46       ` Julien Grall
2024-03-04 16:55         ` Jan Beulich [this message]
2024-03-04 17:07           ` Andrew Cooper
2024-03-04 17:40             ` Julien Grall
2024-03-04 17:50               ` Andrew Cooper
2024-03-05 15:15                 ` Oleksii
2024-03-05 15:43                   ` Jan Beulich
2024-03-05 15:47                     ` Andrew Cooper
2024-03-05 18:56                     ` Oleksii
2024-03-05  7:10               ` Jan Beulich
2024-03-04 16:47       ` Andrew Cooper
2024-03-04 16:45   ` Jan Beulich
2024-03-04 16:46     ` Andrew Cooper
2024-03-05  7:15   ` Jan Beulich
2024-03-05  7:34   ` Jan Beulich
2024-03-04 16:10 ` [PATCH 2/2] xen/nospec: Allow evaluate_nospec() to short circuit constant expressions Andrew Cooper
2024-03-05  7:30   ` Jan Beulich

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=141ed8a2-df4f-492c-a192-4ffa7f4c8384@suse.com \
    --to=jbeulich@suse.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bertrand.marquis@arm.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=oleksii.kurochko@gmail.com \
    --cc=roger.pau@citrix.com \
    --cc=sanastasio@raptorengineering.com \
    --cc=sstabellini@kernel.org \
    --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.