Kevin Wolf writes:
> Monitor.cmd_table is initialised to point to mon_cmds and never changed
> afterwards. We can remove the indirection and just reference mon_cmds
> directly instead.
>
> Signed-off-by: Kevin Wolf
Reviewed-by: Markus Armbruster
On 6/14/19 3:53 AM, David Gibson wrote:
> On Fri, Jun 14, 2019 at 11:40:56AM +1000, David Gibson wrote:
>> On Thu, Jun 13, 2019 at 11:01:19AM +0200, Philippe Mathieu-Daudé wrote:
>>> On 6/13/19 8:07 AM, David Gibson wrote:
ppc64 and ppc64le are different archs from the host kernel point of
Kevin Wolf writes:
> This renames the type for HMP monitor commands and the tables holding
> the commands to make clear that they are related to HMP and to allow
> making them public later:
>
> * mon_cmd_t -> HMPCommand (fixing use of a reserved name, too)
> * mon_cmds -> hmp_cmds
> * info_cmds
On Fri, 14 Jun 2019 11:34:59 +1000
David Gibson wrote:
> On Thu, Jun 13, 2019 at 06:44:54PM +0200, Greg Kurz wrote:
> > The XICS-related RTAS calls and hypercalls in QEMU are supposed to be
> > called only when the KVM in-kernel XICS is in use.
>
> I've applied this, but reversed the sense of
On 6/13/19 6:39 PM, Peter Maydell wrote:
> This patchset does a couple of the cleanup/leftover things noted
> in the coverletter of the vfp decodetree conversion or discussed
> in code review:
> * use vfp_expand_imm() for doing the VFP const-immediate
>decode, rather than hand-coding it
> *
On Jun 13, 2019 6:16 AM, "Richard Henderson"
wrote:
>
> The loop is written with scalars, not vectors.
> Use the correct type when incrementing.
>
> Fixes: 5ee5c14cacd
> Reported-by: Laurent Vivier
> Tested-by: Laurent Vivier
> Reviewed-by: Laurent Vivier
> Signed-off-by: Richard Henderson
>
Hi,
> Can there be a guest that will fail the MBR in such a way? Yes.
> Look at the following MBR partition table of a Windows XP guest in our
> production
> environment:
>
> Disk size in sectors: 16777216
>
> Binary (only one partition 16 bytes): 80 01 01 00 07 fe ff ff 3f 00 00 00 d5
> ea
Eric Blake writes:
> iotests ./check -qcow2 failed for me today:
>
> 191 fail [10:46:04] [10:46:13] 0s (last: 7s)output
> mismatch (see 191.out.bad)
> --- /home/eblake/qemu/tests/qemu-iotests/191.out 2019-05-24
> 09:27:46.449348997 -0500
> +++
On 6/13/19 8:37 PM, Max Reitz wrote:
> Currently, the "thistime" variable is not reinitialized on every loop
> iteration. This leads to tests that do not yield a run time (because
> they failed or were skipped) printing the run time of the previous test
> that did. Fix that by reinitializing
On Fri, Jun 14, 2019 at 11:40:56AM +1000, David Gibson wrote:
> On Thu, Jun 13, 2019 at 11:01:19AM +0200, Philippe Mathieu-Daudé wrote:
> > On 6/13/19 8:07 AM, David Gibson wrote:
> > > ppc64 and ppc64le are different archs from the host kernel point of view
> > > and are advertised as such in
On Thu, Jun 13, 2019 at 06:44:59PM +0200, Greg Kurz wrote:
> QEMU may crash when running a spapr machine in 'dual' interrupt controller
> mode on some older (but not that old, eg. ubuntu 18.04.2) KVMs with partial
> XIVE support:
>
> qemu-system-ppc64: hw/ppc/spapr_rtas.c:411:
This adds an accelerator name to the "into mtree -f" to tell the user if
a particular memory section is registered with the accelerator;
the primary user for this is KVM and such information is useful
for debugging purposes.
This adds a has_memory() callback to the accelerator class allowing any
On Thu, Jun 13, 2019 at 06:45:05PM +0200, Greg Kurz wrote:
> Older KVMs on POWER9 don't support destroying/recreating a KVM XICS
> device, which is required by 'dual' interrupt controller mode. This
> causes QEMU to emit a warning when the guest is rebooted and to fall
> back on XICS emulation:
>
On Thu, Jun 13, 2019 at 11:01:19AM +0200, Philippe Mathieu-Daudé wrote:
> On 6/13/19 8:07 AM, David Gibson wrote:
> > ppc64 and ppc64le are different archs from the host kernel point of view
> > and are advertised as such in uname. But these cover the same set of CPUs,
> > just in different
On Thu, Jun 13, 2019 at 06:44:54PM +0200, Greg Kurz wrote:
> The XICS-related RTAS calls and hypercalls in QEMU are supposed to be
> called only when the KVM in-kernel XICS is in use.
I've applied this, but reversed the sense of the sentence above, which
appears to be the intent.
>
> Add some
On Thu, Jun 13, 2019 at 11:34:06PM +0200, Philippe Mathieu-Daudé wrote:
> Commit 14e714900f6 refactored the call to spapr_dt_drc(),
> introducing a potential NULL pointer dereference while
> accessing bus->parent_dev.
> A trivial audit show 'bus' is not null in the two places
> the static function
On Thu, Apr 25, 2019 at 11:28:31AM +0800, Wei Yang wrote:
>The value left in nr is the number of bits for the last word, which
>could be calculate the last word mask directly.
>
>Remove the unnecessary size.
Ping...
>
>Signed-off-by: Wei Yang
>---
> util/bitmap.c | 6 ++
> 1 file changed, 2
On 13/06/2019 23:08, Philippe Mathieu-Daudé wrote:
> Hi Alexey,
>
> On 6/13/19 7:09 AM, Alexey Kardashevskiy wrote:
>> This adds a trace point which prints every loaded image. This includes
>> bios/firmware/kernel/initradmdisk/pcirom.
>>
>> Signed-off-by: Alexey Kardashevskiy
>> ---
>>
>> The
On 6/13/19 9:39 AM, Peter Maydell wrote:
> Remove some old constructns from NEON_2RM_VCVT_F16_F32 code:
> * don't use CPU_F0s
> * don't use tcg_gen_st_f32
>
> Signed-off-by: Peter Maydell
> ---
> target/arm/translate.c | 26 +++---
> 1 file changed, 11 insertions(+), 15
On 6/13/19 9:39 AM, Peter Maydell wrote:
> Remove the now unused TCG globals cpu_F0s, cpu_F0d, cpu_F1s, cpu_F1d.
>
> cpu_M0 is still used by the iwmmxt code, and cpu_V0 and
> cpu_V1 are used by both iwmmxt and Neon.
>
> Signed-off-by: Peter Maydell
> ---
> target/arm/translate.c | 12
On Wed, 12 Jun 2019 14:40:04 +0200
Eric Auger wrote:
> The code used to assign an interrupt index/subindex to an
> eventfd is duplicated many times. Let's introduce an helper that
> allows to set/unset the signaling for an ACTION_TRIGGER,
> ACTION_MASK or ACTION_UNMASK action.
>
> In the error
From: Eric Auger
The code used to assign an interrupt index/subindex to an
eventfd is duplicated many times. Let's introduce an helper that
allows to set/unset the signaling for an ACTION_TRIGGER,
ACTION_MASK or ACTION_UNMASK action.
In the error message, we now use errno in case of any
Commit 14e714900f6 refactored the call to spapr_dt_drc(),
introducing a potential NULL pointer dereference while
accessing bus->parent_dev.
A trivial audit show 'bus' is not null in the two places
the static function spapr_dt_drc() is called.
Since the 'bus' parameter is not NULL in both callers,
The resizable BAR capability is currently exposed read-only from the
kernel and we don't yet implement a protocol for virtualizing it to
the VM. Exposing it to the guest read-only introduces poor behavior
as the guest has no reason to test that a control register write is
accepted by the
The MSI-X relocation code can sometimes be used to work around bogus
MSI-X capabilities, but this test for whether the PBA is outside of
the specified BAR causes the device to error before we can apply a
relocation. Let it proceed if we intend to relocate MSI-X anyway.
Signed-off-by: Alex
Le 19/05/2019 à 22:19, Richard Henderson a écrit :
> Remove the incorrectly defined UREG constants.
>
> Maddeningly, in some cases we used the correct constant getting
> the env register wrong, and in other cases we used the incorrect
> constant getting the env register right.
>
> In the case of
The following changes since commit 650a379d505bf558bcb41124bc6c951a76cbc113:
Merge remote-tracking branch
'remotes/pmaydell/tags/pull-target-arm-20190613-1' into staging (2019-06-13
15:16:39 +0100)
are available in the Git repository at:
git://github.com/awilliam/qemu-vfio.git tags/vfio
On 6/13/19 9:39 AM, Peter Maydell wrote:
> Stop using cpu_F0s for the Neon f32/s32 VCVT operations.
> Since this is the last user of cpu_F0s in the Neon 2rm-op
> loop, we can remove the handling code for it too.
>
> Signed-off-by: Peter Maydell
> ---
> target/arm/translate.c | 82
On 6/13/19 9:39 AM, Peter Maydell wrote:
> Stop using cpu_F0s for NEON_2RM_VRECPE_F and NEON_2RM_VRSQRTE_F.
>
> Signed-off-by: Peter Maydell
> ---
> target/arm/translate.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Reviewed-by: Richard Henderson
r~
On 6/13/19 9:39 AM, Peter Maydell wrote:
> Stop using cpu_F0s in the Neon VCVT fixed-point operations.
>
> Signed-off-by: Peter Maydell
> ---
> target/arm/translate.c | 62 +++---
> 1 file changed, 28 insertions(+), 34 deletions(-)
Reviewed-by: Richard
On 6/13/19 9:39 AM, Peter Maydell wrote:
> Remove some old constructs from NEON_2RM_VCVT_F16_F32 code:
> * don't use cpu_F0s
> * don't use tcg_gen_ld_f32
>
> Signed-off-by: Peter Maydell
> ---
> target/arm/translate.c | 27 ---
> 1 file changed, 12 insertions(+), 15
On 6/13/19 9:39 AM, Peter Maydell wrote:
> Switch NEON_2RM_VRINT* away from using cpu_F0s.
>
> Signed-off-by: Peter Maydell
> ---
> target/arm/translate.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
Reviewed-by: Richard Henderson
r~
On 6/13/19 9:39 AM, Peter Maydell wrote:
> Switch NEON_2RM_VABS_F away from using cpu_F0s.
>
> Signed-off-by: Peter Maydell
> ---
> target/arm/translate.c | 13 ++---
> 1 file changed, 2 insertions(+), 11 deletions(-)
Reviewed-by: Richard Henderson
r~
On 6/13/19 9:39 AM, Peter Maydell wrote:
> Stop using cpu_F0s for the NEON_2RM_VCVT[ANPM][US] ops.
>
> Signed-off-by: Peter Maydell
> ---
> target/arm/translate.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
Reviewed-by: Richard Henderson
r~
On 6/13/19 9:39 AM, Peter Maydell wrote:
> Where Neon instructions are floating point operations, we
> mostly use the old VFP utility functions like gen_vfp_abs()
> which work on the TCG globals cpu_F0s and cpu_F1s. The
> Neon for-each-element loop conditionally loads the inputs
> into either a
On 6/13/19 9:39 AM, Peter Maydell wrote:
> The AArch32 VMOV (immediate) instruction uses the same VFP encoded
> immediate format we already handle in vfp_expand_imm(). Use that
> function rather than hand-decoding it.
>
> Suggested-by: Richard Henderson
> Signed-off-by: Peter Maydell
> ---
>
On 6/13/19 9:39 AM, Peter Maydell wrote:
> We want to use vfp_expand_imm() in the AArch32 VFP decode;
> move it from the a64-only header/source file to the
> AArch32 one (which is always compiled even for AArch64).
>
> Signed-off-by: Peter Maydell
> ---
> target/arm/translate-a64.h | 1 -
>
On 6/13/19 7:37 AM, Peter Maydell wrote:
> The AArch32 VTRN instruction is specified to give an UNKNOWN
> result if Vd and Vm are the same register; avoid generating
> this in risu output, as we already do for VUZP and VZIP.
>
> Signed-off-by: Peter Maydell
> ---
> Alex: this pattern error is
On 6/13/19 2:31 PM, Max Reitz wrote:
>> @@ -657,71 +644,147 @@ static int connect_to_ssh(BDRVSSHState *s,
>> BlockdevOptionsSsh *opts,
>
> [...]
>
>> +/*
>> + * Try to disable the Nagle algorithm on TCP sockets to reduce latency,
>> + * but do not fail if it cannot be disabled.
>>
On 6/13/19 1:37 PM, Max Reitz wrote:
> Currently, the "thistime" variable is not reinitialized on every loop
> iteration. This leads to tests that do not yield a run time (because
> they failed or were skipped) printing the run time of the previous test
> that did. Fix that by reinitializing
*** This bug is a duplicate of bug 1828495 ***
https://bugs.launchpad.net/bugs/1828495
I'm marking this bug as a duplicate of LP: #1828495 since both are
asking for mitigations pass-through to i386 kvm guests and I'm preparing
a fix for both simultaneously.
** This bug has been marked a
On 07.05.19 22:35, Max Reitz wrote:
> Hi,
>
> This series adds a --salvage option to qemu-img convert. With this,
> qemu-img will not abort when it encounters an I/O error. Instead, it
> tries to narrow it down and will treat the affected sectors as being
> completely 0 (and print a warning).
>
On 28.05.19 21:53, Max Reitz wrote:
> img_rebase() can leak a QDict in two occasions. Fix it.
>
> Coverity: CID 1401416
> Fixes: d16699b64671466b42079c45b89127aeea1ca565
> Fixes: 330c72957196e0ae382abcaa97ebf4eb9bc8574f
> Signed-off-by: Max Reitz
> ---
> qemu-img.c | 3 +++
> 1 file changed, 3
On 03.06.19 22:22, Max Reitz wrote:
> QEMU’s always been confused over what a snapshot is: Is it the overlay?
> Is it the backing image?
>
> Confusion is rarely a good thing. I can’t think of any objective reason
> why the overlay would be a snapshot. A snapshot is something that does
> not
On 12.06.19 15:27, Philippe Mathieu-Daudé wrote:
> Cc'ing Alex (Docker, Travis) and Stefan (MinGW)
[...]
> Note, libssh is not available on MinGW.
Nor is it available for Mingw64:
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=mingw64-x86_64-libssh=x86_64
That makes building for Windows more
Ping
just the final three patches left to review
On 22.05.19 19:03, Max Reitz wrote:
> Hi,
>
> This series is mainly a fix for
> https://bugzilla.redhat.com/show_bug.cgi?id=1703793. The problem
> described there is that mirroring to a gluster volume, then switching
> off the volume makes qemu
Currently, the "thistime" variable is not reinitialized on every loop
iteration. This leads to tests that do not yield a run time (because
they failed or were skipped) printing the run time of the previous test
that did. Fix that by reinitializing "thistime" for every test.
Signed-off-by: Max
On 13.06.19 15:20, Pino Toscano wrote:
> Rewrite the implementation of the ssh block driver to use libssh instead
> of libssh2. The libssh library has various advantages over libssh2:
> - easier API for authentication (for example for using ssh-agent)
> - easier API for known_hosts handling
> -
On 29.05.19 17:46, Vladimir Sementsov-Ogievskiy wrote:
> Drop write notifiers and use filter node instead. Changes:
>
> 1. copy-before-writes now handled by filter node, so, drop all
>is_write_notifier arguments.
>
> 2. we don't have intersecting requests, so their handling is dropped.
>
Hi Everyone,
I'm working on a project that involves building on top of existing QEMU
work, and I'm trying to virtualize I2C devices that are shared between
multiple VMs. I've been reading QEMU documentation and source code to get a
better idea of how to add something like this to QEMU (since it
On 6/13/19 5:12 PM, Laszlo Ersek wrote:
> On 06/06/19 15:31, Laszlo Ersek wrote:
>> Launchpad: https://bugs.launchpad.net/qemu/+bug/1831477
>> Repo: https://github.com/lersek/qemu.git
>> Branch:edk2-stable201905-lp-1831477
>>
>> edk2-stable201905 has been released today; let's update
On May 19, 2019 10:27 PM, "Richard Henderson"
wrote:
>
> Add an empty inline function for each target, and invoke it
> from the proper places.
>
Can we outline the meaning/purpose of the new function here?
This commit message looks horrible.
Regards,
Aleksandar
> Signed-off-by: Richard
Hi Laszlo,
On 3/12/19 5:29 PM, Laszlo Ersek wrote:
> On 03/11/19 01:30, Philippe Mathieu-Daudé wrote:
>> Add a job to build and install the EDK2 platform firmware binaries.
>>
>> This job is only triggered if the last commit matches the EDK2
>> name (case insensitive), or when tag are created
Patchew URL:
https://patchew.org/QEMU/20190613121433.5246-1-peter.mayd...@linaro.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PULL 00/48] target-arm queue
Type: series
Message-id:
On Thu, 13 Jun 2019 at 18:13, Eric Blake wrote:
>
> The following changes since commit 785a602eae7ad97076b9794ebaba072ad4a9f74f:
>
> Merge remote-tracking branch
> 'remotes/kraxel/tags/vga-20190613-pull-request' into staging (2019-06-13
> 13:25:25 +0100)
>
>
QEMU may crash when running a spapr machine in 'dual' interrupt controller
mode on some older (but not that old, eg. ubuntu 18.04.2) KVMs with partial
XIVE support:
qemu-system-ppc64: hw/ppc/spapr_rtas.c:411: spapr_rtas_register:
Assertion `!name || !rtas_table[token].name' failed.
XICS is
This series fixes various issues that can happen when running a spapr
machine on a POWER9 host and KVM doesn't have proper support to destroy
XICS-on-XIVE devices (ie, without the changes at [1]).
Patch 1 and 2 fix a QEMU crash that happens with the default settings, ie.
ic-mode=dual and
Patchew URL:
https://patchew.org/QEMU/20190529154654.95870-1-vsement...@virtuozzo.com/
Hi,
This series failed build test on s390x host. Please find the details below.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing to a
The AArch32 VMOV (immediate) instruction uses the same VFP encoded
immediate format we already handle in vfp_expand_imm(). Use that
function rather than hand-decoding it.
Suggested-by: Richard Henderson
Signed-off-by: Peter Maydell
---
target/arm/translate-vfp.inc.c | 28
Remove some old constructns from NEON_2RM_VCVT_F16_F32 code:
* don't use CPU_F0s
* don't use tcg_gen_st_f32
Signed-off-by: Peter Maydell
---
target/arm/translate.c | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/target/arm/translate.c
Remove some old constructs from NEON_2RM_VCVT_F16_F32 code:
* don't use cpu_F0s
* don't use tcg_gen_ld_f32
Signed-off-by: Peter Maydell
---
target/arm/translate.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/target/arm/translate.c
Remove the now unused TCG globals cpu_F0s, cpu_F0d, cpu_F1s, cpu_F1d.
cpu_M0 is still used by the iwmmxt code, and cpu_V0 and
cpu_V1 are used by both iwmmxt and Neon.
Signed-off-by: Peter Maydell
---
target/arm/translate.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
We want to use vfp_expand_imm() in the AArch32 VFP decode;
move it from the a64-only header/source file to the
AArch32 one (which is always compiled even for AArch64).
Signed-off-by: Peter Maydell
---
target/arm/translate-a64.h | 1 -
target/arm/translate.h | 7 +++
Stop using cpu_F0s for the NEON_2RM_VCVT[ANPM][US] ops.
Signed-off-by: Peter Maydell
---
target/arm/translate.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/target/arm/translate.c b/target/arm/translate.c
index 243dbee8357..124045a9ef6 100644
---
Stop using cpu_F0s in the Neon VCVT fixed-point operations.
Signed-off-by: Peter Maydell
---
target/arm/translate.c | 62 +++---
1 file changed, 28 insertions(+), 34 deletions(-)
diff --git a/target/arm/translate.c b/target/arm/translate.c
index
Switch NEON_2RM_VRINT* away from using cpu_F0s.
Signed-off-by: Peter Maydell
---
target/arm/translate.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/target/arm/translate.c b/target/arm/translate.c
index a006ab498e7..243dbee8357 100644
--- a/target/arm/translate.c
Stop using cpu_F0s for NEON_2RM_VRECPE_F and NEON_2RM_VRSQRTE_F.
Signed-off-by: Peter Maydell
---
target/arm/translate.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/target/arm/translate.c b/target/arm/translate.c
index 124045a9ef6..75ed7cc7cb0 100644
---
On 29.05.19 17:46, Vladimir Sementsov-Ogievskiy wrote:
> From: Vladimir Sementsov-Ogievskiy
>
> Introduce lock/unlock range functionality, based on serialized
> requests. This is needed to refactor backup, dropping local
> tracked-request-like synchronization.
>
> Signed-off-by: Vladimir
Switch NEON_2RM_VABS_F away from using cpu_F0s.
Signed-off-by: Peter Maydell
---
target/arm/translate.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/target/arm/translate.c b/target/arm/translate.c
index a10fded1f39..a006ab498e7 100644
---
Where Neon instructions are floating point operations, we
mostly use the old VFP utility functions like gen_vfp_abs()
which work on the TCG globals cpu_F0s and cpu_F1s. The
Neon for-each-element loop conditionally loads the inputs
into either a plain old TCG temporary for most operations
or into
Le 19/05/2019 à 22:19, Richard Henderson a écrit :
> This value is not, as far as I know, used by any linux software,
> but it is set by the kernel and is part of the ABI.
>
> Signed-off-by: Richard Henderson
> ---
> linux-user/alpha/target_cpu.h | 2 ++
> 1 file changed, 2 insertions(+)
>
>
On 6/13/19 6:24 PM, no-re...@patchew.org wrote:
> === TEST SCRIPT BEGIN ===
> #!/bin/bash
> time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1
> === TEST SCRIPT END ===
> The full log is available at
>
Le 19/05/2019 à 22:19, Richard Henderson a écrit :
> Add an empty inline function for each target, and invoke it
> from the proper places.
>
> Signed-off-by: Richard Henderson
> ---
> linux-user/aarch64/target_cpu.h| 4
> linux-user/alpha/target_cpu.h | 4
>
On 13/06/19 19:15, Philippe Mathieu-Daudé wrote:
>
> On 6/13/19 6:24 PM, no-re...@patchew.org wrote:
>> === TEST SCRIPT BEGIN ===
>> #!/bin/bash
>> time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1
>> === TEST SCRIPT END ===
>
>> The full log is available at
>>
On 13.06.19 18:12, Stefan Hajnoczi wrote:
> On Fri, May 24, 2019 at 07:28:09PM +0200, Max Reitz wrote:
>> Hi,
>>
>> http://lists.nongnu.org/archive/html/qemu-block/2019-05/msg00569.html
>> shows that optimizations affect HDDs and SSDs differently. It would be
>> nice if we could differentiate
Quoting Peter Maydell (2019-06-13 10:29:33)
> On Thu, 13 Jun 2019 at 16:20, Michael Roth wrote:
> >
> > Quoting Peter Maydell (2019-06-10 08:45:45)
> > > The qemu-ga documentation is currently in qemu-ga.texi in
> > > Texinfo format, which we present to the user as:
> > > * a qemu-ga manpage
> >
The XICS-related RTAS calls and hypercalls in QEMU are supposed to be
called only when the KVM in-kernel XICS is in use.
Add some explicit checks to detect that, print an error message and report
an hardware error to the guest.
Signed-off-by: Greg Kurz
---
hw/intc/xics_spapr.c | 46
Patchew URL: https://patchew.org/QEMU/20190613132000.2146-1-ptosc...@redhat.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
time
Le 19/05/2019 à 22:19, Richard Henderson a écrit :
> We will need a target-specific hook for adjusting registers
> in the parent during clone. To avoid confusion, rename the
> one we have to make it clear it affects the child.
>
> Signed-off-by: Richard Henderson
> ---
>
This patchset does a couple of the cleanup/leftover things noted
in the coverletter of the vfp decodetree conversion or discussed
in code review:
* use vfp_expand_imm() for doing the VFP const-immediate
decode, rather than hand-coding it
* get rid of the final uses of cpu_F[01][sd]
cpu_V0,
On 13.06.19 17:28, Vladimir Sementsov-Ogievskiy wrote:
> 13.06.2019 1:09, Max Reitz wrote:
>> Hi,
>>
>> When we introduced filters, we did it a bit casually. Sure, we talked a
>> lot about them before, but that was mostly discussion about where
>> implicit filters should be added to the graph
The edk2-build.sh script set the 'nounset' option:
BASH(1)
set [arg ...]
-u Treat unset variables and parameters other than the
special parameters "@" and "*" as an error when
performing parameter expansion. If expansion is
attempted on an unset
Patchew URL: https://patchew.org/QEMU/20190613153405.24769-1-kw...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190613153405.24769-1-kw...@redhat.com
Subject: [Qemu-devel] [PATCH v3 00/15] monitor: Split monitor.c
Confirmed. The exact failure mode depends on debugging enabled or not.
The test case is "buggy" in the sense that it makes a call to a NULL
function pointer, and the failure happens while trying to translate
the instructions at address 0.
That said, the correct behaviour for QEMU is a SIGSEGV
On Fri, May 24, 2019 at 07:28:09PM +0200, Max Reitz wrote:
> Hi,
>
> http://lists.nongnu.org/archive/html/qemu-block/2019-05/msg00569.html
> shows that optimizations affect HDDs and SSDs differently. It would be
> nice if we could differentiate between the two and then choose to adjust
> our
Patchew URL:
https://patchew.org/QEMU/20190529154654.95870-1-vsement...@virtuozzo.com/
Hi,
This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
On 13.06.19 17:16, Eric Blake wrote:
> On 6/11/19 5:27 AM, Vladimir Sementsov-Ogievskiy wrote:
>> No reason to keep it separate, it differs from others block driver
>> behavior and therefor confuses. Instead of generic
>
> s/therefor/therefore/ (both spellings are valid, but the former looks
>
iotests ./check -qcow2 failed for me today:
191 fail [10:46:04] [10:46:13] 0s (last: 7s)output
mismatch (see 191.out.bad)
--- /home/eblake/qemu/tests/qemu-iotests/191.out2019-05-24
09:27:46.449348997 -0500
+++ /home/eblake/qemu/tests/qemu-iotests/191.out.bad2019-06-13
Older KVMs on POWER9 don't support destroying/recreating a KVM XICS
device, which is required by 'dual' interrupt controller mode. This
causes QEMU to emit a warning when the guest is rebooted and to fall
back on XICS emulation:
qemu-system-ppc64: warning: kernel_irqchip allowed but unavailable:
From: Vladimir Sementsov-Ogievskiy
No reason for keeping driver handlers realization separate from driver
structure. We can get rid of extra header file.
While being here, fix comments style, restore forgotten comments for
NBD_FOREACH_REPLY_CHUNK and nbd_reply_chunk_iter_receive, remove extra
[re-adding the original CCs, why not]
On 13.06.19 16:30, Vladimir Sementsov-Ogievskiy wrote:
> 13.06.2019 17:21, Max Reitz wrote:
>> On 13.06.19 16:19, Vladimir Sementsov-Ogievskiy wrote:
>>> 13.06.2019 1:08, Max Reitz wrote:
If the main loop cancels all block jobs while the block layer is
From: Max Reitz
common.nbd's nbd_server_set_tcp_port() tries to find a free port, and
then uses it for the whole test run. However, this is racy because even
if the port was free at the beginning, there is no guarantee it will
continue to be available. Therefore, 233 currently cannot reliably
Stop using cpu_F0s for the Neon f32/s32 VCVT operations.
Since this is the last user of cpu_F0s in the Neon 2rm-op
loop, we can remove the handling code for it too.
Signed-off-by: Peter Maydell
---
target/arm/translate.c | 82 --
1 file changed, 22
From: Vladimir Sementsov-Ogievskiy
Drop one on failure path (we have errp) and turn two others into trace
points.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Message-Id: <20190611102720.86114-2-vsement...@virtuozzo.com>
Reviewed-by: Eric Blake
Signed-off-by: Eric Blake
---
Commit 3d068aff (3.0) introduced NBD_MAX_BITMAP_EXTENTS as a limit on
how large we would allow a reply to NBD_CMD_BLOCK_STATUS to grow when
it is visiting a qemu:dirty-bitmap: context. Later, commit fb7afc79
(3.1) reused the constant to limit base:allocation context replies,
although the name is
From: Max Reitz
--fork is a bit boring if there is no way to get the child's PID. This
option helps.
Signed-off-by: Max Reitz
Message-Id: <20190508211820.17851-2-mre...@redhat.com>
Signed-off-by: Eric Blake
---
qemu-nbd.texi | 2 ++
qemu-nbd.c| 11 +++
2 files changed, 13
From: Max Reitz
Signed-off-by: Max Reitz
Message-Id: <20190508211820.17851-5-mre...@redhat.com>
Signed-off-by: Eric Blake
---
tests/qemu-iotests/common.rc | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/tests/qemu-iotests/common.rc b/tests/qemu-iotests/common.rc
From: Max Reitz
qemu_nbd_pipe() currently unconditionally reads qemu-nbd's output. That
is not ideal because qemu-nbd may keep stderr open after the parent
process has exited.
Currently, the only user of qemu_nbd_pipe() is 147, which discards the
whole output if the parent process returned
The following changes since commit 785a602eae7ad97076b9794ebaba072ad4a9f74f:
Merge remote-tracking branch 'remotes/kraxel/tags/vga-20190613-pull-request'
into staging (2019-06-13 13:25:25 +0100)
are available in the Git repository at:
https://repo.or.cz/qemu/ericb.git tags/pull-nbd-2019-06
From: Vladimir Sementsov-Ogievskiy
No reason to keep it separate, it differs from others block driver
behavior and therefore confuses. Instead of generic
'state = (State*)bs->opaque' we have to use special helper.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Message-Id:
1 - 100 of 315 matches
Mail list logo
