[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 04/11] tools/xenstored: add GLOBAL_QUOTA_DATA record for live update
- To: Anthony PERARD <anthony.perard@xxxxxxxxxx>
- From: Jürgen Groß <jgross@xxxxxxxx>
- Date: Mon, 16 Mar 2026 09:15:47 +0100
- Autocrypt: addr=jgross@xxxxxxxx; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Julien Grall <julien@xxxxxxx>
- Delivery-date: Mon, 16 Mar 2026 08:15:59 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 13.03.26 18:08, Anthony PERARD wrote:
On Thu, Mar 05, 2026 at 02:52:01PM +0100, Juergen Gross wrote:
diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c
index acdcaa769e..694ae58973 100644
--- a/tools/xenstored/domain.c
+++ b/tools/xenstored/domain.c
@@ -1332,6 +1332,27 @@ int do_set_feature(const void *ctx, struct connection
*conn,
return 0;
}
+static bool parse_quota_name(const char *name, unsigned int *qidx,
+ unsigned int *idx)
+{
+ unsigned int q;
What do you think of using something like:
const char soft_prefix[] = "soft-";
const size_t soft_prefix_len = sizeof(soft_prefix) - 1;
to explain the `5`, here and in e.g. the function build_quota_data() ?
We used this in libxl in one place:
https://elixir.bootlin.com/xen/v4.21.0/source/tools/libs/light/libxl_qmp.c#L1288
But it's fine to leave it like that, as the '5's are close enought to
the prefix that we can guess easly enough.
I can change it, but I'd prefer to use macros for that purpose.
+
+ if (strncmp(name, "soft-", 5)) {
+ *idx = Q_IDX_HARD;
+ } else {
+ *idx = Q_IDX_SOFT;
+ name += 5;
+ }
+ for (q = 0; q < ACC_N; q++) {
+ if (quota_adm[q].name && !strcmp(quota_adm[q].name, name)) {
+ *qidx = q;
+ return false;
+ }
+ }
+
+ return true;
+}
+
static int close_xgt_handle(void *_handle)
{
xengnttab_close(*(xengnttab_handle **)_handle);
@@ -2001,6 +2022,61 @@ void read_state_connection(const void *ctx, const void
*state)
}
}
+static unsigned int get_quota_size(struct quota *quota, unsigned int *len)
+{
+ unsigned int q;
+ unsigned int n = 0;
+
+ for (q = 0; q < ACC_N; q++) {
+ if (!quota_adm[q].name)
+ continue;
+ if (quota[q].val[Q_IDX_HARD] != Q_VAL_DISABLED) {
+ n++;
+ *len += strlen(quota_adm[q].name) + 1;
+ }
+ if (quota[q].val[Q_IDX_SOFT] != Q_VAL_DISABLED) {
+ n++;
+ *len += strlen(quota_adm[q].name) + 5 + 1;
The value 5 here isn't explained. A comment would be nice.
Using the macro mentioned above will make it more descriptive.
+ }
+ }
+
+ return n;
+}
+
+static void build_quota_data(struct quota *quota, uint32_t *val, char *name)
I guess we will need a leap of faith to trust that `val` is big enough,
after finding out that it's actually an output of multiple values, and
not an input of a single value.
That's what get_quota_size() is calculating.
And `name` seems to also be an output, and this is actually impossible
to guess from the prototype.
True. What about names?
+{
+ unsigned int q;
+ unsigned int n = 0;
+
+ for (q = 0; q < ACC_N; q++) {
+ if (!quota_adm[q].name)
+ continue;
+ if (quota[q].val[Q_IDX_HARD] != Q_VAL_DISABLED) {
+ val[n++] = quota[q].val[Q_IDX_HARD];
+ strcpy(name, quota_adm[q].name);
+ name += strlen(name) + 1;
+ }
+ if (quota[q].val[Q_IDX_SOFT] != Q_VAL_DISABLED) {
+ val[n++] = quota[q].val[Q_IDX_SOFT];
+ strcpy(name, "soft-");
+ strcpy(name + 5, quota_adm[q].name);
+ name += strlen(name) + 1;
+ }
+ }
+}
+
+static void parse_quota_data(const uint32_t *val, const char *name,
+ unsigned int n, struct quota *quota)
+{
+ unsigned int i, q, idx;
+
+ for (i = 0; i < n; i++) {
+ if (!parse_quota_name(name, &q, &idx))
+ quota[q].val[idx] = val[i];
+ name += strlen(name) + 1;
So for `val`, we have a size. But, we don't have a size for `name`, are
we sure that it's safe to keep reading past `NUL` characters ? Is the
size of name available somewhere?
Yes. get_quota_size() calculated that as well.
+ }
+}
+
static int dump_state_domain(const void *k, void *v, void *arg)
{
struct domain *domain = v;
@@ -2049,6 +2125,53 @@ void read_state_domain(const void *ctx, const void
*state, unsigned int version)
domain->features = sd->features;
}
+const char *dump_state_glb_quota(FILE *fp)
+{
+ struct xs_state_record_header *head;
+ struct xs_state_glb_quota *glb;
+ void *record;
+ unsigned int n_quota;
+ unsigned int len = sizeof(*glb);
+ size_t ret;
+
+ n_quota = get_quota_size(quotas, &len);
So, get_quota_size is actually an "add" the size to this variable, and
not "store" the size in this variable. That's not confusing at all.
Would it be better if len is renamed to names_len (both here and the
parameter of get_quota_size())?
+ len += n_quota * sizeof(glb->quota_val[0]);
+ len = ROUNDUP(len, 3);
+
+ record = talloc_size(NULL, len + sizeof(*head));
+ if (!record)
+ return "Dump global quota allocation error";
+
+ head = record;
+ head->type = XS_STATE_TYPE_GLB_QUOTA;
+ head->length = len;
+
+ glb = (struct xs_state_glb_quota *)(head + 1);
+ glb->n_dom_quota = n_quota;
+ glb->n_glob_quota = 0;
Shouldn't `n_quota` be assigned to `n_glob_quota` instead? We don't have
per-domain quota yet, and only have global quota, right?
We are applying all global quota values to the domains, so this is fine.
It isn't about where we store the quota (per domain or globally), but
how the quota values are used.
It would be possible to have e.g. "total_memory" or "total_nodes" quota
which would not apply to single domains, but to all of xenstore. Those
would need to be counted by n_glob_quota.
+
+ build_quota_data(quotas, glb->quota_val,
+ (char *)(glb->quota_val + n_quota));
+
+ ret = fwrite(record, len + sizeof(*head), 1, fp);
+
+ talloc_free(record);
+
+ if (ret != 1 || dump_state_align(fp))
+ return "Dump global quota error";
+
+ return NULL;
+}
+
+void read_state_glb_quota(const void *ctx, const void *state)
+{
+ const struct xs_state_glb_quota *glb = state;
+ unsigned int n_quota = glb->n_dom_quota + glb->n_glob_quota;
+ const char *name = (const char *)(glb->quota_val + n_quota);
+
+ parse_quota_data(glb->quota_val, name, n_quota, quotas);
+}
+
Juergen
Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
|