Re: [Qemu-devel] [PATCH 3/3] linux-user: MIPS set cpu to r6 CPU if binary is R6

[Laurent Vivier]

Le 17/01/2018 à 03:26, YunQiang Su a écrit :
> On Sat, Jan 13, 2018 at 10:48 PM, Laurent Vivier  wrote:
>> From: YunQiang Su 
>>
>> So here we need to detect the version of binaries and set
>> cpu_model for it.
>>
>> [lv: original patch modified to move code into get_cpu_model()]
>> Signed-off-by: Laurent Vivier 
>> ---
>>
>> Notes:
>> YunQiang Su, please add your Signed-off-by that was
>> missing in your original patch.
> 
> How to add Signed-off-by? Send a v2 for my version of patch?

You can reply to your original patch with your "Signed-off-by".
And as I did some changes in the following series, it would be good to
reply with a "Reviewed-by" to the new patches if you agree with the changes.

Thanks,
Laurent

Re: [Qemu-devel] [RFC v1] block/NVMe: introduce a new vhost NVMe host device to QEMU

[Paolo Bonzini]

On 17/01/2018 01:53, Liu, Changpeng wrote:
>> Second, virtio-based vhost-user remains QEMU's preferred method for
>> high-performance I/O in guests.  Discard support is missing and that is
>> important for SSDs; that should be fixed in the virtio spec.  Are there
> Previously I have a patch adding DISCARD support to virtio-blk, but I didn't 
> find
> the way using svn to update the spec patch, any git repository I can use
> to update the virtio-blk spec ? I think I can pick up the feature again.

There is https://github.com/oasis-tcs/virtio-spec.

You should add support for all of:

1) a command that can do WRITE ZERO, WRITE ZERO with discard, and
advisory DISCARD of a range of blocks.  The command must be controlled
by a new feature bit.

2) a configuration space element for discard granularity, controlled by
the same feature bit as (1)

3) a feature bit that is 1 if WRITE ZERO with discard can actually
discard parts that are aligned to the granularity

Thanks,

Paolo

Re: [Qemu-devel] [PATCH v2 0/4] coroutine-lock: polymorphic CoQueue

[no-reply]

Hi,

This series failed docker-build@min-glib build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

Type: series
Message-id: 20180116142316.30486-1-pbonz...@redhat.com
Subject: [Qemu-devel] [PATCH v2 0/4] coroutine-lock: polymorphic CoQueue

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=8
time make docker-test-build@min-glib
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
ceb8579b71 curl: convert to CoQueue
deb8f34b74 coroutine-lock: make qemu_co_enter_next thread-safe
5a30f36fba coroutine-lock: convert CoQueue to use QemuLockable
215b4ef03d lockable: add QemuLockable

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into '/var/tmp/patchew-tester-tmp-m03t9cw_/src/dtc'...
Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42'
  BUILD   min-glib
Traceback (most recent call last):
  File "./tests/docker/docker.py", line 407, in 
sys.exit(main())
  File "./tests/docker/docker.py", line 404, in main
return args.cmdobj.run(args, argv)
  File "./tests/docker/docker.py", line 287, in run
dkr = Docker()
  File "./tests/docker/docker.py", line 133, in __init__
self._command = _guess_docker_command()
  File "./tests/docker/docker.py", line 58, in _guess_docker_command
commands_txt)
Exception: Cannot find working docker command. Tried:
  docker
  sudo -n docker
make: *** [tests/docker/Makefile.include:37: docker-image-min-glib] Error 1

real0m0.649s
user0m0.049s
sys 0m0.029s
=== OUTPUT END ===

Test command exited with code: 2


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@freelists.org

[Qemu-devel] [PATCH v1 4/4] virtio-balloon: Don't skip free pages if the poison val is non-zero

[Wei Wang]

If the guest is using a non-zero poisoning, we don't skip the transfer
of guest free pages.

Todo: As a next step optimization, we can try
1) skip the transfer of guest poisoned free pages;
2) send the poison value to destination; and
3) seek a way to poison the guest free pages before the guest starts to
run on the destination.

Signed-off-by: Wei Wang 
CC: Michael S. Tsirkin 
---
 hw/virtio/virtio-balloon.c  | 3 ++-
 include/hw/virtio/virtio-balloon.h  | 1 +
 include/standard-headers/linux/virtio_balloon.h | 2 ++
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index dcc8cb3..0cdc755 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -403,7 +403,7 @@ static void virtio_balloon_handle_free_pages(VirtIODevice 
*vdev, VirtQueue *vq)
 ram_addr_t offset;
 
 if (atomic_read(>free_page_report_status) ==
-FREE_PAGE_REPORT_S_IN_PROGRESS) {
+FREE_PAGE_REPORT_S_IN_PROGRESS && !dev->poison_val) {
 block = qemu_ram_block_from_host(elem->in_sg[0].iov_base,
  false, );
 size = elem->in_sg[0].iov_len;
@@ -530,6 +530,7 @@ static void virtio_balloon_set_config(VirtIODevice *vdev,
 ((ram_addr_t) dev->actual << VIRTIO_BALLOON_PFN_SHIFT),
 _abort);
 }
+dev->poison_val = le32_to_cpu(config.poison_val);
 trace_virtio_balloon_set_config(dev->actual, oldactual);
 }
 
diff --git a/include/hw/virtio/virtio-balloon.h 
b/include/hw/virtio/virtio-balloon.h
index 268f7d6..0bb80cd 100644
--- a/include/hw/virtio/virtio-balloon.h
+++ b/include/hw/virtio/virtio-balloon.h
@@ -43,6 +43,7 @@ typedef struct VirtIOBalloon {
 uint32_t num_pages;
 uint32_t actual;
 uint32_t free_page_report_cmd_id;
+uint32_t poison_val;
 uint64_t stats[VIRTIO_BALLOON_S_NR];
 VirtQueueElement *stats_vq_elem;
 size_t stats_vq_offset;
diff --git a/include/standard-headers/linux/virtio_balloon.h 
b/include/standard-headers/linux/virtio_balloon.h
index 596df5d..f6f4ff3 100644
--- a/include/standard-headers/linux/virtio_balloon.h
+++ b/include/standard-headers/linux/virtio_balloon.h
@@ -47,6 +47,8 @@ struct virtio_balloon_config {
uint32_t actual;
 /* The free_page report command id, readonly by guest */
uint32_t free_page_report_cmd_id;
+   /* Stores PAGE_POISON if page poisoning with sanity check is in use */
+   uint32_t poison_val;
 };
 
 #define VIRTIO_BALLOON_S_SWAP_IN  0   /* Amount of memory swapped in */
-- 
1.8.3.1

[Qemu-devel] [PATCH v1 0/4] virtio-balloon: support free page reporting

[Wei Wang]

This is the deivce part implementation to add a new feature,
VIRTIO_BALLOON_F_FREE_PAGE_VQ to the virtio-balloon device. The device
receives the guest free page hint from the driver and clears the
corresponding bits in the dirty bitmap, so that those free pages are
not transferred to the destination. Please see the results in the
commit log of patch 1.

Link to the driver patches:
https://marc.info/?l=kvm=151616696828185=2

Wei Wang (4):
  virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ
  migration: call balloon to clear bits of free pages from dirty bitmap
  virtio-balloon: add a timer to limit the free page report wating time
  virtio-balloon: Don't skip free pages if the poison val is non-zero

 balloon.c   |  46 -
 hw/virtio/virtio-balloon.c  | 224 ++--
 hw/virtio/virtio-pci.c  |   3 +
 include/hw/virtio/virtio-balloon.h  |  12 +-
 include/migration/misc.h|   3 +
 include/standard-headers/linux/virtio_balloon.h |   6 +
 include/sysemu/balloon.h|  15 +-
 migration/ram.c |  38 +++-
 8 files changed, 316 insertions(+), 31 deletions(-)

-- 
1.8.3.1

[Qemu-devel] [PATCH v1 1/4] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ

[Wei Wang]

The new feature enables the virtio-balloon device to receive the hint of
guest free pages from the free page vq, and clears the corresponding bits
of the free page from the dirty bitmap, so that those free pages are not
transferred by the migration thread.

Without this feature, to local live migrate an 8G idle guest takes
~2286 ms. With this featrue, it takes ~260 ms, which redues the
migration time to ~11%.

Signed-off-by: Wei Wang 
Signed-off-by: Liang Li 
CC: Michael S. Tsirkin 
---
 balloon.c   |  46 ++--
 hw/virtio/virtio-balloon.c  | 140 +---
 include/hw/virtio/virtio-balloon.h  |   7 +-
 include/migration/misc.h|   3 +
 include/standard-headers/linux/virtio_balloon.h |   4 +
 include/sysemu/balloon.h|  15 ++-
 migration/ram.c |  10 ++
 7 files changed, 198 insertions(+), 27 deletions(-)

diff --git a/balloon.c b/balloon.c
index 1d720ff..480a989 100644
--- a/balloon.c
+++ b/balloon.c
@@ -36,6 +36,9 @@
 
 static QEMUBalloonEvent *balloon_event_fn;
 static QEMUBalloonStatus *balloon_stat_fn;
+static QEMUBalloonFreePageSupport *balloon_free_page_support_fn;
+static QEMUBalloonFreePageStart *balloon_free_page_start_fn;
+static QEMUBalloonFreePageStop *balloon_free_page_stop_fn;
 static void *balloon_opaque;
 static bool balloon_inhibited;
 
@@ -64,17 +67,41 @@ static bool have_balloon(Error **errp)
 return true;
 }
 
-int qemu_add_balloon_handler(QEMUBalloonEvent *event_func,
- QEMUBalloonStatus *stat_func, void *opaque)
+bool balloon_free_page_support(void)
 {
-if (balloon_event_fn || balloon_stat_fn || balloon_opaque) {
-/* We're already registered one balloon handler.  How many can
- * a guest really have?
- */
+return balloon_free_page_support_fn &&
+   balloon_free_page_support_fn(balloon_opaque);
+}
+
+void balloon_free_page_start(void)
+{
+balloon_free_page_start_fn(balloon_opaque);
+}
+
+void balloon_free_page_stop(void)
+{
+balloon_free_page_stop_fn(balloon_opaque);
+}
+
+int qemu_add_balloon_handler(QEMUBalloonEvent *event_fn,
+ QEMUBalloonStatus *stat_fn,
+ QEMUBalloonFreePageSupport *free_page_support_fn,
+ QEMUBalloonFreePageStart *free_page_start_fn,
+ QEMUBalloonFreePageStop *free_page_stop_fn,
+ void *opaque)
+{
+if (balloon_event_fn || balloon_stat_fn || balloon_free_page_support_fn ||
+balloon_free_page_start_fn || balloon_free_page_stop_fn ||
+balloon_opaque) {
+/* We already registered one balloon handler. */
 return -1;
 }
-balloon_event_fn = event_func;
-balloon_stat_fn = stat_func;
+
+balloon_event_fn = event_fn;
+balloon_stat_fn = stat_fn;
+balloon_free_page_support_fn = free_page_support_fn;
+balloon_free_page_start_fn = free_page_start_fn;
+balloon_free_page_stop_fn = free_page_stop_fn;
 balloon_opaque = opaque;
 return 0;
 }
@@ -86,6 +113,9 @@ void qemu_remove_balloon_handler(void *opaque)
 }
 balloon_event_fn = NULL;
 balloon_stat_fn = NULL;
+balloon_free_page_support_fn = NULL;
+balloon_free_page_start_fn = NULL;
+balloon_free_page_stop_fn = NULL;
 balloon_opaque = NULL;
 }
 
diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index 14e08d2..a2a5536 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -30,6 +30,7 @@
 
 #include "hw/virtio/virtio-bus.h"
 #include "hw/virtio/virtio-access.h"
+#include "migration/misc.h"
 
 #define BALLOON_PAGE_SIZE  (1 << VIRTIO_BALLOON_PFN_SHIFT)
 
@@ -73,6 +74,13 @@ static bool balloon_stats_supported(const VirtIOBalloon *s)
 return virtio_vdev_has_feature(vdev, VIRTIO_BALLOON_F_STATS_VQ);
 }
 
+static bool balloon_free_page_supported(const VirtIOBalloon *s)
+{
+VirtIODevice *vdev = VIRTIO_DEVICE(s);
+
+return virtio_vdev_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_VQ);
+}
+
 static bool balloon_stats_enabled(const VirtIOBalloon *s)
 {
 return s->stats_poll_interval > 0;
@@ -305,6 +313,85 @@ out:
 }
 }
 
+static void virtio_balloon_handle_free_pages(VirtIODevice *vdev, VirtQueue *vq)
+{
+VirtIOBalloon *dev = VIRTIO_BALLOON(vdev);
+VirtQueueElement *elem;
+uint32_t size, id;
+
+for (;;) {
+elem = virtqueue_pop(vq, sizeof(VirtQueueElement));
+if (!elem) {
+break;
+}
+
+if (elem->out_num) {
+iov_to_buf(elem->out_sg, elem->out_num, 0, , sizeof(uint32_t));
+size = elem->out_sg[0].iov_len;
+if (id == dev->free_page_report_cmd_id) {
+atomic_set(>free_page_report_status,
+   FREE_PAGE_REPORT_S_IN_PROGRESS);
+ 

[Qemu-devel] [PATCH v1 3/4] virtio-balloon: add a timer to limit the free page report wating time

[Wei Wang]

This patch adds a timer to limit the time that the host waits for the
free pages reported by the guest. Users can specify the time in ms via
"free-page-wait-time" command line option. If a user doesn't specify a
time, the host waits till the guest finishes reporting all the free
pages. The policy (wait for all the free pages to be reported or use a
time limit) is determined by the orchestration layer.

Signed-off-by: Wei Wang 
CC: Michael S. Tsirkin 
---
 hw/virtio/virtio-balloon.c | 85 +-
 hw/virtio/virtio-pci.c |  3 ++
 include/hw/virtio/virtio-balloon.h |  4 ++
 3 files changed, 91 insertions(+), 1 deletion(-)

diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index a2a5536..dcc8cb3 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -213,6 +213,66 @@ static void balloon_stats_set_poll_interval(Object *obj, 
Visitor *v,
 balloon_stats_change_timer(s, 0);
 }
 
+static void balloon_free_page_change_timer(VirtIOBalloon *s, int64_t ms)
+{
+timer_mod(s->free_page_timer,
+  qemu_clock_get_ms(QEMU_CLOCK_REALTIME) + ms);
+}
+
+static void balloon_stop_free_page_report(void *opaque)
+{
+VirtIOBalloon *dev = opaque;
+VirtIODevice *vdev = VIRTIO_DEVICE(dev);
+
+timer_del(dev->free_page_timer);
+timer_free(dev->free_page_timer);
+dev->free_page_timer = NULL;
+
+if (atomic_read(>free_page_report_status) ==
+FREE_PAGE_REPORT_S_IN_PROGRESS) {
+dev->host_stop_free_page = true;
+virtio_notify_config(vdev);
+}
+}
+
+static void balloon_free_page_get_wait_time(Object *obj, Visitor *v,
+const char *name, void *opaque,
+Error **errp)
+{
+VirtIOBalloon *s = opaque;
+
+visit_type_int(v, name, >free_page_wait_time, errp);
+}
+
+static void balloon_free_page_set_wait_time(Object *obj, Visitor *v,
+const char *name, void *opaque,
+Error **errp)
+{
+VirtIOBalloon *s = opaque;
+Error *local_err = NULL;
+int64_t value;
+
+visit_type_int(v, name, , _err);
+if (local_err) {
+error_propagate(errp, local_err);
+return;
+}
+if (value < 0) {
+error_setg(errp, "free page wait time must be greater than zero");
+return;
+}
+
+if (value > UINT32_MAX) {
+error_setg(errp, "free page wait time value is too big");
+return;
+}
+
+s->free_page_wait_time = value;
+g_assert(s->free_page_timer == NULL);
+s->free_page_timer = timer_new_ms(QEMU_CLOCK_REALTIME,
+  balloon_stop_free_page_report, s);
+}
+
 static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
 {
 VirtIOBalloon *s = VIRTIO_BALLOON(vdev);
@@ -332,6 +392,7 @@ static void virtio_balloon_handle_free_pages(VirtIODevice 
*vdev, VirtQueue *vq)
 atomic_set(>free_page_report_status,
FREE_PAGE_REPORT_S_IN_PROGRESS);
 } else {
+dev->host_stop_free_page = false;
 atomic_set(>free_page_report_status,
FREE_PAGE_REPORT_S_STOP);
 }
@@ -386,6 +447,10 @@ static void virtio_balloon_free_page_stop(void *opaque)
 return;
 }
 
+if (dev->free_page_wait_time) {
+balloon_free_page_change_timer(dev, dev->free_page_wait_time);
+}
+
 /* Wait till a stop sign is received from the guest */
 while (atomic_read(>free_page_report_status) !=
FREE_PAGE_REPORT_S_STOP)
@@ -399,7 +464,19 @@ static void virtio_balloon_get_config(VirtIODevice *vdev, 
uint8_t *config_data)
 
 config.num_pages = cpu_to_le32(dev->num_pages);
 config.actual = cpu_to_le32(dev->actual);
-config.free_page_report_cmd_id = cpu_to_le32(dev->free_page_report_cmd_id);
+if (dev->host_stop_free_page) {
+/*
+ * Host is actively requesting to stop the free page report, send the
+ * stop sign to the guest. This happens when the migration thread has
+ * reached the phase to send pages to the destination while the guest
+ * hasn't done the reporting.
+ */
+config.free_page_report_cmd_id =
+VIRTIO_BALLOON_FREE_PAGE_REPORT_STOP_ID;
+} else {
+config.free_page_report_cmd_id =
+cpu_to_le32(dev->free_page_report_cmd_id);
+}
 
 trace_virtio_balloon_get_config(config.num_pages, config.actual);
 memcpy(config_data, , sizeof(struct virtio_balloon_config));
@@ -526,6 +603,7 @@ static void virtio_balloon_device_realize(DeviceState *dev, 
Error **errp)
 s->free_page_vq = virtio_add_queue(vdev, 128,
virtio_balloon_handle_free_pages);
 

[Qemu-devel] [PATCH v1 2/4] migration: call balloon to clear bits of free pages from dirty bitmap

[Wei Wang]

When migration starts, call the related balloon functions to clear the
bits of guest free pages from the dirty bitmap. The dirty bitmap should
be ready to use when sending pages to the destination, so stop the guest
from reporting free pages before sending pages.

Signed-off-by: Wei Wang 
CC: Michael S. Tsirkin 
---
 migration/ram.c | 28 
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index d6f462c..9b8d102 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -49,6 +49,7 @@
 #include "qemu/rcu_queue.h"
 #include "migration/colo.h"
 #include "migration/block.h"
+#include "sysemu/balloon.h"
 
 /***/
 /* ram save/restore */
@@ -206,6 +207,10 @@ struct RAMState {
 uint32_t last_version;
 /* We are in the first round */
 bool ram_bulk_stage;
+/* The feature, skipping the transfer of free pages, is supported */
+bool free_page_support;
+/* Skip the transfer of free pages in the bulk stage */
+bool free_page_done;
 /* How many times we have dirty too many pages */
 int dirty_rate_high_cnt;
 /* these variables are used for bitmap sync */
@@ -773,7 +778,7 @@ unsigned long migration_bitmap_find_dirty(RAMState *rs, 
RAMBlock *rb,
 unsigned long *bitmap = rb->bmap;
 unsigned long next;
 
-if (rs->ram_bulk_stage && start > 0) {
+if (rs->ram_bulk_stage && start > 0 && !rs->free_page_support) {
 next = start + 1;
 } else {
 next = find_next_bit(bitmap, size, start);
@@ -1653,6 +1658,8 @@ static void ram_state_reset(RAMState *rs)
 rs->last_page = 0;
 rs->last_version = ram_list.version;
 rs->ram_bulk_stage = true;
+rs->free_page_support = balloon_free_page_support();
+rs->free_page_done = false;
 }
 
 #define MAX_WAIT 50 /* ms, half buffered_file limit */
@@ -2135,7 +2142,7 @@ static int ram_state_init(RAMState **rsp)
 return 0;
 }
 
-static void ram_list_init_bitmaps(void)
+static void ram_list_init_bitmaps(RAMState *rs)
 {
 RAMBlock *block;
 unsigned long pages;
@@ -2145,7 +2152,11 @@ static void ram_list_init_bitmaps(void)
 QLIST_FOREACH_RCU(block, _list.blocks, next) {
 pages = block->max_length >> TARGET_PAGE_BITS;
 block->bmap = bitmap_new(pages);
-bitmap_set(block->bmap, 0, pages);
+if (rs->free_page_support) {
+bitmap_set(block->bmap, 1, pages);
+} else {
+bitmap_set(block->bmap, 0, pages);
+}
 if (migrate_postcopy_ram()) {
 block->unsentmap = bitmap_new(pages);
 bitmap_set(block->unsentmap, 0, pages);
@@ -2161,8 +2172,11 @@ static void ram_init_bitmaps(RAMState *rs)
 qemu_mutex_lock_ramlist();
 rcu_read_lock();
 
-ram_list_init_bitmaps();
+ram_list_init_bitmaps(rs);
 memory_global_dirty_log_start();
+if (rs->free_page_support) {
+balloon_free_page_start();
+}
 migration_bitmap_sync(rs);
 
 rcu_read_unlock();
@@ -2275,6 +2289,12 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
 
 ram_control_before_iterate(f, RAM_CONTROL_ROUND);
 
+/* Before sending the pages, stop the guest from reporting free pages. */
+if (rs->free_page_support && !rs->free_page_done) {
+balloon_free_page_stop();
+rs->free_page_done = true;
+}
+
 t0 = qemu_clock_get_ns(QEMU_CLOCK_REALTIME);
 i = 0;
 while ((ret = qemu_file_rate_limit(f)) == 0) {
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH 00/11] qdev: remove DeviceClass::init/exit()

[no-reply]

Hi,

This series failed docker-mingw@fedora build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

Type: series
Message-id: 20180116131555.14242-1-f4...@amsat.org
Subject: [Qemu-devel] [PATCH 00/11] qdev: remove DeviceClass::init/exit()

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=8
time make docker-test-mingw@fedora
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 t [tag update]patchew/20180115170243.24578-1-berra...@redhat.com 
-> patchew/20180115170243.24578-1-berra...@redhat.com
Switched to a new branch 'test'
8a511044fd qdev: rename typedef qdev_resetfn() -> DeviceReset()
7b8b539cc2 qdev: remove empty realize/unrealize stubs
8eb472976f qdev: remove DeviceClass::exit
0f4697db59 qdev: remove DeviceClass::init
a2de037067 qdev: simplify the SysBusDeviceClass::init path
d84d6882ed sysbus: add realize() and unrealize()
dae9ccfb44 virtio-ccw: convert VirtIOCCWDeviceClass::init -> realize
2c474c1777 usb-ccid: convert CCIDCardClass::init -> realize
bc93b82615 hw/i2c: convert I2CSlaveClass::init -> realize
515a5a9b11 smbus_eeprom: replace SMBusDeviceClass::init by DeviceClass::reset
224b669cd4 smbus: add a NULL check for SMBusDeviceClass::init callbacks

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into '/var/tmp/patchew-tester-tmp-t68avrnp/src/dtc'...
Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42'
  BUILD   fedora
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-t68avrnp/src'
  GEN 
/var/tmp/patchew-tester-tmp-t68avrnp/src/docker-src.2018-01-17-00.43.41.32609/qemu.tar
Cloning into 
'/var/tmp/patchew-tester-tmp-t68avrnp/src/docker-src.2018-01-17-00.43.41.32609/qemu.tar.vroot'...
done.
Checking out files:  44% (2547/5723)   
Checking out files:  45% (2576/5723)   
Checking out files:  46% (2633/5723)   
Checking out files:  47% (2690/5723)   
Checking out files:  48% (2748/5723)   
Checking out files:  49% (2805/5723)   
Checking out files:  50% (2862/5723)   
Checking out files:  51% (2919/5723)   
Checking out files:  52% (2976/5723)   
Checking out files:  53% (3034/5723)   
Checking out files:  54% (3091/5723)   
Checking out files:  55% (3148/5723)   
Checking out files:  56% (3205/5723)   
Checking out files:  57% (3263/5723)   
Checking out files:  58% (3320/5723)   
Checking out files:  59% (3377/5723)   
Checking out files:  60% (3434/5723)   
Checking out files:  61% (3492/5723)   
Checking out files:  62% (3549/5723)   
Checking out files:  63% (3606/5723)   
Checking out files:  64% (3663/5723)   
Checking out files:  65% (3720/5723)   
Checking out files:  66% (3778/5723)   
Checking out files:  67% (3835/5723)   
Checking out files:  68% (3892/5723)   
Checking out files:  69% (3949/5723)   
Checking out files:  70% (4007/5723)   
Checking out files:  71% (4064/5723)   
Checking out files:  72% (4121/5723)   
Checking out files:  73% (4178/5723)   
Checking out files:  74% (4236/5723)   
Checking out files:  75% (4293/5723)   
Checking out files:  76% (4350/5723)   
Checking out files:  77% (4407/5723)   
Checking out files:  78% (4464/5723)   
Checking out files:  79% (4522/5723)   
Checking out files:  80% (4579/5723)   
Checking out files:  81% (4636/5723)   
Checking out files:  82% (4693/5723)   
Checking out files:  83% (4751/5723)   
Checking out files:  84% (4808/5723)   
Checking out files:  85% (4865/5723)   
Checking out files:  86% (4922/5723)   
Checking out files:  87% (4980/5723)   
Checking out files:  88% (5037/5723)   
Checking out files:  89% (5094/5723)   
Checking out files:  90% (5151/5723)   
Checking out files:  91% (5208/5723)   
Checking out files:  92% (5266/5723)   
Checking out files:  93% (5323/5723)   
Checking out files:  94% (5380/5723)   
Checking out files:  95% (5437/5723)   
Checking out files:  96% (5495/5723)   
Checking out files:  97% (5552/5723)   
Checking out files:  98% (5609/5723)   
Checking out files:  99% (5666/5723)   
Checking out files: 100% (5723/5723)   
Checking out files: 100% (5723/5723), done.
Your branch is up-to-date with 'origin/test'.
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 
'/var/tmp/patchew-tester-tmp-t68avrnp/src/docker-src.2018-01-17-00.43.41.32609/qemu.tar.vroot/dtc'...
Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42'
Submodule 'ui/keycodemapdb' (git://git.qemu.org/keycodemapdb.git) registered 
for path 'ui/keycodemapdb'
Cloning into 
'/var/tmp/patchew-tester-tmp-t68avrnp/src/docker-src.2018-01-17-00.43.41.32609/qemu.tar.vroot/ui/keycodemapdb'...
Submodule path 'ui/keycodemapdb': checked out 
'10739aa26051a5d49d88132604539d3ed085e72e'
  COPYRUNNER
RUN test-mingw in qemu:fedora 

Re: [Qemu-devel] [PATCH v2 0/4] coroutine-lock: polymorphic CoQueue

[Fam Zheng]

On 01/17/2018 02:04 PM, no-re...@patchew.org wrote:

   BUILD   min-glib
Traceback (most recent call last):
   File "./tests/docker/docker.py", line 407, in 
 sys.exit(main())
   File "./tests/docker/docker.py", line 404, in main
 return args.cmdobj.run(args, argv)
   File "./tests/docker/docker.py", line 287, in run
 dkr = Docker()
   File "./tests/docker/docker.py", line 133, in __init__
 self._command = _guess_docker_command()
   File "./tests/docker/docker.py", line 58, in _guess_docker_command
 commands_txt)
Exception: Cannot find working docker command. Tried:
   docker
   sudo -n docker


Patchew.org was misconfigured to run this docker tests on a host that 
has no docker. Fixed now. Sorry for the noise.


Fam

Re: [Qemu-devel] [PATCH v5 0/2] qemu-img: Document --force-share / -U

[Fam Zheng]

Ping?

On Tue, Dec 26, 2017 at 10:52 AM, Fam Zheng  wrote:
> v5: Clean up the @table @var section first. [Kevin, Peter]
>
> Fam Zheng (2):
>   qemu-img.texi: Clean up parameter list
>   qemu-img: Document --force-share / -U
>
>  qemu-img.texi | 75 
> ++-
>  1 file changed, 48 insertions(+), 27 deletions(-)
>
> --
> 2.14.3
>
>

Re: [Qemu-devel] [qemu-s390x] [PATCH v3 4/8] s390-ccw: interactive boot menu for eckd dasd (menu setup)

[Thomas Huth]

On 16.01.2018 20:37, Collin L. Walling wrote:
> On 01/16/2018 01:23 PM, Thomas Huth wrote:
>> On 15.01.2018 17:44, Collin L. Walling wrote:
>>> Reads boot menu flag and timeout values from the iplb and
>>> sets the respective fields for the menu.
>>>
>>> Signed-off-by: Collin L. Walling 
>>> ---
>> [...]
>>> diff --git a/pc-bios/s390-ccw/iplb.h b/pc-bios/s390-ccw/iplb.h
>>> index fe909d2..da29e6e 100644
>>> --- a/pc-bios/s390-ccw/iplb.h
>>> +++ b/pc-bios/s390-ccw/iplb.h
>>> @@ -81,6 +81,9 @@ extern IplParameterBlock iplb
>>> __attribute__((__aligned__(PAGE_SIZE)));
>>>   #define S390_IPL_TYPE_CCW 0x02
>>>   #define S390_IPL_TYPE_QEMU_SCSI 0xff
>>>   +#define LOADPARM_PROMPT "PROMPT  "
>>> +#define LOADPARM_EMPTY  ""
>> I've got a question: Is there a (public) specification document
>> available somewhere for the loadparm field?
> 
> Unfortunately there does not seems to be any kind of documentation
> regarding loadparm for
> KVM on IBM z.  Most of the information available on the IBM Knowledge
> Center focuses on
> z/VM, which isn't very helpful in this case :(

Ok, too bad :-(

> Are there any specific questions that I can help with?

I was just wondering whether there are pre-defined values for this
field, e.g. is "PROMPT" something you came up with, or is this a value
that has been documented in a specification somewhere? ... I'm just
curious: If there is a list of pre-defined values somewhere, what are
the other values that the s390-ccw bios does not support yet?

 Thomas

Re: [Qemu-devel] [PATCH v9 00/26] tcg: generic vector operations

[Fam Zheng]

gcc-4.8.5-16.el7_4.1.ppc64le

On Tue, Jan 16, 2018 at 11:50 PM, Richard Henderson
 wrote:
> On 01/16/2018 03:59 AM, Peter Maydell wrote:
>> /var/tmp/patchew-tester-tmp-r7vd2rsz/src/accel/tcg/tcg-runtime-gvec.c:533:26:
>> internal compiler error: in emit_move_insn, at expr.c:3495
>
> Bah.  I remember seeing this myself on the gcc 4.8.x that is the system
> compiler on the gcc compile farm machines.  I forgot about it because I
> immediately changed my path to select gcc 7.x.  ;-P
>
>> We need to either work around that or update the compiler in patchew's
>> setup or disable that build before we can merge this, or patchew will
>> start mailing complaints about every series that's sent to the list...
>
> I can work around it in configure, but it might be worth updating the compiler
> as well -- this bug has been fixed for years.

This gcc is the CentOS 7 packaged version and an update (from
gcc-4.8.5-16.el7.ppc64le
 to gcc-4.8.5-16.el7_4.1.ppc64le) doesn't fix it.

Fam

Re: [Qemu-devel] [PATCH v3 1/4] cryptodev: add vhost-user as a new cryptodev backend

[Zhoujian (jay)]

> -Original Message-
> From: Qemu-devel [mailto:qemu-devel-
> bounces+jianjay.zhou=huawei@nongnu.org] On Behalf Of Michael S. Tsirkin
> Sent: Wednesday, January 17, 2018 12:41 AM
> To: Zhoujian (jay) 
> Cc: pa...@linux.vnet.ibm.com; Huangweidong (C) ;
> xin.z...@intel.com; qemu-devel@nongnu.org; Gonglei (Arei)
> ; roy.fan.zh...@intel.com; stefa...@redhat.com;
> pbonz...@redhat.com; longpeng 
> Subject: Re: [Qemu-devel] [PATCH v3 1/4] cryptodev: add vhost-user as a new
> cryptodev backend
> 
> On Tue, Jan 16, 2018 at 10:06:50PM +0800, Jay Zhou wrote:
> > From: Gonglei 
> >
> > Usage:
> >  -chardev socket,id=charcrypto0,path=/path/to/your/socket
> >  -object cryptodev-vhost-user,id=cryptodev0,chardev=charcrypto0
> >  -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0
> >
> > Signed-off-by: Gonglei 
> > Signed-off-by: Longpeng(Mike) 
> > Signed-off-by: Jay Zhou 
> > ---
> >  backends/Makefile.objs   |   4 +
> >  backends/cryptodev-vhost-user.c  | 333
> +++
> >  backends/cryptodev-vhost.c   |  73 +
> >  include/sysemu/cryptodev-vhost.h | 154 ++
> >  qemu-options.hx  |  21 +++
> >  vl.c |   4 +
> >  6 files changed, 589 insertions(+)
> >  create mode 100644 backends/cryptodev-vhost-user.c  create mode
> > 100644 backends/cryptodev-vhost.c  create mode 100644
> > include/sysemu/cryptodev-vhost.h
> >
> > diff --git a/backends/Makefile.objs b/backends/Makefile.objs index
> > 0400799..9e1fb76 100644
> > --- a/backends/Makefile.objs
> > +++ b/backends/Makefile.objs
> > @@ -8,3 +8,7 @@ common-obj-$(CONFIG_LINUX) += hostmem-file.o
> >
> >  common-obj-y += cryptodev.o
> >  common-obj-y += cryptodev-builtin.o
> > +
> > +ifeq ($(CONFIG_VIRTIO),y)
> > +common-obj-$(CONFIG_LINUX) += cryptodev-vhost.o
> > +cryptodev-vhost-user.o endif
> 
> Shouldn't this depend on CONFIG_VHOST_USER?

Yes, you're right. Will fix it soon.

Regards,
Jay

> 
> 
> > diff --git a/backends/cryptodev-vhost-user.c
> > b/backends/cryptodev-vhost-user.c new file mode 100644 index
> > 000..4e63ece
> > --- /dev/null
> > +++ b/backends/cryptodev-vhost-user.c
> > @@ -0,0 +1,333 @@
> > +/*
> > + * QEMU Cryptodev backend for QEMU cipher APIs
> > + *
> > + * Copyright (c) 2016 HUAWEI TECHNOLOGIES CO., LTD.
> > + *
> > + * Authors:
> > + *Gonglei 
> > + *
> > + * This library is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2 of the License, or (at your option) any later version.
> > + *
> > + * This library 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
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with this library; if not, see
> .
> > + *
> > + */
> > +
> > +#include "qemu/osdep.h"
> > +#include "hw/boards.h"
> > +#include "qapi/error.h"
> > +#include "qapi/qmp/qerror.h"
> > +#include "qemu/error-report.h"
> > +#include "standard-headers/linux/virtio_crypto.h"
> > +#include "sysemu/cryptodev-vhost.h"
> > +#include "chardev/char-fe.h"
> > +
> > +
> > +/**
> > + * @TYPE_CRYPTODEV_BACKEND_VHOST_USER:
> > + * name of backend that uses vhost user server  */ #define
> > +TYPE_CRYPTODEV_BACKEND_VHOST_USER "cryptodev-vhost-user"
> > +
> > +#define CRYPTODEV_BACKEND_VHOST_USER(obj) \
> > +OBJECT_CHECK(CryptoDevBackendVhostUser, \
> > + (obj), TYPE_CRYPTODEV_BACKEND_VHOST_USER)
> > +
> > +
> > +typedef struct CryptoDevBackendVhostUser {
> > +CryptoDevBackend parent_obj;
> > +
> > +CharBackend chr;
> > +char *chr_name;
> > +bool opened;
> > +CryptoDevBackendVhost *vhost_crypto[MAX_CRYPTO_QUEUE_NUM];
> > +} CryptoDevBackendVhostUser;
> > +
> > +static int
> > +cryptodev_vhost_user_running(
> > + CryptoDevBackendVhost *crypto) {
> > +return crypto ? 1 : 0;
> > +}
> > +
> > +static void cryptodev_vhost_user_stop(int queues,
> > +  CryptoDevBackendVhostUser *s) {
> > +size_t i;
> > +
> > +for (i = 0; i < queues; i++) {
> > +if (!cryptodev_vhost_user_running(s->vhost_crypto[i])) {
> > +continue;
> > +}
> > +
> > +if (s->vhost_crypto) {
> > +cryptodev_vhost_cleanup(s->vhost_crypto[i]);
> > +s->vhost_crypto[i] = NULL;
> > +}
> > +}
> > +}
> > +
> > +static int
> > +cryptodev_vhost_user_start(int queues,
> > + 

Re: [Qemu-devel] [RFC 3/3] vhost-user: add VFIO based accelerators support

[Tiwei Bie]

On Tue, Jan 16, 2018 at 10:23:39AM -0700, Alex Williamson wrote:
> On Fri, 22 Dec 2017 14:41:51 +0800
> Tiwei Bie  wrote:
> 
> > Signed-off-by: Tiwei Bie 
> > ---
> >  docs/interop/vhost-user.txt|  57 ++
> >  hw/vfio/common.c   |   2 +-
> >  hw/virtio/vhost-user.c | 381 
> > -
> >  hw/virtio/vhost.c  |   3 +-
> >  hw/virtio/virtio-pci.c |   8 -
> >  hw/virtio/virtio-pci.h |   8 +
> >  include/hw/vfio/vfio.h |   2 +
> >  include/hw/virtio/vhost-user.h |  26 +++
> >  8 files changed, 476 insertions(+), 11 deletions(-)
> > 
> > diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> > index 7b2924c0ef..53d8700581 100644
> > --- a/hw/vfio/common.c
> > +++ b/hw/vfio/common.c
> > @@ -49,7 +49,7 @@ struct vfio_as_head vfio_address_spaces =
> >   * initialized, this file descriptor is only released on QEMU exit and
> >   * we'll re-use it should another vfio device be attached before then.
> >   */
> > -static int vfio_kvm_device_fd = -1;
> > +int vfio_kvm_device_fd = -1;
> >  #endif
> 
> It seems troublesome for vhost to maintain it's own list of groups and
> register them with the vfio-kvm device.  These should likely be made
> into services provided by vfio/common.c such that we can have a single
> group list and interfaces for adding and deleting them.  Thanks,

Thank you very much for the comments! I'll fix this.

Best regards,
Tiwei Bie

Re: [Qemu-devel] [PATCH v2 6/8] docker: add the Fedora 27 base image

[Fam Zheng]

On Tue, Jan 16, 2018 at 12:38 AM, Philippe Mathieu-Daudé
 wrote:
> On 01/15/2018 01:27 PM, Daniel P. Berrange wrote:
>> On Mon, Jan 15, 2018 at 11:34:57AM -0300, Philippe Mathieu-Daudé wrote:
>>> straight copy on Fedora 25 base.
>>>
>>> Suggested-by: Paolo Bonzini 
>>> Signed-off-by: Philippe Mathieu-Daudé 
>>> ---
>>>  tests/docker/dockerfiles/fedora27.docker | 18 ++
>>>  1 file changed, 18 insertions(+)
>>>  create mode 100644 tests/docker/dockerfiles/fedora27.docker
>>>
>>> diff --git a/tests/docker/dockerfiles/fedora27.docker 
>>> b/tests/docker/dockerfiles/fedora27.docker
>>> new file mode 100644
>>> index 00..7cba4dcc2c
>>> --- /dev/null
>>> +++ b/tests/docker/dockerfiles/fedora27.docker
>>> @@ -0,0 +1,18 @@
>>> +FROM fedora:27
>>> +ENV PACKAGES \
>>> +ccache gettext git tar PyYAML sparse flex bison python2 bzip2 hostname 
>>> \
>>> +glib2-devel pixman-devel zlib-devel SDL-devel libfdt-devel \
>>
>> Perhaps SDL2 here too
>>
>>> +gcc gcc-c++ clang make perl which bc findutils libaio-devel \
>>> +nettle-devel \
>>> +mingw32-pixman mingw32-glib2 mingw32-gmp mingw32-SDL 
>>> mingw32-pkg-config \
>>> +mingw32-gtk2 mingw32-gtk3 mingw32-gnutls mingw32-nettle 
>>> mingw32-libtasn1 \
>>
>> Is there a reason we have both GTK2 and GTK3 installed ? We've deprecated 
>> GTK2
>> and configure will pick GTK3 by default. IIUC there's no way to override
>> that in the docker builds to force GTK2, so it can possibly be dropped.
>
> No clue, Fam?
>

I think Dan is right here.

Fam

Re: [Qemu-devel] [PATCH v1] migration: use s->threshold_size inside migration_update_counters

[Peter Xu]

On Wed, Jan 17, 2018 at 09:06:43AM +0800, Wei Wang wrote:
> On 01/16/2018 08:19 PM, Peter Xu wrote:
> > On Tue, Jan 16, 2018 at 06:51:32PM +0800, Wei Wang wrote:
> > > The threshold size is changed to be recorded in s->threshold_size by
> > > commit b15df1ae5063c7c181f8f068f9eba7661b3b5e1.
> > > 
> > > Signed-off-by: Wei Wang 
> > Could you help confirm the commit ID?  Since what I see is
> > b15df1ae50.  Otherwise:
> > 
> > Reviewed-by: Peter Xu 
> > 
> > And I'd prefer add:
> > 
> > Fixes: b15df1ae50 ("migration: cleanup stats update into function")
> > 
> > Thanks for the patch!
> > 
> 
> Sure. b15df1ae50 is shortcut and works too. Agree with your change.

Ouch.  I wasn't taking about shortcut or not... I must have pasted a
wrong commit ID of yours. Please forget that.  :)

-- 
Peter Xu

Re: [Qemu-devel] [PATCH v2 0/4] Clean up the ppc configs

[David Gibson]

On Tue, Jan 16, 2018 at 01:15:54PM +0100, Thomas Huth wrote:
> ppc64-softmmu is a superset of ppc-softmmu which in turn is a superset
> of ppcemb-softmmu. But since the config files are currently independent
> from each other, we missed to define some CONFIG switches in the super-
> sets: CONFIG_SUNGEM is missing from the ppc64-softmmu config, and the
> CONFIG_IDE_SII3112 switch is only defined in ppcemb-softmmu.
> 
> This patch series fixes these problems, together with cleaning up
> the config- and make-files for better usability. qemu-system-ppcemb
> is finally marked as deprecated since there is hardly any use case
> for this separate build nowadays anymore (and if somebody really
> still needs page sizes < 4k, we should likely rather use the dynamic
> approach that is already done on the ARM boards instead).

Applied to ppc-for-2.12, thanks.


> 
> v2:
>  - Added patch to disable the PPC4xx boards in the hw/ppc/Makefile
>  - Added patch to deprecate qemu-system-ppcemb
> 
> Thomas Huth (4):
>   default-configs/ppc64-softmmu: Include 32-bit configs instead of
> copying them
>   default-configs/ppc-softmmu: Restructure the switches according to the
> machines
>   hw/ppc/Makefile: Add a way to disable the PPC4xx boards
>   ppc: Deprecate qemu-system-ppcemb
> 
>  default-configs/ppc-softmmu.mak   | 59 -
>  default-configs/ppc64-softmmu.mak | 61 
> +--
>  hw/ppc/Makefile.objs  |  4 +--
>  qemu-doc.texi |  6 
>  target/ppc/translate_init.c   |  5 
>  5 files changed, 53 insertions(+), 82 deletions(-)
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 0/3] target/ppc: add support for hypervisor doorbells

[David Gibson]

On Tue, Jan 16, 2018 at 08:41:54AM +0100, Cédric Le Goater wrote:
> Hi,
> 
> The hypervisor doorbells are used by skiboot and Linux on POWER9
> processors to wake up secondaries. This adds processor control support
> to the Book3S architecture.
> 
> The full tree can be found here :
> 
>   https://github.com/legoater/qemu powernv-2.12

1 & 2 look like correct fixes regardless of anything else, so I've
applied them.  Still looking at 3/3.

> 
> Thanks,
> 
> C.
> 
> Cédric Le Goater (3):
>   target/ppc: fix doorbell and hypervisor doorbell definitions
>   target/ppc: msgsnd and msgclr instructions need hypervisor privilege
>   target/ppc: add support for hypervisor doorbells on book3s CPUs
> 
>  target/ppc/cpu.h| 16 ++--
>  target/ppc/excp_helper.c| 39 ---
>  target/ppc/helper.h |  2 +-
>  target/ppc/translate.c  | 17 ++---
>  target/ppc/translate_init.c |  2 +-
>  5 files changed, 58 insertions(+), 18 deletions(-)
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH] Add ability to provide ifname when using netdev bridge or tap helper

[Jason Wang]

On 2018年01月17日 07:18, Shaun Reitan wrote:

This patch replaces the patch I sent yesturday. This one fixes
a bug in my original code as well as corrects a few styling
issues. Hopfully this one comes out correct!  Sorry for the
inconvienece.
  
When currently using -netdev bridge or -netdev tap with a helper

you are unable to set an ifname. This patch adds that ability so
that you can now specify an ifname.

Signed-off-by: Shaun Reitan 
---
  net/tap.c| 33 -
  qapi/net.json|  1 +
  qemu-bridge-helper.c | 11 +--
  qemu-options.hx  |  2 +-
  4 files changed, 35 insertions(+), 12 deletions(-)



Applied.

Thanks

Re: [Qemu-devel] [PULL 00/25] pc, pci, virtio: features, fixes, cleanups

[Jason Wang]

On 2018年01月16日 16:03, Dmitry Fleytman wrote:



On 16 Jan 2018, at 8:28, Jason Wang  wrote:



On 2018年01月16日 10:48, Michael S. Tsirkin wrote:

On Tue, Jan 09, 2018 at 12:10:10PM +1100, David Gibson wrote:

On Mon, Jan 08, 2018 at 08:10:23PM +0200, Michael S. Tsirkin wrote:

On Mon, Jan 08, 2018 at 09:14:41AM +, Peter Maydell wrote:

On 21 December 2017 at 23:43, Michael S. Tsirkin  wrote:

you also need to drop "hw/pci: remove obsolete PCIDevice->init()"
(applied in your tree as 18951fce55d5aa58cd1629b4cb704ee51bab4420)
else the not-yet-QOM'ified NVME won't work anymore.

Done that too, thanks a lot

Hi. I'm afraid this pullreq (merge of 880b1ff) has new runtime
errors from the clang sanitizer:

/home/petmay01/linaro/qemu-for-merges/hw/net/net_tx_pkt.c:201:27:
runtime error: member access within misaligned address 0x55b4ffee8246
for type 'struct ip_header', which requires 4 byte alignment
0x55b4ffee8246: note: pointer points here
  01 00 00 00 45 00  01 a9 01 00 00 00 40 11  78 45 00 00 00 00 ff ff
ff ff 00 00 00 00 00 00  00 00
  ^
/home/petmay01/linaro/qemu-for-merges/hw/net/net_tx_pkt.c:201:27:
runtime error: load of misaligned address 0x55b4ffee8246 for type
'uint8_t' (aka 'unsigned char'), which requires 4 byte alignment
0x55b4ffee8246: note: pointer points here
  01 00 00 00 45 00  01 a9 01 00 00 00 40 11  78 45 00 00 00 00 ff ff
ff ff 00 00 00 00 00 00  00 00
  ^
/home/petmay01/linaro/qemu-for-merges/hw/net/net_tx_pkt.c:208:65:
runtime error: member access within misaligned address 0x55b4ffee8246
for type 'struct ip_header', which requires 4 byte alignment
0x55b4ffee8246: note: pointer points here
  01 00 00 00 45 00  01 a9 01 00 00 00 40 11  78 45 00 00 00 00 ff ff
ff ff 00 00 00 00 00 00  00 00
  ^
/home/petmay01/linaro/qemu-for-merges/hw/net/net_tx_pkt.c:210:13:
runtime error: member access within misaligned address 0x55b4ffee8246
for type 'struct ip_header', which requires 4 byte alignment
0x55b4ffee8246: note: pointer points here
  01 00 00 00 45 00  01 a9 01 00 00 00 40 11  78 45 00 00 00 00 ff ff
ff ff 00 00 00 00 00 00  00 00
  ^
/home/petmay01/linaro/qemu-for-merges/hw/net/net_tx_pkt.c:210:13:
runtime error: load of misaligned address 0x55b4ffee8246 for type
'uint8_t' (aka 'unsigned char'), which requires 4 byte alignment
0x55b4ffee8246: note: pointer points here
  01 00 00 00 45 00  01 a9 01 00 00 00 40 11  78 45 00 00 00 00 ff ff
ff ff 00 00 00 00 00 00  00 00
  ^

Sorry for the late report, I didn't quite have time
to process the pull before Christmas holidays.

thanks
-- PMM

So I bisected and the reason is this commit:

commit 18b20bb43a2f37f0c8ae23a3e9b3d9a4a05b6bd4
Author: David Gibson 
Date:   Tue Dec 19 15:45:22 2017 +1100

 tests/pxe-test: Add some extra tests
  Previously virtio-net was only tested for ppc64 in "slow" mode.  That
 doesn't make much sense since virtio-net is used much more often in
 practice than the spapr-vlan device which was tested always.  So, move
 virtio-net to always be tested on ppc64.
  We had no tests at all for the q35 machine, which doesn't seem wise
 given its increasing prominence.  Add a couple of tests for it,
 including testing the newer e1000e adapter.
  Signed-off-by: David Gibson 
 Reviewed-by: Thomas Huth 
 Reviewed-by: Michael S. Tsirkin 
 Signed-off-by: Michael S. Tsirkin 

:04 04 5a982bfea24b9ac3c651b84425a39b3c85f4871e 
771af3fdfb2778c6d6ed6b1098d1e79c181d6fb0 M  tests

Pls either fix or drop e1000e test

Feel free to drop this patch for now.  I'll debug and repost it when I
have a chance.

--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson

BTw, Jason, you might want to take a look.
I suspect it's a bug somewhere in the e1000e emulation.


Will have a look.

cc Dmitry for more thoughts.

Not all uint8_t fields in IP header are aligned by 32 bit. Should type of those 
fields be changed to something that does not require alignment?


I'm not quite sure but according to C11 draft 6.3.2.3[1]:

A pointer to an object type may be converted to a pointer to a different 
object type.  If the resulting  pointer  is  not correctly  aligned 68) 
for  the  referenced  type,  the  behavior is undefined.


We should do it.

[1] http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

Thanks




Thanks

Re: [Qemu-devel] [PATCH v4 13/13] docker: change Fedora images to run with python3

[Fam Zheng]

On 01/16/2018 01:02 AM, Daniel P. Berrange wrote:

Fedora has switched to Python 3 by default, so it makes sense to use that
for testing QEMU builds, so we get testing of Python 3 compatibility.

Signed-off-by: Daniel P. Berrange 
---
  tests/docker/dockerfiles/fedora.docker | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/docker/dockerfiles/fedora.docker 
b/tests/docker/dockerfiles/fedora.docker
index 4b26c3aded..a22fe16157 100644
--- a/tests/docker/dockerfiles/fedora.docker
+++ b/tests/docker/dockerfiles/fedora.docker
@@ -1,6 +1,6 @@
  FROM fedora:latest
  ENV PACKAGES \
-ccache gettext git tar PyYAML sparse flex bison python2 bzip2 hostname \
+ccache gettext git tar PyYAML sparse flex bison python3 bzip2 hostname \
  glib2-devel pixman-devel zlib-devel SDL-devel libfdt-devel \
  gcc gcc-c++ clang make perl which bc findutils libaio-devel \
  nettle-devel \
@@ -12,6 +12,7 @@ ENV PACKAGES \
  mingw64-gtk2 mingw64-gtk3 mingw64-gnutls mingw64-nettle mingw64-libtasn1 \
  mingw64-libjpeg-turbo mingw64-libpng mingw64-curl mingw64-libssh2 \
  mingw64-bzip2
+ENV QEMU_CONFIGURE_OPTS --python=/usr/bin/python3
  
  RUN dnf install -y $PACKAGES

  RUN rpm -q $PACKAGES | sort > /packages.txt


QAPI changes stands out in the series' diffstat, so:

Reviewed-by: Fam Zheng 
Acked-by: Fam Zheng 

Re: [Qemu-devel] [PATCH 0/7] docker: update Ubuntu and Fedora images, deprecate old ones

[Fam Zheng]

On 01/12/2018 08:49 PM, Philippe Mathieu-Daudé wrote:

Hi,

This series is to be clearer about which upstream version we are using.

All "FROM distrib:latest" entries have now been removed and replaced by
explicit "FROM distrib:version" ones.

To keep backward compatibility, a warning is displayed to the user,
suggesting which correct base image to use.

To be consistent, we remove the deprecated images of the "make docker" output.


Changing image names when a new release comes out is not maintainable 
for Fedora and Ubuntu because of the fast pace. Therefore I prefer 
Paolo's simple patch.


Maybe you can somehow create an alias in Makefile to point "fedora" to 
"fedora${last_release_num}", and update it when adding a new release. 
But still I don't think keeping more than one fedora dockerfiles is very 
useful.


In principle, we use Debian, CentOS and ubuntu-lts to cover long living 
releases and {ubuntu,fedora}:latest to cover cutting edge releases. 
Spending effort on tests is better than adding more versions, IMO.


Thanks,

Fam



Regards,

Phil.

Philippe Mathieu-Daudé (7):
   docker: sort images list displayed by 'make docker'
   docker: do not display deprecated images in 'make docker' help
   docker: add the Ubuntu Trusty base image
   docker: do not use Trusty APT source in Xenial
   docker: warn users to use ubuntu16.04 for the LTS Xenial image
   docker: add the Fedora 27 base image
   docker: warn users to use newer fedora25/fedora27 base image

  tests/docker/Makefile.include   |  5 -
  tests/docker/dockerfiles/fedora.docker  | 29 -
  tests/docker/dockerfiles/fedora25.docker| 18 ++
  tests/docker/dockerfiles/fedora27.docker| 18 ++
  tests/docker/dockerfiles/ubuntu.docker  | 28 ++--
  tests/docker/dockerfiles/ubuntu14.04.docker | 17 +
  tests/docker/dockerfiles/ubuntu16.04.docker | 16 
  7 files changed, 95 insertions(+), 36 deletions(-)
  create mode 100644 tests/docker/dockerfiles/fedora25.docker
  create mode 100644 tests/docker/dockerfiles/fedora27.docker
  create mode 100644 tests/docker/dockerfiles/ubuntu14.04.docker
  create mode 100644 tests/docker/dockerfiles/ubuntu16.04.docker

[Qemu-devel] [PULL 19/22] ppc/pnv: fix XSCOM core addressing on POWER9

[David Gibson]

From: Cédric Le Goater 

The XSCOM base address of the core chiplet was wrongly calculated. Use
the OPAL macros to fix that and do a couple of renames.

Signed-off-by: Cédric Le Goater 
Signed-off-by: David Gibson 
---
 hw/ppc/pnv.c   | 15 ---
 hw/ppc/pnv_core.c  |  2 +-
 include/hw/ppc/pnv.h   |  1 -
 include/hw/ppc/pnv_xscom.h | 13 +++--
 tests/pnv-xscom-test.c | 27 +--
 5 files changed, 37 insertions(+), 21 deletions(-)

diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index f9591cd41d..80245f57f1 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -721,7 +721,6 @@ static void pnv_chip_power8e_class_init(ObjectClass *klass, 
void *data)
 k->cores_mask = POWER8E_CORE_MASK;
 k->core_pir = pnv_chip_core_pir_p8;
 k->xscom_base = 0x003fc00ull;
-k->xscom_core_base = 0x1000ull;
 dc->desc = "PowerNV Chip POWER8E";
 }
 
@@ -735,7 +734,6 @@ static void pnv_chip_power8_class_init(ObjectClass *klass, 
void *data)
 k->cores_mask = POWER8_CORE_MASK;
 k->core_pir = pnv_chip_core_pir_p8;
 k->xscom_base = 0x003fc00ull;
-k->xscom_core_base = 0x1000ull;
 dc->desc = "PowerNV Chip POWER8";
 }
 
@@ -749,7 +747,6 @@ static void pnv_chip_power8nvl_class_init(ObjectClass 
*klass, void *data)
 k->cores_mask = POWER8_CORE_MASK;
 k->core_pir = pnv_chip_core_pir_p8;
 k->xscom_base = 0x003fc00ull;
-k->xscom_core_base = 0x1000ull;
 dc->desc = "PowerNV Chip POWER8NVL";
 }
 
@@ -763,7 +760,6 @@ static void pnv_chip_power9_class_init(ObjectClass *klass, 
void *data)
 k->cores_mask = POWER9_CORE_MASK;
 k->core_pir = pnv_chip_core_pir_p9;
 k->xscom_base = 0x00603fcull;
-k->xscom_core_base = 0x0ull;
 dc->desc = "PowerNV Chip POWER9";
 }
 
@@ -887,6 +883,7 @@ static void pnv_chip_realize(DeviceState *dev, Error **errp)
  && (i < chip->nr_cores); core_hwid++) {
 char core_name[32];
 void *pnv_core = chip->cores + i * typesize;
+uint64_t xscom_core_base;
 
 if (!(chip->cores_mask & (1ull << core_hwid))) {
 continue;
@@ -910,9 +907,13 @@ static void pnv_chip_realize(DeviceState *dev, Error 
**errp)
 object_unref(OBJECT(pnv_core));
 
 /* Each core has an XSCOM MMIO region */
-pnv_xscom_add_subregion(chip,
-PNV_XSCOM_EX_CORE_BASE(pcc->xscom_core_base,
-   core_hwid),
+if (!pnv_chip_is_power9(chip)) {
+xscom_core_base = PNV_XSCOM_EX_BASE(core_hwid);
+} else {
+xscom_core_base = PNV_XSCOM_P9_EC_BASE(core_hwid);
+}
+
+pnv_xscom_add_subregion(chip, xscom_core_base,
 _CORE(pnv_core)->xscom_regs);
 i++;
 }
diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
index 7e8a76df44..cbb64ad9e7 100644
--- a/hw/ppc/pnv_core.c
+++ b/hw/ppc/pnv_core.c
@@ -192,7 +192,7 @@ 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), _core_xscom_ops,
-  pc, name, PNV_XSCOM_EX_CORE_SIZE);
+  pc, name, PNV_XSCOM_EX_SIZE);
 return;
 
 err:
diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
index f023f1ec99..90759240a7 100644
--- a/include/hw/ppc/pnv.h
+++ b/include/hw/ppc/pnv.h
@@ -74,7 +74,6 @@ typedef struct PnvChipClass {
 uint64_t cores_mask;
 
 hwaddr   xscom_base;
-hwaddr   xscom_core_base;
 
 uint32_t (*core_pir)(PnvChip *chip, uint32_t core_id);
 } PnvChipClass;
diff --git a/include/hw/ppc/pnv_xscom.h b/include/hw/ppc/pnv_xscom.h
index 7252e219e2..fb1bd5df09 100644
--- a/include/hw/ppc/pnv_xscom.h
+++ b/include/hw/ppc/pnv_xscom.h
@@ -21,6 +21,8 @@
 
 #include "qom/object.h"
 
+typedef struct PnvChip PnvChip;
+
 typedef struct PnvXScomInterface {
 Object parent;
 } PnvXScomInterface;
