[PATCH] paaudio: add missing break

2019-10-22 Thread Gerd Hoffmann
CID 1406449

Signed-off-by: Gerd Hoffmann 
---
 audio/paaudio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/audio/paaudio.c b/audio/paaudio.c
index df541a72d3a9..55a91f898073 100644
--- a/audio/paaudio.c
+++ b/audio/paaudio.c
@@ -385,6 +385,7 @@ static pa_stream *qpa_simple_new (
 map.map[5] = PA_CHANNEL_POSITION_REAR_RIGHT;
 map.map[6] = PA_CHANNEL_POSITION_SIDE_LEFT;
 map.map[7] = PA_CHANNEL_POSITION_SIDE_RIGHT;
+break;
 
 default:
 dolog("Internal error: unsupported channel count %d\n", ss->channels);
-- 
2.18.1




[PATCH 1/3] migration/multifd: fix nullptr access in terminating multifd threads

2019-10-22 Thread cenjiahui
From: Jiahui Cen 

One multifd channel will shutdown all the other multifd's IOChannel when it
fails to receive an IOChannel. In this senario, if some multifds had not
received its IOChannel yet, it would try to shutdown its IOChannel which could
cause nullptr access at qio_channel_shutdown.

Here is the coredump stack:
#0  object_get_class (obj=obj@entry=0x0) at qom/object.c:908
#1  0x5563fdbb8f4a in qio_channel_shutdown (ioc=0x0, 
how=QIO_CHANNEL_SHUTDOWN_BOTH, errp=0x0) at io/channel.c:355
#2  0x5563fd7b4c5f in multifd_recv_terminate_threads (err=) at migration/ram.c:1280
#3  0x5563fd7bc019 in multifd_recv_new_channel 
(ioc=ioc@entry=0x556400255610, errp=errp@entry=0x7ffec07dce00) at 
migration/ram.c:1478
#4  0x5563fda82177 in migration_ioc_process_incoming 
(ioc=ioc@entry=0x556400255610, errp=errp@entry=0x7ffec07dce30) at 
migration/migration.c:605
#5  0x5563fda8567d in migration_channel_process_incoming 
(ioc=0x556400255610) at migration/channel.c:44
#6  0x5563fda83ee0 in socket_accept_incoming_migration 
(listener=0x5563fff6b920, cioc=0x556400255610, opaque=) at 
migration/socket.c:166
#7  0x5563fdbc25cd in qio_net_listener_channel_func (ioc=, condition=, opaque=) at io/net-listener.c:54
#8  0x7f895b6fe9a9 in g_main_context_dispatch () from 
/usr/lib64/libglib-2.0.so.0
#9  0x5563fdc18136 in glib_pollfds_poll () at util/main-loop.c:218
#10 0x5563fdc181b5 in os_host_main_loop_wait (timeout=10) at 
util/main-loop.c:241
#11 0x5563fdc183a2 in main_loop_wait (nonblocking=nonblocking@entry=0) 
at util/main-loop.c:517
#12 0x5563fd8edb37 in main_loop () at vl.c:1791
#13 0x5563fd74fd45 in main (argc=, argv=, 
envp=) at vl.c:4473

To fix it up, let's check p->c before calling qio_channel_shutdown.

Signed-off-by: Jiahui Cen 
Signed-off-by: Ying Fang 
---
 migration/ram.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/migration/ram.c b/migration/ram.c
index 5078f94..dc63692 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -1280,7 +1280,9 @@ static void multifd_recv_terminate_threads(Error *err)
- normal quit, i.e. everything went fine, just finished
- error quit: We close the channels so the channel threads
  finish the qio_channel_read_all_eof() */
-qio_channel_shutdown(p->c, QIO_CHANNEL_SHUTDOWN_BOTH, NULL);
+if (p->c) {
+qio_channel_shutdown(p->c, QIO_CHANNEL_SHUTDOWN_BOTH, NULL);
+}
 qemu_mutex_unlock(>mutex);
 }
 }
-- 
1.8.3.1





[PATCH 2/3] migration/multifd: fix destroyed mutex access in terminating multifd threads

2019-10-22 Thread cenjiahui
From: Jiahui Cen 

One multifd will lock all the other multifds' IOChannel mutex to inform them
to quit by setting p->quit or shutting down p->c. In this senario, if some
multifds had already been terminated and 
multifd_load_cleanup/multifd_save_cleanup
had destroyed their mutex, it could cause destroyed mutex access when trying
lock their mutex.

Here is the coredump stack:
#0  0x7f81a2794437 in raise () from /usr/lib64/libc.so.6
#1  0x7f81a2795b28 in abort () from /usr/lib64/libc.so.6
#2  0x7f81a278d1b6 in __assert_fail_base () from /usr/lib64/libc.so.6
#3  0x7f81a278d262 in __assert_fail () from /usr/lib64/libc.so.6
#4  0x55eb1bfadbd3 in qemu_mutex_lock_impl (mutex=0x55eb1e2d1988, 
file=, line=) at util/qemu-thread-posix.c:64
#5  0x55eb1bb4564a in multifd_send_terminate_threads (err=) at migration/ram.c:1015
#6  0x55eb1bb4bb7f in multifd_send_thread (opaque=0x55eb1e2d19f8) at 
migration/ram.c:1171
#7  0x55eb1bfad628 in qemu_thread_start (args=0x55eb1e170450) at 
util/qemu-thread-posix.c:502
#8  0x7f81a2b36df5 in start_thread () from /usr/lib64/libpthread.so.0
#9  0x7f81a286048d in clone () from /usr/lib64/libc.so.6

To fix it up, let's destroy the mutex after all the other multifd threads had
been terminated.

Signed-off-by: Jiahui Cen 
Signed-off-by: Ying Fang 
---
 migration/ram.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/migration/ram.c b/migration/ram.c
index dc63692..24a8906 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -1032,6 +1032,10 @@ void multifd_save_cleanup(void)
 if (p->running) {
 qemu_thread_join(>thread);
 }
+}
+for (i = 0; i < migrate_multifd_channels(); i++) {
+MultiFDSendParams *p = _send_state->params[i];
+
 socket_send_channel_destroy(p->c);
 p->c = NULL;
 qemu_mutex_destroy(>mutex);
@@ -1308,6 +1312,10 @@ int multifd_load_cleanup(Error **errp)
 qemu_sem_post(>sem_sync);
 qemu_thread_join(>thread);
 }
+}
+for (i = 0; i < migrate_multifd_channels(); i++) {
+MultiFDRecvParams *p = _recv_state->params[i];
+
 object_unref(OBJECT(p->c));
 p->c = NULL;
 qemu_mutex_destroy(>mutex);
-- 
1.8.3.1





Re: [Qemu-devel] [PATCH] pci_bridge: fix a typo in comment

2019-10-22 Thread maozy

ping...

On 11/8/18 9:12 PM, Philippe Mathieu-Daudé wrote:

Cc'ing qemu-trivial@

On 8/11/18 13:21, Mao Zhongyi wrote:

Signed-off-by: Mao Zhongyi 


Reviewed-by: Philippe Mathieu-Daudé 


---
  hw/pci/pci_bridge.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
index ee9dff2d3a..da8daa3ff2 100644
--- a/hw/pci/pci_bridge.c
+++ b/hw/pci/pci_bridge.c
@@ -310,7 +310,7 @@ void pci_bridge_reset(DeviceState *qdev)
  /*
   * the default values for base/limit registers aren't specified
- * in the PCI-to-PCI-bridge spec. So we don't thouch them here.
+ * in the PCI-to-PCI-bridge spec. So we don't touch them here.
   * Each implementation can override it.
   * typical implementation does
   * zero base/limit registers or









Re: [PATCH] net: add tulip (dec21143) driver

2019-10-22 Thread Jason Wang



On 2019/10/22 下午8:02, Peter Maydell wrote:

On Tue, 22 Oct 2019 at 04:30, Jason Wang  wrote:

On 2019/10/20 上午1:38, Sven Schnelle wrote:

This adds the basic functionality to emulate a Tulip NIC.

Implemented are:

- RX and TX functionality
- Perfect Frame Filtering
- Big/Little Endian descriptor support
- 93C46 EEPROM support
- LXT970 PHY

Not implemented, mostly because i had no OS using these functions:

- Imperfect frame filtering
- General Purpose Timer
- Transmit automatic polling
- Boot ROM support
- SIA interface
- Big/Little Endian data buffer conversion

Successfully tested with the following Operating Systems:

- MSDOS with Microsoft Network Client 3.0 and DEC ODI drivers
- HPPA Linux
- Windows XP
- HP-UX

Signed-off-by: Sven Schnelle
---

Applied.

Hi Jason; I just sent some code review comments on this patch
so you might want to hold off on applying it for now.

thanks
-- PMM



Sure.

Thanks




[PATCH 3/3] migration/multifd: fix potential wrong acception order of IOChannel

2019-10-22 Thread cenjiahui
From: Jiahui Cen 

Multifd assumes the migration thread IOChannel is always established before
the multifd IOChannels, but this assumption will be broken in many situations
like network packet loss.

For example:
Step1: Source (migration thread IOChannel)  --SYN-->  Destination
Step2: Source (migration thread IOChannel)  <--SYNACK  Destination
Step3: Source (migration thread IOChannel, lost) --ACK-->X  Destination
Step4: Source (multifd IOChannel) --SYN-->Destination
Step5: Source (multifd IOChannel) <--SYNACK   Destination
Step6: Source (multifd IOChannel, ESTABLISHED) --ACK-->  Destination
Step7: Destination accepts multifd IOChannel
Step8: Source (migration thread IOChannel, ESTABLISHED) -ACK,DATA->  Destination
Step9: Destination accepts migration thread IOChannel

The above situation can be reproduced by creating a weak network environment,
such as "tc qdisc add dev eth0 root netem loss 50%". The wrong acception order
will cause magic check failure and thus lead to migration failure.

This patch fixes this issue by sending a migration IOChannel initial packet with
a unique id when using multifd migration. Since the multifd IOChannels will also
send initial packets, the destination can judge whether the processing IOChannel
belongs to multifd by checking the id in the initial packet. This mechanism can
ensure that different IOChannels will go to correct branches in our test.

Signed-off-by: Jiahui Cen 
Signed-off-by: Ying Fang 
---
 migration/channel.c   |  9 +
 migration/migration.c | 49 -
 migration/migration.h |  3 +++
 migration/ram.c   | 38 +-
 migration/ram.h   |  3 ++-
 migration/socket.c|  7 +++
 6 files changed, 58 insertions(+), 51 deletions(-)

diff --git a/migration/channel.c b/migration/channel.c
index 20e4c8e..7462181 100644
--- a/migration/channel.c
+++ b/migration/channel.c
@@ -82,6 +82,15 @@ void migration_channel_connect(MigrationState *s,
 return;
 }
 } else {
+if (migrate_use_multifd()) {
+/* multifd migration cannot distinguish migration IOChannel
+ * from multifd IOChannels, so we need to send an initial 
packet
+ * to show it is migration IOChannel
+ */
+migration_send_initial_packet(ioc,
+  migrate_multifd_channels(),
+  );
+}
 QEMUFile *f = qemu_fopen_channel_output(ioc);
 
 qemu_mutex_lock(>qemu_file_lock);
