Re: [Qemu-devel] [PATCH for-4.0-maybe] device_tree: Fix integer overflowing in load_device_tree()

On Tue, Apr 9, 2019 at 10:59 PM Markus Armbruster wrote: > > Philippe Mathieu-Daudé writes: > > > On 4/10/19 7:28 AM, Markus Armbruster wrote: > >> Philippe Mathieu-Daudé writes: > >>> On 4/9/19 7:40 PM, Markus Armbruster wrote: > If the value of get_image_size() exceeds INT_MAX / 2 - 1

Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures

On 10.04.19 08:07, Thomas Huth wrote: > That's great, good to know that you're still interested in TCI! ... but > I think one of the main problems is still that we completely lack test > coverage for TCI - the code always is in danger to bit-rot if it is not > tested by default. Ideally it would

Re: [Qemu-devel] [PATCH for-4.0 v2 2/2] roms: Allow the EDK2_EFIROM variable to be overridden

Am Mon, 8 Apr 2019 13:05:07 +0200 schrieb Laszlo Ersek : > Then build scripts could be updated to invoke: > > make -C roms \ > EDK2_BASETOOLS_OPTFLAGS='...' \ > EDK2_BASETOOLS_LDFLAGS='...' \ > efirom The question remains: 'But why?'. Why can edk2 not be built with '-fno-pie' right

Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures

On 09.04.19 22:39, Richard Henderson wrote: > On 4/9/19 9:46 AM, Stefan Weil wrote: >> * Calling conventions. The current implementation works on many hosts, >> but for example not on Sparc. A fix would require simple calling >> conventions for all helper functions (for example stack based argument

Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures

On 09/04/2019 21.46, Stefan Weil wrote: > On 05.04.19 11:16, Philippe Mathieu-Daudé wrote: >> On 4/5/19 11:02 AM, Daniel P. Berrangé wrote: >>> On Fri, Apr 05, 2019 at 10:47:54AM +0200, Philippe Mathieu-Daudé wrote: >>> Do the various crashes that you illustrate in that cover letter >>> still exist

Re: [Qemu-devel] [PATCH for-4.0-maybe] device_tree: Fix integer overflowing in load_device_tree()

Philippe Mathieu-Daudé writes: > On 4/10/19 7:28 AM, Markus Armbruster wrote: >> Philippe Mathieu-Daudé writes: >>> On 4/9/19 7:40 PM, Markus Armbruster wrote: If the value of get_image_size() exceeds INT_MAX / 2 - 1, the computation of @dt_size overflows to a negative number, whic

Re: [Qemu-devel] [PATCH RFC 2/3] pxtool: Add new qemu-img command info generation tool

John Snow writes: > Presently we use hxtool and a .hx format to generate a few things like > the qemu_img subcommand dispatch table, the qemu_img help() display output, > and a help output in qemu-img.texi. > > Unfortunately, this means that this information is duplicated in at least > three plac

Re: [Qemu-devel] [PATCH for-4.0-maybe] device_tree: Fix integer overflowing in load_device_tree()

On 4/10/19 7:28 AM, Markus Armbruster wrote: > Philippe Mathieu-Daudé writes: >> On 4/9/19 7:40 PM, Markus Armbruster wrote: >>> If the value of get_image_size() exceeds INT_MAX / 2 - 1, the >>> computation of @dt_size overflows to a negative number, which then >>> gets converted to a very lar

Re: [Qemu-devel] [PATCH] qemu-img: fix .hx and .texi disparity

John Snow writes: > It turns out that having options listed in three places continues to be > a bad idea. I'm still toying with the idea of an improved infrastructure > here, but in the meantime, another bandaid. > > There are three locations: > (1) .hx file, formatted as texi > (2) .hx file, for

[Qemu-devel] [PATCH] roms: List and describe the Makefile 'clean' rule

Signed-off-by: Philippe Mathieu-Daudé --- roms/Makefile | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/roms/Makefile b/roms/Makefile index 1ff78b63bb3..f55c4a2d3bb 100644 --- a/roms/Makefile +++ b/roms/Makefile @@ -61,6 +61,8 @@ default: @echo " skiboot

Re: [Qemu-devel] [PATCH for-4.0-maybe] device_tree: Fix integer overflowing in load_device_tree()

Peter Maydell writes: > On Tue, 9 Apr 2019 at 21:15, Alistair Francis wrote: >> >> On Tue, Apr 9, 2019 at 1:08 PM Peter Maydell >> wrote: >> > >> > On Wed, 10 Apr 2019 at 00:40, Markus Armbruster wrote: >> > > >> > > If the value of get_image_size() exceeds INT_MAX / 2 - 1, the >> > > com

Re: [Qemu-devel] [PATCH for-4.0-maybe] device_tree: Fix integer overflowing in load_device_tree()

Philippe Mathieu-Daudé writes: > On 4/9/19 7:40 PM, Markus Armbruster wrote: >> If the value of get_image_size() exceeds INT_MAX / 2 - 1, the >> computation of @dt_size overflows to a negative number, which then >> gets converted to a very large size_t for g_malloc0() and >> load_image_size()

Re: [Qemu-devel] [PATCH for-4.0-maybe] device_tree: Fix integer overflowing in load_device_tree()

On 4/9/19 10:08 PM, Peter Maydell wrote: > On Wed, 10 Apr 2019 at 00:40, Markus Armbruster wrote: >> >> If the value of get_image_size() exceeds INT_MAX / 2 - 1, the >> computation of @dt_size overflows to a negative number, which then >> gets converted to a very large size_t for g_malloc0() a

Re: [Qemu-devel] [PATCH for-4.1 v4 07/12] roms: build edk2 firmware binaries and variable store templates

On 4/10/19 1:00 AM, Laszlo Ersek wrote: > Add the "efi" target to "Makefile". > > Introduce "Makefile.edk2" for building and cleaning the firmware images > and varstore templates. > > Collect the common bits from the recipes in the helper script > "edk2-build.sh". > > Signed-off-by: Laszlo Ersek

Re: [Qemu-devel] [PATCH 0/4] Header cleanups

Peter Maydell writes: > On Tue, 9 Apr 2019 at 17:42, Aruna Jayasena wrote: >> >> Yeah this is a stand alone patch. > > OK, thanks -- just wanted to check there wasn't a missing > bit. I think this could go in via the qemu-trivial tree > so I have cc'd them. > > We're in the middle of a release a

Re: [Qemu-devel] [PATCH for-4.1 v4 09/12] pc-bios: document the edk2 firmware images; add firmware descriptors

On 4/10/19 1:00 AM, Laszlo Ersek wrote: > Update the README file with information on the images added previously, > and provide firmware descriptor documents that conform to > "docs/interop/firmware.json". > > Signed-off-by: Laszlo Ersek > Reviewed-by: Michal Privoznik > Reviewed-by: Michael S.

Re: [Qemu-devel] [PATCH 12/15] qemu-print: New qemu_printf(), qemu_vprintf() etc.

"Dr. David Alan Gilbert" writes: > * Markus Armbruster (arm...@redhat.com) wrote: >> We commonly want to print to the current monitor if we have one, else >> to stdout/stderr. For stderr, have error_printf(). For stdout, all >> we have is monitor_vfprintf(), which is rather unwieldy. We often

Re: [Qemu-devel] [PATCH for-4.1 v4 06/12] roms/Makefile: replace the $(EDK2_EFIROM) target with "edk2-basetools"

On 4/10/19 1:00 AM, Laszlo Ersek wrote: > We don't (can't) have a recipe for building just $(EDK2_EFIROM); > therefore, while we call the target $(EDK2_EFIROM), we actually build all > of the edk2 BaseTools. Rename the target to edk2-basetools, and update the > iPXE prerequisite accordingly. This w

[Qemu-devel] [PATCH for-4.1] roms: Correct the EDK2_BASETOOLS_OPTFLAGS variable description

In commit 1cab464136b4 we incorrectly described the EDK2_BASETOOLS_OPTFLAGS can pass CPPFLAGS and CFLAGS options to the EDK2 build tools, but it only expands the CFLAGS (not to the CPPFLAGS). Update the description to be more accurate. Reported-by: Laszlo Ersek Signed-off-by: Philippe Mathieu-Dau

[Qemu-devel] [PATCH v5 3/6] libnvdimm: add dax_dev sync flag

This patch adds 'DAXDEV_SYNC' flag which is set for nd_region doing synchronous flush. This later is used to disable MAP_SYNC functionality for ext4 & xfs filesystem for devices don't support synchronous flush. Signed-off-by: Pankaj Gupta --- drivers/dax/bus.c| 2 +- drivers/dax/sup

[Qemu-devel] [PATCH v5 6/6] xfs: disable map_sync for async flush

Dont support 'MAP_SYNC' with non-DAX files and DAX files with asynchronous dax_device. Virtio pmem provides asynchronous host page cache flush mechanism. We don't support 'MAP_SYNC' with virtio pmem and xfs. Signed-off-by: Pankaj Gupta --- fs/xfs/xfs_file.c | 10 ++ 1 file changed, 6 ins

[Qemu-devel] [PATCH v5 2/5] virtio-pmem: Add virtio pmem driver

This patch adds virtio-pmem driver for KVM guest. Guest reads the persistent memory range information from Qemu over VIRTIO and registers it on nvdimm_bus. It also creates a nd_region object with the persistent memory range information so that existing 'nvdimm/pmem' driver can reserve this into sy

[Qemu-devel] [PATCH v5 0/6] virtio pmem driver

This patch series has implementation for "virtio pmem". "virtio pmem" is fake persistent memory(nvdimm) in guest which allows to bypass the guest page cache. This also implements a VIRTIO based asynchronous flush mechanism. Sharing guest kernel driver in this patchset with the changes

[Qemu-devel] [PATCH v5 5/6] ext4: disable map_sync for async flush

Dont support 'MAP_SYNC' with non-DAX files and DAX files with asynchronous dax_device. Virtio pmem provides asynchronous host page cache flush mechanism. We don't support 'MAP_SYNC' with virtio pmem and ext4. Signed-off-by: Pankaj Gupta --- fs/ext4/file.c | 11 ++- 1 file changed, 6 ins

[Qemu-devel] [PATCH v5 4/6] dax: check synchronous mapping is supported

This patch introduces 'daxdev_mapping_supported' helper which checks if 'MAP_SYNC' is supported with filesystem mapping. It also checks if corresponding dax_device is synchronous. Virtio pmem device is asynchronous and does not not support VM_SYNC. Suggested-by: Jan Kara Signed-off-by: Pankaj Gu

[Qemu-devel] [PATCH v5 1/6] libnvdimm: nd_region flush callback support

This patch adds functionality to perform flush from guest to host over VIRTIO. We are registering a callback based on 'nd_region' type. virtio_pmem driver requires this special flush function. For rest of the region types we are registering existing flush function. Report error returned by host fsy

[Qemu-devel] [Bug 1824053] [NEW] Qemu-img convert appears to be stuck on aarch64 host with low probability

Public bug reported: Hi, I found a problem that qemu-img convert appears to be stuck on aarch64 host with low probability. The convert command line is "qemu-img convert -f qcow2 -O raw disk.qcow2 disk.raw ". The bt is below: Thread 2 (Thread 0x4b776e50 (LWP 27215)): #0 0x4a3f299

Re: [Qemu-devel] [PATCH v6 48/49] linux-user: Split out ioctl

On 4/9/19 1:30 PM, Richard Henderson wrote: > On 4/9/19 1:15 PM, Richard Henderson wrote: >> On 2/13/19 3:46 AM, Laurent Vivier wrote: >>> In fact it happens with sid, with ppc64 too, but not with m68k and sh4. >>> >>> And only with "unshare --pid --fork". >>> >>> Without "unshare", the result is:

[Qemu-devel] [PATCH RFC 3/3] qemu-img.texi: use macros for command summaries

Use a macro to recall this text instead of re-entering it manually. Modify the pxtool script to create macros for each subcommand, then alter the qemu-img.texi file to recall these macros. Signed-off-by: John Snow --- qemu-img.texi | 28 ++-- scripts/pxtool.py | 4 +

[Qemu-devel] [PATCH RFC 2/3] pxtool: Add new qemu-img command info generation tool

Presently we use hxtool and a .hx format to generate a few things like the qemu_img subcommand dispatch table, the qemu_img help() display output, and a help output in qemu-img.texi. Unfortunately, this means that this information is duplicated in at least three places: (1) in qemu-img-cmds.hx as

[Qemu-devel] [PATCH RFC 1/3] qemu-img: fix .hx and .texi disparity

It turns out that having options listed in three places continues to be a bad idea. I'm still toying with the idea of an improved infrastructure here, but in the meantime, another bandaid. There are three locations: (1) .hx file, formatted as texi (2) .hx file, formatted as human readable. (3) .te

[Qemu-devel] [PATCH RFC 0/3] qemu-img: remove command documentation duplication

This might hopefully cut down on the doc duplication/mismatching until I can devise something more comprehensive. Ideally, I'd like to redo all of the documentation for qemu-img nearly from scratch; with a parser generator that helps generate the documentation as well so they'll never get out of d

Re: [Qemu-devel] [PATCH for-4.1] q35: acpi: do not create dummy MCFG table

On Tue, Apr 09, 2019 at 05:00:37PM +0200, Igor Mammedov wrote: >Dummy table (with signature "QEMU") creation came from original SeaBIOS >codebase. And QEMU would have to keep it around if there were Q35 machine >that depended on keeping ACPI tables blob constant size. Luckily there >were no version

[Qemu-devel] [RHEL-8.1 virt 1/2] memory: Fix the memory region type assignment order

BZ: 1667249 Branch: rhel-8.1.0 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1667249 Upstream Status: 4.0.0-rc1 Build Info: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=20980582 Conflicts: None commit 2ddb89b00f947f785c9ca6742f28f954e3b75e62 Author: Singh, Brijesh Date: M

[Qemu-devel] [RHEL-8.1 virt 2/2] target/i386: sev: Do not pin the ram device memory region

BZ: 1667249 Branch: rhel-8.1.0 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1667249 Upstream Status: 4.0.0-rc1 Build Info: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=20980582 Conflicts: None commit cedc0ad539afbbb669dba9e73dfad2915bc1c25b Author: Singh, Brijesh Date: M

[Qemu-devel] [RHEL-8.1 virt 0/2] Enable SEV VM to boot with assigned PCI device

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1667249 On an AMD SEV enabled host with an SEV enabled guest, attaching an assigned device to the VM results in a failure to start the VM: qemu-kvm: -device vfio-pci,host=01:00.0,id=hostdev0,bus=pci.2,addr=0x0: sev_ram_block_added: failed to

Re: [Qemu-devel] [PATCH for-4.1 2/2] spapr: Drop duplicate code in LSI mapping

On Mon, Apr 08, 2019 at 05:01:37PM +0200, Greg Kurz wrote: > On Mon, 8 Apr 2019 13:40:54 +1000 > David Gibson wrote: > > > On Fri, Apr 05, 2019 at 06:30:48PM +0200, Greg Kurz wrote: > > > LSI mapping in spapr currently open-codes standard PCI swizzling. It thus > > > duplicates the code of pci_sw

Re: [Qemu-devel] [PATCH for-4.0-maybe] device_tree: Fix integer overflowing in load_device_tree()

