Fix bug introduced by 0762e2502f1f ("x86/physdev: factor out the code to allocate and
map a pirq"). After that re-factoring, when pirq<0 and current_pirq>0, it means
caller want to allocate a free pirq for irq but irq already has a mapped pirq, then
it returns the negative pirq, so it fails. However, the logic before that
re-factoring is different, it should return the current_pirq that irq was already
mapped to and make the call success.
Fixes: 0762e2502f1f ("x86/physdev: factor out the code to allocate and map a pirq")
Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
xen/arch/x86/irq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 017a94e31155..47477d88171b 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -2898,6 +2898,7 @@ static int allocate_pirq(struct domain *d, int index, int pirq, int irq,
d->domain_id, index, pirq, current_pirq);
if ( current_pirq < 0 )
return -EBUSY;
+ pirq = current_pirq;
}
else if ( type == MAP_PIRQ_TYPE_MULTI_MSI )
{
--
2.34.1
On 08/07/2024 9:04 am, Jiqian Chen wrote: > Fix bug introduced by 0762e2502f1f ("x86/physdev: factor out the code to allocate and > map a pirq"). After that re-factoring, when pirq<0 and current_pirq>0, it means > caller want to allocate a free pirq for irq but irq already has a mapped pirq, then > it returns the negative pirq, so it fails. However, the logic before that > re-factoring is different, it should return the current_pirq that irq was already > mapped to and make the call success. > > Fixes: 0762e2502f1f ("x86/physdev: factor out the code to allocate and map a pirq") > > Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> > Signed-off-by: Huang Rui <ray.huang@amd.com> > Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> > Reviewed-by: Jan Beulich <jbeulich@suse.com> As a minor note, we treat Fixes: as a tag like all the others, so tend not to have a blank line between it an the SoB. Can be fixed on commit - no need to resend. ~Andrew
On Mon, 2024-07-08 at 11:32 +0100, Andrew Cooper wrote: > On 08/07/2024 9:04 am, Jiqian Chen wrote: > > Fix bug introduced by 0762e2502f1f ("x86/physdev: factor out the > > code to allocate and > > map a pirq"). After that re-factoring, when pirq<0 and > > current_pirq>0, it means > > caller want to allocate a free pirq for irq but irq already has a > > mapped pirq, then > > it returns the negative pirq, so it fails. However, the logic > > before that > > re-factoring is different, it should return the current_pirq that > > irq was already > > mapped to and make the call success. > > > > Fixes: 0762e2502f1f ("x86/physdev: factor out the code to allocate > > and map a pirq") > > > > Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> > > Signed-off-by: Huang Rui <ray.huang@amd.com> > > Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> > > Reviewed-by: Jan Beulich <jbeulich@suse.com> > > As a minor note, we treat Fixes: as a tag like all the others, so > tend > not to have a blank line between it an the SoB. > > Can be fixed on commit - no need to resend. Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com> ~ Oleksii
On 2024/7/8 18:32, Andrew Cooper wrote: > On 08/07/2024 9:04 am, Jiqian Chen wrote: >> Fix bug introduced by 0762e2502f1f ("x86/physdev: factor out the code to allocate and >> map a pirq"). After that re-factoring, when pirq<0 and current_pirq>0, it means >> caller want to allocate a free pirq for irq but irq already has a mapped pirq, then >> it returns the negative pirq, so it fails. However, the logic before that >> re-factoring is different, it should return the current_pirq that irq was already >> mapped to and make the call success. >> >> Fixes: 0762e2502f1f ("x86/physdev: factor out the code to allocate and map a pirq") >> >> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> >> Signed-off-by: Huang Rui <ray.huang@amd.com> >> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> >> Reviewed-by: Jan Beulich <jbeulich@suse.com> > > As a minor note, we treat Fixes: as a tag like all the others, so tend > not to have a blank line between it an the SoB. Learned it, thank you! > > Can be fixed on commit - no need to resend. > > ~Andrew -- Best regards, Jiqian Chen.
© 2016 - 2024 Red Hat, Inc.