Re: [PATCH v13 03/10] virtio-iommu: Implement attach/detach command

Hi Peter, On 2/3/20 4:19 PM, Peter Xu wrote: > On Mon, Feb 03, 2020 at 03:59:00PM +0100, Auger Eric wrote: > > [...] > +static void virtio_iommu_detach_endpoint_from_domain(VirtIOIOMMUEndpoint *ep) +{ +QLIST_REMOVE(ep, next); +g_tree_unref(ep->domain->mappings);

Re: [PATCH v6 00/41] target/arm: Implement ARMv8.1-VHE

Richard Henderson writes: > Version 6 moves vhe_reginfo[] to file scope, and one tweak > to the vhe register access masking that Peter asked for. > > All patches now have reviews. I was re-testing and I was able to boot my guest Image+buildroot. However the busybox crashes after login so I'm u

[PATCH 2/3] m25p80: Improve command handling for Jedec and unsupported commands

Always report 6 bytes of JEDEC data. Fill remaining data with 0. For unsupported commands, keep sending a value of 0 until the chip is deselected. Both changes avoid attempts to decode random commands. Up to now this happened if the reported Jedec data was shorter than 6 bytes but the host read 6

Re: [PATCH 1/2] configure: Allow user to specify sphinx-build binary

Peter Maydell writes: > Currently we insist on using 'sphinx-build' from the $PATH; > allow the user to specify the binary to use. This will be > more useful as we become pickier about the capabilities > we require (eg needing a Python 3 sphinx-build). > > Signed-off-by: Peter Maydell Reviewe

[PATCH 1/3] m25p80: Convert to support tracing

While at it, add some trace messages to help debug problems seen when running the latest Linux kernel. Signed-off-by: Guenter Roeck --- hw/block/m25p80.c | 48 --- hw/block/trace-events | 16 +++ 2 files changed, 38 insertions(+), 26 deleti

Re: [PATCH 2/2] configure: Check that sphinx-build is using Python 3

Peter Maydell writes: > Currently configure's has_sphinx_build() check simply runs a dummy > sphinx-build and either passes or fails. This means that "no > sphinx-build at all" and "sphinx-build exists but is too old" are > both reported the same way. > > Further, we want to assume that all th

Re: [PATCH v2 2/2] bcm2835_dma: Re-initialize xlen in TD mode

Philippe, of course you are right. I understand, what you mean. I'm a non-native English speaker and I'm still learning. :) Yes, I agree. Peter, please make the change, if you agree with the patch. Thanks, Rene On Monday, 3 February 2020, 17:27:08 CET, Philippe Mathieu-Daudé wrote: > On 2/3/

[PATCH 3/3] aspeed/smc: Fix number of dummy cycles for FAST_READ_4 command

The Linux kernel recently started using FAST_READ_4 commands. This results in flash read failures. At the same time, the m25p80 emulation is seen to read 8 more bytes than expected. Adjusting the expected number of dummy cycles to match FAST_READ fixes the problem. Signed-off-by: Guenter Roeck --

Re: [PATCH v13 03/10] virtio-iommu: Implement attach/detach command

