[Qemu-devel] [PATCH v5 2/6] fsdev-throttle-qmp: Rename the ThrottleLimits member names

2018-11-16 Thread xiezhide
Rename the ThrottleLimits member names and modify related code

Signed-off-by: xiezhide 
---
 qapi/block-core.json |  70 +++---
 util/throttle.c  | 163 +--
 2 files changed, 116 insertions(+), 117 deletions(-)

diff --git a/qapi/block-core.json b/qapi/block-core.json
index d4fe710..4ffaaea 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -2240,45 +2240,45 @@
 # transaction. All fields are optional. When setting limits, if a field is
 # missing the current value is not changed.
 #
-# @iops-total: limit total I/O operations per second
-# @iops-total-max: I/O operations burst
-# @iops-total-max-length:  length of the iops-total-max burst period, in 
seconds
-#  It must only be set if @iops-total-max is set as 
well.
-# @iops-read:  limit read operations per second
-# @iops-read-max:  I/O operations read burst
-# @iops-read-max-length:   length of the iops-read-max burst period, in seconds
-#  It must only be set if @iops-read-max is set as 
well.
-# @iops-write: limit write operations per second
-# @iops-write-max: I/O operations write burst
-# @iops-write-max-length:  length of the iops-write-max burst period, in 
seconds
-#  It must only be set if @iops-write-max is set as 
well.
-# @bps-total:  limit total bytes per second
-# @bps-total-max:  total bytes burst
-# @bps-total-max-length:   length of the bps-total-max burst period, in 
seconds.
-#  It must only be set if @bps-total-max is set as 
well.
-# @bps-read:   limit read bytes per second
-# @bps-read-max:   total bytes read burst
-# @bps-read-max-length:length of the bps-read-max burst period, in seconds
-#  It must only be set if @bps-read-max is set as well.
-# @bps-write:  limit write bytes per second
-# @bps-write-max:  total bytes write burst
-# @bps-write-max-length:   length of the bps-write-max burst period, in seconds
-#  It must only be set if @bps-write-max is set as 
well.
-# @iops-size:  when limiting by iops max size of an I/O in bytes
+# @iops: limit total I/O operations per second
+# @iops_max: I/O operations burst
+# @iops_max_length:  length of the iops_total_max burst period, in seconds
+#  It must only be set if @iops_total_max is set as 
well.
+# @iops_rd:  limit read operations per second
+# @iops_rd_max:  I/O operations read burst
+# @iops_rd_max_length:   length of the iops_read_max burst period, in seconds
+#  It must only be set if @iops_read_max is set as 
well.
+# @iops_wr: limit write operations per second
+# @iops_wr_max: I/O operations write burst
+# @iops_wr_max_length:  length of the iops_write_max burst period, in seconds
+#  It must only be set if @iops_write_max is set as 
well.
+# @bps:  limit total bytes per second
+# @bps_max:  total bytes burst
+# @bps_max_length:   length of the bps_total_max burst period, in seconds.
+#  It must only be set if @bps_total_max is set as 
well.
+# @bps_rd:   limit read bytes per second
+# @bps_rd_max:   total bytes read burst
+# @bps_rd_max_length:length of the bps_read_max burst period, in seconds
+#  It must only be set if @bps_read_max is set as well.
+# @bps_wr:  limit write bytes per second
+# @bps_wr_max:  total bytes write burst
+# @bps_wr_max_length:   length of the bps_write_max burst period, in seconds
+#  It must only be set if @bps_write_max is set as 
well.
+# @iops_size:  when limiting by iops max size of an I/O in bytes
 #
 # Since: 2.11
 ##
 { 'struct': 'ThrottleLimits',
-  'data': { '*iops-total' : 'int', '*iops-total-max' : 'int',
-'*iops-total-max-length' : 'int', '*iops-read' : 'int',
-'*iops-read-max' : 'int', '*iops-read-max-length' : 'int',
-'*iops-write' : 'int', '*iops-write-max' : 'int',
-'*iops-write-max-length' : 'int', '*bps-total' : 'int',
-'*bps-total-max' : 'int', '*bps-total-max-length' : 'int',
-'*bps-read' : 'int', '*bps-read-max' : 'int',
-'*bps-read-max-length' : 'int', '*bps-write' : 'int',
-'*bps-write-max' : 'int', '*bps-write-max-length' : 'int',
-'*iops-size' : 'int' } }
+  'data': { '*iops' : 'int', '*iops_max' : 'int',
+'*iops_max_length' : 'int', '*iops_rd' : 'int',
+'*iops_rd_max' : 'int', '*iops_rd_max_length' : 'int',
+'*iops_wr' : 'int', '*iops_wr_max' : 'int',
+'*iops_wr_max_length' : 'int', '*bps' : 'int',
+'*bps_max' : 'int', 

[Qemu-devel] [PATCH v5 3/6] fsdev-throttle-qmp: Rewrite BlockIOThrottle with ThrottleLimits as its base class

2018-11-16 Thread xiezhide
Rewrite BlockIOThrottle with ThrottleLimits as its base class and modify 
related code

Signed-off-by: xiezhide 
---
 blockdev.c   |  2 ++
 qapi/block-core.json | 73 ++--
 2 files changed, 4 insertions(+), 71 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index fce5d8f..89921ec 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -2752,6 +2752,8 @@ void qmp_block_set_io_throttle(BlockIOThrottle *arg, 
Error **errp)
 cfg.op_size = arg->iops_size;
 }
 
+throttle_limits_to_config(qapi_BlockIOThrottle_base(arg), , errp);
+
 if (!throttle_is_valid(, errp)) {
 goto out;
 }
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 4ffaaea..3abd6af 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -2155,82 +2155,13 @@
 #
 # @id: The name or QOM path of the guest device (since: 2.8)
 #
-# @bps: total throughput limit in bytes per second
-#
-# @bps_rd: read throughput limit in bytes per second
-#
-# @bps_wr: write throughput limit in bytes per second
-#
-# @iops: total I/O operations per second
-#
-# @iops_rd: read I/O operations per second
-#
-# @iops_wr: write I/O operations per second
-#
-# @bps_max: total throughput limit during bursts,
-# in bytes (Since 1.7)
-#
-# @bps_rd_max: read throughput limit during bursts,
-#in bytes (Since 1.7)
-#
-# @bps_wr_max: write throughput limit during bursts,
-#in bytes (Since 1.7)
-#
-# @iops_max: total I/O operations per second during bursts,
-#  in bytes (Since 1.7)
-#
-# @iops_rd_max: read I/O operations per second during bursts,
-# in bytes (Since 1.7)
-#
-# @iops_wr_max: write I/O operations per second during bursts,
-# in bytes (Since 1.7)
-#
-# @bps_max_length: maximum length of the @bps_max burst
-#period, in seconds. It must only
-#be set if @bps_max is set as well.
-#Defaults to 1. (Since 2.6)
-#
-# @bps_rd_max_length: maximum length of the @bps_rd_max
-#   burst period, in seconds. It must only
-#   be set if @bps_rd_max is set as well.
-#   Defaults to 1. (Since 2.6)
-#
-# @bps_wr_max_length: maximum length of the @bps_wr_max
-#   burst period, in seconds. It must only
-#   be set if @bps_wr_max is set as well.
-#   Defaults to 1. (Since 2.6)
-#
-# @iops_max_length: maximum length of the @iops burst
-# period, in seconds. It must only
-# be set if @iops_max is set as well.
-# Defaults to 1. (Since 2.6)
-#
-# @iops_rd_max_length: maximum length of the @iops_rd_max
-#burst period, in seconds. It must only
-#be set if @iops_rd_max is set as well.
-#Defaults to 1. (Since 2.6)
-#
-# @iops_wr_max_length: maximum length of the @iops_wr_max
-#burst period, in seconds. It must only
-#be set if @iops_wr_max is set as well.
-#Defaults to 1. (Since 2.6)
-#
-# @iops_size: an I/O size in bytes (Since 1.7)
-#
 # @group: throttle group name (Since 2.4)
 #
 # Since: 1.1
 ##
 { 'struct': 'BlockIOThrottle',
-  'data': { '*device': 'str', '*id': 'str', 'bps': 'int', 'bps_rd': 'int',
-'bps_wr': 'int', 'iops': 'int', 'iops_rd': 'int', 'iops_wr': 'int',
-'*bps_max': 'int', '*bps_rd_max': 'int',
-'*bps_wr_max': 'int', '*iops_max': 'int',
-'*iops_rd_max': 'int', '*iops_wr_max': 'int',
-'*bps_max_length': 'int', '*bps_rd_max_length': 'int',
-'*bps_wr_max_length': 'int', '*iops_max_length': 'int',
-'*iops_rd_max_length': 'int', '*iops_wr_max_length': 'int',
-'*iops_size': 'int', '*group': 'str' } }
+  'base': 'ThrottleLimits',
+  'data': { '*device': 'str', '*id': 'str', '*group': 'str' } }
 
 ##
 # @ThrottleLimits:
-- 
1.8.3.1




Re: [Qemu-devel] [PATCH for-4.0 00/17] tcg: Move softmmu out-of-line

2018-11-16 Thread Richard Henderson
On 11/16/18 6:10 AM, Emilio G. Cota wrote:
> It's possible that newer machines with larger reorder buffers
> will be able to take better advantage of the higher instruction
> locality, hiding the latency of having to execute more instructions.
> I'll test on Skylake tomorrow.

I've noticed that the code we generate for calls has twice as many instructions
as really needed for setting up the arguments.  I have a plan to fix that,
which hopefully will solve this problem.


r~



Re: [Qemu-devel] [PATCH 0/3] Introduce 'rendernode' option for egl-headless display type

2018-11-16 Thread Gerd Hoffmann
On Thu, Nov 15, 2018 at 09:47:44AM -0600, Eric Blake wrote:
> On 11/15/18 9:15 AM, Erik Skultety wrote:
> > Since QEMU always picks the default DRI device, libvirt doesn't know which 
> > one
> > to put into the mount namespace and relabel it accordingly, hence hitting
> > permission issues, unless admin tweaks the default permissions of the DRI
> > devices.
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1648236
> 
> This is borderline between fixing a bug that gets in the way of libvirt (and
> thus useful for 3.1) and a feature (thus for 4.0, since we won't have a 3.2
> release). I'll let Gerd decide.

It's simple enough and we are early in the -rc cycle still, I think it
would be okay for 3.1.

cheers,
  Gerd




Re: [Qemu-devel] [RFC v1 13/23] riscv: tcg-target: Add the extract instructions

2018-11-16 Thread Richard Henderson
On 11/15/18 11:35 PM, Alistair Francis wrote:
> Signed-off-by: Alistair Francis 
> Signed-off-by: Michael Clark 
> ---
>  tcg/riscv/tcg-target.inc.c | 34 ++
>  1 file changed, 34 insertions(+)

Reviewed-by: Richard Henderson 


r~



Re: [Qemu-devel] [PATCH v5 18/24] hw: i386: Export the MADT build method

2018-11-16 Thread Igor Mammedov
On Mon,  5 Nov 2018 02:40:41 +0100
Samuel Ortiz  wrote:

> It is going to be used by the PC machine type as the MADT table builder
> method and thus needs to be exported outside of acpi-build.c
> 
> Also, now that the generic build_madt() API is exported, we have to
> rename the ARM static one in order to avoid build time conflicts.
> 
> Reviewed-by: Philippe Mathieu-Daudé 
> Tested-by: Philippe Mathieu-Daudé 
> Signed-off-by: Samuel Ortiz 
> ---
>  include/hw/i386/acpi.h   | 28 
>  hw/arm/virt-acpi-build.c |  4 ++--
>  hw/i386/acpi-build.c |  4 ++--
>  3 files changed, 32 insertions(+), 4 deletions(-)
>  create mode 100644 include/hw/i386/acpi.h
> 
> diff --git a/include/hw/i386/acpi.h b/include/hw/i386/acpi.h
> new file mode 100644
> index 00..b7a887111d
> --- /dev/null
> +++ b/include/hw/i386/acpi.h
[...]

> +/* ACPI MADT (Multiple APIC Description Table) build method */
> +void build_madt(GArray *table_data, BIOSLinker *linker,
> +MachineState *ms, AcpiConfiguration *conf);
> +
> +#endif
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index b5e165543a..b0354c5f03 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -564,7 +564,7 @@ build_gtdt(GArray *table_data, BIOSLinker *linker, 
> VirtMachineState *vms)
>  
>  /* MADT */
>  static void
> -build_madt(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
> +virt_build_madt(GArray *table_data, BIOSLinker *linker, VirtMachineState 
> *vms)
>  {
You are moving build_madt() into x86 specific header i386/acpi.h
so question is why do you touch ARM variant at all?

[...]



[Qemu-devel] [PATCH for-3.1] nvme: fix out-of-bounds access to the CMB

2018-11-16 Thread Paolo Bonzini
Because the CMB BAR has a min_access_size of 2, if you read the last
byte it will try to memcpy *2* bytes from n->cmbuf, causing an off-by-one
error.  This is CVE-2018-16847.

Another way to fix this might be to register the CMB as a RAM memory
region, which would also be more efficient.  However, that might be a
change for big-endian machines; I didn't think this through and I don't
know how real hardware works.  Add a basic testcase for the CMB in case
somebody does this change later on.

Cc: Keith Busch 
Cc: qemu-bl...@nongnu.org
Cc: Li Qiang 
Signed-off-by: Paolo Bonzini 
---
 hw/block/nvme.c|  2 +-
 tests/Makefile.include |  2 +-
 tests/nvme-test.c  | 58 +++---
 3 files changed, 57 insertions(+), 5 deletions(-)

diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index 09d7c90259..5d92794ef7 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -1192,7 +1192,7 @@ static const MemoryRegionOps nvme_cmb_ops = {
 .write = nvme_cmb_write,
 .endianness = DEVICE_LITTLE_ENDIAN,
 .impl = {
-.min_access_size = 2,
+.min_access_size = 1,
 .max_access_size = 8,
 },
 };
diff --git a/tests/Makefile.include b/tests/Makefile.include
index 613242bc6e..fb0b449c02 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -730,7 +730,7 @@ tests/test-hmp$(EXESUF): tests/test-hmp.o
 tests/machine-none-test$(EXESUF): tests/machine-none-test.o
 tests/drive_del-test$(EXESUF): tests/drive_del-test.o $(libqos-virtio-obj-y)
 tests/qdev-monitor-test$(EXESUF): tests/qdev-monitor-test.o $(libqos-pc-obj-y)
-tests/nvme-test$(EXESUF): tests/nvme-test.o
+tests/nvme-test$(EXESUF): tests/nvme-test.o $(libqos-pc-obj-y)
 tests/pvpanic-test$(EXESUF): tests/pvpanic-test.o
 tests/i82801b11-test$(EXESUF): tests/i82801b11-test.o
 tests/ac97-test$(EXESUF): tests/ac97-test.o
diff --git a/tests/nvme-test.c b/tests/nvme-test.c
index 7674a446e4..2abb3b6d19 100644
--- a/tests/nvme-test.c
+++ b/tests/nvme-test.c
@@ -8,11 +8,64 @@
  */
 
 #include "qemu/osdep.h"
+#include "qemu/units.h"
 #include "libqtest.h"
+#include "libqos/libqos-pc.h"
+
+static QOSState *qnvme_start(const char *extra_opts)
+{
+QOSState *qs;
+const char *arch = qtest_get_arch();
+const char *cmd = "-drive id=drv0,if=none,file=null-co://,format=raw "
+  "-device nvme,addr=0x4.0,serial=foo,drive=drv0 %s";
+
+if (strcmp(arch, "i386") == 0 || strcmp(arch, "x86_64") == 0) {
+qs = qtest_pc_boot(cmd, extra_opts ? : "");
+global_qtest = qs->qts;
+return qs;
+}
+
+g_printerr("nvme tests are only available on x86\n");
+exit(EXIT_FAILURE);
+}
+
+static void qnvme_stop(QOSState *qs)
+{
+qtest_shutdown(qs);
+}
 
-/* Tests only initialization so far. TODO: Replace with functional tests */
 static void nop(void)
 {
+QOSState *qs;
+
+qs = qnvme_start(NULL);
+qnvme_stop(qs);
+}
+
+static void nvmetest_cmb_test(void)
+{
+const int cmb_bar_size = 2 * MiB;
+QOSState *qs;
+QPCIDevice *pdev;
+QPCIBar bar;
+
+qs = qnvme_start("-global nvme.cmb_size_mb=2");
+pdev = qpci_device_find(qs->pcibus, QPCI_DEVFN(4,0));
+g_assert(pdev != NULL);
+
+qpci_device_enable(pdev);
+bar = qpci_iomap(pdev, 2, NULL);
+
+qpci_io_writel(pdev, bar, 0, 0xccbbaa99);
+g_assert_cmpint(qpci_io_readb(pdev, bar, 0), ==, 0x99);
+g_assert_cmpint(qpci_io_readw(pdev, bar, 0), ==, 0xaa99);
+
+/* Test partially out-of-bounds accesses.  */
+qpci_io_writel(pdev, bar, cmb_bar_size - 1, 0x44332211);
+g_assert_cmpint(qpci_io_readb(pdev, bar, cmb_bar_size - 1), ==, 0x11);
+g_assert_cmpint(qpci_io_readw(pdev, bar, cmb_bar_size - 1), !=, 0x2211);
+g_assert_cmpint(qpci_io_readl(pdev, bar, cmb_bar_size - 1), !=, 
0x44332211);
+qnvme_stop(qs);
 }
 
 int main(int argc, char **argv)
@@ -21,9 +74,8 @@ int main(int argc, char **argv)
 
 g_test_init(, , NULL);
 qtest_add_func("/nvme/nop", nop);
+qtest_add_func("/nvme/cmb_test", nvmetest_cmb_test);
 
-qtest_start("-drive id=drv0,if=none,file=null-co://,format=raw "
-"-device nvme,drive=drv0,serial=foo");
 ret = g_test_run();
 
 qtest_end();
-- 
2.19.1




[Qemu-devel] [PATCH v5 0/6] fsdev-throttle-qmp: qmp interface for fsdev io throttling

2018-11-16 Thread xiezhide
This patches provide qmp interface to query/set io throttle parameters of a 
fsdev.
Some of patches also refactor the code and structure that was present in block 
and fsdev files. 

xiezhide (6):
  fsdev-throttle-qmp: factor out throttle code to reuse code
  fsdev-throttle-qmp: Rename the ThrottleLimits member names
  fsdev-throttle-qmp: Rewrite BlockIOThrottle with ThrottleLimits as its
base class
  fsdev-throttle-qmp: Move ThrottleLimits into a new file for future
reuse
  fsdev-throttle-qmp: qmp interface for fsdev io throttling
  fsdev-throttle-qmp: hmp interface for fsdev io throttling

 Makefile|  18 
 Makefile.objs   |   8 ++
 block/throttle.c|   6 +-
 blockdev.c  |  45 +---
 fsdev/qemu-fsdev-dummy.c|  11 ++
 fsdev/qemu-fsdev-throttle.c | 142 +++-
 fsdev/qemu-fsdev-throttle.h |   6 +-
 fsdev/qemu-fsdev.c  |  29 +
 hmp-commands-info.hx|  15 +++
 hmp-commands.hx |  15 +++
 hmp.c   |  81 --
 hmp.h   |   4 +
 include/qemu/throttle-options.h |   2 +
 include/qemu/throttle.h |   4 +-
 include/qemu/typedefs.h |   1 +
 qapi/block-core.json| 122 +
 qapi/fsdev.json |  96 +
 qapi/qapi-schema.json   |   2 +
 qapi/tlimits.json   |  53 +
 qmp.c   |  13 +++
 util/throttle.c | 231 ++--
 21 files changed, 598 insertions(+), 306 deletions(-)
 create mode 100644 qapi/fsdev.json
 create mode 100644 qapi/tlimits.json

 v0 -> v1:
  Addressed comments from Eric Blake and Greg Kurz.
  Fix patch corrupt issue due to email client change the patch format with 
copy-to-paster
  Break patch to patches

 v1 -> v2:
  Addressed comments from Greg Kurz.
  send patch with outlook,patch corrupted, resend with git send-email

 v2 -> v3:
  Addressed comments from Eric Blake.
  split patch1 into two patches

 v3 -> v4:
  Fix issue cause test failed on centos and fedora

 v4 -> v5:
  Addressed comments from Eric Blake.
  split patch3 into three patches  

-- 
1.8.3.1




[Qemu-devel] [PATCH v5 1/6] fsdev-throttle-qmp: factor out throttle code to reuse code

2018-11-16 Thread xiezhide
Factor out throttle parameter parsing code to a new common
function which will be used by block and fsdev.
Rename function throttle_parse_options to throttle_parse_group
to resolve function name conflict

Reviewed-by: Eric Blake 
Signed-off-by: xiezhide 
---
 block/throttle.c|  6 ++--
 blockdev.c  | 43 +-
 fsdev/qemu-fsdev-throttle.c | 44 ++
 include/qemu/throttle-options.h |  2 ++
 include/qemu/throttle.h |  4 +--
 include/qemu/typedefs.h |  1 +
 util/throttle.c | 68 +
 7 files changed, 79 insertions(+), 89 deletions(-)

diff --git a/block/throttle.c b/block/throttle.c
index 636c976..bd23c58 100644
--- a/block/throttle.c
+++ b/block/throttle.c
@@ -41,7 +41,7 @@ static QemuOptsList throttle_opts = {
  * @group and must be freed by the caller.
  * If there's an error then @group remains unmodified.
  */
-static int throttle_parse_options(QDict *options, char **group, Error **errp)
+static int throttle_parse_group(QDict *options, char **group, Error **errp)
 {
 int ret;
 const char *group_name;
@@ -90,7 +90,7 @@ static int throttle_open(BlockDriverState *bs, QDict *options,
 bs->supported_zero_flags = bs->file->bs->supported_zero_flags |
BDRV_REQ_WRITE_UNCHANGED;
 
-ret = throttle_parse_options(options, , errp);
+ret = throttle_parse_group(options, , errp);
 if (ret == 0) {
 /* Register membership to group with name group_name */
 throttle_group_register_tgm(tgm, group, bdrv_get_aio_context(bs));
@@ -179,7 +179,7 @@ static int throttle_reopen_prepare(BDRVReopenState 
*reopen_state,
 assert(reopen_state != NULL);
 assert(reopen_state->bs != NULL);
 
-ret = throttle_parse_options(reopen_state->options, , errp);
+ret = throttle_parse_group(reopen_state->options, , errp);
 reopen_state->opaque = group;
 return ret;
 }
diff --git a/blockdev.c b/blockdev.c
index 81f95d9..fce5d8f 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -400,48 +400,7 @@ static void extract_common_blockdev_options(QemuOpts 
*opts, int *bdrv_flags,
 }
 
 if (throttle_cfg) {
-throttle_config_init(throttle_cfg);
-throttle_cfg->buckets[THROTTLE_BPS_TOTAL].avg =
-qemu_opt_get_number(opts, "throttling.bps-total", 0);
-throttle_cfg->buckets[THROTTLE_BPS_READ].avg  =
-qemu_opt_get_number(opts, "throttling.bps-read", 0);
-throttle_cfg->buckets[THROTTLE_BPS_WRITE].avg =
-qemu_opt_get_number(opts, "throttling.bps-write", 0);
-throttle_cfg->buckets[THROTTLE_OPS_TOTAL].avg =
-qemu_opt_get_number(opts, "throttling.iops-total", 0);
-throttle_cfg->buckets[THROTTLE_OPS_READ].avg =
-qemu_opt_get_number(opts, "throttling.iops-read", 0);
-throttle_cfg->buckets[THROTTLE_OPS_WRITE].avg =
-qemu_opt_get_number(opts, "throttling.iops-write", 0);
-
-throttle_cfg->buckets[THROTTLE_BPS_TOTAL].max =
-qemu_opt_get_number(opts, "throttling.bps-total-max", 0);
-throttle_cfg->buckets[THROTTLE_BPS_READ].max  =
-qemu_opt_get_number(opts, "throttling.bps-read-max", 0);
-throttle_cfg->buckets[THROTTLE_BPS_WRITE].max =
-qemu_opt_get_number(opts, "throttling.bps-write-max", 0);
-throttle_cfg->buckets[THROTTLE_OPS_TOTAL].max =
-qemu_opt_get_number(opts, "throttling.iops-total-max", 0);
-throttle_cfg->buckets[THROTTLE_OPS_READ].max =
-qemu_opt_get_number(opts, "throttling.iops-read-max", 0);
-throttle_cfg->buckets[THROTTLE_OPS_WRITE].max =
-qemu_opt_get_number(opts, "throttling.iops-write-max", 0);
-
-throttle_cfg->buckets[THROTTLE_BPS_TOTAL].burst_length =
-qemu_opt_get_number(opts, "throttling.bps-total-max-length", 1);
-throttle_cfg->buckets[THROTTLE_BPS_READ].burst_length  =
-qemu_opt_get_number(opts, "throttling.bps-read-max-length", 1);
-throttle_cfg->buckets[THROTTLE_BPS_WRITE].burst_length =
-qemu_opt_get_number(opts, "throttling.bps-write-max-length", 1);
-throttle_cfg->buckets[THROTTLE_OPS_TOTAL].burst_length =
-qemu_opt_get_number(opts, "throttling.iops-total-max-length", 1);
-throttle_cfg->buckets[THROTTLE_OPS_READ].burst_length =
-qemu_opt_get_number(opts, "throttling.iops-read-max-length", 1);
-throttle_cfg->buckets[THROTTLE_OPS_WRITE].burst_length =
-qemu_opt_get_number(opts, "throttling.iops-write-max-length", 1);
-
-throttle_cfg->op_size =
-qemu_opt_get_number(opts, "throttling.iops-size", 0);
+throttle_parse_options(throttle_cfg, opts);
 
 if (!throttle_is_valid(throttle_cfg, errp)) {
 return;
diff --git a/fsdev/qemu-fsdev-throttle.c b/fsdev/qemu-fsdev-throttle.c
index cfd8641..6a4108a 100644
--- 

Re: [Qemu-devel] [PATCH v4 1/4] fsdev-throttle-qmp: factor out throttle code to reuse code

2018-11-16 Thread xiezhide


-Original Message-
From: Eric Blake [mailto:ebl...@redhat.com] 
Sent: 2018年11月16日 4:56
To: xiezhide ; qemu-devel@nongnu.org
Cc: gr...@kaod.org; aneesh.ku...@linux.vnet.ibm.com; arm...@redhat.com; 
be...@igalia.com; zengcanfu 00215970 ; Jinxuefeng 
; Chenhui (Felix, Euler) 
Subject: Re: [PATCH v4 1/4] fsdev-throttle-qmp: factor out throttle code to 
reuse code

On 11/15/18 2:54 AM, xiezhide wrote:
> This patch factor out throttle parameter parse code to common function

s/factor/factors/

Actually, when I write commit messages, I like to use the imperative mood, with 
an implicit "Apply this patch in order to" unspoken prefix. 
Starting with an explicit "This patch does" is more of a descriptive mood. So I 
might have written:

Factor out the throttle parameter parsing code to a new common function which 
will be used by block and fsdev.

Very helpful, thanks

> which will be used by block and fsdev.
> rename function throttle_parse_options to throttle_parse_group to 
> resolve function name conflict
> 
> Signed-off-by: xiezhide 
> ---
>   block/throttle.c|  6 ++--
>   blockdev.c  | 43 +-
>   fsdev/qemu-fsdev-throttle.c | 44 ++
>   include/qemu/throttle-options.h |  2 ++
>   include/qemu/throttle.h |  4 +--
>   include/qemu/typedefs.h |  1 +
>   util/throttle.c | 68 
> +
>   7 files changed, 79 insertions(+), 89 deletions(-)
> 
> +++ b/include/qemu/throttle-options.h
> @@ -111,4 +111,6 @@
>   .help = "when limiting by iops max size of an I/O in bytes",\
>   }
>   
> +void throttle_parse_options(ThrottleConfig *, QemuOpts *);

It's okay to use parameter names in function declarations.

> +++ b/include/qemu/typedefs.h
> @@ -113,6 +113,7 @@ typedef struct uWireSlave uWireSlave;
>   typedef struct VirtIODevice VirtIODevice;
>   typedef struct Visitor Visitor;
>   typedef struct node_info NodeInfo;
> +typedef struct ThrottleConfig ThrottleConfig;

Please keep this in the right sorted location, right after SSIBus.

[Hmm, we already have an inconsistency on whether we are sorting by en_US 
rules, which are case-insensitive and therefore has 'struct node_info' in the 
wrong location, or by C rules which sort lowercase later and therefore has 
'struct uWireSlave' in the wrong position. For that matter, why are we renaming 
'struct node_info NodeInfo', and why does uWireSlave violate our naming 
conventions?  But those are independent cleanups, and not necessarily something 
for you to worry about]

With the sorting fixed,

-Fix it now

Thanks
Kidd


Re: [Qemu-devel] [RFC v1 00/23] Add RISC-V TCG backend support

2018-11-16 Thread no-reply
Hi,

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

Message-id: cover.1542321076.git.alistair.fran...@wdc.com
Type: series
Subject: [Qemu-devel] [RFC v1 00/23]  Add RISC-V TCG backend support

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
e0946be configure: Add support for building RISC-V host
769ab2a dias: Add RISC-V support
88c2947 tcg: Add RISC-V cpu signal handler
19e47a6 riscv: tcg-target: Add the target init code
506445c riscv: tcg-target: Add the prologue generation
496bf6b riscv: tcg-target: Add the out op decoder
7d5359d riscv: tcg-target: Add direct load and store instructions
25c5371 riscv: tcg-target: Add slowpath load and store instructions
4ca5f0c riscv: tcg-target: Add branch and jump instructions
cd8821b riscv: tcg-target: Add the out load and store instructions
58bb3e0 riscv: tcg-target: Add the extract instructions
a9dc143 riscv: tcg-target: Add the mov and movi instruction
4cf20d8 riscv: tcg-target: Add the relocation functions
78c1eb9 riscv: tcg-target: Add the instruction emitters
e277371 riscv: tcg-target: Add the immediate encoders
dcdb8bc riscv: tcg-target: Add support for the constraints
6a691a5 riscv: tcg-target: Regiser the JIT
b2165c4 riscv: Add the tcg target registers
243a714 riscv: Add the tcg-target header file
c2feca77 exec: Add RISC-V GCC poison macro
19ca815 linux-user: Add host dependency for RISC-V 64-bit
e84813f linux-user: Add host dependency for RISC-V 32-bit
a62d116 elf.h: Add the RISCV ELF magic numbers

=== OUTPUT BEGIN ===
Checking PATCH 1/23: elf.h: Add the RISCV ELF magic numbers...
Checking PATCH 2/23: linux-user: Add host dependency for RISC-V 32-bit...
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#11: 
new file mode 100644

total: 0 errors, 1 warnings, 11 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Checking PATCH 3/23: linux-user: Add host dependency for RISC-V 64-bit...
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#11: 
new file mode 100644

total: 0 errors, 1 warnings, 11 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Checking PATCH 4/23: exec: Add RISC-V GCC poison macro...
Checking PATCH 5/23: riscv: Add the tcg-target header file...
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#11: 
new file mode 100644

WARNING: architecture specific defines should be avoided
#43: FILE: tcg/riscv/tcg-target.h:28:
+#if __riscv_xlen == 32

total: 0 errors, 2 warnings, 173 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Checking PATCH 6/23: riscv: Add the tcg target registers...
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#11: 
new file mode 100644

total: 0 errors, 1 warnings, 120 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Checking PATCH 7/23: riscv: tcg-target: Regiser the JIT...
Checking PATCH 8/23: riscv: tcg-target: Add support for the constraints...
Checking PATCH 9/23: riscv: tcg-target: Add the immediate encoders...
Checking PATCH 10/23: riscv: tcg-target: Add the instruction emitters...
Checking PATCH 11/23: riscv: tcg-target: Add the relocation functions...
Checking PATCH 12/23: riscv: tcg-target: Add the mov and movi instruction...
Checking PATCH 13/23: riscv: tcg-target: Add the extract instructions...
Checking PATCH 14/23: riscv: tcg-target: Add the out load and store 
instructions...
Checking PATCH 15/23: riscv: tcg-target: Add branch and jump instructions...
Checking PATCH 16/23: riscv: tcg-target: Add slowpath load and store 
instructions...
Checking PATCH 17/23: riscv: tcg-target: Add direct load and store 
instructions...
ERROR: spaces required around that '*' (ctx:WxV)
#68: FILE: tcg/riscv/tcg-target.inc.c:1011:
+tcg_insn_unit *label_ptr[1];
   ^

ERROR: spaces required around that '*' (ctx:WxV)
#133: FILE: tcg/riscv/tcg-target.inc.c:1076:
+tcg_insn_unit *label_ptr[1];
   ^

total: 2 errors, 0 warnings, 

Re: [Qemu-devel] [RFC v1 12/23] riscv: tcg-target: Add the mov and movi instruction

2018-11-16 Thread Richard Henderson
On 11/15/18 11:35 PM, Alistair Francis wrote:
> Signed-off-by: Alistair Francis 
> Signed-off-by: Michael Clark 
> ---
>  tcg/riscv/tcg-target.inc.c | 62 ++
>  1 file changed, 62 insertions(+)
> 
> diff --git a/tcg/riscv/tcg-target.inc.c b/tcg/riscv/tcg-target.inc.c
> index 475feca906..0e891e24c9 100644
> --- a/tcg/riscv/tcg-target.inc.c
> +++ b/tcg/riscv/tcg-target.inc.c
> @@ -422,6 +422,68 @@ static void patch_reloc(tcg_insn_unit *code_ptr, int 
> type,
>  }
>  }
>  
> +/*
> + * TCG intrinsics
> + */
> +
> +static void tcg_out_mov(TCGContext *s, TCGType type, TCGReg ret, TCGReg arg)
> +{
> +if (ret == arg) {
> +return;
> +}
> +switch (type) {
> +case TCG_TYPE_I32:
> +case TCG_TYPE_I64:
> +tcg_out_opc_imm(s, OPC_ADDI, ret, arg, 0);
> +break;
> +default:
> +g_assert_not_reached();
> +}
> +}
> +
> +static void tcg_out_movi(TCGContext *s, TCGType type, TCGReg rd,
> + tcg_target_long val)
> +{
> +tcg_target_long lo = sextract32(val, 0, 12);

sextract64, otherwise you'll make wrong decisions for rv64.
(Although it might be worthwhile to add a local alias so that rv32 doesn't do
more work than necessary.)

> +tcg_target_long hi = val - lo;
> +
> +RISCVInsn add32_op = TCG_TARGET_REG_BITS == 64 ? OPC_ADDIW : OPC_ADDI;
> +
> +#if TCG_TARGET_REG_BITS == 64
> +ptrdiff_t offset = tcg_pcrel_diff(s, (void *)val);
> +#endif
> +
> +if (val == lo) {
> +tcg_out_opc_imm(s, OPC_ADDI, rd, TCG_REG_ZERO, val);
   return;
   }

Should match

if (TCG_TARGET_REG_BITS == 32 || val == (int32_t)val) {
tcg_out_opc_upper(s, OPC_LUI, rd, hi);
if (lo != 0) {
tcg_out_opc_imm(s, add32_op, rd, rd, lo);
}
return;
}

here.

(1) Almost all values requested are 32-bit constants, so check the most common
cases first.  (2) You know hi != 0 because you just eliminated val == lo.  (3)
This handles the cases where LUI alone can load the constant, e.g. 0x1000,
which would otherwise have been matched by your power-of-two test.


> +} else if (val && !(val & (val - 1))) {
> +/* power of 2 */
> +tcg_out_opc_imm(s, OPC_ADDI, rd, TCG_REG_ZERO, 1);
> +tcg_out_opc_imm(s, OPC_SLLI, rd, rd, ctz64(val));

There's no reason to restrict this to powers of 2 and a shift of the constant 1:

shift = ctz64(val);
tmp = val >> shift;
if (tmp == sextract64(tmp, 0, 12))

> +} else if (TCG_TARGET_REG_BITS == 64 &&
> +   !(val >> 31 == 0 || val >> 31 == -1)) {
> +int shift = 12 + ctz64(hi >> 12);

This is just ctz64(hi), since you've already cleared the lo 12 bits.

> +hi >>= shift;
> +tcg_out_movi(s, type, rd, hi);
> +tcg_out_opc_imm(s, OPC_SLLI, rd, rd, shift);
> +if (lo != 0) {
> +tcg_out_opc_imm(s, OPC_ADDI, rd, rd, lo);
> +}
> +#if TCG_TARGET_REG_BITS == 64
> +} else if (offset == sextract32(offset, 1, 31) << 1) {

sextract64.

> +tcg_out_opc_upper(s, OPC_AUIPC, rd, 0);
> +tcg_out_opc_imm(s, OPC_ADDI, rd, rd, 0);
> +reloc_call(s->code_ptr - 2, (tcg_insn_unit *)val);
> +#endif

Move this pc-rel case above the fully general case and then you can make the
fully general case unconditional.  Also, that preserves an invariant of
increasing order of complexity of the cases.  No need for the ifdef, since this
code should be removed as dead for rv32 (which saw the lui+addi case as
unconditional).


r~



[Qemu-devel] QEMU crash with sun4v machine

2018-11-16 Thread Thomas Huth


 Hi Artyom,

I noticed that QEMU aborts the hard way when it is simply started like this:

$ sparc64-softmmu/qemu-system-sparc64 -M sun4v 
qemu: fatal: Trap 0x0010 while trap level (6) >= MAXTL (6), Error state
pc: 0200  npc: 0204
%g0-3:    
%g4-7:    
%o0-3:     
%o4-7:     
%l0-3: 07f0 01ff 01fff008  
%l4-7:     
%i0-3:     
%i4-7:     
%f00:     
%f08:     
%f16:     
%f24:     
%f32:     
%f40:     
%f48:     
%f56:     
pstate: 0014 ccr: 44 (icc: -Z-- xcc: -Z--) asi: 00 tl: 6 pil: 0 gl: 8
tbr:  hpstate: 0004 htba: 
cansave: 6 canrestore: 0 otherwin: 0 wstate: 0 cleanwin: 6 cwp: 7
fsr:  y:  fprs: 

Aborted (core dumped)

That's ugly - QEMU should never simply abort unless we hit a
programming error. Do you see a good way to ease this situation, e.g.
by printing a more friendly error message if both, kernel and bios
could not be loaded?

 Thomas



Re: [Qemu-devel] [PATCH V6 5/6] hw/arm/virt: add pvpanic deviceinvirt acpi table

2018-11-16 Thread peng.hao2
>> >> add pvpanic device in virt acpi table, so when kenrel command line uses
>> >> acpi=force, kernel can get info from acpi table in aarch64.
>>
>> [...]
>>
>> >>
>> >> +static void acpi_dsdt_add_pvpanic(Aml *scope, const MemMapEntry 
>> >> *pvpanic_memmap)
>> >> +{
>> >> +Aml *dev = aml_device("PANC");
>> >
>> >Shouldn't this be "PEVT" ("panic event"), like it is for x86?
>> >
>> yeah, I will change it.
>> >> +aml_append(dev, aml_name_decl("_HID", aml_string("QEMU0001")));
>> >> +aml_append(dev, aml_name_decl("_UID", aml_int(0)));
>> >
>> >Why add _UID? Also, I see x86 had some issues with not having _STA and
>> >then having a _STA without the UI flag. It now has _STA=0xf
>> >(PRESENT|ENABLED|UI|FUNCTIONING). I'm not saying we need to do that to,
>> >but I'd like to know if it was considered and decided we don't need to.
>> >
>> The way the kernel code processes _STA is that if _STA is not found, the 
>> default
>> setting is (PRESENT|ENABLED|UI|FUNCTIONING). So I think it is not necessary
>>  to add it. It is only parsed in the pvpanic driver.
>
>Good enough for me.
>
>> for _UID, I think it is used for device index. I just fill it with 0 because 
>> there is
>> only one pvpanic device.
>
>OK, but I'm still not sure it's necessary.
>
you can see other devices in virt-acpi-build.c. _UID is used for device index.

>>
>> by the way, How to get the value of ACPI conveniently? how dou you get the
>> value of _STA?
>
>Not sure what you mean here. From where do you want to check the value?
>If you mean from guest userspace, then there's nothing convenient that I
>know of. You'll have to disassemble the tables you extract from sysfs,
>afaik.
>
yeah ,I just want to know this.
thanks
>Thanks,
>drew

>
> Thanks.
> >> +
> >> +Aml *crs = aml_resource_template();
> >> +aml_append(crs, aml_memory32_fixed(pvpanic_memmap->base,
> >> +   pvpanic_memmap->size, 
> >> AML_READ_WRITE));
> >> +
> >> +aml_append(dev, aml_name_decl("_CRS", crs));
> >> +
> >> +aml_append(scope, dev);
> >> +}
> >> +
> >>  static void acpi_dsdt_add_uart(Aml *scope, const MemMapEntry *uart_memmap,
> >> uint32_t uart_irq)
> >>  {
> >> @@ -770,6 +785,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, 
> >> VirtMachineState *vms)
> >>  acpi_dsdt_add_cpus(scope, vms->smp_cpus);
> >>  acpi_dsdt_add_uart(scope, [VIRT_UART],
> >> (irqmap[VIRT_UART] + ARM_SPI_BASE));
> >> +acpi_dsdt_add_pvpanic(scope, [VIRT_PVPANIC]);
> >>  acpi_dsdt_add_flash(scope, [VIRT_FLASH]);
> >>  acpi_dsdt_add_fw_cfg(scope, [VIRT_FW_CFG]);
> >>  acpi_dsdt_add_virtio(scope, [VIRT_MMIO],
> >> --
> >> 1.8.3.1
> >>
> >>
> >
> >Thanks,
> >drew

Re: [Qemu-devel] [PATCH 0/3] Introduce 'rendernode' option for egl-headless display type

2018-11-16 Thread Gerd Hoffmann
On Fri, Nov 16, 2018 at 10:24:30AM +0100, Erik Skultety wrote:
> On Fri, Nov 16, 2018 at 09:43:52AM +0100, Gerd Hoffmann wrote:
> > It's simple enough and we are early in the -rc cycle still, I think it
> > would be okay for 3.1.
> 
> As far as upstream's concerned, I'm okay with both because libvirt has to add
> another version specific capability enum for this anyway. It's been broken
> since libvirt 4.6.0 where I added egl-headless graphics type. Luckily, even
> though it's far from optimal, a working solution exists, just change the
> permissions on the device.

I'm fine either way too.  So just pick a version, update the doc
comments and repost.

thanks,
  Gerd




Re: [Qemu-devel] [PATCH v5 19/24] hw: acpi: Retrieve the PCI bus from AcpiPciHpState

2018-11-16 Thread Igor Mammedov
On Mon,  5 Nov 2018 02:40:42 +0100
Samuel Ortiz  wrote:

> From: Sebastien Boeuf 
> 
> Instead of using the machine type specific method find_i440fx() to
> retrieve the PCI bus, this commit aims to rely on the fact that the
> PCI bus is known by the structure AcpiPciHpState.
> 
> When the structure is initialized through acpi_pcihp_init() call,
> it saves the PCI bus, which means there is no need to invoke a
> special function later on.
> 
> Based on the fact that find_i440fx() was only used there, this
> patch also removes the function find_i440fx() itself from the
> entire codebase.
> 
> Reviewed-by: Philippe Mathieu-Daudé 
> Tested-by: Philippe Mathieu-Daudé 
> Signed-off-by: Sebastien Boeuf 
> Signed-off-by: Jing Liu 
Thanks for cleaning it up

minor nit:
Taking in account that you're removing '/* TODO: Q35 support */'
comment along with find_i440fx(), it might be worth to mention
in this commit message. Something along lines that ACPI PCIHP
exist to support guests without SHPC support on PCI
based PC machine. Considering that Q35 provides native
PCI-E hotplug, there is no need to add ACPI hotplug there.


with commit message fixed

Reviewed-by: Igor Mammedov 

> ---
>  include/hw/i386/pc.h  |  1 -
>  hw/acpi/pcihp.c   | 10 --
>  hw/pci-host/piix.c|  8 
>  stubs/pci-host-piix.c |  6 --
>  stubs/Makefile.objs   |  1 -
>  5 files changed, 4 insertions(+), 22 deletions(-)
>  delete mode 100644 stubs/pci-host-piix.c
> 
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index 44cb6bf3f3..8e5f1464eb 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -255,7 +255,6 @@ PCIBus *i440fx_init(const char *host_type, const char 
> *pci_type,
>  MemoryRegion *pci_memory,
>  MemoryRegion *ram_memory);
>  
> -PCIBus *find_i440fx(void);
>  /* piix4.c */
>  extern PCIDevice *piix4_dev;
>  int piix4_init(PCIBus *bus, ISABus **isa_bus, int devfn);
> diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
> index 80d42e12ff..254b2e50ab 100644
> --- a/hw/acpi/pcihp.c
> +++ b/hw/acpi/pcihp.c
> @@ -93,10 +93,9 @@ static void *acpi_set_bsel(PCIBus *bus, void *opaque)
>  return bsel_alloc;
>  }
>  
> -static void acpi_set_pci_info(void)
> +static void acpi_set_pci_info(AcpiPciHpState *s)
>  {
>  static bool bsel_is_set;
> -PCIBus *bus;
>  unsigned bsel_alloc = ACPI_PCIHP_BSEL_DEFAULT;
>  
>  if (bsel_is_set) {
> @@ -104,10 +103,9 @@ static void acpi_set_pci_info(void)
>  }
>  bsel_is_set = true;
>  
> -bus = find_i440fx(); /* TODO: Q35 support */
> -if (bus) {
> +if (s->root) {
>  /* Scan all PCI buses. Set property to enable acpi based hotplug. */
> -pci_for_each_bus_depth_first(bus, acpi_set_bsel, NULL, _alloc);
> +pci_for_each_bus_depth_first(s->root, acpi_set_bsel, NULL, 
> _alloc);
>  }
>  }
>  
> @@ -213,7 +211,7 @@ static void acpi_pcihp_update(AcpiPciHpState *s)
>  
>  void acpi_pcihp_reset(AcpiPciHpState *s)
>  {
> -acpi_set_pci_info();
> +acpi_set_pci_info(s);
>  acpi_pcihp_update(s);
>  }
>  
> diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
> index 47293a3915..658460264b 100644
> --- a/hw/pci-host/piix.c
> +++ b/hw/pci-host/piix.c
> @@ -445,14 +445,6 @@ PCIBus *i440fx_init(const char *host_type, const char 
> *pci_type,
>  return b;
>  }
>  
> -PCIBus *find_i440fx(void)
> -{
> -PCIHostState *s = OBJECT_CHECK(PCIHostState,
> -   object_resolve_path("/machine/i440fx", 
> NULL),
> -   TYPE_PCI_HOST_BRIDGE);
> -return s ? s->bus : NULL;
> -}
> -
>  /* PIIX3 PCI to ISA bridge */
>  static void piix3_set_irq_pic(PIIX3State *piix3, int pic_irq)
>  {
> diff --git a/stubs/pci-host-piix.c b/stubs/pci-host-piix.c
> deleted file mode 100644
> index 6ed81b1f21..00
> --- a/stubs/pci-host-piix.c
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -#include "qemu/osdep.h"
> -#include "hw/i386/pc.h"
> -PCIBus *find_i440fx(void)
> -{
> -return NULL;
> -}
> diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
> index 5dd0aeeec6..725f78bedc 100644
> --- a/stubs/Makefile.objs
> +++ b/stubs/Makefile.objs
> @@ -41,6 +41,5 @@ stub-obj-y += pc_madt_cpu_entry.o
>  stub-obj-y += vmgenid.o
>  stub-obj-y += xen-common.o
>  stub-obj-y += xen-hvm.o
> -stub-obj-y += pci-host-piix.o
>  stub-obj-y += ram-block.o
>  stub-obj-y += ramfb.o




[Qemu-devel] [PATCH v5 5/6] fsdev-throttle-qmp: qmp interface for fsdev io throttling

2018-11-16 Thread xiezhide
provides two interfaces:
1. set the IO limits for the required fsdev device
2. query info of all the fsdev devices.

Signed-off-by: xiezhide 
---
 Makefile| 27 -
 Makefile.objs   | 12 --
 fsdev/qemu-fsdev-dummy.c| 11 +
 fsdev/qemu-fsdev-throttle.c | 98 ++---
 fsdev/qemu-fsdev-throttle.h |  6 ++-
 fsdev/qemu-fsdev.c  | 29 ++
 qapi/fsdev.json | 96 
 qapi/qapi-schema.json   |  1 +
 qmp.c   | 13 ++
 9 files changed, 272 insertions(+), 21 deletions(-)
 create mode 100644 qapi/fsdev.json

diff --git a/Makefile b/Makefile
index b546e98..e2c0e92 100644
--- a/Makefile
+++ b/Makefile
@@ -95,6 +95,7 @@ GENERATED_FILES += qapi/qapi-types-block.h 
qapi/qapi-types-block.c
 GENERATED_FILES += qapi/qapi-types-char.h qapi/qapi-types-char.c
 GENERATED_FILES += qapi/qapi-types-common.h qapi/qapi-types-common.c
 GENERATED_FILES += qapi/qapi-types-crypto.h qapi/qapi-types-crypto.c
+GENERATED_FILES += qapi/qapi-types-fsdev.h qapi/qapi-types-fsdev.c
 GENERATED_FILES += qapi/qapi-types-introspect.h qapi/qapi-types-introspect.c
 GENERATED_FILES += qapi/qapi-types-job.h qapi/qapi-types-job.c
 GENERATED_FILES += qapi/qapi-types-migration.h qapi/qapi-types-migration.c
@@ -103,10 +104,10 @@ GENERATED_FILES += qapi/qapi-types-net.h 
qapi/qapi-types-net.c
 GENERATED_FILES += qapi/qapi-types-rocker.h qapi/qapi-types-rocker.c
 GENERATED_FILES += qapi/qapi-types-run-state.h qapi/qapi-types-run-state.c
 GENERATED_FILES += qapi/qapi-types-sockets.h qapi/qapi-types-sockets.c
+GENERATED_FILES += qapi/qapi-types-tlimits.h qapi/qapi-types-tlimits.c
 GENERATED_FILES += qapi/qapi-types-tpm.h qapi/qapi-types-tpm.c
 GENERATED_FILES += qapi/qapi-types-trace.h qapi/qapi-types-trace.c
 GENERATED_FILES += qapi/qapi-types-transaction.h qapi/qapi-types-transaction.c
-GENERATED_FILES += qapi/qapi-types-tlimits.h qapi/qapi-types-tlimits.c
 GENERATED_FILES += qapi/qapi-types-ui.h qapi/qapi-types-ui.c
 GENERATED_FILES += qapi/qapi-builtin-visit.h qapi/qapi-builtin-visit.c
 GENERATED_FILES += qapi/qapi-visit.h qapi/qapi-visit.c
@@ -115,6 +116,7 @@ GENERATED_FILES += qapi/qapi-visit-block.h 
qapi/qapi-visit-block.c
 GENERATED_FILES += qapi/qapi-visit-char.h qapi/qapi-visit-char.c
 GENERATED_FILES += qapi/qapi-visit-common.h qapi/qapi-visit-common.c
 GENERATED_FILES += qapi/qapi-visit-crypto.h qapi/qapi-visit-crypto.c
+GENERATED_FILES += qapi/qapi-visit-fsdev.h qapi/qapi-visit-fsdev.c
 GENERATED_FILES += qapi/qapi-visit-introspect.h qapi/qapi-visit-introspect.c
 GENERATED_FILES += qapi/qapi-visit-job.h qapi/qapi-visit-job.c
 GENERATED_FILES += qapi/qapi-visit-migration.h qapi/qapi-visit-migration.c
@@ -123,10 +125,10 @@ GENERATED_FILES += qapi/qapi-visit-net.h 
qapi/qapi-visit-net.c
 GENERATED_FILES += qapi/qapi-visit-rocker.h qapi/qapi-visit-rocker.c
 GENERATED_FILES += qapi/qapi-visit-run-state.h qapi/qapi-visit-run-state.c
 GENERATED_FILES += qapi/qapi-visit-sockets.h qapi/qapi-visit-sockets.c
+GENERATED_FILES += qapi/qapi-visit-tlimits.h qapi/qapi-visit-tlimits.c
 GENERATED_FILES += qapi/qapi-visit-tpm.h qapi/qapi-visit-tpm.c
 GENERATED_FILES += qapi/qapi-visit-trace.h qapi/qapi-visit-trace.c
 GENERATED_FILES += qapi/qapi-visit-transaction.h qapi/qapi-visit-transaction.c
-GENERATED_FILES += qapi/qapi-visit-tlimits.h qapi/qapi-visit-tlimits.c
 GENERATED_FILES += qapi/qapi-visit-ui.h qapi/qapi-visit-ui.c
 GENERATED_FILES += qapi/qapi-commands.h qapi/qapi-commands.c
 GENERATED_FILES += qapi/qapi-commands-block-core.h 
qapi/qapi-commands-block-core.c
@@ -134,6 +136,7 @@ GENERATED_FILES += qapi/qapi-commands-block.h 
qapi/qapi-commands-block.c
 GENERATED_FILES += qapi/qapi-commands-char.h qapi/qapi-commands-char.c
 GENERATED_FILES += qapi/qapi-commands-common.h qapi/qapi-commands-common.c
 GENERATED_FILES += qapi/qapi-commands-crypto.h qapi/qapi-commands-crypto.c
+GENERATED_FILES += qapi/qapi-commands-fsdev.h qapi/qapi-commands-fsdev.c
 GENERATED_FILES += qapi/qapi-commands-introspect.h 
qapi/qapi-commands-introspect.c
 GENERATED_FILES += qapi/qapi-commands-job.h qapi/qapi-commands-job.c
 GENERATED_FILES += qapi/qapi-commands-migration.h 
qapi/qapi-commands-migration.c
@@ -142,10 +145,10 @@ GENERATED_FILES += qapi/qapi-commands-net.h 
qapi/qapi-commands-net.c
 GENERATED_FILES += qapi/qapi-commands-rocker.h qapi/qapi-commands-rocker.c
 GENERATED_FILES += qapi/qapi-commands-run-state.h 
qapi/qapi-commands-run-state.c
 GENERATED_FILES += qapi/qapi-commands-sockets.h qapi/qapi-commands-sockets.c
+GENERATED_FILES += qapi/qapi-commands-tlimits.h qapi/qapi-commands-tlimits.c
 GENERATED_FILES += qapi/qapi-commands-tpm.h qapi/qapi-commands-tpm.c
 GENERATED_FILES += qapi/qapi-commands-trace.h qapi/qapi-commands-trace.c
 GENERATED_FILES += qapi/qapi-commands-transaction.h 
qapi/qapi-commands-transaction.c
-GENERATED_FILES += qapi/qapi-commands-tlimits.h 

Re: [Qemu-devel] [RFC v1 08/23] riscv: tcg-target: Add support for the constraints

2018-11-16 Thread Richard Henderson
On 11/15/18 11:35 PM, Alistair Francis wrote:
> +case 'L':
> +/* qemu_ld/qemu_st constraint */
> +ct->ct |= TCG_CT_REG;
> +ct->u.regs = 0x;
> +/* qemu_ld/qemu_st uses TCG_REG_TMP0 */
> +#if defined(CONFIG_SOFTMMU)
> +/* tcg_out_tlb_load uses TCG_REG_TMP0/TMP1 and TCG_REG_L0/L1 */
> +/* tcg_regset_reset_reg(ct->u.regs, TCG_REG_TMP0); */
> +/* tcg_regset_reset_reg(ct->u.regs, TCG_REG_TMP1); */
> +tcg_regset_reset_reg(ct->u.regs, TCG_REG_TMP2);

Normally TMP registers are reserved and do not need to be mentioned in
constraints at all.

> +if ((ct & TCG_CT_CONST_S12) && val >= -2048 && val <= 2047) {
> +return 1;
> +}
> +if ((ct & TCG_CT_CONST_N12) && val >= -2047 && val <= 2048) {
> +return 1;
> +}

Clearer as val == sextracttl(val, 0, 12)
and -val == sextracttl(-val, 0, 12)?


r~



Re: [Qemu-devel] [PATCH v4] Add arm SBSA reference machine

2018-11-16 Thread Hongbo Zhang
On Fri, 16 Nov 2018 at 00:21, Peter Maydell  wrote:
>
> On 19 October 2018 at 09:55, Hongbo Zhang  wrote:
> > there are two commit reverts I have to do to boot system currently, these 
> > block not only my new 'sbsa-ref', but also the 'virt'.
> > (other two workarounds can be ignored, they are just for temp using before 
> > firmware porting is fully finished)
> >
> > I am not saying the comments themselves have problem, maybe firmware need 
> > to be adapted accordingly too. But before they are fixed, I just simply 
> > revert them to not block my run.
> > (And, I've mentioned in v3 list that there are still problem of booting SMP 
> > too, but I won't mention it here this time, otherwise this patch/cover 
> > letter becomes too complicated -- at least we can boot one core, I can 
> > fix/discuss it later separately.)
>
> We do need to investigate and at least understand all these issues
> before we can take this new board. Thanks for the repro instructions
> for the virt board.
>
Well, for the SMP booting, when GICv2 used, there is no problem, max
CPU number 8 can be booted, including all the three cases: kernel
only, UEFI+kernel and ATF+UEFI+kernel.

But when GICv3 used, these two cases still work: kernel only, and
UEFI+kernel, but ATF+UEFI+kernel fails booting more than 4 cores with
GICv3.
The original ATF didn't support GICv3, so I added the support:
http://git.linaro.org/people/hongbo.zhang/atf-sbsa.git/log/?h=sbsa_gicv3

Root cause of failing to boot more than 4 cores with ATF+UEFI+kernel
with my GICv3 enabled is due to this:
In QEMU, we have this defination
#define ARM_DEFAULT_CPUS_PER_CLUSTER 8
But in ATF, the defination is
#define PLATFORM_MAX_CPUS_PER_CLUSTER 4
So when we pass smp=6 for example, QEMU generates MPIDR showing all
the 6 cores are at cluster 0, but when ATF parses such MPIDR, the
function plat_core_pos_by_mpidr() in plat/qemu/topology.c returns
error since there should be no more cores than 4.

I think we should change the definition in QEMU to 4, instead of
changing the ATF's, because I checked Cortext a57/a72/a73/a75 spec, it
says there are 4 cores max at one cluster.

> > Steps to reproduce issues:
> > 1. Compile ARMTF
> > make CROSS_COMPILE=aarch64-linux-gnu- PLAT=qemu all DEBUG=1
>
> What source tree do I need to build this EDK ?
>
I use https://github.com/ARM-software/arm-trusted-firmware.git
And you can also use my
http://git.linaro.org/people/hongbo.zhang/atf-sbsa.git/log/?h=sbsa_gicv3
with GICv3 enabled.

Use additional compiling parameter QEMU_USE_GIC_DRIVER to selecct GICv3
"make PLAT=qemu all DEBUG=1 QEMU_USE_GIC_DRIVER=QEMU_GICV3"
No such parameter to select default GICv2
(But I found if you change GICv2 and v3 from time to time when
compiling, the build system may not do the correct changing every
time, so it is better to do a clean before compiling)

> > 2. Compile edk2
> > make -C BaseTools
> > . edksetup.sh
> > export GCC49_AARCH64_PREFIX=aarch64-linux-gnu-
> > build -a AARCH64 -t GCC49 -p ArmVirtPkg/ArmVirtQemuKernel.dsc
> >
> > 3. Run QEMU
> > 3a. copy or link ARMTF and edk2 images to the directory where you want to 
> > launch QEMU
> > bl1.bin -> /home/hongbo/work/arm-trusted-firmware/build/qemu/debug/bl1.bin*
> > bl2.bin -> /home/hongbo/work/arm-trusted-firmware/build/qemu/debug/bl2.bin*
> > bl31.bin -> 
> > /home/hongbo/work/arm-trusted-firmware/build/qemu/debug/bl31.bin*
> > bl33.bin -> 
> > /home/hongbo/work/edk2/Build/ArmVirtQemuKernel-AARCH64/DEBUG_GCC49/FV/QEMU_EFI.fd
> >
> > 3b. command to launch QEMU
> > command1 to load a whole system
> > qemu-system-aarch64 -machine virt,secure=on,virtualization=on -cpu 
> > cortex-a57 -m 1024 -bios bl1.bin -semihosting -serial stdio -device 
> > virtio-scsi-device,id=scsi -drive 
> > file=../qemu-imgs/deb9_arm64_netinst_uefi.raw,id=rootimg,if=none -device 
> > scsi-hd,drive=rootimg -netdev user,id=unet -device 
> > virtio-net-device,netdev=unet -net user
> >
> > or command2 simply load a kernel
> > qemu-system-aarch64 -machine virt,secure=on,virtualization=on -cpu 
> > cortex-a57 -m 1024 -bios bl1.bin -semihosting -serial stdio -kernel Image 
> > -initrd xxx -append "root=/dev/xxx console=ttyAMA0"
> >
> > 4a. system halt with error message
> > ASSERT_EFI_ERROR (Status = Not Found)
> > ASSERT [ResetSystemRuntimeDxe] 
> > /home/hongbo/work/edk2/Build/ArmVirtQemuKernel-AARCH64/DEBUG_GCC49/AARCH64/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe/DEBUG/AutoGen.c(370):
> >  !EFI_ERROR (Status)
> >
> > 4b. Revert "device_tree: Increase FDT_MAX_SIZE to 1 MiB"
> > command1 can run further to halt at nother place, see 5a and 5b
> > command2 can load kernel successfully
>
> I'm not sure what's going on here. Some debugging of what the
> assertion is checking and why we've hit it would be required.
> I didn't expect changing FDT_MAX_SIZE would affect much but
> perhaps it changes where the fdt winds up in memory or how
> big it is so it overlaps with something else.
> There is an fdt_pack() function which 

Re: [Qemu-devel] [RFC v1 09/23] riscv: tcg-target: Add the immediate encoders

2018-11-16 Thread Richard Henderson
On 11/15/18 11:35 PM, Alistair Francis wrote:
> +static int32_t encode_simm12(uint32_t imm)
> +{
> +return ((imm << 20) >> 25) << 25 | ((imm << 27) >> 27) << 7;
> +}

I'm not fond of triple shifts like this, as it makes me count.
I'd be ok with a formulation like

return ((imm & 0x1f) << 7) | ((imm & 0xfe) << (25 - 5));

but perhaps best as

uint32_t ret = 0;
ret = deposit32(ret, imm, 7, 5);
ret = deposit32(ret, imm >> 5, 25, 7);

Similarly with encode_sbimm12, encode_uimm20 (which is a simple &), 
encode_ujimm12.


r~



Re: [Qemu-devel] [RFC v1 11/23] riscv: tcg-target: Add the relocation functions

2018-11-16 Thread Richard Henderson
On 11/15/18 11:35 PM, Alistair Francis wrote:
> +static void reloc_sbimm12(tcg_insn_unit *code_ptr, tcg_insn_unit *target)
> +{
> +intptr_t offset = (intptr_t)target - (intptr_t)code_ptr;
> +tcg_debug_assert(offset == sextract32(offset, 1, 12) << 1);
> +
> +code_ptr[0] |= encode_sbimm12(offset);
> +}

FYI, I have an in-flight patch for 4.0 that will make patch_reloc return a bool
for relocation success, which will move these asserts.

http://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg02237.html


> +static void reloc_call(tcg_insn_unit *code_ptr, tcg_insn_unit *target)
> +{
> +intptr_t offset = (intptr_t)target - (intptr_t)code_ptr;
> +tcg_debug_assert(offset == (int32_t)offset);
> +
> +int32_t hi20 = ((offset + 0x800) >> 12) << 12;
> +int32_t lo12 = offset - hi20;
> +
> +code_ptr[0] |= encode_uimm20(hi20);
> +code_ptr[1] |= encode_imm12(lo12);
> +}
> +

This is ok for patching during generation, but it is not ok for
tb_target_set_jmp_target from patch 9.

Will the riscv-32 compiler use a FSTD insn to implement atomic_set for 64-bit?
 If not, you may be just better off using the indirect method.


r~



Re: [Qemu-devel] [RFC v1 15/23] riscv: tcg-target: Add branch and jump instructions

2018-11-16 Thread Richard Henderson
On 11/15/18 11:36 PM, Alistair Francis wrote:
> +static void tcg_out_brcond(TCGContext *s, TCGCond cond, TCGReg arg1,
> +   TCGReg arg2, TCGLabel *l)
> +{
> +RISCVInsn op = tcg_brcond_to_riscv[cond].op;
> +bool swap = tcg_brcond_to_riscv[cond].swap;
> +
> +tcg_out_opc_branch(s, op, swap ? arg2 : arg1, swap ? arg1 : arg2, 0);

You might want to tcg_debug_assert(op != 0) here.

> +if (l->has_value) {
> +reloc_sbimm12(s->code_ptr - 1, l->u.value_ptr);

I'm concerned about the conditional branch range.  +-4K isn't much to work
with.  The minimum we have for other hosts is +-32K.

We have two options: (1) greatly reduce the max size of the TB for this host;
(2) be prepared to emit a 2 insn sequence: conditional branch across
unconditional branch, with forward branches that turn out to be small patched
with a nop.

FWIW, the first case would be done via modification of tcg_op_buf_full.  You
might have to go as low as 500 opcodes, I'm not sure.

> +static inline void tcg_out_goto(TCGContext *s, tcg_insn_unit *target)
> +{
> +ptrdiff_t offset = tcg_pcrel_diff(s, target);
> +tcg_debug_assert(offset == sextract64(offset, 0, 26));
> +tcg_out_opc_jump(s, OPC_JAL, TCG_REG_ZERO, offset);
> +}
> +
> +static inline void tcg_out_goto_long(TCGContext *s, tcg_insn_unit *target)
> +{
> +ptrdiff_t offset = tcg_pcrel_diff(s, target);
> +
> +if (offset == sextract64(offset, 0, 26)) {
> +tcg_out_opc_jump(s, OPC_JAL, TCG_REG_ZERO, offset);
> +} else {
> +tcg_out_movi(s, TCG_TYPE_I64, TCG_REG_TMP0, (intptr_t)target);
> +tcg_out_opc_jump(s, OPC_JAL, TCG_REG_TMP0, 0);
> +}
> +}

How are these to be used?  I guess I'll find out...

> +static void tcg_out_call_int(TCGContext *s, tcg_insn_unit *arg, bool tail)
> +{
> +TCGReg link = tail ? TCG_REG_ZERO : TCG_REG_RA;
> +ptrdiff_t offset = tcg_pcrel_diff(s, arg);
> +if (offset == sextract32(offset, 1, 20) << 1) {

sextract64.

> +/* short jump: -2097150 to 2097152 */
> +tcg_out_opc_jump(s, OPC_JAL, link, offset);
> +} else if (TCG_TARGET_REG_BITS == 32 ||
> +offset == sextract32(offset, 1, 31) << 1) {

sextract64.

> +/* long jump: -2147483646 to 2147483648 */
> +tcg_out_opc_upper(s, OPC_AUIPC, TCG_REG_TMP0, 0);
> +tcg_out_opc_imm(s, OPC_JALR, link, TCG_REG_TMP0, 0);
> +reloc_call(s->code_ptr - 2, arg);
> +} else if (TCG_TARGET_REG_BITS == 64) {
> +/* far jump: 64-bit */
> +tcg_target_long imm = sextract32((tcg_target_long)arg, 0, 12);
> +tcg_target_long base = (tcg_target_long)arg - imm;
> +tcg_out_movi(s, TCG_TYPE_PTR, TCG_REG_TMP0, base);
> +tcg_out_opc_imm(s, OPC_JALR, link, TCG_REG_TMP0, imm);


r~



Re: [Qemu-devel] [PATCH V7 6/6] pvpanic : update pvpanic document

2018-11-16 Thread Andrew Jones
On Fri, Nov 16, 2018 at 06:50:06PM +0800, Peng Hao wrote:
> Add mmio support info in docs/specs/pvpanic.txt.
> 
> Signed-off-by: Peng Hao 
> ---
>  docs/specs/pvpanic.txt | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/specs/pvpanic.txt b/docs/specs/pvpanic.txt
> index c7bbacc..4e1f69d 100644
> --- a/docs/specs/pvpanic.txt
> +++ b/docs/specs/pvpanic.txt
> @@ -1,7 +1,7 @@
>  PVPANIC DEVICE
>  ==
>  
> -pvpanic device is a simulated ISA device, through which a guest panic
> +pvpanic device is a simulated device, through which a guest panic
>  event is sent to qemu, and a QMP event is generated. This allows
>  management apps (e.g. libvirt) to be notified and respond to the event.
>  
> @@ -9,6 +9,13 @@ The management app has the option of waiting for 
> GUEST_PANICKED events,
>  and/or polling for guest-panicked RunState, to learn when the pvpanic
>  device has fired a panic event.
>  
> +Some architectures do not support ioport, just like arm. So add mmio
> +support.

This isn't a commit message it's a document. We shouldn't be using the
word 'add'. Anyway I don't see any reason to put this sentence in the
document at all. It's clear to users of machine types without an ISA
bus that if they want to use this device they'll need a different
interface. Let's just tell them what interfaces this device has, like
what's done below.

> +
> +When pvpanic device is implemented as a ISA device, it supports IOPORT
> +mode. If pvpanic device supports MMIO mode, it will be implemented as
> +a SYSBUS device.

pvpanic _does_ support MMIO mode after this patch series. So the 'If'
doesn't make much sense. You could do something like "Since QEMU v3.1
pvpanic also supports MMIO mode..." though.

> +
>  ISA Interface
>  -
>  
> @@ -19,6 +26,13 @@ Software should set only bits both itself and the device 
> recognize.
>  Currently, only bit 0 is recognized, setting it indicates a guest panic
>  has happened.
>  
> +SYSBUS Interface
> +--

Missing two '--'

> +
> +The SYSBUS interface is similar to the ISA interface except that it uses
> +MMIO. Pvpanic exposes a address space region 0x0907--0x09070001 in 
 ^an[0x907, 0x9070001]

Using the brackets indicates that the addresses are inclusive. I would
also write something like "For example, the arm virt machine could put
the pvpanic device at [0x907, 0x9070001]". That way users see this
is just an example and not guaranteed to stay the same nor need to be
the same for their machines.

And again /Pvpanic/pvpanic/. "pvpanic" is a device name, we shouldn't
change it, not even for grammar.

> +arm virt machine. Currently only the first byte is used.
> +
>  ACPI Interface
>  --
>  
> -- 
> 1.8.3.1
> 
> 

Thanks,
drew



Re: [Qemu-devel] [RFC v8 15/18] hw/arm/virt: Add virtio-iommu to the virt board

2018-11-16 Thread Auger Eric
Hi Jean, Bharat,

On 11/14/18 5:41 PM, Auger Eric wrote:
> Hi Jean,
> 
> On 11/14/18 5:01 PM, Jean-Philippe Brucker wrote:
>> On 09/11/2018 11:29, Eric Auger wrote:
>>> +static void create_virtio_iommu(VirtMachineState *vms,
>>> +const char *pciehb_nodename, PCIBus *bus)
>>> +{
>>> +const char compat[] = "virtio,pci-iommu";
>>> +uint16_t bdf = 0x8; /* 00:01.0 */
>>> +DeviceState *dev;
>>> +char *node;
>>> +
>>> +dev = qdev_create(BUS(bus), TYPE_VIRTIO_IOMMU_PCI);
>>> +object_property_set_bool(OBJECT(dev), true, "realized", _fatal);
>>
>> For the Arm virt platform, should msi_bypass default to false? Otherwise
>> I don't think pass-through to guest userpace will work.
> That's correct. It's a regression compared to v7. I will fix this soon
> while doing the pc machine integration + resv regions flaws you reported
> in the meantime.

The reported issues related to probe requests are fixed in the following
branch:
https://github.com/eauger/qemu/tree/v3.1.0-rc1-virtio-iommu-v0.8.1

This branch was used to test [PATCH v4 0/7] Add virtio-iommu driver

Thanks

Eric

> 
> Thanks!
> 
> Eric
>>
>> Thanks,
>> Jean
>>
> 



Re: [Qemu-devel] [PATCH v6 04/16] gdbstub: add multiprocess support to 'H' and 'T' packets

2018-11-16 Thread Edgar E. Iglesias
On Thu, Nov 15, 2018 at 10:41:55AM +0100, Luc Michel wrote:
> Add a couple of helper functions to cope with GDB threads and processes.
> 
> The gdb_get_process() function looks for a process given a pid.
> 
> The gdb_get_cpu() function returns the CPU corresponding to the (pid,
> tid) pair given as parameters.
> 
> The read_thread_id() function parses the thread-id sent by the peer.
> This function supports the multiprocess extension thread-id syntax.  The
> return value specifies if the parsing failed, or if a special case was
> encountered (all processes or all threads).
> 
> Use them in 'H' and 'T' packets handling to support the multiprocess
> extension.
> 
> Signed-off-by: Luc Michel 
> Reviewed-by: Philippe Mathieu-Daudé 


Hi Luc,



> ---
>  gdbstub.c | 152 +++---
>  1 file changed, 134 insertions(+), 18 deletions(-)
> 
> diff --git a/gdbstub.c b/gdbstub.c
> index 4fbc05dfe3..fa2b7077b2 100644
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -680,10 +680,73 @@ out:
>  #else
>  return s->processes[0].pid;
>  #endif
>  }
>  
> +static GDBProcess *gdb_get_process(const GDBState *s, uint32_t pid)
> +{
> +int i;
> +
> +if (!pid) {
> +/* 0 means any process, we take the first one */
> +return >processes[0];
> +}
> +
> +for (i = 0; i < s->process_num; i++) {
> +if (s->processes[i].pid == pid) {
> +return >processes[i];
> +}
> +}
> +
> +return NULL;
> +}
> +
> +static GDBProcess *gdb_get_cpu_process(const GDBState *s, CPUState *cpu)
> +{
> +return gdb_get_process(s, gdb_get_cpu_pid(s, cpu));
> +}
> +
> +static CPUState *find_cpu(uint32_t thread_id)
> +{
> +CPUState *cpu;
> +
> +CPU_FOREACH(cpu) {
> +if (cpu_gdb_index(cpu) == thread_id) {
> +return cpu;
> +}
> +}
> +
> +return NULL;
> +}
> +
> +static CPUState *gdb_get_cpu(const GDBState *s, uint32_t pid, uint32_t tid)
> +{
> +GDBProcess *process;
> +CPUState *cpu = find_cpu(tid);
> +
> +if (!tid) {
> +/* 0 means any thread, we take the first one */
> +tid = 1;
> +}
> +
> +if (cpu == NULL) {
> +return NULL;
> +}

Not sure about this. If tid is zero, you fix up the wildcard by setting tid to 
one.
Shouldn't you also retry find_cpu(tid) in that case?

Otherwise, tid doesn't seem to be used after the wildcard fixup.

Other than that, I think this looks good:
Reviewed-by: Edgar E. Iglesias 



> +
> +process = gdb_get_cpu_process(s, cpu);
> +
> +if (process->pid != pid) {
> +return NULL;
> +}
> +
> +if (!process->attached) {
> +return NULL;
> +}
> +
> +return cpu;
> +}
> +
>  static const char *get_feature_xml(const char *p, const char **newp,
> CPUClass *cc)
>  {
>  size_t len;
>  int i;
> @@ -936,23 +999,10 @@ static void gdb_set_cpu_pc(GDBState *s, target_ulong pc)
>  
>  cpu_synchronize_state(cpu);
>  cpu_set_pc(cpu, pc);
>  }
>  
> -static CPUState *find_cpu(uint32_t thread_id)
> -{
> -CPUState *cpu;
> -
> -CPU_FOREACH(cpu) {
> -if (cpu_gdb_index(cpu) == thread_id) {
> -return cpu;
> -}
> -}
> -
> -return NULL;
> -}
> -
>  static char *gdb_fmt_thread_id(const GDBState *s, CPUState *cpu,
> char *buf, size_t buf_size)
>  {
>  if (s->multiprocess) {
>  snprintf(buf, buf_size, "p%02x.%02x",
> @@ -962,10 +1012,64 @@ static char *gdb_fmt_thread_id(const GDBState *s, 
> CPUState *cpu,
>  }
>  
>  return buf;
>  }
>  
> +typedef enum GDBThreadIdKind {
> +GDB_ONE_THREAD = 0,
> +GDB_ALL_THREADS, /* One process, all threads */
> +GDB_ALL_PROCESSES,
> +GDB_READ_THREAD_ERR
> +} GDBThreadIdKind;
> +
> +static GDBThreadIdKind read_thread_id(const char *buf, const char **end_buf,
> +  uint32_t *pid, uint32_t *tid)
> +{
> +unsigned long p, t;
> +int ret;
> +
> +if (*buf == 'p') {
> +buf++;
> +ret = qemu_strtoul(buf, , 16, );
> +
> +if (ret) {
> +return GDB_READ_THREAD_ERR;
> +}
> +
> +/* Skip '.' */
> +buf++;
> +} else {
> +p = 1;
> +}
> +
> +ret = qemu_strtoul(buf, , 16, );
> +
> +if (ret) {
> +return GDB_READ_THREAD_ERR;
> +}
> +
> +*end_buf = buf;
> +
> +if (p == -1) {
> +return GDB_ALL_PROCESSES;
> +}
> +
> +if (pid) {
> +*pid = p;
> +}
> +
> +if (t == -1) {
> +return GDB_ALL_THREADS;
> +}
> +
> +if (tid) {
> +*tid = t;
> +}
> +
> +return GDB_ONE_THREAD;
> +}
> +
>  static int is_query_packet(const char *p, const char *query, char separator)
>  {
>  unsigned int query_len = strlen(query);
>  
>  return strncmp(p, query, query_len) == 0 &&
> @@ -1070,16 +1174,18 @@ static int gdb_handle_packet(GDBState *s, const char 
> *line_buf)
>  {
>  

Re: [Qemu-devel] [PATCH v6 05/16] gdbstub: add multiprocess support to vCont packets

2018-11-16 Thread Edgar E. Iglesias
On Thu, Nov 15, 2018 at 10:41:56AM +0100, Luc Michel wrote:
> Add the gdb_first_cpu() and gdb_next_cpu() to iterate over all
> the CPUs in currently attached processes.
> 
> Add the gdb_first_cpu_in_process() and gdb_next_cpu_in_process() to
> iterate over CPUs of a given process.
> 
> Use them to add multiprocess extension support to vCont packets.
> 
> Signed-off-by: Luc Michel 
> Reviewed-by: Philippe Mathieu-Daudé 
> ---
>  gdbstub.c | 117 +++---
>  1 file changed, 102 insertions(+), 15 deletions(-)
> 
> diff --git a/gdbstub.c b/gdbstub.c
> index fa2b7077b2..f1ec3481cb 100644
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -716,10 +716,40 @@ static CPUState *find_cpu(uint32_t thread_id)
>  }
>  
>  return NULL;
>  }
>  
> +static CPUState *get_first_cpu_in_process(const GDBState *s,
> +  GDBProcess *process)
> +{
> +CPUState *cpu;
> +
> +CPU_FOREACH(cpu) {
> +if (gdb_get_cpu_pid(s, cpu) == process->pid) {
> +return cpu;
> +}
> +}
> +
> +return NULL;
> +}
> +
> +static CPUState *gdb_next_cpu_in_process(const GDBState *s, CPUState *cpu)
> +{
> +uint32_t pid = gdb_get_cpu_pid(s, cpu);
> +cpu = CPU_NEXT(cpu);
> +
> +while (cpu) {
> +if (gdb_get_cpu_pid(s, cpu) == pid) {
> +break;
> +}
> +
> +cpu = CPU_NEXT(cpu);
> +}
> +
> +return cpu;
> +}
> +
>  static CPUState *gdb_get_cpu(const GDBState *s, uint32_t pid, uint32_t tid)
>  {
>  GDBProcess *process;
>  CPUState *cpu = find_cpu(tid);
>  
> @@ -743,10 +773,41 @@ static CPUState *gdb_get_cpu(const GDBState *s, 
> uint32_t pid, uint32_t tid)
>  }
>  
>  return cpu;
>  }
>  
> +/* Return the cpu following @cpu, while ignoring
> + * unattached processes.
> + */
> +static CPUState *gdb_next_cpu(const GDBState *s, CPUState *cpu)

Perhaps a better name would be gdb_next_attached_cpu() ?

With that name change:
Reviewed-by: Edgar E. Iglesias 




> +{
> +cpu = CPU_NEXT(cpu);
> +
> +while (cpu) {
> +if (gdb_get_cpu_process(s, cpu)->attached) {
> +break;
> +}
> +
> +cpu = CPU_NEXT(cpu);
> +}
> +
> +return cpu;
> +}
> +
> +/* Return the first attached cpu */
> +static CPUState *gdb_first_cpu(const GDBState *s)
> +{
> +CPUState *cpu = first_cpu;
> +GDBProcess *process = gdb_get_cpu_process(s, cpu);
> +
> +if (!process->attached) {
> +return gdb_next_cpu(s, cpu);
> +}
> +
> +return cpu;
> +}
> +
>  static const char *get_feature_xml(const char *p, const char **newp,
> CPUClass *cc)
>  {
>  size_t len;
>  int i;
> @@ -1081,14 +1142,16 @@ static int is_query_packet(const char *p, const char 
> *query, char separator)
>   * returns -ENOTSUP if a command is unsupported, -EINVAL or -ERANGE if there 
> is
>   * a format error, 0 on success.
>   */
>  static int gdb_handle_vcont(GDBState *s, const char *p)
>  {
> -int res, idx, signal = 0;
> +int res, signal = 0;
>  char cur_action;
>  char *newstates;
>  unsigned long tmp;
> +uint32_t pid, tid;
> +GDBProcess *process;
>  CPUState *cpu;
>  #ifdef CONFIG_USER_ONLY
>  int max_cpus = 1; /* global variable max_cpus exists only in system mode 
> */
>  
>  CPU_FOREACH(cpu) {
> @@ -1127,29 +1190,52 @@ static int gdb_handle_vcont(GDBState *s, const char 
> *p)
>  } else if (cur_action != 'c' && cur_action != 's') {
>  /* unknown/invalid/unsupported command */
>  res = -ENOTSUP;
>  goto out;
>  }
> -/* thread specification. special values: (none), -1 = all; 0 = any */
> -if ((p[0] == ':' && p[1] == '-' && p[2] == '1') || (p[0] != ':')) {
> -if (*p == ':') {
> -p += 3;
> -}
> -for (idx = 0; idx < max_cpus; idx++) {
> -if (newstates[idx] == 1) {
> -newstates[idx] = cur_action;
> +
> +if (*p++ != ':') {
> +res = -ENOTSUP;
> +goto out;
> +}
> +
> +switch (read_thread_id(p, , , )) {
> +case GDB_READ_THREAD_ERR:
> +res = -EINVAL;
> +goto out;
> +
> +case GDB_ALL_PROCESSES:
> +cpu = gdb_first_cpu(s);
> +while (cpu) {
> +if (newstates[cpu->cpu_index] == 1) {
> +newstates[cpu->cpu_index] = cur_action;
>  }
> +
> +cpu = gdb_next_cpu(s, cpu);
>  }
> -} else if (*p == ':') {
> -p++;
> -res = qemu_strtoul(p, , 16, );
> -if (res) {
> +break;
> +
> +case GDB_ALL_THREADS:
> +process = gdb_get_process(s, pid);
> +
> +if (!process->attached) {
> +res = -EINVAL;
>  goto out;
>  }
>  
> -/* 0 means any 

Re: [Qemu-devel] [PATCH v6 09/16] gdbstub: add multiprocess support to gdb_vm_state_change()

2018-11-16 Thread Edgar E. Iglesias
On Thu, Nov 15, 2018 at 10:42:00AM +0100, Luc Michel wrote:
> Add support for multiprocess extension in gdb_vm_state_change()
> function.
> 
> Signed-off-by: Luc Michel 
> Reviewed-by: Philippe Mathieu-Daudé 

Reviewed-by: Edgar E. Iglesias 


> ---
>  gdbstub.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/gdbstub.c b/gdbstub.c
> index 4cbc81ae5b..5df9929f92 100644
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -1713,10 +1713,11 @@ void gdb_set_stop_cpu(CPUState *cpu)
>  static void gdb_vm_state_change(void *opaque, int running, RunState state)
>  {
>  GDBState *s = gdbserver_state;
>  CPUState *cpu = s->c_cpu;
>  char buf[256];
> +char thread_id[16];
>  const char *type;
>  int ret;
>  
>  if (running || s->state == RS_INACTIVE) {
>  return;
> @@ -1724,10 +1725,18 @@ static void gdb_vm_state_change(void *opaque, int 
> running, RunState state)
>  /* Is there a GDB syscall waiting to be sent?  */
>  if (s->current_syscall_cb) {
>  put_packet(s, s->syscall_buf);
>  return;
>  }
> +
> +if (cpu == NULL) {
> +/* No process attached */
> +return;
> +}
> +
> +gdb_fmt_thread_id(s, cpu, thread_id, sizeof(thread_id));
> +
>  switch (state) {
>  case RUN_STATE_DEBUG:
>  if (cpu->watchpoint_hit) {
>  switch (cpu->watchpoint_hit->flags & BP_MEM_ACCESS) {
>  case BP_MEM_READ:
> @@ -1741,12 +1750,12 @@ static void gdb_vm_state_change(void *opaque, int 
> running, RunState state)
>  break;
>  }
>  trace_gdbstub_hit_watchpoint(type, cpu_gdb_index(cpu),
>  (target_ulong)cpu->watchpoint_hit->vaddr);
>  snprintf(buf, sizeof(buf),
> - "T%02xthread:%02x;%swatch:" TARGET_FMT_lx ";",
> - GDB_SIGNAL_TRAP, cpu_gdb_index(cpu), type,
> + "T%02xthread:%s;%swatch:" TARGET_FMT_lx ";",
> + GDB_SIGNAL_TRAP, thread_id, type,
>   (target_ulong)cpu->watchpoint_hit->vaddr);
>  cpu->watchpoint_hit = NULL;
>  goto send_packet;
>  } else {
>  trace_gdbstub_hit_break();
> @@ -1784,11 +1793,11 @@ static void gdb_vm_state_change(void *opaque, int 
> running, RunState state)
>  trace_gdbstub_hit_unknown(state);
>  ret = GDB_SIGNAL_UNKNOWN;
>  break;
>  }
>  gdb_set_stop_cpu(cpu);
> -snprintf(buf, sizeof(buf), "T%02xthread:%02x;", ret, cpu_gdb_index(cpu));
> +snprintf(buf, sizeof(buf), "T%02xthread:%s;", ret, thread_id);
>  
>  send_packet:
>  put_packet(s, buf);
>  
>  /* disable single step if it was enabled */
> -- 
> 2.19.1
> 



Re: [Qemu-devel] [PATCH v6 08/16] gdbstub: add multiprocess support to Xfer:features:read:

2018-11-16 Thread Edgar E. Iglesias
On Thu, Nov 15, 2018 at 10:41:59AM +0100, Luc Michel wrote:
> Change the Xfer:features:read: packet handling to support the
> multiprocess extension. This packet is used to request the XML
> description of the CPU. In multiprocess mode, different descriptions can
> be sent for different processes.
> 
> This function now takes the process to send the description for as a
> parameter, and use a buffer in the process structure to store the
> generated description.
> 
> It takes the first CPU of the process to generate the description.
> 
> Signed-off-by: Luc Michel 
> Reviewed-by: Philippe Mathieu-Daudé 

Reviewed-by: Edgar E. Iglesias 


> ---
>  gdbstub.c | 47 +++
>  1 file changed, 27 insertions(+), 20 deletions(-)
> 
> diff --git a/gdbstub.c b/gdbstub.c
> index 292dee8914..4cbc81ae5b 100644
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -298,10 +298,12 @@ typedef struct GDBRegisterState {
>  } GDBRegisterState;
>  
>  typedef struct GDBProcess {
>  uint32_t pid;
>  bool attached;
> +
> +char target_xml[1024];
>  } GDBProcess;
>  
>  enum RSState {
>  RS_INACTIVE,
>  RS_IDLE,
> @@ -804,55 +806,57 @@ static CPUState *gdb_first_cpu(const GDBState *s)
>  }
>  
>  return cpu;
>  }
>  
> -static const char *get_feature_xml(const char *p, const char **newp,
> -   CPUClass *cc)
> +static const char *get_feature_xml(const GDBState *s, const char *p,
> +   const char **newp, GDBProcess *process)
>  {
>  size_t len;
>  int i;
>  const char *name;
> -static char target_xml[1024];
> +CPUState *cpu = get_first_cpu_in_process(s, process);
> +CPUClass *cc = CPU_GET_CLASS(cpu);
>  
>  len = 0;
>  while (p[len] && p[len] != ':')
>  len++;
>  *newp = p + len;
>  
>  name = NULL;
>  if (strncmp(p, "target.xml", len) == 0) {
> +char *buf = process->target_xml;
> +const size_t buf_sz = sizeof(process->target_xml);
> +
>  /* Generate the XML description for this CPU.  */
> -if (!target_xml[0]) {
> +if (!buf[0]) {
>  GDBRegisterState *r;
> -CPUState *cpu = first_cpu;
>  
> -pstrcat(target_xml, sizeof(target_xml),
> +pstrcat(buf, buf_sz,
>  ""
>  ""
>  "");
>  if (cc->gdb_arch_name) {
>  gchar *arch = cc->gdb_arch_name(cpu);
> -pstrcat(target_xml, sizeof(target_xml), "");
> -pstrcat(target_xml, sizeof(target_xml), arch);
> -pstrcat(target_xml, sizeof(target_xml), "");
> +pstrcat(buf, buf_sz, "");
> +pstrcat(buf, buf_sz, arch);
> +pstrcat(buf, buf_sz, "");
>  g_free(arch);
>  }
> -pstrcat(target_xml, sizeof(target_xml), " -pstrcat(target_xml, sizeof(target_xml), cc->gdb_core_xml_file);
> -pstrcat(target_xml, sizeof(target_xml), "\"/>");
> +pstrcat(buf, buf_sz, " +pstrcat(buf, buf_sz, cc->gdb_core_xml_file);
> +pstrcat(buf, buf_sz, "\"/>");
>  for (r = cpu->gdb_regs; r; r = r->next) {
> -pstrcat(target_xml, sizeof(target_xml), " href=\"");
> -pstrcat(target_xml, sizeof(target_xml), r->xml);
> -pstrcat(target_xml, sizeof(target_xml), "\"/>");
> +pstrcat(buf, buf_sz, " +pstrcat(buf, buf_sz, r->xml);
> +pstrcat(buf, buf_sz, "\"/>");
>  }
> -pstrcat(target_xml, sizeof(target_xml), "");
> +pstrcat(buf, buf_sz, "");
>  }
> -return target_xml;
> +return buf;
>  }
>  if (cc->gdb_get_dynamic_xml) {
> -CPUState *cpu = first_cpu;
>  char *xmlname = g_strndup(p, len);
>  const char *xml = cc->gdb_get_dynamic_xml(cpu, xmlname);
>  
>  g_free(xmlname);
>  if (xml) {
> @@ -1258,10 +1262,11 @@ out:
>  }
>  
>  static int gdb_handle_packet(GDBState *s, const char *line_buf)
>  {
>  CPUState *cpu;
> +GDBProcess *process;
>  CPUClass *cc;
>  const char *p;
>  uint32_t pid, tid;
>  int ch, reg_size, type, res;
>  uint8_t mem_buf[MAX_PACKET_LENGTH];
> @@ -1639,18 +1644,19 @@ static int gdb_handle_packet(GDBState *s, const char 
> *line_buf)
>  }
>  if (strncmp(p, "Xfer:features:read:", 19) == 0) {
>  const char *xml;
>  target_ulong total_len;
>  
> -cc = CPU_GET_CLASS(first_cpu);
> +process = gdb_get_cpu_process(s, s->g_cpu);
> +cc = CPU_GET_CLASS(s->g_cpu);
>  if (cc->gdb_core_xml_file == NULL) {
>  goto unknown_command;
>  }
>  
>  gdb_has_xml = true;
>  p += 19;
> -xml = get_feature_xml(p, , cc);
> +xml 

Re: [Qemu-devel] [PATCH v1 6/9] qapi: rewrite string-input-visitor

2018-11-16 Thread Markus Armbruster
David Hildenbrand  writes:

> The input visitor has some problems right now, especially
> - unsigned type "Range" is used to process signed ranges, resulting in
>   inconsistent behavior and ugly/magical code
> - uint64_t are parsed like int64_t, so big uint64_t values are not
>   supported and error messages are misleading
> - lists/ranges of int64_t are accepted although no list is parsed and
>   we should rather report an error
> - lists/ranges are preparsed using int64_t, making it hard to
>   implement uint64_t values or uint64_t lists
> - types that don't support lists don't bail out
> - visiting beyond the end of a list is not handled properly

  - We don't actually parse lists, we parse *sets*: members are sorted,
and duplicates eliminated

Reproducers for the problems would be nice.  Suggestion, not demand.

>
> So let's rewrite it by getting rid of usage of the type "Range" and
> properly supporting lists of int64_t and uint64_t (including ranges of
> both types), fixing the above mentioned issues.
>
> Lists of other types are not supported and will properly report an
> error. Virtual walks are now supported.
>
> Tests have to be fixed up:
> - Two BUGs were hardcoded that are fixed now
> - The string-input-visitor now actually returns a parsed list and not
>   an ordered set.

I'd expect this to necessitate an update of callers that expect a set, but...

> Signed-off-by: David Hildenbrand 
> ---
>  include/qapi/string-input-visitor.h |   4 +-
>  qapi/string-input-visitor.c | 410 
>  tests/test-string-input-visitor.c   |  18 +-
>  3 files changed, 239 insertions(+), 193 deletions(-)

... there's none.

Let me know if you need help finding them.  I think we tracked them down
during the discussion that led to this series.

>
> diff --git a/include/qapi/string-input-visitor.h 
> b/include/qapi/string-input-visitor.h
> index 33551340e3..921f3875b9 100644
> --- a/include/qapi/string-input-visitor.h
> +++ b/include/qapi/string-input-visitor.h
> @@ -19,8 +19,8 @@ typedef struct StringInputVisitor StringInputVisitor;
>  
>  /*
>   * The string input visitor does not implement support for visiting
> - * QAPI structs, alternates, null, or arbitrary QTypes.  It also
> - * requires a non-null list argument to visit_start_list().
> + * QAPI structs, alternates, null, or arbitrary QTypes. Only flat lists
> + * of integers (except type "size") are supported.
>   */
>  Visitor *string_input_visitor_new(const char *str);
>  
> diff --git a/qapi/string-input-visitor.c b/qapi/string-input-visitor.c
> index b89c6c4e06..4113be01fb 100644
> --- a/qapi/string-input-visitor.c
> +++ b/qapi/string-input-visitor.c
> @@ -4,10 +4,10 @@
>   * Copyright Red Hat, Inc. 2012-2016
>   *
>   * Author: Paolo Bonzini 
> + * David Hildenbrand 
>   *
>   * This work is licensed under the terms of the GNU LGPL, version 2.1 or 
> later.
>   * See the COPYING.LIB file in the top-level directory.
> - *
>   */
>  
>  #include "qemu/osdep.h"
> @@ -18,21 +18,39 @@
>  #include "qapi/qmp/qerror.h"
>  #include "qapi/qmp/qnull.h"
>  #include "qemu/option.h"
> -#include "qemu/queue.h"
> -#include "qemu/range.h"
>  #include "qemu/cutils.h"
>  
> +typedef enum ListMode {
> +/* no list parsing active / no list expected */
> +LM_NONE,
> +/* we have an unparsed string remaining */
> +LM_UNPARSED,
> +/* we have an unfinished int64 range */
> +LM_INT64_RANGE,
> +/* we have an unfinished uint64 range */
> +LM_UINT64_RANGE,
> +/* we have parsed the string completely and no range is remaining */
> +LM_END,
> +} ListMode;
> +
> +typedef union RangeElement {
> +int64_t i64;
> +uint64_t u64;
> +} RangeElement;
>  
>  struct StringInputVisitor
>  {
>  Visitor visitor;
>  
> -GList *ranges;
> -GList *cur_range;
> -int64_t cur;
> +/* List parsing state */
> +ListMode lm;
> +RangeElement rangeNext;
> +RangeElement rangeEnd;
> +const char *unparsed_string;
> +void *list;
>  
> +/* The original string to parse */
>  const char *string;
> -void *list; /* Only needed for sanity checking the caller */
>  };
>  
>  static StringInputVisitor *to_siv(Visitor *v)
> @@ -40,136 +58,43 @@ static StringInputVisitor *to_siv(Visitor *v)
>  return container_of(v, StringInputVisitor, visitor);
>  }
>  
> -static void free_range(void *range, void *dummy)
> -{
> -g_free(range);
> -}
> -
> -static int parse_str(StringInputVisitor *siv, const char *name, Error **errp)
> -{
> -char *str = (char *) siv->string;
> -long long start, end;
> -Range *cur;
> -char *endptr;
> -
> -if (siv->ranges) {
> -return 0;
> -}
> -
> -if (!*str) {
> -return 0;
> -}
> -
> -do {
> -errno = 0;
> -start = strtoll(str, , 0);
> -if (errno == 0 && endptr > str) {
> -if (*endptr == '\0') {
> -cur = g_malloc0(sizeof(*cur));
> -

Re: [Qemu-devel] [PATCH v6 12/16] gdbstub: add support for vAttach packets

2018-11-16 Thread Edgar E. Iglesias
On Thu, Nov 15, 2018 at 10:42:03AM +0100, Luc Michel wrote:
> Add support for the vAttach packets. In multiprocess mode, GDB sends
> them to attach to additional processes.
> 
> Signed-off-by: Luc Michel 

Reviewed-by: Edgar E. Iglesias 


> ---
>  gdbstub.c | 35 +++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/gdbstub.c b/gdbstub.c
> index ada53ac559..0427d1c4f0 100644
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -1340,10 +1340,45 @@ static int gdb_handle_packet(GDBState *s, const char 
> *line_buf)
>  break;
>  }
>  goto unknown_command;
>  }
>  break;
> +} else if (strncmp(p, "Attach;", 7) == 0) {
> +unsigned long pid;
> +
> +p += 7;
> +
> +if (qemu_strtoul(p, , 16, )) {
> +put_packet(s, "E22");
> +break;
> +}
> +
> +process = gdb_get_process(s, pid);
> +
> +if (process == NULL) {
> +put_packet(s, "E22");
> +break;
> +}
> +
> +cpu = get_first_cpu_in_process(s, process);
> +
> +if (cpu == NULL) {
> +/* Refuse to attach an empty process */
> +put_packet(s, "E22");
> +break;
> +}
> +
> +process->attached = true;
> +
> +s->g_cpu = cpu;
> +s->c_cpu = cpu;
> +
> +snprintf(buf, sizeof(buf), "T%02xthread:%s;", GDB_SIGNAL_TRAP,
> + gdb_fmt_thread_id(s, cpu, thread_id, 
> sizeof(thread_id)));
> +
> +put_packet(s, buf);
> +break;
>  } else {
>  goto unknown_command;
>  }
>  case 'k':
>  /* Kill the target */
> -- 
> 2.19.1
> 



[Qemu-devel] [PATCH v2 2/3] ui: Allow specifying 'rendernode' display option for egl-headless

2018-11-16 Thread Erik Skultety
As libvirt can't predict which rendernode QEMU would pick, it
won't adjust the permissions on the device, hence QEMU getting
"Permission denied" when opening the DRI device. Therefore, enable
'rendernode' option for egl-headless display type.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1648236

Signed-off-by: Erik Skultety 
---
 ui/egl-headless.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ui/egl-headless.c b/ui/egl-headless.c
index 42a41310b0..4cf3bbc0e4 100644
--- a/ui/egl-headless.c
+++ b/ui/egl-headless.c
@@ -176,7 +176,7 @@ static void egl_headless_init(DisplayState *ds, 
DisplayOptions *opts)
 egl_dpy *edpy;
 int idx;
 
-if (egl_rendernode_init(NULL, mode) < 0) {
+if (egl_rendernode_init(opts->u.egl_headless.rendernode, mode) < 0) {
 error_report("egl: render node init failed");
 exit(1);
 }
-- 
2.19.1




Re: [Qemu-devel] [PATCH v6 14/16] gdbstub: gdb_set_stop_cpu: ignore request when process is not attached

2018-11-16 Thread Edgar E. Iglesias
On Thu, Nov 15, 2018 at 10:42:05AM +0100, Luc Michel wrote:
> When gdb_set_stop_cpu() is called with a CPU associated to a process
> currently not attached by the GDB client, return without modifying the
> stop CPU. Otherwise, GDB gets confused if it receives packets with a
> thread-id it does not know about.
> 
> Signed-off-by: Luc Michel 
> Acked-by: Alistair Francis 

Reviewed-by: Edgar E. Iglesias 


> ---
>  gdbstub.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/gdbstub.c b/gdbstub.c
> index 59eed3b878..89819a6a72 100644
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -1787,10 +1787,19 @@ static int gdb_handle_packet(GDBState *s, const char 
> *line_buf)
>  return RS_IDLE;
>  }
>  
>  void gdb_set_stop_cpu(CPUState *cpu)
>  {
> +GDBProcess *p = gdb_get_cpu_process(gdbserver_state, cpu);
> +
> +if (!p->attached) {
> +/* Having a stop CPU corresponding to a process that is not attached
> + * confuses GDB. So we ignore the request.
> + */
> +return;
> +}
> +
>  gdbserver_state->c_cpu = cpu;
>  gdbserver_state->g_cpu = cpu;
>  }
>  
>  #ifndef CONFIG_USER_ONLY
> -- 
> 2.19.1
> 



Re: [Qemu-devel] [PATCH v2] qapi: Reduce Makefile boilerplate

2018-11-16 Thread Markus Armbruster
Eric Blake  writes:

> Adding a new qapi module requires some rather tedious repetition to
> wire it into Makefile and Makefile.objs. Add some indirection by
> taking advantage of GNU Make string processing to expand a list
> of module names into all the required artifacts, so that future
> additions of a new module need only touch the list of module names.
>
> The list has to live in Makefile.objs, due to the way that
> unnest-vars slirps in that file without remembering any definition
> of $(QAPI_MODULES) from Makefile.
>
> Signed-off-by: Eric Blake 
>
> ---
> v2: also condense Makefile.objs, prefer $(FOO:%=a%b) over
> %(patsubst %,a%b,$(foo))
> ---
>  Makefile  | 192 ++
>  Makefile.objs |  75 ++--
>  2 files changed, 30 insertions(+), 237 deletions(-)

Lovely diffstat.

Reviewed-by: Markus Armbruster 



Re: [Qemu-devel] [PATCH v6 00/16] gdbstub: support for the multiprocess extension

2018-11-16 Thread Edgar E. Iglesias
On Thu, Nov 15, 2018 at 10:41:51AM +0100, Luc Michel wrote:

Hi Luc,

I think I've either reviewed all of the patches or commented on all now.

Great work!

Thanks,
Edgar


> changes since v5:
>   - patch 1Rebased on top of master
> 
>   - patch 2Cluster ID handling hardening to ensure uint32_t overflow
>won't cause PID 0 to be used [Edgar]
> 
>   - patch 2Fix the GDB process ordering function to avoid uint32_t
>overflow when comparing two cluster_ids [Edgar]
> 
> changes since v4:
>   - patch 1add cpu_cluster.[ch] files into MAINTAINERS Machine core
>section (thanks Eduardo!) [Philippe, Eduardo]
> 
>   - patch 1revert to uint32_t for cluster IDs [Philippe]
> 
>   - patch 1fixed a coding style issue [patchew]
> 
> changes since v3:
>   - patch 1cpu_cluster.h: remove QEMU_ from the multiple includes
>guard #ifdef/#define [Alistair]
> 
>   - patch 1cpu_cluster.c: include osdep.h first [Alistair]
> 
>   - patch 1use uint64_t for cluster ID for prosperity :) [Philippe]
> 
>   - patch 1auto-assign a cluster ID to newly created clusters [Philippe]
> 
>   - patch 2fix mid-code variable declaration [Alistair]
> 
>   - patch 3add a comment in gdb_get_cpu_pid() when retrieving CPU
>parent canonical path [Alistair]
> 
>   - patch 14   fix a typo in the commit message [Alistair]
> 
> changes since v2:
>   - patch 1introducing the cpu-cluster type. I didn't opt for an
>Interface, but I can add one if you think it's necessary.
>For now this class inherits from Device and has a
>cluster-id property, used by the GDB stub to compute a
>PID.
> 
>   - patch 2removed GDB group related code as it has been replaced
>with CPU clusters
> 
>   - patch 2/8  moved GDBProcess target_xml field introduction into patch
>8 [Philippe]
> 
>   - patch 3gdb_get_cpu_pid() now search for CPU being a child of a
>cpu-cluster object. Use the cluster-id to compute the PID.
> 
>   - patch 4gdb_get_process() does not rely on s->processes array
>indices anymore as PIDs can now be sparse. Instead, iterate
>over the array to find the process.
> 
>   - patch 3/4  removed Reviewed-by tags because of substantial changes.
> 
>   - patch 4/7  read_thread_id() hardening [Philippe]
> 
>   - patch 12   safer vAttach packet parsing [Phillipe]
> 
>   - patch 16   put APUs and RPUs in different clusters instead of GDB
>groups
> 
> changes since v1:
>   - rename qemu_get_thread_id() to gdb_fmt_thread_id() [Philippe]
>   - check qemu_strtoul() return value for 'D' packets [Philippe]
> 
> 
> This series adds support for the multiprocess extension of the GDB
> remote protocol in the QEMU GDB stub.
> 
> This extension is useful to split QEMU emulated CPUs in different
> processes from the point of view of the GDB client. It adds the
> possibility to debug different kind of processors (e.g. an AArch64 and
> an ARMv7 CPU) at the same time (it is not possible otherwise since GDB
> expects an SMP view at the thread granularity.
> 
> CPUs are grouped using specially named QOM containers. CPUs that are
> children of such a container are grouped under the same GDB process.
> 
> The last patch groups the CPUs of different model in the zynqmp machines
> into separate processes.
> 
> To test this patchset, you can use the following commands:
> 
> (Note that this requires a recent enough GDB, I think GDB 7.2 is OK.
> Also, it must be compiled to support both ARM and AArch64 architectures)
> 
> Run QEMU: (-smp 6 in xlnx-zcu102 enables both cortex-a53 and cortex-r5
> CPUs)
> 
> qemu-system-aarch64 -M xlnx-zcu102 -gdb tcp::1234 -S -smp 6
> 
> Run the following commands in GDB:
> 
> target extended :1234
> add-inferior
> inferior 2
> attach 2
> info threads
> 
> I want to thanks the Xilinx's QEMU team who sponsored this work for
> their collaboration and their prototype implementation.
> 
> Luc Michel (16):
>   hw/cpu: introduce CPU clusters
>   gdbstub: introduce GDB processes
>   gdbstub: add multiprocess support to '?' packets
>   gdbstub: add multiprocess support to 'H' and 'T' packets
>   gdbstub: add multiprocess support to vCont packets
>   gdbstub: add multiprocess support to 'sC' packets
>   gdbstub: add multiprocess support to (f|s)ThreadInfo and
> ThreadExtraInfo
>   gdbstub: add multiprocess support to Xfer:features:read:
>   gdbstub: add multiprocess support to gdb_vm_state_change()
>   gdbstub: add multiprocess support to 'D' packets
>   gdbstub: add support for extended mode packet
>   gdbstub: add support for vAttach packets
>   gdbstub: processes initialization on new peer connection
>   gdbstub: gdb_set_stop_cpu: ignore request when process is not attached
>   gdbstub: add multiprocess extension support
>   arm/xlnx-zynqmp: put APUs and RPUs in separate CPU 

Re: [Qemu-devel] [PATCH v6 15/16] gdbstub: add multiprocess extension support

2018-11-16 Thread Edgar E. Iglesias
On Thu, Nov 15, 2018 at 10:42:06AM +0100, Luc Michel wrote:
> Add multiprocess extension support by enabling multiprocess mode when
> the peer requests it, and by replying that we actually support it in the
> qSupported reply packet.
> 
> Signed-off-by: Luc Michel 
> Reviewed-by: Philippe Mathieu-Daudé 
> Acked-by: Alistair Francis 

Reviewed-by: Edgar E. Iglesias 



> ---
>  gdbstub.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/gdbstub.c b/gdbstub.c
> index 89819a6a72..e0b844c040 100644
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -1721,10 +1721,16 @@ static int gdb_handle_packet(GDBState *s, const char 
> *line_buf)
>  snprintf(buf, sizeof(buf), "PacketSize=%x", MAX_PACKET_LENGTH);
>  cc = CPU_GET_CLASS(first_cpu);
>  if (cc->gdb_core_xml_file != NULL) {
>  pstrcat(buf, sizeof(buf), ";qXfer:features:read+");
>  }
> +
> +if (strstr(p, "multiprocess+")) {
> +s->multiprocess = true;
> +}
> +pstrcat(buf, sizeof(buf), ";multiprocess+");
> +
>  put_packet(s, buf);
>  break;
>  }
>  if (strncmp(p, "Xfer:features:read:", 19) == 0) {
>  const char *xml;
> -- 
> 2.19.1
> 



Re: [Qemu-devel] [PATCH v2] qapi: Reduce Makefile boilerplate

2018-11-16 Thread Daniel P . Berrangé
On Thu, Nov 15, 2018 at 04:50:52PM -0600, Eric Blake wrote:
> Adding a new qapi module requires some rather tedious repetition to
> wire it into Makefile and Makefile.objs. Add some indirection by
> taking advantage of GNU Make string processing to expand a list
> of module names into all the required artifacts, so that future
> additions of a new module need only touch the list of module names.
> 
> The list has to live in Makefile.objs, due to the way that
> unnest-vars slirps in that file without remembering any definition
> of $(QAPI_MODULES) from Makefile.
> 
> Signed-off-by: Eric Blake 
> 
> ---
> v2: also condense Makefile.objs, prefer $(FOO:%=a%b) over
> %(patsubst %,a%b,$(foo))
> ---
>  Makefile  | 192 ++
>  Makefile.objs |  75 ++--
>  2 files changed, 30 insertions(+), 237 deletions(-)

Reviewed-by: Daniel P. Berrangé 

Though I'd also suggest .gitignore is updated to use wildcards
to exclude the generated files.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|



Re: [Qemu-devel] [PATCH v2 4/4] keymaps: drop support for include files

2018-11-16 Thread Li Qiang
Gerd Hoffmann  于2018年11月16日周五 下午6:43写道:

> Signed-off-by: Gerd Hoffmann 
>

Reviewed-by: Li Qiang 


> ---
>  ui/keymaps.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/ui/keymaps.c b/ui/keymaps.c
> index 085889b555..6e44f738ed 100644
> --- a/ui/keymaps.c
> +++ b/ui/keymaps.c
> @@ -115,10 +115,9 @@ static int parse_keyboard_layout(kbd_layout_t *k,
>  continue;
>  }
>  if (!strncmp(line, "include ", 8)) {
> -if (parse_keyboard_layout(k, table, line + 8, errp) < 0) {
> -ret = -1;
> -goto out;
> -}
> +error_setg(errp, "keymap include files are not supported any
> more");
> +ret = -1;
> +goto out;
>  } else {
>  int offset = 0;
>  while (line[offset] != 0 &&
> --
> 2.9.3
>
>


[Qemu-devel] [PATCH v5 09/36] ppc/xive: notify the CPU when the interrupt priority is more privileged

2018-11-16 Thread Cédric Le Goater
After the event data was pushed in the O/S Event Queue, the IVPE
raises the bit corresponding to the priority of the pending interrupt
in the register IBP (Interrupt Pending Buffer) to indicate there is an
event pending in one of the 8 priority queues. The Pending Interrupt
Priority Register (PIPR) is also updated using the IPB. This register
represent the priority of the most favored pending notification.

The PIPR is then compared to the the Current Processor Priority
Register (CPPR). If it is more favored (numerically less than), the
CPU interrupt line is raised and the EO bit of the Notification Source
Register (NSR) is updated to notify the presence of an exception for
the O/S. The check needs to be done whenever the PIPR or the CPPR are
changed.

The O/S acknowledges the interrupt with a special load in the Thread
Interrupt Management Area. If the EO bit of the NSR is set, the CPPR
takes the value of PIPR. The bit number in the IBP corresponding to
the priority of the pending interrupt is reseted and so is the EO bit
of the NSR.

Signed-off-by: Cédric Le Goater 
---
 hw/intc/xive.c | 94 +-
 1 file changed, 93 insertions(+), 1 deletion(-)

diff --git a/hw/intc/xive.c b/hw/intc/xive.c
index 5ba3b06e6e25..c49932d2b799 100644
--- a/hw/intc/xive.c
+++ b/hw/intc/xive.c
@@ -21,9 +21,73 @@
  * XIVE Thread Interrupt Management context
  */
 
+/* Convert a priority number to an Interrupt Pending Buffer (IPB)
+ * register, which indicates a pending interrupt at the priority
+ * corresponding to the bit number
+ */
+static uint8_t priority_to_ipb(uint8_t priority)
+{
+return priority > XIVE_PRIORITY_MAX ?
+0 : 1 << (XIVE_PRIORITY_MAX - priority);
+}
+
+/* Convert an Interrupt Pending Buffer (IPB) register to a Pending
+ * Interrupt Priority Register (PIPR), which contains the priority of
+ * the most favored pending notification.
+ */
+static uint8_t ipb_to_pipr(uint8_t ibp)
+{
+return ibp ? clz32((uint32_t)ibp << 24) : 0xff;
+}
+
+static void ipb_update(uint8_t *regs, uint8_t priority)
+{
+regs[TM_IPB] |= priority_to_ipb(priority);
+regs[TM_PIPR] = ipb_to_pipr(regs[TM_IPB]);
+}
+
+static uint8_t exception_mask(uint8_t ring)
+{
+switch (ring) {
+case TM_QW1_OS:
+return TM_QW1_NSR_EO;
+default:
+g_assert_not_reached();
+}
+}
+
 static uint64_t xive_tctx_accept(XiveTCTX *tctx, uint8_t ring)
 {
-return 0;
+uint8_t *regs = >regs[ring];
+uint8_t nsr = regs[TM_NSR];
+uint8_t mask = exception_mask(ring);
+
+qemu_irq_lower(tctx->output);
+
+if (regs[TM_NSR] & mask) {
+uint8_t cppr = regs[TM_PIPR];
+
+regs[TM_CPPR] = cppr;
+
+/* Reset the pending buffer bit */
+regs[TM_IPB] &= ~priority_to_ipb(cppr);
+regs[TM_PIPR] = ipb_to_pipr(regs[TM_IPB]);
+
+/* Drop Exception bit */
+regs[TM_NSR] &= ~mask;
+}
+
+return (nsr << 8) | regs[TM_CPPR];
+}
+
+static void xive_tctx_notify(XiveTCTX *tctx, uint8_t ring)
+{
+uint8_t *regs = >regs[ring];
+
+if (regs[TM_PIPR] < regs[TM_CPPR]) {
+regs[TM_NSR] |= exception_mask(ring);
+qemu_irq_raise(tctx->output);
+}
 }
 
 static void xive_tctx_set_cppr(XiveTCTX *tctx, uint8_t ring, uint8_t cppr)
@@ -33,6 +97,9 @@ static void xive_tctx_set_cppr(XiveTCTX *tctx, uint8_t ring, 
uint8_t cppr)
 }
 
 tctx->regs[ring + TM_CPPR] = cppr;
+
+/* CPPR has changed, check if we need to raise a pending exception */
+xive_tctx_notify(tctx, ring);
 }
 
 /*
@@ -198,6 +265,17 @@ static void xive_tm_set_os_cppr(XiveTCTX *tctx, hwaddr 
offset,
 xive_tctx_set_cppr(tctx, TM_QW1_OS, value & 0xff);
 }
 
+/*
+ * Adjust the IPB to allow a CPU to process event queues of other
+ * priorities during one physical interrupt cycle.
+ */
+static void xive_tm_set_os_pending(XiveTCTX *tctx, hwaddr offset,
+   uint64_t value, unsigned size)
+{
+ipb_update(>regs[TM_QW1_OS], value & 0xff);
+xive_tctx_notify(tctx, TM_QW1_OS);
+}
+
 /*
  * Define a mapping of "special" operations depending on the TIMA page
  * offset and the size of the operation.
@@ -220,6 +298,7 @@ static const XiveTmOp xive_tm_operations[] = {
 
 /* MMIOs above 2K : special operations with side effects */
 { XIVE_TM_OS_PAGE, TM_SPC_ACK_OS_REG, 2, NULL, xive_tm_ack_os_reg },
+{ XIVE_TM_OS_PAGE, TM_SPC_SET_OS_PENDING, 1, xive_tm_set_os_pending, NULL 
},
 };
 
 static const XiveTmOp *xive_tm_find_op(hwaddr offset, unsigned size, bool 
write)
@@ -409,6 +488,13 @@ static void xive_tctx_reset(void *dev)
 tctx->regs[TM_QW1_OS + TM_LSMFB] = 0xFF;
 tctx->regs[TM_QW1_OS + TM_ACK_CNT] = 0xFF;
 tctx->regs[TM_QW1_OS + TM_AGE] = 0xFF;
+
+/*
+ * Initialize PIPR to 0xFF to avoid phantom interrupts when the
+ * CPPR is first set.
+ */
+tctx->regs[TM_QW1_OS + TM_PIPR] =
+ipb_to_pipr(tctx->regs[TM_QW1_OS + TM_IPB]);
 }
 
 static void 

[Qemu-devel] [PATCH v5 12/36] spapr: initialize VSMT before initializing the IRQ backend

2018-11-16 Thread Cédric Le Goater
We will need to use xics_max_server_number() to create the sPAPRXive
object modeling the interrupt controller of the machine which is
created before the CPUs.

Signed-off-by: Cédric Le Goater 
---
 hw/ppc/spapr.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 7afd1a175bf2..50cb9f9f4a02 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2466,11 +2466,6 @@ static void spapr_init_cpus(sPAPRMachineState *spapr)
 boot_cores_nr = possible_cpus->len;
 }
 
-/* VSMT must be set in order to be able to compute VCPU ids, ie to
- * call xics_max_server_number() or spapr_vcpu_id().
- */
-spapr_set_vsmt_mode(spapr, _fatal);
-
 if (smc->pre_2_10_has_unused_icps) {
 int i;
 
@@ -2593,6 +2588,11 @@ static void spapr_machine_init(MachineState *machine)
 /* Setup a load limit for the ramdisk leaving room for SLOF and FDT */
 load_limit = MIN(spapr->rma_size, RTAS_MAX_ADDR) - FW_OVERHEAD;
 
+/* VSMT must be set in order to be able to compute VCPU ids, ie to
+ * call xics_max_server_number() or spapr_vcpu_id().
+ */
+spapr_set_vsmt_mode(spapr, _fatal);
+
 /* Set up Interrupt Controller before we create the VCPUs */
 smc->irq->init(spapr, _fatal);
 
-- 
2.17.2




[Qemu-devel] [PATCH v5 15/36] spapr: introdude a new machine IRQ backend for XIVE

2018-11-16 Thread Cédric Le Goater
The XIVE IRQ backend uses the same layout as the new XICS backend but
covers the full range of the IRQ number space. The IRQ numbers for the
CPU IPIs are allocated at the bottom of this space, below 4K, to
preserve compatibility with XICS which does not use that range.

This should be enough given that the maximum number of CPUs is 1024
for the sPAPR machine under QEMU. For the record, the biggest POWER8
or POWER9 system has a maximum of 1536 HW threads (16 sockets, 192
cores, SMT8).

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/spapr.h |   2 +
 include/hw/ppc/spapr_irq.h |   7 ++-
 hw/ppc/spapr.c |   2 +-
 hw/ppc/spapr_irq.c | 119 -
 4 files changed, 124 insertions(+), 6 deletions(-)

diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index 6279711fe8f7..1fbc2663e06c 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -16,6 +16,7 @@ typedef struct sPAPREventLogEntry sPAPREventLogEntry;
 typedef struct sPAPREventSource sPAPREventSource;
 typedef struct sPAPRPendingHPT sPAPRPendingHPT;
 typedef struct ICSState ICSState;
+typedef struct sPAPRXive sPAPRXive;
 
 #define HPTE64_V_HPTE_DIRTY 0x0040ULL
 #define SPAPR_ENTRY_POINT   0x100
@@ -175,6 +176,7 @@ struct sPAPRMachineState {
 const char *icp_type;
 int32_t irq_map_nr;
 unsigned long *irq_map;
+sPAPRXive  *xive;
 
 bool cmd_line_caps[SPAPR_CAP_NUM];
 sPAPRCapabilities def, eff, mig;
diff --git a/include/hw/ppc/spapr_irq.h b/include/hw/ppc/spapr_irq.h
index 0e9229bf219e..c854ae527808 100644
--- a/include/hw/ppc/spapr_irq.h
+++ b/include/hw/ppc/spapr_irq.h
@@ -13,6 +13,7 @@
 /*
  * IRQ range offsets per device type
  */
+#define SPAPR_IRQ_IPI0x0
 #define SPAPR_IRQ_EPOW   0x1000  /* XICS_IRQ_BASE offset */
 #define SPAPR_IRQ_HOTPLUG0x1001
 #define SPAPR_IRQ_VIO0x1100  /* 256 VIO devices */
@@ -33,7 +34,8 @@ typedef struct sPAPRIrq {
 uint32_tnr_irqs;
 uint32_tnr_msis;
 
-void (*init)(sPAPRMachineState *spapr, int nr_irqs, Error **errp);
+void (*init)(sPAPRMachineState *spapr, int nr_irqs, int nr_servers,
+ Error **errp);
 int (*claim)(sPAPRMachineState *spapr, int irq, bool lsi, Error **errp);
 void (*free)(sPAPRMachineState *spapr, int irq, int num);
 qemu_irq (*qirq)(sPAPRMachineState *spapr, int irq);
@@ -42,8 +44,9 @@ typedef struct sPAPRIrq {
 
 extern sPAPRIrq spapr_irq_xics;
 extern sPAPRIrq spapr_irq_xics_legacy;
+extern sPAPRIrq spapr_irq_xive;
 
-void spapr_irq_init(sPAPRMachineState *spapr, Error **errp);
+void spapr_irq_init(sPAPRMachineState *spapr, int nr_servers, Error **errp);
 int spapr_irq_claim(sPAPRMachineState *spapr, int irq, bool lsi, Error **errp);
 void spapr_irq_free(sPAPRMachineState *spapr, int irq, int num);
 qemu_irq spapr_qirq(sPAPRMachineState *spapr, int irq);
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index e470efe7993c..9f8c19e56e7a 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2594,7 +2594,7 @@ static void spapr_machine_init(MachineState *machine)
 spapr_set_vsmt_mode(spapr, _fatal);
 
 /* Set up Interrupt Controller before we create the VCPUs */
-spapr_irq_init(spapr, _fatal);
+spapr_irq_init(spapr, xics_max_server_number(spapr), _fatal);
 
 /* Set up containers for ibm,client-architecture-support negotiated options
  */
diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
index bac45023..2569ae1bc7f8 100644
--- a/hw/ppc/spapr_irq.c
+++ b/hw/ppc/spapr_irq.c
@@ -12,6 +12,7 @@
 #include "qemu/error-report.h"
 #include "qapi/error.h"
 #include "hw/ppc/spapr.h"
+#include "hw/ppc/spapr_xive.h"
 #include "hw/ppc/xics.h"
 #include "sysemu/kvm.h"
 
@@ -91,7 +92,7 @@ error:
 }
 
 static void spapr_irq_init_xics(sPAPRMachineState *spapr, int nr_irqs,
-Error **errp)
+int nr_servers, Error **errp)
 {
 MachineState *machine = MACHINE(spapr);
 Error *local_err = NULL;
@@ -204,10 +205,122 @@ sPAPRIrq spapr_irq_xics = {
 .print_info  = spapr_irq_print_info_xics,
 };
 
+ /*
+ * XIVE IRQ backend.
+ */
+static sPAPRXive *spapr_xive_create(sPAPRMachineState *spapr,
+const char *type_xive, int nr_irqs,
+int nr_servers, Error **errp)
+{
+sPAPRXive *xive;
+Error *local_err = NULL;
+Object *obj;
+uint32_t nr_ends = nr_servers << 3; /* 8 priority ENDs per CPU */
+int i;
+
+obj = object_new(type_xive);
+object_property_set_int(obj, nr_irqs, "nr-irqs", _abort);
+object_property_set_int(obj, nr_ends, "nr-ends", _abort);
+object_property_set_bool(obj, true, "realized", _err);
+if (local_err) {
+error_propagate(errp, local_err);
+return NULL;
+}
+qdev_set_parent_bus(DEVICE(obj), sysbus_get_default());
+xive = SPAPR_XIVE(obj);
+
+/* Enable the CPU IPIs */
+for (i = 0; i < nr_servers; 

[Qemu-devel] [PATCH v5 13/36] spapr: introduce a spapr_irq_init() routine

2018-11-16 Thread Cédric Le Goater
Initialize the MSI bitmap from it as this will be necessary for the
sPAPR IRQ backend for XIVE.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/spapr_irq.h |  1 +
 hw/ppc/spapr.c |  2 +-
 hw/ppc/spapr_irq.c | 16 +++-
 3 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/include/hw/ppc/spapr_irq.h b/include/hw/ppc/spapr_irq.h
index a467ce696ee4..bd7301e6d9c6 100644
--- a/include/hw/ppc/spapr_irq.h
+++ b/include/hw/ppc/spapr_irq.h
@@ -43,6 +43,7 @@ typedef struct sPAPRIrq {
 extern sPAPRIrq spapr_irq_xics;
 extern sPAPRIrq spapr_irq_xics_legacy;
 
+void spapr_irq_init(sPAPRMachineState *spapr, Error **errp);
 int spapr_irq_claim(sPAPRMachineState *spapr, int irq, bool lsi, Error **errp);
 void spapr_irq_free(sPAPRMachineState *spapr, int irq, int num);
 qemu_irq spapr_qirq(sPAPRMachineState *spapr, int irq);
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 50cb9f9f4a02..e470efe7993c 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2594,7 +2594,7 @@ static void spapr_machine_init(MachineState *machine)
 spapr_set_vsmt_mode(spapr, _fatal);
 
 /* Set up Interrupt Controller before we create the VCPUs */
-smc->irq->init(spapr, _fatal);
+spapr_irq_init(spapr, _fatal);
 
 /* Set up containers for ibm,client-architecture-support negotiated options
  */
diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
index e77b94cc685e..f8b651de0ec9 100644
--- a/hw/ppc/spapr_irq.c
+++ b/hw/ppc/spapr_irq.c
@@ -97,11 +97,6 @@ static void spapr_irq_init_xics(sPAPRMachineState *spapr, 
Error **errp)
 int nr_irqs = smc->irq->nr_irqs;
 Error *local_err = NULL;
 
-/* Initialize the MSI IRQ allocator. */
-if (!SPAPR_MACHINE_GET_CLASS(spapr)->legacy_irq_allocation) {
-spapr_irq_msi_init(spapr, smc->irq->nr_msis);
-}
-
 if (kvm_enabled()) {
 if (machine_kernel_irqchip_allowed(machine) &&
 !xics_kvm_init(spapr, _err)) {
@@ -213,6 +208,17 @@ sPAPRIrq spapr_irq_xics = {
 /*
  * sPAPR IRQ frontend routines for devices
  */
+void spapr_irq_init(sPAPRMachineState *spapr, Error **errp)
+{
+sPAPRMachineClass *smc = SPAPR_MACHINE_GET_CLASS(spapr);
+
+/* Initialize the MSI IRQ allocator. */
+if (!SPAPR_MACHINE_GET_CLASS(spapr)->legacy_irq_allocation) {
+spapr_irq_msi_init(spapr, smc->irq->nr_msis);
+}
+
+smc->irq->init(spapr, errp);
+}
 
 int spapr_irq_claim(sPAPRMachineState *spapr, int irq, bool lsi, Error **errp)
 {
-- 
2.17.2




[Qemu-devel] [PATCH v5 06/36] ppc/xive: add support for the END Event State buffers

2018-11-16 Thread Cédric Le Goater
The Event Notification Descriptor also contains two Event State
Buffers providing further coalescing of interrupts, one for the
notification event (ESn) and one for the escalation events (ESe). A
MMIO page is assigned for each to control the EOI through loads
only. Stores are not allowed.

The END ESBs are modeled through an object resembling the 'XiveSource'
It is stateless as the END state bits are backed into the XiveEND
structure under the XiveRouter and the MMIO accesses follow the same
rules as for the standard source ESBs.

END ESBs are not supported by the Linux drivers neither on OPAL nor on
sPAPR. Nevetherless, it provides a mean to study the question in the
future and validates a bit more the XIVE model.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/xive.h |  20 ++
 hw/intc/xive.c| 160 +-
 2 files changed, 178 insertions(+), 2 deletions(-)

diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
index ce62aaf28343..24301bf2076d 100644
--- a/include/hw/ppc/xive.h
+++ b/include/hw/ppc/xive.h
@@ -208,6 +208,26 @@ int xive_router_get_end(XiveRouter *xrtr, uint8_t end_blk, 
uint32_t end_idx,
 int xive_router_set_end(XiveRouter *xrtr, uint8_t end_blk, uint32_t end_idx,
 XiveEND *end);
 
+/*
+ * XIVE END ESBs
+ */
+
+#define TYPE_XIVE_END_SOURCE "xive-end-source"
+#define XIVE_END_SOURCE(obj) \
+OBJECT_CHECK(XiveENDSource, (obj), TYPE_XIVE_END_SOURCE)
+
+typedef struct XiveENDSource {
+SysBusDevice parent;
+
+uint32_tnr_ends;
+
+/* ESB memory region */
+uint32_tesb_shift;
+MemoryRegionesb_mmio;
+
+XiveRouter  *xrtr;
+} XiveENDSource;
+
 /*
  * For legacy compatibility, the exceptions define up to 256 different
  * priorities. P9 implements only 9 levels : 8 active levels [0 - 7]
diff --git a/hw/intc/xive.c b/hw/intc/xive.c
index 9cb001e7b540..5a8882d47a98 100644
--- a/hw/intc/xive.c
+++ b/hw/intc/xive.c
@@ -622,8 +622,18 @@ static void xive_router_end_notify(XiveRouter *xrtr, 
uint8_t end_blk,
  * even futher coalescing in the Router
  */
 if (!(end.w0 & END_W0_UCOND_NOTIFY)) {
-qemu_log_mask(LOG_UNIMP, "XIVE: !UCOND_NOTIFY not implemented\n");
-return;
+uint8_t pq = GETFIELD(END_W1_ESn, end.w1);
+bool notify = xive_esb_trigger();
+
+if (pq != GETFIELD(END_W1_ESn, end.w1)) {
+end.w1 = SETFIELD(END_W1_ESn, end.w1, pq);
+xive_router_set_end(xrtr, end_blk, end_idx, );
+}
+
+/* ESn[Q]=1 : end of notification */
+if (!notify) {
+return;
+}
 }
 
 /*
@@ -706,6 +716,151 @@ void xive_eas_pic_print_info(XiveEAS *eas, uint32_t lisn, 
Monitor *mon)
(uint32_t) GETFIELD(EAS_END_DATA, eas->w));
 }
 
+/*
+ * END ESB MMIO loads
+ */
+static uint64_t xive_end_source_read(void *opaque, hwaddr addr, unsigned size)
+{
+XiveENDSource *xsrc = XIVE_END_SOURCE(opaque);
+XiveRouter *xrtr = xsrc->xrtr;
+uint32_t offset = addr & 0xFFF;
+uint8_t end_blk;
+uint32_t end_idx;
+XiveEND end;
+uint32_t end_esmask;
+uint8_t pq;
+uint64_t ret = -1;
+
+end_blk = xrtr->chip_id;
+end_idx = addr >> (xsrc->esb_shift + 1);
+if (xive_router_get_end(xrtr, end_blk, end_idx, )) {
+qemu_log_mask(LOG_GUEST_ERROR, "XIVE: No END %x/%x\n", end_blk,
+  end_idx);
+return -1;
+}
+
+if (!(end.w0 & END_W0_VALID)) {
+qemu_log_mask(LOG_GUEST_ERROR, "XIVE: END %x/%x is invalid\n",
+  end_blk, end_idx);
+return -1;
+}
+
+end_esmask = addr_is_even(addr, xsrc->esb_shift) ? END_W1_ESn : END_W1_ESe;
+pq = GETFIELD(end_esmask, end.w1);
+
+switch (offset) {
+case XIVE_ESB_LOAD_EOI ... XIVE_ESB_LOAD_EOI + 0x7FF:
+ret = xive_esb_eoi();
+
+/* Forward the source event notification for routing ?? */
+break;
+
+case XIVE_ESB_GET ... XIVE_ESB_GET + 0x3FF:
+ret = pq;
+break;
+
+case XIVE_ESB_SET_PQ_00 ... XIVE_ESB_SET_PQ_00 + 0x0FF:
+case XIVE_ESB_SET_PQ_01 ... XIVE_ESB_SET_PQ_01 + 0x0FF:
+case XIVE_ESB_SET_PQ_10 ... XIVE_ESB_SET_PQ_10 + 0x0FF:
+case XIVE_ESB_SET_PQ_11 ... XIVE_ESB_SET_PQ_11 + 0x0FF:
+ret = xive_esb_set(, (offset >> 8) & 0x3);
+break;
+default:
+qemu_log_mask(LOG_GUEST_ERROR, "XIVE: invalid END ESB load addr %d\n",
+  offset);
+return -1;
+}
+
+if (pq != GETFIELD(end_esmask, end.w1)) {
+end.w1 = SETFIELD(end_esmask, end.w1, pq);
+xive_router_set_end(xrtr, end_blk, end_idx, );
+}
+
+return ret;
+}
+
+/*
+ * END ESB MMIO stores are invalid
+ */
+static void xive_end_source_write(void *opaque, hwaddr addr,
+  uint64_t value, unsigned size)
+{
+qemu_log_mask(LOG_GUEST_ERROR, "XIVE: invalid ESB write addr 0x%"
+  HWADDR_PRIx"\n", addr);
+}

[Qemu-devel] [PATCH v5 21/36] spapr: extend the sPAPR IRQ backend for XICS migration

2018-11-16 Thread Cédric Le Goater
Introduce a new sPAPR IRQ handler to handle resend after migration
when the machine is using a KVM XICS interrupt controller model.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/spapr_irq.h |  2 ++
 hw/ppc/spapr.c | 13 +
 hw/ppc/spapr_irq.c | 27 +++
 3 files changed, 34 insertions(+), 8 deletions(-)

diff --git a/include/hw/ppc/spapr_irq.h b/include/hw/ppc/spapr_irq.h
index b299dd794bff..4e36c0984e1a 100644
--- a/include/hw/ppc/spapr_irq.h
+++ b/include/hw/ppc/spapr_irq.h
@@ -45,6 +45,7 @@ typedef struct sPAPRIrq {
 void *fdt, uint32_t phandle);
 Object *(*cpu_intc_create)(sPAPRMachineState *spapr, Object *cpu,
Error **errp);
+int (*post_load)(sPAPRMachineState *spapr, int version_id);
 } sPAPRIrq;
 
 extern sPAPRIrq spapr_irq_xics;
@@ -55,6 +56,7 @@ void spapr_irq_init(sPAPRMachineState *spapr, int nr_servers, 
Error **errp);
 int spapr_irq_claim(sPAPRMachineState *spapr, int irq, bool lsi, Error **errp);
 void spapr_irq_free(sPAPRMachineState *spapr, int irq, int num);
 qemu_irq spapr_qirq(sPAPRMachineState *spapr, int irq);
+int spapr_irq_post_load(sPAPRMachineState *spapr, int version_id);
 
 /*
  * XICS legacy routines
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 8fbb743769db..f9cf2debff5a 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1738,14 +1738,6 @@ static int spapr_post_load(void *opaque, int version_id)
 return err;
 }
 
-if (!object_dynamic_cast(OBJECT(spapr->ics), TYPE_ICS_KVM)) {
-CPUState *cs;
-CPU_FOREACH(cs) {
-PowerPCCPU *cpu = POWERPC_CPU(cs);
-icp_resend(ICP(cpu->intc));
-}
-}
-
 /* In earlier versions, there was no separate qdev for the PAPR
  * RTC, so the RTC offset was stored directly in sPAPREnvironment.
  * So when migrating from those versions, poke the incoming offset
@@ -1766,6 +1758,11 @@ static int spapr_post_load(void *opaque, int version_id)
 }
 }
 
+err = spapr_irq_post_load(spapr, version_id);
+if (err) {
+return err;
+}
+
 return err;
 }
 
diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
index f6e9e44d4cf9..33dd5da7d255 100644
--- a/hw/ppc/spapr_irq.c
+++ b/hw/ppc/spapr_irq.c
@@ -203,6 +203,18 @@ static Object 
*spapr_irq_cpu_intc_create_xics(sPAPRMachineState *spapr,
 return icp_create(cpu, spapr->icp_type, XICS_FABRIC(spapr), errp);
 }
 
+static int spapr_irq_post_load_xics(sPAPRMachineState *spapr, int version_id)
+{
+if (!object_dynamic_cast(OBJECT(spapr->ics), TYPE_ICS_KVM)) {
+CPUState *cs;
+CPU_FOREACH(cs) {
+PowerPCCPU *cpu = POWERPC_CPU(cs);
+icp_resend(ICP(cpu->intc));
+}
+}
+return 0;
+}
+
 #define SPAPR_IRQ_XICS_NR_IRQS 0x1000
 #define SPAPR_IRQ_XICS_NR_MSIS \
 (XICS_IRQ_BASE + SPAPR_IRQ_XICS_NR_IRQS - SPAPR_IRQ_MSI)
@@ -219,6 +231,7 @@ sPAPRIrq spapr_irq_xics = {
 .print_info  = spapr_irq_print_info_xics,
 .dt_populate = spapr_irq_dt_populate_xics,
 .cpu_intc_create = spapr_irq_cpu_intc_create_xics,
+.post_load   = spapr_irq_post_load_xics,
 };
 
  /*
@@ -331,6 +344,11 @@ static Object 
*spapr_irq_cpu_intc_create_xive(sPAPRMachineState *spapr,
 XIVE_ROUTER(spapr->xive), errp);
 }
 
+static int spapr_irq_post_load_xive(sPAPRMachineState *spapr, int version_id)
+{
+return 0;
+}
+
 /*
  * XIVE uses the full IRQ number space. Set it to 8K to be compatible
  * with XICS.
@@ -351,6 +369,7 @@ sPAPRIrq spapr_irq_xive = {
 .print_info  = spapr_irq_print_info_xive,
 .dt_populate = spapr_irq_dt_populate_xive,
 .cpu_intc_create = spapr_irq_cpu_intc_create_xive,
+.post_load   = spapr_irq_post_load_xive,
 };
 
 /*
@@ -389,6 +408,13 @@ qemu_irq spapr_qirq(sPAPRMachineState *spapr, int irq)
 return smc->irq->qirq(spapr, irq);
 }
 
+int spapr_irq_post_load(sPAPRMachineState *spapr, int version_id)
+{
+sPAPRMachineClass *smc = SPAPR_MACHINE_GET_CLASS(spapr);
+
+return smc->irq->post_load(spapr, version_id);
+}
+
 /*
  * XICS legacy routines - to deprecate one day
  */
@@ -458,4 +484,5 @@ sPAPRIrq spapr_irq_xics_legacy = {
 .print_info  = spapr_irq_print_info_xics,
 .dt_populate = spapr_irq_dt_populate_xics,
 .cpu_intc_create = spapr_irq_cpu_intc_create_xics,
+.post_load   = spapr_irq_post_load_xics,
 };
-- 
2.17.2




[Qemu-devel] [PATCH v5 25/36] spapr: set the interrupt presenter at reset

2018-11-16 Thread Cédric Le Goater
Currently, the interrupt presenter of the VPCU is set at realize
time. Setting it at reset will become useful when the new machine
supporting both interrupt modes is introduced. In this machine, the
interrupt mode is chosen at CAS time and activated after a reset.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/spapr_cpu_core.h |  2 ++
 hw/ppc/spapr_cpu_core.c | 26 ++
 hw/ppc/spapr_irq.c  | 11 +++
 3 files changed, 39 insertions(+)

diff --git a/include/hw/ppc/spapr_cpu_core.h b/include/hw/ppc/spapr_cpu_core.h
index 9e2821e4b31f..fc8ea9021656 100644
--- a/include/hw/ppc/spapr_cpu_core.h
+++ b/include/hw/ppc/spapr_cpu_core.h
@@ -53,4 +53,6 @@ static inline sPAPRCPUState *spapr_cpu_state(PowerPCCPU *cpu)
 return (sPAPRCPUState *)cpu->machine_data;
 }
 
+void spapr_cpu_core_set_intc(PowerPCCPU *cpu, const char *intc_type);
+
 #endif
diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
index 1811cd48db90..529de0b6b9c8 100644
--- a/hw/ppc/spapr_cpu_core.c
+++ b/hw/ppc/spapr_cpu_core.c
@@ -398,3 +398,29 @@ static const TypeInfo spapr_cpu_core_type_infos[] = {
 };
 
 DEFINE_TYPES(spapr_cpu_core_type_infos)
+
+typedef struct ForeachFindIntCArgs {
+const char *intc_type;
+Object *intc;
+} ForeachFindIntCArgs;
+
+static int spapr_cpu_core_find_intc(Object *child, void *opaque)
+{
+ForeachFindIntCArgs *args = opaque;
+
+if (object_dynamic_cast(child, args->intc_type)) {
+args->intc = child;
+}
+
+return args->intc != NULL;
+}
+
+void spapr_cpu_core_set_intc(PowerPCCPU *cpu, const char *intc_type)
+{
+ForeachFindIntCArgs args = { intc_type, NULL };
+
+object_child_foreach(OBJECT(cpu), spapr_cpu_core_find_intc, );
+g_assert(args.intc);
+
+cpu->intc = args.intc;
+}
diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
index 984c6d60cd9f..969efad7e6e9 100644
--- a/hw/ppc/spapr_irq.c
+++ b/hw/ppc/spapr_irq.c
@@ -218,6 +218,11 @@ static int spapr_irq_post_load_xics(sPAPRMachineState 
*spapr, int version_id)
 
 static void spapr_irq_reset_xics(sPAPRMachineState *spapr, Error **errp)
 {
+CPUState *cs;
+
+CPU_FOREACH(cs) {
+spapr_cpu_core_set_intc(POWERPC_CPU(cs), spapr->icp_type);
+}
 }
 
 #define SPAPR_IRQ_XICS_NR_IRQS 0x1000
@@ -370,6 +375,12 @@ static int spapr_irq_post_load_xive(sPAPRMachineState 
*spapr, int version_id)
 
 static void spapr_irq_reset_xive(sPAPRMachineState *spapr, Error **errp)
 {
+CPUState *cs;
+
+CPU_FOREACH(cs) {
+spapr_cpu_core_set_intc(POWERPC_CPU(cs), spapr->xive_tctx_type);
+}
+
 spapr_xive_mmio_map(spapr->xive);
 }
 
-- 
2.17.2




[Qemu-devel] [PATCH v5 20/36] spapr: add classes for the XIVE models

2018-11-16 Thread Cédric Le Goater
The XIVE models for the QEMU and KVM accelerators will have a lot in
common. Introduce an abstract class for the source, the thread context
and the interrupt controller object to handle the differences in the
object initialization. These classes will also be used to define state
synchronization handlers for the monitor and migration usage.

This is very much like the XICS models.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/spapr_xive.h |  15 +
 include/hw/ppc/xive.h   |  30 ++
 hw/intc/spapr_xive.c|  86 +++-
 hw/intc/xive.c  | 109 +---
 hw/ppc/spapr_irq.c  |   4 +-
 5 files changed, 182 insertions(+), 62 deletions(-)

diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
index 5b3fab192d41..aca2969a09ab 100644
--- a/include/hw/ppc/spapr_xive.h
+++ b/include/hw/ppc/spapr_xive.h
@@ -13,6 +13,10 @@
 #include "hw/sysbus.h"
 #include "hw/ppc/xive.h"
 
+#define TYPE_SPAPR_XIVE_BASE "spapr-xive-base"
+#define SPAPR_XIVE_BASE(obj) \
+OBJECT_CHECK(sPAPRXive, (obj), TYPE_SPAPR_XIVE_BASE)
+
 #define TYPE_SPAPR_XIVE "spapr-xive"
 #define SPAPR_XIVE(obj) OBJECT_CHECK(sPAPRXive, (obj), TYPE_SPAPR_XIVE)
 
@@ -38,6 +42,17 @@ typedef struct sPAPRXive {
 MemoryRegion  tm_mmio;
 } sPAPRXive;
 
+#define SPAPR_XIVE_BASE_CLASS(klass) \
+ OBJECT_CLASS_CHECK(sPAPRXiveClass, (klass), TYPE_SPAPR_XIVE_BASE)
+#define SPAPR_XIVE_BASE_GET_CLASS(obj) \
+ OBJECT_GET_CLASS(sPAPRXiveClass, (obj), TYPE_SPAPR_XIVE_BASE)
+
+typedef struct sPAPRXiveClass {
+XiveRouterClass parent_class;
+
+DeviceRealize   parent_realize;
+} sPAPRXiveClass;
+
 bool spapr_xive_irq_enable(sPAPRXive *xive, uint32_t lisn, bool lsi);
 bool spapr_xive_irq_disable(sPAPRXive *xive, uint32_t lisn);
 void spapr_xive_pic_print_info(sPAPRXive *xive, Monitor *mon);
diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
index b74eb326dcd1..281ed370121c 100644
--- a/include/hw/ppc/xive.h
+++ b/include/hw/ppc/xive.h
@@ -38,6 +38,10 @@ typedef struct XiveFabricClass {
  * XIVE Interrupt Source
  */
 
+#define TYPE_XIVE_SOURCE_BASE "xive-source-base"
+#define XIVE_SOURCE_BASE(obj) \
+OBJECT_CHECK(XiveSource, (obj), TYPE_XIVE_SOURCE_BASE)
+
 #define TYPE_XIVE_SOURCE "xive-source"
 #define XIVE_SOURCE(obj) OBJECT_CHECK(XiveSource, (obj), TYPE_XIVE_SOURCE)
 
@@ -68,6 +72,18 @@ typedef struct XiveSource {
 XiveFabric  *xive;
 } XiveSource;
 
+#define XIVE_SOURCE_BASE_CLASS(klass) \
+ OBJECT_CLASS_CHECK(XiveSourceClass, (klass), TYPE_XIVE_SOURCE_BASE)
+#define XIVE_SOURCE_BASE_GET_CLASS(obj) \
+ OBJECT_GET_CLASS(XiveSourceClass, (obj), TYPE_XIVE_SOURCE_BASE)
+
+typedef struct XiveSourceClass {
+SysBusDeviceClass parent_class;
+
+DeviceRealize parent_realize;
+DeviceReset   parent_reset;
+} XiveSourceClass;
+
 /*
  * ESB MMIO setting. Can be one page, for both source triggering and
  * source management, or two different pages. See below for magic
@@ -253,6 +269,9 @@ void xive_end_pic_print_info(XiveEND *end, uint32_t 
end_idx, Monitor *mon);
  * XIVE Thread interrupt Management (TM) context
  */
 
+#define TYPE_XIVE_TCTX_BASE "xive-tctx-base"
+#define XIVE_TCTX_BASE(obj) OBJECT_CHECK(XiveTCTX, (obj), TYPE_XIVE_TCTX_BASE)
+
 #define TYPE_XIVE_TCTX "xive-tctx"
 #define XIVE_TCTX(obj) OBJECT_CHECK(XiveTCTX, (obj), TYPE_XIVE_TCTX)
 
@@ -278,6 +297,17 @@ typedef struct XiveTCTX {
 XiveRouter  *xrtr;
 } XiveTCTX;
 
+#define XIVE_TCTX_BASE_CLASS(klass) \
+ OBJECT_CLASS_CHECK(XiveTCTXClass, (klass), TYPE_XIVE_TCTX_BASE)
+#define XIVE_TCTX_BASE_GET_CLASS(obj) \
+ OBJECT_GET_CLASS(XiveTCTXClass, (obj), TYPE_XIVE_TCTX_BASE)
+
+typedef struct XiveTCTXClass {
+DeviceClass   parent_class;
+
+DeviceRealize parent_realize;
+} XiveTCTXClass;
+
 /*
  * XIVE Thread Interrupt Management Aera (TIMA)
  */
diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
index 3bf77ace11a2..ec85f7e4f88d 100644
--- a/hw/intc/spapr_xive.c
+++ b/hw/intc/spapr_xive.c
@@ -53,9 +53,9 @@ static void spapr_xive_mmio_map(sPAPRXive *xive)
 sysbus_mmio_map(SYS_BUS_DEVICE(xive), 0, xive->tm_base);
 }
 
-static void spapr_xive_reset(DeviceState *dev)
+static void spapr_xive_base_reset(DeviceState *dev)
 {
-sPAPRXive *xive = SPAPR_XIVE(dev);
+sPAPRXive *xive = SPAPR_XIVE_BASE(dev);
 int i;
 
 /* Xive Source reset is done through SysBus, it should put all
@@ -76,9 +76,9 @@ static void spapr_xive_reset(DeviceState *dev)
 spapr_xive_mmio_map(xive);
 }
 
-static void spapr_xive_instance_init(Object *obj)
+static void spapr_xive_base_instance_init(Object *obj)
 {
-sPAPRXive *xive = SPAPR_XIVE(obj);
+sPAPRXive *xive = SPAPR_XIVE_BASE(obj);
 
 object_initialize(>source, sizeof(xive->source), TYPE_XIVE_SOURCE);
 object_property_add_child(obj, "source", OBJECT(>source), NULL);
@@ -89,9 +89,9 @@ static void spapr_xive_instance_init(Object *obj)
   

[Qemu-devel] [PATCH v5 11/36] spapr/xive: use the VCPU id as a NVT identifier

2018-11-16 Thread Cédric Le Goater
The IVPE scans the O/S CAM line of the XIVE thread interrupt contexts
to find a matching Notification Virtual Target (NVT) among the NVTs
dispatched on the HW processor threads.

On a real system, the thread interrupt contexts are updated by the
hypervisor when a Virtual Processor is scheduled to run on a HW
thread. Under QEMU, the model emulates the same behavior by hardwiring
the NVT identifier in the thread context registers at reset.

The NVT identifier used by the sPAPRXive model is the VCPU id. The END
identifier is also derived from the VCPU id. A set of helpers doing
the conversion between identifiers are provided for the hcalls
configuring the sources and the ENDs.

The model does not need a NVT table but The XiveRouter NVT operations
are provided to perform some extra checks in the routing algorithm.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/spapr_xive.h |  17 +
 include/hw/ppc/xive.h   |   3 +
 hw/intc/spapr_xive.c| 136 
 hw/intc/xive.c  |   9 +++
 4 files changed, 165 insertions(+)

diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
index 06727bd86aa9..3f65b8f485fd 100644
--- a/include/hw/ppc/spapr_xive.h
+++ b/include/hw/ppc/spapr_xive.h
@@ -43,4 +43,21 @@ bool spapr_xive_irq_disable(sPAPRXive *xive, uint32_t lisn);
 void spapr_xive_pic_print_info(sPAPRXive *xive, Monitor *mon);
 qemu_irq spapr_xive_qirq(sPAPRXive *xive, uint32_t lisn);
 
+/*
+ * sPAPR NVT and END indexing helpers
+ */
+uint32_t spapr_xive_nvt_to_target(sPAPRXive *xive, uint8_t nvt_blk,
+  uint32_t nvt_idx);
+int spapr_xive_target_to_nvt(sPAPRXive *xive, uint32_t target,
+uint8_t *out_nvt_blk, uint32_t *out_nvt_idx);
+int spapr_xive_cpu_to_nvt(sPAPRXive *xive, PowerPCCPU *cpu,
+  uint8_t *out_nvt_blk, uint32_t *out_nvt_idx);
+
+int spapr_xive_end_to_target(sPAPRXive *xive, uint8_t end_blk, uint32_t 
end_idx,
+ uint32_t *out_server, uint8_t *out_prio);
+int spapr_xive_target_to_end(sPAPRXive *xive, uint32_t target, uint8_t prio,
+ uint8_t *out_end_blk, uint32_t *out_end_idx);
+int spapr_xive_cpu_to_end(sPAPRXive *xive, PowerPCCPU *cpu, uint8_t prio,
+  uint8_t *out_end_blk, uint32_t *out_end_idx);
+
 #endif /* PPC_SPAPR_XIVE_H */
diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
index e715a6c6923d..e6931ddaa83f 100644
--- a/include/hw/ppc/xive.h
+++ b/include/hw/ppc/xive.h
@@ -187,6 +187,8 @@ typedef struct XiveRouter {
 #define XIVE_ROUTER_GET_CLASS(obj)  \
 OBJECT_GET_CLASS(XiveRouterClass, (obj), TYPE_XIVE_ROUTER)
 
+typedef struct XiveTCTX XiveTCTX;
+
 typedef struct XiveRouterClass {
 SysBusDeviceClass parent;
 
@@ -201,6 +203,7 @@ typedef struct XiveRouterClass {
XiveNVT *nvt);
 int (*set_nvt)(XiveRouter *xrtr, uint8_t nvt_blk, uint32_t nvt_idx,
XiveNVT *nvt);
+void (*reset_tctx)(XiveRouter *xrtr, XiveTCTX *tctx);
 } XiveRouterClass;
 
 void xive_eas_pic_print_info(XiveEAS *eas, uint32_t lisn, Monitor *mon);
diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
index 5d038146c08e..3bf77ace11a2 100644
--- a/hw/intc/spapr_xive.c
+++ b/hw/intc/spapr_xive.c
@@ -199,6 +199,139 @@ static int spapr_xive_set_end(XiveRouter *xrtr,
 return 0;
 }
 
+static int spapr_xive_get_nvt(XiveRouter *xrtr,
+  uint8_t nvt_blk, uint32_t nvt_idx, XiveNVT *nvt)
+{
+sPAPRXive *xive = SPAPR_XIVE(xrtr);
+uint32_t vcpu_id = spapr_xive_nvt_to_target(xive, nvt_blk, nvt_idx);
+PowerPCCPU *cpu = spapr_find_cpu(vcpu_id);
+
+if (!cpu) {
+return -1;
+}
+
+/*
+ * sPAPR does not maintain a NVT table. Return that the NVT is
+ * valid if we have found a matching CPU
+ */
+nvt->w0 = NVT_W0_VALID;
+return 0;
+}
+
+static int spapr_xive_set_nvt(XiveRouter *xrtr,
+  uint8_t nvt_blk, uint32_t nvt_idx, XiveNVT *nvt)
+{
+/* no NVT table */
+return 0;
+}
+
+/*
+ * When a Virtual Processor is scheduled to run on a HW thread, the
+ * hypervisor pushes its identifier in the OS CAM line. Under QEMU, we
+ * need to emulate the same behavior.
+ */
+static void spapr_xive_reset_tctx(XiveRouter *xrtr, XiveTCTX *tctx)
+{
+uint8_t  nvt_blk;
+uint32_t nvt_idx;
+uint32_t nvt_cam;
+
+spapr_xive_cpu_to_nvt(SPAPR_XIVE(xrtr), POWERPC_CPU(tctx->cs),
+  _blk, _idx);
+
+nvt_cam = cpu_to_be32(TM_QW1W2_VO | xive_tctx_cam_line(nvt_blk, nvt_idx));
+memcpy(>regs[TM_QW1_OS + TM_WORD2], _cam, 4);
+}
+
+/*
+ * The allocation of VP blocks is a complex operation in OPAL and the
+ * VP identifiers have a relation with the number of HW chips, the
+ * size of the VP blocks, VP grouping, etc. The QEMU sPAPR XIVE
+ * controller model does not have the same constraints and can use a
+ * 

[Qemu-devel] [PATCH v5 31/36] spapr/xive: export the spapr_xive_kvm_init() routine

2018-11-16 Thread Cédric Le Goater
We will need it to initialize the KVM XIVE device globally from the
machine when the XIVE interrupt mode is selected.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/spapr_xive.h | 2 ++
 hw/intc/spapr_xive_kvm.c| 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
index fa7f3d7718da..1d134a681326 100644
--- a/include/hw/ppc/spapr_xive.h
+++ b/include/hw/ppc/spapr_xive.h
@@ -107,4 +107,6 @@ void spapr_xive_mmio_map(sPAPRXive *xive);
 #define TYPE_XIVE_TCTX_KVM   "xive-tctx-kvm"
 #define XIVE_TCTX_KVM(obj)   OBJECT_CHECK(XiveTCTX, (obj), TYPE_XIVE_TCTX_KVM)
 
+void spapr_xive_kvm_init(sPAPRXive *xive, Error **errp);
+
 #endif /* PPC_SPAPR_XIVE_H */
diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
index b9fee4ea240f..cb2aa6e81274 100644
--- a/hw/intc/spapr_xive_kvm.c
+++ b/hw/intc/spapr_xive_kvm.c
@@ -809,7 +809,7 @@ static void spapr_xive_kvm_instance_init(Object *obj)
   NULL);
 }
 
-static void spapr_xive_kvm_init(sPAPRXive *xive, Error **errp)
+void spapr_xive_kvm_init(sPAPRXive *xive, Error **errp)
 {
 Error *local_err = NULL;
 size_t tima_len;
-- 
2.17.2




[Qemu-devel] [PATCH v5 36/36] ppc/pnv: add XIVE support

2018-11-16 Thread Cédric Le Goater
This is simple model of the POWER9 XIVE interrupt controller for the
PowerNV machine. XIVE for baremetal is a complex controller and the
model only addresses the needs of the skiboot firmware.

* Overall architecture

  XIVE Interrupt Controller
  +-+   IPIs
  | +-+ +-+ +-+ |++
  | |VC   | |CQ   | |PC   |> | CORES  |
  | | esb | | | | |> ||
  | | eas | |  Bridge | | |> ||
  | |SC   end | | | | nvt | |||
+--+  | +-+ +++ +-+ |+--+-+-+-+
| RAM  |  +--|--+   | | |
|  | |  | | |
|  | |  | | |
|  |   +-v--v-v-v---+  other
|  <---+   Power Bus+> chips
|  esb |   +---+---++
|  eas |   |   |
|  end |   |   |
|  nvt |   +---++  +---++
+--+   |SC  |  |SC  |
   ||  ||
   | 2-bits |  | 2-bits |
   | local  |  |   VC   |
   ++  ++
 PCIe  NX,NPU,CAPI

  SC: Source Controller (aka. IVSE)
  VC: Virtualization Controller (aka. IVRE)
  CQ: Common Queue (Bridge)
  PC: Presentation Controller (aka. IVPE)

  2-bits: source state machine
 esb: Event State Buffer (Array of PQ bits in an IVSE)
 eas: Event Assignment Structure
 end: Event Notification Descriptor
 nvt: Notification Virtual Target

It is composed of three sub-engines :

  - Interrupt Virtualization Source Engine (IVSE), or Source
Controller (SC). These are found in PCI PHBs, in the PSI host
bridge controller, but also inside the main controller for the
core IPIs and other sub-chips (NX, CAP, NPU) of the
chip/processor. They are configured to feed the IVRE with events.

  - Interrupt Virtualization Routing Engine (IVRE) or Virtualization
Controller (VC). Its job is to match an event source with an Event
Notification Descriptor (END).

  - Interrupt Virtualization Presentation Engine (IVPE) or Presentation
Controller (PC). It maintains the interrupt context state of each
thread and handles the delivery of the external exception to the
thread.

* XIVE internal tables

Each of the sub-engines uses a set of tables to redirect exceptions
from event sources to CPU threads.

 +---+
   User or OS|  EQ   |
   or+-->|entries|
   Hypervisor|   |  ..   |
 Memory  |   +---+
 |   ^
 |   |
   +--+
 |   |
   Hypervisor+--++---+--++---+--+   +--+
 Memory  | ESB  || EAT  || ENDT |   | NVTT |
(skiboot)++-+++-+++-+   +--+
   ^  |^  |^  |   ^
   |  ||  ||  |   |
   +--+
   |  ||  ||  |   |
   |  ||  ||  |   |
 +-|--||--||--|-+   +-|-++--+
 | |  ||  ||  | |   | | tctx||Thread|
IPI or   + +  v+  v+  v |---| +  .. |-> |
   HW events |  |   |   ||  |
 |  IVRE|   | IVPE  |+--+
 +--+   +---+

The IVSE have a 2-bits, P for pending and Q for queued, state machine
for each source that allows events to be triggered. They are stored in
an array, the Event State Buffer (ESB) and controlled by MMIOs.

If the event is let through, the IVRE looks up in the Event Assignment
Structure (EAS) table for an Event Notification Descriptor (END)
configured for the source. Each Event Notification Descriptor defines
a notification path to a CPU and an in-memory Event Queue, in which
will be pushed an EQ data for the OS to pull.

The 

[Qemu-devel] [PATCH v5 29/36] ppc/xics: remove abort() in icp_kvm_init()

2018-11-16 Thread Cédric Le Goater
Replace the abort with an error report which will be handled by the
caller.

Signed-off-by: Cédric Le Goater 
---
 hw/intc/xics_kvm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/intc/xics_kvm.c b/hw/intc/xics_kvm.c
index efad1b19d821..9662e208fa81 100644
--- a/hw/intc/xics_kvm.c
+++ b/hw/intc/xics_kvm.c
@@ -131,7 +131,8 @@ static void icp_kvm_init(ICPState *icp, Error **errp)
 int ret;
 
 if (kernel_xics_fd == -1) {
-abort();
+error_setg(errp, "KVM XICS device is not initialized");
+return;
 }
 
 cs = icp->cs;
-- 
2.17.2




[Qemu-devel] [PATCH v5 16/36] spapr: add hcalls support for the XIVE exploitation interrupt mode

2018-11-16 Thread Cédric Le Goater
The different XIVE virtualization structures (sources and event queues)
are configured with a set of Hypervisor calls :

 - H_INT_GET_SOURCE_INFO

   used to obtain the address of the MMIO page of the Event State
   Buffer (ESB) entry associated with the source.

 - H_INT_SET_SOURCE_CONFIG

   assigns a source to a "target".

 - H_INT_GET_SOURCE_CONFIG

   determines which "target" and "priority" is assigned to a source

 - H_INT_GET_QUEUE_INFO

   returns the address of the notification management page associated
   with the specified "target" and "priority".

 - H_INT_SET_QUEUE_CONFIG

   sets or resets the event queue for a given "target" and "priority".
   It is also used to set the notification configuration associated
   with the queue, only unconditional notification is supported for
   the moment. Reset is performed with a queue size of 0 and queueing
   is disabled in that case.

 - H_INT_GET_QUEUE_CONFIG

   returns the queue settings for a given "target" and "priority".

 - H_INT_RESET

   resets all of the guest's internal interrupt structures to their
   initial state, losing all configuration set via the hcalls
   H_INT_SET_SOURCE_CONFIG and H_INT_SET_QUEUE_CONFIG.

 - H_INT_SYNC

   issue a synchronisation on a source to make sure all notifications
   have reached their queue.

Calls that still need to be addressed :

   H_INT_SET_OS_REPORTING_LINE
   H_INT_GET_OS_REPORTING_LINE

See the code for more documentation on each hcall.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/spapr.h  |  15 +-
 include/hw/ppc/spapr_xive.h |   6 +
 hw/intc/spapr_xive_hcall.c  | 892 
 hw/ppc/spapr_irq.c  |   2 +
 hw/intc/Makefile.objs   |   2 +-
 5 files changed, 915 insertions(+), 2 deletions(-)
 create mode 100644 hw/intc/spapr_xive_hcall.c

diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index 1fbc2663e06c..8415faea7b82 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -452,7 +452,20 @@ struct sPAPRMachineState {
 #define H_INVALIDATE_PID0x378
 #define H_REGISTER_PROC_TBL 0x37C
 #define H_SIGNAL_SYS_RESET  0x380
-#define MAX_HCALL_OPCODEH_SIGNAL_SYS_RESET
+
+#define H_INT_GET_SOURCE_INFO   0x3A8
+#define H_INT_SET_SOURCE_CONFIG 0x3AC
+#define H_INT_GET_SOURCE_CONFIG 0x3B0
+#define H_INT_GET_QUEUE_INFO0x3B4
+#define H_INT_SET_QUEUE_CONFIG  0x3B8
+#define H_INT_GET_QUEUE_CONFIG  0x3BC
+#define H_INT_SET_OS_REPORTING_LINE 0x3C0
+#define H_INT_GET_OS_REPORTING_LINE 0x3C4
+#define H_INT_ESB   0x3C8
+#define H_INT_SYNC  0x3CC
+#define H_INT_RESET 0x3D0
+
+#define MAX_HCALL_OPCODEH_INT_RESET
 
 /* The hcalls above are standardized in PAPR and implemented by pHyp
  * as well.
diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
index 3f65b8f485fd..418511f3dc10 100644
--- a/include/hw/ppc/spapr_xive.h
+++ b/include/hw/ppc/spapr_xive.h
@@ -60,4 +60,10 @@ int spapr_xive_target_to_end(sPAPRXive *xive, uint32_t 
target, uint8_t prio,
 int spapr_xive_cpu_to_end(sPAPRXive *xive, PowerPCCPU *cpu, uint8_t prio,
   uint8_t *out_end_blk, uint32_t *out_end_idx);
 
+bool spapr_xive_priority_is_valid(uint8_t priority);
+
+typedef struct sPAPRMachineState sPAPRMachineState;
+
+void spapr_xive_hcall_init(sPAPRMachineState *spapr);
+
 #endif /* PPC_SPAPR_XIVE_H */
diff --git a/hw/intc/spapr_xive_hcall.c b/hw/intc/spapr_xive_hcall.c
new file mode 100644
index ..52e4e23995f5
--- /dev/null
+++ b/hw/intc/spapr_xive_hcall.c
@@ -0,0 +1,892 @@
+/*
+ * QEMU PowerPC sPAPR XIVE interrupt controller model
+ *
+ * Copyright (c) 2017-2018, IBM Corporation.
+ *
+ * This code is licensed under the GPL version 2 or later. See the
+ * COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/log.h"
+#include "qapi/error.h"
+#include "cpu.h"
+#include "hw/ppc/fdt.h"
+#include "hw/ppc/spapr.h"
+#include "hw/ppc/spapr_xive.h"
+#include "hw/ppc/xive_regs.h"
+#include "monitor/monitor.h"
+
+/*
+ * OPAL uses the priority 7 EQ to automatically escalate interrupts
+ * for all other queues (DD2.X POWER9). So only priorities [0..6] are
+ * available for the guest.
+ */
+bool spapr_xive_priority_is_valid(uint8_t priority)
+{
+switch (priority) {
+case 0 ... 6:
+return true;
+case 7: /* OPAL escalation queue */
+default:
+return false;
+}
+}
+
+/*
+ * The H_INT_GET_SOURCE_INFO hcall() is used to obtain the logical
+ * real address of the MMIO page through which the Event State Buffer
+ * entry associated with the value of the "lisn" parameter is managed.
+ *
+ * Parameters:
+ * Input
+ * - "flags"
+ *   Bits 0-63 reserved
+ * - "lisn" is per "interrupts", "interrupt-map", or
+ *   "ibm,xive-lisn-ranges" properties, or as returned by the
+ *   ibm,query-interrupt-source-number RTAS call, or as returned
+ *   by the H_ALLOCATE_VAS_WINDOW hcall
+ *
+ * Output
+ * - R4: 

[Qemu-devel] [PATCH v5 30/36] spapr: check for KVM IRQ device activation

2018-11-16 Thread Cédric Le Goater
The KVM IRQ device activation will depend on the interrupt mode chosen
at CAS time by the machine and some methods used at reset or by the
migration need to be protected.

Signed-off-by: Cédric Le Goater 
---
 hw/intc/spapr_xive_kvm.c |  5 +
 hw/intc/xics_kvm.c   | 20 
 2 files changed, 25 insertions(+)

diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
index 176083c37d61..b9fee4ea240f 100644
--- a/hw/intc/spapr_xive_kvm.c
+++ b/hw/intc/spapr_xive_kvm.c
@@ -656,6 +656,11 @@ static int spapr_xive_kvm_pre_save(sPAPRXive *xive)
 int i;
 int ret = 0;
 
+/* The KVM XIVE device is not in use */
+if (xive->fd == -1) {
+return 0;
+}
+
 /* Quiesce the sources, to stop the flow of event notifications */
 for (i = 0; i < xsrc->nr_irqs; i++) {
 /*
diff --git a/hw/intc/xics_kvm.c b/hw/intc/xics_kvm.c
index 9662e208fa81..eabc901a4556 100644
--- a/hw/intc/xics_kvm.c
+++ b/hw/intc/xics_kvm.c
@@ -58,6 +58,11 @@ static void icp_get_kvm_state(ICPState *icp)
 uint64_t state;
 int ret;
 
+/* The KVM XICS device is not in use */
+if (kernel_xics_fd == -1) {
+return;
+}
+
 /* ICP for this CPU thread is not in use, exiting */
 if (!icp->cs) {
 return;
@@ -94,6 +99,11 @@ static int icp_set_kvm_state(ICPState *icp, int version_id)
 uint64_t state;
 int ret;
 
+/* The KVM XICS device is not in use */
+if (kernel_xics_fd == -1) {
+return 0;
+}
+
 /* ICP for this CPU thread is not in use, exiting */
 if (!icp->cs) {
 return 0;
@@ -209,6 +219,11 @@ static void ics_get_kvm_state(ICSState *ics)
 uint64_t state;
 int i;
 
+/* The KVM XICS device is not in use */
+if (kernel_xics_fd == -1) {
+return;
+}
+
 for (i = 0; i < ics->nr_irqs; i++) {
 ICSIRQState *irq = >irqs[i];
 
@@ -268,6 +283,11 @@ static int ics_set_kvm_state(ICSState *ics, int version_id)
 int i;
 Error *local_err = NULL;
 
+/* The KVM XICS device is not in use */
+if (kernel_xics_fd == -1) {
+return 0;
+}
+
 for (i = 0; i < ics->nr_irqs; i++) {
 ICSIRQState *irq = >irqs[i];
 int ret;
-- 
2.17.2




[Qemu-devel] [PATCH v5 27/36] sysbus: add a sysbus_mmio_unmap() helper

2018-11-16 Thread Cédric Le Goater
This will be used to remove the MMIO regions of the POWER9 XIVE
interrupt controller when the sPAPR machine is reseted.

Signed-off-by: Cédric Le Goater 
---
 include/hw/sysbus.h |  1 +
 hw/core/sysbus.c| 10 ++
 2 files changed, 11 insertions(+)

diff --git a/include/hw/sysbus.h b/include/hw/sysbus.h
index 0b59a3b8d605..bc641984b5da 100644
--- a/include/hw/sysbus.h
+++ b/include/hw/sysbus.h
@@ -92,6 +92,7 @@ qemu_irq sysbus_get_connected_irq(SysBusDevice *dev, int n);
 void sysbus_mmio_map(SysBusDevice *dev, int n, hwaddr addr);
 void sysbus_mmio_map_overlap(SysBusDevice *dev, int n, hwaddr addr,
  int priority);
+void sysbus_mmio_unmap(SysBusDevice *dev, int n);
 void sysbus_add_io(SysBusDevice *dev, hwaddr addr,
MemoryRegion *mem);
 MemoryRegion *sysbus_address_space(SysBusDevice *dev);
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
index 7ac36ad3e707..09f202167dcb 100644
--- a/hw/core/sysbus.c
+++ b/hw/core/sysbus.c
@@ -153,6 +153,16 @@ static void sysbus_mmio_map_common(SysBusDevice *dev, int 
n, hwaddr addr,
 }
 }
 
+void sysbus_mmio_unmap(SysBusDevice *dev, int n)
+{
+assert(n >= 0 && n < dev->num_mmio);
+
+if (dev->mmio[n].addr != (hwaddr)-1) {
+memory_region_del_subregion(get_system_memory(), dev->mmio[n].memory);
+dev->mmio[n].addr = (hwaddr)-1;
+}
+}
+
 void sysbus_mmio_map(SysBusDevice *dev, int n, hwaddr addr)
 {
 sysbus_mmio_map_common(dev, n, addr, false, 0);
-- 
2.17.2




Re: [Qemu-devel] [RFC v1 07/23] riscv: tcg-target: Regiser the JIT

2018-11-16 Thread Richard Henderson
On 11/15/18 11:34 PM, Alistair Francis wrote:
> Signed-off-by: Alistair Francis 
> Signed-off-by: Michael Clark 
> ---
>  tcg/riscv/tcg-target.inc.c | 45 ++
>  1 file changed, 45 insertions(+)

I think this whole patch should be merged with the prologue.  They are
interrelated and it's hard to verify this without the other.

Also, FRAME_SIZE isn't defined yet, so this patch isn't even self-contained.


r~



[Qemu-devel] [PATCH v5 6/6] fsdev-throttle-qmp: hmp interface for fsdev io throttling

2018-11-16 Thread xiezhide
introduces io throttling hmp interfaces for the fsdev devices

Signed-off-by: xiezhide 
---
 hmp-commands-info.hx | 15 ++
 hmp-commands.hx  | 15 ++
 hmp.c| 81 ++--
 hmp.h|  4 +++
 4 files changed, 107 insertions(+), 8 deletions(-)

diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
index cbee8b9..eaf0ff5 100644
--- a/hmp-commands-info.hx
+++ b/hmp-commands-info.hx
@@ -100,6 +100,21 @@ STEXI
 Show progress of ongoing block device operations.
 ETEXI
 
+#if defined(CONFIG_VIRTFS)
+ {
+.name   = "fsdev_iothrottle",
+.args_type  = "",
+.params = "",
+.help   = "show fsdev iothrottle information",
+.cmd= hmp_info_fsdev_iothrottle,
+},
+#endif
+STEXI
+@item info fsdev_iothrottle
+@findex fsdev_iothrottle
+Show fsdev device throttle info.
+ETEXI
+
 {
 .name   = "registers",
 .args_type  = "cpustate_all:-a",
diff --git a/hmp-commands.hx b/hmp-commands.hx
index db0c681..40ca7fe 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1716,6 +1716,21 @@ Change I/O throttle limits for a block drive to 
@var{bps} @var{bps_rd} @var{bps_
 @var{device} can be a block device name, a qdev ID or a QOM path.
 ETEXI
 
+#if defined(CONFIG_VIRTFS)
+ {
+.name   = "fsdev_set_io_throttle",
+.args_type  = 
"device:B,bps:l,bps_rd:l,bps_wr:l,iops:l,iops_rd:l,iops_wr:l",
+.params = "device bps bps_rd bps_wr iops iops_rd iops_wr",
+.help   = "change I/O throttle limits for a fs devices",
+.cmd= hmp_fsdev_set_io_throttle,
+},
+#endif
+STEXI
+@item fsdev_set_io_throttle @var{device} @var{bps} @var{bps_rd} @var{bps_wr} 
@var{iops} @var{iops_rd} @var{iops_wr}
+@findex fsdev_set_io_throttle
+Change I/O throttle limits for a fs devices to @var{bps} @var{bps_rd} 
@var{bps_wr} @var{iops} @var{iops_rd} @var{iops_wr}
+ETEXI
+
 {
 .name   = "set_password",
 .args_type  = "protocol:s,password:s,connected:s?",
diff --git a/hmp.c b/hmp.c
index 7828f93..7162d87 100644
--- a/hmp.c
+++ b/hmp.c
@@ -38,6 +38,7 @@
 #include "qapi/qapi-commands-run-state.h"
 #include "qapi/qapi-commands-tpm.h"
 #include "qapi/qapi-commands-ui.h"
+#include "qapi/qapi-commands-fsdev.h"
 #include "qapi/qmp/qdict.h"
 #include "qapi/qmp/qerror.h"
 #include "qapi/string-input-visitor.h"
@@ -1886,18 +1887,22 @@ void hmp_change(Monitor *mon, const QDict *qdict)
 hmp_handle_error(mon, );
 }
 
+static void hmp_initialize_throttle_limits(ThrottleLimits *iot,
+   const QDict *qdict)
+{
+iot->bps = qdict_get_int(qdict, "bps");
+iot->bps_rd = qdict_get_int(qdict, "bps_rd");
+iot->bps_wr = qdict_get_int(qdict, "bps_wr");
+iot->iops = qdict_get_int(qdict, "iops");
+iot->iops_rd = qdict_get_int(qdict, "iops_rd");
+iot->iops_wr = qdict_get_int(qdict, "iops_wr");
+}
+
 void hmp_block_set_io_throttle(Monitor *mon, const QDict *qdict)
 {
 Error *err = NULL;
 char *device = (char *) qdict_get_str(qdict, "device");
-BlockIOThrottle throttle = {
-.bps = qdict_get_int(qdict, "bps"),
-.bps_rd = qdict_get_int(qdict, "bps_rd"),
-.bps_wr = qdict_get_int(qdict, "bps_wr"),
-.iops = qdict_get_int(qdict, "iops"),
-.iops_rd = qdict_get_int(qdict, "iops_rd"),
-.iops_wr = qdict_get_int(qdict, "iops_wr"),
-};
+BlockIOThrottle throttle = {0};
 
 /* qmp_block_set_io_throttle has separate parameters for the
  * (deprecated) block device name and the qdev ID but the HMP
@@ -1910,10 +1915,70 @@ void hmp_block_set_io_throttle(Monitor *mon, const 
QDict *qdict)
 throttle.id = device;
 }
 
+hmp_initialize_throttle_limits(qapi_BlockIOThrottle_base(), 
qdict);
 qmp_block_set_io_throttle(, );
 hmp_handle_error(mon, );
 }
 
+#ifdef CONFIG_VIRTFS
+void hmp_fsdev_set_io_throttle(Monitor *mon, const QDict *qdict)
+{
+Error *err = NULL;
+ThrottleLimits *tlimits;
+FsdevIOThrottle throttle = {
+.has_id = true,
+.id = (char *) qdict_get_str(qdict, "device"),
+};
+
+tlimits = qapi_FsdevIOThrottle_base();
+hmp_initialize_throttle_limits(tlimits, qdict);
+qmp_fsdev_set_io_throttle(, );
+hmp_handle_error(mon, );
+}
+
+static void print_fsdev_throttle_config(Monitor *mon, FsdevIOThrottle *fscfg)
+{
+monitor_printf(mon, "%s", fscfg->id);
+monitor_printf(mon, "I/O throttling:"
+   " bps=%" PRId64
+   " bps_rd=%" PRId64  " bps_wr=%" PRId64
+   " bps_max=%" PRId64
+   " bps_rd_max=%" PRId64
+   " bps_wr_max=%" PRId64
+   " iops=%" PRId64 " iops_rd=%" PRId64
+   " iops_wr=%" PRId64
+   " iops_max=%" PRId64
+   " iops_rd_max=%" PRId64
+   " iops_wr_max=%" PRId64
+ 

[Qemu-devel] [PATCH v5 4/6] fsdev-throttle-qmp: Move ThrottleLimits into a new file for future reuse

2018-11-16 Thread xiezhide
Move ThrottleLimits into a new file for future reuse.

Signed-off-by: xiezhide 
---
 Makefile  |  9 +
 Makefile.objs |  4 
 qapi/block-core.json  | 49 +--
 qapi/qapi-schema.json |  1 +
 qapi/tlimits.json | 53 +++
 5 files changed, 68 insertions(+), 48 deletions(-)
 create mode 100644 qapi/tlimits.json

diff --git a/Makefile b/Makefile
index f294718..b546e98 100644
--- a/Makefile
+++ b/Makefile
@@ -106,6 +106,7 @@ GENERATED_FILES += qapi/qapi-types-sockets.h 
qapi/qapi-types-sockets.c
 GENERATED_FILES += qapi/qapi-types-tpm.h qapi/qapi-types-tpm.c
 GENERATED_FILES += qapi/qapi-types-trace.h qapi/qapi-types-trace.c
 GENERATED_FILES += qapi/qapi-types-transaction.h qapi/qapi-types-transaction.c
+GENERATED_FILES += qapi/qapi-types-tlimits.h qapi/qapi-types-tlimits.c
 GENERATED_FILES += qapi/qapi-types-ui.h qapi/qapi-types-ui.c
 GENERATED_FILES += qapi/qapi-builtin-visit.h qapi/qapi-builtin-visit.c
 GENERATED_FILES += qapi/qapi-visit.h qapi/qapi-visit.c
@@ -125,6 +126,7 @@ GENERATED_FILES += qapi/qapi-visit-sockets.h 
qapi/qapi-visit-sockets.c
 GENERATED_FILES += qapi/qapi-visit-tpm.h qapi/qapi-visit-tpm.c
 GENERATED_FILES += qapi/qapi-visit-trace.h qapi/qapi-visit-trace.c
 GENERATED_FILES += qapi/qapi-visit-transaction.h qapi/qapi-visit-transaction.c
+GENERATED_FILES += qapi/qapi-visit-tlimits.h qapi/qapi-visit-tlimits.c
 GENERATED_FILES += qapi/qapi-visit-ui.h qapi/qapi-visit-ui.c
 GENERATED_FILES += qapi/qapi-commands.h qapi/qapi-commands.c
 GENERATED_FILES += qapi/qapi-commands-block-core.h 
qapi/qapi-commands-block-core.c
@@ -143,6 +145,7 @@ GENERATED_FILES += qapi/qapi-commands-sockets.h 
qapi/qapi-commands-sockets.c
 GENERATED_FILES += qapi/qapi-commands-tpm.h qapi/qapi-commands-tpm.c
 GENERATED_FILES += qapi/qapi-commands-trace.h qapi/qapi-commands-trace.c
 GENERATED_FILES += qapi/qapi-commands-transaction.h 
qapi/qapi-commands-transaction.c
+GENERATED_FILES += qapi/qapi-commands-tlimits.h qapi/qapi-commands-tlimits.c
 GENERATED_FILES += qapi/qapi-commands-ui.h qapi/qapi-commands-ui.c
 GENERATED_FILES += qapi/qapi-events.h qapi/qapi-events.c
 GENERATED_FILES += qapi/qapi-events-block-core.h qapi/qapi-events-block-core.c
@@ -161,6 +164,7 @@ GENERATED_FILES += qapi/qapi-events-sockets.h 
qapi/qapi-events-sockets.c
 GENERATED_FILES += qapi/qapi-events-tpm.h qapi/qapi-events-tpm.c
 GENERATED_FILES += qapi/qapi-events-trace.h qapi/qapi-events-trace.c
 GENERATED_FILES += qapi/qapi-events-transaction.h 
qapi/qapi-events-transaction.c
+GENERATED_FILES += qapi/qapi-events-tlimits.h qapi/qapi-events-tlimits.c
 GENERATED_FILES += qapi/qapi-events-ui.h qapi/qapi-events-ui.c
 GENERATED_FILES += qapi/qapi-introspect.c qapi/qapi-introspect.h
 GENERATED_FILES += qapi/qapi-doc.texi
@@ -596,6 +600,7 @@ qapi-modules = $(SRC_PATH)/qapi/qapi-schema.json 
$(SRC_PATH)/qapi/common.json \
$(SRC_PATH)/qapi/run-state.json \
$(SRC_PATH)/qapi/sockets.json \
$(SRC_PATH)/qapi/tpm.json \
+   $(SRC_PATH)/qapi/tlimits.json \
$(SRC_PATH)/qapi/trace.json \
$(SRC_PATH)/qapi/transaction.json \
$(SRC_PATH)/qapi/ui.json
@@ -618,6 +623,7 @@ qapi/qapi-types-sockets.c qapi/qapi-types-sockets.h \
 qapi/qapi-types-tpm.c qapi/qapi-types-tpm.h \
 qapi/qapi-types-trace.c qapi/qapi-types-trace.h \
 qapi/qapi-types-transaction.c qapi/qapi-types-transaction.h \
+qapi/qapi-types-tlimits.c qapi/qapi-types-tlimits.h \
 qapi/qapi-types-ui.c qapi/qapi-types-ui.h \
 qapi/qapi-builtin-visit.c qapi/qapi-builtin-visit.h \
 qapi/qapi-visit.c qapi/qapi-visit.h \
@@ -637,6 +643,7 @@ qapi/qapi-visit-sockets.c qapi/qapi-visit-sockets.h \
 qapi/qapi-visit-tpm.c qapi/qapi-visit-tpm.h \
 qapi/qapi-visit-trace.c qapi/qapi-visit-trace.h \
 qapi/qapi-visit-transaction.c qapi/qapi-visit-transaction.h \
+qapi/qapi-visit-tlimits.c qapi/qapi-visit-tlimits.h \
 qapi/qapi-visit-ui.c qapi/qapi-visit-ui.h \
 qapi/qapi-commands.h qapi/qapi-commands.c \
 qapi/qapi-commands-block-core.c qapi/qapi-commands-block-core.h \
@@ -655,6 +662,7 @@ qapi/qapi-commands-sockets.c qapi/qapi-commands-sockets.h \
 qapi/qapi-commands-tpm.c qapi/qapi-commands-tpm.h \
 qapi/qapi-commands-trace.c qapi/qapi-commands-trace.h \
 qapi/qapi-commands-transaction.c qapi/qapi-commands-transaction.h \
+qapi/qapi-commands-tlimits.c qapi/qapi-commands-tlimits.h \
 qapi/qapi-commands-ui.c qapi/qapi-commands-ui.h \
 qapi/qapi-events.c qapi/qapi-events.h \
 qapi/qapi-events-block-core.c qapi/qapi-events-block-core.h \
@@ -673,6 +681,7 @@ qapi/qapi-events-sockets.c qapi/qapi-events-sockets.h \
 qapi/qapi-events-tpm.c qapi/qapi-events-tpm.h \
 qapi/qapi-events-trace.c qapi/qapi-events-trace.h \
 qapi/qapi-events-transaction.c qapi/qapi-events-transaction.h \
+qapi/qapi-events-tlimits.c qapi/qapi-events-tlimits.h \
 qapi/qapi-events-ui.c qapi/qapi-events-ui.h \
 qapi/qapi-introspect.h 

Re: [Qemu-devel] [PATCH for-4.0 00/17] tcg: Move softmmu out-of-line

2018-11-16 Thread Richard Henderson
On 11/16/18 2:13 AM, Emilio G. Cota wrote:
> This allows us to discard most TBs; in the example above,
> we end up *not* discarding only ~70 TBs, that is we end up keeping
> only 70/2500 = 2.8% of the TBs that we'd discard without OOL.

Thanks.

When I apply this I think I'll rename "n_ool_thunks" to "ool_generation".  We
don't care about the absolute count, but any change.


r~



Re: [Qemu-devel] [PATCH v4 2/4] fsdev-throttle-qmp: move struct ThrottleLimits to new file

2018-11-16 Thread xiezhide


-Original Message-
From: Eric Blake [mailto:ebl...@redhat.com] 
Sent: 2018年11月16日 6:03
To: xiezhide ; qemu-devel@nongnu.org
Cc: be...@igalia.com; arm...@redhat.com; zengcanfu 00215970 
; gr...@kaod.org; aneesh.ku...@linux.vnet.ibm.com; 
Jinxuefeng ; Chenhui (Felix, Euler) 

Subject: Re: [Qemu-devel] [PATCH v4 2/4] fsdev-throttle-qmp: move struct 
ThrottleLimits to new file

On 11/15/18 3:41 PM, Eric Blake wrote:
> On 11/15/18 2:55 AM, xiezhide wrote:
>> this patch move ThrottleLimits to new file and rename struct field 
>> with common format
> 
> As written, you need s/move/moves/ and s/rename/renames/ to match the 
> singular actor 'this patch'.  Or, if you stick with my preference for 
> imperative sense, s/this patch move/Move/
> 
> s/to new/to a new/
> 
>>
>> Signed-off-by: xiezhide 
>> ---
> 
>> +++ b/Makefile
>> @@ -106,6 +106,7 @@ GENERATED_FILES += qapi/qapi-types-sockets.h 
>> qapi/qapi-types-sockets.c
>>   GENERATED_FILES += qapi/qapi-types-tpm.h qapi/qapi-types-tpm.c
>>   GENERATED_FILES += qapi/qapi-types-trace.h qapi/qapi-types-trace.c
>>   GENERATED_FILES += qapi/qapi-types-transaction.h 
>> qapi/qapi-types-transaction.c
>> +GENERATED_FILES += qapi/qapi-types-tlimits.h 
>> +qapi/qapi-types-tlimits.c
> 
> tlimits comes before tpm, not after transaction.  (Multiple times in 
> this file)

Or, just apply your patch after mine[1], for a much simpler task of inserting 
'tlimits' in the right place within QAPI_MODULES.

[1] https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg03070.html


Great, it makes the task very simple. thanks

Thanks
Kidd


Re: [Qemu-devel] [PATCH v4 2/4] fsdev-throttle-qmp: move struct ThrottleLimits to new file

2018-11-16 Thread xiezhide


-Original Message-
From: Eric Blake [mailto:ebl...@redhat.com] 
Sent: 2018年11月16日 5:41
To: xiezhide ; qemu-devel@nongnu.org
Cc: gr...@kaod.org; aneesh.ku...@linux.vnet.ibm.com; arm...@redhat.com; 
be...@igalia.com; zengcanfu 00215970 ; Jinxuefeng 
; Chenhui (Felix, Euler) 
Subject: Re: [PATCH v4 2/4] fsdev-throttle-qmp: move struct ThrottleLimits to 
new file

On 11/15/18 2:55 AM, xiezhide wrote:
> this patch move ThrottleLimits to new file and rename struct field 
> with common format

As written, you need s/move/moves/ and s/rename/renames/ to match the singular 
actor 'this patch'.  Or, if you stick with my preference for imperative sense, 
s/this patch move/Move/

s/to new/to a new/

> 
> Signed-off-by: xiezhide 
> ---

> +++ b/Makefile
> @@ -106,6 +106,7 @@ GENERATED_FILES += qapi/qapi-types-sockets.h 
> qapi/qapi-types-sockets.c
>   GENERATED_FILES += qapi/qapi-types-tpm.h qapi/qapi-types-tpm.c
>   GENERATED_FILES += qapi/qapi-types-trace.h qapi/qapi-types-trace.c
>   GENERATED_FILES += qapi/qapi-types-transaction.h 
> qapi/qapi-types-transaction.c
> +GENERATED_FILES += qapi/qapi-types-tlimits.h 
> +qapi/qapi-types-tlimits.c

tlimits comes before tpm, not after transaction.  (Multiple times in this file)

> +++ b/Makefile.objs
> @@ -20,6 +20,7 @@ util-obj-y += qapi/qapi-types-sockets.o
>   util-obj-y += qapi/qapi-types-tpm.o
>   util-obj-y += qapi/qapi-types-trace.o
>   util-obj-y += qapi/qapi-types-transaction.o
> +util-obj-y += qapi/qapi-types-tlimits.o

Here too.


>   { 'struct': 'BlockIOThrottle',
> -  'data': { '*device': 'str', '*id': 'str', 'bps': 'int', 'bps_rd': 'int',
> -'bps_wr': 'int', 'iops': 'int', 'iops_rd': 'int', 'iops_wr': 
> 'int',
> -'*bps_max': 'int', '*bps_rd_max': 'int',
> -'*bps_wr_max': 'int', '*iops_max': 'int',
> -'*iops_rd_max': 'int', '*iops_wr_max': 'int',
> -'*bps_max_length': 'int', '*bps_rd_max_length': 'int',
> -'*bps_wr_max_length': 'int', '*iops_max_length': 'int',
> -'*iops_rd_max_length': 'int', '*iops_wr_max_length': 'int',
> -'*iops_size': 'int', '*group': 'str' } }
> -

> -{ 'struct': 'ThrottleLimits',
> -  'data': { '*iops-total' : 'int', '*iops-total-max' : 'int',
> -'*iops-total-max-length' : 'int', '*iops-read' : 'int',
> -'*iops-read-max' : 'int', '*iops-read-max-length' : 'int',
> -'*iops-write' : 'int', '*iops-write-max' : 'int',
> -'*iops-write-max-length' : 'int', '*bps-total' : 'int',
> -'*bps-total-max' : 'int', '*bps-total-max-length' : 'int',
> -'*bps-read' : 'int', '*bps-read-max' : 'int',
> -'*bps-read-max-length' : 'int', '*bps-write' : 'int',
> -'*bps-write-max' : 'int', '*bps-write-max-length' : 'int',
> -'*iops-size' : 'int' } }
> +  'base': 'ThrottleLimits',
> +  'data': { '*device': 'str', '*id': 'str', '*group': 'str' } }

The old code has QMP using 'bps_wr' for BlockIOThrottle, but 'bps-write' 
for ThrottleLimits. The new code...

> +++ b/qapi/tlimits.json

> +{ 'struct': 'ThrottleLimits',
> +  'data': { '*bps': 'int', '*bps_rd': 'int',
> +'*bps_wr': 'int', '*iops': 'int', '*iops_rd': 'int', '*iops_wr': 
> 'int',
> +'*bps_max': 'int', '*bps_rd_max': 'int',
> +'*bps_wr_max': 'int', '*iops_max': 'int',
> +'*iops_rd_max': 'int', '*iops_wr_max': 'int',
> +'*bps_max_length': 'int', '*bps_rd_max_length': 'int',
> +'*bps_wr_max_length': 'int', '*iops_max_length': 'int',
> +'*iops_rd_max_length': 'int', '*iops_wr_max_length': 'int',
> +'*iops_size': 'int' } }

...is sticking with the BlockIOThrottle naming.  I don't see any use of 
ThrottleLimits in QAPI code (quick check: grep bps-wr qapi/qapi-introspect.c 
comes up empty), so we SHOULD be okay with regards to back-compat.  But I'd 
still split this patch into multiple
pieces: 1. Rename the ThrottleLimits member names (and give justification why 
such rename doesn't break back-compat). 2. Rewrite BlockIOThrottle with 
ThrottleLimits as its base class. 3. Move ThrottleLimits into a new file for 
future reuse.  (Maybe 2 and 3 can be squashed into a single patch)

> diff --git a/util/throttle.c b/util/throttle.c index e7db2ad..b421e33 
> 100644
> --- a/util/throttle.c
> +++ b/util/throttle.c
> @@ -496,98 +496,97 @@ void throttle_account(ThrottleState *ts, bool is_write, 
> uint64_t size)
>   void throttle_limits_to_config(ThrottleLimits *arg, ThrottleConfig *cfg,
>  Error **errp)
>   {
> -if (arg->has_bps_total) {
> -cfg->buckets[THROTTLE_BPS_TOTAL].avg = arg->bps_total;
> +if (arg->has_bps) {
> +cfg->buckets[THROTTLE_BPS_TOTAL].avg = arg->bps;

Otherwise, the churn from renaming members (part 1) makes it hard to see if the 
code was properly moved into a new file.

Split this patch to three patches in v5

Thanks
Kidd



Re: [Qemu-devel] [RFC v1 10/23] riscv: tcg-target: Add the instruction emitters

2018-11-16 Thread Richard Henderson
On 11/15/18 11:35 PM, Alistair Francis wrote:
> Signed-off-by: Alistair Francis 
> Signed-off-by: Michael Clark 
> ---
>  tcg/riscv/tcg-target.inc.c | 40 ++
>  1 file changed, 40 insertions(+)


Reviewed-by: Richard Henderson 

r~





Re: [Qemu-devel] [RFC v1 14/23] riscv: tcg-target: Add the out load and store instructions

2018-11-16 Thread Richard Henderson
On 11/15/18 11:36 PM, Alistair Francis wrote:
> Signed-off-by: Alistair Francis 
> Signed-off-by: Michael Clark 
> ---
>  tcg/riscv/tcg-target.inc.c | 56 ++
>  1 file changed, 56 insertions(+)
> 
> diff --git a/tcg/riscv/tcg-target.inc.c b/tcg/riscv/tcg-target.inc.c
> index 646a4d3ebd..bc433170c4 100644
> --- a/tcg/riscv/tcg-target.inc.c
> +++ b/tcg/riscv/tcg-target.inc.c
> @@ -518,6 +518,62 @@ static void tcg_out_ext32s(TCGContext *s, TCGReg ret, 
> TCGReg arg)
>  tcg_out_opc_imm(s, OPC_ADDIW, ret, arg, 0);
>  }
>  
> +static void tcg_out_ldst(TCGContext *s, RISCVInsn opc, TCGReg data,
> + TCGReg addr, intptr_t offset)
> +{
> +int32_t imm12 = sextract32(offset, 0, 12);

sextract64 for rv64.

Otherwise,
Reviewed-by: Richard Henderson 

r~



Re: [Qemu-devel] [PATCH V6 5/6] hw/arm/virt: add pvpanic device invirt acpi table

2018-11-16 Thread Andrew Jones
On Fri, Nov 16, 2018 at 09:45:42AM +0800, peng.h...@zte.com.cn wrote:
> >> add pvpanic device in virt acpi table, so when kenrel command line uses
> >> acpi=force, kernel can get info from acpi table in aarch64.
> 
> [...]
> 
> >>
> >> +static void acpi_dsdt_add_pvpanic(Aml *scope, const MemMapEntry 
> >> *pvpanic_memmap)
> >> +{
> >> +Aml *dev = aml_device("PANC");
> >
> >Shouldn't this be "PEVT" ("panic event"), like it is for x86?
> >
> yeah, I will change it.
> >> +aml_append(dev, aml_name_decl("_HID", aml_string("QEMU0001")));
> >> +aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> >
> >Why add _UID? Also, I see x86 had some issues with not having _STA and
> >then having a _STA without the UI flag. It now has _STA=0xf
> >(PRESENT|ENABLED|UI|FUNCTIONING). I'm not saying we need to do that to,
> >but I'd like to know if it was considered and decided we don't need to.
> >
> The way the kernel code processes _STA is that if _STA is not found, the 
> default 
> setting is (PRESENT|ENABLED|UI|FUNCTIONING). So I think it is not necessary
>  to add it. It is only parsed in the pvpanic driver. 

Good enough for me.

> for _UID, I think it is used for device index. I just fill it with 0 because 
> there is 
> only one pvpanic device.

OK, but I'm still not sure it's necessary.

> 
> by the way, How to get the value of ACPI conveniently? how dou you get the 
> value of _STA?

Not sure what you mean here. From where do you want to check the value?
If you mean from guest userspace, then there's nothing convenient that I
know of. You'll have to disassemble the tables you extract from sysfs,
afaik.

Thanks,
drew

> 
> Thanks.
> >> +
> >> +Aml *crs = aml_resource_template();
> >> +aml_append(crs, aml_memory32_fixed(pvpanic_memmap->base,
> >> +   pvpanic_memmap->size, 
> >> AML_READ_WRITE));
> >> +
> >> +aml_append(dev, aml_name_decl("_CRS", crs));
> >> +
> >> +aml_append(scope, dev);
> >> +}
> >> +
> >>  static void acpi_dsdt_add_uart(Aml *scope, const MemMapEntry *uart_memmap,
> >> uint32_t uart_irq)
> >>  {
> >> @@ -770,6 +785,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, 
> >> VirtMachineState *vms)
> >>  acpi_dsdt_add_cpus(scope, vms->smp_cpus);
> >>  acpi_dsdt_add_uart(scope, [VIRT_UART],
> >> (irqmap[VIRT_UART] + ARM_SPI_BASE));
> >> +acpi_dsdt_add_pvpanic(scope, [VIRT_PVPANIC]);
> >>  acpi_dsdt_add_flash(scope, [VIRT_FLASH]);
> >>  acpi_dsdt_add_fw_cfg(scope, [VIRT_FW_CFG]);
> >>  acpi_dsdt_add_virtio(scope, [VIRT_MMIO],
> >> --
> >> 1.8.3.1
> >>
> >>
> >
> >Thanks,
> >drew



Re: [Qemu-devel] [RFC v1 16/23] riscv: tcg-target: Add slowpath load and store instructions

2018-11-16 Thread Richard Henderson
On 11/15/18 11:36 PM, Alistair Francis wrote:
> +static void tcg_out_mb(TCGContext *s, TCGArg a0)
> +{
> +static const RISCVInsn fence[] = {
> +[0 ... TCG_MO_ALL] = OPC_FENCE_RW_RW,
> +[TCG_MO_LD_LD] = OPC_FENCE_R_R,
> +[TCG_MO_ST_LD] = OPC_FENCE_W_R,
> +[TCG_MO_LD_ST] = OPC_FENCE_R_W,
> +[TCG_MO_ST_ST] = OPC_FENCE_W_W,
> +[TCG_BAR_LDAQ] = OPC_FENCE_R_RW,
> +[TCG_BAR_STRL] = OPC_FENCE_RW_W,
> +[TCG_BAR_SC]   = OPC_FENCE_RW_RW,
> +};
> +tcg_out32(s, fence[a0 & TCG_MO_ALL]);
> +}
> +

TCG_MO_* and TCG_BAR_* are two different bitmasks, or'ed together.
Which you've separated by "& TCG_MO_ALL".  Thus the TCG_BAR_* constants should
not appear in this table.


> +static void * const qemu_ld_helpers[16] = {
> +[MO_UB]   = helper_ret_ldub_mmu,
> +[MO_SB]   = helper_ret_ldsb_mmu,
> +[MO_LEUW] = helper_le_lduw_mmu,
> +[MO_LESW] = helper_le_ldsw_mmu,
> +[MO_LEUL] = helper_le_ldul_mmu,
> +[MO_LESL] = helper_le_ldsl_mmu,
> +[MO_LEQ]  = helper_le_ldq_mmu,
> +[MO_BEUW] = helper_be_lduw_mmu,
> +[MO_BESW] = helper_be_ldsw_mmu,
> +[MO_BEUL] = helper_be_ldul_mmu,
> +[MO_BESL] = helper_be_ldsl_mmu,
> +[MO_BEQ]  = helper_be_ldq_mmu,
> +};

The LESL and BESL functions will not be present for rv32 -> link error.  Here
you do need an ifdef.

> +} else {
> +adj = cmp_off - sextract32(cmp_off, 0, 12);
> +tcg_debug_assert(add_off - adj >= -0x1000
> + && add_off - adj < 0x1000);
> +
> +tcg_out_opc_upper(s, OPC_LUI, base, adj);
> +tcg_out_opc_reg(s, OPC_ADD, base, TCG_REG_ZERO, TCG_AREG0);

base, base, TCG_AREG0.

> +/* Compare masked address with the TLB entry. */
> +label_ptr[0] = s->code_ptr;
> +tcg_out_opc_branch(s, OPC_BNE, TCG_REG_TMP0, TCG_REG_TMP1, 0);

Another case of a potential out-of-range branch.

It might be worthwhile to move all of this out-of-line from the start, where
that branch will always be short.  See

http://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg02234.html


r~



Re: [Qemu-devel] [PATCH 0/3] Introduce 'rendernode' option for egl-headless display type

2018-11-16 Thread Erik Skultety
On Fri, Nov 16, 2018 at 09:43:52AM +0100, Gerd Hoffmann wrote:
> On Thu, Nov 15, 2018 at 09:47:44AM -0600, Eric Blake wrote:
> > On 11/15/18 9:15 AM, Erik Skultety wrote:
> > > Since QEMU always picks the default DRI device, libvirt doesn't know 
> > > which one
> > > to put into the mount namespace and relabel it accordingly, hence hitting
> > > permission issues, unless admin tweaks the default permissions of the DRI
> > > devices.
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1648236
> >
> > This is borderline between fixing a bug that gets in the way of libvirt (and
> > thus useful for 3.1) and a feature (thus for 4.0, since we won't have a 3.2
> > release). I'll let Gerd decide.
>
> It's simple enough and we are early in the -rc cycle still, I think it
> would be okay for 3.1.

As far as upstream's concerned, I'm okay with both because libvirt has to add
another version specific capability enum for this anyway. It's been broken
since libvirt 4.6.0 where I added egl-headless graphics type. Luckily, even
though it's far from optimal, a working solution exists, just change the
permissions on the device.

Thanks,
Erik



Re: [Qemu-devel] Are FreeBSD guest images working?

2018-11-16 Thread Peter Maydell
On 16 November 2018 at 05:01, Peter Xu  wrote:
> I would guess there aren't many people like me to prefer booting a VM
> using console, though I agree that it'll be nice if we put something
> into the prebuilt images like what's suggested by Ilya (and so far I
> don't see anything bad with that):

As it happens I would have preferred the instructions on
the QEMU wiki to work with a pure serial console but was unable
to get that working so defaulted to graphics. (I didn't try very
hard: x86 in general is much worse for getting serial boot
working than other architectures, partly because of the BIOS.)

thanks
-- PMM



Re: [Qemu-devel] [PATCH v6 06/16] gdbstub: add multiprocess support to 'sC' packets

2018-11-16 Thread Edgar E. Iglesias
On Thu, Nov 15, 2018 at 10:41:57AM +0100, Luc Michel wrote:
> Change the sC packet handling to support the multiprocess extension.
> Instead of returning the first thread, we return the first thread of the
> current process.
> 
> Signed-off-by: Luc Michel 
> Reviewed-by: Philippe Mathieu-Daudé 
> Reviewed-by: Alistair Francis 

Reviewed-by: Edgar E. Iglesias 


> ---
>  gdbstub.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/gdbstub.c b/gdbstub.c
> index f1ec3481cb..d19b0137e8 100644
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -1546,13 +1546,18 @@ static int gdb_handle_packet(GDBState *s, const char 
> *line_buf)
>  type = strtoul(p, (char **), 16);
>  sstep_flags = type;
>  put_packet(s, "OK");
>  break;
>  } else if (strcmp(p,"C") == 0) {
> -/* "Current thread" remains vague in the spec, so always return
> - *  the first CPU (gdb returns the first thread). */
> -put_packet(s, "QC1");
> +/* "Current thread" remains vague in the spec, so always return 
> the
> + * first thread of the current process (gdb returns the first
> + * thread).
> + */
> +cpu = get_first_cpu_in_process(s, gdb_get_cpu_process(s, 
> s->g_cpu));
> +snprintf(buf, sizeof(buf), "QC%s",
> + gdb_fmt_thread_id(s, cpu, thread_id, 
> sizeof(thread_id)));
> +put_packet(s, buf);
>  break;
>  } else if (strcmp(p,"fThreadInfo") == 0) {
>  s->query_cpu = first_cpu;
>  goto report_cpuinfo;
>  } else if (strcmp(p,"sThreadInfo") == 0) {
> -- 
> 2.19.1
> 



Re: [Qemu-devel] [Qemu-block] [PATCH] migration/block-dirty-bitmap: fix Coverity CID1390625

2018-11-16 Thread Peter Maydell
On 16 November 2018 at 03:28, John Snow  wrote:
> I looked again. I think Vladimir's patch will shut up Coverity for sure,
> feel free to apply it if you want this out of your hair.
>
> Stefan suggests the following, however;
>
>
> diff --git a/migration/block-dirty-bitmap.c b/migration/block-dirty-bitmap.c
> index 5e90f44c2f..00c068fda3 100644
> --- a/migration/block-dirty-bitmap.c
> +++ b/migration/block-dirty-bitmap.c
> @@ -284,7 +284,7 @@ static int init_dirty_bitmap_migration(void)
>  const char *drive_name = bdrv_get_device_or_node_name(bs);
>
>  /* skip automatically inserted nodes */
> -while (bs && bs->drv && bs->implicit) {
> +while (bs->drv && bs->implicit) {
>  bs = backing_bs(bs);
>  }
>
>
> that by removing the assumption that bs could ever be null here (it
> shouldn't), that we'll coax coverity into not warning anymore. I don't
> know if that will work, because backing_bs can theoretically return NULL
> and might convince coverity there's a problem. In practice it won't be.
>
> I don't know how to check this to see if Stefan's suggestion is appropriate.
>
> For such a small, trivial issue though, just merge this and be done with
> it, in my opinion. If you want to take this fix directly as a "build
> fix" I wouldn't object.

Personally I think the main benefit of this sort of Coverity
warning is that it nudges you to work through and figure out
whether something really can be NULL or not. Stefan's fix
will satisfy Coverity, because what it's complaining about
is that the code in one place assumes a pointer can't be NULL
but in another place does have handling for NULL: it is the
inconsistency that triggers the warning. If backing_bs()
can't return NULL (ie if you would be happy in theory to put
an assert() in after the call) then I think Stefan's fix is
better. If it can return NULL ever then Vladimir's fix is
what you want.

thanks
-- PMM



Re: [Qemu-devel] [PATCH v6 11/16] gdbstub: add support for extended mode packet

2018-11-16 Thread Edgar E. Iglesias
On Thu, Nov 15, 2018 at 10:42:02AM +0100, Luc Michel wrote:
> Add support for the '!' extended mode packet. This is required for the
> multiprocess extension.
> 
> Signed-off-by: Luc Michel 

Reviewed-by: Edgar E. Iglesias 



> ---
>  gdbstub.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/gdbstub.c b/gdbstub.c
> index eec1cf0d09..ada53ac559 100644
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -1294,10 +1294,13 @@ static int gdb_handle_packet(GDBState *s, const char 
> *line_buf)
>  trace_gdbstub_io_command(line_buf);
>  
>  p = line_buf;
>  ch = *p++;
>  switch(ch) {
> +case '!':
> +put_packet(s, "OK");
> +break;
>  case '?':
>  /* TODO: Make this return the correct value for user-mode.  */
>  snprintf(buf, sizeof(buf), "T%02xthread:%s;", GDB_SIGNAL_TRAP,
>   gdb_fmt_thread_id(s, s->c_cpu, thread_id, 
> sizeof(thread_id)));
>  put_packet(s, buf);
> -- 
> 2.19.1
> 



Re: [Qemu-devel] [PATCH 0/2] typedefs.h cleanup

2018-11-16 Thread Markus Armbruster
Eric Blake  writes:

> Prompted by my review of xiezhide's work.  No semantic change, but
> not technically a bug fix, so I don't care if it goes in 3.1 or
> waits for 4.0.

Reviewed-by: Markus Armbruster 



[Qemu-devel] [PATCH v2 0/3] Introduce 'rendernode' option for egl-headless display type

2018-11-16 Thread Erik Skultety
https://bugzilla.redhat.com/show_bug.cgi?id=1648236

Changes since v1:
- adjusted the QAPI version and description commentaries for egl-headless

Erik Skultety (3):
  qapi: Add "rendernode" display option for egl-headless
  ui: Allow specifying 'rendernode' display option for egl-headless
  help: Provide help for egl-headless

 qapi/ui.json  | 17 -
 qemu-options.hx   |  6 +-
 ui/egl-headless.c |  2 +-
 3 files changed, 22 insertions(+), 3 deletions(-)

--
2.19.1




Re: [Qemu-devel] [PATCH v6 13/16] gdbstub: processes initialization on new peer connection

2018-11-16 Thread Edgar E. Iglesias
On Thu, Nov 15, 2018 at 10:42:04AM +0100, Luc Michel wrote:
> When a new connection is established, we set the first process to be
> attached, and the others detached. The first CPU of the first process
> is selected as the current CPU.
> 
> Signed-off-by: Luc Michel 
> Reviewed-by: Alistair Francis 

Reviewed-by: Edgar E. Iglesias 


> ---
>  gdbstub.c | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/gdbstub.c b/gdbstub.c
> index 0427d1c4f0..59eed3b878 100644
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -2245,13 +2245,14 @@ static bool gdb_accept(void)
>  close(fd);
>  return false;
>  }
>  
>  s = g_malloc0(sizeof(GDBState));
> -s->c_cpu = first_cpu;
> -s->g_cpu = first_cpu;
>  create_unique_process(s);
> +s->processes[0].attached = true;
> +s->c_cpu = gdb_first_cpu(s);
> +s->g_cpu = s->c_cpu;
>  s->fd = fd;
>  gdb_has_xml = false;
>  
>  gdbserver_state = s;
>  return true;
> @@ -2333,12 +2334,23 @@ static void gdb_chr_receive(void *opaque, const 
> uint8_t *buf, int size)
>  }
>  }
>  
>  static void gdb_chr_event(void *opaque, int event)
>  {
> +int i;
> +GDBState *s = (GDBState *) opaque;
> +
>  switch (event) {
>  case CHR_EVENT_OPENED:
> +/* Start with first process attached, others detached */
> +for (i = 0; i < s->process_num; i++) {
> +s->processes[i].attached = !i;
> +}
> +
> +s->c_cpu = gdb_first_cpu(s);
> +s->g_cpu = s->c_cpu;
> +
>  vm_stop(RUN_STATE_PAUSED);
>  gdb_has_xml = false;
>  break;
>  default:
>  break;
> @@ -2524,19 +2536,17 @@ int gdbserver_start(const char *device)
>  mon_chr = s->mon_chr;
>  cleanup_processes(s);
>  memset(s, 0, sizeof(GDBState));
>  s->mon_chr = mon_chr;
>  }
> -s->c_cpu = first_cpu;
> -s->g_cpu = first_cpu;
>  
>  create_processes(s);
>  
>  if (chr) {
>  qemu_chr_fe_init(>chr, chr, _abort);
>  qemu_chr_fe_set_handlers(>chr, gdb_chr_can_receive, 
> gdb_chr_receive,
> - gdb_chr_event, NULL, NULL, NULL, true);
> + gdb_chr_event, NULL, s, NULL, true);
>  }
>  s->state = chr ? RS_IDLE : RS_INACTIVE;
>  s->mon_chr = mon_chr;
>  s->current_syscall_cb = NULL;
>  
> -- 
> 2.19.1
> 



Re: [Qemu-devel] [PATCH v4] Add arm SBSA reference machine

2018-11-16 Thread Hongbo Zhang
On Fri, 16 Nov 2018 at 17:58, Peter Maydell  wrote:
>
> On 16 November 2018 at 08:23, Hongbo Zhang  wrote:
> > Well, for the SMP booting, when GICv2 used, there is no problem, max
> > CPU number 8 can be booted, including all the three cases: kernel
> > only, UEFI+kernel and ATF+UEFI+kernel.
> >
> > But when GICv3 used, these two cases still work: kernel only, and
> > UEFI+kernel, but ATF+UEFI+kernel fails booting more than 4 cores with
> > GICv3.
> > The original ATF didn't support GICv3, so I added the support:
> > http://git.linaro.org/people/hongbo.zhang/atf-sbsa.git/log/?h=sbsa_gicv3
> >
> > Root cause of failing to boot more than 4 cores with ATF+UEFI+kernel
> > with my GICv3 enabled is due to this:
> > In QEMU, we have this defination
> > #define ARM_DEFAULT_CPUS_PER_CLUSTER 8
> > But in ATF, the defination is
> > #define PLATFORM_MAX_CPUS_PER_CLUSTER 4
> > So when we pass smp=6 for example, QEMU generates MPIDR showing all
> > the 6 cores are at cluster 0, but when ATF parses such MPIDR, the
> > function plat_core_pos_by_mpidr() in plat/qemu/topology.c returns
> > error since there should be no more cores than 4.
> >
> > I think we should change the definition in QEMU to 4, instead of
> > changing the ATF's, because I checked Cortext a57/a72/a73/a75 spec, it
> > says there are 4 cores max at one cluster.
>
> Architecturally 8 per cluster is entirely legal. This is
> an ATF limitation and there's an argument for fixing it there.
> However, since for this board we're trying to match what real
> hardware with these CPUs would look like, it does make sense
> to use the same number of CPUs per cluster as the hardware.
> If you want your board to instantiate 4 per cluster this is possible,
> and you don't need to change ARM_DEFAULT_CPUS_PER_CLUSTER.
> This value is only used if the board code does not set the
> cpu->mp_affinity value itself (it is the default, as the
> name suggests). So you can just make your board code set
> the mp_affinity up however you like, after the CPU object
> is created but before it is realized.
>
Get it, thanks.

> thanks
> -- PMM



[Qemu-devel] [PATCH v5 00/36] ppc: support for the XIVE interrupt controller (POWER9)

2018-11-16 Thread Cédric Le Goater
Hello,

Here is the version 5 of the QEMU models adding support for the XIVE
interrupt controller to the sPAPR machine, under TCG and KVM, and to
the PowerNV POWER9 machine.

The most important changes for sPAPR are the introduction of a new
'dual' pseries machine supporting both interrupt mode: XICS and XIVE,
under TCG and KVM, and fixes for the virtual LSIs.

The QEMU PowerNV POWER9 machine now has support for PHB4 bringing it
to the level of a "real" machine. It validates the model of the
barematel XIVE IC controller proposed in this patchset. The other
PowerNV models will be part of another patchset.

Thanks,

C.


Changes in v5 :

 Common XIVE models :

 - renamed the XIVE structures to fit the changes of the XIVE
   architecture documents: IVE, EQD, VPD -> EAS, END, NVT   
 - reworked the monitor ouput to print the EQ contents

 sPAPR models :

 - introduced a XIVE Router 'reset' method for the Xive Thread Context
   to set the OS CAM line of the VCPU
 - introduced a spapr_irq_init() routine to the sPAPR IRQ backend
   and reworked the XIVE-only machine to fit mainline QEMU
 - introduced a reset() method to the sPAPR IRQ backend to handle
   changes in the interrupt mode after machine reset
 - introduced a 'dual' machine supporting both interrupt mode

 KVM :

 - introduced some more sPAPR NVT and END indexing helpers for KVM support
 - fixed the virtual LSIs in KVM by using the H_INT_ESB source flag
 - improved the KVM support with better common classes and cleaner
   QEMU<->KVM interfaces
 - improved KVM migration with a better control on the capture sequence.
   Still some issues with 'ceded' VCPUs 
 - introduced KVM support for the 'dual' machine

 PowerNV:

 - introduced address spaces for the IPI and END set translation
   tables


Changes in v4 :

   See https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg01672.html


= XIVE =


The POWER9 processor comes with a new interrupt controller, called
XIVE as "eXternal Interrupt Virtualization Engine".


* Overall architecture


  XIVE Interrupt Controller
  +-+   IPIs
  | +-+ +-+ +-+ |++
  | |VC   | |CQ   | |PC   |> | CORES  |
  | | esb | | | | |> ||
  | | eas | |  Bridge | | |> ||
  | |SC   end | | | | nvt | |||
+--+  | +-+ +++ +-+ |+--+-+-+-+
| RAM  |  +--|--+   | | |
|  | |  | | |
|  | |  | | |
|  |   +-v--v-v-v---+  other
|  <---+   Power Bus+> chips
|  esb |   +---+---++
|  eas |   |   |
|  end |   |   |
|  nvt |   +---++  +---++
+--+   |SC  |  |SC  |
   ||  ||
   | 2-bits |  | 2-bits |
   | local  |  |   VC   |
   ++  ++
 PCIe  NX,NPU,CAPI

  SC: Source Controller (aka. IVSE)
  VC: Virtualization Controller (aka. IVRE)
  CQ: Common Queue (Bridge)
  PC: Presentation Controller (aka. IVPE)

  2-bits: source state machine (PQ bits)
 esb: Event State Buffer (Array of PQ bits in an IVSE)
 eas: Event Assignment Structure
 end: Event Notification Descriptor
 nvt: Notification Virtual Target

It is composed of three sub-engines :

  - Interrupt Virtualization Source Engine (IVSE), or Source
Controller (SC). These are found in PCI PHBs, in the PSI host
bridge controller, but also inside the main controller for the
core IPIs and other sub-chips (NX, CAP, NPU) of the
chip/processor. They are configured to feed the IVRE with events.

  - Interrupt Virtualization Routing Engine (IVRE) or Virtualization
Controller (VC). Its job is to match an event source with an Event
Notification Descriptor (END).

  - Interrupt Virtualization Presentation Engine (IVPE) or Presentation
Controller (PC). It maintains the interrupt context state of each
thread and handles the delivery of the external exception to the
thread.


* XIVE internal tables

Each of the sub-engines uses a set of tables to redirect exceptions
from event sources to CPU threads.

 +---+
   User or OS|  EQ   

[Qemu-devel] [PATCH v5 03/36] ppc/xive: introduce the XiveFabric interface

2018-11-16 Thread Cédric Le Goater
The XiveFabric offers a simple interface, between the XiveSource
object and the main interrupt controller of the machine. It will
forward event notifications to the XIVE Interrupt Virtualization
Routing Engine (IVRE).

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/xive.h | 23 +++
 hw/intc/xive.c| 25 +
 2 files changed, 48 insertions(+)

diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
index e118acd59f1e..be93fae6317b 100644
--- a/include/hw/ppc/xive.h
+++ b/include/hw/ppc/xive.h
@@ -12,6 +12,27 @@
 
 #include "hw/sysbus.h"
 
+/*
+ * XIVE Fabric (Interface between Source and Router)
+ */
+
+typedef struct XiveFabric {
+Object parent;
+} XiveFabric;
+
+#define TYPE_XIVE_FABRIC "xive-fabric"
+#define XIVE_FABRIC(obj) \
+OBJECT_CHECK(XiveFabric, (obj), TYPE_XIVE_FABRIC)
+#define XIVE_FABRIC_CLASS(klass) \
+OBJECT_CLASS_CHECK(XiveFabricClass, (klass), TYPE_XIVE_FABRIC)
+#define XIVE_FABRIC_GET_CLASS(obj)   \
+OBJECT_GET_CLASS(XiveFabricClass, (obj), TYPE_XIVE_FABRIC)
+
+typedef struct XiveFabricClass {
+InterfaceClass parent;
+void (*notify)(XiveFabric *xf, uint32_t lisn);
+} XiveFabricClass;
+
 /*
  * XIVE Interrupt Source
  */
@@ -42,6 +63,8 @@ typedef struct XiveSource {
 uint64_tesb_flags;
 uint32_tesb_shift;
 MemoryRegionesb_mmio;
+
+XiveFabric  *xive;
 } XiveSource;
 
 /*
diff --git a/hw/intc/xive.c b/hw/intc/xive.c
index ac4605fee8b7..014a2e41f71f 100644
--- a/hw/intc/xive.c
+++ b/hw/intc/xive.c
@@ -152,7 +152,11 @@ static bool xive_source_esb_eoi(XiveSource *xsrc, uint32_t 
srcno)
  */
 static void xive_source_notify(XiveSource *xsrc, int srcno)
 {
+XiveFabricClass *xfc = XIVE_FABRIC_GET_CLASS(xsrc->xive);
 
+if (xfc->notify) {
+xfc->notify(xsrc->xive, srcno);
+}
 }
 
 /*
@@ -358,6 +362,17 @@ static void xive_source_reset(DeviceState *dev)
 static void xive_source_realize(DeviceState *dev, Error **errp)
 {
 XiveSource *xsrc = XIVE_SOURCE(dev);
+Object *obj;
+Error *local_err = NULL;
+
+obj = object_property_get_link(OBJECT(dev), "xive", _err);
+if (!obj) {
+error_propagate(errp, local_err);
+error_prepend(errp, "required link 'xive' not found: ");
+return;
+}
+
+xsrc->xive = XIVE_FABRIC(obj);
 
 if (!xsrc->nr_irqs) {
 error_setg(errp, "Number of interrupt needs to be greater than 0");
@@ -427,9 +442,19 @@ static const TypeInfo xive_source_info = {
 .class_init= xive_source_class_init,
 };
 
+/*
+ * XIVE Fabric
+ */
+static const TypeInfo xive_fabric_info = {
+.name = TYPE_XIVE_FABRIC,
+.parent = TYPE_INTERFACE,
+.class_size = sizeof(XiveFabricClass),
+};
+
 static void xive_register_types(void)
 {
 type_register_static(_source_info);
+type_register_static(_fabric_info);
 }
 
 type_init(xive_register_types)
-- 
2.17.2




[Qemu-devel] [PATCH v5 02/36] ppc/xive: add support for the LSI interrupt sources

2018-11-16 Thread Cédric Le Goater
The 'sent' status of the LSI interrupt source is modeled with the 'P'
bit of the ESB and the assertion status of the source is maintained in
an array under the main sPAPRXive object. The type of the source is
stored in the same array for practical reasons.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/xive.h | 20 -
 hw/intc/xive.c| 68 +++
 2 files changed, 81 insertions(+), 7 deletions(-)

diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
index 5fec4b08705d..e118acd59f1e 100644
--- a/include/hw/ppc/xive.h
+++ b/include/hw/ppc/xive.h
@@ -32,8 +32,10 @@ typedef struct XiveSource {
 /* IRQs */
 uint32_tnr_irqs;
 qemu_irq*qirqs;
+unsigned long   *lsi_map;
+int32_t lsi_map_size; /* for VMSTATE_BITMAP */
 
-/* PQ bits */
+/* PQ bits and LSI assertion bit */
 uint8_t *status;
 
 /* ESB memory region */
@@ -89,6 +91,7 @@ static inline hwaddr xive_source_esb_mgmt(XiveSource *xsrc, 
int srcno)
  * When doing an EOI, the Q bit will indicate if the interrupt
  * needs to be re-triggered.
  */
+#define XIVE_STATUS_ASSERTED  0x4  /* Extra bit for LSI */
 #define XIVE_ESB_VAL_P0x2
 #define XIVE_ESB_VAL_Q0x1
 
@@ -127,4 +130,19 @@ static inline qemu_irq xive_source_qirq(XiveSource *xsrc, 
uint32_t srcno)
 return xsrc->qirqs[srcno];
 }
 
+static inline bool xive_source_irq_is_lsi(XiveSource *xsrc, uint32_t srcno)
+{
+assert(srcno < xsrc->nr_irqs);
+return test_bit(srcno, xsrc->lsi_map);
+}
+
+static inline void xive_source_irq_set(XiveSource *xsrc, uint32_t srcno,
+   bool lsi)
+{
+assert(srcno < xsrc->nr_irqs);
+if (lsi) {
+bitmap_set(xsrc->lsi_map, srcno, 1);
+}
+}
+
 #endif /* PPC_XIVE_H */
diff --git a/hw/intc/xive.c b/hw/intc/xive.c
index f7621f84828c..ac4605fee8b7 100644
--- a/hw/intc/xive.c
+++ b/hw/intc/xive.c
@@ -88,14 +88,40 @@ uint8_t xive_source_esb_set(XiveSource *xsrc, uint32_t 
srcno, uint8_t pq)
 return xive_esb_set(>status[srcno], pq);
 }
 
+/*
+ * Returns whether the event notification should be forwarded.
+ */
+static bool xive_source_lsi_trigger(XiveSource *xsrc, uint32_t srcno)
+{
+uint8_t old_pq = xive_source_esb_get(xsrc, srcno);
+
+switch (old_pq) {
+case XIVE_ESB_RESET:
+xive_source_esb_set(xsrc, srcno, XIVE_ESB_PENDING);
+return true;
+default:
+return false;
+}
+}
+
 /*
  * Returns whether the event notification should be forwarded.
  */
 static bool xive_source_esb_trigger(XiveSource *xsrc, uint32_t srcno)
 {
+bool ret;
+
 assert(srcno < xsrc->nr_irqs);
 
-return xive_esb_trigger(>status[srcno]);
+ret = xive_esb_trigger(>status[srcno]);
+
+if (xive_source_irq_is_lsi(xsrc, srcno) &&
+xive_source_esb_get(xsrc, srcno) == XIVE_ESB_QUEUED) {
+qemu_log_mask(LOG_GUEST_ERROR,
+  "XIVE: queued an event on LSI IRQ %d\n", srcno);
+}
+
+return ret;
 }
 
 /*
@@ -103,9 +129,22 @@ static bool xive_source_esb_trigger(XiveSource *xsrc, 
uint32_t srcno)
  */
 static bool xive_source_esb_eoi(XiveSource *xsrc, uint32_t srcno)
 {
+bool ret;
+
 assert(srcno < xsrc->nr_irqs);
 
-return xive_esb_eoi(>status[srcno]);
+ret = xive_esb_eoi(>status[srcno]);
+
+/* LSI sources do not set the Q bit but they can still be
+ * asserted, in which case we should forward a new event
+ * notification
+ */
+if (xive_source_irq_is_lsi(xsrc, srcno) &&
+xsrc->status[srcno] & XIVE_STATUS_ASSERTED) {
+ret = xive_source_lsi_trigger(xsrc, srcno);
+}
+
+return ret;
 }
 
 /*
@@ -268,8 +307,17 @@ static void xive_source_set_irq(void *opaque, int srcno, 
int val)
 XiveSource *xsrc = XIVE_SOURCE(opaque);
 bool notify = false;
 
-if (val) {
-notify = xive_source_esb_trigger(xsrc, srcno);
+if (xive_source_irq_is_lsi(xsrc, srcno)) {
+if (val) {
+xsrc->status[srcno] |= XIVE_STATUS_ASSERTED;
+notify = xive_source_lsi_trigger(xsrc, srcno);
+} else {
+xsrc->status[srcno] &= ~XIVE_STATUS_ASSERTED;
+}
+} else {
+if (val) {
+notify = xive_source_esb_trigger(xsrc, srcno);
+}
 }
 
 /* Forward the source event notification for routing */
@@ -289,9 +337,11 @@ void xive_source_pic_print_info(XiveSource *xsrc, uint32_t 
offset, Monitor *mon)
 continue;
 }
 
-monitor_printf(mon, "  %08x %c%c\n", i + offset,
+monitor_printf(mon, "  %08x %s %c%c%c\n", i + offset,
+   xive_source_irq_is_lsi(xsrc, i) ? "LSI" : "MSI",
pq & XIVE_ESB_VAL_P ? 'P' : '-',
-   pq & XIVE_ESB_VAL_Q ? 'Q' : '-');
+   pq & XIVE_ESB_VAL_Q ? 'Q' : '-',
+   xsrc->status[i] & XIVE_STATUS_ASSERTED ? 'A' : ' ');
 }
 }
 
@@ -299,6 +349,8 @@ 

[Qemu-devel] [PATCH v5 22/36] spapr/xive: add models for KVM support

2018-11-16 Thread Cédric Le Goater
This introduces a set of XIVE models specific to KVM which derive from
the XIVE base models. The interfaces with KVM are a new capability and
a new KVM device for the XIVE native exploitation interrupt mode.

They handle the initialization of the TIMA and the source ESB memory
regions which have a different type under KVM. These are 'ram device'
memory mappings, similarly to VFIO, exposed to the guest and the
associated VMAs on the host are populated dynamically with the
appropriate pages using a fault handler.

Signed-off-by: Cédric Le Goater 
---
 default-configs/ppc64-softmmu.mak |   1 +
 include/hw/ppc/spapr_xive.h   |  18 ++
 include/hw/ppc/xive.h |   3 +
 linux-headers/asm-powerpc/kvm.h   |  12 +
 linux-headers/linux/kvm.h |   4 +
 target/ppc/kvm_ppc.h  |   6 +
 hw/intc/spapr_xive_kvm.c  | 430 ++
 hw/ppc/spapr.c|   7 +-
 hw/ppc/spapr_irq.c|  19 +-
 target/ppc/kvm.c  |   7 +
 hw/intc/Makefile.objs |   1 +
 11 files changed, 503 insertions(+), 5 deletions(-)
 create mode 100644 hw/intc/spapr_xive_kvm.c

diff --git a/default-configs/ppc64-softmmu.mak 
b/default-configs/ppc64-softmmu.mak
index 7f34ad0528ed..c1bf5cd951f5 100644
--- a/default-configs/ppc64-softmmu.mak
+++ b/default-configs/ppc64-softmmu.mak
@@ -18,6 +18,7 @@ CONFIG_XICS_SPAPR=$(CONFIG_PSERIES)
 CONFIG_XICS_KVM=$(call land,$(CONFIG_PSERIES),$(CONFIG_KVM))
 CONFIG_XIVE=$(CONFIG_PSERIES)
 CONFIG_XIVE_SPAPR=$(CONFIG_PSERIES)
+CONFIG_XIVE_KVM=$(call land,$(CONFIG_PSERIES),$(CONFIG_KVM))
 CONFIG_MEM_DEVICE=y
 CONFIG_DIMM=y
 CONFIG_SPAPR_RNG=y
diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
index aca2969a09ab..9c817bb7ae74 100644
--- a/include/hw/ppc/spapr_xive.h
+++ b/include/hw/ppc/spapr_xive.h
@@ -40,6 +40,10 @@ typedef struct sPAPRXive {
 /* TIMA mapping address */
 hwaddrtm_base;
 MemoryRegion  tm_mmio;
+
+/* KVM support */
+int   fd;
+void  *tm_mmap;
 } sPAPRXive;
 
 #define SPAPR_XIVE_BASE_CLASS(klass) \
@@ -83,4 +87,18 @@ void spapr_xive_hcall_init(sPAPRMachineState *spapr);
 void spapr_dt_xive(sPAPRXive *xive, int nr_servers, void *fdt,
uint32_t phandle);
 
+/*
+ * XIVE KVM models
+ */
+
+#define TYPE_SPAPR_XIVE_KVM  "spapr-xive-kvm"
+#define SPAPR_XIVE_KVM(obj)  OBJECT_CHECK(sPAPRXive, (obj), 
TYPE_SPAPR_XIVE_KVM)
+
+#define TYPE_XIVE_SOURCE_KVM "xive-source-kvm"
+#define XIVE_SOURCE_KVM(obj) \
+OBJECT_CHECK(XiveSource, (obj), TYPE_XIVE_SOURCE_KVM)
+
+#define TYPE_XIVE_TCTX_KVM   "xive-tctx-kvm"
+#define XIVE_TCTX_KVM(obj)   OBJECT_CHECK(XiveTCTX, (obj), TYPE_XIVE_TCTX_KVM)
+
 #endif /* PPC_SPAPR_XIVE_H */
diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
index 281ed370121c..7aaf5a182cb3 100644
--- a/include/hw/ppc/xive.h
+++ b/include/hw/ppc/xive.h
@@ -69,6 +69,9 @@ typedef struct XiveSource {
 uint32_tesb_shift;
 MemoryRegionesb_mmio;
 
+/* KVM support */
+void*esb_mmap;
+
 XiveFabric  *xive;
 } XiveSource;
 
diff --git a/linux-headers/asm-powerpc/kvm.h b/linux-headers/asm-powerpc/kvm.h
index 8c876c166ef2..f34c971491dd 100644
--- a/linux-headers/asm-powerpc/kvm.h
+++ b/linux-headers/asm-powerpc/kvm.h
@@ -675,4 +675,16 @@ struct kvm_ppc_cpu_char {
 #define  KVM_XICS_PRESENTED(1ULL << 43)
 #define  KVM_XICS_QUEUED   (1ULL << 44)
 
+/* POWER9 XIVE Native Interrupt Controller */
+#define KVM_DEV_XIVE_GRP_CTRL  1
+#define   KVM_DEV_XIVE_GET_ESB_FD  1
+#define   KVM_DEV_XIVE_GET_TIMA_FD 2
+#define   KVM_DEV_XIVE_VC_BASE 3
+#define KVM_DEV_XIVE_GRP_SOURCES   2   /* 64-bit source attributes */
+
+/* Layout of 64-bit XIVE source attribute values */
+#define KVM_XIVE_LEVEL_SENSITIVE   (1ULL << 0)
+#define KVM_XIVE_LEVEL_ASSERTED(1ULL << 1)
+
+
 #endif /* __LINUX_KVM_POWERPC_H */
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index f11a7eb49cfa..59fa8d8d7f39 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -965,6 +965,8 @@ struct kvm_ppc_resize_hpt {
 #define KVM_CAP_COALESCED_PIO 162
 #define KVM_CAP_HYPERV_ENLIGHTENED_VMCS 163
 #define KVM_CAP_EXCEPTION_PAYLOAD 164
+#define KVM_CAP_ARM_VM_IPA_SIZE 165
+#define KVM_CAP_PPC_IRQ_XIVE 166
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
@@ -1188,6 +1190,8 @@ enum kvm_device_type {
 #define KVM_DEV_TYPE_ARM_VGIC_V3   KVM_DEV_TYPE_ARM_VGIC_V3
KVM_DEV_TYPE_ARM_VGIC_ITS,
 #define KVM_DEV_TYPE_ARM_VGIC_ITS  KVM_DEV_TYPE_ARM_VGIC_ITS
+   KVM_DEV_TYPE_XIVE,
+#define KVM_DEV_TYPE_XIVE  KVM_DEV_TYPE_XIVE
KVM_DEV_TYPE_MAX,
 };
 
diff --git a/target/ppc/kvm_ppc.h b/target/ppc/kvm_ppc.h
index bdfaa4e70a83..d2159660f9f2 100644
--- a/target/ppc/kvm_ppc.h
+++ b/target/ppc/kvm_ppc.h
@@ -59,6 +59,7 @@ bool kvmppc_has_cap_fixup_hcalls(void);
 bool kvmppc_has_cap_htm(void);
 bool 

[Qemu-devel] [PATCH v5 18/36] spapr: allocate the interrupt thread context under the CPU core

2018-11-16 Thread Cédric Le Goater
Each interrupt mode has its own specific interrupt presenter object,
that we store under the CPU object, one for XICS and one for XIVE.

Extend the sPAPR IRQ backend with a new handler to support them both.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/spapr.h |  1 +
 include/hw/ppc/spapr_irq.h |  2 ++
 include/hw/ppc/xive.h  |  2 ++
 hw/intc/xive.c | 21 +
 hw/ppc/spapr_cpu_core.c|  5 ++---
 hw/ppc/spapr_irq.c | 17 +
 6 files changed, 45 insertions(+), 3 deletions(-)

diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index 8415faea7b82..f43ef69d61bc 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -177,6 +177,7 @@ struct sPAPRMachineState {
 int32_t irq_map_nr;
 unsigned long *irq_map;
 sPAPRXive  *xive;
+const char *xive_tctx_type;
 
 bool cmd_line_caps[SPAPR_CAP_NUM];
 sPAPRCapabilities def, eff, mig;
diff --git a/include/hw/ppc/spapr_irq.h b/include/hw/ppc/spapr_irq.h
index cfdc1f86e713..c3b4c38145eb 100644
--- a/include/hw/ppc/spapr_irq.h
+++ b/include/hw/ppc/spapr_irq.h
@@ -42,6 +42,8 @@ typedef struct sPAPRIrq {
 void (*print_info)(sPAPRMachineState *spapr, Monitor *mon);
 void (*dt_populate)(sPAPRMachineState *spapr, uint32_t nr_servers,
 void *fdt, uint32_t phandle);
+Object *(*cpu_intc_create)(sPAPRMachineState *spapr, Object *cpu,
+   Error **errp);
 } sPAPRIrq;
 
 extern sPAPRIrq spapr_irq_xics;
diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
index e6931ddaa83f..b74eb326dcd1 100644
--- a/include/hw/ppc/xive.h
+++ b/include/hw/ppc/xive.h
@@ -284,6 +284,8 @@ typedef struct XiveTCTX {
 extern const MemoryRegionOps xive_tm_ops;
 
 void xive_tctx_pic_print_info(XiveTCTX *tctx, Monitor *mon);
+Object *xive_tctx_create(Object *cpu, const char *type, XiveRouter *xrtr,
+ Error **errp);
 
 static inline uint32_t xive_tctx_cam_line(uint8_t nvt_blk, uint32_t nvt_idx)
 {
diff --git a/hw/intc/xive.c b/hw/intc/xive.c
index fc6ef5895e6d..7d921023e2ee 100644
--- a/hw/intc/xive.c
+++ b/hw/intc/xive.c
@@ -579,6 +579,27 @@ static const TypeInfo xive_tctx_info = {
 .class_init= xive_tctx_class_init,
 };
 
+Object *xive_tctx_create(Object *cpu, const char *type, XiveRouter *xrtr,
+ Error **errp)
+{
+Error *local_err = NULL;
+Object *obj;
+
+obj = object_new(type);
+object_property_add_child(cpu, type, obj, _abort);
+object_unref(obj);
+object_property_add_const_link(obj, "cpu", cpu, _abort);
+object_property_add_const_link(obj, "xive", OBJECT(xrtr), _abort);
+object_property_set_bool(obj, true, "realized", _err);
+if (local_err) {
+object_unparent(obj);
+error_propagate(errp, local_err);
+return NULL;
+}
+
+return obj;
+}
+
 /*
  * XIVE ESB helpers
  */
diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
index 2398ce62c0e7..1811cd48db90 100644
--- a/hw/ppc/spapr_cpu_core.c
+++ b/hw/ppc/spapr_cpu_core.c
@@ -11,7 +11,6 @@
 #include "hw/ppc/spapr_cpu_core.h"
 #include "target/ppc/cpu.h"
 #include "hw/ppc/spapr.h"
-#include "hw/ppc/xics.h" /* for icp_create() - to be removed */
 #include "hw/boards.h"
 #include "qapi/error.h"
 #include "sysemu/cpus.h"
@@ -215,6 +214,7 @@ static void spapr_cpu_core_unrealize(DeviceState *dev, 
Error **errp)
 static void spapr_realize_vcpu(PowerPCCPU *cpu, sPAPRMachineState *spapr,
sPAPRCPUCore *sc, Error **errp)
 {
+sPAPRMachineClass *smc = SPAPR_MACHINE_GET_CLASS(spapr);
 CPUPPCState *env = >env;
 CPUState *cs = CPU(cpu);
 Error *local_err = NULL;
@@ -233,8 +233,7 @@ static void spapr_realize_vcpu(PowerPCCPU *cpu, 
sPAPRMachineState *spapr,
 qemu_register_reset(spapr_cpu_reset, cpu);
 spapr_cpu_reset(cpu);
 
-cpu->intc = icp_create(OBJECT(cpu), spapr->icp_type, XICS_FABRIC(spapr),
-   _err);
+cpu->intc = smc->irq->cpu_intc_create(spapr, OBJECT(cpu), _err);
 if (local_err) {
 goto error_unregister;
 }
diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
index d88a029d8c5c..253abc10e780 100644
--- a/hw/ppc/spapr_irq.c
+++ b/hw/ppc/spapr_irq.c
@@ -197,6 +197,12 @@ static void spapr_irq_dt_populate_xics(sPAPRMachineState 
*spapr,
 spapr_dt_xics(nr_servers, fdt, phandle);
 }
 
+static Object *spapr_irq_cpu_intc_create_xics(sPAPRMachineState *spapr,
+  Object *cpu, Error **errp)
+{
+return icp_create(cpu, spapr->icp_type, XICS_FABRIC(spapr), errp);
+}
+
 #define SPAPR_IRQ_XICS_NR_IRQS 0x1000
 #define SPAPR_IRQ_XICS_NR_MSIS \
 (XICS_IRQ_BASE + SPAPR_IRQ_XICS_NR_IRQS - SPAPR_IRQ_MSI)
@@ -211,6 +217,7 @@ sPAPRIrq spapr_irq_xics = {
 .qirq= spapr_qirq_xics,
 .print_info  = spapr_irq_print_info_xics,
 .dt_populate = spapr_irq_dt_populate_xics,
+.cpu_intc_create = 

[Qemu-devel] [PATCH v5 07/36] ppc/xive: introduce the XIVE interrupt thread context

2018-11-16 Thread Cédric Le Goater
Each POWER9 processor chip has a XIVE presenter that can generate four
different exceptions to its threads:

  - hypervisor exception,
  - O/S exception
  - Event-Based Branch (EBB)
  - msgsnd (doorbell).

Each exception has a state independent from the others called a Thread
Interrupt Management context. This context is a set of registers which
lets the thread handle priority management and interrupt acknowledgment
among other things. The most important ones being :

  - Interrupt Priority Register  (PIPR)
  - Interrupt Pending Buffer (IPB)
  - Current Processor Priority   (CPPR)
  - Notification Source Register (NSR)

These registers are accessible through a specific MMIO region, called
the Thread Interrupt Management Area (TIMA), four aligned pages, each
exposing a different view of the registers. First page (page address
ending in 0b00) gives access to the entire context and is reserved for
the ring 0 security monitor. The second (page address ending in 0b01)
is for the hypervisor, ring 1. The third (page address ending in 0b10)
is for the operating system, ring 2. The fourth (page address ending
in 0b11) is for user level, ring 3.

The thread interrupt context is modeled with a XiveTCTX object
containing the values of the different exception registers. The TIMA
region is mapped at the same address for each CPU.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/xive.h  |  36 +++
 include/hw/ppc/xive_regs.h |  82 +++
 hw/intc/xive.c | 443 +
 3 files changed, 561 insertions(+)

diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
index 24301bf2076d..5987f26ddb98 100644
--- a/include/hw/ppc/xive.h
+++ b/include/hw/ppc/xive.h
@@ -238,4 +238,40 @@ typedef struct XiveENDSource {
 void xive_end_reset(XiveEND *end);
 void xive_end_pic_print_info(XiveEND *end, uint32_t end_idx, Monitor *mon);
 
+/*
+ * XIVE Thread interrupt Management (TM) context
+ */
+
+#define TYPE_XIVE_TCTX "xive-tctx"
+#define XIVE_TCTX(obj) OBJECT_CHECK(XiveTCTX, (obj), TYPE_XIVE_TCTX)
+
+/*
+ * XIVE Thread interrupt Management register rings :
+ *
+ *   QW-0  User   event-based exception state
+ *   QW-1  O/SOS context for priority management, interrupt acks
+ *   QW-2  Pool   hypervisor context for virtual processor being dispatched
+ *   QW-3  Physical   for the security monitor to manage the entire context
+ */
+#define TM_RING_COUNT   4
+#define TM_RING_SIZE0x10
+
+typedef struct XiveTCTX {
+DeviceState parent_obj;
+
+CPUState*cs;
+qemu_irqoutput;
+
+uint8_t regs[TM_RING_COUNT * TM_RING_SIZE];
+
+XiveRouter  *xrtr;
+} XiveTCTX;
+
+/*
+ * XIVE Thread Interrupt Management Aera (TIMA)
+ */
+extern const MemoryRegionOps xive_tm_ops;
+
+void xive_tctx_pic_print_info(XiveTCTX *tctx, Monitor *mon);
+
 #endif /* PPC_XIVE_H */
diff --git a/include/hw/ppc/xive_regs.h b/include/hw/ppc/xive_regs.h
index f97fb2b90bee..2e3d6cb507da 100644
--- a/include/hw/ppc/xive_regs.h
+++ b/include/hw/ppc/xive_regs.h
@@ -10,6 +10,88 @@
 #ifndef PPC_XIVE_REGS_H
 #define PPC_XIVE_REGS_H
 
+#define TM_SHIFT16
+
+/* TM register offsets */
+#define TM_QW0_USER 0x000 /* All rings */
+#define TM_QW1_OS   0x010 /* Ring 0..2 */
+#define TM_QW2_HV_POOL  0x020 /* Ring 0..1 */
+#define TM_QW3_HV_PHYS  0x030 /* Ring 0..1 */
+
+/* Byte offsets inside a QW QW0 QW1 QW2 QW3 */
+#define TM_NSR  0x0  /*  +   +   -   +  */
+#define TM_CPPR 0x1  /*  -   +   -   +  */
+#define TM_IPB  0x2  /*  -   +   +   +  */
+#define TM_LSMFB0x3  /*  -   +   +   +  */
+#define TM_ACK_CNT  0x4  /*  -   +   -   -  */
+#define TM_INC  0x5  /*  -   +   -   +  */
+#define TM_AGE  0x6  /*  -   +   -   +  */
+#define TM_PIPR 0x7  /*  -   +   -   +  */
+
+#define TM_WORD00x0
+#define TM_WORD10x4
+
+/*
+ * QW word 2 contains the valid bit at the top and other fields
+ * depending on the QW.
+ */
+#define TM_WORD20x8
+#define   TM_QW0W2_VU   PPC_BIT32(0)
+#define   TM_QW0W2_LOGIC_SERV   PPC_BITMASK32(1, 31) /* XX 2,31 ? */
+#define   TM_QW1W2_VO   PPC_BIT32(0)
+#define   TM_QW1W2_OS_CAM   PPC_BITMASK32(8, 31)
+#define   TM_QW2W2_VP   PPC_BIT32(0)
+#define   TM_QW2W2_POOL_CAM PPC_BITMASK32(8, 31)
+#define   TM_QW3W2_VT   PPC_BIT32(0)
+#define   TM_QW3W2_LP   PPC_BIT32(6)
+#define   TM_QW3W2_LE   PPC_BIT32(7)
+#define   TM_QW3W2_TPPC_BIT32(31)
+
+/*
+ * In addition to normal loads to "peek" and writes (only when invalid)
+ * using 4 and 8 bytes accesses, the above registers support these
+ * "special" byte operations:
+ *
+ *   - Byte load from QW0[NSR] - User level NSR (EBB)
+ *   - Byte store to QW0[NSR] - User level NSR (EBB)
+ *   - Byte load/store to QW1[CPPR] and 

[Qemu-devel] [PATCH v5 17/36] spapr: add device tree support for the XIVE exploitation mode

2018-11-16 Thread Cédric Le Goater
The XIVE interface for the guest is described in the device tree under
the "interrupt-controller" node. A couple of new properties are
specific to XIVE :

 - "reg"

   contains the base address and size of the thread interrupt
   managnement areas (TIMA), for the User level and for the Guest OS
   level. Only the Guest OS level is taken into account today.

 - "ibm,xive-eq-sizes"

   the size of the event queues. One cell per size supported, contains
   log2 of size, in ascending order.

 - "ibm,xive-lisn-ranges"

   the IRQ interrupt number ranges assigned to the guest for the IPIs.

and also under the root node :

 - "ibm,plat-res-int-priorities"

   contains a list of priorities that the hypervisor has reserved for
   its own use. OPAL uses the priority 7 queue to automatically
   escalate interrupts for all other queues (DD2.X POWER9). So only
   priorities [0..6] are allowed for the guest.

Extend the sPAPR IRQ backend with a new handler to populate the DT
with the appropriate "interrupt-controller" node.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/spapr_irq.h  |  2 ++
 include/hw/ppc/spapr_xive.h |  2 ++
 hw/intc/spapr_xive_hcall.c  | 62 +
 hw/ppc/spapr.c  |  3 +-
 hw/ppc/spapr_irq.c  | 17 ++
 5 files changed, 85 insertions(+), 1 deletion(-)

diff --git a/include/hw/ppc/spapr_irq.h b/include/hw/ppc/spapr_irq.h
index c854ae527808..cfdc1f86e713 100644
--- a/include/hw/ppc/spapr_irq.h
+++ b/include/hw/ppc/spapr_irq.h
@@ -40,6 +40,8 @@ typedef struct sPAPRIrq {
 void (*free)(sPAPRMachineState *spapr, int irq, int num);
 qemu_irq (*qirq)(sPAPRMachineState *spapr, int irq);
 void (*print_info)(sPAPRMachineState *spapr, Monitor *mon);
+void (*dt_populate)(sPAPRMachineState *spapr, uint32_t nr_servers,
+void *fdt, uint32_t phandle);
 } sPAPRIrq;
 
 extern sPAPRIrq spapr_irq_xics;
diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
index 418511f3dc10..5b3fab192d41 100644
--- a/include/hw/ppc/spapr_xive.h
+++ b/include/hw/ppc/spapr_xive.h
@@ -65,5 +65,7 @@ bool spapr_xive_priority_is_valid(uint8_t priority);
 typedef struct sPAPRMachineState sPAPRMachineState;
 
 void spapr_xive_hcall_init(sPAPRMachineState *spapr);
+void spapr_dt_xive(sPAPRXive *xive, int nr_servers, void *fdt,
+   uint32_t phandle);
 
 #endif /* PPC_SPAPR_XIVE_H */
diff --git a/hw/intc/spapr_xive_hcall.c b/hw/intc/spapr_xive_hcall.c
index 52e4e23995f5..66c78aa88500 100644
--- a/hw/intc/spapr_xive_hcall.c
+++ b/hw/intc/spapr_xive_hcall.c
@@ -890,3 +890,65 @@ void spapr_xive_hcall_init(sPAPRMachineState *spapr)
 spapr_register_hypercall(H_INT_SYNC, h_int_sync);
 spapr_register_hypercall(H_INT_RESET, h_int_reset);
 }
+
+void spapr_dt_xive(sPAPRXive *xive, int nr_servers, void *fdt, uint32_t 
phandle)
+{
+int node;
+uint64_t timas[2 * 2];
+/* Interrupt number ranges for the IPIs */
+uint32_t lisn_ranges[] = {
+cpu_to_be32(0),
+cpu_to_be32(nr_servers),
+};
+uint32_t eq_sizes[] = {
+cpu_to_be32(12), /* 4K */
+cpu_to_be32(16), /* 64K */
+cpu_to_be32(21), /* 2M */
+cpu_to_be32(24), /* 16M */
+};
+/* The following array is in sync with the 'spapr_xive_priority_is_valid'
+ * routine above. The O/S is expected to choose priority 6.
+ */
+uint32_t plat_res_int_priorities[] = {
+cpu_to_be32(7),/* start */
+cpu_to_be32(0xf8), /* count */
+};
+gchar *nodename;
+
+/* Thread Interrupt Management Area : User (ring 3) and OS (ring 2) */
+timas[0] = cpu_to_be64(xive->tm_base + 3 * (1ull << TM_SHIFT));
+timas[1] = cpu_to_be64(1ull << TM_SHIFT);
+timas[2] = cpu_to_be64(xive->tm_base + 2 * (1ull << TM_SHIFT));
+timas[3] = cpu_to_be64(1ull << TM_SHIFT);
+
+nodename = g_strdup_printf("interrupt-controller@%" PRIx64,
+   xive->tm_base + 3 * (1 << TM_SHIFT));
+_FDT(node = fdt_add_subnode(fdt, 0, nodename));
+g_free(nodename);
+
+_FDT(fdt_setprop_string(fdt, node, "device_type", "power-ivpe"));
+_FDT(fdt_setprop(fdt, node, "reg", timas, sizeof(timas)));
+
+_FDT(fdt_setprop_string(fdt, node, "compatible", "ibm,power-ivpe"));
+_FDT(fdt_setprop(fdt, node, "ibm,xive-eq-sizes", eq_sizes,
+ sizeof(eq_sizes)));
+_FDT(fdt_setprop(fdt, node, "ibm,xive-lisn-ranges", lisn_ranges,
+ sizeof(lisn_ranges)));
+
+/* For Linux to link the LSIs to the main interrupt controller.
+ * These properties are not in XIVE exploitation mode sPAPR
+ * specs
+ */
+_FDT(fdt_setprop(fdt, node, "interrupt-controller", NULL, 0));
+_FDT(fdt_setprop_cell(fdt, node, "#interrupt-cells", 2));
+
+/* For SLOF */
+_FDT(fdt_setprop_cell(fdt, node, "linux,phandle", phandle));
+_FDT(fdt_setprop_cell(fdt, node, "phandle", phandle));
+
+/* The "ibm,plat-res-int-priorities" property 

[Qemu-devel] [PATCH v5 33/36] spapr: introduce routines to delete the KVM IRQ device

2018-11-16 Thread Cédric Le Goater
If a new interrupt mode is chosen by CAS, the machine generates a
reset to reconfigure. At this point, the connection with the previous
KVM device needs to be closed and a new connection needs to opened
with the KVM device operating the chosen interrupt mode.

New routines are introduced to destroy the XICS and XIVE KVM
devices. They make use of a new KVM device ioctl which destroys the
device and also disconnects the IRQ presenters from the VCPUs.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/spapr_xive.h |  1 +
 include/hw/ppc/xics.h   |  1 +
 linux-headers/linux/kvm.h   |  2 ++
 hw/intc/spapr_xive_kvm.c| 54 +++
 hw/intc/xics_kvm.c  | 57 +
 5 files changed, 115 insertions(+)

diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
index 1d134a681326..c913c0aed08a 100644
--- a/include/hw/ppc/spapr_xive.h
+++ b/include/hw/ppc/spapr_xive.h
@@ -108,5 +108,6 @@ void spapr_xive_mmio_map(sPAPRXive *xive);
 #define XIVE_TCTX_KVM(obj)   OBJECT_CHECK(XiveTCTX, (obj), TYPE_XIVE_TCTX_KVM)
 
 void spapr_xive_kvm_init(sPAPRXive *xive, Error **errp);
+void spapr_xive_kvm_fini(sPAPRXive *xive, Error **errp);
 
 #endif /* PPC_SPAPR_XIVE_H */
diff --git a/include/hw/ppc/xics.h b/include/hw/ppc/xics.h
index 9958443d1984..a5468c6eb6e3 100644
--- a/include/hw/ppc/xics.h
+++ b/include/hw/ppc/xics.h
@@ -205,6 +205,7 @@ void icp_resend(ICPState *ss);
 typedef struct sPAPRMachineState sPAPRMachineState;
 
 int xics_kvm_init(sPAPRMachineState *spapr, Error **errp);
+int xics_kvm_fini(sPAPRMachineState *spapr, Error **errp);
 void xics_spapr_init(sPAPRMachineState *spapr);
 
 Object *icp_create(Object *cpu, const char *type, XICSFabric *xi,
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index 59fa8d8d7f39..b7a74c58d0db 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -1309,6 +1309,8 @@ struct kvm_s390_ucas_mapping {
 #define KVM_GET_DEVICE_ATTR  _IOW(KVMIO,  0xe2, struct kvm_device_attr)
 #define KVM_HAS_DEVICE_ATTR  _IOW(KVMIO,  0xe3, struct kvm_device_attr)
 
+#define KVM_DESTROY_DEVICE   _IOWR(KVMIO,  0xf0, struct kvm_create_device)
+
 /*
  * ioctls for vcpu fds
  */
diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
index cb2aa6e81274..0672d8bcbc6b 100644
--- a/hw/intc/spapr_xive_kvm.c
+++ b/hw/intc/spapr_xive_kvm.c
@@ -55,6 +55,16 @@ static void kvm_cpu_enable(CPUState *cs)
 QLIST_INSERT_HEAD(_enabled_cpus, enabled_cpu, node);
 }
 
+static void kvm_cpu_disable_all(void)
+{
+KVMEnabledCPU *enabled_cpu, *next;
+
+QLIST_FOREACH_SAFE(enabled_cpu, _enabled_cpus, node, next) {
+QLIST_REMOVE(enabled_cpu, node);
+g_free(enabled_cpu);
+}
+}
+
 /*
  * XIVE Thread Interrupt Management context (KVM)
  */
@@ -864,6 +874,50 @@ void spapr_xive_kvm_init(sPAPRXive *xive, Error **errp)
 kvm_gsi_direct_mapping = true;
 }
 
+void spapr_xive_kvm_fini(sPAPRXive *xive, Error **errp)
+{
+XiveSource *xsrc = >source;
+struct kvm_create_device xive_destroy_device = {
+.fd = xive->fd,
+.type = KVM_DEV_TYPE_XIVE,
+.flags = 0,
+};
+size_t esb_len = (1ull << xsrc->esb_shift) * xsrc->nr_irqs;
+int rc;
+
+/* The KVM XIVE device is not in use */
+if (xive->fd == -1) {
+return;
+}
+
+if (!kvm_enabled() || !kvmppc_has_cap_xive()) {
+error_setg(errp,
+   "IRQ_XIVE capability must be present for KVM XIVE device");
+return;
+}
+
+/* Clear the KVM mapping */
+sysbus_mmio_unmap(SYS_BUS_DEVICE(xsrc), 0);
+munmap(xsrc->esb_mmap, esb_len);
+sysbus_mmio_unmap(SYS_BUS_DEVICE(xive), 0);
+munmap(xive->tm_mmap, 4ull << TM_SHIFT);
+
+/* Destroy the KVM device. This also clears the VCPU presenters */
+rc = kvm_vm_ioctl(kvm_state, KVM_DESTROY_DEVICE, _destroy_device);
+if (rc < 0) {
+error_setg_errno(errp, -rc, "Error on KVM_DESTROY_DEVICE for XIVE");
+}
+close(xive->fd);
+xive->fd = -1;
+
+kvm_kernel_irqchip = false;
+kvm_msi_via_irqfd_allowed = false;
+kvm_gsi_direct_mapping = false;
+
+/* Clear the local list of presenter (hotplug) */
+kvm_cpu_disable_all();
+}
+
 static void spapr_xive_kvm_realize(DeviceState *dev, Error **errp)
 {
 sPAPRXive *xive = SPAPR_XIVE_KVM(dev);
diff --git a/hw/intc/xics_kvm.c b/hw/intc/xics_kvm.c
index eabc901a4556..a7e3ec32a761 100644
--- a/hw/intc/xics_kvm.c
+++ b/hw/intc/xics_kvm.c
@@ -50,6 +50,16 @@ typedef struct KVMEnabledICP {
 static QLIST_HEAD(, KVMEnabledICP)
 kvm_enabled_icps = QLIST_HEAD_INITIALIZER(_enabled_icps);
 
+static void kvm_disable_icps(void)
+{
+KVMEnabledICP *enabled_icp, *next;
+
+QLIST_FOREACH_SAFE(enabled_icp, _enabled_icps, node, next) {
+QLIST_REMOVE(enabled_icp, node);
+g_free(enabled_icp);
+}
+}
+
 /*
  * ICP-KVM
  */
@@ -475,6 +485,53 @@ fail:
 return -1;
 }
 
+int 

[Qemu-devel] [PATCH v5 32/36] spapr/rtas: modify spapr_rtas_register() to remove RTAS handlers

2018-11-16 Thread Cédric Le Goater
Removing RTAS handlers will become necessary when the new pseries
machine supporting multiple interrupt mode is introduced.

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

diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
index d6a0952154ac..e005d5d08151 100644
--- a/hw/ppc/spapr_rtas.c
+++ b/hw/ppc/spapr_rtas.c
@@ -404,7 +404,7 @@ void spapr_rtas_register(int token, const char *name, 
spapr_rtas_fn fn)
 
 token -= RTAS_TOKEN_BASE;
 
-assert(!rtas_table[token].name);
+assert(!name || !rtas_table[token].name);
 
 rtas_table[token].name = name;
 rtas_table[token].fn = fn;
-- 
2.17.2




[Qemu-devel] [PATCH v5 28/36] ppc/xics: introduce a icp_kvm_init() routine

2018-11-16 Thread Cédric Le Goater
This routine gathers all the KVM initialization of the XICS KVM
presenter. It will be useful when the initialization of the KVM XICS
device is moved to a global routine.

Signed-off-by: Cédric Le Goater 
---
 hw/intc/xics_kvm.c | 29 +++--
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/hw/intc/xics_kvm.c b/hw/intc/xics_kvm.c
index e8fa9a53aeba..efad1b19d821 100644
--- a/hw/intc/xics_kvm.c
+++ b/hw/intc/xics_kvm.c
@@ -123,11 +123,8 @@ static void icp_kvm_reset(DeviceState *dev)
 icp_set_kvm_state(ICP(dev), 1);
 }
 
-static void icp_kvm_realize(DeviceState *dev, Error **errp)
+static void icp_kvm_init(ICPState *icp, Error **errp)
 {
-ICPState *icp = ICP(dev);
-ICPStateClass *icpc = ICP_GET_CLASS(icp);
-Error *local_err = NULL;
 CPUState *cs;
 KVMEnabledICP *enabled_icp;
 unsigned long vcpu_id;
@@ -137,12 +134,6 @@ static void icp_kvm_realize(DeviceState *dev, Error **errp)
 abort();
 }
 
-icpc->parent_realize(dev, _err);
-if (local_err) {
-error_propagate(errp, local_err);
-return;
-}
-
 cs = icp->cs;
 vcpu_id = kvm_arch_vcpu_id(cs);
 
@@ -168,6 +159,24 @@ static void icp_kvm_realize(DeviceState *dev, Error **errp)
 QLIST_INSERT_HEAD(_enabled_icps, enabled_icp, node);
 }
 
+static void icp_kvm_realize(DeviceState *dev, Error **errp)
+{
+ICPStateClass *icpc = ICP_GET_CLASS(dev);
+Error *local_err = NULL;
+
+icpc->parent_realize(dev, _err);
+if (local_err) {
+error_propagate(errp, local_err);
+return;
+}
+
+icp_kvm_init(ICP(dev), _err);
+if (local_err) {
+error_propagate(errp, local_err);
+return;
+}
+}
+
 static void icp_kvm_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
-- 
2.17.2




[Qemu-devel] [PATCH v5 35/36] ppc: externalize ppc_get_vcpu_by_pir()

2018-11-16 Thread Cédric Le Goater
We will use it to get the CPU interrupt presenter in XIVE.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/ppc.h |  1 +
 hw/ppc/pnv.c | 16 
 hw/ppc/ppc.c | 16 
 3 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/include/hw/ppc/ppc.h b/include/hw/ppc/ppc.h
index 298ec354a8a8..daaa04a22dbf 100644
--- a/include/hw/ppc/ppc.h
+++ b/include/hw/ppc/ppc.h
@@ -4,6 +4,7 @@
 #include "target/ppc/cpu-qom.h"
 
 void ppc_set_irq(PowerPCCPU *cpu, int n_IRQ, int level);
+PowerPCCPU *ppc_get_vcpu_by_pir(int pir);
 
 /* PowerPC hardware exceptions management helpers */
 typedef void (*clk_setup_cb)(void *opaque, uint32_t freq);
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 346f5e7aedb5..66f2301b4ece 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1070,22 +1070,6 @@ static void pnv_ics_resend(XICSFabric *xi)
 }
 }
 
-static PowerPCCPU *ppc_get_vcpu_by_pir(int pir)
-{
-CPUState *cs;
-
-CPU_FOREACH(cs) {
-PowerPCCPU *cpu = POWERPC_CPU(cs);
-CPUPPCState *env = >env;
-
-if (env->spr_cb[SPR_PIR].default_value == pir) {
-return cpu;
-}
-}
-
-return NULL;
-}
-
 static ICPState *pnv_icp_get(XICSFabric *xi, int pir)
 {
 PowerPCCPU *cpu = ppc_get_vcpu_by_pir(pir);
diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c
index ec4be25f4994..9292f986eba7 100644
--- a/hw/ppc/ppc.c
+++ b/hw/ppc/ppc.c
@@ -1358,3 +1358,19 @@ void PPC_debug_write (void *opaque, uint32_t addr, 
uint32_t val)
 break;
 }
 }
+
+PowerPCCPU *ppc_get_vcpu_by_pir(int pir)
+{
+CPUState *cs;
+
+CPU_FOREACH(cs) {
+PowerPCCPU *cpu = POWERPC_CPU(cs);
+CPUPPCState *env = >env;
+
+if (env->spr_cb[SPR_PIR].default_value == pir) {
+return cpu;
+}
+}
+
+return NULL;
+}
-- 
2.17.2




Re: [Qemu-devel] [PATCH v5 22/24] hw: pci-host: piix: Return PCI host pointer instead of PCI bus

2018-11-16 Thread Igor Mammedov
On Mon,  5 Nov 2018 02:40:45 +0100
Samuel Ortiz  wrote:

All remaining patches a bit out of proper order,
they should be around patch 12/24 where you started to touch MCFG code.

> For building the MCFG table, we need to track a given machine
> type PCI host pointer, and we can't get it from the bus pointer alone.
> As piix returns a PCI bus pointer, we simply modify its builder to
> return a PCI host pointer instead.
PC machine doesn't build MCFG so we don't really need it to provide
this pointer, having this patch doesn't hurt but I'm not sure we
need it.

CCing ARM folks since we are talking about generalizing MCFG table generation.

we have following invariants wrt using MCFG:

   pc [pci_host != NULL] -> bail out early + do not build MCFG

   pc [pci_host == NULL] -> would explode if not only for [has_acpi_build = 
false] guard
should be: do not even call acpi_get_mcfg().

   q35 [pci_host == NULL] -> not valid combo and must assert

   q35 [pci_host != NULL && mcfg_base != PCIE_BASE_ADDR_UNMAPPED]
generate MCFG using mcfg_base/size

   q35 [pci_host != NULL && mcfg_base == PCIE_BASE_ADDR_UNMAPPED]
generate place-holder 'QEMU' table for legacy machine versions without
resizable MemoryRegion support.
Mapped/not mapped could be dynamic accross reboots, so we need
access to PCIE(pci_host) to fetch current values.

   arm/virt gpex [memmap[ecam_id].base/size] do build MCFG
hacked up variant that doesn't use pci_host mcfg_base/size fields
not sure if it's possible to disable ecam as on q35 (does it need any 
fixing?)
we should fix arm/virt to use pci-host mcfg_base/size so we
could reuse properties PCIE_HOST_MCFG_BASE/PCIE_HOST_MCFG_SIZE
on ARM and generic build_mcfg()

So we have quite a mess here, the current acpi_get_mcfg() does 2 things
  1. indirectly checks that pci_host is PCI-E (presence of PCIE_HOST_MCFG_BASE 
property)
  2. fetches mcfg_base/size if it's PCI-E host

and i386/build_mcfg() is called only when #1 is true

As far as see we use pci_host only to fetch mcfg_base/size and not for anything
else.
Maybe as refactoring plan we should"
 * pass to acpi_setup(PCIHostState* pcie_host) as an argument pcie host pointer,
   which for PC will be NULL and for the rest set it to q35/gxpe/... PCI-E host.
 * call build_mcfg() if pcie_host != NULL
   (no more indirect guessing using PCIE_HOST_MCFG_BASE property presence)
 * move MCFG/QEMU table signature decision out of build_mcfg() and pass
   it as argument 'build_mcfg(...,char *mcfg_signature)'. It moves out masking
   table quirk into caller, where q35 can decide to change signature
   if ECAM is not mapped. The rest (arm|i386/virt) will always pass 'MCFG'.
   Or even better if ecam is mapped, create MCFG (with masking trick if q35
   machine is old and do not support resizable MemoryRegions).

> Signed-off-by: Samuel Ortiz 
> ---
>  include/hw/i386/pc.h | 21 +++--
>  hw/i386/pc_piix.c| 18 +++---
>  hw/pci-host/piix.c   | 24 
>  3 files changed, 34 insertions(+), 29 deletions(-)
> 
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index 8e5f1464eb..b6b79e146d 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -244,16 +244,17 @@ typedef struct PCII440FXState PCII440FXState;
>   */
>  #define RCR_IOPORT 0xcf9
>  
> -PCIBus *i440fx_init(const char *host_type, const char *pci_type,
> -PCII440FXState **pi440fx_state, int *piix_devfn,
> -ISABus **isa_bus, qemu_irq *pic,
> -MemoryRegion *address_space_mem,
> -MemoryRegion *address_space_io,
> -ram_addr_t ram_size,
> -ram_addr_t below_4g_mem_size,
> -ram_addr_t above_4g_mem_size,
> -MemoryRegion *pci_memory,
> -MemoryRegion *ram_memory);
> +struct PCIHostState *i440fx_init(const char *host_type, const char *pci_type,
> + PCII440FXState **pi440fx_state,
> + int *piix_devfn,
> + ISABus **isa_bus, qemu_irq *pic,
> + MemoryRegion *address_space_mem,
> + MemoryRegion *address_space_io,
> + ram_addr_t ram_size,
> + ram_addr_t below_4g_mem_size,
> + ram_addr_t above_4g_mem_size,
> + MemoryRegion *pci_memory,
> + MemoryRegion *ram_memory);
>  
>  /* piix4.c */
>  extern PCIDevice *piix4_dev;
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 0620d10715..f5b139a3eb 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -32,6 +32,7 @@
>  #include "hw/display/ramfb.h"
>  #include "hw/smbios/smbios.h"
>  #include 

Re: [Qemu-devel] [PATCH v4] hw/arm: Add arm SBSA reference machine

2018-11-16 Thread Peter Maydell
On 16 November 2018 at 10:46, Hongbo Zhang  wrote:
> On Fri, 16 Nov 2018 at 00:05, Peter Maydell  wrote:
>> If after you've done that this patch is still more than
>> about 500 lines long, I would recommend that you split it
>> up into coherent pieces, to make it easier to review.

> I think however I re-work this file, it is still more than 500 lines.
> If split it, then how? one for most basic skeleton, including memory
> map, class and instance init etc, and another adding peripheral
> devices, like pcie etc?

Yes, that's a reasonable split.

>> This is still generating a lot of device tree nodes.
>> I thought we had agreed that we were going to just have
>> a minimal device tree that says "here is the RAM" and nothing
>> else ?
>>
> If I remember correct, it was not only the RAM, but also the CPUs
> because it depends on the command parameters dynamically, and also the
> GIC as well since it depends on the CPU number.
> And should NUMA info if used, be added to DT?
> And by the way, I didn't find the RAM size info in the DT.

You should include the absolute minimum you need that you
cannot either say "we know what this value is because we
know the board" or probe for anyway. I think that is basically
ram inf and number of CPUs. (Ram size and numa configuration
is added to the dtb by the hw/arm/boot.c code, which sets up
the "/memory" nodes.)

You shouldn't need to put the GIC info into the DT, because
you can just hard code into UEFI where it is in memory.

>> > +static void create_ehci(const VirtMachineState *vms, qemu_irq *pic)
>> > +{
>> > +hwaddr base = vms->memmap[VIRT_EHCI].base;
>> > +int irq = vms->irqmap[VIRT_EHCI];
>> > +USBBus *usb_bus;
>> > +
>> > +sysbus_create_simple("exynos4210-ehci-usb", base, pic[irq]);
>>
>> What is this using the exynos4210 USB device for? That
>> is definitely not correct for a generic board.
>>
> Checked the code:
> #define TYPE_SYS_BUS_EHCI "sysbus-ehci-usb"
> #define TYPE_EXYNOS4210_EHCI "exynos4210-ehci-usb"
> #define TYPE_TEGRA2_EHCI "tegra2-ehci-usb"
> #define TYPE_PPC4xx_EHCI "ppc4xx-ehci-usb"
> #define TYPE_FUSBH200_EHCI "fusbh200-ehci-usb"
>
> The first one seems only a parent type, not a general instance, cannot
> be used directly.
> The other four are specific instances using the first as parent type,
> one of them can be chosen to use.
> That is my understanding, any comments, or do we need to implement one
> which seems generic?

You need to work out what you want and implement that;
I don't really know enough about USB to advise.
You probably also need to consider how you want
the USB companion chip stuff to work -- I know that
we've had a bug report that the Exynos4210 USB setup
is not getting that right, so it may be a poor example
to copy from.

>> > +
>> > +usb_bus = usb_bus_find(-1);
>> > +usb_create_simple(usb_bus, "usb-kbd");
>> > +usb_create_simple(usb_bus, "usb-mouse");
>>
>> Don't create USB devices by default -- let the user do it on
>> the command line.
>>
> Some users hope that, I can remove it if not reasonable.

Almost no other board models do it (only a few PPC ones
and an sh4 board). Generally for QEMU the approach we take
is that we don't provide defaults, we expect the user
(or the 'management layer' software like libvirt) to
specify what they want. This allows users to specify that
they *don't* want a usb keyboard, for instance.

>> > +/* If we have an EL3 boot ROM then the assumption is that it will
>> > + * implement PSCI itself, so disable QEMU's internal implementation
>> > + * so it doesn't get in the way. Instead of starting secondary
>> > + * CPUs in PSCI powerdown state we will start them all running and
>> > + * let the boot ROM sort them out.
>> > + * The usual case is that we do use QEMU's PSCI implementation;
>> > + * if the guest has EL2 then we will use SMC as the conduit,
>> > + * and otherwise we will use HVC (for backwards compatibility and
>> > + * because if we're using KVM then we must use HVC).
>> > + */
>> > +if (vms->secure && firmware_loaded) {
>> > +vms->psci_conduit = QEMU_PSCI_CONDUIT_DISABLED;
>> > +} else if (vms->virt) {
>> > +vms->psci_conduit = QEMU_PSCI_CONDUIT_SMC;
>> > +} else {
>> > +vms->psci_conduit = QEMU_PSCI_CONDUIT_HVC;
>> > +}
>>
>> Do you actually intend this to work in all these cases? I
>> thought the intention was "always start the boot rom in EL3"
>> for this board, like the real hardware would. In that case, most
>> of these if clauses are dead code.
>>
> Well, I myself prefer "always enable EL3" too.
> But during this work, I found that if EL2/EL3 enabled, QEMU runs much
> slower than without EL2/3, so I guess if there would be some user of
> this platform, for the reason of speed they choose to disable EL2/3,
> should we give them such a chance?
> If get confirmation that we always enable EL2/3, that is fine for me,
> this will make codes cleaner.
>
> (By the way, I wonder 

Re: [Qemu-devel] [PATCH v2 01/12] i2c: Split smbus into parts

2018-11-16 Thread Corey Minyard

On 11/15/18 4:22 PM, Philippe Mathieu-Daudé wrote:

On 15/11/18 20:24, miny...@acm.org wrote:

From: Corey Minyard 

smbus.c and smbus.h had device side code, master side code, and
smbus.h has some smbus_eeprom.c definitions.  Split them into
separate files.


Lovely cleanup!


Yes, this really needed to be done.  It took me a while to understand
this code originally because it was all mixed up.

I've fixed the things you pointed out.  One thing, though:




diff --git a/include/hw/i2c/smbus_eeprom.h 
b/include/hw/i2c/smbus_eeprom.h

new file mode 100644
index 00..2f56e5dc4e
--- /dev/null
+++ b/include/hw/i2c/smbus_eeprom.h
@@ -0,0 +1,11 @@


You missed the copyright notice here.


Other files don't have copyright notices (i2c.h, for instance), and for
the smbus.[ch] case the copyrights are kind of mixed up, the include
files had the big header with a copyright by one company and the C
file had a different copyright notice by a different company.

Not a huge deal, but I didn't include it in that file because I didn't
think it was necessary.  I'm wondering if it would be best to
establish a style like Linux has, with the // SPDX... thing on the
first line.

Thanks,

-corey




[Qemu-devel] [PULL 0/3] Fixes 31 20181116 patches

2018-11-16 Thread Gerd Hoffmann
The following changes since commit cb968d275c145467c8b385a3618a207ec111eab1:

  Update version for v3.1.0-rc1 release (2018-11-13 18:16:14 +)

are available in the git repository at:

  git://git.kraxel.org/qemu tags/fixes-31-20181116-pull-request

for you to fetch changes up to 144aaa990e0d54d08865c4d98ba2138a89689530:

  help: Provide help for egl-headless (2018-11-16 11:44:22 +0100)


ui: add rendernode arg for egl-headless (fixes permission issues with libvirt)



Erik Skultety (3):
  qapi: Add "rendernode" display option for egl-headless
  ui: Allow specifying 'rendernode' display option for egl-headless
  help: Provide help for egl-headless

 ui/egl-headless.c |  2 +-
 qapi/ui.json  | 17 -
 qemu-options.hx   |  6 +-
 3 files changed, 22 insertions(+), 3 deletions(-)

-- 
2.9.3




[Qemu-devel] [PULL 3/3] help: Provide help for egl-headless

2018-11-16 Thread Gerd Hoffmann
From: Erik Skultety 

EGL headless has been missing from QEMU's help or man page, we should
mention that such a thing exists, especially since projects like libvirt
might rely on that. This patch also adds the newly introduced option for
egl-headless 'rendernode'.

Signed-off-by: Erik Skultety 
Message-id: 
87ef678b0934d3abba66c46c9e65b57119d29295.1542362949.git.eskul...@redhat.com
Signed-off-by: Gerd Hoffmann 
---
 qemu-options.hx | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index ee379b32e3..f7df472f43 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1216,7 +1216,8 @@ DEF("display", HAS_ARG, QEMU_OPTION_display,
 "-display gtk[,grab_on_hover=on|off][,gl=on|off]|\n"
 "-display vnc=[,]\n"
 "-display curses\n"
-"-display none"
+"-display none\n"
+"-display egl-headless[,rendernode=]"
 "select display type\n"
 "The default display is equivalent to\n"
 #if defined(CONFIG_GTK)
@@ -1258,6 +1259,9 @@ menus and other UI elements to configure and control the 
VM during
 runtime.
 @item vnc
 Start a VNC server on display 
+@item egl-headless
+Offload all OpenGL operations to a local DRI device. For any graphical display,
+this display needs to be paired with either VNC or SPICE displays.
 @end table
 ETEXI
 
-- 
2.9.3




[Qemu-devel] [PULL 1/3] qapi: Add "rendernode" display option for egl-headless

2018-11-16 Thread Gerd Hoffmann
From: Erik Skultety 

Unlike SPICE, egl-headless doesn't offer a way of specifying the DRM
node used for OpenGL, hence QEMU always selecting the first one that is
available. Thus, add the 'rendernode' option for egl-headless to QAPI.

Signed-off-by: Erik Skultety 
Message-id: 
7658e15eca72d520e7a5fb1c2e724702d83d4f7f.1542362949.git.eskul...@redhat.com
Signed-off-by: Gerd Hoffmann 
---
 qapi/ui.json | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/qapi/ui.json b/qapi/ui.json
index bf9e157d5a..e248d3 100644
--- a/qapi/ui.json
+++ b/qapi/ui.json
@@ -1037,6 +1037,20 @@
   'data': { '*grab-on-hover' : 'bool',
 '*zoom-to-fit'   : 'bool'  } }
 
+##
+# @DisplayEGLHeadless:
+#
+# EGL headless display options.
+#
+# @rendernode: Which DRM render node should be used. Default is the first
+#  available node on the host.
+#
+# Since: 3.1
+#
+##
+{ 'struct'  : 'DisplayEGLHeadless',
+  'data': { '*rendernode' : 'str' } }
+
  ##
  # @DisplayGLMode:
  #
@@ -1086,4 +1100,5 @@
 '*window-close'  : 'bool',
 '*gl': 'DisplayGLMode' },
   'discriminator' : 'type',
-  'data': { 'gtk': 'DisplayGTK' } }
+  'data': { 'gtk': 'DisplayGTK',
+'egl-headless'   : 'DisplayEGLHeadless'} }
-- 
2.9.3




[Qemu-devel] [PULL 2/3] ui: Allow specifying 'rendernode' display option for egl-headless

2018-11-16 Thread Gerd Hoffmann
From: Erik Skultety 

As libvirt can't predict which rendernode QEMU would pick, it
won't adjust the permissions on the device, hence QEMU getting
"Permission denied" when opening the DRI device. Therefore, enable
'rendernode' option for egl-headless display type.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1648236

Signed-off-by: Erik Skultety 
Message-id: 
27f4617f19aa1072114f10f1aa9dd199735ef982.1542362949.git.eskul...@redhat.com
Signed-off-by: Gerd Hoffmann 
---
 ui/egl-headless.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ui/egl-headless.c b/ui/egl-headless.c
index 42a41310b0..4cf3bbc0e4 100644
--- a/ui/egl-headless.c
+++ b/ui/egl-headless.c
@@ -176,7 +176,7 @@ static void egl_headless_init(DisplayState *ds, 
DisplayOptions *opts)
 egl_dpy *edpy;
 int idx;
 
-if (egl_rendernode_init(NULL, mode) < 0) {
+if (egl_rendernode_init(opts->u.egl_headless.rendernode, mode) < 0) {
 error_report("egl: render node init failed");
 exit(1);
 }
-- 
2.9.3




Re: [Qemu-devel] [PATCH v2 00/12] RFC: Fix/add vmstate handling in some I2C code

2018-11-16 Thread Corey Minyard

On 11/15/18 5:01 PM, Philippe Mathieu-Daudé wrote:

Hi Corey,

On 15/11/18 20:24, miny...@acm.org wrote:

These changes allow SMBus access while doing a state transfer.
Seems like a good idea to me in general.

I have these queued for the SMBus IPMI driver work, of course.

I had submitted this before and then lost track of the work since I
started finding all kinds of broken things in the I2C code.  I
have fixed the broken things I found first, and then added the
previous patches.

I have tested this in q35 and it works without issue.  On piix4 the
pm_smbus code is broken on a migration, however. The device disappears
from the PCI bus on a migration, from what I can tell.  It's not the
fault of this code, something more fundamental is going on.  The
following comment in piix4.c may have something to do with it:

/* qemu-kvm 1.2 uses version 3 but advertised as 2
  * To support incoming qemu-kvm 1.2 migration, change version_id
  * and minimum_version_id to 2 below (which breaks migration from
  * qemu 1.2).

Anyway, I need to chase that down.

I'm primarily submitting this to make sure I'm doing the backwards
compatability with .needed correctly.  I'm adding a new field in
the machine class and setting it in the initialization code for
older versions.  David, is this what you wanted?  It will have to
be adjusted for the proper version if/when it really goes in, of
course.  You can see those in the following commits:
   boards.h: Ignore migration for SMBus devices on
   i2c:pm_smbus: Fix state transfer
   i2c: Add vmstate handling to the smbus eeprom
I thought about adding a field to the pm_smbus code to only transfer
if it was accessed, but I'm assuming that most modern OSes will
at least initialized the device based on its presence on the PCI
bus.  So that didn't seem like it would add any value.

I'm also submitting to see if all the fixes and cleanups look ok.
That's the first 5 commits.


$ git diff origin/master --summary
 delete mode 100644 hw/i2c/smbus.c
 create mode 100644 hw/i2c/smbus_master.c
 create mode 100644 hw/i2c/smbus_slave.c
 create mode 100644 include/hw/i2c/smbus_eeprom.h
 rename include/hw/i2c/{smbus.h => smbus_master.h} (56%)
 create mode 100644 include/hw/i2c/smbus_slave.h

Can you add the following files in the MAINTAINERS file:
- hw/i2c/smbus_master.c
- hw/i2c/smbus_slave.c
- include/hw/i2c/smbus_eeprom.h
- include/hw/i2c/smbus_master.h
- include/hw/i2c/smbus_slave.h


Ok, but who should the maintainer be?  I guess I can take
it, if that is what you are implying.  But most of the files in
i2c are not maintained.

Thanks,

-corey




Re: [Qemu-devel] [Qemu-block] [PATCH v5 2/3] file-posix: Drop s->lock_fd

2018-11-16 Thread Max Reitz
On 14.11.18 14:54, Alberto Garcia wrote:
> On Thu 11 Oct 2018 09:21:34 AM CEST, Fam Zheng wrote:
>> The lock_fd field is not strictly necessary because transferring locked
>> bytes from old fd to the new one shouldn't fail anyway. This spares the
>> user one fd per image.
>>
>> Signed-off-by: Fam Zheng 
>> Reviewed-by: Max Reitz 
> 
> One of my tests (not published yet) starts to fail after this
> patch. Here's how you can reproduce the error:
> 
> $ qemu-img create -f qcow2 hd.qcow2 4G
> $ qemu-system-x86_64 -qmp stdio
> 
> { "execute": "qmp_capabilities" }
> { "execute": "blockdev-add", "arguments": {"driver": "qcow2", "node-name": 
> "hd0", "file": {"driver": "file", "filename": "hd.qcow2", "locking": "on" }}}
> { "execute": "human-monitor-command", "arguments": {"command-line": "qemu-io 
> hd0 \"reopen -o file.locking=on\""}}
> { "execute": "human-monitor-command", "arguments": {"command-line": "qemu-io 
> hd0 \"reopen -o file.locking=off\""}}
> { "execute": "blockdev-del", "arguments": {"node-name": "hd0"}}
> { "execute": "blockdev-add", "arguments": {"driver": "qcow2", "node-name": 
> "hd0", "file": {"driver": "file", "filename": "hd.qcow2"}}}
> 
> {"error": {"class": "GenericError", "desc": "Failed to get \"consistent 
> read\" lock"}}

To me that looks like a problem in the general reopen code.
raw_reopen_prepare() is called and succeeds.  Then bdrv_reopen_prepare()
notices the option wasn't handled and therefore fails.
bdrv_reopen_multiple() thus doesn't set bs_entry->prepared to true,
which means raw_reopen_abort() won't be called.

We should always call either BlockDriver.bdrv_reopen_commit() or
BlockDriver.bdrv_reopen_abort() when BlockDriver.bdrv_reopen_prepare()
succeeded.

Max



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH 3/4] target/arm: Install ASIDs for short-form from EL1

2018-11-16 Thread Peter Maydell
On 29 October 2018 at 15:53, Richard Henderson
 wrote:
> This is less complex than the LPAE case, but still we now avoid the
> flush in case it is only the PROCID field that is changing.
>
> Signed-off-by: Richard Henderson 
> ---
>  target/arm/helper.c | 34 --
>  1 file changed, 24 insertions(+), 10 deletions(-)
>
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index 26d6f28793..f767467dcf 100644
> --- a/target/arm/helper.c
> +++ b/target/arm/helper.c
> @@ -541,17 +541,31 @@ static void fcse_write(CPUARMState *env, const 
> ARMCPRegInfo *ri, uint64_t value)
>  static void contextidr_write(CPUARMState *env, const ARMCPRegInfo *ri,
>   uint64_t value)
>  {
> -ARMCPU *cpu = arm_env_get_cpu(env);
> -
> -if (raw_read(env, ri) != value && !arm_feature(env, ARM_FEATURE_PMSA)
> -&& !extended_addresses_enabled(env)) {
> -/* For VMSA (when not using the LPAE long descriptor page table
> - * format) this register includes the ASID, so do a TLB flush.
> - * For PMSA it is purely a process ID and no action is needed.
> - */
> -tlb_flush(CPU(cpu));
> -}
>  raw_write(env, ri, value);
> +
> +/*
> + * For VMSA (when not using the LPAE long descriptor page table format)
> + * this register includes the ASID.  For PMSA it is purely a process ID
> + * and no action is needed.
> + */

I've now thought about this a bit and read through some of
the relevant bits of the Arm ARM. My updated opinion is below:

General principles first:
 * the set of MMU indexes we need to do a set-asid or flush for
depends on the register being written (and not the context
from which it is being written), ie your remarks to this effect
in the cover letter are correct
 * for some registers the register is used by translations in
exactly one translation regime, and therefore the situation is
simple (eg TTBR(S) is only used by S1E3|S1SE0)
 * for some registers the same register may be used by more than
one translation regime, eg AArch64 CONTEXTIDR_EL1 written from
EL3 may be because we're setting up the translation regime
for Secure EL1&0 (ie S1SE1|S1SE0) or for NS EL1&0 (S12NSE1|S12NSE0),
and we can't tell which at this point.

> +if (!arm_feature(env, ARM_FEATURE_PMSA) &&
> +!extended_addresses_enabled(env)) {

The current definition of extended_addresses_enabled(), which
is used only here, is:

static inline bool extended_addresses_enabled(CPUARMState *env)
{
TCR *tcr = >cp15.tcr_el[arm_is_secure(env) ? 3 : 1];
return arm_el_is_aa64(env, 1) ||
   (arm_feature(env, ARM_FEATURE_LPAE) && (tcr->raw_tcr & TTBCR_EAE));
}

This is bogus both because of that hardcoded '1' argument to
arm_el_is_aa64() and also because it's asking a question about
the current state of the CPU, whereas what we'd like to know
is whether the translation regime affected by the register
which we are changing is using extended addressing.
We also need to make sure that any state we depend upon here
when determining which indexes to flush is either:
 * in the list of things the architecture says can be
   cached in a tlb and so the guest is going to have
   to do tlb maintenance ops if they change it
 * something that causes QEMU to do a tlb flush or asid update
   if it changes

We should fix the condition we're checking, and I think also
just do it inline here and get rid of extended_addresses_enabled(),
which looks like a general-purpose utility function but isn't.
(We've previously managed to get rid of all the other uses
of it, which were generally bugs.)

> +CPUState *cs = CPU(arm_env_get_cpu(env));
> +int asid = extract32(value, 0, 8);
> +int idxmask;
> +
> +switch (ri->secure) {
> +case ARM_CP_SECSTATE_S:
> +idxmask = ARMMMUIdxBit_S1SE1 | ARMMMUIdxBit_S1SE0;

This must be TTBR(S), which means EL3 must be AArch32 and we're
in Secure EL3 (aka Secure PL1), and the ASID here affects only
S1E3|SESE0.

> +break;
> +case ARM_CP_SECSTATE_NS:
> +idxmask = ARMMMUIdxBit_S12NSE1 | ARMMMUIdxBit_S12NSE0;

There are two possibilities here:
 * EL3 is AArch32: this must be TTBR(NS), in which case it affects
   S12NSE1|S12NSE0
 * EL3 is AArch64, in which case this is the one and only
   CONTEXTIDR_EL1 (whether we're accessing it from AArch32 or
   AArch64), and it affects either S1SE1|S1SE0 or S12NSE1|S12NSE0.
   If we're executing at EL2 or below then we can know which
   of those two is affected (it will be the current CPU state),
   but we can't set-asid just the one that is affected unless we're
   also willing to arrange to do a set-asid for the other security
   state when we transition into EL3. (Otherwise "be in NS EL1;
   set CONTEXTIDR_EL1; go to EL3; set S bit; go to S EL1" will
   take you to S EL1 with a new CONTEXTIDR value without having
   updated the ASID for its MMU indexes.)
   (If we have no EL3 at all then 

Re: [Qemu-devel] [PATCH v4] Add arm SBSA reference machine

2018-11-16 Thread Peter Maydell
On 16 November 2018 at 08:23, Hongbo Zhang  wrote:
> Well, for the SMP booting, when GICv2 used, there is no problem, max
> CPU number 8 can be booted, including all the three cases: kernel
> only, UEFI+kernel and ATF+UEFI+kernel.
>
> But when GICv3 used, these two cases still work: kernel only, and
> UEFI+kernel, but ATF+UEFI+kernel fails booting more than 4 cores with
> GICv3.
> The original ATF didn't support GICv3, so I added the support:
> http://git.linaro.org/people/hongbo.zhang/atf-sbsa.git/log/?h=sbsa_gicv3
>
> Root cause of failing to boot more than 4 cores with ATF+UEFI+kernel
> with my GICv3 enabled is due to this:
> In QEMU, we have this defination
> #define ARM_DEFAULT_CPUS_PER_CLUSTER 8
> But in ATF, the defination is
> #define PLATFORM_MAX_CPUS_PER_CLUSTER 4
> So when we pass smp=6 for example, QEMU generates MPIDR showing all
> the 6 cores are at cluster 0, but when ATF parses such MPIDR, the
> function plat_core_pos_by_mpidr() in plat/qemu/topology.c returns
> error since there should be no more cores than 4.
>
> I think we should change the definition in QEMU to 4, instead of
> changing the ATF's, because I checked Cortext a57/a72/a73/a75 spec, it
> says there are 4 cores max at one cluster.

Architecturally 8 per cluster is entirely legal. This is
an ATF limitation and there's an argument for fixing it there.
However, since for this board we're trying to match what real
hardware with these CPUs would look like, it does make sense
to use the same number of CPUs per cluster as the hardware.
If you want your board to instantiate 4 per cluster this is possible,
and you don't need to change ARM_DEFAULT_CPUS_PER_CLUSTER.
This value is only used if the board code does not set the
cpu->mp_affinity value itself (it is the default, as the
name suggests). So you can just make your board code set
the mp_affinity up however you like, after the CPU object
is created but before it is realized.

thanks
-- PMM



Re: [Qemu-devel] [PATCH v6 07/16] gdbstub: add multiprocess support to (f|s)ThreadInfo and ThreadExtraInfo

2018-11-16 Thread Edgar E. Iglesias
On Thu, Nov 15, 2018 at 10:41:58AM +0100, Luc Michel wrote:
> Change the thread info related packets handling to support multiprocess
> extension.
> 
> Add the CPUs class name in the extra info to help differentiate
> them in multiprocess mode.
> 
> Signed-off-by: Luc Michel 
> Reviewed-by: Philippe Mathieu-Daudé 
> ---
>  gdbstub.c | 35 +--
>  1 file changed, 25 insertions(+), 10 deletions(-)
> 
> diff --git a/gdbstub.c b/gdbstub.c
> index d19b0137e8..292dee8914 100644
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -1260,11 +1260,10 @@ out:
>  static int gdb_handle_packet(GDBState *s, const char *line_buf)
>  {
>  CPUState *cpu;
>  CPUClass *cc;
>  const char *p;
> -uint32_t thread;
>  uint32_t pid, tid;
>  int ch, reg_size, type, res;
>  uint8_t mem_buf[MAX_PACKET_LENGTH];
>  char buf[sizeof(mem_buf) + 1 /* trailing NUL */];
>  char thread_id[16];
> @@ -1556,30 +1555,46 @@ static int gdb_handle_packet(GDBState *s, const char 
> *line_buf)
>  snprintf(buf, sizeof(buf), "QC%s",
>   gdb_fmt_thread_id(s, cpu, thread_id, 
> sizeof(thread_id)));
>  put_packet(s, buf);
>  break;
>  } else if (strcmp(p,"fThreadInfo") == 0) {
> -s->query_cpu = first_cpu;
> +s->query_cpu = gdb_first_cpu(s);
>  goto report_cpuinfo;
>  } else if (strcmp(p,"sThreadInfo") == 0) {
>  report_cpuinfo:
>  if (s->query_cpu) {
> -snprintf(buf, sizeof(buf), "m%x", 
> cpu_gdb_index(s->query_cpu));
> +snprintf(buf, sizeof(buf), "m%s",
> + gdb_fmt_thread_id(s, s->query_cpu,
> +   thread_id, sizeof(thread_id)));
>  put_packet(s, buf);
> -s->query_cpu = CPU_NEXT(s->query_cpu);
> +s->query_cpu = gdb_next_cpu(s, s->query_cpu);
>  } else
>  put_packet(s, "l");
>  break;
>  } else if (strncmp(p,"ThreadExtraInfo,", 16) == 0) {
> -thread = strtoull(p+16, (char **), 16);
> -cpu = find_cpu(thread);
> +if (read_thread_id(p + 16, , , ) == 
> GDB_READ_THREAD_ERR) {
> +put_packet(s, "E22");
> +break;
> +}
> +cpu = gdb_get_cpu(s, pid, tid);
>  if (cpu != NULL) {
>  cpu_synchronize_state(cpu);
> -/* memtohex() doubles the required space */
> -len = snprintf((char *)mem_buf, sizeof(buf) / 2,
> -   "CPU#%d [%s]", cpu->cpu_index,
> -   cpu->halted ? "halted " : "running");
> +
> +if (s->multiprocess && (s->process_num > 1)) {
> +/* Print the CPU model in multiprocess mode */
> +ObjectClass *oc = object_get_class(OBJECT(cpu));
> +const char *cpu_model = object_class_get_name(oc);
> +len = snprintf((char *)mem_buf, sizeof(buf) / 2,
> +   "CPU#%d %s [%s]", cpu->cpu_index,
> +   cpu_model,
> +   cpu->halted ? "halted " : "running");



I wonder if we could also print a friendly name here deducted from QOM?
In some of our use-cases we have an array of MicroBlazes that all live
in different HW subsystems and are named differently (e.g CSU, PMU, PMC,
PSM etc).

Instead of just seeing a list of MicroBlaze cores it may be more useful
to see the actual core name of some sort, e.g:

Instead of:
CPU#0 MicroBlaze [running]
CPU#1 MicroBlaze [running]
CPU#2 MicroBlaze [running]
CPU#3 MicroBlaze [running]

Perhaps something like:
CPU#0 MicroBlaze PMU [running]
CPU#1 MicroBlaze PMC-PPU0 [running]
CPU#2 MicroBlaze PMC-PPU1 [running]
CPU#3 MicroBlaze PSM [running]

Any thoughts on that?

Thanks,
Edgar

> +} else {
> +/* memtohex() doubles the required space */
> +len = snprintf((char *)mem_buf, sizeof(buf) / 2,
> +   "CPU#%d [%s]", cpu->cpu_index,
> +   cpu->halted ? "halted " : "running");
> +}
>  trace_gdbstub_op_extra_info((char *)mem_buf);
>  memtohex(buf, mem_buf, len);
>  put_packet(s, buf);
>  }
>  break;
> -- 
> 2.19.1
> 



Re: [Qemu-devel] [PATCH v6 10/16] gdbstub: add multiprocess support to 'D' packets

2018-11-16 Thread Edgar E. Iglesias
On Thu, Nov 15, 2018 at 10:42:01AM +0100, Luc Michel wrote:
> 'D' packets are used by GDB to detach from a process. In multiprocess
> mode, the PID to detach from is sent in the request.
> 
> Signed-off-by: Luc Michel 
> Reviewed-by: Philippe Mathieu-Daudé 

Reviewed-by: Edgar E. Iglesias 


> ---
>  gdbstub.c | 60 ---
>  1 file changed, 53 insertions(+), 7 deletions(-)
> 
> diff --git a/gdbstub.c b/gdbstub.c
> index 5df9929f92..eec1cf0d09 100644
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -1039,24 +1039,39 @@ static int gdb_breakpoint_remove(target_ulong addr, 
> target_ulong len, int type)
>  default:
>  return -ENOSYS;
>  }
>  }
>  
> +static inline void gdb_cpu_breakpoint_remove_all(CPUState *cpu)
> +{
> +cpu_breakpoint_remove_all(cpu, BP_GDB);
> +#ifndef CONFIG_USER_ONLY
> +cpu_watchpoint_remove_all(cpu, BP_GDB);
> +#endif
> +}
> +
> +static void gdb_process_breakpoint_remove_all(const GDBState *s, GDBProcess 
> *p)
> +{
> +CPUState *cpu = get_first_cpu_in_process(s, p);
> +
> +while (cpu) {
> +gdb_cpu_breakpoint_remove_all(cpu);
> +cpu = gdb_next_cpu_in_process(s, cpu);
> +}
> +}
> +
>  static void gdb_breakpoint_remove_all(void)
>  {
>  CPUState *cpu;
>  
>  if (kvm_enabled()) {
>  kvm_remove_all_breakpoints(gdbserver_state->c_cpu);
>  return;
>  }
>  
>  CPU_FOREACH(cpu) {
> -cpu_breakpoint_remove_all(cpu, BP_GDB);
> -#ifndef CONFIG_USER_ONLY
> -cpu_watchpoint_remove_all(cpu, BP_GDB);
> -#endif
> +gdb_cpu_breakpoint_remove_all(cpu);
>  }
>  }
>  
>  static void gdb_set_cpu_pc(GDBState *s, target_ulong pc)
>  {
> @@ -1331,13 +1346,44 @@ static int gdb_handle_packet(GDBState *s, const char 
> *line_buf)
>  /* Kill the target */
>  error_report("QEMU: Terminated via GDBstub");
>  exit(0);
>  case 'D':
>  /* Detach packet */
> -gdb_breakpoint_remove_all();
> -gdb_syscall_mode = GDB_SYS_DISABLED;
> -gdb_continue(s);
> +pid = 1;
> +
> +if (s->multiprocess) {
> +unsigned long lpid;
> +if (*p != ';') {
> +put_packet(s, "E22");
> +break;
> +}
> +
> +if (qemu_strtoul(p + 1, , 16, )) {
> +put_packet(s, "E22");
> +break;
> +}
> +
> +pid = lpid;
> +}
> +
> +process = gdb_get_process(s, pid);
> +gdb_process_breakpoint_remove_all(s, process);
> +process->attached = false;
> +
> +if (pid == gdb_get_cpu_pid(s, s->c_cpu)) {
> +s->c_cpu = gdb_first_cpu(s);
> +}
> +
> +if (pid == gdb_get_cpu_pid(s, s->g_cpu)) {
> +s->g_cpu = gdb_first_cpu(s);
> +}
> +
> +if (s->c_cpu == NULL) {
> +/* No more process attached */
> +gdb_syscall_mode = GDB_SYS_DISABLED;
> +gdb_continue(s);
> +}
>  put_packet(s, "OK");
>  break;
>  case 's':
>  if (*p != '\0') {
>  addr = strtoull(p, (char **), 16);
> -- 
> 2.19.1
> 



[Qemu-devel] [PATCH v2 3/3] help: Provide help for egl-headless

2018-11-16 Thread Erik Skultety
EGL headless has been missing from QEMU's help or man page, we should
mention that such a thing exists, especially since projects like libvirt
might rely on that. This patch also adds the newly introduced option for
egl-headless 'rendernode'.

Signed-off-by: Erik Skultety 
---
 qemu-options.hx | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index ee379b32e3..f7df472f43 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1216,7 +1216,8 @@ DEF("display", HAS_ARG, QEMU_OPTION_display,
 "-display gtk[,grab_on_hover=on|off][,gl=on|off]|\n"
 "-display vnc=[,]\n"
 "-display curses\n"
-"-display none"
+"-display none\n"
+"-display egl-headless[,rendernode=]"
 "select display type\n"
 "The default display is equivalent to\n"
 #if defined(CONFIG_GTK)
@@ -1258,6 +1259,9 @@ menus and other UI elements to configure and control the 
VM during
 runtime.
 @item vnc
 Start a VNC server on display 
+@item egl-headless
+Offload all OpenGL operations to a local DRI device. For any graphical display,
+this display needs to be paired with either VNC or SPICE displays.
 @end table
 ETEXI
 
-- 
2.19.1




[Qemu-devel] [PATCH v2 1/3] qapi: Add "rendernode" display option for egl-headless

2018-11-16 Thread Erik Skultety
Unlike SPICE, egl-headless doesn't offer a way of specifying the DRM
node used for OpenGL, hence QEMU always selecting the first one that is
available. Thus, add the 'rendernode' option for egl-headless to QAPI.

Signed-off-by: Erik Skultety 
---
 qapi/ui.json | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/qapi/ui.json b/qapi/ui.json
index bf9e157d5a..e248d3 100644
--- a/qapi/ui.json
+++ b/qapi/ui.json
@@ -1037,6 +1037,20 @@
   'data': { '*grab-on-hover' : 'bool',
 '*zoom-to-fit'   : 'bool'  } }
 
+##
+# @DisplayEGLHeadless:
+#
+# EGL headless display options.
+#
+# @rendernode: Which DRM render node should be used. Default is the first
+#  available node on the host.
+#
+# Since: 3.1
+#
+##
+{ 'struct'  : 'DisplayEGLHeadless',
+  'data': { '*rendernode' : 'str' } }
+
  ##
  # @DisplayGLMode:
  #
@@ -1086,4 +1100,5 @@
 '*window-close'  : 'bool',
 '*gl': 'DisplayGLMode' },
   'discriminator' : 'type',
-  'data': { 'gtk': 'DisplayGTK' } }
+  'data': { 'gtk': 'DisplayGTK',
+'egl-headless'   : 'DisplayEGLHeadless'} }
-- 
2.19.1




Re: [Qemu-devel] [PATCH for-3.1] nvme: fix out-of-bounds access to the CMB

2018-11-16 Thread Li Qiang
Paolo Bonzini  于2018年11月16日周五 下午5:31写道:

> Because the CMB BAR has a min_access_size of 2, if you read the last
> byte it will try to memcpy *2* bytes from n->cmbuf, causing an off-by-one
> error.  This is CVE-2018-16847.
>
> Another way to fix this might be to register the CMB as a RAM memory
> region, which would also be more efficient.  However, that might be a
> change for big-endian machines; I didn't think this through and I don't
> know how real hardware works.  Add a basic testcase for the CMB in case
> somebody does this change later on.
>
> Cc: Keith Busch 
> Cc: qemu-bl...@nongnu.org
> Cc: Li Qiang 
> Signed-off-by: Paolo Bonzini 

---
>  hw/block/nvme.c|  2 +-
>  tests/Makefile.include |  2 +-
>  tests/nvme-test.c  | 58 +++---
>  3 files changed, 57 insertions(+), 5 deletions(-)
>
> diff --git a/hw/block/nvme.c b/hw/block/nvme.c
> index 09d7c90259..5d92794ef7 100644
> --- a/hw/block/nvme.c
> +++ b/hw/block/nvme.c
> @@ -1192,7 +1192,7 @@ static const MemoryRegionOps nvme_cmb_ops = {
>  .write = nvme_cmb_write,
>  .endianness = DEVICE_LITTLE_ENDIAN,
>  .impl = {
> -.min_access_size = 2,
> +.min_access_size = 1,
>  .max_access_size = 8,
>  },
>  };
> diff --git a/tests/Makefile.include b/tests/Makefile.include
> index 613242bc6e..fb0b449c02 100644
> --- a/tests/Makefile.include
> +++ b/tests/Makefile.include
> @@ -730,7 +730,7 @@ tests/test-hmp$(EXESUF): tests/test-hmp.o
>  tests/machine-none-test$(EXESUF): tests/machine-none-test.o
>  tests/drive_del-test$(EXESUF): tests/drive_del-test.o
> $(libqos-virtio-obj-y)
>  tests/qdev-monitor-test$(EXESUF): tests/qdev-monitor-test.o
> $(libqos-pc-obj-y)
> -tests/nvme-test$(EXESUF): tests/nvme-test.o
> +tests/nvme-test$(EXESUF): tests/nvme-test.o $(libqos-pc-obj-y)
>  tests/pvpanic-test$(EXESUF): tests/pvpanic-test.o
>  tests/i82801b11-test$(EXESUF): tests/i82801b11-test.o
>  tests/ac97-test$(EXESUF): tests/ac97-test.o
> diff --git a/tests/nvme-test.c b/tests/nvme-test.c
> index 7674a446e4..2abb3b6d19 100644
> --- a/tests/nvme-test.c
> +++ b/tests/nvme-test.c
> @@ -8,11 +8,64 @@
>   */
>
>  #include "qemu/osdep.h"
> +#include "qemu/units.h"
>  #include "libqtest.h"
> +#include "libqos/libqos-pc.h"
> +
> +static QOSState *qnvme_start(const char *extra_opts)
> +{
> +QOSState *qs;
> +const char *arch = qtest_get_arch();
> +const char *cmd = "-drive id=drv0,if=none,file=null-co://,format=raw "
> +  "-device nvme,addr=0x4.0,serial=foo,drive=drv0 %s";
> +
> +if (strcmp(arch, "i386") == 0 || strcmp(arch, "x86_64") == 0) {
> +qs = qtest_pc_boot(cmd, extra_opts ? : "");
> +global_qtest = qs->qts;
> +return qs;
> +}
> +
> +g_printerr("nvme tests are only available on x86\n");
> +exit(EXIT_FAILURE);
> +}
> +
> +static void qnvme_stop(QOSState *qs)
> +{
> +qtest_shutdown(qs);
> +}
>
> -/* Tests only initialization so far. TODO: Replace with functional tests
> */
>  static void nop(void)
>  {
> +QOSState *qs;
> +
> +qs = qnvme_start(NULL);
> +qnvme_stop(qs);
> +}
> +
> +static void nvmetest_cmb_test(void)
> +{
> +const int cmb_bar_size = 2 * MiB;
> +QOSState *qs;
> +QPCIDevice *pdev;
> +QPCIBar bar;
> +
> +qs = qnvme_start("-global nvme.cmb_size_mb=2");
> +pdev = qpci_device_find(qs->pcibus, QPCI_DEVFN(4,0));
> +g_assert(pdev != NULL);
> +
> +qpci_device_enable(pdev);
> +bar = qpci_iomap(pdev, 2, NULL);
> +
> +qpci_io_writel(pdev, bar, 0, 0xccbbaa99);
> +g_assert_cmpint(qpci_io_readb(pdev, bar, 0), ==, 0x99);
> +g_assert_cmpint(qpci_io_readw(pdev, bar, 0), ==, 0xaa99);
> +
> +/* Test partially out-of-bounds accesses.  */
> +qpci_io_writel(pdev, bar, cmb_bar_size - 1, 0x44332211);
> +g_assert_cmpint(qpci_io_readb(pdev, bar, cmb_bar_size - 1), ==, 0x11);
> +g_assert_cmpint(qpci_io_readw(pdev, bar, cmb_bar_size - 1), !=,
> 0x2211);
> +g_assert_cmpint(qpci_io_readl(pdev, bar, cmb_bar_size - 1), !=,
> 0x44332211);
>


Here seems need a g_free(pdev),




> +qnvme_stop(qs);
>  }
>
>  int main(int argc, char **argv)
> @@ -21,9 +74,8 @@ int main(int argc, char **argv)
>
>  g_test_init(, , NULL);
>  qtest_add_func("/nvme/nop", nop);
> +qtest_add_func("/nvme/cmb_test", nvmetest_cmb_test);
>
> -qtest_start("-drive id=drv0,if=none,file=null-co://,format=raw "
> -"-device nvme,drive=drv0,serial=foo");
>  ret = g_test_run();
>
>  qtest_end();
>

There is no qtest_start(), this qtest_end() seems trigger an assert in glib.
(tests/nvme-test:44053): GLib-CRITICAL **: g_hook_destroy_link: assertion
'hook != NULL' failed

Otherwise
Reviewed-by: Li Qiang 
Tested-by: Li Qiang 


Thanks,
Li Qiang



> --
> 2.19.1
>
>


[Qemu-devel] [PATCH v2 3/4] keymaps: remove common include

2018-11-16 Thread Gerd Hoffmann
Copy the content into the sl and sv files (the only ones left which are
not generated by qemu-keymap).

Signed-off-by: Gerd Hoffmann 
---
 Makefile   |   2 +-
 pc-bios/keymaps/common | 174 
 pc-bios/keymaps/sl | 177 -
 pc-bios/keymaps/sv | 176 +++-
 4 files changed, 352 insertions(+), 177 deletions(-)
 delete mode 100644 pc-bios/keymaps/common

diff --git a/Makefile b/Makefile
index d3355ec2c7..6e63ce8ec1 100644
--- a/Makefile
+++ b/Makefile
@@ -796,7 +796,7 @@ distclean: clean
 
 KEYMAPS=da en-gb  et  fr fr-ch  is  lt  no  pt-br  sv \
 ar  de en-us  fi  fr-be  hr it  lv  nl pl  ru th \
-common  de-ch  es fo  fr-ca  hu ja  mk  pt  sl tr \
+de-ch  es fo  fr-ca  hu ja  mk  pt  sl tr \
 bepocz
 
 ifdef INSTALL_BLOBS
diff --git a/pc-bios/keymaps/common b/pc-bios/keymaps/common
deleted file mode 100644
index aa844c82ed..00
--- a/pc-bios/keymaps/common
+++ /dev/null
@@ -1,174 +0,0 @@
-Shift_R 0x36
-Shift_L 0x2a
-
-Alt_R 0xb8
-Mode_switch 0xb8
-ISO_Level3_Shift 0xb8
-Alt_L 0x38
-
-Control_R 0x9d
-Control_L 0x1d
-
-# Translate Super to Windows keys.
-# This is hardcoded. See documentation for details.
-Super_R 0xdc
-Super_L 0xdb
-
-# Translate Menu to the Windows Application key.
-Menu 0xdd
-
-#
-# Top row
-#
-1 0x2
-2 0x3
-3 0x4
-4 0x5
-5 0x6
-6 0x7
-7 0x8
-8 0x9
-9 0xa
-0 0xb
-BackSpace 0xe
-
-#
-# QWERTY first row
-#
-Tab 0xf localstate
-ISO_Left_Tab 0xf shift
-q 0x10 addupper
-w 0x11 addupper
-e 0x12 addupper
-r 0x13 addupper
-t 0x14 addupper
-y 0x15 addupper
-u 0x16 addupper
-i 0x17 addupper
-o 0x18 addupper
-p 0x19 addupper
-
-#
-# QWERTY second row
-#
-a 0x1e addupper
-s 0x1f addupper
-d 0x20 addupper
-f 0x21 addupper
-g 0x22 addupper
-h 0x23 addupper
-j 0x24 addupper
-k 0x25 addupper
-l 0x26 addupper
-Return 0x1c localstate
-
-#
-# QWERTY third row
-#
-z 0x2c addupper
-x 0x2d addupper
-c 0x2e addupper
-v 0x2f addupper
-b 0x30 addupper
-n 0x31 addupper
-m 0x32 addupper
-
-space 0x39 localstate
-
-less 0x56
-greater 0x56 shift
-bar 0x56 altgr
-brokenbar 0x56 shift altgr
-
-#
-# Esc and Function keys
-#
-Escape 0x1 localstate
-F1 0x3b localstate
-F2 0x3c localstate
-F3 0x3d localstate
-F4 0x3e localstate
-F5 0x3f localstate
-F6 0x40 localstate
-F7 0x41 localstate
-F8 0x42 localstate
-F9 0x43 localstate
-F10 0x44 localstate
-F11 0x57 localstate
-F12 0x58 localstate
-
-# Printscreen, Scrollock and Pause
-# Printscreen really requires four scancodes (0xe0, 0x2a, 0xe0, 0x37),
-# but (0xe0, 0x37) seems to work.
-Print 0xb7 localstate
-Sys_Req 0xb7 localstate
-Execute 0xb7 localstate
-Scroll_Lock 0x46
-
-#
-# Insert - PgDown
-#
-Insert 0xd2 localstate
-Delete 0xd3 localstate
-Home 0xc7 localstate
-End 0xcf localstate
-Page_Up 0xc9 localstate
-Page_Down 0xd1 localstate
-
-#
-# Arrow keys
-#
-Left 0xcb localstate
-Up 0xc8 localstate
-Down 0xd0 localstate
-Right 0xcd localstate
-
-#
-# Numpad
-#
-Num_Lock 0x45
-KP_Divide 0xb5
-KP_Multiply 0x37
-KP_Subtract 0x4a
-KP_Add 0x4e
-KP_Enter 0x9c
-
-KP_Decimal 0x53 numlock
-KP_Separator 0x53 numlock
-KP_Delete 0x53
-
-KP_0 0x52 numlock
-KP_Insert 0x52
-
-KP_1 0x4f numlock
-KP_End 0x4f
-
-KP_2 0x50 numlock
-KP_Down 0x50
-
-KP_3 0x51 numlock
-KP_Next 0x51
-
-KP_4 0x4b numlock
-KP_Left 0x4b
-
-KP_5 0x4c numlock
-KP_Begin 0x4c
-
-KP_6 0x4d numlock
-KP_Right 0x4d
-
-KP_7 0x47 numlock
-KP_Home 0x47
-
-KP_8 0x48 numlock
-KP_Up 0x48
-
-KP_9 0x49 numlock
-KP_Prior 0x49
-
-Caps_Lock 0x3a
-#
-# Inhibited keys
-#
-Multi_key 0x0 inhibit
diff --git a/pc-bios/keymaps/sl b/pc-bios/keymaps/sl
index 56835a92c3..73eb956d04 100644
--- a/pc-bios/keymaps/sl
+++ b/pc-bios/keymaps/sl
@@ -1,5 +1,180 @@
 # generated from XKB map sl
-include common
+
+Shift_R 0x36
+Shift_L 0x2a
+
+Alt_R 0xb8
+Mode_switch 0xb8
+ISO_Level3_Shift 0xb8
+Alt_L 0x38
+
+Control_R 0x9d
+Control_L 0x1d
+
+# Translate Super to Windows keys.
+# This is hardcoded. See documentation for details.
+Super_R 0xdc
+Super_L 0xdb
+
+# Translate Menu to the Windows Application key.
+Menu 0xdd
+
+#
+# Top row
+#
+1 0x2
+2 0x3
+3 0x4
+4 0x5
+5 0x6
+6 0x7
+7 0x8
+8 0x9
+9 0xa
+0 0xb
+BackSpace 0xe
+
+#
+# QWERTY first row
+#
+Tab 0xf localstate
+ISO_Left_Tab 0xf shift
+q 0x10 addupper
+w 0x11 addupper
+e 0x12 addupper
+r 0x13 addupper
+t 0x14 addupper
+y 0x15 addupper
+u 0x16 addupper
+i 0x17 addupper
+o 0x18 addupper
+p 0x19 addupper
+
+#
+# QWERTY second row
+#
+a 0x1e addupper
+s 0x1f addupper
+d 0x20 addupper
+f 0x21 addupper
+g 0x22 addupper
+h 0x23 addupper
+j 0x24 addupper
+k 0x25 addupper
+l 0x26 addupper
+Return 0x1c localstate
+
+#
+# QWERTY third row
+#
+z 0x2c addupper
+x 0x2d addupper
+c 0x2e addupper
+v 0x2f addupper
+b 0x30 addupper
+n 0x31 addupper
+m 0x32 addupper
+
+space 0x39 localstate
+
+less 0x56
+greater 0x56 shift
+bar 0x56 altgr
+brokenbar 0x56 shift altgr
+
+#
+# Esc and Function keys
+#

[Qemu-devel] [PATCH v2 1/4] keymaps: remove modifiers include

2018-11-16 Thread Gerd Hoffmann
"common" is the only file using it, so we can just include it directly.

Signed-off-by: Gerd Hoffmann 
---
 Makefile  |  2 +-
 pc-bios/keymaps/common| 19 ++-
 pc-bios/keymaps/modifiers | 18 --
 3 files changed, 19 insertions(+), 20 deletions(-)
 delete mode 100644 pc-bios/keymaps/modifiers

diff --git a/Makefile b/Makefile
index f2947186a4..7899f9d621 100644
--- a/Makefile
+++ b/Makefile
@@ -794,7 +794,7 @@ distclean: clean
rm -Rf .sdk
if test -f dtc/version_gen.h; then $(MAKE) $(DTC_MAKE_ARGS) clean; fi
 
-KEYMAPS=da en-gb  et  fr fr-ch  is  lt  modifiers  no  pt-br  sv \
+KEYMAPS=da en-gb  et  fr fr-ch  is  lt  no  pt-br  sv \
 ar  de en-us  fi  fr-be  hr it  lv  nl pl  ru th \
 common  de-ch  es fo  fr-ca  hu ja  mk  nl-be  pt  sl tr \
 bepocz
diff --git a/pc-bios/keymaps/common b/pc-bios/keymaps/common
index adc56c77d2..aa844c82ed 100644
--- a/pc-bios/keymaps/common
+++ b/pc-bios/keymaps/common
@@ -1,4 +1,21 @@
-include modifiers
+Shift_R 0x36
+Shift_L 0x2a
+
+Alt_R 0xb8
+Mode_switch 0xb8
+ISO_Level3_Shift 0xb8
+Alt_L 0x38
+
+Control_R 0x9d
+Control_L 0x1d
+
+# Translate Super to Windows keys.
+# This is hardcoded. See documentation for details.
+Super_R 0xdc
+Super_L 0xdb
+
+# Translate Menu to the Windows Application key.
+Menu 0xdd
 
 #
 # Top row
diff --git a/pc-bios/keymaps/modifiers b/pc-bios/keymaps/modifiers
deleted file mode 100644
index d73b7a6637..00
--- a/pc-bios/keymaps/modifiers
+++ /dev/null
@@ -1,18 +0,0 @@
-Shift_R 0x36
-Shift_L 0x2a
-
-Alt_R 0xb8
-Mode_switch 0xb8
-ISO_Level3_Shift 0xb8
-Alt_L 0x38
-
-Control_R 0x9d
-Control_L 0x1d
-
-# Translate Super to Windows keys.
-# This is hardcoded. See documentation for details.
-Super_R 0xdc
-Super_L 0xdb
-
-# Translate Menu to the Windows Application key.
-Menu 0xdd
-- 
2.9.3




  1   2   3   >