The said sub-op is not supported on Arm64, 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 Arm64, only the Acquire
Resource infrastructure is used to query and map the IOREQ Server pages.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
---
xen/include/public/arch-arm.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index e2412a1747..023cc2f468 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -130,7 +130,6 @@
* HYPERVISOR_dm_op
* Exactly these sub-operations are supported:
* * XEN_DMOP_create_ioreq_server
- * * XEN_DMOP_get_ioreq_server_info
* * XEN_DMOP_map_io_range_to_ioreq_server
* * XEN_DMOP_unmap_io_range_from_ioreq_server
* * XEN_DMOP_set_ioreq_server_state
--
2.34.1On 01/09/2025 14:58, Oleksandr Tyshchenko wrote: > The said sub-op is not supported on Arm64, 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 Arm64, only the Acquire > Resource infrastructure is used to query and map the IOREQ Server pages. These points are valid. However, I don't understand why you mention Arm64 only. What about Arm32? It's the same here.> > Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> > --- > xen/include/public/arch-arm.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h > index e2412a1747..023cc2f468 100644 > --- a/xen/include/public/arch-arm.h > +++ b/xen/include/public/arch-arm.h > @@ -130,7 +130,6 @@ > * HYPERVISOR_dm_op > * Exactly these sub-operations are supported: > * * XEN_DMOP_create_ioreq_server > - * * XEN_DMOP_get_ioreq_server_info > * * XEN_DMOP_map_io_range_to_ioreq_server > * * XEN_DMOP_unmap_io_range_from_ioreq_server > * * XEN_DMOP_set_ioreq_server_state This list is kept in sync with the op_size array in xen/arch/arm/dm.c. I think we should drop this op from there, not only from the comment listing supported ops. ~Michal
On 02.09.25 10:27, Orzel, Michal wrote: Hello Michal > > > On 01/09/2025 14:58, Oleksandr Tyshchenko wrote: >> The said sub-op is not supported on Arm64, 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 Arm64, only the Acquire >> Resource infrastructure is used to query and map the IOREQ Server pages. > These points are valid. However, I don't understand why you mention Arm64 only. > What about Arm32? It's the same here.> I will s/Arm64/Arm >> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> >> --- >> xen/include/public/arch-arm.h | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h >> index e2412a1747..023cc2f468 100644 >> --- a/xen/include/public/arch-arm.h >> +++ b/xen/include/public/arch-arm.h >> @@ -130,7 +130,6 @@ >> * HYPERVISOR_dm_op >> * Exactly these sub-operations are supported: >> * * XEN_DMOP_create_ioreq_server >> - * * XEN_DMOP_get_ioreq_server_info >> * * XEN_DMOP_map_io_range_to_ioreq_server >> * * XEN_DMOP_unmap_io_range_from_ioreq_server >> * * XEN_DMOP_set_ioreq_server_state > This list is kept in sync with the op_size array in xen/arch/arm/dm.c. > I think we should drop this op from there, not only from the comment listing > supported ops. I think you are right, will do > > ~Michal > > >
© 2016 - 2025 Red Hat, Inc.