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

Re: [PATCH v4 09/11] silo: remove circular xsm hook call


  • To: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 9 Sep 2021 17:45:29 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Obk2aI5gcsFFFM6Z23Rp7Yx/We9v/EARn0Z5pydQ+N8=; b=QWeO1xo9LqwTA1QUK52+BRPjAJjdPlmSkd0xG+2ZW2BbGxCKA/WW9uCwJdzSuJTVRaH/cyrii0Jjcwnup4yPg9rJRklJVTQ40aSeFyNbl2B4zwJwfpWRj7M5gS/f3MQmEMm1N3isTHd2QN9jRPjhSj3SBppfRFdEQqA9+IdyuheNP3vZfLzF5x83Rrd4c+JjT2DGY/On3KxDZG2nvDzHWWgF51ir3PPFva8Sgh3Rwk36DRF801RJq4Ep99O6SqS+zqZwZ79LZewZw5SKCbAo1qoqS/wwUGNcU2wo5Lp/UAQ2s66VcdgOtnz+/mpybTtHxcvrW9Egb9idTPP/qq0SJA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ypja0fzlQ58crFjt2SzThOPS3RtPdBsOS2fZEPRlz8W5O6roSTuq8UGLka3v1oPxWT3BIq8rPYsK8GO6GArEV6FgGoGuxyspJTTBIVtZlpO+CE1vTfSwbUFzWeXPqLFLchIFZRozA+iilBqGyO8qlRcWlS7SCKDNaDcnglOSfNnkz3LBZOe6ShSxZgY+u00k6FR0pw3ojcomFIvH5GsnSRFjP34Jdais+vgtpChtexeA7AHAn7wS1ZRUSQQzgd0nWtEAQE4Pes7CWCsb97HYSuaWO7GZV6vX/UDd6/pycYrhfCNVerkC6uvRbd0sz94fu9zq0T0stpun7H2Y4TsywA==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 09 Sep 2021 15:45:42 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 03.09.2021 21:06, Daniel P. Smith wrote:
> SILO implements a few XSM hooks to extended the decision logic beyond
> what is defined in the dummy/default policy. For each of the hooks, it
> falls back to the dummy/default policy. The fall back is done a slight
> round-about way. This commit makes the direct call to the default policy's
> logic, xsm_default_action().

Again it's not clear to me what you're finding wrong here. The way it's
done is not as direct as it could be, but going through the extra layer
allows the functions to document things at the same time. You lose not
only that documentation, but also ...

> @@ -43,7 +44,7 @@ static int silo_evtchn_unbound(struct domain *d1, struct 
> evtchn *chn,
>      else
>      {
>          if ( silo_mode_dom_check(d1, d2) )
> -            rc = xsm_evtchn_unbound(d1, chn, id2);
> +            rc = xsm_default_action(XSM_TARGET, current->domain, d1);

... will need to sync changes to the dummy xsm_evtchn_unbound(), no
matter how unlikely such may be, back to here. This would be quite
easy to forget.

But maybe I'm overlooking something where how things are really gets in
the way of something you mean to do in the remaining two patches (or
later)?

>  static int silo_grant_copy(struct domain *d1, struct domain *d2)
>  {
>      if ( silo_mode_dom_check(d1, d2) )
> -        return xsm_grant_copy(d1, d2);
> +        return xsm_default_action(XSM_HOOK, d1, d2);
>      return -EPERM;
>  }
>  
> @@ -86,14 +87,14 @@ static int silo_argo_register_single_source(const struct 
> domain *d1,
>                                              const struct domain *d2)
>  {
>      if ( silo_mode_dom_check(d1, d2) )
> -        return xsm_argo_register_single_source(d1, d2);
> +        return 0;
>      return -EPERM;
>  }
>  
>  static int silo_argo_send(const struct domain *d1, const struct domain *d2)
>  {
>      if ( silo_mode_dom_check(d1, d2) )
> -        return xsm_argo_send(d1, d2);
> +        return 0;
>      return -EPERM;
>  }

This would then also avoid introducing the anomaly observed by Andrew here.
And in fact the Argo dummy functions may be a good example where a change
might happen down the road - them being all empty doesn't seem quite right
to me.

Jan




 


Rackspace

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