[PATCH] x86/hvm/ioreq: Fix condition in hvm_alloc_legacy_ioreq_gfn()

Oleksandr Tyshchenko posted 1 patch 2 months, 2 weeks ago
Patches applied successfully (tree, apply log)
git fetch https://gitlab.com/xen-project/patchew/xen tags/patchew/20250815101946.2329018-1-oleksandr._5Ftyshchenko@epam.com
xen/arch/x86/hvm/ioreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[PATCH] x86/hvm/ioreq: Fix condition in hvm_alloc_legacy_ioreq_gfn()
Posted by Oleksandr Tyshchenko 2 months, 2 weeks ago
Fix the incorrect condition that causes hvm_alloc_legacy_ioreq_gfn()
to return INVALID_GFN even if the HVM param was installed properly by
the toolstack.

Fixes: 3486f398a3dd (' x86/hvm/ioreq: allow ioreq servers to use HVM_PARAM_[BUF]IOREQ_PFN')
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
---
When playing with the XEN_DMOP_get_ioreq_server_info sub-op, I noticed weird
behavior where the hypercall returned success only the second time.
---
---
 xen/arch/x86/hvm/ioreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index ec709e5f47..4d30f2d730 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -63,7 +63,7 @@ static gfn_t hvm_alloc_legacy_ioreq_gfn(struct ioreq_server *s)
 
     for ( i = HVM_PARAM_IOREQ_PFN; i <= HVM_PARAM_BUFIOREQ_PFN; i++ )
     {
-        if ( !test_and_clear_bit(i, &d->arch.hvm.ioreq_gfn.legacy_mask) )
+        if ( test_and_clear_bit(i, &d->arch.hvm.ioreq_gfn.legacy_mask) )
             return _gfn(d->arch.hvm.params[i]);
     }
 
-- 
2.34.1
Re: [PATCH] x86/hvm/ioreq: Fix condition in hvm_alloc_legacy_ioreq_gfn()
Posted by Jan Beulich 2 months, 2 weeks ago
On 15.08.2025 12:19, Oleksandr Tyshchenko wrote:
> Fix the incorrect condition that causes hvm_alloc_legacy_ioreq_gfn()
> to return INVALID_GFN even if the HVM param was installed properly by
> the toolstack.
> 
> Fixes: 3486f398a3dd (' x86/hvm/ioreq: allow ioreq servers to use HVM_PARAM_[BUF]IOREQ_PFN')
> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>