On 11/25/20 2:45 AM, Yutao Ai wrote:
> Delete '#' and use '0x' prefix instead
>
> Signed-off-by: Yutao Ai
> ---
> monitor/misc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Philippe Mathieu-Daudé
On 11/25/20 5:06 AM, Richard Henderson wrote:
> Signed-off-by: Richard Henderson
> ---
> target/arm/translate.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé
On 11/25/20 5:06 AM, Richard Henderson wrote:
> Signed-off-by: Richard Henderson
> ---
> target/arm/translate.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé
Cc'ing Fam directly because his launchpad account
contact points to invalid email address.
On 11/25/20 8:22 AM, Gaoning Pan wrote:
> Public bug reported:
>
> Hello,
>
> I found an assertion failure in hw/scsi/lsi53c895a.c:624
>
> This was found in latest version 5.2.0.
>
>
> my reproduced env
On Wed, Nov 11, 2020 at 12:43:22PM +, Stefan Hajnoczi wrote:
From: Coiby Xu
This test case has the same tests as tests/virtio-blk-test.c except for
tests have block_resize. Since vhost-user server can only server one
client one time, two instances of vhost-user-blk-server are started by
qem
On 24.11.2020 20:57, Dr. David Alan Gilbert wrote:
* Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:
Implemented support for the whole RAM block memory
protection/un-protection. Introduced higher level
ram_write_tracking_start() and ram_write_tracking_stop()
to start/stop tracking guest mem
On Wed, Nov 25, 2020 at 04:20:56PM +0800, Coiby Xu wrote:
On Wed, Nov 11, 2020 at 12:43:22PM +, Stefan Hajnoczi wrote:
From: Coiby Xu
This test case has the same tests as tests/virtio-blk-test.c except for
tests have block_resize. Since vhost-user server can only server one
client one time
set_pci_host_devaddr() is hard to follow, thus bug-prone.
For example, a bug was introduced in commit bccb20c49df, as
the same line might be used to parse a bus (up to 0xff) or
a slot (up to 0x1f).
Instead of making things worst, rewrite using g_strsplit().
Signed-off-by: Philippe Mathieu-Daudé
On Tue, Nov 24, 2020 at 08:17:35PM +0100, David Hildenbrand wrote:
> On 24.11.20 19:11, Jonathan Cameron wrote:
> > On Mon, 9 Nov 2020 20:47:09 +0100
> > David Hildenbrand wrote:
> >
> > +CC Eric based on similar query in other branch of the thread.
> >
> >> On 05.11.20 18:43, Jonathan Cameron w
On 25.11.20 09:38, Andrew Jones wrote:
> On Tue, Nov 24, 2020 at 08:17:35PM +0100, David Hildenbrand wrote:
>> On 24.11.20 19:11, Jonathan Cameron wrote:
>>> On Mon, 9 Nov 2020 20:47:09 +0100
>>> David Hildenbrand wrote:
>>>
>>> +CC Eric based on similar query in other branch of the thread.
>>>
>>
On Tue, Nov 24, 2020 at 5:46 PM Markus Armbruster wrote:
> Yuri Benditovich writes:
>
> > On Tue, Nov 24, 2020 at 3:36 PM Markus Armbruster
> wrote:
> >
> >> Markus Armbruster writes:
> >>
> >> > Yuri Benditovich writes:
> >> >
> >> >> Please confirm that this patch is intended to solve only
On 11/24/20 9:01 PM, Paolo Bonzini wrote:
> On 24/11/20 20:08, Eduardo Habkost wrote:
>>> Not a big advantage I agree,
>>> I think however there is one, in using the existing framework that exists,
>>> for the purposes that it was built for.
>>>
>>> As I understand it, the global module init frame
On 11/24/20 9:13 PM, Paolo Bonzini wrote:
> On 24/11/20 17:22, Claudio Fontana wrote:
>> +static void x86_cpu_accel_init(void)
>> {
>> -X86CPUAccelClass *acc;
>> +const char *ac_name;
>> +ObjectClass *ac;
>> +char *xac_name;
>> +ObjectClass *xac;
>>
>> -acc = X86_CPU_ACCE
On 11/24/20 10:31 PM, Eduardo Habkost wrote:
> On Tue, Nov 24, 2020 at 09:13:13PM +0100, Paolo Bonzini wrote:
>> On 24/11/20 17:22, Claudio Fontana wrote:
>>> +static void x86_cpu_accel_init(void)
>>> {
>>> -X86CPUAccelClass *acc;
>>> +const char *ac_name;
>>> +ObjectClass *ac;
>>> +
* Kirti Wankhede (kwankh...@nvidia.com) wrote:
> Header file where CONFIG_VFIO is defined is not included in migration.c
> file. Include config devices header file in migration.c.
>
> Fixes: 3710586caa5d ("qapi: Add VFIO devices migration stats in Migration
> stats")
>
> Signed-off-by: Kirti Wank
On 25/11/20 10:21, Claudio Fontana wrote:
Hi Paolo,
in RFC v5 , module init for ACCEL_CPU is not conditional anymore, right?
But the fact that its behavior depends on current_accel() still disqualifies it?
It is called right after the accelerator is chosen and initialized
in RFC v5, this still i
On Tue, 24 Nov 2020 18:56:02 +0100
Cédric Le Goater wrote:
[...]
> >
> > I guess you're talking about KVM_DEV_XIVE_NR_SERVERS in
> > kvmppc_xive_connect() actually. We're currently passing
> > spapr_max_server_number() (vCPU id) but you might be
> > right.
> >
> > I need to re-read the story a
On 11/24/20 9:34 PM, Eduardo Habkost wrote:
> On Tue, Nov 24, 2020 at 08:39:33PM +0100, Claudio Fontana wrote:
>> On 11/24/20 8:27 PM, Eduardo Habkost wrote:
>>> On Tue, Nov 24, 2020 at 07:52:15PM +0100, Claudio Fontana wrote:
>>> [...]
>> +}
>
> Additionally, if you call arch_cpu_a
On Tue, Sep 08, 2020 at 05:33:40PM +0200, Martin Wilck wrote:
> On Tue, 2020-09-08 at 10:14 -0400, Michael S. Tsirkin wrote:
> > On Mon, Aug 31, 2020 at 02:37:26PM +0200, Laurent Vivier wrote:
> > > On 28/08/2020 23:34, Martin Wilck wrote:
> > > > On Wed, 2020-08-26 at 08:26 -0400, Michael S. Tsirk
Stephen Long writes:
> Hi Peter,
>
>> (a) what does "fails to load" mean here? In the sample binary
>> I had, we got a SIGSEGV in zero_bss() when it tried to memset()
>> memory that hadn't been mmap()ed. Is that the only failure mode,
>> or can this manifest in other ways too?
>
> Apologies fo
Philippe Mathieu-Daudé writes:
> On 11/24/20 12:04 PM, Claudio Fontana wrote:
>> Hi Alex,
>>
>> I am seeing build failures with build-user and build-user-plugin:
>>
>> https://gitlab.com/hw-claudio/qemu/-/pipelines/220245998
>>
>> and I am trying to start investigating.
>>
>> How do I repro
On Wed, 25 Nov 2020 13:39:47 +1100
David Gibson wrote:
> On Mon, Nov 23, 2020 at 12:51:08PM +0100, Greg Kurz wrote:
> > On Mon, 23 Nov 2020 16:11:30 +1100
> > David Gibson wrote:
> >
> > > On Sat, Nov 21, 2020 at 12:42:03AM +0100, Greg Kurz wrote:
> > > > When it comes to resetting the compat m
CLI -netdev accumulates in option group "netdev".
Before commit 08712fcb85 "net: Track netdevs in NetClientState rather
than QemuOpt", netdev_add added to the option group, and netdev_del
removed from it, both HMP and QMP. Thus, every netdev had a
corresponding QemuOpts in this option group.
Com
This is a regression fix, but the regression is already in 5.0. I
think it's too late for 5.2. If I'm right, then the issue should be
documented in the release notes (I can do that).
Markus Armbruster (1):
net: Fix handling of id in netdev_add and netdev_del
net/net.c | 20 ++
From: Marc-André Lureau
Hi,
libvhost-user is meant to be free of glib dependency, and easily
copyable/reusable outside of QEMU. Clean-up some dependencies that crept in
recently (the one remaining is qemu/atomic.h, from which a subset is used)
v2:
- fix memfd flags argument (spotted by D. Gilbe
From: Marc-André Lureau
Signed-off-by: Marc-André Lureau
Reviewed-by: Dr. David Alan Gilbert
Reviewed-by: Stefan Hajnoczi
---
contrib/libvhost-user/libvhost-user.c | 77 ++-
1 file changed, 40 insertions(+), 37 deletions(-)
diff --git a/contrib/libvhost-user/libvhost-
From: Marc-André Lureau
Undo the damage from commit 5f9ff1eff3 ("libvhost-user: Support tracking
inflight I/O in shared memory") which introduced glib dependency through
osdep.h inclusion.
libvhost-user.c tries to stay free from glib usage.
Use glibc memfd_create directly when available (assume
From: Marc-André Lureau
By making libvhost-user a subproject, check it builds
standalone (without the global QEMU cflags etc).
Note that the library still relies on QEMU include/qemu/atomic.h and
linux_headers/.
Signed-off-by: Marc-André Lureau
---
meson.build
From: Marc-André Lureau
Signed-off-by: Marc-André Lureau
---
contrib/libvhost-user/libvhost-user.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/contrib/libvhost-user/libvhost-user.c
b/contrib/libvhost-user/libvhost-user.c
index 54aabd1878..fab7ca17ee 100644
--- a/con
From: Marc-André Lureau
Signed-off-by: Marc-André Lureau
---
.gitlab-ci.yml | 11 +++
1 file changed, 11 insertions(+)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index d0173e82b1..e517506c35 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -455,6 +455,17 @@ check-dco:
variables
From: Marc-André Lureau
Signed-off-by: Marc-André Lureau
---
contrib/libvhost-user/libvhost-user-glib.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/contrib/libvhost-user/libvhost-user-glib.c
b/contrib/libvhost-user/libvhost-user-glib.c
index 0df2ec9271..efc9d
From: Marc-André Lureau
Do not compile potentially panicking code, instead check memfd API is
present during configure time.
Signed-off-by: Marc-André Lureau
---
subprojects/libvhost-user/libvhost-user.c | 6 --
subprojects/libvhost-user/meson.build | 12
2 files changed,
Didn't make 5.2. Pity. Try again for 6.0, please!
From: Marc-André Lureau
Signed-off-by: Marc-André Lureau
---
subprojects/libvhost-user/link-test.c | 45 +++
subprojects/libvhost-user/meson.build | 4 +++
2 files changed, 49 insertions(+)
create mode 100644 subprojects/libvhost-user/link-test.c
diff --git a/subproje
Yuri Benditovich writes:
> On Tue, Nov 24, 2020 at 5:46 PM Markus Armbruster wrote:
[...]
>> The CLI accumulates -netdev in option group "netdev". It has to, or
>> else -writeconfig doesn't work.
>>
>> Before commit 08712fcb85 "net: Track netdevs in NetClientState rather
>> than QemuOpt", netde
* Andrey Shinkevich (andrey.shinkev...@virtuozzo.com) wrote:
> On 24.11.2020 13:04, Vladimir Sementsov-Ogievskiy wrote:
> > 23.11.2020 18:44, Andrey Shinkevich wrote:
> > > This patch paves the way for the one that follows. The following patch
> > > makes the QMP monitor to read up to 4K from stdin
The fixture->fd is created in fixture_setup() and, likewise, needs to be closed
in fixture_tear_down().
Reported-by: Euler Robot
Signed-off-by: Alex Chen
---
tests/test-qga.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/test-qga.c b/tests/test-qga.c
index c1b173b3cb..eb33264e8e 100
On Wed, Nov 25, 2020 at 2:37 PM Alex Chen wrote:
> The fixture->fd is created in fixture_setup() and, likewise, needs to be
> closed
> in fixture_tear_down().
>
> Reported-by: Euler Robot
> Signed-off-by: Alex Chen
>
Reviewed-by: Marc-André Lureau
---
> tests/test-qga.c | 1 +
> 1 file cha
On 11/25/20 10:30 AM, Paolo Bonzini wrote:
> On 25/11/20 10:21, Claudio Fontana wrote:
>> Hi Paolo,
>>
>> in RFC v5 , module init for ACCEL_CPU is not conditional anymore, right?
>> But the fact that its behavior depends on current_accel() still disqualifies
>> it?
>> It is called right after the
On Wed, Nov 25, 2020 at 09:45:19AM +0100, David Hildenbrand wrote:
> On 25.11.20 09:38, Andrew Jones wrote:
> > On Tue, Nov 24, 2020 at 08:17:35PM +0100, David Hildenbrand wrote:
> >> On 24.11.20 19:11, Jonathan Cameron wrote:
> >>> On Mon, 9 Nov 2020 20:47:09 +0100
> >>> David Hildenbrand wrote:
We need the CCW address on the libvirt side to correctly identify
the disk, so add this information to the GuestDiskAddress on s390x.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1755075
Signed-off-by: Thomas Huth
---
qga/commands-posix.c | 34 ++
qga/qapi
On 25.11.20 11:47, Andrew Jones wrote:
> On Wed, Nov 25, 2020 at 09:45:19AM +0100, David Hildenbrand wrote:
>> On 25.11.20 09:38, Andrew Jones wrote:
>>> On Tue, Nov 24, 2020 at 08:17:35PM +0100, David Hildenbrand wrote:
On 24.11.20 19:11, Jonathan Cameron wrote:
> On Mon, 9 Nov 2020 20:47
>>> This complexifies migration because we have to guess at
>>> post load if we should claim the IPI in KVM or not. The
>>> simple presence of the vCPU isn't enough : we need to
>>> guess if the guest actually configured the IPI or not.
>>
>> The EAT will be transferred from the source and the ca
On 11/25/20 10:32 AM, Claudio Fontana wrote:
> On 11/24/20 9:34 PM, Eduardo Habkost wrote:
>> On Tue, Nov 24, 2020 at 08:39:33PM +0100, Claudio Fontana wrote:
>>> On 11/24/20 8:27 PM, Eduardo Habkost wrote:
On Tue, Nov 24, 2020 at 07:52:15PM +0100, Claudio Fontana wrote:
[...]
>>> +
>From 0b4318c9dbf6fa152ec14eab29837ea06e2d78e5 Mon Sep 17 00:00:00 2001
From: eillon
Date: Wed, 25 Nov 2020 19:17:03 +0800
Subject: [PATCH] x86/cpu: initialize the CPU concurrently
Currently we initialize cpu one by one in qemu_init_vcpu(), every cpu
should have to wait util cpu->created = true.
Hi Alex,
On 11/25/20 10:42 AM, Alex Bennée wrote:
>
> Philippe Mathieu-Daudé writes:
>
>> On 11/24/20 12:04 PM, Claudio Fontana wrote:
>>> Hi Alex,
>>>
>>> I am seeing build failures with build-user and build-user-plugin:
>>>
>>> https://gitlab.com/hw-claudio/qemu/-/pipelines/220245998
>>>
>>>
On Wed, Nov 25, 2020 at 8:09 AM Jason Wang wrote:
>
>
> On 2020/11/21 上午2:50, Eugenio Pérez wrote:
> > This series enable vDPA software assisted live migration for vhost-net
> > devices. This is a new method of vhost devices migration: Instead of
> > relay on vDPA device's dirty logging capability
* Juan Quintela (quint...@redhat.com) wrote:
> If we have a paused guest, it can't unplug the network VF device, so
> we wait there forever. Just change the code to give one error on that
> case.
>
> Signed-off-by: Juan Quintela
Reviewed-by: Dr. David Alan Gilbert
> ---
> migration/migration
On Wed, Nov 18, 2020 at 09:38:24PM +0100, Fabrice Fontaine wrote:
> time element is deprecated on new input_event structure in kernel's
> input.h [1]
>
> This will avoid the following build failure:
>
> hw/input/virtio-input-host.c: In function 'virtio_input_host_handle_status':
> hw/input/virtio
On Wed, Nov 25, 2020 at 1:03 PM Eugenio Perez Martin
wrote:
>
> On Wed, Nov 25, 2020 at 8:09 AM Jason Wang wrote:
> >
> >
> > On 2020/11/21 上午2:50, Eugenio Pérez wrote:
> > > This series enable vDPA software assisted live migration for vhost-net
> > > devices. This is a new method of vhost device
On Wed, 25 Nov 2020 12:34:25 +0100
Cédric Le Goater wrote:
>
> >>> This complexifies migration because we have to guess at
> >>> post load if we should claim the IPI in KVM or not. The
> >>> simple presence of the vCPU isn't enough : we need to
> >>> guess if the guest actually configured the I
Hello Darren, all
+-- On Tue, 24 Nov 2020, Darren Kenny wrote --+
| I always understood triage to be the initial steps in assessing a bug:
|
| - determining if it is a security bug, in this case
| - then deciding on the severity of it
|
| I would not expect triage to include seeing it through t
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1842038
Title:
qemu 4.0/4.1 segfault on live migrate with virtio-scsi iothread
Status in QEMU:
* Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:
> In this particular implementation the same single migration
> thread is responsible for both normal linear dirty page
> migration and procesing UFFD page fault events.
>
> Processing write faults includes reading UFFD file descriptor,
> find
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
On 11/25/20 4:02 AM, Markus Armbruster wrote:
> CLI -netdev accumulates in option group "netdev".
>
> Before commit 08712fcb85 "net: Track netdevs in NetClientState rather
> than QemuOpt", netdev_add added to the option group, and netdev_del
> removed from it, both HMP and QMP. Thus, every netdev
Am I correct to expect the VM to continue successfully, after oom-killer
successfully freed up memory? This journactl does show a calltrace
which includes "vmx_vmexit", and I'm not sure what that function is for
but looks a little worrisome.
** Attachment added: "section or journalctl from host,
Public bug reported:
Host: qemu 5.1.0, linux 5.5.13
Guest: Windows 7 64-bit
This guest ran a memory intensive process, and triggered oom-killer on
host. Luckily, it killed chromium. My understanding is this should
mean qemu should have continued running unharmed. But, the spice
connection show
Hello,
We recently found out that some softwares are effectively crashing
when they detect qemu's `OEM ID` or `OEM table ID` in the ACPI tables.
I see no reason not to expose the setting to the user/command-line. A
previous patch has been submitted in 2015[1] but did not get through
because (if I
On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:
> Hello,
>
> We recently found out that some softwares are effectively crashing
> when they detect qemu's `OEM ID` or `OEM table ID` in the ACPI tables.
>
> I see no reason not to expose the setting to the user/command-line. A
> prev
The issue is not experienced any more.
** Changed in: qemu
Status: Incomplete => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1837218
Title:
qemu segfaults after spice update
+-- On Tue, 15 Sep 2020, P J P wrote --+
| +-- On Tue, 11 Aug 2020, P J P wrote --+
| | * This series asserts that MemoryRegionOps objects define read/write
| | callback methods. Thus avoids potential NULL pointer dereference.
| | ex. ->
https://git.qemu.org/?p=qemu.git;a=commit;h=bb15013ef346
I see two recent hits we have still logs for.
The one described in comment #10
And another but there the error message is a bit different:
on the migration source host:
:
https://6f0be18d925d64906a23-689ad0b9b6f06bc0c51bfb99bf86ea04.ssl.cf5.rackcdn.com/698706/4/check/nova-grenade-multinode/ee2d
This adds a very basic test for checking that we present devices
in a way that Linux can consume: boot with both virtio-net-ccw and
virtio-net-pci attached and then verify that Linux is able to see
and detect these devices.
Signed-off-by: Cornelia Huck
---
A very basic test, but it would have ca
Hello,
On 20-11-24 08:37:14, Klaus Jensen wrote:
> From: Gollu Appalanaidu
>
> Add the Compare command.
>
> This implementation uses a bounce buffer to read in the data from
> storage and then compare with the host supplied buffer.
>
> Signed-off-by: Gollu Appalanaidu
> [k.jensen: rebased]
>
On Nov 25 23:11, Minwoo Im wrote:
> Hello,
>
> On 20-11-24 08:37:14, Klaus Jensen wrote:
> > From: Gollu Appalanaidu
> >
> > Add the Compare command.
> >
> > This implementation uses a bounce buffer to read in the data from
> > storage and then compare with the host supplied buffer.
> >
> > Si
OK, but that still says in both cases here we've got a virtio error
telling us that the queues are broken before migration even starts; so
we should try and figure out why that's happening first.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribe
Hello,
On 20-11-24 08:14:17, Klaus Jensen wrote:
> From: Klaus Jensen
>
> Add new data structures and types for the Simple Copy command.
>
> Signed-off-by: Klaus Jensen
> Cc: Stefan Hajnoczi
> Cc: Fam Zheng
> ---
> include/block/nvme.h | 45 ++--
> 1
On 25.11.2020 16:08, Dr. David Alan Gilbert wrote:
* Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:
In this particular implementation the same single migration
thread is responsible for both normal linear dirty page
migration and procesing UFFD page fault events.
Processing write faults i
On Wednesday, 2020-11-25 at 18:18:56 +0530, P J P wrote:
> Hello Darren, all
>
> +-- On Tue, 24 Nov 2020, Darren Kenny wrote --+
> | I always understood triage to be the initial steps in assessing a bug:
> |
> | - determining if it is a security bug, in this case
> | - then deciding on the sever
On Wed, Nov 25, 2020 at 12:48:22PM +0100, Claudio Fontana wrote:
> On 11/25/20 10:32 AM, Claudio Fontana wrote:
> > On 11/24/20 9:34 PM, Eduardo Habkost wrote:
> >> On Tue, Nov 24, 2020 at 08:39:33PM +0100, Claudio Fontana wrote:
> >>> On 11/24/20 8:27 PM, Eduardo Habkost wrote:
> On Tue, Nov
On Tue, 24 Nov 2020 20:17:35 +0100
David Hildenbrand wrote:
> On 24.11.20 19:11, Jonathan Cameron wrote:
> > On Mon, 9 Nov 2020 20:47:09 +0100
> > David Hildenbrand wrote:
> >
> > +CC Eric based on similar query in other branch of the thread.
> >
> >> On 05.11.20 18:43, Jonathan Cameron wrot
On Wed, Nov 25, 2020 at 07:40:48AM +0100, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > On Tue, Nov 24, 2020 at 04:20:37PM +0100, Markus Armbruster wrote:
> >> Eduardo Habkost writes:
> >>
> >> > On Tue, Nov 24, 2020 at 09:49:30AM +0100, Markus Armbruster wrote:
> >> >> Eduardo Habko
On 25/11/2020 14.58, Cornelia Huck wrote:
> This adds a very basic test for checking that we present devices
> in a way that Linux can consume: boot with both virtio-net-ccw and
> virtio-net-pci attached and then verify that Linux is able to see
> and detect these devices.
Thanks for tackling it!
> Ah. I'd missed that quirk around MAX_ORDER. It's also true of ARM64 with
> 4k pages. As you can probably guess I'd forgotten to recompile my 4k test
> kernel after adding that particular check. :(
>
> Ah well. Given we are already in a situation where adding 2MiB doesn't
> actually
> do anyth
Hi
On Mon, Sep 28, 2020 at 5:49 PM Peter Maydell
wrote:
> On Mon, 28 Sep 2020 at 14:12, Philippe Mathieu-Daudé
> wrote:
> >
> > Since commit efc6c070aca ("configure: Add a test for the
> > minimum compiler version") the minimum compiler version
> > required for GCC is 4.8, which has the GCC BZ#
On Wed, 25 Nov 2020 16:03:13 +0100
Thomas Huth wrote:
> On 25/11/2020 14.58, Cornelia Huck wrote:
> > This adds a very basic test for checking that we present devices
> > in a way that Linux can consume: boot with both virtio-net-ccw and
> > virtio-net-pci attached and then verify that Linux is a
64k guest on 4k host with 512MiB block size seems fine.
If there are any places anyone thinks need particular poking I'd
appreciate a hint :)
>>>
>>> If things seem to work for now, that's great :) Thanks!
>>>
>> Cool. I'll run a few more comprehensive tests then send o
Hi Cornelia,
On 11/25/20 4:03 PM, Thomas Huth wrote:
> On 25/11/2020 14.58, Cornelia Huck wrote:
>> This adds a very basic test for checking that we present devices
>> in a way that Linux can consume: boot with both virtio-net-ccw and
>> virtio-net-pci attached and then verify that Linux is able t
On Wed, Nov 25, 2020 at 01:32:51PM +, Richard W.M. Jones wrote:
> On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:
> > Hello,
> >
> > We recently found out that some softwares are effectively crashing
> > when they detect qemu's `OEM ID` or `OEM table ID` in the ACPI tables.
> >
On Wed, 25 Nov 2020 16:54:53 +0100
David Hildenbrand wrote:
>
> 64k guest on 4k host with 512MiB block size seems fine.
>
> If there are any places anyone thinks need particular poking I'd
> appreciate a hint :)
> >>>
> >>> If things seem to work for now, that's grea
Hi! Did you ever get a backtrace? ... otherwise I think we have to close
this ticket due to insufficient data...
** 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.launch
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
Closing according to comment #3
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1837049
Title:
qemu-system-ppc segfaults with -display sdl
Sta
** Changed in: qemu
Status: Incomplete => New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1826568
Title:
RISC-V Disassembler/translator instruction decoding disagreement
Status in QEMU:
On 25.11.20 17:11, Jonathan Cameron wrote:
> On Wed, 25 Nov 2020 16:54:53 +0100
> David Hildenbrand wrote:
>
>>
>> 64k guest on 4k host with 512MiB block size seems fine.
>>
>> If there are any places anyone thinks need particular poking I'd
>> appreciate a hint :)
>
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
** Changed in: qemu
Status: Incomplete => New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1779447
Title:
SLIRP SMB silently fails with MacOS smbd
Status in QEMU:
New
Bug description:
On Tue 24 Nov 2020 08:44:00 PM CET, Maxim Levitsky wrote:
> On Tue, 2020-11-24 at 20:59 +0200, Maxim Levitsky wrote:
>> On Tue, 2020-11-24 at 19:59 +0100, Alberto Garcia wrote:
>> > On Tue 24 Nov 2020 10:17:23 AM CET, Kevin Wolf wrote:
>> > > We can then continue work to find a minimal reproducer a
On 20-11-13 08:47:59, Markus Armbruster wrote:
> Eric Blake writes:
>
> > On 11/10/20 11:47 PM, Ben Widawsky wrote:
> >> A CXL memory device (AKA Type 3) is a CXL component that contains some
> >> combination of volatile and persistent memory. It also implements the
> >> previously defined mailbo
Claudio Fontana writes:
> Hi Alex,
>
> On 11/25/20 10:42 AM, Alex Bennée wrote:
>>
>> Philippe Mathieu-Daudé writes:
>>
>>> On 11/24/20 12:04 PM, Claudio Fontana wrote:
Hi Alex,
I am seeing build failures with build-user and build-user-plugin:
https://gitlab.com/hw-c
On 11/25/20 6:02 PM, Alex Bennée wrote:
>
> Claudio Fontana writes:
>
>> Hi Alex,
>>
>> On 11/25/20 10:42 AM, Alex Bennée wrote:
>>>
>>> Philippe Mathieu-Daudé writes:
>>>
On 11/24/20 12:04 PM, Claudio Fontana wrote:
> Hi Alex,
>
> I am seeing build failures with build-user and
Setuptools is not needed anymore by the bundled copy of meson,
remove it.
Suggested-by: Thomas Huth
Signed-off-by: Paolo Bonzini
---
.cirrus.yml| 1 -
tests/docker/dockerfiles/debian10.docker | 1 -
tests/docker/dockerfiles/fedora-win32-cross.do
On 25/11/20 05:19, Thomas Huth wrote:
On 24/11/2020 22.19, Olaf Hering wrote:
Since meson.git#0240d760c7699a059cc89e584363c6431cdd2b61 setuptools is not
required anymore.
That commit was part of meson 0.55.1. We require at least meson 0.55.3. So
right, this should be fine.
Signed-off-by: Ol
Hi Steven, Catalin,
On 18/11/2020 16:01, Steven Price wrote:
> On 17/11/2020 16:07, Catalin Marinas wrote:
>> On Mon, Oct 26, 2020 at 03:57:27PM +, Steven Price wrote:
>>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>>> index 19aacc7d64de..38fe25310ca1 100644
>>> --- a/arch/arm64/
On 25/11/2020 18.50, Paolo Bonzini wrote:
> Setuptools is not needed anymore by the bundled copy of meson,
> remove it.
>
> Suggested-by: Thomas Huth
> Signed-off-by: Paolo Bonzini
> ---
> .cirrus.yml| 1 -
> tests/docker/dockerfiles/debian10.docker
On 20-11-17 14:09:14, Jonathan Cameron wrote:
[snip]
>
> Agreed, it was the intermediate state that I wasn't keen on of structures
> defined
> but then given 0 size. I'd rather just look at them all once. If that
> sometimes
> means introducing a file that isn't even referenced for a few pat
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
* Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:
> On 25.11.2020 16:08, Dr. David Alan Gilbert wrote:
> > * Andrey Gruzdev (andrey.gruz...@virtuozzo.com) wrote:
> > > In this particular implementation the same single migration
> > > thread is responsible for both normal linear dirty page
> >
1 - 100 of 169 matches
Mail list logo
