From: Thomas Huth
The license information in this file is very messy. A short note at
the beginning says GPL first, but the long boilerplate code then
talks about "GNU Lesser General Public License version 2.0". First,
there is no such version of the "GNU Lesser GPL", it only started with
version
From: Marc-André Lureau
If no -name is given, let's use a friendly "QEMU version" server
name. This is sometime exposed on spice client side, for example on
remote-viewer title.
Signed-off-by: Marc-André Lureau
Tested-by: Victor Toso
Message-id: 20190221110703.5775-11-marcandre.lur...@redhat.c
On 02/21/19 20:57, Stephen Checkoway wrote:
>
>
>> On Feb 20, 2019, at 03:55, Laszlo Ersek wrote:
>>
>> I would strongly prefer if the guest-side view wouldn't change at
>> all.
>
> It sounds like sector protection isn't something you want and it's not
> something I currently need so unless tha
qkbd_state_key_event() does that for us.
Fixes: 07333e1ca3 kbd-state: use state tracker for sdl2
Reported-by: BALATON Zoltan
Signed-off-by: Gerd Hoffmann
Tested-by: BALATON Zoltan
Message-id: 20190208072744.10687-1-kra...@redhat.com
---
ui/sdl2-input.c | 3 ---
1 file changed, 3 deletions(-)
From: Marc-André Lureau
This will allow easier subclassing of SpiceChardev, in upcoming
"display: add -display spice-app launching external application"
patch.
Signed-off-by: Marc-André Lureau
Tested-by: Victor Toso
Message-id: 20190221110703.5775-7-marcandre.lur...@redhat.com
Signed-off-by: G
From: Marc-André Lureau
Spice port registration is delayed until the server is started. But
ports created after are not being registered. If the server is already
started, do vmc_register_interface() to register it from
qemu_chr_open_spice_port().
Signed-off-by: Marc-André Lureau
Tested-by: Vic
From: Marc-André Lureau
Passing several -spice options to qemu command line, or calling
several time qemu_opts_set() will ignore all but the first option
list. Since the spice server is a singleton, it makes sense to merge
all the options, the last value being the one taken into account.
This ch
Hi,
We have another seccomp issue with mesa, leading to SIGSYS bad system
call (when running a virgl VM with libvirt for example)
Since commit :
https://gitlab.freedesktop.org/mesa/mesa/commit/d877451b48a59ab0f9a4210fc736f51da5851c9a
(unfortunately, already in f29)
mesa wants to set its thread a
On 02/21/19 21:42, Philippe Mathieu-Daudé wrote:
> Hi Alex,
>
> On 2/21/19 7:48 PM, Alex Bennée wrote:
>> It looks like there was going to be code to check we had some sort of
>> alignment so lets replace it with an actual check. This is a bit more
>> useful than the enigmatic "failed to read the
From: Marc-André Lureau
Most chardev backend handle write() as discarded data if underlying
system is disconnected. For unknown historical reasons, the Spice
backend has "reliable" write: it will wait until the client end is
reconnected to do further successful write().
To decide whether it make
From: Marc-André Lureau
Add a new display backend that will configure Spice to allow a remote
client to control QEMU in a similar fashion as other QEMU display
backend/UI like GTK.
For this to work, it will set up Spice server with a unix socket, and
register a VC chardev that will be exposed as
Hi Heyi,
On 2/22/19 8:34 AM, Heyi Guo wrote:
> Hi Eric,
>
> Can't we still use one single memory map and update the base of every
> entry following VIRT_MEM? So that we don't need to split memory map or
> the enumeration definition, neither do we need to copy a15memmap into
> the extended memmap.
On 02/22/19 08:42, Markus Armbruster wrote:
> Stephen Checkoway writes:
>
>>> On Feb 20, 2019, at 03:55, Laszlo Ersek wrote:
>>>
>>> I would strongly prefer if the guest-side view wouldn't change at all.
>>
>> It sounds like sector protection isn't something you want and it's not
>
> László is
On 02/21/19 21:07, Alex Bennée wrote:
>
> Laszlo Ersek writes:
>
>> On 02/21/19 19:48, Alex Bennée wrote:
>>> It looks like there was going to be code to check we had some sort of
>>> alignment so lets replace it with an actual check. This is a bit more
>>> useful than the enigmatic "failed to r
As we will support vector instructions soon, and vector registers are
stored in 64bit host chunks, let's use cpu_to_be64. Same applies to the
guarded storage control block.
Signed-off-by: David Hildenbrand
---
target/s390x/helper.c | 31 +--
1 file changed, 21 inserti
These are minor preparations for vector instruction support for TCG, also
touching KVM code.
During SIGP STORE ADDITIONAL STATUS we have to properly convert the
endianess. On machine checks, we have to also store the vector registers
into the extended save area.
Both changes are not used by TCG c
If we have vector registers and the designation is not zero, we have
to try to write the vector registers. If the designation is zero or
if storing fails, we must not indicate validity. s390_build_validity_mcic()
automatically already sets validity if the vector instruction facility
is installed.
Convert this to QEMU style.
Signed-off-by: David Hildenbrand
---
target/s390x/helper.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/target/s390x/helper.c b/target/s390x/helper.c
index f3fcf96482..a7edd5df7d 100644
--- a/target/s390x/helper.c
+++ b/target/s390x/help
On Thu, Feb 21, 2019 at 03:37:53PM +0100, Igor Mammedov wrote:
>On Tue, 19 Feb 2019 13:36:57 +0100
>Philippe Mathieu-Daudé wrote:
>
>> On 2/19/19 7:07 AM, Wei Yang wrote:
>> > PCDIMM's realize callback is introduced to do proper setup for NVDIMM.
>> >
>> > Currently the NVDIMM setup task is nvdim
On Thu, Feb 21, 2019 at 03:45:51PM +0100, Igor Mammedov wrote:
>On Tue, 19 Feb 2019 16:08:26 +0800
>Wei Yang wrote:
>
>> Currently we do device realization like below:
>>
>>hotplug_handler_pre_plug()
>>dc->realize()
>>hotplug_handler_plug()
>>
>> Before we do device realization and p
The following changes since commit 2e68b8620637a4ee8c79b5724144b726af1e261b:
Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.0-20190219' into
staging (2019-02-18 16:20:13 +)
are available in the git repository at:
git://git.kraxel.org/qemu tags/vga-20190222-pu
This patch adds EDID support to the family of virtio-gpu devices. It is
turned off by default, use the new edid property to enable it.
Signed-off-by: Gerd Hoffmann
Message-id: 20190221081054.13853-1-kra...@redhat.com
---
include/hw/virtio/virtio-gpu.h | 5 +
hw/display/virtio-gpu-3d.c
From: Marc-André Lureau
Signed-off-by: Marc-André Lureau
Reviewed-by: Christophe Fergeau
Reviewed-by: Philippe Mathieu-Daudé
Message-id: 20190221114330.17968-2-marcandre.lur...@redhat.com
Signed-off-by: Gerd Hoffmann
---
include/hw/virtio/virtio-gpu.h | 1 -
hw/display/virtio-gpu.c|
From: Marc-André Lureau
Now that 2d commands are translated to 3d rendering, qemu must stop
sending 3d updates (from 2d) to Spice as well.
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=1674324
Cc: cferg...@redhat.com
Signed-off-by: Marc-André Lureau
Reviewed-by: Christophe Fergeau
Tested
From: Marc-André Lureau
Signed-off-by: Marc-André Lureau
Reviewed-by: Christophe Fergeau
Reviewed-by: Philippe Mathieu-Daudé
Message-id: 20190221114330.17968-3-marcandre.lur...@redhat.com
Signed-off-by: Gerd Hoffmann
---
include/hw/virtio/virtio-gpu.h | 2 --
hw/display/virtio-gpu.c|
From: Marc-André Lureau
Let's check renderer_blocked instead directly.
Signed-off-by: Marc-André Lureau
Reviewed-by: Christophe Fergeau
Reviewed-by: Philippe Mathieu-Daudé
Message-id: 20190221114330.17968-5-marcandre.lur...@redhat.com
Signed-off-by: Gerd Hoffmann
---
include/hw/virtio/virti
Public bug reported:
Operating system: Ubuntu 18.04.2 LTS
qemu version: 2.11.1, but also reproduced with 3.1.0 (compiled manually).
virsh --version: 4.0.0
Hello,
I am having an issue with migration of UEFI virtual machines. If the
--copy-storage-inc and the --tunnelled libvirt flags are used tog
On 2/21/19 9:03 AM, Peter Xu wrote:
> On Wed, Feb 20, 2019 at 05:06:26PM +0100, Marc-André Lureau wrote:
>> qemu_chr_fe_set_handlers() may switch the context of various
>> sources. In order to prevent dispatch races from different threads,
>> let's acquire or freeze the context, do all the sourc
On 22/02/2019 09.11, David Hildenbrand wrote:
> Convert this to QEMU style.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/target/s390x/helper.c b/target/s390x/helper.c
> index f3fcf96482..a7edd
On Thu, 21 Feb 2019 13:01:40 -0500
"Jason J. Herne" wrote:
> On 2/4/19 6:24 AM, Cornelia Huck wrote:
> > On Tue, 29 Jan 2019 08:29:17 -0500
> > "Jason J. Herne" wrote:
(...)
> >> -#define SCSW_FCTL_CLEAR_FUNC 0x1000
> >> -#define SCSW_FCTL_HALT_FUNC 0x2000
> >> +/* Function Control */
> >> #de
On 2/22/19 7:05 AM, Richard Henderson wrote:
> For priv levels 1 & 2, we were doing so from do_ibranch_priv.
>
> Signed-off-by: Richard Henderson
> ---
> target/hppa/translate.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/target/hppa/translate.c b/target/hppa/t
On Thu, Feb 21, 2019 at 03:45:51PM +0100, Igor Mammedov wrote:
>On Tue, 19 Feb 2019 16:08:26 +0800
>Wei Yang wrote:
>
>> Currently we do device realization like below:
>>
>>hotplug_handler_pre_plug()
>>dc->realize()
>>hotplug_handler_plug()
>>
>> Before we do device realization and p
On 22/02/2019 09.11, David Hildenbrand wrote:
> As we will support vector instructions soon, and vector registers are
> stored in 64bit host chunks, let's use cpu_to_be64. Same applies to the
> guarded storage control block.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.c | 31
On 2/22/19 9:09 AM, Laszlo Ersek wrote:
> On 02/21/19 21:07, Alex Bennée wrote:
>> Laszlo Ersek writes:
>>
>>> On 02/21/19 19:48, Alex Bennée wrote:
It looks like there was going to be code to check we had some sort of
alignment so lets replace it with an actual check. This is a bit more
On Thu, Feb 21, 2019 at 04:03:57PM +0800, Peter Xu wrote:
[...]
> > +static gboolean
> > +main_context_wait_cb(gpointer user_data)
> > +{
> > +struct MainContextWait *w = user_data;
> > +
> > +qemu_mutex_lock(&w->lock);
> > +qemu_cond_signal(&w->cond);
> > +/* wait until switching
Hi
Le ven. 22 févr. 2019 à 09:33, Philippe Mathieu-Daudé a
écrit :
>
>
> On 2/21/19 9:03 AM, Peter Xu wrote:
> > On Wed, Feb 20, 2019 at 05:06:26PM +0100, Marc-André Lureau wrote:
> >> qemu_chr_fe_set_handlers() may switch the context of various
> >> sources. In order to prevent dispatch races f
Alex Bennée writes:
> It looks like there was going to be code to check we had some sort of
> alignment so lets replace it with an actual check. This is a bit more
> useful than the enigmatic "failed to read the initial flash content"
> when we attempt to read the number of bytes the device shoul
On Thu, 14 Feb 2019 15:39:13 +1100
David Gibson wrote:
> The virtio-balloon device's verification of the address given to it by the
> guest has a number of faults:
> * The addresses here are guest physical addresses, which should be
> 'hwaddr' rather than 'ram_addr_t' (the distinction i
On 22/02/2019 09.11, David Hildenbrand wrote:
> If we have vector registers and the designation is not zero, we have
> to try to write the vector registers. If the designation is zero or
> if storing fails, we must not indicate validity. s390_build_validity_mcic()
> automatically already sets valid
On 22/02/19 07:57, Peter Xu wrote:
> On Fri, Feb 22, 2019 at 07:37:02AM +0100, Marc-André Lureau wrote:
>> Hi
>>
>> On Fri, Feb 22, 2019 at 4:14 AM Peter Xu wrote:
>>>
>>> We were pushing the context until right before running the gmainloop.
>>> Now since we have everything unconditionally, we can
Markus Armbruster writes:
> Alex Bennée writes:
>
>> It looks like there was going to be code to check we had some sort of
>> alignment so lets replace it with an actual check. This is a bit more
>> useful than the enigmatic "failed to read the initial flash content"
>> when we attempt to read
On 22/02/19 04:14, Peter Xu wrote:
> And if this patchset can survive... how about running gcontext
> directly in iothread_run()? I believe there could be a bit more
> things to clean but I'll see.
Do you mean instead of aio_poll? The problem is that GMainContext is
quite a bit slower than aio_p
On 22/02/19 07:36, Peter Xu wrote:
> On Fri, Feb 22, 2019 at 07:25:16AM +0100, Marc-André Lureau wrote:
>> Hi
>>
>> On Fri, Feb 22, 2019 at 4:14 AM Peter Xu wrote:
>>>
>>> Only sending an init-done message using lock+cond seems an overkill to
>>> me. Replacing it with a simpler semaphore.
>>>
>>>
Hi Mathieu,
How big is your testuefi-VM_VARS.fd file ? Does the problem go away if you
pad it to 1MB?
I've seen a problem migrating pflash where the files aren't 1MB (?)
multiples but only using the 'old style' block migration; normally you
get an NBD based block migration but when you select
Hi
On Fri, Feb 22, 2019 at 10:33 AM Paolo Bonzini wrote:
>
> On 22/02/19 07:36, Peter Xu wrote:
> > On Fri, Feb 22, 2019 at 07:25:16AM +0100, Marc-André Lureau wrote:
> >> Hi
> >>
> >> On Fri, Feb 22, 2019 at 4:14 AM Peter Xu wrote:
> >>>
> >>> Only sending an init-done message using lock+cond s
On Fri, Feb 22, 2019 at 10:28:57AM +0100, Paolo Bonzini wrote:
> On 22/02/19 04:14, Peter Xu wrote:
> > And if this patchset can survive... how about running gcontext
> > directly in iothread_run()? I believe there could be a bit more
> > things to clean but I'll see.
>
> Do you mean instead of a
On 22/02/2019 03:17, Cleber Rosa wrote:
>
>
> On 2/18/19 4:25 PM, Philippe Mathieu-Daudé wrote:
>> On 2/18/19 9:05 PM, Eric Blake wrote:
>>> [adding Eduardo for some python 2-vs-3 advice]
>>
>> And Cleber.
>>
>>>
>>> On 2/18/19 1:59 PM, Andrey Shinkevich wrote:
To write one byte to disk, P
From: Paolo Bonzini
It fails to install homebrew. Unfortunately we cannot mark
it as an expected failure because Travis does not match
allow_failures rows against include rows (only against the
main test matrix, which we do not use at all), so just disable
it.
Signed-off-by: Paolo Bonzini
Mess
The builds are reaching the magic 50 minute limit with regularity so
lets split them up. Rather than doing a full debug build on both just
enable debug tcg for linux-user.
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
diff --git a/.travis.yml b/.travis.yml
index 866a1872b1..36ed7ec3
From: Thomas Huth
This is very convenient for people like me who store their QEMU git trees
on gitlab.com: Automatic CI pipelines are now run for each branch that is
pushed to the server - useful for some extra-testing before sending PULL-
requests for example. Since the runtime of the jobs is li
We are seeing instability on our CI runs which has been there since
the test was introduced. I suspect it triggers more on Travis due to
their heavy load.
Signed-off-by: Alex Bennée
Acked-by: Thomas Huth
diff --git a/tests/cdrom-test.c b/tests/cdrom-test.c
index 14bd981336..05611da648 100644
--
From: "Dr. David Alan Gilbert"
Commit 315d3184525 turned --disable-uuid into a warning only; remove
the check from Travis.
Signed-off-by: Dr. David Alan Gilbert
Message-Id: <20190215094502.32149-2-dgilb...@redhat.com>
Reviewed-by: Thomas Huth
Signed-off-by: Alex Bennée
diff --git a/.travis.y
The following changes since commit fc3dbb90f2eb069801bfb4cfe9cbc83cf9c5f4a9:
Merge remote-tracking branch 'remotes/jnsnow/tags/bitmaps-pull-request' into
staging (2019-02-21 13:09:33 +)
are available in the Git repository at:
https://github.com/stsquad/qemu.git tags/pull-testing-next-22
Signed-off-by: Alex Bennée
diff --git a/tests/docker/dockerfiles/debian9.docker
b/tests/docker/dockerfiles/debian9.docker
index 154ae2a455..5f23a35404 100644
--- a/tests/docker/dockerfiles/debian9.docker
+++ b/tests/docker/dockerfiles/debian9.docker
@@ -13,8 +13,8 @@ FROM debian:stretch-slim
RU
From: "Dr. David Alan Gilbert"
We've had the build break with replication disabled, so lets
test that case in travis.
Suggsted-by: Alex Bennée
Signed-off-by: Dr. David Alan Gilbert
Message-Id: <20190215094502.32149-1-dgilb...@redhat.com>
Reviewed-by: Thomas Huth
Signed-off-by: Alex Bennée
d
Some operations take a long time and enabling "-l 2 -r all" can take
more than a day which is stretching the definition of a "slow" test.
Lets default to the quick test and leave a note for those who wish to
run by hand.
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
diff --git a/tes
Tracking head is always going to be at the whims of the upstream.
Let's use a defined release so things don't magically change under us.
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
diff --git a/tests/docker/dockerfiles/debian-amd64.docker
b/tests/docker/dockerfiles/debian-amd64.d
On Thu, Feb 21, 2019 at 11:33:04AM +0100, Stefano Garzarella wrote:
> This series adds the support of DISCARD and WRITE_ZEROES commands
> and extends the virtio-blk-test to test these new commands.
>
> v6:
> - fixed patchew failure on patch 8 (do not initialise globals to 0 or NULL)
> - added R-b
Am 21.02.2019 um 20:32 hat Sergio Lopez geschrieben:
> On Thu, Feb 21, 2019 at 12:08:12PM -0600, Eric Blake wrote:
> > On 2/21/19 11:37 AM, Sergio Lopez wrote:
> > > This parameter is analogous to convert's "-C", making use of
> > > bdrv_co_copy_range().
> >
> > The last time I tried to patch 'qem
On Thu, 21 Feb 2019 18:21:11 +0100
Auger Eric wrote:
> Hi Igor,
> On 2/21/19 5:19 PM, Igor Mammedov wrote:
> > On Wed, 20 Feb 2019 23:39:49 +0100
> > Eric Auger wrote:
> >
> >> In the prospect to introduce an extended memory map supporting more
> >> RAM, let's split the memory map array into
On Fri, 22 Feb 2019 09:11:50 +0100
David Hildenbrand wrote:
> These are minor preparations for vector instruction support for TCG, also
> touching KVM code.
>
> During SIGP STORE ADDITIONAL STATUS we have to properly convert the
> endianess. On machine checks, we have to also store the vector re
On Wed, 20 Feb 2019 23:39:50 +0100
Eric Auger wrote:
> On ARM, the kvm_type will be resolved by querying the KVMState.
> Let's add the MachineState handle to the callback so that we
> can retrieve the KVMState handle. in kvm_init, when the callback
> is called, the kvm_state variable is not yet
On Fri, 22 Feb 2019 09:11:53 +0100
David Hildenbrand wrote:
> If we have vector registers and the designation is not zero, we have
> to try to write the vector registers. If the designation is zero or
> if storing fails, we must not indicate validity. s390_build_validity_mcic()
> automatically al
On 22.02.19 11:16, Cornelia Huck wrote:
> On Fri, 22 Feb 2019 09:11:50 +0100
> David Hildenbrand wrote:
>
>> These are minor preparations for vector instruction support for TCG, also
>> touching KVM code.
>>
>> During SIGP STORE ADDITIONAL STATUS we have to properly convert the
>> endianess. On m
Looking through old bug tickets... can you still reproduce this issue
with the latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribe
On Fri, 22 Feb 2019 16:53:55 +0800
Wei Yang wrote:
> On Thu, Feb 21, 2019 at 03:45:51PM +0100, Igor Mammedov wrote:
> >On Tue, 19 Feb 2019 16:08:26 +0800
> >Wei Yang wrote:
> >
> >> Currently we do device realization like below:
> >>
> >>hotplug_handler_pre_plug()
> >>dc->realize()
>
On Wed, 20 Feb 2019 23:39:52 +0100
Eric Auger wrote:
> The machine RAM attributes will need to be analyzed during the
> configure_accelerator() process. especially kvm_type() arm64
> machine callback will use them to know how many IPA/GPA bits are
> needed to model the whole RAM range. So let's a
Hi David,
Thanks you for your help.
The VARS file is 128K.
I increased the "/var/lib/libvirt/qemu/nvram/testuefi_VARS.fd" var file
to 1M, but had this error during migration:
error: internal error: qemu unexpectedly closed the monitor:
2019-02-22T09:52:34.098833Z qemu-system-x86_64: Length mis
Looking through old bug tickets... can you still reproduce this issue
with the latest version of QEMU? Or could we close this ticket nowadays?
If not, can you provide an example for testing?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you a
Are you sure that EHCI handles low-speed devices in that case? I thought that
XHCI is capable of handling low-speed devices instead...
Anyway, QEMU certainly only emulates the EHCI in a traditional way, so if you
want to use low-speed devices here, you also have to specify an UHCI controller
for
Yep that Length mismatch is expected - the source and destination do
have to match.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1817268
Title:
Input/output error during migration
Status in QEMU:
On 22/02/2019 05:49, Gerd Hoffmann wrote:
This patch adds EDID support to the vfio display (aka vgpu) code.
When supported by the mdev driver qemu will generate a EDID blob
and pass it on using the new vfio edid region. The EDID blob will
be updated on UI changes (i.e. window resize), so the gue
On 22/02/2019 05:49, Gerd Hoffmann wrote:
This allows configure the display resolution which the vgpu should use.
"configure" -> "configuration of" or "us to configure" ?
The information will be passed to the guest using EDID, so the mdev
driver must support the vfio edid region for this to w
On 22/02/2019 05:49, Gerd Hoffmann wrote:
Kick the display link up event with a 0.1 sec delay,
so the guest has a chance to notice the link down first.
Signed-off-by: Gerd Hoffmann
Depending on your thoughts on the suggestion in patch 1 regarding a
comment at the 'err' label - another candid
On 22.02.2019 09:11, David Hildenbrand wrote:
> As we will support vector instructions soon, and vector registers are
> stored in 64bit host chunks, let's use cpu_to_be64. Same applies to the
> guarded storage control block.
>
> Signed-off-by: David Hildenbrand
looks sane.
Reviewed-by: Chris
On Thu, 21 Feb 2019 at 18:57, Peter Maydell wrote:
>
> Arm queue -- mostly the first slice of my Musca patches.
>
> thanks
> -- PMM
>
> The following changes since commit fc3dbb90f2eb069801bfb4cfe9cbc83cf9c5f4a9:
>
> Merge remote-tracking branch 'remotes/jnsnow/tags/bitmaps-pull-request'
> into
On 22.02.2019 09:11, David Hildenbrand wrote:
> Convert this to QEMU style.
>
> Signed-off-by: David Hildenbrand
Acked-by: Christian Borntraeger
> ---
> target/s390x/helper.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/target/s390x/helper.c b/target/s3
The data type for bytes in Python3 differs from the one in Python2.
Those cases should be managed separately.
v1:
In the first version, the TypeError in Python3 was handled as the
exception.
Discussed in the e-mail thread with the Message ID:
<1550519997-253534-1-git-send-email-andrey.shinkev...@v
On Thu, Feb 21, 2019 at 03:55:14PM +0100, BALATON Zoltan wrote:
> At least two machines, the PPC mac99 and MIPS fulong2e, have an ATI
> gfx chip by default (Rage 128 Pro and M6/RV100 respectively) and
> guests running on these and the PMON2000 firmware of the fulong2e
> expect this to be available.
After g_source_attach() the GMainContext holds a reference to the
GSource, so the caller does not need to keep it.
qio_task_thread_worker() is not releasing its reference so the GSource
is being leaked since a17536c594bfed94d05667b419f747b692f5fc7f.
Signed-off-by: Alberto Garcia
---
io/task.c |
This works like g_idle_add() but allows specifying a different
GMainContext. It also returns the GSource directly instead of its ID
number for convenience.
qio_task_thread_worker() is modified to make use of this new function.
Signed-off-by: Alberto Garcia
---
include/qemu/main-loop.h | 12
This fixes a race condition in which the tcp_chr_read() ioc handler
can close a connection that is being written to from another thread.
This is essentially v1 rebased on top of the current master, after
Daniel and Marc-André's chardev series have been merged.
Note: vhost-user-test still fails if
There's a race condition in which the tcp_chr_read() ioc handler can
close a connection that is being written to from another thread.
Running iotest 136 in a loop triggers this problem and crashes QEMU.
(gdb) bt
#0 0x5558b842902d in object_get_class (obj=0x0) at qom/object.c:860
#1 0x000
In $SUBJECT s/main-loop/io/
On Fri, Feb 22, 2019 at 01:59:10PM +0200, Alberto Garcia wrote:
> After g_source_attach() the GMainContext holds a reference to the
> GSource, so the caller does not need to keep it.
>
> qio_task_thread_worker() is not releasing its reference so the GSource
> is being
Thanks you, so it is a bug and not the expected behavior right ?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1817268
Title:
Input/output error during migration
Status in QEMU:
New
Bug descrip
On Fri, Feb 22, 2019 at 01:59:11PM +0200, Alberto Garcia wrote:
> This works like g_idle_add() but allows specifying a different
> GMainContext. It also returns the GSource directly instead of its ID
> number for convenience.
>
> qio_task_thread_worker() is modified to make use of this new functio
On Fri, Feb 22, 2019 at 01:59:12PM +0200, Alberto Garcia wrote:
> There's a race condition in which the tcp_chr_read() ioc handler can
> close a connection that is being written to from another thread.
>
> Running iotest 136 in a loop triggers this problem and crashes QEMU.
>
> (gdb) bt
> #0 0
On Fri, Feb 22, 2019 at 01:34:12AM +0100, Philippe Mathieu-Daudé wrote:
> Hi Daniel,
>
> On 2/15/19 4:57 PM, Daniel P. Berrangé wrote:
> > From: "Daniel P. Berrange"
> >
> > Add an authorization backend that talks to PAM to check whether the user
> > identity is allowed. This only uses the PAM a
Alex Bennée writes:
> Markus Armbruster writes:
>
>> Alex Bennée writes:
>>
>>> It looks like there was going to be code to check we had some sort of
>>> alignment so lets replace it with an actual check. This is a bit more
>>> useful than the enigmatic "failed to read the initial flash content
On Fri 22 Feb 2019 01:16:57 PM CET, Daniel P. Berrangé wrote:
> On Fri, Feb 22, 2019 at 01:59:12PM +0200, Alberto Garcia wrote:
>> There's a race condition in which the tcp_chr_read() ioc handler can
>> close a connection that is being written to from another thread.
>>
>> Running iotest 136 in a
On 22/02/19 12:59, Alberto Garcia wrote:
> This fixes a race condition in which the tcp_chr_read() ioc handler
> can close a connection that is being written to from another thread.
>
> This is essentially v1 rebased on top of the current master, after
> Daniel and Marc-André's chardev series have
On 2/13/19 2:32 AM, David Gibson wrote:
> On Tue, Feb 12, 2019 at 08:18:19AM +0100, Cédric Le Goater wrote:
>> On 2/12/19 2:11 AM, David Gibson wrote:
>>> On Mon, Jan 07, 2019 at 07:39:46PM +0100, Cédric Le Goater wrote:
The interrupt mode is chosen by the CAS negotiation process and
acti
Yes, I think so; although old-style block migration doesn't get much
work on it now; so probably the fix I'd recommend for most cases now
would be to pad the var file.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launc
On Wed, 20 Feb 2019 23:39:54 +0100
Eric Auger wrote:
> This patch implements the machine class kvm_type() callback.
> It returns the number of bits requested to implement the whole GPA
> range including the RAM and IO regions located beyond.
> The returned value in passed though the KVM_CREATE_VM
On Wed, 20 Feb 2019 23:39:53 +0100
Eric Auger wrote:
> Up to now the memory map has been static and the high IO region
> base has always been 256GiB.
>
> This patch modifies the virt_set_memmap() function, which freezes
> the memory map, so that the high IO range base becomes floating,
> located
On Thu, 21 Feb 2019 at 18:53, Aleksandar Markovic
wrote:
>
> From: Aleksandar Markovic
>
> Merge remote-tracking branch 'remotes/jnsnow/tags/bitmaps-pull-request'
> into staging (2019-02-21 13:09:33 +)
>
> are available in the git repository at:
>
> https://github.com/AMarkovic/qemu tags
Removing RTAS handlers will become necessary when the new pseries
machine supporting multiple interrupt mode is introduced.
Signed-off-by: Cédric Le Goater
---
include/hw/ppc/spapr.h | 4
hw/ppc/spapr_rtas.c| 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/hw
The activation of the KVM IRQ device depends on the interrupt mode
chosen at CAS time by the machine and some methods used at reset or by
the migration need to be protected.
Signed-off-by: Cédric Le Goater
---
hw/intc/spapr_xive_kvm.c | 28
hw/intc/xics_kvm.c |
All is in place for KVM now. State synchronization and migration will
come next.
Signed-off-by: Cédric Le Goater
---
hw/ppc/spapr_irq.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
index 6e1c36dc62ca..1ad57582a403 100644
--- a/hw/ppc/spapr_i
This introduces a set of helpers when KVM is in use, which create the
KVM XIVE device, initialize the interrupt sources at a KVM level and
connect the interrupt presenters to the vCPU.
They also handle the initialization of the TIMA and the source ESB
memory regions of the controller. These have a
1 - 100 of 375 matches
Mail list logo
