Hi,
On 05/04/18 04:17, Alex Williamson wrote:
> 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 regi
Hi,
I am doing kvm guest network performance analysis to compare relevant
alternatives for virtio devices on Arrach64.
I have generated bridge tap and macvtap performance numbers on guest
10G interface
connected back to another 10G on other host.
The results for guest with "macvtap" vs "bri
QEMU currently exits unexpectedly when trying to introspect the fsl-imx6
and fsl-imx7 devices on systems with many SMP CPUs:
$ echo "{'execute':'qmp_capabilities'}"\
"{'execute':'device-list-properties',"\
" 'arguments':{'typename':'fsl,imx6'}}" \
| arm-softmmu/qemu-system-arm
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 hav
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 "{'execute':'qmp_cap
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:
>>> $ aarch64-linux-user/qemu-aar
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:
> >> $ aar
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 ps
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 me
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
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
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?
>
> memory.c | 18 ++
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 for-2.1
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 for-2.13
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 ===
#!/
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 pr
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.
host_memory_bac
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 com
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")
> >> added an error message if a passed memory s
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 -
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
* Spli
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 ca
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
a
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", "c
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 PPCHash64
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 *_i
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
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
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 set
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 +++--
hw/ppc/pnv.c | 4 ++--
hw/ppc/spapr.c | 4 ++
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
Rev
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
Reviewed-by: Greg Kurz
---
target/pp
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 more
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: D
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 ma
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
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 Mathieson wrote:
> > > > > Hi all, was looki
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
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: fi
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
@@ -1225,6 +1225,22 @@
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 @@ static void memory_r
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
mem
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 32
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 tiny
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 "-v")
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 size and thus cannot be D
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.
Ho
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é
---
hw/block/pflash_cfi01.c | 10 -
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 l
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)) &
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.
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 av
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
+++ b/include/fpu/softfloa
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 ## _is_zero_or_no
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:
div
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. Cota
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
- after:
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
- after:
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 100644
--- a/target/tricore/fpu_helper.c
+++ b/target
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
Cc:
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
- aft
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 a/include/fpu/softfloat.h b/include/fpu/softfloat.h
index 36626a5..a8512fb 100
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 +++
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: 411
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. N
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:
f
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
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 float{32,64}_input_flush
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 fixes the trace by print
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 this
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
http://dow
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 regio
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
> >> Signed-off-by: Richard Henderson
> >
> > Just bisected a segfault for
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 t
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 Krowia
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 returni
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:
>
> git://github.
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 "{'execute':'qmp_cap
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 primaril
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
>>>
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 fo
[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 p
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 bisected a segfault for aarch64 nbench on a PowerPC host
> to this commit (79d61de6bdc398). I've als
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 l
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
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
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,
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 provid
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 ch
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(&nd_table[0], ...) for example.
But this is w
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 host
to this commit (79d61de6bdc398). I've also tested on x86_64 and
aarch64 hosts
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 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
> 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 +0200, Paolo Bonzini wrote:
> On 04/
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 tes
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.)
Sug
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
>
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:
> The source/quality
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
f
> 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 opaque. We've no i
1 - 100 of 263 matches
Mail list logo