On Tue, Apr 09, 2019 at 08:59:55PM +0200, Philippe Mathieu-Daudé wrote: > On 4/9/19 7:40 PM, Markus Armbruster wrote: > > If the value of get_image_size() exceeds INT_MAX / 2 - 1, the > > computation of @dt_size overflows to a negative number, which then > > gets converted to a very large size_

Re: [Qemu-devel] [PATCH for-4.1] hw/arm/smmuv3: Remove SMMUNotifierNode

On Tue, Apr 09, 2019 at 06:02:19PM +0200, Eric Auger wrote: > The SMMUNotifierNode struct is not necessary and brings extra > complexity so let's remove it. We now directly track the SMMUDevices > which have registered IOMMU MR notifiers. > > This is inspired from the same transformation on intel-

[Qemu-devel] [PULL 1/1] device_tree: Fix integer overflowing in load_device_tree()

From: Markus Armbruster If the value of get_image_size() exceeds INT_MAX / 2 - 1, the computation of @dt_size overflows to a negative number, which then gets converted to a very large size_t for g_malloc0() and load_image_size(). In the (fortunately improbable) case g_malloc0() succeeds and

[Qemu-devel] [PULL 0/1] device-tree queue

The following changes since commit f151f8aca5cf5da24f6eb743a55a2233091ae532: migration/ram.c: Fix use-after-free in multifd_recv_unfill_packet() (2019-04-09 20:46:34 +0100) are available in the Git repository at: g...@github.com:alistair23/qemu.git tags/pull-device-tree-20190409-1 for you

Re: [Qemu-devel] [PATCH v4 1/6] vfio-ccw: make it safe to access channel programs

On Mon, 8 Apr 2019 19:07:47 +0200 Cornelia Huck wrote: > On Mon, 8 Apr 2019 13:02:12 -0400 > Farhan Ali wrote: > > > On 03/01/2019 04:38 AM, Cornelia Huck wrote: > > > When we get a solicited interrupt, the start function may have > > > been cleared by a csch, but we still have a channel progra

[Qemu-devel] [PATCH] migration: savevm: fix error code with migration blockers

The only caller that checks the error code is looking for != 0, so returning false is incorrect. Fixes: 5aaac467938 "migration: savevm: consult migration blockers" Signed-off-by: Cole Robinson --- migration/savevm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/migration/s

Re: [Qemu-devel] [PATCH v6 48/49] linux-user: Split out ioctl

On 4/9/19 1:15 PM, Richard Henderson wrote: > On 2/13/19 3:46 AM, Laurent Vivier wrote: >> In fact it happens with sid, with ppc64 too, but not with m68k and sh4. >> >> And only with "unshare --pid --fork". >> >> Without "unshare", the result is: >> >> Unsupported ioctl: cmd=0x80047476 >> bash:

Re: [Qemu-devel] [PATCH v6 48/49] linux-user: Split out ioctl

On 2/13/19 3:46 AM, Laurent Vivier wrote: > On 13/02/2019 14:09, Laurent Vivier wrote: >> Hi, >> >> this one is really a cut'n'paste but it introduces a problem with >> qemu-alpha, I don't know how/why: >> >> $ sudo unshare --ipc --uts --pid --fork --kill-child --mount chroot >> chroot/alpha/si

Re: [Qemu-devel] [PATCH for-4.1 v4 00/12] bundle edk2 platform firmware with QEMU

On Wed, Apr 10, 2019 at 01:00:10AM +0200, Laszlo Ersek wrote: > Repo: https://github.com/lersek/qemu.git > Branch: edk2_build_v4 > > Posting a v4 is necessary because patch #6 needs > - manual conflict resolution against some commits between v4.0.0-rc2 and > v4.0.0-rc3, > - and corresponding c

[Qemu-devel] [PATCH for-4.1 v4 12/12] MAINTAINERS: add the "EDK2 Firmware" subsystem

We now have the edk2 submodule, somewhat elaborate build helpers for it, and even a UEFI application written against edk2 whose genuine home is the QEMU repository. Add the "EDK2 Firmware" subsystem such that all relevant pathnames be covered. Suggested-by: Daniel P. Berrangé Suggested-by: Michae

[Qemu-devel] [PATCH for-4.1 v4 11/12] Makefile: install the edk2 firmware images and their descriptors

Decompress and install the edk2 firmware blobs as part of "make install", unless blob installation was disabled with configure's "--disable-blobs" option. Additionally, decompress the blobs as a pre-requisite for building softmmu binaries -- this is helpful for both "make check" and other ad-hoc t

[Qemu-devel] [PATCH for-4.1 v4 08/12] pc-bios: add edk2 firmware binaries and variable store templates

Add the files built by the last patch: (compressed) binaries, and the cumulative license text that covers them. Signed-off-by: Laszlo Ersek Reviewed-by: Michal Privoznik Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Michael S. Tsirkin --- Notes: v4: - no change v3:

[Qemu-devel] [PATCH for-4.1 v4 10/12] tests: add missing dependency to build QTEST_QEMU_BINARY, round 2

In commit b94b330e2333 ("tests: add missing dependency to build QTEST_QEMU_BINARY", 2017-07-31), Phil fixed the dependency list of make target "check-qtest-%". Namely, the recipe would set QTEST_QEMU_BINARY to the softmmu emulator for the emulation target, but the prerequisites didn't include the e

