Re: [PULL 06/15] configure: Enable test and libs for zstd

2020-03-02 Thread Juan Quintela
Richard Henderson  wrote:
>> +##
>> +# zstd check
>> +
>> +if test "$zstd" != "no" ; then
>> +if $pkg_config --exist libzstd ; then
>
> The option is spelled --exists.  This is generating an error during configure.

Ooops, you are right.

Sending a patch.  Just wondering why I didn't saw that error :-(

Thanks, Juan.




Re: [PATCH v3] i386: Fix GCC warning with snprintf when HAX is enabled

2020-03-02 Thread Paolo Bonzini
On 02/03/20 02:58, Julio Faracco wrote:
> Sorry my ignorance, Paolo.
> But why should I remove MAX_{VM,VCPU}_ID?
> 
> Did you mean that check?
> if (vm_id > MAX_VM_ID || vcpu_id > MAX_VCPU_ID) {
> fprintf(stderr, "Too big vm id %x or vcpu id %x\n", vm_id, vcpu_id);
> return NULL;
> }
> 
> Wouldn't it be dangerous?

No, the check is only needed to avoid the buffer truncation from
snprintf.  If you use g_strdup_printf it's not needed anymore because
there can be no truncation.

Paolo




Re: [PATCH 1/2] ide: Make room for flags in PCIIDEState and add one for legacy IRQ routing

2020-03-02 Thread Markus Armbruster
BALATON Zoltan  writes:

> On Sun, 1 Mar 2020, Mark Cave-Ayland wrote:
>> On 29/02/2020 23:02, BALATON Zoltan wrote:
>>> We'll need a flag for implementing some device specific behaviour in
>>> via-ide but we already have a currently CMD646 specific field that can
>>> be repurposed for this and leave room for furhter flags if needed in
>>> the future. This patch changes the "secondary" field to "flags" and
>>> define the flags for CMD646 and via-ide and change CMD646 and its
>>> users accordingly.
>>>
>>> Signed-off-by: BALATON Zoltan 
>>> ---
>>>  hw/alpha/dp264.c |  2 +-
>>>  hw/ide/cmd646.c  | 12 ++--
>>>  hw/sparc64/sun4u.c   |  9 ++---
>>>  include/hw/ide.h |  4 ++--
>>>  include/hw/ide/pci.h |  7 ++-
>>>  5 files changed, 17 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/hw/alpha/dp264.c b/hw/alpha/dp264.c
[...]
>>> @@ -317,20 +317,20 @@ static void pci_cmd646_ide_exitfn(PCIDevice *dev)
>>>  }
>>>  }
>>>
>>> -void pci_cmd646_ide_init(PCIBus *bus, DriveInfo **hd_table,
>>> - int secondary_ide_enabled)
>>> +void pci_cmd646_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn,
>>> + bool secondary_ide_enabled)
>>>  {
>>>  PCIDevice *dev;
>>>
>>> -dev = pci_create(bus, -1, "cmd646-ide");
>>> -qdev_prop_set_uint32(&dev->qdev, "secondary", secondary_ide_enabled);
>>> +dev = pci_create(bus, devfn, "cmd646-ide");
>>> +qdev_prop_set_bit(&dev->qdev, "secondary", secondary_ide_enabled);
>>>  qdev_init_nofail(&dev->qdev);
>>>
>>>  pci_ide_create_devs(dev, hd_table);
>>>  }
>>
>> Note that legacy init functions such as pci_cmd646_ide_init() should be 
>> removed where
>> possible, and in fact I posted a patch last week to completely remove it. 
>> This is
>> because using qdev directly allows each board to wire up the device as 
>> required,
>> rather than pushing it down into a set of init functions with different 
>> defaults.
>>
>> Given that you're working in this area, I'd highly recommend doing the same 
>> for
>> via_ide_init() too.
>
> I could do that, however these ide init functions seem to exist for
> piix, cmd646 and via-ide so that pci_ide_create_devs function is kept
> local to hw/ide. Nothing else called that func apart from sun4u so
> I've chosen this way to keep consistency (also keeps property type at
> one place instead of needing to change each board that sets
> property). If the consensus is that getting rid of these init funcs
> even if that means pci_ide_create_devs will not be local to ide any
> more I can go that way but would like to hear opinion of ide
> maintainer as well.

I think Mark's point is that modelling a device and wiring up a device
model are separate things, and the latter belongs to the board.

pci_cmd646_ide_init() is a helper for boards.  Similar helpers exist
elsewhere.

In the oldest stratum of qdev code, such helpers were static inline
functions in the device model's .h.  That way, they're kind of separate
from the device model proper, in the .c, and kind of in the board code
where they belong, via inlining.  I've always considered that a terrible
idea; it's "kind of" as in "not really".  Over time, practice moved
first to putting the helpers into .c, then to open-coding the wiring
where it belongs: in the boards.

A few helper functions have survived, e.g. in hw/lm32/milkymist-hw.h,
and the IDE helpers we're discussing here.

Of course, when the code to wire up certain devices gets overly
repetitive, factoring out common code into helpers can make sense.  But
where to put them?  I can't see an obvious home for common board
helpers.  We tend to put these wiring helpers into a device model's .c
code for want of a better place.  Tolerable, I think.




Re: [PATCH] hw/smbios: add options for type 4 max_speed and current_speed

2020-03-02 Thread Igor Mammedov
On Sat, 29 Feb 2020 08:17:48 +0800
Heyi Guo  wrote:

> Hi Igor,
> 
> On 2020/2/28 17:39, Igor Mammedov wrote:
> > On Thu, 27 Feb 2020 17:12:21 +0800
> > Heyi Guo  wrote:
> >  
> >> On 2020/2/25 17:24, Philippe Mathieu-Daudé wrote:  
> >>> On 2/25/20 8:50 AM, Heyi Guo wrote:  
>  Common VM users sometimes care about CPU speed, so we add two new
>  options to allow VM vendors to present CPU speed to their users.
>  Normally these information can be fetched from host smbios.
> 
>  Strictly speaking, the "max speed" and "current speed" in type 4
>  are not really for the max speed and current speed of processor, for
>  "max speed" identifies a capability of the system, and "current speed"
>  identifies the processor's speed at boot (see smbios spec), but some
>  applications do not tell the differences.
> 
>  Signed-off-by: Heyi Guo 
> 
>  ---
>  Cc: "Michael S. Tsirkin" 
>  Cc: Igor Mammedov 
>  ---
>     hw/smbios/smbios.c | 22 +++---
>     qemu-options.hx    |  3 ++-
>     2 files changed, 21 insertions(+), 4 deletions(-)
> 
>  diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
>  index ffd98727ee..1d5439643d 100644
>  --- a/hw/smbios/smbios.c
>  +++ b/hw/smbios/smbios.c
>  @@ -94,6 +94,8 @@ static struct {
>       static struct {
>     const char *sock_pfx, *manufacturer, *version, *serial, *asset,
>  *part;
>  +    uint32_t max_speed;
>  +    uint32_t current_speed;
>     } type4;
>       static struct {
>  @@ -272,6 +274,14 @@ static const QemuOptDesc
>  qemu_smbios_type4_opts[] = {
>     .name = "version",
>     .type = QEMU_OPT_STRING,
>     .help = "version number",
>  +    },{
>  +    .name = "max_speed",  
> > I'd suggest to use - instead of _ in option name  
> 
> Thanks for your comments. However I can see other options like 
> "sock_pfx" and "loc_pfx" also use "_" in option names. Should we keep 
> consistent with the context?

For new options one should use '-',
that way we won't have to build wrappers around it if it becomes
a qom property in the future.

> 
> Thanks,
> 
> Heyi
> 
> 
> >  
>  +    .type = QEMU_OPT_NUMBER,
>  +    .help = "max speed in MHz",
>  +    },{
>  +    .name = "current_speed",  
> > ditto
> >  
>  +    .type = QEMU_OPT_NUMBER,
>  +    .help = "speed at system boot in MHz",
>     },{
>     .name = "serial",
>     .type = QEMU_OPT_STRING,
>  @@ -586,9 +596,8 @@ static void
>  smbios_build_type_4_table(MachineState *ms, unsigned instance)
>     SMBIOS_TABLE_SET_STR(4, processor_version_str, type4.version);
>     t->voltage = 0;
>     t->external_clock = cpu_to_le16(0); /* Unknown */
>  -    /* SVVP requires max_speed and current_speed to not be unknown. */
>  -    t->max_speed = cpu_to_le16(2000); /* 2000 MHz */
>  -    t->current_speed = cpu_to_le16(2000); /* 2000 MHz */
>  +    t->max_speed = cpu_to_le16(type4.max_speed);
>  +    t->current_speed = cpu_to_le16(type4.current_speed);
>     t->status = 0x41; /* Socket populated, CPU enabled */
>     t->processor_upgrade = 0x01; /* Other */
>     t->l1_cache_handle = cpu_to_le16(0x); /* N/A */
>  @@ -1129,6 +1138,13 @@ void smbios_entry_add(QemuOpts *opts, Error
>  **errp)
>     save_opt(&type4.serial, opts, "serial");
>     save_opt(&type4.asset, opts, "asset");
>     save_opt(&type4.part, opts, "part");
>  +    /*
>  + * SVVP requires max_speed and current_speed to not be
>  unknown, and
>  + * we set the default value to 2000MHz as we did before.
>  + */
>  +    type4.max_speed = qemu_opt_get_number(opts, "max_speed",
>  2000);
>  +    type4.current_speed = qemu_opt_get_number(opts,
>  "current_speed",
>  +  2000);  
> >>> Maybe check speeds are <= UINT16_MAX else set errp?  
> >> OK; I can do that in the v2. But I would wait for the maintainers to
> >> provide more comments :)
> >>
> >> Thanks,
> >>
> >> Heyi
> >>  
> >>> 
>     return;
>     case 11:
>     qemu_opts_validate(opts, qemu_smbios_type11_opts, &err);
>  diff --git a/qemu-options.hx b/qemu-options.hx
>  index ac315c1ac4..bc9ef0fda8 100644
>  --- a/qemu-options.hx
>  +++ b/qemu-options.hx
>  @@ -2233,6 +2233,7 @@ DEF("smbios", HAS_ARG, QEMU_OPTION_smbios,
>     "    specify SMBIOS type 3 fields\n"
>     "-smbios
>  type=4[,sock_pfx=str][,manufacturer=str][,version=str][,serial=str]\n"
>     "  [,asset=str][,part=str]\n"
>  +    "  [,max_speed=%d][,current_speed=%d]\n"

[PATCH v2 3/4] qcow2: add zstd cluster compression

2020-03-02 Thread Denis Plotnikov
zstd significantly reduces cluster compression time.
It provides better compression performance maintaining
the same level of the compression ratio in comparison with
zlib, which, at the moment, is the only compression
method available.

The performance test results:
Test compresses and decompresses qemu qcow2 image with just
installed rhel-7.6 guest.
Image cluster size: 64K. Image on disk size: 2.2G

The test was conducted with brd disk to reduce the influence
of disk subsystem to the test results.
The results is given in seconds.

compress cmd:
  time ./qemu-img convert -O qcow2 -c -o compression_type=[zlib|zstd]
  src.img [zlib|zstd]_compressed.img
decompress cmd
  time ./qemu-img convert -O qcow2
  [zlib|zstd]_compressed.img uncompressed.img

   compression   decompression
 zlib   zstd   zlib zstd

real 65.5   16.3 (-75 %)1.9  1.6 (-16 %)
user 65.0   15.85.3  2.5
sys   3.30.22.0  2.0

Both ZLIB and ZSTD gave the same compression ratio: 1.57
compressed image size in both cases: 1.4G

Signed-off-by: Denis Plotnikov 
---
 docs/interop/qcow2.txt |  20 +++
 configure  |  29 ++
 qapi/block-core.json   |   3 +-
 block/qcow2-threads.c  | 120 +
 block/qcow2.c  |   7 +++
 5 files changed, 178 insertions(+), 1 deletion(-)

diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt
index 5597e24474..9048114445 100644
--- a/docs/interop/qcow2.txt
+++ b/docs/interop/qcow2.txt
@@ -208,6 +208,7 @@ version 2.
 
 Available compression type values:
 0: zlib 
+1: zstd 
 
 
 === Header padding ===
@@ -575,11 +576,30 @@ Compressed Clusters Descriptor (x = 62 - (cluster_bits - 
8)):
 Another compressed cluster may map to the tail of the final
 sector used by this compressed cluster.
 
+The layout of the compressed data depends on the 
compression
+type used for the image (see compressed cluster layout).
+
 If a cluster is unallocated, read requests shall read the data from the backing
 file (except if bit 0 in the Standard Cluster Descriptor is set). If there is
 no backing file or the backing file is smaller than the image, they shall read
 zeros for all parts that are not covered by the backing file.
 
+=== Compressed Cluster Layout ===
+
+The compressed cluster data has a layout depending on the compression
+type used for the image, as follows:
+
+Compressed data layout for the available compression types:
+data_space_lenght - data chunk length available to store a compressed cluster.
+(for more details see "Compressed Clusters Descriptor")
+x = data_space_length - 1
+
+0:  (default)  zlib :
+Byte  0 -  x: the compressed data content
+  all the space provided used for compressed data
+1:  zstd :
+Byte  0 -  3: the length of compressed data in bytes
+  4 -  x: the compressed data content
 
 == Snapshots ==
 
diff --git a/configure b/configure
index 48d6f89d57..4690a7ea9f 100755
--- a/configure
+++ b/configure
@@ -444,6 +444,7 @@ opengl_dmabuf="no"
 cpuid_h="no"
 avx2_opt=""
 zlib="yes"
+zstd=""
 capstone=""
 lzo=""
 snappy=""
@@ -1371,6 +1372,10 @@ for opt do
   ;;
   --disable-lzfse) lzfse="no"
   ;;
+  --enable-zstd) zstd="yes"
+  ;;
+  --disable-zstd) zstd="no"
+  ;;
   --enable-guest-agent) guest_agent="yes"
   ;;
   --disable-guest-agent) guest_agent="no"
@@ -1829,6 +1834,7 @@ disabled with --disable-FEATURE, default is enabled if 
available:
   (for reading bzip2-compressed dmg images)
   lzfse   support of lzfse compression library
   (for reading lzfse-compressed dmg images)
+  zstdsupport of zstd compression library
   seccomp seccomp support
   coroutine-pool  coroutine freelist (better performance)
   glusterfs   GlusterFS backend
@@ -2453,6 +2459,25 @@ EOF
 fi
 fi
 
+#
+# zstd check
+
+if test "$zstd" != "no" ; then
+cat > $TMPC << EOF
+#include 
+int main(void) { ZSTD_versionNumber(); return 0; }
+EOF
+if compile_prog "" "-lzstd" ; then
+LIBS="$LIBS -lzstd"
+zstd="yes"
+else
+if test "$zstd" = "yes"; then
+feature_not_found "zstd" "Install libzstd-devel"
+fi
+zstd="no"
+fi
+fi
+
 ##
 # libseccomp check
 
@@ -6668,6 +6693,7 @@ echo "lzo support   $lzo"
 echo "snappy support$snappy"
 echo "bzip2 support $bzip2"
 echo "lzfse support $lzfse"
+echo "zstd support 

[PATCH v2 0/4] qcow2: Implement zstd cluster compression method

2020-03-02 Thread Denis Plotnikov
v2:
  * rework compression type setting [Vladimir]
  * squash iotest changes to the compression type introduction patch [Vladimir, 
Eric]
  * fix zstd availability checking in zstd iotest [Vladimir]
  * remove unnecessry casting [Eric]
  * remove rudundant checks [Eric]
  * fix compressed cluster layout in qcow2 spec [Vladimir]
  * fix wording [Eric, Vladimir]
  * fix compression type filtering in iotests [Eric]

v1:
  the initial series

---
zstd comression method is faster than the only available zlib.
The series adds zstd to the methods available for clusters compression.

The implementation is done with respect to the recently added compression
type additional header to the qcow2 specification.

Denis Plotnikov (4):
  qcow2: introduce compression type feature
  qcow2: rework the cluster compression routine
  qcow2: add zstd cluster compression
  iotests: 287: add qcow2 compression type test

 docs/interop/qcow2.txt   |  20 
 configure|  29 +
 qapi/block-core.json |  23 +++-
 block/qcow2.h|  18 ++-
 include/block/block_int.h|   1 +
 block/qcow2-threads.c| 197 ---
 block/qcow2.c| 116 ++
 tests/qemu-iotests/031.out   |  14 +--
 tests/qemu-iotests/036.out   |   4 +-
 tests/qemu-iotests/049.out   | 102 
 tests/qemu-iotests/060.out   |   1 +
 tests/qemu-iotests/061.out   |  34 +++---
 tests/qemu-iotests/065   |  20 ++--
 tests/qemu-iotests/080   |   2 +-
 tests/qemu-iotests/144.out   |   4 +-
 tests/qemu-iotests/182.out   |   2 +-
 tests/qemu-iotests/242.out   |   5 +
 tests/qemu-iotests/255.out   |   8 +-
 tests/qemu-iotests/287   | 127 
 tests/qemu-iotests/287.out   |  43 +++
 tests/qemu-iotests/common.filter |   3 +-
 tests/qemu-iotests/group |   1 +
 22 files changed, 666 insertions(+), 108 deletions(-)
 create mode 100755 tests/qemu-iotests/287
 create mode 100644 tests/qemu-iotests/287.out

-- 
2.17.0




[PATCH v2 2/4] qcow2: rework the cluster compression routine

2020-03-02 Thread Denis Plotnikov
The patch enables processing the image compression type defined
for the image and chooses an appropriate method for image clusters
(de)compression.

Signed-off-by: Denis Plotnikov 
---
 block/qcow2-threads.c | 77 +++
 1 file changed, 63 insertions(+), 14 deletions(-)

diff --git a/block/qcow2-threads.c b/block/qcow2-threads.c
index 77bb578cdf..9288a4f852 100644
--- a/block/qcow2-threads.c
+++ b/block/qcow2-threads.c
@@ -74,7 +74,9 @@ typedef struct Qcow2CompressData {
 } Qcow2CompressData;
 
 /*
- * qcow2_compress()
+ * qcow2_zlib_compress()
+ *
+ * Compress @src_size bytes of data using zlib compression method
  *
  * @dest - destination buffer, @dest_size bytes
  * @src - source buffer, @src_size bytes
@@ -83,8 +85,8 @@ typedef struct Qcow2CompressData {
  *  -ENOMEM destination buffer is not enough to store compressed data
  *  -EIOon any other error
  */
-static ssize_t qcow2_compress(void *dest, size_t dest_size,
-  const void *src, size_t src_size)
+static ssize_t qcow2_zlib_compress(void *dest, size_t dest_size,
+   const void *src, size_t src_size)
 {
 ssize_t ret;
 z_stream strm;
@@ -119,19 +121,19 @@ static ssize_t qcow2_compress(void *dest, size_t 
dest_size,
 }
 
 /*
- * qcow2_decompress()
+ * qcow2_zlib_decompress()
  *
  * Decompress some data (not more than @src_size bytes) to produce exactly
- * @dest_size bytes.
+ * @dest_size bytes using zlib compression method
  *
  * @dest - destination buffer, @dest_size bytes
  * @src - source buffer, @src_size bytes
  *
  * Returns: 0 on success
- *  -1 on fail
+ *  -EIO on failure
  */
-static ssize_t qcow2_decompress(void *dest, size_t dest_size,
-const void *src, size_t src_size)
+static ssize_t qcow2_zlib_decompress(void *dest, size_t dest_size,
+ const void *src, size_t src_size)
 {
 int ret = 0;
 z_stream strm;
@@ -144,7 +146,7 @@ static ssize_t qcow2_decompress(void *dest, size_t 
dest_size,
 
 ret = inflateInit2(&strm, -12);
 if (ret != Z_OK) {
-return -1;
+return -EIO;
 }
 
 ret = inflate(&strm, Z_FINISH);
@@ -154,7 +156,7 @@ static ssize_t qcow2_decompress(void *dest, size_t 
dest_size,
  * @src buffer may be processed partly (because in qcow2 we know size 
of
  * compressed data with precision of one sector)
  */
-ret = -1;
+ret = -EIO;
 }
 
 inflateEnd(&strm);
@@ -189,20 +191,67 @@ qcow2_co_do_compress(BlockDriverState *bs, void *dest, 
size_t dest_size,
 return arg.ret;
 }
 
+/*
+ * qcow2_co_compress()
+ *
+ * Compress @src_size bytes of data using the compression
+ * method defined by the image compression type
+ *
+ * @dest - destination buffer, @dest_size bytes
+ * @src - source buffer, @src_size bytes
+ *
+ * Returns: compressed size on success
+ *  a negative error code on failure
+ */
 ssize_t coroutine_fn
 qcow2_co_compress(BlockDriverState *bs, void *dest, size_t dest_size,
   const void *src, size_t src_size)
 {
-return qcow2_co_do_compress(bs, dest, dest_size, src, src_size,
-qcow2_compress);
+BDRVQcow2State *s = bs->opaque;
+Qcow2CompressFunc fn;
+
+switch (s->compression_type) {
+case QCOW2_COMPRESSION_TYPE_ZLIB:
+fn = qcow2_zlib_compress;
+break;
+
+default:
+abort();
+}
+
+return qcow2_co_do_compress(bs, dest, dest_size, src, src_size, fn);
 }
 
+/*
+ * qcow2_co_decompress()
+ *
+ * Decompress some data (not more than @src_size bytes) to produce exactly
+ * @dest_size bytes using the compression method defined by the image
+ * compression type
+ *
+ * @dest - destination buffer, @dest_size bytes
+ * @src - source buffer, @src_size bytes
+ *
+ * Returns: 0 on success
+ *  a negative error code on failure
+ */
 ssize_t coroutine_fn
 qcow2_co_decompress(BlockDriverState *bs, void *dest, size_t dest_size,
 const void *src, size_t src_size)
 {
-return qcow2_co_do_compress(bs, dest, dest_size, src, src_size,
-qcow2_decompress);
+BDRVQcow2State *s = bs->opaque;
+Qcow2CompressFunc fn;
+
+switch (s->compression_type) {
+case QCOW2_COMPRESSION_TYPE_ZLIB:
+fn = qcow2_zlib_decompress;
+break;
+
+default:
+return -ENOTSUP;
+}
+
+return qcow2_co_do_compress(bs, dest, dest_size, src, src_size, fn);
 }
 
 
-- 
2.17.0




[PATCH v2 4/4] iotests: 287: add qcow2 compression type test

2020-03-02 Thread Denis Plotnikov
The test checks fulfilling qcow2 requiriements for the compression
type feature and zstd compression type operability.

Signed-off-by: Denis Plotnikov 
---
 tests/qemu-iotests/287 | 127 +
 tests/qemu-iotests/287.out |  43 +
 tests/qemu-iotests/group   |   1 +
 3 files changed, 171 insertions(+)
 create mode 100755 tests/qemu-iotests/287
 create mode 100644 tests/qemu-iotests/287.out

diff --git a/tests/qemu-iotests/287 b/tests/qemu-iotests/287
new file mode 100755
index 00..39cb665c85
--- /dev/null
+++ b/tests/qemu-iotests/287
@@ -0,0 +1,127 @@
+#!/usr/bin/env bash
+#
+# Test case for an image using zstd compression
+#
+# Copyright (c) 2020 Virtuozzo International GmbH
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+#
+
+# creator
+owner=dplotni...@virtuozzo.com
+
+seq="$(basename $0)"
+echo "QA output created by $seq"
+
+status=1   # failure is the default!
+
+_cleanup()
+{
+   _cleanup_test_img
+}
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+# standard environment
+. ./common.rc
+. ./common.filter
+
+# This tests qocw2-specific low-level functionality
+_supported_fmt qcow2
+_supported_proto file
+_supported_os Linux
+
+# Check if we can run this test.
+IMGOPTS='compression_type=zstd'
+
+_make_test_img 64M | grep "Invalid parameter 'zstd'" 2>&1 1>/dev/null
+
+ZSTD_SUPPORTED=$?
+
+if (($ZSTD_SUPPORTED==0)); then
+_notrun "ZSTD is disabled"
+fi
+
+# Test: when compression is zlib the incompatible bit is unset
+echo
+echo "=== Testing compression type incompatible bit setting for zlib ==="
+echo
+
+IMGOPTS='compression_type=zlib' _make_test_img 64M
+$PYTHON qcow2.py "$TEST_IMG" dump-header | grep incompatible_features
+
+# Test: when compression differs from zlib the incompatible bit is set
+echo
+echo "=== Testing compression type incompatible bit setting for zstd ==="
+echo
+
+IMGOPTS='compression_type=zstd' _make_test_img 64M
+$PYTHON qcow2.py "$TEST_IMG" dump-header | grep incompatible_features
+
+# Test: an image can't be openned if compression type is zlib and
+#   incompatible feature compression type is set
+echo
+echo "=== Testing zlib with incompatible bit set  ==="
+echo
+
+IMGOPTS='compression_type=zlib' _make_test_img 64M
+$PYTHON qcow2.py "$TEST_IMG" set-feature-bit incompatible 3
+# to make sure the bit was actually set
+$PYTHON qcow2.py "$TEST_IMG" dump-header | grep incompatible_features
+$QEMU_IMG info "$TEST_IMG" 2>1 1>/dev/null
+if (($?==0)); then
+echo "Error: The image openned successfully. The image must not be openned"
+fi
+
+# Test: an image can't be openned if compression type is NOT zlib and
+#   incompatible feature compression type is UNSET
+echo
+echo "=== Testing zstd with incompatible bit unset  ==="
+echo
+
+IMGOPTS='compression_type=zstd' _make_test_img 64M
+$PYTHON qcow2.py "$TEST_IMG" set-header incompatible_features 0
+# to make sure the bit was actually unset
+$PYTHON qcow2.py "$TEST_IMG" dump-header | grep incompatible_features
+$QEMU_IMG info "$TEST_IMG" 2>1 1>/dev/null
+if (($?==0)); then
+echo "Error: The image openned successfully. The image must not be openned"
+fi
+# Test: check compression type values
+echo
+echo "=== Testing compression type values  ==="
+echo
+# zlib=0
+IMGOPTS='compression_type=zlib' _make_test_img 64M
+od -j104 -N1 -An -vtu1 "$TEST_IMG"
+
+# zstd=1
+IMGOPTS='compression_type=zstd' _make_test_img 64M
+od -j104 -N1 -An -vtu1 "$TEST_IMG"
+
+# Test: using zstd compression, write to and read from an image
+echo
+echo "=== Testing reading and writing with zstd ==="
+echo
+
+CLUSTER_SIZE=65536
+IMGOPTS='compression_type=zstd' _make_test_img 64M
+$QEMU_IO -c "write -c -P 0xAC 65536 64k " "$TEST_IMG" | _filter_qemu_io
+$QEMU_IO -c "read -P 0xAC 65536 65536 " "$TEST_IMG" | _filter_qemu_io
+$QEMU_IO -c "read -v 131070 8 " "$TEST_IMG" | _filter_qemu_io
+$QEMU_IO -c "read -v 65534 8" "$TEST_IMG" | _filter_qemu_io
+
+# success, all done
+echo "*** done"
+rm -f $seq.full
+status=0
diff --git a/tests/qemu-iotests/287.out b/tests/qemu-iotests/287.out
new file mode 100644
index 00..8e51c3078d
--- /dev/null
+++ b/tests/qemu-iotests/287.out
@@ -0,0 +1,43 @@
+QA output created by 287
+
+=== Testing compression type incompatible bit setting for zlib ===
+
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864
+incompatible_features []
+
+=== Testing compression type incom

[PATCH v2 1/4] qcow2: introduce compression type feature

2020-03-02 Thread Denis Plotnikov
The patch adds some preparation parts for incompatible compression type
feature to qcow2 allowing the use different compression methods for
image clusters (de)compressing.

It is implied that the compression type is set on the image creation and
can be changed only later by image conversion, thus compression type
defines the only compression algorithm used for the image, and thus,
for all image clusters.

The goal of the feature is to add support of other compression methods
to qcow2. For example, ZSTD which is more effective on compression than ZLIB.

The default compression is ZLIB. Images created with ZLIB compression type
are backward compatible with older qemu versions.

Adding of the compression type breaks a number of tests because now the
compression type is reported on image creation and there are some changes
in the qcow2 header in size and offsets.

The tests are fixed in the following ways:
* filter out compression_type for all the tests
* fix header size, feature table size and backing file offset
  affected tests: 031, 036, 061, 080
  header_size +=8: 1 byte compression type
   7 bytes padding
  feature_table += 48: incompatible feture compression type
  backing_file_offset += 56 (8 + 48 -> header_change + fature_table_change)
* add "compression type" for test output matching when it isn't filtered
  affected tests: 049, 060, 061, 065, 144, 182, 242, 255

Signed-off-by: Denis Plotnikov 
---
 qapi/block-core.json |  22 ++-
 block/qcow2.h|  18 -
 include/block/block_int.h|   1 +
 block/qcow2.c| 109 +++
 tests/qemu-iotests/031.out   |  14 ++--
 tests/qemu-iotests/036.out   |   4 +-
 tests/qemu-iotests/049.out   | 102 ++---
 tests/qemu-iotests/060.out   |   1 +
 tests/qemu-iotests/061.out   |  34 ++
 tests/qemu-iotests/065   |  20 +++---
 tests/qemu-iotests/080   |   2 +-
 tests/qemu-iotests/144.out   |   4 +-
 tests/qemu-iotests/182.out   |   2 +-
 tests/qemu-iotests/242.out   |   5 ++
 tests/qemu-iotests/255.out   |   8 +--
 tests/qemu-iotests/common.filter |   3 +-
 16 files changed, 255 insertions(+), 94 deletions(-)

diff --git a/qapi/block-core.json b/qapi/block-core.json
index 85e27bb61f..a67eb8bff4 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -78,6 +78,8 @@
 #
 # @bitmaps: A list of qcow2 bitmap details (since 4.0)
 #
+# @compression-type: the image cluster compression method (since 5.0)
+#
 # Since: 1.7
 ##
 { 'struct': 'ImageInfoSpecificQCow2',
@@ -89,7 +91,8 @@
   '*corrupt': 'bool',
   'refcount-bits': 'int',
   '*encrypt': 'ImageInfoSpecificQCow2Encryption',
-  '*bitmaps': ['Qcow2BitmapInfo']
+  '*bitmaps': ['Qcow2BitmapInfo'],
+  'compression-type': 'Qcow2CompressionType'
   } }
 
 ##
@@ -4392,6 +4395,18 @@
   'data': [ 'v2', 'v3' ] }
 
 
+##
+# @Qcow2CompressionType:
+#
+# Compression type used in qcow2 image file
+#
+# @zlib:  zlib compression, see 
+#
+# Since: 5.0
+##
+{ 'enum': 'Qcow2CompressionType',
+  'data': [ 'zlib' ] }
+
 ##
 # @BlockdevCreateOptionsQcow2:
 #
@@ -4415,6 +4430,8 @@
 # allowed values: off, falloc, full, metadata)
 # @lazy-refcounts: True if refcounts may be updated lazily (default: off)
 # @refcount-bits: Width of reference counts in bits (default: 16)
+# @compression-type: The image cluster compression method
+#(default: zlib, since 5.0)
 #
 # Since: 2.12
 ##
@@ -4430,7 +4447,8 @@
 '*cluster-size':'size',
 '*preallocation':   'PreallocMode',
 '*lazy-refcounts':  'bool',
-'*refcount-bits':   'int' } }
+'*refcount-bits':   'int',
+'*compression-type':'Qcow2CompressionType' } }
 
 ##
 # @BlockdevCreateOptionsQed:
diff --git a/block/qcow2.h b/block/qcow2.h
index 0942126232..6a43495c27 100644
--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -146,6 +146,12 @@ typedef struct QCowHeader {
 
 uint32_t refcount_order;
 uint32_t header_length;
+
+/* Additional fields */
+uint8_t  compression_type;
+
+/* header must be a multiple of 8 */
+uint8_t  padding[7];
 } QEMU_PACKED QCowHeader;
 
 typedef struct QEMU_PACKED QCowSnapshotHeader {
@@ -216,13 +222,16 @@ enum {
 QCOW2_INCOMPAT_DIRTY_BITNR  = 0,
 QCOW2_INCOMPAT_CORRUPT_BITNR= 1,
 QCOW2_INCOMPAT_DATA_FILE_BITNR  = 2,
+QCOW2_INCOMPAT_COMPRESSION_BITNR= 3,
 QCOW2_INCOMPAT_DIRTY= 1 << QCOW2_INCOMPAT_DIRTY_BITNR,
 QCOW2_INCOMPAT_CORRUPT  = 1 << QCOW2_INCOMPAT_CORRUPT_BITNR,
 QCOW2_INCOMPAT_DATA_FILE= 1 << QCOW2_INCOMPAT_DATA_FILE_BITNR,
+QCOW2_INCOMPAT_COMPRESSION  = 1 << QCOW2_INCOMPAT_COMPRESSION_BITNR,
 
 QCOW2_INCOMPAT_MASK = QCOW2_INCOMPAT_DIRTY
 | QCOW2_INCOMPAT_CORRUPT
-   

Re: [PULL 06/15] configure: Enable test and libs for zstd

2020-03-02 Thread Alex Bennée


Juan Quintela  writes:

> Richard Henderson  wrote:
>>> +##
>>> +# zstd check
>>> +
>>> +if test "$zstd" != "no" ; then
>>> +if $pkg_config --exist libzstd ; then
>>
>> The option is spelled --exists.  This is generating an error during 
>> configure.
>
> Ooops, you are right.
>
> Sending a patch.  Just wondering why I didn't saw that error :-(

I was only noticing when re-directing output - otherwise you miss it in
a fairly long scrollback.

>
> Thanks, Juan.


-- 
Alex Bennée



Re: [PATCH] hw/smbios: add options for type 4 max_speed and current_speed

2020-03-02 Thread Heyi Guo



On 2020/3/2 16:20, Igor Mammedov wrote:

On Sat, 29 Feb 2020 08:17:48 +0800
Heyi Guo  wrote:


Hi Igor,

On 2020/2/28 17:39, Igor Mammedov wrote:

On Thu, 27 Feb 2020 17:12:21 +0800
Heyi Guo  wrote:
  

On 2020/2/25 17:24, Philippe Mathieu-Daudé wrote:

On 2/25/20 8:50 AM, Heyi Guo wrote:

Common VM users sometimes care about CPU speed, so we add two new
options to allow VM vendors to present CPU speed to their users.
Normally these information can be fetched from host smbios.

Strictly speaking, the "max speed" and "current speed" in type 4
are not really for the max speed and current speed of processor, for
"max speed" identifies a capability of the system, and "current speed"
identifies the processor's speed at boot (see smbios spec), but some
applications do not tell the differences.

Signed-off-by: Heyi Guo 

---
Cc: "Michael S. Tsirkin" 
Cc: Igor Mammedov 
---
    hw/smbios/smbios.c | 22 +++---
    qemu-options.hx    |  3 ++-
    2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index ffd98727ee..1d5439643d 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -94,6 +94,8 @@ static struct {
      static struct {
    const char *sock_pfx, *manufacturer, *version, *serial, *asset,
*part;
+    uint32_t max_speed;
+    uint32_t current_speed;
    } type4;
      static struct {
@@ -272,6 +274,14 @@ static const QemuOptDesc
qemu_smbios_type4_opts[] = {
    .name = "version",
    .type = QEMU_OPT_STRING,
    .help = "version number",
+    },{
+    .name = "max_speed",

I'd suggest to use - instead of _ in option name

Thanks for your comments. However I can see other options like
"sock_pfx" and "loc_pfx" also use "_" in option names. Should we keep
consistent with the context?

For new options one should use '-',
that way we won't have to build wrappers around it if it becomes
a qom property in the future.


Thanks for the explanation. I'll fix that in v2.

Thanks,

Heyi





Thanks,

Heyi


  

+    .type = QEMU_OPT_NUMBER,
+    .help = "max speed in MHz",
+    },{
+    .name = "current_speed",

ditto
  

+    .type = QEMU_OPT_NUMBER,
+    .help = "speed at system boot in MHz",
    },{
    .name = "serial",
    .type = QEMU_OPT_STRING,
@@ -586,9 +596,8 @@ static void
smbios_build_type_4_table(MachineState *ms, unsigned instance)
    SMBIOS_TABLE_SET_STR(4, processor_version_str, type4.version);
    t->voltage = 0;
    t->external_clock = cpu_to_le16(0); /* Unknown */
-    /* SVVP requires max_speed and current_speed to not be unknown. */
-    t->max_speed = cpu_to_le16(2000); /* 2000 MHz */
-    t->current_speed = cpu_to_le16(2000); /* 2000 MHz */
+    t->max_speed = cpu_to_le16(type4.max_speed);
+    t->current_speed = cpu_to_le16(type4.current_speed);
    t->status = 0x41; /* Socket populated, CPU enabled */
    t->processor_upgrade = 0x01; /* Other */
    t->l1_cache_handle = cpu_to_le16(0x); /* N/A */
@@ -1129,6 +1138,13 @@ void smbios_entry_add(QemuOpts *opts, Error
**errp)
    save_opt(&type4.serial, opts, "serial");
    save_opt(&type4.asset, opts, "asset");
    save_opt(&type4.part, opts, "part");
+    /*
+ * SVVP requires max_speed and current_speed to not be
unknown, and
+ * we set the default value to 2000MHz as we did before.
+ */
+    type4.max_speed = qemu_opt_get_number(opts, "max_speed",
2000);
+    type4.current_speed = qemu_opt_get_number(opts,
"current_speed",
+  2000);

Maybe check speeds are <= UINT16_MAX else set errp?

OK; I can do that in the v2. But I would wait for the maintainers to
provide more comments :)

Thanks,

Heyi
  
 

    return;
    case 11:
    qemu_opts_validate(opts, qemu_smbios_type11_opts, &err);
diff --git a/qemu-options.hx b/qemu-options.hx
index ac315c1ac4..bc9ef0fda8 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2233,6 +2233,7 @@ DEF("smbios", HAS_ARG, QEMU_OPTION_smbios,
    "    specify SMBIOS type 3 fields\n"
    "-smbios
type=4[,sock_pfx=str][,manufacturer=str][,version=str][,serial=str]\n"
    "  [,asset=str][,part=str]\n"
+    "  [,max_speed=%d][,current_speed=%d]\n"
    "    specify SMBIOS type 4 fields\n"
    "-smbios
type=17[,loc_pfx=str][,bank=str][,manufacturer=str][,serial=str]\n"
    "   [,asset=str][,part=str][,speed=%d]\n"
@@ -2255,7 +2256,7 @@ Specify SMBIOS type 2 fields
    @item -smbios
type=3[,manufacturer=@var{str}][,version=@var{str}][,serial=@var{str}][,asset=@var{str}][,sku=@var{str}]
    Specify SMBIOS type 3 fields
    -@item -smbios
type=4[,sock_pfx=@var{str}][,manufacturer=@var{str}][,version=@var{str}][,serial=@var{str}][,asset=@var{str}][,part=@var{str}]
+@item -smbios
type=4[,sock_p

Re: [PATCH v2 0/4] qcow2: Implement zstd cluster compression method

2020-03-02 Thread Vladimir Sementsov-Ogievskiy

Doesn't apply to master, as zstd already exists in ./configure :) (for 
migration)


02.03.2020 11:21, Denis Plotnikov wrote:

v2:
   * rework compression type setting [Vladimir]
   * squash iotest changes to the compression type introduction patch 
[Vladimir, Eric]
   * fix zstd availability checking in zstd iotest [Vladimir]
   * remove unnecessry casting [Eric]
   * remove rudundant checks [Eric]
   * fix compressed cluster layout in qcow2 spec [Vladimir]
   * fix wording [Eric, Vladimir]
   * fix compression type filtering in iotests [Eric]

v1:
   the initial series

---
zstd comression method is faster than the only available zlib.
The series adds zstd to the methods available for clusters compression.

The implementation is done with respect to the recently added compression
type additional header to the qcow2 specification.

Denis Plotnikov (4):
   qcow2: introduce compression type feature
   qcow2: rework the cluster compression routine
   qcow2: add zstd cluster compression
   iotests: 287: add qcow2 compression type test

  docs/interop/qcow2.txt   |  20 
  configure|  29 +
  qapi/block-core.json |  23 +++-
  block/qcow2.h|  18 ++-
  include/block/block_int.h|   1 +
  block/qcow2-threads.c| 197 ---
  block/qcow2.c| 116 ++
  tests/qemu-iotests/031.out   |  14 +--
  tests/qemu-iotests/036.out   |   4 +-
  tests/qemu-iotests/049.out   | 102 
  tests/qemu-iotests/060.out   |   1 +
  tests/qemu-iotests/061.out   |  34 +++---
  tests/qemu-iotests/065   |  20 ++--
  tests/qemu-iotests/080   |   2 +-
  tests/qemu-iotests/144.out   |   4 +-
  tests/qemu-iotests/182.out   |   2 +-
  tests/qemu-iotests/242.out   |   5 +
  tests/qemu-iotests/255.out   |   8 +-
  tests/qemu-iotests/287   | 127 
  tests/qemu-iotests/287.out   |  43 +++
  tests/qemu-iotests/common.filter |   3 +-
  tests/qemu-iotests/group |   1 +
  22 files changed, 666 insertions(+), 108 deletions(-)
  create mode 100755 tests/qemu-iotests/287
  create mode 100644 tests/qemu-iotests/287.out




--
Best regards,
Vladimir



Re: [PATCH v2 0/4] qcow2: Implement zstd cluster compression method

2020-03-02 Thread Denis Plotnikov




On 02.03.2020 11:51, Vladimir Sementsov-Ogievskiy wrote:
Doesn't apply to master, as zstd already exists in ./configure :) (for 
migration)

M, will rebase it. Any other comments?



02.03.2020 11:21, Denis Plotnikov wrote:

v2:
   * rework compression type setting [Vladimir]
   * squash iotest changes to the compression type introduction patch 
[Vladimir, Eric]

   * fix zstd availability checking in zstd iotest [Vladimir]
   * remove unnecessry casting [Eric]
   * remove rudundant checks [Eric]
   * fix compressed cluster layout in qcow2 spec [Vladimir]
   * fix wording [Eric, Vladimir]
   * fix compression type filtering in iotests [Eric]

v1:
   the initial series

---
zstd comression method is faster than the only available zlib.
The series adds zstd to the methods available for clusters compression.

The implementation is done with respect to the recently added 
compression

type additional header to the qcow2 specification.

Denis Plotnikov (4):
   qcow2: introduce compression type feature
   qcow2: rework the cluster compression routine
   qcow2: add zstd cluster compression
   iotests: 287: add qcow2 compression type test

  docs/interop/qcow2.txt   |  20 
  configure    |  29 +
  qapi/block-core.json |  23 +++-
  block/qcow2.h    |  18 ++-
  include/block/block_int.h    |   1 +
  block/qcow2-threads.c    | 197 ---
  block/qcow2.c    | 116 ++
  tests/qemu-iotests/031.out   |  14 +--
  tests/qemu-iotests/036.out   |   4 +-
  tests/qemu-iotests/049.out   | 102 
  tests/qemu-iotests/060.out   |   1 +
  tests/qemu-iotests/061.out   |  34 +++---
  tests/qemu-iotests/065   |  20 ++--
  tests/qemu-iotests/080   |   2 +-
  tests/qemu-iotests/144.out   |   4 +-
  tests/qemu-iotests/182.out   |   2 +-
  tests/qemu-iotests/242.out   |   5 +
  tests/qemu-iotests/255.out   |   8 +-
  tests/qemu-iotests/287   | 127 
  tests/qemu-iotests/287.out   |  43 +++
  tests/qemu-iotests/common.filter |   3 +-
  tests/qemu-iotests/group |   1 +
  22 files changed, 666 insertions(+), 108 deletions(-)
  create mode 100755 tests/qemu-iotests/287
  create mode 100644 tests/qemu-iotests/287.out









[PULL 0/2] Vga 20200302 patches

2020-03-02 Thread Gerd Hoffmann
The following changes since commit e0175b71638cf4398903c0d25f93fe62e0606389:

  Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20200228' 
into staging (2020-02-28 16:39:27 +)

are available in the Git repository at:

  git://git.kraxel.org/qemu tags/vga-20200302-pull-request

for you to fetch changes up to 44b5c1ebfa5db337714180e9d4a8d525da5595d6:

  qxl: map rom r/o (2020-03-02 08:24:36 +0100)


vga: bugfixes for qxl and edid generator.



Anton V. Boyarshinov (1):
  Arithmetic error in EDID generation fixed

Gerd Hoffmann (1):
  qxl: map rom r/o

 hw/display/edid-generate.c | 4 ++--
 hw/display/qxl.c   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.18.2




[PULL 1/2] Arithmetic error in EDID generation fixed

2020-03-02 Thread Gerd Hoffmann
From: "Anton V. Boyarshinov" 

To calculate screen size in centimeters we should calculate:
pixels/dpi*2.54
but not
pixels*dpi/2540

Using wrong formula we actually get 65 DPI and very small fonts.

Signed-off-by: Anton V. Boyarshinov 
Message-id: 20200226122054.366b9cda@table.localdomain
Signed-off-by: Gerd Hoffmann 
---
 hw/display/edid-generate.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/display/edid-generate.c b/hw/display/edid-generate.c
index 75c945a94813..e58472fde501 100644
--- a/hw/display/edid-generate.c
+++ b/hw/display/edid-generate.c
@@ -360,8 +360,8 @@ void qemu_edid_generate(uint8_t *edid, size_t size,
 edid[20] = 0xa5;
 
 /* screen size: undefined */
-edid[21] = info->prefx * info->dpi / 2540;
-edid[22] = info->prefy * info->dpi / 2540;
+edid[21] = info->prefx * 254 / 100 / info->dpi;
+edid[22] = info->prefy * 254 / 100 / info->dpi;
 
 /* display gamma: 2.2 */
 edid[23] = 220 - 100;
-- 
2.18.2




[PULL 2/2] qxl: map rom r/o

2020-03-02 Thread Gerd Hoffmann
Map qxl rom read-only into the guest, so the guest can't tamper with the
content.  qxl has a shadow copy of the rom to deal with that, but the
shadow doesn't cover the mode list.  A privilidged user in the guest can
manipulate the mode list and that to trick qemu into oob reads, leading
to a DoS via segfault if that read access happens to hit unmapped memory.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Philippe Mathieu-Daudé 
Message-id: 20200225055920.17261-2-kra...@redhat.com
---
 hw/display/qxl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/display/qxl.c b/hw/display/qxl.c
index 21a43a1d5ec2..227da69a50d9 100644
--- a/hw/display/qxl.c
+++ b/hw/display/qxl.c
@@ -2136,7 +2136,7 @@ static void qxl_realize_common(PCIQXLDevice *qxl, Error 
**errp)
 pci_set_byte(&config[PCI_INTERRUPT_PIN], 1);
 
 qxl->rom_size = qxl_rom_size();
-memory_region_init_ram(&qxl->rom_bar, OBJECT(qxl), "qxl.vrom",
+memory_region_init_rom(&qxl->rom_bar, OBJECT(qxl), "qxl.vrom",
qxl->rom_size, &error_fatal);
 init_qxl_rom(qxl);
 init_qxl_ram(qxl);
-- 
2.18.2




[PATCH v2] hw/smbios: add options for type 4 max-speed and current-speed

2020-03-02 Thread Heyi Guo
Common VM users sometimes care about CPU speed, so we add two new
options to allow VM vendors to present CPU speed to their users.
Normally these information can be fetched from host smbios.

Strictly speaking, the "max speed" and "current speed" in type 4
are not really for the max speed and current speed of processor, for
"max speed" identifies a capability of the system, and "current speed"
identifies the processor's speed at boot (see smbios spec), but some
applications do not tell the differences.

Signed-off-by: Heyi Guo 

---
Cc: "Michael S. Tsirkin" 
Cc: Igor Mammedov 
Cc: Philippe Mathieu-Daudé 

v1 -> v2:
- change "_" in option names to "-"
- check if option value is too large to fit in SMBIOS type 4 speed fields.

---
 hw/smbios/smbios.c | 28 +---
 qemu-options.hx|  3 ++-
 2 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index ffd98727ee..77135a1eca 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -94,6 +94,8 @@ static struct {
 
 static struct {
 const char *sock_pfx, *manufacturer, *version, *serial, *asset, *part;
+uint32_t max_speed;
+uint32_t current_speed;
 } type4;
 
 static struct {
@@ -272,6 +274,14 @@ static const QemuOptDesc qemu_smbios_type4_opts[] = {
 .name = "version",
 .type = QEMU_OPT_STRING,
 .help = "version number",
+},{
+.name = "max-speed",
+.type = QEMU_OPT_NUMBER,
+.help = "max speed in MHz",
+},{
+.name = "current-speed",
+.type = QEMU_OPT_NUMBER,
+.help = "speed at system boot in MHz",
 },{
 .name = "serial",
 .type = QEMU_OPT_STRING,
@@ -586,9 +596,8 @@ static void smbios_build_type_4_table(MachineState *ms, 
unsigned instance)
 SMBIOS_TABLE_SET_STR(4, processor_version_str, type4.version);
 t->voltage = 0;
 t->external_clock = cpu_to_le16(0); /* Unknown */
-/* SVVP requires max_speed and current_speed to not be unknown. */
-t->max_speed = cpu_to_le16(2000); /* 2000 MHz */
-t->current_speed = cpu_to_le16(2000); /* 2000 MHz */
+t->max_speed = cpu_to_le16(type4.max_speed);
+t->current_speed = cpu_to_le16(type4.current_speed);
 t->status = 0x41; /* Socket populated, CPU enabled */
 t->processor_upgrade = 0x01; /* Other */
 t->l1_cache_handle = cpu_to_le16(0x); /* N/A */
@@ -1129,6 +1138,19 @@ void smbios_entry_add(QemuOpts *opts, Error **errp)
 save_opt(&type4.serial, opts, "serial");
 save_opt(&type4.asset, opts, "asset");
 save_opt(&type4.part, opts, "part");
+/*
+ * SVVP requires max_speed and current_speed to not be unknown, and
+ * we set the default value to 2000MHz as we did before.
+ */
+type4.max_speed = qemu_opt_get_number(opts, "max-speed", 2000);
+type4.current_speed = qemu_opt_get_number(opts, "current-speed",
+  2000);
+if (type4.max_speed > UINT16_MAX ||
+type4.current_speed > UINT16_MAX) {
+error_setg(errp, "SMBIOS CPU speed is too large (> %d)",
+   UINT16_MAX);
+}
+
 return;
 case 11:
 qemu_opts_validate(opts, qemu_smbios_type11_opts, &err);
diff --git a/qemu-options.hx b/qemu-options.hx
index ac315c1ac4..7a2f7c1f66 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2233,6 +2233,7 @@ DEF("smbios", HAS_ARG, QEMU_OPTION_smbios,
 "specify SMBIOS type 3 fields\n"
 "-smbios 
type=4[,sock_pfx=str][,manufacturer=str][,version=str][,serial=str]\n"
 "  [,asset=str][,part=str]\n"
+"  [,max-speed=%d][,current-speed=%d]\n"
 "specify SMBIOS type 4 fields\n"
 "-smbios 
type=17[,loc_pfx=str][,bank=str][,manufacturer=str][,serial=str]\n"
 "   [,asset=str][,part=str][,speed=%d]\n"
@@ -2255,7 +2256,7 @@ Specify SMBIOS type 2 fields
 @item -smbios 
type=3[,manufacturer=@var{str}][,version=@var{str}][,serial=@var{str}][,asset=@var{str}][,sku=@var{str}]
 Specify SMBIOS type 3 fields
 
-@item -smbios 
type=4[,sock_pfx=@var{str}][,manufacturer=@var{str}][,version=@var{str}][,serial=@var{str}][,asset=@var{str}][,part=@var{str}]
+@item -smbios 
type=4[,sock_pfx=@var{str}][,manufacturer=@var{str}][,version=@var{str}][,serial=@var{str}][,asset=@var{str}][,part=@var{str}][,max-speed=@var{%d}][,current-speed=@var{%d}]
 Specify SMBIOS type 4 fields
 
 @item -smbios 
type=17[,loc_pfx=@var{str}][,bank=@var{str}][,manufacturer=@var{str}][,serial=@var{str}][,asset=@var{str}][,part=@var{str}][,speed=@var{%d}]
-- 
2.19.1




[PATCH 1/3] usb/hcd-xhci: Make dma read/writes hooks pci free

2020-03-02 Thread Sai Pavan Boddu
This patch starts making the hcd-xhci.c pci free, as part of this
restructuring dma read/writes are handled without passing pci object.

Signed-off-by: Sai Pavan Boddu 
---
 hw/usb/hcd-xhci.c | 23 ++-
 hw/usb/hcd-xhci.h |  3 +++
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c
index b330e36..6e88670 100644
--- a/hw/usb/hcd-xhci.c
+++ b/hw/usb/hcd-xhci.c
@@ -495,7 +495,7 @@ static inline void xhci_dma_read_u32s(XHCIState *xhci, 
dma_addr_t addr,
 
 assert((len % sizeof(uint32_t)) == 0);
 
-pci_dma_read(PCI_DEVICE(xhci), addr, buf, len);
+dma_memory_read(xhci->as, addr, buf, len);
 
 for (i = 0; i < (len / sizeof(uint32_t)); i++) {
 buf[i] = le32_to_cpu(buf[i]);
@@ -515,7 +515,7 @@ static inline void xhci_dma_write_u32s(XHCIState *xhci, 
dma_addr_t addr,
 for (i = 0; i < n; i++) {
 tmp[i] = cpu_to_le32(buf[i]);
 }
-pci_dma_write(PCI_DEVICE(xhci), addr, tmp, len);
+dma_memory_write(xhci->as, addr, tmp, len);
 }
 
 static XHCIPort *xhci_lookup_port(XHCIState *xhci, struct USBPort *uport)
@@ -644,7 +644,6 @@ static void xhci_die(XHCIState *xhci)
 
 static void xhci_write_event(XHCIState *xhci, XHCIEvent *event, int v)
 {
-PCIDevice *pci_dev = PCI_DEVICE(xhci);
 XHCIInterrupter *intr = &xhci->intr[v];
 XHCITRB ev_trb;
 dma_addr_t addr;
@@ -663,7 +662,7 @@ static void xhci_write_event(XHCIState *xhci, XHCIEvent 
*event, int v)
ev_trb.status, ev_trb.control);
 
 addr = intr->er_start + TRB_SIZE*intr->er_ep_idx;
-pci_dma_write(pci_dev, addr, &ev_trb, TRB_SIZE);
+dma_memory_write(xhci->as, addr, &ev_trb, TRB_SIZE);
 
 intr->er_ep_idx++;
 if (intr->er_ep_idx >= intr->er_size) {
@@ -720,12 +719,11 @@ static void xhci_ring_init(XHCIState *xhci, XHCIRing 
*ring,
 static TRBType xhci_ring_fetch(XHCIState *xhci, XHCIRing *ring, XHCITRB *trb,
dma_addr_t *addr)
 {
-PCIDevice *pci_dev = PCI_DEVICE(xhci);
 uint32_t link_cnt = 0;
 
 while (1) {
 TRBType type;
-pci_dma_read(pci_dev, ring->dequeue, trb, TRB_SIZE);
+dma_memory_read(xhci->as, ring->dequeue, trb, TRB_SIZE);
 trb->addr = ring->dequeue;
 trb->ccs = ring->ccs;
 le64_to_cpus(&trb->parameter);
@@ -762,7 +760,6 @@ static TRBType xhci_ring_fetch(XHCIState *xhci, XHCIRing 
*ring, XHCITRB *trb,
 
 static int xhci_ring_chain_length(XHCIState *xhci, const XHCIRing *ring)
 {
-PCIDevice *pci_dev = PCI_DEVICE(xhci);
 XHCITRB trb;
 int length = 0;
 dma_addr_t dequeue = ring->dequeue;
@@ -773,7 +770,7 @@ static int xhci_ring_chain_length(XHCIState *xhci, const 
XHCIRing *ring)
 
 while (1) {
 TRBType type;
-pci_dma_read(pci_dev, dequeue, &trb, TRB_SIZE);
+dma_memory_read(xhci->as, dequeue, &trb, TRB_SIZE);
 le64_to_cpus(&trb.parameter);
 le32_to_cpus(&trb.status);
 le32_to_cpus(&trb.control);
@@ -828,7 +825,7 @@ static void xhci_er_reset(XHCIState *xhci, int v)
 xhci_die(xhci);
 return;
 }
-pci_dma_read(PCI_DEVICE(xhci), erstba, &seg, sizeof(seg));
+dma_memory_read(xhci->as, erstba, &seg, sizeof(seg));
 le32_to_cpus(&seg.addr_low);
 le32_to_cpus(&seg.addr_high);
 le32_to_cpus(&seg.size);
@@ -1440,7 +1437,7 @@ static int xhci_xfer_create_sgl(XHCITransfer *xfer, int 
in_xfer)
 int i;
 
 xfer->int_req = false;
-pci_dma_sglist_init(&xfer->sgl, PCI_DEVICE(xhci), xfer->trb_count);
+qemu_sglist_init(&xfer->sgl, DEVICE(xhci), xfer->trb_count, xhci->as);
 for (i = 0; i < xfer->trb_count; i++) {
 XHCITRB *trb = &xfer->trbs[i];
 dma_addr_t addr;
@@ -2101,7 +2098,7 @@ static TRBCCode xhci_address_slot(XHCIState *xhci, 
unsigned int slotid,
 assert(slotid >= 1 && slotid <= xhci->numslots);
 
 dcbaap = xhci_addr64(xhci->dcbaap_low, xhci->dcbaap_high);
-poctx = ldq_le_pci_dma(PCI_DEVICE(xhci), dcbaap + 8 * slotid);
+poctx = ldq_le_dma(xhci->as, dcbaap + 8 * slotid);
 ictx = xhci_mask64(pictx);
 octx = xhci_mask64(poctx);
 
@@ -2439,7 +2436,7 @@ static TRBCCode xhci_get_port_bandwidth(XHCIState *xhci, 
uint64_t pctx)
 /* TODO: actually implement real values here */
 bw_ctx[0] = 0;
 memset(&bw_ctx[1], 80, xhci->numports); /* 80% */
-pci_dma_write(PCI_DEVICE(xhci), ctx, bw_ctx, sizeof(bw_ctx));
+dma_memory_write(xhci->as, ctx, bw_ctx, sizeof(bw_ctx));
 
 return CC_SUCCESS;
 }
@@ -3531,7 +3528,7 @@ static int usb_xhci_post_load(void *opaque, int 
version_id)
 continue;
 }
 slot->ctx =
-xhci_mask64(ldq_le_pci_dma(pci_dev, dcbaap + 8 * slotid));
+xhci_mask64(ldq_le_dma(xhci->as, dcbaap + 8 * slotid));
 xhci_dma_read_u32s(xhci, slot->ctx, slot_ctx, sizeof(slot_ctx));
 slot->uport = xhci_lookup_uport(xhci, slot_ctx);
 if (!slot->uport) {
diff --git a/hw/usb/hcd-x

[PATCH 3/3] usb/hcd-xhci: Split pci wrapper for xhci base model

2020-03-02 Thread Sai Pavan Boddu
This patch sets the base to use xhci as sysbus model, for which pci
specific hooks are moved to hcd-xhci-pci.c. As a part of this requirment
msi/msix interrupts handling is moved under XHCIPCIState. Made required
changes for qemu-xhci-nec.

Signed-off-by: Sai Pavan Boddu 
---
 hw/usb/Kconfig|   6 ++
 hw/usb/Makefile.objs  |   1 +
 hw/usb/hcd-xhci-nec.c |   8 +--
 hw/usb/hcd-xhci-pci.c | 192 --
 hw/usb/hcd-xhci-pci.h |  47 
 hw/usb/hcd-xhci.c | 167 +++
 hw/usb/hcd-xhci.h |  12 ++--
 7 files changed, 275 insertions(+), 158 deletions(-)
 create mode 100644 hw/usb/hcd-xhci-pci.h

diff --git a/hw/usb/Kconfig b/hw/usb/Kconfig
index 5e70ed5..e93541e 100644
--- a/hw/usb/Kconfig
+++ b/hw/usb/Kconfig
@@ -36,6 +36,12 @@ config USB_XHCI
 depends on PCI
 select USB
 
+config USB_XHCI_PCI
+bool
+default y if PCI_DEVICES
+depends on PCI
+select USB_XHCI
+
 config USB_XHCI_NEC
 bool
 default y if PCI_DEVICES
diff --git a/hw/usb/Makefile.objs b/hw/usb/Makefile.objs
index 2b10868..ff150fe 100644
--- a/hw/usb/Makefile.objs
+++ b/hw/usb/Makefile.objs
@@ -11,6 +11,7 @@ common-obj-$(CONFIG_USB_EHCI_PCI) += hcd-ehci-pci.o
 common-obj-$(CONFIG_USB_EHCI_SYSBUS) += hcd-ehci-sysbus.o
 common-obj-$(CONFIG_USB_XHCI) += hcd-xhci.o
 common-obj-$(CONFIG_USB_XHCI_NEC) += hcd-xhci-nec.o
+common-obj-$(CONFIG_USB_XHCI_PCI) += hcd-xhci-pci.o
 common-obj-$(CONFIG_USB_MUSB) += hcd-musb.o
 
 common-obj-$(CONFIG_TUSB6010) += tusb6010.o
diff --git a/hw/usb/hcd-xhci-nec.c b/hw/usb/hcd-xhci-nec.c
index e6a5a22..e1a29bf 100644
--- a/hw/usb/hcd-xhci-nec.c
+++ b/hw/usb/hcd-xhci-nec.c
@@ -25,11 +25,11 @@
 #include "hw/pci/pci.h"
 #include "hw/qdev-properties.h"
 
-#include "hcd-xhci.h"
+#include "hcd-xhci-pci.h"
 
 static Property nec_xhci_properties[] = {
-DEFINE_PROP_ON_OFF_AUTO("msi", XHCIState, msi, ON_OFF_AUTO_AUTO),
-DEFINE_PROP_ON_OFF_AUTO("msix", XHCIState, msix, ON_OFF_AUTO_AUTO),
+DEFINE_PROP_ON_OFF_AUTO("msi", XHCIPciState, msi, ON_OFF_AUTO_AUTO),
+DEFINE_PROP_ON_OFF_AUTO("msix", XHCIPciState, msix, ON_OFF_AUTO_AUTO),
 DEFINE_PROP_BIT("superspeed-ports-first",
 XHCIState, flags, XHCI_FLAG_SS_FIRST, true),
 DEFINE_PROP_BIT("force-pcie-endcap", XHCIState, flags,
@@ -52,7 +52,7 @@ static void nec_xhci_class_init(ObjectClass *klass, void 
*data)
 
 static const TypeInfo nec_xhci_info = {
 .name  = TYPE_NEC_XHCI,
-.parent= TYPE_XHCI,
+.parent= TYPE_XHCI_PCI,
 .class_init= nec_xhci_class_init,
 };
 
diff --git a/hw/usb/hcd-xhci-pci.c b/hw/usb/hcd-xhci-pci.c
index 26af683..fb51ddf 100644
--- a/hw/usb/hcd-xhci-pci.c
+++ b/hw/usb/hcd-xhci-pci.c
@@ -23,12 +23,192 @@
 #include "qemu/osdep.h"
 #include "hw/pci/pci.h"
 #include "hw/qdev-properties.h"
+#include "migration/vmstate.h"
 #include "hw/pci/msi.h"
 #include "hw/pci/msix.h"
-#include "hcd-xhci.h"
+#include "hcd-xhci-pci.h"
 #include "trace.h"
 #include "qapi/error.h"
 
+#define OFF_MSIX_TABLE  0x3000
+#define OFF_MSIX_PBA0x3800
+
+static void xhci_pci_intr_update(void *opaque, int n, bool enable)
+{
+XHCIPciState *s = XHCI_PCI(opaque);
+PCIDevice *pci_dev = PCI_DEVICE(opaque);
+
+if (!msix_enabled(pci_dev)) {
+return;
+}
+if (enable == !!s->msix_used[n]) {
+return;
+}
+if (enable) {
+trace_usb_xhci_irq_msix_use(n);
+msix_vector_use(pci_dev, n);
+s->msix_used[n] = 1;
+} else {
+trace_usb_xhci_irq_msix_unuse(n);
+msix_vector_unuse(pci_dev, n);
+s->msix_used[n] = 0;
+}
+}
+
+static void xhci_pci_intr_raise(void *opaque, int n, bool level)
+{
+PCIDevice *pci_dev = PCI_DEVICE(opaque);
+
+if (n == 0 &&
+!(msix_enabled(pci_dev) ||
+ msi_enabled(pci_dev))) {
+pci_set_irq(pci_dev, level);
+}
+if (msix_enabled(pci_dev)) {
+msix_notify(pci_dev, n);
+return;
+}
+
+if (msi_enabled(pci_dev)) {
+msi_notify(pci_dev, n);
+return;
+}
+}
+
+static void xhci_pci_reset(DeviceState *dev)
+{
+XHCIPciState *s = XHCI_PCI(dev);
+
+device_legacy_reset(DEVICE(s->xhci));
+}
+
+static void usb_xhci_pci_realize(struct PCIDevice *dev, Error **errp)
+{
+int ret;
+Error *err = NULL;
+XHCIPciState *s = XHCI_PCI(dev);
+DeviceState *xhci_dev = DEVICE(s->xhci);
+
+dev->config[PCI_CLASS_PROG] = 0x30;/* xHCI */
+dev->config[PCI_INTERRUPT_PIN] = 0x01; /* interrupt pin 1 */
+dev->config[PCI_CACHE_LINE_SIZE] = 0x10;
+dev->config[0x60] = 0x30; /* release number */
+
+qdev_prop_set_bit(xhci_dev, "streams", s->enable_streams);
+qdev_prop_set_uint32(xhci_dev, "p2", s->numports_2);
+qdev_prop_set_uint32(xhci_dev, "p3", s->numports_3);
+object_property_set_link(OBJECT(xhci_dev), OBJECT(s), "host", NULL);
+qdev_init_nofail(xhci_dev);
+s->xhci = XHCI(xhci_dev);
+  

[PATCH 0/3] Make hcd-xhci independent of pci hooks

2020-03-02 Thread Sai Pavan Boddu
Hi,

This patch series attempts to make 'hcd-xhci' an independent model so
it can be used by both pci and system-bus interface.

Regards,
Sai Pavan

Sai Pavan Boddu (3):
  usb/hcd-xhci: Make dma read/writes hooks pci free
  usb/hcd-xhci: Move qemu-xhci device to hcd-xhci-pci.c
  usb/hcd-xhci: Split pci wrapper for xhci base model

 hw/usb/Kconfig|   6 ++
 hw/usb/Makefile.objs  |   1 +
 hw/usb/hcd-xhci-nec.c |   8 +-
 hw/usb/hcd-xhci-pci.c | 246 ++
 hw/usb/hcd-xhci-pci.h |  47 ++
 hw/usb/hcd-xhci.c | 230 --
 hw/usb/hcd-xhci.h |  17 ++--
 7 files changed, 351 insertions(+), 204 deletions(-)
 create mode 100644 hw/usb/hcd-xhci-pci.c
 create mode 100644 hw/usb/hcd-xhci-pci.h

-- 
2.7.4




[PATCH 2/3] usb/hcd-xhci: Move qemu-xhci device to hcd-xhci-pci.c

2020-03-02 Thread Sai Pavan Boddu
Move pci specific devices to new file. This set the environment to move all
pci specific hooks in hcd-xhci.c to hcd-xhci-pci.c.

Signed-off-by: Sai Pavan Boddu 
---
 hw/usb/hcd-xhci-pci.c | 64 +++
 hw/usb/hcd-xhci.c | 40 ++--
 hw/usb/hcd-xhci.h |  2 ++
 3 files changed, 68 insertions(+), 38 deletions(-)
 create mode 100644 hw/usb/hcd-xhci-pci.c

diff --git a/hw/usb/hcd-xhci-pci.c b/hw/usb/hcd-xhci-pci.c
new file mode 100644
index 000..26af683
--- /dev/null
+++ b/hw/usb/hcd-xhci-pci.c
@@ -0,0 +1,64 @@
+/*
+ * USB xHCI controller with PCI system bus emulation
+ *
+ * Copyright (c) 2011 Securiforest
+ * Date: 2011-05-11 ;  Author: Hector Martin 
+ * Based on usb-ohci.c, emulates Renesas NEC USB 3.0
+ * Date: 2020-03-01; Author: Sai Pavan Boddu 
+ * Moved the pci specific content for hcd-xhci.c to hcd-xhci-pci.c
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ */
+#include "qemu/osdep.h"
+#include "hw/pci/pci.h"
+#include "hw/qdev-properties.h"
+#include "hw/pci/msi.h"
+#include "hw/pci/msix.h"
+#include "hcd-xhci.h"
+#include "trace.h"
+#include "qapi/error.h"
+
+static void qemu_xhci_class_init(ObjectClass *klass, void *data)
+{
+PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+k->vendor_id= PCI_VENDOR_ID_REDHAT;
+k->device_id= PCI_DEVICE_ID_REDHAT_XHCI;
+k->revision = 0x01;
+}
+
+static void qemu_xhci_instance_init(Object *obj)
+{
+XHCIState *xhci = XHCI(obj);
+
+xhci->msi  = ON_OFF_AUTO_OFF;
+xhci->msix = ON_OFF_AUTO_AUTO;
+xhci->numintrs = MAXINTRS;
+xhci->numslots = MAXSLOTS;
+xhci_set_flag(xhci, XHCI_FLAG_SS_FIRST);
+}
+
+static const TypeInfo qemu_xhci_info = {
+.name  = TYPE_QEMU_XHCI,
+.parent= TYPE_XHCI,
+.class_init= qemu_xhci_class_init,
+.instance_init = qemu_xhci_instance_init,
+};
+
+static void xhci_register_types(void)
+{
+type_register_static(&qemu_xhci_info);
+}
+
+type_init(xhci_register_types)
diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c
index 6e88670..ba07ca2 100644
--- a/hw/usb/hcd-xhci.c
+++ b/hw/usb/hcd-xhci.c
@@ -429,12 +429,12 @@ static const char *ep_state_name(uint32_t state)
ARRAY_SIZE(ep_state_names));
 }
 
-static bool xhci_get_flag(XHCIState *xhci, enum xhci_flags bit)
+bool xhci_get_flag(XHCIState *xhci, enum xhci_flags bit)
 {
 return xhci->flags & (1 << bit);
 }
 
-static void xhci_set_flag(XHCIState *xhci, enum xhci_flags bit)
+void xhci_set_flag(XHCIState *xhci, enum xhci_flags bit)
 {
 xhci->flags |= (1 << bit);
 }
@@ -3691,13 +3691,6 @@ static Property xhci_properties[] = {
 DEFINE_PROP_END_OF_LIST(),
 };
 
-static void xhci_instance_init(Object *obj)
-{
-/* QEMU_PCI_CAP_EXPRESS initialization does not depend on QEMU command
- * line, therefore, no need to wait to realize like other devices */
-PCI_DEVICE(obj)->cap_present |= QEMU_PCI_CAP_EXPRESS;
-}
-
 static void xhci_class_init(ObjectClass *klass, void *data)
 {
 PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
@@ -3717,7 +3710,6 @@ static const TypeInfo xhci_info = {
 .parent= TYPE_PCI_DEVICE,
 .instance_size = sizeof(XHCIState),
 .class_init= xhci_class_init,
-.instance_init = xhci_instance_init,
 .abstract  = true,
 .interfaces = (InterfaceInfo[]) {
 { INTERFACE_PCIE_DEVICE },
@@ -3726,37 +3718,9 @@ static const TypeInfo xhci_info = {
 },
 };
 
-static void qemu_xhci_class_init(ObjectClass *klass, void *data)
-{
-PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
-
-k->vendor_id= PCI_VENDOR_ID_REDHAT;
-k->device_id= PCI_DEVICE_ID_REDHAT_XHCI;
-k->revision = 0x01;
-}
-
-static void qemu_xhci_instance_init(Object *obj)
-{
-XHCIState *xhci = XHCI(obj);
-
-xhci->msi  = ON_OFF_AUTO_OFF;
-xhci->msix = ON_OFF_AUTO_AUTO;
-xhci->numintrs = MAXINTRS;
-xhci->numslots = MAXSLOTS;
-xhci_set_flag(xhci, XHCI_FLAG_SS_FIRST);
-}
-
-static const TypeInfo qemu_xhci_info = {
-.name  = TYPE_QEMU_XHCI,
-.parent= TYPE_XHCI,
-.class_init= qemu_xhci_class_init,
-.instance_init = qemu_xhci_instance_init,
-};
-
 static void xhci_register_types(void)
 {
 type_register_static(&xhci_info);
-type_register_static(&qemu_xhci_info);
 }
 
 ty

Re: [PULL 4/9] hw/display/artist: Avoid drawing line when nothing to display

2020-03-02 Thread Philippe Mathieu-Daudé

On 2/29/20 10:31 AM, Sven Schnelle wrote:

On Tue, Feb 18, 2020 at 11:39:24AM -0800, Richard Henderson wrote:

From: Philippe Mathieu-Daudé 

Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20200214001303.12873-5-f4...@amsat.org>
Signed-off-by: Richard Henderson 
---
  hw/display/artist.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/hw/display/artist.c b/hw/display/artist.c
index 97c811b35e..5492079116 100644
--- a/hw/display/artist.c
+++ b/hw/display/artist.c
@@ -579,6 +579,9 @@ static void draw_line(ARTISTState *s, int x1, int y1, int 
x2, int y2,
  } else {
  dy = y1 - y2;
  }
+if (!dx || !dy) {
+return;
+}
  
  c1 = false;

  if (dy > dx) {
--
2.20.1




I noticed that this change causes 1px wide lines to disappear. So i would 
propose
to revert that change.


Maybe "if (!dx && !dy) { return; }"?



Regards
Sven






Re: [PATCH v2 1/2] tests/vhost-user-bridge: move to contrib/

2020-03-02 Thread Laurent Vivier
On 01/03/2020 13:12, Michael S. Tsirkin wrote:
> On Fri, Feb 07, 2020 at 10:54:11AM +0100, Laurent Vivier wrote:
>> vhost-user-bridge is not a test. Move it to contrib/ and
>> add it to the tools list.
>>
>> It will be built only if tools (--enable-tools) and
>> vhost-user (--enable-vhost-user) are enabled (both are set
>> by default).
>>
>> Suggested-by: Dr. David Alan Gilbert 
>> Signed-off-by: Laurent Vivier 
>> Reviewed-by: Philippe Mathieu-Daudé 
> 
> 
> I had to drop this series from my tree since it cause failures
> on OSX. Pls use something like travis CI to test when you repost
> a fixed version. Thanks!
> 

Do you have a link to the error logs?

Thanks,
Laurent




[PATCH 5/5] block/io: auto-no-fallback for write-zeroes

2020-03-02 Thread Vladimir Sementsov-Ogievskiy
NBD driver may has max_pwrite_zeroes but doesn't has
max_pwrite_zeroes_no_fallback limit. This means, that (when
BDRV_REQ_NO_FALLBACK is supported) it is beneficial to try send request
with BDRV_REQ_NO_FALLBACK instead of splitting the request accordingly
to max_pwrite_zeroes.

If failed, fallback to old behavior.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block/io.c | 30 ++
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/block/io.c b/block/io.c
index c64566b4cf..48d71b0883 100644
--- a/block/io.c
+++ b/block/io.c
@@ -1752,17 +1752,28 @@ static int coroutine_fn 
bdrv_co_do_pwrite_zeroes(BlockDriverState *bs,
 int head = 0;
 int tail = 0;
 
-int max_write_zeroes = MIN_NON_ZERO((flags & BDRV_REQ_NO_FALLBACK) ?
-bs->bl.max_pwrite_zeroes_no_fallback :
-bs->bl.max_pwrite_zeroes, INT_MAX);
+int max_write_zeroes;
 int alignment = MAX(bs->bl.pwrite_zeroes_alignment,
 bs->bl.request_alignment);
 int max_transfer = MIN_NON_ZERO(bs->bl.max_transfer, MAX_BOUNCE_BUFFER);
+bool auto_no_fallback;
 
 if (!drv) {
 return -ENOMEDIUM;
 }
 
+if (!(flags & BDRV_REQ_NO_FALLBACK) &&
+(bs->supported_zero_flags & BDRV_REQ_NO_FALLBACK) &&
+bs->bl.max_pwrite_zeroes &&
+bs->bl.max_pwrite_zeroes < bytes &&
+(bs->bl.max_pwrite_zeroes < bs->bl.max_pwrite_zeroes_no_fallback ||
+ bs->bl.max_pwrite_zeroes_no_fallback == 0))
+{
+assert(drv->bdrv_co_pwrite_zeroes);
+flags |= BDRV_REQ_NO_FALLBACK;
+auto_no_fallback = true;
+}
+
 if ((flags & ~bs->supported_zero_flags) & BDRV_REQ_NO_FALLBACK) {
 return -ENOTSUP;
 }
@@ -1770,7 +1781,11 @@ static int coroutine_fn 
bdrv_co_do_pwrite_zeroes(BlockDriverState *bs,
 assert(alignment % bs->bl.request_alignment == 0);
 head = offset % alignment;
 tail = (offset + bytes) % alignment;
-max_write_zeroes = QEMU_ALIGN_DOWN(max_write_zeroes, alignment);
+max_write_zeroes =
+QEMU_ALIGN_DOWN(MIN_NON_ZERO((flags & BDRV_REQ_NO_FALLBACK) ?
+ bs->bl.max_pwrite_zeroes_no_fallback :
+ bs->bl.max_pwrite_zeroes, INT_MAX),
+alignment);
 assert(max_write_zeroes >= bs->bl.request_alignment);
 
 while (bytes > 0 && !ret) {
@@ -1801,6 +1816,13 @@ static int coroutine_fn 
bdrv_co_do_pwrite_zeroes(BlockDriverState *bs,
 if (drv->bdrv_co_pwrite_zeroes) {
 ret = drv->bdrv_co_pwrite_zeroes(bs, offset, num,
  flags & bs->supported_zero_flags);
+if (ret == -ENOTSUP && auto_no_fallback) {
+flags &= ~BDRV_REQ_NO_FALLBACK;
+max_write_zeroes =
+QEMU_ALIGN_DOWN(MIN_NON_ZERO(bs->bl.max_pwrite_zeroes,
+ INT_MAX), alignment);
+continue;
+}
 if (ret != -ENOTSUP && (flags & BDRV_REQ_FUA) &&
 !(bs->supported_zero_flags & BDRV_REQ_FUA)) {
 need_flush = true;
-- 
2.21.0




[PATCH 2/5] block/nbd-client: drop max_block restriction from discard

2020-03-02 Thread Vladimir Sementsov-Ogievskiy
NBD spec is updated, so that max_block doesn't relate to
NBD_CMD_TRIM. So, drop the restriction.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block/nbd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/block/nbd.c b/block/nbd.c
index 2a58d6b91c..a62761ea5a 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -1955,7 +1955,6 @@ static void nbd_refresh_limits(BlockDriverState *bs, 
Error **errp)
 }
 
 bs->bl.request_alignment = min;
-bs->bl.max_pdiscard = max;
 bs->bl.max_pwrite_zeroes = max;
 bs->bl.max_transfer = max;
 
-- 
2.21.0




[PATCH 3/5] block: add max_pwrite_zeroes_no_fallback to BlockLimits

2020-03-02 Thread Vladimir Sementsov-Ogievskiy
NBD spec is updated, so that max_block doesn't relate to
NBD_CMD_WRITE_ZEROES with NBD_CMD_FLAG_FAST_ZERO (which mirrors Qemu
flag BDRV_REQ_NO_FALLBACK). To drop the restriction we need new
max_pwrite_zeroes_no_fallback.

Default value of new max_pwrite_zeroes_no_fallback is zero and it means
no-restriction, so we are automatically done by this commit. Note that
nbd and blkdebug are the only drivers which in the same time define
max_pwrite_zeroes limit and support BDRV_REQ_NO_FALLBACK, so we need to
update only blkdebug.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 include/block/block_int.h | 8 
 block/blkdebug.c  | 7 ++-
 block/io.c| 4 +++-
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/include/block/block_int.h b/include/block/block_int.h
index 6f9fd5e20e..c167e887c6 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -618,6 +618,14 @@ typedef struct BlockLimits {
  * pwrite_zeroes_alignment. May be 0 if no inherent 32-bit limit */
 int32_t max_pwrite_zeroes;
 
+/*
+ * Maximum number of bytes that can zeroized at once if flag
+ * BDRV_REQ_NO_FALLBACK specified (since it is signed, it must be < 2G, if
+ * set). Must be multiple of pwrite_zeroes_alignment. May be 0 if no
+ * inherent 32-bit limit.
+ */
+int32_t max_pwrite_zeroes_no_fallback;
+
 /* Optimal alignment for write zeroes requests in bytes. A power
  * of 2 is best but not mandatory.  Must be a multiple of
  * bl.request_alignment, and must be less than max_pwrite_zeroes
diff --git a/block/blkdebug.c b/block/blkdebug.c
index af44aa973f..7627fbcb3b 100644
--- a/block/blkdebug.c
+++ b/block/blkdebug.c
@@ -692,7 +692,11 @@ static int coroutine_fn 
blkdebug_co_pwrite_zeroes(BlockDriverState *bs,
 }
 assert(QEMU_IS_ALIGNED(offset, align));
 assert(QEMU_IS_ALIGNED(bytes, align));
-if (bs->bl.max_pwrite_zeroes) {
+if ((flags & BDRV_REQ_NO_FALLBACK) &&
+bs->bl.max_pwrite_zeroes_no_fallback)
+{
+assert(bytes <= bs->bl.max_pwrite_zeroes_no_fallback);
+} else if (bs->bl.max_pwrite_zeroes) {
 assert(bytes <= bs->bl.max_pwrite_zeroes);
 }
 
@@ -977,6 +981,7 @@ static void blkdebug_refresh_limits(BlockDriverState *bs, 
Error **errp)
 }
 if (s->max_write_zero) {
 bs->bl.max_pwrite_zeroes = s->max_write_zero;
+bs->bl.max_pwrite_zeroes_no_fallback = s->max_write_zero;
 }
 if (s->opt_discard) {
 bs->bl.pdiscard_alignment = s->opt_discard;
diff --git a/block/io.c b/block/io.c
index 7e4cb74cf4..75fd5600c2 100644
--- a/block/io.c
+++ b/block/io.c
@@ -1752,7 +1752,9 @@ static int coroutine_fn 
bdrv_co_do_pwrite_zeroes(BlockDriverState *bs,
 int head = 0;
 int tail = 0;
 
-int max_write_zeroes = MIN_NON_ZERO(bs->bl.max_pwrite_zeroes, INT_MAX);
+int max_write_zeroes = MIN_NON_ZERO((flags & BDRV_REQ_NO_FALLBACK) ?
+bs->bl.max_pwrite_zeroes_no_fallback :
+bs->bl.max_pwrite_zeroes, INT_MAX);
 int alignment = MAX(bs->bl.pwrite_zeroes_alignment,
 bs->bl.request_alignment);
 int max_transfer = MIN_NON_ZERO(bs->bl.max_transfer, MAX_BOUNCE_BUFFER);
-- 
2.21.0




[PATCH 1/5] block/nbd-client: drop max_block restriction from block_status

2020-03-02 Thread Vladimir Sementsov-Ogievskiy
NBD spec is updated, so that max_block doesn't relate to
NBD_CMD_BLOCK_STATUS. So, drop the restriction.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block/nbd.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/block/nbd.c b/block/nbd.c
index 976be76647..2a58d6b91c 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -1320,9 +1320,7 @@ static int coroutine_fn nbd_client_co_block_status(
 NBDRequest request = {
 .type = NBD_CMD_BLOCK_STATUS,
 .from = offset,
-.len = MIN(MIN_NON_ZERO(QEMU_ALIGN_DOWN(INT_MAX,
-bs->bl.request_alignment),
-s->info.max_block),
+.len = MIN(QEMU_ALIGN_DOWN(INT_MAX, bs->bl.request_alignment),
MIN(bytes, s->info.size - offset)),
 .flags = NBD_CMD_FLAG_REQ_ONE,
 };
-- 
2.21.0




[PATCH 0/5] nbd: reduce max_block restrictions

2020-03-02 Thread Vladimir Sementsov-Ogievskiy
Recent changes in NBD protocol allowed to use some commands without
max_block restriction. Let's drop restrictions.

NBD change is here:
https://github.com/NetworkBlockDevice/nbd/commit/9f30fedb8699f151e7ef4ccc07e624330be3316b#diff-762fb7c670348da69cc9050ef58fe3ae

Vladimir Sementsov-Ogievskiy (5):
  block/nbd-client: drop max_block restriction from block_status
  block/nbd-client: drop max_block restriction from discard
  block: add max_pwrite_zeroes_no_fallback to BlockLimits
  block/io: fix bdrv_co_do_pwrite_zeroes head calculation
  block/io: auto-no-fallback for write-zeroes

 include/block/block_int.h |  8 
 block/blkdebug.c  |  7 ++-
 block/io.c| 32 +---
 block/nbd.c   |  5 +
 4 files changed, 44 insertions(+), 8 deletions(-)

-- 
2.21.0




[PATCH 4/5] block/io: fix bdrv_co_do_pwrite_zeroes head calculation

2020-03-02 Thread Vladimir Sementsov-Ogievskiy
It's wrong to update head using num in this place, as num may be
reduced during the iteration, and we'll have wrong head value on next
iteration.

Instead update head at iteration end.

Cc: qemu-sta...@nongnu.org
Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block/io.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/block/io.c b/block/io.c
index 75fd5600c2..c64566b4cf 100644
--- a/block/io.c
+++ b/block/io.c
@@ -1785,7 +1785,6 @@ static int coroutine_fn 
bdrv_co_do_pwrite_zeroes(BlockDriverState *bs,
  * convenience, limit this request to max_transfer even if
  * we don't need to fall back to writes.  */
 num = MIN(MIN(bytes, max_transfer), alignment - head);
-head = (head + num) % alignment;
 assert(num < max_write_zeroes);
 } else if (tail && num > alignment) {
 /* Shorten the request to the last aligned sector.  */
@@ -1844,6 +1843,9 @@ static int coroutine_fn 
bdrv_co_do_pwrite_zeroes(BlockDriverState *bs,
 
 offset += num;
 bytes -= num;
+if (head) {
+head = offset % alignment;
+}
 }
 
 fail:
-- 
2.21.0




Re: [PATCH v3 0/4] misc: Improve error reporting on Windows

2020-03-02 Thread Markus Armbruster
Philippe Mathieu-Daudé  writes:

> Few patches to improve bug reports on Windows.
> (i.e. https://bugs.launchpad.net/qemu/+bug/1657841)

Queued, thanks!




Re: qemu-system-x86_64: warning: Unknown X11 keycode mapping ''.

2020-03-02 Thread Daniel P . Berrangé
On Mon, Mar 02, 2020 at 12:04:46AM +0100, Thorsten Glaser wrote:
> I got this while running qemu under VNC, and was told to report it.
> 
> including the following information:
> 
>   - Operating system
>   Debian GNU/Linux sid/x32
>   - X11 Server
>   x11vnc  0.9.16-3

Can you tell me a bit more detail about how you launch this all.

"x11vnc" suggests you had a regular X11 desktop session, and are
exporting it via VNC ?

But later...

>   - xdpyinfo
>   name of display::2
>   version number:11.0
>   vendor string:AT&T Laboratories Cambridge

...this suggests your running a VNC server, with embedded X11 server


>   - xprop -root

...there's no _XKB_RULES_NAMES(STRING) property listed, which is the key
thing we'd expect to see for a modern X server. eg

  _XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us", "", ""

is what most X servers on Linux will report.

Can you also say what QEMU version ?

QEMU since 2.12.0 or later has a second way to detect the keymap, by
querying the scancode mapping for certain keys.

So either your QEMU is fairly old, or you are using a keycode mapping
that QEMU has no understanding of (we support evdev, or the classic
xfree86 'kbd' mapping). It would be highly unusual not to use one of
those two, but none the less, that appears to be the case here ?


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: [PATCH] vhost-vsock: fix error message output

2020-03-02 Thread Ján Tomko

On a Sunday in 2020, Nick Erdmann wrote:

error_setg_errno takes a positive error number, so we should not invert
errno's sign.

Signed-off-by: Nick Erdmann 
---
hw/virtio/vhost-vsock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)



Reviewed-by: Ján Tomko 

Jano


signature.asc
Description: PGP signature


Re: [PULL 0/4] Machine queue, 2020-02-28

2020-03-02 Thread Peter Maydell
On Fri, 28 Feb 2020 at 21:04, Eduardo Habkost  wrote:
>
> The following changes since commit e0175b71638cf4398903c0d25f93fe62e0606389:
>
>   Merge remote-tracking branch 
> 'remotes/pmaydell/tags/pull-target-arm-20200228' into staging (2020-02-28 
> 16:39:27 +)
>
> are available in the Git repository at:
>
>   git://github.com/ehabkost/qemu.git tags/machine-next-pull-request
>
> for you to fetch changes up to 6db1857ec9960c63024f4ce6329d947f727bad39:
>
>   vl: Abort if multiple machines are registered as default (2020-02-28 
> 14:57:19 -0500)
>
> 
> Machine queue, 2020-02-28
>
> Cleanups:
> * Fix NMI() macro (Philippe Mathieu-Daudé)
> * Make MachineClass::is_default boolean, refuse multiple
>   default machines (Philippe Mathieu-Daudé)
>
> 


Applied, thanks.

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

-- PMM



Re: [PATCH v2 1/2] tests/vhost-user-bridge: move to contrib/

2020-03-02 Thread Michael S. Tsirkin
On Mon, Mar 02, 2020 at 10:50:16AM +0100, Laurent Vivier wrote:
> On 01/03/2020 13:12, Michael S. Tsirkin wrote:
> > On Fri, Feb 07, 2020 at 10:54:11AM +0100, Laurent Vivier wrote:
> >> vhost-user-bridge is not a test. Move it to contrib/ and
> >> add it to the tools list.
> >>
> >> It will be built only if tools (--enable-tools) and
> >> vhost-user (--enable-vhost-user) are enabled (both are set
> >> by default).
> >>
> >> Suggested-by: Dr. David Alan Gilbert 
> >> Signed-off-by: Laurent Vivier 
> >> Reviewed-by: Philippe Mathieu-Daudé 
> > 
> > 
> > I had to drop this series from my tree since it cause failures
> > on OSX. Pls use something like travis CI to test when you repost
> > a fixed version. Thanks!
> > 
> 
> Do you have a link to the error logs?
> 
> Thanks,
> Laurent


Peter sent me this:


Hi; this fails to build on OSX:

  CC  contrib/libvhost-user/libvhost-user.o
/Users/pm215/src/qemu-for-merges/contrib/libvhost-user/libvhost-user.c:27:10:
fatal error: 'sys/eventfd.h' file not found
#include 
 ^~~
In file included from
/Users/pm215/src/qemu-for-merges/contrib/vhost-user-bridge/main.c:37:
/Users/pm215/src/qemu-for-merges/contrib/libvhost-user/libvhost-user.h:21:10:
fatal error: 'linux/vhost.h' file not found
#include 
 ^~~
1 error generated.

thanks
-- PMM

But pls do test on OSX before reposting.

-- 
MST




[PATCH v3 2/6] hw/arm/virt: Introduce VirtGICType enum type

2020-03-02 Thread Eric Auger
We plan to introduce yet another value for the gic version (nosel).
As we already use exotic values such as 0 and -1, let's introduce
a dedicated enum type and let vms->gic_version take this
type.

Signed-off-by: Eric Auger 

---

v2 -> v3:
- replaced defines by enum VirtGICType
- use that new type for vms->gic_version
---
 hw/arm/virt.c | 30 +++---
 include/hw/arm/virt.h | 11 +--
 2 files changed, 24 insertions(+), 17 deletions(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index c093f0ab85..b449a445de 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -298,7 +298,7 @@ static void fdt_add_timer_nodes(const VirtMachineState *vms)
 irqflags = GIC_FDT_IRQ_FLAGS_EDGE_LO_HI;
 }
 
-if (vms->gic_version == 2) {
+if (vms->gic_version == VIRT_GIC_VERSION_2) {
 irqflags = deposit32(irqflags, GIC_FDT_IRQ_PPI_CPU_START,
  GIC_FDT_IRQ_PPI_CPU_WIDTH,
  (1 << vms->smp_cpus) - 1);
@@ -439,7 +439,7 @@ static void fdt_add_gic_node(VirtMachineState *vms)
 qemu_fdt_setprop_cell(vms->fdt, nodename, "#address-cells", 0x2);
 qemu_fdt_setprop_cell(vms->fdt, nodename, "#size-cells", 0x2);
 qemu_fdt_setprop(vms->fdt, nodename, "ranges", NULL, 0);
-if (vms->gic_version == 3) {
+if (vms->gic_version == VIRT_GIC_VERSION_3) {
 int nb_redist_regions = virt_gicv3_redist_region_count(vms);
 
 qemu_fdt_setprop_string(vms->fdt, nodename, "compatible",
@@ -518,7 +518,7 @@ static void fdt_add_pmu_nodes(const VirtMachineState *vms)
 }
 }
 
-if (vms->gic_version == 2) {
+if (vms->gic_version == VIRT_GIC_VERSION_2) {
 irqflags = deposit32(irqflags, GIC_FDT_IRQ_PPI_CPU_START,
  GIC_FDT_IRQ_PPI_CPU_WIDTH,
  (1 << vms->smp_cpus) - 1);
@@ -1469,7 +1469,7 @@ static uint64_t virt_cpu_mp_affinity(VirtMachineState 
*vms, int idx)
  * purposes are to make TCG consistent (with 64-bit KVM hosts)
  * and to improve SGI efficiency.
  */
-if (vms->gic_version == 3) {
+if (vms->gic_version == VIRT_GIC_VERSION_3) {
 clustersz = GICV3_TARGETLIST_BITS;
 } else {
 clustersz = GIC_TARGETLIST_BITS;
@@ -1560,15 +1560,15 @@ static void machvirt_init(MachineState *machine)
 /* We can probe only here because during property set
  * KVM is not available yet
  */
-if (vms->gic_version <= 0) {
-/* "host" or "max" */
+if (vms->gic_version == VIRT_GIC_VERSION_HOST ||
+vms->gic_version == VIRT_GIC_VERSION_MAX) {
 if (!kvm_enabled()) {
-if (vms->gic_version == 0) {
+if (vms->gic_version == VIRT_GIC_VERSION_HOST) {
 error_report("gic-version=host requires KVM");
 exit(1);
 } else {
 /* "max": currently means 3 for TCG */
-vms->gic_version = 3;
+vms->gic_version = VIRT_GIC_VERSION_3;
 }
 } else {
 vms->gic_version = kvm_arm_vgic_probe();
@@ -1627,7 +1627,7 @@ static void machvirt_init(MachineState *machine)
 /* The maximum number of CPUs depends on the GIC version, or on how
  * many redistributors we can fit into the memory map.
  */
-if (vms->gic_version == 3) {
+if (vms->gic_version == VIRT_GIC_VERSION_3) {
 virt_max_cpus =
 vms->memmap[VIRT_GIC_REDIST].size / GICV3_REDIST_SIZE;
 virt_max_cpus +=
@@ -1855,7 +1855,7 @@ static void virt_set_its(Object *obj, bool value, Error 
**errp)
 static char *virt_get_gic_version(Object *obj, Error **errp)
 {
 VirtMachineState *vms = VIRT_MACHINE(obj);
-const char *val = vms->gic_version == 3 ? "3" : "2";
+const char *val = vms->gic_version == VIRT_GIC_VERSION_3 ? "3" : "2";
 
 return g_strdup(val);
 }
@@ -1865,13 +1865,13 @@ static void virt_set_gic_version(Object *obj, const 
char *value, Error **errp)
 VirtMachineState *vms = VIRT_MACHINE(obj);
 
 if (!strcmp(value, "3")) {
-vms->gic_version = 3;
+vms->gic_version = VIRT_GIC_VERSION_3;
 } else if (!strcmp(value, "2")) {
-vms->gic_version = 2;
+vms->gic_version = VIRT_GIC_VERSION_2;
 } else if (!strcmp(value, "host")) {
-vms->gic_version = 0; /* Will probe later */
+vms->gic_version = VIRT_GIC_VERSION_HOST; /* Will probe later */
 } else if (!strcmp(value, "max")) {
-vms->gic_version = -1; /* Will probe later */
+vms->gic_version = VIRT_GIC_VERSION_MAX; /* Will probe later */
 } else {
 error_setg(errp, "Invalid gic-version value");
 error_append_hint(errp, "Valid values are 3, 2, host, max.\n");
@@ -2139,7 +2139,7 @@ static void virt_instance_init(Object *obj)
 "physical address space above 32 bits",
 NULL);
 /* Default GIC type is v2 */
-vms->g

[PATCH v3 0/6] hw/arm/virt: kvm: allow gicv3 by default if v2 cannot work

2020-03-02 Thread Eric Auger
At the moment if the end-user does not specify the gic-version along
with KVM acceleration, v2 is set by default. However most of the
systems now have GICv3 and sometimes they do not support GICv2
compatibility. In that case we now end up with the following error:

"qemu-system-aarch64: Initialization of device kvm-arm-gic failed:
error creating in-kernel VGIC: No such device
Perhaps the host CPU does not support GICv2?"

since "1904f9b5f1  hw/intc/arm_gic_kvm: Don't assume kernel can
provide a GICv2" which already allowed to output an explicit error
message.

This patch keeps the default v2 selection in all cases except
in the KVM accelerated mode when v2 cannot work:
- either because the host does not support v2 in-kernel emulation or
- because more than 8 vcpus were requested.

Those cases did not work anyway so we do not break any compatibility.
Now we get v3 selected in such a case.

Best Regards

Eric

This series can be found at:
https://github.com/eauger/qemu/tree/v4.2.0-gic-version-v3

History:

v2 -> v3:
- replaced defines by VirtGICType enum type
- fixed some style issue
- collected Richard and Dres's R-b
  except on "hw/arm/virt: Introduce VirtGICType enum type" just
  to make sure this matches their expectation.

RFC -> v2:
- 1904f9b5f1  hw/intc/arm_gic_kvm: Don't assume kernel can
  provide a GICv2" now has landed upstream
- Fix gic-version description
- Introduce finalize_gic_version and use switch/cases
- take into account smp value

Eric Auger (6):
  hw/arm/virt: Document 'max' value in gic-version property description
  hw/arm/virt: Introduce VirtGICType enum type
  hw/arm/virt: Introduce finalize_gic_version()
  target/arm/kvm: Let kvm_arm_vgic_probe() return a bitmap
  hw/arm/virt: kvm: Check the chosen gic version is supported by the
host
  hw/arm/virt: kvm: allow gicv3 by default if v2 cannot work

 hw/arm/virt.c | 125 +++---
 include/hw/arm/virt.h |  12 +++-
 target/arm/kvm.c  |  14 +++--
 target/arm/kvm_arm.h  |   3 +
 4 files changed, 114 insertions(+), 40 deletions(-)

-- 
2.20.1




Re: [PATCH] block: make BlockConf.*_size properties 32-bit

2020-03-02 Thread Roman Kagan
On Thu, Feb 13, 2020 at 04:55:44PM +0300, Roman Kagan wrote:
> On Thu, Feb 13, 2020 at 06:47:10AM -0600, Eric Blake wrote:
> > On 2/13/20 2:01 AM, Roman Kagan wrote:
> > > On Wed, Feb 12, 2020 at 03:44:19PM -0600, Eric Blake wrote:
> > > > On 2/11/20 5:54 AM, Roman Kagan wrote:
> > > > > Devices (virtio-blk, scsi, etc.) and the block layer are happy to use
> > > > > 32-bit for logical_block_size, physical_block_size, and min_io_size.
> > > > > However, the properties in BlockConf are defined as uint16_t limiting
> > > > > the values to 32768.
> > > > > 
> > > > > This appears unnecessary tight, and we've seen bigger block sizes 
> > > > > handy
> > > > > at times.
> > > > 
> > > > What larger sizes?  I could see 64k or maybe even 1M block sizes,...
> > > 
> > > We played exactly with these two :)
> > > 
> > > > > 
> > > > > Make them 32 bit instead and lift the limitation.
> > > > > 
> > > > > Signed-off-by: Roman Kagan 
> > > > > ---
> > > > >hw/core/qdev-properties.c| 21 -
> > > > >include/hw/block/block.h |  8 
> > > > >include/hw/qdev-properties.h |  2 +-
> > > > >3 files changed, 17 insertions(+), 14 deletions(-)
> > > > > 
> > > > > diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
> > > > > index 7f93bfeb88..5f84e4a3b8 100644
> > > > > --- a/hw/core/qdev-properties.c
> > > > > +++ b/hw/core/qdev-properties.c
> > > > > @@ -716,30 +716,32 @@ const PropertyInfo qdev_prop_pci_devfn = {
> > > > >/* --- blocksize --- */
> > > > > +#define MIN_BLOCK_SIZE 512
> > > > > +#define MAX_BLOCK_SIZE 2147483648
> > > > 
> > > > ...but 2G block sizes are going to have tremendous performance problems.
> > > > 
> > > > I'm not necessarily opposed to the widening to a 32-bit type, but think 
> > > > you
> > > > need more justification or a smaller number for the max block size,
> > > 
> > > I thought any smaller value would just be arbitrary and hard to reason
> > > about, so I went ahead with the max value that fit in the type and could
> > > be made visibile to the guest.
> > 
> > You've got bigger problems than what is visible to the guest. block/qcow2.c
> > operates on a cluster at a time; if you are stating that it now requires
> > reading multiple clusters to operate on one, qcow2 will have to do lots of
> > wasteful read-modify-write cycles.
> 
> I'm failing to see how this is supposed to happen.  The guest will issue
> requests bigger than the cluster size; why would it cause RMW?
> 
> Big logical_block_size would cause RMW in the guest if it wants to
> perform smaller writes, but that's up to the user to take this tradeoff,
> isn't it?
> 
> > You really need a strong reason to
> > support a maximum larger than 2M other than just "so the guest can
> > experiment with it".
> 
> Do I get you right that your suggestion is to cap the block size
> property at 2MB?
> 
> Thanks,
> Roman.

Ping?

> > > 
> > > Besides this is a property that is set explicitly, so I don't see a
> > > problem leaving this up to the user.
> > > 
> > > > particularly since qcow2 refuses to use cluster sizes larger than 2M 
> > > > and it
> > > > makes no sense to allow a block size larger than a cluster size.
> > > 
> > > This still doesn't contradict passing a bigger value to the guest, for
> > > experimenting if nothing else.
> > > 
> > > Thanks,
> > > Roman.
> > > 
> > 
> > -- 
> > Eric Blake, Principal Software Engineer
> > Red Hat, Inc.   +1-919-301-3226
> > Virtualization:  qemu.org | libvirt.org
> > 
> 



[PATCH v3 1/6] hw/arm/virt: Document 'max' value in gic-version property description

2020-03-02 Thread Eric Auger
Mention 'max' value in the gic-version property description.

Signed-off-by: Eric Auger 
Reviewed-by: Richard Henderson 
Reviewed-by: Andrew Jones 
---
 hw/arm/virt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 856808599d..c093f0ab85 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -2144,7 +2144,8 @@ static void virt_instance_init(Object *obj)
 virt_set_gic_version, NULL);
 object_property_set_description(obj, "gic-version",
 "Set GIC version. "
-"Valid values are 2, 3 and host", NULL);
+"Valid values are 2, 3, host and max",
+NULL);
 
 vms->highmem_ecam = !vmc->no_highmem_ecam;
 
-- 
2.20.1




[PATCH v3 3/6] hw/arm/virt: Introduce finalize_gic_version()

2020-03-02 Thread Eric Auger
Let's move the code which freezes which gic-version to
be applied in a dedicated function. We also now set by
default the VIRT_GIC_VERSION_NO_SET. This eventually
turns into the legacy v2 choice in the finalize() function.

Signed-off-by: Eric Auger 
Reviewed-by: Richard Henderson 
Reviewed-by: Andrew Jones 

---

v2 -> v3:
- add NOTSEL value at the end of the new enum type
---
 hw/arm/virt.c | 54 ++-
 include/hw/arm/virt.h |  1 +
 2 files changed, 34 insertions(+), 21 deletions(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index b449a445de..338d56999f 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1534,6 +1534,37 @@ static void virt_set_memmap(VirtMachineState *vms)
 }
 }
 
+/*
+ * finalize_gic_version - Determines the final gic_version
+ * according to the gic-version property
+ *
+ * Default GIC type is v2
+ */
+static void finalize_gic_version(VirtMachineState *vms)
+{
+if (vms->gic_version == VIRT_GIC_VERSION_HOST ||
+vms->gic_version == VIRT_GIC_VERSION_MAX) {
+if (!kvm_enabled()) {
+if (vms->gic_version == VIRT_GIC_VERSION_HOST) {
+error_report("gic-version=host requires KVM");
+exit(1);
+} else {
+/* "max": currently means 3 for TCG */
+vms->gic_version = VIRT_GIC_VERSION_3;
+}
+} else {
+vms->gic_version = kvm_arm_vgic_probe();
+if (!vms->gic_version) {
+error_report(
+"Unable to determine GIC version supported by host");
+exit(1);
+}
+}
+} else if (vms->gic_version == VIRT_GIC_VERSION_NOSEL) {
+vms->gic_version = VIRT_GIC_VERSION_2;
+}
+}
+
 static void machvirt_init(MachineState *machine)
 {
 VirtMachineState *vms = VIRT_MACHINE(machine);
@@ -1560,25 +1591,7 @@ static void machvirt_init(MachineState *machine)
 /* We can probe only here because during property set
  * KVM is not available yet
  */
-if (vms->gic_version == VIRT_GIC_VERSION_HOST ||
-vms->gic_version == VIRT_GIC_VERSION_MAX) {
-if (!kvm_enabled()) {
-if (vms->gic_version == VIRT_GIC_VERSION_HOST) {
-error_report("gic-version=host requires KVM");
-exit(1);
-} else {
-/* "max": currently means 3 for TCG */
-vms->gic_version = VIRT_GIC_VERSION_3;
-}
-} else {
-vms->gic_version = kvm_arm_vgic_probe();
-if (!vms->gic_version) {
-error_report(
-"Unable to determine GIC version supported by host");
-exit(1);
-}
-}
-}
+ finalize_gic_version(vms);
 
 if (!cpu_type_valid(machine->cpu_type)) {
 error_report("mach-virt: CPU type %s not supported", 
machine->cpu_type);
@@ -2138,8 +2151,7 @@ static void virt_instance_init(Object *obj)
 "Set on/off to enable/disable using "
 "physical address space above 32 bits",
 NULL);
-/* Default GIC type is v2 */
-vms->gic_version = VIRT_GIC_VERSION_2;
+vms->gic_version = VIRT_GIC_VERSION_NOSEL;
 object_property_add_str(obj, "gic-version", virt_get_gic_version,
 virt_set_gic_version, NULL);
 object_property_set_description(obj, "gic-version",
diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
index c0827cacdf..893796d3b0 100644
--- a/include/hw/arm/virt.h
+++ b/include/hw/arm/virt.h
@@ -100,6 +100,7 @@ typedef enum VirtGICType {
 VIRT_GIC_VERSION_HOST,
 VIRT_GIC_VERSION_2,
 VIRT_GIC_VERSION_3,
+VIRT_GIC_VERSION_NOSEL,
 } VirtGICType;
 
 typedef struct MemMapEntry {
-- 
2.20.1




[PATCH v3 4/6] target/arm/kvm: Let kvm_arm_vgic_probe() return a bitmap

2020-03-02 Thread Eric Auger
Convert kvm_arm_vgic_probe() so that it returns a
bitmap of supported in-kernel emulation VGIC versions instead
of the max version: at the moment values can be v2 and v3.
This allows to expose the case where the host GICv3 also
supports GICv2 emulation. This will be useful to choose the
default version in KVM accelerated mode.

Signed-off-by: Eric Auger 
Reviewed-by: Andrew Jones 
Reviewed-by: Richard Henderson 
---
 hw/arm/virt.c| 11 +--
 target/arm/kvm.c | 14 --
 target/arm/kvm_arm.h |  3 +++
 3 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 338d56999f..eb8c57c85e 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1553,11 +1553,18 @@ static void finalize_gic_version(VirtMachineState *vms)
 vms->gic_version = VIRT_GIC_VERSION_3;
 }
 } else {
-vms->gic_version = kvm_arm_vgic_probe();
-if (!vms->gic_version) {
+int probe_bitmap = kvm_arm_vgic_probe();
+
+if (!probe_bitmap) {
 error_report(
 "Unable to determine GIC version supported by host");
 exit(1);
+} else {
+if (probe_bitmap & KVM_ARM_VGIC_V3) {
+vms->gic_version = VIRT_GIC_VERSION_3;
+} else {
+vms->gic_version = VIRT_GIC_VERSION_2;
+}
 }
 }
 } else if (vms->gic_version == VIRT_GIC_VERSION_NOSEL) {
diff --git a/target/arm/kvm.c b/target/arm/kvm.c
index 85860e6f95..390077c518 100644
--- a/target/arm/kvm.c
+++ b/target/arm/kvm.c
@@ -874,15 +874,17 @@ int kvm_arch_irqchip_create(KVMState *s)
 
 int kvm_arm_vgic_probe(void)
 {
+int val = 0;
+
 if (kvm_create_device(kvm_state,
   KVM_DEV_TYPE_ARM_VGIC_V3, true) == 0) {
-return 3;
-} else if (kvm_create_device(kvm_state,
- KVM_DEV_TYPE_ARM_VGIC_V2, true) == 0) {
-return 2;
-} else {
-return 0;
+val |= KVM_ARM_VGIC_V3;
 }
+if (kvm_create_device(kvm_state,
+  KVM_DEV_TYPE_ARM_VGIC_V2, true) == 0) {
+val |= KVM_ARM_VGIC_V2;
+}
+return val;
 }
 
 int kvm_arm_set_irq(int cpu, int irqtype, int irq, int level)
diff --git a/target/arm/kvm_arm.h b/target/arm/kvm_arm.h
index ae9e075d75..48bf5e16d5 100644
--- a/target/arm/kvm_arm.h
+++ b/target/arm/kvm_arm.h
@@ -15,6 +15,9 @@
 #include "exec/memory.h"
 #include "qemu/error-report.h"
 
+#define KVM_ARM_VGIC_V2   (1 << 0)
+#define KVM_ARM_VGIC_V3   (1 << 1)
+
 /**
  * kvm_arm_vcpu_init:
  * @cs: CPUState
-- 
2.20.1




[PATCH v3 5/6] hw/arm/virt: kvm: Check the chosen gic version is supported by the host

2020-03-02 Thread Eric Auger
Restructure the finalize_gic_version with switch cases and, in
KVM mode, explictly check whether the chosen version is supported
by the host.

if the end-user explicitly sets v2/v3 and this is not supported by
the host, then the user gets an explicit error message.

Signed-off-by: Eric Auger 
Reviewed-by: Richard Henderson 
Reviewed-by: Andrew Jones 

---

v2 -> v3:
- explictly list V2 and V3 in the switch/case
- fix indent
---
 hw/arm/virt.c | 77 +++
 1 file changed, 53 insertions(+), 24 deletions(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index eb8c57c85e..aeb6c45e51 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1542,33 +1542,62 @@ static void virt_set_memmap(VirtMachineState *vms)
  */
 static void finalize_gic_version(VirtMachineState *vms)
 {
-if (vms->gic_version == VIRT_GIC_VERSION_HOST ||
-vms->gic_version == VIRT_GIC_VERSION_MAX) {
-if (!kvm_enabled()) {
-if (vms->gic_version == VIRT_GIC_VERSION_HOST) {
-error_report("gic-version=host requires KVM");
-exit(1);
-} else {
-/* "max": currently means 3 for TCG */
-vms->gic_version = VIRT_GIC_VERSION_3;
-}
-} else {
-int probe_bitmap = kvm_arm_vgic_probe();
+if (kvm_enabled()) {
+int probe_bitmap = kvm_arm_vgic_probe();
 
-if (!probe_bitmap) {
-error_report(
-"Unable to determine GIC version supported by host");
-exit(1);
-} else {
-if (probe_bitmap & KVM_ARM_VGIC_V3) {
-vms->gic_version = VIRT_GIC_VERSION_3;
-} else {
-vms->gic_version = VIRT_GIC_VERSION_2;
-}
-}
+if (!probe_bitmap) {
+error_report("Unable to determine GIC version supported by host");
+exit(1);
 }
-} else if (vms->gic_version == VIRT_GIC_VERSION_NOSEL) {
+
+switch (vms->gic_version) {
+case VIRT_GIC_VERSION_NOSEL:
+vms->gic_version = VIRT_GIC_VERSION_2;
+break;
+case VIRT_GIC_VERSION_HOST:
+case VIRT_GIC_VERSION_MAX:
+if (probe_bitmap & KVM_ARM_VGIC_V3) {
+vms->gic_version = VIRT_GIC_VERSION_3;
+} else {
+vms->gic_version = VIRT_GIC_VERSION_2;
+}
+return;
+case VIRT_GIC_VERSION_2:
+case VIRT_GIC_VERSION_3:
+break;
+}
+
+if (!kvm_irqchip_in_kernel()) {
+return;
+}
+
+/* Check chosen version is effectively supported by the host */
+if (vms->gic_version == VIRT_GIC_VERSION_2 &&
+!(probe_bitmap & KVM_ARM_VGIC_V2)) {
+error_report("host does not support in-kernel GICv2 emulation");
+exit(1);
+} else if (vms->gic_version == VIRT_GIC_VERSION_3 &&
+   !(probe_bitmap & KVM_ARM_VGIC_V3)) {
+error_report("host does not support in-kernel GICv3 emulation");
+exit(1);
+}
+return;
+}
+
+/* TCG mode */
+switch (vms->gic_version) {
+case VIRT_GIC_VERSION_NOSEL:
 vms->gic_version = VIRT_GIC_VERSION_2;
+break;
+case VIRT_GIC_VERSION_MAX:
+vms->gic_version = VIRT_GIC_VERSION_3;
+break;
+case VIRT_GIC_VERSION_HOST:
+error_report("gic-version=host requires KVM");
+exit(1);
+case VIRT_GIC_VERSION_2:
+case VIRT_GIC_VERSION_3:
+break;
 }
 }
 
-- 
2.20.1




[PATCH v3 6/6] hw/arm/virt: kvm: allow gicv3 by default if v2 cannot work

2020-03-02 Thread Eric Auger
At the moment if the end-user does not specify the gic-version along
with KVM acceleration, v2 is set by default. However most of the
systems now have GICv3 and sometimes they do not support GICv2
compatibility.

This patch keeps the default v2 selection in all cases except
in the KVM accelerated mode when either
- the host does not support GICv2 in-kernel emulation or
- number of VCPUS exceeds 8.

Those cases did not work anyway so we do not break any compatibility.
Now we get v3 selected in such a case.

Signed-off-by: Eric Auger 
Reported-by: Dr. David Alan Gilbert 
Reviewed-by: Andrew Jones 
Reviewed-by: Richard Henderson 

---

v2 -> v3:
- add ()
---
 hw/arm/virt.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index aeb6c45e51..2d1dee50f8 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1542,6 +1542,8 @@ static void virt_set_memmap(VirtMachineState *vms)
  */
 static void finalize_gic_version(VirtMachineState *vms)
 {
+unsigned int max_cpus = MACHINE(vms)->smp.max_cpus;
+
 if (kvm_enabled()) {
 int probe_bitmap = kvm_arm_vgic_probe();
 
@@ -1552,7 +1554,17 @@ static void finalize_gic_version(VirtMachineState *vms)
 
 switch (vms->gic_version) {
 case VIRT_GIC_VERSION_NOSEL:
-vms->gic_version = VIRT_GIC_VERSION_2;
+if (((probe_bitmap & KVM_ARM_VGIC_V2) && max_cpus <= GIC_NCPU) ||
+!kvm_irqchip_in_kernel()) {
+vms->gic_version = VIRT_GIC_VERSION_2;
+} else {
+/*
+ * in case the host does not support v2 in-kernel emulation or
+ * the end-user requested more than 8 VCPUs we now default
+ * to v3. In any case defaulting to v2 would be broken.
+ */
+vms->gic_version = VIRT_GIC_VERSION_3;
+}
 break;
 case VIRT_GIC_VERSION_HOST:
 case VIRT_GIC_VERSION_MAX:
-- 
2.20.1




Re: [PATCH] hw/arm/smmu-common: a fix to smmu_find_smmu_pcibus

2020-03-02 Thread Peter Maydell
On Wed, 26 Feb 2020 at 17:37, Philippe Mathieu-Daudé  wrote:
>
> Hi Eric,

> Patch is easy to review but code not. By inverting the if() statement I
> find the code easier to review.



> SMMUPciBus *smmu_find_smmu_pcibus(SMMUState *s, uint8_t bus_num)
> {
>  SMMUPciBus *smmu_pci_bus = s->smmu_pcibus_by_bus_num[bus_num];
>  GHashTableIter iter;
>
>  if (smmu_pci_bus) {
>  return smmu_pci_bus;
>  }
>
>  g_hash_table_iter_init(&iter, s->smmu_pcibus_by_busptr);
>  while (g_hash_table_iter_next(&iter, NULL, (void **)&smmu_pci_bus)) {
>  if (pci_bus_num(smmu_pci_bus->bus) == bus_num) {
>  s->smmu_pcibus_by_bus_num[bus_num] = smmu_pci_bus;
>  return smmu_pci_bus;
>  }
>  }
>
>  return NULL;
> }
>
> What do you think?

I think I agree with Philippe here -- the current code is already
a bit confusing in that it looks at first glance as if the "find
the bus in the hash table" code works by falling through into
the "we already had the cached value" code on success, but in
fact the success case is dealt with by the return in the middle
of the while loop and it's only the not-found case that falls
through. Adding this patch on top fixes the bug but leaves in
place the odd code structure that caused it. Rearranging it as
Philippe does above makes it much clearer what's happening,
I think.

Would one of you like to submit a patch that does it that way
round, please?

thanks
-- PMM



Re: [PATCH v3 02/33] qemu-doc: remove target OS documentation

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> From: Paolo Bonzini 
>
> This section covers OSes up to Windows 2000, and as such it is mostly
> obsolete.  Zap it.
>
> Reviewed-by: Peter Maydell 
> Signed-off-by: Paolo Bonzini 
> Message-id: 20200226113034.6741-3-pbonz...@redhat.com
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

> ---
>  qemu-doc.texi | 96 ---
>  1 file changed, 96 deletions(-)
>
> diff --git a/qemu-doc.texi b/qemu-doc.texi
> index 6636816b85f..e555dea4ef6 100644
> --- a/qemu-doc.texi
> +++ b/qemu-doc.texi
> @@ -148,7 +148,6 @@ accelerator is required to use more than one host CPU for 
> emulation.
>  * vnc_security::   VNC security
>  * network_tls::TLS setup for network services
>  * gdb_usage::  GDB usage
> -* pcsys_os_specific::  Target OS specific information
>  @end menu
>  
>  @node pcsys_introduction
> @@ -1605,101 +1604,6 @@ received: "OK"
>  @end example
>  @end table
>  
> -@node pcsys_os_specific
> -@section Target OS specific information
> -
> -@subsection Linux
> -
> -To have access to SVGA graphic modes under X11, use the @code{vesa} or
> -the @code{cirrus} X11 driver. For optimal performances, use 16 bit
> -color depth in the guest and the host OS.
> -
> -When using a 2.6 guest Linux kernel, you should add the option
> -@code{clock=pit} on the kernel command line because the 2.6 Linux
> -kernels make very strict real time clock checks by default that QEMU
> -cannot simulate exactly.
> -
> -When using a 2.6 guest Linux kernel, verify that the 4G/4G patch is
> -not activated because QEMU is slower with this patch. The QEMU
> -Accelerator Module is also much slower in this case. Earlier Fedora
> -Core 3 Linux kernel (< 2.6.9-1.724_FC3) were known to incorporate this
> -patch by default. Newer kernels don't have it.
> -
> -@subsection Windows
> -
> -If you have a slow host, using Windows 95 is better as it gives the
> -best speed. Windows 2000 is also a good choice.
> -
> -@subsubsection SVGA graphic modes support
> -
> -QEMU emulates a Cirrus Logic GD5446 Video
> -card. All Windows versions starting from Windows 95 should recognize
> -and use this graphic card. For optimal performances, use 16 bit color
> -depth in the guest and the host OS.
> -
> -If you are using Windows XP as guest OS and if you want to use high
> -resolution modes which the Cirrus Logic BIOS does not support (i.e. >=
> -1280x1024x16), then you should use the VESA VBE virtual graphic card
> -(option @option{-std-vga}).
> -
> -@subsubsection CPU usage reduction
> -
> -Windows 9x does not correctly use the CPU HLT
> -instruction. The result is that it takes host CPU cycles even when
> -idle. You can install the utility from
> -@url{https://web.archive.org/web/20060212132151/http://www.user.cityline.ru/~maxamn/amnhltm.zip}
> -to solve this problem. Note that no such tool is needed for NT, 2000 or XP.
> -
> -@subsubsection Windows 2000 disk full problem
> -
> -Windows 2000 has a bug which gives a disk full problem during its
> -installation. When installing it, use the @option{-win2k-hack} QEMU
> -option to enable a specific workaround. After Windows 2000 is
> -installed, you no longer need this option (this option slows down the
> -IDE transfers).
> -
> -@subsubsection Windows 2000 shutdown
> -
> -Windows 2000 cannot automatically shutdown in QEMU although Windows 98
> -can. It comes from the fact that Windows 2000 does not automatically
> -use the APM driver provided by the BIOS.
> -
> -In order to correct that, do the following (thanks to Struan
> -Bartlett): go to the Control Panel => Add/Remove Hardware & Next =>
> -Add/Troubleshoot a device => Add a new device & Next => No, select the
> -hardware from a list & Next => NT Apm/Legacy Support & Next => Next
> -(again) a few times. Now the driver is installed and Windows 2000 now
> -correctly instructs QEMU to shutdown at the appropriate moment.
> -
> -@subsubsection Share a directory between Unix and Windows
> -
> -See @ref{sec_invocation} about the help of the option
> -@option{'-netdev user,smb=...'}.
> -
> -@subsubsection Windows XP security problem
> -
> -Some releases of Windows XP install correctly but give a security
> -error when booting:
> -@example
> -A problem is preventing Windows from accurately checking the
> -license for this computer. Error code: 0x800703e6.
> -@end example
> -
> -The workaround is to install a service pack for XP after a boot in safe
> -mode. Then reboot, and the problem should go away. Since there is no
> -network while in safe mode, its recommended to download the full
> -installation of SP1 or SP2 and transfer that via an ISO or using the
> -vvfat block device ("-hdb fat:directory_which_holds_the_SP").
> -
> -@subsection MS-DOS and FreeDOS
> -
> -@subsubsection CPU usage reduction
> -
> -DOS does not correctly use the CPU HLT instruction. The result is that
> -it takes host CPU cycles even when idle. You can install the utility from
> -@url{https://web.archive.o

Re: [PATCH v3 01/33] qemu-doc: convert user-mode emulation to a separate Sphinx manual

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> From: Paolo Bonzini 
>
> The final addition to the set of QEMU manuals is the user-mode emulation
> manual, which right now is included in qemu-doc.texi.  Extract it and
> convert it to rST, so that qemu-doc.texi covers only full system emulation.
>
> Signed-off-by: Paolo Bonzini 
> Message-id: 20200226113034.6741-2-pbonz...@redhat.com
> [PMM: Fix makefile conflicts; add user manual to
>  index.rst and index.html.in; don't specify empty man_pages
>  list; fixed a few comments to say 'user' rather than 'system']
> Reviewed-by: Peter Maydell 
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

> ---
>  Makefile|   8 +-
>  docs/index.html.in  |   1 +
>  docs/index.rst  |   1 +
>  docs/user/conf.py   |  15 ++
>  docs/user/index.rst |  16 +++
>  docs/user/main.rst  | 295 ++
>  qemu-doc.texi   | 337 
>  7 files changed, 335 insertions(+), 338 deletions(-)
>  create mode 100644 docs/user/conf.py
>  create mode 100644 docs/user/index.rst
>  create mode 100644 docs/user/main.rst
>
> diff --git a/Makefile b/Makefile
> index aa9cc0b5847..faa0ffa05b0 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -787,6 +787,7 @@ distclean: clean
>   $(call clean-manual,specs)
>   $(call clean-manual,system)
>   $(call clean-manual,tools)
> + $(call clean-manual,user)
>   for d in $(TARGET_DIRS); do \
>   rm -rf $$d || exit 1 ; \
>  done
> @@ -845,6 +846,7 @@ install-sphinxdocs: sphinxdocs
>   $(call install-manual,specs)
>   $(call install-manual,system)
>   $(call install-manual,tools)
> + $(call install-manual,user)
>  
>  install-doc: $(DOCS) install-sphinxdocs
>   $(INSTALL_DIR) "$(DESTDIR)$(qemu_docdir)"
> @@ -1039,7 +1041,8 @@ sphinxdocs: $(MANUAL_BUILDDIR)/devel/index.html \
>  $(MANUAL_BUILDDIR)/interop/index.html \
>  $(MANUAL_BUILDDIR)/specs/index.html \
>  $(MANUAL_BUILDDIR)/system/index.html \
> -$(MANUAL_BUILDDIR)/tools/index.html
> +$(MANUAL_BUILDDIR)/tools/index.html \
> +$(MANUAL_BUILDDIR)/user/index.html
>  
>  # Canned command to build a single manual
>  # Arguments: $1 = manual name, $2 = Sphinx builder ('html' or 'man')
> @@ -1074,6 +1077,9 @@ $(MANUAL_BUILDDIR)/system/index.html: $(call 
> manual-deps,system)
>  $(MANUAL_BUILDDIR)/tools/index.html: $(call manual-deps,tools) 
> $(SRC_PATH)/qemu-img-cmds.hx $(SRC_PATH)/docs/qemu-option-trace.rst.inc
>   $(call build-manual,tools,html)
>  
> +$(MANUAL_BUILDDIR)/user/index.html: $(call manual-deps,user)
> + $(call build-manual,user,html)
> +
>  $(call define-manpage-rule,interop,qemu-ga.8)
>  
>  $(call define-manpage-rule,system,qemu-block-drivers.7)
> diff --git a/docs/index.html.in b/docs/index.html.in
> index cf61b1cf448..a576ace8a27 100644
> --- a/docs/index.html.in
> +++ b/docs/index.html.in
> @@ -14,6 +14,7 @@
>  System Emulation Guest Hardware 
> Specifications
>  System Emulation User's 
> Guide
>  Tools Guide
> +User Mode Emulation User's 
> Guide
>  
>  
>  
> diff --git a/docs/index.rst b/docs/index.rst
> index acd604fa8a9..376dab28850 100644
> --- a/docs/index.rst
> +++ b/docs/index.rst
> @@ -15,3 +15,4 @@ Welcome to QEMU's documentation!
> specs/index
> system/index
> tools/index
> +   user/index
> diff --git a/docs/user/conf.py b/docs/user/conf.py
> new file mode 100644
> index 000..4b09aedd454
> --- /dev/null
> +++ b/docs/user/conf.py
> @@ -0,0 +1,15 @@
> +# -*- coding: utf-8 -*-
> +#
> +# QEMU documentation build configuration file for the 'user' manual.
> +#
> +# This includes the top level conf file and then makes any necessary tweaks.
> +import sys
> +import os
> +
> +qemu_docdir = os.path.abspath("..")
> +parent_config = os.path.join(qemu_docdir, "conf.py")
> +exec(compile(open(parent_config, "rb").read(), parent_config, 'exec'))
> +
> +# This slightly misuses the 'description', but is the best way to get
> +# the manual title to appear in the sidebar.
> +html_theme_options['description'] = u'User Mode Emulation User''s Guide'
> diff --git a/docs/user/index.rst b/docs/user/index.rst
> new file mode 100644
> index 000..e030dadf652
> --- /dev/null
> +++ b/docs/user/index.rst
> @@ -0,0 +1,16 @@
> +.. This is the top level page for the 'user' manual.
> +
> +
> +QEMU User Mode Emulation User's Guide
> +=
> +
> +This manual is the overall guide for users using QEMU
> +for user-mode emulation.  In this mode, QEMU can launch
> +processes compiled for one CPU on another CPU.
> +
> +Contents:
> +
> +.. toctree::
> +   :maxdepth: 2
> +
> +   main
> diff --git a/docs/user/main.rst b/docs/user/main.rst
> new file mode 100644
> index 000..ca69f7727d5
> --- /dev/null
> +++ b/docs/user/main.rst
> @@ -0,0 +1,295 @@
> +QEMU User space emulator
> +
>

Re: [PATCH v1 2/2] hw/arm: versal: Generate xlnx-versal-virt zdma FDT nodes

2020-03-02 Thread Luc Michel
On 2/27/20 4:44 PM, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" 
> 
> Generate xlnx-versal-virt zdma FDT nodes.
> 
> Signed-off-by: Edgar E. Iglesias 

Reviewed-by: Luc Michel 

> ---
>  hw/arm/xlnx-versal-virt.c | 28 
>  1 file changed, 28 insertions(+)
> 
> diff --git a/hw/arm/xlnx-versal-virt.c b/hw/arm/xlnx-versal-virt.c
> index e7f4ca8bf9..878a275140 100644
> --- a/hw/arm/xlnx-versal-virt.c
> +++ b/hw/arm/xlnx-versal-virt.c
> @@ -229,6 +229,33 @@ static void fdt_add_gem_nodes(VersalVirt *s)
>  }
>  }
>  
> +static void fdt_add_zdma_nodes(VersalVirt *s)
> +{
> +const char clocknames[] = "clk_main\0clk_apb";
> +const char compat[] = "xlnx,zynqmp-dma-1.0";
> +int i;
> +
> +for (i = XLNX_VERSAL_NR_ADMAS - 1; i >= 0; i--) {
> +uint64_t addr = MM_ADMA_CH0 + MM_ADMA_CH0_SIZE * i;
> +char *name = g_strdup_printf("/dma@%" PRIx64, addr);
> +
> +qemu_fdt_add_subnode(s->fdt, name);
> +
> +qemu_fdt_setprop_cell(s->fdt, name, "xlnx,bus-width", 64);
> +qemu_fdt_setprop_cells(s->fdt, name, "clocks",
> +   s->phandle.clk_25Mhz, s->phandle.clk_25Mhz);
> +qemu_fdt_setprop(s->fdt, name, "clock-names",
> + clocknames, sizeof(clocknames));
> +qemu_fdt_setprop_cells(s->fdt, name, "interrupts",
> +   GIC_FDT_IRQ_TYPE_SPI, VERSAL_ADMA_IRQ_0 + i,
> +   GIC_FDT_IRQ_FLAGS_LEVEL_HI);
> +qemu_fdt_setprop_sized_cells(s->fdt, name, "reg",
> + 2, addr, 2, 0x1000);
> +qemu_fdt_setprop(s->fdt, name, "compatible", compat, sizeof(compat));
> +g_free(name);
> +}
> +}
> +
>  static void fdt_nop_memory_nodes(void *fdt, Error **errp)
>  {
>  Error *err = NULL;
> @@ -427,6 +454,7 @@ static void versal_virt_init(MachineState *machine)
>  fdt_add_uart_nodes(s);
>  fdt_add_gic_nodes(s);
>  fdt_add_timer_nodes(s);
> +fdt_add_zdma_nodes(s);
>  fdt_add_cpu_nodes(s, psci_conduit);
>  fdt_add_clk_node(s, "/clk125", 12500, s->phandle.clk_125Mhz);
>  fdt_add_clk_node(s, "/clk25", 2500, s->phandle.clk_25Mhz);
> 



Re: [PATCH v1 1/2] hw/arm: versal: Add support for the LPD ADMAs

2020-03-02 Thread Luc Michel
On 2/27/20 4:44 PM, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" 
> 
> Add support for the Versal LPD ADMAs.
> 
> Signed-off-by: Edgar E. Iglesias 

Reviewed-by: Luc Michel 

> ---
>  hw/arm/xlnx-versal.c | 24 
>  include/hw/arm/xlnx-versal.h |  6 ++
>  2 files changed, 30 insertions(+)
> 
> diff --git a/hw/arm/xlnx-versal.c b/hw/arm/xlnx-versal.c
> index 1cf3daaf4f..f9beba07ed 100644
> --- a/hw/arm/xlnx-versal.c
> +++ b/hw/arm/xlnx-versal.c
> @@ -193,6 +193,29 @@ static void versal_create_gems(Versal *s, qemu_irq *pic)
>  }
>  }
>  
> +static void versal_create_admas(Versal *s, qemu_irq *pic)
> +{
> +int i;
> +
> +for (i = 0; i < ARRAY_SIZE(s->lpd.iou.adma); i++) {
> +char *name = g_strdup_printf("adma%d", i);
> +DeviceState *dev;
> +MemoryRegion *mr;
> +
> +dev = qdev_create(NULL, "xlnx.zdma");
> +s->lpd.iou.adma[i] = SYS_BUS_DEVICE(dev);
> +object_property_add_child(OBJECT(s), name, OBJECT(dev), 
> &error_fatal);
> +qdev_init_nofail(dev);
> +
> +mr = sysbus_mmio_get_region(s->lpd.iou.adma[i], 0);
> +memory_region_add_subregion(&s->mr_ps,
> +MM_ADMA_CH0 + i * MM_ADMA_CH0_SIZE, mr);
> +
> +sysbus_connect_irq(s->lpd.iou.adma[i], 0, pic[VERSAL_ADMA_IRQ_0 + 
> i]);
> +g_free(name);
> +}
> +}
> +
>  /* This takes the board allocated linear DDR memory and creates aliases
>   * for each split DDR range/aperture on the Versal address map.
>   */
> @@ -274,6 +297,7 @@ static void versal_realize(DeviceState *dev, Error **errp)
>  versal_create_apu_gic(s, pic);
>  versal_create_uarts(s, pic);
>  versal_create_gems(s, pic);
> +versal_create_admas(s, pic);
>  versal_map_ddr(s);
>  versal_unimp(s);
>  
> diff --git a/include/hw/arm/xlnx-versal.h b/include/hw/arm/xlnx-versal.h
> index d844c4ffe4..6c0a692b2f 100644
> --- a/include/hw/arm/xlnx-versal.h
> +++ b/include/hw/arm/xlnx-versal.h
> @@ -22,6 +22,7 @@
>  #define XLNX_VERSAL_NR_ACPUS   2
>  #define XLNX_VERSAL_NR_UARTS   2
>  #define XLNX_VERSAL_NR_GEMS2
> +#define XLNX_VERSAL_NR_ADMAS   8
>  #define XLNX_VERSAL_NR_IRQS192
>  
>  typedef struct Versal {
> @@ -50,6 +51,7 @@ typedef struct Versal {
>  struct {
>  SysBusDevice *uart[XLNX_VERSAL_NR_UARTS];
>  SysBusDevice *gem[XLNX_VERSAL_NR_GEMS];
> +SysBusDevice *adma[XLNX_VERSAL_NR_ADMAS];
>  } iou;
>  } lpd;
>  
> @@ -74,6 +76,7 @@ typedef struct Versal {
>  #define VERSAL_GEM0_WAKE_IRQ_0 57
>  #define VERSAL_GEM1_IRQ_0  58
>  #define VERSAL_GEM1_WAKE_IRQ_0 59
> +#define VERSAL_ADMA_IRQ_0  60
>  
>  /* Architecturally reserved IRQs suitable for virtualization.  */
>  #define VERSAL_RSVD_IRQ_FIRST 111
> @@ -96,6 +99,9 @@ typedef struct Versal {
>  #define MM_GEM1 0xff0dU
>  #define MM_GEM1_SIZE0x1
>  
> +#define MM_ADMA_CH0 0xffa8U
> +#define MM_ADMA_CH0_SIZE0x1
> +
>  #define MM_OCM  0xfffcU
>  #define MM_OCM_SIZE 0x4
>  
> 



Re: [PATCH v3 03/33] texi2pod: parse @include directives outside "@c man" blocks

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> From: Paolo Bonzini 
>
> This enables splitting the huge qemu-doc.texi file and keeping parallel
> Texinfo and rST versions of the documentation.  texi2pod is not going to
> live much longer and hardly anyone cares about its upstream status,
> so the temporary fork should be acceptable.
>
> Signed-off-by: Paolo Bonzini 
> Message-id: 20200226113034.6741-4-pbonz...@redhat.com
> Reviewed-by: Peter Maydell 
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

> ---
>  scripts/texi2pod.pl | 36 ++--
>  1 file changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/scripts/texi2pod.pl b/scripts/texi2pod.pl
> index 839b7917cf7..8bfc6f6f4c4 100755
> --- a/scripts/texi2pod.pl
> +++ b/scripts/texi2pod.pl
> @@ -143,6 +143,24 @@ while(<$inf>) {
>   next;
>  };
>  
> +# Single line command handlers.
> +
> +/^\@include\s+(.+)$/ and do {
> + push @instack, $inf;
> + $inf = gensym();
> + $file = postprocess($1);
> +
> + # Try cwd and $ibase, then explicit -I paths.
> + $done = 0;
> + foreach $path ("", $ibase, @ipath) {
> + $mypath = $file;
> + $mypath = $path . "/" . $mypath if ($path ne "");
> + open($inf, "<" . $mypath) and ($done = 1, last);
> + }
> + die "cannot find $file" if !$done;
> + next;
> +};
> +
>  next unless $output;
>  
>  # Discard comments.  (Can't do it above, because then we'd never see
> @@ -242,24 +260,6 @@ while(<$inf>) {
>   s/>/>/g;
>  }
>  
> -# Single line command handlers.
> -
> -/^\@include\s+(.+)$/ and do {
> - push @instack, $inf;
> - $inf = gensym();
> - $file = postprocess($1);
> -
> - # Try cwd and $ibase, then explicit -I paths.
> - $done = 0;
> - foreach $path ("", $ibase, @ipath) {
> - $mypath = $file;
> - $mypath = $path . "/" . $mypath if ($path ne "");
> - open($inf, "<" . $mypath) and ($done = 1, last);
> - }
> - die "cannot find $file" if !$done;
> - next;
> -};
> -
>  /^\@(?:section|unnumbered|unnumberedsec|center)\s+(.+)$/
>   and $_ = "\n=head2 $1\n";
>  /^\@subsection\s+(.+)$/


-- 
Alex Bennée



Re: [PATCH v3 04/33] qemu-doc: split CPU models doc between MIPS and x86 parts

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> From: Paolo Bonzini 
>
> The MIPS CPU models end up in the middle of the PC documentation.  Move
> them to a separate file so that they can be placed in the right section.
>
> The man page still includes both x86 and MIPS content.

We really need to flesh that out one day - it's not like ARM hasn't got
it's own tweaks.

>
> Signed-off-by: Paolo Bonzini 
> Message-id: 20200226113034.6741-5-pbonz...@redhat.com
> Reviewed-by: Peter Maydell 
> Signed-off-by: Peter Maydell 
> ---
>  Makefile  |  11 +-
>  MAINTAINERS   |   3 +-
>  docs/system/cpu-models-mips.texi  | 157 +
>  .../cpu-models-x86.texi}  | 221 ++
>  docs/system/qemu-cpu-models.texi  |  28 +++

I wonder if there is something that should go to docs/core? AFAICT the
CPU modelling covers two things:

  - system KVM modelling which deals with feature bits and presenting a
common base for the purposes of migration

  - TCG modelling which covers what CPUs we can emulate which affects
both linux-user and system emulation

Anyway we can "fix it in post" as they say in the movies ;-)

Reviewed-by: Alex Bennée 

>  qemu-doc.texi |  12 +-
>  6 files changed, 213 insertions(+), 219 deletions(-)
>  create mode 100644 docs/system/cpu-models-mips.texi
>  rename docs/{qemu-cpu-models.texi => system/cpu-models-x86.texi} (71%)
>  create mode 100644 docs/system/qemu-cpu-models.texi
>
> diff --git a/Makefile b/Makefile
> index faa0ffa05b0..f75a7b51938 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -354,7 +354,7 @@ endif
>  DOCS+=$(MANUAL_BUILDDIR)/system/qemu-block-drivers.7
>  DOCS+=docs/interop/qemu-qmp-ref.html docs/interop/qemu-qmp-ref.txt 
> docs/interop/qemu-qmp-ref.7
>  DOCS+=docs/interop/qemu-ga-ref.html docs/interop/qemu-ga-ref.txt 
> docs/interop/qemu-ga-ref.7
> -DOCS+=docs/qemu-cpu-models.7
> +DOCS+=docs/system/qemu-cpu-models.7
>  DOCS+=$(MANUAL_BUILDDIR)/index.html
>  ifdef CONFIG_VIRTFS
>  DOCS+=$(MANUAL_BUILDDIR)/tools/virtfs-proxy-helper.1
> @@ -780,7 +780,7 @@ distclean: clean
>   rm -f docs/interop/qemu-qmp-ref.txt docs/interop/qemu-ga-ref.txt
>   rm -f docs/interop/qemu-qmp-ref.pdf docs/interop/qemu-ga-ref.pdf
>   rm -f docs/interop/qemu-qmp-ref.html docs/interop/qemu-ga-ref.html
> - rm -f docs/qemu-cpu-models.7
> + rm -f docs/system/qemu-cpu-models.7
>   rm -rf .doctrees
>   $(call clean-manual,devel)
>   $(call clean-manual,interop)
> @@ -861,7 +861,7 @@ ifdef CONFIG_POSIX
>   $(INSTALL_DIR) "$(DESTDIR)$(mandir)/man7"
>   $(INSTALL_DATA) docs/interop/qemu-qmp-ref.7 "$(DESTDIR)$(mandir)/man7"
>   $(INSTALL_DATA) $(MANUAL_BUILDDIR)/system/qemu-block-drivers.7 
> "$(DESTDIR)$(mandir)/man7"
> - $(INSTALL_DATA) docs/qemu-cpu-models.7 "$(DESTDIR)$(mandir)/man7"
> + $(INSTALL_DATA) docs/system/qemu-cpu-models.7 "$(DESTDIR)$(mandir)/man7"
>  ifeq ($(CONFIG_TOOLS),y)
>   $(INSTALL_DATA) $(MANUAL_BUILDDIR)/tools/qemu-img.1 
> "$(DESTDIR)$(mandir)/man1"
>   $(INSTALL_DIR) "$(DESTDIR)$(mandir)/man8"
> @@ -,7 +,7 @@ docs/interop/qemu-ga-qapi.texi: 
> qga/qapi-generated/qga-qapi-doc.texi
>  
>  qemu.1: qemu-doc.texi qemu-options.texi qemu-monitor.texi 
> qemu-monitor-info.texi
>  qemu.1: qemu-option-trace.texi
> -docs/qemu-cpu-models.7: docs/qemu-cpu-models.texi
> +docs/system/qemu-cpu-models.7: docs/system/qemu-cpu-models.texi 
> docs/system/cpu-models-x86.texi docs/system/cpu-models-mips.texi
>  
>  html: qemu-doc.html docs/interop/qemu-qmp-ref.html 
> docs/interop/qemu-ga-ref.html sphinxdocs
>  info: qemu-doc.info docs/interop/qemu-qmp-ref.info 
> docs/interop/qemu-ga-ref.info
> @@ -1123,7 +1123,8 @@ qemu-doc.html qemu-doc.info qemu-doc.pdf qemu-doc.txt: \
>   qemu-tech.texi qemu-option-trace.texi \
>   qemu-deprecated.texi qemu-monitor.texi \
>   qemu-monitor-info.texi \
> - docs/qemu-cpu-models.texi docs/security.texi
> + docs/system/cpu-models-x86.texi docs/system/cpu-models-mips.texi \
> + docs/security.texi
>  
>  docs/interop/qemu-ga-ref.dvi docs/interop/qemu-ga-ref.html \
>  docs/interop/qemu-ga-ref.info docs/interop/qemu-ga-ref.pdf \
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b66c46dcb9f..8c6d8f533ce 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -215,6 +215,7 @@ S: Maintained
>  F: target/mips/
>  F: default-configs/*mips*
>  F: disas/*mips*
> +F: docs/system/cpu-models-mips.texi
>  F: hw/intc/mips_gic.c
>  F: hw/mips/
>  F: hw/misc/mips_*
> @@ -319,7 +320,7 @@ F: tests/tcg/i386/
>  F: tests/tcg/x86_64/
>  F: hw/i386/
>  F: disas/i386.c
> -F: docs/qemu-cpu-models.texi
> +F: docs/system/cpu-models-x86.texi
>  T: git https://github.com/ehabkost/qemu.git x86-next
>  
>  Xtensa TCG CPUs
> diff --git a/docs/system/cpu-models-mips.texi 
> b/docs/system/cpu-models-mips.texi
> new file mode 100644
> index 000..6a0370cb693
> --- /dev/null
> ++

Re: [PATCH v2 1/2] tests/vhost-user-bridge: move to contrib/

2020-03-02 Thread Laurent Vivier
On 02/03/2020 11:53, Michael S. Tsirkin wrote:
> On Mon, Mar 02, 2020 at 10:50:16AM +0100, Laurent Vivier wrote:
>> On 01/03/2020 13:12, Michael S. Tsirkin wrote:
>>> On Fri, Feb 07, 2020 at 10:54:11AM +0100, Laurent Vivier wrote:
 vhost-user-bridge is not a test. Move it to contrib/ and
 add it to the tools list.

 It will be built only if tools (--enable-tools) and
 vhost-user (--enable-vhost-user) are enabled (both are set
 by default).

 Suggested-by: Dr. David Alan Gilbert 
 Signed-off-by: Laurent Vivier 
 Reviewed-by: Philippe Mathieu-Daudé 
>>>
>>>
>>> I had to drop this series from my tree since it cause failures
>>> on OSX. Pls use something like travis CI to test when you repost
>>> a fixed version. Thanks!
>>>
>>
>> Do you have a link to the error logs?
>>
>> Thanks,
>> Laurent
> 
> 
> Peter sent me this:
> 
> 
> Hi; this fails to build on OSX:
> 
>   CC  contrib/libvhost-user/libvhost-user.o
> /Users/pm215/src/qemu-for-merges/contrib/libvhost-user/libvhost-user.c:27:10:
> fatal error: 'sys/eventfd.h' file not found
> #include 
>  ^~~
> In file included from
> /Users/pm215/src/qemu-for-merges/contrib/vhost-user-bridge/main.c:37:
> /Users/pm215/src/qemu-for-merges/contrib/libvhost-user/libvhost-user.h:21:10:
> fatal error: 'linux/vhost.h' file not found
> #include 
>  ^~~
> 1 error generated.
> 
> thanks
> -- PMM
> 
> But pls do test on OSX before reposting.
> 

Thank you.

I will fix and test the new patch with Travis CI.

Laurent




Re: [PATCH v3 2/6] hw/arm/virt: Introduce VirtGICType enum type

2020-03-02 Thread Philippe Mathieu-Daudé

On 3/2/20 11:55 AM, Eric Auger wrote:

We plan to introduce yet another value for the gic version (nosel).
As we already use exotic values such as 0 and -1, let's introduce
a dedicated enum type and let vms->gic_version take this
type.

Signed-off-by: Eric Auger 

---

v2 -> v3:
- replaced defines by enum VirtGICType
- use that new type for vms->gic_version
---
  hw/arm/virt.c | 30 +++---
  include/hw/arm/virt.h | 11 +--


Please have a look at scripts/git.orderfile, it helps making review 
easier/quicker.


Reviewed-by: Philippe Mathieu-Daudé 


  2 files changed, 24 insertions(+), 17 deletions(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index c093f0ab85..b449a445de 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -298,7 +298,7 @@ static void fdt_add_timer_nodes(const VirtMachineState *vms)
  irqflags = GIC_FDT_IRQ_FLAGS_EDGE_LO_HI;
  }
  
-if (vms->gic_version == 2) {

+if (vms->gic_version == VIRT_GIC_VERSION_2) {
  irqflags = deposit32(irqflags, GIC_FDT_IRQ_PPI_CPU_START,
   GIC_FDT_IRQ_PPI_CPU_WIDTH,
   (1 << vms->smp_cpus) - 1);
@@ -439,7 +439,7 @@ static void fdt_add_gic_node(VirtMachineState *vms)
  qemu_fdt_setprop_cell(vms->fdt, nodename, "#address-cells", 0x2);
  qemu_fdt_setprop_cell(vms->fdt, nodename, "#size-cells", 0x2);
  qemu_fdt_setprop(vms->fdt, nodename, "ranges", NULL, 0);
-if (vms->gic_version == 3) {
+if (vms->gic_version == VIRT_GIC_VERSION_3) {
  int nb_redist_regions = virt_gicv3_redist_region_count(vms);
  
  qemu_fdt_setprop_string(vms->fdt, nodename, "compatible",

@@ -518,7 +518,7 @@ static void fdt_add_pmu_nodes(const VirtMachineState *vms)
  }
  }
  
-if (vms->gic_version == 2) {

+if (vms->gic_version == VIRT_GIC_VERSION_2) {
  irqflags = deposit32(irqflags, GIC_FDT_IRQ_PPI_CPU_START,
   GIC_FDT_IRQ_PPI_CPU_WIDTH,
   (1 << vms->smp_cpus) - 1);
@@ -1469,7 +1469,7 @@ static uint64_t virt_cpu_mp_affinity(VirtMachineState 
*vms, int idx)
   * purposes are to make TCG consistent (with 64-bit KVM hosts)
   * and to improve SGI efficiency.
   */
-if (vms->gic_version == 3) {
+if (vms->gic_version == VIRT_GIC_VERSION_3) {
  clustersz = GICV3_TARGETLIST_BITS;
  } else {
  clustersz = GIC_TARGETLIST_BITS;
@@ -1560,15 +1560,15 @@ static void machvirt_init(MachineState *machine)
  /* We can probe only here because during property set
   * KVM is not available yet
   */
-if (vms->gic_version <= 0) {
-/* "host" or "max" */
+if (vms->gic_version == VIRT_GIC_VERSION_HOST ||
+vms->gic_version == VIRT_GIC_VERSION_MAX) {
  if (!kvm_enabled()) {
-if (vms->gic_version == 0) {
+if (vms->gic_version == VIRT_GIC_VERSION_HOST) {
  error_report("gic-version=host requires KVM");
  exit(1);
  } else {
  /* "max": currently means 3 for TCG */
-vms->gic_version = 3;
+vms->gic_version = VIRT_GIC_VERSION_3;
  }
  } else {
  vms->gic_version = kvm_arm_vgic_probe();
@@ -1627,7 +1627,7 @@ static void machvirt_init(MachineState *machine)
  /* The maximum number of CPUs depends on the GIC version, or on how
   * many redistributors we can fit into the memory map.
   */
-if (vms->gic_version == 3) {
+if (vms->gic_version == VIRT_GIC_VERSION_3) {
  virt_max_cpus =
  vms->memmap[VIRT_GIC_REDIST].size / GICV3_REDIST_SIZE;
  virt_max_cpus +=
@@ -1855,7 +1855,7 @@ static void virt_set_its(Object *obj, bool value, Error 
**errp)
  static char *virt_get_gic_version(Object *obj, Error **errp)
  {
  VirtMachineState *vms = VIRT_MACHINE(obj);
-const char *val = vms->gic_version == 3 ? "3" : "2";
+const char *val = vms->gic_version == VIRT_GIC_VERSION_3 ? "3" : "2";
  
  return g_strdup(val);

  }
@@ -1865,13 +1865,13 @@ static void virt_set_gic_version(Object *obj, const 
char *value, Error **errp)
  VirtMachineState *vms = VIRT_MACHINE(obj);
  
  if (!strcmp(value, "3")) {

-vms->gic_version = 3;
+vms->gic_version = VIRT_GIC_VERSION_3;
  } else if (!strcmp(value, "2")) {
-vms->gic_version = 2;
+vms->gic_version = VIRT_GIC_VERSION_2;
  } else if (!strcmp(value, "host")) {
-vms->gic_version = 0; /* Will probe later */
+vms->gic_version = VIRT_GIC_VERSION_HOST; /* Will probe later */
  } else if (!strcmp(value, "max")) {
-vms->gic_version = -1; /* Will probe later */
+vms->gic_version = VIRT_GIC_VERSION_MAX; /* Will probe later */
  } else {
  error_setg(errp, "Invalid gic-version value");
  error_append_hint(errp, "Valid values are 3, 2, host, max.\n");

Re: [PATCH v3 05/33] qemu-doc: split qemu-doc.texi in multiple files

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> From: Paolo Bonzini 
>
> In order to facilitate the reorganization of qemu-doc.texi content,
> as well as the conversion to rST/Sphinx, split it in multiple .texi
> files that are included from docs/system.
>
> The "other devices" section is renamed to ivshmem and placed last.
>
> Signed-off-by: Paolo Bonzini 
> Message-id: 20200226113034.6741-6-pbonz...@redhat.com
> Reviewed-by: Peter Maydell 
> Signed-off-by: Peter Maydell 
> ---
>  Makefile |   16 +
>  docs/system/build-platforms.texi |   67 ++
>  docs/system/gdb.texi |   71 ++

The gdb test would be better served in docs/core if we could have
optional sections on invocation rendering depending on if it's built
with system emulation or linux-user docs. Is that something that's
already supported?

Anyway not holding this up:

Reviewed-by: Alex Bennée 


>  docs/system/images.texi  |   88 ++
>  docs/system/invocation.texi  |  240 +
>  docs/system/ivshmem.texi |   60 ++
>  docs/system/keys.texi|   53 ++
>  docs/system/license.texi |9 +
>  docs/system/linuxboot.texi   |   27 +
>  docs/system/monitor.texi |   35 +
>  docs/system/mux-chardev.texi |   51 ++
>  docs/system/net.texi |   96 ++
>  docs/system/quickstart.texi  |   13 +
>  docs/system/tls.texi |  329 +++
>  docs/system/usb.texi |  115 +++
>  docs/system/vnc-security.texi|  196 
>  qemu-doc.texi| 1471 +-
>  17 files changed, 1483 insertions(+), 1454 deletions(-)
>  create mode 100644 docs/system/build-platforms.texi
>  create mode 100644 docs/system/gdb.texi
>  create mode 100644 docs/system/images.texi
>  create mode 100644 docs/system/invocation.texi
>  create mode 100644 docs/system/ivshmem.texi
>  create mode 100644 docs/system/keys.texi
>  create mode 100644 docs/system/license.texi
>  create mode 100644 docs/system/linuxboot.texi
>  create mode 100644 docs/system/monitor.texi
>  create mode 100644 docs/system/mux-chardev.texi
>  create mode 100644 docs/system/net.texi
>  create mode 100644 docs/system/quickstart.texi
>  create mode 100644 docs/system/tls.texi
>  create mode 100644 docs/system/usb.texi
>  create mode 100644 docs/system/vnc-security.texi
>
> diff --git a/Makefile b/Makefile
> index f75a7b51938..9790a0fd15b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1123,6 +1123,22 @@ qemu-doc.html qemu-doc.info qemu-doc.pdf qemu-doc.txt: 
> \
>   qemu-tech.texi qemu-option-trace.texi \
>   qemu-deprecated.texi qemu-monitor.texi \
>   qemu-monitor-info.texi \
> +docs/system/quickstart.texi \
> +docs/system/invocation.texi \
> +docs/system/keys.texi \
> +docs/system/mux-chardev.texi \
> +docs/system/monitor.texi \
> +docs/system/cpu-models-x86.texi \
> +docs/system/images.texi \
> +docs/system/net.texi \
> +docs/system/usb.texi \
> +docs/system/ivshmem.texi \
> +docs/system/linuxboot.texi \
> +docs/system/vnc-security.texi \
> +docs/system/tls.texi \
> +docs/system/gdb.texi \
> +docs/system/build-platforms.texi \
> +docs/system/license.texi \
>   docs/system/cpu-models-x86.texi docs/system/cpu-models-mips.texi \
>   docs/security.texi
>  
> diff --git a/docs/system/build-platforms.texi 
> b/docs/system/build-platforms.texi
> new file mode 100644
> index 000..531ef5bed44
> --- /dev/null
> +++ b/docs/system/build-platforms.texi
> @@ -0,0 +1,67 @@
> +@node Supported build platforms
> +@appendix Supported build platforms
> +
> +QEMU aims to support building and executing on multiple host OS platforms.
> +This appendix outlines which platforms are the major build targets. These
> +platforms are used as the basis for deciding upon the minimum required
> +versions of 3rd party software QEMU depends on. The supported platforms
> +are the targets for automated testing performed by the project when patches
> +are submitted for review, and tested before and after merge.
> +
> +If a platform is not listed here, it does not imply that QEMU won't work.
> +If an unlisted platform has comparable software versions to a listed 
> platform,
> +there is every expectation that it will work. Bug reports are welcome for
> +problems encountered on unlisted platforms unless they are clearly older
> +vintage than what is described here.
> +
> +Note that when considering software versions shipped in distros as support
> +targets, QEMU considers only the version number, and assumes the features in
> +that distro match the upstream release with the same version. In other words,
> +if a distro backports extra features to the software in their distro, QEMU
> +upstream code will not add explicit support for those backports, unless the
> +feature is auto-detectable in a manner that works for the upstream releases
> +too.
> +
> +The Repology site @url

Re: [PATCH v1 1/2] hw/arm: versal: Add support for the LPD ADMAs

2020-03-02 Thread Peter Maydell
On Thu, 27 Feb 2020 at 03:17, Edgar E. Iglesias
 wrote:
>
> From: "Edgar E. Iglesias" 
>
> Add support for the Versal LPD ADMAs.
>
> Signed-off-by: Edgar E. Iglesias 
> ---
>  hw/arm/xlnx-versal.c | 24 
>  include/hw/arm/xlnx-versal.h |  6 ++
>  2 files changed, 30 insertions(+)
>
> diff --git a/hw/arm/xlnx-versal.c b/hw/arm/xlnx-versal.c
> index 1cf3daaf4f..f9beba07ed 100644
> --- a/hw/arm/xlnx-versal.c
> +++ b/hw/arm/xlnx-versal.c
> @@ -193,6 +193,29 @@ static void versal_create_gems(Versal *s, qemu_irq *pic)
>  }
>  }
>
> +static void versal_create_admas(Versal *s, qemu_irq *pic)
> +{
> +int i;
> +
> +for (i = 0; i < ARRAY_SIZE(s->lpd.iou.adma); i++) {
> +char *name = g_strdup_printf("adma%d", i);
> +DeviceState *dev;
> +MemoryRegion *mr;
> +
> +dev = qdev_create(NULL, "xlnx.zdma");
> +s->lpd.iou.adma[i] = SYS_BUS_DEVICE(dev);
> +object_property_add_child(OBJECT(s), name, OBJECT(dev), 
> &error_fatal);
> +qdev_init_nofail(dev);
> +
> +mr = sysbus_mmio_get_region(s->lpd.iou.adma[i], 0);
> +memory_region_add_subregion(&s->mr_ps,
> +MM_ADMA_CH0 + i * MM_ADMA_CH0_SIZE, mr);
> +
> +sysbus_connect_irq(s->lpd.iou.adma[i], 0, pic[VERSAL_ADMA_IRQ_0 + 
> i]);
> +g_free(name);
> +}
> +}

It would be more in the modern style to write it with the child device
struct embedded in the parent struct, object_initialize_child() in the
parent init, and object_property_set_bool(..., true, "realized", ...)
in the parent realized, but I guess this fits with the way the
rest of the existing device is written.

Series applied to target-arm.next, thanks.

thanks
-- PMM



Re: [PATCH v2 1/4] qcow2: introduce compression type feature

2020-03-02 Thread Vladimir Sementsov-Ogievskiy

02.03.2020 11:21, Denis Plotnikov wrote:

The patch adds some preparation parts for incompatible compression type
feature to qcow2 allowing the use different compression methods for
image clusters (de)compressing.

It is implied that the compression type is set on the image creation and
can be changed only later by image conversion, thus compression type
defines the only compression algorithm used for the image, and thus,
for all image clusters.

The goal of the feature is to add support of other compression methods
to qcow2. For example, ZSTD which is more effective on compression than ZLIB.

The default compression is ZLIB. Images created with ZLIB compression type
are backward compatible with older qemu versions.

Adding of the compression type breaks a number of tests because now the
compression type is reported on image creation and there are some changes
in the qcow2 header in size and offsets.

The tests are fixed in the following ways:
 * filter out compression_type for all the tests
 * fix header size, feature table size and backing file offset
   affected tests: 031, 036, 061, 080
   header_size +=8: 1 byte compression type
7 bytes padding
   feature_table += 48: incompatible feture compression type
   backing_file_offset += 56 (8 + 48 -> header_change + fature_table_change)
 * add "compression type" for test output matching when it isn't filtered
   affected tests: 049, 060, 061, 065, 144, 182, 242, 255

Signed-off-by: Denis Plotnikov 


I'm almost OK with this patch. Some notes below and:

Seems, new option should be handled in qcow2_amend_options among other 
unsupported ones (otherwise qcow2_amend_options aborts).


---
  qapi/block-core.json |  22 ++-
  block/qcow2.h|  18 -
  include/block/block_int.h|   1 +
  block/qcow2.c| 109 +++
  tests/qemu-iotests/031.out   |  14 ++--
  tests/qemu-iotests/036.out   |   4 +-
  tests/qemu-iotests/049.out   | 102 ++---
  tests/qemu-iotests/060.out   |   1 +
  tests/qemu-iotests/061.out   |  34 ++
  tests/qemu-iotests/065   |  20 +++---
  tests/qemu-iotests/080   |   2 +-
  tests/qemu-iotests/144.out   |   4 +-
  tests/qemu-iotests/182.out   |   2 +-
  tests/qemu-iotests/242.out   |   5 ++
  tests/qemu-iotests/255.out   |   8 +--
  tests/qemu-iotests/common.filter |   3 +-
  16 files changed, 255 insertions(+), 94 deletions(-)



[..]


--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -146,6 +146,12 @@ typedef struct QCowHeader {
  
  uint32_t refcount_order;

  uint32_t header_length;
+
+/* Additional fields */
+uint8_t  compression_type;
+
+/* header must be a multiple of 8 */
+uint8_t  padding[7];
  } QEMU_PACKED QCowHeader;
  
  typedef struct QEMU_PACKED QCowSnapshotHeader {

@@ -216,13 +222,16 @@ enum {
  QCOW2_INCOMPAT_DIRTY_BITNR  = 0,
  QCOW2_INCOMPAT_CORRUPT_BITNR= 1,
  QCOW2_INCOMPAT_DATA_FILE_BITNR  = 2,
+QCOW2_INCOMPAT_COMPRESSION_BITNR= 3,


checkpatch complains. I think, you can just use one space before '=' and don't
care about alignment.


  QCOW2_INCOMPAT_DIRTY= 1 << QCOW2_INCOMPAT_DIRTY_BITNR,
  QCOW2_INCOMPAT_CORRUPT  = 1 << QCOW2_INCOMPAT_CORRUPT_BITNR,
  QCOW2_INCOMPAT_DATA_FILE= 1 << QCOW2_INCOMPAT_DATA_FILE_BITNR,
+QCOW2_INCOMPAT_COMPRESSION  = 1 << QCOW2_INCOMPAT_COMPRESSION_BITNR,
  
  QCOW2_INCOMPAT_MASK = QCOW2_INCOMPAT_DIRTY

  | QCOW2_INCOMPAT_CORRUPT
-| QCOW2_INCOMPAT_DATA_FILE,
+| QCOW2_INCOMPAT_DATA_FILE
+| QCOW2_INCOMPAT_COMPRESSION,
  };
  
  /* Compatible feature bits */

@@ -369,6 +378,13 @@ typedef struct BDRVQcow2State {
  
  bool metadata_preallocation_checked;

  bool metadata_preallocation;
+/*
+ * Compression type used for the image. Default: 0 - ZLIB
+ * The image compression type is set on image creation.
+ * The only way to change the compression type is to convert the image
+ * with the desired compression type set
+ */
+Qcow2CompressionType compression_type;
  } BDRVQcow2State;
  
  typedef struct Qcow2COWRegion {

diff --git a/include/block/block_int.h b/include/block/block_int.h
index 6f9fd5e20e..2c6bb9dc99 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -57,6 +57,7 @@
  #define BLOCK_OPT_REFCOUNT_BITS "refcount_bits"
  #define BLOCK_OPT_DATA_FILE "data_file"
  #define BLOCK_OPT_DATA_FILE_RAW "data_file_raw"
+#define BLOCK_OPT_COMPRESSION_TYPE  "compression_type"
  
  #define BLOCK_PROBE_BUF_SIZE512
  
diff --git a/block/qcow2.c b/block/qcow2.c

index 3c754f616b..fc5232a5d6 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1242,6 +1242,50 @@ st

Re: [PATCH v3 06/33] qemu-doc: extract common system emulator documentation from the PC section

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> From: Paolo Bonzini 
>
> Move the section on PC peripherals together with other targets.
> While some x86-specific information remains in the main system
> emulation chapter, it can be tackled more easily a section at a
> time.
>
> Signed-off-by: Paolo Bonzini 
> Message-id: 20200226113034.6741-7-pbonz...@redhat.com
> Reviewed-by: Peter Maydell 
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

> ---
>  docs/system/quickstart.texi |   2 +-
>  qemu-doc.texi   | 102 
>  2 files changed, 57 insertions(+), 47 deletions(-)
>
> diff --git a/docs/system/quickstart.texi b/docs/system/quickstart.texi
> index 8cd5b4bc6e5..ed7295de7a2 100644
> --- a/docs/system/quickstart.texi
> +++ b/docs/system/quickstart.texi
> @@ -2,7 +2,7 @@
>  @section Quick Start
>  @cindex quick start
>  
> -Download and uncompress a hard disk image with Linux installed (e.g.
> +Download and uncompress a PC hard disk image with Linux installed (e.g.
>  @file{linux.img}) and type:
>  
>  @example
> diff --git a/qemu-doc.texi b/qemu-doc.texi
> index 33d24caf946..88e84300e91 100644
> --- a/qemu-doc.texi
> +++ b/qemu-doc.texi
> @@ -36,8 +36,8 @@
>  
>  @menu
>  * Introduction::
> -* QEMU PC System emulator::
> -* QEMU System emulator for non PC targets::
> +* QEMU System emulator::
> +* QEMU System emulator targets::
>  * System requirements::
>  * Security::
>  * Implementation notes::
> @@ -127,19 +127,16 @@ accelerator is required to use more than one host CPU 
> for emulation.
>  
>  @end itemize
>  
> -
> -@node QEMU PC System emulator
> -@chapter QEMU PC System emulator
> -@cindex system emulation (PC)
> +@node QEMU System emulator
> +@chapter QEMU System emulator
> +@cindex system emulation
>  
>  @menu
> -* pcsys_introduction:: Introduction
> -* pcsys_quickstart::   Quick Start
> +* pcsys_quickstart::   Quick start
>  * sec_invocation:: Invocation
>  * pcsys_keys:: Keys in the graphical frontends
>  * mux_keys::   Keys in the character backend multiplexer
>  * pcsys_monitor::  QEMU Monitor
> -* cpu_models_x86:: Supported CPU model configurations on x86 hosts
>  * disk_images::Disk Images
>  * pcsys_network::  Network emulation
>  * pcsys_usb::  USB emulation
> @@ -150,13 +147,57 @@ accelerator is required to use more than one host CPU 
> for emulation.
>  * gdb_usage::  GDB usage
>  @end menu
>  
> -@node pcsys_introduction
> -@section Introduction
> +@include docs/system/quickstart.texi
> +@include docs/system/invocation.texi
> +@include docs/system/keys.texi
> +@include docs/system/mux-chardev.texi
> +@include docs/system/monitor.texi
> +@include docs/system/images.texi
> +@include docs/system/net.texi
> +@include docs/system/usb.texi
> +@include docs/system/ivshmem.texi
> +@include docs/system/linuxboot.texi
> +@include docs/system/vnc-security.texi
> +@include docs/system/tls.texi
> +@include docs/system/gdb.texi
> +
> +@node QEMU System emulator targets
> +@chapter QEMU System emulator targets
> +@cindex system emulation (PC)
> +
> +QEMU is a generic emulator and it emulates many machines. Most of the
> +options are similar for all machines. Specific information about the
> +various targets are mentioned in the following sections.
> +
> +@menu
> +* x86 (PC) System emulator::
> +* PowerPC System emulator::
> +* Sparc32 System emulator::
> +* Sparc64 System emulator::
> +* MIPS System emulator::
> +* ARM System emulator::
> +* ColdFire System emulator::
> +* Cris System emulator::
> +* Microblaze System emulator::
> +* SH4 System emulator::
> +* Xtensa System emulator::
> +@end menu
> +
> +@node x86 (PC) System emulator
> +@section x86 (PC) System emulator
> +@cindex system emulation (PC)
> +
> +@menu
> +* pcsys_devices::  Peripherals
> +* cpu_models_x86:: Supported CPU model configurations on x86 hosts
> +@end menu
> +
> +@node pcsys_devices
> +@subsection Peripherals
>  
>  @c man begin DESCRIPTION
>  
> -The QEMU PC System emulator simulates the
> -following peripherals:
> +The QEMU PC System emulator simulates the following peripherals:
>  
>  @itemize @minus
>  @item
> @@ -222,40 +263,9 @@ CS4231A is the chip used in Windows Sound System and 
> GUSMAX products
>  
>  @c man end
>  
> -@include docs/system/quickstart.texi
> -@include docs/system/invocation.texi
> -@include docs/system/keys.texi
> -@include docs/system/mux-chardev.texi
> -@include docs/system/monitor.texi
> +@lowersections
>  @include docs/system/cpu-models-x86.texi
> -@include docs/system/images.texi
> -@include docs/system/net.texi
> -@include docs/system/usb.texi
> -@include docs/system/ivshmem.texi
> -@include docs/system/linuxboot.texi
> -@include docs/system/vnc-security.texi
> -@include docs/system/tls.texi
> -@include docs/system/gdb.texi
> -
> -@node QEMU System emulator for non PC targets
> -@chapter QEMU System emulator for non PC targets
> -
> -QEMU is a generic emulator and it emulates many non PC
> -machi

Re: [PATCH v3 08/33] qemu-doc: split target sections to separate files

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> From: Paolo Bonzini 
>
> Signed-off-by: Paolo Bonzini 
> Message-id: 20200226113034.6741-9-pbonz...@redhat.com
> Reviewed-by: Peter Maydell 
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

> ---
>  docs/system/target-arm.texi | 264 ++
>  docs/system/target-i386.texi|  92 
>  docs/system/target-m68k.texi|  46 ++
>  docs/system/target-mips.texi| 152 ++
>  docs/system/target-ppc.texi |  78 +++
>  docs/system/target-sparc.texi   |  96 
>  docs/system/target-sparc64.texi |  61 +++
>  docs/system/target-xtensa.texi  |  56 ++
>  qemu-doc.texi   | 873 +---
>  9 files changed, 853 insertions(+), 865 deletions(-)
>  create mode 100644 docs/system/target-arm.texi
>  create mode 100644 docs/system/target-i386.texi
>  create mode 100644 docs/system/target-m68k.texi
>  create mode 100644 docs/system/target-mips.texi
>  create mode 100644 docs/system/target-ppc.texi
>  create mode 100644 docs/system/target-sparc.texi
>  create mode 100644 docs/system/target-sparc64.texi
>  create mode 100644 docs/system/target-xtensa.texi
>
> diff --git a/docs/system/target-arm.texi b/docs/system/target-arm.texi
> new file mode 100644
> index 000..040d77b5e05
> --- /dev/null
> +++ b/docs/system/target-arm.texi
> @@ -0,0 +1,264 @@
> +@node ARM System emulator
> +@section ARM System emulator
> +@cindex system emulation (ARM)
> +
> +Use the executable @file{qemu-system-arm} to simulate a ARM
> +machine. The ARM Integrator/CP board is emulated with the following
> +devices:
> +
> +@itemize @minus
> +@item
> +ARM926E, ARM1026E, ARM946E, ARM1136 or Cortex-A8 CPU
> +@item
> +Two PL011 UARTs
> +@item
> +SMC 91c111 Ethernet adapter
> +@item
> +PL110 LCD controller
> +@item
> +PL050 KMI with PS/2 keyboard and mouse.
> +@item
> +PL181 MultiMedia Card Interface with SD card.
> +@end itemize
> +
> +The ARM Versatile baseboard is emulated with the following devices:
> +
> +@itemize @minus
> +@item
> +ARM926E, ARM1136 or Cortex-A8 CPU
> +@item
> +PL190 Vectored Interrupt Controller
> +@item
> +Four PL011 UARTs
> +@item
> +SMC 91c111 Ethernet adapter
> +@item
> +PL110 LCD controller
> +@item
> +PL050 KMI with PS/2 keyboard and mouse.
> +@item
> +PCI host bridge.  Note the emulated PCI bridge only provides access to
> +PCI memory space.  It does not provide access to PCI IO space.
> +This means some devices (eg. ne2k_pci NIC) are not usable, and others
> +(eg. rtl8139 NIC) are only usable when the guest drivers use the memory
> +mapped control registers.
> +@item
> +PCI OHCI USB controller.
> +@item
> +LSI53C895A PCI SCSI Host Bus Adapter with hard disk and CD-ROM devices.
> +@item
> +PL181 MultiMedia Card Interface with SD card.
> +@end itemize
> +
> +Several variants of the ARM RealView baseboard are emulated,
> +including the EB, PB-A8 and PBX-A9.  Due to interactions with the
> +bootloader, only certain Linux kernel configurations work out
> +of the box on these boards.
> +
> +Kernels for the PB-A8 board should have CONFIG_REALVIEW_HIGH_PHYS_OFFSET
> +enabled in the kernel, and expect 512M RAM.  Kernels for The PBX-A9 board
> +should have CONFIG_SPARSEMEM enabled, CONFIG_REALVIEW_HIGH_PHYS_OFFSET
> +disabled and expect 1024M RAM.
> +
> +The following devices are emulated:
> +
> +@itemize @minus
> +@item
> +ARM926E, ARM1136, ARM11MPCore, Cortex-A8 or Cortex-A9 MPCore CPU
> +@item
> +ARM AMBA Generic/Distributed Interrupt Controller
> +@item
> +Four PL011 UARTs
> +@item
> +SMC 91c111 or SMSC LAN9118 Ethernet adapter
> +@item
> +PL110 LCD controller
> +@item
> +PL050 KMI with PS/2 keyboard and mouse
> +@item
> +PCI host bridge
> +@item
> +PCI OHCI USB controller
> +@item
> +LSI53C895A PCI SCSI Host Bus Adapter with hard disk and CD-ROM devices
> +@item
> +PL181 MultiMedia Card Interface with SD card.
> +@end itemize
> +
> +The XScale-based clamshell PDA models ("Spitz", "Akita", "Borzoi"
> +and "Terrier") emulation includes the following peripherals:
> +
> +@itemize @minus
> +@item
> +Intel PXA270 System-on-chip (ARM V5TE core)
> +@item
> +NAND Flash memory
> +@item
> +IBM/Hitachi DSCM microdrive in a PXA PCMCIA slot - not in "Akita"
> +@item
> +On-chip OHCI USB controller
> +@item
> +On-chip LCD controller
> +@item
> +On-chip Real Time Clock
> +@item
> +TI ADS7846 touchscreen controller on SSP bus
> +@item
> +Maxim MAX analog-digital converter on I@math{^2}C bus
> +@item
> +GPIO-connected keyboard controller and LEDs
> +@item
> +Secure Digital card connected to PXA MMC/SD host
> +@item
> +Three on-chip UARTs
> +@item
> +WM8750 audio CODEC on I@math{^2}C and I@math{^2}S busses
> +@end itemize
> +
> +The Palm Tungsten|E PDA (codename "Cheetah") emulation includes the
> +following elements:
> +
> +@itemize @minus
> +@item
> +Texas Instruments OMAP310 System-on-chip (ARM 925T core)
> +@item
> +ROM and RAM memories (ROM firmware image can be loaded with -option-rom)
> +@item
> +On-chip LCD controller
> +@item
> +On-chip Rea

Re: [PATCH v2 1/4] qcow2: introduce compression type feature

2020-03-02 Thread Denis Plotnikov




On 02.03.2020 14:24, Vladimir Sementsov-Ogievskiy wrote:

02.03.2020 11:21, Denis Plotnikov wrote:

The patch adds some preparation parts for incompatible compression type
feature to qcow2 allowing the use different compression methods for
image clusters (de)compressing.

It is implied that the compression type is set on the image creation and
can be changed only later by image conversion, thus compression type
defines the only compression algorithm used for the image, and thus,
for all image clusters.

The goal of the feature is to add support of other compression methods
to qcow2. For example, ZSTD which is more effective on compression 
than ZLIB.


The default compression is ZLIB. Images created with ZLIB compression 
type

are backward compatible with older qemu versions.

Adding of the compression type breaks a number of tests because now the
compression type is reported on image creation and there are some 
changes

in the qcow2 header in size and offsets.

The tests are fixed in the following ways:
 * filter out compression_type for all the tests
 * fix header size, feature table size and backing file offset
   affected tests: 031, 036, 061, 080
   header_size +=8: 1 byte compression type
    7 bytes padding
   feature_table += 48: incompatible feture compression type
   backing_file_offset += 56 (8 + 48 -> header_change + 
fature_table_change)
 * add "compression type" for test output matching when it isn't 
filtered

   affected tests: 049, 060, 061, 065, 144, 182, 242, 255

Signed-off-by: Denis Plotnikov 


I'm almost OK with this patch. Some notes below and:

Seems, new option should be handled in qcow2_amend_options among other 
unsupported ones (otherwise qcow2_amend_options aborts).



---
  qapi/block-core.json |  22 ++-
  block/qcow2.h    |  18 -
  include/block/block_int.h    |   1 +
  block/qcow2.c    | 109 +++
  tests/qemu-iotests/031.out   |  14 ++--
  tests/qemu-iotests/036.out   |   4 +-
  tests/qemu-iotests/049.out   | 102 ++---
  tests/qemu-iotests/060.out   |   1 +
  tests/qemu-iotests/061.out   |  34 ++
  tests/qemu-iotests/065   |  20 +++---
  tests/qemu-iotests/080   |   2 +-
  tests/qemu-iotests/144.out   |   4 +-
  tests/qemu-iotests/182.out   |   2 +-
  tests/qemu-iotests/242.out   |   5 ++
  tests/qemu-iotests/255.out   |   8 +--
  tests/qemu-iotests/common.filter |   3 +-
  16 files changed, 255 insertions(+), 94 deletions(-)



[..]


--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -146,6 +146,12 @@ typedef struct QCowHeader {
    uint32_t refcount_order;
  uint32_t header_length;
+
+    /* Additional fields */
+    uint8_t  compression_type;
+
+    /* header must be a multiple of 8 */
+    uint8_t  padding[7];
  } QEMU_PACKED QCowHeader;
    typedef struct QEMU_PACKED QCowSnapshotHeader {
@@ -216,13 +222,16 @@ enum {
  QCOW2_INCOMPAT_DIRTY_BITNR  = 0,
  QCOW2_INCOMPAT_CORRUPT_BITNR    = 1,
  QCOW2_INCOMPAT_DATA_FILE_BITNR  = 2,
+    QCOW2_INCOMPAT_COMPRESSION_BITNR= 3,


checkpatch complains. I think, you can just use one space before '=' 
and don't

care about alignment.

ok



  QCOW2_INCOMPAT_DIRTY    = 1 << QCOW2_INCOMPAT_DIRTY_BITNR,
  QCOW2_INCOMPAT_CORRUPT  = 1 << 
QCOW2_INCOMPAT_CORRUPT_BITNR,
  QCOW2_INCOMPAT_DATA_FILE    = 1 << 
QCOW2_INCOMPAT_DATA_FILE_BITNR,
+    QCOW2_INCOMPAT_COMPRESSION  = 1 << 
QCOW2_INCOMPAT_COMPRESSION_BITNR,

    QCOW2_INCOMPAT_MASK = QCOW2_INCOMPAT_DIRTY
  | QCOW2_INCOMPAT_CORRUPT
-    | QCOW2_INCOMPAT_DATA_FILE,
+    | QCOW2_INCOMPAT_DATA_FILE
+    | QCOW2_INCOMPAT_COMPRESSION,
  };
    /* Compatible feature bits */
@@ -369,6 +378,13 @@ typedef struct BDRVQcow2State {
    bool metadata_preallocation_checked;
  bool metadata_preallocation;
+    /*
+ * Compression type used for the image. Default: 0 - ZLIB
+ * The image compression type is set on image creation.
+ * The only way to change the compression type is to convert the 
image

+ * with the desired compression type set
+ */
+    Qcow2CompressionType compression_type;
  } BDRVQcow2State;
    typedef struct Qcow2COWRegion {
diff --git a/include/block/block_int.h b/include/block/block_int.h
index 6f9fd5e20e..2c6bb9dc99 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -57,6 +57,7 @@
  #define BLOCK_OPT_REFCOUNT_BITS "refcount_bits"
  #define BLOCK_OPT_DATA_FILE "data_file"
  #define BLOCK_OPT_DATA_FILE_RAW "data_file_raw"
+#define BLOCK_OPT_COMPRESSION_TYPE  "compression_type"
    #define BLOCK_PROBE_BUF_SIZE    512
  diff --git a/block/qcow2.c b/block/qcow2.c
index 3c754f616b..fc5232a5d6 100

Re: [PATCH v3 11/33] qemu-doc: move included files to docs/system

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> From: Paolo Bonzini 
>
> Since qemu-doc.texi is mostly including files from docs/system,
> move the existing include files there for consistency.
>
> Signed-off-by: Paolo Bonzini 
> Message-id: 20200226113034.6741-12-pbonz...@redhat.com
> [PMM: update MAINTAINERS line for qemu-option-trace.texi]
> Reviewed-by: Peter Maydell 
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

> ---
>  Makefile  | 8 
>  MAINTAINERS   | 5 +++--
>  qemu-deprecated.texi => docs/system/deprecated.texi   | 0
>  .../system/qemu-option-trace.texi | 0
>  docs/{ => system}/security.texi   | 0
>  qemu-doc.texi | 4 ++--
>  qemu-options.hx   | 2 +-
>  7 files changed, 10 insertions(+), 9 deletions(-)
>  rename qemu-deprecated.texi => docs/system/deprecated.texi (100%)
>  rename qemu-option-trace.texi => docs/system/qemu-option-trace.texi (100%)
>  rename docs/{ => system}/security.texi (100%)
>
> diff --git a/Makefile b/Makefile
> index 56382a45936..7e60a435426 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1110,7 +1110,7 @@ docs/interop/qemu-ga-qapi.texi: 
> qga/qapi-generated/qga-qapi-doc.texi
>   @cp -p $< $@
>  
>  qemu.1: qemu-doc.texi qemu-options.texi qemu-monitor.texi 
> qemu-monitor-info.texi
> -qemu.1: qemu-option-trace.texi
> +qemu.1: docs/system/qemu-option-trace.texi
>  docs/system/qemu-cpu-models.7: docs/system/qemu-cpu-models.texi 
> docs/system/cpu-models-x86.texi docs/system/cpu-models-mips.texi
>  
>  html: qemu-doc.html docs/interop/qemu-qmp-ref.html 
> docs/interop/qemu-ga-ref.html sphinxdocs
> @@ -1120,8 +1120,7 @@ txt: qemu-doc.txt docs/interop/qemu-qmp-ref.txt 
> docs/interop/qemu-ga-ref.txt
>  
>  qemu-doc.html qemu-doc.info qemu-doc.pdf qemu-doc.txt: \
>   qemu-options.texi \
> - qemu-option-trace.texi \
> - qemu-deprecated.texi qemu-monitor.texi \
> + qemu-monitor.texi \
>   qemu-monitor-info.texi \
>  docs/system/quickstart.texi \
>  docs/system/invocation.texi \
> @@ -1140,7 +1139,8 @@ qemu-doc.html qemu-doc.info qemu-doc.pdf qemu-doc.txt: \
>  docs/system/build-platforms.texi \
>  docs/system/license.texi \
>   docs/system/cpu-models-x86.texi docs/system/cpu-models-mips.texi \
> - docs/security.texi
> + docs/system/deprecated.texi docs/system/qemu-option-trace.texi \
> + docs/system/security.texi
>  
>  docs/interop/qemu-ga-ref.dvi docs/interop/qemu-ga-ref.html \
>  docs/interop/qemu-ga-ref.info docs/interop/qemu-ga-ref.pdf \
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8c6d8f533ce..74b025fb806 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2232,7 +2232,7 @@ M: Stefan Hajnoczi 
>  S: Maintained
>  F: trace/
>  F: trace-events
> -F: qemu-option-trace.texi
> +F: docs/system/qemu-option-trace.texi
>  F: scripts/tracetool.py
>  F: scripts/tracetool/
>  F: scripts/qemu-trace-stap*
> @@ -2802,7 +2802,8 @@ F: contrib/gitdm/*
>  
>  Incompatible changes
>  R: libvir-l...@redhat.com
> -F: qemu-deprecated.texi
> +F: docs/system/deprecated.texi
> +F: docs/system/deprecated.rst
>  
>  Build System
>  
> diff --git a/qemu-deprecated.texi b/docs/system/deprecated.texi
> similarity index 100%
> rename from qemu-deprecated.texi
> rename to docs/system/deprecated.texi
> diff --git a/qemu-option-trace.texi b/docs/system/qemu-option-trace.texi
> similarity index 100%
> rename from qemu-option-trace.texi
> rename to docs/system/qemu-option-trace.texi
> diff --git a/docs/security.texi b/docs/system/security.texi
> similarity index 100%
> rename from docs/security.texi
> rename to docs/system/security.texi
> diff --git a/qemu-doc.texi b/qemu-doc.texi
> index e4bff7edbee..d3e743719ab 100644
> --- a/qemu-doc.texi
> +++ b/qemu-doc.texi
> @@ -189,9 +189,9 @@ various targets are mentioned in the following sections.
>  @include docs/system/target-m68k.texi
>  @include docs/system/target-xtensa.texi
>  
> -@include docs/security.texi
> +@include docs/system/security.texi
>  
> -@include qemu-deprecated.texi
> +@include docs/system/deprecated.texi
>  
>  @include docs/system/build-platforms.texi
>  
> diff --git a/qemu-options.hx b/qemu-options.hx
> index ac315c1ac45..5fbfa2797cb 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -4221,7 +4221,7 @@ HXCOMM This line is not accurate, as some sub-options 
> are backend-specific but
>  HXCOMM HX does not support conditional compilation of text.
>  @item -trace [[enable=]@var{pattern}][,events=@var{file}][,file=@var{file}]
>  @findex -trace
> -@include qemu-option-trace.texi
> +@include docs/system/qemu-option-trace.texi
>  ETEXI
>  DEF("plugin", HAS_ARG, QEMU_OPTION_plugin,
>  "-plugin [file=][,arg=]\n"


-- 
Alex Bennée



Re: [PATCH v3 10/33] qemu-doc: move qemu-tech.texi into main section

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> From: Paolo Bonzini 
>
> The only remaining content in qemu-tech.texi is a few paragraphs
> about managed start up options.  Move them in the main section
> about full system emulation.
>
> Signed-off-by: Paolo Bonzini 
> Message-id: 20200226113034.6741-11-pbonz...@redhat.com
> Reviewed-by: Peter Maydell 
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

> ---
>  Makefile   | 2 +-
>  qemu-tech.texi => docs/system/managed-startup.texi | 9 +
>  qemu-doc.texi  | 5 ++---
>  3 files changed, 4 insertions(+), 12 deletions(-)
>  rename qemu-tech.texi => docs/system/managed-startup.texi (92%)
>
> diff --git a/Makefile b/Makefile
> index 9790a0fd15b..56382a45936 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1120,7 +1120,7 @@ txt: qemu-doc.txt docs/interop/qemu-qmp-ref.txt 
> docs/interop/qemu-ga-ref.txt
>  
>  qemu-doc.html qemu-doc.info qemu-doc.pdf qemu-doc.txt: \
>   qemu-options.texi \
> - qemu-tech.texi qemu-option-trace.texi \
> + qemu-option-trace.texi \
>   qemu-deprecated.texi qemu-monitor.texi \
>   qemu-monitor-info.texi \
>  docs/system/quickstart.texi \
> diff --git a/qemu-tech.texi b/docs/system/managed-startup.texi
> similarity index 92%
> rename from qemu-tech.texi
> rename to docs/system/managed-startup.texi
> index 35da6a40af1..ec168095cc4 100644
> --- a/qemu-tech.texi
> +++ b/docs/system/managed-startup.texi
> @@ -1,11 +1,4 @@
> -@node Implementation notes
> -@appendix Implementation notes
> -
> -@menu
> -* Managed start up options::
> -@end menu
> -
> -@node Managed start up options
> +@node managed_startup
>  @section Managed start up options
>  
>  In system mode emulation, it's possible to create a VM in a paused state 
> using
> diff --git a/qemu-doc.texi b/qemu-doc.texi
> index f702dce4557..e4bff7edbee 100644
> --- a/qemu-doc.texi
> +++ b/qemu-doc.texi
> @@ -39,7 +39,6 @@
>  * QEMU System emulator::
>  * QEMU System emulator targets::
>  * Security::
> -* Implementation notes::
>  * Deprecated features::
>  * Recently removed features::
>  * Supported build platforms::
> @@ -144,6 +143,7 @@ accelerator is required to use more than one host CPU for 
> emulation.
>  * vnc_security::   VNC security
>  * network_tls::TLS setup for network services
>  * gdb_usage::  GDB usage
> +* managed_startup::Managed startup options
>  @end menu
>  
>  @include docs/system/quickstart.texi
> @@ -159,6 +159,7 @@ accelerator is required to use more than one host CPU for 
> emulation.
>  @include docs/system/vnc-security.texi
>  @include docs/system/tls.texi
>  @include docs/system/gdb.texi
> +@include docs/system/managed-startup.texi
>  
>  @node QEMU System emulator targets
>  @chapter QEMU System emulator targets
> @@ -190,8 +191,6 @@ various targets are mentioned in the following sections.
>  
>  @include docs/security.texi
>  
> -@include qemu-tech.texi
> -
>  @include qemu-deprecated.texi
>  
>  @include docs/system/build-platforms.texi


-- 
Alex Bennée



Re: [PATCH v3 09/33] qemu-doc: Remove the "CPU emulation" part of the "Implementation notes"

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> The "CPU emulation" part of the "Implementation notes" in
> qemu-tech.texi looks like it is documenting what features of various
> CPUs we do or don't emulate.  However:
>  * it covers only six of our 21 guest architectures
>  * the last time anybody updated it for actual content was in
>2011/2012 for Xtensa; the content for the other five
>architectures is even older, being from 2008 or before!
>
> What we have is out of date, misleading and incomplete.
> Just delete this part of the document rather than trying to
> convert it to rST.
>
> (It would be nice eventually to have documentation of the
> scope and limitations of our emulation; but we will want to
> separate out the generic "system emulation" information from
> the parts that are specific to linux-user anyway, as they will
> be in different manuals.)

Ahh I guess this is what would be the TCG specifics. I wonder if what
replaces this is more suitable as developer documentation? Anyway happy
to delete the cruft:

Reviewed-by: Alex Bennée 

>
> Signed-off-by: Peter Maydell 
> Message-id: 20200226113034.6741-10-pbonz...@redhat.com
> Message-Id: <20200225154121.21116-3-peter.mayd...@linaro.org>
> Signed-off-by: Paolo Bonzini 
> ---
>  qemu-tech.texi | 153 -
>  1 file changed, 153 deletions(-)
>
> diff --git a/qemu-tech.texi b/qemu-tech.texi
> index 0380de77b62..35da6a40af1 100644
> --- a/qemu-tech.texi
> +++ b/qemu-tech.texi
> @@ -2,162 +2,9 @@
>  @appendix Implementation notes
>  
>  @menu
> -* CPU emulation::
>  * Managed start up options::
>  @end menu
>  
> -@node CPU emulation
> -@section CPU emulation
> -
> -@menu
> -* x86:: x86 and x86-64 emulation
> -* ARM:: ARM emulation
> -* MIPS::MIPS emulation
> -* PPC:: PowerPC emulation
> -* SPARC::   Sparc32 and Sparc64 emulation
> -* Xtensa::  Xtensa emulation
> -@end menu
> -
> -@node x86
> -@subsection x86 and x86-64 emulation
> -
> -QEMU x86 target features:
> -
> -@itemize
> -
> -@item The virtual x86 CPU supports 16 bit and 32 bit addressing with 
> segmentation.
> -LDT/GDT and IDT are emulated. VM86 mode is also supported to run
> -DOSEMU. There is some support for MMX/3DNow!, SSE, SSE2, SSE3, SSSE3,
> -and SSE4 as well as x86-64 SVM.
> -
> -@item Support of host page sizes bigger than 4KB in user mode emulation.
> -
> -@item QEMU can emulate itself on x86.
> -
> -@item An extensive Linux x86 CPU test program is included 
> @file{tests/test-i386}.
> -It can be used to test other x86 virtual CPUs.
> -
> -@end itemize
> -
> -Current QEMU limitations:
> -
> -@itemize
> -
> -@item Limited x86-64 support.
> -
> -@item IPC syscalls are missing.
> -
> -@item The x86 segment limits and access rights are not tested at every
> -memory access (yet). Hopefully, very few OSes seem to rely on that for
> -normal use.
> -
> -@end itemize
> -
> -@node ARM
> -@subsection ARM emulation
> -
> -@itemize
> -
> -@item Full ARM 7 user emulation.
> -
> -@item NWFPE FPU support included in user Linux emulation.
> -
> -@item Can run most ARM Linux binaries.
> -
> -@end itemize
> -
> -@node MIPS
> -@subsection MIPS emulation
> -
> -@itemize
> -
> -@item The system emulation allows full MIPS32/MIPS64 Release 2 emulation,
> -including privileged instructions, FPU and MMU, in both little and big
> -endian modes.
> -
> -@item The Linux userland emulation can run many 32 bit MIPS Linux binaries.
> -
> -@end itemize
> -
> -Current QEMU limitations:
> -
> -@itemize
> -
> -@item Self-modifying code is not always handled correctly.
> -
> -@item 64 bit userland emulation is not implemented.
> -
> -@item The system emulation is not complete enough to run real firmware.
> -
> -@item The watchpoint debug facility is not implemented.
> -
> -@end itemize
> -
> -@node PPC
> -@subsection PowerPC emulation
> -
> -@itemize
> -
> -@item Full PowerPC 32 bit emulation, including privileged instructions,
> -FPU and MMU.
> -
> -@item Can run most PowerPC Linux binaries.
> -
> -@end itemize
> -
> -@node SPARC
> -@subsection Sparc32 and Sparc64 emulation
> -
> -@itemize
> -
> -@item Full SPARC V8 emulation, including privileged
> -instructions, FPU and MMU. SPARC V9 emulation includes most privileged
> -and VIS instructions, FPU and I/D MMU. Alignment is fully enforced.
> -
> -@item Can run most 32-bit SPARC Linux binaries, SPARC32PLUS Linux binaries 
> and
> -some 64-bit SPARC Linux binaries.
> -
> -@end itemize
> -
> -Current QEMU limitations:
> -
> -@itemize
> -
> -@item IPC syscalls are missing.
> -
> -@item Floating point exception support is buggy.
> -
> -@item Atomic instructions are not correctly implemented.
> -
> -@item There are still some problems with Sparc64 emulators.
> -
> -@end itemize
> -
> -@node Xtensa
> -@subsection Xtensa emulation
> -
> -@itemize
> -
> -@item Core Xtensa ISA emulation, including most options: code density,
> -loop, extended L32R, 16- and 32-bit multiplication, 32-bit division,
> -MAC16, miscellaneous operations

Re: [PATCH v3 12/33] qemu-doc: remove indices other than findex

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> From: Paolo Bonzini 
>
> These indices are not well-maintained, and pandoc also chokes on the
> directives.  Just nuke them.
>
> Signed-off-by: Paolo Bonzini 
> Message-id: 20200226113034.6741-13-pbonz...@redhat.com
> Reviewed-by: Peter Maydell 
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

> ---
>  docs/system/keys.texi   | 10 
>  docs/system/monitor.texi|  1 -
>  docs/system/mux-chardev.texi|  7 --
>  docs/system/quickstart.texi |  1 -
>  docs/system/target-arm.texi |  1 -
>  docs/system/target-i386.texi|  1 -
>  docs/system/target-m68k.texi|  2 --
>  docs/system/target-mips.texi|  2 --
>  docs/system/target-ppc.texi |  1 -
>  docs/system/target-sparc.texi   |  1 -
>  docs/system/target-sparc64.texi |  1 -
>  docs/system/target-xtensa.texi  |  1 -
>  qemu-doc.texi   | 44 -
>  13 files changed, 73 deletions(-)
>
> diff --git a/docs/system/keys.texi b/docs/system/keys.texi
> index 4c74b3bf4dd..c04daf54f23 100644
> --- a/docs/system/keys.texi
> +++ b/docs/system/keys.texi
> @@ -10,23 +10,18 @@ then the modifier is Ctrl-Alt-Shift (instead of Ctrl-Alt) 
> and if you use
>  
>  @table @key
>  @item Ctrl-Alt-f
> -@kindex Ctrl-Alt-f
>  Toggle full screen
>  
>  @item Ctrl-Alt-+
> -@kindex Ctrl-Alt-+
>  Enlarge the screen
>  
>  @item Ctrl-Alt--
> -@kindex Ctrl-Alt--
>  Shrink the screen
>  
>  @item Ctrl-Alt-u
> -@kindex Ctrl-Alt-u
>  Restore the screen's un-scaled dimensions
>  
>  @item Ctrl-Alt-n
> -@kindex Ctrl-Alt-n
>  Switch to virtual console 'n'. Standard console mappings are:
>  @table @emph
>  @item 1
> @@ -38,14 +33,9 @@ Serial port
>  @end table
>  
>  @item Ctrl-Alt
> -@kindex Ctrl-Alt
>  Toggle mouse and keyboard grab.
>  @end table
>  
> -@kindex Ctrl-Up
> -@kindex Ctrl-Down
> -@kindex Ctrl-PageUp
> -@kindex Ctrl-PageDown
>  In the virtual consoles, you can use @key{Ctrl-Up}, @key{Ctrl-Down},
>  @key{Ctrl-PageUp} and @key{Ctrl-PageDown} to move in the back log.
>  
> diff --git a/docs/system/monitor.texi b/docs/system/monitor.texi
> index c5b6a9b38e4..b41b144885d 100644
> --- a/docs/system/monitor.texi
> +++ b/docs/system/monitor.texi
> @@ -1,6 +1,5 @@
>  @node pcsys_monitor
>  @section QEMU Monitor
> -@cindex QEMU monitor
>  
>  The QEMU monitor is used to give complex commands to the QEMU
>  emulator. You can use it to:
> diff --git a/docs/system/mux-chardev.texi b/docs/system/mux-chardev.texi
> index c9a2d14cb88..b21c2c56540 100644
> --- a/docs/system/mux-chardev.texi
> +++ b/docs/system/mux-chardev.texi
> @@ -12,26 +12,19 @@ you're using the default.
>  
>  @table @key
>  @item Ctrl-a h
> -@kindex Ctrl-a h
>  Print this help
>  @item Ctrl-a x
> -@kindex Ctrl-a x
>  Exit emulator
>  @item Ctrl-a s
> -@kindex Ctrl-a s
>  Save disk data back to file (if -snapshot)
>  @item Ctrl-a t
> -@kindex Ctrl-a t
>  Toggle console timestamps
>  @item Ctrl-a b
> -@kindex Ctrl-a b
>  Send break (magic sysrq in Linux)
>  @item Ctrl-a c
> -@kindex Ctrl-a c
>  Rotate between the frontends connected to the multiplexer (usually
>  this switches between the monitor and the console)
>  @item Ctrl-a Ctrl-a
> -@kindex Ctrl-a Ctrl-a
>  Send the escape character to the frontend
>  @end table
>  @c man end
> diff --git a/docs/system/quickstart.texi b/docs/system/quickstart.texi
> index ed7295de7a2..baceaa96eb2 100644
> --- a/docs/system/quickstart.texi
> +++ b/docs/system/quickstart.texi
> @@ -1,6 +1,5 @@
>  @node pcsys_quickstart
>  @section Quick Start
> -@cindex quick start
>  
>  Download and uncompress a PC hard disk image with Linux installed (e.g.
>  @file{linux.img}) and type:
> diff --git a/docs/system/target-arm.texi b/docs/system/target-arm.texi
> index 040d77b5e05..c56b5f6ebfe 100644
> --- a/docs/system/target-arm.texi
> +++ b/docs/system/target-arm.texi
> @@ -1,6 +1,5 @@
>  @node ARM System emulator
>  @section ARM System emulator
> -@cindex system emulation (ARM)
>  
>  Use the executable @file{qemu-system-arm} to simulate a ARM
>  machine. The ARM Integrator/CP board is emulated with the following
> diff --git a/docs/system/target-i386.texi b/docs/system/target-i386.texi
> index edd23fa8df5..cc352b89a84 100644
> --- a/docs/system/target-i386.texi
> +++ b/docs/system/target-i386.texi
> @@ -1,6 +1,5 @@
>  @node x86 (PC) System emulator
>  @section x86 (PC) System emulator
> -@cindex system emulation (PC)
>  
>  @menu
>  * pcsys_devices::  Peripherals
> diff --git a/docs/system/target-m68k.texi b/docs/system/target-m68k.texi
> index b5bc9df40ae..a77b19ea0f1 100644
> --- a/docs/system/target-m68k.texi
> +++ b/docs/system/target-m68k.texi
> @@ -1,7 +1,5 @@
>  @node ColdFire System emulator
>  @section ColdFire System emulator
> -@cindex system emulation (ColdFire)
> -@cindex system emulation (M68K)
>  
>  Use the executable @file{qemu-system-m68k} to simulate a ColdFire machine.
>  The emulator is able to boot a uClinux kernel.
> diff --git a/docs/system/target-mip

Re: [PATCH v3 13/33] docs/system: put qemu-block-drivers body in an included file

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> From: Paolo Bonzini 
>
> This removes the "only" directives, and lets us use the conventional
> "DESCRIPTION" section in the manpage.
>
> This temporarily drops the qemu-block-drivers documentation
> from the system manual, but it will be put back (in the
> right place in the toctree) in a later commit.
>
> Signed-off-by: Paolo Bonzini 
> Message-id: 20200226113034.6741-14-pbonz...@redhat.com
> Reviewed-by: Peter Maydell 
> [PMM: Added commit message note about temporarily losing
> qemu-block-drivers from the system manual]
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

> ---
>  docs/system/index.rst |   1 -
>  docs/system/qemu-block-drivers.rst| 987 +-
>  ...drivers.rst => qemu-block-drivers.rst.inc} |  59 +-
>  3 files changed, 26 insertions(+), 1021 deletions(-)
>  copy docs/system/{qemu-block-drivers.rst => qemu-block-drivers.rst.inc} (96%)
>
> diff --git a/docs/system/index.rst b/docs/system/index.rst
> index 1a4b2c82ace..fc774a18b54 100644
> --- a/docs/system/index.rst
> +++ b/docs/system/index.rst
> @@ -14,5 +14,4 @@ Contents:
>  .. toctree::
> :maxdepth: 2
>  
> -   qemu-block-drivers
> vfio-ap
> diff --git a/docs/system/qemu-block-drivers.rst 
> b/docs/system/qemu-block-drivers.rst
> index 388adbefbf4..7ca890ea23a 100644
> --- a/docs/system/qemu-block-drivers.rst
> +++ b/docs/system/qemu-block-drivers.rst
> @@ -1,985 +1,22 @@
> +:orphan:
> +
>  QEMU block drivers reference
>  
>  
>  .. |qemu_system| replace:: qemu-system-x86_64
>  
> -..
> -   We put the 'Synopsis' and 'See also' sections into the manpage, but not
> -   the HTML. This makes the HTML docs read better and means the ToC in
> -   the index has a more useful set of entries. Ideally, the section
> -   headings 'Disk image file formats' would be top-level headings for
> -   the HTML, but sub-headings of the conventional manpage 'Description'
> -   header for the manpage. Unfortunately, due to deficiencies in
> -   the Sphinx 'only' directive, this isn't possible: they must be headers
> -   at the same level as 'Synopsis' and 'See also', otherwise Sphinx's
> -   identification of which header underline style is which gets confused.
> +Synopsis
> +
>  
> -.. only:: man
> +QEMU block driver reference manual
>  
> -  Synopsis
> -  
> +Description
> +---
>  
> -  QEMU block driver reference manual
> +.. include:: qemu-block-drivers.rst.inc
>  
> -Disk image file formats
> 
> +See also
> +
>  
> -QEMU supports many image file formats that can be used with VMs as well as 
> with
> -any of the tools (like ``qemu-img``). This includes the preferred formats
> -raw and qcow2 as well as formats that are supported for compatibility with
> -older QEMU versions or other hypervisors.
> -
> -Depending on the image format, different options can be passed to
> -``qemu-img create`` and ``qemu-img convert`` using the ``-o`` option.
> -This section describes each format and the options that are supported for it.
> -
> -.. program:: image-formats
> -.. option:: raw
> -
> -  Raw disk image format. This format has the advantage of
> -  being simple and easily exportable to all other emulators. If your
> -  file system supports *holes* (for example in ext2 or ext3 on
> -  Linux or NTFS on Windows), then only the written sectors will reserve
> -  space. Use ``qemu-img info`` to know the real size used by the
> -  image or ``ls -ls`` on Unix/Linux.
> -
> -  Supported options:
> -
> -  .. program:: raw
> -  .. option:: preallocation
> -
> -Preallocation mode (allowed values: ``off``, ``falloc``,
> -``full``). ``falloc`` mode preallocates space for image by
> -calling ``posix_fallocate()``. ``full`` mode preallocates space
> -for image by writing data to underlying storage. This data may or
> -may not be zero, depending on the storage location.
> -
> -.. program:: image-formats
> -.. option:: qcow2
> -
> -  QEMU image format, the most versatile format. Use it to have smaller
> -  images (useful if your filesystem does not supports holes, for example
> -  on Windows), zlib based compression and support of multiple VM
> -  snapshots.
> -
> -  Supported options:
> -
> -  .. program:: qcow2
> -  .. option:: compat
> -
> -Determines the qcow2 version to use. ``compat=0.10`` uses the
> -traditional image format that can be read by any QEMU since 0.10.
> -``compat=1.1`` enables image format extensions that only QEMU 1.1 and
> -newer understand (this is the default). Amongst others, this includes
> -zero clusters, which allow efficient copy-on-read for sparse images.
> -
> -  .. option:: backing_file
> -
> -File name of a base image (see ``create`` subcommand)
> -
> -  .. option:: backing_fmt
> -
> -Image format of the base image
> -
> -  .. option:: encryption
> -
> -This option is deprecated and equivalent to ``encrypt.format=aes``
> -
> -

Re: [PATCH] hw/arm/smmu-common: a fix to smmu_find_smmu_pcibus

2020-03-02 Thread Peter Maydell
On Mon, 2 Mar 2020 at 11:02, Peter Maydell  wrote:
> Would one of you like to submit a patch that does it that way
> round, please?

Aha, I see you already did:
https://patchew.org/QEMU/20200227164728.11635-1-phi...@redhat.com/
(I process my to-review queue mostly oldest-first).

thanks
-- PMM



Re: [PATCH v3 0/2] hw/arm/smmu-common: Avoid smmu_find_smmu_pcibus return dangling pointer

2020-03-02 Thread Peter Maydell
On Thu, 27 Feb 2020 at 16:47, Philippe Mathieu-Daudé  wrote:
>
> This series include the previous patch from Eric, then a
> code refactor to avoid similar mistakes in the future.
>
> Eric Auger (1):
>   hw/arm/smmu-common: a fix to smmu_find_smmu_pcibus
>
> Philippe Mathieu-Daudé (1):
>   hw/arm/smmu-common: Simplify smmu_find_smmu_pcibus() logic
>
>  hw/arm/smmu-common.c | 20 +++-
>  1 file changed, 11 insertions(+), 9 deletions(-)



Applied to target-arm.next, thanks.

-- PMM



Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC

2020-03-02 Thread BALATON Zoltan

On Sun, 1 Mar 2020, Richard Henderson wrote:

On 3/1/20 4:13 PM, Programmingkid wrote:
Ok, I was just looking at Intel's x87 chip documentation. It supports 
IEEE 754 floating point operations and exception flags. This leads me 
to this question. Would simply taking the host exception flags and 
using them to set the PowerPC's FPU's flag be an acceptable solution to 
this problem?


In my understanding that's what is currently done, the problem with PPC as 
Richard said is the non-sticky versions of some of these bits which need 
clearing FP exception status before every FPU op which seems to be 
expensive and slower than using softfloat. So to use hardfloat we either 
accept that we can't emulate these bits with hardfloat or we need to do 
something else than clearing flags and checking after every FPU op.


While not emulating these bits don't seem to matter for most clients and 
other PPC emulations got away with it, QEMU prefers accuracy over speed 
even for rarely used features.



No.

The primary issue is the FPSCR.FI flag.  This is not an accumulative bit, per
ieee754, but per operation.

The "hardfloat" option works (with other targets) only with ieee745
accumulative exceptions, when the most common of those exceptions, inexact, has
already been raised.  And thus need not be raised a second time.


Why exactly it's done that way? What are the differences between IEEE FP 
implementations that prevents using hardfloat most of the time instead of 
only using it in some (although supposedly common) special cases?



Per the PowerPC architecture, inexact must be recognized afresh for every
operation.  Which is cheap in hardware but expensive in software.

And once you're done with FI, FR has been and continues to be emulated 
incorrectly.


I think CPUs can also raise exceptions when they detect the condition in 
hardware so maybe we should install our FPU exception handler and set 
guest flags from that then we don't need to check and won't have problem 
with these bits either. Why is that not possible or isn't done? The 
softfloat code has a comment that working with exceptions is not pleasent 
but why? Isn't setting flags from a handler easier than checking 
separately for each op? If this is because of differences in how flags are 
handled by different targets we don't have to do that from the host FPU 
exception handler. That handler could only set a global flag on each 
exception that targets can be checked by targets and handle differences. 
This global flag then can include non-sticky versions if needed because 
clearing a global should be less expensive than clearing FPU status reg. 
But I don't really know, just guessing, somone who knows more about FPUs 
probably knows a better way.


Regards,
BALATON Zoltan



Re: [PATCH 0/5] hw/arm: Remove big-endian checks on machine code

2020-03-02 Thread Peter Maydell
On Fri, 28 Feb 2020 at 12:53, Philippe Mathieu-Daudé  wrote:
>
> We only build the little-endian softmmu configurations.
> Checking for big endian is pointless, remove the unused code.
>
> Philippe Mathieu-Daudé (5):
>   hw/arm/gumstix: Simplify since the machines are little-endian only
>   hw/arm/mainstone: Simplify since the machines are little-endian only
>   hw/arm/omap_sx1: Simplify since the machines are little-endian only
>   hw/arm/z2: Simplify since the machines are little-endian only
>   hw/arm/musicpal: Simplify since the machines are little-endian only
>
>  hw/arm/gumstix.c   | 16 ++--
>  hw/arm/mainstone.c |  8 +---
>  hw/arm/musicpal.c  | 10 --
>  hw/arm/omap_sx1.c  | 11 ++-
>  hw/arm/z2.c|  8 +---
>  5 files changed, 6 insertions(+), 47 deletions(-)



Applied to target-arm.next, thanks.

-- PMM



Re: [PATCH v3 2/4] target/i386: Remove monitor from some CPU models

2020-03-02 Thread Tao Xu

On 2/29/2020 5:39 AM, Eduardo Habkost wrote:

On Wed, Feb 12, 2020 at 04:13:26PM +0800, Tao Xu wrote:

Add new version of Snowridge, Denverton, Opteron_G3, EPYC, and Dhyana
CPU model to uremove MONITOR/MWAIT featre.

After QEMU/KVM use "-overcommit cpu-pm=on" to expose MONITOR/MWAIT
(commit id 6f131f13e68d648a8e4f083c667ab1acd88ce4cd), the MONITOR/MWAIT
feature in these CPU model is unused.

Signed-off-by: Tao Xu 


What exactly is the problem you are trying to fix?

No CPU model will ever have monitor=on set by default with KVM,
because kvm_default_props has a monitor=off element.



Maybe it is not a fix. For example, when we boot a guest with Denverton
cpu model, guest cannot detect MONITOR/MWAIT and boot with no warning, 
because of "monitor=off" by default. The MONITOR/MWAIT feature in these 
CPU model is unused,but no harm. I am wondering if we should remove it 
from existing CPU models.




Re: [PATCH 0/8] target/arm: Misc cleanups surrounding TBI

2020-03-02 Thread Peter Maydell
On Tue, 25 Feb 2020 at 03:12, Richard Henderson
 wrote:
>
> We have a bug at present wherein we do not supply the memory tag to
> the memory system, so that on fault FAR_ELx does not contain the
> correct value.
>
> For system mode, we already handle ignoring TBI in get_phys_addr_lpae,
> as long as we don't actually drop the tag during translation.
> For user mode, we don't have that option, so for now we must simply
> accept that we'll get the wrong value in the siginfo_t.

Something weird happened to this series: it looks like
the first 2 patches were sent as replies to the cover letter,
but then patches 3-8 were all replies to patch 2:

https://lists.gnu.org/archive/html/qemu-devel/2020-02/msg06699.html

The result is that neither patches nor patchew think they
got the entire series. Could you resend it, please?

thanks
-- PMM



Re: [PATCH 1/8] target/arm: Replicate TBI/TBID bits for single range regimes

2020-03-02 Thread Peter Maydell
On Tue, 25 Feb 2020 at 03:12, Richard Henderson
 wrote:
>
> Replicate the single TBI bit from TCR_EL2 and TCR_EL3 so that
> we can unconditionally use pointer bit 55 to index into our
> composite TBI1:TBI0 field.
>
> Signed-off-by: Richard Henderson 
> ---
>  target/arm/helper.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

Reviewed-by: Peter Maydell 

thanks
-- PMM



Re: [PATCH v3 4/4] target/i386: Add notes for versioned CPU models

2020-03-02 Thread Tao Xu

On 2/29/2020 5:52 AM, Eduardo Habkost wrote:

On Wed, Feb 12, 2020 at 04:13:28PM +0800, Tao Xu wrote:

Add which features are added or removed in this version. Remove the
changed model-id in versioned CPU models, to keep the model name
unchanged at /proc/cpuinfo inside the VM.

Signed-off-by: Tao Xu 
---

Changes in v2:
 - correct the note of Cascadelake v3 (Xiaoyao)
---
  target/i386/cpu.c | 54 ++-
  1 file changed, 25 insertions(+), 29 deletions(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 81a039beb6..739ef4ce91 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2278,10 +2278,9 @@ static X86CPUDefinition builtin_x86_defs[] = {
  {
  .version = 2,
  .alias = "Nehalem-IBRS",
+.note = "IBRS",
  .props = (PropValue[]) {
  { "spec-ctrl", "on" },
-{ "model-id",
-  "Intel Core i7 9xx (Nehalem Core i7, IBRS update)" },
  { /* end of list */ }


Changing model-id is guest-visible, so we can't do this.  The
same applies to the other models where model-id is being removed.

I suggest using the .note property only on the CPU model versions
that don't have custom model-id set yet, or when existing
information on model-id is incomplete.

For future CPU model versions, we can start using only .note and
stop changing model-id.



Got it,thanks!



Re: [PATCH 2/8] target/arm: Optimize cpu_mmu_index

2020-03-02 Thread Peter Maydell
On Tue, 25 Feb 2020 at 03:14, Richard Henderson
 wrote:
>
> We now cache the core mmu_idx in env->hflags.  Rather than recompute
> from scratch, extract the field.  All of the uses of cpu_mmu_index
> within target/arm are within helpers where env->hflags is stable.

Do you mean "within helpers, and env->hflags is always stable in
a helper", or "within helpers, and env->hflags is stable for the
particular set of helpers where we use cpu_mmu_index, though it might
not be in other helpers" ?

thanks
-- PMM



Re: [PATCH 3/8] target/arm: Apply TBI to ESR_ELx in helper_exception_return

2020-03-02 Thread Peter Maydell
On Tue, 25 Feb 2020 at 03:14, Richard Henderson
 wrote:
>
> We missed this case within AArch64.ExceptionReturn.
>
> Signed-off-by: Richard Henderson 
> ---
>  target/arm/helper-a64.c | 23 ++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/target/arm/helper-a64.c b/target/arm/helper-a64.c
> index 509ae93069..95e9e879ca 100644
> --- a/target/arm/helper-a64.c
> +++ b/target/arm/helper-a64.c
> @@ -1031,6 +1031,8 @@ void HELPER(exception_return)(CPUARMState *env, 
> uint64_t new_pc)
>"AArch32 EL%d PC 0x%" PRIx32 "\n",
>cur_el, new_el, env->regs[15]);
>  } else {
> +int tbii;
> +
>  env->aarch64 = 1;
>  spsr &= aarch64_pstate_valid_mask(&env_archcpu(env)->isar);
>  pstate_write(env, spsr);
> @@ -1038,8 +1040,27 @@ void HELPER(exception_return)(CPUARMState *env, 
> uint64_t new_pc)
>  env->pstate &= ~PSTATE_SS;
>  }
>  aarch64_restore_sp(env, new_el);
> -env->pc = new_pc;
>  helper_rebuild_hflags_a64(env, new_el);
> +
> +/*
> + * Apply TBI to the exception return address.  We had to delay this
> + * until after we selected the new EL, so that we could select the
> + * correct TBI+TBID bits.  This is made easier by waiting until after
> + * the hflags rebuild, since we can pull the composite TBII field
> + * from there.
> + */
> +tbii = FIELD_EX32(env->hflags, TBFLAG_A64, TBII);
> +if ((tbii >> extract64(new_pc, 55, 1)) & 1) {
> +/* TBI is enabled. */
> +int core_mmu_idx = cpu_mmu_index(env, false);
> +if (regime_has_2_ranges(core_mmu_idx | ARM_MMU_IDX_A)) {

We have core_to_arm_mmu_idx() so you don't need to open-code this.
Or just call arm_mmu_idx(env) to get the ARMMMUIdx directly.

> +new_pc = sextract64(new_pc, 0, 56);
> +} else {
> +new_pc = extract64(new_pc, 0, 56);
> +}
> +}
> +env->pc = new_pc;
> +
>  qemu_log_mask(CPU_LOG_INT, "Exception return from AArch64 EL%d to "
>"AArch64 EL%d PC 0x%" PRIx64 "\n",
>cur_el, new_el, env->pc);

thanks
-- PMM



Re: [PATCH v3 15/33] docs/system: Convert qemu-cpu-models.texi to rST

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> From: Kashyap Chamarthy 
>
> This doc was originally written by Daniel P. Berrangé
> , introduced via commit[1]: 2544e9e4aa (docs: add
> guidance on configuring CPU models for x86, 2018-06-27).
>
> In this patch:
>
>   - 1-1 conversion of Texinfo to rST, besides a couple of minor
> tweaks that are too trivial to mention.   (Thanks to Stephen
> Finucane on IRC for the suggestion to use rST "definition lists"
> instead of bullets in some places.)
>
> Further modifications will be done via a separate patch.
>
>   - rST and related infra changes: manual page generation, Makefile
> fixes, clean up references to qemu-cpu-models.texi, update year in
> the copyright notice, etc.
>
> [1] https://git.qemu.org/?p=qemu.git;a=commit;h=2544e9e4aa
>
> As part of the conversion, we use a more generic 'author' attribution
> for the manpage than we previously had, as agreed with the original
> author Dan Berrange.
>
> Signed-off-by: Kashyap Chamarthy 
> Signed-off-by: Paolo Bonzini 
> Message-id: 20200226113034.6741-15-pbonz...@redhat.com
> [Move macros to defs.rst.inc, split in x86 and MIPS parts,
>  make qemu-cpu-models.rst a standalone document. - Paolo]
> Signed-off-by: Paolo Bonzini 
> [PMM: Move defs.rst.inc setup to its own commit;
>  fix minor issues with MAINTAINERS file updates;
>  drop copyright date change; keep capitalization of
>  "QEMU Project developers" consistent with other uses;
>  minor Makefile fixups]
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

> ---
>  Makefile|   8 +-
>  MAINTAINERS |   2 +
>  docs/system/conf.py |   6 +-
>  docs/system/cpu-models-mips.rst.inc | 105 
>  docs/system/cpu-models-x86.rst.inc  | 365 
>  docs/system/qemu-cpu-models.rst |  20 ++
>  docs/system/qemu-cpu-models.texi|  28 ---
>  7 files changed, 500 insertions(+), 34 deletions(-)
>  create mode 100644 docs/system/cpu-models-mips.rst.inc
>  create mode 100644 docs/system/cpu-models-x86.rst.inc
>  create mode 100644 docs/system/qemu-cpu-models.rst
>  delete mode 100644 docs/system/qemu-cpu-models.texi
>
> diff --git a/Makefile b/Makefile
> index 26bbd334438..f8642cd28a1 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -354,7 +354,7 @@ endif
>  DOCS+=$(MANUAL_BUILDDIR)/system/qemu-block-drivers.7
>  DOCS+=docs/interop/qemu-qmp-ref.html docs/interop/qemu-qmp-ref.txt 
> docs/interop/qemu-qmp-ref.7
>  DOCS+=docs/interop/qemu-ga-ref.html docs/interop/qemu-ga-ref.txt 
> docs/interop/qemu-ga-ref.7
> -DOCS+=docs/system/qemu-cpu-models.7
> +DOCS+=$(MANUAL_BUILDDIR)/system/qemu-cpu-models.7
>  DOCS+=$(MANUAL_BUILDDIR)/index.html
>  ifdef CONFIG_VIRTFS
>  DOCS+=$(MANUAL_BUILDDIR)/tools/virtfs-proxy-helper.1
> @@ -780,7 +780,6 @@ distclean: clean
>   rm -f docs/interop/qemu-qmp-ref.txt docs/interop/qemu-ga-ref.txt
>   rm -f docs/interop/qemu-qmp-ref.pdf docs/interop/qemu-ga-ref.pdf
>   rm -f docs/interop/qemu-qmp-ref.html docs/interop/qemu-ga-ref.html
> - rm -f docs/system/qemu-cpu-models.7
>   rm -rf .doctrees
>   $(call clean-manual,devel)
>   $(call clean-manual,interop)
> @@ -861,7 +860,7 @@ ifdef CONFIG_POSIX
>   $(INSTALL_DIR) "$(DESTDIR)$(mandir)/man7"
>   $(INSTALL_DATA) docs/interop/qemu-qmp-ref.7 "$(DESTDIR)$(mandir)/man7"
>   $(INSTALL_DATA) $(MANUAL_BUILDDIR)/system/qemu-block-drivers.7 
> "$(DESTDIR)$(mandir)/man7"
> - $(INSTALL_DATA) docs/system/qemu-cpu-models.7 "$(DESTDIR)$(mandir)/man7"
> + $(INSTALL_DATA) $(MANUAL_BUILDDIR)/system/qemu-cpu-models.7 
> "$(DESTDIR)$(mandir)/man7"
>  ifeq ($(CONFIG_TOOLS),y)
>   $(INSTALL_DATA) $(MANUAL_BUILDDIR)/tools/qemu-img.1 
> "$(DESTDIR)$(mandir)/man1"
>   $(INSTALL_DIR) "$(DESTDIR)$(mandir)/man8"
> @@ -1083,7 +1082,7 @@ $(MANUAL_BUILDDIR)/user/index.html: $(call 
> manual-deps,user)
>  
>  $(call define-manpage-rule,interop,qemu-ga.8)
>  
> -$(call define-manpage-rule,system,qemu-block-drivers.7)
> +$(call define-manpage-rule,system,qemu-block-drivers.7 qemu-cpu-models.7)
>  
>  $(call define-manpage-rule,tools,\
> qemu-img.1 qemu-nbd.8 qemu-trace-stap.1\
> @@ -1112,7 +,6 @@ docs/interop/qemu-ga-qapi.texi: 
> qga/qapi-generated/qga-qapi-doc.texi
>  
>  qemu.1: qemu-doc.texi qemu-options.texi qemu-monitor.texi 
> qemu-monitor-info.texi
>  qemu.1: docs/system/qemu-option-trace.texi
> -docs/system/qemu-cpu-models.7: docs/system/qemu-cpu-models.texi 
> docs/system/cpu-models-x86.texi docs/system/cpu-models-mips.texi
>  
>  html: qemu-doc.html docs/interop/qemu-qmp-ref.html 
> docs/interop/qemu-ga-ref.html sphinxdocs
>  info: qemu-doc.info docs/interop/qemu-qmp-ref.info 
> docs/interop/qemu-ga-ref.info
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 74b025fb806..1712eb90851 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -216,6 +216,7 @@ F: target/mips/
>  F: default-configs/*mips*
>  F: disas/*mips*
>  F: docs/system/cpu-models-mips.texi
> +F:

Re: [PATCH 4/8] target/arm: Move helper_dc_zva to helper-a64.c

2020-03-02 Thread Peter Maydell
On Tue, 25 Feb 2020 at 03:14, Richard Henderson
 wrote:
>
> This is an aarch64-only function.  Move it out of the shared file.
> This patch is code movement only.
>
> Signed-off-by: Richard Henderson 

Reviewed-by: Peter Maydell 

thanks
-- PMM



Re: [PATCH v3 16/33] docs/system: Convert security.texi to rST format

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> security.texi is included from qemu-doc.texi but is not used
> in the qemu.1 manpage. So we can do a straightforward conversion
> of the contents, which go into the system manual.
>
> Signed-off-by: Peter Maydell 
> Signed-off-by: Paolo Bonzini 
> Message-id: 20200226113034.6741-16-pbonz...@redhat.com

Reviewed-by: Alex Bennée 

> ---
>  docs/system/index.rst|   1 +
>  docs/system/security.rst | 173 +++
>  2 files changed, 174 insertions(+)
>  create mode 100644 docs/system/security.rst
>
> diff --git a/docs/system/index.rst b/docs/system/index.rst
> index fc774a18b54..5034f903407 100644
> --- a/docs/system/index.rst
> +++ b/docs/system/index.rst
> @@ -14,4 +14,5 @@ Contents:
>  .. toctree::
> :maxdepth: 2
>  
> +   security
> vfio-ap
> diff --git a/docs/system/security.rst b/docs/system/security.rst
> new file mode 100644
> index 000..f2092c8768b
> --- /dev/null
> +++ b/docs/system/security.rst
> @@ -0,0 +1,173 @@
> +Security
> +
> +
> +Overview
> +
> +
> +This chapter explains the security requirements that QEMU is designed to meet
> +and principles for securely deploying QEMU.
> +
> +Security Requirements
> +-
> +
> +QEMU supports many different use cases, some of which have stricter security
> +requirements than others.  The community has agreed on the overall security
> +requirements that users may depend on.  These requirements define what is
> +considered supported from a security perspective.
> +
> +Virtualization Use Case
> +'''
> +
> +The virtualization use case covers cloud and virtual private server (VPS)
> +hosting, as well as traditional data center and desktop virtualization.  
> These
> +use cases rely on hardware virtualization extensions to execute guest code
> +safely on the physical CPU at close-to-native speed.
> +
> +The following entities are untrusted, meaning that they may be buggy or
> +malicious:
> +
> +- Guest
> +- User-facing interfaces (e.g. VNC, SPICE, WebSocket)
> +- Network protocols (e.g. NBD, live migration)
> +- User-supplied files (e.g. disk images, kernels, device trees)
> +- Passthrough devices (e.g. PCI, USB)
> +
> +Bugs affecting these entities are evaluated on whether they can cause damage 
> in
> +real-world use cases and treated as security bugs if this is the case.
> +
> +Non-virtualization Use Case
> +'''
> +
> +The non-virtualization use case covers emulation using the Tiny Code 
> Generator
> +(TCG).  In principle the TCG and device emulation code used in conjunction 
> with
> +the non-virtualization use case should meet the same security requirements as
> +the virtualization use case.  However, for historical reasons much of the
> +non-virtualization use case code was not written with these security
> +requirements in mind.
> +
> +Bugs affecting the non-virtualization use case are not considered security
> +bugs at this time.  Users with non-virtualization use cases must not rely on
> +QEMU to provide guest isolation or any security guarantees.
> +
> +Architecture
> +
> +
> +This section describes the design principles that ensure the security
> +requirements are met.
> +
> +Guest Isolation
> +'''
> +
> +Guest isolation is the confinement of guest code to the virtual machine.  
> When
> +guest code gains control of execution on the host this is called escaping the
> +virtual machine.  Isolation also includes resource limits such as throttling 
> of
> +CPU, memory, disk, or network.  Guests must be unable to exceed their 
> resource
> +limits.
> +
> +QEMU presents an attack surface to the guest in the form of emulated devices.
> +The guest must not be able to gain control of QEMU.  Bugs in emulated devices
> +could allow malicious guests to gain code execution in QEMU.  At this point 
> the
> +guest has escaped the virtual machine and is able to act in the context of 
> the
> +QEMU process on the host.
> +
> +Guests often interact with other guests and share resources with them.  A
> +malicious guest must not gain control of other guests or access their data.
> +Disk image files and network traffic must be protected from other guests 
> unless
> +explicitly shared between them by the user.
> +
> +Principle of Least Privilege
> +
> +
> +The principle of least privilege states that each component only has access 
> to
> +the privileges necessary for its function.  In the case of QEMU this means 
> that
> +each process only has access to resources belonging to the guest.
> +
> +The QEMU process should not have access to any resources that are 
> inaccessible
> +to the guest.  This way the guest does not gain anything by escaping into the
> +QEMU process since it already has access to those same resources from within
> +the guest.
> +
> +Following the principle of least privilege immediately fulfills guest 
> isolation
> +requirements.  For example, g

Re: [PATCH 5/8] target/arm: Use DEF_HELPER_FLAGS for helper_dc_zva

2020-03-02 Thread Peter Maydell
On Tue, 25 Feb 2020 at 03:14, Richard Henderson
 wrote:
>
> The function does not write registers, and only reads them by
> implication via the exception path.
>
> Signed-off-by: Richard Henderson 
> ---
>  target/arm/helper-a64.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/arm/helper-a64.h b/target/arm/helper-a64.h
> index b1a5935f61..3df7c185aa 100644
> --- a/target/arm/helper-a64.h
> +++ b/target/arm/helper-a64.h
> @@ -90,7 +90,7 @@ DEF_HELPER_2(advsimd_f16touinth, i32, f16, ptr)
>  DEF_HELPER_2(sqrt_f16, f16, f16, ptr)
>
>  DEF_HELPER_2(exception_return, void, env, i64)
> -DEF_HELPER_2(dc_zva, void, env, i64)
> +DEF_HELPER_FLAGS_2(dc_zva, TCG_CALL_NO_WG, void, env, i64)
>
>  DEF_HELPER_FLAGS_3(pacia, TCG_CALL_NO_WG, i64, env, i64, i64)
>  DEF_HELPER_FLAGS_3(pacib, TCG_CALL_NO_WG, i64, env, i64, i64)
> --

Reviewed-by: Peter Maydell 

thanks
-- PMM



Re: [PATCH v3 17/33] docs/system: convert managed startup to rST.

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> Fix one typo in the process and format more option and
> command names as literal text, but make no significant
> changes to the content.
>
> Signed-off-by: Peter Maydell 
> Signed-off-by: Paolo Bonzini 
> Message-id: 20200226113034.6741-17-pbonz...@redhat.com

Reviewed-by: Alex Bennée 

> ---
>  docs/system/index.rst   |  2 +-
>  docs/system/managed-startup.rst | 35 +
>  2 files changed, 36 insertions(+), 1 deletion(-)
>  create mode 100644 docs/system/managed-startup.rst
>
> diff --git a/docs/system/index.rst b/docs/system/index.rst
> index 5034f903407..d655344fffd 100644
> --- a/docs/system/index.rst
> +++ b/docs/system/index.rst
> @@ -13,6 +13,6 @@ Contents:
>  
>  .. toctree::
> :maxdepth: 2
> -
> +   managed-startup
> security
> vfio-ap
> diff --git a/docs/system/managed-startup.rst b/docs/system/managed-startup.rst
> new file mode 100644
> index 000..9bcf98ea790
> --- /dev/null
> +++ b/docs/system/managed-startup.rst
> @@ -0,0 +1,35 @@
> +Managed start up options
> +
> +
> +In system mode emulation, it's possible to create a VM in a paused
> +state using the ``-S`` command line option. In this state the machine
> +is completely initialized according to command line options and ready
> +to execute VM code but VCPU threads are not executing any code. The VM
> +state in this paused state depends on the way QEMU was started. It
> +could be in:
> +
> +- initial state (after reset/power on state)
> +- with direct kernel loading, the initial state could be amended to execute
> +  code loaded by QEMU in the VM's RAM and with incoming migration
> +- with incoming migration, initial state will be amended with the migrated
> +  machine state after migration completes
> +
> +This paused state is typically used by users to query machine state and/or
> +additionally configure the machine (by hotplugging devices) in runtime before
> +allowing VM code to run.
> +
> +However, at the ``-S`` pause point, it's impossible to configure options
> +that affect initial VM creation (like: ``-smp``/``-m``/``-numa`` ...) or
> +cold plug devices. The experimental ``--preconfig`` command line option
> +allows pausing QEMU before the initial VM creation, in a "preconfig" state,
> +where additional queries and configuration can be performed via QMP
> +before moving on to the resulting configuration startup. In the
> +preconfig state, QEMU only allows a limited set of commands over the
> +QMP monitor, where the commands do not depend on an initialized
> +machine, including but not limited to:
> +
> +- ``qmp_capabilities``
> +- ``query-qmp-schema``
> +- ``query-commands``
> +- ``query-status``
> +- ``x-exit-preconfig``


-- 
Alex Bennée



Re: [PATCH v3 18/33] docs/system: convert the documentation of deprecated features to rST.

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> We put the whole of this document into the system manual, though
> technically a few parts of it apply to qemu-img or qemu-nbd which are
> otherwise documented in tools/.
>
> We only make formatting fixes, except for one use of 'appendix' which
> we change to 'section' because this isn't an appendix in the Sphinx
> manual.
>
> Signed-off-by: Peter Maydell 
> Signed-off-by: Paolo Bonzini 
> Message-id: 20200226113034.6741-18-pbonz...@redhat.com

Reviewed-by: Alex Bennée 

> ---
>  docs/system/deprecated.rst | 446 +
>  docs/system/index.rst  |   1 +
>  2 files changed, 447 insertions(+)
>  create mode 100644 docs/system/deprecated.rst
>
> diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
> new file mode 100644
> index 000..1eaa559079b
> --- /dev/null
> +++ b/docs/system/deprecated.rst
> @@ -0,0 +1,446 @@
> +Deprecated features
> +===
> +
> +In general features are intended to be supported indefinitely once
> +introduced into QEMU. In the event that a feature needs to be removed,
> +it will be listed in this section. The feature will remain functional
> +for 2 releases prior to actual removal. Deprecated features may also
> +generate warnings on the console when QEMU starts up, or if activated
> +via a monitor command, however, this is not a mandatory requirement.
> +
> +Prior to the 2.10.0 release there was no official policy on how
> +long features would be deprecated prior to their removal, nor
> +any documented list of which features were deprecated. Thus
> +any features deprecated prior to 2.10.0 will be treated as if
> +they were first deprecated in the 2.10.0 release.
> +
> +What follows is a list of all features currently marked as
> +deprecated.
> +
> +System emulator command line arguments
> +--
> +
> +``-machine enforce-config-section=on|off`` (since 3.1)
> +''
> +
> +The ``enforce-config-section`` parameter is replaced by the
> +``-global migration.send-configuration={on|off}`` option.
> +
> +``-no-kvm`` (since 1.3.0)
> +'
> +
> +The ``-no-kvm`` argument is now a synonym for setting ``-accel tcg``.
> +
> +``-usbdevice`` (since 2.10.0)
> +'
> +
> +The ``-usbdevice DEV`` argument is now a synonym for setting
> +the ``-device usb-DEV`` argument instead. The deprecated syntax
> +would automatically enable USB support on the machine type.
> +If using the new syntax, USB support must be explicitly
> +enabled via the ``-machine usb=on`` argument.
> +
> +``-drive file=json:{...{'driver':'file'}}`` (since 3.0)
> +'''
> +
> +The 'file' driver for drives is no longer appropriate for character or host
> +devices and will only accept regular files (S_IFREG). The correct driver
> +for these file types is 'host_cdrom' or 'host_device' as appropriate.
> +
> +``-net ...,name=``\ *name* (since 3.1)
> +''
> +
> +The ``name`` parameter of the ``-net`` option is a synonym
> +for the ``id`` parameter, which should now be used instead.
> +
> +``-smp`` (invalid topologies) (since 3.1)
> +'
> +
> +CPU topology properties should describe whole machine topology including
> +possible CPUs.
> +
> +However, historically it was possible to start QEMU with an incorrect 
> topology
> +where *n* <= *sockets* * *cores* * *threads* < *maxcpus*,
> +which could lead to an incorrect topology enumeration by the guest.
> +Support for invalid topologies will be removed, the user must ensure
> +topologies described with -smp include all possible cpus, i.e.
> +*sockets* * *cores* * *threads* = *maxcpus*.
> +
> +``-vnc acl`` (since 4.0.0)
> +''
> +
> +The ``acl`` option to the ``-vnc`` argument has been replaced
> +by the ``tls-authz`` and ``sasl-authz`` options.
> +
> +``QEMU_AUDIO_`` environment variables and ``-audio-help`` (since 4.0)
> +'
> +
> +The ``-audiodev`` argument is now the preferred way to specify audio
> +backend settings instead of environment variables.  To ease migration to
> +the new format, the ``-audiodev-help`` option can be used to convert
> +the current values of the environment variables to ``-audiodev`` options.
> +
> +Creating sound card devices and vnc without ``audiodev=`` property (since 
> 4.2)
> +''
> +
> +When not using the deprecated legacy audio config, each sound card
> +should specify an ``audiodev=`` property.  Additionally, when using
> +vnc, you should specify an ``audiodev=`` propery if you plan to
> +transmit audio through the VNC protocol.
> +
> +``-mon ...,control=readline,pretty=on|off`` (since 4.1)
> +'''
> 

Re: [PATCH v3 19/33] docs/system: convert Texinfo documentation to rST

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:


>
> Signed-off-by: Paolo Bonzini 
> Message-id: 20200226113034.6741-19-pbonz...@redhat.com
> [PMM: Fixed target-arm.rst use of :math:; remove out of date
>  note about images.rst from commit message; fixed expansion
>  of |qemu_system_x86|; use parsed-literal in invocation.rst
>  when we want to use |qemu_system_x86|; fix incorrect subsection
>  level for "OS requirements" in target-i386.rst; fix incorrect
>  syntax for making links to other sections of the manual]
> Reviewed-by: Peter Maydell 
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée



Re: [PATCH v3 2/6] hw/arm/virt: Introduce VirtGICType enum type

2020-03-02 Thread Andrew Jones
On Mon, Mar 02, 2020 at 11:55:12AM +0100, Eric Auger wrote:
> We plan to introduce yet another value for the gic version (nosel).
> As we already use exotic values such as 0 and -1, let's introduce
> a dedicated enum type and let vms->gic_version take this
> type.
> 
> Signed-off-by: Eric Auger 
> 
> ---
> 
> v2 -> v3:
> - replaced defines by enum VirtGICType
> - use that new type for vms->gic_version
> ---
>  hw/arm/virt.c | 30 +++---
>  include/hw/arm/virt.h | 11 +--
>  2 files changed, 24 insertions(+), 17 deletions(-)
>

Reviewed-by: Andrew Jones 




Re: [PATCH v3 20/33] hmp-commands.hx: Add rST documentation fragments

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> Add the rST versions of the documentation fragments.  Once we've
> converted fully from Texinfo to rST we can remove the ETEXI
> fragments; for the moment we need both.
>
> Since the only consumer of the hmp-commands hxtool documentation
> is the HTML manual, all we need to do for the monitor command
> documentation to appear in the Sphinx system manual is add the
> one line that invokes the hxtool extension on the .hx file.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

> ---
>  Makefile|   2 +-
>  docs/system/monitor.rst |  10 +-
>  hmp-commands.hx | 688 
>  3 files changed, 698 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index f8642cd28a1..22427376b48 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1071,7 +1071,7 @@ $(MANUAL_BUILDDIR)/interop/index.html: $(call 
> manual-deps,interop)
>  $(MANUAL_BUILDDIR)/specs/index.html: $(call manual-deps,specs)
>   $(call build-manual,specs,html)
>  
> -$(MANUAL_BUILDDIR)/system/index.html: $(call manual-deps,system)
> +$(MANUAL_BUILDDIR)/system/index.html: $(call manual-deps,system) 
> $(SRC_PATH)/hmp-commands.hx
>   $(call build-manual,system,html)
>  
>  $(MANUAL_BUILDDIR)/tools/index.html: $(call manual-deps,tools) 
> $(SRC_PATH)/qemu-img-cmds.hx $(SRC_PATH)/docs/qemu-option-trace.rst.inc
> diff --git a/docs/system/monitor.rst b/docs/system/monitor.rst
> index 482f391f327..52b0f18cfec 100644
> --- a/docs/system/monitor.rst
> +++ b/docs/system/monitor.rst
> @@ -14,8 +14,16 @@ You can use it to:
>  
>  -  Inspect the VM state without an external debugger.
>  
> +Commands
> +
> +
> +The following commands are available:
> +
> +.. hxtool-doc:: hmp-commands.hx
> +
>  ..
> -  The commands section goes here once it's converted from Texinfo to RST.
> +  TODO: convert and reference hmp-commands-info.hx
> +
>  
>  Integer expressions
>  ~~~
> diff --git a/hmp-commands.hx b/hmp-commands.hx
> index dc23185de43..9aa59f52312 100644
> --- a/hmp-commands.hx
> +++ b/hmp-commands.hx
> @@ -23,6 +23,10 @@ STEXI
>  @findex help
>  Show the help for all commands or just for command @var{cmd}.
>  ETEXI
> +SRST
> +``help`` or ``?`` [*cmd*]
> +  Show the help for all commands or just for command *cmd*.
> +ERST
>  
>  {
>  .name   = "commit",
> @@ -42,6 +46,16 @@ the backing file, the backing file will not be truncated.  
> If you want the
>  backing file to match the size of the smaller snapshot, you can safely 
> truncate
>  it yourself once the commit operation successfully completes.
>  ETEXI
> +SRST
> +``commit``
> +  Commit changes to the disk images (if -snapshot is used) or backing files.
> +  If the backing file is smaller than the snapshot, then the backing file
> +  will be resized to be the same size as the snapshot.  If the snapshot is
> +  smaller than the backing file, the backing file will not be truncated.
> +  If you want the backing file to match the size of the smaller snapshot,
> +  you can safely truncate it yourself once the commit operation successfully
> +  completes.
> +ERST
>  
>  {
>  .name   = "q|quit",
> @@ -56,6 +70,10 @@ STEXI
>  @findex quit
>  Quit the emulator.
>  ETEXI
> +SRST
> +``q`` or ``quit``
> +  Quit the emulator.
> +ERST
>  
>  {
>  .name   = "exit_preconfig",
> @@ -75,6 +93,14 @@ and via the QMP monitor during the preconfig state. The 
> command is only
>  available during the preconfig state (i.e. when the --preconfig command
>  line option was in use).
>  ETEXI
> +SRST
> +``exit_preconfig``
> +  This command makes QEMU exit the preconfig state and proceed with
> +  VM initialization using configuration data provided on the command line
> +  and via the QMP monitor during the preconfig state. The command is only
> +  available during the preconfig state (i.e. when the --preconfig command
> +  line option was in use).
> +ERST
>  
>  {
>  .name   = "block_resize",
> @@ -92,6 +118,13 @@ action to see the updated size.  Resize to a lower size 
> is supported,
>  but should be used with extreme caution.  Note that this command only
>  resizes image files, it can not resize block devices like LVM volumes.
>  ETEXI
> +SRST
> +``block_resize``
> +  Resize a block image while a guest is running.  Usually requires guest
> +  action to see the updated size.  Resize to a lower size is supported,
> +  but should be used with extreme caution.  Note that this command only
> +  resizes image files, it can not resize block devices like LVM volumes.
> +ERST
>  
>  {
>  .name   = "block_stream",
> @@ -106,6 +139,10 @@ STEXI
>  @findex block_stream
>  Copy data from a backing file into a block device.
>  ETEXI
> +SRST
> +``block_stream``
> +  Copy data from a backing file into a block device.
> +ERST
>  
>  {
>  .name   = "block_job_set_speed",
> @@ -120,6 +157,10 @@ STEXI
>  @findex block_job_set_speed
>  

Re: [PATCH v3 21/33] hmp-commands-info.hx: Add rST documentation fragments

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> Add the rST versions of the documentation fragments.  Once we've
> converted fully from Texinfo to rST we can remove the ETEXI
> fragments; for the moment we need both.
>
> Note that most of the SRST fragments are 2-space indented so that the
> 'info foo' documentation entries appear as a sublist under the 'info'
> entry in the top level list.
>
> Again, all we need to do to put the documentation in the Sphinx manual
> is a one-line hxtool-doc invocation.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

> ---
>  Makefile|   2 +-
>  docs/system/monitor.rst |   4 +-
>  hmp-commands-info.hx| 271 
>  3 files changed, 273 insertions(+), 4 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 22427376b48..98ef06ab8e8 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1071,7 +1071,7 @@ $(MANUAL_BUILDDIR)/interop/index.html: $(call 
> manual-deps,interop)
>  $(MANUAL_BUILDDIR)/specs/index.html: $(call manual-deps,specs)
>   $(call build-manual,specs,html)
>  
> -$(MANUAL_BUILDDIR)/system/index.html: $(call manual-deps,system) 
> $(SRC_PATH)/hmp-commands.hx
> +$(MANUAL_BUILDDIR)/system/index.html: $(call manual-deps,system) 
> $(SRC_PATH)/hmp-commands.hx $(SRC_PATH)/hmp-commands-info.hx
>   $(call build-manual,system,html)
>  
>  $(MANUAL_BUILDDIR)/tools/index.html: $(call manual-deps,tools) 
> $(SRC_PATH)/qemu-img-cmds.hx $(SRC_PATH)/docs/qemu-option-trace.rst.inc
> diff --git a/docs/system/monitor.rst b/docs/system/monitor.rst
> index 52b0f18cfec..0bcd5da2164 100644
> --- a/docs/system/monitor.rst
> +++ b/docs/system/monitor.rst
> @@ -21,9 +21,7 @@ The following commands are available:
>  
>  .. hxtool-doc:: hmp-commands.hx
>  
> -..
> -  TODO: convert and reference hmp-commands-info.hx
> -
> +.. hxtool-doc:: hmp-commands-info.hx
>  
>  Integer expressions
>  ~~~
> diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
> index 257ee7d7a3f..1730f866cde 100644
> --- a/hmp-commands-info.hx
> +++ b/hmp-commands-info.hx
> @@ -4,6 +4,12 @@ HXCOMM discarded from C version
>  HXCOMM DEF(command, args, callback, arg_string, help) is used to construct
>  HXCOMM monitor info commands
>  HXCOMM HXCOMM can be used for comments, discarded from both texi and C
> +HXCOMM
> +HXCOMM In this file, generally SRST fragments should have two extra
> +HXCOMM spaces of indent, so that the documentation list item for "info foo"
> +HXCOMM appears inside the documentation list item for the top level
> +HXCOMM "info" documentation entry. The exception is the first SRST
> +HXCOMM fragment that defines that top level entry.
>  
>  STEXI
>  @table @option
> @@ -12,6 +18,11 @@ STEXI
>  Show various information about the system state.
>  @table @option
>  ETEXI
> +SRST
> +``info`` *subcommand*
> +  Show various information about the system state.
> +
> +ERST
>  
>  {
>  .name   = "version",
> @@ -27,6 +38,10 @@ STEXI
>  @findex info version
>  Show the version of QEMU.
>  ETEXI
> +SRST
> +  ``info version``
> +Show the version of QEMU.
> +ERST
>  
>  {
>  .name   = "network",
> @@ -41,6 +56,10 @@ STEXI
>  @findex info network
>  Show the network state.
>  ETEXI
> +SRST
> +  ``info network``
> +Show the network state.
> +ERST
>  
>  {
>  .name   = "chardev",
> @@ -56,6 +75,10 @@ STEXI
>  @findex info chardev
>  Show the character devices.
>  ETEXI
> +SRST
> +  ``info chardev``
> +Show the character devices.
> +ERST
>  
>  {
>  .name   = "block",
> @@ -71,6 +94,10 @@ STEXI
>  @findex info block
>  Show info of one block device or all block devices.
>  ETEXI
> +SRST
> +  ``info block``
> +Show info of one block device or all block devices.
> +ERST
>  
>  {
>  .name   = "blockstats",
> @@ -85,6 +112,10 @@ STEXI
>  @findex info blockstats
>  Show block device statistics.
>  ETEXI
> +SRST
> +  ``info blockstats``
> +Show block device statistics.
> +ERST
>  
>  {
>  .name   = "block-jobs",
> @@ -99,6 +130,10 @@ STEXI
>  @findex info block-jobs
>  Show progress of ongoing block device operations.
>  ETEXI
> +SRST
> +  ``info block-jobs``
> +Show progress of ongoing block device operations.
> +ERST
>  
>  {
>  .name   = "registers",
> @@ -113,6 +148,10 @@ STEXI
>  @findex info registers
>  Show the cpu registers.
>  ETEXI
> +SRST
> +  ``info registers``
> +Show the cpu registers.
> +ERST
>  
>  #if defined(TARGET_I386)
>  {
> @@ -130,6 +169,10 @@ STEXI
>  @findex info lapic
>  Show local APIC state
>  ETEXI
> +SRST
> +  ``info lapic``
> +Show local APIC state
> +ERST
>  
>  #if defined(TARGET_I386)
>  {
> @@ -146,6 +189,10 @@ STEXI
>  @findex info ioapic
>  Show io APIC state
>  ETEXI
> +SRST
> +  ``info ioapic``
> +Show io APIC state
> +ERST
>  
>  {
>  .name   = "cpus",
> @@ -160,6 +207,10 @@ STEXI
>  @findex info cpus
>  Show infos for each CPU.
>  ETEXI
> +S

Re: [PATCH v3 05/33] qemu-doc: split qemu-doc.texi in multiple files

2020-03-02 Thread Peter Maydell
On Mon, 2 Mar 2020 at 11:22, Alex Bennée  wrote:
>
>
> Peter Maydell  writes:
>
> > From: Paolo Bonzini 
> >
> > In order to facilitate the reorganization of qemu-doc.texi content,
> > as well as the conversion to rST/Sphinx, split it in multiple .texi
> > files that are included from docs/system.
> >
> > The "other devices" section is renamed to ivshmem and placed last.
> >
> > Signed-off-by: Paolo Bonzini 
> > Message-id: 20200226113034.6741-6-pbonz...@redhat.com
> > Reviewed-by: Peter Maydell 
> > Signed-off-by: Peter Maydell 
> > ---
> >  Makefile |   16 +
> >  docs/system/build-platforms.texi |   67 ++
> >  docs/system/gdb.texi |   71 ++
>
> The gdb test would be better served in docs/core if we could have
> optional sections on invocation rendering depending on if it's built
> with system emulation or linux-user docs. Is that something that's
> already supported?

No, for three reasons:

(1) we build all the docs, always -- there's no concept
of "skip some bits of docs if some configure feature was
disabled"

(2) there is no docs/core -- the subdirectories of docs/
correspond to the "manuals" which we want to present to
the user, like "Manual for system emulation users" and
"Manual for user-mode users" and "Manual for the
standalone tools"; a "core" manual wouldn't fit into this
classification, and we already have slightly more manuals
than I'm entirely comfortable with.

(3) Sphinx's support for conditional documentation is
not very good, as it is implemented at the "wrong"
end of the pipeline (ie it's not like a preprocessor
ifdef, but instead is just "suppress the output", so
manual pieces inside a disabled ifdef still turn up
in places like the index and table of contents). The
best you can do is to mess around with the include
directive, but if we do that too much then things get
awkward to understand and maintain. (We do it a bit
in this series to handle "manpage vs manual" stuff.)

thanks
-- PMM



Re: [PATCH v3 22/33] doc/scripts/hxtool.py: Strip trailing ':' from DEFHEADING/ARCHHEADING

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> In hxtool files, section headings defined with the DEFHEADING
> and ARCHHEADING macros have a trailing ':'
>   DEFHEADING(Standard options:)
>
> This is for the benefit of the --help output. For consistency
> with the rest of the rST documentation, strip any trailing ':'
> when we construct headings with the Sphinx hxtool extension.
> This makes the table of contents look neater.
>
> This only affects generation of documentation from qemu-options.hx,
> which we will start doing in a later commit.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

> ---
>  docs/sphinx/hxtool.py | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/docs/sphinx/hxtool.py b/docs/sphinx/hxtool.py
> index 5d6736f3002..7dd223fe362 100644
> --- a/docs/sphinx/hxtool.py
> +++ b/docs/sphinx/hxtool.py
> @@ -60,8 +60,9 @@ def parse_defheading(file, lnum, line):
>  # empty we ignore the directive -- these are used only to add
>  # blank lines in the plain-text content of the --help output.
>  #
> -# Return the heading text
> -match = re.match(r'DEFHEADING\((.*)\)', line)
> +# Return the heading text. We strip out any trailing ':' for
> +# consistency with other headings in the rST documentation.
> +match = re.match(r'DEFHEADING\((.*?):?\)', line)
>  if match is None:
>  serror(file, lnum, "Invalid DEFHEADING line")
>  return match.group(1)
> @@ -72,8 +73,9 @@ def parse_archheading(file, lnum, line):
>  # though note that the 'some string' could be the empty string.
>  # As with DEFHEADING, empty string ARCHHEADINGs will be ignored.
>  #
> -# Return the heading text
> -match = re.match(r'ARCHHEADING\((.*),.*\)', line)
> +# Return the heading text. We strip out any trailing ':' for
> +# consistency with other headings in the rST documentation.
> +match = re.match(r'ARCHHEADING\((.*?):?,.*\)', line)
>  if match is None:
>  serror(file, lnum, "Invalid ARCHHEADING line")
>  return match.group(1)


-- 
Alex Bennée



Re: [PATCH v3 24/33] docs: Roll -prom-env and -g target-specific info into qemu-options.hx

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> The SPARC and PPC targets currently have a fragment of target-specific
> information about the -g and -prom options which would be better placed
> as part of the general documentation of those options in qemu-options.hx.
> Move the relevant information to those locations.
>
> SPARC also has a bit of text about the -M option which is out of
> date and provides no useful information over the generic documentation
> of that option, so just delete it.
>
> The motivation here is again to avoid having to awkwardly include
> this text into the rST version of the qemu.1 manpage.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

> ---
>  docs/system/target-ppc.rst  | 14 --
>  docs/system/target-ppc.texi | 25 -
>  docs/system/target-sparc.rst| 19 ---
>  docs/system/target-sparc.texi   | 27 ---
>  docs/system/target-sparc64.rst  | 12 
>  docs/system/target-sparc64.texi | 22 --
>  qemu-options.hx | 19 +++
>  7 files changed, 19 insertions(+), 119 deletions(-)
>
> diff --git a/docs/system/target-ppc.rst b/docs/system/target-ppc.rst
> index 43fadf3c00b..a2f04c533c2 100644
> --- a/docs/system/target-ppc.rst
> +++ b/docs/system/target-ppc.rst
> @@ -43,19 +43,5 @@ the g3beige and mac99 PowerMac and the 40p machines. 
> OpenBIOS is a free
>  (GPL v2) portable firmware implementation. The goal is to implement a
>  100% IEEE 1275-1994 (referred to as Open Firmware) compliant firmware.
>  
> -The following options are specific to the PowerPC emulation:
> -
> -``-g WxH[xDEPTH]``
> -   Set the initial VGA graphic mode. The default is 800x600x32.
> -
> -``-prom-env string``
> -   Set OpenBIOS variables in NVRAM, for example:
> -
> -   ::
> -
> -  qemu-system-ppc -prom-env 'auto-boot?=false' \
> -   -prom-env 'boot-device=hd:2,\yaboot' \
> -   -prom-env 'boot-args=conf=hd:2,\yaboot.conf'
> -
>  More information is available at
>  http://perso.magic.fr/l_indien/qemu-ppc/.
> diff --git a/docs/system/target-ppc.texi b/docs/system/target-ppc.texi
> index 55f98f65b12..5c83d4f68e7 100644
> --- a/docs/system/target-ppc.texi
> +++ b/docs/system/target-ppc.texi
> @@ -47,31 +47,6 @@ for the g3beige and mac99 PowerMac and the 40p machines. 
> OpenBIOS is a free
>  (GPL v2) portable firmware implementation. The goal is to implement a 100%
>  IEEE 1275-1994 (referred to as Open Firmware) compliant firmware.
>  
> -@c man begin OPTIONS
> -
> -The following options are specific to the PowerPC emulation:
> -
> -@table @option
> -
> -@item -g @var{W}x@var{H}[x@var{DEPTH}]
> -
> -Set the initial VGA graphic mode. The default is 800x600x32.
> -
> -@item -prom-env @var{string}
> -
> -Set OpenBIOS variables in NVRAM, for example:
> -
> -@example
> -qemu-system-ppc -prom-env 'auto-boot?=false' \
> - -prom-env 'boot-device=hd:2,\yaboot' \
> - -prom-env 'boot-args=conf=hd:2,\yaboot.conf'
> -@end example
> -
> -@end table
> -
> -@c man end
> -
> -
>  More information is available at
>  @url{http://perso.magic.fr/l_indien/qemu-ppc/}.
>  
> diff --git a/docs/system/target-sparc.rst b/docs/system/target-sparc.rst
> index 589c88d1756..b55f8d09e9c 100644
> --- a/docs/system/target-sparc.rst
> +++ b/docs/system/target-sparc.rst
> @@ -60,22 +60,3 @@ QEMU web site. There are still issues with NetBSD and 
> OpenBSD, but most
>  kernel versions work. Please note that currently older Solaris kernels
>  don't work probably due to interface issues between OpenBIOS and
>  Solaris.
> -
> -The following options are specific to the Sparc32 emulation:
> -
> -``-g WxHx[xDEPTH]``
> -   Set the initial graphics mode. For TCX, the default is 1024x768x8
> -   with the option of 1024x768x24. For cgthree, the default is
> -   1024x768x8 with the option of 1152x900x8 for people who wish to use
> -   OBP.
> -
> -``-prom-env string``
> -   Set OpenBIOS variables in NVRAM, for example:
> -
> -   ::
> -
> -  qemu-system-sparc -prom-env 'auto-boot?=false' \
> -   -prom-env 'boot-device=sd(0,2,0):d' -prom-env 'boot-args=linux single'
> -
> -``-M [SS-4|SS-5|SS-10|SS-20|SS-600MP|LX|Voyager|SPARCClassic] [|SPARCbook]``
> -   Set the emulated machine type. Default is SS-5.
> diff --git a/docs/system/target-sparc.texi b/docs/system/target-sparc.texi
> index 7748001f734..99fbf820b42 100644
> --- a/docs/system/target-sparc.texi
> +++ b/docs/system/target-sparc.texi
> @@ -64,32 +64,5 @@ most kernel versions work. Please note that currently 
> older Solaris kernels
>  don't work probably due to interface issues between OpenBIOS and
>  Solaris.
>  
> -@c man begin OPTIONS
> -
> -The following options are specific to the Sparc32 emulation:
> -
> -@table @option
> -
> -@item -g @var{W}x@var{H}x[x@var{DEPTH}]
> -
> -Set the initial graphics mode. For TCX, the default is 1024x768x8 with the
> -option of 1024x768x24. For cgthree, the default is 1024x768x8 with the option
> -of 1152x900x8 for p

Re: [PATCH v3 23/33] docs: Roll semihosting option information into qemu-options.hx

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> Currently the per-target documentation for those targets that
> implement semihosting includes a bit of text that goes into both the
> manual and the manpage about options specific to the target.  This
> text is redundant with the earlier generic option description of the
> semihosting option produced from qemu-options.hx. To avoid having
> to create a lot of stub include files to include into the rST
> generated qemu.1 manpage, roll target-specific bits of information
> into the qemu-options.hx text, so the user doesn't have to look
> in two places for this information.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

> ---
> Yes, it would in theory make sense to do this before generating
> the rst from the texi docs, but I didn't realize this was a
> good idea until well after Paolo had done that part.
> ---
>  docs/system/target-arm.rst | 10 --
>  docs/system/target-arm.texi| 18 --
>  docs/system/target-m68k.rst| 11 ---
>  docs/system/target-m68k.texi   | 19 ---
>  docs/system/target-xtensa.rst  | 12 
>  docs/system/target-xtensa.texi | 20 
>  qemu-options.hx| 18 ++
>  7 files changed, 18 insertions(+), 90 deletions(-)
>
> diff --git a/docs/system/target-arm.rst b/docs/system/target-arm.rst
> index 0490be55871..d2a3b44ce88 100644
> --- a/docs/system/target-arm.rst
> +++ b/docs/system/target-arm.rst
> @@ -215,13 +215,3 @@ emulation includes the following elements:
>  
>  A Linux 2.6 test image is available on the QEMU web site. More
>  information is available in the QEMU mailing-list archive.
> -
> -The following options are specific to the ARM emulation:
> -
> -``-semihosting``
> -   Enable semihosting syscall emulation.
> -
> -   On ARM this implements the \"Angel\" interface.
> -
> -   Note that this allows guest direct access to the host filesystem, so
> -   should only be used with trusted guest OS.
> diff --git a/docs/system/target-arm.texi b/docs/system/target-arm.texi
> index c56b5f6ebfe..eb80dd35f0b 100644
> --- a/docs/system/target-arm.texi
> +++ b/docs/system/target-arm.texi
> @@ -243,21 +243,3 @@ Three on-chip UARTs
>  A Linux 2.6 test image is available on the QEMU web site. More
>  information is available in the QEMU mailing-list archive.
>  
> -@c man begin OPTIONS
> -
> -The following options are specific to the ARM emulation:
> -
> -@table @option
> -
> -@item -semihosting
> -Enable semihosting syscall emulation.
> -
> -On ARM this implements the "Angel" interface.
> -
> -Note that this allows guest direct access to the host filesystem,
> -so should only be used with trusted guest OS.
> -
> -@end table
> -
> -@c man end
> -
> diff --git a/docs/system/target-m68k.rst b/docs/system/target-m68k.rst
> index 50b7dd9d639..d28d3b92e5e 100644
> --- a/docs/system/target-m68k.rst
> +++ b/docs/system/target-m68k.rst
> @@ -19,14 +19,3 @@ The AN5206 emulation includes the following devices:
>  -  MCF5206 ColdFire V2 Microprocessor.
>  
>  -  Two on-chip UARTs.
> -
> -The following options are specific to the ColdFire emulation:
> -
> -``-semihosting``
> -   Enable semihosting syscall emulation.
> -
> -   On M68K this implements the \"ColdFire GDB\" interface used by
> -   libgloss.
> -
> -   Note that this allows guest direct access to the host filesystem, so
> -   should only be used with trusted guest OS.
> diff --git a/docs/system/target-m68k.texi b/docs/system/target-m68k.texi
> index a77b19ea0f1..dcce7bc8c56 100644
> --- a/docs/system/target-m68k.texi
> +++ b/docs/system/target-m68k.texi
> @@ -23,22 +23,3 @@ MCF5206 ColdFire V2 Microprocessor.
>  @item
>  Two on-chip UARTs.
>  @end itemize
> -
> -@c man begin OPTIONS
> -
> -The following options are specific to the ColdFire emulation:
> -
> -@table @option
> -
> -@item -semihosting
> -Enable semihosting syscall emulation.
> -
> -On M68K this implements the "ColdFire GDB" interface used by libgloss.
> -
> -Note that this allows guest direct access to the host filesystem,
> -so should only be used with trusted guest OS.
> -
> -@end table
> -
> -@c man end
> -
> diff --git a/docs/system/target-xtensa.rst b/docs/system/target-xtensa.rst
> index 43cab8dc4da..8d703ad769e 100644
> --- a/docs/system/target-xtensa.rst
> +++ b/docs/system/target-xtensa.rst
> @@ -25,15 +25,3 @@ The Avnet LX60/LX110/LX200 emulation supports:
>  -  16550 UART
>  
>  -  OpenCores 10/100 Mbps Ethernet MAC
> -
> -The following options are specific to the Xtensa emulation:
> -
> -``-semihosting``
> -   Enable semihosting syscall emulation.
> -
> -   Xtensa semihosting provides basic file IO calls, such as
> -   open/read/write/seek/select. Tensilica baremetal libc for ISS and
> -   linux platform \"sim\" use this interface.
> -
> -   Note that this allows guest direct access to the host filesystem, so
> -   should only be used with trusted guest OS.
> diff --git a/docs/system/target-xtensa.texi b/docs/system/target

Re: [PATCH v3 2/6] hw/arm/virt: Introduce VirtGICType enum type

2020-03-02 Thread Auger Eric
Hi Philippe,

On 3/2/20 12:18 PM, Philippe Mathieu-Daudé wrote:
> On 3/2/20 11:55 AM, Eric Auger wrote:
>> We plan to introduce yet another value for the gic version (nosel).
>> As we already use exotic values such as 0 and -1, let's introduce
>> a dedicated enum type and let vms->gic_version take this
>> type.
>>
>> Signed-off-by: Eric Auger 
>>
>> ---
>>
>> v2 -> v3:
>> - replaced defines by enum VirtGICType
>> - use that new type for vms->gic_version
>> ---
>>   hw/arm/virt.c | 30 +++---
>>   include/hw/arm/virt.h | 11 +--
> 
> Please have a look at scripts/git.orderfile, it helps making review
> easier/quicker.
OK I added it to my .git/config. Thanks for pointer
> 
> Reviewed-by: Philippe Mathieu-Daudé 

Thanks!

Eric
> 
>>   2 files changed, 24 insertions(+), 17 deletions(-)
>>
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index c093f0ab85..b449a445de 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -298,7 +298,7 @@ static void fdt_add_timer_nodes(const
>> VirtMachineState *vms)
>>   irqflags = GIC_FDT_IRQ_FLAGS_EDGE_LO_HI;
>>   }
>>   -    if (vms->gic_version == 2) {
>> +    if (vms->gic_version == VIRT_GIC_VERSION_2) {
>>   irqflags = deposit32(irqflags, GIC_FDT_IRQ_PPI_CPU_START,
>>    GIC_FDT_IRQ_PPI_CPU_WIDTH,
>>    (1 << vms->smp_cpus) - 1);
>> @@ -439,7 +439,7 @@ static void fdt_add_gic_node(VirtMachineState *vms)
>>   qemu_fdt_setprop_cell(vms->fdt, nodename, "#address-cells", 0x2);
>>   qemu_fdt_setprop_cell(vms->fdt, nodename, "#size-cells", 0x2);
>>   qemu_fdt_setprop(vms->fdt, nodename, "ranges", NULL, 0);
>> -    if (vms->gic_version == 3) {
>> +    if (vms->gic_version == VIRT_GIC_VERSION_3) {
>>   int nb_redist_regions = virt_gicv3_redist_region_count(vms);
>>     qemu_fdt_setprop_string(vms->fdt, nodename, "compatible",
>> @@ -518,7 +518,7 @@ static void fdt_add_pmu_nodes(const
>> VirtMachineState *vms)
>>   }
>>   }
>>   -    if (vms->gic_version == 2) {
>> +    if (vms->gic_version == VIRT_GIC_VERSION_2) {
>>   irqflags = deposit32(irqflags, GIC_FDT_IRQ_PPI_CPU_START,
>>    GIC_FDT_IRQ_PPI_CPU_WIDTH,
>>    (1 << vms->smp_cpus) - 1);
>> @@ -1469,7 +1469,7 @@ static uint64_t
>> virt_cpu_mp_affinity(VirtMachineState *vms, int idx)
>>    * purposes are to make TCG consistent (with 64-bit KVM hosts)
>>    * and to improve SGI efficiency.
>>    */
>> -    if (vms->gic_version == 3) {
>> +    if (vms->gic_version == VIRT_GIC_VERSION_3) {
>>   clustersz = GICV3_TARGETLIST_BITS;
>>   } else {
>>   clustersz = GIC_TARGETLIST_BITS;
>> @@ -1560,15 +1560,15 @@ static void machvirt_init(MachineState *machine)
>>   /* We can probe only here because during property set
>>    * KVM is not available yet
>>    */
>> -    if (vms->gic_version <= 0) {
>> -    /* "host" or "max" */
>> +    if (vms->gic_version == VIRT_GIC_VERSION_HOST ||
>> +    vms->gic_version == VIRT_GIC_VERSION_MAX) {
>>   if (!kvm_enabled()) {
>> -    if (vms->gic_version == 0) {
>> +    if (vms->gic_version == VIRT_GIC_VERSION_HOST) {
>>   error_report("gic-version=host requires KVM");
>>   exit(1);
>>   } else {
>>   /* "max": currently means 3 for TCG */
>> -    vms->gic_version = 3;
>> +    vms->gic_version = VIRT_GIC_VERSION_3;
>>   }
>>   } else {
>>   vms->gic_version = kvm_arm_vgic_probe();
>> @@ -1627,7 +1627,7 @@ static void machvirt_init(MachineState *machine)
>>   /* The maximum number of CPUs depends on the GIC version, or on how
>>    * many redistributors we can fit into the memory map.
>>    */
>> -    if (vms->gic_version == 3) {
>> +    if (vms->gic_version == VIRT_GIC_VERSION_3) {
>>   virt_max_cpus =
>>   vms->memmap[VIRT_GIC_REDIST].size / GICV3_REDIST_SIZE;
>>   virt_max_cpus +=
>> @@ -1855,7 +1855,7 @@ static void virt_set_its(Object *obj, bool
>> value, Error **errp)
>>   static char *virt_get_gic_version(Object *obj, Error **errp)
>>   {
>>   VirtMachineState *vms = VIRT_MACHINE(obj);
>> -    const char *val = vms->gic_version == 3 ? "3" : "2";
>> +    const char *val = vms->gic_version == VIRT_GIC_VERSION_3 ? "3" :
>> "2";
>>     return g_strdup(val);
>>   }
>> @@ -1865,13 +1865,13 @@ static void virt_set_gic_version(Object *obj,
>> const char *value, Error **errp)
>>   VirtMachineState *vms = VIRT_MACHINE(obj);
>>     if (!strcmp(value, "3")) {
>> -    vms->gic_version = 3;
>> +    vms->gic_version = VIRT_GIC_VERSION_3;
>>   } else if (!strcmp(value, "2")) {
>> -    vms->gic_version = 2;
>> +    vms->gic_version = VIRT_GIC_VERSION_2;
>>   } else if (!strcmp(value, "host")) {
>> -

Re: [PATCH v3 25/33] scripts/hxtool-conv: Archive script used in qemu-options.hx conversion

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> This commit archives the perl script used to do conversion of the
> STEXI/ETEXI blocks in qemu-options.hx. (The other .hx files were
> manually converted, but qemu-options.hx is complicated enough that
> I felt I needed some scripting.)
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

> ---
> Please don't critique the script, it is purely for a one-off
> conversion job, and I then did manual fixups on the output
> to get the changes in the following patch. I merely felt it
> was potentially useful to archive a copy of the mechanism used.
> Or we could drop this patch if that's not needed.
> ---
>  scripts/hxtool-conv.pl | 137 +
>  1 file changed, 137 insertions(+)
>  create mode 100755 scripts/hxtool-conv.pl
>
> diff --git a/scripts/hxtool-conv.pl b/scripts/hxtool-conv.pl
> new file mode 100755
> index 000..eede40b3462
> --- /dev/null
> +++ b/scripts/hxtool-conv.pl
> @@ -0,0 +1,137 @@
> +#!/usr/bin/perl -w
> +#
> +# Script to convert .hx file STEXI/ETEXI blocks to SRST/ERST
> +#
> +# Copyright (C) 2020 Linaro
> +#
> +# This work is licensed under the terms of the GNU GPL, version 2 or
> +# (at your option) any later version. See the COPYING file in the
> +# top-level directory.
> +
> +# This script was only ever intended as a one-off conversion operation.
> +# Please excuse the places where it is a bit hacky.
> +# Some manual intervention after the conversion is expected, as are
> +# some warnings from makeinfo.
> +# Warning: this script is not idempotent: don't try to run it on
> +# a .hx file that already has SRST/ERST sections.
> +
> +# Expected usage:
> +# scripts/hxtool-conv.pl file.hx > file.hx.new
> +
> +use utf8;
> +
> +my $reading_texi = 0;
> +my $texiblock = '';
> +my @tables = ();
> +
> +sub update_tables($) {
> +my ($texi) = @_;
> +# Update our list of open table directives: every @table
> +# line in the texi fragment is added to the list, and every
> +# @end table line means we remove an entry from the list.
> +# If this fragment had a completely self contained table with
> +# both the @table and @end table lines, this will be a no-op.
> +foreach (split(/\n/, $texi)) {
> +push @tables, $_ if /^\@table/;
> +pop @tables if /^\@end table/;
> +}
> +}
> +
> +sub only_table_directives($) {
> +# Return true if every line in the fragment is a start or end table 
> directive
> +my ($texi) = @_;
> +foreach (split(/\n/, $texi)) {
> +return 0 unless /^\@table/ or /^\@end table/;
> +}
> +return 1;
> +}
> +
> +sub output_rstblock($) {
> +# Write the output to /tmp/frag.texi, wrapped in whatever current @table
> +# lines we need.
> +my ($texi) = @_;
> +
> +# As a special case, if this fragment is only table directives and
> +# nothing else, update our set of open table directives but otherwise
> +# ignore it. This avoids emitting an empty SRST/ERST block.
> +if (only_table_directives($texi)) {
> +update_tables($texi);
> +return;
> +}
> +
> +open(my $fragfh, '>', '/tmp/frag.texi');
> +# First output the currently active set of open table directives
> +print $fragfh join("\n", @tables);
> +# Next, update our list of open table directives.
> +# We need to do this before we emit the closing table directives
> +# so that we emit the right number if this fragment had an
> +# unbalanced set of directives.
> +update_tables($texi);
> +# Then emit the texi fragment itself.
> +print $fragfh "\n$texi\n";
> +# Finally, add the necessary closing table directives.
> +print $fragfh "\@end table\n" x scalar @tables;
> +close $fragfh;
> +
> +# Now invoke makeinfo/pandoc on it and slurp the results into a string
> +open(my $fh, '-|', "makeinfo --force -o - --docbook "
> + . "-D 'qemu_system_x86 QEMU_SYSTEM_X86_MACRO' "
> + . "-D 'qemu_system QEMU_SYSTEM_MACRO'  /tmp/frag.texi "
> + . " | pandoc  -f docbook -t rst")
> +or die "can't start makeinfo/pandoc: $!";
> +
> +binmode $fh, ':encoding(utf8)';
> +
> +print "SRST\n";
> +
> +# Slurp the whole thing into a string so we can do multiline
> +# string matches on it.
> +my $rst = do {
> +local $/ = undef;
> +<$fh>;
> +};
> +$rst =~ s/^-  − /-  /gm;
> +$rst =~ s/“/"/gm;
> +$rst =~ s/”/"/gm;
> +$rst =~ s/‘/'/gm;
> +$rst =~ s/’/'/gm;
> +$rst =~ s/QEMU_SYSTEM_MACRO/|qemu_system|/g;
> +$rst =~ s/QEMU_SYSTEM_X86_MACRO/|qemu_system_x86|/g;
> +$rst =~ s/(?=::\n\n +\|qemu)/.. parsed-literal/g;
> +$rst =~ s/:\n\n::$/::/gm;
> +
> +# Fix up the invalid reference format makeinfo/pandoc emit:
> +# `Some string here <#anchorname>`__
> +# should be:
> +# :ref:`anchorname`
> +$rst =~ s/\`[^<`]+\<\#([^>]+)\>\`__/:ref:`$1`/gm;
> +print $rst;
> +
> +close $fh or die "error on close: $!";
> +

Re: [PATCH v3 28/33] docs: Split out sections for the manpage into .rst.inc files

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> Sphinx doesn't have very good facilities for marking chunks
> of documentation as "put this in the manpage only". So instead
> we move the parts we want to put into both the HTML manuals
> and the manpage into their own .rst.inc files, which we can
> include from both the main manual rst files and a new toplevel
> rst file that will be the skeleton of the qemu.1 manpage.
>
> In this commit, just split out the parts of the documentation
> that go in the manpage.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée



Re: [PATCH v3 27/33] qemu-options.hx: Fix up the autogenerated rST

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> This commit contains hand-written fixes for some issues with the
> autogenerated rST fragments in qemu-options.hx:
>
>  * Sphinx complains about the UTF-8 art table in the documentation of
>the -drive option.  Replace it with a proper rST format table.
>
>  * rST does not like definition list entries with no actual
>definition, but it is possible to work around this by putting a
>single escaped literal space as the definition line.
>
>  * The "-g widthxheight" option documentation suffers particularly
>badly from losing the distinction between italics and fixed-width
>as a result of the auto conversion, so put it back in again.
>
>  * The script missed some places that use the |qemu_system| etc
>macros and need to be marked up as parsed-literal blocks.
>
>  * The script autogenerated an expanded out version of the
>contents of qemu-option-trace.texi; replace it with an
>qemu-option-trace.rst.inc include.
>
> This is sufficient that we can enable inclusion of the
> option documentation from invocation.rst.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée



Re: [PATCH v3 29/33] docs: Generate qemu.1 manpage with Sphinx

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> Generate the qemu.1 manpage using Sphinx; we do this with a new
> top-level rst source file which is just the skeleton of the manpage
> and which includes .rst.inc fragments where it needs to incorporate
> sections from the larger HTML manuals.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

> ---
>  Makefile | 10 
>  docs/system/conf.py  |  2 ++
>  docs/system/qemu-manpage.rst | 45 
>  3 files changed, 51 insertions(+), 6 deletions(-)
>  create mode 100644 docs/system/qemu-manpage.rst
>
> diff --git a/Makefile b/Makefile
> index f7d08997dbf..ef10b9a031d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -344,7 +344,8 @@ MANUAL_BUILDDIR := docs
>  endif
>  
>  ifdef BUILD_DOCS
> -DOCS=qemu-doc.html qemu-doc.txt qemu.1
> +DOCS=qemu-doc.html qemu-doc.txt
> +DOCS+=$(MANUAL_BUILDDIR)/system/qemu.1
>  DOCS+=$(MANUAL_BUILDDIR)/tools/qemu-img.1
>  DOCS+=$(MANUAL_BUILDDIR)/tools/qemu-nbd.8
>  DOCS+=$(MANUAL_BUILDDIR)/interop/qemu-ga.8
> @@ -856,7 +857,7 @@ install-doc: $(DOCS) install-sphinxdocs
>   $(INSTALL_DATA) docs/interop/qemu-qmp-ref.txt "$(DESTDIR)$(qemu_docdir)"
>  ifdef CONFIG_POSIX
>   $(INSTALL_DIR) "$(DESTDIR)$(mandir)/man1"
> - $(INSTALL_DATA) qemu.1 "$(DESTDIR)$(mandir)/man1"
> + $(INSTALL_DATA) $(MANUAL_BUILDDIR)/system/qemu.1 
> "$(DESTDIR)$(mandir)/man1"
>   $(INSTALL_DIR) "$(DESTDIR)$(mandir)/man7"
>   $(INSTALL_DATA) docs/interop/qemu-qmp-ref.7 "$(DESTDIR)$(mandir)/man7"
>   $(INSTALL_DATA) $(MANUAL_BUILDDIR)/system/qemu-block-drivers.7 
> "$(DESTDIR)$(mandir)/man7"
> @@ -1082,7 +1083,7 @@ $(MANUAL_BUILDDIR)/user/index.html: $(call 
> manual-deps,user)
>  
>  $(call define-manpage-rule,interop,qemu-ga.8)
>  
> -$(call define-manpage-rule,system,qemu-block-drivers.7 qemu-cpu-models.7)
> +$(call define-manpage-rule,system,qemu.1 qemu-block-drivers.7 
> qemu-cpu-models.7)
>  
>  $(call define-manpage-rule,tools,\
> qemu-img.1 qemu-nbd.8 qemu-trace-stap.1\
> @@ -1109,9 +1110,6 @@ docs/interop/qemu-qmp-qapi.texi: qapi/qapi-doc.texi
>  docs/interop/qemu-ga-qapi.texi: qga/qapi-generated/qga-qapi-doc.texi
>   @cp -p $< $@
>  
> -qemu.1: qemu-doc.texi qemu-options.texi qemu-monitor.texi 
> qemu-monitor-info.texi
> -qemu.1: docs/system/qemu-option-trace.texi
> -
>  html: qemu-doc.html docs/interop/qemu-qmp-ref.html 
> docs/interop/qemu-ga-ref.html sphinxdocs
>  info: qemu-doc.info docs/interop/qemu-qmp-ref.info 
> docs/interop/qemu-ga-ref.info
>  pdf: qemu-doc.pdf docs/interop/qemu-qmp-ref.pdf docs/interop/qemu-ga-ref.pdf
> diff --git a/docs/system/conf.py b/docs/system/conf.py
> index 23cab3fb364..6251849fefc 100644
> --- a/docs/system/conf.py
> +++ b/docs/system/conf.py
> @@ -17,6 +17,8 @@ html_theme_options['description'] = u'System Emulation 
> User''s Guide'
>  # One entry per manual page. List of tuples
>  # (source start file, name, description, authors, manual section).
>  man_pages = [
> +('qemu-manpage', 'qemu', u'QEMU User Documentation',
> + ['Fabrice Bellard'], 1),
>  ('qemu-block-drivers', 'qemu-block-drivers',
>   u'QEMU block drivers reference',
>   ['Fabrice Bellard and the QEMU Project developers'], 7),
> diff --git a/docs/system/qemu-manpage.rst b/docs/system/qemu-manpage.rst
> new file mode 100644
> index 000..e9a25d0680f
> --- /dev/null
> +++ b/docs/system/qemu-manpage.rst
> @@ -0,0 +1,45 @@
> +:orphan:
> +
> +..
> +   This file is the skeleton for the qemu.1 manpage. It mostly
> +   should simply include the .rst.inc files corresponding to the
> +   parts of the documentation that go in the manpage as well as the
> +   HTML manual.
> +
> +Title
> +=
> +
> +Synopsis
> +
> +
> +.. parsed-literal::
> +
> +   |qemu_system| [options] [disk_image]
> +
> +Description
> +---
> +
> +.. include:: target-i386-desc.rst.inc
> +
> +Options
> +---
> +
> +disk_image is a raw hard disk image for IDE hard disk 0. Some targets do
> +not need a disk image.
> +
> +.. hxtool-doc:: qemu-options.hx
> +
> +.. include:: keys.rst.inc
> +
> +.. include:: mux-chardev.rst.inc
> +
> +Notes
> +-
> +
> +.. include:: device-url-syntax.rst.inc
> +
> +See also
> +
> +
> +The HTML documentation of QEMU for more precise information and Linux
> +user mode emulator invocation.


-- 
Alex Bennée



Re: [PATCH v3 30/33] ui/cocoa.m: Update documentation file and pathname

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> We want to stop generating the old qemu-doc.html; first we
> must update places that refer to it so they instead go to
> our top level index.html documentation landing page.
> The Cocoa UI has a menu option to bring up the documentation;
> make it point to the new top level index.html instead.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée



Re: [PATCH v2 1/2] tests/vhost-user-bridge: move to contrib/

2020-03-02 Thread Laurent Vivier
On 02/03/2020 12:19, Laurent Vivier wrote:
> On 02/03/2020 11:53, Michael S. Tsirkin wrote:
>> On Mon, Mar 02, 2020 at 10:50:16AM +0100, Laurent Vivier wrote:
>>> On 01/03/2020 13:12, Michael S. Tsirkin wrote:
 On Fri, Feb 07, 2020 at 10:54:11AM +0100, Laurent Vivier wrote:
> vhost-user-bridge is not a test. Move it to contrib/ and
> add it to the tools list.
>
> It will be built only if tools (--enable-tools) and
> vhost-user (--enable-vhost-user) are enabled (both are set
> by default).
>
> Suggested-by: Dr. David Alan Gilbert 
> Signed-off-by: Laurent Vivier 
> Reviewed-by: Philippe Mathieu-Daudé 


 I had to drop this series from my tree since it cause failures
 on OSX. Pls use something like travis CI to test when you repost
 a fixed version. Thanks!

>>>
>>> Do you have a link to the error logs?
>>>
>>> Thanks,
>>> Laurent
>>
>>
>> Peter sent me this:
>>
>>
>> Hi; this fails to build on OSX:
>>
>>   CC  contrib/libvhost-user/libvhost-user.o
>> /Users/pm215/src/qemu-for-merges/contrib/libvhost-user/libvhost-user.c:27:10:
>> fatal error: 'sys/eventfd.h' file not found
>> #include 
>>  ^~~
>> In file included from
>> /Users/pm215/src/qemu-for-merges/contrib/vhost-user-bridge/main.c:37:
>> /Users/pm215/src/qemu-for-merges/contrib/libvhost-user/libvhost-user.h:21:10:
>> fatal error: 'linux/vhost.h' file not found
>> #include 
>>  ^~~
>> 1 error generated.
>>
>> thanks
>> -- PMM
>>
>> But pls do test on OSX before reposting.
>>
> 
> Thank you.
> 
> I will fix and test the new patch with Travis CI.

In fact, travis was enabled when I sent the series but the QEMU
.travis.yml disables the tools so the vhost-user-bridge was not built.

Thanks,
Laurent




Re: [PATCH v3 31/33] docs: Stop building qemu-doc

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> Stop building the old texinfo qemu-doc; all its contents are
> now available in the Sphinx-generated manuals and manpages.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée



Re: [edk2-devel] A problem with live migration of UEFI virtual machines

2020-03-02 Thread Dr. David Alan Gilbert
* Laszlo Ersek (ler...@redhat.com) wrote:

> The interesting question is, what happens when you power down the VM on
> the destination host (= post migration), and launch it again there, from
> zero. In that case, the firmware executable file comes from the
> *destination host* (it was never persistently migrated from the source
> host, i.e. never written out on the dst). It simply comes from the OVMF
> package that had been installed on the destination host, by the
> sysadmin. However, the varstore pflash does reflect the permanent result
> of the previous migration. So this is where things can fall apart, if
> both firmware binaries (on the src host and on the dst host) don't agree
> about the internal structure of the varstore pflash.

My guess is that overtime we're going to need to find a way to handle
this, otherwise we're going to find people having to maintain old
versions of OVMF just to keep variable store compatiiblity.

Dave

> Thanks
> Laszlo
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK




Re: [PATCH v3 32/33] docs: Remove old texinfo sources

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> We can now delete the old .texi files, which we have been keeping in
> the tree as a parallel set of documentation to the new rST sources.
> The only remaining use of Texinfo is the autogenerated manuals
> and HTML documents created from the QAPI JSON doc comments.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée



Re: [PATCH v3 33/33] *.hx: Remove all the STEXI/ETEXI blocks

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> We no longer generate texinfo from the hxtool input files,
> so delete all the STEXI/ETEXI blocks.
>
> This commit was created using the following Perl one-liner:
>   perl -i -n -e '$suppress = 1,next if /^STEXI/;$suppress=0,next if /^ETEXI/; 
> print if !$suppress;' *.hx
>
> Signed-off-by: Peter Maydell 
> ---
>  hmp-commands-info.hx |  329 
>  hmp-commands.hx  |  821 -
>  qemu-options.hx  | 4054 --
>  3 files changed, 5204 deletions(-)
>
> diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
> index 1730f866cde..499d6d54b01 100644
> --- a/hmp-commands-info.hx
> +++ b/hmp-commands-info.hx
> @@ -11,13 +11,6 @@ HXCOMM appears inside the documentation list item for the 
> top level
>  HXCOMM "info" documentation entry. The exception is the first SRST
>  HXCOMM fragment that defines that top level entry.

We still mention them in the preamble just before:

  HXCOMM Text between STEXI and ETEXI are copied to texi version and
  HXCOMM discarded from C version

And don't mention the SRST/ERST sections. It might be worth tweaking
that while we are at it.

Otherwise:

Reviewed-by: Alex Bennée 

-- 
Alex Bennée



Re: [PATCH v3 14/33] docs: Create defs.rst.inc as a place to define substitutions

2020-03-02 Thread Kashyap Chamarthy
On Fri, Feb 28, 2020 at 03:36:00PM +, Peter Maydell wrote:
> Rather than accumulating generally useful rST substitution
> definitions in individual rST files, create a defs.rst.inc where we
> can define these.  To start with it has the |qemu_system| definition
> from qemu-block-drivers.rst.
> 
> Add a comment noting a pitfall where putting literal markup in the
> definition of |qemu_system| makes it misrender manpage output; this
> means the point-of-use must handle the literal markup (which is
> almost always done by having it inside a parsed-literal block).
> 
> Signed-off-by: Peter Maydell 

Reviewed-by: Kashyap Chamarthy 

> ---
>  Makefile   |  1 +
>  docs/conf.py   |  6 ++
>  docs/defs.rst.inc  | 11 +++
>  docs/system/qemu-block-drivers.rst |  2 --
>  4 files changed, 18 insertions(+), 2 deletions(-)
>  create mode 100644 docs/defs.rst.inc
> 
> diff --git a/Makefile b/Makefile
> index 7e60a435426..26bbd334438 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1052,6 +1052,7 @@ sphinxdocs: $(MANUAL_BUILDDIR)/devel/index.html \
>  build-manual = $(call quiet-command,CONFDIR="$(qemu_confdir)" 
> $(SPHINX_BUILD) $(if $(V),,-q) -W -b $2 -D version=$(VERSION) -D 
> release="$(FULL_VERSION)" -d .doctrees/$1-$2 $(SRC_PATH)/docs/$1 
> $(MANUAL_BUILDDIR)/$1 ,"SPHINX","$(MANUAL_BUILDDIR)/$1")
>  # We assume all RST files in the manual's directory are used in it
>  manual-deps = $(wildcard $(SRC_PATH)/docs/$1/*.rst) \
> +  $(SRC_PATH)/docs/defs.rst.inc \
>$(SRC_PATH)/docs/$1/conf.py $(SRC_PATH)/docs/conf.py
>  # Macro to write out the rule and dependencies for building manpages
>  # Usage: $(call define-manpage-rule,manualname,manpage1 
> manpage2...[,extradeps])
> diff --git a/docs/conf.py b/docs/conf.py
> index 7588bf192ee..960043cb860 100644
> --- a/docs/conf.py
> +++ b/docs/conf.py
> @@ -132,6 +132,12 @@ suppress_warnings = ["ref.option"]
>  # style document building; our Makefile always sets the variable.
>  confdir = os.getenv('CONFDIR', "/etc/qemu")
>  rst_epilog = ".. |CONFDIR| replace:: ``" + confdir + "``\n"
> +# We slurp in the defs.rst.inc and literally include it into rst_epilog,
> +# because Sphinx's include:: directive doesn't work with absolute paths
> +# and there isn't any one single relative path that will work for all
> +# documents and for both via-make and direct sphinx-build invocation.
> +with open(os.path.join(qemu_docdir, 'defs.rst.inc')) as f:

I didn't know about the above quirk; thanks for the explanatory comment.

> +rst_epilog += f.read()
>  
>  # -- Options for HTML output --
>  
> diff --git a/docs/defs.rst.inc b/docs/defs.rst.inc
> new file mode 100644
> index 000..ae80d2f35d8
> --- /dev/null
> +++ b/docs/defs.rst.inc
> @@ -0,0 +1,11 @@
> +..
> +   Generally useful rST substitution definitions. This is included for
> +   all rST files as part of the epilogue by docs/conf.py.  conf.py
> +   also defines some dynamically generated substitutions like CONFDIR.
> +
> +   Note that |qemu_system| is intended to be used inside a parsed-literal
> +   block: the definition must not include extra literal formatting with
> +   ``..``: this works in the HTML output but the manpages will end up
> +   misrendered with following normal text incorrectly in boldface.

Thanks for documenting the above bit here.  (I learnt about it from you
on IRC.)

> +.. |qemu_system| replace:: qemu-system-x86_64
> diff --git a/docs/system/qemu-block-drivers.rst 
> b/docs/system/qemu-block-drivers.rst
> index 7ca890ea23a..bd99d4fa8eb 100644
> --- a/docs/system/qemu-block-drivers.rst
> +++ b/docs/system/qemu-block-drivers.rst
> @@ -3,8 +3,6 @@
>  QEMU block drivers reference
>  
>  
> -.. |qemu_system| replace:: qemu-system-x86_64
> -
>  Synopsis
>  
>  
> -- 
> 2.20.1
> 

-- 
/kashyap




Re: [PATCH v3 00/33] Convert qemu-doc to rST

2020-03-02 Thread Alex Bennée


Peter Maydell  writes:

> Hi; this series does a complete conversion of qemu-doc from
> Texinfo to rST, including the hxtool-generated parts and
> creation of the qemu.1 manpage from rST.
>
> It's marked v3 because it's a development of the v2 that
> Paolo sent out earlier this week.


I should mention the whole thing is:

Tested-by: Alex Bennée 

by virtue of my custom rtd branch:

  https://qemu-stsquad.readthedocs.io/en/doc-updates/index.html

-- 
Alex Bennée



Re: [PATCH v3 32/33] docs: Remove old texinfo sources

2020-03-02 Thread Kashyap Chamarthy
On Fri, Feb 28, 2020 at 03:36:18PM +, Peter Maydell wrote:
> We can now delete the old .texi files, which we have been keeping in
> the tree as a parallel set of documentation to the new rST sources.
> The only remaining use of Texinfo is the autogenerated manuals
> and HTML documents created from the QAPI JSON doc comments.
> 
> Signed-off-by: Peter Maydell 
> ---
>  MAINTAINERS|   5 +-
>  docs/system/build-platforms.texi   |  67 
>  docs/system/cpu-models-mips.texi   | 157 --
>  docs/system/cpu-models-x86.texi| 482 -
>  docs/system/deprecated.texi| 377 --
>  docs/system/gdb.texi   |  71 -
>  docs/system/images.texi|  88 --
>  docs/system/invocation.texi| 240 --
>  docs/system/ivshmem.texi   |  60 
>  docs/system/keys.texi  |  43 ---
>  docs/system/license.texi   |   9 -
>  docs/system/linuxboot.texi |  27 --
>  docs/system/managed-startup.texi   |  35 ---
>  docs/system/monitor.texi   |  34 --
>  docs/system/mux-chardev.texi   |  44 ---
>  docs/system/net.texi   |  96 --
>  docs/system/qemu-option-trace.texi |  28 --
>  docs/system/quickstart.texi|  12 -
>  docs/system/security.texi  | 167 --
>  docs/system/target-arm.texi| 245 ---
>  docs/system/target-i386.texi   |  91 --
>  docs/system/target-m68k.texi   |  25 --
>  docs/system/target-mips.texi   | 150 -
>  docs/system/target-ppc.texi|  52 
>  docs/system/target-sparc.texi  |  68 
>  docs/system/target-sparc64.texi|  38 ---
>  docs/system/target-xtensa.texi |  35 ---
>  docs/system/tls.texi   | 329 
>  docs/system/usb.texi   | 115 ---
>  docs/system/vnc-security.texi  | 196 
>  qemu-doc.texi  | 201 
>  31 files changed, 1 insertion(+), 3586 deletions(-)

Nice diff-stat; "negative code" for the win! :-)

(Yes, yes, we do add them back in a different form elsewhere...)


Reviewed-by: Kashyap Chamarthy 

[...]

-- 
/kashyap




  1   2   3   4   >