Re: [Qemu-devel] [qemu-web PATCH] download: Add instructions for MacPorts

On 04/04/2018 19:41, Stefan Weil wrote: > Am 04.04.2018 um 18:11 schrieb Paolo Bonzini: >> On 04/04/2018 17:55, Stefan Weil wrote: >>> By the way: https://qemu.weilnetz.de provides https (maybe I should >>> enforce it), it includes sha512, and I also sign the binaries with my >>> key. You still

[Qemu-devel] [PATCH v2] hw/arm/integratorcp: Don't do things that could be fatal in the instance_init

An instance_init function must not fail - and might be called multiple times, e.g. during device introspection with the 'device-list-properties' QMP command. Since the integratorcm device ignores this rule, QEMU currently aborts in this case (though it really should not): echo

Re: [Qemu-devel] [PULL 16/20] target/arm: Use vector infrastructure for aa64 compares

On 05.04.2018 02:54, Richard Henderson wrote: > On 04/05/2018 10:07 AM, Richard Henderson wrote: >> On 04/05/2018 02:49 AM, Emilio G. Cota wrote: >>> 1. grab this binary: >>> http://cs.columbia.edu/~cota/qemu/nbench-aarch64 >>> 2. run it on a PowerPC host with: >>> $

Re: [Qemu-devel] [PULL 16/20] target/arm: Use vector infrastructure for aa64 compares

On Thu, Apr 05, 2018 at 10:54:46 +1000, Richard Henderson wrote: > On 04/05/2018 10:07 AM, Richard Henderson wrote: > > On 04/05/2018 02:49 AM, Emilio G. Cota wrote: > >> 1. grab this binary: > >> http://cs.columbia.edu/~cota/qemu/nbench-aarch64 > >> 2. run it on a PowerPC host with: > >> $

Re: [Qemu-devel] [PATCH v3 4/4] target/ppc: generalize check on radix when in HV mode

On Thu, Mar 15, 2018 at 01:34:02PM +, Cédric Le Goater wrote: > On a POWER9 processor, the first doubleword of the partition table > entry (as pointed to by the PTCR) indicates whether the host uses HPT > or Radix Tree translation for that partition. Use that bit to check > for radix mode on

Re: [Qemu-devel] [PATCH for-2.12] memfd: fix vhost-user-test on non-memfd capable host

On Wed, Mar 28, 2018 at 02:18:04PM +0200, Marc-André Lureau wrote: > On RHEL7, memfd is not supported, and vhost-user-test fails: > TEST: tests/vhost-user-test... (pid=10248) > /x86_64/vhost-user/migrate: > qemu-system-x86_64: -object memory-backend-memfd,id=mem,size=2M,: failed to > create

Re: [Qemu-devel] [PATCH v2] linux-user: fix preadv/pwritev offsets