[Qemu-devel] [PATCH for-4.1 v4 03/12] tests/uefi-test-tools/build.sh: work around TianoCore#1607

The edk2-stabe201903 release introduced Python3 support to edk2's BaseTools; however the Python3 enablement breaks in a corner case (which is nevertheless supported by the edk2 community), namely the in-module parallelization that we utilize. This is tracked under

[Qemu-devel] [PATCH for-4.1 v4 07/12] roms: build edk2 firmware binaries and variable store templates

Add the "efi" target to "Makefile". Introduce "Makefile.edk2" for building and cleaning the firmware images and varstore templates. Collect the common bits from the recipes in the helper script "edk2-build.sh". Signed-off-by: Laszlo Ersek Reviewed-by: Michal Privoznik Reviewed-by: Philippe Mat

[Qemu-devel] [PATCH for-4.1 v4 04/12] roms/edk2: advance to tag edk2-stable201903

Update the roms/edk2 submodule hash from edk2-stable201811 to edk2-stable201903. The release notes are available at . $ git shortlog edk2-stable201811..edk2-stable201903 Achin Gupta (9): ArmPkg: Add PCDs needed for MM communi

[Qemu-devel] [PATCH for-4.1 v4 09/12] pc-bios: document the edk2 firmware images; add firmware descriptors

Update the README file with information on the images added previously, and provide firmware descriptor documents that conform to "docs/interop/firmware.json". Signed-off-by: Laszlo Ersek Reviewed-by: Michal Privoznik Reviewed-by: Michael S. Tsirkin Tested-by: Igor Mammedov --- Notes: v4:

[Qemu-devel] [PATCH for-4.1 v4 02/12] roms/edk2-funcs.sh: require gcc-4.8+ for building i386 and x86_64

Adapt the qemu_edk2_get_toolchain() function in "roms/edk2-funcs.sh" in advance to edk2 commit 8d7cdfae8cb8 ("OvmfPkg: require GCC48 or later", 2019-01-08), which is part of the "edk2-stable201903" tag. Signed-off-by: Laszlo Ersek Reviewed-by: Philippe Mathieu-Daudé Tested-by: Philippe Mathieu-D

[Qemu-devel] [PATCH for-4.1 v4 06/12] roms/Makefile: replace the $(EDK2_EFIROM) target with "edk2-basetools"

We don't (can't) have a recipe for building just $(EDK2_EFIROM); therefore, while we call the target $(EDK2_EFIROM), we actually build all of the edk2 BaseTools. Rename the target to edk2-basetools, and update the iPXE prerequisite accordingly. This will let other targets depend on "edk2-basetools"

[Qemu-devel] [PATCH for-4.1 v4 00/12] bundle edk2 platform firmware with QEMU

Repo: https://github.com/lersek/qemu.git Branch: edk2_build_v4 Posting a v4 is necessary because patch #6 needs - manual conflict resolution against some commits between v4.0.0-rc2 and v4.0.0-rc3, - and corresponding commit message updates. These are noted in more detail on the patch itself:

[Qemu-devel] [PATCH for-4.1 v4 01/12] roms: lift "edk2-funcs.sh" from "tests/uefi-test-tools/build.sh"

Extract the dense logic for architecture and toolchain massaging from "tests/uefi-test-tools/build.sh", to a set of small functions. We'll reuse these functions for building full platform firmware images. Signed-off-by: Laszlo Ersek Reviewed-by: Philippe Mathieu-Daudé Tested-by: Philippe Mathieu

[Qemu-devel] [PATCH for-4.1 v4 05/12] roms/edk2-funcs.sh: add the qemu_edk2_get_thread_count() function

The edk2 "build" utility natively supports building modules (that is, INF files) in parallel. The feature is not useful when building a single module (with the "-m" option), but it is useful for platform firmware builds (which include many modules). Add a function that determines the "-n" option ar

[Qemu-devel] [PATCH] qemu-img: fix .hx and .texi disparity

It turns out that having options listed in three places continues to be a bad idea. I'm still toying with the idea of an improved infrastructure here, but in the meantime, another bandaid. There are three locations: (1) .hx file, formatted as texi (2) .hx file, formatted as human readable. (3) .te

Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures

On 4/9/19 9:46 AM, Stefan Weil wrote: > * Calling conventions. The current implementation works on many hosts, > but for example not on Sparc. A fix would require simple calling > conventions for all helper functions (for example stack based argument > passing, can this be enforced?), or it needs t

[Qemu-devel] [Bug 1815252] Re: virtio-9p-pci passthrough fsync hang

Damn, I just ran into this bug again! Then realized I'd already reported it :( -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1815252 Title: virtio-9p-pci passthrough fsync hang Status in QEMU:

Re: [Qemu-devel] [PATCH for-4.0-maybe] device_tree: Fix integer overflowing in load_device_tree()

On Tue, 9 Apr 2019 at 21:15, Alistair Francis wrote: > > On Tue, Apr 9, 2019 at 1:08 PM Peter Maydell wrote: > > > > On Wed, 10 Apr 2019 at 00:40, Markus Armbruster wrote: > > > > > > If the value of get_image_size() exceeds INT_MAX / 2 - 1, the > > > computation of @dt_size overflows to a n

