Re: [PATCH RFC 0/8] Add Counter delegation ISA extension support
Hi Daniel, On Sat, Jun 1, 2024 at 2:52 AM Daniel Henrique Barboza wrote: > > Hi Atish, > > > I see that Rajnesh sent some patches that were built on top of this > work [1], and this series no longer applies neither to alistair's > risc-to-apply.next nor to master. > > If you could send a rebased version of this series that would be great. > > Yes. I am planning to send revised series for counter delegation, Smcntrpmf and a few other miscellaneous fixes soon. > Thanks, > > > Daniel > > > > [1] > https://lore.kernel.org/qemu-riscv/20240529160950.132754-1-rkan...@rivosinc.com/ > > > On 2/16/24 21:01, Atish Patra wrote: > > This series adds the counter delegation extension support. The counter > > delegation ISA extension(Smcdeleg/Ssccfg) actually depends on multiple ISA > > extensions. > > > > 1. S[m|s]csrind : The indirect CSR extension[1] which defines additional > > 5 ([M|S|VS]IREG2-[M|S|VS]IREG6) register to address size limitation of > > RISC-V CSR address space. > > 2. Smstateen: The stateen bit[60] controls the access to the registers > > indirectly via the above indirect registers. > > 3. Smcdeleg/Ssccfg: The counter delegation extensions[2] > > > > The counter delegation extension allows Supervisor mode to program the > > hpmevent and hpmcounters directly without needing the assistance from the > > M-mode via SBI calls. This results in a faster perf profiling and very > > few traps. This extension also introduces a scountinhibit CSR which allows > > to stop/start any counter directly from the S-mode. As the counter > > delegation extension potentially can have more than 100 CSRs, the > > specificaiton > > leverages the indirect CSR extension to save the precious CSR address range. > > > > Due to the dependancy of these extensions, the following extensions must be > > enabled to use the counter delegation feature in S-mode. > > > > "smstateen=true,sscofpmf=true,ssccfg=true,smcdeleg=true,smcsrind=true,sscsrind=true" > > > > This makes the qemu command line quite tedious. In stead of that, I think we > > can enable these features by default if there is no objection. > > > > The first 2 patches decouple the indirect CSR usage from AIA implementation > > while patch3 adds stateen bits validation for AIA. > > The PATCH4 implements indirect CSR extensions while remaining patches > > implement the counter delegation extensions. > > > > The Qemu patches can be found here: > > https://github.com/atishp04/qemu/tree/counter_delegation_rfc > > > > The opensbi patch can be found here: > > https://github.com/atishp04/opensbi/tree/counter_delegation_v1 > > > > The Linux kernel patches can be found here: > > https://github.com/atishp04/linux/tree/counter_delegation_rfc > > > > [1] https://github.com/riscv/riscv-indirect-csr-access > > [2] https://github.com/riscv/riscv-smcdeleg-ssccfg > > > > Atish Patra (1): > > target/riscv: Enable S*stateen bits for AIA > > > > Kaiwen Xue (7): > > target/riscv: Add properties for Indirect CSR Access extension > > target/riscv: Decouple AIA processing from xiselect and xireg > > target/riscv: Support generic CSR indirect access > > target/riscv: Add smcdeleg/ssccfg properties > > target/riscv: Add counter delegation definitions > > target/riscv: Add select value range check for counter delegation > > target/riscv: Add counter delegation/configuration support > > > > target/riscv/cpu.c | 8 + > > target/riscv/cpu.h | 1 + > > target/riscv/cpu_bits.h | 34 +- > > target/riscv/cpu_cfg.h | 4 + > > target/riscv/csr.c | 713 +--- > > target/riscv/machine.c | 1 + > > 6 files changed, 722 insertions(+), 39 deletions(-) > > > > -- > > 2.34.1 > >
Re: [PATCH v3 1/4] osdep: Make qemu_madvise() to set errno in all cases
On 2024/06/01 0:46, Philippe Mathieu-Daudé wrote: On 31/5/24 17:10, Michal Privoznik wrote: The unspoken premise of qemu_madvise() is that errno is set on error. And it is mostly the case except for posix_madvise() which is documented to return either zero (on success) or a positive error number. This means, we must set errno ourselves. And while at it, make the function return a negative value on error, just like other error paths do. Signed-off-by: Michal Privoznik --- util/osdep.c | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/util/osdep.c b/util/osdep.c index e996c4744a..1345238a5c 100644 --- a/util/osdep.c +++ b/util/osdep.c @@ -57,7 +57,19 @@ int qemu_madvise(void *addr, size_t len, int advice) #if defined(CONFIG_MADVISE) return madvise(addr, len, advice); #elif defined(CONFIG_POSIX_MADVISE) - return posix_madvise(addr, len, advice); + /* + * On Darwin posix_madvise() has the same return semantics as + * plain madvise, i.e. errno is set and -1 is returned. Otherwise, + * a positive error number is returned. + */ Alternative is to guard with #ifdef CONFIG_DARWIN ... #else ... #endif which might be clearer. Although this approach seems reasonable, so: Reviewed-by: Philippe Mathieu-Daudé We should use plain madvise() if posix_madvise() is broken. In fact, QEMU detects the availability of plain madvise() and use it instead of posix_madvise() on my MacBook. Perhaps it may be better to stop defining CONFIG_POSIX_MADVISE on Darwin to ensure we never use the broken implementation.
Re: [RFC PATCH v2 2/5] meson: move block.syms dependency out of libblock
>On 2024/05/27 19:49, Paolo Bonzini wrote: In order to define libqemuutil symbols that are requested by block modules, QEMU currently uses a combination of the "link_depends" argument of libraries (which is propagated into dependencies, but not available in dependencies) and the "link_args" argument of declare_dependency() (which _is_ available in static_library, but probably not used for historical reasons only). Unfortunately the link_depends will not be propagated into the "block" dependency if it is defined using declare_dependency(objects: ...); and it is not possible to add it directly to the dependency because the keyword argument simply is not available. The only solution, in order to switch to defining the dependency without using "link_whole" (which has problems of its own, see https://github.com/mesonbuild/meson/pull/8151#issuecomment-754796420), is unfortunately to add the link_args and link_depends to the executables directly; fortunately there is just four of them. It is possible (and I will look into it) to add "link_depends" to declare_dependency(), but it probably will be a while before QEMU can use it. Signed-off-by: Paolo Bonzini This is not ideal but I think is good enough. Reviewed-by: Akihiko Odaki
Re: [RFC PATCH v2 1/5] meson: move shared_module() calls where modules are already walked
On 2024/05/27 19:49, Paolo Bonzini wrote: Signed-off-by: Paolo Bonzini Reviewed-by: Akihiko Odaki
Re: [PATCH v13 11/13] virtio-gpu: Handle resource blob commands
On 2024/05/27 12:02, Dmitry Osipenko wrote:
From: Antonio Caggiano
Support BLOB resources creation, mapping and unmapping by calling the
new stable virglrenderer 0.10 interface. Only enabled when available and
via the blob config. E.g. -device virtio-vga-gl,blob=true
Signed-off-by: Antonio Caggiano
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Huang Rui
Signed-off-by: Dmitry Osipenko
---
hw/display/virtio-gpu-virgl.c | 320 -
hw/display/virtio-gpu.c| 4 +-
include/hw/virtio/virtio-gpu.h | 2 +
3 files changed, 322 insertions(+), 4 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 7f45b4fa5fd7..0c73d9ba65f9 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -26,6 +26,7 @@
struct virtio_gpu_virgl_resource {
struct virtio_gpu_simple_resource base;
+MemoryRegion *mr;
};
static struct virtio_gpu_virgl_resource *
@@ -49,6 +50,159 @@ virgl_get_egl_display(G_GNUC_UNUSED void *cookie)
}
#endif
+#ifdef HAVE_VIRGL_RESOURCE_BLOB
+typedef enum {
+HOSTMEM_MR_MAPPED,
+HOSTMEM_MR_UNMAPPING,
+HOSTMEM_MR_FINISH_UNMAPPING,
+} HostmemMRState;
+
+struct virtio_gpu_virgl_hostmem_region {
+MemoryRegion mr;
+struct VirtIOGPU *g;
+HostmemMRState state;
+};
+
+static struct virtio_gpu_virgl_hostmem_region *
+to_hostmem_region(MemoryRegion *mr)
+{
+return container_of(mr, struct virtio_gpu_virgl_hostmem_region, mr);
+}
+
+static void virtio_gpu_virgl_resume_cmdq_bh(void *opaque)
+{
+VirtIOGPU *g = opaque;
+
+virtio_gpu_process_cmdq(g);
+}
+
+static void virtio_gpu_virgl_hostmem_region_free(void *obj)
+{
+MemoryRegion *mr = MEMORY_REGION(obj);
+struct virtio_gpu_virgl_hostmem_region *vmr;
+VirtIOGPUBase *b;
+VirtIOGPUGL *gl;
+
+vmr = to_hostmem_region(mr);
+vmr->state = HOSTMEM_MR_FINISH_UNMAPPING;
+
+b = VIRTIO_GPU_BASE(vmr->g);
+b->renderer_blocked--;
+
+/*
+ * memory_region_unref() is executed from RCU thread context, while
+ * virglrenderer works only on the main-loop thread that's holding GL
+ * context.
+ */
+gl = VIRTIO_GPU_GL(vmr->g);
+qemu_bh_schedule(gl->cmdq_resume_bh);
+}
+
+static int
+virtio_gpu_virgl_map_resource_blob(VirtIOGPU *g,
+ struct virtio_gpu_virgl_resource *res,
+ uint64_t offset)
+{
+struct virtio_gpu_virgl_hostmem_region *vmr;
+VirtIOGPUBase *b = VIRTIO_GPU_BASE(g);
+MemoryRegion *mr;
+uint64_t size;
+void *data;
+int ret;
+
+if (!virtio_gpu_hostmem_enabled(b->conf)) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: hostmem disabled\n", __func__);
+return -EOPNOTSUPP;
+}
+
+ret = virgl_renderer_resource_map(res->base.resource_id, &data, &size);
+if (ret) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: failed to map virgl resource:
%s\n",
+ __func__, strerror(-ret));
+return ret;
+}
+
+vmr = g_new0(struct virtio_gpu_virgl_hostmem_region, 1);
+vmr->g = g;
+
+mr = &vmr->mr;
+memory_region_init_ram_ptr(mr, OBJECT(mr), "blob", size, data);
+memory_region_add_subregion(&b->hostmem, offset, mr);
+memory_region_set_enabled(mr, true);
+
+/*
+ * MR could outlive the resource if MR's reference is held outside of
+ * virtio-gpu. In order to prevent unmapping resource while MR is alive,
+ * and thus, making the data pointer invalid, we will block virtio-gpu
+ * command processing until MR is fully unreferenced and freed.
+ */
+OBJECT(mr)->free = virtio_gpu_virgl_hostmem_region_free;
+
+res->mr = mr;
+
+return 0;
+}
+
+static int
+virtio_gpu_virgl_unmap_resource_blob(VirtIOGPU *g,
+ struct virtio_gpu_virgl_resource *res,
+ bool *cmd_suspended)
+{
+struct virtio_gpu_virgl_hostmem_region *vmr;
+VirtIOGPUBase *b = VIRTIO_GPU_BASE(g);
+MemoryRegion *mr = res->mr;
+int ret;
+
+if (!mr) {
+return 0;
+}
+
+vmr = to_hostmem_region(res->mr);
+
+/*
+ * Perform async unmapping in 3 steps:
+ *
+ * 1. Begin async unmapping with memory_region_del_subregion()
+ *and suspend/block cmd processing.
+ * 2. Wait for res->mr to be freed and cmd processing resumed
+ *asynchronously by virtio_gpu_virgl_hostmem_region_free().
+ * 3. Finish the unmapping with final virgl_renderer_resource_unmap().
+ */
+
+switch (vmr->state) {
+case HOSTMEM_MR_MAPPED:
+vmr->state = HOSTMEM_MR_UNMAPPING;
+
+*cmd_suspended = true;
+
+/* render will be unblocked once MR is freed */
+b->renderer_blocked++;
+
+/* memory region owns self res->mr object and frees it by itself */
+memory_region_set_enabled(mr, false);
+memory_region_del_subregion(&b->hostmem, mr);
+object_unparent(OBJECT(m
Re: [PATCH] accel/kvm: Fix two lines with hard-coded tabs
On Fri, May 31, 2024 at 06:09:52PM +0100, Peter Maydell wrote: > Date: Fri, 31 May 2024 18:09:52 +0100 > From: Peter Maydell > Subject: [PATCH] accel/kvm: Fix two lines with hard-coded tabs > X-Mailer: git-send-email 2.34.1 > > In kvm-all.c, two lines have been accidentally indented with > hard-coded tabs rather than spaces. Normalise to match the rest > of the file. > > Signed-off-by: Peter Maydell > --- > accel/kvm/kvm-all.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Zhao Liu
Re: [PATCH v13 03/13] virtio-gpu: Handle virtio_gpu_virgl_init() failure
On 2024/05/27 12:02, Dmitry Osipenko wrote:
virtio_gpu_virgl_init() may fail, leading to a further Qemu crash
because Qemu assumes it never fails. Check virtio_gpu_virgl_init()
return code and don't execute virtio commands on error. Failed
virtio_gpu_virgl_init() will result in a timed out virtio commands
for a guest OS.
Signed-off-by: Dmitry Osipenko
---
hw/display/virtio-gpu-gl.c | 29 +
include/hw/virtio/virtio-gpu.h | 11 +--
2 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
index e06be60dfbfc..38a2b1bd3916 100644
--- a/hw/display/virtio-gpu-gl.c
+++ b/hw/display/virtio-gpu-gl.c
@@ -29,9 +29,14 @@ static void virtio_gpu_gl_update_cursor_data(VirtIOGPU *g,
struct virtio_gpu_scanout *s,
uint32_t resource_id)
{
+VirtIOGPUGL *gl = VIRTIO_GPU_GL(g);
uint32_t width, height;
uint32_t pixels, *data;
+if (gl->renderer_state != RS_INITED) {
+return;
+}
+
data = virgl_renderer_get_cursor_data(resource_id, &width, &height);
if (!data) {
return;
@@ -65,13 +70,21 @@ static void virtio_gpu_gl_handle_ctrl(VirtIODevice *vdev,
VirtQueue *vq)
return;
}
-if (!gl->renderer_inited) {
-virtio_gpu_virgl_init(g);
-gl->renderer_inited = true;
-}
-if (gl->renderer_reset) {
-gl->renderer_reset = false;
+switch (gl->renderer_state) {
+case RS_RESET:
virtio_gpu_virgl_reset(g);
+/* fallthrough */
+case RS_START:
+if (virtio_gpu_virgl_init(g)) {
+gl->renderer_state = RS_INIT_FAILED;
+} else {
+gl->renderer_state = RS_INITED;
+}
+break;
+case RS_INIT_FAILED:
+return;
+case RS_INITED:
+break;
}
cmd = virtqueue_pop(vq, sizeof(struct virtio_gpu_ctrl_command));
@@ -98,9 +111,9 @@ static void virtio_gpu_gl_reset(VirtIODevice *vdev)
* GL functions must be called with the associated GL context in main
* thread, and when the renderer is unblocked.
*/
-if (gl->renderer_inited && !gl->renderer_reset) {
+if (gl->renderer_state == RS_INITED) {
virtio_gpu_virgl_reset_scanout(g);
-gl->renderer_reset = true;
+gl->renderer_state = RS_RESET;
}
}
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index 7ff989a45a5c..6e71d799e5da 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -224,11 +224,18 @@ struct VirtIOGPUClass {
Error **errp);
};
+/* VirtIOGPUGL renderer states */
+typedef enum {
+RS_START, /* starting state */
+RS_INIT_FAILED, /* failed initialisation */
Is the distinction between RS_START and RS_INIT_FAILED really necessary?
Re: [PATCH] machine: allow early use of machine_require_guest_memfd
On Fri, May 31, 2024 at 01:26:36PM +0200, Paolo Bonzini wrote: > Date: Fri, 31 May 2024 13:26:36 +0200 > From: Paolo Bonzini > Subject: [PATCH] machine: allow early use of machine_require_guest_memfd > X-Mailer: git-send-email 2.45.1 > > Ask the ConfidentialGuestSupport object whether to use guest_memfd > for KVM-backend private memory. This bool can be set in instance_init > (or user_complete) so that it is available when the machine is created. > > Signed-off-by: Paolo Bonzini > --- > include/exec/confidential-guest-support.h | 5 + > include/hw/boards.h | 1 - > hw/core/machine.c | 2 +- > 3 files changed, 6 insertions(+), 2 deletions(-) Reviewed-by: Zhao Liu
[Bug 1524546] Re: qemu-img rebase error message mentions wrong file name
What to do if the old file has been moved? Say the backing file was /path/to/os.qcow2 and it was moved to /new/path/to/os.qcow2. How can we tell snapshot.qcow2 to update the backing file from /path/to/os.qcow2 to /new/path/to/os.qcow2? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1524546 Title: qemu-img rebase error message mentions wrong file name Status in QEMU: Fix Released Bug description: While doing 'qemu-img rebase' for linking to a different backing file, if the old backing file does not exist, the command fails. During this failure, the error message shown is misleading. e.g. qemu-img rebase -b throws error saying "Could not open " Ideally it should "Could not open " snippet - [root@oxy-dev ~]# qemu-img info /opt/stack/data/nova/instances/94864a64-ebf8-45e6-a777-615921216a0a/disk image: /opt/stack/data/nova/instances/94864a64-ebf8-45e6-a777-615921216a0a/disk file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 174M cluster_size: 65536 backing file: /tmp/3559241a79b79ae663ec6e3d9b75d469967b383b Format specific information: compat: 1.1 lazy refcounts: false [root@oxy-dev ~]# mv /tmp/3559241a79b79ae663ec6e3d9b75d469967b383b /tmp/3559241a79b79ae663ec6e3d9b75d469967b383a [root@oxy-dev ~]# file !$ file /tmp/3559241a79b79ae663ec6e3d9b75d469967b383a /tmp/3559241a79b79ae663ec6e3d9b75d469967b383a: x86 boot sector; partition 1: ID=0x83, active, starthead 32, startsector 2048, 409600 sectors; partition 2: ID=0x8e, starthead 159, startsector 411648, 16365568 sectors, code offset 0xc0 [root@oxy-dev ~]# file /tmp/3559241a79b79ae663ec6e3d9b75d469967b383b /tmp/3559241a79b79ae663ec6e3d9b75d469967b383b: cannot open (No such file or directory) [root@oxy-dev ~]# qemu-img rebase -b /tmp/3559241a79b79ae663ec6e3d9b75d469967b383a /opt/stack/data/nova/instances/94864a64-ebf8-45e6-a777-615921216a0a/disk qemu-img: Could not open '/opt/stack/data/nova/instances/94864a64-ebf8-45e6-a777-615921216a0a/disk': Could not open file: No such file or directory [root@oxy-dev ~]# qemu-img version 1.5.3 OS: RHEL7 - 3.10.0-229 libvirtd (libvirt) 1.2.8 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1524546/+subscriptions
[PATCH v2 0/2] AWS Nitro Enclave emulation
This is v2 submission for AWS Nitro Enclave emulation in QEMU. v1 is at: https://mail.gnu.org/archive/html/qemu-devel/2024-05/msg03524.html Changes in v2: - moved eif.c and eif.h files from hw/i386 to hw/core Hi, Hope everyone is doing well. I am working on adding AWS Nitro Enclave[1] emulation support in QEMU. Alexander Graf is mentoring me on this work. This is a patch series adding, not yet complete, but useful emulation support of nitro enclaves. I have a gitlab branch where you can view the patches in the gitlab web UI for each commit: https://gitlab.com/dorjoy03/qemu/-/tree/nitro-enclave-emulation AWS nitro enclaves is an Amazon EC2[2] feature that allows creating isolated execution environments, called enclaves, from Amazon EC2 instances, which are used for processing highly sensitive data. Enclaves have no persistent storage and no external networking. The enclave VMs are based on Firecracker microvm and have a vhost-vsock device for communication with the parent EC2 instance that spawned it and a Nitro Secure Module (NSM) device for cryptographic attestation. The parent instance VM always has CID 3 while the enclave VM gets a dynamic CID. The enclave VMs can communicate with the parent instance over various ports to CID 3, for example, the init process inside an enclave sends a heartbeat to port 9000 upon boot, expecting a heartbeat reply, letting the parent instance know that the enclave VM has successfully booted. >From inside an EC2 instance, nitro-cli[3] is used to spawn an enclave VM using an EIF (Enclave Image Format)[4] file. EIF files can be built using nitro-cli as well. There is no official EIF specification apart from the github aws-nitro-enclaves-image-format repository[4]. An EIF file contains the kernel, cmdline and ramdisk(s) in different sections which are used to boot the enclave VM. You can look at the structs in hw/i386/eif.c file for more details about the EIF file format. Adding nitro enclave emulation support in QEMU will make the life of AWS Nitro Enclave users easier as they will be able to test their EIF images locally without having to run real nitro enclaves which can be difficult for debugging due to its roots in security. This will also make quick prototyping easier. In QEMU, the new nitro-enclave machine type is implemented based on the microvm machine type similar to how AWS Nitro Enclaves are based on Firecracker microvm. The vhost-vsock device support is already part of this patch series so that the enclave VM can communicate to CID 3 using vsock. A mandatory 'guest-cid' machine type option is needed which becomes the CID of the enclave VM. Some documentation for the new 'nitro-enclave' machine type has also been added. The NSM device support will be added in the future. The plan is to eventually make the nitro enclave emulation in QEMU standalone i.e., without needing to run another VM with CID 3 with proper vsock communication support. For this to work, one approach could be to teach the vhost-vsock driver in kernel to forward CID 3 messages to another CID (set to CID 2 for host) so that users of the nitro-enclave machine type can run the necessary vsock server/clients in the host machine (some defaults can be implemented in QEMU as well, for example, sending a reply to the heartbeat) which will rid them of the cumbersome way of running another whole VM with CID 3. This way, users of nitro-enclave machine in QEMU, could potentially also run multiple enclaves with their messages for CID 3 forwarded to different CIDs which, in QEMU side, could then be specified using a new machine type option (parent-cid) if implemented. I will be posting an email to the linux virtualization mailing list about this approach asking for feedback and suggestions soon. For local testing you need to generate a hello.eif image by first building nitro-cli locally[5]. Then you can use nitro-cli to build a hello.eif image[6]. You need to build qemu-system-x86_64 after applying the patches and then you can run the following command to boot a hello.eif image using the new 'nitro-enclave' machine type option in QEMU: sudo ./qemu-system-x86_64 -M nitro-enclave,guest-cid=8 -kernel path/to/hello.eif -nographic -m 4G --enable-kvm -cpu host The command needs to be run as sudo because for the vhost-vsock device to work QEMU needs to be able to open vhost device in host. Right now, if you just run the nitro-enclave machine, the kernel panics because the init process exits abnormally because it cannot connect to port 9000 to CID 3 to send its heartbeat message (the connection times out), so another VM with CID 3 with proper vsock communication support must be run for it to be useful. But this restriction can be lifted once the approach about forwarding CID 3 messages is implemented if it gets accepted. Thanks. Regards, Dorjoy [1] https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave.html [2] https://aws.amazon.com/ec2/ [3] https://docs.aws.amazon.com/enclaves/latest/user/
[PATCH v2 2/2] machine/nitro-enclave: new machine type for AWS nitro enclave
AWS nitro enclaves[1] is an Amazon EC2[2] feature that allows creating isolated execution environments, called enclaves, from Amazon EC2 instances which are used for processing highly sensitive data. Enclaves have no persistent storage and no external networking. The enclave VMs are based on Firecracker microvm with a vhost-vsock device for communication with the parent EC2 instance that spawned it and a Nitro Secure Module (NSM) device for cryptographic attestation. The parent instance VM always has CID 3 while the enclave VM gets a dynamic CID. This commit adds support for limited AWS nitro enclave emulation using a new machine type option '-M nitro-enclave'. This new machine type is based on the 'microvm' machine type (similar to how real nitro enclave VMs are based on Firecracker microvm) which requires a mandatory 'guest-cid' machine type option which becomes the CID of the running nitro-enclave VM using a built-in vhost-vsock device. The code for checking and loading EIF in the microvm machine code added in the previous commit has been put inside a 'nitro-enclave' machine type check so that EIF images can only be loaded using a 'nitro-enclave' machine. Right now, the emulation support is not complete as nitro-enclave cannot be run standalone using QEMU. A separate VM with CID 3 must be run with the necessary vsock communication support that the enclave VM communicates with. Also the Nitro Secure Module (NSM) device is not implemented yet. [1] https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave.html [2] https://aws.amazon.com/ec2/ Signed-off-by: Dorjoy Chowdhury --- MAINTAINERS | 10 ++ configs/devices/i386-softmmu/default.mak | 1 + docs/system/i386/nitro-enclave.rst | 58 ++ hw/i386/Kconfig | 4 + hw/i386/meson.build | 1 + hw/i386/microvm.c| 21 ++-- hw/i386/nitro_enclave.c | 134 +++ include/hw/i386/nitro_enclave.h | 38 +++ 8 files changed, 260 insertions(+), 7 deletions(-) create mode 100644 docs/system/i386/nitro-enclave.rst create mode 100644 hw/i386/nitro_enclave.c create mode 100644 include/hw/i386/nitro_enclave.h diff --git a/MAINTAINERS b/MAINTAINERS index 448dc951c5..250ab32743 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1867,6 +1867,16 @@ F: hw/i386/microvm.c F: include/hw/i386/microvm.h F: pc-bios/bios-microvm.bin +nitro-enclave +M: Alexander Graf +M: Dorjoy Chowdhury +S: Maintained +F: docs/system/i386/nitro-enclave.rst +F: hw/core/eif.c +F: hw/core/eif.h +F: hw/i386/nitro_enclave.c +F: include/hw/i386/nitro_enclave.h + Machine core M: Eduardo Habkost M: Marcel Apfelbaum diff --git a/configs/devices/i386-softmmu/default.mak b/configs/devices/i386-softmmu/default.mak index 448e3e3b1b..4faf2f0315 100644 --- a/configs/devices/i386-softmmu/default.mak +++ b/configs/devices/i386-softmmu/default.mak @@ -29,3 +29,4 @@ # CONFIG_I440FX=n # CONFIG_Q35=n # CONFIG_MICROVM=n +# CONFIG_NITRO_ENCLAVE=n diff --git a/docs/system/i386/nitro-enclave.rst b/docs/system/i386/nitro-enclave.rst new file mode 100644 index 00..0b86b6ab88 --- /dev/null +++ b/docs/system/i386/nitro-enclave.rst @@ -0,0 +1,58 @@ +'nitro-enclave' virtual machine (``nitro-enclave``) +=== + +``nitro-enclave`` is a machine type which emulates an ``AWS nitro enclave`` +virtual machine. `AWS nitro enclaves`_ is an `Amazon EC2`_ feature that allows +creating isolated execution environments, called enclaves, from Amazon EC2 +instances which are used for processing highly sensitive data. Enclaves have +no persistent storage and no external networking. The enclave VMs are based +on Firecracker microvm with a vhost-vsock device for communication with the +parent EC2 instance that spawned it and a Nitro Secure Module (NSM) device +for cryptographic attestation. The parent instance VM always has CID 3 while +the enclave VM gets a dynamic CID. Enclaves use an EIF (`Enclave Image Format`_) +file which contains the necessary kernel, cmdline and ramdisk(s) to boot. + +In QEMU, ``nitro-enclave`` is a machine type based on ``microvm`` similar to how +``AWS nitro enclaves`` are based on ``Firecracker``. This is useful for local +testing of EIF images using QEMU instead of running real AWS Nitro Enclaves +which can be difficult for debugging due to its roots in security. + +.. _AWS nitro enlaves: https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave.html +.. _Amazon EC2: https://aws.amazon.com/ec2/ +.. _Enclave Image Format: https://github.com/aws/aws-nitro-enclaves-image-format + + +Limitations +--- + +AWS nitro enclave emulation support is not complete yet: + +- Although support for the vhost-vsock device is implemented, standalone +nitro-enclave VMs cannot be run right now as nitro-enclave VMs communicate +with a parent instance VM with CID 3. So another VM with C
[PATCH v2 1/2] machine/microvm: support for loading EIF image
An EIF (Enclave Image Format)[1] image is used to boot an AWS nitro
enclave[2] virtual machine. The EIF file contains the necessary
kernel, cmdline, ramdisk(s) sections to boot.
This commit adds support for loading EIF image using the microvm
machine code. For microvm to boot from an EIF file, the kernel and
ramdisk(s) are extracted into a temporary kernel and a temporary
initrd file which are then hooked into the regular x86 boot mechanism
along with the extracted cmdline.
Although not useful for the microvm machine itself, this is needed
as the following commit adds support for a new machine type
'nitro-enclave' which uses the microvm machine type as parent. The
code for checking and loading EIF will be put inside a 'nitro-enclave'
machine type check in the following commit so that microvm cannot load
EIF because it shouldn't.
[1] https://github.com/aws/aws-nitro-enclaves-image-format
[2] https://aws.amazon.com/ec2/nitro/nitro-enclaves/
Signed-off-by: Dorjoy Chowdhury
---
hw/core/eif.c | 486
hw/core/eif.h | 20 ++
hw/core/meson.build | 1 +
hw/i386/microvm.c | 134 +++-
4 files changed, 640 insertions(+), 1 deletion(-)
create mode 100644 hw/core/eif.c
create mode 100644 hw/core/eif.h
diff --git a/hw/core/eif.c b/hw/core/eif.c
new file mode 100644
index 00..281ff43ea5
--- /dev/null
+++ b/hw/core/eif.c
@@ -0,0 +1,486 @@
+/*
+ * EIF (Enclave Image Format) related helpers
+ *
+ * Copyright (c) 2024 Dorjoy Chowdhury
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * (at your option) any later version. See the COPYING file in the
+ * top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/bswap.h"
+#include "qapi/error.h"
+#include /* for crc32 */
+
+#include "hw/core/eif.h"
+
+#define MAX_SECTIONS 32
+
+/* members are ordered according to field order in .eif file */
+typedef struct EifHeader {
+uint8_t magic[4]; /* must be .eif in ascii i.e., [46, 101, 105, 102] */
+uint16_t version;
+uint16_t flags;
+uint64_t default_memory;
+uint64_t default_cpus;
+uint16_t reserved;
+uint16_t section_cnt;
+uint64_t section_offsets[MAX_SECTIONS];
+uint64_t section_sizes[MAX_SECTIONS];
+uint32_t unused;
+uint32_t eif_crc32;
+} QEMU_PACKED EifHeader;
+
+/* members are ordered according to field order in .eif file */
+typedef struct EifSectionHeader {
+/*
+ * 0 = invalid, 1 = kernel, 2 = cmdline, 3 = ramdisk, 4 = signature,
+ * 5 = metadata
+ */
+uint16_t section_type;
+uint16_t flags;
+uint64_t section_size;
+} QEMU_PACKED EifSectionHeader;
+
+enum EifSectionTypes {
+EIF_SECTION_INVALID = 0,
+EIF_SECTION_KERNEL = 1,
+EIF_SECTION_CMDLINE = 2,
+EIF_SECTION_RAMDISK = 3,
+EIF_SECTION_SIGNATURE = 4,
+EIF_SECTION_METADATA = 5,
+EIF_SECTION_MAX = 6,
+};
+
+static const char *section_type_to_string(uint16_t type)
+{
+const char *str;
+switch (type) {
+case EIF_SECTION_INVALID:
+str = "invalid";
+break;
+case EIF_SECTION_KERNEL:
+str = "kernel";
+break;
+case EIF_SECTION_CMDLINE:
+str = "cmdline";
+break;
+case EIF_SECTION_RAMDISK:
+str = "ramdisk";
+break;
+case EIF_SECTION_SIGNATURE:
+str = "signature";
+break;
+case EIF_SECTION_METADATA:
+str = "metadata";
+break;
+default:
+str = "unknown";
+break;
+}
+
+return str;
+}
+
+static bool read_eif_header(FILE *f, EifHeader *header, uint32_t *crc,
+Error **errp)
+{
+size_t got;
+size_t header_size = sizeof(*header);
+
+got = fread(header, 1, header_size, f);
+if (got != header_size) {
+error_setg(errp, "Failed to read EIF header");
+return false;
+}
+
+if (memcmp(header->magic, ".eif", 4) != 0) {
+error_setg(errp, "Invalid EIF image. Magic mismatch.");
+return false;
+}
+
+/* Exclude header->eif_crc32 field from CRC calculation */
+*crc = crc32(*crc, (uint8_t *)header, header_size - 4);
+
+header->version = be16_to_cpu(header->version);
+header->flags = be16_to_cpu(header->flags);
+header->default_memory = be64_to_cpu(header->default_memory);
+header->default_cpus = be64_to_cpu(header->default_cpus);
+header->reserved = be16_to_cpu(header->reserved);
+header->section_cnt = be16_to_cpu(header->section_cnt);
+
+for (int i = 0; i < MAX_SECTIONS; ++i) {
+header->section_offsets[i] = be64_to_cpu(header->section_offsets[i]);
+}
+
+for (int i = 0; i < MAX_SECTIONS; ++i) {
+header->section_sizes[i] = be64_to_cpu(header->section_sizes[i]);
+}
+
+header->unused = be32_to_cpu(header->unused);
+header->eif_crc32 = be32_to_cpu(header->eif_crc32);
+return true;
+}
+
+static bool read_eif_section_header(FILE *f, EifSectionHeader *section_header,
+
Re: [PATCH V2 2/3] target/i386: call cpu_exec_realizefn before x86_cpu_filter_features
On Fri, May 31, 2024 at 10:13:47AM -0700, Chen, Zide wrote:
> Date: Fri, 31 May 2024 10:13:47 -0700
> From: "Chen, Zide"
> Subject: Re: [PATCH V2 2/3] target/i386: call cpu_exec_realizefn before
> x86_cpu_filter_features
>
> On 5/30/2024 11:30 PM, Zhao Liu wrote:
> > Hi Zide,
> >
> > On Fri, May 24, 2024 at 01:00:16PM -0700, Zide Chen wrote:
> >> Date: Fri, 24 May 2024 13:00:16 -0700
> >> From: Zide Chen
> >> Subject: [PATCH V2 2/3] target/i386: call cpu_exec_realizefn before
> >> x86_cpu_filter_features
> >> X-Mailer: git-send-email 2.34.1
> >>
> >> cpu_exec_realizefn which calls the accel-specific realizefn may expand
> >> features. e.g., some accel-specific options may require extra features
> >> to be enabled, and it's appropriate to expand these features in accel-
> >> specific realizefn.
> >>
> >> One such example is the cpu-pm option, which may add CPUID_EXT_MONITOR.
> >>
> >> Thus, call cpu_exec_realizefn before x86_cpu_filter_features to ensure
> >> that it won't expose features not supported by the host.
> >>
> >> Fixes: 662175b91ff2 ("i386: reorder call to cpu_exec_realizefn")
> >> Suggested-by: Xiaoyao Li
> >> Signed-off-by: Zide Chen
> >> ---
> >> target/i386/cpu.c | 24
> >> target/i386/kvm/kvm-cpu.c | 1 -
> >> 2 files changed, 12 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> >> index bc2dceb647fa..a1c1c785bd2f 100644
> >> --- a/target/i386/cpu.c
> >> +++ b/target/i386/cpu.c
> >> @@ -7604,6 +7604,18 @@ static void x86_cpu_realizefn(DeviceState *dev,
> >> Error **errp)
> >> }
> >> }
> >>
> >> +/*
> >> + * note: the call to the framework needs to happen after feature
> >> expansion,
> >> + * but before the checks/modifications to ucode_rev, mwait, phys_bits.
> >> + * These may be set by the accel-specific code,
> >> + * and the results are subsequently checked / assumed in this
> >> function.
> >> + */
> >> +cpu_exec_realizefn(cs, &local_err);
> >> +if (local_err != NULL) {
> >> +error_propagate(errp, local_err);
> >> +return;
> >> +}
> >> +
> >> x86_cpu_filter_features(cpu, cpu->check_cpuid || cpu->enforce_cpuid);
> >
> > For your case, which sets cpu-pm=on via overcommit, then
> > x86_cpu_filter_features() will complain that mwait is not supported.
> >
> > Such warning is not necessary, because the purpose of overcommit (from
> > code) is only to support mwait when possible, not to commit to support
> > mwait in Guest.
> >
> > Additionally, I understand x86_cpu_filter_features() is primarily
> > intended to filter features configured by the user,
>
> Yes, that's why this patches intends to let x86_cpu_filter_features()
> filter out the MWAIT bit which is set from the overcommit option.
HMM, but in fact x86_cpu_filter_features() has already checked the MWAIT
bit set by "-overcommit cpu-pm=on". ;-)
(Pls correct me if I'm wrong) Revisiting what cpu-pm did to MWAIT:
* Firstly, it set MWAIT bit in x86_cpu_expand_features():
x86_cpu_expand_features()
-> x86_cpu_get_supported_feature_word()
-> kvm_arch_get_supported_cpuid()
This MWAIT is based on Host's MWAIT capability. This MWAIT enablement
is fine for next x86_cpu_filter_features() and x86_cpu_filter_features()
is working correctly here!
* Then, MWAIT was secondly set in host_cpu_enable_cpu_pm() regardless
neither Host's support or previous MWAIT enablement result. This is
the root cause of your issue.
Therefore, we should make cpu-pm honor his first MWAIT enablement result
instead of repeatly and unconditionally setting the MWAIT bit again in
host_cpu_enable_cpu_pm().
Additionally, I think the code in x86_cpu_realizefn():
cpu->mwait.ecx |= CPUID_MWAIT_EMX | CPUID_MWAIT_IBE;
has the similar issue because it also should check MWAIT feature bit.
Further, it may be possible to remove cpu->mwait: just check the MWAIT
bit in leaf 5 of cpu_x86_cpuid(), and if MWAIT is present, use host's
mwait info plus CPUID_MWAIT_EMX | CPUID_MWAIT_IBE.
> > and the changes of
> > CPUID after x86_cpu_filter_features() should by default be regarded like
> > "QEMU knows what it is doing".
>
> Sure, we can add feature bits after x86_cpu_filter_features(), but I
> think moving cpu_exec_realizefn() before x86_cpu_filter_features() is
> more generic, and actually this is what QEMU did before commit 662175b91ff2.
>
> - Less redundant code. Specifically, no need to call
> x86_cpu_get_supported_feature_word() again.
> - Potentially there could be other features could be added from the
> accel-specific realizefn, kvm_cpu_realizefn() for example. And these
> features need to be checked against the host availability.
Mainly I don't think this reorder is a direct fix for the problem (I
just analyse it above), also in your case x86_cpu_filter_features() will
print a WARNING when QEMU boots, which I don't think is cpu-pm's intention.
Re: [PATCH] accel/tcg: nochain should disable goto_ptr
On 6/1/24 00:57, niugen wrote:
on 2024/6/1 01:32, Richard Henderson wrote:
On 5/31/24 03:17, NiuGenen wrote:
Signed-off-by: NiuGenen
---
accel/tcg/cpu-exec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
index 2972f75b96..084fa645c7 100644
--- a/accel/tcg/cpu-exec.c
+++ b/accel/tcg/cpu-exec.c
@@ -173,7 +173,7 @@ uint32_t curr_cflags(CPUState *cpu)
} else if (qatomic_read(&one_insn_per_tb)) {
cflags |= CF_NO_GOTO_TB | 1;
} else if (qemu_loglevel_mask(CPU_LOG_TB_NOCHAIN)) {
- cflags |= CF_NO_GOTO_TB;
+ cflags |= CF_NO_GOTO_TB | CF_NO_GOTO_PTR;
}
return cflags;
Why?
The original intent of nochain was so that -d exec would log all blocks, which requires
excluding goto_tb. There is exec logging in helper_lookup_goto_ptr, so there is no need
to avoid goto_ptr.
You must provide a rationale, at minimum.
r~
Sorry, my mistake. I thought nochain will disable all kinds of branches, including direct
branch and indirect branch, but I found that indirect branch still call
helper_lookup_tb_ptr to continue executing TB instead of epilogue-tblookup-prologue.
Maybe the exec logging can be removed from helper_lookup_tb_ptr and nochain can disable
all the chaining of TB?
Why? You still haven't provided a rationale.
r~
Re: Unexpected error in rme_configure_one() at ../target/arm/kvm-rme.c:159
Hi Jean and Ard,
On 6/1/24 01:09, Jean-Philippe Brucker wrote:
On Fri, May 31, 2024 at 04:23:13PM +1000, Gavin Shan wrote:
I got a chance to try CCA software components, suggested by [1]. However, the
edk2
is stuck somewhere. I didn't reach to stage of loading guest kernel yet. I'm
replying
to see if anyone has a idea.
...
INFO:BL31: Preparing for EL3 exit to normal world
INFO:Entry point address = 0x6000
INFO:SPSR = 0x3c9
UEFI firmware (version built at 01:31:23 on May 31 2024)
The boot is stuck and no more output after that. I tried adding more verbose
output
from edk2 and found it's stuck at the following point.
ArmVirtPkg/PrePi/PrePi.c::PrePiMain
rmVirtPkg/Library/PlatformPeiLib/PlatformPeiLib.c::PlatformPeim
#ifdef MDE_CPU_AARCH64
//
// Set the SMCCC conduit to SMC if executing at EL2, which is typically the
// exception level that services HVCs rather than the one that invokes them.
//
if (ArmReadCurrentEL () == AARCH64_EL2) {
Status = PcdSetBoolS (PcdMonitorConduitHvc, FALSE); // The function
is never returned in my case
ASSERT_EFI_ERROR (Status);
}
#endif
I'm able to reproduce this even without RME. This code was introduced
recently by c98f7f755089 ("ArmVirtPkg: Use dynamic PCD to set the SMCCC
conduit"). Maybe Ard (Cc'd) knows what could be going wrong here.
A slightly reduced reproducer:
$ cd edk2/
$ build -b DEBUG -a AARCH64 -t GCC5 -p ArmVirtPkg/ArmVirtQemuKernel.dsc
$ cd ..
$ git clone https://github.com/ARM-software/arm-trusted-firmware.git tf-a
$ cd tf-a/
$ make -j CROSS_COMPILE=aarch64-linux-gnu- PLAT=qemu DEBUG=1 LOG_LEVEL=40
QEMU_USE_GIC_DRIVER=QEMU_GICV3
BL33=../edk2/Build/ArmVirtQemuKernel-AARCH64/DEBUG_GCC5/FV/QEMU_EFI.fd all fip
&& \
dd if=build/qemu/debug/bl1.bin of=flash.bin && \
dd if=build/qemu/debug/fip.bin of=flash.bin seek=64 bs=4096
$ qemu-system-aarch64 -M virt,virtualization=on,secure=on,gic-version=3 -cpu
max -m 2G -smp 8 -monitor none -serial mon:stdio -nographic -bios flash.bin
Thanks for the hints. Eventually, I'm able to start the host with
'edk2-stable202402'.
Note that 'edk2-stable202405' doesn't work. However, I failed to build the edk2
for
guest and unable to start the guest successfully, more information is provided
below.
--> host's edk2
# git clone g...@github.com:gwshan/edk2.git edk2
# cd edk2; git checkout edk2-stable202402 -b stable202402
# git submodule update --init --recursive; \
source edksetup.sh; make -j -C BaseTools; \
export GCC5_AARCH64_PREFIX=; \
build -b DEBUG -a AARCH64 -t GCC5 -p ArmVirtPkg/ArmVirtQemuKernel.dsc
---> tf-a: rebuild using commands as you suggested.
---> Boot host
/home/gavin/sandbox/qemu.main/build/qemu-system-aarch64
\
-M virt,virtualization=on,secure=on,gic-version=3,acpi=off
\
-cpu max,x-rme=on -m 8G -smp 8
\
-nodefaults -monitor none -serial mon:stdio -nographic
\
-bios /home/gavin/sandbox/CCA/tf-a/flash.bin
\
-kernel /home/gavin/sandbox/CCA/linux/arch/arm64/boot/Image
\
-drive
format=raw,if=none,file=/home/gavin/sandbox/CCA/buildroot/output/images/rootfs.ext4,id=hd0
\
-device virtio-blk-pci,drive=hd0
\
-netdev
tap,id=tap0,vhost=false,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown
\
-device virtio-net-pci,netdev=tap0,mac=52:54:00:f1:26:b0
\
-append root=/dev/vda console=ttyAMA0
\
-device virtio-9p-device,fsdev=shr0,mount_tag=shr0
\
-fsdev local,security_model=none,path=/home/gavin/sandbox/CCA,id=shr0
:
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v2.10.0(debug):99e0b97aa-dirty
NOTICE: BL1: Built : 00:31:35, May 31 2024
INFO:BL1: RAM 0xe0ee000 - 0xe0f7000
INFO:BL1: Loading BL2
:
Booting RMM v.0.4.0(debug) 17924bc Built with GCC 11.4.1
RMM-EL3 Interface v.0.2
Boot Manifest Interface v.0.3
RMI/RSI ABI v.1.0/1.0 built: May 31 2024 00:21:59
INFO:RMM init end.
:
UEFI firmware (version built at 04:07:42 on Jun 1 2024)
PlatformPeim: PL011 UART (console) @ 0x900
PlatformPeim: PL011 UART (debug) @ 0x900
:
EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable
:
Welcome to Buildroot
buildroot login:
# ifconfig eth0 | grep 'inet addr'
inet addr:10.26.1.212 Bcast:10.26.1.255 Mask:255.255.255.0
---> guest edk2
# git clone https://git.codelinaro.org/linaro/dcap/edk2.git edk2-guest
# cd edk2-guest; git checkout origin/cca/v2 -b cca/v2
# git submodule update --init --recursive; \
source edksetup.sh; make -j -C BaseTools; \
export G
Re: [PATCH RFC 0/8] Add Counter delegation ISA extension support
Hi Atish, I see that Rajnesh sent some patches that were built on top of this work [1], and this series no longer applies neither to alistair's risc-to-apply.next nor to master. If you could send a rebased version of this series that would be great. Thanks, Daniel [1] https://lore.kernel.org/qemu-riscv/20240529160950.132754-1-rkan...@rivosinc.com/ On 2/16/24 21:01, Atish Patra wrote: This series adds the counter delegation extension support. The counter delegation ISA extension(Smcdeleg/Ssccfg) actually depends on multiple ISA extensions. 1. S[m|s]csrind : The indirect CSR extension[1] which defines additional 5 ([M|S|VS]IREG2-[M|S|VS]IREG6) register to address size limitation of RISC-V CSR address space. 2. Smstateen: The stateen bit[60] controls the access to the registers indirectly via the above indirect registers. 3. Smcdeleg/Ssccfg: The counter delegation extensions[2] The counter delegation extension allows Supervisor mode to program the hpmevent and hpmcounters directly without needing the assistance from the M-mode via SBI calls. This results in a faster perf profiling and very few traps. This extension also introduces a scountinhibit CSR which allows to stop/start any counter directly from the S-mode. As the counter delegation extension potentially can have more than 100 CSRs, the specificaiton leverages the indirect CSR extension to save the precious CSR address range. Due to the dependancy of these extensions, the following extensions must be enabled to use the counter delegation feature in S-mode. "smstateen=true,sscofpmf=true,ssccfg=true,smcdeleg=true,smcsrind=true,sscsrind=true" This makes the qemu command line quite tedious. In stead of that, I think we can enable these features by default if there is no objection. The first 2 patches decouple the indirect CSR usage from AIA implementation while patch3 adds stateen bits validation for AIA. The PATCH4 implements indirect CSR extensions while remaining patches implement the counter delegation extensions. The Qemu patches can be found here: https://github.com/atishp04/qemu/tree/counter_delegation_rfc The opensbi patch can be found here: https://github.com/atishp04/opensbi/tree/counter_delegation_v1 The Linux kernel patches can be found here: https://github.com/atishp04/linux/tree/counter_delegation_rfc [1] https://github.com/riscv/riscv-indirect-csr-access [2] https://github.com/riscv/riscv-smcdeleg-ssccfg Atish Patra (1): target/riscv: Enable S*stateen bits for AIA Kaiwen Xue (7): target/riscv: Add properties for Indirect CSR Access extension target/riscv: Decouple AIA processing from xiselect and xireg target/riscv: Support generic CSR indirect access target/riscv: Add smcdeleg/ssccfg properties target/riscv: Add counter delegation definitions target/riscv: Add select value range check for counter delegation target/riscv: Add counter delegation/configuration support target/riscv/cpu.c | 8 + target/riscv/cpu.h | 1 + target/riscv/cpu_bits.h | 34 +- target/riscv/cpu_cfg.h | 4 + target/riscv/csr.c | 713 +--- target/riscv/machine.c | 1 + 6 files changed, 722 insertions(+), 39 deletions(-) -- 2.34.1
[PATCH 4/5] tests/lcitool: Install mingw-w64-tools for the Windows cross-builds
Beside g++ we also need the mingw-w64-tools for properly building the code in qga/vss-win32/ , so let's install that package now, too. Signed-off-by: Thomas Huth --- tests/lcitool/projects/qemu-win-installer.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/lcitool/projects/qemu-win-installer.yml b/tests/lcitool/projects/qemu-win-installer.yml index 86aa22297c..f3663ba030 100644 --- a/tests/lcitool/projects/qemu-win-installer.yml +++ b/tests/lcitool/projects/qemu-win-installer.yml @@ -2,3 +2,4 @@ --- packages: - g++ + - mingw-w64-tools -- 2.45.1
[PATCH 5/5] tests/docker/dockerfiles: Run lcitool-refresh to update Fedora and Alpine
Run "make lcitool-refresh" to update the dockerfiles with the recent changes to the lcitool. Signed-off-by: Thomas Huth --- tests/docker/dockerfiles/alpine.docker | 4 ++-- tests/docker/dockerfiles/fedora-win64-cross.docker | 6 -- tests/docker/dockerfiles/fedora.docker | 5 +++-- 3 files changed, 9 insertions(+), 6 deletions(-) diff --git a/tests/docker/dockerfiles/alpine.docker b/tests/docker/dockerfiles/alpine.docker index 554464f31e..b079a83fe2 100644 --- a/tests/docker/dockerfiles/alpine.docker +++ b/tests/docker/dockerfiles/alpine.docker @@ -1,10 +1,10 @@ # THIS FILE WAS AUTO-GENERATED # -# $ lcitool dockerfile --layers all alpine-318 qemu +# $ lcitool dockerfile --layers all alpine-319 qemu # # https://gitlab.com/libvirt/libvirt-ci -FROM docker.io/library/alpine:3.18 +FROM docker.io/library/alpine:3.19 RUN apk update && \ apk upgrade && \ diff --git a/tests/docker/dockerfiles/fedora-win64-cross.docker b/tests/docker/dockerfiles/fedora-win64-cross.docker index 0f78711876..007e1574bd 100644 --- a/tests/docker/dockerfiles/fedora-win64-cross.docker +++ b/tests/docker/dockerfiles/fedora-win64-cross.docker @@ -1,10 +1,10 @@ # THIS FILE WAS AUTO-GENERATED # -# $ lcitool dockerfile --layers all --cross-arch mingw64 fedora-38 qemu,qemu-win-installer +# $ lcitool dockerfile --layers all --cross-arch mingw64 fedora-40 qemu,qemu-win-installer # # https://gitlab.com/libvirt/libvirt-ci -FROM registry.fedoraproject.org/fedora:38 +FROM registry.fedoraproject.org/fedora:40 RUN dnf install -y nosync && \ printf '#!/bin/sh\n\ @@ -51,6 +51,7 @@ exec "$@"\n' > /usr/bin/nosync && \ python3-pip \ python3-sphinx \ python3-sphinx_rtd_theme \ + python3-zombie-imp \ sed \ socat \ sparse \ @@ -74,6 +75,7 @@ ENV NINJA "/usr/bin/ninja" ENV PYTHON "/usr/bin/python3" RUN nosync dnf install -y \ + mingw-w64-tools \ mingw32-nsis \ mingw64-SDL2 \ mingw64-SDL2_image \ diff --git a/tests/docker/dockerfiles/fedora.docker b/tests/docker/dockerfiles/fedora.docker index 098c894d10..44f239c088 100644 --- a/tests/docker/dockerfiles/fedora.docker +++ b/tests/docker/dockerfiles/fedora.docker @@ -1,10 +1,10 @@ # THIS FILE WAS AUTO-GENERATED # -# $ lcitool dockerfile --layers all fedora-38 qemu +# $ lcitool dockerfile --layers all fedora-40 qemu # # https://gitlab.com/libvirt/libvirt-ci -FROM registry.fedoraproject.org/fedora:38 +FROM registry.fedoraproject.org/fedora:40 RUN dnf install -y nosync && \ printf '#!/bin/sh\n\ @@ -110,6 +110,7 @@ exec "$@"\n' > /usr/bin/nosync && \ python3-pip \ python3-sphinx \ python3-sphinx_rtd_theme \ + python3-zombie-imp \ rdma-core-devel \ sed \ snappy-devel \ -- 2.45.1
[PATCH 0/5] tests: Update Fedora and Alpine containers via lcitool
According to QEMU's support policy, Fedora 38 and Alpine 3.18 are not supported anymore, so let's bump the containers to a newer version. Both, Alpine 3.20 and Fedora 40 ship with Python 3.12 that breaks our old version of Avocado since the "imp" module has been removed there. To work around this problem, Fedora fortunately still ships a separate "python3-zombi-imp" package that we can install. And with regards to Alpine, we only upgrade to 3.19 that is still using Python 3.11. Another problem are improvements in the undefined-behavior sanitizer of the latest versions of Clang that we use in the "clang-system" Fedora container: We now need to compile with -fno-sanitize=function there until all spots in the source code have been fixed (and that might take while since many of the issues are not trivial). Thomas Huth (5): tests/lcitool: Delete obsolete centos-stream-8.yml file tests/lcitool: Bump to latest libvirt-ci and update Fedora and Alpine version .gitlab-ci.d/buildtest.yml: Use -fno-sanitize=function in the clang-system job tests/lcitool: Install mingw-w64-tools for the Windows cross-builds tests/docker/dockerfiles: Run lcitool-refresh to update Fedora and Alpine .gitlab-ci.d/buildtest.yml | 1 + tests/docker/dockerfiles/alpine.docker | 4 ++-- tests/docker/dockerfiles/fedora-win64-cross.docker | 6 -- tests/docker/dockerfiles/fedora.docker | 5 +++-- tests/lcitool/libvirt-ci | 2 +- tests/lcitool/projects/qemu-win-installer.yml | 1 + tests/lcitool/projects/qemu.yml| 1 + tests/lcitool/refresh | 6 +++--- tests/lcitool/targets/centos-stream-8.yml | 3 --- 9 files changed, 16 insertions(+), 13 deletions(-) delete mode 100644 tests/lcitool/targets/centos-stream-8.yml -- 2.45.1
[PATCH 2/5] tests/lcitool: Bump to latest libvirt-ci and update Fedora and Alpine version
Update to the latest version of lcitool. It dropped support for Fedora 38
and Alpine 3.18, so we have to update these to newer versions here, too.
Python 3.12 dropped the "imp" module which we still need for running
Avocado. Fortunately Fedora 40 still ships with a work-around package
that we can use until somebody updates our Avocado to a newer version.
Signed-off-by: Thomas Huth
---
tests/lcitool/libvirt-ci| 2 +-
tests/lcitool/projects/qemu.yml | 1 +
tests/lcitool/refresh | 6 +++---
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/tests/lcitool/libvirt-ci b/tests/lcitool/libvirt-ci
index cec6703971..0e9490cebc 16
--- a/tests/lcitool/libvirt-ci
+++ b/tests/lcitool/libvirt-ci
@@ -1 +1 @@
-Subproject commit cec67039719becbfbab866f9c23574f389cf9559
+Subproject commit 0e9490cebc726ef772b6c9e27dac32e7ae99f9b2
diff --git a/tests/lcitool/projects/qemu.yml b/tests/lcitool/projects/qemu.yml
index 7511ec7ccb..070d7f4706 100644
--- a/tests/lcitool/projects/qemu.yml
+++ b/tests/lcitool/projects/qemu.yml
@@ -89,6 +89,7 @@ packages:
- pkg-config
- pulseaudio
- python3
+ - python3-imp
- python3-numpy
- python3-opencv
- python3-pillow
diff --git a/tests/lcitool/refresh b/tests/lcitool/refresh
index 789acefb75..9d8e9c6a4a 100755
--- a/tests/lcitool/refresh
+++ b/tests/lcitool/refresh
@@ -124,11 +124,11 @@ try:
#
# Standard native builds
#
-generate_dockerfile("alpine", "alpine-318")
+generate_dockerfile("alpine", "alpine-319")
generate_dockerfile("centos9", "centos-stream-9")
generate_dockerfile("debian", "debian-12",
trailer="".join(debian12_extras))
-generate_dockerfile("fedora", "fedora-38")
+generate_dockerfile("fedora", "fedora-40")
generate_dockerfile("opensuse-leap", "opensuse-leap-15")
generate_dockerfile("ubuntu2204", "ubuntu-2204")
@@ -191,7 +191,7 @@ try:
trailer=cross_build("s390x-linux-gnu-",
"s390x-softmmu,s390x-linux-user"))
-generate_dockerfile("fedora-win64-cross", "fedora-38",
+generate_dockerfile("fedora-win64-cross", "fedora-40",
project='qemu,qemu-win-installer',
cross="mingw64",
trailer=cross_build("x86_64-w64-mingw32-",
--
2.45.1
[PATCH 1/5] tests/lcitool: Delete obsolete centos-stream-8.yml file
We've missed to delete this file when removing support for CentOS 8. Since the current upstream version of the lcitool removed support for CentOS 8 now, too, we have to remove the file before updating. Signed-off-by: Thomas Huth --- tests/lcitool/targets/centos-stream-8.yml | 3 --- 1 file changed, 3 deletions(-) delete mode 100644 tests/lcitool/targets/centos-stream-8.yml diff --git a/tests/lcitool/targets/centos-stream-8.yml b/tests/lcitool/targets/centos-stream-8.yml deleted file mode 100644 index 6b11160fd1..00 --- a/tests/lcitool/targets/centos-stream-8.yml +++ /dev/null @@ -1,3 +0,0 @@ -paths: - pip3: /usr/bin/pip3.8 - python: /usr/bin/python3.8 -- 2.45.1
[PATCH 3/5] .gitlab-ci.d/buildtest.yml: Use -fno-sanitize=function in the clang-system job
The latest version of Clang (version 18 from Fedora 40) now reports bad function pointer casts as undefined behavior. Unfortunately, we are still doing this in quite a lot of places in the QEMU code and some of them are not easy to fix. So for the time being, temporarily switch this off in the failing clang-system job until all spots in the QEMU sources have been tackled. Signed-off-by: Thomas Huth --- .gitlab-ci.d/buildtest.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitlab-ci.d/buildtest.yml b/.gitlab-ci.d/buildtest.yml index 91c57efded..0eec570310 100644 --- a/.gitlab-ci.d/buildtest.yml +++ b/.gitlab-ci.d/buildtest.yml @@ -432,6 +432,7 @@ clang-system: IMAGE: fedora CONFIGURE_ARGS: --cc=clang --cxx=clang++ --extra-cflags=-fsanitize=undefined --extra-cflags=-fno-sanitize-recover=undefined + --extra-cflags=-fno-sanitize=function TARGETS: alpha-softmmu arm-softmmu m68k-softmmu mips64-softmmu s390x-softmmu MAKE_CHECK_ARGS: check-qtest check-tcg -- 2.45.1
