From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-42af.mail.infomaniak.ch (smtp-42af.mail.infomaniak.ch [84.16.66.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C91ED125AA for ; Tue, 28 Apr 2026 16:40:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=84.16.66.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777394450; cv=none; b=M1eWAzQ6B5/3B+8Fn365FbQFb4kQhLpUOw9bxh1eJj9wXF6TarhG/V0BzIUa/F/7jeP3vub1dJYKNBuAUvmIc84esy9Ev2o47JXr+YIjWmSDkcD5cxkMO8NEDyziiPZkLhM5ijLSu6cSfi14j/ub97dtm53pkaP7nuiHFTlN+XU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777394450; c=relaxed/simple; bh=13zKIVzA7YTw8NSqeHDJolyHHzduz2syXEMLUnJyKJ4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Z79u31iOeCCnBLjQFlJzRAlXrKCacZ2mzb9wPCHYBZrNaTnRIrucbjQMHC/1epZDcmNWB1MF0dicviocyf7UcuURtOfdvrfMbe42hTV4oH7JTq7NPJVj2BkHm4SbbUTkjQyMNrzijvPGws76zfnoxo4f/nusVCxbTfZN0YOOYnA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=etik.com; spf=pass smtp.mailfrom=etik.com; dkim=pass (1024-bit key) header.d=etik.com header.i=@etik.com header.b=qsaF2RGi; arc=none smtp.client-ip=84.16.66.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=etik.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=etik.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=etik.com header.i=@etik.com header.b="qsaF2RGi" Received: from smtp-4-0001.mail.infomaniak.ch (smtp-4-0001.mail.infomaniak.ch [10.7.10.108]) by smtp-4-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4g4mQF5QsRzhbd; Tue, 28 Apr 2026 18:40:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=etik.com; s=20210927; t=1777394437; bh=+R5SuEtYO5urHSnnIncU8Xd/pfyPnwGZ7JN5GbyzE4E=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=qsaF2RGixNmdDsYonFzLQwBz0602GzDS10SjRj/5sA8x+fZTpAzUnttm/jIW7m2dc lirlpWglrfXMSWmwQUKfIEH8e1EQH4r9x0KqWdj3iZIyFsYrOaDvCZ6K3qLKBxvFNu 2ZyjasAuPdlBGgWwB0Vv6lYgMDXUTXX6zzXAm1Zk= Received: from unknown by smtp-4-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4g4mQD0RL4zZB5; Tue, 28 Apr 2026 18:40:36 +0200 (CEST) Message-ID: Date: Tue, 28 Apr 2026 18:40:35 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] xen/riscv: per-CPU devid setup for Xen event channel IRQ on IMSIC To: Anup Patel Cc: linux-riscv@lists.infradead.org, tglx@linutronix.de, pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr, linux-kernel@vger.kernel.org, oleksii.kurochko@gmail.com, xen-devel-owner@lists.xenproject.org References: <75820aee-f842-4f40-983b-f360ae6e6d29@etik.com> Content-Language: en-US From: Baptiste Le Duc Autocrypt: addr=baptiste.leduc@etik.com; keydata= xsFNBGnvLjgBEADAyweyc6WR9/BO+cWHJAmqh6hZ0cBM4Z6ShEMuZmKcrcVxVyDljqoFH9z2 TS7+BMEDWvtVgoDND/OgQPJ9mh76puQNiklAommLSbG2Zw03/fXYf2oIt3I+fSAoy7EI+2Fn /yLYpfH9Wg1iBLyYbzFbqrlLjwIvki5nyhMtPBxLaIG5EKnlrQAnEE7kdOg1Nkw3ZQdIkkHi BBZ7xL9/tjcTFD+eV77CwxezI4bmMgIRwAX5Md8i+DTvn8WSY6r1wtLqTMHsT+aFfABljKWM HxcoDlSMH1DdPMx9im255ZoXYJXNJTB6BabButgtYAeHZm5SskRD1+/SQGWBztigweB35SBj M5Hp9+U27DFf2JF7zf61ItcfZx09wMNusWEeHKIlFjFzTeB7Q94VFBNjCLVcgsg8beD7sfTN YIjVLqGulajntN8Cnvk/zDDDCAB2c1xtD8/Kav09z4yFpOQiuobF0JGMy2hBQDQJbywNd+Nn 1SJV0yFigDD0O6hj6gMsBqB2flDW7bmdC2MoUOgO6eYYHl5rZG2DopcAgchO1A/QkLGICZcO 5jDUvECo0B9WMJaMVtW2WM8QmLFxQfO+F6nbl8JI+86YE+jSErdXW0MdunZPGIj0JUOJjMZz hjj9tXliWjEOdprB2sSn8bVv/KtLAtBAQZ97VXGSIX4CY1y1+QARAQABzSlCYXB0aXN0ZSBM ZSBEdWMgPGJhcHRpc3RlLmxlZHVjQGV0aWsuY29tPsLBjQQTAQgANxYhBJXmIBvNu84z1lDq 0zv2cHaCozU7BQJp7y45BQkJZgGAAhsDBAsJCAcFFQgJCgsFFgIDAQAACgkQO/ZwdoKjNTtq Tw/7BICAkShQLcaGg0KTsX/DjUGh1TXYwMigp9GoVxBqMkV6sscSBouSuD2dq+lxKs/WXRP6 lAo8ffQaEuYAROu/oWWtldGxzRYlXx8yT6AEGdyaYr3ZexSGTRbqPdlQeMZyilN6KWmDN9d0 K8kNQ5Xh5bOI/6Tb9/C7xTgZeGZaX8X/pLf+iwyDVWtSPBBSZIZKdAuxqnYSCW0fJgMl7O28 lGiFJL3PTKxrmLvvnHjZwge93BuP46/zhDGoqi6mlnAs/Q+M/OC1SwyDgf2/J70Y9fylhPZc 5z8VUUTUUqb3qNxsEIrNamcQrIFaMKTHAUUvQARv3GPPSTbQXtvLoi5oiS3WGuHqwaMo9PaM 7wXwAI1N7zir9v1Z9+l6FfhDZpSMyVbKNj9wOzOiZp1W2Rb1m/+Hk0Vre+nq4Ctyi0BH7UCu eqlOUYZA22M457PlM76r11uyhl5opCeI76Mq6xOJzwkGo7ljRxgqi38982AFJcoktRDW0XFd gvtymSopG56WVP6g14d9v1C8HU5myS5CDuewUcD396dVB324cuZOBf+lbA7KgwjI4IDPwB3j 0in23fpKaym0w38y3avWApanPpdJd4z7G7/3Ss1HaQTzLX79WNw6yxlBxGN7I9DxCqFL+2QG J3S5bzSgYakoAEnzXjQBSk5mbG0u4DbmJ1bU9/bOwU0Eae8uOgEQAOOQmj3kv6YzdsuFCO80 bjzCk4KsumyXNZ732My+vKRrKRPdozj7qVdNZsphmx83mkq5SYx0/TFMhxcn7km25gVzGI2d +qHOFilH6u0ugr9ob/IFWJk07Vw43/iuqvAODGfATppbvm8UqQzIp3riPNMUOVeiT/lAvkl6 xO3eJwCkwSDBAhgRBQwuLpjAI8MUz2XGL5UcHgPl1wkmHpuvB62hZGoBqDPcj2eSB9RhLBVJ PCuopRbmYrYFsyBMOEwUczGezzfFXWXZ5zDShxjCYMmjgd1ukYfGG3LlgK3srKSrb5YTSV4l H0lS+pRWLKy2Z1aWl7MKxdOwrDVbmP65USqvYsrLXQ3qabh7DS3N0JV63Duk9YdOUzH5s0b/ iDEgnAL6TgmlAysRwvuZM2MWX1xGAnM/5qgEfu6bR8aS55DJ6/NTyII5sObEJlEW4880vKPG Gw5b5m2Pr/yoQdURRCG2BfoQupmGcN9DdqjDfLRDQqHk5f02u73epHfWsf+bAVLjzDZYCCGP r0uxYmz+EulRedtuXabz+zPeXwh2q45PYPb4NbCHICtJkw60Vz8g8Nq9ffTLBMcBHqVRDUD9 gq5s6zfn/xaD/d5UzNLmgonqMpOWXM61U+FO96A0cTJIaLo0MfkxgjWZoceD1lgvlVIPKbgt CwB/u4lQOZeag9HdABEBAAHCwXwEGAEIACYWIQSV5iAbzbvOM9ZQ6tM79nB2gqM1OwUCae8u OwUJCWYBgAIbDAAKCRA79nB2gqM1OxybD/4xZ/xdebhhomnXm1Mivtp0EMn0ZwaQuIQ07SlK /mQqtgfIwHoHSLnS7tQgyeOZnI1khwnOn3zendeytxfCKyhuQbwBh8ppgwxucc6JC7UD8jEo KBGhplrs0bdI8YxqQDH8gdZoiXwfe2REPDdNciYQ+OmidMBGq7EVAucrDpPCQ3UvPODI3zOk 3MsP1/p9Guzr2VYK2G1NL+ZlzZDnl7wZ3kQzAlg2IukGkdIWEpo27oOdNParpnd9jes/U0AG tlYoWOWsxtE8DDKlje+ORCHQuFJynEV06agCpIo3io5NNUt6m+YpOvfOh53y4IlEUfOG5sBz CQwsZJ/cmJJLAW6qvWuKUOXP2MjJIg0Afwly2mqgy8D26quzf47O0Kra4yysfVRkK8iElm+B BLG/tSoxTarjWW+7RGpFAxXHSIkUWGIhpSx3MsF9ZYJIdtKft2qLCGnDJ6wKEI0yMckRnoON Ur8uEJkM8oCU90g4rZTJ5zqtki2nfXGNKE4NblFl5XHq+ehG3O0kPBwejUqagvniJqdXUnNk ttZaV8JoZAvGDfgX4kHjdkTUuiBtketoUs3h5HKAYrA9VZyVIDiz1vlsviHpSgXbYB06+LKe HvAEHUvnGVuBchVLEX/kmFrxjW+dFu8D7KR145s2jfNAddotpFX4YL+38XYNhwhXQVqVhQ== In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Feedback-ID: :bbb8044e0943cee:ham:8bba193fd89ba14 X-Infomaniak-Routing: alpha Hi, Thanks for your quick response. I've implemented Xen event channels as a local interrupt, which works correctly for Xen <-> dom0 communication. However, this approach hits a limitation when dom0 needs to notify another guest domain: running in VS-mode, dom0 has no access to the hvip CSR and therefore cannot inject an IRQ_S_SOFTWARE interrupt into another guest directly as it can only be done by the hypervisor from HS-mode. Do you have any ideas to handle this ? Thanks in advance. Regards, Baptiste On 4/24/26 6:55 PM, Anup Patel wrote: > On Fri, Apr 24, 2026 at 10:09 PM Baptiste Le Duc > wrote: >> Hi, >> >> While adding Xen/RISC-V support, the guest event channel interrupt is >> allocated via irq_of_parse_and_map() against the IMSIC domain and, if >> we refer to the ARM implementation, it must >> be enabled/disabled per vCPU through enable_percpu_irq() / >> disable_percpu_irq() in the CPU hotplug callbacks. >> >> With IMSIC using handle_edge_irq (the upstream default), >> enable_percpu_irq() never clears IRQD_IRQ_DISABLED. That flag is set at >> irq_desc allocation time (irqdesc.c) and is only cleared by >> irq_startup(), which is called from __setup_irq() only when >> irq_settings_can_autoenable() returns true. >> >> irq_set_percpu_devid() sets IRQ_NOAUTOEN (via irq_set_percpu_devid_flags), >> so irq_startup() is intentionally skipped for percpu-devid IRQs. >> enable_percpu_irq() calls irq_percpu_enable() which does irq_enable/unmask >> on the chip but never touches IRQD_IRQ_DISABLED. >> >> Result: handle_edge_irq() hits irq_can_handle_actions() → checks >> irqd_irq_disabled() → returns false → IRQ silently dropped. >> >> This was confirmed by logs: >> >> XEN_TRACE irq=12 percpu_enable cpu=0 IRQD_DISABLED=1 >> XEN_TRACE irq=12 handle_edge DROP IRQD_DISABLED=1 action=... >> >> What we tried >> ------------- >> - request_irq() correctly works with upstream IMSIC which uses >> handle_edge_irq with no >> irq_set_percpu_devid() but it means we only can have one vCPU which will >> always handle the irq, >> and we don't want that. >> >> - Adding irq_set_percpu_devid() + switching to handle_percpu_devid_irq in >> imsic_irq_domain_alloc() fixes the Xen case but breaks all other IMSIC >> users (PCI MSI, platform devices) that call request_irq(), since >> request_threaded_irq() rejects IRQs marked _IRQ_PER_CPU_DEVID: >> >> WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:2101 >> request_threaded_irq+0x80/0x12c >> >> Therefore, do you have any recommendations on how should I handle this >> case ? >> > The RISC-V IMSIC driver does not register per-CPU interrupts > rather it treats IDs across all CPUs as independent vectors and > picks the right vector for a device MSI based on availability + affinity. > > Only the RISC-V intc driver manages per-CPU interrupts so the > Xen guest event channel interrupt should be a local interrupt > managed by RISC-V intc driver. > > Regards, > Anup