On 02/09/2025 13:10, Orzel, Michal wrote:
On 02/09/2025 13:54, Julien Grall wrote:
Hi,
On 02/09/2025 11:18, Orzel, Michal wrote:
On 02/09/2025 11:49, Oleksandr Tyshchenko wrote:
The said sub-op is not supported on Arm, since it:
- does not support the buffered emulation (so bufioreq_port/bufioreq_gfn
cannot be returned), please refer to ioreq_server_create()
- does not support "legacy" mechanism of mapping IOREQ Server
magic pages (so ioreq_gfn/bufioreq_gfn cannot be returned), please
refer to arch_ioreq_server_map_pages(). On Arm, only the Acquire
Resource infrastructure is used to query and map the IOREQ Server pages.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshche...@epam.com>
Reviewed-by: Michal Orzel <michal.or...@amd.com>
Could we perhaps add a Fixes tag here pointing to the commit introducing these
DM ops and thus add this patch for this release? Not sure what others think.
Fixes usually implies a bug and I don't see what bug we are solving. In
fact, I don't understand why we are trying to remove the subop...
Hmm, the issue is that the subop that is not supported at the moment is listed
as supported in the public header.
[...]
As for the code, from safety perspective if this subop is listed explicilty in
Arm's
dm.c, we would need to write a separate test case and test to cover it that at
the end, still returns -EOPNOTSUPP.
Why do you think it is not supported? AFAICT, it is still possible to
pass XEN_DMOP_nognfs to figure out whwether bufioreq is currently
available. The error code would be 0 not -EOPNOTSUPP.
> I think if we mistakenly mention sth as> supported in e.g. SUPPORT.md
we would have no issues adding a Fixes tag. There
> are many cases where Fixes was used just to change something in a
comment, so
> I'm having a hard time reasoning about when it's appropriate to use it.
I think what we would want is "Amends". This is currently proposed by [1].
[1]
https://lore.kernel.org/xen-devel/e7c99116-f6a9-43e1-80ae-b3a4d4485...@amd.com/T/#t
~Michal
--
Julien Grall
