Re: [Qemu-devel] [PATCH 03/18] Include qapi/error.h exactly where needed

[Markus Armbruster]

Eric Blake  writes:

> On 01/30/2018 04:21 AM, Markus Armbruster wrote:
>> This cleanup makes the number of objects depending on qapi/error.h
>> drop from 1910 (out of 4739) to 1612 in my "build everything" tree.
>> 
>> Signed-off-by: Markus Armbruster 
>> ---
>>  arch_init.c | 1 +
>>  audio/wavcapture.c  | 1 +
>>  balloon.c   | 1 +
>>  block.c | 2 ++
>>  block/block-backend.c   | 1 +
>>  block/iscsi.c   | 1 +
>>  block/qapi.c| 1 +
>
> So several .c files have to use it explicitly,
>
>>  fsdev/qemu-fsdev-throttle.h | 1 -
>
>>  include/crypto/random.h | 1 -
>>  include/crypto/xts.h| 1 -
>>  include/hw/ide/internal.h   | 1 -
>>  include/ui/console.h| 1 -
>
> because they were previously getting it from .h files that don't
> directly emit an error.  Makes sense.
>
> Patches like this are easy to test - if it still compiles, you did it
> right ;)  Out of curiousity, how are you counting how many files got
> compiled per run?  Touch the .h, then pass 'make' output to 'grep -c "^
> CC "'?

The data is up for grabs: in the .d gcc spits out for make.  I process
them like this, after fresh build:

$ find bld -name \*.d -exec cat {} + | clean-deps

where clean-deps is this AWK script:

#!/usr/bin/awk -f
/\\$/ {
l = $0
while (sub(/\\$/, "", l) && (getline t))
l = l t
$0 = l
}

NF > 1 {
delete a
for (i = 2; i <= NF; i++) {
n = $i
# ignore system headers and non-headers
if (match(n, /^\/usr/) || !match(n, /\.h$/))
continue
# strip leading ../ from target build running in sub-directory
sub(/^\.\.\//, "", n)
# normalize /../ and /./
while (sub(/[^\/]*\/\.\.\//, "", n)) ;
gsub(/\/\.\//, "/", n)
# absolute -> relative
sub(/\/home\/armbru\/work\//, "/work/armbru/", n)
sub(/\/work\/armbru\/qemu\/(bld\/)?/, "", n)
# ignore dupes
if (n in a)
continue
a[n] = i
h[n]++
}
}

END {
for (i in h)
print i, h[i]
}

My conversion from absolute to relative is specific to my personal
setup.  It would have to be generalized before we can put this into
scripts.

> But just to make sure nothing weird is happening, I also read through
> it, and found:
>
>> 
>> diff --git a/arch_init.c b/arch_init.c
>> index a0b8ed6167..0fb8093f92 100644
>> --- a/arch_init.c
>> +++ b/arch_init.c
>> @@ -21,6 +21,7 @@
>>   * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
>>   * THE SOFTWARE.
>>   */
>> +
>>  #include "qemu/osdep.h"
>>  #include "qemu-common.h"
>>  #include "cpu.h"
>
> Spurious whitespace change.  Should this belong in 1/18, even though
> arch_init.c didn't need cleanup there?  Or...
>
>> +++ b/block.c
>> @@ -21,6 +21,7 @@
>>   * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
>>   * THE SOFTWARE.
>>   */
>> +
>>  #include "qemu/osdep.h"
>>  #include "block/trace.h"
>>  #include "block/block_int.h"
>
> ...since you did it again, do you need a separate patch for ALL of these
> types of whitespace cleanups near osdep.h?

I routinely insert this blank line when I touch includes anyway.

>> +++ b/block/qcow2.c
>> @@ -21,6 +21,7 @@
>>   * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
>>   * THE SOFTWARE.
>>   */
>> +
>>  #include "qemu/osdep.h"
>>  #include "block/block_int.h"
>>  #include "sysemu/block-backend.h"
>
> and again
>
>> +++ b/chardev/char-ringbuf.c
>> @@ -21,9 +21,11 @@
>>   * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
>>   * THE SOFTWARE.
>>   */
>> +
>>  #include "qemu/osdep.h"
>>  #include "chardev/char.h"
>>  #include "qmp-commands.h"
>> +#include "qapi/error.h"
>>  #include "qemu/base64.h"
>>  
>>  /* Ring buffer chardev */
>
> Here, it's in the same hunk, so a bit more forgivable.  But there's
> definitely enough of them that a separate commit might be in order.
>
> At any rate, whether done as one patch (with a better commit message) or
> as two, I see nothing semantically wrong with the cleanups done here, so

I'll amend the commit message.

> Reviewed-by: Eric Blake 

Thanks!

Re: [Qemu-devel] [PATCH 02/18] Drop superfluous includes of qapi-types.h

[Markus Armbruster]

Eric Blake  writes:

> On 01/30/2018 04:21 AM, Markus Armbruster wrote:
>> Signed-off-by: Markus Armbruster 
>> ---
>
>> +++ b/tests/test-clone-visitor.c
>> @@ -11,7 +11,6 @@
>>  
>>  #include "qemu-common.h"
>>  #include "qapi/clone-visitor.h"
>> -#include "test-qapi-types.h"
>
> Overactive sed pattern?  This is a different header.  While the tests
> still pass after deleting this include, removal of the test-qapi-types.h
> line here and in other tests/ files should be a separate patch, or else
> the commit message updated to mention it.

Intentional.  I'll amend the commit message.

Re: [Qemu-devel] [PATCH 01/18] Clean up includes

[Markus Armbruster]

BALATON Zoltan  writes:

> On Tue, 30 Jan 2018, Markus Armbruster wrote:
>> Clean up includes so that osdep.h is included first and headers
>> which it implies are not included manually.
>>
>> This commit was created with scripts/clean-includes, with the change
>> to target/s390x/gen-features.c manually reverted, and blank lines
>> around deletions collapsed.
>>
>> Signed-off-by: Markus Armbruster 
[...]
>> diff --git a/hw/ide/sii3112.c b/hw/ide/sii3112.c
>> index 17aa930e39..a5d1776756 100644
>> --- a/hw/ide/sii3112.c
>> +++ b/hw/ide/sii3112.c
>> @@ -12,6 +12,7 @@
>>  * http://wiki.osdev.org/User:Quok/Silicon_Image_Datasheets
>>  */
>>
>> +#include "qemu/osdep.h"
>> #include 
>> #include 
>> #include "trace.h"
>
> This is wrong. I've sent a patch instead to change angle brackets to
> quotes for these two includes. This wasn't catched either by
> checkpatch nor review though so maybe it could be added to checkpatch
> if quotes are the preferred style for these includes.

Good catch!  There's more than these two in the tree.  I'll stick in a
suitable cleanup patch.

Re: [Qemu-devel] [PATCH 1/3] s390x/pci: fixup the code walking IOMMU tables

[Thomas Huth]

On 30.01.2018 10:47, Yi Min Zhao wrote:
> Current s390x PCI IOMMU code is lack of flags' checking, including:
> 1) protection bit
> 2) table length
> 3) table offset
> 4) intermediate tables' invalid bit
> 5) format control bit
> 
> This patch introduces a new struct named S390IOTLBEntry, and makes up
> these missed checkings. At the same time, inform the guest with the
> corresponding error number when the check fails.
> 
> Reviewed-by: Pierre Morel 
> Signed-off-by: Yi Min Zhao 
> ---
>  hw/s390x/s390-pci-bus.c  | 223 
> ++-
>  hw/s390x/s390-pci-bus.h  |  10 +++
>  hw/s390x/s390-pci-inst.c |  10 ---
>  3 files changed, 190 insertions(+), 53 deletions(-)
[...]
> @@ -374,26 +511,26 @@ static IOMMUTLBEntry 
> s390_translate_iommu(IOMMUMemoryRegion *mr, hwaddr addr,
>  DPRINTF("iommu trans addr 0x%" PRIx64 "\n", addr);
>  
>  if (addr < iommu->pba || addr > iommu->pal) {
> -return ret;
> +error = ERR_EVENT_OORANGE;
> +goto err;
>  }
>  
> -pte = s390_guest_io_table_walk(s390_pci_get_table_origin(iommu->g_iota),
> -   addr);
> -if (!pte) {
> -return ret;
> -}
> +error = s390_guest_io_table_walk(iommu->g_iota, addr, );
>  
> -flags = pte & ZPCI_PTE_FLAG_MASK;
> -ret.iova = addr;
> -ret.translated_addr = pte & ZPCI_PTE_ADDR_MASK;
> -ret.addr_mask = 0xfff;
> +ret.iova = entry.iova;
> +ret.translated_addr = entry.translated_addr;
> +ret.addr_mask = entry.len - 1;
> +ret.perm = entry.perm;
>  
> -if (flags & ZPCI_PTE_INVALID) {
> -ret.perm = IOMMU_NONE;
> -} else {
> -ret.perm = IOMMU_RW;
> +if ((flag != IOMMU_NONE) && !(flag & ret.perm)) {

You could drop the parentheses around "flag != IOMMU_NONE".

For the rest of the patch: Sorry, can't review due to missing PCI spec :-(

 Thomas

Re: [Qemu-devel] [RFC PATCH qemu v6] vfio-pci: Allow mmap of MSIX BAR

[no-reply]

Hi,

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

Type: series
Message-id: 20180131072445.22783-1-...@ozlabs.ru
Subject: [Qemu-devel] [RFC PATCH qemu v6] vfio-pci: Allow mmap of MSIX BAR

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

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

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

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

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
e891e69645 vfio-pci: Allow mmap of MSIX BAR

=== OUTPUT BEGIN ===
Checking PATCH 1/1: vfio-pci: Allow mmap of MSIX BAR...
ERROR: line over 90 characters
#82: FILE: hw/vfio/common.c:517:
+error_report("Region %"HWADDR_PRIx"..%"HWADDR_PRIx" is not aligned 
to %"HWADDR_PRIx" and cannot be mapped for DMA",

total: 1 errors, 0 warnings, 157 lines checked

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

=== OUTPUT END ===

Test command exited with code: 1


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

[Qemu-devel] [RFC PATCH qemu v6] vfio-pci: Allow mmap of MSIX BAR

[Alexey Kardashevskiy]

This makes use of a new VFIO_REGION_INFO_CAP_MSIX_MAPPABLE capability
which tells that a region with MSIX data can be mapped entirely, i.e.
the VFIO PCI driver won't prevent MSIX vectors area from being mapped.

With this change, all BARs are mapped in a single chunk and MSIX vectors
are emulated on top unless the machine requests not to by defining and
enabling a new "vfio-no-msix-emulation" property. At the moment only
sPAPR machine does so - it prohibits MSIX emulation and does not allow
enabling it as it does not define the "set" callback for the new property;
the new property also does not appear in "-machine pseries,help".

This change may affect machines which are using MSIX emulation and
mapping MMIO RAM regions for DMA as previously MSIX containing BAR
would be split in chunks aligned to the system page size and we would
only see aligned RAM memory sections in vfio_listener_region_add/del.
As the system page size is usually is equal or bigger than the IOMMU
page size, vfio_dma_map() did not have a legitimate reason to fail so
mapping failures were fatal. Note that this behaviour silently skips
parts of BARs adjacent to the MSIX data.

With this change, we map entire MSIX BAR and emulate MSIX on top of it
so vfio_listener_region_add/del may be called with unaligned MMIO RAM
regions and vfio_dma_map() will fail on these. In order to mitigate
this, this changes vfio_listener_region_add() not to try vfio_dma_map() if
the memory section is not aligned to the minimal IOMMU page; an error
is printed instead. This also treats all errors from vfio_dma_map()
non fatal when the listener is called on the MMIO RAM region.
vfio_listener_region_del() is adjusted accordingly.

If the amount of errors printed is overwhelming, the MSIX relocation
could be used to avoid excessive error output.

This requires the kernel change - "vfio-pci: Allow mapping MSIX BAR" -
for the new capability: https://www.spinics.net/lists/kvm/msg160282.html

Signed-off-by: Alexey Kardashevskiy 
---
Changes:
v6:
* dropped that stupid p2p property patch

v5:
* rebased on top of 'p2p' proposed patch

v4:
* silenced dma map errors if unaligned mapping is attempted - they are going
to fail anyway

v3:
* vfio_listener_region_add() won't make qemu exit if failed on MMIO MR
---
 include/hw/vfio/vfio-common.h |  1 +
 linux-headers/linux/vfio.h|  5 
 hw/ppc/spapr.c|  7 +
 hw/vfio/common.c  | 66 +++
 hw/vfio/pci.c | 10 +++
 5 files changed, 83 insertions(+), 6 deletions(-)

diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
index f3a2ac9..927d600 100644
--- a/include/hw/vfio/vfio-common.h
+++ b/include/hw/vfio/vfio-common.h
@@ -171,6 +171,7 @@ int vfio_get_region_info(VFIODevice *vbasedev, int index,
  struct vfio_region_info **info);
 int vfio_get_dev_region_info(VFIODevice *vbasedev, uint32_t type,
  uint32_t subtype, struct vfio_region_info **info);
+bool vfio_is_cap_present(VFIODevice *vbasedev, uint16_t cap_type, int region);
 #endif
 extern const MemoryListener vfio_prereg_listener;
 
diff --git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h
index 4312e96..b45182e 100644
--- a/linux-headers/linux/vfio.h
+++ b/linux-headers/linux/vfio.h
@@ -301,6 +301,11 @@ struct vfio_region_info_cap_type {
 #define VFIO_REGION_SUBTYPE_INTEL_IGD_HOST_CFG (2)
 #define VFIO_REGION_SUBTYPE_INTEL_IGD_LPC_CFG  (3)
 
+/*
+ * The MSIX mappable capability informs that MSIX data of a BAR can be mmapped.
+ */
+#define VFIO_REGION_INFO_CAP_MSIX_MAPPABLE 3
+
 /**
  * VFIO_DEVICE_GET_IRQ_INFO - _IOWR(VFIO_TYPE, VFIO_BASE + 9,
  * struct vfio_irq_info)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 32a876b..6d333e2 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2830,6 +2830,11 @@ static void spapr_set_modern_hotplug_events(Object *obj, 
bool value,
 spapr->use_hotplug_event_source = value;
 }
 
+static bool spapr_get_msix_emulation(Object *obj, Error **errp)
+{
+return true;
+}
+
 static char *spapr_get_resize_hpt(Object *obj, Error **errp)
 {
 sPAPRMachineState *spapr = SPAPR_MACHINE(obj);
@@ -2911,6 +2916,8 @@ static void spapr_instance_init(Object *obj)
 object_property_set_description(obj, "vsmt",
 "Virtual SMT: KVM behaves as if this were"
 " the host's SMT mode", _abort);
+object_property_add_bool(obj, "vfio-no-msix-emulation",
+ spapr_get_msix_emulation, NULL, NULL);
 }
 
 static void spapr_machine_finalizefn(Object *obj)
diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 3d652c8..9100a42 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -508,6 +508,18 @@ static void vfio_listener_region_add(MemoryListener 
*listener,
 }
 
 /* Here we assume that memory_region_is_ram(section->mr)==true 

Re: [Qemu-devel] [PATCH v1] ps2: check PS2Queue pointers in post_load routine

[P J P]

+-- On Thu, 25 Jan 2018, Gerd Hoffmann wrote --+
| Ok, finally queueed up v1 for merge.

Okay, cool. Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

Re: [Qemu-devel] SDL2 UI behavior of switching views

[Gerd Hoffmann]

  Hi,

> I think it does not have to be runtime switchable in the sense that the
> setting does not need to be changable during run (like in gtk) because we
> don't have a UI for changing it anyway. It's enough to have an option to
> decide it once at startup, in case that's easier to implement.

Yes, a global switch (so all consoles are in the same mode) is probably
easier to implement.

> If not then I guess this will remain as it is now but it's unfortunate
> to change the previous behaviour with a version change for no good
> reason.

Well, I find it quite useful to see windows side by side.  For example
in case of a multihead setup, or to see vga and serial console at the
same time ...

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 00/18] Clean up includes to reduce compile time

[Thomas Huth]

On 30.01.2018 11:21, Markus Armbruster wrote:
> We have awfully many "touch it, recompile the world" headers.  Right
> now, I count about fifty that are prerequisites of more than half the
> objects in my "build everything" tree.

Could you maybe share the list of these 50 headers? ... cleaning this up
could also be a good task for https://wiki.qemu.org/BiteSizedTasks I guess?

 Thomas

[Qemu-devel] [PATCH v4 5/6] hostmem: add more information in error messages

[Haozhong Zhang]

When there are multiple memory backends in use, including the object type
name, ID and the property name in the error message can help users to
locate the error.

Signed-off-by: Haozhong Zhang 
Suggested-by: "Dr. David Alan Gilbert" 
Reviewed-by: Michael S. Tsirkin 
---
 backends/hostmem-file.c |  9 ++---
 backends/hostmem.c  | 11 +++
 2 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c
index 67ecfed895..df06b547a6 100644
--- a/backends/hostmem-file.c
+++ b/backends/hostmem-file.c
@@ -80,7 +80,8 @@ static void set_mem_path(Object *o, const char *str, Error 
**errp)
 HostMemoryBackendFile *fb = MEMORY_BACKEND_FILE(o);
 
 if (host_memory_backend_mr_inited(backend)) {
-error_setg(errp, "cannot change property value");
+error_setg(errp, "cannot change property 'mem-path' of %s '%s'",
+   object_get_typename(o), backend->id);
 return;
 }
 g_free(fb->mem_path);
@@ -100,7 +101,8 @@ static void file_memory_backend_set_share(Object *o, bool 
value, Error **errp)
 HostMemoryBackendFile *fb = MEMORY_BACKEND_FILE(o);
 
 if (host_memory_backend_mr_inited(backend)) {
-error_setg(errp, "cannot change property value");
+error_setg(errp, "cannot change property 'share' of %s '%s'",
+   object_get_typename(o), backend->id);
 return;
 }
 fb->share = value;
@@ -137,7 +139,8 @@ static void file_memory_backend_set_align(Object *o, 
Visitor *v,
 uint64_t val;
 
 if (host_memory_backend_mr_inited(backend)) {
-error_setg(_err, "cannot change property value");
+error_setg(_err, "cannot change property '%s' of %s '%s'",
+   name, object_get_typename(o), backend->id);
 goto out;
 }
 
diff --git a/backends/hostmem.c b/backends/hostmem.c
index ee2c2d5bfd..6853d19bc5 100644
--- a/backends/hostmem.c
+++ b/backends/hostmem.c
@@ -46,7 +46,8 @@ host_memory_backend_set_size(Object *obj, Visitor *v, const 
char *name,
 uint64_t value;
 
 if (host_memory_backend_mr_inited(backend)) {
-error_setg(_err, "cannot change property value");
+error_setg(_err, "cannot change property %s of %s '%s'",
+   name, object_get_typename(obj), backend->id);
 goto out;
 }
 
@@ -55,8 +56,9 @@ host_memory_backend_set_size(Object *obj, Visitor *v, const 
char *name,
 goto out;
 }
 if (!value) {
-error_setg(_err, "Property '%s.%s' doesn't take value '%"
-   PRIu64 "'", object_get_typename(obj), name, value);
+error_setg(_err,
+   "property '%s' of %s '%s' doesn't take value '%" PRIu64 "'",
+   name, object_get_typename(obj), backend->id, value);
 goto out;
 }
 backend->size = value;
@@ -363,7 +365,8 @@ static void set_id(Object *o, const char *str, Error **errp)
 HostMemoryBackend *backend = MEMORY_BACKEND(o);
 
 if (backend->id) {
-error_setg(errp, "cannot change property value");
+error_setg(errp, "cannot change property 'id' of %s '%s'",
+   object_get_typename(o), backend->id);
 return;
 }
 backend->id = g_strdup(str);
-- 
2.14.1

[Qemu-devel] [PATCH v4 4/6] util/mmap-alloc: support MAP_SYNC in qemu_ram_mmap()

[Haozhong Zhang]

When a file supporting DAX is used as vNVDIMM backend, mmap it with
MAP_SYNC flag in addition can guarantee the persistence of guest write
to the backend file without other QEMU actions (e.g., periodic fsync()
by QEMU).

A set of QEMU_RAM_SYNC_{AUTO,ON,OFF} flags are added to qemu_ram_mmap():

- If QEMU_RAM_SYNC_ON is present, qemu_ram_mmap() will try to pass
  MAP_SYNC to mmap(). It will then fail if the host OS or the backend
  file do not support MAP_SYNC, or MAP_SYNC is conflict with other
  flags.

- If QEMU_RAM_SYNC_OFF is present, qemu_ram_mmap() will never pass
  MAP_SYNC to mmap().

- If QEMU_RAM_SYNC_AUTO is present, and
  * if the host OS and the backend file support MAP_SYNC, and MAP_SYNC
is not conflict with other flags, qemu_ram_mmap() will work as if
QEMU_RAM_SYNC_ON is present;
  * otherwise, qemu_ram_mmap() will work as if QEMU_RAM_SYNC_OFF is
present.

Signed-off-by: Haozhong Zhang 
---
 include/exec/memory.h | 26 ++
 include/exec/ram_addr.h   |  4 
 include/qemu/mmap-alloc.h |  4 
 include/standard-headers/linux/mman.h | 42 +++
 util/mmap-alloc.c | 23 ++-
 5 files changed, 98 insertions(+), 1 deletion(-)
 create mode 100644 include/standard-headers/linux/mman.h

diff --git a/include/exec/memory.h b/include/exec/memory.h
index 6b547da6a3..96a60e9c1d 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -458,6 +458,28 @@ void memory_region_init_resizeable_ram(MemoryRegion *mr,
 
 #define QEMU_RAM_SHARE  (1UL << 0)
 
+#define QEMU_RAM_SYNC_SHIFT 1
+#define QEMU_RAM_SYNC_MASK  0x6
+#define QEMU_RAM_SYNC_OFF   ((0UL << QEMU_RAM_SYNC_SHIFT) & QEMU_RAM_SYNC_MASK)
+#define QEMU_RAM_SYNC_ON((1UL << QEMU_RAM_SYNC_SHIFT) & QEMU_RAM_SYNC_MASK)
+#define QEMU_RAM_SYNC_AUTO  ((2UL << QEMU_RAM_SYNC_SHIFT) & QEMU_RAM_SYNC_MASK)
+
+static inline uint64_t qemu_ram_sync_flags(OnOffAuto v)
+{
+return v == ON_OFF_AUTO_OFF ? QEMU_RAM_SYNC_OFF :
+   v == ON_OFF_AUTO_ON ? QEMU_RAM_SYNC_ON : QEMU_RAM_SYNC_AUTO;
+}
+
+static inline OnOffAuto qemu_ram_sync_val(uint64_t flags)
+{
+unsigned int v = (flags & QEMU_RAM_SYNC_MASK) >> QEMU_RAM_SYNC_SHIFT;
+
+assert(v < 3);
+
+return v == 0 ? ON_OFF_AUTO_OFF :
+   v == 1 ? ON_OFF_AUTO_ON : ON_OFF_AUTO_AUTO;
+}
+
 #ifdef __linux__
 /**
  * memory_region_init_ram_from_file:  Initialize RAM memory region with a
@@ -473,6 +495,10 @@ void memory_region_init_resizeable_ram(MemoryRegion *mr,
  * @flags: specify properties of this memory region, which can be one or bit-or
  * of following values:
  * - QEMU_RAM_SHARE: memory must be mmaped with the MAP_SHARED flag
+ * - One of
+ *   QEMU_RAM_SYNC_ON:   mmap with MAP_SYNC flag
+ *   QEMU_RAM_SYNC_OFF:  do not mmap with MAP_SYNC flag
+ *   QEMU_RAM_SYNC_AUTO: automatically decide the use of MAP_SYNC flag
  * Other bits are ignored.
  * @path: the path in which to allocate the RAM.
  * @errp: pointer to Error*, to store an error if it happens.
diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index e24aae75a2..a2cc5a9f60 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@ -84,6 +84,10 @@ unsigned long last_ram_page(void);
  *  @flags: specify the properties of the ram block, which can be one
  *  or bit-or of following values
  *  - QEMU_RAM_SHARE: mmap the back file or device with MAP_SHARED
+ *  - One of
+ *QEMU_RAM_SYNC_ON:   mmap with MAP_SYNC flag
+ *QEMU_RAM_SYNC_OFF:  do not mmap with MAP_SYNC flag
+ *QEMU_RAM_SYNC_AUTO: automatically decide the use of MAP_SYNC flag
  *  Other bits are ignored.
  *  @mem_path or @fd: specify the back file or device
  *  @errp: pointer to Error*, to store an error if it happens
diff --git a/include/qemu/mmap-alloc.h b/include/qemu/mmap-alloc.h
index dc5e8b5efb..74346bdd3a 100644
--- a/include/qemu/mmap-alloc.h
+++ b/include/qemu/mmap-alloc.h
@@ -18,6 +18,10 @@ size_t qemu_mempath_getpagesize(const char *mem_path);
  *  @flags: specifies additional properties of the mapping, which can be one or
  *  bit-or of following values
  *  - QEMU_RAM_SHARE: mmap with MAP_SHARED flag
+ *  - One of
+ *QEMU_RAM_SYNC_ON:   mmap with MAP_SYNC flag
+ *QEMU_RAM_SYNC_OFF:  do not mmap with MAP_SYNC flag
+ *QEMU_RAM_SYNC_AUTO: automatically decide the use of MAP_SYNC flag
  *  Other bits are ignored.
  *
  * Return:
diff --git a/include/standard-headers/linux/mman.h 
b/include/standard-headers/linux/mman.h
new file mode 100644
index 00..02ad4f
--- /dev/null
+++ b/include/standard-headers/linux/mman.h
@@ -0,0 +1,42 @@
+/*
+ * Definitions of Linux-specific mmap flags.
+ *
+ * Copyright Intel Corporation, 2018
+ *
+ * Author: Haozhong Zhang 

[Qemu-devel] [PATCH v4 2/6] exec: switch qemu_ram_alloc_from_{file, fd} to the 'flags' parameter

[Haozhong Zhang]

As more flag parameters besides the existing 'share' are going to be
added to qemu_ram_alloc_from_{file,fd}(), let's swith 'share' to a
'flags' parameters in advance, so as to ease the further additions.

Signed-off-by: Haozhong Zhang 
---
 exec.c  | 15 ---
 include/exec/ram_addr.h | 25 +++--
 memory.c|  8 ++--
 3 files changed, 37 insertions(+), 11 deletions(-)

diff --git a/exec.c b/exec.c
index c0a5a52c4a..0b46b03d87 100644
--- a/exec.c
+++ b/exec.c
@@ -1607,6 +1607,7 @@ static void *file_ram_alloc(RAMBlock *block,
 ram_addr_t memory,
 int fd,
 bool truncate,
+uint64_t flags,
 Error **errp)
 {
 void *area;
@@ -1652,8 +1653,7 @@ static void *file_ram_alloc(RAMBlock *block,
 perror("ftruncate");
 }
 
-area = qemu_ram_mmap(fd, memory, block->mr->align,
- (block->flags & RAM_SHARED) ? QEMU_RAM_SHARE : 0);
+area = qemu_ram_mmap(fd, memory, block->mr->align, flags);
 if (area == MAP_FAILED) {
 error_setg_errno(errp, errno,
  "unable to map backing store for guest RAM");
@@ -2000,7 +2000,7 @@ static void ram_block_add(RAMBlock *new_block, Error 
**errp)
 
 #ifdef __linux__
 RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size, MemoryRegion *mr,
- bool share, int fd,
+ uint64_t flags, int fd,
  Error **errp)
 {
 RAMBlock *new_block;
@@ -2042,8 +2042,9 @@ RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size, 
MemoryRegion *mr,
 new_block->mr = mr;
 new_block->used_length = size;
 new_block->max_length = size;
-new_block->flags = share ? RAM_SHARED : 0;
-new_block->host = file_ram_alloc(new_block, size, fd, !file_size, errp);
+new_block->flags = (flags & QEMU_RAM_SHARE) ? RAM_SHARED : 0;
+new_block->host = file_ram_alloc(new_block, size, fd, !file_size, flags,
+ errp);
 if (!new_block->host) {
 g_free(new_block);
 return NULL;
@@ -2061,7 +2062,7 @@ RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size, 
MemoryRegion *mr,
 
 
 RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr,
-   bool share, const char *mem_path,
+   uint64_t flags, const char *mem_path,
Error **errp)
 {
 int fd;
@@ -2073,7 +2074,7 @@ RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, 
MemoryRegion *mr,
 return NULL;
 }
 
-block = qemu_ram_alloc_from_fd(size, mr, share, fd, errp);
+block = qemu_ram_alloc_from_fd(size, mr, flags, fd, errp);
 if (!block) {
 if (created) {
 unlink(mem_path);
diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index 7633ef6342..e24aae75a2 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@ -72,12 +72,33 @@ static inline unsigned long int 
ramblock_recv_bitmap_offset(void *host_addr,
 
 long qemu_getrampagesize(void);
 unsigned long last_ram_page(void);
+
+/**
+ * qemu_ram_alloc_from_file,
+ * qemu_ram_alloc_from_fd: Allocate a ram block from the specified back
+ * file or device
+ *
+ * Parameters:
+ *  @size: the size in bytes of the ram block
+ *  @mr: the memory region where the ram block is
+ *  @flags: specify the properties of the ram block, which can be one
+ *  or bit-or of following values
+ *  - QEMU_RAM_SHARE: mmap the back file or device with MAP_SHARED
+ *  Other bits are ignored.
+ *  @mem_path or @fd: specify the back file or device
+ *  @errp: pointer to Error*, to store an error if it happens
+ *
+ * Return:
+ *  On success, return a pointer to the ram block.
+ *  On failure, return NULL.
+ */
 RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr,
-   bool share, const char *mem_path,
+   uint64_t flags, const char *mem_path,
Error **errp);
 RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size, MemoryRegion *mr,
- bool share, int fd,
+ uint64_t flags, int fd,
  Error **errp);
+
 RAMBlock *qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
   MemoryRegion *mr, Error **errp);
 RAMBlock *qemu_ram_alloc(ram_addr_t size, MemoryRegion *mr, Error **errp);
diff --git a/memory.c b/memory.c
index 449a1429b9..1ac4ebcaca 100644
--- a/memory.c
+++ b/memory.c
@@ -1580,7 +1580,9 @@ void memory_region_init_ram_from_file(MemoryRegion *mr,
 mr->terminates = true;
 mr->destructor = memory_region_destructor_ram;
 mr->align = align;
-mr->ram_block 

[Qemu-devel] [PATCH v4 0/6] nvdimm: support MAP_SYNC for memory-backend-file

[Haozhong Zhang]

Linux 4.15 introduces a new mmap flag MAP_SYNC, which can be used to
guarantee the write persistence to mmap'ed files supporting DAX (e.g.,
files on ext4/xfs file system mounted with '-o dax').

A description of MAP_SYNC and MAP_SHARED_VALIDATE can be found at
https://patchwork.kernel.org/patch/10028151/

This patchset enables QEMU to use MAP_SYNC flag for memory-backend-file,
in order to guarantee the guest write persistence to backend files
supporting DAX.

A new auto on/off option 'sync' is added to memory-backend-file:
 - on:  try to pass MAP_SYNC to mmap(2); if MAP_SYNC is not supported or
'share=off', QEMU will abort
 - off: never pass MAP_SYNC to mmap(2)
 - auto (default): if MAP_SYNC is supported and 'share=on', work as if
'sync=on'; otherwise, work as if 'sync=off'

Changes in v4:
 * Add patch 1-3 to switch some functions to a single 'flags'
   parameters. (Michael S. Tsirkin)
 * v3 patch 1-3 become v4 patch 4-6.
 * Patch 4: move definitions of MAP_SYNC and MAP_SHARED_VALIDATE to a
   new header file under include/standard-headers/linux/. (Michael S. Tsirkin)
 * Patch 6: refine the description of the 'sync' option. (Michael S. Tsirkin)

Changes in v3:
 * Patch 1: add MAP_SHARED_VALIDATE in both sync=on and sync=auto
   cases, and add back the retry mechanism. MAP_SYNC will be ignored
   by Linux kernel 4.15 if MAP_SHARED_VALIDATE is missed.
 * Patch 1: define MAP_SYNC and MAP_SHARED_VALIDATE as 0 on non-Linux
   platforms in order to make qemu_ram_mmap() compile on those platforms.
 * Patch 2&3: include more information in error messages of
   memory-backend in hope to help user to identify the error.
   (Dr. David Alan Gilbert)
 * Patch 3: fix typo in the commit message. (Dr. David Alan Gilbert)

Changes in v2:
 * Add 'sync' option to control the use of MAP_SYNC. (Eduardo Habkost)
 * Remove the unnecessary set of MAP_SHARED_VALIDATE in some cases and
   the retry mechanism in qemu_ram_mmap(). (Michael S. Tsirkin)
 * Move OS dependent definitions of MAP_SYNC and MAP_SHARED_VALIDATE
   to osdep.h. (Michael S. Tsirkin)


Haozhong Zhang (6):
  util/mmap-alloc: switch qemu_ram_mmap() to 'flags' parameter
  exec: switch qemu_ram_alloc_from_{file,fd} to the 'flags' parameter
  memory: switch memory_region_init_ram_from_file() to 'flags' parameter
  util/mmap-alloc: support MAP_SYNC in qemu_ram_mmap()
  hostmem: add more information in error messages
  hostmem-file: add 'sync' option

 backends/hostmem-file.c   | 51 ---
 backends/hostmem.c| 11 +---
 docs/nvdimm.txt   | 20 +-
 exec.c| 15 ++-
 include/exec/memory.h | 36 +++--
 include/exec/ram_addr.h   | 29 ++--
 include/qemu/mmap-alloc.h | 23 +++-
 include/standard-headers/linux/mman.h | 42 +
 memory.c  |  8 +++---
 numa.c|  2 +-
 qemu-options.hx   | 22 ++-
 util/mmap-alloc.c | 31 ++---
 util/oslib-posix.c|  2 +-
 13 files changed, 261 insertions(+), 31 deletions(-)
 create mode 100644 include/standard-headers/linux/mman.h

-- 
2.14.1

[Qemu-devel] [PATCH v4 1/6] util/mmap-alloc: switch qemu_ram_mmap() to 'flags' parameter

[Haozhong Zhang]

As more flag parameters besides the existing 'shared' are going to be
added to qemu_ram_mmap(), let's switch 'shared' to a 'flags' parameter
in advance, so as to ease the further additions.

Signed-off-by: Haozhong Zhang 
Suggested-by: "Michael S. Tsirkin" 
---
 exec.c|  2 +-
 include/exec/memory.h |  3 +++
 include/qemu/mmap-alloc.h | 19 ++-
 util/mmap-alloc.c |  8 +---
 util/oslib-posix.c|  2 +-
 5 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/exec.c b/exec.c
index 629a508385..c0a5a52c4a 100644
--- a/exec.c
+++ b/exec.c
@@ -1653,7 +1653,7 @@ static void *file_ram_alloc(RAMBlock *block,
 }
 
 area = qemu_ram_mmap(fd, memory, block->mr->align,
- block->flags & RAM_SHARED);
+ (block->flags & RAM_SHARED) ? QEMU_RAM_SHARE : 0);
 if (area == MAP_FAILED) {
 error_setg_errno(errp, errno,
  "unable to map backing store for guest RAM");
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 07c5d6d597..4790cd9e13 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -455,6 +455,9 @@ void memory_region_init_resizeable_ram(MemoryRegion *mr,
uint64_t length,
void *host),
Error **errp);
+
+#define QEMU_RAM_SHARE  (1UL << 0)
+
 #ifdef __linux__
 /**
  * memory_region_init_ram_from_file:  Initialize RAM memory region with a
diff --git a/include/qemu/mmap-alloc.h b/include/qemu/mmap-alloc.h
index 50385e3f81..dc5e8b5efb 100644
--- a/include/qemu/mmap-alloc.h
+++ b/include/qemu/mmap-alloc.h
@@ -7,7 +7,24 @@ size_t qemu_fd_getpagesize(int fd);
 
 size_t qemu_mempath_getpagesize(const char *mem_path);
 
-void *qemu_ram_mmap(int fd, size_t size, size_t align, bool shared);
+/**
+ * qemu_ram_mmap: mmap the specified file or device.
+ *
+ * Parameters:
+ *  @fd: the file or the device to mmap
+ *  @size: the number of bytes to be mmaped
+ *  @align: if not zero, specify the alignment of the starting mapping address;
+ *  otherwise, the alignment in use will be determined by QEMU.
+ *  @flags: specifies additional properties of the mapping, which can be one or
+ *  bit-or of following values
+ *  - QEMU_RAM_SHARE: mmap with MAP_SHARED flag
+ *  Other bits are ignored.
+ *
+ * Return:
+ *  On success, return a pointer to the mapped area.
+ *  On failure, return MAP_FAILED.
+ */
+void *qemu_ram_mmap(int fd, size_t size, size_t align, uint64_t flags);
 
 void qemu_ram_munmap(void *ptr, size_t size);
 
diff --git a/util/mmap-alloc.c b/util/mmap-alloc.c
index 2fd8cbcc6f..cd95566800 100644
--- a/util/mmap-alloc.c
+++ b/util/mmap-alloc.c
@@ -13,6 +13,7 @@
 #include "qemu/osdep.h"
 #include "qemu/mmap-alloc.h"
 #include "qemu/host-utils.h"
+#include "exec/memory.h"
 
 #define HUGETLBFS_MAGIC   0x958458f6
 
@@ -73,7 +74,7 @@ size_t qemu_mempath_getpagesize(const char *mem_path)
 return getpagesize();
 }
 
-void *qemu_ram_mmap(int fd, size_t size, size_t align, bool shared)
+void *qemu_ram_mmap(int fd, size_t size, size_t align, uint64_t flags)
 {
 /*
  * Note: this always allocates at least one extra page of virtual address
@@ -90,11 +91,12 @@ void *qemu_ram_mmap(int fd, size_t size, size_t align, bool 
shared)
  * anonymous memory is OK.
  */
 int anonfd = fd == -1 || qemu_fd_getpagesize(fd) == getpagesize() ? -1 : 
fd;
-int flags = anonfd == -1 ? MAP_ANONYMOUS : MAP_NORESERVE;
-void *ptr = mmap(0, total, PROT_NONE, flags | MAP_PRIVATE, anonfd, 0);
+int mmap_flags = anonfd == -1 ? MAP_ANONYMOUS : MAP_NORESERVE;
+void *ptr = mmap(0, total, PROT_NONE, mmap_flags | MAP_PRIVATE, anonfd, 0);
 #else
 void *ptr = mmap(0, total, PROT_NONE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
 #endif
+bool shared = flags & QEMU_RAM_SHARE;
 size_t offset;
 void *ptr1;
 
diff --git a/util/oslib-posix.c b/util/oslib-posix.c
index 77369c92ce..2a78cfb67e 100644
--- a/util/oslib-posix.c
+++ b/util/oslib-posix.c
@@ -130,7 +130,7 @@ void *qemu_memalign(size_t alignment, size_t size)
 void *qemu_anon_ram_alloc(size_t size, uint64_t *alignment)
 {
 size_t align = QEMU_VMALLOC_ALIGN;
-void *ptr = qemu_ram_mmap(-1, size, align, false);
+void *ptr = qemu_ram_mmap(-1, size, align, 0);
 
 if (ptr == MAP_FAILED) {
 return NULL;
-- 
2.14.1

[Qemu-devel] [PATCH v4 3/6] memory: switch memory_region_init_ram_from_file() to 'flags' parameter

[Haozhong Zhang]

As more flag parameters besides the existing 'share' are going to be
added to memory_region_init_ram_from_file(), let's switch 'share' to
a 'flags' parameter in advance, so as to ease the further additions.

Signed-off-by: Haozhong Zhang 
---
 backends/hostmem-file.c | 3 ++-
 include/exec/memory.h   | 7 +--
 memory.c| 6 ++
 numa.c  | 2 +-
 4 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c
index e319ec1ad8..67ecfed895 100644
--- a/backends/hostmem-file.c
+++ b/backends/hostmem-file.c
@@ -59,7 +59,8 @@ file_backend_memory_alloc(HostMemoryBackend *backend, Error 
**errp)
 path = object_get_canonical_path(OBJECT(backend));
 memory_region_init_ram_from_file(>mr, OBJECT(backend),
  path,
- backend->size, fb->align, fb->share,
+ backend->size, fb->align,
+ fb->share ? QEMU_RAM_SHARE : 0,
  fb->mem_path, errp);
 g_free(path);
 }
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 4790cd9e13..6b547da6a3 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -470,7 +470,10 @@ void memory_region_init_resizeable_ram(MemoryRegion *mr,
  * @size: size of the region.
  * @align: alignment of the region base address; if 0, the default alignment
  * (getpagesize()) will be used.
- * @share: %true if memory must be mmaped with the MAP_SHARED flag
+ * @flags: specify properties of this memory region, which can be one or bit-or
+ * of following values:
+ * - QEMU_RAM_SHARE: memory must be mmaped with the MAP_SHARED flag
+ * Other bits are ignored.
  * @path: the path in which to allocate the RAM.
  * @errp: pointer to Error*, to store an error if it happens.
  *
@@ -482,7 +485,7 @@ void memory_region_init_ram_from_file(MemoryRegion *mr,
   const char *name,
   uint64_t size,
   uint64_t align,
-  bool share,
+  uint64_t flags,
   const char *path,
   Error **errp);
 
diff --git a/memory.c b/memory.c
index 1ac4ebcaca..a4f19a5d30 100644
--- a/memory.c
+++ b/memory.c
@@ -1571,7 +1571,7 @@ void memory_region_init_ram_from_file(MemoryRegion *mr,
   const char *name,
   uint64_t size,
   uint64_t align,
-  bool share,
+  uint64_t flags,
   const char *path,
   Error **errp)
 {
@@ -1580,9 +1580,7 @@ void memory_region_init_ram_from_file(MemoryRegion *mr,
 mr->terminates = true;
 mr->destructor = memory_region_destructor_ram;
 mr->align = align;
-mr->ram_block = qemu_ram_alloc_from_file(size, mr,
- share ? QEMU_RAM_SHARE : 0,
- path, errp);
+mr->ram_block = qemu_ram_alloc_from_file(size, mr, flags, path, errp);
 mr->dirty_log_mask = tcg_enabled() ? (1 << DIRTY_MEMORY_CODE) : 0;
 }
 
diff --git a/numa.c b/numa.c
index 83675a03f3..fa202a376d 100644
--- a/numa.c
+++ b/numa.c
@@ -456,7 +456,7 @@ static void allocate_system_memory_nonnuma(MemoryRegion 
*mr, Object *owner,
 if (mem_path) {
 #ifdef __linux__
 Error *err = NULL;
-memory_region_init_ram_from_file(mr, owner, name, ram_size, 0, false,
+memory_region_init_ram_from_file(mr, owner, name, ram_size, 0, 0,
  mem_path, );
 if (err) {
 error_report_err(err);
-- 
2.14.1

[Qemu-devel] [PATCH v4 6/6] hostmem-file: add 'sync' option

[Haozhong Zhang]

This option controls whether QEMU mmap(2) the memory backend file with
MAP_SYNC flag, which can fully guarantee the guest write persistence
to the backend, if MAP_SYNC flag is supported by the host kernel
(Linux kernel 4.15 and later) and the backend is a file supporting
DAX (e.g., file on ext4/xfs file system mounted with '-o dax').

It can take one of following values:
 - on:  try to pass MAP_SYNC to mmap(2); if MAP_SYNC is not supported or
'share=off', QEMU will abort
 - off: never pass MAP_SYNC to mmap(2)
 - auto (default): if MAP_SYNC is supported and 'share=on', work as if
'sync=on'; otherwise, work as if 'sync=off'

Signed-off-by: Haozhong Zhang 
Suggested-by: Eduardo Habkost 
Reviewed-by: Michael S. Tsirkin 
---
 backends/hostmem-file.c | 41 -
 docs/nvdimm.txt | 20 +++-
 qemu-options.hx | 22 +-
 3 files changed, 80 insertions(+), 3 deletions(-)

diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c
index df06b547a6..ade80d76f1 100644
--- a/backends/hostmem-file.c
+++ b/backends/hostmem-file.c
@@ -15,6 +15,7 @@
 #include "sysemu/hostmem.h"
 #include "sysemu/sysemu.h"
 #include "qom/object_interfaces.h"
+#include "qapi-visit.h"
 
 /* hostmem-file.c */
 /**
@@ -35,6 +36,7 @@ struct HostMemoryBackendFile {
 bool discard_data;
 char *mem_path;
 uint64_t align;
+OnOffAuto sync;
 };
 
 static void
@@ -60,7 +62,8 @@ file_backend_memory_alloc(HostMemoryBackend *backend, Error 
**errp)
 memory_region_init_ram_from_file(>mr, OBJECT(backend),
  path,
  backend->size, fb->align,
- fb->share ? QEMU_RAM_SHARE : 0,
+ (fb->share ? QEMU_RAM_SHARE : 0) |
+ qemu_ram_sync_flags(fb->sync),
  fb->mem_path, errp);
 g_free(path);
 }
@@ -154,6 +157,39 @@ static void file_memory_backend_set_align(Object *o, 
Visitor *v,
 error_propagate(errp, local_err);
 }
 
+static void file_memory_backend_get_sync(
+Object *obj, Visitor *v, const char *name, void *opaque, Error **errp)
+{
+HostMemoryBackendFile *fb = MEMORY_BACKEND_FILE(obj);
+OnOffAuto value = fb->sync;
+
+visit_type_OnOffAuto(v, name, , errp);
+}
+
+static void file_memory_backend_set_sync(
+Object *obj, Visitor *v, const char *name, void *opaque, Error **errp)
+{
+HostMemoryBackend *backend = MEMORY_BACKEND(obj);
+HostMemoryBackendFile *fb = MEMORY_BACKEND_FILE(obj);
+Error *local_err = NULL;
+OnOffAuto value;
+
+if (host_memory_backend_mr_inited(backend)) {
+error_setg(_err, "cannot change property '%s' of %s '%s'",
+   name, object_get_typename(obj), backend->id);
+goto out;
+}
+
+visit_type_OnOffAuto(v, name, , _err);
+if (local_err) {
+goto out;
+}
+fb->sync = value;
+
+ out:
+error_propagate(errp, local_err);
+}
+
 static void file_backend_unparent(Object *obj)
 {
 HostMemoryBackend *backend = MEMORY_BACKEND(obj);
@@ -188,6 +224,9 @@ file_backend_class_init(ObjectClass *oc, void *data)
 file_memory_backend_get_align,
 file_memory_backend_set_align,
 NULL, NULL, _abort);
+object_class_property_add(oc, "sync", "OnOffAuto",
+file_memory_backend_get_sync, file_memory_backend_set_sync,
+NULL, NULL, _abort);
 }
 
 static void file_backend_instance_finalize(Object *o)
diff --git a/docs/nvdimm.txt b/docs/nvdimm.txt
index e903d8bb09..5e9cee5f5e 100644
--- a/docs/nvdimm.txt
+++ b/docs/nvdimm.txt
@@ -142,11 +142,29 @@ backend of vNVDIMM:
 Guest Data Persistence
 --
 
+vNVDIMM is designed and implemented to guarantee the guest data
+persistence on the backends even on the host crash and power
+failures. However, there are still some requirements and limitations
+as explained below.
+
 Though QEMU supports multiple types of vNVDIMM backends on Linux,
-currently the only one that can guarantee the guest write persistence
+if MAP_SYNC is not supported by the host kernel and the backends,
+the only backend that can guarantee the guest write persistence
 is the device DAX on the real NVDIMM device (e.g., /dev/dax0.0), to
 which all guest access do not involve any host-side kernel cache.
 
+mmap(2) flag MAP_SYNC is added since Linux kernel 4.15. On such
+systems, QEMU can mmap(2) the backend with MAP_SYNC, which can
+guarantee the guest write persistence to vNVDIMM. Besides the host
+kernel support, enabling MAP_SYNC in QEMU also requires:
+
+ - the backend is a file supporting DAX, e.g., a file on an ext4 or
+   xfs file system mounted with '-o dax',
+
+ - 'sync' option of memory-backend-file is not 'off', and
+
+ - 'share' option of memory-backend-file is 'on'.
+
 When using other types of backends, it's 

[Qemu-devel] [PATCH] Add a git-publish configuration file

[Fam Zheng]

git-publish [1] is a convenient tool to send patches and has been
popular among QEMU developers.  Recently it has been made available in
Fedora official repo thanks to Stefan's work.

One nice feature of the tool is a per-project configuration with
profiles, especially in which the cccmd option is a handy method to
create the Cc list.

[1]: https://github.com/stefanha/git-publish

Signed-off-by: Fam Zheng 
---
 .gitpublish | 57 +
 1 file changed, 57 insertions(+)
 create mode 100644 .gitpublish

diff --git a/.gitpublish b/.gitpublish
new file mode 100644
index 00..2099c1520f
--- /dev/null
+++ b/.gitpublish
@@ -0,0 +1,57 @@
+#
+# Common git-publish profiles that can be used to send patches to QEMU 
upstream.
+#
+# See https://github.com/stefanha/git-publish for more information
+#
+[gitpublishprofile "qemu"]
+base = master
+prefix = PATCH
+to = qemu-devel@nongnu.org
+cccmd = scripts/get_maintainer.pl --noroles --norolestats --nogit 
--nogit-fallback 2>/dev/null
+
+[gitpublishprofile "qemu-rfc"]
+base = master
+prefix = RFC PATCH
+to = qemu-devel@nongnu.org
+cccmd = scripts/get_maintainer.pl --noroles --norolestats --nogit 
--nogit-fallback 2>/dev/null
+
+[gitpublishprofile "qemu-stable"]
+base = master
+prefix = PATCH
+to = qemu-devel@nongnu.org
+cc = qemu-sta...@nongnu.org
+cccmd = scripts/get_maintainer.pl --noroles --norolestats --nogit 
--nogit-fallback 2>/dev/null
+
+[gitpublishprofile "qemu-trivial"]
+base = master
+prefix = PATCH
+to = qemu-devel@nongnu.org
+cccmd = scripts/get_maintainer.pl --noroles --norolestats --nogit 
--nogit-fallback 2>/dev/null
+
+[gitpublishprofile "qemu-block"]
+base = master
+prefix = PATCH
+to = qemu-devel@nongnu.org
+cc = qemu-bl...@nongnu.org
+cccmd = scripts/get_maintainer.pl --noroles --norolestats --nogit 
--nogit-fallback 2>/dev/null
+
+[gitpublishprofile "qemu-arm"]
+base = master
+prefix = PATCH
+to = qemu-devel@nongnu.org
+cc = qemu-...@nongnu.org
+cccmd = scripts/get_maintainer.pl --noroles --norolestats --nogit 
--nogit-fallback 2>/dev/null
+
+[gitpublishprofile "qemu-s390"]
+base = master
+prefix = PATCH
+to = qemu-devel@nongnu.org
+cc = qemu-s...@nongnu.org
+cccmd = scripts/get_maintainer.pl --noroles --norolestats --nogit 
--nogit-fallback 2>/dev/null
+
+[gitpublishprofile "qemu-ppc"]
+base = master
+prefix = PATCH
+to = qemu-devel@nongnu.org
+cc = qemu-...@nongnu.org
+cccmd = scripts/get_maintainer.pl --noroles --norolestats --nogit 
--nogit-fallback 2>/dev/null
-- 
2.14.3

Re: [Qemu-devel] MTTCG External Halt

[Paolo Bonzini]

On 30/01/2018 18:56, Alistair Francis wrote:
> 
> I don't have a good solution though, as setting CPU_INTERRUPT_RESET
> doesn't help (that isn't handled while we are halted) and
> async_run_on_cpu()/run_on_cpu() doesn't reliably reset the CPU when we
> want.
> 
> I've ever tried pausing all CPUs before reseting the CPU and them
> resuming them all but that doesn't seem to to work either.

async_safe_run_on_cpu would be like async_run_on_cpu, except that it
takes care of stopping all other CPUs while the function runs.

> Is there
> anything I'm missing? Is there no reliable way to reset a CPU?

What do you mean by reliable?  Executing no instruction after the one
you were at?

Paolo

Re: [Qemu-devel] [PATCH V4 0/7] CAN bus support for QEMU (SJA1000 PCI so far)

[Deniz Eren]

Hi Paolo,



Thank you for the correction! Greatly appreciated and it worked.



I tested all combinations of Linux host using virtual Socket-CAN and pcm3680 
and mioe3680 client QEmu Linux environments using Linux Socket-CAN drivers, 
sending and receiving from each-other (all combinations; host-to-client, 
client-to-client, etc).


All tests passed!



Details:



Setup virtual Socket-CAN from host Linux system:

    $ sudo ip link add dev vcan0 type vcan
    $ sudo ip link set up vcan0
    $ sudo ip link add dev vcan1 type vcan
    $ sudo ip link set up vcan1

    $ sudo ip link set vcan0 txqueuelen 15
    $ sudo ip link set vcan1 txqueuelen 15


Starting 2 x QEmu sessions from host Linux; one for pcm3680 and other for 
mioe3680:

    $ ./qemu-local/bin/qemu-system-i386 -hda sdd2gb-uno1483-16.04-2.0-dev.img -boot 
d -k en-us -object can-bus,id=canbus0 -object can-bus,id=canbus1 -object 
can-host-socketcan,id=canhost0,canbus=canbus0,if=vcan0 -object 
can-host-socketcan,id=canhost1,canbus=canbus1,if=vcan1 -device 
mioe3680_pci,canbus0=canbus0,canbus1=canbus1 -m size=2048 -netdev user,id=user.0 
-device e1000,netdev=user.0 -redir tcp:5022::22 -enable-kvm &

    $ ./qemu-local/bin/qemu-system-i386 -hda sdd2gb-uno1483-16.04-2.0-dev-copy.img 
-boot d -k en-us -object can-bus,id=canbus0 -object can-bus,id=canbus1 -object 
can-host-socketcan,id=canhost0,canbus=canbus0,if=vcan0 -object 
can-host-socketcan,id=canhost1,canbus=canbus1,if=vcan1 -device 
pcm3680_pci,canbus0=canbus0,canbus1=canbus1 -m size=2048 -netdev user,id=user.0 
-device e1000,netdev=user.0 -redir tcp:6022::22 -enable-kvm &

    
Login to client QEmu instances and setup CAN networks:

    $ ssh -Yp5022 user@localhost

    $ sudo ip link set can0 type can bitrate 25
    $ sudo ip link set can1 type can bitrate 25
    $ sudo ip link set up can0
    $ sudo ip link set up can1
    $ sudo ip link set can0 txqueuelen 15
    $ sudo ip link set can1 txqueuelen 15

    $ ssh -Yp6022 user@localhost

    $ ... similarly ...

Then tried all combinations of "candump vcan0/1" from host and "candump can0/1" 
from clients for transmission and reception to and from host to client and client to client.

user@:~$ candump can1
  can1  123   [8]  11 22 33 44 55 66 77 88
  can1  123   [8]  11 22 33 44 55 66 77 88
  can1  123   [8]  11 22 33 44 55 66 77 88

host:$ candump vcan0
  vcan0  123   [8]  11 22 33 44 55 66 77 88
  vcan0  123   [8]  11 22 33 44 55 66 77 88
  vcan0  123   [8]  11 22 33 44 55 66 77 88
  vcan0  123   [8]  11 22 33 44 55 66 77 88

All successful.







Best regards,
Deniz

On Jan 31, 2018, at 12:10 PM, Paolo Bonzini  wrote:


On 30/01/2018 20:08, Paolo Bonzini wrote:

On 30/01/2018 19:13, Deniz Eren wrote:
Hi Pavel, Paolo,


I tried to rerun my environment to test however it seems the interface has 
changed a little and my standard program options cause complaints. 
Unfortunately I don’t have too much time to dig through at the moment.


My standard startup command is:


$ ./qemu-local/bin/qemu-system-i386 -hda sdd2gb-uno1483-16.04-2.0-dev.img -boot d 
-k en-us -device 
mioe3680_pci,canbus1=canbus0,host1=vcan0,canbus2=canbus1,host2=vcan1 -m size=2048 
-netdev user,id=user.0 -device e1000,netdev=user.0 -redir tcp:5022::22 -enable-kvm 
&


Yep, it's now like this:


./qemu-local/bin/qemu-system-i386 \
-hda sdd2gb-uno1483-16.04-2.0-dev.img -boot d -k en-us \
-object can-bus,id=canbus0 \
-object can-bus,id=canbus1 \
-object can-host-socketcan,id=canhost0,canbus=canbus0,ifname=vcan0 \
-object can-host-socketcan,id=canhost1,canbus=canbus1,ifname=vcan1 \
-device mioe3680_pci,canbus0=canbus0,canbus1=canbus1 \
-m size=2048 -netdev user,id=user.0 -device e1000,netdev=user.0 \
-redir tcp:5022::22 -enable-kvm

Sorry, all "ifname" are "if".

Paolo


Thanks,


Paolo








Best regards,
Deniz


Sent from my iPhone


Deniz Eren
+61 400 307 762


On 31 Jan 2018, at 9:12 am, Pavel Pisa  wrote:


Hello Paolo,


thanks much for conversion to acceptable QOM model.


On Tuesday 30 of January 2018 15:15:22 Paolo Bonzini wrote:
On 25/01/2018 22:33, Pavel Pisa wrote:
Hello Paolo,


thanks for suggestions. I understand and fully agree with your
request to switch to QOM. I have succeed with that for CAN devices
some time ago. It worth to be done for the rest of the objects
but I fear that I do not find time to complete QOMification
in reasonable future. Contributions/suggestions from other
are welcomed. I can look for students for GSoC at our university
or under other funding.


Please take a look at branch can-pci-qom of github.com/bonzini/qemu.git.
Apart from QOMification of the backend include, I simplified the IRQ
handling in can_kvaser_pci (fixing bugs too I think), and removed an
unnecessary mutex. I also moved the files to net/can and hw/net/can so
that in the future Jason (networking maintainer) can take care of pull
requests.


I might have broken something, and the top commit in particular is
completely 

[Qemu-devel] [PATCH] virtio-gpu: disallow vIOMMU

[Peter Xu]

virtio-gpu has special code path that bypassed vIOMMU protection.  So
for now let's disable iommu_platform for the device until we fully
support that (if needed).

After the patch, both virtio-vga and virtio-gpu won't allow to boot with
iommu_platform parameter set.

CC: Gerd Hoffmann 
Signed-off-by: Peter Xu 
---
 hw/display/virtio-gpu-pci.c | 8 +++-
 hw/display/virtio-gpu.c | 5 +
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/hw/display/virtio-gpu-pci.c b/hw/display/virtio-gpu-pci.c
index ef92c4ad6f..3519dc80b1 100644
--- a/hw/display/virtio-gpu-pci.c
+++ b/hw/display/virtio-gpu-pci.c
@@ -28,10 +28,16 @@ static void virtio_gpu_pci_realize(VirtIOPCIProxy 
*vpci_dev, Error **errp)
 VirtIOGPU *g = >vdev;
 DeviceState *vdev = DEVICE(>vdev);
 int i;
+Error *local_error = NULL;
 
 qdev_set_parent_bus(vdev, BUS(_dev->bus));
 virtio_pci_force_virtio_1(vpci_dev);
-object_property_set_bool(OBJECT(vdev), true, "realized", errp);
+object_property_set_bool(OBJECT(vdev), true, "realized", _error);
+
+if (local_error) {
+error_propagate(errp, local_error);
+return;
+}
 
 for (i = 0; i < g->conf.max_outputs; i++) {
 object_property_set_link(OBJECT(g->scanout[i].con),
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 274e365713..6658f6c6a6 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1173,6 +1173,11 @@ static void virtio_gpu_device_realize(DeviceState *qdev, 
Error **errp)
 Error *local_err = NULL;
 int i;
 
+if (virtio_host_has_feature(vdev, VIRTIO_F_IOMMU_PLATFORM)) {
+error_setg(errp, "virtio-gpu does not support vIOMMU yet");
+return;
+}
+
 if (g->conf.max_outputs > VIRTIO_GPU_MAX_SCANOUTS) {
 error_setg(errp, "invalid max_outputs > %d", VIRTIO_GPU_MAX_SCANOUTS);
 return;
-- 
2.14.3

[Qemu-devel] [PATCH v2] docs: Add docs/devel/testing.rst

[Fam Zheng]

To make our efforts on QEMU testing easier to consume by contributors,
let's add a document. For example, Patchew reports build errors on
patches that should be relatively easy to reproduce with a few steps, and
it is much nicer if there is such a documentation that it can refer to.

This focuses on how to run existing tests and how to write new test
cases, without going into the frameworks themselves.

The VM based testing section is moved from tests/vm/README which now
is a single line pointing to the new doc.

Signed-off-by: Fam Zheng 

---

v2: Fix spelling errors and improve wordings. [Stefan, Eric, Thomas]
Example test name "test-foo -> foo-test". The mass renaming will be
done in another series. [Thomas, Eric]
Document how to debug unit tests and qtests. [Eric]
Document group permission setup for docker, and the privilege risks.
[Alex]
Update tests/vm/README.
---
 docs/devel/testing.rst | 486 +
 tests/vm/README|  90 +
 2 files changed, 487 insertions(+), 89 deletions(-)
 create mode 100644 docs/devel/testing.rst

diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
new file mode 100644
index 00..795df60dcd
--- /dev/null
+++ b/docs/devel/testing.rst
@@ -0,0 +1,486 @@
+===
+Testing in QEMU
+===
+
+This document describes the testing infrastructure in QEMU.
+
+Testing with "make check"
+=
+
+The "make check" testing family includes most of the C based tests in QEMU. For
+a quick help, run ``make check-help`` from the source tree.
+
+The usual way to run these tests is:
+
+.. code::
+
+  make check
+
+which includes QAPI schema tests, unit tests, and QTests. Different sub-types
+of "make check" testings will be explained below.
+
+Before running tests, it is best to build QEMU programs first. Some tests
+expect the executables to exist and will fail with obscure messages if they
+cannot find them.
+
+Unit tests
+--
+
+Unit tests, which can be invoked with ``make check-unit``, are simple C tests
+that typically link to individual QEMU object files and exercise them by
+calling exported functions.
+
+If you are writing new code in QEMU, consider adding a unit test, especially
+for utility modules that are relatively stateless or have few dependencies. To
+add a new unit test:
+
+1. Create a new source file. For example, ``tests/foo-test.c``.
+
+2. Write the test. Normally you would include the header file which exports
+   the module API, then verify the interface behaves as expected from your
+   test. The test code should be organized with the glib testing framework.
+   Copying and modifying an existing test is usually a good idea.
+
+3. Add the test to ``tests/Makefile.include``. First, name the unit test
+   program and add it to ``$(check-unit-y)``; then add a rule to build the
+   executable. Optionally, you can add a magical variable to support ``gcov``.
+   For example:
+
+.. code::
+
+  check-unit-y += tests/foo-test$(EXESUF)
+  tests/foo-test$(EXESUF): tests/foo-test.o $(test-util-obj-y)
+  ...
+  gcov-files-foo-test-y = util/foo.c
+
+Since unit tests don't require environment variables, the simplest way to debug
+a unit test failure is often directly invoking it or even running it under
+``gdb``. However there can still be differences in behavior between ``make``
+invocations and your manual run, due to ``$MALLOC_PERTURB_`` environment
+variable (which affects memory reclaimation and catches invalid pointers
+better) and gtester options. If necessary, you can run
+
+.. code::
+  make check-unit V=1
+
+and copy the actual command line which executes the unit test, then run
+it from the command line.
+
+QTest
+-
+
+QTest is a device emulation testing framework.  It can be very useful to test
+device models; it could also control certain aspects of QEMU (such as virtual
+clock stepping), with a special purpose "qtest" protocol.  Refer to the
+documentation in ``qtest.c`` for more details of the protocol.
+
+QTest cases can be executed with
+
+.. code::
+
+   make check-qtest
+
+The QTest library is implemented by ``tests/libqtest.c`` and the API is defined
+in ``tests/libqtest.h``.
+
+Consider adding a new QTest case when you are introducing a new virtual
+hardware, or extending one if you are adding functionalities to an existing
+virtual device.
+
+On top of libqtest, a higher level library, ``libqos``, was created to
+encapsulate common tasks of device drivers, such as memory management and
+communicating with system buses or devices. Many virtual device tests use
+libqos instead of directly calling into libqos.
+
+Steps to add a new QTest case are:
+
+1. Create a new source file for the test. (More than one file can be added as
+   necessary.) For example, ``tests/test-foo-device.c``.
+
+2. Write the test code with the glib and libqtest/libqos API. See also existing
+   tests and the library headers for reference.

Re: [Qemu-devel] [PATCH] docs: Add docs/devel/testing.rst

[Fam Zheng]

On Mon, Jan 29, 2018 at 6:36 PM, Alex Bennée  wrote:
> Fam Zheng  writes:
>> +Prerequisites
>> +-
>> +
>> +Install "docker" with the system package manager and start the Docker 
>> service
>> +on your development machine, then make sure you have the privilege to run
>> +Docker commands. Typically it means setting up passwordless ``sudo docker``
>> +command or login as root.
>
> The third option (which I run) is using group permissions so you can add
> users to the docker group and make the socket group accessible via the
> daemon.
>
> It should be pointed out that both the sudo and group methods do open up
> your machine to being exploited via docker's ability to bind mount
> stuff. That is to say it's fine for developers on their own machine but
> you might not want to do that on shared servers.

Thanks, Alex, very good I've added that paragraph!

Fam

Re: [Qemu-devel] [PATCH] docs: Add docs/devel/testing.rst

[Fam Zheng]

On Mon, Jan 29, 2018 at 7:04 PM, Stefan Hajnoczi  wrote:
> On Mon, Jan 29, 2018 at 11:31:33AM +0800, Fam Zheng wrote:
>
> Thanks for writing this!
>
> I have only reviewed some parts in detail.

Thanks for the review! I've made all the fixes (except for the buses
spelling. :).

Fam

Re: [Qemu-devel] [PATCH] docs: Add docs/devel/testing.rst

[Fam Zheng]

On Mon, Jan 29, 2018 at 10:51 PM, Eric Blake  wrote:
> On 01/28/2018 09:31 PM, Fam Zheng wrote:
>> To make our efforts on QEMU testing easier to consume by contributors,
>> let's add a document. For example, Patchew reports build errors on
>> patches that should be relativly easy to reproduce with a few steps, and
>
> s/relativly/relatively/
>
>> it is much nicer if there is such a documentation that it can refer to.
>>
>> This focues on how to run existing tests and how to write new test
>
> s/focues/focuses/
>
>> cases, without going into the frameworks themselves.
>>
>> Signed-off-by: Fam Zheng 
>>
>> ---
>>
>
> I'll try not to repeat comments made by others...
>
>> +This document describes the testing infrastructure in QEMU.
>> +
>> +"Make check" testings
>> +=
>
> s/testings/tests/, or 'Testing with "make check"'

Sounds good, it will put "make" back to lower case again. :)

>
>> +
>> +The "make check" testing family includes most of the C based tests in QEMU. 
>> For
>> +a quick help, run ``make check-help`` from the source tree.
>> +
>> +The usual way to run these tests is:
>> +
>> +.. code::
>> +
>> +  make check
>> +
>> +which includes QAPI schema tests, unit tests, and QTests. Different 
>> sub-types
>> +of "make check" testings will be explained below.
>
> s/testings/tests/
>
>> +
>> +Before running tests, it is best to build QEMU programs first. Some tests
>> +expect the executables to exist and will fail with obscure messages if 
>> cannot
>> +find them.
>
> Should we fix 'make check' to depend on 'make all', so that we don't
> have to require this?

Maybe. We should try.

>
>> +
>> +Unit tests
>> +--
>> +
>> +Unit tests, which can be invoked with ``make check-unit``, are simple C 
>> tests
>> +that typically link to individual QEMU objects and exercise them by calling
>> +into the modules.
>> +
>> +If you are writing new code in QEMU, consider adding a unit test, especially
>> +for utility modules that are relatively stateless or have few dependencies. 
>> To
>> +add a new unit test:
>> +
>> +1. Create a new source file. For example, ``tests/test-foo.c``.
>> +
>> +2. Write the test. Normally you would include the headers file which exports
>> +   the module API, then verify the interface behaves as expected from your
>> +   test. The test code should be organized with the glib testing framework.
>> +   Copy and modify an existing test is usually a good idea.
>> +
>> +3. Add the test to ``tests/Makefile.include``. First, name the unit test
>> +   program and add it to ``$(check-unit-y)``; then add a rule to build the
>> +   executable. Optionally, you can add a magical variable to support 
>> ``gcov``.
>> +   For example:
>> +
>> +.. code::
>> +
>> +  check-unit-y += tests/test-foo$(EXESUF)
>> +  tests/test-foo$(EXESUF): tests/test-foo.o $(test-util-obj-y)
>> +  ...
>> +  gcov-files-test-foo-y = util/foo.c
>
> Is it worth documenting that you can often run 'gdb ./test-foo' after
> the fact for a failing test?  (Most unit tests don't require any magic
> environment variables to be set)

Good point!

I'll also add a paragraph about MALLOC_PERTURB_ then.

>
>> +
>> +QTest
>> +-
>> +
>> +QTest is a testing framework that simplifies starting QEMU and interacting 
>> with
>> +the virtual machine just like a guest kernel does. It can be very useful to
>> +test hardware emulation, for example; it could also control certain aspects 
>> of
>> +QEMU (such as virtual clock stepping), with a specially purposed "qtest"
>> +protocol. Refer to the documentation in ``qtest.c`` file for more details of
>> +the protocol.
>> +
>> +QTest cases can be executed with
>> +
>> +.. code::
>> +
>> +   make check-qtest
>> +
>> +The QTest library is implemented by ``tests/libqtest.c`` and the API is 
>> defined
>> +in ``tests/libqtest.h``.
>> +
>> +Consider adding a new QTest case when you are introducing a new virtual
>> +hardware, or extending one if you are adding functionalities to an existing
>> +virtual device.
>> +
>> +On top of libqtest, a higher level library, ``libqos``, was created to
>> +encapsulate common tasks of device drivers, such as memory management and
>> +communicating with system buses or devices. Many virtual device tests use
>> +libqos instead of directly calling into libqos.
>> +
>> +Steps to add a new QTest case are:
>> +
>> +1. Create a new source file for the test. (More than one file can be added 
>> as
>> +   necessary.) For example, ``tests/test-foo-device.c``.  2. Write the test
>> +   code with the glib and libqtest/libqos API. See also existing tests and 
>> the
>> +   library headers for reference.
>> +
>> +3. Register the new test in ``tests/Makefile.include``. Add the test 
>> executable
>> +   name to an appropriate ``check-qtest-*-y`` variable. For example:
>> +
>> +   ``check-qtest-generic-y = tests/test-foo-device$(EXESUF)``
>> +
>> +4. Add object dependencies of the executable in the Makefile, including the
>> +   

Re: [Qemu-devel] [PATCH V4 0/7] CAN bus support for QEMU (SJA1000 PCI so far)

[Deniz Eren]

Hi Pavel, Paolo,

I tried to rerun my environment to test however it seems the interface has 
changed a little and my standard program options cause complaints. 
Unfortunately I don’t have too much time to dig through at the moment.

My standard startup command is:

$ ./qemu-local/bin/qemu-system-i386 -hda sdd2gb-uno1483-16.04-2.0-dev.img -boot 
d -k en-us -device 
mioe3680_pci,canbus1=canbus0,host1=vcan0,canbus2=canbus1,host2=vcan1 -m 
size=2048 -netdev user,id=user.0 -device e1000,netdev=user.0 -redir 
tcp:5022::22 -enable-kvm &



Best regards,
Deniz

Sent from my iPhone

Deniz Eren
+61 400 307 762

> On 31 Jan 2018, at 9:12 am, Pavel Pisa  wrote:
> 
> Hello Paolo,
> 
> thanks much for conversion to acceptable QOM model.
> 
>> On Tuesday 30 of January 2018 15:15:22 Paolo Bonzini wrote:
>>> On 25/01/2018 22:33, Pavel Pisa wrote:
>>> Hello Paolo,
>>> 
>>> thanks for suggestions. I understand and fully agree with your
>>> request to switch to QOM. I have succeed with that for CAN devices
>>> some time ago. It worth to be done for the rest of the objects
>>> but I fear that I do not find time to complete QOMification
>>> in reasonable future. Contributions/suggestions from other
>>> are welcomed. I can look for students for GSoC at our university
>>> or under other funding.
>> 
>> Please take a look at branch can-pci-qom of github.com/bonzini/qemu.git.
>> Apart from QOMification of the backend include, I simplified the IRQ
>> handling in can_kvaser_pci (fixing bugs too I think), and removed an
>> unnecessary mutex.  I also moved the files to net/can and hw/net/can so
>> that in the future Jason (networking maintainer) can take care of pull
>> requests.
>> 
>> I might have broken something, and the top commit in particular is
>> completely untested.
> 
> I have run basic test with Linux kernel on both sides
> for one kavser_pci card on guest side and vcan (no real interface)
> on host side.
> 
> Mesages exchange tests passed and looks OK.
> 
> I have used next parameters
> 
>  -object can-bus,id=canbus0 \
>  -device kvaser_pci,canbus=canbus0 \
>  -object can-host-socketcan,if=can0,canbus=canbus0,id=canbus0-socketcan
> 
> The id parameter is required for "can-host-socketcan" object.
> Else next error is printed
> 
>  qemu-system-x86_64: -object can-host-socketcan,if=can0,canbus=canbus0: 
> Parameter 'id' is missing
> 
> If "-object can-bus,id=canbus0" is missing then next error is reported
> 
>  qemu-system-x86_64: -object 
> can-host-socketcan,if=can0,canbus=canbus0,id=canbus0-socketcan: Device 
> 'canbus0' not found
> 
> I have inspected through monitor the state of objects
> 
>  (qemu) qom-list /objects
>  canbus0-socketcan (child)
>  type (string)
>  canbus0 (child)
> 
>  (qemu) info qom-tree
>  /machine (pc-i440fx-2.12-machine)
>...
>/peripheral-anon (container)
>  /device[1] (kvaser_pci)
>/bus master[0] (qemu:memory-region)
>/kvaser_pci-xilinx[0] (qemu:memory-region)
>/kvaser_pci-s5920[0] (qemu:memory-region)
>/kvaser_pci-sja[0] (qemu:memory-region)
>/bus master container[0] (qemu:memory-region)
>...
> 
> 
>  (qemu) qom-list /objects
>  canbus0-socketcan (child)
>  type (string)
>  canbus0 (child)
> 
>  (qemu) qom-list /machine/peripheral-anon/device[1]
>  bus master container[0] (child)
>  canbus (link)
>  rombar (uint32)
>  hotpluggable (bool)
>  x-pcie-lnksta-dllla (bool)
>  kvaser_pci-sja[0] (child)
>  multifunction (bool)
>  hotplugged (bool)
>  parent_bus (link)
>  romfile (str)
>  kvaser_pci-s5920[0] (child)
>  x-pcie-extcap-init (bool)
>  command_serr_enable (bool)
>  addr (int32)
>  type (string)
>  legacy-addr (str)
>  kvaser_pci-xilinx[0] (child)
>  realized (bool)
>  bus master[0] (child)
> 
> From the user point of view, it would be nice if "can-bus"
> can be populated when required automatically.
> 
> I am not sure, but may it be that it would worth to
> push can-bus objects under some category/specific
> container. The path /objects is quite wide.
> Into something like /object/can-bus or /net/can.
> 
> But generally thanks much, the progress you have made
> in one day is really great. I hope that others check
> your branch. I have pushed your unmodified version into
> "can-pci-qom" branch of my repo
> 
>  https://gitlab.fel.cvut.cz/canbus/qemu-canbus/tree/can-pci-qom
> 
> It would be great if others can check that everything
> works in their setup. I think that then it can be pushed
> into mainline and some usability improvements can be
> done/experiment with later.
> 
> Thanks much,
> 
> 
>Pavel Pisa

[Qemu-devel] [PATCH] pc: correct misspelled CPU model-id for pc 2.2

[Wang Xin]

Signed-off-by: Wang Xin 

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index bb49165..635c8b2 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -617,7 +617,7 @@ bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
 
 #define PC_COMPAT_2_2 \
 HW_COMPAT_2_2 \
-PC_CPU_MODEL_IDS("2.3.0") \
+PC_CPU_MODEL_IDS("2.2.0") \
 {\
 .driver = "kvm64" "-" TYPE_X86_CPU,\
 .property = "vme",\
-- 
2.8.1.windows.1

[Qemu-devel] [Bug 1746394] [NEW] No provider of glEGLImageTargetTexture2DOES found with NVIDIA proprietary driver

[Jeff]

Public bug reported:

https://github.com/anholt/libepoxy/issues/148

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  No provider of glEGLImageTargetTexture2DOES found with NVIDIA
  proprietary driver

Status in QEMU:
  New

Bug description:
  https://github.com/anholt/libepoxy/issues/148

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

Re: [Qemu-devel] [PATCH V4 0/7] CAN bus support for QEMU (SJA1000 PCI so far)

[Paolo Bonzini]

On 30/01/2018 20:08, Paolo Bonzini wrote:
> On 30/01/2018 19:13, Deniz Eren wrote:
>> Hi Pavel, Paolo,
>>
>> I tried to rerun my environment to test however it seems the interface has 
>> changed a little and my standard program options cause complaints. 
>> Unfortunately I don’t have too much time to dig through at the moment.
>>
>> My standard startup command is:
>>
>> $ ./qemu-local/bin/qemu-system-i386 -hda sdd2gb-uno1483-16.04-2.0-dev.img 
>> -boot d -k en-us -device 
>> mioe3680_pci,canbus1=canbus0,host1=vcan0,canbus2=canbus1,host2=vcan1 -m 
>> size=2048 -netdev user,id=user.0 -device e1000,netdev=user.0 -redir 
>> tcp:5022::22 -enable-kvm &
> 
> Yep, it's now like this:
> 
> ./qemu-local/bin/qemu-system-i386 \
>   -hda sdd2gb-uno1483-16.04-2.0-dev.img -boot d -k en-us \
>   -object can-bus,id=canbus0 \
>   -object can-bus,id=canbus1 \
>   -object can-host-socketcan,id=canhost0,canbus=canbus0,ifname=vcan0 \
>   -object can-host-socketcan,id=canhost1,canbus=canbus1,ifname=vcan1 \
>   -device mioe3680_pci,canbus0=canbus0,canbus1=canbus1 \
>   -m size=2048 -netdev user,id=user.0 -device e1000,netdev=user.0 \
>   -redir tcp:5022::22 -enable-kvm

Sorry, all "ifname" are "if".

Paolo

> Thanks,
> 
> Paolo
> 
>>
>>
>>
>> Best regards,
>> Deniz
>>
>> Sent from my iPhone
>>
>> Deniz Eren
>> +61 400 307 762
>>
>>> On 31 Jan 2018, at 9:12 am, Pavel Pisa  wrote:
>>>
>>> Hello Paolo,
>>>
>>> thanks much for conversion to acceptable QOM model.
>>>
 On Tuesday 30 of January 2018 15:15:22 Paolo Bonzini wrote:
> On 25/01/2018 22:33, Pavel Pisa wrote:
> Hello Paolo,
>
> thanks for suggestions. I understand and fully agree with your
> request to switch to QOM. I have succeed with that for CAN devices
> some time ago. It worth to be done for the rest of the objects
> but I fear that I do not find time to complete QOMification
> in reasonable future. Contributions/suggestions from other
> are welcomed. I can look for students for GSoC at our university
> or under other funding.

 Please take a look at branch can-pci-qom of github.com/bonzini/qemu.git.
 Apart from QOMification of the backend include, I simplified the IRQ
 handling in can_kvaser_pci (fixing bugs too I think), and removed an
 unnecessary mutex.  I also moved the files to net/can and hw/net/can so
 that in the future Jason (networking maintainer) can take care of pull
 requests.

 I might have broken something, and the top commit in particular is
 completely untested.
>>>
>>> I have run basic test with Linux kernel on both sides
>>> for one kavser_pci card on guest side and vcan (no real interface)
>>> on host side.
>>>
>>> Mesages exchange tests passed and looks OK.
>>>
>>> I have used next parameters
>>>
>>>  -object can-bus,id=canbus0 \
>>>  -device kvaser_pci,canbus=canbus0 \
>>>  -object can-host-socketcan,if=can0,canbus=canbus0,id=canbus0-socketcan
>>>
>>> The id parameter is required for "can-host-socketcan" object.
>>> Else next error is printed
>>>
>>>  qemu-system-x86_64: -object can-host-socketcan,if=can0,canbus=canbus0: 
>>> Parameter 'id' is missing
>>>
>>> If "-object can-bus,id=canbus0" is missing then next error is reported
>>>
>>>  qemu-system-x86_64: -object 
>>> can-host-socketcan,if=can0,canbus=canbus0,id=canbus0-socketcan: Device 
>>> 'canbus0' not found
>>>
>>> I have inspected through monitor the state of objects
>>>
>>>  (qemu) qom-list /objects
>>>  canbus0-socketcan (child)
>>>  type (string)
>>>  canbus0 (child)
>>>
>>>  (qemu) info qom-tree
>>>  /machine (pc-i440fx-2.12-machine)
>>>...
>>>/peripheral-anon (container)
>>>  /device[1] (kvaser_pci)
>>>/bus master[0] (qemu:memory-region)
>>>/kvaser_pci-xilinx[0] (qemu:memory-region)
>>>/kvaser_pci-s5920[0] (qemu:memory-region)
>>>/kvaser_pci-sja[0] (qemu:memory-region)
>>>/bus master container[0] (qemu:memory-region)
>>>...
>>>
>>>
>>>  (qemu) qom-list /objects
>>>  canbus0-socketcan (child)
>>>  type (string)
>>>  canbus0 (child)
>>>
>>>  (qemu) qom-list /machine/peripheral-anon/device[1]
>>>  bus master container[0] (child)
>>>  canbus (link)
>>>  rombar (uint32)
>>>  hotpluggable (bool)
>>>  x-pcie-lnksta-dllla (bool)
>>>  kvaser_pci-sja[0] (child)
>>>  multifunction (bool)
>>>  hotplugged (bool)
>>>  parent_bus (link)
>>>  romfile (str)
>>>  kvaser_pci-s5920[0] (child)
>>>  x-pcie-extcap-init (bool)
>>>  command_serr_enable (bool)
>>>  addr (int32)
>>>  type (string)
>>>  legacy-addr (str)
>>>  kvaser_pci-xilinx[0] (child)
>>>  realized (bool)
>>>  bus master[0] (child)
>>>
>>> From the user point of view, it would be nice if "can-bus"
>>> can be populated when required automatically.
>>>
>>> I am not sure, but may it be that it would worth to
>>> push can-bus objects under some category/specific
>>> container. The path /objects is quite wide.
>>> Into something like /object/can-bus or /net/can.
>>>
>>> But 

Re: [Qemu-devel] [RFC PATCH v5 13/24] kvm: remove BQL lock/unlock

[Paolo Bonzini]

On 23/01/2018 03:54, Pavel Dovgalyuk wrote:
> @@ -1861,7 +1861,6 @@ int kvm_cpu_exec(CPUState *cpu)
>  return EXCP_HLT;
>  }
>  
> -qemu_mutex_unlock_iothread();
>  cpu_exec_start(cpu);
>  do {
>  MemTxAttrs attrs;


So this means that kvm_cpu_exec is now called without taking the BQL.
I'll leave aside the bisectability issue (patch 11 breaks kvm_cpu_exec,
because this qemu_mutex_unlock_iothread now has an assertion failure),
since they are easily fixed by squashing patches 11-13 together.

The lines immediately above are

if (kvm_arch_process_async_events(cpu)) {
atomic_set(>exit_request, 0);
return EXCP_HLT;
}

So this means that, after patch 11, kvm_arch_process_async_events went
from "called with BQL taken" to "called with BQL not taken".  And that
is completely broken, because it accesses cs->interrupt_request just
like cpu_has_work.  Previous reviews have ascertained that accessing
cs->interrupt_request requires taking the BQL; this is the same, except
worse because now we can even *write* cs->interrupt_request (clear bits)
without taking the lock.  I don't need to explain to you why this is bad.

 ..
 | .. |
 | | This is not how you are supposed to modify | |
 | | multi-threaded code.   | |
 | '' |
 ''

If something can be accessed outside a lock, e.g. with atomics, that has
to be documented.  In addition, if it's not obvious whether a function
is called with a lock or without, you add comments that make it clear.
Take a lock at accel/tcg/translate-all.c or exec.c for examples.

This is the last pass through this series that I make.  I'll pick the
patches that I consider ready, for everything else you'll have to find a
reviewer that is willing to look through the series and vouch for it
with a "Reviewed-by".

Paolo

Re: [Qemu-devel] [PATCH V4 0/7] CAN bus support for QEMU (SJA1000 PCI so far)

[Paolo Bonzini]

On 30/01/2018 19:13, Deniz Eren wrote:
> Hi Pavel, Paolo,
> 
> I tried to rerun my environment to test however it seems the interface has 
> changed a little and my standard program options cause complaints. 
> Unfortunately I don’t have too much time to dig through at the moment.
> 
> My standard startup command is:
> 
> $ ./qemu-local/bin/qemu-system-i386 -hda sdd2gb-uno1483-16.04-2.0-dev.img 
> -boot d -k en-us -device 
> mioe3680_pci,canbus1=canbus0,host1=vcan0,canbus2=canbus1,host2=vcan1 -m 
> size=2048 -netdev user,id=user.0 -device e1000,netdev=user.0 -redir 
> tcp:5022::22 -enable-kvm &

Yep, it's now like this:

./qemu-local/bin/qemu-system-i386 \
  -hda sdd2gb-uno1483-16.04-2.0-dev.img -boot d -k en-us \
  -object can-bus,id=canbus0 \
  -object can-bus,id=canbus1 \
  -object can-host-socketcan,id=canhost0,canbus=canbus0,ifname=vcan0 \
  -object can-host-socketcan,id=canhost1,canbus=canbus1,ifname=vcan1 \
  -device mioe3680_pci,canbus0=canbus0,canbus1=canbus1 \
  -m size=2048 -netdev user,id=user.0 -device e1000,netdev=user.0 \
  -redir tcp:5022::22 -enable-kvm

Thanks,

Paolo

> 
> 
> 
> Best regards,
> Deniz
> 
> Sent from my iPhone
> 
> Deniz Eren
> +61 400 307 762
> 
>> On 31 Jan 2018, at 9:12 am, Pavel Pisa  wrote:
>>
>> Hello Paolo,
>>
>> thanks much for conversion to acceptable QOM model.
>>
>>> On Tuesday 30 of January 2018 15:15:22 Paolo Bonzini wrote:
 On 25/01/2018 22:33, Pavel Pisa wrote:
 Hello Paolo,

 thanks for suggestions. I understand and fully agree with your
 request to switch to QOM. I have succeed with that for CAN devices
 some time ago. It worth to be done for the rest of the objects
 but I fear that I do not find time to complete QOMification
 in reasonable future. Contributions/suggestions from other
 are welcomed. I can look for students for GSoC at our university
 or under other funding.
>>>
>>> Please take a look at branch can-pci-qom of github.com/bonzini/qemu.git.
>>> Apart from QOMification of the backend include, I simplified the IRQ
>>> handling in can_kvaser_pci (fixing bugs too I think), and removed an
>>> unnecessary mutex.  I also moved the files to net/can and hw/net/can so
>>> that in the future Jason (networking maintainer) can take care of pull
>>> requests.
>>>
>>> I might have broken something, and the top commit in particular is
>>> completely untested.
>>
>> I have run basic test with Linux kernel on both sides
>> for one kavser_pci card on guest side and vcan (no real interface)
>> on host side.
>>
>> Mesages exchange tests passed and looks OK.
>>
>> I have used next parameters
>>
>>  -object can-bus,id=canbus0 \
>>  -device kvaser_pci,canbus=canbus0 \
>>  -object can-host-socketcan,if=can0,canbus=canbus0,id=canbus0-socketcan
>>
>> The id parameter is required for "can-host-socketcan" object.
>> Else next error is printed
>>
>>  qemu-system-x86_64: -object can-host-socketcan,if=can0,canbus=canbus0: 
>> Parameter 'id' is missing
>>
>> If "-object can-bus,id=canbus0" is missing then next error is reported
>>
>>  qemu-system-x86_64: -object 
>> can-host-socketcan,if=can0,canbus=canbus0,id=canbus0-socketcan: Device 
>> 'canbus0' not found
>>
>> I have inspected through monitor the state of objects
>>
>>  (qemu) qom-list /objects
>>  canbus0-socketcan (child)
>>  type (string)
>>  canbus0 (child)
>>
>>  (qemu) info qom-tree
>>  /machine (pc-i440fx-2.12-machine)
>>...
>>/peripheral-anon (container)
>>  /device[1] (kvaser_pci)
>>/bus master[0] (qemu:memory-region)
>>/kvaser_pci-xilinx[0] (qemu:memory-region)
>>/kvaser_pci-s5920[0] (qemu:memory-region)
>>/kvaser_pci-sja[0] (qemu:memory-region)
>>/bus master container[0] (qemu:memory-region)
>>...
>>
>>
>>  (qemu) qom-list /objects
>>  canbus0-socketcan (child)
>>  type (string)
>>  canbus0 (child)
>>
>>  (qemu) qom-list /machine/peripheral-anon/device[1]
>>  bus master container[0] (child)
>>  canbus (link)
>>  rombar (uint32)
>>  hotpluggable (bool)
>>  x-pcie-lnksta-dllla (bool)
>>  kvaser_pci-sja[0] (child)
>>  multifunction (bool)
>>  hotplugged (bool)
>>  parent_bus (link)
>>  romfile (str)
>>  kvaser_pci-s5920[0] (child)
>>  x-pcie-extcap-init (bool)
>>  command_serr_enable (bool)
>>  addr (int32)
>>  type (string)
>>  legacy-addr (str)
>>  kvaser_pci-xilinx[0] (child)
>>  realized (bool)
>>  bus master[0] (child)
>>
>> From the user point of view, it would be nice if "can-bus"
>> can be populated when required automatically.
>>
>> I am not sure, but may it be that it would worth to
>> push can-bus objects under some category/specific
>> container. The path /objects is quite wide.
>> Into something like /object/can-bus or /net/can.
>>
>> But generally thanks much, the progress you have made
>> in one day is really great. I hope that others check
>> your branch. I have pushed your unmodified version into
>> "can-pci-qom" branch of my repo
>>
>>  

Re: [Qemu-devel] MTTCG External Halt

[Alistair Francis]

On Fri, Jan 5, 2018 at 6:23 PM, Alistair Francis  wrote:
> On Thu, Jan 4, 2018 at 3:08 AM, Alex Bennée  wrote:
>>
>> Alistair Francis  writes:
>>
>>> Hey guys, I'm super stuck with an ugly MTTCG issue and was wondering
>>> if anyone had any ideas.
>>>
>>> In the Xilinx fork of QEMU (based on 2.11) we have a way for CPUs to
>>> halt other CPUs. This is used for example when the power control unit
>>> halts the ARM A53s. To do this we have internal GPIO signals that end
>>> up calling a function that basically does this:
>>>
>>> To halt:
>>> cpu->halted = true;
>>> cpu_interrupt(cpu, CPU_INTERRUPT_HALT);
>>
>> Hmm I don't think you should be setting cpu->halted unless you know it
>> is safe to do so. As the other CPUs free-run during BQL this isn't
>> enough for a cross vCPU interaction. However you can schedule work to
>> run in the target vCPUs context safely.
>
> We actually pretty much only ever set it on reset.
>
>>
>> That said isn't the cpu_interrupt enough to trigger the target vCPU to
>> halt?
>>
>>>
>>> To un-halt
>>> cpu->halted = false;
>>> cpu_reset_interrupt(cpu, CPU_INTERRUPT_HALT);
>>
>> Again if cross vCPU context this needs to be scheduled against the
>> target vCPU.
>>
>>>
>>> We also have the standard ARM WFI (Wait For Interrupt) implementation
>>> in op_helper.c:
>>> cs->halted = 1;
>>> cs->exception_index = EXCP_HLT;
>>> cpu_loop_exit(cs);
>>>
>>> Before MTTCG this used to work great, but now either we end up with
>>> the guest Linux complaining about CPU stalls or we hit:
>>> ERROR:/scratch/alistai/master-qemu/cpus.c:1516:qemu_tcg_cpu_thread_fn:
>>> assertion failed: (cpu->halted)
>>>
>>> If I remove the instances of manually setting cpu->halted then I don't
>>> see the asserts(), but the the WFI instruction doesn't work correctly.
>>> So it seems like setting the halted status externally from the CPU
>>> causes the issue.
>>
>>   /* during start-up the vCPU is reset and the thread is
>>* kicked several times. If we don't ensure we go back
>>* to sleep in the halted state we won't cleanly
>>* start-up when the vCPU is enabled.
>>*
>>* cpu->halted should ensure we sleep in wait_io_event
>>*/
>>
>> I think what I'm trying to say is we should never be halted without
>> having gone via wait_io_event where we can sleep.
>>
>>
>>> I have tried setting it inside a lock, using atomic
>>> operations and running the setter async on the CPU, but nothing works.
>>>
>>> Any chance any one has some insight into a way to externally set a
>>> vCPU as halted/un-halted?
>>
>> See the PSCI code which uses the async interface for exactly this.

Grr... It's back.

I narrowed it down to a reset (triggered by a external GPIO) is
causing the problem. Apparently QEMU doesn't like halted CPUs being
reset while spinning around qemu_tcg_cpu_thread_fn().

I don't have a good solution though, as setting CPU_INTERRUPT_RESET
doesn't help (that isn't handled while we are halted) and
async_run_on_cpu()/run_on_cpu() doesn't reliably reset the CPU when we
want.

I've ever tried pausing all CPUs before reseting the CPU and them
resuming them all but that doesn't seem to to work either. Is there
anything I'm missing? Is there no reliable way to reset a CPU?

Alistair

>
> Yeah, that and a fix to our weird double reset fixed it.
>
> What I don't get is how a double reset would cause the assert() to be hit.
>
> Alistair
>
>>
>>>
>>> Thanks,
>>> Alistair
>>
>>
>> --
>> Alex Bennée

Re: [Qemu-devel] [PATCH v6 02/23] exec: add ram_debug_ops support

[Brijesh Singh]

On 1/30/18 4:37 PM, Edgar E. Iglesias wrote:
> On Tue, Jan 30, 2018 at 04:34:37PM -0600, Brijesh Singh wrote:
>>
>> On 1/30/18 3:59 PM, Edgar E. Iglesias wrote:
>>> On Mon, Jan 29, 2018 at 11:41:11AM -0600, Brijesh Singh wrote:
 Currently, the guest memory access for the debug purpose is performed
 using the memcpy(). Lets extend the 'struct MemoryRegion' to include
 ram_debug_ops callbacks. The ram_debug_ops can be used to override
 memcpy() with something else.

 The feature can be used by encrypted guest -- which can register
 callbacks to override memcpy() with memory encryption/decryption APIs.

 a typical usage:

 mem_read(uint8_t *dst, uint8_t *src, uint32_t len, MemTxAttrs *attrs);
 mem_write(uint8_t *dst, uint8_t *src, uint32_t len, MemTxAttrs *attrs);

 MemoryRegionRAMReadWriteOps ops;
 ops.read = mem_read;
 ops.write = mem_write;
>>> Hi,
>>>
>>> Do these really need to be RAM specific (ram_debug_ops -> debug_ops) ?
>>> I was hoping a similar infrastructure could be used for MMIO
>>> debug accesses.
>> Hi Edgar,
>>
>> The MMIO regions will contains unencrypted data hence I do not find the
>> need to add debug hooks for it. A memcpy() to/from MMIO should be fine.
>> If we see the need for MMIO case then it can extended later.
> In this use-case yes, but in a general use-case MMIO regions may also
> want to differentiate debug from normal accesses.
>
> I'm not saying you need to implement MMIO examples but do we really
> need to have ram_debug_ops and mmio_debug_ops in the future?
> Can we get away with one somehow?

If anyone see this coming in near future then having one debug_ops makes
sense and it should be  doable. If we decide to use debug_ops for MMIO
then I could see us needing to add a new argument to debug_ops callback
to let the client knows whether the access came MMIO vs RAM region
because client may do different things for RAM vs MMIO case (e.g in SEV
RAM is encrypted but MMIO is unencrypted).

> Cheers,
> Edgar
>
>> Brijesh
>>> Best regards,
>>> Edgar
>>>
>>>
>>>
 memory_region_init_ram(mem, NULL, "memory", size, NULL);
 memory_region_set_ram_debug_ops(mem, ops);

 Cc: Paolo Bonzini 
 Cc: Peter Crosthwaite 
 Cc: Richard Henderson 
 Signed-off-by: Brijesh Singh 
 ---
  exec.c| 66 
 ++-
  include/exec/memory.h | 27 +
  2 files changed, 77 insertions(+), 16 deletions(-)

 diff --git a/exec.c b/exec.c
 index 629a5083851d..1919052b7385 100644
 --- a/exec.c
 +++ b/exec.c
 @@ -3050,7 +3050,11 @@ static MemTxResult flatview_write_continue(FlatView 
 *fv, hwaddr addr,
  } else {
  /* RAM case */
  ptr = qemu_ram_ptr_length(mr->ram_block, addr1, , false);
 -memcpy(ptr, buf, l);
 +if (attrs.debug && mr->ram_debug_ops) {
 +mr->ram_debug_ops->write(ptr, buf, l, attrs);
 +} else {
 +memcpy(ptr, buf, l);
 +}
  invalidate_and_set_dirty(mr, addr1, l);
  }
  
 @@ -3148,7 +3152,11 @@ MemTxResult flatview_read_continue(FlatView *fv, 
 hwaddr addr,
  } else {
  /* RAM case */
  ptr = qemu_ram_ptr_length(mr->ram_block, addr1, , false);
 -memcpy(buf, ptr, l);
 +if (attrs.debug && mr->ram_debug_ops) {
 +mr->ram_debug_ops->read(buf, ptr, l, attrs);
 +} else {
 +memcpy(buf, ptr, l);
 +}
  }
  
  if (release_lock) {
 @@ -3218,11 +3226,13 @@ void cpu_physical_memory_rw(hwaddr addr, uint8_t 
 *buf,
  
  enum write_rom_type {
  WRITE_DATA,
 +READ_DATA,
  FLUSH_CACHE,
  };
  
 -static inline void cpu_physical_memory_write_rom_internal(AddressSpace 
 *as,
 -hwaddr addr, const uint8_t *buf, int len, enum write_rom_type type)
 +static inline void cpu_physical_memory_rw_internal(AddressSpace *as,
 +hwaddr addr, uint8_t *buf, int len, MemTxAttrs attrs,
 +enum write_rom_type type)
  {
  hwaddr l;
  uint8_t *ptr;
 @@ -3237,12 +3247,33 @@ static inline void 
 cpu_physical_memory_write_rom_internal(AddressSpace *as,
  if (!(memory_region_is_ram(mr) ||
memory_region_is_romd(mr))) {
  l = memory_access_size(mr, l, addr1);
 +/* Pass MMIO down to address address_space_rw */
 +switch (type) {
 +case READ_DATA:
 +case WRITE_DATA:
 +address_space_rw(as, addr1, attrs, buf, l,
 + type == 

Re: [Qemu-devel] [PATCH 1/4] multiboot: Change multiboot_info from array of bytes to a C struct

[Jack Schwartz]

Hi Anatol and Kevin.

Even though I am new to Qemu, I have a patch to deliver for multiboot.c 
(as you know) and so I feel familiar enough to do a review of this 
patch.  One comment is probably more for maintainers.


Comments inline...


On 01/29/18 12:43, Anatol Pomozov wrote:

Using C structs makes the code more readable and prevents type conversion
errors.

Borrow multiboot1 header from GRUB project.

Signed-off-by: Anatol Pomozov 
---
  hw/i386/multiboot.c | 124 +
  hw/i386/multiboot_header.h  | 254 
  tests/multiboot/mmap.c  |  14 +--
  tests/multiboot/mmap.out|  10 ++
  tests/multiboot/modules.c   |  12 ++-
  tests/multiboot/modules.out |  10 ++
  tests/multiboot/multiboot.h |  66 
  7 files changed, 339 insertions(+), 151 deletions(-)
  create mode 100644 hw/i386/multiboot_header.h
  delete mode 100644 tests/multiboot/multiboot.h

diff --git a/hw/i386/multiboot.c b/hw/i386/multiboot.c
index c7b70c91d5..c6d05ca46b 100644
--- a/hw/i386/multiboot.c
+++ b/hw/i386/multiboot.c
@@ -28,6 +28,7 @@
  #include "hw/hw.h"
  #include "hw/nvram/fw_cfg.h"
  #include "multiboot.h"
+#include "multiboot_header.h"
  #include "hw/loader.h"
  #include "elf.h"
  #include "sysemu/sysemu.h"
@@ -47,39 +48,9 @@
  #error multiboot struct needs to fit in 16 bit real mode
  #endif
  
-enum {

-/* Multiboot info */
-MBI_FLAGS   = 0,
-MBI_MEM_LOWER   = 4,
-MBI_MEM_UPPER   = 8,
-MBI_BOOT_DEVICE = 12,
-MBI_CMDLINE = 16,
-MBI_MODS_COUNT  = 20,
-MBI_MODS_ADDR   = 24,
-MBI_MMAP_ADDR   = 48,
-MBI_BOOTLOADER  = 64,
-
-MBI_SIZE= 88,
-
-/* Multiboot modules */
-MB_MOD_START= 0,
-MB_MOD_END  = 4,
-MB_MOD_CMDLINE  = 8,
-
-MB_MOD_SIZE = 16,
-
-/* Region offsets */
-ADDR_E820_MAP = MULTIBOOT_STRUCT_ADDR + 0,
-ADDR_MBI  = ADDR_E820_MAP + 0x500,
-
-/* Multiboot flags */
-MULTIBOOT_FLAGS_MEMORY  = 1 << 0,
-MULTIBOOT_FLAGS_BOOT_DEVICE = 1 << 1,
-MULTIBOOT_FLAGS_CMDLINE = 1 << 2,
-MULTIBOOT_FLAGS_MODULES = 1 << 3,
-MULTIBOOT_FLAGS_MMAP= 1 << 6,
-MULTIBOOT_FLAGS_BOOTLOADER  = 1 << 9,
-};
+/* Region offsets */
+#define ADDR_E820_MAP MULTIBOOT_STRUCT_ADDR
+#define ADDR_MBI  (ADDR_E820_MAP + 0x500)
  
  typedef struct {

  /* buffer holding kernel, cmdlines and mb_infos */
@@ -128,14 +99,15 @@ static void mb_add_mod(MultibootState *s,
 hwaddr start, hwaddr end,
 hwaddr cmdline_phys)
  {
-char *p;
+multiboot_module_t *mod;
  assert(s->mb_mods_count < s->mb_mods_avail);
  
-p = (char *)s->mb_buf + s->offset_mbinfo + MB_MOD_SIZE * s->mb_mods_count;

+mod = s->mb_buf + s->offset_mbinfo +
+  sizeof(multiboot_module_t) * s->mb_mods_count;
  
-stl_p(p + MB_MOD_START,   start);

-stl_p(p + MB_MOD_END, end);
-stl_p(p + MB_MOD_CMDLINE, cmdline_phys);
+stl_p(>mod_start, start);
+stl_p(>mod_end,   end);
+stl_p(>cmdline,   cmdline_phys);
  
  mb_debug("mod%02d: "TARGET_FMT_plx" - "TARGET_FMT_plx"\n",

   s->mb_mods_count, start, end);
@@ -151,26 +123,29 @@ int load_multiboot(FWCfgState *fw_cfg,
 int kernel_file_size,
 uint8_t *header)
  {
-int i, is_multiboot = 0;
+int i;
+bool is_multiboot = false;
  uint32_t flags = 0;
  uint32_t mh_entry_addr;
  uint32_t mh_load_addr;
  uint32_t mb_kernel_size;
  MultibootState mbs;
-uint8_t bootinfo[MBI_SIZE];
+multiboot_info_t bootinfo;
  uint8_t *mb_bootinfo_data;
  uint32_t cmdline_len;
+struct multiboot_header *multiboot_header;
  
  /* Ok, let's see if it is a multiboot image.

 The header is 12x32bit long, so the latest entry may be 8192 - 48. */
  for (i = 0; i < (8192 - 48); i += 4) {
-if (ldl_p(header+i) == 0x1BADB002) {
-uint32_t checksum = ldl_p(header+i+8);
-flags = ldl_p(header+i+4);
+multiboot_header = (struct multiboot_header *)(header + i);
+if (ldl_p(_header->magic) == MULTIBOOT_HEADER_MAGIC) {
+uint32_t checksum = ldl_p(_header->checksum);
+flags = ldl_p(_header->flags);
  checksum += flags;
-checksum += (uint32_t)0x1BADB002;
+checksum += (uint32_t)MULTIBOOT_HEADER_MAGIC;
  if (!checksum) {
-is_multiboot = 1;
+is_multiboot = true;
  break;
  }
  }
@@ -180,13 +155,13 @@ int load_multiboot(FWCfgState *fw_cfg,
  return 0; /* no multiboot */
  
  mb_debug("qemu: I believe we found a multiboot image!\n");

-memset(bootinfo, 0, sizeof(bootinfo));
+memset(, 0, sizeof(bootinfo));
  memset(, 0, sizeof(mbs));
  
-if (flags & 0x0004) { /* MULTIBOOT_HEADER_HAS_VBE */

+if (flags & 

Re: [Qemu-devel] [PATCH 2/4] multiboot: load elf sections and section headers

[Jack Schwartz]

Hi Anatol.

I have one comment about sections.c headers (and didn't really look 
further in that file), and start.S.


Comments inline...

On 01/29/18 12:43, Anatol Pomozov wrote:

Multiboot may load section headers and all sections (even those that are
not part of any segment) to target memory.

Tested with an ELF application that uses data from strings table
section.

Signed-off-by: Anatol Pomozov 
---
  hw/core/loader.c |   8 +--
  hw/i386/multiboot.c  |  17 +++--
  hw/s390x/ipl.c   |   2 +-
  include/hw/elf_ops.h | 110 +--
  include/hw/loader.h  |  11 +++-
  tests/multiboot/Makefile |   8 ++-
  tests/multiboot/generate_sections_out.py |  33 ++
  tests/multiboot/modules.out  |  22 +++
  tests/multiboot/run_test.sh  |   6 +-
  tests/multiboot/sections.c   |  57 
  tests/multiboot/start.S  |   2 +-
  11 files changed, 248 insertions(+), 28 deletions(-)
  create mode 100755 tests/multiboot/generate_sections_out.py
  create mode 100644 tests/multiboot/sections.c




diff --git a/tests/multiboot/sections.c b/tests/multiboot/sections.c
new file mode 100644
index 00..64060510ce
--- /dev/null
+++ b/tests/multiboot/sections.c
@@ -0,0 +1,57 @@
+/*
+ * Copyright (c) 2017 Anatol Pomozov 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "libc.h"
+#include "../../hw/i386/multiboot_header.h"
As like the first patch, I suggest creating a "multiboot" subdir in the 
"include" subtree and putting all multiboot header files there. 
Including "multiboot/multiboot_header.h" would be cleaner.

+#include "../../include/elf.h"
+
+int test_main(uint32_t magic, struct multiboot_info *mbi)
+{
+void *p;
+unsigned int i;
+
+(void) magic;
+multiboot_elf_section_header_table_t shdr;
+
+printf("Multiboot header at %x, ELF section headers %s\n\n", mbi,
+mbi->flags & MULTIBOOT_INFO_ELF_SHDR ? "present" : "doesn't present");
+
+shdr = mbi->u.elf_sec;
+printf("Sections list with %d entries of size %d at %x, string index %d\n",
+shdr.num, shdr.size, shdr.addr, shdr.shndx);
+
+const char *string_table = (char *)((Elf32_Shdr *)(uintptr_t)(shdr.addr +
+shdr.shndx * shdr.size))->sh_addr;
+
+for (i = 0, p = (void *)shdr.addr;
+ i < shdr.num;
+ i++, p += shdr.size)
+{
+Elf32_Shdr *sec;
+
+sec = (Elf32_Shdr *)p;
+printf("Elf section name=%s addr=%lx size=%ld\n",
+string_table + sec->sh_name, sec->sh_addr, sec->sh_size);
+}
+
+return 0;
+}
diff --git a/tests/multiboot/start.S b/tests/multiboot/start.S
index 7d33959650..bd404100c2 100644
--- a/tests/multiboot/start.S
+++ b/tests/multiboot/start.S
@@ -23,7 +23,7 @@
  .section multiboot
  
  #define MB_MAGIC 0x1badb002

-#define MB_FLAGS 0x0
+#define MB_FLAGS 0x2
  #define MB_CHECKSUM -(MB_MAGIC + MB_FLAGS)
C headers can be included in assembly files.  Since you are bringing 
over multiboot_header.h, why not include it and use its values instead 
of re-defining them here?


    Thanks,
    Jack
  
  .align  4

Re: [Qemu-devel] [qemu-web PATCH] Add "Understanding QEMU devices" blog post

[Paolo Bonzini]

On 29/01/2018 12:27, Thomas Huth wrote:
> On 26.01.2018 15:46, Eric Blake wrote:
>> On 01/26/2018 06:40 AM, Paolo Bonzini wrote:
>>> On 26/01/2018 10:19, Thomas Huth wrote:
 Last July, Eric Blake wrote a nice summary for newcomers about what
 QEMU has to do to emulate devices for the guests. So far, we missed
 to integrate this somewhere into the QEM web site or wiki, so let's
 publish this now as a nice blog post for the users.
>>>
>>> It's very nice!  Some proofreading and corrections follow.
>>
>> Thanks for digging up my original email, and enhancing it (I guess the
>> fact that I don't blog very often, and stick to email, means that I rely
>> on others helping to polish my gems for the masses).
> 
> Sure ... Would you like to give it a try this time and continue with the
> patch, or shall I continue and send a v2?
> 
 +++ b/_posts/2018-01-26-understanding-qemu-devices.md
 @@ -0,0 +1,139 @@
 +---
 +layout: post
 +title:  "Understanding QEMU devices"
 +date:   2018-01-26 10:00:00 +0100
>>
>> That's when you're posting it online, but should it also mention when I
>> first started these thoughts in email form?
> 
> At least in the header we should have the current date, or the blog post
> will not show up at the top of the blog. Not sure whether there is an
> alternate field for the original date ... maybe we could rather add an
> "originally written in 2017 ..." sentence at the bottom of the post instead?

I don't think it's relevant, as long as it's brought up to date when we
post it to the web.

Paolo

Re: [Qemu-devel] [PATCH] vcpu: create vcpu thread with QEMU_THREAD_DETACHED mode

[Paolo Bonzini]

On 28/01/2018 05:14, CheneyLin wrote:
>> This is dangerous, it risks introducing use-after-free bugs in the vCPU
>> thread.  Can you instead add a qemu_thread_join call where the vCPU goes
>> away (e.g. unrealize, I'm not sure)?
> 
> 1. If another thread calls qemu_thread_join, it will block until vcpu thread 
> exit.

Sure, but that's not a problem.  If the code is written correctly, it
will only block for a very short time.  In particular, in this case
we'll block anyway in cpu_remove_sync.  The fix is just to change that
function from qemu_cond_wait to qemu_thread_join.

> 2. As vcpu exits, its resources should be freed ,which will not be used any 
> more(e.g. user space stack), how can we get use-after-free bugs?

Use-after-free bugs happen in the vCPU thread if the vCPU resources are
freed just before the vCPU thread exits.

Paolo

Re: [Qemu-devel] [PATCH] qemu-options.hx: Remove confusing spaces in parameter listings

[Paolo Bonzini]

On 30/01/2018 10:36, Thomas Huth wrote:
> The spaces between the parameters in the chardev and tpmdev sections
> are rather confusing than helpful, and prevent that the lists can be
> copy-n-pasted easily for real usage. We also don't use such spaces
> in other sections in the documentation, e.g. with the -netdev option,
> so let's be consistent and remove the spaces in the chardev and tpmdev
> sections, too.
> 
> Signed-off-by: Thomas Huth 
> ---
>  qemu-options.hx | 48 
>  1 file changed, 24 insertions(+), 24 deletions(-)
> 
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 8ce427d..08a73fa 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -2522,7 +2522,7 @@ STEXI
>  
>  The general form of a character device option is:
>  @table @option
> -@item -chardev @var{backend} ,id=@var{id} [,mux=on|off] [,@var{options}]
> +@item -chardev @var{backend},id=@var{id}[,mux=on|off][,@var{options}]
>  @findex -chardev
>  Backend is one of:
>  @option{null},
> @@ -2541,7 +2541,7 @@ Backend is one of:
>  @option{tty},
>  @option{parallel},
>  @option{parport},
> -@option{spicevmc}.
> +@option{spicevmc},
>  @option{spiceport}.
>  The specific backend will determine the applicable options.
>  
> @@ -2605,11 +2605,11 @@ opened.
>  The available backends are:
>  
>  @table @option
> -@item -chardev null ,id=@var{id}
> +@item -chardev null,id=@var{id}
>  A void device. This device will not emit any data, and will drop any data it
>  receives. The null backend does not take any options.
>  
> -@item -chardev socket ,id=@var{id} [@var{TCP options} or @var{unix options}] 
> [,server] [,nowait] [,telnet] [,reconnect=@var{seconds}] [,tls-creds=@var{id}]
> +@item -chardev socket,id=@var{id}[,@var{TCP options} or @var{unix 
> options}][,server][,nowait][,telnet][,reconnect=@var{seconds}][,tls-creds=@var{id}]
>  
>  Create a two-way stream socket, which can be either a TCP or a unix socket. A
>  unix socket will be created if @option{path} is specified. Behaviour is
> @@ -2636,7 +2636,7 @@ TCP and unix socket options are given below:
>  
>  @table @option
>  
> -@item TCP options: port=@var{port} [,host=@var{host}] [,to=@var{to}] [,ipv4] 
> [,ipv6] [,nodelay]
> +@item TCP options: 
> port=@var{port}[,host=@var{host}][,to=@var{to}][,ipv4][,ipv6][,nodelay]
>  
>  @option{host} for a listening socket specifies the local address to be bound.
>  For a connecting socket species the remote host to connect to. @option{host} 
> is
> @@ -2664,7 +2664,7 @@ required.
>  
>  @end table
>  
> -@item -chardev udp ,id=@var{id} [,host=@var{host}] ,port=@var{port} 
> [,localaddr=@var{localaddr}] [,localport=@var{localport}] [,ipv4] [,ipv6]
> +@item -chardev 
> udp,id=@var{id}[,host=@var{host}],port=@var{port}[,localaddr=@var{localaddr}][,localport=@var{localport}][,ipv4][,ipv6]
>  
>  Sends all traffic from the guest to a remote host over UDP.
>  
> @@ -2683,12 +2683,12 @@ available local port will be used.
>  @option{ipv4} and @option{ipv6} specify that either IPv4 or IPv6 must be 
> used.
>  If neither is specified the device may use either protocol.
>  
> -@item -chardev msmouse ,id=@var{id}
> +@item -chardev msmouse,id=@var{id}
>  
>  Forward QEMU's emulated msmouse events to the guest. @option{msmouse} does 
> not
>  take any options.
>  
> -@item -chardev vc ,id=@var{id} [[,width=@var{width}] [,height=@var{height}]] 
> [[,cols=@var{cols}] [,rows=@var{rows}]]
> +@item -chardev 
> vc,id=@var{id}[[,width=@var{width}][,height=@var{height}]][[,cols=@var{cols}][,rows=@var{rows}]]
>  
>  Connect to a QEMU text console. @option{vc} may optionally be given a 
> specific
>  size.
> @@ -2699,12 +2699,12 @@ the console, in pixels.
>  @option{cols} and @option{rows} specify that the console be sized to fit a 
> text
>  console with the given dimensions.
>  
> -@item -chardev ringbuf ,id=@var{id} [,size=@var{size}]
> +@item -chardev ringbuf,id=@var{id}[,size=@var{size}]
>  
>  Create a ring buffer with fixed size @option{size}.
>  @var{size} must be a power of two and defaults to @code{64K}.
>  
> -@item -chardev file ,id=@var{id} ,path=@var{path}
> +@item -chardev file,id=@var{id},path=@var{path}
>  
>  Log all traffic received from the guest to a file.
>  
> @@ -2712,7 +2712,7 @@ Log all traffic received from the guest to a file.
>  created if it does not already exist, and overwritten if it does. 
> @option{path}
>  is required.
>  
> -@item -chardev pipe ,id=@var{id} ,path=@var{path}
> +@item -chardev pipe,id=@var{id},path=@var{path}
>  
>  Create a two-way connection to the guest. The behaviour differs slightly 
> between
>  Windows hosts and other hosts:
> @@ -2729,14 +2729,14 @@ be present.
>  @option{path} forms part of the pipe path as described above. @option{path} 
> is
>  required.
>  
> -@item -chardev console ,id=@var{id}
> +@item -chardev console,id=@var{id}
>  
>  Send traffic from the guest to QEMU's standard output. @option{console} does 
> not
>  take any 

Re: [Qemu-devel] [PATCH v6 02/23] exec: add ram_debug_ops support

[Edgar E. Iglesias]

On Tue, Jan 30, 2018 at 04:34:37PM -0600, Brijesh Singh wrote:
> 
> 
> On 1/30/18 3:59 PM, Edgar E. Iglesias wrote:
> > On Mon, Jan 29, 2018 at 11:41:11AM -0600, Brijesh Singh wrote:
> >> Currently, the guest memory access for the debug purpose is performed
> >> using the memcpy(). Lets extend the 'struct MemoryRegion' to include
> >> ram_debug_ops callbacks. The ram_debug_ops can be used to override
> >> memcpy() with something else.
> >>
> >> The feature can be used by encrypted guest -- which can register
> >> callbacks to override memcpy() with memory encryption/decryption APIs.
> >>
> >> a typical usage:
> >>
> >> mem_read(uint8_t *dst, uint8_t *src, uint32_t len, MemTxAttrs *attrs);
> >> mem_write(uint8_t *dst, uint8_t *src, uint32_t len, MemTxAttrs *attrs);
> >>
> >> MemoryRegionRAMReadWriteOps ops;
> >> ops.read = mem_read;
> >> ops.write = mem_write;
> >
> > Hi,
> >
> > Do these really need to be RAM specific (ram_debug_ops -> debug_ops) ?
> > I was hoping a similar infrastructure could be used for MMIO
> > debug accesses.
> 
> Hi Edgar,
> 
> The MMIO regions will contains unencrypted data hence I do not find the
> need to add debug hooks for it. A memcpy() to/from MMIO should be fine.
> If we see the need for MMIO case then it can extended later.

In this use-case yes, but in a general use-case MMIO regions may also
want to differentiate debug from normal accesses.

I'm not saying you need to implement MMIO examples but do we really
need to have ram_debug_ops and mmio_debug_ops in the future?
Can we get away with one somehow?

Cheers,
Edgar

> 
> Brijesh
> > Best regards,
> > Edgar
> >
> >
> >
> >> memory_region_init_ram(mem, NULL, "memory", size, NULL);
> >> memory_region_set_ram_debug_ops(mem, ops);
> >>
> >> Cc: Paolo Bonzini 
> >> Cc: Peter Crosthwaite 
> >> Cc: Richard Henderson 
> >> Signed-off-by: Brijesh Singh 
> >> ---
> >>  exec.c| 66 
> >> ++-
> >>  include/exec/memory.h | 27 +
> >>  2 files changed, 77 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/exec.c b/exec.c
> >> index 629a5083851d..1919052b7385 100644
> >> --- a/exec.c
> >> +++ b/exec.c
> >> @@ -3050,7 +3050,11 @@ static MemTxResult flatview_write_continue(FlatView 
> >> *fv, hwaddr addr,
> >>  } else {
> >>  /* RAM case */
> >>  ptr = qemu_ram_ptr_length(mr->ram_block, addr1, , false);
> >> -memcpy(ptr, buf, l);
> >> +if (attrs.debug && mr->ram_debug_ops) {
> >> +mr->ram_debug_ops->write(ptr, buf, l, attrs);
> >> +} else {
> >> +memcpy(ptr, buf, l);
> >> +}
> >>  invalidate_and_set_dirty(mr, addr1, l);
> >>  }
> >>  
> >> @@ -3148,7 +3152,11 @@ MemTxResult flatview_read_continue(FlatView *fv, 
> >> hwaddr addr,
> >>  } else {
> >>  /* RAM case */
> >>  ptr = qemu_ram_ptr_length(mr->ram_block, addr1, , false);
> >> -memcpy(buf, ptr, l);
> >> +if (attrs.debug && mr->ram_debug_ops) {
> >> +mr->ram_debug_ops->read(buf, ptr, l, attrs);
> >> +} else {
> >> +memcpy(buf, ptr, l);
> >> +}
> >>  }
> >>  
> >>  if (release_lock) {
> >> @@ -3218,11 +3226,13 @@ void cpu_physical_memory_rw(hwaddr addr, uint8_t 
> >> *buf,
> >>  
> >>  enum write_rom_type {
> >>  WRITE_DATA,
> >> +READ_DATA,
> >>  FLUSH_CACHE,
> >>  };
> >>  
> >> -static inline void cpu_physical_memory_write_rom_internal(AddressSpace 
> >> *as,
> >> -hwaddr addr, const uint8_t *buf, int len, enum write_rom_type type)
> >> +static inline void cpu_physical_memory_rw_internal(AddressSpace *as,
> >> +hwaddr addr, uint8_t *buf, int len, MemTxAttrs attrs,
> >> +enum write_rom_type type)
> >>  {
> >>  hwaddr l;
> >>  uint8_t *ptr;
> >> @@ -3237,12 +3247,33 @@ static inline void 
> >> cpu_physical_memory_write_rom_internal(AddressSpace *as,
> >>  if (!(memory_region_is_ram(mr) ||
> >>memory_region_is_romd(mr))) {
> >>  l = memory_access_size(mr, l, addr1);
> >> +/* Pass MMIO down to address address_space_rw */
> >> +switch (type) {
> >> +case READ_DATA:
> >> +case WRITE_DATA:
> >> +address_space_rw(as, addr1, attrs, buf, l,
> >> + type == WRITE_DATA);
> >> +break;
> >> +case FLUSH_CACHE:
> >> +break;
> >> +}
> >>  } else {
> >>  /* ROM/RAM case */
> >>  ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
> >>  switch (type) {
> >> +case READ_DATA:
> >> +if (mr->ram_debug_ops) {
> >> +mr->ram_debug_ops->read(buf, ptr, l, attrs);
> >> +  

Re: [Qemu-devel] [PATCH v6 02/23] exec: add ram_debug_ops support

[Brijesh Singh]

On 1/30/18 3:59 PM, Edgar E. Iglesias wrote:
> On Mon, Jan 29, 2018 at 11:41:11AM -0600, Brijesh Singh wrote:
>> Currently, the guest memory access for the debug purpose is performed
>> using the memcpy(). Lets extend the 'struct MemoryRegion' to include
>> ram_debug_ops callbacks. The ram_debug_ops can be used to override
>> memcpy() with something else.
>>
>> The feature can be used by encrypted guest -- which can register
>> callbacks to override memcpy() with memory encryption/decryption APIs.
>>
>> a typical usage:
>>
>> mem_read(uint8_t *dst, uint8_t *src, uint32_t len, MemTxAttrs *attrs);
>> mem_write(uint8_t *dst, uint8_t *src, uint32_t len, MemTxAttrs *attrs);
>>
>> MemoryRegionRAMReadWriteOps ops;
>> ops.read = mem_read;
>> ops.write = mem_write;
>
> Hi,
>
> Do these really need to be RAM specific (ram_debug_ops -> debug_ops) ?
> I was hoping a similar infrastructure could be used for MMIO
> debug accesses.

Hi Edgar,

The MMIO regions will contains unencrypted data hence I do not find the
need to add debug hooks for it. A memcpy() to/from MMIO should be fine.
If we see the need for MMIO case then it can extended later.

Brijesh
> Best regards,
> Edgar
>
>
>
>> memory_region_init_ram(mem, NULL, "memory", size, NULL);
>> memory_region_set_ram_debug_ops(mem, ops);
>>
>> Cc: Paolo Bonzini 
>> Cc: Peter Crosthwaite 
>> Cc: Richard Henderson 
>> Signed-off-by: Brijesh Singh 
>> ---
>>  exec.c| 66 
>> ++-
>>  include/exec/memory.h | 27 +
>>  2 files changed, 77 insertions(+), 16 deletions(-)
>>
>> diff --git a/exec.c b/exec.c
>> index 629a5083851d..1919052b7385 100644
>> --- a/exec.c
>> +++ b/exec.c
>> @@ -3050,7 +3050,11 @@ static MemTxResult flatview_write_continue(FlatView 
>> *fv, hwaddr addr,
>>  } else {
>>  /* RAM case */
>>  ptr = qemu_ram_ptr_length(mr->ram_block, addr1, , false);
>> -memcpy(ptr, buf, l);
>> +if (attrs.debug && mr->ram_debug_ops) {
>> +mr->ram_debug_ops->write(ptr, buf, l, attrs);
>> +} else {
>> +memcpy(ptr, buf, l);
>> +}
>>  invalidate_and_set_dirty(mr, addr1, l);
>>  }
>>  
>> @@ -3148,7 +3152,11 @@ MemTxResult flatview_read_continue(FlatView *fv, 
>> hwaddr addr,
>>  } else {
>>  /* RAM case */
>>  ptr = qemu_ram_ptr_length(mr->ram_block, addr1, , false);
>> -memcpy(buf, ptr, l);
>> +if (attrs.debug && mr->ram_debug_ops) {
>> +mr->ram_debug_ops->read(buf, ptr, l, attrs);
>> +} else {
>> +memcpy(buf, ptr, l);
>> +}
>>  }
>>  
>>  if (release_lock) {
>> @@ -3218,11 +3226,13 @@ void cpu_physical_memory_rw(hwaddr addr, uint8_t 
>> *buf,
>>  
>>  enum write_rom_type {
>>  WRITE_DATA,
>> +READ_DATA,
>>  FLUSH_CACHE,
>>  };
>>  
>> -static inline void cpu_physical_memory_write_rom_internal(AddressSpace *as,
>> -hwaddr addr, const uint8_t *buf, int len, enum write_rom_type type)
>> +static inline void cpu_physical_memory_rw_internal(AddressSpace *as,
>> +hwaddr addr, uint8_t *buf, int len, MemTxAttrs attrs,
>> +enum write_rom_type type)
>>  {
>>  hwaddr l;
>>  uint8_t *ptr;
>> @@ -3237,12 +3247,33 @@ static inline void 
>> cpu_physical_memory_write_rom_internal(AddressSpace *as,
>>  if (!(memory_region_is_ram(mr) ||
>>memory_region_is_romd(mr))) {
>>  l = memory_access_size(mr, l, addr1);
>> +/* Pass MMIO down to address address_space_rw */
>> +switch (type) {
>> +case READ_DATA:
>> +case WRITE_DATA:
>> +address_space_rw(as, addr1, attrs, buf, l,
>> + type == WRITE_DATA);
>> +break;
>> +case FLUSH_CACHE:
>> +break;
>> +}
>>  } else {
>>  /* ROM/RAM case */
>>  ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
>>  switch (type) {
>> +case READ_DATA:
>> +if (mr->ram_debug_ops) {
>> +mr->ram_debug_ops->read(buf, ptr, l, attrs);
>> +} else {
>> +memcpy(buf, ptr, l);
>> +}
>> +break;
>>  case WRITE_DATA:
>> -memcpy(ptr, buf, l);
>> +if (mr->ram_debug_ops) {
>> +mr->ram_debug_ops->write(ptr, buf, l, attrs);
>> +} else {
>> +memcpy(ptr, buf, l);
>> +}
>>  invalidate_and_set_dirty(mr, addr1, l);
>>  break;
>>  case FLUSH_CACHE:
>> @@ -3261,7 +3292,8 @@ static inline void 
>> cpu_physical_memory_write_rom_internal(AddressSpace *as,

[Qemu-devel] [Bug 1186984] Re: large -initrd can wrap around in memory causing memory corruption

[Richard Jones]

The answer is I don't know.  Closing this bug seems correct unless
someone can reproduce the original problem.

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

Title:
  large -initrd can wrap around in memory causing memory corruption

Status in QEMU:
  Incomplete

Bug description:
  We don't use large -initrd in libguestfs any more, but I noticed that
  a large -initrd file now crashes qemu spectacularly:

  $ ls -lh /tmp/kernel /tmp/initrd 
  -rw-r--r--. 1 rjones rjones 273M Jun  3 14:02 /tmp/initrd
  lrwxrwxrwx. 1 rjones rjones   35 Jun  3 14:02 /tmp/kernel -> 
/boot/vmlinuz-3.9.4-200.fc18.x86_64

  $ ./x86_64-softmmu/qemu-system-x86_64 -L pc-bios \
  -kernel /tmp/kernel -initrd /tmp/initrd -hda /tmp/test1.img -serial stdio 
\
  -append console=ttyS0

  qemu crashes with one of several errors:

  PFLASH: Possible BUG - Write block confirm

  qemu: fatal: Trying to execute code outside RAM or ROM at
  0x000b96cd

  If -enable-kvm is used:

  KVM: injection failed, MSI lost (Operation not permitted)

  In all cases the SDL display fills up with coloured blocks before the
  crash (see the attached screenshot).

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

Re: [Qemu-devel] [PATCH v6 05/23] target/i386: add memory encryption feature cpuid support

[Brijesh Singh]

On 1/30/18 3:46 PM, Brijesh Singh wrote:
>
> On 1/30/18 11:49 AM, Dr. David Alan Gilbert wrote:
>> * Brijesh Singh (brijesh.si...@amd.com) wrote:
>>> AMD EPYC processors support memory encryption feature. The feature
>>> is reported through CPUID 8000_001F[EAX].
>>>
>>> Fn8000_001F [EAX]:
>>>  Bit 0   Secure Memory Encryption (SME) supported
>>>  Bit 1   Secure Encrypted Virtualization (SEV) supported
>>>  Bit 2   Page flush MSR supported
>>>  Bit 3   Ecrypted State (SEV-ES) support
>>>
>>> when memory encryption feature is reported, CPUID 8000_001F[EBX] should
>>> provide additional information regarding the feature (such as which page
>>> table bit is used to mark pages as encrypted etc). The information in EBX
>>> and ECX may vary from one family to another hence we use the host cpuid
>>> to populate the EBX information.
>> That's going to make it interesting for migration.  If the guest needs
>> to know that C-bit position then you presumably can't migrate between
>> those two host types, but we wouldn't have anything that currently
>> stops us.
>> We already have similar problems with variations in physical address
>> size but normally get away with that, especially on smaller VMs.
> Dave,
>
> While building the page tables guest need to know the C-bit position.
> The C-bit position in the guest is same as C-bit position on the host.
> For migration case, we should be able to migrate SEV guest on same host
> type (i.e all EPYC and Ryzen CPUs are based on family 17 and we should
> be okay migrating the SEV guests among those host types).  Since C-bit
> position is not fixed hence migrating to different host family will be
> an issue.

One small correct, Ryzen CPUs do not support SEV feature hence we will
not able migrate SEV guest from EPYC to Ryzen.

> -Brijesh
>> Dave
>>
>>
>>> The details for memory encryption CPUID is available in AMD APM
>>> (http://support.amd.com/TechDocs/24593.pdf) Section 15.34.1
>>> Cc: Paolo Bonzini 
>>> Cc: Richard Henderson 
>>> Cc: Eduardo Habkost 
>>> Signed-off-by: Brijesh Singh 
>>> ---
>>>  target/i386/cpu.c | 36 
>>>  target/i386/cpu.h |  6 ++
>>>  2 files changed, 42 insertions(+)
>>>
>>> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
>>> index a49d2221adc9..4147eb6e18a9 100644
>>> --- a/target/i386/cpu.c
>>> +++ b/target/i386/cpu.c
>>> @@ -234,6 +234,7 @@ static void x86_cpu_vendor_words2str(char *dst, 
>>> uint32_t vendor1,
>>>  #define TCG_EXT4_FEATURES 0
>>>  #define TCG_SVM_FEATURES 0
>>>  #define TCG_KVM_FEATURES 0
>>> +#define TCG_MEM_ENCRYPT_FEATURES 0
>>>  #define TCG_7_0_EBX_FEATURES (CPUID_7_0_EBX_SMEP | CPUID_7_0_EBX_SMAP | \
>>>CPUID_7_0_EBX_BMI1 | CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_ADX | \
>>>CPUID_7_0_EBX_PCOMMIT | CPUID_7_0_EBX_CLFLUSHOPT |\
>>> @@ -545,6 +546,20 @@ static FeatureWordInfo 
>>> feature_word_info[FEATURE_WORDS] = {
>>>  .cpuid_reg = R_EDX,
>>>  .tcg_features = ~0U,
>>>  },
>>> +[FEAT_MEM_ENCRYPT] = {
>>> +.feat_names = {
>>> +"sme", "sev", "page-flush-msr", "sev-es",
>>> +NULL, NULL, NULL, NULL,
>>> +NULL, NULL, NULL, NULL,
>>> +NULL, NULL, NULL, NULL,
>>> +NULL, NULL, NULL, NULL,
>>> +NULL, NULL, NULL, NULL,
>>> +NULL, NULL, NULL, NULL,
>>> +NULL, NULL, NULL, NULL,
>>> +},
>>> +.cpuid_eax = 0x801F, .cpuid_reg = R_EAX,
>>> +.tcg_features = TCG_MEM_ENCRYPT_FEATURES,
>>> +}
>>>  };
>>>  
>>>  typedef struct X86RegisterInfo32 {
>>> @@ -1965,6 +1980,9 @@ static X86CPUDefinition builtin_x86_defs[] = {
>>>  CPUID_XSAVE_XGETBV1,
>>>  .features[FEAT_6_EAX] =
>>>  CPUID_6_EAX_ARAT,
>>> +/* Missing: SEV_ES */
>>> +.features[FEAT_MEM_ENCRYPT] =
>>> +CPUID_8000_001F_EAX_SME | CPUID_8000_001F_EAX_SEV,
>>>  .xlevel = 0x800A,
>>>  .model_id = "AMD EPYC Processor",
>>>  },
>>> @@ -3589,6 +3607,19 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, 
>>> uint32_t count,
>>>  *edx = 0;
>>>  }
>>>  break;
>>> +case 0x801F:
>>> +if (env->features[FEAT_MEM_ENCRYPT] & CPUID_8000_001F_EAX_SEV) {
>>> +*eax = env->features[FEAT_MEM_ENCRYPT];
>>> +host_cpuid(0x801F, 0, NULL, ebx, NULL, NULL);
>>> +*ecx = 0;
>>> +*edx = 0;
>>> +} else {
>>> +*eax = 0;
>>> +*ebx = 0;
>>> +*ecx = 0;
>>> +*edx = 0;
>>> +}
>>> +break;
>>>  case 0xC000:
>>>  *eax = env->cpuid_xlevel2;
>>>  *ebx = 0;
>>> @@ -4036,10 +4067,15 @@ static void x86_cpu_expand_features(X86CPU *cpu, 
>>> Error **errp)
>>>  x86_cpu_adjust_feat_level(cpu, FEAT_C000_0001_EDX);
>>>  

Re: [Qemu-devel] [PATCH V4 0/7] CAN bus support for QEMU (SJA1000 PCI so far)

[Pavel Pisa]

Hello Paolo,

thanks much for conversion to acceptable QOM model.

On Tuesday 30 of January 2018 15:15:22 Paolo Bonzini wrote:
> On 25/01/2018 22:33, Pavel Pisa wrote:
> > Hello Paolo,
> >
> > thanks for suggestions. I understand and fully agree with your
> > request to switch to QOM. I have succeed with that for CAN devices
> > some time ago. It worth to be done for the rest of the objects
> > but I fear that I do not find time to complete QOMification
> > in reasonable future. Contributions/suggestions from other
> > are welcomed. I can look for students for GSoC at our university
> > or under other funding.
>
> Please take a look at branch can-pci-qom of github.com/bonzini/qemu.git.
>  Apart from QOMification of the backend include, I simplified the IRQ
> handling in can_kvaser_pci (fixing bugs too I think), and removed an
> unnecessary mutex.  I also moved the files to net/can and hw/net/can so
> that in the future Jason (networking maintainer) can take care of pull
> requests.
>
> I might have broken something, and the top commit in particular is
> completely untested.

I have run basic test with Linux kernel on both sides
for one kavser_pci card on guest side and vcan (no real interface)
on host side.

Mesages exchange tests passed and looks OK.

I have used next parameters

  -object can-bus,id=canbus0 \
  -device kvaser_pci,canbus=canbus0 \
  -object can-host-socketcan,if=can0,canbus=canbus0,id=canbus0-socketcan

The id parameter is required for "can-host-socketcan" object.
Else next error is printed

  qemu-system-x86_64: -object can-host-socketcan,if=can0,canbus=canbus0: 
Parameter 'id' is missing

If "-object can-bus,id=canbus0" is missing then next error is reported

  qemu-system-x86_64: -object 
can-host-socketcan,if=can0,canbus=canbus0,id=canbus0-socketcan: Device 
'canbus0' not found

I have inspected through monitor the state of objects

  (qemu) qom-list /objects
  canbus0-socketcan (child)
  type (string)
  canbus0 (child)

  (qemu) info qom-tree
  /machine (pc-i440fx-2.12-machine)
...
/peripheral-anon (container)
  /device[1] (kvaser_pci)
/bus master[0] (qemu:memory-region)
/kvaser_pci-xilinx[0] (qemu:memory-region)
/kvaser_pci-s5920[0] (qemu:memory-region)
/kvaser_pci-sja[0] (qemu:memory-region)
/bus master container[0] (qemu:memory-region)
...


  (qemu) qom-list /objects
  canbus0-socketcan (child)
  type (string)
  canbus0 (child)

  (qemu) qom-list /machine/peripheral-anon/device[1]
  bus master container[0] (child)
  canbus (link)
  rombar (uint32)
  hotpluggable (bool)
  x-pcie-lnksta-dllla (bool)
  kvaser_pci-sja[0] (child)
  multifunction (bool)
  hotplugged (bool)
  parent_bus (link)
  romfile (str)
  kvaser_pci-s5920[0] (child)
  x-pcie-extcap-init (bool)
  command_serr_enable (bool)
  addr (int32)
  type (string)
  legacy-addr (str)
  kvaser_pci-xilinx[0] (child)
  realized (bool)
  bus master[0] (child)

From the user point of view, it would be nice if "can-bus"
can be populated when required automatically.

I am not sure, but may it be that it would worth to
push can-bus objects under some category/specific
container. The path /objects is quite wide.
Into something like /object/can-bus or /net/can.

But generally thanks much, the progress you have made
in one day is really great. I hope that others check
your branch. I have pushed your unmodified version into
"can-pci-qom" branch of my repo

  https://gitlab.fel.cvut.cz/canbus/qemu-canbus/tree/can-pci-qom

It would be great if others can check that everything
works in their setup. I think that then it can be pushed
into mainline and some usability improvements can be
done/experiment with later.

Thanks much,


Pavel Pisa

Re: [Qemu-devel] [PATCH v6 18/23] sev: emit the SEV_MEASUREMENT event

[Brijesh Singh]

On 1/30/18 2:08 PM, Dr. David Alan Gilbert wrote:
> * Brijesh Singh (brijesh.si...@amd.com) wrote:
>> During machine creation we encrypted the guest bios image, the
>> LAUNCH_MEASURE command can be used to retrieve the measurement of
>> the encrypted memory region. Emit the SEV_MEASUREMENT event so that
>> libvirt can grab the measurement value as soon as we are done with
>> creating the encrypted machine.
> Can you ust clarify what happens if the libvirt has disconnected and
> reconnected to qemu and so didn't see the event?  Can the reconnecting
> libvirt query it and find out it's ready/not ready yet?

Dave,

I have not looked into details between libvirt and qemu interaction to
comment how and when the events will be delivered. Recently, one of my
colleague was implementing libvirt interface for the SEV guest and ran
into somewhat a similar challenge and posted question on libvirt mailing
list [1].

In previous discussion on qemu mailing list, we agreed to implement SEV
MEASUREMENT event which can be seen by libvirt. That's what this patch
is doing.

But during the libvirt implementation it seems that qemu monitor
silently drops all the events before it get the first qmp_capabilities
command. At a quick glance it seems on reconnect, libvirt issues
qmp_capabilities command and any event issued before the
qmp_capabilities command will never to delivered to libvirt. we are
looking for  help from libvirt/qemu monitor experts on how we solve this
problem. Our goal is to provide the measurement to libvirt before
libvirt issues "continue" command. Since event can't be seen by libvirt
before it resumes the guest hence I was wondering if we should we should
drop the SEV measurement event and consider adding a new QMP command to
query the SEV measurement.

[1] https://www.redhat.com/archives/libvir-list/2018-January/msg00602.html

> Dave
>
>> Cc: Daniel P. Berrange 
>> Cc: Paolo Bonzini 
>> Cc: k...@vger.kernel.org
>> Signed-off-by: Brijesh Singh 
>> ---
>>  accel/kvm/sev.c| 58 
>> ++
>>  accel/kvm/trace-events |  1 +
>>  include/sysemu/sev.h   |  1 +
>>  3 files changed, 60 insertions(+)
>>
>> diff --git a/accel/kvm/sev.c b/accel/kvm/sev.c
>> index 1f757df725df..b78cf3144b1d 100644
>> --- a/accel/kvm/sev.c
>> +++ b/accel/kvm/sev.c
>> @@ -19,11 +19,13 @@
>>  #include "sysemu/sev.h"
>>  #include "sysemu/sysemu.h"
>>  #include "trace.h"
>> +#include "qapi-event.h"
>>  
>>  #define DEFAULT_GUEST_POLICY0x1 /* disable debug */
>>  #define DEFAULT_SEV_DEVICE  "/dev/sev"
>>  
>>  static int sev_fd;
>> +static SEVState *sev_state;
>>  
>>  #define SEV_FW_MAX_ERROR  0x17
>>  
>> @@ -418,6 +420,59 @@ err:
>>  return ret;
>>  }
>>  
>> +static void
>> +sev_launch_get_measure(Notifier *notifier, void *unused)
>> +{
>> +int ret, error;
>> +guchar *data;
>> +SEVState *s = sev_state;
>> +struct kvm_sev_launch_measure *measurement;
>> +
>> +measurement = g_malloc0(sizeof(*measurement));
>> +if (!measurement) {
>> +return;
>> +}
>> +
>> +/* query the measurement blob length */
>> +ret = sev_ioctl(KVM_SEV_LAUNCH_MEASURE, measurement, );
>> +if (!measurement->len) {
>> +error_report("%s: LAUNCH_MEASURE ret=%d fw_error=%d '%s'",
>> + __func__, ret, error, fw_error_to_str(errno));
>> +goto free_measurement;
>> +}
>> +
>> +data = g_malloc(measurement->len);
>> +if (s->measurement) {
>> +goto free_data;
>> +}
>> +
>> +measurement->uaddr = (unsigned long)data;
>> +
>> +/* get the measurement blob */
>> +ret = sev_ioctl(KVM_SEV_LAUNCH_MEASURE, measurement, );
>> +if (ret) {
>> +error_report("%s: LAUNCH_MEASURE ret=%d fw_error=%d '%s'",
>> + __func__, ret, error, fw_error_to_str(errno));
>> +goto free_data;
>> +}
>> +
>> +sev_set_guest_state(SEV_STATE_SECRET);
>> +
>> +/* encode the measurement value and emit the event */
>> +s->measurement = g_base64_encode(data, measurement->len);
>> +trace_kvm_sev_launch_measurement(s->measurement);
>> +qapi_event_send_sev_measurement(s->measurement, _abort);
>> +
>> +free_data:
>> +g_free(data);
>> +free_measurement:
>> +g_free(measurement);
>> +}
>> +
>> +static Notifier sev_machine_done_notify = {
>> +.notify = sev_launch_get_measure,
>> +};
>> +
>>  void *
>>  sev_guest_init(const char *id)
>>  {
>> @@ -461,6 +516,9 @@ sev_guest_init(const char *id)
>>  }
>>  
>>  ram_block_notifier_add(_ram_notifier);
>> +qemu_add_machine_init_done_notifier(_machine_done_notify);
>> +
>> +sev_state = s;
>>  
>>  return s;
>>  err:
>> diff --git a/accel/kvm/trace-events b/accel/kvm/trace-events
>> index c55546f36a25..51df5113ad07 100644
>> --- a/accel/kvm/trace-events
>> +++ b/accel/kvm/trace-events
>> @@ -20,3 +20,4 @@ kvm_memcrypt_unregister_region(void *addr, 

Re: [Qemu-devel] [PATCH v6 02/23] exec: add ram_debug_ops support

[Edgar E. Iglesias]

On Mon, Jan 29, 2018 at 11:41:11AM -0600, Brijesh Singh wrote:
> Currently, the guest memory access for the debug purpose is performed
> using the memcpy(). Lets extend the 'struct MemoryRegion' to include
> ram_debug_ops callbacks. The ram_debug_ops can be used to override
> memcpy() with something else.
> 
> The feature can be used by encrypted guest -- which can register
> callbacks to override memcpy() with memory encryption/decryption APIs.
> 
> a typical usage:
> 
> mem_read(uint8_t *dst, uint8_t *src, uint32_t len, MemTxAttrs *attrs);
> mem_write(uint8_t *dst, uint8_t *src, uint32_t len, MemTxAttrs *attrs);
> 
> MemoryRegionRAMReadWriteOps ops;
> ops.read = mem_read;
> ops.write = mem_write;


Hi,

Do these really need to be RAM specific (ram_debug_ops -> debug_ops) ?
I was hoping a similar infrastructure could be used for MMIO
debug accesses.

Best regards,
Edgar



> 
> memory_region_init_ram(mem, NULL, "memory", size, NULL);
> memory_region_set_ram_debug_ops(mem, ops);
> 
> Cc: Paolo Bonzini 
> Cc: Peter Crosthwaite 
> Cc: Richard Henderson 
> Signed-off-by: Brijesh Singh 
> ---
>  exec.c| 66 
> ++-
>  include/exec/memory.h | 27 +
>  2 files changed, 77 insertions(+), 16 deletions(-)
> 
> diff --git a/exec.c b/exec.c
> index 629a5083851d..1919052b7385 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -3050,7 +3050,11 @@ static MemTxResult flatview_write_continue(FlatView 
> *fv, hwaddr addr,
>  } else {
>  /* RAM case */
>  ptr = qemu_ram_ptr_length(mr->ram_block, addr1, , false);
> -memcpy(ptr, buf, l);
> +if (attrs.debug && mr->ram_debug_ops) {
> +mr->ram_debug_ops->write(ptr, buf, l, attrs);
> +} else {
> +memcpy(ptr, buf, l);
> +}
>  invalidate_and_set_dirty(mr, addr1, l);
>  }
>  
> @@ -3148,7 +3152,11 @@ MemTxResult flatview_read_continue(FlatView *fv, 
> hwaddr addr,
>  } else {
>  /* RAM case */
>  ptr = qemu_ram_ptr_length(mr->ram_block, addr1, , false);
> -memcpy(buf, ptr, l);
> +if (attrs.debug && mr->ram_debug_ops) {
> +mr->ram_debug_ops->read(buf, ptr, l, attrs);
> +} else {
> +memcpy(buf, ptr, l);
> +}
>  }
>  
>  if (release_lock) {
> @@ -3218,11 +3226,13 @@ void cpu_physical_memory_rw(hwaddr addr, uint8_t *buf,
>  
>  enum write_rom_type {
>  WRITE_DATA,
> +READ_DATA,
>  FLUSH_CACHE,
>  };
>  
> -static inline void cpu_physical_memory_write_rom_internal(AddressSpace *as,
> -hwaddr addr, const uint8_t *buf, int len, enum write_rom_type type)
> +static inline void cpu_physical_memory_rw_internal(AddressSpace *as,
> +hwaddr addr, uint8_t *buf, int len, MemTxAttrs attrs,
> +enum write_rom_type type)
>  {
>  hwaddr l;
>  uint8_t *ptr;
> @@ -3237,12 +3247,33 @@ static inline void 
> cpu_physical_memory_write_rom_internal(AddressSpace *as,
>  if (!(memory_region_is_ram(mr) ||
>memory_region_is_romd(mr))) {
>  l = memory_access_size(mr, l, addr1);
> +/* Pass MMIO down to address address_space_rw */
> +switch (type) {
> +case READ_DATA:
> +case WRITE_DATA:
> +address_space_rw(as, addr1, attrs, buf, l,
> + type == WRITE_DATA);
> +break;
> +case FLUSH_CACHE:
> +break;
> +}
>  } else {
>  /* ROM/RAM case */
>  ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
>  switch (type) {
> +case READ_DATA:
> +if (mr->ram_debug_ops) {
> +mr->ram_debug_ops->read(buf, ptr, l, attrs);
> +} else {
> +memcpy(buf, ptr, l);
> +}
> +break;
>  case WRITE_DATA:
> -memcpy(ptr, buf, l);
> +if (mr->ram_debug_ops) {
> +mr->ram_debug_ops->write(ptr, buf, l, attrs);
> +} else {
> +memcpy(ptr, buf, l);
> +}
>  invalidate_and_set_dirty(mr, addr1, l);
>  break;
>  case FLUSH_CACHE:
> @@ -3261,7 +3292,8 @@ static inline void 
> cpu_physical_memory_write_rom_internal(AddressSpace *as,
>  void cpu_physical_memory_write_rom(AddressSpace *as, hwaddr addr,
> const uint8_t *buf, int len)
>  {
> -cpu_physical_memory_write_rom_internal(as, addr, buf, len, WRITE_DATA);
> +cpu_physical_memory_rw_internal(as, addr, (uint8_t *)buf, len,
> +MEMTXATTRS_UNSPECIFIED, WRITE_DATA);
>  }
>  
>  void cpu_flush_icache_range(hwaddr start, int 

Re: [Qemu-devel] [PATCH v6 01/23] memattrs: add debug attribute

[Edgar E. Iglesias]

On Mon, Jan 29, 2018 at 11:41:10AM -0600, Brijesh Singh wrote:
> Extend the MemTxAttrs to include 'debug' flag. The flag can be used as
> general indicator that operation was triggered by the debugger.
> 
> Later in the patch series we set the debug=1 when issuing a memory access
> from the gdbstub or HMP commands. This patch is prerequisite to support
> debugging the encrypted guest. If we see request with debug=1 then we
> will need to use encryption APIs to access the guest memory.
> 
> Cc: Alistair Francis 
> Cc: Peter Maydell 
> Cc: Edgar E. Iglesias" 
> Cc: Richard Henderson 
> Cc: Paolo Bonzini 
> Signed-off-by: Brijesh Singh 

Reviewed-by: Edgar E. Iglesias 


> ---
>  include/exec/memattrs.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/exec/memattrs.h b/include/exec/memattrs.h
> index d4a16420984b..08099e4f7e72 100644
> --- a/include/exec/memattrs.h
> +++ b/include/exec/memattrs.h
> @@ -37,6 +37,8 @@ typedef struct MemTxAttrs {
>  unsigned int user:1;
>  /* Requester ID (for MSI for example) */
>  unsigned int requester_id:16;
> +/* Memory access request from the debugger */
> +unsigned int debug:1;
>  } MemTxAttrs;
>  
>  /* Bus masters which don't specify any attributes will get this,
> -- 
> 2.9.5
> 

Re: [Qemu-devel] [PATCH v6 05/23] target/i386: add memory encryption feature cpuid support

[Brijesh Singh]

On 1/30/18 11:49 AM, Dr. David Alan Gilbert wrote:
> * Brijesh Singh (brijesh.si...@amd.com) wrote:
>> AMD EPYC processors support memory encryption feature. The feature
>> is reported through CPUID 8000_001F[EAX].
>>
>> Fn8000_001F [EAX]:
>>  Bit 0   Secure Memory Encryption (SME) supported
>>  Bit 1   Secure Encrypted Virtualization (SEV) supported
>>  Bit 2   Page flush MSR supported
>>  Bit 3   Ecrypted State (SEV-ES) support
>>
>> when memory encryption feature is reported, CPUID 8000_001F[EBX] should
>> provide additional information regarding the feature (such as which page
>> table bit is used to mark pages as encrypted etc). The information in EBX
>> and ECX may vary from one family to another hence we use the host cpuid
>> to populate the EBX information.
> That's going to make it interesting for migration.  If the guest needs
> to know that C-bit position then you presumably can't migrate between
> those two host types, but we wouldn't have anything that currently
> stops us.
> We already have similar problems with variations in physical address
> size but normally get away with that, especially on smaller VMs.

Dave,

While building the page tables guest need to know the C-bit position.
The C-bit position in the guest is same as C-bit position on the host.
For migration case, we should be able to migrate SEV guest on same host
type (i.e all EPYC and Ryzen CPUs are based on family 17 and we should
be okay migrating the SEV guests among those host types).  Since C-bit
position is not fixed hence migrating to different host family will be
an issue.

-Brijesh
> Dave
>
>
>> The details for memory encryption CPUID is available in AMD APM
>> (http://support.amd.com/TechDocs/24593.pdf) Section 15.34.1
>> Cc: Paolo Bonzini 
>> Cc: Richard Henderson 
>> Cc: Eduardo Habkost 
>> Signed-off-by: Brijesh Singh 
>> ---
>>  target/i386/cpu.c | 36 
>>  target/i386/cpu.h |  6 ++
>>  2 files changed, 42 insertions(+)
>>
>> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
>> index a49d2221adc9..4147eb6e18a9 100644
>> --- a/target/i386/cpu.c
>> +++ b/target/i386/cpu.c
>> @@ -234,6 +234,7 @@ static void x86_cpu_vendor_words2str(char *dst, uint32_t 
>> vendor1,
>>  #define TCG_EXT4_FEATURES 0
>>  #define TCG_SVM_FEATURES 0
>>  #define TCG_KVM_FEATURES 0
>> +#define TCG_MEM_ENCRYPT_FEATURES 0
>>  #define TCG_7_0_EBX_FEATURES (CPUID_7_0_EBX_SMEP | CPUID_7_0_EBX_SMAP | \
>>CPUID_7_0_EBX_BMI1 | CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_ADX | \
>>CPUID_7_0_EBX_PCOMMIT | CPUID_7_0_EBX_CLFLUSHOPT |\
>> @@ -545,6 +546,20 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] 
>> = {
>>  .cpuid_reg = R_EDX,
>>  .tcg_features = ~0U,
>>  },
>> +[FEAT_MEM_ENCRYPT] = {
>> +.feat_names = {
>> +"sme", "sev", "page-flush-msr", "sev-es",
>> +NULL, NULL, NULL, NULL,
>> +NULL, NULL, NULL, NULL,
>> +NULL, NULL, NULL, NULL,
>> +NULL, NULL, NULL, NULL,
>> +NULL, NULL, NULL, NULL,
>> +NULL, NULL, NULL, NULL,
>> +NULL, NULL, NULL, NULL,
>> +},
>> +.cpuid_eax = 0x801F, .cpuid_reg = R_EAX,
>> +.tcg_features = TCG_MEM_ENCRYPT_FEATURES,
>> +}
>>  };
>>  
>>  typedef struct X86RegisterInfo32 {
>> @@ -1965,6 +1980,9 @@ static X86CPUDefinition builtin_x86_defs[] = {
>>  CPUID_XSAVE_XGETBV1,
>>  .features[FEAT_6_EAX] =
>>  CPUID_6_EAX_ARAT,
>> +/* Missing: SEV_ES */
>> +.features[FEAT_MEM_ENCRYPT] =
>> +CPUID_8000_001F_EAX_SME | CPUID_8000_001F_EAX_SEV,
>>  .xlevel = 0x800A,
>>  .model_id = "AMD EPYC Processor",
>>  },
>> @@ -3589,6 +3607,19 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, 
>> uint32_t count,
>>  *edx = 0;
>>  }
>>  break;
>> +case 0x801F:
>> +if (env->features[FEAT_MEM_ENCRYPT] & CPUID_8000_001F_EAX_SEV) {
>> +*eax = env->features[FEAT_MEM_ENCRYPT];
>> +host_cpuid(0x801F, 0, NULL, ebx, NULL, NULL);
>> +*ecx = 0;
>> +*edx = 0;
>> +} else {
>> +*eax = 0;
>> +*ebx = 0;
>> +*ecx = 0;
>> +*edx = 0;
>> +}
>> +break;
>>  case 0xC000:
>>  *eax = env->cpuid_xlevel2;
>>  *ebx = 0;
>> @@ -4036,10 +4067,15 @@ static void x86_cpu_expand_features(X86CPU *cpu, 
>> Error **errp)
>>  x86_cpu_adjust_feat_level(cpu, FEAT_C000_0001_EDX);
>>  x86_cpu_adjust_feat_level(cpu, FEAT_SVM);
>>  x86_cpu_adjust_feat_level(cpu, FEAT_XSAVE);
>> +x86_cpu_adjust_feat_level(cpu, FEAT_MEM_ENCRYPT);
>>  /* SVM requires CPUID[0x800A] */
>>  if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) {
>>  

Re: [Qemu-devel] [PATCH 00/18] Clean up includes to reduce compile time

[no-reply]

Hi,

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

Type: series
Message-id: 20180130102202.28519-1-arm...@redhat.com
Subject: [Qemu-devel] [PATCH 00/18] Clean up includes to reduce compile time

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
b82040d7c2 Move include qemu/option.h from qemu-common.h to actual users
35c5d79dfc Drop superfluous includes of qapi/qmp/qjson.h
08042c2c46 Drop superfluous includes of qapi/qmp/dispatch.h
490c58458e Include qapi/qmp/qnull.h exactly where needed
661e629169 Include qapi/qmp/qnum.h exactly where needed
b2a77fa265 Include qapi/qmp/qbool.h exactly where needed
2083f5d04d Include qapi/qmp/qstring.h exactly where needed
4dacfa5ea1 Include qapi/qmp/qdict.h exactly where needed
40d80b9c49 Include qapi/qmp/qlist.h exactly where needed
b1aa592bef Include qapi/qmp/qobject.h exactly where needed
23f8be7488 qdict qlist: Make most helper macros functions
92f9da25c9 Eliminate qapi/qmp/types.h
8d457a8644 Typedef the subtypes of QObject in qemu/typedefs.h, too
1c6de32770 Include qmp-commands.h exactly where needed
6813f055bb Drop superfluous includes of qapi/qmp/qerror.h
f93b76ad10 Include qapi/error.h exactly where needed
5f1752d1f5 Drop superfluous includes of qapi-types.h
772b091f1c Clean up includes

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into '/var/tmp/patchew-tester-tmp-r8up9vt2/src/dtc'...
Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42'
  BUILD   fedora
  GEN 
/var/tmp/patchew-tester-tmp-r8up9vt2/src/docker-src.2018-01-30-08.37.51.23589/qemu.tar
Cloning into 
'/var/tmp/patchew-tester-tmp-r8up9vt2/src/docker-src.2018-01-30-08.37.51.23589/qemu.tar.vroot'...
done.
Your branch is up-to-date with 'origin/test'.
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 
'/var/tmp/patchew-tester-tmp-r8up9vt2/src/docker-src.2018-01-30-08.37.51.23589/qemu.tar.vroot/dtc'...
Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42'
Submodule 'ui/keycodemapdb' (git://git.qemu.org/keycodemapdb.git) registered 
for path 'ui/keycodemapdb'
Cloning into 
'/var/tmp/patchew-tester-tmp-r8up9vt2/src/docker-src.2018-01-30-08.37.51.23589/qemu.tar.vroot/ui/keycodemapdb'...
Submodule path 'ui/keycodemapdb': checked out 
'10739aa26051a5d49d88132604539d3ed085e72e'
  COPYRUNNER
RUN test-mingw in qemu:fedora 
Packages installed:
PyYAML-3.11-13.fc25.x86_64
SDL-devel-1.2.15-21.fc24.x86_64
bc-1.06.95-16.fc24.x86_64
bison-3.0.4-4.fc24.x86_64
bzip2-1.0.6-21.fc25.x86_64
ccache-3.3.4-1.fc25.x86_64
clang-3.9.1-2.fc25.x86_64
findutils-4.6.0-8.fc25.x86_64
flex-2.6.0-3.fc25.x86_64
gcc-6.4.1-1.fc25.x86_64
gcc-c++-6.4.1-1.fc25.x86_64
gettext-0.19.8.1-3.fc25.x86_64
git-2.9.5-3.fc25.x86_64
glib2-devel-2.50.3-1.fc25.x86_64
hostname-3.15-8.fc25.x86_64
libaio-devel-0.3.110-6.fc24.x86_64
libasan-6.4.1-1.fc25.x86_64
libfdt-devel-1.4.2-1.fc25.x86_64
libubsan-6.4.1-1.fc25.x86_64
make-4.1-6.fc25.x86_64
mingw32-SDL-1.2.15-7.fc24.noarch
mingw32-bzip2-1.0.6-7.fc24.noarch
mingw32-curl-7.47.0-1.fc24.noarch
mingw32-glib2-2.50.3-1.fc25.noarch
mingw32-gmp-6.1.1-1.fc25.noarch
mingw32-gnutls-3.5.5-2.fc25.noarch
mingw32-gtk2-2.24.31-2.fc25.noarch
mingw32-gtk3-3.22.17-1.fc25.noarch
mingw32-libjpeg-turbo-1.5.1-1.fc25.noarch
mingw32-libpng-1.6.27-1.fc25.noarch
mingw32-libssh2-1.4.3-5.fc24.noarch
mingw32-libtasn1-4.9-1.fc25.noarch
mingw32-nettle-3.3-1.fc25.noarch
mingw32-pixman-0.34.0-1.fc25.noarch
mingw32-pkg-config-0.28-6.fc24.x86_64
mingw64-SDL-1.2.15-7.fc24.noarch
mingw64-bzip2-1.0.6-7.fc24.noarch
mingw64-curl-7.47.0-1.fc24.noarch
mingw64-glib2-2.50.3-1.fc25.noarch
mingw64-gmp-6.1.1-1.fc25.noarch
mingw64-gnutls-3.5.5-2.fc25.noarch
mingw64-gtk2-2.24.31-2.fc25.noarch
mingw64-gtk3-3.22.17-1.fc25.noarch
mingw64-libjpeg-turbo-1.5.1-1.fc25.noarch
mingw64-libpng-1.6.27-1.fc25.noarch
mingw64-libssh2-1.4.3-5.fc24.noarch
mingw64-libtasn1-4.9-1.fc25.noarch
mingw64-nettle-3.3-1.fc25.noarch
mingw64-pixman-0.34.0-1.fc25.noarch
mingw64-pkg-config-0.28-6.fc24.x86_64
nettle-devel-3.3-1.fc25.x86_64
package python2 is not installed
perl-5.24.3-389.fc25.x86_64
pixman-devel-0.34.0-2.fc24.x86_64
sparse-0.5.0-10.fc25.x86_64
tar-1.29-3.fc25.x86_64
which-2.21-1.fc25.x86_64
zlib-devel-1.2.8-10.fc24.x86_64

Environment variables:
PACKAGES=ccache gettext git tar PyYAML sparse flex bison python2 bzip2 hostname 
glib2-devel pixman-devel zlib-devel SDL-devel libfdt-devel gcc gcc-c++ 
clang make perl which bc findutils libaio-devel nettle-devel libasan 
libubsan mingw32-pixman mingw32-glib2 mingw32-gmp mingw32-SDL 

[Qemu-devel] [Bug 1186984] Re: large -initrd can wrap around in memory causing memory corruption

[Thomas Huth]

Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  large -initrd can wrap around in memory causing memory corruption

Status in QEMU:
  Incomplete

Bug description:
  We don't use large -initrd in libguestfs any more, but I noticed that
  a large -initrd file now crashes qemu spectacularly:

  $ ls -lh /tmp/kernel /tmp/initrd 
  -rw-r--r--. 1 rjones rjones 273M Jun  3 14:02 /tmp/initrd
  lrwxrwxrwx. 1 rjones rjones   35 Jun  3 14:02 /tmp/kernel -> 
/boot/vmlinuz-3.9.4-200.fc18.x86_64

  $ ./x86_64-softmmu/qemu-system-x86_64 -L pc-bios \
  -kernel /tmp/kernel -initrd /tmp/initrd -hda /tmp/test1.img -serial stdio 
\
  -append console=ttyS0

  qemu crashes with one of several errors:

  PFLASH: Possible BUG - Write block confirm

  qemu: fatal: Trying to execute code outside RAM or ROM at
  0x000b96cd

  If -enable-kvm is used:

  KVM: injection failed, MSI lost (Operation not permitted)

  In all cases the SDL display fills up with coloured blocks before the
  crash (see the attached screenshot).

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

[Qemu-devel] [Bug 1186303] Re: virtual fat do not working in qemu 1.5.0

[Thomas Huth]

Triaging old bug tickets... Have you ever bisected the problem? Can you
still reproduce this issue with the latest version of QEMU? Or could we
close this ticket nowadays?

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  virtual fat do not working in qemu 1.5.0

Status in QEMU:
  Incomplete

Bug description:
  Guest : windows Seven / XP
  Qemu version : 1.5.0 
  cmd line : 
  -drive 
file=fat:floppy:/mnt/vdisk/diskconf/TEST004/,if=none,id=drive-fdc0-0-0,readonly=on
 
  generated by  libvirt :
   
  






  

  works with qemu <= 1.4.1

  with qemu 1.5.0 , guest does not see the floppy content.

  Regards

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

[Qemu-devel] [Bug 1084148] Re: Qt5 Beta 1 QProcess start and execute causes segmentation fault on armhf

[Thomas Huth]

Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  Qt5 Beta 1 QProcess start and execute causes segmentation fault on
  armhf

Status in QEMU:
  Incomplete
Status in Linaro QEMU:
  Confirmed

Bug description:
  Steps
  1) pbuilder-dist quantal armhf create
  2) add ppa from 
https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta1 to the pbuilder
  2.0) pbuilder-dist quantal armhf login
  2.1) apt-get install software-properties-common
  2.2) apt-add-repository ppa:canonical-qt5-edgers/qt5-beta1
  2.3) apt-get update
  3) apt-get install qtbase qtdeclarative qttools bzr
  4) bzr branch lp:~juhapekka-piiroinen/+junk/qemu-crash
  5) cd qemu-crash; /opt/qt5/bin/qmake; make; ./untitled

  Expected Result:
  Would execute 'ls'

  Actual result:
  # ./untitled 
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault (core dumped)

  Note: this code works on i386, amd64 and armel.

  Packages:
  $ apt-cache policy qemu-user-static
  qemu-user-static:
Installed: 1.2.0-2012.09-0ubuntu1
Candidate: 1.2.0-2012.09-0ubuntu1
Version table:
   *** 1.2.0-2012.09-0ubuntu1 0
  500 http://fi.archive.ubuntu.com/ubuntu/ quantal/universe amd64 
Packages
  100 /var/lib/dpkg/status
   1.2.0-2012.09-0ubuntu1~linaro1 0
  500 http://ppa.launchpad.net/linaro-maintainers/tools/ubuntu/ 
quantal/main amd64 Packages

  # apt-cache policy qtbase
  qtbase:
Installed: 5.0-release~beta+20120831-1ubuntu54
Candidate: 5.0-release~beta+20120831-1ubuntu54
Version table:
   *** 5.0-release~beta+20120831-1ubuntu54 0
  500 http://ppa.launchpad.net/canonical-qt5-edgers/qt5-beta1/ubuntu/ 
quantal/main armhf Packages
  100 /var/lib/dpkg/status

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

[Qemu-devel] [Bug 1175513] Re: Qemu 1.5-git gpu clock control doesn`t work after guest reboot

[Thomas Huth]

Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  Qemu 1.5-git gpu clock control doesn`t work after guest reboot

Status in Linux:
  New
Status in QEMU:
  Incomplete

Bug description:
  I run qemu from git with such command:

  qemu-system-x86_64 -nodefaults -m 4096 -smp 8,cores=4,threads=2,sockets=1 
-cpu 'kvm64' -device usb-mouse -M q35 -vga qxl -no-hpet -boot once=c,menu=on 
-device vfio-pci,host=02:00.0,x-vga=on \
  -enable-kvm -monitor stdio -chardev 
socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtio-serial -device 
virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -net 
nic,vlan=0,model=e1000 -net tap,ifname=tap0,script=/etc/guest-ifup -usb -device 
intel-hda -device hda-duplex \
  -drive 
file='/home//qemu/win7',if=none,id=drive-virtio-disk0,cache=writeback,aio=native,format=qed,discard=on
 -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk \
  -drive 
file='/dev/sr0',if=none,id=drive-ide1-0-0,media=cdrom,snapshot=off,format=raw 
-device ide-drive,bus=ide.1,unit=0,drive=drive-ide1-0-0,id=ide1-0-0 \
  -spice port=5930,disable-ticketing

  Before guest (Windows 7) reboot, videocard works in 3D mode with full
  frequency. But after reboot videocard works in 3D only with powersafe
  frequency. Then I must reboot host for recover gpu clock control.

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

Re: [Qemu-devel] [PATCH] block/mirror: change the semantic of 'force' of block-job-cancel

[John Snow]

On 01/30/2018 03:18 PM, John Snow wrote:
> 
> 
> On 01/30/2018 03:38 AM, Liang Li wrote:
>> When doing drive mirror to a low speed shared storage, if there was heavy
>> BLK IO write workload in VM after the 'ready' event, drive mirror block job
>> can't be canceled immediately, it would keep running until the heavy BLK IO
>> workload stopped in the VM.
>>
>> Because libvirt depends on block-job-cancel for block live migration, the
>> current block-job-cancel has the semantic to make sure data is in sync after
>> the 'ready' event.  This semantic can't meet some requirement, for example,
>> people may use drive mirror for realtime backup while need the ability of
>> block live migration. If drive mirror can't not be cancelled immediately,
>> it means block live migration need to wait, because libvirt make use drive
>> mirror to implement block live migration and only one drive mirror block
>> job is allowed at the same time for a give block dev.
>>
>> We need a new interface for 'force cancel', which could quit block job
>> immediately if don't care about whether data is in sync or not.
>>
>> 'force' is not used by libvirt currently, to make things simple, change
>> it's semantic slightly, hope it will not break some use case which need its
>> original semantic.
>>
>> Cc: Paolo Bonzini 
>> Cc: Jeff Cody 
>> Cc: Kevin Wolf 
>> Cc: Max Reitz 
>> Cc: Eric Blake 
>> Cc: John Snow 
>> Reported-by: Huaitong Han 
>> Signed-off-by: Huaitong Han 
>> Signed-off-by: Liang Li 
>> ---
>>  block/mirror.c|  9 +++--
>>  blockdev.c|  4 ++--
>>  blockjob.c| 11 ++-
>>  hmp-commands.hx   |  3 ++-
>>  include/block/blockjob.h  |  9 -
>>  qapi/block-core.json  |  6 --
>>  tests/test-blockjob-txn.c |  8 
>>  7 files changed, 29 insertions(+), 21 deletions(-)
>>
>> diff --git a/block/mirror.c b/block/mirror.c
>> index c9badc1..c22dff9 100644
>> --- a/block/mirror.c
>> +++ b/block/mirror.c
>> @@ -869,11 +869,8 @@ static void coroutine_fn mirror_run(void *opaque)
>>  
>>  ret = 0;
>>  trace_mirror_before_sleep(s, cnt, s->synced, delay_ns);
>> -if (!s->synced) {
>> -block_job_sleep_ns(>common, delay_ns);
>> -if (block_job_is_cancelled(>common)) {
>> -break;
>> -}
>> +if (block_job_is_cancelled(>common) && s->common.force) {
>> +break;
> 
> what's the justification for removing the sleep in the case that
> !s->synced && !block_job_is_cancelled(...) ?
> 
>>  } else if (!should_complete) {
>>  delay_ns = (s->in_flight == 0 && cnt == 0 ? SLICE_TIME : 0);
>>  block_job_sleep_ns(>common, delay_ns);
>> @@ -887,7 +884,7 @@ immediate_exit:
>>   * or it was cancelled prematurely so that we do not guarantee that
>>   * the target is a copy of the source.
>>   */
>> -assert(ret < 0 || (!s->synced && 
>> block_job_is_cancelled(>common)));
>> +assert(ret < 0 || block_job_is_cancelled(>common));
> 
> This assertion gets weaker in the case where force isn't provided, is
> that desired?
> 
>>  assert(need_drain);
>>  mirror_wait_for_all_io(s);
>>  }
>> diff --git a/blockdev.c b/blockdev.c
>> index 8e977ee..039f156 100644
>> --- a/blockdev.c
>> +++ b/blockdev.c
>> @@ -145,7 +145,7 @@ void blockdev_mark_auto_del(BlockBackend *blk)
>>  aio_context_acquire(aio_context);
>>  
>>  if (bs->job) {
>> -block_job_cancel(bs->job);
>> +block_job_cancel(bs->job, false);
>>  }
>>  
>>  aio_context_release(aio_context);
>> @@ -3802,7 +3802,7 @@ void qmp_block_job_cancel(const char *device,
>>  }
>>  
>>  trace_qmp_block_job_cancel(job);
>> -block_job_cancel(job);
>> +block_job_cancel(job, force);
>>  out:
>>  aio_context_release(aio_context);
>>  }
>> diff --git a/blockjob.c b/blockjob.c
>> index f5cea84..0aacb50 100644
>> --- a/blockjob.c
>> +++ b/blockjob.c
>> @@ -365,7 +365,7 @@ static void block_job_completed_single(BlockJob *job)
>>  block_job_unref(job);
>>  }
>>  
>> -static void block_job_cancel_async(BlockJob *job)
>> +static void block_job_cancel_async(BlockJob *job, bool force)
>>  {
>>  if (job->iostatus != BLOCK_DEVICE_IO_STATUS_OK) {
>>  block_job_iostatus_reset(job);
>> @@ -376,6 +376,7 @@ static void block_job_cancel_async(BlockJob *job)
>>  job->pause_count--;
>>  }
>>  job->cancelled = true;
>> +job->force = force;
>>  }
>>  
> 
> I suppose this is okay; we're setting a permanent property of the job as
> part of a limited operation.
> 
> Granted, the job should disappear afterwards, so it should never
> conflict, but it made me wonder for a moment.
> 
> What happens 

Re: [Qemu-devel] [PATCH v3] scripts/make-release: Don't archive .git files

[Thomas Huth]

On 30.01.2018 20:33, Cole Robinson wrote:
> As was last done in 379e21c25, we don't want .git files for
> submodules here, which we aren't presently doing for capstone and
> keycodemapdb.
> 
> Rather than delete the offending files before archiving, ask tar
> to --exclude=.git
> 
> Signed-off-by: Cole Robinson 
> ---
> v2:
> Use armbru's --exclude suggestion, requires tweaking
> existing tar options a bit.
> 
> v3:
> thuth's suggestion to use --exclude for both tar commands
> 
>  scripts/make-release | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/scripts/make-release b/scripts/make-release
> index 3917df7142..04fa9defdc 100755
> --- a/scripts/make-release
> +++ b/scripts/make-release
> @@ -19,11 +19,10 @@ pushd ${destination}
>  git checkout "v${version}"
>  git submodule update --init
>  (cd roms/seabios && git describe --tags --long --dirty > .version)
> -rm -rf .git roms/*/.git dtc/.git pixman/.git

Thanks, this also fixes the dead pixman/.git path :-)

Reviewed-by: Thomas Huth 

Re: [Qemu-devel] [PATCH v2 00/13] blockjob: refactor mirror_throttle

[John Snow]

ping;

I won't respin for patchew until this gets looked over again, sorry :)

On 01/19/2018 03:58 PM, John Snow wrote:
> mirror_throttle attempts to make sure we yield every so often when we're
> doing operations that may not otherwise be as cooperative as we'd like.
> 
> This pattern is useful to other jobs like commit as well; if commit
> continuously decides not to copy data (and calculates delay_ns to be 0),
> we'll frequently and aggressively yield, only to be rescheduled immediately.
> 
> This causes those "WARNING: I/O thread spun for 1000 iterations"
> warnings that everyone loves so much.
> 
> Split out the mirror_throttle function to become a new internal
> BlockJob API function, block_job_throttle; then use it for all
> the other jobs in their runtime loops.
> 
> I decided to use it in stream and backup as well, so that regardless of if the
> loop structure has the chance to be greedy or not (I did not audit this), the
> BlockJob has some kind of failsafe that will occasionally perform a 0ns sleep
> every SLICE_TIME.
> 
> v2:
>  - Fixed spacing consistency (Paolo)
>  - Renamed last_yield_ns to last_enter_ns (Stefan)
>  - Renamed block_job_throttle to block_job_relax (Stefan)
>  - Removed external usages of block_job_pause_point and
>block_job_sleep_ns (Paolo)
>  - Further cut down block/backup code to use block_job_relax
> 
> 
> 
> For convenience, this branch is available at:
> https://github.com/jnsnow/qemu.git branch block-job-yield
> https://github.com/jnsnow/qemu/tree/block-job-yield
> 
> This version is tagged block-job-yield-v2:
> https://github.com/jnsnow/qemu/releases/tag/block-job-yield-v2
> 
> John Snow (13):
>   blockjob: record time of last entrance
>   blockjob: consolidate SLICE_TIME definition
>   blockjob: create block_job_relax
>   blockjob: allow block_job_throttle to take delay_ns
>   block/commit: use block_job_relax
>   block/stream: use block_job_relax
>   block/backup: use block_job_relax
>   allow block_job_relax to return -ECANCELED
>   block/backup: remove yield_and_check
>   block/mirror: condense cancellation and relax calls
>   block/mirror: remove block_job_sleep_ns calls
>   blockjob: privatize block_job_sleep_ns
>   blockjob: remove block_job_pause_point from interface
> 
>  block/backup.c   | 27 ++-
>  block/commit.c   |  4 +---
>  block/mirror.c   | 52 
> +++-
>  block/stream.c   |  4 +---
>  block/trace-events   |  2 +-
>  blockjob.c   | 51 ---
>  include/block/blockjob.h |  5 +
>  include/block/blockjob_int.h | 37 +++
>  tests/test-bdrv-drain.c  |  2 +-
>  tests/test-blockjob-txn.c|  2 +-
>  10 files changed, 94 insertions(+), 92 deletions(-)
> 

Re: [Qemu-devel] [PATCH] block/mirror: change the semantic of 'force' of block-job-cancel

[John Snow]

On 01/30/2018 03:38 AM, Liang Li wrote:
> When doing drive mirror to a low speed shared storage, if there was heavy
> BLK IO write workload in VM after the 'ready' event, drive mirror block job
> can't be canceled immediately, it would keep running until the heavy BLK IO
> workload stopped in the VM.
> 
> Because libvirt depends on block-job-cancel for block live migration, the
> current block-job-cancel has the semantic to make sure data is in sync after
> the 'ready' event.  This semantic can't meet some requirement, for example,
> people may use drive mirror for realtime backup while need the ability of
> block live migration. If drive mirror can't not be cancelled immediately,
> it means block live migration need to wait, because libvirt make use drive
> mirror to implement block live migration and only one drive mirror block
> job is allowed at the same time for a give block dev.
> 
> We need a new interface for 'force cancel', which could quit block job
> immediately if don't care about whether data is in sync or not.
> 
> 'force' is not used by libvirt currently, to make things simple, change
> it's semantic slightly, hope it will not break some use case which need its
> original semantic.
> 
> Cc: Paolo Bonzini 
> Cc: Jeff Cody 
> Cc: Kevin Wolf 
> Cc: Max Reitz 
> Cc: Eric Blake 
> Cc: John Snow 
> Reported-by: Huaitong Han 
> Signed-off-by: Huaitong Han 
> Signed-off-by: Liang Li 
> ---
>  block/mirror.c|  9 +++--
>  blockdev.c|  4 ++--
>  blockjob.c| 11 ++-
>  hmp-commands.hx   |  3 ++-
>  include/block/blockjob.h  |  9 -
>  qapi/block-core.json  |  6 --
>  tests/test-blockjob-txn.c |  8 
>  7 files changed, 29 insertions(+), 21 deletions(-)
> 
> diff --git a/block/mirror.c b/block/mirror.c
> index c9badc1..c22dff9 100644
> --- a/block/mirror.c
> +++ b/block/mirror.c
> @@ -869,11 +869,8 @@ static void coroutine_fn mirror_run(void *opaque)
>  
>  ret = 0;
>  trace_mirror_before_sleep(s, cnt, s->synced, delay_ns);
> -if (!s->synced) {
> -block_job_sleep_ns(>common, delay_ns);
> -if (block_job_is_cancelled(>common)) {
> -break;
> -}
> +if (block_job_is_cancelled(>common) && s->common.force) {
> +break;

what's the justification for removing the sleep in the case that
!s->synced && !block_job_is_cancelled(...) ?

>  } else if (!should_complete) {
>  delay_ns = (s->in_flight == 0 && cnt == 0 ? SLICE_TIME : 0);
>  block_job_sleep_ns(>common, delay_ns);
> @@ -887,7 +884,7 @@ immediate_exit:
>   * or it was cancelled prematurely so that we do not guarantee that
>   * the target is a copy of the source.
>   */
> -assert(ret < 0 || (!s->synced && 
> block_job_is_cancelled(>common)));
> +assert(ret < 0 || block_job_is_cancelled(>common));

This assertion gets weaker in the case where force isn't provided, is
that desired?

>  assert(need_drain);
>  mirror_wait_for_all_io(s);
>  }
> diff --git a/blockdev.c b/blockdev.c
> index 8e977ee..039f156 100644
> --- a/blockdev.c
> +++ b/blockdev.c
> @@ -145,7 +145,7 @@ void blockdev_mark_auto_del(BlockBackend *blk)
>  aio_context_acquire(aio_context);
>  
>  if (bs->job) {
> -block_job_cancel(bs->job);
> +block_job_cancel(bs->job, false);
>  }
>  
>  aio_context_release(aio_context);
> @@ -3802,7 +3802,7 @@ void qmp_block_job_cancel(const char *device,
>  }
>  
>  trace_qmp_block_job_cancel(job);
> -block_job_cancel(job);
> +block_job_cancel(job, force);
>  out:
>  aio_context_release(aio_context);
>  }
> diff --git a/blockjob.c b/blockjob.c
> index f5cea84..0aacb50 100644
> --- a/blockjob.c
> +++ b/blockjob.c
> @@ -365,7 +365,7 @@ static void block_job_completed_single(BlockJob *job)
>  block_job_unref(job);
>  }
>  
> -static void block_job_cancel_async(BlockJob *job)
> +static void block_job_cancel_async(BlockJob *job, bool force)
>  {
>  if (job->iostatus != BLOCK_DEVICE_IO_STATUS_OK) {
>  block_job_iostatus_reset(job);
> @@ -376,6 +376,7 @@ static void block_job_cancel_async(BlockJob *job)
>  job->pause_count--;
>  }
>  job->cancelled = true;
> +job->force = force;
>  }
>  

I suppose this is okay; we're setting a permanent property of the job as
part of a limited operation.

Granted, the job should disappear afterwards, so it should never
conflict, but it made me wonder for a moment.

What happens if we cancel with force = true and then immediately cancel
again with force = false? What happens? Can it cause issues?

>  static int block_job_finish_sync(BlockJob *job,
> @@ -437,7 

Re: [Qemu-devel] SDL2 UI behavior of switching views

[BALATON Zoltan]

On Tue, 30 Jan 2018, Gerd Hoffmann wrote:

SDL1 has a single window for all consoles.
SDL2 has one window for each console.

Fixed.  Not switchable, neither for SDL1 nor for SDL2.

It sure is possible to make it runtime switchable, but I expect it is
more much difficuilt to code up when compared to gtk due to the lack of
widgets.  gtk has one widget per console, I can hook the console widgets
into my widget/window tree as I like and gtk handles alot of the
management for me.


I think it does not have to be runtime switchable in the sense that the 
setting does not need to be changable during run (like in gtk) because we 
don't have a UI for changing it anyway. It's enough to have an option to 
decide it once at startup, in case that's easier to implement. If not then 
I guess this will remain as it is now but it's unfortunate to change the 
previous behaviour with a version change for no good reason.



But feel free to try and send patches.


Unortunately I know nothing about this code and don't have time nor much 
inclination to learn it now. So unless you can at least give some hints on 
what would need to be done I can't send patches for this.



Can't see much of a difference here.  gtk has a menu bar, sdl hasn't,
otherwise the two look the same and most hotkeys are the same too.

Adding an option to hide the gtk menu bar shouldn't be much of an issue,
some code for that is already there as gtk hides the menu bar in
fullscreen mode.


There's also a version change going on on the gtk side moving from gtk 2 
to 3 which brought similar issues: old behaviour is changed and not 
working the same way any more, themes are broken, more dependencies 
introduced and so on. (Not specifically in QEMU but generally for all gtk 
apps.) Using SDL was also a way to avoid those problems, but then it all 
happens there again.



I think at the end of the day it boils down to personal preference.
Which is perfectly fine.  But it needs someone who finds sdl important
enough to step up and care about it.


I think people who used SDL so far were happy with the way it worked 
before and that's why there wasn't a need to change until now that a 
version update brought unexpected UI changes.


Regards,
BALATON Zoltan

Re: [Qemu-devel] [PATCH] block/mirror: change the semantic of 'force' of block-job-cancel

[John Snow]

On 01/30/2018 03:38 AM, Liang Li wrote:
> When doing drive mirror to a low speed shared storage, if there was heavy
> BLK IO write workload in VM after the 'ready' event, drive mirror block job
> can't be canceled immediately, it would keep running until the heavy BLK IO
> workload stopped in the VM.
> 
> Because libvirt depends on block-job-cancel for block live migration, the
> current block-job-cancel has the semantic to make sure data is in sync after
> the 'ready' event.  This semantic can't meet some requirement, for example,
> people may use drive mirror for realtime backup while need the ability of
> block live migration. If drive mirror can't not be cancelled immediately,
> it means block live migration need to wait, because libvirt make use drive
> mirror to implement block live migration and only one drive mirror block
> job is allowed at the same time for a give block dev.
> 
> We need a new interface for 'force cancel', which could quit block job
> immediately if don't care about whether data is in sync or not.
> 
> 'force' is not used by libvirt currently, to make things simple, change
> it's semantic slightly, hope it will not break some use case which need its
> original semantic.
> 
> Cc: Paolo Bonzini 
> Cc: Jeff Cody 
> Cc: Kevin Wolf 
> Cc: Max Reitz 
> Cc: Eric Blake 
> Cc: John Snow 
> Reported-by: Huaitong Han 
> Signed-off-by: Huaitong Han 
> Signed-off-by: Liang Li 

Just a note to JTC that this will conflict with my two series trying to
refactor jobs:

(1) [Qemu-devel] [PATCH v2 00/13] blockjob: refactor mirror_throttle
(2) [Qemu-devel] [RFC v3 00/14] blockjobs: add explicit job management​

Re: [Qemu-devel] [PATCH v6 18/23] sev: emit the SEV_MEASUREMENT event

[Dr. David Alan Gilbert]

* Brijesh Singh (brijesh.si...@amd.com) wrote:
> During machine creation we encrypted the guest bios image, the
> LAUNCH_MEASURE command can be used to retrieve the measurement of
> the encrypted memory region. Emit the SEV_MEASUREMENT event so that
> libvirt can grab the measurement value as soon as we are done with
> creating the encrypted machine.

Can you ust clarify what happens if the libvirt has disconnected and
reconnected to qemu and so didn't see the event?  Can the reconnecting
libvirt query it and find out it's ready/not ready yet?

Dave

> Cc: Daniel P. Berrange 
> Cc: Paolo Bonzini 
> Cc: k...@vger.kernel.org
> Signed-off-by: Brijesh Singh 
> ---
>  accel/kvm/sev.c| 58 
> ++
>  accel/kvm/trace-events |  1 +
>  include/sysemu/sev.h   |  1 +
>  3 files changed, 60 insertions(+)
> 
> diff --git a/accel/kvm/sev.c b/accel/kvm/sev.c
> index 1f757df725df..b78cf3144b1d 100644
> --- a/accel/kvm/sev.c
> +++ b/accel/kvm/sev.c
> @@ -19,11 +19,13 @@
>  #include "sysemu/sev.h"
>  #include "sysemu/sysemu.h"
>  #include "trace.h"
> +#include "qapi-event.h"
>  
>  #define DEFAULT_GUEST_POLICY0x1 /* disable debug */
>  #define DEFAULT_SEV_DEVICE  "/dev/sev"
>  
>  static int sev_fd;
> +static SEVState *sev_state;
>  
>  #define SEV_FW_MAX_ERROR  0x17
>  
> @@ -418,6 +420,59 @@ err:
>  return ret;
>  }
>  
> +static void
> +sev_launch_get_measure(Notifier *notifier, void *unused)
> +{
> +int ret, error;
> +guchar *data;
> +SEVState *s = sev_state;
> +struct kvm_sev_launch_measure *measurement;
> +
> +measurement = g_malloc0(sizeof(*measurement));
> +if (!measurement) {
> +return;
> +}
> +
> +/* query the measurement blob length */
> +ret = sev_ioctl(KVM_SEV_LAUNCH_MEASURE, measurement, );
> +if (!measurement->len) {
> +error_report("%s: LAUNCH_MEASURE ret=%d fw_error=%d '%s'",
> + __func__, ret, error, fw_error_to_str(errno));
> +goto free_measurement;
> +}
> +
> +data = g_malloc(measurement->len);
> +if (s->measurement) {
> +goto free_data;
> +}
> +
> +measurement->uaddr = (unsigned long)data;
> +
> +/* get the measurement blob */
> +ret = sev_ioctl(KVM_SEV_LAUNCH_MEASURE, measurement, );
> +if (ret) {
> +error_report("%s: LAUNCH_MEASURE ret=%d fw_error=%d '%s'",
> + __func__, ret, error, fw_error_to_str(errno));
> +goto free_data;
> +}
> +
> +sev_set_guest_state(SEV_STATE_SECRET);
> +
> +/* encode the measurement value and emit the event */
> +s->measurement = g_base64_encode(data, measurement->len);
> +trace_kvm_sev_launch_measurement(s->measurement);
> +qapi_event_send_sev_measurement(s->measurement, _abort);
> +
> +free_data:
> +g_free(data);
> +free_measurement:
> +g_free(measurement);
> +}
> +
> +static Notifier sev_machine_done_notify = {
> +.notify = sev_launch_get_measure,
> +};
> +
>  void *
>  sev_guest_init(const char *id)
>  {
> @@ -461,6 +516,9 @@ sev_guest_init(const char *id)
>  }
>  
>  ram_block_notifier_add(_ram_notifier);
> +qemu_add_machine_init_done_notifier(_machine_done_notify);
> +
> +sev_state = s;
>  
>  return s;
>  err:
> diff --git a/accel/kvm/trace-events b/accel/kvm/trace-events
> index c55546f36a25..51df5113ad07 100644
> --- a/accel/kvm/trace-events
> +++ b/accel/kvm/trace-events
> @@ -20,3 +20,4 @@ kvm_memcrypt_unregister_region(void *addr, size_t len) 
> "addr %p len 0x%lu"
>  kvm_sev_change_state(char *old, char *new) "%s -> %s"
>  kvm_sev_launch_start(int policy, void *session, void *pdh) "policy 0x%x 
> session %p pdh %p"
>  kvm_sev_launch_update_data(void *addr, uint64_t len) "addr %p len 0x%" PRIu64
> +kvm_sev_launch_measurement(const char *value) "data %s"
> diff --git a/include/sysemu/sev.h b/include/sysemu/sev.h
> index 839800efdbbf..572120c865ea 100644
> --- a/include/sysemu/sev.h
> +++ b/include/sysemu/sev.h
> @@ -63,6 +63,7 @@ typedef enum {
>  
>  struct SEVState {
>  QSevGuestInfo *sev_info;
> +gchar *measurement;
>  };
>  
>  typedef struct SEVState SEVState;
> -- 
> 2.9.5
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

[Qemu-devel] [Bug 1745312] Re: Regression report: Disk subsystem I/O failures/issues surfacing in DOS/early Windows [two separate issues: one bisected, one root-caused]

[John Snow]

Can you post your commandline for the MSDOS 6.22 issue? NT is known to
have a few problems and may be out of scope for what I can help with,
but I was under the assumption that MSDOS 6.22 was well-behaved in QEMU.

Commandline and steps to reproduce the error may be helpful (any
particularly kind of command, workflow, etc that helps trigger the IO
errors? How big is the hard disk you are using? etc)

Thanks,
--John

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

Title:
  Regression report: Disk subsystem I/O failures/issues surfacing in
  DOS/early Windows [two separate issues: one bisected, one root-caused]

Status in QEMU:
  New

Bug description:
  [Headsup: This report is long-ish due to the amount of detail I've
  stumbled on along the way that I think is relevant to include. I can't
  speak as to the complexity of the actual bugs, but the size of this
  report should not suggest that the reproduction process is
  particularly headache-inducing.]

  Hi!

  I recently needed to fire up some ancient software for research
  purposes and got very distracted discovering and playing with old
  versions of Windows :). In the process I've discovered some glitches
  with disk I/O.

  I believe I've stumbled on two completely separate issues that
  coincidentally surfaced at the same time. It's possible that
  components of this report will be re-filed as more specific new bugs,
  but I'm not an authority on QEMU internals or how to narrow
  down/categorize what I've found.

  - The first bug only surfaces when the "isapc" machine type is used.
  It intermittently produces "General failure {read,writ}ing drive _"
  under MS-DOS 6.22, and also somehow interferes with early bootstrap of
  Windows NT 4 (in NTLDR). Enabling or disabling KVM (I'm on Linux)
  appears to make no difference whatsoever, which may help with
  debugging.

  - The second issue involves
- a WinNT4 disk image
- created by running through a bog-standard NT4 install inside QEMU 2.9.0
- which will now fail to boot in any version of QEMU - even version 1.0
  - but which VirtualBox will boot fine
- but only if I point VirtualBox at QEMU's raw disk image via a
  hacked-together VMDK file
- if the raw image is converted to VHD(X), VirtualBox will also fail
  to boot the image with exactly the same error as QEMU
- this state of affairs is not affected by image sparseness (which makes
  sense)

  I'm confident I've bisected the first issue.

  I wasn't able to bisect the second issue (as all tested versions of
  QEMU behaved identically), but I've figured out a working repro
  testcase and I believe I've managed to pin down a solid root cause.


  == #1: Intermittent I/O issues when `-M isapc` is used =

  These symptoms sometimes take a small amount of time and fiddling to
  trigger, but I AM able to consistently surface them on my machine
  after a short while. (I am very very interested to hear if others
  cannot reproduce them.)

  So, first of all:

  https://github.com/qemu/qemu/commit/306ec6c3cece7004429c79c1ac93d49919f1f1cc
(Jul 30 2013): the last version that works

  https://github.com/qemu/qemu/commit/e689f7c668cbd9d08f330e17c3dd3a059c9553d3
(Oct 30 2013): the first version that intermittently fails

  Maybe lift out and build these branches while reading. *shrug*
  (How to do this can be found at the end of this report - along with a 
time-saving ./configure line, FWIW)

  Here are the changelists between these two revisions:

  https://github.com/qemu/qemu/compare/306ec6c...e689f7c
  (Compare direction: OLD to NEW) (Commits: 166  Files changed: 192)

  https://github.com/qemu/qemu/compare/e689f7c...306ec6c
  (Compare direction: NEW to OLD) (Commits: 30   Files changed: 22)

  (Someone else more familiar with Git might know why GitHub returns
  results for both compare directions, and/or if the 2nd link is useful
  information. The first link returns a lot more results than the 2nd
  one, at least. Does comparing new>old return deletions?)

  ---

  Now on to the symptoms. In a moment I'll describe reproduction.

  # MS-DOS 6.22

  The first symptom I discovered was that trivial read and write
  operations under MS-DOS would sometimes fail:

C:\>echo test > hi

General failure writing drive C
Abort, Retry, Fail?

  Anything else that exercises the disk behaves similarly:

C:\>dir /s > nul

General failure reading drive C
Abort, Retry, Fail?

  (Note that the above demonstrates both write and read failures)

  (Also, FWIW, `dir /s` == `ls -R`)

  The behavior of the I/O errors is not possible to characterise as it
  fluctuates so much. For example something as simple as DIR can produce
  wildly differing results: in one run, poking around with DIR ended
  with DOS deciding C:\ was empty at one point; at another point in a
  different run 

Re: [Qemu-devel] [PATCH v4 0/4] ivshmem: MSI bug fixes

[Paolo Bonzini]

On 30/01/2018 13:30, Markus Armbruster wrote:
> Paolo, care to merge these fixes?

Ok, will do.

Paolo

Re: [Qemu-devel] [PATCH v5] chardev/char-socket: add POLLHUP handler

[Paolo Bonzini]

On 25/01/2018 08:51, Klim Kireev wrote:
> The following behavior was observed for QEMU configured by libvirt
> to use guest agent as usual for the guests without virtio-serial
> driver (Windows or the guest remaining in BIOS stage).
> 
> In QEMU on first connect to listen character device socket
> the listen socket is removed from poll just after the accept().
> virtio_serial_guest_ready() returns 0 and the descriptor
> of the connected Unix socket is removed from poll and it will
> not be present in poll() until the guest will initialize the driver
> and change the state of the serial to "guest connected".
> 
> In libvirt connect() to guest agent is performed on restart and
> is run under VM state lock. Connect() is blocking and can
> wait forever.
> In this case libvirt can not perform ANY operation on that VM.
> 
> The bug can be easily reproduced this way:
> 
> Terminal 1:
> qemu-system-x86_64 -m 512 -device pci-serial,chardev=serial1 -chardev 
> socket,id=serial1,path=/tmp/console.sock,server,nowait
> (virtio-serial and isa-serial also fit)
> 
> Terminal 2:
> minicom -D unix\#/tmp/console.sock
> (type something and press enter)
> C-a x (to exit)
> 
> Do 3 times:
> minicom -D unix\#/tmp/console.sock
> C-a x
> 
> It needs 4 connections, because the first one is accepted by QEMU, then two 
> are queued by
> the kernel, and the 4th blocks.
> 
> The problem is that QEMU doesn't add a read watcher after succesful read
> until the guest device wants to acquire recieved data, so
> I propose to install a separate pullhup watcher regardless of
> whether the device waits for data or not.
> 
> Signed-off-by: Klim Kireev 
> ---
> Changelog:
> v2: Remove timer as a redundant feature
> 
> v3: Remove read call and return G_SOURCE_REMOVE
> 
> v4: Move to GSource API
> 
> v5: Fix git typos 
> 
>  chardev/char-socket.c | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/chardev/char-socket.c b/chardev/char-socket.c
> index 77cdf487eb..a340af6cd3 100644
> --- a/chardev/char-socket.c
> +++ b/chardev/char-socket.c
> @@ -42,6 +42,7 @@ typedef struct {
>  QIOChannel *ioc; /* Client I/O channel */
>  QIOChannelSocket *sioc; /* Client master channel */
>  QIONetListener *listener;
> +GSource *hup_source;
>  QCryptoTLSCreds *tls_creds;
>  int connected;
>  int max_size;
> @@ -352,6 +353,12 @@ static void tcp_chr_free_connection(Chardev *chr)
>  s->read_msgfds_num = 0;
>  }
>  
> +if (s->hup_source != NULL) {
> +g_source_destroy(s->hup_source);
> +g_source_unref(s->hup_source);
> +s->hup_source = NULL;
> +}
> +
>  tcp_set_msgfds(chr, NULL, 0);
>  remove_fd_in_watch(chr);
>  object_unref(OBJECT(s->sioc));
> @@ -455,6 +462,15 @@ static gboolean tcp_chr_read(QIOChannel *chan, 
> GIOCondition cond, void *opaque)
>  return TRUE;
>  }
>  
> +static gboolean tcp_chr_hup(QIOChannel *channel,
> +   GIOCondition cond,
> +   void *opaque)
> +{
> +Chardev *chr = CHARDEV(opaque);
> +tcp_chr_disconnect(chr);
> +return G_SOURCE_REMOVE;
> +}
> +
>  static int tcp_chr_sync_read(Chardev *chr, const uint8_t *buf, int len)
>  {
>  SocketChardev *s = SOCKET_CHARDEV(chr);
> @@ -528,6 +544,12 @@ static void tcp_chr_connect(void *opaque)
> tcp_chr_read,
> chr, chr->gcontext);
>  }
> +
> +s->hup_source = qio_channel_create_watch(s->ioc, G_IO_HUP);
> +g_source_set_callback(s->hup_source, (GSourceFunc)tcp_chr_hup,
> +  chr, NULL);
> +g_source_attach(s->hup_source, chr->gcontext);
> +
>  qemu_chr_be_event(chr, CHR_EVENT_OPENED);
>  }
>  
> 

Queued, thanks.

Paolo

Re: [Qemu-devel] [PATCH v2 0/4] Updates based on feedback.

[Justin Terry (VM) via Qemu-devel]

No worries at all Paolo. I was just making sure I didn’t miss something.

We have been working on some minor fixups/perf improvements on our end and I 
will submit those patches after this merges. I figured it would be easier 
because they will be very small and isolated so easier to review moving forward.

Thanks,
Justin

> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Tuesday, January 30, 2018 11:34 AM
> To: Justin Terry (VM) ; qemu-devel@nongnu.org
> Cc: crosthwaite.pe...@gmail.com; r...@twiddle.net; ehabk...@redhat.com
> Subject: Re: [PATCH v2 0/4] Updates based on feedback.
> 
> On 29/01/2018 14:58, Justin Terry (VM) wrote:
> > Hi All,
> >
> > Is there any additional feedback I can address here to help out the
> process? Please let me know.
> 
> Nothing specifically (it didn't help that most of last week I was sick!).  
> From
> my point of view, I just need to review the changes you made and include
> these patches in a pull request.
> 
> Thanks,
> 
> Paolo
> 
> > Thanks again,
> > Justin
> >
> >> -Original Message-
> >> From: Justin Terry (VM)
> >> Sent: Monday, January 22, 2018 1:08 PM
> >> To: qemu-devel@nongnu.org
> >> Cc: pbonz...@redhat.com; crosthwaite.pe...@gmail.com;
> >> r...@twiddle.net; ehabk...@redhat.com; Justin Terry (VM)
> >> 
> >> Subject: [PATCH v2 0/4] Updates based on feedback.
> >>
> >> Updates based on review feedback.
> >>
> >> 1. Fixes style issues and properly ran the scripts/checkpatch pre
> submission.
> >> 2. Added migration blockers for CPUID, dirty memory tracking, and
> >> XSAVE/XRSTOR.
> >> 3. Fixed some bugs around register states when using bios vs efi.
> >>
> >> Justin Terry (VM) (4):
> >>   Add the Windows Hypervisor Platform accelerator.
> >>   Add the WHPX vcpu API
> >>   Introduce the WHPX impl
> >>   Add the WHPX acceleration enlightenments
> >>
> >>  accel/stubs/Makefile.objs |9 +-
> >>  accel/stubs/whpx-stub.c   |   48 ++
> >>  configure |   48 +-
> >>  cpus.c|   66 ++-
> >>  include/sysemu/hw_accel.h |   13 +
> >>  include/sysemu/whpx.h |   40 ++
> >>  qemu-options.hx   |8 +-
> >>  target/i386/Makefile.objs |1 +
> >>  target/i386/helper.c  |2 +-
> >>  target/i386/whpx-all.c| 1366
> >> +
> >>  10 files changed, 1590 insertions(+), 11 deletions(-)  create mode
> >> 100644 accel/stubs/whpx-stub.c  create mode 100644
> >> include/sysemu/whpx.h create mode 100644 target/i386/whpx-all.c
> >>
> >> --
> >> 2.7.4
> >

Re: [Qemu-devel] [RFC 0/4] Allow custom socket option in socket_listen and socket_connect

[no-reply]

Hi,

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

Type: series
Message-id: 1517253224-14361-1-git-send-email-whois.zihan.y...@gmail.com
Subject: [Qemu-devel] [RFC 0/4] Allow custom socket option in socket_listen and 
socket_connect

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

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

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

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

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
e14ef46352 net/socket: change net_socket_connect_init to use functions in 
sockets.h
e72c98470f net/socket: change net_socket_listen_init to use functions in 
include/qemu/sockets.h
f820da9f2e qemu-socket: Allow custom socket options in socket_connect
8849322e0a qemu-socket: Allow custom socket option in socket_listen

=== OUTPUT BEGIN ===
Checking PATCH 1/4: qemu-socket: Allow custom socket option in socket_listen...
ERROR: space required before the open parenthesis '('
#99: FILE: util/qemu-sockets.c:204:
+if(!sconf) {

ERROR: space required before the open parenthesis '('
#104: FILE: util/qemu-sockets.c:209:
+if(sconf->nonblocking) {

ERROR: trailing whitespace
#106: FILE: util/qemu-sockets.c:211:
+} $

ERROR: space required before the open parenthesis '('
#108: FILE: util/qemu-sockets.c:213:
+for(sopt = sconf->options; sopt; sopt = sopt->next) {

ERROR: trailing whitespace
#109: FILE: util/qemu-sockets.c:214:
+if(sopt->level < IPPROTO_IP || sopt->optname < SO_DEBUG || $

ERROR: space required before the open parenthesis '('
#109: FILE: util/qemu-sockets.c:214:
+if(sopt->level < IPPROTO_IP || sopt->optname < SO_DEBUG || 

ERROR: Error messages should not contain newlines
#111: FILE: util/qemu-sockets.c:216:
+error_setg(errp, "Invalid socket option:\n"

ERROR: Error messages should not contain newlines
#112: FILE: util/qemu-sockets.c:217:
+ "level=%d, optname=%d, optval=%p, optlen=%d\n",

ERROR: trailing whitespace
#116: FILE: util/qemu-sockets.c:221:
+qemu_setsockopt(fd, sopt->level, sopt->optname, $

ERROR: space required before the open parenthesis '('
#135: FILE: util/qemu-sockets.c:320:
+if(parse_socket_options(slisten, errp, sconf) < 0) {

ERROR: space required before the open parenthesis '('
#157: FILE: util/qemu-sockets.c:755:
+if(parse_socket_options(slisten, errp, sconf) < 0) {

ERROR: space required before the open parenthesis '('
#190: FILE: util/qemu-sockets.c:840:
+if(parse_socket_options(sock, errp, sconf) < 0) {

total: 12 errors, 0 warnings, 201 lines checked

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

Checking PATCH 2/4: qemu-socket: Allow custom socket options in 
socket_connect...
ERROR: space required before the open parenthesis '('
#103: FILE: util/qemu-sockets.c:390:
+if(parse_socket_options(sock, errp, sconf) < 0) {

WARNING: line over 80 characters
#114: FILE: util/qemu-sockets.c:401:
+/* More judge for nonblocking socket, borrowed from 
net_socket_connect_init */

ERROR: space required before the open parenthesis '('
#115: FILE: util/qemu-sockets.c:402:
+if(sconf->nonblocking) {

ERROR: space required before the open parenthesis '('
#116: FILE: util/qemu-sockets.c:403:
+if(rc == -EWOULDBLOCK)

ERROR: braces {} are necessary for all arms of this statement
#116: FILE: util/qemu-sockets.c:403:
+if(rc == -EWOULDBLOCK)
[...]
+else if(rc == -EINPROGRESS ||
[...]

ERROR: space required before the open parenthesis '('
#118: FILE: util/qemu-sockets.c:405:
+else if(rc == -EINPROGRESS ||

ERROR: braces {} are necessary for all arms of this statement
#118: FILE: util/qemu-sockets.c:405:
+else if(rc == -EINPROGRESS ||
[...]

ERROR: space required before the open parenthesis '('
#168: FILE: util/qemu-sockets.c:725:
+if(parse_socket_options(sock, errp, sconf) < 0) {

ERROR: space required before the open parenthesis '('
#179: FILE: util/qemu-sockets.c:736:
+if(sconf->nonblocking) {

ERROR: space required before the open parenthesis '('
#180: FILE: util/qemu-sockets.c:737:
+if(rc == -EWOULDBLOCK)

ERROR: braces {} are necessary for all arms of this statement
#180: FILE: util/qemu-sockets.c:737:
+if(rc == -EWOULDBLOCK)
[...]
+else if(rc == -EINPROGRESS ||
[...]

ERROR: space required before the open parenthesis '('
#182: FILE: util/qemu-sockets.c:739:
+else if(rc == -EINPROGRESS ||

ERROR: braces {} 

[Qemu-devel] [PATCH v3] scripts/make-release: Don't archive .git files

[Cole Robinson]

As was last done in 379e21c25, we don't want .git files for
submodules here, which we aren't presently doing for capstone and
keycodemapdb.

Rather than delete the offending files before archiving, ask tar
to --exclude=.git

Signed-off-by: Cole Robinson 
---
v2:
Use armbru's --exclude suggestion, requires tweaking
existing tar options a bit.

v3:
thuth's suggestion to use --exclude for both tar commands

 scripts/make-release | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/scripts/make-release b/scripts/make-release
index 3917df7142..04fa9defdc 100755
--- a/scripts/make-release
+++ b/scripts/make-release
@@ -19,11 +19,10 @@ pushd ${destination}
 git checkout "v${version}"
 git submodule update --init
 (cd roms/seabios && git describe --tags --long --dirty > .version)
-rm -rf .git roms/*/.git dtc/.git pixman/.git
 # FIXME: The following line is a workaround for avoiding filename collisions
 # when unpacking u-boot sources on case-insensitive filesystems. Once we
 # update to something with u-boot commit 610eec7f0 we can drop this line.
-tar cfj roms/u-boot.tar.bz2 -C roms u-boot && rm -rf roms/u-boot
+tar --exclude=.git -cjf roms/u-boot.tar.bz2 -C roms u-boot && rm -rf 
roms/u-boot
 popd
-tar cfj ${destination}.tar.bz2 ${destination}
+tar --exclude=.git -cjf ${destination}.tar.bz2 ${destination}
 rm -rf ${destination}
-- 
2.14.3

Re: [Qemu-devel] [PATCH v2 0/4] Updates based on feedback.

[Paolo Bonzini]

On 29/01/2018 14:58, Justin Terry (VM) wrote:
> Hi All,
> 
> Is there any additional feedback I can address here to help out the process? 
> Please let me know.

Nothing specifically (it didn't help that most of last week I was
sick!).  From my point of view, I just need to review the changes you
made and include these patches in a pull request.

Thanks,

Paolo

> Thanks again,
> Justin
> 
>> -Original Message-
>> From: Justin Terry (VM)
>> Sent: Monday, January 22, 2018 1:08 PM
>> To: qemu-devel@nongnu.org
>> Cc: pbonz...@redhat.com; crosthwaite.pe...@gmail.com; r...@twiddle.net;
>> ehabk...@redhat.com; Justin Terry (VM) 
>> Subject: [PATCH v2 0/4] Updates based on feedback.
>>
>> Updates based on review feedback.
>>
>> 1. Fixes style issues and properly ran the scripts/checkpatch pre submission.
>> 2. Added migration blockers for CPUID, dirty memory tracking, and
>> XSAVE/XRSTOR.
>> 3. Fixed some bugs around register states when using bios vs efi.
>>
>> Justin Terry (VM) (4):
>>   Add the Windows Hypervisor Platform accelerator.
>>   Add the WHPX vcpu API
>>   Introduce the WHPX impl
>>   Add the WHPX acceleration enlightenments
>>
>>  accel/stubs/Makefile.objs |9 +-
>>  accel/stubs/whpx-stub.c   |   48 ++
>>  configure |   48 +-
>>  cpus.c|   66 ++-
>>  include/sysemu/hw_accel.h |   13 +
>>  include/sysemu/whpx.h |   40 ++
>>  qemu-options.hx   |8 +-
>>  target/i386/Makefile.objs |1 +
>>  target/i386/helper.c  |2 +-
>>  target/i386/whpx-all.c| 1366
>> +
>>  10 files changed, 1590 insertions(+), 11 deletions(-)  create mode 100644
>> accel/stubs/whpx-stub.c  create mode 100644 include/sysemu/whpx.h
>> create mode 100644 target/i386/whpx-all.c
>>
>> --
>> 2.7.4
> 

Re: [Qemu-devel] [PATCH v2 0/4] memory/vfio: notify region_del() when unregister listeners

[Paolo Bonzini]

On 22/01/2018 01:02, Peter Xu wrote:
> v2
> - add begin() hooks [Paolo]
> - move vfio patch to front [Paolo]
> - one more patch for arm devlistener unregister [Paolo]
> - one more patch for vhost traces
> - removing RFC tag
> 
> This series fixes bug reported here:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1531393
> 
> The first patch only adds traces for vhost, with which I tested on
> vhost to make sure that my last patch works as expected with vhost.
> Please pick it if anyone wants, or ignore it if no one likes it.
> 
> The 2nd patch is the arm fix for preparation of the last patch.
> 
> The 3rd patch is the vfio fix for preparation of the last patch.
> 
> The 4th patch is the core fix of the problem.
> 
> Please review, thanks.
> 
> Thanks.
> 
> Peter Xu (4):
>   vhost: add traces for memory listeners
>   arm: postpone device listener unregister
>   vfio: listener unregister before unset container
>   memory: do explicit cleanup when remove listeners
> 
>  hw/vfio/common.c   | 16 
>  hw/virtio/trace-events |  6 ++
>  hw/virtio/vhost.c  | 11 +++
>  memory.c   | 27 +++
>  target/arm/kvm.c   |  2 +-
>  5 files changed, 53 insertions(+), 9 deletions(-)
> 

Queued, thanks.

Paolo

Re: [Qemu-devel] [Qemu-block] [PATCH] virtio-blk: check for NULL BlockDriverState

[John Snow]

On 01/30/2018 10:56 AM, Kevin Wolf wrote:
> Am 30.01.2018 um 13:38 hat Stefan Hajnoczi geschrieben:
>> On Mon, Jan 29, 2018 at 04:41:07PM +0100, Kevin Wolf wrote:
>>> Am 24.01.2018 um 12:31 hat Stefan Hajnoczi geschrieben:
 On Mon, Jan 22, 2018 at 09:01:49AM -0600, Mark Kanda wrote:
> Add a BlockDriverState NULL check to virtio_blk_handle_request()
> to prevent a segfault if the drive is forcibly removed using HMP
> 'drive_del' (without performing a hotplug 'device_del' first).
>
> Signed-off-by: Mark Kanda 
> Reviewed-by: Karl Heubaum 
> Reviewed-by: Ameya More 
> ---
>  hw/block/virtio-blk.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
> index b1532e4..76ddbbf 100644
> --- a/hw/block/virtio-blk.c
> +++ b/hw/block/virtio-blk.c
> @@ -507,6 +507,13 @@ static int virtio_blk_handle_request(VirtIOBlockReq 
> *req, MultiReqBuffer *mrb)
>  return -1;
>  }
>  
> +/* If the drive was forcibly removed (e.g. HMP 'drive_del'), the 
> block
> + * driver state may be NULL and there is nothing left to do. */
> +if (!blk_bs(req->dev->blk)) {

 Adding Markus Armbruster to check my understanding of drive_del:

 1. If id is a node name (e.g. created via blockdev-add) then attempting
to remove the root node produces the "Node %s is in use" error.  In
that case this patch isn't needed.

 2. If id is a BlockBackend (e.g. created via -drive) then removing the
root node is allowed.  The BlockBackend stays in place but blk->root
becomes NULL, hence this patch is needed.

 Markus: What are the valid use cases for #2?  If blk->bs becomes NULL I
 would think a lot more code beyond virtio-blk can segfault.
>>>
>>> blk->root = NULL is completely normal, it is what happens with removable
>>> media when the drive is empty.
>>>
>>> The problem, which was first reported during the 2.10 RC phase and was
>>> worked around in IDE code then, is that Paolo's commit 99723548561 added
>>> unconditional bdrv_inc/dec_in_flight() calls. I am pretty sure that any
>>> segfaults that Mark is seeing have the same cause.
>>>
>>> We do need an in-flight counter even for those requests so that
>>> blk_drain() works correctly, so just making the calls condition wouldn't
>>> be right. However, this needs to become a separate counter in
>>> BlockBackend, and the drain functions must be changed to make use of it.
>>>
>>> I did post rough patches back then, but they weren't quite ready, and
>>> since then they have fallen through the cracks.
>>
>> Will you send a new version of that patch series?
> 
> I would like to continue my work on the drain functions (which this
> would be a part of) sooner or later, but the work to enable libvirt to
> use blockdev-add is at a higher priority at the moment.
> 
> So if you can wait, I'll get to it eventually. If not, feel free to pick
> up the patches.
> 
> Kevin
> 

It'd probably be nice for 2.12.

I'm not sure I understand the throttling well enough to do it /quickly/
and I have other priorities right now, but let's try to keep this one in
mind as something to fix before another release goes by.

--js

[Qemu-devel] 4.14 linux kernel vs postcopy migration

[Dr. David Alan Gilbert]

Hi,
  It looks like the 4.14 linux kernel has something which breaks
postcopy;  4.13 and 4.15 both seem OK, but both Peter and myself ran
into problems with double faults after postcopy migration on a Fedora
27 host, and I've recreated the same problem on upstream kernels
from v4.14.0 through v4.14.0.
  The stand alone userfaultfd tests seem ok though.

I might try some further bisecting, but for now I think I'll just
flip to a bleeding edge 4.15.

Dave

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

Re: [Qemu-devel] [PATCH 00/18] Clean up includes to reduce compile time

[Philippe Mathieu-Daudé]

On 01/30/2018 07:21 AM, Markus Armbruster wrote:
> We have awfully many "touch it, recompile the world" headers.  Right
> now, I count about fifty that are prerequisites of more than half the
> objects in my "build everything" tree.
> 
> Some of them are that way by necessity.  Many of them are not.  This
> series takes care of six I happen to touch, because serve as their
> maintainer:
> 
> include/qapi/qmp/qdict.h
> include/qapi/qmp/qlist.h
> include/qapi/qmp/qnull.h
> include/qapi/qmp/qnum.h
> include/qapi/qmp/qobject.h
> include/qemu/option.h
> 
> Before this series, touching any of these recompiles more than 95% of
> my objects.  That's more than 4500 compiler runs.  After this series,
> only 0.3% - 8% of my objects get recompiled.

nice cleanup :)

No more comment than what Eric said (mostly newlines),
and Zoltan regarding , so
Reviewed-by: Philippe Mathieu-Daudé 

Is there a way to check if an header got used or not?
(thinking about a patchew check to not add headers until effectively used).

> 
> Markus Armbruster (18):
>   Clean up includes
>   Drop superfluous includes of qapi-types.h
>   Include qapi/error.h exactly where needed
>   Drop superfluous includes of qapi/qmp/qerror.h
>   Include qmp-commands.h exactly where needed
>   Typedef the subtypes of QObject in qemu/typedefs.h, too
>   Eliminate qapi/qmp/types.h
>   qdict qlist: Make most helper macros functions
>   Include qapi/qmp/qobject.h exactly where needed
>   Include qapi/qmp/qlist.h exactly where needed
>   Include qapi/qmp/qdict.h exactly where needed
>   Include qapi/qmp/qstring.h exactly where needed
>   Include qapi/qmp/qbool.h exactly where needed
>   Include qapi/qmp/qnum.h exactly where needed
>   Include qapi/qmp/qnull.h exactly where needed
>   Drop superfluous includes of qapi/qmp/dispatch.h
>   Drop superfluous includes of qapi/qmp/qjson.h
>   Move include qemu/option.h from qemu-common.h to actual users
> 
>  accel/accel.c  |  2 +-
>  arch_init.c|  1 +
>  audio/wavcapture.c |  1 +
>  backends/cryptodev.c   |  1 -
>  backends/hostmem.c |  1 -
>  backends/tpm.c |  1 -
>  balloon.c  |  2 +-
>  block.c|  6 --
>  block/blkdebug.c   |  2 +-
>  block/blkverify.c  |  1 +
>  block/block-backend.c  |  2 ++
>  block/crypto.c |  2 ++
>  block/curl.c   |  5 +++--
>  block/file-posix.c |  2 ++
>  block/file-win32.c |  3 +++
>  block/gluster.c|  3 +++
>  block/iscsi-opts.c |  1 +
>  block/iscsi.c  |  3 ++-
>  block/nbd.c|  2 +-
>  block/nfs.c|  2 +-
>  block/null.c   |  1 +
>  block/parallels.c  |  3 ++-
>  block/parallels.h  |  1 -
>  block/qapi.c   |  6 +-
>  block/qcow.c   |  5 +++--
>  block/qcow2-cluster.c  |  1 -
>  block/qcow2.c  |  6 --
>  block/qed.c|  2 +-
>  block/quorum.c |  4 ++--
>  block/rbd.c|  3 +++
>  block/replication.c|  2 +-
>  block/sheepdog.c   |  1 +
>  block/snapshot.c   |  2 ++
>  block/ssh.c|  2 ++
>  block/throttle.c   |  1 +
>  block/vdi.c|  1 +
>  block/vhdx.c   |  2 +-
>  block/vmdk.c   |  1 +
>  block/vpc.c|  3 ++-
>  block/vvfat.c  |  4 +++-
>  block/write-threshold.c|  1 +
>  blockdev-nbd.c |  2 +-
>  blockdev.c |  5 -
>  blockjob.c |  3 +--
>  chardev/char-file.c|  3 ++-
>  chardev/char-mux.c |  3 ++-
>  chardev/char-parallel.c|  2 ++
>  chardev/char-pipe.c|  2 ++
>  chardev/char-ringbuf.c  

Re: [Qemu-devel] [PATCH v4 0/4] ivshmem: MSI bug fixes

[Markus Armbruster]

Paolo, care to merge these fixes?

Re: [Qemu-devel] [PATCH] qemu-options.hx: Remove confusing spaces in parameter listings

[Stefan Berger]

On 01/30/2018 04:36 AM, Thomas Huth wrote:

The spaces between the parameters in the chardev and tpmdev sections
are rather confusing than helpful, and prevent that the lists can be
copy-n-pasted easily for real usage. We also don't use such spaces
in other sections in the documentation, e.g. with the -netdev option,
so let's be consistent and remove the spaces in the chardev and tpmdev
sections, too.

Signed-off-by: Thomas Huth 

Reviewed-by: Stefan Berger 



---
  qemu-options.hx | 48 
  1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index 8ce427d..08a73fa 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2522,7 +2522,7 @@ STEXI

  The general form of a character device option is:
  @table @option
-@item -chardev @var{backend} ,id=@var{id} [,mux=on|off] [,@var{options}]
+@item -chardev @var{backend},id=@var{id}[,mux=on|off][,@var{options}]
  @findex -chardev
  Backend is one of:
  @option{null},
@@ -2541,7 +2541,7 @@ Backend is one of:
  @option{tty},
  @option{parallel},
  @option{parport},
-@option{spicevmc}.
+@option{spicevmc},
  @option{spiceport}.
  The specific backend will determine the applicable options.

@@ -2605,11 +2605,11 @@ opened.
  The available backends are:

  @table @option
-@item -chardev null ,id=@var{id}
+@item -chardev null,id=@var{id}
  A void device. This device will not emit any data, and will drop any data it
  receives. The null backend does not take any options.

-@item -chardev socket ,id=@var{id} [@var{TCP options} or @var{unix options}] 
[,server] [,nowait] [,telnet] [,reconnect=@var{seconds}] [,tls-creds=@var{id}]
+@item -chardev socket,id=@var{id}[,@var{TCP options} or @var{unix 
options}][,server][,nowait][,telnet][,reconnect=@var{seconds}][,tls-creds=@var{id}]

  Create a two-way stream socket, which can be either a TCP or a unix socket. A
  unix socket will be created if @option{path} is specified. Behaviour is
@@ -2636,7 +2636,7 @@ TCP and unix socket options are given below:

  @table @option

-@item TCP options: port=@var{port} [,host=@var{host}] [,to=@var{to}] [,ipv4] 
[,ipv6] [,nodelay]
+@item TCP options: 
port=@var{port}[,host=@var{host}][,to=@var{to}][,ipv4][,ipv6][,nodelay]

  @option{host} for a listening socket specifies the local address to be bound.
  For a connecting socket species the remote host to connect to. @option{host} 
is
@@ -2664,7 +2664,7 @@ required.

  @end table

-@item -chardev udp ,id=@var{id} [,host=@var{host}] ,port=@var{port} 
[,localaddr=@var{localaddr}] [,localport=@var{localport}] [,ipv4] [,ipv6]
+@item -chardev 
udp,id=@var{id}[,host=@var{host}],port=@var{port}[,localaddr=@var{localaddr}][,localport=@var{localport}][,ipv4][,ipv6]

  Sends all traffic from the guest to a remote host over UDP.

@@ -2683,12 +2683,12 @@ available local port will be used.
  @option{ipv4} and @option{ipv6} specify that either IPv4 or IPv6 must be used.
  If neither is specified the device may use either protocol.

-@item -chardev msmouse ,id=@var{id}
+@item -chardev msmouse,id=@var{id}

  Forward QEMU's emulated msmouse events to the guest. @option{msmouse} does not
  take any options.

-@item -chardev vc ,id=@var{id} [[,width=@var{width}] [,height=@var{height}]] 
[[,cols=@var{cols}] [,rows=@var{rows}]]
+@item -chardev 
vc,id=@var{id}[[,width=@var{width}][,height=@var{height}]][[,cols=@var{cols}][,rows=@var{rows}]]

  Connect to a QEMU text console. @option{vc} may optionally be given a specific
  size.
@@ -2699,12 +2699,12 @@ the console, in pixels.
  @option{cols} and @option{rows} specify that the console be sized to fit a 
text
  console with the given dimensions.

-@item -chardev ringbuf ,id=@var{id} [,size=@var{size}]
+@item -chardev ringbuf,id=@var{id}[,size=@var{size}]

  Create a ring buffer with fixed size @option{size}.
  @var{size} must be a power of two and defaults to @code{64K}.

-@item -chardev file ,id=@var{id} ,path=@var{path}
+@item -chardev file,id=@var{id},path=@var{path}

  Log all traffic received from the guest to a file.

@@ -2712,7 +2712,7 @@ Log all traffic received from the guest to a file.
  created if it does not already exist, and overwritten if it does. 
@option{path}
  is required.

-@item -chardev pipe ,id=@var{id} ,path=@var{path}
+@item -chardev pipe,id=@var{id},path=@var{path}

  Create a two-way connection to the guest. The behaviour differs slightly 
between
  Windows hosts and other hosts:
@@ -2729,14 +2729,14 @@ be present.
  @option{path} forms part of the pipe path as described above. @option{path} is
  required.

-@item -chardev console ,id=@var{id}
+@item -chardev console,id=@var{id}

  Send traffic from the guest to QEMU's standard output. @option{console} does 
not
  take any options.

  @option{console} is only available on Windows hosts.

-@item -chardev serial ,id=@var{id} ,path=@option{path}
+@item -chardev serial,id=@var{id},path=@option{path}

  Send 

Re: [Qemu-devel] [PATCH 18/18] Move include qemu/option.h from qemu-common.h to actual users

[Eric Blake]

On 01/30/2018 04:22 AM, Markus Armbruster wrote:
> qemu-common.h includes qemu/option.h, but most places that include the
> former don't actually need the latter.  Drop the include, and add it
> to the places that actually need it.
> 
> While there, drop superfluous includes of both headers.
> 
> This cleanup makes the number of objects depending on qemu/option.h
> drop from 4542 (out of 4739) to 284 in my "build everything" tree.
> 
> Signed-off-by: Markus Armbruster 
> ---
>  103 files changed, 98 insertions(+), 54 deletions(-)

Bigger effort, but still a nice cleanup.  And especially nice if we're
trying to reduce users of QemuOpts.

Reviewed-by: Eric Blake 

> +++ b/block/file-posix.c
> @@ -21,12 +21,14 @@
>   * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
>   * THE SOFTWARE.
>   */
> +
>  #include "qemu/osdep.h"
>  #include "qapi/error.h"
>  #include "qemu/cutils.h"
>  #include "qemu/error-report.h"
>  #include "block/block_int.h"
>  #include "qemu/module.h"
> +#include "qemu/option.h"
>  #include "trace.h"

More of the blank line before osdep.h cleanup comment.

> +++ b/hw/9pfs/9p-handle.c
> @@ -22,6 +22,7 @@
>  #include "qemu/xattr.h"
>  #include "qemu/cutils.h"
>  #include "qemu/error-report.h"
> +#include "qemu/option.h"
>  #include 
>  #ifdef CONFIG_LINUX_MAGIC_H
>  #include 

Shouldn't we be fixing this one to include system headers (like
 prior to internal headers?  Separate cleanup, though.

> diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c
> index c6d8af4fb8..d85494bd31 100644
> --- a/hw/9pfs/9p-local.c
> +++ b/hw/9pfs/9p-local.c
> @@ -26,6 +26,7 @@
>  #include "qapi/error.h"
>  #include "qemu/cutils.h"
>  #include "qemu/error-report.h"
> +#include "qemu/option.h"
>  #include 
>  #include 

More of that separate cleanup.

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 17/18] Drop superfluous includes of qapi/qmp/qjson.h

[Eric Blake]

On 01/30/2018 04:22 AM, Markus Armbruster wrote:
> Signed-off-by: Markus Armbruster 
> ---
>  balloon.c   | 1 -
>  block/nbd.c | 1 -
>  block/quorum.c  | 1 -
>  blockjob.c  | 1 -
>  hw/core/qdev.c  | 1 -
>  hw/net/virtio-net.c | 1 -
>  hw/pci/pcie_aer.c   | 1 -
>  target/s390x/kvm.c  | 1 -
>  tests/test-qobject-output-visitor.c | 1 -
>  ui/spice-core.c | 1 -
>  vl.c| 1 -
>  11 files changed, 11 deletions(-)

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v5] cocoa.m: Add ability for user to specify mouse ungrab key

[Programmingkid]

> On Jan 30, 2018, at 7:18 AM, Gerd Hoffmann  wrote:
> 
> On Fri, Jan 26, 2018 at 04:47:31PM -0500, John Arbuckle wrote:
>> Currently the ungrab keys for the Cocoa and GTK interface are Control-Alt-g.
> 
> SDL is the same now, for consistency.
> 
>> This combination may not be very fun for the user to have to enter, so we
>> now enable the user to specify their own key(s) as the ungrab key(s).
> 
> What about the other hotkeys?
> 
> There is fullscreen.  Ctrl-Alt-F for SDL and GTK.  Cmd-F for cocoa, but
> it works only if the grab is not active.

If has to be that way because the meta (command) key is sent to the guest when 
the mouse grab is in effect. I actually suggest the SDL and GTK interfaces send 
the meta (windows key on PC keyboard) key to the guest when a mouse grab is in 
effect. This way guest operating systems like Mac OS X can use keyboard 
shortcuts. 

> Console select (Ctrl-Alt-), works for SDL and GTK.  When I read the
> code correctly it should work for cocoa the same way, but it doesn't
> work for me.  Dunno why. 

I know this code was broken in cocoa for a while but I made the patch that 
fixes this problem. Console selection does work correctly using a recent git 
version of QEMU.

> Quit. Ctrl-Alt-Q on gtk.  Cmd-Q on cocoa, again only working without
> keyboard grab.  Nothing on SDL.  Just closing the window to quit works
> on GTK and SDL, both have a switch to turn it off.

I know Command-Q is the standard Macintosh keyboard short for quitting an 
application. With GTK I would imagine it would depend on how the host operating 
system expects applications to be built. I don't think Windows and Linux have a 
standard keyboard shortcut for quitting an application. 

> 
> [ ... list of hotkeys is incomplete, there is more, most of them working
>  in some of the user interfaces only ... ]
> 
> There is the -ctrl-grab switch.  Changes all hotkeys from Ctrl-Alt-
> to Ctrl-.  SDL only.  I want deprecate it.
> 
> There is the -alt-grab switch.  Changes all hotkeys from Ctrl-Alt-
> to Ctrl-Alt-Shift-.  SDL only.  I want deprecate it too.

Sounds like a good idea. It would help to keep things consistent between the 
UI's.

> 
> When touching this mess I want move to something more consistent.
> 
> 
>> Syntax: -ungrab 
> 
> As mentioned earlier: New toplevel switch isn't going to fly.  Should be
> a suboption of -display.

Is this good?:
-display ungrab=... 

. 

Ok I see what you want:

-display gtk,hotkey-modifiers=ctrl+shift,hotkey-grab=f12,hotkey-fullscreen=f11

-display cocoa,hotkey-modifiers=Command,hotkey-grab=f13,hotkey-fullscreen=f14

I assume hotkey-modifiers is used to set the meta key. Is hotkey-grab the key
used to ungrab the mouse? If it is shouldn't it be called hotkey-ungrab?


> 
>> Example usage:  -ungrab home
>>  -ungrab shift-ctrl
> 
> Modifier-only hotkeys are tricky with gtk (doable, but no support for
> that in the toolkit).
> 
>>  -ungrab ctrl-x
>>  -ungrab pgup-pgdn
> 
> Really?  Two non-modifier keys?
Yes. The ungrab sequence could be a-b-c and still allow these keys to be used 
in the guest.

>  How is that implemented?  Do you queue
> up the pgup keypress, waiting to see whenever pgdn is pressed too, then
> only in case that didn't happen forward the queued pgup key to the guest?

Basically there is a array that acts as a check list. It checks off keys that 
belong to the ungrab sequence as they are detected. Once a non-ungrab key is 
detected, the check list is cleared. If all the ungrab keys are detected the 
ungrab code is executed. This only happens on keyup events. That way if 
Control-ALT were the ungrab keys, sending Control-ALT-Delete to the guest is 
still possible because these are the keys detected on the keyup event. The 
Delete key would have cleared the check list. Daniel Berrange is the one I can 
thank for this idea. He might be able to explain it better than me.

> Making this work properly without unpleasent surprises in corner cases
> doesn't look easy to me.  Needless to say that the gtk toolkit doesn't
> support this either.

I know it sounds hard to implement but it really isn't. It is just knowing 
which pieces fit where. The keyup and keydown events is where most of the 
action takes place.

> I think we should limit ourself to key combinations which have one
> non-modifier key and optionally one or more modifier keys.  That should
> be supportable in all user interfaces we have.  Except curses, modifier
> key handling in unix terminals is a completely different world ...
> 
> When it comes to defining hotkeys I see basically two possible
> ways to do it:
> 
>  (1) Have a fixed (set of) modifier keys for all hot keys,
>  i.e. something like this:
> 
> -display 
> gtk,hotkey-modifiers=ctrl+shift,hotkey-grab=f12,hotkey-fullscreen=f11
> 
>  (2) Allow complete freedom when defining hotkeys, i.e.
> 
> -display gtk,hotkey-grab=shift+f12,hotkey-fullscreen=ctrl+f11
> 
> 

Re: [Qemu-devel] [PATCH 16/18] Drop superfluous includes of qapi/qmp/dispatch.h

[Eric Blake]

On 01/30/2018 04:22 AM, Markus Armbruster wrote:
> Signed-off-by: Markus Armbruster 
> ---
>  monitor.c | 1 -
>  qga/main.c| 1 -
>  tests/test-qmp-commands.c | 1 -
>  3 files changed, 3 deletions(-)

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 15/18] Include qapi/qmp/qnull.h exactly where needed

[Eric Blake]

On 01/30/2018 04:21 AM, Markus Armbruster wrote:
> Signed-off-by: Markus Armbruster 
> ---
>  target/ppc/translate.c  | 1 -
>  target/ppc/translate_init.c | 1 +
>  2 files changed, 1 insertion(+), 1 deletion(-)
> 
Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 14/18] Include qapi/qmp/qnum.h exactly where needed

[Eric Blake]

On 01/30/2018 04:21 AM, Markus Armbruster wrote:
> Signed-off-by: Markus Armbruster 
> ---
>  tests/check-qlit.c | 1 -
>  1 file changed, 1 deletion(-)

Not much to this one :)

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 13/18] Include qapi/qmp/qbool.h exactly where needed

[Eric Blake]

On 01/30/2018 04:21 AM, Markus Armbruster wrote:
> Signed-off-by: Markus Armbruster 
> ---
>  block.c| 1 -
>  block/blkdebug.c   | 1 -
>  block/curl.c   | 1 -
>  block/qcow2.c  | 1 -
>  block/quorum.c | 1 -
>  block/vvfat.c  | 1 -
>  hw/usb/xen-usb.c   | 1 -
>  monitor.c  | 1 -
>  qemu-img.c | 1 -
>  qemu-io.c  | 1 -
>  target/s390x/cpu_models.c  | 1 -
>  tests/check-qlit.c | 1 -
>  tests/device-introspect-test.c | 1 -
>  ui/spice-core.c| 1 -
>  14 files changed, 14 deletions(-)

All deletions == fun patch

(Obviously, the header is still in use, but your earlier patches in the
series fixed the other .c files that actually need the header, and
weren't already including it, as side effects of cleaning other messes)

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PULL v5 00/43] hppa-softmmu

[Peter Maydell]

On 30 January 2018 at 04:46, Richard Henderson
 wrote:
> Changes since v4:
>   * Fix format warnings for 32-bit host.
>
>
> r~
>
>
> The following changes since commit 30d9fefe1aca1e92c785214aa9201fd7c2287d56:
>
>   Merge remote-tracking branch 
> 'remotes/kraxel/tags/input-20180129-v2-pull-request' into staging (2018-01-29 
> 15:52:27 +)
>
> are available in the Git repository at:
>
>   git://github.com/rth7680/qemu.git tags/pull-hppa-20180129
>
> for you to fetch changes up to 8d077702ca076c0264e111b95c2c211e5ab9a314:
>
>   target/hppa: Implement PROBE for system mode (2018-01-29 20:40:01 -0800)
>
> 
> Implement hppa-softmmu
>
> 

The Windows build fails:

/home/petmay01/linaro/qemu-for-merges/target/hppa/translate.c: In
function ‘gen_hlt’:
/home/petmay01/linaro/qemu-for-merges/target/hppa/translate.c:2336:9:
error: implicit declaration of function ‘gen_helper_shutdown’
[-Werror=implicit-function-declaration]
 gen_helper_shutdown(cpu_env);
 ^
/home/petmay01/linaro/qemu-for-merges/target/hppa/translate.c:2336:9:
error: nested extern declaration of ‘gen_helper_shutdown’
[-Werror=nested-externs]

I think here you're falling foul of this thing in include/win32/os-win32.h:

#define shutdown qemu_shutdown_wrap

which messes up the use in the HELPER macro.


/home/petmay01/linaro/qemu-for-merges/target/hppa/translate.c: In
function ‘trans_probe’:
/home/petmay01/linaro/qemu-for-merges/target/hppa/translate.c:2403:37:
error: ‘PROT_WRITE’ undeclared (first use in this function)
 want = tcg_const_i32(is_write ? PROT_WRITE : PROT_READ);
 ^
/home/petmay01/linaro/qemu-for-merges/target/hppa/translate.c:2403:37:
note: each undeclared identifier is reported only once for each
function it appears in
/home/petmay01/linaro/qemu-for-merges/target/hppa/translate.c:2403:50:
error: ‘PROT_READ’ undeclared (first use in this function)
 want = tcg_const_i32(is_write ? PROT_WRITE : PROT_READ);
  ^
cc1: all warnings being treated as errors

I'm guessing you wanted PAGE_READ and PAGE_WRITE.

thanks
-- PMM

Re: [Qemu-devel] [PATCH 12/18] Include qapi/qmp/qstring.h exactly where needed

[Eric Blake]

On 01/30/2018 04:21 AM, Markus Armbruster wrote:
> Signed-off-by: Markus Armbruster 
> ---

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v6 05/23] target/i386: add memory encryption feature cpuid support

[Dr. David Alan Gilbert]

* Brijesh Singh (brijesh.si...@amd.com) wrote:
> AMD EPYC processors support memory encryption feature. The feature
> is reported through CPUID 8000_001F[EAX].
> 
> Fn8000_001F [EAX]:
>  Bit 0   Secure Memory Encryption (SME) supported
>  Bit 1   Secure Encrypted Virtualization (SEV) supported
>  Bit 2   Page flush MSR supported
>  Bit 3   Ecrypted State (SEV-ES) support
> 
> when memory encryption feature is reported, CPUID 8000_001F[EBX] should
> provide additional information regarding the feature (such as which page
> table bit is used to mark pages as encrypted etc). The information in EBX
> and ECX may vary from one family to another hence we use the host cpuid
> to populate the EBX information.

That's going to make it interesting for migration.  If the guest needs
to know that C-bit position then you presumably can't migrate between
those two host types, but we wouldn't have anything that currently
stops us.
We already have similar problems with variations in physical address
size but normally get away with that, especially on smaller VMs.

Dave


> The details for memory encryption CPUID is available in AMD APM
> (http://support.amd.com/TechDocs/24593.pdf) Section 15.34.1

> Cc: Paolo Bonzini 
> Cc: Richard Henderson 
> Cc: Eduardo Habkost 
> Signed-off-by: Brijesh Singh 
> ---
>  target/i386/cpu.c | 36 
>  target/i386/cpu.h |  6 ++
>  2 files changed, 42 insertions(+)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index a49d2221adc9..4147eb6e18a9 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -234,6 +234,7 @@ static void x86_cpu_vendor_words2str(char *dst, uint32_t 
> vendor1,
>  #define TCG_EXT4_FEATURES 0
>  #define TCG_SVM_FEATURES 0
>  #define TCG_KVM_FEATURES 0
> +#define TCG_MEM_ENCRYPT_FEATURES 0
>  #define TCG_7_0_EBX_FEATURES (CPUID_7_0_EBX_SMEP | CPUID_7_0_EBX_SMAP | \
>CPUID_7_0_EBX_BMI1 | CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_ADX | \
>CPUID_7_0_EBX_PCOMMIT | CPUID_7_0_EBX_CLFLUSHOPT |\
> @@ -545,6 +546,20 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] 
> = {
>  .cpuid_reg = R_EDX,
>  .tcg_features = ~0U,
>  },
> +[FEAT_MEM_ENCRYPT] = {
> +.feat_names = {
> +"sme", "sev", "page-flush-msr", "sev-es",
> +NULL, NULL, NULL, NULL,
> +NULL, NULL, NULL, NULL,
> +NULL, NULL, NULL, NULL,
> +NULL, NULL, NULL, NULL,
> +NULL, NULL, NULL, NULL,
> +NULL, NULL, NULL, NULL,
> +NULL, NULL, NULL, NULL,
> +},
> +.cpuid_eax = 0x801F, .cpuid_reg = R_EAX,
> +.tcg_features = TCG_MEM_ENCRYPT_FEATURES,
> +}
>  };
>  
>  typedef struct X86RegisterInfo32 {
> @@ -1965,6 +1980,9 @@ static X86CPUDefinition builtin_x86_defs[] = {
>  CPUID_XSAVE_XGETBV1,
>  .features[FEAT_6_EAX] =
>  CPUID_6_EAX_ARAT,
> +/* Missing: SEV_ES */
> +.features[FEAT_MEM_ENCRYPT] =
> +CPUID_8000_001F_EAX_SME | CPUID_8000_001F_EAX_SEV,
>  .xlevel = 0x800A,
>  .model_id = "AMD EPYC Processor",
>  },
> @@ -3589,6 +3607,19 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, 
> uint32_t count,
>  *edx = 0;
>  }
>  break;
> +case 0x801F:
> +if (env->features[FEAT_MEM_ENCRYPT] & CPUID_8000_001F_EAX_SEV) {
> +*eax = env->features[FEAT_MEM_ENCRYPT];
> +host_cpuid(0x801F, 0, NULL, ebx, NULL, NULL);
> +*ecx = 0;
> +*edx = 0;
> +} else {
> +*eax = 0;
> +*ebx = 0;
> +*ecx = 0;
> +*edx = 0;
> +}
> +break;
>  case 0xC000:
>  *eax = env->cpuid_xlevel2;
>  *ebx = 0;
> @@ -4036,10 +4067,15 @@ static void x86_cpu_expand_features(X86CPU *cpu, 
> Error **errp)
>  x86_cpu_adjust_feat_level(cpu, FEAT_C000_0001_EDX);
>  x86_cpu_adjust_feat_level(cpu, FEAT_SVM);
>  x86_cpu_adjust_feat_level(cpu, FEAT_XSAVE);
> +x86_cpu_adjust_feat_level(cpu, FEAT_MEM_ENCRYPT);
>  /* SVM requires CPUID[0x800A] */
>  if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_SVM) {
>  x86_cpu_adjust_level(cpu, >cpuid_min_xlevel, 0x800A);
>  }
> +/* SEV requires CPUID[0x801F] */
> +if ((env->features[FEAT_MEM_ENCRYPT] & CPUID_8000_001F_EAX_SEV)) {
> +x86_cpu_adjust_level(cpu, >cpuid_min_xlevel, 0x801F);
> +}
>  }
>  
>  /* Set cpuid_*level* based on cpuid_min_*level, if not explicitly set */
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index f91e37d25dea..f7a0ab20fdd1 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -483,6 +483,7 @@ typedef enum FeatureWord {
>  FEAT_6_EAX, /* CPUID[6].EAX */
>  

Re: [Qemu-devel] [PATCH 10/18] Include qapi/qmp/qlist.h exactly where needed

[Eric Blake]

On 01/30/2018 04:21 AM, Markus Armbruster wrote:
> This cleanup makes the number of objects depending on qapi/qmp/qlist.h
> drop from 4548 (out of 4739) to 16 in my "build everything" tree.
> 
> Signed-off-by: Markus Armbruster 
> ---

> +++ b/tests/check-qdict.c
> @@ -9,9 +9,11 @@
>   * This work is licensed under the terms of the GNU LGPL, version 2.1 or 
> later.
>   * See the COPYING.LIB file in the top-level directory.
>   */
> +
>  #include "qemu/osdep.h"

Another one of these whitespace cleanups around osdep.h that might be
worth collecting into its own patch.

>  
>  #include "qapi/qmp/qdict.h"
> +#include "qapi/qmp/qlist.h"
>  #include "qapi/qmp/qnum.h"
>  #include "qapi/qmp/qstring.h"
>  #include "qapi/error.h"

But at least it was in the same hunk as the actual meat of the commit.

> +++ b/tests/libqtest.c
> @@ -14,6 +14,7 @@
>   * See the COPYING file in the top-level directory.
>   *
>   */
> +
>  #include "qemu/osdep.h"
>  #include "libqtest.h"
>  
> @@ -25,6 +26,7 @@
>  #include "qapi/qmp/json-parser.h"
>  #include "qapi/qmp/json-streamer.h"
>  #include "qapi/qmp/qjson.h"
> +#include "qapi/qmp/qlist.h"
>  

In contrast to this location.

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 11/18] Include qapi/qmp/qdict.h exactly where needed

[Eric Blake]

On 01/30/2018 04:21 AM, Markus Armbruster wrote:
> This cleanup makes the number of objects depending on qapi/qmp/qdict.h
> drop from 4547 (out of 4739) to 368 in my "build everything" tree.
> For qapi/qmp/qobject.h, the number drops from 4549 to 390.
> 
> Signed-off-by: Markus Armbruster 
> ---

> +++ b/block/qcow.c
> @@ -21,6 +21,7 @@
>   * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
>   * THE SOFTWARE.
>   */
> +
>  #include "qemu/osdep.h"
>  #include "qapi/error.h"
>  #include "qemu-common.h"
> @@ -30,6 +31,7 @@
>  #include "qemu/module.h"
>  #include "qemu/bswap.h"
>  #include 
> +#include "qapi/qmp/qdict.h"

Same comments as on other patches in the series.

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v4 09/14] pci: Add support for Designware IP block

[Andrey Smirnov]

On Tue, Jan 30, 2018 at 5:18 AM, Marcel Apfelbaum
 wrote:
> Hi Andrei,
>
> Sorry for letting you wait,
> I have some comments/questions below.
>
>
> On 16/01/2018 3:37, Andrey Smirnov wrote:
>>
>> Add code needed to get a functional PCI subsytem when using in
>> conjunction with upstream Linux guest (4.13+). Tested to work against
>> "e1000e" (network adapter, using MSI interrupts) as well as
>> "usb-ehci" (USB controller, using legacy PCI interrupts).
>>
>> Cc: Peter Maydell 
>> Cc: Jason Wang 
>> Cc: Philippe Mathieu-Daudé 
>> Cc: qemu-devel@nongnu.org
>> Cc: qemu-...@nongnu.org
>> Cc: yurov...@gmail.com
>> Signed-off-by: Andrey Smirnov 
>> ---
>>   default-configs/arm-softmmu.mak  |   2 +
>>   hw/pci-host/Makefile.objs|   2 +
>>   hw/pci-host/designware.c | 618
>> +++
>>   include/hw/pci-host/designware.h |  93 ++
>>   include/hw/pci/pci_ids.h |   2 +
>>   5 files changed, 717 insertions(+)
>>   create mode 100644 hw/pci-host/designware.c
>>   create mode 100644 include/hw/pci-host/designware.h
>>
>> diff --git a/default-configs/arm-softmmu.mak
>> b/default-configs/arm-softmmu.mak
>> index b0d6e65038..0c5ae914ed 100644
>> --- a/default-configs/arm-softmmu.mak
>> +++ b/default-configs/arm-softmmu.mak
>> @@ -132,3 +132,5 @@ CONFIG_GPIO_KEY=y
>>   CONFIG_MSF2=y
>>   CONFIG_FW_CFG_DMA=y
>>   CONFIG_XILINX_AXI=y
>> +CONFIG_PCI_DESIGNWARE=y
>> +
>> diff --git a/hw/pci-host/Makefile.objs b/hw/pci-host/Makefile.objs
>> index 9c7909cf44..0e2c0a123b 100644
>> --- a/hw/pci-host/Makefile.objs
>> +++ b/hw/pci-host/Makefile.objs
>> @@ -17,3 +17,5 @@ common-obj-$(CONFIG_PCI_PIIX) += piix.o
>>   common-obj-$(CONFIG_PCI_Q35) += q35.o
>>   common-obj-$(CONFIG_PCI_GENERIC) += gpex.o
>>   common-obj-$(CONFIG_PCI_XILINX) += xilinx-pcie.o
>> +
>> +common-obj-$(CONFIG_PCI_DESIGNWARE) += designware.o
>> diff --git a/hw/pci-host/designware.c b/hw/pci-host/designware.c
>> new file mode 100644
>> index 00..98fff5e5f3
>> --- /dev/null
>> +++ b/hw/pci-host/designware.c
>> @@ -0,0 +1,618 @@
>> +/*
>> + * Copyright (c) 2017, Impinj, Inc.
>
> 2018 :)
>
>> + *
>> + * Designware PCIe IP block emulation
>> + *
>> + * 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 "qapi/error.h"
>> +#include "hw/pci/msi.h"
>> +#include "hw/pci/pci_bridge.h"
>> +#include "hw/pci/pci_host.h"
>> +#include "hw/pci/pcie_port.h"
>> +#include "hw/pci-host/designware.h"
>> +
>> +#define PCIE_PORT_LINK_CONTROL  0x710
>> +
>> +#define PCIE_PHY_DEBUG_R1   0x72C
>> +#define PCIE_PHY_DEBUG_R1_XMLH_LINK_UP  BIT(4)
>> +
>> +#define PCIE_LINK_WIDTH_SPEED_CONTROL   0x80C
>> +
>> +#define PCIE_MSI_ADDR_LO0x820
>> +#define PCIE_MSI_ADDR_HI0x824
>> +#define PCIE_MSI_INTR0_ENABLE   0x828
>> +#define PCIE_MSI_INTR0_MASK 0x82C
>> +#define PCIE_MSI_INTR0_STATUS   0x830
>> +
>> +#define PCIE_ATU_VIEWPORT   0x900
>> +#define PCIE_ATU_REGION_INBOUND (0x1 << 31)
>> +#define PCIE_ATU_REGION_OUTBOUND(0x0 << 31)
>> +#define PCIE_ATU_REGION_INDEX2  (0x2 << 0)
>> +#define PCIE_ATU_REGION_INDEX1  (0x1 << 0)
>> +#define PCIE_ATU_REGION_INDEX0  (0x0 << 0)
>> +#define PCIE_ATU_CR10x904
>> +#define PCIE_ATU_TYPE_MEM   (0x0 << 0)
>> +#define PCIE_ATU_TYPE_IO(0x2 << 0)
>> +#define PCIE_ATU_TYPE_CFG0  (0x4 << 0)
>> +#define PCIE_ATU_TYPE_CFG1  (0x5 << 0)
>> +#define PCIE_ATU_CR20x908
>> +#define PCIE_ATU_ENABLE (0x1 << 31)
>> +#define PCIE_ATU_BAR_MODE_ENABLE(0x1 << 30)
>> +#define PCIE_ATU_LOWER_BASE 0x90C
>> +#define PCIE_ATU_UPPER_BASE 0x910
>> +#define PCIE_ATU_LIMIT  0x914
>> +#define PCIE_ATU_LOWER_TARGET   0x918
>> +#define PCIE_ATU_BUS(x) (((x) >> 24) & 0xff)
>> +#define PCIE_ATU_DEVFN(x)   (((x) >> 16) & 0xff)
>> +#define PCIE_ATU_UPPER_TARGET   0x91C
>> +
>> +static DesignwarePCIEHost *
>> +designware_pcie_root_to_host(DesignwarePCIERoot *root)
>> +{
>> +BusState 

[Qemu-devel] [PULL 04/10] tests: virtio-9p: wait for completion in the test code

[Greg Kurz]

In order to test request cancellation, we will need to send multiple
requests and wait for the associated replies. Since we poll the ISR
to know if a request completed, we may have several replies to parse
when we detect ISR was set to 1.

This patch moves the waiting out of the reply parsing path, up into
the functional tests.

Signed-off-by: Greg Kurz 
Reviewed-by: Stefan Hajnoczi 
---
 tests/virtio-9p-test.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/tests/virtio-9p-test.c b/tests/virtio-9p-test.c
index 5ada2839b9ae..cb086315a36e 100644
--- a/tests/virtio-9p-test.c
+++ b/tests/virtio-9p-test.c
@@ -246,13 +246,17 @@ static const char *rmessage_name(uint8_t id)
 "";
 }
 
-static void v9fs_req_recv(P9Req *req, uint8_t id)
+static void v9fs_req_wait_for_reply(P9Req *req)
 {
 QVirtIO9P *v9p = req->v9p;
-P9Hdr hdr;
 
 qvirtio_wait_used_elem(v9p->dev, v9p->vq, req->free_head,
QVIRTIO_9P_TIMEOUT_US);
+}
+
+static void v9fs_req_recv(P9Req *req, uint8_t id)
+{
+P9Hdr hdr;
 
 v9fs_memread(req, , 7);
 hdr.size = ldl_le_p();
@@ -398,6 +402,7 @@ static void fs_version(QVirtIO9P *v9p)
 P9Req *req;
 
 req = v9fs_tversion(v9p, P9_MAX_SIZE, version, P9_NOTAG);
+v9fs_req_wait_for_reply(req);
 v9fs_rversion(req, _len, _version);
 
 g_assert_cmpmem(server_version, server_len, version, strlen(version));
@@ -411,6 +416,7 @@ static void fs_attach(QVirtIO9P *v9p)
 
 fs_version(v9p);
 req = v9fs_tattach(v9p, 0, getuid(), 0);
+v9fs_req_wait_for_reply(req);
 v9fs_rattach(req, NULL);
 }
 
@@ -431,6 +437,7 @@ static void fs_walk(QVirtIO9P *v9p)
 
 fs_attach(v9p);
 req = v9fs_twalk(v9p, 0, 1, P9_MAXWELEM, wnames, 0);
+v9fs_req_wait_for_reply(req);
 v9fs_rwalk(req, , );
 
 g_assert_cmpint(nwqid, ==, P9_MAXWELEM);
@@ -452,6 +459,7 @@ static void fs_walk_no_slash(QVirtIO9P *v9p)
 
 fs_attach(v9p);
 req = v9fs_twalk(v9p, 0, 1, 1, wnames, 0);
+v9fs_req_wait_for_reply(req);
 v9fs_rlerror(req, );
 
 g_assert_cmpint(err, ==, ENOENT);
@@ -467,9 +475,11 @@ static void fs_walk_dotdot(QVirtIO9P *v9p)
 
 fs_version(v9p);
 req = v9fs_tattach(v9p, 0, getuid(), 0);
+v9fs_req_wait_for_reply(req);
 v9fs_rattach(req, _qid);
 
 req = v9fs_twalk(v9p, 0, 1, 1, wnames, 0);
+v9fs_req_wait_for_reply(req);
 v9fs_rwalk(req, NULL, ); /* We now we'll get one qid */
 
 g_assert_cmpmem(_qid, 13, wqid[0], 13);
-- 
2.13.6

[Qemu-devel] [PULL 09/10] tests: virtio-9p: add FLUSH operation test

[Greg Kurz]

The idea is to send a victim request that will possibly block in the
server and to send a flush request to cancel the victim request.

This patch adds two test to verifiy that:
- the server does not reply to a victim request that was actually
  cancelled
- the server replies to the flush request after replying to the
  victim request if it could not cancel it

9p request cancellation reference:

http://man.cat-v.org/plan_9/5/flush

Signed-off-by: Greg Kurz 
Reviewed-by: Stefan Hajnoczi 
---
 hw/9pfs/9p-synth.c |  24 ++
 hw/9pfs/9p-synth.h |   5 +++
 hw/9pfs/9p.c   |   1 +
 tests/virtio-9p-test.c | 117 +++--
 4 files changed, 134 insertions(+), 13 deletions(-)

diff --git a/hw/9pfs/9p-synth.c b/hw/9pfs/9p-synth.c
index f2d59a90a670..0a9940dfa23c 100644
--- a/hw/9pfs/9p-synth.c
+++ b/hw/9pfs/9p-synth.c
@@ -521,6 +521,24 @@ static ssize_t v9fs_synth_qtest_write(void *buf, int len, 
off_t offset,
 return len;
 }
 
+static ssize_t v9fs_synth_qtest_flush_write(void *buf, int len, off_t offset,
+void *arg)
+{
+QtestV9fsSynthFlushData *data = buf;
+
+assert(len == sizeof(*data));
+
+if (data->usec_timeout) {
+usleep(data->usec_timeout);
+
+/* This will cause the server to call us again until we're cancelled */
+errno = EINTR;
+return -1;
+}
+
+return len;
+}
+
 static int synth_init(FsContext *ctx, Error **errp)
 {
 QLIST_INIT(_root.child);
@@ -557,6 +575,12 @@ static int synth_init(FsContext *ctx, Error **errp)
 ret = qemu_v9fs_synth_add_file(NULL, 0, QTEST_V9FS_SYNTH_WRITE_FILE,
NULL, v9fs_synth_qtest_write, ctx);
 assert(!ret);
+
+/* File for FLUSH test */
+ret = qemu_v9fs_synth_add_file(NULL, 0, QTEST_V9FS_SYNTH_FLUSH_FILE,
+   NULL, v9fs_synth_qtest_flush_write,
+   ctx);
+assert(!ret);
 }
 
 return 0;
diff --git a/hw/9pfs/9p-synth.h b/hw/9pfs/9p-synth.h
index a74032d7bd9a..502ec6309a36 100644
--- a/hw/9pfs/9p-synth.h
+++ b/hw/9pfs/9p-synth.h
@@ -54,5 +54,10 @@ int qemu_v9fs_synth_add_file(V9fsSynthNode *parent, int mode,
 #define QTEST_V9FS_SYNTH_WALK_FILE "WALK%d"
 #define QTEST_V9FS_SYNTH_LOPEN_FILE "LOPEN"
 #define QTEST_V9FS_SYNTH_WRITE_FILE "WRITE"
+#define QTEST_V9FS_SYNTH_FLUSH_FILE "FLUSH"
+
+typedef struct {
+uint32_t usec_timeout;
+} QtestV9fsSynthFlushData;
 
 #endif
diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index e88bb50f1365..85a1ed8171a4 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -24,6 +24,7 @@
 #include "coth.h"
 #include "trace.h"
 #include "migration/blocker.h"
+#include "sysemu/qtest.h"
 
 int open_fd_hw;
 int total_open_fd;
diff --git a/tests/virtio-9p-test.c b/tests/virtio-9p-test.c
index cef21aea76c9..41fa492cb778 100644
--- a/tests/virtio-9p-test.c
+++ b/tests/virtio-9p-test.c
@@ -247,14 +247,15 @@ static const char *rmessage_name(uint8_t id)
 id == P9_RWALK ? "RWALK" :
 id == P9_RLOPEN ? "RLOPEN" :
 id == P9_RWRITE ? "RWRITE" :
+id == P9_RFLUSH ? "RFLUSH" :
 "";
 }
 
-static void v9fs_req_wait_for_reply(P9Req *req)
+static void v9fs_req_wait_for_reply(P9Req *req, uint32_t *len)
 {
 QVirtIO9P *v9p = req->v9p;
 
-qvirtio_wait_used_elem(v9p->dev, v9p->vq, req->free_head, NULL,
+qvirtio_wait_used_elem(v9p->dev, v9p->vq, req->free_head, len,
QVIRTIO_9P_TIMEOUT_US);
 }
 
@@ -454,6 +455,24 @@ static void v9fs_rwrite(P9Req *req, uint32_t *count)
 v9fs_req_free(req);
 }
 
+/* size[4] Tflush tag[2] oldtag[2] */
+static P9Req *v9fs_tflush(QVirtIO9P *v9p, uint16_t oldtag, uint16_t tag)
+{
+P9Req *req;
+
+req = v9fs_req_init(v9p,  2, P9_TFLUSH, tag);
+v9fs_uint32_write(req, oldtag);
+v9fs_req_send(req);
+return req;
+}
+
+/* size[4] Rflush tag[2] */
+static void v9fs_rflush(P9Req *req)
+{
+v9fs_req_recv(req, P9_RFLUSH);
+v9fs_req_free(req);
+}
+
 static void fs_version(QVirtIO9P *v9p)
 {
 const char *version = "9P2000.L";
@@ -462,7 +481,7 @@ static void fs_version(QVirtIO9P *v9p)
 P9Req *req;
 
 req = v9fs_tversion(v9p, P9_MAX_SIZE, version, P9_NOTAG);
-v9fs_req_wait_for_reply(req);
+v9fs_req_wait_for_reply(req, NULL);
 v9fs_rversion(req, _len, _version);
 
 g_assert_cmpmem(server_version, server_len, version, strlen(version));
@@ -476,7 +495,7 @@ static void fs_attach(QVirtIO9P *v9p)
 
 fs_version(v9p);
 req = v9fs_tattach(v9p, 0, getuid(), 0);
-v9fs_req_wait_for_reply(req);
+v9fs_req_wait_for_reply(req, NULL);
 v9fs_rattach(req, NULL);
 }
 
@@ -494,7 +513,7 @@ static void fs_walk(QVirtIO9P *v9p)
 
 fs_attach(v9p);
 req = v9fs_twalk(v9p, 0, 1, P9_MAXWELEM, wnames, 0);
-v9fs_req_wait_for_reply(req);
+v9fs_req_wait_for_reply(req, NULL);
 

[Qemu-devel] [PULL 01/10] 9pfs: drop v9fs_register_transport()

[Greg Kurz]

No good reasons to do this outside of v9fs_device_realize_common().

Signed-off-by: Greg Kurz 
Reviewed-by: Stefano Stabellini 
---
 hw/9pfs/9p.c   |  6 +-
 hw/9pfs/9p.h   | 10 ++
 hw/9pfs/virtio-9p-device.c |  8 ++--
 hw/9pfs/xen-9p-backend.c   |  3 +--
 4 files changed, 10 insertions(+), 17 deletions(-)

diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index 909a61139405..364c7cb44628 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -3485,7 +3485,8 @@ void pdu_submit(V9fsPDU *pdu, P9MsgHeader *hdr)
 }
 
 /* Returns 0 on success, 1 on failure. */
-int v9fs_device_realize_common(V9fsState *s, Error **errp)
+int v9fs_device_realize_common(V9fsState *s, const V9fsTransport *t,
+   Error **errp)
 {
 int i, len;
 struct stat stat;
@@ -3493,6 +3494,9 @@ int v9fs_device_realize_common(V9fsState *s, Error **errp)
 V9fsPath path;
 int rc = 1;
 
+assert(!s->transport);
+s->transport = t;
+
 /* initialize pdu allocator */
 QLIST_INIT(>free_list);
 QLIST_INIT(>active_list);
diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h
index ffe658ab8975..5ced427d861b 100644
--- a/hw/9pfs/9p.h
+++ b/hw/9pfs/9p.h
@@ -346,7 +346,8 @@ void v9fs_path_sprintf(V9fsPath *path, const char *fmt, 
...);
 void v9fs_path_copy(V9fsPath *lhs, V9fsPath *rhs);
 int v9fs_name_to_path(V9fsState *s, V9fsPath *dirpath,
   const char *name, V9fsPath *path);
-int v9fs_device_realize_common(V9fsState *s, Error **errp);
+int v9fs_device_realize_common(V9fsState *s, const V9fsTransport *t,
+   Error **errp);
 void v9fs_device_unrealize_common(V9fsState *s, Error **errp);
 
 V9fsPDU *pdu_alloc(V9fsState *s);
@@ -366,11 +367,4 @@ struct V9fsTransport {
 void(*push_and_notify)(V9fsPDU *pdu);
 };
 
-static inline int v9fs_register_transport(V9fsState *s, const V9fsTransport *t)
-{
-assert(!s->transport);
-s->transport = t;
-return 0;
-}
-
 #endif
diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index 43f4e53f336f..775e8ff76671 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -198,17 +198,13 @@ static void virtio_9p_device_realize(DeviceState *dev, 
Error **errp)
 V9fsVirtioState *v = VIRTIO_9P(dev);
 V9fsState *s = >state;
 
-if (v9fs_device_realize_common(s, errp)) {
-goto out;
+if (v9fs_device_realize_common(s, _9p_transport, errp)) {
+return;
 }
 
 v->config_size = sizeof(struct virtio_9p_config) + strlen(s->fsconf.tag);
 virtio_init(vdev, "virtio-9p", VIRTIO_ID_9P, v->config_size);
 v->vq = virtio_add_queue(vdev, MAX_REQ, handle_9p_output);
-v9fs_register_transport(s, _9p_transport);
-
-out:
-return;
 }
 
 static void virtio_9p_device_unrealize(DeviceState *dev, Error **errp)
diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
index df2a4100bf55..14f0d6a50e75 100644
--- a/hw/9pfs/xen-9p-backend.c
+++ b/hw/9pfs/xen-9p-backend.c
@@ -446,7 +446,6 @@ static int xen_9pfs_connect(struct XenDevice *xendev)
 xen_9pdev->id = s->fsconf.fsdev_id =
 g_strdup_printf("xen9p%d", xendev->dev);
 xen_9pdev->tag = s->fsconf.tag = xenstore_read_fe_str(xendev, "tag");
-v9fs_register_transport(s, _9p_transport);
 fsdev = qemu_opts_create(qemu_find_opts("fsdev"),
 s->fsconf.tag,
 1, NULL);
@@ -455,7 +454,7 @@ static int xen_9pfs_connect(struct XenDevice *xendev)
 qemu_opt_set(fsdev, "security_model", xen_9pdev->security_model, NULL);
 qemu_opts_set_id(fsdev, s->fsconf.fsdev_id);
 qemu_fsdev_add(fsdev);
-v9fs_device_realize_common(s, NULL);
+v9fs_device_realize_common(s, _9p_transport, NULL);
 
 return 0;
 
-- 
2.13.6

[Qemu-devel] [PULL 08/10] libqos/virtio: return length written into used descriptor

[Greg Kurz]

When a 9p request is flushed (ie, cancelled) by the guest, the device
is expected to simply mark the request as used, without sending a 9p
reply (ie, without writing anything into the used buffer).

To be able to test this, we need access to the length written by the
device into the used descriptor. This patch adds a uint32_t * argument
to qvirtqueue_get_buf() and qvirtio_wait_used_elem() for this purpose.

All existing users are updated accordingly.

Signed-off-by: Greg Kurz 
Reviewed-by: Stefan Hajnoczi 
---
 tests/libqos/virtio.c| 25 +
 tests/libqos/virtio.h|  3 ++-
 tests/virtio-9p-test.c   |  2 +-
 tests/virtio-blk-test.c  | 24 +---
 tests/virtio-net-test.c  |  6 +++---
 tests/virtio-scsi-test.c |  3 ++-
 6 files changed, 38 insertions(+), 25 deletions(-)

diff --git a/tests/libqos/virtio.c b/tests/libqos/virtio.c
index 0879a621c8af..0dad5c19acde 100644
--- a/tests/libqos/virtio.c
+++ b/tests/libqos/virtio.c
@@ -119,6 +119,8 @@ uint8_t qvirtio_wait_status_byte_no_isr(QVirtioDevice *d,
 /*
  * qvirtio_wait_used_elem:
  * @desc_idx: The next expected vq->desc[] index in the used ring
+ * @len: A pointer that is filled with the length written into the buffer, may
+ *   be NULL
  * @timeout_us: How many microseconds to wait before failing
  *
  * This function waits for the next completed request on the used ring.
@@ -126,6 +128,7 @@ uint8_t qvirtio_wait_status_byte_no_isr(QVirtioDevice *d,
 void qvirtio_wait_used_elem(QVirtioDevice *d,
 QVirtQueue *vq,
 uint32_t desc_idx,
+uint32_t *len,
 gint64 timeout_us)
 {
 gint64 start_time = g_get_monotonic_time();
@@ -136,7 +139,7 @@ void qvirtio_wait_used_elem(QVirtioDevice *d,
 clock_step(100);
 
 if (d->bus->get_queue_isr_status(d, vq) &&
-qvirtqueue_get_buf(vq, _desc_idx)) {
+qvirtqueue_get_buf(vq, _desc_idx, len)) {
 g_assert_cmpint(got_desc_idx, ==, desc_idx);
 return;
 }
@@ -304,30 +307,36 @@ void qvirtqueue_kick(QVirtioDevice *d, QVirtQueue *vq, 
uint32_t free_head)
 /*
  * qvirtqueue_get_buf:
  * @desc_idx: A pointer that is filled with the vq->desc[] index, may be NULL
+ * @len: A pointer that is filled with the length written into the buffer, may
+ *   be NULL
  *
  * This function gets the next used element if there is one ready.
  *
  * Returns: true if an element was ready, false otherwise
  */
-bool qvirtqueue_get_buf(QVirtQueue *vq, uint32_t *desc_idx)
+bool qvirtqueue_get_buf(QVirtQueue *vq, uint32_t *desc_idx, uint32_t *len)
 {
 uint16_t idx;
+uint64_t elem_addr;
 
 idx = readw(vq->used + offsetof(struct vring_used, idx));
 if (idx == vq->last_used_idx) {
 return false;
 }
 
-if (desc_idx) {
-uint64_t elem_addr;
+elem_addr = vq->used +
+offsetof(struct vring_used, ring) +
+(vq->last_used_idx % vq->size) *
+sizeof(struct vring_used_elem);
 
-elem_addr = vq->used +
-offsetof(struct vring_used, ring) +
-(vq->last_used_idx % vq->size) *
-sizeof(struct vring_used_elem);
+if (desc_idx) {
 *desc_idx = readl(elem_addr + offsetof(struct vring_used_elem, id));
 }
 
+if (len) {
+*len = readw(elem_addr + offsetof(struct vring_used_elem, len));
+}
+
 vq->last_used_idx++;
 return true;
 }
diff --git a/tests/libqos/virtio.h b/tests/libqos/virtio.h
index 0a04740adfe1..69b5b13840e7 100644
--- a/tests/libqos/virtio.h
+++ b/tests/libqos/virtio.h
@@ -124,6 +124,7 @@ uint8_t qvirtio_wait_status_byte_no_isr(QVirtioDevice *d,
 void qvirtio_wait_used_elem(QVirtioDevice *d,
 QVirtQueue *vq,
 uint32_t desc_idx,
+uint32_t *len,
 gint64 timeout_us);
 void qvirtio_wait_config_isr(QVirtioDevice *d, gint64 timeout_us);
 QVirtQueue *qvirtqueue_setup(QVirtioDevice *d,
@@ -140,7 +141,7 @@ uint32_t qvirtqueue_add(QVirtQueue *vq, uint64_t data, 
uint32_t len, bool write,
 bool next);
 uint32_t qvirtqueue_add_indirect(QVirtQueue *vq, QVRingIndirectDesc *indirect);
 void qvirtqueue_kick(QVirtioDevice *d, QVirtQueue *vq, uint32_t free_head);
-bool qvirtqueue_get_buf(QVirtQueue *vq, uint32_t *desc_idx);
+bool qvirtqueue_get_buf(QVirtQueue *vq, uint32_t *desc_idx, uint32_t *len);
 
 void qvirtqueue_set_used_event(QVirtQueue *vq, uint16_t idx);
 
diff --git a/tests/virtio-9p-test.c b/tests/virtio-9p-test.c
index 37a7dae3f78e..cef21aea76c9 100644
--- a/tests/virtio-9p-test.c
+++ b/tests/virtio-9p-test.c
@@ -254,7 +254,7 @@ static void v9fs_req_wait_for_reply(P9Req *req)
 {
 QVirtIO9P *v9p = req->v9p;
 
-qvirtio_wait_used_elem(v9p->dev, v9p->vq, 

[Qemu-devel] [PULL 07/10] tests: virtio-9p: add WRITE operation test

[Greg Kurz]

Trivial test of a successful write.

Signed-off-by: Greg Kurz 
(groug, handle potential overflow when computing request size)
Reviewed-by: Stefan Hajnoczi 
---
 hw/9pfs/9p-synth.c | 11 +
 hw/9pfs/9p-synth.h |  1 +
 tests/virtio-9p-test.c | 62 ++
 3 files changed, 74 insertions(+)

diff --git a/hw/9pfs/9p-synth.c b/hw/9pfs/9p-synth.c
index f17b74f44461..f2d59a90a670 100644
--- a/hw/9pfs/9p-synth.c
+++ b/hw/9pfs/9p-synth.c
@@ -515,6 +515,12 @@ static int synth_unlinkat(FsContext *ctx, V9fsPath *dir,
 return -1;
 }
 
+static ssize_t v9fs_synth_qtest_write(void *buf, int len, off_t offset,
+  void *arg)
+{
+return len;
+}
+
 static int synth_init(FsContext *ctx, Error **errp)
 {
 QLIST_INIT(_root.child);
@@ -546,6 +552,11 @@ static int synth_init(FsContext *ctx, Error **errp)
 ret = qemu_v9fs_synth_add_file(NULL, 0, QTEST_V9FS_SYNTH_LOPEN_FILE,
NULL, NULL, ctx);
 assert(!ret);
+
+/* File for WRITE test */
+ret = qemu_v9fs_synth_add_file(NULL, 0, QTEST_V9FS_SYNTH_WRITE_FILE,
+   NULL, v9fs_synth_qtest_write, ctx);
+assert(!ret);
 }
 
 return 0;
diff --git a/hw/9pfs/9p-synth.h b/hw/9pfs/9p-synth.h
index 2a8d6fd00d69..a74032d7bd9a 100644
--- a/hw/9pfs/9p-synth.h
+++ b/hw/9pfs/9p-synth.h
@@ -53,5 +53,6 @@ int qemu_v9fs_synth_add_file(V9fsSynthNode *parent, int mode,
 
 #define QTEST_V9FS_SYNTH_WALK_FILE "WALK%d"
 #define QTEST_V9FS_SYNTH_LOPEN_FILE "LOPEN"
+#define QTEST_V9FS_SYNTH_WRITE_FILE "WRITE"
 
 #endif
diff --git a/tests/virtio-9p-test.c b/tests/virtio-9p-test.c
index 6ba782e24f3a..37a7dae3f78e 100644
--- a/tests/virtio-9p-test.c
+++ b/tests/virtio-9p-test.c
@@ -150,6 +150,13 @@ static void v9fs_uint32_write(P9Req *req, uint32_t val)
 v9fs_memwrite(req, _val, 4);
 }
 
+static void v9fs_uint64_write(P9Req *req, uint64_t val)
+{
+uint64_t le_val = cpu_to_le64(val);
+
+v9fs_memwrite(req, _val, 8);
+}
+
 static void v9fs_uint32_read(P9Req *req, uint32_t *val)
 {
 v9fs_memread(req, val, 4);
@@ -239,6 +246,7 @@ static const char *rmessage_name(uint8_t id)
 id == P9_RATTACH ? "RATTACH" :
 id == P9_RWALK ? "RWALK" :
 id == P9_RLOPEN ? "RLOPEN" :
+id == P9_RWRITE ? "RWRITE" :
 "";
 }
 
@@ -418,6 +426,34 @@ static void v9fs_rlopen(P9Req *req, v9fs_qid *qid, 
uint32_t *iounit)
 v9fs_req_free(req);
 }
 
+/* size[4] Twrite tag[2] fid[4] offset[8] count[4] data[count] */
+static P9Req *v9fs_twrite(QVirtIO9P *v9p, uint32_t fid, uint64_t offset,
+  uint32_t count, const void *data, uint16_t tag)
+{
+P9Req *req;
+uint32_t body_size = 4 + 8 + 4;
+
+g_assert_cmpint(body_size, <=, UINT32_MAX - count);
+body_size += count;
+req = v9fs_req_init(v9p,  body_size, P9_TWRITE, tag);
+v9fs_uint32_write(req, fid);
+v9fs_uint64_write(req, offset);
+v9fs_uint32_write(req, count);
+v9fs_memwrite(req, data, count);
+v9fs_req_send(req);
+return req;
+}
+
+/* size[4] Rwrite tag[2] count[4] */
+static void v9fs_rwrite(P9Req *req, uint32_t *count)
+{
+v9fs_req_recv(req, P9_RWRITE);
+if (count) {
+v9fs_uint32_read(req, count);
+}
+v9fs_req_free(req);
+}
+
 static void fs_version(QVirtIO9P *v9p)
 {
 const char *version = "9P2000.L";
@@ -524,6 +560,31 @@ static void fs_lopen(QVirtIO9P *v9p)
 g_free(wnames[0]);
 }
 
+static void fs_write(QVirtIO9P *v9p)
+{
+static const uint32_t write_count = P9_MAX_SIZE / 2;
+char *const wnames[] = { g_strdup(QTEST_V9FS_SYNTH_WRITE_FILE) };
+char *buf = g_malloc(write_count);
+uint32_t count;
+P9Req *req;
+
+fs_attach(v9p);
+req = v9fs_twalk(v9p, 0, 1, 1, wnames, 0);
+v9fs_req_wait_for_reply(req);
+v9fs_rwalk(req, NULL, NULL);
+
+req = v9fs_tlopen(v9p, 1, O_WRONLY, 0);
+v9fs_req_wait_for_reply(req);
+v9fs_rlopen(req, NULL, NULL);
+
+req = v9fs_twrite(v9p, 1, 0, write_count, buf, 0);
+v9fs_req_wait_for_reply(req);
+v9fs_rwrite(req, );
+g_assert_cmpint(count, ==, write_count);
+
+g_free(wnames[0]);
+}
+
 typedef void (*v9fs_test_fn)(QVirtIO9P *v9p);
 
 static void v9fs_run_pci_test(gconstpointer data)
@@ -554,6 +615,7 @@ int main(int argc, char **argv)
 v9fs_qtest_pci_add("/virtio/9p/pci/fs/walk/dotdot_from_root",
fs_walk_dotdot);
 v9fs_qtest_pci_add("/virtio/9p/pci/fs/lopen/basic", fs_lopen);
+v9fs_qtest_pci_add("/virtio/9p/pci/fs/write/basic", fs_write);
 
 return g_test_run();
 }
-- 
2.13.6

[Qemu-devel] [PULL 10/10] tests/virtio-9p: explicitly handle potential integer overflows

[Greg Kurz]

Signed-off-by: Greg Kurz 
Reviewed-by: Eric Blake 
Reviewed-by: Stefan Hajnoczi 
---
 tests/virtio-9p-test.c | 31 +--
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/tests/virtio-9p-test.c b/tests/virtio-9p-test.c
index 41fa492cb778..f4824fa33b87 100644
--- a/tests/virtio-9p-test.c
+++ b/tests/virtio-9p-test.c
@@ -168,7 +168,7 @@ static uint16_t v9fs_string_size(const char *string)
 {
 size_t len = strlen(string);
 
-g_assert_cmpint(len, <=, UINT16_MAX);
+g_assert_cmpint(len, <=, UINT16_MAX - 2);
 
 return 2 + len;
 }
@@ -209,17 +209,20 @@ static P9Req *v9fs_req_init(QVirtIO9P *v9p, uint32_t 
size, uint8_t id,
 uint16_t tag)
 {
 P9Req *req = g_new0(P9Req, 1);
-uint32_t t_size = 7 + size; /* 9P header has well-known size of 7 bytes */
+uint32_t total_size = 7; /* 9P header has well-known size of 7 bytes */
 P9Hdr hdr = {
-.size = cpu_to_le32(t_size),
 .id = id,
 .tag = cpu_to_le16(tag)
 };
 
-g_assert_cmpint(t_size, <=, P9_MAX_SIZE);
+g_assert_cmpint(total_size, <=, UINT32_MAX - size);
+total_size += size;
+hdr.size = cpu_to_le32(total_size);
+
+g_assert_cmpint(total_size, <=, P9_MAX_SIZE);
 
 req->v9p = v9p;
-req->t_size = t_size;
+req->t_size = total_size;
 req->t_msg = guest_alloc(v9p->qs->alloc, req->t_size);
 v9fs_memwrite(req, , 7);
 req->tag = tag;
@@ -305,8 +308,13 @@ static void v9fs_rlerror(P9Req *req, uint32_t *err)
 static P9Req *v9fs_tversion(QVirtIO9P *v9p, uint32_t msize, const char 
*version,
 uint16_t tag)
 {
-P9Req *req = v9fs_req_init(v9p, 4 + v9fs_string_size(version), P9_TVERSION,
-   tag);
+P9Req *req;
+uint32_t body_size = 4;
+uint16_t string_size = v9fs_string_size(version);
+
+g_assert_cmpint(body_size, <=, UINT32_MAX - string_size);
+body_size += string_size;
+req = v9fs_req_init(v9p, body_size, P9_TVERSION, tag);
 
 v9fs_uint32_write(req, msize);
 v9fs_string_write(req, version);
@@ -366,12 +374,15 @@ static P9Req *v9fs_twalk(QVirtIO9P *v9p, uint32_t fid, 
uint32_t newfid,
 {
 P9Req *req;
 int i;
-uint32_t size = 4 + 4 + 2;
+uint32_t body_size = 4 + 4 + 2;
 
 for (i = 0; i < nwname; i++) {
-size += v9fs_string_size(wnames[i]);
+uint16_t wname_size = v9fs_string_size(wnames[i]);
+
+g_assert_cmpint(body_size, <=, UINT32_MAX - wname_size);
+body_size += wname_size;
 }
-req = v9fs_req_init(v9p,  size, P9_TWALK, tag);
+req = v9fs_req_init(v9p,  body_size, P9_TWALK, tag);
 v9fs_uint32_write(req, fid);
 v9fs_uint32_write(req, newfid);
 v9fs_uint16_write(req, nwname);
-- 
2.13.6

[Qemu-devel] [PULL 03/10] tests: virtio-9p: move request tag to the test functions

[Greg Kurz]

It doesn't really makes sense to hide the request tag from the test
functions. It prevents to test the 9p server behavior when passed
a wrong tag (ie, still in use or different from P9_NOTAG for a
version request). Also the spec says that a tag is reusable as soon
as the corresponding request was replied or flushed: no need to
always increment tags like we do now. And finaly, an upcoming test
of the flush command will need to manipulate tags explicitely.

This simply changes all request functions to have a tag argument.
Except for the version request which needs P9_NOTAG, all other
tests can pass 0 since they wait for the reply before sending
another request.

Signed-off-by: Greg Kurz 
Reviewed-by: Stefan Hajnoczi 
---
 tests/virtio-9p-test.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/tests/virtio-9p-test.c b/tests/virtio-9p-test.c
index 00f00f7246e9..5ada2839b9ae 100644
--- a/tests/virtio-9p-test.c
+++ b/tests/virtio-9p-test.c
@@ -27,7 +27,6 @@ typedef struct {
 QOSState *qs;
 QVirtQueue *vq;
 char *test_share;
-uint16_t p9_req_tag;
 } QVirtIO9P;
 
 static QVirtIO9P *qvirtio_9p_start(const char *driver)
@@ -294,10 +293,11 @@ static void v9fs_rlerror(P9Req *req, uint32_t *err)
 }
 
 /* size[4] Tversion tag[2] msize[4] version[s] */
-static P9Req *v9fs_tversion(QVirtIO9P *v9p, uint32_t msize, const char 
*version)
+static P9Req *v9fs_tversion(QVirtIO9P *v9p, uint32_t msize, const char 
*version,
+uint16_t tag)
 {
 P9Req *req = v9fs_req_init(v9p, 4 + v9fs_string_size(version), P9_TVERSION,
-   P9_NOTAG);
+   tag);
 
 v9fs_uint32_write(req, msize);
 v9fs_string_write(req, version);
@@ -323,12 +323,12 @@ static void v9fs_rversion(P9Req *req, uint16_t *len, char 
**version)
 }
 
 /* size[4] Tattach tag[2] fid[4] afid[4] uname[s] aname[s] n_uname[4] */
-static P9Req *v9fs_tattach(QVirtIO9P *v9p, uint32_t fid, uint32_t n_uname)
+static P9Req *v9fs_tattach(QVirtIO9P *v9p, uint32_t fid, uint32_t n_uname,
+   uint16_t tag)
 {
 const char *uname = ""; /* ignored by QEMU */
 const char *aname = ""; /* ignored by QEMU */
-P9Req *req = v9fs_req_init(v9p, 4 + 4 + 2 + 2 + 4, P9_TATTACH,
-   ++(v9p->p9_req_tag));
+P9Req *req = v9fs_req_init(v9p, 4 + 4 + 2 + 2 + 4, P9_TATTACH, tag);
 
 v9fs_uint32_write(req, fid);
 v9fs_uint32_write(req, P9_NOFID);
@@ -353,7 +353,7 @@ static void v9fs_rattach(P9Req *req, v9fs_qid *qid)
 
 /* size[4] Twalk tag[2] fid[4] newfid[4] nwname[2] nwname*(wname[s]) */
 static P9Req *v9fs_twalk(QVirtIO9P *v9p, uint32_t fid, uint32_t newfid,
- uint16_t nwname, char *const wnames[])
+ uint16_t nwname, char *const wnames[], uint16_t tag)
 {
 P9Req *req;
 int i;
@@ -362,7 +362,7 @@ static P9Req *v9fs_twalk(QVirtIO9P *v9p, uint32_t fid, 
uint32_t newfid,
 for (i = 0; i < nwname; i++) {
 size += v9fs_string_size(wnames[i]);
 }
-req = v9fs_req_init(v9p,  size, P9_TWALK, ++(v9p->p9_req_tag));
+req = v9fs_req_init(v9p,  size, P9_TWALK, tag);
 v9fs_uint32_write(req, fid);
 v9fs_uint32_write(req, newfid);
 v9fs_uint16_write(req, nwname);
@@ -397,7 +397,7 @@ static void fs_version(QVirtIO9P *v9p)
 char *server_version;
 P9Req *req;
 
-req = v9fs_tversion(v9p, P9_MAX_SIZE, version);
+req = v9fs_tversion(v9p, P9_MAX_SIZE, version, P9_NOTAG);
 v9fs_rversion(req, _len, _version);
 
 g_assert_cmpmem(server_version, server_len, version, strlen(version));
@@ -410,7 +410,7 @@ static void fs_attach(QVirtIO9P *v9p)
 P9Req *req;
 
 fs_version(v9p);
-req = v9fs_tattach(v9p, 0, getuid());
+req = v9fs_tattach(v9p, 0, getuid(), 0);
 v9fs_rattach(req, NULL);
 }
 
@@ -430,7 +430,7 @@ static void fs_walk(QVirtIO9P *v9p)
 }
 
 fs_attach(v9p);
-req = v9fs_twalk(v9p, 0, 1, P9_MAXWELEM, wnames);
+req = v9fs_twalk(v9p, 0, 1, P9_MAXWELEM, wnames, 0);
 v9fs_rwalk(req, , );
 
 g_assert_cmpint(nwqid, ==, P9_MAXWELEM);
@@ -451,7 +451,7 @@ static void fs_walk_no_slash(QVirtIO9P *v9p)
 uint32_t err;
 
 fs_attach(v9p);
-req = v9fs_twalk(v9p, 0, 1, 1, wnames);
+req = v9fs_twalk(v9p, 0, 1, 1, wnames, 0);
 v9fs_rlerror(req, );
 
 g_assert_cmpint(err, ==, ENOENT);
@@ -466,10 +466,10 @@ static void fs_walk_dotdot(QVirtIO9P *v9p)
 P9Req *req;
 
 fs_version(v9p);
-req = v9fs_tattach(v9p, 0, getuid());
+req = v9fs_tattach(v9p, 0, getuid(), 0);
 v9fs_rattach(req, _qid);
 
-req = v9fs_twalk(v9p, 0, 1, 1, wnames);
+req = v9fs_twalk(v9p, 0, 1, 1, wnames, 0);
 v9fs_rwalk(req, NULL, ); /* We now we'll get one qid */
 
 g_assert_cmpmem(_qid, 13, wqid[0], 13);
-- 
2.13.6

[Qemu-devel] [PULL 00/10] 9p patches for 2.12 20180130

[Greg Kurz]

The following changes since commit 30d9fefe1aca1e92c785214aa9201fd7c2287d56:

  Merge remote-tracking branch 
'remotes/kraxel/tags/input-20180129-v2-pull-request' into staging (2018-01-29 
15:52:27 +)

are available in the git repository at:

  https://github.com/gkurz/qemu.git tags/for-upstream

for you to fetch changes up to 0dfef72861261bdfd30f2cc53d61c12c097af11a:

  tests/virtio-9p: explicitly handle potential integer overflows (2018-01-30 
15:28:56 +0100)


This series is mostly about 9p request cancellation. It fixes a
long standing bug (read "specification violation") where the server
would send an invalid response when the client has cancelled an
in-flight request. This was causing annoying spurious EINTR returns
in linux. The fix comes with some related testing in QTEST.

Other patches are code cleanup and improvements.


Greg Kurz (9):
  9pfs: drop v9fs_register_transport()
  tests: virtio-9p: move request tag to the test functions
  tests: virtio-9p: wait for completion in the test code
  tests: virtio-9p: use the synth backend
  tests: virtio-9p: add LOPEN operation test
  tests: virtio-9p: add WRITE operation test
  libqos/virtio: return length written into used descriptor
  tests: virtio-9p: add FLUSH operation test
  tests/virtio-9p: explicitly handle potential integer overflows

Keno Fischer (1):
  9pfs: Correctly handle cancelled requests

 hw/9pfs/9p-synth.c |  56 +
 hw/9pfs/9p-synth.h |  11 ++
 hw/9pfs/9p.c   |  25 +++-
 hw/9pfs/9p.h   |  10 +-
 hw/9pfs/trace-events   |   1 +
 hw/9pfs/virtio-9p-device.c |   8 +-
 hw/9pfs/xen-9p-backend.c   |   3 +-
 tests/libqos/virtio.c  |  25 ++--
 tests/libqos/virtio.h  |   3 +-
 tests/virtio-9p-test.c | 293 ++---
 tests/virtio-blk-test.c|  24 ++--
 tests/virtio-net-test.c|   6 +-
 tests/virtio-scsi-test.c   |   3 +-
 13 files changed, 386 insertions(+), 82 deletions(-)
-- 
2.13.6

[Qemu-devel] [PULL 02/10] 9pfs: Correctly handle cancelled requests

[Greg Kurz]

From: Keno Fischer 

# Background

I was investigating spurious non-deterministic EINTR returns from
various 9p file system operations in a Linux guest served from the
qemu 9p server.

 ## EINTR, ERESTARTSYS and the linux kernel

When a signal arrives that the Linux kernel needs to deliver to user-space
while a given thread is blocked (in the 9p case waiting for a reply to its
request in 9p_client_rpc -> wait_event_interruptible), it asks whatever
driver is currently running to abort its current operation (in the 9p case
causing the submission of a TFLUSH message) and return to user space.
In these situations, the error message reported is generally ERESTARTSYS.
If the userspace processes specified SA_RESTART, this means that the
system call will get restarted upon completion of the signal handler
delivery (assuming the signal handler doesn't modify the process state
in complicated ways not relevant here). If SA_RESTART is not specified,
ERESTARTSYS gets translated to EINTR and user space is expected to handle
the restart itself.

 ## The 9p TFLUSH command

The 9p TFLUSH commands requests that the server abort an ongoing operation.
The man page [1] specifies:

```
If it recognizes oldtag as the tag of a pending transaction, it should
abort any pending response and discard that tag.
[...]
When the client sends a Tflush, it must wait to receive the corresponding
Rflush before reusing oldtag for subsequent messages. If a response to the
flushed request is received before the Rflush, the client must honor the
response as if it had not been flushed, since the completed request may
signify a state change in the server
```

In particular, this means that the server must not send a reply with the
orignal tag in response to the cancellation request, because the client is
obligated to interpret such a reply as a coincidental reply to the original
request.

 # The bug

When qemu receives a TFlush request, it sets the `cancelled` flag on the
relevant pdu. This flag is periodically checked, e.g. in
`v9fs_co_name_to_path`, and if set, the operation is aborted and the error
is set to EINTR. However, the server then violates the spec, by returning
to the client an Rerror response, rather than discarding the message
entirely. As a result, the client is required to assume that said Rerror
response is a result of the original request, not a result of the
cancellation and thus passes the EINTR error back to user space.
This is not the worst thing it could do, however as discussed above, the
correct error code would have been ERESTARTSYS, such that user space
programs with SA_RESTART set get correctly restarted upon completion of
the signal handler.
Instead, such programs get spurious EINTR results that they were not
expecting to handle.

It should be noted that there are plenty of user space programs that do not
set SA_RESTART and do not correctly handle EINTR either. However, that is
then a userspace bug. It should also be noted that this bug has been
mitigated by a recent commit to the Linux kernel [2], which essentially
prevents the kernel from sending Tflush requests unless the process is about
to die (in which case the process likely doesn't care about the response).
Nevertheless, for older kernels and to comply with the spec, I believe this
change is beneficial.

 # Implementation

The fix is fairly simple, just skipping notification of a reply if
the pdu was previously cancelled. We do however, also notify the transport
layer that we're doing this, so it can clean up any resources it may be
holding. I also added a new trace event to distinguish
operations that caused an error reply from those that were cancelled.

One complication is that we only omit sending the message on EINTR errors in
order to avoid confusing the rest of the code (which may assume that a
client knows about a fid if it sucessfully passed it off to pud_complete
without checking for cancellation status). This does mean that if the server
acts upon the cancellation flag, it always needs to set err to EINTR. I
believe this is true of the current code.

[1] https://9fans.github.io/plan9port/man/man9/flush.html
[2] https://github.com/torvalds/linux/commit/9523feac272ccad2ad8186ba4fcc891

Signed-off-by: Keno Fischer 
Reviewed-by: Greg Kurz 
[groug, send a zero-sized reply instead of detaching the buffer]
Signed-off-by: Greg Kurz 
Acked-by: Michael S. Tsirkin 
Reviewed-by: Stefano Stabellini 
---
 hw/9pfs/9p.c | 18 ++
 hw/9pfs/trace-events |  1 +
 2 files changed, 19 insertions(+)

diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index 364c7cb44628..e88bb50f1365 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -630,6 +630,24 @@ static void coroutine_fn pdu_complete(V9fsPDU *pdu, 
ssize_t len)
 V9fsState *s = pdu->s;
 int ret;
 
+/*
+ * The 9p spec requires that successfully cancelled pdus receive no 

[Qemu-devel] [PULL 06/10] tests: virtio-9p: add LOPEN operation test

[Greg Kurz]

Trivial test of a successful open.

Signed-off-by: Greg Kurz 
Reviewed-by: Stefan Hajnoczi 
---
 hw/9pfs/9p-synth.c |  5 +
 hw/9pfs/9p-synth.h |  1 +
 tests/virtio-9p-test.c | 47 +++
 3 files changed, 53 insertions(+)

diff --git a/hw/9pfs/9p-synth.c b/hw/9pfs/9p-synth.c
index dcbd320da17a..f17b74f44461 100644
--- a/hw/9pfs/9p-synth.c
+++ b/hw/9pfs/9p-synth.c
@@ -541,6 +541,11 @@ static int synth_init(FsContext *ctx, Error **errp)
 assert(!ret);
 g_free(name);
 }
+
+/* File for LOPEN test */
+ret = qemu_v9fs_synth_add_file(NULL, 0, QTEST_V9FS_SYNTH_LOPEN_FILE,
+   NULL, NULL, ctx);
+assert(!ret);
 }
 
 return 0;
diff --git a/hw/9pfs/9p-synth.h b/hw/9pfs/9p-synth.h
index 876b4ef58288..2a8d6fd00d69 100644
--- a/hw/9pfs/9p-synth.h
+++ b/hw/9pfs/9p-synth.h
@@ -52,5 +52,6 @@ int qemu_v9fs_synth_add_file(V9fsSynthNode *parent, int mode,
 /* qtest stuff */
 
 #define QTEST_V9FS_SYNTH_WALK_FILE "WALK%d"
+#define QTEST_V9FS_SYNTH_LOPEN_FILE "LOPEN"
 
 #endif
diff --git a/tests/virtio-9p-test.c b/tests/virtio-9p-test.c
index 652198156731..6ba782e24f3a 100644
--- a/tests/virtio-9p-test.c
+++ b/tests/virtio-9p-test.c
@@ -238,6 +238,7 @@ static const char *rmessage_name(uint8_t id)
 id == P9_RVERSION ? "RVERSION" :
 id == P9_RATTACH ? "RATTACH" :
 id == P9_RWALK ? "RWALK" :
+id == P9_RLOPEN ? "RLOPEN" :
 "";
 }
 
@@ -389,6 +390,34 @@ static void v9fs_rwalk(P9Req *req, uint16_t *nwqid, 
v9fs_qid **wqid)
 v9fs_req_free(req);
 }
 
+/* size[4] Tlopen tag[2] fid[4] flags[4] */
+static P9Req *v9fs_tlopen(QVirtIO9P *v9p, uint32_t fid, uint32_t flags,
+  uint16_t tag)
+{
+P9Req *req;
+
+req = v9fs_req_init(v9p,  4 + 4, P9_TLOPEN, tag);
+v9fs_uint32_write(req, fid);
+v9fs_uint32_write(req, flags);
+v9fs_req_send(req);
+return req;
+}
+
+/* size[4] Rlopen tag[2] qid[13] iounit[4] */
+static void v9fs_rlopen(P9Req *req, v9fs_qid *qid, uint32_t *iounit)
+{
+v9fs_req_recv(req, P9_RLOPEN);
+if (qid) {
+v9fs_memread(req, qid, 13);
+} else {
+v9fs_memskip(req, 13);
+}
+if (iounit) {
+v9fs_uint32_read(req, iounit);
+}
+v9fs_req_free(req);
+}
+
 static void fs_version(QVirtIO9P *v9p)
 {
 const char *version = "9P2000.L";
@@ -478,6 +507,23 @@ static void fs_walk_dotdot(QVirtIO9P *v9p)
 g_free(wnames[0]);
 }
 
+static void fs_lopen(QVirtIO9P *v9p)
+{
+char *const wnames[] = { g_strdup(QTEST_V9FS_SYNTH_LOPEN_FILE) };
+P9Req *req;
+
+fs_attach(v9p);
+req = v9fs_twalk(v9p, 0, 1, 1, wnames, 0);
+v9fs_req_wait_for_reply(req);
+v9fs_rwalk(req, NULL, NULL);
+
+req = v9fs_tlopen(v9p, 1, O_WRONLY, 0);
+v9fs_req_wait_for_reply(req);
+v9fs_rlopen(req, NULL, NULL);
+
+g_free(wnames[0]);
+}
+
 typedef void (*v9fs_test_fn)(QVirtIO9P *v9p);
 
 static void v9fs_run_pci_test(gconstpointer data)
@@ -507,6 +553,7 @@ int main(int argc, char **argv)
 v9fs_qtest_pci_add("/virtio/9p/pci/fs/walk/no_slash", fs_walk_no_slash);
 v9fs_qtest_pci_add("/virtio/9p/pci/fs/walk/dotdot_from_root",
fs_walk_dotdot);
+v9fs_qtest_pci_add("/virtio/9p/pci/fs/lopen/basic", fs_lopen);
 
 return g_test_run();
 }
-- 
2.13.6

[Qemu-devel] [PULL 05/10] tests: virtio-9p: use the synth backend

[Greg Kurz]

The purpose of virtio-9p-test is to test the virtio-9p device, especially
the 9p server state machine. We don't really care what fsdev backend we're
using. Moreover, if we want to be able to test the flush request or a
device reset with in-flights I/O, it is close to impossible to achieve
with a physical backend because we cannot ask it reliably to put an I/O
on hold at a specific point in time.

Fortunately, we can do that with the synthetic backend, which allows to
register callbacks on read/write accesses to a specific file. This will
be used by a later patch to test the 9P flush request.

The walk request test is converted to using the synth backend.

Signed-off-by: Greg Kurz 
Reviewed-by: Stefan Hajnoczi 
---
 hw/9pfs/9p-synth.c | 16 
 hw/9pfs/9p-synth.h |  4 
 tests/virtio-9p-test.c | 22 ++
 3 files changed, 26 insertions(+), 16 deletions(-)

diff --git a/hw/9pfs/9p-synth.c b/hw/9pfs/9p-synth.c
index 8f255e91c00f..dcbd320da17a 100644
--- a/hw/9pfs/9p-synth.c
+++ b/hw/9pfs/9p-synth.c
@@ -19,6 +19,7 @@
 #include "qemu/rcu.h"
 #include "qemu/rcu_queue.h"
 #include "qemu/cutils.h"
+#include "sysemu/qtest.h"
 
 /* Root node for synth file system */
 static V9fsSynthNode synth_root = {
@@ -527,6 +528,21 @@ static int synth_init(FsContext *ctx, Error **errp)
 
 /* Mark the subsystem is ready for use */
 synth_fs = 1;
+
+if (qtest_enabled()) {
+V9fsSynthNode *node = NULL;
+int i, ret;
+
+/* Directory hierarchy for WALK test */
+for (i = 0; i < P9_MAXWELEM; i++) {
+char *name = g_strdup_printf(QTEST_V9FS_SYNTH_WALK_FILE, i);
+
+ret = qemu_v9fs_synth_mkdir(node, 0700, name, );
+assert(!ret);
+g_free(name);
+}
+}
+
 return 0;
 }
 
diff --git a/hw/9pfs/9p-synth.h b/hw/9pfs/9p-synth.h
index 49c2fc7b274e..876b4ef58288 100644
--- a/hw/9pfs/9p-synth.h
+++ b/hw/9pfs/9p-synth.h
@@ -49,4 +49,8 @@ int qemu_v9fs_synth_add_file(V9fsSynthNode *parent, int mode,
  const char *name, v9fs_synth_read read,
  v9fs_synth_write write, void *arg);
 
+/* qtest stuff */
+
+#define QTEST_V9FS_SYNTH_WALK_FILE "WALK%d"
+
 #endif
diff --git a/tests/virtio-9p-test.c b/tests/virtio-9p-test.c
index cb086315a36e..652198156731 100644
--- a/tests/virtio-9p-test.c
+++ b/tests/virtio-9p-test.c
@@ -17,6 +17,7 @@
 #include "standard-headers/linux/virtio_ids.h"
 #include "standard-headers/linux/virtio_pci.h"
 #include "hw/9pfs/9p.h"
+#include "hw/9pfs/9p-synth.h"
 
 #define QVIRTIO_9P_TIMEOUT_US (10 * 1000 * 1000)
 
@@ -26,23 +27,19 @@ typedef struct {
 QVirtioDevice *dev;
 QOSState *qs;
 QVirtQueue *vq;
-char *test_share;
 } QVirtIO9P;
 
 static QVirtIO9P *qvirtio_9p_start(const char *driver)
 {
 const char *arch = qtest_get_arch();
-const char *cmd = "-fsdev local,id=fsdev0,security_model=none,path=%s "
+const char *cmd = "-fsdev synth,id=fsdev0 "
   "-device %s,fsdev=fsdev0,mount_tag=%s";
 QVirtIO9P *v9p = g_new0(QVirtIO9P, 1);
 
-v9p->test_share = g_strdup("/tmp/qtest.XX");
-g_assert_nonnull(mkdtemp(v9p->test_share));
-
 if (strcmp(arch, "i386") == 0 || strcmp(arch, "x86_64") == 0) {
-v9p->qs = qtest_pc_boot(cmd, v9p->test_share, driver, mount_tag);
+v9p->qs = qtest_pc_boot(cmd, driver, mount_tag);
 } else if (strcmp(arch, "ppc64") == 0) {
-v9p->qs = qtest_spapr_boot(cmd, v9p->test_share, driver, mount_tag);
+v9p->qs = qtest_spapr_boot(cmd, driver, mount_tag);
 } else {
 g_printerr("virtio-9p tests are only available on x86 or ppc64\n");
 exit(EXIT_FAILURE);
@@ -54,8 +51,6 @@ static QVirtIO9P *qvirtio_9p_start(const char *driver)
 static void qvirtio_9p_stop(QVirtIO9P *v9p)
 {
 qtest_shutdown(v9p->qs);
-rmdir(v9p->test_share);
-g_free(v9p->test_share);
 g_free(v9p);
 }
 
@@ -422,17 +417,14 @@ static void fs_attach(QVirtIO9P *v9p)
 
 static void fs_walk(QVirtIO9P *v9p)
 {
-char *wnames[P9_MAXWELEM], *paths[P9_MAXWELEM];
-char *last_path = v9p->test_share;
+char *wnames[P9_MAXWELEM];
 uint16_t nwqid;
 v9fs_qid *wqid;
 int i;
 P9Req *req;
 
 for (i = 0; i < P9_MAXWELEM; i++) {
-wnames[i] = g_strdup_printf("%s%d", __func__, i);
-last_path = paths[i] = g_strdup_printf("%s/%s", last_path, wnames[i]);
-g_assert(!mkdir(paths[i], 0700));
+wnames[i] = g_strdup_printf(QTEST_V9FS_SYNTH_WALK_FILE, i);
 }
 
 fs_attach(v9p);
@@ -443,8 +435,6 @@ static void fs_walk(QVirtIO9P *v9p)
 g_assert_cmpint(nwqid, ==, P9_MAXWELEM);
 
 for (i = 0; i < P9_MAXWELEM; i++) {
-rmdir(paths[P9_MAXWELEM - i - 1]);
-g_free(paths[P9_MAXWELEM - i - 1]);
 g_free(wnames[i]);
 }
 
-- 
2.13.6

Re: [Qemu-devel] [RFC 0/2] Use SDL to create an OpenGL ES context for virglrenderer.

[Elie Tournier]

On Tue, Jan 30, 2018 at 04:22:33PM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > > Well, display configuration is going to be rewritten, and while that is
> > > in flight adding new config options isn't a good idea b/c things will
> > > conflict ...
> > I'm wondering how extensive this rewrite is going to be. Did you plan to 
> > modify the qemu interface?
> > If someone already start working on this task, can you send me the link to 
> > the repository?
> > I will be happy to help if needed.
> 
> https://www.kraxel.org/cgit/qemu/log/?h=sirius/display-cmdline
Awesome, thanks. I will definitely have a look to it.
> 
> > > Beside that:  Is a new config option actually needed in the first place?
> > > 
> > > Ideally qemu (or sdl) would figure on its own that a full core context
> > > isn't available and try fallback to gles then.
> > I'm fine with this idea.
> > However, I think we still need to add a way to the user to choose the 
> > backend he want.
> 
> Changing gl from bool to multiple choice looks more useful to me then,
> i.e. have "gl={on,core,gles,off}", where "on" automatically picks "core"
> or "gles" depending on what is available.
I like that solution. ;). I will implement it on top of your work.
> 
> What is the status of the virglrenderer patches btw?
We keep upstreaming no invasive patches.
But with upstream virglrenderer, you will not be able to use a gles backend.
If you want to know more about the current status of the project, you can have 
a look to our repo [1].

Currently, we are working through bugs, cleaning up the remaing patches.
Our short term goal is to pass the GLES2 CTS [2] in the guest side.

Regards,
Elie

[1] https://gitlab.collabora.com/jakob/virglrenderer-gles/tree/hacks
[2] https://github.com/KhronosGroup/VK-GL-CTS
> 
> cheers,
>   Gerd
> 

Re: [Qemu-devel] [PATCH RFC 1/2] s390x/tcg: wire up pci instructions

[Cornelia Huck]

On Tue, 30 Jan 2018 14:00:12 +0100
David Hildenbrand  wrote:

> On 29.01.2018 17:52, Cornelia Huck wrote:
> > On s390x, pci support is implemented via a set of instructions
> > (no mmio). Unfortunately, none of them are documented in the
> > PoP; the code is based upon the existing implementation for KVM
> > and the Linux zpci driver.
> > 
> > Signed-off-by: Cornelia Huck 
> > ---
> >  target/s390x/helper.h  |   9 
> >  target/s390x/insn-data.def |  13 +
> >  target/s390x/misc_helper.c | 123 
> > +
> >  target/s390x/translate.c   | 123 
> > +
> >  4 files changed, 268 insertions(+)
> > 

(...)

> > diff --git a/target/s390x/misc_helper.c b/target/s390x/misc_helper.c
> > index 86da6aab7e..1271106628 100644
> > --- a/target/s390x/misc_helper.c
> > +++ b/target/s390x/misc_helper.c
> > @@ -36,6 +36,7 @@
> >  #include "hw/s390x/ebcdic.h"
> >  #include "hw/s390x/s390-virtio-hcall.h"
> >  #include "hw/s390x/sclp.h"
> > +#include "hw/s390x/s390-pci-inst.h"
> >  #endif
> >  
> >  /* #define DEBUG_HELPER */
> > @@ -560,3 +561,125 @@ uint32_t HELPER(stfle)(CPUS390XState *env, uint64_t 
> > addr)
> >  env->regs[0] = deposit64(env->regs[0], 0, 8, (max_bytes / 8) - 1);
> >  return count_bytes >= max_bytes ? 0 : 3;
> >  }
> > +
> > +#ifndef CONFIG_USER_ONLY
> > +void HELPER(clp)(CPUS390XState *env, uint32_t r2)
> > +{
> > +S390CPU *cpu = s390_env_get_cpu(env);
> > +int r = -1;
> > +
> > +if (s390_has_feat(S390_FEAT_ZPCI)) {
> > +qemu_mutex_lock_iothread();
> > +r = clp_service_call(cpu, r2, GETPC());
> > +qemu_mutex_unlock_iothread();
> > +}
> > +if (r) {
> > +s390_program_interrupt(env, PGM_OPERATION, 4, GETPC());
> > +}  
> 
> Hmmm, this handling should not be necessary for TCG. All we should need is:
> 
> qemu_mutex_lock_iothread();
> r = clp_service_call(cpu, r2, GETPC());
> qemu_mutex_unlock_iothread();
> 
> We will handle
> 
> a) pci not configured in patch nr2 via the CPU model (will propose
> something there).
> 
> b) we will handle !s390_has_feat(S390_FEAT_ZPCI) although available
> later just as other instructions via the "PCI" flag you attached to the
> instructions (Richard once posted a patch to do that).

Even better if that works. (Although I don't quite understand how the
FAC_xxx defines interact with the facilities.)

> 
> > +}

(...)

> > diff --git a/target/s390x/translate.c b/target/s390x/translate.c
> > index df0b41606d..b73f7143db 100644
> > --- a/target/s390x/translate.c
> > +++ b/target/s390x/translate.c
> > @@ -4777,6 +4777,128 @@ static ExitStatus op_zero2(DisasContext *s, 
> > DisasOps *o)
> >  return NO_EXIT;
> >  }
> >
> 
> > +
> > +static ExitStatus op_stpcifc(DisasContext *s, DisasOps *o)
> > +{
> > +TCGv_i32 r1 = tcg_const_i32(get_field(s->fields, r1));
> > +int b2 = get_field(s->fields, b2);
> > +int d2 = get_field(s->fields, d2);
> > +TCGv_i64 addr;
> > +TCGv_i32 ar;
> > +  
> 
> You can simply drop b2, d2 and addr, and instead use in1_la2 for the
> input value specification:
> 
> 
> C(0xe3d4, STPCIFC, RXY_a, PCI, la2, 0, 0, 0, stpcifc, 0)
> 
> > +check_privileged(s);
> > +addr = get_address(s, 0, b2, d2);
> > +ar = tcg_const_i32(b2);
> > +gen_helper_stpcifc(cpu_env, r1, addr, ar);  
> 
> gen_helper_stpcifc(cpu_env, r1, o->addr1, ar);
> 
> > +tcg_temp_free_i64(addr);
> > +tcg_temp_free_i32(ar);
> > +tcg_temp_free_i32(r1);
> > +set_cc_static(s);
> > +return NO_EXIT;
> > +}
> > +
> > +static ExitStatus op_sic(DisasContext *s, DisasOps *o)
> > +{
> > +int r1 = get_field(s->fields, r1);
> > +int r3 = get_field(s->fields, r3);
> > +  
> 
> (these two can be const)
> you could use in1_r1 and in2_r3
> 
> > +check_privileged(s);
> > +gen_helper_sic(cpu_env, regs[r1], regs[r3]);  
> 
> gen_helper_sic(cpu_env, o->in1, o->in2);
> 
> > +set_cc_static(s);  
> 
> Are you sure this instruction modifies the cc? Can't spot a set_cc when
> following the kvm code.

Ah, you're right. The kernel insn agrees as well.

> 
> > +return NO_EXIT;
> > +}
> > +
> > +static ExitStatus op_rpcit(DisasContext *s, DisasOps *o)
> > +{
> > +TCGv_i32 r1 = tcg_const_i32(get_field(s->fields, r1));
> > +TCGv_i32 r2 = tcg_const_i32(get_field(s->fields, r2));
> > +
> > +check_privileged(s);
> > +gen_helper_rpcit(cpu_env, r1, r2);
> > +tcg_temp_free_i32(r1);
> > +tcg_temp_free_i32(r2);
> > +set_cc_static(s);
> > +return NO_EXIT;
> > +}
> > +
> > +static ExitStatus op_pcistb(DisasContext *s, DisasOps *o)
> > +{
> > +TCGv_i32 r1 = tcg_const_i32(get_field(s->fields, r1));
> > +TCGv_i32 r3 = tcg_const_i32(get_field(s->fields, r3));
> > +int b2 = get_field(s->fields, b2);
> > +int d2 = get_field(s->fields, d2);  
> 
> Dito, use in1_la2
> 
> > +TCGv_i64 addr;
> > +TCGv_i32 ar;
> > +
> > +

Re: [Qemu-devel] [PATCH 09/18] Include qapi/qmp/qobject.h exactly where needed

[Eric Blake]

On 01/30/2018 04:21 AM, Markus Armbruster wrote:
> Signed-off-by: Markus Armbruster 
> ---
Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 08/18] qdict qlist: Make most helper macros functions

[Eric Blake]

On 01/30/2018 04:21 AM, Markus Armbruster wrote:
> The macro expansions of qdict_put_TYPE() and qlist_append_TYPE() need
> qbool.h, qnull.h, qnum.h and qstring.h to compile.  We include qnull.h
> and qnum.h in the headers, but not qbool.h and qstring.h.  Works,
> because we include those wherever the macros get used.
> 
> Open-coding these helpers is of dubious value.  Turn them into
> functions and drop the includes from the headers.
> 
> This cleanup makes the number of objects depending on qapi/qmp/qnum.h
> from 4548 (out of 4739) to 46 in my "build everything" tree.  For
> qapi/qmp/qnull.h, the number drops from 4549 to 21.

Impressive!


> +++ b/qobject/qdict.c
> @@ -14,6 +14,7 @@
>  #include "qapi/qmp/qnum.h"
>  #include "qapi/qmp/qdict.h"
>  #include "qapi/qmp/qbool.h"
> +#include "qapi/qmp/qnull.h"
>  #include "qapi/qmp/qstring.h"
>  #include "qapi/qmp/qobject.h"
>  #include "qapi/error.h"
> @@ -143,6 +144,26 @@ void qdict_put_obj(QDict *qdict, const char *key, 
> QObject *value)
>  }
>  }
>  
> +void qdict_put_int(QDict *qdict, const char *key, int64_t value)
> +{
> +qdict_put(qdict, key, qnum_from_int(value));
> +}

If I'm not mistaken (although I didn't actually test), this triggers a
false positive in scripts/coccinelle/qobject.cocci, no?  Is there a
convenient way to tell coccinelle that a rewrite pattern applies
everywhere except for where the pattern itself is implemented?  But even
if not, we can always use manual inspection when rerunning Coccinelle to
make sure we don't turn these into infinite loops.

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 07/18] Eliminate qapi/qmp/types.h

[Eric Blake]

On 01/30/2018 04:21 AM, Markus Armbruster wrote:
> qapi/qmp/types.h is a convenience header to include a number of
> qapi/qmp/ headers.  Since we rarely need all of the headers
> qapi/qmp/types.h includes, we bypass it most of the time.  Most of the
> places that use it don't need all the headers, either.
> 
> Include the necessary headers directly, and drop qapi/qmp/types.h.
> 
> Signed-off-by: Markus Armbruster 
> ---
>  block/qapi.c|  3 ++-
>  block/qcow2.c   |  3 ++-
>  blockdev.c  |  2 +-
>  hw/pci/pcie_aer.c   |  1 -
>  hw/watchdog/watchdog.c  |  1 -
>  include/qapi/qmp/types.h| 24 

Goodbye!  Glad to be rid of you!

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature