The pseries guests do not normally allocate PCI resources and rely on
the system firmware doing so. Furthermore at least at some point in
the past the pseries guests won't even allowed to change BARs, probably
it is still the case for phyp. So since the initial commit we have [1]
which prevents res
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.
Signed-off-by: Wei Yang
---
v2: refine bitmap_set_atomic too, suggested from Peter
---
util/bitmap.c | 9 +++--
1 file changed, 3 insertions(+),
ping?
On 2019/7/16 10:06, l00284672 wrote:
Forwarded Message
Subject:virtio_scsi_ctx_check failed when detach virtio_scsi disk
Date: Mon, 15 Jul 2019 23:34:24 +0800
From: l00284672
To: kw...@redhat.com, be...@igalia.com, Stefan Hajnoczi
, Paolo Bonzini
CC:
Patch 1 refine bitmap_set a little.
Patch 2 add related test case to bitmap_set.
v2:
* refine bitmap_set_atomic
* add a test case
Wei Yang (2):
bitmap: get last word mask from nr directly
test-bitmap: add test for bitmap_set
tests/test-bitmap.c | 33 +
ut
Add a test for bitmap_set. There are three cases:
* Both start and end is BITS_PER_LONG aligned
* Only start is BITS_PER_LONG aligned
* Only end is BITS_PER_LONG aligned
Signed-off-by: Wei Yang
---
tests/test-bitmap.c | 33 +
1 file changed, 33 insertions(+
On 16/07/2019 14:19, Kevin Wolf wrote:
> Am 15.07.2019 um 18:07 hat Andrey Shinkevich geschrieben:
>> The Valgrind tool reports about the uninitialised buffer 'buf'
>> instantiated on the stack of the function guess_disk_lchs().
>> Pass 'read-zeroes=on' to the null block driver to make it determi
On Wed, Jul 17, 2019 at 03:11:14PM +0800, Wei Yang wrote:
> Add a test for bitmap_set. There are three cases:
>
> * Both start and end is BITS_PER_LONG aligned
> * Only start is BITS_PER_LONG aligned
> * Only end is BITS_PER_LONG aligned
>
> Signed-off-by: Wei Yang
Hi, Wei,
Thanks for do
On 16.07.19 19:01, Kevin Wolf wrote:
> Am 03.07.2019 um 19:28 hat Max Reitz geschrieben:
>> BDS.inherits_from does not always point to an immediate parent node.
>> When launching a block job with a filter node, for example, the node
>> directly below the filter will not point to the filter, but kee
On Wed, Jul 17, 2019 at 04:58:06PM +1000, Suraj Jitindar Singh wrote:
> Hi,
>
> I'm trying to use qemu inside a a guest, however since there isn't
> enough entropy for the rng getrandom() blocks. This means I am unable
> to even get output from 'qemu --help' for example. This is annoying at
> best
On Wed, Jul 17, 2019 at 03:43:11PM +0800, Peter Xu wrote:
>On Wed, Jul 17, 2019 at 03:11:14PM +0800, Wei Yang wrote:
>> Add a test for bitmap_set. There are three cases:
>>
>> * Both start and end is BITS_PER_LONG aligned
>> * Only start is BITS_PER_LONG aligned
>> * Only end is BITS_PER_LON
Patchew URL:
https://patchew.org/QEMU/20190716084240.17594-1-marcandre.lur...@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/
On Sat, Jun 29, 2019 at 02:10:28AM +0200, Richard Henderson wrote:
> On 6/28/19 9:27 AM, Andrew Jones wrote:
> > Also, while it's true we can always
> > get the max vq with next-smaller(ARM_MAX_VQ + 1), having it cached in
> > cpu->sve_max_vq is convenient. That said, I think we'd rather keep it.
>
Am 17.07.2019 um 09:47 hat Max Reitz geschrieben:
> On 16.07.19 19:01, Kevin Wolf wrote:
> > Am 03.07.2019 um 19:28 hat Max Reitz geschrieben:
> >> BDS.inherits_from does not always point to an immediate parent node.
> >> When launching a block job with a filter node, for example, the node
> >> dir
Valgrind showed some memory leaks while running qemu-system-ppc64.
Fixing them in this series.
---
Shivaprasad G Bhat (4):
ppc: fix memory leak in spapr_caps_add_properties
ppc: fix memory leak in spapr_dt_drc()
ppc: fix leak in h_client_architecture_support
ppc: dont over
Leaking the drc_name while preparing the DT properties.
Fixing that.
Also, remove the const qualifier from spapr_drc_name().
Signed-off-by: Shivaprasad G Bhat
---
hw/ppc/spapr_drc.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_d
Free all SpaprOptionVector local pointers after use.
Signed-off-by: Shivaprasad G Bhat
---
hw/ppc/spapr_hcall.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 6808d4cda8..71cfe7c41d 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_h
Free the capability name string after setting
the capability.
Signed-off-by: Shivaprasad G Bhat
---
hw/ppc/spapr_caps.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
index bbb001f84a..0263c78d69 100644
--- a/hw/ppc/spapr_caps.
The check to see if the idle_timer is already initialized is
missing. Every vcpu thread would call kvm_arch_init_vcpu()
and overwrite the idle_timer resulting in a memory leak.
Patch fixes that.
Signed-off-by: Shivaprasad G Bhat
---
target/ppc/kvm.c |3 ++-
1 file changed, 2 insertions(+), 1
On 15/07/2019 21:27, Paolo Bonzini wrote:
> On 15/07/19 19:23, Max Reitz wrote:
>> On 12.07.19 21:17, Andrey Shinkevich wrote:
>>> When tcp_chr_disconnect() is called, other thread may be still writing
>>> to the channel. This patch protects only read operations that initiate
>>> the disconnectio
Public bug reported:
I found a problem that virtio_scsi_ctx_check failed when detaching
virtio_scsi disk. The bt is below:
(gdb) bt
#0 0xb02e1bd0 in raise () from /lib64/libc.so.6
#1 0xb02e2f7c in abort () from /lib64/libc.so.6
#2 0xb02db124 in __assert_fail_base ()
On 17/07/2019 04:08, David Gibson wrote:
> On Mon, Jul 15, 2019 at 05:45:38PM +0200, Cédric Le Goater wrote:
>> On 12/07/2019 03:15, David Gibson wrote:
>>> On Wed, Jul 03, 2019 at 07:54:57AM +0200, Cédric Le Goater wrote:
On 03/07/2019 04:07, David Gibson wrote:
> On Sun, Jun 30, 2019 at
On 07/16/19 22:10, Philippe Mathieu-Daudé wrote:
> On 7/16/19 8:42 PM, Laszlo Ersek wrote:
>> On 07/16/19 18:59, Peter Maydell wrote:
>>> On Tue, 16 Jul 2019 at 17:51, Laszlo Ersek wrote:
The issue still reproduces, so it makes sense for me to look at the host
kernel version... Well, I'm
On 16.07.19 18:54, Kevin Wolf wrote:
> Am 15.07.2019 um 12:45 hat Max Reitz geschrieben:
>> If a qcow2 file is preallocated, it can no longer guarantee that it
>> initially appears as filled with zeroes.
>>
>> So implement .bdrv_has_zero_init() by checking whether the file is
>> preallocated; if so
On Fri, Jun 28, 2019 at 05:55:50PM +0200, Auger Eric wrote:
> Hi Drew,
>
> On 6/21/19 6:34 PM, Andrew Jones wrote:
> > Extend the SVE vq map initialization and validation with KVM's
> > supported vector lengths when KVM is enabled. In order to determine
> > and select supported lengths we add two
Am 16.07.2019 um 04:06 hat l00284672 geschrieben:
> Forwarded Message
> Subject: virtio_scsi_ctx_check failed when detach virtio_scsi disk
> Date: Mon, 15 Jul 2019 23:34:24 +0800
> From: l00284672
> To: kw...@redhat.com, be...@igalia.com, Stefan Hajnoczi
>
We are using the wrong functions to set/clear bits, effectively touching
multiple bits, writing out of range of the bitmap, resulting in memory
corruptions. We have to use set_bit()/clear_bit() instead.
Can easily be reproduced by starting a qemu guest on hugetlbfs memory,
inflating the balloon. Q
On Thu, Jul 04, 2019 at 10:20:16AM +, Zhang, Lei wrote:
> Hi Andrew,
>
> This patch series works fine for my use cases.
> Please feel free to add.
>
>Tested-by: Zhang, Lei
Thank you, Lei.
>
> I suppose v3 patches will be released. I'm looking forward to the v3 patches.
I'm starting t
On 16/07/2019 17:24, Paolo Bonzini wrote:
> On 16/07/19 15:08, Andrey Shinkevich wrote:
>> The test check-qtest-x86_64: tests/qos-test hangs with the
>> QTEST_VHOST_USER_FIXME set even without applying the series:
>
> Hmm it must have bitrot. :(( I hope I can look at it on Thursday.
>
> Paolo
On Tue, 16 Jul 2019 14:34:22 -0400
Collin Walling wrote:
> On 7/16/19 11:20 AM, Cornelia Huck wrote:
> > On Wed, 10 Jul 2019 10:20:41 +0200
> > Cornelia Huck wrote:
> >
> >> On Tue, 9 Jul 2019 18:55:34 -0400
> >> Collin Walling wrote:
> >>
> >>> On 7/8/19 9:23 AM, Christian Borntraeger wro
On 17.07.19 10:17, Kevin Wolf wrote:
> Am 17.07.2019 um 09:47 hat Max Reitz geschrieben:
>> On 16.07.19 19:01, Kevin Wolf wrote:
>>> Am 03.07.2019 um 19:28 hat Max Reitz geschrieben:
BDS.inherits_from does not always point to an immediate parent node.
When launching a block job with a fil
* Alex Williamson (alex.william...@redhat.com) wrote:
> On Tue, 9 Jul 2019 15:19:11 +0530
> Kirti Wankhede wrote:
>
> > These functions save and restore PCI device specific data - config
> > space of PCI device.
> > Tested save and restore with MSI and MSIX type.
> >
> > Signed-off-by: Kirti Wan
On 17/07/19 03:13, Wei Yang wrote:
> On Tue, May 14, 2019 at 03:21:08PM +0100, Dr. David Alan Gilbert wrote:
>> * Wei Yang (richardw.y...@linux.intel.com) wrote:
>>> Since start of cpu_physical_memory_sync_dirty_bitmap is always 0, we can
>>> remove this parameter and simplify the calculation a bit
On 30/04/19 05:44, Wei Yang wrote:
> RAMBlock->offset is calculated by find_ram_offset, which makes sure the
> offset is aligned to a word.
>
> This patch removes the alignment check on offset and unnecessary
> variable *word*.
>
> Signed-off-by: Wei Yang
I would add an assertion instead, but o
On 07/17/19 10:36, Laszlo Ersek wrote:
> On 07/16/19 22:10, Philippe Mathieu-Daudé wrote:
>> On 7/16/19 8:42 PM, Laszlo Ersek wrote:
>>> On 07/16/19 18:59, Peter Maydell wrote:
On Tue, 16 Jul 2019 at 17:51, Laszlo Ersek
wrote:
> The issue still reproduces, so it makes sense for me to
On 07/17/19 11:22, Laszlo Ersek wrote:
> On 07/17/19 10:36, Laszlo Ersek wrote:
>> On 07/16/19 22:10, Philippe Mathieu-Daudé wrote:
>>> On 7/16/19 8:42 PM, Laszlo Ersek wrote:
On 07/16/19 18:59, Peter Maydell wrote:
> On Tue, 16 Jul 2019 at 17:51, Laszlo Ersek
> wrote:
>> The issu
On Thu, Jun 27, 2019 at 04:02:24PM +0100, Dave Martin wrote:
> Either way, it's entirely reasonable for userspace not to try to support
> additional slices for now. We'll have plenty of time to plan away
> across that bridge when we spot it on the horizon...
Which makes me inclined to keep the ge
On 17.07.19 10:54, Cornelia Huck wrote:
> On Tue, 16 Jul 2019 14:34:22 -0400
> Collin Walling wrote:
>
>> On 7/16/19 11:20 AM, Cornelia Huck wrote:
>>> On Wed, 10 Jul 2019 10:20:41 +0200
>>> Cornelia Huck wrote:
>>>
On Tue, 9 Jul 2019 18:55:34 -0400
Collin Walling wrote:
On Wed, Jun 26, 2019 at 05:22:34PM +0200, Richard Henderson wrote:
> On 6/21/19 6:34 PM, Andrew Jones wrote:
> > +/*
> > + * If ARM_MAX_VQ is increased to be greater than 16, then we can no
> > + * longer hard code slices to 1 in kvm_arch_put/get_sve().
> > + */
> > +QEMU_BUILD_BUG_ON(ARM_MAX_VQ >
On 16/07/2019 17.37, Max Reitz wrote:
> On 16.07.19 14:28, Thomas Huth wrote:
>> People often forget to run the iotests before submitting patches or pull
>> requests - this is likely due to the fact that we do not run the tests
>> during our mandatory "make check" tests yet. Now that we've got a pr
David Gibson writes:
> On Tue, Jul 16, 2019 at 01:13:52PM +0100, Alex Bennée wrote:
>> The opcode decode tables aren't really part of the CPUPPCState but an
>> internal implementation detail for the translator. This can cause
>> problems with memcpy in cpu_copy as any table created during
>> pp
On 17/07/19 02:46, elohi...@gmail.com wrote:
> From: Xie Yongji
>
> This avoids memory leak when device hotplug is failed.
>
> Signed-off-by: Xie Yongji
> ---
> hw/scsi/vhost-user-scsi.c | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/hw/scsi/vhost-u
On 16/07/19 23:44, Mark Kanda wrote:
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index a8bafdb8b9..dacbf7a9fe 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -2838,7 +2838,6 @@ static PropValue kvm_default_props[] = {
> { "kvm-asyncpf", "on" },
> { "kvm-steal-ti
I reproduce it on qemu4.0.0 version again. The bt is below:
(gdb) bt
#0 0x86aacbd0 in raise () from /lib64/libc.so.6
#1 0x86aadf7c in abort () from /lib64/libc.so.6
#2 0x86aa6124 in __assert_fail_base () from /lib64/libc.so.6
#3 0x86aa61a4 in __assert_fail ()
From: Xie Yongji
This avoids memory leak when device hotplug is failed.
Signed-off-by: Xie Yongji
Message-Id: <20190717004606.12444-2-xieyon...@baidu.com>
Signed-off-by: Paolo Bonzini
---
hw/scsi/vhost-user-scsi.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff -
On 16.07.19 18:58, John Snow wrote:
>
>
> On 7/16/19 8:04 AM, Max Reitz wrote:
>> On 16.07.19 02:01, John Snow wrote:
>>> Signed-off-by: John Snow
>>> ---
>>> tests/qemu-iotests/257 | 41 +-
>>> tests/qemu-iotests/257.out | 3089
>>> 2 files changed, 3
The argument is not used and passing it clutters error propagation in the
callers. So, get rid of it.
Signed-off-by: Paolo Bonzini
---
hw/scsi/vhost-scsi.c| 2 +-
hw/scsi/vhost-user-scsi.c | 2 +-
hw/scsi/virtio-scsi.c | 4 ++--
include/hw/virtio/virtio-scsi.h | 2 +-
On Wed, Jul 17, 2019 at 10:42:55AM +0200, David Hildenbrand wrote:
> We are using the wrong functions to set/clear bits, effectively touching
> multiple bits, writing out of range of the bitmap, resulting in memory
> corruptions. We have to use set_bit()/clear_bit() instead.
>
> Can easily be repr
On 17.07.19 11:57, Michael S. Tsirkin wrote:
> On Wed, Jul 17, 2019 at 10:42:55AM +0200, David Hildenbrand wrote:
>> We are using the wrong functions to set/clear bits, effectively touching
>> multiple bits, writing out of range of the bitmap, resulting in memory
>> corruptions. We have to use set_
Le 14/07/2019 à 18:19, John Paul Adrian Glaubitz a écrit :
> Hi!
>
>> On Jul 14, 2019, at 3:40 PM, Laurent Vivier wrote:
>>
>> Add --preserve-arg0 in qemu-binfmt-conf.sh to configure the preserve-arg0
>> flag.
>>
>> Now, if QEMU is started with -0 or QEMU_ARGV0 and an empty parameter
>> argv[0] (
On 17/07/19 08:06, tony.ngu...@bt.com wrote:
> +
> +static inline MemOp MEMOP(unsigned size)
> +{
> +switch (size) {
> +case 1:
> +return MO_8;
> +case 2:
> +return MO_16;
> +case 4:
> +return MO_32;
> +case 8:
> +return MO_64;
> +default:
> +
On 17/07/19 07:57, tony.ngu...@bt.com wrote:
> This patchset implements the IE (Invert Endian) bit in SPARCv9 MMU TTE.
>
> It is an attempt of the instructions outlined by Richard Henderson to Mark
> Cave-Ayland.
>
> Tested with OpenBSD on sun4u. Solaris 10 is my actual goal, but unfortunately
>
On Mon, Jun 24, 2019 at 10:13:04AM +0100, Stefan Hajnoczi wrote:
> The vhost-user specification does not explain when
> VHOST_USER_PROTOCOL_F_MQ must be implemented. This may lead
> implementors of vhost-user masters to believe that this protocol feature
> is required for any device that has multi
On 17/07/2019 07:39, Nicholas Piggin wrote:
> H_PROD is added, and H_CEDE is modified to test the prod bit
> according to PAPR.
>
> Signed-off-by: Nicholas Piggin
> ---
> hw/ppc/spapr_hcall.c | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/hw/ppc/spapr_hc
On 17.07.19 12:04, David Hildenbrand wrote:
> On 17.07.19 11:57, Michael S. Tsirkin wrote:
>> On Wed, Jul 17, 2019 at 10:42:55AM +0200, David Hildenbrand wrote:
>>> We are using the wrong functions to set/clear bits, effectively touching
>>> multiple bits, writing out of range of the bitmap, result
Hi, I'm a bit worried that this patch might have been forgotten.
Is it queued? Thanks!
14.06.2019, 19:56, "Dr. David Alan Gilbert" :
> * Yury Kotov (yury-ko...@yandex-team.ru) wrote:
>> Currently, there is no information about error if outgoing migration was
>> failed
>> because of file channel
On Wed, 17 Jul 2019 17:06:36 +1000
Alexey Kardashevskiy wrote:
> The pseries guests do not normally allocate PCI resources and rely on
> the system firmware doing so. Furthermore at least at some point in
> the past the pseries guests won't even allowed to change BARs, probably
> it is still the
We are using the wrong functions to set/clear bits, effectively touching
multiple bits, writing out of range of the bitmap, resulting in memory
corruptions. We have to use set_bit()/clear_bit() instead.
Can easily be reproduced by starting a qemu guest on hugetlbfs memory,
inflating the balloon. Q
On Wed, Jul 17, 2019 at 11:14:53AM +0100, Stefan Hajnoczi wrote:
> On Mon, Jun 24, 2019 at 10:13:04AM +0100, Stefan Hajnoczi wrote:
> > The vhost-user specification does not explain when
> > VHOST_USER_PROTOCOL_F_MQ must be implemented. This may lead
> > implementors of vhost-user masters to belie
Some v4.1 (also v4.0 stable) fixes for virtio-balloon that only trigger
when the pagesize is > BALLOON_PAGE_SIZE (4k).
v1 -> v2:
- Added "virtio-balloon: fix memory leak on unrealize()"
- Added "virtio-balloon: reset pbp on device resets"
Cc: Stefan Hajnoczi
Cc: David Gibson
Cc: Michael S. Tsir
When a guest reboots (ordinary reboots, but also via kexec), it will
happily reuse any system memory, including previously inflated memory.
We could have tracking data for a pbp (PartiallyBalloonedPage). It could
happen that a new inflation request from the guest will result in a
discard of such a
On Mon, Jun 24, 2019 at 05:02:00AM -0400, Igor Mammedov wrote:
> QEMU will crash when device-memory-region-size property is read if
> ms->device_memory
> wasn't initialized yet.
>
> Crash can be reproduced with:
> $QEMU -preconfig -qmp unix:qmp_socket,server,nowait &
> ./scripts/qmp/qom-get -s
We could have tracking data for a pbp (PartiallyBalloonedPage)
allocated. Let's free it.
Fixes: ed48c59875b6 ("virtio-balloon: Safely handle BALLOON_PAGE_SIZE <
host page size")
Cc: qemu-sta...@nongnu.org #v4.0.0
Cc: Stefan Hajnoczi
Cc: David Gibson
Cc: Michael S. Tsirkin
C
On Wed, 17 Jul 2019 03:19:43 -0500
Shivaprasad G Bhat wrote:
> Free the capability name string after setting
> the capability.
>
> Signed-off-by: Shivaprasad G Bhat
> ---
Reviewed-by: Greg Kurz
> hw/ppc/spapr_caps.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --g
On Wed, 17 Jul 2019 03:20:01 -0500
Shivaprasad G Bhat wrote:
> Leaking the drc_name while preparing the DT properties.
> Fixing that.
>
> Also, remove the const qualifier from spapr_drc_name().
>
> Signed-off-by: Shivaprasad G Bhat
> ---
> hw/ppc/spapr_drc.c |7 +--
> 1 file changed,
On Wed, Jul 17, 2019 at 12:35:50PM +0200, David Hildenbrand wrote:
> When a guest reboots (ordinary reboots, but also via kexec), it will
> happily reuse any system memory, including previously inflated memory.
>
> We could have tracking data for a pbp (PartiallyBalloonedPage). It could
> happen t
On Wed, 17 Jul 2019 03:20:31 -0500
Shivaprasad G Bhat wrote:
> Free all SpaprOptionVector local pointers after use.
>
> Signed-off-by: Shivaprasad G Bhat
> ---
Reviewed-by: Greg Kurz
> hw/ppc/spapr_hcall.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/hw/ppc/spapr_hcall.c b
On Wed, Jun 12, 2019 at 10:11:57AM +0800, Tiwei Bie wrote:
> On Tue, Jun 11, 2019 at 10:10:14AM -0400, Michael S. Tsirkin wrote:
> > On Tue, Jun 11, 2019 at 02:51:37PM +0800, Tiwei Bie wrote:
> > > The VIRTIO_NET_F_CTRL_VLAN feature requires the support of
> > > vhost-user backend. But it will be a
Cédric Le Goater's on July 17, 2019 8:16 pm:
> On 17/07/2019 07:39, Nicholas Piggin wrote:
>> H_PROD is added, and H_CEDE is modified to test the prod bit
>> according to PAPR.
>>
>> Signed-off-by: Nicholas Piggin
>> ---
>> hw/ppc/spapr_hcall.c | 29 +
>> 1 file chang
On 17.07.19 12:48, Michael S. Tsirkin wrote:
> On Wed, Jul 17, 2019 at 12:35:50PM +0200, David Hildenbrand wrote:
>> When a guest reboots (ordinary reboots, but also via kexec), it will
>> happily reuse any system memory, including previously inflated memory.
>>
>> We could have tracking data for a
On Wed, Jul 17, 2019 at 12:17:57PM +0200, David Hildenbrand wrote:
> On 17.07.19 12:04, David Hildenbrand wrote:
> > On 17.07.19 11:57, Michael S. Tsirkin wrote:
> >> On Wed, Jul 17, 2019 at 10:42:55AM +0200, David Hildenbrand wrote:
> >>> We are using the wrong functions to set/clear bits, effecti
On Wed, Jul 17, 2019 at 10:42:55AM +0200, David Hildenbrand wrote:
> We are using the wrong functions to set/clear bits, effectively touching
> multiple bits, writing out of range of the bitmap, resulting in memory
> corruptions. We have to use set_bit()/clear_bit() instead.
>
> Can easily be repr
On 17.07.19 13:06, Michael S. Tsirkin wrote:
> On Wed, Jul 17, 2019 at 12:17:57PM +0200, David Hildenbrand wrote:
>> On 17.07.19 12:04, David Hildenbrand wrote:
>>> On 17.07.19 11:57, Michael S. Tsirkin wrote:
On Wed, Jul 17, 2019 at 10:42:55AM +0200, David Hildenbrand wrote:
> We are usin
On 17.07.19 13:10, Michael S. Tsirkin wrote:
> On Wed, Jul 17, 2019 at 10:42:55AM +0200, David Hildenbrand wrote:
>> We are using the wrong functions to set/clear bits, effectively touching
>> multiple bits, writing out of range of the bitmap, resulting in memory
>> corruptions. We have to use set_
The regular expressions in the "check" script currently expect that there
is always a space after the test number in the group file, so you can't
have a test in there without a group unless the line still ends with a
space - which is quite error prone since some editors might remove spaces
at the e
People often forget to run the iotests before submitting patches or pull
requests - this is likely due to the fact that we do not run the tests
during our mandatory "make check" tests yet. Now that we've got a proper
"auto" group of iotests that should be fine to run in every environment,
we can en
Let's enable the block iotests during "make check" again, to avoid that
they get broken so easily by accident (like we've seen many times in the
past).
v3:
- Added dependency for "check-block" so that the *-softmmu targets are
now built first
- Added 197 and 215 back to gitlab-ci.yml (there i
Since most iotests are now run during "make check" already, we do not
need to test them explicitly from the gitlab-ci.yml script anymore.
And while we're at it, add some of the new non-auto tests >= 246 instead.
Signed-off-by: Thomas Huth
---
.gitlab-ci.yml | 13 -
1 file changed, 4
Remove some more tests from the "auto" group that either have issues
in certain environments (like macOS or FreeBSD, or on certain file systems
like ZFS or tmpfs), do not work with the qcow2 format, or that are simply
taking too much time.
Reviewed-by: Max Reitz
Signed-off-by: Thomas Huth
---
t
On 17/07/19 12:37, Michael S. Tsirkin wrote:
> On Mon, Jun 24, 2019 at 05:02:00AM -0400, Igor Mammedov wrote:
>> QEMU will crash when device-memory-region-size property is read if
>> ms->device_memory
>> wasn't initialized yet.
>>
>> Crash can be reproduced with:
>> $QEMU -preconfig -qmp unix:qmp
On Wed, Jul 17, 2019 at 01:10:21PM +0200, David Hildenbrand wrote:
> On 17.07.19 13:06, Michael S. Tsirkin wrote:
> > On Wed, Jul 17, 2019 at 12:17:57PM +0200, David Hildenbrand wrote:
> >> On 17.07.19 12:04, David Hildenbrand wrote:
> >>> On 17.07.19 11:57, Michael S. Tsirkin wrote:
> On Wed,
On Wed, Jul 17, 2019 at 01:22:27PM +0200, Paolo Bonzini wrote:
> On 17/07/19 12:37, Michael S. Tsirkin wrote:
> > On Mon, Jun 24, 2019 at 05:02:00AM -0400, Igor Mammedov wrote:
> >> QEMU will crash when device-memory-region-size property is read if
> >> ms->device_memory
> >> wasn't initialized ye
On 17.07.19 13:22, Michael S. Tsirkin wrote:
> On Wed, Jul 17, 2019 at 01:10:21PM +0200, David Hildenbrand wrote:
>> On 17.07.19 13:06, Michael S. Tsirkin wrote:
>>> On Wed, Jul 17, 2019 at 12:17:57PM +0200, David Hildenbrand wrote:
On 17.07.19 12:04, David Hildenbrand wrote:
> On 17.07.19
On Wed, Jul 17, 2019 at 01:06:29PM +0200, David Hildenbrand wrote:
> On 17.07.19 12:48, Michael S. Tsirkin wrote:
> > On Wed, Jul 17, 2019 at 12:35:50PM +0200, David Hildenbrand wrote:
> >> When a guest reboots (ordinary reboots, but also via kexec), it will
> >> happily reuse any system memory, in
On 17.07.19 13:29, Michael S. Tsirkin wrote:
> On Wed, Jul 17, 2019 at 01:06:29PM +0200, David Hildenbrand wrote:
>> On 17.07.19 12:48, Michael S. Tsirkin wrote:
>>> On Wed, Jul 17, 2019 at 12:35:50PM +0200, David Hildenbrand wrote:
When a guest reboots (ordinary reboots, but also via kexec),
On Wed, Jul 17, 2019 at 01:28:19PM +0200, David Hildenbrand wrote:
> On 17.07.19 13:22, Michael S. Tsirkin wrote:
> > On Wed, Jul 17, 2019 at 01:10:21PM +0200, David Hildenbrand wrote:
> >> On 17.07.19 13:06, Michael S. Tsirkin wrote:
> >>> On Wed, Jul 17, 2019 at 12:17:57PM +0200, David Hildenbran
On 08/07/2019 09.24, Marc-André Lureau wrote:
> Modify the behaviour of qtest_quit() to check against the expected
> exit status value. The default remains 0.
>
> Signed-off-by: Marc-André Lureau
> ---
> tests/libqtest.c | 41 ++---
> tests/libqtest.h | 9 +++
On Tue, 16 Jul 2019 14:56:32 -0600
Alex Williamson wrote:
> On Tue, 9 Jul 2019 15:19:08 +0530
> Kirti Wankhede wrote:
> > diff --git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h
> > index 24f505199f83..6696a4600545 100644
> > --- a/linux-headers/linux/vfio.h
> > +++ b/linux-headers
Am 17.07.2019 um 11:07 hat Max Reitz geschrieben:
> On 17.07.19 10:17, Kevin Wolf wrote:
> > Am 17.07.2019 um 09:47 hat Max Reitz geschrieben:
> >> On 16.07.19 19:01, Kevin Wolf wrote:
> >>> Am 03.07.2019 um 19:28 hat Max Reitz geschrieben:
> BDS.inherits_from does not always point to an immed
Patchew URL:
https://patchew.org/QEMU/20190716121352.302-1-alex.ben...@linaro.org/
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
ma
Hi Phil,
On 07/17/19 00:15, Philippe Mathieu-Daudé wrote:
> Hello it's me again, insisting with this series because there are at
> least 2 different report of guests bricked on reset due to the bug
> fixed by patch #5:
> https://bugzilla.redhat.com/show_bug.cgi?id=1678713
> https://bugzilla.redhat
On 2019/7/17 下午7:00, Michael S. Tsirkin wrote:
On Wed, Jun 12, 2019 at 10:11:57AM +0800, Tiwei Bie wrote:
On Tue, Jun 11, 2019 at 10:10:14AM -0400, Michael S. Tsirkin wrote:
On Tue, Jun 11, 2019 at 02:51:37PM +0800, Tiwei Bie wrote:
The VIRTIO_NET_F_CTRL_VLAN feature requires the support of
在 2019/7/17 下午1:53, David Gibson 写道:
On Wed, Jul 17, 2019 at 10:33:00AM +0800, Fei Li wrote:
From: Fei Li
qemu_thread_create() abort()s on error. Not nice. Give it a return
value and an Error ** argument, so it can return success/failure.
Considering qemu_thread_create() is quite widely use
FWIW, I've got a new iotest failure with current master branch:
$ ./check -qed 141
QEMU --
"/tmp/qemu/tests/qemu-iotests/../../x86_64-softmmu/qemu-system-x86_64"
-nodefaults -machine accel=qtest
QEMU_IMG -- "/tmp/qemu/tests/qemu-iotests/../../qemu-img"
QEMU_IO -- "/tmp/qemu/
On 17.07.19 14:35, Thomas Huth wrote:
> FWIW, I've got a new iotest failure with current master branch:
>
> $ ./check -qed 141
> QEMU --
> "/tmp/qemu/tests/qemu-iotests/../../x86_64-softmmu/qemu-system-x86_64"
> -nodefaults -machine accel=qtest
> QEMU_IMG -- "/tmp/qemu/tests/qemu-i
On 07/17/19 11:22, Laszlo Ersek wrote:
> because, (A --> B) === (!A --> !B)
Obviously, it is impossible for me to write an email containing logical
formulae without at least one *crucial* typo.
The correct form of the above equivalence is:
(A --> B) === (!B --> !A)
This typo does not affect
On 17/07/2019 07:39, Nicholas Piggin wrote:
> Implement cpu_exec_enter/exit on ppc which calls into new methods of
> the same name in PPCVirtualHypervisorClass. These are used by spapr
> to implement these splpar elements, used in subsequent changes.
>
> Signed-off-by: Nicholas Piggin
This is ni
Thomas Huth writes:
> Let's enable the block iotests during "make check" again, to avoid that
> they get broken so easily by accident (like we've seen many times in the
> past).
Queued to testing/next, thanks.
>
> v3:
> - Added dependency for "check-block" so that the *-softmmu targets are
>
On 7/17/19 5:27 AM, Christian Borntraeger wrote:
On 17.07.19 10:54, Cornelia Huck wrote:
On Tue, 16 Jul 2019 14:34:22 -0400
Collin Walling wrote:
On 7/16/19 11:20 AM, Cornelia Huck wrote:
On Wed, 10 Jul 2019 10:20:41 +0200
Cornelia Huck wrote:
On Tue, 9 Jul 2019 18:55:34 -0400
Collin
On 07/17/19 11:22, Laszlo Ersek wrote:
> On 07/17/19 10:36, Laszlo Ersek wrote:
>> -assert(no_aa32 || cpu_isar_feature(arm_div, cpu));
>> +assert(!no_aa32 || !cpu_isar_feature(arm_div, cpu));
BTW this can be pronounced in natural language as follows: "we either
have aa32 support,
On 7/16/19 11:04 AM, Thomas Huth wrote:
On 16/07/2019 15.06, Markus Armbruster wrote:
Paolo Bonzini writes:
On 15/07/19 18:12, Cornelia Huck wrote:
Is it INTx vs. MSI vs. MSI-X?
I think for s390x we need (INTx || MSI) vs MSI-X...
I think MSI vs MSI-X is just how it's configured, not the
1 - 100 of 246 matches
Mail list logo