On 04/05/2018 11:41 AM, Max Filippov wrote: > +static void target_low_high_to_host_low_high(abi_ulong tlow, > + abi_ulong thigh, > + unsigned long *hlow, > + unsigned

Re: [Qemu-devel] [PATCH] linux-user: fix preadv/pwritev offsets

On 04/05/2018 11:33 AM, Max Filippov wrote: > +static void target_low_high_to_host_low_high(abi_ulong tlow, > + abi_ulong thigh, > + unsigned long *hlow, > + unsigned

Re: [Qemu-devel] [RFC PATCH v2 4/4] memory: Add memory_region_set_priority()

On 5/4/18 11:22 am, Philippe Mathieu-Daudé wrote: > Signed-off-by: Philippe Mathieu-Daudé > --- > Sadly I'm missing something, this does not work. What does not work precisely? memory_region_set_priority() is not called or visit_type_int32() does not return priority, etc? > >

Re: [Qemu-devel] [PATCHv2 for-2.13 0/2] Helpers to obtain host page sizes for guest RAM

On Wed, Apr 04, 2018 at 07:35:17PM -0700, no-re...@patchew.org wrote: > Hi, > > This series seems to have some coding style problems. See output below for > more information: > > Type: series > Message-id: 20180405022002.17809-1-da...@gibson.dropbear.id.au > Subject: [Qemu-devel] [PATCHv2

Re: [Qemu-devel] [PATCHv2 for-2.13 0/2] Helpers to obtain host page sizes for guest RAM

Hi, This series failed 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. Type: series Message-id: 20180405022002.17809-1-da...@gibson.dropbear.id.au Subject: [Qemu-devel] [PATCHv2

Re: [Qemu-devel] [PATCHv2 for-2.13 0/2] Helpers to obtain host page sizes for guest RAM

Hi, This series seems to have some coding style problems. See output below for more information: Type: series Message-id: 20180405022002.17809-1-da...@gibson.dropbear.id.au Subject: [Qemu-devel] [PATCHv2 for-2.13 0/2] Helpers to obtain host page sizes for guest RAM === TEST SCRIPT BEGIN ===

Re: [Qemu-devel] [PATCH qemu] spapr: Initialize reserved areas list in FDT in H_CAS handler

On Thu, Apr 05, 2018 at 12:07:38PM +1000, Alexey Kardashevskiy wrote: > At the moment the device tree produced by the H_CAS handler has no > reserved map initialized at all which is not correct as at least one > empty record is required to be present as a marker of the end. > This does not cause

[Qemu-devel] [PATCHv2 for-2.13 2/2] Add host_memory_backend_pagesize() helper

There are a couple places (one generic, one target specific) where we need to get the host page size associated with a particular memory backend. I have some upcoming code which will add another place which wants this. So, for convenience, add a helper function to calculate this.

[Qemu-devel] [PATCH for-2.13 13/13] target/ppc: Fold slb_nr into PPCHash64Options

The env->slb_nr field gives the size of the SLB (Segment Lookaside Buffer). This is another static-after-initialization parameter of the specific version of the 64-bit hash MMU in the CPU. So, this patch folds the field into PPCHash64Options with the other hash MMU options. This is a bit more

Re: [Qemu-devel] [PATCH v2 for 2.12] vfio: Use a trace point when a RAM section cannot be DMA mapped

On Thu, 5 Apr 2018 10:53:38 +1000 Alexey Kardashevskiy wrote: > On 5/4/18 9:09 am, Alex Williamson wrote: > > On Wed, 4 Apr 2018 22:30:50 +0200 > > Eric Auger wrote: > > > >> The 567b5b309abe ("vfio/pci: Relax DMA map errors for MMIO regions") > >>

[Qemu-devel] [PATCH for-2.13 09/13] target/ppc: Move 1T segment and AMR options to PPCHash64Options

Currently env->mmu_model is a bit of an unholy mess of an enum of distinct MMU types, with various flag bits as well. This makes which bits of the field should be compared pretty confusing. Make a start on cleaning that up by moving two of the flags bits - POWERPC_MMU_1TSEG and POWERPC_MMU_AMR -

[Qemu-devel] [PATCHv2 for-2.13 0/2] Helpers to obtain host page sizes for guest RAM

This series makes some small changes to make it easier to obtain the host page size backing given portions of guest RAM. We use this in a couple of places currently, and I have one or two more to add in some upcoming code. Changes since v1: * Reworked design based on Eduardo's feedback *

[Qemu-devel] [PATCH for-2.13 12/13] target/ppc: Get rid of POWERPC_MMU_VER() macros

These macros were introduced to deal with the fact that the mmu_model field has bit flags mixed in with what's otherwise an enum of various mmu types. We've now eliminated all those flags except for one, and that one - POWERPC_MMU_64 - is already included/compared in the MMU_VER macros. So, we

[Qemu-devel] [PATCH for-2.13 05/13] target/ppc: Remove fallback 64k pagesize information

CPU definitions for cpus with the 64-bit hash MMU can include a table of available pagesizes. If this isn't supplied ppc_cpu_instance_init() will fill it in a fallback table based on the POWERPC_MMU_64K bit in mmu_model. However, it turns out all the cpus which support 64K pages already include

[Qemu-devel] [PATCH for-2.13 07/13] target/ppc: Split page size information into a separate allocation

env->sps contains page size encoding information as an embedded structure. Since this information is specific to 64-bit hash MMUs, split it out into a separately allocated structure, to reduce the basic env size for other cpus. Along the way we make a few other cleanups: * Rename to

[Qemu-devel] [PATCH for-2.13 04/13] target/ppc: Avoid taking "env" parameter to mmu-hash64 functions

In most cases we prefer to pass a PowerPCCPU rather than the (embedded) CPUPPCState. For ppc_hash64_update_{rmls,vrma}() change to take "cpu" instead of "env". For ppc_hash64_set_{dsi,isi}() remove the redundant "env" parameter. In theory this makes more work for the functions, but since "cs",

[Qemu-devel] [PATCH for-2.13 01/13] target/ppc: Standardize instance_init and realize function names

Because of the various hooks called some variant on "init" - and the rather greater number that used to exist, I'm always wondering when a function called simply "*_init" or "*_initfn" will be called. To make it easier on myself, and maybe others, rename the instance_init hooks for ppc cpus to

[Qemu-devel] [PATCHv2 for-2.13 1/2] Make qemu_mempath_getpagesize() accept NULL

qemu_mempath_getpagesize() gets the effective (host side) page size for a block of memory backed by an mmap()ed file on the host. It requires the mem_path parameter to be non-NULL. This ends up meaning all the callers need a different case for handling anonymous memory (for memory-backend-ram or

[Qemu-devel] [PATCH for-2.13 00/13] target/ppc: Assorted cpu cleanups (esp. hash64 MMU)

Here's a set of cleanups for the ppc cpu code. Most are related specifically to the 64-bit hash MMU, but there are some others as well. In particular it establishes a new structure PPCHash64Options which contains details of the hash64 mmu which can vary from one cpu to another. This attempts to

[Qemu-devel] [PATCH for-2.13 08/13] target/ppc: Make hash64_opts field mandatory for 64-bit hash MMUs

Currently some cpus set the hash64_opts field in the class structure, with specific details of their variant of the 64-bit hash mmu. For the remaining cpus with that mmu, ppc_hash64_realize() fills in defaults. But there are only a couple of cpus that use those fallbacks, so just have them to

[Qemu-devel] [PATCH for-2.13 03/13] target/ppc: Pass cpu instead of env to ppc_create_page_sizes_prop()

As a rule we prefer to pass PowerPCCPU instead of CPUPPCState, and this change will make some things simpler later on. Signed-off-by: David Gibson Reviewed-by: Greg Kurz Reviewed-by: Cédric Le Goater --- hw/ppc/fdt.c | 5

[Qemu-devel] [PATCH for-2.13 10/13] target/ppc: Fold ci_large_pages flag into PPCHash64Options

The ci_large_pages boolean in CPUPPCState is only relevant to 64-bit hash MMU machines, indicating whether it's possible to map large (> 4kiB) pages as cache-inhibitied (i.e. for IO, rather than memory). Fold it as another flag into the PPCHash64Options structure. Signed-off-by: David Gibson

[Qemu-devel] [PATCH for-2.13 11/13] target/ppc: Remove unnecessary POWERPC_MMU_V3 flag from mmu_model

The only place we test this flag is in conjunction with ppc64_use_proc_tbl(). That checks for the LPCR_UPRT bit, which we already ensure can't be set except on a machine with a v3 MMU (i.e. POWER9). Signed-off-by: David Gibson Reviewed-by: Cédric Le Goater

[Qemu-devel] [PATCH for-2.13 02/13] target/ppc: Simplify cpu valid check in ppc_cpu_realize

The #if isn't necessary, because there's a suitable one inside ppc_cpu_is_valid(). We've already filtered for suitable cpu models in the functions that search and register them. So by the time we get to realize having an invalid one indicates a code error, not a user error, so an assert() is

[Qemu-devel] [PATCH for-2.13 06/13] target/ppc: Move page size setup to helper function

Initialization of the env->sps structure at the end of instance_init is specific to the 64-bit hash MMU, so move the code into a helper function in mmu-hash64.c. We also create a corresponding function to be called at finalize time - it's empty for now, but we'll need it shortly. Signed-off-by:

[Qemu-devel] [PATCH qemu] spapr: Initialize reserved areas list in FDT in H_CAS handler

At the moment the device tree produced by the H_CAS handler has no reserved map initialized at all which is not correct as at least one empty record is required to be present as a marker of the end. This does not cause problems now as the only consumer is SLOF which does not look at the reserved

[Qemu-devel] [PATCH v2] linux-user: fix preadv/pwritev offsets

preadv/pwritev accept low and high parts of file offset in two separate parameters. When host bitness doesn't match guest bitness these parts must be appropriately recombined. Introduce target_low_high_to_host_low_high that does this recombination and use it in preadv/pwritev syscalls. This fixes

Re: [Qemu-devel] Loadable block drivers?

On 4 April 2018 at 23:41, Stefan Hajnoczi wrote: > On Tue, Apr 03, 2018 at 11:30:33AM +0800, Fam Zheng wrote: > > On Tue, 04/03 13:17, Lindsay Mathieson wrote: > > > On 3 April 2018 at 13:11, Fam Zheng wrote: > > > > > > > On Tue, 04/03 12:59, Lindsay

[Qemu-devel] [PATCH] linux-user: fix preadv/pwritev offsets

preadv/pwritev accept low and high parts of file offset in two separate parameters. When host bitness doesn't match guest bitness these parts must be appropriately recombined. Introduce target_low_high_to_host_low_high that does this recombination and use it in preadv/pwritev syscalls. This fixes

Re: [Qemu-devel] [RFC PATCH v2 0/4] memory: fix access_with_adjusted_size() and misc

Hi, This series failed 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. Type: series Message-id: 20180405012241.25714-1-f4...@amsat.org Subject: [Qemu-devel] [RFC PATCH v2 0/4] memory:

[Qemu-devel] [RFC PATCH v2 4/4] memory: Add memory_region_set_priority()

Signed-off-by: Philippe Mathieu-Daudé --- Sadly I'm missing something, this does not work. memory.c | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/memory.c b/memory.c index eaa5fa7f23..ae45ea7779 100644 --- a/memory.c +++ b/memory.c @@

[Qemu-devel] [PATCH v2 3/4] memory: Fix memory_region 'priority' property sign

Priorities can be negative, fix this limitation. Signed-off-by: Philippe Mathieu-Daudé --- memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/memory.c b/memory.c index e77f9e4036..eaa5fa7f23 100644 --- a/memory.c +++ b/memory.c @@ -1258,7 +1258,7 @@

[Qemu-devel] [PATCH v2 1/4] memory: Avoid to create tiny RAM regions, handled as subpages

If an user creates a RAM region smaller than TARGET_PAGE_SIZE, this region will be handled as a subpage. While the subpage behavior can be noticed by an experienced QEMU developper, it might takes hours to a novice to figure it out. To save time to novices, do not allow subpage creation via the

[Qemu-devel] [NOTFORMERGE PATCH v2 2/4] memory: Fix access_with_adjusted_size() when size < access_size_min

ASan reported: shift exponent 4294967280 is too large for 64-bit type 'long unsigned int' ... runtime error: shift exponent -16 is negative This can occurs when MemoryRegionOps .valid.min_access_size < .impl.min_access_size, for example if a guest uses a 16-bit operand to access a

[Qemu-devel] [RFC PATCH v2 0/4] memory: fix access_with_adjusted_size() and misc

Hi, these are few memory related patches. Patch #2 v1 was: http://lists.gnu.org/archive/html/qemu-devel/2017-08/msg02255.html I'll send the related qtests in v3. Patch #4 is a failed attempt to change a region priority at runtime. Phil. Philippe Mathieu-Daudé (4): memory: Avoid to create

Re: [Qemu-devel] [PULL 16/20] target/arm: Use vector infrastructure for aa64 compares

On 04/05/2018 10:07 AM, Richard Henderson wrote: > On 04/05/2018 02:49 AM, Emilio G. Cota wrote: >> 1. grab this binary: >> http://cs.columbia.edu/~cota/qemu/nbench-aarch64 >> 2. run it on a PowerPC host with: >> $ aarch64-linux-user/qemu-aarch64 nbench-aarch64 -V >> >> Note: the "-V" (or

Re: [Qemu-devel] [PATCH v2 for 2.12] vfio: Use a trace point when a RAM section cannot be DMA mapped

On 5/4/18 9:09 am, Alex Williamson wrote: > On Wed, 4 Apr 2018 22:30:50 +0200 > Eric Auger wrote: > >> The 567b5b309abe ("vfio/pci: Relax DMA map errors for MMIO regions") >> added an error message if a passed memory section address or size >> is not aligned to the page

Re: [Qemu-devel] [PULL 16/20] target/arm: Use vector infrastructure for aa64 compares

On 04/05/2018 02:49 AM, Emilio G. Cota wrote: > 1. grab this binary: > http://cs.columbia.edu/~cota/qemu/nbench-aarch64 > 2. run it on a PowerPC host with: > $ aarch64-linux-user/qemu-aarch64 nbench-aarch64 -V > > Note: the "-V" (or "-v") flag is important! Without it, there's no segfault.

[Qemu-devel] [PATCH for-2.12] hw/block/pflash_cfi: fix off-by-one error

ASAN reported: hw/block/pflash_cfi02.c:245:33: runtime error: index 82 out of bounds for type 'uint8_t [82]' Since the 'cfi_len' member is not used, remove it to keep the code safer. Reported-by: AddressSanitizer Signed-off-by: Philippe Mathieu-Daudé ---

Re: [Qemu-devel] [PATCH v3 00/15] fp-test + hardfloat

Hi, This series seems to have some coding style problems. See output below for more information: Type: series Message-id: 1522883475-27858-1-git-send-email-c...@braap.org Subject: [Qemu-devel] [PATCH v3 00/15] fp-test + hardfloat === TEST SCRIPT BEGIN === #!/bin/bash BASE=base n=1 total=$(git

Re: [Qemu-devel] [PATCH v3 13/15] hardfloat: support float32/64 fused multiply-add

On Wed, Apr 04, 2018 at 19:11:13 -0400, Emilio G. Cota wrote: (snip) > +if (likely((soft_t ## _is_normal(a) || soft_t ## _is_zero(a)) && \ > + (soft_t ## _is_normal(b) || soft_t ## _is_zero(b)) && \ > + (soft_t ## _is_normal(c) || soft_t ## _is_zero(c))

Re: [Qemu-devel] [PATCHv1 00/14] Translation loop conversion for sh4/sparc/mips/s390x/openrisc targets

On Thu, Mar 01, 2018 at 17:53:44 -0500, Emilio G. Cota wrote: > [ What is this all about? See this message: > http://lists.gnu.org/archive/html/qemu-devel/2018-02/msg04785.html ] (snip) > You can fetch this series from: > https://github.com/cota/qemu/tree/trloop-conv-v1 *ping* on this series.

[Qemu-devel] [PATCH v3 09/15] fpu: introduce hardfloat

The appended paves the way for leveraging the host FPU for a subset of guest FP operations. For most guest workloads (e.g. FP flags aren't ever cleared, inexact occurs often and rounding is set to the default [to nearest]) this will yield sizable performance speedups. The approach followed here

[Qemu-devel] [PATCH v3 08/15] softfloat: add float{32, 64}_is_zero_or_normal

These will gain some users very soon. Signed-off-by: Emilio G. Cota --- include/fpu/softfloat.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/include/fpu/softfloat.h b/include/fpu/softfloat.h index a8512fb..66985e1 100644 --- a/include/fpu/softfloat.h +++

Re: [Qemu-devel] [PATCH v3 14/15] hardfloat: support float32/64 square root

On Wed, Apr 04, 2018 at 19:11:14 -0400, Emilio G. Cota wrote: (snip) > +if (likely((soft_t ## _is_normal(a) || soft_t ## _is_zero(a)) && \ Updated on the github tree to: -if (likely((soft_t ## _is_normal(a) || soft_t ## _is_zero(a)) && \ +if (likely(soft_t ##

[Qemu-devel] [PATCH v3 12/15] hardfloat: support float32/64 division

Performance results for fp-bench: 1. Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz - before: div-single: 34.84 MFlops div-double: 34.04 MFlops - after: div-single: 275.23 MFlops div-double: 216.38 MFlops 2. ARM Aarch64 A57 @ 2.4GHz - before: div-single: 9.33 MFlops div-double: 9.30 MFlops - after:

[Qemu-devel] [PATCH v3 06/15] tests/fp: add fp-bench, a collection of simple floating point microbenchmarks

This will allow us to measure the performance impact of FP emulation optimizations. Note that we can measure both directly the impact on the softfloat functions (with "-t soft"), or the impact on an emulated workload (call with "-t host" and run under qemu user-mode). Signed-off-by: Emilio G.

[Qemu-devel] [PATCH v3 11/15] hardfloat: support float32/64 multiplication

Performance results for fp-bench: 1. Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz - before: mul-single: 126.91 MFlops mul-double: 118.28 MFlops - after: mul-single: 258.02 MFlops mul-double: 197.96 MFlops 2. ARM Aarch64 A57 @ 2.4GHz - before: mul-single: 37.42 MFlops mul-double: 38.77 MFlops -

[Qemu-devel] [PATCH v3 15/15] hardfloat: support float32/64 comparison

Performance results for fp-bench: 1. Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz - before: cmp-single: 113.01 MFlops cmp-double: 115.54 MFlops - after: cmp-single: 527.83 MFlops cmp-double: 457.21 MFlops 2. ARM Aarch64 A57 @ 2.4GHz - before: cmp-single: 39.32 MFlops cmp-double: 39.80 MFlops -

[Qemu-devel] [PATCH v3 05/15] target/tricore: use float32_is_denormal

Cc: Bastian Koppelmann Signed-off-by: Emilio G. Cota --- target/tricore/fpu_helper.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/target/tricore/fpu_helper.c b/target/tricore/fpu_helper.c index df16290..31df462

[Qemu-devel] [PATCH v3 07/15] softfloat: rename canonicalize to sf_canonicalize

glibc >= 2.25 defines canonicalize in commit eaf5ad0 (Add canonicalize, canonicalizef, canonicalizel., 2016-10-26). Given that we'll be including soon, prepare for this by prefixing our canonicalize() with sf_ to avoid clashing with the libc's canonicalize(). Reported-by: Bastian Koppelmann

[Qemu-devel] [PATCH v3 14/15] hardfloat: support float32/64 square root

Performance results for fp-bench: 1. Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz - before: sqrt-single: 43.27 MFlops sqrt-double: 24.81 MFlops - after: sqrt-single: 297.94 MFlops sqrt-double: 210.46 MFlops 2. ARM Aarch64 A57 @ 2.4GHz - before: sqrt-single: 12.41 MFlops sqrt-double: 6.22 MFlops -

[Qemu-devel] [PATCH v3 04/15] softfloat: add float{32, 64}_is_{de, }normal

This paves the way for upcoming work. Cc: Bastian Koppelmann Reviewed-by: Alex Bennée Signed-off-by: Emilio G. Cota --- include/fpu/softfloat.h | 20 1 file changed, 20 insertions(+) diff --git

[Qemu-devel] [PATCH v3 03/15] fp-test: add muladd variants

These are a few muladd-related operations that the original IBM syntax does not specify; model files for these are in muladd.fptest. Signed-off-by: Emilio G. Cota --- tests/fp/fp-test.c | 24 tests/fp/muladd.fptest | 51

[Qemu-devel] [PATCH v3 10/15] hardfloat: support float32/64 addition and subtraction

Performance results (single and double precision) for fp-bench: 1. Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz - before: add-single: 135.07 MFlops add-double: 131.60 MFlops sub-single: 130.04 MFlops sub-double: 133.01 MFlops - after: add-single: 443.04 MFlops add-double: 301.95 MFlops sub-single:

[Qemu-devel] [PATCH v3 01/15] tests: add fp-test, a floating point test suite

This will allow us to run correctness tests against our FP implementation. The test can be run in two modes (called "testers"): host and soft. With the former we check the results and FP flags on the host machine against the model. With the latter we check QEMU's fpu primitives against the model.

[Qemu-devel] [PATCH v3 13/15] hardfloat: support float32/64 fused multiply-add

Performance results for fp-bench: 1. Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz - before: fma-single: 74.73 MFlops fma-double: 74.54 MFlops - after: fma-single: 203.37 MFlops fma-double: 169.37 MFlops 2. ARM Aarch64 A57 @ 2.4GHz - before: fma-single: 23.24 MFlops fma-double: 23.70 MFlops - after:

[Qemu-devel] [PATCH v3 02/15] softfloat: fix {min, max}nummag for same-abs-value inputs

Before 8936006 ("fpu/softfloat: re-factor minmax", 2018-02-21), we used to return +Zero for maxnummag(-Zero,+Zero); after that commit, we return -Zero. Fix it by making {min,max}nummag consistent with {min,max}num, deferring to the latter when the absolute value of the operands is the same. With

[Qemu-devel] [PATCH v3 00/15] fp-test + hardfloat

v2: https://lists.gnu.org/archive/html/qemu-devel/2018-03/msg06805.html Changes since v2: - Add R-b tags - Add a patch to rename our canonicalize to sf_canonicalize, to avoid clashing with glibc's. - Add a patch to define float{32,64}_is_zero_or_normal - Simplify the

Re: [Qemu-devel] [PATCH v2 for 2.12] vfio: Use a trace point when a RAM section cannot be DMA mapped

On Wed, 4 Apr 2018 22:30:50 +0200 Eric Auger wrote: > The 567b5b309abe ("vfio/pci: Relax DMA map errors for MMIO regions") > added an error message if a passed memory section address or size > is not aligned to the page size and thus cannot be DMA mapped. > > This patch

Re: [Qemu-devel] [Qemu-arm] [PATCH for-2.12] hw/arm/integratorcp: Don't do things that could be fatal in the instance_init

Hi Thomas, On 04/04/2018 04:15 PM, Thomas Huth wrote: > An instance_init function must not fail - and might be called multiple times, > e.g. during device introspection with the 'device-list-properties' QMP > command. Since the integratorcm device ignores this rule, QEMU currently > aborts in

[Qemu-devel] [ANNOUNCE] QEMU 2.12.0-rc2 is now available

Hello, On behalf of the QEMU Team, I'd like to announce the availability of the third release candidate for the QEMU 2.12 release. This release is meant for testing purposes and should not be used in a production environment. http://download.qemu-project.org/qemu-2.12.0-rc2.tar.xz

Re: [Qemu-devel] [PATCH v2 for 2.12] vfio: Use a trace point when a RAM section cannot be DMA mapped

On 04/04/2018 05:30 PM, Eric Auger wrote: > The 567b5b309abe ("vfio/pci: Relax DMA map errors for MMIO regions") > added an error message if a passed memory section address or size > is not aligned to the page size and thus cannot be DMA mapped. > > This patch fixes the trace by printing the

Re: [Qemu-devel] [PULL 16/20] target/arm: Use vector infrastructure for aa64 compares

On Wed, Apr 04, 2018 at 19:24:52 +0100, Alex Bennée wrote: > > Emilio G. Cota writes: > > > On Wed, Feb 07, 2018 at 14:55:36 -0800, Richard Henderson wrote: > >> Reviewed-by: Alex Bennée > >> Reviewed-by: Peter Maydell > >>

[Qemu-devel] [PATCH v2 for 2.12] vfio: Use a trace point when a RAM section cannot be DMA mapped

The 567b5b309abe ("vfio/pci: Relax DMA map errors for MMIO regions") added an error message if a passed memory section address or size is not aligned to the page size and thus cannot be DMA mapped. This patch fixes the trace by printing the region name and the memory region section offset within

Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception

On 04/04/2018 09:43 AM, Pierre Morel wrote: On 04/04/2018 15:33, Tony Krowiak wrote: On 04/04/2018 07:09 AM, Pierre Morel wrote: On 02/04/2018 18:36, Tony Krowiak wrote: On 03/26/2018 05:03 AM, Pierre Morel wrote: On 26/03/2018 10:32, David Hildenbrand wrote: On 16.03.2018 00:24, Tony

Re: [Qemu-devel] [PATCH 1/1] block-backend: simplify blk_get_aio_context

Ping On 03/27/2018 10:08 AM, Daniel Henrique Barboza wrote: blk_get_aio_context verifies if BlockDriverState bs is not NULL, return bdrv_get_aio_context(bs) if true or qemu_get_aio_context() otherwise. However, bdrv_get_aio_context from block.c already does this verification itself, also

Re: [Qemu-devel] [PULL for-2.12 0/1] Block patches

On 4 April 2018 at 17:10, Jeff Cody wrote: > The following changes since commit fd69ad866b62ca8ed4337ffee83b6d82a4e99282: > > Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging > (2018-04-04 14:00:07 +0100) > > are available in the git repository at:

[Qemu-devel] [PATCH for-2.12] hw/arm/integratorcp: Don't do things that could be fatal in the instance_init

An instance_init function must not fail - and might be called multiple times, e.g. during device introspection with the 'device-list-properties' QMP command. Since the integratorcm device ignores this rule, QEMU currently aborts in this case (though it really should not): echo

[Qemu-devel] TCG MicroBlaze 64-bit extended addressing

Hello, I'm looking at adding support for MicroBlaze extended addressing allowing 32bit cores to reach a 64-bit address space. The ABI for MicroBlaze remains 32-bits. It's basically a PAE-like MMU extension + a new set of extended address Load/Store instructions for the non-MMU mode. I'm

Re: [Qemu-devel] [Qemu-block] [PATCH for-2.12] gluster: Fix blockdev-add with server.N.type=unix

On 04/04/2018 01:37 PM, Kevin Wolf wrote: > Am 04.04.2018 um 20:16 hat Eric Blake geschrieben: >> On 04/04/2018 10:54 AM, Kevin Wolf wrote: >> > Should we also add a deprecation warning for 'socket' and update the > deprecation documentation, so we can start the clock ticking on getting

Re: [Qemu-devel] [Qemu-block] [PATCH for-2.12] gluster: Fix blockdev-add with server.N.type=unix

Am 04.04.2018 um 20:16 hat Eric Blake geschrieben: > On 04/04/2018 10:54 AM, Kevin Wolf wrote: > > >>> Should we also add a deprecation warning for 'socket' and update the > >>> deprecation documentation, so we can start the clock ticking on getting > >>> rid of maintaining the back-compat glue

Re: [Qemu-devel] [PATCH RFC v3 for-2.12?] scripts/checkpatch.pl: Bug fix

[adding a few more cc's] On 03/25/2018 09:06 PM, Su Hang wrote: > Commit 2b9aef6fcd96ba7ed8c1ee723e391901852d344c introduced a regression: > checkpatch.pl started complaining about the following valid pattern: > do { > /* something */ > } while (condition); > > Fix the script to once again

Re: [Qemu-devel] [PULL 16/20] target/arm: Use vector infrastructure for aa64 compares

Emilio G. Cota writes: > On Wed, Feb 07, 2018 at 14:55:36 -0800, Richard Henderson wrote: >> Reviewed-by: Alex Bennée >> Reviewed-by: Peter Maydell >> Signed-off-by: Richard Henderson > > Just

Re: [Qemu-devel] [Qemu-block] [PATCH for-2.12] gluster: Fix blockdev-add with server.N.type=unix

On 04/04/2018 10:54 AM, Kevin Wolf wrote: >>> Should we also add a deprecation warning for 'socket' and update the >>> deprecation documentation, so we can start the clock ticking on getting >>> rid of maintaining the back-compat glue forever? >> >> Well, that won't be as easy. Since there is at

[Qemu-devel] [Bug 1025244] Re: qcow2 image increasing disk size above the virtual limit

Looking through old bug tickets... is there anything left to do here? Or should we rather close this ticket nowadays? ** Changed in: qemu Status: New => Incomplete ** Changed in: qemu-kvm (Ubuntu) Status: Triaged => Incomplete -- You received this bug notification because you are

[Qemu-devel] [Bug 1426092] Re: virtio-balloon-device locks up Guest

Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? ... anyway, this rather sounds like a bug with the guest kernel to me, so in case this problem persists, you likely should report this in the kernel bug tracker instead. ** Changed in: qemu

[Qemu-devel] [Bug 1441443] Re: Is there a way to create a 10G network interface for VMs in KVM2.0?

Looking through old bug tickets ... have you already tried to use vhost- net? That should be one of the fastest ways of networking with QEMU as far as I know... ** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml,

Re: [Qemu-devel] [qemu-web PATCH] download: Add instructions for MacPorts

Am 04.04.2018 um 18:11 schrieb Paolo Bonzini: > On 04/04/2018 17:55, Stefan Weil wrote: >> By the way: https://qemu.weilnetz.de provides https (maybe I should >> enforce it), it includes sha512, and I also sign the binaries with my >> key. You still have to trust me, Debian and Cygwin (which

Re: [Qemu-devel] [qemu-web PATCH] download: Add instructions for MacPorts

On 04/04/2018 18:19, Programmingkid wrote: >>> I guess there is just too much distrust to provide a QEMU binary for >>> download. >> It's not distrust, it's responsibility. >> >> Paolo > So from what I learned, in order to provide a binary of QEMU, these things > must be done: > - Some kind of

[Qemu-devel] [PATCH for-2.12] hw/arm/allwinner-a10: Do not use nd_table in instance_init function

The instance_init function of a device can be called at any time, even if the device is not going to be used (i.e. not going to be realized). So a instance_init function must not do things that could cause QEMU to exit, like calling qemu_check_nic_model(_table[0], ...) for example. But this is

Re: [Qemu-devel] [PULL 16/20] target/arm: Use vector infrastructure for aa64 compares

On Wed, Feb 07, 2018 at 14:55:36 -0800, Richard Henderson wrote: > Reviewed-by: Alex Bennée > Reviewed-by: Peter Maydell > Signed-off-by: Richard Henderson Just bisected a segfault for aarch64 nbench on a PowerPC

Re: [Qemu-devel] [PATCH] tcg: fix 16-byte vector operations detection

On 3 April 2018 at 16:45, Laurent Vivier wrote: > On 29/03/2018 18:54, Laurent Vivier wrote: >> Hi, >> >> I think it would be good to have this fix (or something similar) in -rc2. > > So no one agrees with that? Applied to master, thanks. -- PMM

[Qemu-devel] [Bug 1749393] Re: sbrk() not working under qemu-user with a PIE-compiled binary?

qemu patch proposed at http://lists.nongnu.org/archive/html/qemu- devel/2018-03/msg04700.html -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1749393 Title: sbrk() not working under qemu-user with a

Re: [Qemu-devel] [qemu-web PATCH] download: Add instructions for MacPorts

> On Apr 4, 2018, at 12:08 PM, Paolo Bonzini wrote: > > On 04/04/2018 18:05, Programmingkid wrote: >> >>> On Apr 4, 2018, at 11:55 AM, Stefan Weil wrote: >>> >>> Am 04.04.2018 um 16:58 schrieb Daniel P. Berrangé: On Wed, Apr 04, 2018 at 04:45:48PM

Re: [Qemu-devel] [PATCH for-2.12 v2] qemu-iotests: update 185 output

On 2018-04-04 17:01, Stefan Hajnoczi wrote: > Commit 4486e89c219c0d1b9bd8dfa0b1dd5b0d51ff2268 ("vl: introduce > vm_shutdown()") added a bdrv_drain_all() call. As a side-effect of the > drain operation the block job iterates one more time than before. The > 185 output no longer matches and the

[Qemu-devel] [PULL for-2.12 1/1] block/rbd: remove processed options from qdict

Commit 4bfb274 added some QAPIfication of option parsing in qemu_rbd_open(). We need to remove all the options we processed, otherwise in bdrv_open_inherit() we will think the remaining options are invalid. (This needs to go in 2.12 to avoid a regression that prevents rbd from being opened.)

Re: [Qemu-devel] [qemu-web PATCH] download: Add instructions for MacPorts

On 04/04/2018 17:55, Stefan Weil wrote: > Am 04.04.2018 um 16:58 schrieb Daniel P. Berrangé: >> On Wed, Apr 04, 2018 at 04:45:48PM +0200, Paolo Bonzini wrote: >>> On 04/04/2018 16:38, Daniel P. Berrangé wrote: The source/quality of those binaries is completely opaque. We've no idea who

Re: [Qemu-devel] [qemu-web PATCH] download: Add instructions for MacPorts

On 04/04/2018 18:05, Programmingkid wrote: > >> On Apr 4, 2018, at 11:55 AM, Stefan Weil wrote: >> >> Am 04.04.2018 um 16:58 schrieb Daniel P. Berrangé: >>> On Wed, Apr 04, 2018 at 04:45:48PM +0200, Paolo Bonzini wrote: On 04/04/2018 16:38, Daniel P. Berrangé wrote: >

[Qemu-devel] [PULL for-2.12 0/1] Block patches

The following changes since commit fd69ad866b62ca8ed4337ffee83b6d82a4e99282: Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging (2018-04-04 14:00:07 +0100) are available in the git repository at: git://github.com/codyprime/qemu-kvm-jtc.git tags/block-pull-request

Re: [Qemu-devel] [qemu-web PATCH] download: Add instructions for MacPorts

> On Apr 4, 2018, at 11:55 AM, Stefan Weil wrote: > > Am 04.04.2018 um 16:58 schrieb Daniel P. Berrangé: >> On Wed, Apr 04, 2018 at 04:45:48PM +0200, Paolo Bonzini wrote: >>> On 04/04/2018 16:38, Daniel P. Berrangé wrote: The source/quality of those binaries is completely

Re: [Qemu-devel] [PATCH v2 RFC 0/2] Implement Hex file loader and add test case

Thanks for your reply! Owning to cultural difference， I used to regard “RFC” as a way of show modest... I will apply your suggestion in v3. Best, Su Hang "Eric Blake" wrote: > On 04/04/2018 10:19 AM, Su Hang wrote: > > These series of patchs implement Intel Hexadecimal File

Re: [Qemu-devel] [PATCH 0/2 RFC] Implement Hex file loader and add test case

A bit embarrassing, this mistake was introduced by me. I submitted a corresponding patch to fix it, but no one has reviewed it. See link below: http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg06506.html "Eric Blake" wrote: > On 04/03/2018 10:37 AM,

Re: [Qemu-devel] [PATCH for-2.12] block/rbd: remove processed options from qdict

Am 04.04.2018 um 17:53 hat Jeff Cody geschrieben: > Commit 4bfb274 added some QAPIfication of option parsing in > qemu_rbd_open(). We need to remove all the options we processed, > otherwise in bdrv_open_inherit() we will think the remaining options are > invalid. > > (This needs to go in 2.12

  1   2   3   >