From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Shawn Anastasio <sanastasio@raptorengineering.com>,
Alistair Francis <alistair.francis@wdc.com>,
Bob Eshleman <bobbyeshleman@gmail.com>,
Connor Davis <connojdavis@gmail.com>,
Oleksii Kurochko <oleksii.kurochko@gmail.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH for-4.19] ppc/riscv: fix arch_acquire_resource_check()
Date: Thu, 2 May 2024 09:35:30 +0200 [thread overview]
Message-ID: <ZjNCQiR2uUR5Iz8Q@macbook> (raw)
In-Reply-To: <0f39a067-70d2-4652-910a-5d05db6a3ebc@suse.com>
On Thu, May 02, 2024 at 09:23:30AM +0200, Jan Beulich wrote:
> On 30.04.2024 17:34, Roger Pau Monne wrote:
> > None of the implementations support set_foreign_p2m_entry() yet, neither they
> > have a p2m walk in domain_relinquish_resources() in order to remove the foreign
> > mappings from the p2m and thus drop the extra refcounts.
>
> While I don't mind the cod adjustment into the more safe direction, I find
> this justification odd: RISC-V has no domain_relinquish_resources() at all
> right now, and PPC has it properly as a stub only. Judgement on what there
> is (or not) can only be made one non-stub implementations exist.
Right, hence stating that foreign mappings are properly handled
(arch_acquire_resource_check() returning true) is bogus to me because
there's no code yet.
> IOW provided PPC and RISC-V people agree, I'm fine putting this in, but
> preferably with an adjusted description. To be honest with how you put it,
> it's not even really clear to me what (practical) problem, if any, you're
> trying to address.
The current statement is at best misleading, because there's no
implementation of set_foreign_p2m_entry() or
domain_relinquish_resources(), and hence making claims that future
implementation of them will properly handle foreign mappings could
lead to the special requirements of those mappings not being taken
into account when implementing those functions just because
arch_acquire_resource_check() already returns true.
IMO arch_acquire_resource_check() can only return true once the code
is in place, and mappings are properly handled. Making claims about
yet to be implemented code is wrong.
Thanks, Roger.
next prev parent reply other threads:[~2024-05-02 7:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-30 15:34 [PATCH for-4.19] ppc/riscv: fix arch_acquire_resource_check() Roger Pau Monne
2024-05-02 7:23 ` Jan Beulich
2024-05-02 7:35 ` Roger Pau Monné [this message]
2024-05-02 8:46 ` Oleksii
2024-05-02 10:31 ` Roger Pau Monné
2024-05-05 22:12 ` Shawn Anastasio
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=ZjNCQiR2uUR5Iz8Q@macbook \
--to=roger.pau@citrix.com \
--cc=alistair.francis@wdc.com \
--cc=bobbyeshleman@gmail.com \
--cc=connojdavis@gmail.com \
--cc=jbeulich@suse.com \
--cc=oleksii.kurochko@gmail.com \
--cc=sanastasio@raptorengineering.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.