On Thu, Oct 03, 2019 at 11:55:36PM +, Zhang, Lei wrote:
> Hi Jones,
>
> Thanks for your patch.
>
> I have tested the v5 patch.
>
> All the test is passed, except one problem.
> The problem was reported
> in [[Qemu-devel] [RFC QEMU v2 0/2] arm/virt: Account for guest pause time]
> https://lis
On Fri, 4 Oct 2019 07:53:13 +0200
Cédric Le Goater wrote:
> >> @@ -283,11 +292,13 @@ static void spapr_xive_realize(DeviceState *dev,
> >> Error **errp)
> >> return;
> >> }
> >>
> >> -if (!xive->nr_ends) {
> >> -error_setg(errp, "Number of interrupt needs to be greate
On Fri, 4 Oct 2019 14:07:25 +1000
David Gibson wrote:
> On Thu, Oct 03, 2019 at 02:01:13PM +0200, Greg Kurz wrote:
> > The sPAPR XIVE object has an nr_ends field which happens to be a
> > multiple of spapr_max_server_number(). It is currently set with
> > the help of "nr-ends" property. This is a
When I run make check-acceptance in a 32-bit (i686) container, this
test fails, because it tries to start a guest with 4G of RAM, which
can't fit in the userspace address space on a 32-bit host, obviously.
(16/44)
/home/dwg/src/qemu/tests/acceptance/linux_initrd.py:LinuxInitrd.test_with_2gib_fil
>> @@ -283,11 +292,13 @@ static void spapr_xive_realize(DeviceState *dev, Error
>> **errp)
>> return;
>> }
>>
>> -if (!xive->nr_ends) {
>> -error_setg(errp, "Number of interrupt needs to be greater 0");
>> +if (!xive->nr_servers) {
>> +error_setg(errp, "Numb
On Thu, 03 Oct 2019 16:46:37 +0100,
Eric Auger wrote:
>
> Since 4.18, KVM/ARM exposes a KVM_MAX_VCPUS equal to 512. However it was
> reported [1] that a VM with more than 256 vcpus cannot be launched. 5.4
> fixes the situation with 2 patches:
> - one upgrade of the KVM_IRQ_LINE API [2] supporting
On Thu, Oct 03, 2019 at 02:01:13PM +0200, Greg Kurz wrote:
> The sPAPR XIVE object has an nr_ends field which happens to be a
> multiple of spapr_max_server_number(). It is currently set with
> the help of "nr-ends" property. This is a bit unfortunate since
> it exposes to the sPAPR irq frontend wh
Hi Philippe,
On Thu, Oct 03, 2019 at 09:36:56AM +0200, Philippe Mathieu-Daudé wrote:
Hi Matthew,
On 10/3/19 2:18 AM, Matthew Kilgore wrote:
The current code uses getcchar() and setcchar() to handle the cchar_t
values, which is correct, however it incorrectly deconstructs the chtype
value that
The current code does not correctly pass the color pair information to
setcchar(), it instead always passes zero. This results in the curses
output always being in white on black.
This patch fixes this by using PAIR_NUMBER() to retrieve the color pair
number from the chtype value, and then passes
This patch set fixes up ui/curses.c. A previous change to ui/curses.c,
commit 962cf8fd4fae ("ui/curses: manipulate cchar_t with standard curses
functions"), did not correctly pass the attributes from the chtype to
`setcchar()`.
The biggest issue this caused is that colors no longer work when using
The curses API provides the A_ATTRIBUTES and A_CHARTEXT bit masks for
getting the attributes and character parts of a chtype, respectively. We
should use provided constants instead of using 0xff.
Signed-off-by: Matthew Kilgore
---
ui/curses.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletion
If stressone() or stress() exits it's because of a failure
because the test runs forever otherwise, so change stressone
type to void and stress should always return -1 to make the
path of 'if (stress(ramsizeGB, ncpus) < 0)' can be reached.
Signed-off-by: Mao Zhongyi
---
tests/migration/stress.c
Signed-off-by: Mao Zhongyi
Reviewed-by: Alex Bennée
Reviewed-by: Laurent Vivier
---
tests/migration/stress.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/migration/stress.c b/tests/migration/stress.c
index 9e128eef50..debf34359f 100644
--- a/tests/migration/stress.c
‘data’ has the possibility of memory leaks, so use the
glib macros g_autofree recommended by CODING_STYLE.rst
to automatically release the memory that returned from
g_malloc().
Signed-off-by: Mao Zhongyi
Reviewed-by: Alex Bennée
---
tests/migration/stress.c | 10 ++
1 file changed, 2 in
This patchset mainly fixes memory leak, typo and return
value of stress function in stress test.
v3->v2:
p1:
- replace malloc with g_malloc [Laurent Vivier]
p3:
- change stressone type to void and stree return value
to -1 to make the path of 'if (stress(ramsizeGB, ncpus) < 0)'
can be reache
exynos4210_gic_realize() prints the number of cpus into some temporary
buffers, but it only allows 3 bytes space for it. That's plenty - I'm
pretty sure that existing machines will only ever set this value to 2
(EXYNOS4210_NCPUS). But the compiler can't really be expected to figure
that out.
Som
On Thu, Oct 03, 2019 at 04:36:17PM +0200, Cédric Le Goater wrote:
> The POWER8 PowerNV machine needs to implement a XICSFabric interface
> as this is the POWER8 interrupt controller model. But the POWER9
> machine uselessly inherits of XICSFabric from the common PowerNV
> machine definition.
>
> O
On 10/3/19 5:23 PM, Laurent Vivier wrote:
Le 03/10/2019 à 09:17, maozy a écrit :
Hi, Laurent
On 10/1/19 11:46 PM, Laurent Vivier wrote:
Le 11/09/2019 à 05:31, Mao Zhongyi a écrit :
if stress function always return 0, the path
'if (stress(ramsizeGB, ncpus) < 0)' is nerver unreachable,
so f
Patchew URL: https://patchew.org/QEMU/20191003225437.16651-1-phi...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20191003225437.16651-1-phi...@redhat.com
Subject: [PATCH 0/7] fw_cfg: Run tests on big-endia
On 9/16/19 4:15 PM, Peter Maydell wrote:
Factor out the implementation of SYS_SEEK via the new function
tables.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
---
target/arm/arm-semi.c | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(
On 9/16/19 4:15 PM, Peter Maydell wrote:
Factor out the implementation of SYS_ISTTY via the new function
tables.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
---
target/arm/arm-semi.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff -
Hi Jones,
Thanks for your patch.
I have tested the v5 patch.
All the test is passed, except one problem.
The problem was reported
in [[Qemu-devel] [RFC QEMU v2 0/2] arm/virt: Account for guest pause time]
https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg05713.html
My test environment is
On 10/3/19 6:14 AM, Vladimir Sementsov-Ogievskiy wrote:
> 03.10.2019 0:35, John Snow wrote:
>> On 10/2/19 6:46 AM, Peter Krempa wrote:
>>
>> [ * poof * ]
>>
>>>
>>> I'd like to re-iterate that the necessity to keep node names same on
>>> both sides of migration is unexpected, undocumented and in
On 9/16/19 4:15 PM, Peter Maydell wrote:
Currently for the semihosting calls which take a file descriptor
(SYS_CLOSE, SYS_WRITE, SYS_READ, SYS_ISTTY, SYS_SEEK, SYS_FLEN)
we have effectively two implementations, one for real host files
and one for when we indirect via the gdbstub. We want to add a
On 9/16/19 4:15 PM, Peter Maydell wrote:
Factor out the implementation of SYS_READ via the
new function tables.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
---
target/arm/arm-semi.c | 55 +++
1 file changed, 35 insertions(+),
On 9/16/19 4:15 PM, Peter Maydell wrote:
When we are routing semihosting operations through the gdbstub, the
work of sorting out the return value and setting errno if necessary
is done by callback functions which are invoked by the gdbstub code.
Clean up some ifdeffery in those functions by havin
On 9/16/19 4:15 PM, Peter Maydell wrote:
Factor out the implementation of SYS_FLEN via the new
function tables.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
---
target/arm/arm-semi.c | 32 ++--
1 file changed, 22 insertions(+), 10 deletion
On 9/16/19 4:15 PM, Peter Maydell wrote:
Factor out the implementation of SYS_WRITE via the
new function tables.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
---
target/arm/arm-semi.c | 51 ---
1 file changed, 33 insertions(+),
On 2019-10-01 08:23, Markus Armbruster wrote:
"Zoltán Kővágó" writes:
On 2019-09-25 11:49, Markus Armbruster wrote:
"Zoltán Kővágó" writes:
On 2019-09-23 15:08, Markus Armbruster wrote:
"Kővágó, Zoltán" writes:
This will allow us to disable mixeng when we use a decent backend.
Disabli
The "hw/ptimer.h" header is not used, remove it.
Reviewed-by: Alistair Francis
Signed-off-by: Philippe Mathieu-Daudé
---
hw/rtc/xlnx-zynqmp-rtc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/hw/rtc/xlnx-zynqmp-rtc.c b/hw/rtc/xlnx-zynqmp-rtc.c
index f9f09b7296..2bcd14d779 100644
--- a/hw/r
On 9/16/19 4:15 PM, Peter Maydell wrote:
The set_swi_errno() function is called to capture the errno
from a host system call, so that we can return -1 from the
semihosting function and later allow the guest to get a more
specific error code with the SYS_ERRNO function. It comes in
two versions, o
On 9/16/19 4:15 PM, Peter Maydell wrote:
If we fail a semihosting call we should always set the
semihosting errno to something; we were failing to do
this for some of the "check inputs for sanity" cases.
Signed-off-by: Peter Maydell
Reviewed-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daud
Only 2 source files require the "mc146818rtc_regs.h" header.
Instead of having it processed 12 times, by all objects
using "mc146818rtc.h", include it directly where used.
Reviewed-by: Alistair Francis
Signed-off-by: Philippe Mathieu-Daudé
---
hw/rtc/mc146818rtc.c | 1 +
hw/timer/hpet.c
Move RTC devices under the hw/rtc/ subdirectory.
Reviewed-by: Alistair Francis
Signed-off-by: Philippe Mathieu-Daudé
---
hw/rtc/Makefile.objs | 1 +
hw/{timer => rtc}/exynos4210_rtc.c | 0
hw/timer/Makefile.objs | 1 -
3 files changed, 1 insertion(+), 1 deletion(-)
re
The system include is already provided by "osdep.h"
(the scripts/clean-includes file clean such headers).
Commit 64552b6be47 suggests we don't need to include "hw/irq.h":
Move the qemu_irq and qemu_irq_handler typedefs from hw/irq.h to
qemu/typedefs.h, and then include hw/irq.h only wher
The DS1338 is a Real Time Clock, not a timer.
Move it under the hw/rtc/ subdirectory.
Reviewed-by: Alistair Francis
Signed-off-by: Philippe Mathieu-Daudé
---
hw/rtc/Kconfig | 4
hw/rtc/Makefile.objs | 1 +
hw/{timer => rtc}/ds1338.c | 0
hw/timer/Kconfig | 4 ---
Move RTC devices under the hw/rtc/ subdirectory.
Remove Alistair outdated email address (see commit c22e580c2ad).
Reviewed-by: Alistair Francis
Signed-off-by: Philippe Mathieu-Daudé
---
hw/rtc/Makefile.objs| 1 +
hw/rtc/trace-events | 3 +++
hw/{
Move RTC devices under the hw/rtc/ subdirectory.
Reviewed-by: Cédric Le Goater
Reviewed-by: Alistair Francis
Signed-off-by: Philippe Mathieu-Daudé
---
hw/rtc/Makefile.objs | 1 +
hw/{timer => rtc}/aspeed_rtc.c | 2 +-
hw/rtc/trace-events| 4
h
Move RTC devices under the hw/rtc/ subdirectory.
Reviewed-by: Alistair Francis
Signed-off-by: Philippe Mathieu-Daudé
---
MAINTAINERS | 4 ++--
hw/rtc/Kconfig| 3 +++
hw/rtc/Makefile.objs | 1 +
hw/{timer => rtc}/sun4v-rtc.c | 2 +-
hw/rtc/trace-eve
The TWL92230 is an "energy management device" companion with
a RTC. Since we mostly model the RTC, move it under the hw/rtc/
subdirectory.
Reviewed-by: Alistair Francis
Signed-off-by: Philippe Mathieu-Daudé
---
MAINTAINERS | 2 +-
hw/rtc/Kconfig | 4
hw/rtc/M
It is pointless to create/remove a QFWCFG object for each test.
Move it to the test context and create/remove it only once.
Signed-off-by: Philippe Mathieu-Daudé
---
tests/fw_cfg-test.c | 74 +
1 file changed, 27 insertions(+), 47 deletions(-)
diff --
The M48T59 is a Real Time Clock, not a timer.
Move it under the hw/rtc/ subdirectory.
Reviewed-by: Alistair Francis
Signed-off-by: Philippe Mathieu-Daudé
---
v2: delete include/hw/timer/m48t59.h (dgibson)
---
MAINTAINERS | 4 +-
hw/ppc/ppc405_boards.c | 2
The MC146818 is a Real Time Clock, not a timer.
Move it under the hw/rtc/ subdirectory.
Use copyright statement from 80cabfad163 for "hw/rtc/mc146818rtc.h".
Reviewed-by: Alistair Francis
Acked-by: David Gibson
Signed-off-by: Philippe Mathieu-Daudé
---
v2: Use SPDX identifier (thuth)
---
MAINT
We have been restricting our fw_cfg tests to the PC machine,
which is a little-endian architecture.
The fw_cfg device is also used on the SPARC and PowerPC
architectures, which can run in big-endian configuration.
Since we want to be sure our device does not regress
regardless the endianess used,
The M41T80 is a Real Time Clock, not a timer.
Move it under the hw/rtc/ subdirectory.
Reviewed-by: Alistair Francis
Signed-off-by: Philippe Mathieu-Daudé
---
MAINTAINERS| 2 +-
hw/rtc/Kconfig | 4
hw/rtc/Makefile.objs | 1 +
hw/{timer => rtc}/m41t80.c | 0
All these devices do not contain any target-specific. While most
of them are arch-specific, they are shared between different
targets of the same arch family (ARM and AArch64, MIPS32/MIPS64,
endianess, ...).
Put them into common-obj-y to compile them once for all targets.
Reviewed-by: Alistair Fra
The PL031 is a Real Time Clock, not a timer.
Move it under the hw/rtc/ subdirectory.
Reviewed-by: Alistair Francis
Signed-off-by: Philippe Mathieu-Daudé
---
MAINTAINERS | 4 ++--
Makefile.objs | 1 +
hw/Kconfig| 1 +
hw/Makefile.
Since a QFWCFG object is not tied to a particular test, we can
call *_fw_cfg_init() once before creating QTests and use the same
for all the tests, then release the object with g_free() once all
the tests are run.
Refactor the qfw_cfg* API to take QTestState as argument.
Signed-off-by: Philippe M
Since v1: https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03334.html
- addressed review comments (described in patches 3 and 4)
- added R-b/A-b tags
Whole series now reviewed.
v1 blurb:
When working on timers, I found it confuse to have RTC devices
mixed in the hw/timer/ directory.
We
Document pc_fw_cfg_init() return value must be released
with g_free(). Directly calling g_free() we don't really
need pc_fw_cfg_uninit(): remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
tests/fw_cfg-test.c | 22 +++---
tests/libqos/fw_cfg.h| 14 +-
tests
Introduce the local QTestCtx structure, and register the tests
with qtest_add_data_func(ctx).
For now the context only contains the machine name (which is
fixed to the 'pc' machine, since this test only runs on the
x86 architecture).
Signed-off-by: Philippe Mathieu-Daudé
---
tests/fw_cfg-test.c
Document mm_fw_cfg_init() return value must be released
with g_free(). mm_fw_cfg_uninit() was never used, remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
tests/libqos/fw_cfg.c | 5 -
tests/libqos/fw_cfg.h | 10 +-
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/t
Document io_fw_cfg_init() return value must be released
with g_free(). Directly calling g_free() we don't really
need io_fw_cfg_uninit(): remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
tests/libqos/fw_cfg.c | 5 -
tests/libqos/fw_cfg.h | 11 +--
2 files changed, 9 insertions(+
This series allow fw_cfg tests to run on big-endian targets.
This should help us to notice regression such this one
introduced in QEMU v4.0.0:
commit ee5d0f89de3e53cdb0dcf51acc1502b310ed3bd2
Date: Tue Nov 20 21:10:25 2018 -0800
fw_cfg: Fix -boot reboot-timeout error checking
Later fix
On 10/2/19 1:44 AM, Michael Roth wrote:
Hi everyone,
The following new patches are queued for QEMU stable v4.0.1:
https://github.com/mdroth/qemu/commits/stable-4.0-staging
The release is planned for 2019-10-17:
https://wiki.qemu.org/Planning/4.0
Please respond here or CC qemu-sta...@no
** Also affects: kunpeng920
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/1805256
Title:
qemu-img hangs on rcu_call_ready_event logic in Aarch64 when
c
Cc'ing the SABRELITE maintainers:
$ ./scripts/get_maintainer.pl -f hw/misc/imx6_ccm.c
Peter Maydell (odd fixer:SABRELITE / i.MX6)
Jean-Christophe Dubois (reviewer:SABRELITE / i.MX6)
qemu-...@nongnu.org (open list:SABRELITE / i.MX6)
On 10/3/19 1:54 PM, Bin Meng wrote:
+QEMU developers ML
On Th
Patchew URL: https://patchew.org/QEMU/20191003193245.8993-1-js...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20191003193245.8993-1-js...@redhat.com
Subject: [PULL v2 0/8] Ide patches
=== TEST SCRIPT BEG
On Thu, Oct 3, 2019 at 1:36 PM Michal Suchánek wrote:
> On Thu, Oct 03, 2019 at 10:48:46AM -0700, Mauricio Galindo wrote:
> > Hi,
> >
> > I'm running QEMU in user mode and I'm running into issues when trying
> > to exec binaries within the emulated process given that binaries are
> > expected to
From: Sam Eiderman
Relevant devices are:
* ide-hd (and ide-cd, ide-drive)
* scsi-hd (and scsi-cd, scsi-disk, scsi-block)
* virtio-blk-pci
We do not call del_boot_device_lchs() for ide-* since we don't need to -
IDE block devices do not support unplugging.
Signed-off-by: Sam Eiderman
From: Sam Eiderman
We will need to add LCHS removal logic to scsi-hd's unrealize() in the
next commit.
Signed-off-by: Sam Eiderman
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
Message-id: 20190925110639.100699-5-sam...@google.com
Signed-off-by: John Snow
--
From: Sam Eiderman
Add an interface to provide direct logical CHS values for boot devices.
We will use this interface in the next commits.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
Message-id: 20190925110639.100699-4-sam...@google.com
Signed-off-by: John S
From: Sam Eiderman
Using fw_cfg, supply logical CHS values directly from QEMU to the BIOS.
Non-standard logical geometries break under QEMU.
A virtual disk which contains an operating system which depends on
logical geometries (consistent values being reported from BIOS INT13
AH=08) will most l
From: Sam Eiderman
Add logical geometry variables to BlockConf.
A user can now supply "lcyls", "lheads" & "lsecs" for any HD device
that supports CHS ("cyls", "heads", "secs").
These devices include:
* ide-hd
* scsi-hd
* virtio-blk-pci
In future commits we will use the provided LCH
From: Sam Eiderman
Fixing tabbing in block related macros.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
Message-id: 20190925110639.100699-2-sam...@google.com
Signed-off-by: John Snow
---
include/hw/block/block.h | 16
hw/ide/qdev.c
From: Sam Eiderman
Move device name construction to a separate function.
We will reuse this function in the following commit to pass logical CHS
parameters through fw_cfg much like we currently pass bootindex.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
Mes
From: Sam Eiderman
Add QTest tests to check the logical geometry override option.
The tests in hd-geo-test are out of date - they only test IDE and do not
test interesting MBRs.
I added a few helper functions which will make adding more tests easier.
QTest's fw_cfg helper functions support onl
On Thu, Oct 03, 2019 at 10:48:46AM -0700, Mauricio Galindo wrote:
> Hi,
>
> I'm running QEMU in user mode and I'm running into issues when trying
> to exec binaries within the emulated process given that binaries are
> expected to run in the native architecture. Would it be useful to have
> an opt
The following changes since commit 7f21573c822805a8e6be379d9bcf3ad9effef3dc:
Merge remote-tracking branch
'remotes/huth-gitlab/tags/pull-request-2019-10-01' into staging (2019-10-01
13:13:38 +0100)
are available in the Git repository at:
https://github.com/jnsnow/qemu.git tags/ide-pull-req
Hi Juan,
On 10/3/19 6:14 PM, Juan Quintela wrote:
> Eric Auger wrote:
>> Introduce support for GTree migration. A custom save/restore
>> is implemented. Each item is made of a key and a data. For that
>> reason, 2 VMSD objects are passed into the GTree VMStateField.
>>
>> When putting the items,
Quoting Thomas Huth (2019-10-01 23:40:49)
> On 02/10/2019 01.44, Michael Roth wrote:
> > Hi everyone,
> >
> >
> > The following new patches are queued for QEMU stable v4.0.1:
> >
> > https://github.co
On 25/09/2019 08:04, Cédric Le Goater wrote:
> On 25/09/2019 03:46, David Gibson wrote:
>> On Tue, Sep 24, 2019 at 04:06:02PM +0200, Cédric Le Goater wrote:
>>> On 24/09/2019 13:41, David Gibson wrote:
On Tue, Sep 24, 2019 at 07:31:44AM +0200, Cédric Le Goater wrote:
> On 24/09/2019 06:59,
Hi,
I'm running QEMU in user mode and I'm running into issues when trying
to exec binaries within the emulated process given that binaries are
expected to run in the native architecture. Would it be useful to have
an option to rewrite execve(/bin/some_binary, ...) to
execve(qemu-$arch-static, [/bi
Hi,
I'm running QEMU in user mode and I'm running into issues when trying to
exec binaries within the emulated process given that binaries are
expected to run in the native architecture. Would it be useful to have an
option to rewrite execve(/bin/some_binary, ...) to
execve(qemu-$arch-static, [/bi
Ahh, yeah, the FAQ ...! :D A lot of work testing stuff and then I forgot
about that. (I _did_ have a look into it when I wondered about the
binaries whose name ends with a W.)
Anyways, WHPX is not available for Win8.1, but only starting with Win10 _1803_,
they say:
https://docs.microsoft.com/en-u
On 10/3/19 11:35 AM, Peter Maydell wrote:
> On Wed, 2 Oct 2019 at 00:56, John Snow wrote:
>>
>> The following changes since commit 7f21573c822805a8e6be379d9bcf3ad9effef3dc:
>>
>> Merge remote-tracking branch
>> 'remotes/huth-gitlab/tags/pull-request-2019-10-01' into staging (2019-10-01
>> 1
Move bounce_buffer allocation block_copy_with_bounce_buffer. This
commit simplifies further work on implementing copying by larger chunks
(of different size) and further asynchronous handling of block_copy
iterations (with help of block/aio_task API).
Allocation works fast, a lot faster than disk
On 10/3/19 11:35 AM, Peter Maydell wrote:
> On Wed, 2 Oct 2019 at 00:56, John Snow wrote:
>>
>> The following changes since commit 7f21573c822805a8e6be379d9bcf3ad9effef3dc:
>>
>> Merge remote-tracking branch
>> 'remotes/huth-gitlab/tags/pull-request-2019-10-01' into staging (2019-10-01
>> 1
Merge copying code into one function block_copy_do_copy, which only
calls bdrv_ io functions and don't do any synchronization (like dirty
bitmap set/reset).
Refactor block_copy() function so that it takes full decision about
size of chunk to be copied and does all the synchronization (checking
int
No reason to limit buffered copy to one cluster. Let's allow up to 1
MiB.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/block/block-copy.h | 2 +-
block/block-copy.c | 44 +++---
2 files changed, 32 insertions(+), 14 deletions(-)
diff --git a/i
Introduce an API for some shared splitable resource, like memory.
It's going to be used by backup. Backup uses both read/write io and
copy_range. copy_range may consume memory implictly, so new API is
abstract: it don't allocate any real memory but only handling out
tickets.
The idea is that we ha
Large copy range may imply memory allocation and large io effort, so
using 2G copy range request may be bad idea. Let's limit it to 16 MiB.
It also helps the following patch to refactor copy-with-offload
fallback to copy-with-bounce-buffer.
Note, that total memory usage of backup is still not limi
Hi all!
I'm going to bring block-status driven, async copying process to
block-copy, to make it fast. The first step is to limit memory usage of
backup, here is it.
Based on my "[PATCH v15 0/5] backup-top filter driver for backup":
Based-on: <20191001131409.14202-1-vsement...@virtuozzo.com>
Vlad
Currently total allocation for parallel requests to block-copy instance
is unlimited. Let's limit it to 128 MiB.
For now block-copy is used only in backup, so actually we limit total
allocation for backup job.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/block/block-copy.h | 3 +++
b
Coverity (CID 1405786) thinks that there is a possible memory leak as
we don't guarantee that the memory allocated from riscv_find_firmware()
is freed. This is a false positive, but let's tidy up the code to fix
the warning.
Signed-off-by: Alistair Francis
Reviewed-by: Richard Henderson
Reviewed
On Wed, 2 Oct 2019 at 17:18, Kevin Wolf wrote:
>
> The following changes since commit 7f21573c822805a8e6be379d9bcf3ad9effef3dc:
>
> Merge remote-tracking branch
> 'remotes/huth-gitlab/tags/pull-request-2019-10-01' into staging (2019-10-01
> 13:13:38 +0100)
>
> are available in the Git reposito
Eric Auger wrote:
> Introduce support for GTree migration. A custom save/restore
> is implemented. Each item is made of a key and a data. For that
> reason, 2 VMSD objects are passed into the GTree VMStateField.
>
> When putting the items, the tree is traversed in sorted order by
> g_tree_foreach.
On Fri, 23 Aug 2019 16:38:47 PDT (-0700), Alistair Francis wrote:
Signed-off-by: Alistair Francis
---
target/riscv/cpu_helper.c | 39 ++-
1 file changed, 30 insertions(+), 9 deletions(-)
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
inde
Update the headers against commit:
0f1a7b3fac05 ("timer-of: don't use conditional expression
with mixed 'void' types")
Signed-off-by: Eric Auger
---
include/standard-headers/asm-x86/bootparam.h | 2 +
include/standard-headers/asm-x86/kvm_para.h | 1 +
include/standard-headers/linux/ethtoo
Host kernel within [4.18, 5.3] report an erroneous KVM_MAX_VCPUS=512
for ARM. The actual capability to instantiate more than 256 vcpus
was fixed in 5.4 with the upgrade of the KVM_IRQ_LINE ABI to support
vcpu id encoded on 12 bits instead of 8 and a redistributor consuming
a single KVM IO device in
Host kernels that expose the KVM_CAP_ARM_IRQ_LINE_LAYOUT_2 capability
allow injection of interrupts along with vcpu ids larger than 255.
Let's encode the vpcu id on 12 bits according to the upgraded KVM_IRQ_LINE
ABI when needed.
Given that we have two callsites that need to assemble
the value for
Since 4.18, KVM/ARM exposes a KVM_MAX_VCPUS equal to 512. However it was
reported [1] that a VM with more than 256 vcpus cannot be launched. 5.4
fixes the situation with 2 patches:
- one upgrade of the KVM_IRQ_LINE API [2] supporting a vcpu id encoded
on 12 bits,
- the reduction of KVM IO devices
On Wed, 2 Oct 2019 at 00:56, John Snow wrote:
>
> The following changes since commit 7f21573c822805a8e6be379d9bcf3ad9effef3dc:
>
> Merge remote-tracking branch
> 'remotes/huth-gitlab/tags/pull-request-2019-10-01' into staging (2019-10-01
> 13:13:38 +0100)
>
> are available in the Git repositor
01.10.2019 22:46, Max Reitz wrote:
> Signed-off-by: Max Reitz
> ---
> tests/qemu-iotests/iotests.py | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
> index 7030900807..cdcb62c4ac 100644
> --- a/tests/qemu-iot
01.10.2019 22:46, Max Reitz wrote:
> Signed-off-by: Max Reitz
> ---
> tests/qemu-iotests/iotests.py | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
> index cdcb62c4ac..b5ea424de4 100644
> --- a/tests/q
01.10.2019 22:46, Max Reitz wrote:
> We do not do anything with yet, but this is the first step.
>
> Signed-off-by: Max Reitz
> ---
> tests/qemu-iotests/iotests.py | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
> in
02.10.2019 1:16, John Snow wrote:
>
>
> On 10/1/19 3:46 PM, Max Reitz wrote:
>> We do not do anything with yet, but this is the first step.
>>
>> Signed-off-by: Max Reitz
>> ---
>> tests/qemu-iotests/iotests.py | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/tests/qemu-iotes
On Thu, 3 Oct 2019 15:59:29 +0200
Cédric Le Goater wrote:
> On 03/10/2019 15:41, Greg Kurz wrote:
> > On Thu, 3 Oct 2019 15:19:22 +0200
> > Cédric Le Goater wrote:
> >
> >> On 03/10/2019 15:02, Greg Kurz wrote:
> >>> On Thu, 3 Oct 2019 14:58:45 +0200
> >>> Cédric Le Goater wrote:
> >>>
>
On Thu, Oct 03, 2019 at 04:54:31PM +0200, Eric Auger wrote:
> Introduce support for GTree migration. A custom save/restore
> is implemented. Each item is made of a key and a data. For that
> reason, 2 VMSD objects are passed into the GTree VMStateField.
>
> When putting the items, the tree is trav
02.10.2019 17:22, Andrey Shinkevich wrote:
> Add a test case to the iotest #030 that checks 'compress' option for a
> block-stream job.
>
> Signed-off-by: Andrey Shinkevich
> ---
> tests/qemu-iotests/030 | 49
> +-
> tests/qemu-iotests/030.out |
1 - 100 of 191 matches
Mail list logo