diff --git a/migration/migration.c b/migration/migration.c
index 3febd0f..3da2baf 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -521,12 +521,6 @@ static void migration_incoming_setup(QEMUFile *f)
 {
 MigrationIncomingState *mis = migration_incoming_get_current();
 
-if (multifd_load_setup() != 0) {
-/* We haven't been able to create multifd threads
-   nothing better to do */
-exit(EXIT_FAILURE);
-}
-
 if (!mis->from_src_file) {
 mis->from_src_file = f;
 }
@@ -584,36 +578,41 @@ void migration_fd_process_incoming(QEMUFile *f)
 void migration_ioc_process_incoming(QIOChannel *ioc, Error **errp)
 {
 MigrationIncomingState *mis = migration_incoming_get_current();
-bool start_migration;
-
-if (!mis->from_src_file) {
-/* The first connection (multifd may have multiple) */
-QEMUFile *f = qemu_fopen_channel_input(ioc);
+Error *local_err = NULL;
+int id = 0;
 
-/* If it's a recovery, we're done */
-if (postcopy_try_recover(f)) {
-return;
-}
+if (migrate_use_multifd()) {
+id = migration_recv_initial_packet(ioc, _err);
+}
+if (!migrate_use_multifd() || id == migrate_multifd_channels()) {
+if (!mis->from_src_file) {
+/* The migration connection (multifd may have multiple) */
+QEMUFile *f = qemu_fopen_channel_input(ioc);
 
-migration_incoming_setup(f);
+/* If it's a recovery, we're done */
+if (postcopy_try_recover(f)) {
+return;
+}
 
-/*
- * Common migration only needs one channel, so we can start
- * right now.  Multifd needs more than one channel, we wait.
- */
-start_migration = !migrate_use_multifd();
-} else {
-Error *local_err = NULL;
+migration_incoming_setup(f);
+}
+} else if (id >= 0) {
 /* Multiple connections */
 assert(migrate_use_multifd());
-start_migration = multifd_recv_new_channel(ioc, _err);
+multifd_recv_new_channel(ioc, id, _err);
 if (local_err) {
 error_propagate(errp, local_err);
 return;
 }
+} else {
+/* Bad connections */
+multifd_recv_terminate_threads(local_err);
+

Re: [PATCH v4 0/3] some fix in tests/migration

2019-10-22 Thread maozy

Hi,

patch2 has been merged into the master by Laurent Vivier.
patch3 is still not reviewed.

So ping...

Thanks,
Mao

On 10/5/19 1:32 AM, Mao Zhongyi wrote:

This patchset mainly fixes memory leak, typo and return
value of stress function in stress test.

v4-v3:
p1:
- remove redundant g_malloc return value judgment.
  [Laurent Vivier]
p3:
- always use exit_failure() as the exit function of main().
  [Laurent Vivier]
- update the commit message.

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 reached.[Laurent Vivier]
- update the commit message.

v2->v1:
- use g_autofree to release memory automatically instead
   of free(). [Alex Bennée]
   
Cc: arm...@redhat.com

Cc: laur...@vivier.eu
Cc: tony.ngu...@bt.com
Cc: alex.ben...@linaro.org

Mao Zhongyi (3):
   tests/migration: mem leak fix
   tests/migration: fix a typo in comment
   tests/migration:fix unreachable path in stress test

  tests/migration/stress.c | 36 
  1 file changed, 8 insertions(+), 28 deletions(-)







Re: [RFC PATCH] iothread: add set_iothread_poll_* commands

2019-10-22 Thread Eric Blake

On 10/22/19 9:28 PM, Zhenyu Ye wrote:


I will change the name argument to ENUM, such as,

 { 'enum': 'IothreadPollProperty',
   'data': [ 'max-ns', 'grow', 'shrink' ] }





ok, I will correct it, such as,

 { 'command': 'set-iothread-poll-param',
 'data': {'iothread-id': 'str', 'name': 'IothreadPollProperty', 'value': 
'int'} }



That's one approach.  But another approach would be:

{ 'command': 'set-iothread-poll-params',
  'data': { 'iothread-id': 'str',
'*max-ns': 'int', '*grow': 'int', '*shrink': 'int' } }

The difference on the wire is between:

{ "execute": "set-iothread-poll-param",
  "arguments": { "iothread-id": "thr1",
"name": "max-ns", "value": 1000 } }
{ "execute": "set-iothread-poll-param",
  "arguments": { "iothread-id": "thr1",
"name": "grow", "value": 100 } }

vs.

{ "execute": "set-iothread-poll-params",
  "arguments': { "iothread-id": "thr1",
 "max-ns": 1000, "grow": 100 } }

I'll leave it up to Markus to give guidance on which style is nicer.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org




Re: [RFC PATCH] iothread: add set_iothread_poll_* commands

2019-10-22 Thread Zhenyu Ye



On 2019/10/23 4:40, Eric Blake wrote:
> On 10/22/19 3:12 AM, yezhenyu (A) wrote:
>> Since qemu2.9, QEMU added three AioContext poll parameters to struct
>> IOThread: poll_max_ns, poll_grow and poll_shrink. These properties are
>> used to control iothread polling time.
>>
>> However, there isn't properly hmp commands to adjust them when the VM is
>> alive. It's useful to adjust them online when observing the impact of
>> different property value on performance.
>>
>> This patch add three hmp commands to adjust iothread poll-* properties
>> for special iothread:
>>
>> set_iothread_poll_max_ns: set the maximum polling time in ns;
>> set_iothread_poll_grow: set how many ns will be added to polling time;
>> set_iothread_poll_shrink: set how many ns will be removed from polling
>> time.
>>
>> Signed-off-by: Zhenyu Ye 
>> ---
>> hmp-commands.hx | 42 
>> hmp.c | 30 +++
>> hmp.h | 3 ++
>> include/sysemu/iothread.h | 6 +++
>> iothread.c | 80 +++
>> qapi/misc.json | 23 +++
>> 6 files changed, 184 insertions(+)
> 
> Looking at just the QMP...
> 

Thanks for your review. I will split this patch to QMP and HMP.

>> +++ b/qapi/misc.json
>> @@ -675,6 +675,29 @@
>> { 'command': 'query-iothreads', 'returns': ['IOThreadInfo'],
>> 'allow-preconfig': true }
>>
>> +##
>> +# @set-iothread-poll-param:
>> +#
>> +# Set poll-* properties for a special iothread.
>> +# The poll-* name can be poll_max_ns/poll_grow/poll_shrink.
> 
> This should be an enum.

I will change the name argument to ENUM, such as,

{ 'enum': 'IothreadPollProperty',
  'data': [ 'max-ns', 'grow', 'shrink' ] }

>> +#
>> +# Notes: can not set the QEMU main loop thread, which is not declared
>> +# using the -object iothread command-line option. The poll_ns property can 
>> not
>> +# be set manually, which is auto-adjust.
> 
> You failed to document the parameters (iothread_id, name, value).
> 

I will add these documents.

>> +#
>> +# Example:
>> +#
>> +# -> { "execute": "set-iothread-poll-param",
>> +# "arguments": { "iothread_id": "1",
>> +# "name": "poll_max_ns",
>> +# "value": 1000 } }
>> +# <- { "return": {} }
>> +#
>> +# Since 3.0
> 
> 4.2 is the earliest this can make it in.
> 

OK, I will change this to 4.2.

>> +##
>> +{ 'command': 'set-iothread-poll-param',
>> + 'data': {'iothread_id': 'str', 'name': 'str', 'value': 'int'} }
> 
> Our naming convention prefers 'iothread-id'.
> 

ok, I will correct it, such as,

{ 'command': 'set-iothread-poll-param',
'data': {'iothread-id': 'str', 'name': 'IothreadPollProperty', 'value': 
'int'} }




[PULL 3/3] iotests: test nbd reconnect

2019-10-22 Thread Eric Blake
From: Vladimir Sementsov-Ogievskiy 

Add test, which starts backup to nbd target and restarts nbd server
during backup.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Message-Id: <20191009084158.15614-4-vsement...@virtuozzo.com>
Reviewed-by: Eric Blake 
Signed-off-by: Eric Blake 
---
 tests/qemu-iotests/264| 95 +++
 tests/qemu-iotests/264.out| 13 +
 tests/qemu-iotests/group  |  1 +
 tests/qemu-iotests/iotests.py | 11 
 4 files changed, 120 insertions(+)
 create mode 100755 tests/qemu-iotests/264
 create mode 100644 tests/qemu-iotests/264.out

diff --git a/tests/qemu-iotests/264 b/tests/qemu-iotests/264
new file mode 100755
index ..c8cd97ae2b74
--- /dev/null
+++ b/tests/qemu-iotests/264
@@ -0,0 +1,95 @@
+#!/usr/bin/env python
+#
+# Test nbd reconnect
+#
+# Copyright (c) 2019 Virtuozzo International GmbH.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+#
+
+import time
+
+import iotests
+from iotests import qemu_img_create, qemu_io_silent_check, file_path, \
+qemu_nbd_popen, log
+
+disk_a, disk_b, nbd_sock = file_path('disk_a', 'disk_b', 'nbd-sock')
+nbd_uri = 'nbd+unix:///?socket=' + nbd_sock
+size = 5 * 1024 * 1024
+wait_limit = 3
+wait_step = 0.2
+
+qemu_img_create('-f', iotests.imgfmt, disk_a, str(size))
+qemu_img_create('-f', iotests.imgfmt, disk_b, str(size))
+srv = qemu_nbd_popen('-k', nbd_sock, '-f', iotests.imgfmt, disk_b)
+
+# Wait for NBD server availability
+t = 0
+ok = False
+while t < wait_limit:
+ok = qemu_io_silent_check('-f', 'raw', '-c', 'read 0 512', nbd_uri)
+if ok:
+break
+time.sleep(wait_step)
+t += wait_step
+
+assert ok
+
+vm = iotests.VM().add_drive(disk_a)
+vm.launch()
+vm.hmp_qemu_io('drive0', 'write 0 {}'.format(size))
+
+vm.qmp_log('blockdev-add', filters=[iotests.filter_qmp_testfiles],
+   **{'node_name': 'backup0',
+  'driver': 'raw',
+  'file': {'driver': 'nbd',
+   'server': {'type': 'unix', 'path': nbd_sock},
+   'reconnect-delay': 10}})
+vm.qmp_log('blockdev-backup', device='drive0', sync='full', target='backup0',
+   speed=(1 * 1024 * 1024))
+
+# Wait for some progress
+t = 0
+while t < wait_limit:
+jobs = vm.qmp('query-block-jobs')['return']
+if jobs and jobs[0]['offset'] > 0:
+break
+time.sleep(wait_step)
+t += wait_step
+
+if jobs and jobs[0]['offset'] > 0:
+log('Backup job is started')
+
+log('Kill NBD server')
+srv.kill()
+srv.wait()
+
+jobs = vm.qmp('query-block-jobs')['return']
+if jobs and jobs[0]['offset'] < jobs[0]['len']:
+log('Backup job is still in progress')
+
+vm.qmp_log('block-job-set-speed', device='drive0', speed=0)
+
+# Emulate server down time for 1 second
+time.sleep(1)
+
+log('Start NBD server')
+srv = qemu_nbd_popen('-k', nbd_sock, '-f', iotests.imgfmt, disk_b)
+
+e = vm.event_wait('BLOCK_JOB_COMPLETED')
+log('Backup completed: {}'.format(e['data']['offset']))
+
+vm.qmp_log('blockdev-del', node_name='backup0')
+srv.kill()
+vm.shutdown()
diff --git a/tests/qemu-iotests/264.out b/tests/qemu-iotests/264.out
new file mode 100644
index ..3000944b099a
--- /dev/null
+++ b/tests/qemu-iotests/264.out
@@ -0,0 +1,13 @@
+{"execute": "blockdev-add", "arguments": {"driver": "raw", "file": {"driver": 
"nbd", "reconnect-delay": 10, "server": {"path": "TEST_DIR/PID-nbd-sock", 
"type": "unix"}}, "node-name": "backup0"}}
+{"return": {}}
+{"execute": "blockdev-backup", "arguments": {"device": "drive0", "speed": 
1048576, "sync": "full", "target": "backup0"}}
+{"return": {}}
+Backup job is started
+Kill NBD server
+Backup job is still in progress
+{"execute": "block-job-set-speed", "arguments": {"device": "drive0", "speed": 
0}}
+{"return": {}}
+Start NBD server
+Backup completed: 5242880
+{"execute": "blockdev-del", "arguments": {"node-name": "backup0"}}
+{"return": {}}
diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index a73df279e5ee..af322af75683 100644
--- a/tests/qemu-iotests/group
+++ b/tests/qemu-iotests/group
@@ -276,6 +276,7 @@
 260 rw quick
 262 rw quick migration
 263 rw quick
+264 rw
 265 rw auto quick
 266 rw quick
 267 rw auto quick snapshot
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index 3a8f378f90d3..693fde155a43 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ 

[PULL 2/3] block/nbd: nbd reconnect

2019-10-22 Thread Eric Blake
From: Vladimir Sementsov-Ogievskiy 

Implement reconnect. To achieve this:

1. add new modes:
   connecting-wait: means, that reconnecting is in progress, and there
 were small number of reconnect attempts, so all requests are
 waiting for the connection.
   connecting-nowait: reconnecting is in progress, there were a lot of
 attempts of reconnect, all requests will return errors.

   two old modes are used too:
   connected: normal state
   quit: exiting after fatal error or on close

Possible transitions are:

   * -> quit
   connecting-* -> connected
   connecting-wait -> connecting-nowait (transition is done after
  reconnect-delay seconds in connecting-wait mode)
   connected -> connecting-wait

2. Implement reconnect in connection_co. So, in connecting-* mode,
connection_co, tries to reconnect unlimited times.

3. Retry nbd queries on channel error, if we are in connecting-wait
state.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Message-Id: <20191009084158.15614-3-vsement...@virtuozzo.com>
Reviewed-by: Eric Blake 
Signed-off-by: Eric Blake 
---
 block/nbd.c | 331 ++--
 1 file changed, 268 insertions(+), 63 deletions(-)

diff --git a/block/nbd.c b/block/nbd.c
index fd78e5f33055..123976171cf4 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -1,6 +1,7 @@
 /*
  * QEMU Block driver for  NBD
  *
+ * Copyright (c) 2019 Virtuozzo International GmbH.
  * Copyright (C) 2016 Red Hat, Inc.
  * Copyright (C) 2008 Bull S.A.S.
  * Author: Laurent Vivier 
@@ -55,6 +56,8 @@ typedef struct {
 } NBDClientRequest;

 typedef enum NBDClientState {
+NBD_CLIENT_CONNECTING_WAIT,
+NBD_CLIENT_CONNECTING_NOWAIT,
 NBD_CLIENT_CONNECTED,
 NBD_CLIENT_QUIT
 } NBDClientState;
@@ -67,8 +70,14 @@ typedef struct BDRVNBDState {
 CoMutex send_mutex;
 CoQueue free_sema;
 Coroutine *connection_co;
+QemuCoSleepState *connection_co_sleep_ns_state;
+bool drained;
+bool wait_drained_end;
 int in_flight;
 NBDClientState state;
+int connect_status;
+Error *connect_err;
+bool wait_in_flight;

 NBDClientRequest requests[MAX_NBD_REQUESTS];
 NBDReply reply;
@@ -83,10 +92,21 @@ typedef struct BDRVNBDState {
 char *x_dirty_bitmap;
 } BDRVNBDState;

-/* @ret will be used for reconnect in future */
+static int nbd_client_connect(BlockDriverState *bs, Error **errp);
+
 static void nbd_channel_error(BDRVNBDState *s, int ret)
 {
-s->state = NBD_CLIENT_QUIT;
+if (ret == -EIO) {
+if (s->state == NBD_CLIENT_CONNECTED) {
+s->state = s->reconnect_delay ? NBD_CLIENT_CONNECTING_WAIT :
+NBD_CLIENT_CONNECTING_NOWAIT;
+}
+} else {
+if (s->state == NBD_CLIENT_CONNECTED) {
+qio_channel_shutdown(s->ioc, QIO_CHANNEL_SHUTDOWN_BOTH, NULL);
+}
+s->state = NBD_CLIENT_QUIT;
+}
 }

 static void nbd_recv_coroutines_wake_all(BDRVNBDState *s)
@@ -129,7 +149,13 @@ static void nbd_client_attach_aio_context(BlockDriverState 
*bs,
 {
 BDRVNBDState *s = (BDRVNBDState *)bs->opaque;

-qio_channel_attach_aio_context(QIO_CHANNEL(s->ioc), new_context);
+/*
+ * s->connection_co is either yielded from nbd_receive_reply or from
+ * nbd_co_reconnect_loop()
+ */
+if (s->state == NBD_CLIENT_CONNECTED) {
+qio_channel_attach_aio_context(QIO_CHANNEL(s->ioc), new_context);
+}

 bdrv_inc_in_flight(bs);

@@ -140,24 +166,150 @@ static void 
nbd_client_attach_aio_context(BlockDriverState *bs,
 aio_wait_bh_oneshot(new_context, nbd_client_attach_aio_context_bh, bs);
 }

+static void coroutine_fn nbd_client_co_drain_begin(BlockDriverState *bs)
+{
+BDRVNBDState *s = (BDRVNBDState *)bs->opaque;
+
+s->drained = true;
+if (s->connection_co_sleep_ns_state) {
+qemu_co_sleep_wake(s->connection_co_sleep_ns_state);
+}
+}
+
+static void coroutine_fn nbd_client_co_drain_end(BlockDriverState *bs)
+{
+BDRVNBDState *s = (BDRVNBDState *)bs->opaque;
+
+s->drained = false;
+if (s->wait_drained_end) {
+s->wait_drained_end = false;
+aio_co_wake(s->connection_co);
+}
+}
+

 static void nbd_teardown_connection(BlockDriverState *bs)
 {
 BDRVNBDState *s = (BDRVNBDState *)bs->opaque;

-assert(s->ioc);
-
-/* finish any pending coroutines */
-qio_channel_shutdown(s->ioc,
- QIO_CHANNEL_SHUTDOWN_BOTH,
- NULL);
+if (s->state == NBD_CLIENT_CONNECTED) {
+/* finish any pending coroutines */
+assert(s->ioc);
+qio_channel_shutdown(s->ioc, QIO_CHANNEL_SHUTDOWN_BOTH, NULL);
+}
+s->state = NBD_CLIENT_QUIT;
+if (s->connection_co) {
+if (s->connection_co_sleep_ns_state) {
+qemu_co_sleep_wake(s->connection_co_sleep_ns_state);
+}
+}
 BDRV_POLL_WHILE(bs, s->connection_co);
+}

-nbd_client_detach_aio_context(bs);
-

[PULL 1/3] qemu-coroutine-sleep: introduce qemu_co_sleep_wake

2019-10-22 Thread Eric Blake
From: Vladimir Sementsov-Ogievskiy 

Introduce a function to gracefully wake a coroutine sleeping in
qemu_co_sleep_ns().

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Kevin Wolf 
Reviewed-by: Eric Blake 
Message-Id: <20191009084158.15614-2-vsement...@virtuozzo.com>
Signed-off-by: Eric Blake 
---
 include/qemu/coroutine.h| 23 +++--
 util/qemu-coroutine-sleep.c | 51 +++--
 2 files changed, 59 insertions(+), 15 deletions(-)

diff --git a/include/qemu/coroutine.h b/include/qemu/coroutine.h
index 9801e7f5a497..8d55663062ad 100644
--- a/include/qemu/coroutine.h
+++ b/include/qemu/coroutine.h
@@ -273,10 +273,29 @@ void qemu_co_rwlock_wrlock(CoRwlock *lock);
  */
 void qemu_co_rwlock_unlock(CoRwlock *lock);

+typedef struct QemuCoSleepState QemuCoSleepState;
+
 /**
- * Yield the coroutine for a given duration
+ * Yield the coroutine for a given duration. During this yield, @sleep_state
+ * (if not NULL) is set to an opaque pointer, which may be used for
+ * qemu_co_sleep_wake(). Be careful, the pointer is set back to zero when the
+ * timer fires. Don't save the obtained value to other variables and don't call
+ * qemu_co_sleep_wake from another aio context.
  */
-void coroutine_fn qemu_co_sleep_ns(QEMUClockType type, int64_t ns);
+void coroutine_fn qemu_co_sleep_ns_wakeable(QEMUClockType type, int64_t ns,
+QemuCoSleepState **sleep_state);
+static inline void coroutine_fn qemu_co_sleep_ns(QEMUClockType type, int64_t 
ns)
+{
+qemu_co_sleep_ns_wakeable(type, ns, NULL);
+}
+
+/**
+ * Wake a coroutine if it is sleeping in qemu_co_sleep_ns. The timer will be
+ * deleted. @sleep_state must be the variable whose address was given to
+ * qemu_co_sleep_ns() and should be checked to be non-NULL before calling
+ * qemu_co_sleep_wake().
+ */
+void qemu_co_sleep_wake(QemuCoSleepState *sleep_state);

 /**
  * Yield until a file descriptor becomes readable
diff --git a/util/qemu-coroutine-sleep.c b/util/qemu-coroutine-sleep.c
index 4bfdd30cbf13..ae91b92b6e78 100644
--- a/util/qemu-coroutine-sleep.c
+++ b/util/qemu-coroutine-sleep.c
@@ -17,31 +17,56 @@
 #include "qemu/timer.h"
 #include "block/aio.h"

-static void co_sleep_cb(void *opaque)
+static const char *qemu_co_sleep_ns__scheduled = "qemu_co_sleep_ns";
+
+struct QemuCoSleepState {
+Coroutine *co;
+QEMUTimer *ts;
+QemuCoSleepState **user_state_pointer;
+};
+
+void qemu_co_sleep_wake(QemuCoSleepState *sleep_state)
 {
-Coroutine *co = opaque;
-
 /* Write of schedule protected by barrier write in aio_co_schedule */
-atomic_set(>scheduled, NULL);
-aio_co_wake(co);
+const char *scheduled = atomic_cmpxchg(_state->co->scheduled,
+   qemu_co_sleep_ns__scheduled, NULL);
+
+assert(scheduled == qemu_co_sleep_ns__scheduled);
+if (sleep_state->user_state_pointer) {
+*sleep_state->user_state_pointer = NULL;
+}
+timer_del(sleep_state->ts);
+aio_co_wake(sleep_state->co);
+}
+
+static void co_sleep_cb(void *opaque)
+{
+qemu_co_sleep_wake(opaque);
 }

-void coroutine_fn qemu_co_sleep_ns(QEMUClockType type, int64_t ns)
+void coroutine_fn qemu_co_sleep_ns_wakeable(QEMUClockType type, int64_t ns,
+QemuCoSleepState **sleep_state)
 {
 AioContext *ctx = qemu_get_current_aio_context();
-QEMUTimer *ts;
-Coroutine *co = qemu_coroutine_self();
+QemuCoSleepState state = {
+.co = qemu_coroutine_self(),
+.ts = aio_timer_new(ctx, type, SCALE_NS, co_sleep_cb, ),
+.user_state_pointer = sleep_state,
+};

-const char *scheduled = atomic_cmpxchg(>scheduled, NULL, __func__);
+const char *scheduled = atomic_cmpxchg(>scheduled, NULL,
+   qemu_co_sleep_ns__scheduled);
 if (scheduled) {
 fprintf(stderr,
 "%s: Co-routine was already scheduled in '%s'\n",
 __func__, scheduled);
 abort();
 }
-ts = aio_timer_new(ctx, type, SCALE_NS, co_sleep_cb, co);
-timer_mod(ts, qemu_clock_get_ns(type) + ns);
+
+if (sleep_state) {
+*sleep_state = 
+}
+timer_mod(state.ts, qemu_clock_get_ns(type) + ns);
 qemu_coroutine_yield();
-timer_del(ts);
-timer_free(ts);
+timer_free(state.ts);
 }
-- 
2.21.0




[PULL 0/3] NBD patches for 2019-10-22

2019-10-22 Thread Eric Blake
The following changes since commit f9bec781379dd7ccf9d01b4b6a79a9ec82c192e5:

  Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20191022' into 
staging (2019-10-22 13:45:09 +0100)

are available in the Git repository at:

  https://repo.or.cz/qemu/ericb.git tags/pull-nbd-2019-10-22

for you to fetch changes up to 23ee0ec2360b51619cae452c4faa8590dea74a6e:

  iotests: test nbd reconnect (2019-10-22 20:51:31 -0500)

Several other NBD patches have appeared on list, but need respins based
on review comments, and may still be okay after soft freeze. But this one
is a feature addition, so I'm sending the PR now, rather than waiting to
bundle in a few more.


nbd patches for 2019-10-22

- add ability for NBD client reconnect


Vladimir Sementsov-Ogievskiy (3):
  qemu-coroutine-sleep: introduce qemu_co_sleep_wake
  block/nbd: nbd reconnect
  iotests: test nbd reconnect

 include/qemu/coroutine.h  |  23 ++-
 block/nbd.c   | 331 ++
 util/qemu-coroutine-sleep.c   |  51 +--
 tests/qemu-iotests/264|  95 
 tests/qemu-iotests/264.out|  13 ++
 tests/qemu-iotests/group  |   1 +
 tests/qemu-iotests/iotests.py |  11 ++
 7 files changed, 447 insertions(+), 78 deletions(-)
 create mode 100755 tests/qemu-iotests/264
 create mode 100644 tests/qemu-iotests/264.out

Vladimir Sementsov-Ogievskiy (3):
  qemu-coroutine-sleep: introduce qemu_co_sleep_wake
  block/nbd: nbd reconnect
  iotests: test nbd reconnect

 include/qemu/coroutine.h  |  23 ++-
 block/nbd.c   | 331 +++---
 util/qemu-coroutine-sleep.c   |  51 --
 tests/qemu-iotests/264|  95 ++
 tests/qemu-iotests/264.out|  13 ++
 tests/qemu-iotests/group  |   1 +
 tests/qemu-iotests/iotests.py |  11 ++
 7 files changed, 447 insertions(+), 78 deletions(-)
 create mode 100755 tests/qemu-iotests/264
 create mode 100644 tests/qemu-iotests/264.out

-- 
2.21.0




Re: [PATCH v13 01/12] util/cutils: Add qemu_strtotime_ps()

2019-10-22 Thread Tao Xu

On 10/23/2019 9:13 AM, Eric Blake wrote:

On 10/20/19 6:11 AM, Tao Xu wrote:

To convert strings with time suffixes to numbers, support time unit are
"ps" for picosecond, "ns" for nanosecond, "us" for microsecond, "ms"
for millisecond or "s" for second.


I haven't yet reviewed the patch itself, but my off-hand observation:

picosecond is probably too narrow to ever be useful.  POSIX interfaces
only go down to nanoseconds, and when you start adding in vmexit delay
times and such, we're lucky when we get anything better than microsecond
accuracies.  Supporting just three sub-second suffixes instead of four
would slightly simplify the code, and not cost you any real precision.


Thank you for your suggestion.



Re: [PATCH v13 00/12] Build ACPI Heterogeneous Memory Attribute Table (HMAT)

2019-10-22 Thread Tao Xu

On 10/22/2019 7:22 PM, Markus Armbruster wrote:

I just stumbled over this series.  It touches the QAPI visitors and even
the generator, without cc'ing its maintainers.  Such changes require
review.  There's precious little time until the soft freeze now.  I'll
try, but no promises.

Please cc me and Michael Roth  on future
revisions.

In general, peruse output of scripts/get_maintainer.pl to find relevant
maintainers.


[...]

v10:
 - Add qemu_strtotime_ps() to convert strings with time suffixes
 to numbers, and add some tests for it.
 - Add qapi buildin type time, and add some tests for it.
 - Add machine oprion properties "-machine hmat=on|off" for
  enabling or disabling HMAT in QEMU.


I guess this is where you started messing with QAPI.  Seven weeks ago.
The time crunch is of your own making, I'm afraid.



I am sorry. I will cc all related maintainers next time.



Re: [PATCH v10 3/3] iotests: test nbd reconnect

2019-10-22 Thread Eric Blake

On 10/9/19 3:41 AM, Vladimir Sementsov-Ogievskiy wrote:

Add test, which starts backup to nbd target and restarts nbd server
during backup.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
  tests/qemu-iotests/264| 95 +++
  tests/qemu-iotests/264.out| 13 +
  tests/qemu-iotests/group  |  1 +
  tests/qemu-iotests/iotests.py | 11 
  4 files changed, 120 insertions(+)
  create mode 100755 tests/qemu-iotests/264
  create mode 100644 tests/qemu-iotests/264.out

diff --git a/tests/qemu-iotests/264 b/tests/qemu-iotests/264
new file mode 100755
index 00..c8cd97ae2b
--- /dev/null
+++ b/tests/qemu-iotests/264



+import iotests
+from iotests import qemu_img_create, qemu_io_silent_check, file_path, \
+qemu_nbd_popen, log
+
+disk_a, disk_b, nbd_sock = file_path('disk_a', 'disk_b', 'nbd-sock')
+nbd_uri = 'nbd+unix:///?socket=' + nbd_sock


Needs rebasing on top of Max's patches to stick sockets in SOCK_DIR:

https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg04201.html

[or, if my pull request lands first, Max needs to add this one to the 
list of affected tests...]




+vm.qmp_log('blockdev-add', filters=[iotests.filter_qmp_testfiles],
+   **{'node_name': 'backup0',
+  'driver': 'raw',
+  'file': {'driver': 'nbd',
+   'server': {'type': 'unix', 'path': nbd_sock},
+   'reconnect-delay': 10}})
+vm.qmp_log('blockdev-backup', device='drive0', sync='full', target='backup0',
+   speed=(1 * 1024 * 1024))


This starts the job throttled, to give us time...


+
+# Wait for some progress
+t = 0
+while t < wait_limit:
+jobs = vm.qmp('query-block-jobs')['return']
+if jobs and jobs[0]['offset'] > 0:
+break
+time.sleep(wait_step)
+t += wait_step
+
+if jobs and jobs[0]['offset'] > 0:
+log('Backup job is started')
+
+log('Kill NBD server')
+srv.kill()
+srv.wait()
+
+jobs = vm.qmp('query-block-jobs')['return']
+if jobs and jobs[0]['offset'] < jobs[0]['len']:
+log('Backup job is still in progress')
+
+vm.qmp_log('block-job-set-speed', device='drive0', speed=0)
+
+# Emulate server down time for 1 second
+time.sleep(1)


...but once we restart,...


+
+log('Start NBD server')
+srv = qemu_nbd_popen('-k', nbd_sock, '-f', iotests.imgfmt, disk_b)
+
+e = vm.event_wait('BLOCK_JOB_COMPLETED')


...should we unthrottle the job to allow the test to complete slightly 
faster after the reconnect?  But that can be done as an improvement on 
top, if it helps.




+++ b/tests/qemu-iotests/iotests.py
@@ -165,6 +165,13 @@ def qemu_io_silent(*args):
   (-exitcode, ' '.join(args)))
  return exitcode
  
+def qemu_io_silent_check(*args):

+'''Run qemu-io and return the true if subprocess returned 0'''
+args = qemu_io_args + list(args)
+exitcode = subprocess.call(args, stdout=open('/dev/null', 'w'),
+   stderr=subprocess.STDOUT)


This discards the stdout data, even on failure. Is there a smarter way 
to grab the output into a variable, but only dump it to the log on 
failure, rather than outright discarding it?


But for the sake of getting this test in before freeze, that can be a 
followup, if at all.


Reviewed-by: Eric Blake 

I'll send a pull request soon.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org




Re: [PATCH v13 01/12] util/cutils: Add qemu_strtotime_ps()

2019-10-22 Thread Eric Blake

On 10/20/19 6:11 AM, Tao Xu wrote:

To convert strings with time suffixes to numbers, support time unit are
"ps" for picosecond, "ns" for nanosecond, "us" for microsecond, "ms"
for millisecond or "s" for second.


I haven't yet reviewed the patch itself, but my off-hand observation:

picosecond is probably too narrow to ever be useful.  POSIX interfaces 
only go down to nanoseconds, and when you start adding in vmexit delay 
times and such, we're lucky when we get anything better than microsecond 
accuracies.  Supporting just three sub-second suffixes instead of four 
would slightly simplify the code, and not cost you any real precision.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org




Re: [PATCH v13 01/12] util/cutils: Add qemu_strtotime_ps()

2019-10-22 Thread Eduardo Habkost
Hi,

First of all, sorry for not reviewing this earlier.  I thought
other people were already looking at the first 4 patches.

On Sun, Oct 20, 2019 at 07:11:14PM +0800, Tao Xu wrote:
> To convert strings with time suffixes to numbers, support time unit are
> "ps" for picosecond, "ns" for nanosecond, "us" for microsecond, "ms"
> for millisecond or "s" for second.
> 
> Signed-off-by: Tao Xu 
> ---
> 
> No changes in v13.
> ---
>  include/qemu/cutils.h |  1 +
>  util/cutils.c | 82 +++
>  2 files changed, 83 insertions(+)
> 
> diff --git a/include/qemu/cutils.h b/include/qemu/cutils.h
> index b54c847e0f..7b6d106bdd 100644
> --- a/include/qemu/cutils.h
> +++ b/include/qemu/cutils.h
> @@ -182,5 +182,6 @@ int uleb128_decode_small(const uint8_t *in, uint32_t *n);
>   * *str1 is <, == or > than *str2.
>   */
>  int qemu_pstrcmp0(const char **str1, const char **str2);
> +int qemu_strtotime_ps(const char *nptr, const char **end, uint64_t *result);
>  
>  #endif
> diff --git a/util/cutils.c b/util/cutils.c
> index fd591cadf0..a50c15f46a 100644
> --- a/util/cutils.c
> +++ b/util/cutils.c
> @@ -847,3 +847,85 @@ int qemu_pstrcmp0(const char **str1, const char **str2)
>  {
>  return g_strcmp0(*str1, *str2);
>  }
> +
> +static int64_t timeunit_mul(const char *unitstr)
> +{
> +if (g_strcmp0(unitstr, "ps") == 0) {
> +return 1;

This makes do_strtotime("123ps,...", , ...) fail because of
trailing data.

> +} else if (g_strcmp0(unitstr, "ns") == 0) {
> +return 1000;
> +} else if (g_strcmp0(unitstr, "us") == 0) {
> +return 100;
> +} else if (g_strcmp0(unitstr, "ms") == 0) {
> +return 10LL;
> +} else if (g_strcmp0(unitstr, "s") == 0) {
> +return 1LL;

Same as above, for the other suffixes.

> +} else {
> +return -1;

But this makes do_strtotime("123,...", , ...) work as
expected.

This is inconsistent.  I see that you are not testing non-NULL
`end` argument at test_qemu_strtotime_ps_trailing(), so that's
probably why this issue wasn't detected.

> +}
> +}
> +
> +
> +/*
> + * Convert string to time, support time unit are ps for picosecond,
> + * ns for nanosecond, us for microsecond, ms for millisecond or s for second.
> + * End pointer will be returned in *end, if not NULL. Return -ERANGE on
> + * overflow, and -EINVAL on other error.
> + */
> +static int do_strtotime(const char *nptr, const char **end,
> +  const char *default_unit, uint64_t *result)
> +{
> +int retval;
> +const char *endptr;
> +int mul_required = 0;
> +int64_t mul;
> +double val, integral, fraction;
> +
> +retval = qemu_strtod_finite(nptr, , );
> +if (retval) {
> +goto out;
> +}
> +fraction = modf(val, );
> +if (fraction != 0) {
> +mul_required = 1;
> +}
> +
> +mul = timeunit_mul(endptr);
> +
> +if (mul == 1LL) {
> +endptr++;
> +} else if (mul != -1) {
> +endptr += 2;

This is fragile.  It can break very easily if additional
one-letter suffixes are added to timeunit_mul() in the future.

One option to make this safer is to make timeunit_mul() get a
pointer to endptr.


> +} else {
> +mul = timeunit_mul(default_unit);
> +assert(mul >= 0);
> +}
> +if (mul == 1 && mul_required) {
> +retval = -EINVAL;
> +goto out;
> +}
> +/*
> + * Values >= 0xfc00 overflow uint64_t after their trip
> + * through double (53 bits of precision).
> + */
> +if ((val * (double)mul >= 0xfc00) || val < 0) {
> +retval = -ERANGE;
> +goto out;
> +}
> +*result = val * (double)mul;
> +retval = 0;
> +
> +out:
> +if (end) {
> +*end = endptr;

This indicates that having trailing data after the string is OK
if `end` is not NULL, but timeunit_mul() doesn't take that into
account.

Considering that this function is just a copy of do_strtosz(), I
suggest making do_strtosz() and suffix_mul() get a
suffix/multiplier table as input, instead of duplicating the
code.


> +} else if (*endptr) {
> +retval = -EINVAL;
> +}
> +
> +return retval;
> +}
> +
> +int qemu_strtotime_ps(const char *nptr, const char **end, uint64_t *result)
> +{
> +return do_strtotime(nptr, end, "ps", result);
> +}
> -- 
> 2.20.1
> 

-- 
Eduardo




Re: [GIT PULL for qemu-pseries] pseries: Update SLOF firmware image

2019-10-22 Thread Eric Blake

On 10/22/19 7:04 PM, Alexey Kardashevskiy wrote:


Looking at commit 8e59d05f71ae which update the SLOF submodule,
in your future updates can you include the git shortlog in the
commit description?



I guess I can do that.

Is there an easy way to combine

git -C roms/SLOF shortlog qemu-slof-20190911..qemu-slof-20191022
git commit
?



git -C roms/SLOF shortlog qemu-slof-20190911..qemu-slof-20191022 \
  | git commit -F -


You can get something similar with less typing as:

git sumodule summary | git commit -F -



After
export MYDIFF=$(git -C roms/SLOF shortlog 
qemu-slof-20190911..qemu-slof-20191022)
$MYDIFF looses formatting (drops \r) so it is no good for a commit log.


Potentially insufficient quoting there.

POSIX says that:

export foo=$(printf 'a  b')

can result in either of the following scenarios:

both 'foo' and 'b' are exported, foo with the value 'a', b with its 
existing value (if any, otherwise empty); bash uses this behavior [in 
POSIX terms, bash treats arguments after 'export' in an assignment context]


just 'foo' is exported, with value 'a  b'; dash uses this behavior

If you want to guarantee the latter (that is, that the shell does not 
split on whitespace or perform globbing), you have to either split it 
into two commands (so that your unquoted use of $() is guaranteed to 
occur in assignment context, without worrying whether 'export' 
introduces those contexts):


export foo
foo=$(...)

or use quoting:

export foo="$(...)"

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org




Re: [PATCH] enable translating statx syscalls on more arches

2019-10-22 Thread Andrew Kelley
bump

On 10/16/19 5:01 PM, Andrew Kelley wrote:
> Signed-off-by: Andrew Kelley 
> ---
>  linux-user/aarch64/syscall_nr.h | 13 ++
>  linux-user/arm/syscall_nr.h | 38 
>  linux-user/i386/syscall_nr.h| 43 
>  linux-user/mips/cpu_loop.c  |  6 +
>  linux-user/ppc/syscall_nr.h | 44 +
>  5 files changed, 144 insertions(+)
> 
> diff --git a/linux-user/aarch64/syscall_nr.h
> b/linux-user/aarch64/syscall_nr.h
> index f00ffd7fb8..4e8d0bbb15 100644
> --- a/linux-user/aarch64/syscall_nr.h
> +++ b/linux-user/aarch64/syscall_nr.h
> @@ -276,5 +276,18 @@
>  #define TARGET_NR_membarrier 283
>  #define TARGET_NR_mlock2 284
>  #define TARGET_NR_copy_file_range 285
> +#define TARGET_NR_preadv2 286
> +#define TARGET_NR_pwritev2 287
> +#define TARGET_NR_pkey_mprotect 288
> +#define TARGET_NR_pkey_alloc 289
> +#define TARGET_NR_pkey_free 290
> +#define TARGET_NR_statx 291
> +#define TARGET_NR_io_pgetevents 292
> +#define TARGET_NR_rseq 293
> +#define TARGET_NR_kexec_file_load 294
> +#define TARGET_NR_pidfd_send_signal 424
> +#define TARGET_NR_io_uring_setup 425
> +#define TARGET_NR_io_uring_enter 426
> +#define TARGET_NR_io_uring_register 427
> 
>  #endif
> diff --git a/linux-user/arm/syscall_nr.h b/linux-user/arm/syscall_nr.h
> index e7eda0d766..20afa3992a 100644
> --- a/linux-user/arm/syscall_nr.h
> +++ b/linux-user/arm/syscall_nr.h
> @@ -400,4 +400,42 @@
>  #define TARGET_NR_membarrier   (389)
>  #define TARGET_NR_mlock2   (390)
> 
> +#define TARGET_NR_copy_file_range  (391)
> +#define TARGET_NR_preadv2  (392)
> +#define TARGET_NR_pwritev2 (393)
> +#define TARGET_NR_pkey_mprotect(394)
> +#define TARGET_NR_pkey_alloc   (395)
> +#define TARGET_NR_pkey_free(396)
> +#define TARGET_NR_statx(397)
> +#define TARGET_NR_rseq (398)
> +#define TARGET_NR_io_pgetevents(399)
> +#define TARGET_NR_migrate_pages(400)
> +
> +#define TARGET_NR_kexec_file_load  (401)
> +#define TARGET_NR_clock_gettime64  (403)
> +#define TARGET_NR_clock_settime64  (404)
> +#define TARGET_NR_clock_adjtime64  (405)
> +#define TARGET_NR_clock_getres_time64  (406)
> +#define TARGET_NR_clock_nanosleep_time64   (407)
> +#define TARGET_NR_timer_gettime64  (408)
> +#define TARGET_NR_timer_settime64  (409)
> +#define TARGET_NR_timerfd_gettime64(410)
> +
> +#define TARGET_NR_timerfd_settime64(411)
> +#define TARGET_NR_utimensat_time64 (412)
> +#define TARGET_NR_pselect6_time64  (413)
> +#define TARGET_NR_ppoll_time64 (414)
> +#define TARGET_NR_io_pgetevents_time64 (416)
> +#define TARGET_NR_recvmmsg_time64  (417)
> +#define TARGET_NR_mq_timedsend_time64  (418)
> +#define TARGET_NR_mq_timedreceive_time64   (419)
> +#define TARGET_NR_semtimedop_time64(420)
> +
> +#define TARGET_NR_rt_sigtimedwait_time64   (421)
> +#define TARGET_NR_futex_time64 (422)
> +#define TARGET_NR_sched_rr_get_interval_time64 (423)
> +#define TARGET_NR_pidfd_send_signal(424)
> +#define TARGET_NR_io_uring_setup   (425)
> +#define TARGET_NR_io_uring_enter   (426)
> +#define TARGET_NR_io_uring_register(427)
>  #endif
> diff --git a/linux-user/i386/syscall_nr.h b/linux-user/i386/syscall_nr.h
> index 3234ec21c6..e641674daf 100644
> --- a/linux-user/i386/syscall_nr.h
> +++ b/linux-user/i386/syscall_nr.h
> @@ -383,5 +383,48 @@
>  #define TARGET_NR_membarrier375
>  #define TARGET_NR_mlock2376
>  #define TARGET_NR_copy_file_range   377
> +#define TARGET_NR_preadv2 378
> +#define TARGET_NR_pwritev2 379
> +#define TARGET_NR_pkey_mprotect 380
> +#define TARGET_NR_pkey_alloc 381
> +#define TARGET_NR_pkey_free 382
> +#define TARGET_NR_statx 383
> +#define TARGET_NR_arch_prctl 384
> +#define TARGET_NR_io_pgetevents 385
> +#define TARGET_NR_rseq 386
> +#define TARGET_NR_semget 393
> +#define TARGET_NR_semctl 394
> +#define TARGET_NR_shmget 395
> +#define TARGET_NR_shmctl 396
> +#define TARGET_NR_shmat 397
> +#define TARGET_NR_shmdt 398
> +#define TARGET_NR_msgget 399
> +#define TARGET_NR_msgsnd 400
> +#define TARGET_NR_msgrcv 401
> +#define TARGET_NR_msgctl 402
> +#define TARGET_NR_clock_gettime64 403
> +#define TARGET_NR_clock_settime64 404
> +#define TARGET_NR_clock_adjtime64 405
> +#define TARGET_NR_clock_getres_time64 406
> +#define TARGET_NR_clock_nanosleep_time64 407
> +#define TARGET_NR_timer_gettime64 408
> +#define TARGET_NR_timer_settime64 409
> +#define TARGET_NR_timerfd_gettime64 410
> +#define TARGET_NR_timerfd_settime64 411
> +#define TARGET_NR_utimensat_time64 412
> +#define 

Re: [GIT PULL for qemu-pseries] pseries: Update SLOF firmware image

2019-10-22 Thread Alexey Kardashevskiy



On 22/10/2019 19:49, Philippe Mathieu-Daudé wrote:
> Hi Alekey,
> 
> On 10/22/19 6:09 AM, Alexey Kardashevskiy wrote:
>> The following changes since commit 7cff77c24d8f5e558cef3538a44044d66aa225a5:
>>
>>    spapr: Move SpaprIrq::nr_xirqs to SpaprMachineClass (2019-10-16 12:01:41 
>> +1100)
>>
>> are available in the Git repository at:
>>
>>    g...@github.com:aik/qemu.git tags/qemu-slof-20191022
>>
>> for you to fetch changes up to 8e59d05f71ae783e12a8eb7eb582e0a86ba3d6dc:
>>
>>    pseries: Update SLOF firmware image (2019-10-22 15:05:36 +1100)
>>
>> 
>> Alexey Kardashevskiy (1):
>>    pseries: Update SLOF firmware image
>>
>>   pc-bios/README   |   2 +-
>>   pc-bios/slof.bin | Bin 930640 -> 928552 bytes
>>   roms/SLOF    |   2 +-
>>   3 files changed, 2 insertions(+), 2 deletions(-)
> 
> Looking at commit 8e59d05f71ae which update the SLOF submodule,
> in your future updates can you include the git shortlog in the
> commit description?


I guess I can do that.

Is there an easy way to combine

git -C roms/SLOF shortlog qemu-slof-20190911..qemu-slof-20191022
git commit
?

After
export MYDIFF=$(git -C roms/SLOF shortlog 
qemu-slof-20190911..qemu-slof-20191022)
$MYDIFF looses formatting (drops \r) so it is no good for a commit log.


> 
> Simply:
> 
>   $ git shortlog qemu-slof-20190911..qemu-slof-20191022
>   Alexey Kardashevskiy (3):
>     pci: Align PCI node names with QEMU
>     libusb: Fix compiler warnings with gcc9
>     version: update to 20191022
> 
>   Thomas Huth (1):
>     ipv6: Fix gcc9 warnings
> 
> Thanks,
> 
> Phil.
> 

-- 
Alexey



[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

2019-10-22 Thread Laszlo Ersek (Red Hat)
In reply to :

> Is it possible that we're talking about some kind of miscompilation
> here, maybe because gcc-9.2.0 is just that tiny bit too spanking
> current?

I'm riding the trailing edge here (gcc-4.8 in RHEL7) :)

[...]

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1846427

Title:
  4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

Status in QEMU:
  New

Bug description:
  I'm seeing massive corruption of qcow2 images with qemu 4.1.0 and git
  master as of 7f21573c822805a8e6be379d9bcf3ad9effef3dc after a few
  savevm/quit/loadvm cycles. I've narrowed it down to the following
  reproducer (further notes below):

  # qemu-img check debian.qcow2
  No errors were found on the image.
  251601/327680 = 76.78% allocated, 1.63% fragmented, 0.00% compressed clusters
  Image end offset: 18340446208
  # bin/qemu/bin/qemu-system-x86_64 -machine pc-q35-4.0.1,accel=kvm -m 4096 
-chardev stdio,id=charmonitor -mon chardev=charmonitor -drive 
file=debian.qcow2,id=d -S
  qemu-system-x86_64: warning: dbind: Couldn't register with accessibility bus: 
Did not receive a reply. Possible causes include: the remote application did 
not send a reply, the message bus security policy blocked the reply, the reply 
timeout expired, or the network connection was broken.
  QEMU 4.1.50 monitor - type 'help' for more information
  (qemu) loadvm foo
  (qemu) c
  (qemu) qcow2_free_clusters failed: Invalid argument
  qcow2_free_clusters failed: Invalid argument
  qcow2_free_clusters failed: Invalid argument
  qcow2_free_clusters failed: Invalid argument
  quit
  [m@nargothrond:~] qemu-img check debian.qcow2
  Leaked cluster 85179 refcount=2 reference=1
  Leaked cluster 85180 refcount=2 reference=1
  ERROR cluster 266150 refcount=0 reference=2
  [...]
  ERROR OFLAG_COPIED data cluster: l2_entry=42284 refcount=1

  9493 errors were found on the image.
  Data may be corrupted, or further writes to the image may corrupt it.

  2 leaked clusters were found on the image.
  This means waste of disk space, but no harm to data.
  259266/327680 = 79.12% allocated, 1.67% fragmented, 0.00% compressed clusters
  Image end offset: 18340446208

  This is on a x86_64 Linux 5.3.1 Gentoo host with qemu-system-x86_64
  and accel=kvm. The compiler is gcc-9.2.0 with the rest of the system
  similarly current.

  Reproduced with qemu-4.1.0 from distribution package as well as
  vanilla git checkout of tag v4.1.0 and commit
  7f21573c822805a8e6be379d9bcf3ad9effef3dc (today's master). Does not
  happen with qemu compiled from vanilla checkout of tag v4.0.0. Build
  sequence:

  ./configure --prefix=$HOME/bin/qemu-bisect --target-list=x86_64-softmmu 
--disable-werror --disable-docs
  [...]
  CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g
  [...] (can provide full configure output if helpful)
  make -j8 install

  The kind of guest OS does not matter: seen with Debian testing 64bit,
  Windows 7 x86/x64 BIOS and Windows 7 x64 EFI.

  The virtual storage controller does not seem to matter: seen with
  VirtIO SCSI, emulated SCSI and emulated SATA AHCI.

  Caching modes (none, directsync, writeback), aio mode (threads,
  native) or discard (ignore, unmap) or detect-zeroes (off, unmap) does
  not influence occurence either.

  Having more RAM in the guest seems to increase odds of corruption:
  With 512MB to the Debian guest problem hardly occurs at all, with 4GB
  RAM it happens almost instantly.

  An automated reproducer works as follows:

  - the guest *does* mount its root fs and swap with option discard and
  my testing leaves me with the impression that file deletion rather
  than reading is causing the issue

  - foo is a snapshot of the running Debian VM which is already running
  command

  # while true ; do dd if=/dev/zero of=foo bs=10240k count=400 ; done

  to produce some I/O to the disk (4GB file with 4GB of RAM).

  - on the host a loop continuously resumes and saves the guest state
  and quits qemu inbetween:

  # while true ; do (echo loadvm foo ; echo c ; sleep 10 ; echo stop ;
  echo savevm foo ; echo quit ) | bin/qemu-bisect/bin/qemu-system-x86_64
  -machine pc-q35-3.1,accel=kvm -m 4096 -chardev stdio,id=charmonitor
  -mon chardev=charmonitor -drive file=debian.qcow2,id=d -S -display
  none ; done

  - quitting qemu inbetween saves and loads seems to be necessary for
  the problem to occur. Just continusouly in one session saving and
  loading guest state does not trigger it.

  - For me, after about 2 to 6 iterations of above loop the image is
  corrupted.

  - corruption manifests with other messages from qemu as well, e.g.:

  (qemu) loadvm foo
  Error: Device 'd' does not have the requested snapshot 'foo'

  Using above reproducer I have to the be best of my ability bisected
  the introduction of the problem to commit
  69f47505ee66afaa513305de0c1895a224e52c45 

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

2019-10-22 Thread Michael Weiser
Please ignore the stuff about (!is_zero_cow(bs, m) || true) being
optimized out. Of course it isn't. And corruption still occurs with that
way of calling only is_zero_cow(). Dunno what I did there. It seems to
be even later than I thought. The rest of my testing holds true though.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1846427

Title:
  4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

Status in QEMU:
  New

Bug description:
  I'm seeing massive corruption of qcow2 images with qemu 4.1.0 and git
  master as of 7f21573c822805a8e6be379d9bcf3ad9effef3dc after a few
  savevm/quit/loadvm cycles. I've narrowed it down to the following
  reproducer (further notes below):

  # qemu-img check debian.qcow2
  No errors were found on the image.
  251601/327680 = 76.78% allocated, 1.63% fragmented, 0.00% compressed clusters
  Image end offset: 18340446208
  # bin/qemu/bin/qemu-system-x86_64 -machine pc-q35-4.0.1,accel=kvm -m 4096 
-chardev stdio,id=charmonitor -mon chardev=charmonitor -drive 
file=debian.qcow2,id=d -S
  qemu-system-x86_64: warning: dbind: Couldn't register with accessibility bus: 
Did not receive a reply. Possible causes include: the remote application did 
not send a reply, the message bus security policy blocked the reply, the reply 
timeout expired, or the network connection was broken.
  QEMU 4.1.50 monitor - type 'help' for more information
  (qemu) loadvm foo
  (qemu) c
  (qemu) qcow2_free_clusters failed: Invalid argument
  qcow2_free_clusters failed: Invalid argument
  qcow2_free_clusters failed: Invalid argument
  qcow2_free_clusters failed: Invalid argument
  quit
  [m@nargothrond:~] qemu-img check debian.qcow2
  Leaked cluster 85179 refcount=2 reference=1
  Leaked cluster 85180 refcount=2 reference=1
  ERROR cluster 266150 refcount=0 reference=2
  [...]
  ERROR OFLAG_COPIED data cluster: l2_entry=42284 refcount=1

  9493 errors were found on the image.
  Data may be corrupted, or further writes to the image may corrupt it.

  2 leaked clusters were found on the image.
  This means waste of disk space, but no harm to data.
  259266/327680 = 79.12% allocated, 1.67% fragmented, 0.00% compressed clusters
  Image end offset: 18340446208

  This is on a x86_64 Linux 5.3.1 Gentoo host with qemu-system-x86_64
  and accel=kvm. The compiler is gcc-9.2.0 with the rest of the system
  similarly current.

  Reproduced with qemu-4.1.0 from distribution package as well as
  vanilla git checkout of tag v4.1.0 and commit
  7f21573c822805a8e6be379d9bcf3ad9effef3dc (today's master). Does not
  happen with qemu compiled from vanilla checkout of tag v4.0.0. Build
  sequence:

  ./configure --prefix=$HOME/bin/qemu-bisect --target-list=x86_64-softmmu 
--disable-werror --disable-docs
  [...]
  CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g
  [...] (can provide full configure output if helpful)
  make -j8 install

  The kind of guest OS does not matter: seen with Debian testing 64bit,
  Windows 7 x86/x64 BIOS and Windows 7 x64 EFI.

  The virtual storage controller does not seem to matter: seen with
  VirtIO SCSI, emulated SCSI and emulated SATA AHCI.

  Caching modes (none, directsync, writeback), aio mode (threads,
  native) or discard (ignore, unmap) or detect-zeroes (off, unmap) does
  not influence occurence either.

  Having more RAM in the guest seems to increase odds of corruption:
  With 512MB to the Debian guest problem hardly occurs at all, with 4GB
  RAM it happens almost instantly.

  An automated reproducer works as follows:

  - the guest *does* mount its root fs and swap with option discard and
  my testing leaves me with the impression that file deletion rather
  than reading is causing the issue

  - foo is a snapshot of the running Debian VM which is already running
  command

  # while true ; do dd if=/dev/zero of=foo bs=10240k count=400 ; done

  to produce some I/O to the disk (4GB file with 4GB of RAM).

  - on the host a loop continuously resumes and saves the guest state
  and quits qemu inbetween:

  # while true ; do (echo loadvm foo ; echo c ; sleep 10 ; echo stop ;
  echo savevm foo ; echo quit ) | bin/qemu-bisect/bin/qemu-system-x86_64
  -machine pc-q35-3.1,accel=kvm -m 4096 -chardev stdio,id=charmonitor
  -mon chardev=charmonitor -drive file=debian.qcow2,id=d -S -display
  none ; done

  - quitting qemu inbetween saves and loads seems to be necessary for
  the problem to occur. Just continusouly in one session saving and
  loading guest state does not trigger it.

  - For me, after about 2 to 6 iterations of above loop the image is
  corrupted.

  - corruption manifests with other messages from qemu as well, e.g.:

  (qemu) loadvm foo
  Error: Device 'd' does not have the requested snapshot 'foo'

  Using above reproducer I have to the be best of my ability bisected
  the introduction of the problem to commit
  69f47505ee66afaa513305de0c1895a224e52c45 

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

2019-10-22 Thread Michael Weiser
> I tried to reproduce the problem locally, on the same commit, with the
> steps you described, but I wasn't lucky. I tried keeping the image on my
> home directory (XFS), on tmpfs, and finally on a newly created ext4
> filesystem on a spare LVM volume, but the image just wouldn't break even
> after letting the loop run for a quite a while.

That's certainly an important data point. Is it possible that we're
talking about some kind of miscompilation here, maybe because gcc-9.2.0
is just that tiny bit too spanking current?

> So as the next step I would like to test my theory that the problem
> isn't bdrv_co_block_status() returning a different value after the
> commit, but that qcow2_detect_metadata_preallocation() even runs. I
> think the easiest way to do this would be modifying handle_alloc_space()
> so that it performs the checks, but skips its optimisation regardless of
> the is_zero_cow() return value:

> if (!is_zero_cow(bs, m) || true) {
> continue;
> }

I made the change and the problem went away.

Then, extrapolating the jest of your methodology :), I went ahead and
disabled only bdrv_co_pwrite_zeroes() by placing a continue in front of
it but let qcow2_pre_write_overlap_check() execute and the problem
reappeared. I certainly did not expect that to happen because the
function name ends in _check(), suggesting read-only access. And it's
not even touched by the commit.

This had me so rattled that I revalidated that the problem does indeed
not occur with the commit before. And it does not. I left it running for
about half an hour without problems.

After some more tests I finally figured out that even with -g and no -O
gcc is smart enough to optimize out (!is_zero_cow() || true) and that
corruption only happens if is_zero_cow() is actually called. Corruption
also does not occur if I make is_zero_cow() or is_unallocated() return 0
always.

So my first guess was that is_unallocated() sometimes returns false
positives, making is_zero_cow() report false positives which is not
caught by qcow2_pre_write_overlap_check() and causes
bdrv_co_pwrite_zeroes() to zero out actual data. That seemed a bit
convoluted to me.

But then I realized that corruption still occurs if the rest of
handle_alloc_space() is disabled like so:

--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -2185,9 +2185,8 @@ static int handle_alloc_space(BlockDriverState *bs, 
QCowL2Meta *l2meta)
 continue;
 }
 
-if (!is_zero_cow(bs, m)) {
-continue;
-}
+is_zero_cow(bs, m);
+continue;
 
 /*
  * instead of writing zero COW buffers,

So it's much more likely that is_zero_cow() has a side-effect that
somehow causes corruption later on even without handle_alloc_space()
ever calling bdrv_co_pwrite_zeroes(). That would also explain why
qcow2_pre_write_overlap_check() does not catch those false positives
overwriting metadata because there simply are none.

Putting a breakpoint on handle_alloc_space() and single stepping into
is_zero_cow() I do indeed end up in bdrv_co_block_status():

gdb) bt
#0  0x55d610fd in bdrv_co_block_status (bs=0x567c69e0, 
want_zero=false, offset=5242880, bytes=12288, pnum=0x7ffedffd7b28, map=0x0, 
file=0x0)
at block/io.c:2048
#1  0x55d6167e in bdrv_co_block_status_above
(bs=0x567c69e0, base=0x0, want_zero=false, offset=5242880, bytes=12288, 
pnum=0x7ffedffd7b28, map=0x0, file=0x0) at block/io.c:2190
#2  0x55d61764 in bdrv_block_status_above_co_entry 
(opaque=0x7ffedffd7a10) at block/io.c:2220
#3  0x55d6188f in bdrv_common_block_status_above
(bs=0x567c69e0, base=0x0, want_zero=false, offset=5242880, bytes=12288, 
pnum=0x7ffedffd7b28, map=0x0, file=0x0) at block/io.c:2255
#4  0x55d61afa in bdrv_is_allocated (bs=0x567c69e0, offset=5242880, 
bytes=12288, pnum=0x7ffedffd7b28) at block/io.c:2285
#5  0x55d61b8c in bdrv_is_allocated_above (top=0x567c69e0, 
base=0x0, offset=5242880, bytes=12288, pnum=0x7ffedffd7b80) at block/io.c:2323
#6  0x55d12d48 in is_unallocated (bs=0x567c69e0, offset=5242880, 
bytes=12288) at block/qcow2.c:2151
#7  0x55d12dbc in is_zero_cow (bs=0x567c69e0, m=0x569d35b0) at 
block/qcow2.c:2162
#8  0x55d12e9c in handle_alloc_space (bs=0x567c69e0, 
l2meta=0x569d35b0) at block/qcow2.c:2188
#9  0x55d13321 in qcow2_co_pwritev (bs=0x567c69e0, offset=5255168, 
bytes=4096, qiov=0x7fffe82ec310, flags=0) at block/qcow2.c:2302
#10 0x55d5e6d5 in bdrv_driver_pwritev (bs=0x567c69e0, 
offset=5255168, bytes=4096, qiov=0x7fffe82ec310, flags=0) at block/io.c:1043
#11 0x55d6014b in bdrv_aligned_pwritev (child=0x5675cf80, 
req=0x7ffedffd7e50, offset=5255168, bytes=4096, align=1, qiov=0x7fffe82ec310, 
flags=0)
at block/io.c:1670
#12 0x55d60d77 in bdrv_co_pwritev (child=0x5675cf80, 
offset=5255168, bytes=4096, qiov=0x7fffe82ec310, flags=0) at block/io.c:1897

Re: [PATCH 0/3] eliminate remaining places that abuse memory_region_allocate_system_memory()

2019-10-22 Thread Eduardo Habkost
On Sun, Oct 20, 2019 at 04:38:06PM +0200, Philippe Mathieu-Daudé wrote:
> Ping?

Sorry, missed this.  queued on machine-next.  Pull request will
be submitted today or tomorrow.

> 
> On Fri, Oct 11, 2019 at 5:23 PM Igor Mammedov  wrote:
> > On Thu, 10 Oct 2019 19:35:03 +0200
> > Igor Mammedov  wrote:
> >
> > Forgot to actually CC Eduardo,
> >
> > > On Tue,  8 Oct 2019 07:33:15 -0400
> > > Igor Mammedov  wrote:
> > ...
> > > Eduardo,
> > >
> > > This patches are fixing various machines across tree, so series does not 
> > > belong
> > > to any particular arch specific tree, can you merge it via generic 
> > > machine tree?
> >
> >
> > > >
> > > >
> > > > Igor Mammedov (3):
> > > >   sparc64: use memory_region_allocate_system_memory() only for '-m'
> > > > specified RAM
> > > >   ppc: rs6000_mc: drop usage of memory_region_allocate_system_memory()
> > > >   hppa: drop usage of memory_region_allocate_system_memory() for ROM
> > > >
> > > >  hw/hppa/machine.c|  5 ++---
> > > >  hw/ppc/rs6000_mc.c   | 15 ++-
> > > >  hw/sparc64/niagara.c | 25 +
> > > >  3 files changed, 25 insertions(+), 20 deletions(-)
> > > >

-- 
Eduardo




Re: [PATCH v4 2/2] i386: Add support to get/set/migrate Intel Processor Trace feature

2019-10-22 Thread Eduardo Habkost
On Mon, Oct 21, 2019 at 06:02:28AM +, Kang, Luwei wrote:
> > > > > f9f4cd1..097c953 100644
> > > > > --- a/target/i386/kvm.c
> > > > > +++ b/target/i386/kvm.c
> > > > > @@ -1811,6 +1811,25 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
> > > > >  kvm_msr_entry_add(cpu, MSR_MTRRphysMask(i), mask);
> > > > >  }
> > > > >  }
> > > > > +if (env->features[FEAT_7_0_EBX] & CPUID_7_0_EBX_INTEL_PT) {
> > > > > +int addr_num = kvm_arch_get_supported_cpuid(kvm_state,
> > > > > +0x14, 1,
> > > > > + R_EAX) & 0x7;
> > > > > +
> > > > > +kvm_msr_entry_add(cpu, MSR_IA32_RTIT_CTL,
> > > > > +env->msr_rtit_ctrl);
> > > > > +kvm_msr_entry_add(cpu, MSR_IA32_RTIT_STATUS,
> > > > > +env->msr_rtit_status);
> > > > > +kvm_msr_entry_add(cpu, MSR_IA32_RTIT_OUTPUT_BASE,
> > > > > +env->msr_rtit_output_base);
> > > >
> > > > This causes the following crash on some hosts:
> > > >
> > > >   qemu-system-x86_64: error: failed to set MSR 0x560 to 0x0
> > > >   qemu-system-x86_64: target/i386/kvm.c:2673: kvm_put_msrs: Assertion 
> > > > `ret == cpu->kvm_msr_buf->nmsrs' failed.
> > > >
> > > > Checking for CPUID_7_0_EBX_INTEL_PT is not enough: KVM has
> > > > additional conditions that might prevent writing to this MSR 
> > > > (PT_CAP_topa_output && PT_CAP_single_range_output).  This
> > causes QEMU to crash if some of the conditions aren't met.
> > > >
> > > > Writing and reading this MSR (and the ones below) need to be 
> > > > conditional on KVM_GET_MSR_INDEX_LIST.
> > > >
> > >
> > > Hi Eduardo,
> > > I found this issue can't be reproduced in upstream source code but 
> > > can be reproduced on RHEL8.1. I haven't got the qemu source
> > code of RHEL8.1. But after adding some trace in KVM, I found the KVM has 
> > reported the complete Intel PT CPUID information to qemu
> > but the Intel PT CPUID (0x14) is lost when qemu setting the CPUID to KVM 
> > (cpuid level is 0xd). It looks like lost the below patch.
> > >
> > > commit f24c3a79a415042f6dc195f029a2ba7247d14cac
> > > Author: Luwei Kang 
> > > Date:   Tue Jan 29 18:52:59 2019 -0500
> > > i386: extended the cpuid_level when Intel PT is enabled
> > >
> > > Intel Processor Trace required CPUID[0x14] but the cpuid_level
> > > have no change when create a kvm guest with
> > > e.g. "-cpu qemu64,+intel-pt".
> > 
> > Thanks for the pointer.  This may avoid triggering the bug in the default 
> > configuration, but we still need to make the MSR writing
> > conditional on KVM_GET_MSR_INDEX_LIST.  Older machine-types have 
> > x-intel-pt-auto-level=off, and the user may set `level`
> > manually.
> 
> Hi Eduardo,
> Sorry for a delay reply because my mail filter. I tried with
> the Q35 machine type and default, all looks work well (With
> some old cpu type + "intel_pt" also work well).  KVM will check
> the Intel PT work mode and HW to decide if Intel PT can be
> exposed to guest, only extended the CPUID level is useless. If
> the guest doesn't support Intel PT, any MSR read or write will
> cause #GP. Please remind me if I lost something.

I understand you have tried q35 and pc, but have you tried with
older machine-type versions?

Commit f24c3a79a415 doesn't change behavior on pc-*-3.1 and
older, so it only avoids triggering the crash in the default
case.  Doesn't QEMU crash if running:
"-cpu qemu64,+intel-pt -machine pc-i440fx-3.1"?

KVM rejecting MSR writes when something is missing is correct.
QEMU trying to write the MSR when something is missing (and
crashing because of that) is a bug.

-- 
Eduardo




[PATCH] target/riscv: PMP violation due to wrong size parameter

2019-10-22 Thread Dayeol Lee
riscv_cpu_tlb_fill() uses the `size` parameter to check PMP violation
using pmp_hart_has_privs().
However, if the size is unknown (=0), the ending address will be
`addr - 1` as it is `addr + size - 1` in `pmp_hart_has_privs()`.
This always causes a false PMP violation on the starting address of the
range, as `addr - 1` is not in the range.

In order to fix, we just assume that all bytes from addr to the end of
the page will be accessed if the size is unknown.

Signed-off-by: Dayeol Lee 
Reviewed-by: Richard Henderson 
---
 target/riscv/pmp.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/target/riscv/pmp.c b/target/riscv/pmp.c
index 958c7502a0..7a9fd415ba 100644
--- a/target/riscv/pmp.c
+++ b/target/riscv/pmp.c
@@ -232,6 +232,7 @@ bool pmp_hart_has_privs(CPURISCVState *env, target_ulong 
addr,
 {
 int i = 0;
 int ret = -1;
+int pmp_size = 0;
 target_ulong s = 0;
 target_ulong e = 0;
 pmp_priv_t allowed_privs = 0;
@@ -241,11 +242,21 @@ bool pmp_hart_has_privs(CPURISCVState *env, target_ulong 
addr,
 return true;
 }
 
+/*
+ * if size is unknown (0), assume that all bytes
+ * from addr to the end of the page will be accessed.
+ */
+if (size == 0) {
+pmp_size = -(addr | TARGET_PAGE_MASK);
+} else {
+pmp_size = size;
+}
+
 /* 1.10 draft priv spec states there is an implicit order
  from low to high */
 for (i = 0; i < MAX_RISCV_PMPS; i++) {
 s = pmp_is_in_range(env, i, addr);
-e = pmp_is_in_range(env, i, addr + size - 1);
+e = pmp_is_in_range(env, i, addr + pmp_size - 1);
 
 /* partially inside */
 if ((s + e) == 1) {
-- 
2.23.0




[Bug 1848556] Re: qemu-img check failing on remote image in Eoan

2019-10-22 Thread Rod Smith
I managed to check the PPA version just now, and it's working fine.
Thanks for the quick fix!

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1848556

Title:
  qemu-img check failing on remote image in Eoan

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Triaged
Status in qemu source package in Eoan:
  Triaged
Status in qemu source package in Focal:
  Triaged

Bug description:
  Ubuntu SRU Template:

  [Impact]

   * There is fallout due to changes in libcurl that affect qemu and might 
 lead to a hang.

   * Fix by backporting the upstream fix

  [Test Case]

   * If you have network just run
 $ qemu-img check http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img

   * Without network, install apache2, and get a complex qemu file (like a 
 cloud image) onto the system. Then access the file via apache http but 
 not localhost (that would work)

  [Regression Potential]

   * The change is local to the libcurl usage of qemu, so that could be 
 affected. But then this is what has been found to not work here, so I'd 
 expect not too much trouble. But if so then in the curl usage (which 
 means disks on http)

  [Other Info]
   
   * n/a

  ---

  The "qemu-img check" function is failing on remote (HTTP-hosted)
  images, beginning with Ubuntu 19.10 (qemu-utils version 1:4.0+dfsg-
  0ubuntu9). With previous versions, through Ubuntu 19.04/qemu-utils
  version 1:3.1+dfsg-2ubuntu3.5, the following worked:

  $ /usr/bin/qemu-img check  
http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img
  No errors were found on the image.
  19778/36032 = 54.89% allocated, 90.34% fragmented, 89.90% compressed clusters
  Image end offset: 514064384

  The 10.193.37.117 server holds an Apache server that hosts the cloud
  images on a LAN. Beginning with Ubuntu 19.10/qemu-utils 1:4.0+dfsg-
  0ubuntu9, the same command never returns. (I've left it for up to an
  hour with no change.) I'm able to wget the image from the same server
  and installation on which qemu-img check fails. I've tried several
  .img files on the server, ranging from Bionic to Eoan, with the same
  results with all of them.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1848556/+subscriptions



Re: [PATCH for 4.2 v1 00/19] testing/next before softfreeze

2019-10-22 Thread Alex Bennée


Alex Bennée  writes:

> Hi,
>
> This is the current status of testing/next. I dropped the Travis arm64
> build due to stability concerns. As far as I can tell Thomas' latest
> iotest updates are working fine. If there are any other patches worth
> considering before the softfreeze now is the time to shout.
>

> John Snow (1):
>   iotests: remove 'linux' from default supported platforms
>
> Thomas Huth (5):

>   iotests: Test 041 only works on certain systems
>   iotests: Test 183 does not work on macOS and OpenBSD
>   iotests: Skip "make check-block" if QEMU does not support virtio-blk
>   iotests: Enable more tests in the 'auto' group to improve test
> coverage
>   iotests: Remove 130 from the "auto" group


I'll drop these from my tree so they can go in with the rest of the
iotests stuff.

--
Alex Bennée



Re: [PATCH v3 0/6] Enable more iotests during "make check-block"

2019-10-22 Thread Alex Bennée


Thomas Huth  writes:

> On 22/10/2019 15.48, Alex Bennée wrote:
>>
>> Max Reitz  writes:
>>
>>> On 22.10.19 15:11, Alex Bennée wrote:

 Thomas Huth  writes:

> As discussed here:
>
>  https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg00697.html
>
> and here:
>
>  https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg01388.html

 Queued to testing/next, thanks.
>>>
>>> It should be noted that this series depends on my SOCK_DIR series (which
>>> I have in my block branch), or the newly added tests are likely to fail
>>> in the CI environment.
>>
>> Ahh I misread
>> 
>>
> it would be good to have some more valuable iotests enabled in the
> "auto" group to get better iotest coverage during "make check".
>
> And once Max' "iotests: Add and use $SOCK_DIR" patch series has been
> merged, we can indeed enable these Python-based tests, too.
>>
>> I though these weren't enabled in this series. Do I need to drop all the
>> patches?
>
> I think it's better if the iotest patches go through Max' or Kevin's
> block tree.

OK I can drop them from my tree.

>
>  Thomas


--
Alex Bennée



[PATCH v3 2/6] hppa: Add support for LASI chip with i82596 NIC

2019-10-22 Thread Sven Schnelle
From: Helge Deller 

LASI is a built-in multi-I/O chip which supports serial, parallel,
network (Intel i82596 Apricot), sound and other functionalities.
LASI has been used in many HP PARISC machines.
This patch adds the necessary parts to allow Linux and HP-UX to detect
LASI and the network card.

Signed-off-by: Helge Deller 
Signed-off-by: Sven Schnelle 
---
 MAINTAINERS |   2 +
 hw/hppa/Kconfig |   1 +
 hw/hppa/Makefile.objs   |   2 +-
 hw/hppa/hppa_sys.h  |   2 +
 hw/hppa/lasi.c  | 360 ++
 hw/hppa/machine.c   |   8 +-
 hw/hppa/trace-events|   5 +
 hw/net/Kconfig  |   7 +
 hw/net/Makefile.objs|   2 +
 hw/net/i82596.c | 734 
 hw/net/i82596.h |  55 +++
 hw/net/lasi_i82596.c| 188 +
 hw/net/trace-events |  13 +
 include/hw/net/lasi_82596.h |  29 ++
 14 files changed, 1406 insertions(+), 2 deletions(-)
 create mode 100644 hw/hppa/lasi.c
 create mode 100644 hw/net/i82596.c
 create mode 100644 hw/net/i82596.h
 create mode 100644 hw/net/lasi_i82596.c
 create mode 100644 include/hw/net/lasi_82596.h

diff --git a/MAINTAINERS b/MAINTAINERS
index f9541c3305..91e9e8ceac 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -178,6 +178,8 @@ S: Maintained
 F: target/hppa/
 F: hw/hppa/
 F: disas/hppa.c
+F: hw/net/*i82596*
+F: include/hw/net/lasi_82596.h
 
 LM32 TCG CPUs
 M: Michael Walle 
diff --git a/hw/hppa/Kconfig b/hw/hppa/Kconfig
index 6e5d74a825..2a7b38d6d6 100644
--- a/hw/hppa/Kconfig
+++ b/hw/hppa/Kconfig
@@ -10,3 +10,4 @@ config DINO
 select IDE_CMD646
 select MC146818RTC
 select LSI_SCSI_PCI
+select LASI_82596
diff --git a/hw/hppa/Makefile.objs b/hw/hppa/Makefile.objs
index 67838f50a3..eac3467d8a 100644
--- a/hw/hppa/Makefile.objs
+++ b/hw/hppa/Makefile.objs
@@ -1 +1 @@
-obj-$(CONFIG_DINO) += pci.o machine.o dino.o
+obj-$(CONFIG_DINO) += pci.o machine.o dino.o lasi.o
diff --git a/hw/hppa/hppa_sys.h b/hw/hppa/hppa_sys.h
index 43d25d21fc..d99b5dd87b 100644
--- a/hw/hppa/hppa_sys.h
+++ b/hw/hppa/hppa_sys.h
@@ -11,6 +11,8 @@
 #include "hppa_hardware.h"
 
 PCIBus *dino_init(MemoryRegion *, qemu_irq *, qemu_irq *);
+DeviceState *lasi_init(MemoryRegion *);
+#define enable_lasi_lan()   0
 
 #define TYPE_DINO_PCI_HOST_BRIDGE "dino-pcihost"
 
diff --git a/hw/hppa/lasi.c b/hw/hppa/lasi.c
new file mode 100644
index 00..51752589f3
--- /dev/null
+++ b/hw/hppa/lasi.c
@@ -0,0 +1,360 @@
+/*
+ * HP-PARISC Lasi chipset emulation.
+ *
+ * (C) 2019 by Helge Deller 
+ *
+ * This work is licensed under the GNU GPL license version 2 or later.
+ *
+ * Documentation available at:
+ * https://parisc.wiki.kernel.org/images-parisc/7/79/Lasi_ers.pdf
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/units.h"
+#include "qapi/error.h"
+#include "cpu.h"
+#include "trace.h"
+#include "hw/hw.h"
+#include "hw/irq.h"
+#include "sysemu/sysemu.h"
+#include "sysemu/runstate.h"
+#include "hppa_sys.h"
+#include "hw/net/lasi_82596.h"
+#include "hw/char/parallel.h"
+#include "hw/char/serial.h"
+#include "exec/address-spaces.h"
+#include "migration/vmstate.h"
+
+#define TYPE_LASI_CHIP "lasi-chip"
+
+#define LASI_IRR0x00/* RO */
+#define LASI_IMR0x04
+#define LASI_IPR0x08
+#define LASI_ICR0x0c
+#define LASI_IAR0x10
+
+#define LASI_PCR0x0C000 /* LASI Power Control register */
+#define LASI_ERRLOG 0x0C004 /* LASI Error Logging register */
+#define LASI_VER0x0C008 /* LASI Version Control register */
+#define LASI_IORESET0x0C00C /* LASI I/O Reset register */
+#define LASI_AMR0x0C010 /* LASI Arbitration Mask register */
+#define LASI_IO_CONF0x7FFFE /* LASI primary configuration register */
+#define LASI_IO_CONF2   0x7 /* LASI secondary configuration register */
+
+#define LASI_BIT(x) (1ul << (x))
+#define LASI_IRQ_BITS   (LASI_BIT(5) | LASI_BIT(7) | LASI_BIT(8) | LASI_BIT(9) 
\
+| LASI_BIT(13) | LASI_BIT(14) | LASI_BIT(16) | LASI_BIT(17) \
+| LASI_BIT(18) | LASI_BIT(19) | LASI_BIT(20) | LASI_BIT(21) \
+| LASI_BIT(26))
+
+#define ICR_BUS_ERROR_BIT  LASI_BIT(8)  /* bit 8 in ICR */
+#define ICR_TOC_BITLASI_BIT(1)  /* bit 1 in ICR */
+
+#define LASI_CHIP(obj) \
+OBJECT_CHECK(LasiState, (obj), TYPE_LASI_CHIP)
+
+#define LASI_RTC_HPA(LASI_HPA + 0x9000)
+
+typedef struct LasiState {
+PCIHostState parent_obj;
+
+uint32_t irr;
+uint32_t imr;
+uint32_t ipr;
+uint32_t icr;
+uint32_t iar;
+
+uint32_t errlog;
+uint32_t amr;
+uint32_t rtc;
+time_t rtc_ref;
+
+MemoryRegion this_mem;
+} LasiState;
+
+static bool lasi_chip_mem_valid(void *opaque, hwaddr addr,
+unsigned size, bool is_write,
+MemTxAttrs attrs)
+{
+bool ret = false;
+
+switch (addr) {
+case LASI_IRR:
+case LASI_IMR:
+case LASI_IPR:
+case 

[PATCH v3 4/6] hppa: add emulation of LASI PS2 controllers

2019-10-22 Thread Sven Schnelle
Signed-off-by: Sven Schnelle 
---
 hw/hppa/Kconfig|   1 +
 hw/hppa/lasi.c |  10 +-
 hw/input/Kconfig   |   3 +
 hw/input/Makefile.objs |   1 +
 hw/input/lasips2.c | 289 +
 hw/input/ps2.c |   5 +
 hw/input/trace-events  |   5 +
 include/hw/input/lasips2.h |  16 ++
 include/hw/input/ps2.h |   1 +
 9 files changed, 330 insertions(+), 1 deletion(-)
 create mode 100644 hw/input/lasips2.c
 create mode 100644 include/hw/input/lasips2.h

diff --git a/hw/hppa/Kconfig b/hw/hppa/Kconfig
index 2a7b38d6d6..7f9be7f25c 100644
--- a/hw/hppa/Kconfig
+++ b/hw/hppa/Kconfig
@@ -11,3 +11,4 @@ config DINO
 select MC146818RTC
 select LSI_SCSI_PCI
 select LASI_82596
+select LASIPS2
diff --git a/hw/hppa/lasi.c b/hw/hppa/lasi.c
index 51752589f3..d8d03f95c0 100644
--- a/hw/hppa/lasi.c
+++ b/hw/hppa/lasi.c
@@ -22,6 +22,7 @@
 #include "hw/net/lasi_82596.h"
 #include "hw/char/parallel.h"
 #include "hw/char/serial.h"
+#include "hw/input/lasips2.h"
 #include "exec/address-spaces.h"
 #include "migration/vmstate.h"
 
@@ -324,6 +325,7 @@ DeviceState *lasi_init(MemoryRegion *address_space)
  lpt_irq, parallel_hds[0]);
 
 /* Real time clock (RTC), it's only one 32-bit counter @9000 */
+
 s->rtc = time(NULL);
 s->rtc_ref = 0;
 
@@ -333,8 +335,14 @@ DeviceState *lasi_init(MemoryRegion *address_space)
 lasi_get_irq(LASI_UART_HPA));
 serial_mm_init(address_space, LASI_UART_HPA + 0x800, 0,
 serial_irq, 800 / 16,
-serial_hd(1), DEVICE_NATIVE_ENDIAN);
+serial_hd(0), DEVICE_NATIVE_ENDIAN);
 }
+
+/* PS/2 Keyboard/Mouse */
+qemu_irq ps2kbd_irq = qemu_allocate_irq(lasi_set_irq, s,
+lasi_get_irq(LASI_PS2KBD_HPA));
+lasips2_init(address_space, LASI_PS2KBD_HPA,  ps2kbd_irq);
+
 return dev;
 }
 
diff --git a/hw/input/Kconfig b/hw/input/Kconfig
index 287f08887b..25c77a1b87 100644
--- a/hw/input/Kconfig
+++ b/hw/input/Kconfig
@@ -41,3 +41,6 @@ config VHOST_USER_INPUT
 
 config TSC210X
 bool
+
+config LASIPS2
+select PS2
diff --git a/hw/input/Makefile.objs b/hw/input/Makefile.objs
index a1bc502ed0..f98f635685 100644
--- a/hw/input/Makefile.objs
+++ b/hw/input/Makefile.objs
@@ -15,3 +15,4 @@ common-obj-$(CONFIG_VHOST_USER_INPUT) += vhost-user-input.o
 obj-$(CONFIG_MILKYMIST) += milkymist-softusb.o
 obj-$(CONFIG_PXA2XX) += pxa2xx_keypad.o
 obj-$(CONFIG_TSC210X) += tsc210x.o
+obj-$(CONFIG_LASIPS2) += lasips2.o
diff --git a/hw/input/lasips2.c b/hw/input/lasips2.c
new file mode 100644
index 00..1943671d1e
--- /dev/null
+++ b/hw/input/lasips2.c
@@ -0,0 +1,289 @@
+/*
+ * QEMU HP Lasi PS/2 interface emulation
+ *
+ * Copyright (c) 2019 Sven Schnelle
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include "qemu/osdep.h"
+#include "qemu/log.h"
+#include "hw/qdev-properties.h"
+#include "hw/hw.h"
+#include "hw/input/ps2.h"
+#include "hw/input/lasips2.h"
+#include "hw/sysbus.h"
+#include "exec/hwaddr.h"
+#include "sysemu/sysemu.h"
+#include "trace.h"
+#include "exec/address-spaces.h"
+#include "migration/vmstate.h"
+#include "hw/irq.h"
+struct LASIPS2State;
+typedef struct LASIPS2Port {
+struct LASIPS2State *parent;
+MemoryRegion reg;
+void *dev;
+uint8_t id;
+uint8_t control;
+uint8_t buf;
+bool loopback_rbne;
+bool irq;
+} LASIPS2Port;
+
+typedef struct LASIPS2State {
+LASIPS2Port kbd;
+LASIPS2Port mouse;
+qemu_irq irq;
+} LASIPS2State;
+
+static const VMStateDescription vmstate_lasips2 = {
+.name = "lasips2",
+.version_id = 0,
+.minimum_version_id = 0,
+.fields = (VMStateField[]) {
+VMSTATE_UINT8(kbd.control, LASIPS2State),
+VMSTATE_UINT8(kbd.id, LASIPS2State),
+VMSTATE_BOOL(kbd.irq, LASIPS2State),
+VMSTATE_UINT8(mouse.control, LASIPS2State),
+VMSTATE_UINT8(mouse.id, 

[PATCH v3 5/6] hppa: Add emulation of Artist graphics

2019-10-22 Thread Sven Schnelle
This adds emulation of Artist graphics good enough
to get a Text console on both Linux and HP-UX. The
X11 server from HP-UX also works.

Signed-off-by: Sven Schnelle 
---
 hw/display/Kconfig   |3 +
 hw/display/Makefile.objs |1 +
 hw/display/artist.c  | 1336 ++
 hw/display/trace-events  |9 +
 hw/hppa/Kconfig  |1 +
 hw/hppa/hppa_hardware.h  |1 +
 hw/hppa/machine.c|   10 +
 7 files changed, 1361 insertions(+)
 create mode 100644 hw/display/artist.c

diff --git a/hw/display/Kconfig b/hw/display/Kconfig
index cbdf7b1a67..953631afb6 100644
--- a/hw/display/Kconfig
+++ b/hw/display/Kconfig
@@ -91,6 +91,9 @@ config TCX
 config CG3
 bool
 
+config ARTIST
+bool
+
 config VGA
 bool
 
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index 5a4066383b..5f63294149 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -39,6 +39,7 @@ common-obj-$(CONFIG_SM501) += sm501.o
 common-obj-$(CONFIG_TCX) += tcx.o
 common-obj-$(CONFIG_CG3) += cg3.o
 common-obj-$(CONFIG_NEXTCUBE) += next-fb.o
+common-obj-$(CONFIG_ARTIST) += artist.o
 
 obj-$(CONFIG_VGA) += vga.o
 
diff --git a/hw/display/artist.c b/hw/display/artist.c
new file mode 100644
index 00..9b285b3993
--- /dev/null
+++ b/hw/display/artist.c
@@ -0,0 +1,1336 @@
+/*
+ * QEMU HP Artist Emulation
+ *
+ * Copyright (c) 2019 Sven Schnelle 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "qemu/error-report.h"
+#include "qemu/typedefs.h"
+#include "qemu/log.h"
+#include "qemu/module.h"
+#include "qapi/error.h"
+#include "hw/sysbus.h"
+#include "hw/loader.h"
+#include "hw/qdev-core.h"
+#include "hw/qdev-properties.h"
+#include "migration/vmstate.h"
+#include "ui/console.h"
+#include "trace.h"
+
+#define TYPE_ARTIST "artist"
+#define ARTIST(obj) OBJECT_CHECK(ARTISTState, (obj), TYPE_ARTIST)
+
+struct vram_buffer {
+uint8_t *data;
+int size;
+int width;
+int height;
+};
+
+typedef struct ARTISTState {
+SysBusDevice parent_obj;
+
+QemuConsole *con;
+MemoryRegion vram_mem;
+MemoryRegion reg;
+uint8_t *vram;
+
+struct vram_buffer vram_buffer[16];
+
+uint16_t width;
+uint16_t height;
+uint16_t depth;
+
+uint32_t fg_color;
+uint32_t bg_color;
+
+uint32_t vram_char_y;
+uint32_t vram_bitmask;
+
+uint32_t vram_start;
+uint32_t vram_pos;
+
+uint32_t vram_size;
+
+uint32_t blockmove_source;
+uint32_t blockmove_dest;
+uint32_t blockmove_size;
+
+uint32_t line_size;
+uint32_t line_end;
+uint32_t line_xy;
+uint32_t line_pattern_start;
+uint32_t line_pattern_skip;
+
+uint32_t cursor_pos;
+
+uint32_t cursor_height;
+uint32_t cursor_width;
+
+uint32_t plane_mask;
+
+uint32_t reg_100080;
+uint32_t reg_300200;
+uint32_t reg_300208;
+uint32_t reg_300218;
+
+uint32_t cmap_bm_access;
+uint32_t dst_bm_access;
+uint32_t src_bm_access;
+uint32_t control_plane;
+uint32_t transfer_data;
+uint32_t image_bitmap_op;
+
+uint32_t font_write1;
+uint32_t font_write2;
+uint32_t font_write_pos_y;
+
+int draw_line_pattern;
+} ARTISTState;
+
+typedef enum {
+ARTIST_BUFFER_AP = 1,
+ARTIST_BUFFER_OVERLAY = 2,
+ARTIST_BUFFER_CURSOR1 = 6,
+ARTIST_BUFFER_CURSOR2 = 7,
+ARTIST_BUFFER_ATTRIBUTE = 13,
+ARTIST_BUFFER_CMAP = 15,
+} artist_buffer_t;
+
+typedef enum {
+VRAM_IDX = 0x1004a0,
+VRAM_BITMASK = 0x1005a0,
+VRAM_WRITE_INCR_X = 0x100600,
+VRAM_WRITE_INCR_X2 = 0x100604,
+VRAM_WRITE_INCR_Y = 0x100620,
+VRAM_START = 0x100800,
+BLOCK_MOVE_SIZE = 0x100804,
+BLOCK_MOVE_SOURCE = 0x100808,
+TRANSFER_DATA = 0x100820,
+FONT_WRITE_INCR_Y = 0x1008a0,
+VRAM_START_TRIGGER = 0x100a00,
+VRAM_SIZE_TRIGGER = 0x100a04,
+FONT_WRITE_START = 0x100aa0,
+BLOCK_MOVE_DEST_TRIGGER = 0x100b00,
+BLOCK_MOVE_SIZE_TRIGGER = 0x100b04,
+LINE_XY = 0x100ccc,
+PATTERN_LINE_START = 0x100ecc,
+LINE_SIZE = 0x100e04,
+LINE_END = 0x100e44,
+CMAP_BM_ACCESS = 0x118000,
+DST_BM_ACCESS = 0x118004,
+SRC_BM_ACCESS = 0x118008,
+CONTROL_PLANE = 0x11800c,
+FG_COLOR = 0x118010,
+BG_COLOR = 0x118014,
+PLANE_MASK = 0x118018,
+IMAGE_BITMAP_OP = 0x11801c,
+CURSOR_POS = 0x300100,
+CURSOR_CTRL = 0x300104,
+} artist_reg_t;
+
+typedef enum {
+ARTIST_ROP_CLEAR = 0,
+ARTIST_ROP_COPY = 3,
+ARTIST_ROP_XOR = 6,
+ARTIST_ROP_NOT_DST = 10,
+ARTIST_ROP_SET = 15,
+} artist_rop_t;
+
+#define REG_NAME(_x) case _x: return " "#_x;
+static const char *artist_reg_name(uint64_t addr)
+{
+switch ((artist_reg_t)addr) {
+REG_NAME(VRAM_IDX);
+REG_NAME(VRAM_BITMASK);
+REG_NAME(VRAM_WRITE_INCR_X);
+REG_NAME(VRAM_WRITE_INCR_X2);
+REG_NAME(VRAM_WRITE_INCR_Y);
+REG_NAME(VRAM_START);
+REG_NAME(BLOCK_MOVE_SIZE);

[PATCH v3 1/6] hw/hppa/dino.c: Improve emulation of Dino PCI chip

2019-10-22 Thread Sven Schnelle
From: Helge Deller 

The tests of the dino chip with the Online-diagnostics CD
("ODE DINOTEST") now succeeds.
Additionally add some qemu trace events.

Signed-off-by: Helge Deller 
Signed-off-by: Sven Schnelle 
Reviewed-by: Philippe Mathieu-Daudé 
---
 MAINTAINERS  |  2 +-
 hw/hppa/dino.c   | 97 +---
 hw/hppa/trace-events |  5 +++
 3 files changed, 89 insertions(+), 15 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 250ce8e7a1..f9541c3305 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -874,7 +874,7 @@ F: hw/*/etraxfs_*.c
 
 HP-PARISC Machines
 --
