[Public]

> -----Original Message-----
> From: Jan Beulich <[email protected]>
> Sent: Thursday, September 11, 2025 7:02 PM
> To: Penny, Zheng <[email protected]>; Daniel P. Smith
> <[email protected]>
> Cc: Huang, Ray <[email protected]>; [email protected]
> Subject: Re: [PATCH v2 15/26] xen/domctl: wrap
> xsm_{irq_permission,iomem_permission} with CONFIG_MGMT_HYPERCALLS
>
> On 10.09.2025 09:38, Penny Zheng wrote:
> > --- a/xen/xsm/flask/hooks.c
> > +++ b/xen/xsm/flask/hooks.c
> > @@ -1111,12 +1111,14 @@ static int cf_check flask_unbind_pt_irq(
> >      return current_has_perm(d, SECCLASS_RESOURCE,
> RESOURCE__REMOVE);
> > }
> >
> > +#ifdef CONFIG_MGMT_HYPERCALLS
> >  static int cf_check flask_irq_permission(
> >      struct domain *d, int pirq, uint8_t access)  {
> >      /* the PIRQ number is not useful; real IRQ is checked during mapping */
> >      return current_has_perm(d, SECCLASS_RESOURCE,
> > resource_to_perm(access));  }
> > +#endif /* CONFIG_MGMT_HYPERCALLS */
> >
> >  struct iomem_has_perm_data {
> >      uint32_t ssid;
> > @@ -1943,8 +1945,10 @@ static const struct xsm_ops __initconst_cf_clobber
> flask_ops = {
> >      .unmap_domain_irq = flask_unmap_domain_irq,
> >      .bind_pt_irq = flask_bind_pt_irq,
> >      .unbind_pt_irq = flask_unbind_pt_irq,
> > +#ifdef CONFIG_MGMT_HYPERCALLS
> >      .irq_permission = flask_irq_permission,
> >      .iomem_permission = flask_iomem_permission,
> > +#endif
> >      .iomem_mapping = flask_iomem_mapping,
> >      .pci_config_permission = flask_pci_config_permission,
> >
>
> It's odd that flask_iomem_permission() remains as a function, but for the 
> moment
> that looks to be necessary, as it's (oddly enough) called from
> flask_iomem_mapping(). However, for that one I again can't drive from titles 
> of
> subsequent patches where it would be taken care of.
>
> Daniel - is this layering actually helpful? Can't we either drop
> flask_iomem_mapping() (with the benefit of a cf_check disappearing), or have 
> it do
> directly what it wants done, rather than calling the other hook function?
>

If with no explicit worries, I'll create a new commit in next serie to remove 
redundant xsm_iomem_mapping(). Then here, we only shall take care of  
xsm_irq_permission()

> Having reached the bottom of the patch - what about xsm/dummy.h?
>
> Jan

Reply via email to