On 2/28/19 6:24 AM, Richard Henderson wrote:
One great big block comment isn't the best way to document
the syntax of a language.
Signed-off-by: Richard Henderson
---
MAINTAINERS | 1 +
docs/devel/decodetree.rst | 156 ++
scripts/decodetre
On 2/28/19 6:24 AM, Richard Henderson wrote:
Cc: Bastian Koppelmann
Signed-off-by: Richard Henderson
---
docs/devel/decodetree.rst | 7 +++
1 file changed, 7 insertions(+)
Reviewed-by: Bastian Koppelmann
Cheers,
Bastian
On 27.02.19 16:53, Richard Henderson wrote:
> On 2/26/19 3:38 AM, David Hildenbrand wrote:
>> To avoid an helper, we have to do the actual calculation of the element
>> address (offset in cpu_env + cpu_env) manually. Factor that out into
>> get_vec_element_ptr_i64(). The same logic will be reused f
On 27.02.19 16:56, Richard Henderson wrote:
> On 2/26/19 3:38 AM, David Hildenbrand wrote:
>> +zero_vec(TMP_VREG_0);
>> +load_vec_element(s, TMP_VREG_0, enr, o->addr1, es);
>> +gen_gvec_mov(get_field(s->fields, v1), TMP_VREG_0);
>
> load into TCGv_i64, zero real dest, store into real d
Hi Yuval,
On 2/27/19 4:06 PM, Yuval Shaia wrote:
Allow interrogating device internals through HMP interface.
The exposed indicators can be used for troubleshooting by developers or
sysadmin.
There is no need to expose these attributes to a management system (e.x.
libvirt) because (1) most of the
В сообщении от Thursday 28 February 2019 08:06:45 Mark Cave-Ayland написал(а):
> On 26/02/2019 22:25, Andrew Randrianasulu wrote:
>
> (adding qemu-ppc, Richard and David - please make sure you add the relevant
> maintainer on bug reports, as otherwise due to the high volume of mails to
> the list i
On 27/02/2019 18.55, no-re...@patchew.org wrote:
> Patchew URL:
> https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
>
> Hi,
>
> This series seems to have some coding style problems. See output below for
> more information:
Fam, Paolo,
Patchew is really going wild
On 27.02.19 17:08, Richard Henderson wrote:
> On 2/26/19 3:38 AM, David Hildenbrand wrote:
>> +void HELPER(vll)(CPUS390XState *env, void *v1, uint64_t addr, uint64_t
>> bytes)
>> +{
>> +S390Vector tmp = {};
>> +int i;
>> +
>> +bytes = MIN(bytes, 16);
>> +for (i = 0; i < bytes; i++)
From: Xie Yongji
The vu_check_queue_msg_file() has checked the FD flag. So let's
delete the redundant check after it.
Signed-off-by: Xie Yongji
Signed-off-by: Zhang Yu
---
contrib/libvhost-user/libvhost-user.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a
From: Xie Yongji
Introduce vu_queue_map_desc() which should be
independent with vu_queue_pop();
Signed-off-by: Xie Yongji
Signed-off-by: Zhang Yu
Reviewed-by: Marc-André Lureau
---
contrib/libvhost-user/libvhost-user.c | 88 ---
1 file changed, 51 insertions(+), 37 de
On 27.02.19 17:02, Richard Henderson wrote:
> On 2/26/19 3:38 AM, David Hildenbrand wrote:
>> Also fairly easy to implement. One issue we have is that exceptions will
>> result in some vectors already being modified. At least handle it
>> consistently per vector by using a temporary vector. Good en
From: Xie Yongji
This patchset is aimed at supporting qemu to reconnect
vhost-user-blk backend after vhost-user-blk backend crash or
restart.
The patch 1 introduces two new messages VHOST_USER_GET_INFLIGHT_FD
and VHOST_USER_SET_INFLIGHT_FD to support transferring shared
buffer between qemu and b
From: Xie Yongji
This patch introduces two new messages VHOST_USER_GET_INFLIGHT_FD
and VHOST_USER_SET_INFLIGHT_FD to support transferring a shared
buffer between qemu and backend.
Firstly, qemu uses VHOST_USER_GET_INFLIGHT_FD to get the
shared buffer from backend. Then qemu should send it back
t
From: Xie Yongji
This patch adds support for vhost-user-blk device to get/set
inflight buffer from/to backend.
Signed-off-by: Xie Yongji
Signed-off-by: Zhang Yu
---
hw/block/vhost-user-blk.c | 28
include/hw/virtio/vhost-user-blk.h | 1 +
2 files changed
On 27.02.19 17:20, Richard Henderson wrote:
> On 2/26/19 3:39 AM, David Hildenbrand wrote:
>> +for (dst_idx = 0; dst_idx < NUM_VEC_ELEMENTS(es); dst_idx++) {
>> +src_idx = dst_idx / 2;
>> +if (!high) {
>> +src_idx += NUM_VEC_ELEMENTS(es) / 2;
>> +}
>> +
From: Xie Yongji
This patch adds support for VHOST_USER_GET_INFLIGHT_FD and
VHOST_USER_SET_INFLIGHT_FD message to set/get shared buffer
to/from qemu. Then backend can track inflight I/O in this buffer.
Signed-off-by: Xie Yongji
Signed-off-by: Zhang Yu
---
Makefile
From: Xie Yongji
Since we now support the message VHOST_USER_GET_INFLIGHT_FD
and VHOST_USER_SET_INFLIGHT_FD. The backend is able to restart
safely because it can track inflight I/O in shared memory.
This patch allows qemu to reconnect the backend after
connection closed.
Signed-off-by: Xie Yongj
Hi Igor,
Thanks for the elaboration. Please find my response inline.
On 02/21/2019 07:42 PM, Igor Mammedov wrote:
On Tue, 19 Feb 2019 14:59:25 +0530
Shivaprasad G Bhat wrote:
On 02/19/2019 01:41 PM, Igor Mammedov wrote:
On Tue, 05 Feb 2019 23:26:27 -0600
Shivaprasad G Bhat wrote:
Add
From: Xie Yongji
This patch enables inflight I/O tracking for
vhost-user-blk backend so that we could restart it safely.
Signed-off-by: Xie Yongji
Signed-off-by: Zhang Yu
---
contrib/vhost-user-blk/vhost-user-blk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/
On Thu, Feb 28, 2019 at 10:35:38AM +0200, Marcel Apfelbaum wrote:
> Hi Yuval,
>
> On 2/27/19 4:06 PM, Yuval Shaia wrote:
> > Allow interrogating device internals through HMP interface.
> > The exposed indicators can be used for troubleshooting by developers or
> > sysadmin.
> > There is no need to
On 28/02/19 09:37, Thomas Huth wrote:
> On 27/02/2019 18.55, no-re...@patchew.org wrote:
>> Patchew URL:
>> https://patchew.org/QEMU/20190222141024.22217-1-kbast...@mail.uni-paderborn.de/
>>
>> Hi,
>>
>> This series seems to have some coding style problems. See output below for
>> more information
On 28.02.19 00:39, Richard Henderson wrote:
> On 2/26/19 3:39 AM, David Hildenbrand wrote:
>> +tmp = tcg_temp_new_i64();
>> +tcg_gen_movi_i64(tmp, data);
>> +gen_gvec_dup_i64(es, get_field(s->fields, v1), tmp);
>> +tcg_temp_free_i64(tmp);
>> +return DISAS_NEXT;
>
> Reuse the du
On Wed, 27 Feb 2019 10:20:12 +1100
David Gibson wrote:
> On Mon, Feb 25, 2019 at 10:26:51AM +0100, Greg Kurz wrote:
> > On Mon, 25 Feb 2019 10:37:11 +1100
> > David Gibson wrote:
> >
> > > On Fri, Feb 22, 2019 at 10:08:22AM +0100, Greg Kurz wrote:
> > > > On Thu, 14 Feb 2019 15:39:13 +1100
On 28.02.19 00:42, Richard Henderson wrote:
> On 2/26/19 3:39 AM, David Hildenbrand wrote:
>> +tcg_gen_not_vec(vece, t, c);
>> +tcg_gen_and_vec(vece, t, t, b);
>
> tcg_gen_andc_vec(t, b, c);
>
>> +tcg_gen_not_i64(t, c);
>> +tcg_gen_and_i64(t, b, t);
>
> Likewise.
>
Changed, tha
On 28.02.19 00:46, Richard Henderson wrote:
> On 2/26/19 3:39 AM, David Hildenbrand wrote:
>> +static DisasJumpType op_vst(DisasContext *s, DisasOps *o)
>> +{
>> +/*
>> + * FIXME: On exceptions we must not modify any memory.
>> + */
>> +store_vec_element(s, get_field(s->fields, v1),
On 28.02.19 00:49, Richard Henderson wrote:
> On 2/26/19 3:39 AM, David Hildenbrand wrote:
>> Very similar to VECTOR LOAD WITH LENGTH, just the opposite direction.
>>
>> Signed-off-by: David Hildenbrand
>> ---
>> target/s390x/helper.h | 1 +
>> target/s390x/insn-data.def | 2 ++
>
On 28/02/19 08:14, Gerd Hoffmann wrote:
> On Thu, Feb 28, 2019 at 08:01:53AM +0100, Thomas Huth wrote:
>> On 28/02/2019 06.00, David Gibson wrote:
>>> On Thu, Feb 28, 2019 at 03:35:03PM +1100, Alexey Kardashevskiy wrote:
The configure script checks multiple times whether it works in a git
The CPUID code will call kvm_arch_get_supported_cpuid() and, even though
it is undef kvm_enabled() so it never runs for user-mode emulators,
sometimes clang will not optimize it out at -O0.
That could be considered a compiler bug, however at -O0 we give it
a pass and just add the stubs.
Reported-
When a bitmap is removed, we can clean some space on the disk. The size
of a cluster may be larger, so is the size of the bitmap that includes
many clusters. Some bitmaps can be as large as tens of megabytes.
The flag QCOW2_DISCARD_ALWAYS allows a call to the raw_co_pdiscard()
that does the actual
On Mon, Feb 25, 2019 at 03:43:34PM +, Frediano Ziglio wrote:
> Instead of using lot of low level function and manually allocate
> the temporary string in audio_process_options use more high
> level GLib function. The function is not used in hot path but to
> read some initial setting.
Added to
On 28.02.19 01:03, Richard Henderson wrote:
> On 2/26/19 3:39 AM, David Hildenbrand wrote:
>> Combine all variant in a single handler. As source and destination
>> have different element sizes, we can't use gvec expansion. Expand
>> manually. Also watch out for overlapping source and destination an
On Mon, 25 Feb 2019 at 15:21, Kevin Wolf wrote:
>
> The following changes since commit 59a568b57848b10e8a44518a889323f12ccdd8f4:
>
> Merge remote-tracking branch
> 'remotes/kraxel/tags/vga-20190222-pull-request' into staging (2019-02-25
> 12:49:07 +)
>
> are available in the Git repository
Hi Igor,
On 2/27/19 6:14 PM, Igor Mammedov wrote:
> On Mon, 28 Jan 2019 11:05:45 +
> Shameer Kolothum wrote:
>
>> pc-dimm memory hotplug is enabled using GPIO(Pin 2) based ACPI
>> event. Hot removal functionality is not yet supported.
>>
>> Signed-off-by: Shameer Kolothum
>> ---
>> hw/arm/
On Mon, 25 Feb 2019 at 13:06, Peter Maydell wrote:
>
> On Mon, 25 Feb 2019 at 12:22, Natanael Copa wrote:
> >
> > On Mon, 25 Feb 2019 10:34:23 +
> > Peter Maydell wrote:
> > > The short term fix is to fix your toolchain/compilation
> > > environment options so that it isn't trying to overrid
On Thu, 28 Feb 2019 at 04:36, Alexey Kardashevskiy wrote:
>
> The configure script checks multiple times whether it works in a git
> repository and it does this by "test -e "${source_path}/.git" in 4 cases
> but in one case where it tries to enable werror "-d" is used there which
> fails on git wo
From: Thomas Huth
The semaphore code was only working with SDL1.2 - with SDL2, it causes
a deadlock. Since we've removed support for SDL1.2 recently, we can
now completely remove the semaphore code from sdlaudio.c.
Signed-off-by: Thomas Huth
Reviewed-by: Philippe Mathieu-Daudé
Message-id: 1549
The following changes since commit 86c7e2f4a93322a76afea5ee6806a83420d1dfea:
Merge remote-tracking branch 'remotes/berrange/tags/authz-core-pull-request'
into staging (2019-02-26 17:59:41 +)
are available in the git repository at:
git://git.kraxel.org/qemu tags/audio-201
From: Thomas Huth
At the end of the while-loop, either "samples" or "sdl->live" is zero, so
now that we've removed the semaphore code, the content of the while-loop
is always only executed once. Thus we can remove the while-loop now to
get rid of one indentation level here.
Signed-off-by: Thomas
From: Frediano Ziglio
audio_calloc uses g_malloc0 which never returns in case of
memory failure.
Signed-off-by: Frediano Ziglio
Message-id: 20190225154335.11397-2-fzig...@redhat.com
Signed-off-by: Gerd Hoffmann
---
audio/audio.c | 48 ++--
1 file ch
In case no sound hardware is present both alsa and sdl drivers
initialize successfully and throw errors later on, i.e. effectively
the automatic probing doesn't work. Drop them from the list of
default audio drivers for linux because of that.
Fixes: 6a48541873 audio: probe audio drivers by defaul
From: Frediano Ziglio
Instead of using lot of low level function and manually allocate
the temporary string in audio_process_options use more high
level GLib function. The function is not used in hot path but to
read some initial setting.
Signed-off-by: Frediano Ziglio
Message-id: 2019022515433
On Fri, Feb 22, 2019 at 05:49:32PM -0500, Bandan Das wrote:
> Fix some coverity issues and a few others pointed out by Peter
>
> Bandan Das (2):
> usb-mtp: return incomplete transfer on a lstat failure
> usb-mtp: fix some usb_mtp_write_data return paths
Series needs a rebase (conflicts with D
Hi Laszlo,
On 2/27/19 9:14 PM, Laszlo Ersek wrote:
> On 02/27/19 13:55, Shameerali Kolothum Thodi wrote:
>> Hi Laszlo,
>>
>>> -Original Message-
>>> From: Shameerali Kolothum Thodi
>>> Sent: 25 February 2019 09:54
>>> To: 'Laszlo Ersek' ; Auger Eric ;
>>> shannon.zha...@gmail.com; peter.ma
27.02.2019 21:45, John Snow wrote:
>
>
> On 2/25/19 10:30 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 25.02.2019 17:18, Vladimir Sementsov-Ogievskiy wrote:
>>> 23.02.2019 3:22, John Snow wrote:
Add an inconsistent bit to dirty-bitmaps that allows us to report a bitmap
as
persistent
28.02.2019 2:48, John Snow wrote:
>
>
> On 2/25/19 11:21 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 23.02.2019 3:22, John Snow wrote:
>>> Set the inconsistent bit on load instead of rejecting such bitmaps.
>>> There is no way to un-set it; the only option is to delete it.
>>>
>>> Obvervations:
>>
@Ubuntu-Desktop Team (now subscribed) - is there a chance we can revert [1] in
mesa before it will be released with Disco for now. That would be needed until
an accepted solution throughout the stack of libvirt/qemu/mesa is found?
Otherwise using GL backed qemu graphics will fail as outlined in t
Thanks Daniel and MarcAndre for chiming in here.
Atfer thinking more about it I agree to Daniel that actually mesa should honor
and stick with its affinity assignment.
For documentation purpose: the solution proposed on the ML is at
https://lists.freedesktop.org/archives/mesa-dev/2019-February/2
On Wed, Feb 27, 2019 at 08:21:40PM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé writes:
>
> > On Wed, Feb 27, 2019 at 07:59:11AM -0600, Eric Blake wrote:
> >> On 2/27/19 5:01 AM, Daniel P. Berrangé wrote:
> >> > On Wed, Feb 27, 2019 at 12:21:32PM +1100, David Gibson wrote:
> >> >> At pres
28.02.2019 12:26, Andrey Shinkevich wrote:
> When a bitmap is removed, we can clean some space on the disk. The size
> of a cluster may be larger, so is the size of the bitmap that includes
> many clusters. Some bitmaps can be as large as tens of megabytes.
> The flag QCOW2_DISCARD_ALWAYS allows a
On Mon, 25 Feb 2019 at 20:32, Max Filippov wrote:
>
> Hi Peter,
>
> please pull the following batch of target/xtensa updates:
>
> The following changes since commit 1c3d45df5e94042d5fb2bb31416072563ab30e49:
>
> Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2019-02-04' into
> staging
On 2/28/19 11:01 AM, Yuval Shaia wrote:
On Thu, Feb 28, 2019 at 10:35:38AM +0200, Marcel Apfelbaum wrote:
Hi Yuval,
On 2/27/19 4:06 PM, Yuval Shaia wrote:
Allow interrogating device internals through HMP interface.
The exposed indicators can be used for troubleshooting by developers or
sysa
On 07/02/19 18:57, Paolo Bonzini wrote:
> diff --git a/default-configs/ppc64-softmmu.mak
> b/default-configs/ppc64-softmmu.mak
> index d642b67..cca5266 100644
> --- a/default-configs/ppc64-softmmu.mak
> +++ b/default-configs/ppc64-softmmu.mak
> @@ -5,11 +5,6 @@ include ppc-softmmu.mak
>
> # For
Hi,
I am having a guest freeze issue (win10), and through debugging I found out
that sometimes sorecvfrom() is called from slirp.c because revents ==
G_IO_IN, however inside sorecvfrom() function, ioctlsocket() returns 0
bytes available and recvfrom could be blocking indefinitely. I am not sure
th
Am 27.02.2019 um 15:44 hat Stefan Hajnoczi geschrieben:
> Test 238 does not require the kvm accelerator. Using the qtest
> accelerator allows the test to run in both non-kvm and non-tcg
> environments.
>
> iotests.VM implicitly uses the qtest accelerator and is really the class
> that this test s
Dr. David Alan Gilbert (git) writes:
> From: "Dr. David Alan Gilbert"
>
> Currently we cleanup the migration object as we exit main after the
> main_loop finishes; however if there's a migration running things
> get messy and we can end up with the migration thread still trying
> to access fre
Adding Timo who maintainers mesa.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1815889
Title:
qemu-system-x86_64 crashed with signal 31 in
__pthread_setaffinity_new()
Status in Mesa:
Unknown
Stefan Hajnoczi writes:
> Test that 32-bit instructions declared UNDEFINED in the ARMv6-M
> Reference Manual really do raise an exception. Also test that the 6
> 32-bit instructions defined in the ARMv6-M Reference Manual do not raise
> an exception.
>
> The Intel HEX (.hex) file is included t
On 28.02.19 10:28, David Hildenbrand wrote:
> On 28.02.19 01:03, Richard Henderson wrote:
>> On 2/26/19 3:39 AM, David Hildenbrand wrote:
>>> Combine all variant in a single handler. As source and destination
>>> have different element sizes, we can't use gvec expansion. Expand
>>> manually. Also w
On 30/01/19 00:52, Luwei Kang wrote:
> Intel Processor Trace required CPUID[0x14] but the cpuid_level
> have no change when create a kvm guest with
> e.g. "-cpu qemu64,+intel-pt".
>
> Signed-off-by: Eduardo Habkost
> Signed-off-by: Luwei Kang
> ---
> hw/i386/pc.c | 1 +
> target/i386/cpu.c
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Thursday, February 28, 2019 7:02 PM
> To: Kang, Luwei ; m...@redhat.com;
> marcel.apfelb...@gmail.com; r...@twiddle.net; ehabk...@redhat.com
> Cc: qemu-devel@nongnu.org
> Subject: Re: [PATCH V2] i386: extende
ull-target-arm-20190228-1
for you to fetch changes up to 1c9af3a9e05c1607a36df4943f8f5393d7621a91:
linux-user: Enable HWCAP_ASIMDFHM, HWCAP_JSCVT (2019-02-28 11:03:05 +)
target-arm queue:
* add MHU and dual-core support to Mu
Currently the Arm arm-powerctl.h APIs allow:
* arm_set_cpu_on(), which powers on a CPU and sets its
initial PC and other startup state
* arm_reset_cpu(), which resets a CPU which is already on
(and fails if the CPU is powered off)
but there is no way to say "power on a CPU as if it had
jus
Implement a model of the Message Handling Unit (MHU) found in
the Arm SSE-200. This is a simple device which just contains
some registers which allow the two cores of the SSE-200
to raise interrupts on each other.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id: 2019021912
Instead of gating the A32/T32 FP16 conversion instructions on
the ARM_FEATURE_VFP_FP16 flag, switch to our new approach of
looking at ID register bits. In this case MVFR1 fields FPHP
and SIMDHP indicate the presence of these insns.
This change doesn't alter behaviour for any of our CPUs.
Signed-o
The iotkit-sysctl device has a register it names INITSVRTOR0.
This is actually a typo present in the IoTKit documentation
and also in part of the SSE-200 documentation: it should be
INITSVTOR0 because it is specifying the initial value of the
Secure VTOR register in the CPU. Correct the typo.
Sig
The SYSCTL block in the SSE-200 has some extra registers that
are not present in the IoTKit version. Add these registers
(as reads-as-written stubs), enabled by a new QOM property.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id: 20190219125808.25174-7-peter.mayd...@linaro
There is a set of VFP instructions which we implement in
disas_vfp_v8_insn() and gate on the ARM_FEATURE_V8 bit.
These were all first introduced in v8 for A-profile, but in
M-profile they appeared in v7M. Gate them on the MVFR2
FPMisc field instead, and rename the function appropriately.
Signed-of
Make the M-profile "init-svtor" property be settable after realize.
This matches the hardware, where this is a config signal which
is sampled on CPU reset and can thus be changed between one
reset and another. To do this we have to change the API we
use to add the property.
(We will need this capa
At the moment the handling of init-svtor and cpuwait initial
values is split between armsse.c and iotkit-sysctl.c:
the code in armsse.c sets the initial state of the CPU
object by setting the init-svtor and start-powered-off
properties, but the iotkit-sysctl.c code has its own
code setting the rese
From: Richard Henderson
Note that float16_to_float32 rightly squashes SNaN to QNaN.
But of course pickNaNMulAdd, for ARM, selects SNaNs first.
So we have to preserve SNaN long enough for the correct NaN
to be selected. Thus float16_to_float32_by_bits.
Signed-off-by: Richard Henderson
Message-i
The CPUWAIT register acts as a sort of power-control: if a bit
in it is 1 then the CPU will have been forced into waiting
when the system was reset (which in QEMU we model as the
CPU starting powered off). Writing a 0 to the register will
allow the CPU to boot (for QEMU, we model this as powering
i
Create and connect the MHUs in the SSE-200.
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Message-id: 20190219125808.25174-3-peter.mayd...@linaro.org
---
include/hw/arm/armsse.h | 3 ++-
hw/arm/armsse.c | 40 ++--
2 files changed, 32 in
From: Richard Henderson
Signed-off-by: Richard Henderson
Message-id: 20190219222952.22183-3-richard.hender...@linaro.org
Reviewed-by: Peter Maydell
Signed-off-by: Peter Maydell
---
target/arm/cpu.h | 5
target/arm/translate-a64.c | 49 +-
2
This reverts commit 823e1b3818f9b10b824ddcd756983b6e2fa68730,
which introduces a regression running EDK2 guest firmware
under KVM:
error: kvm run failed Function not implemented
PC=00013f5a6208 X00=404003c4 X01=003a
X02= X03=404003c4 X04=000
From: Richard Henderson
Signed-off-by: Richard Henderson
Message-id: 20190219222952.22183-4-richard.hender...@linaro.org
Reviewed-by: Peter Maydell
Signed-off-by: Peter Maydell
---
target/arm/cpu.h | 5 ++
target/arm/translate.c | 129 ++---
2 files
Found out that the guest freeze issue is due to a block udp reading call
rather than a deaklock. I have rephase the bug description and sent a
patch in qemu-devel.
** Summary changed:
- deadlock in prepare_mmio_access reading mmio
+ sorecvfrom freezes guest
** Description changed:
QEMU releas
Hi,
On Thu, Feb 28, 2019 at 11:45 AM llyzs wrote:
>
> Hi,
>
> I am having a guest freeze issue (win10), and through debugging I found out
> that sometimes sorecvfrom() is called from slirp.c because revents ==
> G_IO_IN, however inside sorecvfrom() function, ioctlsocket() returns 0
> bytes availa
From: Richard Henderson
Signed-off-by: Richard Henderson
Message-id: 20190219222952.22183-6-richard.hender...@linaro.org
Reviewed-by: Peter Maydell
Signed-off-by: Peter Maydell
---
linux-user/elfload.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/linux-user/elfload.c b/linux-user/elf
From: Richard Henderson
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
Message-id: 20190219222952.22183-5-richard.hender...@linaro.org
Signed-off-by: Peter Maydell
---
target/arm/cpu.c | 1 +
target/arm/cpu64.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/target/arm/c
On Tue, 26 Feb 2019 at 04:53, David Gibson wrote:
>
> The following changes since commit ef80b99ce7ffbd66b3efd493f4ca99f8abf59e79:
>
> Merge remote-tracking branch
> 'remotes/stsquad/tags/pull-testing-next-220219-1' into staging (2019-02-25
> 14:04:20 +)
>
> are available in the Git reposi
Patchew URL:
https://patchew.org/QEMU/20190228110835.16159-1-peter.mayd...@linaro.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190228110835.16159-1-peter.mayd...@linaro.org
Subject: [Qemu-devel] [PULL 00/16] target-arm que
* Peter Xu (pet...@redhat.com) wrote:
> On Wed, Feb 27, 2019 at 04:49:00PM +, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > Currently we cleanup the migration object as we exit main after the
> > main_loop finishes; however if there's a migration running thing
Sometimes sorecvfrom() is called from slirp.c because revents == G_IO_IN,
however inside sorecvfrom() function, ioctlsocket() returns 0 bytes available
and recvfrom could be blocking indefinitely. This adds a non-blocking flag to
recvfrom and checks data availability.
---
slirp/socket.c | 4 +++-
On Thu, Feb 28, 2019 at 11:40:19AM +, Dr. David Alan Gilbert wrote:
> * Peter Xu (pet...@redhat.com) wrote:
> > On Wed, Feb 27, 2019 at 04:49:00PM +, Dr. David Alan Gilbert (git)
> > wrote:
> > > From: "Dr. David Alan Gilbert"
> > >
> > > Currently we cleanup the migration object as we e
On Tue, 26 Feb 2019 at 14:12, Alex Bennée wrote:
>
> The following changes since commit ef80b99ce7ffbd66b3efd493f4ca99f8abf59e79:
>
> Merge remote-tracking branch
> 'remotes/stsquad/tags/pull-testing-next-220219-1' into staging (2019-02-25
> 14:04:20 +)
>
> are available in the Git reposit
> -Original Message-
> From: Auger Eric [mailto:eric.au...@redhat.com]
> Sent: 28 February 2019 10:12
> To: Laszlo Ersek ; Shameerali Kolothum Thodi
> ; shannon.zha...@gmail.com;
> peter.mayd...@linaro.org; imamm...@redhat.com; qemu-devel@nongnu.org;
> qemu-...@nongnu.org
> Cc: xuwei (O)
> -Original Message-
> From: Igor Mammedov [mailto:imamm...@redhat.com]
> Sent: 27 February 2019 16:28
> To: Shameerali Kolothum Thodi
> Cc: eric.au...@redhat.com; shannon.zha...@gmail.com;
> peter.mayd...@linaro.org; qemu-devel@nongnu.org; qemu-...@nongnu.org;
> xuwei (O) ; Linuxarm
>
> -Original Message-
> From: Igor Mammedov [mailto:imamm...@redhat.com]
> Sent: 27 February 2019 17:14
> To: Shameerali Kolothum Thodi
> Cc: eric.au...@redhat.com; shannon.zha...@gmail.com;
> peter.mayd...@linaro.org; qemu-devel@nongnu.org; qemu-...@nongnu.org;
> Linuxarm ; xuwei (O)
>
Hi Peter,
the following changes since commit adf2e451f357e993f173ba9b4176dbf3e65fee7e:
Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging
(2019-02-26 19:04:47 +)
are available in the git repository at:
https://gitlab.com/huth/qemu.git tags/pull-request-2019-02
From: Philippe Mathieu-Daudé
Reviewed-by: Mark Cave-Ayland
Signed-off-by: Philippe Mathieu-Daudé
Signed-off-by: Thomas Huth
---
MAINTAINERS | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8f9f9d7..22e0293 100644
--- a/MAINTAINERS
+++ b/
From: Thomas Huth
The MCF5208EVB supports 2 MiB of flash at address 0. Add support
for this memory region and some code to load the file that can
be specified with the "-bios" command line option.
This can be used for example to load U-Boot images for the
MCF5208EVB (we still lack some features i
From: Philippe Mathieu-Daudé
Nobody is looking at those files, downgrade this subsystem as orphan.
Remove the qemu-devel@nongnu.org entry because the list is always
selected by the 'All patches CC here' section.
Suggested-by: Markus Armbruster
Signed-off-by: Philippe Mathieu-Daudé
Signed-off-
From: Philippe Mathieu-Daudé
Acked-by: Daniel P. Berrangé
Signed-off-by: Philippe Mathieu-Daudé
Signed-off-by: Thomas Huth
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4e38864..d81f9c4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2069
From: Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Thomas Huth
---
MAINTAINERS | 4
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 22e0293..3a034f9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@
Can somebody please pick this up in the near future? (@Eduardo, @MST,
@Paolo, @David - I have no idea who the right person is :) )
The longer we wait, the more likely it is that some stuff gets upstreamed
that conflicts with patch 1 and will break unnoticed. (e.g. spapr PHB
hotplug was just upstre
From: Philippe Mathieu-Daudé
Add Michael, Cornelia and Paolo as maintainers of the Linux subsystem.
Remove the qemu-devel@nongnu.org entry because the list is always
selected by the 'All patches CC here' section.
Suggested-by: Paolo Bonzini
Signed-off-by: Philippe Mathieu-Daudé
Acked-by: Corn
From: Philippe Mathieu-Daudé
Add Richard as maintainer, and Helge as reviewer.
Cc: Richard Henderson
Cc: Helge Deller
Signed-off-by: Philippe Mathieu-Daudé
[thuth: Add the machine entry alphabetically]
Signed-off-by: Thomas Huth
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
From: Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Thomas Huth
Reviewed-by: Markus Armbruster
Signed-off-by: Thomas Huth
---
MAINTAINERS | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3a034f9..4e38864 1006
When unplugging a device, at one point the device will be destroyed
via object_unparent(). This will, one the one hand, unrealize the
removed device hierarchy, and on the other hand, destroy/free the
device hierarchy.
When chaining hotplug handlers, we want to overwrite a bus hotplug
handler by th
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Thu, Feb 28, 2019 at 11:40:19AM +, Dr. David Alan Gilbert wrote:
> > * Peter Xu (pet...@redhat.com) wrote:
> > > On Wed, Feb 27, 2019 at 04:49:00PM +, Dr. David Alan Gilbert (git)
> > > wrote:
> > > > From: "Dr. David Alan Gilbert"
>
1 - 100 of 366 matches
Mail list logo