On Mon, Feb 03, 2020 at 06:46:36PM +0100, Auger Eric wrote: > Hi Peter, > > On 2/3/20 4:19 PM, Peter Xu wrote: > > On Mon, Feb 03, 2020 at 03:59:00PM +0100, Auger Eric wrote: > > > > [...] > > > +static void > virtio_iommu_detach_endpoint_from_domain(VirtIOIOMMUEndpoint *ep) > +{

Re: [PATCH v2 1/2] qemu-img: Add --target-is-zero to convert

24.01.2020 13:34, David Edmondson wrote: In many cases the target of a convert operation is a newly provisioned target that the user knows is blank (filled with zeroes). In this situation there is no requirement for qemu-img to wastefully zero out the entire device. Add a new option, --target-is

Re: [PATCH v2] block/backup-top: fix flags handling

03.02.2020 18:42, Eric Blake wrote: On 2/3/20 7:42 AM, Vladimir Sementsov-Ogievskiy wrote: backup-top "supports" write-unchanged, by skipping CBW operation in backup_top_co_pwritev. But it forgets to do the same in backup_top_co_pwrite_zeroes, as well as declare support for BDRV_REQ_WRITE_UNCHAN

Re: [PATCH v3 01/18] hw/i386: Rename X86CPUTopoInfo structure to X86CPUTopoIDs

On 2/3/20 9:08 AM, Igor Mammedov wrote: > On Tue, 03 Dec 2019 18:37:01 -0600 > Babu Moger wrote: > >> Rename few data structures related to X86 topology. X86CPUTopoIDs will >> have individual arch ids. Next patch introduces X86CPUTopoInfo which will >> have all topology information(like cores

[PATCH v1 00/13] Ram blocks with resizable anonymous allocations under POSIX

We already allow resizable ram blocks for anonymous memory, however, they are not actually resized. All memory is mmaped() R/W, including the memory exceeding the used_length, up to the max_length. When resizing, effectively only the boundary is moved. Implement actually resizable anonymous alloca

[PATCH v1 03/13] exec: Reuse qemu_ram_apply_settings() in qemu_ram_remap()

I don't see why we shouldn't apply all settings to make it look like the surrounding RAM (and enable proper VMA merging). Note: memory backend settings might have overridden these settings. We would need a callback to let the memory backend fix that up. Cc: Richard Henderson Cc: Paolo Bonzini S

[PATCH v1 01/13] util: vfio-helpers: Factor out and fix processing of existings ram blocks

Factor it out into common code when a new notifier is registered, just as done with the memory region notifier. This allows us to have the logic about how to process existing ram blocks at a central place (which will be extended soon). Just like when adding a new ram block, we have to register the

[PATCH v1 07/13] util/mmap-alloc: Factor out populating of memory to mmap_populate()

We want to populate memory within a reserved memory region. Let's factor that out. Cc: "Michael S. Tsirkin" Cc: Greg Kurz Cc: Murilo Opsfelder Araujo Cc: Eduardo Habkost Cc: "Dr. David Alan Gilbert" Signed-off-by: David Hildenbrand --- util/mmap-alloc.c | 89 +---

[PATCH v1 09/13] util/mmap-alloc: Implement resizable mmaps

Implement resizable mmaps. For now, the actual resizing is not wired up. Introduce qemu_ram_mmap_resizable() and qemu_ram_mmap_resize(). Make qemu_ram_mmap() a wrapper of qemu_ram_mmap_resizable(). Cc: "Michael S. Tsirkin" Cc: Greg Kurz Cc: Murilo Opsfelder Araujo Cc: Eduardo Habkost Cc: "Dr.

[PATCH v1 08/13] util/mmap-alloc: Prepare for resizable mmaps

When shrinking a mmap we want to re-reserve the already populated area. When growing a memory region, we want to populate starting with a given fd_offset. Prepare by allowing to pass these parameters. Also, let's make sure we always process full pages, to avoid unmapping/remapping pages that are a

[PATCH v1 02/13] exec: Factor out setting ram settings (madvise ...) into qemu_ram_apply_settings()

Factor all settings out into qemu_ram_apply_settings(). For memory_try_enable_merging(), the important bit is that it won't be called with XEN - which is now still the case as new_block->host will remain NULL. Cc: Richard Henderson Cc: Paolo Bonzini Signed-off-by: David Hildenbrand --- exec.c

[PATCH v1 10/13] numa: Introduce ram_block_notify_resized() and ram_block_notifiers_support_resize()

We want to actually resize ram blocks (make everything between used_length and max_length inaccessible) - however, not all ram block notifiers will support that. So introduce a way to detect if any registered notifier does not support it and add a way to notify all notifiers that support it. Usin

[PATCH v1 05/13] util/mmap-alloc: Factor out calculation of pagesize to mmap_pagesize()

Factor it out and add a comment. Cc: "Michael S. Tsirkin" Cc: Murilo Opsfelder Araujo Cc: Greg Kurz Cc: Eduardo Habkost Cc: "Dr. David Alan Gilbert" Signed-off-by: David Hildenbrand --- util/mmap-alloc.c | 21 - 1 file changed, 12 insertions(+), 9 deletions(-) diff --gi

[PATCH v1 06/13] util/mmap-alloc: Factor out reserving of a memory region to mmap_reserve()

We want to reserve a memory region without actually populating memory. Let's factor that out. Cc: "Michael S. Tsirkin" Cc: Greg Kurz Cc: Murilo Opsfelder Araujo Cc: Eduardo Habkost Cc: "Dr. David Alan Gilbert" Signed-off-by: David Hildenbrand --- util/mmap-alloc.c | 58 +

[PATCH v1 04/13] exec: Drop "shared" parameter from ram_block_add()

Properly store it in the flags of the ram block instead (and the flag even already exists and is used). E.g., qemu_ram_is_shared() now properly succeeds on all ram blocks that are actually shared. Cc: Richard Henderson Cc: Paolo Bonzini Signed-off-by: David Hildenbrand --- exec.c | 12 +++

[PATCH v1 11/13] util: vfio-helpers: Implement ram_block_resized()

Let's implement ram_block_resized(). Note: Resizing is currently only allowed during reboot or when migration starts. Cc: "Dr. David Alan Gilbert" Cc: Paolo Bonzini Cc: Markus Armbruster Cc: Alex Williamson Signed-off-by: David Hildenbrand --- util/vfio-helpers.c | 13 + 1 file

[PATCH v1 13/13] exec: Ram blocks with resizable anonymous allocations under POSIX

We can now make use of resizable anonymous allocations to implement actually resizable ram blocks. Resizable anonymous allocations are not implemented under WIN32 yet and are not available when using alternative allocators. Fall back to the existing handling. We also have to fallback to the existi

[PATCH v1 12/13] util: oslib: Resizable anonymous allocations under POSIX

Introduce qemu_anon_ram_alloc_resizable() and qemu_anon_ram_resize(). Implement them under POSIX and make them return NULL under WIN32. Under POSIX, we make use of resizable mmaps. An implementation under WIN32 is theoretically possible AFAIK and can be added later. In qemu_anon_ram_free(), renam

Re: [PATCH 1/6] hw/arm/raspi: Use BCM2708 machine type with pre Device Tree kernels

On Mon, Feb 3, 2020 at 12:28 AM Philippe Mathieu-Daudé wrote: > > When booting without device tree, the Linux kernels uses the $R1 > register to determine the machine type. The list of values is > registered at [1]. > > There are two entries for the Raspberry Pi: > > - https://www.arm.linux.org.uk

Re: [PATCH 1/3] m25p80: Convert to support tracing

On Mon, Feb 3, 2020 at 10:10 AM Guenter Roeck wrote: > > While at it, add some trace messages to help debug problems > seen when running the latest Linux kernel. > > Signed-off-by: Guenter Roeck Reviewed-by: Alistair Francis Alistair > --- > hw/block/m25p80.c | 48 ---

Re: [PATCH v2 1/2] qemu-img: Add --target-is-zero to convert

On 2/3/20 12:20 PM, Vladimir Sementsov-Ogievskiy wrote: 24.01.2020 13:34, David Edmondson wrote: In many cases the target of a convert operation is a newly provisioned target that the user knows is blank (filled with zeroes). In this situation there is no requirement for qemu-img to wastefully z

Re: [PATCH v3 02/17] tests/docker: better handle symlinked libs

On Mon, 3 Feb 2020 at 04:09, Alex Bennée wrote: > Subject: [PATCH v3 02/17] tests/docker: better handle symlinked libs > > When we are copying we want to ensure we grab the first > resolution (the found in path section). However even that binary might > be a symlink so lets make sure we chase the

Re: [PATCH v2 03/29] python/qemu: Add binutils::binary_get_version()

On 1/29/20 7:23 PM, Philippe Mathieu-Daudé wrote: Add a helper to query the version of a QEMU binary. We simply send the 'query-version' command over a QMP socket. Introduce the PythonQemuCoreScripts class to test our new helper. Signed-off-by: Philippe Mathieu-Daudé --- python/qemu/binutil

Re: [PATCH v3 00/18] APIC ID fixes for AMD EPYC CPU models

On 2/3/20 8:59 AM, Igor Mammedov wrote: > On Tue, 03 Dec 2019 18:36:54 -0600 > Babu Moger wrote: > >> This series fixes APIC ID encoding problems on AMD EPYC CPUs. >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D1728166&data=02%7C0

Re: [PATCH v4 00/11] RFC: [for 5.0]: HMP monitor handlers refactoring

* Maxim Levitsky (mlevi...@redhat.com) wrote: > This patch series is bunch of cleanups to the hmp monitor code. > It mostly moves the blockdev related hmp handlers to its own file, > and does some minor refactoring. > > No functional changes expected. You've still got the title marked as RFC - ar

Re: [PATCH] ui/cocoa: Drop workarounds for pre-10.12 OSX

> Date: Sat, 1 Feb 2020 17:05:34 + > From: Peter Maydell > To: qemu-devel@nongnu.org > Cc: Gerd Hoffmann > Subject: [PATCH] ui/cocoa: Drop workarounds for pre-10.12 OSX > Message-ID: <20200201170534.22123-1-peter.mayd...@linaro.org> > > Our official OSX support policy covers the last two rel

Re: Making QEMU easier for management tools and applications

On Fri, 2020-01-31 at 07:50 +0100, Markus Armbruster wrote: > Kevin Wolf writes: > > Much of this threads plays with the though that maybe we don't need any > > compatibility and make the radical conclusion that we don't need any > > human-friendly interface at all. Keeping full compatibility is t

Re: [RFC PATCH] audio: proper support for float samples in mixeng

On 2020-02-03 11:00, Peter Maydell wrote: On Sun, 2 Feb 2020 at 19:39, Kővágó, Zoltán wrote: This adds proper support for float samples in mixeng by adding a new audio format for it. Limitations: only native endianness is supported. Could you explain a bit more what this limitation means, p

Re: [PATCH qemu] spapr/rtas: Print message from "ibm,os-term"

On 2/3/20 12:20 AM, Alexey Kardashevskiy wrote: The "ibm,os-term" RTAS call has a single parameter which is a pointer to a message from the guest kernel about the termination cause; this prints it. Signed-off-by: Alexey Kardashevskiy --- hw/ppc/spapr_rtas.c | 7 +++ 1 file changed, 7

[PATCH 0/1] Introduce Xlnx ZynqMP CAN controller for QEMU

Example for single CAN: -object can-bus,id=canbus0 \ -global driver=xlnx.zynqmp-can,property=canbus0,value=canbus0 \ -object can-host-socketcan,id=socketcan0,if=vcan0,canbus=canbus0 Example for connecting both CAN: -object can-bus,id=canbus0 -object can-bus,id=canbus1 \ -global

[PATCH 1/1] hw/net/can: Introduce Xlnx ZynqMP CAN controller for QEMU

XlnxCAN is developed based on SocketCAN, QEMU CAN bus implementation. Bus connection and socketCAN connection for each CAN module can be set through command lines. Signed-off-by: Vikram Garhwal --- hw/net/can/Makefile.objs |1 + hw/net/can/xlnx-zynqmp-can.c | 1106 +++

Re: Need help understanding assertion fail.

I see. So you're saying that it might be possible that my guest could be generating TCG ops that can't be translated into PPC instructions because the displacement value is to big. While the same TCG ops can be translated into x86 instructions because x86 allows for a bigger displacement value. B

Re: [PATCH v3 07/18] machine: Add a new function init_apicid_fn in MachineClass

On 2/3/20 9:17 AM, Igor Mammedov wrote: > On Wed, 29 Jan 2020 10:17:11 -0600 > Babu Moger wrote: > >> On 1/29/20 3:14 AM, Igor Mammedov wrote: >>> On Tue, 28 Jan 2020 13:45:31 -0600 >>> Babu Moger wrote: >>> On 1/28/20 10:29 AM, Igor Mammedov wrote: > On Tue, 03 Dec 2019 18:37:4

Disabling PCI "hot-unplug" for a guest (and/or a single PCI device)

Although I've never experienced it, due to not running Windows guests, I've recently learned that a Windows guest permits a user (hopefully only one with local admin privileges??!) to "hot-unplug" any PCI device. I've also learned that some hypervisor admins don't want to permit admins of the v

Re: VW ELF loader

On 04/02/2020 02:08, Paolo Bonzini wrote: > On 03/02/20 11:58, Alexey Kardashevskiy wrote: So really, the question isn't whether we implement things in firmware or in qemu. It's whether we implement the firmware functionality as guest cpu code, which needs to be coded to work wit

[PATCH 2/3] spapr: Detect hot unplugged devices during CAS

We can't properly handle hotplug of a device as long the guest kernel isn't fully booted. We detect this at CAS and potentially trigger a CAS reboot to complete the hotplug sequence. The same goes actually with hot unplug but we currently don't detect it. Doing device_del before CAS hence seems to

[PATCH 0/3] spapr: Fix device unplug vs CAS or migration

While working on getting rid of CAS reboot, I realized that we currently don't handle device hot unplug properly in the following situations: 1) if the device is unplugged between boot and CAS, SLOF doesn't handle the even, which is a known limitation. The device hence stays around forever (

[PATCH 3/3] spapr: Migrate SpaprDrc::unplug_requested

Hot unplugging a device is an asynchronous operation. If the guest is migrated after the event was sent but before it could release the device with RTAS, the destination QEMU doesn't know about the pending unplug operation and doesn't actually remove the device when the guest finally releases it. T

[PATCH 1/3] spapr: Don't use spapr_drc_needed() in CAS code

We currently don't support hotplug of devices between boot and CAS. If this happens a CAS reboot is triggered. We detect this during CAS using the spapr_drc_needed() function which is essentially a VMStateDescription .needed callback. Even if the condition for CAS reboot happens to be the same as f

RE: [PATCH 0/4] linux-user: fix use of SIGRTMIN

FWIW, this removes the need for the target-specific code for Hexagon in signal.c. Thanks, Taylor PS Stay tuned for a Hexagon target patch series once this is merged. > -Original Message- > From: Laurent Vivier > Sent: Saturday, February 1, 2020 6:28 AM > To: qemu-devel@nongnu.org > Cc

Re: VW ELF loader

Il lun 3 feb 2020, 23:36 Alexey Kardashevskiy ha scritto: > > > What partition formats would have to be supported? > > MBR, GPT, is there anything else? "Support" is limited to converting a > number after command to [start, size] couple. I am not going for file > systems. > > > But honestly I'm >

RE: [PATCH 2/4] linux-user: cleanup signal.c

> -Original Message- > From: Laurent Vivier > Sent: Saturday, February 1, 2020 6:28 AM > To: qemu-devel@nongnu.org > Cc: Josh Kunz ; milos.stojano...@rt-rk.com; Matus Kysel > ; Aleksandar Markovic rk.com>; Marlies Ruck ; Laurent Vivier > ; Peter Maydell ; Taylor > Simpson ; Riku Voipio

RE: [PATCH 3/4] linux-user: fix TARGET_NSIG and _NSIG uses

> -Original Message- > From: Laurent Vivier > Sent: Saturday, February 1, 2020 6:28 AM > To: qemu-devel@nongnu.org > Cc: Josh Kunz ; milos.stojano...@rt-rk.com; Matus Kysel > ; Aleksandar Markovic rk.com>; Marlies Ruck ; Laurent Vivier > ; Peter Maydell ; Taylor > Simpson ; Riku Voipio

RE: [PATCH 4/4] linux-user: fix use of SIGRTMIN

> -Original Message- > From: Laurent Vivier > Sent: Saturday, February 1, 2020 6:28 AM > To: qemu-devel@nongnu.org > Cc: Josh Kunz ; milos.stojano...@rt-rk.com; Matus Kysel > ; Aleksandar Markovic rk.com>; Marlies Ruck ; Laurent Vivier > ; Peter Maydell ; Taylor > Simpson ; Riku Voipio

Re: VW ELF loader

On 04/02/2020 09:56, Paolo Bonzini wrote: > > > Il lun 3 feb 2020, 23:36 Alexey Kardashevskiy > ha scritto: > > > > What partition formats would have to be supported? > > MBR, GPT, is there anything else? "Support" is limited to converting a > number afte

Re: VW ELF loader

Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy ha scritto: > > > Speaking seriously, what would I put into the guest? > Only things that would be considered drivers. Ignore the partitions issue for now so that you can just pass the device tree services to QEMU with hypercalls. Netboot's dhcp/tft

Re: [PATCH] configure: Fix typo of the have_afalg variable

在 2020/2/4 0:00, Thomas Huth 写道: > The variable is called 'have_afalg' and not 'hava_afalg'. > > Fixes: f0d92b56d88 ('introduce some common functions for af_alg backend') > Signed-off-by: Thomas Huth > --- > configure | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/conf

Re: [PATCH 0/4] linux-user: fix use of SIGRTMIN

On Sat, Feb 1, 2020 at 4:27 AM Laurent Vivier wrote: > This has been tested with Go (golang 1.10.1 linux/arm64, bionic) on x86_64 > fedora 31. We can avoid the failure in this case allowing the unsupported > signals when we don't provide the "act" parameters to sigaction, only the > "oldact" one.

Re: [PATCH] pl031: add finalize function to avoid memleaks

On 2/3/2020 5:58 PM, Peter Maydell wrote: > On Mon, 3 Feb 2020 at 07:47, wrote: >> >> From: Pan Nengyuan >> >> There is a memory leak when we call 'device_list_properties' with >> typename = pl031. It's easy to reproduce as follow: >> >> virsh qemu-monitor-command vm1 --pretty '{"execute":

Re: [PATCH v2 0/7] Some cleanup in arm/virt/acpi

在 2020/2/3 22:03, Peter Maydell 写道: On Mon, 3 Feb 2020 at 13:33, Heyi Guo wrote: 在 2020/2/3 14:43, Michael S. Tsirkin 写道: On Mon, Feb 03, 2020 at 08:14:58AM +0800, Heyi Guo wrote: Remove conflict _ADR objects, and fix and refine PCI device definition in ACPI/DSDT. Cc: Peter Maydell Cc: "

[PATCH v3 0/7] Some cleanup in arm/virt/acpi

Remove conflict _ADR objects, and fix and refine PCI device definition in ACPI/DSDT. History: v3 -> v2: - update commit message for patch 4/7. - remove diff keywords in commit message of patch 7/7 to avoid applying patch failure. v1 -> v2: - flow the work flow in tests/qtest/bios-table-test.c

[PATCH v3 5/7] arm/acpi: fix duplicated _UID of PCI interrupt link devices

Using _UID of 0 for all PCI interrupt link devices absolutely violates the spec. Simply increase one by one. Signed-off-by: Heyi Guo Reviewed-by: Michael S. Tsirkin --- Cc: Peter Maydell Cc: "Michael S. Tsirkin" Cc: Igor Mammedov Cc: Shannon Zhao Cc: qemu-...@nongnu.org Cc: qemu-devel@nongn

[PATCH v3 7/7] virt/acpi: update golden masters for DSDT update

Differences between disassembled ASL files: @@ -5,13 +5,13 @@ * * Disassembling to symbolic ASL+ operators * - * Disassembly of DSDT, Thu Jan 23 16:00:04 2020 + * Disassembly of DSDT.new, Thu Jan 23 16:47:12 2020 * * Original Table Header: * Signature"DSDT" - * Length

[PATCH v3 6/7] arm/acpi: simplify the description of PCI _CRS

The original code defines a named object for the resource template but then returns the resource template object itself; the resulted output is like below: Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (RBUF, ResourceTemplate () { WordBusNumber (Resourc

[PATCH v3 4/7] arm/acpi: fix PCI _PRT definition

The address field in each _PRT mapping package should be constructed with high word for device# and low word for function#, so it is wrong to use bus_no as the high word. The existing code adds a bunch useless entries with device #s above 31. Enumerate all possible slots (i.e. PCI_SLOT_MAX) instead

[PATCH v3 3/7] arm/virt/acpi: remove _ADR from devices identified by _HID

According to ACPI spec, _ADR should be used for device on a bus that has a standard enumeration algorithm, but not for device which is on system bus and must be enumerated by OSPM. And it is not recommended to contain both _HID and _ADR in a single device. See ACPI 6.3, section 6.1, top of page 34

[PATCH v3 2/7] arm/virt/acpi: remove meaningless sub device "RP0" from PCI0

The sub device "RP0" under PCI0 in ACPI/DSDT does not contain any method or property other than "_ADR", so it is safe to remove it. Signed-off-by: Heyi Guo Acked-by: "Michael S. Tsirkin" --- Cc: Peter Maydell Cc: "Michael S. Tsirkin" Cc: Igor Mammedov Cc: Shannon Zhao Cc: qemu-...@nongnu.or

[PATCH v3 1/7] bios-tables-test: prepare to change ARM virt ACPI DSDT

We are going to change ARM virt ACPI DSDT table, which will cause make check to fail, so temporarily add related golden masters to ignore list. Signed-off-by: Heyi Guo Reviewed-by: Michael S. Tsirkin --- Cc: Peter Maydell Cc: "Michael S. Tsirkin" Cc: Igor Mammedov Cc: Shannon Zhao Cc: qemu-

[PATCH v2] pl031: add finalize function to avoid memleaks

From: Pan Nengyuan There is a memory leak when we call 'device_list_properties' with typename = pl031. It's easy to reproduce as follow: virsh qemu-monitor-command vm1 --pretty '{"execute": "device-list-properties", "arguments": {"typename": "pl031"}}' The memory leak stack: Direct leak of

[PATCH v3 1/4] linux-user: Use `qemu_log' for non-strace logging

Since most calls to `gemu_log` are actually logging unimplemented features, this change replaces most non-strace calls to `gemu_log` with calls to `qemu_log_mask(LOG_UNIMP, ...)`. This allows the user to easily log to a file, and to mask out these log messages if they desire. Note: This change is

[PATCH v3 0/4] migration: Replace gemu_log with qemu_log

Summary of v2->v3 changes: * Removed assert for CMSG handling, replaced with LOG_UNIMP. Will switch to assert in follow-up patch. * Fixed BSD-user build (dangling references to qemu_add_log), and verified the user-mode build works. Summary of v1->v2 changes: * Removed backwards-compa

[PATCH v3 2/4] linux-user: Use `qemu_log' for strace

This change switches linux-user strace logging to use the newer `qemu_log` logging subsystem rather than the older `gemu_log` (notice the "g") logger. `qemu_log` has several advantages, namely that it allows logging to a file, and provides a more unified interface for configuration of logging (via

Re: [PATCH v2 2/4] linux-user: Use `qemu_log' for strace

On Tue, Jan 28, 2020 at 7:07 AM Laurent Vivier wrote: > > Le 17/01/2020 à 20:28, Josh Kunz a écrit : > > This change switches linux-user strace logging to use the newer `qemu_log` > > logging subsystem rather than the older `gemu_log` (notice the "g") > > logger. `qemu_log` has several advantages,

[PATCH v3 4/4] bsd-user: Replace gemu_log with qemu_log

gemu_log is an old logging mechanism used to implement strace logging in the bsd-user tree. It logs directly to stderr and cannot easily be redirected. This change instead causes strace to log via the qemu_log subsystem which has fine-grained logging control, and a centralized mechanism for log red

[PATCH v3 3/4] linux-user: remove gemu_log from the linux-user tree

Now that all uses have been migrated to `qemu_log' it is no longer needed. Reviewed-by: Laurent Vivier Signed-off-by: Josh Kunz --- linux-user/main.c | 9 - linux-user/qemu.h | 1 - 2 files changed, 10 deletions(-) diff --git a/linux-user/main.c b/linux-user/main.c index 8f1d07cdd6..22

Re: [PATCH v2 1/4] linux-user: Use `qemu_log' for non-strace logging

I've switched it to a LOG_UNIMP, similar to to the one several lines below. I will follow up with a change to switch this to an assert as recommended. On Tue, Jan 28, 2020 at 9:07 AM Laurent Vivier wrote: > > Le 28/01/2020 à 17:53, Alex Bennée a écrit : > > > > Laurent Vivier writes: > > > >> L

Re: [PATCH 0/4] migration: Replace gemu_log with qemu_log

On Mon, Jan 20, 2020 at 3:36 AM Alex Bennée wrote: > Ahh the default build target for the BSDs is "check" but as bsd-user > doesn't have any checks it doesn't end up building. You can force it > with > > make vm-build-netbsd EXTRA_CONFIGURE_OPTS="--disable-system" > BUILD_TARGET="all" > > It wo

Re: [RFC PATCH] hw/arm/virt: Support NMI injection

On 1/31/20 8:39 PM, Marc Zyngier wrote: On 2020-01-31 06:59, Gavin Shan wrote: On 1/29/20 8:04 PM, Marc Zyngier wrote: On 2020-01-29 02:44, Alexey Kardashevskiy wrote: On 28/01/2020 17:48, Gavin Shan wrote: but a NMI is injected through LAPIC on x86. So I'm not sure what architect (system res

Re: [PATCH v4 00/14] Fixes for DP8393X SONIC device emulation

On 2020/1/29 下午5:27, Finn Thain wrote: Hi All, There are bugs in the emulated dp8393x device that can stop packet reception in a Linux/m68k guest (q800 machine). With a Linux/m68k v5.5 guest (q800), it's possible to remotely trigger an Oops by sending ping floods. With a Linux/mips guest (ma

Re: [PATCH] e1000e: Avoid hw_error if legacy mode used

On 2020/1/28 上午12:03, Yuri Benditovich wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1787142 The emulation issues hw_error if PSRCTL register is written, for example, with zero value. Such configuration does not present any problem when DTYP bits of RCTL register define legacy format of tr

Re: [PATCH v5 3/4] spapr: Add NVDIMM device support

On Thu, Jan 30, 2020 at 05:48:15AM -0600, Shivaprasad G Bhat wrote: > Add support for NVDIMM devices for sPAPR. Piggyback on existing nvdimm > device interface in QEMU to support virtual NVDIMM devices for Power. > Create the required DT entries for the device (some entries have > dummy values righ

Re: [PATCH v5 4/4] spapr: Add Hcalls to support PAPR NVDIMM device

On Thu, Jan 30, 2020 at 05:48:28AM -0600, Shivaprasad G Bhat wrote: > This patch implements few of the necessary hcalls for the nvdimm support. > > PAPR semantics is such that each NVDIMM device is comprising of multiple > SCM(Storage Class Memory) blocks. The guest requests the hypervisor to > bi

[PATCH] migration: Optimization about wait-unplug migration state

qemu_savevm_nr_failover_devices() is originally designed to get the number of failover devices, but it actually returns the number of "unplug-pending" failover devices now. Moreover, what drives migration state to wait-unplug should be the number of "unplug-pending" failover devices, not all failov

Re: VW ELF loader

On 04/02/2020 00.26, Paolo Bonzini wrote: > > > Il mar 4 feb 2020, 00:20 Alexey Kardashevskiy > ha scritto: > > Speaking seriously, what would I put into the guest? > > Only things that would be considered drivers. Ignore the partitions > issue for now so that you ca

Re: [PATCH v3 2/7] arm/virt/acpi: remove meaningless sub device "RP0" from PCI0

On Tue, Feb 04, 2020 at 09:43:20AM +0800, Heyi Guo wrote: > The sub device "RP0" under PCI0 in ACPI/DSDT does not contain any > method or property other than "_ADR", so it is safe to remove it. > > Signed-off-by: Heyi Guo > Acked-by: "Michael S. Tsirkin" Reviewed-by: Michael S. Tsirkin > ---

Re: [PATCH v3 3/7] arm/virt/acpi: remove _ADR from devices identified by _HID

On Tue, Feb 04, 2020 at 09:43:21AM +0800, Heyi Guo wrote: > According to ACPI spec, _ADR should be used for device on a bus that > has a standard enumeration algorithm, but not for device which is on > system bus and must be enumerated by OSPM. And it is not recommended > to contain both _HID and _

[PULL 1/3] target/mips: Fix ll/sc after 7dd547e5ab6b31e7a0cfc182d3ad131dd55a948f

From: Alex Richardson After 7dd547e5ab6b31e7a0cfc182d3ad131dd55a948f the env->llval value is loaded as an unsigned value (instead of sign-extended as before). Therefore, the CMPXCHG in gen_st_cond() in translate.c fails if the sign bit is set in the loaded value. Fix this by sign-extending the ll

[PULL 0/3] MIPS queue for February 4th, 2020

From: Aleksandar Markovic The following changes since commit f31160c7d1b89cfb4dd4001a23575b42141cb0ec: Merge remote-tracking branch 'remotes/pmaydell/tags/pull-docs-20200203' into staging (2020-02-03 11:14:24 +) are available in the git repository at: https://github.com

[PULL 2/3] target/mips: Separate CP0-related helpers into their own file

From: Aleksandar Markovic For clarity and easier maintenence, create target/mips/cp0_helper.c, and move all CP0-related content form target/mips/op_helper.c to that file. Signed-off-by: Aleksandar Markovic Reviewed-by: Aleksandar Rikalo Message-Id: <1580745443-24650-2-git-send-email-aleksandar

Re: [RFC PATCH] audio: proper support for float samples in mixeng

Eric Blake writes: > On 2/3/20 12:21 AM, Markus Armbruster wrote: >> "Kővágó, Zoltán" writes: >> >>> This adds proper support for float samples in mixeng by adding a new >>> audio format for it. >>> >>> Limitations: only native endianness is supported. >>> >>> Signed-off-by: Kővágó, Zoltán >>>

Re: [PULL 0/3] MIPS queue for February 4th, 2020

Patchew URL: https://patchew.org/QEMU/1580798552-703-1-git-send-email-aleksandar.marko...@rt-rk.com/ Hi, This series seems to have some coding style problems. See output below for more information: Subject: [PULL 0/3] MIPS queue for February 4th, 2020 Message-id: 1580798552-703-1-git-send-ema

Re: [PATCH 1/3] m25p80: Convert to support tracing

On 2/3/20 7:09 PM, Guenter Roeck wrote: > While at it, add some trace messages to help debug problems > seen when running the latest Linux kernel. > > Signed-off-by: Guenter Roeck Reviewed-by: Cédric Le Goater We have been chasing a bug for years on the witherspoon-bmc machine using UBIfs. I

Re: [PATCH v2] pl031: add finalize function to avoid memleaks

On 2/4/20 3:05 AM, pannengy...@huawei.com wrote: From: Pan Nengyuan There is a memory leak when we call 'device_list_properties' with typename = pl031. It's easy to reproduce as follow: virsh qemu-monitor-command vm1 --pretty '{"execute": "device-list-properties", "arguments": {"typename":

Re: [PULL 3/3] target/mips: Separate FPU-related helpers into their own file

On 2/4/20 7:42 AM, Aleksandar Markovic wrote: From: Aleksandar Markovic For clarity and easier maintenence, create target/mips/fpu_helper.c, and move all FPU-related content form target/mips/op_helper.c to that file. Signed-off-by: Aleksandar Markovic Reviewed-by: Aleksandar Rikalo Message-I

Re: [PATCH v3 07/18] machine: Add a new function init_apicid_fn in MachineClass

On Mon, 3 Feb 2020 15:49:31 -0600 Babu Moger wrote: > On 2/3/20 9:17 AM, Igor Mammedov wrote: > > On Wed, 29 Jan 2020 10:17:11 -0600 > > Babu Moger wrote: > > > >> On 1/29/20 3:14 AM, Igor Mammedov wrote: > >>> On Tue, 28 Jan 2020 13:45:31 -0600 > >>> Babu Moger wrote: > >>> > On

Re: [PATCH 3/3] aspeed/smc: Fix number of dummy cycles for FAST_READ_4 command

On 2/3/20 7:09 PM, Guenter Roeck wrote: > The Linux kernel recently started using FAST_READ_4 commands. > This results in flash read failures. At the same time, the m25p80 > emulation is seen to read 8 more bytes than expected. Adjusting the > expected number of dummy cycles to match FAST_READ fixe

Re: [PATCH] pl031: add finalize function to avoid memleaks

On 2/3/20 7:47 AM, pannengy...@huawei.com wrote: > +static void pl031_finalize(Object *obj) > +{ > +PL031State *s = PL031(obj); > +if (s->timer) { As far as I can see, s->timer can never be null. Otherwise, Reviewed-by: Richard Henderson r~

[PATCH] tests/qemu_iotests: Minimize usage of used ports

Using a range of ports from 32768 to 65538 is dangerous as some application might already be listening there and interfere with the testing. There is no way to reserve ports, but let's decrease the chance of interactions by only using ports that were free at the time of importing this module. With

Re: [PATCH] tests/qtest: update comments about bios-tables-test-allowed-diff.h

On Sun, 2 Feb 2020 19:00:09 +0800 Heyi Guo wrote: > Update comments in tests/qtest/bios-tables-test.c to reflect the > current path of bios-tables-test-allowed-diff.h, which is now under > tests/qtest/ as well. > > Signed-off-by: Heyi Guo Reviewed-by: Igor Mammedov > > --- > > Cc: "Michael

Re: [PATCH] pl031: add finalize function to avoid memleaks

On 2/3/2020 3:59 PM, Richard Henderson wrote: > On 2/3/20 7:47 AM, pannengy...@huawei.com wrote: >> +static void pl031_finalize(Object *obj) >> +{ >> +PL031State *s = PL031(obj); >> +if (s->timer) { > > As far as I can see, s->timer can never be null. Yes, it's no instances, just seems

[Bug 1823790] Re: QEMU mishandling of SO_PEERSEC forces systemd into tight loop

Thanks, Laurent! I'll get back to you, asap. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1823790 Title: QEMU mishandling of SO_PEERSEC forces systemd into tight loop Status in QEMU: Confirmed

[PATCH 0/6] hw/arm/raspi: Dynamically create machines based on the board revision

Hi, These patches simplify adding the raspi0/raspi1/raspi4 boards. I still need some time to figure out what is the best way to organize the SoC code because since these socs use different ARM cores, the interrupt controller are different too. Igor has been working in his "refactor main RAM allo

  1   2   3   4   >