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

Re: [RFC 4/6] capabilities: introduce console io as a domain capability


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Date: Tue, 8 Aug 2023 19:32:51 -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=1691537576; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=yIJghSW8omd3M8TJsuo41CcpbjM/paoBCzdM07Hk/Ik=; b=HNm2K1Qq2wZIb+QE5Os6paD26kL8WvBj16PcQlGTaRB3/bqCBN4ml3LUXMaQPZRTK3O+BQeybRgHRYu/KKxhqSDzyXJWh72bSSRrczdFPEW0AlRE1LwIv5dC3IcKAXMPZWPz9JEgkLR4Kpw3kMy63NoFvWlk/pyTCyrpHNiVndA=
  • Arc-seal: i=1; a=rsa-sha256; t=1691537576; cv=none; d=zohomail.com; s=zohoarc; b=EBSJmbzn2Rkk06O6cgqX3DQB0dg1wY/I/sp1NglCIifjRAmxqSlHqBPMnQzuS+hcxhqVOZ+GiSAyUNSqKykOpoh1DXWJ87R7W+NRaXtrrTRonA0xnaXSSrgCZU8TH+WSldYliBErJwAEpJw9W4sBxTt8Jnar3j6JWFShTlDDaSc=
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 08 Aug 2023 23:33:09 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 8/8/23 11:24, Jan Beulich wrote:
On 01.08.2023 22:20, Daniel P. Smith wrote:
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -472,8 +472,8 @@ struct domain
  #define ROLE_HARDWARE_DOMAIN   (1U<<2)
  #define ROLE_XENSTORE_DOMAIN   (1U<<3)
      uint8_t          role;
-    /* Can this guest access the Xen console? */
-    bool             is_console;
+#define CAP_CONSOLE_IO  (1U<<0)
+    uint8_t          capabilities;
      /* Is this guest being debugged by dom0? */
      bool             debugger_attached;
      /*
@@ -1146,6 +1146,27 @@ static always_inline bool is_hvm_vcpu(const struct vcpu 
*v)
      return is_hvm_domain(v->domain);
  }
+static always_inline bool domain_has_cap(
+    const struct domain *d, uint8_t cap)
+{
+    return d->capabilities & cap;
+}

What you implement here is effectively domain_has_any_cap(), which I
don't think is of much use. At the very least you want to assert that
cap is a power of two. But perhaps you rather want the caller to pass
in a bit number, not a mask, such that it's obvious that only one
thing can be checked at a time.

I did this thinking I was going to save keystrokes and encapsulate the check, but I just double checked and it would have only saved one. I will drop this and put the explicit bit checks at all the check sites.

+static always_inline bool domain_set_cap(
+    struct domain *d, uint8_t cap)
+{
+    switch ( cap )
+    {
+    case CAP_CONSOLE_IO:
+        d->capabilities |= cap;
+        break;
+    default:
+        return false;
+    }
+
+    return domain_has_cap(d, cap);
+}

The "set" operation doesn't need to be an inline function, does it?

I guess not, I can move into common/domain.c.

v/r,
dps



 


Rackspace

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