On Thu, Mar 30, 2023 at 8:33 AM Andrew Melnychenko wrote:
>
> This series of patches provides the ability to retrieve eBPF program
> through qmp, so management application may load bpf blob with proper
> capabilities.
> Now, virtio-net devices can accept eBPF programs and maps through properties
On Thu, Mar 30, 2023 at 2:53 PM Jason Wang wrote:
>
> On Thu, Mar 30, 2023 at 8:33 AM Andrew Melnychenko wrote:
> >
> > Changed eBPF map updates through mmaped array.
> > Mmaped arrays provide direct access to map data.
> > It should omit using bpf_map_update_elem() call,
> > which may require ca
On Thu, Mar 30, 2023 at 8:33 AM Andrew Melnychenko wrote:
>
> Now, the binary objects may be retrieved by id/name.
> It would require for future qmp commands that may require specific
> eBPF blob.
>
> Signed-off-by: Andrew Melnychenko
> ---
> ebpf/ebpf.c | 48 +++
On Thu, Mar 30, 2023 at 8:33 AM Andrew Melnychenko wrote:
>
> Changed eBPF map updates through mmaped array.
> Mmaped arrays provide direct access to map data.
> It should omit using bpf_map_update_elem() call,
> which may require capabilities that are not present.
This requires kernel support, s
On Thu, Mar 30, 2023 at 2:20 PM Jason Wang wrote:
>
> On Fri, Mar 24, 2023 at 3:54 AM Eugenio Pérez wrote:
> >
> > Evaluating it at start time instead of initialization time may make the
> > guest capable of dynamically adding or removing migration blockers.
> >
> > Also, moving to initialization
On Fri, Mar 24, 2023 at 3:54 AM Eugenio Pérez wrote:
>
> Evaluating it at start time instead of initialization time may make the
> guest capable of dynamically adding or removing migration blockers.
>
> Also, moving to initialization reduces the number of ioctls in the
> migration, reducing failur
On Fri, Mar 24, 2023 at 3:54 AM Eugenio Pérez wrote:
>
> This allows to set the features of a vhost-vdpa device from external
> subsystems like vhost-net. It is used in subsequent patches to
> negotiate features and probe for CVQ ASID isolation.
>
> Reviewed-by: Stefano Garzarella
> Signed-off-b
On Fri, Mar 24, 2023 at 3:54 AM Eugenio Pérez wrote:
>
> We need to tell in the caller, as some errors are expected in a normal
> workflow. In particular, parent drivers in recent kernels with
> VHOST_BACKEND_F_IOTLB_ASID may not support vring groups. In that case,
> -ENOTSUP is returned.
>
> Th
Hi,
On 2023-03-27 07:50:29, Kautuk Consul wrote:
> Avocado version 101.0 has a fix to re-compute the checksum
> of an asset file if the algorithm used in the *-CHECKSUM
> file isn't the same as the one being passed to it by the
> avocado user (i.e. the avocado_qemu python module).
> In the earlier
decode_save_opc() will not work for generate_exception(), since 0 is passed
to riscv_raise_exception() as pc in helper_raise_exception(), and bins will
not be restored in this case.
Signed-off-by: Weiwei Li
Signed-off-by: Junqiang Wang
---
target/riscv/insn_trans/trans_rvh.c.inc | 2 ++
1 file
From: Ninad Palsule
Qemu already supports devices attached to ISA and sysbus. This drop adds
support for the I2C bus attached TPM devices.
This commit includes changes for the common code.
- Added support for the new checksum registers which are required for
the I2C support. The checksum calcu
From: Ninad Palsule
This is a documentation change for I2C TPM device support.
Qemu already supports devices attached to ISA and sysbus.
This drop adds support for the I2C bus attached TPM devices.
Signed-off-by: Ninad Palsule
Reviewed-by: Stefan Berger
Reviewed-by: Cédric Le Goater
Reviewed
Hello,
Incorporated review comments from Stefan. Please review.
This drop adds support for the TPM devices attached to the I2C bus. It
only supports the TPM2 protocol. You need to run it with the external
TPM emulator like swtpm. I have tested it with swtpm.
I have refered to the work done by zhd
From: Ninad Palsule
Qemu already supports devices attached to ISA and sysbus. This drop adds
support for the I2C bus attached TPM devices. I2C model only supports
TPM2 protocol.
This commit includes changes for the common code.
- Added I2C emulation model. Logic was added in the model to tempora
On Wed, Mar 29, 2023, 9:00 AM Andreas Schwab wrote:
> Do not reverse the order of environment variables in the target environ
> array relative to the incoming environ order. Some testsuites depend on a
> specific order, even though it is not defined by any standard.
>
> Signed-off-by: Andreas Sc
On 2023/3/30 01:28, Daniel Henrique Barboza wrote:
We don't have MISA extensions in isa_edata_arr[] anymore. Remove the
redundant 'multi_letter' field from isa_ext_data.
Suggested-by: Weiwei Li
Signed-off-by: Daniel Henrique Barboza
---
Reviewed-by: Weiwei Li
Weiwei Li
target/riscv/cpu
On 2023/3/30 00:36, Richard Henderson wrote:
On 3/28/23 20:23, Weiwei Li wrote:
Transform the fetch address in cpu_get_tb_cpu_state() when pointer
mask for instruction is enabled.
Enable PC-relative translation when J is enabled.
Signed-off-by: Weiwei Li
Signed-off-by: Junqiang Wang
---
t
On 2023/3/30 00:27, Richard Henderson wrote:
On 3/28/23 20:23, Weiwei Li wrote:
static bool trans_auipc(DisasContext *ctx, arg_auipc *a)
{
- gen_set_gpri(ctx, a->rd, a->imm + ctx->base.pc_next);
+ assert(ctx->pc_save != -1);
+ if (tb_cflags(ctx->base.tb) & CF_PCREL) {
+ TCG
On 2023/3/29 23:33, Richard Henderson wrote:
On 3/28/23 20:23, Weiwei Li wrote:
We should sync cpu_pc before storing it into badaddr when mis-aligned
exception is triggered.
Signed-off-by: Weiwei Li
Signed-off-by: Junqiang Wang
---
target/riscv/insn_trans/trans_rvi.c.inc | 1 +
target/ri
Now, the binary objects may be retrieved by id/name.
It would require for future qmp commands that may require specific
eBPF blob.
Signed-off-by: Andrew Melnychenko
---
ebpf/ebpf.c | 48
ebpf/ebpf.h | 25 +
ebpf/e
eBPF RSS program and maps may now be passed during initialization.
Initially was implemented for libvirt to launch qemu without permissions,
and initialized eBPF program through the helper.
Signed-off-by: Andrew Melnychenko
---
hw/net/virtio-net.c| 77
Updated section name, so libbpf should init/gues proper
program type without specifications during open/load.
Signed-off-by: Andrew Melnychenko
---
ebpf/rss.bpf.skeleton.h | 1469 ---
tools/ebpf/rss.bpf.c|2 +-
2 files changed, 741 insertions(+), 730 d
Added command "request-ebpf". This command returns
eBPF program encoded base64. The program taken from the
skeleton and essentially is an ELF object that can be
loaded in the future with libbpf.
Signed-off-by: Andrew Melnychenko
---
monitor/qmp-cmds.c | 17 +
qapi/misc.json |
Changed eBPF map updates through mmaped array.
Mmaped arrays provide direct access to map data.
It should omit using bpf_map_update_elem() call,
which may require capabilities that are not present.
Signed-off-by: Andrew Melnychenko
---
ebpf/ebpf_rss-stub.c | 6 +++
ebpf/ebpf_rss.c | 120 +
This series of patches provides the ability to retrieve eBPF program
through qmp, so management application may load bpf blob with proper
capabilities.
Now, virtio-net devices can accept eBPF programs and maps through properties
as external file descriptors. Access to the eBPF map is direct throug
On Wed, 29 Mar 2023, Volker Rümelin wrote:
Am 29.03.23 um 21:20 schrieb BALATON Zoltan:
On Tue, 28 Mar 2023, Volker Rümelin wrote:
it seems your Mac uses a 48kHz sample rate, although QEMU requested a
44.1kHz sample rate. Could you add -audiodev
coreaudio,id=audio0,out.frequency=48000 to your
Am 29.03.23 um 21:20 schrieb BALATON Zoltan:
On Tue, 28 Mar 2023, Volker Rümelin wrote:
it seems your Mac uses a 48kHz sample rate, although QEMU requested a
44.1kHz sample rate. Could you add -audiodev
coreaudio,id=audio0,out.frequency=48000 to your command line and test
if the playback speed
On 2023/03/08 11:25, Damian Hobson-Garcia wrote:
When multiple outputs are enabled using the "max_outputs" attribute,
only the first connector appears as "Connected" in the guest DRM
device. Additional connectors must be enabled from the host side
UI frontend before they are usable by the guest.
Alex Bennée writes:
> From: David Woodhouse
>
> Exercise guests with a few different modes for interrupt delivery. In
> particular we want to cover:
>
> • Xen event channel delivery via GSI to the I/O APIC
> • Xen event channel delivery via GSI to the i8259 PIC
> • MSIs routed to PIRQ event
On 3/29/23 17:08, Daniel Henrique Barboza wrote:
Hi,
This series contains changes proposed by Weiwei Li in v5.
All patches are acked.
I forgot to mention: this series is based on:
"[PATCH v3 00/20] remove MISA ext_N flags from cpu->cfg"
Daniel
Changes from v5:
- patch 9:
- remove
Let's remove more code that is open coded in riscv_cpu_realize() and put
it into a helper. Let's also add an error message instead of just
asserting out if env->misa_mxl_max != env->misa_mlx.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: LIU Zhiwei
Reviewed-by: Weiwei Li
---
target/riscv
All these generic CPUs are using the latest priv available, at this
moment PRIV_VERSION_1_12_0:
- riscv_any_cpu_init()
- rv32_base_cpu_init()
- rv64_base_cpu_init()
- rv128_base_cpu_init()
Create a new PRIV_VERSION_LATEST enum and use it in those cases. I'll
make it easier to update everything at
We're doing env->priv_spec validation and assignment at the start of
riscv_cpu_realize(), which is fine, but then we're doing a force disable
on extensions that aren't compatible with the priv version.
This second step is being done too early. The disabled extensions might be
re-enabled again in r
We have 4 config settings being done in riscv_cpu_init(): ext_ifencei,
ext_icsr, mmu and pmp. This is also the constructor of the "riscv-cpu"
device, which happens to be the parent device of every RISC-V cpu.
The result is that these 4 configs are being set every time, and every
other CPU should a
Hi,
This series contains changes proposed by Weiwei Li in v5.
All patches are acked.
Changes from v5:
- patch 9:
- remove ext_ifencei setting from rv64_thead_c906_cpu_init()
- v5 link: https://lists.gnu.org/archive/html/qemu-devel/2023-03/msg06740.html
Daniel Henrique Barboza (9):
target/ri
There is no need to init timers if we're not even sure that our
extensions are valid. Execute riscv_cpu_validate_set_extensions() before
riscv_timer_init().
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: LIU Zhiwei
Reviewed-by: Weiwei Li
---
target/riscv/cpu.c | 11 ---
1 file cha
write_misa() must use as much common logic as possible. We want to open
code just the bits that are exclusive to the CSR write operation and TCG
internals.
Our validation is done with riscv_cpu_validate_set_extensions(), but we
need a small tweak first. When enabling RVG we're doing:
env-
The RVV verification will error out if fails and it's being done at the
end of riscv_cpu_validate_set_extensions(), after we've already set some
extensions that are dependent on RVV. Let's put it in its own function
and do it earlier.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: LIU Zhiwe
This setter is doing nothing else but setting env->vext_ver. Assign the
value directly.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: LIU Zhiwei
Reviewed-by: Weiwei Li
---
target/riscv/cpu.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/target/riscv/cpu.c b/ta
The setter is doing nothing special. Just set env->priv_ver directly.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: LIU Zhiwei
Reviewed-by: Weiwei Li
---
target/riscv/cpu.c | 29 -
1 file changed, 12 insertions(+), 17 deletions(-)
diff --git a/target/riscv/cp
Am 29.03.23 um 14:03 schrieb Rene Engel:
After short tests with the command line -audiodev
coreaudio,id=audio0,out.frequency=48000 the sound output runs in the correct
speed.
Tested with one and the same mp3 file under AmigaOs4.1 and MacOs with es1370
and ac97 on Pegasos 2 emulation
This in
The function is now a no-op for all cpu_init() callers that are setting
a non-zero misa value in set_misa(), since it's no longer used to sync
cpu->cfg props with env->misa_ext bits. Remove it in those cases.
While we're at it, rename the function to match what it's actually
doing: create user pro
Create a new "m" RISCVCPUMisaExtConfig property that will update
env->misa_ext* with RVM. Instances of cpu->cfg.ext_m and similar are
replaced with riscv_has_ext(env, RVM).
Remove the old "m" property and 'ext_m' from RISCVCPUConfig.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Weiwei Li
We're still have one RISCVCPUConfig MISA flag, 'ext_g'. We'll remove it
the same way we did with the others: create a "g" RISCVCPUMisaExtConfig
property, remove the old "g" property, remove all instances of 'cfg.ext_g'
and use riscv_has_ext(env, RVG).
The caveat is that we don't have RVG, so add i
Create a new "v" RISCVCPUMisaExtConfig property that will update
env->misa_ext* with RVV. Instances of cpu->cfg.ext_v and similar are
replaced with riscv_has_ext(env, RVV).
Remove the old "v" property and 'ext_v' from RISCVCPUConfig.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Weiwei Li
The code that disables extensions if there's a priv version mismatch
uses cpu->cfg.ext_N properties to do its job.
We're aiming to not rely on cpu->cfg.ext_N props for MISA bits. Split
the MISA related verifications in a new function, removing it from
isa_edata_arr[].
We're also erroring it out i
Create a new "i" RISCVCPUMisaExtConfig property that will update
env->misa_ext* with RVI. Instances of cpu->cfg.ext_i and similar are
replaced with riscv_has_ext(env, RVI).
Remove the old "i" property and 'ext_i' from RISCVCPUConfig.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Weiwei Li
Create a new "e" RISCVCPUMisaExtConfig property that will update
env->misa_ext* with RVE. Instances of cpu->cfg.ext_e and similar are
replaced with riscv_has_ext(env, RVE).
Remove the old "e" property and 'ext_e' from RISCVCPUConfig.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Weiwei Li
Create a new "s" RISCVCPUMisaExtConfig property that will update
env->misa_ext* with RVS. Instances of cpu->cfg.ext_s and similar are
replaced with riscv_has_ext(env, RVS).
Remove the old "s" property and 'ext_s' from RISCVCPUConfig.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Weiwei Li
We don't have MISA extensions in isa_edata_arr[] anymore. Remove the
redundant 'multi_letter' field from isa_ext_data.
Suggested-by: Weiwei Li
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c | 118 ++---
1 file changed, 58 insertions(+), 60
Create a new "u" RISCVCPUMisaExtConfig property that will update
env->misa_ext* with RVU. Instances of cpu->cfg.ext_u and similar are
replaced with riscv_has_ext(env, RVU).
Remove the old "u" property and 'ext_u' from RISCVCPUConfig.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Weiwei Li
Hi,
This new version has a new patch (3) that removes the 'multi_letter'
attribute from isa_ext_data that became redundant after the changes made
in patch 2. The change was proposed by Weiwei Li in the v2.
All patches but patch 3 are acked.
Changes from v2:
- patch 3 (new)
- remove 'multi_lett
Create a new "d" RISCVCPUMisaExtConfig property that will update
env->misa_ext* with RVD. Instances of cpu->cfg.ext_d and similar are
replaced with riscv_has_ext(env, RVD).
Remove the old "d" property and 'ext_d' from RISCVCPUConfig.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Weiwei Li
Create a new "j" RISCVCPUMisaExtConfig property that will update
env->misa_ext* with RVJ. Instances of cpu->cfg.ext_j and similar are
replaced with riscv_has_ext(env, RVJ).
Remove the old "j" property and 'ext_j' from RISCVCPUConfig.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Weiwei Li
Create a new "h" RISCVCPUMisaExtConfig property that will update
env->misa_ext* with RVH. Instances of cpu->cfg.ext_h and similar are
replaced with riscv_has_ext(env, RVH).
Remove the old "h" property and 'ext_h' from RISCVCPUConfig.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Weiwei Li
This function was created to move the sync between cpu->cfg.ext_N bit
changes to env->misa_ext* from the validation step to an ealier step,
giving us a guarantee that we could use either cpu->cfg.ext_N or
riscv_has_ext(env,N) in the validation.
We don't have any cpu->cfg.ext_N left that has an exi
This CPU is enabling G via cfg.ext_g and, at the same time, setting
IMAFD in set_misa() and cfg.ext_icsr.
riscv_cpu_validate_set_extensions() is already doing that, so there's no
need for cpu_init() setups to worry about setting G and its extensions.
Signed-off-by: Daniel Henrique Barboza
Review
Create a new "c" RISCVCPUMisaExtConfig property that will update
env->misa_ext* with RVC. Instances of cpu->cfg.ext_c and similar are
replaced with riscv_has_ext(env, RVC).
Remove the old "c" property and 'ext_c' from RISCVCPUConfig.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Weiwei Li
Create a new "a" RISCVCPUMisaExtConfig property that will update
env->misa_ext* with RVA. Instances of cpu->cfg.ext_a and similar are
replaced with riscv_has_ext(env, RVA).
Remove the old "a" property and 'ext_a' from RISCVCPUConfig.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Weiwei Li
Create a new "f" RISCVCPUMisaExtConfig property that will update
env->misa_ext* with RVF. Instances of cpu->cfg.ext_f and similar are
replaced with riscv_has_ext(env, RVF).
Remove the old "f" property and 'ext_f' from RISCVCPUConfig.
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Weiwei Li
Ever since RISCVCPUConfig got introduced users are able to set CPU extensions
in the command line. User settings are reflected in the cpu->cfg object
for later use. These properties are used in the target/riscv/cpu.c code,
most notably in riscv_cpu_validate_set_extensions(), where most of our
reali
When riscv_cpu_realize() starts we're guaranteed to have cpu->cfg.ext_N
properties updated. The same can't be said about env->misa_ext*, since
the user might enable/disable MISA extensions in the command line, and
env->misa_ext* won't caught these changes. The current solution is to
sync everything
On 29/3/23 18:48, Rob Landley wrote:
On 3/29/23 11:07, Philippe Mathieu-Daudé wrote:
On 29/3/23 18:09, Rob Landley wrote:
On 3/28/23 12:02, Philippe Mathieu-Daudé wrote:
On 20/3/23 17:58, Nathan Chancellor wrote:
On Wed, Mar 08, 2023 at 12:33:38AM +0100, Philippe Mathieu-Daudé wrote:
On 23
Daniel P. Berrangé writes:
> Currently our NetBSD VM recipe requests instal of the python37 package
> and explicitly tells QEMU to use that version of python. Since the
> NetBSD base ISO was updated to version 9.3 though, the default system
> python version is 3.9 which is sufficiently new for
Daniel P. Berrangé writes:
> The 'check' script will use "#!/usr/bin/env python3" by default
> to locate python, but this doesn't work in distros which lack a
> bare 'python3' binary like NetBSD.
>
> We need to explicitly invoke 'check' by referring to the 'python'
> variable in meson, which re
Philippe Mathieu-Daudé writes:
> It is pointless to build libgdb_user.fa in a system-only build
> (or libgdb_softmmu.fa in a user-only build). Besides, in some
> restricted build configurations, some APIs might be restricted /
> not available. Example in a KVM-only builds where TCG is disabled:
On Wed, Mar 29, 2023 at 08:19:22AM -0500, Eric DeVolder wrote:
>
>
> On 3/29/23 08:16, Eric DeVolder wrote:
> >
> >
> > On 3/29/23 00:03, Michael S. Tsirkin wrote:
> > > On Tue, Mar 28, 2023 at 11:59:26AM -0400, Eric DeVolder wrote:
> > > > Currently i386 QEMU generates MADT revision 3, and rep
On Wed, Mar 29, 2023 at 08:14:37AM -0500, Eric DeVolder wrote:
>
>
> On 3/29/23 00:19, Michael S. Tsirkin wrote:
> > Hmm I don't think we can reasonably make such a change for 8.0.
> > Seems too risky.
> > Also, I feel we want to have an internal (with "x-" prefix") flag to
> > revert to old beha
> -Original Message-
> From: Alex Bennée
> Sent: Wednesday, March 29, 2023 10:34 AM
> To: Marco Liebel (QUIC)
> Cc: Taylor Simpson ; qemu-devel@nongnu.org
> Subject: Re: [PATCH] Use hexagon toolchain version 16.0.0
>
> Marco Liebel writes:
>
> > Signed-off-by: Marco Liebel
> > ---
>
On 3/29/23 09:18, Philippe Mathieu-Daudé wrote:
It is pointless to build libgdb_user.fa in a system-only build
(or libgdb_softmmu.fa in a user-only build). Besides, in some
restricted build configurations, some APIs might be restricted /
not available. Example in a KVM-only builds where TCG is di
On 3/28/23 20:23, Weiwei Li wrote:
Transform the fetch address in cpu_get_tb_cpu_state() when pointer
mask for instruction is enabled.
Enable PC-relative translation when J is enabled.
Signed-off-by: Weiwei Li
Signed-off-by: Junqiang Wang
---
target/riscv/cpu.c| 4
target/risc
Marco Liebel writes:
> Signed-off-by: Marco Liebel
> ---
> tests/docker/dockerfiles/debian-hexagon-cross.docker | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/docker/dockerfiles/debian-hexagon-cross.docker
> b/tests/docker/dockerfiles/debian-hexagon-cross.docke
On 3/29/23 11:07, Philippe Mathieu-Daudé wrote:
> On 29/3/23 18:09, Rob Landley wrote:
>> On 3/28/23 12:02, Philippe Mathieu-Daudé wrote:
>>> On 20/3/23 17:58, Nathan Chancellor wrote:
On Wed, Mar 08, 2023 at 12:33:38AM +0100, Philippe Mathieu-Daudé wrote:
> On 23/2/23 17:19, Jiaxun Yan
On 3/28/23 20:23, Weiwei Li wrote:
static bool trans_auipc(DisasContext *ctx, arg_auipc *a)
{
-gen_set_gpri(ctx, a->rd, a->imm + ctx->base.pc_next);
+assert(ctx->pc_save != -1);
+if (tb_cflags(ctx->base.tb) & CF_PCREL) {
+TCGv target_pc = tcg_temp_new();
dest_gpr(s, a->r
Le 28/03/2023 à 14:22, Luca Bonissi a écrit :
On 28/03/23 13:55, Thomas Huth wrote:
On 28/03/2023 13.48, Luca Bonissi wrote:
--- qemu-20230327/linux-user/syscall_defs.h 2023-03-27 15:41:42.0
+0200
+++ qemu-20230327/linux-user/syscall_defs.h.new 2023-03-27
21:43:25.615115126 +020
It is pointless to build libgdb_user.fa in a system-only build
(or libgdb_softmmu.fa in a user-only build). Besides, in some
restricted build configurations, some APIs might be restricted /
not available. Example in a KVM-only builds where TCG is disabled:
$ ninja qemu-system-x86_64
[99/2187]
On 3/29/23 03:55, Thomas Huth wrote:
> On 28/03/2023 19.02, Philippe Mathieu-Daudé wrote:
>> On 20/3/23 17:58, Nathan Chancellor wrote:
>>> On Wed, Mar 08, 2023 at 12:33:38AM +0100, Philippe Mathieu-Daudé wrote:
On 23/2/23 17:19, Jiaxun Yang wrote:
> 145e2198d749 ("hw/mips/gt64xxx_pci:
On 29/3/23 17:00, Andreas Schwab wrote:
Do not reverse the order of environment variables in the target environ
array relative to the incoming environ order. Some testsuites depend on a
specific order, even though it is not defined by any standard.
Signed-off-by: Andreas Schwab
---
bsd-user/
On 29/3/23 18:09, Rob Landley wrote:
On 3/28/23 12:02, Philippe Mathieu-Daudé wrote:
On 20/3/23 17:58, Nathan Chancellor wrote:
On Wed, Mar 08, 2023 at 12:33:38AM +0100, Philippe Mathieu-Daudé wrote:
On 23/2/23 17:19, Jiaxun Yang wrote:
145e2198d749 ("hw/mips/gt64xxx_pci: Endian-swap using PC
On 23/3/23 11:05, Philippe Mathieu-Daudé wrote:
Hi Alex, Paolo,
On 7/3/23 22:21, Alex Bennée wrote:
Now we have removed any target specific bits from the core gdbstub
code we only need to build it twice. We have to jump a few meson hoops
to manually define the CONFIG_USER_ONLY symbol but it see
On 3/28/23 12:02, Philippe Mathieu-Daudé wrote:
> On 20/3/23 17:58, Nathan Chancellor wrote:
>> On Wed, Mar 08, 2023 at 12:33:38AM +0100, Philippe Mathieu-Daudé wrote:
>>> On 23/2/23 17:19, Jiaxun Yang wrote:
145e2198d749 ("hw/mips/gt64xxx_pci: Endian-swap using PCI_HOST_BRIDGE
MemoryRegi
On 3/28/23 20:23, Weiwei Li wrote:
We should sync cpu_pc before storing it into badaddr when mis-aligned
exception is triggered.
Signed-off-by: Weiwei Li
Signed-off-by: Junqiang Wang
---
target/riscv/insn_trans/trans_rvi.c.inc | 1 +
target/riscv/translate.c| 1 +
2 files c
On 3/29/23 21:53, Bui Quang Minh wrote:
On 3/28/23 22:58, Bui Quang Minh wrote:
On 3/27/23 23:49, David Woodhouse wrote:
On Mon, 2023-03-27 at 23:35 +0700, Bui Quang Minh wrote:
On 3/27/23 23:22, David Woodhouse wrote:
On Mon, 2023-03-27 at 22:45 +0700, Bui Quang Minh wrote:
Maybe I'm misr
On 3/28/23 20:24, gaosong wrote:
I also think we could make use of (__typeof(Vd->E1(0))) instead of separately passing
the output type? It would appear to be less error-prone.
I will try this on v3.
Consider using local typedefs, e.g.
typedef __typeof(Vd->E1(0)) TD;
r~
On 3/29/23 02:59, gaosong wrote:
在 2023/3/29 上午3:59, Richard Henderson 写道:
On 3/27/23 20:05, Song Gao wrote:
+ func(mop, vd_ofs, vj_ofs, vk_ofs, 16, 16);
Oh, reading about ASXD and 256-bit vectors makes me wonder if it would be better to plan
ahead and have a function, or DisasContext me
On 3/29/23 05:32, liweiwei wrote:
On 2023/3/28 06:49, Daniel Henrique Barboza wrote:
The code that disables extensions if there's a priv version mismatch
uses cpu->cfg.ext_N properties to do its job.
We're aiming to not rely on cpu->cfg.ext_N props for MISA bits. Split
the MISA related veri
Do not reverse the order of environment variables in the target environ
array relative to the incoming environ order. Some testsuites depend on a
specific order, even though it is not defined by any standard.
Signed-off-by: Andreas Schwab
---
bsd-user/main.c | 10 +-
linux-user/main.c
> -Original Message-
> From: qemu-devel-bounces+bcain=quicinc@nongnu.org bounces+bcain=quicinc@nongnu.org> On Behalf Of Marco Liebel
> Sent: Wednesday, March 29, 2023 9:21 AM
> To: qemu-devel@nongnu.org
> Cc: Taylor Simpson ; Marco Liebel (QUIC)
>
> Subject: [PATCH] Use hexagon
On 3/29/23 03:19, Weiwei Li wrote:
Function get_physical_address() translates both virtual address and
guest physical address, and the latter is 34-bits for Sv32x4. So we
should use vaddr type for 'addr' parameter.
Signed-off-by: Weiwei Li
Signed-off-by: Junqiang Wang
---
target/riscv/cpu_help
On 3/28/23 22:58, Bui Quang Minh wrote:
On 3/27/23 23:49, David Woodhouse wrote:
On Mon, 2023-03-27 at 23:35 +0700, Bui Quang Minh wrote:
On 3/27/23 23:22, David Woodhouse wrote:
On Mon, 2023-03-27 at 22:45 +0700, Bui Quang Minh wrote:
Maybe I'm misreading the patch, but to me it looks that
On Mär 29 2023, Philippe Mathieu-Daudé wrote:
> On 29/3/23 16:00, Daniel P. Berrangé wrote:
>> On Wed, Mar 29, 2023 at 03:55:13PM +0200, Andreas Schwab wrote:
>>> Do not reverse the order of environment variables in the target environ
>>> array relative to the incoming environ order. Some testsui
On Wed, Mar 29, 2023, 4:00 PM Daniel P. Berrangé
wrote:
> On Wed, Mar 29, 2023 at 03:55:13PM +0200, Andreas Schwab wrote:
> > Do not reverse the order of environment variables in the target environ
> > array relative to the incoming environ order. Some testsuites depend on
> a
> > specific order
Signed-off-by: Marco Liebel
---
tests/docker/dockerfiles/debian-hexagon-cross.docker | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/docker/dockerfiles/debian-hexagon-cross.docker
b/tests/docker/dockerfiles/debian-hexagon-cross.docker
index 5308ccb8fe..b99d99f943 100644
On 22/3/23 18:55, Titus Rwantare wrote:
Devices models calling pmbus_send_string can't be relied upon to
send a non-zero pointer. This logs an error and doesn't segfault.
Reviewed-by: Patrick Venture
Signed-off-by: Titus Rwantare
---
hw/i2c/pmbus_device.c | 7 +++
1 file changed, 7 inse
On Wed, Mar 29, 2023 at 04:04:43PM +0200, Andreas Schwab wrote:
> On Mär 29 2023, Daniel P. Berrangé wrote:
>
> > On Wed, Mar 29, 2023 at 03:55:13PM +0200, Andreas Schwab wrote:
> >> Do not reverse the order of environment variables in the target environ
> >> array relative to the incoming environ
On Mär 29 2023, Daniel P. Berrangé wrote:
> On Wed, Mar 29, 2023 at 03:55:13PM +0200, Andreas Schwab wrote:
>> Do not reverse the order of environment variables in the target environ
>> array relative to the incoming environ order. Some testsuites depend on a
>> specific order, even though it is
Add MEN z125 UART over MEN Chameleon Bus emulation.
Signed-off-by: Johannes Thumshirn
---
hw/char/Kconfig | 6 +++
hw/char/meson.build | 1 +
hw/char/serial-mcb.c | 115 +++
3 files changed, 122 insertions(+)
create mode 100644 hw/char/serial-mc
Add PCI based MEN Chameleon Bus carrier emulation.
Signed-off-by: Johannes Thumshirn
---
hw/mcb/Kconfig | 6 +
hw/mcb/mcb-pci.c | 307 +
hw/mcb/meson.build | 1 +
3 files changed, 314 insertions(+)
create mode 100644 hw/mcb/mcb-pci.c
diff -
If the Xen PV guest VM sends a close whilst there is outstanding I/O
being processed that IO needs to be completed and drained before
unrealizing the rings or SEGVs will occurr when the I/O does complete
and tries to update an already unmapped grant entry.
On 29/3/23 16:00, Daniel P. Berrangé wrote:
On Wed, Mar 29, 2023 at 03:55:13PM +0200, Andreas Schwab wrote:
Do not reverse the order of environment variables in the target environ
array relative to the incoming environ order. Some testsuites depend on a
specific order, even though it is not def
1 - 100 of 150 matches
Mail list logo
