[RFC PATCH 6/6] doc: Update multi-thread compression doc

Modify the doc to fit the previous changes. Signed-off-by: Zeyu Jin Signed-off-by: Ying Fang --- docs/multi-thread-compression.txt | 31 ++- 1 file changed, 18 insertions(+), 13 deletions(-) diff --git a/docs/multi-thread-compression.txt

[RFC PATCH 5/6] migration: Add compress_level sanity check

Zlib compression has level from 1 to 9. However Zstd compression has level from 1 to 22 (level >= 20 not recommanded). Let's do sanity check here to make sure a vaild compress_level is given by user. Signed-off-by: Zeyu Jin Signed-off-by: Ying Fang --- migration/migration.c | 32

[RFC PATCH 3/6] migration: Add multi-thread compress ops

Add the MigrationCompressOps and MigrationDecompressOps structures to make the compression method configurable for multi-thread compression migration. Signed-off-by: Zeyu Jin Signed-off-by: Ying Fang parameters.decompress_threads; } +CompressMethod migrate_compress_method(void) +{ +

[RFC PATCH 4/6] migration: Add zstd support in multi-thread compression

This patch enables zstd option in multi-thread compression. Signed-off-by: Zeyu Jin Signed-off-by: Ying Fang --- hw/core/qdev-properties-system.c | 2 +- migration/ram.c | 128 ++- qapi/migration.json | 2 +- 3 files changed, 129

[PATCH 1/6] migration: Add multi-thread compress method

A multi-thread compress method parameter is added to hold the method we are going to use. By default the 'zlib' method is used to maintain the compatibility as before. Signed-off-by: Zeyu Jin Signed-off-by: Ying Fang --- hw/core/qdev-properties-system.c | 11 +++

[RFC PATCH 2/6] migration: Refactoring multi-thread compress migration

Code refactor for the compression procedure which includes: 1. Move qemu_compress_data and qemu_put_compression_data from qemu-file.c to ram.c, for the reason that most part of the code logical has nothing to do with qemu-file. Besides, the decompression code is located at ram.c only. 2.

[RFC PATCH 0/6] migration: Multi-thread compression method support

Currently we have both multi-thread compression and multifd to optimize live migration in Qemu. Mulit-thread compression deals with the situation where network bandwith is limited but cpu resource adequate. Multifd instead aims to take full advantage of network bandwith. Moreover it supports both

Re: [PATCH v2 09/13] audio: remove GNUC & MSVC check

On Fri, Nov 27, 2020 at 11:15 AM Gerd Hoffmann wrote: > Hi, > > > > #if defined AUDIO_BREAKPOINT_ON_BUG > > > # if defined HOST_I386 > > > + __asm__ ("int3"); > > > # else > > > abort (); > > > # endif > > > -- > > > 2.29.0 > > > > I would prefer to just drop this attempt

[PATCH 7/7] musicpal: Use ptimer_free() in the finalize function to avoid memleaks

When running device-introspect-test, a memory leak occurred in the mv88w8618_pit_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 192 byte(s) in 4 object(s) allocated from: #0 0xab97e1f0 in __interceptor_calloc

[PATCH 5/7] exynos4210_rtc: Use ptimer_free() in the finalize function to avoid memleaks

When running device-introspect-test, a memory leak occurred in the exynos4210_rtc_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 96 byte(s) in 1 object(s) allocated from: #0 0xab97e1f0 in __interceptor_calloc

[PATCH 4/7] exynos4210_pwm: Use ptimer_free() in the finalize function to avoid memleaks

When running device-introspect-test, a memory leak occurred in the exynos4210_pwm_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 240 byte(s) in 5 object(s) allocated from: #0 0xab97e1f0 in __interceptor_calloc

[PATCH 6/7] mss-timer: Use ptimer_free() in the finalize function to avoid memleaks

When running device-introspect-test, a memory leak occurred in the mss_timer_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 192 byte(s) in 2 object(s) allocated from: #0 0xab97e1f0 in __interceptor_calloc

[PATCH 2/7] digic-timer: Use ptimer_free() in the finalize function to avoid memleaks

When running device-introspect-test, a memory leak occurred in the digic_timer_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 288 byte(s) in 3 object(s) allocated from: #0 0xab97e1f0 in __interceptor_calloc

Re: [RFC PATCH 1/2] spapr: drc: Add support for async hcalls at the drc level

Thanks for the comments Bharata. On Fri, Nov 27, 2020 at 11:12 AM Bharata B Rao wrote: > ... > > +qemu_mutex_lock(>async_hcall_states_lock); > > +retry: > > +if (qemu_guest_getrandom(, sizeof(token), ) < 0) { > > +error_report_err(err); > > +g_free(state); > > +

[PATCH 3/7] exynos4210_mct: Use ptimer_free() in the finalize function to avoid memleaks

When running device-introspect-test, a memory leak occurred in the exynos4210_mct_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 96 byte(s) in 1 object(s) allocated from: #0 0xab97e1f0 in __interceptor_calloc

[PATCH 1/7] allwinner-a10-pit: Use ptimer_free() in the finalize function to avoid memleaks

When running device-introspect-test, a memory leak occurred in the a10_pit_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 288 byte(s) in 6 object(s) allocated from: #0 0xab97e1f0 in __interceptor_calloc

Re: [PATCH v3] Fix build with 64 bits time_t

Hi, > Changes v2 -> v3 (after review of Gerd Hoffmann): > - Replace include on by >"standard-headers/linux/input.h" to try to fix build on rhel-7 Now it complains about ioctl() not being declared. /me suggests to create a fork @ gitlab.com and push your branch there, that'll run it

[PATCH 0/7] Fix some memleaks caused by ptimer_init

Hi all, When running device-introspect-test, I found some memory leaks caused by ptimer_init in the init function, so I released it in the finalize function. Gan Qixin (7): allwinner-a10-pit: Use ptimer_free() in the finalize function to avoid memleaks digic-timer: Use ptimer_free() in

Re: [PATCH v2 09/13] audio: remove GNUC & MSVC check

Hi, > > #if defined AUDIO_BREAKPOINT_ON_BUG > > # if defined HOST_I386 > > + __asm__ ("int3"); > > # else > > abort (); > > # endif > > -- > > 2.29.0 > > I would prefer to just drop this attempt to emit an inline > breakpoint insn (which won't work on non-x86 hosts and

Re: [PATCH] qxl: fix segfault

Hi, > > It would be nice to include this regression fix in the release. Anyone > > taking the patch to PR? > > Looks like a safe fix and we do need to roll rc4 anyway, so if somebody wants > to send a pullreq tomorrow I can apply it. I had one prepared already and was waiting for ci. Sent

[PULL 1/1] qxl: fix segfault

Add missing sanity check. Reproducer: run qemu with "-device qxl" but without "-spice ..." Fixes: 0d9b90ce5c73 ("console: make QMP/HMP screendump run in coroutine") Signed-off-by: Gerd Hoffmann Reviewed-by: Marc-André Lureau Message-id: 20201124122936.30588-1-kra...@redhat.com --- ui/console.c

[PULL 0/1] Fixes 20201127 patches

The following changes since commit dd3d2340c4076d1735cd0f7cb61f4d8622b9562d: Update version for v5.2.0-rc3 release (2020-11-24 22:13:30 +) are available in the Git repository at: git://git.kraxel.org/qemu tags/fixes-20201127-pull-request for you to fetch changes up to

Re: [RFC v6 10/11] accel: introduce AccelCPUClass extending CPUClass

On 26/11/20 23:32, Claudio Fontana wrote: +if (acc) { +object_class_foreach(accel_init_cpu_int_aux, cpu_type, false, acc); +} Any reason to do it for cpu_type only, rather than for all subclasses of CPU_RESOLVING_TYPE? This would remove the cpu_type argument to

Re: [RFC PATCH v2 0/5] eBPF RSS support for virtio-net

On Fri, Nov 27, 2020 at 6:36 AM Jason Wang wrote: > > On 2020/11/26 下午8:52, Yuri Benditovich wrote: > > > > > > On Mon, Nov 23, 2020 at 8:08 AM Jason Wang > > wrote: > > > > > > On 2020/11/19 下午7:13, Andrew Melnychenko wrote: > > > This set of patches

Re: [PATCH for-6.0 4/9] spapr: Set compat mode in spapr_reset_vcpu()

On Thu, Nov 26, 2020 at 10:10:27AM +0100, Greg Kurz wrote: > On Thu, 26 Nov 2020 15:57:37 +1100 > David Gibson wrote: > > > On Wed, Nov 25, 2020 at 10:51:05AM +0100, Greg Kurz wrote: > > > On Wed, 25 Nov 2020 13:39:47 +1100 > > > David Gibson wrote: > > > > > > > On Mon, Nov 23, 2020 at

Re: [RFC PATCH 1/2] spapr: drc: Add support for async hcalls at the drc level

On Thu, Nov 26, 2020 at 01:54:55AM -0600, Shivaprasad G Bhat wrote: > The patch adds support for async hcalls at the DRC level for the > spapr devices. To be used by spapr-scm devices in the patch/es to follow. > > Signed-off-by: Shivaprasad G Bhat > --- > hw/ppc/spapr_drc.c | 146 >

Re: [PATCH 0/1] net: Fix handling of id in netdev_add and netdev_del

On 2020/11/25 下午6:02, Markus Armbruster wrote: This is a regression fix, but the regression is already in 5.0. I think it's too late for 5.2. If I'm right, then the issue should be documented in the release notes (I can do that). Please do that and I've queued this for the next release.

Re: [PATCH v2] net/e1000e_core: adjust count if RDH exceeds RDT in e1000e_ring_advance()

On 2020/11/24 上午5:30, Mauro Matteo Cascella wrote: On Thu, Nov 19, 2020 at 6:57 AM Jason Wang wrote: On 2020/11/18 下午4:53, Mauro Matteo Cascella wrote: On Wed, Nov 18, 2020 at 4:56 AM Jason Wang wrote: On 2020/11/13 下午6:31, Mauro Matteo Cascella wrote: The e1000e_write_packet_to_guest()

[Bug 1905651] Re: Tests cannot call g_error

I don't know QEMU that well yet, but the following question arises: Why can't QEMU be driven in a way that allows it to see that its controlling parent has died -> causing QEMU to terminate as well. That way the test doesn't need to care how it dies (e.g., we don't want a segfault to hang testing;

Re: [PATCH 26/36] remove preconfig state

On 26/11/20 19:55, Igor Mammedov wrote: On Mon, 23 Nov 2020 09:14:25 -0500 Paolo Bonzini wrote: The preconfig state is only used if -incoming is not specified, which makes the RunState state machine more tricky than it need be. However there is already an equivalent condition which works

Re: [PATCH 13/36] vl: move semihosting command line fallback to qemu_init_board

On 26/11/20 18:10, Igor Mammedov wrote: On Mon, 23 Nov 2020 09:14:12 -0500 Paolo Bonzini wrote: Move more sane parts of the huge qemu_init function out of it. Signed-off-by: Paolo Bonzini --- softmmu/vl.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git

Re: [PATCH v2 2/6] accel: accel_available() function

On 26/11/20 22:06, Claudio Fontana wrote: I think it's just that the usecase is not that common. "Is this accelerator compiled in the binary" is not something you need after startup (or if querying the monitor). A script that repeatedly uses the QMP interface to query for the status could

Re: [PATCH 7/8] arm: Add Hypervisor.framework build target

On 26/11/20 22:50, Alexander Graf wrote: Now that we have all logic in place that we need to handle Hypervisor.framework on Apple Silicon systems, let's add CONFIG_HVF for aarch64 as well so that we can build it. Signed-off-by: Alexander Graf Between patch 1 and this one, this series is a

Re: [PATCH 1/8] hvf: Add hypervisor entitlement to output binaries

On 26/11/20 22:50, Alexander Graf wrote: +rm -f "$2" +cp -a "$SRC" "$DST" +codesign --entitlements "$ENTITLEMENT" --force -s - "$DST" Slight improvement to avoid races between ^C and this script: set -e trap 'rm "$DST.tmp"' exit cp -a "$SRC" "$DST.tmp" codesign --entitlements "$ENTITLEMENT"

Re: [PATCH 4/8] arm: Synchronize CPU on PSCI on

On 27/11/20 00:32, Alexander Graf wrote: On 26.11.20 23:26, Peter Maydell wrote: On Thu, 26 Nov 2020 at 22:16, Alexander Graf wrote: cpu_synchronize_state() sets the CPU registers into "dirty" state which means that env now holds the current copy. On the next entry, we then sync them back

Re: [RFC PATCH v2 5/5] docs: Added eBPF documentation.

On 2020/11/26 下午9:00, Yuri Benditovich wrote: This reminds me that we probably need to probe this ability via configure script. I'm not sure. One can boot with an older kernel, build qemu and run it with a newer kernel, correct? Yes, so we should depend on verifier instead of

Re: [RFC PATCH v2 0/5] eBPF RSS support for virtio-net

On 2020/11/26 下午8:52, Yuri Benditovich wrote: On Mon, Nov 23, 2020 at 8:08 AM Jason Wang > wrote: On 2020/11/19 下午7:13, Andrew Melnychenko wrote: > This set of patches introduces the usage of eBPF for packet steering > and RSS hash calculation:

[Bug 1896317] Re: ioapic: UndefinedBehaviorSanitizer starting qemu-system-i386

[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1896317 Title: ioapic:

Re: [RFC] ich9:cpuhp: add support for cpu hot-unplug with SMI broadcast enabled

On 2020-11-26 12:38 p.m., Igor Mammedov wrote: On Thu, 26 Nov 2020 12:17:27 +0100 Laszlo Ersek wrote: On 11/24/20 13:25, Igor Mammedov wrote: If firmware negotiates ICH9_LPC_SMI_F_CPU_HOT_UNPLUG_BIT feature, OSPM on CPU eject will set bit #4 in CPU hotplug block for to be ejected CPU to mark

Re: [RFC] ich9:cpuhp: add support for cpu hot-unplug with SMI broadcast enabled

On 2020-11-26 11:50 a.m., Igor Mammedov wrote: On Thu, 26 Nov 2020 13:46:32 +0100 Laszlo Ersek wrote: On 11/26/20 11:24, Ankur Arora wrote: On 2020-11-24 4:25 a.m., Igor Mammedov wrote: If firmware negotiates ICH9_LPC_SMI_F_CPU_HOT_UNPLUG_BIT feature, OSPM on CPU eject will set bit #4 in

Re: [RFC] ich9:cpuhp: add support for cpu hot-unplug with SMI broadcast enabled

On 2020-11-26 4:46 a.m., Laszlo Ersek wrote: On 11/26/20 11:24, Ankur Arora wrote: On 2020-11-24 4:25 a.m., Igor Mammedov wrote: If firmware negotiates ICH9_LPC_SMI_F_CPU_HOT_UNPLUG_BIT feature, OSPM on CPU eject will set bit #4 in CPU hotplug block for to be ejected CPU to mark it for removal

RE: [PATCH] block: Don't inactivate bs if it is aleady inactive

> The following steps will cause qemu assertion failure: > - pause vm > - save memory snapshot into local file through fd migration > - do the above operation again will cause qemu assertion failure > > The backtrace looks like: > #0 0x7fbf958c5c37 in raise () from

[PATCH v5 05/12] hw/block/nvme: support namespace types

From: Klaus Jensen Implement support for TP 4056 ("Namespace Types"). This adds the 'iocs' (I/O Command Set) device parameter to the nvme-ns device. Signed-off-by: Klaus Jensen --- docs/specs/nvme.txt | 3 + hw/block/nvme-ns.h| 12 ++- hw/block/nvme.h | 3 +

[Bug 1796520] Re: autogen crashes on qemu-sh4-user after 61dedf2af7

Bug is still pending on git master. Have not pinged the SuperH crew yet. Will try to do that tomorrow, I'll also ping glibc upstream. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1796520 Title:

[PATCH v5 08/12] hw/block/nvme: add the zone management send command

From: Klaus Jensen Add the Zone Management Send command. The spec specifies that "All logical blocks in a zone *shall* be marked as deallocated when [the zone is reset]". Since the device guarantees 0x00 to be read from deallocated blocks we have to issue a pwrite_zeroes since we cannot be sure

[PATCH v5 10/12] hw/block/nvme: track and enforce zone resources

From: Klaus Jensen Track number of open/active resources. Signed-off-by: Klaus Jensen --- docs/specs/nvme.txt | 6 hw/block/nvme-ns.h | 7 + include/block/nvme.h | 2 ++ hw/block/nvme-ns.c | 17 ++-- hw/block/nvme.c | 65

[PATCH v5 09/12] hw/block/nvme: add the zone append command

From: Klaus Jensen Add the Zone Append command. Signed-off-by: Klaus Jensen --- hw/block/nvme.h | 5 include/block/nvme.h | 7 ++ hw/block/nvme.c | 53 +++ hw/block/trace-events | 1 + 4 files changed, 66 insertions(+) diff

[PATCH v5 11/12] hw/block/nvme: allow open to close zone transitions by controller

From: Klaus Jensen Allow the controller to release open resources by transitioning implicitly and explicitly opened zones to closed. This is done using a naive "least recently opened" strategy. Signed-off-by: Klaus Jensen --- hw/block/nvme-ns.h| 5 hw/block/nvme-ns.c| 3 +++

[PATCH v5 06/12] hw/block/nvme: add basic read/write for zoned namespaces

From: Klaus Jensen This adds basic read and write for zoned namespaces. A zoned namespace is created by setting the iocs namespace parameter to 0x2 and specifying the zns.zcap parameter (zone capacity) in number of logical blocks per zone. If a zone size (zns.zsze) is not specified, the

[PATCH v5 04/12] hw/block/nvme: Generate namespace UUIDs

From: Dmitry Fomichev In NVMe 1.4, a namespace must report an ID descriptor of UUID type if it doesn't support EUI64 or NGUID. Add a new namespace property, "uuid", that provides the user the option to either specify the UUID explicitly or have a UUID generated automatically every time a

[PATCH RFC v5 12/12] hw/block/nvme: add persistence for zone info

From: Klaus Jensen Signed-off-by: Klaus Jensen --- docs/specs/nvme.txt | 15 +++ hw/block/nvme-ns.h| 16 hw/block/nvme-ns.c| 212 +- hw/block/nvme.c | 87 + hw/block/trace-events | 2 + 5 files changed, 331

[PATCH v5 07/12] hw/block/nvme: add the zone management receive command

From: Klaus Jensen Add the Zone Management Receive command. Signed-off-by: Klaus Jensen --- hw/block/nvme-ns.h| 8 +++ hw/block/nvme.h | 1 + include/block/nvme.h | 46 + hw/block/nvme-ns.c| 8 +++ hw/block/nvme.c | 150

[PATCH v5 01/12] hw/block/nvme: Separate read and write handlers

From: Dmitry Fomichev With ZNS support in place, the majority of code in nvme_rw() has become read- or write-specific. Move these parts to two separate handlers, nvme_read() and nvme_write() to make the code more readable and to remove multiple is_write checks that so far existed in the i/o

[PATCH v5 03/12] hw/block/nvme: add commands supported and effects log page

From: Gollu Appalanaidu This is to support for the Commands Supported and Effects log page. See NVM Express Spec 1.3d, sec. 5.14.1.5 ("Commands Supported and Effects") Signed-off-by: Gollu Appalanaidu Signed-off-by: Klaus Jensen --- include/block/nvme.h | 25 --

[PATCH v5 00/12] hw/block/nvme: zoned namespace command set

From: Klaus Jensen Oi, Things seem to have slowed down a bit on the zoned front, so in the interest of moving things forward and catalyzing the process, I'm posting a v5 of my series (v4 never got posted, but it's in my repo for posterity, see below). I picked some preparatory patches from

[PATCH v5 02/12] hw/block/nvme: Merge nvme_write_zeroes() with nvme_write()

From: Dmitry Fomichev nvme_write() now handles WRITE, WRITE ZEROES and ZONE_APPEND. Signed-off-by: Dmitry Fomichev Reviewed-by: Niklas Cassel [kj: rebased] Signed-off-by: Klaus Jensen --- hw/block/nvme.c | 69 +-- hw/block/trace-events | 1 - 2

Re: [PATCH 4/8] arm: Synchronize CPU on PSCI on

On 26.11.20 23:26, Peter Maydell wrote: On Thu, 26 Nov 2020 at 22:16, Alexander Graf wrote: cpu_synchronize_state() sets the CPU registers into "dirty" state which means that env now holds the current copy. On the next entry, we then sync them back into HVF. Without the

Re: [PATCH for-6.0 4/9] spapr: Set compat mode in spapr_reset_vcpu()

On Thu, 26 Nov 2020 17:23:20 +0100 Igor Mammedov wrote: > On Thu, 26 Nov 2020 10:10:27 +0100 > Greg Kurz wrote: > > > On Thu, 26 Nov 2020 15:57:37 +1100 > > David Gibson wrote: > > > > > On Wed, Nov 25, 2020 at 10:51:05AM +0100, Greg Kurz wrote: > > > > On Wed, 25 Nov 2020 13:39:47

[RFC v6 11/11] i386: split cpu accelerators from cpu.c, using AccelCPUClass

i386 is the first user of AccelCPUClass, allowing to split cpu.c into: cpu.ccpuid and common x86 cpu functionality host-cpu.c host x86 cpu functions and "host" cpu type kvm/cpu.cKVM x86 AccelCPUClass hvf/cpu.cHVF x86 AccelCPUClass tcg/cpu.cTCG x86

[RFC v6 08/11] accel: extend AccelState and AccelClass to user-mode

Signed-off-by: Claudio Fontana --- MAINTAINERS| 2 +- accel/accel-common.c | 50 ++ accel/{accel.c => accel-softmmu.c} | 27 ++-- accel/accel-user.c | 24 ++ accel/meson.build

[RFC v6 09/11] accel: replace struct CpusAccel with AccelOpsClass

centralize the registration of the cpus.c module accelerator operations in accel/accel-softmmu.c Signed-off-by: Claudio Fontana --- MAINTAINERS | 3 ++- accel/accel-common.c | 11 + accel/accel-softmmu.c| 43 +++---

[RFC v6 10/11] accel: introduce AccelCPUClass extending CPUClass

add a new optional interface to CPUClass, which allows accelerators to extend the CPUClass with additional accelerator-specific initializations. Signed-off-by: Claudio Fontana --- MAINTAINERS | 1 + accel/accel-common.c| 43 +

[RFC v6 04/11] i386: hvf: remove stale MAINTAINERS entry for old hvf stubs

Signed-off-by: Claudio Fontana Reviewed-by: Roman Bolshakov --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 463317784c..e892dd2220 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -443,7 +443,6 @@ M: Cameron Esfahani M: Roman Bolshakov W:

[RFC v6 03/11] i386: move hax accel files into hax/

Signed-off-by: Claudio Fontana --- MAINTAINERS | 2 +- target/i386/{ => hax}/hax-all.c | 0 target/i386/{ => hax}/hax-cpus.c | 0 target/i386/{ => hax}/hax-cpus.h | 0 target/i386/{ => hax}/hax-i386.h | 6 +++--- target/i386/{ =>

[RFC v6 07/11] i386: move TCG cpu class initialization out of helper.c

Signed-off-by: Claudio Fontana --- target/i386/cpu.c | 33 -- target/i386/cpu.h | 97 ++--- target/i386/helper-tcg.h | 112 ++ target/i386/helper.c | 23 --- target/i386/meson.build

[RFC v6 06/11] i386: move cpu dump out of helper.c into cpu-dump.c

Signed-off-by: Claudio Fontana --- target/i386/cpu-dump.c | 538 target/i386/cpu.h | 1 + target/i386/helper.c| 514 -- target/i386/meson.build | 1 + 4 files changed, 540 insertions(+), 514 deletions(-)

[RFC v6 00/11] i386 cleanup

Hi all, this is v6 of the i386 cleanup, with the most interesting patches at the end. v5 -> v6: remove MODULE_INIT_ACCEL_CPU instead, use a call to accel_init_interfaces(). * The class lookups are now general and performed in accel/ new AccelCPUClass for new archs are supported as new ones

[RFC v6 05/11] i386: move TCG accel files into tcg/

Signed-off-by: Claudio Fontana --- target/i386/meson.build | 14 +- target/i386/{ => tcg}/bpt_helper.c | 0 target/i386/{ => tcg}/cc_helper.c | 0 target/i386/{ => tcg}/excp_helper.c | 0 target/i386/{ => tcg}/fpu_helper.c | 0 target/i386/{ => tcg}/int_helper.c

Re: [PATCH 8/8] hw/arm/virt: Disable highmem when on hypervisor.framework

On Thu, 26 Nov 2020 at 22:17, Alexander Graf wrote: > Are you suggesting that on boot, we start a tiny mini-VM to enumerate > the PARange and set highmem based on it? That sounds like absolute > overkill to me ... You'll likely want that for a bunch of other information too. The KVM version of

[RFC v6 02/11] i386: move whpx accel files into whpx/

Signed-off-by: Claudio Fontana --- MAINTAINERS | 5 + target/i386/meson.build | 5 + target/i386/whpx/meson.build | 4 target/i386/{ => whpx}/whp-dispatch.h | 0 target/i386/{ => whpx}/whpx-all.c | 0 target/i386/{ =>

[RFC v6 01/11] i386: move kvm accel files into kvm/

Signed-off-by: Claudio Fontana --- MAINTAINERS | 2 +- hw/i386/fw_cfg.c | 2 +- hw/i386/intel_iommu.c| 2 +- hw/i386/kvm/apic.c | 2 +- hw/i386/kvm/clock.c | 2 +- hw/i386/microvm.c

Re: [PATCH 4/8] arm: Synchronize CPU on PSCI on

On Thu, 26 Nov 2020 at 22:16, Alexander Graf wrote: > cpu_synchronize_state() sets the CPU registers into "dirty" state which > means that env now holds the current copy. On the next entry, we then > sync them back into HVF. > > Without the cpu_synchronize_state() call, HVF never knows that the

Re: [PATCH 8/8] hw/arm/virt: Disable highmem when on hypervisor.framework

On Thu, 26 Nov 2020 at 22:14, Eduardo Habkost wrote: > > On Thu, Nov 26, 2020 at 10:50:17PM +0100, Alexander Graf wrote: > > The Apple M1 only supports up to 36 bits of physical address space. That > > means we can not fit the 64bit MMIO BAR region into our address space. > > > > To fix this,

Re: [PATCH v2] hw/block/nvme: add compare command

Hello, On Fri, Nov 27, 2020 at 3:56 AM Klaus Jensen wrote: > > From: Gollu Appalanaidu > > Add the Compare command. > > This implementation uses a bounce buffer to read in the data from > storage and then compare with the host supplied buffer. > > Signed-off-by: Gollu Appalanaidu > [k.jensen:

Re: [PATCH 6/8] hvf: Use OS provided vcpu kick function

On Thu, Nov 26, 2020 at 10:50:15PM +0100, Alexander Graf wrote: > When kicking another vCPU, we get an OS function that explicitly does that > for us > on Apple Silicon. That works better than the current signaling logic, let's > make > use of it there. > > Signed-off-by: Alexander Graf > ---

Re: [PATCH 8/8] hw/arm/virt: Disable highmem when on hypervisor.framework

On 26.11.20 22:54, Peter Maydell wrote: On Thu, 26 Nov 2020 at 21:36, Alexander Graf wrote: The Apple M1 only supports up to 36 bits of physical address space. That means we can not fit the 64bit MMIO BAR region into our address space. To fix this, let's not expose a 64bit MMIO BAR region

Re: [PATCH 4/8] arm: Synchronize CPU on PSCI on

On 26.11.20 22:47, Peter Maydell wrote: On Thu, 26 Nov 2020 at 21:36, Alexander Graf wrote: We are going to reuse the TCG PSCI code for HVF. This however means that we need to ensure that CPU register state is synchronized properly between the two worlds. So let's make sure that at least on

Re: [PATCH 8/8] hw/arm/virt: Disable highmem when on hypervisor.framework

On Thu, Nov 26, 2020 at 10:50:17PM +0100, Alexander Graf wrote: > The Apple M1 only supports up to 36 bits of physical address space. That > means we can not fit the 64bit MMIO BAR region into our address space. > > To fix this, let's not expose a 64bit MMIO BAR region when running on > Apple

Re: [PATCH 0/8] hvf: Implement Apple Silicon Support

On Thu, Nov 26, 2020 at 10:50:09PM +0100, Alexander Graf wrote: > Now that Apple Silicon is widely available, people are obviously excited > to try and run virtualized workloads on them, such as Linux and Windows. > > This patch set implements a rudimentary, first version to get the ball > going

[PATCH 5/8] hvf: Add Apple Silicon support

With Apple Silicon available to the masses, it's a good time to add support for driving its virtualization extensions from QEMU. This patch adds all necessary architecture specific code to get basic VMs working. It's still pretty raw, but definitely functional. Known limitations: - Vtimer

[PATCH 0/8] hvf: Implement Apple Silicon Support

Now that Apple Silicon is widely available, people are obviously excited to try and run virtualized workloads on them, such as Linux and Windows. This patch set implements a rudimentary, first version to get the ball going on that. With this applied, I can successfully run both Linux and Windows

[PATCH 7/8] arm: Add Hypervisor.framework build target

Now that we have all logic in place that we need to handle Hypervisor.framework on Apple Silicon systems, let's add CONFIG_HVF for aarch64 as well so that we can build it. Signed-off-by: Alexander Graf --- meson.build| 9 - target/arm/hvf/meson.build | 3 +++

[PATCH 8/8] hw/arm/virt: Disable highmem when on hypervisor.framework

The Apple M1 only supports up to 36 bits of physical address space. That means we can not fit the 64bit MMIO BAR region into our address space. To fix this, let's not expose a 64bit MMIO BAR region when running on Apple Silicon. I have not been able to find a way to enumerate that easily, so

[PATCH 3/8] arm: Set PSCI to 0.2 for HVF

In Hypervisor.framework, we just pass PSCI calls straight on to the QEMU emulation of it. That means, if TCG is compatible with PSCI 0.2, so are we. Let's transpose that fact in code too. Signed-off-by: Alexander Graf --- target/arm/cpu.c | 4 1 file changed, 4 insertions(+) diff --git

Re: [PATCH 8/8] hw/arm/virt: Disable highmem when on hypervisor.framework

On Thu, 26 Nov 2020 at 21:36, Alexander Graf wrote: > The Apple M1 only supports up to 36 bits of physical address space. That > means we can not fit the 64bit MMIO BAR region into our address space. > > To fix this, let's not expose a 64bit MMIO BAR region when running on > Apple Silicon. > > I

[PATCH 2/8] hvf: Move common code out

Until now, Hypervisor.framework has only been available on x86_64 systems. With Apple Silicon shipping now, it extends its reach to aarch64. To prepare for support for multiple architectures, let's move common code out into its own accel directory. Signed-off-by: Alexander Graf --- MAINTAINERS

[PATCH 4/8] arm: Synchronize CPU on PSCI on

We are going to reuse the TCG PSCI code for HVF. This however means that we need to ensure that CPU register state is synchronized properly between the two worlds. So let's make sure that at least on the PSCI on call, the secondary core gets to sync its registers after reset, so that changes also

[PATCH 6/8] hvf: Use OS provided vcpu kick function

When kicking another vCPU, we get an OS function that explicitly does that for us on Apple Silicon. That works better than the current signaling logic, let's make use of it there. Signed-off-by: Alexander Graf --- accel/hvf/hvf-cpus.c | 12 1 file changed, 12 insertions(+) diff

[PATCH 1/8] hvf: Add hypervisor entitlement to output binaries

In macOS 11, QEMU only gets access to Hypervisor.framework if it has the respective entitlement. Add an entitlement template and automatically self sign and apply the entitlement in the build. Signed-off-by: Alexander Graf --- accel/hvf/entitlements.plist | 8 meson.build

Re: [PATCH v2 2/6] accel: accel_available() function

On Thu, Nov 26, 2020 at 10:06:03PM +0100, Claudio Fontana wrote: > On 11/26/20 3:25 PM, Paolo Bonzini wrote: > > On 26/11/20 15:13, Claudio Fontana wrote: > >> One option I see is simply to document the behavior where > >> accel_available() is declared in accel.h (ie do not use in fast > >> path),

Re: [PATCH 4/8] arm: Synchronize CPU on PSCI on

On Thu, 26 Nov 2020 at 21:36, Alexander Graf wrote: > > We are going to reuse the TCG PSCI code for HVF. This however means that we > need to ensure that CPU register state is synchronized properly between the > two worlds. > > So let's make sure that at least on the PSCI on call, the secondary

Re: [PATCH v2 2/6] accel: accel_available() function

On 11/26/20 3:25 PM, Paolo Bonzini wrote: > On 26/11/20 15:13, Claudio Fontana wrote: >> One option I see is simply to document the behavior where >> accel_available() is declared in accel.h (ie do not use in fast >> path), as well as in accel_find() actually, so that both accel_find() >> and

Re: [RFC] ich9:cpuhp: add support for cpu hot-unplug with SMI broadcast enabled

On Thu, 26 Nov 2020 12:17:27 +0100 Laszlo Ersek wrote: > On 11/24/20 13:25, Igor Mammedov wrote: > > If firmware negotiates ICH9_LPC_SMI_F_CPU_HOT_UNPLUG_BIT feature, > > OSPM on CPU eject will set bit #4 in CPU hotplug block for to be > > ejected CPU to mark it for removal by firmware and

Re: [RFC] ich9:cpuhp: add support for cpu hot-unplug with SMI broadcast enabled

On Thu, 26 Nov 2020 02:24:27 -0800 Ankur Arora wrote: > On 2020-11-24 4:25 a.m., Igor Mammedov wrote: > > If firmware negotiates ICH9_LPC_SMI_F_CPU_HOT_UNPLUG_BIT feature, > > OSPM on CPU eject will set bit #4 in CPU hotplug block for to be > > ejected CPU to mark it for removal by firmware and

Re: [RFC] ich9:cpuhp: add support for cpu hot-unplug with SMI broadcast enabled

On Thu, 26 Nov 2020 13:46:32 +0100 Laszlo Ersek wrote: > On 11/26/20 11:24, Ankur Arora wrote: > > On 2020-11-24 4:25 a.m., Igor Mammedov wrote: > >> If firmware negotiates ICH9_LPC_SMI_F_CPU_HOT_UNPLUG_BIT feature, > >> OSPM on CPU eject will set bit #4 in CPU hotplug block for to be > >>

Re: [DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set.

On Thu, 26 Nov 2020 12:05:27 -0500 "Michael S. Tsirkin" wrote: > On Thu, Nov 26, 2020 at 05:34:50PM +0100, Antoine Damhet wrote: > > On Thu, Nov 26, 2020 at 08:29:41AM -0500, Michael S. Tsirkin wrote: > > > On Thu, Nov 26, 2020 at 01:50:12PM +0100, Antoine Damhet wrote: > > > > On Thu, Nov

[PATCH v2] hw/block/nvme: add compare command

From: Gollu Appalanaidu Add the Compare command. This implementation uses a bounce buffer to read in the data from storage and then compare with the host supplied buffer. Signed-off-by: Gollu Appalanaidu [k.jensen: rebased] Signed-off-by: Klaus Jensen --- Notes: v2: save status in

Re: [PATCH 26/36] remove preconfig state

On Mon, 23 Nov 2020 09:14:25 -0500 Paolo Bonzini wrote: > The preconfig state is only used if -incoming is not specified, which > makes the RunState state machine more tricky than it need be. However > there is already an equivalent condition which works even with -incoming, > namely

Re: [PATCH] virtfs-proxy-helper: Fix a resource leak in main()

On Donnerstag, 26. November 2020 19:27:19 CET Greg Kurz wrote: > On Thu, 26 Nov 2020 18:52:39 +0100 > > Christian Schoenebeck wrote: > > On Donnerstag, 26. November 2020 14:15:51 CET Alex Chen wrote: > > > Hi Greg, > > > > > > Thanks for your review. > > > > > > On 2020/11/26 20:07, Greg Kurz

Re: [PATCH] virtfs-proxy-helper: Fix a resource leak in main()

On Thu, 26 Nov 2020 18:52:39 +0100 Christian Schoenebeck wrote: > On Donnerstag, 26. November 2020 14:15:51 CET Alex Chen wrote: > > Hi Greg, > > > > Thanks for your review. > > > > On 2020/11/26 20:07, Greg Kurz wrote: > > > On Thu, 26 Nov 2020 10:16:24 + > > > > > > Alex Chen wrote: >

  1   2   3   >