Hi,
This series failed docker-build@min-glib build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
Type: series
Message-id: 20180328121804.16203-1-marcandre.lur...@redhat.com
Subject: [Qemu-devel] [PATCH for-2.12
Hi,
This series failed docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
Type: series
Message-id: 1522344417-60114-1-git-send-email-...@sifive.com
Subject: [Qemu-devel] [PULL 0/1] RISC-V:
Hi,
This series failed docker-build@min-glib build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
Type: series
Message-id: 20180326202039.21070-1-mre...@redhat.com
Subject: [Qemu-devel] [PULL 0/4] Block patches
Hi,
This series failed docker-build@min-glib build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
Type: series
Message-id: 20180327202152.1799131-1-ebl...@redhat.com
Subject: [Qemu-devel] [PATCH for-2.12] dump:
Hi,
This series failed docker-quick@centos6 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
Type: series
Message-id: 1522316251-16399-1-git-send-email-th...@redhat.com
Subject: [Qemu-devel] [PATCH for-2.13]
Hi,
This series failed docker-quick@centos6 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
Type: series
Message-id: 152231456507.69730.15601462044394150786.st...@bahia.lan
Subject: [Qemu-devel] [PATCH 0/3]
Hi,
This series failed docker-quick@centos6 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
Type: series
Message-id: 20180329113320.8053-1-coh...@redhat.com
Subject: [Qemu-devel] [PATCH for-2.13] s390x: int
Hi,
This series failed docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
Type: series
Message-id: 20180329154833.566-1-marcandre.lur...@redhat.com
Subject: [Qemu-devel] [PATCH v3 0/4] RFC:
** Patch added:
"0001-hw-char-cmsdk-apb-uart-fix-clearing-of-interrupt-fla.patch"
https://bugs.launchpad.net/qemu/+bug/1760262/+attachment/5096702/+files/0001-hw-char-cmsdk-apb-uart-fix-clearing-of-interrupt-fla.patch
--
You received this bug notification because you are a member of qemu-
de
Public bug reported:
I have been writing a small operating system and using QEMU emulating
the mps2-an385 board for some of my testing.
During development of the uart driver I observed some odd behaviour with
the TX interrupt -- writing a '1' to bit 0 of the INTCLEAR register
doesn't clear the TX
Found in v2.12.0-rc1.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1760262
Title:
cmsdk-apb-uart doesn't appear to clear interrupt flags
Status in QEMU:
New
Bug description:
I have been writ
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20180329213857.15499-1-ehabk...@redhat.com
Subject: [Qemu-devel] [RFC 00/18] QEMU validator: A method to specify QEMU
crash-test cases
=== TEST SCRIPT BEGIN ===
#!/bin/bash
Public bug reported:
Running an install to HD of Lubuntu 18.04 and after running
update/upgrade this morning now the optical drive door doesn't respond
to keyboard "eject" key on a Mac keyboard for '12 MacPro . . . . I
tried to use "xfburn" to get the door to open, nothing seems to get it
to work
In case of syscall restart request set pc back to the syscall
instruction.
Signed-off-by: Max Filippov
---
linux-user/main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/linux-user/main.c b/linux-user/main.c
index ba09b7d0c873..8907a8411411 100644
--- a/linux-user/main.c
+++ b/linux-us
On Fri, Mar 30, 2018 at 08:02:09PM +0300, Roman Kagan wrote:
> In order to guarantee compatibility on migration, QEMU should have
> complete control over the features it announces to the guest via CPUID.
>
> However, for a number of Hyper-V-related cpu properties, if the
> corresponding feature is
Got similar behavior with windows server 2012r2 VMs.
Environment:
uname -a
Linux ubuntu-q87 4.13.0-37-generic #42~16.04.1-Ubuntu SMP Wed Mar 7 16:03:28
UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
ii linux-image-4.13.0-36-generic
4.13.0-36.40~16.04.1 am
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: linux (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1728256
Title:
Mem
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: 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/1728256
Title:
Memory corruption in Windows 10 guest / amd64
Status in QEM
Is there way to emulate SGI IRIX 6.5 MIPS R4000 in QEMU? I need to transfer my
work from my software Softimage 3d 4.0 to IRIX for a modern machine and qemu is
great for this, I saw many on YouTube and Google working perfectly Debian (no
graphic) DEC Alpha and up to Windows NT 4.0 MIPS 4000 in Qe
Hi Peter,
I had tested Richard's proper fix but we didn't have a PR or the required
Reviewed-by and Signed-off-by so I made the PR for the conservative fix,
assuming we can test Richard's more correct fix and include it in the QEMU
2.13 timeframe. I've tested Richard's fix with the simple scheduli
In order to guarantee compatibility on migration, QEMU should have
complete control over the features it announces to the guest via CPUID.
However, a number of Hyper-V-related features happen to depend on the
support in the underlying KVM, with no regard to QEMU configuration.
Make QEMU regain co
In order to guarantee compatibility on migration, QEMU should have
complete control over the features it announces to the guest via CPUID.
However, for a number of Hyper-V-related cpu properties, if the
corresponding feature is not supported by the underlying KVM, the
propery is silently ignored a
In order to guarantee compatibility on migration, QEMU should have
complete control over the features it announces to the guest via CPUID.
However, the availability of Hyper-V frequency MSRs
(HV_X64_MSR_TSC_FREQUENCY and HV_X64_MSR_APIC_FREQUENCY) depends solely
on the support for them in the unde
Le 30/03/2018 à 18:54, Rob Landley a écrit :
> On 03/20/2018 04:08 AM, Laurent Vivier wrote:> This series of patches is
> needed
> to fix a problem
>> in the m68k translator that can crash QEMU when translation
>> cache has too many instructions:
>>
>> qemu-m68k: tcg/tcg.c:883: tcg_temp_alloc: A
On Fri, Mar 30, 2018 at 12:11 AM, Alex Bennée
wrote:
>
> Michael Clark writes:
>
> > On Tue, Mar 27, 2018 at 3:17 PM, Philippe Mathieu-Daudé >
> > wrote:
> >
> >> Cc'ing Alex and Richard.
> >>
> >> On 03/27/2018 04:54 PM, Michael Clark wrote:
> >> > This change is a workaround for a bug where m
30.03.2018 02:18, Eric Blake wrote:
It's never a good idea to blindly read for size bytes as
returned by the server without first validating that the size
is within bounds; a malicious or buggy server could cause us
to hang or get out of sync from reading further messages.
It may be smarter to t
On 03/20/2018 04:08 AM, Laurent Vivier wrote:> This series of patches is needed
to fix a problem
> in the m68k translator that can crash QEMU when translation
> cache has too many instructions:
>
> qemu-m68k: tcg/tcg.c:883: tcg_temp_alloc: Assertion `n < 512' failed.
> qemu: uncaught target si
30.03.2018 16:09, Eric Blake wrote:
Having a more detailed log of the interaction between client and
server is invaluable in debugging how meta context negotiation
actually works.
Signed-off-by: Eric Blake
---
nbd/client.c | 2 ++
nbd/server.c | 8
nbd/trace-events | 6
30.03.2018 19:10, Vladimir Sementsov-Ogievskiy wrote:
Use MIGRATION events instead of RESUME. Also, make a TODO: enable
dirty-bitmaps capability for offline case.
This (likely) fixes racy faults at least of the following types:
- timeout on waiting for RESUME event
- sha256 mismatch o
Use MIGRATION events instead of RESUME. Also, make a TODO: enable
dirty-bitmaps capability for offline case.
This (likely) fixes racy faults at least of the following types:
- timeout on waiting for RESUME event
- sha256 mismatch on 136 (138 after this patch)
Signed-off-by: Vladimir Seme
The following patch should fix that:
http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg07437.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1756519
Title:
qemu linux-user crash in QOM
30.03.2018 16:31, Vladimir Sementsov-Ogievskiy wrote:
29.03.2018 18:09, Vladimir Sementsov-Ogievskiy wrote:
29.03.2018 17:03, Max Reitz wrote:
On 2018-03-29 10:08, Vladimir Sementsov-Ogievskiy wrote:
28.03.2018 17:53, Max Reitz wrote:
On 2018-03-27 12:11, Vladimir Sementsov-Ogievskiy wrote:
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/iotests.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index 83c454d..89fe446 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-i
Add an assert (we don't want set both arguments) and remove
duplication.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/iotests.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index b5d
for 2.12
30.03.2018 18:16, Vladimir Sementsov-Ogievskiy wrote:
Blacklist these formats, as they don't support image creation, as they
say:
> ./qemu-img create -f bochs x 1m
qemu-img: x: Format driver 'bochs' does not support image creation
> ./qemu-img create -f cloop x 1m
q
Blacklist these formats, as they don't support image creation, as they
say:
> ./qemu-img create -f bochs x 1m
qemu-img: x: Format driver 'bochs' does not support image creation
> ./qemu-img create -f cloop x 1m
qemu-img: x: Format driver 'cloop' does not support image creation
Vla
Blacklist these formats, as they don't support image creation, as they
say:
> ./qemu-img create -f bochs x 1m
qemu-img: x: Format driver 'bochs' does not support image creation
> ./qemu-img create -f cloop x 1m
qemu-img: x: Format driver 'cloop' does not support image creation
Sig
Support luks images creatins like in 205
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/208 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/qemu-iotests/208 b/tests/qemu-iotests/208
index 4e82b96..18f59ad 100755
--- a/tests/qemu-iotests/208
+++ b/tes
Le 30/03/2018 à 15:35, Max Filippov a écrit :
> cpu_copy adds newly created CPU object to container/machine/unattached,
> but does it w/o proper locking. As a result when multiple threads are
> created rapidly QEMU may abort with the following message:
>
> GLib-CRITICAL **: g_hash_table_iter_nex
cpu_copy adds newly created CPU object to container/machine/unattached,
but does it w/o proper locking. As a result when multiple threads are
created rapidly QEMU may abort with the following message:
GLib-CRITICAL **: g_hash_table_iter_next: assertion
'ri->version == ri->hash_table->version'
29.03.2018 18:09, Vladimir Sementsov-Ogievskiy wrote:
29.03.2018 17:03, Max Reitz wrote:
On 2018-03-29 10:08, Vladimir Sementsov-Ogievskiy wrote:
28.03.2018 17:53, Max Reitz wrote:
On 2018-03-27 12:11, Vladimir Sementsov-Ogievskiy wrote:
[...]
isn't it because a lot of cat processes? will c
Having a more detailed log of the interaction between client and
server is invaluable in debugging how meta context negotiation
actually works.
Signed-off-by: Eric Blake
---
nbd/client.c | 2 ++
nbd/server.c | 8
nbd/trace-events | 6 ++
3 files changed, 16 insertions(+)
di
Start the free page optimization after the migration bitmap is
synchronized. This can't be used in the stop© phase since the guest
is paused. Make sure the guest reporting has stopped before
synchronizing the migration dirty bitmap. Currently, the optimization is
added to precopy only.
Signed-off-
On 03/20/2018 11:24 AM, Michael S. Tsirkin wrote:
On Tue, Mar 20, 2018 at 11:18:23AM +0800, Wei Wang wrote:
On 03/20/2018 10:59 AM, Michael S. Tsirkin wrote:
On Tue, Mar 20, 2018 at 10:16:09AM +0800, Wei Wang wrote:
On 03/20/2018 06:55 AM, Michael S. Tsirkin wrote:
On Mon, Mar 19, 2018 at 05:
The new feature enables the virtio-balloon device to receive hints of
guest free pages from the free page vq.
balloon_free_page_start - start guest free page hint reporting.
balloon_free_page_stop - stop guest free page hint reporting.
Note: balloon will report pages which were free at the time
o
The bitmap mutex is used to synchronize threads to update the dirty
bitmap and the migration_dirty_pages counter. This patch makes
migration_bitmap_clear_dirty update the bitmap and counter under the
mutex.
Signed-off-by: Wei Wang
CC: Dr. David Alan Gilbert
CC: Juan Quintela
CC: Michael S. Tsir
This patch adds an API to clear bits corresponding to guest free pages
from the dirty bitmap. Spilt the free page block if it crosses the QEMU
RAMBlock boundary.
Signed-off-by: Wei Wang
CC: Dr. David Alan Gilbert
CC: Juan Quintela
CC: Michael S. Tsirkin
---
include/migration/misc.h | 2 ++
m
Count the number of 1s in a bitmap starting from an offset.
Signed-off-by: Wei Wang
CC: Dr. David Alan Gilbert
CC: Juan Quintela
CC: Michael S. Tsirkin
Reviewed-by: Dr. David Alan Gilbert
---
include/qemu/bitmap.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/qem
This is the deivce part implementation to add a new feature,
VIRTIO_BALLOON_F_FREE_PAGE_HINT to the virtio-balloon device. The device
receives the guest free page hints from the driver and clears the
corresponding bits in the dirty bitmap, so that those free pages are
not transferred by the migrati
Hi everyone,
Currently, I found virtio-9p in VirtFS don't support "O_DIRECT + aio"
mode, both v9fs and qemu. So when user use "O_DIRECT + aio" mode and
increase iodepths, they can't get higher IOPS.
I want to know why v9fs don't implement this mode? And I will try to
implement this mode from now
From: Xiao Guangrong
Now, we can reuse the path in ram_save_page() to post the page out
as normal, then the only thing remained in ram_save_compressed_page()
is compression that we can move it out to the caller
Reviewed-by: Peter Xu
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Xiao Guang
From: Xiao Guangrong
Abstract the common function control_save_page() to cleanup the code,
no logic is changed
Reviewed-by: Peter Xu
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Xiao Guangrong
---
migration/ram.c | 174 +---
1 file ch
From: Xiao Guangrong
It directly sends the page to the stream neither checking zero nor
using xbzrle or compression
Reviewed-by: Peter Xu
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Xiao Guangrong
---
migration/ram.c | 50 ++
1 file chan
From: Xiao Guangrong
Current code uses compress2() to compress memory which manages memory
internally, that causes huge memory is allocated and freed very
frequently
More worse, frequently returning memory to kernel will flush TLBs
and trigger invalidation callbacks on mmu-notification which
int
From: Xiao Guangrong
Current code uses uncompress() to decompress memory which manages
memory internally, that causes huge memory is allocated and freed
very frequently, more worse, frequently returning memory to kernel
will flush TLBs
So, we maintain the memory by ourselves and reuse it for eac
From: Xiao Guangrong
The function is called by both ram_save_page and ram_save_target_page,
so move it to the common caller to cleanup the code
Reviewed-by: Peter Xu
Signed-off-by: Xiao Guangrong
---
migration/ram.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff
From: Xiao Guangrong
save_zero_page() is always our first approach to try, move it to
the common place before calling ram_save_compressed_page
and ram_save_page
Reviewed-by: Peter Xu
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Xiao Guangrong
---
migration/ram.c | 105 +
From: Xiao Guangrong
Currently the page being compressed is allowed to be updated by
the VM on the source QEMU, correspondingly the destination QEMU
just ignores the decompression error. However, we completely miss
the chance to catch real errors, then the VM is corrupted silently
To make the mi
From: Xiao Guangrong
Move some code from ram_save_target_page() to ram_save_host_page()
to make it be more readable for latter patches that dramatically
clean ram_save_target_page() up
Reviewed-by: Peter Xu
Signed-off-by: Xiao Guangrong
---
migration/ram.c | 43 +++
From: Xiao Guangrong
Changelog in v3:
Following changes are from Peter's review:
1) use comp_param[i].file and decomp_param[i].compbuf to indicate if
the thread is properly init'd or not
2) save the file which is used by ram loader to the global variable
instead it is cached per decompressi
From: Xiao Guangrong
As compression is a heavy work, do not do it in migration thread,
instead, we post it out as a normal page
Reviewed-by: Wei Wang
Reviewed-by: Peter Xu
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Xiao Guangrong
---
migration/ram.c | 32
Michael Clark writes:
> On Tue, Mar 27, 2018 at 3:17 PM, Philippe Mathieu-Daudé
> wrote:
>
>> Cc'ing Alex and Richard.
>>
>> On 03/27/2018 04:54 PM, Michael Clark wrote:
>> > This change is a workaround for a bug where mstatus.FS
>> > is not correctly reporting dirty when MTTCG and SMP are
>> >
62 matches
Mail list logo
