[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] x86/irq: Return -EEXIST from map_domain_pirq()
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Jason Andryuk <jason.andryuk@xxxxxxx>
- Date: Tue, 19 May 2026 14:00:07 -0400
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fjknw+1Oy9Iv1ktAAF/hX0aOUOpZcxnroVvhN5VaOGg=; b=avOzKu4NP8AmEmYIaruTeRpuWGMZihw9D5rmoyI0cVtJcCfh4AZWGPyYZ/2w3/EgJjJzUSFQ9FHLtk0XjcZU/ZExdcIwKHfby2GR98YqomhntPQzRBDZ8j0X1QAoeOY4y3yylS5wUNghEWcNwU3QOZ/1NMH+BipLs319EdKViJNP1CUy6aCeMIjLCOgnPi2vFGs9hxowo2XWz9sBseWxLF+4IGMBep0GVaxinLMg6nyn9rOet0y0zlYAsV173bUtVhLXfqQ08s6FKt75LYkft6CQNw24VnD9sqg14IUaR3IfglJZlgLiH00ygmudRkKkh7Jd2nJq2igYB+oVIFKzMg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=BPW9EuKVhwrM9Mk2r2eptoNaJVXmK1TOIai+f1ruSqMpZUO7CH8rkKLg+xm2//0tqMEOtGRNxIE6bE3FdKVc1NIqCvFs//M3XdCsKbGl90Gwbyzcd8mD9uMR/Oh/kxoioSqPv6io3/dImz7T5cklco9X6UeRXaPKDNkM3RVmiAVY6ZfQvAk3a81DHK8FiPWi+eRPOfBIAai6m4LGMxmI0Rpn7ibg7nDGwOKBHBkBZRmkfnSkx3iSfLJhxkyeub/YpqG+bzsSAl9T7ZCbLmBvtnODimod7pcDu9CiS7hOnTdgH4zJXLko8xOoPEFRQ0/eRUmxw41/ue4tJFxoB5LBhg==
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Teddy Astie <teddy.astie@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Tue, 19 May 2026 18:00:33 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 2026-05-19 03:21, Jan Beulich wrote:
On 19.05.2026 02:15, Jason Andryuk wrote:
commit bfc341a65cfb ("x86: Make the hypercall PHYSDEVOP_alloc_irq_vector
hypercall dummy.") modified map_domain_pirq() to return 0 when an irq or
pirq is already mapped, when it previously returned -EINVAL. This
occured when moving map_domain_pirq()'s call from
PHYSDEVOP_alloc_irq_vector into PHYSDEVOP_apic_write.
However, this means other callers cannot detect when a pirq or irq is
already mapped. Since success is returned but the pirq is not
connected, it will never fire.
Modify map_domain_pirq() to return -EEXIST. -EINVAL is already returned
elsewhere in map_domain_pirq(), so -EEXIST allows identifying this case.
With that, squash -EEXIST in ioapic_guest_write() so the behavior does not
change.
What about the function's uses from allocate_and_map_[gm]si_pirq()? Don't they
then also need to cope with getting back -EEXIST to keep externally visible
behavior unaltered? Else those cases want discussing in the description, I
suppose.
For my use, I want allocate_and_map_gsi_pirq() to return -EEXIST. I'll
have to look at everything again and update the description.
Signed-off-by: Jason Andryuk <jason.andryuk@xxxxxxx>
---
I'm not sure whether or not this warrants a Fixes. Nothing in tree
today is broken, so I did not add one.
In which case this then also isn't 4.22 material, I guess?
Probably not.
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -2315,6 +2315,8 @@ int ioapic_guest_write(unsigned long physbase, unsigned
int reg, u32 val)
ret = map_domain_pirq(hardware_domain, pirq, irq,
MAP_PIRQ_TYPE_GSI, NULL);
write_unlock(&hardware_domain->event_lock);
+ if ( ret == -EEXIST )
+ ret = 0;
if ( ret < 0 )
return ret;
Slightly shorter
if ( ret < 0 && ret != -EEXIST )
return ret;
?
Well, I intentionally set ret = 0, so -EEXIST wasn't seen later in the
function. Though double checking now, there aren't any further uses of
ret, so your suggestion is okay. I just felt better overriding ret
instead of leaving it.
Thanks,
Jason
|