@@ -54,8 +56,15 @@ typedef struct PnvXScomInterfaceClass {
  *   PCB SLAVE   0x110F
  */
 
-#define PNV_XSCOM_EX_CORE_BASE(base, i) ((base) | ((uint64_t)(i) << 24))
-#define PNV_XSCOM_EX_CORE_SIZE0x10
+#define PNV_XSCOM_EX_CORE_BASE0x1000ull
+
+#define PNV_XSCOM_EX_BASE(core) \
+(PNV_XSCOM_EX_CORE_BASE | ((uint64_t)(core) << 24))
+#define PNV_XSCOM_EX_SIZE 0x10
+
+#define PNV_XSCOM_P9_EC_BASE(core) \
+((uint64_t)(((core) & 0x1F) + 0x20) << 24)
+#define PNV_XSCOM_P9_EC_SIZE  0x10
 
 #define PNV_XSCOM_LPC_BASE0xb0020
 #define PNV_XSCOM_LPC_SIZE0x4
diff --git a/tests/pnv-xscom-test.c b/tests/pnv-xscom-test.c
index 9d545c4718..efb7c838b5 100644
--- a/tests/pnv-xscom-test.c
+++ b/tests/pnv-xscom-test.c
@@ -21,7 +21,6 @@ typedef struct PnvChip {
 PnvChipType chip_type;
 const char *cpu_model;
 uint64_t

Re: [Qemu-devel] [PATCH 3/3] linux-user: MIPS set cpu to r6 CPU if binary is R6

[YunQiang Su]

On Sat, Jan 13, 2018 at 10:48 PM, Laurent Vivier  wrote:
> From: YunQiang Su 
>
> So here we need to detect the version of binaries and set
> cpu_model for it.
>
> [lv: original patch modified to move code into get_cpu_model()]
> Signed-off-by: Laurent Vivier 
> ---
>
> Notes:
> YunQiang Su, please add your Signed-off-by that was
> missing in your original patch.

How to add Signed-off-by? Send a v2 for my version of patch?

>
>  include/elf.h |  4 
>  linux-user/main.c | 10 ++
>  2 files changed, 14 insertions(+)
>
> diff --git a/include/elf.h b/include/elf.h
> index e8a515ce3d..f2104809b1 100644
> --- a/include/elf.h
> +++ b/include/elf.h
> @@ -40,6 +40,10 @@ typedef int64_t  Elf64_Sxword;
>  #define EF_MIPS_ARCH_5 0x4000  /* -mips5 code.  */
>  #define EF_MIPS_ARCH_320x5000  /* MIPS32 code.  */
>  #define EF_MIPS_ARCH_640x6000  /* MIPS64 code.  */
> +#define EF_MIPS_ARCH_32R2   0x7000  /* MIPS32r2 code.  */
> +#define EF_MIPS_ARCH_64R2   0x8000  /* MIPS64r2 code.  */
> +#define EF_MIPS_ARCH_32R6   0x9000  /* MIPS32r6 code.  */
> +#define EF_MIPS_ARCH_64R6   0xa000  /* MIPS64r6 code.  */
>
>  /* The ABI of a file. */
>  #define EF_MIPS_ABI_O320x1000  /* O32 ABI.  */
> diff --git a/linux-user/main.c b/linux-user/main.c
> index 2fc2267fd4..3229ef079e 100644
> --- a/linux-user/main.c
> +++ b/linux-user/main.c
> @@ -4285,9 +4285,19 @@ static const char *get_cpu_model(int fd)
>  return "Fujitsu MB86904";
>  #endif
>  #elif defined(TARGET_MIPS)
> +int ret;
> +uint32_t eflags;
> +
> +ret = get_elf_eflags(fd, );
>  #if defined(TARGET_ABI_MIPSN32) || defined(TARGET_ABI_MIPSN64)
> +if (ret == 0 && (eflags & EF_MIPS_ARCH_64R6) != 0) {
> +return "I6400";
> +}
>  return "5KEf";
>  #else
> +if (ret == 0 && (eflags & EF_MIPS_ARCH_32R6) != 0) {
> +return "mips32r6-generic";
> +}
>  return "24Kf";
>  #endif
>  #elif defined TARGET_OPENRISC
> --
> 2.14.3
>

[Qemu-devel] [PULL 18/22] ppc/pnv: introduce pnv*_is_power9() helpers

[David Gibson]

From: Cédric Le Goater 

These are useful when instantiating device models which are shared
between the POWER8 and the POWER9 processor families.

Signed-off-by: Cédric Le Goater 
Signed-off-by: David Gibson 
---
 hw/ppc/pnv_xscom.c   |  8 +++-
 include/hw/ppc/pnv.h | 10 ++
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/hw/ppc/pnv_xscom.c b/hw/ppc/pnv_xscom.c
index e51d634f40..99c40efecd 100644
--- a/hw/ppc/pnv_xscom.c
+++ b/hw/ppc/pnv_xscom.c
@@ -51,10 +51,9 @@ static void xscom_complete(CPUState *cs, uint64_t hmer_bits)
 
 static uint32_t pnv_xscom_pcba(PnvChip *chip, uint64_t addr)
 {
-PnvChipClass *pcc = PNV_CHIP_GET_CLASS(chip);
-
 addr &= (PNV_XSCOM_SIZE - 1);
-if (pcc->chip_type == PNV_CHIP_POWER9) {
+
+if (pnv_chip_is_power9(chip)) {
 return addr >> 3;
 } else {
 return ((addr >> 4) & ~0xfull) | ((addr >> 3) & 0xf);
@@ -231,7 +230,6 @@ int pnv_dt_xscom(PnvChip *chip, void *fdt, int root_offset)
 int xscom_offset;
 ForeachPopulateArgs args;
 char *name;
-PnvChipClass *pcc = PNV_CHIP_GET_CLASS(chip);
 
 name = g_strdup_printf("xscom@%" PRIx64, be64_to_cpu(reg[0]));
 xscom_offset = fdt_add_subnode(fdt, root_offset, name);
@@ -242,7 +240,7 @@ int pnv_dt_xscom(PnvChip *chip, void *fdt, int root_offset)
 _FDT((fdt_setprop_cell(fdt, xscom_offset, "#size-cells", 1)));
 _FDT((fdt_setprop(fdt, xscom_offset, "reg", reg, sizeof(reg;
 
-if (pcc->chip_type == PNV_CHIP_POWER9) {
+if (pnv_chip_is_power9(chip)) {
 _FDT((fdt_setprop(fdt, xscom_offset, "compatible", compat_p9,
   sizeof(compat_p9;
 } else {
diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
index 61896f9fd7..f023f1ec99 100644
--- a/include/hw/ppc/pnv.h
+++ b/include/hw/ppc/pnv.h
@@ -138,6 +138,16 @@ typedef struct PnvMachineState {
 Notifier powerdown_notifier;
 } PnvMachineState;
 
+static inline bool pnv_chip_is_power9(const PnvChip *chip)
+{
+return PNV_CHIP_GET_CLASS(chip)->chip_type == PNV_CHIP_POWER9;
+}
+
+static inline bool pnv_is_power9(PnvMachineState *pnv)
+{
+return pnv_chip_is_power9(pnv->chips[0]);
+}
+
 #define PNV_FDT_ADDR  0x0100
 #define PNV_TIMEBASE_FREQ 51200ULL
 
-- 
2.14.3

[Qemu-devel] [PULL 08/22] hw/ppc/spapr_caps: Rework spapr_caps to use uint8 internal representation

[David Gibson]

From: Suraj Jitindar Singh 

Currently spapr_caps are tied to boolean values (on or off). This patch
reworks the caps so that they can have any uint8 value. This allows more
capabilities with various values to be represented in the same way
internally. Capabilities are numbered in ascending order. The internal
representation of capability values is an array of uint8s in the
sPAPRMachineState, indexed by capability number.

Capabilities can have their own name, description, options, getter and
setter functions, type and allow functions. They also each have their own
section in the migration stream. Capabilities are only migrated if they
were explictly set on the command line, with the assumption that
otherwise the default will match.

On migration we ensure that the capability value on the destination
is greater than or equal to the capability value from the source. So
long at this remains the case then the migration is considered
compatible and allowed to continue.

This patch implements generic getter and setter functions for boolean
capabilities. It also converts the existings cap-htm, cap-vsx and
cap-dfp capabilities to this new format.

Signed-off-by: David Gibson 
---
 hw/ppc/spapr.c |  45 +--
 hw/ppc/spapr_caps.c| 322 +
 include/hw/ppc/spapr.h |  45 +++
 3 files changed, 225 insertions(+), 187 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index d1acfe8858..3e528fe91e 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -320,7 +320,7 @@ static void spapr_populate_pa_features(sPAPRMachineState 
*spapr,
  */
 pa_features[3] |= 0x20;
 }
-if (spapr_has_cap(spapr, SPAPR_CAP_HTM) && pa_size > 24) {
+if ((spapr_get_cap(spapr, SPAPR_CAP_HTM) != 0) && pa_size > 24) {
 pa_features[24] |= 0x80;/* Transactional memory support */
 }
 if (legacy_guest && pa_size > 40) {
@@ -563,7 +563,7 @@ static void spapr_populate_cpu_dt(CPUState *cs, void *fdt, 
int offset,
  *
  * Only CPUs for which we create core types in spapr_cpu_core.c
  * are possible, and all of those have VMX */
-if (spapr_has_cap(spapr, SPAPR_CAP_VSX)) {
+if (spapr_get_cap(spapr, SPAPR_CAP_VSX) != 0) {
 _FDT((fdt_setprop_cell(fdt, offset, "ibm,vmx", 2)));
 } else {
 _FDT((fdt_setprop_cell(fdt, offset, "ibm,vmx", 1)));
@@ -572,7 +572,7 @@ static void spapr_populate_cpu_dt(CPUState *cs, void *fdt, 
int offset,
 /* Advertise DFP (Decimal Floating Point) if available
  *   0 / no property == no DFP
  *   1   == DFP available */
-if (spapr_has_cap(spapr, SPAPR_CAP_DFP)) {
+if (spapr_get_cap(spapr, SPAPR_CAP_DFP) != 0) {
 _FDT((fdt_setprop_cell(fdt, offset, "ibm,dfp", 1)));
 }
 
@@ -1586,6 +1586,18 @@ static bool spapr_vga_init(PCIBus *pci_bus, Error **errp)
 }
 }
 
+static int spapr_pre_load(void *opaque)
+{
+int rc;
+
+rc = spapr_caps_pre_load(opaque);
+if (rc) {
+return rc;
+}
+
+return 0;
+}
+
 static int spapr_post_load(void *opaque, int version_id)
 {
 sPAPRMachineState *spapr = (sPAPRMachineState *)opaque;
@@ -1627,6 +1639,18 @@ static int spapr_post_load(void *opaque, int version_id)
 return err;
 }
 
+static int spapr_pre_save(void *opaque)
+{
+int rc;
+
+rc = spapr_caps_pre_save(opaque);
+if (rc) {
+return rc;
+}
+
+return 0;
+}
+
 static bool version_before_3(void *opaque, int version_id)
 {
 return version_id < 3;
@@ -1747,7 +1771,9 @@ static const VMStateDescription vmstate_spapr = {
 .name = "spapr",
 .version_id = 3,
 .minimum_version_id = 1,
+.pre_load = spapr_pre_load,
 .post_load = spapr_post_load,
+.pre_save = spapr_pre_save,
 .fields = (VMStateField[]) {
 /* used to be @next_irq */
 VMSTATE_UNUSED_BUFFER(version_before_3, 0, 4),
@@ -1762,7 +1788,9 @@ static const VMStateDescription vmstate_spapr = {
 _spapr_ov5_cas,
 _spapr_patb_entry,
 _spapr_pending_events,
-_spapr_caps,
+_spapr_cap_htm,
+_spapr_cap_vsx,
+_spapr_cap_dfp,
 NULL
 }
 };
@@ -2323,8 +2351,6 @@ static void spapr_machine_init(MachineState *machine)
 char *filename;
 Error *resize_hpt_err = NULL;
 
-spapr_caps_validate(spapr, _fatal);
-
 msi_nonbroken = true;
 
 QLIST_INIT(>phbs);
@@ -3834,7 +3860,9 @@ static void spapr_machine_class_init(ObjectClass *oc, 
void *data)
  */
 mc->numa_mem_align_shift = 28;
 
-smc->default_caps = spapr_caps(SPAPR_CAP_VSX | SPAPR_CAP_DFP);
+smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_OFF;
+smc->default_caps.caps[SPAPR_CAP_VSX] = SPAPR_CAP_ON;
+smc->default_caps.caps[SPAPR_CAP_DFP] = SPAPR_CAP_ON;
 spapr_caps_add_properties(smc, _abort);
 }
 
@@ -3916,8 +3944,7 @@ static void spapr_machine_2_11_class_options(MachineClass 
*mc)
 sPAPRMachineClass 

[Qemu-devel] [PULL 21/22] target/ppc: add support for POWER9 HILE

[David Gibson]

From: Cédric Le Goater 

Signed-off-by: Cédric Le Goater 
Signed-off-by: David Gibson 
---
 target/ppc/cpu.h | 1 +
 target/ppc/excp_helper.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
index dc6820c5eb..14aaa87fe8 100644
--- a/target/ppc/cpu.h
+++ b/target/ppc/cpu.h
@@ -2012,6 +2012,7 @@ void ppc_compat_add_property(Object *obj, const char 
*name,
 #define HID0_DOZE   (1 << 23)   /* pre-2.06 */
 #define HID0_NAP(1 << 22)   /* pre-2.06 */
 #define HID0_HILE   PPC_BIT(19) /* POWER8 */
+#define HID0_POWER9_HILEPPC_BIT(4)
 
 /*/
 /* PowerPC Instructions types definitions*/
diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
index 37d2410726..4e548a4487 100644
--- a/target/ppc/excp_helper.c
+++ b/target/ppc/excp_helper.c
@@ -654,7 +654,7 @@ static inline void powerpc_excp(PowerPCCPU *cpu, int 
excp_model, int excp)
 }
 } else if (excp_model == POWERPC_EXCP_POWER8) {
 if (new_msr & MSR_HVB) {
-if (env->spr[SPR_HID0] & HID0_HILE) {
+if (env->spr[SPR_HID0] & (HID0_HILE | HID0_POWER9_HILE)) {
 new_msr |= (target_ulong)1 << MSR_LE;
 }
 } else if (env->spr[SPR_LPCR] & LPCR_ILE) {
-- 
2.14.3

[Qemu-devel] [PULL 16/22] ppc/pnv: use POWER9 DD2 processor

[David Gibson]

From: Cédric Le Goater 

commit 1ed9c8af501f ("target/ppc: Add POWER9 DD2.0 model information")
deprecated the POWER9 model v1.0.

Signed-off-by: Cédric Le Goater 
Signed-off-by: David Gibson 
---
 hw/ppc/pnv.c   | 2 +-
 tests/pnv-xscom-test.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 9475e8479c..536162b274 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -759,7 +759,7 @@ static void pnv_chip_power9_class_init(ObjectClass *klass, 
void *data)
 PnvChipClass *k = PNV_CHIP_CLASS(klass);
 
 k->chip_type = PNV_CHIP_POWER9;
-k->chip_cfam_id = 0x100d10498000ull; /* P9 Nimbus DD1.0 */
+k->chip_cfam_id = 0x220d10498000ull; /* P9 Nimbus DD2.0 */
 k->cores_mask = POWER9_CORE_MASK;
 k->core_pir = pnv_chip_core_pir_p9;
 k->xscom_base = 0x00603fcull;
diff --git a/tests/pnv-xscom-test.c b/tests/pnv-xscom-test.c
index 89fa6282d3..a1a119c091 100644
--- a/tests/pnv-xscom-test.c
+++ b/tests/pnv-xscom-test.c
@@ -48,7 +48,7 @@ static const PnvChip pnv_chips[] = {
 .cpu_model  = "POWER9",
 .xscom_base = 0x000603fcull,
 .xscom_core_base = 0x0ull,
-.cfam_id= 0x100d10498000ull,
+.cfam_id= 0x220d10498000ull,
 .first_core = 0x20,
 },
 #endif
-- 
2.14.3

[Qemu-devel] [PULL 03/22] spapr: Treat Hardware Transactional Memory (HTM) as an optional capability

[David Gibson]

This adds an spapr capability bit for Hardware Transactional Memory.  It is
enabled by default for pseries-2.11 and earlier machine types. with POWER8
or later CPUs (as it must be, since earlier qemu versions would implicitly
allow it).  However it is disabled by default for the latest pseries-2.12
machine type.

This means that with the latest machine type, HTM will not be available,
regardless of CPU, unless it is explicitly enabled on the command line.
That change is made on the basis that:

 * This way running with -M pseries,accel=tcg will start with whatever cpu
   and will provide the same guest visible model as with accel=kvm.
 - More specifically, this means existing make check tests don't have
   to be modified to use cap-htm=off in order to run with TCG

 * We hope to add a new "HTM without suspend" feature in the not too
   distant future which could work on both POWER8 and POWER9 cpus, and
   could be enabled by default.

 * Best guesses suggest that future POWER cpus may well only support the
   HTM-without-suspend model, not the (frankly, horribly overcomplicated)
   POWER8 style HTM with suspend.

 * Anecdotal evidence suggests problems with HTM being enabled when it
   wasn't wanted are more common than being missing when it was.

Signed-off-by: David Gibson 
Reviewed-by: Greg Kurz 
---
 hw/ppc/spapr.c | 15 ++-
 hw/ppc/spapr_caps.c| 29 -
 include/hw/ppc/spapr.h |  3 +++
 3 files changed, 41 insertions(+), 6 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index a6cf1234d8..73310bd3ee 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -253,7 +253,9 @@ static int spapr_fixup_cpu_numa_dt(void *fdt, int offset, 
PowerPCCPU *cpu)
 }
 
 /* Populate the "ibm,pa-features" property */
-static void spapr_populate_pa_features(PowerPCCPU *cpu, void *fdt, int offset,
+static void spapr_populate_pa_features(sPAPRMachineState *spapr,
+   PowerPCCPU *cpu,
+   void *fdt, int offset,
bool legacy_guest)
 {
 CPUPPCState *env = >env;
@@ -318,7 +320,7 @@ static void spapr_populate_pa_features(PowerPCCPU *cpu, 
void *fdt, int offset,
  */
 pa_features[3] |= 0x20;
 }
-if (kvmppc_has_cap_htm() && pa_size > 24) {
+if (spapr_has_cap(spapr, SPAPR_CAP_HTM) && pa_size > 24) {
 pa_features[24] |= 0x80;/* Transactional memory support */
 }
 if (legacy_guest && pa_size > 40) {
@@ -384,8 +386,8 @@ static int spapr_fixup_cpu_dt(void *fdt, sPAPRMachineState 
*spapr)
 return ret;
 }
 
-spapr_populate_pa_features(cpu, fdt, offset,
- spapr->cas_legacy_guest_workaround);
+spapr_populate_pa_features(spapr, cpu, fdt, offset,
+   spapr->cas_legacy_guest_workaround);
 }
 return ret;
 }
@@ -579,7 +581,7 @@ static void spapr_populate_cpu_dt(CPUState *cs, void *fdt, 
int offset,
   page_sizes_prop, page_sizes_prop_size)));
 }
 
-spapr_populate_pa_features(cpu, fdt, offset, false);
+spapr_populate_pa_features(spapr, cpu, fdt, offset, false);
 
 _FDT((fdt_setprop_cell(fdt, offset, "ibm,chip-id",
cs->cpu_index / vcpus_per_socket)));
@@ -3903,7 +3905,10 @@ static void 
spapr_machine_2_11_instance_options(MachineState *machine)
 
 static void spapr_machine_2_11_class_options(MachineClass *mc)
 {
+sPAPRMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
+
 spapr_machine_2_12_class_options(mc);
+smc->default_caps = spapr_caps(SPAPR_CAP_HTM);
 SET_MACHINE_COMPAT(mc, SPAPR_COMPAT_2_11);
 }
 
diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
index 968ba7b857..3b35b91a5b 100644
--- a/hw/ppc/spapr_caps.c
+++ b/hw/ppc/spapr_caps.c
@@ -24,6 +24,10 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
 #include "qapi/visitor.h"
+#include "sysemu/hw_accel.h"
+#include "target/ppc/cpu.h"
+#include "cpu-models.h"
+#include "kvm_ppc.h"
 
 #include "hw/ppc/spapr.h"
 
@@ -40,18 +44,41 @@ typedef struct sPAPRCapabilityInfo {
 void (*disallow)(sPAPRMachineState *spapr, Error **errp);
 } sPAPRCapabilityInfo;
 
+static void cap_htm_allow(sPAPRMachineState *spapr, Error **errp)
+{
+if (tcg_enabled()) {
+error_setg(errp,
+   "No Transactional Memory support in TCG, try cap-htm=off");
+} else if (kvm_enabled() && !kvmppc_has_cap_htm()) {
+error_setg(errp,
+"KVM implementation does not support Transactional Memory, try cap-htm=off"
+);
+}
+}
+
 static sPAPRCapabilityInfo capability_table[] = {
+{
+.name = "htm",
+.description = "Allow Hardware Transactional Memory (HTM)",
+.flag = SPAPR_CAP_HTM,
+.allow = cap_htm_allow,
+/* TODO: add cap_htm_disallow */
+},
 };
 
 static sPAPRCapabilities 

[Qemu-devel] [PULL 22/22] target-ppc: Fix booke206 tlbwe TLB instruction

[David Gibson]

From: Luc MICHEL 

When overwritting a valid TLB entry with a new one, the previous page
were not flushed in QEMU TLB, leading to incoherent mapping. This commit
fixes this.

Signed-off-by: Luc MICHEL 
Signed-off-by: David Gibson 
---
 target/ppc/mmu_helper.c | 32 +++-
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/target/ppc/mmu_helper.c b/target/ppc/mmu_helper.c
index 2a1f9902c9..298c15e961 100644
--- a/target/ppc/mmu_helper.c
+++ b/target/ppc/mmu_helper.c
@@ -2570,6 +2570,17 @@ void helper_booke_setpid(CPUPPCState *env, uint32_t 
pidn, target_ulong pid)
 tlb_flush(CPU(cpu));
 }
 
+static inline void flush_page(CPUPPCState *env, ppcmas_tlb_t *tlb)
+{
+PowerPCCPU *cpu = ppc_env_get_cpu(env);
+
+if (booke206_tlb_to_page_size(env, tlb) == TARGET_PAGE_SIZE) {
+tlb_flush_page(CPU(cpu), tlb->mas2 & MAS2_EPN_MASK);
+} else {
+tlb_flush(CPU(cpu));
+}
+}
+
 void helper_booke206_tlbwe(CPUPPCState *env)
 {
 PowerPCCPU *cpu = ppc_env_get_cpu(env);
@@ -2628,6 +2639,21 @@ void helper_booke206_tlbwe(CPUPPCState *env)
 if (msr_gs) {
 cpu_abort(CPU(cpu), "missing HV implementation\n");
 }
+
+if (tlb->mas1 & MAS1_VALID) {
+/* Invalidate the page in QEMU TLB if it was a valid entry.
+ *
+ * In "PowerPC e500 Core Family Reference Manual, Rev. 1",
+ * Section "12.4.2 TLB Write Entry (tlbwe) Instruction":
+ * (https://www.nxp.com/docs/en/reference-manual/E500CORERM.pdf)
+ *
+ * "Note that when an L2 TLB entry is written, it may be displacing an
+ * already valid entry in the same L2 TLB location (a victim). If a
+ * valid L1 TLB entry corresponds to the L2 MMU victim entry, that L1
+ * TLB entry is automatically invalidated." */
+flush_page(env, tlb);
+}
+
 tlb->mas7_3 = ((uint64_t)env->spr[SPR_BOOKE_MAS7] << 32) |
 env->spr[SPR_BOOKE_MAS3];
 tlb->mas1 = env->spr[SPR_BOOKE_MAS1];
@@ -2663,11 +2689,7 @@ void helper_booke206_tlbwe(CPUPPCState *env)
 tlb->mas1 &= ~MAS1_IPROT;
 }
 
-if (booke206_tlb_to_page_size(env, tlb) == TARGET_PAGE_SIZE) {
-tlb_flush_page(CPU(cpu), tlb->mas2 & MAS2_EPN_MASK);
-} else {
-tlb_flush(CPU(cpu));
-}
+flush_page(env, tlb);
 }
 
 static inline void booke206_tlb_to_mas(CPUPPCState *env, ppcmas_tlb_t *tlb)
-- 
2.14.3

[Qemu-devel] [PULL 13/22] spapr: Adjust default VSMT value for better migration compatibility

[David Gibson]

fa98fbfc "PC: KVM: Support machine option to set VSMT mode" introduced the
"vsmt" parameter for the pseries machine type, which controls the spacing
of the vcpu ids of thread 0 for each virtual core.  This was done to bring
some consistency and stability to how that was done, while still allowing
backwards compatibility for migration and otherwise.

The default value we used for vsmt was set to the max of the host's
advertised default number of threads and the number of vthreads per vcore
in the guest.  This was done to continue running without extra parameters
on older KVM versions which don't allow the VSMT value to be changed.

Unfortunately, even that smaller than before leakage of host configuration
into guest visible configuration still breaks things.  Specifically a guest
with 4 (or less) vthread/vcore will get a different vsmt value when
running on a POWER8 (vsmt==8) and POWER9 (vsmt==4) host.  That means the
vcpu ids don't line up so you can't migrate between them, though you should
be able to.

Long term we really want to make vsmt == smp_threads for sufficiently
new machine types.  However, that means that qemu will then require a
sufficiently recent KVM (one which supports changing VSMT) - that's still
not widely enough deployed to be really comfortable to do.

In the meantime we need some default that will work as often as
possible.  This patch changes that default to 8 in all circumstances.
This does change guest visible behaviour (including for existing
machine versions) for many cases - just not the most common/important
case.

Following is case by case justification for why this is still the least
worst option.  Note that any of the old behaviours can still be duplicated
after this patch, it's just that it requires manual intervention by
setting the vsmt property on the command line.

KVM HV on POWER8 host:
   This is the overwhelmingly common case in production setups, and is
   unchanged by design.  POWER8 hosts will advertise a default VSMT mode
   of 8, and > 8 vthreads/vcore isn't permitted

KVM HV on POWER7 host:
   Will break, but POWER7s allowing KVM were never released to the public.

KVM HV on POWER9 host:
   Not yet released to the public, breaking this now will reduce other
   breakage later.

KVM HV on PowerPC 970:
   Will theoretically break it, but it was barely supported to begin with
   and already required various user visible hacks to work.  Also so old
   that I just don't care.

TCG:
   This is the nastiest one; it means migration of TCG guests (without
   manual vsmt setting) will break.  Since TCG is rarely used in production
   I think this is worth it for the other benefits.  It does also remove
   one more barrier to TCG<->KVM migration which could be interesting for
   debugging applications.

KVM PR:
   As with TCG, this will break migration of existing configurations,
   without adding extra manual vsmt options.  As with TCG, it is rare in
   production so I think the benefits outweigh breakages.

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
Reviewed-by: Jose Ricardo Ziviani 
Reviewed-by: Greg Kurz 
---
 hw/ppc/spapr.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 9e7088a192..499ab647d8 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2305,9 +2305,14 @@ static void spapr_set_vsmt_mode(sPAPRMachineState 
*spapr, Error **errp)
 }
 /* In this case, spapr->vsmt has been set by the command line */
 } else {
-/* Choose a VSMT mode that may be higher than necessary but is
- * likely to be compatible with hosts that don't have VSMT. */
-spapr->vsmt = MAX(kvm_smt, smp_threads);
+/*
+ * Default VSMT value is tricky, because we need it to be as
+ * consistent as possible (for migration), but this requires
+ * changing it for at least some existing cases.  We pick 8 as
+ * the value that we'd get with KVM on POWER8, the
+ * overwhelmingly common case in production systems.
+ */
+spapr->vsmt = 8;
 }
 
 /* KVM: If necessary, set the SMT mode: */
-- 
2.14.3

[Qemu-devel] [PULL 12/22] spapr: Allow some cases where we can't set VSMT mode in the kernel

[David Gibson]

At present if we require a vsmt mode that's not equal to the kernel's
default, and the kernel doesn't let us change it (e.g. because it's an old
kernel without support) then we always fail.

But in fact we can cope with the kernel having a different vsmt as long as
  a) it's >= the actual number of vthreads/vcore (so that guest threads
 that are supposed to be on the same core act like it)
  b) it's a submultiple of the requested vsmt mode (so that guest threads
 spaced by the vsmt value will act like they're on different cores)

Allowing this case gives us a bit more freedom to adjust the vsmt behaviour
without breaking existing cases.

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
Tested-by: Greg Kurz 
Reviewed-by: Greg Kurz 
---
 hw/ppc/spapr.c | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index e35214bfc3..9e7088a192 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2314,17 +2314,29 @@ static void spapr_set_vsmt_mode(sPAPRMachineState 
*spapr, Error **errp)
 if (kvm_enabled() && (spapr->vsmt != kvm_smt)) {
 ret = kvmppc_set_smt_threads(spapr->vsmt);
 if (ret) {
+/* Looks like KVM isn't able to change VSMT mode */
 error_setg(_err,
"Failed to set KVM's VSMT mode to %d (errno %d)",
spapr->vsmt, ret);
-if (!vsmt_user) {
-error_append_hint(_err, "On PPC, a VM with %d threads/"
- "core on a host with %d threads/core requires "
- " the use of VSMT mode %d.\n",
- smp_threads, kvm_smt, spapr->vsmt);
+/* We can live with that if the default one is big enough
+ * for the number of threads, and a submultiple of the one
+ * we want.  In this case we'll waste some vcpu ids, but
+ * behaviour will be correct */
+if ((kvm_smt >= smp_threads) && ((spapr->vsmt % kvm_smt) == 0)) {
+warn_report_err(local_err);
+local_err = NULL;
+goto out;
+} else {
+if (!vsmt_user) {
+error_append_hint(_err,
+  "On PPC, a VM with %d threads/core"
+  " on a host with %d threads/core"
+  " requires the use of VSMT mode %d.\n",
+  smp_threads, kvm_smt, spapr->vsmt);
+}
+kvmppc_hint_smt_possible(_err);
+goto out;
 }
-kvmppc_hint_smt_possible(_err);
-goto out;
 }
 }
 /* else TCG: nothing to do currently */
-- 
2.14.3

[Qemu-devel] [PULL 05/22] target/ppc: Clean up probing of VMX, VSX and DFP availability on KVM

[David Gibson]

When constructing the "host" cpu class we modify whether the VMX and VSX
vector extensions and DFP (Decimal Floating Point) are available
based on whether KVM can support those instructions.  This can depend on
policy in the host kernel as well as on the actual host cpu capabilities.

However, the way we probe for this is not very nice: we explicitly check
the host's device tree.  That works in practice, but it's not really
correct, since the device tree is a property of the host kernel's platform
which we don't really know about.  We get away with it because the only
modern POWER platforms happen to encode VMX, VSX and DFP availability in
the device tree in the same way.

Arguably we should have an explicit KVM capability for this, but we haven't
needed one so far.  Barring specific KVM policies which don't yet exist,
each of these instruction classes will be available in the guest if and
only if they're available in the qemu userspace process.  We can determine
that from the ELF AUX vector we're supplied with.

Once reworked like this, there are no more callers for kvmppc_get_vmx() and
kvmppc_get_dfp() so remove them.

Signed-off-by: David Gibson 
Reviewed-by: Greg Kurz 
---
 target/ppc/kvm.c | 27 ++-
 target/ppc/kvm_ppc.h |  2 --
 2 files changed, 6 insertions(+), 23 deletions(-)

diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index 09fcb082d2..914be687e7 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -2011,16 +2011,6 @@ uint64_t kvmppc_get_clockfreq(void)
 return kvmppc_read_int_cpu_dt("clock-frequency");
 }
 
-uint32_t kvmppc_get_vmx(void)
-{
-return kvmppc_read_int_cpu_dt("ibm,vmx");
-}
-
-uint32_t kvmppc_get_dfp(void)
-{
-return kvmppc_read_int_cpu_dt("ibm,dfp");
-}
-
 static int kvmppc_get_pvinfo(CPUPPCState *env, struct kvm_ppc_pvinfo *pvinfo)
  {
  PowerPCCPU *cpu = ppc_env_get_cpu(env);
@@ -2404,23 +2394,18 @@ static void alter_insns(uint64_t *word, uint64_t flags, 
bool on)
 static void kvmppc_host_cpu_class_init(ObjectClass *oc, void *data)
 {
 PowerPCCPUClass *pcc = POWERPC_CPU_CLASS(oc);
-uint32_t vmx = kvmppc_get_vmx();
-uint32_t dfp = kvmppc_get_dfp();
 uint32_t dcache_size = kvmppc_read_int_cpu_dt("d-cache-size");
 uint32_t icache_size = kvmppc_read_int_cpu_dt("i-cache-size");
 
 /* Now fix up the class with information we can query from the host */
 pcc->pvr = mfpvr();
 
-if (vmx != -1) {
-/* Only override when we know what the host supports */
-alter_insns(>insns_flags, PPC_ALTIVEC, vmx > 0);
-alter_insns(>insns_flags2, PPC2_VSX, vmx > 1);
-}
-if (dfp != -1) {
-/* Only override when we know what the host supports */
-alter_insns(>insns_flags2, PPC2_DFP, dfp);
-}
+alter_insns(>insns_flags, PPC_ALTIVEC,
+qemu_getauxval(AT_HWCAP) & PPC_FEATURE_HAS_ALTIVEC);
+alter_insns(>insns_flags2, PPC2_VSX,
+qemu_getauxval(AT_HWCAP) & PPC_FEATURE_HAS_VSX);
+alter_insns(>insns_flags2, PPC2_DFP,
+qemu_getauxval(AT_HWCAP) & PPC_FEATURE_HAS_DFP);
 
 if (dcache_size != -1) {
 pcc->l1_dcache_size = dcache_size;
diff --git a/target/ppc/kvm_ppc.h b/target/ppc/kvm_ppc.h
index d6be38ecaf..ecb55493cc 100644
--- a/target/ppc/kvm_ppc.h
+++ b/target/ppc/kvm_ppc.h
@@ -15,8 +15,6 @@
 
 uint32_t kvmppc_get_tbfreq(void);
 uint64_t kvmppc_get_clockfreq(void);
-uint32_t kvmppc_get_vmx(void);
-uint32_t kvmppc_get_dfp(void);
 bool kvmppc_get_host_model(char **buf);
 bool kvmppc_get_host_serial(char **buf);
 int kvmppc_get_hasidle(CPUPPCState *env);
-- 
2.14.3

[Qemu-devel] [PULL 20/22] ppc/pnv: change initrd address

[David Gibson]

From: Cédric Le Goater 

When skiboot starts, it first clears the CPU structs for all possible
CPUs on a system :

for (i = 0; i <= cpu_max_pir; i++)
memset(_stacks[i].cpu, 0, sizeof(struct cpu_thread));

On POWER9, cpu_max_pir is quite big, 0x7fff, and the skiboot cpu_stacks
array overlaps with the memory region in which QEMU maps the initramfs
file. Move it upwards in memory to keep it safe.

Signed-off-by: Cédric Le Goater 
Signed-off-by: David Gibson 
---
 hw/ppc/pnv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 80245f57f1..98ee3c607a 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -53,7 +53,7 @@
 #define FW_MAX_SIZE 0x0040
 
 #define KERNEL_LOAD_ADDR0x2000
-#define INITRD_LOAD_ADDR0x4000
+#define INITRD_LOAD_ADDR0x6000
 
 static const char *pnv_chip_core_typename(const PnvChip *o)
 {
-- 
2.14.3

[Qemu-devel] [PULL 17/22] ppc/pnv: change core mask for POWER9

[David Gibson]

From: Cédric Le Goater 

When addressed by XSCOM, the first core has the 0x20 chiplet ID but
the CPU PIR can start at 0x0.

Signed-off-by: Cédric Le Goater 
Signed-off-by: David Gibson 
---
 hw/ppc/pnv.c   | 4 ++--
 tests/pnv-xscom-test.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 536162b274..f9591cd41d 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -707,9 +707,9 @@ static uint32_t pnv_chip_core_pir_p9(PnvChip *chip, 
uint32_t core_id)
 #define POWER8_CORE_MASK   (0x7e7eull)
 
 /*
- * POWER9 has 24 cores, ids starting at 0x20
+ * POWER9 has 24 cores, ids starting at 0x0
  */
-#define POWER9_CORE_MASK   (0xffull)
+#define POWER9_CORE_MASK   (0xffull)
 
 static void pnv_chip_power8e_class_init(ObjectClass *klass, void *data)
 {
diff --git a/tests/pnv-xscom-test.c b/tests/pnv-xscom-test.c
index a1a119c091..9d545c4718 100644
--- a/tests/pnv-xscom-test.c
+++ b/tests/pnv-xscom-test.c
@@ -49,7 +49,7 @@ static const PnvChip pnv_chips[] = {
 .xscom_base = 0x000603fcull,
 .xscom_core_base = 0x0ull,
 .cfam_id= 0x220d10498000ull,
-.first_core = 0x20,
+.first_core = 0x0,
 },
 #endif
 };
-- 
2.14.3

[Qemu-devel] [PULL 11/22] target/ppc: Clarify compat mode max_threads value

[David Gibson]

We recently had some discussions that were sidetracked for a while, because
nearly everyone misapprehended the purpose of the 'max_threads' field in
the compatiblity modes table.  It's all about guest expectations, not host
expectations or support (that's handled elsewhere).

In an attempt to avoid a repeat of that confusion, rename the field to
'max_vthreads' and add an explanatory comment.

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
Reviewed-by: Greg Kurz 
Reviewed-by: Jose Ricardo Ziviani 
---
 hw/ppc/spapr.c  |  4 ++--
 target/ppc/compat.c | 25 +
 target/ppc/cpu.h|  2 +-
 3 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 3e528fe91e..e35214bfc3 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -345,7 +345,7 @@ static int spapr_fixup_cpu_dt(void *fdt, sPAPRMachineState 
*spapr)
 PowerPCCPU *cpu = POWERPC_CPU(cs);
 DeviceClass *dc = DEVICE_GET_CLASS(cs);
 int index = spapr_vcpu_id(cpu);
-int compat_smt = MIN(smp_threads, ppc_compat_max_threads(cpu));
+int compat_smt = MIN(smp_threads, ppc_compat_max_vthreads(cpu));
 
 if ((index % smt) != 0) {
 continue;
@@ -503,7 +503,7 @@ static void spapr_populate_cpu_dt(CPUState *cs, void *fdt, 
int offset,
 size_t page_sizes_prop_size;
 uint32_t vcpus_per_socket = smp_threads * smp_cores;
 uint32_t pft_size_prop[] = {0, cpu_to_be32(spapr->htab_shift)};
-int compat_smt = MIN(smp_threads, ppc_compat_max_threads(cpu));
+int compat_smt = MIN(smp_threads, ppc_compat_max_vthreads(cpu));
 sPAPRDRConnector *drc;
 int drc_index;
 uint32_t radix_AP_encodings[PPC_PAGE_SIZES_MAX_SZ];
diff --git a/target/ppc/compat.c b/target/ppc/compat.c
index 276b5b52c2..807c906f68 100644
--- a/target/ppc/compat.c
+++ b/target/ppc/compat.c
@@ -32,7 +32,16 @@ typedef struct {
 uint32_t pvr;
 uint64_t pcr;
 uint64_t pcr_level;
-int max_threads;
+
+/*
+ * Maximum allowed virtual threads per virtual core
+ *
+ * This is to stop older guests getting confused by seeing more
+ * threads than they think the cpu can support.  Usually it's
+ * equal to the number of threads supported on bare metal
+ * hardware, but not always (see POWER9).
+ */
+int max_vthreads;
 } CompatInfo;
 
 static const CompatInfo compat_table[] = {
@@ -45,28 +54,28 @@ static const CompatInfo compat_table[] = {
 .pcr = PCR_COMPAT_3_00 | PCR_COMPAT_2_07 | PCR_COMPAT_2_06 |
PCR_COMPAT_2_05 | PCR_TM_DIS | PCR_VSX_DIS,
 .pcr_level = PCR_COMPAT_2_05,
-.max_threads = 2,
+.max_vthreads = 2,
 },
 { /* POWER7, ISA2.06 */
 .name = "power7",
 .pvr = CPU_POWERPC_LOGICAL_2_06,
 .pcr = PCR_COMPAT_3_00 | PCR_COMPAT_2_07 | PCR_COMPAT_2_06 | 
PCR_TM_DIS,
 .pcr_level = PCR_COMPAT_2_06,
-.max_threads = 4,
+.max_vthreads = 4,
 },
 {
 .name = "power7+",
 .pvr = CPU_POWERPC_LOGICAL_2_06_PLUS,
 .pcr = PCR_COMPAT_3_00 | PCR_COMPAT_2_07 | PCR_COMPAT_2_06 | 
PCR_TM_DIS,
 .pcr_level = PCR_COMPAT_2_06,
-.max_threads = 4,
+.max_vthreads = 4,
 },
 { /* POWER8, ISA2.07 */
 .name = "power8",
 .pvr = CPU_POWERPC_LOGICAL_2_07,
 .pcr = PCR_COMPAT_3_00 | PCR_COMPAT_2_07,
 .pcr_level = PCR_COMPAT_2_07,
-.max_threads = 8,
+.max_vthreads = 8,
 },
 { /* POWER9, ISA3.00 */
 .name = "power9",
@@ -80,7 +89,7 @@ static const CompatInfo compat_table[] = {
  * confusing if half of the threads disappear from the guest
  * if it announces it's POWER9 aware at CAS time.
  */
-.max_threads = 8,
+.max_vthreads = 8,
 },
 };
 
@@ -192,14 +201,14 @@ void ppc_set_compat_all(uint32_t compat_pvr, Error **errp)
 }
 }
 
-int ppc_compat_max_threads(PowerPCCPU *cpu)
+int ppc_compat_max_vthreads(PowerPCCPU *cpu)
 {
 const CompatInfo *compat = compat_by_pvr(cpu->compat_pvr);
 int n_threads = CPU(cpu)->nr_threads;
 
 if (cpu->compat_pvr) {
 g_assert(compat);
-n_threads = MIN(n_threads, compat->max_threads);
+n_threads = MIN(n_threads, compat->max_vthreads);
 }
 
 return n_threads;
diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
index a5e49f23e9..dc6820c5eb 100644
--- a/target/ppc/cpu.h
+++ b/target/ppc/cpu.h
@@ -1395,7 +1395,7 @@ void ppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr, 
Error **errp);
 #if !defined(CONFIG_USER_ONLY)
 void ppc_set_compat_all(uint32_t compat_pvr, Error **errp);
 #endif
-int ppc_compat_max_threads(PowerPCCPU *cpu);
+int ppc_compat_max_vthreads(PowerPCCPU *cpu);
 void ppc_compat_add_property(Object *obj, const char *name,
  uint32_t *compat_pvr, const char *basedesc,
  

[Qemu-devel] [PULL 04/22] spapr: Validate capabilities on migration

[David Gibson]

Now that the "pseries" machine type implements optional capabilities (well,
one so far) there's the possibility of having different capabilities
available at either end of a migration.  Although arguably a user error,
it would be nice to catch this situation and fail as gracefully as we can.

This adds code to migrate the capabilities flags.  These aren't pulled
directly into the destination's configuration since what the user has
specified on the destination command line should take precedence.  However,
they are checked against the destination capabilities.

If the source was using a capability which is absent on the destination,
we fail the migration, since that could easily cause a guest crash or other
bad behaviour.  If the source lacked a capability which is present on the
destination we warn, but allow the migration to proceed.

Signed-off-by: David Gibson 
Reviewed-by: Greg Kurz 
---
 hw/ppc/spapr.c |  6 
 hw/ppc/spapr_caps.c| 96 --
 include/hw/ppc/spapr.h |  6 
 3 files changed, 105 insertions(+), 3 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 73310bd3ee..3451d0806d 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1589,6 +1589,11 @@ static int spapr_post_load(void *opaque, int version_id)
 sPAPRMachineState *spapr = (sPAPRMachineState *)opaque;
 int err = 0;
 
+err = spapr_caps_post_migration(spapr);
+if (err) {
+return err;
+}
+
 if (!object_dynamic_cast(OBJECT(spapr->ics), TYPE_ICS_KVM)) {
 CPUState *cs;
 CPU_FOREACH(cs) {
@@ -1755,6 +1760,7 @@ static const VMStateDescription vmstate_spapr = {
 _spapr_ov5_cas,
 _spapr_patb_entry,
 _spapr_pending_events,
+_spapr_caps,
 NULL
 }
 };
diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
index 3b35b91a5b..cad40fe49a 100644
--- a/hw/ppc/spapr_caps.c
+++ b/hw/ppc/spapr_caps.c
@@ -22,6 +22,7 @@
  * THE SOFTWARE.
  */
 #include "qemu/osdep.h"
+#include "qemu/error-report.h"
 #include "qapi/error.h"
 #include "qapi/visitor.h"
 #include "sysemu/hw_accel.h"
@@ -83,6 +84,93 @@ static sPAPRCapabilities 
default_caps_with_cpu(sPAPRMachineState *spapr,
 return caps;
 }
 
+static bool spapr_caps_needed(void *opaque)
+{
+sPAPRMachineState *spapr = opaque;
+
+return (spapr->forced_caps.mask != 0) || (spapr->forbidden_caps.mask != 0);
+}
+
+/* This has to be called from the top-level spapr post_load, not the
+ * caps specific one.  Otherwise it wouldn't be called when the source
+ * caps are all defaults, which could still conflict with overridden
+ * caps on the destination */
+int spapr_caps_post_migration(sPAPRMachineState *spapr)
+{
+uint64_t allcaps = 0;
+int i;
+bool ok = true;
+sPAPRCapabilities dstcaps = spapr->effective_caps;
+sPAPRCapabilities srccaps;
+
+srccaps = default_caps_with_cpu(spapr, first_cpu);
+srccaps.mask |= spapr->mig_forced_caps.mask;
+srccaps.mask &= ~spapr->mig_forbidden_caps.mask;
+
+for (i = 0; i < ARRAY_SIZE(capability_table); i++) {
+sPAPRCapabilityInfo *info = _table[i];
+
+allcaps |= info->flag;
+
+if ((srccaps.mask & info->flag) && !(dstcaps.mask & info->flag)) {
+error_report("cap-%s=on in incoming stream, but off in 
destination",
+ info->name);
+ok = false;
+}
+
+if (!(srccaps.mask & info->flag) && (dstcaps.mask & info->flag)) {
+warn_report("cap-%s=off in incoming stream, but on in destination",
+ info->name);
+}
+}
+
+if (spapr->mig_forced_caps.mask & ~allcaps) {
+error_report(
+"Unknown capabilities 0x%"PRIx64" enabled in incoming stream",
+spapr->mig_forced_caps.mask & ~allcaps);
+ok = false;
+}
+if (spapr->mig_forbidden_caps.mask & ~allcaps) {
+warn_report(
+"Unknown capabilities 0x%"PRIx64" disabled in incoming stream",
+spapr->mig_forbidden_caps.mask & ~allcaps);
+}
+
+return ok ? 0 : -EINVAL;
+}
+
+static int spapr_caps_pre_save(void *opaque)
+{
+sPAPRMachineState *spapr = opaque;
+
+spapr->mig_forced_caps = spapr->forced_caps;
+spapr->mig_forbidden_caps = spapr->forbidden_caps;
+return 0;
+}
+
+static int spapr_caps_pre_load(void *opaque)
+{
+sPAPRMachineState *spapr = opaque;
+
+spapr->mig_forced_caps = spapr_caps(0);
+spapr->mig_forbidden_caps = spapr_caps(0);
+return 0;
+}
+
+const VMStateDescription vmstate_spapr_caps = {
+.name = "spapr/caps",
+.version_id = 1,
+.minimum_version_id = 1,
+.needed = spapr_caps_needed,
+.pre_save = spapr_caps_pre_save,
+.pre_load = spapr_caps_pre_load,
+.fields = (VMStateField[]) {
+VMSTATE_UINT64(mig_forced_caps.mask, sPAPRMachineState),
+VMSTATE_UINT64(mig_forbidden_caps.mask, sPAPRMachineState),
+

[Qemu-devel] [PULL 02/22] spapr: Capabilities infrastructure

[David Gibson]

Because PAPR is a paravirtual environment access to certain CPU (or other)
facilities can be blocked by the hypervisor.  PAPR provides ways to
advertise in the device tree whether or not those features are available to
the guest.

In some places we automatically determine whether to make a feature
available based on whether our host can support it, in most cases this is
based on limitations in the available KVM implementation.

Although we correctly advertise this to the guest, it means that host
factors might make changes to the guest visible environment which is bad:
as well as generaly reducing reproducibility, it means that a migration
between different host environments can easily go bad.

We've mostly gotten away with it because the environments considered mature
enough to be well supported (basically, KVM on POWER8) have had consistent
feature availability.  But, it's still not right and some limitations on
POWER9 is going to make it more of an issue in future.

This introduces an infrastructure for defining "sPAPR capabilities".  These
are set by default based on the machine version, masked by the capabilities
of the chosen cpu, but can be overriden with machine properties.

The intention is at reset time we verify that the requested capabilities
can be supported on the host (considering TCG, KVM and/or host cpu
limitations).  If not we simply fail, rather than silently modifying the
advertised featureset to the guest.

This does mean that certain configurations that "worked" may now fail, but
such configurations were already more subtly broken.

Signed-off-by: David Gibson 
Reviewed-by: Greg Kurz 
---
 hw/ppc/Makefile.objs   |   2 +-
 hw/ppc/spapr.c |   7 ++
 hw/ppc/spapr_caps.c| 181 +
 include/hw/ppc/spapr.h |  31 +
 4 files changed, 220 insertions(+), 1 deletion(-)
 create mode 100644 hw/ppc/spapr_caps.c

diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
index 7efc686748..1faff853b7 100644
--- a/hw/ppc/Makefile.objs
+++ b/hw/ppc/Makefile.objs
@@ -1,7 +1,7 @@
 # shared objects
 obj-y += ppc.o ppc_booke.o fdt.o
 # IBM pSeries (sPAPR)
-obj-$(CONFIG_PSERIES) += spapr.o spapr_vio.o spapr_events.o
+obj-$(CONFIG_PSERIES) += spapr.o spapr_caps.o spapr_vio.o spapr_events.o
 obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o spapr_rtas.o
 obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o spapr_rng.o
 obj-$(CONFIG_PSERIES) += spapr_cpu_core.o spapr_ovec.o
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index dfd352c473..a6cf1234d8 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1466,6 +1466,8 @@ static void spapr_machine_reset(void)
 /* Check for unknown sysbus devices */
 foreach_dynamic_sysbus_device(find_unknown_sysbus_device, NULL);
 
+spapr_caps_reset(spapr);
+
 first_ppc_cpu = POWERPC_CPU(first_cpu);
 if (kvm_enabled() && kvmppc_has_cap_mmu_radix() &&
 ppc_check_compat(first_ppc_cpu, CPU_POWERPC_LOGICAL_3_00, 0,
@@ -2311,6 +2313,8 @@ static void spapr_machine_init(MachineState *machine)
 char *filename;
 Error *resize_hpt_err = NULL;
 
+spapr_caps_validate(spapr, _fatal);
+
 msi_nonbroken = true;
 
 QLIST_INIT(>phbs);
@@ -3819,6 +3823,9 @@ static void spapr_machine_class_init(ObjectClass *oc, 
void *data)
  * in which LMBs are represented and hot-added
  */
 mc->numa_mem_align_shift = 28;
+
+smc->default_caps = spapr_caps(0);
+spapr_caps_add_properties(smc, _abort);
 }
 
 static const TypeInfo spapr_machine_info = {
diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
new file mode 100644
index 00..968ba7b857
--- /dev/null
+++ b/hw/ppc/spapr_caps.c
@@ -0,0 +1,181 @@
+/*
+ * QEMU PowerPC pSeries Logical Partition capabilities handling
+ *
+ * Copyright (c) 2017 David Gibson, Red Hat Inc.
+ *
+ * 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"

[Qemu-devel] [PULL 10/22] ppc: Change Power9 compat table to support at most 8 threads/core

[David Gibson]

From: Jose Ricardo Ziviani 

Increases the max smt mode to 8 for Power9. That's because KVM supports
smt emulation in this platform so QEMU should allow users to use it as
well.

Today if we try to pass -smp ...,threads=8, QEMU will silently truncate
it to smt4 mode and may cause a crash if we try to perform a cpu
hotplug.

Signed-off-by: Jose Ricardo Ziviani 
[dwg: Added an explanatory comment]
Signed-off-by: David Gibson 
---
 target/ppc/compat.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/target/ppc/compat.c b/target/ppc/compat.c
index ad8f93c064..276b5b52c2 100644
--- a/target/ppc/compat.c
+++ b/target/ppc/compat.c
@@ -73,7 +73,14 @@ static const CompatInfo compat_table[] = {
 .pvr = CPU_POWERPC_LOGICAL_3_00,
 .pcr = PCR_COMPAT_3_00,
 .pcr_level = PCR_COMPAT_3_00,
-.max_threads = 4,
+/*
+ * POWER9 hardware only supports 4 threads / core, but this
+ * limit is for guests.  We need to support 8 vthreads/vcore
+ * on POWER9 for POWER8 compatibility guests, and it's very
+ * confusing if half of the threads disappear from the guest
+ * if it announces it's POWER9 aware at CAS time.
+ */
+.max_threads = 8,
 },
 };
 
-- 
2.14.3

[Qemu-devel] [PULL 15/22] tests/boot-serial-test: fix powernv support

[David Gibson]

From: Cédric Le Goater 

Recent commit introduced the firmware image skiboot 5.9 which
has a different first line ouput.

Signed-off-by: Cédric Le Goater 
Signed-off-by: David Gibson 
---
 tests/boot-serial-test.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/boot-serial-test.c b/tests/boot-serial-test.c
index 663b78b950..418c5b92dc 100644
--- a/tests/boot-serial-test.c
+++ b/tests/boot-serial-test.c
@@ -72,7 +72,7 @@ static testdef_t tests[] = {
 { "ppc64", "ppce500", "", "U-Boot" },
 { "ppc64", "prep", "", "Open Hack'Ware BIOS" },
 { "ppc64", "pseries", "", "Open Firmware" },
-{ "ppc64", "powernv", "-cpu POWER8", "SkiBoot" },
+{ "ppc64", "powernv", "-cpu POWER8", "OPAL" },
 { "i386", "isapc", "-cpu qemu32 -device sga", "SGABIOS" },
 { "i386", "pc", "-device sga", "SGABIOS" },
 { "i386", "q35", "-device sga", "SGABIOS" },
-- 
2.14.3

[Qemu-devel] [PULL 00/22] ppc-for-2.12 queue 20180117

[David Gibson]

The following changes since commit 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:

  Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' into 
staging (2018-01-16 17:36:39 +)

are available in the Git repository at:

  git://github.com/dgibson/qemu.git tags/ppc-for-2.12-20180117

for you to fetch changes up to 2e569845bd314fc1dde83d65dc9b87e71b4d29b4:

  target-ppc: Fix booke206 tlbwe TLB instruction (2018-01-17 09:35:24 +1100)

This pull request hasn't been through a Travis build, unfortunately,
since Travis seems to have a gigantic backlog today.  I've run all the
rest of my usual tests, and I did get a Travis build of this branch
before the latest minor rebase, so it's unlikely there's a problem
there.



ppc patch queue 2017-01-17

Another pull request for ppc related patches.  The most interesting
thing here is the new capabilities framework for the pseries machine
type.  This gives us better handling of several existing
incompatibilities between TCG, PR and HV KVM, as well as new ones that
arise with POWER9.  Further, it will allow reasonable handling of the
advertisement of features necessary to mitigate the recent CVEs
(Spectre and Meltdown).

In addition there's:
 * Improvide handling of different "vsmt" modes
 * Significant enhancements to the "pnv" machine type
 * Assorted other bugfixes


Alexey Kardashevskiy (1):
  target/ppc: Yet another fix for KVM-HV HPTE accessors

Cédric Le Goater (8):
  ppc/pnv: Update skiboot firmware image
  tests/boot-serial-test: fix powernv support
  ppc/pnv: use POWER9 DD2 processor
  ppc/pnv: change core mask for POWER9
  ppc/pnv: introduce pnv*_is_power9() helpers
  ppc/pnv: fix XSCOM core addressing on POWER9
  ppc/pnv: change initrd address
  target/ppc: add support for POWER9 HILE

David Gibson (10):
  spapr: Capabilities infrastructure
  spapr: Treat Hardware Transactional Memory (HTM) as an optional capability
  spapr: Validate capabilities on migration
  target/ppc: Clean up probing of VMX, VSX and DFP availability on KVM
  spapr: Handle VMX/VSX presence as an spapr capability flag
  spapr: Handle Decimal Floating Point (DFP) as an optional capability
  spapr: Remove unnecessary 'options' field from sPAPRCapabilityInfo
  target/ppc: Clarify compat mode max_threads value
  spapr: Allow some cases where we can't set VSMT mode in the kernel
  spapr: Adjust default VSMT value for better migration compatibility

Jose Ricardo Ziviani (1):
  ppc: Change Power9 compat table to support at most 8 threads/core

Luc MICHEL (1):
  target-ppc: Fix booke206 tlbwe TLB instruction

Suraj Jitindar Singh (1):
  hw/ppc/spapr_caps: Rework spapr_caps to use uint8 internal representation

 hw/ppc/Makefile.objs   |   2 +-
 hw/ppc/pnv.c   |  23 +--
 hw/ppc/pnv_core.c  |   2 +-
 hw/ppc/pnv_xscom.c |   8 +-
 hw/ppc/spapr.c | 115 +++
 hw/ppc/spapr_caps.c| 345 +
 include/hw/ppc/pnv.h   |  11 +-
 include/hw/ppc/pnv_xscom.h |  13 +-
 include/hw/ppc/spapr.h |  49 +++
 pc-bios/skiboot.lid| Bin 983893 -> 1302336 bytes
 roms/skiboot   |   2 +-
 target/ppc/compat.c|  32 +++--
 target/ppc/cpu.h   |   3 +-
 target/ppc/excp_helper.c   |   2 +-
 target/ppc/kvm.c   |  38 ++---
 target/ppc/kvm_ppc.h   |   2 -
 target/ppc/mmu_helper.c|  32 -
 tests/boot-serial-test.c   |   2 +-
 tests/pnv-xscom-test.c |  31 ++--
 19 files changed, 610 insertions(+), 102 deletions(-)
 create mode 100644 hw/ppc/spapr_caps.c

[Qemu-devel] [PULL 01/22] target/ppc: Yet another fix for KVM-HV HPTE accessors

[David Gibson]

From: Alexey Kardashevskiy 

As stated in the 1ad9f0a464fe commit log, the returned entries are not
a whole PTEG. It was not a problem before 1ad9f0a464fe as it would read
a single record assuming it contains a whole PTEG but now the code tries
reading the entire PTEG and "if ((n - i) < invalid)" produces negative
values which then are converted to size_t for memset() and that throws
seg fault.

This fixes the math.

While here, fix the last @i increment as well.

Fixes: 1ad9f0a464fe "target/ppc: Fix KVM-HV HPTE accessors"
Signed-off-by: Alexey Kardashevskiy 
Signed-off-by: David Gibson 
---
 target/ppc/kvm.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index 4664a3ce9d..09fcb082d2 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -2667,21 +2667,24 @@ void kvmppc_read_hptes(ppc_hash_pte64_t *hptes, hwaddr 
ptex, int n)
 
 hdr = (struct kvm_get_htab_header *)buf;
 while ((i < n) && ((char *)hdr < (buf + rc))) {
-int invalid = hdr->n_invalid;
+int invalid = hdr->n_invalid, valid = hdr->n_valid;
 
 if (hdr->index != (ptex + i)) {
 hw_error("kvmppc_read_hptes: Unexpected HPTE index %"PRIu32
  " != (%"HWADDR_PRIu" + %d", hdr->index, ptex, i);
 }
 
-memcpy(hptes + i, hdr + 1, HASH_PTE_SIZE_64 * hdr->n_valid);
-i += hdr->n_valid;
+if (n - i < valid) {
+valid = n - i;
+}
+memcpy(hptes + i, hdr + 1, HASH_PTE_SIZE_64 * valid);
+i += valid;
 
 if ((n - i) < invalid) {
 invalid = n - i;
 }
 memset(hptes + i, 0, invalid * HASH_PTE_SIZE_64);
-i += hdr->n_invalid;
+i += invalid;
 
 hdr = (struct kvm_get_htab_header *)
 ((char *)(hdr + 1) + HASH_PTE_SIZE_64 * hdr->n_valid);
-- 
2.14.3

[Qemu-devel] [PULL 07/22] spapr: Handle Decimal Floating Point (DFP) as an optional capability

[David Gibson]

Decimal Floating Point has been available on POWER7 and later (server)
cpus.  However, it can be disabled on the hypervisor, meaning that it's
not available to guests.

We currently handle this by conditionally advertising DFP support in the
device tree depending on whether the guest CPU model supports it - which
can also depend on what's allowed in the host for -cpu host.  That can lead
to confusion on migration, since host properties are silently affecting
guest visible properties.

This patch handles it by treating it as an optional capability for the
pseries machine type.

Signed-off-by: David Gibson 
Reviewed-by: Greg Kurz 
---
 hw/ppc/spapr.c |  7 ---
 hw/ppc/spapr_caps.c| 18 ++
 include/hw/ppc/spapr.h |  3 +++
 3 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index eca9f11c91..d1acfe8858 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -572,7 +572,7 @@ static void spapr_populate_cpu_dt(CPUState *cs, void *fdt, 
int offset,
 /* Advertise DFP (Decimal Floating Point) if available
  *   0 / no property == no DFP
  *   1   == DFP available */
-if (env->insns_flags2 & PPC2_DFP) {
+if (spapr_has_cap(spapr, SPAPR_CAP_DFP)) {
 _FDT((fdt_setprop_cell(fdt, offset, "ibm,dfp", 1)));
 }
 
@@ -3834,7 +3834,7 @@ static void spapr_machine_class_init(ObjectClass *oc, 
void *data)
  */
 mc->numa_mem_align_shift = 28;
 
-smc->default_caps = spapr_caps(SPAPR_CAP_VSX);
+smc->default_caps = spapr_caps(SPAPR_CAP_VSX | SPAPR_CAP_DFP);
 spapr_caps_add_properties(smc, _abort);
 }
 
@@ -3916,7 +3916,8 @@ static void spapr_machine_2_11_class_options(MachineClass 
*mc)
 sPAPRMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
 
 spapr_machine_2_12_class_options(mc);
-smc->default_caps = spapr_caps(SPAPR_CAP_HTM | SPAPR_CAP_VSX);
+smc->default_caps = spapr_caps(SPAPR_CAP_HTM | SPAPR_CAP_VSX
+   | SPAPR_CAP_DFP);
 SET_MACHINE_COMPAT(mc, SPAPR_COMPAT_2_11);
 }
 
diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
index 7c855c67ad..9d070a306c 100644
--- a/hw/ppc/spapr_caps.c
+++ b/hw/ppc/spapr_caps.c
@@ -70,6 +70,16 @@ static void cap_vsx_allow(sPAPRMachineState *spapr, Error 
**errp)
 }
 }
 
+static void cap_dfp_allow(sPAPRMachineState *spapr, Error **errp)
+{
+PowerPCCPU *cpu = POWERPC_CPU(first_cpu);
+CPUPPCState *env = >env;
+
+if (!(env->insns_flags2 & PPC2_DFP)) {
+error_setg(errp, "DFP support not available, try cap-dfp=off");
+}
+}
+
 static sPAPRCapabilityInfo capability_table[] = {
 {
 .name = "htm",
@@ -85,6 +95,13 @@ static sPAPRCapabilityInfo capability_table[] = {
 .allow = cap_vsx_allow,
 /* TODO: add cap_vsx_disallow */
 },
+{
+.name = "dfp",
+.description = "Allow Decimal Floating Point (DFP)",
+.flag = SPAPR_CAP_DFP,
+.allow = cap_dfp_allow,
+/* TODO: add cap_dfp_disallow */
+},
 };
 
 static sPAPRCapabilities default_caps_with_cpu(sPAPRMachineState *spapr,
@@ -104,6 +121,7 @@ static sPAPRCapabilities 
default_caps_with_cpu(sPAPRMachineState *spapr,
 if (!ppc_check_compat(cpu, CPU_POWERPC_LOGICAL_2_06,
   0, spapr->max_compat_pvr)) {
 caps.mask &= ~SPAPR_CAP_VSX;
+caps.mask &= ~SPAPR_CAP_DFP;
 }
 
 return caps;
diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index 148a03d189..26ac17e641 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -62,6 +62,9 @@ typedef enum {
 /* Vector Scalar Extensions */
 #define SPAPR_CAP_VSX   0x0002ULL
 
+/* Decimal Floating Point */
+#define SPAPR_CAP_DFP   0x0004ULL
+
 typedef struct sPAPRCapabilities sPAPRCapabilities;
 struct sPAPRCapabilities {
 uint64_t mask;
-- 
2.14.3

[Qemu-devel] [PULL 09/22] spapr: Remove unnecessary 'options' field from sPAPRCapabilityInfo

[David Gibson]

The options field here is intended to list the available values for the
capability.  It's not used yet, because the existing capabilities are
boolean.

We're going to add capabilities that aren't, but in that case the info on
the possible values can be folded into the .description field.

Signed-off-by: David Gibson 
---
 hw/ppc/spapr_caps.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
index f95a78547d..d5c9ce774a 100644
--- a/hw/ppc/spapr_caps.c
+++ b/hw/ppc/spapr_caps.c
@@ -35,7 +35,6 @@
 typedef struct sPAPRCapabilityInfo {
 const char *name;
 const char *description;
-const char *options;/* valid capability values */
 int index;
 
 /* Getter and Setter Function Pointers */
@@ -126,7 +125,6 @@ sPAPRCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
 [SPAPR_CAP_HTM] = {
 .name = "htm",
 .description = "Allow Hardware Transactional Memory (HTM)",
-.options = "",
 .index = SPAPR_CAP_HTM,
 .get = spapr_cap_get_bool,
 .set = spapr_cap_set_bool,
@@ -136,7 +134,6 @@ sPAPRCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
 [SPAPR_CAP_VSX] = {
 .name = "vsx",
 .description = "Allow Vector Scalar Extensions (VSX)",
-.options = "",
 .index = SPAPR_CAP_VSX,
 .get = spapr_cap_get_bool,
 .set = spapr_cap_set_bool,
@@ -146,7 +143,6 @@ sPAPRCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
 [SPAPR_CAP_DFP] = {
 .name = "dfp",
 .description = "Allow Decimal Floating Point (DFP)",
-.options = "",
 .index = SPAPR_CAP_DFP,
 .get = spapr_cap_get_bool,
 .set = spapr_cap_set_bool,
@@ -338,7 +334,7 @@ void spapr_caps_add_properties(sPAPRMachineClass *smc, 
Error **errp)
 return;
 }
 
-desc = g_strdup_printf("%s%s", cap->description, cap->options);
+desc = g_strdup_printf("%s", cap->description);
 object_class_property_set_description(klass, name, desc, _err);
 g_free(desc);
 if (local_err) {
-- 
2.14.3

[Qemu-devel] [PULL 06/22] spapr: Handle VMX/VSX presence as an spapr capability flag

[David Gibson]

We currently have some conditionals in the spapr device tree code to decide
whether or not to advertise the availability of the VMX (aka Altivec) and
VSX vector extensions to the guest, based on whether the guest cpu has
those features.

This can lead to confusion and subtle failures on migration, since it makes
a guest visible change based only on host capabilities.  We now have a
better mechanism for this, in spapr capabilities flags, which explicitly
depend on user options rather than host capabilities.

Rework the advertisement of VSX and VMX based on a new VSX capability.  We
no longer bother with a conditional for VMX support, because every CPU
that's ever been supported by the pseries machine type supports VMX.

NOTE: Some userspace distributions (e.g. RHEL7.4) already rely on
availability of VSX in libc, so using cap-vsx=off may lead to a fatal
SIGILL in init.

Signed-off-by: David Gibson 
Reviewed-by: Greg Kurz 
---
 hw/ppc/spapr.c | 20 +++-
 hw/ppc/spapr_caps.c| 25 +
 include/hw/ppc/spapr.h |  3 +++
 3 files changed, 39 insertions(+), 9 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 3451d0806d..eca9f11c91 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -557,14 +557,16 @@ static void spapr_populate_cpu_dt(CPUState *cs, void 
*fdt, int offset,
   segs, sizeof(segs;
 }
 
-/* Advertise VMX/VSX (vector extensions) if available
- *   0 / no property == no vector extensions
+/* Advertise VSX (vector extensions) if available
  *   1   == VMX / Altivec available
- *   2   == VSX available */
-if (env->insns_flags & PPC_ALTIVEC) {
-uint32_t vmx = (env->insns_flags2 & PPC2_VSX) ? 2 : 1;
-
-_FDT((fdt_setprop_cell(fdt, offset, "ibm,vmx", vmx)));
+ *   2   == VSX available
+ *
+ * Only CPUs for which we create core types in spapr_cpu_core.c
+ * are possible, and all of those have VMX */
+if (spapr_has_cap(spapr, SPAPR_CAP_VSX)) {
+_FDT((fdt_setprop_cell(fdt, offset, "ibm,vmx", 2)));
+} else {
+_FDT((fdt_setprop_cell(fdt, offset, "ibm,vmx", 1)));
 }
 
 /* Advertise DFP (Decimal Floating Point) if available
@@ -3832,7 +3834,7 @@ static void spapr_machine_class_init(ObjectClass *oc, 
void *data)
  */
 mc->numa_mem_align_shift = 28;
 
-smc->default_caps = spapr_caps(0);
+smc->default_caps = spapr_caps(SPAPR_CAP_VSX);
 spapr_caps_add_properties(smc, _abort);
 }
 
@@ -3914,7 +3916,7 @@ static void spapr_machine_2_11_class_options(MachineClass 
*mc)
 sPAPRMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
 
 spapr_machine_2_12_class_options(mc);
-smc->default_caps = spapr_caps(SPAPR_CAP_HTM);
+smc->default_caps = spapr_caps(SPAPR_CAP_HTM | SPAPR_CAP_VSX);
 SET_MACHINE_COMPAT(mc, SPAPR_COMPAT_2_11);
 }
 
diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
index cad40fe49a..7c855c67ad 100644
--- a/hw/ppc/spapr_caps.c
+++ b/hw/ppc/spapr_caps.c
@@ -57,6 +57,19 @@ static void cap_htm_allow(sPAPRMachineState *spapr, Error 
**errp)
 }
 }
 
+static void cap_vsx_allow(sPAPRMachineState *spapr, Error **errp)
+{
+PowerPCCPU *cpu = POWERPC_CPU(first_cpu);
+CPUPPCState *env = >env;
+
+/* Allowable CPUs in spapr_cpu_core.c should already have gotten
+ * rid of anything that doesn't do VMX */
+g_assert(env->insns_flags & PPC_ALTIVEC);
+if (!(env->insns_flags2 & PPC2_VSX)) {
+error_setg(errp, "VSX support not available, try cap-vsx=off");
+}
+}
+
 static sPAPRCapabilityInfo capability_table[] = {
 {
 .name = "htm",
@@ -65,6 +78,13 @@ static sPAPRCapabilityInfo capability_table[] = {
 .allow = cap_htm_allow,
 /* TODO: add cap_htm_disallow */
 },
+{
+.name = "vsx",
+.description = "Allow Vector Scalar Extensions (VSX)",
+.flag = SPAPR_CAP_VSX,
+.allow = cap_vsx_allow,
+/* TODO: add cap_vsx_disallow */
+},
 };
 
 static sPAPRCapabilities default_caps_with_cpu(sPAPRMachineState *spapr,
@@ -81,6 +101,11 @@ static sPAPRCapabilities 
default_caps_with_cpu(sPAPRMachineState *spapr,
 caps.mask &= ~SPAPR_CAP_HTM;
 }
 
+if (!ppc_check_compat(cpu, CPU_POWERPC_LOGICAL_2_06,
+  0, spapr->max_compat_pvr)) {
+caps.mask &= ~SPAPR_CAP_VSX;
+}
+
 return caps;
 }
 
diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index 5c85f39c3b..148a03d189 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -59,6 +59,9 @@ typedef enum {
 /* Hardware Transactional Memory */
 #define SPAPR_CAP_HTM   0x0001ULL
 
+/* Vector Scalar Extensions */
+#define SPAPR_CAP_VSX   0x0002ULL
+
 typedef struct sPAPRCapabilities sPAPRCapabilities;
 struct sPAPRCapabilities {
 uint64_t mask;
-- 
2.14.3

Re: [Qemu-devel] [PATCH 4/7] docker: do not use Trusty APT source in Xenial

[Fam Zheng]

On 01/12/2018 08:49 PM, Philippe Mathieu-Daudé wrote:

probably missed in 7fc581c29518

Signed-off-by: Philippe Mathieu-Daudé 
---
  tests/docker/dockerfiles/ubuntu.docker | 2 --
  1 file changed, 2 deletions(-)

diff --git a/tests/docker/dockerfiles/ubuntu.docker 
b/tests/docker/dockerfiles/ubuntu.docker
index dabbf2a8a4..686d90ae8c 100644
--- a/tests/docker/dockerfiles/ubuntu.docker
+++ b/tests/docker/dockerfiles/ubuntu.docker
@@ -1,6 +1,4 @@
  FROM ubuntu:16.04
-RUN echo "deb http://archive.ubuntu.com/ubuntu/ trusty universe multiverse" >> 
\
-/etc/apt/sources.list
  RUN apt-get update
  ENV PACKAGES flex bison \
  libusb-1.0-0-dev libiscsi-dev librados-dev libncurses5-dev 
libncursesw5-dev \


Reviewed-by: Fam Zheng 

Re: [Qemu-devel] [PATCH 3/7] docker: add the Ubuntu Trusty base image

[Fam Zheng]

On 01/12/2018 08:49 PM, Philippe Mathieu-Daudé wrote:

based on QEMU v2.10 ubuntu.docker (ca853f0c76e3 and 2346b12fc52d)

Signed-off-by: Philippe Mathieu-Daudé 
---
  tests/docker/dockerfiles/ubuntu14.04.docker | 17 +
  1 file changed, 17 insertions(+)
  create mode 100644 tests/docker/dockerfiles/ubuntu14.04.docker

diff --git a/tests/docker/dockerfiles/ubuntu14.04.docker 
b/tests/docker/dockerfiles/ubuntu14.04.docker
new file mode 100644
index 00..cd24e759a7
--- /dev/null
+++ b/tests/docker/dockerfiles/ubuntu14.04.docker
@@ -0,0 +1,17 @@
+FROM ubuntu:14.04
+RUN apt-get update
+ENV PACKAGES flex bison \
+libusb-1.0-0-dev libiscsi-dev librados-dev libncurses5-dev 
libncursesw5-dev \
+libseccomp-dev libgnutls-dev libssh2-1-dev  libspice-server-dev \
+libspice-protocol-dev libnss3-dev libfdt-dev \
+libgtk-3-dev libvte-2.90-dev libsdl1.2-dev libpng12-dev libpixman-1-dev \
+libvdeplug-dev liblzo2-dev libsnappy-dev libbz2-dev libxen-dev 
librdmacm-dev libibverbs-dev \
+libsasl2-dev libjpeg-turbo8-dev xfslibs-dev libcap-ng-dev libbrlapi-dev 
libcurl4-gnutls-dev \
+libbluetooth-dev librbd-dev libaio-dev glusterfs-common libnuma-dev 
libepoxy-dev libdrm-dev libgbm-dev \
+libjemalloc-dev libusbredirhost-dev libnfs-dev libcap-dev libattr1-dev \
+texinfo dpkg-dev \
+gettext git make ccache python-yaml gcc clang sparse
+RUN DEBIAN_FRONTEND=noninteractive apt-get -y --no-install-recommends install 
$PACKAGES
+RUN dpkg -l $PACKAGES | sort > /packages.txt
+ENV FEATURES clang pyyaml
+ENV QEMU_CONFIGURE_OPTS --disable-opengl


Why is this option needed?

Re: [Qemu-devel] [PATCH 2/7] docker: do not display deprecated images in 'make docker' help

[Fam Zheng]

On 01/12/2018 08:49 PM, Philippe Mathieu-Daudé wrote:

the 'debian' base image is deprecated since 3e11974988d8

Signed-off-by: Philippe Mathieu-Daudé 
---
  tests/docker/Makefile.include | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index ef95703cef..f0cd26c2b6 100644
--- a/tests/docker/Makefile.include
+++ b/tests/docker/Makefile.include
@@ -4,7 +4,8 @@
  
  DOCKER_SUFFIX := .docker

  DOCKER_FILES_DIR := $(SRC_PATH)/tests/docker/dockerfiles
-DOCKER_IMAGES := $(sort $(notdir $(basename $(wildcard 
$(DOCKER_FILES_DIR)/*.docker
+DOCKER_DEPRECATED_IMAGES := debian
+DOCKER_IMAGES := $(filter-out $(DOCKER_DEPRECATED_IMAGES),$(sort $(notdir 
$(basename $(wildcard $(DOCKER_FILES_DIR)/*.docker)
  DOCKER_TARGETS := $(patsubst %,docker-image-%,$(DOCKER_IMAGES))
  # Use a global constant ccache directory to speed up repetitive builds
  DOCKER_CCACHE_DIR := $$HOME/.cache/qemu-docker-ccache


While we are at it, could you please just spell out this list 
explicitly, consistent to how we build obj-y variables?

Re: [Qemu-devel] Qemu c++ build question

[Ancuta, Cristian]

Hi and thanks for the answer,

Yes, not quite what I expected but your suggestion might indeed be the solution 
I need.

Even if the problem that I'm encountering doesn't seeem to be related to the 
one you had, I'd will just export a C interface from the C++ code and keep the 
two isolated, rather than mess around with the build system since that looks 
like it's going nowhere.

Regards,
Cristi

-Original Message-
From: Liviu Ionescu [mailto:i...@livius.net] 
Sent: Wednesday, January 17, 2018 3:37 AM
To: Ancuta, Cristian 
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Qemu c++ build question



> On 17 Jan 2018, at 03:14, Ancuta, Cristian  wrote:
> 
> I'm currently working on implementing an emulation target in QEMU and the 
> implementation is in C++.

it might not be the answer you expect, but last time I tried to do a similar 
thing I encountered a problem that prevented the direct C++ integration into 
QEMU.

I don't know if it is still the case, but a field in one of the main headers 
defining objects was called `class`, a reserved name in C++.

so be sure you isolate the C++ code outside QEMU and access it only via a C 
interface; also be sure you do not include the QEMU headers in C++ files.


regards,

Liviu

Re: [Qemu-devel] Qemu c++ build question

[Liviu Ionescu]

> On 17 Jan 2018, at 03:14, Ancuta, Cristian  wrote:
> 
> I'm currently working on implementing an emulation target in QEMU and the 
> implementation is in C++.

it might not be the answer you expect, but last time I tried to do a similar 
thing I encountered a problem that prevented the direct C++ integration into 
QEMU.

I don't know if it is still the case, but a field in one of the main headers 
defining objects was called `class`, a reserved name in C++.

so be sure you isolate the C++ code outside QEMU and access it only via a C 
interface; also be sure you do not include the QEMU headers in C++ files.


regards,

Liviu

Re: [Qemu-devel] [PATCH] memory: update comments and fix some typos

[Zhoujian (jay)]

> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Tuesday, January 16, 2018 10:44 PM
> To: Zhoujian (jay) ; qemu-devel@nongnu.org
> Cc: Huangweidong (C) ; wangxin (U)
> 
> Subject: Re: [PATCH] memory: update comments and fix some typos
> 
> On 16/01/2018 09:32, Zhoujian (jay) wrote:
> > Hi Paolo,
> > Maybe it is a little boring to review updated comments, but I think it
> > is the right thing to do, so could you have a look when you're free?
> 
> On the contrary, it's useful!  I just missed it among the email after new
> year's break.
> 
> I queued it now.

Thanks,

Jay

> 
> Paolo
> 
> > Regards,
> > Jay
> >
> >> -Original Message-
> >> From: Zhoujian (jay)
> >> Sent: Thursday, January 04, 2018 1:30 PM
> >> To: qemu-devel@nongnu.org
> >> Cc: pbonz...@redhat.com; Huangweidong (C) ;
> >> wangxin
> >> (U) ; Zhoujian (jay)
> >> 
> >> Subject: [PATCH] memory: update comments and fix some typos
> >>
> >> Signed-off-by: Jay Zhou 
> >> ---
> >>  include/exec/memory.h | 27 +++
> >>  1 file changed, 15 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/include/exec/memory.h b/include/exec/memory.h index
> >> a4cabdf..6e5684d 100644
> >> --- a/include/exec/memory.h
> >> +++ b/include/exec/memory.h
> >> @@ -324,7 +324,7 @@ FlatView *address_space_to_flatview(AddressSpace *as);
> >>   * MemoryRegionSection: describes a fragment of a #MemoryRegion
> >>   *
> >>   * @mr: the region, or %NULL if empty
> >> - * @address_space: the address space the region is mapped in
> >> + * @fv: the flat view of the address space the region is mapped in
> >>   * @offset_within_region: the beginning of the section, relative to
> >> @mr's start
> >>   * @size: the size of the section; will not exceed @mr's boundaries
> >>   * @offset_within_address_space: the address of the first byte of
> >> the section @@ -607,6 +607,7 @@ void
> >> memory_region_init_rom_nomigrate(MemoryRegion *mr,
> >>   * @mr: the #MemoryRegion to be initialized.
> >>   * @owner: the object that tracks the region's reference count
> >>   * @ops: callbacks for write access handling (must not be NULL).
> >> + * @opaque: passed to the read and write callbacks of the @ops structure.
> >>   * @name: Region name, becomes part of RAMBlock name used in
> >> migration stream
> >>   *must be unique within any device
> >>   * @size: size of the region.
> >> @@ -650,11 +651,10 @@ static inline void
> >> memory_region_init_reservation(MemoryRegion *mr,
> >>   * An IOMMU region translates addresses and forwards accesses to a target
> >>   * memory region.
> >>   *
> >> - * @typename: QOM class name
> >>   * @_iommu_mr: the #IOMMUMemoryRegion to be initialized
> >>   * @instance_size: the IOMMUMemoryRegion subclass instance size
> >> + * @mrtypename: the type name of the #IOMMUMemoryRegion
> >>   * @owner: the object that tracks the region's reference count
> >> - * @ops: a function that translates addresses into the @target region
> >>   * @name: used for debugging; not visible to the user or ABI
> >>   * @size: size of the region.
> >>   */
> >> @@ -824,8 +824,8 @@ static inline IOMMUMemoryRegion
> >> *memory_region_get_iommu(MemoryRegion *mr)
> >>   * memory_region_get_iommu_class_nocheck: returns iommu memory region
> class
> >>   *   if an iommu or NULL if not
> >>   *
> >> - * Returns pointer to IOMMUMemoryRegioniClass if a memory region is
> >> an iommu,
> >> - * otherwise NULL. This is fast path avoinding QOM checking, use
> >> with caution.
> >> + * Returns pointer to IOMMUMemoryRegionClass if a memory region is
> >> + an iommu,
> >> + * otherwise NULL. This is fast path avoiding QOM checking, use with
> caution.
> >>   *
> >>   * @mr: the memory region being queried
> >>   */
> >> @@ -990,7 +990,8 @@ int memory_region_get_fd(MemoryRegion *mr);
> >>   * protecting the pointer, such as a reference to the region that
> includes
> >>   * the incoming ram_addr_t.
> >>   *
> >> - * @mr: the memory region being queried.
> >> + * @ptr: the host pointer to be converted
> >> + * @offset: the offset within memory region
> >>   */
> >>  MemoryRegion *memory_region_from_host(void *ptr, ram_addr_t
> >> *offset);
> >>
> >> @@ -1267,7 +1268,7 @@ void
> >> memory_region_clear_global_locking(MemoryRegion
> >> *mr);
> >>   * @size: the size of the access to trigger the eventfd
> >>   * @match_data: whether to match against @data, instead of just @addr
> >>   * @data: the data to match against the guest write
> >> - * @fd: the eventfd to be triggered when @addr, @size, and @data all
> match.
> >> + * @e: event notifier to be triggered when @addr, @size, and @data all
> match.
> >>   **/
> >>  void memory_region_add_eventfd(MemoryRegion *mr,
> >> hwaddr addr, @@ -1287,7 +1288,7 @@
> >> void 

Re: [Qemu-devel] [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps

[David Gibson]

On Wed, Jan 17, 2018 at 10:46:45AM +1100, Alexey Kardashevskiy wrote:
> On 17/01/18 10:30, David Gibson wrote:
> > On Wed, Jan 17, 2018 at 10:26:28AM +1100, Alexey Kardashevskiy wrote:
> >> On 17/01/18 09:34, David Gibson wrote:
> >>> On Tue, Jan 16, 2018 at 03:46:20PM +0100, Andrea Bolognani wrote:
>  On Wed, 2018-01-17 at 00:54 +1100, David Gibson wrote:
> >> Correct me if I'm wrong, but it seems to me like there's no way
> >> to figure out through QMP whether these new machine options can be
> >> used for a given QEMU binary.
> >
> > Uh, I don't think so.  These are machine options like any other (just
> > constructed a bit differently).  So they'll appear in qemu -machine
> > pseries,? and I believe that info can also be retrieved with QMP.
> 
>  Yes, they will indeed show up in the output of -machine pseries,?
>  but there's AFAICT no way to retrieve them via QMP.
> >>>
> >>> Really!?  I thought introspecting object properties was QMP's bread
> >>> and butter.
> >>
> >>
> >> On a guest started with '-S':
> >> {"execute": "qom-list", "arguments": {"path": "/machine"}}
> >>
> >> returns:
> >> {   'return': [   {'name': 'graphics', 'type': 'bool'},
> >>   {'name': 'phandle-start', 'type': 'int'},
> >>   {'name': 'dump-guest-core', 'type': 'bool'},
> >>   {'name': 'kernel-irqchip', 'type': 'OnOffSplit'},
> >>   {'name': 'accel', 'type': 'string'},
> >>   {'name': 'append', 'type': 'string'},
> >>   {'name': 'dumpdtb', 'type': 'string'},
> >>   {'name': 'igd-passthru', 'type': 'bool'},
> >>   {'name': 'dt-compatible', 'type': 'string'},
> >>   {'name': 'kernel', 'type': 'string'},
> >>   {'name': 'usb', 'type': 'bool'},
> >>   {'name': 'suppress-vmdesc', 'type': 'bool'},
> >>   {'name': 'dtb', 'type': 'string'},
> >>   {'name': 'firmware', 'type': 'string'},
> >>   {'name': 'mem-merge', 'type': 'bool'},
> >>   {'name': 'initrd', 'type': 'string'},
> >>   {'name': 'enforce-config-section', 'type': 'bool'},
> >>   {'name': 'kvm-shadow-mem', 'type': 'int'},
> >>   {'name': 'cap-dfp', 'type': 'bool'},
> >>   {'name': 'cap-htm', 'type': 'bool'},
> >>   {'name': 'cap-vsx', 'type': 'bool'},
> >   ^^^
> > Here are the cap properties.  Is it just Suraj's new tristate ones
> > that aren't showing up?  If so that's weird...  are you sure you built
> > with those patches included?
> 
> I am sure I do not have them, my point was that QMP has it all if they are
> present in qemu :)

Oh sorry, I wasn't paying attention.  I thought that mail was from
Andrea, not you.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

[Qemu-devel] Qemu c++ build question

[Ancuta, Cristian]

I'm not sure this is the right way to ask this question - and I appollogize if 
it isn't - but here goes:

I'm currently working on implementing an emulation target in QEMU and the 
implementation is in C++.

I have the file qemu/target/mytarget/translate.cpp from which I #include 
 and osdep.h includes  "config-host.h".
When I run make it complains that config-host.h cannot be found.
This doesn't happen if I change the translate file from .cpp to .c

I only have a vague feeling that it has something to do with the C++ compiler 
and I've added the path where the header is located to the -extra-cxxflags when 
running the ./configure script, but it doesn't seem to pick it up.

Any help would be appreciated.

Thanks.

Re: [Qemu-devel] [PATCH v1] migration: use s->threshold_size inside migration_update_counters

[Wei Wang]

On 01/16/2018 08:19 PM, Peter Xu wrote:

On Tue, Jan 16, 2018 at 06:51:32PM +0800, Wei Wang wrote:

The threshold size is changed to be recorded in s->threshold_size by
commit b15df1ae5063c7c181f8f068f9eba7661b3b5e1.

Signed-off-by: Wei Wang 

Could you help confirm the commit ID?  Since what I see is
b15df1ae50.  Otherwise:

Reviewed-by: Peter Xu 

And I'd prefer add:

Fixes: b15df1ae50 ("migration: cleanup stats update into function")

Thanks for the patch!



Sure. b15df1ae50 is shortcut and works too. Agree with your change.

Best,
Wei

Re: [Qemu-devel] [RFC v1] block/NVMe: introduce a new vhost NVMe host device to QEMU

[Liu, Changpeng]

> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Wednesday, January 17, 2018 1:07 AM
> To: Liu, Changpeng ; qemu-devel@nongnu.org
> Cc: Harris, James R ; Busch, Keith
> ; f...@redhat.com; stefa...@gmail.com;
> m...@redhat.com
> Subject: Re: [RFC v1] block/NVMe: introduce a new vhost NVMe host device to
> QEMU
> 
> On 15/01/2018 09:01, Changpeng Liu wrote:
> > NVMe 1.3 specification introduces a new NVMe ADMIN command:
> > doorbell buffer config, which can write shadow doorbell buffer
> > instead of MMIO registers, so it can improve the Guest performance
> > a lot for emulated NVMe devices inside VM.
> >
> > Similar with existing vhost-user-scsi solution, this commit builds a
> > new vhost_user_nvme host device to VM and the I/O is processed at
> > the slave I/O target, so users can implement a user space NVMe driver
> > in the slave I/O target.
> >
> > Users can start QEMU with: -chardev socket,id=char0,path=/path/vhost.0 \
> > -device vhost-user-nvme,chardev=char0,num_io_queues=2.
> 
> Hi Changpeng,
> 
> I have two comments on this series.
> 
> First, the new command in NVMe 1.3 is great.  However, please first add
> support for the doorbell buffer config in hw/block/nvme.c.  There is no
> need to tie support for the new command to a completely new external
> server architecture.  Emulated NVMe can be enhanced to use iothreads and
> (when the doorbell buffer is configured) ioeventfd, and that should come
> before enhancements for external vhost-like servers.
Yes, adding doorbell buffer config support at hw/block/nvme.c is great to 
improve
the efficiency, this vhost-like idea is another solution which can provide 
end-to-end
userspace software stack.
> 
> Second, virtio-based vhost-user remains QEMU's preferred method for
> high-performance I/O in guests.  Discard support is missing and that is
> important for SSDs; that should be fixed in the virtio spec.  Are there
Previously I have a patch adding DISCARD support to virtio-blk, but I didn't 
find
the way using svn to update the spec patch, any git repository I can use
to update the virtio-blk spec ? I think I can pick up the feature again.
> any other features where virtio-blk is lagging behind NVMe?
From the efficiency consideration, I compared the solution with vhost-user-blk,
Indeed, the two solution are almost at the same level, IOPS/CPU utilization 
inside Guest/KVM events(VM_EXIT,
KVM_FAST_MMIO,KVM_MSI_SET_IRQ,KVM_MSR) are almost same.
> 
> Thanks,
> 
> Paolo

[Qemu-devel] [PATCH v2] usb-storage: Fix share-rw option parsing

[Fam Zheng]

Because usb-storage creates an internal scsi device, we should propagate
options. We already do so for bootindex etc, but failed to take care of
share-rw. Fix it in an apparent way: add a new parameter to
scsi_bus_legacy_add_drive and pass in s->conf.share_rw.

Cc: qemu-sta...@nongnu.org
Signed-off-by: Fam Zheng 

---

v2: Rebase to master.
---
 hw/scsi/scsi-bus.c | 9 -
 hw/usb/dev-storage.c   | 3 ++-
 include/hw/scsi/scsi.h | 1 +
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/hw/scsi/scsi-bus.c b/hw/scsi/scsi-bus.c
index 965becf31f..05e501efd3 100644
--- a/hw/scsi/scsi-bus.c
+++ b/hw/scsi/scsi-bus.c
@@ -224,6 +224,7 @@ static void scsi_qdev_unrealize(DeviceState *qdev, Error 
**errp)
 /* handle legacy '-drive if=scsi,...' cmd line args */
 SCSIDevice *scsi_bus_legacy_add_drive(SCSIBus *bus, BlockBackend *blk,
   int unit, bool removable, int bootindex,
+  bool share_rw,
   const char *serial, Error **errp)
 {
 const char *driver;
@@ -254,6 +255,12 @@ SCSIDevice *scsi_bus_legacy_add_drive(SCSIBus *bus, 
BlockBackend *blk,
 object_unparent(OBJECT(dev));
 return NULL;
 }
+object_property_set_bool(OBJECT(dev), share_rw, "share-rw", );
+if (err != NULL) {
+error_propagate(errp, err);
+object_unparent(OBJECT(dev));
+return NULL;
+}
 object_property_set_bool(OBJECT(dev), true, "realized", );
 if (err != NULL) {
 error_propagate(errp, err);
@@ -288,7 +295,7 @@ void scsi_bus_legacy_handle_cmdline(SCSIBus *bus, bool 
deprecated)
 }
 }
 scsi_bus_legacy_add_drive(bus, blk_by_legacy_dinfo(dinfo),
-  unit, false, -1, NULL, _fatal);
+  unit, false, -1, false, NULL, _fatal);
 }
 loc_pop();
 }
diff --git a/hw/usb/dev-storage.c b/hw/usb/dev-storage.c
index 9722ac854c..80c03eff35 100644
--- a/hw/usb/dev-storage.c
+++ b/hw/usb/dev-storage.c
@@ -633,7 +633,8 @@ static void usb_msd_storage_realize(USBDevice *dev, Error 
**errp)
 scsi_bus_new(>bus, sizeof(s->bus), DEVICE(dev),
  _msd_scsi_info_storage, NULL);
 scsi_dev = scsi_bus_legacy_add_drive(>bus, blk, 0, !!s->removable,
- s->conf.bootindex, dev->serial,
+ s->conf.bootindex, s->conf.share_rw,
+ dev->serial,
  errp);
 blk_unref(blk);
 if (!scsi_dev) {
diff --git a/include/hw/scsi/scsi.h b/include/hw/scsi/scsi.h
index 23a8ee6a7d..802a647cdc 100644
--- a/include/hw/scsi/scsi.h
+++ b/include/hw/scsi/scsi.h
@@ -151,6 +151,7 @@ static inline SCSIBus *scsi_bus_from_device(SCSIDevice *d)
 
 SCSIDevice *scsi_bus_legacy_add_drive(SCSIBus *bus, BlockBackend *blk,
   int unit, bool removable, int bootindex,
+  bool share_rw,
   const char *serial, Error **errp);
 void scsi_bus_legacy_handle_cmdline(SCSIBus *bus, bool deprecated);
 void scsi_legacy_handle_cmdline(void);
-- 
2.14.3

Re: [Qemu-devel] [PATCH v2 2/3] xlnx-zynqmp-rtc: Add basic time support

[Alistair Francis]

On Mon, Jan 15, 2018 at 5:35 AM, Peter Maydell  wrote:
> On 12 January 2018 at 22:37, Alistair Francis
>  wrote:
>> Allow the guest to determine the time set from the QEMU command line.
>>
>> This includes adding a trace event to debug the new time.
>>
>> Signed-off-by: Alistair Francis 
>> ---
>>  - Convert DB_PRINT() macro to trace
>>
>>  hw/timer/trace-events  |  3 +++
>>  hw/timer/xlnx-zynqmp-rtc.c | 23 +++
>>  include/hw/timer/xlnx-zynqmp-rtc.h |  3 +++
>>  3 files changed, 29 insertions(+)
>>
>> diff --git a/hw/timer/trace-events b/hw/timer/trace-events
>> index 640722b5d1..e6e042fddb 100644
>> --- a/hw/timer/trace-events
>> +++ b/hw/timer/trace-events
>> @@ -60,3 +60,6 @@ systick_write(uint64_t addr, uint32_t value, unsigned 
>> size) "systick write addr
>>  cmsdk_apb_timer_read(uint64_t offset, uint64_t data, unsigned size) "CMSDK 
>> APB timer read: offset 0x%" PRIx64 " data 0x%" PRIx64 " size %u"
>>  cmsdk_apb_timer_write(uint64_t offset, uint64_t data, unsigned size) "CMSDK 
>> APB timer write: offset 0x%" PRIx64 " data 0x%" PRIx64 " size %u"
>>  cmsdk_apb_timer_reset(void) "CMSDK APB timer: reset"
>> +
>> +# hw/timer/xlnx-zynqmp-rtc.c
>> +xlnx_zynqmp_rtc_gettime(int year, int month, int day, int hour, int min, 
>> int sec) "Get time from host: %d-%d-%d %2d:%02d:%02d"
>> diff --git a/hw/timer/xlnx-zynqmp-rtc.c b/hw/timer/xlnx-zynqmp-rtc.c
>> index ead40fc42d..4adcc4701a 100644
>> --- a/hw/timer/xlnx-zynqmp-rtc.c
>> +++ b/hw/timer/xlnx-zynqmp-rtc.c
>> @@ -29,6 +29,7 @@
>>  #include "hw/register.h"
>>  #include "qemu/bitops.h"
>>  #include "qemu/log.h"
>> +#include "hw/ptimer.h"
>>  #include "hw/timer/xlnx-zynqmp-rtc.h"
>>
>>  #ifndef XLNX_ZYNQMP_RTC_ERR_DEBUG
>> @@ -47,6 +48,13 @@ static void addr_error_int_update_irq(XlnxZynqMPRTC *s)
>>  qemu_set_irq(s->irq_addr_error_int, pending);
>>  }
>>
>> +static uint64_t current_time_postr(RegisterInfo *reg, uint64_t val64)
>> +{
>> +XlnxZynqMPRTC *s = XLNX_ZYNQMP_RTC(reg->opaque);
>> +
>> +return mktime(>current_tm);
>
> No other timer device calls mktime(), so I suspect this is the wrong
> approach. (You may want something involving the QEMU mktimegm() utility
> function.)

Ah, mktimegm() gives me the correct timezone, that does work better.

>
> Also, looking at mc146818rtc.c it has logic for tracking what the
> guest thinks the RTC is, which might be at an offset from what the
> host's idea of the RTC is. I don't see anything like that here, which
> makes me think this patch is missing something.

My testing shows that what I have works with the date function in the
Xilinx kernel

If I start QEMU with
-rtc base=2017-10-17T16:01:21

I can run this:
root@xilinx-zcu102-2017_3:~# date
Tue Oct 17 16:01:28 UTC 2017

root@xilinx-zcu102-2017_3:~# date
Tue Oct 17 16:02:18 UTC 2017

The offset seems fine to me

>
>> +}
>> +
>>  static void rtc_int_status_postw(RegisterInfo *reg, uint64_t val64)
>>  {
>>  XlnxZynqMPRTC *s = XLNX_ZYNQMP_RTC(reg->opaque);
>> @@ -103,11 +111,13 @@ static const RegisterAccessInfo rtc_regs_info[] = {
>>  {   .name = "SET_TIME_WRITE",  .addr = A_SET_TIME_WRITE,
>>  },{ .name = "SET_TIME_READ",  .addr = A_SET_TIME_READ,
>>  .ro = 0x,
>> +.post_read = current_time_postr,
>>  },{ .name = "CALIB_WRITE",  .addr = A_CALIB_WRITE,
>>  },{ .name = "CALIB_READ",  .addr = A_CALIB_READ,
>>  .ro = 0x1f,
>>  },{ .name = "CURRENT_TIME",  .addr = A_CURRENT_TIME,
>>  .ro = 0x,
>> +.post_read = current_time_postr,
>>  },{ .name = "CURRENT_TICK",  .addr = A_CURRENT_TICK,
>>  .ro = 0x,
>>  },{ .name = "ALARM",  .addr = A_ALARM,
>> @@ -147,6 +157,12 @@ static void rtc_reset(DeviceState *dev)
>>  register_reset(>regs_info[i]);
>>  }
>>
>> +qemu_get_timedate(>current_tm, 0);
>> +
>> +trace_xlnx_zynqmp_rtc_gettime(s->current_tm.tm_year, 
>> s->current_tm.tm_mon,
>> +  s->current_tm.tm_mday, 
>> s->current_tm.tm_hour,
>> +  s->current_tm.tm_min, 
>> s->current_tm.tm_sec);
>> +
>>  rtc_int_update_irq(s);
>>  addr_error_int_update_irq(s);
>>  }
>> @@ -190,6 +206,13 @@ static const VMStateDescription vmstate_rtc = {
>>  .minimum_version_id = 1,
>>  .fields = (VMStateField[]) {
>>  VMSTATE_UINT32_ARRAY(regs, XlnxZynqMPRTC, XLNX_ZYNQMP_RTC_R_MAX),
>> +VMSTATE_INT32(current_tm.tm_sec, XlnxZynqMPRTC),
>> +VMSTATE_INT32(current_tm.tm_min, XlnxZynqMPRTC),
>> +VMSTATE_INT32(current_tm.tm_hour, XlnxZynqMPRTC),
>> +VMSTATE_INT32(current_tm.tm_wday, XlnxZynqMPRTC),
>> +VMSTATE_INT32(current_tm.tm_mday, XlnxZynqMPRTC),
>> +VMSTATE_INT32(current_tm.tm_mon, XlnxZynqMPRTC),
>> +VMSTATE_INT32(current_tm.tm_year, XlnxZynqMPRTC),
>
> Presumably the timer device has an internal 

Re: [Qemu-devel] [PATCH] LEON3 IRQMP: Fix IRQ software ack

[Alistair Francis]

On Mon, Jan 15, 2018 at 9:27 AM, Jean-Christophe Dubois
 wrote:
> Le 2018-01-15 14:45, Jean-Christophe Dubois a écrit :
>>
>> Le 2018-01-15 12:09, Fabien Chouteau a écrit :
>>>
>>> On 12/01/2018 15:10, Jean-Christophe Dubois wrote:

 Le 2018-01-12 11:55, Fabien Chouteau a écrit :
>
> On 11/01/2018 13:35, Jean-Christophe Dubois wrote:
>>
>> Thanks Fabien,
>>
>> Now, as a side question, could you tell me which reference LEON3
>> platform is implemented by Qemu in leon3_generic?
>>
>
> I think it was the based on the FPGA version of Leon3 I was using at
> the
> time. The name leon3_generic comes from my will to make it a
> configurable board where users could define the number and the location
> of the different peripherals, I never had time to work on this.


 I see. I am not sure how to bring configurability to Qemu. There is the
 possibility to describe the hw PTF with DTC/DTB or something similar. I
 think some people were working on it for the ARM Qemu platform (but I am 
 not
 sure what happened to this initiative).

 Now in the meantime, would it make sense to move leon3_generic to a tsim
 compatible platform?

>>>
>>> I don't think so, leon3_generic is compatible with a real hardware which
>>> is also interesting for comparison.
>>
>>
>> What real hardware (gaisler reference platform) is it? Could you point
>> to the public reference manual for this hardware?
>>
>> Another possibility is to add a leon3_tsim platform into Qemu to
>> support the compatibility with the tsim emulator. But the difference
>> with leon3_generic would be minimal.
>>
>>>
 This would allow to validate the same software on the 2 simulators
 (obviously it would not be compatible with your specific FPGA version for
 now).

>>>
>>> The Leon3 AMBA bus provides a way to discover the peripherals and their
>>> address, so any system should be capable of supporting different
>>> peripheral layouts.
>>>
>>> Here's an example of AMBA discovery code from a very old project of mine
>>> (don't judge me on this :) :
>>> https://github.com/Fabien-Chouteau/kabitbol/blob/master/src/amba.c
>>>
>>> There was a couple of patches submitted some times ago to add Leon3 AMBA
>>> support in QEMU, I think it's time to bring them back...
>>
>>
>> What you are talking about here is the possibility for the software
>> running inside Qemu to probe/discover the hardware. For such feature
>> Qemu should implement what is required for this AMBA discovery. But it
>> does not solve how you decide at run time at what addresses are the
>> various AMBA devices (how you decide to emulate a tsim platform or
>> another one).
>>
>> Note: For now I am not so much interested in the AMBA discovery as the
>> type of software platform I am thinking about is embedded where the
>> hardware is well known ahead of time. This discovery capability would
>> make sense for more generic OS like linux or such. We cannot require
>> all embedded OS to implement the AMBA discovery process.
>
>
> For the configurability of Qemu, I was thinking of using something similar
> to the Qemu provided by Xilinx (http://www.wiki.xilinx.com/QEMU). Basically,
> you provide a DTB file as a Qemu command line argument and Qemu will build
> the various devices (including addresses and interrupts) based on the
> content of this file. Then when running an OS, it can provide the DTB file
> (for example to Linux) that match exactly the emulated platform.
>
> This should allow to build "any" variation of the platform and to add
> devices as you need them. This makes sense for Xilinx (their customer are
> building custom platforms) and it would also make sense for LEON as the CPU
> core is usually integrated inside a custom SOC/FPGA.

This is a cool solution and works pretty well for us, but it requires
very complex code and is not easy to debug or maintain, just something
to keep in mind.

We also have a lot of trouble working with Linux device trees. For our
more complex ZynqMP SoC we have our own non-standard device trees as
the Linux ones don't include enough information.

Alistair

>
> JC
>

Re: [Qemu-devel] [PATCH v2 1/3] xlnx-zynqmp-rtc: Initial commit

[Alistair Francis]

On Mon, Jan 15, 2018 at 5:25 AM, Peter Maydell  wrote:
> On 12 January 2018 at 22:36, Alistair Francis
>  wrote:
>> Initial commit of the ZynqMP RTC device.
>>
>> Signed-off-by: Alistair Francis 
>> ---
>> V2:
>>  - Delete unused realise function
>>  - Remove DB_PRINT()
>>
>>  hw/timer/Makefile.objs |   1 +
>>  hw/timer/xlnx-zynqmp-rtc.c | 218 
>> +
>>  include/hw/timer/xlnx-zynqmp-rtc.h |  84 ++
>>  3 files changed, 303 insertions(+)
>>  create mode 100644 hw/timer/xlnx-zynqmp-rtc.c
>>  create mode 100644 include/hw/timer/xlnx-zynqmp-rtc.h
>>
>> diff --git a/hw/timer/Makefile.objs b/hw/timer/Makefile.objs
>> index 8c19eac3b6..8b27a4b7ef 100644
>> --- a/hw/timer/Makefile.objs
>> +++ b/hw/timer/Makefile.objs
>> @@ -21,6 +21,7 @@ common-obj-$(CONFIG_IMX) += imx_epit.o
>>  common-obj-$(CONFIG_IMX) += imx_gpt.o
>>  common-obj-$(CONFIG_LM32) += lm32_timer.o
>>  common-obj-$(CONFIG_MILKYMIST) += milkymist-sysctl.o
>> +common-obj-$(CONFIG_XLNX_ZYNQMP) += xlnx-zynqmp-rtc.o
>>
>>  obj-$(CONFIG_ALTERA_TIMER) += altera_timer.o
>>  obj-$(CONFIG_EXYNOS4) += exynos4210_mct.o
>> diff --git a/hw/timer/xlnx-zynqmp-rtc.c b/hw/timer/xlnx-zynqmp-rtc.c
>> new file mode 100644
>> index 00..ead40fc42d
>> --- /dev/null
>> +++ b/hw/timer/xlnx-zynqmp-rtc.c
>> @@ -0,0 +1,218 @@
>> +/*
>> + * QEMU model of the Xilinx ZynqMP Real Time Clock (RTC).
>> + *
>> + * Copyright (c) 2017 Xilinx Inc.
>> + *
>> + * Written-by: Alistair Francis 
>> + *
>> + * 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 "hw/sysbus.h"
>> +#include "hw/register.h"
>> +#include "qemu/bitops.h"
>> +#include "qemu/log.h"
>> +#include "hw/timer/xlnx-zynqmp-rtc.h"
>> +
>> +#ifndef XLNX_ZYNQMP_RTC_ERR_DEBUG
>> +#define XLNX_ZYNQMP_RTC_ERR_DEBUG 0
>> +#endif
>
> This #define doesn't seem to be used, or have I missed it?

As Philippe said, it is used in the init() function.

>
>> +
>> +static void rtc_int_update_irq(XlnxZynqMPRTC *s)
>> +{
>> +bool pending = s->regs[R_RTC_INT_STATUS] & ~s->regs[R_RTC_INT_MASK];
>> +qemu_set_irq(s->irq_rtc_int, pending);
>> +}
>> +
>> +static void addr_error_int_update_irq(XlnxZynqMPRTC *s)
>> +{
>> +bool pending = s->regs[R_ADDR_ERROR] & ~s->regs[R_ADDR_ERROR_INT_MASK];
>> +qemu_set_irq(s->irq_addr_error_int, pending);
>> +}
>> +
>> +static void rtc_int_status_postw(RegisterInfo *reg, uint64_t val64)
>> +{
>> +XlnxZynqMPRTC *s = XLNX_ZYNQMP_RTC(reg->opaque);
>> +rtc_int_update_irq(s);
>> +}
>> +
>> +static uint64_t rtc_int_en_prew(RegisterInfo *reg, uint64_t val64)
>> +{
>> +XlnxZynqMPRTC *s = XLNX_ZYNQMP_RTC(reg->opaque);
>> +uint32_t val = val64;
>> +
>> +s->regs[R_RTC_INT_MASK] &= ~val;
>> +rtc_int_update_irq(s);
>> +return 0;
>> +}
>
> I have to say I find all this pre-write/post-write stuff confusing
> compared to just having a straightforward pair of read and write functions
> for the device. Why do we update the interrupt state in a post-write
> for the status register but a pre-write for the int_en register ?

There isn't really a specific reason, I think this is just how it was
auto generated. Would you prefer them all to be post write?

>
>
>
>> +static void rtc_reset(DeviceState *dev)
>> +{
>> +XlnxZynqMPRTC *s = XLNX_ZYNQMP_RTC(dev);
>> +unsigned int i;
>> +
>> +for (i = 0; i < ARRAY_SIZE(s->regs_info); ++i) {
>> +register_reset(>regs_info[i]);
>> +}
>> +
>> +rtc_int_update_irq(s);
>> +addr_error_int_update_irq(s);
>> +}
>
> Updating irq lines in reset functions is a bit dubious.
> (We really should figure out how to do that properly some day.)

Is there a better way though?

>
>> This email and any attachments are 

[Qemu-devel] [PATCH] Add ability to provide ifname when using netdev bridge or tap helper

[Shaun Reitan]

This patch replaces the patch I sent yesturday. This one fixes
a bug in my original code as well as corrects a few styling
issues. Hopfully this one comes out correct!  Sorry for the
inconvienece.
 
When currently using -netdev bridge or -netdev tap with a helper
you are unable to set an ifname. This patch adds that ability so
that you can now specify an ifname.

Signed-off-by: Shaun Reitan 
---
 net/tap.c| 33 -
 qapi/net.json|  1 +
 qemu-bridge-helper.c | 11 +--
 qemu-options.hx  |  2 +-
 4 files changed, 35 insertions(+), 12 deletions(-)

diff --git a/net/tap.c b/net/tap.c
index 979e622..c4f3bb0 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -472,7 +472,7 @@ static int recv_fd(int c)
 }
 
 static int net_bridge_run_helper(const char *helper, const char *bridge,
- Error **errp)
+ const char *ifname, Error **errp)
 {
 sigset_t oldmask, mask;
 int pid, status;
@@ -499,7 +499,9 @@ static int net_bridge_run_helper(const char *helper, const 
char *bridge,
 int open_max = sysconf(_SC_OPEN_MAX), i;
 char fd_buf[6+10];
 char br_buf[6+IFNAMSIZ] = {0};
-char helper_cmd[PATH_MAX + sizeof(fd_buf) + sizeof(br_buf) + 15];
+char ifname_buf[10 + IFNAMSIZ];
+char helper_cmd[PATH_MAX + sizeof(fd_buf) + sizeof(br_buf)
++ sizeof(ifname_buf) + 16];
 
 for (i = 3; i < open_max; i++) {
 if (i != sv[1]) {
@@ -516,8 +518,13 @@ static int net_bridge_run_helper(const char *helper, const 
char *bridge,
 snprintf(br_buf, sizeof(br_buf), "%s%s", "--br=", bridge);
 }
 
-snprintf(helper_cmd, sizeof(helper_cmd), "%s %s %s %s",
- helper, "--use-vnet", fd_buf, br_buf);
+if (strstr(helper, "--ifname=") == NULL && ifname != NULL) {
+snprintf(ifname_buf, sizeof(ifname_buf), "%s%s", "--ifname=",
+ ifname);
+}
+
+snprintf(helper_cmd, sizeof(helper_cmd), "%s %s %s %s %s",
+ helper, "--use-vnet", fd_buf, br_buf, ifname_buf);
 
 parg = args;
 *parg++ = (char *)"sh";
@@ -536,6 +543,13 @@ static int net_bridge_run_helper(const char *helper, const 
char *bridge,
 *parg++ = (char *)"--use-vnet";
 *parg++ = fd_buf;
 *parg++ = br_buf;
+
+if (ifname != NULL) {
+snprintf(ifname_buf, sizeof(ifname_buf), "%s%s", "--ifname=",
+ ifname);
+*parg++ = ifname_buf;
+}
+
 *parg++ = NULL;
 
 execv(helper, args);
@@ -586,7 +600,7 @@ int net_init_bridge(const Netdev *netdev, const char *name,
 helper = bridge->has_helper ? bridge->helper : DEFAULT_BRIDGE_HELPER;
 br = bridge->has_br ? bridge->br : DEFAULT_BRIDGE_INTERFACE;
 
-fd = net_bridge_run_helper(helper, br, errp);
+fd = net_bridge_run_helper(helper, br, bridge->ifname, errp);
 if (fd == -1) {
 return -1;
 }
@@ -854,16 +868,17 @@ free_fail:
 g_free(vhost_fds);
 return -1;
 } else if (tap->has_helper) {
-if (tap->has_ifname || tap->has_script || tap->has_downscript ||
-tap->has_vnet_hdr || tap->has_queues || tap->has_vhostfds) {
-error_setg(errp, "ifname=, script=, downscript=, vnet_hdr=, "
-   "queues=, and vhostfds= are invalid with helper=");
+if (tap->has_script || tap->has_downscript || tap->has_vnet_hdr ||
+tap->has_queues || tap->has_vhostfds) {
+error_setg(errp, "script=, downscript=, vnet_hdr=, queues=, and "
+   "vhostfds= are invalid with helper=");
 return -1;
 }
 
 fd = net_bridge_run_helper(tap->helper,
tap->has_br ?
tap->br : DEFAULT_BRIDGE_INTERFACE,
+   tap->ifname,
errp);
 if (fd == -1) {
 return -1;
diff --git a/qapi/net.json b/qapi/net.json
index 4beff5d..5b5b281 100644
--- a/qapi/net.json
+++ b/qapi/net.json
@@ -402,6 +402,7 @@
 { 'struct': 'NetdevBridgeOptions',
   'data': {
 '*br': 'str',
+'*ifname': 'str',
 '*helper': 'str' } }
 
 ##
diff --git a/qemu-bridge-helper.c b/qemu-bridge-helper.c
index 5396fbf..7b01cd5 100644
--- a/qemu-bridge-helper.c
+++ b/qemu-bridge-helper.c
@@ -57,7 +57,7 @@ typedef QSIMPLEQ_HEAD(ACLList, ACLRule) ACLList;
 static void usage(void)
 {
 fprintf(stderr,
-"Usage: qemu-bridge-helper [--use-vnet] --br=bridge 
--fd=unixfd\n");
+"Usage: qemu-bridge-helper [--use-vnet] --br=bridge --fd=unixfd 
[--ifname=name]\n");
 }
 
 static int parse_acl_file(const char *filename, ACLList *acl_list)
@@ -223,6 +223,7 @@ int 

Re: [Qemu-devel] [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps

[Alexey Kardashevskiy]

On 17/01/18 10:30, David Gibson wrote:
> On Wed, Jan 17, 2018 at 10:26:28AM +1100, Alexey Kardashevskiy wrote:
>> On 17/01/18 09:34, David Gibson wrote:
>>> On Tue, Jan 16, 2018 at 03:46:20PM +0100, Andrea Bolognani wrote:
 On Wed, 2018-01-17 at 00:54 +1100, David Gibson wrote:
>> Correct me if I'm wrong, but it seems to me like there's no way
>> to figure out through QMP whether these new machine options can be
>> used for a given QEMU binary.
>
> Uh, I don't think so.  These are machine options like any other (just
> constructed a bit differently).  So they'll appear in qemu -machine
> pseries,? and I believe that info can also be retrieved with QMP.

 Yes, they will indeed show up in the output of -machine pseries,?
 but there's AFAICT no way to retrieve them via QMP.
>>>
>>> Really!?  I thought introspecting object properties was QMP's bread
>>> and butter.
>>
>>
>> On a guest started with '-S':
>> {"execute": "qom-list", "arguments": {"path": "/machine"}}
>>
>> returns:
>> {   'return': [   {'name': 'graphics', 'type': 'bool'},
>>   {'name': 'phandle-start', 'type': 'int'},
>>   {'name': 'dump-guest-core', 'type': 'bool'},
>>   {'name': 'kernel-irqchip', 'type': 'OnOffSplit'},
>>   {'name': 'accel', 'type': 'string'},
>>   {'name': 'append', 'type': 'string'},
>>   {'name': 'dumpdtb', 'type': 'string'},
>>   {'name': 'igd-passthru', 'type': 'bool'},
>>   {'name': 'dt-compatible', 'type': 'string'},
>>   {'name': 'kernel', 'type': 'string'},
>>   {'name': 'usb', 'type': 'bool'},
>>   {'name': 'suppress-vmdesc', 'type': 'bool'},
>>   {'name': 'dtb', 'type': 'string'},
>>   {'name': 'firmware', 'type': 'string'},
>>   {'name': 'mem-merge', 'type': 'bool'},
>>   {'name': 'initrd', 'type': 'string'},
>>   {'name': 'enforce-config-section', 'type': 'bool'},
>>   {'name': 'kvm-shadow-mem', 'type': 'int'},
>>   {'name': 'cap-dfp', 'type': 'bool'},
>>   {'name': 'cap-htm', 'type': 'bool'},
>>   {'name': 'cap-vsx', 'type': 'bool'},
>   ^^^
> Here are the cap properties.  Is it just Suraj's new tristate ones
> that aren't showing up?  If so that's weird...  are you sure you built
> with those patches included?

I am sure I do not have them, my point was that QMP has it all if they are
present in qemu :)


Here is rerun:


 {"execute": "qom-list", "arguments": {"path": "/machine"}}

{   'return': [   {'name': 'graphics', 'type': 'bool'},
  {'name': 'phandle-start', 'type': 'int'},
  {'name': 'dump-guest-core', 'type': 'bool'},
  {'name': 'kernel-irqchip', 'type': 'OnOffSplit'},
  {'name': 'accel', 'type': 'string'},
  {'name': 'append', 'type': 'string'},
  {'name': 'dumpdtb', 'type': 'string'},
  {'name': 'igd-passthru', 'type': 'bool'},
  {'name': 'dt-compatible', 'type': 'string'},
  {'name': 'kernel', 'type': 'string'},
  {'name': 'usb', 'type': 'bool'},
  {'name': 'suppress-vmdesc', 'type': 'bool'},
  {'name': 'dtb', 'type': 'string'},
  {'name': 'firmware', 'type': 'string'},
  {'name': 'mem-merge', 'type': 'bool'},
  {'name': 'initrd', 'type': 'string'},
  {'name': 'enforce-config-section', 'type': 'bool'},
  {'name': 'kvm-shadow-mem', 'type': 'int'},
  {'name': 'cap-ibs', 'type': 'string'},
  {'name': 'cap-cfpc', 'type': 'string'},
  {'name': 'cap-sbbc', 'type': 'string'},
  {'name': 'cap-dfp', 'type': 'bool'},
  {'name': 'cap-htm', 'type': 'bool'},
  {'name': 'cap-vsx', 'type': 'bool'},
  {'name': 'kvm-type', 'type': 'string'},
  {'name': 'max-cpu-compat', 'type': 'string'},
  {   'name': 'dr-connector[268435480]',
  'type': 'child'},
  {'name': 'peripheral', 'type': 'child'},
  {   'name': 'dr-connector[268435472]',
  'type': 'child'},
  {'name': 'modern-hotplug-events', 'type': 'bool'},
  {   'name': 'dr-connector[268435464]',
  'type': 'child'},
  {   'name': 'dr-connector[268435456]',
  'type': 'child'},
  {'name': 'peripheral-anon', 'type': 'child'},
  {'name': 'ics', 'type': 'child'},
  {'name': 'vsmt', 'type': 'uint32'},
  {'name': 'type', 'type': 'string'},
  

[Qemu-devel] [PATCH v5 8/9] xlnx-zynqmp-pmu: Connect the IPI device to the PMU

[Alistair Francis]

Signed-off-by: Alistair Francis 
Reviewed-by: Edgar E. Iglesias 
---
V4:
 - Move the IPI to the machine instead of the SoC

 hw/microblaze/xlnx-zynqmp-pmu.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/hw/microblaze/xlnx-zynqmp-pmu.c b/hw/microblaze/xlnx-zynqmp-pmu.c
index 828eeedc9f..14b8ed4a43 100644
--- a/hw/microblaze/xlnx-zynqmp-pmu.c
+++ b/hw/microblaze/xlnx-zynqmp-pmu.c
@@ -24,6 +24,7 @@
 #include "cpu.h"
 #include "boot.h"

+#include "hw/intc/xlnx-zynqmp-ipi.h"
 #include "hw/intc/xlnx-pmu-iomod-intc.h"

 /* Define the PMU device */
@@ -38,6 +39,15 @@

 #define XLNX_ZYNQMP_PMU_INTC_ADDR   0xFFD4

+#define XLNX_ZYNQMP_PMU_NUM_IPIS4
+
+static const uint64_t ipi_addr[XLNX_ZYNQMP_PMU_NUM_IPIS] = {
+0xFF34, 0xFF35, 0xFF36, 0xFF37,
+};
+static const uint64_t ipi_irq[XLNX_ZYNQMP_PMU_NUM_IPIS] = {
+19, 20, 21, 22,
+};
+
 typedef struct XlnxZynqMPPMUSoCState {
 /*< private >*/
 DeviceState parent_obj;
@@ -136,6 +146,9 @@ static void xlnx_zynqmp_pmu_init(MachineState *machine)
 MemoryRegion *address_space_mem = get_system_memory();
 MemoryRegion *pmu_rom = g_new(MemoryRegion, 1);
 MemoryRegion *pmu_ram = g_new(MemoryRegion, 1);
+XlnxZynqMPIPI *ipi[XLNX_ZYNQMP_PMU_NUM_IPIS];
+qemu_irq irq[32];
+int i;

 /* Create the ROM */
 memory_region_init_rom(pmu_rom, NULL, "xlnx-zynqmp-pmu.rom",
@@ -155,6 +168,24 @@ static void xlnx_zynqmp_pmu_init(MachineState *machine)
   _abort);
 object_property_set_bool(OBJECT(pmu), true, "realized", _fatal);

+for (i = 0; i < 32; i++) {
+irq[i] = qdev_get_gpio_in(DEVICE(>intc), i);
+}
+
+/* Create and connect the IPI device */
+for (i = 0; i < XLNX_ZYNQMP_PMU_NUM_IPIS; i++) {
+ipi[i] = g_new0(XlnxZynqMPIPI, 1);
+object_initialize(ipi[i], sizeof(XlnxZynqMPIPI), TYPE_XLNX_ZYNQMP_IPI);
+qdev_set_parent_bus(DEVICE(ipi[i]), sysbus_get_default());
+}
+
+for (i = 0; i < XLNX_ZYNQMP_PMU_NUM_IPIS; i++) {
+object_property_set_bool(OBJECT(ipi[i]), true, "realized",
+ _abort);
+sysbus_mmio_map(SYS_BUS_DEVICE(ipi[i]), 0, ipi_addr[i]);
+sysbus_connect_irq(SYS_BUS_DEVICE(ipi[i]), 0, irq[ipi_irq[i]]);
+}
+
 /* Load the kernel */
 microblaze_load_kernel(>cpu, XLNX_ZYNQMP_PMU_RAM_ADDR,
machine->ram_size,
--
2.14.1

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

[Qemu-devel] [PATCH v5 5/9] xlnx-pmu-iomod-intc: Add the PMU Interrupt controller

[Alistair Francis]

Add the PMU IO Module Interrupt controller device.

Signed-off-by: Alistair Francis 
Reviewed-by: Edgar E. Iglesias 
---

 default-configs/microblaze-softmmu.mak |   1 +
 hw/intc/Makefile.objs  |   1 +
 hw/intc/xlnx-pmu-iomod-intc.c  | 554 +
 include/hw/intc/xlnx-pmu-iomod-intc.h  |  58 
 4 files changed, 614 insertions(+)
 create mode 100644 hw/intc/xlnx-pmu-iomod-intc.c
 create mode 100644 include/hw/intc/xlnx-pmu-iomod-intc.h

diff --git a/default-configs/microblaze-softmmu.mak 
b/default-configs/microblaze-softmmu.mak
index ce2630818a..7fca8e4c99 100644
--- a/default-configs/microblaze-softmmu.mak
+++ b/default-configs/microblaze-softmmu.mak
@@ -9,3 +9,4 @@ CONFIG_XILINX_SPI=y
 CONFIG_XILINX_ETHLITE=y
 CONFIG_SSI=y
 CONFIG_SSI_M25P80=y
+CONFIG_XLNX_ZYNQMP=y
diff --git a/hw/intc/Makefile.objs b/hw/intc/Makefile.objs
index ae358569a1..211655023e 100644
--- a/hw/intc/Makefile.objs
+++ b/hw/intc/Makefile.objs
@@ -3,6 +3,7 @@ common-obj-$(CONFIG_I8259) += i8259_common.o i8259.o
 common-obj-$(CONFIG_PL190) += pl190.o
 common-obj-$(CONFIG_PUV3) += puv3_intc.o
 common-obj-$(CONFIG_XILINX) += xilinx_intc.o
+common-obj-$(CONFIG_XLNX_ZYNQMP) += xlnx-pmu-iomod-intc.o
 common-obj-$(CONFIG_ETRAXFS) += etraxfs_pic.o
 common-obj-$(CONFIG_IMX) += imx_avic.o
 common-obj-$(CONFIG_LM32) += lm32_pic.o
diff --git a/hw/intc/xlnx-pmu-iomod-intc.c b/hw/intc/xlnx-pmu-iomod-intc.c
new file mode 100644
index 00..1ce2f4fa6b
--- /dev/null
+++ b/hw/intc/xlnx-pmu-iomod-intc.c
@@ -0,0 +1,554 @@
+/*
+ * QEMU model of Xilinx I/O Module Interrupt Controller
+ *
+ * Copyright (c) 2013 Xilinx Inc
+ * Written by Edgar E. Iglesias 
+ * Written by Alistair Francis 
+ *
+ * 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 "hw/sysbus.h"
+#include "hw/register.h"
+#include "qemu/bitops.h"
+#include "qemu/log.h"
+#include "hw/intc/xlnx-pmu-iomod-intc.h"
+
+#ifndef XLNX_PMU_IO_INTC_ERR_DEBUG
+#define XLNX_PMU_IO_INTC_ERR_DEBUG 0
+#endif
+
+#define DB_PRINT_L(lvl, fmt, args...) do {\
+if (XLNX_PMU_IO_INTC_ERR_DEBUG >= lvl) {\
+qemu_log(TYPE_XLNX_PMU_IO_INTC ": %s:" fmt, __func__, ## args);\
+} \
+} while (0)
+
+#define DB_PRINT(fmt, args...) DB_PRINT_L(1, fmt, ## args)
+
+REG32(IRQ_MODE, 0xc)
+REG32(GPO0, 0x10)
+FIELD(GPO0, MAGIC_WORD_1, 24, 8)
+FIELD(GPO0, MAGIC_WORD_2, 16, 8)
+FIELD(GPO0, FT_INJECT_FAILURE, 13, 3)
+FIELD(GPO0, DISABLE_RST_FTSM, 12, 1)
+FIELD(GPO0, RST_FTSM, 11, 1)
+FIELD(GPO0, CLR_FTSTS, 10, 1)
+FIELD(GPO0, RST_ON_SLEEP, 9, 1)
+FIELD(GPO0, DISABLE_TRACE_COMP, 8, 1)
+FIELD(GPO0, PIT3_PRESCALE, 7, 1)
+FIELD(GPO0, PIT2_PRESCALE, 5, 2)
+FIELD(GPO0, PIT1_PRESCALE, 3, 2)
+FIELD(GPO0, PIT0_PRESCALE, 1, 2)
+FIELD(GPO0, DEBUG_REMAP, 0, 1)
+REG32(GPO1, 0x14)
+FIELD(GPO1, MIO_5, 5, 1)
+FIELD(GPO1, MIO_4, 4, 1)
+FIELD(GPO1, MIO_3, 3, 1)
+FIELD(GPO1, MIO_2, 2, 1)
+FIELD(GPO1, MIO_1, 1, 1)
+FIELD(GPO1, MIO_0, 0, 1)
+REG32(GPO2, 0x18)
+FIELD(GPO2, DAP_RPU_WAKE_ACK, 9, 1)
+FIELD(GPO2, DAP_FP_WAKE_ACK, 8, 1)
+FIELD(GPO2, PS_STATUS, 7, 1)
+FIELD(GPO2, PCAP_EN, 6, 1)
+REG32(GPO3, 0x1c)
+FIELD(GPO3, PL_GPO_31, 31, 1)
+FIELD(GPO3, PL_GPO_30, 30, 1)
+FIELD(GPO3, PL_GPO_29, 29, 1)
+FIELD(GPO3, PL_GPO_28, 28, 1)
+FIELD(GPO3, PL_GPO_27, 27, 1)
+FIELD(GPO3, PL_GPO_26, 26, 1)
+FIELD(GPO3, PL_GPO_25, 25, 1)
+FIELD(GPO3, PL_GPO_24, 24, 1)
+FIELD(GPO3, PL_GPO_23, 23, 1)
+FIELD(GPO3, PL_GPO_22, 22, 1)
+FIELD(GPO3, PL_GPO_21, 21, 1)
+FIELD(GPO3, PL_GPO_20, 20, 1)
+FIELD(GPO3, PL_GPO_19, 19, 1)
+FIELD(GPO3, PL_GPO_18, 18, 1)
+FIELD(GPO3, PL_GPO_17, 17, 1)
+FIELD(GPO3, PL_GPO_16, 16, 1)
+FIELD(GPO3, PL_GPO_15, 15, 1)
+FIELD(GPO3, PL_GPO_14, 14, 1)
+  

Re: [Qemu-devel] [PATCH v5 0/9] Add the ZynqMP PMU and IPI

[Alistair Francis]

On Tue, Jan 16, 2018 at 3:22 PM, Alistair Francis
 wrote:
>
> This series adds the ZynqMP Power Management Unit (PMU) machine with basic
> functionality.
>
> The machine only has the
>  - CPU
>  - Memory
>  - Interrupt controller
>  - IPI device
>
> connected, but that is enough to run some of the ROM and firmware
> code on the machine
>
> The series also adds the IPI device and connects it to the ZynqMP ARM
> side and the ZynqMP PMU. These IPI devices don't connect between the ARM
> and MicroBlaze instances though.
>
> V5:
>  - Fix clang makecheck error
>  - Rebase on master
> V4:
>  - Rename the ZCU102 machine to just ZynqMP
>  - Rename the PMC SoC to "xlnx,zynqmp-pmu-soc"
>  - Move the IPI device to the machine instead of the SoC
> V3:
>  - Add the interrupt controller
>  - Replace some of the error_fatals with errp
>  - Fix the PMU CPU name
>
>
>
> Alistair Francis (9):
>   microblaze: boot.c: Don't try to find NULL pointer
>   xlnx-zynqmp-pmu: Initial commit of the ZynqMP PMU
>   xlnx-zynqmp-pmu: Add the CPU and memory
>   aarch64-softmmu.mak: Use an ARM specific config
>   xlnx-pmu-iomod-intc: Add the PMU Interrupt controller
>   xlnx-zynqmp-pmu: Connect the PMU interrupt controller
>   xlnx-zynqmp-ipi: Initial version of the Xilinx IPI device
>   xlnx-zynqmp-pmu: Connect the IPI device to the PMU
>   xlnx-zynqmp: Connect the IPI device to the ZynqMP SoC
>
>  default-configs/aarch64-softmmu.mak|   1 +
>  default-configs/microblaze-softmmu.mak |   1 +
>  hw/arm/Makefile.objs   |   2 +-
>  hw/arm/xlnx-zynqmp.c   |  14 +
>  hw/display/Makefile.objs   |   2 +-
>  hw/dma/Makefile.objs   |   1 +
>  hw/intc/Makefile.objs  |   2 +
>  hw/intc/xlnx-pmu-iomod-intc.c  | 554 
> +
>  hw/intc/xlnx-zynqmp-ipi.c  | 377 ++
>  hw/microblaze/Makefile.objs|   1 +
>  hw/microblaze/boot.c   |   2 +-
>  hw/microblaze/xlnx-zynqmp-pmu.c| 204 
>  include/hw/arm/xlnx-zynqmp.h   |   2 +
>  include/hw/intc/xlnx-pmu-iomod-intc.h  |  58 
>  include/hw/intc/xlnx-zynqmp-ipi.h  |  57 
>  15 files changed, 1275 insertions(+), 3 deletions(-)
>  create mode 100644 hw/intc/xlnx-pmu-iomod-intc.c
>  create mode 100644 hw/intc/xlnx-zynqmp-ipi.c
>  create mode 100644 hw/microblaze/xlnx-zynqmp-pmu.c
>  create mode 100644 include/hw/intc/xlnx-pmu-iomod-intc.h
>  create mode 100644 include/hw/intc/xlnx-zynqmp-ipi.h
>
> --
> 2.14.1
>
> This email and any attachments are intended for the sole use of the named 
> recipient(s) and contain(s) confidential information that may be proprietary, 
> privileged or copyrighted under applicable law. If you are not the intended 
> recipient, do not read, copy, or forward this email message or any 
> attachments. Delete this email message and any attachments immediately.

ARGH! Apparently Xilinx started this crap up again. I didn't realise
this is on all my emails. I'll work on getting it removed.

Alistair

[Qemu-devel] [PATCH v5 7/9] xlnx-zynqmp-ipi: Initial version of the Xilinx IPI device

[Alistair Francis]

This is the initial version of the Inter Processor Interrupt device.

Signed-off-by: Alistair Francis 
Reviewed-by: Edgar E. Iglesias 
---

 hw/intc/Makefile.objs |   1 +
 hw/intc/xlnx-zynqmp-ipi.c | 377 ++
 include/hw/intc/xlnx-zynqmp-ipi.h |  57 ++
 3 files changed, 435 insertions(+)
 create mode 100644 hw/intc/xlnx-zynqmp-ipi.c
 create mode 100644 include/hw/intc/xlnx-zynqmp-ipi.h

diff --git a/hw/intc/Makefile.objs b/hw/intc/Makefile.objs
index 211655023e..571e094a14 100644
--- a/hw/intc/Makefile.objs
+++ b/hw/intc/Makefile.objs
@@ -4,6 +4,7 @@ common-obj-$(CONFIG_PL190) += pl190.o
 common-obj-$(CONFIG_PUV3) += puv3_intc.o
 common-obj-$(CONFIG_XILINX) += xilinx_intc.o
 common-obj-$(CONFIG_XLNX_ZYNQMP) += xlnx-pmu-iomod-intc.o
+common-obj-$(CONFIG_XLNX_ZYNQMP) += xlnx-zynqmp-ipi.o
 common-obj-$(CONFIG_ETRAXFS) += etraxfs_pic.o
 common-obj-$(CONFIG_IMX) += imx_avic.o
 common-obj-$(CONFIG_LM32) += lm32_pic.o
diff --git a/hw/intc/xlnx-zynqmp-ipi.c b/hw/intc/xlnx-zynqmp-ipi.c
new file mode 100644
index 00..aa50a8ac08
--- /dev/null
+++ b/hw/intc/xlnx-zynqmp-ipi.c
@@ -0,0 +1,377 @@
+/*
+ * QEMU model of the IPI Inter Processor Interrupt block
+ *
+ * Copyright (c) 2014 Xilinx Inc.
+ *
+ * Written by Edgar E. Iglesias 
+ * Written by Alistair Francis 
+ *
+ * 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 "hw/sysbus.h"
+#include "hw/register.h"
+#include "qemu/bitops.h"
+#include "qemu/log.h"
+#include "hw/intc/xlnx-zynqmp-ipi.h"
+
+#ifndef XLNX_ZYNQMP_IPI_ERR_DEBUG
+#define XLNX_ZYNQMP_IPI_ERR_DEBUG 0
+#endif
+
+#define DB_PRINT_L(lvl, fmt, args...) do {\
+if (XLNX_ZYNQMP_IPI_ERR_DEBUG >= lvl) {\
+qemu_log(TYPE_XLNX_ZYNQMP_IPI ": %s:" fmt, __func__, ## args);\
+} \
+} while (0)
+
+#define DB_PRINT(fmt, args...) DB_PRINT_L(1, fmt, ## args)
+
+REG32(IPI_TRIG, 0x0)
+FIELD(IPI_TRIG, PL_3, 27, 1)
+FIELD(IPI_TRIG, PL_2, 26, 1)
+FIELD(IPI_TRIG, PL_1, 25, 1)
+FIELD(IPI_TRIG, PL_0, 24, 1)
+FIELD(IPI_TRIG, PMU_3, 19, 1)
+FIELD(IPI_TRIG, PMU_2, 18, 1)
+FIELD(IPI_TRIG, PMU_1, 17, 1)
+FIELD(IPI_TRIG, PMU_0, 16, 1)
+FIELD(IPI_TRIG, RPU_1, 9, 1)
+FIELD(IPI_TRIG, RPU_0, 8, 1)
+FIELD(IPI_TRIG, APU, 0, 1)
+REG32(IPI_OBS, 0x4)
+FIELD(IPI_OBS, PL_3, 27, 1)
+FIELD(IPI_OBS, PL_2, 26, 1)
+FIELD(IPI_OBS, PL_1, 25, 1)
+FIELD(IPI_OBS, PL_0, 24, 1)
+FIELD(IPI_OBS, PMU_3, 19, 1)
+FIELD(IPI_OBS, PMU_2, 18, 1)
+FIELD(IPI_OBS, PMU_1, 17, 1)
+FIELD(IPI_OBS, PMU_0, 16, 1)
+FIELD(IPI_OBS, RPU_1, 9, 1)
+FIELD(IPI_OBS, RPU_0, 8, 1)
+FIELD(IPI_OBS, APU, 0, 1)
+REG32(IPI_ISR, 0x10)
+FIELD(IPI_ISR, PL_3, 27, 1)
+FIELD(IPI_ISR, PL_2, 26, 1)
+FIELD(IPI_ISR, PL_1, 25, 1)
+FIELD(IPI_ISR, PL_0, 24, 1)
+FIELD(IPI_ISR, PMU_3, 19, 1)
+FIELD(IPI_ISR, PMU_2, 18, 1)
+FIELD(IPI_ISR, PMU_1, 17, 1)
+FIELD(IPI_ISR, PMU_0, 16, 1)
+FIELD(IPI_ISR, RPU_1, 9, 1)
+FIELD(IPI_ISR, RPU_0, 8, 1)
+FIELD(IPI_ISR, APU, 0, 1)
+REG32(IPI_IMR, 0x14)
+FIELD(IPI_IMR, PL_3, 27, 1)
+FIELD(IPI_IMR, PL_2, 26, 1)
+FIELD(IPI_IMR, PL_1, 25, 1)
+FIELD(IPI_IMR, PL_0, 24, 1)
+FIELD(IPI_IMR, PMU_3, 19, 1)
+FIELD(IPI_IMR, PMU_2, 18, 1)
+FIELD(IPI_IMR, PMU_1, 17, 1)
+FIELD(IPI_IMR, PMU_0, 16, 1)
+FIELD(IPI_IMR, RPU_1, 9, 1)
+FIELD(IPI_IMR, RPU_0, 8, 1)
+FIELD(IPI_IMR, APU, 0, 1)
+REG32(IPI_IER, 0x18)
+FIELD(IPI_IER, PL_3, 27, 1)
+FIELD(IPI_IER, PL_2, 26, 1)
+FIELD(IPI_IER, PL_1, 25, 1)
+FIELD(IPI_IER, PL_0, 24, 1)
+FIELD(IPI_IER, PMU_3, 19, 1)
+FIELD(IPI_IER, PMU_2, 18, 1)
+FIELD(IPI_IER, PMU_1, 17, 1)
+FIELD(IPI_IER, PMU_0, 16, 1)
+FIELD(IPI_IER, RPU_1, 9, 1)
+FIELD(IPI_IER, RPU_0, 8, 1)
+FIELD(IPI_IER, APU, 0, 1)

Re: [Qemu-devel] [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps

[David Gibson]

On Wed, Jan 17, 2018 at 10:26:28AM +1100, Alexey Kardashevskiy wrote:
> On 17/01/18 09:34, David Gibson wrote:
> > On Tue, Jan 16, 2018 at 03:46:20PM +0100, Andrea Bolognani wrote:
> >> On Wed, 2018-01-17 at 00:54 +1100, David Gibson wrote:
>  Correct me if I'm wrong, but it seems to me like there's no way
>  to figure out through QMP whether these new machine options can be
>  used for a given QEMU binary.
> >>>
> >>> Uh, I don't think so.  These are machine options like any other (just
> >>> constructed a bit differently).  So they'll appear in qemu -machine
> >>> pseries,? and I believe that info can also be retrieved with QMP.
> >>
> >> Yes, they will indeed show up in the output of -machine pseries,?
> >> but there's AFAICT no way to retrieve them via QMP.
> > 
> > Really!?  I thought introspecting object properties was QMP's bread
> > and butter.
> 
> 
> On a guest started with '-S':
> {"execute": "qom-list", "arguments": {"path": "/machine"}}
> 
> returns:
> {   'return': [   {'name': 'graphics', 'type': 'bool'},
>   {'name': 'phandle-start', 'type': 'int'},
>   {'name': 'dump-guest-core', 'type': 'bool'},
>   {'name': 'kernel-irqchip', 'type': 'OnOffSplit'},
>   {'name': 'accel', 'type': 'string'},
>   {'name': 'append', 'type': 'string'},
>   {'name': 'dumpdtb', 'type': 'string'},
>   {'name': 'igd-passthru', 'type': 'bool'},
>   {'name': 'dt-compatible', 'type': 'string'},
>   {'name': 'kernel', 'type': 'string'},
>   {'name': 'usb', 'type': 'bool'},
>   {'name': 'suppress-vmdesc', 'type': 'bool'},
>   {'name': 'dtb', 'type': 'string'},
>   {'name': 'firmware', 'type': 'string'},
>   {'name': 'mem-merge', 'type': 'bool'},
>   {'name': 'initrd', 'type': 'string'},
>   {'name': 'enforce-config-section', 'type': 'bool'},
>   {'name': 'kvm-shadow-mem', 'type': 'int'},
>   {'name': 'cap-dfp', 'type': 'bool'},
>   {'name': 'cap-htm', 'type': 'bool'},
>   {'name': 'cap-vsx', 'type': 'bool'},
  ^^^
Here are the cap properties.  Is it just Suraj's new tristate ones
that aren't showing up?  If so that's weird...  are you sure you built
with those patches included?

>   {'name': 'vfio-no-msix-emulation', 'type': 'bool'},
>   {'name': 'kvm-type', 'type': 'string'},
>   {'name': 'max-cpu-compat', 'type': 'string'},
>   {   'name': 'dr-connector[268435480]',
>   'type': 'child'},
>   {'name': 'peripheral', 'type': 'child'},
>   {   'name': 'dr-connector[268435472]',
>   'type': 'child'},
>   {'name': 'modern-hotplug-events', 'type': 'bool'},
>   {   'name': 'dr-connector[268435464]',
>   'type': 'child'},
>   {   'name': 'dr-connector[268435456]',
>   'type': 'child'},
>   {'name': 'peripheral-anon', 'type': 'child'},
>   {'name': 'ics', 'type': 'child'},
>   {'name': 'vsmt', 'type': 'uint32'},
>   {'name': 'type', 'type': 'string'},
>   {'name': 'rtc-time', 'type': 'struct tm'},
>   {'name': 'unattached', 'type': 'child'},
>   {'name': 'rtc', 'type': 'child'},
>   {'name': 'resize-hpt', 'type': 'string'}]}
> 
> 
> but still requires a running qemu, yes.
> 
> > 
> >> And libvirt
> >> can't afford to spawn a QEMU process for each machine type
> >> implemented by each QEMU binary installed on the system just to
> >> figure out what properties they support; in fact, we've been
> >> pushing away from that approach - which was used initially - for
> >> years and we're now at the point where we only fall back to it
> >> for positively ancient QEMU versions. So the information needs
> >> to be available through QMP for libvirt to consume it.
> > 
> > Right, I'm not arguing with that.  It's just that I thought that
> > standard QOM properties on QOM objects (the machine in this case) met
> > the criteria.
> > 
> 
> 




-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

[Qemu-devel] [PATCH v5 6/9] xlnx-zynqmp-pmu: Connect the PMU interrupt controller

[Alistair Francis]

Signed-off-by: Alistair Francis 
Reviewed-by: Edgar E. Iglesias 
---

 hw/microblaze/xlnx-zynqmp-pmu.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/hw/microblaze/xlnx-zynqmp-pmu.c b/hw/microblaze/xlnx-zynqmp-pmu.c
index c6a0b3b8a1..828eeedc9f 100644
--- a/hw/microblaze/xlnx-zynqmp-pmu.c
+++ b/hw/microblaze/xlnx-zynqmp-pmu.c
@@ -24,6 +24,8 @@
 #include "cpu.h"
 #include "boot.h"

+#include "hw/intc/xlnx-pmu-iomod-intc.h"
+
 /* Define the PMU device */

 #define TYPE_XLNX_ZYNQMP_PMU_SOC "xlnx,zynqmp-pmu-soc"
@@ -34,14 +36,18 @@
 #define XLNX_ZYNQMP_PMU_ROM_ADDR0xFFD0
 #define XLNX_ZYNQMP_PMU_RAM_ADDR0xFFDC

+#define XLNX_ZYNQMP_PMU_INTC_ADDR   0xFFD4
+
 typedef struct XlnxZynqMPPMUSoCState {
 /*< private >*/
 DeviceState parent_obj;

 /*< public >*/
 MicroBlazeCPU cpu;
+XlnxPMUIOIntc intc;
 }  XlnxZynqMPPMUSoCState;

+
 static void xlnx_zynqmp_pmu_soc_init(Object *obj)
 {
 XlnxZynqMPPMUSoCState *s = XLNX_ZYNQMP_PMU_SOC(obj);
@@ -50,6 +56,9 @@ static void xlnx_zynqmp_pmu_soc_init(Object *obj)
   TYPE_MICROBLAZE_CPU);
 object_property_add_child(obj, "pmu-cpu", OBJECT(>cpu),
   _abort);
+
+object_initialize(>intc, sizeof(s->intc), TYPE_XLNX_PMU_IO_INTC);
+qdev_set_parent_bus(DEVICE(>intc), sysbus_get_default());
 }

 static void xlnx_zynqmp_pmu_soc_realize(DeviceState *dev, Error **errp)
@@ -80,6 +89,21 @@ static void xlnx_zynqmp_pmu_soc_realize(DeviceState *dev, 
Error **errp)
 error_propagate(errp, err);
 return;
 }
+
+object_property_set_uint(OBJECT(>intc), 0x10, "intc-intr-size",
+ _abort);
+object_property_set_uint(OBJECT(>intc), 0x0, "intc-level-edge",
+ _abort);
+object_property_set_uint(OBJECT(>intc), 0x, "intc-positive",
+ _abort);
+object_property_set_bool(OBJECT(>intc), true, "realized", );
+if (err) {
+error_propagate(errp, err);
+return;
+}
+sysbus_mmio_map(SYS_BUS_DEVICE(>intc), 0, XLNX_ZYNQMP_PMU_INTC_ADDR);
+sysbus_connect_irq(SYS_BUS_DEVICE(>intc), 0,
+   qdev_get_gpio_in(DEVICE(>cpu), MB_CPU_IRQ));
 }

 static void xlnx_zynqmp_pmu_soc_class_init(ObjectClass *oc, void *data)
--
2.14.1

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

[Qemu-devel] [PATCH v5 3/9] xlnx-zynqmp-pmu: Add the CPU and memory

[Alistair Francis]

Connect the MicroBlaze CPU and the ROM and RAM memory regions.

Signed-off-by: Alistair Francis 
Reviewed-by: Edgar E. Iglesias 
---

V4:
 - Remove the ZCU102 name
V2:
 - Fix the pmu-cpu name
 - Use err and errp for CPU realise instead of error_fatal

 hw/microblaze/xlnx-zynqmp-pmu.c | 70 +++--
 1 file changed, 68 insertions(+), 2 deletions(-)

diff --git a/hw/microblaze/xlnx-zynqmp-pmu.c b/hw/microblaze/xlnx-zynqmp-pmu.c
index ac0f78928a..c6a0b3b8a1 100644
--- a/hw/microblaze/xlnx-zynqmp-pmu.c
+++ b/hw/microblaze/xlnx-zynqmp-pmu.c
@@ -18,8 +18,11 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
 #include "qemu-common.h"
+#include "exec/address-spaces.h"
 #include "hw/boards.h"
+#include "hw/qdev-properties.h"
 #include "cpu.h"
+#include "boot.h"

 /* Define the PMU device */

@@ -27,21 +30,56 @@
 #define XLNX_ZYNQMP_PMU_SOC(obj) OBJECT_CHECK(XlnxZynqMPPMUSoCState, (obj), \
   TYPE_XLNX_ZYNQMP_PMU_SOC)

+#define XLNX_ZYNQMP_PMU_ROM_SIZE0x8000
+#define XLNX_ZYNQMP_PMU_ROM_ADDR0xFFD0
+#define XLNX_ZYNQMP_PMU_RAM_ADDR0xFFDC
+
 typedef struct XlnxZynqMPPMUSoCState {
 /*< private >*/
 DeviceState parent_obj;

 /*< public >*/
+MicroBlazeCPU cpu;
 }  XlnxZynqMPPMUSoCState;

 static void xlnx_zynqmp_pmu_soc_init(Object *obj)
 {
+XlnxZynqMPPMUSoCState *s = XLNX_ZYNQMP_PMU_SOC(obj);

+object_initialize(>cpu, sizeof(s->cpu),
+  TYPE_MICROBLAZE_CPU);
+object_property_add_child(obj, "pmu-cpu", OBJECT(>cpu),
+  _abort);
 }

 static void xlnx_zynqmp_pmu_soc_realize(DeviceState *dev, Error **errp)
 {
-
+XlnxZynqMPPMUSoCState *s = XLNX_ZYNQMP_PMU_SOC(dev);
+Error *err = NULL;
+
+object_property_set_uint(OBJECT(>cpu), XLNX_ZYNQMP_PMU_ROM_ADDR,
+ "base-vectors", _abort);
+object_property_set_bool(OBJECT(>cpu), true, "use-stack-protection",
+ _abort);
+object_property_set_uint(OBJECT(>cpu), 0, "use-fpu", _abort);
+object_property_set_uint(OBJECT(>cpu), 0, "use-hw-mul", _abort);
+object_property_set_bool(OBJECT(>cpu), true, "use-barrel",
+ _abort);
+object_property_set_bool(OBJECT(>cpu), true, "use-msr-instr",
+ _abort);
+object_property_set_bool(OBJECT(>cpu), true, "use-pcmp-instr",
+ _abort);
+object_property_set_bool(OBJECT(>cpu), false, "use-mmu", _abort);
+object_property_set_bool(OBJECT(>cpu), true, "endianness",
+ _abort);
+object_property_set_str(OBJECT(>cpu), "8.40.b", "version",
+_abort);
+object_property_set_uint(OBJECT(>cpu), 0, "pvr", _abort);
+object_property_set_bool(OBJECT(>cpu), true, "realized", );
+if (err) {
+error_propagate(errp, err);
+return;
+}
 }

 static void xlnx_zynqmp_pmu_soc_class_init(ObjectClass *oc, void *data)
@@ -70,7 +108,35 @@ type_init(xlnx_zynqmp_pmu_soc_register_types)

 static void xlnx_zynqmp_pmu_init(MachineState *machine)
 {
-
+XlnxZynqMPPMUSoCState *pmu = g_new0(XlnxZynqMPPMUSoCState, 1);
+MemoryRegion *address_space_mem = get_system_memory();
+MemoryRegion *pmu_rom = g_new(MemoryRegion, 1);
+MemoryRegion *pmu_ram = g_new(MemoryRegion, 1);
+
+/* Create the ROM */
+memory_region_init_rom(pmu_rom, NULL, "xlnx-zynqmp-pmu.rom",
+   XLNX_ZYNQMP_PMU_ROM_SIZE, _fatal);
+memory_region_add_subregion(address_space_mem, XLNX_ZYNQMP_PMU_ROM_ADDR,
+pmu_rom);
+
+/* Create the RAM */
+memory_region_init_ram(pmu_ram, NULL, "xlnx-zynqmp-pmu.ram",
+   machine->ram_size, _fatal);
+memory_region_add_subregion(address_space_mem, XLNX_ZYNQMP_PMU_RAM_ADDR,
+pmu_ram);
+
+/* Create the PMU device */
+object_initialize(pmu, sizeof(XlnxZynqMPPMUSoCState), 
TYPE_XLNX_ZYNQMP_PMU_SOC);
+object_property_add_child(OBJECT(machine), "pmu", OBJECT(pmu),
+  _abort);
+object_property_set_bool(OBJECT(pmu), true, "realized", _fatal);
+
+/* Load the kernel */
+microblaze_load_kernel(>cpu, XLNX_ZYNQMP_PMU_RAM_ADDR,
+   machine->ram_size,
+   machine->kernel_filename,
+   machine->dtb,
+   NULL);
 }

 static void xlnx_zynqmp_pmu_machine_init(MachineClass *mc)
--
2.14.1

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments 

[Qemu-devel] [PATCH v5 4/9] aarch64-softmmu.mak: Use an ARM specific config

[Alistair Francis]

In preperation for having an ARM and MicroBlaze ZynqMP machine let's
split out the current ARM specific config options.

Signed-off-by: Alistair Francis 
Acked-by: Peter Maydell 
Reviewed-by: Edgar E. Iglesias 
---

 default-configs/aarch64-softmmu.mak | 1 +
 hw/arm/Makefile.objs| 2 +-
 hw/display/Makefile.objs| 2 +-
 hw/dma/Makefile.objs| 1 +
 4 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/default-configs/aarch64-softmmu.mak 
b/default-configs/aarch64-softmmu.mak
index 24494832cf..9ddccf855e 100644
--- a/default-configs/aarch64-softmmu.mak
+++ b/default-configs/aarch64-softmmu.mak
@@ -7,3 +7,4 @@ CONFIG_AUX=y
 CONFIG_DDC=y
 CONFIG_DPCD=y
 CONFIG_XLNX_ZYNQMP=y
+CONFIG_XLNX_ZYNQMP_ARM=y
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 2794e086d6..1c896bafb4 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -13,7 +13,7 @@ obj-y += omap1.o omap2.o strongarm.o
 obj-$(CONFIG_ALLWINNER_A10) += allwinner-a10.o cubieboard.o
 obj-$(CONFIG_RASPI) += bcm2835_peripherals.o bcm2836.o raspi.o
 obj-$(CONFIG_STM32F205_SOC) += stm32f205_soc.o
-obj-$(CONFIG_XLNX_ZYNQMP) += xlnx-zynqmp.o xlnx-zcu102.o
+obj-$(CONFIG_XLNX_ZYNQMP_ARM) += xlnx-zynqmp.o xlnx-zcu102.o
 obj-$(CONFIG_FSL_IMX25) += fsl-imx25.o imx25_pdk.o
 obj-$(CONFIG_FSL_IMX31) += fsl-imx31.o kzm.o
 obj-$(CONFIG_FSL_IMX6) += fsl-imx6.o sabrelite.o
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index 551c050a6a..d3a4cb396e 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -40,4 +40,4 @@ virtio-gpu.o-libs += $(VIRGL_LIBS)
 virtio-gpu-3d.o-cflags := $(VIRGL_CFLAGS)
 virtio-gpu-3d.o-libs += $(VIRGL_LIBS)
 obj-$(CONFIG_DPCD) += dpcd.o
-obj-$(CONFIG_XLNX_ZYNQMP) += xlnx_dp.o
+obj-$(CONFIG_XLNX_ZYNQMP_ARM) += xlnx_dp.o
diff --git a/hw/dma/Makefile.objs b/hw/dma/Makefile.objs
index 0b3a009b87..c2afecbf73 100644
--- a/hw/dma/Makefile.objs
+++ b/hw/dma/Makefile.objs
@@ -9,6 +9,7 @@ common-obj-$(CONFIG_ZYNQ_DEVCFG) += xlnx-zynq-devcfg.o
 common-obj-$(CONFIG_ETRAXFS) += etraxfs_dma.o
 common-obj-$(CONFIG_STP2000) += sparc32_dma.o
 obj-$(CONFIG_XLNX_ZYNQMP) += xlnx_dpdma.o
+obj-$(CONFIG_XLNX_ZYNQMP_ARM) += xlnx_dpdma.o

 obj-$(CONFIG_OMAP) += omap_dma.o soc_dma.o
 obj-$(CONFIG_PXA2XX) += pxa2xx_dma.o
--
2.14.1

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

[Qemu-devel] [PATCH v5 2/9] xlnx-zynqmp-pmu: Initial commit of the ZynqMP PMU

[Alistair Francis]

The Xilinx ZynqMP SoC has two main processing systems in it. The ARM
processing system (which is already modeled in QEMU) and the MicroBlaze
Power Management Unit (PMU). This is the inital work for adding support
for the PMU.

The PMU susbsystem runs along side the ARM system on hardware, but due
to architecture limitations in QEMU the two instances are seperate for
the time being.

Let's follow the same setup we do with the ARM system, where there is an
SoC device and a ZCU102 board. Although the PMU is less board specific
we are still going to follow the same split as maybe in future we can
connect the PMU device to the ARM ZCU102 board. As the machine will be
fairly small let's keep them both together in one file.

Signed-off-by: Alistair Francis 
Reviewed-by: Edgar E. Iglesias 
---

V4:
 - Rename to remove ZCU102 name

 hw/microblaze/Makefile.objs |  1 +
 hw/microblaze/xlnx-zynqmp-pmu.c | 83 +
 2 files changed, 84 insertions(+)
 create mode 100644 hw/microblaze/xlnx-zynqmp-pmu.c

diff --git a/hw/microblaze/Makefile.objs b/hw/microblaze/Makefile.objs
index b2517d87fe..ae9fd40de7 100644
--- a/hw/microblaze/Makefile.objs
+++ b/hw/microblaze/Makefile.objs
@@ -1,3 +1,4 @@
 obj-y += petalogix_s3adsp1800_mmu.o
 obj-y += petalogix_ml605_mmu.o
+obj-y += xlnx-zynqmp-pmu.o
 obj-y += boot.o
diff --git a/hw/microblaze/xlnx-zynqmp-pmu.c b/hw/microblaze/xlnx-zynqmp-pmu.c
new file mode 100644
index 00..ac0f78928a
--- /dev/null
+++ b/hw/microblaze/xlnx-zynqmp-pmu.c
@@ -0,0 +1,83 @@
+/*
+ * Xilinx Zynq MPSoC PMU (Power Management Unit) emulation
+ *
+ * Copyright (C) 2017 Xilinx Inc
+ * Written by Alistair Francis 
+ *
+ * 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.
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "qemu-common.h"
+#include "hw/boards.h"
+#include "cpu.h"
+
+/* Define the PMU device */
+
+#define TYPE_XLNX_ZYNQMP_PMU_SOC "xlnx,zynqmp-pmu-soc"
+#define XLNX_ZYNQMP_PMU_SOC(obj) OBJECT_CHECK(XlnxZynqMPPMUSoCState, (obj), \
+  TYPE_XLNX_ZYNQMP_PMU_SOC)
+
+typedef struct XlnxZynqMPPMUSoCState {
+/*< private >*/
+DeviceState parent_obj;
+
+/*< public >*/
+}  XlnxZynqMPPMUSoCState;
+
+static void xlnx_zynqmp_pmu_soc_init(Object *obj)
+{
+
+}
+
+static void xlnx_zynqmp_pmu_soc_realize(DeviceState *dev, Error **errp)
+{
+
+}
+
+static void xlnx_zynqmp_pmu_soc_class_init(ObjectClass *oc, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(oc);
+
+dc->realize = xlnx_zynqmp_pmu_soc_realize;
+}
+
+static const TypeInfo xlnx_zynqmp_pmu_soc_type_info = {
+.name = TYPE_XLNX_ZYNQMP_PMU_SOC,
+.parent = TYPE_DEVICE,
+.instance_size = sizeof(XlnxZynqMPPMUSoCState),
+.instance_init = xlnx_zynqmp_pmu_soc_init,
+.class_init = xlnx_zynqmp_pmu_soc_class_init,
+};
+
+static void xlnx_zynqmp_pmu_soc_register_types(void)
+{
+type_register_static(_zynqmp_pmu_soc_type_info);
+}
+
+type_init(xlnx_zynqmp_pmu_soc_register_types)
+
+/* Define the PMU Machine */
+
+static void xlnx_zynqmp_pmu_init(MachineState *machine)
+{
+
+}
+
+static void xlnx_zynqmp_pmu_machine_init(MachineClass *mc)
+{
+mc->desc = "Xilinx ZynqMP PMU machine";
+mc->init = xlnx_zynqmp_pmu_init;
+}
+
+DEFINE_MACHINE("xlnx-zynqmp-pmu", xlnx_zynqmp_pmu_machine_init)
+
--
2.14.1

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

[Qemu-devel] [PATCH v5 1/9] microblaze: boot.c: Don't try to find NULL pointer

[Alistair Francis]

Previously if no device tree was passed to microblaze_load_kernel() then
qemu_find_file() would try to find a NULL pointer. To avoid this put a
check around qemu_find_file().

Signed-off-by: Alistair Francis 
Reported-by: Peter Maydell 
---

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

diff --git a/hw/microblaze/boot.c b/hw/microblaze/boot.c
index 457a08a2fe..35bfeda7aa 100644
--- a/hw/microblaze/boot.c
+++ b/hw/microblaze/boot.c
@@ -124,7 +124,7 @@ void microblaze_load_kernel(MicroBlazeCPU *cpu, hwaddr 
ddr_base,
 kernel_cmdline = qemu_opt_get(machine_opts, "append");
 dtb_arg = qemu_opt_get(machine_opts, "dtb");
 /* default to pcbios dtb as passed by machine_init */
-if (!dtb_arg) {
+if (!dtb_arg && dtb_filename) {
 filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, dtb_filename);
 }

--
2.14.1

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

[Qemu-devel] [PATCH v5 0/9] Add the ZynqMP PMU and IPI

[Alistair Francis]

This series adds the ZynqMP Power Management Unit (PMU) machine with basic
functionality.

The machine only has the
 - CPU
 - Memory
 - Interrupt controller
 - IPI device

connected, but that is enough to run some of the ROM and firmware
code on the machine

The series also adds the IPI device and connects it to the ZynqMP ARM
side and the ZynqMP PMU. These IPI devices don't connect between the ARM
and MicroBlaze instances though.

V5:
 - Fix clang makecheck error
 - Rebase on master
V4:
 - Rename the ZCU102 machine to just ZynqMP
 - Rename the PMC SoC to "xlnx,zynqmp-pmu-soc"
 - Move the IPI device to the machine instead of the SoC
V3:
 - Add the interrupt controller
 - Replace some of the error_fatals with errp
 - Fix the PMU CPU name



Alistair Francis (9):
  microblaze: boot.c: Don't try to find NULL pointer
  xlnx-zynqmp-pmu: Initial commit of the ZynqMP PMU
  xlnx-zynqmp-pmu: Add the CPU and memory
  aarch64-softmmu.mak: Use an ARM specific config
  xlnx-pmu-iomod-intc: Add the PMU Interrupt controller
  xlnx-zynqmp-pmu: Connect the PMU interrupt controller
  xlnx-zynqmp-ipi: Initial version of the Xilinx IPI device
  xlnx-zynqmp-pmu: Connect the IPI device to the PMU
  xlnx-zynqmp: Connect the IPI device to the ZynqMP SoC

 default-configs/aarch64-softmmu.mak|   1 +
 default-configs/microblaze-softmmu.mak |   1 +
 hw/arm/Makefile.objs   |   2 +-
 hw/arm/xlnx-zynqmp.c   |  14 +
 hw/display/Makefile.objs   |   2 +-
 hw/dma/Makefile.objs   |   1 +
 hw/intc/Makefile.objs  |   2 +
 hw/intc/xlnx-pmu-iomod-intc.c  | 554 +
 hw/intc/xlnx-zynqmp-ipi.c  | 377 ++
 hw/microblaze/Makefile.objs|   1 +
 hw/microblaze/boot.c   |   2 +-
 hw/microblaze/xlnx-zynqmp-pmu.c| 204 
 include/hw/arm/xlnx-zynqmp.h   |   2 +
 include/hw/intc/xlnx-pmu-iomod-intc.h  |  58 
 include/hw/intc/xlnx-zynqmp-ipi.h  |  57 
 15 files changed, 1275 insertions(+), 3 deletions(-)
 create mode 100644 hw/intc/xlnx-pmu-iomod-intc.c
 create mode 100644 hw/intc/xlnx-zynqmp-ipi.c
 create mode 100644 hw/microblaze/xlnx-zynqmp-pmu.c
 create mode 100644 include/hw/intc/xlnx-pmu-iomod-intc.h
 create mode 100644 include/hw/intc/xlnx-zynqmp-ipi.h

--
2.14.1

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

Re: [Qemu-devel] [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps

[Alexey Kardashevskiy]

On 17/01/18 09:34, David Gibson wrote:
> On Tue, Jan 16, 2018 at 03:46:20PM +0100, Andrea Bolognani wrote:
>> On Wed, 2018-01-17 at 00:54 +1100, David Gibson wrote:
 Correct me if I'm wrong, but it seems to me like there's no way
 to figure out through QMP whether these new machine options can be
 used for a given QEMU binary.
>>>
>>> Uh, I don't think so.  These are machine options like any other (just
>>> constructed a bit differently).  So they'll appear in qemu -machine
>>> pseries,? and I believe that info can also be retrieved with QMP.
>>
>> Yes, they will indeed show up in the output of -machine pseries,?
>> but there's AFAICT no way to retrieve them via QMP.
> 
> Really!?  I thought introspecting object properties was QMP's bread
> and butter.


On a guest started with '-S':
{"execute": "qom-list", "arguments": {"path": "/machine"}}

returns:
{   'return': [   {'name': 'graphics', 'type': 'bool'},
  {'name': 'phandle-start', 'type': 'int'},
  {'name': 'dump-guest-core', 'type': 'bool'},
  {'name': 'kernel-irqchip', 'type': 'OnOffSplit'},
  {'name': 'accel', 'type': 'string'},
  {'name': 'append', 'type': 'string'},
  {'name': 'dumpdtb', 'type': 'string'},
  {'name': 'igd-passthru', 'type': 'bool'},
  {'name': 'dt-compatible', 'type': 'string'},
  {'name': 'kernel', 'type': 'string'},
  {'name': 'usb', 'type': 'bool'},
  {'name': 'suppress-vmdesc', 'type': 'bool'},
  {'name': 'dtb', 'type': 'string'},
  {'name': 'firmware', 'type': 'string'},
  {'name': 'mem-merge', 'type': 'bool'},
  {'name': 'initrd', 'type': 'string'},
  {'name': 'enforce-config-section', 'type': 'bool'},
  {'name': 'kvm-shadow-mem', 'type': 'int'},
  {'name': 'cap-dfp', 'type': 'bool'},
  {'name': 'cap-htm', 'type': 'bool'},
  {'name': 'cap-vsx', 'type': 'bool'},
  {'name': 'vfio-no-msix-emulation', 'type': 'bool'},
  {'name': 'kvm-type', 'type': 'string'},
  {'name': 'max-cpu-compat', 'type': 'string'},
  {   'name': 'dr-connector[268435480]',
  'type': 'child'},
  {'name': 'peripheral', 'type': 'child'},
  {   'name': 'dr-connector[268435472]',
  'type': 'child'},
  {'name': 'modern-hotplug-events', 'type': 'bool'},
  {   'name': 'dr-connector[268435464]',
  'type': 'child'},
  {   'name': 'dr-connector[268435456]',
  'type': 'child'},
  {'name': 'peripheral-anon', 'type': 'child'},
  {'name': 'ics', 'type': 'child'},
  {'name': 'vsmt', 'type': 'uint32'},
  {'name': 'type', 'type': 'string'},
  {'name': 'rtc-time', 'type': 'struct tm'},
  {'name': 'unattached', 'type': 'child'},
  {'name': 'rtc', 'type': 'child'},
  {'name': 'resize-hpt', 'type': 'string'}]}


but still requires a running qemu, yes.

> 
>> And libvirt
>> can't afford to spawn a QEMU process for each machine type
>> implemented by each QEMU binary installed on the system just to
>> figure out what properties they support; in fact, we've been
>> pushing away from that approach - which was used initially - for
>> years and we're now at the point where we only fall back to it
>> for positively ancient QEMU versions. So the information needs
>> to be available through QMP for libvirt to consume it.
> 
> Right, I'm not arguing with that.  It's just that I thought that
> standard QOM properties on QOM objects (the machine in this case) met
> the criteria.
> 


-- 
Alexey



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 31/32] qcow2: Allow configuring the L2 slice size

[Eric Blake]

On 12/15/2017 06:53 AM, Alberto Garcia wrote:
> Now that the code is ready to handle L2 slices we can finally add an
> option to allow configuring their size.
> 
> An L2 slice is the portion of an L2 table that is read by the qcow2
> cache. Until now the cache was always reading full L2 tables, and
> since the L2 table size is equal to the cluster size this was not very
> efficient with large clusters. Here's a more detailed explanation of
> why it makes sense to have smaller cache entries in order to load L2
> data:
> 
>https://lists.gnu.org/archive/html/qemu-block/2017-09/msg00635.html
> 
> This patch introduces a new command-line option to the qcow2 driver
> named l2-cache-entry-size (cf. l2-cache-size). The cache entry size
> has the same restrictions as the cluster size: it must be a power of
> two and it has the same range of allowed values, with the additional
> requirement that it must not be larger than the cluster size.
> 
> The L2 cache entry size (L2 slice size) remains equal to the cluster
> size for now by default, so this feature must be explicitly enabled.
> Although my tests show that 4KB slices consistently improve
> performance and give the best results, let's wait and make more tests
> with different cluster sizes before deciding on an optimal default.
> 
> Signed-off-by: Alberto Garcia 
> ---
>  block/qcow2-cache.c | 10 --
>  block/qcow2.c   | 33 +++--
>  block/qcow2.h   |  4 +++-
>  3 files changed, 38 insertions(+), 9 deletions(-)

Is there a QMP counterpart to the command-line option?  I suspect
Kevin's work on making a QMP command for image creation will also be
impacted.

I haven't reviewed the patch closely, yet.

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 26/32] qcow2: Update qcow2_truncate() to support L2 slices

[Eric Blake]

On 12/15/2017 06:53 AM, Alberto Garcia wrote:
> The qcow2_truncate() code is mostly independent from whether
> we're using L2 slices or full L2 tables, but in full and
> falloc preallocation modes new L2 tables are allocated using
> qcow2_alloc_cluster_link_l2().  Therefore the code needs to be
> modified to ensure that all nb_clusters that are processed in each
> call can be allocated with just one L2 slice.
> 
> Signed-off-by: Alberto Garcia 
> ---
>  block/qcow2.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v6 20/21] sdhci: implement UHS-I voltage switch

[Alistair Francis]

On Thu, Jan 11, 2018 at 12:56 PM, Philippe Mathieu-Daudé
 wrote:
> [based on a patch from Alistair Francis 
>  from qemu/xilinx tag xilinx-v2015.2]
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  include/hw/sd/sd.h| 16 
>  include/hw/sd/sdhci.h |  1 +
>  hw/sd/core.c  | 13 +
>  hw/sd/sd.c| 13 +
>  hw/sd/sdhci.c | 12 +++-
>  hw/sd/trace-events|  1 +
>  6 files changed, 55 insertions(+), 1 deletion(-)
>
> diff --git a/include/hw/sd/sd.h b/include/hw/sd/sd.h
> index 96caefe373..f086679493 100644
> --- a/include/hw/sd/sd.h
> +++ b/include/hw/sd/sd.h
> @@ -55,6 +55,20 @@
>  #define AKE_SEQ_ERROR  (1 << 3)
>  #define OCR_CCS_BITN30
>
> +typedef enum {
> +SD_VOLTAGE_0_4V = 400,  /* currently not supported */
> +SD_VOLTAGE_1_8V = 1800,
> +SD_VOLTAGE_3_0V = 3000,
> +SD_VOLTAGE_3_3V = 3300,
> +} sd_voltage_mv_t;
> +
> +typedef enum  {
> +UHS_NOT_SUPPORTED   = 0,
> +UHS_I   = 1,
> +UHS_II  = 2,/* currently not supported */
> +UHS_III = 3,/* currently not supported */
> +} sd_uhs_mode_t;
> +
>  typedef enum {
>  sd_none = -1,
>  sd_bc = 0, /* broadcast -- no response */
> @@ -88,6 +102,7 @@ typedef struct {
>  void (*write_data)(SDState *sd, uint8_t value);
>  uint8_t (*read_data)(SDState *sd);
>  bool (*data_ready)(SDState *sd);
> +void (*set_voltage)(SDState *sd, uint16_t millivolts);
>  void (*enable)(SDState *sd, bool enable);
>  bool (*get_inserted)(SDState *sd);
>  bool (*get_readonly)(SDState *sd);
> @@ -134,6 +149,7 @@ void sd_enable(SDState *sd, bool enable);
>  /* Functions to be used by qdevified callers (working via
>   * an SDBus rather than directly with SDState)
>   */
> +void sdbus_set_voltage(SDBus *sdbus, uint16_t millivolts);
>  int sdbus_do_command(SDBus *sd, SDRequest *req, uint8_t *response);
>  void sdbus_write_data(SDBus *sd, uint8_t value);
>  uint8_t sdbus_read_data(SDBus *sd);
> diff --git a/include/hw/sd/sdhci.h b/include/hw/sd/sdhci.h
> index e66d6d6abd..2803e78e7f 100644
> --- a/include/hw/sd/sdhci.h
> +++ b/include/hw/sd/sdhci.h
> @@ -107,6 +107,7 @@ typedef struct SDHCIState {
>  bool bus64;
>  /* v3 */
>  uint8_t slot_type, sdr, strength;
> +uint8_t uhs_mode;
>  } cap;
>  } SDHCIState;
>
> diff --git a/hw/sd/core.c b/hw/sd/core.c
> index 498284f109..6d198ea775 100644
> --- a/hw/sd/core.c
> +++ b/hw/sd/core.c
> @@ -41,6 +41,19 @@ static SDState *get_card(SDBus *sdbus)
>  return SD_CARD(kid->child);
>  }
>
> +void sdbus_set_voltage(SDBus *sdbus, uint16_t millivolts)
> +{
> +SDState *card = get_card(sdbus);
> +
> +trace_sdbus_set_voltage(sdbus_name(sdbus), millivolts);
> +if (card) {
> +SDCardClass *sc = SD_CARD_GET_CLASS(card);
> +
> +assert(sc->set_voltage);
> +sc->set_voltage(card, millivolts);
> +}
> +}
> +
>  int sdbus_do_command(SDBus *sdbus, SDRequest *req, uint8_t *response)
>  {
>  SDState *card = get_card(sdbus);
> diff --git a/hw/sd/sd.c b/hw/sd/sd.c
> index 35347a5bbc..609b2da14f 100644
> --- a/hw/sd/sd.c
> +++ b/hw/sd/sd.c
> @@ -128,6 +128,18 @@ struct SDState {
>  bool enable;
>  };
>
> +static void sd_set_voltage(SDState *sd, uint16_t millivolts)
> +{
> +switch (millivolts) {
> +case 3001 ... 3600: /* SD_VOLTAGE_3_3V */
> +case 2001 ... 3000: /* SD_VOLTAGE_3_0V */
> +break;
> +default:
> +qemu_log_mask(LOG_GUEST_ERROR, "SD card voltage not supported: 
> %.3fV",
> +  millivolts / 1000.f);
> +}
> +}
> +
>  static void sd_set_mode(SDState *sd)
>  {
>  switch (sd->state) {
> @@ -1925,6 +1937,7 @@ static void sd_class_init(ObjectClass *klass, void 
> *data)
>  dc->reset = sd_reset;
>  dc->bus_type = TYPE_SD_BUS;
>
> +sc->set_voltage = sd_set_voltage;
>  sc->do_command = sd_do_command;
>  sc->write_data = sd_write_data;
>  sc->read_data = sd_read_data;
> diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
> index 834b835f3e..a4727b4577 100644
> --- a/hw/sd/sdhci.c
> +++ b/hw/sd/sdhci.c
> @@ -1159,7 +1159,16 @@ sdhci_write(void *opaque, hwaddr offset, uint64_t val, 
> unsigned size)
>  sdhci_update_irq(s);
>  break;
>  case SDHC_ACMD12ERRSTS:
> -MASKED_WRITE(s->acmd12errsts, mask, value);
> +MASKED_WRITE(s->acmd12errsts, mask, value & UINT16_MAX);
> +if (s->cap.uhs_mode >= UHS_I) {
> +MASKED_WRITE(s->hostctl2, mask >> 16, value >> 16);
> +
> +if (FIELD_EX32(s->hostctl2, SDHC_HOSTCTL2, V18_ENA)) {
> +sdbus_set_voltage(>sdbus, SD_VOLTAGE_1_8V);
> +} else {
> +sdbus_set_voltage(>sdbus, SD_VOLTAGE_3_3V);
> +}
> +}
>  break;
>
>  

Re: [Qemu-devel] [PATCH v6 11/21] hw/arm/xilinx_zynq: implement SDHCI Spec v2

[Alistair Francis]

On Thu, Jan 11, 2018 at 12:56 PM, Philippe Mathieu-Daudé
 wrote:
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  hw/arm/xilinx_zynq.c | 64 
> 
>  1 file changed, 40 insertions(+), 24 deletions(-)
>
> diff --git a/hw/arm/xilinx_zynq.c b/hw/arm/xilinx_zynq.c
> index 1836a4ed45..9a106db7b7 100644
> --- a/hw/arm/xilinx_zynq.c
> +++ b/hw/arm/xilinx_zynq.c
> @@ -165,10 +165,8 @@ static void zynq_init(MachineState *machine)
>  MemoryRegion *address_space_mem = get_system_memory();
>  MemoryRegion *ext_ram = g_new(MemoryRegion, 1);
>  MemoryRegion *ocm_ram = g_new(MemoryRegion, 1);
> -DeviceState *dev, *carddev;
> +DeviceState *dev;
>  SysBusDevice *busdev;
> -DriveInfo *di;
> -BlockBackend *blk;
>  qemu_irq pic[64];
>  int n;
>
> @@ -247,27 +245,45 @@ static void zynq_init(MachineState *machine)
>  gem_init(_table[0], 0xE000B000, pic[54-IRQ_OFFSET]);
>  gem_init(_table[1], 0xE000C000, pic[77-IRQ_OFFSET]);
>
> -dev = qdev_create(NULL, TYPE_SYSBUS_SDHCI);
> -qdev_init_nofail(dev);
> -sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, 0xE010);
> -sysbus_connect_irq(SYS_BUS_DEVICE(dev), 0, pic[56-IRQ_OFFSET]);
> -
> -di = drive_get_next(IF_SD);
> -blk = di ? blk_by_legacy_dinfo(di) : NULL;
> -carddev = qdev_create(qdev_get_child_bus(dev, "sd-bus"), TYPE_SD_CARD);
> -qdev_prop_set_drive(carddev, "drive", blk, _fatal);
> -object_property_set_bool(OBJECT(carddev), true, "realized", 
> _fatal);
> -
> -dev = qdev_create(NULL, TYPE_SYSBUS_SDHCI);
> -qdev_init_nofail(dev);
> -sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, 0xE0101000);
> -sysbus_connect_irq(SYS_BUS_DEVICE(dev), 0, pic[79-IRQ_OFFSET]);
> -
> -di = drive_get_next(IF_SD);
> -blk = di ? blk_by_legacy_dinfo(di) : NULL;
> -carddev = qdev_create(qdev_get_child_bus(dev, "sd-bus"), TYPE_SD_CARD);
> -qdev_prop_set_drive(carddev, "drive", blk, _fatal);
> -object_property_set_bool(OBJECT(carddev), true, "realized", 
> _fatal);
> +for (n = 0; n < 2; n++) {
> +int hci_irq = n ? 79 : 56;
> +hwaddr hci_addr = n ? 0xE0101000 : 0xE010;
> +DriveInfo *di;
> +BlockBackend *blk;
> +DeviceState *carddev;
> +
> +/* Compatible with:
> + * - SD Host Controller Specification Version 2.0 Part A2
> + * - SDIO Specification Version 2.0
> + * - MMC Specification Version 3.31
> + *
> + * - SDMA (single operation DMA)
> + * - ADMA1 (4 KB boundary limited DMA)
> + * - ADMA2
> + *
> + * - up to seven functions in SD1, SD4, but does not support SPI mode
> + * - SD high-speed (SDHS) card
> + * - SD High Capacity (SDHC) card
> + *
> + * - Low-speed, 1 KHz to 400 KHz
> + * - Full-speed, 1 MHz to 50 MHz (25 MB/sec)
> + */
> +dev = qdev_create(NULL, TYPE_SYSBUS_SDHCI);
> +qdev_prop_set_uint8(dev, "sd-spec-version", 2);
> +qdev_prop_set_bit(dev, "adma1", true);
> +qdev_prop_set_bit(dev, "high-speed", true);
> +qdev_prop_set_uint16(dev, "max-block-length", 1024);
> +qdev_init_nofail(dev);
> +sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, hci_addr);
> +sysbus_connect_irq(SYS_BUS_DEVICE(dev), 0, pic[hci_irq - 
> IRQ_OFFSET]);
> +
> +di = drive_get_next(IF_SD);
> +blk = di ? blk_by_legacy_dinfo(di) : NULL;
> +carddev = qdev_create(qdev_get_child_bus(dev, "sd-bus"), 
> TYPE_SD_CARD);
> +qdev_prop_set_drive(carddev, "drive", blk, _fatal);
> +object_property_set_bool(OBJECT(carddev), true, "realized",
> + _fatal);
> +}
>
>  dev = qdev_create(NULL, TYPE_ZYNQ_XADC);
>  qdev_init_nofail(dev);
> --
> 2.15.1
>
>

Re: [Qemu-devel] [PATCH v2 25/32] qcow2: Update expand_zero_clusters_in_l1() to support L2 slices

[Eric Blake]

On 12/15/2017 06:53 AM, Alberto Garcia wrote:
> expand_zero_clusters_in_l1() expands zero clusters as a necessary step
> to downgrade qcow2 images to a version that doesn't support metadata
> zero clusters. This function takes an L1 table (which may or may not
> be active) and iterates over all its L2 tables looking for zero
> clusters.
> 
> Since we'll be loading L2 slices instead of full tables we need to add
> an extra loop that iterates over all slices of each L2 table, and we
> should also use the slice size when allocating the buffer used when
> the L1 table is not active.
> 
> As a consequence of the new loop the refcount data also needs to be
> loaded before the L2 data, but this is a trivial change with no side
> effects.
> 
> This function doesn't need any additional changes so apart from that
> this patch simply updates the variable name from l2_table to l2_slice.
> 
> Signed-off-by: Alberto Garcia 
> ---
>  block/qcow2-cluster.c | 207 
> +++---
>  1 file changed, 110 insertions(+), 97 deletions(-)
> 

Even hairier diff than the previous patch. Would it be feasible to split
this into two or three parts - one that just adds an additional {}
scoping (but no variable renames or loop condition changes) (where git
diff -b can easily check the change in isolation); the other that
renames the variable and switches the new scope to be a loop over the
smaller slice limits (possibly as two patches, if the change in refcount
vs. L2 data load ordering deserves separation from the slice conversion)?

> -} else {
> -/* load inactive L2 tables from disk */
> -ret = bdrv_read(bs->file, l2_offset / BDRV_SECTOR_SIZE,
> -(void *)l2_table, s->cluster_sectors);

Pre-existing...

> -}
> -if (ret < 0) {
> -goto fail;
> -}
> -
>  ret = qcow2_get_refcount(bs, l2_offset >> s->cluster_bits,
>   _refcount);
>  if (ret < 0) {
>  goto fail;
>  }
>  
> -for (j = 0; j < s->l2_size; j++) {
> -uint64_t l2_entry = be64_to_cpu(l2_table[j]);
> -int64_t offset = l2_entry & L2E_OFFSET_MASK;
> -QCow2ClusterType cluster_type = qcow2_get_cluster_type(l2_entry);
> -
> -if (cluster_type != QCOW2_CLUSTER_ZERO_PLAIN &&
> -cluster_type != QCOW2_CLUSTER_ZERO_ALLOC) {
> -continue;
> +for (slice = 0; slice < n_slices; slice++) {
> +uint64_t slice_offset = l2_offset + slice * slice_size;
> +if (is_active_l1) {
> +/* get active L2 tables from cache */
> +ret = qcow2_cache_get(bs, s->l2_table_cache, slice_offset,
> +  (void **)_slice);
> +} else {
> +/* load inactive L2 tables from disk */
> +ret = bdrv_read(bs->file, slice_offset >> BDRV_SECTOR_BITS,
> +(void *)l2_slice,
> +slice_size >> BDRV_SECTOR_BITS);

...but is it time to convert this to use bdrv_pread[v](), for one less
use of the older sector-based interfaces?

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 24/32] qcow2: Update qcow2_update_snapshot_refcount() to support L2 slices

[Eric Blake]

On 12/15/2017 06:53 AM, Alberto Garcia wrote:
> qcow2_update_snapshot_refcount() increases the refcount of all
> clusters of a given snapshot. In order to do that it needs to load all
> its L2 tables and iterate over their entries. Since we'll be loading
> L2 slices instead of full tables we need to add an extra loop that
> iterates over all slices of each L2 table.
> 
> This function doesn't need any additional changes so apart from that
> this patch simply updates the variable name from l2_table to l2_slice.
> 
> Signed-off-by: Alberto Garcia 
> ---
>  block/qcow2-refcount.c | 150 
> ++---
>  1 file changed, 80 insertions(+), 70 deletions(-)
> 

> -l2_table = NULL;
> +l2_slice = NULL;
>  l1_table = NULL;
>  l1_size2 = l1_size * sizeof(uint64_t);
>  
> +slice_size = s->l2_slice_size * sizeof(uint64_t);

Again, better naming on s->l2_slice_size in an earlier patch may make
this more readable, at a cost of slight rebase churn.

The diff looks hideous, but that's thanks to indentation changes.

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 23/32] qcow2: Update zero_single_l2() to support L2 slices

[Eric Blake]

On 12/15/2017 06:53 AM, Alberto Garcia wrote:
> zero_single_l2() limits the number of clusters to be zeroed to the
> amount that fits inside an L2 table. Since we'll be loading L2 slices
> instead of full tables we need to update that limit.
> 
> Apart from that, this function doesn't need any additional changes, so
> this patch simply updates the variable name from l2_table to l2_slice.
> 
> Signed-off-by: Alberto Garcia 
> ---
>  block/qcow2-cluster.c | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 22/32] qcow2: Update discard_single_l2() to support L2 slices

[Eric Blake]

On 12/15/2017 06:53 AM, Alberto Garcia wrote:
> discard_single_l2() limits the number of clusters to be discarded to
> the amount that fits inside an L2 table. Since we'll be loading L2
> slices instead of full tables we need to update that limit.
> 
> Apart from that, this function doesn't need any additional changes, so
> this patch simply updates the variable name from l2_table to l2_slice.
> 
> Signed-off-by: Alberto Garcia 
> ---
>  block/qcow2-cluster.c | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 21/32] qcow2: Update handle_alloc() to support L2 slices

[Eric Blake]

On 12/15/2017 06:53 AM, Alberto Garcia wrote:
> handle_alloc() loads an L2 table and limits the number of checked
> clusters to the amount that fits inside that table. Since we'll be
> loading L2 slices instead of full tables we need to update that limit.
> 
> Apart from that, this function doesn't need any additional changes, so
> this patch simply updates the variable name from l2_table to l2_slice.
> 
> Signed-off-by: Alberto Garcia 
> ---
>  block/qcow2-cluster.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 20/32] qcow2: Update handle_copied() to support L2 slices

[Eric Blake]

On 12/15/2017 06:53 AM, Alberto Garcia wrote:
> handle_copied() loads an L2 table and limits the number of checked
> clusters to the amount that fits inside that table. Since we'll be
> loading L2 slices instead of full tables we need to update that limit.
> 
> Apart from that, this function doesn't need any additional changes, so
> this patch simply updates the variable name from l2_table to l2_slice.
> 
> Signed-off-by: Alberto Garcia 
> ---
>  block/qcow2-cluster.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps

[David Gibson]

On Tue, Jan 16, 2018 at 03:46:20PM +0100, Andrea Bolognani wrote:
> On Wed, 2018-01-17 at 00:54 +1100, David Gibson wrote:
> > > Correct me if I'm wrong, but it seems to me like there's no way
> > > to figure out through QMP whether these new machine options can be
> > > used for a given QEMU binary.
> > 
> > Uh, I don't think so.  These are machine options like any other (just
> > constructed a bit differently).  So they'll appear in qemu -machine
> > pseries,? and I believe that info can also be retrieved with QMP.
> 
> Yes, they will indeed show up in the output of -machine pseries,?
> but there's AFAICT no way to retrieve them via QMP.

Really!?  I thought introspecting object properties was QMP's bread
and butter.

> And libvirt
> can't afford to spawn a QEMU process for each machine type
> implemented by each QEMU binary installed on the system just to
> figure out what properties they support; in fact, we've been
> pushing away from that approach - which was used initially - for
> years and we're now at the point where we only fall back to it
> for positively ancient QEMU versions. So the information needs
> to be available through QMP for libvirt to consume it.

Right, I'm not arguing with that.  It's just that I thought that
standard QOM properties on QOM objects (the machine in this case) met
the criteria.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH v2 19/32] qcow2: Update qcow2_alloc_cluster_link_l2() to support L2 slices

[Eric Blake]

On 12/15/2017 06:53 AM, Alberto Garcia wrote:
> There's a loop in this function that iterates over the L2 entries in a
> table, so now we need to assert that it remains within the limits of
> an L2 slice.
> 
> Apart from that, this function doesn't need any additional changes, so
> this patch simply updates the variable name from l2_table to l2_slice.
> 
> Signed-off-by: Alberto Garcia 
> ---
>  block/qcow2-cluster.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH x86-next v2] target-i386: add PCID flag to Westmere, Sandy Bridge and Ivy Bridge

[Kashyap Chamarthy]

On Tue, Jan 16, 2018 at 05:43:44PM +, Daniel P. Berrange wrote:
> On Tue, Jan 16, 2018 at 03:08:15PM -0200, Eduardo Habkost wrote:
> > [CCing Daniel]

[...]

> > I still don't understand why OpenStack doesn't let users add or
> > modify elements on the domain XML.  This isn't the first time I
> > see this preventing users from fixing problems or optimizing
> > their systems.
> > 
> > Is there a summary of the reasons behind this limitation
> > somewhere?
> 
> Exposing ability to control every aspect of Libvirt XML is a non-goal of
> Nova. A great many of the features require different modelling and/or
> explicit handling by Nova to work well in the context of OpenStack's
> architecture. The domain XML is automatically generated on the fly by
> Nova based on the info it gets from various inputs, so there's nothing
> that can be editted directly to add custom elements. The only way that
> would allow modification is for Nova to send the XML it generates to
> an external plugin script and read back modified XML. Historically Nova
> did have alot of plugin points that allowed arbitrary admin hacks like
> this, but they end up being a support burden in themselves, as they
> end up being black boxes which change Nova behaviour in unpredictable
> ways. Thus Nova has actually worked to remove as many of the plugins
> as possible.
> 
> In this case there is a clear benefit to being able to add extra CPU
> features, over the base named model. It is easy for Nova to wire this
> up and it should do so as a priority.

Agreed, it has long been pending in Nova; I also recall you've
identified other use cases for it (e.g. ability to mention 1G huge pages
with the CPU flag "pdpe1gb").  So I began a quick WIP Nova change to
allow it to specify CPU feature flags.  I haven't worked out all the
details yet, and still addressing the quick comment you (DanPB) made on
IRC.

https://review.openstack.org/#/c/534384 -- [WIP] libvirt: Allow to
specify granular CPU feature flags

PS: Thursday and Friday I'll be a bit sporadic in my availability, but
this change is on top of my TODO list.

-- 
/kashyap

Re: [Qemu-devel] [PULL v1 0/8] Xilinx queue

[Alistair Francis]

On Tue, Jan 16, 2018 at 6:54 AM, Peter Maydell  wrote:
> On 16 January 2018 at 14:49, Edgar E. Iglesias
>  wrote:
>> This didn't show up on my clang testing, do you mind sharing configure line 
>> and clang version you use?
>>
>> @Alistair, it does seem like the call to microblaze_load_kernel is passing 
>> wrong arguments.
>> Can you have a look?
>
> exec '../../configure' '--cc=clang' '--cxx=clang++' '--enable-gtk'
> '--extra-cflags=-fsanitize=undefined  -fno-sanitize=shift-base
> -Werror' "$@"
>
> with clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
> on ubuntu xenial.

Ok, should be fixed in v5, just running though one more test then I'll
send the patches out.

Alistair

>
> thanks
> -- PMM
>

Re: [Qemu-devel] [PATCH v2 18/32] qcow2: Update qcow2_get_cluster_offset() to support L2 slices

[Eric Blake]

On 12/15/2017 06:53 AM, Alberto Garcia wrote:
> qcow2_get_cluster_offset() checks how many contiguous bytes are
> available at a given offset. The returned number of bytes is limited
> by the amount that can be addressed without having to load more than
> one L2 table.
> 
> Since we'll be loading L2 slices instead of full tables this patch
> changes the limit accordingly using the size of the L2 slice for the
> calculations instead of the full table size.
> 
> The l2_table variable is also renamed to l2_slice to reflect this, and
> offset_to_l2_index() is replaced with offset_to_l2_slice_index().
> 
> Signed-off-by: Alberto Garcia 
> ---
>  block/qcow2-cluster.c | 30 +++---
>  1 file changed, 15 insertions(+), 15 deletions(-)
> 

Callers like 'qemu-img map' will potentially have to iterate in more
steps over an entire image; but that's not a severe limitation.  The
block_status() functions already document that as long as drivers make
progress, callers must be prepared for back-to-back calls that return
the same status, so you are not breaking semantics with a shorter
clamping limit.

Maybe some of that is worth mentioning in the commit message.  Either way,

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 17/32] qcow2: Update get_cluster_table() to support L2 slices

[Eric Blake]

On 12/15/2017 06:53 AM, Alberto Garcia wrote:
> This patch updates get_cluster_table() to return L2 slices instead of
> full L2 tables.
> 
> The code itself needs almost no changes, it only needs to call
> offset_to_l2_slice_index() instead of offset_to_l2_index(). This patch
> also renames all the relevant variables and the documentation.
> 
> Signed-off-by: Alberto Garcia 
> ---
>  block/qcow2-cluster.c | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
> index ecb75b6be6..3d43dc2307 100644
> --- a/block/qcow2-cluster.c
> +++ b/block/qcow2-cluster.c
> @@ -660,20 +660,20 @@ fail:
>   * get_cluster_table
>   *
>   * for a given disk offset, load (and allocate if needed)
> - * the l2 table.
> + * the appropiate slice of its l2 table.

s/appropiate/appropriate/

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 16/32] qcow2: Update l2_allocate() to support L2 slices

[Eric Blake]

On 12/15/2017 06:53 AM, Alberto Garcia wrote:
> This patch updates l2_allocate() to support the qcow2 cache returning
> L2 slices instead of full L2 tables.
> 
> The old code simply gets an L2 table from the cache and initializes it
> with zeroes or with the contents of an existing table. With a cache
> that returns slices instead of tables the idea remains the same, but
> the code must now iterate over all the slices that are contained in an
> L2 table.
> 
> Since now we're operating with slices the function can no longer
> return the newly-allocated table, so it's up to the caller to retrieve
> the appropriate L2 slice after calling l2_allocate() (note that with
> this patch the caller is still loading full L2 tables, but we'll deal
> with that in a separate patch).
> 
> Signed-off-by: Alberto Garcia 
> ---
>  block/qcow2-cluster.c | 86 
> +++
>  1 file changed, 52 insertions(+), 34 deletions(-)
> 

> @@ -299,42 +300,50 @@ static int l2_allocate(BlockDriverState *bs, int 
> l1_index, uint64_t **table)
>  
>  /* allocate a new entry in the l2 cache */
>  
> +slice_size = s->l2_slice_size * sizeof(uint64_t);

Would this read any better if the earlier patch named it
s->l2_slice_entries?  (When I see size, I try to think bytes, even
though the earlier patch made l2_slice_size be the number of entries;
worse, you are multiplying it back to a local variable slice_size that
IS in bytes).


> +
> +/* write the l2 slice to the file */
> +BLKDBG_EVENT(bs->file, BLKDBG_L2_ALLOC_WRITE);
>  
> -/* write the l2 table to the file */
> -BLKDBG_EVENT(bs->file, BLKDBG_L2_ALLOC_WRITE);
> +trace_qcow2_l2_allocate_write_l2(bs, l1_index);
> +qcow2_cache_entry_mark_dirty(s->l2_table_cache, l2_slice);
> +ret = qcow2_cache_flush(bs, s->l2_table_cache);

As Anton pointed out, flushing the cache seems like you could do it once
after the loop rather than on each iteration.

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



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH v3 0/4] linux-user: select CPU type according ELF header values

[Laurent Vivier]

This idea has been suggested to me before by Philippe
Mathieu-Daudé, and recently YunQiang Su has proposed a
patch to manage the MIPS r6 case.

Based on this, this series tries to clean-up the original
patch, and introduces the use for m68k architecture and
port the patch from YunQiang Su.

v3: fix code indent problem reported by patchew
remove useless "!= 0"
check for EF_M68K_M68000
add EF_M68K_* flags in elf.h
set 680x0 default CPU to m68040
change "#if ... #endif" structure for ppc
v2: move cpu_model selection to linux-user/*/target_elf.h
provide eflags to cpu_get_model() instead of fd
(and modify other patches accordingly)

Laurent Vivier (2):
  linux-user: Move CPU type name selection to a function
  linux-user,m68k: select CPU according to ELF header values

YunQiang Su (2):
  linux-user: introduce functions to detect CPU type
  linux-user: MIPS set cpu to r6 CPU if binary is R6

 include/elf.h  | 32 +
 linux-user/aarch64/target_elf.h| 14 +
 linux-user/alpha/target_elf.h  | 14 +
 linux-user/arm/target_elf.h| 14 +
 linux-user/cris/target_elf.h   | 14 +
 linux-user/elfload.c   | 35 ++
 linux-user/hppa/target_elf.h   | 14 +
 linux-user/i386/target_elf.h   | 14 +
 linux-user/m68k/target_elf.h   | 20 +
 linux-user/main.c  | 59 +++---
 linux-user/microblaze/target_elf.h | 14 +
 linux-user/mips/target_elf.h   | 17 +++
 linux-user/mips64/target_elf.h | 17 +++
 linux-user/nios2/target_elf.h  | 14 +
 linux-user/openrisc/target_elf.h   | 14 +
 linux-user/ppc/target_elf.h| 18 
 linux-user/qemu.h  |  1 +
 linux-user/s390x/target_elf.h  | 14 +
 linux-user/sh4/target_elf.h| 14 +
 linux-user/sparc/target_elf.h  | 14 +
 linux-user/sparc64/target_elf.h| 14 +
 linux-user/tilegx/target_elf.h | 14 +
 linux-user/unicore32/target_elf.h  | 14 +
 linux-user/x86_64/target_elf.h | 14 +
 24 files changed, 375 insertions(+), 48 deletions(-)
 create mode 100644 linux-user/aarch64/target_elf.h
 create mode 100644 linux-user/alpha/target_elf.h
 create mode 100644 linux-user/arm/target_elf.h
 create mode 100644 linux-user/cris/target_elf.h
 create mode 100644 linux-user/hppa/target_elf.h
 create mode 100644 linux-user/i386/target_elf.h
 create mode 100644 linux-user/m68k/target_elf.h
 create mode 100644 linux-user/microblaze/target_elf.h
 create mode 100644 linux-user/mips/target_elf.h
 create mode 100644 linux-user/mips64/target_elf.h
 create mode 100644 linux-user/nios2/target_elf.h
 create mode 100644 linux-user/openrisc/target_elf.h
 create mode 100644 linux-user/ppc/target_elf.h
 create mode 100644 linux-user/s390x/target_elf.h
 create mode 100644 linux-user/sh4/target_elf.h
 create mode 100644 linux-user/sparc/target_elf.h
 create mode 100644 linux-user/sparc64/target_elf.h
 create mode 100644 linux-user/tilegx/target_elf.h
 create mode 100644 linux-user/unicore32/target_elf.h
 create mode 100644 linux-user/x86_64/target_elf.h

-- 
2.14.3

[Qemu-devel] [PATCH v3 3/4] linux-user, m68k: select CPU according to ELF header values

[Laurent Vivier]

M680x0 doesn't support the same set of instructions
as ColdFire, so we can't use "any" CPU type to execute
m68020 instructions.
We select CPU type ("m68040" or "any" for ColdFire)
according to the ELF header. If we can't, we
use by default the value used until now: "any".

Signed-off-by: Laurent Vivier 
---

Notes:
v3: check for EF_M68K_M68000
add EF_M68K_* flags in elf.h
set 680x0 default CPU to m68040
v2: call cpu_get_model() with the result of get_elf_eflags()

 include/elf.h| 28 
 linux-user/m68k/target_elf.h |  6 ++
 2 files changed, 34 insertions(+)

diff --git a/include/elf.h b/include/elf.h
index e8a515ce3d..ca9a419043 100644
--- a/include/elf.h
+++ b/include/elf.h
@@ -537,6 +537,34 @@ typedef struct {
 #define HWCAP_S390_HIGH_GPRS512
 #define HWCAP_S390_TE   1024
 
+/* M68K specific definitions. */
+/* We use the top 24 bits to encode information about the
+   architecture variant.  */
+#define EF_M68K_CPU320x0081
+#define EF_M68K_M68000   0x0100
+#define EF_M68K_CFV4E0x8000
+#define EF_M68K_FIDO 0x0200
+#define EF_M68K_ARCH_MASK   \
+  (EF_M68K_M68000 | EF_M68K_CPU32 | EF_M68K_CFV4E | EF_M68K_FIDO)
+
+/* We use the bottom 8 bits to encode information about the
+   coldfire variant.  If we use any of these bits, the top 24 bits are
+   either 0 or EF_M68K_CFV4E.  */
+#define EF_M68K_CF_ISA_MASK 0x0F  /* Which ISA */
+#define EF_M68K_CF_ISA_A_NODIV  0x01  /* ISA A except for div */
+#define EF_M68K_CF_ISA_A0x02
+#define EF_M68K_CF_ISA_A_PLUS   0x03
+#define EF_M68K_CF_ISA_B_NOUSP  0x04  /* ISA_B except for USP */
+#define EF_M68K_CF_ISA_B0x05
+#define EF_M68K_CF_ISA_C0x06
+#define EF_M68K_CF_ISA_C_NODIV  0x07  /* ISA C except for div */
+#define EF_M68K_CF_MAC_MASK 0x30
+#define EF_M68K_CF_MAC  0x10  /* MAC */
+#define EF_M68K_CF_EMAC 0x20  /* EMAC */
+#define EF_M68K_CF_EMAC_B   0x30  /* EMAC_B */
+#define EF_M68K_CF_FLOAT0x40  /* Has float insns */
+#define EF_M68K_CF_MASK 0xFF
+
 /*
  * 68k ELF relocation types
  */
diff --git a/linux-user/m68k/target_elf.h b/linux-user/m68k/target_elf.h
index df375ad5d3..998fe0fe2f 100644
--- a/linux-user/m68k/target_elf.h
+++ b/linux-user/m68k/target_elf.h
@@ -9,6 +9,12 @@
 #define M68K_TARGET_ELF_H
 static inline const char *cpu_get_model(uint32_t eflags)
 {
+if (eflags == 0 || (eflags & EF_M68K_M68000)) {
+/* 680x0 */
+return "m68040";
+}
+
+/* Coldfire */
 return "any";
 }
 #endif
-- 
2.14.3

[Qemu-devel] [PATCH v3 4/4] linux-user: MIPS set cpu to r6 CPU if binary is R6

[Laurent Vivier]

From: YunQiang Su 

So here we need to detect the version of binaries and set
cpu_model for it.

[lv: original patch modified to move code into cpu_get_model()]
Signed-off-by: Laurent Vivier 
Reviewed-by: Richard Henderson 
---

Notes:
YunQiang Su, please add your Signed-off-by that was
missing in your original patch.

v3: fix code indent problem reported by patchew
remove useless "!= 0"
v2: call cpu_get_model() with the result of get_elf_eflags()

 include/elf.h  | 4 
 linux-user/mips/target_elf.h   | 3 +++
 linux-user/mips64/target_elf.h | 3 +++
 3 files changed, 10 insertions(+)

diff --git a/include/elf.h b/include/elf.h
index ca9a419043..746b6d393b 100644
--- a/include/elf.h
+++ b/include/elf.h
@@ -40,6 +40,10 @@ typedef int64_t  Elf64_Sxword;
 #define EF_MIPS_ARCH_5 0x4000  /* -mips5 code.  */
 #define EF_MIPS_ARCH_320x5000  /* MIPS32 code.  */
 #define EF_MIPS_ARCH_640x6000  /* MIPS64 code.  */
+#define EF_MIPS_ARCH_32R2   0x7000  /* MIPS32r2 code.  */
+#define EF_MIPS_ARCH_64R2   0x8000  /* MIPS64r2 code.  */
+#define EF_MIPS_ARCH_32R6   0x9000  /* MIPS32r6 code.  */
+#define EF_MIPS_ARCH_64R6   0xa000  /* MIPS64r6 code.  */
 
 /* The ABI of a file. */
 #define EF_MIPS_ABI_O320x1000  /* O32 ABI.  */
diff --git a/linux-user/mips/target_elf.h b/linux-user/mips/target_elf.h
index bed0b43259..14b53d7469 100644
--- a/linux-user/mips/target_elf.h
+++ b/linux-user/mips/target_elf.h
@@ -9,6 +9,9 @@
 #define MIPS_TARGET_ELF_H
 static inline const char *cpu_get_model(uint32_t eflags)
 {
+if (eflags & EF_MIPS_ARCH_32R6) {
+return "mips32r6-generic";
+}
 return "24Kf";
 }
 #endif
diff --git a/linux-user/mips64/target_elf.h b/linux-user/mips64/target_elf.h
index 5b6f4692e0..ae14b38bfa 100644
--- a/linux-user/mips64/target_elf.h
+++ b/linux-user/mips64/target_elf.h
@@ -9,6 +9,9 @@
 #define MIPS64_TARGET_ELF_H
 static inline const char *cpu_get_model(uint32_t eflags)
 {
+if (eflags & EF_MIPS_ARCH_64R6) {
+return "I6400";
+}
 return "5KEf";
 }
 #endif
-- 
2.14.3

[Qemu-devel] [PATCH v3 1/4] linux-user: Move CPU type name selection to a function

[Laurent Vivier]

Instead of a sequence of "#if ... #endif" move the
selection to a function in linux-user/*/target_elf.h

We can't add them in linux-user/*/target_cpu.h
because we will need to include "elf.h" to
use ELF flags with eflags, and including
"elf.h" in "target_cpu.h" introduces some
conflicts in elfload.c

Suggested-by: Richard Henderson 
Signed-off-by: Laurent Vivier 
Reviewed-by: Richard Henderson 
Reviewed-by: Philippe Mathieu-Daudé 
---

Notes:
v3: change "#if ... #endif" structure for ppc
v2: new patch in the series

 linux-user/aarch64/target_elf.h| 14 +
 linux-user/alpha/target_elf.h  | 14 +
 linux-user/arm/target_elf.h| 14 +
 linux-user/cris/target_elf.h   | 14 +
 linux-user/hppa/target_elf.h   | 14 +
 linux-user/i386/target_elf.h   | 14 +
 linux-user/m68k/target_elf.h   | 14 +
 linux-user/main.c  | 41 ++
 linux-user/microblaze/target_elf.h | 14 +
 linux-user/mips/target_elf.h   | 14 +
 linux-user/mips64/target_elf.h | 14 +
 linux-user/nios2/target_elf.h  | 14 +
 linux-user/openrisc/target_elf.h   | 14 +
 linux-user/ppc/target_elf.h| 18 +
 linux-user/s390x/target_elf.h  | 14 +
 linux-user/sh4/target_elf.h| 14 +
 linux-user/sparc/target_elf.h  | 14 +
 linux-user/sparc64/target_elf.h| 14 +
 linux-user/tilegx/target_elf.h | 14 +
 linux-user/unicore32/target_elf.h  | 14 +
 linux-user/x86_64/target_elf.h | 14 +
 21 files changed, 286 insertions(+), 39 deletions(-)
 create mode 100644 linux-user/aarch64/target_elf.h
 create mode 100644 linux-user/alpha/target_elf.h
 create mode 100644 linux-user/arm/target_elf.h
 create mode 100644 linux-user/cris/target_elf.h
 create mode 100644 linux-user/hppa/target_elf.h
 create mode 100644 linux-user/i386/target_elf.h
 create mode 100644 linux-user/m68k/target_elf.h
 create mode 100644 linux-user/microblaze/target_elf.h
 create mode 100644 linux-user/mips/target_elf.h
 create mode 100644 linux-user/mips64/target_elf.h
 create mode 100644 linux-user/nios2/target_elf.h
 create mode 100644 linux-user/openrisc/target_elf.h
 create mode 100644 linux-user/ppc/target_elf.h
 create mode 100644 linux-user/s390x/target_elf.h
 create mode 100644 linux-user/sh4/target_elf.h
 create mode 100644 linux-user/sparc/target_elf.h
 create mode 100644 linux-user/sparc64/target_elf.h
 create mode 100644 linux-user/tilegx/target_elf.h
 create mode 100644 linux-user/unicore32/target_elf.h
 create mode 100644 linux-user/x86_64/target_elf.h

diff --git a/linux-user/aarch64/target_elf.h b/linux-user/aarch64/target_elf.h
new file mode 100644
index 00..a7eb962fba
--- /dev/null
+++ b/linux-user/aarch64/target_elf.h
@@ -0,0 +1,14 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation, or (at your option) any
+ * later version. See the COPYING file in the top-level directory.
+ */
+
+#ifndef AARCH64_TARGET_ELF_H
+#define AARCH64_TARGET_ELF_H
+static inline const char *cpu_get_model(uint32_t eflags)
+{
+return "any";
+}
+#endif
diff --git a/linux-user/alpha/target_elf.h b/linux-user/alpha/target_elf.h
new file mode 100644
index 00..344e9f4d39
--- /dev/null
+++ b/linux-user/alpha/target_elf.h
@@ -0,0 +1,14 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation, or (at your option) any
+ * later version. See the COPYING file in the top-level directory.
+ */
+
+#ifndef ALPHA_TARGET_ELF_H
+#define ALPHA_TARGET_ELF_H
+static inline const char *cpu_get_model(uint32_t eflags)
+{
+return "any";
+}
+#endif
diff --git a/linux-user/arm/target_elf.h b/linux-user/arm/target_elf.h
new file mode 100644
index 00..58ff6a0986
--- /dev/null
+++ b/linux-user/arm/target_elf.h
@@ -0,0 +1,14 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation, or (at your option) any
+ * later version. See the COPYING file in the top-level directory.
+ */
+
+#ifndef ARM_TARGET_ELF_H
+#define ARM_TARGET_ELF_H
+static inline const char *cpu_get_model(uint32_t eflags)
+{
+return "any";
+}
+#endif
diff --git a/linux-user/cris/target_elf.h b/linux-user/cris/target_elf.h
new file mode 100644
index 00..99eb4ec704
--- /dev/null
+++ b/linux-user/cris/target_elf.h
@@ -0,0 +1,14 @@
+/*
+ * This program is free software; 

[Qemu-devel] [PATCH v3 2/4] linux-user: introduce functions to detect CPU type

[Laurent Vivier]

From: YunQiang Su 

Add a function to return ELF e_flags and use it
to select the CPU model.

[lv: split the patch and some cleanup in get_elf_eflags()]
Signed-off-by: Laurent Vivier 
Reviewed-by: Richard Henderson 
---

Notes:
YunQiang Su, please add your Signed-off-by that was
missing in your original patch.

v2: call cpu_get_model() with the result of get_elf_eflags()

 linux-user/elfload.c | 35 +++
 linux-user/main.c| 20 ++--
 linux-user/qemu.h|  1 +
 3 files changed, 46 insertions(+), 10 deletions(-)

diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 20f3d8c2c3..67e2425ac6 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -2376,6 +2376,41 @@ give_up:
 g_free(syms);
 }
 
+uint32_t get_elf_eflags(int fd)
+{
+struct elfhdr ehdr;
+off_t offset;
+int ret;
+
+/* Read ELF header */
+offset = lseek(fd, 0, SEEK_SET);
+if (offset == (off_t) -1) {
+return 0;
+}
+ret = read(fd, , sizeof(ehdr));
+if (ret < sizeof(ehdr)) {
+return 0;
+}
+offset = lseek(fd, offset, SEEK_SET);
+if (offset == (off_t) -1) {
+return 0;
+}
+
+/* Check ELF signature */
+if (!elf_check_ident()) {
+return 0;
+}
+
+/* check header */
+bswap_ehdr();
+if (!elf_check_ehdr()) {
+return 0;
+}
+
+/* return architecture id */
+return ehdr.e_flags;
+}
+
 int load_elf_binary(struct linux_binprm *bprm, struct image_info *info)
 {
 struct image_info interp_info;
diff --git a/linux-user/main.c b/linux-user/main.c
index 3954e8996b..6845b56030 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -4319,8 +4319,17 @@ int main(int argc, char **argv, char **envp)
 
 init_qemu_uname_release();
 
+execfd = qemu_getauxval(AT_EXECFD);
+if (execfd == 0) {
+execfd = open(filename, O_RDONLY);
+if (execfd < 0) {
+printf("Error while loading %s: %s\n", filename, strerror(errno));
+_exit(EXIT_FAILURE);
+}
+}
+
 if (cpu_model == NULL) {
-cpu_model = cpu_get_model(0);
+cpu_model = cpu_get_model(get_elf_eflags(execfd));
 }
 tcg_exec_init(0);
 /* NOTE: we need to init the CPU at this stage to get
@@ -4413,15 +4422,6 @@ int main(int argc, char **argv, char **envp)
 cpu->opaque = ts;
 task_settid(ts);
 
-execfd = qemu_getauxval(AT_EXECFD);
-if (execfd == 0) {
-execfd = open(filename, O_RDONLY);
-if (execfd < 0) {
-printf("Error while loading %s: %s\n", filename, strerror(errno));
-_exit(EXIT_FAILURE);
-}
-}
-
 ret = loader_exec(execfd, filename, target_argv, target_environ, regs,
 info, );
 if (ret != 0) {
diff --git a/linux-user/qemu.h b/linux-user/qemu.h
index 4edd7d0c08..47ca71159c 100644
--- a/linux-user/qemu.h
+++ b/linux-user/qemu.h
@@ -188,6 +188,7 @@ int loader_exec(int fdexec, const char *filename, char 
**argv, char **envp,
  struct target_pt_regs * regs, struct image_info *infop,
  struct linux_binprm *);
 
+uint32_t get_elf_eflags(int fd);
 int load_elf_binary(struct linux_binprm *bprm, struct image_info *info);
 int load_flt_binary(struct linux_binprm *bprm, struct image_info *info);
 
-- 
2.14.3

Re: [Qemu-devel] [PATCH v2 15/32] qcow2: Update l2_load() to support L2 slices

[Eric Blake]

On 12/15/2017 06:53 AM, Alberto Garcia wrote:
> Each entry in the qcow2 L2 cache stores a full L2 table (which uses a
> complete cluster in the qcow2 image). A cluster is usually too large
> to be used efficiently as the size for a cache entry, so we want to
> decouple both values by allowing smaller cache entries. Therefore the
> qcow2 L2 cache will no longer return full L2 tables but slices
> instead.
> 
> This patch updates l2_load() so it can handle L2 slices correctly.
> Apart from the offset of the L2 table (which we already had) we also
> need the guest offset in order to calculate which one of the slices
> we need.
> 
> An L2 slice has currently the same size as an L2 table (one cluster),
> so for now this function will load exactly the same data as before.
> 
> This patch also removes a stale comment about the return value being
> a pointer to the L2 table. This function returns an error code since
> 55c17e9821c474d5fcdebdc82ed2fc096777d611.
> 
> Signed-off-by: Alberto Garcia 
> ---
>  block/qcow2-cluster.c | 28 +---
>  1 file changed, 17 insertions(+), 11 deletions(-)
> 

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 14/32] qcow2: Add offset_to_l2_slice_index()

[Eric Blake]

On 12/15/2017 06:53 AM, Alberto Garcia wrote:
> Similar to offset_to_l2_index(), this function takes a guest offset
> and returns the index in the L2 slice that contains its L2 entry.
> 
> An L2 slice has currently the same size as an L2 table (one cluster),
> so both functions return the same value for now.
> 
> Signed-off-by: Alberto Garcia 
> ---
>  block/qcow2.h | 5 +
>  1 file changed, 5 insertions(+)
> 

Reviewed-by: Eric Blake 

> +
>  static inline int64_t align_offset(int64_t offset, int n)
>  {
>  offset = (offset + n - 1) & ~(n - 1);
> 

Unrelated to this commit, but should we switch this to use
QEMU_ALIGN_UP() instead of open-coding it?

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 13/32] qcow2: Add l2_slice_size field to BDRVQcow2State

[Eric Blake]

On 12/15/2017 06:53 AM, Alberto Garcia wrote:
> The BDRVQcow2State structure contains an l2_size field, which stores
> the number of 64-bit entries in an L2 table.
> 
> For efficiency reasons we want to be able to load slices instead of
> full L2 tables, so we need to know how many entries an L2 slice can
> hold.
> 
> An L2 slice is the portion of an L2 table that is loaded by the qcow2
> cache. At the moment that cache can only load complete tables,
> therefore an L2 slice has the same size as an L2 table (one cluster)
> and l2_size == l2_slice_size.
> 
> Later we'll allow smaller slices, but until then we have to use this
> new l2_slice_size field to make the rest of the code ready for that.
> 
> Signed-off-by: Alberto Garcia 
> ---
>  block/qcow2.c | 3 +++
>  block/qcow2.h | 1 +
>  2 files changed, 4 insertions(+)
> 
> diff --git a/block/qcow2.c b/block/qcow2.c
> index bdac1c156f..c1e4bab391 100644
> --- a/block/qcow2.c
> +++ b/block/qcow2.c
> @@ -797,6 +797,7 @@ static void read_cache_sizes(BlockDriverState *bs, 
> QemuOpts *opts,
>  typedef struct Qcow2ReopenState {
>  Qcow2Cache *l2_table_cache;
>  Qcow2Cache *refcount_block_cache;
> +int l2_slice_size;

Worth a comment?
/* Number of entries in a slice of the L2 table */

With or without,
Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 12/32] qcow2: Add offset_to_l1_index()

[Eric Blake]

On 12/15/2017 06:53 AM, Alberto Garcia wrote:
> Similar to offset_to_l2_index(), this function returns the index in
> the L1 table for a given guest offset. This is only used in a couple
> of places and it's not a particularly complex calculation, but it
> makes the code a bit more readable.
> 
> Although in the qcow2_get_cluster_offset() case the old code was
> taking advantage of the l1_bits variable, we're going to get rid of
> the other uses of l1_bits in a later patch anyway, so it doesn't make
> sense to keep it just for this.
> 
> Signed-off-by: Alberto Garcia 
> ---
>  block/qcow2-cluster.c | 4 ++--
>  block/qcow2.h | 5 +
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature