[Qemu-devel] [PATCH] ui/cocoa: Fix mouse grabbing in fullscreen mode for relative input device

2019-03-21 Thread Chen Zhang via Qemu-devel
In fullscreen mode, the window property of cocoaView may not be the key
window, and the current implementation would not grab mouse in
fullscreen mode after left clicks on relative input devices.

This patch used isFullscreen value as a short-cirtuit condition for
relative input device grabbing.

Note that this patch should be tested after applying a previous patch
which fixed event location conversion for relative input devices.

Signed-off-by: Chen Zhang 
---
 ui/cocoa.m | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 420b2411c1..51463bb931 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -862,7 +862,12 @@ QemuCocoaView *cocoaView;
 case NSEventTypeLeftMouseUp:
 mouse_event = true;
 if (!isMouseGrabbed && [self screenContainsPoint:p]) {
-if([[self window] isKeyWindow]) {
+/*
+ * In fullscreen mode, the window of cocoaView may not be the
+ * key window, therefore the position relative to the virtual
+ * screen alone will be sufficient.
+ */
+if(isFullscreen || [[self window] isKeyWindow]) {
 [self grabMouse];
 }
 }
-- 
2.19.2




Re: [Qemu-devel] [PATCH] ui/cocoa: Fix mouse grabbing in fullscreen mode for relative input device

2019-03-21 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/176e53d9-50b8-405c-82ff-524734226...@me.com/



Hi,

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

Message-id: 176e53d9-50b8-405c-82ff-524734226...@me.com
Subject: [Qemu-devel] [PATCH] ui/cocoa: Fix mouse grabbing in fullscreen mode 
for relative input device
Type: series

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag]   patchew/176e53d9-50b8-405c-82ff-524734226...@me.com 
-> patchew/176e53d9-50b8-405c-82ff-524734226...@me.com
 t [tag update]
patchew/20190313065649.19067-1-yuchen...@synology.com -> 
patchew/20190313065649.19067-1-yuchen...@synology.com
 t [tag update]
patchew/20190315032629.21234-1-richard.hender...@linaro.org -> 
patchew/20190315032629.21234-1-richard.hender...@linaro.org
Switched to a new branch 'test'
79cb56db3d ui/cocoa: Fix mouse grabbing in fullscreen mode for relative input 
device

=== OUTPUT BEGIN ===
ERROR: Author email address is mangled by the mailing list
#2: 
Author: Chen Zhang via Qemu-devel 

total: 1 errors, 0 warnings, 13 lines checked

Commit 79cb56db3d30 (ui/cocoa: Fix mouse grabbing in fullscreen mode for 
relative input device) has style problems, please review.  If any of these 
errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/176e53d9-50b8-405c-82ff-524734226...@me.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] [PATCH 0/2] make docker-travis work again

2019-03-21 Thread Alex Bennée


Wainer dos Santos Moschetta  writes:

> The `make docker-travis@IMAGE` is broken because:
> 1) travis.py fails to parse the current .travis.yml
> 2) The travis script does not get the correct reference
> to the source directory. It is a regression introduced on
> commit 05790dafef1.
>
> Tested with `make docker-travis@ubuntu`.

Just goes to show how often we run the Travis matrix locally

These look good to me. As they are bug fixes I think they are good
enough to go into my next Travis PR. I'm just waiting for reviews on:

  Subject: [PATCH  v1 0/3 for 4.0] reduce timeouts on Travis
  Date: Tue, 19 Mar 2019 12:47:57 +
  Message-Id: <20190319124800.7454-1-alex.ben...@linaro.org>

before putting it together.

>
> Wainer dos Santos Moschetta (2):
>   docker: Fix travis.py parser and misc change
>   docker: Fix travis script unable to find source dir
>
>  tests/docker/travis|  1 +
>  tests/docker/travis.py | 11 +--
>  2 files changed, 6 insertions(+), 6 deletions(-)


--
Alex Bennée



Re: [Qemu-devel] [PATCH 1/2] docker: Fix travis.py parser and misc change

2019-03-21 Thread Alex Bennée


Wainer dos Santos Moschetta  writes:

> Fixed the travis.py script that has failed to parse the current
> QEMU_SRC/.travis.yml file. It no longer makes combinations from
> env/matrix, instead it uses explicit includes. Also the compiler
> can be omitted from matrix/include, so that Travis chooses the
> first entry of the global compiler list.
>
> Replaced yaml.load() with yaml.safe_load() so that quieting the
> following deprecation warning:
> https://github.com/yaml/pyyaml/wiki/PyYAML-yaml.load(input)-Deprecation
>
> Signed-off-by: Wainer dos Santos Moschetta 

Reviewed-by: Alex Bennée 

> ---
>  tests/docker/travis.py | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/tests/docker/travis.py b/tests/docker/travis.py
> index ea1ef169e6..e1433012bd 100755
> --- a/tests/docker/travis.py
> +++ b/tests/docker/travis.py
> @@ -17,18 +17,17 @@ import yaml
>  import itertools
>
>  def load_yaml(fname):
> -return yaml.load(open(fname, "r").read())
> +return yaml.safe_load(open(fname, "r").read())
>
>  def conf_iter(conf):
> +# If "compiler" is omitted from the included env then Travis picks the
> +# first entry of the global compiler list.
> +default_compiler = conf["compiler"][0]
>  def env_to_list(env):
>  return env if isinstance(env, list) else [env]
>  for entry in conf["matrix"]["include"]:
>  yield {"env": env_to_list(entry["env"]),
> -   "compiler": entry["compiler"]}
> -for entry in itertools.product(conf["compiler"],
> -   conf["env"]["matrix"]):
> -yield {"env": env_to_list(entry[1]),
> -   "compiler": entry[0]}
> +   "compiler": entry.get("compiler", default_compiler)}
>
>  def main():
>  if len(sys.argv) < 2:


--
Alex Bennée



Re: [Qemu-devel] [PATCH 2/2] docker: Fix travis script unable to find source dir

2019-03-21 Thread Alex Bennée


Wainer dos Santos Moschetta  writes:

> The script generated from QEMU_SRC/.travis.yml uses BUILD_DIR and
> SRC_DIR path relative to the current dir, unless these variables
> are exported in environment.
>
> Since commit 05790dafef1 BUILD_DIR is exported in the runner script,
> although SRC_DIR is not, so that make docker-travis fails becase
> the reference to source dir is wrong. So let's unset both BUILD_DIR
> and SRC_DIR before calling the script, given it is executed from
> the source dir already (as in Travis).
>
> Signed-off-by: Wainer dos Santos Moschetta 

Reviewed-by: Alex Bennée 

> ---
>  tests/docker/travis | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/tests/docker/travis b/tests/docker/travis
> index d345393ced..47c03677d6 100755
> --- a/tests/docker/travis
> +++ b/tests/docker/travis
> @@ -18,4 +18,5 @@ cmdfile=/tmp/travis_cmd_list.sh
>  $QEMU_SRC/tests/docker/travis.py $QEMU_SRC/.travis.yml > $cmdfile
>  chmod +x $cmdfile
>  cd "$QEMU_SRC"
> +unset BUILD_DIR SRC_DIR
>  $cmdfile


--
Alex Bennée



Re: [Qemu-devel] [PULL 00/12] EDK2 Firmware roms

2019-03-21 Thread Peter Maydell
On Wed, 20 Mar 2019 at 19:42, Laszlo Ersek  wrote:
> An alternative to rebasing / reworking the series in-place (for
> xz-->bz2) and to missing the 4.0 bus consequently, would be to merge the
> PULL req as is, and for me to submit an incremental update, for the
> xz-->bz2 replacement. I think that would qualify as a bugfix, and be
> eligible for the hard freeze too.

No, I cannot merge this pullreq as is, because it would
break the tests I do before merges. (I could fix my OSX
install easily, but the tests/vm/ setups for the BSDs
are not under my control.)

thanks
-- PMM



[Qemu-devel] [PATCH 2/3] vhost-scsi: Add vmstate descriptor

2019-03-21 Thread Nir Weiner
As preparation of enabling migration of vhost-scsi device,
define it’s VMState. Note, we keep the convention of
verifying in the pre_save() method that the vhost backend
must be stopped before attempting to save the device
state. Similar to how it is done for vhost-vsock.

Reviewed-by: Bijan Mottahedeh 
Reviewed-by: Liran Alon 
Signed-off-by: Nir Weiner 
---
 hw/scsi/vhost-scsi.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
index ca42cff1b907..eb0cf9e1312f 100644
--- a/hw/scsi/vhost-scsi.c
+++ b/hw/scsi/vhost-scsi.c
@@ -139,6 +139,28 @@ static void vhost_dummy_handle_output(VirtIODevice *vdev, 
VirtQueue *vq)
 {
 }
 
+static int vhost_scsi_pre_save(void *opaque)
+{
+VHostSCSICommon *vsc = opaque;
+
+/* At this point, backend must be stopped, otherwise
+ * it might keep writing to memory. */
+assert(!vsc->dev.started);
+
+return 0;
+}
+
+static const VMStateDescription vmstate_virtio_vhost_scsi = {
+.name = "virtio-vhost_scsi",
+.minimum_version_id = 1,
+.version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_VIRTIO_DEVICE,
+VMSTATE_END_OF_LIST()
+},
+.pre_save = vhost_scsi_pre_save,
+};
+
 static void vhost_scsi_realize(DeviceState *dev, Error **errp)
 {
 VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(dev);
@@ -256,6 +278,7 @@ static void vhost_scsi_class_init(ObjectClass *klass, void 
*data)
 FWPathProviderClass *fwc = FW_PATH_PROVIDER_CLASS(klass);
 
 dc->props = vhost_scsi_properties;
+dc->vmsd = &vmstate_virtio_vhost_scsi;
 set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
 vdc->realize = vhost_scsi_realize;
 vdc->unrealize = vhost_scsi_unrealize;
-- 
2.17.1




[Qemu-devel] [PATCH 0/3] vhost-scsi: Support live migration

2019-03-21 Thread Nir Weiner
Originally migration was not possible with vhost-scsi because
as part of migration, the source host target SCSI device state
needs to be saved and loaded into the destination host target SCSI
device. This cannot be done by QEMU.

As this can be handled either by external orchestrator or by having
shared-storage (i.e. iSCSI), there is no reason to limit the
orchestrator from being able to explictly specify it wish to enable
migration even when VM have a vhost-scsi device.

Liran Alon (1):
  vhost-scsi: Allow user to enable migration

Nir Weiner (2):
  vhost-scsi: The vhost device should be stopped when the VM is not
running
  vhost-scsi: Add vmstate descriptor

 hw/scsi/vhost-scsi.c  | 57 ++-
 include/hw/virtio/vhost-scsi-common.h |  1 +
 2 files changed, 48 insertions(+), 10 deletions(-)

-- 
2.17.1




[Qemu-devel] [PATCH 1/3] vhost-scsi: The vhost device should be stopped when the VM is not running

2019-03-21 Thread Nir Weiner
vhost-scsi doesn’t takes into account whether the vm is running or not in
order to decide if it should start/stop vhost processing.
This would lead to vhost processing still being active when VM the RunState
suddenly change to stopped.

An example of when this issue is encountered is when Live-Migration Pre-Copy
phase completes. As in this case, VM state will be changed to stopped (while
vhost processing is still active), which will result in
virtio_vmstate_change() -> virtio_set_status() -> vhost_scsi_set_status()
executed but vhost_scsi_set_status() will just return without stopping
vhost processing.

To handle this, change code to consider that vhost processing should be
stopped when vm is not running. similar to how it is done in vhost-vsock
device at vhost_vsock_set_status().

Fixes: 5e9be92d7752 ("vhost-scsi: new device supporting the tcm_vhost Linux 
kernel module”)
Reviewed-by: Bijan Mottahedeh 
Reviewed-by: Liran Alon 
Signed-off-by: Nir Weiner 
---
 hw/scsi/vhost-scsi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
index 61e2e57da9d5..ca42cff1b907 100644
--- a/hw/scsi/vhost-scsi.c
+++ b/hw/scsi/vhost-scsi.c
@@ -114,6 +114,10 @@ static void vhost_scsi_set_status(VirtIODevice *vdev, 
uint8_t val)
 VHostSCSICommon *vsc = VHOST_SCSI_COMMON(s);
 bool start = (val & VIRTIO_CONFIG_S_DRIVER_OK);
 
+if (!vdev->vm_running) {
+start = false;
+}
+
 if (vsc->dev.started == start) {
 return;
 }
-- 
2.17.1




[Qemu-devel] [PATCH 3/3] vhost-scsi: Allow user to enable migration

2019-03-21 Thread Nir Weiner
From: Liran Alon 

Originally migration was not possible with vhost-scsi because
as part of migration, the source host target SCSI device state
needs to be saved and loaded into the destination host target SCSI
device. This cannot be done by QEMU.

As this can be handled either by external orchestrator or by having
shared-storage (i.e. iSCSI), there is no reason to limit the
orchestrator from being able to explictly specify it wish to enable
migration even when VM have a vhost-scsi device.

Reviewed-by: Nir Weiner 
Reviewed-by: Bijan Mottahedeh 
Signed-off-by: Liran Alon 
---
 hw/scsi/vhost-scsi.c  | 30 ++-
 include/hw/virtio/vhost-scsi-common.h |  1 +
 2 files changed, 21 insertions(+), 10 deletions(-)

diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
index eb0cf9e1312f..52d46a788e6c 100644
--- a/hw/scsi/vhost-scsi.c
+++ b/hw/scsi/vhost-scsi.c
@@ -199,13 +199,18 @@ static void vhost_scsi_realize(DeviceState *dev, Error 
**errp)
 goto close_fd;
 }
 
