pc_memory_pre_plug() is called during hotplug for both pc-dimm and
nvdimm. This is more proper to check apci hotplug capability before
check nvdimm specific capability.
Signed-off-by: Wei Yang
---
hw/i386/pc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/hw/i386
Xiang Zheng writes:
> Hi Kevin,
>
> On 2019/4/9 16:28, Kevin Wolf wrote:
>> Am 09.04.2019 um 08:01 hat Markus Armbruster geschrieben:
>>> László's last sentence below is "This really needs the attention of the
>>> block people." Cc'ing some.
>>>
>>> Laszlo Ersek writes:
>>>
On 04/08/19 15:
Hi Steve,
After reading kernel code about time keeping and something related, I've not
got a clear picture of how we can use MSR_KVM_WALL_CLOCK_NEW to keep wall clock
in guest VM.
1. On X86, MSR_KVM_WALL_CLOCK_NEW is only used by the callback of system
suspend and resume; I didn't find it use
On 11.04.19 08:46, Richard Henderson wrote:
> Looks ok, I guess, although the introduction of tci_write_reg16 seems
> redundant
> with the uint16_t value that is loaded.
It could directly call tci_write_reg, but the new code is similar to the
existing code which also uses the same kind of indirec
On 11/04/19 02:57, Li Qiang wrote:
>
>
> Paolo Bonzini mailto:pbonz...@redhat.com>> 于2019
> 年4月10日周三 下午11:55写道：
>
> On 10/04/19 16:33, Li Qiang wrote:
> > Hi all,
> >
> >
> >
> > I see the link device ‘_PRS’ uses irq line 5, 10, 11 in
> > ‘build_link_dev’ function.
Paolo Bonzini 于2019年4月11日周四 下午3:44写道：
> On 11/04/19 02:57, Li Qiang wrote:
> >
> >
> > Paolo Bonzini mailto:pbonz...@redhat.com>> 于2019
> > 年4月10日周三 下午11:55写道：
> >
> > On 10/04/19 16:33, Li Qiang wrote:
> > > Hi all,
> > >
> > >
> > >
> > > I see the link device ‘_PRS’ us
10.04.2019 23:42, Eric Blake wrote:
> Filter the qemu-nbd server output to get rid of a direct reference
> to my build directory.
>
> Fixes: e9dce9cb
> Reported-by: Max Reitz
> Signed-off-by: Eric Blake
> ---
>
> Not worth -rc4 on its own, but if something else pops up that requires
> another s
Hi,
Here is a series of patches from Ben providing MMU fixes for sPAPR and
PowerNV. They seem of interest and deserve a closer look by people
with good knowledge of the PPC MMU.
Thanks,
C.
Benjamin Herrenschmidt (6):
target/ppc: Don't check UPRT in radix mode when in HV real mode
ppc/spapr:
From: Benjamin Herrenschmidt
On some architectures, PTE updates for dirty and changed bits need
to be performed atomically. This adds a couple of address_space_cmpxchg*
helpers for that purpose.
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Cédric Le Goater
---
include/exec/memory_ldst
From: Benjamin Herrenschmidt
It appears that during kexec, we run for a while in hypervisor
real mode with LPCR:HR set and LPCR:UPRT clear, which trips
the assertion in ppc_radix64_handle_mmu_fault().
First this shouldn't be an assertion, it's a guest error.
Then we shouldn't be checking these
From: Benjamin Herrenschmidt
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Cédric Le Goater
---
hw/ppc/spapr_hcall.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index be8044a92f2f..7761d4a841af 100644
--- a/
From: Benjamin Herrenschmidt
With MT-TCG, we are now running translation in a racy way, thus
we need to mimic hardware when it comes to updating the R and
C bits, by doing byte stores.
The current "store_hpte" abstraction is ill suited for this, we
replace it with two separate callbacks for sett
From: Benjamin Herrenschmidt
They should be atomic for MTTCG. Note: a real POWER9 core doesn't actually
implement atomic PTE updates, it always fault for SW to handle it. Only
the nest MMU (used by some accelerator devices and GPUs) implements
those HW updates.
However, the architecture does all
From: Benjamin Herrenschmidt
With MT-TCG, we are now running translation in a racy way, thus
we need to mimic hardware when it comes to updating the R and
C bits, by doing byte stores.
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Cédric Le Goater
---
target/ppc/mmu-hash32.c | 45 +
On 11/04/2019 09.17, Wei Yang wrote:
> pc_memory_pre_plug() is called during hotplug for both pc-dimm and
> nvdimm. This is more proper to check apci hotplug capability before
> check nvdimm specific capability.
>
> Signed-off-by: Wei Yang
> ---
> hw/i386/pc.c | 10 +-
> 1 file changed,
On Thu, Apr 11, 2019 at 10:32:39AM +0200, Thomas Huth wrote:
>On 11/04/2019 09.17, Wei Yang wrote:
>> pc_memory_pre_plug() is called during hotplug for both pc-dimm and
>> nvdimm. This is more proper to check apci hotplug capability before
>> check nvdimm specific capability.
>>
>> Signed-off-by:
On Thu, 11 Apr 2019 08:34:08 +0200
Cédric Le Goater wrote:
> From: Benjamin Herrenschmidt
>
> H_PROD should be fully functional, H_CEDE is modified to
> ignore a proded CPU. H_CONFER is a stub to avoid returning
> an error.
>
> Signed-off-by: Benjamin Herrenschmidt
> Signed-off-by: Cédric Le
On Wed, 10 Apr 2019 at 22:51, Andrew Randrianasulu
wrote:
>
> Please also include this patch in next -rc or final, it fixes 32-bit
> compilation:
>
> https://patchew.org/QEMU/20190402073018.17747-1-kraxel%40redhat.com/
> ([Qemu-devel] [PATCH] curses: fix wchar_t printf warning)
>
> without it I g
On 3/15/19 4:26 AM, Richard Henderson wrote:
> Avoids leaking the /dev/urandom fd into any child processes.
>
> Reviewed-by: Daniel P. Berrangé
> Signed-off-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
> ---
> crypto/random-platform.c | 4 ++--
> 1 file changed, 2 insertions(+),
On 3/15/19 4:26 AM, Richard Henderson wrote:
> There were 3 copies of this code, one of which used the wrong
> data size for the failure indicator.
Which, as the comment said, has never been called.
Good cleanup.
Reviewed-by: Philippe Mathieu-Daudé
> Cc: Gerd Hoffmann
> Signed-off-by: Richard
On 3/15/19 4:26 AM, Richard Henderson wrote:
> Use a better interface for random numbers than rand().
> Fail gracefully if for some reason we cannot use the crypto system.
>
> Cc: Gerd Hoffmann
> Signed-off-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
> ---
> v2: Use qcrypto_rand
On 3/15/19 4:26 AM, Richard Henderson wrote:
> This routine is intended to produce high-quality random numbers to the
> guest. Normally, such numbers are crypto quality from the host, but a
> command-line option can force the use of a fully deterministic sequence
> for use while debugging.
>
> Cc
On 3/15/19 4:26 AM, Richard Henderson wrote:
> When the -seed option is given, call qemu_guest_random_seed_main,
> putting the subsystem into deterministic mode. Pass derived seeds
> to each cpu created; which is a no-op unless the subsystem is in
> deterministic mode.
>
> Cc: Daniel P. Berrangé
On 3/15/19 4:26 AM, Richard Henderson wrote:
> When the -seed option is given, call qemu_guest_random_seed_main,
> putting the subsystem into deterministic mode. Pass derived seeds
> to each cpu created during clone; which is a no-op unless the
> subsystem is in deterministic mode.
>
> Cc: Lauren
Hi Richard,
On 3/15/19 4:26 AM, Richard Henderson wrote:
> Cc: Laurent Vivier
> Signed-off-by: Richard Henderson
> ---
> linux-user/main.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/linux-user/main.c b/linux-user/main.c
> index cf7095bdaf..8478306
On 3/15/19 4:26 AM, Richard Henderson wrote:
> Use a better interface for random numbers than rand() * 3.
>
> Cc: Laurent Vivier
> Signed-off-by: Richard Henderson
> ---
> linux-user/aarch64/target_syscall.h | 2 --
> linux-user/aarch64/cpu_loop.c | 29 ++-
> linu
On 3/15/19 4:26 AM, Richard Henderson wrote:
> We no longer use rand() within linux-user.
>
> Cc: Laurent Vivier
> Signed-off-by: Richard Henderson
> ---
> linux-user/main.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/linux-user/main.c b/linux-user/main.c
> index 8478306eef..80cb
On 3/15/19 4:26 AM, Richard Henderson wrote:
> The random number is intended for use by the guest. As such, we should
> honor the -seed argument for reproducibility. Use the *_nofail routine
> instead of rolling our own error handling locally.
>
> Cc: qemu-...@nongnu.org
> Cc: Cédric Le Goater
On 3/15/19 4:26 AM, Richard Henderson wrote:
> The random number is intended for use by the guest. As such, we should
> honor the -seed argument for reproducibility. Use the *_nofail routine
> instead of rolling our own error handling locally.
>
> Cc: qemu-...@nongnu.org
> Cc: Andrew Baumann
>
On 3/15/19 4:26 AM, Richard Henderson wrote:
> This allows us to use a single syscall to initialize them all.
>
> Signed-off-by: Richard Henderson
> ---
> target/arm/cpu.h | 12 +++-
> linux-user/aarch64/cpu_loop.c | 6 +-
> linux-user/syscall.c | 10 +-
On 3/15/19 4:26 AM, Richard Henderson wrote:
> The random number is intended for use by the guest. As such, we should
> honor the -seed argument for reproducibility.
>
> Cc: qemu-...@nongnu.org
> Cc: Igor Mitsyanko
> Signed-off-by: Richard Henderson
> ---
> hw/misc/exynos4210_rng.c | 11 --
В сообщении от Thursday 11 April 2019 12:14:45 Peter Maydell написал(а):
> On Wed, 10 Apr 2019 at 22:51, Andrew Randrianasulu
> wrote:
> >
> > Please also include this patch in next -rc or final, it fixes 32-bit
> > compilation:
> >
> > https://patchew.org/QEMU/20190402073018.17747-1-kraxel%40red
Similar to VECTOR SHIFT RIGHT ARITHMETICAL.
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 1 +
target/s390x/insn-data.def | 4
target/s390x/translate_vx.inc.c | 17 +
target/s390x/vec_int_helper.c | 6 ++
4 files changed, 28 insertions(
Let's return the cc value directly via cpu_env. Unfortunately there
isn't a simple way to calculate the value lazily - one would have to
calculate and store e.g. the population count of the mask and the
result so it can be evaluated in a cc helper.
But as VTM only sets the cc, we can assume the va
Similar to VECTOR SUM ACROSS DOUBLEWORD.
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 29 +
2 files changed, 31 insertions(+)
diff --git a/target/s390x/insn-data.def b/target/s390x/insn-data.def
index
Add 4.1 machine types for arm/i440fx/q35/s390x/spapr.
Signed-off-by: Cornelia Huck
---
IIRC, we agreed last time that we want to merge a patch introducing
the new compat machines first thing in a new development cycle. So
here's that patch for 4.1.
---
hw/arm/virt.c | 9 -
Perform the calculations without a helper. Only 16 bit or 32 bit values
have to be added.
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 29 +
2 files changed, 31 insertions(+)
diff --git a/target/s390x
Hi Yoshinori,
On 4/1/19 4:03 PM, Yoshinori Sato wrote:
> Hello.
> This patch series is added Renesas RX target emulation.
>
> Update review comments.
>
> My git repository is bellow.
> git://git.pf.osdn.net/gitroot/y/ys/ysato/qemu.git
>
> Testing binaries bellow.
> u-boot
> Download - https://o
Similar to VECTOR SUM ACROSS DOUBLEWORD, however without a loop and
using 128-bit calculations.
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 32
2 files changed, 34 insertions(+)
diff --git a/tar
We can reuse the existing 128-bit shift utility function.
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 1 +
target/s390x/insn-data.def | 4
target/s390x/translate_vx.inc.c | 20
target/s390x/vec_int_helper.c | 6 ++
4 files change
Let's keep it simple for now and handle 8/16/128 bit elements via helpers.
Especially for 8/16, we could come up with some bit tricks.
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 3 +++
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 30
Reuse s390_vec_sub() to perform two 128-bit subtraction, calculating the
borrow.
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 1 +
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 13 +
target/s390x/vec_int_helper.c | 16
Fairly easy as only 128-bit handling is required. Simply perform the
subtraction and then subtract the borrow.
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 27 +++
2 files changed, 29 insertions(+)
diff -
Hi Yoshinori,
Note about the patch subject:
- typo in regiserfields (missing 't') -> registerfields
- I'd simply use "hw/registerfields: Add 8bit and 16bit register macros"
On 4/1/19 4:03 PM, Yoshinori Sato wrote:
> Some RX peripheral using 8bit and 16bit registers.
> Added 8bit and 16bit APIs.
>
We can use tcg_gen_sub2_i64() to do 128-bit subtraction and otherwise
existing gvec helpers.
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 17 +
2 files changed, 19 insertions(+)
diff --git a/target/s390x/insn-dat
Similar to VECTOR SHIFT LEFT ARITHMETIC. Add s390_vec_sar() similar to
s390_vec_shr().
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 1 +
target/s390x/insn-data.def | 4
target/s390x/translate_vx.inc.c | 17 +
target/s390x/vec_int_helper.c |
Take care of properly taking the modulo of the count. We might later
want to come back and create a variant of VERLL where the base register
is 0, resulting in an immediate.
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 4 +++
target/s390x/insn-data.def | 3 ++
ta
Again, vector enhancements facility 1 material.
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 7 +++
2 files changed, 9 insertions(+)
diff --git a/target/s390x/insn-data.def b/target/s390x/insn-data.def
index fb74374a0a..52171
Implement it via an ool helper. reusing the existing shift helpers.
In case the starting index is 0, it is basically a copy of v2 to v1.
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 1 +
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 15
Use the new vector expansion for GVecGen3i. In the ool helpers, reuse
the rotation funvtions introduced with VECTOR ELEMENT ROTATE LEFT
LOGICAL.
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 2 ++
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c
Similar to VECTOR AVERAGE but without sign extension.
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 2 ++
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 48 +
target/s390x/vec_int_helper.c | 16 +++
4
Part of vector enhancements facility 1, but easy to implement.
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate.c| 1 +
target/s390x/translate_vx.inc.c | 7 +++
3 files changed, 10 insertions(+)
diff --git a/target/s390x/insn-data.d
Only for one special case we can reuse real gvec helpers. Mostly
rely on oom helpers.
One important thing to take care of is always to properly mask of
unused bits from the shift count.
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 18 +
target/s390x/insn-data.def
Similar to VECTOR COUNT TRAILING ZEROES.
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 2 ++
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 19 +++
target/s390x/vec_int_helper.c | 14 ++
4 files changed, 37 inser
Again, part of vector enhancement facility 1. The operation corresponds
to an bitwise equality check.
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 7 +++
2 files changed, 9 insertions(+)
diff --git a/target/s390x/insn-data.de
Yet another set of variants. Implement it similar to VECTOR MULTIPLY AND
ADD *. At least for one variant we have a gvec helper we can reuse.
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 16 +
target/s390x/insn-data.def | 14 +
target/s390x/translate_vx.in
Similar to VECTOR LOAD COMPLEMENT but unfortunately we don't have a
gvec helper.
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 2 ++
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 40 +
target/s390x/vec_int_hel
Reuse a gvec helper.
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 7 +++
2 files changed, 9 insertions(+)
diff --git a/target/s390x/insn-data.def b/target/s390x/insn-data.def
index b549b76b96..fb74374a0a 100644
--- a/target/s
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 7 +++
2 files changed, 9 insertions(+)
diff --git a/target/s390x/insn-data.def b/target/s390x/insn-data.def
index bc8b84e1c2..4983867a44 100644
--- a/target/s390x/insn-data.def
+++
Luckily, we already have gvec helpers for all four cases.
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 8
target/s390x/translate_vx.inc.c | 31 +++
2 files changed, 39 insertions(+)
diff --git a/target/s390x/insn-data.def b/target/
Easy, we can reuse an existing gvec helper.
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 7 +++
2 files changed, 9 insertions(+)
diff --git a/target/s390x/insn-data.def b/target/s390x/insn-data.def
index a355b7f62f..b8400c191
Quite some variants to handle. At least handle some 32-bit element
variants via gvec expansion (we could also handle 16/32-bit variants
for ODD and EVEN easily via gvec expansion, but let's keep it simple
for now).
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 18 +
A galois field multiplication in field 2 is like binary multiplication,
however instead of doing ordinary binary additions, xor's are performed.
So no carries are considered.
Implement all variants via helpers. s390_vec_sar() and s390_vec_shr()
will be reused later on.
Signed-off-by: David Hilden
We can reuse an existing gvec helper for negating the values.
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 17 +
2 files changed, 19 insertions(+)
diff --git a/target/s390x/insn-data.def b/target/s390x/insn-data.
Implement it similar to VECTOR COUNT LEADING ZEROS.
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 2 ++
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 28
target/s390x/vec_int_helper.c | 14 ++
4 fil
Fairly easy to implement, we can make use of the existing CC helpers
cmps64 and cmpu64 - we siply have to sign extend the elements.
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 4
target/s390x/translate_vx.inc.c | 20
2 files changed, 24 inser
Handle 32/64-bit elements via gvec expansion and the 8/16 bits via
ool helpers.
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 2 ++
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 63 +
target/s390x/vec_int_help
To carry out the comparison, we can reuse the existing gvec comparison
function. In case the CC is to be computed, save the result vector
and compute the CC lazily. The result is a vector consisting of all 1's
for elements that matched and 0's for elements that didn't match.
Signed-off-by: David H
For 8/16, use the 32 bit variant and properly subtract the added
leading zero bits.
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 2 ++
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 31 +++
target/s390x/vec_int_he
Only slightly ugly, perform two additions. At least it is only supported
for 128 bit elements.
Introduce gen_gvec128_4_i64() similar to gen_gvec128_3_i64().
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 63 +++
Introduce two types of fancy new helpers that will be reused a couple of
times
1. gen_gvec_fn_3: Call an existing tcg_gen_gvec_X function with 3
parameters, simplifying parameter passing
2. gen_gvec128_3_i64: Call a function that performs 128 bit calculations
using two 64 bit values per vect
Only 64 bit handling is really easy. 128 bit handling is performed
via an ool handler, introducing s390_vec_add() that will be reused later.
8/16/32 bit handling is black magic inspired by gen_addv_mask(). If
there is every a bug detected in there, throw it away and simply use
ool helpers for 8/16
Easy, as we can reuse existing gvec helpers.
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 4
target/s390x/translate_vx.inc.c | 14 ++
2 files changed, 18 insertions(+)
diff --git a/target/s390x/insn-data.def b/target/s390x/insn-data.def
index a531b219
Let's add tcg_gen_gvec_3i(), similar to tcg_gen_gvec_2i(), however
without introducing "gen_helper_gvec_3i *fnoi", as it isn't needed
for now.
Signed-off-by: David Hildenbrand
---
tcg/tcg-op-gvec.c | 139 ++
tcg/tcg-op-gvec.h | 24
2 files ch
Time to introduce read_vec_element_i32 and write_vec_element_i32.
Take proper care of properly adding the carry.
Signed-off-by: David Hildenbrand
---
target/s390x/insn-data.def | 2 +
target/s390x/translate_vx.inc.c | 67 +
2 files changed, 69 insertions(+)
On Thu, 11 Apr 2019 03:28:46 -0700 (PDT)
no-re...@patchew.org wrote:
> === OUTPUT BEGIN ===
> ERROR: spaces required around that '=' (ctx:WxV)
> #58: FILE: hw/i386/pc.c:118:
> +GlobalProperty pc_compat_4_0[] ={};
> ^
>
> total: 1 errors, 0 warnings, 160 lines check
Again, use a helper as calculating the carry is even more involved than
for VECTOR ADD COMPUTE CARRY.
Signed-off-by: David Hildenbrand
---
target/s390x/helper.h | 1 +
target/s390x/insn-data.def | 2 ++
target/s390x/translate_vx.inc.c | 13 +
target/s390x/vec_int_hel
RBD APIs don't allow us to write more than the size set with rbd_create()
or rbd_resize().
In order to support growing images (eg. qcow2), we resize the image
before RW operations that exceed the current size.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1171007
Signed-off-by: Stefano Garz
This is the second part of vector instruction support for s390x. It is
based on the series soon to land upstream:
[PATCH 0/9] tcg: Add tcg_gen_extract2_{i32,i64}
Part 1: Vector Support Instructions
Part 2: Vector Integer Instructions
Part 3: Vector String Instructions
Part 4: Vector Floating-P
Signed-off-by: Yuval Shaia
---
hw/Kconfig | 1 +
hw/rdma/Kconfig | 4 +
hw/rdma/Makefile.objs | 2 +
hw/rdma/virtio/virtio-rdma-ib.c | 287
hw/rdma/virtio/virtio-rdma-ib.h
Patchew URL: https://patchew.org/QEMU/20190411102025.22559-1-coh...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190411102025.22559-1-coh...@redhat.com
Subject: [Qemu-devel] [PATCH for-4.1] hw: add compat machines fo
On Thu, 11 Apr 2019 at 11:03, Andrew Randrianasulu
wrote:
>
> В сообщении от Thursday 11 April 2019 12:14:45 Peter Maydell написал(а):
> > On Wed, 10 Apr 2019 at 22:51, Andrew Randrianasulu
> > wrote:
> > >
> > > Please also include this patch in next -rc or final, it fixes 32-bit
> > > compilat
On Wed 10 Apr 2019 05:32:47 PM CEST, Eric Blake wrote:
> On 4/10/19 10:24 AM, Alberto Garcia wrote:
>> You can reproduce this by passing an invalid filter-node-name (like
>> "1234") to block-commit. In this case the base image is put in
>> read-write mode but is never reset back to read-only.
>
> I
RBD APIs don't allow us to write more than the maximum size of the file set
with rbd_create() or rbd_resize(), so we are not able to create/use a qcow2
image with the rbd driver.
What I found is the following:
- when qcow2 uses the rbd driver, the new file is created (rbd_create)
with the size e
Signed-off-by: Yuval Shaia
---
hw/virtio/virtio-net-pci.c | 18 ++-
include/hw/virtio/virtio-net-pci.h | 35 ++
2 files changed, 37 insertions(+), 16 deletions(-)
create mode 100644 include/hw/virtio/virtio-net-pci.h
diff --git a/hw/virtio/virtio-
Data center backends use more and more RDMA or RoCE devices and more and
more software runs in virtualized environment.
There is a need for a standard to enable RDMA/RoCE on Virtual Machines.
Virtio is the optimal solution since is the de-facto para-virtualizaton
technology and also because the Vi
Signed-off-by: Yuval Shaia
---
drivers/infiniband/Kconfig| 1 +
drivers/infiniband/hw/Makefile| 1 +
drivers/infiniband/hw/virtio/Kconfig | 6 +
drivers/infiniband/hw/virtio/Makefile | 4 +
drivers/infiniband/hw/virtio/virtio_rdma.h
It would ensure that we would notice attempt to write beyond
the allocated buffer. In case of MemoryRegion backed ROM it's
the host buffer and the guest RAM otherwise.
assert can be triggered with:
dd if=/dev/zero of=/tmp/blob bs=63k count=1
qemu-system-x86_64 `for i in {1..33}; do echo -n "
Hi Eric,
Could you help to confirm?
Thanks,
Heyi
On 2019/4/7 9:59, Heyi Guo wrote:
Hi Eric,
My real interesting is about the hotplug of PCIe switch, which means we don't
need to provide lots of PCIe root ports or PCIe down stream ports at the
beginning, but we can extend the capacity by h
Public bug reported:
A high volume of communication (UDPv4) between the host and Qemu causes it to
crash.
Qemu version: 2.11.1
Ubuntu 18.04.1 LTS
I attached GDB to the Qemu but wasn't able to get the debug symbols working.
Some more assistance with how to get this working is appreciated (I am ne
Kevin Wolf writes:
> Am 15.03.2019 um 16:33 hat Sergio Lopez geschrieben:
>>
>> Stefan Hajnoczi writes:
>>
>> > On Thu, Mar 14, 2019 at 06:31:34PM +0100, Sergio Lopez wrote:
>> >> Our current AIO path does a great job at unloading the work from the VM,
>> >> and combined with IOThreads provide
On Thu, 11 Apr 2019 09:32:11 +0800
Wei Yang wrote:
> On Wed, Apr 10, 2019 at 05:01:50PM +0200, Igor Mammedov wrote:
> >On Wed, 10 Apr 2019 22:27:56 +0800
> >Wei Yang wrote:
> >
> >[...]
> >> >@@ -2411,19 +2410,7 @@ build_mcfg_q35(GArray *table_data, BIOSLinker
> >> >*linker, AcpiMcfgInfo *inf
On Tue, Apr 09, 2019 at 01:25:43PM +0200, Marc-André Lureau wrote:
> Hi
>
> On Tue, Apr 9, 2019 at 12:40 PM Philippe Mathieu-Daudé
> wrote:
> >
> > On 4/8/19 2:31 PM, Markus Armbruster wrote:
> > > Marc-André Lureau writes:
> > >
> > >> Hi
> > >>
> > >> On Mon, Apr 8, 2019 at 10:36 AM Markus Arm
Could you try reproducing this with the QEMU 4.0 rc3 which we've just
put out, please? I have a vague recollection that we fixed a memory leak
in the slirp networking in this area.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https
On Tue, Apr 09, 2019 at 11:37:44AM +0200, Philippe Mathieu-Daudé wrote:
> On 4/9/19 10:59 AM, Aleksandar Markovic wrote:
> >>
> >> Lidong Chen writes:
> >>
> >>> Due to an off-by-one error, the assert statements allow an
> >>> out-of-bounds array access.
> >>>
> >>> Signed-off-by: Lidong Chen
> >
On Wed, 10 Apr 2019 23:10:42 +
Alistair Francis wrote:
> Signed-off-by: Alistair Francis
Reviewed-by: Igor Mammedov
> ---
> hw/riscv/virt.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index fc4c6b306e..5b25f028ad 100644
On Tue, Apr 09, 2019 at 05:44:35PM +0200, 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
> ---
> docs/devel/test
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1824331
Title:
Qemu Crashes
Status in QEMU:
Incomplete
Bug description:
A high volume of com
On Wed, Apr 10, 2019 at 12:26:52PM +0300, Yury Kotov wrote:
> Currently such case is possible for incoming:
> QMP: add-fd (fdset = 0, fd of some file):
> adds fd to fdset 0 and returns QEMU's fd (e.g. 33)
> QMP: migrate-incoming (uri = "fd:33"): fd is stored in QIOChannel *ioc
> ...
> Incoming
On Wed, 10 Apr 2019 23:11:00 +
Alistair Francis wrote:
> Add a generic spike machine (not tied to a version) and deprecate the
> spike mahines that are tied to a specific version. As we can now specify
> the CPU via the command line we no londer need specific versions of the
> spike machines.
1 - 100 of 285 matches
Mail list logo