Re: [Qemu-devel] [Bug 1814352] Re: SIOCGIFNAME takes a struct ifreq not an integer

On Wed, 10 Apr 2019 at 01:26, Erik Kline <1814...@bugs.launchpad.net> wrote: > Sure. Looking at HEAD, and even the surrounding the lines, I think I > should have tried STRUCT_short_ifreq instead of STRUCT_int_ifreq, though > I'm not sure what the real difference would be. The multiple STRUCT_*_if

Re: [Qemu-devel] [PATCH for-4.0-maybe] device_tree: Fix integer overflowing in load_device_tree()

On Tue, Apr 9, 2019 at 1:08 PM Peter Maydell wrote: > > On Wed, 10 Apr 2019 at 00:40, Markus Armbruster wrote: > > > > If the value of get_image_size() exceeds INT_MAX / 2 - 1, the > > computation of @dt_size overflows to a negative number, which then > > gets converted to a very large size_t

Re: [Qemu-devel] [PATCH for-4.0-maybe] device_tree: Fix integer overflowing in load_device_tree()

On Wed, 10 Apr 2019 at 00:40, Markus Armbruster wrote: > > If the value of get_image_size() exceeds INT_MAX / 2 - 1, the > computation of @dt_size overflows to a negative number, which then > gets converted to a very large size_t for g_malloc0() and > load_image_size(). In the (fortunately im

Re: [Qemu-devel] Misaligned memory writes on ARM and other runtime errors

On Wed, 10 Apr 2019 at 02:12, Stefan Weil wrote: > > When QEMU for ARM is compiled with sanitizers > (--extra-cflags=-fsanitize=address,undefined), I see runtime errors for > qemu-arm which indicate misaligned memory writes: > > /qemu/linux-user/fd-trans.c:1389:18: runtime error: store to misalign

Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures

On 05.04.19 11:16, Philippe Mathieu-Daudé wrote: > On 4/5/19 11:02 AM, Daniel P. Berrangé wrote: >> On Fri, Apr 05, 2019 at 10:47:54AM +0200, Philippe Mathieu-Daudé wrote: >> Do the various crashes that you illustrate in that cover letter >> still exist today ? If so, 2 years of continued brokennes

[Qemu-devel] [PATCH] linux-user: Support the SIOCSIFPFLAGS and SIOCGIFPFLAGS ioctls

From: Neng Chen Add support for setting and getting extended (private) flags of a network device via SIOCSIFPFLAGS and SIOCGIFPFLAGS ioctls. The ioctl numeric values are platform-independent and determined by the file include/uapi/linux/sockios.h in Linux kernel source code. The ioctls set and

Re: [Qemu-devel] [PATCH for-4.0] migration/ram.c: Fix use-after-free in multifd_recv_unfill_packet()

On Tue, 9 Apr 2019 at 22:42, Juan Quintela wrote: > > Peter Maydell wrote: > > Coverity points out (CID 1400442) that in this code: > > > > if (packet->pages_alloc > p->pages->allocated) { > > multifd_pages_clear(p->pages); > > multifd_pages_init(packet->pages_alloc); > >

[Qemu-devel] Misaligned memory writes on ARM and other runtime errors

When QEMU for ARM is compiled with sanitizers (--extra-cflags=-fsanitize=address,undefined), I see runtime errors for qemu-arm which indicate misaligned memory writes: /qemu/linux-user/fd-trans.c:1389:18: runtime error: store to misaligned address 0x42ff4b34 for type 'uint64_t', which requires 8 b

Re: [Qemu-devel] [PATCH v4 00/20] monitor: add asynchronous command type

Patchew URL: https://patchew.org/QEMU/20190409161009.6322-1-marcandre.lur...@redhat.com/ Hi, This series failed the docker-mingw@fedora build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BE

Re: [Qemu-devel] [PATCH 0/9] tcg: Add tcg_gen_extract2_{i32,i64}

On 09.04.19 21:02, Richard Henderson wrote: > On 4/9/19 8:53 AM, David Hildenbrand wrote: >> On 07.03.19 15:41, Richard Henderson wrote: >>> The primary motivator here is usage within s390x, >>> but (as with any good primitive) the opcode has >>> applications outside that. >> >> I am planning to se

Re: [Qemu-devel] [PATCH v4 00/20] monitor: add asynchronous command type

Patchew URL: https://patchew.org/QEMU/20190409161009.6322-1-marcandre.lur...@redhat.com/ Hi, This series failed the asan build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #!/bin/b

Re: [Qemu-devel] [PATCH 0/9] tcg: Add tcg_gen_extract2_{i32,i64}

On 4/9/19 8:53 AM, David Hildenbrand wrote: > On 07.03.19 15:41, Richard Henderson wrote: >> The primary motivator here is usage within s390x, >> but (as with any good primitive) the opcode has >> applications outside that. > > I am planning to send the next big part of vector instruction support

Re: [Qemu-devel] [PATCH 0/9] tcg: Add tcg_gen_extract2_{i32,i64}

On 07.03.19 15:41, Richard Henderson wrote: > The primary motivator here is usage within s390x, > but (as with any good primitive) the opcode has > applications outside that. I am planning to send the next big part of vector instruction support (Vector Integer Instructions) soon, that would make u

Re: [Qemu-devel] [PATCH for-4.0-maybe] device_tree: Fix integer overflowing in load_device_tree()

On 4/9/19 7:40 PM, Markus Armbruster wrote: > If the value of get_image_size() exceeds INT_MAX / 2 - 1, the > computation of @dt_size overflows to a negative number, which then > gets converted to a very large size_t for g_malloc0() and > load_image_size(). In the (fortunately improbable) case

Re: [Qemu-devel] [PATCH] docs: replace min-glib with fedora

On 4/9/19 5:44 PM, Marc-André Lureau wrote: > min-glib.docker was removed in commit > e7b3af81597db1a6b55f2c15d030d703c6b2c6ac ("glib: bump min required > glib library version to 2.40"). > > Cc: Daniel P. Berrangé > Signed-off-by: Marc-André Lureau Reviewed-by: Philippe Mathieu-Daudé > --- >

Re: [Qemu-devel] [PATCH for-4.0] migration/ram.c: Fix use-after-free in multifd_recv_unfill_packet()

On 4/9/19 5:18 PM, Peter Maydell wrote: > Coverity points out (CID 1400442) that in this code: > > if (packet->pages_alloc > p->pages->allocated) { > multifd_pages_clear(p->pages); > multifd_pages_init(packet->pages_alloc); > } > > we free p->pages in multifd_pages_clear()

Re: [Qemu-devel] [PULL v3 0/5] Misc patches for QEMU 5.0-rc3

On 4/9/19 7:25 PM, Peter Maydell wrote: > On Tue, 9 Apr 2019 at 17:36, Paolo Bonzini wrote: >> >> The following changes since commit 248987f92cfda8305d6d44ced23e173e62a8bc0e: >> >> Merge remote-tracking branch >> 'remotes/vivier2/tags/linux-user-for-4.0-pull-request' into staging >> (2019-04-0

Re: [Qemu-devel] [PATCH 15/15] monitor: Simplify how -device/device_add print help

* Markus Armbruster (arm...@redhat.com) wrote: > Commit a95db58f210 added monitor_vfprintf() as an error_printf() > generalized from stderr to arbitrary streams, then used it wrapped in > helper out_printf() to print -device/device_add help to stdout. Use > qemu_printf() instead, and delete monito

Re: [Qemu-devel] [Bug 1814352] Re: SIOCGIFNAME takes a struct ifreq not an integer

Sure. Looking at HEAD, and even the surrounding the lines, I think I should have tried STRUCT_short_ifreq instead of STRUCT_int_ifreq, though I'm not sure what the real difference would be. I'll try to test internally with the _short_ version and if that works send that. -- You received this bu

[Qemu-devel] [Bug 1823998] [NEW] qemu-system-aarch64: support kernels bigger than 128MiB

Public bug reported: Presently QEMU reserves up to 128MiB of space for an arm64 Linux kernel, placing the initrd following this, and the dtb following the initrd. This is not sufficient for some debug configurations of the kernel, which can be larger than 128MiB. Depending on the relative size of

Re: [Qemu-devel] [PATCH 12/15] qemu-print: New qemu_printf(), qemu_vprintf() etc.

* Markus Armbruster (arm...@redhat.com) wrote: > We commonly want to print to the current monitor if we have one, else > to stdout/stderr. For stderr, have error_printf(). For stdout, all > we have is monitor_vfprintf(), which is rather unwieldy. We often > print to stderr just because error_pri

Re: [Qemu-devel] [PATCH 00/10] block/pflash_cfi02: Implement missing AMD pflash functionality

On Apr 9, 2019, at 12:15, Philippe Mathieu-Daudé wrote: > Since you did changes in the CFI table, I think we should add a tests > verifying the table is correctly generated for all you FlashConfig entries. That's a good idea. Some of the values are essentially arbitrary (e.g., how long an er

[Qemu-devel] [PATCH for-4.0-maybe] device_tree: Fix integer overflowing in load_device_tree()

If the value of get_image_size() exceeds INT_MAX / 2 - 1, the computation of @dt_size overflows to a negative number, which then gets converted to a very large size_t for g_malloc0() and load_image_size(). In the (fortunately improbable) case g_malloc0() succeeds and load_image_size() survives

Re: [Qemu-devel] How to correctly use more than 2 floppy drives?

On 4/9/19 7:38 AM, Philippe Mathieu-Daudé wrote: > On 4/8/19 9:30 PM, John Snow wrote: >> On 4/8/19 1:38 AM, Markus Armbruster wrote: >>> Hervé Poussineau writes: >>> Le 05/04/2019 à 12:29, Philippe Mathieu-Daudé a écrit : > Hi, > > I am trying to understand the possible values

Re: [Qemu-devel] [PULL v3 0/5] Misc patches for QEMU 5.0-rc3

On Tue, 9 Apr 2019 at 17:36, Paolo Bonzini wrote: > > The following changes since commit 248987f92cfda8305d6d44ced23e173e62a8bc0e: > > Merge remote-tracking branch > 'remotes/vivier2/tags/linux-user-for-4.0-pull-request' into staging > (2019-04-09 10:02:30 +0100) > > are available in the git r

Re: [Qemu-devel] [PATCH for 4.1 v2 2/6] target/riscv: Fall back to generating a RISC-V CPU

On Thu, Apr 4, 2019 at 5:35 AM Ian Campbell wrote: > > On Fri, 2019-03-29 at 22:39 +, Alistair Francis wrote: > > +for (i = 0; i < strlen(riscv_cpu); i++) { > > +if (i == 0 && riscv_cpu[i] == 'r' && > > +riscv_cpu[i + 1] == 'v') { > > Dpes something somewhere else enfor

Re: [Qemu-devel] [PATCH] tci: Fix some unaligned memory accesses

On Tue, 9 Apr 2019 at 18:04, Stefan Weil wrote: > > On 09.04.19 08:58, Richard Henderson wrote: > > On 4/8/19 8:04 PM, Stefan Weil wrote: > >> static tcg_target_ulong tci_read_i(uint8_t **tb_ptr) > >> { > >> -tcg_target_ulong value = *(tcg_target_ulong *)(*tb_ptr); > >> +tcg_target_ulong

Re: [Qemu-devel] [PATCH 0/4] Header cleanups

Thanks! On Tue, Apr 9, 2019 at 10:36 PM, Thomas Huth wrote: > On 09/04/2019 17.56, Aruna Jayasena wrote: > > Removed unwanted includes from cpu-common.h > > This task was under https://wiki.qemu.org/Contribute/BiteSizedTasks > > > > Signed-off-by: Aruna Jayasena > > > > --- > > include/exec/cp

Re: [Qemu-devel] [PATCH 0/4] Header cleanups

On 09/04/2019 17.56, Aruna Jayasena wrote: > Removed unwanted includes from cpu-common.h > This task was under https://wiki.qemu.org/Contribute/BiteSizedTasks > > Signed-off-by: Aruna Jayasena > > --- > include/exec/cpu-common.h | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/include

Re: [Qemu-devel] [PATCH] tci: Fix some unaligned memory accesses

On 09.04.19 08:58, Richard Henderson wrote: > On 4/8/19 8:04 PM, Stefan Weil wrote: >> static tcg_target_ulong tci_read_i(uint8_t **tb_ptr) >> { >> -tcg_target_ulong value = *(tcg_target_ulong *)(*tb_ptr); >> +tcg_target_ulong value; > > Ideally these would use the helpers from "qemu/bsw

Re: [Qemu-devel] [PATCH 0/4] Header cleanups

Ok, thanks On Tue, Apr 9, 2019 at 10:20 PM, Peter Maydell wrote: > On Tue, 9 Apr 2019 at 17:42, Aruna Jayasena > wrote: > > > > Yeah this is a stand alone patch. > > OK, thanks -- just wanted to check there wasn't a missing > bit. I think this could go in via the qemu-trivial tree > so I have c

Re: [Qemu-devel] [PATCH 0/4] Header cleanups

On Tue, 9 Apr 2019 at 17:42, Aruna Jayasena wrote: > > Yeah this is a stand alone patch. OK, thanks -- just wanted to check there wasn't a missing bit. I think this could go in via the qemu-trivial tree so I have cc'd them. We're in the middle of a release at the moment, but we should reopen for

Re: [Qemu-devel] [PATCH 0/4] Header cleanups

Thank you On Tue, Apr 9, 2019 at 10:12 PM, Aruna Jayasena wrote: > Yeah this is a stand alone patch. > > On Tue, Apr 9, 2019 at 10:10 PM, Peter Maydell > wrote: > >> On Tue, 9 Apr 2019 at 16:58, Aruna Jayasena >> wrote: >> > >> > Removed unwanted includes from cpu-common.h >> > This task was u

Re: [Qemu-devel] [PATCH 0/4] Header cleanups

Yeah this is a stand alone patch. On Tue, Apr 9, 2019 at 10:10 PM, Peter Maydell wrote: > On Tue, 9 Apr 2019 at 16:58, Aruna Jayasena > wrote: > > > > Removed unwanted includes from cpu-common.h > > This task was under https://wiki.qemu.org/Contribute/BiteSizedTasks > > > > Signed-off-by: Aruna

[Qemu-devel] [PATCH] xen-block: support feature-large-sector-size

A recent Xen commit [1] clarified the semantics of sector based quantities used in the blkif protocol such that it is now safe to create a xen-block device with a logical_block_size != 512, as long as the device only connects to a frontend advertizing 'feature-large-block-size'. This patch modifie

Re: [Qemu-devel] [PATCH 0/4] Header cleanups

On Tue, 9 Apr 2019 at 16:58, Aruna Jayasena wrote: > > Removed unwanted includes from cpu-common.h > This task was under https://wiki.qemu.org/Contribute/BiteSizedTasks > > Signed-off-by: Aruna Jayasena > > --- > include/exec/cpu-common.h | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a

[Qemu-devel] [PULL 5/5] tests: Make check-block a phony target

From: Markus Armbruster Fixes: b93b63f574c "test makefile overhaul" Signed-off-by: Markus Armbruster Reviewed-by: Eric Blake Message-Id: <20190319072104.32591-1-arm...@redhat.com> Signed-off-by: Paolo Bonzini --- tests/Makefile.include | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) d

  1   2   3   >