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 - 2026 Red Hat, Inc.