Stack trace w/o debug symbols:
#0 0x55b7d9f96a49 address_space_dispatch_free (qemu-system-x86_64)
#1 0x55b7d9ff1169 n/a (qemu-system-x86_64)
#2 0x55b7da40126c n/a (qemu-system-x86_64)
#3 0x55b7da3ef121 n/a (qemu-system-x86_64)
#4 0x7f257e69e57f start_thread (libpthread.so.
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf
> Of David Gibson
> Sent: Wednesday, July 17, 2019 11:07 AM
> To: Liu, Yi L
> Subject: Re: [RFC v1 05/18] vfio/pci: add pasid alloc/free implementation
>
> On Tue, Jul 16, 2019 at 10:25:55AM +, Liu, Yi L wrote:
> >
On Fri, Jul 19, 2019 at 06:52:24PM +, Oleinik, Alexander wrote:
> Virtual devices should not try to send zero-sized packets. The caller
> should check the size prior to calling qemu_sendv_packet_async.
>
> Signed-off-by: Alexander Oleinik
> ---
> net/net.c | 3 +++
> 1 file changed, 3 insert
On Fri, Jul 19, 2019 at 06:52:30PM +, Oleinik, Alexander wrote:
> virtio_net_flush_tx does not check that the packet size is nonzero,
> which causes q->aysnc_tx.elem to be set. Then, when the device is reset, there
> is an assertion failure since q->aysnc_tx.elem must be flushed/cleared.
> Zero
On Fri, Jul 19, 2019 at 03:21:15PM +, Oleinik, Alexander wrote:
> While fuzzing the virtio-net tx vq, I ran into an assertion failure due
> to iov_copy offsets larger than the total iov size. Though there is
> a check to cover this, it does not execute when !n->has_vnet_hdr. This
> change alway
On Fri, Jul 19, 2019 at 03:21:15PM +, Oleinik, Alexander wrote:
> While fuzzing the virtio-net tx vq, I ran into an assertion failure due
> to iov_copy offsets larger than the total iov size. Though there is
> a check to cover this, it does not execute when !n->has_vnet_hdr. This
> change alway
Richard Henderson writes:
> About half of this patch set is cleanup of the qemu tlb handling
> leading up to the actual implementation of VHE, and the biggest
> piece of that: The EL2&0 translation regime.
>
> Testing so far has been limited to booting a debian 9 system with
> a 4.9 kernel, and
On 22.07.19 05:04, David Gibson wrote:
> On Fri, Jul 19, 2019 at 06:01:20PM +0200, David Hildenbrand wrote:
>> Using the address of a RAMBlock to test for a matching pbp is not really
>> safe. Instead, let's use the guest physical address of the base page
>> along with the page size (via the number
It is not reasonable to continue when version_id mismatch.
Signed-off-by: Wei Yang
---
migration/ram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/migration/ram.c b/migration/ram.c
index 7e34c82a72..6bfdfae16e 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -4216,7
Two cleanup for ram_load:
* return -EINVAL for version_id mismatch
* extract ram_load_precopy for better readability
Wei Yang (2):
migration: return -EINVAL directly when version_id mismatch
migration: extract ram_load_precopy
migration/ram.c | 73 +++
After cleanup, it would be clear to audience there are two cases
ram_load:
* precopy
* postcopy
And it is not necessary to check postcopy_running on each iteration for
precopy.
Signed-off-by: Wei Yang
---
migration/ram.c | 73 +++--
1 file change
On Mon, Jul 22, 2019 at 09:43:43AM +0200, David Hildenbrand wrote:
> On 22.07.19 05:04, David Gibson wrote:
> > On Fri, Jul 19, 2019 at 06:01:20PM +0200, David Hildenbrand wrote:
> >> Using the address of a RAMBlock to test for a matching pbp is not really
> >> safe. Instead, let's use the guest ph
On Fri, Jul 12, 2019 at 03:14:03AM +0800, Kirti Wankhede wrote:
>
>
> On 7/11/2019 5:43 PM, Dr. David Alan Gilbert wrote:
> > * Kirti Wankhede (kwankh...@nvidia.com) wrote:
> >> VM state change handler gets called on change in VM's state. This is used
> >> to set
> >> VFIO device state to _RUNNI
On Tue, Jul 09, 2019 at 05:49:15PM +0800, Kirti Wankhede wrote:
> Define flags to be used as delimeter in migration file stream.
> Added .save_setup and .save_cleanup functions. Mapped & unmapped migration
> region from these functions at source during saving or pre-copy phase.
> Set VFIO device st
On Tue, Jul 09, 2019 at 05:49:18PM +0800, Kirti Wankhede wrote:
> Dirty page tracking (.log_sync) is part of RAM copying state, where
> vendor driver provides the bitmap of pages which are dirtied by vendor
> driver through migration region and as part of RAM copy, those pages
> gets copied to file
On Tue, Jul 09, 2019 at 05:49:13PM +0800, Kirti Wankhede wrote:
> VM state change handler gets called on change in VM's state. This is used to
> set
> VFIO device state to _RUNNING.
> VM state change handler, migration state change handler and log_sync listener
> are called asynchronously, which s
On Fri, Jul 19, 2019 at 03:21:15PM +, Oleinik, Alexander wrote:
> While fuzzing the virtio-net tx vq, I ran into an assertion failure due
> to iov_copy offsets larger than the total iov size. Though there is
> a check to cover this, it does not execute when !n->has_vnet_hdr. This
> change alway
On Sun, Jul 21, 2019 at 09:15:07PM +0300, Maxim Levitsky wrote:
> Currently if you attampt to create too large file with luks you
> get the following error message:
>
> Formatting 'test.luks', fmt=luks size=17592186044416 key-secret=sec0
> qemu-img: test.luks: Could not resize file: File too large
On Sun, 21 Jul 2019 at 17:39, Stefan Weil wrote:
> Peter, is this fall through for ARM correct?
>
> https://github.com/qemu/qemu/blob/master/target/arm/helper.c#L7958
>
> It looks rather suspicious and is one of the remaining related compiler
> warnings.
It's wrong, and Philippe posted a patch fo
On Fri, 19 Jul 2019 at 14:43, Kevin Wolf wrote:
>
> The following changes since commit 0274f45bdef73283f2c213610f11d4e5dcba43b6:
>
> Merge remote-tracking branch
> 'remotes/vivier2/tags/linux-user-for-4.1-pull-request' into staging
> (2019-07-19 09:44:43 +0100)
>
> are available in the Git rep
On Sun, Jul 21, 2019 at 09:15:08PM +0300, Maxim Levitsky wrote:
> Currently we print message like that:
>
> "
> new_file.qcow2 : error message
> "
>
> However the error could have come from opening the backing file (e.g when it
> missing encryption keys),
> thus try to clarify this by using this
Hi Thomas.
where should I specify this command?
On Sun, Jul 21, 2019 at 10:13 AM Thomas Huth wrote:
> On 19/07/2019 15.26, Philippe Mathieu-Daudé wrote:
> > On 7/19/19 10:26 AM, Michael Rolnik wrote:
> [...]
> >> diff --git a/tests/boot-serial-test.c b/tests/boot-serial-test.c
> >> index 24852d4
Hi Philippe,
Le 7/20/19 à 11:50 AM, Philippe Mathieu-Daudé a écrit :
Cc'ing Stefan
On 7/20/19 11:44 AM, Philippe Mathieu-Daudé wrote:
Hi Frederic,
On 7/20/19 8:18 AM, KONRAD Frederic wrote:
There are some debug trace appearing when using GDB with the HTIF mapped @0:
Invalid htif read: addr
Alex Bennée writes:
> Richard Henderson writes:
>
>> About half of this patch set is cleanup of the qemu tlb handling
>> leading up to the actual implementation of VHE, and the biggest
>> piece of that: The EL2&0 translation regime.
>>
>> Testing so far has been limited to booting a debian 9 s
Hi Michael,
On 22/07/2019 11.16, Michael Rolnik wrote:
> Hi Thomas.
> where should I specify this command?
In patch 6/8, you introduced the error message:
if (bytes_loaded < 0) {
error_report(
"Unable to load %s as ELF, trying again as raw binary",
Am 21.07.2019 um 20:15 hat Maxim Levitsky geschrieben:
> Currently we print message like that:
>
> "
> new_file.qcow2 : error message
> "
>
> However the error could have come from opening the backing file (e.g when it
> missing encryption keys),
> thus try to clarify this by using this format:
On Fri, Jul 19, 2019 at 03:21:15PM +, Oleinik, Alexander wrote:
> While fuzzing the virtio-net tx vq, I ran into an assertion failure due
> to iov_copy offsets larger than the total iov size. Though there is
> a check to cover this, it does not execute when !n->has_vnet_hdr. This
> change alway
On Thu, Jul 18, 2019 at 07:00:37AM +0200, Philippe Mathieu-Daudé wrote:
> Cc'ing qemu-block@
>
> On 7/18/19 5:25 AM, no-re...@patchew.org wrote:
> > Patchew URL:
> > https://patchew.org/QEMU/20190717094728.31006-1-pbonz...@redhat.com/
> [...]> time make docker-test-debug@fedora TARGET_LIST=x86_64
> On 22 Jul 2019, at 7:00, Jan Kiszka wrote:
>
> Writing the nested state e.g. after a vmport access can invalidate
> important parts of the kernel-internal state, and it is not needed as
> well. So leave this out from KVM_PUT_RUNTIME_STATE.
>
> Suggested-by: Paolo Bonzini
> Signed-off-by: J
On Fri, Jul 19, 2019 at 03:21:15PM +, Oleinik, Alexander wrote:
> While fuzzing the virtio-net tx vq, I ran into an assertion failure due
> to iov_copy offsets larger than the total iov size. Though there is
> a check to cover this, it does not execute when !n->has_vnet_hdr. This
> change alway
On Mon, 2019-07-22 at 11:41 +0200, Kevin Wolf wrote:
> Am 21.07.2019 um 20:15 hat Maxim Levitsky geschrieben:
> > Currently we print message like that:
> >
> > "
> > new_file.qcow2 : error message
> > "
> >
> > However the error could have come from opening the backing file (e.g when
> > it miss
Richard Henderson writes:
> Although we can't do much with ASIDs except remember them, this
> will allow cleanups within target/ that should make things clearer.
>
> Signed-off-by: Richard Henderson
>
> ---
> v2: Assert cpu_is_self; only flush idx w/ asid mismatch.
> ---
> include/exec/cpu-al
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> So here's my understanding: "-rtc base=" says what is the RTC value
> when the guest starts. This value is only used by qemu_get_timedate,
> and most RTCs only use it on startup or reset. However, there are
> exceptions (the PC RTC's host clock noti
On Mon, 2019-07-22 at 10:15 +0100, Daniel P. Berrangé wrote:
> On Sun, Jul 21, 2019 at 09:15:08PM +0300, Maxim Levitsky wrote:
> > Currently we print message like that:
> >
> > "
> > new_file.qcow2 : error message
> > "
> >
> > However the error could have come from opening the backing file (e.g
Richard Henderson writes:
> Since we have remembered ASIDs, we can further minimize flushing
> by comparing against the one we want to flush.
>
> Signed-off-by: Richard Henderson
> ---
> include/exec/exec-all.h | 16 +
> include/qom/cpu.h | 1 +
> accel/tcg/cputlb.c |
On 19/07/2019 20:20, Eric Blake wrote:
> We've had two separate reports of different callers running into use
> of uninitialized data if s->quit is set (one detected by gcc -O3,
> another by valgrind), due to checking 'nbd_reply_is_simple(reply) ||
> s->quit' in the wrong order. Rather than chasi
On 22.07.19 11:44, Liran Alon wrote:
>
>
>> On 22 Jul 2019, at 7:00, Jan Kiszka wrote:
>>
>> Writing the nested state e.g. after a vmport access can invalidate
>> important parts of the kernel-internal state, and it is not needed as
>> well. So leave this out from KVM_PUT_RUNTIME_STATE.
>>
>> Su
> On 22 Jul 2019, at 13:20, Jan Kiszka wrote:
>
> On 22.07.19 11:44, Liran Alon wrote:
>>
>>
>>> On 22 Jul 2019, at 7:00, Jan Kiszka wrote:
>>>
>>> Writing the nested state e.g. after a vmport access can invalidate
>>> important parts of the kernel-internal state, and it is not needed as
>
On 22.07.19 12:31, Liran Alon wrote:
>> On 22 Jul 2019, at 13:20, Jan Kiszka wrote:
>>
>> On 22.07.19 11:44, Liran Alon wrote:
>>>
>>>
On 22 Jul 2019, at 7:00, Jan Kiszka wrote:
Writing the nested state e.g. after a vmport access can invalidate
important parts of the kernel-in
On Thu, 18 Jul 2019 at 14:17, Peter Maydell wrote:
>
> If configure detects that it's being run on a source tree which
> is missing git modules, it prints an error messages suggesting
> that the user downloads a correct source archive from the project
> website. However https://www.qemu.org/downlo
On 7/20/19 3:00 AM, no-re...@patchew.org wrote:
> Patchew URL: https://patchew.org/QEMU/20190719185158.20316-1-alx...@bu.edu/
>
> PASS 18 test-bdrv-drain /bdrv-drain/iothread/drain_all
> =
> ==8150==ERROR: AddressSanitizer: heap-use-a
Hi Tony,
On 7/22/19 5:27 AM, tony.ngu...@bt.com wrote:
> Move the define of target access alignment earlier from
> target/foo/cpu.h to configure.
>
You missed:
Suggested-by: Richard Henderson
> Signed-off-by: Tony Nguyen
The single change from your v1 is:
- target_bigendian=yes
+ target_
On Thu, Jul 18, 2019 at 01:54:10PM +0200, Cédric Le Goater wrote:
> When the 's' bit is set the escalation is said to be 'silent' or
> 'silent/gather'. In such configuration, the notification sequence is
> skipped and only the escalation sequence is performed. This is used to
> configure all the EQ
On Thu, Jul 18, 2019 at 03:03:09PM +0200, Cédric Le Goater wrote:
> On 18/07/2019 08:16, David Gibson wrote:
> > On Thu, Jul 18, 2019 at 03:12:17PM +0930, Joel Stanley wrote:
> >> Currently we fail to boot a qemu powernv machine with a Power9
> >> processor:
> >>
> >> PLAT: Detected generic platfo
On Thu, Jul 18, 2019 at 01:54:03PM +0200, Cédric Le Goater wrote:
> Hello,
>
> The QEMU PowerNV machine emulates a baremetal OpenPOWER system and
> acts as an hypervisor (L0). Supporting emulation of KVM to run guests
> (L1) requires a few more extensions, among which guest support for the
> XIVE
On Mon, Jul 22, 2019 at 04:17:51PM +1000, Nicholas Piggin wrote:
> Move the i386 suspend_wakeup logic out of the fallback path, and into
> the new ->wakeup method.
>
> Signed-off-by: Nicholas Piggin
Reviewed-by: David Gibson
> ---
> hw/i386/pc.c | 8
> vl.c | 2 --
> 2 files
On Mon, Jul 22, 2019 at 04:17:52PM +1000, Nicholas Piggin wrote:
> This has been useful to modify and test the Linux pseries suspend
> code but it requires modification to the guest to call it (due to
> being gated by other unimplemented features). It is not otherwise
> used by Linux yet, but work
On Fri, Jul 19, 2019 at 03:51:26AM -0500, Shivaprasad G Bhat wrote:
> The current code is broken for more than vcpu as
> each thread would overwrite idle_timer and there were
> memory leaks.
>
> Make it part of PowerPCCPU so that every thread has a
> separate one. Avoid using the timer_new_ns whic
On Mon, Jul 22, 2019 at 03:32:13PM +1000, Nicholas Piggin wrote:
> Waking from suspend is not logically a machine reset on all machines,
> particularly in the paravirtualized case rather than hardware
> emulated. The ppc spapr machine for example just invokes hypervisor
> to suspend, and expects th
On Mon, Jul 22, 2019 at 03:32:12PM +1000, Nicholas Piggin wrote:
> Hi, this series is rebased on top of the qmp event fix, and takes
> Paolo's suggestion to implement ->wakeup for i386 before adding
> ppc, which makes it much nicer.
>
> If the first two patches can be agreed on initially and merge
On 22/07/19 08:17, Nicholas Piggin wrote:
> Move the i386 suspend_wakeup logic out of the fallback path, and into
> the new ->wakeup method.
>
> Signed-off-by: Nicholas Piggin
> ---
> hw/i386/pc.c | 8
> vl.c | 2 --
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff -
While most features are now detected by probing the ID_* registers
kernels can (and do) use MIDR_EL1 for working out of they have to
apply errata. This can trip up warnings in the kernel as it tries to
work out if it should apply workarounds to features that don't
actually exist in the reported CPU
On 22/07/19 10:39, David Gibson wrote:
> On Mon, Jul 22, 2019 at 03:32:12PM +1000, Nicholas Piggin wrote:
>> Hi, this series is rebased on top of the qmp event fix, and takes
>> Paolo's suggestion to implement ->wakeup for i386 before adding
>> ppc, which makes it much nicer.
>>
>> If the first two
On 22/07/19 12:43, Jan Kiszka wrote:
>> Currently QEMU writes to userspace maintained nested-state only at
>> kvm_arch_init_vcpu() and
>> when loading vmstate_nested_state vmstate subsection.
>> kvm_arch_reset_vcpu() do not modify userspace maintained nested-state.
> Hmm, then we probably achieve
While older toolchains produced binaries where the physical load address
of ELF segments was the same as the virtual address, newer versions seem
to choose a different physical address if it isn't specified explicitly.
The means that the test kernel doesn't use the right addresses to access
e.g. fo
On Mon, 22 Jul 2019 at 12:19, Alex Bennée wrote:
>
> While most features are now detected by probing the ID_* registers
> kernels can (and do) use MIDR_EL1 for working out of they have to
> apply errata. This can trip up warnings in the kernel as it tries to
> work out if it should apply workaroun
On 7/19/19 3:14 PM, Philippe Mathieu-Daudé wrote:
> GCC9 is confused by this comment when building with CFLAG
> -Wimplicit-fallthrough=2:
>
> hw/block/pflash_cfi02.c: In function ‘pflash_write’:
> hw/block/pflash_cfi02.c:574:16: error: this statement may fall through
> [-Werror=implicit-fallt
On 22/07/19 04:59, Jing Liu wrote:
>
>
> On 7/19/2019 4:10 PM, Paolo Bonzini wrote:
>> On 19/07/19 09:20, Jing Liu wrote:
Then CPUID[7,0].EAX is set automatically to 0 or 1 depending on whether
BF16 is enabled or not.
>>>
>>> Could I ask why don't we directly check BF16 enabling when
>>
Peter Maydell writes:
> On Mon, 22 Jul 2019 at 12:19, Alex Bennée wrote:
>>
>> While most features are now detected by probing the ID_* registers
>> kernels can (and do) use MIDR_EL1 for working out of they have to
>> apply errata. This can trip up warnings in the kernel as it tries to
>> work
On Fri, 19 Jul 2019 at 17:47, Mark Rutland wrote:
>
> Hi Peter,
>
> I've just been testing on QEMU v4.1.0-rc1, and found a case where the
> DTB overlapped the end of the kernel, and I think there's a bug in this
> patch -- explanation below.
>
> On Thu, May 16, 2019 at 03:47:32PM +0100, Peter Mayd
On 21/07/19 10:08, l00284672 wrote:
> commit a6f230c move blockbackend back to main AioContext on unplug. It set
> the AioContext of
> SCSIDevice to the main AioContex, but s->ctx is still the iothread
> AioContex（if the scsi controller
> is configure with iothread）. So if there are having in-fli
On Fri, 19 Jul 2019 at 11:18, Marc-André Lureau
wrote:
>
> Hi
>
> On Fri, Jul 19, 2019 at 2:10 PM Peter Maydell
> wrote:
> >
> > contrib/elf2dmp has a source file which uses curl/curl.h;
> > although we link the final executable with CURL_LIBS, we
> > forgot to build this source file with CURL_C
On Mon, Jul 22, 2019 at 01:20:08PM +0200, Paolo Bonzini wrote:
> On 22/07/19 10:39, David Gibson wrote:
> > On Mon, Jul 22, 2019 at 03:32:12PM +1000, Nicholas Piggin wrote:
> >> Hi, this series is rebased on top of the qmp event fix, and takes
> >> Paolo's suggestion to implement ->wakeup for i386
On Fri, 19 Jul 2019 at 21:21, Eric Blake wrote:
>
> The following changes since commit e2b47666fe1544959c89bd3ed159e9e37cc9fc73:
>
> Merge remote-tracking branch 'remotes/berrange/tags/misc-next-pull-request'
> into staging (2019-07-19 14:29:13 +0100)
>
> are available in the Git repository at:
On Tue, Jul 09, 2019 at 07:25:32PM -0400, John Snow wrote:
> This series adds a new "BITMAP" sync mode that is meant to replace the
> existing "INCREMENTAL" sync mode.
>
> This mode can have its behavior modified by issuing any of three bitmap sync
> modes, passed as arguments to the job.
>
> The
I changed it to info_report.
raw binaries are totally fine, however if a user supplies a damaged elf he
will never know if no warning/info is reported.
On Mon, Jul 22, 2019 at 12:41 PM Thomas Huth wrote:
> Hi Michael,
>
> On 22/07/2019 11.16, Michael Rolnik wrote:
> > Hi Thomas.
> > where shoul
On Mon, 22 Jul 2019 at 13:33, Michael Rolnik wrote:
> I changed it to info_report.
> raw binaries are totally fine, however if a user supplies a damaged elf he
> will never know if no warning/info is reported.
I find a good rule of thumb for architecture specific/board specific
code is that if ot
On Mon, Jul 22, 2019 at 12:59:01PM +0100, Peter Maydell wrote:
> On Fri, 19 Jul 2019 at 17:47, Mark Rutland wrote:
> >
> > Hi Peter,
> >
> > I've just been testing on QEMU v4.1.0-rc1, and found a case where the
> > DTB overlapped the end of the kernel, and I think there's a bug in this
> > patch -
Not sure if it has been reported before, but test 059 currently fails:
059 fail [14:55:21] [14:55:26]output
mismatch (see 059.out.bad)
--- /home/thuth/devel/qemu/tests/qemu-iotests/059.out 2019-07-19
10:19:18.0 +0200
+++ /home/thuth/tmp/qemu-build/tests/qem
From: Philippe Mathieu-Daudé
Reported by GCC9 when building with -Wimplicit-fallthrough=2:
target/arm/helper.c: In function ‘arm_cpu_do_interrupt_aarch32_hyp’:
target/arm/helper.c:7958:14: error: this statement may fall through
[-Werror=implicit-fallthrough=]
7958 | addr = 0x14;
ericb/tags/pull-nbd-2019-07-19' into
staging (2019-07-22 10:11:28 +0100)
are available in the Git repository at:
https://git.linaro.org/people/pmaydell/qemu-arm.git
tags/pull-target-arm-20190722
for you to fetch changes up to ddb45afbfbc639365d6c934e4e29f6de5e5e2a0e:
contrib/elf2dmp: B
In arm_cpu_realizefn() we make several assertions about the values of
guest ID registers:
* if the CPU provides AArch32 v7VE or better it must advertise the
ARM_DIV feature
* if the CPU provides AArch32 A-profile v6 or better it must
advertise the Jazelle feature
These are essentially cons
The i.MX6UL always has a single Cortex-A7 CPU (we set FSL_IMX6UL_NUM_CPUS
to 1 in line with this). This means that all the code in fsl-imx6ul.c to
handle multiple CPUs is dead code, and Coverity is now complaining that
it is unreachable (CID 1403008, 1403011).
Remove the unreachable code and the o
If configure detects that it's being run on a source tree which
is missing git modules, it prints an error messages suggesting
that the user downloads a correct source archive from the project
website. However https://www.qemu.org/download/ is a link to a
page with multiple tabs, with the default b
contrib/elf2dmp has a source file which uses curl/curl.h;
although we link the final executable with CURL_LIBS, we
forgot to build this source file with CURL_CFLAGS, so if
the curl header is in a place that's not already on the
system include path then it will fail to build.
Add a line specifying
On Sun, 21 Jul 2019 at 10:04, Zhang Chen wrote:
>
> From: Zhang Chen
>
> This patch to fix the origin "char *data" memory leak, code style issue
> and add necessary check here.
> Reported-by: Coverity (CID 1402785)
>
> Signed-off-by: Zhang Chen
> @@ -1008,21 +1019,24 @@ static void
> compare_n
virtio_net_flush_tx does not check that the packet size is nonzero,
which causes q->aysnc_tx.elem to be set. Then, when the device is reset, there
is an assertion failure since q->aysnc_tx.elem must be flushed/cleared.
Zero-sized packets are unsupported - check packet size, prior to
sending.
Found
Virtual devices should not try to send zero-sized packets. The caller
should check the size prior to calling qemu_sendv_packet_async.
Signed-off-by: Alexander Oleinik
---
v2:
* Improve the comment to explain the rationale for adding the assert.
net/net.c | 9 +
1 file changed, 9 insert
While fuzzing the virtio-net tx vq, I ran into an assertion failure due
to iov_copy offsets larger than the total iov size. Though there is
a check to cover this, it does not execute when !n->has_vnet_hdr. This
patch tries to fix this.
The call stack for the assertion failure:
#8 in __assert_fail
bdrv_set_aio_context_ignore() can only work in the main loop:
bdrv_drained_begin() only works in the main loop and the node's (old)
AioContext; and bdrv_drained_end() really only works in the main loop
and the node's (new) AioContext (contrary to its current comment, which
is just wrong).
Conseque
Decrementing drained_end_counter after bdrv_dec_in_flight() (which in
turn invokes bdrv_wakeup() and thus aio_wait_kick()) is not very clever.
We should decrement it beforehand, so that any waiting aio_poll() that
is woken by bdrv_dec_in_flight() sees the decremented
drained_end_counter.
Because t
Hi,
I noted that test-bdrv-drain sometimgs hangs (very rarely, though), and
tried to write a test that triggers the issue. I failed to do so (there
is a good reason for that, see patch 1), but on my way I noticed that
calling bdrv_set_aio_context_ignore() from any AioContext but the main
one is a
bdrv_drop_intermediate() calls BdrvChildRole.update_filename(). That
may poll, thus changing the graph, which potentially breaks the
QLIST_FOREACH_SAFE() loop.
Just keep the whole subtree drained. This is probably the right thing
to do anyway (dropping nodes while the subtree is not drained seem
Currently, bdrv_replace_child_noperm() undrains the parent until it is
completely undrained, then re-drains it after attaching the new child
node.
This is a problem with bdrv_drop_intermediate(): We want to keep the
whole subtree drained, including parents, while the operation is
under way. bdrv_
I think the patches speak for themselves now.
(The title of this series alludes to what the iotest added in the final
patch tests.)
v3:
- Rebased on master
- Added two tests to test-bdrv-drain [Kevin]
- Removed new iotest from auto [Thomas]
git-backport-diff against v2:
Key:
[] : patches
Signed-off-by: Max Reitz
---
tests/test-bdrv-drain.c | 167
1 file changed, 167 insertions(+)
diff --git a/tests/test-bdrv-drain.c b/tests/test-bdrv-drain.c
index 03fa1142a1..1600d41e9a 100644
--- a/tests/test-bdrv-drain.c
+++ b/tests/test-bdrv-drain.c
@@
Add a test for what happens when you call bdrv_replace_child_noperm()
for various drain situations ({old,new} child {drained,not drained}).
Most importantly, if both the old and the new child are drained, the
parent must not be undrained at any point.
Signed-off-by: Max Reitz
---
tests/test-bdr
We already have 030 for that in general, but this tests very specific
cases of both jobs finishing concurrently.
Signed-off-by: Max Reitz
---
tests/qemu-iotests/258 | 163 +
tests/qemu-iotests/258.out | 33
tests/qemu-iotests/group | 1 +
3 f
Thomas Huth writes:
> On 16/07/2019 15.06, Markus Armbruster wrote:
[...]
>> 2. We want a way to Kconfig the PCI devices that work, i.e. only the
>>ones that support MSI or MSI-X.
>>
>> I don't like calling devices without any MSI capability "classic" or
>> "conventional devices". I'd rathe
As we discovered yet another issue with current PBP code, we decided
to use a local PBP only, limited to one series of inflation requests.
This series supersedes:
- [PATCH-for-4.1 v2 0/3] virtio-balloon: fixes for PartialBalloonedPage
- [PATCH v1 0/3] virtio-balloon: PartialBalloonedPage rework
Pa
Using the address of a RAMBlock to test for a matching pbp is not really
safe. Instead, let's use the guest physical address of the base page
along with the page size (via the number of subpages).
Also, let's allocate the bitmap separately. This makes the code
easier to read and maintain - we can
If we directly cast from int to uint64_t, we will first sign-extend to
an int64_t, which is wrong. We actually want to treat the PFNs like
unsigned values.
As far as I can see, this dates back to the initial virtio-balloon
commit, but wasn't triggered as fairly big guests would be required.
Cc: q
Let's simplify this - the case we are optimizing for is very hard to
trigger and not worth the effort. If we're switching from inflation to
deflation, let's reset the pbp.
Acked-by: David Gibson
Signed-off-by: David Hildenbrand
---
hw/virtio/virtio-balloon.c | 26 +-
1 f
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
"host_page_base" is really confusing, let's make this clearer, also
rename the other offsets to indicate to which base they apply.
offset -> mr_offset
ram_offset -> rb_offset
host_page_base -> rb_aligned_offset
While at it, use QEMU_ALIGN_DOWN() instead of a handcrafted computation
and move the c
On 7/20/19 9:54 PM, Richard Henderson wrote:
> On 7/11/19 3:32 PM, Jan Bobek wrote:
>> +sub data16($%)
>> +{
>> +my ($insn, %data16) = @_;
>> +$insn->{data16} = \%data16;
>> +}
>> +
>> +sub rep($%)
>> +{
>> +my ($insn, %rep) = @_;
>> +$insn->{rep} = \%rep;
>> +}
>> +
>> +sub repne($
We still have multiple issues in the current code
- The PBP is not freed during unrealize()
- The PBP is not reset on device resets: After a reset, the PBP is stale.
- We are not indicating VIRTIO_BALLOON_F_MUST_TELL_HOST, therefore
guests (esp. legacy guests) will reuse pages without deflating,
> From: Aleksandar Markovic
> Sent: Monday, July 15, 2019 10:00 PM
> To: qemu-devel@nongnu.org
> Cc: s...@weilnetz.de; Aleksandar Markovic; Aleksandar Rikalo
> Subject: [PATCH for 4.1 v4 5/5] target/mips: Fix emulation of MSA pack
> instructions on big endian hosts
>
> From: Aleksandar Markovic
> From: Aleksandar Markovic
> Sent: Monday, July 15, 2019 10:00 PM
> To: qemu-devel@nongnu.org
> Cc: s...@weilnetz.de; Aleksandar Markovic; Aleksandar Rikalo
> Subject: [PATCH for 4.1 v4 1/5] target/mips: Add 'fall through' comments for
> handling nanoMips' SHXS, SWXS
>
> From: Aleksandar Markovi
got it.
On Mon, Jul 22, 2019 at 3:40 PM Peter Maydell
wrote:
> On Mon, 22 Jul 2019 at 13:33, Michael Rolnik wrote:
> > I changed it to info_report.
> > raw binaries are totally fine, however if a user supplies a damaged elf
> he
> > will never know if no warning/info is reported.
>
> I find a g
1 - 100 of 228 matches
Mail list logo
