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

Re: [PATCH 20/24] XSM: fold xsm_{,un}map_domain_pirq() hooks


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Date: Thu, 13 Aug 2026 08:42:30 -0400
  • Arc-authentication-results: i=1; mx.zohomail.com; dkim=pass header.i=apertussolutions.com; spf=pass smtp.mailfrom=dpsmith@xxxxxxxxxxxxxxxxxxxx; dmarc=pass header.from=<dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1786624952; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; bh=Za9EcdLJWXnTEiY37uj/GrBDPCX3LBcarDK7TVNkNuQ=; b=PCZj+AvVcRfbhH+CQz2GtXK6tQ/qGacvOmuBINsa4KV0Vsf/i2O+RpezaAjF2Rpazd2lusO8qyJEjQik9ptvx6ZPitoCoMMyJUU2ZdNsU57n9xdCovmflfdfqLjKEhhb1MwY/W3WB5AFIXX9glOeYTgsAhDyoojEhSv1JUWyQMg=
  • Arc-seal: i=1; a=rsa-sha256; t=1786624952; cv=none; d=zohomail.com; s=zohoarc; b=gaHJa66Rjuhi6xoH52Jgiw/U4Juq8kTHXEs64E9hqfZ7UO7wlLPV6spF0dfvjO7kIW1omcxc313Pvd9ecP6XZ9rJwCQVxn1qsx+bF0H7ajAApDhNpyLTOVoIHIHHSj8xY+Y9WIBSA/xjcaz87EgQIXf6N/OZ1Q0pHE457OPR0P0=
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=zoho header.d=apertussolutions.com header.i="dpsmith@xxxxxxxxxxxxxxxxxxxx" header.h="Message-ID:Date:MIME-Version:Subject:To:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding"
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Teddy Astie <teddy.astie@xxxxxxxxxx>, Roger Pau Monné <roger@xxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 13 Aug 2026 12:42:49 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>



On 8/6/26 3:36 AM, Jan Beulich wrote:
On 06.08.2026 03:10, Daniel P. Smith wrote:
On 7/28/26 9:23 AM, Jan Beulich wrote:
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1022,14 +1022,9 @@ static char *cf_check flask_show_irq_sid
#ifdef CONFIG_HAS_PIRQ -static int cf_check flask_map_domain_pirq(struct domain *d)
+static int cf_check flask_map_domain_pirq(struct domain *d, bool access)
   {
-    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
-}
-
-static int cf_check flask_unmap_domain_pirq(struct domain *d)
-{
-    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+    return current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(access));
   }
#endif /* CONFIG_HAS_PIRQ */


I am not opposed to collapsing the calls as long as the semantic is not
lost, which I feel the reuse of the xsm_map_domain_pirq does looses it
much less provides an opportunity for confusion. Something like
xsm_domain_pirq(..., access) makes more semantic sense to me, as it
would read, grant domain pirq access T/F.

In fact I was as well wondering about naming (and a possible name change)
here. I decided against it because of the other hooks (touched by patch
19), which all follow a similar model of their names really more expressing
the "positive" form than the "negative" one. Further, entirely losing "map"
from the name also doesn't look quite right, as physdev_{,un}map_pirq() is
where they're called from. To follow the naming of some of the other hook,
maybe xsm_domain_pirq_mapping(..., bool map)? Possibly even with "domain"
dropped from the name, fully fitting xsm_io{mem,port}_mapping()? Which
would then further raise the question whether patch 19 should maybe rename
the parameters of those two hooks to "map" at the same time.


Sound like you and I were running through the same argument with ourselves, except you went right and I went left.

For me, I find the false case of xsm_map_domain_pirq(..., access) reads a bit weird, "Can the target map domain pirq access=false?" I do like your mapping suggestion along with the parameter rename to map. It changes the reading to "Is target allowed map(true)/unmap(false) for the domain pirq mapping?" This could be carried through to the other cases.

v/r,
dps





 


Rackspace

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