Re: [PATCH v2 1/7] vhost-user: strip superfluous whitespace
On 8/30/23 15:40, Laszlo Ersek wrote: > Cc: "Michael S. Tsirkin" (supporter:vhost) > Cc: Eugenio Perez Martin > Cc: German Maglione > Cc: Liu Jiang > Cc: Sergio Lopez Pascual > Cc: Stefano Garzarella > Signed-off-by: Laszlo Ersek > Reviewed-by: Stefano Garzarella > --- > > Notes: > v2: > > - pick up Stefano's R-b > > hw/virtio/vhost-user.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) This has been Reviewed-by: Philippe Mathieu-Daudé under the (identical) v1 posting: cd0604a1-6826-ac6c-6c47-dcb6def64b28@linaro.org">http://mid.mail-archive.com/cd0604a1-6826-ac6c-6c47-dcb6def64b28@linaro.org Thanks, Phil! (and sorry that I posted v2 too quickly -- I forgot that sometimes reviewers split a review over multiple days.) Laszlo > > diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c > index 8dcf049d422b..b4b677c1ce66 100644 > --- a/hw/virtio/vhost-user.c > +++ b/hw/virtio/vhost-user.c > @@ -398,7 +398,7 @@ static int vhost_user_write(struct vhost_dev *dev, > VhostUserMsg *msg, > * operations such as configuring device memory mappings or issuing > device > * resets, which affect the whole device instead of individual VQs, > * vhost-user messages should only be sent once. > - * > + * > * Devices with multiple vhost_devs are given an associated dev->vq_index > * so per_device requests are only sent if vq_index is 0. > */ >
Re: [PATCH v2 2/7] vhost-user: tighten "reply_supported" scope in "set_vring_addr"
On 8/30/23 15:40, Laszlo Ersek wrote:
> In the vhost_user_set_vring_addr() function, we calculate
> "reply_supported" unconditionally, even though we'll only need it if
> "wait_for_reply" is also true.
>
> Restrict the scope of "reply_supported" to the minimum.
>
> This is purely refactoring -- no observable change.
>
> Cc: "Michael S. Tsirkin" (supporter:vhost)
> Cc: Eugenio Perez Martin
> Cc: German Maglione
> Cc: Liu Jiang
> Cc: Sergio Lopez Pascual
> Cc: Stefano Garzarella
> Signed-off-by: Laszlo Ersek
> Reviewed-by: Stefano Garzarella
> ---
>
> Notes:
> v2:
>
> - pick up Stefano's R-b
>
> hw/virtio/vhost-user.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
identical to v1, so:
Reviewed-by: Philippe Mathieu-Daudé
from
<6c12069e-da31-9758-4972-7121ab5ffdee@linaro.org">http://mid.mail-archive.com/6c12069e-da31-9758-4972-7121ab5ffdee@linaro.org>.
Laszlo
>
> diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
> index b4b677c1ce66..64eac317bfb2 100644
> --- a/hw/virtio/vhost-user.c
> +++ b/hw/virtio/vhost-user.c
> @@ -1331,17 +1331,18 @@ static int vhost_user_set_vring_addr(struct vhost_dev
> *dev,
> .hdr.size = sizeof(msg.payload.addr),
> };
>
> -bool reply_supported = virtio_has_feature(dev->protocol_features,
> -
> VHOST_USER_PROTOCOL_F_REPLY_ACK);
> -
> /*
> * wait for a reply if logging is enabled to make sure
> * backend is actually logging changes
> */
> bool wait_for_reply = addr->flags & (1 << VHOST_VRING_F_LOG);
>
> -if (reply_supported && wait_for_reply) {
> -msg.hdr.flags |= VHOST_USER_NEED_REPLY_MASK;
> +if (wait_for_reply) {
> +bool reply_supported = virtio_has_feature(dev->protocol_features,
> + VHOST_USER_PROTOCOL_F_REPLY_ACK);
> +if (reply_supported) {
> +msg.hdr.flags |= VHOST_USER_NEED_REPLY_MASK;
> +}
> }
>
> ret = vhost_user_write(dev, &msg, NULL, 0);
>
Re: [PATCH v4 11/48] target/loongarch: Implement xvhaddw/xvhsubw
在 2023/8/31 上午2:12, Richard Henderson 写道: On 8/30/23 01:48, Song Gao wrote: --- a/target/loongarch/vec.h +++ b/target/loongarch/vec.h @@ -47,4 +47,7 @@ #define Q(x) Q[x] #endif /* HOST_BIG_ENDIAN */ +#define DO_ADD(a, b) (a + b) +#define DO_SUB(a, b) (a - b) + Why are these moved? I want to move simple macros together. Thanks. Song Gao
Re: [PATCH v4 06/48] target/loongarch: Implement xvreplgr2vr
在 2023/8/31 上午12:09, Richard Henderson 写道:
On 8/30/23 01:48, Song Gao wrote:
This patch includes:
- XVREPLGR2VR.{B/H/W/D}.
Signed-off-by: Song Gao
Reviewed-by: Richard Henderson
---
target/loongarch/insns.decode | 5 +
target/loongarch/disas.c | 10 ++
target/loongarch/insn_trans/trans_lasx.c.inc | 5 +
target/loongarch/insn_trans/trans_lsx.c.inc | 12 ++--
4 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/target/loongarch/insns.decode
b/target/loongarch/insns.decode
index bcc18fb6c5..04bd238995 100644
--- a/target/loongarch/insns.decode
+++ b/target/loongarch/insns.decode
@@ -1310,3 +1310,8 @@ xvsub_h 0111 0100 11001 . .
. @vvv
xvsub_w 0111 0100 11010 . . . @vvv
xvsub_d 0111 0100 11011 . . . @vvv
xvsub_q 0111 01010010 11011 . . . @vvv
+
+xvreplgr2vr_b 0111 01101001 0 0 . . @vr
+xvreplgr2vr_h 0111 01101001 0 1 . . @vr
+xvreplgr2vr_w 0111 01101001 0 00010 . . @vr
+xvreplgr2vr_d 0111 01101001 0 00011 . . @vr
diff --git a/target/loongarch/disas.c b/target/loongarch/disas.c
index d8b62ba532..c47f455ed0 100644
--- a/target/loongarch/disas.c
+++ b/target/loongarch/disas.c
@@ -1708,6 +1708,11 @@ static void output_vvv_x(DisasContext *ctx,
arg_vvv * a, const char *mnemonic)
output(ctx, mnemonic, "x%d, x%d, x%d", a->vd, a->vj, a->vk);
}
+static void output_vr_x(DisasContext *ctx, arg_vr *a, const char
*mnemonic)
+{
+ output(ctx, mnemonic, "x%d, r%d", a->vd, a->rj);
+}
+
INSN_LASX(xvadd_b, vvv)
INSN_LASX(xvadd_h, vvv)
INSN_LASX(xvadd_w, vvv)
@@ -1718,3 +1723,8 @@ INSN_LASX(xvsub_h, vvv)
INSN_LASX(xvsub_w, vvv)
INSN_LASX(xvsub_d, vvv)
INSN_LASX(xvsub_q, vvv)
+
+INSN_LASX(xvreplgr2vr_b, vr)
+INSN_LASX(xvreplgr2vr_h, vr)
+INSN_LASX(xvreplgr2vr_w, vr)
+INSN_LASX(xvreplgr2vr_d, vr)
diff --git a/target/loongarch/insn_trans/trans_lasx.c.inc
b/target/loongarch/insn_trans/trans_lasx.c.inc
index 218b8dc648..66b5abc790 100644
--- a/target/loongarch/insn_trans/trans_lasx.c.inc
+++ b/target/loongarch/insn_trans/trans_lasx.c.inc
@@ -50,3 +50,8 @@ TRANS(xvsub_b, LASX, gvec_vvv, 32, MO_8,
tcg_gen_gvec_sub)
TRANS(xvsub_h, LASX, gvec_vvv, 32, MO_16, tcg_gen_gvec_sub)
TRANS(xvsub_w, LASX, gvec_vvv, 32, MO_32, tcg_gen_gvec_sub)
TRANS(xvsub_d, LASX, gvec_vvv, 32, MO_64, tcg_gen_gvec_sub)
+
+TRANS(xvreplgr2vr_b, LASX, gvec_dup, 32, MO_8)
+TRANS(xvreplgr2vr_h, LASX, gvec_dup, 32, MO_16)
+TRANS(xvreplgr2vr_w, LASX, gvec_dup, 32, MO_32)
+TRANS(xvreplgr2vr_d, LASX, gvec_dup, 32, MO_64)
diff --git a/target/loongarch/insn_trans/trans_lsx.c.inc
b/target/loongarch/insn_trans/trans_lsx.c.inc
index 0e12213e8b..c0e7a9a372 100644
--- a/target/loongarch/insn_trans/trans_lsx.c.inc
+++ b/target/loongarch/insn_trans/trans_lsx.c.inc
@@ -4161,7 +4161,7 @@ static bool trans_vpickve2gr_du(DisasContext
*ctx, arg_rv_i *a)
return true;
}
-static bool gvec_dup(DisasContext *ctx, arg_vr *a, MemOp mop)
+static bool gvec_dup(DisasContext *ctx, arg_vr *a, uint32_t oprsz,
MemOp mop)
{
TCGv src = gpr_src(ctx, a->rj, EXT_NONE);
@@ -4172,14 +4172,14 @@ static bool gvec_dup(DisasContext *ctx, arg_vr
*a, MemOp mop)
CHECK_VEC;
tcg_gen_gvec_dup_i64(mop, vec_full_offset(a->vd),
- 16, ctx->vl/8, src);
+ oprsz, ctx->vl / 8, src);
return true;
}
-TRANS(vreplgr2vr_b, LSX, gvec_dup, MO_8)
-TRANS(vreplgr2vr_h, LSX, gvec_dup, MO_16)
-TRANS(vreplgr2vr_w, LSX, gvec_dup, MO_32)
-TRANS(vreplgr2vr_d, LSX, gvec_dup, MO_64)
+TRANS(vreplgr2vr_b, LSX, gvec_dup, 16, MO_8)
+TRANS(vreplgr2vr_h, LSX, gvec_dup, 16, MO_16)
+TRANS(vreplgr2vr_w, LSX, gvec_dup, 16, MO_32)
+TRANS(vreplgr2vr_d, LSX, gvec_dup, 16, MO_64)
Hmm.
Ok, so revising the advice I gave versus the previous patch, I can see
how having a common CHECK_VEC is helpful. But it still needs to use
oprsz not vl for the size check.
It would be better to replace with a function, like
if (!check_vec(ctx, oprsz)) {
return true;
}
rather than a macro with a hidden return. The replacement should be
done in a patch by itself, probably using check_vec(ctx, 16) for all of
the existing LSX code until, step by step, oprsz is plumbed into all of
the places required.
I still think having separate minimal gen_vvv and gen_xxx helpers will
help reduce the possibility of typos, when there are a lot of
instructions within an instruction format. But when there are just 8,
like here, just adding oprsz certainly looks simpler.
Thanks for you suggestions. I will correct them on v5.
I wonder if it is really clearer having the LASX instructions in a
separate file? Perhaps it be better to keep all of the similar patterns
toget
Re: [PATCH v4 10/48] target/loongarch: rename lsx_helper.c to vec_helper.c
在 2023/8/31 上午2:06, Richard Henderson 写道:
On 8/30/23 01:48, Song Gao wrote:
Use gen_helper_gvec_* series function.
and rename lsx_helper.c to vec_helper.c.
Signed-off-by: Song Gao
---
target/loongarch/helper.h | 642
.../loongarch/{lsx_helper.c => vec_helper.c} | 1297 -
These changes are fine, but should be split.
The helper changes can be done with only minimal changes
target/loongarch/insn_trans/trans_lsx.c.inc | 731 +-
here, rather than to 700+ lines at once.
OK, It seems that need more patches do this.
-static bool gen_(DisasContext *ctx, arg_ *a,
- void (*func)(TCGv_ptr, TCGv_i32, TCGv_i32,
- TCGv_i32, TCGv_i32))
+static bool gen_(DisasContext *ctx, arg_ *a, int oprsz,
+ gen_helper_gvec_4 *fn)
If you omit the oprsz argument within this patch,
+ tcg_gen_gvec_4_ool(vec_full_offset(a->vd),
+ vec_full_offset(a->vj),
+ vec_full_offset(a->vk),
+ vec_full_offset(a->va),
+ oprsz, ctx->vl / 8, oprsz, fn);
hard-coding 16 here instead,
-TRANS(vhaddw_h_b, LSX, gen_vvv, gen_helper_vhaddw_h_b)
+TRANS(vhaddw_h_b, LSX, gen_vvv, 16, gen_helper_vhaddw_h_b)
then you do not need all of these changes.
At which point I'll refer you back to my comments vs patches 5 and 6,
wherein separate gen_vvv and gen_xxx helpers would avoid the need to
replicate 16 across all of these lines.
Got it
Thanks.
Song Gao
Re: [PATCH v2 5/7] vhost-user: hoist "write_sync", "get_features", "get_u64"
On 8/30/23 15:40, Laszlo Ersek wrote:
> In order to avoid a forward-declaration for "vhost_user_write_sync" in a
> subsequent patch, hoist "vhost_user_write_sync" ->
> "vhost_user_get_features" -> "vhost_user_get_u64" just above
> "vhost_set_vring".
>
> This is purely code movement -- no observable change.
>
> Cc: "Michael S. Tsirkin" (supporter:vhost)
> Cc: Eugenio Perez Martin
> Cc: German Maglione
> Cc: Liu Jiang
> Cc: Sergio Lopez Pascual
> Cc: Stefano Garzarella
> Signed-off-by: Laszlo Ersek
> Reviewed-by: Stefano Garzarella
> ---
>
> Notes:
> v2:
>
> - pick up R-b from Stefano
>
> - rename "vhost_user_write_msg" to "vhost_user_write_sync" (in code and
> commit message) [Stefano]
>
> hw/virtio/vhost-user.c | 170 ++--
> 1 file changed, 85 insertions(+), 85 deletions(-)
Phil reviewed v1:
98150923-39ef-7581-6144-8d0ad8d4dd52@linaro.org">http://mid.mail-archive.com/98150923-39ef-7581-6144-8d0ad8d4dd52@linaro.org
and I would've kept his R-b (similar to Stefano's) across the
vhost_user_write_msg->vhost_user_write_sync rename in v2; so I'm copying
it here:
Reviewed-by: Philippe Mathieu-Daudé
Hope that's OK.
Laszlo
>
> diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
> index 4129ba72e408..c79b6f77cdca 100644
> --- a/hw/virtio/vhost-user.c
> +++ b/hw/virtio/vhost-user.c
> @@ -1083,6 +1083,91 @@ static int vhost_user_set_vring_endian(struct
> vhost_dev *dev,
> return vhost_user_write(dev, &msg, NULL, 0);
> }
>
> +static int vhost_user_get_u64(struct vhost_dev *dev, int request, uint64_t
> *u64)
> +{
> +int ret;
> +VhostUserMsg msg = {
> +.hdr.request = request,
> +.hdr.flags = VHOST_USER_VERSION,
> +};
> +
> +if (vhost_user_per_device_request(request) && dev->vq_index != 0) {
> +return 0;
> +}
> +
> +ret = vhost_user_write(dev, &msg, NULL, 0);
> +if (ret < 0) {
> +return ret;
> +}
> +
> +ret = vhost_user_read(dev, &msg);
> +if (ret < 0) {
> +return ret;
> +}
> +
> +if (msg.hdr.request != request) {
> +error_report("Received unexpected msg type. Expected %d received %d",
> + request, msg.hdr.request);
> +return -EPROTO;
> +}
> +
> +if (msg.hdr.size != sizeof(msg.payload.u64)) {
> +error_report("Received bad msg size.");
> +return -EPROTO;
> +}
> +
> +*u64 = msg.payload.u64;
> +
> +return 0;
> +}
> +
> +static int vhost_user_get_features(struct vhost_dev *dev, uint64_t *features)
> +{
> +if (vhost_user_get_u64(dev, VHOST_USER_GET_FEATURES, features) < 0) {
> +return -EPROTO;
> +}
> +
> +return 0;
> +}
> +
> +/* Note: "msg->hdr.flags" may be modified. */
> +static int vhost_user_write_sync(struct vhost_dev *dev, VhostUserMsg *msg,
> + bool wait_for_reply)
> +{
> +int ret;
> +
> +if (wait_for_reply) {
> +bool reply_supported = virtio_has_feature(dev->protocol_features,
> + VHOST_USER_PROTOCOL_F_REPLY_ACK);
> +if (reply_supported) {
> +msg->hdr.flags |= VHOST_USER_NEED_REPLY_MASK;
> +}
> +}
> +
> +ret = vhost_user_write(dev, msg, NULL, 0);
> +if (ret < 0) {
> +return ret;
> +}
> +
> +if (wait_for_reply) {
> +uint64_t dummy;
> +
> +if (msg->hdr.flags & VHOST_USER_NEED_REPLY_MASK) {
> +return process_message_reply(dev, msg);
> +}
> +
> + /*
> +* We need to wait for a reply but the backend does not
> +* support replies for the command we just sent.
> +* Send VHOST_USER_GET_FEATURES which makes all backends
> +* send a reply.
> +*/
> +return vhost_user_get_features(dev, &dummy);
> +}
> +
> +return 0;
> +}
> +
> static int vhost_set_vring(struct vhost_dev *dev,
> unsigned long int request,
> struct vhost_vring_state *ring)
> @@ -1255,91 +1340,6 @@ static int vhost_user_set_vring_err(struct vhost_dev
> *dev,
> return vhost_set_vring_file(dev, VHOST_USER_SET_VRING_ERR, file);
> }
>
> -static int vhost_user_get_u64(struct vhost_dev *dev, int request, uint64_t
> *u64)
> -{
> -int ret;
> -VhostUserMsg msg = {
> -.hdr.request = request,
> -.hdr.flags = VHOST_USER_VERSION,
> -};
> -
> -if (vhost_user_per_device_request(request) && dev->vq_index != 0) {
> -return 0;
> -}
> -
> -ret = vhost_user_write(dev, &msg, NULL, 0);
> -if (ret < 0) {
> -return ret;
> -}
> -
> -ret = vhost_user_read(dev, &msg);
> -if (ret < 0) {
> -return ret;
> -}
> -
> -if (msg.hdr.request != request) {
> -error_report("Received unexpected msg type. Expected %d received %d",
> - request, msg.hdr.request);
> -return -EPROTO;
> -}
> -
> -if (msg.hdr.size != siz
qemu-system-ppc failures with glibc 2.38
Hi, Yocto Project's CI is noticing a lot of issues with qemu-system-ppc emulation on loaded systems after we switch glibc to 2.38. This is manifesting as hangs in the emulated system and for example, systemd units then timeout and restart. If we have long running commands running over ssh (e.g. configure or kernel module builds), these are then are then disconnected. It does appear the system does 'freeze' periodically. It also seems related to the load on the system running the emulation. On an otherwise idle system it is fine, when there is other load, we hit the freezes, watchdog resets and resulting faiilures. We do sometimes see kernel rcu stalls too, the frequency of them may be higher with the new glibc, it is hard to tell. Can anyone think of something that changed in glibc 2.38 which might affect qemu-system-ppc in this way? Everything else we test seems ok. I've tested with qemu 8.0.0, 8.0.3, 8.0.4 and 8.1.0 with similar results. The latter has other problems unfortunately which we're still trying to debug (x86 hangs, we then tried the "softmmu: Assert data in bounds in iotlb_to_section" patches but that breaks mips). Cheers, Richard
Re: About "PC_MACHINE_CLASS" definition.
Thanks a lot. On Thu, Aug 31, 2023 at 2:11 PM Philippe Mathieu-Daudé wrote: > Hi, > > On 31/8/23 05:15, Liu Jaloo wrote: > > Where actually defined the "PC_MACHINE_CLASS", I can't find it in source > > code, please help to point out the file. > > It is defined in include/hw/i386/pc.h: > > OBJECT_DECLARE_TYPE(PCMachineState, PCMachineClass, PC_MACHINE) > > The macro itself is defined in include/qom/object.h: > > /** > * OBJECT_DECLARE_TYPE: > * @InstanceType: instance struct name > * @ClassType: class struct name > * @MODULE_OBJ_NAME: the object name in uppercase with underscore > separators > * > * This macro is typically used in a header file, and will: > * > * - create the typedefs for the object and class structs > * - register the type for use with g_autoptr > * - provide three standard type cast functions > * > * The object struct and class struct need to be declared manually. > */ > > See the QOM documentation: > > https://qemu-project.gitlab.io/qemu/devel/qom.html > > Regards, > > Phil. >
Re: [PATCH 1/4] ppc/xive: Use address_space routines to access the machine RAM
On 29/08/2023 16:32, Cédric Le Goater wrote:
to log an error in case of bad configuration of the XIVE tables by the FW.
Signed-off-by: Cédric Le Goater
---
hw/intc/pnv_xive.c | 27 +++
hw/intc/pnv_xive2.c | 27 +++
2 files changed, 46 insertions(+), 8 deletions(-)
diff --git a/hw/intc/pnv_xive.c b/hw/intc/pnv_xive.c
index e536b3ec26e5..b2bafd61b157 100644
--- a/hw/intc/pnv_xive.c
+++ b/hw/intc/pnv_xive.c
@@ -242,12 +242,20 @@ static int pnv_xive_vst_read(PnvXive *xive, uint32_t
type, uint8_t blk,
{
const XiveVstInfo *info = &vst_infos[type];
uint64_t addr = pnv_xive_vst_addr(xive, type, blk, idx);
+MemTxResult result;
if (!addr) {
return -1;
}
-cpu_physical_memory_read(addr, data, info->size);
+result = address_space_read(&address_space_memory, addr,
+MEMTXATTRS_UNSPECIFIED, data,
+info->size);
I had been wondering which is the "right" API to update the guest
memory. Since the cpu_physical_memory_* family ends up calling its
address_space_* equivalent, I'm guessing the point of the change is
really to catch any error and remove any potential ambiguity about the
address space?
In any case,
Reviewed-by: Frederic Barrat
Fred
+if (result != MEMTX_OK) {
+xive_error(xive, "VST: read failed at @0x%" HWADDR_PRIx
+ " for VST %s %x/%x\n", addr, info->name, blk, idx);
+return -1;
+}
return 0;
}
@@ -258,16 +266,27 @@ static int pnv_xive_vst_write(PnvXive *xive, uint32_t type, uint8_t blk,
{
const XiveVstInfo *info = &vst_infos[type];
uint64_t addr = pnv_xive_vst_addr(xive, type, blk, idx);
+MemTxResult result;
if (!addr) {
return -1;
}
if (word_number == XIVE_VST_WORD_ALL) {
-cpu_physical_memory_write(addr, data, info->size);
+result = address_space_write(&address_space_memory, addr,
+ MEMTXATTRS_UNSPECIFIED, data,
+ info->size);
} else {
-cpu_physical_memory_write(addr + word_number * 4,
- data + word_number * 4, 4);
+result = address_space_write(&address_space_memory,
+ addr + word_number * 4,
+ MEMTXATTRS_UNSPECIFIED,
+ data + word_number * 4, 4);
+}
+
+if (result != MEMTX_OK) {
+xive_error(xive, "VST: write failed at @0x%" HWADDR_PRIx
+"for VST %s %x/%x\n", addr, info->name, blk, idx);
+return -1;
}
return 0;
}
diff --git a/hw/intc/pnv_xive2.c b/hw/intc/pnv_xive2.c
index bbb44a533cff..4b8d0a5d8120 100644
--- a/hw/intc/pnv_xive2.c
+++ b/hw/intc/pnv_xive2.c
@@ -240,12 +240,20 @@ static int pnv_xive2_vst_read(PnvXive2 *xive, uint32_t
type, uint8_t blk,
{
const XiveVstInfo *info = &vst_infos[type];
uint64_t addr = pnv_xive2_vst_addr(xive, type, blk, idx);
+MemTxResult result;
if (!addr) {
return -1;
}
-cpu_physical_memory_read(addr, data, info->size);
+result = address_space_read(&address_space_memory, addr,
+MEMTXATTRS_UNSPECIFIED, data,
+info->size);
+if (result != MEMTX_OK) {
+xive2_error(xive, "VST: read failed at @0x%" HWADDR_PRIx
+ " for VST %s %x/%x\n", addr, info->name, blk, idx);
+return -1;
+}
return 0;
}
@@ -256,16 +264,27 @@ static int pnv_xive2_vst_write(PnvXive2 *xive, uint32_t type, uint8_t blk,
{
const XiveVstInfo *info = &vst_infos[type];
uint64_t addr = pnv_xive2_vst_addr(xive, type, blk, idx);
+MemTxResult result;
if (!addr) {
return -1;
}
if (word_number == XIVE_VST_WORD_ALL) {
-cpu_physical_memory_write(addr, data, info->size);
+result = address_space_write(&address_space_memory, addr,
+ MEMTXATTRS_UNSPECIFIED, data,
+ info->size);
} else {
-cpu_physical_memory_write(addr + word_number * 4,
- data + word_number * 4, 4);
+result = address_space_write(&address_space_memory,
+ addr + word_number * 4,
+ MEMTXATTRS_UNSPECIFIED,
+ data + word_number * 4, 4);
+}
+
+if (result != MEMTX_OK) {
+xive2_error(xive, "VST: write failed at @0x%" HWADDR_PRIx
+ "for VST %s %x/%x\n", addr, info->name, blk, idx);
+return -1;
}
return 0;
}
Re: [PATCH 2/4] ppc/xive: Introduce a new XiveRouter end_notify() handler
On 29/08/2023 16:32, Cédric Le Goater wrote:
It will help us model the END triggers on the PowerNV machine, which
can be rerouted to another interrupt controller.
Signed-off-by: Cédric Le Goater
---
diff --git a/hw/intc/xive.c b/hw/intc/xive.c
index 56670b2cac6e..df3ee0496fe7 100644
--- a/hw/intc/xive.c
+++ b/hw/intc/xive.c
@@ -1518,6 +1518,13 @@ static void xive_router_realize(DeviceState *dev, Error
**errp)
assert(xrtr->xfb);
}
+static void xive_router_end_notify_handler(XiveRouter *xrtr, XiveEAS *eas)
+{
+XiveRouterClass *xrc = XIVE_ROUTER_GET_CLASS(xrtr);
+
+return xrc->end_notify(xrtr, eas);
+}
+
/*
* Encode the HW CAM line in the block group mode format :
*
@@ -1664,8 +1671,7 @@ static bool xive_router_end_es_notify(XiveRouter *xrtr,
uint8_t end_blk,
* another chip. We don't model the PowerBus but the END trigger
* message has the same parameters than in the function below.
*/
-static void xive_router_end_notify(XiveRouter *xrtr, uint8_t end_blk,
- uint32_t end_idx, uint32_t end_data)
+void xive_router_end_notify(XiveRouter *xrtr, XiveEAS *eas)
{
XiveEND end;
uint8_t priority;
@@ -1675,6 +1681,10 @@ static void xive_router_end_notify(XiveRouter *xrtr,
uint8_t end_blk,
XiveNVT nvt;
bool found;
+uint8_t end_blk = xive_get_field64(EAS_END_BLOCK, eas->w);
+uint32_t end_idx = xive_get_field64(EAS_END_INDEX, eas->w);
+uint32_t end_data = xive_get_field64(EAS_END_DATA, eas->w);
+
/* END cache lookup */
if (xive_router_get_end(xrtr, end_blk, end_idx, &end)) {
qemu_log_mask(LOG_GUEST_ERROR, "XIVE: No END %x/%x\n", end_blk,
@@ -1817,10 +1827,7 @@ do_escalation:
/*
* The END trigger becomes an Escalation trigger
*/
-xive_router_end_notify(xrtr,
- xive_get_field32(END_W4_ESC_END_BLOCK, end.w4),
- xive_get_field32(END_W4_ESC_END_INDEX, end.w4),
- xive_get_field32(END_W5_ESC_END_DATA, end.w5));
+xive_router_end_notify_handler(xrtr, (XiveEAS *) &end.w4);
I didn't like the cast, but I can see why you're doing it this way. We
should be fine as long as the notify handler is not testing the validity
bit of the EAS structure.
Reviewed-by: Frederic Barrat
Fred
}
void xive_router_notify(XiveNotifier *xn, uint32_t lisn, bool pq_checked)
@@ -1871,10 +1878,7 @@ void xive_router_notify(XiveNotifier *xn, uint32_t lisn,
bool pq_checked)
/*
* The event trigger becomes an END trigger
*/
-xive_router_end_notify(xrtr,
- xive_get_field64(EAS_END_BLOCK, eas.w),
- xive_get_field64(EAS_END_INDEX, eas.w),
- xive_get_field64(EAS_END_DATA, eas.w));
+xive_router_end_notify_handler(xrtr, &eas);
}
static Property xive_router_properties[] = {
@@ -1887,12 +1891,16 @@ static void xive_router_class_init(ObjectClass *klass,
void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
XiveNotifierClass *xnc = XIVE_NOTIFIER_CLASS(klass);
+XiveRouterClass *xrc = XIVE_ROUTER_CLASS(klass);
dc->desc= "XIVE Router Engine";
device_class_set_props(dc, xive_router_properties);
/* Parent is SysBusDeviceClass. No need to call its realize hook */
dc->realize = xive_router_realize;
xnc->notify = xive_router_notify;
+
+/* By default, the router handles END triggers locally */
+xrc->end_notify = xive_router_end_notify;
}
static const TypeInfo xive_router_info = {
Re: [PATCH 1/4] ppc/xive: Use address_space routines to access the machine RAM
On 8/31/23 09:44, Frederic Barrat wrote:
On 29/08/2023 16:32, Cédric Le Goater wrote:
to log an error in case of bad configuration of the XIVE tables by the FW.
Signed-off-by: Cédric Le Goater
---
hw/intc/pnv_xive.c | 27 +++
hw/intc/pnv_xive2.c | 27 +++
2 files changed, 46 insertions(+), 8 deletions(-)
diff --git a/hw/intc/pnv_xive.c b/hw/intc/pnv_xive.c
index e536b3ec26e5..b2bafd61b157 100644
--- a/hw/intc/pnv_xive.c
+++ b/hw/intc/pnv_xive.c
@@ -242,12 +242,20 @@ static int pnv_xive_vst_read(PnvXive *xive, uint32_t
type, uint8_t blk,
{
const XiveVstInfo *info = &vst_infos[type];
uint64_t addr = pnv_xive_vst_addr(xive, type, blk, idx);
+ MemTxResult result;
if (!addr) {
return -1;
}
- cpu_physical_memory_read(addr, data, info->size);
+ result = address_space_read(&address_space_memory, addr,
+ MEMTXATTRS_UNSPECIFIED, data,
+ info->size);
I had been wondering which is the "right" API to update the guest memory. Since the cpu_physical_memory_* family ends up calling its address_space_* equivalent, I'm guessing the point of the change is really to catch any error
yes.
and remove any potential ambiguity about the address space?
yes. See LPC and XSCOM for other address spaces in the PowerNV domain. Also,
the XIVE EDT but that's more a modeling trick.
In this case, the IC is reading RAM using a physical address, so checking
that the transaction status is important. The FW could configure bogus
addresses.
In any case,
Reviewed-by: Frederic Barrat
Thanks,
C.
Fred
+ if (result != MEMTX_OK) {
+ xive_error(xive, "VST: read failed at @0x%" HWADDR_PRIx
+ " for VST %s %x/%x\n", addr, info->name, blk, idx);
+ return -1;
+ }
return 0;
}
@@ -258,16 +266,27 @@ static int pnv_xive_vst_write(PnvXive *xive, uint32_t
type, uint8_t blk,
{
const XiveVstInfo *info = &vst_infos[type];
uint64_t addr = pnv_xive_vst_addr(xive, type, blk, idx);
+ MemTxResult result;
if (!addr) {
return -1;
}
if (word_number == XIVE_VST_WORD_ALL) {
- cpu_physical_memory_write(addr, data, info->size);
+ result = address_space_write(&address_space_memory, addr,
+ MEMTXATTRS_UNSPECIFIED, data,
+ info->size);
} else {
- cpu_physical_memory_write(addr + word_number * 4,
- data + word_number * 4, 4);
+ result = address_space_write(&address_space_memory,
+ addr + word_number * 4,
+ MEMTXATTRS_UNSPECIFIED,
+ data + word_number * 4, 4);
+ }
+
+ if (result != MEMTX_OK) {
+ xive_error(xive, "VST: write failed at @0x%" HWADDR_PRIx
+ "for VST %s %x/%x\n", addr, info->name, blk, idx);
+ return -1;
}
return 0;
}
diff --git a/hw/intc/pnv_xive2.c b/hw/intc/pnv_xive2.c
index bbb44a533cff..4b8d0a5d8120 100644
--- a/hw/intc/pnv_xive2.c
+++ b/hw/intc/pnv_xive2.c
@@ -240,12 +240,20 @@ static int pnv_xive2_vst_read(PnvXive2 *xive, uint32_t
type, uint8_t blk,
{
const XiveVstInfo *info = &vst_infos[type];
uint64_t addr = pnv_xive2_vst_addr(xive, type, blk, idx);
+ MemTxResult result;
if (!addr) {
return -1;
}
- cpu_physical_memory_read(addr, data, info->size);
+ result = address_space_read(&address_space_memory, addr,
+ MEMTXATTRS_UNSPECIFIED, data,
+ info->size);
+ if (result != MEMTX_OK) {
+ xive2_error(xive, "VST: read failed at @0x%" HWADDR_PRIx
+ " for VST %s %x/%x\n", addr, info->name, blk, idx);
+ return -1;
+ }
return 0;
}
@@ -256,16 +264,27 @@ static int pnv_xive2_vst_write(PnvXive2 *xive, uint32_t
type, uint8_t blk,
{
const XiveVstInfo *info = &vst_infos[type];
uint64_t addr = pnv_xive2_vst_addr(xive, type, blk, idx);
+ MemTxResult result;
if (!addr) {
return -1;
}
if (word_number == XIVE_VST_WORD_ALL) {
- cpu_physical_memory_write(addr, data, info->size);
+ result = address_space_write(&address_space_memory, addr,
+ MEMTXATTRS_UNSPECIFIED, data,
+ info->size);
} else {
- cpu_physical_memory_write(addr + word_number * 4,
- data + word_number * 4, 4);
+ result = address_space_write(&address_space_memory,
+ addr + word_number * 4,
+ MEMTXATTRS_UNSPECIFIED,
+ data + word_number * 4, 4);
+ }
+
+ if (result != MEMTX_OK) {
+ xive2_error(xive,
Re: [PATCH 3/4] ppc/xive: Handle END triggers between chips with MMIOs
On 29/08/2023 16:32, Cédric Le Goater wrote:
The notify page of the interrupt controller can either be used to
receive trigger events from the HW controllers (PHB, PSI) or to
reroute interrupts between Interrupt Controllers. In which case, the
VSD table is used to determine the address of the notify page of the
remote IC and the store data is forwarded.
Today, our model grabs the remote VSD (EAS, END, NVT) address using
pnv_xive_get_remote() helper. Be more precise and implement remote END
triggers using a store on the remote IC notify page.
We still have a shortcut in the model for the NVT accesses which we
will address later.
Signed-off-by: Cédric Le Goater
---
Reviewed-by: Frederic Barrat
Fred
hw/intc/pnv_xive_regs.h | 1 +
hw/intc/pnv_xive.c | 69 +++--
2 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/hw/intc/pnv_xive_regs.h b/hw/intc/pnv_xive_regs.h
index c78f030c0260..793847638bce 100644
--- a/hw/intc/pnv_xive_regs.h
+++ b/hw/intc/pnv_xive_regs.h
@@ -228,6 +228,7 @@
* VSD and is only meant to be used in indirect mode !
*/
#define VSD_MODEPPC_BITMASK(0, 1)
+#define VSD_MODE_INVALID 0
#define VSD_MODE_SHARED1
#define VSD_MODE_EXCLUSIVE 2
#define VSD_MODE_FORWARD 3
diff --git a/hw/intc/pnv_xive.c b/hw/intc/pnv_xive.c
index b2bafd61b157..aae5cb6f607b 100644
--- a/hw/intc/pnv_xive.c
+++ b/hw/intc/pnv_xive.c
@@ -225,6 +225,11 @@ static uint64_t pnv_xive_vst_addr(PnvXive *xive, uint32_t
type, uint8_t blk,
/* Remote VST access */
if (GETFIELD(VSD_MODE, vsd) == VSD_MODE_FORWARD) {
+if (type != VST_TSEL_VPDT) {
+xive_error(xive, "VST: invalid access on remote VST %s %x/%x !?",
+ info->name, blk, idx);
+return 0;
+}
xive = pnv_xive_get_remote(blk);
return xive ? pnv_xive_vst_addr(xive, type, blk, idx) : 0;
@@ -294,12 +299,26 @@ static int pnv_xive_vst_write(PnvXive *xive, uint32_t
type, uint8_t blk,
static int pnv_xive_get_end(XiveRouter *xrtr, uint8_t blk, uint32_t idx,
XiveEND *end)
{
+PnvXive *xive = PNV_XIVE(xrtr);
+
+if (pnv_xive_block_id(xive) != blk) {
+xive_error(xive, "VST: END %x/%x is remote !?", blk, idx);
+return -1;
+}
+
return pnv_xive_vst_read(PNV_XIVE(xrtr), VST_TSEL_EQDT, blk, idx, end);
}
static int pnv_xive_write_end(XiveRouter *xrtr, uint8_t blk, uint32_t idx,
XiveEND *end, uint8_t word_number)
{
+PnvXive *xive = PNV_XIVE(xrtr);
+
+if (pnv_xive_block_id(xive) != blk) {
+xive_error(xive, "VST: END %x/%x is remote !?", blk, idx);
+return -1;
+}
+
return pnv_xive_vst_write(PNV_XIVE(xrtr), VST_TSEL_EQDT, blk, idx, end,
word_number);
}
@@ -1368,6 +1387,50 @@ static const MemoryRegionOps pnv_xive_ic_reg_ops = {
#define PNV_XIVE_SYNC_PUSH 0xf00 /* Sync push context */
#define PNV_XIVE_SYNC_VPC 0xf80 /* Sync remove VPC store */
+static void pnv_xive_end_notify(XiveRouter *xrtr, XiveEAS *eas)
+{
+PnvXive *xive = PNV_XIVE(xrtr);
+uint8_t end_blk = xive_get_field64(EAS_END_BLOCK, eas->w);
+uint32_t end_idx = xive_get_field64(EAS_END_INDEX, eas->w);
+uint32_t end_data = xive_get_field64(EAS_END_DATA, eas->w);
+uint64_t end_vsd = xive->vsds[VST_TSEL_EQDT][end_blk];
+
+switch (GETFIELD(VSD_MODE, end_vsd)) {
+case VSD_MODE_EXCLUSIVE:
+/* Perform the END notification on the local IC. */
+xive_router_end_notify(xrtr, eas);
+break;
+
+case VSD_MODE_FORWARD: {
+MemTxResult result;
+uint64_t notif_port = end_vsd & VSD_ADDRESS_MASK;
+uint64_t data = XIVE_TRIGGER_END | XIVE_TRIGGER_PQ |
+be64_to_cpu(eas->w);
+
+/* Forward the store on the remote IC notify page. */
+address_space_stq_be(&address_space_memory, notif_port, data,
+ MEMTXATTRS_UNSPECIFIED, &result);
+if (result != MEMTX_OK) {
+xive_error(xive, "IC: Forward notif END %x/%x [%x] failed @%"
+ HWADDR_PRIx, end_blk, end_idx, end_data, notif_port);
+return;
+}
+break;
+}
+
+case VSD_MODE_INVALID:
+default:
+/* Set FIR */
+xive_error(xive, "IC: Invalid END VSD for block %x", end_blk);
+return;
+}
+}
+
+/*
+ * The notify page can either be used to receive trigger events from
+ * the HW controllers (PHB, PSI) or to reroute interrupts between
+ * Interrupt controllers.
+ */
static void pnv_xive_ic_hw_trigger(PnvXive *xive, hwaddr addr, uint64_t val)
{
uint8_t blk;
@@ -1376,8 +1439,8 @@ static void pnv_xive_ic_hw_trigger(PnvXive *xive, hwaddr
addr, uint64_t val)
trace_pnv_xive_ic_hw_trigger(addr, val);
if (val & XIVE_TRIGGER_END) {
-xive_err
Re: [PATCH 4/4] ppc/xive: Add support for the PC MMIOs
On 29/08/2023 16:32, Cédric Le Goater wrote:
The XIVE interrupt contoller maintains various fields on interrupt
targets in a structure called NVT. Each unit has a NVT cache, backed
by RAM.
When the NVT structure is not local (in RAM) to the chip, the XIVE
interrupt controller forwards the memory operation to the owning chip
using the PC MMIO region configured for this purpose. QEMU does not
need to be so precise since software shouldn't perform any of these
operations. The model implementation is simplified to return the RAM
address of the NVT structure which is then used by pnv_xive_vst_write
or read to perform the operation in RAM.
Remove the last use of pnv_xive_get_remote().
Signed-off-by: Cédric Le Goater
-
Nice cleanup
Reviewed-by: Frederic Barrat
Fred
hw/intc/pnv_xive.c | 84 ++
1 file changed, 48 insertions(+), 36 deletions(-)
diff --git a/hw/intc/pnv_xive.c b/hw/intc/pnv_xive.c
index aae5cb6f607b..9b10e905195a 100644
--- a/hw/intc/pnv_xive.c
+++ b/hw/intc/pnv_xive.c
@@ -84,28 +84,6 @@ static uint8_t pnv_xive_block_id(PnvXive *xive)
return blk;
}
-/*
- * Remote access to controllers. HW uses MMIOs. For now, a simple scan
- * of the chips is good enough.
- *
- * TODO: Block scope support
- */
-static PnvXive *pnv_xive_get_remote(uint8_t blk)
-{
-PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
-int i;
-
-for (i = 0; i < pnv->num_chips; i++) {
-Pnv9Chip *chip9 = PNV9_CHIP(pnv->chips[i]);
-PnvXive *xive = &chip9->xive;
-
-if (pnv_xive_block_id(xive) == blk) {
-return xive;
-}
-}
-return NULL;
-}
-
/*
* VST accessors for SBE, EAT, ENDT, NVT
*
@@ -209,6 +187,42 @@ static uint64_t pnv_xive_vst_addr_indirect(PnvXive *xive,
uint32_t type,
return pnv_xive_vst_addr_direct(xive, type, vsd, (idx % vst_per_page));
}
+/*
+ * This is a simplified model of operation forwarding on a remote IC.
+ *
+ * A PC MMIO address is built to identify the NVT structure. The load
+ * on the remote IC will return the address of the structure in RAM,
+ * which will then be used by pnv_xive_vst_write/read to perform the
+ * RAM operation.
+ */
+static uint64_t pnv_xive_vst_addr_remote(PnvXive *xive, uint32_t type,
+ uint64_t vsd, uint8_t blk,
+ uint32_t idx)
+{
+const XiveVstInfo *info = &vst_infos[type];
+uint64_t remote_addr = vsd & VSD_ADDRESS_MASK;
+uint64_t vst_addr;
+MemTxResult result;
+
+if (type != VST_TSEL_VPDT) {
+xive_error(xive, "VST: invalid access on remote VST %s %x/%x !?",
+ info->name, blk, idx);
+return 0;
+}
+
+remote_addr |= idx << xive->pc_shift;
+
+vst_addr = address_space_ldq_be(&address_space_memory, remote_addr,
+MEMTXATTRS_UNSPECIFIED, &result);
+if (result != MEMTX_OK) {
+xive_error(xive, "VST: read failed at @0x%" HWADDR_PRIx
+ " for NVT %x/%x\n", remote_addr, blk, idx);
+return 0;
+}
+
+return vst_addr;
+}
+
static uint64_t pnv_xive_vst_addr(PnvXive *xive, uint32_t type, uint8_t blk,
uint32_t idx)
{
@@ -225,14 +239,7 @@ static uint64_t pnv_xive_vst_addr(PnvXive *xive, uint32_t
type, uint8_t blk,
/* Remote VST access */
if (GETFIELD(VSD_MODE, vsd) == VSD_MODE_FORWARD) {
-if (type != VST_TSEL_VPDT) {
-xive_error(xive, "VST: invalid access on remote VST %s %x/%x !?",
- info->name, blk, idx);
-return 0;
-}
-xive = pnv_xive_get_remote(blk);
-
-return xive ? pnv_xive_vst_addr(xive, type, blk, idx) : 0;
+return pnv_xive_vst_addr_remote(xive, type, vsd, blk, idx);
}
if (VSD_INDIRECT & vsd) {
@@ -1785,16 +1792,20 @@ static const MemoryRegionOps pnv_xive_vc_ops = {
};
/*
- * Presenter Controller MMIO region. The Virtualization Controller
- * updates the IPB in the NVT table when required. Not modeled.
+ * Presenter Controller MMIO region. Points to the NVT sets.
+ *
+ * HW implements all possible mem ops to the underlying NVT structure
+ * but QEMU does not need to be so precise. The model implementation
+ * simply returns the RAM address of the NVT structure which is then
+ * used by pnv_xive_vst_write/read to perform the RAM operation.
*/
-static uint64_t pnv_xive_pc_read(void *opaque, hwaddr addr,
- unsigned size)
+static uint64_t pnv_xive_pc_read(void *opaque, hwaddr offset, unsigned size)
{
PnvXive *xive = PNV_XIVE(opaque);
+uint32_t nvt_idx = offset >> xive->pc_shift;
+uint8_t blk = pnv_xive_block_id(xive); /* TODO: VDT -> block xlate */
-xive_error(xive, "PC: invalid read @%"HWADDR_PRIx, addr);
-return -1;
+return pnv_xive_vst_addr(xive, VST_TSEL_VPDT, blk, nvt_idx);
}
stati
Re: [PATCH v5 00/20] linux-user: Implement VDSOs
Richard Henderson writes: > On 8/30/23 07:52, Helge Deller wrote: >> On 8/30/23 00:02, Richard Henderson wrote: >>> Changes for v5: >>> * Integrated cross-compile, via new build-vdso.sh and meson rules. >>> However, keep the binaries in the tree for hosts which do not >>> have all of the cross-compile machinery. >>> * Update our loongarch64 docker image to avoid a binutils bug. >>> >>> Just in case the list eats a binary: >>> https://gitlab.com/rth7680/qemu/-/tree/lu-vdso >> I pulled that on top of git head, and ran into the build problem >> below. >> Do I miss something? > > No idea, since it worked for me. Looks like some sort of docker.py problem. > Alex? > > In the short term, use --disable-containers so that you only use the > cross-compilers that you have locally installed. > > > r~ > >> Helge >> [62/1742] Generating linux-user/aarch64/vdso-be.so with a custom >> command >> FAILED: linux-user/aarch64/vdso-be.so >> /home/cvs/qemu/qemu/linux-user/build-vdso.sh -B /srv/_build -C >> /home/cvs/qemu/qemu/linux-user/aarch64 -T aarch64-linux-user -o >> linux-user/aarch64/vdso-be.so -- -nostdlib -shared >> -Wl,-h,linux-vdso.so.1 -Wl,--build-id=sha1 -Wl,--hash-style=both >> -Wl,-T,../../home/cvs/qemu/qemu/linux-user/aarch64/vdso.ld >> ../../home/cvs/qemu/qemu/linux-user/aarch64/vdso.S -mbig-endian >> Error: short-name resolution enforced but cannot prompt without a TTY >> Traceback (most recent call last): >> File "/home/cvs/qemu/qemu/tests/docker/docker.py", line 683, in >> sys.exit(main()) >> ^^ >> File "/home/cvs/qemu/qemu/tests/docker/docker.py", line 679, in main >> return args.cmdobj.run(args, argv) >> ^^^ >> File "/home/cvs/qemu/qemu/tests/docker/docker.py", line 657, in run >> return Docker().run(cmd, False, quiet=args.quiet, >> ^^ >> File "/home/cvs/qemu/qemu/tests/docker/docker.py", line 370, in run >> ret = self._do_check(["run", "--rm", "--label", >> ^ >> File "/home/cvs/qemu/qemu/tests/docker/docker.py", line 247, in _do_check >> return subprocess.check_call(self._command + cmd, **kwargs) >> >> File "/usr/lib64/python3.11/subprocess.py", line 413, in check_call >> raise CalledProcessError(retcode, cmd) >> subprocess.CalledProcessError: Command '['podman', 'run', '--rm', >> '--label', It looks like it detected podman on this setup. Can you invoke the container from the command line? >> 'com.qemu.instance.uuid=e746f7e345ed420088a9cc30e884a7e8', >> '--userns=keep-id', '-u', '1000', '-w', '/srv/_build', '-v', >> '/srv/_build:/srv/_build:rw', '-v', >> '/home/cvs/qemu/qemu:/home/cvs/qemu/qemu:ro,z', >> 'qemu/debian-arm64-cross', 'aarch64-linux-gnu-gcc-10', '-o', >> 'linux-user/aarch64/vdso-be.so', '-nostdlib', '-shared', >> '-Wl,-h,linux-vdso.so.1', '-Wl,--build-id=sha1', >> '-Wl,--hash-style=both', >> '-Wl,-T,../../home/cvs/qemu/qemu/linux-user/aarch64/vdso.ld', >> '../../home/cvs/qemu/qemu/linux-user/aarch64/vdso.S', >> '-mbig-endian']' returned non-zero exit status 125. >> filter=--filter=label=com.qemu.instance.uuid=e746f7e345ed420088a9cc30e884a7e8 >> -- Alex Bennée Virtualisation Tech Lead @ Linaro
Re: [PATCH] pci: SLT must be RO
On 31/8/23 08:45, Michael S. Tsirkin wrote:
On Thu, Aug 31, 2023 at 08:22:34AM +0200, Philippe Mathieu-Daudé wrote:
Hi Michael,
On 30/8/23 23:48, Michael S. Tsirkin wrote:
current code sets PCI_SEC_LATENCY_TIMER to WO, but for
pcie to pcie bridges it must be RO 0 according to
pci express spec which says:
This register does not apply to PCI Express. It must be read-only
and hardwired to 00h. For PCI Express to PCI/PCI-X Bridges, refer to the
[PCIe-to-PCI-PCI-X-Bridge] for requirements for this register.
also, fix typo in comment where it's make writeable - this typo
is likely what prevented us noticing we violate this requirement
in the 1st place.
Reported-by: Marcin Juszkiewicz
Signed-off-by: Michael S. Tsirkin
---
Marcin, could you pls test this patch with virt-8.1 and latest?
Thanks a lot!
include/hw/pci/pci_bridge.h | 3 +++
hw/core/machine.c | 5 -
hw/pci/pci.c| 2 +-
hw/pci/pci_bridge.c | 14 ++
4 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/include/hw/pci/pci_bridge.h b/include/hw/pci/pci_bridge.h
index ea54a81a15..5cd452115a 100644
--- a/include/hw/pci/pci_bridge.h
+++ b/include/hw/pci/pci_bridge.h
@@ -77,6 +77,9 @@ struct PCIBridge {
pci_map_irq_fn map_irq;
const char *bus_name;
+
+/* SLT is RO for PCIE to PCIE bridges, but old QEMU versions had it RW */
+bool pcie_writeable_slt_bug;
};
Patch LGTM, so:
Reviewed-by: Philippe Mathieu-Daudé
-GlobalProperty hw_compat_8_1[] = {};
+GlobalProperty hw_compat_8_1[] = {
+{ TYPE_PCI_BRIDGE, "x-pci-express-writeable-slt-bug", "true" },
However I don't understand why we can't clear the config register and
must use a compat flag, since per the spec it is hardwired to 0.
Because historically we didn't. If we make it RO and migrate from
VM where guest wrote into this register, migration will fail
as we check that RO fields are unchanged.
Another trick would be to pretend it's hardware driven
and set cmask. Compat machinery is more straight-forward though.
I see.
Do we need the "x-" compat prefix? This is not an experimental property.
It's an internal one, we don't want users to tweak it.
OK, thanks!
Re: [PATCH v2 01/12] build: Only define OS_OBJECT_USE_OBJC with gcc
On 30/8/23 18:14, Alexander Graf wrote: Recent versions of macOS use clang instead of gcc. The OS_OBJECT_USE_OBJC define is only necessary when building with gcc. Let's not define it when building with clang. With this patch, I can successfully include GCD headers in QEMU when building with clang. Signed-off-by: Alexander Graf --- meson.build | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/meson.build b/meson.build index 98e68ef0b1..0d6a0015a1 100644 --- a/meson.build +++ b/meson.build @@ -224,7 +224,9 @@ qemu_ldflags = [] if targetos == 'darwin' # Disable attempts to use ObjectiveC features in os/object.h since they # won't work when we're compiling with gcc as a C compiler. - qemu_common_flags += '-DOS_OBJECT_USE_OBJC=0' + if compiler.get_id() == 'gcc' +qemu_common_flags += '-DOS_OBJECT_USE_OBJC=0' + endif elif targetos == 'solaris' # needed for CMSG_ macros in sys/socket.h qemu_common_flags += '-D_XOPEN_SOURCE=600' Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v2 04/12] hvf: arm: Ignore writes to CNTP_CTL_EL0
On 30/8/23 18:14, Alexander Graf wrote: MacOS unconditionally disables interrupts of the physical timer on boot and then continues to use the virtual one. We don't really want to support a full physical timer emulation, so let's just ignore those writes. Signed-off-by: Alexander Graf --- v1 -> v2: - Add log message on write --- target/arm/hvf/hvf.c | 9 + 1 file changed, 9 insertions(+) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH 10/10] configure: move --enable-debug-tcg to meson
On 29/8/23 10:29, Paolo Bonzini wrote: Signed-off-by: Paolo Bonzini --- configure | 11 +-- meson.build | 3 ++- meson_options.txt | 2 ++ scripts/meson-buildoptions.sh | 3 +++ 4 files changed, 8 insertions(+), 11 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH 02/10] meson: update unsupported host/CPU messages
On Tue, Aug 29, 2023 at 12:34 PM Daniel P. Berrangé wrote: > I think I agree wrt to CPUs, but in the case of OS I think > it is fairly accurate as-is. Ok, I wanted to leave out the "*intends* to remove support" part, which is too strong; but I agree that keeping some kind of "support may go away in future releases unless you act" is a good idea. Paolo
[PATCH v2] accel: Remove HAX accelerator
HAX is deprecated since commits 73741fda6c ("MAINTAINERS: Abort
HAXM maintenance") and 90c167a1da ("docs/about/deprecated: Mark
HAXM in QEMU as deprecated"), released in v8.0.0.
Per the latest HAXM release (v7.8 [*]), the latest QEMU supported
is v7.2:
Note: Up to this release, HAXM supports QEMU from 2.9.0 to 7.2.0.
The next commit (https://github.com/intel/haxm/commit/da1b8ec072)
added:
HAXM v7.8.0 is our last release and we will not accept
pull requests or respond to issues after this.
It became very hard to build and test HAXM. Its previous
maintainers made it clear they won't help. It doesn't seem to be
a very good use of QEMU maintainers to spend their time in a dead
project. Save our time by removing this orphan zombie code.
[*] https://github.com/intel/haxm/releases/tag/v7.8.0
Reviewed-by: Richard Henderson
Acked-by: Markus Armbruster
Signed-off-by: Philippe Mathieu-Daudé
---
I plan to commit this in my next PR.
---
MAINTAINERS |8 -
docs/about/build-platforms.rst|2 +-
docs/about/deprecated.rst |6 -
docs/about/index.rst |2 +-
docs/about/removed-features.rst | 11 +-
docs/system/index.rst |2 +-
docs/system/introduction.rst |3 -
meson.build |7 -
include/exec/poison.h |1 -
include/hw/core/cpu.h |2 +-
include/sysemu/hax.h | 49 -
include/sysemu/hw_accel.h |1 -
target/i386/hax/hax-accel-ops.h | 31 -
target/i386/hax/hax-i386.h| 98 --
target/i386/hax/hax-interface.h | 369 --
target/i386/hax/hax-posix.h | 61 -
target/i386/hax/hax-windows.h | 88 --
accel/stubs/hax-stub.c| 24 -
hw/intc/apic_common.c |3 +-
softmmu/cpus.c|6 -
softmmu/vl.c |6 -
target/i386/hax/hax-accel-ops.c | 105 --
target/i386/hax/hax-all.c | 1141 -
target/i386/hax/hax-mem.c | 323 -
target/i386/hax/hax-posix.c | 305 -
target/i386/hax/hax-windows.c | 485 ---
accel/Kconfig |3 -
accel/stubs/meson.build |1 -
meson_options.txt |2 -
qemu-options.hx |8 +-
.../ci/org.centos/stream/8/x86_64/configure |1 -
scripts/meson-buildoptions.sh |3 -
target/i386/hax/meson.build |7 -
target/i386/meson.build |1 -
34 files changed, 16 insertions(+), 3149 deletions(-)
delete mode 100644 include/sysemu/hax.h
delete mode 100644 target/i386/hax/hax-accel-ops.h
delete mode 100644 target/i386/hax/hax-i386.h
delete mode 100644 target/i386/hax/hax-interface.h
delete mode 100644 target/i386/hax/hax-posix.h
delete mode 100644 target/i386/hax/hax-windows.h
delete mode 100644 accel/stubs/hax-stub.c
delete mode 100644 target/i386/hax/hax-accel-ops.c
delete mode 100644 target/i386/hax/hax-all.c
delete mode 100644 target/i386/hax/hax-mem.c
delete mode 100644 target/i386/hax/hax-posix.c
delete mode 100644 target/i386/hax/hax-windows.c
delete mode 100644 target/i386/hax/meson.build
diff --git a/MAINTAINERS b/MAINTAINERS
index 6111b6b4d9..3b29568ed4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -543,14 +543,6 @@ F: include/sysemu/xen.h
F: include/sysemu/xen-mapcache.h
F: stubs/xen-hw-stub.c
-Guest CPU Cores (HAXM)
--
-X86 HAXM CPUs
-S: Orphan
-F: accel/stubs/hax-stub.c
-F: include/sysemu/hax.h
-F: target/i386/hax/
-
Guest CPU Cores (NVMM)
--
NetBSD Virtual Machine Monitor (NVMM) CPU support
diff --git a/docs/about/build-platforms.rst b/docs/about/build-platforms.rst
index 0e2cb9e770..f2a7aec56f 100644
--- a/docs/about/build-platforms.rst
+++ b/docs/about/build-platforms.rst
@@ -52,7 +52,7 @@ Those hosts are officially supported, with various
accelerators:
* - SPARC
- tcg
* - x86
- - hax, hvf (64 bit only), kvm, nvmm, tcg, whpx (64 bit only), xen
+ - hvf (64 bit only), kvm, nvmm, tcg, whpx (64 bit only), xen
Other host architectures are not supported. It is possible to build QEMU system
emulation on an unsupported host architecture using the configure
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 92a2bafd2b..dc4da95329 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -105,12 +105,6 @@ Use ``-machine hpet=off`` instead.
The ``-no-acpi`` setting has been turned into a machine property.
Use ``-machine acpi=off`` instead.
-``-accel hax`` (since 8.0)
Re: [PATCH] hw/usb/hcd-xhci-pci: Fail if user requested MSIX but it can't be used
kind ping?
On 25/8/23 10:02, Philippe Mathieu-Daudé wrote:
Ping?
On 19/7/23 16:17, Philippe Mathieu-Daudé wrote:
Do not silently ignore the user request of using MSIX.
Remove the TODO. Coverity reported this as CID 1508725.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/usb/hcd-xhci-pci.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/hw/usb/hcd-xhci-pci.c b/hw/usb/hcd-xhci-pci.c
index 643d4643e4..416656b78c 100644
--- a/hw/usb/hcd-xhci-pci.c
+++ b/hw/usb/hcd-xhci-pci.c
@@ -155,11 +155,22 @@ static void usb_xhci_pci_realize(struct
PCIDevice *dev, Error **errp)
}
if (s->msix != ON_OFF_AUTO_OFF) {
- /* TODO check for errors, and should fail when msix=on */
- msix_init(dev, s->xhci.numintrs,
- &s->xhci.mem, 0, OFF_MSIX_TABLE,
- &s->xhci.mem, 0, OFF_MSIX_PBA,
- 0x90, NULL);
+ ret = msix_init(dev, s->xhci.numintrs,
+ &s->xhci.mem, 0, OFF_MSIX_TABLE,
+ &s->xhci.mem, 0, OFF_MSIX_PBA,
+ 0x90, &err);
+ if (ret < 0) {
+ if (s->msi == ON_OFF_AUTO_ON) {
+ /* Can't satisfy user's explicit msi=on request, fail */
+ error_append_hint(&err, "You might have to use msi=auto"
+ " (default) or msi=off with
this"
+ " machine type.\n");
+ error_propagate(errp, err);
+ return;
+ }
+ /* report that msix is not supported, but do not error
out */
+ warn_report_err(err);
+ }
}
s->xhci.as = pci_get_address_space(dev);
}
Re: [PATCH] hw/usb/hcd-xhci-pci: Fail if user requested MSIX but it can't be used
Cc'ing Markus and Marc-André
On 31/8/23 10:22, Philippe Mathieu-Daudé wrote:
kind ping?
On 25/8/23 10:02, Philippe Mathieu-Daudé wrote:
Ping?
On 19/7/23 16:17, Philippe Mathieu-Daudé wrote:
Do not silently ignore the user request of using MSIX.
Remove the TODO. Coverity reported this as CID 1508725.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/usb/hcd-xhci-pci.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/hw/usb/hcd-xhci-pci.c b/hw/usb/hcd-xhci-pci.c
index 643d4643e4..416656b78c 100644
--- a/hw/usb/hcd-xhci-pci.c
+++ b/hw/usb/hcd-xhci-pci.c
@@ -155,11 +155,22 @@ static void usb_xhci_pci_realize(struct
PCIDevice *dev, Error **errp)
}
if (s->msix != ON_OFF_AUTO_OFF) {
- /* TODO check for errors, and should fail when msix=on */
- msix_init(dev, s->xhci.numintrs,
- &s->xhci.mem, 0, OFF_MSIX_TABLE,
- &s->xhci.mem, 0, OFF_MSIX_PBA,
- 0x90, NULL);
+ ret = msix_init(dev, s->xhci.numintrs,
+ &s->xhci.mem, 0, OFF_MSIX_TABLE,
+ &s->xhci.mem, 0, OFF_MSIX_PBA,
+ 0x90, &err);
+ if (ret < 0) {
+ if (s->msi == ON_OFF_AUTO_ON) {
+ /* Can't satisfy user's explicit msi=on request,
fail */
+ error_append_hint(&err, "You might have to use
msi=auto"
+ " (default) or msi=off with
this"
+ " machine type.\n");
+ error_propagate(errp, err);
+ return;
+ }
+ /* report that msix is not supported, but do not error
out */
+ warn_report_err(err);
+ }
}
s->xhci.as = pci_get_address_space(dev);
}
Re: [PATCH 04/10] configure: create native file with contents of $host_cc
On Tue, Aug 29, 2023 at 7:14 PM Daniel P. Berrangé wrote:
>
> On Tue, Aug 29, 2023 at 10:29:25AM +0200, Paolo Bonzini wrote:
> > The argument of --host-cc is not obeyed when cross compiling. To avoid
> > this issue, place it in a configuration file and pass it to meson
> > with --native-file.
> >
> > While at it, clarify that --host-cc is not obeyed anyway when _not_
> > cross compiling.
>
> I presume that's refering to this piece of code
>
> if test -z "${CC}${cross_prefix}"; then
> cc="$host_cc"
> else
> cc="${CC-${cross_prefix}gcc}"
> fi
>
> which is using $host_cc *before* --host-cc is processed, thus
> meaning it is always at its default value of 'cc'.
That, plus the fact that --native-file is only used in cross
compilation scenarios; when doing a native compilation there's no
difference between "native: true" and "native: false" as far as Meson
is concerned.
> Perhaps the above code snippet should just be changed to
>
> if test -z "${CC}${cross_prefix}"; then
> cc="cc"
> else
> cc="${CC-${cross_prefix}gcc}"
> fi
>
> to make it clear that we were not intending to honour the
> --host-cc value for this code.
Since I have to send a v2 anyway for the (un)supported OS message,
I'll do the change.
Paolo
Re: [PATCH] util/iov: Avoid dynamic stack allocation
Cc'ing qemu-block@ (I suppose this will go via a block tree)
On 24/8/23 18:47, Peter Maydell wrote:
From: Philippe Mathieu-Daudé
Use autofree heap allocation instead of variable-length array on the
stack.
The codebase has very few VLAs, and if we can get rid of them all we
can make the compiler error on new additions. This is a defensive
measure against security bugs where an on-stack dynamic allocation
isn't correctly size-checked (e.g. CVE-2021-3527).
Signed-off-by: Philippe Mathieu-Daudé
Signed-off-by: Peter Maydell
---
Usual "only tested with make check/make check-avocado" caveat.
util/iov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/util/iov.c b/util/iov.c
index 866fb577f30..7e73948f5e3 100644
--- a/util/iov.c
+++ b/util/iov.c
@@ -571,7 +571,7 @@ static int sortelem_cmp_src_index(const void *a, const void
*b)
*/
void qemu_iovec_clone(QEMUIOVector *dest, const QEMUIOVector *src, void *buf)
{
-IOVectorSortElem sortelems[src->niov];
+g_autofree IOVectorSortElem *sortelems = g_new(IOVectorSortElem,
src->niov);
void *last_end;
int i;
Re: [PATCH v3 0/8] misc AHCI cleanups
Hi John, On 7/8/23 19:37, John Snow wrote: Apologies again for the delay. I tested it lightly and it seems fine to me (and in general I trust your commits as they've got meticulous references to the spec, so it'll be easy to fix if something goes wrong) It's my fault we'll miss this release window, but putting it in early next window gives us a lot of time for people to notice accidental regressions. Thanks for the patches and I hope to see more from you soon ;) I've been doing some testing (x86/mips), but I don't think I have the same coverage as your maintainer test suite. Still, if you are busy, I can merge this series now that we are at the beginning of the development cycle. Regards, Phil.
Re: [PATCH 2/4] ppc/xive: Introduce a new XiveRouter end_notify() handler
On 8/31/23 09:50, Frederic Barrat wrote:
On 29/08/2023 16:32, Cédric Le Goater wrote:
It will help us model the END triggers on the PowerNV machine, which
can be rerouted to another interrupt controller.
Signed-off-by: Cédric Le Goater
---
diff --git a/hw/intc/xive.c b/hw/intc/xive.c
index 56670b2cac6e..df3ee0496fe7 100644
--- a/hw/intc/xive.c
+++ b/hw/intc/xive.c
@@ -1518,6 +1518,13 @@ static void xive_router_realize(DeviceState *dev, Error
**errp)
assert(xrtr->xfb);
}
+static void xive_router_end_notify_handler(XiveRouter *xrtr, XiveEAS *eas)
+{
+ XiveRouterClass *xrc = XIVE_ROUTER_GET_CLASS(xrtr);
+
+ return xrc->end_notify(xrtr, eas);
+}
+
/*
* Encode the HW CAM line in the block group mode format :
*
@@ -1664,8 +1671,7 @@ static bool xive_router_end_es_notify(XiveRouter *xrtr,
uint8_t end_blk,
* another chip. We don't model the PowerBus but the END trigger
* message has the same parameters than in the function below.
*/
-static void xive_router_end_notify(XiveRouter *xrtr, uint8_t end_blk,
- uint32_t end_idx, uint32_t end_data)
+void xive_router_end_notify(XiveRouter *xrtr, XiveEAS *eas)
{
XiveEND end;
uint8_t priority;
@@ -1675,6 +1681,10 @@ static void xive_router_end_notify(XiveRouter *xrtr,
uint8_t end_blk,
XiveNVT nvt;
bool found;
+ uint8_t end_blk = xive_get_field64(EAS_END_BLOCK, eas->w);
+ uint32_t end_idx = xive_get_field64(EAS_END_INDEX, eas->w);
+ uint32_t end_data = xive_get_field64(EAS_END_DATA, eas->w);
+
/* END cache lookup */
if (xive_router_get_end(xrtr, end_blk, end_idx, &end)) {
qemu_log_mask(LOG_GUEST_ERROR, "XIVE: No END %x/%x\n", end_blk,
@@ -1817,10 +1827,7 @@ do_escalation:
/*
* The END trigger becomes an Escalation trigger
*/
- xive_router_end_notify(xrtr,
- xive_get_field32(END_W4_ESC_END_BLOCK, end.w4),
- xive_get_field32(END_W4_ESC_END_INDEX, end.w4),
- xive_get_field32(END_W5_ESC_END_DATA, end.w5));
+ xive_router_end_notify_handler(xrtr, (XiveEAS *) &end.w4);
I didn't like the cast, but I can see why you're doing it this way.
OPAL does a similar cast :
https://github.com/open-power/skiboot/blob/master/hw/xive.c#L783
We should be fine as long as the notify handler is not testing the validity bit
of the EAS structure.
Indeed. It doesn't seem to be set :
XIVE[0] #0 END Escalation EAT
008e -Qend:00/008f data:
008f --end:01/003f data:008f
0096 -Qend:00/0097 data:
0097 --end:01/003f data:0097
I don't remember to be honest. This is from a few years back. Ask the
HW designer may be ?
Reviewed-by: Frederic Barrat
Thanks,
C.
Fred
}
void xive_router_notify(XiveNotifier *xn, uint32_t lisn, bool pq_checked)
@@ -1871,10 +1878,7 @@ void xive_router_notify(XiveNotifier *xn, uint32_t lisn,
bool pq_checked)
/*
* The event trigger becomes an END trigger
*/
- xive_router_end_notify(xrtr,
- xive_get_field64(EAS_END_BLOCK, eas.w),
- xive_get_field64(EAS_END_INDEX, eas.w),
- xive_get_field64(EAS_END_DATA, eas.w));
+ xive_router_end_notify_handler(xrtr, &eas);
}
static Property xive_router_properties[] = {
@@ -1887,12 +1891,16 @@ static void xive_router_class_init(ObjectClass *klass,
void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
XiveNotifierClass *xnc = XIVE_NOTIFIER_CLASS(klass);
+ XiveRouterClass *xrc = XIVE_ROUTER_CLASS(klass);
dc->desc = "XIVE Router Engine";
device_class_set_props(dc, xive_router_properties);
/* Parent is SysBusDeviceClass. No need to call its realize hook */
dc->realize = xive_router_realize;
xnc->notify = xive_router_notify;
+
+ /* By default, the router handles END triggers locally */
+ xrc->end_notify = xive_router_end_notify;
}
static const TypeInfo xive_router_info = {
Re: [PATCH v2] accel: Remove HAX accelerator
On 31/08/2023 10.20, Philippe Mathieu-Daudé wrote:
HAX is deprecated since commits 73741fda6c ("MAINTAINERS: Abort
HAXM maintenance") and 90c167a1da ("docs/about/deprecated: Mark
HAXM in QEMU as deprecated"), released in v8.0.0.
Per the latest HAXM release (v7.8 [*]), the latest QEMU supported
is v7.2:
Note: Up to this release, HAXM supports QEMU from 2.9.0 to 7.2.0.
The next commit (https://github.com/intel/haxm/commit/da1b8ec072)
added:
HAXM v7.8.0 is our last release and we will not accept
pull requests or respond to issues after this.
It became very hard to build and test HAXM. Its previous
maintainers made it clear they won't help. It doesn't seem to be
a very good use of QEMU maintainers to spend their time in a dead
project. Save our time by removing this orphan zombie code.
[*] https://github.com/intel/haxm/releases/tag/v7.8.0
Reviewed-by: Richard Henderson
Acked-by: Markus Armbruster
Signed-off-by: Philippe Mathieu-Daudé
---
I plan to commit this in my next PR.
Yes, please!
Reviewed-by: Thomas Huth
Re: [PATCH v2 1/2] hw/riscv/virt.c: fix non-KVM --enable-debug build
On Wed, Aug 30, 2023 at 10:35:02AM -0300, Daniel Henrique Barboza wrote:
> A build with --enable-debug and without KVM will fail as follows:
>
> /usr/bin/ld: libqemu-riscv64-softmmu.fa.p/hw_riscv_virt.c.o: in function
> `virt_machine_init':
> ./qemu/build/../hw/riscv/virt.c:1465: undefined reference to
> `kvm_riscv_aia_create'
>
> This happens because the code block with "if virt_use_kvm_aia(s)" isn't
> being ignored by the debug build, resulting in an undefined reference to
> a KVM only function.
>
> Add a 'kvm_enabled()' conditional together with virt_use_kvm_aia() will
> make the compiler crop the kvm_riscv_aia_create() call entirely from a
> non-KVM build. Note that adding the 'kvm_enabled()' conditional inside
> virt_use_kvm_aia() won't fix the build because this function would need
> to be inlined multiple times to make the compiler zero out the entire
> block.
>
> While we're at it, use kvm_enabled() in all instances where
> virt_use_kvm_aia() is checked to allow the compiler to elide these other
> kvm-only instances as well.
>
> Suggested-by: Richard Henderson
> Fixes: dbdb99948e ("target/riscv: select KVM AIA in riscv virt machine")
> Signed-off-by: Daniel Henrique Barboza
> ---
> hw/riscv/virt.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index 388e52a294..3b259b9305 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -782,7 +782,7 @@ static void create_fdt_sockets(RISCVVirtState *s, const
> MemMapEntry *memmap,
> }
>
> /* KVM AIA only has one APLIC instance */
> -if (virt_use_kvm_aia(s)) {
> +if (kvm_enabled() && virt_use_kvm_aia(s)) {
> create_fdt_socket_aplic(s, memmap, 0,
> msi_m_phandle, msi_s_phandle, phandle,
> &intc_phandles[0], xplic_phandles,
> @@ -808,7 +808,7 @@ static void create_fdt_sockets(RISCVVirtState *s, const
> MemMapEntry *memmap,
>
> g_free(intc_phandles);
>
> -if (virt_use_kvm_aia(s)) {
> +if (kvm_enabled() && virt_use_kvm_aia(s)) {
> *irq_mmio_phandle = xplic_phandles[0];
> *irq_virtio_phandle = xplic_phandles[0];
> *irq_pcie_phandle = xplic_phandles[0];
> @@ -1461,7 +1461,7 @@ static void virt_machine_init(MachineState *machine)
> }
> }
>
> -if (virt_use_kvm_aia(s)) {
> +if (kvm_enabled() && virt_use_kvm_aia(s)) {
> kvm_riscv_aia_create(machine, IMSIC_MMIO_GROUP_MIN_SHIFT,
> VIRT_IRQCHIP_NUM_SOURCES, VIRT_IRQCHIP_NUM_MSIS,
> memmap[VIRT_APLIC_S].base,
> --
> 2.41.0
>
>
I think I'd prefer
/* We need this inlined for debug (-O0) builds */
static inline QEMU_ALWAYS_INLINE bool virt_use_kvm_aia(RISCVVirtState *s)
{
return kvm_enabled() && kvm_irqchip_in_kernel() && s->aia_type ==
VIRT_AIA_TYPE_APLIC_IMSIC;
}
assuming that works.
Either way,
Reviewed-by: Andrew Jones
Thanks,
drew
Re: [PATCH v2 2/2] hw/intc/riscv_aplic.c fix non-KVM --enable-debug build
On Wed, Aug 30, 2023 at 10:35:03AM -0300, Daniel Henrique Barboza wrote:
> Commit 6df0b37e2ab breaks a --enable-debug build in a non-KVM
> environment with the following error:
>
> /usr/bin/ld: libqemu-riscv64-softmmu.fa.p/hw_intc_riscv_aplic.c.o: in
> function `riscv_kvm_aplic_request':
> ./qemu/build/../hw/intc/riscv_aplic.c:486: undefined reference to
> `kvm_set_irq'
> collect2: error: ld returned 1 exit status
>
> This happens because the debug build will poke into the
> 'if (is_kvm_aia(aplic->msimode))' block and fail to find a reference to
> the KVM only function riscv_kvm_aplic_request().
>
> There are multiple solutions to fix this. We'll go with the same
> solution from the previous patch, i.e. add a kvm_enabled() conditional
> to filter out the block. But there's a catch: riscv_kvm_aplic_request()
> is a local function that would end up being used if the compiler crops
> the block, and this won't work. Quoting Richard Henderson's explanation
> in [1]:
>
> "(...) the compiler won't eliminate entire unused functions with -O0"
>
> We'll solve it by moving riscv_kvm_aplic_request() to kvm.c and add its
> declaration in kvm_riscv.h, where all other KVM specific public
> functions are already declared. Other archs handles KVM specific code in
> this manner and we expect to do the same from now on.
>
> [1]
> https://lore.kernel.org/qemu-riscv/d2f1ad02-eb03-138f-9d08-db676deee...@linaro.org/
>
> Signed-off-by: Daniel Henrique Barboza
> ---
> hw/intc/riscv_aplic.c| 8 ++--
> target/riscv/kvm.c | 5 +
> target/riscv/kvm_riscv.h | 1 +
> 3 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/hw/intc/riscv_aplic.c b/hw/intc/riscv_aplic.c
> index 592c3ce768..99aae8ccbe 100644
> --- a/hw/intc/riscv_aplic.c
> +++ b/hw/intc/riscv_aplic.c
> @@ -32,6 +32,7 @@
> #include "target/riscv/cpu.h"
> #include "sysemu/sysemu.h"
> #include "sysemu/kvm.h"
> +#include "kvm_riscv.h"
> #include "migration/vmstate.h"
>
> #define APLIC_MAX_IDC (1UL << 14)
> @@ -481,11 +482,6 @@ static uint32_t riscv_aplic_idc_claimi(RISCVAPLICState
> *aplic, uint32_t idc)
> return topi;
> }
>
> -static void riscv_kvm_aplic_request(void *opaque, int irq, int level)
> -{
> -kvm_set_irq(kvm_state, irq, !!level);
> -}
> -
> static void riscv_aplic_request(void *opaque, int irq, int level)
> {
> bool update = false;
> @@ -840,7 +836,7 @@ static void riscv_aplic_realize(DeviceState *dev, Error
> **errp)
> * have IRQ lines delegated by their parent APLIC.
> */
> if (!aplic->parent) {
> -if (is_kvm_aia(aplic->msimode)) {
> +if (kvm_enabled() && is_kvm_aia(aplic->msimode)) {
> qdev_init_gpio_in(dev, riscv_kvm_aplic_request, aplic->num_irqs);
> } else {
> qdev_init_gpio_in(dev, riscv_aplic_request, aplic->num_irqs);
> diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c
> index faee8536ef..ac28a70723 100644
> --- a/target/riscv/kvm.c
> +++ b/target/riscv/kvm.c
> @@ -46,6 +46,11 @@
> #include "sysemu/runstate.h"
> #include "hw/riscv/numa.h"
>
> +void riscv_kvm_aplic_request(void *opaque, int irq, int level)
> +{
> +kvm_set_irq(kvm_state, irq, !!level);
> +}
> +
> static uint64_t kvm_riscv_reg_id(CPURISCVState *env, uint64_t type,
> uint64_t idx)
> {
> diff --git a/target/riscv/kvm_riscv.h b/target/riscv/kvm_riscv.h
> index 7d4b7c60e2..de8c209ebc 100644
> --- a/target/riscv/kvm_riscv.h
> +++ b/target/riscv/kvm_riscv.h
> @@ -26,5 +26,6 @@ void kvm_riscv_aia_create(MachineState *machine, uint64_t
> group_shift,
>uint64_t aia_irq_num, uint64_t aia_msi_num,
>uint64_t aplic_base, uint64_t imsic_base,
>uint64_t guest_num);
> +void riscv_kvm_aplic_request(void *opaque, int irq, int level);
>
> #endif
> --
> 2.41.0
>
>
I'd also try the always_inline trick with is_kvm_aia(), particularly
because now we're inconsistent with how it's used. In two of the three
places it's called we don't guard it with kvm_enabled().
But, I'm also mostly OK with this, so
Reviewed-by: Andrew Jones
Thanks,
drew
Re: [PATCH 02/10] meson: update unsupported host/CPU messages
On Thu, Aug 31, 2023 at 10:20:26AM +0200, Paolo Bonzini wrote: > On Tue, Aug 29, 2023 at 12:34 PM Daniel P. Berrangé > wrote: > > I think I agree wrt to CPUs, but in the case of OS I think > > it is fairly accurate as-is. > > Ok, I wanted to leave out the "*intends* to remove support" part, > which is too strong; but I agree that keeping some kind of "support > may go away in future releases unless you act" is a good idea. Yeah, making the language a little more fuzzy would be ok. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH v2 01/12] build: Only define OS_OBJECT_USE_OBJC with gcc
On 2023/08/31 17:12, Philippe Mathieu-Daudé wrote: On 30/8/23 18:14, Alexander Graf wrote: Recent versions of macOS use clang instead of gcc. The OS_OBJECT_USE_OBJC define is only necessary when building with gcc. Let's not define it when building with clang. With this patch, I can successfully include GCD headers in QEMU when building with clang. Signed-off-by: Alexander Graf --- meson.build | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/meson.build b/meson.build index 98e68ef0b1..0d6a0015a1 100644 --- a/meson.build +++ b/meson.build @@ -224,7 +224,9 @@ qemu_ldflags = [] if targetos == 'darwin' # Disable attempts to use ObjectiveC features in os/object.h since they # won't work when we're compiling with gcc as a C compiler. - qemu_common_flags += '-DOS_OBJECT_USE_OBJC=0' + if compiler.get_id() == 'gcc' + qemu_common_flags += '-DOS_OBJECT_USE_OBJC=0' + endif elif targetos == 'solaris' # needed for CMSG_ macros in sys/socket.h qemu_common_flags += '-D_XOPEN_SOURCE=600' Reviewed-by: Philippe Mathieu-Daudé Defining OS_OBJECT_USE_OBJC does not look like a proper solution. Looking at os/object.h, it seems OS_OBJECT_USE_OBJC is defined as 0 when: !defined(OS_OBJECT_HAVE_OBJC_SUPPORT) && (!defined(__OBJC__) || defined(__OBJC_GC__)) This means OS_OBJECT_USE_OBJC is always 0 if Objective-C is disabled. I also confirmed os/object.h will not use Objective-C features when compiled as C code on clang with the following command: clang -E -x -c - < EOF If compilation fails with GCC when not defining OS_OBJECT_USE_OBJC, it probably means GCC incorrectly treats C code as Objective-C and that is the problem we should solve. I cannot confirm this theory however since I have only an Apple Silicon Mac that is incompatible with GCC. Regards, Akihiko Odaki
Re: [PATCH v2 01/12] build: Only define OS_OBJECT_USE_OBJC with gcc
On 31.08.23 10:53, Akihiko Odaki wrote: On 2023/08/31 17:12, Philippe Mathieu-Daudé wrote: On 30/8/23 18:14, Alexander Graf wrote: Recent versions of macOS use clang instead of gcc. The OS_OBJECT_USE_OBJC define is only necessary when building with gcc. Let's not define it when building with clang. With this patch, I can successfully include GCD headers in QEMU when building with clang. Signed-off-by: Alexander Graf --- meson.build | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/meson.build b/meson.build index 98e68ef0b1..0d6a0015a1 100644 --- a/meson.build +++ b/meson.build @@ -224,7 +224,9 @@ qemu_ldflags = [] if targetos == 'darwin' # Disable attempts to use ObjectiveC features in os/object.h since they # won't work when we're compiling with gcc as a C compiler. - qemu_common_flags += '-DOS_OBJECT_USE_OBJC=0' + if compiler.get_id() == 'gcc' + qemu_common_flags += '-DOS_OBJECT_USE_OBJC=0' + endif elif targetos == 'solaris' # needed for CMSG_ macros in sys/socket.h qemu_common_flags += '-D_XOPEN_SOURCE=600' Reviewed-by: Philippe Mathieu-Daudé Defining OS_OBJECT_USE_OBJC does not look like a proper solution. Looking at os/object.h, it seems OS_OBJECT_USE_OBJC is defined as 0 when: !defined(OS_OBJECT_HAVE_OBJC_SUPPORT) && (!defined(__OBJC__) || defined(__OBJC_GC__)) This means OS_OBJECT_USE_OBJC is always 0 if Objective-C is disabled. I also confirmed os/object.h will not use Objective-C features when compiled as C code on clang with the following command: clang -E -x -c - < EOF If compilation fails with GCC when not defining OS_OBJECT_USE_OBJC, it probably means GCC incorrectly treats C code as Objective-C and that is the problem we should solve. I cannot confirm this theory however since I have only an Apple Silicon Mac that is incompatible with GCC. My take on this was to make the gcc hack be a "legacy" thing that we put into its own corner, so that in a few years we can just drop it altogether. I don't really think it's worth wasting much time on this workaround and its potential compatibility with old macOS versions. Alex Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879
Re: [PATCH 4/4] ppc/xive: Add support for the PC MMIOs
On 8/31/23 09:57, Frederic Barrat wrote:
On 29/08/2023 16:32, Cédric Le Goater wrote:
The XIVE interrupt contoller maintains various fields on interrupt
targets in a structure called NVT. Each unit has a NVT cache, backed
by RAM.
When the NVT structure is not local (in RAM) to the chip, the XIVE
interrupt controller forwards the memory operation to the owning chip
using the PC MMIO region configured for this purpose. QEMU does not
need to be so precise since software shouldn't perform any of these
operations. The model implementation is simplified to return the RAM
address of the NVT structure which is then used by pnv_xive_vst_write
or read to perform the operation in RAM.
Remove the last use of pnv_xive_get_remote().
Signed-off-by: Cédric Le Goater
-
Nice cleanup
Well, it is not perfect (I was lazy in implementing all the ops) but,
at least, the model is now using all addresses set by FW in the VSD
structures (VSD_MODE_FORWARD).
Thanks,
C.
Reviewed-by: Frederic Barrat
Fred
hw/intc/pnv_xive.c | 84 ++
1 file changed, 48 insertions(+), 36 deletions(-)
diff --git a/hw/intc/pnv_xive.c b/hw/intc/pnv_xive.c
index aae5cb6f607b..9b10e905195a 100644
--- a/hw/intc/pnv_xive.c
+++ b/hw/intc/pnv_xive.c
@@ -84,28 +84,6 @@ static uint8_t pnv_xive_block_id(PnvXive *xive)
return blk;
}
-/*
- * Remote access to controllers. HW uses MMIOs. For now, a simple scan
- * of the chips is good enough.
- *
- * TODO: Block scope support
- */
-static PnvXive *pnv_xive_get_remote(uint8_t blk)
-{
- PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
- int i;
-
- for (i = 0; i < pnv->num_chips; i++) {
- Pnv9Chip *chip9 = PNV9_CHIP(pnv->chips[i]);
- PnvXive *xive = &chip9->xive;
-
- if (pnv_xive_block_id(xive) == blk) {
- return xive;
- }
- }
- return NULL;
-}
-
/*
* VST accessors for SBE, EAT, ENDT, NVT
*
@@ -209,6 +187,42 @@ static uint64_t pnv_xive_vst_addr_indirect(PnvXive *xive,
uint32_t type,
return pnv_xive_vst_addr_direct(xive, type, vsd, (idx % vst_per_page));
}
+/*
+ * This is a simplified model of operation forwarding on a remote IC.
+ *
+ * A PC MMIO address is built to identify the NVT structure. The load
+ * on the remote IC will return the address of the structure in RAM,
+ * which will then be used by pnv_xive_vst_write/read to perform the
+ * RAM operation.
+ */
+static uint64_t pnv_xive_vst_addr_remote(PnvXive *xive, uint32_t type,
+ uint64_t vsd, uint8_t blk,
+ uint32_t idx)
+{
+ const XiveVstInfo *info = &vst_infos[type];
+ uint64_t remote_addr = vsd & VSD_ADDRESS_MASK;
+ uint64_t vst_addr;
+ MemTxResult result;
+
+ if (type != VST_TSEL_VPDT) {
+ xive_error(xive, "VST: invalid access on remote VST %s %x/%x !?",
+ info->name, blk, idx);
+ return 0;
+ }
+
+ remote_addr |= idx << xive->pc_shift;
+
+ vst_addr = address_space_ldq_be(&address_space_memory, remote_addr,
+ MEMTXATTRS_UNSPECIFIED, &result);
+ if (result != MEMTX_OK) {
+ xive_error(xive, "VST: read failed at @0x%" HWADDR_PRIx
+ " for NVT %x/%x\n", remote_addr, blk, idx);
+ return 0;
+ }
+
+ return vst_addr;
+}
+
static uint64_t pnv_xive_vst_addr(PnvXive *xive, uint32_t type, uint8_t blk,
uint32_t idx)
{
@@ -225,14 +239,7 @@ static uint64_t pnv_xive_vst_addr(PnvXive *xive, uint32_t
type, uint8_t blk,
/* Remote VST access */
if (GETFIELD(VSD_MODE, vsd) == VSD_MODE_FORWARD) {
- if (type != VST_TSEL_VPDT) {
- xive_error(xive, "VST: invalid access on remote VST %s %x/%x !?",
- info->name, blk, idx);
- return 0;
- }
- xive = pnv_xive_get_remote(blk);
-
- return xive ? pnv_xive_vst_addr(xive, type, blk, idx) : 0;
+ return pnv_xive_vst_addr_remote(xive, type, vsd, blk, idx);
}
if (VSD_INDIRECT & vsd) {
@@ -1785,16 +1792,20 @@ static const MemoryRegionOps pnv_xive_vc_ops = {
};
/*
- * Presenter Controller MMIO region. The Virtualization Controller
- * updates the IPB in the NVT table when required. Not modeled.
+ * Presenter Controller MMIO region. Points to the NVT sets.
+ *
+ * HW implements all possible mem ops to the underlying NVT structure
+ * but QEMU does not need to be so precise. The model implementation
+ * simply returns the RAM address of the NVT structure which is then
+ * used by pnv_xive_vst_write/read to perform the RAM operation.
*/
-static uint64_t pnv_xive_pc_read(void *opaque, hwaddr addr,
- unsigned size)
+static uint64_t pnv_xive_pc_read(void *opaque, hwaddr offset, unsigned size)
{
PnvXive *xive = PNV_XIVE(opaque);
+ uint32_t nvt_idx = offset >> xive->pc_shift;
+ uint8_t blk = pnv_xive_bl
Re: QEMU features useful for Xen development?
On Thu, 31 Aug 2023 at 01:57, Stefano Stabellini wrote: > As Xen is gaining R52 and R82 support, it would be great to be able to > use QEMU for development and testing there as well, but I don't think > QEMU can emulate EL2 properly for the Cortex-R architecture. We would > need EL2 support in the GIC/timer for R52/R82 as well. We do actually have a Cortex-R52 model which at least in theory should include EL2 support, though as usual with newer QEMU stuff it quite likely has lurking bugs; I'm not sure how much testing it's had. Also there is currently no board model which will work with the Cortex-R52 so it's a bit tricky to use in practice. (What sort of board model would Xen want to use it with?) The Cortex-R82 would be more work, because (unlike the R52) it's AArch64, and we don't have Armv8-R AArch64 support yet, only the AArch32. I haven't looked at whether GIC on R-profile requires any changes from the A-profile GIC; on A-profile obviously we emulate the virtualization support already. > On Cortex-As, in addition to a PCI root complex and an arbitrary PCI > device, SMMUv3 emulation (both stages) and GICv3 ITS are needed to be > able to test PCI Passthrough. However, if I recall correctly SMMUv3 > emulation in QEMU might not be complete enough to enable us to use it. Yeah, at the moment the SMMU emulation supports stage 1 and stage 2, but not both at the same time. This is good enough for PCI passthrough with a Linux guest using KVM to pass a device through to a nested Linux guest. thanks -- PMM
Re: [PATCH v2 3/8] machine: Print supported CPU models instead of typenames
On Wed, 30 Aug 2023 17:34:12 +1000
Gavin Shan wrote:
> Hi Igor,
>
> On 8/29/23 19:03, Igor Mammedov wrote:
> > On Tue, 29 Aug 2023 16:28:45 +1000
> > Gavin Shan wrote:
> >> On 8/29/23 00:46, Igor Mammedov wrote:
> >>> On Mon, 31 Jul 2023 15:07:30 +1000
> >>> Gavin Shan wrote:
> On 7/27/23 19:00, Igor Mammedov wrote:
> > On Thu, 27 Jul 2023 15:16:18 +1000
> > Gavin Shan wrote:
> >
> >> On 7/27/23 09:08, Richard Henderson wrote:
> >>> On 7/25/23 17:32, Gavin Shan wrote:
> -static const char *q800_machine_valid_cpu_types[] = {
> +static const char * const q800_machine_valid_cpu_types[] = {
> M68K_CPU_TYPE_NAME("m68040"),
> NULL
> };
> +static const char * const q800_machine_valid_cpu_models[] = {
> + "m68040",
> + NULL
> +};
> >>>
> >>> I really don't like this replication.
> >>>
> >>
> >> Right, it's going to be lots of replications, but gives much
> >> flexibility.
> >> There are 21 targets and we don't have fixed pattern for the mapping
> >> between
> >> CPU model name and CPU typename. I'm summarizing the used patterns
> >> like below.
> >>
> >> 1 All CPU model names are mappinged to fixed CPU typename;
> >
> >plainly spelled it would be: cpu_model name ignored and
> >a cpu type is returned anyways.
> >
> > I'd make this hard error right away, as "junk in => error out"
> > it's clearly user error. I think we don't even have to follow
> > deprecation process for that.
> >
>
> Right, It's not expected behavior to map ambiguous CPU model names to
> the fixed CPU typename.
> >>>
> >>> to be nice we can deprecate those and then later remove.
> >>> (while deprecating make those targets accept typenames)
> >>>
> >>
> >> Lets put it aside for now and revisit it later, so that we can focus on
> >> the conversion from the CPU type name to the CPU model name for now.
> >>
>
> >> 2 CPU model name is same to CPU typename;
> >> 3 CPU model name is alias to CPU typename;
> >> 4 CPU model name is prefix of CPU typename;
> >
> > and some more:
> >5. cpu model names aren't names at all sometimes, and some other
> > CPU property is used. (ppc)
> > This one I'd prefer to get rid of and ppc handling more consistent
> > with other targets, which would need PPC folks to persuaded to drop
> > PVR lookup.
> >
>
> I put this into class 3, meaning the PVRs are regarded as aliases to CPU
> typenames.
> >>>
> >>> with PPC using 'true' aliases, -cpu input is lost after it's translated
> >>> into typename.
> >>> (same for alpha)
> >>>
> >>> it also adds an extra fun with 'max' cpu model but that boils down to
> >>> above statement.
> >>> (same for
> >>> * sh4
> >>> * cris(in user mode only, but you are making sysemu extension, so it
> >>> doesn't count)
> >>> )
> >>> For this class of aliases reverse translation won't yield the same
> >>> result as used -cpu. The only option you have is to store -cpu cpu_model
> >>> somewhere (use qemu_opts??, and then fetch it later to print in error
> >>> message)
> >>>
> >>> x86 has 'aliases' as well, but in reality it creates distinct cpu types
> >>> for each 'alias', so it's possible to do reverse translation.
> >>>
> >>
> >> It's true that '-cpu input' gets lost in these cases. However, the CPU type
> >> name instead of the CPU model name is printed in the error message when the
> >> CPU type is validated in hw/core/machine.c::machine_run_board_init(). It
> >> looks
> >> good to me to print the CPU type name instead of the model name there.
> >
> > It's the same confusing whether it's type or cpumodel it it doesn't match
> > user provided value.
> >
>
> I tend to agree that it's misleading to print the CPU type name in the
> error message in hw/core/machine.c::machine_run_board_init(), where the CPU
> type is validated. qemu_opts may be too heavy for this. It eventually turns
> to a machine's property if @machine_opts_dict is the best place to store
> '-cpu input'. Besides, it doesn't fit for another case very well, where
> current_machine->cpu_type = machine_class->default_cpu_type if '-cpu input'
> isn't provided by user.
>
> For simplicity, how about to add MachineState::cpu_model? It's initialized to
> cpu_model_from_type(machine_class->default_cpu_type) in qemu_init(), or
> g_strdump(model_pieces[0) in parse_cpu_option().
I'd prefer not bringing cpu_model back to device models
(Machine in this case) after getting rid of it.
> >> Another error message is printed when the CPU model specified in '-cpu
> >> input'
> >> isn't valid. The CPU model has been printed and it looks good either.
> >>
> >> # qemu-system-aarch64 -M virt
Re: [PATCH v2 1/2] hw/riscv/virt.c: fix non-KVM --enable-debug build
On 8/31/23 05:42, Andrew Jones wrote:
On Wed, Aug 30, 2023 at 10:35:02AM -0300, Daniel Henrique Barboza wrote:
A build with --enable-debug and without KVM will fail as follows:
/usr/bin/ld: libqemu-riscv64-softmmu.fa.p/hw_riscv_virt.c.o: in function
`virt_machine_init':
./qemu/build/../hw/riscv/virt.c:1465: undefined reference to
`kvm_riscv_aia_create'
This happens because the code block with "if virt_use_kvm_aia(s)" isn't
being ignored by the debug build, resulting in an undefined reference to
a KVM only function.
Add a 'kvm_enabled()' conditional together with virt_use_kvm_aia() will
make the compiler crop the kvm_riscv_aia_create() call entirely from a
non-KVM build. Note that adding the 'kvm_enabled()' conditional inside
virt_use_kvm_aia() won't fix the build because this function would need
to be inlined multiple times to make the compiler zero out the entire
block.
While we're at it, use kvm_enabled() in all instances where
virt_use_kvm_aia() is checked to allow the compiler to elide these other
kvm-only instances as well.
Suggested-by: Richard Henderson
Fixes: dbdb99948e ("target/riscv: select KVM AIA in riscv virt machine")
Signed-off-by: Daniel Henrique Barboza
---
hw/riscv/virt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index 388e52a294..3b259b9305 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -782,7 +782,7 @@ static void create_fdt_sockets(RISCVVirtState *s, const
MemMapEntry *memmap,
}
/* KVM AIA only has one APLIC instance */
-if (virt_use_kvm_aia(s)) {
+if (kvm_enabled() && virt_use_kvm_aia(s)) {
create_fdt_socket_aplic(s, memmap, 0,
msi_m_phandle, msi_s_phandle, phandle,
&intc_phandles[0], xplic_phandles,
@@ -808,7 +808,7 @@ static void create_fdt_sockets(RISCVVirtState *s, const
MemMapEntry *memmap,
g_free(intc_phandles);
-if (virt_use_kvm_aia(s)) {
+if (kvm_enabled() && virt_use_kvm_aia(s)) {
*irq_mmio_phandle = xplic_phandles[0];
*irq_virtio_phandle = xplic_phandles[0];
*irq_pcie_phandle = xplic_phandles[0];
@@ -1461,7 +1461,7 @@ static void virt_machine_init(MachineState *machine)
}
}
-if (virt_use_kvm_aia(s)) {
+if (kvm_enabled() && virt_use_kvm_aia(s)) {
kvm_riscv_aia_create(machine, IMSIC_MMIO_GROUP_MIN_SHIFT,
VIRT_IRQCHIP_NUM_SOURCES, VIRT_IRQCHIP_NUM_MSIS,
memmap[VIRT_APLIC_S].base,
--
2.41.0
I think I'd prefer
/* We need this inlined for debug (-O0) builds */
static inline QEMU_ALWAYS_INLINE bool virt_use_kvm_aia(RISCVVirtState *s)
{
return kvm_enabled() && kvm_irqchip_in_kernel() && s->aia_type ==
VIRT_AIA_TYPE_APLIC_IMSIC;
}
assuming that works.
I've tried before with 'inline' but not with 'QEMU_ALWAYS_INLINE'. But
unfortunately
it doesn't work too:
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index 3b259b9305..a600d81e77 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -77,9 +77,10 @@
#endif
/* KVM AIA only supports APLIC MSI. APLIC Wired is always emulated by QEMU. */
-static bool virt_use_kvm_aia(RISCVVirtState *s)
+static inline QEMU_ALWAYS_INLINE bool virt_use_kvm_aia(RISCVVirtState *s)
{
-return kvm_irqchip_in_kernel() && s->aia_type == VIRT_AIA_TYPE_APLIC_IMSIC;
+return kvm_enabled() && kvm_irqchip_in_kernel() &&
+ s->aia_type == VIRT_AIA_TYPE_APLIC_IMSIC;
}
static const MemMapEntry virt_memmap[] = {
@@ -782,7 +783,7 @@ static void create_fdt_sockets(RISCVVirtState *s, const
MemMapEntry *memmap,
}
/* KVM AIA only has one APLIC instance */
-if (kvm_enabled() && virt_use_kvm_aia(s)) {
+if (virt_use_kvm_aia(s)) {
create_fdt_socket_aplic(s, memmap, 0,
msi_m_phandle, msi_s_phandle, phandle,
&intc_phandles[0], xplic_phandles,
@@ -808,7 +809,7 @@ static void create_fdt_sockets(RISCVVirtState *s, const
MemMapEntry *memmap,
g_free(intc_phandles);
-if (kvm_enabled() && virt_use_kvm_aia(s)) {
+if (virt_use_kvm_aia(s)) {
*irq_mmio_phandle = xplic_phandles[0];
*irq_virtio_phandle = xplic_phandles[0];
*irq_pcie_phandle = xplic_phandles[0];
@@ -1461,7 +1462,7 @@ static void virt_machine_init(MachineState *machine)
}
}
-if (kvm_enabled() && virt_use_kvm_aia(s)) {
+if (virt_use_kvm_aia(s)) {
kvm_riscv_aia_create(machine, IMSIC_MMIO_GROUP_MIN_SHIFT,
VIRT_IRQCHIP_NUM_SOURCES, VIRT_IRQCHIP_NUM_MSIS,
memmap[VIRT_APLIC_S].base,
Same error:
/libssh.so -lrbd -lrados -lbz2 -lutil -Wl,--end-group
/usr/bin/ld: libqemu-riscv64-softmmu.fa.p/hw_riscv_virt.c.o: in function
`virt_machine_init':
/home/danielhb/work/qemu/build/../hw/riscv/virt.c:1466: undefined refere
[QEMU PATCH v4 03/13] virtio-gpu: hostmem
From: Gerd Hoffmann
Use VIRTIO_GPU_SHM_ID_HOST_VISIBLE as id for virtio-gpu.
Signed-off-by: Antonio Caggiano
Tested-by: Alyssa Ross
Tested-by: Akihiko Odaki
Acked-by: Michael S. Tsirkin
Reviewed-by: Akihiko Odaki
Signed-off-by: Huang Rui
---
This patch is already under review as part of the "rutabaga_gfx + gfxstream"
series (already in v13) and has been included here because of dependency.
hw/display/virtio-gpu-pci.c| 14 ++
hw/display/virtio-gpu.c| 1 +
hw/display/virtio-vga.c| 33 -
include/hw/virtio/virtio-gpu.h | 5 +
4 files changed, 44 insertions(+), 9 deletions(-)
diff --git a/hw/display/virtio-gpu-pci.c b/hw/display/virtio-gpu-pci.c
index 93f214ff58..da6a99f038 100644
--- a/hw/display/virtio-gpu-pci.c
+++ b/hw/display/virtio-gpu-pci.c
@@ -33,6 +33,20 @@ static void virtio_gpu_pci_base_realize(VirtIOPCIProxy
*vpci_dev, Error **errp)
DeviceState *vdev = DEVICE(g);
int i;
+if (virtio_gpu_hostmem_enabled(g->conf)) {
+vpci_dev->msix_bar_idx = 1;
+vpci_dev->modern_mem_bar_idx = 2;
+memory_region_init(&g->hostmem, OBJECT(g), "virtio-gpu-hostmem",
+ g->conf.hostmem);
+pci_register_bar(&vpci_dev->pci_dev, 4,
+ PCI_BASE_ADDRESS_SPACE_MEMORY |
+ PCI_BASE_ADDRESS_MEM_PREFETCH |
+ PCI_BASE_ADDRESS_MEM_TYPE_64,
+ &g->hostmem);
+virtio_pci_add_shm_cap(vpci_dev, 4, 0, g->conf.hostmem,
+ VIRTIO_GPU_SHM_ID_HOST_VISIBLE);
+}
+
virtio_pci_force_virtio_1(vpci_dev);
if (!qdev_realize(vdev, BUS(&vpci_dev->bus), errp)) {
return;
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index bbd5c6561a..48ef0d9fad 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1509,6 +1509,7 @@ static Property virtio_gpu_properties[] = {
256 * MiB),
DEFINE_PROP_BIT("blob", VirtIOGPU, parent_obj.conf.flags,
VIRTIO_GPU_FLAG_BLOB_ENABLED, false),
+DEFINE_PROP_SIZE("hostmem", VirtIOGPU, parent_obj.conf.hostmem, 0),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/hw/display/virtio-vga.c b/hw/display/virtio-vga.c
index e6fb0aa876..c8552ff760 100644
--- a/hw/display/virtio-vga.c
+++ b/hw/display/virtio-vga.c
@@ -115,17 +115,32 @@ static void virtio_vga_base_realize(VirtIOPCIProxy
*vpci_dev, Error **errp)
pci_register_bar(&vpci_dev->pci_dev, 0,
PCI_BASE_ADDRESS_MEM_PREFETCH, &vga->vram);
-/*
- * Configure virtio bar and regions
- *
- * We use bar #2 for the mmio regions, to be compatible with stdvga.
- * virtio regions are moved to the end of bar #2, to make room for
- * the stdvga mmio registers at the start of bar #2.
- */
-vpci_dev->modern_mem_bar_idx = 2;
-vpci_dev->msix_bar_idx = 4;
vpci_dev->modern_io_bar_idx = 5;
+if (!virtio_gpu_hostmem_enabled(g->conf)) {
+/*
+ * Configure virtio bar and regions
+ *
+ * We use bar #2 for the mmio regions, to be compatible with stdvga.
+ * virtio regions are moved to the end of bar #2, to make room for
+ * the stdvga mmio registers at the start of bar #2.
+ */
+vpci_dev->modern_mem_bar_idx = 2;
+vpci_dev->msix_bar_idx = 4;
+} else {
+vpci_dev->msix_bar_idx = 1;
+vpci_dev->modern_mem_bar_idx = 2;
+memory_region_init(&g->hostmem, OBJECT(g), "virtio-gpu-hostmem",
+ g->conf.hostmem);
+pci_register_bar(&vpci_dev->pci_dev, 4,
+ PCI_BASE_ADDRESS_SPACE_MEMORY |
+ PCI_BASE_ADDRESS_MEM_PREFETCH |
+ PCI_BASE_ADDRESS_MEM_TYPE_64,
+ &g->hostmem);
+virtio_pci_add_shm_cap(vpci_dev, 4, 0, g->conf.hostmem,
+ VIRTIO_GPU_SHM_ID_HOST_VISIBLE);
+}
+
if (!(vpci_dev->flags & VIRTIO_PCI_FLAG_PAGE_PER_VQ)) {
/*
* with page-per-vq=off there is no padding space we can use
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index 8377c365ef..de4f624e94 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -108,12 +108,15 @@ enum virtio_gpu_base_conf_flags {
(_cfg.flags & (1 << VIRTIO_GPU_FLAG_BLOB_ENABLED))
#define virtio_gpu_context_init_enabled(_cfg) \
(_cfg.flags & (1 << VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED))
+#define virtio_gpu_hostmem_enabled(_cfg) \
+(_cfg.hostmem > 0)
struct virtio_gpu_base_conf {
uint32_t max_outputs;
uint32_t flags;
uint32_t xres;
uint32_t yres;
+uint64_t hostmem;
};
struct virtio_gpu_ctrl_command {
@@ -137,6 +140,8 @@ struct VirtIOGPUBase {
int renderer_blocked;
int enable;
+MemoryRegion hostmem;
+
struct virtio_gpu_scanout scano
[QEMU PATCH v4 02/13] virtio-gpu: CONTEXT_INIT feature
From: Antonio Caggiano
The feature can be enabled when a backend wants it.
Signed-off-by: Antonio Caggiano
Signed-off-by: Gurchetan Singh
Tested-by: Alyssa Ross
Tested-by: Akihiko Odaki
Reviewed-by: Marc-André Lureau
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Akihiko Odaki
Signed-off-by: Huang Rui
---
This patch is already under review as part of the "rutabaga_gfx + gfxstream"
series (already in v13) and has been included here because of dependency.
hw/display/virtio-gpu-base.c | 3 +++
include/hw/virtio/virtio-gpu.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c
index ca1fb7b16f..4f2b0ba1f3 100644
--- a/hw/display/virtio-gpu-base.c
+++ b/hw/display/virtio-gpu-base.c
@@ -232,6 +232,9 @@ virtio_gpu_base_get_features(VirtIODevice *vdev, uint64_t
features,
if (virtio_gpu_blob_enabled(g->conf)) {
features |= (1 << VIRTIO_GPU_F_RESOURCE_BLOB);
}
+if (virtio_gpu_context_init_enabled(g->conf)) {
+features |= (1 << VIRTIO_GPU_F_CONTEXT_INIT);
+}
return features;
}
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index 390c4642b8..8377c365ef 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -93,6 +93,7 @@ enum virtio_gpu_base_conf_flags {
VIRTIO_GPU_FLAG_EDID_ENABLED,
VIRTIO_GPU_FLAG_DMABUF_ENABLED,
VIRTIO_GPU_FLAG_BLOB_ENABLED,
+VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED,
};
#define virtio_gpu_virgl_enabled(_cfg) \
@@ -105,6 +106,8 @@ enum virtio_gpu_base_conf_flags {
(_cfg.flags & (1 << VIRTIO_GPU_FLAG_DMABUF_ENABLED))
#define virtio_gpu_blob_enabled(_cfg) \
(_cfg.flags & (1 << VIRTIO_GPU_FLAG_BLOB_ENABLED))
+#define virtio_gpu_context_init_enabled(_cfg) \
+(_cfg.flags & (1 << VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED))
struct virtio_gpu_base_conf {
uint32_t max_outputs;
--
2.34.1
[QEMU PATCH v4 06/13] virtio-gpu: Configure context init for virglrenderer
Configure context init feature flag for virglrenderer.
Originally-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
New patch, result of splitting
[RFC QEMU PATCH 04/18] virtio-gpu: CONTEXT_INIT feature
meson.build | 4
1 file changed, 4 insertions(+)
diff --git a/meson.build b/meson.build
index 98e68ef0b1..ff20d3c249 100644
--- a/meson.build
+++ b/meson.build
@@ -1068,6 +1068,10 @@ if not get_option('virglrenderer').auto() or have_system
or have_vhost_user_gpu
prefix: '#include ',
dependencies: virgl))
endif
+ config_host_data.set('HAVE_VIRGL_CONTEXT_INIT',
+
cc.has_function('virgl_renderer_context_create_with_flags',
+ prefix: '#include ',
+ dependencies: virgl))
endif
blkio = not_found
if not get_option('blkio').auto() or have_block
--
2.34.1
[QEMU PATCH v4 05/13] virtio-gpu: Support context init feature with virglrenderer
Patch "virtio-gpu: CONTEXT_INIT feature" has added the context_init
feature flags.
We would like to enable the feature with virglrenderer, so add to create
virgl renderer context with flags using context_id when valid.
Originally-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
New patch, result of splitting
[RFC QEMU PATCH 04/18] virtio-gpu: CONTEXT_INIT feature
hw/display/virtio-gpu-virgl.c | 13 +++--
hw/display/virtio-gpu.c | 2 ++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 8bb7a2c21f..312953ec16 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -106,8 +106,17 @@ static void virgl_cmd_context_create(VirtIOGPU *g,
trace_virtio_gpu_cmd_ctx_create(cc.hdr.ctx_id,
cc.debug_name);
-virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen,
- cc.debug_name);
+if (cc.context_init) {
+#ifdef HAVE_VIRGL_CONTEXT_INIT
+virgl_renderer_context_create_with_flags(cc.hdr.ctx_id,
+ cc.context_init,
+ cc.nlen,
+ cc.debug_name);
+return;
+#endif
+}
+
+virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen, cc.debug_name);
}
static void virgl_cmd_context_destroy(VirtIOGPU *g,
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 3e658f1fef..a66cbd9930 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1506,6 +1506,8 @@ static Property virtio_gpu_properties[] = {
DEFINE_PROP_BIT("blob", VirtIOGPU, parent_obj.conf.flags,
VIRTIO_GPU_FLAG_BLOB_ENABLED, false),
DEFINE_PROP_SIZE("hostmem", VirtIOGPU, parent_obj.conf.hostmem, 0),
+DEFINE_PROP_BIT("context_init", VirtIOGPU, parent_obj.conf.flags,
+VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED, false),
DEFINE_PROP_END_OF_LIST(),
};
--
2.34.1
[QEMU PATCH v4 00/13] Support blob memory and venus on qemu
Hi all, Antonio Caggiano made the venus with QEMU on KVM platform last September[1]. This series are inherited from his original work to support the features of context init, hostmem, resource uuid, and blob resources for venus. At March of this year, we sent out the V1 version[2] for the review. But those series are included both xen and virtio gpu. Right now, we would like to divide into two parts, one is to continue the Antonio's work to upstream virtio-gpu support for blob memory and venus, and another is to upstream xen specific patches. This series is focusing on virtio-gpu, so we are marking as V4 version here to continue Antonio's patches[1]. And we will send xen specific patches separately, because they are hypervisor specific. Besides of QEMU, these supports also included virglrenderer[3][4] and mesa[5][6] as well. Right now, virglrenderer and mesa parts are all accepted by upstream. In this qemu version, we try to address the concerns around not proper cleanup during blob resource unmap and unref. Appreciate it if you have any commments. [1] https://lore.kernel.org/qemu-devel/20220926142422.22325-1-antonio.caggi...@collabora.com/ [2] V1: https://lore.kernel.org/qemu-devel/20230312092244.451465-1-ray.hu...@amd.com [3] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1068 [4] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1180 [5] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22108 [6] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23680 Please note the first 4 patches 1 -> 4 are inlcuded in these series because the series depends on them and not because we want them to be reviewed since they are already in the process of review through the "rutabaga_gfx + gfxstream" series. - https://lore.kernel.org/qemu-devel/20230829003629.410-1-gurchetansi...@chromium.org/ Changes from V1 to V2 (virtio gpu V4) - Remove unused #include "hw/virtio/virtio-iommu.h" - Add a local function, called virgl_resource_destroy(), that is used to release a vgpu resource on error paths and in resource_unref. - Remove virtio_gpu_virgl_resource_unmap from virtio_gpu_cleanup_mapping(), since this function won't be called on blob resources and also because blob resources are unmapped via virgl_cmd_resource_unmap_blob(). - In virgl_cmd_resource_create_blob(), do proper cleanup in error paths and move QTAILQ_INSERT_HEAD(&g->reslist, res, next) after the resource has been fully initialized. - Memory region has a different life-cycle from virtio gpu resources i.e. cannot be released synchronously along with the vgpu resource. So, here the field "region" was changed to a pointer and is allocated dynamically when the blob is mapped. Also, since the pointer can be used to indicate whether the blob is mapped, the explicite field "mapped" was removed. - In virgl_cmd_resource_map_blob(), add check on the value of res->region, to prevent beeing called twice on the same resource. - Add a patch to enable automatic deallocation of memory regions to resolve use-after-free memory corruption with a reference. References Demo with Venus: - https://static.sched.com/hosted_files/xen2023/3f/xen_summit_2023_virtgpu_demo.mp4 QEMU repository: - https://gitlab.freedesktop.org/rui/qemu-xen/-/commits/upstream-for-virtio-gpu Thanks, Ray Antonio Caggiano (6): virtio-gpu: CONTEXT_INIT feature virtio-gpu: blob prep virtio-gpu: Handle resource blob commands virtio-gpu: Resource UUID virtio-gpu: Support Venus capset virtio-gpu: Initialize Venus Dmitry Osipenko (1): virtio-gpu: Don't require udmabuf when blobs and virgl are enabled Dr. David Alan Gilbert (1): virtio: Add shared memory capability Gerd Hoffmann (1): virtio-gpu: hostmem Huang Rui (3): virtio-gpu: Support context init feature with virglrenderer virtio-gpu: Configure context init for virglrenderer virtio-gpu: Enable virglrenderer render server flag for venus Xenia Ragiadakou (1): softmmu/memory: enable automatic deallocation of memory regions hw/display/trace-events | 1 + hw/display/virtio-gpu-base.c| 5 + hw/display/virtio-gpu-pci.c | 14 + hw/display/virtio-gpu-virgl.c | 270 +++- hw/display/virtio-gpu.c | 61 - hw/display/virtio-vga.c | 33 ++- hw/virtio/virtio-pci.c | 18 ++ include/hw/virtio/virtio-gpu-bswap.h| 15 ++ include/hw/virtio/virtio-gpu.h | 22 ++ include/hw/virtio/virtio-pci.h | 4 + include/standard-headers/linux/virtio_gpu.h | 2 + meson.build | 8 + softmmu/memory.c| 19 +- 13 files changed, 446 insertions(+), 26 deletions(-) -- 2.34.1
[QEMU PATCH v4 07/13] softmmu/memory: enable automatic deallocation of memory regions
From: Xenia Ragiadakou
When the memory region has a different life-cycle from that of her parent,
could be automatically released, once has been unparent and once all of her
references have gone away, via the object's free callback.
However, currently, references to the memory region are held by its owner
without first incrementing the memory region object's reference count.
As a result, the automatic deallocation of the object, not taking into
account those references, results in use-after-free memory corruption.
This patch increases the reference count of the memory region object on
each memory_region_ref() and decreases it on each memory_region_unref().
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Huang Rui
---
New patch
softmmu/memory.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/softmmu/memory.c b/softmmu/memory.c
index 7d9494ce70..0fdd5eebf9 100644
--- a/softmmu/memory.c
+++ b/softmmu/memory.c
@@ -1797,6 +1797,15 @@ Object *memory_region_owner(MemoryRegion *mr)
void memory_region_ref(MemoryRegion *mr)
{
+if (!mr) {
+return;
+}
+
+/* Obtain a reference to prevent the memory region object
+ * from being released under our feet.
+ */
+object_ref(OBJECT(mr));
+
/* MMIO callbacks most likely will access data that belongs
* to the owner, hence the need to ref/unref the owner whenever
* the memory region is in use.
@@ -1807,16 +1816,22 @@ void memory_region_ref(MemoryRegion *mr)
* Memory regions without an owner are supposed to never go away;
* we do not ref/unref them because it slows down DMA sensibly.
*/
-if (mr && mr->owner) {
+if (mr->owner) {
object_ref(mr->owner);
}
}
void memory_region_unref(MemoryRegion *mr)
{
-if (mr && mr->owner) {
+if (!mr) {
+return;
+}
+
+if (mr->owner) {
object_unref(mr->owner);
}
+
+object_unref(OBJECT(mr));
}
uint64_t memory_region_size(MemoryRegion *mr)
--
2.34.1
[QEMU PATCH v4 09/13] virtio-gpu: Handle resource blob commands
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: Dmitry Osipenko
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Huang Rui
---
v1->v2:
- Remove unused #include "hw/virtio/virtio-iommu.h"
- Add a local function, called virgl_resource_destroy(), that is used
to release a vgpu resource on error paths and in resource_unref.
- Remove virtio_gpu_virgl_resource_unmap from virtio_gpu_cleanup_mapping(),
since this function won't be called on blob resources and also because
blob resources are unmapped via virgl_cmd_resource_unmap_blob().
- In virgl_cmd_resource_create_blob(), do proper cleanup in error paths
and move QTAILQ_INSERT_HEAD(&g->reslist, res, next) after the resource
has been fully initialized.
- Memory region has a different life-cycle from virtio gpu resources
i.e. cannot be released synchronously along with the vgpu resource.
So, here the field "region" was changed to a pointer that will be
released automatically once the memory region is unparented and all
of its references have been released.
Also, since the pointer can be used to indicate whether the blob
is mapped, the explicit field "mapped" was removed.
- In virgl_cmd_resource_map_blob(), add check on the value of
res->region, to prevent beeing called twice on the same resource.
- Remove direct references to parent_obj.
- Separate declarations from code.
hw/display/virtio-gpu-virgl.c | 213 +
hw/display/virtio-gpu.c| 4 +-
include/hw/virtio/virtio-gpu.h | 5 +
meson.build| 4 +
4 files changed, 225 insertions(+), 1 deletion(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 312953ec16..17b634d4ee 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -17,6 +17,7 @@
#include "trace.h"
#include "hw/virtio/virtio.h"
#include "hw/virtio/virtio-gpu.h"
+#include "hw/virtio/virtio-gpu-bswap.h"
#include "ui/egl-helpers.h"
@@ -78,9 +79,24 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
virgl_renderer_resource_create(&args, NULL, 0);
}
+static void virgl_resource_destroy(VirtIOGPU *g,
+ struct virtio_gpu_simple_resource *res)
+{
+if (!res)
+return;
+
+QTAILQ_REMOVE(&g->reslist, res, next);
+
+virtio_gpu_cleanup_mapping_iov(g, res->iov, res->iov_cnt);
+g_free(res->addrs);
+
+g_free(res);
+}
+
static void virgl_cmd_resource_unref(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd)
{
+struct virtio_gpu_simple_resource *res;
struct virtio_gpu_resource_unref unref;
struct iovec *res_iovs = NULL;
int num_iovs = 0;
@@ -88,13 +104,22 @@ static void virgl_cmd_resource_unref(VirtIOGPU *g,
VIRTIO_GPU_FILL_CMD(unref);
trace_virtio_gpu_cmd_res_unref(unref.resource_id);
+res = virtio_gpu_find_resource(g, unref.resource_id);
+
virgl_renderer_resource_detach_iov(unref.resource_id,
&res_iovs,
&num_iovs);
if (res_iovs != NULL && num_iovs != 0) {
virtio_gpu_cleanup_mapping_iov(g, res_iovs, num_iovs);
+if (res) {
+res->iov = NULL;
+res->iov_cnt = 0;
+}
}
+
virgl_renderer_resource_unref(unref.resource_id);
+
+virgl_resource_destroy(g, res);
}
static void virgl_cmd_context_create(VirtIOGPU *g,
@@ -426,6 +451,183 @@ static void virgl_cmd_get_capset(VirtIOGPU *g,
g_free(resp);
}
+#ifdef HAVE_VIRGL_RESOURCE_BLOB
+
+static void virgl_cmd_resource_create_blob(VirtIOGPU *g,
+ struct virtio_gpu_ctrl_command *cmd)
+{
+struct virtio_gpu_simple_resource *res;
+struct virtio_gpu_resource_create_blob cblob;
+struct virgl_renderer_resource_create_blob_args virgl_args = { 0 };
+int ret;
+
+VIRTIO_GPU_FILL_CMD(cblob);
+virtio_gpu_create_blob_bswap(&cblob);
+trace_virtio_gpu_cmd_res_create_blob(cblob.resource_id, cblob.size);
+
+if (cblob.resource_id == 0) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: resource id 0 is not allowed\n",
+ __func__);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+return;
+}
+
+res = virtio_gpu_find_resource(g, cblob.resource_id);
+if (res) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: resource already exists %d\n",
+ __func__, cblob.resource_id);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+return;
+}
+
+res = g_new0(struct virtio_gpu_simple_resource, 1);
+if (!res) {
+cmd->error = VI
[QEMU PATCH v4 04/13] virtio-gpu: blob prep
From: Antonio Caggiano
This adds preparatory functions needed to:
- decode blob cmds
- tracking iovecs
Signed-off-by: Antonio Caggiano
Signed-off-by: Dmitry Osipenko
Signed-off-by: Gurchetan Singh
Tested-by: Alyssa Ross
Tested-by: Emmanouil Pitsidianakis
Tested-by: Akihiko Odaki
Reviewed-by: Emmanouil Pitsidianakis
Reviewed-by: Akihiko Odaki
Signed-off-by: Huang Rui
---
This patch is already under review as part of the "rutabaga_gfx + gfxstream"
series (already in v13) and has been included here because of dependency.
hw/display/virtio-gpu.c | 10 +++---
include/hw/virtio/virtio-gpu-bswap.h | 15 +++
include/hw/virtio/virtio-gpu.h | 5 +
3 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 48ef0d9fad..3e658f1fef 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -33,15 +33,11 @@
#define VIRTIO_GPU_VM_VERSION 1
-static struct virtio_gpu_simple_resource*
-virtio_gpu_find_resource(VirtIOGPU *g, uint32_t resource_id);
static struct virtio_gpu_simple_resource *
virtio_gpu_find_check_resource(VirtIOGPU *g, uint32_t resource_id,
bool require_backing,
const char *caller, uint32_t *error);
-static void virtio_gpu_cleanup_mapping(VirtIOGPU *g,
- struct virtio_gpu_simple_resource *res);
static void virtio_gpu_reset_bh(void *opaque);
void virtio_gpu_update_cursor_data(VirtIOGPU *g,
@@ -116,7 +112,7 @@ static void update_cursor(VirtIOGPU *g, struct
virtio_gpu_update_cursor *cursor)
cursor->resource_id ? 1 : 0);
}
-static struct virtio_gpu_simple_resource *
+struct virtio_gpu_simple_resource *
virtio_gpu_find_resource(VirtIOGPU *g, uint32_t resource_id)
{
struct virtio_gpu_simple_resource *res;
@@ -904,8 +900,8 @@ void virtio_gpu_cleanup_mapping_iov(VirtIOGPU *g,
g_free(iov);
}
-static void virtio_gpu_cleanup_mapping(VirtIOGPU *g,
- struct virtio_gpu_simple_resource *res)
+void virtio_gpu_cleanup_mapping(VirtIOGPU *g,
+struct virtio_gpu_simple_resource *res)
{
virtio_gpu_cleanup_mapping_iov(g, res->iov, res->iov_cnt);
res->iov = NULL;
diff --git a/include/hw/virtio/virtio-gpu-bswap.h
b/include/hw/virtio/virtio-gpu-bswap.h
index 637a0585d0..dd1975e2d4 100644
--- a/include/hw/virtio/virtio-gpu-bswap.h
+++ b/include/hw/virtio/virtio-gpu-bswap.h
@@ -70,6 +70,21 @@ virtio_gpu_create_blob_bswap(struct
virtio_gpu_resource_create_blob *cblob)
le64_to_cpus(&cblob->size);
}
+static inline void
+virtio_gpu_map_blob_bswap(struct virtio_gpu_resource_map_blob *mblob)
+{
+virtio_gpu_ctrl_hdr_bswap(&mblob->hdr);
+le32_to_cpus(&mblob->resource_id);
+le64_to_cpus(&mblob->offset);
+}
+
+static inline void
+virtio_gpu_unmap_blob_bswap(struct virtio_gpu_resource_unmap_blob *ublob)
+{
+virtio_gpu_ctrl_hdr_bswap(&ublob->hdr);
+le32_to_cpus(&ublob->resource_id);
+}
+
static inline void
virtio_gpu_scanout_blob_bswap(struct virtio_gpu_set_scanout_blob *ssb)
{
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index de4f624e94..55973e112f 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -257,6 +257,9 @@ void virtio_gpu_base_fill_display_info(VirtIOGPUBase *g,
void virtio_gpu_base_generate_edid(VirtIOGPUBase *g, int scanout,
struct virtio_gpu_resp_edid *edid);
/* virtio-gpu.c */
+struct virtio_gpu_simple_resource *
+virtio_gpu_find_resource(VirtIOGPU *g, uint32_t resource_id);
+
void virtio_gpu_ctrl_response(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd,
struct virtio_gpu_ctrl_hdr *resp,
@@ -275,6 +278,8 @@ int virtio_gpu_create_mapping_iov(VirtIOGPU *g,
uint32_t *niov);
void virtio_gpu_cleanup_mapping_iov(VirtIOGPU *g,
struct iovec *iov, uint32_t count);
+void virtio_gpu_cleanup_mapping(VirtIOGPU *g,
+struct virtio_gpu_simple_resource *res);
void virtio_gpu_process_cmdq(VirtIOGPU *g);
void virtio_gpu_device_realize(DeviceState *qdev, Error **errp);
void virtio_gpu_reset(VirtIODevice *vdev);
--
2.34.1
[QEMU PATCH v4 13/13] virtio-gpu: Enable virglrenderer render server flag for venus
Venus in virglrenderer has required render server support.
Signed-off-by: Huang Rui
---
New patch
hw/display/virtio-gpu-virgl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index c5a62665bd..1ae3e458e2 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -887,7 +887,7 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
}
#endif
-flags |= VIRGL_RENDERER_VENUS;
+flags |= VIRGL_RENDERER_VENUS | VIRGL_RENDERER_RENDER_SERVER;
ret = virgl_renderer_init(g, flags, &virtio_gpu_3d_cbs);
if (ret != 0) {
--
2.34.1
[QEMU PATCH v4 10/13] virtio-gpu: Resource UUID
From: Antonio Caggiano
Enable resource UUID feature and implement command resource assign UUID.
This is done by introducing a hash table to map resource IDs to their
UUIDs.
Signed-off-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
v1->v2:
- Separate declarations from code.
hw/display/trace-events| 1 +
hw/display/virtio-gpu-base.c | 2 ++
hw/display/virtio-gpu-virgl.c | 21 +
hw/display/virtio-gpu.c| 41 ++
include/hw/virtio/virtio-gpu.h | 4
5 files changed, 69 insertions(+)
diff --git a/hw/display/trace-events b/hw/display/trace-events
index 2336a0ca15..54d6894c59 100644
--- a/hw/display/trace-events
+++ b/hw/display/trace-events
@@ -41,6 +41,7 @@ virtio_gpu_cmd_res_create_blob(uint32_t res, uint64_t size)
"res 0x%x, size %" P
virtio_gpu_cmd_res_unref(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_back_attach(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_back_detach(uint32_t res) "res 0x%x"
+virtio_gpu_cmd_res_assign_uuid(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_xfer_toh_2d(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_xfer_toh_3d(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_xfer_fromh_3d(uint32_t res) "res 0x%x"
diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c
index 4f2b0ba1f3..f44388715c 100644
--- a/hw/display/virtio-gpu-base.c
+++ b/hw/display/virtio-gpu-base.c
@@ -236,6 +236,8 @@ virtio_gpu_base_get_features(VirtIODevice *vdev, uint64_t
features,
features |= (1 << VIRTIO_GPU_F_CONTEXT_INIT);
}
+features |= (1 << VIRTIO_GPU_F_RESOURCE_UUID);
+
return features;
}
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 17b634d4ee..1a996a08fc 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -36,6 +36,7 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
{
struct virtio_gpu_resource_create_2d c2d;
struct virgl_renderer_resource_create_args args;
+struct virtio_gpu_simple_resource *res;
VIRTIO_GPU_FILL_CMD(c2d);
trace_virtio_gpu_cmd_res_create_2d(c2d.resource_id, c2d.format,
@@ -53,6 +54,14 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
args.nr_samples = 0;
args.flags = VIRTIO_GPU_RESOURCE_FLAG_Y_0_TOP;
virgl_renderer_resource_create(&args, NULL, 0);
+
+res = g_new0(struct virtio_gpu_simple_resource, 1);
+if (!res) {
+cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY;
+return;
+}
+res->resource_id = c2d.resource_id;
+QTAILQ_INSERT_HEAD(&g->reslist, res, next);
}
static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
@@ -60,6 +69,7 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
{
struct virtio_gpu_resource_create_3d c3d;
struct virgl_renderer_resource_create_args args;
+struct virtio_gpu_simple_resource *res;
VIRTIO_GPU_FILL_CMD(c3d);
trace_virtio_gpu_cmd_res_create_3d(c3d.resource_id, c3d.format,
@@ -77,6 +87,14 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
args.nr_samples = c3d.nr_samples;
args.flags = c3d.flags;
virgl_renderer_resource_create(&args, NULL, 0);
+
+res = g_new0(struct virtio_gpu_simple_resource, 1);
+if (!res) {
+cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY;
+return;
+}
+res->resource_id = c3d.resource_id;
+QTAILQ_INSERT_HEAD(&g->reslist, res, next);
}
static void virgl_resource_destroy(VirtIOGPU *g,
@@ -682,6 +700,9 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
/* TODO add security */
virgl_cmd_ctx_detach_resource(g, cmd);
break;
+case VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID:
+virtio_gpu_resource_assign_uuid(g, cmd);
+break;
case VIRTIO_GPU_CMD_GET_CAPSET_INFO:
virgl_cmd_get_capset_info(g, cmd);
break;
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index cc4c1f81bb..770e4747e3 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -966,6 +966,37 @@ virtio_gpu_resource_detach_backing(VirtIOGPU *g,
virtio_gpu_cleanup_mapping(g, res);
}
+void virtio_gpu_resource_assign_uuid(VirtIOGPU *g,
+ struct virtio_gpu_ctrl_command *cmd)
+{
+struct virtio_gpu_simple_resource *res;
+struct virtio_gpu_resource_assign_uuid assign;
+struct virtio_gpu_resp_resource_uuid resp;
+QemuUUID *uuid = NULL;
+
+VIRTIO_GPU_FILL_CMD(assign);
+virtio_gpu_bswap_32(&assign, sizeof(assign));
+trace_virtio_gpu_cmd_res_assign_uuid(assign.resource_id);
+
+res = virtio_gpu_find_check_resource(g, assign.resource_id, false,
__func__, &cmd->error);
+if (!res) {
+return;
+}
+
+memset(&resp, 0, sizeof(resp));
+resp.hdr.type = VIRTIO_GPU_RESP_OK_RESOURCE_UUID;
+
+uuid = g_hash_table_lookup(g->resource_uuids,
GUINT_TO_POINTER(assign.resource_id));
+if (!uuid) {
+uuid = g_new(QemuUUID, 1);
+qemu_uuid_generate(uui
[QEMU PATCH v4 01/13] virtio: Add shared memory capability
From: "Dr. David Alan Gilbert"
Define a new capability type 'VIRTIO_PCI_CAP_SHARED_MEMORY_CFG' to allow
defining shared memory regions with sizes and offsets of 2^32 and more.
Multiple instances of the capability are allowed and distinguished
by a device-specific 'id'.
Signed-off-by: Dr. David Alan Gilbert
Signed-off-by: Antonio Caggiano
Signed-off-by: Gurchetan Singh
Tested-by: Alyssa Ross
Tested-by: Huang Rui
Tested-by: Akihiko Odaki
Acked-by: Huang Rui
Reviewed-by: Gurchetan Singh
Reviewed-by: Akihiko Odaki
Signed-off-by: Huang Rui
---
This patch is already under review as part of the "rutabaga_gfx + gfxstream"
series (already in v13) and has been included here because of dependency.
hw/virtio/virtio-pci.c | 18 ++
include/hw/virtio/virtio-pci.h | 4
2 files changed, 22 insertions(+)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index edbc0daa18..da8c9ea12d 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1435,6 +1435,24 @@ static int virtio_pci_add_mem_cap(VirtIOPCIProxy *proxy,
return offset;
}
+int virtio_pci_add_shm_cap(VirtIOPCIProxy *proxy,
+ uint8_t bar, uint64_t offset, uint64_t length,
+ uint8_t id)
+{
+struct virtio_pci_cap64 cap = {
+.cap.cap_len = sizeof cap,
+.cap.cfg_type = VIRTIO_PCI_CAP_SHARED_MEMORY_CFG,
+};
+
+cap.cap.bar = bar;
+cap.cap.length = cpu_to_le32(length);
+cap.length_hi = cpu_to_le32(length >> 32);
+cap.cap.offset = cpu_to_le32(offset);
+cap.offset_hi = cpu_to_le32(offset >> 32);
+cap.cap.id = id;
+return virtio_pci_add_mem_cap(proxy, &cap.cap);
+}
+
static uint64_t virtio_pci_common_read(void *opaque, hwaddr addr,
unsigned size)
{
diff --git a/include/hw/virtio/virtio-pci.h b/include/hw/virtio/virtio-pci.h
index ab2051b64b..5a3f182f99 100644
--- a/include/hw/virtio/virtio-pci.h
+++ b/include/hw/virtio/virtio-pci.h
@@ -264,4 +264,8 @@ unsigned virtio_pci_optimal_num_queues(unsigned
fixed_queues);
void virtio_pci_set_guest_notifier_fd_handler(VirtIODevice *vdev, VirtQueue
*vq,
int n, bool assign,
bool with_irqfd);
+
+int virtio_pci_add_shm_cap(VirtIOPCIProxy *proxy, uint8_t bar, uint64_t offset,
+ uint64_t length, uint8_t id);
+
#endif
--
2.34.1
[QEMU PATCH v4 12/13] virtio-gpu: Initialize Venus
From: Antonio Caggiano
Request Venus when initializing VirGL.
Signed-off-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
v1->v2:
- Rebase to latest version
hw/display/virtio-gpu-virgl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 83cd8c8fd0..c5a62665bd 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -887,6 +887,8 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
}
#endif
+flags |= VIRGL_RENDERER_VENUS;
+
ret = virgl_renderer_init(g, flags, &virtio_gpu_3d_cbs);
if (ret != 0) {
error_report("virgl could not be initialized: %d", ret);
--
2.34.1
[QEMU PATCH v4 08/13] virtio-gpu: Don't require udmabuf when blobs and virgl are enabled
From: Dmitry Osipenko
The udmabuf usage is mandatory when virgl is disabled and blobs feature
enabled in the Qemu machine configuration. If virgl and blobs are enabled,
then udmabuf requirement is optional. Since udmabuf isn't widely supported
by a popular Linux distros today, let's relax the udmabuf requirement for
blobs=on,virgl=on. Now, a full-featured virtio-gpu acceleration is
available to Qemu users without a need to have udmabuf available in the
system.
Reviewed-by: Antonio Caggiano
Signed-off-by: Dmitry Osipenko
Signed-off-by: Huang Rui
---
New patch
hw/display/virtio-gpu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index a66cbd9930..5b7a7eab4f 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1361,7 +1361,8 @@ void virtio_gpu_device_realize(DeviceState *qdev, Error
**errp)
VirtIOGPU *g = VIRTIO_GPU(qdev);
if (virtio_gpu_blob_enabled(g->parent_obj.conf)) {
-if (!virtio_gpu_have_udmabuf()) {
+if (!virtio_gpu_virgl_enabled(g->parent_obj.conf) &&
+!virtio_gpu_have_udmabuf()) {
error_setg(errp, "cannot enable blob resources without udmabuf");
return;
}
--
2.34.1
[QEMU PATCH v4 11/13] virtio-gpu: Support Venus capset
From: Antonio Caggiano
Add support for the Venus capset, which enables Vulkan support through
the Venus Vulkan driver for virtio-gpu.
Signed-off-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
hw/display/virtio-gpu-virgl.c | 21 +
include/standard-headers/linux/virtio_gpu.h | 2 ++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 1a996a08fc..83cd8c8fd0 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -437,6 +437,11 @@ static void virgl_cmd_get_capset_info(VirtIOGPU *g,
virgl_renderer_get_cap_set(resp.capset_id,
&resp.capset_max_version,
&resp.capset_max_size);
+} else if (info.capset_index == 2) {
+resp.capset_id = VIRTIO_GPU_CAPSET_VENUS;
+virgl_renderer_get_cap_set(resp.capset_id,
+ &resp.capset_max_version,
+ &resp.capset_max_size);
} else {
resp.capset_max_version = 0;
resp.capset_max_size = 0;
@@ -901,10 +906,18 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g)
{
-uint32_t capset2_max_ver, capset2_max_size;
+uint32_t capset2_max_ver, capset2_max_size, num_capsets;
+num_capsets = 1;
+
virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VIRGL2,
- &capset2_max_ver,
- &capset2_max_size);
+ &capset2_max_ver,
+ &capset2_max_size);
+num_capsets += capset2_max_ver ? 1 : 0;
+
+virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VENUS,
+ &capset2_max_ver,
+ &capset2_max_size);
+num_capsets += capset2_max_size ? 1 : 0;
-return capset2_max_ver ? 2 : 1;
+return num_capsets;
}
diff --git a/include/standard-headers/linux/virtio_gpu.h
b/include/standard-headers/linux/virtio_gpu.h
index 2da48d3d4c..2db643ed8f 100644
--- a/include/standard-headers/linux/virtio_gpu.h
+++ b/include/standard-headers/linux/virtio_gpu.h
@@ -309,6 +309,8 @@ struct virtio_gpu_cmd_submit {
#define VIRTIO_GPU_CAPSET_VIRGL 1
#define VIRTIO_GPU_CAPSET_VIRGL2 2
+/* 3 is reserved for gfxstream */
+#define VIRTIO_GPU_CAPSET_VENUS 4
/* VIRTIO_GPU_CMD_GET_CAPSET_INFO */
struct virtio_gpu_get_capset_info {
--
2.34.1
Re: [QEMU PATCH v4 06/13] virtio-gpu: Configure context init for virglrenderer
On 31/8/23 11:32, Huang Rui wrote:
Configure context init feature flag for virglrenderer.
Originally-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
New patch, result of splitting
[RFC QEMU PATCH 04/18] virtio-gpu: CONTEXT_INIT feature
meson.build | 4
1 file changed, 4 insertions(+)
diff --git a/meson.build b/meson.build
index 98e68ef0b1..ff20d3c249 100644
--- a/meson.build
+++ b/meson.build
@@ -1068,6 +1068,10 @@ if not get_option('virglrenderer').auto() or have_system
or have_vhost_user_gpu
prefix: '#include ',
dependencies: virgl))
endif
+ config_host_data.set('HAVE_VIRGL_CONTEXT_INIT',
+
cc.has_function('virgl_renderer_context_create_with_flags',
+ prefix: '#include ',
+ dependencies: virgl))
Shouldn't this be inverted with previous patch?
Re: [QEMU PATCH v4 05/13] virtio-gpu: Support context init feature with virglrenderer
On 31/8/23 11:32, Huang Rui wrote:
Patch "virtio-gpu: CONTEXT_INIT feature" has added the context_init
feature flags.
We would like to enable the feature with virglrenderer, so add to create
virgl renderer context with flags using context_id when valid.
Originally-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
New patch, result of splitting
[RFC QEMU PATCH 04/18] virtio-gpu: CONTEXT_INIT feature
hw/display/virtio-gpu-virgl.c | 13 +++--
hw/display/virtio-gpu.c | 2 ++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 8bb7a2c21f..312953ec16 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -106,8 +106,17 @@ static void virgl_cmd_context_create(VirtIOGPU *g,
trace_virtio_gpu_cmd_ctx_create(cc.hdr.ctx_id,
cc.debug_name);
-virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen,
- cc.debug_name);
+if (cc.context_init) {
+#ifdef HAVE_VIRGL_CONTEXT_INIT
+virgl_renderer_context_create_with_flags(cc.hdr.ctx_id,
+ cc.context_init,
+ cc.nlen,
+ cc.debug_name);
+return;
+#endif
What happens if someone sets the 'context_init' property but virgl
doesn't have virgl_renderer_context_create_with_flags()? Should we
report an error?
+}
+
+virgl_renderer_context_create(cc.hdr.ctx_id, cc.nlen, cc.debug_name);
}
static void virgl_cmd_context_destroy(VirtIOGPU *g,
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 3e658f1fef..a66cbd9930 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1506,6 +1506,8 @@ static Property virtio_gpu_properties[] = {
DEFINE_PROP_BIT("blob", VirtIOGPU, parent_obj.conf.flags,
VIRTIO_GPU_FLAG_BLOB_ENABLED, false),
DEFINE_PROP_SIZE("hostmem", VirtIOGPU, parent_obj.conf.hostmem, 0),
+DEFINE_PROP_BIT("context_init", VirtIOGPU, parent_obj.conf.flags,
+VIRTIO_GPU_FLAG_CONTEXT_INIT_ENABLED, false),
DEFINE_PROP_END_OF_LIST(),
};
Re: QEMU features useful for Xen development?
Peter Maydell writes: > On Thu, 31 Aug 2023 at 01:57, Stefano Stabellini > wrote: >> As Xen is gaining R52 and R82 support, it would be great to be able to >> use QEMU for development and testing there as well, but I don't think >> QEMU can emulate EL2 properly for the Cortex-R architecture. We would >> need EL2 support in the GIC/timer for R52/R82 as well. > > We do actually have a Cortex-R52 model which at least in theory > should include EL2 support, though as usual with newer QEMU > stuff it quite likely has lurking bugs; I'm not sure how much > testing it's had. Also there is currently no board model which > will work with the Cortex-R52 so it's a bit tricky to use in practice. > (What sort of board model would Xen want to use it with?) We already model a bunch of the mps2/mps3 images so I'm assuming adding the mps3-an536 would be a fairly simple step to do (mps2tz.c is mostly tweaking config values). The question is would it be a useful target for Xen? https://developer.arm.com/documentation/dai0536/latest/ > The Cortex-R82 would be more work, because (unlike the R52) it's > AArch64, and we don't have Armv8-R AArch64 support yet, only the AArch32. > > I haven't looked at whether GIC on R-profile requires any changes > from the A-profile GIC; on A-profile obviously we emulate the > virtualization support already. > >> On Cortex-As, in addition to a PCI root complex and an arbitrary PCI >> device, SMMUv3 emulation (both stages) and GICv3 ITS are needed to be >> able to test PCI Passthrough. We have ITS emulation support and it was recently plumbed into the "sbsa-ref" board as it is needed for higher level SBSA compliance. >> However, if I recall correctly SMMUv3 >> emulation in QEMU might not be complete enough to enable us to use it. > > Yeah, at the moment the SMMU emulation supports stage 1 and stage 2, > but not both at the same time. This is good enough for PCI passthrough > with a Linux guest using KVM to pass a device through to a nested > Linux guest. Is this a missing feature for SMMUv3 or something introduced in the later revisions? We have sketched out the tasks for SMMUv3.2 (https://linaro.atlassian.net/browse/QEMU-558) with a view to whats needed for RME guests to access hardware. However I think there is a lot of other stuff needed specifically for RME including what we do about modelling things like TDISP. Realistically it will be awhile before we get to completing all of that. > > thanks > -- PMM -- Alex Bennée Virtualisation Tech Lead @ Linaro
Re: QEMU features useful for Xen development?
On Thu, 31 Aug 2023 at 10:53, Alex Bennée wrote: > > > Peter Maydell writes: > > > On Thu, 31 Aug 2023 at 01:57, Stefano Stabellini > > wrote: > >> As Xen is gaining R52 and R82 support, it would be great to be able to > >> use QEMU for development and testing there as well, but I don't think > >> QEMU can emulate EL2 properly for the Cortex-R architecture. We would > >> need EL2 support in the GIC/timer for R52/R82 as well. > > > > We do actually have a Cortex-R52 model which at least in theory > > should include EL2 support, though as usual with newer QEMU > > stuff it quite likely has lurking bugs; I'm not sure how much > > testing it's had. Also there is currently no board model which > > will work with the Cortex-R52 so it's a bit tricky to use in practice. > > (What sort of board model would Xen want to use it with?) > > We already model a bunch of the mps2/mps3 images so I'm assuming adding > the mps3-an536 would be a fairly simple step to do (mps2tz.c is mostly > tweaking config values). The question is would it be a useful target for > Xen? All our MPS2/MPS3 boards are M-profile. That means we have the device models for all the interesting devices on the board, but it would be simpler to write the an536 board model separately. (In particular, the M-profile boards are wrappers around an "ARMSSE" sort-of-like-an-SoC component; there's no equivalent for the Cortex-R52.) > https://developer.arm.com/documentation/dai0536/latest/ > > > The Cortex-R82 would be more work, because (unlike the R52) it's > > AArch64, and we don't have Armv8-R AArch64 support yet, only the AArch32. > > > > I haven't looked at whether GIC on R-profile requires any changes > > from the A-profile GIC; on A-profile obviously we emulate the > > virtualization support already. > > > >> On Cortex-As, in addition to a PCI root complex and an arbitrary PCI > >> device, SMMUv3 emulation (both stages) and GICv3 ITS are needed to be > >> able to test PCI Passthrough. > > We have ITS emulation support and it was recently plumbed into the > "sbsa-ref" board as it is needed for higher level SBSA compliance. > > >> However, if I recall correctly SMMUv3 > >> emulation in QEMU might not be complete enough to enable us to use it. > > > > Yeah, at the moment the SMMU emulation supports stage 1 and stage 2, > > but not both at the same time. This is good enough for PCI passthrough > > with a Linux guest using KVM to pass a device through to a nested > > Linux guest. > > Is this a missing feature for SMMUv3 or something introduced in the > later revisions? It's a missing feature. The SMMUv3 spec allows an implementation to implement stage 1, stage 2 or both. We started with just a stage-1-only implementation because Linux doesn't need any more. Stage-2-only just landed recently. Nobody's looked at both-stages yet. thanks -- PMM
Re: [PATCH] pci: SLT must be RO
W dniu 30.08.2023 o 23:48, Michael S. Tsirkin pisze:
current code sets PCI_SEC_LATENCY_TIMER to WO, but for
pcie to pcie bridges it must be RO 0 according to
pci express spec which says:
This register does not apply to PCI Express. It must be read-only
and hardwired to 00h. For PCI Express to PCI/PCI-X Bridges, refer to the
[PCIe-to-PCI-PCI-X-Bridge] for requirements for this register.
also, fix typo in comment where it's make writeable - this typo
is likely what prevented us noticing we violate this requirement
in the 1st place.
Reported-by: Marcin Juszkiewicz
Signed-off-by: Michael S. Tsirkin
---
Marcin, could you pls test this patch with virt-8.1 and latest?
Thanks a lot!
Tested-by: Marcin Juszkiewicz
sbsa-ref: PASS
virt: PASS
virt-8.1: FAIL (as expected)
virt-8.0: FAIL (as expected)
./code/qemu/build/aarch64-softmmu/qemu-system-aarch64 \
-machine virt \
-m 4096 \
-cpu neoverse-n1 \
-smp 2 \
-drive if=pflash,format=raw,file=QEMU_EFI.fd \
-drive if=pflash,format=raw,file=QEMU_EFI-vars.fd \
-drive file=fat:rw:$PWD/disks/virtual/,format=raw \
-device pcie-root-port,id=root30,chassis=30,slot=0 \
-device igb,bus=root30 \
-device qemu-xhci,id=usb \
-device bochs-display \
-device e1000e \
-nographic \
-usb \
-device usb-kbd \
-device usb-tablet \
-monitor telnet::45454,server,nowait \
-serial stdio
include/hw/pci/pci_bridge.h | 3 +++
hw/core/machine.c | 5 -
hw/pci/pci.c| 2 +-
hw/pci/pci_bridge.c | 14 ++
4 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/include/hw/pci/pci_bridge.h b/include/hw/pci/pci_bridge.h
index ea54a81a15..5cd452115a 100644
--- a/include/hw/pci/pci_bridge.h
+++ b/include/hw/pci/pci_bridge.h
@@ -77,6 +77,9 @@ struct PCIBridge {
pci_map_irq_fn map_irq;
const char *bus_name;
+
+/* SLT is RO for PCIE to PCIE bridges, but old QEMU versions had it RW */
+bool pcie_writeable_slt_bug;
};
#define PCI_BRIDGE_DEV_PROP_CHASSIS_NR "chassis_nr"
diff --git a/hw/core/machine.c b/hw/core/machine.c
index da699cf4e1..76743e3b31 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -32,6 +32,7 @@
#include "qemu/error-report.h"
#include "sysemu/qtest.h"
#include "hw/pci/pci.h"
+#include "hw/pci/pci_bridge.h"
#include "hw/mem/nvdimm.h"
#include "migration/global_state.h"
#include "migration/vmstate.h"
@@ -39,7 +40,9 @@
#include "hw/virtio/virtio.h"
#include "hw/virtio/virtio-pci.h"
-GlobalProperty hw_compat_8_1[] = {};
+GlobalProperty hw_compat_8_1[] = {
+{ TYPE_PCI_BRIDGE, "x-pci-express-writeable-slt-bug", "true" },
+};
const size_t hw_compat_8_1_len = G_N_ELEMENTS(hw_compat_8_1);
GlobalProperty hw_compat_8_0[] = {
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 881d774fb6..b0d21bf43a 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -893,7 +893,7 @@ static void pci_init_w1cmask(PCIDevice *dev)
static void pci_init_mask_bridge(PCIDevice *d)
{
/* PCI_PRIMARY_BUS, PCI_SECONDARY_BUS, PCI_SUBORDINATE_BUS and
- PCI_SEC_LETENCY_TIMER */
+ PCI_SEC_LATENCY_TIMER */
memset(d->wmask + PCI_PRIMARY_BUS, 0xff, 4);
/* base and limit */
diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
index e7b9345615..6a4e38856d 100644
--- a/hw/pci/pci_bridge.c
+++ b/hw/pci/pci_bridge.c
@@ -38,6 +38,7 @@
#include "qapi/error.h"
#include "hw/acpi/acpi_aml_interface.h"
#include "hw/acpi/pci.h"
+#include "hw/qdev-properties.h"
/* PCI bridge subsystem vendor ID helper functions */
#define PCI_SSVID_SIZEOF8
@@ -385,6 +386,11 @@ void pci_bridge_initfn(PCIDevice *dev, const char
*typename)
pci_bridge_region_init(br);
QLIST_INIT(&sec_bus->child);
QLIST_INSERT_HEAD(&parent->child, sec_bus, sibling);
+
+/* For express secondary buses, secondary latency timer is RO 0 */
+if (pci_bus_is_express(sec_bus) && !br->pcie_writeable_slt_bug) {
+dev->wmask[PCI_SEC_LATENCY_TIMER] = 0;
+}
}
/* default qdev clean up function for PCI-to-PCI bridge */
@@ -466,10 +472,18 @@ int pci_bridge_qemu_reserve_cap_init(PCIDevice *dev, int
cap_offset,
return 0;
}
+static Property pci_bridge_properties[] = {
+DEFINE_PROP_BOOL("x-pci-express-writeable-slt-bug", PCIBridge,
+ pcie_writeable_slt_bug, false),
+DEFINE_PROP_END_OF_LIST(),
+};
+
static void pci_bridge_class_init(ObjectClass *klass, void *data)
{
AcpiDevAmlIfClass *adevc = ACPI_DEV_AML_IF_CLASS(klass);
+DeviceClass *k = DEVICE_CLASS(klass);
+device_class_set_props(k, pci_bridge_properties);
adevc->build_dev_aml = build_pci_bridge_aml;
}
Re: [QEMU PATCH v4 07/13] softmmu/memory: enable automatic deallocation of memory regions
On 2023/08/31 18:32, Huang Rui wrote:
From: Xenia Ragiadakou
When the memory region has a different life-cycle from that of her parent,
could be automatically released, once has been unparent and once all of her
references have gone away, via the object's free callback.
However, currently, references to the memory region are held by its owner
without first incrementing the memory region object's reference count.
As a result, the automatic deallocation of the object, not taking into
account those references, results in use-after-free memory corruption.
This patch increases the reference count of the memory region object on
each memory_region_ref() and decreases it on each memory_region_unref().
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Huang Rui
---
New patch
softmmu/memory.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/softmmu/memory.c b/softmmu/memory.c
index 7d9494ce70..0fdd5eebf9 100644
--- a/softmmu/memory.c
+++ b/softmmu/memory.c
@@ -1797,6 +1797,15 @@ Object *memory_region_owner(MemoryRegion *mr)
void memory_region_ref(MemoryRegion *mr)
{
+if (!mr) {
+return;
+}
+
+/* Obtain a reference to prevent the memory region object
+ * from being released under our feet.
+ */
+object_ref(OBJECT(mr));
+
/* MMIO callbacks most likely will access data that belongs
* to the owner, hence the need to ref/unref the owner whenever
* the memory region is in use.
@@ -1807,16 +1816,22 @@ void memory_region_ref(MemoryRegion *mr)
* Memory regions without an owner are supposed to never go away;
* we do not ref/unref them because it slows down DMA sensibly.
*/
The collapsed comment says:
> The memory region is a child of its owner. As long as the
> owner doesn't call unparent itself on the memory region,
> ref-ing the owner will also keep the memory region alive.
> Memory regions without an owner are supposed to never go away;
> we do not ref/unref them because it slows down DMA sensibly.
It contradicts with this patch.
-if (mr && mr->owner) {
+if (mr->owner) {
object_ref(mr->owner);
}
}
void memory_region_unref(MemoryRegion *mr)
{
-if (mr && mr->owner) {
+if (!mr) {
+return;
+}
+
+if (mr->owner) {
object_unref(mr->owner);
}
+
+object_unref(OBJECT(mr));
}
uint64_t memory_region_size(MemoryRegion *mr)
Re: [PATCH 01/20] target/riscv: introduce TCG AccelCPUClass
On Fri, Aug 25, 2023 at 10:08:34AM -0300, Daniel Henrique Barboza wrote:
> target/riscv/cpu.c needs to handle all possible accelerators (TCG and
> KVM at this moment) during both init() and realize() time. This forces
> us to resort to a lot of "if tcg" and "if kvm" throughout the code,
> which isn't wrong, but can get cluttered over time. Splitting
> acceleration specific code from cpu.c to its own file will help to
> declutter the existing code and it will also make it easier to support
> KVM/TCG only builds in the future.
>
> We'll start by adding a new subdir called 'tcg' and a new file called
> 'tcg-cpu.c'. This file will be used to introduce a new accelerator class
> for TCG acceleration in RISC-V, allowing us to center all TCG exclusive
> code in its file instead of using 'cpu.c' for everything. This design is
> inpired by the work Claudio Fontana did in x86 a few years ago in commit
> f5cc5a5c1 ("i386: split cpu accelerators from cpu.c, using
> AccelCPUClass").
>
> To avoid moving too much code at once we'll start by adding the new file
> and TCG AccelCPUClass declaration. The 'class_init' from the accel class
> will init 'tcg_ops', relieving the common riscv_cpu_class_init() from
> doing it.
>
> 'riscv_tcg_ops' is being exported from 'cpu.c' for now to avoid having
> to deal with moving code and files around right now. We'll focus on
> decoupling the realize() logic first.
>
> Signed-off-by: Daniel Henrique Barboza
> ---
> target/riscv/cpu.c | 5 +---
> target/riscv/cpu.h | 4 +++
> target/riscv/meson.build | 2 ++
> target/riscv/tcg/meson.build | 2 ++
> target/riscv/tcg/tcg-cpu.c | 57
> 5 files changed, 66 insertions(+), 4 deletions(-)
> create mode 100644 target/riscv/tcg/meson.build
> create mode 100644 target/riscv/tcg/tcg-cpu.c
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 21ebdbf084..38dcbc4dd2 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -2275,9 +2275,7 @@ static const struct SysemuCPUOps riscv_sysemu_ops = {
> };
> #endif
>
> -#include "hw/core/tcg-cpu-ops.h"
> -
> -static const struct TCGCPUOps riscv_tcg_ops = {
> +const struct TCGCPUOps riscv_tcg_ops = {
> .initialize = riscv_translate_init,
> .synchronize_from_tb = riscv_cpu_synchronize_from_tb,
> .restore_state_to_opc = riscv_restore_state_to_opc,
> @@ -2436,7 +2434,6 @@ static void riscv_cpu_class_init(ObjectClass *c, void
> *data)
> #endif
> cc->gdb_arch_name = riscv_gdb_arch_name;
> cc->gdb_get_dynamic_xml = riscv_gdb_get_dynamic_xml;
> -cc->tcg_ops = &riscv_tcg_ops;
>
> object_class_property_add(c, "mvendorid", "uint32", cpu_get_mvendorid,
>cpu_set_mvendorid, NULL, NULL);
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index 577abcd724..b84b62f84e 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -707,6 +707,10 @@ enum riscv_pmu_event_idx {
> RISCV_PMU_EVENT_CACHE_ITLB_PREFETCH_MISS = 0x10021,
> };
>
> +/* Export tcg_ops until we move everything to tcg/tcg-cpu.c */
> +#include "hw/core/tcg-cpu-ops.h"
> +extern const struct TCGCPUOps riscv_tcg_ops;
> +
> /* CSR function table */
> extern riscv_csr_operations csr_ops[CSR_TABLE_SIZE];
>
> diff --git a/target/riscv/meson.build b/target/riscv/meson.build
> index 660078bda1..f0486183fa 100644
> --- a/target/riscv/meson.build
> +++ b/target/riscv/meson.build
> @@ -38,5 +38,7 @@ riscv_system_ss.add(files(
>'riscv-qmp-cmds.c',
> ))
>
> +subdir('tcg')
> +
> target_arch += {'riscv': riscv_ss}
> target_softmmu_arch += {'riscv': riscv_system_ss}
> diff --git a/target/riscv/tcg/meson.build b/target/riscv/tcg/meson.build
> new file mode 100644
> index 00..061df3d74a
> --- /dev/null
> +++ b/target/riscv/tcg/meson.build
> @@ -0,0 +1,2 @@
> +riscv_ss.add(when: 'CONFIG_TCG', if_true: files(
> + 'tcg-cpu.c'))
> diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
> new file mode 100644
> index 00..1ad27a26aa
> --- /dev/null
> +++ b/target/riscv/tcg/tcg-cpu.c
> @@ -0,0 +1,57 @@
> +/*
> + * riscv TCG cpu class initialization
> + *
> + * Copyright (c) 2023 Ventana Micro Systems Inc.
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, see
>
Re: [PATCH 02/20] target/riscv: move riscv_cpu_realize_tcg() to TCG::cpu_realizefn()
On Fri, Aug 25, 2023 at 10:08:35AM -0300, Daniel Henrique Barboza wrote:
> riscv_cpu_realize_tcg() was added to allow TCG cpus to have a different
> realize() path during the common riscv_cpu_realize(), making it a good
> choice to start moving TCG exclusive code to tcg-cpu.c.
>
> Rename it to tcg_cpu_realizefn() and assign it as a implementation of
> accel::cpu_realizefn(). tcg_cpu_realizefn() will then be called during
> riscv_cpu_realize() via cpu_exec_realizefn(). We'll use a similar
> approach with KVM in the near future.
>
> riscv_cpu_validate_set_extensions() is too big and with too many
> dependencies to be moved in this same patch. We'll do that next.
>
> Signed-off-by: Daniel Henrique Barboza
> ---
> target/riscv/cpu.c | 128 ---
> target/riscv/tcg/tcg-cpu.c | 132 +
> 2 files changed, 132 insertions(+), 128 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 38dcbc4dd2..36c5c6e579 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -23,9 +23,7 @@
> #include "qemu/log.h"
> #include "cpu.h"
> #include "cpu_vendorid.h"
> -#include "pmu.h"
> #include "internals.h"
> -#include "time_helper.h"
> #include "exec/exec-all.h"
> #include "qapi/error.h"
> #include "qapi/visitor.h"
> @@ -1065,29 +1063,6 @@ static void riscv_cpu_validate_v(CPURISCVState *env,
> RISCVCPUConfig *cfg,
> }
> }
>
> -static void riscv_cpu_validate_priv_spec(RISCVCPU *cpu, Error **errp)
> -{
> -CPURISCVState *env = &cpu->env;
> -int priv_version = -1;
> -
> -if (cpu->cfg.priv_spec) {
> -if (!g_strcmp0(cpu->cfg.priv_spec, "v1.12.0")) {
> -priv_version = PRIV_VERSION_1_12_0;
> -} else if (!g_strcmp0(cpu->cfg.priv_spec, "v1.11.0")) {
> -priv_version = PRIV_VERSION_1_11_0;
> -} else if (!g_strcmp0(cpu->cfg.priv_spec, "v1.10.0")) {
> -priv_version = PRIV_VERSION_1_10_0;
> -} else {
> -error_setg(errp,
> - "Unsupported privilege spec version '%s'",
> - cpu->cfg.priv_spec);
> -return;
> -}
> -
> -env->priv_ver = priv_version;
> -}
> -}
> -
> static void riscv_cpu_disable_priv_spec_isa_exts(RISCVCPU *cpu)
> {
> CPURISCVState *env = &cpu->env;
> @@ -1112,33 +1087,6 @@ static void
> riscv_cpu_disable_priv_spec_isa_exts(RISCVCPU *cpu)
> }
> }
>
> -static void riscv_cpu_validate_misa_mxl(RISCVCPU *cpu, Error **errp)
> -{
> -RISCVCPUClass *mcc = RISCV_CPU_GET_CLASS(cpu);
> -CPUClass *cc = CPU_CLASS(mcc);
> -CPURISCVState *env = &cpu->env;
> -
> -/* Validate that MISA_MXL is set properly. */
> -switch (env->misa_mxl_max) {
> -#ifdef TARGET_RISCV64
> -case MXL_RV64:
> -case MXL_RV128:
> -cc->gdb_core_xml_file = "riscv-64bit-cpu.xml";
> -break;
> -#endif
> -case MXL_RV32:
> -cc->gdb_core_xml_file = "riscv-32bit-cpu.xml";
> -break;
> -default:
> -g_assert_not_reached();
> -}
> -
> -if (env->misa_mxl_max != env->misa_mxl) {
> -error_setg(errp, "misa_mxl_max must be equal to misa_mxl");
> -return;
> -}
> -}
> -
> /*
> * Check consistency between chosen extensions while setting
> * cpu->cfg accordingly.
> @@ -1512,74 +1460,6 @@ static void riscv_cpu_finalize_features(RISCVCPU *cpu,
> Error **errp)
> #endif
> }
>
> -static void riscv_cpu_validate_misa_priv(CPURISCVState *env, Error **errp)
> -{
> -if (riscv_has_ext(env, RVH) && env->priv_ver < PRIV_VERSION_1_12_0) {
> -error_setg(errp, "H extension requires priv spec 1.12.0");
> -return;
> -}
> -}
> -
> -static void riscv_cpu_realize_tcg(DeviceState *dev, Error **errp)
> -{
> -RISCVCPU *cpu = RISCV_CPU(dev);
> -CPURISCVState *env = &cpu->env;
> -Error *local_err = NULL;
> -
> -if (object_dynamic_cast(OBJECT(dev), TYPE_RISCV_CPU_HOST)) {
> -error_setg(errp, "'host' CPU is not compatible with TCG
> acceleration");
> -return;
> -}
> -
> -riscv_cpu_validate_misa_mxl(cpu, &local_err);
> -if (local_err != NULL) {
> -error_propagate(errp, local_err);
> -return;
> -}
> -
> -riscv_cpu_validate_priv_spec(cpu, &local_err);
> -if (local_err != NULL) {
> -error_propagate(errp, local_err);
> -return;
> -}
> -
> -riscv_cpu_validate_misa_priv(env, &local_err);
> -if (local_err != NULL) {
> -error_propagate(errp, local_err);
> -return;
> -}
> -
> -if (cpu->cfg.epmp && !cpu->cfg.pmp) {
> -/*
> - * Enhanced PMP should only be available
> - * on harts with PMP support
> - */
> -error_setg(errp, "Invalid configuration: EPMP requires PMP support");
> -return;
> -}
> -
> -riscv_cpu_validate_set_extensions(cpu, &local_err);
> -if (local_err != NULL) {
> -error_propagate(errp, local_err)
Re: [QEMU PATCH v4 09/13] virtio-gpu: Handle resource blob commands
On 2023/08/31 18:32, Huang Rui 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: Dmitry Osipenko
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Huang Rui
---
v1->v2:
- Remove unused #include "hw/virtio/virtio-iommu.h"
- Add a local function, called virgl_resource_destroy(), that is used
to release a vgpu resource on error paths and in resource_unref.
- Remove virtio_gpu_virgl_resource_unmap from virtio_gpu_cleanup_mapping(),
since this function won't be called on blob resources and also because
blob resources are unmapped via virgl_cmd_resource_unmap_blob().
- In virgl_cmd_resource_create_blob(), do proper cleanup in error paths
and move QTAILQ_INSERT_HEAD(&g->reslist, res, next) after the resource
has been fully initialized.
- Memory region has a different life-cycle from virtio gpu resources
i.e. cannot be released synchronously along with the vgpu resource.
So, here the field "region" was changed to a pointer that will be
released automatically once the memory region is unparented and all
of its references have been released.
Also, since the pointer can be used to indicate whether the blob
is mapped, the explicit field "mapped" was removed.
- In virgl_cmd_resource_map_blob(), add check on the value of
res->region, to prevent beeing called twice on the same resource.
- Remove direct references to parent_obj.
- Separate declarations from code.
hw/display/virtio-gpu-virgl.c | 213 +
hw/display/virtio-gpu.c| 4 +-
include/hw/virtio/virtio-gpu.h | 5 +
meson.build| 4 +
4 files changed, 225 insertions(+), 1 deletion(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 312953ec16..17b634d4ee 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -17,6 +17,7 @@
#include "trace.h"
#include "hw/virtio/virtio.h"
#include "hw/virtio/virtio-gpu.h"
+#include "hw/virtio/virtio-gpu-bswap.h"
#include "ui/egl-helpers.h"
@@ -78,9 +79,24 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
virgl_renderer_resource_create(&args, NULL, 0);
}
+static void virgl_resource_destroy(VirtIOGPU *g,
+ struct virtio_gpu_simple_resource *res)
+{
+if (!res)
+return;
+
+QTAILQ_REMOVE(&g->reslist, res, next);
+
+virtio_gpu_cleanup_mapping_iov(g, res->iov, res->iov_cnt);
+g_free(res->addrs);
+
+g_free(res);
+}
+
static void virgl_cmd_resource_unref(VirtIOGPU *g,
struct virtio_gpu_ctrl_command *cmd)
{
+struct virtio_gpu_simple_resource *res;
struct virtio_gpu_resource_unref unref;
struct iovec *res_iovs = NULL;
int num_iovs = 0;
@@ -88,13 +104,22 @@ static void virgl_cmd_resource_unref(VirtIOGPU *g,
VIRTIO_GPU_FILL_CMD(unref);
trace_virtio_gpu_cmd_res_unref(unref.resource_id);
+res = virtio_gpu_find_resource(g, unref.resource_id);
+
virgl_renderer_resource_detach_iov(unref.resource_id,
&res_iovs,
&num_iovs);
if (res_iovs != NULL && num_iovs != 0) {
virtio_gpu_cleanup_mapping_iov(g, res_iovs, num_iovs);
+if (res) {
+res->iov = NULL;
+res->iov_cnt = 0;
+}
}
+
virgl_renderer_resource_unref(unref.resource_id);
+
+virgl_resource_destroy(g, res);
}
static void virgl_cmd_context_create(VirtIOGPU *g,
@@ -426,6 +451,183 @@ static void virgl_cmd_get_capset(VirtIOGPU *g,
g_free(resp);
}
+#ifdef HAVE_VIRGL_RESOURCE_BLOB
+
+static void virgl_cmd_resource_create_blob(VirtIOGPU *g,
+ struct virtio_gpu_ctrl_command *cmd)
+{
+struct virtio_gpu_simple_resource *res;
+struct virtio_gpu_resource_create_blob cblob;
+struct virgl_renderer_resource_create_blob_args virgl_args = { 0 };
+int ret;
+
+VIRTIO_GPU_FILL_CMD(cblob);
+virtio_gpu_create_blob_bswap(&cblob);
+trace_virtio_gpu_cmd_res_create_blob(cblob.resource_id, cblob.size);
+
+if (cblob.resource_id == 0) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: resource id 0 is not allowed\n",
+ __func__);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+return;
+}
+
+res = virtio_gpu_find_resource(g, cblob.resource_id);
+if (res) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: resource already exists %d\n",
+ __func__, cblob.resource_id);
+cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID;
+return;
+}
Re: [PATCH 03/20] target/riscv: move riscv_cpu_validate_set_extensions() to tcg-cpu.c
On Fri, Aug 25, 2023 at 10:08:36AM -0300, Daniel Henrique Barboza wrote:
> This function is the core of the RISC-V validations for TCG CPUs, and it
> has a lot going on.
>
> Functions in cpu.c were made public to allow them to be used by the KVM
> accelerator class later on. 'cpu_cfg_ext_get_min_version()' is notably
> hard to move it to another file due to its dependency with isa_edata_arr[]
> array, thus make it public and use it as is for now.
>
> riscv_cpu_validate_set_extensions() is kept public because it's used by
> csr.c in write_misa().
>
> Signed-off-by: Daniel Henrique Barboza
> ---
> target/riscv/cpu.c | 361 +
> target/riscv/cpu.h | 8 +-
> target/riscv/csr.c | 1 +
> target/riscv/tcg/tcg-cpu.c | 352
> target/riscv/tcg/tcg-cpu.h | 28 +++
> 5 files changed, 393 insertions(+), 357 deletions(-)
> create mode 100644 target/riscv/tcg/tcg-cpu.h
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 36c5c6e579..12cea62ee7 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -163,22 +163,21 @@ static const struct isa_ext_data isa_edata_arr[] = {
> /* Hash that stores user set extensions */
> static GHashTable *multi_ext_user_opts;
>
> -static bool isa_ext_is_enabled(RISCVCPU *cpu, uint32_t ext_offset)
> +bool isa_ext_is_enabled(RISCVCPU *cpu, uint32_t ext_offset)
> {
> bool *ext_enabled = (void *)&cpu->cfg + ext_offset;
>
> return *ext_enabled;
> }
>
> -static void isa_ext_update_enabled(RISCVCPU *cpu, uint32_t ext_offset,
> - bool en)
> +void isa_ext_update_enabled(RISCVCPU *cpu, uint32_t ext_offset, bool en)
> {
> bool *ext_enabled = (void *)&cpu->cfg + ext_offset;
>
> *ext_enabled = en;
> }
>
> -static int cpu_cfg_ext_get_min_version(uint32_t ext_offset)
> +int cpu_cfg_ext_get_min_version(uint32_t ext_offset)
> {
> int i;
>
> @@ -194,38 +193,12 @@ static int cpu_cfg_ext_get_min_version(uint32_t
> ext_offset)
> return PRIV_VERSION_1_10_0;
> }
>
> -static bool cpu_cfg_ext_is_user_set(uint32_t ext_offset)
> +bool cpu_cfg_ext_is_user_set(uint32_t ext_offset)
> {
> return g_hash_table_contains(multi_ext_user_opts,
> GUINT_TO_POINTER(ext_offset));
> }
>
> -static void cpu_cfg_ext_auto_update(RISCVCPU *cpu, uint32_t ext_offset,
> -bool value)
> -{
> -CPURISCVState *env = &cpu->env;
> -bool prev_val = isa_ext_is_enabled(cpu, ext_offset);
> -int min_version;
> -
> -if (prev_val == value) {
> -return;
> -}
> -
> -if (cpu_cfg_ext_is_user_set(ext_offset)) {
> -return;
> -}
> -
> -if (value && env->priv_ver != PRIV_VERSION_LATEST) {
> -/* Do not enable it if priv_ver is older than min_version */
> -min_version = cpu_cfg_ext_get_min_version(ext_offset);
> -if (env->priv_ver < min_version) {
> -return;
> -}
> -}
> -
> -isa_ext_update_enabled(cpu, ext_offset, value);
> -}
> -
> const char * const riscv_int_regnames[] = {
> "x0/zero", "x1/ra", "x2/sp", "x3/gp", "x4/tp", "x5/t0", "x6/t1",
> "x7/t2", "x8/s0", "x9/s1", "x10/a0", "x11/a1", "x12/a2", "x13/a3",
> @@ -1024,46 +997,7 @@ static void riscv_cpu_disas_set_info(CPUState *s,
> disassemble_info *info)
> }
> }
>
> -static void riscv_cpu_validate_v(CPURISCVState *env, RISCVCPUConfig *cfg,
> - Error **errp)
> -{
> -if (!is_power_of_2(cfg->vlen)) {
> -error_setg(errp, "Vector extension VLEN must be power of 2");
> -return;
> -}
> -if (cfg->vlen > RV_VLEN_MAX || cfg->vlen < 128) {
> -error_setg(errp,
> - "Vector extension implementation only supports VLEN "
> - "in the range [128, %d]", RV_VLEN_MAX);
> -return;
> -}
> -if (!is_power_of_2(cfg->elen)) {
> -error_setg(errp, "Vector extension ELEN must be power of 2");
> -return;
> -}
> -if (cfg->elen > 64 || cfg->elen < 8) {
> -error_setg(errp,
> - "Vector extension implementation only supports ELEN "
> - "in the range [8, 64]");
> -return;
> -}
> -if (cfg->vext_spec) {
> -if (!g_strcmp0(cfg->vext_spec, "v1.0")) {
> -env->vext_ver = VEXT_VERSION_1_00_0;
> -} else {
> -error_setg(errp, "Unsupported vector spec version '%s'",
> - cfg->vext_spec);
> -return;
> -}
> -} else if (env->vext_ver == 0) {
> -qemu_log("vector version is not specified, "
> - "use the default value v1.0\n");
> -
> -env->vext_ver = VEXT_VERSION_1_00_0;
> -}
> -}
> -
> -static void riscv_cpu_disable_priv_spec_isa_exts(RISCVCPU *cpu)
> +void riscv_cpu_disable_priv_spec_isa_exts(RISCVCPU *cpu)
> {
> CPURIS
Re: [QEMU PATCH v4 10/13] virtio-gpu: Resource UUID
On 2023/08/31 18:32, Huang Rui wrote:
From: Antonio Caggiano
Enable resource UUID feature and implement command resource assign UUID.
This is done by introducing a hash table to map resource IDs to their
UUIDs.
The hash table does not seem to be stored during migration.
Signed-off-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
v1->v2:
- Separate declarations from code.
hw/display/trace-events| 1 +
hw/display/virtio-gpu-base.c | 2 ++
hw/display/virtio-gpu-virgl.c | 21 +
hw/display/virtio-gpu.c| 41 ++
include/hw/virtio/virtio-gpu.h | 4
5 files changed, 69 insertions(+)
diff --git a/hw/display/trace-events b/hw/display/trace-events
index 2336a0ca15..54d6894c59 100644
--- a/hw/display/trace-events
+++ b/hw/display/trace-events
@@ -41,6 +41,7 @@ virtio_gpu_cmd_res_create_blob(uint32_t res, uint64_t size) "res
0x%x, size %" P
virtio_gpu_cmd_res_unref(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_back_attach(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_back_detach(uint32_t res) "res 0x%x"
+virtio_gpu_cmd_res_assign_uuid(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_xfer_toh_2d(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_xfer_toh_3d(uint32_t res) "res 0x%x"
virtio_gpu_cmd_res_xfer_fromh_3d(uint32_t res) "res 0x%x"
diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c
index 4f2b0ba1f3..f44388715c 100644
--- a/hw/display/virtio-gpu-base.c
+++ b/hw/display/virtio-gpu-base.c
@@ -236,6 +236,8 @@ virtio_gpu_base_get_features(VirtIODevice *vdev, uint64_t
features,
features |= (1 << VIRTIO_GPU_F_CONTEXT_INIT);
}
+features |= (1 << VIRTIO_GPU_F_RESOURCE_UUID);
+
return features;
}
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 17b634d4ee..1a996a08fc 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -36,6 +36,7 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
{
struct virtio_gpu_resource_create_2d c2d;
struct virgl_renderer_resource_create_args args;
+struct virtio_gpu_simple_resource *res;
VIRTIO_GPU_FILL_CMD(c2d);
trace_virtio_gpu_cmd_res_create_2d(c2d.resource_id, c2d.format,
@@ -53,6 +54,14 @@ static void virgl_cmd_create_resource_2d(VirtIOGPU *g,
args.nr_samples = 0;
args.flags = VIRTIO_GPU_RESOURCE_FLAG_Y_0_TOP;
virgl_renderer_resource_create(&args, NULL, 0);
+
+res = g_new0(struct virtio_gpu_simple_resource, 1);
+if (!res) {
+cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY;
+return;
virglrenderer thinks the resource is alive in such a situation.
+}
+res->resource_id = c2d.resource_id;
+QTAILQ_INSERT_HEAD(&g->reslist, res, next);
}
static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
@@ -60,6 +69,7 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
{
struct virtio_gpu_resource_create_3d c3d;
struct virgl_renderer_resource_create_args args;
+struct virtio_gpu_simple_resource *res;
VIRTIO_GPU_FILL_CMD(c3d);
trace_virtio_gpu_cmd_res_create_3d(c3d.resource_id, c3d.format,
@@ -77,6 +87,14 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
args.nr_samples = c3d.nr_samples;
args.flags = c3d.flags;
virgl_renderer_resource_create(&args, NULL, 0);
+
+res = g_new0(struct virtio_gpu_simple_resource, 1);
+if (!res) {
+cmd->error = VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY;
+return;
+}
+res->resource_id = c3d.resource_id;
+QTAILQ_INSERT_HEAD(&g->reslist, res, next);
}
static void virgl_resource_destroy(VirtIOGPU *g,
@@ -682,6 +700,9 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
/* TODO add security */
virgl_cmd_ctx_detach_resource(g, cmd);
break;
+case VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID:
+virtio_gpu_resource_assign_uuid(g, cmd);
+break;
case VIRTIO_GPU_CMD_GET_CAPSET_INFO:
virgl_cmd_get_capset_info(g, cmd);
break;
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index cc4c1f81bb..770e4747e3 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -966,6 +966,37 @@ virtio_gpu_resource_detach_backing(VirtIOGPU *g,
virtio_gpu_cleanup_mapping(g, res);
}
+void virtio_gpu_resource_assign_uuid(VirtIOGPU *g,
+ struct virtio_gpu_ctrl_command *cmd)
+{
+struct virtio_gpu_simple_resource *res;
+struct virtio_gpu_resource_assign_uuid assign;
+struct virtio_gpu_resp_resource_uuid resp;
+QemuUUID *uuid = NULL;
This initialization is unnecessary.
+
+VIRTIO_GPU_FILL_CMD(assign);
+virtio_gpu_bswap_32(&assign, sizeof(assign));
+trace_virtio_gpu_cmd_res_assign_uuid(assign.resource_id);
+
+res = virtio_gpu_find_check_resource(g, assign.resource_id, false, __func__,
&cmd->error);
+if (!res) {
+return;
+}
+
Re: QEMU features useful for Xen development?
Hi Peter/Alex, Appreciate your help. :) On 31/08/2023 11:03, Peter Maydell wrote: CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email. On Thu, 31 Aug 2023 at 10:53, Alex Bennée wrote: Peter Maydell writes: On Thu, 31 Aug 2023 at 01:57, Stefano Stabellini wrote: As Xen is gaining R52 and R82 support, it would be great to be able to use QEMU for development and testing there as well, but I don't think QEMU can emulate EL2 properly for the Cortex-R architecture. We would need EL2 support in the GIC/timer for R52/R82 as well. We do actually have a Cortex-R52 model which at least in theory should include EL2 support, though as usual with newer QEMU stuff it quite likely has lurking bugs; I'm not sure how much testing it's had. Also there is currently no board model which will work with the Cortex-R52 so it's a bit tricky to use in practice. (What sort of board model would Xen want to use it with?) We already model a bunch of the mps2/mps3 images so I'm assuming adding the mps3-an536 would be a fairly simple step to do (mps2tz.c is mostly tweaking config values). The question is would it be a useful target for Xen? All our MPS2/MPS3 boards are M-profile. That means we have the device models for all the interesting devices on the board, but it would be simpler to write the an536 board model separately. (In particular, the M-profile boards are wrappers around an "ARMSSE" sort-of-like-an-SoC component; there's no equivalent for the Cortex-R52.) https://developer.arm.com/documentation/dai0536/latest/ Yes, it will be helpful if Qemu can model this board. We have a downstream port of Xen on R52 (upstreaming is in progress). So, we can test the Qemu model with Xen. Also if all works fine, we might consider adding this to the upstream Xen CI docker. Out of curiosity, are you planning to add Qemu R52 SoC support to Zephyr ? - Ayan The Cortex-R82 would be more work, because (unlike the R52) it's AArch64, and we don't have Armv8-R AArch64 support yet, only the AArch32. I haven't looked at whether GIC on R-profile requires any changes from the A-profile GIC; on A-profile obviously we emulate the virtualization support already. On Cortex-As, in addition to a PCI root complex and an arbitrary PCI device, SMMUv3 emulation (both stages) and GICv3 ITS are needed to be able to test PCI Passthrough. We have ITS emulation support and it was recently plumbed into the "sbsa-ref" board as it is needed for higher level SBSA compliance. However, if I recall correctly SMMUv3 emulation in QEMU might not be complete enough to enable us to use it. Yeah, at the moment the SMMU emulation supports stage 1 and stage 2, but not both at the same time. This is good enough for PCI passthrough with a Linux guest using KVM to pass a device through to a nested Linux guest. Is this a missing feature for SMMUv3 or something introduced in the later revisions? It's a missing feature. The SMMUv3 spec allows an implementation to implement stage 1, stage 2 or both. We started with just a stage-1-only implementation because Linux doesn't need any more. Stage-2-only just landed recently. Nobody's looked at both-stages yet. thanks -- PMM
Re: [PATCH 04/20] target/riscv: move riscv_tcg_ops to tcg-cpu.c
On Fri, Aug 25, 2023 at 10:08:37AM -0300, Daniel Henrique Barboza wrote:
> Move the remaining of riscv_tcg_ops now that we have a working realize()
> implementation.
>
> Signed-off-by: Daniel Henrique Barboza
> ---
> target/riscv/cpu.c | 58 -
> target/riscv/cpu.h | 4 ---
> target/riscv/tcg/tcg-cpu.c | 59 ++
> 3 files changed, 59 insertions(+), 62 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 12cea62ee7..839b83e52a 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -839,24 +839,6 @@ static vaddr riscv_cpu_get_pc(CPUState *cs)
> return env->pc;
> }
>
> -static void riscv_cpu_synchronize_from_tb(CPUState *cs,
> - const TranslationBlock *tb)
> -{
> -if (!(tb_cflags(tb) & CF_PCREL)) {
> -RISCVCPU *cpu = RISCV_CPU(cs);
> -CPURISCVState *env = &cpu->env;
> -RISCVMXL xl = FIELD_EX32(tb->flags, TB_FLAGS, XL);
> -
> -tcg_debug_assert(!(cs->tcg_cflags & CF_PCREL));
> -
> -if (xl == MXL_RV32) {
> -env->pc = (int32_t) tb->pc;
> -} else {
> -env->pc = tb->pc;
> -}
> -}
> -}
> -
> static bool riscv_cpu_has_work(CPUState *cs)
> {
> #ifndef CONFIG_USER_ONLY
> @@ -872,29 +854,6 @@ static bool riscv_cpu_has_work(CPUState *cs)
> #endif
> }
>
> -static void riscv_restore_state_to_opc(CPUState *cs,
> - const TranslationBlock *tb,
> - const uint64_t *data)
> -{
> -RISCVCPU *cpu = RISCV_CPU(cs);
> -CPURISCVState *env = &cpu->env;
> -RISCVMXL xl = FIELD_EX32(tb->flags, TB_FLAGS, XL);
> -target_ulong pc;
> -
> -if (tb_cflags(tb) & CF_PCREL) {
> -pc = (env->pc & TARGET_PAGE_MASK) | data[0];
> -} else {
> -pc = data[0];
> -}
> -
> -if (xl == MXL_RV32) {
> -env->pc = (int32_t)pc;
> -} else {
> -env->pc = pc;
> -}
> -env->bins = data[1];
> -}
> -
> static void riscv_cpu_reset_hold(Object *obj)
> {
> #ifndef CONFIG_USER_ONLY
> @@ -1796,23 +1755,6 @@ static const struct SysemuCPUOps riscv_sysemu_ops = {
> };
> #endif
>
> -const struct TCGCPUOps riscv_tcg_ops = {
> -.initialize = riscv_translate_init,
> -.synchronize_from_tb = riscv_cpu_synchronize_from_tb,
> -.restore_state_to_opc = riscv_restore_state_to_opc,
> -
> -#ifndef CONFIG_USER_ONLY
> -.tlb_fill = riscv_cpu_tlb_fill,
> -.cpu_exec_interrupt = riscv_cpu_exec_interrupt,
> -.do_interrupt = riscv_cpu_do_interrupt,
> -.do_transaction_failed = riscv_cpu_do_transaction_failed,
> -.do_unaligned_access = riscv_cpu_do_unaligned_access,
> -.debug_excp_handler = riscv_cpu_debug_excp_handler,
> -.debug_check_breakpoint = riscv_cpu_debug_check_breakpoint,
> -.debug_check_watchpoint = riscv_cpu_debug_check_watchpoint,
> -#endif /* !CONFIG_USER_ONLY */
> -};
> -
> static bool riscv_cpu_is_dynamic(Object *cpu_obj)
> {
> return object_dynamic_cast(cpu_obj, TYPE_RISCV_DYNAMIC_CPU) != NULL;
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index 721bd0b119..2ac00a0304 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -706,10 +706,6 @@ enum riscv_pmu_event_idx {
> RISCV_PMU_EVENT_CACHE_ITLB_PREFETCH_MISS = 0x10021,
> };
>
> -/* Export tcg_ops until we move everything to tcg/tcg-cpu.c */
> -#include "hw/core/tcg-cpu-ops.h"
> -extern const struct TCGCPUOps riscv_tcg_ops;
> -
> /* used by tcg/tcg-cpu.c*/
> void isa_ext_update_enabled(RISCVCPU *cpu, uint32_t ext_offset, bool en);
> bool cpu_cfg_ext_is_user_set(uint32_t ext_offset);
> diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
> index fb17097bb1..2024c98793 100644
> --- a/target/riscv/tcg/tcg-cpu.c
> +++ b/target/riscv/tcg/tcg-cpu.c
> @@ -26,7 +26,66 @@
> #include "qemu/accel.h"
> #include "qemu/error-report.h"
> #include "hw/core/accel-cpu.h"
> +#include "hw/core/tcg-cpu-ops.h"
> +#include "tcg/tcg.h"
>
> +static void riscv_cpu_synchronize_from_tb(CPUState *cs,
> + const TranslationBlock *tb)
> +{
> +if (!(tb_cflags(tb) & CF_PCREL)) {
> +RISCVCPU *cpu = RISCV_CPU(cs);
> +CPURISCVState *env = &cpu->env;
> +RISCVMXL xl = FIELD_EX32(tb->flags, TB_FLAGS, XL);
> +
> +tcg_debug_assert(!(cs->tcg_cflags & CF_PCREL));
> +
> +if (xl == MXL_RV32) {
> +env->pc = (int32_t) tb->pc;
> +} else {
> +env->pc = tb->pc;
> +}
> +}
> +}
> +
> +static void riscv_restore_state_to_opc(CPUState *cs,
> + const TranslationBlock *tb,
> + const uint64_t *data)
> +{
> +RISCVCPU *cpu = RISCV_CPU(cs);
> +CPURISCVState *env = &cpu->env;
> +RISCVMXL xl = FIELD_EX32(tb->flags, TB_FLAGS, XL);
> +target_ulong pc;
> +
> +
Re: [QEMU PATCH v4 12/13] virtio-gpu: Initialize Venus
Hi Huang,
Thank you for pushing this forward!
On 31/08/2023 11:32, Huang Rui wrote:
From: Antonio Caggiano
Request Venus when initializing VirGL.
Signed-off-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
v1->v2:
- Rebase to latest version
hw/display/virtio-gpu-virgl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 83cd8c8fd0..c5a62665bd 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -887,6 +887,8 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
}
#endif
+flags |= VIRGL_RENDERER_VENUS;
+
VIRGL_RENDERER_VENUS is a symbol only available from virglrenderer 0.9.1
[0] and only if VIRGL_RENDERER_UNSTABLE_APIS is defined.
Luckily for us, VIRGL_RENDERER_UNSTABLE_APIS is defined unconditionally
from virglrenderer 0.9.0 [1], so we could check for that in qemu/meson.build
e.g.
if virgl.version().version_compare('>= 0.9.0')
message('Enabling virglrenderer unstable APIs')
virgl = declare_dependency(compile_args:
'-DVIRGL_RENDERER_UNSTABLE_APIS',
dependencies: virgl)
endif
Also, while testing this with various versions of virglrenderer, I
realized there are no guarantees for Venus backend to be available in
the linked library. Virglrenderer should be built with
-Dvenus_experimental=true, and if that is not the case, the following
virgl_renderer_init would fail for previous versions of virglrenderer or
in case it has not been built with venus support.
I would suggest another approach for that which tries initializing Venus
only if VIRGL_RENDERER_VENUS is actually defined. Then, if it fails
cause virglrenderer has not been built with venus support, try again
falling back to virgl only.
e.g.
#ifdef VIRGL_RENDERER_VENUS
ret = virgl_renderer_init(g, VIRGL_RENDERER_VENUS, &virtio_gpu_3d_cbs);
if (ret != 0) {
warn_report("Failed to initialize virglrenderer with venus:
%d", ret);
warn_report("Falling back to virgl only");
ret = virgl_renderer_init(g, 0, &virtio_gpu_3d_cbs);
}
#else
ret = virgl_renderer_init(g, 0, &virtio_gpu_3d_cbs);
#endif
ret = virgl_renderer_init(g, flags, &virtio_gpu_3d_cbs);
if (ret != 0) {
error_report("virgl could not be initialized: %d", ret);
[0]
https://gitlab.freedesktop.org/virgl/virglrenderer/-/commit/6c31f85330bb4c5aba8b82eba606971e598c6e25
[1]
https://gitlab.freedesktop.org/virgl/virglrenderer/-/commit/491afdc42a49ec6a1b8d7cbc5c97360229002d41
Best regards,
Antonio Caggiano
Re: [QEMU PATCH v4 11/13] virtio-gpu: Support Venus capset
On 2023/08/31 18:32, Huang Rui wrote:
From: Antonio Caggiano
Add support for the Venus capset, which enables Vulkan support through
the Venus Vulkan driver for virtio-gpu.
Signed-off-by: Antonio Caggiano
Signed-off-by: Huang Rui
---
hw/display/virtio-gpu-virgl.c | 21 +
include/standard-headers/linux/virtio_gpu.h | 2 ++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 1a996a08fc..83cd8c8fd0 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -437,6 +437,11 @@ static void virgl_cmd_get_capset_info(VirtIOGPU *g,
virgl_renderer_get_cap_set(resp.capset_id,
&resp.capset_max_version,
&resp.capset_max_size);
+} else if (info.capset_index == 2) {
+resp.capset_id = VIRTIO_GPU_CAPSET_VENUS;
+virgl_renderer_get_cap_set(resp.capset_id,
+ &resp.capset_max_version,
+ &resp.capset_max_size);
} else {
resp.capset_max_version = 0;
resp.capset_max_size = 0;
@@ -901,10 +906,18 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g)
{
-uint32_t capset2_max_ver, capset2_max_size;
+uint32_t capset2_max_ver, capset2_max_size, num_capsets;
+num_capsets = 1;
+
virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VIRGL2,
- &capset2_max_ver,
- &capset2_max_size);
+ &capset2_max_ver,
+ &capset2_max_size);
+num_capsets += capset2_max_ver ? 1 : 0;
+
+virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_VENUS,
+ &capset2_max_ver,
+ &capset2_max_size);
+num_capsets += capset2_max_size ? 1 : 0;
-return capset2_max_ver ? 2 : 1;
+return num_capsets;
}
diff --git a/include/standard-headers/linux/virtio_gpu.h
b/include/standard-headers/linux/virtio_gpu.h
index 2da48d3d4c..2db643ed8f 100644
--- a/include/standard-headers/linux/virtio_gpu.h
+++ b/include/standard-headers/linux/virtio_gpu.h
@@ -309,6 +309,8 @@ struct virtio_gpu_cmd_submit {
#define VIRTIO_GPU_CAPSET_VIRGL 1
#define VIRTIO_GPU_CAPSET_VIRGL2 2
+/* 3 is reserved for gfxstream */
+#define VIRTIO_GPU_CAPSET_VENUS 4
This file is synced with scripts/update-linux-headers.sh and should not
be modified.
/* VIRTIO_GPU_CMD_GET_CAPSET_INFO */
struct virtio_gpu_get_capset_info {
[PULL 04/24] target/arm: When tag memory is not present, set MTE=1
From: Richard Henderson
When the cpu support MTE, but the system does not, reduce cpu
support to user instructions at EL0 instead of completely
disabling MTE. If we encounter a cpu implementation which does
something else, we can revisit this setting.
Signed-off-by: Richard Henderson
Reviewed-by: Peter Maydell
Message-id: 20230811214031.171020-5-richard.hender...@linaro.org
Signed-off-by: Peter Maydell
---
target/arm/cpu.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index fe73fd8af75..23901121ac6 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -2067,12 +2067,13 @@ static void arm_cpu_realizefn(DeviceState *dev, Error
**errp)
#ifndef CONFIG_USER_ONLY
/*
- * Disable the MTE feature bits if we do not have tag-memory
- * provided by the machine.
+ * If we do not have tag-memory provided by the machine,
+ * reduce MTE support to instructions enabled at EL0.
+ * This matches Cortex-A710 BROADCASTMTE input being LOW.
*/
if (cpu->tag_memory == NULL) {
cpu->isar.id_aa64pfr1 =
-FIELD_DP64(cpu->isar.id_aa64pfr1, ID_AA64PFR1, MTE, 0);
+FIELD_DP64(cpu->isar.id_aa64pfr1, ID_AA64PFR1, MTE, 1);
}
#endif
}
--
2.34.1
[PULL 03/24] target/arm: Support more GM blocksizes
From: Richard Henderson
Support all of the easy GM block sizes.
Use direct memory operations, since the pointers are aligned.
While BS=2 (16 bytes, 1 tag) is a legal setting, that requires
an atomic store of one nibble. This is not difficult, but there
is also no point in supporting it until required.
Note that cortex-a710 sets GM blocksize to match its cacheline
size of 64 bytes. I expect many implementations will also
match the cacheline, which makes 16 bytes very unlikely.
Signed-off-by: Richard Henderson
Reviewed-by: Peter Maydell
Message-id: 20230811214031.171020-4-richard.hender...@linaro.org
Signed-off-by: Peter Maydell
---
target/arm/cpu.c| 18 +---
target/arm/tcg/mte_helper.c | 56 +++--
2 files changed, 62 insertions(+), 12 deletions(-)
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index d906d2b1caa..fe73fd8af75 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -2056,16 +2056,26 @@ static void arm_cpu_realizefn(DeviceState *dev, Error
**errp)
ID_PFR1, VIRTUALIZATION, 0);
}
+if (cpu_isar_feature(aa64_mte, cpu)) {
+/*
+ * The architectural range of GM blocksize is 2-6, however qemu
+ * doesn't support blocksize of 2 (see HELPER(ldgm)).
+ */
+if (tcg_enabled()) {
+assert(cpu->gm_blocksize >= 3 && cpu->gm_blocksize <= 6);
+}
+
#ifndef CONFIG_USER_ONLY
-if (cpu->tag_memory == NULL && cpu_isar_feature(aa64_mte, cpu)) {
/*
* Disable the MTE feature bits if we do not have tag-memory
* provided by the machine.
*/
-cpu->isar.id_aa64pfr1 =
-FIELD_DP64(cpu->isar.id_aa64pfr1, ID_AA64PFR1, MTE, 0);
-}
+if (cpu->tag_memory == NULL) {
+cpu->isar.id_aa64pfr1 =
+FIELD_DP64(cpu->isar.id_aa64pfr1, ID_AA64PFR1, MTE, 0);
+}
#endif
+}
if (tcg_enabled()) {
/*
diff --git a/target/arm/tcg/mte_helper.c b/target/arm/tcg/mte_helper.c
index 3640c6e57f5..b23d11563ab 100644
--- a/target/arm/tcg/mte_helper.c
+++ b/target/arm/tcg/mte_helper.c
@@ -428,6 +428,8 @@ uint64_t HELPER(ldgm)(CPUARMState *env, uint64_t ptr)
int gm_bs = env_archcpu(env)->gm_blocksize;
int gm_bs_bytes = 4 << gm_bs;
void *tag_mem;
+uint64_t ret;
+int shift;
ptr = QEMU_ALIGN_DOWN(ptr, gm_bs_bytes);
@@ -443,16 +445,41 @@ uint64_t HELPER(ldgm)(CPUARMState *env, uint64_t ptr)
/*
* The ordering of elements within the word corresponds to
- * a little-endian operation.
+ * a little-endian operation. Computation of shift comes from
+ *
+ * index = address
+ * data = tag
+ *
+ * Because of the alignment of ptr above, BS=6 has shift=0.
+ * All memory operations are aligned. Defer support for BS=2,
+ * requiring insertion or extraction of a nibble, until we
+ * support a cpu that requires it.
*/
switch (gm_bs) {
+case 3:
+/* 32 bytes -> 2 tags -> 8 result bits */
+ret = *(uint8_t *)tag_mem;
+break;
+case 4:
+/* 64 bytes -> 4 tags -> 16 result bits */
+ret = cpu_to_le16(*(uint16_t *)tag_mem);
+break;
+case 5:
+/* 128 bytes -> 8 tags -> 32 result bits */
+ret = cpu_to_le32(*(uint32_t *)tag_mem);
+break;
case 6:
/* 256 bytes -> 16 tags -> 64 result bits */
-return ldq_le_p(tag_mem);
+return cpu_to_le64(*(uint64_t *)tag_mem);
default:
-/* cpu configured with unsupported gm blocksize. */
+/*
+ * CPU configured with unsupported/invalid gm blocksize.
+ * This is detected early in arm_cpu_realizefn.
+ */
g_assert_not_reached();
}
+shift = extract64(ptr, LOG2_TAG_GRANULE, 4) * 4;
+return ret << shift;
}
void HELPER(stgm)(CPUARMState *env, uint64_t ptr, uint64_t val)
@@ -462,6 +489,7 @@ void HELPER(stgm)(CPUARMState *env, uint64_t ptr, uint64_t
val)
int gm_bs = env_archcpu(env)->gm_blocksize;
int gm_bs_bytes = 4 << gm_bs;
void *tag_mem;
+int shift;
ptr = QEMU_ALIGN_DOWN(ptr, gm_bs_bytes);
@@ -478,13 +506,25 @@ void HELPER(stgm)(CPUARMState *env, uint64_t ptr,
uint64_t val)
return;
}
-/*
- * The ordering of elements within the word corresponds to
- * a little-endian operation.
- */
+/* See LDGM for comments on BS and on shift. */
+shift = extract64(ptr, LOG2_TAG_GRANULE, 4) * 4;
+val >>= shift;
switch (gm_bs) {
+case 3:
+/* 32 bytes -> 2 tags -> 8 result bits */
+*(uint8_t *)tag_mem = val;
+break;
+case 4:
+/* 64 bytes -> 4 tags -> 16 result bits */
+*(uint16_t *)tag_mem = cpu_to_le16(val);
+break;
+case 5:
+/* 128 bytes -> 8 tags -> 32 result bits */
+*(uint32_t *)tag_mem = cpu_to_le32(val);
+break;
case 6:
-
[PULL 06/24] target/arm: Apply access checks to neoverse-n1 special registers
From: Richard Henderson
Access to many of the special registers is enabled or disabled
by ACTLR_EL[23], which we implement as constant 0, which means
that all writes outside EL3 should trap.
Signed-off-by: Richard Henderson
Reviewed-by: Peter Maydell
Message-id: 20230811214031.171020-7-richard.hender...@linaro.org
Signed-off-by: Peter Maydell
---
target/arm/cpregs.h| 2 ++
target/arm/helper.c| 4 ++--
target/arm/tcg/cpu64.c | 46 +-
3 files changed, 41 insertions(+), 11 deletions(-)
diff --git a/target/arm/cpregs.h b/target/arm/cpregs.h
index 14785686f64..f1293d16c07 100644
--- a/target/arm/cpregs.h
+++ b/target/arm/cpregs.h
@@ -1077,4 +1077,6 @@ static inline void
define_cortex_a72_a57_a53_cp_reginfo(ARMCPU *cpu) { }
void define_cortex_a72_a57_a53_cp_reginfo(ARMCPU *cpu);
#endif
+CPAccessResult access_tvm_trvm(CPUARMState *, const ARMCPRegInfo *, bool);
+
#endif /* TARGET_ARM_CPREGS_H */
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 4dfc51de351..e3f5a7d2bdc 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -319,8 +319,8 @@ static CPAccessResult access_tpm(CPUARMState *env, const
ARMCPRegInfo *ri,
}
/* Check for traps from EL1 due to HCR_EL2.TVM and HCR_EL2.TRVM. */
-static CPAccessResult access_tvm_trvm(CPUARMState *env, const ARMCPRegInfo *ri,
- bool isread)
+CPAccessResult access_tvm_trvm(CPUARMState *env, const ARMCPRegInfo *ri,
+ bool isread)
{
if (arm_current_el(env) == 1) {
uint64_t trap = isread ? HCR_TRVM : HCR_TVM;
diff --git a/target/arm/tcg/cpu64.c b/target/arm/tcg/cpu64.c
index 00f39d42a8c..bc3db798f09 100644
--- a/target/arm/tcg/cpu64.c
+++ b/target/arm/tcg/cpu64.c
@@ -463,10 +463,30 @@ static void aarch64_a64fx_initfn(Object *obj)
/* TODO: Add A64FX specific HPC extension registers */
}
+static CPAccessResult access_actlr_w(CPUARMState *env, const ARMCPRegInfo *r,
+ bool read)
+{
+if (!read) {
+int el = arm_current_el(env);
+
+/* Because ACTLR_EL2 is constant 0, writes below EL2 trap to EL2. */
+if (el < 2 && arm_is_el2_enabled(env)) {
+return CP_ACCESS_TRAP_EL2;
+}
+/* Because ACTLR_EL3 is constant 0, writes below EL3 trap to EL3. */
+if (el < 3 && arm_feature(env, ARM_FEATURE_EL3)) {
+return CP_ACCESS_TRAP_EL3;
+}
+}
+return CP_ACCESS_OK;
+}
+
static const ARMCPRegInfo neoverse_n1_cp_reginfo[] = {
{ .name = "ATCR_EL1", .state = ARM_CP_STATE_AA64,
.opc0 = 3, .opc1 = 0, .crn = 15, .crm = 7, .opc2 = 0,
- .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
+ .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0,
+ /* Traps and enables are the same as for TCR_EL1. */
+ .accessfn = access_tvm_trvm, .fgt = FGT_TCR_EL1, },
{ .name = "ATCR_EL2", .state = ARM_CP_STATE_AA64,
.opc0 = 3, .opc1 = 4, .crn = 15, .crm = 7, .opc2 = 0,
.access = PL2_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
@@ -481,13 +501,16 @@ static const ARMCPRegInfo neoverse_n1_cp_reginfo[] = {
.access = PL2_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
{ .name = "CPUACTLR_EL1", .state = ARM_CP_STATE_AA64,
.opc0 = 3, .opc1 = 0, .crn = 15, .crm = 1, .opc2 = 0,
- .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
+ .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0,
+ .accessfn = access_actlr_w },
{ .name = "CPUACTLR2_EL1", .state = ARM_CP_STATE_AA64,
.opc0 = 3, .opc1 = 0, .crn = 15, .crm = 1, .opc2 = 1,
- .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
+ .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0,
+ .accessfn = access_actlr_w },
{ .name = "CPUACTLR3_EL1", .state = ARM_CP_STATE_AA64,
.opc0 = 3, .opc1 = 0, .crn = 15, .crm = 1, .opc2 = 2,
- .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
+ .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0,
+ .accessfn = access_actlr_w },
/*
* Report CPUCFR_EL1.SCU as 1, as we do not implement the DSU
* (and in particular its system registers).
@@ -497,7 +520,8 @@ static const ARMCPRegInfo neoverse_n1_cp_reginfo[] = {
.access = PL1_R, .type = ARM_CP_CONST, .resetvalue = 4 },
{ .name = "CPUECTLR_EL1", .state = ARM_CP_STATE_AA64,
.opc0 = 3, .opc1 = 0, .crn = 15, .crm = 1, .opc2 = 4,
- .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0x961563010 },
+ .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0x961563010,
+ .accessfn = access_actlr_w },
{ .name = "CPUPCR_EL3", .state = ARM_CP_STATE_AA64,
.opc0 = 3, .opc1 = 6, .crn = 15, .crm = 8, .opc2 = 1,
.access = PL3_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
@@ -512,16 +536,20 @@ static const ARMCPRegInfo neoverse_n1_cp_reginfo[] = {
.access = PL3_RW, .type = ARM_CP_CO
[PULL 07/24] target/arm: Apply access checks to neoverse-v1 special registers
From: Richard Henderson
There is only one additional EL1 register modeled, which
also needs to use access_actlr_w.
Signed-off-by: Richard Henderson
Reviewed-by: Peter Maydell
Message-id: 20230811214031.171020-8-richard.hender...@linaro.org
Signed-off-by: Peter Maydell
---
target/arm/tcg/cpu64.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/arm/tcg/cpu64.c b/target/arm/tcg/cpu64.c
index bc3db798f09..b0cac05be65 100644
--- a/target/arm/tcg/cpu64.c
+++ b/target/arm/tcg/cpu64.c
@@ -560,7 +560,8 @@ static void define_neoverse_n1_cp_reginfo(ARMCPU *cpu)
static const ARMCPRegInfo neoverse_v1_cp_reginfo[] = {
{ .name = "CPUECTLR2_EL1", .state = ARM_CP_STATE_AA64,
.opc0 = 3, .opc1 = 0, .crn = 15, .crm = 1, .opc2 = 5,
- .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
+ .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0,
+ .accessfn = access_actlr_w },
{ .name = "CPUPPMCR_EL3", .state = ARM_CP_STATE_AA64,
.opc0 = 3, .opc1 = 6, .crn = 15, .crm = 2, .opc2 = 0,
.access = PL3_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
--
2.34.1
[PULL 24/24] hw/arm: Set number of MPU regions correctly for an505, an521, an524
The IoTKit, SSE200 and SSE300 all default to 8 MPU regions. The
MPS2/MPS3 FPGA images don't override these except in the case of
AN547, which uses 16 MPU regions.
Define properties on the ARMSSE object for the MPU regions (using the
same names as the documented RTL configuration settings, and
following the pattern we already have for this device of using
all-caps names as the RTL does), and set them in the board code.
We don't actually need to override the default except on AN547,
but it's simpler code to have the board code set them always
rather than tracking which board subtypes want to set them to
a non-default value separately from what that value is.
Tho overall effect is that for mps2-an505, mps2-an521 and mps3-an524
we now correctly use 8 MPU regions, while mps3-an547 stays at its
current 16 regions.
It's possible some guest code wrongly depended on the previous
incorrectly modeled number of memory regions. (Such guest code
should ideally check the number of regions via the MPU_TYPE
register.) The old behaviour can be obtained with additional
-global arguments to QEMU:
For mps2-an521 and mps2-an524:
-global sse-200.CPU0_MPU_NS=16 -global sse-200.CPU0_MPU_S=16 -global
sse-200.CPU1_MPU_NS=16 -global sse-200.CPU1_MPU_S=16
For mps2-an505:
-global sse-200.CPU0_MPU_NS=16 -global sse-200.CPU0_MPU_S=16
NB that the way the implementation allows this use of -global
is slightly fragile: if the board code explicitly sets the
properties on the sse-200 object, this overrides the -global
command line option. So we rely on:
- the boards that need fixing all happen to use the SSE defaults
- we can write the board code to only set the property if it
is different from the default, rather than having all boards
explicitly set the property
- the board that does need to use a non-default value happens
to need to set it to the same value (16) we previously used
This works, but there are some kinds of refactoring of the
mps2-tz.c code that would break the support for -global here.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1772
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
Message-id: 20230724174335.2150499-4-peter.mayd...@linaro.org
---
include/hw/arm/armsse.h | 5 +
hw/arm/armsse.c | 16
hw/arm/mps2-tz.c| 29 +
3 files changed, 50 insertions(+)
diff --git a/include/hw/arm/armsse.h b/include/hw/arm/armsse.h
index cd0931d0a0b..88b3b759c5a 100644
--- a/include/hw/arm/armsse.h
+++ b/include/hw/arm/armsse.h
@@ -56,6 +56,9 @@
*(matching the hardware) is that for CPU0 in an IoTKit and CPU1 in an
*SSE-200 both are present; CPU0 in an SSE-200 has neither.
*Since the IoTKit has only one CPU, it does not have the CPU1_*
properties.
+ * + QOM properties "CPU0_MPU_NS", "CPU0_MPU_S", "CPU1_MPU_NS" and
"CPU1_MPU_S"
+ *which set the number of MPU regions on the CPUs. If there is only one
+ *CPU the CPU1 properties are not present.
* + Named GPIO inputs "EXP_IRQ" 0..n are the expansion interrupts for CPU 0,
*which are wired to its NVIC lines 32 .. n+32
* + Named GPIO inputs "EXP_CPU1_IRQ" 0..n are the expansion interrupts for
@@ -221,6 +224,8 @@ struct ARMSSE {
uint32_t exp_numirq;
uint32_t sram_addr_width;
uint32_t init_svtor;
+uint32_t cpu_mpu_ns[SSE_MAX_CPUS];
+uint32_t cpu_mpu_s[SSE_MAX_CPUS];
bool cpu_fpu[SSE_MAX_CPUS];
bool cpu_dsp[SSE_MAX_CPUS];
};
diff --git a/hw/arm/armsse.c b/hw/arm/armsse.c
index 0202bad787b..11cd08b6c1e 100644
--- a/hw/arm/armsse.c
+++ b/hw/arm/armsse.c
@@ -85,6 +85,8 @@ static Property iotkit_properties[] = {
DEFINE_PROP_UINT32("init-svtor", ARMSSE, init_svtor, 0x1000),
DEFINE_PROP_BOOL("CPU0_FPU", ARMSSE, cpu_fpu[0], true),
DEFINE_PROP_BOOL("CPU0_DSP", ARMSSE, cpu_dsp[0], true),
+DEFINE_PROP_UINT32("CPU0_MPU_NS", ARMSSE, cpu_mpu_ns[0], 8),
+DEFINE_PROP_UINT32("CPU0_MPU_S", ARMSSE, cpu_mpu_s[0], 8),
DEFINE_PROP_END_OF_LIST()
};
@@ -98,6 +100,10 @@ static Property sse200_properties[] = {
DEFINE_PROP_BOOL("CPU0_DSP", ARMSSE, cpu_dsp[0], false),
DEFINE_PROP_BOOL("CPU1_FPU", ARMSSE, cpu_fpu[1], true),
DEFINE_PROP_BOOL("CPU1_DSP", ARMSSE, cpu_dsp[1], true),
+DEFINE_PROP_UINT32("CPU0_MPU_NS", ARMSSE, cpu_mpu_ns[0], 8),
+DEFINE_PROP_UINT32("CPU0_MPU_S", ARMSSE, cpu_mpu_s[0], 8),
+DEFINE_PROP_UINT32("CPU1_MPU_NS", ARMSSE, cpu_mpu_ns[1], 8),
+DEFINE_PROP_UINT32("CPU1_MPU_S", ARMSSE, cpu_mpu_s[1], 8),
DEFINE_PROP_END_OF_LIST()
};
@@ -109,6 +115,8 @@ static Property sse300_properties[] = {
DEFINE_PROP_UINT32("init-svtor", ARMSSE, init_svtor, 0x1000),
DEFINE_PROP_BOOL("CPU0_FPU", ARMSSE, cpu_fpu[0], true),
DEFINE_PROP_BOOL("CPU0_DSP", ARMSSE, cpu_dsp[0], true),
+DEFINE_PROP_UINT32("CPU0_MPU_NS", ARMSSE, cpu_mpu_ns[0], 8),
+DEFINE_PROP_UINT32("CPU0_MPU_S", ARMSSE, cpu_mpu_s[0], 8),
DEFIN
[PULL 20/24] hw/rtc/aspeed_rtc: Use 64-bit offset for holding time_t difference
In the aspeed_rtc device we store a difference between two time_t
values in an 'int'. This is not really correct when time_t could
be 64 bits. Enlarge the field to 'int64_t'.
This is a migration compatibility break for the aspeed boards.
While we are changing the vmstate, remove the accidental
duplicate of the offset field.
Signed-off-by: Peter Maydell
Reviewed-by: Cédric Le Goater
---
include/hw/rtc/aspeed_rtc.h | 2 +-
hw/rtc/aspeed_rtc.c | 5 ++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/include/hw/rtc/aspeed_rtc.h b/include/hw/rtc/aspeed_rtc.h
index df61e46059e..596dfebb46c 100644
--- a/include/hw/rtc/aspeed_rtc.h
+++ b/include/hw/rtc/aspeed_rtc.h
@@ -18,7 +18,7 @@ struct AspeedRtcState {
qemu_irq irq;
uint32_t reg[0x18];
-int offset;
+int64_t offset;
};
diff --git a/hw/rtc/aspeed_rtc.c b/hw/rtc/aspeed_rtc.c
index f6da7b666d6..fa861e2d494 100644
--- a/hw/rtc/aspeed_rtc.c
+++ b/hw/rtc/aspeed_rtc.c
@@ -136,11 +136,10 @@ static const MemoryRegionOps aspeed_rtc_ops = {
static const VMStateDescription vmstate_aspeed_rtc = {
.name = TYPE_ASPEED_RTC,
-.version_id = 1,
+.version_id = 2,
.fields = (VMStateField[]) {
VMSTATE_UINT32_ARRAY(reg, AspeedRtcState, 0x18),
-VMSTATE_INT32(offset, AspeedRtcState),
-VMSTATE_INT32(offset, AspeedRtcState),
+VMSTATE_INT64(offset, AspeedRtcState),
VMSTATE_END_OF_LIST()
}
};
--
2.34.1
[PULL 02/24] target/arm: Allow cpu to configure GM blocksize
From: Richard Henderson
Previously we hard-coded the blocksize with GMID_EL1_BS.
But the value we choose for -cpu max does not match the
value that cortex-a710 uses.
Mirror the way we handle dcz_blocksize.
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
Message-id: 20230811214031.171020-3-richard.hender...@linaro.org
Signed-off-by: Peter Maydell
---
target/arm/cpu.h | 2 ++
target/arm/internals.h | 6 -
target/arm/tcg/translate.h | 2 ++
target/arm/helper.c| 11 +---
target/arm/tcg/cpu64.c | 1 +
target/arm/tcg/mte_helper.c| 46 ++
target/arm/tcg/translate-a64.c | 5 ++--
7 files changed, 45 insertions(+), 28 deletions(-)
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index a1e604366b2..278cc135c23 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1075,6 +1075,8 @@ struct ArchCPU {
/* DCZ blocksize, in log_2(words), ie low 4 bits of DCZID_EL0 */
uint8_t dcz_blocksize;
+/* GM blocksize, in log_2(words), ie low 4 bits of GMID_EL0 */
+uint8_t gm_blocksize;
uint64_t rvbar_prop; /* Property/input signals. */
diff --git a/target/arm/internals.h b/target/arm/internals.h
index cf13bb94f59..5f5393b25c4 100644
--- a/target/arm/internals.h
+++ b/target/arm/internals.h
@@ -1246,12 +1246,6 @@ void arm_log_exception(CPUState *cs);
#endif /* !CONFIG_USER_ONLY */
-/*
- * The log2 of the words in the tag block, for GMID_EL1.BS.
- * The is the maximum, 256 bytes, which manipulates 64-bits of tags.
- */
-#define GMID_EL1_BS 6
-
/*
* SVE predicates are 1/8 the size of SVE vectors, and cannot use
* the same simd_desc() encoding due to restrictions on size.
diff --git a/target/arm/tcg/translate.h b/target/arm/tcg/translate.h
index d1cacff0b2f..f748ba6f394 100644
--- a/target/arm/tcg/translate.h
+++ b/target/arm/tcg/translate.h
@@ -151,6 +151,8 @@ typedef struct DisasContext {
int8_t btype;
/* A copy of cpu->dcz_blocksize. */
uint8_t dcz_blocksize;
+/* A copy of cpu->gm_blocksize. */
+uint8_t gm_blocksize;
/* True if this page is guarded. */
bool guarded_page;
/* Bottom two bits of XScale c15_cpar coprocessor access control reg */
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 85291d5b8e2..4dfc51de351 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -7748,10 +7748,6 @@ static const ARMCPRegInfo mte_reginfo[] = {
.opc0 = 3, .opc1 = 0, .crn = 1, .crm = 0, .opc2 = 6,
.access = PL1_RW, .accessfn = access_mte,
.fieldoffset = offsetof(CPUARMState, cp15.gcr_el1) },
-{ .name = "GMID_EL1", .state = ARM_CP_STATE_AA64,
- .opc0 = 3, .opc1 = 1, .crn = 0, .crm = 0, .opc2 = 4,
- .access = PL1_R, .accessfn = access_aa64_tid5,
- .type = ARM_CP_CONST, .resetvalue = GMID_EL1_BS },
{ .name = "TCO", .state = ARM_CP_STATE_AA64,
.opc0 = 3, .opc1 = 3, .crn = 4, .crm = 2, .opc2 = 7,
.type = ARM_CP_NO_RAW,
@@ -9342,6 +9338,13 @@ void register_cp_regs_for_features(ARMCPU *cpu)
* then define only a RAZ/WI version of PSTATE.TCO.
*/
if (cpu_isar_feature(aa64_mte, cpu)) {
+ARMCPRegInfo gmid_reginfo = {
+.name = "GMID_EL1", .state = ARM_CP_STATE_AA64,
+.opc0 = 3, .opc1 = 1, .crn = 0, .crm = 0, .opc2 = 4,
+.access = PL1_R, .accessfn = access_aa64_tid5,
+.type = ARM_CP_CONST, .resetvalue = cpu->gm_blocksize,
+};
+define_one_arm_cp_reg(cpu, &gmid_reginfo);
define_arm_cp_regs(cpu, mte_reginfo);
define_arm_cp_regs(cpu, mte_el0_cacheop_reginfo);
} else if (cpu_isar_feature(aa64_mte_insn_reg, cpu)) {
diff --git a/target/arm/tcg/cpu64.c b/target/arm/tcg/cpu64.c
index 8019f00bc3f..4cd73779c80 100644
--- a/target/arm/tcg/cpu64.c
+++ b/target/arm/tcg/cpu64.c
@@ -868,6 +868,7 @@ void aarch64_max_tcg_initfn(Object *obj)
cpu->ctr = 0x80038003; /* 32 byte I and D cacheline size, VIPT icache */
cpu->dcz_blocksize = 7; /* 512 bytes */
#endif
+cpu->gm_blocksize = 6; /* 256 bytes */
cpu->sve_vq.supported = MAKE_64BIT_MASK(0, ARM_MAX_VQ);
cpu->sme_vq.supported = SVE_VQ_POW2_MAP;
diff --git a/target/arm/tcg/mte_helper.c b/target/arm/tcg/mte_helper.c
index 9c64def0816..3640c6e57f5 100644
--- a/target/arm/tcg/mte_helper.c
+++ b/target/arm/tcg/mte_helper.c
@@ -421,46 +421,54 @@ void HELPER(st2g_stub)(CPUARMState *env, uint64_t ptr)
}
}
-#define LDGM_STGM_SIZE (4 << GMID_EL1_BS)
-
uint64_t HELPER(ldgm)(CPUARMState *env, uint64_t ptr)
{
int mmu_idx = cpu_mmu_index(env, false);
uintptr_t ra = GETPC();
+int gm_bs = env_archcpu(env)->gm_blocksize;
+int gm_bs_bytes = 4 << gm_bs;
void *tag_mem;
-ptr = QEMU_ALIGN_DOWN(ptr, LDGM_STGM_SIZE);
+ptr = QEMU_ALIGN_DOWN(ptr, gm_bs_bytes);
/* Trap if accessing an invalid page. */
tag_mem = allocation_tag_mem(env, mmu_idx, ptr, MMU_DATA_LOAD,
-
[PULL 14/24] Refactor i.MX7 processor code
From: Jean-Christophe Dubois
* Add Addr and size definition for all i.MX7 devices in i.MX7 header file.
* Use those newly defined named constants whenever possible.
* Standardize the way we init a familly of unimplemented devices
- SAI
- PWM
- CAN
* Add/rework few comments
Signed-off-by: Jean-Christophe Dubois
Message-id:
59e195d33e4d486a8d131392acd46633c8c10ed7.1692964892.git@tribudubois.net
Reviewed-by: Peter Maydell
Signed-off-by: Peter Maydell
---
include/hw/arm/fsl-imx7.h | 330 --
hw/arm/fsl-imx7.c | 130 ++-
2 files changed, 335 insertions(+), 125 deletions(-)
diff --git a/include/hw/arm/fsl-imx7.h b/include/hw/arm/fsl-imx7.h
index fcce6421c8c..06b2c5e4acf 100644
--- a/include/hw/arm/fsl-imx7.h
+++ b/include/hw/arm/fsl-imx7.h
@@ -25,7 +25,6 @@
#include "hw/misc/imx7_ccm.h"
#include "hw/misc/imx7_snvs.h"
#include "hw/misc/imx7_gpr.h"
-#include "hw/misc/imx6_src.h"
#include "hw/watchdog/wdt_imx2.h"
#include "hw/gpio/imx_gpio.h"
#include "hw/char/imx_serial.h"
@@ -39,6 +38,7 @@
#include "hw/usb/chipidea.h"
#include "cpu.h"
#include "qom/object.h"
+#include "qemu/units.h"
#define TYPE_FSL_IMX7 "fsl-imx7"
OBJECT_DECLARE_SIMPLE_TYPE(FslIMX7State, FSL_IMX7)
@@ -57,6 +57,9 @@ enum FslIMX7Configuration {
FSL_IMX7_NUM_ECSPIS = 4,
FSL_IMX7_NUM_USBS = 3,
FSL_IMX7_NUM_ADCS = 2,
+FSL_IMX7_NUM_SAIS = 3,
+FSL_IMX7_NUM_CANS = 2,
+FSL_IMX7_NUM_PWMS = 4,
};
struct FslIMX7State {
@@ -87,80 +90,106 @@ struct FslIMX7State {
enum FslIMX7MemoryMap {
FSL_IMX7_MMDC_ADDR= 0x8000,
-FSL_IMX7_MMDC_SIZE= 2 * 1024 * 1024 * 1024UL,
+FSL_IMX7_MMDC_SIZE= (2 * GiB),
-FSL_IMX7_GPIO1_ADDR = 0x3020,
-FSL_IMX7_GPIO2_ADDR = 0x3021,
-FSL_IMX7_GPIO3_ADDR = 0x3022,
-FSL_IMX7_GPIO4_ADDR = 0x3023,
-FSL_IMX7_GPIO5_ADDR = 0x3024,
-FSL_IMX7_GPIO6_ADDR = 0x3025,
-FSL_IMX7_GPIO7_ADDR = 0x3026,
+FSL_IMX7_QSPI1_MEM_ADDR = 0x6000,
+FSL_IMX7_QSPI1_MEM_SIZE = (256 * MiB),
-FSL_IMX7_IOMUXC_LPSR_GPR_ADDR = 0x3027,
+FSL_IMX7_PCIE1_MEM_ADDR = 0x4000,
+FSL_IMX7_PCIE1_MEM_SIZE = (256 * MiB),
-FSL_IMX7_WDOG1_ADDR = 0x3028,
-FSL_IMX7_WDOG2_ADDR = 0x3029,
-FSL_IMX7_WDOG3_ADDR = 0x302A,
-FSL_IMX7_WDOG4_ADDR = 0x302B,
+FSL_IMX7_QSPI1_RX_BUF_ADDR= 0x3400,
+FSL_IMX7_QSPI1_RX_BUF_SIZE= (32 * MiB),
-FSL_IMX7_IOMUXC_LPSR_ADDR = 0x302C,
+/* PCIe Peripherals */
+FSL_IMX7_PCIE_REG_ADDR= 0x3380,
-FSL_IMX7_GPT1_ADDR= 0x302D,
-FSL_IMX7_GPT2_ADDR= 0x302E,
-FSL_IMX7_GPT3_ADDR= 0x302F,
-FSL_IMX7_GPT4_ADDR= 0x3030,
+/* MMAP Peripherals */
+FSL_IMX7_DMA_APBH_ADDR= 0x3300,
+FSL_IMX7_DMA_APBH_SIZE= 0x8000,
-FSL_IMX7_IOMUXC_ADDR = 0x3033,
-FSL_IMX7_IOMUXC_GPR_ADDR = 0x3034,
-FSL_IMX7_IOMUXCn_SIZE = 0x1000,
+/* GPV configuration */
+FSL_IMX7_GPV6_ADDR= 0x3260,
+FSL_IMX7_GPV5_ADDR= 0x3250,
+FSL_IMX7_GPV4_ADDR= 0x3240,
+FSL_IMX7_GPV3_ADDR= 0x3230,
+FSL_IMX7_GPV2_ADDR= 0x3220,
+FSL_IMX7_GPV1_ADDR= 0x3210,
+FSL_IMX7_GPV0_ADDR= 0x3200,
+FSL_IMX7_GPVn_SIZE= (1 * MiB),
-FSL_IMX7_OCOTP_ADDR = 0x3035,
-FSL_IMX7_OCOTP_SIZE = 0x1,
+/* Arm Peripherals */
+FSL_IMX7_A7MPCORE_ADDR= 0x3100,
-FSL_IMX7_ANALOG_ADDR = 0x3036,
-FSL_IMX7_SNVS_ADDR= 0x3037,
-FSL_IMX7_CCM_ADDR = 0x3038,
+/* AIPS-3 Begin */
-FSL_IMX7_SRC_ADDR = 0x3039,
-FSL_IMX7_SRC_SIZE = 0x1000,
+FSL_IMX7_ENET2_ADDR = 0x30BF,
+FSL_IMX7_ENET1_ADDR = 0x30BE,
-FSL_IMX7_ADC1_ADDR= 0x3061,
-FSL_IMX7_ADC2_ADDR= 0x3062,
-FSL_IMX7_ADCn_SIZE= 0x1000,
+FSL_IMX7_SDMA_ADDR= 0x30BD,
+FSL_IMX7_SDMA_SIZE= (4 * KiB),
-FSL_IMX7_PWM1_ADDR= 0x3066,
-FSL_IMX7_PWM2_ADDR= 0x3067,
-FSL_IMX7_PWM3_ADDR= 0x3068,
-FSL_IMX7_PWM4_ADDR= 0x3069,
-FSL_IMX7_PWMn_SIZE= 0x1,
+FSL_IMX7_EIM_ADDR = 0x30BC,
+FSL_IMX7_EIM_SIZE = (4 * KiB),
-FSL_IMX7_PCIE_PHY_ADDR= 0x306D,
-FSL_IMX7_PCIE_PHY_SIZE= 0x1,
+FSL_IMX7_QSPI_ADDR= 0x30BB,
+FSL_IMX7_QSPI_SIZE= 0x800
[PULL 22/24] target/arm: Do all "ARM_FEATURE_X implies Y" checks in post_init
Where architecturally one ARM_FEATURE_X flag implies another
ARM_FEATURE_Y, we allow the CPU init function to only set X, and then
set Y for it. Currently we do this in two places -- we set a few
flags in arm_cpu_post_init() because we need them to decide which
properties to create on the CPU object, and then we do the rest in
arm_cpu_realizefn(). However, this is fragile, because it's easy to
add a new property and not notice that this means that an X-implies-Y
check now has to move from realize to post-init.
As a specific example, the pmsav7-dregion property is conditional
on ARM_FEATURE_PMSA && ARM_FEATURE_V7, which means it won't appear
on the Cortex-M33 and -M55, because they set ARM_FEATURE_V8 and
rely on V8-implies-V7, which doesn't happen until the realizefn.
Move all of these X-implies-Y checks into a new function, which
we call at the top of arm_cpu_post_init(), so the feature bits
are available at that point.
This does now give us the reverse issue, that if there's a feature
bit which is enabled or disabled by the setting of a property then
then X-implies-Y features that are dependent on that property need to
be in realize, not in this new function. But the only one of those
is the "EL3 implies VBAR" which is already in the right place, so
putting things this way round seems better to me.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id: 20230724174335.2150499-2-peter.mayd...@linaro.org
---
target/arm/cpu.c | 179 +--
1 file changed, 97 insertions(+), 82 deletions(-)
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 17540300feb..0bb05854419 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1356,17 +1356,108 @@ unsigned int gt_cntfrq_period_ns(ARMCPU *cpu)
NANOSECONDS_PER_SECOND / cpu->gt_cntfrq_hz : 1;
}
+static void arm_cpu_propagate_feature_implications(ARMCPU *cpu)
+{
+CPUARMState *env = &cpu->env;
+bool no_aa32 = false;
+
+/*
+ * Some features automatically imply others: set the feature
+ * bits explicitly for these cases.
+ */
+
+if (arm_feature(env, ARM_FEATURE_M)) {
+set_feature(env, ARM_FEATURE_PMSA);
+}
+
+if (arm_feature(env, ARM_FEATURE_V8)) {
+if (arm_feature(env, ARM_FEATURE_M)) {
+set_feature(env, ARM_FEATURE_V7);
+} else {
+set_feature(env, ARM_FEATURE_V7VE);
+}
+}
+
+/*
+ * There exist AArch64 cpus without AArch32 support. When KVM
+ * queries ID_ISAR0_EL1 on such a host, the value is UNKNOWN.
+ * Similarly, we cannot check ID_AA64PFR0 without AArch64 support.
+ * As a general principle, we also do not make ID register
+ * consistency checks anywhere unless using TCG, because only
+ * for TCG would a consistency-check failure be a QEMU bug.
+ */
+if (arm_feature(&cpu->env, ARM_FEATURE_AARCH64)) {
+no_aa32 = !cpu_isar_feature(aa64_aa32, cpu);
+}
+
+if (arm_feature(env, ARM_FEATURE_V7VE)) {
+/*
+ * v7 Virtualization Extensions. In real hardware this implies
+ * EL2 and also the presence of the Security Extensions.
+ * For QEMU, for backwards-compatibility we implement some
+ * CPUs or CPU configs which have no actual EL2 or EL3 but do
+ * include the various other features that V7VE implies.
+ * Presence of EL2 itself is ARM_FEATURE_EL2, and of the
+ * Security Extensions is ARM_FEATURE_EL3.
+ */
+assert(!tcg_enabled() || no_aa32 ||
+ cpu_isar_feature(aa32_arm_div, cpu));
+set_feature(env, ARM_FEATURE_LPAE);
+set_feature(env, ARM_FEATURE_V7);
+}
+if (arm_feature(env, ARM_FEATURE_V7)) {
+set_feature(env, ARM_FEATURE_VAPA);
+set_feature(env, ARM_FEATURE_THUMB2);
+set_feature(env, ARM_FEATURE_MPIDR);
+if (!arm_feature(env, ARM_FEATURE_M)) {
+set_feature(env, ARM_FEATURE_V6K);
+} else {
+set_feature(env, ARM_FEATURE_V6);
+}
+
+/*
+ * Always define VBAR for V7 CPUs even if it doesn't exist in
+ * non-EL3 configs. This is needed by some legacy boards.
+ */
+set_feature(env, ARM_FEATURE_VBAR);
+}
+if (arm_feature(env, ARM_FEATURE_V6K)) {
+set_feature(env, ARM_FEATURE_V6);
+set_feature(env, ARM_FEATURE_MVFR);
+}
+if (arm_feature(env, ARM_FEATURE_V6)) {
+set_feature(env, ARM_FEATURE_V5);
+if (!arm_feature(env, ARM_FEATURE_M)) {
+assert(!tcg_enabled() || no_aa32 ||
+ cpu_isar_feature(aa32_jazelle, cpu));
+set_feature(env, ARM_FEATURE_AUXCR);
+}
+}
+if (arm_feature(env, ARM_FEATURE_V5)) {
+set_feature(env, ARM_FEATURE_V4T);
+}
+if (arm_feature(env, ARM_FEATURE_LPAE)) {
+set_feature(env, ARM_FEATURE_V7MP);
+}
+if (arm_feature(env, ARM_FEATURE_CBAR_RO)) {
+set_feature(env, ARM_FEATU
[PULL 09/24] target/arm: Implement FEAT_HPDS2 as a no-op
From: Richard Henderson This feature allows the operating system to set TCR_ELx.HWU* to allow the implementation to use the PBHA bits from the block and page descriptors for for IMPLEMENTATION DEFINED purposes. Since QEMU has no need to use these bits, we may simply ignore them. Signed-off-by: Richard Henderson Reviewed-by: Peter Maydell Message-id: 20230811214031.171020-11-richard.hender...@linaro.org Signed-off-by: Peter Maydell --- docs/system/arm/emulation.rst | 1 + target/arm/tcg/cpu32.c| 2 +- target/arm/tcg/cpu64.c| 2 +- 3 files changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/system/arm/emulation.rst b/docs/system/arm/emulation.rst index bdafc68819b..2012bbf7c7c 100644 --- a/docs/system/arm/emulation.rst +++ b/docs/system/arm/emulation.rst @@ -40,6 +40,7 @@ the following architecture extensions: - FEAT_HAFDBS (Hardware management of the access flag and dirty bit state) - FEAT_HCX (Support for the HCRX_EL2 register) - FEAT_HPDS (Hierarchical permission disables) +- FEAT_HPDS2 (Translation table page-based hardware attributes) - FEAT_I8MM (AArch64 Int8 matrix multiplication instructions) - FEAT_IDST (ID space trap handling) - FEAT_IESB (Implicit error synchronization event) diff --git a/target/arm/tcg/cpu32.c b/target/arm/tcg/cpu32.c index 47d2e8e7811..1f918ff5375 100644 --- a/target/arm/tcg/cpu32.c +++ b/target/arm/tcg/cpu32.c @@ -62,7 +62,7 @@ void aa32_max_features(ARMCPU *cpu) cpu->isar.id_mmfr3 = t; t = cpu->isar.id_mmfr4; -t = FIELD_DP32(t, ID_MMFR4, HPDS, 1); /* FEAT_AA32HPD */ +t = FIELD_DP32(t, ID_MMFR4, HPDS, 2); /* FEAT_HPDS2 */ t = FIELD_DP32(t, ID_MMFR4, AC2, 1); /* ACTLR2, HACTLR2 */ t = FIELD_DP32(t, ID_MMFR4, CNP, 1); /* FEAT_TTCNP */ t = FIELD_DP32(t, ID_MMFR4, XNX, 1); /* FEAT_XNX */ diff --git a/target/arm/tcg/cpu64.c b/target/arm/tcg/cpu64.c index b0cac05be65..11e406d960e 100644 --- a/target/arm/tcg/cpu64.c +++ b/target/arm/tcg/cpu64.c @@ -852,7 +852,7 @@ void aarch64_max_tcg_initfn(Object *obj) t = FIELD_DP64(t, ID_AA64MMFR1, HAFDBS, 2); /* FEAT_HAFDBS */ t = FIELD_DP64(t, ID_AA64MMFR1, VMIDBITS, 2); /* FEAT_VMID16 */ t = FIELD_DP64(t, ID_AA64MMFR1, VH, 1); /* FEAT_VHE */ -t = FIELD_DP64(t, ID_AA64MMFR1, HPDS, 1); /* FEAT_HPDS */ +t = FIELD_DP64(t, ID_AA64MMFR1, HPDS, 2); /* FEAT_HPDS2 */ t = FIELD_DP64(t, ID_AA64MMFR1, LO, 1); /* FEAT_LOR */ t = FIELD_DP64(t, ID_AA64MMFR1, PAN, 3); /* FEAT_PAN3 */ t = FIELD_DP64(t, ID_AA64MMFR1, XNX, 1); /* FEAT_XNX */ -- 2.34.1
[PULL 13/24] Add i.MX6UL missing devices.
From: Jean-Christophe Dubois
* Add TZASC as unimplemented device.
- Allow bare metal application to access this (unimplemented) device
* Add CSU as unimplemented device.
- Allow bare metal application to access this (unimplemented) device
* Add 4 missing PWM devices
Signed-off-by: Jean-Christophe Dubois
Reviewed-by: Philippe Mathieu-Daudé
Message-id:
59e4dc56e14eccfefd379275ec19048dff9c10b3.1692964892.git@tribudubois.net
Signed-off-by: Peter Maydell
---
include/hw/arm/fsl-imx6ul.h | 2 +-
hw/arm/fsl-imx6ul.c | 16
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/include/hw/arm/fsl-imx6ul.h b/include/hw/arm/fsl-imx6ul.h
index f7bf684b428..63012628ff0 100644
--- a/include/hw/arm/fsl-imx6ul.h
+++ b/include/hw/arm/fsl-imx6ul.h
@@ -60,7 +60,7 @@ enum FslIMX6ULConfiguration {
FSL_IMX6UL_NUM_USBS = 2,
FSL_IMX6UL_NUM_SAIS = 3,
FSL_IMX6UL_NUM_CANS = 2,
-FSL_IMX6UL_NUM_PWMS = 4,
+FSL_IMX6UL_NUM_PWMS = 8,
};
struct FslIMX6ULState {
diff --git a/hw/arm/fsl-imx6ul.c b/hw/arm/fsl-imx6ul.c
index 06a32aff647..e37b69a5e16 100644
--- a/hw/arm/fsl-imx6ul.c
+++ b/hw/arm/fsl-imx6ul.c
@@ -583,6 +583,10 @@ static void fsl_imx6ul_realize(DeviceState *dev, Error
**errp)
FSL_IMX6UL_PWM2_ADDR,
FSL_IMX6UL_PWM3_ADDR,
FSL_IMX6UL_PWM4_ADDR,
+FSL_IMX6UL_PWM5_ADDR,
+FSL_IMX6UL_PWM6_ADDR,
+FSL_IMX6UL_PWM7_ADDR,
+FSL_IMX6UL_PWM8_ADDR,
};
snprintf(name, NAME_SIZE, "pwm%d", i);
@@ -636,6 +640,18 @@ static void fsl_imx6ul_realize(DeviceState *dev, Error
**errp)
create_unimplemented_device("lcdif", FSL_IMX6UL_LCDIF_ADDR,
FSL_IMX6UL_LCDIF_SIZE);
+/*
+ * CSU
+ */
+create_unimplemented_device("csu", FSL_IMX6UL_CSU_ADDR,
+FSL_IMX6UL_CSU_SIZE);
+
+/*
+ * TZASC
+ */
+create_unimplemented_device("tzasc", FSL_IMX6UL_TZASC_ADDR,
+FSL_IMX6UL_TZASC_SIZE);
+
/*
* ROM memory
*/
--
2.34.1
Re: [PATCH v2 01/12] build: Only define OS_OBJECT_USE_OBJC with gcc
On 2023/08/31 17:59, Alexander Graf wrote: On 31.08.23 10:53, Akihiko Odaki wrote: On 2023/08/31 17:12, Philippe Mathieu-Daudé wrote: On 30/8/23 18:14, Alexander Graf wrote: Recent versions of macOS use clang instead of gcc. The OS_OBJECT_USE_OBJC define is only necessary when building with gcc. Let's not define it when building with clang. With this patch, I can successfully include GCD headers in QEMU when building with clang. Signed-off-by: Alexander Graf --- meson.build | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/meson.build b/meson.build index 98e68ef0b1..0d6a0015a1 100644 --- a/meson.build +++ b/meson.build @@ -224,7 +224,9 @@ qemu_ldflags = [] if targetos == 'darwin' # Disable attempts to use ObjectiveC features in os/object.h since they # won't work when we're compiling with gcc as a C compiler. - qemu_common_flags += '-DOS_OBJECT_USE_OBJC=0' + if compiler.get_id() == 'gcc' + qemu_common_flags += '-DOS_OBJECT_USE_OBJC=0' + endif elif targetos == 'solaris' # needed for CMSG_ macros in sys/socket.h qemu_common_flags += '-D_XOPEN_SOURCE=600' Reviewed-by: Philippe Mathieu-Daudé Defining OS_OBJECT_USE_OBJC does not look like a proper solution. Looking at os/object.h, it seems OS_OBJECT_USE_OBJC is defined as 0 when: !defined(OS_OBJECT_HAVE_OBJC_SUPPORT) && (!defined(__OBJC__) || defined(__OBJC_GC__)) This means OS_OBJECT_USE_OBJC is always 0 if Objective-C is disabled. I also confirmed os/object.h will not use Objective-C features when compiled as C code on clang with the following command: clang -E -x -c - < EOF If compilation fails with GCC when not defining OS_OBJECT_USE_OBJC, it probably means GCC incorrectly treats C code as Objective-C and that is the problem we should solve. I cannot confirm this theory however since I have only an Apple Silicon Mac that is incompatible with GCC. My take on this was to make the gcc hack be a "legacy" thing that we put into its own corner, so that in a few years we can just drop it altogether. I don't really think it's worth wasting much time on this workaround and its potential compatibility with old macOS versions. That makes sense. Reviewed-by: Akihiko Odaki
[PULL 00/24] target-arm queue
Hi; here's the latest round of arm patches. I have included also my patchset for the RTC devices to avoid keeping time_t and time_t diffs in 32-bit variables. thanks -- PMM The following changes since commit 156618d9ea67f2f2e31d9dedd97f2dcccbe6808c: Merge tag 'block-pull-request' of https://gitlab.com/stefanha/qemu into staging (2023-08-30 09:20:27 -0400) are available in the Git repository at: https://git.linaro.org/people/pmaydell/qemu-arm.git tags/pull-target-arm-20230831 for you to fetch changes up to e73b8bb8a3e9a162f70e9ffbf922d4fafc96bbfb: hw/arm: Set number of MPU regions correctly for an505, an521, an524 (2023-08-31 11:07:02 +0100) target-arm queue: * Some of the preliminary patches for Cortex-A710 support * i.MX7 and i.MX6UL refactoring * Implement SRC device for i.MX7 * Catch illegal-exception-return from EL3 with bad NSE/NS * Use 64-bit offsets for holding time_t differences in RTC devices * Model correct number of MPU regions for an505, an521, an524 boards Alex Bennée (1): target/arm: properly document FEAT_CRC32 Jean-Christophe Dubois (6): Remove i.MX7 IOMUX GPR device from i.MX6UL Refactor i.MX6UL processor code Add i.MX6UL missing devices. Refactor i.MX7 processor code Add i.MX7 missing TZ devices and memory regions Add i.MX7 SRC device implementation Peter Maydell (8): target/arm: Catch illegal-exception-return from EL3 with bad NSE/NS hw/rtc/m48t59: Use 64-bit arithmetic in set_alarm() hw/rtc/twl92230: Use int64_t for sec_offset and alm_sec hw/rtc/aspeed_rtc: Use 64-bit offset for holding time_t difference rtc: Use time_t for passing and returning time offsets target/arm: Do all "ARM_FEATURE_X implies Y" checks in post_init hw/arm/armv7m: Add mpu-ns-regions and mpu-s-regions properties hw/arm: Set number of MPU regions correctly for an505, an521, an524 Richard Henderson (9): target/arm: Reduce dcz_blocksize to uint8_t target/arm: Allow cpu to configure GM blocksize target/arm: Support more GM blocksizes target/arm: When tag memory is not present, set MTE=1 target/arm: Introduce make_ccsidr64 target/arm: Apply access checks to neoverse-n1 special registers target/arm: Apply access checks to neoverse-v1 special registers target/arm: Suppress FEAT_TRBE (Trace Buffer Extension) target/arm: Implement FEAT_HPDS2 as a no-op docs/system/arm/emulation.rst | 2 + include/hw/arm/armsse.h| 5 + include/hw/arm/armv7m.h| 8 + include/hw/arm/fsl-imx6ul.h| 158 --- include/hw/arm/fsl-imx7.h | 338 ++--- include/hw/misc/imx7_src.h | 66 include/hw/rtc/aspeed_rtc.h| 2 +- include/sysemu/rtc.h | 4 +- target/arm/cpregs.h| 2 + target/arm/cpu.h | 5 +- target/arm/internals.h | 6 - target/arm/tcg/translate.h | 2 + hw/arm/armsse.c| 16 ++ hw/arm/armv7m.c| 21 +++ hw/arm/fsl-imx6ul.c| 174 + hw/arm/fsl-imx7.c | 201 +++- hw/arm/mps2-tz.c | 29 hw/misc/imx7_src.c | 276 + hw/rtc/aspeed_rtc.c| 5 +- hw/rtc/m48t59.c| 2 +- hw/rtc/twl92230.c | 4 +- softmmu/rtc.c | 4 +- target/arm/cpu.c | 207 ++--- target/arm/helper.c| 15 +- target/arm/tcg/cpu32.c | 2 +- target/arm/tcg/cpu64.c | 102 + target/arm/tcg/helper-a64.c| 9 ++ target/arm/tcg/mte_helper.c| 90 --- target/arm/tcg/translate-a64.c | 5 +- hw/misc/meson.build| 1 + hw/misc/trace-events | 4 + 31 files changed, 1393 insertions(+), 372 deletions(-) create mode 100644 include/hw/misc/imx7_src.h create mode 100644 hw/misc/imx7_src.c
[PULL 01/24] target/arm: Reduce dcz_blocksize to uint8_t
From: Richard Henderson
This value is only 4 bits wide.
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
Message-id: 20230811214031.171020-2-richard.hender...@linaro.org
Signed-off-by: Peter Maydell
---
target/arm/cpu.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index cdf8600b96a..a1e604366b2 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1074,7 +1074,8 @@ struct ArchCPU {
bool prop_lpa2;
/* DCZ blocksize, in log_2(words), ie low 4 bits of DCZID_EL0 */
-uint32_t dcz_blocksize;
+uint8_t dcz_blocksize;
+
uint64_t rvbar_prop; /* Property/input signals. */
/* Configurable aspects of GIC cpu interface (which is part of the CPU) */
--
2.34.1
[PULL 08/24] target/arm: Suppress FEAT_TRBE (Trace Buffer Extension)
From: Richard Henderson Like FEAT_TRF (Self-hosted Trace Extension), suppress tracing external to the cpu, which is out of scope for QEMU. Signed-off-by: Richard Henderson Reviewed-by: Peter Maydell Message-id: 20230811214031.171020-10-richard.hender...@linaro.org Signed-off-by: Peter Maydell --- target/arm/cpu.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/target/arm/cpu.c b/target/arm/cpu.c index 23901121ac6..17540300feb 100644 --- a/target/arm/cpu.c +++ b/target/arm/cpu.c @@ -2088,6 +2088,9 @@ static void arm_cpu_realizefn(DeviceState *dev, Error **errp) /* FEAT_SPE (Statistical Profiling Extension) */ cpu->isar.id_aa64dfr0 = FIELD_DP64(cpu->isar.id_aa64dfr0, ID_AA64DFR0, PMSVER, 0); +/* FEAT_TRBE (Trace Buffer Extension) */ +cpu->isar.id_aa64dfr0 = +FIELD_DP64(cpu->isar.id_aa64dfr0, ID_AA64DFR0, TRACEBUFFER, 0); /* FEAT_TRF (Self-hosted Trace Extension) */ cpu->isar.id_aa64dfr0 = FIELD_DP64(cpu->isar.id_aa64dfr0, ID_AA64DFR0, TRACEFILT, 0); -- 2.34.1
[PULL 23/24] hw/arm/armv7m: Add mpu-ns-regions and mpu-s-regions properties
M-profile CPUs generally allow configuration of the number of MPU
regions that they have. We don't currently model this, so our
implementations of some of the board models provide CPUs with the
wrong number of regions. RTOSes like Zephyr that hardcode the
expected number of regions may therefore not run on the model if they
are set up to run on real hardware.
Add properties mpu-ns-regions and mpu-s-regions to the ARMV7M object,
matching the ability of hardware to configure the number of Secure
and NonSecure regions separately. Our actual CPU implementation
doesn't currently support that, and it happens that none of the MPS
boards we model set the number of regions differently for Secure vs
NonSecure, so we provide an interface to the boards and SoCs that
won't need to change if we ever do add that functionality in future,
but make it an error to configure the two properties to different
values.
(The property name on the CPU is the somewhat misnamed-for-M-profile
"pmsav7-dregion", so we don't follow that naming convention for
the properties here. The TRM doesn't say what the CPU configuration
variable names are, so we pick something, and follow the lowercase
convention we already have for properties here.)
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
Message-id: 20230724174335.2150499-3-peter.mayd...@linaro.org
---
include/hw/arm/armv7m.h | 8
hw/arm/armv7m.c | 21 +
2 files changed, 29 insertions(+)
diff --git a/include/hw/arm/armv7m.h b/include/hw/arm/armv7m.h
index b7ba0ff409c..e2cebbd15c0 100644
--- a/include/hw/arm/armv7m.h
+++ b/include/hw/arm/armv7m.h
@@ -52,6 +52,12 @@ OBJECT_DECLARE_SIMPLE_TYPE(ARMv7MState, ARMV7M)
* + Property "vfp": enable VFP (forwarded to CPU object)
* + Property "dsp": enable DSP (forwarded to CPU object)
* + Property "enable-bitband": expose bitbanded IO
+ * + Property "mpu-ns-regions": number of Non-Secure MPU regions (forwarded
+ * to CPU object pmsav7-dregion property; default is whatever the default
+ * for the CPU is)
+ * + Property "mpu-s-regions": number of Secure MPU regions (default is
+ * whatever the default for the CPU is; must currently be set to the same
+ * value as mpu-ns-regions if the CPU implements the Security Extension)
* + Clock input "refclk" is the external reference clock for the systick
timers
* + Clock input "cpuclk" is the main CPU clock
*/
@@ -95,6 +101,8 @@ struct ARMv7MState {
Object *idau;
uint32_t init_svtor;
uint32_t init_nsvtor;
+uint32_t mpu_ns_regions;
+uint32_t mpu_s_regions;
bool enable_bitband;
bool start_powered_off;
bool vfp;
diff --git a/hw/arm/armv7m.c b/hw/arm/armv7m.c
index 50a9507c0bd..bf173b10b8b 100644
--- a/hw/arm/armv7m.c
+++ b/hw/arm/armv7m.c
@@ -334,6 +334,25 @@ static void armv7m_realize(DeviceState *dev, Error **errp)
}
}
+/*
+ * Real M-profile hardware can be configured with a different number of
+ * MPU regions for Secure vs NonSecure. QEMU's CPU implementation doesn't
+ * support that yet, so catch attempts to select that.
+ */
+if (arm_feature(&s->cpu->env, ARM_FEATURE_M_SECURITY) &&
+s->mpu_ns_regions != s->mpu_s_regions) {
+error_setg(errp,
+ "mpu-ns-regions and mpu-s-regions properties must have the
same value");
+return;
+}
+if (s->mpu_ns_regions != UINT_MAX &&
+object_property_find(OBJECT(s->cpu), "pmsav7-dregion")) {
+if (!object_property_set_uint(OBJECT(s->cpu), "pmsav7-dregion",
+ s->mpu_ns_regions, errp)) {
+return;
+}
+}
+
/*
* Tell the CPU where the NVIC is; it will fail realize if it doesn't
* have one. Similarly, tell the NVIC where its CPU is.
@@ -530,6 +549,8 @@ static Property armv7m_properties[] = {
false),
DEFINE_PROP_BOOL("vfp", ARMv7MState, vfp, true),
DEFINE_PROP_BOOL("dsp", ARMv7MState, dsp, true),
+DEFINE_PROP_UINT32("mpu-ns-regions", ARMv7MState, mpu_ns_regions,
UINT_MAX),
+DEFINE_PROP_UINT32("mpu-s-regions", ARMv7MState, mpu_s_regions, UINT_MAX),
DEFINE_PROP_END_OF_LIST(),
};
--
2.34.1
[PULL 05/24] target/arm: Introduce make_ccsidr64
From: Richard Henderson
Do not hard-code the constants for Neoverse V1.
Signed-off-by: Richard Henderson
Reviewed-by: Peter Maydell
Message-id: 20230811214031.171020-6-richard.hender...@linaro.org
Signed-off-by: Peter Maydell
---
target/arm/tcg/cpu64.c | 48 --
1 file changed, 32 insertions(+), 16 deletions(-)
diff --git a/target/arm/tcg/cpu64.c b/target/arm/tcg/cpu64.c
index 4cd73779c80..00f39d42a8c 100644
--- a/target/arm/tcg/cpu64.c
+++ b/target/arm/tcg/cpu64.c
@@ -24,9 +24,36 @@
#include "qemu/module.h"
#include "qapi/visitor.h"
#include "hw/qdev-properties.h"
+#include "qemu/units.h"
#include "internals.h"
#include "cpregs.h"
+static uint64_t make_ccsidr64(unsigned assoc, unsigned linesize,
+ unsigned cachesize)
+{
+unsigned lg_linesize = ctz32(linesize);
+unsigned sets;
+
+/*
+ * The 64-bit CCSIDR_EL1 format is:
+ * [55:32] number of sets - 1
+ * [23:3] associativity - 1
+ * [2:0] log2(linesize) - 4
+ * so 0 == 16 bytes, 1 == 32 bytes, 2 == 64 bytes, etc
+ */
+assert(assoc != 0);
+assert(is_power_of_2(linesize));
+assert(lg_linesize >= 4 && lg_linesize <= 7 + 4);
+
+/* sets * associativity * linesize == cachesize. */
+sets = cachesize / (assoc * linesize);
+assert(cachesize % (assoc * linesize) == 0);
+
+return ((uint64_t)(sets - 1) << 32)
+ | ((assoc - 1) << 3)
+ | (lg_linesize - 4);
+}
+
static void aarch64_a35_initfn(Object *obj)
{
ARMCPU *cpu = ARM_CPU(obj);
@@ -651,26 +678,15 @@ static void aarch64_neoverse_v1_initfn(Object *obj)
* The Neoverse-V1 r1p2 TRM lists 32-bit format CCSIDR_EL1 values,
* but also says it implements CCIDX, which means they should be
* 64-bit format. So we here use values which are based on the textual
- * information in chapter 2 of the TRM (and on the fact that
- * sets * associativity * linesize == cachesize).
- *
- * The 64-bit CCSIDR_EL1 format is:
- * [55:32] number of sets - 1
- * [23:3] associativity - 1
- * [2:0] log2(linesize) - 4
- * so 0 == 16 bytes, 1 == 32 bytes, 2 == 64 bytes, etc
- *
- * L1: 4-way set associative 64-byte line size, total size 64K,
- * so sets is 256.
+ * information in chapter 2 of the TRM:
*
+ * L1: 4-way set associative 64-byte line size, total size 64K.
* L2: 8-way set associative, 64 byte line size, either 512K or 1MB.
- * We pick 1MB, so this has 2048 sets.
- *
* L3: No L3 (this matches the CLIDR_EL1 value).
*/
-cpu->ccsidr[0] = 0x00ff001aull; /* 64KB L1 dcache */
-cpu->ccsidr[1] = 0x00ff001aull; /* 64KB L1 icache */
-cpu->ccsidr[2] = 0x07ff003aull; /* 1MB L2 cache */
+cpu->ccsidr[0] = make_ccsidr64(4, 64, 64 * KiB); /* L1 dcache */
+cpu->ccsidr[1] = cpu->ccsidr[0]; /* L1 icache */
+cpu->ccsidr[2] = make_ccsidr64(8, 64, 1 * MiB); /* L2 cache */
/* From 3.2.115 SCTLR_EL3 */
cpu->reset_sctlr = 0x30c50838;
--
2.34.1
[PULL 15/24] Add i.MX7 missing TZ devices and memory regions
From: Jean-Christophe Dubois
* Add TZASC as unimplemented device.
- Allow bare metal application to access this (unimplemented) device
* Add CSU as unimplemented device.
- Allow bare metal application to access this (unimplemented) device
* Add various memory segments
- OCRAM
- OCRAM EPDC
- OCRAM PXP
- OCRAM S
- ROM
- CAAM
Signed-off-by: Jean-Christophe Dubois
Reviewed-by: Philippe Mathieu-Daudé
Message-id:
f887a3483996ba06d40bd62ffdfb0ecf68621987.1692964892.git@tribudubois.net
Signed-off-by: Peter Maydell
---
include/hw/arm/fsl-imx7.h | 7 +
hw/arm/fsl-imx7.c | 63 +++
2 files changed, 70 insertions(+)
diff --git a/include/hw/arm/fsl-imx7.h b/include/hw/arm/fsl-imx7.h
index 06b2c5e4acf..01e15004d76 100644
--- a/include/hw/arm/fsl-imx7.h
+++ b/include/hw/arm/fsl-imx7.h
@@ -84,6 +84,13 @@ struct FslIMX7State {
IMX7GPRState gpr;
ChipideaState usb[FSL_IMX7_NUM_USBS];
DesignwarePCIEHost pcie;
+MemoryRegion rom;
+MemoryRegion caam;
+MemoryRegion ocram;
+MemoryRegion ocram_epdc;
+MemoryRegion ocram_pxp;
+MemoryRegion ocram_s;
+
uint32_t phy_num[FSL_IMX7_NUM_ETHS];
bool phy_connected[FSL_IMX7_NUM_ETHS];
};
diff --git a/hw/arm/fsl-imx7.c b/hw/arm/fsl-imx7.c
index e9760535393..97e982bf061 100644
--- a/hw/arm/fsl-imx7.c
+++ b/hw/arm/fsl-imx7.c
@@ -664,6 +664,69 @@ static void fsl_imx7_realize(DeviceState *dev, Error
**errp)
create_unimplemented_device("pcie-phy", FSL_IMX7_PCIE_PHY_ADDR,
FSL_IMX7_PCIE_PHY_SIZE);
+/*
+ * CSU
+ */
+create_unimplemented_device("csu", FSL_IMX7_CSU_ADDR,
+FSL_IMX7_CSU_SIZE);
+
+/*
+ * TZASC
+ */
+create_unimplemented_device("tzasc", FSL_IMX7_TZASC_ADDR,
+FSL_IMX7_TZASC_SIZE);
+
+/*
+ * OCRAM memory
+ */
+memory_region_init_ram(&s->ocram, NULL, "imx7.ocram",
+ FSL_IMX7_OCRAM_MEM_SIZE,
+ &error_abort);
+memory_region_add_subregion(get_system_memory(), FSL_IMX7_OCRAM_MEM_ADDR,
+&s->ocram);
+
+/*
+ * OCRAM EPDC memory
+ */
+memory_region_init_ram(&s->ocram_epdc, NULL, "imx7.ocram_epdc",
+ FSL_IMX7_OCRAM_EPDC_SIZE,
+ &error_abort);
+memory_region_add_subregion(get_system_memory(), FSL_IMX7_OCRAM_EPDC_ADDR,
+&s->ocram_epdc);
+
+/*
+ * OCRAM PXP memory
+ */
+memory_region_init_ram(&s->ocram_pxp, NULL, "imx7.ocram_pxp",
+ FSL_IMX7_OCRAM_PXP_SIZE,
+ &error_abort);
+memory_region_add_subregion(get_system_memory(), FSL_IMX7_OCRAM_PXP_ADDR,
+&s->ocram_pxp);
+
+/*
+ * OCRAM_S memory
+ */
+memory_region_init_ram(&s->ocram_s, NULL, "imx7.ocram_s",
+ FSL_IMX7_OCRAM_S_SIZE,
+ &error_abort);
+memory_region_add_subregion(get_system_memory(), FSL_IMX7_OCRAM_S_ADDR,
+&s->ocram_s);
+
+/*
+ * ROM memory
+ */
+memory_region_init_rom(&s->rom, OBJECT(dev), "imx7.rom",
+ FSL_IMX7_ROM_SIZE, &error_abort);
+memory_region_add_subregion(get_system_memory(), FSL_IMX7_ROM_ADDR,
+&s->rom);
+
+/*
+ * CAAM memory
+ */
+memory_region_init_rom(&s->caam, OBJECT(dev), "imx7.caam",
+ FSL_IMX7_CAAM_MEM_SIZE, &error_abort);
+memory_region_add_subregion(get_system_memory(), FSL_IMX7_CAAM_MEM_ADDR,
+&s->caam);
}
static Property fsl_imx7_properties[] = {
--
2.34.1
[PULL 10/24] target/arm: properly document FEAT_CRC32
From: Alex Bennée This is a mandatory feature for Armv8.1 architectures but we don't state the feature clearly in our emulation list. Also include FEAT_CRC32 comment in aarch64_max_tcg_initfn for ease of grepping. Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Alex Bennée Message-id: 20230824075406.1515566-1-alex.ben...@linaro.org Cc: qemu-sta...@nongnu.org Message-Id: <20230222110104.3996971-1-alex.ben...@linaro.org> [PMM: pluralize 'instructions' in docs] Signed-off-by: Peter Maydell --- docs/system/arm/emulation.rst | 1 + target/arm/tcg/cpu64.c| 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/system/arm/emulation.rst b/docs/system/arm/emulation.rst index 2012bbf7c7c..2e6a7c8961e 100644 --- a/docs/system/arm/emulation.rst +++ b/docs/system/arm/emulation.rst @@ -14,6 +14,7 @@ the following architecture extensions: - FEAT_BBM at level 2 (Translation table break-before-make levels) - FEAT_BF16 (AArch64 BFloat16 instructions) - FEAT_BTI (Branch Target Identification) +- FEAT_CRC32 (CRC32 instructions) - FEAT_CSV2 (Cache speculation variant 2) - FEAT_CSV2_1p1 (Cache speculation variant 2, version 1.1) - FEAT_CSV2_1p2 (Cache speculation variant 2, version 1.2) diff --git a/target/arm/tcg/cpu64.c b/target/arm/tcg/cpu64.c index 11e406d960e..0f8972950d6 100644 --- a/target/arm/tcg/cpu64.c +++ b/target/arm/tcg/cpu64.c @@ -788,7 +788,7 @@ void aarch64_max_tcg_initfn(Object *obj) t = FIELD_DP64(t, ID_AA64ISAR0, AES, 2); /* FEAT_PMULL */ t = FIELD_DP64(t, ID_AA64ISAR0, SHA1, 1); /* FEAT_SHA1 */ t = FIELD_DP64(t, ID_AA64ISAR0, SHA2, 2); /* FEAT_SHA512 */ -t = FIELD_DP64(t, ID_AA64ISAR0, CRC32, 1); +t = FIELD_DP64(t, ID_AA64ISAR0, CRC32, 1);/* FEAT_CRC32 */ t = FIELD_DP64(t, ID_AA64ISAR0, ATOMIC, 2); /* FEAT_LSE */ t = FIELD_DP64(t, ID_AA64ISAR0, RDM, 1); /* FEAT_RDM */ t = FIELD_DP64(t, ID_AA64ISAR0, SHA3, 1); /* FEAT_SHA3 */ -- 2.34.1
[PULL 19/24] hw/rtc/twl92230: Use int64_t for sec_offset and alm_sec
In the twl92230 device, use int64_t for the two state fields
sec_offset and alm_sec, because we set these to values that
are either time_t or differences between two time_t values.
These fields aren't saved in vmstate anywhere, so we can
safely widen them.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
---
hw/rtc/twl92230.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/rtc/twl92230.c b/hw/rtc/twl92230.c
index d8534dad949..64c61c3daeb 100644
--- a/hw/rtc/twl92230.c
+++ b/hw/rtc/twl92230.c
@@ -65,8 +65,8 @@ struct MenelausState {
struct tm tm;
struct tm new;
struct tm alm;
-int sec_offset;
-int alm_sec;
+int64_t sec_offset;
+int64_t alm_sec;
int next_comp;
} rtc;
uint16_t rtc_next_vmstate;
--
2.34.1
[PULL 11/24] Remove i.MX7 IOMUX GPR device from i.MX6UL
From: Jean-Christophe Dubois
i.MX7 IOMUX GPR device is not equivalent to i.MX6UL IOMUXC GPR device.
In particular, register 22 is not present on i.MX6UL and this is actualy
The only register that is really emulated in the i.MX7 IOMUX GPR device.
Note: The i.MX6UL code is actually also implementing the IOMUX GPR device
as an unimplemented device at the same bus adress and the 2 instantiations
were actualy colliding. So we go back to the unimplemented device for now.
Signed-off-by: Jean-Christophe Dubois
Message-id:
48681bf51ee97646479bb261bee19abebbc8074e.1692964892.git@tribudubois.net
Reviewed-by: Peter Maydell
Signed-off-by: Peter Maydell
---
include/hw/arm/fsl-imx6ul.h | 2 --
hw/arm/fsl-imx6ul.c | 11 ---
2 files changed, 13 deletions(-)
diff --git a/include/hw/arm/fsl-imx6ul.h b/include/hw/arm/fsl-imx6ul.h
index 9ee15ae38d6..3bec6bb3fb7 100644
--- a/include/hw/arm/fsl-imx6ul.h
+++ b/include/hw/arm/fsl-imx6ul.h
@@ -22,7 +22,6 @@
#include "hw/misc/imx6ul_ccm.h"
#include "hw/misc/imx6_src.h"
#include "hw/misc/imx7_snvs.h"
-#include "hw/misc/imx7_gpr.h"
#include "hw/intc/imx_gpcv2.h"
#include "hw/watchdog/wdt_imx2.h"
#include "hw/gpio/imx_gpio.h"
@@ -74,7 +73,6 @@ struct FslIMX6ULState {
IMX6SRCState src;
IMX7SNVSState snvs;
IMXGPCv2State gpcv2;
-IMX7GPRState gpr;
IMXSPIStatespi[FSL_IMX6UL_NUM_ECSPIS];
IMXI2CStatei2c[FSL_IMX6UL_NUM_I2CS];
IMXSerialState uart[FSL_IMX6UL_NUM_UARTS];
diff --git a/hw/arm/fsl-imx6ul.c b/hw/arm/fsl-imx6ul.c
index 2189dcbb72c..0fdd2782ba5 100644
--- a/hw/arm/fsl-imx6ul.c
+++ b/hw/arm/fsl-imx6ul.c
@@ -63,11 +63,6 @@ static void fsl_imx6ul_init(Object *obj)
*/
object_initialize_child(obj, "snvs", &s->snvs, TYPE_IMX7_SNVS);
-/*
- * GPR
- */
-object_initialize_child(obj, "gpr", &s->gpr, TYPE_IMX7_GPR);
-
/*
* GPIOs 1 to 5
*/
@@ -537,12 +532,6 @@ static void fsl_imx6ul_realize(DeviceState *dev, Error
**errp)
FSL_IMX6UL_WDOGn_IRQ[i]));
}
-/*
- * GPR
- */
-sysbus_realize(SYS_BUS_DEVICE(&s->gpr), &error_abort);
-sysbus_mmio_map(SYS_BUS_DEVICE(&s->gpr), 0, FSL_IMX6UL_IOMUXC_GPR_ADDR);
-
/*
* SDMA
*/
--
2.34.1
[PULL 12/24] Refactor i.MX6UL processor code
From: Jean-Christophe Dubois
* Add Addr and size definition for most i.MX6UL devices in i.MX6UL header file.
* Use those newly defined named constants whenever possible.
* Standardize the way we init a familly of unimplemented devices
- SAI
- PWM
- CAN
* Add/rework few comments
Signed-off-by: Jean-Christophe Dubois
Message-id:
d579043fbd4e4b490370783fda43fc02c8e9be75.1692964892.git@tribudubois.net
Reviewed-by: Peter Maydell
Signed-off-by: Peter Maydell
---
include/hw/arm/fsl-imx6ul.h | 156 +++-
hw/arm/fsl-imx6ul.c | 147 ++---
2 files changed, 232 insertions(+), 71 deletions(-)
diff --git a/include/hw/arm/fsl-imx6ul.h b/include/hw/arm/fsl-imx6ul.h
index 3bec6bb3fb7..f7bf684b428 100644
--- a/include/hw/arm/fsl-imx6ul.h
+++ b/include/hw/arm/fsl-imx6ul.h
@@ -37,6 +37,7 @@
#include "exec/memory.h"
#include "cpu.h"
#include "qom/object.h"
+#include "qemu/units.h"
#define TYPE_FSL_IMX6UL "fsl-imx6ul"
OBJECT_DECLARE_SIMPLE_TYPE(FslIMX6ULState, FSL_IMX6UL)
@@ -57,6 +58,9 @@ enum FslIMX6ULConfiguration {
FSL_IMX6UL_NUM_ADCS = 2,
FSL_IMX6UL_NUM_USB_PHYS = 2,
FSL_IMX6UL_NUM_USBS = 2,
+FSL_IMX6UL_NUM_SAIS = 3,
+FSL_IMX6UL_NUM_CANS = 2,
+FSL_IMX6UL_NUM_PWMS = 4,
};
struct FslIMX6ULState {
@@ -92,119 +96,227 @@ struct FslIMX6ULState {
enum FslIMX6ULMemoryMap {
FSL_IMX6UL_MMDC_ADDR= 0x8000,
-FSL_IMX6UL_MMDC_SIZE= 2 * 1024 * 1024 * 1024UL,
+FSL_IMX6UL_MMDC_SIZE= (2 * GiB),
FSL_IMX6UL_QSPI1_MEM_ADDR = 0x6000,
-FSL_IMX6UL_EIM_ALIAS_ADDR = 0x5800,
-FSL_IMX6UL_EIM_CS_ADDR = 0x5000,
-FSL_IMX6UL_AES_ENCRYPT_ADDR = 0x1000,
-FSL_IMX6UL_QSPI1_RX_ADDR= 0x0C00,
+FSL_IMX6UL_QSPI1_MEM_SIZE = (256 * MiB),
-/* AIPS-2 */
+FSL_IMX6UL_EIM_ALIAS_ADDR = 0x5800,
+FSL_IMX6UL_EIM_ALIAS_SIZE = (128 * MiB),
+
+FSL_IMX6UL_EIM_CS_ADDR = 0x5000,
+FSL_IMX6UL_EIM_CS_SIZE = (128 * MiB),
+
+FSL_IMX6UL_AES_ENCRYPT_ADDR = 0x1000,
+FSL_IMX6UL_AES_ENCRYPT_SIZE = (1 * MiB),
+
+FSL_IMX6UL_QSPI1_RX_ADDR= 0x0C00,
+FSL_IMX6UL_QSPI1_RX_SIZE= (32 * MiB),
+
+/* AIPS-2 Begin */
FSL_IMX6UL_UART6_ADDR = 0x021FC000,
+
FSL_IMX6UL_I2C4_ADDR= 0x021F8000,
+
FSL_IMX6UL_UART5_ADDR = 0x021F4000,
FSL_IMX6UL_UART4_ADDR = 0x021F,
FSL_IMX6UL_UART3_ADDR = 0x021EC000,
FSL_IMX6UL_UART2_ADDR = 0x021E8000,
+
FSL_IMX6UL_WDOG3_ADDR = 0x021E4000,
+
FSL_IMX6UL_QSPI_ADDR= 0x021E,
+FSL_IMX6UL_QSPI_SIZE= 0x500,
+
FSL_IMX6UL_SYS_CNT_CTRL_ADDR= 0x021DC000,
+FSL_IMX6UL_SYS_CNT_CTRL_SIZE= (16 * KiB),
+
FSL_IMX6UL_SYS_CNT_CMP_ADDR = 0x021D8000,
+FSL_IMX6UL_SYS_CNT_CMP_SIZE = (16 * KiB),
+
FSL_IMX6UL_SYS_CNT_RD_ADDR = 0x021D4000,
+FSL_IMX6UL_SYS_CNT_RD_SIZE = (16 * KiB),
+
FSL_IMX6UL_TZASC_ADDR = 0x021D,
+FSL_IMX6UL_TZASC_SIZE = (16 * KiB),
+
FSL_IMX6UL_PXP_ADDR = 0x021CC000,
+FSL_IMX6UL_PXP_SIZE = (16 * KiB),
+
FSL_IMX6UL_LCDIF_ADDR = 0x021C8000,
+FSL_IMX6UL_LCDIF_SIZE = 0x100,
+
FSL_IMX6UL_CSI_ADDR = 0x021C4000,
+FSL_IMX6UL_CSI_SIZE = 0x100,
+
FSL_IMX6UL_CSU_ADDR = 0x021C,
+FSL_IMX6UL_CSU_SIZE = (16 * KiB),
+
FSL_IMX6UL_OCOTP_CTRL_ADDR = 0x021BC000,
+FSL_IMX6UL_OCOTP_CTRL_SIZE = (4 * KiB),
+
FSL_IMX6UL_EIM_ADDR = 0x021B8000,
+FSL_IMX6UL_EIM_SIZE = 0x100,
+
FSL_IMX6UL_SIM2_ADDR= 0x021B4000,
+
FSL_IMX6UL_MMDC_CFG_ADDR= 0x021B,
+FSL_IMX6UL_MMDC_CFG_SIZE= (4 * KiB),
+
FSL_IMX6UL_ROMCP_ADDR = 0x021AC000,
+FSL_IMX6UL_ROMCP_SIZE = 0x300,
+
FSL_IMX6UL_I2C3_ADDR= 0x021A8000,
FSL_IMX6UL_I2C2_ADDR= 0x021A4000,
FSL_IMX6UL_I2C1_ADDR= 0x021A,
+
FSL_IMX6UL_ADC2_ADDR= 0x0219C000,
FSL_IMX6UL_ADC1_ADDR= 0x02198000,
+FSL_IMX6UL_ADCn_SIZE= 0x100,
+
FSL_IMX6UL_USDHC2_ADDR = 0x02194000,
FSL_IMX6UL_USDHC1_ADDR = 0x0219,
-FSL_IMX6UL_SIM1_ADDR= 0x0218C000,
-FSL_IMX6UL_ENET1_ADDR = 0x02188000,
-FSL_IMX6UL_USBO2_USBMISC_ADDR = 0x02184800,
-FSL_IMX6UL_USBO2_USB_ADDR = 0x02184000,
-FSL_IMX6UL_USBO2_PL301_ADDR = 0x0218,
-FSL_IMX6UL_AIPS2_CFG_ADDR = 0x0217C000,
-FSL_IMX6UL_CAAM_ADDR= 0x0214,
-FSL_IMX6UL_A7MPCORE_DAP_ADDR= 0x0210,
-/* AIPS-1 */
+FSL_IMX6UL_SIM1_ADDR= 0x0218
[PULL 16/24] Add i.MX7 SRC device implementation
From: Jean-Christophe Dubois
The SRC device is normally used to start the secondary CPU.
When running Linux directly, QEMU is emulating a PSCI interface that UBOOT
is installing at boot time and therefore the fact that the SRC device is
unimplemented is hidden as Qemu respond directly to PSCI requets without
using the SRC device.
But if you try to run a more bare metal application (maybe uboot itself),
then it is not possible to start the secondary CPU as the SRC is an
unimplemented device.
This patch adds the ability to start the secondary CPU through the SRC
device so that you can use this feature in bare metal applications.
Signed-off-by: Jean-Christophe Dubois
Reviewed-by: Peter Maydell
Message-id:
ce9a0162defd2acee5dc7f8a674743de0cded569.1692964892.git@tribudubois.net
Signed-off-by: Peter Maydell
---
include/hw/arm/fsl-imx7.h | 3 +-
include/hw/misc/imx7_src.h | 66 +
hw/arm/fsl-imx7.c | 8 +-
hw/misc/imx7_src.c | 276 +
hw/misc/meson.build| 1 +
hw/misc/trace-events | 4 +
6 files changed, 356 insertions(+), 2 deletions(-)
create mode 100644 include/hw/misc/imx7_src.h
create mode 100644 hw/misc/imx7_src.c
diff --git a/include/hw/arm/fsl-imx7.h b/include/hw/arm/fsl-imx7.h
index 01e15004d76..2cbfc6b2b2c 100644
--- a/include/hw/arm/fsl-imx7.h
+++ b/include/hw/arm/fsl-imx7.h
@@ -25,6 +25,7 @@
#include "hw/misc/imx7_ccm.h"
#include "hw/misc/imx7_snvs.h"
#include "hw/misc/imx7_gpr.h"
+#include "hw/misc/imx7_src.h"
#include "hw/watchdog/wdt_imx2.h"
#include "hw/gpio/imx_gpio.h"
#include "hw/char/imx_serial.h"
@@ -74,6 +75,7 @@ struct FslIMX7State {
IMX7CCMState ccm;
IMX7AnalogStateanalog;
IMX7SNVSState snvs;
+IMX7SRCState src;
IMXGPCv2State gpcv2;
IMXSPIStatespi[FSL_IMX7_NUM_ECSPIS];
IMXI2CStatei2c[FSL_IMX7_NUM_I2CS];
@@ -292,7 +294,6 @@ enum FslIMX7MemoryMap {
FSL_IMX7_GPC_ADDR = 0x303A,
FSL_IMX7_SRC_ADDR = 0x3039,
-FSL_IMX7_SRC_SIZE = (4 * KiB),
FSL_IMX7_CCM_ADDR = 0x3038,
diff --git a/include/hw/misc/imx7_src.h b/include/hw/misc/imx7_src.h
new file mode 100644
index 000..b4b97dcb1c1
--- /dev/null
+++ b/include/hw/misc/imx7_src.h
@@ -0,0 +1,66 @@
+/*
+ * IMX7 System Reset Controller
+ *
+ * Copyright (C) 2023 Jean-Christophe Dubois
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#ifndef IMX7_SRC_H
+#define IMX7_SRC_H
+
+#include "hw/sysbus.h"
+#include "qemu/bitops.h"
+#include "qom/object.h"
+
+#define SRC_SCR 0
+#define SRC_A7RCR0 1
+#define SRC_A7RCR1 2
+#define SRC_M4RCR 3
+#define SRC_ERCR 5
+#define SRC_HSICPHY_RCR 7
+#define SRC_USBOPHY1_RCR 8
+#define SRC_USBOPHY2_RCR 9
+#define SRC_MPIPHY_RCR 10
+#define SRC_PCIEPHY_RCR 11
+#define SRC_SBMR1 22
+#define SRC_SRSR 23
+#define SRC_SISR 26
+#define SRC_SIMR 27
+#define SRC_SBMR2 28
+#define SRC_GPR1 29
+#define SRC_GPR2 30
+#define SRC_GPR3 31
+#define SRC_GPR4 32
+#define SRC_GPR5 33
+#define SRC_GPR6 34
+#define SRC_GPR7 35
+#define SRC_GPR8 36
+#define SRC_GPR9 37
+#define SRC_GPR10 38
+#define SRC_MAX 39
+
+/* SRC_A7SCR1 */
+#define R_CORE1_ENABLE_SHIFT 1
+#define R_CORE1_ENABLE_LENGTH1
+/* SRC_A7SCR0 */
+#define R_CORE1_RST_SHIFT5
+#define R_CORE1_RST_LENGTH 1
+#define R_CORE0_RST_SHIFT4
+#define R_CORE0_RST_LENGTH 1
+
+#define TYPE_IMX7_SRC "imx7.src"
+OBJECT_DECLARE_SIMPLE_TYPE(IMX7SRCState, IMX7_SRC)
+
+struct IMX7SRCState {
+/* */
+SysBusDevice parent_obj;
+
+/* */
+MemoryRegion iomem;
+
+uint32_t regs[SRC_MAX];
+};
+
+#endif /* IMX7_SRC_H */
diff --git a/hw/arm/fsl-imx7.c b/hw/arm/fsl-imx7.c
index 97e982bf061..474cfdc87c6 100644
--- a/hw/arm/fsl-imx7.c
+++ b/hw/arm/fsl-imx7.c
@@ -82,6 +82,11 @@ static void fsl_imx7_init(Object *obj)
*/
object_initialize_child(obj, "gpcv2", &s->gpcv2, TYPE_IMX_GPCV2);
+/*
+ * SRC
+ */
+object_initialize_child(obj, "src", &s->src, TYPE_IMX7_SRC);
+
/*
* ECSPIs
*/
@@ -488,7 +493,8 @@ static void fsl_imx7_realize(DeviceState *dev, Error **errp)
/*
* SRC
*/
-create_unimplemented_device("src", FSL_IMX7_SRC_ADDR, FSL_IMX7_SRC_SIZE);
+sysbus_realize(SYS_BUS_DEVICE(&s->src), &error_abort);
+sysbus_mmio_map(SYS_BUS_DEVICE(&s->src), 0, FSL_IMX7_SRC_ADDR);
/*
* Watchdogs
diff --git a/hw/misc/imx7_src.c b/hw/misc/imx7_src.c
new file mode 100644
index 000..983251e86f7
--- /dev/null
+++ b/hw/misc/imx7_src.c
@@ -0,0 +1,276 @@
+/*
+ * IMX7 System Reset Controller
+ *
+ * Copyright (c) 2023 Jean-Christophe Dubois
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "hw/misc/imx7_s
[PULL 18/24] hw/rtc/m48t59: Use 64-bit arithmetic in set_alarm()
In the m48t59 device we almost always use 64-bit arithmetic when
dealing with time_t deltas. The one exception is in set_alarm(),
which currently uses a plain 'int' to hold the difference between two
time_t values. Switch to int64_t instead to avoid any possible
overflow issues.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
---
hw/rtc/m48t59.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/rtc/m48t59.c b/hw/rtc/m48t59.c
index ec3e56e84fd..2e2c849985c 100644
--- a/hw/rtc/m48t59.c
+++ b/hw/rtc/m48t59.c
@@ -133,7 +133,7 @@ static void alarm_cb (void *opaque)
static void set_alarm(M48t59State *NVRAM)
{
-int diff;
+int64_t diff;
if (NVRAM->alrm_timer != NULL) {
timer_del(NVRAM->alrm_timer);
diff = qemu_timedate_diff(&NVRAM->alarm) - NVRAM->time_offset;
--
2.34.1
[PULL 21/24] rtc: Use time_t for passing and returning time offsets
The functions qemu_get_timedate() and qemu_timedate_diff() take
and return a time offset as an integer. Coverity points out that
means that when an RTC device implementation holds an offset
as a time_t, as the m48t59 does, the time_t will get truncated.
(CID 1507157, 1517772).
The functions work with time_t internally, so make them use that type
in their APIs.
Note that this won't help any Y2038 issues where either the device
model itself is keeping the offset in a 32-bit integer, or where the
hardware under emulation has Y2038 or other rollover problems. If we
missed any cases of the former then hopefully Coverity will warn us
about them since after this patch we'd be truncating a time_t in
assignments from qemu_timedate_diff().)
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
---
include/sysemu/rtc.h | 4 ++--
softmmu/rtc.c| 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/sysemu/rtc.h b/include/sysemu/rtc.h
index 159702b45b5..0fc8ad6fdf1 100644
--- a/include/sysemu/rtc.h
+++ b/include/sysemu/rtc.h
@@ -42,7 +42,7 @@
* The behaviour of the clock whose value this function returns will
* depend on the -rtc command line option passed by the user.
*/
-void qemu_get_timedate(struct tm *tm, int offset);
+void qemu_get_timedate(struct tm *tm, time_t offset);
/**
* qemu_timedate_diff: Return difference between a struct tm and the RTC
@@ -53,6 +53,6 @@ void qemu_get_timedate(struct tm *tm, int offset);
* a timestamp one hour further ahead than the current RTC time
* then this function will return 3600.
*/
-int qemu_timedate_diff(struct tm *tm);
+time_t qemu_timedate_diff(struct tm *tm);
#endif
diff --git a/softmmu/rtc.c b/softmmu/rtc.c
index 4b2bf75dd67..4904581abeb 100644
--- a/softmmu/rtc.c
+++ b/softmmu/rtc.c
@@ -68,7 +68,7 @@ static time_t qemu_ref_timedate(QEMUClockType clock)
return value;
}
-void qemu_get_timedate(struct tm *tm, int offset)
+void qemu_get_timedate(struct tm *tm, time_t offset)
{
time_t ti = qemu_ref_timedate(rtc_clock);
@@ -85,7 +85,7 @@ void qemu_get_timedate(struct tm *tm, int offset)
}
}
-int qemu_timedate_diff(struct tm *tm)
+time_t qemu_timedate_diff(struct tm *tm)
{
time_t seconds;
--
2.34.1
[PULL 17/24] target/arm: Catch illegal-exception-return from EL3 with bad NSE/NS
The architecture requires (R_TYTWB) that an attempt to return from EL3
when SCR_EL3.{NSE,NS} are {1,0} is an illegal exception return. (This
enforces that the CPU can't ever be executing below EL3 with the
NSE,NS bits indicating an invalid security state.)
We were missing this check; add it.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id: 20230807150618.101357-1-peter.mayd...@linaro.org
---
target/arm/tcg/helper-a64.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/target/arm/tcg/helper-a64.c b/target/arm/tcg/helper-a64.c
index 1c9370f07bd..0cf56f6dc44 100644
--- a/target/arm/tcg/helper-a64.c
+++ b/target/arm/tcg/helper-a64.c
@@ -780,6 +780,15 @@ void HELPER(exception_return)(CPUARMState *env, uint64_t
new_pc)
spsr &= ~PSTATE_SS;
}
+/*
+ * FEAT_RME forbids return from EL3 with an invalid security state.
+ * We don't need an explicit check for FEAT_RME here because we enforce
+ * in scr_write() that you can't set the NSE bit without it.
+ */
+if (cur_el == 3 && (env->cp15.scr_el3 & (SCR_NS | SCR_NSE)) == SCR_NSE) {
+goto illegal_return;
+}
+
new_el = el_from_spsr(spsr);
if (new_el == -1) {
goto illegal_return;
--
2.34.1
Re: QEMU features useful for Xen development?
Peter Maydell writes: > On Thu, 31 Aug 2023 at 10:53, Alex Bennée wrote: >> >> >> Peter Maydell writes: >> >> > On Thu, 31 Aug 2023 at 01:57, Stefano Stabellini >> > wrote: >> >> As Xen is gaining R52 and R82 support, it would be great to be able to >> >> use QEMU for development and testing there as well, but I don't think >> >> QEMU can emulate EL2 properly for the Cortex-R architecture. We would >> >> need EL2 support in the GIC/timer for R52/R82 as well. >> > >> > We do actually have a Cortex-R52 model which at least in theory >> > should include EL2 support, though as usual with newer QEMU >> > stuff it quite likely has lurking bugs; I'm not sure how much >> > testing it's had. Also there is currently no board model which >> > will work with the Cortex-R52 so it's a bit tricky to use in practice. >> > (What sort of board model would Xen want to use it with?) >> >> We already model a bunch of the mps2/mps3 images so I'm assuming adding >> the mps3-an536 would be a fairly simple step to do (mps2tz.c is mostly >> tweaking config values). The question is would it be a useful target for >> Xen? > > All our MPS2/MPS3 boards are M-profile. That means we have the > device models for all the interesting devices on the board, but > it would be simpler to write the an536 board model separately. > (In particular, the M-profile boards are wrappers around an > "ARMSSE" sort-of-like-an-SoC component; there's no equivalent > for the Cortex-R52.) > >> https://developer.arm.com/documentation/dai0536/latest/ It's not super clear from the design notes but it does mention the SSE-200 sub-system as the basis for peripherals. Specifically the blocks are: Arm Cortex-R52 Processor Arm CoreSight SoC-400 (n/a for QEMU) Cortex-M System Design Kit PL022 Serial Port NIC-400 Network interconnect But if writing it from scratch is simpler so be it. The real question is what new hardware would we need to model to be able to bring something up that is useful to Xen? >> > The Cortex-R82 would be more work, because (unlike the R52) it's >> > AArch64, and we don't have Armv8-R AArch64 support yet, only the AArch32. >> > >> > I haven't looked at whether GIC on R-profile requires any changes >> > from the A-profile GIC; on A-profile obviously we emulate the >> > virtualization support already. >> > -- Alex Bennée Virtualisation Tech Lead @ Linaro
Re: [PATCH 07/20] target/riscv/cpu.c: add .instance_post_init()
On Fri, Aug 25, 2023 at 10:08:40AM -0300, Daniel Henrique Barboza wrote:
> All generic CPUs call riscv_cpu_add_user_properties(). The 'max' CPU
> calls riscv_init_max_cpu_extensions(). Both can be moved to a common
> instance_post_init() callback, implemented in riscv_cpu_post_init(),
> called by all CPUs. The call order then becomes:
>
> riscv_cpu_init() -> cpu_init() of each CPU -> .instance_post_init()
>
> A CPU class that wants to add user flags will let us know via the
> 'user_extension_properties' property. Likewise, 'cfg.max_features' will
> determine if any given CPU, regardless of being the 'max' CPU or not,
> wants to enable the maximum amount of extensions.
>
> In the near future riscv_cpu_post_init() will call the init() function
> of the current accelerator, providing a hook for KVM and TCG accel
> classes to change the init() process of the CPU.
>
> Signed-off-by: Daniel Henrique Barboza
> ---
> target/riscv/cpu.c | 20 +++-
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index c35d58c64b..f67b782675 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -430,8 +430,6 @@ static void riscv_max_cpu_init(Object *obj)
> mlx = MXL_RV32;
> #endif
> set_misa(env, mlx, 0);
> -riscv_cpu_add_user_properties(obj);
> -riscv_init_max_cpu_extensions(obj);
> env->priv_ver = PRIV_VERSION_LATEST;
> #ifndef CONFIG_USER_ONLY
> set_satp_mode_max_supported(RISCV_CPU(obj), mlx == MXL_RV32 ?
> @@ -445,7 +443,6 @@ static void rv64_base_cpu_init(Object *obj)
> CPURISCVState *env = &RISCV_CPU(obj)->env;
> /* We set this in the realise function */
> set_misa(env, MXL_RV64, 0);
> -riscv_cpu_add_user_properties(obj);
> /* Set latest version of privileged specification */
> env->priv_ver = PRIV_VERSION_LATEST;
> #ifndef CONFIG_USER_ONLY
> @@ -569,7 +566,6 @@ static void rv128_base_cpu_init(Object *obj)
> CPURISCVState *env = &RISCV_CPU(obj)->env;
> /* We set this in the realise function */
> set_misa(env, MXL_RV128, 0);
> -riscv_cpu_add_user_properties(obj);
> /* Set latest version of privileged specification */
> env->priv_ver = PRIV_VERSION_LATEST;
> #ifndef CONFIG_USER_ONLY
> @@ -582,7 +578,6 @@ static void rv32_base_cpu_init(Object *obj)
> CPURISCVState *env = &RISCV_CPU(obj)->env;
> /* We set this in the realise function */
> set_misa(env, MXL_RV32, 0);
> -riscv_cpu_add_user_properties(obj);
> /* Set latest version of privileged specification */
> env->priv_ver = PRIV_VERSION_LATEST;
> #ifndef CONFIG_USER_ONLY
> @@ -1212,6 +1207,20 @@ static void riscv_cpu_set_irq(void *opaque, int irq,
> int level)
> }
> #endif /* CONFIG_USER_ONLY */
>
> +static void riscv_cpu_post_init(Object *obj)
> +{
> +RISCVCPU *cpu = RISCV_CPU(obj);
> +RISCVCPUClass *rcc = RISCV_CPU_GET_CLASS(cpu);
> +
> +if (rcc->user_extension_properties) {
It's not yet clear to me why we need 'user_extension_properties'. Can't we
just do the 'object_dynamic_cast(obj, TYPE_RISCV_DYNAMIC_CPU) != NULL'
check here?
> +riscv_cpu_add_user_properties(obj);
> +}
> +
> +if (cpu->cfg.max_features) {
It's also not yet clear why we need max_features. I can't think of any
other models that want max_features besides 'max'. Checking the cpu type
here should be sufficient, no?
> +riscv_init_max_cpu_extensions(obj);
> +}
> +}
> +
> static void riscv_cpu_init(Object *obj)
> {
> RISCVCPU *cpu = RISCV_CPU(obj);
> @@ -2019,6 +2028,7 @@ static const TypeInfo riscv_cpu_type_infos[] = {
> .instance_size = sizeof(RISCVCPU),
> .instance_align = __alignof__(RISCVCPU),
> .instance_init = riscv_cpu_init,
> +.instance_post_init = riscv_cpu_post_init,
> .abstract = true,
> .class_size = sizeof(RISCVCPUClass),
> .class_init = riscv_cpu_class_init,
> --
> 2.41.0
>
>
Thanks,
drew
Re: [PATCH 08/20] target/riscv: move 'host' CPU declaration to kvm.c
On Fri, Aug 25, 2023 at 10:08:41AM -0300, Daniel Henrique Barboza wrote:
> This CPU only exists if we're compiling with KVM so move it to the kvm
> specific file. While we're at it, change its class_init() to enable the
> user_extensions_flag class property, sparing us from having to execute
> riscv_cpu_add_user_properties() by hand and letting the post_init() hook
> do the work.
>
> Signed-off-by: Daniel Henrique Barboza
> ---
> target/riscv/cpu.c | 23 ---
> target/riscv/kvm.c | 29 +
> 2 files changed, 29 insertions(+), 23 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index f67b782675..dbf81796d2 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -655,19 +655,6 @@ static void rv32_imafcu_nommu_cpu_init(Object *obj)
> }
> #endif
>
> -#if defined(CONFIG_KVM)
> -static void riscv_host_cpu_init(Object *obj)
> -{
> -CPURISCVState *env = &RISCV_CPU(obj)->env;
> -#if defined(TARGET_RISCV32)
> -set_misa(env, MXL_RV32, 0);
> -#elif defined(TARGET_RISCV64)
> -set_misa(env, MXL_RV64, 0);
> -#endif
> -riscv_cpu_add_user_properties(obj);
> -}
> -#endif /* CONFIG_KVM */
> -
> static ObjectClass *riscv_cpu_class_by_name(const char *cpu_model)
> {
> ObjectClass *oc;
> @@ -2000,13 +1987,6 @@ static void riscv_vendor_cpu_class_init(ObjectClass
> *c, void *data)
> rcc->user_extension_properties = false;
> }
>
> -#define DEFINE_CPU(type_name, initfn) \
> -{ \
> -.name = type_name, \
> -.parent = TYPE_RISCV_CPU, \
> -.instance_init = initfn\
> -}
> -
> #define DEFINE_DYNAMIC_CPU(type_name, initfn) \
> { \
> .name = type_name,\
> @@ -2047,9 +2027,6 @@ static const TypeInfo riscv_cpu_type_infos[] = {
> },
> DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_ANY, riscv_any_cpu_init),
> DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_MAX, riscv_max_cpu_init),
> -#if defined(CONFIG_KVM)
> -DEFINE_CPU(TYPE_RISCV_CPU_HOST, riscv_host_cpu_init),
> -#endif
> #if defined(TARGET_RISCV32)
> DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_BASE32, rv32_base_cpu_init),
> DEFINE_VENDOR_CPU(TYPE_RISCV_CPU_IBEX, rv32_ibex_cpu_init),
> diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c
> index 7c6dec05e3..59004caa8e 100644
> --- a/target/riscv/kvm.c
> +++ b/target/riscv/kvm.c
> @@ -1217,3 +1217,32 @@ void kvm_riscv_aia_create(MachineState *machine,
> uint64_t group_shift,
>
> kvm_msi_via_irqfd_allowed = kvm_irqfds_enabled();
> }
> +
> +static void riscv_host_cpu_init(Object *obj)
> +{
> +CPURISCVState *env = &RISCV_CPU(obj)->env;
> +
> +#if defined(TARGET_RISCV32)
> +env->misa_mxl_max = env->misa_mxl = MXL_RV32;
> +#elif defined(TARGET_RISCV64)
> +env->misa_mxl_max = env->misa_mxl = MXL_RV64;
> +#endif
> +}
> +
> +static void riscv_kvm_cpu_class_init(ObjectClass *c, void *data)
> +{
> +RISCVCPUClass *rcc = RISCV_CPU_CLASS(c);
> +
> +rcc->user_extension_properties = true;
> +}
> +
> +static const TypeInfo riscv_kvm_cpu_type_infos[] = {
> +{
> +.name = TYPE_RISCV_CPU_HOST,
> +.parent = TYPE_RISCV_CPU,
> +.instance_init = riscv_host_cpu_init,
> +.class_init = riscv_kvm_cpu_class_init,
> +}
> +};
> +
> +DEFINE_TYPES(riscv_kvm_cpu_type_infos)
> --
> 2.41.0
>
>
Reviewed-by: Andrew Jones
Re: [PATCH 09/20] target/riscv/cpu.c: mark extensions arrays as 'const'
On Fri, Aug 25, 2023 at 10:08:42AM -0300, Daniel Henrique Barboza wrote:
> We'll need to export these arrays to the accelerator classes in the next
> patches. Mark them as 'const' now to minimize changes in the future.
Not to "minimize changes in the future", but "because they should
not be modified at runtime".
>
> Note that 'riscv_cpu_options' will also be exported, but can't be marked
> as 'const', because the properties are changed via
> qdev_property_add_static().
>
> Signed-off-by: Daniel Henrique Barboza
> ---
> target/riscv/cpu.c | 22 +-
> 1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index dbf81796d2..4eda853f1d 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -1381,7 +1381,7 @@ typedef struct RISCVCPUMultiExtConfig {
> {.name = _name, .offset = CPU_CFG_OFFSET(_prop), \
> .enabled = _defval}
>
> -static RISCVCPUMultiExtConfig riscv_cpu_extensions[] = {
> +static const RISCVCPUMultiExtConfig riscv_cpu_extensions[] = {
> /* Defaults for standard extensions */
> MULTI_EXT_CFG_BOOL("sscofpmf", ext_sscofpmf, false),
> MULTI_EXT_CFG_BOOL("Zifencei", ext_ifencei, true),
> @@ -1441,7 +1441,7 @@ static RISCVCPUMultiExtConfig riscv_cpu_extensions[] = {
> DEFINE_PROP_END_OF_LIST(),
> };
>
> -static RISCVCPUMultiExtConfig riscv_cpu_vendor_exts[] = {
> +static const RISCVCPUMultiExtConfig riscv_cpu_vendor_exts[] = {
> MULTI_EXT_CFG_BOOL("xtheadba", ext_xtheadba, false),
> MULTI_EXT_CFG_BOOL("xtheadbb", ext_xtheadbb, false),
> MULTI_EXT_CFG_BOOL("xtheadbs", ext_xtheadbs, false),
> @@ -1459,7 +1459,7 @@ static RISCVCPUMultiExtConfig riscv_cpu_vendor_exts[] =
> {
> };
>
> /* These are experimental so mark with 'x-' */
> -static RISCVCPUMultiExtConfig riscv_cpu_experimental_exts[] = {
> +static const RISCVCPUMultiExtConfig riscv_cpu_experimental_exts[] = {
> MULTI_EXT_CFG_BOOL("x-zicond", ext_zicond, false),
>
> /* ePMP 0.9.3 */
> @@ -1532,7 +1532,7 @@ static void cpu_get_multi_ext_cfg(Object *obj, Visitor
> *v, const char *name,
> }
>
> static void cpu_add_multi_ext_prop(Object *cpu_obj,
> - RISCVCPUMultiExtConfig *multi_cfg)
> + const RISCVCPUMultiExtConfig *multi_cfg)
> {
> object_property_add(cpu_obj, multi_cfg->name, "bool",
> cpu_get_multi_ext_cfg,
> @@ -1568,9 +1568,11 @@ static void cpu_set_cfg_unavailable(Object *obj,
> Visitor *v,
> #endif
>
> static void riscv_cpu_add_multiext_prop_array(Object *obj,
> - RISCVCPUMultiExtConfig *array)
> +const RISCVCPUMultiExtConfig *array)
> {
> -for (RISCVCPUMultiExtConfig *prop = array; prop && prop->name; prop++) {
> +const RISCVCPUMultiExtConfig *prop;
> +
> +for (prop = array; prop && prop->name; prop++) {
> cpu_add_multi_ext_prop(obj, prop);
> }
> }
> @@ -1594,9 +1596,11 @@ static void riscv_cpu_add_kvm_unavail_prop(Object
> *obj, const char *prop_name)
> }
>
> static void riscv_cpu_add_kvm_unavail_prop_array(Object *obj,
> - RISCVCPUMultiExtConfig
> *array)
> +const RISCVCPUMultiExtConfig *array)
> {
> -for (RISCVCPUMultiExtConfig *prop = array; prop && prop->name; prop++) {
> +const RISCVCPUMultiExtConfig *prop;
> +
> +for (prop = array; prop && prop->name; prop++) {
> riscv_cpu_add_kvm_unavail_prop(obj, prop->name);
> }
> }
> @@ -1659,7 +1663,7 @@ static void riscv_init_max_cpu_extensions(Object *obj)
> {
> RISCVCPU *cpu = RISCV_CPU(obj);
> CPURISCVState *env = &cpu->env;
> -RISCVCPUMultiExtConfig *prop;
> +const RISCVCPUMultiExtConfig *prop;
>
> /* Enable RVG, RVJ and RVV that are disabled by default */
> set_misa(env, env->misa_mxl, env->misa_ext | RVG | RVJ | RVV);
> --
> 2.41.0
>
>
Other than the commit message change,
Reviewed-by: Andrew Jones
Re: [PATCH 10/20] target/riscv: move riscv_cpu_add_kvm_properties() to kvm.c
On Fri, Aug 25, 2023 at 10:08:43AM -0300, Daniel Henrique Barboza wrote:
> We'll introduce the KVM accelerator class with a 'cpu_instance_init'
> implementation that is going to be invoked during the common
> riscv_cpu_post_init() (via accel_cpu_instance_init()). This
> instance_init will execute KVM exclusive code that TCG doesn't care
> about, such as adding KVM specific properties, initing registers using a
> KVM scratch CPU and so on.
>
> The core of the forementioned cpu_instance_init impl is the current
> riscv_cpu_add_kvm_properties() that is being used by the common code via
> riscv_cpu_add_user_properties() in cpu.c. Move it to kvm.c, together
> will all the relevant artifacts, exporting and renaming it to
> kvm_riscv_cpu_add_kvm_properties() so cpu.c can keep using it for now.
>
> To make this work we'll need to export riscv_cpu_extensions,
> riscv_cpu_vendor_exts and riscv_cpu_experimental_exts from cpu.c as
> well. The TCG accelerator will also need to access those in the near
> future so this export will benefit us in the long run.
>
> Signed-off-by: Daniel Henrique Barboza
> ---
> target/riscv/cpu.c | 87 +++-
> target/riscv/cpu.h | 14 +++
> target/riscv/kvm.c | 66 +-
> target/riscv/kvm_riscv.h | 2 +-
> 4 files changed, 86 insertions(+), 83 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 4eda853f1d..58b0ef2af8 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -1344,7 +1344,7 @@ static RISCVCPUMisaExtConfig misa_ext_cfgs[] = {
> MISA_CFG(RVG, false),
> };
>
> -static void riscv_cpu_add_misa_properties(Object *cpu_obj)
> +void riscv_cpu_add_misa_properties(Object *cpu_obj)
> {
> int i;
>
> @@ -1371,17 +1371,11 @@ static void riscv_cpu_add_misa_properties(Object
> *cpu_obj)
> }
> }
>
> -typedef struct RISCVCPUMultiExtConfig {
> -const char *name;
> -uint32_t offset;
> -bool enabled;
> -} RISCVCPUMultiExtConfig;
> -
> #define MULTI_EXT_CFG_BOOL(_name, _prop, _defval) \
> {.name = _name, .offset = CPU_CFG_OFFSET(_prop), \
> .enabled = _defval}
>
> -static const RISCVCPUMultiExtConfig riscv_cpu_extensions[] = {
> +const RISCVCPUMultiExtConfig riscv_cpu_extensions[] = {
> /* Defaults for standard extensions */
> MULTI_EXT_CFG_BOOL("sscofpmf", ext_sscofpmf, false),
> MULTI_EXT_CFG_BOOL("Zifencei", ext_ifencei, true),
> @@ -1441,7 +1435,7 @@ static const RISCVCPUMultiExtConfig
> riscv_cpu_extensions[] = {
> DEFINE_PROP_END_OF_LIST(),
> };
>
> -static const RISCVCPUMultiExtConfig riscv_cpu_vendor_exts[] = {
> +const RISCVCPUMultiExtConfig riscv_cpu_vendor_exts[] = {
> MULTI_EXT_CFG_BOOL("xtheadba", ext_xtheadba, false),
> MULTI_EXT_CFG_BOOL("xtheadbb", ext_xtheadbb, false),
> MULTI_EXT_CFG_BOOL("xtheadbs", ext_xtheadbs, false),
> @@ -1459,7 +1453,7 @@ static const RISCVCPUMultiExtConfig
> riscv_cpu_vendor_exts[] = {
> };
>
> /* These are experimental so mark with 'x-' */
> -static const RISCVCPUMultiExtConfig riscv_cpu_experimental_exts[] = {
> +const RISCVCPUMultiExtConfig riscv_cpu_experimental_exts[] = {
> MULTI_EXT_CFG_BOOL("x-zicond", ext_zicond, false),
>
> /* ePMP 0.9.3 */
> @@ -1487,7 +1481,7 @@ static const RISCVCPUMultiExtConfig
> riscv_cpu_experimental_exts[] = {
> DEFINE_PROP_END_OF_LIST(),
> };
>
> -static Property riscv_cpu_options[] = {
> +Property riscv_cpu_options[] = {
> DEFINE_PROP_UINT8("pmu-num", RISCVCPU, cfg.pmu_num, 16),
>
> DEFINE_PROP_BOOL("mmu", RISCVCPU, cfg.mmu, true),
> @@ -1548,25 +1542,6 @@ static void cpu_add_multi_ext_prop(Object *cpu_obj,
> multi_cfg->enabled);
> }
>
> -#ifndef CONFIG_USER_ONLY
> -static void cpu_set_cfg_unavailable(Object *obj, Visitor *v,
> -const char *name,
> -void *opaque, Error **errp)
> -{
> -const char *propname = opaque;
> -bool value;
> -
> -if (!visit_type_bool(v, name, &value, errp)) {
> -return;
> -}
> -
> -if (value) {
> -error_setg(errp, "extension %s is not available with KVM",
> - propname);
> -}
> -}
> -#endif
> -
> static void riscv_cpu_add_multiext_prop_array(Object *obj,
> const RISCVCPUMultiExtConfig *array)
> {
> @@ -1577,56 +1552,6 @@ static void riscv_cpu_add_multiext_prop_array(Object
> *obj,
> }
> }
>
> -#ifndef CONFIG_USER_ONLY
> -static void riscv_cpu_add_kvm_unavail_prop(Object *obj, const char
> *prop_name)
> -{
> -/* Check if KVM created the property already */
> -if (object_property_find(obj, prop_name)) {
> -return;
> -}
> -
> -/*
> - * Set the default to disabled for every extension
> - * unknown to KVM and error out if the user attempts
> - * to enable any of them.
> - */
> -object_property_add(obj
Re: [PATCH 11/20] target/riscv: introduce KVM AccelCPUClass
On Fri, Aug 25, 2023 at 10:08:44AM -0300, Daniel Henrique Barboza wrote:
> Add a KVM accelerator class like we did with TCG. The difference is
> that, at least for now, we won't be using a realize() implementation for
> this accelerator.
>
> We'll start by assiging kvm_riscv_cpu_add_kvm_properties(), renamed to
> kvm_cpu_instance_init(), as a 'cpu_instance_init' implementation. Change
> riscv_cpu_post_init() to invoke accel_cpu_instance_init(), which will go
> through the 'cpu_instance_init' impl of the current acceleration (if
> available) and execute it. The end result is that the KVM initial setup,
> i.e. starting registers and adding its specific properties, will be done
> via this hook.
>
> riscv_cpu_add_user_properties() is still being called via the common
> post_init() function, thus we still need the "if kvm then return" logic
> inside it for now. We'll deal with it when TCG accel class get its own
> 'cpu_instance_init' implementation.
>
> riscv_add_satp_mode_properties() is now being exported from cpu.c since
> it's a common helper between KVM and TCG.
>
> Signed-off-by: Daniel Henrique Barboza
> ---
> target/riscv/cpu.c | 8 ++---
> target/riscv/cpu.h | 1 +
> target/riscv/kvm.c | 64 +++-
> target/riscv/kvm_riscv.h | 1 -
> 4 files changed, 49 insertions(+), 25 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 58b0ef2af8..04c6bfaeef 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -1112,7 +1112,7 @@ static void cpu_riscv_set_satp(Object *obj, Visitor *v,
> const char *name,
> satp_map->init |= 1 << satp;
> }
>
> -static void riscv_add_satp_mode_properties(Object *obj)
> +void riscv_add_satp_mode_properties(Object *obj)
> {
> RISCVCPU *cpu = RISCV_CPU(obj);
>
> @@ -1199,6 +1199,8 @@ static void riscv_cpu_post_init(Object *obj)
> RISCVCPU *cpu = RISCV_CPU(obj);
> RISCVCPUClass *rcc = RISCV_CPU_GET_CLASS(cpu);
>
> +accel_cpu_instance_init(CPU(obj));
> +
> if (rcc->user_extension_properties) {
> riscv_cpu_add_user_properties(obj);
> }
> @@ -1561,12 +1563,10 @@ static void riscv_cpu_add_multiext_prop_array(Object
> *obj,
> static void riscv_cpu_add_user_properties(Object *obj)
> {
> #ifndef CONFIG_USER_ONLY
> -riscv_add_satp_mode_properties(obj);
> -
> if (kvm_enabled()) {
> -kvm_riscv_cpu_add_kvm_properties(obj);
> return;
> }
> +riscv_add_satp_mode_properties(obj);
> #endif
>
> riscv_cpu_add_misa_properties(obj);
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index b9c4bea3f7..950c2301f2 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -726,6 +726,7 @@ extern const RISCVCPUMultiExtConfig
> riscv_cpu_experimental_exts[];
> extern Property riscv_cpu_options[];
>
> void riscv_cpu_add_misa_properties(Object *cpu_obj);
> +void riscv_add_satp_mode_properties(Object *obj);
>
> /* CSR function table */
> extern riscv_csr_operations csr_ops[CSR_TABLE_SIZE];
> diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c
> index 7e67121456..3c4fa43cee 100644
> --- a/target/riscv/kvm.c
> +++ b/target/riscv/kvm.c
> @@ -31,6 +31,7 @@
> #include "sysemu/kvm_int.h"
> #include "cpu.h"
> #include "trace.h"
> +#include "hw/core/accel-cpu.h"
> #include "hw/pci/pci.h"
> #include "exec/memattrs.h"
> #include "exec/address-spaces.h"
> @@ -1262,26 +1263,6 @@ void kvm_riscv_aia_create(MachineState *machine,
> uint64_t group_shift,
> kvm_msi_via_irqfd_allowed = kvm_irqfds_enabled();
> }
>
> -void kvm_riscv_cpu_add_kvm_properties(Object *obj)
> -{
> -DeviceState *dev = DEVICE(obj);
> -
> -riscv_init_user_properties(obj);
> -riscv_cpu_add_misa_properties(obj);
> -
> -riscv_cpu_add_kvm_unavail_prop_array(obj, riscv_cpu_extensions);
> -riscv_cpu_add_kvm_unavail_prop_array(obj, riscv_cpu_vendor_exts);
> -riscv_cpu_add_kvm_unavail_prop_array(obj, riscv_cpu_experimental_exts);
> -
> -for (Property *prop = riscv_cpu_options; prop && prop->name; prop++) {
> -/* Check if KVM created the property already */
> -if (object_property_find(obj, prop->name)) {
> -continue;
> -}
> -qdev_property_add_static(dev, prop);
> -}
> -}
> -
> static void riscv_host_cpu_init(Object *obj)
> {
> CPURISCVState *env = &RISCV_CPU(obj)->env;
> @@ -1310,3 +1291,46 @@ static const TypeInfo riscv_kvm_cpu_type_infos[] = {
> };
>
> DEFINE_TYPES(riscv_kvm_cpu_type_infos)
> +
> +static void kvm_cpu_instance_init(CPUState *cs)
> +{
> +Object *obj = OBJECT(RISCV_CPU(cs));
> +DeviceState *dev = DEVICE(obj);
> +
> +riscv_init_user_properties(obj);
> +
> +riscv_add_satp_mode_properties(obj);
> +riscv_cpu_add_misa_properties(obj);
> +
> +riscv_cpu_add_kvm_unavail_prop_array(obj, riscv_cpu_extensions);
> +riscv_cpu_add_kvm_unavail_prop_array(obj, riscv_cpu_vendor_exts);
> +riscv_cpu_add_kvm_unavail_prop_arr
Re: [PATCH 12/20] target/riscv: move KVM only files to kvm subdir
On Fri, Aug 25, 2023 at 10:08:45AM -0300, Daniel Henrique Barboza wrote:
> Move the files to a 'kvm' dir to promote more code separation between
> accelerators and making our lives easier supporting build options such
> as --disable-tcg.
>
> Rename kvm.c to kvm-cpu.c to keep it in line with its TCG counterpart.
Now that we have 'kvm' and 'tcg' subdirectories, it seems like we should
be removing prefixes from files, i.e. 'kvm/cpu.c' and 'tcg/cpu.c' would be
less verbose and just as easy to identify, but whatever people like...
>
> Signed-off-by: Daniel Henrique Barboza
> ---
> hw/riscv/virt.c | 2 +-
> target/riscv/cpu.c| 2 +-
> target/riscv/{kvm.c => kvm/kvm-cpu.c} | 0
> target/riscv/{ => kvm}/kvm-stub.c | 0
> target/riscv/{ => kvm}/kvm_riscv.h| 0
> target/riscv/kvm/meson.build | 2 ++
> target/riscv/meson.build | 2 +-
> 7 files changed, 5 insertions(+), 3 deletions(-)
> rename target/riscv/{kvm.c => kvm/kvm-cpu.c} (100%)
> rename target/riscv/{ => kvm}/kvm-stub.c (100%)
> rename target/riscv/{ => kvm}/kvm_riscv.h (100%)
> create mode 100644 target/riscv/kvm/meson.build
>
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index 388e52a294..77c384ddc3 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -35,7 +35,7 @@
> #include "hw/riscv/virt.h"
> #include "hw/riscv/boot.h"
> #include "hw/riscv/numa.h"
> -#include "kvm_riscv.h"
> +#include "kvm/kvm_riscv.h"
> #include "hw/intc/riscv_aclint.h"
> #include "hw/intc/riscv_aplic.h"
> #include "hw/intc/riscv_imsic.h"
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 04c6bfaeef..bf6c8519b1 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -33,7 +33,7 @@
> #include "fpu/softfloat-helpers.h"
> #include "sysemu/kvm.h"
> #include "sysemu/tcg.h"
> -#include "kvm_riscv.h"
> +#include "kvm/kvm_riscv.h"
> #include "tcg/tcg.h"
>
> /* RISC-V CPU definitions */
> diff --git a/target/riscv/kvm.c b/target/riscv/kvm/kvm-cpu.c
> similarity index 100%
> rename from target/riscv/kvm.c
> rename to target/riscv/kvm/kvm-cpu.c
> diff --git a/target/riscv/kvm-stub.c b/target/riscv/kvm/kvm-stub.c
> similarity index 100%
> rename from target/riscv/kvm-stub.c
> rename to target/riscv/kvm/kvm-stub.c
> diff --git a/target/riscv/kvm_riscv.h b/target/riscv/kvm/kvm_riscv.h
> similarity index 100%
> rename from target/riscv/kvm_riscv.h
> rename to target/riscv/kvm/kvm_riscv.h
> diff --git a/target/riscv/kvm/meson.build b/target/riscv/kvm/meson.build
> new file mode 100644
> index 00..1cd6783894
> --- /dev/null
> +++ b/target/riscv/kvm/meson.build
> @@ -0,0 +1,2 @@
> +riscv_ss.add(when: 'CONFIG_KVM', if_true: files('kvm-cpu.c'),
> + if_false: files('kvm-stub.c'))
> diff --git a/target/riscv/meson.build b/target/riscv/meson.build
> index f0486183fa..c53962215f 100644
> --- a/target/riscv/meson.build
> +++ b/target/riscv/meson.build
> @@ -24,7 +24,6 @@ riscv_ss.add(files(
>'zce_helper.c',
>'vcrypto_helper.c'
> ))
> -riscv_ss.add(when: 'CONFIG_KVM', if_true: files('kvm.c'), if_false:
> files('kvm-stub.c'))
>
> riscv_system_ss = ss.source_set()
> riscv_system_ss.add(files(
> @@ -39,6 +38,7 @@ riscv_system_ss.add(files(
> ))
>
> subdir('tcg')
> +subdir('kvm')
>
> target_arch += {'riscv': riscv_ss}
> target_softmmu_arch += {'riscv': riscv_system_ss}
> --
> 2.41.0
>
>
Reviewed-by: Andrew Jones
Re: [PATCH 13/20] target/riscv/kvm: refactor kvm_riscv_init_user_properties()
On Fri, Aug 25, 2023 at 10:08:46AM -0300, Daniel Henrique Barboza wrote:
> The function is doing way more than just init user properties. We would
> also like to use the 'user_extension_properties' class property, as the
> TCG driver is already using, to decide whether KVM should expose user
> properties or not.
>
> Rename kvm_riscv_init_user_properties() to riscv_init_kvm_registers()
> and leave only the essential, non-optional KVM init functions there. All
> functions that deals with property handling is now gated via
> rcc->user_extension_properties.
>
> Signed-off-by: Daniel Henrique Barboza
> ---
> target/riscv/kvm/kvm-cpu.c | 19 +++
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
> index 3c4fa43cee..85e8b0a927 100644
> --- a/target/riscv/kvm/kvm-cpu.c
> +++ b/target/riscv/kvm/kvm-cpu.c
> @@ -792,7 +792,7 @@ static void kvm_riscv_init_multiext_cfg(RISCVCPU *cpu,
> KVMScratchCPU *kvmcpu)
> }
> }
>
> -static void riscv_init_user_properties(Object *cpu_obj)
> +static void riscv_init_kvm_registers(Object *cpu_obj)
> {
> RISCVCPU *cpu = RISCV_CPU(cpu_obj);
> KVMScratchCPU kvmcpu;
> @@ -801,7 +801,6 @@ static void riscv_init_user_properties(Object *cpu_obj)
> return;
> }
>
> -kvm_riscv_add_cpu_user_properties(cpu_obj);
> kvm_riscv_init_machine_ids(cpu, &kvmcpu);
> kvm_riscv_init_misa_ext_mask(cpu, &kvmcpu);
> kvm_riscv_init_multiext_cfg(cpu, &kvmcpu);
> @@ -1295,16 +1294,20 @@ DEFINE_TYPES(riscv_kvm_cpu_type_infos)
> static void kvm_cpu_instance_init(CPUState *cs)
> {
> Object *obj = OBJECT(RISCV_CPU(cs));
> +RISCVCPUClass *rcc = RISCV_CPU_GET_CLASS(obj);
> DeviceState *dev = DEVICE(obj);
>
> -riscv_init_user_properties(obj);
> +riscv_init_kvm_registers(obj);
>
> -riscv_add_satp_mode_properties(obj);
> -riscv_cpu_add_misa_properties(obj);
> +if (rcc->user_extension_properties) {
> +kvm_riscv_add_cpu_user_properties(obj);
> +riscv_add_satp_mode_properties(obj);
> +riscv_cpu_add_misa_properties(obj);
>
> -riscv_cpu_add_kvm_unavail_prop_array(obj, riscv_cpu_extensions);
> -riscv_cpu_add_kvm_unavail_prop_array(obj, riscv_cpu_vendor_exts);
> -riscv_cpu_add_kvm_unavail_prop_array(obj, riscv_cpu_experimental_exts);
> +riscv_cpu_add_kvm_unavail_prop_array(obj, riscv_cpu_extensions);
> +riscv_cpu_add_kvm_unavail_prop_array(obj, riscv_cpu_vendor_exts);
> +riscv_cpu_add_kvm_unavail_prop_array(obj,
> riscv_cpu_experimental_exts);
> +}
>
> for (Property *prop = riscv_cpu_options; prop && prop->name; prop++) {
> /* Check if we have a specific KVM handler for the option */
> --
> 2.41.0
>
>
Reviewed-by: Andrew Jones
Re: QEMU features useful for Xen development?
On Thu, 31 Aug 2023 at 11:49, Alex Bennée wrote: > Peter Maydell writes: > > All our MPS2/MPS3 boards are M-profile. That means we have the > > device models for all the interesting devices on the board, but > > it would be simpler to write the an536 board model separately. > > (In particular, the M-profile boards are wrappers around an > > "ARMSSE" sort-of-like-an-SoC component; there's no equivalent > > for the Cortex-R52.) > > > >> https://developer.arm.com/documentation/dai0536/latest/ > > It's not super clear from the design notes but it does mention the > SSE-200 sub-system as the basis for peripherals. Specifically the blocks > are: > > Arm Cortex-R52 Processor > Arm CoreSight SoC-400 (n/a for QEMU) > Cortex-M System Design Kit > PL022 Serial Port > NIC-400 Network interconnect > > But if writing it from scratch is simpler so be it. The real question is > what new hardware would we need to model to be able to bring something > up that is useful to Xen? Just the board, basically. The SSE-200 is specifically a dual-Cortex-M33 block; all the references to it in the AN536 appnote look like cases where text wasn't sufficiently cleaned up when creating it based on the M-profile doc... -- PMM
