linux-kernel - Re: [PATCH] xen/events: Fix Global and Domain VIRQ tracking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3823aae9-34cd-430f-8cf5-873d354c52ac@suse.com>
Date: Fri, 15 Aug 2025 07:12:36 +0200
From: Jürgen Groß <jgross@...e.com>
To: Jason Andryuk <jason.andryuk@....com>,
 Stefano Stabellini <sstabellini@...nel.org>,
 Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>,
 Chris Wright <chrisw@...s-sol.org>,
 Jeremy Fitzhardinge <jeremy@...source.com>
Cc: stable@...r.kernel.org, xen-devel@...ts.xenproject.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] xen/events: Fix Global and Domain VIRQ tracking

On 14.08.25 23:04, Jason Andryuk wrote:
> On 2025-08-14 03:05, Jürgen Groß wrote:
>> On 13.08.25 17:03, Jason Andryuk wrote:
>>> On 2025-08-12 15:00, Jason Andryuk wrote:
>>>> VIRQs come in 3 flavors, per-VPU, per-domain, and global.  The existing
>>>> tracking of VIRQs is handled by per-cpu variables virq_to_irq.
>>>>
>>>> The issue is that bind_virq_to_irq() sets the per_cpu virq_to_irq at
>>>> registration time - typically CPU 0.  Later, the interrupt can migrate,
>>>> and info->cpu is updated.  When calling unbind_from_irq(), the per-cpu
>>>> virq_to_irq is cleared for a different cpu.  If bind_virq_to_irq() is
>>
>> This is what needs to be fixed. At migration the per_cpu virq_to_irq of the
>> source and the target cpu need to be updated to reflect that migration.
> 
> I considered this, and even implemented it, before changing my approach.  My 
> concern was that the single VIRQ is now in one of the N per_cpu virq_to_irq 
> arrays.  A second attempt to register on CPU 0 will probably find -1 and 
> continue and issue the hypercall.

The hypervisor would reject the attempt, right? So in the end no problem.

> It looks like Xen tracks virq on the bind_virq vcpu, so per-domain/global stays 
> on vcpu0.  Binding again would return -EEXISTS. find_virq() would not match the 
> virq if it was re-bound to a different vcpu.

We probably would want to modify find_virq() and bind_virq_to_irq() to not
result in a BUG() if a non-percpu virq is bound to another cpu. This could
be done by passing the percpu flag to find_virq() and let find_virq() return
e.g. -EEXIST if a non-percpu virq is found to be bound to another cpu.


Juergen

Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3684 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (496 bytes)