Re: [PATCH] riscv: Add semihosting support [v5]
Peter Maydell writes:
> I don't think a semihosting specification for RISC-V needs
> necessarily to be a very heavyweight thing -- it is, after
> all, a debug API at heart -- but I do agree that you should
> have one.
We've had a couple of weeks of discussion in the RISC-V sw-dev group and
have created a new specification for RISC-V semihosting. It is located
within the RISC-V consortium github account here:
https://github.com/riscv/riscv-semihosting-spec
The current version is 0.2, and this patch to QEMU implements that
version.
From 404ff408fa00ab7f65d1842966854824c418020c Mon Sep 17 00:00:00 2001
From: Keith Packard
Date: Mon, 21 Oct 2019 01:12:13 -0700
Subject: [PATCH] riscv: Add semihosting support [v5]
Adapt the arm semihosting support code for RISCV. This implementation
is based on the standard for RISC-V semihosting version 0.2 as
documented in
https://github.com/riscv/riscv-semihosting-spec/releases/tag/0.2
Signed-off-by: Keith Packard
---
v2:
Update PC after exception is handled to follow
change in the ARM version for SYS_READC
v3:
Disallow semihosting in user mode; report a regular
breakpoint in that case.
v4:
Fix errors reported by checkpatch
v5:
Reference current RISC-V semihosting specification
---
default-configs/riscv32-softmmu.mak |1 +
linux-user/qemu.h |2 +
qemu-options.hx | 10 +-
target/riscv/Makefile.objs|2 +-
target/riscv/cpu.h|2 +
target/riscv/cpu_bits.h |1 +
target/riscv/cpu_helper.c |9 +
.../riscv/insn_trans/trans_privileged.inc.c | 24 +-
target/riscv/riscv-semi.c | 1084 +
target/riscv/translate.c | 11 +
10 files changed, 1140 insertions(+), 6 deletions(-)
create mode 100644 target/riscv/riscv-semi.c
diff --git a/default-configs/riscv32-softmmu.mak b/default-configs/riscv32-softmmu.mak
index 1ae077ed87..21b7bedf19 100644
--- a/default-configs/riscv32-softmmu.mak
+++ b/default-configs/riscv32-softmmu.mak
@@ -3,6 +3,7 @@
# Uncomment the following lines to disable these optional devices:
#
#CONFIG_PCI_DEVICES=n
+CONFIG_SEMIHOSTING=y
# Boards:
#
diff --git a/linux-user/qemu.h b/linux-user/qemu.h
index 792c74290f..fb59776a34 100644
--- a/linux-user/qemu.h
+++ b/linux-user/qemu.h
@@ -105,6 +105,8 @@ typedef struct TaskState {
/* FPA state */
FPA11 fpa;
# endif
+#endif
+#if defined(TARGET_ARM) || defined(TARGET_RISCV)
int swi_errno;
#endif
#if defined(TARGET_I386) && !defined(TARGET_X86_64)
diff --git a/qemu-options.hx b/qemu-options.hx
index 16debd03cb..917b32ef32 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -4103,10 +4103,10 @@ ERST
DEF("semihosting", 0, QEMU_OPTION_semihosting,
"-semihostingsemihosting mode\n",
QEMU_ARCH_ARM | QEMU_ARCH_M68K | QEMU_ARCH_XTENSA | QEMU_ARCH_LM32 |
-QEMU_ARCH_MIPS | QEMU_ARCH_NIOS2)
+QEMU_ARCH_MIPS | QEMU_ARCH_NIOS2 | QEMU_ARCH_RISCV)
SRST
``-semihosting``
-Enable semihosting mode (ARM, M68K, Xtensa, MIPS, Nios II only).
+Enable semihosting mode (ARM, M68K, Xtensa, MIPS, Nios II only, RISC-V).
Note that this allows guest direct access to the host filesystem, so
should only be used with a trusted guest OS.
@@ -4118,10 +4118,10 @@ DEF("semihosting-config", HAS_ARG, QEMU_OPTION_semihosting_config,
"-semihosting-config [enable=on|off][,target=native|gdb|auto][,chardev=id][,arg=str[,...]]\n" \
"semihosting configuration\n",
QEMU_ARCH_ARM | QEMU_ARCH_M68K | QEMU_ARCH_XTENSA | QEMU_ARCH_LM32 |
-QEMU_ARCH_MIPS | QEMU_ARCH_NIOS2)
+QEMU_ARCH_MIPS | QEMU_ARCH_NIOS2 | QEMU_ARCH_RISCV)
SRST
``-semihosting-config [enable=on|off][,target=native|gdb|auto][,chardev=id][,arg=str[,...]]``
-Enable and configure semihosting (ARM, M68K, Xtensa, MIPS, Nios II
+Enable and configure semihosting (ARM, M68K, Xtensa, MIPS, Nios II, RISC-V
only).
Note that this allows guest direct access to the host filesystem, so
@@ -4136,6 +4136,8 @@ SRST
open/read/write/seek/select. Tensilica baremetal libc for ISS and
linux platform "sim" use this interface.
+On RISC-V this implements the standard semihosting API, version 0.2.
+
``target=native|gdb|auto``
Defines where the semihosting calls will be addressed, to QEMU
(``native``) or to GDB (``gdb``). The default is ``auto``, which
diff --git a/target/riscv/Makefile.objs b/target/riscv/Makefile.objs
index ff651f69f6..6fd7f40e29 100644
--- a/target/riscv/Makefile.objs
+++ b/target/riscv/Makefile.objs
@@ -1,4 +1,4 @@
-obj-y += translate.o op_helper.o cpu_helper.o cpu.o csr.o fpu_helper.o gdbstub.o
+obj-y += translate.o op_helper.o cpu_helper.o cpu.o csr.o fpu_helper.o gdbstub.o riscv-semi.o
obj-$(CONFIG_SOFTMMU) += pmp.o
ifeq ($(CONFIG_SOFTMMU),y)
diff --git a/target/riscv/cpu.h
Re: [PATCH] hax: Dynamic allocate vcpu state structure
Patchew URL: https://patchew.org/QEMU/20200406035016.609-1-bowen.w...@intel.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PATCH] hax: Dynamic allocate vcpu state structure
Message-id: 20200406035016.609-1-bowen.w...@intel.com
Type: series
=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===
Switched to a new branch 'test'
0f29908 hax: Dynamic allocate vcpu state structure
=== OUTPUT BEGIN ===
ERROR: space required before the open brace '{'
#45: FILE: target/i386/hax-all.c:262:
+if (max_cpus > HAX_MAX_VCPU){
ERROR: line over 90 characters
#46: FILE: target/i386/hax-all.c:263:
+fprintf(stderr, "Failed to create vm, maximum possible VCPU number
supported by QEMU is %d\n", HAX_MAX_VCPU);
ERROR: space required before the open brace '{'
#52: FILE: target/i386/hax-all.c:269:
+for(i = 0; i < vm->numvcpus; i++){
ERROR: space required before the open parenthesis '('
#52: FILE: target/i386/hax-all.c:269:
+for(i = 0; i < vm->numvcpus; i++){
ERROR: spaces required around that '=' (ctx:VxV)
#53: FILE: target/i386/hax-all.c:270:
+vm->vcpus[i]=NULL;
^
total: 5 errors, 0 warnings, 85 lines checked
Commit 0f299088bd75 (hax: Dynamic allocate vcpu state structure) has style
problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===
Test command exited with code: 1
The full log is available at
http://patchew.org/logs/20200406035016.609-1-bowen.w...@intel.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com
[PATCH] hax: Dynamic allocate vcpu state structure
Dynamic allocating vcpu state structure according to smp value to be
more precise and safe. Previously it will allocate array of fixed size
HAX_MAX_VCPU.
This is achieved by using g_new0 to dynamic allocate the array. The
allocated size is obtained from smp.max_cpus in MachineState. Also, the
size is compared with HAX_MAX_VCPU when creating the vm. The reason for
chosing dynamic array over linked list is because the status is visited
by index all the time.
This will lead to QEMU checking whether the smp value is larger than the
HAX_MAX_VCPU when creating vm, if larger, the process will terminate,
otherwise it will allocate array of size smp to store the status.
Signed-off-by: WangBowen
---
target/i386/hax-all.c | 25 +++--
target/i386/hax-i386.h | 5 +++--
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/target/i386/hax-all.c b/target/i386/hax-all.c
index a8b6e5aeb8..7ccd53a901 100644
--- a/target/i386/hax-all.c
+++ b/target/i386/hax-all.c
@@ -232,10 +232,10 @@ int hax_init_vcpu(CPUState *cpu)
return ret;
}
-struct hax_vm *hax_vm_create(struct hax_state *hax)
+struct hax_vm *hax_vm_create(struct hax_state *hax, int max_cpus)
{
struct hax_vm *vm;
-int vm_id = 0, ret;
+int vm_id = 0, ret, i;
if (hax_invalid_fd(hax->fd)) {
return NULL;
@@ -259,6 +259,17 @@ struct hax_vm *hax_vm_create(struct hax_state *hax)
goto error;
}
+if (max_cpus > HAX_MAX_VCPU){
+fprintf(stderr, "Failed to create vm, maximum possible VCPU number
supported by QEMU is %d\n", HAX_MAX_VCPU);
+goto error;
+}
+
+vm->numvcpus = max_cpus;
+vm->vcpus = g_new0(struct hax_vcpu_state *, vm->numvcpus);
+for(i = 0; i < vm->numvcpus; i++){
+vm->vcpus[i]=NULL;
+}
+
hax->vm = vm;
return vm;
@@ -272,12 +283,14 @@ int hax_vm_destroy(struct hax_vm *vm)
{
int i;
-for (i = 0; i < HAX_MAX_VCPU; i++)
+for (i = 0; i < vm->numvcpus; i++)
if (vm->vcpus[i]) {
fprintf(stderr, "VCPU should be cleaned before vm clean\n");
return -1;
}
hax_close_fd(vm->fd);
+vm->numvcpus = 0;
+g_free(vm->vcpus);
g_free(vm);
hax_global.vm = NULL;
return 0;
@@ -292,7 +305,7 @@ static void hax_handle_interrupt(CPUState *cpu, int mask)
}
}
-static int hax_init(ram_addr_t ram_size)
+static int hax_init(ram_addr_t ram_size, int max_cpus)
{
struct hax_state *hax = NULL;
struct hax_qemu_version qversion;
@@ -324,7 +337,7 @@ static int hax_init(ram_addr_t ram_size)
goto error;
}
-hax->vm = hax_vm_create(hax);
+hax->vm = hax_vm_create(hax, max_cpus);
if (!hax->vm) {
fprintf(stderr, "Failed to create HAX VM\n");
ret = -EINVAL;
@@ -352,7 +365,7 @@ static int hax_init(ram_addr_t ram_size)
static int hax_accel_init(MachineState *ms)
{
-int ret = hax_init(ms->ram_size);
+int ret = hax_init(ms->ram_size, (int)ms->smp.max_cpus);
if (ret && (ret != -ENOSPC)) {
fprintf(stderr, "No accelerator found.\n");
diff --git a/target/i386/hax-i386.h b/target/i386/hax-i386.h
index 54e9d8b057..7d988f81da 100644
--- a/target/i386/hax-i386.h
+++ b/target/i386/hax-i386.h
@@ -47,7 +47,8 @@ struct hax_state {
struct hax_vm {
hax_fd fd;
int id;
-struct hax_vcpu_state *vcpus[HAX_MAX_VCPU];
+int numvcpus;
+struct hax_vcpu_state **vcpus;
};
#ifdef NEED_CPU_H
@@ -58,7 +59,7 @@ int valid_hax_tunnel_size(uint16_t size);
/* Host specific functions */
int hax_mod_version(struct hax_state *hax, struct hax_module_version *version);
int hax_inject_interrupt(CPUArchState *env, int vector);
-struct hax_vm *hax_vm_create(struct hax_state *hax);
+struct hax_vm *hax_vm_create(struct hax_state *hax, int max_cpus);
int hax_vcpu_run(struct hax_vcpu_state *vcpu);
int hax_vcpu_create(int id);
int hax_sync_vcpu_state(CPUArchState *env, struct vcpu_state_t *state,
--
2.24.1
Requesting review about a bugfix in touch_all_pages
From faf903f7b8892179e64bd1a37fe3585a6441bc51 Mon Sep 17 00:00:00 2001
From: Bauerchen
Date: Mon, 6 Apr 2020 10:36:54 +0800
Subject: [PATCH] Fix: In touch_all_pages, maybe we need a lock to protect
qemu_cond_boardcast, or qemu_cond_boardcast may be called before all touch
page threads enter qemu_cond_wait. In this case, main thread waits touch
page threads return, touch page threads wait main thread waking up, that is a
dead lock ,vm will be in pause state forever;
Signed-off-by: Bauerchen
---
util/oslib-posix.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/util/oslib-posix.c b/util/oslib-posix.c
index 4dd6d7d..062236a 100644
--- a/util/oslib-posix.c
+++ b/util/oslib-posix.c
@@ -492,8 +492,11 @@ static bool touch_all_pages(char *area, size_t hpagesize,
size_t numpages,
QEMU_THREAD_JOINABLE);
addr += memset_thread[i].numpages * hpagesize;
}
+
+ qemu_mutex_lock(_mutex);
threads_created_flag = true;
qemu_cond_broadcast(_cond);
+ qemu_mutex_unlock(_mutex);
for (i = 0; i < memset_num_threads; i++) {
qemu_thread_join(_thread[i].pgthread);
--
1.8.3.1
Re: [PATCH] ppc/pnv: Create BMC devices only when defaults are enabled
On Sat, Apr 04, 2020 at 05:36:55PM +0200, Cédric Le Goater wrote:
> Commit e2392d4395dd ("ppc/pnv: Create BMC devices at machine init")
> introduced default BMC devices which can be a problem when the same
> devices are defined on the command line with :
>
> -device ipmi-bmc-sim,id=bmc0 -device isa-ipmi-bt,bmc=bmc0,irq=10
>
> QEMU fails with :
>
> qemu-system-ppc64: error creating device tree: node: FDT_ERR_EXISTS
>
> Use defaults_enabled() when creating the default BMC devices to let
> the user provide its own BMC devices using '-nodefaults'. If no BMC
> device are provided, output a warning but let QEMU run as this is a
> supported configuration. However, when multiple BMC devices are
> defined, stop QEMU with a clear error as the results are unexpected.
>
> Fixes: e2392d4395dd ("ppc/pnv: Create BMC devices at machine init")
> Reported-by: Nathan Chancellor
> Signed-off-by: Cédric Le Goater
As a regression fix, applied to ppc-for-5.0.
> ---
> include/hw/ppc/pnv.h | 2 ++
> hw/ppc/pnv.c | 32 ++-
> hw/ppc/pnv_bmc.c | 45
> 3 files changed, 74 insertions(+), 5 deletions(-)
>
> diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
> index fb4d0c0234b3..d4b0b0e2ff71 100644
> --- a/include/hw/ppc/pnv.h
> +++ b/include/hw/ppc/pnv.h
> @@ -241,6 +241,8 @@ struct PnvMachineState {
> void pnv_dt_bmc_sensors(IPMIBmc *bmc, void *fdt);
> void pnv_bmc_powerdown(IPMIBmc *bmc);
> IPMIBmc *pnv_bmc_create(PnvPnor *pnor);
> +IPMIBmc *pnv_bmc_find(Error **errp);
> +void pnv_bmc_set_pnor(IPMIBmc *bmc, PnvPnor *pnor);
>
> /*
> * POWER8 MMIO base addresses
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index ac83b8698b8e..a3b7a8d0ff32 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -573,10 +573,29 @@ static void pnv_powerdown_notify(Notifier *n, void
> *opaque)
>
> static void pnv_reset(MachineState *machine)
> {
> +PnvMachineState *pnv = PNV_MACHINE(machine);
> +IPMIBmc *bmc;
> void *fdt;
>
> qemu_devices_reset();
>
> +/*
> + * The machine should provide by default an internal BMC simulator.
> + * If not, try to use the BMC device that was provided on the command
> + * line.
> + */
> +bmc = pnv_bmc_find(_fatal);
> +if (!pnv->bmc) {
> +if (!bmc) {
> +warn_report("machine has no BMC device. Use '-device "
> +"ipmi-bmc-sim,id=bmc0 -device
> isa-ipmi-bt,bmc=bmc0,irq=10' "
> +"to define one");
> +} else {
> +pnv_bmc_set_pnor(bmc, pnv->pnor);
> +pnv->bmc = bmc;
> +}
> +}
> +
> fdt = pnv_dt_create(machine);
>
> /* Pack resulting tree */
> @@ -835,9 +854,6 @@ static void pnv_init(MachineState *machine)
> }
> g_free(chip_typename);
>
> -/* Create the machine BMC simulator */
> -pnv->bmc = pnv_bmc_create(pnv->pnor);
> -
> /* Instantiate ISA bus on chip 0 */
> pnv->isa_bus = pnv_isa_create(pnv->chips[0], _fatal);
>
> @@ -847,8 +863,14 @@ static void pnv_init(MachineState *machine)
> /* Create an RTC ISA device too */
> mc146818_rtc_init(pnv->isa_bus, 2000, NULL);
>
> -/* Create the IPMI BT device for communication with the BMC */
> -pnv_ipmi_bt_init(pnv->isa_bus, pnv->bmc, 10);
> +/*
> + * Create the machine BMC simulator and the IPMI BT device for
> + * communication with the BMC
> + */
> +if (defaults_enabled()) {
> +pnv->bmc = pnv_bmc_create(pnv->pnor);
> +pnv_ipmi_bt_init(pnv->isa_bus, pnv->bmc, 10);
> +}
>
> /*
> * OpenPOWER systems use a IPMI SEL Event message to notify the
> diff --git a/hw/ppc/pnv_bmc.c b/hw/ppc/pnv_bmc.c
> index 8863354c1c08..4e018b8b70e4 100644
> --- a/hw/ppc/pnv_bmc.c
> +++ b/hw/ppc/pnv_bmc.c
> @@ -213,6 +213,18 @@ static const IPMINetfn hiomap_netfn = {
> .cmd_handlers = hiomap_cmds
> };
>
> +
> +void pnv_bmc_set_pnor(IPMIBmc *bmc, PnvPnor *pnor)
> +{
> +object_ref(OBJECT(pnor));
> +object_property_add_const_link(OBJECT(bmc), "pnor", OBJECT(pnor),
> + _abort);
> +
> +/* Install the HIOMAP protocol handlers to access the PNOR */
> +ipmi_sim_register_netfn(IPMI_BMC_SIMULATOR(bmc), IPMI_NETFN_OEM,
> +_netfn);
> +}
> +
> /*
> * Instantiate the machine BMC. PowerNV uses the QEMU internal
> * simulator but it could also be external.
> @@ -232,3 +244,36 @@ IPMIBmc *pnv_bmc_create(PnvPnor *pnor)
>
> return IPMI_BMC(obj);
> }
> +
> +typedef struct ForeachArgs {
> +const char *name;
> +Object *obj;
> +} ForeachArgs;
> +
> +static int bmc_find(Object *child, void *opaque)
> +{
> +ForeachArgs *args = opaque;
> +
> +if (object_dynamic_cast(child, args->name)) {
> +if (args->obj) {
> +return 1;
> +}
> +args->obj = child;
> +}
> +return 0;
> +}
> +
> +IPMIBmc
[Bug 1821595] Re: Failed to emulate MMIO access with EmulatorReturnStatus: 2
FYI, I was curious if this was a Ryzen issue or not (which I am running), so I tried another machine - here are the two combos I tried, 1) Ryzen 5 2600X, Windows 19041.172 2) Core i5-6600K, Windows 18363.720 Same issue on both. Thanks! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1821595 Title: Failed to emulate MMIO access with EmulatorReturnStatus: 2 Status in QEMU: New Bug description: I have compiled qemu with enable-whpx parameter for Hyper-V Platform API in Mingw64 . When I tried run with Windows 7 iso file I have faced issue with the following problem: qemu-system-x86_64.exe: WHPX: Failed to emulate MMIO access with EmulatorReturnStatus: 2 qemu-system-x86_64.exe: WHPX: Failed to exec a virtual processor configuration directives: ../configure --target-list=x86_64-softmmu,i386-softmmu --enable-lzo\ --enable-bzip2 --enable-tools --enable-sdl --enable-gtk --enable-hax\ --enable-vdi --enable-qcow1 --enable-whpx --disable-capstone\ --disable-werror --disable-stack-protector --prefix="../../QEMU-bin" Qemu command line: qemu-system-x86_64.exe -m 1024 -cdrom "C:\Users\vmcs\Documents\en_windows_7_home_premium_with_sp1_x86_dvd_u_676701.iso" -display sdl -machine q35 -accel whpx To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1821595/+subscriptions
[Bug 1821595] Re: Failed to emulate MMIO access with EmulatorReturnStatus: 2
Hi, Having a similar issue here, running "QEMU emulator version 4.2.91 (v5.0.0-rc1-31-g146aa0f104-dirty)" Configuration / build command line, ./configure --cross-prefix=x86_64-w64-mingw32- --target-list=x86_64-softmmu --enable-whpx --enable-fdt --enable-gtk --enable-vnc --disable-pie --enable-opengl && make -j16 && make -j16 installer And the QEMU command line, qemu-system-x86_64.exe \ -m 2G \ -machine q35 \ -cpu Penryn \ -accel whpx \ -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \ -smbios type=2 \ -drive if=pflash,format=raw,readonly,file="./firmware/OVMF_CODE.fd"\ -drive if=pflash,format=raw,file="./firmware/OVMF_VARS-1024x768.fd" \ -usb -device usb-kbd -device usb-mouse \ -netdev user,id=net0 \ -device e1000-82545em,netdev=net0,id=net0,mac=52:54:00:c9:18:27 \ -device ich9-ahci,id=sata \ -drive id=ESP,if=none,format=qcow2,file=ESP.qcow2 \ -device ide-hd,bus=sata.2,drive=ESP \ -drive id=InstallMedia,format=raw,if=none,file=BaseSystem.img \ -device ide-hd,bus=sata.3,drive=InstallMedia \ -drive id=SystemDisk,if=none,file=MyDisk.qcow2 \ -device ide-hd,bus=sata.4,drive=SystemDisk \ If I remove (only), -accel whpx \ => Then it all runs, just very slowly ;-). Any suggestions, things to try? Thanks! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1821595 Title: Failed to emulate MMIO access with EmulatorReturnStatus: 2 Status in QEMU: New Bug description: I have compiled qemu with enable-whpx parameter for Hyper-V Platform API in Mingw64 . When I tried run with Windows 7 iso file I have faced issue with the following problem: qemu-system-x86_64.exe: WHPX: Failed to emulate MMIO access with EmulatorReturnStatus: 2 qemu-system-x86_64.exe: WHPX: Failed to exec a virtual processor configuration directives: ../configure --target-list=x86_64-softmmu,i386-softmmu --enable-lzo\ --enable-bzip2 --enable-tools --enable-sdl --enable-gtk --enable-hax\ --enable-vdi --enable-qcow1 --enable-whpx --disable-capstone\ --disable-werror --disable-stack-protector --prefix="../../QEMU-bin" Qemu command line: qemu-system-x86_64.exe -m 1024 -cdrom "C:\Users\vmcs\Documents\en_windows_7_home_premium_with_sp1_x86_dvd_u_676701.iso" -display sdl -machine q35 -accel whpx To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1821595/+subscriptions
[Bug 1871005] [NEW] build fails on CLOCK_MONOTONIC
Public bug reported: Moc OS X.11.6 El Capitan build fails on this /Users/alba/Downloads/qemu-5.0.0-rc1/include/qemu/timer.h:843:9: warning: implicit declaration of function 'clock_gettime' is invalid in C99 [-Wimplicit-function-declaration] clock_gettime(CLOCK_MONOTONIC, ); ^ /Users/alba/Downloads/qemu-5.0.0-rc1/include/qemu/timer.h:843:23: error: use of undeclared identifier 'CLOCK_MONOTONIC' clock_gettime(CLOCK_MONOTONIC, ); ^ 1 warning and 1 error generated. make: *** [trace/control.o] Error 1 ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1871005 Title: build fails on CLOCK_MONOTONIC Status in QEMU: New Bug description: Moc OS X.11.6 El Capitan build fails on this /Users/alba/Downloads/qemu-5.0.0-rc1/include/qemu/timer.h:843:9: warning: implicit declaration of function 'clock_gettime' is invalid in C99 [-Wimplicit-function-declaration] clock_gettime(CLOCK_MONOTONIC, ); ^ /Users/alba/Downloads/qemu-5.0.0-rc1/include/qemu/timer.h:843:23: error: use of undeclared identifier 'CLOCK_MONOTONIC' clock_gettime(CLOCK_MONOTONIC, ); ^ 1 warning and 1 error generated. make: *** [trace/control.o] Error 1 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1871005/+subscriptions
Re: [PATCH v4 2/2] net/colo-compare.c: handling of the full primary or secondary queue
On Sat, 28 Mar 2020 20:46:46 +0800
Derek Su wrote:
> The pervious handling of the full primary or queue is only dropping
> the packet. If there are lots of clients to the guest VM,
> the "drop" will lead to the lost of the networking connection
> until next checkpoint.
>
> To address the issue, this patch drops the packet firstly.
> Then, do checkpoint and flush packets.
>
> Signed-off-by: Derek Su
Looks good and works well in my tests.
Reviewed-by: Lukas Straub
Tested-by: Lukas Straub
Regards,
Lukas Straub
> ---
> net/colo-compare.c | 39 ---
> 1 file changed, 28 insertions(+), 11 deletions(-)
>
> diff --git a/net/colo-compare.c b/net/colo-compare.c
> index cdd87b2aa8..fe8779cf2d 100644
> --- a/net/colo-compare.c
> +++ b/net/colo-compare.c
> @@ -125,6 +125,12 @@ static const char *colo_mode[] = {
> [SECONDARY_IN] = "secondary",
> };
>
> +enum {
> +QUEUE_INSERT_ERR = -1,
> +QUEUE_INSERT_OK = 0,
> +QUEUE_INSERT_FULL = 1,
> +};
> +
> static int compare_chr_send(CompareState *s,
> const uint8_t *buf,
> uint32_t size,
> @@ -211,8 +217,10 @@ static int colo_insert_packet(GQueue *queue, Packet
> *pkt, uint32_t *max_ack)
> }
>
> /*
> - * Return 0 on success, if return -1 means the pkt
> - * is unsupported(arp and ipv6) and will be sent later
> + * Return QUEUE_INSERT_OK on success.
> + * If return QUEUE_INSERT_FULL means list is full, and
> + * QUEUE_INSERT_ERR means the pkt is unsupported(arp and ipv6) and
> + * will be sent later
> */
> static int packet_enqueue(CompareState *s, int mode, Connection **con)
> {
> @@ -234,7 +242,7 @@ static int packet_enqueue(CompareState *s, int mode,
> Connection **con)
> if (parse_packet_early(pkt)) {
> packet_destroy(pkt, NULL);
> pkt = NULL;
> -return -1;
> +return QUEUE_INSERT_ERR;
> }
> fill_connection_key(pkt, );
>
> @@ -258,11 +266,12 @@ static int packet_enqueue(CompareState *s, int mode,
> Connection **con)
> "drop packet", colo_mode[mode]);
> packet_destroy(pkt, NULL);
> pkt = NULL;
> +return QUEUE_INSERT_FULL;
> }
>
> *con = conn;
>
> -return 0;
> +return QUEUE_INSERT_OK;
> }
>
> static inline bool after(uint32_t seq1, uint32_t seq2)
> @@ -995,17 +1004,21 @@ static void compare_pri_rs_finalize(SocketReadState
> *pri_rs)
> {
> CompareState *s = container_of(pri_rs, CompareState, pri_rs);
> Connection *conn = NULL;
> +int ret;
>
> -if (packet_enqueue(s, PRIMARY_IN, )) {
> +ret = packet_enqueue(s, PRIMARY_IN, );
> +if (ret == QUEUE_INSERT_OK) {
> +/* compare packet in the specified connection */
> +colo_compare_connection(conn, s);
> +} else if (ret == QUEUE_INSERT_FULL) {
> +colo_compare_inconsistency_notify(s);
> +} else {
> trace_colo_compare_main("primary: unsupported packet in");
> compare_chr_send(s,
> pri_rs->buf,
> pri_rs->packet_len,
> pri_rs->vnet_hdr_len,
> false);
> -} else {
> -/* compare packet in the specified connection */
> -colo_compare_connection(conn, s);
> }
> }
>
> @@ -1013,12 +1026,16 @@ static void compare_sec_rs_finalize(SocketReadState
> *sec_rs)
> {
> CompareState *s = container_of(sec_rs, CompareState, sec_rs);
> Connection *conn = NULL;
> +int ret;
>
> -if (packet_enqueue(s, SECONDARY_IN, )) {
> -trace_colo_compare_main("secondary: unsupported packet in");
> -} else {
> +ret = packet_enqueue(s, SECONDARY_IN, );
> +if (ret == QUEUE_INSERT_OK) {
> /* compare packet in the specified connection */
> colo_compare_connection(conn, s);
> +} else if (ret == QUEUE_INSERT_FULL) {
> +colo_compare_inconsistency_notify(s);
> +} else {
> +trace_colo_compare_main("secondary: unsupported packet in");
> }
> }
>
pgp7uyYoK4C26.pgp
Description: OpenPGP digital signature
Re: [PATCH v4 1/2] net/colo-compare.c: Fix memory leak in packet_enqueue()
On Sat, 28 Mar 2020 20:46:45 +0800
Derek Su wrote:
> The patch is to fix the "pkt" memory leak in packet_enqueue().
> The allocated "pkt" needs to be freed if the colo compare
> primary or secondary queue is too big.
>
> Signed-off-by: Derek Su
Looks good and works well in my tests.
Reviewed-by: Lukas Straub
Tested-by: Lukas Straub
Regards,
Lukas Straub
> ---
> net/colo-compare.c | 23 +++
> 1 file changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/net/colo-compare.c b/net/colo-compare.c
> index 7ee17f2cf8..cdd87b2aa8 100644
> --- a/net/colo-compare.c
> +++ b/net/colo-compare.c
> @@ -120,6 +120,10 @@ enum {
> SECONDARY_IN,
> };
>
> +static const char *colo_mode[] = {
> +[PRIMARY_IN] = "primary",
> +[SECONDARY_IN] = "secondary",
> +};
>
> static int compare_chr_send(CompareState *s,
> const uint8_t *buf,
> @@ -215,6 +219,7 @@ static int packet_enqueue(CompareState *s, int mode,
> Connection **con)
> ConnectionKey key;
> Packet *pkt = NULL;
> Connection *conn;
> +int ret;
>
> if (mode == PRIMARY_IN) {
> pkt = packet_new(s->pri_rs.buf,
> @@ -243,16 +248,18 @@ static int packet_enqueue(CompareState *s, int mode,
> Connection **con)
> }
>
> if (mode == PRIMARY_IN) {
> -if (!colo_insert_packet(>primary_list, pkt, >pack)) {
> -error_report("colo compare primary queue size too big,"
> - "drop packet");
> -}
> +ret = colo_insert_packet(>primary_list, pkt, >pack);
> } else {
> -if (!colo_insert_packet(>secondary_list, pkt, >sack)) {
> -error_report("colo compare secondary queue size too big,"
> - "drop packet");
> -}
> +ret = colo_insert_packet(>secondary_list, pkt, >sack);
> }
> +
> +if (!ret) {
> +error_report("colo compare %s queue size too big,"
> + "drop packet", colo_mode[mode]);
> +packet_destroy(pkt, NULL);
> +pkt = NULL;
> +}
> +
> *con = conn;
>
> return 0;
pgpXMmwInBgDz.pgp
Description: OpenPGP digital signature
[Bug 1821444] Re: qemu-ppc (user) incorrectly translates float32 arithmetics
fix committed with c0e6616b6685ffdb4c5e091bc152e46e14703dd1 and released
with 4.2.0
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1821444
Title:
qemu-ppc (user) incorrectly translates float32 arithmetics
Status in QEMU:
Fix Released
Bug description:
I'm using qemu-3.1.0 (Gentoo).
When I was running regression test suite via qemu-ppc for GHC I
noticed a few uint32_t<->float32 failures I did not expect to
encounter.
Here is an example
$ cat a.c
#include
#include
int main() {
volatile uint32_t i = 1;
printf("0x1 = %e\n", *(volatile float*));
}
$ powerpc-unknown-linux-gnu-gcc -O2 a.c -Wall -o a -fno-strict-aliasing
-fno-stack-protector -static && ./a
0x1 = 2.802597e-45
$ scp a timberdoodle.ppc64.dev.gentoo.org:~/
a
100% 826KB 102.0KB/s 00:08
$ ssh timberdoodle.ppc64.dev.gentoo.org ./a
0x1 = 1.401298e-45
$ qemu-ppc ./a
0x1 = 2.802597e-45
Looks like off-by-one bit somewhere. I'm not sure if it's FPU
instruction or some internals of printf() that are emulated
incorrectly.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1821444/+subscriptions
[PATCH] Fixed IPv6 payload lenght without jumbo option
From: Andrew Melnychenko
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1708065
e1000e driver doesn't sets 'plen' field for IPv6 for big packets
if TSO is enabled. Jumbo option isn't added yet, until
qemu supports packets greater than 64K.
Signed-off-by: Andrew Melnychenko
---
hw/net/e1000e_core.c | 1 +
hw/net/net_tx_pkt.c | 31 +++
hw/net/net_tx_pkt.h | 7 +++
include/net/eth.h| 1 +
4 files changed, 40 insertions(+)
diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
index d5676871fa..a1ec55598b 100644
--- a/hw/net/e1000e_core.c
+++ b/hw/net/e1000e_core.c
@@ -656,6 +656,7 @@ e1000e_tx_pkt_send(E1000ECore *core, struct e1000e_tx *tx,
int queue_index)
NetClientState *queue = qemu_get_subqueue(core->owner_nic, target_queue);
e1000e_setup_tx_offloads(core, tx);
+net_tx_pkt_fix_ip6_payload_len(tx->tx_pkt);
net_tx_pkt_dump(tx->tx_pkt);
diff --git a/hw/net/net_tx_pkt.c b/hw/net/net_tx_pkt.c
index 162f802dd7..b05d554ac3 100644
--- a/hw/net/net_tx_pkt.c
+++ b/hw/net/net_tx_pkt.c
@@ -635,3 +635,34 @@ bool net_tx_pkt_send_loopback(struct NetTxPkt *pkt,
NetClientState *nc)
return res;
}
+
+void net_tx_pkt_fix_ip6_payload_len(struct NetTxPkt *pkt)
+{
+/*
+ * If ipv6 payload length field is 0 - then there should be Hop-by-Hop
+ * option for packets greater than 65,535.
+ * For packets with payload less than 65,535: fix 'plen' field.
+ * For now, qemu drops every packet with size greater 64K
+ * (see net_tx_pkt_send()) so, there is no reason to add jumbo option to
ip6
+ * hop-by-hop extension if it's missed
+ */
+
+struct iovec *l2 = >vec[NET_TX_PKT_L2HDR_FRAG];
+if (eth_get_l3_proto(l2, 1, l2->iov_len) == ETH_P_IPV6) {
+struct ip6_header *ip6 = (struct ip6_header *) pkt->l3_hdr;
+/*
+ * TODO: if qemu would support >64K packets - add jumbo option check
+ * something like that:
+ * 'if (ip6->ip6_plen == 0 && !has_jumbo_option(ip6)) {'
+ */
+if (ip6->ip6_plen == 0) {
+if (pkt->payload_len <= ETH_MAX_IP_DGRAM_LEN) {
+ip6->ip6_plen = htons(pkt->payload_len);
+}
+/*
+ * TODO: if qemu would support >64K packets
+ * add jumbo option for packets greater then 65,535 bytes
+ */
+}
+}
+}
diff --git a/hw/net/net_tx_pkt.h b/hw/net/net_tx_pkt.h
index 212ecc62fc..912d56ef13 100644
--- a/hw/net/net_tx_pkt.h
+++ b/hw/net/net_tx_pkt.h
@@ -187,4 +187,11 @@ bool net_tx_pkt_parse(struct NetTxPkt *pkt);
*/
bool net_tx_pkt_has_fragments(struct NetTxPkt *pkt);
+/**
+ * Fix IPv6 'plen' field.
+ *
+ * @pktpacket
+ */
+void net_tx_pkt_fix_ip6_payload_len(struct NetTxPkt *pkt);
+
#endif
diff --git a/include/net/eth.h b/include/net/eth.h
index 7f45c678e7..0671be6916 100644
--- a/include/net/eth.h
+++ b/include/net/eth.h
@@ -186,6 +186,7 @@ struct tcp_hdr {
#define ip6_nxt ip6_ctlun.ip6_un1.ip6_un1_nxt
#define ip6_ecn_acc ip6_ctlun.ip6_un3.ip6_un3_ecn
+#define ip6_plen ip6_ctlun.ip6_un1.ip6_un1_plen
#define PKT_GET_ETH_HDR(p)\
((struct eth_header *)(p))
--
2.24.1
Re: [PATCH v1 2/3] hvf: Make long mode enter and exit code clearer.
On Mon, Mar 30, 2020 at 05:16:05PM -0700, Cameron Esfahani wrote:
> Signed-off-by: Cameron Esfahani
> ---
> target/i386/hvf/vmx.h | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/target/i386/hvf/vmx.h b/target/i386/hvf/vmx.h
> index 8ec2e6414e..1a1b150c97 100644
> --- a/target/i386/hvf/vmx.h
> +++ b/target/i386/hvf/vmx.h
> @@ -121,6 +121,7 @@ static inline void macvm_set_cr0(hv_vcpuid_t vcpu,
> uint64_t cr0)
> uint64_t pdpte[4] = {0, 0, 0, 0};
> uint64_t efer = rvmcs(vcpu, VMCS_GUEST_IA32_EFER);
> uint64_t old_cr0 = rvmcs(vcpu, VMCS_GUEST_CR0);
> +uint64_t changed_cr0 = old_cr0 ^ cr0;
> uint64_t mask = CR0_PG_MASK | CR0_CD_MASK | CR0_NW_MASK |
> CR0_NE_MASK | CR0_ET_MASK;
>
> @@ -139,11 +140,12 @@ static inline void macvm_set_cr0(hv_vcpuid_t vcpu,
> uint64_t cr0)
> wvmcs(vcpu, VMCS_CR0_SHADOW, cr0);
>
> if (efer & MSR_EFER_LME) {
> -if (!(old_cr0 & CR0_PG_MASK) && (cr0 & CR0_PG_MASK)) {
> -enter_long_mode(vcpu, cr0, efer);
> -}
> -if (!(cr0 & CR0_PG_MASK)) {
> -exit_long_mode(vcpu, cr0, efer);
> +if (changed_cr0 & CR0_PG_MASK) {
> +if (cr0 & CR0_PG_MASK) {
> +enter_long_mode(vcpu, cr0, efer);
> +} else {
> +exit_long_mode(vcpu, cr0, efer);
> +}
> }
> }
>
> --
> 2.24.0
>
The changes look good but I have a few nitpicks.
The summary line should not have "." at the end, please see
(https://wiki.qemu.org/Contribute/SubmitAPatch#Write_a_meaningful_commit_message):
> Whether the "single line summary of change" starts with a capital is a
> matter of taste, but we prefer that the summary does not end in "."
Also, it would be good to mention in the title/commit message that with the
change QEMU is skipping unconditional writes to the guest IA32_EFER.LMA
and VMCS Entry Controls in compatibility mode, instead it does so only
when the actual switch out of long mode happens. (It's worth to mention
any other issues the patch helps to address, if any).
The comment in the previous patch may be dropped here IMO.
Besides that,
Reviewed-by: Roman Bolshakov
Thanks,
Roman
[PATCH] Fixed IPv6 payload lenght without jumbo option
From: Andrew Melnychenko
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1708065
e1000e driver doesn't sets 'plen' field for IPv6 for big packets
if TSO is enabled. Jumbo option isn't added yet, until
qemu supports packets greater than 64K.
Signed-off-by: Andrew Melnychenko
---
hw/net/e1000e_core.c | 1 +
hw/net/net_tx_pkt.c | 31 +++
hw/net/net_tx_pkt.h | 7 +++
include/net/eth.h| 1 +
4 files changed, 40 insertions(+)
diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
index d5676871fa..a1ec55598b 100644
--- a/hw/net/e1000e_core.c
+++ b/hw/net/e1000e_core.c
@@ -656,6 +656,7 @@ e1000e_tx_pkt_send(E1000ECore *core, struct e1000e_tx *tx,
int queue_index)
NetClientState *queue = qemu_get_subqueue(core->owner_nic, target_queue);
e1000e_setup_tx_offloads(core, tx);
+net_tx_pkt_fix_ip6_payload_len(tx->tx_pkt);
net_tx_pkt_dump(tx->tx_pkt);
diff --git a/hw/net/net_tx_pkt.c b/hw/net/net_tx_pkt.c
index 162f802dd7..b05d554ac3 100644
--- a/hw/net/net_tx_pkt.c
+++ b/hw/net/net_tx_pkt.c
@@ -635,3 +635,34 @@ bool net_tx_pkt_send_loopback(struct NetTxPkt *pkt,
NetClientState *nc)
return res;
}
+
+void net_tx_pkt_fix_ip6_payload_len(struct NetTxPkt *pkt)
+{
+/*
+ * If ipv6 payload length field is 0 - then there should be Hop-by-Hop
+ * option for packets greater than 65,535.
+ * For packets with payload less than 65,535: fix 'plen' field.
+ * For now, qemu drops every packet with size greater 64K
+ * (see net_tx_pkt_send()) so, there is no reason to add jumbo option to
ip6
+ * hop-by-hop extension if it's missed
+ */
+
+struct iovec *l2 = >vec[NET_TX_PKT_L2HDR_FRAG];
+if (eth_get_l3_proto(l2, 1, l2->iov_len) == ETH_P_IPV6) {
+struct ip6_header *ip6 = (struct ip6_header *) pkt->l3_hdr;
+/*
+ * TODO: if qemu would support >64K packets - add jumbo option check
+ * something like that:
+ * 'if (ip6->ip6_plen == 0 && !has_jumbo_option(ip6)) {'
+ */
+if (ip6->ip6_plen == 0) {
+if (pkt->payload_len <= ETH_MAX_IP_DGRAM_LEN) {
+ip6->ip6_plen = htons(pkt->payload_len);
+}
+/*
+ * TODO: if qemu would support >64K packets
+ * add jumbo option for packets greater then 65,535 bytes
+ */
+}
+}
+}
diff --git a/hw/net/net_tx_pkt.h b/hw/net/net_tx_pkt.h
index 212ecc62fc..912d56ef13 100644
--- a/hw/net/net_tx_pkt.h
+++ b/hw/net/net_tx_pkt.h
@@ -187,4 +187,11 @@ bool net_tx_pkt_parse(struct NetTxPkt *pkt);
*/
bool net_tx_pkt_has_fragments(struct NetTxPkt *pkt);
+/**
+ * Fix IPv6 'plen' field.
+ *
+ * @pktpacket
+ */
+void net_tx_pkt_fix_ip6_payload_len(struct NetTxPkt *pkt);
+
#endif
diff --git a/include/net/eth.h b/include/net/eth.h
index 7f45c678e7..0671be6916 100644
--- a/include/net/eth.h
+++ b/include/net/eth.h
@@ -186,6 +186,7 @@ struct tcp_hdr {
#define ip6_nxt ip6_ctlun.ip6_un1.ip6_un1_nxt
#define ip6_ecn_acc ip6_ctlun.ip6_un3.ip6_un3_ecn
+#define ip6_plen ip6_ctlun.ip6_un1.ip6_un1_plen
#define PKT_GET_ETH_HDR(p)\
((struct eth_header *)(p))
--
2.24.1
Re: [PATCH v1 1/3] hvf: use standard CR0 and CR4 register definitions
On Mon, Mar 30, 2020 at 05:16:04PM -0700, Cameron Esfahani wrote:
> Signed-off-by: Cameron Esfahani
> ---
> target/i386/cpu.h | 2 ++
> target/i386/hvf/hvf.c | 1 +
> target/i386/hvf/vmx.h | 15 ---
> target/i386/hvf/x86.c | 6 +++---
> target/i386/hvf/x86.h | 34 --
> target/i386/hvf/x86_mmu.c | 2 +-
> target/i386/hvf/x86_task.c | 3 ++-
> 7 files changed, 17 insertions(+), 46 deletions(-)
>
Hi Cameron,
I'm sorry for delay.
This is fun, I had very similar changeset I forgot to send quite a while
ago:
https://github.com/roolebo/qemu/commits/hvf-common-cr-constants
> diff --git a/target/i386/hvf/hvf.c b/target/i386/hvf/hvf.c
> index d72543dc31..fef1ee7d70 100644
> --- a/target/i386/hvf/hvf.c
> +++ b/target/i386/hvf/hvf.c
> @@ -455,6 +455,7 @@ void hvf_reset_vcpu(CPUState *cpu) {
> wvmcs(cpu->hvf_fd, VMCS_GUEST_PDPTE0 + i * 2, pdpte[i]);
> }
>
> +macvm_set_cr0(cpu->hvf_fd, CR0_CD_MASK | CR0_NW_MASK | CR0_ET_MASK);
> macvm_set_cr0(cpu->hvf_fd, 0x6010);
The second macvm_set_cr0() is a duplicate of the first one and should be
dropped.
>
> wvmcs(cpu->hvf_fd, VMCS_CR4_MASK, CR4_VMXE_MASK);
> diff --git a/target/i386/hvf/vmx.h b/target/i386/hvf/vmx.h
> index 03d2c79b9c..8ec2e6414e 100644
> --- a/target/i386/hvf/vmx.h
> +++ b/target/i386/hvf/vmx.h
> @@ -138,17 +139,17 @@ static inline void macvm_set_cr0(hv_vcpuid_t vcpu,
> uint64_t cr0)
> wvmcs(vcpu, VMCS_CR0_SHADOW, cr0);
>
> if (efer & MSR_EFER_LME) {
> -if (!(old_cr0 & CR0_PG) && (cr0 & CR0_PG)) {
> +if (!(old_cr0 & CR0_PG_MASK) && (cr0 & CR0_PG_MASK)) {
> enter_long_mode(vcpu, cr0, efer);
> }
> -if (/*(old_cr0 & CR0_PG) &&*/ !(cr0 & CR0_PG)) {
> +if (!(cr0 & CR0_PG_MASK)) {
IMO the patch should only change CR0_PG to CR0_PG_MASK without removal
of the commented condition.
In the next patch you're improving how long mode exit is done and
replacement of the comment with an implementation fits better there.
> exit_long_mode(vcpu, cr0, efer);
> }
> }
>
> /* Filter new CR0 after we are finished examining it above. */
> -cr0 = (cr0 & ~(mask & ~CR0_PG));
> -wvmcs(vcpu, VMCS_GUEST_CR0, cr0 | CR0_NE | CR0_ET);
> +cr0 = (cr0 & ~(mask & ~CR0_PG_MASK));
> +wvmcs(vcpu, VMCS_GUEST_CR0, cr0 | CR0_NE_MASK | CR0_ET_MASK);
>
> hv_vcpu_invalidate_tlb(vcpu);
> hv_vcpu_flush(vcpu);
> --
> 2.24.0
>
Best regards,
Roman
Re: [PATCH 0/3] target/mips: Add loongson gs464 core
13:37 Pet, 03.04.2020. Jiaxun Yang је написао/ла: > > > 在 星期五, 2020-04-03 18:00:31 Aleksandar Markovic < aleksandar.qemu.de...@gmail.com> 撰写 > > > > 00:02 Pet, 27.03.2020. Aleksandar Markovic < aleksandar.qemu.de...@gmail.com> је написао/ла: > > > > > > 12:05 Sre, 25.03.2020. Jiaxun Yang је написао/ла: > > > > > > > > Loongson gs464 core can be found in Loongson-3A1000 processor. > > > > This patchset add minimal support for that core. > > > > There are still some instructions missing, I'm going to work on > > > > them later. > > > > > > > > The corresponding hw board is also missing. I'm using modified kernel > > > > for malta for testing purpose and planing to take the design of Lemote's > > > > KVM virtual machine. > > > > > > > > Official manual of this core can be found here [1] (In Chinese). > > > > My collection of instruction documents mainly based on Chinese > > > > version of manual, binutils gas code and experiments on real machine > > > > can be found here [2] (In English). > > > > > > > > [1]: http://loongson.cn/uploadfile/cpu/3A1000/Loongson_3A1000_cpu_user_2.pdf > > > > [2]: https://github.com/FlyGoat/loongson-insn/blob/master/loongson-ext.md > > > > > > > > > > Thanks, Jiaxun! > > > > > > Just to mention whay you probably know, since this is a new feature, this is too late for 5.0, so we are shooting for integrsying it in 5.1. > > > > > > Speak to you later of course in more details. > > > > > Jiaxun, hello again. > > May I ask you to provide us the automatic english transl > > tion of document [1]? > > translate.google.com site has the festure of uploading and translating a pdf file. Unfortunately, one can't download resulting pdf file. But, there is a workaround: one can "print" the page to pdf format from the browser. > > There may be other ways of automatic translation of pdfs, but the one above seems pretty reasonable. > > Yours, > > Aleksandar > > Hi Aleksandar, > > Machine translated version attached. > > It's not very easy to read it as Google Translation don't know much about > computer sciences vocabulary in Chinese. > And the figures are all messed up. That is fine, Jiaxin, and, frankly, I did not expect anything better from automatic Google translation. Thanks again. See you later, on the list! Aleksandar > Also, there are some known errata in this manual, some default values of registers > appear to be different from the actual hardware. > > If you have any questions about GS464 please ask me and I'll forward them to > Loongson guys. They're not willing to appear on the list but at least they'll respond > my questions. > > Thanks! > -- > Jiaxun Yang > > > > > > > Yours, > > > Aleksandar > > > > > > > Jiaxun Yang (3): > > > > target/mips: Introduce loongson ext & mmi ASE flags > > > > target/mips: Add loongson ext lsdc2 instrustions > > > > target/mips: Add loongson gs464 core > > > > > > > > target/mips/mips-defs.h | 2 + > > > > target/mips/translate.c | 166 ++- > > > > target/mips/translate_init.inc.c | 25 - > > > > 3 files changed, 188 insertions(+), 5 deletions(-) > > > > > > > > -- > > > > 2.26.0.rc2 > > > > > > > > > > > >
Re: [PATCH v4 for-5.0] configure: warn if not using a separate build directory
11:14 Sub, 04.04.2020. Peter Maydell је написао/ла: > > On Fri, 3 Apr 2020 at 23:35, Aleksandar Markovic > wrote: > > But, Eric, while, to some extent I understand your motivation and the idea, there are still features working in in-tree builds only (some coccinele scenarios, and some gcov-related scenarios - and perhaps others that nobody seems to care to try to find out at all), and not in out-of tree builds. And, now, if I understand well your proposal, and supposing that I use gcov in-tree build (since I have to), this will stop me from doing out-of-tree builds in this QEMU directory, since my in-tree gcov build will be destroyed. > > To repeat from the last thread: we are *not going* to remove in-tree > builds before we fix whatever we need to to allow people to > use out-of-tree for whatever they are currently doing with in-tree > builds. I am with you, Peter, and I truly appreciate your repeating that for the second time. But, what made me upset, obviously not everybody is reading your statements. If you really carefully read responses to the original thread started by you and also subsequent threads, you'll see that a number of suggestions either cripple or outrightly effectively remove in-tree builds! And all that not in 4 months, not in 8 months, but now, in the same patch that was discussed (maybe the authors meant "later", but certainly did not write that). (on closer examination, perhaps Eric's proposal does not belong to this catehory, so my apologies to Eric) > The reason for putting in deprecation warnings etc now > is timescales: releases are every four months or so, so if we > want to warn users about something we need to put in that warning > well in advance. Bug fixes on the other hand can go into the tree > very quickly, so we can without any problems have a timeline that > goes deprecation-notice --- fix bugs with out-of-tree builds -- remove > or convert in-tree builds to automatically out-of-tree. > > Plus the only way we find out about problems we're going to need > to fix is if we tell people "in-tree is going away" and they then tell > us "er, XYZ doesn't seem to work out-of-tree". > Understood. > The reason people are currently focusing on the warning bit > is that we have about one week to do that if we want to get > it into this release. After that we have months to investigate > and fix the problems with out-of-tree builds. > > Can you provide repro instructions for your gcov issue? > I unfortunately can't, because I am working from home, and having difficulties accessing my dev system with said behavior, that I left at the company. If and when these difficulties disappear, I will gladly and certainly send a bug report. > What is the "coccinelle scenario" you mention? > I meant to say the scenario you mention in your original thread on the same topic from the other day, and perhaps you said "Coverity", and not "coccinele" - and I mixed up the two. So, in other words, nothing new, I was just echoing what you said before, the other day, in a response to one of my messages. Regards, Aleksandar > thanks > -- PMM
Re: [PATCH v4 for-5.0] configure: warn if not using a separate build directory
16:39 Ned, 05.04.2020. Peter Maydell је написао/ла: > > On Fri, 3 Apr 2020 at 14:53, Daniel P. Berrangé wrote: > > > > Running configure directly from the source directory is a build > > configuration that will go away in future. It is also not currently > > covered by any automated testing. Display a deprecation warning if > > the user attempts to use an in-srcdir build setup, so that they are > > aware that they're building QEMU in an undesirable manner. > > > > Reviewed-by: Eric Blake > > Reviewed-by: Markus Armbruster > > Reviewed-by: Philippe Mathieu-Daudé > > Tested-by: Philippe Mathieu-Daudé > > Signed-off-by: Daniel P. Berrangé > > --- > > > +if test "$in_srcdir" = "yes"; then > > +echo > > +echo "WARNING: SUPPORT FOR BUILDING IN THE SOURCE DIR IS DEPRECATED" > > +echo > > +echo "Support for running the 'configure' script directly from the" > > +echo "source directory is deprecated. In-tree builds are not covered" > > +echo "by automated testing and thus may not correctly build QEMU." > > +echo "Users are recommended to use a separate build directory:" > > +echo > > +echo " $ mkdir build" > > +echo " $ cd build" > > +echo " $ ../configure" > > +echo " $ make" > > +echo > > +fi > > So here's my stab at some text here; I'm aiming at nudging users > towards out-of-tree builds if they were simply not thinking about > it, but not actively marking them as 'deprecated', since it sounded > to me like we were planning to keep at least the basic > 'configure+make+make install' sequence of commands working. > > echo "NOTE: we recommend against building in the source directory" > echo > echo "You've run the 'configure' script directly from the source" > echo "directory. This will work, but we recommend using a separate" > echo "build directory, especially if you plan to work with the QEMU" > echo "sources rather than just building it once. You can switch to" > echo "a separate build directory like this:" > [instructions go here] > Peter's version is far more superior to Daniel's. I'd better not discuss the reasons, not wanting to waste my time and other's time. For Peter's version: Reviewed-by: Aleksandar Markovic > thanks > -- PMM >
[Bug 1870911] Re: QEMU Crashes on Launch, Windows
Thanks for the pointer! Yep, same here - if I --disable-pie, rebuild and try again => now no crash, at least checking --version ;-). Will continue testing here, report back if I see any other oddities. Thanks again. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1870911 Title: QEMU Crashes on Launch, Windows Status in QEMU: New Bug description: Hi, I an having no issues up to (and including) v5.0.0-rc0, but when I move to rc1 ... it won't even execute in Windows. If I just try to, for example, run qemu-system-x86_64.exe --version No output, it just exits. This seems to be new with this version. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1870911/+subscriptions
Re: [PATCH v4 for-5.0] configure: warn if not using a separate build directory
On Fri, 3 Apr 2020 at 14:53, Daniel P. Berrangé wrote: > > Running configure directly from the source directory is a build > configuration that will go away in future. It is also not currently > covered by any automated testing. Display a deprecation warning if > the user attempts to use an in-srcdir build setup, so that they are > aware that they're building QEMU in an undesirable manner. > > Reviewed-by: Eric Blake > Reviewed-by: Markus Armbruster > Reviewed-by: Philippe Mathieu-Daudé > Tested-by: Philippe Mathieu-Daudé > Signed-off-by: Daniel P. Berrangé > --- > +if test "$in_srcdir" = "yes"; then > +echo > +echo "WARNING: SUPPORT FOR BUILDING IN THE SOURCE DIR IS DEPRECATED" > +echo > +echo "Support for running the 'configure' script directly from the" > +echo "source directory is deprecated. In-tree builds are not covered" > +echo "by automated testing and thus may not correctly build QEMU." > +echo "Users are recommended to use a separate build directory:" > +echo > +echo " $ mkdir build" > +echo " $ cd build" > +echo " $ ../configure" > +echo " $ make" > +echo > +fi So here's my stab at some text here; I'm aiming at nudging users towards out-of-tree builds if they were simply not thinking about it, but not actively marking them as 'deprecated', since it sounded to me like we were planning to keep at least the basic 'configure+make+make install' sequence of commands working. echo "NOTE: we recommend against building in the source directory" echo echo "You've run the 'configure' script directly from the source" echo "directory. This will work, but we recommend using a separate" echo "build directory, especially if you plan to work with the QEMU" echo "sources rather than just building it once. You can switch to" echo "a separate build directory like this:" [instructions go here] thanks -- PMM
Re: [Bug 1870911] [NEW] QEMU Crashes on Launch, Windows
On Sun, Apr 5, 2020 at 3:38 PM Russell Morris wrote: > Public bug reported: > > Hi, > > I an having no issues up to (and including) v5.0.0-rc0, but when I move > to rc1 ... it won't even execute in Windows. If I just try to, for > example, run > > qemu-system-x86_64.exe --version > > No output, it just exits. This seems to be new with this version. > > Thanks! > > ** Affects: qemu > Importance: Undecided > Status: New > > -- > You received this bug notification because you are a member of qemu- > devel-ml, which is subscribed to QEMU. > https://bugs.launchpad.net/bugs/1870911 > > Title: > QEMU Crashes on Launch, Windows > > Status in QEMU: > New > > Bug description: > Hi, > > I an having no issues up to (and including) v5.0.0-rc0, but when I > move to rc1 ... it won't even execute in Windows. If I just try to, > for example, run > > qemu-system-x86_64.exe --version > > No output, it just exits. This seems to be new with this version. > > Thanks! > > To manage notifications about this bug go to: > https://bugs.launchpad.net/qemu/+bug/1870911/+subscriptions > > Happens to me too with qemu-system-ppc. Earlier thread is here: https://lists.nongnu.org/archive/html/qemu-ppc/2020-04/msg00027.html For now compiling with --disable-pie will produce a running executable. Best, Howard
[Bug 1870911] [NEW] QEMU Crashes on Launch, Windows
Public bug reported: Hi, I an having no issues up to (and including) v5.0.0-rc0, but when I move to rc1 ... it won't even execute in Windows. If I just try to, for example, run qemu-system-x86_64.exe --version No output, it just exits. This seems to be new with this version. Thanks! ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1870911 Title: QEMU Crashes on Launch, Windows Status in QEMU: New Bug description: Hi, I an having no issues up to (and including) v5.0.0-rc0, but when I move to rc1 ... it won't even execute in Windows. If I just try to, for example, run qemu-system-x86_64.exe --version No output, it just exits. This seems to be new with this version. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1870911/+subscriptions
Re: [PATCH] hw/riscv: Generate correct "mmu-type" for 32-bit machines
Hi Palmer, On Tue, Mar 10, 2020 at 1:22 AM Alistair Francis wrote: > > On Sat, Mar 7, 2020 at 4:49 AM Bin Meng wrote: > > > > 32-bit machine should have its CPU's "mmu-type" set to "riscv,sv32". > > > > Signed-off-by: Bin Meng > > Reviewed-by: Alistair Francis > Ping? Could you please take this for v5.0.0? Regards, Bin
[PATCH v2 3/3] dsoundaudio: dsound_get_buffer_in should honor *size
This patch prevents an underflow of variable samples in function
audio_pcm_hw_run_in(). See commit 599eac4e5a "audio:
audio_generic_get_buffer_in should honor *size". This time the
while loop in audio_pcm_hw_run_in() will terminate nevertheless,
because it seems the recording stream in Windows is always rate
limited.
Signed-off-by: Volker Rümelin
---
audio/audio.c | 12 +---
audio/dsoundaudio.c | 2 +-
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/audio/audio.c b/audio/audio.c
index 9ac9a20c41..7a9e680355 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -1491,15 +1491,13 @@ size_t audio_generic_write(HWVoiceOut *hw, void *buf,
size_t size)
size_t audio_generic_read(HWVoiceIn *hw, void *buf, size_t size)
{
-size_t src_size, copy_size;
-void *src = hw->pcm_ops->get_buffer_in(hw, _size);
-copy_size = MIN(size, src_size);
+void *src = hw->pcm_ops->get_buffer_in(hw, );
-memcpy(buf, src, copy_size);
-hw->pcm_ops->put_buffer_in(hw, src, copy_size);
-return copy_size;
-}
+memcpy(buf, src, size);
+hw->pcm_ops->put_buffer_in(hw, src, size);
+return size;
+}
static int audio_driver_init(AudioState *s, struct audio_driver *drv,
bool msg, Audiodev *dev)
diff --git a/audio/dsoundaudio.c b/audio/dsoundaudio.c
index a08d519cae..4cdf19ab67 100644
--- a/audio/dsoundaudio.c
+++ b/audio/dsoundaudio.c
@@ -540,7 +540,7 @@ static void *dsound_get_buffer_in(HWVoiceIn *hw, size_t
*size)
}
req_size = audio_ring_dist(cpos, hw->pos_emul, hw->size_emul);
-req_size = MIN(req_size, hw->size_emul - hw->pos_emul);
+req_size = MIN(*size, MIN(req_size, hw->size_emul - hw->pos_emul));
if (req_size == 0) {
*size = 0;
--
2.16.4
[PATCH v2 1/3] dsoundaudio: fix never-ending playback loop
Currently the DirectSound backend fails to stop audio playback
in dsound_enable_out(). To detect a lost buffer condition
dsound_get_status_out() incorrectly uses the error code
DSERR_BUFFERLOST instead of flag DSBSTATUS_BUFFERLOST as a mask
and returns with an error. As a result dsound_enable_out()
returns early and doesn't stop playback.
To reproduce the bug start qemu on a Windows host with
-soundhw pcspk -audiodev dsound,id=audio0. On the guest
FreeDOS 1.2 command line enter beep. The image Day 1 - F-Bird
from the QEMU Advent Calendar 2018 shows the bug as well.
Buglink: https://bugs.launchpad.net/qemu/+bug/1699628
Signed-off-by: Volker Rümelin
---
audio/dsoundaudio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/audio/dsoundaudio.c b/audio/dsoundaudio.c
index bd57082a8d..9e621c8899 100644
--- a/audio/dsoundaudio.c
+++ b/audio/dsoundaudio.c
@@ -279,7 +279,7 @@ static int dsound_get_status_out (LPDIRECTSOUNDBUFFER dsb,
DWORD *statusp,
return -1;
}
-if (*statusp & DSERR_BUFFERLOST) {
+if (*statusp & DSBSTATUS_BUFFERLOST) {
dsound_restore_out(dsb, s);
return -1;
}
--
2.16.4
[PATCH v2 2/3] dsoundaudio: fix "Could not lock capture buffer" warning
IDirectSoundCaptureBuffer_Lock() fails on Windows when called
with len = 0. Return early from dsound_get_buffer_in() in this
case.
To reproduce the warning start a linux guest. In the guest
start Audacity and you will see a lot of "Could not lock
capture buffer" warnings.
Signed-off-by: Volker Rümelin
---
audio/dsoundaudio.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/audio/dsoundaudio.c b/audio/dsoundaudio.c
index 9e621c8899..a08d519cae 100644
--- a/audio/dsoundaudio.c
+++ b/audio/dsoundaudio.c
@@ -542,6 +542,11 @@ static void *dsound_get_buffer_in(HWVoiceIn *hw, size_t
*size)
req_size = audio_ring_dist(cpos, hw->pos_emul, hw->size_emul);
req_size = MIN(req_size, hw->size_emul - hw->pos_emul);
+if (req_size == 0) {
+*size = 0;
+return NULL;
+}
+
err = dsound_lock_in(dscb, >info, hw->pos_emul, req_size, , NULL,
_size, NULL, false, ds->s);
if (err) {
--
2.16.4
[PATCH v2 0/3] DirectSound fixes for 5.0
Three audio fixes for DirectSound on Windows. They were tested on a Windows 10 Home system with HAXM accelerator. v2: - "dsoundaudio: fix never-ending playback loop" The commit message and the changed code was wrong. Volker Rümelin (3): dsoundaudio: fix never-ending playback loop dsoundaudio: fix "Could not lock capture buffer" warning dsoundaudio: dsound_get_buffer_in should honor *size audio/audio.c | 12 +--- audio/dsoundaudio.c | 9 +++-- 2 files changed, 12 insertions(+), 9 deletions(-) -- 2.16.4
Re: [PATCH] ppc/pnv: Create BMC devices only when defaults are enabled
On 4/4/20 11:44 PM, Nathan Chancellor wrote:
> Hi Cédric,
>
> On Sat, Apr 04, 2020 at 05:36:55PM +0200, Cédric Le Goater wrote:
>> Commit e2392d4395dd ("ppc/pnv: Create BMC devices at machine init")
>> introduced default BMC devices which can be a problem when the same
>> devices are defined on the command line with :
>>
>> -device ipmi-bmc-sim,id=bmc0 -device isa-ipmi-bt,bmc=bmc0,irq=10
>>
>> QEMU fails with :
>>
>> qemu-system-ppc64: error creating device tree: node: FDT_ERR_EXISTS
>>
>> Use defaults_enabled() when creating the default BMC devices to let
>> the user provide its own BMC devices using '-nodefaults'. If no BMC
>> device are provided, output a warning but let QEMU run as this is a
>> supported configuration. However, when multiple BMC devices are
>> defined, stop QEMU with a clear error as the results are unexpected.
>>
>> Fixes: e2392d4395dd ("ppc/pnv: Create BMC devices at machine init")
>> Reported-by: Nathan Chancellor
>> Signed-off-by: Cédric Le Goater
>
> This fixes my issue when -nodefaults is passed and that does not regress
> QEMU 3.1.0 or 4.2.0. Thank you for the quick fix!
>
> Tested-by: Nathan Chancellor
>
> A few comments inline.
>
>> ---
>> include/hw/ppc/pnv.h | 2 ++
>> hw/ppc/pnv.c | 32 ++-
>> hw/ppc/pnv_bmc.c | 45
>> 3 files changed, 74 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
>> index fb4d0c0234b3..d4b0b0e2ff71 100644
>> --- a/include/hw/ppc/pnv.h
>> +++ b/include/hw/ppc/pnv.h
>> @@ -241,6 +241,8 @@ struct PnvMachineState {
>> void pnv_dt_bmc_sensors(IPMIBmc *bmc, void *fdt);
>> void pnv_bmc_powerdown(IPMIBmc *bmc);
>> IPMIBmc *pnv_bmc_create(PnvPnor *pnor);
>> +IPMIBmc *pnv_bmc_find(Error **errp);
>> +void pnv_bmc_set_pnor(IPMIBmc *bmc, PnvPnor *pnor);
>>
>> /*
>> * POWER8 MMIO base addresses
>> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
>> index ac83b8698b8e..a3b7a8d0ff32 100644
>> --- a/hw/ppc/pnv.c
>> +++ b/hw/ppc/pnv.c
>> @@ -573,10 +573,29 @@ static void pnv_powerdown_notify(Notifier *n, void
>> *opaque)
>>
>> static void pnv_reset(MachineState *machine)
>> {
>> +PnvMachineState *pnv = PNV_MACHINE(machine);
>> +IPMIBmc *bmc;
>> void *fdt;
>>
>> qemu_devices_reset();
>>
>> +/*
>> + * The machine should provide by default an internal BMC simulator.
>> + * If not, try to use the BMC device that was provided on the command
>> + * line.
>> + */
>> +bmc = pnv_bmc_find(_fatal);
>> +if (!pnv->bmc) {
>> +if (!bmc) {
>> +warn_report("machine has no BMC device. Use '-device "
>> +"ipmi-bmc-sim,id=bmc0 -device
>> isa-ipmi-bt,bmc=bmc0,irq=10' "
>> +"to define one");
>
> If I pass no -device flags + -nodefaults, I don't see this message. Is
> that expected?
yes. Because the machine instantiates the default BMC devices.
>
>> +} else {
>> +pnv_bmc_set_pnor(bmc, pnv->pnor);
>> +pnv->bmc = bmc;
>> +}
>> +}
>> +
>> fdt = pnv_dt_create(machine);
>>
>> /* Pack resulting tree */
>> @@ -835,9 +854,6 @@ static void pnv_init(MachineState *machine)
>> }
>> g_free(chip_typename);
>>
>> -/* Create the machine BMC simulator */
>> -pnv->bmc = pnv_bmc_create(pnv->pnor);
>> -
>> /* Instantiate ISA bus on chip 0 */
>> pnv->isa_bus = pnv_isa_create(pnv->chips[0], _fatal);
>>
>> @@ -847,8 +863,14 @@ static void pnv_init(MachineState *machine)
>> /* Create an RTC ISA device too */
>> mc146818_rtc_init(pnv->isa_bus, 2000, NULL);
>>
>> -/* Create the IPMI BT device for communication with the BMC */
>> -pnv_ipmi_bt_init(pnv->isa_bus, pnv->bmc, 10);
>> +/*
>> + * Create the machine BMC simulator and the IPMI BT device for
>> + * communication with the BMC
>> + */
>> +if (defaults_enabled()) {
>> +pnv->bmc = pnv_bmc_create(pnv->pnor);
>> +pnv_ipmi_bt_init(pnv->isa_bus, pnv->bmc, 10);
>> +}
>>
>> /*
>> * OpenPOWER systems use a IPMI SEL Event message to notify the
>> diff --git a/hw/ppc/pnv_bmc.c b/hw/ppc/pnv_bmc.c
>> index 8863354c1c08..4e018b8b70e4 100644
>> --- a/hw/ppc/pnv_bmc.c
>> +++ b/hw/ppc/pnv_bmc.c
>> @@ -213,6 +213,18 @@ static const IPMINetfn hiomap_netfn = {
>> .cmd_handlers = hiomap_cmds
>> };
>>
>> +
>> +void pnv_bmc_set_pnor(IPMIBmc *bmc, PnvPnor *pnor)
>> +{
>> +object_ref(OBJECT(pnor));
>> +object_property_add_const_link(OBJECT(bmc), "pnor", OBJECT(pnor),
>> + _abort);
>> +
>> +/* Install the HIOMAP protocol handlers to access the PNOR */
>> +ipmi_sim_register_netfn(IPMI_BMC_SIMULATOR(bmc), IPMI_NETFN_OEM,
>> +_netfn);
>> +}
>> +
>> /*
>> * Instantiate the machine BMC. PowerNV uses the QEMU internal
>> * simulator but it could also be external.
>> @@ -232,3
Re: [PATCH for-5.0] hw/gpio/aspeed_gpio.c: Don't directly include assert.h
On Fri, 3 Apr 2020, at 23:17, Peter Maydell wrote: > Remove a direct include of assert.h -- this is already > provided by qemu/osdep.h, and it breaks our rule that the > first include must always be osdep.h. > > In particular we must get the assert() macro via osdep.h > to avoid compile failures on mingw (see the comment in > osdep.h where we redefine assert() for that platform). > > Signed-off-by: Peter Maydell Acked-by: Andrew Jeffery