-error_setg(&vsc->migration_blocker,
-   "vhost-scsi does not support migration");
-migrate_add_blocker(vsc->migration_blocker, &err);
-if (err) {
-error_propagate(errp, err);
-error_free(vsc->migration_blocker);
-goto close_fd;
+if (!vsc->migratable) {
+error_setg(&vsc->migration_blocker,
+"vhost-scsi does not support migration in all cases."
+"When external environment is supports it (Orchestrator 
migrates"
+"target SCSI device state or use shared storage over network),"
+"set 'migratable' property to true to enable migration.");
+migrate_add_blocker(vsc->migration_blocker, &err);
+if (err) {
+error_propagate(errp, err);
+error_free(vsc->migration_blocker);
+goto close_fd;
+}
 }
 
 vsc->dev.nvqs = VHOST_SCSI_VQ_NUM_FIXED + vs->conf.num_queues;
@@ -230,7 +235,9 @@ static void vhost_scsi_realize(DeviceState *dev, Error 
**errp)
 return;
 
  free_vqs:
-migrate_del_blocker(vsc->migration_blocker);
+if (!vsc->migratable) {
+migrate_del_blocker(vsc->migration_blocker);
+}
 g_free(vsc->dev.vqs);
  close_fd:
 close(vhostfd);
@@ -243,8 +250,10 @@ static void vhost_scsi_unrealize(DeviceState *dev, Error 
**errp)
 VHostSCSICommon *vsc = VHOST_SCSI_COMMON(dev);
 struct vhost_virtqueue *vqs = vsc->dev.vqs;
 
-migrate_del_blocker(vsc->migration_blocker);
-error_free(vsc->migration_blocker);
+if (!vsc->migratable) {
+migrate_del_blocker(vsc->migration_blocker);
+error_free(vsc->migration_blocker);
+}
 
 /* This will stop vhost backend. */
 vhost_scsi_set_status(vdev, 0);
@@ -268,6 +277,7 @@ static Property vhost_scsi_properties[] = {
 DEFINE_PROP_BIT64("t10_pi", VHostSCSICommon, host_features,
  VIRTIO_SCSI_F_T10_PI,
  false),
+DEFINE_PROP_BOOL("migratable", VHostSCSICommon, migratable, false),
 DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/include/hw/virtio/vhost-scsi-common.h 
b/include/hw/virtio/vhost-scsi-common.h
index 57fb1d87b51d..4eab767ee89f 100644
--- a/include/hw/virtio/vhost-scsi-common.h
+++ b/include/hw/virtio/vhost-scsi-common.h
@@ -36,6 +36,7 @@ typedef struct VHostSCSICommon {
 int target;
 int lun;
 uint64_t host_features;
+bool migratable;
 } VHostSCSICommon;
 
 int vhost_scsi_common_start(VHostSCSICommon *vsc);
-- 
2.17.1




Re: [Qemu-devel] [Qemu-block] [PATCH] tests/qemu-iotests/235: Allow fallback to tcg and remove it from quick group

2019-03-21 Thread Thomas Huth
On 20/03/2019 18.32, John Snow wrote:
> 
> 
> On 3/1/19 7:20 AM, Thomas Huth wrote:
>> iotest 235 currently only works with KVM - this is bad for systems where
>> it is not available, e.g. CI pipelines. The test also works when using
>> "tcg" as accelerator, so we can simply add that to the list of accelerators,
>> too. But still, there might be the case that someone compiled their
>> QEMU with --disable-tcg and still try to run the iotests in a CI pipeline
>> where KVM is not available - in that case it would be best to use the
>> "qtest" accelerator for this test. However, that currently hangs and I
>> did not succeed to get it working with "accel=qtest" yet. Thus, as long
>> as this is not fixed, it's likely better to remove this test from the
>> "quick" group so that it does not fail on CI pipelines.
>>
>> Signed-off-by: Thomas Huth 
> 
> What happens if we set accel=kvm:tcg but leave it in quick group? It
> will still fail in those cases where we have neither accelerator for
> whichever reason, but maybe that's better than just trying to prevent it
> from running ... ?

... but since it is failing, you can't use "make check-block" in the CI
pipelines in that case. I had to manually select the test cases in the
.gitlab-ci.yml file due to this. I don't mind too much, but IMHO "make
check-block" should simply run everywhere, with every QEMU binary, and
not only if you've compiled it with the right options and/or KVM is
available. Otherwise, we maybe need a "make check-block-simple" or "make
check-block-ci" target, that uses another new group beside the "quick"
group? I.e. introduce a "ci" or "simple" group into
tests/qemu-iotests/group ?

 Thomas



Re: [Qemu-devel] [qemu-s390x] [PATCH v5 00/15] s390: vfio-ccw dasd ipl support

2019-03-21 Thread Thomas Huth
On 20/03/2019 16.11, Jason J. Herne wrote:
> On 3/13/19 12:31 PM, Jason J. Herne wrote:
>> This is to support booting from vfio-ccw dasd devices. We basically
>> implement
>> the real hardware ipl procedure. This allows for booting Linux guests on
>> vfio-ccw devices.
>>
>> vfio-ccw's channel program prefetch algorithm complicates ipl because
>> most ipl
>> channel programs dynamically modify themselves. Details on the ipl
>> process and
>> how we worked around this issue can be found in
>> docs/devel/s390-dasd-ipl.txt.
>>
>> Changelog
>> ==
>> v5
>> - Whitespace changes and comments.
>> - Added newlines to printed strings in patch 15.
>>
> ...
> 
> Ping. Thomas or Christian, are you ready to pick this series up or do
> you feel we need any more work?

Sorry, I was out of office during the last week ... I'll try to have a
closer look during the next days... (but it's too late for 4.0 now since
we're already in the freeze period).

 Thomas



[Qemu-devel] [PATCH 2/6] exec.c: remove an unnecessary assert on PHYS_MAP_NODE_NIL in phys_map_node_alloc()

2019-03-21 Thread Wei Yang
PHYS_MAP_NODE_NIL is assigned to PhysPageEntry.ptr in case this is not a
leaf entry, while map->nodes_nb range in [0, nodes_nb_alloc).

Seems we are asserting on two different things, just remove it.

Signed-off-by: Wei Yang 
---
 exec.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/exec.c b/exec.c
index 98ebd0dd1d..8e8b6bb1f9 100644
--- a/exec.c
+++ b/exec.c
@@ -242,7 +242,6 @@ static uint32_t phys_map_node_alloc(PhysPageMap *map, bool 
leaf)
 
 ret = map->nodes_nb++;
 p = map->nodes[ret];
-assert(ret != PHYS_MAP_NODE_NIL);
 assert(ret != map->nodes_nb_alloc);
 
 e.skip = leaf ? 0 : 1;
-- 
2.19.1




[Qemu-devel] [PATCH 3/6] exec.c: get nodes_nb_alloc with one MAX calculation

2019-03-21 Thread Wei Yang
The purpose of these two MAX here is to get the maximum of these three
variables:

A: map->nodes_nb + nodes
B: map->nodes_nb_alloc
C: alloc_hint

We can write it like MAX(A, B, C). Since the if condition says A > B,
this means MAX(A, B, C) = MAX(A, C).

This patch just simplify the calculation a bit.

Signed-off-by: Wei Yang 
---
 exec.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/exec.c b/exec.c
index 8e8b6bb1f9..78bf810ae8 100644
--- a/exec.c
+++ b/exec.c
@@ -226,8 +226,7 @@ static void phys_map_node_reserve(PhysPageMap *map, 
unsigned nodes)
 {
 static unsigned alloc_hint = 16;
 if (map->nodes_nb + nodes > map->nodes_nb_alloc) {
-map->nodes_nb_alloc = MAX(map->nodes_nb_alloc, alloc_hint);
-map->nodes_nb_alloc = MAX(map->nodes_nb_alloc, map->nodes_nb + nodes);
+map->nodes_nb_alloc = MAX(alloc_hint, map->nodes_nb + nodes);
 map->nodes = g_renew(Node, map->nodes, map->nodes_nb_alloc);
 alloc_hint = map->nodes_nb_alloc;
 }
-- 
2.19.1




[Qemu-devel] [PATCH 1/6] exec.c: replace hwaddr with uint64_t for better understanding

2019-03-21 Thread Wei Yang
Function phys_page_set() and phys_page_set_level() 's argument *nb*
stands for number of pages to set instead of hardware address.

This would be more proper to use uint64_t instead of hwaddr for its
type.

Signed-off-by: Wei Yang 
---
 exec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/exec.c b/exec.c
index 86a38d3b3b..98ebd0dd1d 100644
--- a/exec.c
+++ b/exec.c
@@ -254,7 +254,7 @@ static uint32_t phys_map_node_alloc(PhysPageMap *map, bool 
leaf)
 }
 
 static void phys_page_set_level(PhysPageMap *map, PhysPageEntry *lp,
-hwaddr *index, hwaddr *nb, uint16_t leaf,
+hwaddr *index, uint64_t *nb, uint16_t leaf,
 int level)
 {
 PhysPageEntry *p;
@@ -280,7 +280,7 @@ static void phys_page_set_level(PhysPageMap *map, 
PhysPageEntry *lp,
 }
 
 static void phys_page_set(AddressSpaceDispatch *d,
-  hwaddr index, hwaddr nb,
+  hwaddr index, uint64_t nb,
   uint16_t leaf)
 {
 /* Wildly overreserve - it doesn't matter much. */
-- 
2.19.1




[Qemu-devel] [PATCH 0/6] Refine exec

2019-03-21 Thread Wei Yang
This serial refine exec a little.

Wei Yang (6):
  exec.c: replace hwaddr with uint64_t for better understanding
  exec.c: remove an unnecessary assert on PHYS_MAP_NODE_NIL in
phys_map_node_alloc()
  exec.c: get nodes_nb_alloc with one MAX calculation
  exec.c: subpage->sub_section is already initialized to 0
  exec.c: correct the maximum skip value during compact
  exec.c: add a check between constants to see whether we could skip

 exec.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

-- 
2.19.1




[Qemu-devel] [PATCH 5/6] exec.c: correct the maximum skip value during compact

2019-03-21 Thread Wei Yang
skip is defined with 6 bits. So the maximum value should be (1 << 6).

Signed-off-by: Wei Yang 
---
 exec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/exec.c b/exec.c
index 788a8c3f69..6c660f656c 100644
--- a/exec.c
+++ b/exec.c
@@ -322,7 +322,7 @@ static void phys_page_compact(PhysPageEntry *lp, Node 
*nodes)
 assert(valid_ptr < P_L2_SIZE);
 
 /* Don't compress if it won't fit in the # of bits we have. */
-if (lp->skip + p[valid_ptr].skip >= (1 << 3)) {
+if (lp->skip + p[valid_ptr].skip >= (1 << 6)) {
 return;
 }
 
-- 
2.19.1




[Qemu-devel] [PATCH 4/6] exec.c: subpage->sub_section is already initialized to 0

2019-03-21 Thread Wei Yang
In subpage_init(), we will set subpage->sub_section to
PHYS_SECTION_UNASSIGNED by subpage_register. Since
PHYS_SECTION_UNASSIGNED is defined to be 0, and we allocate subpage with
g_malloc0, this means subpage->sub_section is already initialized to 0.

This patch removes the redundant setup for a new subpage and also fix
the code style.

Signed-off-by: Wei Yang 
---
 exec.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/exec.c b/exec.c
index 78bf810ae8..788a8c3f69 100644
--- a/exec.c
+++ b/exec.c
@@ -1494,8 +1494,8 @@ hwaddr memory_region_section_get_iotlb(CPUState *cpu,
 
 #if !defined(CONFIG_USER_ONLY)
 
-static int subpage_register (subpage_t *mmio, uint32_t start, uint32_t end,
- uint16_t section);
+static int subpage_register(subpage_t *mmio, uint32_t start, uint32_t end,
+uint16_t section);
 static subpage_t *subpage_init(FlatView *fv, hwaddr base);
 
 static void *(*phys_mem_alloc)(size_t size, uint64_t *align, bool shared) =
@@ -2943,8 +2943,8 @@ static const MemoryRegionOps subpage_ops = {
 .endianness = DEVICE_NATIVE_ENDIAN,
 };
 
-static int subpage_register (subpage_t *mmio, uint32_t start, uint32_t end,
- uint16_t section)
+static int subpage_register(subpage_t *mmio, uint32_t start, uint32_t end,
+uint16_t section)
 {
 int idx, eidx;
 
@@ -2967,6 +2967,7 @@ static subpage_t *subpage_init(FlatView *fv, hwaddr base)
 {
 subpage_t *mmio;
 
+/* mmio->sub_section is set to PHYS_SECTION_UNASSIGNED with g_malloc0 */
 mmio = g_malloc0(sizeof(subpage_t) + TARGET_PAGE_SIZE * sizeof(uint16_t));
 mmio->fv = fv;
 mmio->base = base;
@@ -2977,7 +2978,6 @@ static subpage_t *subpage_init(FlatView *fv, hwaddr base)
 printf("%s: %p base " TARGET_FMT_plx " len %08x\n", __func__,
mmio, base, TARGET_PAGE_SIZE);
 #endif
-subpage_register(mmio, 0, TARGET_PAGE_SIZE-1, PHYS_SECTION_UNASSIGNED);
 
 return mmio;
 }
-- 
2.19.1




[Qemu-devel] [PATCH 6/6] exec.c: add a check between constants to see whether we could skip

2019-03-21 Thread Wei Yang
The maximum level is defined as P_L2_LEVELS and skip is defined with 6
bits, which means if P_L2_LEVELS < (1 << 6), skip never exceeds the
boundary.

Since this check is between two constants, which leverages compiler
to optimize the code based on different configuration.

Signed-off-by: Wei Yang 
---
 exec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/exec.c b/exec.c
index 6c660f656c..5d71fdb89f 100644
--- a/exec.c
+++ b/exec.c
@@ -322,7 +322,8 @@ static void phys_page_compact(PhysPageEntry *lp, Node 
*nodes)
 assert(valid_ptr < P_L2_SIZE);
 
 /* Don't compress if it won't fit in the # of bits we have. */
-if (lp->skip + p[valid_ptr].skip >= (1 << 6)) {
+if (P_L2_LEVELS >= (1 << 6) &&
+lp->skip + p[valid_ptr].skip >= (1 << 6)) {
 return;
 }
 
-- 
2.19.1




Re: [Qemu-devel] [PATCH 1/2] iotests: 030 TestParallelOps non-shared base node

2019-03-21 Thread Vladimir Sementsov-Ogievskiy
20.03.2019 20:25, Alberto Garcia wrote:
> On Wed 20 Mar 2019 10:35:27 AM CET, Vladimir Sementsov-Ogievskiy wrote:
>>> Maybe at least this kind of freezing isn't the right tool for block
>>> jobs, after all.
>>
>> I think, the correct way, which will support these correct cases
>> (which however don't look like real use cases) is removing base from
>> stream view. Stream should operate instead using bottom-node.
> 
> What is bottom-node?

I mean bottom intermediate node, or a node which backing is base.

> 
>> And this all looks really more complicated than what we already have
>> with frozen backing chain.
>>
>> Do we really need such cases with parallel streams, sharing same node
>> as base for one and top for another? Will someone be upset if we drop
>> usage for such scenarios?
> 
> That would mean that 'base' is blocked and therefore cannot be used by a
> different block job.
> 
> I don't think it's terrible to restrict that scenario, although it's
> technically a regression so someone could complain about it. As I said
> ealier I would prefer not to do it if there's a simple solution (we
> would need to think about it), but I wouldn't want to make the code more
> complicated just for this use case.
> 
> Berto
> 


-- 
Best regards,
Vladimir


Re: [Qemu-devel] [PATCH] virtio-net: do not start queues that are not enabled by the guest

2019-03-21 Thread Michael S. Tsirkin
On Thu, Mar 14, 2019 at 10:45:25PM +0800, Jason Wang wrote:
> 
> On 2019/2/25 下午8:33, Michael S. Tsirkin wrote:
> > On Mon, Feb 25, 2019 at 03:47:48PM +0800, Jason Wang wrote:
> > > On 2019/2/22 下午12:22, Michael S. Tsirkin wrote:
> > > > On Thu, Feb 21, 2019 at 10:10:08PM -0500, Michael S. Tsirkin wrote:
> > > > > On Fri, Feb 22, 2019 at 11:04:05AM +0800, Jason Wang wrote:
> > > > > > On 2019/2/22 上午9:35, Michael S. Tsirkin wrote:
> > > > > > > On Thu, Feb 21, 2019 at 05:40:22PM +0800, Jason Wang wrote:
> > > > > > > > On 2019/2/21 下午4:18, Yuri Benditovich wrote:
> > > > > > > > 
> > > > > > > >For 1.0 device, we can fix the queue_enable, but for 
> > > > > > > > 0.9x device how do
> > > > > > > >you enable one specific queue in this case? (setting 
> > > > > > > > status?)
> > > > > > > > 
> > > > > > > > 
> > > > > > > >Do I understand correctly that for 0.9 device in some 
> > > > > > > > cases the device will
> > > > > > > >receive feature _MQ set, but will not receive 
> > > > > > > > VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET?
> > > > > > > >Or the problem is different?
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Let me clarify, VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET is used to 
> > > > > > > > control the the
> > > > > > > > number of queue pairs used by device for doing transmission and 
> > > > > > > > reception. It
> > > > > > > > was not used to enable or disable a virtqueue.
> > > > > > > > 
> > > > > > > > For 1.0 device, we should use queue_enable in pci cfg to enable 
> > > > > > > > and disable
> > > > > > > > queue:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > We could do:
> > > > > > > > 
> > > > > > > > 1) allocate memory and set queue_enable for vq0
> > > > > > > > 
> > > > > > > > 2) allocate memory and set queue_enable for vq1
> > > > > > > > 
> > > > > > > > 3) Set vq paris to 1
> > > > > > > > 
> > > > > > > > 4) allocate memory and set queue_enable for vq2
> > > > > > > > 
> > > > > > > > 5) allocate memory and set queue_enable for vq3
> > > > > > > > 
> > > > > > > > 6) set vq pairs to 2
> > > > > > > I do not think spec allows this.
> > > > > > > 
> > > > > > > 
> > > > > > > The driver MUST follow this sequence to initialize a device:
> > > > > > > 1. Reset the device.
> > > > > > > 2. Set the ACKNOWLEDGE status bit: the guest OS has noticed the 
> > > > > > > device.
> > > > > > > 3. Set the DRIVER status bit: the guest OS knows how to drive the 
> > > > > > > device.
> > > > > > > 4. Read device feature bits, and write the subset of feature bits 
> > > > > > > understood by the OS and driver to the
> > > > > > > device. During this step the driver MAY read (but MUST NOT write) 
> > > > > > > the device-specific configuration
> > > > > > > fields to check that it can support the device before accepting 
> > > > > > > it.
> > > > > > > 5. Set the FEATURES_OK status bit. The driver MUST NOT accept new 
> > > > > > > feature bits after this step.
> > > > > > > 6. Re-read device status to ensure the FEATURES_OK bit is still 
> > > > > > > set: otherwise, the device does not
> > > > > > > support our subset of features and the device is unusable.
> > > > > > > 7. Perform device-specific setup, including discovery of 
> > > > > > > virtqueues for the device, optional per-bus setup,
> > > > > > > reading and possibly writing the device’s virtio configuration 
> > > > > > > space, and population of virtqueues.
> > > > > > > 8. Set the DRIVER_OK status bit. At this point the device is 
> > > > > > > “live”.
> > > > > > > 
> > > > > > > 
> > > > > > > Thus vqs are setup at step 7.
> > > > > > > 
> > > > > > > # of vq pairs are set up through a command which is a special
> > > > > > > buffer, and spec says:
> > > > > > > 
> > > > > > > The driver MUST NOT send any buffer available notifications to 
> > > > > > > the device before setting DRIVER_OK.
> > > > > > So you meant write to queue_enable is forbidden after DRIVER_OK 
> > > > > > (though it's
> > > > > > not very clear to me from the  spec). And if a driver want to 
> > > > > > enable new
> > > > > > queues, it must reset the device?
> > > > > That's my reading.  What do you think?
> > > Looks like I can infer this from the spec, maybe it's better to clarify.
> > > 
> > > 
> > > > Btw some legacy drivers might violate this by addig buffers
> > > > before driver_ok.
> > > Yes, but it's probably too late to fix them.
> > > 
> > > Thanks.
> > Right. As a work around virtio net also checks rings
> > when it detects driver ok. We can disable that when VIRTIO_1
> > has been negotiated.
> > 
> 
> So, it looks to me the proper fix is probably start the vhost virtqueues
> selectively only when the vring address is not zero (for 0.9x) or
> queue_enable is set (for 1.0).
> 
> Thanks

Any update here? Looks like a spec violation in qemu
so I think we should fix this before we put out the
release. Jason do you have the time to work on a fix?

-- 
MST



Re: [Qemu-devel] [PATCH v3 1/8] slirp: update COPYRIGHT to use full 3-Clause BSD License

2019-03-21 Thread Thomas Huth
On 14/03/2019 14.34, Eric Blake wrote:
> On 3/14/19 8:10 AM, Marc-André Lureau wrote:
>> According to commit 2f5f89963186d42a7ded253bc6cf5b32abb45cec ("Remove
>> the advertising clause from the slirp license"), Danny Gasparovski
>> gave permission to license slirp code under 3-clause BSD license:
>>
>> Subject: RE: Slirp license
>> Date: Thu, 8 Jan 2009 10:51:00 +1100
>> From: "Gasparovski, Daniel" 
>> To: "Richard Fontana" 
>>
>> I have no objection to having Slirp code in QEMU be licensed under
>> the 3-clause BSD license.
>>
>> slirp/COPYRIGHT's initial version in 2004 (commit 5fafdf24) listed
>> only 3 clauses BUT used the poisonous advertising clause for clause 3
>> which is the controversial clause of non-free 4-clause (that is, it
>> appears that the BSD-4 license was copied, and then the WRONG clause
>> was deleted, when creating COPYRIGHT.

When you look at the files in the original slirp repository with:

 cvs -z3 -d:pserver:anonym...@a.cvs.sourceforge.net:/cvsroot/slirp co -P
slirp-1.0

... you can see that the file already looked like this there. So I guess
the statement from Danny Gasparovski was rather about the copyright
remarks in the source files. But for consistency with the source files,
the missing clause should be added to this COPYRIGHT file here, too, so
I think the patch is the right thing to do, thus:

Reviewed-by: Thomas Huth 

>> + 3. Neither the name of the copyright holder nor the names of its
>> +contributors may be used to endorse or promote products derived
>> +from this software without specific prior written permission.
> 
> Matches the text on both:
> https://spdx.org/licenses/BSD-3-Clause.html
> https://opensource.org/licenses/BSD-3-Clause
> 
> (well, those two pages differ on whether "All rights reserved" is part
> of the boilerplate, but that's a different battle that doesn't affect
> this cleanup)

"All rights reserved" is not needed anymore since the year 2000, see:

https://en.wikipedia.org/wiki/All_rights_reserved#Obsolescence

 Thomas




signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH v3 2/8] slirp: relicense GPL files to BSD-3

2019-03-21 Thread Thomas Huth
On 14/03/2019 14.10, Marc-André Lureau wrote:
> In order to make slirp a standalone project, the project must have a
> clear license, and be compatible with the GPL or LGPL.
> 
> Since commit 2f5f89963186d42a7ded253bc6cf5b32abb45cec ("Remove the
> advertising clause from the slirp license"), slirp is BSD-3. But new
> files have been added under slirp/ with QEMU GPL license since then.
> 
> The copyright holders have been asked to relicense files to BSD-3 and
> gave their permission:
> 
> - slirp/dhcpv6.{c,h}
> 
> Subject: Re: Clearing slirp/ license
> To: "Marc-André Lureau" , QEMU 
> , Thomas Huth 
> Cc: Peter Maydell , Samuel Thibault 
> 
> References: 
> 
> From: "Cédric Le Goater" 
> Message-ID: 
> Date: Mon, 11 Mar 2019 16:23:25 +0100
> 
>> Could you reply that you have no objection in relicensing those files
>> are 3-Clause BSD?
> 
> Fine for me. You can change the license of slirp/ncsi.c and
> slirp/ncsi-pkt.hto a 3-Clause BSD.
> 
> Thanks,
> 
> C.
> 
> Subject: Re: [Qemu-devel] Clearing slirp/ license
> To: Peter Maydell , Shan Gavin 
> 
> Cc: Alexey Kardashevskiy , "Marc-André Lureau" 
> , Gavin Shan , Thomas 
> Huth , QEMU , Samuel Thibault 
> 
> References: 
>  
>  
>  
>  
>  
> 
> From: "Cédric Le Goater" 
> Message-ID: <4ddf6031-0df1-b3b5-965e-a181266e4...@kaod.org>
> Date: Tue, 12 Mar 2019 11:49:21 +0100
> 
>> Is the code in question copyright you personally, or copyright
>> IBM as your employer at the time ? If the latter, it is IBM that
>> would need to approve the relicensing.
> 
> That was done. I had our legal team approve the change of license.
> 
> Thanks,
> 
> C.
> 
> From: Shan Gavin 
> Date: Tue, 12 Mar 2019 15:04:54 +0800
> Message-ID: 
> 
> Subject: Re: [Qemu-devel] Clearing slirp/ license
> To: Alexey Kardashevskiy 
> Cc: "Marc-André Lureau" , "Cédric Le Goater" 
> , gws...@linux.vnet.ibm.com, Peter Maydell 
> , Thomas Huth , QEMU 
> , Samuel Thibault 
> 
>> Gavin, could you reply that you have no objection in relicensing
>> ncsi-pkt.h as 3-Clause BSD?
> 
> No objection. Please go ahead with the relicensing.
> 
> Cheers,
> Gavin
> 
> - ncsi.c, ncsi-pkt.h
> 
> Subject: Re: Clearing slirp/ license
> To: "Marc-André Lureau" , QEMU 
> , "Cédric Le Goater" 
> Cc: Peter Maydell , Samuel Thibault 
> 
> References: 
> 
> From: Thomas Huth 
> Message-ID: 
> Date: Wed, 13 Feb 2019 12:30:32 +0100
> 
>> Could you reply that you have no objection in relicensing those files
>> are 3-Clause BSD?
> 
> Ok, for the records: I'm fine if you change the license of dhcpv6.[ch]
> to either 3-Clause BSD or 2-Clause BSD.
> 
>  Thomas
> 
> - vmstate.{c,h}
> 
> From: Juan Quintela 
> To: "Marc-André Lureau" 
> Cc: QEMU , Peter Maydell , 
> Samuel Thibault 
> Subject: Re: Clearing slirp/ license
> Date: Tue, 12 Mar 2019 12:43:17 +0100
> Message-ID: <87k1h4qpwq@trasno.org>
> 
>> Juan, Could you reply that you have no objection in relicensing the
>> vmstate files as 3-Clause BSD?
> 
> No problem at all on my side.
> 
> Later, Juan.
> 
> Signed-off-by: Marc-André Lureau 
> Reviewed-by: Eric Blake 
> ---
>  slirp/src/dhcpv6.h   | 31 +--
>  slirp/src/ncsi-pkt.h | 33 +
>  slirp/src/vmstate.h  | 42 +++---
>  slirp/src/dhcpv6.c   | 37 +++--
>  slirp/src/ncsi.c | 31 +--
>  slirp/src/vmstate.c  | 31 +--
>  6 files changed, 170 insertions(+), 35 deletions(-)

Acked-by: Thomas Huth 



[Qemu-devel] [PATCH] ohci: don't die on ED_LINK_LIMIT overflow

2019-03-21 Thread Laurent Vivier
Stop processing the descriptor list instead. The next frame timer tick will
resume the work

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1686705
Suggested-by: Gerd Hoffmann 
Signed-off-by: Laurent Vivier 
---
 hw/usb/hcd-ohci.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/hw/usb/hcd-ohci.c b/hw/usb/hcd-ohci.c
index 196a9f72002d..81cf5ab7a5a7 100644
--- a/hw/usb/hcd-ohci.c
+++ b/hw/usb/hcd-ohci.c
@@ -1200,7 +1200,7 @@ static int ohci_service_ed_list(OHCIState *ohci, uint32_t 
head, int completion)
 if (head == 0)
 return 0;
 
-for (cur = head; cur; cur = next_ed) {
+for (cur = head; cur && link_cnt++ < ED_LINK_LIMIT; cur = next_ed) {
 if (ohci_read_ed(ohci, cur, &ed)) {
 trace_usb_ohci_ed_read_error(cur);
 ohci_die(ohci);
@@ -1209,11 +1209,6 @@ static int ohci_service_ed_list(OHCIState *ohci, 
uint32_t head, int completion)
 
 next_ed = ed.next & OHCI_DPTR_MASK;
 
-if (++link_cnt > ED_LINK_LIMIT) {
-ohci_die(ohci);
-return 0;
-}
-
 if ((ed.head & OHCI_ED_H) || (ed.flags & OHCI_ED_K)) {
 uint32_t addr;
 /* Cancel pending packets for ED that have been paused.  */
-- 
2.20.1




Re: [Qemu-devel] [PATCH v8 1/2] pflash: Require backend size to match device, improve errors

2019-03-21 Thread Alex Bennée


Markus Armbruster  writes:

> We reject undersized backends with a rather enigmatic "failed to read
> the initial flash content" error.  For instance:
>
> $ qemu-system-ppc64 -S -display none -M sam460ex -drive 
> if=pflash,format=raw,file=eins.img
> qemu-system-ppc64: Initialization of device cfi.pflash02 failed: failed 
> to read the initial flash content
>
> We happily accept oversized images, ignoring their tail.  Throwing
> away parts of firmware that way is pretty much certain to end in an
> even more enigmatic failure to boot.
>
> Require the backend's size to match the device's size exactly.  Report
> mismatch like this:
>
> qemu-system-ppc64: Initialization of device cfi.pflash01 failed: device 
> requires 1048576 bytes, block backend provides 512 bytes
>
> Improve the error for actual read failures to "can't read block
> backend".
>
> To avoid duplicating even more code between the two pflash device
> models, do all that in new helper blk_check_size_and_read_all().
>
> The error reporting can still be confusing.  For instance:
>
> qemu-system-ppc64 -S -display none -M taihu -drive 
> if=pflash,format=raw,file=eins.img  -drive 
> if=pflash,unit=1,format=raw,file=zwei.img
> qemu-system-ppc64: Initialization of device cfi.pflash02 failed: device 
> requires 2097152 bytes, block backend provides 512 bytes
>
> Leaves the user guessing which of the two -drive is wrong.  Mention
> the issue in a TODO comment.
>
> Suggested-by: Alex Bennée 
> Signed-off-by: Markus Armbruster 

My this patch has morphed a bit... thanks for carrying it forward:

Reviewed-by: Alex Bennée 

> ---
>  hw/block/block.c | 48 +++-
>  hw/block/pflash_cfi01.c  |  8 +++
>  hw/block/pflash_cfi02.c  |  7 +++---
>  include/hw/block/block.h |  7 +-
>  4 files changed, 59 insertions(+), 11 deletions(-)
>
> diff --git a/hw/block/block.c b/hw/block/block.c
> index cf0eb826f1..bf56c7612b 100644
> --- a/hw/block/block.c
> +++ b/hw/block/block.c
> @@ -13,7 +13,53 @@
>  #include "hw/block/block.h"
>  #include "qapi/error.h"
>  #include "qapi/qapi-types-block.h"
> -#include "qemu/error-report.h"
> +
> +/*
> + * Read the entire contents of @blk into @buf.
> + * @blk's contents must be @size bytes, and @size must be at most
> + * BDRV_REQUEST_MAX_BYTES.
> + * On success, return true.
> + * On failure, store an error through @errp and return false.
> + * Note that the error messages do not identify the block backend.
> + * TODO Since callers don't either, this can result in confusing
> + * errors.
> + * This function not intended for actual block devices, which read on
> + * demand.  It's for things like memory devices that (ab)use a block
> + * backend to provide persistence.
> + */
> +bool blk_check_size_and_read_all(BlockBackend *blk, void *buf, hwaddr size,
> + Error **errp)
> +{
> +int64_t blk_len;
> +int ret;
> +
> +blk_len = blk_getlength(blk);
> +if (blk_len < 0) {
> +error_setg_errno(errp, -blk_len,
> + "can't get size of block backend");
> +return false;
> +}
> +if (blk_len != size) {
> +error_setg(errp, "device requires %" HWADDR_PRIu " bytes, "
> +   "block backend provides %" PRIu64 " bytes",
> +   size, blk_len);
> +return false;
> +}
> +
> +/*
> + * We could loop for @size > BDRV_REQUEST_MAX_BYTES, but if we
> + * ever get to the point we want to read *gigabytes* here, we
> + * should probably rework the device to be more like an actual
> + * block device and read only on demand.
> + */
> +assert(size <= BDRV_REQUEST_MAX_BYTES);
> +ret = blk_pread(blk, 0, buf, size);
> +if (ret < 0) {
> +error_setg_errno(errp, -ret, "can't read block backend");
> +return false;
> +}
> +return true;
> +}
>
>  void blkconf_blocksizes(BlockConf *conf)
>  {
> diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
> index 125f70b8e4..9937739a82 100644
> --- a/hw/block/pflash_cfi01.c
> +++ b/hw/block/pflash_cfi01.c
> @@ -38,6 +38,7 @@
>
>  #include "qemu/osdep.h"
>  #include "hw/hw.h"
> +#include "hw/block/block.h"
>  #include "hw/block/flash.h"
>  #include "sysemu/block-backend.h"
>  #include "qapi/error.h"
> @@ -763,12 +764,9 @@ static void pflash_cfi01_realize(DeviceState *dev, Error 
> **errp)
>  }
>
>  if (pfl->blk) {
> -/* read the initial flash content */
> -ret = blk_pread(pfl->blk, 0, pfl->storage, total_len);
> -
> -if (ret < 0) {
> +if (!blk_check_size_and_read_all(pfl->blk, pfl->storage, total_len,
> + errp)) {
>  vmstate_unregister_ram(&pfl->mem, DEVICE(pfl));
> -error_setg(errp, "failed to read the initial flash content");
>  return;
>  }
>  }
> diff --git a/hw/block/pflash_cfi02.c b/hw/block/pflash_cfi02.c
> index c9db430611..9b93

Re: [Qemu-devel] [PATCH] Clean up includes

2019-03-21 Thread Thomas Huth
On 13/03/2019 17.28, Markus Armbruster wrote:
> Clean up includes so that osdep.h is included first and headers
> which it implies are not included manually.
> 
> This commit was created with scripts/clean-includes, with the changes
> to the following files manually reverted:
> 
> contrib/libvhost-user/libvhost-user-glib.h
> contrib/libvhost-user/libvhost-user.c
> contrib/libvhost-user/libvhost-user.h
> linux-user/mips64/cpu_loop.c
> linux-user/mips64/signal.c
> linux-user/sparc64/cpu_loop.c
> linux-user/sparc64/signal.c
> linux-user/x86_64/cpu_loop.c
> linux-user/x86_64/signal.c
> slirp/src/*
> target/s390x/gen-features.c
> tests/migration/s390x/a-b-bios.c
> tests/test-rcu-simpleq.c
> tests/test-rcu-tailq.c
> tests/uefi-test-tools/UefiTestToolsPkg/BiosTablesTest/BiosTablesTest.c
> 
> We're in the process of spinning out slirp/.  tests/uefi-test-tools/
> is guest software.  The remaining reverts are the same as in commit
> b7d89466dde.
> 
> Signed-off-by: Markus Armbruster 
> ---
>  contrib/elf2dmp/main.c   | 3 +--
>  contrib/elf2dmp/pdb.c| 3 +--
>  hw/display/ati.c | 1 +
>  hw/display/ati_2d.c  | 1 +
>  hw/display/ati_dbg.c | 1 +
>  hw/display/ati_int.h | 1 -
>  include/hw/cpu/cluster.h | 1 -
>  tests/fp/platform.h  | 1 -
>  tests/libqos/qgraph.h| 4 
>  tests/qos-test.c | 2 +-
>  10 files changed, 6 insertions(+), 12 deletions(-)

Reviewed-by: Thomas Huth 



Re: [Qemu-devel] [PATCH] qemu-pr-helper: check the return value of fcntl in do_pr_out

2019-03-21 Thread Stefano Garzarella
Hi Zhengui,
thanks for this patch!

For the next patches, please add a version tag when resending.
"git format-patch" and "git send-email" both understand the
"-v2" option.

On Wed, Mar 20, 2019 at 10:07:27PM +0800, Zhengui li wrote:
> The function fcntl maybe return -1, which is not a unsigned type.
> Unsigned type or Negative values should not do bitwise operator with
> O_ACCMODE.
> 
> Signed-off-by: Zhengui li 
> ---
>  scsi/qemu-pr-helper.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)

Reviewed-by: Stefano Garzarella 

> 
> diff --git a/scsi/qemu-pr-helper.c b/scsi/qemu-pr-helper.c
> index e7af637..fcbe4d9 100644
> --- a/scsi/qemu-pr-helper.c
> +++ b/scsi/qemu-pr-helper.c
> @@ -551,8 +551,14 @@ static int do_pr_out(int fd, const uint8_t *cdb, uint8_t 
> *sense,
>   const uint8_t *param, int sz)
>  {
>  int resp_sz;
> +int flags;
>  
> -if ((fcntl(fd, F_GETFL) & O_ACCMODE) == O_RDONLY) {
> +flags = fcntl(fd, F_GETFL);
> +if (flags < 0) {
> +return -1;
> +}
> +
> +if (((unsigned int) flags & O_ACCMODE) == O_RDONLY) {
>  scsi_build_sense(sense, SENSE_CODE(INVALID_OPCODE));
>  return CHECK_CONDITION;
>  }
> -- 
> 2.7.2.windows.1
> 
> 
> 



Re: [Qemu-devel] [PULL 0/1] seccomp branch queue

2019-03-21 Thread Peter Maydell
On Wed, 20 Mar 2019 at 15:11, Eduardo Otubo  wrote:
>
> The following changes since commit 62a172e6a77d9072bb1a18f295ce0fcf4b90a4f2:
>
>   Update version for v4.0.0-rc0 release (2019-03-19 17:17:22 +)
>
> are available in the Git repository at:
>
>   https://github.com/otubo/qemu.git tags/pull-seccomp-20190320
>
> for you to fetch changes up to a25f1f63814c8ac5347a4d744c5bbad2702ef51c:
>
>   seccomp: don't kill process for resource control syscalls (2019-03-20 
> 16:05:02 +0100)
>
> 
> pull-seccomp-20190320
>
> 
> Daniel P. Berrangé (1):
>   seccomp: don't kill process for resource control syscalls

Hi; I'm afraid this doesn't build on all platforms:

On PPC64 and also on my x86-64 box:
/home/pm215/qemu/qemu-seccomp.c: In function ‘seccomp_start’:
/home/pm215/qemu/qemu-seccomp.c:181:9: error: implicit declaration of
function ‘qemu_seccomp_get_kill_action’
[-Werror=implicit-function-declaration]
 action = qemu_seccomp_get_kill_action(blacklist[i].set);
 ^
/home/pm215/qemu/qemu-seccomp.c:181:9: error: nested extern
declaration of ‘qemu_seccomp_get_kill_action’ [-Werror=nested-externs]
/home/pm215/qemu/qemu-seccomp.c: At top level:
/home/pm215/qemu/qemu-seccomp.c:124:17: error:
‘qemu_seccomp_get_action’ defined but not used
[-Werror=unused-function]
 static uint32_t qemu_seccomp_get_action(int set)
 ^

I think this will fail to build anywhere where
CONFIG_SECCOMP is set, or am I missing something ?

thanks
-- PMM



[Qemu-devel] 答复: [PATCH] qemu-pr-helper: check the return value of fcntl in do_pr_out

2019-03-21 Thread lizhengui
Ok!

-邮件原件-
发件人: Stefano Garzarella [mailto:sgarz...@redhat.com] 
发送时间: 2019年3月21日 17:28
收件人: lizhengui
抄送: pbonz...@redhat.com; stefa...@redhat.com; mre...@redhat.com; 
kw...@redhat.com; wangjie (P); qemu-devel@nongnu.org; qemu-bl...@nongnu.org; 
Fangyi (C)
主题: Re: [Qemu-devel] [PATCH] qemu-pr-helper: check the return value of fcntl in 
do_pr_out

Hi Zhengui,
thanks for this patch!

For the next patches, please add a version tag when resending.
"git format-patch" and "git send-email" both understand the
"-v2" option.

On Wed, Mar 20, 2019 at 10:07:27PM +0800, Zhengui li wrote:
> The function fcntl maybe return -1, which is not a unsigned type.
> Unsigned type or Negative values should not do bitwise operator with
> O_ACCMODE.
> 
> Signed-off-by: Zhengui li 
> ---
>  scsi/qemu-pr-helper.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)

Reviewed-by: Stefano Garzarella 

> 
> diff --git a/scsi/qemu-pr-helper.c b/scsi/qemu-pr-helper.c
> index e7af637..fcbe4d9 100644
> --- a/scsi/qemu-pr-helper.c
> +++ b/scsi/qemu-pr-helper.c
> @@ -551,8 +551,14 @@ static int do_pr_out(int fd, const uint8_t *cdb, uint8_t 
> *sense,
>   const uint8_t *param, int sz)
>  {
>  int resp_sz;
> +int flags;
>  
> -if ((fcntl(fd, F_GETFL) & O_ACCMODE) == O_RDONLY) {
> +flags = fcntl(fd, F_GETFL);
> +if (flags < 0) {
> +return -1;
> +}
> +
> +if (((unsigned int) flags & O_ACCMODE) == O_RDONLY) {
>  scsi_build_sense(sense, SENSE_CODE(INVALID_OPCODE));
>  return CHECK_CONDITION;
>  }
> -- 
> 2.7.2.windows.1
> 
> 
> 


Re: [Qemu-devel] [PATCH v8 1/2] pflash: Require backend size to match device, improve errors

2019-03-21 Thread Philippe Mathieu-Daudé
Le mar. 19 mars 2019 17:35, Markus Armbruster  a écrit :

> We reject undersized backends with a rather enigmatic "failed to read
> the initial flash content" error.  For instance:
>
> $ qemu-system-ppc64 -S -display none -M sam460ex -drive
> if=pflash,format=raw,file=eins.img
> qemu-system-ppc64: Initialization of device cfi.pflash02 failed:
> failed to read the initial flash content
>
> We happily accept oversized images, ignoring their tail.  Throwing
> away parts of firmware that way is pretty much certain to end in an
> even more enigmatic failure to boot.
>
> Require the backend's size to match the device's size exactly.  Report
> mismatch like this:
>
> qemu-system-ppc64: Initialization of device cfi.pflash01 failed:
> device requires 1048576 bytes, block backend provides 512 bytes
>
> Improve the error for actual read failures to "can't read block
> backend".
>
> To avoid duplicating even more code between the two pflash device
> models, do all that in new helper blk_check_size_and_read_all().
>
> The error reporting can still be confusing.  For instance:
>
> qemu-system-ppc64 -S -display none -M taihu -drive
> if=pflash,format=raw,file=eins.img  -drive
> if=pflash,unit=1,format=raw,file=zwei.img
> qemu-system-ppc64: Initialization of device cfi.pflash02 failed:
> device requires 2097152 bytes, block backend provides 512 bytes
>
> Leaves the user guessing which of the two -drive is wrong.  Mention
> the issue in a TODO comment.
>
> Suggested-by: Alex Bennée 
> Signed-off-by: Markus Armbruster 
> ---
>  hw/block/block.c | 48 +++-
>  hw/block/pflash_cfi01.c  |  8 +++
>  hw/block/pflash_cfi02.c  |  7 +++---
>  include/hw/block/block.h |  7 +-
>  4 files changed, 59 insertions(+), 11 deletions(-)
>
> diff --git a/hw/block/block.c b/hw/block/block.c
> index cf0eb826f1..bf56c7612b 100644
> --- a/hw/block/block.c
> +++ b/hw/block/block.c
> @@ -13,7 +13,53 @@
>  #include "hw/block/block.h"
>  #include "qapi/error.h"
>  #include "qapi/qapi-types-block.h"
> -#include "qemu/error-report.h"
> +
> +/*
> + * Read the entire contents of @blk into @buf.
> + * @blk's contents must be @size bytes, and @size must be at most
> + * BDRV_REQUEST_MAX_BYTES.
> + * On success, return true.
> + * On failure, store an error through @errp and return false.
> + * Note that the error messages do not identify the block backend.
> + * TODO Since callers don't either, this can result in confusing
> + * errors.
> + * This function not intended for actual block devices, which read on
> + * demand.  It's for things like memory devices that (ab)use a block
> + * backend to provide persistence.
> + */
> +bool blk_check_size_and_read_all(BlockBackend *blk, void *buf, hwaddr
> size,
> + Error **errp)
> +{
> +int64_t blk_len;
> +int ret;
> +
> +blk_len = blk_getlength(blk);
> +if (blk_len < 0) {
> +error_setg_errno(errp, -blk_len,
> + "can't get size of block backend");
> +return false;
> +}
> +if (blk_len != size) {
> +error_setg(errp, "device requires %" HWADDR_PRIu " bytes, "
> +   "block backend provides %" PRIu64 " bytes",
> +   size, blk_len);
> +return false;
> +}
> +
> +/*
> + * We could loop for @size > BDRV_REQUEST_MAX_BYTES, but if we
> + * ever get to the point we want to read *gigabytes* here, we
> + * should probably rework the device to be more like an actual
> + * block device and read only on demand.
> + */
> +assert(size <= BDRV_REQUEST_MAX_BYTES);
> +ret = blk_pread(blk, 0, buf, size);
> +if (ret < 0) {
> +error_setg_errno(errp, -ret, "can't read block backend");
> +return false;
> +}
> +return true;
> +}
>
>  void blkconf_blocksizes(BlockConf *conf)
>  {
> diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
> index 125f70b8e4..9937739a82 100644
> --- a/hw/block/pflash_cfi01.c
> +++ b/hw/block/pflash_cfi01.c
> @@ -38,6 +38,7 @@
>
>  #include "qemu/osdep.h"
>  #include "hw/hw.h"
> +#include "hw/block/block.h"
>  #include "hw/block/flash.h"
>  #include "sysemu/block-backend.h"
>  #include "qapi/error.h"
> @@ -763,12 +764,9 @@ static void pflash_cfi01_realize(DeviceState *dev,
> Error **errp)
>  }
>
>  if (pfl->blk) {
> -/* read the initial flash content */
> -ret = blk_pread(pfl->blk, 0, pfl->storage, total_len);
> -
> -if (ret < 0) {
> +if (!blk_check_size_and_read_all(pfl->blk, pfl->storage,
> total_len,
> + errp)) {
>  vmstate_unregister_ram(&pfl->mem, DEVICE(pfl));
> -error_setg(errp, "failed to read the initial flash content");
>  return;
>  }
>  }
> diff --git a/hw/block/pflash_cfi02.c b/hw/block/pflash_cfi02.c
> index c9db430611..9b934305fa 100644
> --- a/hw/block/pflash_cfi02.c
> +++ b/hw/block/pflash_c

Re: [Qemu-devel] State of QEMU CI as we enter 4.0

2019-03-21 Thread Alex Bennée


Cleber Rosa  writes:

> On Thu, Mar 14, 2019 at 03:57:06PM +, Alex Bennée wrote:
>>
>> Hi,
>>
>> As we approach stabilisation for 4.0 I thought it would be worth doing a
>> review of the current state of CI and stimulate some discussion of where
>> it is working for us and what could be improved.
>>
>> Testing in Build System
>> ===
>>
>> Things seem to be progressing well in this respect. More and more tests
>> have been added into the main source tree and they are only a make
>> invocation away. These include:
>>
>>   check  (includes unit, qapi-schema, qtest and decodetree)
>>   check-tcg  (now with system mode tests!)
>>   check-softfloat
>>   check-block
>>   check-acceptance
>>
>> Personally check-acceptance is the area I've looked at the least but
>> this seems to be the best place for "full life cycle" tests like booting
>> kernels and running stress and performance tests. I'm still a little
>> unsure how we deal with prebuilt kernels and images here though. Are
>> they basically provided by 3rd parties from their websites? Do we mirror
>> any of the artefacts we use for these tests?
>
> While it's possible to add any sort of files alongside the tests, and
> "get it"[1] from the test[2], this is certainly not desirable for
> kernels and other similarly large blobs.  The current approach is to
> use well known URLs[3] and download[4][5] those at test run time.
>
> Those are cached locally, automatically on the first run and reused on
> subsequent executions.  The caching is helpful for development
> environments, but is usually irrelevant to CI environments, where
> you'd most often than not get a new machine (or a clean environment).
>
> For now I would, also for the sake of simplicity, keep relying on 3rd
> party websites until they prove to be unreliable.  This adds
> trasnparency and reproducibility well beyond can be achieved if we
> attempt to mirror them to a QEMU sponsored/official location IMO.

I think this is fine for "well-known" artefacts. Any distro kernel is
reproducible if you go through the appropriate steps. But we don't want
to repeat the mistakes of:

  https://wiki.qemu.org/Testing/System_Images

which is a fairly random collection of stuff. At least the Advent
Calendar images have a bit more documentation with them.

>
>>
>> One area of concern is how well this all sits with KVM (and other HW
>> accelerators) and how that gets tested. With my ARM hat on I don't
>> really see any integration between testing kernel and QEMU changes
>> together to catch any problems as the core OS support for KVM gets
>> updated.
>>
>
> In short, I don't think there should be at the QEMU CI be any
> integration testing that changes both KVM and QEMU at once.
>
> But, that's me assuming that the vast majority of changes in QEMU and
> KVM can be developed, an tested separately of each other.  That's in
> sharp contrast with the the days in which KVM Autotest would build
> both the kernel and userspace as part of all test jobs, because of
> very frequent dependencies among them.
>
> I'd love to get feedback on this from KVM (and other HW accelerator)
> folks.
>
>> Another area I would like to improve is how we expand testing with
>> existing test suites. I'm thinking things like LTP and kvm-unit-tests
>> which can exercise a bunch of QEMU code but are maybe a bit to big to be
>> included in the source tree. Although given we included TestFloat (via a
>> git submodule) maybe we shouldn't dismiss that approach? Or is this
>> something that could be done via Avocado?
>>
>
> Well, there's this:
>
>   https://github.com/avocado-framework-tests/avocado-misc-tests
>
> Which contains close to 300 tests, most of them wrappers for other
> test suites, including LTP:
>
>   
> https://github.com/avocado-framework-tests/avocado-misc-tests/blob/master/generic/ltp.py
>
> I'm claiming it's the perfect fit for your idea, but sounds like a
> good starting point.

Cool - I shall have a look at that the other side of Connect. I'd like
to make running LTP easier for non-core linux-user developers.

>
>> Generally though I think we are doing pretty well at increasing our test
>> coverage while making the tests more directly available to developers
>> without having to rely on someones personal collection of random
>> binaries.
>>
>
> +1.
>
>> I wanted to know if we should encode this somewhere in our developer
>> documentation:
>>
>>   There is a strong preference for new QEMU tests to be integrated with
>>   the build system. Developers should be able to (build and) run the new
>>   tests locally directly from make.
>>
>> ?
>>
>
> There should definitely be, if reasonable, a similar experience for
> running different types of tests.  Right now, the build system (make
> targets) is clearly the common place, so +1.
>
> - Cleber.
>
> [1] - 
> https://avocado-framework.readthedocs.io/en/69.0/api/core/avocado.core.html#avocado.core.test.TestData.get_data
> [2] - 
> https://avocado-framewo

Re: [Qemu-devel] State of QEMU CI as we enter 4.0

2019-03-21 Thread Alex Bennée


Wainer dos Santos Moschetta  writes:

> Hi all,

>> Conclusion
>> ==
>>
>> I think generally the state of QEMU's CI has improved over the last few
>> years but we still have a number of challenges caused by its distributed
>> nature and test stability. We are still re-active to failures rather
>> than having something fast and reliable enough to gate changes going
>> into the code base. This results in fairly long periods when one
>> or more parts of the testing mosaic are stuck on red waiting for fixes
>> to finally get merged back into master.
>>
>> So what do people think? Have I missed anything out? What else can we do
>> to improve the situation?
>>
>> Let the discussion begin ;-)
>
> I want to help on improve QEMU CI, and in fact I can commit some time
> to do so. But since I'm new to the community and made just a few
> contributions, I'm in the position of only try to understand what we
> have in place now.
>
> So allow me to put this in a different perspective. I took some notes
> in terms of CI workflows we have. It goes below along with some
> comments and questions:
>
> 
> Besides being distributed across CI providers, there are different CI
> workflows being executed on each stages of the development process.
>
> - Developer tests before send the patch to the mailing-list
>   Each developer has its own recipe.
>   Can be as simple as `make check[-TEST-SUITE]` locally. Or
> Docker-based `make docker-*` tests.

The make docker-* tests mostly cover building on other distros where
there might be subtle differences. The tests themselves are the same
make check-FOO as before.

>   It seems not widely used but some may also use push to GitHub/GibLab
> + triggers to the cloud provider.
>
>   What kind of improvements we can make here?
>   Perhaps (somehow) automate the github/githab + triggers to cloud
> provider workflow?

We have a mechanism that can already do that with patchew. But I'm not
sure how much automation can be done for developers given they need to
have accounts on the relevant services. Once that is done however it
really is just a few git pushes.

>   Allow to reproduce a failure that happens on cloud provider locally,
> when it comes to failures that occurred on next stages of development
> (see below) seems highly appreciated.

In theory yes, in practice it seems our CI providers are quite good at
producing failures under load. I've run tests that fail on travis 10's
thousands of times locally without incident. The reproductions I've done
recently have all been on VMs where I've constrained memory and vCPUs
and then very heavily loaded them. It seems like most developers are
blessed with beefy boxes that rarely show up these problems.

What would be more useful is being able to debug the failure that
occurred on the CI system. Either by:

  a) having some sort of access to the failed system

  The original Travis setup didn't really support that but I think there
  may be options now. I haven't really looked into the other CI setups
  yet. They may be better off. Certainly if we can augment CI with our
  own runners they are easier to give developers access to.

  b) upload the failure artefacts *somewhere*

  Quite a lot of these failures should be dumping core. Maybe if we can
  upload the core, associated binary, config.log and commit id to
  something we can then do a bit more post-mortem on what went wrong.

  c) dump more information in the CI logs

  An alternative to uploading would be some sort of clean-up script
  which could at least dump backtraces of cores in the logs.

>
> - Developer sends a patch to the mailing-list
>   Patchew pushes the patch to GitHub, run tests (checkpatch, asan,
> docker-clang@ubuntu, docker-mingw@fedora)
>   Reports to ML on failure. Shouldn't send an email on success as well
> so that it creates awareness about CI?

Patchew has been a little inconsistent of late with it's notifications.
Maybe a simple email with a "Just so you know patchew has run all it's
tests on this and it's fine" wouldn't be considered too noisy?

> - Maintainer tests its branch before the pull-request
>   Alike developers, it seems each one sits on its own recipe that may
> (or may not) trigger on an CI provider.

Usually the same set of normal checks plus any particular hand-crafted
tests that might be appropriate for the patches included. For example
for all of Emilio's scaling patches I ran lot of stress tests by hand.
They are only semi-automated because it's not something I'd do for most
branches.

> - Maintainer sends a pull-request to the mailing-list
>   Again patchew gets in. It seems it runs the same tests. Am I right?
>   Also send the email to mailing-list only on failure.

Yes - although generally a PR is collection of patches so it's
technically a new tree state to test.

> - Peter runs tests for each PR
>   IIUC not integrated to any CI provider yet.
>   Likely here we have the most complete scenario in terms of coverage
> (several hosts, targ

[Qemu-devel] [PATCH] block/vhdx: Use IEC binary prefixes from "qemu/units.h"

2019-03-21 Thread Stefano Garzarella
IEC binary prefixes are defined in "qemu/units.h", so we
can remove redundant definitions in "block/vhdx.h".

Signed-off-by: Stefano Garzarella 
---
 block/vhdx-log.c | 1 +
 block/vhdx.c | 4 +++-
 block/vhdx.h | 5 -
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/block/vhdx-log.c b/block/vhdx-log.c
index 3149ff08d8..ad9905eb6d 100644
--- a/block/vhdx-log.c
+++ b/block/vhdx-log.c
@@ -18,6 +18,7 @@
  *
  */
 #include "qemu/osdep.h"
+#include "qemu/units.h"
 #include "qapi/error.h"
 #include "qemu-common.h"
 #include "block/block_int.h"
diff --git a/block/vhdx.c b/block/vhdx.c
index b785aef4b7..e9b16c5ef6 100644
--- a/block/vhdx.c
+++ b/block/vhdx.c
@@ -16,6 +16,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "qemu/units.h"
 #include "qapi/error.h"
 #include "block/block_int.h"
 #include "block/qdict.h"
@@ -1889,7 +1890,8 @@ static int coroutine_fn 
vhdx_co_create(BlockdevCreateOptions *opts,
 return -EINVAL;
 }
 if (block_size > VHDX_BLOCK_SIZE_MAX) {
-error_setg(errp, "Block size must not exceed %d", VHDX_BLOCK_SIZE_MAX);
+error_setg(errp, "Block size must not exceed %" PRId64,
+   VHDX_BLOCK_SIZE_MAX);
 return -EINVAL;
 }
 
diff --git a/block/vhdx.h b/block/vhdx.h
index 1bfb4e4f73..deb6e362ad 100644
--- a/block/vhdx.h
+++ b/block/vhdx.h
@@ -18,11 +18,6 @@
 #ifndef BLOCK_VHDX_H
 #define BLOCK_VHDX_H
 
-#define KiB  (1 * 1024)
-#define MiB(KiB * 1024)
-#define GiB(MiB * 1024)
-#define TiB ((uint64_t) GiB * 1024)
-
 #define DEFAULT_LOG_SIZE 1048576 /* 1MiB */
 /* Structures and fields present in the VHDX file */
 
-- 
2.20.1




Re: [Qemu-devel] [PULL 0/3] Filemon next patches

2019-03-21 Thread Daniel P . Berrangé
Obviously NACK to applying this PULL given the patchew reported
mess up I did with tests.  Not sure why patchew never gave any
complaint when the original patch was posted & reviewed :-(

On Wed, Mar 20, 2019 at 05:41:47PM +, Daniel P. Berrangé wrote:
> The following changes since commit 62a172e6a77d9072bb1a18f295ce0fcf4b90a4f2:
> 
>   Update version for v4.0.0-rc0 release (2019-03-19 17:17:22 +)
> 
> are available in the Git repository at:
> 
>   https://github.com/berrange/qemu tags/filemon-next-pull-request
> 
> for you to fetch changes up to 9c8cc692ccda6912e46a4b13c4bbcd42df3e8673:
> 
>   filemon: fix watch IDs to avoid potential wraparound issues (2019-03-20 
> 17:03:29 +)
> 
> 
> Fix watch uniqueness and protect against guest triggered
> integer wraparound clashes in watches.
> 
> 
> 
> Daniel P. Berrangé (3):
>   tests: refactor file monitor test to make it more understandable
>   filemon: ensure watch IDs are unique to QFileMonitor scope
>   filemon: fix watch IDs to avoid potential wraparound issues
> 
>  authz/listfile.c  |   2 +-
>  hw/usb/dev-mtp.c  |  10 +-
>  include/authz/listfile.h  |   2 +-
>  include/qemu/filemonitor.h|  16 +-
>  tests/test-util-filemonitor.c | 626 +-
>  util/filemonitor-inotify.c|  26 +-
>  util/filemonitor-stub.c   |   4 +-
>  util/trace-events |   6 +-
>  8 files changed, 337 insertions(+), 355 deletions(-)
> 
> -- 
> 2.20.1
> 

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] ohci: don't die on ED_LINK_LIMIT overflow

2019-03-21 Thread Laurent Vivier
On 21/03/2019 11:15, BALATON Zoltan wrote:
> On Thu, 21 Mar 2019, Laurent Vivier wrote:
>> Stop processing the descriptor list instead. The next frame timer tick
>> will
>> resume the work
> 
> Shoud this log something when the limit is reached to let the user know
> why USB stopped working instead of silently ignoring frames?

I don't think frames are ignored, they are only delayed. The aim of
ED_LINK_LIMIT is to avoid an infinite loop inside QEMU.

Thanks,
Laurent

> Regards,
> BALATON Zoltan
> 
>> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1686705
>> Suggested-by: Gerd Hoffmann 
>> Signed-off-by: Laurent Vivier 
>> ---
>> hw/usb/hcd-ohci.c | 7 +--
>> 1 file changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/hw/usb/hcd-ohci.c b/hw/usb/hcd-ohci.c
>> index 196a9f72002d..81cf5ab7a5a7 100644
>> --- a/hw/usb/hcd-ohci.c
>> +++ b/hw/usb/hcd-ohci.c
>> @@ -1200,7 +1200,7 @@ static int ohci_service_ed_list(OHCIState *ohci,
>> uint32_t head, int completion)
>>     if (head == 0)
>>     return 0;
>>
>> -    for (cur = head; cur; cur = next_ed) {
>> +    for (cur = head; cur && link_cnt++ < ED_LINK_LIMIT; cur = next_ed) {
>>     if (ohci_read_ed(ohci, cur, &ed)) {
>>     trace_usb_ohci_ed_read_error(cur);
>>     ohci_die(ohci);
>> @@ -1209,11 +1209,6 @@ static int ohci_service_ed_list(OHCIState
>> *ohci, uint32_t head, int completion)
>>
>>     next_ed = ed.next & OHCI_DPTR_MASK;
>>
>> -    if (++link_cnt > ED_LINK_LIMIT) {
>> -    ohci_die(ohci);
>> -    return 0;
>> -    }
>> -
>>     if ((ed.head & OHCI_ED_H) || (ed.flags & OHCI_ED_K)) {
>>     uint32_t addr;
>>     /* Cancel pending packets for ED that have been paused.  */
>>




Re: [Qemu-devel] [PATCH] ohci: don't die on ED_LINK_LIMIT overflow

2019-03-21 Thread BALATON Zoltan

On Thu, 21 Mar 2019, Laurent Vivier wrote:

Stop processing the descriptor list instead. The next frame timer tick will
resume the work


Shoud this log something when the limit is reached to let the user know 
why USB stopped working instead of silently ignoring frames?


Regards,
BALATON Zoltan


Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1686705
Suggested-by: Gerd Hoffmann 
Signed-off-by: Laurent Vivier 
---
hw/usb/hcd-ohci.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/hw/usb/hcd-ohci.c b/hw/usb/hcd-ohci.c
index 196a9f72002d..81cf5ab7a5a7 100644
--- a/hw/usb/hcd-ohci.c
+++ b/hw/usb/hcd-ohci.c
@@ -1200,7 +1200,7 @@ static int ohci_service_ed_list(OHCIState *ohci, uint32_t 
head, int completion)
if (head == 0)
return 0;

-for (cur = head; cur; cur = next_ed) {
+for (cur = head; cur && link_cnt++ < ED_LINK_LIMIT; cur = next_ed) {
if (ohci_read_ed(ohci, cur, &ed)) {
trace_usb_ohci_ed_read_error(cur);
ohci_die(ohci);
@@ -1209,11 +1209,6 @@ static int ohci_service_ed_list(OHCIState *ohci, 
uint32_t head, int completion)

next_ed = ed.next & OHCI_DPTR_MASK;

-if (++link_cnt > ED_LINK_LIMIT) {
-ohci_die(ohci);
-return 0;
-}
-
if ((ed.head & OHCI_ED_H) || (ed.flags & OHCI_ED_K)) {
uint32_t addr;
/* Cancel pending packets for ED that have been paused.  */





Re: [Qemu-devel] [PULL 0/1] seccomp branch queue

2019-03-21 Thread Eduardo Otubo
On 21/03/2019 - 09:30:24, Peter Maydell wrote:
> On Wed, 20 Mar 2019 at 15:11, Eduardo Otubo  wrote:
> >
> > The following changes since commit 62a172e6a77d9072bb1a18f295ce0fcf4b90a4f2:
> >
> >   Update version for v4.0.0-rc0 release (2019-03-19 17:17:22 +)
> >
> > are available in the Git repository at:
> >
> >   https://github.com/otubo/qemu.git tags/pull-seccomp-20190320
> >
> > for you to fetch changes up to a25f1f63814c8ac5347a4d744c5bbad2702ef51c:
> >
> >   seccomp: don't kill process for resource control syscalls (2019-03-20 
> > 16:05:02 +0100)
> >
> > 
> > pull-seccomp-20190320
> >
> > 
> > Daniel P. Berrangé (1):
> >   seccomp: don't kill process for resource control syscalls
> 
> Hi; I'm afraid this doesn't build on all platforms:
> 
> On PPC64 and also on my x86-64 box:
> /home/pm215/qemu/qemu-seccomp.c: In function ‘seccomp_start’:
> /home/pm215/qemu/qemu-seccomp.c:181:9: error: implicit declaration of
> function ‘qemu_seccomp_get_kill_action’
> [-Werror=implicit-function-declaration]
>  action = qemu_seccomp_get_kill_action(blacklist[i].set);
>  ^
> /home/pm215/qemu/qemu-seccomp.c:181:9: error: nested extern
> declaration of ‘qemu_seccomp_get_kill_action’ [-Werror=nested-externs]
> /home/pm215/qemu/qemu-seccomp.c: At top level:
> /home/pm215/qemu/qemu-seccomp.c:124:17: error:
> ‘qemu_seccomp_get_action’ defined but not used
> [-Werror=unused-function]
>  static uint32_t qemu_seccomp_get_action(int set)
>  ^
> 
> I think this will fail to build anywhere where
> CONFIG_SECCOMP is set, or am I missing something ?

No, actually I messed up the patch while applying. I changed the name of the
function declaration based on some reviews and forgot to change when it is
called. I'll fix that and send again. Sorry for the trouble.

-- 
Eduardo Otubo


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PATCH] ohci: don't die on ED_LINK_LIMIT overflow

2019-03-21 Thread BALATON Zoltan

On Thu, 21 Mar 2019, Laurent Vivier wrote:

On 21/03/2019 11:15, BALATON Zoltan wrote:

On Thu, 21 Mar 2019, Laurent Vivier wrote:

Stop processing the descriptor list instead. The next frame timer tick
will
resume the work


Shoud this log something when the limit is reached to let the user know
why USB stopped working instead of silently ignoring frames?


I don't think frames are ignored, they are only delayed. The aim of
ED_LINK_LIMIT is to avoid an infinite loop inside QEMU.

Thanks,
Laurent


I don't know, just asked. It wasn't clear from commit message to me.


Regards,
BALATON Zoltan


Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1686705
Suggested-by: Gerd Hoffmann 
Signed-off-by: Laurent Vivier 
---
hw/usb/hcd-ohci.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/hw/usb/hcd-ohci.c b/hw/usb/hcd-ohci.c
index 196a9f72002d..81cf5ab7a5a7 100644
--- a/hw/usb/hcd-ohci.c
+++ b/hw/usb/hcd-ohci.c
@@ -1200,7 +1200,7 @@ static int ohci_service_ed_list(OHCIState *ohci,
uint32_t head, int completion)
??? if (head == 0)
??? return 0;

-??? for (cur = head; cur; cur = next_ed) {
+??? for (cur = head; cur && link_cnt++ < ED_LINK_LIMIT; cur = next_ed) {
??? if (ohci_read_ed(ohci, cur, &ed)) {
??? trace_usb_ohci_ed_read_error(cur);
??? ohci_die(ohci);
@@ -1209,11 +1209,6 @@ static int ohci_service_ed_list(OHCIState
*ohci, uint32_t head, int completion)

??? next_ed = ed.next & OHCI_DPTR_MASK;

-??? if (++link_cnt > ED_LINK_LIMIT) {
-??? ohci_die(ohci);
-??? return 0;
-??? }
-
??? if ((ed.head & OHCI_ED_H) || (ed.flags & OHCI_ED_K)) {
??? uint32_t addr;
??? /* Cancel pending packets for ED that have been paused.? */








[Qemu-devel] [PATCH v3 10/10] hw/arm/virt: Init GED device and enable memory hotplug

2019-03-21 Thread Shameer Kolothum
This initializes the GED device with base memory and irq,
configures ged memory hotplug event and builds the
corresponding aml code.

GED irq routing to Guest is also enabled. Memory hotplug
should now work.

Signed-off-by: Shameer Kolothum 
---
 hw/acpi/generic_event_device.c | 18 ++
 hw/arm/virt-acpi-build.c   |  9 +
 hw/arm/virt.c  | 30 +-
 include/hw/arm/virt.h  |  2 ++
 4 files changed, 54 insertions(+), 5 deletions(-)

diff --git a/hw/acpi/generic_event_device.c b/hw/acpi/generic_event_device.c
index 9deaa33..02d5e66 100644
--- a/hw/acpi/generic_event_device.c
+++ b/hw/acpi/generic_event_device.c
@@ -200,6 +200,23 @@ static void acpi_ged_event(GEDState *ged_st, uint32_t 
ged_irq_sel)
 qemu_irq_pulse(ged_st->gsi[ged_st->irq]);
 }
 
+static void acpi_ged_init(MemoryRegion *as, DeviceState *dev, GEDState *ged_st)
+{
+VirtAcpiState *s = VIRT_ACPI(dev);
+
+assert(!ged_io_base && !ged_events && !ged_events_size);
+
+ged_io_base = s->ged_base;
+ged_events = s->ged_events;
+ged_events_size = s->ged_events_size;
+ged_st->irq = s->ged_irq;
+ged_st->gsi = s->gsi;
+qemu_mutex_init(&ged_st->lock);
+memory_region_init_io(&ged_st->io, OBJECT(dev), &ged_ops, ged_st,
+  "acpi-ged-event", ACPI_GED_REG_LEN);
+memory_region_add_subregion(as, ged_io_base, &ged_st->io);
+}
+
 static void virt_device_plug_cb(HotplugHandler *hotplug_dev,
 DeviceState *dev, Error **errp)
 {
@@ -242,6 +259,7 @@ static void virt_device_realize(DeviceState *dev, Error 
**errp)
 acpi_memory_hotplug_init(get_system_memory(), OBJECT(dev),
  &s->memhp_state,
  s->memhp_base);
+acpi_ged_init(get_system_memory(), dev, &s->ged_state);
 }
 }
 
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 1887531..116e9c9 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -41,6 +41,7 @@
 #include "hw/hw.h"
 #include "hw/acpi/aml-build.h"
 #include "hw/acpi/memory_hotplug.h"
+#include "hw/acpi/generic_event_device.h"
 #include "hw/pci/pcie_host.h"
 #include "hw/pci/pci.h"
 #include "hw/arm/virt.h"
@@ -50,6 +51,13 @@
 #define ARM_SPI_BASE 32
 #define ACPI_POWER_BUTTON_DEVICE "PWRB"
 
+static void acpi_dsdt_add_ged(Aml *scope, VirtMachineState *vms)
+{
+int irq =  vms->irqmap[VIRT_ACPI_GED] + ARM_SPI_BASE;
+
+build_ged_aml(scope, "\\_SB."GED_DEVICE, irq, AML_SYSTEM_MEMORY);
+}
+
 static void acpi_dsdt_add_memory_hotplug(Aml *scope, MachineState *ms)
 {
 uint32_t nr_mem = ms->ram_slots;
@@ -758,6 +766,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, 
VirtMachineState *vms)
  */
 scope = aml_scope("\\_SB");
 acpi_dsdt_add_memory_hotplug(scope, MACHINE(vms));
+acpi_dsdt_add_ged(scope, vms);
 acpi_dsdt_add_cpus(scope, vms->smp_cpus);
 acpi_dsdt_add_uart(scope, &memmap[VIRT_UART],
(irqmap[VIRT_UART] + ARM_SPI_BASE));
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index b602151..e3f8aa7 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -63,6 +63,7 @@
 #include "target/arm/internals.h"
 #include "hw/mem/pc-dimm.h"
 #include "hw/mem/nvdimm.h"
+#include "hw/acpi/generic_event_device.h"
 
 #define DEFINE_VIRT_MACHINE_LATEST(major, minor, latest) \
 static void virt_##major##_##minor##_class_init(ObjectClass *oc, \
@@ -134,6 +135,7 @@ static const MemMapEntry base_memmap[] = {
 [VIRT_SECURE_UART] ={ 0x0904, 0x1000 },
 [VIRT_SMMU] =   { 0x0905, 0x0002 },
 [VIRT_PCDIMM_ACPI] ={ 0x0907, 0x0001 },
+[VIRT_ACPI_GED] =   { 0x0908, 0x0001 },
 [VIRT_MMIO] =   { 0x0a00, 0x0200 },
 /* ...repeating for a total of NUM_VIRTIO_TRANSPORTS, each of that size */
 [VIRT_PLATFORM_BUS] =   { 0x0c00, 0x0200 },
@@ -169,6 +171,7 @@ static const int a15irqmap[] = {
 [VIRT_PCIE] = 3, /* ... to 6 */
 [VIRT_GPIO] = 7,
 [VIRT_SECURE_UART] = 8,
+[VIRT_ACPI_GED] = 9,
 [VIRT_MMIO] = 16, /* ...to 16 + NUM_VIRTIO_TRANSPORTS - 1 */
 [VIRT_GIC_V2M] = 48, /* ...to 48 + NUM_GICV2M_SPIS - 1 */
 [VIRT_SMMU] = 74,/* ...to 74 + NUM_SMMU_IRQS - 1 */
@@ -184,6 +187,13 @@ static const char *valid_cpus[] = {
 ARM_CPU_TYPE_NAME("max"),
 };
 
+static GedEvent ged_events[] = {
+{
+.selector = ACPI_GED_IRQ_SEL_MEM,
+.event= GED_MEMORY_HOTPLUG,
+},
+};
+
 static bool cpu_type_valid(const char *cpu)
 {
 int i;
@@ -524,6 +534,11 @@ static DeviceState *create_virt_acpi(VirtMachineState *vms)
 dev = qdev_create(NULL, "virt-acpi");
 qdev_prop_set_uint64(dev, "memhp_base",
  vms->memmap[VIRT_PCDIMM_ACPI].base);
+qdev_prop_set_ptr(dev, "gsi", vms->gsi);
+qdev_prop_set_uint64(dev, "ged_base", vms->memmap[VIRT_ACPI_GED].base);
+qdev_pro

[Qemu-devel] [PATCH v3 06/10] hw/arm/virt-acpi-build: Add PC-DIMM in SRAT

2019-03-21 Thread Shameer Kolothum
Generate Memory Affinity Structures for PC-DIMM ranges.

Signed-off-by: Shameer Kolothum 
Signed-off-by: Eric Auger 
Reviewed-by: Igor Mammedov 
---
 hw/arm/virt-acpi-build.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 20d3c83..1887531 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -524,6 +524,7 @@ build_srat(GArray *table_data, BIOSLinker *linker, 
VirtMachineState *vms)
 int i, srat_start;
 uint64_t mem_base;
 MachineClass *mc = MACHINE_GET_CLASS(vms);
+MachineState *ms = MACHINE(vms);
 const CPUArchIdList *cpu_list = mc->possible_cpu_arch_ids(MACHINE(vms));
 
 srat_start = table_data->len;
@@ -549,6 +550,14 @@ build_srat(GArray *table_data, BIOSLinker *linker, 
VirtMachineState *vms)
 }
 }
 
+if (ms->device_memory) {
+numamem = acpi_data_push(table_data, sizeof *numamem);
+build_srat_memory(numamem, ms->device_memory->base,
+  memory_region_size(&ms->device_memory->mr),
+  nb_numa_nodes - 1,
+  MEM_AFFINITY_HOTPLUGGABLE | MEM_AFFINITY_ENABLED);
+}
+
 build_header(linker, table_data, (void *)(table_data->data + srat_start),
  "SRAT", table_data->len - srat_start, 3, NULL, NULL);
 }
-- 
2.7.4





[Qemu-devel] [PATCH v3 08/10] hw/arm/boot: Expose the PC-DIMM nodes in the DT

2019-03-21 Thread Shameer Kolothum
This patch adds memory nodes corresponding to PC-DIMM regions.
This is an opt-in feature and needs to be enabled("fdt=on") when
Guest is booted with DT.

NVDIMM and ACPI_NVDIMM configs are not yet set for ARM so we
don't need to care about NVDIMM at this stage.

Signed-off-by: Shameer Kolothum 
Signed-off-by: Eric Auger 

Signed-off-by: Shameer Kolothum 
---
 hw/arm/boot.c | 44 
 1 file changed, 44 insertions(+)

diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index a830655..5b9a994 100644
--- a/hw/arm/boot.c
+++ b/hw/arm/boot.c
@@ -19,6 +19,7 @@
 #include "sysemu/numa.h"
 #include "hw/boards.h"
 #include "hw/loader.h"
+#include "hw/mem/memory-device.h"
 #include "elf.h"
 #include "sysemu/device_tree.h"
 #include "qemu/config-file.h"
@@ -522,6 +523,41 @@ static void fdt_add_psci_node(void *fdt)
 qemu_fdt_setprop_cell(fdt, "/psci", "migrate", migrate_fn);
 }
 
+static int fdt_add_hotpluggable_memory_nodes(void *fdt,
+ uint32_t acells, uint32_t scells) 
{
+MemoryDeviceInfoList *info, *info_list = qmp_memory_device_list();
+MemoryDeviceInfo *mi;
+int ret = 0;
+
+for (info = info_list; info != NULL; info = info->next) {
+mi = info->value;
+switch (mi->type) {
+case MEMORY_DEVICE_INFO_KIND_DIMM:
+{
+PCDIMMDeviceInfo *di = mi->u.dimm.data;
+
+ret = fdt_add_memory_node(fdt, acells, di->addr,
+  scells, di->size, di->node);
+if (ret) {
+fprintf(stderr,
+"couldn't add PCDIMM /memory@%"PRIx64" node\n",
+di->addr);
+goto out;
+}
+break;
+}
+default:
+fprintf(stderr, "%s memory nodes are not yet supported\n",
+MemoryDeviceInfoKind_str(mi->type));
+ret = -ENOENT;
+goto out;
+}
+}
+out:
+qapi_free_MemoryDeviceInfoList(info_list);
+return ret;
+}
+
 int arm_load_dtb(hwaddr addr, const struct arm_boot_info *binfo,
  hwaddr addr_limit, AddressSpace *as)
 {
@@ -621,6 +657,14 @@ int arm_load_dtb(hwaddr addr, const struct arm_boot_info 
*binfo,
 }
 }
 
+if (object_property_get_bool(OBJECT(qdev_get_machine()), "fdt", NULL)) {
+rc = fdt_add_hotpluggable_memory_nodes(fdt, acells, scells);
+if (rc < 0) {
+fprintf(stderr, "couldn't add hotpluggable memory nodes\n");
+goto fail;
+}
+}
+
 rc = fdt_path_offset(fdt, "/chosen");
 if (rc < 0) {
 qemu_fdt_add_subnode(fdt, "/chosen");
-- 
2.7.4





[Qemu-devel] [PATCH v3 09/10] hw/acpi: Add ACPI Generic Event Device Support

2019-03-21 Thread Shameer Kolothum
From: Samuel Ortiz 

The ACPI Generic Event Device (GED) is a hardware-reduced specific
device that handles all platform events, including the hotplug ones.
This patch generates the AML code that defines GEDs.

Platforms need to specify their own GedEvent array to describe what
kind of events they want to support through GED.  Also this uses a
a single interrupt for the  GED device, relying on IO memory region
to communicate the type of device affected by the interrupt. This
way, we can support up to 32 events with a unique interrupt.

This is in preparation for making use of GED for ARM/virt
platform and for now supports only memory hotplug.

Signed-off-by: Samuel Ortiz 
Signed-off-by: Sebastien Boeuf 
Signed-off-by: Shameer Kolothum 
---
 hw/acpi/generic_event_device.c | 200 +
 include/hw/acpi/generic_event_device.h |  34 ++
 2 files changed, 234 insertions(+)

diff --git a/hw/acpi/generic_event_device.c b/hw/acpi/generic_event_device.c
index 0b32fc9..9deaa33 100644
--- a/hw/acpi/generic_event_device.c
+++ b/hw/acpi/generic_event_device.c
@@ -23,6 +23,183 @@
 #include "hw/acpi/generic_event_device.h"
 #include "hw/mem/pc-dimm.h"
 
+static hwaddr ged_io_base;
+static GedEvent *ged_events;
+static uint32_t ged_events_size;
+
+static Aml *ged_event_aml(const GedEvent *event)
+{
+
+if (!event) {
+return NULL;
+}
+
+switch (event->event) {
+case GED_MEMORY_HOTPLUG:
+/* We run a complete memory SCAN when getting a memory hotplug event */
+return aml_call0(MEMORY_DEVICES_CONTAINER "." MEMORY_SLOT_SCAN_METHOD);
+default:
+break;
+}
+
+return NULL;
+}
+
+/*
+ * The ACPI Generic Event Device (GED) is a hardware-reduced specific
+ * device[ACPI v6.1 Section 5.6.9] that handles all platform events,
+ * including the hotplug ones. Platforms need to specify their own
+ * GedEvent array to describe what kind of events they want to support
+ * through GED. This routine uses a single interrupt for the GED device,
+ * relying on IO memory region to communicate the type of device
+ * affected by the interrupt. This way, we can support up to 32 events
+ * with a unique interrupt.
+ */
+void build_ged_aml(Aml *table, const char *name, uint32_t ged_irq,
+   AmlRegionSpace rs)
+{
+Aml *crs = aml_resource_template();
+Aml *evt, *field;
+Aml *dev = aml_device("%s", name);
+Aml *irq_sel = aml_local(0);
+Aml *isel = aml_name(AML_GED_IRQ_SEL);
+uint32_t i;
+
+if (!ged_io_base || !ged_events || !ged_events_size) {
+return;
+}
+
+/* _CRS interrupt */
+aml_append(crs, aml_interrupt(AML_CONSUMER, AML_EDGE, AML_ACTIVE_HIGH,
+  AML_EXCLUSIVE, &ged_irq, 1));
+/*
+ * For each GED event we:
+ * - Add an interrupt to the CRS section.
+ * - Add a conditional block for each event, inside a while loop.
+ *   This is semantically equivalent to a switch/case implementation.
+ */
+evt = aml_method("_EVT", 1, AML_SERIALIZED);
+{
+Aml *ged_aml;
+Aml *if_ctx;
+
+/* Local0 = ISEL */
+aml_append(evt, aml_store(isel, irq_sel));
+
+/*
+ * Here we want to call a method for each supported GED event type.
+ * The resulting ASL code looks like:
+ *
+ * Local0 = ISEL
+ * If ((Local0 & irq0) == irq0)
+ * {
+ * MethodEvent0()
+ * }
+ *
+ * If ((Local0 & irq1) == irq1)
+ * {
+ * MethodEvent1()
+ * }
+ *
+ * If ((Local0 & irq2) == irq2)
+ * {
+ * MethodEvent2()
+ * }
+ */
+
+for (i = 0; i < ged_events_size; i++) {
+ged_aml = ged_event_aml(&ged_events[i]);
+if (!ged_aml) {
+continue;
+}
+
+/* If ((Local1 == irq))*/
+if_ctx = aml_if(aml_equal(aml_and(irq_sel, 
aml_int(ged_events[i].selector), NULL), aml_int(ged_events[i].selector)));
+{
+/* AML for this specific type of event */
+aml_append(if_ctx, ged_aml);
+}
+
+/*
+ * We append the first "if" to the "while" context.
+ * Other "ifs" will be "elseifs".
+ */
+aml_append(evt, if_ctx);
+}
+}
+
+aml_append(dev, aml_name_decl("_HID", aml_string("ACPI0013")));
+aml_append(dev, aml_name_decl("_UID", aml_string(GED_DEVICE)));
+aml_append(dev, aml_name_decl("_CRS", crs));
+
+/* Append IO region */
+aml_append(dev, aml_operation_region(AML_GED_IRQ_REG, rs,
+   aml_int(ged_io_base + ACPI_GED_IRQ_SEL_OFFSET),
+   ACPI_GED_IRQ_SEL_LEN));
+field = aml_field(AML_GED_IRQ_REG, AML_DWORD_ACC, AML_NOLOCK,
+  AML_WRITE_AS_ZEROS);
+aml_append(field, aml_named_field(AML_GED_IRQ_SEL,
+  ACPI_GED

[Qemu-devel] [PATCH v3 02/10] hw/acpi: Do not create memory hotplug method when handler is not defined

2019-03-21 Thread Shameer Kolothum
From: Samuel Ortiz 

With Hardware-reduced ACPI, the GED device will manage ACPI
hotplug entirely. As a consequence, make the memory specific
events AML generation optional. The code will only be added
when the method name is not NULL.

Signed-off-by: Samuel Ortiz 
Signed-off-by: Shameer Kolothum 
---
 hw/acpi/memory_hotplug.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/hw/acpi/memory_hotplug.c b/hw/acpi/memory_hotplug.c
index 80e25f0..98407e3 100644
--- a/hw/acpi/memory_hotplug.c
+++ b/hw/acpi/memory_hotplug.c
@@ -720,10 +720,12 @@ void build_memory_hotplug_aml(Aml *table, uint32_t nr_mem,
 }
 aml_append(table, dev_container);
 
-method = aml_method(event_handler_method, 0, AML_NOTSERIALIZED);
-aml_append(method,
-aml_call0(MEMORY_DEVICES_CONTAINER "." MEMORY_SLOT_SCAN_METHOD));
-aml_append(table, method);
+if (event_handler_method) {
+method = aml_method(event_handler_method, 0, AML_NOTSERIALIZED);
+aml_append(method,
+   aml_call0(MEMORY_DEVICES_CONTAINER "." 
MEMORY_SLOT_SCAN_METHOD));
+aml_append(table, method);
+}
 
 g_free(mhp_res_path);
 }
-- 
2.7.4





[Qemu-devel] [PATCH v3 05/10] hw/arm/virt: Add ACPI support for device memory cold-plug

2019-03-21 Thread Shameer Kolothum
This adds support to build the aml code so that Guest(ACPI boot)
can see the cold-plugged device memory. Memory cold plug support
with DT boot is not yet enabled.

Signed-off-by: Shameer Kolothum 
---
 default-configs/arm-softmmu.mak|  2 ++
 hw/acpi/generic_event_device.c | 23 +++
 hw/arm/virt-acpi-build.c   |  9 +
 hw/arm/virt.c  | 23 +++
 include/hw/acpi/generic_event_device.h |  5 +
 include/hw/arm/virt.h  |  2 ++
 6 files changed, 64 insertions(+)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 795cb89..6db444e 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -162,3 +162,5 @@ CONFIG_LSI_SCSI_PCI=y
 
 CONFIG_MEM_DEVICE=y
 CONFIG_DIMM=y
+CONFIG_ACPI_MEMORY_HOTPLUG=y
+CONFIG_ACPI_HW_REDUCED=y
diff --git a/hw/acpi/generic_event_device.c b/hw/acpi/generic_event_device.c
index b21a551..0b32fc9 100644
--- a/hw/acpi/generic_event_device.c
+++ b/hw/acpi/generic_event_device.c
@@ -16,13 +16,26 @@
  */
 
 #include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "exec/address-spaces.h"
 #include "hw/sysbus.h"
 #include "hw/acpi/acpi.h"
 #include "hw/acpi/generic_event_device.h"
+#include "hw/mem/pc-dimm.h"
 
 static void virt_device_plug_cb(HotplugHandler *hotplug_dev,
 DeviceState *dev, Error **errp)
 {
+VirtAcpiState *s = VIRT_ACPI(hotplug_dev);
+
+if (s->memhp_state.is_enabled &&
+object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
+acpi_memory_plug_cb(hotplug_dev, &s->memhp_state,
+dev, errp);
+} else {
+error_setg(errp, "virt: device plug request for unsupported device"
+   " type: %s", object_get_typename(OBJECT(dev)));
+}
 }
 
 static void virt_send_ged(AcpiDeviceIf *adev, AcpiEventStatusBits ev)
@@ -31,9 +44,19 @@ static void virt_send_ged(AcpiDeviceIf *adev, 
AcpiEventStatusBits ev)
 
 static void virt_device_realize(DeviceState *dev, Error **errp)
 {
+VirtAcpiState *s = VIRT_ACPI(dev);
+
+if (s->memhp_state.is_enabled) {
+acpi_memory_hotplug_init(get_system_memory(), OBJECT(dev),
+ &s->memhp_state,
+ s->memhp_base);
+}
 }
 
 static Property virt_acpi_properties[] = {
+DEFINE_PROP_UINT64("memhp_base", VirtAcpiState, memhp_base, 0),
+DEFINE_PROP_BOOL("memory-hotplug-support", VirtAcpiState,
+ memhp_state.is_enabled, true),
 DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index bf9c0bc..20d3c83 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -40,6 +40,7 @@
 #include "hw/loader.h"
 #include "hw/hw.h"
 #include "hw/acpi/aml-build.h"
+#include "hw/acpi/memory_hotplug.h"
 #include "hw/pci/pcie_host.h"
 #include "hw/pci/pci.h"
 #include "hw/arm/virt.h"
@@ -49,6 +50,13 @@
 #define ARM_SPI_BASE 32
 #define ACPI_POWER_BUTTON_DEVICE "PWRB"
 
+static void acpi_dsdt_add_memory_hotplug(Aml *scope, MachineState *ms)
+{
+uint32_t nr_mem = ms->ram_slots;
+
+build_memory_hotplug_aml(scope, nr_mem, "\\_SB", NULL, AML_SYSTEM_MEMORY);
+}
+
 static void acpi_dsdt_add_cpus(Aml *scope, int smp_cpus)
 {
 uint16_t i;
@@ -740,6 +748,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, 
VirtMachineState *vms)
  * the RTC ACPI device at all when using UEFI.
  */
 scope = aml_scope("\\_SB");
+acpi_dsdt_add_memory_hotplug(scope, MACHINE(vms));
 acpi_dsdt_add_cpus(scope, vms->smp_cpus);
 acpi_dsdt_add_uart(scope, &memmap[VIRT_UART],
(irqmap[VIRT_UART] + ARM_SPI_BASE));
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index d0ff20d..13db0e9 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -133,6 +133,7 @@ static const MemMapEntry base_memmap[] = {
 [VIRT_GPIO] =   { 0x0903, 0x1000 },
 [VIRT_SECURE_UART] ={ 0x0904, 0x1000 },
 [VIRT_SMMU] =   { 0x0905, 0x0002 },
+[VIRT_PCDIMM_ACPI] ={ 0x0907, 0x0001 },
 [VIRT_MMIO] =   { 0x0a00, 0x0200 },
 /* ...repeating for a total of NUM_VIRTIO_TRANSPORTS, each of that size */
 [VIRT_PLATFORM_BUS] =   { 0x0c00, 0x0200 },
@@ -516,6 +517,18 @@ static void fdt_add_pmu_nodes(const VirtMachineState *vms)
 }
 }
 
+static DeviceState *create_virt_acpi(VirtMachineState *vms)
+{
+DeviceState *dev;
+
+dev = qdev_create(NULL, "virt-acpi");
+qdev_prop_set_uint64(dev, "memhp_base",
+ vms->memmap[VIRT_PCDIMM_ACPI].base);
+qdev_init_nofail(dev);
+
+return dev;
+}
+
 static void create_its(VirtMachineState *vms, DeviceState *gicdev)
 {
 const char *itsclass = its_class_name();
@@ -1644,6 +1657,8 @@ static void machvirt_init(MachineState *machine)
 
 create_platform_bus(vms, pic)

[Qemu-devel] [PATCH v3 01/10] hw/acpi: Make ACPI IO address space configurable

2019-03-21 Thread Shameer Kolothum
This is in preparation for adding support for ARM64 platforms
where it doesn't use port mapped IO for ACPI IO space.

Also move the MEMORY_SLOT_SCAN_METHOD/MEMORY_DEVICES_CONTAINER
definitions to header so that other memory hotplug event
signalling mechanisms (eg. Generic Event Device on HW-reduced
acpi platforms) can use the same from their respective event
handler aml code.

Signed-off-by: Shameer Kolothum 
Reviewed-by: Eric Auger 
---
 hw/acpi/memory_hotplug.c | 24 ++--
 hw/i386/acpi-build.c |  3 ++-
 include/hw/acpi/memory_hotplug.h |  8 ++--
 3 files changed, 22 insertions(+), 13 deletions(-)

diff --git a/hw/acpi/memory_hotplug.c b/hw/acpi/memory_hotplug.c
index 297812d..80e25f0 100644
--- a/hw/acpi/memory_hotplug.c
+++ b/hw/acpi/memory_hotplug.c
@@ -29,12 +29,10 @@
 #define MEMORY_SLOT_PROXIMITY_METHOD "MPXM"
 #define MEMORY_SLOT_EJECT_METHOD "MEJ0"
 #define MEMORY_SLOT_NOTIFY_METHOD"MTFY"
-#define MEMORY_SLOT_SCAN_METHOD  "MSCN"
 #define MEMORY_HOTPLUG_DEVICE"MHPD"
 #define MEMORY_HOTPLUG_IO_LEN 24
-#define MEMORY_DEVICES_CONTAINER "\\_SB.MHPC"
 
-static uint16_t memhp_io_base;
+static hwaddr memhp_io_base;
 
 static ACPIOSTInfo *acpi_memory_device_status(int slot, MemStatus *mdev)
 {
@@ -209,7 +207,7 @@ static const MemoryRegionOps acpi_memory_hotplug_ops = {
 };
 
 void acpi_memory_hotplug_init(MemoryRegion *as, Object *owner,
-  MemHotplugState *state, uint16_t io_base)
+  MemHotplugState *state, hwaddr io_base)
 {
 MachineState *machine = MACHINE(qdev_get_machine());
 
@@ -342,7 +340,8 @@ const VMStateDescription vmstate_memory_hotplug = {
 
 void build_memory_hotplug_aml(Aml *table, uint32_t nr_mem,
   const char *res_root,
-  const char *event_handler_method)
+  const char *event_handler_method,
+  AmlRegionSpace rs)
 {
 int i;
 Aml *ifctx;
@@ -365,14 +364,19 @@ void build_memory_hotplug_aml(Aml *table, uint32_t nr_mem,
 aml_name_decl("_UID", aml_string("Memory hotplug resources")));
 
 crs = aml_resource_template();
-aml_append(crs,
-aml_io(AML_DECODE16, memhp_io_base, memhp_io_base, 0,
-   MEMORY_HOTPLUG_IO_LEN)
-);
+if (rs == AML_SYSTEM_IO) {
+aml_append(crs,
+aml_io(AML_DECODE16, memhp_io_base, memhp_io_base, 0,
+   MEMORY_HOTPLUG_IO_LEN)
+);
+} else {
+aml_append(crs, aml_memory32_fixed(memhp_io_base,
+MEMORY_HOTPLUG_IO_LEN, AML_READ_WRITE));
+}
 aml_append(mem_ctrl_dev, aml_name_decl("_CRS", crs));
 
 aml_append(mem_ctrl_dev, aml_operation_region(
-MEMORY_HOTPLUG_IO_REGION, AML_SYSTEM_IO,
+MEMORY_HOTPLUG_IO_REGION, rs,
 aml_int(memhp_io_base), MEMORY_HOTPLUG_IO_LEN)
 );
 
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 416da31..6d6de44 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -1852,7 +1852,8 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 build_cpus_aml(dsdt, machine, opts, pm->cpu_hp_io_base,
"\\_SB.PCI0", "\\_GPE._E02");
 }
-build_memory_hotplug_aml(dsdt, nr_mem, "\\_SB.PCI0", "\\_GPE._E03");
+build_memory_hotplug_aml(dsdt, nr_mem, "\\_SB.PCI0",
+ "\\_GPE._E03", AML_SYSTEM_IO);
 
 scope =  aml_scope("_GPE");
 {
diff --git a/include/hw/acpi/memory_hotplug.h b/include/hw/acpi/memory_hotplug.h
index 77c6576..f95aa1f 100644
--- a/include/hw/acpi/memory_hotplug.h
+++ b/include/hw/acpi/memory_hotplug.h
@@ -5,6 +5,9 @@
 #include "hw/acpi/acpi.h"
 #include "hw/acpi/aml-build.h"
 
+#define MEMORY_SLOT_SCAN_METHOD  "MSCN"
+#define MEMORY_DEVICES_CONTAINER "\\_SB.MHPC"
+
 /**
  * MemStatus:
  * @is_removing: the memory device in slot has been requested to be ejected.
@@ -29,7 +32,7 @@ typedef struct MemHotplugState {
 } MemHotplugState;
 
 void acpi_memory_hotplug_init(MemoryRegion *as, Object *owner,
-  MemHotplugState *state, uint16_t io_base);
+  MemHotplugState *state, hwaddr io_base);
 
 void acpi_memory_plug_cb(HotplugHandler *hotplug_dev, MemHotplugState *mem_st,
  DeviceState *dev, Error **errp);
@@ -48,5 +51,6 @@ void acpi_memory_ospm_status(MemHotplugState *mem_st, 
ACPIOSTInfoList ***list);
 
 void build_memory_hotplug_aml(Aml *table, uint32_t nr_mem,
   const char *res_root,
-  const char *event_handler_method);
+  const char *event_handler_method,
+  AmlRegionSpace rs);
 #endif
-- 
2.7.4





Re: [Qemu-devel] [PULL 0/1] qio next patches

2019-03-21 Thread Peter Maydell
On Wed, 20 Mar 2019 at 16:58, Daniel P. Berrangé  wrote:
>
> The following changes since commit 62a172e6a77d9072bb1a18f295ce0fcf4b90a4f2:
>
>   Update version for v4.0.0-rc0 release (2019-03-19 17:17:22 +)
>
> are available in the Git repository at:
>
>   https://github.com/berrange/qemu tags/qio-next-pull-request
>
> for you to fetch changes up to dd154c4d9f48a44ad24e13f46033d0f10a05c923:
>
>   io: fix handling of EOF / error conditions in websock GSource (2019-03-20 
> 16:56:30 +)
>
> 
> Merge I/O patch queue
>
> Fix problem with end of file handling with websock channels
>
> 
>
> Daniel P. Berrangé (1):
>   io: fix handling of EOF / error conditions in websock GSource
>
>  io/channel-websock.c | 8 +++-

Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.0
for any user-visible changes.

-- PMM



[Qemu-devel] [PATCH v3 07/10] hw/arm/virt: Introduce opt-in feature "fdt"

2019-03-21 Thread Shameer Kolothum
This is to disable/enable populating DT nodes in case
any conflict with acpi tables. The default is "off".

This will be used in subsequent patch where cold plug
device-memory support is added for DT boot.

If DT memory node support is added for cold-plugged device
memory, those memory will be visible to Guest kernel via
UEFI GetMemoryMap() and gets treated as early boot memory.
Hence memory becomes non hot-un-unpluggable even if Guest
is booted in ACPI mode.

Signed-off-by: Shameer Kolothum 
---
 hw/arm/virt.c | 23 +++
 include/hw/arm/virt.h |  1 +
 2 files changed, 24 insertions(+)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 13db0e9..b602151 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1717,6 +1717,20 @@ static void virt_set_highmem(Object *obj, bool value, 
Error **errp)
 vms->highmem = value;
 }
 
+static bool virt_get_fdt(Object *obj, Error **errp)
+{
+VirtMachineState *vms = VIRT_MACHINE(obj);
+
+return vms->use_fdt;
+}
+
+static void virt_set_fdt(Object *obj, bool value, Error **errp)
+{
+VirtMachineState *vms = VIRT_MACHINE(obj);
+
+vms->use_fdt = value;
+}
+
 static bool virt_get_its(Object *obj, Error **errp)
 {
 VirtMachineState *vms = VIRT_MACHINE(obj);
@@ -2005,6 +2019,15 @@ static void virt_instance_init(Object *obj)
 object_property_set_description(obj, "gic-version",
 "Set GIC version. "
 "Valid values are 2, 3 and host", NULL);
+/* fdt is disabled by default */
+vms->use_fdt = false;
+object_property_add_bool(obj, "fdt", virt_get_fdt,
+ virt_set_fdt, NULL);
+object_property_set_description(obj, "fdt",
+"Set on/off to enable/disable device tree "
+"nodes in case any conflict with ACPI"
+"(eg: device memory node)",
+NULL);
 
 vms->highmem_ecam = !vmc->no_highmem_ecam;
 
diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
index c5e4c96..14b2e0a 100644
--- a/include/hw/arm/virt.h
+++ b/include/hw/arm/virt.h
@@ -119,6 +119,7 @@ typedef struct {
 bool highmem_ecam;
 bool its;
 bool virt;
+bool use_fdt;
 int32_t gic_version;
 VirtIOMMUType iommu;
 struct arm_boot_info bootinfo;
-- 
2.7.4





Re: [Qemu-devel] [PATCH] qemu-pr-helper: check the return value of fcntl in do_pr_out

2019-03-21 Thread Paolo Bonzini
On 20/03/19 15:07, Zhengui li wrote:
> The function fcntl maybe return -1, which is not a unsigned type.
> Unsigned type or Negative values should not do bitwise operator with
> O_ACCMODE.

Did you actually find a case in which the fcntl can fail?

Paolo

> Signed-off-by: Zhengui li 
> ---
>  scsi/qemu-pr-helper.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/scsi/qemu-pr-helper.c b/scsi/qemu-pr-helper.c
> index e7af637..fcbe4d9 100644
> --- a/scsi/qemu-pr-helper.c
> +++ b/scsi/qemu-pr-helper.c
> @@ -551,8 +551,14 @@ static int do_pr_out(int fd, const uint8_t *cdb, uint8_t 
> *sense,
>   const uint8_t *param, int sz)
>  {
>  int resp_sz;
> +int flags;
>  
> -if ((fcntl(fd, F_GETFL) & O_ACCMODE) == O_RDONLY) {
> +flags = fcntl(fd, F_GETFL);
> +if (flags < 0) {
> +return -1;
> +}
> +
> +if (((unsigned int) flags & O_ACCMODE) == O_RDONLY) {
>  scsi_build_sense(sense, SENSE_CODE(INVALID_OPCODE));
>  return CHECK_CONDITION;
>  }
> 




[Qemu-devel] [PATCH v3 00/10] ARM virt: ACPI memory hotplug support

2019-03-21 Thread Shameer Kolothum
This series is an attempt to provide device memory hotplug support 
on ARM virt platform. This is based on Eric's recent works here[1]
and carries some of the pc-dimm related patches dropped from his
series.

The kernel support for arm64 memory hot add was added recently by
Robin and hence the guest kernel should be => 5.0-rc1.

NVDIM support is not included currently as we still have an unresolved
issue while hot adding NVDIMM[2]. However NVDIMM cold plug patches
can be included, but not done for now, for keeping it simple.

This makes use of GED device to sent hotplug ACPI events to the
Guest. GED code is based on Nemu. Thanks to the efforts of Samuel and
Sebastien to add the hardware-reduced support to Nemu using GED
device[3]. (Please shout if I got the author/signed-off wrong for
those patches or missed any names).

Thanks,
Shameer

[1] https://patchwork.kernel.org/cover/10837565/
[2] https://patchwork.kernel.org/cover/10783589/
[3] https://github.com/intel/nemu/blob/topic/virt-x86/hw/acpi/ged.c

v2 --> v2

Addressed comments from Igor and Eric,
-Made virt acpi device platform independent and moved
 to hw/acpi/generic_event_device.c
-Moved ged specific code into hw/acpi/generic_event_device.c
-Introduced an opt-in feature "fdt" to resolve device-memory being
 treated as early boot memory.
-Dropped patch #1 from v2.

RFC --> v2

-Use GED device instead of GPIO for ACPI hotplug events.
-Removed NVDIMM support for now.
-Includes dropped patches from Eric's v9 series.

Eric Auger (1):
  hw/arm/virt: Add memory hotplug framework

Samuel Ortiz (3):
  hw/acpi: Do not create memory hotplug method when handler is not
defined
  hw/arm/virt: Add virtual ACPI device
  hw/acpi: Add ACPI Generic Event Device Support

Shameer Kolothum (6):
  hw/acpi: Make ACPI IO address space configurable
  hw/arm/virt: Add ACPI support for device memory cold-plug
  hw/arm/virt-acpi-build: Add PC-DIMM in SRAT
  hw/arm/virt: Introduce opt-in feature "fdt"
  hw/arm/boot: Expose the PC-DIMM nodes in the DT
  hw/arm/virt: Init GED device and enable memory hotplug

 default-configs/arm-softmmu.mak|   5 +
 hw/acpi/Kconfig|   4 +
 hw/acpi/Makefile.objs  |   1 +
 hw/acpi/generic_event_device.c | 313 +
 hw/acpi/memory_hotplug.c   |  34 ++--
 hw/arm/boot.c  |  44 +
 hw/arm/virt-acpi-build.c   |  27 +++
 hw/arm/virt.c  | 121 -
 hw/i386/acpi-build.c   |   3 +-
 include/hw/acpi/generic_event_device.h |  68 +++
 include/hw/acpi/memory_hotplug.h   |   8 +-
 include/hw/arm/virt.h  |   5 +
 12 files changed, 614 insertions(+), 19 deletions(-)
 create mode 100644 hw/acpi/generic_event_device.c
 create mode 100644 include/hw/acpi/generic_event_device.h

-- 
2.7.4





[Qemu-devel] [PATCH v3 03/10] hw/arm/virt: Add virtual ACPI device

2019-03-21 Thread Shameer Kolothum
From: Samuel Ortiz 

This adds the skeleton to support an acpi device interface
for HW-reduced acpi platforms via ACPI GED - Generic Event
Device (ACPI v6.1 5.6.9).

This will be used by Arm/Virt to add hotplug support.

Signed-off-by: Samuel Ortiz 
Signed-off-by: Shameer Kolothum 
---
 hw/acpi/Kconfig|  4 ++
 hw/acpi/Makefile.objs  |  1 +
 hw/acpi/generic_event_device.c | 72 ++
 include/hw/acpi/generic_event_device.h | 29 ++
 4 files changed, 106 insertions(+)
 create mode 100644 hw/acpi/generic_event_device.c
 create mode 100644 include/hw/acpi/generic_event_device.h

diff --git a/hw/acpi/Kconfig b/hw/acpi/Kconfig
index eca3bee..01a8b41 100644
--- a/hw/acpi/Kconfig
+++ b/hw/acpi/Kconfig
@@ -27,3 +27,7 @@ config ACPI_VMGENID
 bool
 default y
 depends on PC
+
+config ACPI_HW_REDUCED
+bool
+depends on ACPI
diff --git a/hw/acpi/Makefile.objs b/hw/acpi/Makefile.objs
index 2d46e37..b753232 100644
--- a/hw/acpi/Makefile.objs
+++ b/hw/acpi/Makefile.objs
@@ -6,6 +6,7 @@ common-obj-$(CONFIG_ACPI_MEMORY_HOTPLUG) += memory_hotplug.o
 common-obj-$(CONFIG_ACPI_CPU_HOTPLUG) += cpu.o
 common-obj-$(CONFIG_ACPI_NVDIMM) += nvdimm.o
 common-obj-$(CONFIG_ACPI_VMGENID) += vmgenid.o
+common-obj-$(CONFIG_ACPI_HW_REDUCED) += generic_event_device.o
 common-obj-$(call lnot,$(CONFIG_ACPI_X86)) += acpi-stub.o
 
 common-obj-y += acpi_interface.o
diff --git a/hw/acpi/generic_event_device.c b/hw/acpi/generic_event_device.c
new file mode 100644
index 000..b21a551
--- /dev/null
+++ b/hw/acpi/generic_event_device.c
@@ -0,0 +1,72 @@
+/*
+ *
+ * Copyright (c) 2018 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2 or later, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "hw/sysbus.h"
+#include "hw/acpi/acpi.h"
+#include "hw/acpi/generic_event_device.h"
+
+static void virt_device_plug_cb(HotplugHandler *hotplug_dev,
+DeviceState *dev, Error **errp)
+{
+}
+
+static void virt_send_ged(AcpiDeviceIf *adev, AcpiEventStatusBits ev)
+{
+}
+
+static void virt_device_realize(DeviceState *dev, Error **errp)
+{
+}
+
+static Property virt_acpi_properties[] = {
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void virt_acpi_class_init(ObjectClass *class, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(class);
+HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(class);
+AcpiDeviceIfClass *adevc = ACPI_DEVICE_IF_CLASS(class);
+
+dc->desc = "ACPI";
+dc->props = virt_acpi_properties;
+dc->realize = virt_device_realize;
+
+hc->plug = virt_device_plug_cb;
+
+adevc->send_event = virt_send_ged;
+}
+
+static const TypeInfo virt_acpi_info = {
+.name  = TYPE_VIRT_ACPI,
+.parent= TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(VirtAcpiState),
+.class_init= virt_acpi_class_init,
+.interfaces = (InterfaceInfo[]) {
+{ TYPE_HOTPLUG_HANDLER },
+{ TYPE_ACPI_DEVICE_IF },
+{ }
+}
+};
+
+static void virt_acpi_register_types(void)
+{
+type_register_static(&virt_acpi_info);
+}
+
+type_init(virt_acpi_register_types)
diff --git a/include/hw/acpi/generic_event_device.h 
b/include/hw/acpi/generic_event_device.h
new file mode 100644
index 000..f314515
--- /dev/null
+++ b/include/hw/acpi/generic_event_device.h
@@ -0,0 +1,29 @@
+/*
+ *
+ * Copyright (c) 2018 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2 or later, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#ifndef HW_ACPI_GED_H
+#define HW_ACPI_GED_H
+
+#define TYPE_VIRT_ACPI "virt-acpi"
+#define VIRT_ACPI(obj) \
+OBJECT_CHECK(VirtAcpiState, (obj), TYPE_VIRT_ACPI)
+
+typedef struct VirtAcpiState {
+SysBusDevice parent_obj;
+} VirtAcpiState;
+
+#endif
-- 
2.7.4





Re: [Qemu-devel] [PATCH 1/2] iotests: 030 TestParallelOps non-shared base node

2019-03-21 Thread Kevin Wolf
Am 20.03.2019 um 18:02 hat Alberto Garcia geschrieben:
> On Wed 20 Mar 2019 10:16:10 AM CET, Kevin Wolf wrote:
> >> Oh, I see. Let's use a shorter chain for simplicity:
> >> 
> >>A <- B <- C <- D <- E
> >
> > Written from right to left, i.e. E being the base and A the top layer?
> > We usually write things the other write round, I hope this doesn't get
> > too confusing later.
> 
> Oh my... yes, of course you're right, I should have written it the other
> way around:
> 
>E <- D <- C <- B <- A
> 
> >> 1) If we stream first from E to C we add a filter F:
> >> 
> >>A <- B <- F <- C <- D <- E
> 
> ( which should have been written   E <- D <- C <- F <- B <- A )
> 
> >>Now we can't stream from C to A because F is on the way, and the F-C
> >>link is frozen.
> >
> > Why is a frozen link a problem? The streaming operation isn't going to
> > change this link, it just copies data from the subchain (including F
> > and C) to A. This is not something that a frozen link should prevent.
> 
> Not the operation itself, but the first thing that block-stream does is
> freeze the chain from top (A) to base (C), so this would fail if there's
> already a frozen link on the way (C <- F on this case?).

Oh, I see. I think this is why I suggested a counter originally instead
of a bool.

> > So it seems frozen links allow the wrong case, but block the correct
> > one? :-(
> 
> Yes, we probably need to rethink this scenario a bit.

But yes, even with a counter, the other problem would still remain (that
the first job can't remove the filter on completion because the second
one has frozen its link to the filter).

I don't think that's a case we want to just forbid because nobody needs
this anyway. It's a sign of a more fundamental problem in our design,
and I'm sure it will bite us in other places, too.

Kevin



[Qemu-devel] [PATCH v3 04/10] hw/arm/virt: Add memory hotplug framework

2019-03-21 Thread Shameer Kolothum
From: Eric Auger 

This patch adds the the memory hot-plug/hot-unplug infrastructure
in machvirt. It is still not enabled as device memory is not yet
reported to guest.

Signed-off-by: Eric Auger 
Signed-off-by: Kwangwoo Lee 
Signed-off-by: Shameer Kolothum 
---
 default-configs/arm-softmmu.mak |  3 +++
 hw/arm/virt.c   | 53 -
 2 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 2a7efc1..795cb89 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -159,3 +159,6 @@ CONFIG_MUSICPAL=y
 
 # for realview and versatilepb
 CONFIG_LSI_SCSI_PCI=y
+
+CONFIG_MEM_DEVICE=y
+CONFIG_DIMM=y
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index ce2664a..d0ff20d 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -61,6 +61,8 @@
 #include "hw/arm/smmuv3.h"
 #include "hw/acpi/acpi.h"
 #include "target/arm/internals.h"
+#include "hw/mem/pc-dimm.h"
+#include "hw/mem/nvdimm.h"
 
 #define DEFINE_VIRT_MACHINE_LATEST(major, minor, latest) \
 static void virt_##major##_##minor##_class_init(ObjectClass *oc, \
@@ -1806,6 +1808,42 @@ static const CPUArchIdList 
*virt_possible_cpu_arch_ids(MachineState *ms)
 return ms->possible_cpus;
 }
 
+static void virt_memory_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
+ Error **errp)
+{
+const bool is_nvdimm = object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM);
+
+if (dev->hotplugged) {
+error_setg(errp, "memory hotplug is not supported");
+}
+
+if (is_nvdimm) {
+error_setg(errp, "nvdimm is not yet supported");
+return;
+}
+
+pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev), NULL, errp);
+}
+
+static void virt_memory_plug(HotplugHandler *hotplug_dev,
+ DeviceState *dev, Error **errp)
+{
+VirtMachineState *vms = VIRT_MACHINE(hotplug_dev);
+Error *local_err = NULL;
+
+pc_dimm_plug(PC_DIMM(dev), MACHINE(vms), &local_err);
+
+error_propagate(errp, local_err);
+}
+
+static void virt_machine_device_pre_plug_cb(HotplugHandler *hotplug_dev,
+DeviceState *dev, Error **errp)
+{
+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
+virt_memory_pre_plug(hotplug_dev, dev, errp);
+}
+}
+
 static void virt_machine_device_plug_cb(HotplugHandler *hotplug_dev,
 DeviceState *dev, Error **errp)
 {
@@ -1817,12 +1855,23 @@ static void virt_machine_device_plug_cb(HotplugHandler 
*hotplug_dev,
  SYS_BUS_DEVICE(dev));
 }
 }
+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
+virt_memory_plug(hotplug_dev, dev, errp);
+}
+}
+
+static void virt_machine_device_unplug_request_cb(HotplugHandler *hotplug_dev,
+  DeviceState *dev, Error **errp)
+{
+error_setg(errp, "device unplug request for unsupported device"
+   " type: %s", object_get_typename(OBJECT(dev)));
 }
 
 static HotplugHandler *virt_machine_get_hotplug_handler(MachineState *machine,
 DeviceState *dev)
 {
-if (object_dynamic_cast(OBJECT(dev), TYPE_SYS_BUS_DEVICE)) {
+if (object_dynamic_cast(OBJECT(dev), TYPE_SYS_BUS_DEVICE) ||
+   (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM))) {
 return HOTPLUG_HANDLER(machine);
 }
 
@@ -1886,7 +1935,9 @@ static void virt_machine_class_init(ObjectClass *oc, void 
*data)
 mc->kvm_type = virt_kvm_type;
 assert(!mc->get_hotplug_handler);
 mc->get_hotplug_handler = virt_machine_get_hotplug_handler;
+hc->pre_plug = virt_machine_device_pre_plug_cb;
 hc->plug = virt_machine_device_plug_cb;
+hc->unplug_request = virt_machine_device_unplug_request_cb;
 }
 
 static void virt_instance_init(Object *obj)
-- 
2.7.4





Re: [Qemu-devel] [PATCH v3 00/10] ARM virt: ACPI memory hotplug support

2019-03-21 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/20190321104745.28068-1-shameerali.kolothum.th...@huawei.com/



Hi,

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

Message-id: 20190321104745.28068-1-shameerali.kolothum.th...@huawei.com
Subject: [Qemu-devel] [PATCH v3 00/10] ARM virt: ACPI memory hotplug support
Type: series

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
   62a172e6a7..6532dcebb6  master -> master
 t [tag update]
patchew/1553090847-11300-1-git-send-email-lizhen...@huawei.com -> 
patchew/1553090847-11300-1-git-send-email-lizhen...@huawei.com
 t [tag update]patchew/20190313162812.8885-1-arm...@redhat.com -> 
patchew/20190313162812.8885-1-arm...@redhat.com
 t [tag update]
patchew/20190314131049.23175-1-marcandre.lur...@redhat.com -> 
patchew/20190314131049.23175-1-marcandre.lur...@redhat.com
 t [tag update]patchew/20190319163551.32499-1-arm...@redhat.com -> 
patchew/20190319163551.32499-1-arm...@redhat.com
 * [new tag]   patchew/20190321085212.10796-1-lviv...@redhat.com -> 
patchew/20190321085212.10796-1-lviv...@redhat.com
 * [new tag]   patchew/20190321094012.36541-1-sgarz...@redhat.com 
-> patchew/20190321094012.36541-1-sgarz...@redhat.com
 * [new tag]   
patchew/20190321104745.28068-1-shameerali.kolothum.th...@huawei.com -> 
patchew/20190321104745.28068-1-shameerali.kolothum.th...@huawei.com
Switched to a new branch 'test'
125f46770b hw/arm/virt: Init GED device and enable memory hotplug
8b3a542021 hw/acpi: Add ACPI Generic Event Device Support
bbb60b29a5 hw/arm/boot: Expose the PC-DIMM nodes in the DT
8617e42573 hw/arm/virt: Introduce opt-in feature "fdt"
9cd5da671c hw/arm/virt-acpi-build: Add PC-DIMM in SRAT
b25387b9d3 hw/arm/virt: Add ACPI support for device memory cold-plug
ab6d232c4d hw/arm/virt: Add memory hotplug framework
ea71a92426 hw/arm/virt: Add virtual ACPI device
f093e1aaf2 hw/acpi: Do not create memory hotplug method when handler is not 
defined
37eb6a4ab4 hw/acpi: Make ACPI IO address space configurable

=== OUTPUT BEGIN ===
1/10 Checking commit 37eb6a4ab493 (hw/acpi: Make ACPI IO address space 
configurable)
2/10 Checking commit f093e1aaf21d (hw/acpi: Do not create memory hotplug method 
when handler is not defined)
WARNING: line over 80 characters
#31: FILE: hw/acpi/memory_hotplug.c:726:
+   aml_call0(MEMORY_DEVICES_CONTAINER "." 
MEMORY_SLOT_SCAN_METHOD));

total: 0 errors, 1 warnings, 16 lines checked

Patch 2/10 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
3/10 Checking commit ea71a92426cc (hw/arm/virt: Add virtual ACPI device)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#42: 
new file mode 100644

total: 0 errors, 1 warnings, 115 lines checked

Patch 3/10 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
4/10 Checking commit ab6d232c4d16 (hw/arm/virt: Add memory hotplug framework)
5/10 Checking commit b25387b9d3e5 (hw/arm/virt: Add ACPI support for device 
memory cold-plug)
6/10 Checking commit 9cd5da671c49 (hw/arm/virt-acpi-build: Add PC-DIMM in SRAT)
7/10 Checking commit 8617e4257385 (hw/arm/virt: Introduce opt-in feature "fdt")
8/10 Checking commit bbb60b29a575 (hw/arm/boot: Expose the PC-DIMM nodes in the 
DT)
9/10 Checking commit 8b3a54202156 (hw/acpi: Add ACPI Generic Event Device 
Support)
ERROR: line over 90 characters
#124: FILE: hw/acpi/generic_event_device.c:117:
+if_ctx = aml_if(aml_equal(aml_and(irq_sel, 
aml_int(ged_events[i].selector), NULL), aml_int(ged_events[i].selector)));

total: 1 errors, 0 warnings, 269 lines checked

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

10/10 Checking commit 125f46770b37 (hw/arm/virt: Init GED device and enable 
memory hotplug)
=== OUTPUT END ===

Test command exited with code: 1


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

[Qemu-devel] [PATCH for-4.1 v3 09/12] pc-bios: document the edk2 firmware images; add firmware descriptors

2019-03-21 Thread Laszlo Ersek
Update the README file with information on the images added previously,
and provide firmware descriptor documents that conform to
"docs/interop/firmware.json".

Signed-off-by: Laszlo Ersek 
Reviewed-by: Michal Privoznik 
Reviewed-by: Michael S. Tsirkin 
Tested-by: Igor Mammedov 
---

Notes:
v3:

- refer to "edk2-*.fd.bz2" rather than "edk2-*.fd.xz" in the README
  [Peter]

- pick up Igor's T-b still

v2:

- refer to "edk2-*.fd.xz" rather than "edk2-*.fd" in the README hunk
  [Dan, Michael, Phil]

- pick up Michal's and Michael's R-b's

 pc-bios/descriptors/50-edk2-i386-secure.json   | 34 +++
 pc-bios/descriptors/50-edk2-x86_64-secure.json | 35 
 pc-bios/descriptors/60-edk2-aarch64.json   | 31 +
 pc-bios/descriptors/60-edk2-arm.json   | 31 +
 pc-bios/descriptors/60-edk2-i386.json  | 33 ++
 pc-bios/descriptors/60-edk2-x86_64.json| 34 +++
 pc-bios/README | 11 ++
 7 files changed, 209 insertions(+)

diff --git a/pc-bios/descriptors/50-edk2-i386-secure.json 
b/pc-bios/descriptors/50-edk2-i386-secure.json
new file mode 100644
index ..d7108c1da05a
--- /dev/null
+++ b/pc-bios/descriptors/50-edk2-i386-secure.json
@@ -0,0 +1,34 @@
+{
+"description": "UEFI firmware for i386, with Secure Boot and SMM",
+"interface-types": [
+"uefi"
+],
+"mapping": {
+"device": "flash",
+"executable": {
+"filename": "@DATADIR@/edk2-i386-secure-code.fd",
+"format": "raw"
+},
+"nvram-template": {
+"filename": "@DATADIR@/edk2-i386-vars.fd",
+"format": "raw"
+}
+},
+"targets": [
+{
+"architecture": "i386",
+"machines": [
+"pc-q35-*"
+]
+}
+],
+"features": [
+"acpi-s3",
+"requires-smm",
+"secure-boot",
+"verbose-dynamic"
+],
+"tags": [
+
+]
+}
diff --git a/pc-bios/descriptors/50-edk2-x86_64-secure.json 
b/pc-bios/descriptors/50-edk2-x86_64-secure.json
new file mode 100644
index ..387eb356236b
--- /dev/null
+++ b/pc-bios/descriptors/50-edk2-x86_64-secure.json
@@ -0,0 +1,35 @@
+{
+"description": "UEFI firmware for x86_64, with Secure Boot and SMM",
+"interface-types": [
+"uefi"
+],
+"mapping": {
+"device": "flash",
+"executable": {
+"filename": "@DATADIR@/edk2-x86_64-secure-code.fd",
+"format": "raw"
+},
+"nvram-template": {
+"filename": "@DATADIR@/edk2-i386-vars.fd",
+"format": "raw"
+}
+},
+"targets": [
+{
+"architecture": "x86_64",
+"machines": [
+"pc-q35-*"
+]
+}
+],
+"features": [
+"acpi-s3",
+"amd-sev",
+"requires-smm",
+"secure-boot",
+"verbose-dynamic"
+],
+"tags": [
+
+]
+}
diff --git a/pc-bios/descriptors/60-edk2-aarch64.json 
b/pc-bios/descriptors/60-edk2-aarch64.json
new file mode 100644
index ..800a21bda691
--- /dev/null
+++ b/pc-bios/descriptors/60-edk2-aarch64.json
@@ -0,0 +1,31 @@
+{
+"description": "UEFI firmware for aarch64",
+"interface-types": [
+"uefi"
+],
+"mapping": {
+"device": "flash",
+"executable": {
+"filename": "@DATADIR@/edk2-aarch64-code.fd",
+"format": "raw"
+},
+"nvram-template": {
+"filename": "@DATADIR@/edk2-arm-vars.fd",
+"format": "raw"
+}
+},
+"targets": [
+{
+"architecture": "aarch64",
+"machines": [
+"virt-*"
+]
+}
+],
+"features": [
+"verbose-static"
+],
+"tags": [
+
+]
+}
diff --git a/pc-bios/descriptors/60-edk2-arm.json 
b/pc-bios/descriptors/60-edk2-arm.json
new file mode 100644
index ..d5f1bba6cc82
--- /dev/null
+++ b/pc-bios/descriptors/60-edk2-arm.json
@@ -0,0 +1,31 @@
+{
+"description": "UEFI firmware for arm",
+"interface-types": [
+"uefi"
+],
+"mapping": {
+"device": "flash",
+"executable": {
+"filename": "@DATADIR@/edk2-arm-code.fd",
+"format": "raw"
+},
+"nvram-template": {
+"filename": "@DATADIR@/edk2-arm-vars.fd",
+"format": "raw"
+}
+},
+"targets": [
+{
+"architecture": "arm",
+"machines": [
+"virt-*"
+]
+}
+],
+"features": [
+"verbose-static"
+],
+"tags": [
+
+]
+}
diff --git a/pc-bios/descriptors/60-edk2-i386.json 
b/pc-bios/descriptors/60-edk2-i386.json
new file mode 100644
index ..2f8dec74fecb
--- /dev/null
+++ 

[Qemu-devel] [PATCH for-4.1 v3 12/12] MAINTAINERS: add the "EDK2 Firmware" subsystem

2019-03-21 Thread Laszlo Ersek
We now have the edk2 submodule, somewhat elaborate build helpers for it,
and even a UEFI application written against edk2 whose genuine home is the
QEMU repository. Add the "EDK2 Firmware" subsystem such that all relevant
pathnames be covered.

Suggested-by: Daniel P. Berrangé 
Suggested-by: Michael S. Tsirkin 
Suggested-by: Philippe Mathieu-Daudé 
Signed-off-by: Laszlo Ersek 
Reviewed-by: Michal Privoznik 
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 
Tested-by: Igor Mammedov 
Reviewed-by: Michael S. Tsirkin 
---

Notes:
v3:

- pick up Michal's R-b

- pick up Phil's R-b/T-b

- pick up Igor's T-b

- pick up Michael's R-b

v2:

- new patch [Dan, Michael, Phil]

- compared to the suggestions, upgrade the maintenance status ("S") from
  Maintained to Supported

 MAINTAINERS | 12 
 1 file changed, 12 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 85d7d764e526..f7504bb9cc51 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2221,6 +2221,18 @@ F: include/hw/i2c/smbus_master.h
 F: include/hw/i2c/smbus_slave.h
 F: include/hw/i2c/smbus_eeprom.h
 
+EDK2 Firmware
+M: Laszlo Ersek 
+M: Philippe Mathieu-Daudé 
+S: Supported
+F: pc-bios/descriptors/??-edk2-*.json
+F: pc-bios/edk2-*
+F: roms/Makefile.edk2
+F: roms/edk2
+F: roms/edk2-*
+F: tests/data/uefi-boot-images/
+F: tests/uefi-test-tools/
+
 Usermode Emulation
 --
 Overall
-- 
2.19.1.3.g30247aa5d201




[Qemu-devel] [PATCH for-4.1 v3 10/12] tests: add missing dependency to build QTEST_QEMU_BINARY, round 2

2019-03-21 Thread Laszlo Ersek
In commit b94b330e2333 ("tests: add missing dependency to build
QTEST_QEMU_BINARY", 2017-07-31), Phil fixed the dependency list of make
target "check-qtest-%". Namely, the recipe would set QTEST_QEMU_BINARY to
the softmmu emulator for the emulation target, but the prerequisites
didn't include the emulator.

The same issue affects the "check-report-qtest-%.tap" make target, which
is the other make target whose recipe sets QTEST_QEMU_BINARY:

> $ make -j4 check-report-qtest-aarch64.tap
>   TAP check-report-qtest-aarch64.tap
> sh: /.../aarch64-softmmu/qemu-system-aarch64: No such file or directory

Apply Phil's fix to this make target too.

Signed-off-by: Laszlo Ersek 
Reviewed-by: Michal Privoznik 
Tested-by: Igor Mammedov 
Reviewed-by: Michael S. Tsirkin 
---

Notes:
v3:

- pick up Michal's R-b

- pick up Igor's T-b

- pick up Michael's R-b

v2:

- new patch, relied upon by the next patch

 tests/Makefile.include | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/Makefile.include b/tests/Makefile.include
index 852f17b8c79c..0a0e1c340fe2 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -915,7 +915,7 @@ check-speed: $(check-speed-y)
 
 # gtester tests with TAP output
 
-$(patsubst %, check-report-qtest-%.tap, $(QTEST_TARGETS)): 
check-report-qtest-%.tap: $(check-qtest-y)
+$(patsubst %, check-report-qtest-%.tap, $(QTEST_TARGETS)): 
check-report-qtest-%.tap: subdir-%-softmmu $(check-qtest-y)
$(call do_test_tap, $(check-qtest-$*-y) $(check-qtest-generic-y), \
  QTEST_QEMU_BINARY=$*-softmmu/qemu-system-$* \
  QTEST_QEMU_IMG=qemu-img$(EXESUF))
-- 
2.19.1.3.g30247aa5d201





[Qemu-devel] [PATCH for-4.1 v3 07/12] roms: build edk2 firmware binaries and variable store templates

2019-03-21 Thread Laszlo Ersek
Add the "efi" target to "Makefile".

Introduce "Makefile.edk2" for building and cleaning the firmware images
and varstore templates.

Collect the common bits from the recipes in the helper script
"edk2-build.sh".

Signed-off-by: Laszlo Ersek 
Reviewed-by: Michal Privoznik 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Michael S. Tsirkin 
---

Notes:
v3:

- pick up Michal's R-b

- pick up Phil's R-b

- pick up Michael's R-b

- compress FD files with bzip2 rather than xz, so that decompression at
  "make install" time succeed on older build OSes too [Peter]

- do not pick up Phil's T-b, consequently

- do not pick up Igor's T-b for the same reason

v2:

- drop comma after copyright year, in both new files [Eric]

- define the SHELL macro as /bin/bash near the top of "Makefile.edk2",
  so that various bashisms (e.g. the "source" built-in, and the ==
  operator of "[") work even if /bin/sh isn't bash [Phil, Eric]

- rework "Makefile.edk2" to produce xz-compressed flash device files
  [Dan, Michael, Phil]:

  - add implicit rule for compression,

  - mark uncompressed FD files as intermediate,

  - factor out the "flashdevs" macro for sharing between the "all" and
".INTERMEDIATE" targets

- due to said rework above, do not pick up Phil's R-b / T-b, and
  Michal's and Michael's R-b's

 roms/Makefile  |   5 +
 roms/Makefile.edk2 | 148 
 roms/edk2-build.sh |  55 
 3 files changed, 208 insertions(+)

diff --git a/roms/Makefile b/roms/Makefile
index 2e83ececa25a..054b432834ba 100644
--- a/roms/Makefile
+++ b/roms/Makefile
@@ -61,6 +61,7 @@ default:
@echo "  skiboot-- update skiboot.lid"
@echo "  u-boot.e500-- update u-boot.e500"
@echo "  u-boot.sam460  -- update u-boot.sam460"
+   @echo "  efi-- update UEFI (edk2) platform firmware"
 
 bios: build-seabios-config-seabios-128k build-seabios-config-seabios-256k
cp seabios/builds/seabios-128k/bios.bin ../pc-bios/bios.bin
@@ -143,6 +144,9 @@ skiboot:
$(MAKE) -C skiboot CROSS=$(powerpc64_cross_prefix)
cp skiboot/skiboot.lid ../pc-bios/skiboot.lid
 
+efi: edk2-basetools
+   $(MAKE) -f Makefile.edk2
+
 clean:
rm -rf seabios/.config seabios/out seabios/builds
$(MAKE) -C sgabios clean
@@ -153,3 +157,4 @@ clean:
rm -rf u-boot/build.e500
$(MAKE) -C u-boot-sam460ex distclean
$(MAKE) -C skiboot clean
+   $(MAKE) -f Makefile.edk2 clean
diff --git a/roms/Makefile.edk2 b/roms/Makefile.edk2
new file mode 100644
index ..822c547fec64
--- /dev/null
+++ b/roms/Makefile.edk2
@@ -0,0 +1,148 @@
+# Makefile for building firmware binaries and variable store templates for a
+# number of virtual platforms in edk2.
+#
+# Copyright (C) 2019 Red Hat, Inc.
+#
+# This program and the accompanying materials are licensed and made available
+# under the terms and conditions of the BSD License that accompanies this
+# distribution. The full text of the license may be found at
+# .
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+# WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+SHELL = /bin/bash
+
+toolchain = $(shell source ./edk2-funcs.sh && qemu_edk2_get_toolchain $(1))
+
+licenses := \
+   edk2/License.txt \
+   edk2/OvmfPkg/License.txt \
+   edk2/CryptoPkg/Library/OpensslLib/openssl/LICENSE
+
+# The "edk2-arm-vars.fd" varstore template is suitable for aarch64 as well.
+# Similarly, the "edk2-i386-vars.fd" varstore template is suitable for x86_64
+# as well, independently of "secure" too.
+flashdevs := \
+   aarch64-code \
+   arm-code \
+   i386-code \
+   i386-secure-code \
+   x86_64-code \
+   x86_64-secure-code \
+   \
+   arm-vars \
+   i386-vars
+
+all: $(foreach flashdev,$(flashdevs),../pc-bios/edk2-$(flashdev).fd.bz2) \
+   ../pc-bios/edk2-licenses.txt
+
+../pc-bios/edk2-%.fd.bz2: ../pc-bios/edk2-%.fd
+   bzip2 -9 -c $< > $@
+
+# When the build completes, we need not keep the uncompressed flash device
+# files.
+.INTERMEDIATE: $(foreach flashdev,$(flashdevs),../pc-bios/edk2-$(flashdev).fd)
+
+submodules:
+   cd edk2 && git submodule update --init --force
+
+# See notes on the ".NOTPARALLEL" target and the "+" indicator in
+# "tests/uefi-test-tools/Makefile".
+.NOTPARALLEL:
+
+../pc-bios/edk2-aarch64-code.fd: submodules
+   +./edk2-build.sh \
+   aarch64 \
+   --arch=AARCH64 \
+   --platform=ArmVirtPkg/ArmVirtQemu.dsc \
+   -D NETWORK_IP6_ENABLE \
+   -D HTTP_BOOT_ENABLE
+   cp edk2/Build/ArmVirtQemu-AARCH64/DEBUG_$(call 
toolchain,aarch64)/FV/QEMU_EFI.fd \
+   $@
+   truncate --size=64M $@
+
+../pc-bios/edk2-arm-code.fd: submodules

[Qemu-devel] [PATCH for-4.1 v3 11/12] Makefile: install the edk2 firmware images and their descriptors

2019-03-21 Thread Laszlo Ersek
Decompress and install the edk2 firmware blobs as part of "make install",
unless blob installation was disabled with configure's "--disable-blobs"
option.

Additionally, decompress the blobs as a pre-requisite for building softmmu
binaries -- this is helpful for both "make check" and other ad-hoc tests
one might want to run in the build directory.

Signed-off-by: Laszlo Ersek 
Reviewed-by: Michal Privoznik 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Michael S. Tsirkin 
---

Notes:
v3:

- pick up Michal's R-b

- pick up Phil's R-b

- pick up Michael's R-b

- Decompress fd.bz2 files with bzip2 rather than fd.xz files with xz, so
  that decompression at "make install" time succeed on older build OSes
  too [Peter]. Note that "BUNZIP2" matches the name of the actual
  command "bunzip2" (i.e. it is sensible), and that it consists of 7
  characters, satisfying the quiet-command limit.

- do not pick up Phil's T-b, consequently

- do not pick up Igor's T-b for the same reason

v2:

- adapt to tracking the edk2 flash device files in compressed form [Dan,
  Michael, Phil]

- do not pick up Michal's and Michael's R-b's due to the above change

 configure  |  1 +
 Makefile   | 29 +++-
 .gitignore |  1 +
 3 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index c5032425e6d3..df6e01ada833 100755
--- a/configure
+++ b/configure
@@ -7865,6 +7865,7 @@ for bios_file in \
 $source_path/pc-bios/*.img \
 $source_path/pc-bios/openbios-* \
 $source_path/pc-bios/u-boot.* \
+$source_path/pc-bios/edk2-*.fd.bz2 \
 $source_path/pc-bios/palcode-*
 do
 LINKS="$LINKS pc-bios/$(basename $bios_file)"
diff --git a/Makefile b/Makefile
index d8dad39c5db1..f4562092e8dc 100644
--- a/Makefile
+++ b/Makefile
@@ -296,6 +296,10 @@ ui/input-keymap-%.c: $(KEYCODEMAP_GEN) $(KEYCODEMAP_CSV) 
$(SRC_PATH)/ui/Makefile
 $(KEYCODEMAP_GEN): .git-submodule-status
 $(KEYCODEMAP_CSV): .git-submodule-status
 
+edk2-decompressed = $(basename $(wildcard pc-bios/edk2-*.fd.bz2))
+pc-bios/edk2-%.fd: pc-bios/edk2-%.fd.bz2
+   $(call quiet-command,bzip2 -d -c $< > $@,"BUNZIP2",$<)
+
 # Don't try to regenerate Makefile or configure
 # We don't generate any of them
 Makefile: ;
@@ -444,6 +448,7 @@ $(SOFTMMU_SUBDIR_RULES): $(block-obj-y)
 $(SOFTMMU_SUBDIR_RULES): $(crypto-obj-y)
 $(SOFTMMU_SUBDIR_RULES): $(io-obj-y)
 $(SOFTMMU_SUBDIR_RULES): config-all-devices.mak
+$(SOFTMMU_SUBDIR_RULES): $(edk2-decompressed)
 
 subdir-%:
$(call quiet-command,$(MAKE) $(SUBDIR_MAKEFLAGS) -C $* V="$(V)" 
TARGET_DIR="$*/" all,)
@@ -632,6 +637,7 @@ clean:
! -path ./roms/edk2/ArmPkg/Library/GccLto/liblto-arm.a \
! -path ./roms/edk2/BaseTools/Source/Python/UPT/Dll/sqlite3.dll 
\
-exec rm {} +
+   rm -f $(edk2-decompressed)
rm -f $(filter-out %.tlb,$(TOOLS)) $(HELPERS-y) qemu-ga TAGS cscope.* 
*.pod *~ */*~
rm -f fsdev/*.pod scsi/*.pod
rm -f qemu-img-cmds.h
@@ -722,9 +728,14 @@ spapr-rtas.bin slof.bin skiboot.lid \
 palcode-clipper \
 u-boot.e500 u-boot-sam460-20100605.bin \
 qemu_vga.ndrv \
+edk2-licenses.txt \
 hppa-firmware.img
+
+DESCS=50-edk2-i386-secure.json 50-edk2-x86_64-secure.json \
+60-edk2-aarch64.json 60-edk2-arm.json 60-edk2-i386.json 60-edk2-x86_64.json
 else
 BLOBS=
+DESCS=
 endif
 
 # Note that we manually filter-out the non-Sphinx documentation which
@@ -785,7 +796,8 @@ endif
 
 ICON_SIZES=16x16 24x24 32x32 48x48 64x64 128x128 256x256 512x512
 
-install: all $(if $(BUILD_DOCS),install-doc) install-datadir 
install-localstatedir
+install: all $(if $(BUILD_DOCS),install-doc) install-datadir 
install-localstatedir \
+   $(if $(INSTALL_BLOBS),$(edk2-decompressed))
 ifneq ($(TOOLS),)
$(call install-prog,$(subst 
qemu-ga,qemu-ga$(EXESUF),$(TOOLS)),$(DESTDIR)$(bindir))
 endif
@@ -807,6 +819,21 @@ ifneq ($(BLOBS),)
set -e; for x in $(BLOBS); do \
$(INSTALL_DATA) $(SRC_PATH)/pc-bios/$$x 
"$(DESTDIR)$(qemu_datadir)"; \
done
+endif
+ifdef INSTALL_BLOBS
+   set -e; for x in $(edk2-decompressed); do \
+   $(INSTALL_DATA) $$x "$(DESTDIR)$(qemu_datadir)"; \
+   done
+endif
+ifneq ($(DESCS),)
+   $(INSTALL_DIR) "$(DESTDIR)$(qemu_datadir)/firmware"
+   set -e; tmpf=$$(mktemp); trap 'rm -f -- "$$tmpf"' EXIT; \
+   for x in $(DESCS); do \
+   sed -e 's,@DATADIR@,$(DESTDIR)$(qemu_datadir),' \
+   "$(SRC_PATH)/pc-bios/descriptors/$$x" > "$$tmpf"; \
+   $(INSTALL_DATA) "$$tmpf" \
+   "$(DESTDIR)$(qemu_datadir)/firmware/$$x"; \
+   done
 endif
for s in $(ICON_SIZES); do \
mkdir -p "$(DESTDIR)/$(qemu_icondir)/hicolor/$${s}/apps"; \
diff --git a/.gitignore b/.gitignore
index 8f782218044e..fd6e6c38c7b9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -97,6 +97,7 @@
 *.gcno
 *.gcov

[Qemu-devel] [PATCH for-4.1 v3 06/12] roms/Makefile: replace the $(EFIROM) target with "edk2-basetools"

2019-03-21 Thread Laszlo Ersek
We don't (can't) have a recipe for building just $(EFIROM); therefore,
while we call the target $(EFIROM), we actually build all of the edk2
BaseTools. Rename the target to edk2-basetools, and update the iPXE
prerequisite accordingly. This will let other targets depend on
"edk2-basetools", where an $(EFIROM) pre-requisite would be misleading.

Signed-off-by: Laszlo Ersek 
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 
Reviewed-by: Michal Privoznik 
Reviewed-by: Michael S. Tsirkin 
Tested-by: Igor Mammedov 
---

Notes:
v3:

- pick up Igor's T-b

v2:

- pick up Phil's R-b / T-b

- pick up Michal's and Michael's R-b's

 roms/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/roms/Makefile b/roms/Makefile
index 78d5dd18c301..2e83ececa25a 100644
--- a/roms/Makefile
+++ b/roms/Makefile
@@ -102,7 +102,7 @@ pxe-rom-%: build-pxe-roms
 
 efirom: $(patsubst %,efi-rom-%,$(pxerom_variants))
 
-efi-rom-%: build-pxe-roms build-efi-roms $(EFIROM)
+efi-rom-%: build-pxe-roms build-efi-roms edk2-basetools
$(EFIROM) -f "0x$(VID)" -i "0x$(DID)" -l 0x02 \
-b ipxe/src/bin/$(VID)$(DID).rom \
-ec ipxe/src/bin-i386-efi/$(VID)$(DID).efidrv \
@@ -120,7 +120,7 @@ build-efi-roms: build-pxe-roms
$(patsubst %,bin-i386-efi/%.efidrv,$(pxerom_targets)) \
$(patsubst %,bin-x86_64-efi/%.efidrv,$(pxerom_targets))
 
-$(EFIROM):
+edk2-basetools:
$(MAKE) -C edk2/BaseTools
 
 slof:
-- 
2.19.1.3.g30247aa5d201





[Qemu-devel] [PATCH for-4.1 v3 08/12] pc-bios: add edk2 firmware binaries and variable store templates

2019-03-21 Thread Laszlo Ersek
Add the files built by the last patch: (compressed) binaries, and the
cumulative license text that covers them.

Signed-off-by: Laszlo Ersek 
Reviewed-by: Michal Privoznik 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Michael S. Tsirkin 
---

Notes:
v3:

- pick up Michal's R-b

- pick up Phil's R-b

- pick up Michael's R-b

- Compress FD files with bzip2 rather than xz, so that decompression at
  "make install" time succeed on older build OSes too. The total size
  grows from 9,394,072 bytes to 9,492,846. [Peter]

- do not pick up Igor's T-b therefore

v2:

- capture the compressed build outputs of the last patch; slightly
  update the commit message [Dan, Michael, Phil]

- consequently, do not pick up Michal's and Michael's R-b's

 pc-bios/edk2-licenses.txt  | 209 
 pc-bios/edk2-aarch64-code.fd.bz2   | Bin 0 -> 1177603 bytes
 pc-bios/edk2-arm-code.fd.bz2   | Bin 0 -> 1173662 bytes
 pc-bios/edk2-arm-vars.fd.bz2   | Bin 0 -> 263 bytes
 pc-bios/edk2-i386-code.fd.bz2  | Bin 0 -> 1688659 bytes
 pc-bios/edk2-i386-secure-code.fd.bz2   | Bin 0 -> 1881979 bytes
 pc-bios/edk2-i386-vars.fd.bz2  | Bin 0 -> 190 bytes
 pc-bios/edk2-x86_64-code.fd.bz2| Bin 0 -> 1669280 bytes
 pc-bios/edk2-x86_64-secure-code.fd.bz2 | Bin 0 -> 1901210 bytes
 9 files changed, 209 insertions(+)

diff --git a/pc-bios/edk2-licenses.txt b/pc-bios/edk2-licenses.txt
new file mode 100644
index ..8bdb1abc993e
--- /dev/null
+++ b/pc-bios/edk2-licenses.txt
@@ -0,0 +1,209 @@
+==> edk2/License.txt <==
+Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2008 - 2010, Apple Inc. All rights reserved.
+Copyright (c) 2011 - 2015, ARM Limited. All rights reserved.
+Copyright (c) 2014 - 2015, Linaro Limited. All rights reserved.
+Copyright (c) 2013 - 2015, Red Hat, Inc.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+  notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+  notice, this list of conditions and the following disclaimer in
+  the documentation and/or other materials provided with the
+  distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
+ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGE.
+
+==> edk2/OvmfPkg/License.txt <==
+Copyright (c) 2012, Intel Corporation. All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+  notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+  notice, this list of conditions and the following disclaimer in
+  the documentation and/or other materials provided with the
+  distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
+ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGE.
+
+
+Some files are subject to the following license, the MIT license. Those files
+are located in:
+- OvmfPkg/Include/IndustryStandard/Xen/
+- OvmfPkg/XenBusDxe/
+- OvmfPkg/XenPvBlkDxe/
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the ri

[Qemu-devel] [PATCH for-4.1 v3 05/12] roms/edk2-funcs.sh: add the qemu_edk2_get_thread_count() function

2019-03-21 Thread Laszlo Ersek
The edk2 "build" utility natively supports building modules (that is, INF
files) in parallel. The feature is not useful when building a single
module (with the "-m" option), but it is useful for platform firmware
builds (which include many modules). Add a function that determines the
"-n" option argument for "build", from the MAKEFLAGS variable (i.e. based
on the presence of a make job server).

Signed-off-by: Laszlo Ersek 
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 
Reviewed-by: Michal Privoznik 
Reviewed-by: Michael S. Tsirkin 
Tested-by: Igor Mammedov 
---

Notes:
v3:

- pick up Igor's T-b

v2:

- pick up Phil's R-b / T-b

- pick up Michal's and Michael's R-b's

 roms/edk2-funcs.sh | 25 
 1 file changed, 25 insertions(+)

diff --git a/roms/edk2-funcs.sh b/roms/edk2-funcs.sh
index d1cb1e4a111e..a9fae7ee891b 100644
--- a/roms/edk2-funcs.sh
+++ b/roms/edk2-funcs.sh
@@ -226,3 +226,28 @@ qemu_edk2_set_cross_env()
 
   eval "export $cross_prefix_var=\$cross_prefix"
 }
+
+
+# Determine the "-n" option argument (that is, the number of modules to build
+# in parallel) for the edk2 "build" utility. Print the result to the standard
+# output.
+#
+# Parameters:
+#   $1: the value of the MAKEFLAGS variable
+qemu_edk2_get_thread_count()
+{
+  local makeflags="$1"
+
+  if [[ "$makeflags" == *--jobserver-auth=* ]] ||
+ [[ "$makeflags" == *--jobserver-fds=* ]]; then
+# If there is a job server, allow the edk2 "build" utility to parallelize
+# as many module builds as there are logical CPUs in the system. The "make"
+# instances forked by "build" are supposed to limit themselves through the
+# job server. The zero value below causes the edk2 "build" utility to fetch
+# the logical CPU count with Python's multiprocessing.cpu_count() method.
+printf '0\n'
+  else
+# Build a single module at a time.
+printf '1\n'
+  fi
+}
-- 
2.19.1.3.g30247aa5d201





[Qemu-devel] [PATCH for-4.1 v3 03/12] tests/uefi-test-tools/build.sh: work around TianoCore#1607

2019-03-21 Thread Laszlo Ersek
The edk2-stabe201903 release introduced Python3 support to edk2's
BaseTools; however the Python3 enablement breaks in a corner case (which
is nevertheless supported by the edk2 community), namely the in-module
parallelization that we utilize.

This is tracked under
. For now, work
around the issue (in advance) by forcing Python2. (The workaround is a
no-op before we move to edk2-stabe201903 in the roms/edk2 submodule.)

Signed-off-by: Laszlo Ersek 
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 
Reviewed-by: Michal Privoznik 
Reviewed-by: Michael S. Tsirkin 
Tested-by: Igor Mammedov 
---

Notes:
v3:

- pick up Igor's T-b

v2:

- pick up Phil's R-b / T-b

- pick up Michal's and Michael's R-b's

 tests/uefi-test-tools/build.sh | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tests/uefi-test-tools/build.sh b/tests/uefi-test-tools/build.sh
index e2b52c855c39..8aa7935c43bb 100755
--- a/tests/uefi-test-tools/build.sh
+++ b/tests/uefi-test-tools/build.sh
@@ -29,6 +29,9 @@ export PACKAGES_PATH=$(realpath -- "$edk2_dir")
 export WORKSPACE=$PWD
 mkdir -p Conf
 
+# Work around .
+export PYTHON_COMMAND=python2
+
 # Source "edksetup.sh" carefully.
 set +e +u +C
 source "$PACKAGES_PATH/edksetup.sh"
-- 
2.19.1.3.g30247aa5d201





[Qemu-devel] [PATCH for-4.1 v3 02/12] roms/edk2-funcs.sh: require gcc-4.8+ for building i386 and x86_64

2019-03-21 Thread Laszlo Ersek
Adapt the qemu_edk2_get_toolchain() function in "roms/edk2-funcs.sh" in
advance to edk2 commit 8d7cdfae8cb8 ("OvmfPkg: require GCC48 or later",
2019-01-08), which is part of the "edk2-stable201903" tag.

Signed-off-by: Laszlo Ersek 
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 
Reviewed-by: Michal Privoznik 
Reviewed-by: Michael S. Tsirkin 
Tested-by: Igor Mammedov 
---

Notes:
v3:

- pick up Igor's T-b

v2:

- pick up Phil's R-b / T-b

- pick up Michal's and Michael's R-b's

 roms/edk2-funcs.sh | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/roms/edk2-funcs.sh b/roms/edk2-funcs.sh
index 8930479dcb44..d1cb1e4a111e 100644
--- a/roms/edk2-funcs.sh
+++ b/roms/edk2-funcs.sh
@@ -149,23 +149,11 @@ qemu_edk2_get_toolchain()
   # Run "git-blame" on "OvmfPkg/build.sh" in edk2 for more information on
   # the mapping below.
   case "$gcc_version" in
-([1-3].*|4.[0-3].*)
+([1-3].*|4.[0-7].*)
   printf '%s: unsupported gcc version "%s"\n' \
 "$program_name" "$gcc_version" >&2
   return 1
   ;;
-(4.4.*)
-  printf 'GCC44\n'
-  ;;
-(4.5.*)
-  printf 'GCC45\n'
-  ;;
-(4.6.*)
-  printf 'GCC46\n'
-  ;;
-(4.7.*)
-  printf 'GCC47\n'
-  ;;
 (4.8.*)
   printf 'GCC48\n'
   ;;
-- 
2.19.1.3.g30247aa5d201





[Qemu-devel] [PATCH for-4.1 v3 04/12] roms/edk2: advance to tag edk2-stable201903

2019-03-21 Thread Laszlo Ersek
Update the roms/edk2 submodule hash from edk2-stable201811 to
edk2-stable201903. The release notes are available at
.

$ git shortlog edk2-stable201811..edk2-stable201903

Achin Gupta (9):
  ArmPkg: Add PCDs needed for MM communication driver.
  ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROTOCOL DXE driver.
  ArmPkg/Include: Add MM interface SVC return codes.
  ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0.
  StandaloneMmPkg: Add missing dependency on PL011UartClockLib
  StandaloneMmPkg: Enforce alignment check for AArch64
  StandaloneMmPkg: Zero data structure explicitly
  StandaloneMmPkg: Replace dependency on ArmMmuLib
  StandaloneMmPkg: Update dependency on PeCoffExtraActionLib

Albecki, Mateusz (1):
  MdeModulePkg/SdMmcPciHcDxe Fix eMMC HS400 switch sequence

Alex James (2):
  StdLib/sys/termios: Define cc_t as unsigned
  StdLib/Environs: Avoid infinite recursion in _Exit

Antoine Coeur (5):
  ArmVirtPkg: Fix various typos
  CryptoPkg: Fix various typos
  CorebootPayloadPkg: Fix various typos
  CorebootModulePkg: Fix various typos
  BaseTools: Various typo

Ard Biesheuvel (116):
  MdePkg/BaseIoLibIntrinsicArmVirt ARM: avoid double word loads and stores
  ArmPkg/ArmGicDxe ARM: fix encoding for GICv3 interrupt acknowledge
  ArmPlatformPkg: clear frame pointer in startup code
  ArmVirtPkg/PrePi: clear frame pointer in startup code
  ArmPkg/ArmSmcPsciResetSystemLib: add missing call to ExitBootServices()
  ArmPkg: remove now unused BsdLib.h
  ArmPlatformPkg/NorFlashDxe: prepare for devicepath format change
  ArmPlatformPkg/NorFlashDxe: use one GUID plus index to identify flash 
banks
  ArmVirtPkg/FdtClientDxe: take DT node 'status' properties into account
  ArmVirtPkg/NorFlashQemuLib: discover NOR flash banks dynamically
  ArmPlatformPkg/NorFlashPlatformLib: remove unused Guid member from struct
  ArmPkg/ArmPkg.dsc: move ArmMmuStandaloneMmLib.inf to AARCH64 section
  EmbeddedPkg/TemplateSec: remove unused module
  EmbeddedPkg/PrePiHobLib: drop CreateHobList() from library
  ArmVirtPkg/FdtPciHostBridgeLib: map ECAM and I/O spaces in GCD memory map
  ArmVirtPkg/QemuVirtMemInfoLib: remove 1:1 mapping of top of PA range
  MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits
  ArmPkg/ArmLib: add support for reading the max physical address space size
  ArmVirtPkg/XenVirtMemInfoLib: refactor reading of the PA space size
  ArmPkg/ArmMmuLib: take the CPU supported maximum PA space into account
  ArmPkg/CpuPei: base GCD memory space size on CPU's PA range
  ArmPlatformPkg/PrePi: base GCD memory space size on CPU's PA range
  ArmVirtPkg/PrePi: base GCD memory space size on CPU's PA range
  BeagleBoardPkg/PrePi: base GCD memory space size on CPU's PA range
  ArmPlatformPkg/PlatformPei: drop unused PCD references
  EmbeddedPkg/PrePiLib: drop unused PCD reference
  ArmVirtPkg: drop PcdPrePiCpuMemorySize assignments from all platforms
  EmbeddedPkg/EmbeddedPkg.dec: drop PcdPrePiCpuMemorySize declarations
  ArmPkg/ArmMmuLib ARM: handle unmapped section in GetMemoryRegion()
  ArmPkg/ArmMmuLib ARM: handle unmapped sections when updating permissions
  ArmVirtPkg/NorFlashQemuLib: disregard our primary FV
  ArmVirtPkg/QemuVirtMemInfoLib: trim the MMIO region mapping
  BaseTools/CommonLib: avoid using 'native' word size in IP address handling
  BaseTools/CommonLib: use explicit 64-bit type in Strtoi()
  BaseTools/DevicePath: use explicit 64-bit number parsing routines
  BaseTools/CommonLib: add definition of MAX_UINT32
  BaseTools/DevicePath: use MAX_UINT32 as default device path max size
  BaseTools/CommonLib: get rid of 'native' type string parsing routines
  BaseTools/CommonLib: drop definition of MAX_UINTN
  BaseTools/CommonLib: drop the use of MAX_ADDRESS
  Revert "MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits"
  MdeModulePkg/FileExplorerLib: avoid packed struct for program data
  BaseTools/tools_def AARCH64 RELEASE: move GCC49/GGC5 to 4 KB alignment
  ArmVirtPkg/ArmVirtQemuKernel ARM: make some PCD settings apply to ARM
  ArmVirtPkg/PrePiUniCoreRelocatable CLANG38: work around build issues
  BaseTools/GenFw ARM: don't permit R_ARM_GOT_PREL relocations
  MdePkg/BaseMemoryLibOptDxe ARM: add missing function annotations
  BaseTools/tools_def ARM CLANG35: work around -mno-movt option name change
  ArmVirtPkg/PrePi ARM CLANG35: drop incompatible command line option
  ArmVirtPkg/ArmVirt.dsc.inc: define TcpIoLib resolution unconditionally
  ArmPkg: remove redundant _ARM_PLATFORM_FLAGS overrides
  EmbeddedPkg: remove GdbDebugAgent library
  BaseTools/tools_def ARM: emit PIC veneers
  ArmPkg/DefaultExceptionHandlerLib ARM: avoid endless loop in RELEA

[Qemu-devel] [PATCH for-4.1 v3 00/12] bundle edk2 platform firmware with QEMU

2019-03-21 Thread Laszlo Ersek
Repo:   https://github.com/lersek/qemu.git
Branch: edk2_build_v3

Version 2, that is:

  [Qemu-devel] [PATCH v2 00/12] bundle edk2 platform firmware with QEMU

was posted at:

  https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg04670.html
  20190313210057.32584-1-lersek@redhat.com">http://mid.mail-archive.com/20190313210057.32584-1-lersek@redhat.com

Updates in v3 are noted on each patch individually, in the Notes
section. In summary,

- I've picked up feedback tags from the v2 thread (see above),

- I've replaced the xz compression with bz2 compression according to the
  subthread

Re: [Qemu-devel] [PULL 00/12] EDK2 Firmware roms

  at:

https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06016.html

http://mid.mail-archive.com/CAFEAcA-UcX6Brv3O28vcCw31bt=QpvbUwnPBBjhETm=vfci...@mail.gmail.com

I'm pasting a cumulative diffstat, and diff, between v2 and v3 below.
Note that a normal diffstat for this v3 series is at the bottom of the
cover letter, as usual.

>  Makefile   |   6 +++---
>  configure  |   2 +-
>  pc-bios/README |   2 +-
>  pc-bios/edk2-aarch64-code.fd.bz2   | Bin 0 -> 1177603 bytes
>  pc-bios/edk2-aarch64-code.fd.xz| Bin 1146804 -> 0 bytes
>  pc-bios/edk2-arm-code.fd.bz2   | Bin 0 -> 1173662 bytes
>  pc-bios/edk2-arm-code.fd.xz| Bin 1147852 -> 0 bytes
>  pc-bios/edk2-arm-vars.fd.bz2   | Bin 0 -> 263 bytes
>  pc-bios/edk2-arm-vars.fd.xz| Bin 10008 -> 0 bytes
>  pc-bios/edk2-i386-code.fd.bz2  | Bin 0 -> 1688659 bytes
>  pc-bios/edk2-i386-code.fd.xz   | Bin 1674764 -> 0 bytes
>  pc-bios/edk2-i386-secure-code.fd.bz2   | Bin 0 -> 1881979 bytes
>  pc-bios/edk2-i386-secure-code.fd.xz| Bin 1870024 -> 0 bytes
>  pc-bios/edk2-i386-vars.fd.bz2  | Bin 0 -> 190 bytes
>  pc-bios/edk2-i386-vars.fd.xz   | Bin 320 -> 0 bytes
>  pc-bios/edk2-x86_64-code.fd.bz2| Bin 0 -> 1669280 bytes
>  pc-bios/edk2-x86_64-code.fd.xz | Bin 1655276 -> 0 bytes
>  pc-bios/edk2-x86_64-secure-code.fd.bz2 | Bin 0 -> 1901210 bytes
>  pc-bios/edk2-x86_64-secure-code.fd.xz  | Bin 1889024 -> 0 bytes
>  roms/Makefile.edk2 |   6 +++---
>  20 files changed, 8 insertions(+), 8 deletions(-)

> diff --git a/configure b/configure
> index 5061f68653a3..df6e01ada833 100755
> --- a/configure
> +++ b/configure
> @@ -7865,7 +7865,7 @@ for bios_file in \
>  $source_path/pc-bios/*.img \
>  $source_path/pc-bios/openbios-* \
>  $source_path/pc-bios/u-boot.* \
> -$source_path/pc-bios/edk2-*.fd.xz \
> +$source_path/pc-bios/edk2-*.fd.bz2 \
>  $source_path/pc-bios/palcode-*
>  do
>  LINKS="$LINKS pc-bios/$(basename $bios_file)"
> diff --git a/Makefile b/Makefile
> index 6c5c1a1cad6e..f4562092e8dc 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -296,9 +296,9 @@ ui/input-keymap-%.c: $(KEYCODEMAP_GEN) $(KEYCODEMAP_CSV) 
> $(SRC_PATH)/ui/Makefile
>  $(KEYCODEMAP_GEN): .git-submodule-status
>  $(KEYCODEMAP_CSV): .git-submodule-status
>
> -edk2-decompressed = $(basename $(wildcard pc-bios/edk2-*.fd.xz))
> -pc-bios/edk2-%.fd: pc-bios/edk2-%.fd.xz
> - $(call quiet-command,xz -d -c $< > $@,"UNXZ",$<)
> +edk2-decompressed = $(basename $(wildcard pc-bios/edk2-*.fd.bz2))
> +pc-bios/edk2-%.fd: pc-bios/edk2-%.fd.bz2
> + $(call quiet-command,bzip2 -d -c $< > $@,"BUNZIP2",$<)
>
>  # Don't try to regenerate Makefile or configure
>  # We don't generate any of them
> diff --git a/roms/Makefile.edk2 b/roms/Makefile.edk2
> index e5c3036949c8..822c547fec64 100644
> --- a/roms/Makefile.edk2
> +++ b/roms/Makefile.edk2
> @@ -34,11 +34,11 @@ flashdevs := \
>   arm-vars \
>   i386-vars
>
> -all: $(foreach flashdev,$(flashdevs),../pc-bios/edk2-$(flashdev).fd.xz) \
> +all: $(foreach flashdev,$(flashdevs),../pc-bios/edk2-$(flashdev).fd.bz2) \
>   ../pc-bios/edk2-licenses.txt
>
> -../pc-bios/edk2-%.fd.xz: ../pc-bios/edk2-%.fd
> - xz -9 -e -c $< > $@
> +../pc-bios/edk2-%.fd.bz2: ../pc-bios/edk2-%.fd
> + bzip2 -9 -c $< > $@
>
>  # When the build completes, we need not keep the uncompressed flash device
>  # files.
> diff --git a/pc-bios/README b/pc-bios/README
> index f6acd3209610..807d95dd5418 100644
> --- a/pc-bios/README
> +++ b/pc-bios/README
> @@ -51,7 +51,7 @@
>  - QemuMacDrivers (https://github.com/ozbenh/QemuMacDrivers) is a project to
>provide virtualised drivers for PPC MacOS guests.
>
> -- The "edk2-*.fd.xz" images are platform firmware binaries and matching UEFI
> +- The "edk2-*.fd.bz2" images are platform firmware binaries and matching UEFI
>variable store templates built from the TianoCore community's EFI 
> Development
>Kit II project
>. The images
> diff --git a/pc-bios/edk2-aarch64-code.fd.bz2 
> b/pc-bios/edk2-aarch64-code.fd.bz2
> new file mode 100644
> index ..b213334d9553
> Binary files /dev/null and b/

[Qemu-devel] [PATCH for-4.1 v3 01/12] roms: lift "edk2-funcs.sh" from "tests/uefi-test-tools/build.sh"

2019-03-21 Thread Laszlo Ersek
Extract the dense logic for architecture and toolchain massaging from
"tests/uefi-test-tools/build.sh", to a set of small functions. We'll reuse
these functions for building full platform firmware images.

Signed-off-by: Laszlo Ersek 
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 
Reviewed-by: Michal Privoznik 
Reviewed-by: Michael S. Tsirkin 
Tested-by: Igor Mammedov 
---

Notes:
v3:

- pick up Igor's T-b

v2:

- Pick up Phil's R-b and T-b. (I hope that's okay, after the discussion
  about cross-building on Ubuntu and/or with Linaro toolchains!)

- drop comma after copyright year, in the new file [Eric]

- clarify in the leading comment of "edk2-funcs.sh" that the file
  requires bash [Phil, Eric]

- pick up Michal's and Michael's R-b's

 roms/edk2-funcs.sh | 240 
 tests/uefi-test-tools/build.sh |  97 +---
 2 files changed, 246 insertions(+), 91 deletions(-)

diff --git a/roms/edk2-funcs.sh b/roms/edk2-funcs.sh
new file mode 100644
index ..8930479dcb44
--- /dev/null
+++ b/roms/edk2-funcs.sh
@@ -0,0 +1,240 @@
+# Shell script that defines functions for determining some environmental
+# characteristics for the edk2 "build" utility.
+#
+# This script is meant to be sourced, in a bash environment.
+#
+# Copyright (C) 2019 Red Hat, Inc.
+#
+# This program and the accompanying materials are licensed and made available
+# under the terms and conditions of the BSD License that accompanies this
+# distribution. The full text of the license may be found at
+# .
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+# WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+
+# Verify whether the QEMU system emulation target is supported by the UEFI spec
+# and edk2. Print a message to the standard error, and return with nonzero
+# status, if verification fails.
+#
+# Parameters:
+#   $1: QEMU system emulation target
+qemu_edk2_verify_arch()
+{
+  local emulation_target="$1"
+  local program_name=$(basename -- "$0")
+
+  case "$emulation_target" in
+(arm|aarch64|i386|x86_64)
+  ;;
+(*)
+  printf '%s: unknown/unsupported QEMU system emulation target "%s"\n' \
+"$program_name" "$emulation_target" >&2
+  return 1
+  ;;
+  esac
+}
+
+
+# Translate the QEMU system emulation target to the edk2 architecture
+# identifier. Print the result to the standard output.
+#
+# Parameters:
+#   $1: QEMU system emulation target
+qemu_edk2_get_arch()
+{
+  local emulation_target="$1"
+
+  if ! qemu_edk2_verify_arch "$emulation_target"; then
+return 1
+  fi
+
+  case "$emulation_target" in
+(arm)
+  printf 'ARM\n'
+  ;;
+(aarch64)
+  printf 'AARCH64\n'
+  ;;
+(i386)
+  printf 'IA32\n'
+  ;;
+(x86_64)
+  printf 'X64\n'
+  ;;
+  esac
+}
+
+
+# Translate the QEMU system emulation target to the gcc cross-compilation
+# architecture identifier. Print the result to the standard output.
+#
+# Parameters:
+#   $1: QEMU system emulation target
+qemu_edk2_get_gcc_arch()
+{
+  local emulation_target="$1"
+
+  if ! qemu_edk2_verify_arch "$emulation_target"; then
+return 1
+  fi
+
+  case "$emulation_target" in
+(arm|aarch64|x86_64)
+  printf '%s\n' "$emulation_target"
+  ;;
+(i386)
+  printf 'i686\n'
+  ;;
+  esac
+}
+
+
+# Determine the gcc cross-compiler prefix (if any) for use with the edk2
+# toolchain. Print the result to the standard output.
+#
+# Parameters:
+#   $1: QEMU system emulation target
+qemu_edk2_get_cross_prefix()
+{
+  local emulation_target="$1"
+  local gcc_arch
+  local host_arch
+
+  if ! gcc_arch=$(qemu_edk2_get_gcc_arch "$emulation_target"); then
+return 1
+  fi
+
+  host_arch=$(uname -m)
+
+  if [ "$gcc_arch" == "$host_arch" ] ||
+ ( [ "$gcc_arch" == i686 ] && [ "$host_arch" == x86_64 ] ); then
+# no cross-compiler needed
+:
+  else
+printf '%s-linux-gnu-\n' "$gcc_arch"
+  fi
+}
+
+
+# Determine the edk2 toolchain tag for the QEMU system emulation target. Print
+# the result to the standard output. Print a message to the standard error, and
+# return with nonzero status, if the (conditional) gcc version check fails.
+#
+# Parameters:
+#   $1: QEMU system emulation target
+qemu_edk2_get_toolchain()
+{
+  local emulation_target="$1"
+  local program_name=$(basename -- "$0")
+  local cross_prefix
+  local gcc_version
+
+  if ! qemu_edk2_verify_arch "$emulation_target"; then
+return 1
+  fi
+
+  case "$emulation_target" in
+(arm|aarch64)
+  printf 'GCC5\n'
+  ;;
+
+(i386|x86_64)
+  if ! cross_prefix=$(qemu_edk2_get_cross_prefix "$emulation_target"); then
+return 1
+  fi
+
+  gcc_version=$("${cross_prefix}gcc" -v 2>&1 | tail -1 | awk '{print $3}')
+  # Run "git-blame" on "OvmfPkg/build.sh" in edk2 for more information on
+  # th

Re: [Qemu-devel] [PATCH] xen-block: only advertize discard to the frontend when it is enabled...

2019-03-21 Thread Anthony PERARD
On Wed, Mar 20, 2019 at 02:28:25PM +, Paul Durrant wrote:
> ...and properly enable it when synthesizing a drive.
> 
> The Xen toolstack sets 'discard-enable' to '1' in xenstore when it wants
> to enable discard on a specified image. The code in
> xen_block_driver_create() correctly parses this and uses it to set

typo: It's xen_block_drive_create (s/driver/drive/), otherwise my IDE
can't find it :-(.

> 'discard' to 'unamp' for the file_layer, but fails to do the same for the

Looks like s/unamp/unmap/

> driver_layer (which effectively disables it). Meanwhile the code in
> xen_block_realize() advertizes discard support to the frontend in the
> default case (because conf->discard_granularity defaults to -1), even when

That doesn't match the code I'm reading, before the patch apply.
if (discard_granularity > 0) feature-discard=1
Nothing seems to set discard_granularity, so it keeps it's default to
-1, so  wait, discard_granularity is unsigned :-(

The description is fine then.

> the underlying image may not handle it.
> 
> This patch adds the missing option to the driver_layer in
> xen_block_driver_create() and checks whether BDRV_O_UNMAP is actually
> set on the block device before advertizing discard to the frontend.
> In the case that discard is supported it also makes sure that the
> granularity is set to the physical block size.
> 
> Signed-off-by: Paul Durrant 

With the two typos fixed (which I can try to remember to do on commit):
Reviewed-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD



[Qemu-devel] [PATCH] json: Fix off-by-one assert check in next_state()

2019-03-21 Thread Liam Merwick
The assert checking if the value of lexer->state in next_state(),
which is used as an index to the 'json_lexer' array, incorrectly
checks for an index value less than or equal to ARRAY_SIZE(json_lexer).
Fix assert so that it just checks for an index less than the array size.

Signed-off-by: Liam Merwick 
---
 qobject/json-lexer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/qobject/json-lexer.c b/qobject/json-lexer.c
index a7df2093aa30..632320d72d5d 100644
--- a/qobject/json-lexer.c
+++ b/qobject/json-lexer.c
@@ -266,7 +266,7 @@ static inline uint8_t next_state(JSONLexer *lexer, char ch, 
bool flush,
 {
 uint8_t next;
 
-assert(lexer->state <= ARRAY_SIZE(json_lexer));
+assert(lexer->state < ARRAY_SIZE(json_lexer));
 next = json_lexer[lexer->state][(uint8_t)ch];
 *char_consumed = !flush && !(next & LOOKAHEAD);
 return next & ~LOOKAHEAD;
-- 
1.8.3.1




[Qemu-devel] [PULL 1/1] crypto/block: remove redundant struct packing to fix build with gcc 9

2019-03-21 Thread Daniel P . Berrangé
From: Greg Kurz 

Build fails with gcc 9:

crypto/block-luks.c:689:18: error: taking address of packed member of ‘struct 
QCryptoBlockLUKSHeader’ may result in an unaligned pointer value 
[-Werror=address-of-packed-member]
  689 | be32_to_cpus(&luks->header.payload_offset);
  |  ^~~~
crypto/block-luks.c:690:18: error: taking address of packed member of ‘struct 
QCryptoBlockLUKSHeader’ may result in an unaligned pointer value 
[-Werror=address-of-packed-member]
  690 | be32_to_cpus(&luks->header.key_bytes);
  |  ^~~
crypto/block-luks.c:691:18: error: taking address of packed member of ‘struct 
QCryptoBlockLUKSHeader’ may result in an unaligned pointer value 
[-Werror=address-of-packed-member]
  691 | be32_to_cpus(&luks->header.master_key_iterations);
  |  ^~~

... a bunch of similar errors...

crypto/block-luks.c:1288:22: error: taking address of packed member of ‘struct 
QCryptoBlockLUKSKeySlot’ may result in an unaligned pointer value 
[-Werror=address-of-packed-member]
 1288 | be32_to_cpus(&luks->header.key_slots[i].stripes);
  |  ^~
cc1: all warnings being treated as errors

All members of the QCryptoBlockLUKSKeySlot and QCryptoBlockLUKSHeader are
naturally aligned and we already check at build time there isn't any
unwanted padding. Drop the QEMU_PACKED attribute.

Reviewed-by: Eric Blake 
Signed-off-by: Greg Kurz 
Signed-off-by: Daniel P. Berrangé 
---
 crypto/block-luks.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/crypto/block-luks.c b/crypto/block-luks.c
index 6bac79c3ab..5a69b3ce74 100644
--- a/crypto/block-luks.c
+++ b/crypto/block-luks.c
@@ -146,7 +146,7 @@ struct QCryptoBlockLUKSKeySlot {
 uint32_t key_offset;
 /* number of anti-forensic stripes */
 uint32_t stripes;
-} QEMU_PACKED;
+};
 
 QEMU_BUILD_BUG_ON(sizeof(struct QCryptoBlockLUKSKeySlot) != 48);
 
@@ -191,7 +191,7 @@ struct QCryptoBlockLUKSHeader {
 
 /* key slots */
 QCryptoBlockLUKSKeySlot key_slots[QCRYPTO_BLOCK_LUKS_NUM_KEY_SLOTS];
-} QEMU_PACKED;
+};
 
 QEMU_BUILD_BUG_ON(sizeof(struct QCryptoBlockLUKSHeader) != 592);
 
-- 
2.20.1




Re: [Qemu-devel] [PATCH for-4.1 v3 00/12] bundle edk2 platform firmware with QEMU

2019-03-21 Thread Peter Maydell
On Thu, 21 Mar 2019 at 11:34, Laszlo Ersek  wrote:
>
> Repo:   https://github.com/lersek/qemu.git
> Branch: edk2_build_v3
>
> Version 2, that is:
>
>   [Qemu-devel] [PATCH v2 00/12] bundle edk2 platform firmware with QEMU
>
> was posted at:
>
>   https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg04670.html
>   20190313210057.32584-1-lersek@redhat.com">http://mid.mail-archive.com/20190313210057.32584-1-lersek@redhat.com
>
> Updates in v3 are noted on each patch individually, in the Notes
> section. In summary,
>
> - I've picked up feedback tags from the v2 thread (see above),
>
> - I've replaced the xz compression with bz2 compression according to the
>   subthread
>
> Re: [Qemu-devel] [PULL 00/12] EDK2 Firmware roms

Thanks. Could you check that this works in the OpenBSD VM test?
It should just be a matter of
  make -C build vm-build-openbsd

(with 'build' replaced with whatever your build directory's name is):
it will download the VM image and run it automatically. You'll
want to be doing this as a user that can use KVM so that we
do the build in a KVM VM rather than a slow emulated one :-))

thanks
-- PMM



[Qemu-devel] [PULL 0/1] Qcrypto next patches

2019-03-21 Thread Daniel P . Berrangé
The following changes since commit 6532dcebb6160f94b6b278af5e73784164c669f6:

  Merge remote-tracking branch 'remotes/berrange/tags/qio-next-pull-request' 
into staging (2019-03-21 09:33:11 +)

are available in the Git repository at:

  https://github.com/berrange/qemu tags/qcrypto-next-pull-request

for you to fetch changes up to 5993e3be1d9ff5395c0b753c638760bff4a8360f:

  crypto/block: remove redundant struct packing to fix build with gcc 9 
(2019-03-21 11:54:38 +)


Avoid struct packing warnings with gcc9



Greg Kurz (1):
  crypto/block: remove redundant struct packing to fix build with gcc 9

 crypto/block-luks.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
2.20.1




[Qemu-devel] [PULL 1/1] authz: Use OBJECT_CHECK() on objects

2019-03-21 Thread Daniel P . Berrangé
From: Philippe Mathieu-Daudé 

TYPE_QAUTHZ is an abstract object of type TYPE_OBJECT. All other
are children of TYPE_QAUTHZ, thus also objects.

Keep INTERFACE_CHECK() for interfaces, and use OBJECT_CHECK() on
objects.

Reported-by: Markus Armbruster 
Signed-off-by: Philippe Mathieu-Daudé 
Signed-off-by: Daniel P. Berrangé 
---
 include/authz/base.h | 4 ++--
 include/authz/list.h | 4 ++--
 include/authz/listfile.h | 4 ++--
 include/authz/pamacct.h  | 4 ++--
 include/authz/simple.h   | 4 ++--
 5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/include/authz/base.h b/include/authz/base.h
index 77dcd54c4c..55ac9581ad 100644
--- a/include/authz/base.h
+++ b/include/authz/base.h
@@ -35,8 +35,8 @@
  OBJECT_GET_CLASS(QAuthZClass, (obj), \
   TYPE_QAUTHZ)
 #define QAUTHZ(obj) \
- INTERFACE_CHECK(QAuthZ, (obj), \
- TYPE_QAUTHZ)
+ OBJECT_CHECK(QAuthZ, (obj), \
+  TYPE_QAUTHZ)
 
 typedef struct QAuthZ QAuthZ;
 typedef struct QAuthZClass QAuthZClass;
diff --git a/include/authz/list.h b/include/authz/list.h
index a7225a747c..138ae7047c 100644
--- a/include/authz/list.h
+++ b/include/authz/list.h
@@ -33,8 +33,8 @@
 OBJECT_GET_CLASS(QAuthZListClass, (obj),\
   TYPE_QAUTHZ_LIST)
 #define QAUTHZ_LIST(obj) \
-INTERFACE_CHECK(QAuthZList, (obj),  \
-TYPE_QAUTHZ_LIST)
+OBJECT_CHECK(QAuthZList, (obj), \
+ TYPE_QAUTHZ_LIST)
 
 typedef struct QAuthZList QAuthZList;
 typedef struct QAuthZListClass QAuthZListClass;
diff --git a/include/authz/listfile.h b/include/authz/listfile.h
index bcc8d80743..ebbd5a4288 100644
--- a/include/authz/listfile.h
+++ b/include/authz/listfile.h
@@ -34,8 +34,8 @@
 OBJECT_GET_CLASS(QAuthZListFileClass, (obj),\
   TYPE_QAUTHZ_LIST_FILE)
 #define QAUTHZ_LIST_FILE(obj) \
-INTERFACE_CHECK(QAuthZListFile, (obj),  \
-TYPE_QAUTHZ_LIST_FILE)
+OBJECT_CHECK(QAuthZListFile, (obj), \
+ TYPE_QAUTHZ_LIST_FILE)
 
 typedef struct QAuthZListFile QAuthZListFile;
 typedef struct QAuthZListFileClass QAuthZListFileClass;
diff --git a/include/authz/pamacct.h b/include/authz/pamacct.h
index 6e3046e528..cad5b11d47 100644
--- a/include/authz/pamacct.h
+++ b/include/authz/pamacct.h
@@ -33,8 +33,8 @@
  OBJECT_GET_CLASS(QAuthZPAMClass, (obj), \
   TYPE_QAUTHZ_PAM)
 #define QAUTHZ_PAM(obj) \
- INTERFACE_CHECK(QAuthZPAM, (obj), \
- TYPE_QAUTHZ_PAM)
+ OBJECT_CHECK(QAuthZPAM, (obj), \
+  TYPE_QAUTHZ_PAM)
 
 typedef struct QAuthZPAM QAuthZPAM;
 typedef struct QAuthZPAMClass QAuthZPAMClass;
diff --git a/include/authz/simple.h b/include/authz/simple.h
index ef13958269..30b932dfeb 100644
--- a/include/authz/simple.h
+++ b/include/authz/simple.h
@@ -32,8 +32,8 @@
 OBJECT_GET_CLASS(QAuthZSimpleClass, (obj),\
   TYPE_QAUTHZ_SIMPLE)
 #define QAUTHZ_SIMPLE(obj) \
-INTERFACE_CHECK(QAuthZSimple, (obj),  \
-TYPE_QAUTHZ_SIMPLE)
+OBJECT_CHECK(QAuthZSimple, (obj), \
+ TYPE_QAUTHZ_SIMPLE)
 
 typedef struct QAuthZSimple QAuthZSimple;
 typedef struct QAuthZSimpleClass QAuthZSimpleClass;
-- 
2.20.1




Re: [Qemu-devel] [PATCH 1/2] iotests: 030 TestParallelOps non-shared base node

2019-03-21 Thread Vladimir Sementsov-Ogievskiy
21.03.2019 13:53, Kevin Wolf wrote:
> Am 20.03.2019 um 18:02 hat Alberto Garcia geschrieben:
>> On Wed 20 Mar 2019 10:16:10 AM CET, Kevin Wolf wrote:
 Oh, I see. Let's use a shorter chain for simplicity:

 A <- B <- C <- D <- E
>>>
>>> Written from right to left, i.e. E being the base and A the top layer?
>>> We usually write things the other write round, I hope this doesn't get
>>> too confusing later.
>>
>> Oh my... yes, of course you're right, I should have written it the other
>> way around:
>>
>> E <- D <- C <- B <- A
>>
 1) If we stream first from E to C we add a filter F:

 A <- B <- F <- C <- D <- E
>>
>> ( which should have been written   E <- D <- C <- F <- B <- A )
>>
 Now we can't stream from C to A because F is on the way, and the F-C
 link is frozen.
>>>
>>> Why is a frozen link a problem? The streaming operation isn't going to
>>> change this link, it just copies data from the subchain (including F
>>> and C) to A. This is not something that a frozen link should prevent.
>>
>> Not the operation itself, but the first thing that block-stream does is
>> freeze the chain from top (A) to base (C), so this would fail if there's
>> already a frozen link on the way (C <- F on this case?).
> 
> Oh, I see. I think this is why I suggested a counter originally instead
> of a bool.
> 
>>> So it seems frozen links allow the wrong case, but block the correct
>>> one? :-(
>>
>> Yes, we probably need to rethink this scenario a bit.
> 
> But yes, even with a counter, the other problem would still remain (that
> the first job can't remove the filter on completion because the second
> one has frozen its link to the filter).
> 
> I don't think that's a case we want to just forbid because nobody needs
> this anyway. It's a sign of a more fundamental problem in our design,
> and I'm sure it will bite us in other places, too.
> 
> Kevin
> 

Does it mean that we now have problems with other jobs which already has
filter if use them in parallel with stream?

-- 
Best regards,
Vladimir


[Qemu-devel] [PULL 0/1] Authz next patches

2019-03-21 Thread Daniel P . Berrangé
The following changes since commit 62a172e6a77d9072bb1a18f295ce0fcf4b90a4f2:

  Update version for v4.0.0-rc0 release (2019-03-19 17:17:22 +)

are available in the Git repository at:

  https://github.com/berrange/qemu tags/authz-next-pull-request

for you to fetch changes up to 063603d43ec428c1acc63c4e1f8593a7b6d164f1:

  authz: Use OBJECT_CHECK() on objects (2019-03-21 11:52:37 +)


Fix object interface check macro usage



Philippe Mathieu-Daudé (1):
  authz: Use OBJECT_CHECK() on objects

 include/authz/base.h | 4 ++--
 include/authz/list.h | 4 ++--
 include/authz/listfile.h | 4 ++--
 include/authz/pamacct.h  | 4 ++--
 include/authz/simple.h   | 4 ++--
 5 files changed, 10 insertions(+), 10 deletions(-)

-- 
2.20.1




Re: [Qemu-devel] [Qemu-riscv] [PATCH v1 1/1] riscv: plic: Set msi_nonbroken as true

2019-03-21 Thread Andrea Bolognani
On Mon, 2019-03-18 at 02:31 -0700, Palmer Dabbelt wrote:
> On Mon, 18 Mar 2019 01:39:46 PDT (-0700), pbonz...@redhat.com wrote:
> > On 15/03/19 21:05, Alistair Francis wrote:
> > > Set msi_nonbroken as true for the PLIC.
> > > 
> > > According to the comment located here:
> > > https://git.qemu.org/?p=qemu.git;a=blob;f=hw/pci/msi.c;h=47d2b0f33c664533b8dbd5cb17faa8e6a01afe1f;hb=HEAD#l38
> > > the msi_nonbroken variable should be set to true even if they don't
> > > support MSI. In this case that is what we are doing as we don't support
> > > MSI.
> > 
> > I can queue this patch, and add the "select MSI" to CONFIG_SIFIVE.
> 
> Works for me.  Thanks!

Just so we're on the same page, are you targeting this at 4.0.0?
If it gets merged in the next few days I can probably get the
corresponding libvirt patches in before our own freeze starts.

It would be great if we could make it so guests created with
QEMU 4.0.0 + libvirt 5.2.0 get PCI by default :)

-- 
Andrea Bolognani / Red Hat / Virtualization




Re: [Qemu-devel] [Qemu-riscv] [PATCH v1 1/1] riscv: plic: Set msi_nonbroken as true

2019-03-21 Thread Paolo Bonzini
On 21/03/19 12:56, Andrea Bolognani wrote:
> Just so we're on the same page, are you targeting this at 4.0.0?
> If it gets merged in the next few days I can probably get the
> corresponding libvirt patches in before our own freeze starts.
> 
> It would be great if we could make it so guests created with
> QEMU 4.0.0 + libvirt 5.2.0 get PCI by default :)

Yes, I'll send the pull request tomorrow.

Paolo



Re: [Qemu-devel] [PATCH] xen-block: only advertize discard to the frontend when it is enabled...

2019-03-21 Thread Paul Durrant
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 21 March 2019 11:42
> To: Paul Durrant 
> Cc: xen-de...@lists.xenproject.org; qemu-bl...@nongnu.org; 
> qemu-devel@nongnu.org; Stefano Stabellini
> ; Kevin Wolf ; Max Reitz 
> 
> Subject: Re: [PATCH] xen-block: only advertize discard to the frontend when 
> it is enabled...
> 
> On Wed, Mar 20, 2019 at 02:28:25PM +, Paul Durrant wrote:
> > ...and properly enable it when synthesizing a drive.
> >
> > The Xen toolstack sets 'discard-enable' to '1' in xenstore when it wants
> > to enable discard on a specified image. The code in
> > xen_block_driver_create() correctly parses this and uses it to set
> 
> typo: It's xen_block_drive_create (s/driver/drive/), otherwise my IDE
> can't find it :-(.

Sorry, my fingers are so used to typing 'driver'

> 
> > 'discard' to 'unamp' for the file_layer, but fails to do the same for the
> 
> Looks like s/unamp/unmap/

Yes.

> 
> > driver_layer (which effectively disables it). Meanwhile the code in
> > xen_block_realize() advertizes discard support to the frontend in the
> > default case (because conf->discard_granularity defaults to -1), even when
> 
> That doesn't match the code I'm reading, before the patch apply.
> if (discard_granularity > 0) feature-discard=1
> Nothing seems to set discard_granularity, so it keeps it's default to
> -1, so  wait, discard_granularity is unsigned :-(
> 
> The description is fine then.

Indeed.

> 
> > the underlying image may not handle it.
> >
> > This patch adds the missing option to the driver_layer in
> > xen_block_driver_create() and checks whether BDRV_O_UNMAP is actually
> > set on the block device before advertizing discard to the frontend.
> > In the case that discard is supported it also makes sure that the
> > granularity is set to the physical block size.
> >
> > Signed-off-by: Paul Durrant 
> 
> With the two typos fixed (which I can try to remember to do on commit):
> Reviewed-by: Anthony PERARD 

Ok, thanks.

  Paul

> 
> Thanks,
> 
> --
> Anthony PERARD



Re: [Qemu-devel] [PATCH v1 3/3] .travis.yml: --disable-user for --without-default-devices

2019-03-21 Thread Thomas Huth
On 19/03/2019 13.48, Alex Bennée wrote:
> This is essentially a softmmu tweak so don't bother building
> linux-user builds as well.
> 
> Signed-off-by: Alex Bennée 
> ---
>  .travis.yml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 407fc25945..3fb3dab46e 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -165,7 +165,7 @@ matrix:
>  
>  # We manually include builds which we disable "make check" for
>  - env:
> -- CONFIG="--without-default-devices"
> +- CONFIG="--without-default-devices --disable-user"
>  - TEST_CMD=""

Reviewed-by: Thomas Huth 



Re: [Qemu-devel] [PULL v3 00/54] Kconfig conversion, excluding ARM and MIPS

2019-03-21 Thread Laszlo Ersek
On 03/21/19 01:53, Laszlo Ersek wrote:
> Hi Paolo,
> 
> (+libvir-list)
> 
> I'd like to report a regression introduced by this patch set:
> 
> On 03/07/19 21:58, Paolo Bonzini wrote:
>> The following changes since commit
>> 6cb4f6db4f4367faa33da85b15f75bbbd2bed2a6:
>>
>>   Merge remote-tracking branch
>>   'remotes/cleber/tags/python-next-pull-request' into staging
>>   (2019-03-07 16:16:02 +)
>>
>> are available in the Git repository at:
>>
>>   git://github.com/bonzini/qemu.git tags/for-upstream-kconfig
>>
>> for you to fetch changes up to
>> 576c3f2f16e7392e28cc9fe10d9a920d67d3645b:
>>
>>   kconfig: add documentation (2019-03-07 21:54:22 +0100)
>>
>> 
>> Initial Kconfig work, excluding ARM and MIPS
>>
>> 
> 

In brief, the regression is that the aarch64 system emulator now lists
the "virtio-vga" device for the "virt" machine type:

$ qemu-system-aarch64 -M virt -device \? | grep virtio-vga
name "virtio-vga", bus PCI

Here's where I think the issue was introduced:

(1) In commit 82f5181777eb ("kconfig: introduce kconfig files",
2019-03-07), VIRTIO_VGA was introduced simply as a bool (with no other
clauses) in "hw/display/Kconfig".

(2) In commit 7c28b925b7e1 ("build: convert pci.mak to Kconfig",
2019-03-07), VIRTIO_VGA received the following clauses:

default y if PCI_DEVICES
depends on VIRTIO_PCI
select VGA

This is too lax, because it permits virtio-vga for aarch64, while that
shouldn't happen (and it doesn't matches the previous state of the tree).

(3) In commit b42075bb7767 ("virtio: express virtio dependencies with
Kconfig", 2019-03-07), the determination of virtio-vga was switched to
the Kconfig system. Importantly, in this patch, the line

  CONFIG_VIRTIO_VGA=y

was removed *only* from the following file:

  default-configs/i386-softmmu.mak

(4) Both of the remaining instances of

  CONFIG_VIRTIO_VGA=y

were then removed in commit 9483cf27dd36 ("hppa-softmmu.mak: express
dependencies with Kconfig", 2019-03-07) and commit 87f9108bad0c ("ppc64:
Express dependencies of 'pseries' and 'powernv' machines with kconfig",
2019-03-07), from files

  default-configs/hppa-softmmu.mak
  default-configs/ppc64-softmmu.mak

respectively.


Therefore I think commit 7c28b925b7e1 has the bug. The VIRTIO_VGA
restriction

  depends on VIRTIO_PCI

should now be replaced with

  depends on VIRTIO_PCI && (PC || DINO || PSERIES)

Thanks
Laszlo



Re: [Qemu-devel] [PATCH v1 1/3] configure: add --target-list-exclude

2019-03-21 Thread Thomas Huth
On 19/03/2019 13.47, Alex Bennée wrote:
> This is an inverse selection which excludes a selected set of targets
> from the default target list. It will mostly be useful for CI
> configurations but it might be useful for some users as well.

This will be useful for me, too! For my local builds, I normally drop
some few targets (e.g. the "duplicated" endianess targets like
"armeb-linux-user", since I build "arm-linux-user" already), to speed up
the compilation process a little bit. This will be much easier with this
new option when I've got to re-run configure again...

> +if test -z "$target_list_exclude"; then
> +echo "defaults: $target_list_exclude"

That echo line looks like a debug left-over. Remove it?

Apart from that:

Reviewed-by: Thomas Huth 



[Qemu-devel] [PATCH 0/4] build: cleanup in Makefile.objs

2019-03-21 Thread Laurent Vivier
This cleanup removes hardware objects from the list of files to be
built for linux-user only targets.

It also builds traces files only when the related file is built.

Tested with:

   configure --enable-user --disable-system
   configure --disable-user --disable-system
   configure --disable-user --enable-system

Laurent Vivier (4):
  trace: only include trace-event-subdirs when they are needed
  ui: build keymap only with softmmu targets
  tools: edid-generate.c is part of the tools
  build: don't build hardware objects with linux-user

 Makefile   |  2 ++
 Makefile.objs  | 44 --
 tests/Makefile.include | 26 ++---
 3 files changed, 42 insertions(+), 30 deletions(-)

-- 
2.20.1




[Qemu-devel] [PATCH 1/4] trace: only include trace-event-subdirs when they are needed

2019-03-21 Thread Laurent Vivier
Some directories are built only for softmmu targets,
and the related trace-event-subdirs must do the same

Signed-off-by: Laurent Vivier 
---
 Makefile.objs | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/Makefile.objs b/Makefile.objs
index cf065de5ed44..d90123f1d0a3 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -127,11 +127,12 @@ rdmacm-mux-obj-y = contrib/rdmacm-mux/
 trace-events-subdirs =
 trace-events-subdirs += accel/kvm
 trace-events-subdirs += accel/tcg
-trace-events-subdirs += audio
 trace-events-subdirs += authz
 trace-events-subdirs += block
 trace-events-subdirs += chardev
 trace-events-subdirs += crypto
+ifeq ($(CONFIG_SOFTMMU),y)
+trace-events-subdirs += audio
 trace-events-subdirs += hw/9pfs
 trace-events-subdirs += hw/acpi
 trace-events-subdirs += hw/alpha
@@ -173,11 +174,13 @@ trace-events-subdirs += hw/virtio
 trace-events-subdirs += hw/watchdog
 trace-events-subdirs += hw/xen
 trace-events-subdirs += hw/gpio
+trace-events-subdirs += migration
+trace-events-subdirs += net
+trace-events-subdirs += ui
+endif
 trace-events-subdirs += io
 trace-events-subdirs += linux-user
-trace-events-subdirs += migration
 trace-events-subdirs += nbd
-trace-events-subdirs += net
 trace-events-subdirs += qapi
 trace-events-subdirs += qom
 trace-events-subdirs += scsi
@@ -189,7 +192,6 @@ trace-events-subdirs += target/ppc
 trace-events-subdirs += target/riscv
 trace-events-subdirs += target/s390x
 trace-events-subdirs += target/sparc
-trace-events-subdirs += ui
 trace-events-subdirs += util
 
 trace-events-files = $(SRC_PATH)/trace-events 
$(trace-events-subdirs:%=$(SRC_PATH)/%/trace-events)
-- 
2.20.1




[Qemu-devel] [PATCH 2/4] ui: build keymap only with softmmu targets

2019-03-21 Thread Laurent Vivier
we don't need to generate the files for linux-user or for the tools

Signed-off-by: Laurent Vivier 
---
 Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Makefile b/Makefile
index d8dad39c5db1..609fac844637 100644
--- a/Makefile
+++ b/Makefile
@@ -261,6 +261,7 @@ trace-dtrace-root.o: trace-dtrace-root.dtrace
 KEYCODEMAP_GEN = $(SRC_PATH)/ui/keycodemapdb/tools/keymap-gen
 KEYCODEMAP_CSV = $(SRC_PATH)/ui/keycodemapdb/data/keymaps.csv
 
+ifdef CONFIG_SOFTMMU
 KEYCODEMAP_FILES = \
 ui/input-keymap-atset1-to-qcode.c \
 ui/input-keymap-linux-to-qcode.c \
@@ -295,6 +296,7 @@ ui/input-keymap-%.c: $(KEYCODEMAP_GEN) $(KEYCODEMAP_CSV) 
$(SRC_PATH)/ui/Makefile
 
 $(KEYCODEMAP_GEN): .git-submodule-status
 $(KEYCODEMAP_CSV): .git-submodule-status
+endif
 
 # Don't try to regenerate Makefile or configure
 # We don't generate any of them
-- 
2.20.1




[Qemu-devel] [PATCH 3/4] tools: edid-generate.c is part of the tools

2019-03-21 Thread Laurent Vivier
We don't need it for softmmu targets.
This is needed for next patch that will build
hw/ directory only for softmmu and not for tools.

Signed-off-by: Laurent Vivier 
---
 Makefile.objs | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Makefile.objs b/Makefile.objs
index d90123f1d0a3..3538789808af 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -87,6 +87,11 @@ common-obj-y += qmp.o hmp.o
 common-obj-y += qapi/
 endif
 
+ifneq ($(CONFIG_USER_ONLY),y)
+# hw/display/edid-generate.c is needed by qemu-edid
+common-obj-y += hw/display/
+endif
+
 ###
 # Target-independent parts used in system and user emulation
 common-obj-y += cpus-common.o
-- 
2.20.1




[Qemu-devel] [PATCH 4/4] build: don't build hardware objects with linux-user

2019-03-21 Thread Laurent Vivier
Some objects are only needed for system emulation and tools.
We can ignore them for the user mode case

Update tests to run accordingly.

Signed-off-by: Laurent Vivier 
---
 Makefile.objs  | 33 -
 tests/Makefile.include | 26 +++---
 2 files changed, 31 insertions(+), 28 deletions(-)

diff --git a/Makefile.objs b/Makefile.objs
index 3538789808af..5d4585c8e2f5 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -5,6 +5,12 @@ util-obj-y = util/ qobject/ qapi/
 
 chardev-obj-y = chardev/
 
+qom-obj-y = qom/
+
+crypto-obj-y = crypto/
+crypto-aes-obj-y = crypto/
+
+ifneq ($(CONFIG_USER_ONLY),y)
 ###
 # authz-obj-y is code used by both qemu system emulation and qemu-img
 
@@ -21,21 +27,11 @@ block-obj-$(CONFIG_REPLICATION) += replication.o
 
 block-obj-m = block/
 
-###
-# crypto-obj-y is code used by both qemu system emulation and qemu-img
-
-crypto-obj-y = crypto/
-crypto-aes-obj-y = crypto/
-
-###
-# qom-obj-y is code used by both qemu system emulation and qemu-img
-
-qom-obj-y = qom/
-
 ###
 # io-obj-y is code used by both qemu system emulation and qemu-img
 
 io-obj-y = io/
+endif
 
 ##
 # Target independent part of system emulation. The long term path is to
@@ -132,10 +128,18 @@ rdmacm-mux-obj-y = contrib/rdmacm-mux/
 trace-events-subdirs =
 trace-events-subdirs += accel/kvm
 trace-events-subdirs += accel/tcg
+ifeq ($(CONFIG_USER_ONLY),y)
+trace-events-subdirs += linux-user
+else
 trace-events-subdirs += authz
+trace-events-subdirs += nbd
 trace-events-subdirs += block
-trace-events-subdirs += chardev
+trace-events-subdirs += scsi
+trace-events-subdirs += io
+trace-events-subdirs += hw/display # needed by qemu-edid
+endif
 trace-events-subdirs += crypto
+trace-events-subdirs += chardev
 ifeq ($(CONFIG_SOFTMMU),y)
 trace-events-subdirs += audio
 trace-events-subdirs += hw/9pfs
@@ -146,7 +150,6 @@ trace-events-subdirs += hw/audio
 trace-events-subdirs += hw/block
 trace-events-subdirs += hw/block/dataplane
 trace-events-subdirs += hw/char
-trace-events-subdirs += hw/display
 trace-events-subdirs += hw/dma
 trace-events-subdirs += hw/hppa
 trace-events-subdirs += hw/i2c
@@ -183,12 +186,8 @@ trace-events-subdirs += migration
 trace-events-subdirs += net
 trace-events-subdirs += ui
 endif
-trace-events-subdirs += io
-trace-events-subdirs += linux-user
-trace-events-subdirs += nbd
 trace-events-subdirs += qapi
 trace-events-subdirs += qom
-trace-events-subdirs += scsi
 trace-events-subdirs += target/arm
 trace-events-subdirs += target/hppa
 trace-events-subdirs += target/i386
diff --git a/tests/Makefile.include b/tests/Makefile.include
index 852f17b8c79c..c147182fb052 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -45,7 +45,6 @@ SYSEMU_TARGET_LIST := $(subst -softmmu.mak,,$(notdir \
 
 check-unit-y += tests/check-qdict$(EXESUF)
 check-unit-y += tests/check-block-qdict$(EXESUF)
-check-unit-y += tests/test-char$(EXESUF)
 check-unit-y += tests/check-qnum$(EXESUF)
 check-unit-y += tests/check-qstring$(EXESUF)
 check-unit-y += tests/check-qlist$(EXESUF)
@@ -61,9 +60,12 @@ check-unit-y += tests/test-string-input-visitor$(EXESUF)
 check-unit-y += tests/test-string-output-visitor$(EXESUF)
 check-unit-y += tests/test-qmp-event$(EXESUF)
 check-unit-y += tests/test-opts-visitor$(EXESUF)
-check-unit-y += tests/test-coroutine$(EXESUF)
 check-unit-y += tests/test-visitor-serialization$(EXESUF)
 check-unit-y += tests/test-iov$(EXESUF)
+check-unit-y += tests/test-x86-cpuid$(EXESUF)
+ifneq ($(CONFIG_USER_ONLY),y)
+check-unit-y += tests/test-char$(EXESUF)
+check-unit-y += tests/test-coroutine$(EXESUF)
 check-unit-y += tests/test-aio$(EXESUF)
 check-unit-y += tests/test-aio-multithread$(EXESUF)
 check-unit-y += tests/test-throttle$(EXESUF)
@@ -76,7 +78,7 @@ check-unit-y += tests/test-blockjob-txn$(EXESUF)
 check-unit-y += tests/test-block-backend$(EXESUF)
 check-unit-y += tests/test-block-iothread$(EXESUF)
 check-unit-y += tests/test-image-locking$(EXESUF)
-check-unit-y += tests/test-x86-cpuid$(EXESUF)
+endif
 # all code tested by test-x86-cpuid is inside topology.h
 ifeq ($(CONFIG_SOFTMMU),y)
 check-unit-y += tests/test-xbzrle$(EXESUF)
@@ -101,6 +103,14 @@ check-unit-y += tests/check-qom-interface$(EXESUF)
 check-unit-y += tests/check-qom-proplist$(EXESUF)
 check-unit-y += tests/test-qemu-opts$(EXESUF)
 check-unit-y += tests/test-keyval$(EXESUF)
+ifneq (,$(findstring qemu-ga,$(TOOLS)))
+check-unit-$(call land,$(CONFIG_LINUX),$(CONFIG_VIRTIO_SERIAL)) += 
tests/test-qga$(EXESUF)
+endif
+check-unit-y += tests/test-timed-average$(EXESUF)
+check-unit-$(CONFIG_INOTIFY1) += tests/test-util-filemonitor$(EXESUF)
+check-unit-y +=

[Qemu-devel] [PATCH] .travis.yml: reduce number of targets built while disabling things

2019-03-21 Thread Alex Bennée
This build keeps timing out on Travis and it's unlikely including the
additional guest front-ends will catch any failures in the fallback
code.

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

diff --git a/.travis.yml b/.travis.yml
index 3fb3dab46e..2e06aee9d0 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -107,7 +107,7 @@ matrix:
 
 
 - env:
-- CONFIG="--disable-linux-aio --disable-cap-ng --disable-attr 
--disable-brlapi --disable-libusb --disable-user --disable-replication"
+- CONFIG="--disable-linux-aio --disable-cap-ng --disable-attr 
--disable-brlapi --disable-libusb --disable-replication 
--target-list=${MAIN_SOFTMMU_TARGETS}"
 
 
 # Module builds are mostly of interest to major distros
-- 
2.20.1




Re: [Qemu-devel] [PATCH 4/4] build: don't build hardware objects with linux-user

2019-03-21 Thread Daniel P . Berrangé
On Thu, Mar 21, 2019 at 01:46:24PM +0100, Laurent Vivier wrote:
> Some objects are only needed for system emulation and tools.
> We can ignore them for the user mode case
> 
> Update tests to run accordingly.
> 
> Signed-off-by: Laurent Vivier 
> ---
>  Makefile.objs  | 33 -
>  tests/Makefile.include | 26 +++---
>  2 files changed, 31 insertions(+), 28 deletions(-)
> 
> diff --git a/Makefile.objs b/Makefile.objs
> index 3538789808af..5d4585c8e2f5 100644
> --- a/Makefile.objs
> +++ b/Makefile.objs
> @@ -5,6 +5,12 @@ util-obj-y = util/ qobject/ qapi/
>  
>  chardev-obj-y = chardev/
>  
> +qom-obj-y = qom/
> +
> +crypto-obj-y = crypto/
> +crypto-aes-obj-y = crypto/

FYI, this is going to conflict with

  https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg05060.html

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 4/4] build: don't build hardware objects with linux-user

2019-03-21 Thread Philippe Mathieu-Daudé
Le jeu. 21 mars 2019 13:53, Laurent Vivier  a écrit :

> Some objects are only needed for system emulation and tools.
> We can ignore them for the user mode case
>

Finally!


> Update tests to run accordingly.
>
> Signed-off-by: Laurent Vivier 
> ---
>  Makefile.objs  | 33 -
>  tests/Makefile.include | 26 +++---
>  2 files changed, 31 insertions(+), 28 deletions(-)
>
> diff --git a/Makefile.objs b/Makefile.objs
> index 3538789808af..5d4585c8e2f5 100644
> --- a/Makefile.objs
> +++ b/Makefile.objs
> @@ -5,6 +5,12 @@ util-obj-y = util/ qobject/ qapi/
>
>  chardev-obj-y = chardev/
>
> +qom-obj-y = qom/
> +
> +crypto-obj-y = crypto/
> +crypto-aes-obj-y = crypto/
> +
> +ifneq ($(CONFIG_USER_ONLY),y)
>  ###
>  # authz-obj-y is code used by both qemu system emulation and qemu-img
>
> @@ -21,21 +27,11 @@ block-obj-$(CONFIG_REPLICATION) += replication.o
>
>  block-obj-m = block/
>
> -###
> -# crypto-obj-y is code used by both qemu system emulation and qemu-img
> -
> -crypto-obj-y = crypto/
> -crypto-aes-obj-y = crypto/
> -
> -###
> -# qom-obj-y is code used by both qemu system emulation and qemu-img
> -
> -qom-obj-y = qom/
> -
>  ###
>  # io-obj-y is code used by both qemu system emulation and qemu-img
>
>  io-obj-y = io/
> +endif
>
>  ##
>  # Target independent part of system emulation. The long term path is to
> @@ -132,10 +128,18 @@ rdmacm-mux-obj-y = contrib/rdmacm-mux/
>  trace-events-subdirs =
>  trace-events-subdirs += accel/kvm
>  trace-events-subdirs += accel/tcg
> +ifeq ($(CONFIG_USER_ONLY),y)
> +trace-events-subdirs += linux-user
> +else
>  trace-events-subdirs += authz
> +trace-events-subdirs += nbd
>  trace-events-subdirs += block
> -trace-events-subdirs += chardev
> +trace-events-subdirs += scsi
> +trace-events-subdirs += io
> +trace-events-subdirs += hw/display # needed by qemu-edid
> +endif
>  trace-events-subdirs += crypto
> +trace-events-subdirs += chardev
>  ifeq ($(CONFIG_SOFTMMU),y)
>  trace-events-subdirs += audio
>  trace-events-subdirs += hw/9pfs
> @@ -146,7 +150,6 @@ trace-events-subdirs += hw/audio
>  trace-events-subdirs += hw/block
>  trace-events-subdirs += hw/block/dataplane
>  trace-events-subdirs += hw/char
> -trace-events-subdirs += hw/display
>  trace-events-subdirs += hw/dma
>  trace-events-subdirs += hw/hppa
>  trace-events-subdirs += hw/i2c
> @@ -183,12 +186,8 @@ trace-events-subdirs += migration
>  trace-events-subdirs += net
>  trace-events-subdirs += ui
>  endif
> -trace-events-subdirs += io
> -trace-events-subdirs += linux-user
> -trace-events-subdirs += nbd
>  trace-events-subdirs += qapi
>  trace-events-subdirs += qom
> -trace-events-subdirs += scsi
>  trace-events-subdirs += target/arm
>  trace-events-subdirs += target/hppa
>  trace-events-subdirs += target/i386
> diff --git a/tests/Makefile.include b/tests/Makefile.include
> index 852f17b8c79c..c147182fb052 100644
> --- a/tests/Makefile.include
> +++ b/tests/Makefile.include
> @@ -45,7 +45,6 @@ SYSEMU_TARGET_LIST := $(subst -softmmu.mak,,$(notdir \
>
>  check-unit-y += tests/check-qdict$(EXESUF)
>  check-unit-y += tests/check-block-qdict$(EXESUF)
> -check-unit-y += tests/test-char$(EXESUF)
>  check-unit-y += tests/check-qnum$(EXESUF)
>  check-unit-y += tests/check-qstring$(EXESUF)
>  check-unit-y += tests/check-qlist$(EXESUF)
> @@ -61,9 +60,12 @@ check-unit-y += tests/test-string-input-visitor$(EXESUF)
>  check-unit-y += tests/test-string-output-visitor$(EXESUF)
>  check-unit-y += tests/test-qmp-event$(EXESUF)
>  check-unit-y += tests/test-opts-visitor$(EXESUF)
> -check-unit-y += tests/test-coroutine$(EXESUF)
>  check-unit-y += tests/test-visitor-serialization$(EXESUF)
>  check-unit-y += tests/test-iov$(EXESUF)
> +check-unit-y += tests/test-x86-cpuid$(EXESUF)
> +ifneq ($(CONFIG_USER_ONLY),y)
> +check-unit-y += tests/test-char$(EXESUF)
> +check-unit-y += tests/test-coroutine$(EXESUF)
>  check-unit-y += tests/test-aio$(EXESUF)
>  check-unit-y += tests/test-aio-multithread$(EXESUF)
>  check-unit-y += tests/test-throttle$(EXESUF)
> @@ -76,7 +78,7 @@ check-unit-y += tests/test-blockjob-txn$(EXESUF)
>  check-unit-y += tests/test-block-backend$(EXESUF)
>  check-unit-y += tests/test-block-iothread$(EXESUF)
>  check-unit-y += tests/test-image-locking$(EXESUF)
> -check-unit-y += tests/test-x86-cpuid$(EXESUF)
> +endif
>  # all code tested by test-x86-cpuid is inside topology.h
>  ifeq ($(CONFIG_SOFTMMU),y)
>  check-unit-y += tests/test-xbzrle$(EXESUF)
> @@ -101,6 +103,14 @@ check-unit-y += tests/check-qom-interface$(EXESUF)
>  check-unit-y += tests/check-qom-proplist$(EXESUF)
>  check-unit-y += tests/test-qemu-opts$(EXESUF)
>  check-unit-y

Re: [Qemu-devel] [PATCH 2/4] ui: build keymap only with softmmu targets

2019-03-21 Thread Philippe Mathieu-Daudé
Le jeu. 21 mars 2019 13:50, Laurent Vivier  a écrit :

> we don't need to generate the files for linux-user or for the tools
>
> Signed-off-by: Laurent Vivier 
> ---
>  Makefile | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index d8dad39c5db1..609fac844637 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -261,6 +261,7 @@ trace-dtrace-root.o: trace-dtrace-root.dtrace
>  KEYCODEMAP_GEN = $(SRC_PATH)/ui/keycodemapdb/tools/keymap-gen
>  KEYCODEMAP_CSV = $(SRC_PATH)/ui/keycodemapdb/data/keymaps.csv
>
> +ifdef CONFIG_SOFTMMU
>  KEYCODEMAP_FILES = \
>  ui/input-keymap-atset1-to-qcode.c \
>  ui/input-keymap-linux-to-qcode.c \
> @@ -295,6 +296,7 @@ ui/input-keymap-%.c: $(KEYCODEMAP_GEN)
> $(KEYCODEMAP_CSV) $(SRC_PATH)/ui/Makefile
>
>  $(KEYCODEMAP_GEN): .git-submodule-status
>  $(KEYCODEMAP_CSV): .git-submodule-status
> +endif
>
>  # Don't try to regenerate Makefile or configure
>  # We don't generate any of them
> --
> 2.20.1
>


Reviewed-by: Philippe Mathieu-Daudé 

>


Re: [Qemu-devel] [PULL 0/1] Qcrypto next patches

2019-03-21 Thread Peter Maydell
On Thu, 21 Mar 2019 at 12:07, Daniel P. Berrangé  wrote:
>
> The following changes since commit 6532dcebb6160f94b6b278af5e73784164c669f6:
>
>   Merge remote-tracking branch 'remotes/berrange/tags/qio-next-pull-request' 
> into staging (2019-03-21 09:33:11 +)
>
> are available in the Git repository at:
>
>   https://github.com/berrange/qemu tags/qcrypto-next-pull-request
>
> for you to fetch changes up to 5993e3be1d9ff5395c0b753c638760bff4a8360f:
>
>   crypto/block: remove redundant struct packing to fix build with gcc 9 
> (2019-03-21 11:54:38 +)
>
> 
> Avoid struct packing warnings with gcc9
>
> 
>
> Greg Kurz (1):
>   crypto/block: remove redundant struct packing to fix build with gcc 9
>
>  crypto/block-luks.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.0
for any user-visible changes.

-- PMM



Re: [Qemu-devel] [PULL v3 00/54] Kconfig conversion, excluding ARM and MIPS

2019-03-21 Thread Peter Maydell
On Thu, 21 Mar 2019 at 12:40, Laszlo Ersek  wrote:
> In brief, the regression is that the aarch64 system emulator now lists
> the "virtio-vga" device for the "virt" machine type:
>
> $ qemu-system-aarch64 -M virt -device \? | grep virtio-vga
> name "virtio-vga", bus PCI
>
> Here's where I think the issue was introduced:
>
> (1) In commit 82f5181777eb ("kconfig: introduce kconfig files",
> 2019-03-07), VIRTIO_VGA was introduced simply as a bool (with no other
> clauses) in "hw/display/Kconfig".
>
> (2) In commit 7c28b925b7e1 ("build: convert pci.mak to Kconfig",
> 2019-03-07), VIRTIO_VGA received the following clauses:
>
> default y if PCI_DEVICES
> depends on VIRTIO_PCI
> select VGA
>
> This is too lax, because it permits virtio-vga for aarch64, while that
> shouldn't happen (and it doesn't matches the previous state of the tree).
>
> (3) In commit b42075bb7767 ("virtio: express virtio dependencies with
> Kconfig", 2019-03-07), the determination of virtio-vga was switched to
> the Kconfig system. Importantly, in this patch, the line
>
>   CONFIG_VIRTIO_VGA=y
>
> was removed *only* from the following file:
>
>   default-configs/i386-softmmu.mak
>
> (4) Both of the remaining instances of
>
>   CONFIG_VIRTIO_VGA=y
>
> were then removed in commit 9483cf27dd36 ("hppa-softmmu.mak: express
> dependencies with Kconfig", 2019-03-07) and commit 87f9108bad0c ("ppc64:
> Express dependencies of 'pseries' and 'powernv' machines with kconfig",
> 2019-03-07), from files
>
>   default-configs/hppa-softmmu.mak
>   default-configs/ppc64-softmmu.mak
>
> respectively.
>
>
> Therefore I think commit 7c28b925b7e1 has the bug. The VIRTIO_VGA
> restriction
>
>   depends on VIRTIO_PCI
>
> should now be replaced with
>
>   depends on VIRTIO_PCI && (PC || DINO || PSERIES)

Should it? What makes the virtio-vga device only
suitable for those three machines?

thanks
-- PMM



Re: [Qemu-devel] [PATCH 6/8] hw/acpi/Kconfig: Introduce the ACPI_PIIX4 config

2019-03-21 Thread Igor Mammedov
On Tue, 19 Mar 2019 23:47:22 +0100 (CET)
BALATON Zoltan  wrote:

> On Tue, 19 Mar 2019, Igor Mammedov wrote:
> > On Sun, 17 Mar 2019 01:22:57 +0100
> > Philippe Mathieu-Daudé  wrote:
> >  
> >> The PIIX4 chipset is a generic southbridge and can be used by
> >> non-X86 hardware. Introduce the ACPI_PIIX4 Kconfig.
> >> Hardware that requires ACPI but doesn't need the PIIX4 chipset
> >> won't compile it.  
> > I know that mips somewhat depends on piix but does it actually
> > implements, uses or plans to use ACPI in practice?  
> 
> I think it does not compile without due to PIIX depends on it. Likewise 
yep, looks like for piix_pm we need to pull in pci/cpu/mem and nvdimm
stuff even if it's not going to be used 

> for VT82C686. I get errors about undefined functions when linking a 
> ppc board using it (not yet upstream) without this patch:
> http://patchwork.ozlabs.org/patch/1054018/
> 
> ../hw/isa/vt82c686.o: In function `vt82c686b_pm_realize':
> hw/isa/vt82c686.c:375: undefined reference to `apm_init'
> hw/isa/vt82c686.c:381: undefined reference to `acpi_pm_tmr_init'
> hw/isa/vt82c686.c:382: undefined reference to `acpi_pm1_evt_init'
> ../hw/isa/vt82c686.o: In function `pm_update_sci':
> hw/isa/vt82c686.c:195: undefined reference to `acpi_pm1_evt_get_sts'
> ../hw/isa/vt82c686.o: In function `vt82c686b_pm_realize':
> hw/isa/vt82c686.c:383: undefined reference to `acpi_pm1_cnt_init'
> ../hw/isa/vt82c686.o: In function `pm_update_sci':
> hw/isa/vt82c686.c:203: undefined reference to `acpi_pm_tmr_update'

If you a going to reuse vt82c686 then following patch should help


diff --git a/default-configs/mips-softmmu-common.mak 
b/default-configs/mips-softmmu-common.mak
index 0795d52..9c2cf15 100644
--- a/default-configs/mips-softmmu-common.mak
+++ b/default-configs/mips-softmmu-common.mak
@@ -16,10 +16,11 @@ CONFIG_PCSPK=y
 CONFIG_PCKBD=y
 CONFIG_FDC=y
 CONFIG_ACPI=y
-CONFIG_ACPI_X86=y
-CONFIG_ACPI_MEMORY_HOTPLUG=y
-CONFIG_ACPI_NVDIMM=y
-CONFIG_ACPI_CPU_HOTPLUG=y
+CONFIG_ACPI_GENERIC_HW=y
+#CONFIG_ACPI_X86=y
+#CONFIG_ACPI_MEMORY_HOTPLUG=y
+#CONFIG_ACPI_NVDIMM=y
+#CONFIG_ACPI_CPU_HOTPLUG=y
 CONFIG_APM=y
 CONFIG_I8257=y
 CONFIG_PIIX4=y
diff --git a/dtc b/dtc
--- a/dtc
+++ b/dtc
@@ -1 +1 @@
-Subproject commit 88f18909db731a627456f26d779445f84e449536
+Subproject commit 88f18909db731a627456f26d779445f84e449536-dirty
diff --git a/hw/acpi/Kconfig b/hw/acpi/Kconfig
index eca3bee..319707f 100644
--- a/hw/acpi/Kconfig
+++ b/hw/acpi/Kconfig
@@ -4,10 +4,14 @@ config ACPI
 config ACPI_X86
 bool
 select ACPI
+select ACPI_GENERIC_HW
 select ACPI_NVDIMM
 select ACPI_CPU_HOTPLUG
 select ACPI_MEMORY_HOTPLUG
 
+config ACPI_GENERIC_HW
+bool
+
 config ACPI_X86_ICH
 bool
 select ACPI_X86
diff --git a/hw/acpi/Makefile.objs b/hw/acpi/Makefile.objs
index ba93c5b..2b524bd 100644
--- a/hw/acpi/Makefile.objs
+++ b/hw/acpi/Makefile.objs
@@ -1,12 +1,13 @@
 ifeq ($(CONFIG_ACPI),y)
-common-obj-$(CONFIG_ACPI_X86) += core.o piix4.o pcihp.o
+common-obj-$(CONFIG_ACPI_GENERIC_HW) += core.o
+common-obj-$(CONFIG_ACPI_X86) += piix4.o pcihp.o
 common-obj-$(CONFIG_ACPI_X86_ICH) += ich9.o tco.o
 common-obj-$(CONFIG_ACPI_CPU_HOTPLUG) += cpu_hotplug.o
 common-obj-$(CONFIG_ACPI_MEMORY_HOTPLUG) += memory_hotplug.o
 common-obj-$(CONFIG_ACPI_CPU_HOTPLUG) += cpu.o
 common-obj-$(CONFIG_ACPI_NVDIMM) += nvdimm.o
 common-obj-$(CONFIG_ACPI_VMGENID) += vmgenid.o
-common-obj-$(call lnot,$(CONFIG_ACPI_X86)) += acpi-stub.o
+common-obj-$(call lnot,$(CONFIG_ACPI_GENERIC_HW)) += acpi-stub.o
 
 common-obj-y += acpi_interface.o
 common-obj-y += bios-linker-loader.o


> ../hw/isa/vt82c686.o:(.data.rel+0x370): undefined reference to `vmstate_apm'
> collect2: error: ld returned 1 exit status

for that you need to include CONFIG_APM

> 
> Regards,
> BALATON Zoltan
> 
> >> Signed-off-by: Philippe Mathieu-Daudé 
> >> ---
> >>  default-configs/mips-softmmu-common.mak | 2 +-
> >>  hw/acpi/Kconfig | 7 +++
> >>  hw/acpi/Makefile.objs   | 3 ++-
> >>  hw/i386/Kconfig | 2 ++
> >>  4 files changed, 12 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/default-configs/mips-softmmu-common.mak 
> >> b/default-configs/mips-softmmu-common.mak
> >> index 6f49a3a8c7..21c6e3cbe3 100644
> >> --- a/default-configs/mips-softmmu-common.mak
> >> +++ b/default-configs/mips-softmmu-common.mak
> >> @@ -16,7 +16,7 @@ CONFIG_PCSPK=y
> >>  CONFIG_I8042=y
> >>  CONFIG_FDC=y
> >>  CONFIG_ACPI=y
> >> -CONFIG_ACPI_X86=y
> >> +CONFIG_ACPI_PIIX4=y
> >>  CONFIG_ACPI_MEMORY_HOTPLUG=y
> >>  CONFIG_ACPI_NVDIMM=y
> >>  CONFIG_ACPI_CPU_HOTPLUG=y
> >> diff --git a/hw/acpi/Kconfig b/hw/acpi/Kconfig
> >> index b18ddb06da..10f24f3b41 100644
> >> --- a/hw/acpi/Kconfig
> >> +++ b/hw/acpi/Kconfig
> >> @@ -8,6 +8,13 @@ config ACPI_X86
> >>  select ACPI_CPU_HOTPLUG
> >>  select ACPI_MEMORY_HOTPLUG
> >>
> >> +config ACPI_PIIX4
> >> +bool
> >> +select ACPI
> >> +select ACPI_NVDIMM
> >> +select ACPI_CPU

Re: [Qemu-devel] [PATCH] json: Fix off-by-one assert check in next_state()

2019-03-21 Thread Li Qiang
Liam Merwick  于2019年3月21日周四 下午8:04写道:

> The assert checking if the value of lexer->state in next_state(),
> which is used as an index to the 'json_lexer' array, incorrectly
> checks for an index value less than or equal to ARRAY_SIZE(json_lexer).
> Fix assert so that it just checks for an index less than the array size.
>
> Signed-off-by: Liam Merwick 
>

Reviewed-by: Li Qiang 


> ---
>  qobject/json-lexer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/qobject/json-lexer.c b/qobject/json-lexer.c
> index a7df2093aa30..632320d72d5d 100644
> --- a/qobject/json-lexer.c
> +++ b/qobject/json-lexer.c
> @@ -266,7 +266,7 @@ static inline uint8_t next_state(JSONLexer *lexer,
> char ch, bool flush,
>  {
>  uint8_t next;
>
> -assert(lexer->state <= ARRAY_SIZE(json_lexer));
> +assert(lexer->state < ARRAY_SIZE(json_lexer));
>  next = json_lexer[lexer->state][(uint8_t)ch];
>  *char_consumed = !flush && !(next & LOOKAHEAD);
>  return next & ~LOOKAHEAD;
> --
> 1.8.3.1
>
>
>


Re: [Qemu-devel] [PATCH v4] hw/acpi: extract acpi_add_rom_blob()

2019-03-21 Thread Igor Mammedov
On Thu, 21 Mar 2019 08:21:53 +0800
Wei Yang  wrote:

> arm and i386 has almost the same function acpi_add_rom_blob(), except
> giving different FWCfgCallback function.
> 
> This patch moves acpi_add_rom_blob() to utils.c by passing
> FWCfgCallback to it.
> 
> Signed-off-by: Wei Yang 
> 
> ---
> v4:
>   * extract -> moves
>   * adjust comment in source to make checkpatch happy
> v3:
>   * put acpi_add_rom_blob() to hw/acpi/utils.c
> v2:
>   * remove unused header in original source file
> ---
>  hw/acpi/Makefile.objs|  2 +-
>  hw/acpi/utils.c  | 36 
>  hw/arm/virt-acpi-build.c | 26 ++
>  hw/i386/acpi-build.c | 26 ++
>  include/hw/acpi/utils.h  |  9 +
>  5 files changed, 66 insertions(+), 33 deletions(-)
>  create mode 100644 hw/acpi/utils.c
>  create mode 100644 include/hw/acpi/utils.h
> 
> diff --git a/hw/acpi/Makefile.objs b/hw/acpi/Makefile.objs
> index 2d46e3789a..ba93c5b64a 100644
> --- a/hw/acpi/Makefile.objs
> +++ b/hw/acpi/Makefile.objs
> @@ -10,7 +10,7 @@ common-obj-$(call lnot,$(CONFIG_ACPI_X86)) += acpi-stub.o
>  
>  common-obj-y += acpi_interface.o
>  common-obj-y += bios-linker-loader.o
> -common-obj-y += aml-build.o
> +common-obj-y += aml-build.o utils.o
>  common-obj-$(CONFIG_TPM) += tpm.o
>  
>  common-obj-$(CONFIG_IPMI) += ipmi.o
> diff --git a/hw/acpi/utils.c b/hw/acpi/utils.c
> new file mode 100644
> index 00..9747996c8c
> --- /dev/null
> +++ b/hw/acpi/utils.c
> @@ -0,0 +1,36 @@
> +/*
> + * Utilities for generating ACPI tables and passing them to Guests
> + *
> + * Copyright (C) 2019 Intel Corporation
> + * Copyright (C) 2019 Red Hat Inc
> + *
> + * Author: Wei Yang 
> + * Author: Igor Mammedov 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> +
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> +
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, see .
> + */
> +
> +#include "qemu/osdep.h"

> +#include 
is it necessary?

> +#include "hw/acpi/aml-build.h"
> +#include "hw/acpi/utils.h"


> +
> +MemoryRegion *acpi_add_rom_blob(FWCfgCallback update, void *opaque,
> +GArray *blob, const char *name,
> +uint64_t max_size)
> +{
> +return rom_add_blob(name, blob->data, acpi_data_len(blob), max_size, -1,
> +name, update, opaque, NULL, true);
> +}
> +
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 57679a89bf..a846f74a14 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -37,9 +37,9 @@
>  #include "hw/acpi/acpi.h"
>  #include "hw/nvram/fw_cfg.h"
>  #include "hw/acpi/bios-linker-loader.h"
> -#include "hw/loader.h"
>  #include "hw/hw.h"
>  #include "hw/acpi/aml-build.h"
> +#include "hw/acpi/utils.h"
>  #include "hw/pci/pcie_host.h"
>  #include "hw/pci/pci.h"
>  #include "hw/arm/virt.h"
> @@ -881,14 +881,6 @@ static void virt_acpi_build_reset(void *build_opaque)
>  build_state->patched = false;
>  }
>  
> -static MemoryRegion *acpi_add_rom_blob(AcpiBuildState *build_state,
> -   GArray *blob, const char *name,
> -   uint64_t max_size)
> -{
> -return rom_add_blob(name, blob->data, acpi_data_len(blob), max_size, -1,
> -name, virt_acpi_build_update, build_state, NULL, 
> true);
> -}
> -
>  static const VMStateDescription vmstate_virt_acpi_build = {
>  .name = "virt_acpi_build",
>  .version_id = 1,
> @@ -920,20 +912,22 @@ void virt_acpi_setup(VirtMachineState *vms)
>  virt_acpi_build(vms, &tables);
>  
>  /* Now expose it all to Guest */
> -build_state->table_mr = acpi_add_rom_blob(build_state, tables.table_data,
> -   ACPI_BUILD_TABLE_FILE,
> -   ACPI_BUILD_TABLE_MAX_SIZE);
> +build_state->table_mr = acpi_add_rom_blob(virt_acpi_build_update,
> +  build_state, tables.table_data,
> +  ACPI_BUILD_TABLE_FILE,
> +  ACPI_BUILD_TABLE_MAX_SIZE);
>  assert(build_state->table_mr != NULL);
>  
>  build_state->linker_mr =
> -acpi_add_rom_blob(build_state, tables.linker->cmd_blob,
> -  "etc/table-loader", 0);
> +acpi_add_rom_blob(virt_acpi_build_update, build_

Re: [Qemu-devel] [PATCH v1 1/3] configure: add --target-list-exclude

2019-03-21 Thread Alex Bennée


Thomas Huth  writes:

> On 19/03/2019 13.47, Alex Bennée wrote:
>> This is an inverse selection which excludes a selected set of targets
>> from the default target list. It will mostly be useful for CI
>> configurations but it might be useful for some users as well.
>
> This will be useful for me, too! For my local builds, I normally drop
> some few targets (e.g. the "duplicated" endianess targets like
> "armeb-linux-user", since I build "arm-linux-user" already), to speed up
> the compilation process a little bit. This will be much easier with this
> new option when I've got to re-run configure again...
>
>> +if test -z "$target_list_exclude"; then
>> +echo "defaults: $target_list_exclude"
>
> That echo line looks like a debug left-over. Remove it?

Oops, yes, will fix.

>
> Apart from that:
>
> Reviewed-by: Thomas Huth 

Thanks.

--
Alex Bennée



Re: [Qemu-devel] [PULL 0/1] Authz next patches

2019-03-21 Thread Peter Maydell
On Thu, 21 Mar 2019 at 12:11, Daniel P. Berrangé  wrote:
>
> The following changes since commit 62a172e6a77d9072bb1a18f295ce0fcf4b90a4f2:
>
>   Update version for v4.0.0-rc0 release (2019-03-19 17:17:22 +)
>
> are available in the Git repository at:
>
>   https://github.com/berrange/qemu tags/authz-next-pull-request
>
> for you to fetch changes up to 063603d43ec428c1acc63c4e1f8593a7b6d164f1:
>
>   authz: Use OBJECT_CHECK() on objects (2019-03-21 11:52:37 +)
>
> 
> Fix object interface check macro usage
>
Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.0
for any user-visible changes.

-- PMM



Re: [Qemu-devel] [PATCH] json: Fix off-by-one assert check in next_state()

2019-03-21 Thread Markus Armbruster
Liam Merwick  writes:

> The assert checking if the value of lexer->state in next_state(),
> which is used as an index to the 'json_lexer' array, incorrectly
> checks for an index value less than or equal to ARRAY_SIZE(json_lexer).
> Fix assert so that it just checks for an index less than the array size.
>
> Signed-off-by: Liam Merwick 
> ---
>  qobject/json-lexer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/qobject/json-lexer.c b/qobject/json-lexer.c
> index a7df2093aa30..632320d72d5d 100644
> --- a/qobject/json-lexer.c
> +++ b/qobject/json-lexer.c
> @@ -266,7 +266,7 @@ static inline uint8_t next_state(JSONLexer *lexer, char 
> ch, bool flush,
>  {
>  uint8_t next;
>  
> -assert(lexer->state <= ARRAY_SIZE(json_lexer));
> +assert(lexer->state < ARRAY_SIZE(json_lexer));
>  next = json_lexer[lexer->state][(uint8_t)ch];
>  *char_consumed = !flush && !(next & LOOKAHEAD);
>  return next & ~LOOKAHEAD;

Classic off-by-one.

Reviewed-by: Markus Armbruster 

and queued, thanks!



Re: [Qemu-devel] [PATCH] json: Fix off-by-one assert check in next_state()

2019-03-21 Thread Stefano Garzarella
On Thu, Mar 21, 2019 at 11:57:52AM +, Liam Merwick wrote:
> The assert checking if the value of lexer->state in next_state(),
> which is used as an index to the 'json_lexer' array, incorrectly
> checks for an index value less than or equal to ARRAY_SIZE(json_lexer).
> Fix assert so that it just checks for an index less than the array size.
> 
> Signed-off-by: Liam Merwick 
> ---
>  qobject/json-lexer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Stefano Garzarella 

Thanks,
Stefano



Re: [Qemu-devel] [PATCH 6/8] hw/acpi/Kconfig: Introduce the ACPI_PIIX4 config

2019-03-21 Thread Philippe Mathieu-Daudé
Hi Igor,

Le jeu. 21 mars 2019 14:36, Igor Mammedov  a écrit :

> On Tue, 19 Mar 2019 23:47:22 +0100 (CET)
> BALATON Zoltan  wrote:
>
> > On Tue, 19 Mar 2019, Igor Mammedov wrote:
> > > On Sun, 17 Mar 2019 01:22:57 +0100
> > > Philippe Mathieu-Daudé  wrote:
> > >
> > >> The PIIX4 chipset is a generic southbridge and can be used by
> > >> non-X86 hardware. Introduce the ACPI_PIIX4 Kconfig.
> > >> Hardware that requires ACPI but doesn't need the PIIX4 chipset
> > >> won't compile it.
> > > I know that mips somewhat depends on piix but does it actually
> > > implements, uses or plans to use ACPI in practice?


Linux PIIX driver is generic. But Linux Malta works without configuring it
too. We loose power saving features.


> >
> > I think it does not compile without due to PIIX depends on it. Likewise
> yep, looks like for piix_pm we need to pull in pci/cpu/mem and nvdimm
> stuff even if it's not going to be used
>
> > for VT82C686. I get errors about undefined functions when linking a
> > ppc board using it (not yet upstream) without this patch:
> > http://patchwork.ozlabs.org/patch/1054018/
> >
> > ../hw/isa/vt82c686.o: In function `vt82c686b_pm_realize':
> > hw/isa/vt82c686.c:375: undefined reference to `apm_init'
> > hw/isa/vt82c686.c:381: undefined reference to `acpi_pm_tmr_init'
> > hw/isa/vt82c686.c:382: undefined reference to `acpi_pm1_evt_init'
> > ../hw/isa/vt82c686.o: In function `pm_update_sci':
> > hw/isa/vt82c686.c:195: undefined reference to `acpi_pm1_evt_get_sts'
> > ../hw/isa/vt82c686.o: In function `vt82c686b_pm_realize':
> > hw/isa/vt82c686.c:383: undefined reference to `acpi_pm1_cnt_init'
> > ../hw/isa/vt82c686.o: In function `pm_update_sci':
> > hw/isa/vt82c686.c:203: undefined reference to `acpi_pm_tmr_update'
>
> If you a going to reuse vt82c686 then following patch should help
>
>
> diff --git a/default-configs/mips-softmmu-common.mak
> b/default-configs/mips-softmmu-common.mak
> index 0795d52..9c2cf15 100644
> --- a/default-configs/mips-softmmu-common.mak
> +++ b/default-configs/mips-softmmu-common.mak
> @@ -16,10 +16,11 @@ CONFIG_PCSPK=y
>  CONFIG_PCKBD=y
>  CONFIG_FDC=y
>  CONFIG_ACPI=y
> -CONFIG_ACPI_X86=y
> -CONFIG_ACPI_MEMORY_HOTPLUG=y
> -CONFIG_ACPI_NVDIMM=y
> -CONFIG_ACPI_CPU_HOTPLUG=y
> +CONFIG_ACPI_GENERIC_HW=y
> +#CONFIG_ACPI_X86=y
> +#CONFIG_ACPI_MEMORY_HOTPLUG=y
> +#CONFIG_ACPI_NVDIMM=y
> +#CONFIG_ACPI_CPU_HOTPLUG=y
>  CONFIG_APM=y
>  CONFIG_I8257=y
>  CONFIG_PIIX4=y
> diff --git a/dtc b/dtc
> --- a/dtc
> +++ b/dtc
> @@ -1 +1 @@
> -Subproject commit 88f18909db731a627456f26d779445f84e449536
> +Subproject commit 88f18909db731a627456f26d779445f84e449536-dirty
> diff --git a/hw/acpi/Kconfig b/hw/acpi/Kconfig
> index eca3bee..319707f 100644
> --- a/hw/acpi/Kconfig
> +++ b/hw/acpi/Kconfig
> @@ -4,10 +4,14 @@ config ACPI
>  config ACPI_X86
>  bool
>  select ACPI
> +select ACPI_GENERIC_HW
>  select ACPI_NVDIMM
>  select ACPI_CPU_HOTPLUG
>  select ACPI_MEMORY_HOTPLUG
>
> +config ACPI_GENERIC_HW
> +bool
> +
>  config ACPI_X86_ICH
>  bool
>  select ACPI_X86
> diff --git a/hw/acpi/Makefile.objs b/hw/acpi/Makefile.objs
> index ba93c5b..2b524bd 100644
> --- a/hw/acpi/Makefile.objs
> +++ b/hw/acpi/Makefile.objs
> @@ -1,12 +1,13 @@
>  ifeq ($(CONFIG_ACPI),y)
> -common-obj-$(CONFIG_ACPI_X86) += core.o piix4.o pcihp.o
> +common-obj-$(CONFIG_ACPI_GENERIC_HW) += core.o
> +common-obj-$(CONFIG_ACPI_X86) += piix4.o pcihp.o
>  common-obj-$(CONFIG_ACPI_X86_ICH) += ich9.o tco.o
>  common-obj-$(CONFIG_ACPI_CPU_HOTPLUG) += cpu_hotplug.o
>  common-obj-$(CONFIG_ACPI_MEMORY_HOTPLUG) += memory_hotplug.o
>  common-obj-$(CONFIG_ACPI_CPU_HOTPLUG) += cpu.o
>  common-obj-$(CONFIG_ACPI_NVDIMM) += nvdimm.o
>  common-obj-$(CONFIG_ACPI_VMGENID) += vmgenid.o
> -common-obj-$(call lnot,$(CONFIG_ACPI_X86)) += acpi-stub.o
> +common-obj-$(call lnot,$(CONFIG_ACPI_GENERIC_HW)) += acpi-stub.o
>
>  common-obj-y += acpi_interface.o
>  common-obj-y += bios-linker-loader.o
>
>
> > ../hw/isa/vt82c686.o:(.data.rel+0x370): undefined reference to
> `vmstate_apm'
> > collect2: error: ld returned 1 exit status
>
> for that you need to include CONFIG_APM
>
> >
> > Regards,
> > BALATON Zoltan
> >
> > >> Signed-off-by: Philippe Mathieu-Daudé 
> > >> ---
> > >>  default-configs/mips-softmmu-common.mak | 2 +-
> > >>  hw/acpi/Kconfig | 7 +++
> > >>  hw/acpi/Makefile.objs   | 3 ++-
> > >>  hw/i386/Kconfig | 2 ++
> > >>  4 files changed, 12 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/default-configs/mips-softmmu-common.mak
> b/default-configs/mips-softmmu-common.mak
> > >> index 6f49a3a8c7..21c6e3cbe3 100644
> > >> --- a/default-configs/mips-softmmu-common.mak
> > >> +++ b/default-configs/mips-softmmu-common.mak
> > >> @@ -16,7 +16,7 @@ CONFIG_PCSPK=y
> > >>  CONFIG_I8042=y
> > >>  CONFIG_FDC=y
> > >>  CONFIG_ACPI=y
> > >> -CONFIG_ACPI_X86=y
> > >> +CONFIG_ACPI_PIIX4=y
> > >>  CONFIG_ACPI_MEMORY_HOTPLUG=y
> > >>  CONFIG_ACPI_

Re: [Qemu-devel] [PULL v3 00/54] Kconfig conversion, excluding ARM and MIPS

2019-03-21 Thread Philippe Mathieu-Daudé
Le jeu. 21 mars 2019 13:39, Laszlo Ersek  a écrit :

> On 03/21/19 01:53, Laszlo Ersek wrote:
> > Hi Paolo,
> >
> > (+libvir-list)
> >
> > I'd like to report a regression introduced by this patch set:
> >
> > On 03/07/19 21:58, Paolo Bonzini wrote:
> >> The following changes since commit
> >> 6cb4f6db4f4367faa33da85b15f75bbbd2bed2a6:
> >>
> >>   Merge remote-tracking branch
> >>   'remotes/cleber/tags/python-next-pull-request' into staging
> >>   (2019-03-07 16:16:02 +)
> >>
> >> are available in the Git repository at:
> >>
> >>   git://github.com/bonzini/qemu.git tags/for-upstream-kconfig
> >>
> >> for you to fetch changes up to
> >> 576c3f2f16e7392e28cc9fe10d9a920d67d3645b:
> >>
> >>   kconfig: add documentation (2019-03-07 21:54:22 +0100)
> >>
> >> 
> >> Initial Kconfig work, excluding ARM and MIPS
> >>
> >> 
> >
>
> In brief, the regression is that the aarch64 system emulator now lists
> the "virtio-vga" device for the "virt" machine type:
>
> $ qemu-system-aarch64 -M virt -device \? | grep virtio-vga
> name "virtio-vga", bus PCI
>
> Here's where I think the issue was introduced:
>
> (1) In commit 82f5181777eb ("kconfig: introduce kconfig files",
> 2019-03-07), VIRTIO_VGA was introduced simply as a bool (with no other
> clauses) in "hw/display/Kconfig".
>
> (2) In commit 7c28b925b7e1 ("build: convert pci.mak to Kconfig",
> 2019-03-07), VIRTIO_VGA received the following clauses:
>
> default y if PCI_DEVICES
> depends on VIRTIO_PCI
> select VGA
>
> This is too lax, because it permits virtio-vga for aarch64, while that
> shouldn't happen (and it doesn't matches the previous state of the tree).
>

Similar case I noticed in another thread. The Virt machine uses a chipset
that provides PCI. Does this machine expose PCI slots? If yes, this config
is correct, the machine can get any PCI daughter card. Else we shouldn't
use PCI_DEVICES that way.

Why Virt machine now default to virtio-vga?


> (3) In commit b42075bb7767 ("virtio: express virtio dependencies with
> Kconfig", 2019-03-07), the determination of virtio-vga was switched to
> the Kconfig system. Importantly, in this patch, the line
>
>   CONFIG_VIRTIO_VGA=y
>
> was removed *only* from the following file:
>
>   default-configs/i386-softmmu.mak
>
> (4) Both of the remaining instances of
>
>   CONFIG_VIRTIO_VGA=y
>
> were then removed in commit 9483cf27dd36 ("hppa-softmmu.mak: express
> dependencies with Kconfig", 2019-03-07) and commit 87f9108bad0c ("ppc64:
> Express dependencies of 'pseries' and 'powernv' machines with kconfig",
> 2019-03-07), from files
>
>   default-configs/hppa-softmmu.mak
>   default-configs/ppc64-softmmu.mak
>
> respectively.
>
>
> Therefore I think commit 7c28b925b7e1 has the bug. The VIRTIO_VGA
> restriction
>
>   depends on VIRTIO_PCI
>
> should now be replaced with
>
>   depends on VIRTIO_PCI && (PC || DINO || PSERIES)
>
> Thanks
> Laszlo
>
>


  1   2   3   >