[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH for-4.19] ppc/riscv: fix arch_acquire_resource_check()



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.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.