This is actually what the caller acquire_resource() expects on any kind
of error (the comment on top of resource_max_frames() also suggests that).
Otherwise, the caller will treat -errno as a valid value and propagate incorrect
nr_frames to the VM. As a possible consequence, a VM trying to query a resource
size of an unknown type will get the success result from the hypercall and obtain
nr_frames
4294967201.
Also, add an ASSERT_UNREACHABLE() in the default case of _acquire_resource(),
normally we won't get to this point, as an unknown type will always be rejected
earlier in resource_max_frames().
Also, update test-resource app to verify that Xen can deal with invalid
(unknown) resource type properly.
Fixes: 9244528955de ("xen/memory: Fix acquire_resource size semantics")
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit:
9b8708290002f0a4d0b363e0c66ce945f6b520bd
master date: 2025-02-18 14:47:34 +0000
fail(" Fail: Managed to map gnttab v2 status frames in v1 mode\n");
xenforeignmemory_unmap_resource(fh, res);
}
+
+ /*
+ * If this check starts failing, you've found the right place to test your
+ * addition to the Acquire Resource infrastructure.
+ */
+ rc = xenforeignmemory_resource_size(fh, domid, 3, 0, &size);
+
+ /* Check that Xen rejected the resource type. */
+ if ( !rc )
+ fail(" Fail: Expected error on an invalid resource type, got success\n");
}
static void test_domain_configurations(void)
return d->vmtrace_size >> PAGE_SHIFT;
default:
- return -EOPNOTSUPP;
+ return 0;
}
}
return acquire_vmtrace_buf(d, id, frame, nr_frames, mfn_list);
default:
+ ASSERT_UNREACHABLE();
return -EOPNOTSUPP;
}
}