On Mon, Apr 01, 2019 at 02:14:57PM +0800, Wei Yang wrote:
>During migration, there are several places to iterate on
>savevm.handlers. And on each iteration, we need to check its ops and
>related callbacks before invoke it.
>
>Generally, ops is the first element to check, and it is
On Tue, Apr 02, 2019 at 08:31:06AM +0800, Wei Yang wrote:
>MigrationState->bytes_xfer is only set to 0 in migrate_init().
>
>Remove this unnecessary field.
>
>Signed-off-by: Wei Yang
Hi, David
Are you willing to pick up this one?
>---
> migration/migration.c | 1 -
>
The encoding process could be described below:
for [content]
get length of a run
encode this run
By refactoring the code with this logic, it maybe a little easier to
understand.
Signed-off-by: Wei Yang
---
migration/xbzrle.c | 153
Since we will not operate on the next address pointed by out, it is not
necessary to do addition on it.
After removing the operation, the function size reduced 16/18 bytes.
Signed-off-by: Wei Yang
---
util/cutils.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a
. Removing this could save some code space.
Wei Yang (2):
cutils: remove one unnecessary pointer operation
migration/xbzrle: make xbzrle_encode_buffer little easier to read
migration/xbzrle.c | 153 +
util/cutils.c | 8 +--
2 files changed, 77
arm and i386 has almost the same function acpi_add_rom_blob(), except
giving different FWCfgCallback function.
This patch moves acpi_add_rom_blob() to utils.c by passing
FWCfgCallback to it.
Signed-off-by: Wei Yang
Reviewed-by: Igor Mammedov
v7:
* rebase on top of current master because of
When we are not in the last_stage, we need to update the cache if page
is not the same.
Currently this procedure is scattered in two places and mixed with
encoding status check.
This patch extract this general step out to make the code a little bit
easy to read.
Signed-off-by: Wei Yang
---
v2
On Fri, Jun 07, 2019 at 08:01:14PM +0100, Dr. David Alan Gilbert wrote:
>* Wei Yang (richardw.y...@linux.intel.com) wrote:
>> For cache miss condition not in last_stage, we need to insert data into
>> cache. When this step succeed, current_data should be updated. While no
>>
On Fri, Jun 07, 2019 at 07:57:34PM +0100, Dr. David Alan Gilbert wrote:
>* Wei Yang (richardw.y...@linux.intel.com) wrote:
>> When we are not in the last_stage, we need to update the cache if page
>> is not the same.
>>
>> Currently this procedure is scattered i
Currently there is only one user of multifd_send_fill_packet(). We
enlarge the responsibility of it to adjust MultiFDSendParams.
Signed-off-by: Wei Yang
---
migration/ram.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
index
After synchronization request is handled in another case, there only
could be one pending_job for one send thread at most.
This is fine to use boolean to represent this behavior.
Signed-off-by: Wei Yang
---
migration/ram.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff
.
Wei Yang (6):
migration/multifd: move MultiFDSendParams handling into
multifd_send_fill_packet()
migration/multifd: notify channels_ready when send thread starts
migration/multifd: use sync field to synchronize send threads
migration/multifd: used must not be 0 for a pending job
Add a field in MultiFDSendParams to indicate there is a request to
synchronize send threads.
By doing so, send_thread will just post sem_sync on synchronization
request and channels_ready will not *overflow*.
Signed-off-by: Wei Yang
---
migration/ram.c | 30 --
1
The spurious wakeup is gone.
Signed-off-by: Wei Yang
---
migration/ram.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
index 831b15833b..2490631d52 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -1153,9 +1153,6 @@ static void *multifd_send_thread
After thread synchronization request is handled in another case, this
means when we only get pending_job when there is used pages.
Signed-off-by: Wei Yang
---
migration/ram.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
index
uce some unpredictable
situation and disturb the semaphore value.
This is a preparation patch to use another mechanism to do send thread
synchronization to avoid post channels_ready in this case. So this patch
posts channels_ready when send threads start running.
Signed-off-by: Wei Y
When we are not in the last_stage, we need to update the cache if page
is not the same.
Currently this procedure is scattered in two places and mixed with
encoding status check.
This patch extract this general step out to make the code a little bit
easy to read.
Signed-off-by: Wei Yang
For cache miss condition not in last_stage, we need to insert data into
cache. When this step succeed, current_data should be updated. While no
matter these checks pass or not, -1 is returned.
Based on this, the logic in cache miss handling could be simplified a
little.
Signed-off-by: Wei Yang
Two trivial patches to make save_xbzrle_page() a little bit easy to
understand.
Wei Yang (2):
migration/xbzrle: update cache and current_data in one place
migration/xbzrle: cleanup the handling cache miss condition
migration/ram.c | 36 +---
1 file changed
On Wed, Jun 05, 2019 at 05:38:19PM +0800, Peter Xu wrote:
>On Wed, Jun 05, 2019 at 04:52:07PM +0800, Wei Yang wrote:
>> On Wed, Jun 05, 2019 at 02:41:08PM +0800, Peter Xu wrote:
>> >On Wed, Jun 05, 2019 at 09:08:28AM +0800, Wei Yang wrote:
>> >> In case we gets a queu
On Wed, Jun 05, 2019 at 12:33:39PM +0200, Juan Quintela wrote:
>Peter Xu wrote:
>> On Wed, Jun 05, 2019 at 04:52:07PM +0800, Wei Yang wrote:
>>> On Wed, Jun 05, 2019 at 02:41:08PM +0800, Peter Xu wrote:
>>> >On Wed, Jun 05, 2019 at 09:08:28AM +0800, Wei Yang wrote:
&
On Wed, Jun 05, 2019 at 02:27:11PM +0200, Philippe Mathieu-Daud?? wrote:
>migratioin -> migration
Ah... I should take an English lesson...
Thanks
--
Wei Yang
Help you, Help me
On Wed, Jun 05, 2019 at 01:53:18PM +0200, Juan Quintela wrote:
>From: Wei Yang
>
>During migration, we would sync bitmap from ram_list.dirty_memory to
>RAMBlock.bmap in cpu_physical_memory_sync_dirty_bitmap().
>
>Since we set RAMBlock.bmap and ram_list.dirty_memory both to all
On Wed, Jun 05, 2019 at 02:26:52PM +0200, Philippe Mathieu-Daud?? wrote:
>migratioin -> migration
Ah, you are right.
--
Wei Yang
Help you, Help me
On Wed, Jun 05, 2019 at 12:39:06PM +0200, Juan Quintela wrote:
>Wei Yang wrote:
>> Notification from recv thread is not ordered, which means we may be
>> notified by one MultiFDRecvParams but adjust packet_num for another.
>>
>> Move the adjustment after we are sure e
On Wed, Jun 05, 2019 at 02:41:08PM +0800, Peter Xu wrote:
>On Wed, Jun 05, 2019 at 09:08:28AM +0800, Wei Yang wrote:
>> In case we gets a queued page, the order of block is interrupted. We may
>> not rely on the complete_round flag to say we have already searched the
>> who
In case we gets a queued page, the order of block is interrupted. We may
not rely on the complete_round flag to say we have already searched the
whole blocks on the list.
Signed-off-by: Wei Yang
---
migration/ram.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/migration/ram.c b
On Tue, Jun 04, 2019 at 03:06:14PM +0800, Peter Xu wrote:
>On Tue, Jun 04, 2019 at 02:17:27PM +0800, Wei Yang wrote:
>> During migration, we would sync bitmap from ram_list.dirty_memory to
>> RAMBlock.bmap in cpu_physical_memory_sync_dirty_bitmap().
>>
>> Sin
->bmap blank on allocating would have a side effect on
migration_dirty_pages, since it is calculated from the result of
cpu_physical_memory_sync_dirty_bitmap(). To keep it right, we need to
set migration_dirty_pages to 0 in ram_state_init().
Signed-off-by: Wei Yang
Reviewed-by: Dr. David Alan Gilb
On Tue, Jun 04, 2019 at 11:51:24AM +0800, Peter Xu wrote:
>On Tue, Jun 04, 2019 at 08:28:10AM +0800, Wei Yang wrote:
>> During migration, we would sync bitmap from ram_list.dirty_memory to
>> RAMBlock.bmap in cpu_physical_memory_sync_dirty_bitmap().
>>
>> Sin
Notification from recv thread is not ordered, which means we may be
notified by one MultiFDRecvParams but adjust packet_num for another.
Move the adjustment after we are sure each recv thread are sync-ed.
Signed-off-by: Wei Yang
---
migration/ram.c | 8
1 file changed, 4 insertions
Hi, David
Do you prefer I resend 3/4 or it is ok for you to pick up here directly?
On Tue, May 28, 2019 at 09:46:59AM +0800, Wei Yang wrote:
>Just found several small places for unused variables.
>
>Wei Yang (4):
> migration: multifd_save_setup always return 0
> migration/ram.c
->bmap blank on allocating would have a side effect on
migration_dirty_pages, since it is calculated from the result of
cpu_physical_memory_sync_dirty_bitmap(). To keep it right, we need to
set migration_dirty_pages to 0 in ram_state_init().
Signed-off-by: Wei Yang
Reviewed-by: Dr. David Alan Gilb
On Mon, Jun 03, 2019 at 02:05:47PM +0800, Wei Yang wrote:
>On Mon, Jun 03, 2019 at 01:40:13PM +0800, Peter Xu wrote:
>>
>>Ah I see, thanks for the pointer. Then I would agree it's fine.
>>
>>I'm not an expert of TCG - I'm curious on why all those three
Igor,
Do you have some spare time to take a look the general idea?
On Mon, May 13, 2019 at 02:19:04PM +0800, Wei Yang wrote:
>Now MADT is highly depend in architecture and machine type and leaves
>duplicated code in different architecture. The series here tries to generalize
>it
we'll sooner or later copy all 1s from the ramblock bitmap
>
>(2) imho you can move "migration_dirty_pages = 0" into
> ram_list_init_bitmaps() too to let them be together
>
I will address these two comments and send v2.
Thanks.
>--
>Peter Xu
--
Wei Yang
Help you, Help me
On Mon, Jun 03, 2019 at 10:35:27AM +0800, Peter Xu wrote:
>On Mon, Jun 03, 2019 at 09:33:05AM +0800, Wei Yang wrote:
>> On Sat, Jun 01, 2019 at 11:34:41AM +0800, Peter Xu wrote:
>> >On Fri, May 31, 2019 at 05:43:37PM +0100, Dr. David Alan Gilbert wrote:
>> &
On Sat, Jun 01, 2019 at 11:34:41AM +0800, Peter Xu wrote:
>On Fri, May 31, 2019 at 05:43:37PM +0100, Dr. David Alan Gilbert wrote:
>> * Wei Yang (richardw.y...@linux.intel.com) wrote:
>> > During migration, we would sync bitmap from ram_list.dirty_memory to
>
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.
>>
>> Sig
On Wed, May 29, 2019 at 10:57:50AM +0200, Igor Mammedov wrote:
>On Wed, 29 May 2019 08:32:14 +0800
>Wei Yang wrote:
>
>> On Tue, May 28, 2019 at 02:26:27PM +0200, Igor Mammedov wrote:
>> >On Tue, 28 May 2019 09:35:48 +0800
>> >Wei Yang wrote:
>> >
>
On Tue, May 28, 2019 at 11:01:32PM -0400, Michael S. Tsirkin wrote:
>On Tue, Mar 26, 2019 at 10:43:20AM +0800, Wei Yang wrote:
>> arm and i386 has almost the same function acpi_add_rom_blob(), except
>> giving different FWCfgCallback function.
>>
>> This patch moves acp
On Tue, May 28, 2019 at 10:16:06AM +0200, Juan Quintela wrote:
>Wei Yang wrote:
>> Besides init and destroy, MultiFDSendParams.sem_sync is not really used.
>>
>> Signed-off-by: Wei Yang
>
>Reviewed-by: Juan Quintela
>
>I mad SendParamas and RecvParams identi
On Tue, May 28, 2019 at 10:12:39AM +0200, Juan Quintela wrote:
>Wei Yang wrote:
>> MultiFDPacket_t.offset is allocated to store MultiFDPages_t.offset.
>>
>> It would be better to use the same type.
>>
>> Signed-off-by: Wei Yang
>> ---
>> migration
On Tue, May 28, 2019 at 10:11:11AM +0200, Juan Quintela wrote:
>Wei Yang wrote:
>> Signed-off-by: Wei Yang
>> ---
>> migration/migration.c | 7 +--
>> 1 file changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/migration/migration.c b/mi
On Tue, May 28, 2019 at 02:26:27PM +0200, Igor Mammedov wrote:
>On Tue, 28 May 2019 09:35:48 +0800
>Wei Yang wrote:
>
>> On Mon, May 27, 2019 at 02:21:14PM +0200, Igor Mammedov wrote:
>> >On Thu, 11 Apr 2019 15:17:39 +0800
>> >Wei Yang wrote:
>> >
&
Signed-off-by: Wei Yang
---
migration/ram.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
index 5d31f7bd4c..c9a9f7489b 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -892,8 +892,6 @@ static int multifd_recv_unfill_packet(MultiFDRecvParams *p
Besides init and destroy, MultiFDSendParams.sem_sync is not really used.
Signed-off-by: Wei Yang
---
migration/ram.c | 4
1 file changed, 4 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
index dcf4c54eb5..5d31f7bd4c 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -661,8
MultiFDPacket_t.offset is allocated to store MultiFDPages_t.offset.
It would be better to use the same type.
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 4c60869226..dcf4c54eb5 100644
Signed-off-by: Wei Yang
---
migration/migration.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/migration/migration.c b/migration/migration.c
index d0a0f68f11..3aae4f2734 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -3336,12 +3336,7 @@ void
Just found several small places for unused variables.
Wei Yang (4):
migration: multifd_save_setup always return 0
migration/ram.c: use same type in MultiFDPages_t to define offsest
migration/ram.c: MultiFDSendParams.sem_sync is not really used
migration/ram.c: multifd_send_state->count
On Mon, May 27, 2019 at 02:21:14PM +0200, Igor Mammedov wrote:
>On Thu, 11 Apr 2019 15:17:39 +0800
>Wei Yang wrote:
>
>> pc_memory_pre_plug() is called during hotplug for both pc-dimm and
>> nvdimm. This is more proper to check apci hotplug capability before
>> check
On Mon, May 27, 2019 at 10:41:57AM -0400, Michael S. Tsirkin wrote:
>On Mon, May 27, 2019 at 10:34:23AM +0800, Wei Yang wrote:
>> On Tue, Mar 26, 2019 at 10:43:20AM +0800, Wei Yang wrote:
>> >arm and i386 has almost the same function acpi_add_rom_blob(), except
>> >giv
On Tue, Mar 26, 2019 at 10:43:20AM +0800, Wei Yang wrote:
>arm and i386 has almost the same function acpi_add_rom_blob(), except
>giving different FWCfgCallback function.
>
>This patch moves acpi_add_rom_blob() to utils.c by passing
>FWCfgCallback to it.
>
>Signed-off-by: W
On Thu, Apr 11, 2019 at 10:32:39AM +0200, Thomas Huth wrote:
>On 11/04/2019 09.17, Wei Yang wrote:
>> pc_memory_pre_plug() is called during hotplug for both pc-dimm and
>> nvdimm. This is more proper to check apci hotplug capability before
>> check nvdimm specific capability.
On Tue, May 21, 2019 at 08:36:42PM -0500, Eric Blake wrote:
>On 5/21/19 7:53 PM, Wei Yang wrote:
>> On Tue, May 21, 2019 at 05:28:27PM +0200, Markus Armbruster wrote:
>>> Eric Blake writes:
>>>
>>>> On 5/21/19 3:12 AM, Wei Yang wrote:
>>>>
On Tue, May 21, 2019 at 05:28:27PM +0200, Markus Armbruster wrote:
>Eric Blake writes:
>
>> On 5/21/19 3:12 AM, Wei Yang wrote:
>>> All the python script in scripts/qapi is used to generate qapi code. Use
>>> wildcard to simplify it.
>>>
>>> Si
On Tue, May 21, 2019 at 07:00:12AM -0500, Eric Blake wrote:
>On 5/21/19 3:12 AM, Wei Yang wrote:
>> All the python script in scripts/qapi is used to generate qapi code. Use
>> wildcard to simplify it.
>>
>> Signed-off-by: Wei Yang
>> ---
>> Makefile | 8 +
All the python script in scripts/qapi is used to generate qapi code. Use
wildcard to simplify it.
Signed-off-by: Wei Yang
---
Makefile | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/Makefile b/Makefile
index 155f066a20..38b74782d9 100644
--- a/Makefile
+++ b/Makefile
build_append_foo() API doesn't need explicit endianness conversions
which eliminates a source of errors and it makes build_mcfg() look like
declarative definition of MCFG table in ACPI spec, which makes it easy
to review.
Signed-off-by: Wei Yang
Suggested-by: Igor Mammedov
Reviewed-by:
Now we have two identical build_mcfg functions.
Consolidate them in acpi/pci.c.
Signed-off-by: Wei Yang
v4:
* ACPI_PCI depends on both ACPI and PCI
* rebase on latest master, adjust arm Kconfig
v3:
* adjust changelog based on Igor's suggestion
---
default-configs/i386-softmmu.mak
PCI
* rebase on latest master, adjust arm Kconfig
* miss the reserved[8] of MCFG, add it back
* make sure bios-tables-test all OK
Wei Yang (2):
hw/acpi: Consolidate build_mcfg to pci.c
acpi: pci: use build_append_foo() API to construct MCFG
default-configs/i386-softmmu.mak | 1 +
hw/a
On Mon, May 20, 2019 at 11:44:28PM -0400, Michael S. Tsirkin wrote:
>On Tue, May 21, 2019 at 11:32:49AM +0800, Wei Yang wrote:
>> build_append_foo() API doesn't need explicit endianness conversions
>> which eliminates a source of errors and it makes build_mcfg() look like
>&
build_append_foo() API doesn't need explicit endianness conversions
which eliminates a source of errors and it makes build_mcfg() look like
declarative definition of MCFG table in ACPI spec, which makes it easy
to review.
Signed-off-by: Wei Yang
Suggested-by: Igor Mammedov
Reviewed-by:
Now we have two identical build_mcfg functions.
Consolidate them in acpi/pci.c.
Signed-off-by: Wei Yang
---
v5:
* ACPI_PCI depends on both ACPI and PCI
* rebase on latest master, adjust arm Kconfig
v3:
* adjust changelog based on Igor's suggestion
---
default-configs/i386-softmm
PCI
* rebase on latest master, adjust arm Kconfig
* miss the reserved[8] of MCFG, add it back
* make sure bios-tables-test all OK
Wei Yang (2):
hw/acpi: Consolidate build_mcfg to pci.c
acpi: pci: use build_append_foo() API to construct MCFG
default-configs/i386-softmmu.mak | 1 +
hw/a
On Mon, May 20, 2019 at 06:55:53PM -0400, Michael S. Tsirkin wrote:
>On Mon, May 20, 2019 at 08:59:51AM +0800, Wei Yang wrote:
>> This patch set tries to generalize MCFG table build process. And it is
>> based on one un-merged patch from Igor, which is included in this serials
e a global variable in each thread is not a good idea.
This would be better to use an array to assign ops instead of *if*. In case
you would have several compress methods, the code would be difficult to read.
>
> while (true) {
> qemu_sem_wait(&p->sem);
>@@ -1399,7 +1497,11 @@ static void *multifd_recv_thread(void *opaque)
> trace_multifd_recv_thread_start(p->id);
> rcu_register_thread();
>
>-multifd_recv_state->ops = &multifd_none_ops;
>+if (migrate_use_multifd_zlib()) {
>+multifd_recv_state->ops = &multifd_zlib_ops;
>+} else {
>+multifd_recv_state->ops = &multifd_none_ops;
>+}
> while (true) {
> uint32_t used;
> uint32_t flags;
>--
>2.21.0
>
--
Wei Yang
Help you, Help me
#x27;: 'MultifdCompress',
>- 'data': [ 'none' ] }
>+ 'data': [ 'none', 'zlib' ] }
>
> ##
> # @MigrationParameter:
>diff --git a/tests/migration-test.c b/tests/migration-test.c
>index 8a1ccc2516..2dd4d4c5b4 100644
>--- a/tests/migration-test.c
>+++ b/tests/migration-test.c
>@@ -1119,6 +1119,11 @@ static void test_multifd_tcp_none(void)
> test_multifd_tcp("none");
> }
>
>+static void test_multifd_tcp_zlib(void)
>+{
>+test_multifd_tcp("zlib");
>+}
>+
> int main(int argc, char **argv)
> {
> char template[] = "/tmp/migration-test-XX";
>@@ -1174,6 +1179,7 @@ int main(int argc, char **argv)
> /* qtest_add_func("/migration/ignore_shared", test_ignore_shared); */
> qtest_add_func("/migration/xbzrle/unix", test_xbzrle_unix);
> qtest_add_func("/migration/multifd/tcp/none", test_multifd_tcp_none);
>+qtest_add_func("/migration/multifd/tcp/zlib", test_multifd_tcp_zlib);
Actually zlib is not enabled at this moment, the test here may not touch the
real functionality.
>
> ret = g_test_run();
>
>--
>2.21.0
>
--
Wei Yang
Help you, Help me
32_t flags;
>@@ -1353,8 +1398,7 @@ static void *multifd_recv_thread(void *opaque)
> qemu_mutex_unlock(&p->mutex);
>
> if (used) {
>-ret = qio_channel_readv_all(p->c, p->pages->iov,
>-used, &local_err);
>+ret = multifd_recv_state->ops->recv_pages(p, used, &local_err);
> if (ret != 0) {
> break;
> }
>--
>2.21.0
>
--
Wei Yang
Help you, Help me
meters:
>@@ -817,6 +837,9 @@
> #Defaults to 99.
> # (Since 3.1)
> #
>+# @multifd-compress: Which compression method to use.
>+#Defaults to none. (Since 4.1)
>+#
> # Since: 2.4
> ##
> { 'struct': 'MigrationParameters',
>@@ -840,7 +863,8 @@
> '*multifd-channels': 'uint8',
> '*xbzrle-cache-size': 'size',
> '*max-postcopy-bandwidth': 'size',
>-'*max-cpu-throttle':'uint8'} }
>+'*max-cpu-throttle': 'uint8',
>+'*multifd-compress': 'MultifdCompress' } }
>
> ##
> # @query-migrate-parameters:
--
Wei Yang
Help you, Help me
sit_type_MultifdCompress(v, param, &compress_type, &err);
>+if (err) {
>+ break;
>+}
>+if (compress_type < 0 || compress_type >= MULTIFD_COMPRESS__MAX) {
A warning during build:
hmp.c:1835:27: warning: comparison of unsigned enum expression < 0 is always
false [-Wtautological-compare]
if (compress_type < 0 || compress_type >= MULTIFD_COMPRESS__MAX) {
--
Wei Yang
Help you, Help me
tests/migration-test.c b/tests/migration-test.c
>index 65d5e256a7..8a1ccc2516 100644
>--- a/tests/migration-test.c
>+++ b/tests/migration-test.c
Well, may I suggest to split the test into another one?
>@@ -449,7 +449,6 @@ static void migrate_check_parameter_str(QTestState *who,
>const char *parameter,
> g_free(result);
> }
>
>-__attribute__((unused))
> static void migrate_set_parameter_str(QTestState *who, const char *parameter,
> const char *value)
> {
>@@ -1065,7 +1064,7 @@ static void test_precopy_tcp(void)
> g_free(uri);
> }
>
>-static void test_multifd_tcp(void)
>+static void test_multifd_tcp(const char *method)
> {
> char *uri;
> QTestState *from, *to;
>@@ -1087,6 +1086,9 @@ static void test_multifd_tcp(void)
> migrate_set_parameter_int(from, "multifd-channels", 2);
> migrate_set_parameter_int(to, "multifd-channels", 2);
>
>+migrate_set_parameter_str(from, "multifd-compress", method);
>+migrate_set_parameter_str(to, "multifd-compress", method);
>+
> migrate_set_capability(from, "multifd", "true");
> migrate_set_capability(to, "multifd", "true");
> /* Wait for the first serial output from the source */
>@@ -1112,6 +1114,11 @@ static void test_multifd_tcp(void)
> test_migrate_end(from, to, true);
> }
>
>+static void test_multifd_tcp_none(void)
>+{
>+test_multifd_tcp("none");
>+}
>+
> int main(int argc, char **argv)
> {
> char template[] = "/tmp/migration-test-XX";
>@@ -1166,7 +1173,7 @@ int main(int argc, char **argv)
> qtest_add_func("/migration/precopy/tcp", test_precopy_tcp);
> /* qtest_add_func("/migration/ignore_shared", test_ignore_shared); */
> qtest_add_func("/migration/xbzrle/unix", test_xbzrle_unix);
>-qtest_add_func("/migration/multifd/tcp", test_multifd_tcp);
>+qtest_add_func("/migration/multifd/tcp/none", test_multifd_tcp_none);
>
> ret = g_test_run();
>
>--
>2.21.0
>
--
Wei Yang
Help you, Help me
dress");
>+
>+migrate(from, uri, "{}");
>+
>+wait_for_migration_pass(from);
>+
>+/* 300ms it should converge */
>+migrate_set_parameter_int(from, "downtime-limit", 600);
>+
>+if (!got_stop) {
>+qtest_qmp_eventwait(from, "STOP"
On Wed, May 15, 2019 at 02:15:38PM +0200, Juan Quintela wrote:
>We would need _str ones on the next patch.
>
>Signed-off-by: Juan Quintela
Reviewed-by: Wei Yang
>---
> tests/migration-test.c | 49 +-
> 1 file changed, 25 insertion
On Wed, May 15, 2019 at 02:15:37PM +0200, Juan Quintela wrote:
>It uses num in multifd_send(). Make it coherent.
>
>Signed-off-by: Juan Quintela
Reviewed-by: Wei Yang
>---
> migration/trace-events | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/
t;- Parameter is now an enum (soon will see sztd)
^^^
>
--
Wei Yang
Help you, Help me
On Mon, May 20, 2019 at 08:59:56AM +0800, Wei Yang wrote:
>Now we have two identical build_mcfg functions.
>
>Consolidate them in acpi/pci.c.
>
>Signed-off-by: Wei Yang
>Reviewed-by: Philippe Mathieu-Daudé
>Reviewed-by: Igor Mammedov
Oops, I should drop these SOB.
>
gt;+
>+test_migrate_end(from, to, true);
>+}
>+
> int main(int argc, char **argv)
> {
> char template[] = "/tmp/migration-test-XX";
>@@ -1082,6 +1129,7 @@ int main(int argc, char **argv)
> qtest_add_func("/migration/precopy/tcp", test_precopy_tcp);
> /* qtest_add_func("/migration/ignore_shared", test_ignore_shared); */
> qtest_add_func("/migration/xbzrle/unix", test_xbzrle_unix);
>+qtest_add_func("/migration/multifd/tcp", test_multifd_tcp);
>
> ret = g_test_run();
>
>--
>2.21.0
>
--
Wei Yang
Help you, Help me
Now we have two identical build_mcfg functions.
Consolidate them in acpi/pci.c.
Signed-off-by: Wei Yang
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Igor Mammedov
---
v4:
* ACPI_PCI depends on both ACPI and PCI
* rebase on latest master, adjust arm Kconfig
v3:
* adjust changelog
This is obvious the member in AcpiMcfgInfo describe MCFG's property.
Remove the mcfg_ prefix.
Signed-off-by: Wei Yang
Suggested-by: Igor Mammedov
Reviewed-by: Igor Mammedov
Reviewed-by: Philippe Mathieu-Daudé
---
hw/i386/acpi-build.c | 14 +++---
1 file changed, 7 insertions(
To build MCFG, two information is necessary:
* bus number
* base address
Abstract these two information to AcpiMcfgInfo so that build_mcfg and
build_mcfg_q35 will have the same declaration.
Signed-off-by: Wei Yang
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Igor Mammedov
---
v4
build_append_foo() API doesn't need explicit endianness conversions
which eliminates a source of errors and it makes build_mcfg() look like
declarative definition of MCFG table in ACPI spec, which makes it easy
to review.
Signed-off-by: Wei Yang
Suggested-by: Igor Mammedov
Reviewed-by:
g
cross version migration in both directions unconditionally.
Signed-off-by: Igor Mammedov
Signed-off-by: Wei Yang
Reviewed-by: Philippe Mathieu-Daudé
---
hw/i386/acpi-build.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acp
mcfg_start points to the start of MCFG table and is used in
build_header. While this information could be derived from mcfg.
This patch removes the unnecessary variable mcfg_start.
Signed-off-by: Wei Yang
Reviewed-by: Igor Mammedov
Reviewed-by: Philippe Mathieu-Daudé
---
hw/arm/virt-acpi
ack
* make sure bios-tables-test all OK
v3->v4:
* adjust comment to give more information about MCFG table
v2->v3:
* Includes the un-merged patch from Igor
* use build_append_foo() API to construct MCFG
Igor Mammedov (1):
q35: acpi: do not create dummy MCFG table
Wei Yang
On Fri, May 17, 2019 at 04:29:03PM +0200, Igor Mammedov wrote:
>On Fri, 17 May 2019 12:59:57 +0000
>Wei Yang wrote:
>
>> On Fri, May 17, 2019 at 01:11:16PM +0200, Igor Mammedov wrote:
>> >On Fri, 17 May 2019 08:51:14 +0800
>> >Wei Yang wrote:
>> >
On Fri, May 17, 2019 at 01:13:15PM +0200, Igor Mammedov wrote:
>On Fri, 17 May 2019 10:59:03 +0800
>Wei Yang wrote:
>
[..]
>>
>> Well, I hope this will not block the merge.
>>
>> I took a look in the change of default-configs/arm-softmmu.mak. The general
>
On Fri, May 17, 2019 at 01:11:16PM +0200, Igor Mammedov wrote:
>On Fri, 17 May 2019 08:51:14 +0800
>Wei Yang wrote:
>
>> Pointed out by Philippe Mathieu-Daud?? .
>>
>> Signed-off-by: Wei Yang
>> ---
>> hw/acpi/Kconfig | 2 +-
>> 1 file changed, 1 in
On Fri, May 17, 2019 at 10:14:11AM +0200, Philippe Mathieu-Daudé wrote:
>On 5/17/19 5:12 AM, Wei Yang wrote:
>> On Fri, May 17, 2019 at 10:59:03AM +0800, Wei Yang wrote:
>>> On Thu, May 16, 2019 at 08:53:04PM +0200, Philippe Mathieu-Daudé wrote:
>>>> On Thu, Ma
On Fri, May 17, 2019 at 10:59:03AM +0800, Wei Yang wrote:
>On Thu, May 16, 2019 at 08:53:04PM +0200, Philippe Mathieu-Daudé wrote:
>>On Thu, May 16, 2019 at 8:33 PM Philippe Mathieu-Daudé
>> wrote:
>>> On 5/16/19 6:04 PM, Peter Maydell wrote:
>>> > On Thu, 16 M
block the merge.
I took a look in the change of default-configs/arm-softmmu.mak. The general
idea from Thomas is put those hard-coded config to Kconfig.
This is fine and what I need to change in my patch is to select ACPI_PCI in
the proper place, if my understanding is correct.
Two things I need to fix:
* add select ACPI_PCI in proper place of hw/arm/Kconfig
* add a dummy build_mcfg() for link when ACPI_PCI is not configured.
Then I have two questions:
* In hw/arm/Kconfig, I don't see one option contains both PCI and ACPI. I am
confused where to put the select.
* put dummy build_mcfg() in aml-build.c works. Igor, do you like this? Or
you haver other preference?
>Sadly both series clash :(
>
>Regards,
>
>Phil.
--
Wei Yang
Help you, Help me
t;- keep default-configs/arm-softmmu.mak from master:
>
> git checkout origin/master default-configs/arm-softmmu.mak
>
>- applied the following !fixup snippet:
>
>-- >8 --
>--- a/hw/acpi/Kconfig
>+++ b/hw/acpi/Kconfig
>@@ -25,7 +25,7 @@ config ACPI_NVDIMM
>
> config ACPI_PCI
> bool
>-depends on ACPI
>+depends on ACPI && PCI
Take a look into hw/arm/Kconfig. Only ARM_VIRT selects ACPI, but this one
doesn't select PCI.
Which option on arm select both?
>
>---
>
>I felt it easier to review on top of "hw/acpi: Improve build modularity"
>https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg04718.html
>
>Sadly both series clash :(
>
>Regards,
>
>Phil.
--
Wei Yang
Help you, Help me
Pointed out by Philippe Mathieu-Daudé .
Signed-off-by: Wei Yang
---
hw/acpi/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/acpi/Kconfig b/hw/acpi/Kconfig
index 7265843cc3..7c59cf900b 100644
--- a/hw/acpi/Kconfig
+++ b/hw/acpi/Kconfig
@@ -25,7 +25,7 @@ config
build_append_foo() API doesn't need explicit endianness conversions
which eliminates a source of errors and it makes build_mcfg() look like
declarative definition of MCFG table in ACPI spec, which makes it easy
to review.
Signed-off-by: Wei Yang
Suggested-by: Igor Mammedov
---
v2:
*
On Thu, May 16, 2019 at 08:35:43PM +0200, Philippe Mathieu-Daudé wrote:
>On 4/19/19 2:30 AM, Wei Yang wrote:
>> Now we have two identical build_mcfg functions.
>>
>> Consolidate them in acpi/pci.c.
>>
>> Signed-off-by: Wei Yang
>> Reviewed-by: Phili
t;>> -typedef struct AcpiTableMcfg AcpiTableMcfg;
>>> -
>>> /*
>>> * TCPA Description Table
>>> *
>>> --
>>> 2.19.1
--
Wei Yang
Help you, Help me
On Wed, May 15, 2019 at 10:38:37AM +0100, Dr. David Alan Gilbert wrote:
>* Wei Yang (richardw.y...@linux.intel.com) wrote:
>> On Wed, May 15, 2019 at 02:38:27PM +0800, Wei Yang wrote:
>> >On Tue, May 14, 2019 at 04:18:14PM +0100, Dr. David Alan Gilbert wrote:
>>
On Wed, May 15, 2019 at 09:04:51AM +0100, Dr. David Alan Gilbert wrote:
>* Wei Yang (richardw.y...@linux.intel.com) wrote:
>> On Tue, May 14, 2019 at 03:27:02PM +0100, Dr. David Alan Gilbert wrote:
>> >* Wei Yang (richardw.y...@linux.intel.com) wrote:
>> >&
On Wed, May 15, 2019 at 07:29:17AM +0200, Philippe Mathieu-Daudé wrote:
>On 5/15/19 3:10 AM, Michael S. Tsirkin wrote:
>> On Fri, Apr 19, 2019 at 08:30:53AM +0800, Wei Yang wrote:
>>> build_append_foo() API doesn't need explicit endianness conversions
>>> which elim
On Tue, May 14, 2019 at 09:10:34PM -0400, Michael S. Tsirkin wrote:
>On Fri, Apr 19, 2019 at 08:30:53AM +0800, Wei Yang wrote:
>> build_append_foo() API doesn't need explicit endianness conversions
>> which eliminates a source of errors and it makes build_mcfg() look like
>&
301 - 400 of 739 matches
Mail list logo
