[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/4] domctl: Provide appropriate error code when PIRQs are not supported


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Milan Djokic <milan_djokic@xxxxxxxx>
  • Date: Tue, 9 Dec 2025 13:48:05 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • 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=AjOF1jGeG5tmY5uUcGwJW9qBoJ67+psJtHnPGaetGqM=; b=c+pphwG566AysaO5UHSXpFqpc3rbftd3W+eVUV7+Fh5DG2py9/BWOkynJ7hNKeyoUb/c3OFXIRz4W+n1O1iTAppZW6HCWW97ean3y7DtBbWxdcNz3EnK/DE4Ho6UhL8vx61PPjQr8S+i1q/WEVNxRMAuXLvu64O4Gn1B9avcm03KwHdi6bscx2Kr4XT5hiS/kqqalenjhyugPK8can4wI4HIjqvrOHVXY0kP1b/krnhW+IfJRESNLyDVYIkRlXcVcOzo+aufjuQQ3F6sekX/bphzDQizYaxQpWjEUFqZLmXG2UtKCpfKwXZvlHSAv575tueRJKdNAdQkqUZt79flHA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QCXQOkIbOaVQ1VDTLWt6XjTEtxDjRx/CGpUM5SLWFZJx8r5v1X7sWcdrR1E2T8LGnV+wzJb+vr+DEJA2KUErcKFFsnARHHGWpJQgr5rErK0I3yGSfMI449KW9Lp9QGn8kBULznX8gWzlVxb0n3kCsRhA/hNesJ037oQQzJ2Yn4t/JVcpp+yAWL5NYOpB0N8aYxJjxui/l/5AOZjCe7oHBhpRg7+BUYCkL7B8zXkc0Qv1nCgdKcwIMt9+9Wi7t2LfkOISqSEu8L+kbs3BQwd/mQM/CHTy4SMnuebff0Hnock+ilPSTMprD1sJhGqGsF4IuumJy3qcAx421SMc5Qzimg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 09 Dec 2025 12:48:18 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 12/8/25 14:08, Jan Beulich wrote:
On 05.12.2025 21:36, Milan Djokic wrote:
When PIRQs are not supported (e.g. for arm), XEN_DOMCTL_irq_permission
command is not handled.
This results with default (-ENOSYS) error code returned to control domain.
Update command handling to return -EOPNOTSUPP if control domain
invokes it by mistake when PIRQs are not supported.

Did you consider simply replacing the bogus ENOSYS by EOPNOTSUPP? (Assuming
the difference in error code really makes a difference to callers.)


Yes, this is the simplest approach. I didn’t do it because I wanted to keep a distinction between commands that are part of the Xen interface but not supported on the current configuration/platform, and commands that don’t exist at all. I also tried to follow the existing pattern, where unsupported commands are handled explicitly rather than falling through to the default case (e.g. set_llc_colors, soft_reset, etc). If this distinction isn’t useful, then yes, I can definitely just rely on a default-case error.

--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -555,14 +555,14 @@ static XSM_INLINE int cf_check xsm_unmap_domain_irq(
      XSM_ASSERT_ACTION(XSM_HOOK);
      return xsm_default_action(action, current->domain, d);
  }
-
+#ifdef CONFIG_HAS_PIRQ
  static XSM_INLINE int cf_check xsm_irq_permission(
      XSM_DEFAULT_ARG struct domain *d, int pirq, uint8_t allow)
  {
      XSM_ASSERT_ACTION(XSM_HOOK);
      return xsm_default_action(action, current->domain, d);
  }
-
+#endif
  static XSM_INLINE int cf_check xsm_iomem_permission(
      XSM_DEFAULT_ARG struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
  {

Why would you zap blank lines like this (also elsewhere)?


Will fix this.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.