-Dino
+HP B160L
 M: Richard Henderson 
 R: Helge Deller 
 S: Odd Fixes
diff --git a/hw/hppa/dino.c b/hw/hppa/dino.c
index ab6969b45f..9797a7f0d9 100644
--- a/hw/hppa/dino.c
+++ b/hw/hppa/dino.c
@@ -1,7 +1,7 @@
 /*
- * HP-PARISC Dino PCI chipset emulation.
+ * HP-PARISC Dino PCI chipset emulation, as in B160L and similiar machines
  *
- * (C) 2017 by Helge Deller 
+ * (C) 2017-2019 by Helge Deller 
  *
  * This work is licensed under the GNU GPL license version 2 or later.
  *
@@ -21,6 +21,7 @@
 #include "migration/vmstate.h"
 #include "hppa_sys.h"
 #include "exec/address-spaces.h"
+#include "trace.h"
 
 
 #define TYPE_DINO_PCI_HOST_BRIDGE "dino-pcihost"
@@ -82,11 +83,28 @@
 #define DINO_PCI_HOST_BRIDGE(obj) \
 OBJECT_CHECK(DinoState, (obj), TYPE_DINO_PCI_HOST_BRIDGE)
 
+#define DINO800_REGS ((DINO_TLTIM - DINO_GMASK) / 4)
+static const uint32_t reg800_keep_bits[DINO800_REGS] = {
+MAKE_64BIT_MASK(0, 1),
+MAKE_64BIT_MASK(0, 7),
+MAKE_64BIT_MASK(0, 7),
+MAKE_64BIT_MASK(0, 8),
+MAKE_64BIT_MASK(0, 7),
+MAKE_64BIT_MASK(0, 9),
+MAKE_64BIT_MASK(0, 32),
+MAKE_64BIT_MASK(0, 8),
+MAKE_64BIT_MASK(0, 30),
+MAKE_64BIT_MASK(0, 25),
+MAKE_64BIT_MASK(0, 22),
+MAKE_64BIT_MASK(0, 9),
+};
+
 typedef struct DinoState {
 PCIHostState parent_obj;
 
 /* PCI_CONFIG_ADDR is parent_obj.config_reg, via pci_host_conf_be_ops,
so that we can map PCI_CONFIG_DATA to pci_host_data_be_ops.  */
+uint32_t config_reg_dino; /* keep original copy, including 2 lowest bits */
 
 uint32_t iar0;
 uint32_t iar1;
@@ -94,8 +112,12 @@ typedef struct DinoState {
 uint32_t ipr;
 uint32_t icr;
 uint32_t ilr;
+uint32_t io_fbb_en;
 uint32_t io_addr_en;
 uint32_t io_control;
+uint32_t toc_addr;
+
+uint32_t reg800[DINO800_REGS];
 
 MemoryRegion this_mem;
 MemoryRegion pci_mem;
@@ -106,8 +128,6 @@ typedef struct DinoState {
 MemoryRegion bm_ram_alias;
 MemoryRegion bm_pci_alias;
 MemoryRegion bm_cpu_alias;
-
-MemoryRegion cpu0_eir_mem;
 } DinoState;
 
 /*
@@ -122,6 +142,8 @@ static void gsc_to_pci_forwarding(DinoState *s)
 tmp = extract32(s->io_control, 7, 2);
 enabled = (tmp == 0x01);
 io_addr_en = s->io_addr_en;
+/* Mask out first (=firmware) and last (=Dino) areas. */
+io_addr_en &= ~(BIT(31) | BIT(0));
 
 memory_region_transaction_begin();
 for (i = 1; i < 31; i++) {
@@ -142,6 +164,8 @@ static bool dino_chip_mem_valid(void *opaque, hwaddr addr,
 unsigned size, bool is_write,
 MemTxAttrs attrs)
 {
+bool ret = false;
+
 switch (addr) {
 case DINO_IAR0:
 case DINO_IAR1:
@@ -152,16 +176,22 @@ static bool dino_chip_mem_valid(void *opaque, hwaddr addr,
 case DINO_ICR:
 case DINO_ILR:
 case DINO_IO_CONTROL:
+case DINO_IO_FBB_EN:
 case DINO_IO_ADDR_EN:
 case DINO_PCI_IO_DATA:
-return true;
+case DINO_TOC_ADDR:
+case DINO_GMASK ... DINO_TLTIM:
+ret = true;
+break;
 case DINO_PCI_IO_DATA + 2:
-return size <= 2;
+ret = (size <= 2);
+break;
 case DINO_PCI_IO_DATA + 1:
 case DINO_PCI_IO_DATA + 3:
-return size == 1;
+ret = (size == 1);
 }
-return false;
+trace_dino_chip_mem_valid(addr, ret);
+return ret;
 }
 
 static MemTxResult dino_chip_read_with_attrs(void *opaque, hwaddr addr,
@@ -194,6 +224,9 @@ static MemTxResult dino_chip_read_with_attrs(void *opaque, 
hwaddr addr,
 }
 break;
 
+case DINO_IO_FBB_EN:
+val = s->io_fbb_en;
+break;
 case DINO_IO_ADDR_EN:
 val = s->io_addr_en;
 break;
@@ -227,12 +260,28 @@ static MemTxResult dino_chip_read_with_attrs(void 
*opaque, hwaddr addr,
 case DINO_IRR1:
 val = s->ilr & s->imr & s->icr;
 break;
+case DINO_TOC_ADDR:
+val = s->toc_addr;
+break;
+case DINO_GMASK ... DINO_TLTIM:
+val = s->reg800[(addr - DINO_GMASK) / 4];
+if (addr == DINO_PAMR) {
+val &= ~0x01;  /* LSB is hardwired to 0 */
+}
+if (addr == DINO_MLTIM) {
+val &= ~0x07;  /* 3 LSB are hardwired to 0 */
+}
+if (addr == 

[PATCH v3 0/6] HPPA: i82596, PS/2 and graphics emulation

2019-10-22 Thread Sven Schnelle
Hi,

these series adds quite a lot to the HPPA emulation in QEMU:
i82596 emulation from Helge, PS/2 and Artist graphics emulation.

See https://parisc.wiki.kernel.org/index.php/Qemu for a few screenshots
of QEMU running a X11/CDE session in HP-UX.

Changes in v3:
 - use BIT() macro in gsc_to_pci_forwarding()
 - fix version id in vm state
 - fix an error in the PS/2 KBD_CMD_SET_MAKE_BREAK implementation

Changes in v2:
 - dropped 'hppa: remove ISA region' as that patch requires some more work
 - added shortlog to seabios update
 - use const and MAKE_64BIT_MASK in dino.c

Regards,
Sven


Helge Deller (2):
  hw/hppa/dino.c: Improve emulation of Dino PCI chip
  hppa: Add support for LASI chip with i82596 NIC

Sven Schnelle (4):
  ps2: accept 'Set Key Make and Break' commands
  hppa: add emulation of LASI PS2 controllers
  hppa: Add emulation of Artist graphics
  seabios-hppa: update to latest version

 MAINTAINERS |4 +-
 hw/display/Kconfig  |3 +
 hw/display/Makefile.objs|1 +
 hw/display/artist.c | 1336 +++
 hw/display/trace-events |9 +
 hw/hppa/Kconfig |3 +
 hw/hppa/Makefile.objs   |2 +-
 hw/hppa/dino.c  |   97 ++-
 hw/hppa/hppa_hardware.h |1 +
 hw/hppa/hppa_sys.h  |2 +
 hw/hppa/lasi.c  |  368 ++
 hw/hppa/machine.c   |   18 +-
 hw/hppa/trace-events|   10 +
 hw/input/Kconfig|3 +
 hw/input/Makefile.objs  |1 +
 hw/input/lasips2.c  |  289 
 hw/input/ps2.c  |   15 +
 hw/input/trace-events   |5 +
 hw/net/Kconfig  |7 +
 hw/net/Makefile.objs|2 +
 hw/net/i82596.c |  734 +++
 hw/net/i82596.h |   55 ++
 hw/net/lasi_i82596.c|  188 +
 hw/net/trace-events |   13 +
 include/hw/input/lasips2.h  |   16 +
 include/hw/input/ps2.h  |1 +
 include/hw/net/lasi_82596.h |   29 +
 pc-bios/hppa-firmware.img   |  Bin 783724 -> 772876 bytes
 roms/seabios-hppa   |2 +-
 29 files changed, 3196 insertions(+), 18 deletions(-)
 create mode 100644 hw/display/artist.c
 create mode 100644 hw/hppa/lasi.c
 create mode 100644 hw/input/lasips2.c
 create mode 100644 hw/net/i82596.c
 create mode 100644 hw/net/i82596.h
 create mode 100644 hw/net/lasi_i82596.c
 create mode 100644 include/hw/input/lasips2.h
 create mode 100644 include/hw/net/lasi_82596.h

-- 
2.23.0




[PATCH v3 3/6] ps2: accept 'Set Key Make and Break' commands

2019-10-22 Thread Sven Schnelle
HP-UX sends both the 'Set key make and break (0xfc) and
'Set all key typematic make and break' (0xfa). QEMU response
with 'Resend' as it doesn't handle these commands. HP-UX than
reports an PS/2 max retransmission exceeded error. Add these
commands and just reply with ACK.

Signed-off-by: Sven Schnelle 
---
 hw/input/ps2.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/hw/input/ps2.c b/hw/input/ps2.c
index 67f92f6112..0b671b6339 100644
--- a/hw/input/ps2.c
+++ b/hw/input/ps2.c
@@ -49,6 +49,8 @@
 #define KBD_CMD_RESET_DISABLE  0xF5/* reset and disable scanning */
 #define KBD_CMD_RESET_ENABLE   0xF6/* reset and enable scanning */
 #define KBD_CMD_RESET  0xFF/* Reset */
+#define KBD_CMD_SET_MAKE_BREAK  0xFC/* Set Make and Break mode */
+#define KBD_CMD_SET_TYPEMATIC   0xFA/* Set Typematic Make and Break mode */
 
 /* Keyboard Replies */
 #define KBD_REPLY_POR  0xAA/* Power on reset */
@@ -573,6 +575,7 @@ void ps2_write_keyboard(void *opaque, int val)
 case KBD_CMD_SCANCODE:
 case KBD_CMD_SET_LEDS:
 case KBD_CMD_SET_RATE:
+case KBD_CMD_SET_MAKE_BREAK:
 s->common.write_cmd = val;
 ps2_queue(>common, KBD_REPLY_ACK);
 break;
@@ -592,11 +595,18 @@ void ps2_write_keyboard(void *opaque, int val)
 KBD_REPLY_ACK,
 KBD_REPLY_POR);
 break;
+case KBD_CMD_SET_TYPEMATIC:
+ps2_queue(>common, KBD_REPLY_ACK);
+break;
 default:
 ps2_queue(>common, KBD_REPLY_RESEND);
 break;
 }
 break;
+case KBD_CMD_SET_MAKE_BREAK:
+ps2_queue(>common, KBD_REPLY_ACK);
+s->common.write_cmd = -1;
+break;
 case KBD_CMD_SCANCODE:
 if (val == 0) {
 if (s->common.queue.count <= PS2_QUEUE_SIZE - 2) {
-- 
2.23.0




Re: [RFC PATCH] iothread: add set_iothread_poll_* commands

2019-10-22 Thread Eric Blake

On 10/22/19 3:12 AM, yezhenyu (A) wrote:

Since qemu2.9, QEMU added three AioContext poll parameters to struct
IOThread: poll_max_ns, poll_grow and poll_shrink. These properties are
used to control iothread polling time.

However, there isn't properly hmp commands to adjust them when the VM is
alive. It's useful to adjust them online when observing the impact of
different property value on performance.

This patch add three hmp commands to adjust iothread poll-* properties
for special iothread:

set_iothread_poll_max_ns: set the maximum polling time in ns;
set_iothread_poll_grow: set how many ns will be added to polling time;
set_iothread_poll_shrink: set how many ns will be removed from polling
time.

Signed-off-by: Zhenyu Ye 
---
hmp-commands.hx | 42 
hmp.c | 30 +++
hmp.h | 3 ++
include/sysemu/iothread.h | 6 +++
iothread.c | 80 +++
qapi/misc.json | 23 +++
6 files changed, 184 insertions(+)


Looking at just the QMP...


+++ b/qapi/misc.json
@@ -675,6 +675,29 @@
{ 'command': 'query-iothreads', 'returns': ['IOThreadInfo'],
'allow-preconfig': true }

+##
+# @set-iothread-poll-param:
+#
+# Set poll-* properties for a special iothread.
+# The poll-* name can be poll_max_ns/poll_grow/poll_shrink.


This should be an enum.


+#
+# Notes: can not set the QEMU main loop thread, which is not declared
+# using the -object iothread command-line option. The poll_ns property can not
+# be set manually, which is auto-adjust.


You failed to document the parameters (iothread_id, name, value).


+#
+# Example:
+#
+# -> { "execute": "set-iothread-poll-param",
+# "arguments": { "iothread_id": "1",
+# "name": "poll_max_ns",
+# "value": 1000 } }
+# <- { "return": {} }
+#
+# Since 3.0


4.2 is the earliest this can make it in.


+##
+{ 'command': 'set-iothread-poll-param',
+ 'data': {'iothread_id': 'str', 'name': 'str', 'value': 'int'} }


Our naming convention prefers 'iothread-id'.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org




Re: [PATCH v2] Makefile: Remove generated files when doing 'distclean' (and 'clean')

2019-10-22 Thread Aleksandar Markovic
On Tuesday, October 8, 2019, Thomas Huth  wrote:

> When running "make distclean" we currently leave a lot of generated
> files in the build directory. These should be completely removed.
> Some of the generated files are removed in the "clean" target (which
> is a prerequisite for the "distclean" target), since binary files
> should be removed in this step already.
>
> Signed-off-by: Thomas Huth 
> ---
>  v2:
>  - Remove tests/qemu-iotests/common.env in "distclean", not in "clean"
>  - Improved patch description
>
>  Makefile   |  6 +++---
>  tests/Makefile.include | 12 +++-
>  2 files changed, 14 insertions(+), 4 deletions(-)
>
> Hello, Thomas,

Do you intend to send a new version of this patch?

It looks to me this is a very nice clean up that definitely should go into
4.2, no?

Aleksandat



> diff --git a/Makefile b/Makefile
> index 30f0abfb42..767b1ffb25 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -696,14 +696,14 @@ clean: recurse-clean
> -exec rm {} +
> rm -f $(edk2-decompressed)
> rm -f $(filter-out %.tlb,$(TOOLS)) $(HELPERS-y) TAGS cscope.*
> *.pod *~ */*~
> -   rm -f fsdev/*.pod scsi/*.pod
> +   rm -f fsdev/*.pod scsi/*.pod docs/*.pod docs/*/*.pod
> docs/*/.buildinfo
> rm -f qemu-img-cmds.h
> rm -f ui/shader/*-vert.h ui/shader/*-frag.h
> @# May not be present in generated-files-y
> rm -f trace/generated-tracers-dtrace.dtrace*
> rm -f trace/generated-tracers-dtrace.h*
> rm -f $(foreach f,$(generated-files-y),$(f) $(f)-timestamp)
> -   rm -f qapi-gen-timestamp
> +   rm -f qapi-gen-timestamp vhost-user-input
> rm -rf qga/qapi-generated
> rm -f config-all-devices.mak
>
> @@ -724,7 +724,7 @@ distclean: clean
> rm -f tests/tcg/config-*.mak
> rm -f config-all-devices.mak config-all-disas.mak config.status
> rm -f $(SUBDIR_DEVICES_MAK)
> -   rm -f po/*.mo tests/qemu-iotests/common.env
> +   rm -f po/*.mo
> rm -f roms/seabios/config.mak roms/vgabios/config.mak
> rm -f qemu-doc.info qemu-doc.aux qemu-doc.cp qemu-doc.cps
> rm -f qemu-doc.fn qemu-doc.fns qemu-doc.info qemu-doc.ky
> qemu-doc.kys
> diff --git a/tests/Makefile.include b/tests/Makefile.include
> index 3543451ed3..694f193fb6 100644
> --- a/tests/Makefile.include
> +++ b/tests/Makefile.include
> @@ -1176,11 +1176,21 @@ check: check-block check-qapi-schema check-unit
> check-softfloat check-qtest chec
>  check-clean:
> rm -rf $(check-unit-y) tests/*.o $(QEMU_IOTESTS_HELPERS-y)
> rm -rf $(sort $(foreach target,$(SYSEMU_TARGET_LIST),
> $(check-qtest-$(target)-y)) $(check-qtest-generic-y))
> -   rm -f tests/test-qapi-gen-timestamp
> rm -rf $(TESTS_VENV_DIR) $(TESTS_RESULTS_DIR)
> +   rm -f tests/test-qapi-gen-timestamp tests/qht-bench$(EXESUF) \
> +   tests/fp/fp-test tests/fp/*.out tests/qapi-schema/*.test.*
>
>  clean: check-clean
>
> +check-distclean:
> +   rm -f tests/qemu-iotests/common.env tests/qemu-iotests/check.*
> +   rm -f tests/test-qapi-types*.c tests/test-qapi-visit*.c \
> +   tests/test-qapi-commands*.c tests/test-qapi-events*.c \
> +   tests/test-qapi-emit-events.[ch]
> tests/test-qapi-introspect.c \
> +   tests/include/test-qapi-*.c
> +
> +distclean: check-distclean
> +
>  # Build the help program automatically
>
>  all: $(QEMU_IOTESTS_HELPERS-y)
> --
> 2.18.1
>
>
>


Re: [PATCH v5 5/7] ppc: Reset the interrupt presenter from the CPU reset handler

2019-10-22 Thread Greg Kurz
On Tue, 22 Oct 2019 18:38:10 +0200
Cédric Le Goater  wrote:

> On the sPAPR machine and PowerNV machine, the interrupt presenters are
> created by a machine handler at the core level and are reset
> independently. This is not consistent and it raises issues when it
> comes to handle hot-plugged CPUs. In that case, the presenters are not
> reset. This is less of an issue in XICS, although a zero MFFR could
> be a concern, but in XIVE, the OS CAM line is not set and this breaks
> the presenting algorithm. The current code has workarounds which need
> a global cleanup.
> 
> Extend the sPAPR IRQ backend and the PowerNV Chip class with a new
> cpu_intc_reset() handler called by the CPU reset handler and remove
> the XiveTCTX reset handler which is now redundant.
> 
> Signed-off-by: Cédric Le Goater 
> ---

Reviewed-by: Greg Kurz 

>  include/hw/ppc/pnv.h   |  1 +
>  include/hw/ppc/spapr_irq.h |  2 ++
>  include/hw/ppc/xics.h  |  1 +
>  include/hw/ppc/xive.h  |  1 +
>  hw/intc/spapr_xive.c   |  9 +
>  hw/intc/xics.c |  8 ++--
>  hw/intc/xics_spapr.c   |  7 +++
>  hw/intc/xive.c | 12 +---
>  hw/ppc/pnv.c   | 18 ++
>  hw/ppc/pnv_core.c  |  7 +--
>  hw/ppc/spapr_cpu_core.c|  5 -
>  hw/ppc/spapr_irq.c | 14 ++
>  12 files changed, 65 insertions(+), 20 deletions(-)
> 
> diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
> index 1cdbe55bf86c..2a780e633f23 100644
> --- a/include/hw/ppc/pnv.h
> +++ b/include/hw/ppc/pnv.h
> @@ -111,6 +111,7 @@ typedef struct PnvChipClass {
>  
>  uint32_t (*core_pir)(PnvChip *chip, uint32_t core_id);
>  void (*intc_create)(PnvChip *chip, PowerPCCPU *cpu, Error **errp);
> +void (*intc_reset)(PnvChip *chip, PowerPCCPU *cpu);
>  ISABus *(*isa_create)(PnvChip *chip, Error **errp);
>  void (*dt_populate)(PnvChip *chip, void *fdt);
>  void (*pic_print_info)(PnvChip *chip, Monitor *mon);
> diff --git a/include/hw/ppc/spapr_irq.h b/include/hw/ppc/spapr_irq.h
> index 5e150a667902..09232999b07e 100644
> --- a/include/hw/ppc/spapr_irq.h
> +++ b/include/hw/ppc/spapr_irq.h
> @@ -52,6 +52,7 @@ typedef struct SpaprInterruptControllerClass {
>   */
>  int (*cpu_intc_create)(SpaprInterruptController *intc,
>  PowerPCCPU *cpu, Error **errp);
> +void (*cpu_intc_reset)(SpaprInterruptController *intc, PowerPCCPU *cpu);
>  int (*claim_irq)(SpaprInterruptController *intc, int irq, bool lsi,
>   Error **errp);
>  void (*free_irq)(SpaprInterruptController *intc, int irq);
> @@ -68,6 +69,7 @@ void spapr_irq_update_active_intc(SpaprMachineState *spapr);
>  
>  int spapr_irq_cpu_intc_create(SpaprMachineState *spapr,
>PowerPCCPU *cpu, Error **errp);
> +void spapr_irq_cpu_intc_reset(SpaprMachineState *spapr, PowerPCCPU *cpu);
>  void spapr_irq_print_info(SpaprMachineState *spapr, Monitor *mon);
>  void spapr_irq_dt(SpaprMachineState *spapr, uint32_t nr_servers,
>void *fdt, uint32_t phandle);
> diff --git a/include/hw/ppc/xics.h b/include/hw/ppc/xics.h
> index 1e6a9300eb2b..602173c12250 100644
> --- a/include/hw/ppc/xics.h
> +++ b/include/hw/ppc/xics.h
> @@ -161,6 +161,7 @@ void icp_set_mfrr(ICPState *icp, uint8_t mfrr);
>  uint32_t icp_accept(ICPState *ss);
>  uint32_t icp_ipoll(ICPState *ss, uint32_t *mfrr);
>  void icp_eoi(ICPState *icp, uint32_t xirr);
> +void icp_reset(ICPState *icp);
>  
>  void ics_write_xive(ICSState *ics, int nr, int server,
>  uint8_t priority, uint8_t saved_priority);
> diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
> index fd3319bd3202..99381639f50c 100644
> --- a/include/hw/ppc/xive.h
> +++ b/include/hw/ppc/xive.h
> @@ -415,6 +415,7 @@ uint64_t xive_tctx_tm_read(XiveTCTX *tctx, hwaddr offset, 
> unsigned size);
>  
>  void xive_tctx_pic_print_info(XiveTCTX *tctx, Monitor *mon);
>  Object *xive_tctx_create(Object *cpu, XiveRouter *xrtr, Error **errp);
> +void xive_tctx_reset(XiveTCTX *tctx);
>  
>  static inline uint32_t xive_nvt_cam_line(uint8_t nvt_blk, uint32_t nvt_idx)
>  {
> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
> index ba32d2cc5b0f..20a8d8285f64 100644
> --- a/hw/intc/spapr_xive.c
> +++ b/hw/intc/spapr_xive.c
> @@ -553,6 +553,14 @@ static int 
> spapr_xive_cpu_intc_create(SpaprInterruptController *intc,
>  return 0;
>  }
>  
> +static void spapr_xive_cpu_intc_reset(SpaprInterruptController *intc,
> + PowerPCCPU *cpu)
> +{
> +XiveTCTX *tctx = spapr_cpu_state(cpu)->tctx;
> +
> +xive_tctx_reset(tctx);
> +}
> +
>  static void spapr_xive_set_irq(SpaprInterruptController *intc, int irq, int 
> val)
>  {
>  SpaprXive *xive = SPAPR_XIVE(intc);
> @@ -697,6 +705,7 @@ static void spapr_xive_class_init(ObjectClass *klass, 
> void *data)
>  sicc->activate = spapr_xive_activate;
>  sicc->deactivate = 

Re: [PATCH 00/10] image-fuzzer: Port to Python 3

2019-10-22 Thread Eduardo Habkost
On Thu, Oct 17, 2019 at 06:29:27PM -0300, Eduardo Habkost wrote:
> On Thu, Oct 17, 2019 at 05:11:29PM -0400, John Snow wrote:
> > 
> > 
> > On 10/16/19 3:24 PM, Eduardo Habkost wrote:
> > > This series ports image-fuzzer to Python 3.
> > > 
> > > Eduardo Habkost (10):
> > >   image-fuzzer: Open image files in binary mode
> > >   image-fuzzer: Write bytes instead of string to image file
> > >   image-fuzzer: Explicitly use integer division operator
> > >   image-fuzzer: Use io.StringIO
> > >   image-fuzzer: Use %r for all fiels at Field.__repr__()
> > >   image-fuzzer: Return bytes objects on string fuzzing functions
> > >   image-fuzzer: Use bytes constant for field values
> > >   image-fuzzer: Encode file name and file format to bytes
> > >   image-fuzzer: Run using python3
> > >   image-fuzzer: Use errors parameter of subprocess.Popen()
> > > 
> > >  tests/image-fuzzer/qcow2/__init__.py |  1 -
> > >  tests/image-fuzzer/qcow2/fuzz.py | 54 +-
> > >  tests/image-fuzzer/qcow2/layout.py   | 57 ++--
> > >  tests/image-fuzzer/runner.py | 12 +++---
> > >  4 files changed, 61 insertions(+), 63 deletions(-)
> > > 
> > 
> > When I gave my try at converting this to python3 I noticed that the
> > "except OSError as e" segments used e[1] in a way that was not seemingly
> > supported.
> > 
> > Did you fix that in this series or did I miss it?
> 
> Good catch, I hadn't noticed that.  I didn't fix it.

Separate patch sent for that issue:
https://lore.kernel.org/qemu-devel/20191021214117.18091-1-ehabk...@redhat.com/

-- 
Eduardo




Re: [PATCH V3 2/2] target/i386/kvm: Add Hyper-V direct tlb flush support

2019-10-22 Thread Roman Kagan
On Tue, Oct 22, 2019 at 07:04:11PM +0200, Paolo Bonzini wrote:
> On 16/10/19 15:07, lantianyu1...@gmail.com wrote:

Somehow this patch never got through to me so I'll reply here.

> > From: Tianyu Lan 
> > 
> > Hyper-V direct tlb flush targets KVM on Hyper-V guest.
> > Enable direct TLB flush for its guests meaning that TLB
> > flush hypercalls are handled by Level 0 hypervisor (Hyper-V)
> > bypassing KVM in Level 1. Due to the different ABI for hypercall
> > parameters between Hyper-V and KVM, KVM capabilities should be
> > hidden when enable Hyper-V direct tlb flush otherwise KVM
> > hypercalls may be intercepted by Hyper-V. Add new parameter
> > "hv-direct-tlbflush". Check expose_kvm and Hyper-V tlb flush
> > capability status before enabling the feature.
> > 
> > Signed-off-by: Tianyu Lan 
> > ---
> > Change sicne v2:
> >- Update new feature description and name.
> >- Change failure print log.
> > 
> > Change since v1:
> >- Add direct tlb flush's Hyper-V property and use
> >hv_cpuid_check_and_set() to check the dependency of tlbflush
> >feature.
> >- Make new feature work with Hyper-V passthrough mode.
> > ---
> >  docs/hyperv.txt   | 10 ++
> >  target/i386/cpu.c |  2 ++
> >  target/i386/cpu.h |  1 +
> >  target/i386/kvm.c | 24 
> >  4 files changed, 37 insertions(+)
> > 
> > diff --git a/docs/hyperv.txt b/docs/hyperv.txt
> > index 8fdf25c829..140a5c7e44 100644
> > --- a/docs/hyperv.txt
> > +++ b/docs/hyperv.txt
> > @@ -184,6 +184,16 @@ enabled.
> >  
> >  Requires: hv-vpindex, hv-synic, hv-time, hv-stimer
> >  
> > +3.18. hv-direct-tlbflush
> > +===
> > +Enable direct TLB flush for KVM when it is running as a nested
> > +hypervisor on top Hyper-V. When enabled, TLB flush hypercalls from L2
> > +guests are being passed through to L0 (Hyper-V) for handling. Due to ABI
> > +differences between Hyper-V and KVM hypercalls, L2 guests will not be
> > +able to issue KVM hypercalls (as those could be mishanled by L0
> > +Hyper-V), this requires KVM hypervisor signature to be hidden.
> > +
> > +Requires: hv-tlbflush, -kvm
> >  
> >  4. Development features
> >  
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > index 44f1bbdcac..7bc7fee512 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -6156,6 +6156,8 @@ static Property x86_cpu_properties[] = {
> >HYPERV_FEAT_IPI, 0),
> >  DEFINE_PROP_BIT64("hv-stimer-direct", X86CPU, hyperv_features,
> >HYPERV_FEAT_STIMER_DIRECT, 0),
> > +DEFINE_PROP_BIT64("hv-direct-tlbflush", X86CPU, hyperv_features,
> > +  HYPERV_FEAT_DIRECT_TLBFLUSH, 0),
> >  DEFINE_PROP_BOOL("hv-passthrough", X86CPU, hyperv_passthrough, false),
> >  
> >  DEFINE_PROP_BOOL("check", X86CPU, check_cpuid, true),
> > diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> > index eaa5395aa5..3cb105f7d6 100644
> > --- a/target/i386/cpu.h
> > +++ b/target/i386/cpu.h
> > @@ -907,6 +907,7 @@ typedef uint64_t FeatureWordArray[FEATURE_WORDS];
> >  #define HYPERV_FEAT_EVMCS   12
> >  #define HYPERV_FEAT_IPI 13
> >  #define HYPERV_FEAT_STIMER_DIRECT   14
> > +#define HYPERV_FEAT_DIRECT_TLBFLUSH 15
> >  
> >  #ifndef HYPERV_SPINLOCK_NEVER_RETRY
> >  #define HYPERV_SPINLOCK_NEVER_RETRY 0x
> > diff --git a/target/i386/kvm.c b/target/i386/kvm.c
> > index 11b9c854b5..043b66ab22 100644
> > --- a/target/i386/kvm.c
> > +++ b/target/i386/kvm.c
> > @@ -900,6 +900,10 @@ static struct {
> >  },
> >  .dependencies = BIT(HYPERV_FEAT_STIMER)
> >  },
> > +[HYPERV_FEAT_DIRECT_TLBFLUSH] = {
> > +.desc = "direct paravirtualized TLB flush (hv-direct-tlbflush)",
> > +.dependencies = BIT(HYPERV_FEAT_TLBFLUSH)
> > +},
> >  };
> >  
> >  static struct kvm_cpuid2 *try_get_hv_cpuid(CPUState *cs, int max)
> > @@ -1224,6 +1228,7 @@ static int hyperv_handle_properties(CPUState *cs,
> >  r |= hv_cpuid_check_and_set(cs, cpuid, HYPERV_FEAT_EVMCS);
> >  r |= hv_cpuid_check_and_set(cs, cpuid, HYPERV_FEAT_IPI);
> >  r |= hv_cpuid_check_and_set(cs, cpuid, HYPERV_FEAT_STIMER_DIRECT);
> > +r |= hv_cpuid_check_and_set(cs, cpuid, HYPERV_FEAT_DIRECT_TLBFLUSH);

AFAICS this will turn HYPERV_FEAT_DIRECT_TLBFLUSH on if
hyperv_passthrough is on, so ...

> >  
> >  /* Additional dependencies not covered by kvm_hyperv_properties[] */
> >  if (hyperv_feat_enabled(cpu, HYPERV_FEAT_SYNIC) &&
> > @@ -1243,6 +1248,25 @@ static int hyperv_handle_properties(CPUState *cs,
> >  goto free;
> >  }
> >  
> > +if (hyperv_feat_enabled(cpu, HYPERV_FEAT_DIRECT_TLBFLUSH) ||
> > +cpu->hyperv_passthrough) {

... the test for ->hyperv_passthrough is redundant, and ...

> > +if (!cpu->expose_kvm) {
> > +r = kvm_vcpu_enable_cap(cs, KVM_CAP_HYPERV_DIRECT_TLBFLUSH, 0, 
> > 0);
> > +

Re: [PATCH] aspeed: Add an AST2600 eval board

2019-10-22 Thread Cédric Le Goater
On 22/10/2019 19:20, Peter Maydell wrote:
> On Tue, 22 Oct 2019 at 18:16, Cédric Le Goater  wrote:
>> Is it time for me to install an OSX system for dev and tests or is there
>> a way to reproduce the issue ? no errors spotted in valgrind.
> 
> I dunno. You could have a look to see if you can repro
> it with the travis builds. I would investigate but I
> don't have time this week given impending softfreeze
> and KVM Forum next week.

Sure. I will reinstall a Mac I have under OSX.

C. 



[PATCH v1 18/19] iotests: Enable more tests in the 'auto' group to improve test coverage

2019-10-22 Thread Alex Bennée
From: Thomas Huth 

According to Kevin, tests 030, 040 and 041 are among the most valuable
tests that we have, so we should always run them if possible, even if
they take a little bit longer.

According to Max, it would be good to have a test for iothreads and
migration. 127 and 256 seem to be good candidates for iothreads. For
migration, let's enable 091, 181, and 203 (which also tests iothreads).

Reviewed-by: Max Reitz 
Signed-off-by: Thomas Huth 
Message-Id: <20191022072135.11188-6-th...@redhat.com>
---
 tests/qemu-iotests/group | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index a73df279e5e..33b499ed410 100644
--- a/tests/qemu-iotests/group
+++ b/tests/qemu-iotests/group
@@ -51,7 +51,7 @@
 027 rw auto quick
 028 rw backing quick
 029 rw auto quick
-030 rw backing
+030 rw auto backing
 031 rw auto quick
 032 rw auto quick
 033 rw auto quick
@@ -61,8 +61,8 @@
 037 rw auto backing quick
 038 rw auto backing quick
 039 rw auto quick
-040 rw
-041 rw backing
+040 rw auto
+041 rw auto backing
 042 rw auto quick
 043 rw auto backing
 044 rw
@@ -112,7 +112,7 @@
 088 rw quick
 089 rw auto quick
 090 rw auto quick
-091 rw migration
+091 rw auto migration
 092 rw quick
 093 throttle
 094 rw quick
@@ -148,7 +148,7 @@
 124 rw backing
 125 rw
 126 rw auto backing
-127 rw backing quick
+127 rw auto backing quick
 128 rw quick
 129 rw quick
 130 rw auto quick
@@ -197,7 +197,7 @@
 177 rw auto quick
 178 img
 179 rw auto quick
-181 rw migration
+181 rw auto migration
 182 rw quick
 183 rw migration
 184 rw auto quick
@@ -218,7 +218,7 @@
 200 rw
 201 rw migration
 202 rw quick
-203 rw migration
+203 rw auto migration
 204 rw quick
 205 rw quick
 206 rw
@@ -270,7 +270,7 @@
 253 rw quick
 254 rw backing quick
 255 rw quick
-256 rw quick
+256 rw auto quick
 257 rw
 258 rw quick
 260 rw quick
-- 
2.20.1




[PATCH v1 17/19] iotests: Skip "make check-block" if QEMU does not support virtio-blk

2019-10-22 Thread Alex Bennée
From: Thomas Huth 

The next patch is going to add some python-based tests to the "auto"
group, and these tests require virtio-blk to work properly. Running
iotests without virtio-blk likely does not make too much sense anyway,
so instead of adding a check for the availability of virtio-blk to each
and every test (which does not sound very appealing), let's rather add
a check for this at the top level in the check-block.sh script instead
(so that it is possible to run "make check" without the "check-block"
part for qemu-system-tricore for example).

Reviewed-by: Max Reitz 
Signed-off-by: Thomas Huth 
Message-Id: <20191022072135.11188-5-th...@redhat.com>
---
 tests/check-block.sh | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/tests/check-block.sh b/tests/check-block.sh
index 679aedec50c..e9e2978818a 100755
--- a/tests/check-block.sh
+++ b/tests/check-block.sh
@@ -26,10 +26,24 @@ if grep -q "CFLAGS.*-fsanitize" config-host.mak 2>/dev/null 
; then
 exit 0
 fi
 
-if [ -z "$(find . -name 'qemu-system-*' -print)" ]; then
+if [ -n "$QEMU_PROG" ]; then
+qemu_prog="$QEMU_PROG"
+else
+for binary in *-softmmu/qemu-system-* ; do
+if [ -x "$binary" ]; then
+qemu_prog="$binary"
+break
+fi
+done
+fi
+if [ -z "$qemu_prog" ]; then
 echo "No qemu-system binary available ==> Not running the qemu-iotests."
 exit 0
 fi
+if ! "$qemu_prog" -M none -device help | grep -q virtio-blk >/dev/null 2>&1 ; 
then
+echo "$qemu_prog does not support virtio-blk ==> Not running the 
qemu-iotests."
+exit 0
+fi
 
 if ! command -v bash >/dev/null 2>&1 ; then
 echo "bash not available ==> Not running the qemu-iotests."
-- 
2.20.1




[PATCH v1 19/19] iotests: Remove 130 from the "auto" group

2019-10-22 Thread Alex Bennée
From: Thomas Huth 

Peter hit a "Could not open 'TEST_DIR/t.IMGFMT': Failed to get shared
'write' lock - Is another process using the image [TEST_DIR/t.IMGFMT]?"
error with 130 already twice. Looks like this test is a little bit
shaky, so for the time being, let's disable it from the "auto" group so
that it does not gate the pull requests.

Reviewed-by: John Snow 
Signed-off-by: Thomas Huth 
Message-Id: <20191022072135.11188-7-th...@redhat.com>
---
 tests/qemu-iotests/group | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index 33b499ed410..4596497bced 100644
--- a/tests/qemu-iotests/group
+++ b/tests/qemu-iotests/group
@@ -151,7 +151,7 @@
 127 rw auto backing quick
 128 rw quick
 129 rw quick
-130 rw auto quick
+130 rw quick
 131 rw quick
 132 rw quick
 133 auto quick
-- 
2.20.1




[PATCH v1 12/19] tests/vm/netbsd: Disable IPv6

2019-10-22 Thread Alex Bennée
From: Eduardo Habkost 

Workaround for issues when the host has no IPv6 connectivity.

Signed-off-by: Eduardo Habkost 
Reviewed-by: Thomas Huth 
Message-Id: <20191018181705.17957-4-ehabk...@redhat.com>
Signed-off-by: Alex Bennée 
---
 tests/vm/netbsd | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/tests/vm/netbsd b/tests/vm/netbsd
index 9558a672efa..d4dd1929f2d 100755
--- a/tests/vm/netbsd
+++ b/tests/vm/netbsd
@@ -63,6 +63,13 @@ class NetBSDVM(basevm.BaseVM):
 """
 poweroff = "/sbin/poweroff"
 
+# Workaround for NetBSD + IPv6 + slirp issues.
+# NetBSD seems to ignore the ICMPv6 Destination Unreachable
+# messages generated by slirp.  When the host has no IPv6
+# connectivity, this causes every connection to ftp.NetBSD.org
+# take more than a minute to be established.
+ipv6 = False
+
 def build_image(self, img):
 cimg = self._download_with_cache(self.link, sha512sum=self.csum)
 img_tmp = img + ".tmp"
-- 
2.20.1




[PATCH v1 16/19] iotests: Test 183 does not work on macOS and OpenBSD

2019-10-22 Thread Alex Bennée
From: Thomas Huth 

In the long term, we might want to add test 183 to the "auto" group
(but it still fails occasionally, so we cannot do that yet). However,
when running 183 in Cirrus-CI on macOS, or with our vm-build-openbsd
target, it currently always fails with an "Timeout waiting for return
on handle 0" error.

Let's mark it as supported only on systems where the test is working
fine (i.e. Linux, FreeBSD and NetBSD).

Signed-off-by: Thomas Huth 
Message-Id: <20191022072135.11188-4-th...@redhat.com>
---
 tests/qemu-iotests/183 | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/qemu-iotests/183 b/tests/qemu-iotests/183
index 04fb344d08e..ab5a7089549 100755
--- a/tests/qemu-iotests/183
+++ b/tests/qemu-iotests/183
@@ -42,6 +42,7 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
 . ./common.filter
 . ./common.qemu
 
+_supported_os Linux FreeBSD NetBSD
 _supported_fmt qcow2 raw qed quorum
 _supported_proto file
 
-- 
2.20.1




[PATCH v1 08/19] travis.yml: bump Xcode 10 to latest dot release

2019-10-22 Thread Alex Bennée
As 10.3 is available lets use it. I don't know what Apple's
deprecation policy is for Xcode because it requires an AppleID to find
out.

Signed-off-by: Alex Bennée 
---
 .travis.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index f2b679fe701..da6a2063fca 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -247,7 +247,7 @@ matrix:
 - env:
 - 
CONFIG="--target-list=i386-softmmu,ppc-softmmu,ppc64-softmmu,m68k-softmmu,x86_64-softmmu"
   os: osx
-  osx_image: xcode10.2
+  osx_image: xcode10.3
   compiler: clang
 
 
-- 
2.20.1




[PATCH v1 10/19] tests/vm: netbsd autoinstall, using serial console

2019-10-22 Thread Alex Bennée
From: Gerd Hoffmann 

Instead of fetching the prebuilt image from patchew download the install
iso and prepare the image locally.  Install to disk, using the serial
console.  Create qemu user, configure ssh login.  Install packages
needed for qemu builds.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Kamil Rytarowski 
Tested-by: Thomas Huth 
[ehabkost: rebased to latest qemu.git master]
Signed-off-by: Eduardo Habkost 
Message-Id: <20191018181705.17957-2-ehabk...@redhat.com>
[AJB: add sha512sum, rm path check]
Signed-off-by: Alex Bennée 
---
 tests/vm/basevm.py |  10 ++-
 tests/vm/netbsd| 188 ++---
 2 files changed, 186 insertions(+), 12 deletions(-)

diff --git a/tests/vm/basevm.py b/tests/vm/basevm.py
index b5d1479bee9..4921e47f9f2 100755
--- a/tests/vm/basevm.py
+++ b/tests/vm/basevm.py
@@ -92,19 +92,25 @@ class BaseVM(object):
 logging.info("KVM not available, not using -enable-kvm")
 self._data_args = []
 
-def _download_with_cache(self, url, sha256sum=None):
+def _download_with_cache(self, url, sha256sum=None, sha512sum=None):
 def check_sha256sum(fname):
 if not sha256sum:
 return True
 checksum = subprocess.check_output(["sha256sum", fname]).split()[0]
 return sha256sum == checksum.decode("utf-8")
 
+def check_sha512sum(fname):
+if not sha512sum:
+return True
+checksum = subprocess.check_output(["sha512sum", fname]).split()[0]
+return sha512sum == checksum.decode("utf-8")
+
 cache_dir = os.path.expanduser("~/.cache/qemu-vm/download")
 if not os.path.exists(cache_dir):
 os.makedirs(cache_dir)
 fname = os.path.join(cache_dir,
  hashlib.sha1(url.encode("utf-8")).hexdigest())
-if os.path.exists(fname) and check_sha256sum(fname):
+if os.path.exists(fname) and check_sha256sum(fname) and 
check_sha512sum(fname):
 return fname
 logging.debug("Downloading %s to %s...", url, fname)
 subprocess.check_call(["wget", "-c", url, "-O", fname + ".download"],
diff --git a/tests/vm/netbsd b/tests/vm/netbsd
index ee9eaeab504..9558a672efa 100755
--- a/tests/vm/netbsd
+++ b/tests/vm/netbsd
@@ -2,10 +2,11 @@
 #
 # NetBSD VM image
 #
-# Copyright 2017 Red Hat Inc.
+# Copyright 2017-2019 Red Hat Inc.
 #
 # Authors:
 #  Fam Zheng 
+#  Gerd Hoffmann 
 #
 # This code is licensed under the GPL version 2 or later.  See
 # the COPYING file in the top-level directory.
@@ -13,30 +14,197 @@
 
 import os
 import sys
+import time
 import subprocess
 import basevm
 
 class NetBSDVM(basevm.BaseVM):
 name = "netbsd"
 arch = "x86_64"
+
+link = 
"https://cdn.netbsd.org/pub/NetBSD/NetBSD-8.1/images/NetBSD-8.1-amd64.iso;
+csum = 
"718f275b7e0879599bdac95630c5e3f2184700032fdb6cdebf3bdd63687898c48ff3f08f57b89f4437a86cdd8ea07c01a39d432dbb37e1e4b008f4985f98da3f"
+size = "20G"
+pkgs = [
+# tools
+"git-base",
+"pkgconf",
+"xz",
+"python37",
+
+# gnu tools
+"bash",
+"gmake",
+"gsed",
+"flex", "bison",
+
+# libs: crypto
+"gnutls",
+
+# libs: images
+"jpeg",
+"png",
+
+   # libs: ui
+"SDL2",
+"gtk3+",
+"libxkbcommon",
+]
+
 BUILD_SCRIPT = """
 set -e;
-rm -rf /var/tmp/qemu-test.*
-cd $(mktemp -d /var/tmp/qemu-test.XX);
+rm -rf /home/qemu/qemu-test.*
+cd $(mktemp -d /home/qemu/qemu-test.XX);
+mkdir src build; cd src;
 tar -xf /dev/rld1a;
-./configure --python=python2.7 {configure_opts};
+cd ../build
+../src/configure --python=python3.7 --disable-opengl {configure_opts};
 gmake --output-sync -j{jobs} {target} {verbose};
 """
+poweroff = "/sbin/poweroff"
 
 def build_image(self, img):
-cimg = 
self._download_with_cache("http://download.patchew.org/netbsd-7.1-amd64.img.xz;,
- 
sha256sum='b633d565b0eac3d02015cd0c81440bd8a7a8df8512615ac1ee05d318be015732')
-img_tmp_xz = img + ".tmp.xz"
+cimg = self._download_with_cache(self.link, sha512sum=self.csum)
 img_tmp = img + ".tmp"
-sys.stderr.write("Extracting the image...\n")
-subprocess.check_call(["ln", "-f", cimg, img_tmp_xz])
-subprocess.check_call(["xz", "--keep", "-dvf", img_tmp_xz])
+iso = img + ".install.iso"
+
+self.print_step("Preparing iso and disk image")
+subprocess.check_call(["ln", "-f", cimg, iso])
+subprocess.check_call(["qemu-img", "create", "-f", "qcow2",
+   img_tmp, self.size])
+
+self.print_step("Booting installer")
+self.boot(img_tmp, extra_args = [
+"-bios", "pc-bios/bios-256k.bin",
+"-machine", "graphics=off",
+  

[PATCH v1 15/19] iotests: Test 041 only works on certain systems

2019-10-22 Thread Alex Bennée
From: Thomas Huth 

041 works fine on Linux, FreeBSD, NetBSD and OpenBSD, but fails on macOS.
Let's mark it as only supported on the systems where we know that it is
working fine.

Signed-off-by: Thomas Huth 
Message-Id: <20191022072135.11188-3-th...@redhat.com>
---
 tests/qemu-iotests/041 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/qemu-iotests/041 b/tests/qemu-iotests/041
index 8568426311e..0326888c980 100755
--- a/tests/qemu-iotests/041
+++ b/tests/qemu-iotests/041
@@ -1123,4 +1123,5 @@ class TestOrphanedSource(iotests.QMPTestCase):
 
 if __name__ == '__main__':
 iotests.main(supported_fmts=['qcow2', 'qed'],
- supported_protocols=['file'])
+ supported_protocols=['file'],
+ supported_platforms=['linux', 'freebsd', 'netbsd', 'openbsd'])
-- 
2.20.1




[PATCH v1 09/19] cirrus.yml: add latest Xcode build target

2019-10-22 Thread Alex Bennée
CirrusCI provides a mojave-xcode alias for the latest Xcode available.
Let's use it to make sure we track the latest releases.

Signed-off-by: Alex Bennée 
---
 .cirrus.yml | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/.cirrus.yml b/.cirrus.yml
index 4b042c0e12c..59146a89c83 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -26,3 +26,14 @@ macos_task:
 - ./configure --python=/usr/local/bin/python3 
--target-list=${MACOS_ARCHES} || { cat config.log; exit 1; }
 - gmake -j$(sysctl -n hw.ncpu)
 - gmake check -j$(sysctl -n hw.ncpu)
+
+macos_xcode_task:
+  osx_instance:
+# this is an alias for the latest Xcode
+image: mojave-xcode
+  install_script:
+- brew install pkg-config gnu-sed glib pixman make sdl2
+  script:
+- ./configure --cc=clang --target-list=${MACOS_ARCHES} || { cat 
config.log; exit 1; }
+- gmake -j$(sysctl -n hw.ncpu)
+- gmake check -j$(sysctl -n hw.ncpu)
-- 
2.20.1




[PATCH v1 13/19] travis.yml: cache the clang sanitizer build

2019-10-22 Thread Alex Bennée
Hopefully we'll see the same benefits as the other builds.

Signed-off-by: Alex Bennée 
---
 .travis.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.travis.yml b/.travis.yml
index da6a2063fca..c43597f1331 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -189,6 +189,7 @@ matrix:
 
 - env:
 - CONFIG="--target-list=${MAIN_SOFTMMU_TARGETS} "
+- CACHE_NAME="${TRAVIS_BRANCH}-linux-clang-sanitize"
   compiler: clang
   before_script:
 - ./configure ${CONFIG} --extra-cflags="-fsanitize=undefined -Werror" 
|| { cat config.log && exit 1; }
-- 
2.20.1




[PATCH v1 14/19] iotests: remove 'linux' from default supported platforms

2019-10-22 Thread Alex Bennée
From: John Snow 

verify_platform will check an explicit whitelist and blacklist instead.
The default will now be assumed to be allowed to run anywhere.

For tests that do not specify their platforms explicitly, this has the effect of
enabling these tests on non-linux platforms. For tests that always specified
linux explicitly, there is no change.

For Python tests on FreeBSD at least; only seven python tests fail:
045 147 149 169 194 199 211

045 and 149 appear to be misconfigurations,
147 and 194 are the AF_UNIX path too long error,
169 and 199 are bitmap migration bugs, and
211 is a bug that shows up on Linux platforms, too.

This is at least good evidence that these tests are not Linux-only. If
they aren't suitable for other platforms, they should be disabled on a
per-platform basis as appropriate.

Therefore, let's switch these on and deal with the failures.

Reviewed-by: Max Reitz 
Signed-off-by: John Snow 
Message-Id: <20191022072135.11188-2-th...@redhat.com>
---
 tests/qemu-iotests/iotests.py | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index 3a8f378f90d..75e64ef85be 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -869,9 +869,14 @@ def verify_protocol(supported=[], unsupported=[]):
 if not_sup or (imgproto in unsupported):
 notrun('not suitable for this protocol: %s' % imgproto)
 
-def verify_platform(supported_oses=['linux']):
-if True not in [sys.platform.startswith(x) for x in supported_oses]:
-notrun('not suitable for this OS: %s' % sys.platform)
+def verify_platform(supported=None, unsupported=None):
+if unsupported is not None:
+if any((sys.platform.startswith(x) for x in unsupported)):
+notrun('not suitable for this OS: %s' % sys.platform)
+
+if supported is not None:
+if not any((sys.platform.startswith(x) for x in supported)):
+notrun('not suitable for this OS: %s' % sys.platform)
 
 def verify_cache_mode(supported_cache_modes=[]):
 if supported_cache_modes and (cachemode not in supported_cache_modes):
@@ -933,7 +938,8 @@ def execute_unittest(output, verbosity, debug):
 r'Ran \1 tests', output.getvalue()))
 
 def execute_test(test_function=None,
- supported_fmts=[], supported_oses=['linux'],
+ supported_fmts=[],
+ supported_platforms=None,
  supported_cache_modes=[], unsupported_fmts=[],
  supported_protocols=[], unsupported_protocols=[]):
 """Run either unittest or script-style tests."""
@@ -950,7 +956,7 @@ def execute_test(test_function=None,
 verbosity = 1
 verify_image_format(supported_fmts, unsupported_fmts)
 verify_protocol(supported_protocols, unsupported_protocols)
-verify_platform(supported_oses)
+verify_platform(supported=supported_platforms)
 verify_cache_mode(supported_cache_modes)
 
 if debug:
-- 
2.20.1




[PATCH v1 11/19] tests/vm: Let subclasses disable IPv6

2019-10-22 Thread Alex Bennée
From: Eduardo Habkost 

The mechanism will be used to work around issues related to IPv6
on the netbsd image builder.

Signed-off-by: Eduardo Habkost 
Reviewed-by: Thomas Huth 
Reviewed-by: Philippe Mathieu-Daudé 
Message-Id: <20191018181705.17957-3-ehabk...@redhat.com>
Signed-off-by: Alex Bennée 
---
 tests/vm/basevm.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tests/vm/basevm.py b/tests/vm/basevm.py
index 4921e47f9f2..59bd1d31fbe 100755
--- a/tests/vm/basevm.py
+++ b/tests/vm/basevm.py
@@ -57,6 +57,8 @@ class BaseVM(object):
 arch = "#arch"
 # command to halt the guest, can be overridden by subclasses
 poweroff = "poweroff"
+# enable IPv6 networking
+ipv6 = True
 def __init__(self, debug=False, vcpus=None):
 self._guest = None
 self._tmpdir = os.path.realpath(tempfile.mkdtemp(prefix="vm-test-",
@@ -81,7 +83,8 @@ class BaseVM(object):
 self._args = [ \
 "-nodefaults", "-m", "4G",
 "-cpu", "max",
-"-netdev", "user,id=vnet,hostfwd=:127.0.0.1:0-:22",
+"-netdev", "user,id=vnet,hostfwd=:127.0.0.1:0-:22" +
+   (",ipv6=no" if not self.ipv6 else ""),
 "-device", "virtio-net-pci,netdev=vnet",
 "-vnc", "127.0.0.1:0,to=20"]
 if vcpus and vcpus > 1:
-- 
2.20.1




[PATCH v1 05/19] travis.yml: Fix the ccache lines

2019-10-22 Thread Alex Bennée
From: Thomas Huth 

The "command -v ccache && ccache ..." likely were supposed to test
the availability of ccache before running the program. But this
shell construct causes Travis to abort if ccache is not available.
Use an if-statement instead to fix this problem.

Signed-off-by: Thomas Huth 
Message-Id: <20191009170701.14756-5-th...@redhat.com>
---
 .travis.yml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index e65e53f3d7e..7e0d4ad2b31 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -91,13 +91,13 @@ git:
 
 before_script:
   - if [ "$TRAVIS_OS_NAME" == "osx" ] ; then export 
PATH="/usr/local/opt/ccache/libexec:$PATH" ; fi
-  - command -v ccache && ccache --zero-stats
+  - if command -v ccache ; then ccache --zero-stats ; fi
   - mkdir -p ${BUILD_DIR} && cd ${BUILD_DIR}
   - ${SRC_DIR}/configure ${BASE_CONFIG} ${CONFIG} || { cat config.log && exit 
1; }
 script:
   - make -j3 && travis_retry ${TEST_CMD}
 after_script:
-  - command -v ccache && ccache --show-stats
+  - if command -v ccache ; then ccache --show-stats ; fi
 
 
 matrix:
-- 
2.20.1




[PATCH v1 04/19] travis.yml: Use newer version of libgnutls and libpng

2019-10-22 Thread Alex Bennée
From: Thomas Huth 

libgnutls-dev and libpng12-dev are not available in newer versions
of Ubuntu anymore, so installing these packages fails e.g. in the
new arm64 containers on Travis. Let's use newer versions of these
packages by default instead. (The old versions still get tested in
the "gcc-9" build).

Signed-off-by: Thomas Huth 
Message-Id: <20191009170701.14756-4-th...@redhat.com>
---
 .travis.yml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index b446e04e8ae..e65e53f3d7e 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -29,7 +29,7 @@ addons:
   - libcap-dev
   - libcap-ng-dev
   - libgcc-4.8-dev
-  - libgnutls-dev
+  - libgnutls28-dev
   - libgtk-3-dev
   - libiscsi-dev
   - liblttng-ust-dev
@@ -37,7 +37,7 @@ addons:
   - libnfs-dev
   - libnss3-dev
   - libpixman-1-dev
-  - libpng12-dev
+  - libpng-dev
   - librados-dev
   - libsdl2-dev
   - libsdl2-image-dev
-- 
2.20.1




[PATCH v1 06/19] travis.yml: Test the release tarball

2019-10-22 Thread Alex Bennée
From: Philippe Mathieu-Daudé 

Add a job to generate the release tarball and build/install few
QEMU targets from it.

Ideally we should build the 'efi' target from the 'roms' directory,
but it is too time consuming.

This job is only triggered when a tag starting with 'v' is pushed,
which is the case with release candidate tags.

Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20191007160450.3619-1-phi...@redhat.com>
Signed-off-by: Alex Bennée 
---
 .travis.yml | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/.travis.yml b/.travis.yml
index 7e0d4ad2b31..f2b679fe701 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -343,3 +343,26 @@ matrix:
 - 
CONFIG="--target-list=xtensa-softmmu,arm-softmmu,aarch64-softmmu,alpha-softmmu"
 - TEST_CMD="make -j3 check-tcg V=1"
 - CACHE_NAME="${TRAVIS_BRANCH}-linux-gcc-default"
+
+
+# Release builds
+# The make-release script expect a QEMU version, so our tag must start 
with a 'v'.
+# This is the case when release candidate tags are created.
+- if: tag IS present AND tag =~ /^v\d+\.\d+(\.\d+)?(-\S*)?$/
+  env:
+# We want to build from the release tarball
+- BUILD_DIR="release/build/dir" SRC_DIR="../../.."
+- BASE_CONFIG="--prefix=$PWD/dist"
+- 
CONFIG="--target-list=x86_64-softmmu,aarch64-softmmu,armeb-linux-user,ppc-linux-user"
+- TEST_CMD="make install -j3"
+- QEMU_VERSION="${TRAVIS_TAG:1}"
+- CACHE_NAME="${TRAVIS_BRANCH}-linux-gcc-default"
+  before_script:
+- command -v ccache && ccache --zero-stats
+- mkdir -p ${BUILD_DIR} && cd ${BUILD_DIR}
+  script:
+- make -C ${SRC_DIR} qemu-${QEMU_VERSION}.tar.bz2
+- ls -l ${SRC_DIR}/qemu-${QEMU_VERSION}.tar.bz2
+- tar -xf ${SRC_DIR}/qemu-${QEMU_VERSION}.tar.bz2 && cd 
qemu-${QEMU_VERSION}
+- ./configure ${BASE_CONFIG} ${CONFIG} || { cat config.log && exit 1; }
+- make install
-- 
2.20.1




[PATCH for 4.2 v1 00/19] testing/next before softfreeze

2019-10-22 Thread Alex Bennée
Hi,

This is the current status of testing/next. I dropped the Travis arm64
build due to stability concerns. As far as I can tell Thomas' latest
iotest updates are working fine. If there are any other patches worth
considering before the softfreeze now is the time to shout.

Alex Bennée (5):
  travis.yml: reduce scope of the --enable-debug build
  cirrus.yml: reduce scope of MacOS build
  travis.yml: bump Xcode 10 to latest dot release
  cirrus.yml: add latest Xcode build target
  travis.yml: cache the clang sanitizer build

Eduardo Habkost (2):
  tests/vm: Let subclasses disable IPv6
  tests/vm/netbsd: Disable IPv6

Gerd Hoffmann (1):
  tests/vm: netbsd autoinstall, using serial console

John Snow (1):
  iotests: remove 'linux' from default supported platforms

Philippe Mathieu-Daudé (1):
  travis.yml: Test the release tarball

Thomas Huth (9):
  travis.yml: Add libvdeplug-dev to compile-test net/vde.c
  travis.yml: Use libsdl2 instead of libsdl1.2, and install
libsdl2-image
  travis.yml: Use newer version of libgnutls and libpng
  travis.yml: Fix the ccache lines
  iotests: Test 041 only works on certain systems
  iotests: Test 183 does not work on macOS and OpenBSD
  iotests: Skip "make check-block" if QEMU does not support virtio-blk
  iotests: Enable more tests in the 'auto' group to improve test
coverage
  iotests: Remove 130 from the "auto" group

 .cirrus.yml   |  14 ++-
 .travis.yml   |  46 ++--
 tests/check-block.sh  |  16 ++-
 tests/qemu-iotests/041|   3 +-
 tests/qemu-iotests/183|   1 +
 tests/qemu-iotests/group  |  18 ++--
 tests/qemu-iotests/iotests.py |  16 ++-
 tests/vm/basevm.py|  15 ++-
 tests/vm/netbsd   | 195 --
 9 files changed, 285 insertions(+), 39 deletions(-)

-- 
2.20.1




[PATCH v1 07/19] cirrus.yml: reduce scope of MacOS build

2019-10-22 Thread Alex Bennée
The MacOS build can time out on Cirrus running to almost an hour.
Reduce the scope to the historical MacOS architectures much the same
way we do on Travis.

Signed-off-by: Alex Bennée 
---
 .cirrus.yml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/.cirrus.yml b/.cirrus.yml
index 8326a3a4b16..4b042c0e12c 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -1,5 +1,6 @@
 env:
   CIRRUS_CLONE_DEPTH: 1
+  MACOS_ARCHES: 
i386-softmmu,ppc-softmmu,ppc64-softmmu,m68k-softmmu,x86_64-softmmu
 
 freebsd_12_task:
   freebsd_instance:
@@ -22,6 +23,6 @@ macos_task:
   install_script:
 - brew install pkg-config python gnu-sed glib pixman make sdl2
   script:
-- ./configure --python=/usr/local/bin/python3 || { cat config.log; exit 1; 
}
+- ./configure --python=/usr/local/bin/python3 
--target-list=${MACOS_ARCHES} || { cat config.log; exit 1; }
 - gmake -j$(sysctl -n hw.ncpu)
 - gmake check -j$(sysctl -n hw.ncpu)
-- 
2.20.1




[PATCH v1 02/19] travis.yml: Add libvdeplug-dev to compile-test net/vde.c

2019-10-22 Thread Alex Bennée
From: Thomas Huth 

This library is needed to compile the VDE network backend.

Signed-off-by: Thomas Huth 
Message-Id: <20191009170701.14756-2-th...@redhat.com>
---
 .travis.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.travis.yml b/.travis.yml
index 7d90b87540f..7be2a9949f5 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -46,6 +46,7 @@ addons:
   - libssh-dev
   - liburcu-dev
   - libusb-1.0-0-dev
+  - libvdeplug-dev
   - libvte-2.91-dev
   - sparse
   - uuid-dev
-- 
2.20.1




[PATCH v1 01/19] travis.yml: reduce scope of the --enable-debug build

2019-10-22 Thread Alex Bennée
Adding debug makes things run a bit slower so lets not hammer all the
targets.

Signed-off-by: Alex Bennée 
Reviewed-by: Philippe Mathieu-Daudé 
---
v2
  - drop superfluous --enable-debug-tcg in configure string
---
 .travis.yml | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index d0b9e099b9c..7d90b87540f 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -124,12 +124,13 @@ matrix:
 - CACHE_NAME="${TRAVIS_BRANCH}-linux-gcc-default"
 
 
+# --enable-debug implies --enable-debug-tcg, also runs quite a bit slower
 - env:
-- CONFIG="--enable-debug --enable-debug-tcg --disable-user"
+- CONFIG="--enable-debug --target-list=${MAIN_SOFTMMU_TARGETS}"
 - CACHE_NAME="${TRAVIS_BRANCH}-linux-gcc-debug"
 
 
-# TCG debug can be run just on it's own and is mostly agnostic to 
user/softmmu distinctions
+# TCG debug can be run just on its own and is mostly agnostic to 
user/softmmu distinctions
 - env:
 - CONFIG="--enable-debug-tcg --disable-system"
 - CACHE_NAME="${TRAVIS_BRANCH}-linux-gcc-debug"
-- 
2.20.1




[PATCH v1 03/19] travis.yml: Use libsdl2 instead of libsdl1.2, and install libsdl2-image

2019-10-22 Thread Alex Bennée
From: Thomas Huth 

We've removed support for SDL 1.2 quite a while ago already, so let's
use SDL 2 now in Travis to get test coverage for SDL again.
And while we're at it, also add libsdl2-image-dev which can be used
by QEMU nowadays, too.

Signed-off-by: Thomas Huth 
Message-Id: <20191009170701.14756-3-th...@redhat.com>
---
 .travis.yml | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 7be2a9949f5..b446e04e8ae 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -39,7 +39,8 @@ addons:
   - libpixman-1-dev
   - libpng12-dev
   - librados-dev
-  - libsdl1.2-dev
+  - libsdl2-dev
+  - libsdl2-image-dev
   - libseccomp-dev
   - libspice-protocol-dev
   - libspice-server-dev
@@ -309,7 +310,8 @@ matrix:
 - libpixman-1-dev
 - libpng12-dev
 - librados-dev
-- libsdl1.2-dev
+- libsdl2-dev
+- libsdl2-image-dev
 - libseccomp-dev
 - libspice-protocol-dev
 - libspice-server-dev
-- 
2.20.1




Re: [PATCH v14 0/9] hw/m68k: add Apple Machintosh Quadra 800 machine

2019-10-22 Thread no-reply
Patchew URL: https://patchew.org/QEMU/20191022111738.20803-1-laur...@vivier.eu/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Subject: [PATCH v14 0/9] hw/m68k: add Apple Machintosh Quadra 800 machine
Type: series
Message-id: 20191022111738.20803-1-laur...@vivier.eu

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
9523b4e BootLinuxConsoleTest: Test the Quadra 800
6c1259d hw/m68k: define Macintosh Quadra 800
ad6f07a hw/m68k: add a dummy SWIM floppy controller
053ee9c hw/m68k: add Nubus macfb video card
37f2e03 hw/m68k: add Nubus support
40928de hw/m68k: implement ADB bus support for via
63fb68d hw/m68k: add VIA support
72855f9 dp8393x: manage big endian bus
c3a673a esp: add pseudo-DMA as used by Macintosh

=== OUTPUT BEGIN ===
1/9 Checking commit c3a673a27c72 (esp: add pseudo-DMA as used by Macintosh)
2/9 Checking commit 72855f9b74c4 (dp8393x: manage big endian bus)
3/9 Checking commit 63fb68dcc3e2 (hw/m68k: add VIA support)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#83: 
new file mode 100644

ERROR: space prohibited after that '&&' (ctx:WxW)
#455: FILE: hw/misc/mac_via.c:368:
+if (!(v1s->last_b & VIA1B_vRTCClk) && (s->b & VIA1B_vRTCClk)) {
^

total: 1 errors, 1 warnings, 912 lines checked

Patch 3/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

4/9 Checking commit 40928debe4eb (hw/m68k: implement ADB bus support for via)
5/9 Checking commit 37f2e033e3e6 (hw/m68k: add Nubus support)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#64: 
new file mode 100644

total: 0 errors, 1 warnings, 531 lines checked

Patch 5/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
6/9 Checking commit 053ee9c65705 (hw/m68k: add Nubus macfb video card)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#75: 
new file mode 100644

total: 0 errors, 1 warnings, 597 lines checked

Patch 6/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
7/9 Checking commit ad6f07ab616b (hw/m68k: add a dummy SWIM floppy controller)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#62: 
new file mode 100644

total: 0 errors, 1 warnings, 593 lines checked

Patch 7/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
8/9 Checking commit 6c1259d52f65 (hw/m68k: define Macintosh Quadra 800)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#71: 
new file mode 100644

total: 0 errors, 1 warnings, 530 lines checked

Patch 8/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
9/9 Checking commit 9523b4eb8927 (BootLinuxConsoleTest: Test the Quadra 800)
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20191022111738.20803-1-laur...@vivier.eu/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [PATCH v3 0/6] Enable more iotests during "make check-block"

2019-10-22 Thread Thomas Huth
On 22/10/2019 15.48, Alex Bennée wrote:
> 
> Max Reitz  writes:
> 
>> On 22.10.19 15:11, Alex Bennée wrote:
>>>
>>> Thomas Huth  writes:
>>>
 As discussed here:

  https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg00697.html

 and here:

  https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg01388.html
>>>
>>> Queued to testing/next, thanks.
>>
>> It should be noted that this series depends on my SOCK_DIR series (which
>> I have in my block branch), or the newly added tests are likely to fail
>> in the CI environment.
> 
> Ahh I misread
> 
> 
 it would be good to have some more valuable iotests enabled in the
 "auto" group to get better iotest coverage during "make check".

 And once Max' "iotests: Add and use $SOCK_DIR" patch series has been
 merged, we can indeed enable these Python-based tests, too.
> 
> I though these weren't enabled in this series. Do I need to drop all the
> patches?

I think it's better if the iotest patches go through Max' or Kevin's
block tree.

 Thomas




Re: [PATCH v3 07/16] libqos: enforce Device Initialization order

2019-10-22 Thread Thomas Huth
On 22/10/2019 17.48, Stefan Hajnoczi wrote:
> On Mon, Oct 21, 2019 at 02:15:53PM +0200, Thomas Huth wrote:
>> On 19/10/2019 08.38, Stefan Hajnoczi wrote:
>>> According to VIRTIO 1.1 "3.1.1 Driver Requirements: Device
>>> Initialization", configuration space and virtqueues cannot be accessed
>>> before features have been negotiated.  Enforce this requirement.
>>>
>>> Signed-off-by: Stefan Hajnoczi 
>>> ---
>>>  tests/libqos/virtio.c | 11 +++
>>>  1 file changed, 11 insertions(+)
>>>
>>> diff --git a/tests/libqos/virtio.c b/tests/libqos/virtio.c
>>> index 4f7e6bb8a1..2593996c98 100644
>>> --- a/tests/libqos/virtio.c
>>> +++ b/tests/libqos/virtio.c
>>> @@ -13,23 +13,33 @@
>>>  #include "standard-headers/linux/virtio_config.h"
>>>  #include "standard-headers/linux/virtio_ring.h"
>>>  
>>> +/* Features must be negotiated before config space or virtqueue access */
>>> +static void check_features_negotiated(QVirtioDevice *d)
>>> +{
>>> +g_assert_cmphex(d->features, !=, 0);
>>> +}
>>
>> Isn't it "legal" to negotiate 0 feature bits, too (for legacy devices)?
> 
> Yes, it's possible for Legacy devices.  If someone ever does that
> they'll need to extend this code, but it's unlikely so I'd rather not
> complicate this.

Could you please add at least a comment here with that explanation?

 Thanks,
  Thomas




Re: Missing PVR setting capability

2019-10-22 Thread Thomas Huth
On 22/10/2019 18.24, Wayne Li wrote:
> If I run "lsmod | grep kvm" nothing shows up but if I just do a "find .
> -name "kvm"" I get the following:
[...]
> ./sys/devices/virtual/misc/kvm
> ./sys/class/misc/kvm
> ./sys/kernel/debug/kvm
> ./sys/module/kvm
> 
> I guess this shows my OS does have KVM on it?

Alright, I guess that means that KVM compiled into the kernel ... should
be fine, I think.

>  I added the two flags you
> mentioned when running QEMU (the -cpu and the -machine flags) but the
> -cpu flag doesn't seem like it's doing anything as even when I put a
> clearly wrong argument after the flag no error related to the cpu is
> thrown.  Also it says ppce500 is not a machine type and that the
> supported machines are:
> 
> bamboo               bamboo
> boeing-machine       Boeing Machine
> none                 empty machine
> ref405ep             ref405ep
> taihu                taihu
> virtex-ml507         Xilinx Virtex ML507 reference design

Oh, are you running qemu-system-ppc instead of qemu-system-ppc64? I
thought these e*500 CPUs are 64-bit? Is your host kernel 64-bit or 32-bit?

Anyway, if you're using a modified version of QEMU, you should
definitely ask the people who did the modifications there.

 Thomas




Re: [PATCH] Semihost SYS_READC implementation

2019-10-22 Thread Keith Packard
Paolo Bonzini  writes:

Thanks so much for looking at this patch.

> I'm a bit confused, why is it not using semihosting_get_chardev?  That
> would be
>
>   -chardev stdio,id=semihost
>   -semihosting-config on,chardev=semihost

Because I didn't realize the semihosting code already had a Chardev
option.  Thanks much for pointing it out. I've changed the code to use
the semihosting chardev instead of serial_hd(0). That change was quite
simple:

 void qemu_semihosting_console_init(void)
 {
-if (semihosting_enabled()) {
-qemu_chr_fe_init(, serial_hd(0), _abort);
+Chardev *chr = semihosting_get_chardev();
+
+if  (chr) {
+qemu_chr_fe_init(, chr, _abort);
 qemu_chr_fe_set_handlers(,
  console_can_read,
  console_read,

(I left the call to qemu_semihosting_console_init() late in the
initialization process so that the semihosting I/O ended up with the
stdio mux focus instead of the monitor)

Your example command line was really helpful in figuring out how to get
this to work. Here's the full command line I ended up using so that
semihost, serial and monitor are all muxed to stdio:

$ qemu-system-arm -chardev stdio,mux=on,id=stdio0 -serial chardev:stdio0 
-semihosting-config enable=on,chardev=stdio0 -mon chardev=stdio0,mode=readline 

It might be nice if this could be shortened, but it certainly provides
the necessary options to make it all work.

I'll post an updated version of the patch in a while, after waiting to
see if there are any additional comments.

-- 
-keith


signature.asc
Description: PGP signature


Re: [PATCH 5/5] aspeed/i2c: Add trace events

2019-10-22 Thread Philippe Mathieu-Daudé

Hi Cédric,

Sorry for the late reply.

On 10/17/19 1:52 PM, Cédric Le Goater wrote:

Hello Philippe,

On 17/10/2019 12:22, Philippe Mathieu-Daudé wrote:

Hi Cédric,

On 10/16/19 10:50 AM, Cédric Le Goater wrote:

Signed-off-by: Cédric Le Goater 
---
   hw/i2c/aspeed_i2c.c | 93 ++---
   hw/i2c/trace-events |  9 +
   2 files changed, 89 insertions(+), 13 deletions(-)

diff --git a/hw/i2c/aspeed_i2c.c b/hw/i2c/aspeed_i2c.c
index 030d9c56be65..2da04a4bff30 100644
--- a/hw/i2c/aspeed_i2c.c
+++ b/hw/i2c/aspeed_i2c.c
@@ -28,6 +28,7 @@
   #include "hw/i2c/aspeed_i2c.h"
   #include "hw/irq.h"
   #include "hw/qdev-properties.h"
+#include "trace.h"
     /* I2C Global Register */
   @@ -158,6 +159,13 @@ static inline void 
aspeed_i2c_bus_raise_interrupt(AspeedI2CBus *bus)
   {
   AspeedI2CClass *aic = ASPEED_I2C_GET_CLASS(bus->controller);
   +    trace_aspeed_i2c_bus_raise_interrupt(bus->intr_status,
+  bus->intr_status & I2CD_INTR_TX_NAK ? "nak|" : "",
+  bus->intr_status & I2CD_INTR_TX_ACK ? "ack|" : "",
+  bus->intr_status & I2CD_INTR_RX_DONE ? "done|" : "",
+  bus->intr_status & I2CD_INTR_NORMAL_STOP ? "normal|" : "",
+  bus->intr_status & I2CD_INTR_ABNORMAL ? "abnormal" : "");
+
   bus->intr_status &= bus->intr_ctrl;
   if (bus->intr_status) {
   bus->controller->intr_status |= 1 << bus->id;
@@ -170,41 +178,57 @@ static uint64_t aspeed_i2c_bus_read(void *opaque, hwaddr 
offset,
   {
   AspeedI2CBus *bus = opaque;
   AspeedI2CClass *aic = ASPEED_I2C_GET_CLASS(bus->controller);
+    uint64_t value = -1;
     switch (offset) {
   case I2CD_FUN_CTRL_REG:
-    return bus->ctrl;
+    value = bus->ctrl;
+    break;
   case I2CD_AC_TIMING_REG1:
-    return bus->timing[0];
+    value = bus->timing[0];
+    break;
   case I2CD_AC_TIMING_REG2:
-    return bus->timing[1];
+    value = bus->timing[1];
+    break;
   case I2CD_INTR_CTRL_REG:
-    return bus->intr_ctrl;
+    value = bus->intr_ctrl;
+    break;
   case I2CD_INTR_STS_REG:
-    return bus->intr_status;
+    value = bus->intr_status;
+    break;
   case I2CD_POOL_CTRL_REG:
-    return bus->pool_ctrl;
+    value = bus->pool_ctrl;
+    break;
   case I2CD_BYTE_BUF_REG:
-    return bus->buf;
+    value = bus->buf;
+    break;
   case I2CD_CMD_REG:
-    return bus->cmd | (i2c_bus_busy(bus->bus) << 16);
+    value = bus->cmd | (i2c_bus_busy(bus->bus) << 16);
+    break;
   case I2CD_DMA_ADDR:
   if (!aic->has_dma) {
   qemu_log_mask(LOG_GUEST_ERROR, "%s: No DMA support\n",  
__func__);
-    return -1;
+    break;
   }
-    return bus->dma_addr;
+    value = bus->dma_addr;
+    break;
   case I2CD_DMA_LEN:
   if (!aic->has_dma) {
   qemu_log_mask(LOG_GUEST_ERROR, "%s: No DMA support\n",  
__func__);
-    return -1;
+    break;
   }
-    return bus->dma_len;
+    value = bus->dma_len;
+    break;
+
   default:
   qemu_log_mask(LOG_GUEST_ERROR,
     "%s: Bad offset 0x%" HWADDR_PRIx "\n", __func__, 
offset);
-    return -1;
+    value = -1;
+    break;
   }
+
+    trace_aspeed_i2c_bus_read(bus->id, offset, size, value);
+    return value;
   }
     static void aspeed_i2c_set_state(AspeedI2CBus *bus, uint8_t state)
@@ -246,6 +270,9 @@ static int aspeed_i2c_bus_send(AspeedI2CBus *bus, uint8_t 
pool_start)
   for (i = pool_start; i < I2CD_POOL_TX_COUNT(bus->pool_ctrl); i++) {
   uint8_t *pool_base = aic->bus_pool_base(bus);
   +    trace_aspeed_i2c_bus_send("BUF", i + 1,
+  I2CD_POOL_TX_COUNT(bus->pool_ctrl),
+  pool_base[i]);
   ret = i2c_send(bus->bus, pool_base[i]);
   if (ret) {
   break;
@@ -256,6 +283,7 @@ static int aspeed_i2c_bus_send(AspeedI2CBus *bus, uint8_t 
pool_start)
   while (bus->dma_len) {
   uint8_t data;
   aspeed_i2c_dma_read(bus, );
+    trace_aspeed_i2c_bus_send("DMA", bus->dma_len, bus->dma_len, data);
   ret = i2c_send(bus->bus, data);
   if (ret) {
   break;
@@ -263,6 +291,7 @@ static int aspeed_i2c_bus_send(AspeedI2CBus *bus, uint8_t 
pool_start)
   }
   bus->cmd &= ~I2CD_TX_DMA_ENABLE;
   } else {
+    trace_aspeed_i2c_bus_send("BYTE", pool_start, 1, bus->buf);
   ret = i2c_send(bus->bus, bus->buf);
   }
   @@ -281,6 +310,9 @@ static void aspeed_i2c_bus_recv(AspeedI2CBus *bus)
     for (i = 0; i < I2CD_POOL_RX_SIZE(bus->pool_ctrl); i++) {
   pool_base[i] = i2c_recv(bus->bus);
+    trace_aspeed_i2c_bus_recv("BUF", i + 1,
+  

Re: [PATCH v2 23/28] smbus-eeprom: remove PROP_PTR

2019-10-22 Thread Marc-André Lureau
Hi

On Tue, Oct 22, 2019 at 7:19 PM Peter Maydell  wrote:
>
> On Tue, 22 Oct 2019 at 17:24, Marc-André Lureau
>  wrote:
> >
> > Instead, set the initial data field directly.
> >
> > (the initial data is an array of 256 bytes. As I don't know if it may
> > change over time, I keep the pointer to original buffer as is, but it
> > might be worth to consider to copy it instead)
>
> All the callers to smbus_eeprom_init_one() allocate the
> memory for the initial data, populate it, pass the pointer
> to smbus_eeprom_init_one() and do not save the pointer
> anyway. So we effectively "own" the data -- we could choose
> to copy the data and make the callers free the memory instead.
>
> > Signed-off-by: Marc-André Lureau 
>
> I'd still like to know what the right QOM way to pass
> 256 bytes of constant data to a device as a property is.
>

A property with a uint list visitor is the closest thing we have I
guess. We can probably have a specialized QObject to hold a fixed
array, but string form will probably remain a list, I guess.

I can try that, but this is quite complicated to pass 256 bytes internally..



Re: [RFC 1/3] acpi: cpuhp: fix 'Command data' description is spec

2019-10-22 Thread Laszlo Ersek
(I've been dropped from the address list, not sure why)

On 10/22/19 19:17, Christophe de Dinechin wrote:
> 
> Laszlo Ersek writes:
> 
>> On 10/10/19 15:31, Laszlo Ersek wrote:
>>> 2nd round:
>>>
>>> On 10/09/19 15:22, Igor Mammedov wrote:
 QEMU returns 0, in case of erro or invalid value in 'Command field',
 make spec match reality, i.e.
>>>
>>> AHA! so this is exactly where you meant to list the particular cases
>>> when "command data" reads as 0:
>>> - CPU >= max_cpus selected,
>>> - CPU with pending events asked for, but none found
>>>
 Also fix returned value description  in case 'Command field' == 0x0,
 it's in not PXM but CPU selector value with pending event

 Signed-off-by: Igor Mammedov 
 ---
  docs/specs/acpi_cpu_hotplug.txt | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

 diff --git a/docs/specs/acpi_cpu_hotplug.txt 
 b/docs/specs/acpi_cpu_hotplug.txt
 index ee219c8358..ac5903b2b1 100644
 --- a/docs/specs/acpi_cpu_hotplug.txt
 +++ b/docs/specs/acpi_cpu_hotplug.txt
 @@ -44,9 +44,10 @@ read access:
 3-7: reserved and should be ignored by OSPM
  [0x5-0x7] reserved
  [0x8] Command data: (DWORD access)
 -  in case of error or unsupported command reads is 0x
 +  in case of error or unsupported command reads is 0x0
current 'Command field' value:
 -  0: returns PXM value corresponding to device
 +  0: returns CPU selector value corresponding to a CPU with
 + pending event.

  write access:
  offset:

>>>
>>> How about:
>>>
>>> [0x8] Command data: (DWORD access, little endian)
>>>   If the "CPU selector" value last stored by the guest refers to
>>>   an impossible CPU, then 0.
>>>   Otherwise, if the "Command field" value last stored by the
>>>   guest differs from 0, then 0.
>>>   Otherwise, if there is at least one CPU with a pending event,
>>>   then that CPU has been selected; the command data register
>>>   returns that selector.
>>>   Otherwise, 0.
>>
>> Hmmm not exactly. Let me try again.
>>
>> [0x8] Command data: (DWORD access, little endian)
>>   If the "CPU selector" value last stored by the guest refers to
>>   an impossible CPU, then 0.
>>   Otherwise, if the "Command field" value last stored by the
>>   guest differs from 0, then 0.
>>   Otherwise, the currently selected CPU.
> 
> How about phrasing it to put the more general case first, e.g.
> 
> [0x8] Command data: (DWORD access, little endian)
> 
>   The currently selected CPU, unless:
>   - The "CPU selector" value refers to an impossible CPU
>   - The "Command field" value last stored by the guest differs
> from 0
>   In these last two cases, the value is 0.

I prefer my proposal because it translates to source code more directly
(a ladder of "if / else" pairs, or similar).

(I know that some programming languages support "unless"; I could never
wrap my brain around that idea! :) )

Thanks
Laszlo




Re: [PATCH 3/5] aspeed: Add a DRAM memory region at the SoC level

2019-10-22 Thread Philippe Mathieu-Daudé

On 10/16/19 10:50 AM, Cédric Le Goater wrote:

Currently, we link the DRAM memory region to the FMC model (for DMAs)
through a property alias at the SoC level. The I2C model will need a
similar region for DMA support, add a DRAM region property at the SoC
level for both model to use.

Signed-off-by: Cédric Le Goater 
---
  include/hw/arm/aspeed_soc.h | 1 +
  hw/arm/aspeed_ast2600.c | 7 +--
  hw/arm/aspeed_soc.c | 9 +++--
  3 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/include/hw/arm/aspeed_soc.h b/include/hw/arm/aspeed_soc.h
index cccb684a19bb..3375ef91607f 100644
--- a/include/hw/arm/aspeed_soc.h
+++ b/include/hw/arm/aspeed_soc.h
@@ -40,6 +40,7 @@ typedef struct AspeedSoCState {
  ARMCPU cpu[ASPEED_CPUS_NUM];
  uint32_t num_cpus;
  A15MPPrivState a7mpcore;
+MemoryRegion *dram_mr;
  MemoryRegion sram;
  AspeedVICState vic;
  AspeedRtcState rtc;
diff --git a/hw/arm/aspeed_ast2600.c b/hw/arm/aspeed_ast2600.c
index 931887ac681f..a403c2aae067 100644
--- a/hw/arm/aspeed_ast2600.c
+++ b/hw/arm/aspeed_ast2600.c
@@ -158,8 +158,6 @@ static void aspeed_soc_ast2600_init(Object *obj)
typename);
  object_property_add_alias(obj, "num-cs", OBJECT(>fmc), "num-cs",
_abort);
-object_property_add_alias(obj, "dram", OBJECT(>fmc), "dram",
-  _abort);
  
  for (i = 0; i < sc->spis_num; i++) {

  snprintf(typename, sizeof(typename), "aspeed.spi%d-%s", i + 1, 
socname);
@@ -362,6 +360,11 @@ static void aspeed_soc_ast2600_realize(DeviceState *dev, 
Error **errp)
  }
  
  /* FMC, The number of CS is set at the board level */

+object_property_set_link(OBJECT(>fmc), OBJECT(s->dram_mr), "dram", 
);
+if (err) {
+error_propagate(errp, err);
+return;
+}
  object_property_set_int(OBJECT(>fmc), sc->memmap[ASPEED_SDRAM],
  "sdram-base", );
  if (err) {
diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
index f4fe243458fd..dd1ee0e3336d 100644
--- a/hw/arm/aspeed_soc.c
+++ b/hw/arm/aspeed_soc.c
@@ -175,8 +175,6 @@ static void aspeed_soc_init(Object *obj)
typename);
  object_property_add_alias(obj, "num-cs", OBJECT(>fmc), "num-cs",
_abort);
-object_property_add_alias(obj, "dram", OBJECT(>fmc), "dram",
-  _abort);
  
  for (i = 0; i < sc->spis_num; i++) {

  snprintf(typename, sizeof(typename), "aspeed.spi%d-%s", i + 1, 
socname);
@@ -323,6 +321,11 @@ static void aspeed_soc_realize(DeviceState *dev, Error 
**errp)
 aspeed_soc_get_irq(s, ASPEED_I2C));
  
  /* FMC, The number of CS is set at the board level */

+object_property_set_link(OBJECT(>fmc), OBJECT(s->dram_mr), "dram", 
);
+if (err) {
+error_propagate(errp, err);
+return;
+}
  object_property_set_int(OBJECT(>fmc), sc->memmap[ASPEED_SDRAM],
  "sdram-base", );
  if (err) {
@@ -429,6 +432,8 @@ static void aspeed_soc_realize(DeviceState *dev, Error 
**errp)
  }
  static Property aspeed_soc_properties[] = {
  DEFINE_PROP_UINT32("num-cpus", AspeedSoCState, num_cpus, 0),
+DEFINE_PROP_LINK("dram", AspeedSoCState, dram_mr, TYPE_MEMORY_REGION,
+ MemoryRegion *),
  DEFINE_PROP_END_OF_LIST(),
  };
  



Reviewed-by: Philippe Mathieu-Daudé 




Re: [PATCH 0/5] hw/i386/pc: Extract pc_gsi_create() and pc_i8259_create()

2019-10-22 Thread Philippe Mathieu-Daudé

On 10/22/19 6:55 PM, Paolo Bonzini wrote:

On 18/10/19 15:59, Philippe Mathieu-Daudé wrote:

These are few patches extracted from the previous too big series:
hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge
https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg03685.html

Dropped "Move kvm_i8259_init() declaration to sysemu/kvm.h" (thuth),
no logical changes:


I queued this, but neither I nor patchew got patch 5.  I just got it
from the PIIX3/i440FX series.


Odd... Yes this is the same patch resent with no change. Thanks for
noticing this and carrying about finding it!



paolo


$ git backport-diff -u pc_split_i440fx_piix-v1
Key:
[] : patches are identical
[] : number of functional differences between upstream/downstream patch
[down] : patch is downstream-only
The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively

001/5:[] [-C] 'hw/i386/pc: Extract pc_gsi_create()'
002/5:[] [--] 'hw/i386/pc: Reduce gsi_handler scope'
003/5:[] [--] 'hw/i386/pc: Move gsi_state creation code'
004/5:[] [--] 'hw/i386/pc: Extract pc_i8259_create()'
005/5:[] [--] 'hw/i386/pc: Remove kvm_i386.h include'

Based-on: <20191018134754.16362-1-phi...@redhat.com>
hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge [v2]
20191018134754.16362-1-philmd@redhat.com">https://mid.mail-archive.com/20191018134754.16362-1-philmd@redhat.com

Philippe Mathieu-Daudé (5):
   hw/i386/pc: Extract pc_gsi_create()
   hw/i386/pc: Reduce gsi_handler scope
   hw/i386/pc: Move gsi_state creation code
   hw/i386/pc: Extract pc_i8259_create()
   hw/i386/pc: Remove kvm_i386.h include

  hw/i386/pc.c | 36 +++-
  hw/i386/pc_piix.c| 23 ++-
  hw/i386/pc_q35.c | 28 
  include/hw/i386/pc.h |  3 ++-
  4 files changed, 43 insertions(+), 47 deletions(-)







Re: [PATCH] aspeed: Add an AST2600 eval board

2019-10-22 Thread Cédric Le Goater
On 22/10/2019 18:43, Peter Maydell wrote:
> On Thu, 17 Oct 2019 at 14:54, Peter Maydell  wrote:
>>
>> On Thu, 17 Oct 2019 at 07:33, Joel Stanley  wrote:
>>>
>>> On Wed, 16 Oct 2019 at 09:08, Cédric Le Goater  wrote:

 Define the board with 1 GiB of RAM but some boards can have up to 2
 GiB.

 Signed-off-by: Cédric Le Goater 
 Reviewed-by: Joel Stanley 
 ---

  Changes since AST2600 patchset:

  - lowered the RAM size to 1 GiB as it was breaking the tests on some
hosts.
>>>
>>> Peter,
>>>
>>> After chatting with Cédric I agree we should merge this patch.
>>>
>>> As it turns out the EVBs have differing amounts of RAM; his has 1GB
>>> while mine has 2GB. So we are not being inaccurate by setting 1GB as
>>> the default here.
>>
>> That's convenient, means we don't have to figure out how to
>> special-case the test infrastructure for it :-)
> 
> This is now OK on the 32-bit boxes, but still fails 'make check'
> on my OSX system:
> 
> manooth$ QTEST_QEMU_BINARY=aarch64-softmmu/qemu-system-aarch64
> tests/qom-test -p /aarch64/qom/ast2600-evb
> /aarch64/qom/ast2600-evb: Broken pipe
> /Users/pm215/src/qemu-for-merges/tests/libqtest.c:149: kill_qemu()
> detected QEMU death from signal 6 (Abort trap: 6)
> Abort trap: 6
> 
> Dropping from the pullreq again :-(

It will be back !


Is it time for me to install an OSX system for dev and tests or is there 
a way to reproduce the issue ? no errors spotted in valgrind.

Thanks,

C.



Re: [PATCH v3 09/16] libqos: access VIRTIO 1.0 vring in little-endian

2019-10-22 Thread Christophe de Dinechin


Stefan Hajnoczi writes:
[...]
> +static uint16_t qvirtio_readw(QVirtioDevice *d, QTestState *qts, uint64_t 
> addr)
> +{
> +uint16_t val = qtest_readw(qts, addr);
> +
> +if (d->features & (1ull << VIRTIO_F_VERSION_1) && qtest_big_endian(qts)) 
> {

For my education, I was wondering why tests use the (1ull << FEATURE)
notation and not an equivalent of virtio_has_feature()? Is this
intentional, or just legacy?


--
Cheers,
Christophe de Dinechin (IRC c3d)




[PATCH v5 7/7] spapr/xive: Set the OS CAM line at reset

2019-10-22 Thread Cédric Le Goater
When a Virtual Processor is scheduled to run on a HW thread, the
hypervisor pushes its identifier in the OS CAM line. When running with
kernel_irqchip=off, QEMU needs to emulate the same behavior.

Set the OS CAM line when the interrupt presenter of the sPAPR core is
reset. This will also cover the case of hot-plugged CPUs.

This change also has the benefit to remove the use of CPU_FOREACH()
which can be unsafe.

Signed-off-by: Cédric Le Goater 
Reviewed-by: Greg Kurz 
---
 include/hw/ppc/spapr_xive.h |  1 -
 hw/intc/spapr_xive.c| 48 +
 2 files changed, 17 insertions(+), 32 deletions(-)

diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
index d84bd5c229f0..742b7e834f2a 100644
--- a/include/hw/ppc/spapr_xive.h
+++ b/include/hw/ppc/spapr_xive.h
@@ -57,7 +57,6 @@ typedef struct SpaprXive {
 void spapr_xive_pic_print_info(SpaprXive *xive, Monitor *mon);
 
 void spapr_xive_hcall_init(SpaprMachineState *spapr);
-void spapr_xive_set_tctx_os_cam(XiveTCTX *tctx);
 void spapr_xive_mmio_set_enabled(SpaprXive *xive, bool enable);
 void spapr_xive_map_mmio(SpaprXive *xive);
 
diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
index 20a8d8285f64..d8e1291905c3 100644
--- a/hw/intc/spapr_xive.c
+++ b/hw/intc/spapr_xive.c
@@ -205,23 +205,6 @@ void spapr_xive_mmio_set_enabled(SpaprXive *xive, bool 
enable)
 memory_region_set_enabled(>end_source.esb_mmio, false);
 }
 
-/*
- * When a Virtual Processor is scheduled to run on a HW thread, the
- * hypervisor pushes its identifier in the OS CAM line. Emulate the
- * same behavior under QEMU.
- */
-void spapr_xive_set_tctx_os_cam(XiveTCTX *tctx)
-{
-uint8_t  nvt_blk;
-uint32_t nvt_idx;
-uint32_t nvt_cam;
-
-spapr_xive_cpu_to_nvt(POWERPC_CPU(tctx->cs), _blk, _idx);
-
-nvt_cam = cpu_to_be32(TM_QW1W2_VO | xive_nvt_cam_line(nvt_blk, nvt_idx));
-memcpy(>regs[TM_QW1_OS + TM_WORD2], _cam, 4);
-}
-
 static void spapr_xive_end_reset(XiveEND *end)
 {
 memset(end, 0, sizeof(*end));
@@ -544,21 +527,32 @@ static int 
spapr_xive_cpu_intc_create(SpaprInterruptController *intc,
 }
 
 spapr_cpu->tctx = XIVE_TCTX(obj);
-
-/*
- * (TCG) Early setting the OS CAM line for hotplugged CPUs as they
- * don't beneficiate from the reset of the XIVE IRQ backend
- */
-spapr_xive_set_tctx_os_cam(spapr_cpu->tctx);
 return 0;
 }
 
+static void xive_tctx_set_os_cam(XiveTCTX *tctx, uint32_t os_cam)
+{
+uint32_t qw1w2 = cpu_to_be32(TM_QW1W2_VO | os_cam);
+memcpy(>regs[TM_QW1_OS + TM_WORD2], , 4);
+}
+
 static void spapr_xive_cpu_intc_reset(SpaprInterruptController *intc,
  PowerPCCPU *cpu)
 {
 XiveTCTX *tctx = spapr_cpu_state(cpu)->tctx;
+uint8_t  nvt_blk;
+uint32_t nvt_idx;
 
 xive_tctx_reset(tctx);
+
+/*
+ * When a Virtual Processor is scheduled to run on a HW thread,
+ * the hypervisor pushes its identifier in the OS CAM line.
+ * Emulate the same behavior under QEMU.
+ */
+spapr_xive_cpu_to_nvt(cpu, _blk, _idx);
+
+xive_tctx_set_os_cam(tctx, xive_nvt_cam_line(nvt_blk, nvt_idx));
 }
 
 static void spapr_xive_set_irq(SpaprInterruptController *intc, int irq, int 
val)
@@ -651,14 +645,6 @@ static void spapr_xive_dt(SpaprInterruptController *intc, 
uint32_t nr_servers,
 static int spapr_xive_activate(SpaprInterruptController *intc, Error **errp)
 {
 SpaprXive *xive = SPAPR_XIVE(intc);
-CPUState *cs;
-
-CPU_FOREACH(cs) {
-PowerPCCPU *cpu = POWERPC_CPU(cs);
-
-/* (TCG) Set the OS CAM line of the thread interrupt context. */
-spapr_xive_set_tctx_os_cam(spapr_cpu_state(cpu)->tctx);
-}
 
 if (kvm_enabled()) {
 int rc = spapr_irq_init_kvm(kvmppc_xive_connect, intc, errp);
-- 
2.21.0




Re: [PATCH v2 23/28] smbus-eeprom: remove PROP_PTR

2019-10-22 Thread Peter Maydell
On Tue, 22 Oct 2019 at 17:24, Marc-André Lureau
 wrote:
>
> Instead, set the initial data field directly.
>
> (the initial data is an array of 256 bytes. As I don't know if it may
> change over time, I keep the pointer to original buffer as is, but it
> might be worth to consider to copy it instead)

All the callers to smbus_eeprom_init_one() allocate the
memory for the initial data, populate it, pass the pointer
to smbus_eeprom_init_one() and do not save the pointer
anyway. So we effectively "own" the data -- we could choose
to copy the data and make the callers free the memory instead.

> Signed-off-by: Marc-André Lureau 

I'd still like to know what the right QOM way to pass
256 bytes of constant data to a device as a property is.


thanks
-- PMM



Re: [RFC 1/3] acpi: cpuhp: fix 'Command data' description is spec

2019-10-22 Thread Christophe de Dinechin


Laszlo Ersek writes:

> On 10/10/19 15:31, Laszlo Ersek wrote:
>> 2nd round:
>>
>> On 10/09/19 15:22, Igor Mammedov wrote:
>>> QEMU returns 0, in case of erro or invalid value in 'Command field',
>>> make spec match reality, i.e.
>>
>> AHA! so this is exactly where you meant to list the particular cases
>> when "command data" reads as 0:
>> - CPU >= max_cpus selected,
>> - CPU with pending events asked for, but none found
>>
>>> Also fix returned value description  in case 'Command field' == 0x0,
>>> it's in not PXM but CPU selector value with pending event
>>>
>>> Signed-off-by: Igor Mammedov 
>>> ---
>>>  docs/specs/acpi_cpu_hotplug.txt | 5 +++--
>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/docs/specs/acpi_cpu_hotplug.txt 
>>> b/docs/specs/acpi_cpu_hotplug.txt
>>> index ee219c8358..ac5903b2b1 100644
>>> --- a/docs/specs/acpi_cpu_hotplug.txt
>>> +++ b/docs/specs/acpi_cpu_hotplug.txt
>>> @@ -44,9 +44,10 @@ read access:
>>> 3-7: reserved and should be ignored by OSPM
>>>  [0x5-0x7] reserved
>>>  [0x8] Command data: (DWORD access)
>>> -  in case of error or unsupported command reads is 0x
>>> +  in case of error or unsupported command reads is 0x0
>>>current 'Command field' value:
>>> -  0: returns PXM value corresponding to device
>>> +  0: returns CPU selector value corresponding to a CPU with
>>> + pending event.
>>>
>>>  write access:
>>>  offset:
>>>
>>
>> How about:
>>
>> [0x8] Command data: (DWORD access, little endian)
>>   If the "CPU selector" value last stored by the guest refers to
>>   an impossible CPU, then 0.
>>   Otherwise, if the "Command field" value last stored by the
>>   guest differs from 0, then 0.
>>   Otherwise, if there is at least one CPU with a pending event,
>>   then that CPU has been selected; the command data register
>>   returns that selector.
>>   Otherwise, 0.
>
> Hmmm not exactly. Let me try again.
>
> [0x8] Command data: (DWORD access, little endian)
>   If the "CPU selector" value last stored by the guest refers to
>   an impossible CPU, then 0.
>   Otherwise, if the "Command field" value last stored by the
>   guest differs from 0, then 0.
>   Otherwise, the currently selected CPU.

How about phrasing it to put the more general case first, e.g.

[0x8] Command data: (DWORD access, little endian)

  The currently selected CPU, unless:
  - The "CPU selector" value refers to an impossible CPU
  - The "Command field" value last stored by the guest differs
from 0
  In these last two cases, the value is 0.

>
> Thanks,
> Laszlo


--
Cheers,
Christophe de Dinechin (IRC c3d)




Re: [PATCH v2 10/28] serial: add "base" property

2019-10-22 Thread Peter Maydell
On Tue, 22 Oct 2019 at 17:23, Marc-André Lureau
 wrote:
>
> Signed-off-by: Marc-André Lureau 
> ---
>  hw/char/serial.c | 3 +++
>  include/hw/char/serial.h | 1 +
>  2 files changed, 4 insertions(+)
>
> diff --git a/hw/char/serial.c b/hw/char/serial.c
> index 0ae52ec60c..4748a2b023 100644
> --- a/hw/char/serial.c
> +++ b/hw/char/serial.c
> @@ -990,6 +990,7 @@ SerialState *serial_init(int base, qemu_irq irq, int 
> baudbase,
>  qdev_connect_gpio_out_named(dev, "serial-irq", 0, irq);
>  qdev_prop_set_uint32(dev, "baudbase", baudbase);
>  qdev_prop_set_chr(dev, "chardev", chr);
> +qdev_prop_set_uint64(dev, "base", base);
>  serial_realize_core(s, _fatal);
>  qdev_set_legacy_instance_id(dev, base, 2);
>  qdev_init_nofail(dev);
> @@ -1003,6 +1004,7 @@ SerialState *serial_init(int base, qemu_irq irq, int 
> baudbase,
>  static Property serial_properties[] = {
>  DEFINE_PROP_CHR("chardev", SerialState, chr),
>  DEFINE_PROP_UINT32("baudbase", SerialState, baudbase, 115200),
> +DEFINE_PROP_UINT64("base", SerialState, base, 0),
>  DEFINE_PROP_END_OF_LIST(),
>  };
>
> @@ -1083,6 +1085,7 @@ SerialState *serial_mm_init(MemoryRegion *address_space,
>  qdev_prop_set_uint32(dev, "baudbase", baudbase);
>  qdev_prop_set_chr(dev, "chardev", chr);
>  qdev_prop_set_uint8(dev, "regshift", regshift);
> +qdev_prop_set_uint64(dev, "base", base);
>
>  serial_realize_core(s, _fatal);
>  qdev_set_legacy_instance_id(DEVICE(s), base, 2);
> diff --git a/include/hw/char/serial.h b/include/hw/char/serial.h
> index ecbd3f1b40..6e9c9768ed 100644
> --- a/include/hw/char/serial.h
> +++ b/include/hw/char/serial.h
> @@ -77,6 +77,7 @@ typedef struct SerialState {
>
>  QEMUTimer *modem_status_poll;
>  MemoryRegion io;
> +uint64_t base;
>  } SerialState;

Devices shouldn't have properties to set their MMIO base
address -- instead the memory-mapped serial device should
be a child of TYPE_SYSBUS_DEVICE, and should provide
a sysbus mmio region, which users of the device can
map at the address they want to map the registers.

thanks
-- PMM



[PATCH v5 6/7] ppc/pnv: Fix naming of routines realizing the CPUs

2019-10-22 Thread Cédric Le Goater
The 'vcpu' suffix is inherited from the sPAPR machine. Use better
names for PowerNV.

Signed-off-by: Cédric Le Goater 
Reviewed-by: Greg Kurz 
---
 hw/ppc/pnv_core.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
index be0310ac0340..e81cd3a3e047 100644
--- a/hw/ppc/pnv_core.c
+++ b/hw/ppc/pnv_core.c
@@ -162,7 +162,7 @@ static const MemoryRegionOps pnv_core_power9_xscom_ops = {
 .endianness = DEVICE_BIG_ENDIAN,
 };
 
-static void pnv_realize_vcpu(PowerPCCPU *cpu, PnvChip *chip, Error **errp)
+static void pnv_core_cpu_realize(PowerPCCPU *cpu, PnvChip *chip, Error **errp)
 {
 CPUPPCState *env = >env;
 int core_pir;
@@ -247,7 +247,7 @@ static void pnv_core_realize(DeviceState *dev, Error **errp)
 }
 
 for (j = 0; j < cc->nr_threads; j++) {
-pnv_realize_vcpu(pc->threads[j], pc->chip, _err);
+pnv_core_cpu_realize(pc->threads[j], pc->chip, _err);
 if (local_err) {
 goto err;
 }
@@ -269,7 +269,7 @@ err:
 error_propagate(errp, local_err);
 }
 
-static void pnv_unrealize_vcpu(PowerPCCPU *cpu)
+static void pnv_core_cpu_unrealize(PowerPCCPU *cpu)
 {
 PnvCPUState *pnv_cpu = pnv_cpu_state(cpu);
 
@@ -289,7 +289,7 @@ static void pnv_core_unrealize(DeviceState *dev, Error 
**errp)
 qemu_unregister_reset(pnv_core_reset, pc);
 
 for (i = 0; i < cc->nr_threads; i++) {
-pnv_unrealize_vcpu(pc->threads[i]);
+pnv_core_cpu_unrealize(pc->threads[i]);
 }
 g_free(pc->threads);
 }
-- 
2.21.0




Re: [PATCH V3 2/2] target/i386/kvm: Add Hyper-V direct tlb flush support

2019-10-22 Thread Paolo Bonzini
On 16/10/19 15:07, lantianyu1...@gmail.com wrote:
> From: Tianyu Lan 
> 
> Hyper-V direct tlb flush targets KVM on Hyper-V guest.
> Enable direct TLB flush for its guests meaning that TLB
> flush hypercalls are handled by Level 0 hypervisor (Hyper-V)
> bypassing KVM in Level 1. Due to the different ABI for hypercall
> parameters between Hyper-V and KVM, KVM capabilities should be
> hidden when enable Hyper-V direct tlb flush otherwise KVM
> hypercalls may be intercepted by Hyper-V. Add new parameter
> "hv-direct-tlbflush". Check expose_kvm and Hyper-V tlb flush
> capability status before enabling the feature.
> 
> Signed-off-by: Tianyu Lan 
> ---
> Change sicne v2:
>- Update new feature description and name.
>- Change failure print log.
> 
> Change since v1:
>- Add direct tlb flush's Hyper-V property and use
>hv_cpuid_check_and_set() to check the dependency of tlbflush
>feature.
>- Make new feature work with Hyper-V passthrough mode.
> ---
>  docs/hyperv.txt   | 10 ++
>  target/i386/cpu.c |  2 ++
>  target/i386/cpu.h |  1 +
>  target/i386/kvm.c | 24 
>  4 files changed, 37 insertions(+)
> 
> diff --git a/docs/hyperv.txt b/docs/hyperv.txt
> index 8fdf25c829..140a5c7e44 100644
> --- a/docs/hyperv.txt
> +++ b/docs/hyperv.txt
> @@ -184,6 +184,16 @@ enabled.
>  
>  Requires: hv-vpindex, hv-synic, hv-time, hv-stimer
>  
> +3.18. hv-direct-tlbflush
> +===
> +Enable direct TLB flush for KVM when it is running as a nested
> +hypervisor on top Hyper-V. When enabled, TLB flush hypercalls from L2
> +guests are being passed through to L0 (Hyper-V) for handling. Due to ABI
> +differences between Hyper-V and KVM hypercalls, L2 guests will not be
> +able to issue KVM hypercalls (as those could be mishanled by L0
> +Hyper-V), this requires KVM hypervisor signature to be hidden.
> +
> +Requires: hv-tlbflush, -kvm
>  
>  4. Development features
>  
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 44f1bbdcac..7bc7fee512 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -6156,6 +6156,8 @@ static Property x86_cpu_properties[] = {
>HYPERV_FEAT_IPI, 0),
>  DEFINE_PROP_BIT64("hv-stimer-direct", X86CPU, hyperv_features,
>HYPERV_FEAT_STIMER_DIRECT, 0),
> +DEFINE_PROP_BIT64("hv-direct-tlbflush", X86CPU, hyperv_features,
> +  HYPERV_FEAT_DIRECT_TLBFLUSH, 0),
>  DEFINE_PROP_BOOL("hv-passthrough", X86CPU, hyperv_passthrough, false),
>  
>  DEFINE_PROP_BOOL("check", X86CPU, check_cpuid, true),
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index eaa5395aa5..3cb105f7d6 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -907,6 +907,7 @@ typedef uint64_t FeatureWordArray[FEATURE_WORDS];
>  #define HYPERV_FEAT_EVMCS   12
>  #define HYPERV_FEAT_IPI 13
>  #define HYPERV_FEAT_STIMER_DIRECT   14
> +#define HYPERV_FEAT_DIRECT_TLBFLUSH 15
>  
>  #ifndef HYPERV_SPINLOCK_NEVER_RETRY
>  #define HYPERV_SPINLOCK_NEVER_RETRY 0x
> diff --git a/target/i386/kvm.c b/target/i386/kvm.c
> index 11b9c854b5..043b66ab22 100644
> --- a/target/i386/kvm.c
> +++ b/target/i386/kvm.c
> @@ -900,6 +900,10 @@ static struct {
>  },
>  .dependencies = BIT(HYPERV_FEAT_STIMER)
>  },
> +[HYPERV_FEAT_DIRECT_TLBFLUSH] = {
> +.desc = "direct paravirtualized TLB flush (hv-direct-tlbflush)",
> +.dependencies = BIT(HYPERV_FEAT_TLBFLUSH)
> +},
>  };
>  
>  static struct kvm_cpuid2 *try_get_hv_cpuid(CPUState *cs, int max)
> @@ -1224,6 +1228,7 @@ static int hyperv_handle_properties(CPUState *cs,
>  r |= hv_cpuid_check_and_set(cs, cpuid, HYPERV_FEAT_EVMCS);
>  r |= hv_cpuid_check_and_set(cs, cpuid, HYPERV_FEAT_IPI);
>  r |= hv_cpuid_check_and_set(cs, cpuid, HYPERV_FEAT_STIMER_DIRECT);
> +r |= hv_cpuid_check_and_set(cs, cpuid, HYPERV_FEAT_DIRECT_TLBFLUSH);
>  
>  /* Additional dependencies not covered by kvm_hyperv_properties[] */
>  if (hyperv_feat_enabled(cpu, HYPERV_FEAT_SYNIC) &&
> @@ -1243,6 +1248,25 @@ static int hyperv_handle_properties(CPUState *cs,
>  goto free;
>  }
>  
> +if (hyperv_feat_enabled(cpu, HYPERV_FEAT_DIRECT_TLBFLUSH) ||
> +cpu->hyperv_passthrough) {
> +if (!cpu->expose_kvm) {
> +r = kvm_vcpu_enable_cap(cs, KVM_CAP_HYPERV_DIRECT_TLBFLUSH, 0, 
> 0);
> +if (hyperv_feat_enabled(cpu, HYPERV_FEAT_DIRECT_TLBFLUSH) && r) {
> +fprintf(stderr,
> +"Hyper-V %s is not supported by kernel\n",
> +kvm_hyperv_properties[HYPERV_FEAT_DIRECT_TLBFLUSH].desc);
> +return -ENOSYS;
> +}
> +} else if (!cpu->hyperv_passthrough) {
> +fprintf(stderr,
> +"Hyper-V %s requires KVM hypervisor signature "
> +"to be hidden (-kvm).\n",
> + 

Re: [PATCH 0/5] hw/i386/pc: Extract pc_gsi_create() and pc_i8259_create()

2019-10-22 Thread Paolo Bonzini
On 18/10/19 15:59, Philippe Mathieu-Daudé wrote:
> These are few patches extracted from the previous too big series:
> hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge
> https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg03685.html
> 
> Dropped "Move kvm_i8259_init() declaration to sysemu/kvm.h" (thuth),
> no logical changes:

I queued this, but neither I nor patchew got patch 5.  I just got it
from the PIIX3/i440FX series.

paolo

> $ git backport-diff -u pc_split_i440fx_piix-v1
> Key:
> [] : patches are identical
> [] : number of functional differences between upstream/downstream patch
> [down] : patch is downstream-only
> The flags [FC] indicate (F)unctional and (C)ontextual differences, 
> respectively
> 
> 001/5:[] [-C] 'hw/i386/pc: Extract pc_gsi_create()'
> 002/5:[] [--] 'hw/i386/pc: Reduce gsi_handler scope'
> 003/5:[] [--] 'hw/i386/pc: Move gsi_state creation code'
> 004/5:[] [--] 'hw/i386/pc: Extract pc_i8259_create()'
> 005/5:[] [--] 'hw/i386/pc: Remove kvm_i386.h include'
> 
> Based-on: <20191018134754.16362-1-phi...@redhat.com>
> hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge [v2]
> 20191018134754.16362-1-philmd@redhat.com">https://mid.mail-archive.com/20191018134754.16362-1-philmd@redhat.com
> 
> Philippe Mathieu-Daudé (5):
>   hw/i386/pc: Extract pc_gsi_create()
>   hw/i386/pc: Reduce gsi_handler scope
>   hw/i386/pc: Move gsi_state creation code
>   hw/i386/pc: Extract pc_i8259_create()
>   hw/i386/pc: Remove kvm_i386.h include
> 
>  hw/i386/pc.c | 36 +++-
>  hw/i386/pc_piix.c| 23 ++-
>  hw/i386/pc_q35.c | 28 
>  include/hw/i386/pc.h |  3 ++-
>  4 files changed, 43 insertions(+), 47 deletions(-)
> 




Re: [PATCH 0/4] mc146818rtc: Allow call object_initialize(MC146818_RTC) instead of rtc_init()

2019-10-22 Thread Paolo Bonzini
On 18/10/19 15:35, Philippe Mathieu-Daudé wrote:
> Four RTC146818 patches extracted from a bigger series:
> "hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge"
> https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg03685.html
> 
> This step is required to be able to create a MC146818_RTC within
> a QOM object (which will be used in the "piix4: add a mc146818rtc
> controller" patch later).
> 
> No changes since previous post:
> $ git backport-diff -u pc_split_i440fx_piix
> Key:
> [] : patches are identical
> [] : number of functional differences between upstream/downstream patch
> [down] : patch is downstream-only
> The flags [FC] indicate (F)unctional and (C)ontextual differences, 
> respectively
> 
> 001/4:[] [--] 'mc146818rtc: move structure to header file'
> 002/4:[] [--] 'mc146818rtc: Move RTC_ISA_IRQ definition'
> 003/4:[] [--] 'mc146818rtc: Include "mc146818rtc_regs.h" directly in 
> mc146818rtc.c'
> 004/4:[] [--] 'mc146818rtc: always register rtc to rtc list'
> 
> Hervé Poussineau (2):
>   mc146818rtc: move structure to header file
>   mc146818rtc: always register rtc to rtc list
> 
> Philippe Mathieu-Daudé (2):
>   mc146818rtc: Move RTC_ISA_IRQ definition
>   mc146818rtc: Include mc146818rtc_regs.h directly in mc146818rtc.c
> 
>  hw/timer/mc146818rtc.c  | 39 +++--
>  include/hw/timer/mc146818rtc.h  | 36 +-
>  include/hw/timer/mc146818rtc_regs.h |  2 --
>  tests/rtc-test.c|  1 +
>  4 files changed, 39 insertions(+), 39 deletions(-)
> 

Queued, thanks.

Paolo



Re: [PATCH] aspeed: Add an AST2600 eval board

2019-10-22 Thread Peter Maydell
On Tue, 22 Oct 2019 at 18:16, Cédric Le Goater  wrote:
> Is it time for me to install an OSX system for dev and tests or is there
> a way to reproduce the issue ? no errors spotted in valgrind.

I dunno. You could have a look to see if you can repro
it with the travis builds. I would investigate but I
don't have time this week given impending softfreeze
and KVM Forum next week.

thanks
-- PMM



Re: [PATCH] aspeed: Add an AST2600 eval board

2019-10-22 Thread Peter Maydell
On Thu, 17 Oct 2019 at 14:54, Peter Maydell  wrote:
>
> On Thu, 17 Oct 2019 at 07:33, Joel Stanley  wrote:
> >
> > On Wed, 16 Oct 2019 at 09:08, Cédric Le Goater  wrote:
> > >
> > > Define the board with 1 GiB of RAM but some boards can have up to 2
> > > GiB.
> > >
> > > Signed-off-by: Cédric Le Goater 
> > > Reviewed-by: Joel Stanley 
> > > ---
> > >
> > >  Changes since AST2600 patchset:
> > >
> > >  - lowered the RAM size to 1 GiB as it was breaking the tests on some
> > >hosts.
> >
> > Peter,
> >
> > After chatting with Cédric I agree we should merge this patch.
> >
> > As it turns out the EVBs have differing amounts of RAM; his has 1GB
> > while mine has 2GB. So we are not being inaccurate by setting 1GB as
> > the default here.
>
> That's convenient, means we don't have to figure out how to
> special-case the test infrastructure for it :-)

This is now OK on the 32-bit boxes, but still fails 'make check'
on my OSX system:

manooth$ QTEST_QEMU_BINARY=aarch64-softmmu/qemu-system-aarch64
tests/qom-test -p /aarch64/qom/ast2600-evb
/aarch64/qom/ast2600-evb: Broken pipe
/Users/pm215/src/qemu-for-merges/tests/libqtest.c:149: kill_qemu()
detected QEMU death from signal 6 (Abort trap: 6)
Abort trap: 6

Dropping from the pullreq again :-(

thanks
-- PMM



Re: [PATCH v2 10/28] serial: add "base" property

2019-10-22 Thread Peter Maydell
On Tue, 22 Oct 2019 at 17:42, Marc-André Lureau
 wrote:
>
> Hi
>
> On Tue, Oct 22, 2019 at 6:32 PM Peter Maydell  
> wrote:
> >
> > On Tue, 22 Oct 2019 at 17:23, Marc-André Lureau
> >  wrote:
> > Devices shouldn't have properties to set their MMIO base
> > address -- instead the memory-mapped serial device should
> > be a child of TYPE_SYSBUS_DEVICE, and should provide
> > a sysbus mmio region, which users of the device can
> > map at the address they want to map the registers.
>
>
> Can we make serial a sysbus device? It seems to be embedded from
> various places, in various buses. Not sure that makes sense, please
> advise me :)

You want the SerialMMState to be is-a sysbus-device, and to
has-a SerialState, I think.

> "base" is mostly needed to set qdev_set_legacy_instance_id(), I should
> have added a commit comment. Otherwise, it can be passed to
> serial_mm_connect() directly.

serial_mm_connect() shouldn't exist at all, though -- we
want to end up with a normal sysbus device whose users
create it and wire up its MMIO and IRQ in the same way they
do any other sysbus device.

thanks
-- PMM



Re: Missing PVR setting capability

2019-10-22 Thread Wayne Li
And yes that is correct it has the e6500 core using PowerPC.

On Tue, Oct 22, 2019 at 11:24 AM Wayne Li  wrote:

> If I run "lsmod | grep kvm" nothing shows up but if I just do a "find .
> -name "kvm"" I get the following:
>
> ./usr/src/kernel/Documentation/virtual/kvm
> ./usr/src/kernel/arch/arm/kvm
> ./usr/src/kernel/arch/arm64/kvm
> ./usr/src/kernel/arch/mips/kvm
> ./usr/src/kernel/arch/powerpc/kvm
> ./usr/src/kernel/arch/s390/kvm
> ./usr/src/kernel/arch/tile/kvm
> ./usr/src/kernel/arch/x86/kvm
> ./usr/src/kernel/drivers/s390/kvm
> ./usr/src/kernel/include/config/kvm
> ./usr/src/kernel/include/config/have/kvm
> ./usr/src/kernel/include/kvm
> ./usr/src/kernel/virt/kvm
> ./dev/kvm
> ./sys/devices/virtual/misc/kvm
> ./sys/class/misc/kvm
> ./sys/kernel/debug/kvm
> ./sys/module/kvm
>
> I guess this shows my OS does have KVM on it?  I added the two flags you
> mentioned when running QEMU (the -cpu and the -machine flags) but the -cpu
> flag doesn't seem like it's doing anything as even when I put a clearly
> wrong argument after the flag no error related to the cpu is thrown.  Also
> it says ppce500 is not a machine type and that the supported machines are:
>
> bamboo   bamboo
> boeing-machine   Boeing Machine
> none empty machine
> ref405ep ref405ep
> taihutaihu
> virtex-ml507 Xilinx Virtex ML507 reference design
>
> The one being used right now is boeing-machine which is clearly specific
> to the project I am working on.  I'm not exactly sure what boeing-machine
> refers to but I'll ask the person who wrote the code that specified that
> machine,
>
> On Tue, Oct 22, 2019 at 2:04 AM Thomas Huth  wrote:
>
>> On 21/10/2019 23.06, Wayne Li wrote:
>> > Dear Qemu list members,
>> >
>> > I'm attempting to enable KVM in a Qemu-based project that is running on
>> > a T4240RDB board.  After compiling my code with the -enable-kvm option I
>> > ran the qemu executable with the -enable-kvm option.  The application
>> > exited with the following error message: "kvm error: missing PVR setting
>> > capability."  What are some possibilities causing this error?
>>
>> That's an e6500 bas PPC board, isn't it? ... I guess nobody has been
>> running KVM on such a system in a while...
>>
>> What do you get when running "lsmod | grep kvm" ? How did you run QEMU?
>> I think you have to make sure to run with the right CPU model ("-cpu
>> e6500") and machine (likely "-M ppce500" ?).
>>
>>  Thomas
>>
>>


[PATCH v2 28/28] Remove QDEV_PROP_PTR

2019-10-22 Thread Marc-André Lureau
No longer used in the tree. The comment about user_creatable is still
quite relevant, but there is already a similar comment in qdev-core.h.

Reviewed-by: Peter Maydell 
Signed-off-by: Marc-André Lureau 
---
 hw/core/qdev-properties.c| 18 --
 include/hw/qdev-properties.h | 22 --
 2 files changed, 40 deletions(-)

diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
index ac28890e5a..6ca7697599 100644
--- a/hw/core/qdev-properties.c
+++ b/hw/core/qdev-properties.c
@@ -501,13 +501,6 @@ const PropertyInfo qdev_prop_string = {
 .set   = set_string,
 };
 
-/* --- pointer --- */
-
-/* Not a proper property, just for dirty hacks.  TODO Remove it!  */
-const PropertyInfo qdev_prop_ptr = {
-.name  = "ptr",
-};
-
 /* --- mac address --- */
 
 /*
@@ -1165,17 +1158,6 @@ void qdev_prop_set_enum(DeviceState *dev, const char 
*name, int value)
 name, _abort);
 }
 
-void qdev_prop_set_ptr(DeviceState *dev, const char *name, void *value)
-{
-Property *prop;
-void **ptr;
-
-prop = qdev_prop_find(dev, name);
-assert(prop && prop->info == _prop_ptr);
-ptr = qdev_get_prop_ptr(dev, prop);
-*ptr = value;
-}
-
 static GPtrArray *global_props(void)
 {
 static GPtrArray *gp;
diff --git a/include/hw/qdev-properties.h b/include/hw/qdev-properties.h
index 16837ab5dd..a90a9cec80 100644
--- a/include/hw/qdev-properties.h
+++ b/include/hw/qdev-properties.h
@@ -18,7 +18,6 @@ extern const PropertyInfo qdev_prop_size;
 extern const PropertyInfo qdev_prop_string;
 extern const PropertyInfo qdev_prop_chr;
 extern const PropertyInfo qdev_prop_tpm;
-extern const PropertyInfo qdev_prop_ptr;
 extern const PropertyInfo qdev_prop_macaddr;
 extern const PropertyInfo qdev_prop_on_off_auto;
 extern const PropertyInfo qdev_prop_losttickpolicy;
@@ -171,25 +170,6 @@ extern const PropertyInfo qdev_prop_pcie_link_width;
 #define DEFINE_PROP_PCI_DEVFN(_n, _s, _f, _d)   \
 DEFINE_PROP_SIGNED(_n, _s, _f, _d, qdev_prop_pci_devfn, int32_t)
 
-/*
- * Please avoid pointer properties.  If you must use them, you must
- * cover them in their device's class init function as follows:
- *
- * - If the property must be set, the device cannot be used with
- *   device_add, so add code like this:
- *   |* Reason: pointer property "NAME-OF-YOUR-PROP" *|
- *   DeviceClass *dc = DEVICE_CLASS(class);
- *   dc->user_creatable = false;
- *
- * - If the property may safely remain null, document it like this:
- *   |*
- ** Note: pointer property "interrupt_vector" may remain null, thus
- ** no need for dc->user_creatable = false;
- **|
- */
-#define DEFINE_PROP_PTR(_n, _s, _f) \
-DEFINE_PROP(_n, _s, _f, qdev_prop_ptr, void*)
-
 #define DEFINE_PROP_CHR(_n, _s, _f) \
 DEFINE_PROP(_n, _s, _f, qdev_prop_chr, CharBackend)
 #define DEFINE_PROP_STRING(_n, _s, _f) \
@@ -262,8 +242,6 @@ void qdev_prop_set_drive(DeviceState *dev, const char *name,
 void qdev_prop_set_macaddr(DeviceState *dev, const char *name,
const uint8_t *value);
 void qdev_prop_set_enum(DeviceState *dev, const char *name, int value);
-/* FIXME: Remove opaque pointer properties.  */
-void qdev_prop_set_ptr(DeviceState *dev, const char *name, void *value);
 
 void qdev_prop_register_global(GlobalProperty *prop);
 int qdev_prop_check_globals(void);
-- 
2.23.0.606.g08da6496b6




Re: [PATCH RESEND v6 0/2] x86: Enable user wait instructions

2019-10-22 Thread Paolo Bonzini
On 11/10/19 09:41, Tao Xu wrote:
> UMONITOR, UMWAIT and TPAUSE are a set of user wait instructions.
> 
> UMONITOR arms address monitoring hardware using an address. A store
> to an address within the specified address range triggers the
> monitoring hardware to wake up the processor waiting in umwait.
> 
> UMWAIT instructs the processor to enter an implementation-dependent
> optimized state while monitoring a range of addresses. The optimized
> state may be either a light-weight power/performance optimized state
> (c0.1 state) or an improved power/performance optimized state
> (c0.2 state).
> 
> TPAUSE instructs the processor to enter an implementation-dependent
> optimized state c0.1 or c0.2 state and wake up when time-stamp counter
> reaches specified timeout.
> 
> Availability of the user wait instructions is indicated by the presence
> of the CPUID feature flag WAITPKG CPUID.0x07.0x0:ECX[5].
> 
> The patches enable the umonitor, umwait and tpause features in KVM.
> Because umwait and tpause can put a (psysical) CPU into a power saving
> state, by default we dont't expose it in kvm and provide a capability to
> enable it. Use kvm capability to enable UMONITOR, UMWAIT and TPAUSE when
> QEMU use "-overcommit cpu-pm=on, a VM can use UMONITOR, UMWAIT and TPAUSE
> instructions. If the instruction causes a delay, the amount of time
> delayed is called here the physical delay. The physical delay is first
> computed by determining the virtual delay (the time to delay relative to
> the VM’s timestamp counter). Otherwise, UMONITOR, UMWAIT and TPAUSE cause
> an invalid-opcode exception(#UD).
> 
> The release document ref below link:
> https://software.intel.com/sites/default/files/\
> managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf
> 
> Changelog:
> v6:
>   Remove CPUID_7_0_ECX_WAITPKG if enable_cpu_pm is not set.
> (Paolo)
> 
> Tao Xu (2):
>   x86/cpu: Add support for UMONITOR/UMWAIT/TPAUSE
>   target/i386: Add support for save/load IA32_UMWAIT_CONTROL MSR
> 
>  target/i386/cpu.c |  2 +-
>  target/i386/cpu.h |  3 +++
>  target/i386/kvm.c | 19 +++
>  target/i386/machine.c | 20 
>  4 files changed, 43 insertions(+), 1 deletion(-)
> 

Queued, thanks.

Paolo



Re: [PATCH] hw/timer/mc146818rtc: Only include qapi-commands-misc on I386

2019-10-22 Thread Paolo Bonzini
On 17/10/19 18:26, Philippe Mathieu-Daudé wrote:
> Commit a6c7040fb09 restricted the rtc-reset-reinjection command
> to the I386 target.
> Restrict the "qapi/qapi-commands-misc-target.h" header to it too.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/timer/mc146818rtc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/timer/mc146818rtc.c b/hw/timer/mc146818rtc.c
> index 6cb378751b..c1eb0a7376 100644
> --- a/hw/timer/mc146818rtc.c
> +++ b/hw/timer/mc146818rtc.c
> @@ -37,12 +37,12 @@
>  #include "hw/timer/mc146818rtc.h"
>  #include "migration/vmstate.h"
>  #include "qapi/error.h"
> -#include "qapi/qapi-commands-misc-target.h"
>  #include "qapi/qapi-events-misc-target.h"
>  #include "qapi/visitor.h"
>  #include "exec/address-spaces.h"
>  
>  #ifdef TARGET_I386
> +#include "qapi/qapi-commands-misc-target.h"
>  #include "hw/i386/apic.h"
>  #endif
>  
> 

Queued, thanks.

Paolo



[PATCH v2 27/28] qdev: remove PROP_MEMORY_REGION

2019-10-22 Thread Marc-André Lureau
PROP_MEMORY_REGION was a derivative of PROP_PTR, added in commit
ed03d749f3f513b8fb0287757cfda2cb6825f063 (qdev: add MemoryRegion
property) and thankfully no longer needed since commit
3eff40dbf44896a8180c86c84dbdefb2eb173fbe (hw/misc: Remove
mmio_interface device).

Signed-off-by: Marc-André Lureau 
Reviewed-by: Peter Maydell 
---
 include/hw/qdev-properties.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/hw/qdev-properties.h b/include/hw/qdev-properties.h
index c6a8cb5516..16837ab5dd 100644
--- a/include/hw/qdev-properties.h
+++ b/include/hw/qdev-properties.h
@@ -216,8 +216,6 @@ extern const PropertyInfo qdev_prop_pcie_link_width;
 DEFINE_PROP_UNSIGNED(_n, _s, _f, 0, qdev_prop_blocksize, uint16_t)
 #define DEFINE_PROP_PCI_HOST_DEVADDR(_n, _s, _f) \
 DEFINE_PROP(_n, _s, _f, qdev_prop_pci_host_devaddr, PCIHostDeviceAddress)
-#define DEFINE_PROP_MEMORY_REGION(_n, _s, _f) \
-DEFINE_PROP(_n, _s, _f, qdev_prop_ptr, MemoryRegion *)
 #define DEFINE_PROP_OFF_AUTO_PCIBAR(_n, _s, _f, _d) \
 DEFINE_PROP_SIGNED(_n, _s, _f, _d, qdev_prop_off_auto_pcibar, \
 OffAutoPCIBAR)
-- 
2.23.0.606.g08da6496b6




[PATCH v2 26/28] omap-gpio: remove PROP_PTR

2019-10-22 Thread Marc-André Lureau
Since clocks are not QOM objects, replace PROP_PTR of clocks with
setters methods.

Move/adapt the existing TODO comment about a clock framework.

Reviewed-by: Peter Maydell 
Signed-off-by: Marc-André Lureau 
---
 hw/arm/omap1.c|  2 +-
 hw/arm/omap2.c| 13 +++--
 hw/gpio/omap_gpio.c   | 42 +++---
 include/hw/arm/omap.h | 33 +
 4 files changed, 52 insertions(+), 38 deletions(-)

diff --git a/hw/arm/omap1.c b/hw/arm/omap1.c
index fe55c44c7e..f13d46afaa 100644
--- a/hw/arm/omap1.c
+++ b/hw/arm/omap1.c
@@ -4014,7 +4014,7 @@ struct omap_mpu_state_s *omap310_mpu_init(MemoryRegion 
*system_memory,
 
 s->gpio = qdev_create(NULL, "omap-gpio");
 qdev_prop_set_int32(s->gpio, "mpu_model", s->mpu_model);
-qdev_prop_set_ptr(s->gpio, "clk", omap_findclk(s, "arm_gpio_ck"));
+omap_gpio_set_clk(OMAP1_GPIO(s->gpio), omap_findclk(s, "arm_gpio_ck"));
 qdev_init_nofail(s->gpio);
 sysbus_connect_irq(SYS_BUS_DEVICE(s->gpio), 0,
qdev_get_gpio_in(s->ih[0], OMAP_INT_GPIO_BANK1));
diff --git a/hw/arm/omap2.c b/hw/arm/omap2.c
index 046fb6ffb5..d5c20f6486 100644
--- a/hw/arm/omap2.c
+++ b/hw/arm/omap2.c
@@ -2452,13 +2452,14 @@ struct omap_mpu_state_s *omap2420_mpu_init(MemoryRegion 
*sysmem,
 
 s->gpio = qdev_create(NULL, "omap2-gpio");
 qdev_prop_set_int32(s->gpio, "mpu_model", s->mpu_model);
-qdev_prop_set_ptr(s->gpio, "iclk", omap_findclk(s, "gpio_iclk"));
-qdev_prop_set_ptr(s->gpio, "fclk0", omap_findclk(s, "gpio1_dbclk"));
-qdev_prop_set_ptr(s->gpio, "fclk1", omap_findclk(s, "gpio2_dbclk"));
-qdev_prop_set_ptr(s->gpio, "fclk2", omap_findclk(s, "gpio3_dbclk"));
-qdev_prop_set_ptr(s->gpio, "fclk3", omap_findclk(s, "gpio4_dbclk"));
+omap2_gpio_set_iclk(OMAP2_GPIO(s->gpio), omap_findclk(s, "gpio_iclk"));
+omap2_gpio_set_fclk(OMAP2_GPIO(s->gpio), 0, omap_findclk(s, 
"gpio1_dbclk"));
+omap2_gpio_set_fclk(OMAP2_GPIO(s->gpio), 1, omap_findclk(s, 
"gpio2_dbclk"));
+omap2_gpio_set_fclk(OMAP2_GPIO(s->gpio), 2, omap_findclk(s, 
"gpio3_dbclk"));
+omap2_gpio_set_fclk(OMAP2_GPIO(s->gpio), 3, omap_findclk(s, 
"gpio4_dbclk"));
 if (s->mpu_model == omap2430) {
-qdev_prop_set_ptr(s->gpio, "fclk4", omap_findclk(s, "gpio5_dbclk"));
+omap2_gpio_set_fclk(OMAP2_GPIO(s->gpio), 4,
+omap_findclk(s, "gpio5_dbclk"));
 }
 qdev_init_nofail(s->gpio);
 busdev = SYS_BUS_DEVICE(s->gpio);
diff --git a/hw/gpio/omap_gpio.c b/hw/gpio/omap_gpio.c
index 41e1aa798c..85c16897ae 100644
--- a/hw/gpio/omap_gpio.c
+++ b/hw/gpio/omap_gpio.c
@@ -40,10 +40,6 @@ struct omap_gpio_s {
 uint16_t pins;
 };
 
-#define TYPE_OMAP1_GPIO "omap-gpio"
-#define OMAP1_GPIO(obj) \
-OBJECT_CHECK(struct omap_gpif_s, (obj), TYPE_OMAP1_GPIO)
-
 struct omap_gpif_s {
 SysBusDevice parent_obj;
 
@@ -212,10 +208,6 @@ struct omap2_gpio_s {
 uint8_t delay;
 };
 
-#define TYPE_OMAP2_GPIO "omap2-gpio"
-#define OMAP2_GPIO(obj) \
-OBJECT_CHECK(struct omap2_gpif_s, (obj), TYPE_OMAP2_GPIO)
-
 struct omap2_gpif_s {
 SysBusDevice parent_obj;
 
@@ -747,21 +739,13 @@ static void omap2_gpio_realize(DeviceState *dev, Error 
**errp)
 }
 }
 
-/* Using qdev pointer properties for the clocks is not ideal.
- * qdev should support a generic means of defining a 'port' with
- * an arbitrary interface for connecting two devices. Then we
- * could reframe the omap clock API in terms of clock ports,
- * and get some type safety. For now the best qdev provides is
- * passing an arbitrary pointer.
- * (It's not possible to pass in the string which is the clock
- * name, because this device does not have the necessary information
- * (ie the struct omap_mpu_state_s*) to do the clockname to pointer
- * translation.)
- */
+void omap_gpio_set_clk(omap_gpif *gpio, omap_clk clk)
+{
+gpio->clk = clk;
+}
 
 static Property omap_gpio_properties[] = {
 DEFINE_PROP_INT32("mpu_model", struct omap_gpif_s, mpu_model, 0),
-DEFINE_PROP_PTR("clk", struct omap_gpif_s, clk),
 DEFINE_PROP_END_OF_LIST(),
 };
 
@@ -784,15 +768,19 @@ static const TypeInfo omap_gpio_info = {
 .class_init= omap_gpio_class_init,
 };
 
+void omap2_gpio_set_iclk(omap2_gpif *gpio, omap_clk clk)
+{
+gpio->iclk = clk;
+}
+
+void omap2_gpio_set_fclk(omap2_gpif *gpio, uint8_t i, omap_clk clk)
+{
+assert(i <= 5);
+gpio->fclk[i] = clk;
+}
+
 static Property omap2_gpio_properties[] = {
 DEFINE_PROP_INT32("mpu_model", struct omap2_gpif_s, mpu_model, 0),
-DEFINE_PROP_PTR("iclk", struct omap2_gpif_s, iclk),
-DEFINE_PROP_PTR("fclk0", struct omap2_gpif_s, fclk[0]),
-DEFINE_PROP_PTR("fclk1", struct omap2_gpif_s, fclk[1]),
-DEFINE_PROP_PTR("fclk2", struct omap2_gpif_s, fclk[2]),
-DEFINE_PROP_PTR("fclk3", struct omap2_gpif_s, fclk[3]),
-DEFINE_PROP_PTR("fclk4", struct omap2_gpif_s, fclk[4]),
-DEFINE_PROP_PTR("fclk5", struct omap2_gpif_s, fclk[5]),

Re: Missing PVR setting capability

2019-10-22 Thread Wayne Li
If I run "lsmod | grep kvm" nothing shows up but if I just do a "find .
-name "kvm"" I get the following:

./usr/src/kernel/Documentation/virtual/kvm
./usr/src/kernel/arch/arm/kvm
./usr/src/kernel/arch/arm64/kvm
./usr/src/kernel/arch/mips/kvm
./usr/src/kernel/arch/powerpc/kvm
./usr/src/kernel/arch/s390/kvm
./usr/src/kernel/arch/tile/kvm
./usr/src/kernel/arch/x86/kvm
./usr/src/kernel/drivers/s390/kvm
./usr/src/kernel/include/config/kvm
./usr/src/kernel/include/config/have/kvm
./usr/src/kernel/include/kvm
./usr/src/kernel/virt/kvm
./dev/kvm
./sys/devices/virtual/misc/kvm
./sys/class/misc/kvm
./sys/kernel/debug/kvm
./sys/module/kvm

I guess this shows my OS does have KVM on it?  I added the two flags you
mentioned when running QEMU (the -cpu and the -machine flags) but the -cpu
flag doesn't seem like it's doing anything as even when I put a clearly
wrong argument after the flag no error related to the cpu is thrown.  Also
it says ppce500 is not a machine type and that the supported machines are:

bamboo   bamboo
boeing-machine   Boeing Machine
none empty machine
ref405ep ref405ep
taihutaihu
virtex-ml507 Xilinx Virtex ML507 reference design

The one being used right now is boeing-machine which is clearly specific to
the project I am working on.  I'm not exactly sure what boeing-machine
refers to but I'll ask the person who wrote the code that specified that
machine,

On Tue, Oct 22, 2019 at 2:04 AM Thomas Huth  wrote:

> On 21/10/2019 23.06, Wayne Li wrote:
> > Dear Qemu list members,
> >
> > I'm attempting to enable KVM in a Qemu-based project that is running on
> > a T4240RDB board.  After compiling my code with the -enable-kvm option I
> > ran the qemu executable with the -enable-kvm option.  The application
> > exited with the following error message: "kvm error: missing PVR setting
> > capability."  What are some possibilities causing this error?
>
> That's an e6500 bas PPC board, isn't it? ... I guess nobody has been
> running KVM on such a system in a while...
>
> What do you get when running "lsmod | grep kvm" ? How did you run QEMU?
> I think you have to make sure to run with the right CPU model ("-cpu
> e6500") and machine (likely "-M ppce500" ?).
>
>  Thomas
>
>


[PATCH v5 0/7] ppc: reset the interrupt presenter from the CPU reset handler

2019-10-22 Thread Cédric Le Goater
Hello,

On the sPAPR machine and PowerNV machine, the interrupt presenters are
created by a machine handler at the core level and are reseted
independently. This is not consistent and it raises issues when it
comes to handle hot-plugged CPUs. In that case, the presenters are not
reseted. This is less of an issue in XICS, although a zero MFFR could
be a concern, but in XIVE, the OS CAM line is not set and this breaks
the presenting algorithm. The current code has workarounds which need
a global cleanup.

Extend the sPAPR IRQ backend and the PowerNV Chip class with a new
cpu_intc_reset() handler called by the CPU reset handler and remove
the XiveTCTX reset handler which is now redundant.

Set the OS CAM line when the interrupt presenter of the sPAPR core is
reseted. This will also cover the case of hot-plugged CPUs.

Thanks,

C.

Changes in v5:

 - Removed useless PNV_CHIP() cast
 
Changes in v4:

 - Introduce a PnvCore reset handler
 - Add PnvChip pointer to PnvCore

Changes in v3:

 - Introduced a DeviceClass::reset for the CPU (Greg)
 - add support for PowerNV
 
Changes in v2:

 - removed property
 - simplified reset handlers

Cédric Le Goater (6):
  spapr: move CPU reset after presenter creation
  ppc/pnv: Introduce a PnvCore reset handler
  ppc/pnv: Add a PnvChip pointer to PnvCore
  ppc: Reset the interrupt presenter from the CPU reset handler
  ppc/pnv: Fix naming of routines realizing the CPUs
  spapr/xive: Set the OS CAM line at reset

Greg Kurz (1):
  spapr_cpu_core: Implement DeviceClass::reset

 include/hw/ppc/pnv.h|  1 +
 include/hw/ppc/pnv_core.h   |  3 +++
 include/hw/ppc/spapr_irq.h  |  2 ++
 include/hw/ppc/spapr_xive.h |  1 -
 include/hw/ppc/xics.h   |  1 +
 include/hw/ppc/xive.h   |  1 +
 hw/intc/spapr_xive.c| 53 +
 hw/intc/xics.c  |  8 ++
 hw/intc/xics_spapr.c|  7 +
 hw/intc/xive.c  | 12 +
 hw/ppc/pnv.c| 18 +
 hw/ppc/pnv_core.c   | 31 --
 hw/ppc/spapr_cpu_core.c | 44 +++---
 hw/ppc/spapr_irq.c  | 14 ++
 14 files changed, 131 insertions(+), 65 deletions(-)

-- 
2.21.0




[PULL v3 00/18] target-arm queue

2019-10-22 Thread Peter Maydell
Changes v2->v3:
dropped the aspeed new board patch as it fails in
tests/qom-test on OSX (intermittently).

thanks
-- PMM

The following changes since commit f9bec781379dd7ccf9d01b4b6a79a9ec82c192e5:

  Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20191022' into 
staging (2019-10-22 13:45:09 +0100)

are available in the Git repository at:

  https://git.linaro.org/people/pmaydell/qemu-arm.git 
tags/pull-target-arm-20191022-2

for you to fetch changes up to 90600829b3355b8d27b791b893095c18f529aec3:

  hw/arm/digic4: Inline digic4_board_setup_ram() function (2019-10-22 17:44:01 
+0100)


 * Fix sign-extension for SMLAL* instructions
 * Various ptimer device conversions to new transaction API
 * Add a dummy Samsung SDHCI controller model to exynos4 boards
 * Minor refactorings of RAM creation for some arm boards


Guenter Roeck (1):
  hw/timer/exynos4210_mct: Initialize ptimer before starting it

Peter Maydell (7):
  hw/timer/arm_mptimer.c: Undo accidental rename of arm_mptimer_init()
  hw/timer/puv3_ost.c: Switch to transaction-based ptimer API
  hw/timer/sh_timer: Switch to transaction-based ptimer API
  hw/timer/lm32_timer: Switch to transaction-based ptimer API
  hw/timer/altera_timer.c: Switch to transaction-based ptimer API
  hw/watchdog/etraxfs_timer.c: Switch to transaction-based ptimer API
  hw/m68k/mcf5208.c: Switch to transaction-based ptimer API

Philippe Mathieu-Daudé (9):
  hw/sd/sdhci: Add a comment to distinct the i.MX eSDHC functions
  hw/sd/sdhci: Add dummy Samsung SDHCI controller
  hw/arm/exynos4210: Use the Samsung s3c SDHCI controller
  hw/arm/xilinx_zynq: Use the IEC binary prefix definitions
  hw/arm/mps2: Use the IEC binary prefix definitions
  hw/arm/collie: Create the RAM in the board
  hw/arm/omap2: Create the RAM in the board
  hw/arm/omap1: Create the RAM in the board
  hw/arm/digic4: Inline digic4_board_setup_ram() function

Richard Henderson (1):
  target/arm: Fix sign-extension for SMLAL*

 hw/arm/strongarm.h|  4 +--
 include/hw/arm/omap.h | 10 +++
 include/hw/sd/sdhci.h |  2 ++
 hw/arm/collie.c   |  8 --
 hw/arm/digic_boards.c |  9 ++-
 hw/arm/exynos4210.c   |  2 +-
 hw/arm/mps2-tz.c  |  3 ++-
 hw/arm/mps2.c |  3 ++-
 hw/arm/nseries.c  | 10 ---
 hw/arm/omap1.c| 12 -
 hw/arm/omap2.c| 13 -
 hw/arm/omap_sx1.c |  8 --
 hw/arm/palm.c |  8 --
 hw/arm/strongarm.c|  7 +
 hw/arm/xilinx_zynq.c  |  3 ++-
 hw/m68k/mcf5208.c |  9 ---
 hw/sd/sdhci.c | 68 ++-
 hw/timer/altera_timer.c   | 13 ++---
 hw/timer/arm_mptimer.c|  4 +--
 hw/timer/etraxfs_timer.c  | 23 +---
 hw/timer/exynos4210_mct.c |  2 +-
 hw/timer/lm32_timer.c | 13 ++---
 hw/timer/puv3_ost.c   |  9 ---
 hw/timer/sh_timer.c   | 13 ++---
 target/arm/translate.c|  4 ++-
 25 files changed, 174 insertions(+), 86 deletions(-)



[PATCH v5 2/7] spapr_cpu_core: Implement DeviceClass::reset

2019-10-22 Thread Cédric Le Goater
From: Greg Kurz 

Since vCPUs aren't plugged into a bus, we manually register a reset
handler for each vCPU. We also call this handler at realize time
to ensure hot plugged vCPUs are reset before being exposed to the
guest. This results in vCPUs being reset twice at machine reset.
It doesn't break anything but it is slightly suboptimal and above
all confusing.

The hotplug path in device_set_realized() already knows how to reset
a hotplugged device if the device reset handler is present. Implement
one for sPAPR CPU cores that resets all vCPUs under a core.

While here rename spapr_cpu_reset() to spapr_reset_vcpu() for
consistency with spapr_realize_vcpu() and spapr_unrealize_vcpu().

Signed-off-by: Greg Kurz 
Reviewed-by: Philippe Mathieu-Daudé 
[clg: add documentation on the reset helper usage ]
Signed-off-by: Cédric Le Goater 
---
 hw/ppc/spapr_cpu_core.c | 37 -
 1 file changed, 28 insertions(+), 9 deletions(-)

diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
index 2b21285d2009..2e34832d0ea2 100644
--- a/hw/ppc/spapr_cpu_core.c
+++ b/hw/ppc/spapr_cpu_core.c
@@ -25,9 +25,8 @@
 #include "sysemu/hw_accel.h"
 #include "qemu/error-report.h"
 
-static void spapr_cpu_reset(void *opaque)
+static void spapr_reset_vcpu(PowerPCCPU *cpu)
 {
-PowerPCCPU *cpu = opaque;
 CPUState *cs = CPU(cpu);
 CPUPPCState *env = >env;
 PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
@@ -193,7 +192,6 @@ static void spapr_unrealize_vcpu(PowerPCCPU *cpu, 
SpaprCpuCore *sc)
 if (!sc->pre_3_0_migration) {
 vmstate_unregister(NULL, _spapr_cpu_state, cpu->machine_data);
 }
-qemu_unregister_reset(spapr_cpu_reset, cpu);
 if (spapr_cpu_state(cpu)->icp) {
 object_unparent(OBJECT(spapr_cpu_state(cpu)->icp));
 }
@@ -204,12 +202,36 @@ static void spapr_unrealize_vcpu(PowerPCCPU *cpu, 
SpaprCpuCore *sc)
 object_unparent(OBJECT(cpu));
 }
 
+/*
+ * Called when CPUs are hot-plugged.
+ */
+static void spapr_cpu_core_reset(DeviceState *dev)
+{
+CPUCore *cc = CPU_CORE(dev);
+SpaprCpuCore *sc = SPAPR_CPU_CORE(dev);
+int i;
+
+for (i = 0; i < cc->nr_threads; i++) {
+spapr_reset_vcpu(sc->threads[i]);
+}
+}
+
+/*
+ * Called by the machine reset.
+ */
+static void spapr_cpu_core_reset_handler(void *opaque)
+{
+spapr_cpu_core_reset(opaque);
+}
+
 static void spapr_cpu_core_unrealize(DeviceState *dev, Error **errp)
 {
 SpaprCpuCore *sc = SPAPR_CPU_CORE(OBJECT(dev));
 CPUCore *cc = CPU_CORE(dev);
 int i;
 
+qemu_unregister_reset(spapr_cpu_core_reset_handler, sc);
+
 for (i = 0; i < cc->nr_threads; i++) {
 spapr_unrealize_vcpu(sc->threads[i], sc);
 }
@@ -238,12 +260,6 @@ static void spapr_realize_vcpu(PowerPCCPU *cpu, 
SpaprMachineState *spapr,
 goto error_intc_create;
 }
 
-/*
- * FIXME: Hot-plugged CPUs are not reset. Do it at realize.
- */
-qemu_register_reset(spapr_cpu_reset, cpu);
-spapr_cpu_reset(cpu);
-
 if (!sc->pre_3_0_migration) {
 vmstate_register(NULL, cs->cpu_index, _spapr_cpu_state,
  cpu->machine_data);
@@ -338,6 +354,8 @@ static void spapr_cpu_core_realize(DeviceState *dev, Error 
**errp)
 goto err_unrealize;
 }
 }
+
+qemu_register_reset(spapr_cpu_core_reset_handler, sc);
 return;
 
 err_unrealize:
@@ -366,6 +384,7 @@ static void spapr_cpu_core_class_init(ObjectClass *oc, void 
*data)
 
 dc->realize = spapr_cpu_core_realize;
 dc->unrealize = spapr_cpu_core_unrealize;
+dc->reset = spapr_cpu_core_reset;
 dc->props = spapr_cpu_core_properties;
 scc->cpu_type = data;
 }
-- 
2.21.0




[PATCH v5 4/7] ppc/pnv: Add a PnvChip pointer to PnvCore

2019-10-22 Thread Cédric Le Goater
We will use it to reset the interrupt presenter from the CPU reset
handler.

Signed-off-by: Cédric Le Goater 
Reviewed-by: Greg Kurz 
---
 include/hw/ppc/pnv_core.h | 3 +++
 hw/ppc/pnv_core.c | 3 ++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/hw/ppc/pnv_core.h b/include/hw/ppc/pnv_core.h
index bfbd2ec42aa6..55eee95104da 100644
--- a/include/hw/ppc/pnv_core.h
+++ b/include/hw/ppc/pnv_core.h
@@ -31,6 +31,8 @@
 #define PNV_CORE_GET_CLASS(obj) \
  OBJECT_GET_CLASS(PnvCoreClass, (obj), TYPE_PNV_CORE)
 
+typedef struct PnvChip PnvChip;
+
 typedef struct PnvCore {
 /*< private >*/
 CPUCore parent_obj;
@@ -38,6 +40,7 @@ typedef struct PnvCore {
 /*< public >*/
 PowerPCCPU **threads;
 uint32_t pir;
+PnvChip *chip;
 
 MemoryRegion xscom_regs;
 } PnvCore;
diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
index 9f981a4940e6..cc17bbfed829 100644
--- a/hw/ppc/pnv_core.c
+++ b/hw/ppc/pnv_core.c
@@ -222,6 +222,7 @@ static void pnv_core_realize(DeviceState *dev, Error **errp)
 "required link 'chip' not found: ");
 return;
 }
+pc->chip = PNV_CHIP(chip);
 
 pc->threads = g_new(PowerPCCPU *, cc->nr_threads);
 for (i = 0; i < cc->nr_threads; i++) {
@@ -243,7 +244,7 @@ static void pnv_core_realize(DeviceState *dev, Error **errp)
 }
 
 for (j = 0; j < cc->nr_threads; j++) {
-pnv_realize_vcpu(pc->threads[j], PNV_CHIP(chip), _err);
+pnv_realize_vcpu(pc->threads[j], pc->chip, _err);
 if (local_err) {
 goto err;
 }
-- 
2.21.0




[PATCH v5 3/7] ppc/pnv: Introduce a PnvCore reset handler

2019-10-22 Thread Cédric Le Goater
in which individual CPUs are reset. It will ease the introduction of
future change reseting the interrupt presenter from the CPU reset
handler.

Signed-off-by: Cédric Le Goater 
Reviewed-by: Greg Kurz 
---
 hw/ppc/pnv_core.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
index b1a7489e7abf..9f981a4940e6 100644
--- a/hw/ppc/pnv_core.c
+++ b/hw/ppc/pnv_core.c
@@ -40,9 +40,8 @@ static const char *pnv_core_cpu_typename(PnvCore *pc)
 return cpu_type;
 }
 
-static void pnv_cpu_reset(void *opaque)
+static void pnv_core_cpu_reset(PowerPCCPU *cpu)
 {
-PowerPCCPU *cpu = opaque;
 CPUState *cs = CPU(cpu);
 CPUPPCState *env = >env;
 
@@ -192,8 +191,17 @@ static void pnv_realize_vcpu(PowerPCCPU *cpu, PnvChip 
*chip, Error **errp)
 
 /* Set time-base frequency to 512 MHz */
 cpu_ppc_tb_init(env, PNV_TIMEBASE_FREQ);
+}
+
+static void pnv_core_reset(void *dev)
+{
+CPUCore *cc = CPU_CORE(dev);
+PnvCore *pc = PNV_CORE(dev);
+int i;
 
-qemu_register_reset(pnv_cpu_reset, cpu);
+for (i = 0; i < cc->nr_threads; i++) {
+pnv_core_cpu_reset(pc->threads[i]);
+}
 }
 
 static void pnv_core_realize(DeviceState *dev, Error **errp)
@@ -244,6 +252,8 @@ static void pnv_core_realize(DeviceState *dev, Error **errp)
 snprintf(name, sizeof(name), "xscom-core.%d", cc->core_id);
 pnv_xscom_region_init(>xscom_regs, OBJECT(dev), pcc->xscom_ops,
   pc, name, PNV_XSCOM_EX_SIZE);
+
+qemu_register_reset(pnv_core_reset, pc);
 return;
 
 err:
@@ -259,7 +269,6 @@ static void pnv_unrealize_vcpu(PowerPCCPU *cpu)
 {
 PnvCPUState *pnv_cpu = pnv_cpu_state(cpu);
 
-qemu_unregister_reset(pnv_cpu_reset, cpu);
 object_unparent(OBJECT(pnv_cpu_state(cpu)->intc));
 cpu_remove_sync(CPU(cpu));
 cpu->machine_data = NULL;
@@ -273,6 +282,8 @@ static void pnv_core_unrealize(DeviceState *dev, Error 
**errp)
 CPUCore *cc = CPU_CORE(dev);
 int i;
 
+qemu_unregister_reset(pnv_core_reset, pc);
+
 for (i = 0; i < cc->nr_threads; i++) {
 pnv_unrealize_vcpu(pc->threads[i]);
 }
-- 
2.21.0




Re: [PATCH v2 10/28] serial: add "base" property

2019-10-22 Thread Marc-André Lureau
Hi

On Tue, Oct 22, 2019 at 6:32 PM Peter Maydell  wrote:
>
> On Tue, 22 Oct 2019 at 17:23, Marc-André Lureau
>  wrote:
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >  hw/char/serial.c | 3 +++
> >  include/hw/char/serial.h | 1 +
> >  2 files changed, 4 insertions(+)
> >
> > diff --git a/hw/char/serial.c b/hw/char/serial.c
> > index 0ae52ec60c..4748a2b023 100644
> > --- a/hw/char/serial.c
> > +++ b/hw/char/serial.c
> > @@ -990,6 +990,7 @@ SerialState *serial_init(int base, qemu_irq irq, int 
> > baudbase,
> >  qdev_connect_gpio_out_named(dev, "serial-irq", 0, irq);
> >  qdev_prop_set_uint32(dev, "baudbase", baudbase);
> >  qdev_prop_set_chr(dev, "chardev", chr);
> > +qdev_prop_set_uint64(dev, "base", base);
> >  serial_realize_core(s, _fatal);
> >  qdev_set_legacy_instance_id(dev, base, 2);
> >  qdev_init_nofail(dev);
> > @@ -1003,6 +1004,7 @@ SerialState *serial_init(int base, qemu_irq irq, int 
> > baudbase,
> >  static Property serial_properties[] = {
> >  DEFINE_PROP_CHR("chardev", SerialState, chr),
> >  DEFINE_PROP_UINT32("baudbase", SerialState, baudbase, 115200),
> > +DEFINE_PROP_UINT64("base", SerialState, base, 0),
> >  DEFINE_PROP_END_OF_LIST(),
> >  };
> >
> > @@ -1083,6 +1085,7 @@ SerialState *serial_mm_init(MemoryRegion 
> > *address_space,
> >  qdev_prop_set_uint32(dev, "baudbase", baudbase);
> >  qdev_prop_set_chr(dev, "chardev", chr);
> >  qdev_prop_set_uint8(dev, "regshift", regshift);
> > +qdev_prop_set_uint64(dev, "base", base);
> >
> >  serial_realize_core(s, _fatal);
> >  qdev_set_legacy_instance_id(DEVICE(s), base, 2);
> > diff --git a/include/hw/char/serial.h b/include/hw/char/serial.h
> > index ecbd3f1b40..6e9c9768ed 100644
> > --- a/include/hw/char/serial.h
> > +++ b/include/hw/char/serial.h
> > @@ -77,6 +77,7 @@ typedef struct SerialState {
> >
> >  QEMUTimer *modem_status_poll;
> >  MemoryRegion io;
> > +uint64_t base;
> >  } SerialState;
>
> Devices shouldn't have properties to set their MMIO base
> address -- instead the memory-mapped serial device should
> be a child of TYPE_SYSBUS_DEVICE, and should provide
> a sysbus mmio region, which users of the device can
> map at the address they want to map the registers.


Can we make serial a sysbus device? It seems to be embedded from
various places, in various buses. Not sure that makes sense, please
advise me :)

"base" is mostly needed to set qdev_set_legacy_instance_id(), I should
have added a commit comment. Otherwise, it can be passed to
serial_mm_connect() directly.



[PATCH v5 5/7] ppc: Reset the interrupt presenter from the CPU reset handler

2019-10-22 Thread Cédric Le Goater
On the sPAPR machine and PowerNV machine, the interrupt presenters are
created by a machine handler at the core level and are reset
independently. This is not consistent and it raises issues when it
comes to handle hot-plugged CPUs. In that case, the presenters are not
reset. This is less of an issue in XICS, although a zero MFFR could
be a concern, but in XIVE, the OS CAM line is not set and this breaks
the presenting algorithm. The current code has workarounds which need
a global cleanup.

Extend the sPAPR IRQ backend and the PowerNV Chip class with a new
cpu_intc_reset() handler called by the CPU reset handler and remove
the XiveTCTX reset handler which is now redundant.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/pnv.h   |  1 +
 include/hw/ppc/spapr_irq.h |  2 ++
 include/hw/ppc/xics.h  |  1 +
 include/hw/ppc/xive.h  |  1 +
 hw/intc/spapr_xive.c   |  9 +
 hw/intc/xics.c |  8 ++--
 hw/intc/xics_spapr.c   |  7 +++
 hw/intc/xive.c | 12 +---
 hw/ppc/pnv.c   | 18 ++
 hw/ppc/pnv_core.c  |  7 +--
 hw/ppc/spapr_cpu_core.c|  5 -
 hw/ppc/spapr_irq.c | 14 ++
 12 files changed, 65 insertions(+), 20 deletions(-)

diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
index 1cdbe55bf86c..2a780e633f23 100644
--- a/include/hw/ppc/pnv.h
+++ b/include/hw/ppc/pnv.h
@@ -111,6 +111,7 @@ typedef struct PnvChipClass {
 
 uint32_t (*core_pir)(PnvChip *chip, uint32_t core_id);
 void (*intc_create)(PnvChip *chip, PowerPCCPU *cpu, Error **errp);
+void (*intc_reset)(PnvChip *chip, PowerPCCPU *cpu);
 ISABus *(*isa_create)(PnvChip *chip, Error **errp);
 void (*dt_populate)(PnvChip *chip, void *fdt);
 void (*pic_print_info)(PnvChip *chip, Monitor *mon);
diff --git a/include/hw/ppc/spapr_irq.h b/include/hw/ppc/spapr_irq.h
index 5e150a667902..09232999b07e 100644
--- a/include/hw/ppc/spapr_irq.h
+++ b/include/hw/ppc/spapr_irq.h
@@ -52,6 +52,7 @@ typedef struct SpaprInterruptControllerClass {
  */
 int (*cpu_intc_create)(SpaprInterruptController *intc,
 PowerPCCPU *cpu, Error **errp);
+void (*cpu_intc_reset)(SpaprInterruptController *intc, PowerPCCPU *cpu);
 int (*claim_irq)(SpaprInterruptController *intc, int irq, bool lsi,
  Error **errp);
 void (*free_irq)(SpaprInterruptController *intc, int irq);
@@ -68,6 +69,7 @@ void spapr_irq_update_active_intc(SpaprMachineState *spapr);
 
 int spapr_irq_cpu_intc_create(SpaprMachineState *spapr,
   PowerPCCPU *cpu, Error **errp);
+void spapr_irq_cpu_intc_reset(SpaprMachineState *spapr, PowerPCCPU *cpu);
 void spapr_irq_print_info(SpaprMachineState *spapr, Monitor *mon);
 void spapr_irq_dt(SpaprMachineState *spapr, uint32_t nr_servers,
   void *fdt, uint32_t phandle);
diff --git a/include/hw/ppc/xics.h b/include/hw/ppc/xics.h
index 1e6a9300eb2b..602173c12250 100644
--- a/include/hw/ppc/xics.h
+++ b/include/hw/ppc/xics.h
@@ -161,6 +161,7 @@ void icp_set_mfrr(ICPState *icp, uint8_t mfrr);
 uint32_t icp_accept(ICPState *ss);
 uint32_t icp_ipoll(ICPState *ss, uint32_t *mfrr);
 void icp_eoi(ICPState *icp, uint32_t xirr);
+void icp_reset(ICPState *icp);
 
 void ics_write_xive(ICSState *ics, int nr, int server,
 uint8_t priority, uint8_t saved_priority);
diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
index fd3319bd3202..99381639f50c 100644
--- a/include/hw/ppc/xive.h
+++ b/include/hw/ppc/xive.h
@@ -415,6 +415,7 @@ uint64_t xive_tctx_tm_read(XiveTCTX *tctx, hwaddr offset, 
unsigned size);
 
 void xive_tctx_pic_print_info(XiveTCTX *tctx, Monitor *mon);
 Object *xive_tctx_create(Object *cpu, XiveRouter *xrtr, Error **errp);
+void xive_tctx_reset(XiveTCTX *tctx);
 
 static inline uint32_t xive_nvt_cam_line(uint8_t nvt_blk, uint32_t nvt_idx)
 {
diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
index ba32d2cc5b0f..20a8d8285f64 100644
--- a/hw/intc/spapr_xive.c
+++ b/hw/intc/spapr_xive.c
@@ -553,6 +553,14 @@ static int 
spapr_xive_cpu_intc_create(SpaprInterruptController *intc,
 return 0;
 }
 
+static void spapr_xive_cpu_intc_reset(SpaprInterruptController *intc,
+ PowerPCCPU *cpu)
+{
+XiveTCTX *tctx = spapr_cpu_state(cpu)->tctx;
+
+xive_tctx_reset(tctx);
+}
+
 static void spapr_xive_set_irq(SpaprInterruptController *intc, int irq, int 
val)
 {
 SpaprXive *xive = SPAPR_XIVE(intc);
@@ -697,6 +705,7 @@ static void spapr_xive_class_init(ObjectClass *klass, void 
*data)
 sicc->activate = spapr_xive_activate;
 sicc->deactivate = spapr_xive_deactivate;
 sicc->cpu_intc_create = spapr_xive_cpu_intc_create;
+sicc->cpu_intc_reset = spapr_xive_cpu_intc_reset;
 sicc->claim_irq = spapr_xive_claim_irq;
 sicc->free_irq = spapr_xive_free_irq;
 sicc->set_irq = spapr_xive_set_irq;
diff --git a/hw/intc/xics.c b/hw/intc/xics.c
index 

[PATCH v2 19/28] leon3: use qemu_irq framework instead of callback as property

2019-10-22 Thread Marc-André Lureau
"set_pin_in" property is used to define a callback mechanism where the
device says "call the callback function, passing it an opaque cookie
and a 32-bit value". We already have a generic mechanism for doing
that, which is the qemu_irq. So we should just use that.

Signed-off-by: Marc-André Lureau 
---
 hw/intc/grlib_irqmp.c | 35 ---
 hw/sparc/leon3.c  |  9 +
 target/sparc/cpu.h|  1 +
 3 files changed, 10 insertions(+), 35 deletions(-)

diff --git a/hw/intc/grlib_irqmp.c b/hw/intc/grlib_irqmp.c
index bc78e1a14f..794c643af2 100644
--- a/hw/intc/grlib_irqmp.c
+++ b/hw/intc/grlib_irqmp.c
@@ -25,6 +25,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "hw/irq.h"
 #include "hw/sysbus.h"
 #include "cpu.h"
 
@@ -58,10 +59,8 @@ typedef struct IRQMP {
 
 MemoryRegion iomem;
 
-void *set_pil_in;
-void *set_pil_in_opaque;
-
 IRQMPState *state;
+qemu_irq irq;
 } IRQMP;
 
 struct IRQMPState {
@@ -82,7 +81,6 @@ static void grlib_irqmp_check_irqs(IRQMPState *state)
 uint32_t  pend   = 0;
 uint32_t  level0 = 0;
 uint32_t  level1 = 0;
-set_pil_in_fn set_pil_in;
 
 assert(state != NULL);
 assert(state->parent != NULL);
@@ -97,14 +95,8 @@ static void grlib_irqmp_check_irqs(IRQMPState *state)
 trace_grlib_irqmp_check_irqs(state->pending, state->force[0],
  state->mask[0], level1, level0);
 
-set_pil_in = (set_pil_in_fn)state->parent->set_pil_in;
-
 /* Trigger level1 interrupt first and level0 if there is no level1 */
-if (level1 != 0) {
-set_pil_in(state->parent->set_pil_in_opaque, level1);
-} else {
-set_pil_in(state->parent->set_pil_in_opaque, level0);
-}
+qemu_set_irq(state->parent->irq, level1 ?: level0);
 }
 
 static void grlib_irqmp_ack_mask(IRQMPState *state, uint32_t mask)
@@ -335,6 +327,7 @@ static void grlib_irqmp_init(Object *obj)
 IRQMP *irqmp = GRLIB_IRQMP(obj);
 SysBusDevice *dev = SYS_BUS_DEVICE(obj);
 
+qdev_init_gpio_out_named(DEVICE(obj), >irq, "grlib-irq", 1);
 memory_region_init_io(>iomem, obj, _irqmp_ops, irqmp,
   "irqmp", IRQMP_REG_SIZE);
 
@@ -343,31 +336,11 @@ static void grlib_irqmp_init(Object *obj)
 sysbus_init_mmio(dev, >iomem);
 }
 
-static void grlib_irqmp_realize(DeviceState *dev, Error **errp)
-{
-IRQMP *irqmp = GRLIB_IRQMP(dev);
-
-/* Check parameters */
-if (irqmp->set_pil_in == NULL) {
-error_setg(errp, "set_pil_in cannot be NULL.");
-}
-}
-
-static Property grlib_irqmp_properties[] = {
-DEFINE_PROP_PTR("set_pil_in", IRQMP, set_pil_in),
-DEFINE_PROP_PTR("set_pil_in_opaque", IRQMP, set_pil_in_opaque),
-DEFINE_PROP_END_OF_LIST(),
-};
-
 static void grlib_irqmp_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
 
 dc->reset = grlib_irqmp_reset;
-dc->props = grlib_irqmp_properties;
-/* Reason: pointer properties "set_pil_in", "set_pil_in_opaque" */
-dc->user_creatable = false;
-dc->realize = grlib_irqmp_realize;
 }
 
 static const TypeInfo grlib_irqmp_info = {
diff --git a/hw/sparc/leon3.c b/hw/sparc/leon3.c
index c5f1b1ee72..6db6ea9b5c 100644
--- a/hw/sparc/leon3.c
+++ b/hw/sparc/leon3.c
@@ -143,9 +143,10 @@ void leon3_irq_ack(void *irq_manager, int intno)
 grlib_irqmp_ack((DeviceState *)irq_manager, intno);
 }
 
-static void leon3_set_pil_in(void *opaque, uint32_t pil_in)
+static void leon3_set_pil_in(void *opaque, int n, int level)
 {
-CPUSPARCState *env = (CPUSPARCState *)opaque;
+CPUSPARCState *env = opaque;
+uint32_t pil_in = level;
 CPUState *cs;
 
 assert(env != NULL);
@@ -225,8 +226,8 @@ static void leon3_generic_hw_init(MachineState *machine)
 
 /* Allocate IRQ manager */
 dev = qdev_create(NULL, TYPE_GRLIB_IRQMP);
-qdev_prop_set_ptr(dev, "set_pil_in", leon3_set_pil_in);
-qdev_prop_set_ptr(dev, "set_pil_in_opaque", env);
+env->pil_irq = qemu_allocate_irq(leon3_set_pil_in, env, 0);
+qdev_connect_gpio_out_named(dev, "grlib-irq", 0, env->pil_irq);
 qdev_init_nofail(dev);
 sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, LEON3_IRQMP_OFFSET);
 env->irq_manager = dev;
diff --git a/target/sparc/cpu.h b/target/sparc/cpu.h
index 778aa8e073..709215f8c1 100644
--- a/target/sparc/cpu.h
+++ b/target/sparc/cpu.h
@@ -508,6 +508,7 @@ struct CPUSPARCState {
 #endif
 sparc_def_t def;
 
+qemu_irq pil_irq;
 void *irq_manager;
 void (*qemu_irq_ack)(CPUSPARCState *env, void *irq_manager, int intno);
 
-- 
2.23.0.606.g08da6496b6




  1   2   3   4   5   >