Re: [Qemu-devel] [PATCH] iotests: test clearing unknown autoclear_features by qcow2

[Vladimir Sementsov-Ogievskiy]

10.11.2017 23:02, Kevin Wolf wrote:

Am 10.11.2017 um 18:54 hat Vladimir Sementsov-Ogievskiy geschrieben:

Test clearing unknown autoclear_features by qcow2 on incoming
migration.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---

Hi all!

This patch shows degradation, added in 2.10 in commit

commit 9c5e6594f15b7364624a3ad40306c396c93a2145
Author: Kevin Wolf 
Date:   Thu May 4 18:52:40 2017 +0200

 block: Fix write/resize permissions for inactive images

The problem:
When on incoming migration with shared storage we reopen image to RW mode
we call bdrv_invalidate_cache it firstly call drv->bdrv_invalidate_cache and
only after it, through "parent->role->activate(parent, _err);" we set
appropriate RW permission.

Because of this, if drv->bdrv_invalidate_cache wants to write something
(image is RW and BDRV_O_INACTIVE is not set) it goes into
"bdrv_aligned_pwritev: Assertion `child->perm & BLK_PERM_WRITE' failed"

One case, when qcow2_invalidate_cache wants to write
something - when it wants to clear some unknown autoclear features. So,
here is a test for it.

Another case is when we try to migrate persistent dirty bitmaps through
shared storage, on invalidate_cache qcow2 will try to set DIRTY bit in
all loaded bitmaps.

Kevin, what do you think? I understand that operation order should be changed
somehow in bdrv_invalidate_cache, but I'm not sure about how "parent->role->.."
things works and can we safely move this part from function end to the middle.

I don't think you need to move the parent->role->activate() callback,
but just the bdrv_set_perm() so that we request the correct permissions
for operation without the BDRV_O_INACTIVE flag.

The following seems to work for me (including a fix for the test case,
we don't seem to get a RESUME event).


hmm, it works for me with RESUME..


I'm not sure about the error paths
yet. We should probably try do undo the permission changes there. I can
have a closer look into this next week.

Kevin


diff --git a/block.c b/block.c
index edc5bb9f9b..f530b630b6 100644
--- a/block.c
+++ b/block.c
@@ -4178,7 +4178,17 @@ void bdrv_invalidate_cache(BlockDriverState *bs, Error 
**errp)
  }
  }
  
+/* Update permissions, they may differ for inactive nodes */

  bs->open_flags &= ~BDRV_O_INACTIVE;
+bdrv_get_cumulative_perm(bs, , _perm);
+ret = bdrv_check_perm(bs, NULL, perm, shared_perm, NULL, _err);
+if (ret < 0) {
+bs->open_flags |= BDRV_O_INACTIVE;
+error_propagate(errp, local_err);
+return;
+}
+bdrv_set_perm(bs, perm, shared_perm);
+
  if (bs->drv->bdrv_invalidate_cache) {
  bs->drv->bdrv_invalidate_cache(bs, _err);
  if (local_err) {
@@ -4195,16 +4205,6 @@ void bdrv_invalidate_cache(BlockDriverState *bs, Error 
**errp)
  return;
  }
  
-/* Update permissions, they may differ for inactive nodes */

-bdrv_get_cumulative_perm(bs, , _perm);
-ret = bdrv_check_perm(bs, NULL, perm, shared_perm, NULL, _err);
-if (ret < 0) {
-bs->open_flags |= BDRV_O_INACTIVE;
-error_propagate(errp, local_err);
-return;
-}
-bdrv_set_perm(bs, perm, shared_perm);
-
  QLIST_FOREACH(parent, >parents, next_parent) {
  if (parent->role->activate) {
  parent->role->activate(parent, _err);
diff --git a/tests/qemu-iotests/196 b/tests/qemu-iotests/196
index 9ffbc723c2..4116ebc92b 100755
--- a/tests/qemu-iotests/196
+++ b/tests/qemu-iotests/196
@@ -53,7 +53,10 @@ class TestInvalidateAutoclear(iotests.QMPTestCase):
  f.write(b'\xff')
  
  self.vm_b.launch()

-self.assertNotEqual(self.vm_b.event_wait("RESUME"), None)
+while True:
+result = self.vm_b.qmp('query-status')
+if result['return']['status'] == 'running':
+break
  
  with open(disk, 'rb') as f:

  f.seek(88)



--
Best regards,
Vladimir

Re: [Qemu-devel] [Qemu-block] [PATCH 01/10] qemu-iotests: make execution of tests agnostic to test type

[Paolo Bonzini]

On 16/11/2017 18:38, Cleber Rosa wrote:
> check makes a distinction on how it runs Python based tests.  The
> current approach is inconsistent because:
> 
> 1) a large number of Python tests are already set as executable files
> (eg: 030, 040, 041, 044, 045, 055, 056, 057, 065, 093, 118, 147, 149,
> 155, 165 and 194)
> 
> 2) a smaller number of Python tests are not set as executable files
> 
> 3) the true purpose of a shebang line is to make a file executable,
> while it currently is used (inconsistently) as a test type flag
> 
> 4) the same logic could in theory be applied to shell based tests,
> that is, if first line contains a shell shebang, run it with
> "$SHELL $test_file", but it'd be pointless
> 
> IMO, there's no value in the distinction that check makes.  Dropping
> this distinction makes the interface simpler: check requires an
> executable file.
> 
> Signed-off-by: Cleber Rosa 

This is quirky, but I think it makes sense to obey the configure
script's chosen Python interpreter.  Unlike /bin/sh or /bin/bash, there
can be many Python interpreters on a system and the user may not want
the one in /usr/bin/python (think of old RHEL with software collections,
even though our use of Python is generally portable to older versions).

I'd keep it for now; in the longer term, we should set up a virtual
environment so that the shebang line does the right thing.

However, making files executable is certainly a good idea.

Thanks,

Paolo


> ---
>  tests/qemu-iotests/096   | 0
>  tests/qemu-iotests/124   | 0
>  tests/qemu-iotests/129   | 0
>  tests/qemu-iotests/132   | 0
>  tests/qemu-iotests/136   | 0
>  tests/qemu-iotests/139   | 0
>  tests/qemu-iotests/148   | 0
>  tests/qemu-iotests/152   | 0
>  tests/qemu-iotests/163   | 0
>  tests/qemu-iotests/check | 9 ++---
>  10 files changed, 2 insertions(+), 7 deletions(-)
>  mode change 100644 => 100755 tests/qemu-iotests/096
>  mode change 100644 => 100755 tests/qemu-iotests/124
>  mode change 100644 => 100755 tests/qemu-iotests/129
>  mode change 100644 => 100755 tests/qemu-iotests/132
>  mode change 100644 => 100755 tests/qemu-iotests/136
>  mode change 100644 => 100755 tests/qemu-iotests/139
>  mode change 100644 => 100755 tests/qemu-iotests/148
>  mode change 100644 => 100755 tests/qemu-iotests/152
>  mode change 100644 => 100755 tests/qemu-iotests/163
> 
> diff --git a/tests/qemu-iotests/096 b/tests/qemu-iotests/096
> old mode 100644
> new mode 100755
> diff --git a/tests/qemu-iotests/124 b/tests/qemu-iotests/124
> old mode 100644
> new mode 100755
> diff --git a/tests/qemu-iotests/129 b/tests/qemu-iotests/129
> old mode 100644
> new mode 100755
> diff --git a/tests/qemu-iotests/132 b/tests/qemu-iotests/132
> old mode 100644
> new mode 100755
> diff --git a/tests/qemu-iotests/136 b/tests/qemu-iotests/136
> old mode 100644
> new mode 100755
> diff --git a/tests/qemu-iotests/139 b/tests/qemu-iotests/139
> old mode 100644
> new mode 100755
> diff --git a/tests/qemu-iotests/148 b/tests/qemu-iotests/148
> old mode 100644
> new mode 100755
> diff --git a/tests/qemu-iotests/152 b/tests/qemu-iotests/152
> old mode 100644
> new mode 100755
> diff --git a/tests/qemu-iotests/163 b/tests/qemu-iotests/163
> old mode 100644
> new mode 100755
> diff --git a/tests/qemu-iotests/check b/tests/qemu-iotests/check
> index e6b6ff7a04..08741328d0 100755
> --- a/tests/qemu-iotests/check
> +++ b/tests/qemu-iotests/check
> @@ -741,20 +741,15 @@ do
>  start=`_wallclock`
>  $timestamp && printf %s "[$(date "+%T")]"
>  
> -if [ "$(head -n 1 "$source_iotests/$seq")" == "#!/usr/bin/env 
> python" ]; then
> -run_command="$PYTHON $seq"
> -else
> -run_command="./$seq"
> -fi
>  export OUTPUT_DIR=$PWD
>  if $debug; then
>  (cd "$source_iotests";
>  MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(($RANDOM % 255 + 1))} \
> -$run_command -d 2>&1 | tee $tmp.out)
> +./$seq -d 2>&1 | tee $tmp.out)
>  else
>  (cd "$source_iotests";
>  MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(($RANDOM % 255 + 1))} \
> -$run_command >$tmp.out 2>&1)
> +./$seq >$tmp.out 2>&1)
>  fi
>  sts=$?
>  $timestamp && _timestamp
> 

Re: [Qemu-devel] [PATCH for-2.12 v3 08/11] spapr: introduce a XICSFabric irq_is_lsi() operation

[Cédric Le Goater]

On 11/17/2017 05:54 AM, David Gibson wrote:
> On Fri, Nov 10, 2017 at 03:20:14PM +, Cédric Le Goater wrote:
>> It will be used later on to distinguish the allocation of an LSI
>> interrupt from an MSI and also to reduce the use of the ICSIRQState
>> array of the ICSState object, which is on our way to introduce XIVE.
>>
>> The 'irq' parameter continues to refer to the global IRQ number space.
>>
>> On PowerNV, only the PSI controller interrupts are handled and they
>> are all LSIs.
>>
>> Signed-off-by: Cédric Le Goater 
> 
> !?! AFAICT this is a step backwards.  The users of ics_is_lsi() here
> are in the xics code.  So they already have the right information
> locally in the ICSState object.  Why on earth would you indirect
> through the fabric.

because I am trying to get rid of the fact that the current ICS 
allocator handles two things at the same time : IRQ allocation 
and IRQ type. And that's a problem because the ICSState object 
is just used everywhere in the code. 

OK, So that's is not to your liking, I will come up with some 
other solution. Thanks for looking.

C.   
  
> 
>> ---
>>  hw/intc/xics.c| 26 +-
>>  hw/intc/xics_kvm.c|  4 ++--
>>  hw/ppc/pnv.c  | 16 
>>  hw/ppc/spapr.c|  9 +
>>  include/hw/ppc/xics.h |  2 ++
>>  5 files changed, 46 insertions(+), 11 deletions(-)
>>
>> diff --git a/hw/intc/xics.c b/hw/intc/xics.c
>> index 2c4899f278e2..42880e736697 100644
>> --- a/hw/intc/xics.c
>> +++ b/hw/intc/xics.c
>> @@ -33,6 +33,7 @@
>>  #include "trace.h"
>>  #include "qemu/timer.h"
>>  #include "hw/ppc/xics.h"
>> +#include "hw/ppc/spapr.h"
>>  #include "qemu/error-report.h"
>>  #include "qapi/visitor.h"
>>  #include "monitor/monitor.h"
>> @@ -70,8 +71,7 @@ void ics_pic_print_info(ICSState *ics, Monitor *mon)
>>  }
>>  monitor_printf(mon, "  %4x %s %02x %02x\n",
>> ics->offset + i,
>> -   (irq->flags & XICS_FLAGS_IRQ_LSI) ?
>> -   "LSI" : "MSI",
>> +   ics_is_lsi(ics, i) ? "LSI" : "MSI",
> 
> !?! 
> 
>> irq->priority, irq->status);
>>  }
>>  }
>> @@ -377,6 +377,14 @@ static const TypeInfo icp_info = {
>>  /*
>>   * ICS: Source layer
>>   */
>> +bool ics_is_lsi(ICSState *ics, int srcno)
>> +{
>> +XICSFabric *xi = ics->xics;
>> +XICSFabricClass *xic = XICS_FABRIC_GET_CLASS(xi);
>> +
>> +return xic->irq_is_lsi(xi, srcno + ics->offset);
>> +}
>> +
>>  static void ics_simple_resend_msi(ICSState *ics, int srcno)
>>  {
>>  ICSIRQState *irq = ics->irqs + srcno;
>> @@ -435,7 +443,7 @@ static void ics_simple_set_irq(void *opaque, int srcno, 
>> int val)
>>  {
>>  ICSState *ics = (ICSState *)opaque;
>>  
>> -if (ics->irqs[srcno].flags & XICS_FLAGS_IRQ_LSI) {
>> +if (ics_is_lsi(ics, srcno)) {
>>  ics_simple_set_irq_lsi(ics, srcno, val);
>>  } else {
>>  ics_simple_set_irq_msi(ics, srcno, val);
>> @@ -472,7 +480,7 @@ void ics_simple_write_xive(ICSState *ics, int srcno, int 
>> server,
>>  trace_xics_ics_simple_write_xive(ics->offset + srcno, srcno, server,
>>   priority);
>>  
>> -if (ics->irqs[srcno].flags & XICS_FLAGS_IRQ_LSI) {
>> +if (ics_is_lsi(ics, srcno)) {
>>  ics_simple_write_xive_lsi(ics, srcno);
>>  } else {
>>  ics_simple_write_xive_msi(ics, srcno);
>> @@ -484,10 +492,10 @@ static void ics_simple_reject(ICSState *ics, uint32_t 
>> nr)
>>  ICSIRQState *irq = ics->irqs + nr - ics->offset;
>>  
>>  trace_xics_ics_simple_reject(nr, nr - ics->offset);
>> -if (irq->flags & XICS_FLAGS_IRQ_MSI) {
>> -irq->status |= XICS_STATUS_REJECTED;
>> -} else if (irq->flags & XICS_FLAGS_IRQ_LSI) {
>> +if (ics_is_lsi(ics, nr - ics->offset)) {
>>  irq->status &= ~XICS_STATUS_SENT;
>> +} else {
>> +irq->status |= XICS_STATUS_REJECTED;
>>  }
>>  }
>>  
>> @@ -497,7 +505,7 @@ static void ics_simple_resend(ICSState *ics)
>>  
>>  for (i = 0; i < ics->nr_irqs; i++) {
>>  /* FIXME: filter by server#? */
>> -if (ics->irqs[i].flags & XICS_FLAGS_IRQ_LSI) {
>> +if (ics_is_lsi(ics, i)) {
>>  ics_simple_resend_lsi(ics, i);
>>  } else {
>>  ics_simple_resend_msi(ics, i);
>> @@ -512,7 +520,7 @@ static void ics_simple_eoi(ICSState *ics, uint32_t nr)
>>  
>>  trace_xics_ics_simple_eoi(nr);
>>  
>> -if (ics->irqs[srcno].flags & XICS_FLAGS_IRQ_LSI) {
>> +if (ics_is_lsi(ics, srcno)) {
>>  irq->status &= ~XICS_STATUS_SENT;
>>  }
>>  }
>> diff --git a/hw/intc/xics_kvm.c b/hw/intc/xics_kvm.c
>> index 3091ad3ac2c8..2f10637c9f7c 100644
>> --- a/hw/intc/xics_kvm.c
>> +++ b/hw/intc/xics_kvm.c
>> @@ -258,7 +258,7 @@ static int ics_set_kvm_state(ICSState *ics, int 
>> version_id)
>>  state |= KVM_XICS_MASKED;
>>  }
>>  
>> -if (ics->irqs[i].flags & 

Re: [Qemu-devel] [Qemu-block] [PATCH 06/10] qemu-iotests: turn owner variable into a comment

[Paolo Bonzini]

On 16/11/2017 18:38, Cleber Rosa wrote:
> This variables has no real use.  To avoid pretending it does, while
> still keeping the information, let's turn it into a comment.
> 
> The format chosen is the one already being used on tests 149 and 194.

I would just delete it...

Paolo

> Signed-off-by: Cleber Rosa 
> ---
>  tests/qemu-iotests/001 | 5 ++---
>  tests/qemu-iotests/002 | 5 ++---
>  tests/qemu-iotests/003 | 5 ++---
>  tests/qemu-iotests/004 | 5 ++---
>  tests/qemu-iotests/005 | 5 ++---
>  tests/qemu-iotests/007 | 5 ++---
>  tests/qemu-iotests/008 | 5 ++---
>  tests/qemu-iotests/009 | 5 ++---
>  tests/qemu-iotests/010 | 5 ++---
>  tests/qemu-iotests/011 | 5 ++---
>  tests/qemu-iotests/012 | 5 ++---
>  tests/qemu-iotests/013 | 5 ++---
>  tests/qemu-iotests/014 | 5 ++---
>  tests/qemu-iotests/015 | 5 ++---
>  tests/qemu-iotests/017 | 5 ++---
>  tests/qemu-iotests/018 | 5 ++---
>  tests/qemu-iotests/019 | 5 ++---
>  tests/qemu-iotests/020 | 5 ++---
>  tests/qemu-iotests/021 | 5 ++---
>  tests/qemu-iotests/022 | 5 ++---
>  tests/qemu-iotests/023 | 5 ++---
>  tests/qemu-iotests/024 | 5 ++---
>  tests/qemu-iotests/025 | 5 ++---
>  tests/qemu-iotests/026 | 5 ++---
>  tests/qemu-iotests/027 | 5 ++---
>  tests/qemu-iotests/028 | 5 ++---
>  tests/qemu-iotests/029 | 5 ++---
>  tests/qemu-iotests/031 | 5 ++---
>  tests/qemu-iotests/032 | 5 ++---
>  tests/qemu-iotests/033 | 5 ++---
>  tests/qemu-iotests/034 | 5 ++---
>  tests/qemu-iotests/035 | 5 ++---
>  tests/qemu-iotests/036 | 5 ++---
>  tests/qemu-iotests/037 | 5 ++---
>  tests/qemu-iotests/038 | 5 ++---
>  tests/qemu-iotests/039 | 5 ++---
>  tests/qemu-iotests/040 | 1 +
>  tests/qemu-iotests/042 | 5 ++---
>  tests/qemu-iotests/043 | 5 ++---
>  tests/qemu-iotests/046 | 5 ++---
>  tests/qemu-iotests/047 | 5 ++---
>  tests/qemu-iotests/048 | 4 ++--
>  tests/qemu-iotests/049 | 5 ++---
>  tests/qemu-iotests/050 | 5 ++---
>  tests/qemu-iotests/051 | 5 ++---
>  tests/qemu-iotests/052 | 5 ++---
>  tests/qemu-iotests/053 | 5 ++---
>  tests/qemu-iotests/054 | 5 ++---
>  tests/qemu-iotests/058 | 5 ++---
>  tests/qemu-iotests/059 | 5 ++---
>  tests/qemu-iotests/060 | 5 ++---
>  tests/qemu-iotests/061 | 5 ++---
>  tests/qemu-iotests/062 | 5 ++---
>  tests/qemu-iotests/063 | 5 ++---
>  tests/qemu-iotests/064 | 5 ++---
>  tests/qemu-iotests/066 | 5 ++---
>  tests/qemu-iotests/067 | 5 ++---
>  tests/qemu-iotests/068 | 5 ++---
>  tests/qemu-iotests/069 | 5 ++---
>  tests/qemu-iotests/070 | 5 ++---
>  tests/qemu-iotests/071 | 5 ++---
>  tests/qemu-iotests/072 | 5 ++---
>  tests/qemu-iotests/073 | 5 ++---
>  tests/qemu-iotests/074 | 3 +--
>  tests/qemu-iotests/075 | 5 ++---
>  tests/qemu-iotests/076 | 5 ++---
>  tests/qemu-iotests/077 | 5 ++---
>  tests/qemu-iotests/078 | 5 ++---
>  tests/qemu-iotests/079 | 5 ++---
>  tests/qemu-iotests/080 | 5 ++---
>  tests/qemu-iotests/081 | 5 ++---
>  tests/qemu-iotests/082 | 5 ++---
>  tests/qemu-iotests/083 | 5 ++---
>  tests/qemu-iotests/084 | 5 ++---
>  tests/qemu-iotests/085 | 5 ++---
>  tests/qemu-iotests/086 | 5 ++---
>  tests/qemu-iotests/087 | 5 ++---
>  tests/qemu-iotests/088 | 5 ++---
>  tests/qemu-iotests/089 | 5 ++---
>  tests/qemu-iotests/090 | 5 ++---
>  tests/qemu-iotests/091 | 5 ++---
>  tests/qemu-iotests/092 | 5 ++---
>  tests/qemu-iotests/094 | 5 ++---
>  tests/qemu-iotests/095 | 4 ++--
>  tests/qemu-iotests/097 | 5 ++---
>  tests/qemu-iotests/098 | 5 ++---
>  tests/qemu-iotests/099 | 5 ++---
>  tests/qemu-iotests/101 | 5 ++---
>  tests/qemu-iotests/102 | 5 ++---
>  tests/qemu-iotests/103 | 5 ++---
>  tests/qemu-iotests/104 | 5 ++---
>  tests/qemu-iotests/105 | 5 ++---
>  tests/qemu-iotests/106 | 5 ++---
>  tests/qemu-iotests/107 | 5 ++---
>  tests/qemu-iotests/108 | 5 ++---
>  tests/qemu-iotests/109 | 5 ++---
>  tests/qemu-iotests/110 | 5 ++---
>  tests/qemu-iotests/111 | 5 ++---
>  tests/qemu-iotests/112 | 5 ++---
>  tests/qemu-iotests/113 | 5 ++---
>  tests/qemu-iotests/114 | 5 ++---
>  tests/qemu-iotests/115 | 5 ++---
>  tests/qemu-iotests/116 | 5 ++---
>  tests/qemu-iotests/117 | 5 ++---
>  tests/qemu-iotests/119 | 5 ++---
>  tests/qemu-iotests/120 | 5 ++---
>  tests/qemu-iotests/121 | 5 ++---
>  tests/qemu-iotests/122 | 5 ++---
>  tests/qemu-iotests/123 | 5 ++---
>  tests/qemu-iotests/125 | 5 ++---
>  tests/qemu-iotests/126 | 5 ++---
>  tests/qemu-iotests/127 | 5 ++---
>  tests/qemu-iotests/128 | 5 ++---
>  tests/qemu-iotests/130 | 5 ++---
>  tests/qemu-iotests/131 | 5 ++---
>  tests/qemu-iotests/133 | 5 ++---
>  tests/qemu-iotests/134 | 5 ++---
>  tests/qemu-iotests/135 | 5 ++---
>  tests/qemu-iotests/137 | 5 ++---
>  tests/qemu-iotests/138 | 5 ++---
>  tests/qemu-iotests/140 | 5 ++---
>  tests/qemu-iotests/141 | 5 ++---
>  tests/qemu-iotests/142 | 5 ++---
>  tests/qemu-iotests/143 | 5 ++---
>  tests/qemu-iotests/144 | 5 ++---
>  tests/qemu-iotests/145 | 5 ++---
>  tests/qemu-iotests/146 | 5 ++---
>  tests/qemu-iotests/150 | 5 ++---
>  tests/qemu-iotests/153 | 5 ++---
>  tests/qemu-iotests/154 

Re: [Qemu-devel] [PATCH for-2.11] hw/net/eepro100: Fix endianness problem on big endian hosts

[Thomas Huth]

On 17.11.2017 06:35, Stefan Weil wrote:
> Am 17.11.2017 um 05:14 schrieb Michael S. Tsirkin:
>> On Thu, Nov 16, 2017 at 10:16:54PM +0100, Thomas Huth wrote:
>>> Since commit 1865e288a823c764cd4344d ("Fix eepro100 simple transmission
>>> mode"), the test/pxe-test is broken for the eepro100 device on big
>>> endian hosts. However, it seems like that commit did not introduce the
>>> problem, but just uncovered it: The EEPRO100State->tx.tbd_array_addr and
>>> EEPRO100State->tx.tcb_bytes fields are already in host byte order, since
>>> they have already been byte-swapped in the read_cb() function.
>>> Thus byte-swapping them in tx_command() again results in the wrong
>>> endianness. Removing the byte-swapping here fixes the pxe-test.
>>>
>>> Signed-off-by: Thomas Huth 
>>
>> Reviewed-by: Michael S. Tsirkin 
>>
>> Thomas, how about adding sparse endian-ness annotations
>> a la le32 in Linux? We could then use static checkers to
>> catch these bugs at build time.

Sounds like a good idea - but also like a bigger project. I don't have
time for that right now, so if somebody wants to have a look, you're
very welcome! (but I'll also put it on my way-too-big todo-list.txt, so
in case nobody else picks this up, maybe I can have a look at it in a
couple of months...)

> My main problem is that running big endian tests are
> much more complex and time consuming simply because
> my only big endian machines are QEMU virtual machines
> (PPC* or MIPS*), so a test requires running QEMU
> inside QEMU.
> 
> Nevertheless I had run such tests with network boot
> and Linux guests as test cases, and they worked
> (see comments in the header of eepro100.c).
> 
> So I wonder how the tests have to be enhanced to cover
> more cases.

I think this specific problem was "hidden" by the code that has been
removed with commit 1865e288a823c7, so there was no chance that you
could detect this with tests. As I wrote in the description, the
pxe-test worked fine in rc0, it just got broken in rc1.

But if you want to increase automatic test coverage, I think you should
try to improve tests/eepro100-test.c with some more code, e.g. something
similar as it is done in tests/e1000e-test.c.

 Thomas

Re: [Qemu-devel] [PATCH for-2.12 v3 05/11] spapr: introduce an IRQ allocator using a bitmap

[Cédric Le Goater]

On 11/17/2017 05:50 AM, David Gibson wrote:
> On Tue, Nov 14, 2017 at 10:42:24AM +0100, Greg Kurz wrote:
>> On Fri, 10 Nov 2017 15:20:11 +
>> Cédric Le Goater  wrote:
>>
>>> Let's define a new set of XICSFabric IRQ operations for the latest
>>> pseries machine. These simply use a a bitmap 'irq_map' as a IRQ number
>>> allocator.
>>>
>>> The previous pseries machines keep the old set of IRQ operations using
>>> the ICSIRQState array.
>>>
>>> Signed-off-by: Cédric Le Goater 
>>> ---
>>>
>>>  Changes since v2 :
>>>
>>>  - introduced a second set of XICSFabric IRQ operations for older
>>>pseries machines
>>>
>>>  hw/ppc/spapr.c | 76 
>>> ++
>>>  include/hw/ppc/spapr.h |  3 ++
>>>  2 files changed, 74 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
>>> index 4bdceb45a14f..4ef0b73559ca 100644
>>> --- a/hw/ppc/spapr.c
>>> +++ b/hw/ppc/spapr.c
>>> @@ -1681,6 +1681,22 @@ static const VMStateDescription 
>>> vmstate_spapr_patb_entry = {
>>>  },
>>>  };
>>>  
>>> +static bool spapr_irq_map_needed(void *opaque)
>>> +{
>>> +return true;
>>
>> I see that the next patch adds some code to avoid sending the
>> bitmap if it doesn't contain state, but I guess you should also
>> explicitly have this function to return false for older machine
>> types (see remark below).
> 
> I don't see that you should need to migrate this at all.  The machine
> needs to reliably allocate the same interrupts each time, and that
> means source and dest should have the same allocations without
> migrating data.

ok. so we need to make sure that hot plugging devices or CPUs does
not break that scheme. This is not the case today if you don't follow
the exact same order on the monitor.

C.

>>
>>> +}
>>> +
>>> +static const VMStateDescription vmstate_spapr_irq_map = {
>>> +.name = "spapr_irq_map",
>>> +.version_id = 0,
>>> +.minimum_version_id = 0,
>>> +.needed = spapr_irq_map_needed,
>>> +.fields = (VMStateField[]) {
>>> +VMSTATE_BITMAP(irq_map, sPAPRMachineState, 0, nr_irqs),
>>> +VMSTATE_END_OF_LIST()
>>> +},
>>> +};
>>> +
>>>  static const VMStateDescription vmstate_spapr = {
>>>  .name = "spapr",
>>>  .version_id = 3,
>>> @@ -1700,6 +1716,7 @@ static const VMStateDescription vmstate_spapr = {
>>>  _spapr_ov5_cas,
>>>  _spapr_patb_entry,
>>>  _spapr_pending_events,
>>> +_spapr_irq_map,
>>>  NULL
>>>  }
>>>  };
>>> @@ -2337,8 +2354,12 @@ static void ppc_spapr_init(MachineState *machine)
>>>  /* Setup a load limit for the ramdisk leaving room for SLOF and FDT */
>>>  load_limit = MIN(spapr->rma_size, RTAS_MAX_ADDR) - FW_OVERHEAD;
>>>  
>>> +/* Initialize the IRQ allocator */
>>> +spapr->nr_irqs  = XICS_IRQS_SPAPR;
>>> +spapr->irq_map  = bitmap_new(spapr->nr_irqs);
>>> +
>>
>> I think you should introduce a sPAPRMachineClass::has_irq_bitmap boolean
>> so that the bitmap is only allocated for newer machine types. And you should
>> then use this flag in spapr_irq_map_needed() above.
>>
>> Apart from that, the rest of the patch looks good.
>>
>>>  /* Set up Interrupt Controller before we create the VCPUs */
>>> -xics_system_init(machine, XICS_IRQS_SPAPR, _fatal);
>>> +xics_system_init(machine, spapr->nr_irqs, _fatal);
>>>  
>>>  /* Set up containers for ibm,client-architecture-support negotiated 
>>> options
>>>   */
>>> @@ -3560,7 +3581,7 @@ static int ics_find_free_block(ICSState *ics, int 
>>> num, int alignnum)
>>>  return -1;
>>>  }
>>>  
>>> -static bool spapr_irq_test(XICSFabric *xi, int irq)
>>> +static bool spapr_irq_test_2_11(XICSFabric *xi, int irq)
>>>  {
>>>  sPAPRMachineState *spapr = SPAPR_MACHINE(xi);
>>>  ICSState *ics = spapr->ics;
>>> @@ -3569,7 +3590,7 @@ static bool spapr_irq_test(XICSFabric *xi, int irq)
>>>  return !ICS_IRQ_FREE(ics, srcno);
>>>  }
>>>  
>>> -static int spapr_irq_alloc_block(XICSFabric *xi, int count, int align)
>>> +static int spapr_irq_alloc_block_2_11(XICSFabric *xi, int count, int align)
>>>  {
>>>  sPAPRMachineState *spapr = SPAPR_MACHINE(xi);
>>>  ICSState *ics = spapr->ics;
>>> @@ -3583,7 +3604,7 @@ static int spapr_irq_alloc_block(XICSFabric *xi, int 
>>> count, int align)
>>>  return srcno + ics->offset;
>>>  }
>>>  
>>> -static void spapr_irq_free_block(XICSFabric *xi, int irq, int num)
>>> +static void spapr_irq_free_block_2_11(XICSFabric *xi, int irq, int num)
>>>  {
>>>  sPAPRMachineState *spapr = SPAPR_MACHINE(xi);
>>>  ICSState *ics = spapr->ics;
>>> @@ -3601,6 +3622,46 @@ static void spapr_irq_free_block(XICSFabric *xi, int 
>>> irq, int num)
>>>  }
>>>  }
>>>  
>>> +static bool spapr_irq_test(XICSFabric *xi, int irq)
>>> +{
>>> +sPAPRMachineState *spapr = SPAPR_MACHINE(xi);
>>> +int srcno = irq - spapr->ics->offset;
>>> +
>>> +return test_bit(srcno, spapr->irq_map);
>>> +}
>>> 

Re: [Qemu-devel] [PATCH for-2.12 v3 03/11] spapr: introduce new XICSFabric operations for an IRQ allocator

[Cédric Le Goater]

On 11/17/2017 05:48 AM, David Gibson wrote:
> On Fri, Nov 10, 2017 at 03:20:09PM +, Cédric Le Goater wrote:
>> Currently, the ICSState 'ics' object of the sPAPR machine acts as the
>> global interrupt source handler and also as the IRQ number allocator
>> for the machine. Some IRQ numbers are allocated very early in the
>> machine initialization sequence to populate the device tree, and this
>> is a problem to introduce the new POWER XIVE interrupt model, as it
>> needs to share the IRQ numbers with the older model.
>>
>> To prepare ground for XIVE, here is a set of new XICSFabric operations
>> to let the machine handle directly the IRQ number allocation and to
>> decorrelate the allocation from the interrupt source object :
>>
>> bool (*irq_test)(XICSFabric *xi, int irq);
>> int (*irq_alloc_block)(XICSFabric *xi, int count, int align);
>> void (*irq_free_block)(XICSFabric *xi, int irq, int num);
>>
>> In these prototypes, the 'irq' parameter refers to a number in the
>> global IRQ number space. Indexes for arrays storing different state
>> informations on the interrupts, like the ICSIRQState, are usually
>> named 'srcno'.
>>
>> Signed-off-by: Cédric Le Goater 
> 
> This doesn't seem sensible to me.  When I said you should move irq
> allocation to the machine, I mean actually move the code.  The only
> user of irq allocation should be in the machine, so we shouldn't need
> to indirect via the XICSFabric interface to do that.

OK. so we can probably do the same with machine class handlers because 
we do need an indirection to handle the way older pseries machines 
allocate IRQs that will change with newer machines  supporting XIVE.

> And, we shouldn't be using XICSFabric things for XIVE.

ok. The spapr machine should be enough. 

Thanks,

C.
 
>> ---
>>  hw/ppc/spapr.c| 19 +++
>>  include/hw/ppc/xics.h |  4 
>>  2 files changed, 23 insertions(+)
>>
>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
>> index a2dcbee07214..84d68f2fdbae 100644
>> --- a/hw/ppc/spapr.c
>> +++ b/hw/ppc/spapr.c
>> @@ -3536,6 +3536,21 @@ static ICPState *spapr_icp_get(XICSFabric *xi, int 
>> vcpu_id)
>>  return cpu ? ICP(cpu->intc) : NULL;
>>  }
>>  
>> +static bool spapr_irq_test(XICSFabric *xi, int irq)
>> +{
>> +return false;
>> +}
>> +
>> +static int spapr_irq_alloc_block(XICSFabric *xi, int count, int align)
>> +{
>> +return -1;
>> +}
>> +
>> +static void spapr_irq_free_block(XICSFabric *xi, int irq, int num)
>> +{
>> +;
>> +}
>> +
>>  static void spapr_pic_print_info(InterruptStatsProvider *obj,
>>   Monitor *mon)
>>  {
>> @@ -3630,6 +3645,10 @@ static void spapr_machine_class_init(ObjectClass *oc, 
>> void *data)
>>  xic->ics_get = spapr_ics_get;
>>  xic->ics_resend = spapr_ics_resend;
>>  xic->icp_get = spapr_icp_get;
>> +xic->irq_test = spapr_irq_test;
>> +xic->irq_alloc_block = spapr_irq_alloc_block;
>> +xic->irq_free_block = spapr_irq_free_block;
>> +
>>  ispc->print_info = spapr_pic_print_info;
>>  /* Force NUMA node memory size to be a multiple of
>>   * SPAPR_MEMORY_BLOCK_SIZE (256M) since that's the granularity
>> diff --git a/include/hw/ppc/xics.h b/include/hw/ppc/xics.h
>> index 28d248abad61..30e7f2e0a7dd 100644
>> --- a/include/hw/ppc/xics.h
>> +++ b/include/hw/ppc/xics.h
>> @@ -175,6 +175,10 @@ typedef struct XICSFabricClass {
>>  ICSState *(*ics_get)(XICSFabric *xi, int irq);
>>  void (*ics_resend)(XICSFabric *xi);
>>  ICPState *(*icp_get)(XICSFabric *xi, int server);
>> +/* IRQ allocator helpers */
>> +bool (*irq_test)(XICSFabric *xi, int irq);
>> +int (*irq_alloc_block)(XICSFabric *xi, int count, int align);
>> +void (*irq_free_block)(XICSFabric *xi, int irq, int num);
>>  } XICSFabricClass;
>>  
>>  #define XICS_IRQS_SPAPR   1024
> 

Re: [Qemu-devel] [PATCH v3 0/3] Qemu: add Xen vIOMMU interrupt remapping function support

[no-reply]

Hi,

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

Subject: [Qemu-devel] [PATCH v3 0/3] Qemu: add Xen vIOMMU interrupt remapping 
function support
Type: series
Message-id: 1510899865-40323-1-git-send-email-chao@intel.com

=== 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-quick@centos6
time make docker-test-build@min-glib
time make docker-test-mingw@fedora
time make docker-test-block@fedora
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
16118fc296 msi: Handle remappable format interrupt request
196d7fb6ea xen/pt: Pass the whole msi addr/data to Xen
149eba7c46 i386/msi: Correct mask of destination ID in MSI address

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into '/var/tmp/patchew-tester-tmp-6kl3_kge/src/dtc'...
Submodule path 'dtc': checked out '558cd81bdd432769b59bff01240c44f82cfb1a9d'
  BUILD   centos6
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-6kl3_kge/src'
  GEN 
/var/tmp/patchew-tester-tmp-6kl3_kge/src/docker-src.2017-11-17-01.56.18.16837/qemu.tar
Cloning into 
'/var/tmp/patchew-tester-tmp-6kl3_kge/src/docker-src.2017-11-17-01.56.18.16837/qemu.tar.vroot'...
done.
Checking out files:  44% (2526/5654)   
Checking out files:  45% (2545/5654)   
Checking out files:  46% (2601/5654)   
Checking out files:  47% (2658/5654)   
Checking out files:  48% (2714/5654)   
Checking out files:  49% (2771/5654)   
Checking out files:  50% (2827/5654)   
Checking out files:  51% (2884/5654)   
Checking out files:  52% (2941/5654)   
Checking out files:  53% (2997/5654)   
Checking out files:  54% (3054/5654)   
Checking out files:  55% (3110/5654)   
Checking out files:  56% (3167/5654)   
Checking out files:  57% (3223/5654)   
Checking out files:  58% (3280/5654)   
Checking out files:  59% (3336/5654)   
Checking out files:  60% (3393/5654)   
Checking out files:  61% (3449/5654)   
Checking out files:  62% (3506/5654)   
Checking out files:  63% (3563/5654)   
Checking out files:  64% (3619/5654)   
Checking out files:  65% (3676/5654)   
Checking out files:  66% (3732/5654)   
Checking out files:  67% (3789/5654)   
Checking out files:  68% (3845/5654)   
Checking out files:  69% (3902/5654)   
Checking out files:  70% (3958/5654)   
Checking out files:  71% (4015/5654)   
Checking out files:  72% (4071/5654)   
Checking out files:  73% (4128/5654)   
Checking out files:  74% (4184/5654)   
Checking out files:  75% (4241/5654)   
Checking out files:  76% (4298/5654)   
Checking out files:  77% (4354/5654)   
Checking out files:  78% (4411/5654)   
Checking out files:  79% (4467/5654)   
Checking out files:  80% (4524/5654)   
Checking out files:  81% (4580/5654)   
Checking out files:  82% (4637/5654)   
Checking out files:  83% (4693/5654)   
Checking out files:  84% (4750/5654)   
Checking out files:  85% (4806/5654)   
Checking out files:  86% (4863/5654)   
Checking out files:  87% (4919/5654)   
Checking out files:  88% (4976/5654)   
Checking out files:  89% (5033/5654)   
Checking out files:  90% (5089/5654)   
Checking out files:  91% (5146/5654)   
Checking out files:  92% (5202/5654)   
Checking out files:  93% (5259/5654)   
Checking out files:  94% (5315/5654)   
Checking out files:  95% (5372/5654)   
Checking out files:  96% (5428/5654)   
Checking out files:  97% (5485/5654)   
Checking out files:  98% (5541/5654)   
Checking out files:  99% (5598/5654)   
Checking out files: 100% (5654/5654)   
Checking out files: 100% (5654/5654), 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-6kl3_kge/src/docker-src.2017-11-17-01.56.18.16837/qemu.tar.vroot/dtc'...
Submodule path 'dtc': checked out '558cd81bdd432769b59bff01240c44f82cfb1a9d'
Submodule 'ui/keycodemapdb' (git://git.qemu.org/keycodemapdb.git) registered 
for path 'ui/keycodemapdb'
Cloning into 
'/var/tmp/patchew-tester-tmp-6kl3_kge/src/docker-src.2017-11-17-01.56.18.16837/qemu.tar.vroot/ui/keycodemapdb'...
Submodule path 'ui/keycodemapdb': checked out 
'10739aa26051a5d49d88132604539d3ed085e72e'
  COPYRUNNER
RUN test-quick in qemu:centos6 
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
bison-2.4.1-5.el6.x86_64
bzip2-devel-1.0.5-7.el6_0.x86_64
ccache-3.1.6-2.el6.x86_64
csnappy-devel-0-6.20150729gitd7bc683.el6.x86_64
flex-2.5.35-9.el6.x86_64
gcc-4.4.7-18.el6.x86_64
gettext-0.17-18.el6.x86_64
git-1.7.1-9.el6_9.x86_64
glib2-devel-2.28.8-9.el6.x86_64
libepoxy-devel-1.2-3.el6.x86_64
libfdt-devel-1.4.0-1.el6.x86_64
librdmacm-devel-1.0.21-0.el6.x86_64
lzo-devel-2.03-3.1.el6_5.1.x86_64
make-3.81-23.el6.x86_64

Re: [Qemu-devel] [Question] why need to start all queues in vhost_net_start

[Jason Wang]

On 2017年11月17日 12:32, Michael S. Tsirkin wrote:

On Thu, Nov 16, 2017 at 08:04:34PM +0800, Jason Wang wrote:


On 2017年11月16日 17:32, Longpeng (Mike) wrote:

Hi Jason,

On 2017/11/16 17:13, Jason Wang wrote:


On 2017年11月16日 17:01, Gonglei (Arei) wrote:

No, Windows guest + vhost-user/DPDK.

BTW pls see virtio spec in :

"If VIRTIO_NET_F_MQ is negotiated, each of receiveq1. . .receiveqN that will
be used SHOULD be populated
with receive buffers."

It is not mandatory that all queues must be initialized.

I think not, since it said we should fill receive buffers for each queue which
means we should initialize all queues. May Michael can clarify on this.


I think this doesn't matter, but QEMU should consider this scenario...

For example, if one queues isn't initialized (Windows guest), the vring.avail=0,
so vq->desc_phys=0, then vq->desc='a avail HVA'(which is the start addr of 
pc.ram).

  vq->desc_size = s = l = virtio_queue_get_desc_size(vdev, idx);
  vq->desc_phys = a = virtio_queue_get_desc_addr(vdev, idx);
  vq->desc = vhost_memory_map(dev, a, , 0);
  if (!vq->desc || l != s) {
  r = -ENOMEM;
  goto fail_alloc_desc;
  }
  .
  r = vhost_virtqueue_set_addr(dev, vq, vhost_vq_index, dev->log_enabled);
  if (r < 0) {
  r = -errno;
  goto fail_alloc;
  }

Then the HVA is send to the vhost-user.

I think this is wrong, because the '0' here means guest driver doesn't init this
queues, it should not be used to calculate the HVA for this vq.

Yes, workaround is not hard if windows driver won't use the left 3 queues
any more. But we should have a complete solution. The main problem is when
vhost need to be started. For legacy device, there's no easy way to detect
whether or not a specific virtqueue is ready to be used. For modern device,
we can probably do this through queue_enable (but this is not implemented in
current code).

Thanks

What isn't implemented?


I mean queue_enable. Virtio spec said:

queue_enable
   The driver uses this to selectively prevent the device from
   executing requests from this virtqueue. 1 - enabled; 0 - disabled. 



But we have:

    case VIRTIO_PCI_COMMON_Q_ENABLE:
    virtio_queue_set_num(vdev, vdev->queue_sel,
 proxy->vqs[vdev->queue_sel].num);
    virtio_queue_set_rings(vdev, vdev->queue_sel,
((uint64_t)proxy->vqs[vdev->queue_sel].desc[1]) << 32 |
   proxy->vqs[vdev->queue_sel].desc[0],
((uint64_t)proxy->vqs[vdev->queue_sel].avail[1]) << 32 |
   proxy->vqs[vdev->queue_sel].avail[0],
((uint64_t)proxy->vqs[vdev->queue_sel].used[1]) << 32 |
   proxy->vqs[vdev->queue_sel].used[0]);
    proxy->vqs[vdev->queue_sel].enabled = 1;
    break;

So it looks to me that we need:

- Not assume the value is 1
- Start or stop vhost virtqueue depends on value

Thanks



Spec is quite explicit:


Client must only process each ring when it is started.

Client must only pass data between the ring and the
backend, when the ring is enabled.

and later:


Client must start ring upon receiving a kick (that is, detecting that file
descriptor is readable) on the descriptor specified by
VHOST_USER_SET_VRING_KICK, and stop ring upon receiving
VHOST_USER_GET_VRING_BASE.


Does someone kick unused rings? What entity does this?





Thanks


Thanks,
-Gonglei




.

Re: [Qemu-devel] [QEMU-PPC] [PATCH V3] target/ppc: Update setting of cpu features to account for compat modes

[David Gibson]

On Fri, Nov 17, 2017 at 04:39:00PM +1100, Suraj Jitindar Singh wrote:
> The device tree nodes ibm,arch-vec-5-platform-support and ibm,pa-features
> are used to communicate features of the cpu to the guest operating
> system. The properties of each of these are determined based on the
> selected cpu model and the availability of hypervisor features.
> Currently the compatibility mode of the cpu is not taken into account.
> 
> The ibm,arch-vec-5-platform-support node is used to communicate the
> level of support for various ISAv3 processor features to the guest
> before CAS to inform the guests' request. The available mmu mode should
> only be hash unless the cpu is a POWER9 which is not in a prePOWER9
> compat mode, in which case the available modes depend on the
> accelerator and the hypervisor capabilities.
> 
> The ibm,pa-featues node is used to communicate the level of cpu support
> for various features to the guest os. This should only contain features
> relevant to the operating mode of the processor, that is the selected
> cpu model taking into account any compat mode. This means that the
> compat mode should be taken into account when choosing the properties of
> ibm,pa-features and they should match the compat mode selected, or the
> cpu model selected if no compat mode.
> 
> Update the setting of these cpu features in the device tree as described
> above to properly take into account any compat mode. We use the
> ppc_check_compat function which takes into account the current processor
> model and the cpu compat mode.
> 
> Signed-off-by: Suraj Jitindar Singh 

Applied to ppc-for-2.11.

> 
> ---
> 
> V1 -> V2:
> - Pass cpu pointer to spapr_populate_pa_features to avoid extracting it
>   back out from env
> - Slight reword of spapr_dt_ov5_platform_support logic to avoid
>   duplicate case
> V2 -> V3:
> - Use ppc_check_compat() to avoid having to check both the cpu model
>   and the compat mode separately since it does it for us
> ---
>  hw/ppc/spapr.c | 43 +--
>  1 file changed, 21 insertions(+), 22 deletions(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index d682f01..6841bd2 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -44,6 +44,7 @@
>  #include "migration/register.h"
>  #include "mmu-hash64.h"
>  #include "mmu-book3s-v3.h"
> +#include "cpu-models.h"
>  #include "qom/cpu.h"
>  
>  #include "hw/boards.h"
> @@ -252,9 +253,10 @@ static int spapr_fixup_cpu_numa_dt(void *fdt, int 
> offset, PowerPCCPU *cpu)
>  }
>  
>  /* Populate the "ibm,pa-features" property */
> -static void spapr_populate_pa_features(CPUPPCState *env, void *fdt, int 
> offset,
> -  bool legacy_guest)
> +static void spapr_populate_pa_features(PowerPCCPU *cpu, void *fdt, int 
> offset,
> +   bool legacy_guest)
>  {
> +CPUPPCState *env = >env;
>  uint8_t pa_features_206[] = { 6, 0,
>  0xf6, 0x1f, 0xc7, 0x00, 0x80, 0xc0 };
>  uint8_t pa_features_207[] = { 24, 0,
> @@ -287,23 +289,22 @@ static void spapr_populate_pa_features(CPUPPCState 
> *env, void *fdt, int offset,
>  /* 60: NM atomic, 62: RNG */
>  0x80, 0x00, 0x80, 0x00, 0x00, 0x00, /* 60 - 65 */
>  };
> -uint8_t *pa_features;
> +uint8_t *pa_features = NULL;
>  size_t pa_size;
>  
> -switch (POWERPC_MMU_VER(env->mmu_model)) {
> -case POWERPC_MMU_VER_2_06:
> +if (ppc_check_compat(cpu, CPU_POWERPC_LOGICAL_2_06, 0, cpu->compat_pvr)) 
> {
>  pa_features = pa_features_206;
>  pa_size = sizeof(pa_features_206);
> -break;
> -case POWERPC_MMU_VER_2_07:
> +}
> +if (ppc_check_compat(cpu, CPU_POWERPC_LOGICAL_2_07, 0, cpu->compat_pvr)) 
> {
>  pa_features = pa_features_207;
>  pa_size = sizeof(pa_features_207);
> -break;
> -case POWERPC_MMU_VER_3_00:
> +}
> +if (ppc_check_compat(cpu, CPU_POWERPC_LOGICAL_3_00, 0, cpu->compat_pvr)) 
> {
>  pa_features = pa_features_300;
>  pa_size = sizeof(pa_features_300);
> -break;
> -default:
> +}
> +if (!pa_features) {
>  return;
>  }
>  
> @@ -340,7 +341,6 @@ static int spapr_fixup_cpu_dt(void *fdt, 
> sPAPRMachineState *spapr)
>  
>  CPU_FOREACH(cs) {
>  PowerPCCPU *cpu = POWERPC_CPU(cs);
> -CPUPPCState *env = >env;
>  DeviceClass *dc = DEVICE_GET_CLASS(cs);
>  int index = spapr_vcpu_id(cpu);
>  int compat_smt = MIN(smp_threads, ppc_compat_max_threads(cpu));
> @@ -384,7 +384,7 @@ static int spapr_fixup_cpu_dt(void *fdt, 
> sPAPRMachineState *spapr)
>  return ret;
>  }
>  
> -spapr_populate_pa_features(env, fdt, offset,
> +spapr_populate_pa_features(cpu, fdt, offset,
>   spapr->cas_legacy_guest_workaround);
>  }
>  return ret;
> @@ -579,7 +579,7 @@ static void spapr_populate_cpu_dt(CPUState 

[Qemu-devel] [PATCH v3 3/3] msi: Handle remappable format interrupt request

[Chao Gao]

According to VT-d spec Interrupt Remapping and Interrupt Posting ->
Interrupt Remapping -> Interrupt Request Formats On Intel 64
Platforms, fields of MSI data register have changed. This patch
avoids wrongly regarding a remappable format interrupt request as
an interrupt binded with a pirq.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
v3:
 - clarify the interrupt format bit is Intel-specific, then it is
 improper to define MSI_ADDR_IF_MASK in a common header.
---
 hw/i386/xen/xen-hvm.c | 10 +-
 hw/pci/msi.c  |  5 +++--
 hw/pci/msix.c |  4 +++-
 hw/xen/xen_pt_msi.c   |  2 +-
 include/hw/xen/xen.h  |  2 +-
 stubs/xen-hvm.c   |  2 +-
 6 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 8028bed..52dc8af 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -145,8 +145,16 @@ void xen_piix_pci_write_config_client(uint32_t address, 
uint32_t val, int len)
 }
 }
 
-int xen_is_pirq_msi(uint32_t msi_data)
+int xen_is_pirq_msi(uint32_t msi_addr_lo, uint32_t msi_data)
 {
+/* If the MSI address is configured in remapping format, the MSI will not
+ * be remapped into a pirq. This 'if' test excludes Intel-specific
+ * remappable msi.
+ */
+#define MSI_ADDR_IF_MASK 0x0010
+if (msi_addr_lo & MSI_ADDR_IF_MASK) {
+return 0;
+}
 /* If vector is 0, the msi is remapped into a pirq, passed as
  * dest_id.
  */
diff --git a/hw/pci/msi.c b/hw/pci/msi.c
index 5e05ce5..d05c876 100644
--- a/hw/pci/msi.c
+++ b/hw/pci/msi.c
@@ -289,7 +289,7 @@ void msi_reset(PCIDevice *dev)
 static bool msi_is_masked(const PCIDevice *dev, unsigned int vector)
 {
 uint16_t flags = pci_get_word(dev->config + msi_flags_off(dev));
-uint32_t mask, data;
+uint32_t mask, data, addr_lo;
 bool msi64bit = flags & PCI_MSI_FLAGS_64BIT;
 assert(vector < PCI_MSI_VECTORS_MAX);
 
@@ -298,7 +298,8 @@ static bool msi_is_masked(const PCIDevice *dev, unsigned 
int vector)
 }
 
 data = pci_get_word(dev->config + msi_data_off(dev, msi64bit));
-if (xen_is_pirq_msi(data)) {
+addr_lo = pci_get_long(dev->config + msi_address_lo_off(dev));
+if (xen_is_pirq_msi(addr_lo, data)) {
 return false;
 }
 
diff --git a/hw/pci/msix.c b/hw/pci/msix.c
index c944c02..4cb01db 100644
--- a/hw/pci/msix.c
+++ b/hw/pci/msix.c
@@ -83,9 +83,11 @@ static bool msix_vector_masked(PCIDevice *dev, unsigned int 
vector, bool fmask)
 {
 unsigned offset = vector * PCI_MSIX_ENTRY_SIZE;
 uint8_t *data = >msix_table[offset + PCI_MSIX_ENTRY_DATA];
+uint8_t *addr_lo = >msix_table[offset + PCI_MSIX_ENTRY_LOWER_ADDR];
 /* MSIs on Xen can be remapped into pirqs. In those cases, masking
  * and unmasking go through the PV evtchn path. */
-if (xen_enabled() && xen_is_pirq_msi(pci_get_long(data))) {
+if (xen_enabled() && xen_is_pirq_msi(pci_get_long(addr_lo),
+ pci_get_long(data))) {
 return false;
 }
 return fmask || dev->msix_table[offset + PCI_MSIX_ENTRY_VECTOR_CTRL] &
diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
index f7d6e76..0e5bf83 100644
--- a/hw/xen/xen_pt_msi.c
+++ b/hw/xen/xen_pt_msi.c
@@ -96,7 +96,7 @@ static int msi_msix_setup(XenPCIPassthroughState *s,
 
 assert((!is_msix && msix_entry == 0) || is_msix);
 
-if (xen_is_pirq_msi(data)) {
+if (xen_is_pirq_msi(addr, data)) {
 *ppirq = msi_ext_dest_id(addr >> 32) | msi_dest_id(addr);
 if (!*ppirq) {
 /* this probably identifies an misconfiguration of the guest,
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index 7efcdaa..0d6c83e 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -34,7 +34,7 @@ int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num);
 void xen_piix3_set_irq(void *opaque, int irq_num, int level);
 void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len);
 void xen_hvm_inject_msi(uint64_t addr, uint32_t data);
-int xen_is_pirq_msi(uint32_t msi_data);
+int xen_is_pirq_msi(uint32_t msi_addr_lo, uint32_t msi_data);
 
 qemu_irq *xen_interrupt_controller_init(void);
 
diff --git a/stubs/xen-hvm.c b/stubs/xen-hvm.c
index 3ca6c51..aeb1592 100644
--- a/stubs/xen-hvm.c
+++ b/stubs/xen-hvm.c
@@ -31,7 +31,7 @@ void xen_hvm_inject_msi(uint64_t addr, uint32_t data)
 {
 }
 
-int xen_is_pirq_msi(uint32_t msi_data)
+int xen_is_pirq_msi(uint32_t msi_addr_lo, uint32_t msi_data)
 {
 return 0;
 }
-- 
1.8.3.1

[Qemu-devel] [PATCH v3 0/3] Qemu: add Xen vIOMMU interrupt remapping function support

[Chao Gao]

This patchset is to deal with MSI interrupt remapping request when guest
updates MSI registers.

In case of conflicts, this series also can be found in my personal github:
Xen: https://github.com/gc1008/viommu_xen.git vIOMMU4
Qemu: https://github.com/gc1008/viommu_qemu.git vIOMMU3

Any comments would be highly appreciated. And below is the change histroy

Changes from v2:
In last version, a new interface is used for binding a guest remappable msi
with a physical interrupt, while the old interface is used for binding
non-remappable msi. But for AMD, only from the MSI message itself, the
interrupt format cannot be infered. To address this, we decide to pass the
whole guest msi message to Xen and let vIOMMUs in Xen detemine whether
an given interrupt is remappable or not.
So the following changes are made:
- Instead of introducing a new interface for binding remapping format msi,
the exist interface is modified to support msi of both format.
- In patch 3, define MSI_ADDR_IF_MASK inside a function because
it is intel-specific. It is improper to define it in a common header.

Chao Gao (3):
  i386/msi: Correct mask of destination ID in MSI address
  xen/pt: Pass the whole msi addr/data to Xen
  msi: Handle remappable format interrupt request

 hw/i386/xen/xen-hvm.c | 10 -
 hw/pci/msi.c  |  5 +++--
 hw/pci/msix.c |  4 +++-
 hw/xen/xen_pt_msi.c   | 49 ---
 include/hw/i386/apic-msidef.h |  2 +-
 include/hw/xen/xen.h  |  2 +-
 stubs/xen-hvm.c   |  2 +-
 7 files changed, 31 insertions(+), 43 deletions(-)

-- 
1.8.3.1

[Qemu-devel] [PATCH v3 2/3] xen/pt: Pass the whole msi addr/data to Xen

[Chao Gao]

Previously, some fields (reserved or unalterable) are filtered by
Qemu. This fields are useless for the legacy interrupt format.
However, these fields are may meaningful (for intel platform)
for the interrupt of remapping format. It is better to pass the whole
msi addr/data to Xen without any filtering.

The main reason why we want this is QEMU doesn't have the knowledge
to decide the interrupt format after we introduce vIOMMU inside Xen.
Passing the whole msi message down and let arch-specific vIOMMU to
decide the interrupt format.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
v3:
 - new
---
 hw/xen/xen_pt_msi.c | 47 ---
 1 file changed, 12 insertions(+), 35 deletions(-)

diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
index 6d1e3bd..f7d6e76 100644
--- a/hw/xen/xen_pt_msi.c
+++ b/hw/xen/xen_pt_msi.c
@@ -47,25 +47,6 @@ static inline uint32_t msi_ext_dest_id(uint32_t addr_hi)
 return addr_hi & 0xff00;
 }
 
-static uint32_t msi_gflags(uint32_t data, uint64_t addr)
-{
-uint32_t result = 0;
-int rh, dm, dest_id, deliv_mode, trig_mode;
-
-rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
-dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
-dest_id = msi_dest_id(addr);
-deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
-trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
-
-result = dest_id | (rh << XEN_PT_GFLAGS_SHIFT_RH)
-| (dm << XEN_PT_GFLAGS_SHIFT_DM)
-| (deliv_mode << XEN_PT_GFLAGSSHIFT_DELIV_MODE)
-| (trig_mode << XEN_PT_GFLAGSSHIFT_TRG_MODE);
-
-return result;
-}
-
 static inline uint64_t msi_addr64(XenPTMSI *msi)
 {
 return (uint64_t)msi->addr_hi << 32 | msi->addr_lo;
@@ -160,23 +141,20 @@ static int msi_msix_update(XenPCIPassthroughState *s,
bool masked)
 {
 PCIDevice *d = >dev;
-uint8_t gvec = msi_vector(data);
-uint32_t gflags = msi_gflags(data, addr);
+uint32_t gflags = masked ? 0 : (1u << XEN_PT_GFLAGSSHIFT_UNMASKED);
 int rc = 0;
 uint64_t table_addr = 0;
 
-XEN_PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x gflags %#x"
-   " (entry: %#x)\n",
-   is_msix ? "-X" : "", pirq, gvec, gflags, msix_entry);
+XEN_PT_LOG(d, "Updating MSI%s with pirq %d gvec %#x addr %"PRIx64
+   " data %#x gflags %#x (entry: %#x)\n",
+   is_msix ? "-X" : "", pirq, addr, data, gflags, msix_entry);
 
 if (is_msix) {
 table_addr = s->msix->mmio_base_addr;
 }
 
-gflags |= masked ? 0 : (1u << XEN_PT_GFLAGSSHIFT_UNMASKED);
-
-rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
-  pirq, gflags, table_addr);
+rc = xc_domain_update_msi_irq(xen_xc, xen_domid, pirq, addr,
+  data, gflags, table_addr);
 
 if (rc) {
 XEN_PT_ERR(d, "Updating of MSI%s failed. (err: %d)\n",
@@ -199,8 +177,6 @@ static int msi_msix_disable(XenPCIPassthroughState *s,
 bool is_binded)
 {
 PCIDevice *d = >dev;
-uint8_t gvec = msi_vector(data);
-uint32_t gflags = msi_gflags(data, addr);
 int rc = 0;
 
 if (pirq == XEN_PT_UNASSIGNED_PIRQ) {
@@ -208,12 +184,13 @@ static int msi_msix_disable(XenPCIPassthroughState *s,
 }
 
 if (is_binded) {
-XEN_PT_LOG(d, "Unbind MSI%s with pirq %d, gvec %#x\n",
-   is_msix ? "-X" : "", pirq, gvec);
-rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec, pirq, gflags);
+XEN_PT_LOG(d, "Unbind MSI%s with pirq %d, addr %"PRIx64", data %#x\n",
+   is_msix ? "-X" : "", pirq, addr, data);
+rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, pirq, addr, data);
 if (rc) {
-XEN_PT_ERR(d, "Unbinding of MSI%s failed. (err: %d, pirq: %d, 
gvec: %#x)\n",
-   is_msix ? "-X" : "", errno, pirq, gvec);
+XEN_PT_ERR(d, "Unbinding of MSI%s failed. (err: %d, pirq: %d, "
+   "addr: %"PRIx64", data: %#x)\n",
+   is_msix ? "-X" : "", errno, pirq, addr, data);
 return rc;
 }
 }
-- 
1.8.3.1

[Qemu-devel] [PATCH v3 1/3] i386/msi: Correct mask of destination ID in MSI address

[Chao Gao]

According to SDM 10.11.1, only [19:12] bits of MSI address are
Destination ID, change the mask to avoid ambiguity for VT-d spec
has used the bit 4 to indicate a remappable interrupt request.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
Reviewed-by: Anthony PERARD 
Reviewed-by: Peter Xu 
---
 include/hw/i386/apic-msidef.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/hw/i386/apic-msidef.h b/include/hw/i386/apic-msidef.h
index 8b4d4cc..420b411 100644
--- a/include/hw/i386/apic-msidef.h
+++ b/include/hw/i386/apic-msidef.h
@@ -26,6 +26,6 @@
 
 #define MSI_ADDR_DEST_ID_SHIFT  12
 #define MSI_ADDR_DEST_IDX_SHIFT 4
-#define  MSI_ADDR_DEST_ID_MASK  0x000
+#define  MSI_ADDR_DEST_ID_MASK  0x000ff000
 
 #endif /* HW_APIC_MSIDEF_H */
-- 
1.8.3.1

[Qemu-devel] [PATCH] rcu: reduce half heap memory size by malloc_trim()

[Yang Zhong]

Since there are some issues in memory alloc/free machenism
in glibc for little chunk memory, if Qemu frequently
alloc/free little chunk memory, the glibc doesn't alloc
little chunk memory from free list of glibc and still
allocate from OS, which make the heap size bigger and bigger.

This patch introduce malloc_trim(), which will free heap memory.

Below are test results from smaps file.
55f0783e1000-55f07992a000 rw-p  00:00 0  [heap]
Size:  21796 kB
Rss:   14260 kB
Pss:   14260 kB

55cc5fadf000-55cc61008000 rw-p  00:00 0  [heap]
Size:  21668 kB
Rss:6940 kB
Pss:6940 kB

Signed-off-by: Yang Zhong 
---
 util/rcu.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/util/rcu.c b/util/rcu.c
index ca5a63e..8d491a6 100644
--- a/util/rcu.c
+++ b/util/rcu.c
@@ -26,6 +26,7 @@
  * IBM's contributions to this file may be relicensed under LGPLv2 or later.
  */
 
+#include 
 #include "qemu/osdep.h"
 #include "qemu-common.h"
 #include "qemu/rcu.h"
@@ -272,6 +273,9 @@ static void *call_rcu_thread(void *opaque)
 node->func(node);
 }
 qemu_mutex_unlock_iothread();
+#ifdef CONFIG_LINUX
+malloc_trim(0);
+#endif
 }
 abort();
 }
-- 
1.9.1

Re: [Qemu-devel] [PATCH for-2.12 v3 08/11] spapr: introduce a XICSFabric irq_is_lsi() operation

[David Gibson]

On Fri, Nov 10, 2017 at 03:20:14PM +, Cédric Le Goater wrote:
> It will be used later on to distinguish the allocation of an LSI
> interrupt from an MSI and also to reduce the use of the ICSIRQState
> array of the ICSState object, which is on our way to introduce XIVE.
> 
> The 'irq' parameter continues to refer to the global IRQ number space.
> 
> On PowerNV, only the PSI controller interrupts are handled and they
> are all LSIs.
> 
> Signed-off-by: Cédric Le Goater 

!?! AFAICT this is a step backwards.  The users of ics_is_lsi() here
are in the xics code.  So they already have the right information
locally in the ICSState object.  Why on earth would you indirect
through the fabric.

> ---
>  hw/intc/xics.c| 26 +-
>  hw/intc/xics_kvm.c|  4 ++--
>  hw/ppc/pnv.c  | 16 
>  hw/ppc/spapr.c|  9 +
>  include/hw/ppc/xics.h |  2 ++
>  5 files changed, 46 insertions(+), 11 deletions(-)
> 
> diff --git a/hw/intc/xics.c b/hw/intc/xics.c
> index 2c4899f278e2..42880e736697 100644
> --- a/hw/intc/xics.c
> +++ b/hw/intc/xics.c
> @@ -33,6 +33,7 @@
>  #include "trace.h"
>  #include "qemu/timer.h"
>  #include "hw/ppc/xics.h"
> +#include "hw/ppc/spapr.h"
>  #include "qemu/error-report.h"
>  #include "qapi/visitor.h"
>  #include "monitor/monitor.h"
> @@ -70,8 +71,7 @@ void ics_pic_print_info(ICSState *ics, Monitor *mon)
>  }
>  monitor_printf(mon, "  %4x %s %02x %02x\n",
> ics->offset + i,
> -   (irq->flags & XICS_FLAGS_IRQ_LSI) ?
> -   "LSI" : "MSI",
> +   ics_is_lsi(ics, i) ? "LSI" : "MSI",

!?! 

> irq->priority, irq->status);
>  }
>  }
> @@ -377,6 +377,14 @@ static const TypeInfo icp_info = {
>  /*
>   * ICS: Source layer
>   */
> +bool ics_is_lsi(ICSState *ics, int srcno)
> +{
> +XICSFabric *xi = ics->xics;
> +XICSFabricClass *xic = XICS_FABRIC_GET_CLASS(xi);
> +
> +return xic->irq_is_lsi(xi, srcno + ics->offset);
> +}
> +
>  static void ics_simple_resend_msi(ICSState *ics, int srcno)
>  {
>  ICSIRQState *irq = ics->irqs + srcno;
> @@ -435,7 +443,7 @@ static void ics_simple_set_irq(void *opaque, int srcno, 
> int val)
>  {
>  ICSState *ics = (ICSState *)opaque;
>  
> -if (ics->irqs[srcno].flags & XICS_FLAGS_IRQ_LSI) {
> +if (ics_is_lsi(ics, srcno)) {
>  ics_simple_set_irq_lsi(ics, srcno, val);
>  } else {
>  ics_simple_set_irq_msi(ics, srcno, val);
> @@ -472,7 +480,7 @@ void ics_simple_write_xive(ICSState *ics, int srcno, int 
> server,
>  trace_xics_ics_simple_write_xive(ics->offset + srcno, srcno, server,
>   priority);
>  
> -if (ics->irqs[srcno].flags & XICS_FLAGS_IRQ_LSI) {
> +if (ics_is_lsi(ics, srcno)) {
>  ics_simple_write_xive_lsi(ics, srcno);
>  } else {
>  ics_simple_write_xive_msi(ics, srcno);
> @@ -484,10 +492,10 @@ static void ics_simple_reject(ICSState *ics, uint32_t 
> nr)
>  ICSIRQState *irq = ics->irqs + nr - ics->offset;
>  
>  trace_xics_ics_simple_reject(nr, nr - ics->offset);
> -if (irq->flags & XICS_FLAGS_IRQ_MSI) {
> -irq->status |= XICS_STATUS_REJECTED;
> -} else if (irq->flags & XICS_FLAGS_IRQ_LSI) {
> +if (ics_is_lsi(ics, nr - ics->offset)) {
>  irq->status &= ~XICS_STATUS_SENT;
> +} else {
> +irq->status |= XICS_STATUS_REJECTED;
>  }
>  }
>  
> @@ -497,7 +505,7 @@ static void ics_simple_resend(ICSState *ics)
>  
>  for (i = 0; i < ics->nr_irqs; i++) {
>  /* FIXME: filter by server#? */
> -if (ics->irqs[i].flags & XICS_FLAGS_IRQ_LSI) {
> +if (ics_is_lsi(ics, i)) {
>  ics_simple_resend_lsi(ics, i);
>  } else {
>  ics_simple_resend_msi(ics, i);
> @@ -512,7 +520,7 @@ static void ics_simple_eoi(ICSState *ics, uint32_t nr)
>  
>  trace_xics_ics_simple_eoi(nr);
>  
> -if (ics->irqs[srcno].flags & XICS_FLAGS_IRQ_LSI) {
> +if (ics_is_lsi(ics, srcno)) {
>  irq->status &= ~XICS_STATUS_SENT;
>  }
>  }
> diff --git a/hw/intc/xics_kvm.c b/hw/intc/xics_kvm.c
> index 3091ad3ac2c8..2f10637c9f7c 100644
> --- a/hw/intc/xics_kvm.c
> +++ b/hw/intc/xics_kvm.c
> @@ -258,7 +258,7 @@ static int ics_set_kvm_state(ICSState *ics, int 
> version_id)
>  state |= KVM_XICS_MASKED;
>  }
>  
> -if (ics->irqs[i].flags & XICS_FLAGS_IRQ_LSI) {
> +if (ics_is_lsi(ics, i)) {
>  state |= KVM_XICS_LEVEL_SENSITIVE;
>  if (irq->status & XICS_STATUS_ASSERTED) {
>  state |= KVM_XICS_PENDING;
> @@ -293,7 +293,7 @@ static void ics_kvm_set_irq(void *opaque, int srcno, int 
> val)
>  int rc;
>  
>  args.irq = srcno + ics->offset;
> -if (ics->irqs[srcno].flags & XICS_FLAGS_IRQ_MSI) {
> +if (!ics_is_lsi(ics, srcno)) {
>  if (!val) {
>  return;
>  }
> diff 

[Qemu-devel] [QEMU-PPC] [PATCH V3] target/ppc: Update setting of cpu features to account for compat modes

[Suraj Jitindar Singh]

The device tree nodes ibm,arch-vec-5-platform-support and ibm,pa-features
are used to communicate features of the cpu to the guest operating
system. The properties of each of these are determined based on the
selected cpu model and the availability of hypervisor features.
Currently the compatibility mode of the cpu is not taken into account.

The ibm,arch-vec-5-platform-support node is used to communicate the
level of support for various ISAv3 processor features to the guest
before CAS to inform the guests' request. The available mmu mode should
only be hash unless the cpu is a POWER9 which is not in a prePOWER9
compat mode, in which case the available modes depend on the
accelerator and the hypervisor capabilities.

The ibm,pa-featues node is used to communicate the level of cpu support
for various features to the guest os. This should only contain features
relevant to the operating mode of the processor, that is the selected
cpu model taking into account any compat mode. This means that the
compat mode should be taken into account when choosing the properties of
ibm,pa-features and they should match the compat mode selected, or the
cpu model selected if no compat mode.

Update the setting of these cpu features in the device tree as described
above to properly take into account any compat mode. We use the
ppc_check_compat function which takes into account the current processor
model and the cpu compat mode.

Signed-off-by: Suraj Jitindar Singh 

---

V1 -> V2:
- Pass cpu pointer to spapr_populate_pa_features to avoid extracting it
  back out from env
- Slight reword of spapr_dt_ov5_platform_support logic to avoid
  duplicate case
V2 -> V3:
- Use ppc_check_compat() to avoid having to check both the cpu model
  and the compat mode separately since it does it for us
---
 hw/ppc/spapr.c | 43 +--
 1 file changed, 21 insertions(+), 22 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index d682f01..6841bd2 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -44,6 +44,7 @@
 #include "migration/register.h"
 #include "mmu-hash64.h"
 #include "mmu-book3s-v3.h"
+#include "cpu-models.h"
 #include "qom/cpu.h"
 
 #include "hw/boards.h"
@@ -252,9 +253,10 @@ static int spapr_fixup_cpu_numa_dt(void *fdt, int offset, 
PowerPCCPU *cpu)
 }
 
 /* Populate the "ibm,pa-features" property */
-static void spapr_populate_pa_features(CPUPPCState *env, void *fdt, int offset,
-  bool legacy_guest)
+static void spapr_populate_pa_features(PowerPCCPU *cpu, void *fdt, int offset,
+   bool legacy_guest)
 {
+CPUPPCState *env = >env;
 uint8_t pa_features_206[] = { 6, 0,
 0xf6, 0x1f, 0xc7, 0x00, 0x80, 0xc0 };
 uint8_t pa_features_207[] = { 24, 0,
@@ -287,23 +289,22 @@ static void spapr_populate_pa_features(CPUPPCState *env, 
void *fdt, int offset,
 /* 60: NM atomic, 62: RNG */
 0x80, 0x00, 0x80, 0x00, 0x00, 0x00, /* 60 - 65 */
 };
-uint8_t *pa_features;
+uint8_t *pa_features = NULL;
 size_t pa_size;
 
-switch (POWERPC_MMU_VER(env->mmu_model)) {
-case POWERPC_MMU_VER_2_06:
+if (ppc_check_compat(cpu, CPU_POWERPC_LOGICAL_2_06, 0, cpu->compat_pvr)) {
 pa_features = pa_features_206;
 pa_size = sizeof(pa_features_206);
-break;
-case POWERPC_MMU_VER_2_07:
+}
+if (ppc_check_compat(cpu, CPU_POWERPC_LOGICAL_2_07, 0, cpu->compat_pvr)) {
 pa_features = pa_features_207;
 pa_size = sizeof(pa_features_207);
-break;
-case POWERPC_MMU_VER_3_00:
+}
+if (ppc_check_compat(cpu, CPU_POWERPC_LOGICAL_3_00, 0, cpu->compat_pvr)) {
 pa_features = pa_features_300;
 pa_size = sizeof(pa_features_300);
-break;
-default:
+}
+if (!pa_features) {
 return;
 }
 
@@ -340,7 +341,6 @@ static int spapr_fixup_cpu_dt(void *fdt, sPAPRMachineState 
*spapr)
 
 CPU_FOREACH(cs) {
 PowerPCCPU *cpu = POWERPC_CPU(cs);
-CPUPPCState *env = >env;
 DeviceClass *dc = DEVICE_GET_CLASS(cs);
 int index = spapr_vcpu_id(cpu);
 int compat_smt = MIN(smp_threads, ppc_compat_max_threads(cpu));
@@ -384,7 +384,7 @@ static int spapr_fixup_cpu_dt(void *fdt, sPAPRMachineState 
*spapr)
 return ret;
 }
 
-spapr_populate_pa_features(env, fdt, offset,
+spapr_populate_pa_features(cpu, fdt, offset,
  spapr->cas_legacy_guest_workaround);
 }
 return ret;
@@ -579,7 +579,7 @@ static void spapr_populate_cpu_dt(CPUState *cs, void *fdt, 
int offset,
   page_sizes_prop, page_sizes_prop_size)));
 }
 
-spapr_populate_pa_features(env, fdt, offset, false);
+spapr_populate_pa_features(cpu, fdt, offset, false);
 
 _FDT((fdt_setprop_cell(fdt, offset, "ibm,chip-id",
cs->cpu_index / vcpus_per_socket)));
@@ -949,7 

Re: [Qemu-devel] [PATCH for-2.12 v3 05/11] spapr: introduce an IRQ allocator using a bitmap

[David Gibson]

On Tue, Nov 14, 2017 at 10:42:24AM +0100, Greg Kurz wrote:
> On Fri, 10 Nov 2017 15:20:11 +
> Cédric Le Goater  wrote:
> 
> > Let's define a new set of XICSFabric IRQ operations for the latest
> > pseries machine. These simply use a a bitmap 'irq_map' as a IRQ number
> > allocator.
> > 
> > The previous pseries machines keep the old set of IRQ operations using
> > the ICSIRQState array.
> > 
> > Signed-off-by: Cédric Le Goater 
> > ---
> > 
> >  Changes since v2 :
> > 
> >  - introduced a second set of XICSFabric IRQ operations for older
> >pseries machines
> > 
> >  hw/ppc/spapr.c | 76 
> > ++
> >  include/hw/ppc/spapr.h |  3 ++
> >  2 files changed, 74 insertions(+), 5 deletions(-)
> > 
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index 4bdceb45a14f..4ef0b73559ca 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -1681,6 +1681,22 @@ static const VMStateDescription 
> > vmstate_spapr_patb_entry = {
> >  },
> >  };
> >  
> > +static bool spapr_irq_map_needed(void *opaque)
> > +{
> > +return true;
> 
> I see that the next patch adds some code to avoid sending the
> bitmap if it doesn't contain state, but I guess you should also
> explicitly have this function to return false for older machine
> types (see remark below).

I don't see that you should need to migrate this at all.  The machine
needs to reliably allocate the same interrupts each time, and that
means source and dest should have the same allocations without
migrating data.

> 
> > +}
> > +
> > +static const VMStateDescription vmstate_spapr_irq_map = {
> > +.name = "spapr_irq_map",
> > +.version_id = 0,
> > +.minimum_version_id = 0,
> > +.needed = spapr_irq_map_needed,
> > +.fields = (VMStateField[]) {
> > +VMSTATE_BITMAP(irq_map, sPAPRMachineState, 0, nr_irqs),
> > +VMSTATE_END_OF_LIST()
> > +},
> > +};
> > +
> >  static const VMStateDescription vmstate_spapr = {
> >  .name = "spapr",
> >  .version_id = 3,
> > @@ -1700,6 +1716,7 @@ static const VMStateDescription vmstate_spapr = {
> >  _spapr_ov5_cas,
> >  _spapr_patb_entry,
> >  _spapr_pending_events,
> > +_spapr_irq_map,
> >  NULL
> >  }
> >  };
> > @@ -2337,8 +2354,12 @@ static void ppc_spapr_init(MachineState *machine)
> >  /* Setup a load limit for the ramdisk leaving room for SLOF and FDT */
> >  load_limit = MIN(spapr->rma_size, RTAS_MAX_ADDR) - FW_OVERHEAD;
> >  
> > +/* Initialize the IRQ allocator */
> > +spapr->nr_irqs  = XICS_IRQS_SPAPR;
> > +spapr->irq_map  = bitmap_new(spapr->nr_irqs);
> > +
> 
> I think you should introduce a sPAPRMachineClass::has_irq_bitmap boolean
> so that the bitmap is only allocated for newer machine types. And you should
> then use this flag in spapr_irq_map_needed() above.
> 
> Apart from that, the rest of the patch looks good.
> 
> >  /* Set up Interrupt Controller before we create the VCPUs */
> > -xics_system_init(machine, XICS_IRQS_SPAPR, _fatal);
> > +xics_system_init(machine, spapr->nr_irqs, _fatal);
> >  
> >  /* Set up containers for ibm,client-architecture-support negotiated 
> > options
> >   */
> > @@ -3560,7 +3581,7 @@ static int ics_find_free_block(ICSState *ics, int 
> > num, int alignnum)
> >  return -1;
> >  }
> >  
> > -static bool spapr_irq_test(XICSFabric *xi, int irq)
> > +static bool spapr_irq_test_2_11(XICSFabric *xi, int irq)
> >  {
> >  sPAPRMachineState *spapr = SPAPR_MACHINE(xi);
> >  ICSState *ics = spapr->ics;
> > @@ -3569,7 +3590,7 @@ static bool spapr_irq_test(XICSFabric *xi, int irq)
> >  return !ICS_IRQ_FREE(ics, srcno);
> >  }
> >  
> > -static int spapr_irq_alloc_block(XICSFabric *xi, int count, int align)
> > +static int spapr_irq_alloc_block_2_11(XICSFabric *xi, int count, int align)
> >  {
> >  sPAPRMachineState *spapr = SPAPR_MACHINE(xi);
> >  ICSState *ics = spapr->ics;
> > @@ -3583,7 +3604,7 @@ static int spapr_irq_alloc_block(XICSFabric *xi, int 
> > count, int align)
> >  return srcno + ics->offset;
> >  }
> >  
> > -static void spapr_irq_free_block(XICSFabric *xi, int irq, int num)
> > +static void spapr_irq_free_block_2_11(XICSFabric *xi, int irq, int num)
> >  {
> >  sPAPRMachineState *spapr = SPAPR_MACHINE(xi);
> >  ICSState *ics = spapr->ics;
> > @@ -3601,6 +3622,46 @@ static void spapr_irq_free_block(XICSFabric *xi, int 
> > irq, int num)
> >  }
> >  }
> >  
> > +static bool spapr_irq_test(XICSFabric *xi, int irq)
> > +{
> > +sPAPRMachineState *spapr = SPAPR_MACHINE(xi);
> > +int srcno = irq - spapr->ics->offset;
> > +
> > +return test_bit(srcno, spapr->irq_map);
> > +}
> > +
> > +static int spapr_irq_alloc_block(XICSFabric *xi, int count, int align)
> > +{
> > +sPAPRMachineState *spapr = SPAPR_MACHINE(xi);
> > +int start = 0;
> > +int srcno;
> > +
> > +/*
> > + * The 'align_mask' 

Re: [Qemu-devel] [PATCH for-2.11] hw/net/eepro100: Fix endianness problem on big endian hosts

[Stefan Weil]

Am 17.11.2017 um 05:14 schrieb Michael S. Tsirkin:
> On Thu, Nov 16, 2017 at 10:16:54PM +0100, Thomas Huth wrote:
>> Since commit 1865e288a823c764cd4344d ("Fix eepro100 simple transmission
>> mode"), the test/pxe-test is broken for the eepro100 device on big
>> endian hosts. However, it seems like that commit did not introduce the
>> problem, but just uncovered it: The EEPRO100State->tx.tbd_array_addr and
>> EEPRO100State->tx.tcb_bytes fields are already in host byte order, since
>> they have already been byte-swapped in the read_cb() function.
>> Thus byte-swapping them in tx_command() again results in the wrong
>> endianness. Removing the byte-swapping here fixes the pxe-test.
>>
>> Signed-off-by: Thomas Huth 
> 
> 
> Reviewed-by: Michael S. Tsirkin 
> 
> Thomas, how about adding sparse endian-ness annotations
> a la le32 in Linux? We could then use static checkers to
> catch these bugs at build time.

My main problem is that running big endian tests are
much more complex and time consuming simply because
my only big endian machines are QEMU virtual machines
(PPC* or MIPS*), so a test requires running QEMU
inside QEMU.

Nevertheless I had run such tests with network boot
and Linux guests as test cases, and they worked
(see comments in the header of eepro100.c).

So I wonder how the tests have to be enhanced to cover
more cases.

Stefan

Re: [Qemu-devel] [Question] why need to start all queues in vhost_net_start

[Longpeng (Mike)]

On 2017/11/17 12:32, Michael S. Tsirkin wrote:

> On Thu, Nov 16, 2017 at 08:04:34PM +0800, Jason Wang wrote:
>>
>>
>> On 2017年11月16日 17:32, Longpeng (Mike) wrote:
>>> Hi Jason,
>>>
>>> On 2017/11/16 17:13, Jason Wang wrote:
>>>

 On 2017年11月16日 17:01, Gonglei (Arei) wrote:
> No, Windows guest + vhost-user/DPDK.
>
> BTW pls see virtio spec in :
>
> "If VIRTIO_NET_F_MQ is negotiated, each of receiveq1. . .receiveqN that 
> will
> be used SHOULD be populated
> with receive buffers."
>
> It is not mandatory that all queues must be initialized.
 I think not, since it said we should fill receive buffers for each queue 
 which
 means we should initialize all queues. May Michael can clarify on this.

>>>
>>> I think this doesn't matter, but QEMU should consider this scenario...
>>>
>>> For example, if one queues isn't initialized (Windows guest), the 
>>> vring.avail=0,
>>> so vq->desc_phys=0, then vq->desc='a avail HVA'(which is the start addr of 
>>> pc.ram).
>>>
>>>  vq->desc_size = s = l = virtio_queue_get_desc_size(vdev, idx);
>>>  vq->desc_phys = a = virtio_queue_get_desc_addr(vdev, idx);
>>>  vq->desc = vhost_memory_map(dev, a, , 0);
>>>  if (!vq->desc || l != s) {
>>>  r = -ENOMEM;
>>>  goto fail_alloc_desc;
>>>  }
>>>  .
>>>  r = vhost_virtqueue_set_addr(dev, vq, vhost_vq_index, 
>>> dev->log_enabled);
>>>  if (r < 0) {
>>>  r = -errno;
>>>  goto fail_alloc;
>>>  }
>>>
>>> Then the HVA is send to the vhost-user.
>>>
>>> I think this is wrong, because the '0' here means guest driver doesn't init 
>>> this
>>> queues, it should not be used to calculate the HVA for this vq.
>>
>> Yes, workaround is not hard if windows driver won't use the left 3 queues
>> any more. But we should have a complete solution. The main problem is when
>> vhost need to be started. For legacy device, there's no easy way to detect
>> whether or not a specific virtqueue is ready to be used. For modern device,
>> we can probably do this through queue_enable (but this is not implemented in
>> current code).
>>
>> Thanks
> 
> What isn't implemented?
> 
> Spec is quite explicit:
> 
> 
> Client must only process each ring when it is started.
> 
> Client must only pass data between the ring and the
> backend, when the ring is enabled.
> 
> and later:
> 
> 
> Client must start ring upon receiving a kick (that is, detecting that file
> descriptor is readable) on the descriptor specified by
> VHOST_USER_SET_VRING_KICK, and stop ring upon receiving
> VHOST_USER_GET_VRING_BASE.
> 
> 
> Does someone kick unused rings? What entity does this?
> 


Hi Michael,

Maybe you don't get our point, so let me be clear. :)

Suppose there is a VM with 4 vcpus and 7 queues (vhost-user backend), the
Windows guest will only initialize the first 4 queues, so in QEMU the addresses
of the desc/avail/used tables of last 3 queues are all ZERO (initial value).

However QEMU will start all 7 queues, please look at the codes below:
'''
vhost_net_start
  for (i = 0; i < total_queues; i++) // start all 7 queues
vhost_net_start_one
  vhost_dev_start
vhost_virtqueue_start
'''

In vhost_virtqueue_start(), it will use the ZERO to calculate a corresponding
HVA for the last 3 queues and then send to the backend ( by
vhost_virtqueue_set_addr() ).

So our issue here is: the ZERO here means guest doesn't initialize the last 3
queues, so it needn't to calculate the HVA for them and send to then backend.

But, there is no issue on Linux guest, because Linux driver will initialize the
desc/avail/used tables for all 7 queues (even if it only uses the first 4 
queues).

Jason has already get our point, now we need to obtain more information about
Windows virtio-net driver from Yan.

> 
> 
> 
>>>
 Thanks

> Thanks,
> -Gonglei
>



 .

>>>
> 
> .
> 


-- 
Regards,
Longpeng(Mike)

Re: [Qemu-devel] [PATCH for-2.12 v3 03/11] spapr: introduce new XICSFabric operations for an IRQ allocator

[David Gibson]

On Fri, Nov 10, 2017 at 03:20:09PM +, Cédric Le Goater wrote:
> Currently, the ICSState 'ics' object of the sPAPR machine acts as the
> global interrupt source handler and also as the IRQ number allocator
> for the machine. Some IRQ numbers are allocated very early in the
> machine initialization sequence to populate the device tree, and this
> is a problem to introduce the new POWER XIVE interrupt model, as it
> needs to share the IRQ numbers with the older model.
> 
> To prepare ground for XIVE, here is a set of new XICSFabric operations
> to let the machine handle directly the IRQ number allocation and to
> decorrelate the allocation from the interrupt source object :
> 
> bool (*irq_test)(XICSFabric *xi, int irq);
> int (*irq_alloc_block)(XICSFabric *xi, int count, int align);
> void (*irq_free_block)(XICSFabric *xi, int irq, int num);
> 
> In these prototypes, the 'irq' parameter refers to a number in the
> global IRQ number space. Indexes for arrays storing different state
> informations on the interrupts, like the ICSIRQState, are usually
> named 'srcno'.
> 
> Signed-off-by: Cédric Le Goater 

This doesn't seem sensible to me.  When I said you should move irq
allocation to the machine, I mean actually move the code.  The only
user of irq allocation should be in the machine, so we shouldn't need
to indirect via the XICSFabric interface to do that.

And, we shouldn't be using XICSFabric things for XIVE.

> ---
>  hw/ppc/spapr.c| 19 +++
>  include/hw/ppc/xics.h |  4 
>  2 files changed, 23 insertions(+)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index a2dcbee07214..84d68f2fdbae 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -3536,6 +3536,21 @@ static ICPState *spapr_icp_get(XICSFabric *xi, int 
> vcpu_id)
>  return cpu ? ICP(cpu->intc) : NULL;
>  }
>  
> +static bool spapr_irq_test(XICSFabric *xi, int irq)
> +{
> +return false;
> +}
> +
> +static int spapr_irq_alloc_block(XICSFabric *xi, int count, int align)
> +{
> +return -1;
> +}
> +
> +static void spapr_irq_free_block(XICSFabric *xi, int irq, int num)
> +{
> +;
> +}
> +
>  static void spapr_pic_print_info(InterruptStatsProvider *obj,
>   Monitor *mon)
>  {
> @@ -3630,6 +3645,10 @@ static void spapr_machine_class_init(ObjectClass *oc, 
> void *data)
>  xic->ics_get = spapr_ics_get;
>  xic->ics_resend = spapr_ics_resend;
>  xic->icp_get = spapr_icp_get;
> +xic->irq_test = spapr_irq_test;
> +xic->irq_alloc_block = spapr_irq_alloc_block;
> +xic->irq_free_block = spapr_irq_free_block;
> +
>  ispc->print_info = spapr_pic_print_info;
>  /* Force NUMA node memory size to be a multiple of
>   * SPAPR_MEMORY_BLOCK_SIZE (256M) since that's the granularity
> diff --git a/include/hw/ppc/xics.h b/include/hw/ppc/xics.h
> index 28d248abad61..30e7f2e0a7dd 100644
> --- a/include/hw/ppc/xics.h
> +++ b/include/hw/ppc/xics.h
> @@ -175,6 +175,10 @@ typedef struct XICSFabricClass {
>  ICSState *(*ics_get)(XICSFabric *xi, int irq);
>  void (*ics_resend)(XICSFabric *xi);
>  ICPState *(*icp_get)(XICSFabric *xi, int server);
> +/* IRQ allocator helpers */
> +bool (*irq_test)(XICSFabric *xi, int irq);
> +int (*irq_alloc_block)(XICSFabric *xi, int count, int align);
> +void (*irq_free_block)(XICSFabric *xi, int irq, int num);
>  } XICSFabricClass;
>  
>  #define XICS_IRQS_SPAPR   1024

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [Question] why need to start all queues in vhost_net_start

[Michael S. Tsirkin]

On Thu, Nov 16, 2017 at 08:04:34PM +0800, Jason Wang wrote:
> 
> 
> On 2017年11月16日 17:32, Longpeng (Mike) wrote:
> > Hi Jason,
> > 
> > On 2017/11/16 17:13, Jason Wang wrote:
> > 
> > > 
> > > On 2017年11月16日 17:01, Gonglei (Arei) wrote:
> > > > No, Windows guest + vhost-user/DPDK.
> > > > 
> > > > BTW pls see virtio spec in :
> > > > 
> > > > "If VIRTIO_NET_F_MQ is negotiated, each of receiveq1. . .receiveqN that 
> > > > will
> > > > be used SHOULD be populated
> > > > with receive buffers."
> > > > 
> > > > It is not mandatory that all queues must be initialized.
> > > I think not, since it said we should fill receive buffers for each queue 
> > > which
> > > means we should initialize all queues. May Michael can clarify on this.
> > > 
> > 
> > I think this doesn't matter, but QEMU should consider this scenario...
> > 
> > For example, if one queues isn't initialized (Windows guest), the 
> > vring.avail=0,
> > so vq->desc_phys=0, then vq->desc='a avail HVA'(which is the start addr of 
> > pc.ram).
> > 
> >  vq->desc_size = s = l = virtio_queue_get_desc_size(vdev, idx);
> >  vq->desc_phys = a = virtio_queue_get_desc_addr(vdev, idx);
> >  vq->desc = vhost_memory_map(dev, a, , 0);
> >  if (!vq->desc || l != s) {
> >  r = -ENOMEM;
> >  goto fail_alloc_desc;
> >  }
> >  .
> >  r = vhost_virtqueue_set_addr(dev, vq, vhost_vq_index, 
> > dev->log_enabled);
> >  if (r < 0) {
> >  r = -errno;
> >  goto fail_alloc;
> >  }
> > 
> > Then the HVA is send to the vhost-user.
> > 
> > I think this is wrong, because the '0' here means guest driver doesn't init 
> > this
> > queues, it should not be used to calculate the HVA for this vq.
> 
> Yes, workaround is not hard if windows driver won't use the left 3 queues
> any more. But we should have a complete solution. The main problem is when
> vhost need to be started. For legacy device, there's no easy way to detect
> whether or not a specific virtqueue is ready to be used. For modern device,
> we can probably do this through queue_enable (but this is not implemented in
> current code).
> 
> Thanks

What isn't implemented?

Spec is quite explicit:


Client must only process each ring when it is started.

Client must only pass data between the ring and the
backend, when the ring is enabled.

and later:


Client must start ring upon receiving a kick (that is, detecting that file
descriptor is readable) on the descriptor specified by
VHOST_USER_SET_VRING_KICK, and stop ring upon receiving
VHOST_USER_GET_VRING_BASE.


Does someone kick unused rings? What entity does this?




> > 
> > > Thanks
> > > 
> > > > Thanks,
> > > > -Gonglei
> > > > 
> > > 
> > > 
> > > 
> > > .
> > > 
> > 

Re: [Qemu-devel] [PULL 00/10] pc, pci, virtio: fixes for rc1

[Michael S. Tsirkin]

On Thu, Nov 16, 2017 at 05:43:52PM +0100, Thomas Huth wrote:
> On 16.11.2017 17:15, Peter Maydell wrote:
> > On 16 November 2017 at 16:13, Daniel P. Berrange  
> > wrote:
> >> On Thu, Nov 16, 2017 at 04:10:22PM +, Peter Maydell wrote:
> >>> If there are known-buggy iasl versions in the wild we could
> >>> consider a configure test and treat buggy-iasl like no-iasl.
> >>
> >> iasl has long been broken on big-endian, but it has also long contained
> >> code that simply makes it exit immediately in that case, and qemu copes
> >> with that. So if there's buggy iasl it would be a distro which removed
> >> this big-endian check and tried to make it work on big-endian but failed.
> >> Fedora tried the latter, but at least in rawhide it works properly now.
> >> I'm unclear if we shipped broken iasl with the BE check removed in stable
> >> versions though
> > 
> > In this case this is Ubuntu 16.04.2 LTS (xenial) on s390x, with
> > 
> > linux1@lxub05:~$ iasl -v
> > 
> > Intel ACPI Component Architecture
> > ASL+ Optimizing Compiler version 20160108-64
> > Copyright (c) 2000 - 2016 Intel Corporation
> 
> That's likely a broken version, indeed. I've noticed that the iasl that
> ships with the acpica-tools in RHEL7 is broken, too - it does not
> contain the big-endian check (yet?), and fails to byte-swap on big
> endian hosts.
> 
> If you compile the latest version from upstream, you get this instead:
> 
> $ iasl -v
> iASL is not currently supported on big-endian machines.
> 
> But as Daniel already wrote: The version from Fedora contains some
> patches that fix the endianess issue, so that iasl with these patches
> also works fine on big endian hosts:
> 
>  
> https://src.fedoraproject.org/rpms/acpica-tools/blob/master/f/big-endian.patch
>  
> https://src.fedoraproject.org/rpms/acpica-tools/blob/master/f/big-endian-v2.patch
> 
>  Thomas

For the record, I think we should remove the dependency on iasl for
tests too. It is still a handy tool for debugging, so the following
would be a good plan IMHO:

- compare binary actual to expected in memory
- on match pass and skip iasl
- on mismatch, generate aml, run iasl, show
  output in existing format.
  then fail
- when generating expected files, print diff
  and make it easy to append to commit log


-- 
MST

Re: [Qemu-devel] [PATCH for-2.11] hw/net/eepro100: Fix endianness problem on big endian hosts

[Michael S. Tsirkin]

On Thu, Nov 16, 2017 at 10:16:54PM +0100, Thomas Huth wrote:
> Since commit 1865e288a823c764cd4344d ("Fix eepro100 simple transmission
> mode"), the test/pxe-test is broken for the eepro100 device on big
> endian hosts. However, it seems like that commit did not introduce the
> problem, but just uncovered it: The EEPRO100State->tx.tbd_array_addr and
> EEPRO100State->tx.tcb_bytes fields are already in host byte order, since
> they have already been byte-swapped in the read_cb() function.
> Thus byte-swapping them in tx_command() again results in the wrong
> endianness. Removing the byte-swapping here fixes the pxe-test.
> 
> Signed-off-by: Thomas Huth 


Reviewed-by: Michael S. Tsirkin 

Thomas, how about adding sparse endian-ness annotations
a la le32 in Linux? We could then use static checkers to
catch these bugs at build time.

> ---
>  hw/net/eepro100.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c
> index a63ed2c..03e00f7 100644
> --- a/hw/net/eepro100.c
> +++ b/hw/net/eepro100.c
> @@ -756,8 +756,8 @@ static void read_cb(EEPRO100State *s)
>  
>  static void tx_command(EEPRO100State *s)
>  {
> -uint32_t tbd_array = le32_to_cpu(s->tx.tbd_array_addr);
> -uint16_t tcb_bytes = (le16_to_cpu(s->tx.tcb_bytes) & 0x3fff);
> +uint32_t tbd_array = s->tx.tbd_array_addr;
> +uint16_t tcb_bytes = s->tx.tcb_bytes & 0x3fff;
>  /* Sends larger than MAX_ETH_FRAME_SIZE are allowed, up to 2600 bytes. */
>  uint8_t buf[2600];
>  uint16_t size = 0;
> -- 
> 1.8.3.1

Re: [Qemu-devel] [PATCH 0/2] virtio-net: Fix TX data discard on backend disconnection

[Jason Wang]

On 2017年11月17日 02:48, Maxime Coquelin wrote:

This series fixes TX data discard when backend disconnects.

On backend disconnection, QEMU cannot retrieve its internal
avail index, which makes the virtio queue internal state
inconsistent (last_avail_idx will always be 0, whereas used_idx
is correct).

It results in discarding TX data to corrupt the vring state, by
completing descriptors already completed by the backend.

This series fixes this by restoring last_avail_idx to the vring
used idx, as some backends used to do on reconnection.

Maxime Coquelin (2):
   virtio: Add queue interface to restore avail index from vring used
 index
   vhost: restore avail index from vring used index on disconnection

  hw/virtio/vhost.c  |  4 
  hw/virtio/virtio.c | 10 ++
  include/hw/virtio/virtio.h |  1 +
  3 files changed, 15 insertions(+)



Reviewed-by: Jason Wang 

Re: [Qemu-devel] [Question] why need to start all queues in vhost_net_start

[Jason Wang]

On 2017年11月17日 10:01, Longpeng (Mike) wrote:

On 2017/11/16 20:04, Jason Wang wrote:


On 2017年11月16日 17:32, Longpeng (Mike) wrote:

Hi Jason,

On 2017/11/16 17:13, Jason Wang wrote:


On 2017年11月16日 17:01, Gonglei (Arei) wrote:

No, Windows guest + vhost-user/DPDK.

BTW pls see virtio spec in :

"If VIRTIO_NET_F_MQ is negotiated, each of receiveq1. . .receiveqN that will
be used SHOULD be populated
with receive buffers."

It is not mandatory that all queues must be initialized.

I think not, since it said we should fill receive buffers for each queue which
means we should initialize all queues. May Michael can clarify on this.


I think this doesn't matter, but QEMU should consider this scenario...

For example, if one queues isn't initialized (Windows guest), the vring.avail=0,
so vq->desc_phys=0, then vq->desc='a avail HVA'(which is the start addr of
pc.ram).

  vq->desc_size = s = l = virtio_queue_get_desc_size(vdev, idx);
  vq->desc_phys = a = virtio_queue_get_desc_addr(vdev, idx);
  vq->desc = vhost_memory_map(dev, a, , 0);
  if (!vq->desc || l != s) {
  r = -ENOMEM;
  goto fail_alloc_desc;
  }
  .
  r = vhost_virtqueue_set_addr(dev, vq, vhost_vq_index, dev->log_enabled);
  if (r < 0) {
  r = -errno;
  goto fail_alloc;
  }

Then the HVA is send to the vhost-user.

I think this is wrong, because the '0' here means guest driver doesn't init this
queues, it should not be used to calculate the HVA for this vq.

Yes, workaround is not hard if windows driver won't use the left 3 queues any
more. But we should have a complete solution. The main problem is when vhost
need to be started. For legacy device, there's no easy way to detect whether or
not a specific virtqueue is ready to be used. For modern device, we can probably
do this through queue_enable (but this is not implemented in current code).


Can we initialize the vring.desc/vring.avail/vring.used to -1, then we can
detect whether or not a specific vq is ready to be used by check the addr of its
tables is -1 or not ?

Initialize to 0 is not suitable, because we don't know whether the guest set GPA
0 or the guest not initialize this vq.



Unfortunately, it's too late to do this in spec for legacy device. (If 
you look at the spec, legacy MMIO transport treat 0x0 as an illegal 
value.) For modern device, we could detect this through queue_enable.


Let's wait for Yan to reply whether or not windows driver can use the 
left three queues. If not, I will try to post a fix(workaround) for this 
and let's consider a complete solution.


Thanks

Re: [Qemu-devel] [PATCH for-2.12 0/4] qmp dirty bitmap API

[John Snow]

On 11/16/2017 03:17 AM, Vladimir Sementsov-Ogievskiy wrote:
> 16.11.2017 00:20, John Snow wrote:
>>
>> On 11/13/2017 11:20 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> Hi all.
>>>
>>> There are three qmp commands, needed to implement external backup API.
>>>
>>> Using these three commands, client may do all needed bitmap
>>> management by
>>> hand:
>>>
>>> on backup start we need to do a transaction:
>>>   {disable old bitmap, create new bitmap}
>>>
>>> on backup success:
>>>   drop old bitmap
>>>
>>> on backup fail:
>>>   enable old bitmap
>>>   merge new bitmap to old bitmap
>>>   drop new bitmap
>>>
>> Can you give me an example of how you expect these commands to be used,
>> and why they're required?
>>
>> I'm a little weary about how error-prone these commands might be and the
>> potential for incorrect usage seems... high. Why do we require them?
> 
> It is needed for incremental backup. It looks like bad idea to export
> abdicate/reclaim functionality, it is simpler
> and clearer to allow user to merge/enable/disable bitmaps by hand.
> 
> usage is like this:
> 
> 1. we have dirty bitmap bitmap0 for incremental backup.
> 
> 2. prepare image fleecing (create temporary image with backing=our_disk)
> 3. in qmp transaction:
>     - disable bitmap0
>     - create bitmap1
>     - start image fleecing (backup sync=none our_disk -> temp_disk)

This could probably just be its own command, though:

block-job-fleece node=foobar bitmap=bitmap0 etc=etera etc=etera

Could handle forking the bitmap. I'm not sure what the arguments would
look like, but we could name the NBD export here, too. (Assuming the
server is already started and we just need to create the share.)

Then, we can basically do what mirror does:

(1) Cancel
(2) Complete

Cancel would instruct QEMU to keep the bitmap changes (i.e. roll back),
and Complete would instruct QEMU to discard the changes.

This way we don't need to expose commands like split or merge that will
almost always be dangerous to use over QMP.

In fact, a fleecing job would be really convenient even without a
bitmap, because it'd still be nice to have a convenience command for it.
Using an existing infrastructure and understood paradigm is just a bonus.

> 4. export temp_disk (it looks like a snapshot) and bitmap0 through NBD
> 
> === external tool can get bitmap0 and then copy some clusters through
> NBD ===
> 
> on successful backup external tool can drop bitmap0. or can save it and
> reuse somehow
> 
> on failed backup external tool can do the following:
>     - enable bitmap0
>     - merge bitmap1 to bitmap0
>     - drop bitmap1
> 

Re: [Qemu-devel] [PATCH 0/2] e1000: Correct TX offload context handling

[Jason Wang]

On 2017年11月15日 07:23, Ed Swierk via Qemu-devel wrote:

The transmit offload implementation in QEMU's e1000 device is
deficient and causes packet data corruption in some situations.

According to the Intel 8254x software developer's manual[1], the
device maintains two separate contexts: the TCP segmentation offload
context includes parameters for both segmentation offload and checksum
offload, and the normal (checksum-offload-only) context includes only
checksum offload parameters. These parameters specify over which
packet data to compute the checksum, and where in the packet to store
the computed checksum(s).

[1] 
https://www.intel.com/content/dam/doc/manual/pci-pci-x-family-gbe-controllers-software-dev-manual.pdf

The e1000 driver can update either of these contexts by sending a
transmit context descriptor. The TSE bit in the TUCMD field controls
which context is modified by the descriptor. Crucially, a transmit
context descriptor with TSE=1 changes only the TSO context, leaving
the non-TSO context unchanged; with TSE=0 the opposite is true.

Fields in the transmit data descriptor determine which (if either) of
these two contexts the device uses when actually transmitting some
data:

- If the TSE bit in the DCMD field is set, then the device performs
   TCP segmentation offload using the parameters previously set in the
   TSO context. In addition, if TXSM and/or IXSM is set in the POPTS
   field, the device performs the appropriate checksum offloads using
   the parameters in the same (TSO) context.

- Otherwise, if the TSE bit in the DCMD field is clear, then there is
   no TCP segmentation offload. If TXSM and/or IXSM is set in the POPTS
   field, the device performs the appropriate checksum offloads using
   the parameters in the non-TSO context.

The e1000 driver is free to set up the TSO and non-TSO contexts and
then transmit a mixture of data, with each data descriptor using a
different (or neither) context. This is what the e1000 driver for
Windows (Intel(R) PRO/1000 MT Network Connection, aka E1G6023E.sys)
does in certain cases. Sometimes with quite undesirable results, since
the QEMU e1000 device doesn't work as described above.

Instead, the QEMU e1000 device maintains only one context in its state
structure. When it receives a transmit context descriptor from the
driver, it overwrites the context parameters regardless of the TSE bit
in the TUCMD field.

To see why this is wrong, suppose the driver first sets up a non-TSO
context with UDP checksum offload parameters (say, TUCSO pointing to
the appropriate offset for a UDP checksum, 6 bytes into the header),
and then sets up a TSO context with TCP checksum offload parameters
(TUCSO pointing to the appropriate offset for a TCP checksum, 16 bytes
into the header). The driver then sends a transmit data descriptor
with TSO=0 and TXSM=1 along with a UDP datagram. The QEMU e1000 device
computes the checksum using the last set of checksum offload
parameters, and writes the checksum to offset 16, stomping on two
bytes of UDP data, and leaving the wrong checksum in the UDP checksum
field.

To make matters worse, if the network stack on the host running QEMU
treats data transmitted from a VM as locally originated, it may do its
own UDP checksum computation, "correcting" it to match the corrupt
data before sending it on the wire. Now the corrupt UDP packet makes
its way all the way to the peer application.

I have reproduced this behavior with a Windows 10 guest, rather easily
with a TCP iperf and a UDP iperf running in parallel. With the
patchlet below, you'll see an error message whenever the bug is
triggered.


  --- a/hw/net/e1000.c
  +++ b/hw/net/e1000.c
  @@ -534,6 +534,30 @@ e1000_send_packet(E1000State *s, const uint8_t *buf, int 
size)
   }
   
   static void

  +debug_csum(struct e1000_tx *tp, uint16_t oldsum)
  +{
  +e1000x_txd_props *props = >props;
  +uint8_t proto = tp->data[14 + 9];
  +uint32_t sumoff = props->tucso - props->tucss;
  +
  +if ((proto == 17 && sumoff != 6) ||
  +(proto == 6 && sumoff != 16)) {
  +DBGOUT(TXERR, "txsum bug! ver %d src %08x dst %08x len %d proto %d "
  +   "cptse %d sum_needed %x oldsum %x newsum %x realsum %x\n",
  +   tp->data[14] >> 4,
  +   ldl_be_p(tp->data + 14 + 12),
  +   ldl_be_p(tp->data + 14 + 16),
  +   lduw_be_p(tp->data + 14 + 2),
  +   proto,
  +   props->cptse,
  +   props->sum_needed,
  +   oldsum,
  +   lduw_be_p(tp->data + props->tucso),
  +   lduw_be_p(tp->data + props->tucss + (proto == 6 ? 16 : 6)));
  +}
  +}
  +
  +static void
   xmit_seg(E1000State *s)
   {
   uint16_t len;
  @@ -577,8 +601,10 @@ xmit_seg(E1000State *s)
   }
   
   if (tp->props.sum_needed & E1000_TXD_POPTS_TXSM) {

  +uint16_t oldsum = lduw_be_p(tp->data + tp->props.tucso);
   putsum(tp->data, tp->size, tp->props.tucso,
   

Re: [Qemu-devel] [PATCH v3 REPOST] net: Transmit zero UDP checksum as 0xFFFF

[Jason Wang]

On 2017年11月16日 22:06, Ed Swierk wrote:

The checksum algorithm used by IPv4, TCP and UDP allows a zero value
to be represented by either 0x and 0x. But per RFC 768, a zero
UDP checksum must be transmitted as 0x because 0x is a special
value meaning no checksum.

Substitute 0x whenever a checksum is computed as zero when
modifying a UDP datagram header. Doing this on IPv4 and TCP checksums
is unnecessary but legal. Add a wrapper for net_checksum_finish() that
makes the substitution.

(We can't just change net_checksum_finish(), as that function is also
used by receivers to verify checksums, and in that case the expected
value is always 0x.)

Signed-off-by: Ed Swierk 
---
v3:

(Reposted to fix patch format)

Leave net_tx_pkt_update_ip_checksums() alone since it's only computing
a partial sum of the IP pseudo-header.

Rename wrapper to net_checksum_finish_nozero() for clarity.

v2:

Add a wrapper net_checksum_finish_hdr() rather than duplicating the
logic at every caller.
---
  hw/net/e1000.c | 2 +-
  hw/net/net_rx_pkt.c| 2 +-
  hw/net/net_tx_pkt.c| 2 +-
  hw/net/vmxnet3.c   | 3 ++-
  include/net/checksum.h | 6 ++
  5 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/hw/net/e1000.c b/hw/net/e1000.c
index 72a92be..804ec08 100644
--- a/hw/net/e1000.c
+++ b/hw/net/e1000.c
@@ -506,7 +506,7 @@ putsum(uint8_t *data, uint32_t n, uint32_t sloc, uint32_t 
css, uint32_t cse)
  n = cse + 1;
  if (sloc < n-1) {
  sum = net_checksum_add(n-css, data+css);
-stw_be_p(data + sloc, net_checksum_finish(sum));
+stw_be_p(data + sloc, net_checksum_finish_nozero(sum));
  }
  }
  
diff --git a/hw/net/net_rx_pkt.c b/hw/net/net_rx_pkt.c

index cef1c2e..98a5030 100644
--- a/hw/net/net_rx_pkt.c
+++ b/hw/net/net_rx_pkt.c
@@ -518,7 +518,7 @@ _net_rx_pkt_calc_l4_csum(struct NetRxPkt *pkt)
  cntr += net_checksum_add_iov(pkt->vec, pkt->vec_len,
   pkt->l4hdr_off, csl, cso);
  
-csum = net_checksum_finish(cntr);

+csum = net_checksum_finish_nozero(cntr);
  
  trace_net_rx_pkt_l4_csum_calc_csum(pkt->l4hdr_off, csl, cntr, csum);
  
diff --git a/hw/net/net_tx_pkt.c b/hw/net/net_tx_pkt.c

index 20b2549..e29c881 100644
--- a/hw/net/net_tx_pkt.c
+++ b/hw/net/net_tx_pkt.c
@@ -486,7 +486,7 @@ static void net_tx_pkt_do_sw_csum(struct NetTxPkt *pkt)
  net_checksum_add_iov(iov, iov_len, pkt->virt_hdr.csum_start, csl, 
cso);
  
  /* Put the checksum obtained into the packet */

-csum = cpu_to_be16(net_checksum_finish(csum_cntr));
+csum = cpu_to_be16(net_checksum_finish_nozero(csum_cntr));
  iov_from_buf(iov, iov_len, csum_offset, , sizeof csum);
  }
  
diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c

index 8c4bae5..cdc307d 100644
--- a/hw/net/vmxnet3.c
+++ b/hw/net/vmxnet3.c
@@ -972,7 +972,8 @@ static void vmxnet3_rx_need_csum_calculate(struct NetRxPkt 
*pkt,
  data = (uint8_t *)pkt_data + vhdr->csum_start;
  len = pkt_len - vhdr->csum_start;
  /* Put the checksum obtained into the packet */
-stw_be_p(data + vhdr->csum_offset, net_raw_checksum(data, len));
+stw_be_p(data + vhdr->csum_offset,
+ net_checksum_finish_nozero(net_checksum_add(len, data)));
  
  vhdr->flags &= ~VIRTIO_NET_HDR_F_NEEDS_CSUM;

  vhdr->flags |= VIRTIO_NET_HDR_F_DATA_VALID;
diff --git a/include/net/checksum.h b/include/net/checksum.h
index 7df472c..05a0d27 100644
--- a/include/net/checksum.h
+++ b/include/net/checksum.h
@@ -34,6 +34,12 @@ net_checksum_add(int len, uint8_t *buf)
  }
  
  static inline uint16_t

+net_checksum_finish_nozero(uint32_t sum)
+{
+return net_checksum_finish(sum) ?: 0x;
+}
+
+static inline uint16_t
  net_raw_checksum(uint8_t *data, int length)
  {
  return net_checksum_finish(net_checksum_add(length, data));


Applied, thanks.

Re: [Qemu-devel] [PATCH for-2.11] MAINTAINERS: Add missing entry for eepro100 emulation

[Jason Wang]

On 2017年11月17日 03:49, Stefan Weil wrote:

Signed-off-by: Stefan Weil 
---
  MAINTAINERS | 5 +
  1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ffd77b461c..83434e09af 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1183,6 +1183,11 @@ M: Dmitry Fleytman 
  S: Maintained
  F: hw/net/e1000e*
  
+eepro100

+M: Stefan Weil 
+S: Maintained
+F: hw/net/eepro100.c
+
  Generic Loader
  M: Alistair Francis 
  S: Maintained


Applied.

Thanks

Re: [Qemu-devel] [PATCH for-2.11] hw/net/eepro100: Fix endianness problem on big endian hosts

[Jason Wang]

On 2017年11月17日 05:16, Thomas Huth wrote:

Since commit 1865e288a823c764cd4344d ("Fix eepro100 simple transmission
mode"), the test/pxe-test is broken for the eepro100 device on big
endian hosts. However, it seems like that commit did not introduce the
problem, but just uncovered it: The EEPRO100State->tx.tbd_array_addr and
EEPRO100State->tx.tcb_bytes fields are already in host byte order, since
they have already been byte-swapped in the read_cb() function.
Thus byte-swapping them in tx_command() again results in the wrong
endianness. Removing the byte-swapping here fixes the pxe-test.

Signed-off-by: Thomas Huth 
---
  hw/net/eepro100.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c
index a63ed2c..03e00f7 100644
--- a/hw/net/eepro100.c
+++ b/hw/net/eepro100.c
@@ -756,8 +756,8 @@ static void read_cb(EEPRO100State *s)
  
  static void tx_command(EEPRO100State *s)

  {
-uint32_t tbd_array = le32_to_cpu(s->tx.tbd_array_addr);
-uint16_t tcb_bytes = (le16_to_cpu(s->tx.tcb_bytes) & 0x3fff);
+uint32_t tbd_array = s->tx.tbd_array_addr;
+uint16_t tcb_bytes = s->tx.tcb_bytes & 0x3fff;
  /* Sends larger than MAX_ETH_FRAME_SIZE are allowed, up to 2600 bytes. */
  uint8_t buf[2600];
  uint16_t size = 0;


Applied.

Thanks

Re: [Qemu-devel] [PATCH] Revert "Add new PCI ID for i82559a"

[Jason Wang]

On 2017年11月16日 20:20, Jason Wang wrote:

This reverts commit 5e89dc01133f8f5e621f6b66b356c6f37d31dafb since:

- we should use ID in the spec instead the one used by OEM
- in the future, we should allow changing id through either property
   or EEPROM file.

Cc: Stefan Weil 
Cc: Michael Nawrocki 
Cc: Peter Maydell 
Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
---
  hw/net/eepro100.c| 13 -
  include/hw/compat.h  |  4 
  include/hw/pci/pci.h |  1 -
  qemu-options.hx  |  2 +-
  4 files changed, 1 insertion(+), 19 deletions(-)

diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c
index a63ed2c..91dd058 100644
--- a/hw/net/eepro100.c
+++ b/hw/net/eepro100.c
@@ -132,7 +132,6 @@ typedef struct {
  const char *name;
  const char *desc;
  uint16_t device_id;
-uint16_t alt_device_id;
  uint8_t revision;
  uint16_t subsystem_vendor_id;
  uint16_t subsystem_id;
@@ -277,7 +276,6 @@ typedef struct {
  /* Quasi static device properties (no need to save them). */
  uint16_t stats_size;
  bool has_extended_tcb_support;
-bool use_alt_device_id;
  } EEPRO100State;
  
  /* Word indices in EEPROM. */

@@ -1857,14 +1855,6 @@ static void e100_nic_realize(PCIDevice *pci_dev, Error 
**errp)
  
  TRACE(OTHER, logout("\n"));
  
-/* By default, the i82559a adapter uses the legacy PCI ID (for the

- * i82557). This allows the PCI ID to be changed to the alternate
- * i82559 ID if needed.
- */
-if (s->use_alt_device_id && strcmp(info->name, "i82559a") == 0) {
-pci_config_set_device_id(s->dev.config, info->alt_device_id);
-}
-
  s->device = info->device;
  
  e100_pci_reset(s, _err);

@@ -1984,7 +1974,6 @@ static E100PCIDeviceInfo e100_devices[] = {
  .desc = "Intel i82559A Ethernet",
  .device = i82559A,
  .device_id = PCI_DEVICE_ID_INTEL_82557,
-.alt_device_id = PCI_DEVICE_ID_INTEL_82559,
  .revision = 0x06,
  .stats_size = 80,
  .has_extended_tcb_support = true,
@@ -2078,8 +2067,6 @@ static E100PCIDeviceInfo 
*eepro100_get_class(EEPRO100State *s)
  
  static Property e100_properties[] = {

  DEFINE_NIC_PROPERTIES(EEPRO100State, conf),
-DEFINE_PROP_BOOL("x-use-alt-device-id", EEPRO100State, use_alt_device_id,
- true),
  DEFINE_PROP_END_OF_LIST(),
  };
  
diff --git a/include/hw/compat.h b/include/hw/compat.h

index f96212c..cf389b4 100644
--- a/include/hw/compat.h
+++ b/include/hw/compat.h
@@ -10,10 +10,6 @@
  .driver   = "virtio-tablet-device",\
  .property = "wheel-axis",\
  .value= "false",\
-},{\
-.driver   = "i82559a",\
-.property = "x-use-alt-device-id",\
-.value= "false",\
  },
  
  #define HW_COMPAT_2_9 \

diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index f30e2cf..8d02a0a 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -70,7 +70,6 @@ extern bool pci_available;
  /* Intel (0x8086) */
  #define PCI_DEVICE_ID_INTEL_82551IT  0x1209
  #define PCI_DEVICE_ID_INTEL_825570x1229
-#define PCI_DEVICE_ID_INTEL_825590x1030
  #define PCI_DEVICE_ID_INTEL_82801IR  0x2922
  
  /* Red Hat / Qumranet (for QEMU) -- see pci-ids.txt */

diff --git a/qemu-options.hx b/qemu-options.hx
index a39c7e4..3728e9b 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2047,7 +2047,7 @@ that the card should have; this option currently only 
affects virtio cards; set
  @var{v} = 0 to disable MSI-X. If no @option{-net} option is specified, a 
single
  NIC is created.  QEMU can emulate several different models of network card.
  Valid values for @var{type} are
-@code{virtio}, @code{i82551}, @code{i82557b}, @code{i82559a}, @code{i82559er},
+@code{virtio}, @code{i82551}, @code{i82557b}, @code{i82559er},
  @code{ne2k_pci}, @code{ne2k_isa}, @code{pcnet}, @code{rtl8139},
  @code{e1000}, @code{smc91c111}, @code{lance} and @code{mcf_fec}.
  Not all devices are supported on all targets.  Use @code{-net nic,model=help}


Applied, thanks.

Re: [Qemu-devel] [PATCH] colo-compare: fix the dangerous assignment

[Jason Wang]

On 2017年11月16日 10:28, Mao Zhongyi wrote:

Cc: Peter Maydell 
Cc: Jason Wang 
Cc: Zhang Chen 
Cc: Li Zhijian 
Cc: Paolo Bonzini 
Fixes: 8ec14402029d783720f4312ed8a925548e1dad61
Reported-by: Peter Maydell 
Reported-by: Paolo Bonzini 
Signed-off-by: Mao Zhongyi 
---
  net/colo-compare.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/colo-compare.c b/net/colo-compare.c
index ccdcba2..1ce195f 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -179,7 +179,7 @@ static int packet_enqueue(CompareState *s, int mode, 
Connection **con)
   "drop packet");
  }
  }
-con = 
+*con = conn;
  
  return 0;

  }


Applied, thanks.

Re: [Qemu-devel] [PATCH v2] ipmi: check ibe status before ibe outlen at ipmi_bmc_extern_handle_command

[no-reply]

Hi,

This series failed build test on ppc host. Please find the details below.

Type: series
Subject: [Qemu-devel] [PATCH v2] ipmi: check ibe status before ibe outlen at 
ipmi_bmc_extern_handle_command
Message-id: 20171117020447.9776-1-caoxin...@huawei.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing to a commit that has the patches applied on top of "base"
# branch
set -e
echo "=== ENV ==="
env
echo "=== PACKAGES ==="
rpm -qa
echo "=== TEST BEGIN ==="
INSTALL=$PWD/install
BUILD=$PWD/build
mkdir -p $BUILD $INSTALL
SRC=$PWD
cd $BUILD
$SRC/configure --prefix=$INSTALL
make -j100
# XXX: we need reliable clean up
# make check -j100 V=1
make install
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] patchew/20171117020447.9776-1-caoxin...@huawei.com -> 
patchew/20171117020447.9776-1-caoxin...@huawei.com
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Submodule 'pixman' (git://anongit.freedesktop.org/pixman) registered for path 
'pixman'
Submodule 'roms/SLOF' (git://git.qemu-project.org/SLOF.git) registered for path 
'roms/SLOF'
Submodule 'roms/ipxe' (git://git.qemu-project.org/ipxe.git) registered for path 
'roms/ipxe'
Submodule 'roms/openbios' (git://git.qemu-project.org/openbios.git) registered 
for path 'roms/openbios'
Submodule 'roms/openhackware' (git://git.qemu-project.org/openhackware.git) 
registered for path 'roms/openhackware'
Submodule 'roms/qemu-palcode' (git://github.com/rth7680/qemu-palcode.git) 
registered for path 'roms/qemu-palcode'
Submodule 'roms/seabios' (git://git.qemu-project.org/seabios.git/) registered 
for path 'roms/seabios'
Submodule 'roms/sgabios' (git://git.qemu-project.org/sgabios.git) registered 
for path 'roms/sgabios'
Submodule 'roms/u-boot' (git://git.qemu-project.org/u-boot.git) registered for 
path 'roms/u-boot'
Submodule 'roms/vgabios' (git://git.qemu-project.org/vgabios.git/) registered 
for path 'roms/vgabios'
Cloning into 'dtc'...
Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf'
Cloning into 'pixman'...
Submodule path 'pixman': checked out '87eea99e443b389c978cf37efc52788bf03a0ee0'
Cloning into 'roms/SLOF'...
Submodule path 'roms/SLOF': checked out 
'e3d05727a074619fc12d0a67f05cf2c42c875cce'
Cloning into 'roms/ipxe'...
Submodule path 'roms/ipxe': checked out 
'04186319181298083ef28695a8309028b26fe83c'
Cloning into 'roms/openbios'...
Submodule path 'roms/openbios': checked out 
'e79bca64838c96ec44fd7acd508879c5284233dd'
Cloning into 'roms/openhackware'...
Submodule path 'roms/openhackware': checked out 
'c559da7c8eec5e45ef1f67978827af6f0b9546f5'
Cloning into 'roms/qemu-palcode'...
Submodule path 'roms/qemu-palcode': checked out 
'c87a92639b28ac42bc8f6c67443543b405dc479b'
Cloning into 'roms/seabios'...
Submodule path 'roms/seabios': checked out 
'e2fc41e24ee0ada60fc511d60b15a41b294538be'
Cloning into 'roms/sgabios'...
Submodule path 'roms/sgabios': checked out 
'23d474943dcd55d0550a3d20b3d30e9040a4f15b'
Cloning into 'roms/u-boot'...
Submodule path 'roms/u-boot': checked out 
'2072e7262965bb48d7fffb1e283101e6ed8b21a8'
Cloning into 'roms/vgabios'...
Submodule path 'roms/vgabios': checked out 
'19ea12c230ded95928ecaef0db47a82231c2e485'
warning: unable to rmdir pixman: Directory not empty
Switched to a new branch 'test'
M   dtc
M   roms/SLOF
M   roms/ipxe
M   roms/openbios
M   roms/qemu-palcode
M   roms/seabios
M   roms/sgabios
M   roms/u-boot
9f1c021 ipmi: check ibe status before ibe outlen at 
ipmi_bmc_extern_handle_command

=== OUTPUT BEGIN ===
=== ENV ===
XDG_SESSION_ID=36873
SHELL=/bin/sh
USER=patchew
PATCHEW=/home/patchew/patchew/patchew-cli -s http://patchew.org --nodebug
PATH=/usr/bin:/bin
PWD=/var/tmp/patchew-tester-tmp-us33sir9/src
LANG=en_US.UTF-8
HOME=/home/patchew
SHLVL=2
LOGNAME=patchew
XDG_RUNTIME_DIR=/run/user/1000
_=/usr/bin/env
=== PACKAGES ===
plymouth-core-libs-0.8.9-0.28.20140113.el7.centos.ppc64le
vim-common-7.4.160-2.el7.ppc64le
perl-Test-Simple-0.98-243.el7.noarch
hplip-common-3.15.9-3.el7.ppc64le
valgrind-3.12.0-8.el7.ppc64le
gamin-0.1.10-16.el7.ppc64le
libpeas-loader-python-1.20.0-1.el7.ppc64le
telepathy-filesystem-0.0.2-6.el7.noarch
colord-libs-1.3.4-1.el7.ppc64le
kbd-legacy-1.15.5-13.el7.noarch
perl-CPAN-Meta-YAML-0.008-14.el7.noarch
libvirt-daemon-driver-nwfilter-3.2.0-14.el7.ppc64le
ntsysv-1.7.4-1.el7.ppc64le
kernel-bootwrapper-3.10.0-693.el7.ppc64le
telepathy-farstream-0.6.0-5.el7.ppc64le
kdenetwork-common-4.10.5-8.el7_0.noarch
elfutils-devel-0.168-8.el7.ppc64le
pm-utils-1.4.1-27.el7.ppc64le
perl-Error-0.17020-2.el7.noarch
usbmuxd-1.1.0-1.el7.ppc64le
bzip2-devel-1.0.6-13.el7.ppc64le
blktrace-1.0.5-8.el7.ppc64le
gnome-keyring-pam-3.20.0-3.el7.ppc64le
tzdata-java-2017b-1.el7.noarch
perl-devel-5.16.3-292.el7.ppc64le
gnome-getting-started-docs-3.22.0-1.el7.noarch
perl-Log-Message-Simple-0.10-2.el7.noarch

Re: [Qemu-devel] [PATCH v2] ipmi: check ibe status before ibe outlen at ipmi_bmc_extern_handle_command

[no-reply]

Hi,

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

Subject: [Qemu-devel] [PATCH v2] ipmi: check ibe status before ibe outlen at 
ipmi_bmc_extern_handle_command
Type: series
Message-id: 20171117020447.9776-1-caoxin...@huawei.com

=== 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-quick@centos6
time make docker-test-build@min-glib
time make docker-test-mingw@fedora
time make docker-test-block@fedora
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
9f1c02199e ipmi: check ibe status before ibe outlen at 
ipmi_bmc_extern_handle_command

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into '/var/tmp/patchew-tester-tmp-p3n_ue0v/src/dtc'...
Submodule path 'dtc': checked out '558cd81bdd432769b59bff01240c44f82cfb1a9d'
  BUILD   centos6
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-p3n_ue0v/src'
  GEN 
/var/tmp/patchew-tester-tmp-p3n_ue0v/src/docker-src.2017-11-16-21.10.07.29546/qemu.tar
Cloning into 
'/var/tmp/patchew-tester-tmp-p3n_ue0v/src/docker-src.2017-11-16-21.10.07.29546/qemu.tar.vroot'...
done.
Checking out files:  37% (2093/5654)   
Checking out files:  38% (2149/5654)   
Checking out files:  39% (2206/5654)   
Checking out files:  40% (2262/5654)   
Checking out files:  41% (2319/5654)   
Checking out files:  42% (2375/5654)   
Checking out files:  43% (2432/5654)   
Checking out files:  44% (2488/5654)   
Checking out files:  45% (2545/5654)   
Checking out files:  46% (2601/5654)   
Checking out files:  47% (2658/5654)   
Checking out files:  48% (2714/5654)   
Checking out files:  49% (2771/5654)   
Checking out files:  50% (2827/5654)   
Checking out files:  51% (2884/5654)   
Checking out files:  52% (2941/5654)   
Checking out files:  53% (2997/5654)   
Checking out files:  54% (3054/5654)   
Checking out files:  55% (3110/5654)   
Checking out files:  56% (3167/5654)   
Checking out files:  57% (3223/5654)   
Checking out files:  58% (3280/5654)   
Checking out files:  59% (3336/5654)   
Checking out files:  60% (3393/5654)   
Checking out files:  61% (3449/5654)   
Checking out files:  62% (3506/5654)   
Checking out files:  63% (3563/5654)   
Checking out files:  64% (3619/5654)   
Checking out files:  65% (3676/5654)   
Checking out files:  66% (3732/5654)   
Checking out files:  66% (3775/5654)   
Checking out files:  67% (3789/5654)   
Checking out files:  68% (3845/5654)   
Checking out files:  69% (3902/5654)   
Checking out files:  70% (3958/5654)   
Checking out files:  71% (4015/5654)   
Checking out files:  72% (4071/5654)   
Checking out files:  73% (4128/5654)   
Checking out files:  74% (4184/5654)   
Checking out files:  75% (4241/5654)   
Checking out files:  76% (4298/5654)   
Checking out files:  77% (4354/5654)   
Checking out files:  78% (4411/5654)   
Checking out files:  79% (4467/5654)   
Checking out files:  80% (4524/5654)   
Checking out files:  81% (4580/5654)   
Checking out files:  82% (4637/5654)   
Checking out files:  83% (4693/5654)   
Checking out files:  84% (4750/5654)   
Checking out files:  85% (4806/5654)   
Checking out files:  86% (4863/5654)   
Checking out files:  87% (4919/5654)   
Checking out files:  88% (4976/5654)   
Checking out files:  89% (5033/5654)   
Checking out files:  90% (5089/5654)   
Checking out files:  91% (5146/5654)   
Checking out files:  92% (5202/5654)   
Checking out files:  93% (5259/5654)   
Checking out files:  94% (5315/5654)   
Checking out files:  95% (5372/5654)   
Checking out files:  96% (5428/5654)   
Checking out files:  97% (5485/5654)   
Checking out files:  98% (5541/5654)   
Checking out files:  99% (5598/5654)   
Checking out files: 100% (5654/5654)   
Checking out files: 100% (5654/5654), 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-p3n_ue0v/src/docker-src.2017-11-16-21.10.07.29546/qemu.tar.vroot/dtc'...
Submodule path 'dtc': checked out '558cd81bdd432769b59bff01240c44f82cfb1a9d'
Submodule 'ui/keycodemapdb' (git://git.qemu.org/keycodemapdb.git) registered 
for path 'ui/keycodemapdb'
Cloning into 
'/var/tmp/patchew-tester-tmp-p3n_ue0v/src/docker-src.2017-11-16-21.10.07.29546/qemu.tar.vroot/ui/keycodemapdb'...
Submodule path 'ui/keycodemapdb': checked out 
'10739aa26051a5d49d88132604539d3ed085e72e'
  COPYRUNNER
RUN test-quick in qemu:centos6 
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
bison-2.4.1-5.el6.x86_64
bzip2-devel-1.0.5-7.el6_0.x86_64
ccache-3.1.6-2.el6.x86_64
csnappy-devel-0-6.20150729gitd7bc683.el6.x86_64
flex-2.5.35-9.el6.x86_64
gcc-4.4.7-18.el6.x86_64
gettext-0.17-18.el6.x86_64

[Qemu-devel] [PATCH v2] ipmi: check ibe status before ibe outlen at ipmi_bmc_extern_handle_command

[xinhua.Cao]

When we always kill vm's ipmi_sim program. qemu will do handling chr_event
to reconnect ipmi_sim. handling chain is chr_event -> continue_send ->
qemu_chr_fe_write. if ipmi_sim program was killed again. then qemu_chr_fe_write
will failed. then ibe's outlen and outbuf will not cleared. so if vcpu handle
a ipmi_bmc_extern_handle_command. qemu aborted. here is backtrace.

(gdb) bt
0  0x7f3d9f4181d7 in raise () from /usr/lib64/libc.so.6
1  0x7f3d9f4198c8 in abort () from /usr/lib64/libc.so.6
2  0x00635c20 in ipmi_bmc_extern_handle_command (b=,
   cmd=0x4290198 "\030\001\004\001", cmd_len=2,
   max_cmd_len=300, msg_id=39 '\'') at hw/ipmi/ipmi_bmc_extern.c:586
3  0x00636e1d in ipmi_kcs_signal (ii=0x428fea0, ik=)
   at hw/ipmi/isa_ipmi_kcs.c:126
4  0x0047341a in memory_region_write_accessor (mr=0x428ff60, addr=0,
   value=, size=1, shift=, mask=,
   attrs=...) at /root/rpmbuild/BUILD/qemu-kvm-2.8.1/memory.c:527
5  0x0047221f in access_with_adjusted_size (addr=addr@entry=0,
   value=value@entry=0x7f3d8affc838, size=size@entry=1,
   access_size_min=, access_size_max=,
   access=access@entry=0x4733a0 ,
   mr=mr@entry=0x428ff60, attrs=attrs@entry=...)
   at /root/rpmbuild/BUILD/qemu-kvm-2.8.1/memory.c:593
6  0x00473e4d in memory_region_dispatch_write (mr=mr@entry=0x428ff60,
   addr=addr@entry=0, data=1, size=size@entry=1, attrs=attrs@entry=...) at
   /root/rpmbuild/BUILD/qemu-kvm-2.8.1/memory.c:1334
7  0x0042c2ed in address_space_write_continue (as=as@entry=0xecb400
   , addr=addr@entry=3234, attrs=..., attrs@entry=...,
   buf=buf@entry=0x7f3da59fe000 , 
len=len@entry=1,
   addr1=0, l=1, mr=0x428ff60) at 
/root/rpmbuild/BUILD/qemu-kvm-2.8.1/exec.c:2998
8  0x0042de66 in address_space_write (as=0xecb400 ,
   addr=3234, attrs=...,buf=0x7f3da59fe000 ,
   len=1) at /root/rpmbuild/BUILD/qemu-kvm-2.8.1/exec.c:3043
9  0x0042e34d in address_space_rw (as=, 
addr=addr@entry=3234,
   attrs=..., attrs@entry=..., buf=buf@entry=0x7f3da59fe000 , len=len@entry=1, is_write=is_write@entry=true)
   at /root/rpmbuild/BUILD/qemu-kvm-2.8.1/exec.c:3145
10 0x0046b751 in kvm_handle_io (port=3234, attrs=attrs@entry=...,
   data=, direction=, size=1, count=1)
   at /root/rpmbuild/BUILD/qemu-kvm-2.8.1/kvm_all.c:1822
11 0x0046f4a7 in kvm_cpu_exec (cpu=cpu@entry=0x36f3060)
   at /root/rpmbuild/BUILD/qemu-kvm-2.8.1/kvm_all.c:1980
12 0x00459cf5 in qemu_kvm_cpu_thread_fn (arg=arg@entry=0x36f3060)
   at /root/rpmbuild/BUILD/qemu-kvm-2.8.1/cpus.c:1072
13 0x00848818 in thread_entry_for_hotfix (pthread_cb=)
   at uvp/hotpatch/qemu_hotpatch_helper.c:502
14 0x7f3d9f7acdc5 in start_thread () from /usr/lib64/libpthread.so.0
15 0x7f3d9f4da6fd in clone () from /usr/lib64/libc.so.6

we check ibe status before ibe outlen at ipmi_bmc_extern_handle_command to fix 
this abort.
---
 hw/ipmi/ipmi_bmc_extern.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/hw/ipmi/ipmi_bmc_extern.c b/hw/ipmi/ipmi_bmc_extern.c
index abab3bb..02033e3 100644
--- a/hw/ipmi/ipmi_bmc_extern.c
+++ b/hw/ipmi/ipmi_bmc_extern.c
@@ -192,13 +192,6 @@ static void ipmi_bmc_extern_handle_command(IPMIBmc *b,
 uint8_t err = 0, csum;
 unsigned int i;
 
-if (ibe->outlen) {
-/* We already have a command queued.  Shouldn't ever happen. */
-fprintf(stderr, "IPMI KCS: Got command when not finished with the"
-" previous command\n");
-abort();
-}
-
 /* If it's too short or it was truncated, return an error. */
 if (cmd_len < 2) {
 err = IPMI_CC_REQUEST_DATA_LENGTH_INVALID;
@@ -206,7 +199,10 @@ static void ipmi_bmc_extern_handle_command(IPMIBmc *b,
 err = IPMI_CC_REQUEST_DATA_TRUNCATED;
 } else if (!ibe->connected) {
 err = IPMI_CC_BMC_INIT_IN_PROGRESS;
+} else if (ibe->wdt_state.trans_fail) {
+err = IPMI_CC_BMC_INIT_IN_PROGRESS;
 }
+
 if (err) {
 IPMIInterfaceClass *k = IPMI_INTERFACE_GET_CLASS(s);
 unsigned char rsp[3];
@@ -218,6 +214,13 @@ static void ipmi_bmc_extern_handle_command(IPMIBmc *b,
 goto out;
 }
 
+if (ibe->outlen) {
+/* We already have a command queued.  Shouldn't ever happen. */
+fprintf(stderr, "IPMI KCS: Got command when not finished with the"
+" previous command\n");
+abort();
+}
+
 addchar(ibe, msg_id);
 for (i = 0; i < cmd_len; i++) {
 addchar(ibe, cmd[i]);
-- 
2.8.3

Re: [Qemu-devel] [Question] why need to start all queues in vhost_net_start

[Longpeng (Mike)]

On 2017/11/16 20:04, Jason Wang wrote:

> 
> 
> On 2017年11月16日 17:32, Longpeng (Mike) wrote:
>> Hi Jason,
>>
>> On 2017/11/16 17:13, Jason Wang wrote:
>>
>>>
>>> On 2017年11月16日 17:01, Gonglei (Arei) wrote:
 No, Windows guest + vhost-user/DPDK.

 BTW pls see virtio spec in :

 "If VIRTIO_NET_F_MQ is negotiated, each of receiveq1. . .receiveqN that 
 will
 be used SHOULD be populated
 with receive buffers."

 It is not mandatory that all queues must be initialized.
>>> I think not, since it said we should fill receive buffers for each queue 
>>> which
>>> means we should initialize all queues. May Michael can clarify on this.
>>>
>>
>> I think this doesn't matter, but QEMU should consider this scenario...
>>
>> For example, if one queues isn't initialized (Windows guest), the 
>> vring.avail=0,
>> so vq->desc_phys=0, then vq->desc='a avail HVA'(which is the start addr of
>> pc.ram).
>>
>>  vq->desc_size = s = l = virtio_queue_get_desc_size(vdev, idx);
>>  vq->desc_phys = a = virtio_queue_get_desc_addr(vdev, idx);
>>  vq->desc = vhost_memory_map(dev, a, , 0);
>>  if (!vq->desc || l != s) {
>>  r = -ENOMEM;
>>  goto fail_alloc_desc;
>>  }
>>  .
>>  r = vhost_virtqueue_set_addr(dev, vq, vhost_vq_index, dev->log_enabled);
>>  if (r < 0) {
>>  r = -errno;
>>  goto fail_alloc;
>>  }
>>
>> Then the HVA is send to the vhost-user.
>>
>> I think this is wrong, because the '0' here means guest driver doesn't init 
>> this
>> queues, it should not be used to calculate the HVA for this vq.
> 
> Yes, workaround is not hard if windows driver won't use the left 3 queues any
> more. But we should have a complete solution. The main problem is when vhost
> need to be started. For legacy device, there's no easy way to detect whether 
> or
> not a specific virtqueue is ready to be used. For modern device, we can 
> probably
> do this through queue_enable (but this is not implemented in current code).
> 


Can we initialize the vring.desc/vring.avail/vring.used to -1, then we can
detect whether or not a specific vq is ready to be used by check the addr of its
tables is -1 or not ?

Initialize to 0 is not suitable, because we don't know whether the guest set GPA
0 or the guest not initialize this vq.

> Thanks
> 
>>
>>> Thanks
>>>
 Thanks,
 -Gonglei

>>>
>>>
>>>
>>> .
>>>
>>
> 
> 
> .
> 


-- 
Regards,
Longpeng(Mike)

Re: [Qemu-devel] [PATCH v8 10/14] migration: add postcopy migration of dirty bitmaps

[John Snow]

On 11/16/2017 11:50 AM, Dr. David Alan Gilbert wrote:
> * John Snow (js...@redhat.com) wrote:
>>
>>
>> On 10/30/2017 12:33 PM, Vladimir Sementsov-Ogievskiy wrote:
>>> Postcopy migration of dirty bitmaps. Only named dirty bitmaps,
>>> associated with root nodes and non-root named nodes are migrated.
>>>
>>> If destination qemu is already containing a dirty bitmap with the same name
>>> as a migrated bitmap (for the same node), then, if their granularities are
>>> the same the migration will be done, otherwise the error will be generated.
>>>
>>> If destination qemu doesn't contain such bitmap it will be created.
>>>
>>> Signed-off-by: Vladimir Sementsov-Ogievskiy 
>>> ---
>>>  include/migration/misc.h   |   3 +
>>>  migration/migration.h  |   3 +
>>>  migration/block-dirty-bitmap.c | 734 
>>> +
>>
>> Ouch :\
>>
>>>  migration/migration.c  |   3 +
>>>  migration/savevm.c |   2 +
>>>  vl.c   |   1 +
>>>  migration/Makefile.objs|   1 +
>>>  migration/trace-events |  14 +
>>>  8 files changed, 761 insertions(+)
>>>  create mode 100644 migration/block-dirty-bitmap.c
>>>
>>
>> Organizationally, you introduce three new 'public' prototypes:
>>
>> dirty_bitmap_mig_init
>> dirty_bitmap_mig_before_vm_start
>> init_dirty_bitmap_incoming_migration
>>
>> mig_init is advertised in migration/misc.h, the other two are in
>> migration/migration.h.
>> The definitions for all three are in migration/block-dirty-bitmap.c
>>
>> In pure naivety, I find it weird to have something that you use in
>> migration.c and advertised in migration.h actually exist separately in
>> block-dirty-bitmap.c; but maybe this is the sanest thing to do.
> 
> Actually I think that's OK; it makes sense for all of the code for this
> feature to sit in one place,   and there doesn't seem any point creating
> a header just for this one function.
> 

OK, just stood out to me at first. I don't really have better ideas.

>>> diff --git a/include/migration/misc.h b/include/migration/misc.h
>>> index c079b7771b..9cc539e232 100644
>>> --- a/include/migration/misc.h
>>> +++ b/include/migration/misc.h
>>> @@ -55,4 +55,7 @@ bool migration_has_failed(MigrationState *);
>>>  bool migration_in_postcopy_after_devices(MigrationState *);
>>>  void migration_global_dump(Monitor *mon);
>>>  
>>> +/* migration/block-dirty-bitmap.c */
>>> +void dirty_bitmap_mig_init(void);
>>> +
>>>  #endif
>>> diff --git a/migration/migration.h b/migration/migration.h
>>> index 50d1f01346..4e3ad04664 100644
>>> --- a/migration/migration.h
>>> +++ b/migration/migration.h
>>> @@ -211,4 +211,7 @@ void migrate_send_rp_pong(MigrationIncomingState *mis,
>>>  void migrate_send_rp_req_pages(MigrationIncomingState *mis, const char* 
>>> rbname,
>>>ram_addr_t start, size_t len);
>>>  
>>> +void dirty_bitmap_mig_before_vm_start(void);
>>> +void init_dirty_bitmap_incoming_migration(void);
>>> +
>>>  #endif
>>> diff --git a/migration/block-dirty-bitmap.c b/migration/block-dirty-bitmap.c
>>> new file mode 100644
>>> index 00..53cb20045d
>>> --- /dev/null
>>> +++ b/migration/block-dirty-bitmap.c
>>> @@ -0,0 +1,734 @@
>>> +/*
>>> + * Block dirty bitmap postcopy migration
>>> + *
>>> + * Copyright IBM, Corp. 2009
>>> + * Copyright (c) 2016-2017 Parallels International GmbH
>>> + *
>>> + * Authors:
>>> + *  Liran Schour   
>>> + *  Vladimir Sementsov-Ogievskiy 
>>> + *
>>> + * This work is licensed under the terms of the GNU GPL, version 2.  See
>>> + * the COPYING file in the top-level directory.
>>> + * This file is derived from migration/block.c, so it's author and IBM 
>>> copyright
>>> + * are here, although content is quite different.
>>> + *
>>> + * Contributions after 2012-01-13 are licensed under the terms of the
>>> + * GNU GPL, version 2 or (at your option) any later version.
>>> + *
>>> + ****
>>> + *
>>> + * Here postcopy migration of dirty bitmaps is realized. Only named dirty
>>> + * bitmaps, associated with root nodes and non-root named nodes are 
>>> migrated.
>>
>> Put another way, only QMP-addressable bitmaps. Nodes without a name that
>> are not the root have no way to be addressed.
>>
>>> + *
>>> + * If destination qemu is already containing a dirty bitmap with the same 
>>> name
>>
>> "If the destination QEMU already contains a dirty bitmap with the same name"
>>
>>> + * as a migrated bitmap (for the same node), then, if their granularities 
>>> are
>>> + * the same the migration will be done, otherwise the error will be 
>>> generated.
>>
>> "an error"
>>
>>> + *
>>> + * If destination qemu doesn't contain such bitmap it will be created.
>>
>> "If the destination QEMU doesn't contain such a bitmap, it will be created."
>>
>>> + *
>>> + * format of migration:
>>> + *
>>> + * # Header (shared for different chunk types)
>>> + * 1, 2 or 

Re: [Qemu-devel] [PATCH] colo-compare: fix the dangerous assignment

[Mao Zhongyi]

On 11/17/2017 04:07 AM, Stefan Weil wrote:

Am 16.11.2017 um 03:28 schrieb Mao Zhongyi:

Cc: Peter Maydell 
Cc: Jason Wang 
Cc: Zhang Chen 
Cc: Li Zhijian 
Cc: Paolo Bonzini 
Fixes: 8ec14402029d783720f4312ed8a925548e1dad61
Reported-by: Peter Maydell 
Reported-by: Paolo Bonzini 
Signed-off-by: Mao Zhongyi 
---
 net/colo-compare.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/colo-compare.c b/net/colo-compare.c
index ccdcba2..1ce195f 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -179,7 +179,7 @@ static int packet_enqueue(CompareState *s, int mode, 
Connection **con)
  "drop packet");
 }
 }
-con = 
+*con = conn;

 return 0;
 }


Hi, Stefan


The patch is definitely needed if the new function parameter con
should work.

It also fixes a gcc compiler warning:
net/colo-compare.c:139:67: warning: parameter ‘con’ set but not used
[-Wunused-but-set-parameter]

I‌ think using -Wextra would be really good to catch such bugs earlier.


Thanks a bunch. I got it. :)

Mao

Re: [Qemu-devel] [PATCH v8 10/14] migration: add postcopy migration of dirty bitmaps

[John Snow]

On 11/16/2017 05:24 AM, Vladimir Sementsov-Ogievskiy wrote:
> 15.11.2017 04:58, John Snow wrote:
>>
>> On 10/30/2017 12:33 PM, Vladimir Sementsov-Ogievskiy wrote:
>>> Postcopy migration of dirty bitmaps. Only named dirty bitmaps,
>>> associated with root nodes and non-root named nodes are migrated.
>>>
>>> If destination qemu is already containing a dirty bitmap with the
>>> same name
>>> as a migrated bitmap (for the same node), then, if their
>>> granularities are
>>> the same the migration will be done, otherwise the error will be
>>> generated.
>>>
>>> If destination qemu doesn't contain such bitmap it will be created.
>>>
>>> Signed-off-by: Vladimir Sementsov-Ogievskiy 
>>> ---
>>>   include/migration/misc.h   |   3 +
>>>   migration/migration.h  |   3 +
>>>   migration/block-dirty-bitmap.c | 734
>>> +
>> Ouch :\
>>
>>>   migration/migration.c  |   3 +
>>>   migration/savevm.c |   2 +
>>>   vl.c   |   1 +
>>>   migration/Makefile.objs    |   1 +
>>>   migration/trace-events |  14 +
>>>   8 files changed, 761 insertions(+)
>>>   create mode 100644 migration/block-dirty-bitmap.c
>>>
>> Organizationally, you introduce three new 'public' prototypes:
>>
>> dirty_bitmap_mig_init
>> dirty_bitmap_mig_before_vm_start
>> init_dirty_bitmap_incoming_migration
>>
>> mig_init is advertised in migration/misc.h, the other two are in
>> migration/migration.h.
>> The definitions for all three are in migration/block-dirty-bitmap.c
>>
>> In pure naivety, I find it weird to have something that you use in
>> migration.c and advertised in migration.h actually exist separately in
>> block-dirty-bitmap.c; but maybe this is the sanest thing to do.
>>
>>> diff --git a/include/migration/misc.h b/include/migration/misc.h
>>> index c079b7771b..9cc539e232 100644
>>> --- a/include/migration/misc.h
>>> +++ b/include/migration/misc.h
>>> @@ -55,4 +55,7 @@ bool migration_has_failed(MigrationState *);
>>>   bool migration_in_postcopy_after_devices(MigrationState *);
>>>   void migration_global_dump(Monitor *mon);
>>>   +/* migration/block-dirty-bitmap.c */
>>> +void dirty_bitmap_mig_init(void);
>>> +
>>>   #endif
>>> diff --git a/migration/migration.h b/migration/migration.h
>>> index 50d1f01346..4e3ad04664 100644
>>> --- a/migration/migration.h
>>> +++ b/migration/migration.h
>>> @@ -211,4 +211,7 @@ void migrate_send_rp_pong(MigrationIncomingState
>>> *mis,
>>>   void migrate_send_rp_req_pages(MigrationIncomingState *mis, const
>>> char* rbname,
>>>     ram_addr_t start, size_t len);
>>>   +void dirty_bitmap_mig_before_vm_start(void);
>>> +void init_dirty_bitmap_incoming_migration(void);
>>> +
>>>   #endif
>>> diff --git a/migration/block-dirty-bitmap.c
>>> b/migration/block-dirty-bitmap.c
>>> new file mode 100644
>>> index 00..53cb20045d
>>> --- /dev/null
>>> +++ b/migration/block-dirty-bitmap.c
>>> @@ -0,0 +1,734 @@
>>> +/*
>>> + * Block dirty bitmap postcopy migration
>>> + *
>>> + * Copyright IBM, Corp. 2009
>>> + * Copyright (c) 2016-2017 Parallels International GmbH
>>> + *
>>> + * Authors:
>>> + *  Liran Schour   
>>> + *  Vladimir Sementsov-Ogievskiy 
>>> + *
>>> + * This work is licensed under the terms of the GNU GPL, version 2. 
>>> See
>>> + * the COPYING file in the top-level directory.
>>> + * This file is derived from migration/block.c, so it's author and
>>> IBM copyright
>>> + * are here, although content is quite different.
>>> + *
>>> + * Contributions after 2012-01-13 are licensed under the terms of the
>>> + * GNU GPL, version 2 or (at your option) any later version.
>>> + *
>>> + *    ***
>>> + *
>>> + * Here postcopy migration of dirty bitmaps is realized. Only named
>>> dirty
>>> + * bitmaps, associated with root nodes and non-root named nodes are
>>> migrated.
>> Put another way, only QMP-addressable bitmaps. Nodes without a name that
>> are not the root have no way to be addressed.
>>
>>> + *
>>> + * If destination qemu is already containing a dirty bitmap with the
>>> same name
>> "If the destination QEMU already contains a dirty bitmap with the same
>> name"
>>
>>> + * as a migrated bitmap (for the same node), then, if their
>>> granularities are
>>> + * the same the migration will be done, otherwise the error will be
>>> generated.
>> "an error"
>>
>>> + *
>>> + * If destination qemu doesn't contain such bitmap it will be created.
>> "If the destination QEMU doesn't contain such a bitmap, it will be
>> created."
>>
>>> + *
>>> + * format of migration:
>>> + *
>>> + * # Header (shared for different chunk types)
>>> + * 1, 2 or 4 bytes: flags (see qemu_{put,put}_flags)
>>> + * [ 1 byte: node name size ] \  flags & DEVICE_NAME
>>> + * [ n bytes: node name ] /
>>> + * [ 1 byte: bitmap name size ] \  flags & BITMAP_NAME
>>> + * [ n bytes: bitmap name ] /
>>> + *

[Qemu-devel] [QEMU-PPC] [PATCH V2] target/ppc: Update setting of cpu features to account for compat modes

[Suraj Jitindar Singh]

The device tree nodes ibm,arch-vec-5-platform-support and ibm,pa-features
are used to communicate features of the cpu to the guest operating
system. The properties of each of these are determined based on the
selected cpu model and the availability of hypervisor features.
Currently the compatibility mode of the cpu is not taken into account.

The ibm,arch-vec-5-platform-support node is used to communicate the
level of support for various ISAv3 processor features to the guest
before CAS to inform the guests' request. The available mmu mode should
only be hash unless the cpu is a POWER9 which is not in a prePOWER9
compat mode, in which case the available modes depend on the
accelerator and the hypervisor capabilities.

The ibm,pa-featues node is used to communicate the level of cpu support
for various features to the guest os. This should only contain features
relevant to the operating mode of the processor, that is the selected
cpu model taking into account any compat mode. This means that the
compat mode should be taken into account when choosing the properties of
ibm,pa-features and they should match the compat mode selected, or the
cpu model selected if no compat mode.

Update the setting of these cpu features in the device tree as described
above to properly take into account any compat mode.

Signed-off-by: Suraj Jitindar Singh 

---

V1 -> V2:
- Pass cpu pointer to spapr_populate_pa_features to avoid extracting it
  back out from env
- Slight reword of spapr_dt_ov5_platform_support logic to avoid
  duplicate case
---
 hw/ppc/spapr.c | 48 +---
 1 file changed, 37 insertions(+), 11 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index d682f01..480484a 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -44,6 +44,7 @@
 #include "migration/register.h"
 #include "mmu-hash64.h"
 #include "mmu-book3s-v3.h"
+#include "cpu-models.h"
 #include "qom/cpu.h"
 
 #include "hw/boards.h"
@@ -252,9 +253,10 @@ static int spapr_fixup_cpu_numa_dt(void *fdt, int offset, 
PowerPCCPU *cpu)
 }
 
 /* Populate the "ibm,pa-features" property */
-static void spapr_populate_pa_features(CPUPPCState *env, void *fdt, int offset,
-  bool legacy_guest)
+static void spapr_populate_pa_features(PowerPCCPU *cpu, void *fdt, int offset,
+   bool legacy_guest)
 {
+CPUPPCState *env = >env;
 uint8_t pa_features_206[] = { 6, 0,
 0xf6, 0x1f, 0xc7, 0x00, 0x80, 0xc0 };
 uint8_t pa_features_207[] = { 24, 0,
@@ -290,16 +292,36 @@ static void spapr_populate_pa_features(CPUPPCState *env, 
void *fdt, int offset,
 uint8_t *pa_features;
 size_t pa_size;
 
-switch (POWERPC_MMU_VER(env->mmu_model)) {
-case POWERPC_MMU_VER_2_06:
+switch (cpu->compat_pvr) {
+case 0:
+/* If not in a compat mode then determine based on the mmu model */
+switch (POWERPC_MMU_VER(env->mmu_model)) {
+case POWERPC_MMU_VER_2_06:
+pa_features = pa_features_206;
+pa_size = sizeof(pa_features_206);
+break;
+case POWERPC_MMU_VER_2_07:
+pa_features = pa_features_207;
+pa_size = sizeof(pa_features_207);
+break;
+case POWERPC_MMU_VER_3_00:
+pa_features = pa_features_300;
+pa_size = sizeof(pa_features_300);
+break;
+default:
+return;
+}
+break;
+case CPU_POWERPC_LOGICAL_2_06:
+case CPU_POWERPC_LOGICAL_2_06_PLUS:
 pa_features = pa_features_206;
 pa_size = sizeof(pa_features_206);
 break;
-case POWERPC_MMU_VER_2_07:
+case CPU_POWERPC_LOGICAL_2_07:
 pa_features = pa_features_207;
 pa_size = sizeof(pa_features_207);
 break;
-case POWERPC_MMU_VER_3_00:
+case CPU_POWERPC_LOGICAL_3_00:
 pa_features = pa_features_300;
 pa_size = sizeof(pa_features_300);
 break;
@@ -340,7 +362,6 @@ static int spapr_fixup_cpu_dt(void *fdt, sPAPRMachineState 
*spapr)
 
 CPU_FOREACH(cs) {
 PowerPCCPU *cpu = POWERPC_CPU(cs);
-CPUPPCState *env = >env;
 DeviceClass *dc = DEVICE_GET_CLASS(cs);
 int index = spapr_vcpu_id(cpu);
 int compat_smt = MIN(smp_threads, ppc_compat_max_threads(cpu));
@@ -384,7 +405,7 @@ static int spapr_fixup_cpu_dt(void *fdt, sPAPRMachineState 
*spapr)
 return ret;
 }
 
-spapr_populate_pa_features(env, fdt, offset,
+spapr_populate_pa_features(cpu, fdt, offset,
  spapr->cas_legacy_guest_workaround);
 }
 return ret;
@@ -579,7 +600,7 @@ static void spapr_populate_cpu_dt(CPUState *cs, void *fdt, 
int offset,
   page_sizes_prop, page_sizes_prop_size)));
 }
 
-spapr_populate_pa_features(env, fdt, offset, false);
+spapr_populate_pa_features(cpu, fdt, offset, false);
 
 

Re: [Qemu-devel] [PATCH v8 10/14] migration: add postcopy migration of dirty bitmaps

[John Snow]

On 11/16/2017 05:24 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> +    /* if a block is zero we need to flush here since the network
>>> + * bandwidth is now a lot higher than the storage device bandwidth.
>>> + * thus if we queue zero blocks we slow down the migration. */
>> Can you elaborate on this for me?
> 
> it comes from migration/block.c, as it was a prototype for dirty bitmaps
> migration.
> May be the original thought was to give destination storage more time to
> handle
> write-zeros? It may make sense if it can't do it fast but really writes
> zeros.
> 
>>
>>> +    if (flags & DIRTY_BITMAP_MIG_FLAG_ZEROES) {
>>> +    qemu_fflush(f);
>>> +    } else {
>>> +    qemu_put_be64(f, buf_size);
>>> +    qemu_put_buffer(f, buf, buf_size);
>>> +    }
>>> +
>>> +    g_free(buf);
>>> +} 

Peter, Stefan; do you have any insight on the reason for this blurb's
appearance in migration/block.c? Looks like it showed up in
323004a39d4d8d33c744a5b108f80bfe6402fca3

I'm not sure I understand what the concern was that lead to this, unless
it's simply that without a flush() we can't guarantee progress.

Re: [Qemu-devel] [Qemu-ppc] [QEMU-PPC] [PATCH] target/ppc: Update setting of cpu features to account for compat modes

[Suraj Jitindar Singh]

On Thu, 2017-11-16 at 19:24 +0100, Greg Kurz wrote:
> On Thu, 16 Nov 2017 15:16:07 +1100
> Suraj Jitindar Singh  wrote:
> 
> > The device tree nodes ibm,arch-vec-5-platform-support and ibm,pa-
> > features
> > are used to communicate features of the cpu to the guest operating
> > system. The properties of each of these are determined based on the
> > selected cpu model and the availability of hypervisor features.
> > Currently the compatibility mode of the cpu is not taken into
> > account.
> > 
> > The ibm,arch-vec-5-platform-support node is used to communicate the
> > level of support for various ISAv3 processor features to the guest
> > before CAS to inform the guests' request. The available mmu mode
> > should
> > only be hash unless the cpu is a POWER9 which is not in a prePOWER9
> > compat mode, in which case the available modes depend on the
> > accelerator and the hypervisor capabilities.
> > 
> > The ibm,pa-featues node is used to communicate the level of cpu
> > support
> > for various features to the guest os. This should only contain
> > features
> > relevant to the operating mode of the processor, that is the
> > selected
> > cpu model taking into account any compat mode. This means that the
> > compat mode should be taken into account when choosing the
> > properties of
> > ibm,pa-features and they should match the compat mode selected, or
> > the
> > cpu model selected if no compat mode.
> > 
> > Update the setting of these cpu features in the device tree as
> > described
> > above to properly take into account any compat mode.
> > 
> > Signed-off-by: Suraj Jitindar Singh 
> > ---
> >  hw/ppc/spapr.c | 38 +-
> >  1 file changed, 33 insertions(+), 5 deletions(-)
> > 
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index d682f01..0dab6f1 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -44,6 +44,7 @@
> >  #include "migration/register.h"
> >  #include "mmu-hash64.h"
> >  #include "mmu-book3s-v3.h"
> > +#include "cpu-models.h"
> >  #include "qom/cpu.h"
> >  
> >  #include "hw/boards.h"
> > @@ -255,6 +256,7 @@ static int spapr_fixup_cpu_numa_dt(void *fdt,
> > int offset, PowerPCCPU *cpu)
> >  static void spapr_populate_pa_features(CPUPPCState *env, void
> > *fdt, int offset,
> >    bool legacy_guest)
> >  {
> > +PowerPCCPU *cpu = ppc_env_get_cpu(env);
> 
> If spapr_populate_pa_features() now needs to peek into PowerPCCPU,
> then it
> should be passed a PowerPCCPU * instead of doing container_of()
> contorsions.
> Both callers, spapr_fixup_cpu_dt() and spapr_populate_cpu_dt() can do
> that.

Good point :)

> 
> >  uint8_t pa_features_206[] = { 6, 0,
> >  0xf6, 0x1f, 0xc7, 0x00, 0x80, 0xc0 };
> >  uint8_t pa_features_207[] = { 24, 0,
> > @@ -290,16 +292,36 @@ static void
> > spapr_populate_pa_features(CPUPPCState *env, void *fdt, int offset,
> >  uint8_t *pa_features;
> >  size_t pa_size;
> >  
> > -switch (POWERPC_MMU_VER(env->mmu_model)) {
> > -case POWERPC_MMU_VER_2_06:
> > +switch (cpu->compat_pvr) {
> > +case 0:
> > +/* If not in a compat mode then determine based on the mmu
> > model */
> > +switch (POWERPC_MMU_VER(env->mmu_model)) {
> > +case POWERPC_MMU_VER_2_06:
> > +pa_features = pa_features_206;
> > +pa_size = sizeof(pa_features_206);
> > +break;
> > +case POWERPC_MMU_VER_2_07:
> > +pa_features = pa_features_207;
> > +pa_size = sizeof(pa_features_207);
> > +break;
> > +case POWERPC_MMU_VER_3_00:
> > +pa_features = pa_features_300;
> > +pa_size = sizeof(pa_features_300);
> > +break;
> > +default:
> > +return;
> > +}
> > +break;
> > +case CPU_POWERPC_LOGICAL_2_06:
> > +case CPU_POWERPC_LOGICAL_2_06_PLUS:
> >  pa_features = pa_features_206;
> >  pa_size = sizeof(pa_features_206);
> >  break;
> > -case POWERPC_MMU_VER_2_07:
> > +case CPU_POWERPC_LOGICAL_2_07:
> >  pa_features = pa_features_207;
> >  pa_size = sizeof(pa_features_207);
> >  break;
> > -case POWERPC_MMU_VER_3_00:
> > +case CPU_POWERPC_LOGICAL_3_00:
> >  pa_features = pa_features_300;
> >  pa_size = sizeof(pa_features_300);
> >  break;
> > @@ -941,6 +963,7 @@ static void spapr_dt_rtas(sPAPRMachineState
> > *spapr, void *fdt)
> >  static void spapr_dt_ov5_platform_support(void *fdt, int chosen)
> >  {
> >  PowerPCCPU *first_ppc_cpu = POWERPC_CPU(first_cpu);
> > +CPUPPCState *env = _ppc_cpu->env;
> >  
> >  char val[2 * 4] = {
> >  23, 0x00, /* Xive mode, filled in below. */
> > @@ -949,7 +972,12 @@ static void spapr_dt_ov5_platform_support(void
> > *fdt, int chosen)
> >  26, 0x40, /* Radix options: GTSE == yes. */
> >  };
> >  
> > -

Re: [Qemu-devel] [PATCH] ipmi: check ibe status before ibe outlen at ipmi_bmc_extern_handle_command

[no-reply]

Hi,

This series failed build test on s390x host. Please find the details below.

Type: series
Message-id: 20171116052511.16236-1-caoxin...@huawei.com
Subject: [Qemu-devel] [PATCH] ipmi: check ibe status before ibe outlen at 
ipmi_bmc_extern_handle_command

=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing to a commit that has the patches applied on top of "base"
# branch
set -e
echo "=== ENV ==="
env
echo "=== PACKAGES ==="
rpm -qa
echo "=== TEST BEGIN ==="
CC=$HOME/bin/cc
INSTALL=$PWD/install
BUILD=$PWD/build
echo -n "Using CC: "
realpath $CC
mkdir -p $BUILD $INSTALL
SRC=$PWD
cd $BUILD
$SRC/configure --cc=$CC --prefix=$INSTALL
make -j4
# XXX: we need reliable clean up
# make check -j4 V=1
make install
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] patchew/20171116052511.16236-1-caoxin...@huawei.com -> 
patchew/20171116052511.16236-1-caoxin...@huawei.com
Switched to a new branch 'test'
b2364de ipmi: check ibe status before ibe outlen at 
ipmi_bmc_extern_handle_command

=== OUTPUT BEGIN ===
=== ENV ===
XDG_SESSION_ID=94641
SHELL=/bin/sh
USER=fam
PATCHEW=/home/fam/patchew/patchew-cli -s http://patchew.org --nodebug
PATH=/usr/bin:/bin
PWD=/var/tmp/patchew-tester-tmp-jr31nldz/src
LANG=en_US.UTF-8
HOME=/home/fam
SHLVL=2
LOGNAME=fam
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1012/bus
XDG_RUNTIME_DIR=/run/user/1012
_=/usr/bin/env
=== PACKAGES ===
gpg-pubkey-873529b8-54e386ff
xz-libs-5.2.2-2.fc24.s390x
libxshmfence-1.2-3.fc24.s390x
giflib-4.1.6-15.fc24.s390x
trousers-lib-0.3.13-6.fc24.s390x
ncurses-base-6.0-6.20160709.fc25.noarch
gmp-6.1.1-1.fc25.s390x
libidn-1.33-1.fc25.s390x
slang-2.3.0-7.fc25.s390x
pkgconfig-0.29.1-1.fc25.s390x
alsa-lib-1.1.1-2.fc25.s390x
yum-metadata-parser-1.1.4-17.fc25.s390x
python3-slip-dbus-0.6.4-4.fc25.noarch
python2-cssselect-0.9.2-1.fc25.noarch
createrepo_c-libs-0.10.0-6.fc25.s390x
initscripts-9.69-1.fc25.s390x
parted-3.2-21.fc25.s390x
flex-2.6.0-3.fc25.s390x
colord-libs-1.3.4-1.fc25.s390x
python-osbs-client-0.33-3.fc25.noarch
perl-Pod-Simple-3.35-1.fc25.noarch
python2-simplejson-3.10.0-1.fc25.s390x
brltty-5.4-2.fc25.s390x
librados2-10.2.4-2.fc25.s390x
tcp_wrappers-7.6-83.fc25.s390x
libcephfs_jni1-10.2.4-2.fc25.s390x
nettle-devel-3.3-1.fc25.s390x
bzip2-devel-1.0.6-21.fc25.s390x
libuuid-2.28.2-2.fc25.s390x
python3-dnf-1.1.10-6.fc25.noarch
texlive-kpathsea-doc-svn41139-33.fc25.1.noarch
openssh-7.4p1-4.fc25.s390x
texlive-kpathsea-bin-svn40473-33.20160520.fc25.1.s390x
texlive-graphics-svn41015-33.fc25.1.noarch
texlive-dvipdfmx-def-svn40328-33.fc25.1.noarch
texlive-mfware-svn40768-33.fc25.1.noarch
texlive-texlive-scripts-svn41433-33.fc25.1.noarch
texlive-euro-svn22191.1.1-33.fc25.1.noarch
texlive-etex-svn37057.0-33.fc25.1.noarch
texlive-iftex-svn29654.0.2-33.fc25.1.noarch
texlive-palatino-svn31835.0-33.fc25.1.noarch
texlive-texlive-docindex-svn41430-33.fc25.1.noarch
texlive-xunicode-svn30466.0.981-33.fc25.1.noarch
texlive-koma-script-svn41508-33.fc25.1.noarch
texlive-pst-grad-svn15878.1.06-33.fc25.1.noarch
texlive-pst-blur-svn15878.2.0-33.fc25.1.noarch
texlive-jknapltx-svn19440.0-33.fc25.1.noarch
texinfo-6.1-4.fc25.s390x
openssl-devel-1.0.2k-1.fc25.s390x
jansson-2.10-2.fc25.s390x
fedora-repos-25-4.noarch
perl-Errno-1.25-387.fc25.s390x
acl-2.2.52-13.fc25.s390x
systemd-pam-231-17.fc25.s390x
NetworkManager-libnm-1.4.4-5.fc25.s390x
poppler-0.45.0-5.fc25.s390x
ccache-3.3.4-1.fc25.s390x
valgrind-3.12.0-9.fc25.s390x
perl-open-1.10-387.fc25.noarch
libgcc-6.4.1-1.fc25.s390x
libsoup-2.56.1-1.fc25.s390x
libstdc++-devel-6.4.1-1.fc25.s390x
libobjc-6.4.1-1.fc25.s390x
python2-rpm-4.13.0.1-2.fc25.s390x
python2-gluster-3.10.5-1.fc25.s390x
rpm-build-4.13.0.1-2.fc25.s390x
glibc-static-2.24-10.fc25.s390x
lz4-1.8.0-1.fc25.s390x
xapian-core-libs-1.2.24-1.fc25.s390x
elfutils-libelf-devel-0.169-1.fc25.s390x
nss-softokn-3.32.0-1.2.fc25.s390x
pango-1.40.9-1.fc25.s390x
glibc-debuginfo-common-2.24-10.fc25.s390x
libaio-0.3.110-6.fc24.s390x
libfontenc-1.1.3-3.fc24.s390x
lzo-2.08-8.fc24.s390x
isl-0.14-5.fc24.s390x
libXau-1.0.8-6.fc24.s390x
linux-atm-libs-2.5.1-14.fc24.s390x
libXext-1.3.3-4.fc24.s390x
libXxf86vm-1.1.4-3.fc24.s390x
bison-3.0.4-4.fc24.s390x
perl-srpm-macros-1-20.fc25.noarch
gawk-4.1.3-8.fc25.s390x
libwayland-client-1.12.0-1.fc25.s390x
perl-Exporter-5.72-366.fc25.noarch
perl-version-0.99.17-1.fc25.s390x
fftw-libs-double-3.3.5-3.fc25.s390x
libssh2-1.8.0-1.fc25.s390x
ModemManager-glib-1.6.4-1.fc25.s390x
newt-python3-0.52.19-2.fc25.s390x
python-munch-2.0.4-3.fc25.noarch
python-bugzilla-1.2.2-4.fc25.noarch
libedit-3.1-16.20160618cvs.fc25.s390x
createrepo_c-0.10.0-6.fc25.s390x
device-mapper-multipath-libs-0.4.9-83.fc25.s390x
yum-3.4.3-510.fc25.noarch
mozjs17-17.0.0-16.fc25.s390x
libselinux-2.5-13.fc25.s390x
python2-pyparsing-2.1.10-1.fc25.noarch
cairo-gobject-1.14.8-1.fc25.s390x
xorg-x11-proto-devel-7.7-20.fc25.noarch
brlapi-0.6.5-2.fc25.s390x

[Qemu-devel] [PATCH v3 2/2] tests/qemu-iotests: adding savevm/loadvm with postcopy flag test

[Daniel Henrique Barboza]

This patch implements a test case for the scenario that was failing
prior to the patch "migration/ram.c: do not set 'postcopy_running' in
POSTCOPY_INCOMING_END".

This new test file 198 was derived from the test file 181 authored
by Kevin Wolf.

CC: Kevin Wolf 
CC: Max Reitz 
CC: Cleber Rosa 
Signed-off-by: Daniel Henrique Barboza 

---
I CCed Cleber Rosa because this patch was developed at the same
time his patch series "[PATCH 00/10] I/O tests cleanups" hit the
mailing list. Most of the cleanups/fixes he made in the series was
done in this new test as well.

 tests/qemu-iotests/198 | 110 +
 tests/qemu-iotests/198.out |  20 +
 tests/qemu-iotests/group   |   1 +
 3 files changed, 131 insertions(+)
 create mode 100755 tests/qemu-iotests/198
 create mode 100644 tests/qemu-iotests/198.out

diff --git a/tests/qemu-iotests/198 b/tests/qemu-iotests/198
new file mode 100755
index 00..786e37fc95
--- /dev/null
+++ b/tests/qemu-iotests/198
@@ -0,0 +1,110 @@
+#!/bin/bash
+#
+# Test savevm and loadvm after live migration with postcopy flag
+#
+# Copyright (C) 2017, IBM Corporation.
+#
+# This file is derived from tests/qemu-iotests/181 by Kevin Wolf
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+#
+# Creator/Owner : danie...@linux.vnet.ibm.com
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+status=1   # failure is the default!
+
+MIG_SOCKET="${TEST_DIR}/migrate"
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+. ./common.qemu
+
+_cleanup()
+{
+rm -f "${MIG_SOCKET}"
+_cleanup_test_img
+_cleanup_qemu
+}
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+_supported_fmt qcow2
+_supported_proto generic
+_supported_os Linux
+
+size=64M
+_make_test_img $size
+
+echo
+echo === Starting VMs ===
+echo
+
+qemu_comm_method="monitor"
+
+if [ "$IMGOPTSSYNTAX" = "true" ]; then
+_launch_qemu \
+-drive "${TEST_IMG}",cache=${CACHEMODE},id=disk
+else
+_launch_qemu \
+-drive file="${TEST_IMG}",cache=${CACHEMODE},driver=$IMGFMT,id=disk
+fi
+src=$QEMU_HANDLE
+
+if [ "$IMGOPTSSYNTAX" = "true" ]; then
+_launch_qemu \
+-drive "${TEST_IMG}",cache=${CACHEMODE},id=disk \
+-incoming "unix:${MIG_SOCKET}"
+else
+_launch_qemu \
+-drive file="${TEST_IMG}",cache=${CACHEMODE},driver=$IMGFMT,id=disk \
+-incoming "unix:${MIG_SOCKET}"
+fi
+dest=$QEMU_HANDLE
+
+echo
+echo === Set \'migrate_set_capability postcopy-ram on\' and migrate ===
+echo
+
+silent=yes
+_send_qemu_cmd $dest 'migrate_set_capability postcopy-ram on' "(qemu)"
+_send_qemu_cmd $src 'migrate_set_capability postcopy-ram on' "(qemu)"
+_send_qemu_cmd $src "migrate -d unix:${MIG_SOCKET}" "(qemu)"
+
+QEMU_COMM_TIMEOUT=1 qemu_cmd_repeat=10 silent=yes \
+_send_qemu_cmd $src "info migrate" "completed\|failed"
+silent=yes _send_qemu_cmd $src "" "(qemu)"
+
+echo
+echo === On destination, execute savevm and loadvm ===
+echo
+
+silent=
+_send_qemu_cmd $dest 'savevm state1"' "(qemu)"
+_send_qemu_cmd $dest 'loadvm state1"' "(qemu)"
+
+echo
+echo === Shut down and check image ===
+echo
+
+_send_qemu_cmd $src 'quit' ""
+_send_qemu_cmd $dest 'quit' ""
+wait=1 _cleanup_qemu
+
+_check_test_img
+
+# success, all done
+echo "*** done"
+status=0
diff --git a/tests/qemu-iotests/198.out b/tests/qemu-iotests/198.out
new file mode 100644
index 00..6c27303857
--- /dev/null
+++ b/tests/qemu-iotests/198.out
@@ -0,0 +1,20 @@
+QA output created by 198
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864
+
+=== Starting VMs ===
+
+
+=== Set 'migrate_set_capability postcopy-ram on' and migrate ===
+
+
+=== On destination, execute savevm and loadvm ===
+
+(qemu) savevm state1"
+(qemu) loadvm state1"
+
+=== Shut down and check image ===
+
+(qemu) quit
+(qemu) quit
+No errors were found on the image.
+*** done
diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index 24e5ad1b79..84d082bc38 100644
--- a/tests/qemu-iotests/group
+++ b/tests/qemu-iotests/group
@@ -194,3 +194,4 @@
 194 rw auto migration quick
 195 rw auto quick
 197 rw auto quick
+198 rw auto migration
-- 
2.13.6

[Qemu-devel] [PATCH v3 1/2] migration/ram.c: do not set 'postcopy_running' in POSTCOPY_INCOMING_END

[Daniel Henrique Barboza]

When migrating a VM with 'migrate_set_capability postcopy-ram on'
a postcopy_state is set during the process, ending up with the
state POSTCOPY_INCOMING_END when the migration is over. This
postcopy_state is taken into account inside ram_load to check
how it will load the memory pages. This same ram_load is called when
in a loadvm command.

Inside ram_load, the logic to see if we're at postcopy_running state
is:

postcopy_running = postcopy_state_get() >= POSTCOPY_INCOMING_LISTENING

postcopy_state_get() returns this enum type:

typedef enum {
POSTCOPY_INCOMING_NONE = 0,
POSTCOPY_INCOMING_ADVISE,
POSTCOPY_INCOMING_DISCARD,
POSTCOPY_INCOMING_LISTENING,
POSTCOPY_INCOMING_RUNNING,
POSTCOPY_INCOMING_END
} PostcopyState;

In the case where ram_load is executed and postcopy_state is
POSTCOPY_INCOMING_END, postcopy_running will be set to 'true' and
ram_load will behave like a postcopy is in progress. This scenario isn't
achievable in a migration but it is reproducible when executing
savevm/loadvm after migrating with 'postcopy-ram on', causing loadvm
to fail with Error -22:

Source:

(qemu) migrate_set_capability postcopy-ram on
(qemu) migrate tcp:127.0.0.1:

Dest:

(qemu) migrate_set_capability postcopy-ram on
(qemu)
ubuntu1704-intel login:
Ubuntu 17.04 ubuntu1704-intel ttyS0

ubuntu1704-intel login: (qemu)
(qemu) savevm test1
(qemu) loadvm test1
Unknown combination of migration flags: 0x4 (postcopy mode)
error while loading state for instance 0x0 of device 'ram'
Error -22 while loading VM state
(qemu)

This patch fixes this problem by changing the existing logic for
postcopy_advised and postcopy_running in ram_load, making them
'false' if we're at POSTCOPY_INCOMING_END state.

Signed-off-by: Daniel Henrique Barboza 
CC: Juan Quintela 
CC: Dr. David Alan Gilbert 
Reviewed-by: Peter Xu 
Reported-by: Balamuruhan S 
---
 migration/ram.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 8620aa400a..021d583b9b 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -2798,6 +2798,18 @@ static int ram_load_postcopy(QEMUFile *f)
 return ret;
 }
 
+static bool postcopy_is_advised(void)
+{
+PostcopyState ps = postcopy_state_get();
+return ps >= POSTCOPY_INCOMING_ADVISE && ps < POSTCOPY_INCOMING_END;
+}
+
+static bool postcopy_is_running(void)
+{
+PostcopyState ps = postcopy_state_get();
+return ps >= POSTCOPY_INCOMING_LISTENING && ps < POSTCOPY_INCOMING_END;
+}
+
 static int ram_load(QEMUFile *f, void *opaque, int version_id)
 {
 int flags = 0, ret = 0, invalid_flags = 0;
@@ -2807,9 +2819,9 @@ static int ram_load(QEMUFile *f, void *opaque, int 
version_id)
  * If system is running in postcopy mode, page inserts to host memory must
  * be atomic
  */
-bool postcopy_running = postcopy_state_get() >= 
POSTCOPY_INCOMING_LISTENING;
+bool postcopy_running = postcopy_is_running();
 /* ADVISE is earlier, it shows the source has the postcopy capability on */
-bool postcopy_advised = postcopy_state_get() >= POSTCOPY_INCOMING_ADVISE;
+bool postcopy_advised = postcopy_is_advised();
 
 seq_iter++;
 
-- 
2.13.6

[Qemu-devel] [PATCH v3 0/2] Fix savevm/loadvm after postcopy migration

[Daniel Henrique Barboza]

v3:
- patch 1: added 'Reported-by' info in the commit msg. No code
changes were made.
- patch 2 *new*: a new qemu-iotest that verifies the behavior
fixed in patch1.

v2:
- added helper functions to simplify the code

Daniel Henrique Barboza (2):
  migration/ram.c: do not set 'postcopy_running' in
POSTCOPY_INCOMING_END
  tests/qemu-iotests: adding savevm/loadvm with postcopy flag test

 migration/ram.c|  16 ++-
 tests/qemu-iotests/198 | 110 +
 tests/qemu-iotests/198.out |  20 +
 tests/qemu-iotests/group   |   1 +
 4 files changed, 145 insertions(+), 2 deletions(-)
 create mode 100755 tests/qemu-iotests/198
 create mode 100644 tests/qemu-iotests/198.out

-- 
2.13.6

Re: [Qemu-devel] [Qemu-block] segfault in parallel blockjobs (iotest 30)

[John Snow]

On 11/16/2017 10:54 AM, Alberto Garcia wrote:
> On Wed 15 Nov 2017 05:31:20 PM CET, Anton Nefedov wrote:
>>> I have the impression that one major source of headaches is the fact
>>> that the reopen queue contains nodes that don't need to be reopened at
>>> all. Ideally this should be detected early on in bdrv_reopen_queue(), so
>>> there's no chance that the queue contains nodes used by a different
>>> block job. If we had that then op blockers should be enough to prevent
>>> these things. Or am I missing something?
>>>
>> After applying Max's patch I tried the similar approach; that is keep
>> BDSes referenced while they are in the reopen queue.  Now I get the
>> stream job hanging. Somehow one blk_root_drained_begin() is not paired
>> with blk_root_drained_end(). So the job stays paused.
> 
> I can see this if I apply Max's patch and keep refs to BDSs in the
> reopen queue:
> 
> #0  block_job_pause (...) at blockjob.c:130
> #1  0x55c143cb586d in block_job_drained_begin (...) at blockjob.c:227
> #2  0x55c143d08067 in blk_set_dev_ops (...) at block/block-backend.c:887
> #3  0x55c143cb69db in block_job_create (...) at blockjob.c:678
> #4  0x55c143d17c0c in mirror_start_job (...) at block/mirror.c:1177
> 
> There's a ops->drained_begin(opaque) call in blk_set_dev_ops() that
> doesn't seem to be paired. And when you call block_job_start() then it
> yields immediately waiting for the resume (that never arrives).
> 
> John, this change was yours (f4d9cc88ee69a5b04). Any idea?
> 
> Berto
> 

The idea at the time was that if you tell the BlockBackend to drain and
then attach a job to it, once you go to *end* the drained region you'd
have a mismatched begin/end pair.

To allow for some flexibility and to make sure that you *didn't* have a
mismatched begin/end call, what I did was that if you attach dev_ops to
an already drained backend (i.e. we "missed our chance" to issue the
drained_begin) we play catch-up and issue the drained call.

There's no matching call here, because I anticipated whoever initially
bumped that quiesce_counter up to be issuing the drained_end, which will
then be propagated according to the dev_ops structure in place.

Re: [Qemu-devel] [PATCH v1 for-2.11 2/3] s390x/tcg: fix DIAG 308 with > 1 VCPU (single threaded TCG)

[David Hildenbrand]

On 16.11.2017 21:57, Christian Borntraeger wrote:
> Please change the subject. In busy times I tend to ignore tcg patches.
> This code is clearly kvm and tcg.
> So what about "s390x/diag:" as prefix?

Right, it was a fix for TCG, that's why I added TCG only. But it should
have been purely s390x or s390x/diag.

> 
> On 11/16/2017 06:05 PM, David Hildenbrand wrote:
>> Currently, single threaded TCG with > 1 VCPU gets stuck during IPL, when
>> the bios tries to switch to the loaded kernel via DIAG 308.
>>
>> pause_all_vcpus()/resume_all_vcpus() should not be called from a VCPU.
>>
>> And there is also no need for it. run_on_cpu() will make sure that the
>> CPUs exit KVM/TCG, where they get stopped. Once stopped, they will no
>> longer run.
>>
>> Signed-off-by: David Hildenbrand 
>> ---
>>  target/s390x/diag.c | 4 
>>  1 file changed, 4 deletions(-)
>>
>> diff --git a/target/s390x/diag.c b/target/s390x/diag.c
>> index dbbb9e886f..52bc348808 100644
>> --- a/target/s390x/diag.c
>> +++ b/target/s390x/diag.c
>> @@ -27,7 +27,6 @@ static int modified_clear_reset(S390CPU *cpu)
>>  S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
>>  CPUState *t;
>>
>> -pause_all_vcpus();
> 
> 
> I did this to prevent a "still running CPU to restart an already stopped one".
> Are we sure that this can not happen?

Interesting question. I thought it would not be a problem but the way
locking with run_on_cpu() is handled is tricky. Now I am worried about a
couple of deadlocks.

pause_all_vcpus() actually gives up the qemu_global_mutex, so anybody
waiting for that mutex can continue.

We have a deadlock if two CPUs at the same time would call
pause_all_vcpus(). E.g. two CPUs executing at the same time a DIAG 308
(unlikely).

run_on_cpu temporarily gives up the qemu_global_mutex. If two CPUs call
a run_on_cpu at the same time against each other, we might also have a
deadlock.

Two CPUs simultaneously trying to send a SIGP START/STOP/RESTART cannot
run into a deadlock as they are protected by the SIGP mutex with a trylock.

So even with pause_all_vcpus() I think we have a problem if another CPU
sends a SIGP to the issuing DIAG CPU and expects the run_on_cpu to
trigger. Deadlock, but unlikely I assume?

Let's defer this patch for now, booting with 1 VCPU is not degraded and
it looked easier than it is.

Maybe fixing pause_all_vcpus() to work with more than one CPU in single
threaded TCG is an (easier) alternative and at least keeps the (tested)
state. 2.12 material.

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [Qemu-block] [PATCH v2] qapi: block-core: Clarify events emitted by 'block-job-cancel'

[John Snow]

On 11/16/2017 04:14 AM, Kashyap Chamarthy wrote:
> On Wed, Nov 15, 2017 at 04:56:13PM -0500, John Snow wrote:
>>
>>
>> On 11/15/2017 04:54 PM, Kashyap Chamarthy wrote:
>>> On Wed, Nov 15, 2017 at 02:15:57PM -0500, John Snow wrote:
> 
> [...]
> 
 is it covered sufficiently in live-block-operations.rst ?
>>>
>>> I looked in there[2] too.  Short answer: no.  Long: In the "Live disk
>>> synchronization — drive-mirror and blockdev-mirror" section, I simply
>>> seemed to declare: 
>>>
>>> "Issuing the command ``block-job-cancel`` after it emits the event
>>> ``BLOCK_JOB_CANCELLED``"
>>>
>>> As if that's the *only* event it emits, which is clearly not the case.
>>> So while at it, wonder if should I also update it
>>> ('live-block-operations.rst') too.
>>>
>>
>> It's an interesting gotcha that I wasn't really acutely aware of myself,
>> so having it in the doc format for API programmers who aren't
>> necessarily digging through our source sounds like a pleasant courtesy.
> 
> Indeed, will do.  (Just for my own clarity, did you imply: don't update
> it in block-core.json?  FWIW, my first instinct is to check the QAPI
> documentation for such things, that's why I wrote there first :-))
> 

No, definitely update both.

> Thanks for looking.
> 
> [...]
> 

Re: [Qemu-devel] [Qemu-block] [PATCH] iotests: test clearing unknown autoclear_features by qcow2

[John Snow]

On 11/10/2017 03:02 PM, Kevin Wolf wrote:
> Am 10.11.2017 um 18:54 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> Test clearing unknown autoclear_features by qcow2 on incoming
>> migration.
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy 
>> ---
>>
>> Hi all!
>>
>> This patch shows degradation, added in 2.10 in commit
>>
>> commit 9c5e6594f15b7364624a3ad40306c396c93a2145
>> Author: Kevin Wolf 
>> Date:   Thu May 4 18:52:40 2017 +0200
>>
>> block: Fix write/resize permissions for inactive images
>>
>> The problem:
>> When on incoming migration with shared storage we reopen image to RW mode
>> we call bdrv_invalidate_cache it firstly call drv->bdrv_invalidate_cache and
>> only after it, through "parent->role->activate(parent, _err);" we set
>> appropriate RW permission.
>>
>> Because of this, if drv->bdrv_invalidate_cache wants to write something
>> (image is RW and BDRV_O_INACTIVE is not set) it goes into
>> "bdrv_aligned_pwritev: Assertion `child->perm & BLK_PERM_WRITE' failed"
>>
>> One case, when qcow2_invalidate_cache wants to write
>> something - when it wants to clear some unknown autoclear features. So,
>> here is a test for it.
>>
>> Another case is when we try to migrate persistent dirty bitmaps through
>> shared storage, on invalidate_cache qcow2 will try to set DIRTY bit in
>> all loaded bitmaps.
>>
>> Kevin, what do you think? I understand that operation order should be changed
>> somehow in bdrv_invalidate_cache, but I'm not sure about how 
>> "parent->role->.."
>> things works and can we safely move this part from function end to the 
>> middle.
> 
> I don't think you need to move the parent->role->activate() callback,
> but just the bdrv_set_perm() so that we request the correct permissions
> for operation without the BDRV_O_INACTIVE flag.
> 
> The following seems to work for me (including a fix for the test case,
> we don't seem to get a RESUME event). I'm not sure about the error paths
> yet. We should probably try do undo the permission changes there. I can
> have a closer look into this next week.
> 
> Kevin
> 

What's the status here, something we need to be paying attention to for
2.11?

[Qemu-devel] [PATCH for-2.11] hw/net/eepro100: Fix endianness problem on big endian hosts

[Thomas Huth]

Since commit 1865e288a823c764cd4344d ("Fix eepro100 simple transmission
mode"), the test/pxe-test is broken for the eepro100 device on big
endian hosts. However, it seems like that commit did not introduce the
problem, but just uncovered it: The EEPRO100State->tx.tbd_array_addr and
EEPRO100State->tx.tcb_bytes fields are already in host byte order, since
they have already been byte-swapped in the read_cb() function.
Thus byte-swapping them in tx_command() again results in the wrong
endianness. Removing the byte-swapping here fixes the pxe-test.

Signed-off-by: Thomas Huth 
---
 hw/net/eepro100.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c
index a63ed2c..03e00f7 100644
--- a/hw/net/eepro100.c
+++ b/hw/net/eepro100.c
@@ -756,8 +756,8 @@ static void read_cb(EEPRO100State *s)
 
 static void tx_command(EEPRO100State *s)
 {
-uint32_t tbd_array = le32_to_cpu(s->tx.tbd_array_addr);
-uint16_t tcb_bytes = (le16_to_cpu(s->tx.tcb_bytes) & 0x3fff);
+uint32_t tbd_array = s->tx.tbd_array_addr;
+uint16_t tcb_bytes = s->tx.tcb_bytes & 0x3fff;
 /* Sends larger than MAX_ETH_FRAME_SIZE are allowed, up to 2600 bytes. */
 uint8_t buf[2600];
 uint16_t size = 0;
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH v1 for-2.11 1/3] s390x: fix storing CPU status (again)

[Christian Borntraeger]

On 11/16/2017 06:05 PM, David Hildenbrand wrote:
> Looks like the last fix + cleanup introduced another bug. (for now Linux
> guests don't seem to care) - we store the crs into ars.
> 
> Fixes: 947a38bd6f13 ("s390x/kvm: fix and cleanup storing CPU status")
> Signed-off-by: David Hildenbrand 

Reviewed-by: Christian Borntraeger 

> ---
>  target/s390x/helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/s390x/helper.c b/target/s390x/helper.c
> index f78983dd6a..246ba20f0d 100644
> --- a/target/s390x/helper.c
> +++ b/target/s390x/helper.c
> @@ -279,7 +279,7 @@ int s390_store_status(S390CPU *cpu, hwaddr addr, bool 
> store_arch)
>  sa->ars[i] = cpu_to_be32(cpu->env.aregs[i]);
>  }
>  for (i = 0; i < 16; ++i) {
> -sa->ars[i] = cpu_to_be64(cpu->env.cregs[i]);
> +sa->crs[i] = cpu_to_be64(cpu->env.cregs[i]);
>  }
> 
>  cpu_physical_memory_unmap(sa, len, 1, len);
> 

Re: [Qemu-devel] [PATCH v1 for-2.11 2/3] s390x/tcg: fix DIAG 308 with > 1 VCPU (single threaded TCG)

[Christian Borntraeger]

Please change the subject. In busy times I tend to ignore tcg patches.
This code is clearly kvm and tcg.
So what about "s390x/diag:" as prefix?

On 11/16/2017 06:05 PM, David Hildenbrand wrote:
> Currently, single threaded TCG with > 1 VCPU gets stuck during IPL, when
> the bios tries to switch to the loaded kernel via DIAG 308.
> 
> pause_all_vcpus()/resume_all_vcpus() should not be called from a VCPU.
> 
> And there is also no need for it. run_on_cpu() will make sure that the
> CPUs exit KVM/TCG, where they get stopped. Once stopped, they will no
> longer run.
> 
> Signed-off-by: David Hildenbrand 
> ---
>  target/s390x/diag.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/target/s390x/diag.c b/target/s390x/diag.c
> index dbbb9e886f..52bc348808 100644
> --- a/target/s390x/diag.c
> +++ b/target/s390x/diag.c
> @@ -27,7 +27,6 @@ static int modified_clear_reset(S390CPU *cpu)
>  S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
>  CPUState *t;
> 
> -pause_all_vcpus();


I did this to prevent a "still running CPU to restart an already stopped one".
Are we sure that this can not happen?


>  cpu_synchronize_all_states();
>  CPU_FOREACH(t) {
>  run_on_cpu(t, s390_do_cpu_full_reset, RUN_ON_CPU_NULL);
> @@ -37,7 +36,6 @@ static int modified_clear_reset(S390CPU *cpu)
>  s390_crypto_reset();
>  scc->load_normal(CPU(cpu));
>  cpu_synchronize_all_post_reset();
> -resume_all_vcpus();
>  return 0;
>  }
> 
> @@ -53,7 +51,6 @@ static int load_normal_reset(S390CPU *cpu)
>  S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
>  CPUState *t;
> 
> -pause_all_vcpus();
>  cpu_synchronize_all_states();
>  CPU_FOREACH(t) {
>  run_on_cpu(t, s390_do_cpu_reset, RUN_ON_CPU_NULL);
> @@ -63,7 +60,6 @@ static int load_normal_reset(S390CPU *cpu)
>  scc->initial_cpu_reset(CPU(cpu));
>  scc->load_normal(CPU(cpu));
>  cpu_synchronize_all_post_reset();
> -resume_all_vcpus();
>  return 0;
>  }
> 

Re: [Qemu-devel] [PATCH v1 for-2.11 0/3] s390x: fixes for SIGP and DIAG 308

[Christian Borntraeger]

On 11/16/2017 06:23 PM, Cornelia Huck wrote:
> On Thu, 16 Nov 2017 18:05:23 +0100
> David Hildenbrand  wrote:
> 
>> First one also applies to KVM SIGP handling. The other two only
>> apply to TCG (allowing to IPL from disk with more than 1 VCPU- I
>> never tested that before).
>>
>> David Hildenbrand (3):
>>   s390x: fix storing CPU status (again)
>>   s390x/tcg: fix DIAG 308 with > 1 VCPU (single threaded TCG)
>>   s390x/tcg: fix DIAG 308 with > 1 VCPU (MTTCG)
>>
>>  target/s390x/diag.c| 4 
>>  target/s390x/helper.c  | 2 +-
>>  target/s390x/misc_helper.c | 2 ++
>>  3 files changed, 3 insertions(+), 5 deletions(-)
>>
> 
> Thanks, queued to s390-fixes.

Can you please give a chance to review this?
18 minutes is not ok, especially in hard freeze.

Re: [Qemu-devel] [qemu-s390x] [PATCH v1 for-2.11 3/3] s390x/tcg: fix DIAG 308 with > 1 VCPU (MTTCG)

[Thomas Huth]

On 16.11.2017 18:05, David Hildenbrand wrote:
> Currently, multi threaded TCG with > 1 VCPU gets stuck during IPL, when
> the bios tries to switch to the loaded kernel via DIAG 308.
> 
> As run_on_cpu() is used, we run into a deadlock after handling the reset.
> We need the iolock (just like KVM).
> 
> Signed-off-by: David Hildenbrand 
> ---
>  target/s390x/misc_helper.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/target/s390x/misc_helper.c b/target/s390x/misc_helper.c
> index 4afd90b969..d272851e1c 100644
> --- a/target/s390x/misc_helper.c
> +++ b/target/s390x/misc_helper.c
> @@ -103,7 +103,9 @@ void HELPER(diag)(CPUS390XState *env, uint32_t r1, 
> uint32_t r3, uint32_t num)
>  break;
>  case 0x308:
>  /* ipl */
> +qemu_mutex_lock_iothread();
>  handle_diag_308(env, r1, r3);
> +qemu_mutex_unlock_iothread();
>  r = 0;
>  break;
>  case 0x288:
> 

Reviewed-by: Thomas Huth 

Re: [Qemu-devel] [qemu-s390x] [PATCH v1 for-2.11 1/3] s390x: fix storing CPU status (again)

[Thomas Huth]

On 16.11.2017 18:05, David Hildenbrand wrote:
> Looks like the last fix + cleanup introduced another bug. (for now Linux
> guests don't seem to care) - we store the crs into ars.
> 
> Fixes: 947a38bd6f13 ("s390x/kvm: fix and cleanup storing CPU status")
> Signed-off-by: David Hildenbrand 
> ---
>  target/s390x/helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/s390x/helper.c b/target/s390x/helper.c
> index f78983dd6a..246ba20f0d 100644
> --- a/target/s390x/helper.c
> +++ b/target/s390x/helper.c
> @@ -279,7 +279,7 @@ int s390_store_status(S390CPU *cpu, hwaddr addr, bool 
> store_arch)
>  sa->ars[i] = cpu_to_be32(cpu->env.aregs[i]);
>  }
>  for (i = 0; i < 16; ++i) {
> -sa->ars[i] = cpu_to_be64(cpu->env.cregs[i]);
> +sa->crs[i] = cpu_to_be64(cpu->env.cregs[i]);
>  }
>  
>  cpu_physical_memory_unmap(sa, len, 1, len);
> 

Reviewed-by: Thomas Huth 

[Qemu-devel] [PATCH v5 4/4] contrib/vhost-user-blk: introduce a vhost-user-blk sample application

[Changpeng Liu]

This commit introcudes a vhost-user-blk backend device, it uses UNIX
domain socket to communicate with Qemu. The vhost-user-blk sample
application should be used with Qemu vhost-user-blk-pci device.

To use it, complie with:
make vhost-user-blk

and start like this:
vhost-user-blk -b /dev/sdb -s /path/vhost.socket

Signed-off-by: Changpeng Liu 
---
 .gitignore  |   1 +
 Makefile|   3 +
 Makefile.objs   |   1 +
 contrib/vhost-user-blk/Makefile.objs|   1 +
 contrib/vhost-user-blk/vhost-user-blk.c | 536 
 5 files changed, 542 insertions(+)
 create mode 100644 contrib/vhost-user-blk/Makefile.objs
 create mode 100644 contrib/vhost-user-blk/vhost-user-blk.c

diff --git a/.gitignore b/.gitignore
index 588769b..495f854 100644
--- a/.gitignore
+++ b/.gitignore
@@ -55,6 +55,7 @@
 /scsi/qemu-pr-helper
 /vscclient
 /vhost-user-scsi
+/vhost-user-blk
 /fsdev/virtfs-proxy-helper
 *.tmp
 *.[1-9]
diff --git a/Makefile b/Makefile
index d2e31d9..0cfb0f1 100644
--- a/Makefile
+++ b/Makefile
@@ -327,6 +327,7 @@ dummy := $(call unnest-vars,, \
 ivshmem-server-obj-y \
 libvhost-user-obj-y \
 vhost-user-scsi-obj-y \
+vhost-user-blk-obj-y \
 qga-vss-dll-obj-y \
 block-obj-y \
 block-obj-m \
@@ -558,6 +559,8 @@ ivshmem-server$(EXESUF): $(ivshmem-server-obj-y) 
$(COMMON_LDADDS)
 endif
 vhost-user-scsi$(EXESUF): $(vhost-user-scsi-obj-y) libvhost-user.a
$(call LINK, $^)
+vhost-user-blk$(EXESUF): $(vhost-user-blk-obj-y) libvhost-user.a
+   $(call LINK, $^)
 
 module_block.h: $(SRC_PATH)/scripts/modules/module_block.py config-host.mak
$(call quiet-command,$(PYTHON) $< $@ \
diff --git a/Makefile.objs b/Makefile.objs
index 285c6f3..ae9aef7 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -115,6 +115,7 @@ libvhost-user-obj-y = contrib/libvhost-user/
 vhost-user-scsi.o-cflags := $(LIBISCSI_CFLAGS)
 vhost-user-scsi.o-libs := $(LIBISCSI_LIBS)
 vhost-user-scsi-obj-y = contrib/vhost-user-scsi/
+vhost-user-blk-obj-y = contrib/vhost-user-blk/
 
 ##
 trace-events-subdirs =
diff --git a/contrib/vhost-user-blk/Makefile.objs 
b/contrib/vhost-user-blk/Makefile.objs
new file mode 100644
index 000..72e2cdc
--- /dev/null
+++ b/contrib/vhost-user-blk/Makefile.objs
@@ -0,0 +1 @@
+vhost-user-blk-obj-y = vhost-user-blk.o
diff --git a/contrib/vhost-user-blk/vhost-user-blk.c 
b/contrib/vhost-user-blk/vhost-user-blk.c
new file mode 100644
index 000..076ec62
--- /dev/null
+++ b/contrib/vhost-user-blk/vhost-user-blk.c
@@ -0,0 +1,536 @@
+/*
+ * vhost-user-blk sample application
+ *
+ * Copyright (c) 2017 Intel Corporation. All rights reserved.
+ *
+ * Author:
+ *  Changpeng Liu 
+ *
+ * This work is based on the "vhost-user-scsi" sample and "virtio-blk" driver
+ * implemention by:
+ *  Felipe Franciosi 
+ *  Anthony Liguori 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 only.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "standard-headers/linux/virtio_blk.h"
+#include "contrib/libvhost-user/libvhost-user-glib.h"
+#include "contrib/libvhost-user/libvhost-user.h"
+
+#include 
+
+struct virtio_blk_inhdr {
+unsigned char status;
+};
+
+/* vhost user block device */
+typedef struct VubDev {
+VugDev parent;
+int blk_fd;
+struct virtio_blk_config blkcfg;
+char *blk_name;
+GMainLoop *loop;
+} VubDev;
+
+typedef struct VubReq {
+VuVirtqElement *elem;
+int64_t sector_num;
+size_t size;
+struct virtio_blk_inhdr *in;
+struct virtio_blk_outhdr *out;
+VubDev *vdev_blk;
+struct VuVirtq *vq;
+} VubReq;
+
+/**  refer util/iov.c  **/
+static size_t vub_iov_size(const struct iovec *iov,
+  const unsigned int iov_cnt)
+{
+size_t len;
+unsigned int i;
+
+len = 0;
+for (i = 0; i < iov_cnt; i++) {
+len += iov[i].iov_len;
+}
+return len;
+}
+
+static void vub_panic_cb(VuDev *vu_dev, const char *buf)
+{
+VugDev *gdev;
+VubDev *vdev_blk;
+
+assert(vu_dev);
+
+gdev = container_of(vu_dev, VugDev, parent);
+vdev_blk = container_of(gdev, VubDev, parent);
+if (buf) {
+g_warning("vu_panic: %s", buf);
+}
+
+g_main_loop_quit(vdev_blk->loop);
+}
+
+static void vub_req_complete(VubReq *req)
+{
+VugDev *gdev = >vdev_blk->parent;
+VuDev *vu_dev = >parent;
+
+/* IO size with 1 extra status byte */
+vu_queue_push(vu_dev, req->vq, req->elem,
+  req->size + 1);
+vu_queue_notify(vu_dev, req->vq);
+
+if (req->elem) {
+free(req->elem);
+}
+g_free(req);
+}
+
+static int vub_open(const char *file_name, bool wce)
+{
+

[Qemu-devel] [PATCH v5 3/4] contrib/libvhost-user: enable virtio config space messages

[Changpeng Liu]

Enable VHOST_USER_GET_CONFIG/VHOST_USER_SET_CONFIG/VHOST_USER_SET_CONFIG_FD
messages in libvhost-user library, users can implement their own I/O target
based on the library. This enable the virtio config space delivered between
Qemu host device and the I/O target, also event notifier is added in case
of virtio config space changed.

Signed-off-by: Changpeng Liu 
---
 contrib/libvhost-user/libvhost-user.c | 79 +++
 contrib/libvhost-user/libvhost-user.h | 24 ++-
 2 files changed, 102 insertions(+), 1 deletion(-)

diff --git a/contrib/libvhost-user/libvhost-user.c 
b/contrib/libvhost-user/libvhost-user.c
index f409bd3..16fc4f2 100644
--- a/contrib/libvhost-user/libvhost-user.c
+++ b/contrib/libvhost-user/libvhost-user.c
@@ -84,6 +84,9 @@ vu_request_to_string(unsigned int req)
 REQ(VHOST_USER_SET_SLAVE_REQ_FD),
 REQ(VHOST_USER_IOTLB_MSG),
 REQ(VHOST_USER_SET_VRING_ENDIAN),
+REQ(VHOST_USER_GET_CONFIG),
+REQ(VHOST_USER_SET_CONFIG),
+REQ(VHOST_USER_SET_CONFIG_FD),
 REQ(VHOST_USER_MAX),
 };
 #undef REQ
@@ -798,6 +801,69 @@ vu_set_slave_req_fd(VuDev *dev, VhostUserMsg *vmsg)
 }
 
 static bool
+vu_get_config(VuDev *dev, VhostUserMsg *vmsg)
+{
+int ret = -1;
+
+if (dev->iface->get_config) {
+ret = dev->iface->get_config(dev, vmsg->payload.config.region,
+ sizeof(vmsg->payload.config.region));
+}
+
+if (ret) {
+/* resize to zero to indicate an error to master */
+vmsg->size = 0;
+}
+
+return true;
+}
+
+static bool
+vu_set_config(VuDev *dev, VhostUserMsg *vmsg)
+{
+int ret = -1;
+bool reply_supported = !!(dev->protocol_features &
+ (1ULL << VHOST_USER_PROTOCOL_F_REPLY_ACK));
+
+if (dev->iface->set_config) {
+ret = dev->iface->set_config(dev, vmsg->payload.config.region,
+ vmsg->payload.config.offset,
+ vmsg->payload.config.size);
+}
+
+vmsg->size = sizeof(vmsg->payload.u64);
+if (!ret) {
+vmsg->payload.u64 = 0;
+} else {
+/* indicate an error in case reply supported */
+vmsg->payload.u64 = 1;
+}
+
+if (reply_supported) {
+return true;
+}
+
+return false;
+}
+
+static bool
+vu_set_config_fd(VuDev *dev, VhostUserMsg *vmsg)
+{
+   if (vmsg->fd_num != 1) {
+vu_panic(dev, "Invalid config_fd message");
+return false;
+}
+
+if (dev->config_fd != -1) {
+close(dev->config_fd);
+}
+dev->config_fd = vmsg->fds[0];
+DPRINT("Got config_fd: %d\n", vmsg->fds[0]);
+
+return false;
+}
+
+static bool
 vu_process_message(VuDev *dev, VhostUserMsg *vmsg)
 {
 int do_reply = 0;
@@ -862,6 +928,12 @@ vu_process_message(VuDev *dev, VhostUserMsg *vmsg)
 return vu_set_vring_enable_exec(dev, vmsg);
 case VHOST_USER_SET_SLAVE_REQ_FD:
 return vu_set_slave_req_fd(dev, vmsg);
+case VHOST_USER_GET_CONFIG:
+return vu_get_config(dev, vmsg);
+case VHOST_USER_SET_CONFIG:
+return vu_set_config(dev, vmsg);
+case VHOST_USER_SET_CONFIG_FD:
+return vu_set_config_fd(dev, vmsg);
 case VHOST_USER_NONE:
 break;
 default:
@@ -940,6 +1012,11 @@ vu_deinit(VuDev *dev)
 dev->slave_fd = -1;
 }
 
+if (dev->config_fd != -1) {
+close(dev->config_fd);
+dev->config_fd = -1;
+}
+
 if (dev->sock != -1) {
 close(dev->sock);
 }
@@ -970,6 +1047,8 @@ vu_init(VuDev *dev,
 dev->iface = iface;
 dev->log_call_fd = -1;
 dev->slave_fd = -1;
+dev->config_fd = -1;
+
 for (i = 0; i < VHOST_MAX_NR_VIRTQUEUE; i++) {
 dev->vq[i] = (VuVirtq) {
 .call_fd = -1, .kick_fd = -1, .err_fd = -1,
diff --git a/contrib/libvhost-user/libvhost-user.h 
b/contrib/libvhost-user/libvhost-user.h
index 2f5864b..0d1f674 100644
--- a/contrib/libvhost-user/libvhost-user.h
+++ b/contrib/libvhost-user/libvhost-user.h
@@ -30,6 +30,11 @@
 
 #define VHOST_MEMORY_MAX_NREGIONS 8
 
+/*
+ * Maximum size of virtio device config space
+ */
+#define VHOST_USER_MAX_CONFIG_SIZE 256
+
 enum VhostUserProtocolFeature {
 VHOST_USER_PROTOCOL_F_MQ = 0,
 VHOST_USER_PROTOCOL_F_LOG_SHMFD = 1,
@@ -38,7 +43,6 @@ enum VhostUserProtocolFeature {
 VHOST_USER_PROTOCOL_F_NET_MTU = 4,
 VHOST_USER_PROTOCOL_F_SLAVE_REQ = 5,
 VHOST_USER_PROTOCOL_F_CROSS_ENDIAN = 6,
-
 VHOST_USER_PROTOCOL_F_MAX
 };
 
@@ -69,6 +73,9 @@ typedef enum VhostUserRequest {
 VHOST_USER_SET_SLAVE_REQ_FD = 21,
 VHOST_USER_IOTLB_MSG = 22,
 VHOST_USER_SET_VRING_ENDIAN = 23,
+VHOST_USER_GET_CONFIG = 24,
+VHOST_USER_SET_CONFIG = 25,
+VHOST_USER_SET_CONFIG_FD = 26,
 VHOST_USER_MAX
 } VhostUserRequest;
 
@@ -90,6 +97,12 @@ typedef struct VhostUserLog {
 uint64_t mmap_offset;
 } VhostUserLog;
 
+typedef struct VhostUserConfig {
+  

[Qemu-devel] [PATCH v5 2/4] vhost-user-blk: introduce a new vhost-user-blk host device

[Changpeng Liu]

This commit introduces a new vhost-user device for block, it uses a
chardev to connect with the backend, same with Qemu virito-blk device,
Guest OS still uses the virtio-blk frontend driver.

To use it, start Qemu with command line like this:

qemu-system-x86_64 \
-chardev socket,id=char0,path=/path/vhost.socket \
-device vhost-user-blk-pci,chardev=char0,num-queues=2, \
bootindex=2... \

Users can use different parameters for `num-queues` and `bootindex`.

Different with exist Qemu virtio-blk host device, it makes more easy
for users to implement their own I/O processing logic, such as all
user space I/O stack against hardware block device. It uses the new
vhost messages(VHOST_USER_GET_CONFIG) to get block virtio config
information from backend process.

Signed-off-by: Changpeng Liu 
---
 default-configs/pci.mak|   1 +
 hw/block/Makefile.objs |   3 +
 hw/block/vhost-user-blk.c  | 356 +
 hw/virtio/virtio-pci.c |  55 ++
 hw/virtio/virtio-pci.h |  18 ++
 include/hw/virtio/vhost-user-blk.h |  42 +
 6 files changed, 475 insertions(+)
 create mode 100644 hw/block/vhost-user-blk.c
 create mode 100644 include/hw/virtio/vhost-user-blk.h

diff --git a/default-configs/pci.mak b/default-configs/pci.mak
index e514bde..49a0f28 100644
--- a/default-configs/pci.mak
+++ b/default-configs/pci.mak
@@ -43,3 +43,4 @@ CONFIG_VGA_PCI=y
 CONFIG_IVSHMEM_DEVICE=$(CONFIG_IVSHMEM)
 CONFIG_ROCKER=y
 CONFIG_VHOST_USER_SCSI=$(call land,$(CONFIG_VHOST_USER),$(CONFIG_LINUX))
+CONFIG_VHOST_USER_BLK=$(call land,$(CONFIG_VHOST_USER),$(CONFIG_LINUX))
diff --git a/hw/block/Makefile.objs b/hw/block/Makefile.objs
index e0ed980..4c19a58 100644
--- a/hw/block/Makefile.objs
+++ b/hw/block/Makefile.objs
@@ -13,3 +13,6 @@ obj-$(CONFIG_SH4) += tc58128.o
 
 obj-$(CONFIG_VIRTIO) += virtio-blk.o
 obj-$(CONFIG_VIRTIO) += dataplane/
+ifeq ($(CONFIG_VIRTIO),y)
+obj-$(CONFIG_VHOST_USER_BLK) += vhost-user-blk.o
+endif
diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
new file mode 100644
index 000..71bd6e7
--- /dev/null
+++ b/hw/block/vhost-user-blk.c
@@ -0,0 +1,356 @@
+/*
+ * vhost-user-blk host device
+ *
+ * Copyright(C) 2017 Intel Corporation.
+ *
+ * Authors:
+ *  Changpeng Liu 
+ *
+ * Largely based on the "vhost-user-scsi.c" and "vhost-scsi.c" implemented by:
+ * Felipe Franciosi 
+ * Stefan Hajnoczi 
+ * Nicholas Bellinger 
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "qemu/error-report.h"
+#include "qemu/typedefs.h"
+#include "qemu/cutils.h"
+#include "qom/object.h"
+#include "hw/qdev-core.h"
+#include "hw/virtio/vhost.h"
+#include "hw/virtio/vhost-user-blk.h"
+#include "hw/virtio/virtio.h"
+#include "hw/virtio/virtio-bus.h"
+#include "hw/virtio/virtio-access.h"
+
+static const int user_feature_bits[] = {
+VIRTIO_BLK_F_SIZE_MAX,
+VIRTIO_BLK_F_SEG_MAX,
+VIRTIO_BLK_F_GEOMETRY,
+VIRTIO_BLK_F_BLK_SIZE,
+VIRTIO_BLK_F_TOPOLOGY,
+VIRTIO_BLK_F_MQ,
+VIRTIO_BLK_F_RO,
+VIRTIO_BLK_F_FLUSH,
+VIRTIO_BLK_F_CONFIG_WCE,
+VIRTIO_F_VERSION_1,
+VIRTIO_RING_F_INDIRECT_DESC,
+VIRTIO_RING_F_EVENT_IDX,
+VIRTIO_F_NOTIFY_ON_EMPTY,
+VHOST_INVALID_FEATURE_BIT
+};
+
+static void vhost_user_blk_update_config(VirtIODevice *vdev, uint8_t *config)
+{
+VHostUserBlk *s = VHOST_USER_BLK(vdev);
+
+memcpy(config, >blkcfg, sizeof(struct virtio_blk_config));
+}
+
+static void vhost_user_blk_set_config(VirtIODevice *vdev, const uint8_t 
*config)
+{
+VHostUserBlk *s = VHOST_USER_BLK(vdev);
+struct virtio_blk_config *blkcfg = (struct virtio_blk_config *)config;
+int ret;
+
+if (blkcfg->wce == s->blkcfg.wce) {
+return;
+}
+
+ret = vhost_dev_set_config(>dev, config,
+   offsetof(struct virtio_blk_config, wce),
+   sizeof(blkcfg->wce));
+if (ret) {
+error_report("set device config space failed");
+return;
+}
+
+s->blkcfg.wce = blkcfg->wce;
+}
+
+static void vhost_user_blk_handle_config_change(struct vhost_dev *dev)
+{
+int ret;
+struct virtio_blk_config blkcfg;
+VHostUserBlk *s = VHOST_USER_BLK(dev->vdev);
+
+ret = vhost_dev_get_config(dev, (uint8_t *),
+   sizeof(struct virtio_blk_config));
+if (ret < 0) {
+error_report("get config space failed");
+return;
+}
+
+/* valid for resize only */
+if (blkcfg.capacity != s->blkcfg.capacity) {
+s->blkcfg.capacity = blkcfg.capacity;
+memcpy(dev->vdev->config, >blkcfg, sizeof(struct 
virtio_blk_config));
+virtio_notify_config(dev->vdev);
+}
+}
+

[Qemu-devel] [PATCH v5 0/4] *** Introduce a new vhost-user-blk host device to Qemu ***

[Changpeng Liu]

Although virtio scsi specification was designed as a replacement for virtio_blk,
there are still many users using virtio_blk. Qemu 2.9 introduced a new device
vhost user scsi which can process I/O in user space for virtio_scsi, this commit
introduces a new vhost user block host device, which can support virtio_blk in
Guest OS, and I/O processing in another I/O target.

Due to the limitation for virtio_blk specification, virtio_blk device cannot get
block information such as capacity, block size etc via the specification, 
several
new vhost user messages were added to deliver virtio config space
information between Qemu and I/O target, 
VHOST_USER_GET_CONFIG/VHOST_USER_SET_CONFIG
messages used for get/set config space from/to I/O target, 
VHOST_USER_SET_CONFIG_FD
was added for event notifier in case the change of virtio config space. Also, 
those
messages can be used for vhost device live migration as well.

V4-v5: add header offset and size for virtio config space.
v3-v4: refactoring the vhost user block example patch based on new 
libvhost-user library.
v2-v3: add new vhost user message to get/set virtio config space.

Changpeng Liu (4):
  vhost-user: add new vhost user messages to support virtio config space
  vhost-user-blk: introduce a new vhost-user-blk host device
  contrib/libvhost-user: enable virtio config space messages
  contrib/vhost-user-blk: introduce a vhost-user-blk sample application

 .gitignore  |   1 +
 Makefile|   3 +
 Makefile.objs   |   1 +
 contrib/libvhost-user/libvhost-user.c   |  79 +
 contrib/libvhost-user/libvhost-user.h   |  24 +-
 contrib/vhost-user-blk/Makefile.objs|   1 +
 contrib/vhost-user-blk/vhost-user-blk.c | 536 
 default-configs/pci.mak |   1 +
 docs/interop/vhost-user.txt |  39 +++
 hw/block/Makefile.objs  |   3 +
 hw/block/vhost-user-blk.c   | 356 +
 hw/virtio/vhost-user.c  |  98 ++
 hw/virtio/vhost.c   |  63 
 hw/virtio/virtio-pci.c  |  55 
 hw/virtio/virtio-pci.h  |  18 ++
 include/hw/virtio/vhost-backend.h   |   8 +
 include/hw/virtio/vhost-user-blk.h  |  42 +++
 include/hw/virtio/vhost.h   |  16 +
 18 files changed, 1343 insertions(+), 1 deletion(-)
 create mode 100644 contrib/vhost-user-blk/Makefile.objs
 create mode 100644 contrib/vhost-user-blk/vhost-user-blk.c
 create mode 100644 hw/block/vhost-user-blk.c
 create mode 100644 include/hw/virtio/vhost-user-blk.h

-- 
1.9.3

[Qemu-devel] [PATCH v5 1/4] vhost-user: add new vhost user messages to support virtio config space

[Changpeng Liu]

Add VHOST_USER_GET_CONFIG/VHOST_USER_SET_CONFIG messages which can be
used for live migration of vhost user devices, also vhost user devices
can benefit from the messages to get/set virtio config space from/to the
I/O target. For the purpose to support virtio config space change,
VHOST_USER_SET_CONFIG_FD message is added as the event notifier
in case virtio config space change in the I/O target.

Signed-off-by: Changpeng Liu 
---
 docs/interop/vhost-user.txt   | 39 
 hw/virtio/vhost-user.c| 98 +++
 hw/virtio/vhost.c | 63 +
 include/hw/virtio/vhost-backend.h |  8 
 include/hw/virtio/vhost.h | 16 +++
 5 files changed, 224 insertions(+)

diff --git a/docs/interop/vhost-user.txt b/docs/interop/vhost-user.txt
index 954771d..1b98388 100644
--- a/docs/interop/vhost-user.txt
+++ b/docs/interop/vhost-user.txt
@@ -116,6 +116,16 @@ Depending on the request type, payload can be:
 - 3: IOTLB invalidate
 - 4: IOTLB access fail
 
+ * Virtio device config space
+   ---
+   | offset | size | payload |
+   ---
+
+   Offset: a 32-bit offset of virtio device's configuration space
+   Size: a 32-bit size of configuration space that master wanted to change
+   Payload: a 256-bytes array holding the contents of the virtio
+   device's configuration space
+
 In QEMU the vhost-user message is implemented with the following struct:
 
 typedef struct VhostUserMsg {
@@ -129,6 +139,7 @@ typedef struct VhostUserMsg {
 VhostUserMemory memory;
 VhostUserLog log;
 struct vhost_iotlb_msg iotlb;
+VhostUserConfig config;
 };
 } QEMU_PACKED VhostUserMsg;
 
@@ -596,6 +607,34 @@ Master message types
   and expect this message once (per VQ) during device configuration
   (ie. before the master starts the VQ).
 
+ * VHOST_USER_GET_CONFIG
+  Id: 24
+  Equivalent ioctl: N/A
+  Master payload: virtio device config space
+
+  Submitted by the vhost-user master to fetch the contents of the virtio
+  device configuration space. The vhost-user master may cache the contents
+  to avoid repeated VHOST_USER_GET_CONFIG calls.
+
+* VHOST_USER_SET_CONFIG
+  Id: 25
+  Equivalent ioctl: N/A
+  Master payload: virtio device config space
+
+  Submitted by the vhost-user master when the Guest changes the virtio
+  device configuration space and also can be used for live migration
+  on the destination host.
+
+* VHOST_USER_SET_CONFIG_FD
+  Id: 26
+  Equivalent ioctl: N/A
+  Master payload: N/A
+
+  Sets the notifier file descriptor, which is passed as ancillary data.
+  The vhost-user slave uses the file descriptor to notify the vhost-user
+  master of changes to the virtio configuration space. The vhost-user
+  master can read the virtio configuration space to get the latest update.
+
 Slave message types
 ---
 
diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
index 093675e..ef1687b 100644
--- a/hw/virtio/vhost-user.c
+++ b/hw/virtio/vhost-user.c
@@ -26,6 +26,11 @@
 #define VHOST_MEMORY_MAX_NREGIONS8
 #define VHOST_USER_F_PROTOCOL_FEATURES 30
 
+/*
+ * Maximum size of virtio device config space
+ */
+#define VHOST_USER_MAX_CONFIG_SIZE 256
+
 enum VhostUserProtocolFeature {
 VHOST_USER_PROTOCOL_F_MQ = 0,
 VHOST_USER_PROTOCOL_F_LOG_SHMFD = 1,
@@ -65,6 +70,9 @@ typedef enum VhostUserRequest {
 VHOST_USER_SET_SLAVE_REQ_FD = 21,
 VHOST_USER_IOTLB_MSG = 22,
 VHOST_USER_SET_VRING_ENDIAN = 23,
+VHOST_USER_GET_CONFIG = 24,
+VHOST_USER_SET_CONFIG = 25,
+VHOST_USER_SET_CONFIG_FD = 26,
 VHOST_USER_MAX
 } VhostUserRequest;
 
@@ -92,6 +100,12 @@ typedef struct VhostUserLog {
 uint64_t mmap_offset;
 } VhostUserLog;
 
+typedef struct VhostUserConfig {
+uint32_t offset;
+uint32_t size;
+uint8_t region[VHOST_USER_MAX_CONFIG_SIZE];
+} VhostUserConfig;
+
 typedef struct VhostUserMsg {
 VhostUserRequest request;
 
@@ -109,6 +123,7 @@ typedef struct VhostUserMsg {
 VhostUserMemory memory;
 VhostUserLog log;
 struct vhost_iotlb_msg iotlb;
+VhostUserConfig config;
 } payload;
 } QEMU_PACKED VhostUserMsg;
 
@@ -922,6 +937,86 @@ static void vhost_user_set_iotlb_callback(struct vhost_dev 
*dev, int enabled)
 /* No-op as the receive channel is not dedicated to IOTLB messages. */
 }
 
+static int vhost_user_get_config(struct vhost_dev *dev, uint8_t *config,
+ size_t config_len)
+{
+VhostUserMsg msg = {
+.request = VHOST_USER_GET_CONFIG,
+.flags = VHOST_USER_VERSION,
+.size = sizeof(msg.payload.config),
+};
+
+if (vhost_user_write(dev, , NULL, 0) < 0) {
+return -1;
+}
+
+if (vhost_user_read(dev, ) < 0) {
+return -1;
+}
+
+if (msg.request != 

Re: [Qemu-devel] [PATCH] colo-compare: fix the dangerous assignment

[Stefan Weil]

Am 16.11.2017 um 03:28 schrieb Mao Zhongyi:
> Cc: Peter Maydell 
> Cc: Jason Wang 
> Cc: Zhang Chen 
> Cc: Li Zhijian 
> Cc: Paolo Bonzini 
> Fixes: 8ec14402029d783720f4312ed8a925548e1dad61
> Reported-by: Peter Maydell 
> Reported-by: Paolo Bonzini 
> Signed-off-by: Mao Zhongyi 
> ---
>  net/colo-compare.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/colo-compare.c b/net/colo-compare.c
> index ccdcba2..1ce195f 100644
> --- a/net/colo-compare.c
> +++ b/net/colo-compare.c
> @@ -179,7 +179,7 @@ static int packet_enqueue(CompareState *s, int mode, 
> Connection **con)
>   "drop packet");
>  }
>  }
> -con = 
> +*con = conn;
>  
>  return 0;
>  }

The patch is definitely needed if the new function parameter con
should work.

It also fixes a gcc compiler warning:
net/colo-compare.c:139:67: warning: parameter ‘con’ set but not used
[-Wunused-but-set-parameter]

I‌ think using -Wextra would be really good to catch such bugs earlier.

Regards,
Stefan

Re: [Qemu-devel] [PATCH 0/4] Some trivial fixes, mostly comment typos

[Emilio G. Cota]

On Wed, Oct 18, 2017 at 18:01:39 -0400, Emilio G. Cota wrote:
> A few trivial fixes that I embedded in a previous (unrelated) patchset.
> Better to submit them separately as a standalone "trivial" patchset.

*ping*

Can someone please pick up patches 1, 3 and 4?

Thanks,

Emilio

[Qemu-devel] [Bug 1719984] Re: wrgsbase misemulated in x86_64-softmmu

[Todd Eisenberger]

Fix is in master:
https://github.com/qemu/qemu/commit/e0dd5fd41a1a38766009f442967fab700d2d0550

** Changed in: qemu
   Status: In Progress => Fix Committed

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

Title:
  wrgsbase misemulated in x86_64-softmmu

Status in QEMU:
  Fix Committed

Bug description:
  qemu revision: cfe4cade054c0e0d00d0185cdc433a9e3ce3e2e4
  command: ./qemu-system-x86_64 -m 2048 -nographic -net none -smp 4,threads=2 
-machine q35 -kernel zircon.bin -cpu Haswell,+smap,-check -initrd bootdata.bin 
-append 'TERM=screen kernel.halt-on-panic=true '

  On this revision, the VM reports CPUID.07H.0H.EBX[0] = 1.  In this VM,
  with CR4[16] set to 1, wrgsbase triggers #UD, which mismatches the
  behavior described in Intel's instruction reference.

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

[Qemu-devel] [PATCH for-2.11] MAINTAINERS: Add missing entry for eepro100 emulation

[Stefan Weil]

Signed-off-by: Stefan Weil 
---
 MAINTAINERS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ffd77b461c..83434e09af 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1183,6 +1183,11 @@ M: Dmitry Fleytman 
 S: Maintained
 F: hw/net/e1000e*
 
+eepro100
+M: Stefan Weil 
+S: Maintained
+F: hw/net/eepro100.c
+
 Generic Loader
 M: Alistair Francis 
 S: Maintained
-- 
2.11.0

Re: [Qemu-devel] [PULL for-2.11 0/1] Block patches

[Peter Maydell]

On 16 November 2017 at 16:36, Stefan Hajnoczi  wrote:
> The following changes since commit 8048082f7a11040a366942a2de8abb4c3d0020c9:
>
>   Merge remote-tracking branch 
> 'remotes/stefanberger/tags/pull-tpm-2017-11-15-1' into staging (2017-11-16 
> 11:34:24 +)
>
> are available in the git repository at:
>
>   git://github.com/stefanha/qemu.git tags/block-pull-request
>
> for you to fetch changes up to 341e0b5658681f46680024cdbfc998717d85cc35:
>
>   throttle-groups: forget timer and schedule next TGM on detach (2017-11-16 
> 14:12:57 +)
>
> 
>
> 
>
> Stefan Hajnoczi (1):
>   throttle-groups: forget timer and schedule next TGM on detach
>
>  block/throttle-groups.c | 12 
>  1 file changed, 12 insertions(+)

Applied, thanks.

-- PMM

[Qemu-devel] [PATCH 2/2] vhost: restore avail index from vring used index on disconnection

[Maxime Coquelin]

vhost_virtqueue_stop() gets avail index value from the backend,
except if the backend is not responding.

It happens when the backend crashes, and in this case, internal
state of the virtio queue is inconsistent, making packets
to corrupt the vring state.

With a Linux guest, it results in following error message on
backend reconnection:

[   22.444905] virtio_net virtio0: output.0:id 0 is not a head!
[   22.446746] net enp0s3: Unexpected TXQ (0) queue failure: -5
[   22.476360] net enp0s3: Unexpected TXQ (0) queue failure: -5

Fixes: 283e2c2adcb8 ("net: virtio-net discards TX data after link down")
Cc: qemu-sta...@nongnu.org
Signed-off-by: Maxime Coquelin 
---
 hw/virtio/vhost.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index ddc42f0f93..54041948cf 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -1138,6 +1138,10 @@ static void vhost_virtqueue_stop(struct vhost_dev *dev,
 r = dev->vhost_ops->vhost_get_vring_base(dev, );
 if (r < 0) {
 VHOST_OPS_DEBUG("vhost VQ %d ring restore failed: %d", idx, r);
+/* Connection to the backend is broken, so let's sync internal
+ * last avail idx to the device used idx.
+ */
+virtio_queue_restore_last_avail_idx(vdev, idx);
 } else {
 virtio_queue_set_last_avail_idx(vdev, idx, state.num);
 }
-- 
2.14.3

[Qemu-devel] [PATCH 1/2] virtio: Add queue interface to restore avail index from vring used index

[Maxime Coquelin]

In case of backend crash, it is not possible to restore internal
avail index from the backend value as vhost_get_vring_base
callback fails.

This patch provides a new interface to restore internal avail index
from the vring used index, as done by some vhost-user backend on
reconnection.

Signed-off-by: Maxime Coquelin 
---
 hw/virtio/virtio.c | 10 ++
 include/hw/virtio/virtio.h |  1 +
 2 files changed, 11 insertions(+)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 5884ce3480..583516c428 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -2310,6 +2310,16 @@ void virtio_queue_set_last_avail_idx(VirtIODevice *vdev, 
int n, uint16_t idx)
 vdev->vq[n].shadow_avail_idx = idx;
 }
 
+void virtio_queue_restore_last_avail_idx(VirtIODevice *vdev, int n)
+{
+rcu_read_lock();
+if (vdev->vq[n].vring.desc) {
+vdev->vq[n].last_avail_idx = vring_used_idx(>vq[n]);
+vdev->vq[n].shadow_avail_idx = vdev->vq[n].last_avail_idx;
+}
+rcu_read_unlock();
+}
+
 void virtio_queue_update_used_idx(VirtIODevice *vdev, int n)
 {
 rcu_read_lock();
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index 5abada6966..098bdaaea3 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -272,6 +272,7 @@ hwaddr virtio_queue_get_avail_size(VirtIODevice *vdev, int 
n);
 hwaddr virtio_queue_get_used_size(VirtIODevice *vdev, int n);
 uint16_t virtio_queue_get_last_avail_idx(VirtIODevice *vdev, int n);
 void virtio_queue_set_last_avail_idx(VirtIODevice *vdev, int n, uint16_t idx);
+void virtio_queue_restore_last_avail_idx(VirtIODevice *vdev, int n);
 void virtio_queue_invalidate_signalled_used(VirtIODevice *vdev, int n);
 void virtio_queue_update_used_idx(VirtIODevice *vdev, int n);
 VirtQueue *virtio_get_queue(VirtIODevice *vdev, int n);
-- 
2.14.3

[Qemu-devel] [PATCH 0/2] virtio-net: Fix TX data discard on backend disconnection

[Maxime Coquelin]

This series fixes TX data discard when backend disconnects.

On backend disconnection, QEMU cannot retrieve its internal
avail index, which makes the virtio queue internal state
inconsistent (last_avail_idx will always be 0, whereas used_idx
is correct).

It results in discarding TX data to corrupt the vring state, by
completing descriptors already completed by the backend.

This series fixes this by restoring last_avail_idx to the vring
used idx, as some backends used to do on reconnection.

Maxime Coquelin (2):
  virtio: Add queue interface to restore avail index from vring used
index
  vhost: restore avail index from vring used index on disconnection

 hw/virtio/vhost.c  |  4 
 hw/virtio/virtio.c | 10 ++
 include/hw/virtio/virtio.h |  1 +
 3 files changed, 15 insertions(+)

-- 
2.14.3

Re: [Qemu-devel] [Qemu-ppc] [QEMU-PPC] [PATCH] target/ppc: Update setting of cpu features to account for compat modes

[Greg Kurz]

On Thu, 16 Nov 2017 15:16:07 +1100
Suraj Jitindar Singh  wrote:

> The device tree nodes ibm,arch-vec-5-platform-support and ibm,pa-features
> are used to communicate features of the cpu to the guest operating
> system. The properties of each of these are determined based on the
> selected cpu model and the availability of hypervisor features.
> Currently the compatibility mode of the cpu is not taken into account.
> 
> The ibm,arch-vec-5-platform-support node is used to communicate the
> level of support for various ISAv3 processor features to the guest
> before CAS to inform the guests' request. The available mmu mode should
> only be hash unless the cpu is a POWER9 which is not in a prePOWER9
> compat mode, in which case the available modes depend on the
> accelerator and the hypervisor capabilities.
> 
> The ibm,pa-featues node is used to communicate the level of cpu support
> for various features to the guest os. This should only contain features
> relevant to the operating mode of the processor, that is the selected
> cpu model taking into account any compat mode. This means that the
> compat mode should be taken into account when choosing the properties of
> ibm,pa-features and they should match the compat mode selected, or the
> cpu model selected if no compat mode.
> 
> Update the setting of these cpu features in the device tree as described
> above to properly take into account any compat mode.
> 
> Signed-off-by: Suraj Jitindar Singh 
> ---
>  hw/ppc/spapr.c | 38 +-
>  1 file changed, 33 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index d682f01..0dab6f1 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -44,6 +44,7 @@
>  #include "migration/register.h"
>  #include "mmu-hash64.h"
>  #include "mmu-book3s-v3.h"
> +#include "cpu-models.h"
>  #include "qom/cpu.h"
>  
>  #include "hw/boards.h"
> @@ -255,6 +256,7 @@ static int spapr_fixup_cpu_numa_dt(void *fdt, int offset, 
> PowerPCCPU *cpu)
>  static void spapr_populate_pa_features(CPUPPCState *env, void *fdt, int 
> offset,
>bool legacy_guest)
>  {
> +PowerPCCPU *cpu = ppc_env_get_cpu(env);

If spapr_populate_pa_features() now needs to peek into PowerPCCPU, then it
should be passed a PowerPCCPU * instead of doing container_of() contorsions.
Both callers, spapr_fixup_cpu_dt() and spapr_populate_cpu_dt() can do that.

>  uint8_t pa_features_206[] = { 6, 0,
>  0xf6, 0x1f, 0xc7, 0x00, 0x80, 0xc0 };
>  uint8_t pa_features_207[] = { 24, 0,
> @@ -290,16 +292,36 @@ static void spapr_populate_pa_features(CPUPPCState 
> *env, void *fdt, int offset,
>  uint8_t *pa_features;
>  size_t pa_size;
>  
> -switch (POWERPC_MMU_VER(env->mmu_model)) {
> -case POWERPC_MMU_VER_2_06:
> +switch (cpu->compat_pvr) {
> +case 0:
> +/* If not in a compat mode then determine based on the mmu model */
> +switch (POWERPC_MMU_VER(env->mmu_model)) {
> +case POWERPC_MMU_VER_2_06:
> +pa_features = pa_features_206;
> +pa_size = sizeof(pa_features_206);
> +break;
> +case POWERPC_MMU_VER_2_07:
> +pa_features = pa_features_207;
> +pa_size = sizeof(pa_features_207);
> +break;
> +case POWERPC_MMU_VER_3_00:
> +pa_features = pa_features_300;
> +pa_size = sizeof(pa_features_300);
> +break;
> +default:
> +return;
> +}
> +break;
> +case CPU_POWERPC_LOGICAL_2_06:
> +case CPU_POWERPC_LOGICAL_2_06_PLUS:
>  pa_features = pa_features_206;
>  pa_size = sizeof(pa_features_206);
>  break;
> -case POWERPC_MMU_VER_2_07:
> +case CPU_POWERPC_LOGICAL_2_07:
>  pa_features = pa_features_207;
>  pa_size = sizeof(pa_features_207);
>  break;
> -case POWERPC_MMU_VER_3_00:
> +case CPU_POWERPC_LOGICAL_3_00:
>  pa_features = pa_features_300;
>  pa_size = sizeof(pa_features_300);
>  break;
> @@ -941,6 +963,7 @@ static void spapr_dt_rtas(sPAPRMachineState *spapr, void 
> *fdt)
>  static void spapr_dt_ov5_platform_support(void *fdt, int chosen)
>  {
>  PowerPCCPU *first_ppc_cpu = POWERPC_CPU(first_cpu);
> +CPUPPCState *env = _ppc_cpu->env;
>  
>  char val[2 * 4] = {
>  23, 0x00, /* Xive mode, filled in below. */
> @@ -949,7 +972,12 @@ static void spapr_dt_ov5_platform_support(void *fdt, int 
> chosen)
>  26, 0x40, /* Radix options: GTSE == yes. */
>  };
>  
> -if (kvm_enabled()) {
> +if (POWERPC_MMU_VER(env->mmu_model) != POWERPC_MMU_VER_3_00 ||
> +(first_ppc_cpu->compat_pvr && (first_ppc_cpu->compat_pvr <
> +   CPU_POWERPC_LOGICAL_3_00))) {
> +/* If we're in a pre POWER9 compat mode then the guest should do 
> hash */
> +val[3] = 

Re: [Qemu-devel] [PATCH v1 for-2.11 2/3] s390x/tcg: fix DIAG 308 with > 1 VCPU (single threaded TCG)

[David Hildenbrand]

On 16.11.2017 19:12, Alex Bennée wrote:
> 
> David Hildenbrand  writes:
> 
>> On 16.11.2017 18:37, Alex Bennée wrote:
>>>
>>> David Hildenbrand  writes:
>>>
 Currently, single threaded TCG with > 1 VCPU gets stuck during IPL, when
 the bios tries to switch to the loaded kernel via DIAG 308.

 pause_all_vcpus()/resume_all_vcpus() should not be called from a VCPU.

 And there is also no need for it. run_on_cpu() will make sure that the
 CPUs exit KVM/TCG, where they get stopped. Once stopped, they will no
 longer run.

 Signed-off-by: David Hildenbrand 
 ---
  target/s390x/diag.c | 4 
  1 file changed, 4 deletions(-)

 diff --git a/target/s390x/diag.c b/target/s390x/diag.c
 index dbbb9e886f..52bc348808 100644
 --- a/target/s390x/diag.c
 +++ b/target/s390x/diag.c
 @@ -27,7 +27,6 @@ static int modified_clear_reset(S390CPU *cpu)
  S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
  CPUState *t;

 -pause_all_vcpus();
  cpu_synchronize_all_states();
  CPU_FOREACH(t) {
  run_on_cpu(t, s390_do_cpu_full_reset, RUN_ON_CPU_NULL);
>>>
>>> I think you also need to fix the run_on_cpu to be a async_run_on_cpu as
>>> you would otherwise hang waiting for run_on_cpu to finish on a
>>> single-threaded TCG run (as you are in the only vCPU context).
>>
>> No, it works just fine for single threaded TCG. run_on_cpu() can deal
>> with single threaded TCG just fine. (otherwise e.g. SIGP code also
>> wouldn't work)
>>
>> In do_run_on_cpu, the following code always directly triggers for single
>> threaded tcg:
>>
>> if (qemu_cpu_is_self(cpu)) {
>>
>> func(cpu, data);
>>
>> return;
>>
>> }
> 
> For -smp 1 it's fine, but have you tested --accel thread=single -smp 2?

Yes, otherwise I would never have noticed this bug ;)

I use for my current single threaded setup:
"--accel thread=single -smp 4"

The point is: if run_on_cpu() would not be able to cope with this very
simple problem, it would basically be useless.

instead of scheduling work, it simply executes all these functions
directly for single threaded TCG. For multi threaded TCG it actually
schedules work, that's why I notice the missing iolock (see patch
following this one)

> 
>>
>>>
>>> If it is important that the source vCPU doesn't continue you can
>>> schedule it's work afterwards with a async_safe_run_on_cpu which will
>>> complete after all other vCPUs have executed their work.
>>>
>>
>> It is important. Introducing async helpers at a point where sync is
>> needed sounds strange.
> 
> Well the helper that schedulules the final async helper also needs to
> exit the run loop at that point, otherwise you are right it would
> attempt to execute a few more instructions in the block.
> 

And the nice thing about run_on_cpu here is for single threaded TCG that
not a single work has to be scheduled.

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH v8 02/14] block/dirty-bitmap: add locked version of bdrv_release_dirty_bitmap

[John Snow]

On 11/16/2017 03:56 AM, Vladimir Sementsov-Ogievskiy wrote:
> 11.11.2017 01:52, John Snow wrote:
>>
>> On 10/30/2017 12:32 PM, Vladimir Sementsov-Ogievskiy wrote:
>>> It is needed to realize bdrv_dirty_bitmap_release_successor in
>>> the following patch.
>>>
>> OK, but...
>>
>>> Signed-off-by: Vladimir Sementsov-Ogievskiy 
>>> ---
>>>   block/dirty-bitmap.c | 25 -
>>>   1 file changed, 20 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/block/dirty-bitmap.c b/block/dirty-bitmap.c
>>> index 81adbeb6d4..981f99d362 100644
>>> --- a/block/dirty-bitmap.c
>>> +++ b/block/dirty-bitmap.c
>>> @@ -326,13 +326,13 @@ static bool
>>> bdrv_dirty_bitmap_has_name(BdrvDirtyBitmap *bitmap)
>>>   return !!bdrv_dirty_bitmap_name(bitmap);
>>>   }
>>>   -/* Called with BQL taken.  */
>>> -static void bdrv_do_release_matching_dirty_bitmap(
>>> +/* Called within bdrv_dirty_bitmap_lock..unlock */
>> ...Add this so it will compile:
>>
>> __attribute__((__unused__))
> 
> ok
> 
>>> +static void bdrv_do_release_matching_dirty_bitmap_locked(
>>>   BlockDriverState *bs, BdrvDirtyBitmap *bitmap,
>>>   bool (*cond)(BdrvDirtyBitmap *bitmap))
>>>   {
>>>   BdrvDirtyBitmap *bm, *next;
>>> -    bdrv_dirty_bitmaps_lock(bs);
>>> +
>>>   QLIST_FOREACH_SAFE(bm, >dirty_bitmaps, list, next) {
>>>   if ((!bitmap || bm == bitmap) && (!cond || cond(bm))) {
>>>   assert(!bm->active_iterators);
>>> @@ -344,18 +344,33 @@ static void bdrv_do_release_matching_dirty_bitmap(
>>>   g_free(bm);
>>>     if (bitmap) {
>>> -    goto out;
>>> +    return;
>>>   }
>>>   }
>>>   }
>>> +
>>>   if (bitmap) {
>>>   abort();
>>>   }
>> Do we have any style guide rules on using abort() instead of assert()?
>> The rest of this function uses assert, and it'd be less lines to simply
>> write:
>>
>> assert(!bitmap);
>>
>> which I think might also carry better semantic information for coverity
>> beyond an actual runtime conditional branch.
>>
>> (I think. Please correct me if I am wrong, I'm a little hazy on this.)
> 
> agree, but it is a preexisting code, so I'll fix it with an additional
> patch.
> 

You're right. I didn't notice it was pre-existing where I was looking at
it. I'll send my own little fixup. My mistake.

>>
>>> +}
>>>   -out:
>>> +/* Called with BQL taken.  */
>>> +static void bdrv_do_release_matching_dirty_bitmap(
>>> +    BlockDriverState *bs, BdrvDirtyBitmap *bitmap,
>>> +    bool (*cond)(BdrvDirtyBitmap *bitmap))
>>> +{
>>> +    bdrv_dirty_bitmaps_lock(bs);
>>> +    bdrv_do_release_matching_dirty_bitmap_locked(bs, bitmap, cond);
>>>   bdrv_dirty_bitmaps_unlock(bs);
>>>   }
>>>   +/* Called within bdrv_dirty_bitmap_lock..unlock */
>>> +static void bdrv_release_dirty_bitmap_locked(BlockDriverState *bs,
>>> + BdrvDirtyBitmap *bitmap)
>>> +{
>>> +    bdrv_do_release_matching_dirty_bitmap_locked(bs, bitmap, NULL);
>>> +}
>>> +
>>>   /* Called with BQL taken.  */
>>>   void bdrv_release_dirty_bitmap(BlockDriverState *bs,
>>> BdrvDirtyBitmap *bitmap)
>>>   {
>>>
>> If you agree with those two changes, you may add:
> 
> ok
> 
>>
>> Reviewed-by: John Snow 
> 
> 

Just make sure it compiles standalone by using the unused attribute and
you can add the RB.

--js

Re: [Qemu-devel] [PATCH v1 for-2.11 2/3] s390x/tcg: fix DIAG 308 with > 1 VCPU (single threaded TCG)

[Alex Bennée]

David Hildenbrand  writes:

> On 16.11.2017 18:37, Alex Bennée wrote:
>>
>> David Hildenbrand  writes:
>>
>>> Currently, single threaded TCG with > 1 VCPU gets stuck during IPL, when
>>> the bios tries to switch to the loaded kernel via DIAG 308.
>>>
>>> pause_all_vcpus()/resume_all_vcpus() should not be called from a VCPU.
>>>
>>> And there is also no need for it. run_on_cpu() will make sure that the
>>> CPUs exit KVM/TCG, where they get stopped. Once stopped, they will no
>>> longer run.
>>>
>>> Signed-off-by: David Hildenbrand 
>>> ---
>>>  target/s390x/diag.c | 4 
>>>  1 file changed, 4 deletions(-)
>>>
>>> diff --git a/target/s390x/diag.c b/target/s390x/diag.c
>>> index dbbb9e886f..52bc348808 100644
>>> --- a/target/s390x/diag.c
>>> +++ b/target/s390x/diag.c
>>> @@ -27,7 +27,6 @@ static int modified_clear_reset(S390CPU *cpu)
>>>  S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
>>>  CPUState *t;
>>>
>>> -pause_all_vcpus();
>>>  cpu_synchronize_all_states();
>>>  CPU_FOREACH(t) {
>>>  run_on_cpu(t, s390_do_cpu_full_reset, RUN_ON_CPU_NULL);
>>
>> I think you also need to fix the run_on_cpu to be a async_run_on_cpu as
>> you would otherwise hang waiting for run_on_cpu to finish on a
>> single-threaded TCG run (as you are in the only vCPU context).
>
> No, it works just fine for single threaded TCG. run_on_cpu() can deal
> with single threaded TCG just fine. (otherwise e.g. SIGP code also
> wouldn't work)
>
> In do_run_on_cpu, the following code always directly triggers for single
> threaded tcg:
>
> if (qemu_cpu_is_self(cpu)) {
>
> func(cpu, data);
>
> return;
>
> }

Sorry ignore what I said, qemu_cpu_is_self tests the underlying thread
not the vCPU which they all share.


--
Alex Bennée

Re: [Qemu-devel] [PATCH v1 for-2.11 2/3] s390x/tcg: fix DIAG 308 with > 1 VCPU (single threaded TCG)

[Alex Bennée]

David Hildenbrand  writes:

> On 16.11.2017 18:37, Alex Bennée wrote:
>>
>> David Hildenbrand  writes:
>>
>>> Currently, single threaded TCG with > 1 VCPU gets stuck during IPL, when
>>> the bios tries to switch to the loaded kernel via DIAG 308.
>>>
>>> pause_all_vcpus()/resume_all_vcpus() should not be called from a VCPU.
>>>
>>> And there is also no need for it. run_on_cpu() will make sure that the
>>> CPUs exit KVM/TCG, where they get stopped. Once stopped, they will no
>>> longer run.
>>>
>>> Signed-off-by: David Hildenbrand 
>>> ---
>>>  target/s390x/diag.c | 4 
>>>  1 file changed, 4 deletions(-)
>>>
>>> diff --git a/target/s390x/diag.c b/target/s390x/diag.c
>>> index dbbb9e886f..52bc348808 100644
>>> --- a/target/s390x/diag.c
>>> +++ b/target/s390x/diag.c
>>> @@ -27,7 +27,6 @@ static int modified_clear_reset(S390CPU *cpu)
>>>  S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
>>>  CPUState *t;
>>>
>>> -pause_all_vcpus();
>>>  cpu_synchronize_all_states();
>>>  CPU_FOREACH(t) {
>>>  run_on_cpu(t, s390_do_cpu_full_reset, RUN_ON_CPU_NULL);
>>
>> I think you also need to fix the run_on_cpu to be a async_run_on_cpu as
>> you would otherwise hang waiting for run_on_cpu to finish on a
>> single-threaded TCG run (as you are in the only vCPU context).
>
> No, it works just fine for single threaded TCG. run_on_cpu() can deal
> with single threaded TCG just fine. (otherwise e.g. SIGP code also
> wouldn't work)
>
> In do_run_on_cpu, the following code always directly triggers for single
> threaded tcg:
>
> if (qemu_cpu_is_self(cpu)) {
>
> func(cpu, data);
>
> return;
>
> }

For -smp 1 it's fine, but have you tested --accel thread=single -smp 2?

>
>>
>> If it is important that the source vCPU doesn't continue you can
>> schedule it's work afterwards with a async_safe_run_on_cpu which will
>> complete after all other vCPUs have executed their work.
>>
>
> It is important. Introducing async helpers at a point where sync is
> needed sounds strange.

Well the helper that schedulules the final async helper also needs to
exit the run loop at that point, otherwise you are right it would
attempt to execute a few more instructions in the block.

>
> Thanks!
>
>>>
>>> --
>>> 2.13.6
>>
>>
>> --
>> Alex Bennée
>>
>
>
> --
>
> Thanks,
>
> David / dhildenb


--
Alex Bennée

Re: [Qemu-devel] [PATCH v2 1/2] Fix eepro100 simple transmission mode

[Michael Nawrocki]

On 11/16/2017 12:43 PM, Thomas Huth wrote:

On 16.11.2017 17:59, Thomas Huth wrote:

On 06.11.2017 21:35, Mike Nawrocki wrote:

The simple transmission mode was treating the area immediately after the
transmit command block (TCB) as if it were a transmit buffer descriptor,
when in reality it is simply the packet data. This change simply copies
the data following the TCB into the packet buffer.

Signed-off-by: Mike Nawrocki 
---
  hw/net/eepro100.c | 18 +++---
  1 file changed, 3 insertions(+), 15 deletions(-)

diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c
index 80b8f47c4b..91dd058010 100644
--- a/hw/net/eepro100.c
+++ b/hw/net/eepro100.c
@@ -774,23 +774,11 @@ static void tx_command(EEPRO100State *s)
  }
  assert(tcb_bytes <= sizeof(buf));
  while (size < tcb_bytes) {
-uint32_t tx_buffer_address = ldl_le_pci_dma(>dev, tbd_address);
-uint16_t tx_buffer_size = lduw_le_pci_dma(>dev, tbd_address + 4);
-#if 0
-uint16_t tx_buffer_el = lduw_le_pci_dma(>dev, tbd_address + 6);
-#endif
-if (tx_buffer_size == 0) {
-/* Prevent an endless loop. */
-logout("loop in %s:%u\n", __FILE__, __LINE__);
-break;
-}
-tbd_address += 8;
  TRACE(RXTX, logout
  ("TBD (simplified mode): buffer address 0x%08x, size 0x%04x\n",
- tx_buffer_address, tx_buffer_size));
-tx_buffer_size = MIN(tx_buffer_size, sizeof(buf) - size);
-pci_dma_read(>dev, tx_buffer_address, [size], tx_buffer_size);
-size += tx_buffer_size;
+ tbd_address, tcb_bytes));
+pci_dma_read(>dev, tbd_address, [size], tcb_bytes);
+size += tcb_bytes;
  }
  if (tbd_array == 0x) {
  /* Simplified mode. Was already handled by code above. */



  Hi,

I've got no clue why, but apparently this patch introduced a regression
in rc1: The tests/pxe-test is now failing on a big endian (s390x) host
when testing the i82550 device.
It's working fine with commit 8fa5ad6dfb66b6c695aa6a6b54b7031c (and
2.11-rc0), and it's broken starting with commit
1865e288a823c764cd4344d704e33344 ... do you have any clue what might be
wrong here now?


This patch seems to fix the issue for me:

diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c
index a63ed2c..03e00f7 100644
--- a/hw/net/eepro100.c
+++ b/hw/net/eepro100.c
@@ -756,8 +756,8 @@ static void read_cb(EEPRO100State *s)
  
  static void tx_command(EEPRO100State *s)

  {
-uint32_t tbd_array = le32_to_cpu(s->tx.tbd_array_addr);
-uint16_t tcb_bytes = (le16_to_cpu(s->tx.tcb_bytes) & 0x3fff);
+uint32_t tbd_array = s->tx.tbd_array_addr;
+uint16_t tcb_bytes = s->tx.tcb_bytes & 0x3fff;
  /* Sends larger than MAX_ETH_FRAME_SIZE are allowed, up to 2600 bytes. */
  uint8_t buf[2600];
  uint16_t size = 0;

Does that make sense? I think the fields are already swapped in
read_cb(), so no need to swap them in tx_command() again?

  Thomas



That makes sense to me. Not entirely sure why my patch caused the 
regression, but your patch seems like the correct behavior here.


Thanks,
Mike

Re: [Qemu-devel] Effect of qemu-img convert -m and -W options

[Richard W.M. Jones]

On Thu, Nov 16, 2017 at 05:30:48PM +, Stefan Hajnoczi wrote:
> On Thu, Nov 16, 2017 at 3:10 PM, Richard W.M. Jones  wrote:
> > Both local filesystems, but on different SATA devices.
> 
> Okay.  I'm curious what the strace -f output looks like (only the
> preadv(2)/pwritev(2) syscalls are interesting at the moment).

Here's the full strace from one run:

  http://oirase.annexia.org/tmp/strace.xz

The command is (with the output.qcow2 file created in a previous run):

  $ strace -o /tmp/strace -f -s 1024 qemu-img convert -f raw fedora-27.img -O 
qcow2 /var/tmp/output.qcow2 -m 8 -W -n

The version of qemu is: qemu-2.10.0-7.fc28.x86_64

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

Re: [Qemu-devel] [PATCH] hax-interface: Add BSD license

[Eduardo Habkost]

On Thu, Nov 16, 2017 at 07:47:44AM +0100, Stefan Weil wrote:
> Am 16.11.2017 um 07:50 schrieb yu.n...@linux.intel.com:
> > From: Yu Ning 
> > 
> > hax-interface.h defines the interface between the HAXM kernel
> > module and the HAXM QEMU accelerator. The same code can be found in
> > the following files of the HAXM kernel module:
> > 
> >  include/hax_interface.h
> >  include/vcpu_state.h
> >  core/include/vm.h
> > 
> > These files are now open source under the 3-clause BSD license,
> > whereas hax-interface.h in QEMU uses GPLv2.

Why is this a problem?


> > 
> > Address this inconsistency by adding the BSD license to the QEMU
> > file, per Stefan Weil's comment on this HAXM pull request:
> > 
> >  https://github.com/intel/haxm/pull/2

The existing code on qemu.git don't match the code on the GitHub
repository above exactly, and its copyright history looks hard to
track[1].  If we really care about consistency between the two
projects, shouldn't we just delete the existing file and copy the
headers from github.com/intel/haxm directly?


[1] https://github.com/qemu/qemu/commit/47c1c8c12f6c8b3c6e0da7bbd93fd4e1724cf114

https://android.googlesource.com/platform/external/qemu-android/+/2b3098ff27bab079caab9b46b58546b5036f5c0c/target-i386/hax-interface.h

Also, does it even make sense to keep the two licenses in the
file?


> > 
> > Signed-off-by: Yu Ning 
> > ---
> >  target/i386/hax-interface.h | 29 +
> >  1 file changed, 29 insertions(+)
> > 
> > diff --git a/target/i386/hax-interface.h b/target/i386/hax-interface.h
> > index d141308..9a36c9a 100644
> > --- a/target/i386/hax-interface.h
> > +++ b/target/i386/hax-interface.h
> > @@ -1,4 +1,33 @@
> >  /*
> > + * Copyright (c) 2011 Intel Corporation
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions are 
> > met:
> > + *
> > + *   1. Redistributions of source code must retain the above copyright 
> > notice,
> > + *  this list of conditions and the following disclaimer.
> > + *
> > + *   2. Redistributions in binary form must reproduce the above copyright
> > + *  notice, this list of conditions and the following disclaimer in the
> > + *  documentation and/or other materials provided with the 
> > distribution.
> > + *
> > + *   3. Neither the name of the copyright holder nor the names of its
> > + *  contributors may be used to endorse or promote products derived 
> > from
> > + *  this software without specific prior written permission.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> > IS"
> > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, 
> > THE
> > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 
> > PURPOSE
> > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS 
> > BE
> > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF 
> > THE
> > + * POSSIBILITY OF SUCH DAMAGE.
> > + */
> > +/*
> >   * QEMU HAXM support
> >   *
> >   * Copyright (c) 2011 Intel Corporation
> > 
> 
> Reviewed-by: Stefan Weil 
> 
> CC'ing Vincent who added the file to the QEMU code base.
> 
> Maybe the two licenses in the header could be re-arranged when merging
> that commit.

-- 
Eduardo

[Qemu-devel] [PATCH v2 6/7] s390x/pci: move the memory region write from pcistg

[Pierre Morel]

Let's move the memory region write from pcistg into a dedicated
function.
This allows us to prepare a later patch searching for subregions
inside of the memory region.

Signed-off-by: Pierre Morel 
Reviewed-by: Yi Min Zhao 
---
 hw/s390x/s390-pci-inst.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
index d46d4cd..eef3b89 100644
--- a/hw/s390x/s390-pci-inst.c
+++ b/hw/s390x/s390-pci-inst.c
@@ -454,12 +454,27 @@ static int trap_msix(S390PCIBusDevice *pbdev, uint64_t 
offset, uint8_t pcias)
 }
 }
 
+static MemTxResult zpci_write_bar(S390PCIBusDevice *pbdev, uint8_t pcias,
+  uint64_t offset, uint64_t data, uint8_t len)
+{
+MemoryRegion *mr;
+
+if (trap_msix(pbdev, offset, pcias)) {
+offset = offset - pbdev->msix.table_offset;
+mr = >pdev->msix_table_mmio;
+} else {
+mr = pbdev->pdev->io_regions[pcias].memory;
+}
+
+return memory_region_dispatch_write(mr, offset, data, len,
+MEMTXATTRS_UNSPECIFIED);
+}
+
 int pcistg_service_call(S390CPU *cpu, uint8_t r1, uint8_t r2)
 {
 CPUS390XState *env = >env;
 uint64_t offset, data;
 S390PCIBusDevice *pbdev;
-MemoryRegion *mr;
 MemTxResult result;
 uint8_t len;
 uint32_t fh;
@@ -516,15 +531,7 @@ int pcistg_service_call(S390CPU *cpu, uint8_t r1, uint8_t 
r2)
 return 0;
 }
 
-if (trap_msix(pbdev, offset, pcias)) {
-offset = offset - pbdev->msix.table_offset;
-mr = >pdev->msix_table_mmio;
-} else {
-mr = pbdev->pdev->io_regions[pcias].memory;
-}
-
-result = memory_region_dispatch_write(mr, offset, data, len,
- MEMTXATTRS_UNSPECIFIED);
+result = zpci_write_bar(pbdev, pcias, offset, data, len);
 if (result != MEMTX_OK) {
 program_interrupt(env, PGM_OPERAND, 4);
 return 0;
-- 
2.7.4

[Qemu-devel] [PATCH v2 5/7] s390x/pci: move the memory region read from pcilg

[Pierre Morel]

Let's move the memory region read from pcilg into a dedicated function.
This allows us to prepare a later patch.

Signed-off-by: Pierre Morel 
Reviewed-by: Yi Min Zhao 
---
 hw/s390x/s390-pci-inst.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
index 83b68a9..d46d4cd 100644
--- a/hw/s390x/s390-pci-inst.c
+++ b/hw/s390x/s390-pci-inst.c
@@ -345,13 +345,22 @@ static int zpci_endian_swap(uint64_t *ptr, uint8_t len)
 return 0;
 }
 
+static MemTxResult zpci_read_bar(S390PCIBusDevice *pbdev, uint8_t pcias,
+ uint64_t offset, uint64_t *data, uint8_t len)
+{
+MemoryRegion *mr;
+
+mr = pbdev->pdev->io_regions[pcias].memory;
+return memory_region_dispatch_read(mr, offset, data, len,
+   MEMTXATTRS_UNSPECIFIED);
+}
+
 int pcilg_service_call(S390CPU *cpu, uint8_t r1, uint8_t r2)
 {
 CPUS390XState *env = >env;
 S390PCIBusDevice *pbdev;
 uint64_t offset;
 uint64_t data;
-MemoryRegion *mr;
 MemTxResult result;
 uint8_t len;
 uint32_t fh;
@@ -402,9 +411,7 @@ int pcilg_service_call(S390CPU *cpu, uint8_t r1, uint8_t r2)
 program_interrupt(env, PGM_OPERAND, 4);
 return 0;
 }
-mr = pbdev->pdev->io_regions[pcias].memory;
-result = memory_region_dispatch_read(mr, offset, , len,
- MEMTXATTRS_UNSPECIFIED);
+result = zpci_read_bar(pbdev, pcias, offset, , len);
 if (result != MEMTX_OK) {
 program_interrupt(env, PGM_OPERAND, 4);
 return 0;
-- 
2.7.4

[Qemu-devel] [PATCH v2 3/7] s390x/pci: rework PCI LOAD

[Pierre Morel]

Enhance the fault detection, correction of the fault reporting.

Signed-off-by: Pierre Morel 
Reviewed-by: Yi Min Zhao 
Signed-off-by: Pierre Morel 
---
 hw/s390x/s390-pci-inst.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
index df0c8f0..cbc6421 100644
--- a/hw/s390x/s390-pci-inst.c
+++ b/hw/s390x/s390-pci-inst.c
@@ -373,6 +373,11 @@ int pcilg_service_call(S390CPU *cpu, uint8_t r1, uint8_t 
r2)
 len = env->regs[r2] & 0xf;
 offset = env->regs[r2 + 1];
 
+if (!(fh & FH_MASK_ENABLE)) {
+setcc(cpu, ZPCI_PCI_LS_INVAL_HANDLE);
+return 0;
+}
+
 pbdev = s390_pci_find_dev_by_fh(s390_get_phb(), fh);
 if (!pbdev) {
 DPRINTF("pcilg no pci dev\n");
@@ -381,12 +386,7 @@ int pcilg_service_call(S390CPU *cpu, uint8_t r1, uint8_t 
r2)
 }
 
 switch (pbdev->state) {
-case ZPCI_FS_RESERVED:
-case ZPCI_FS_STANDBY:
-case ZPCI_FS_DISABLED:
 case ZPCI_FS_PERMANENT_ERROR:
-setcc(cpu, ZPCI_PCI_LS_INVAL_HANDLE);
-return 0;
 case ZPCI_FS_ERROR:
 setcc(cpu, ZPCI_PCI_LS_ERR);
 s390_set_status_code(env, r2, ZPCI_PCI_ST_BLOCKED);
@@ -395,8 +395,9 @@ int pcilg_service_call(S390CPU *cpu, uint8_t r1, uint8_t r2)
 break;
 }
 
-if (pcias < 6) {
-if ((8 - (offset & 0x7)) < len) {
+switch (pcias) {
+case 0 ... 5:
+if (!len || (len > (8 - (offset & 0x7 {
 program_interrupt(env, PGM_OPERAND, 4);
 return 0;
 }
@@ -407,8 +408,9 @@ int pcilg_service_call(S390CPU *cpu, uint8_t r1, uint8_t r2)
 program_interrupt(env, PGM_OPERAND, 4);
 return 0;
 }
-} else if (pcias == 15) {
-if ((4 - (offset & 0x3)) < len) {
+break;
+case 15:
+if (!len || (len > (4 - (offset & 0x3))) || len == 3) {
 program_interrupt(env, PGM_OPERAND, 4);
 return 0;
 }
@@ -419,8 +421,9 @@ int pcilg_service_call(S390CPU *cpu, uint8_t r1, uint8_t r2)
 program_interrupt(env, PGM_OPERAND, 4);
 return 0;
 }
-} else {
-DPRINTF("invalid space\n");
+break;
+default:
+DPRINTF("pcilg invalid space\n");
 setcc(cpu, ZPCI_PCI_LS_ERR);
 s390_set_status_code(env, r2, ZPCI_PCI_ST_INVAL_AS);
 return 0;
-- 
2.7.4

[Qemu-devel] [PATCH v2 4/7] s390x/pci: rework PCI STORE BLOCK

[Pierre Morel]

Enhance the fault detection.

Fixup the precedence to check the destination path existance
before checking for the source accessibility.

Add the maxstbl entry to both the Query PCI Function Group
response and the PCIBusDevice structure.

Initialize the maxstbl to 128 per default until we get
the actual data from the hardware.

Signed-off-by: Pierre Morel 
Reviewed-by: Yi Min Zhao 
---
 hw/s390x/s390-pci-bus.h  |  1 +
 hw/s390x/s390-pci-inst.c | 62 +---
 hw/s390x/s390-pci-inst.h |  2 +-
 3 files changed, 40 insertions(+), 25 deletions(-)

diff --git a/hw/s390x/s390-pci-bus.h b/hw/s390x/s390-pci-bus.h
index 560bd82..2993f0d 100644
--- a/hw/s390x/s390-pci-bus.h
+++ b/hw/s390x/s390-pci-bus.h
@@ -284,6 +284,7 @@ struct S390PCIBusDevice {
 uint64_t fmb_addr;
 uint8_t isc;
 uint16_t noi;
+uint16_t maxstbl;
 uint8_t sum;
 S390MsixInfo msix;
 AdapterRoutes routes;
diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
index cbc6421..83b68a9 100644
--- a/hw/s390x/s390-pci-inst.c
+++ b/hw/s390x/s390-pci-inst.c
@@ -294,6 +294,7 @@ int clp_service_call(S390CPU *cpu, uint8_t r2)
 stq_p(>msia, ZPCI_MSI_ADDR);
 stw_p(>mui, 0);
 stw_p(>i, 128);
+stw_p(>maxstbl, 128);
 resgrp->version = 0;
 
 stw_p(>hdr.rsp, CLP_RC_OK);
@@ -645,6 +646,7 @@ int pcistb_service_call(S390CPU *cpu, uint8_t r1, uint8_t 
r3, uint64_t gaddr,
 S390PCIBusDevice *pbdev;
 MemoryRegion *mr;
 MemTxResult result;
+uint64_t offset;
 int i;
 uint32_t fh;
 uint8_t pcias;
@@ -659,22 +661,10 @@ int pcistb_service_call(S390CPU *cpu, uint8_t r1, uint8_t 
r3, uint64_t gaddr,
 fh = env->regs[r1] >> 32;
 pcias = (env->regs[r1] >> 16) & 0xf;
 len = env->regs[r1] & 0xff;
+offset = env->regs[r3];
 
-if (pcias > 5) {
-DPRINTF("pcistb invalid space\n");
-setcc(cpu, ZPCI_PCI_LS_ERR);
-s390_set_status_code(env, r1, ZPCI_PCI_ST_INVAL_AS);
-return 0;
-}
-
-switch (len) {
-case 16:
-case 32:
-case 64:
-case 128:
-break;
-default:
-program_interrupt(env, PGM_SPECIFICATION, 6);
+if (!(fh & FH_MASK_ENABLE)) {
+setcc(cpu, ZPCI_PCI_LS_INVAL_HANDLE);
 return 0;
 }
 
@@ -686,12 +676,7 @@ int pcistb_service_call(S390CPU *cpu, uint8_t r1, uint8_t 
r3, uint64_t gaddr,
 }
 
 switch (pbdev->state) {
-case ZPCI_FS_RESERVED:
-case ZPCI_FS_STANDBY:
-case ZPCI_FS_DISABLED:
 case ZPCI_FS_PERMANENT_ERROR:
-setcc(cpu, ZPCI_PCI_LS_INVAL_HANDLE);
-return 0;
 case ZPCI_FS_ERROR:
 setcc(cpu, ZPCI_PCI_LS_ERR);
 s390_set_status_code(env, r1, ZPCI_PCI_ST_BLOCKED);
@@ -700,8 +685,33 @@ int pcistb_service_call(S390CPU *cpu, uint8_t r1, uint8_t 
r3, uint64_t gaddr,
 break;
 }
 
+if (pcias > 5) {
+DPRINTF("pcistb invalid space\n");
+setcc(cpu, ZPCI_PCI_LS_ERR);
+s390_set_status_code(env, r1, ZPCI_PCI_ST_INVAL_AS);
+return 0;
+}
+
+/* Verify the address, offset and length */
+/* offset must be a multiple of 8 */
+if (offset % 8) {
+goto addressing_error;
+}
+/* Length must be greater than 8, a multiple of 8, not greater maxstbl */
+if ((len <= 8) || (len % 8) || (len > pbdev->maxstbl)) {
+goto addressing_error;
+}
+/* Do not cross a 4K-byte boundary */
+if (((offset & 0xfff) + len) > 0x1000) {
+goto addressing_error;
+}
+/* Guest address must be double word aligned */
+if (gaddr & 0x07UL) {
+goto addressing_error;
+}
+
 mr = pbdev->pdev->io_regions[pcias].memory;
-if (!memory_region_access_valid(mr, env->regs[r3], len, true)) {
+if (!memory_region_access_valid(mr, offset, len, true)) {
 program_interrupt(env, PGM_OPERAND, 6);
 return 0;
 }
@@ -711,9 +721,9 @@ int pcistb_service_call(S390CPU *cpu, uint8_t r1, uint8_t 
r3, uint64_t gaddr,
 }
 
 for (i = 0; i < len / 8; i++) {
-result = memory_region_dispatch_write(mr, env->regs[r3] + i * 8,
- ldq_p(buffer + i * 8), 8,
- MEMTXATTRS_UNSPECIFIED);
+result = memory_region_dispatch_write(mr, offset + i * 8,
+  ldq_p(buffer + i * 8), 8,
+  MEMTXATTRS_UNSPECIFIED);
 if (result != MEMTX_OK) {
 program_interrupt(env, PGM_OPERAND, 6);
 return 0;
@@ -722,6 +732,10 @@ int pcistb_service_call(S390CPU *cpu, uint8_t r1, uint8_t 
r3, uint64_t gaddr,
 
 setcc(cpu, ZPCI_PCI_LS_OK);
 return 0;
+
+addressing_error:
+program_interrupt(env, PGM_SPECIFICATION, 6);
+return 0;
 }
 
 static int reg_irqs(CPUS390XState *env, S390PCIBusDevice *pbdev, ZpciFib fib)
diff --git a/hw/s390x/s390-pci-inst.h 

Re: [Qemu-devel] [PATCH v1 for-2.11 2/3] s390x/tcg: fix DIAG 308 with > 1 VCPU (single threaded TCG)

[David Hildenbrand]

On 16.11.2017 18:37, Alex Bennée wrote:
> 
> David Hildenbrand  writes:
> 
>> Currently, single threaded TCG with > 1 VCPU gets stuck during IPL, when
>> the bios tries to switch to the loaded kernel via DIAG 308.
>>
>> pause_all_vcpus()/resume_all_vcpus() should not be called from a VCPU.
>>
>> And there is also no need for it. run_on_cpu() will make sure that the
>> CPUs exit KVM/TCG, where they get stopped. Once stopped, they will no
>> longer run.
>>
>> Signed-off-by: David Hildenbrand 
>> ---
>>  target/s390x/diag.c | 4 
>>  1 file changed, 4 deletions(-)
>>
>> diff --git a/target/s390x/diag.c b/target/s390x/diag.c
>> index dbbb9e886f..52bc348808 100644
>> --- a/target/s390x/diag.c
>> +++ b/target/s390x/diag.c
>> @@ -27,7 +27,6 @@ static int modified_clear_reset(S390CPU *cpu)
>>  S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
>>  CPUState *t;
>>
>> -pause_all_vcpus();
>>  cpu_synchronize_all_states();
>>  CPU_FOREACH(t) {
>>  run_on_cpu(t, s390_do_cpu_full_reset, RUN_ON_CPU_NULL);
> 
> I think you also need to fix the run_on_cpu to be a async_run_on_cpu as
> you would otherwise hang waiting for run_on_cpu to finish on a
> single-threaded TCG run (as you are in the only vCPU context).

No, it works just fine for single threaded TCG. run_on_cpu() can deal
with single threaded TCG just fine. (otherwise e.g. SIGP code also
wouldn't work)

In do_run_on_cpu, the following code always directly triggers for single
threaded tcg:

if (qemu_cpu_is_self(cpu)) {

func(cpu, data);

return;

}

> 
> If it is important that the source vCPU doesn't continue you can
> schedule it's work afterwards with a async_safe_run_on_cpu which will
> complete after all other vCPUs have executed their work.
> 

It is important. Introducing async helpers at a point where sync is
needed sounds strange.

Thanks!

>>
>> --
>> 2.13.6
> 
> 
> --
> Alex Bennée
> 


-- 

Thanks,

David / dhildenb

[Qemu-devel] [PATCH v2 1/7] s390x/pci: factor out endianess conversion

[Pierre Morel]

There are two places where the same endianness conversion
is done.
Let's factor this out into a static function.

Signed-off-by: Pierre Morel 
Reviewed-by: Yi Min Zhao 
Signed-off-by: Pierre Morel 
---
 hw/s390x/s390-pci-inst.c | 59 +++-
 1 file changed, 33 insertions(+), 26 deletions(-)

diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
index 8e088f3..ded1556 100644
--- a/hw/s390x/s390-pci-inst.c
+++ b/hw/s390x/s390-pci-inst.c
@@ -314,6 +314,36 @@ out:
 return 0;
 }
 
+/**
+ * This function is called when endianess is fixed, whatever the host endianess
+ * is, like in our case from s390x BIG endian registers to little endian PCI
+ * Bars, to translate the uint64_t pointed from one endianess to the other.
+ *
+ * @ptr: a pointer to a uint64_t data field
+ * @len: the length of the valid data, must be 1,2,4 or 8
+ */
+static int zpci_endian_swap(uint64_t *ptr, uint8_t len)
+{
+uint64_t data = *ptr;
+switch (len) {
+case 1:
+break;
+case 2:
+data = bswap16(data);
+break;
+case 4:
+data = bswap32(data);
+break;
+case 8:
+data = bswap64(data);
+break;
+default:
+return -EINVAL;
+}
+*ptr = data;
+return 0;
+}
+
 int pcilg_service_call(S390CPU *cpu, uint8_t r1, uint8_t r2)
 {
 CPUS390XState *env = >env;
@@ -385,19 +415,7 @@ int pcilg_service_call(S390CPU *cpu, uint8_t r1, uint8_t 
r2)
 data =  pci_host_config_read_common(
pbdev->pdev, offset, pci_config_size(pbdev->pdev), len);
 
-switch (len) {
-case 1:
-break;
-case 2:
-data = bswap16(data);
-break;
-case 4:
-data = bswap32(data);
-break;
-case 8:
-data = bswap64(data);
-break;
-default:
+if (zpci_endian_swap(, len)) {
 program_interrupt(env, PGM_OPERAND, 4);
 return 0;
 }
@@ -500,19 +518,8 @@ int pcistg_service_call(S390CPU *cpu, uint8_t r1, uint8_t 
r2)
 program_interrupt(env, PGM_OPERAND, 4);
 return 0;
 }
-switch (len) {
-case 1:
-break;
-case 2:
-data = bswap16(data);
-break;
-case 4:
-data = bswap32(data);
-break;
-case 8:
-data = bswap64(data);
-break;
-default:
+
+if (zpci_endian_swap(, len)) {
 program_interrupt(env, PGM_OPERAND, 4);
 return 0;
 }
-- 
2.7.4

[Qemu-devel] [PATCH v2 7/7] s390x/pci: search for subregion inside the BARs

[Pierre Morel]

When dispatching memory access to PCI BAR region, we must
look for possible subregions, used by the PCI device to map
different memory areas inside the same PCI BAR.

Since the data offset we received is calculated starting at the
region start address we need to adjust the offset for the subregion.

The data offset inside the subregion is calculated by substracting
the subregion's starting address from the data offset in the region.

The access to the MSIX region is now handled in a generic way,
we do not need the specific trap_msix() function anymore.

Signed-off-by: Pierre Morel 
Reviewed-by: Yi Min Zhao 
---
 hw/s390x/s390-pci-inst.c | 44 +---
 1 file changed, 25 insertions(+), 19 deletions(-)

diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
index eef3b89..33d08c6 100644
--- a/hw/s390x/s390-pci-inst.c
+++ b/hw/s390x/s390-pci-inst.c
@@ -345,12 +345,31 @@ static int zpci_endian_swap(uint64_t *ptr, uint8_t len)
 return 0;
 }
 
+static MemoryRegion *s390_get_subregion(MemoryRegion *mr, uint64_t offset,
+uint8_t len)
+{
+MemoryRegion *other;
+uint64_t subregion_size;
+
+QTAILQ_FOREACH(other, >subregions, subregions_link) {
+subregion_size = int128_get64(other->size);
+if ((offset >= other->addr) &&
+(offset + len) <= (other->addr + subregion_size)) {
+mr = other;
+break;
+}
+}
+return mr;
+}
+
 static MemTxResult zpci_read_bar(S390PCIBusDevice *pbdev, uint8_t pcias,
  uint64_t offset, uint64_t *data, uint8_t len)
 {
 MemoryRegion *mr;
 
 mr = pbdev->pdev->io_regions[pcias].memory;
+mr = s390_get_subregion(mr, offset, len);
+offset -= mr->addr;
 return memory_region_dispatch_read(mr, offset, data, len,
MEMTXATTRS_UNSPECIFIED);
 }
@@ -442,30 +461,14 @@ int pcilg_service_call(S390CPU *cpu, uint8_t r1, uint8_t 
r2)
 return 0;
 }
 
-static int trap_msix(S390PCIBusDevice *pbdev, uint64_t offset, uint8_t pcias)
-{
-if (pbdev->msix.available && pbdev->msix.table_bar == pcias &&
-offset >= pbdev->msix.table_offset &&
-offset < (pbdev->msix.table_offset +
-  pbdev->msix.entries * PCI_MSIX_ENTRY_SIZE)) {
-return 1;
-} else {
-return 0;
-}
-}
-
 static MemTxResult zpci_write_bar(S390PCIBusDevice *pbdev, uint8_t pcias,
   uint64_t offset, uint64_t data, uint8_t len)
 {
 MemoryRegion *mr;
 
-if (trap_msix(pbdev, offset, pcias)) {
-offset = offset - pbdev->msix.table_offset;
-mr = >pdev->msix_table_mmio;
-} else {
-mr = pbdev->pdev->io_regions[pcias].memory;
-}
-
+mr = pbdev->pdev->io_regions[pcias].memory;
+mr = s390_get_subregion(mr, offset, len);
+offset -= mr->addr;
 return memory_region_dispatch_write(mr, offset, data, len,
 MEMTXATTRS_UNSPECIFIED);
 }
@@ -725,6 +728,9 @@ int pcistb_service_call(S390CPU *cpu, uint8_t r1, uint8_t 
r3, uint64_t gaddr,
 }
 
 mr = pbdev->pdev->io_regions[pcias].memory;
+mr = s390_get_subregion(mr, offset, len);
+offset -= mr->addr;
+
 if (!memory_region_access_valid(mr, offset, len, true)) {
 program_interrupt(env, PGM_OPERAND, 6);
 return 0;
-- 
2.7.4

[Qemu-devel] [PATCH v2 2/7] s390x/pci: rework PCI STORE

[Pierre Morel]

Enhance the fault detection, correction of the fault reporting.

Signed-off-by: Pierre Morel 
Reviewed-by: Yi Min Zhao 
Signed-off-by: Pierre Morel 
---
 hw/s390x/s390-pci-inst.c | 39 ++-
 1 file changed, 22 insertions(+), 17 deletions(-)

diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
index ded1556..df0c8f0 100644
--- a/hw/s390x/s390-pci-inst.c
+++ b/hw/s390x/s390-pci-inst.c
@@ -470,6 +470,12 @@ int pcistg_service_call(S390CPU *cpu, uint8_t r1, uint8_t 
r2)
 pcias = (env->regs[r2] >> 16) & 0xf;
 len = env->regs[r2] & 0xf;
 offset = env->regs[r2 + 1];
+data = env->regs[r1];
+
+if (!(fh & FH_MASK_ENABLE)) {
+setcc(cpu, ZPCI_PCI_LS_INVAL_HANDLE);
+return 0;
+}
 
 pbdev = s390_pci_find_dev_by_fh(s390_get_phb(), fh);
 if (!pbdev) {
@@ -479,12 +485,7 @@ int pcistg_service_call(S390CPU *cpu, uint8_t r1, uint8_t 
r2)
 }
 
 switch (pbdev->state) {
-case ZPCI_FS_RESERVED:
-case ZPCI_FS_STANDBY:
-case ZPCI_FS_DISABLED:
 case ZPCI_FS_PERMANENT_ERROR:
-setcc(cpu, ZPCI_PCI_LS_INVAL_HANDLE);
-return 0;
 case ZPCI_FS_ERROR:
 setcc(cpu, ZPCI_PCI_LS_ERR);
 s390_set_status_code(env, r2, ZPCI_PCI_ST_BLOCKED);
@@ -493,9 +494,13 @@ int pcistg_service_call(S390CPU *cpu, uint8_t r1, uint8_t 
r2)
 break;
 }
 
-data = env->regs[r1];
-if (pcias < 6) {
-if ((8 - (offset & 0x7)) < len) {
+/* Test that the pcias is valid and do the appropriates operations */
+switch (pcias) {
+case 0 ... 5:
+/* Check length:
+ * A length of 0 is invalid and length should not cross a double word
+ */
+if (!len || (len > (8 - (offset & 0x7 {
 program_interrupt(env, PGM_OPERAND, 4);
 return 0;
 }
@@ -513,21 +518,21 @@ int pcistg_service_call(S390CPU *cpu, uint8_t r1, uint8_t 
r2)
 program_interrupt(env, PGM_OPERAND, 4);
 return 0;
 }
-} else if (pcias == 15) {
-if ((4 - (offset & 0x3)) < len) {
-program_interrupt(env, PGM_OPERAND, 4);
-return 0;
-}
-
-if (zpci_endian_swap(, len)) {
+break;
+case 15:
+/* ZPCI uses the pseudo BAR number 15 as configuration space */
+/* possible access lengths are 1,2,4 and must not cross a word */
+if (!len || (len > (4 - (offset & 0x3))) || len == 3) {
 program_interrupt(env, PGM_OPERAND, 4);
 return 0;
 }
-
+/* len = 1,2,4 so we do not need to test */
+zpci_endian_swap(, len);
 pci_host_config_write_common(pbdev->pdev, offset,
  pci_config_size(pbdev->pdev),
  data, len);
-} else {
+break;
+default:
 DPRINTF("pcistg invalid space\n");
 setcc(cpu, ZPCI_PCI_LS_ERR);
 s390_set_status_code(env, r2, ZPCI_PCI_ST_INVAL_AS);
-- 
2.7.4

[Qemu-devel] [PATCH v2 0/7] s390x/pci: Improve zPCI to cover more cases

[Pierre Morel]

This patch fixes the following BUG:
Even a guest is able to detect virtio_pci device, the init function
the Linux virtio_pci driver will hang because zPCI does not support
the subregions used by virtio_pci.

It follows that right now the PCI support is very limited
(e.g. pass through of a host vfio device)
To enable features like virtio-pci several modifications needs to be
done.

As already stated above, Virtio-PCI uses subregions, which may eventually
be discontinuous inside bars instead of a single flat region often used
by real devices.
The address offset being formerly calculated from the BAR base address
must be adapted to the subregions instead of to the single region.

This patch provides the new calculation for the three kind of BAR
access, zPCI STORE, zPCI LOAD and zPCI STORE BLOCK done by zPCI.

We use the opportunity to
 - enhance the fault detection for zPCI STORE and LOAD,
 - enhance the fault detection and to provide the maximum STORE BLOCK
   block size, maxstbl, for zPCI STORE BLOCK
 - factor out part of the code used to calculate the offset and
   access the BARs,
 - factor out the code for endianess conversion.


Pierre Morel (7):
  s390x/pci: factor out endianess conversion
  s390x/pci: rework PCI STORE
  s390x/pci: rework PCI LOAD
  s390x/pci: rework PCI STORE BLOCK
  s390x/pci: move the memory region read from pcilg
  s390x/pci: move the memory region write from pcistg
  s390x/pci: search for subregion inside the BARs

 hw/s390x/s390-pci-bus.h  |   1 +
 hw/s390x/s390-pci-inst.c | 247 ---
 hw/s390x/s390-pci-inst.h |   2 +-
 3 files changed, 150 insertions(+), 100 deletions(-)

-- 
2.7.4

Changelog:

- suppress fallthrough to PCI_ROM_SLOT to handle it in the default case.
- reword most of the patch commit messages
- add comments to the endianness conversion
- reword somme comments inside the patches

Re: [Qemu-devel] [PATCH v2 1/2] Fix eepro100 simple transmission mode

[Thomas Huth]

On 16.11.2017 17:59, Thomas Huth wrote:
> On 06.11.2017 21:35, Mike Nawrocki wrote:
>> The simple transmission mode was treating the area immediately after the
>> transmit command block (TCB) as if it were a transmit buffer descriptor,
>> when in reality it is simply the packet data. This change simply copies
>> the data following the TCB into the packet buffer.
>>
>> Signed-off-by: Mike Nawrocki 
>> ---
>>  hw/net/eepro100.c | 18 +++---
>>  1 file changed, 3 insertions(+), 15 deletions(-)
>>
>> diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c
>> index 80b8f47c4b..91dd058010 100644
>> --- a/hw/net/eepro100.c
>> +++ b/hw/net/eepro100.c
>> @@ -774,23 +774,11 @@ static void tx_command(EEPRO100State *s)
>>  }
>>  assert(tcb_bytes <= sizeof(buf));
>>  while (size < tcb_bytes) {
>> -uint32_t tx_buffer_address = ldl_le_pci_dma(>dev, tbd_address);
>> -uint16_t tx_buffer_size = lduw_le_pci_dma(>dev, tbd_address + 4);
>> -#if 0
>> -uint16_t tx_buffer_el = lduw_le_pci_dma(>dev, tbd_address + 6);
>> -#endif
>> -if (tx_buffer_size == 0) {
>> -/* Prevent an endless loop. */
>> -logout("loop in %s:%u\n", __FILE__, __LINE__);
>> -break;
>> -}
>> -tbd_address += 8;
>>  TRACE(RXTX, logout
>>  ("TBD (simplified mode): buffer address 0x%08x, size 0x%04x\n",
>> - tx_buffer_address, tx_buffer_size));
>> -tx_buffer_size = MIN(tx_buffer_size, sizeof(buf) - size);
>> -pci_dma_read(>dev, tx_buffer_address, [size], 
>> tx_buffer_size);
>> -size += tx_buffer_size;
>> + tbd_address, tcb_bytes));
>> +pci_dma_read(>dev, tbd_address, [size], tcb_bytes);
>> +size += tcb_bytes;
>>  }
>>  if (tbd_array == 0x) {
>>  /* Simplified mode. Was already handled by code above. */
>>
> 
>  Hi,
> 
> I've got no clue why, but apparently this patch introduced a regression
> in rc1: The tests/pxe-test is now failing on a big endian (s390x) host
> when testing the i82550 device.
> It's working fine with commit 8fa5ad6dfb66b6c695aa6a6b54b7031c (and
> 2.11-rc0), and it's broken starting with commit
> 1865e288a823c764cd4344d704e33344 ... do you have any clue what might be
> wrong here now?

This patch seems to fix the issue for me:

diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c
index a63ed2c..03e00f7 100644
--- a/hw/net/eepro100.c
+++ b/hw/net/eepro100.c
@@ -756,8 +756,8 @@ static void read_cb(EEPRO100State *s)
 
 static void tx_command(EEPRO100State *s)
 {
-uint32_t tbd_array = le32_to_cpu(s->tx.tbd_array_addr);
-uint16_t tcb_bytes = (le16_to_cpu(s->tx.tcb_bytes) & 0x3fff);
+uint32_t tbd_array = s->tx.tbd_array_addr;
+uint16_t tcb_bytes = s->tx.tcb_bytes & 0x3fff;
 /* Sends larger than MAX_ETH_FRAME_SIZE are allowed, up to 2600 bytes. */
 uint8_t buf[2600];
 uint16_t size = 0;

Does that make sense? I think the fields are already swapped in
read_cb(), so no need to swap them in tx_command() again?

 Thomas

Re: [Qemu-devel] [PATCH v1 for-2.11 2/3] s390x/tcg: fix DIAG 308 with > 1 VCPU (single threaded TCG)

[David Hildenbrand]

On 16.11.2017 18:05, David Hildenbrand wrote:
> Currently, single threaded TCG with > 1 VCPU gets stuck during IPL, when
> the bios tries to switch to the loaded kernel via DIAG 308.
> 
> pause_all_vcpus()/resume_all_vcpus() should not be called from a VCPU.
> 
> And there is also no need for it. run_on_cpu() will make sure that the
> CPUs exit KVM/TCG, where they get stopped. Once stopped, they will no
> longer run.
> 
> Signed-off-by: David Hildenbrand 
> ---
>  target/s390x/diag.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/target/s390x/diag.c b/target/s390x/diag.c
> index dbbb9e886f..52bc348808 100644
> --- a/target/s390x/diag.c
> +++ b/target/s390x/diag.c
> @@ -27,7 +27,6 @@ static int modified_clear_reset(S390CPU *cpu)
>  S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
>  CPUState *t;
>  
> -pause_all_vcpus();
>  cpu_synchronize_all_states();

Hmm, thinking about this whole synchronization thingy, I guess it could
happen that a VCPU starts running again after the
cpu_synchronize_all_states() but before the reset. So we should do that
in one shot. Resulting in something like the following. Comments?



>From 14440f775e65bb88c1a95705fc9b438f4022f332 Mon Sep 17 00:00:00 2001
From: David Hildenbrand 
Date: Wed, 15 Nov 2017 17:30:02 +0100
Subject: [PATCH v1] s390x/tcg: fix DIAG 308 with > 1 VCPU (single threaded
 TCG)

Currently, single threaded TCG with > 1 VCPU gets stuck during IPL, when
the bios tries to switch to the loaded kernel via DIAG 308.

pause_all_vcpus()/resume_all_vcpus() should not be called from a VCPU.

And there is also no need for it. run_on_cpu() will make sure that the
CPUs exits KVM/TCG, where they get stopped. Once stopped, they will no
longer run. As we have to proper synchronize before and after the reset,
and have to hinder the VCPU from going back into TCG/KVM execution
after the sync, let's do the synchronization in the same shot.

Optimize so we don't do one additional round of synchronization on the
running CPU.

Signed-off-by: David Hildenbrand 
---
 target/s390x/diag.c | 42 --
 1 file changed, 28 insertions(+), 14 deletions(-)

diff --git a/target/s390x/diag.c b/target/s390x/diag.c
index dbbb9e886f..8396124a5f 100644
--- a/target/s390x/diag.c
+++ b/target/s390x/diag.c
@@ -19,51 +19,65 @@
 #include "exec/exec-all.h"
 #include "hw/watchdog/wdt_diag288.h"
 #include "sysemu/cpus.h"
+#include "sysemu/hw_accel.h"
 #include "hw/s390x/ipl.h"
 #include "hw/s390x/s390-virtio-ccw.h"

+static void s390_do_sync_cpu_full_reset(CPUState *cs, run_on_cpu_data arg)
+{
+cpu_synchronize_state(cs);
+cpu_reset(cs);
+cpu_synchronize_post_reset(cs);
+}
+
 static int modified_clear_reset(S390CPU *cpu)
 {
 S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
+CPUState *cs = CPU(cpu);
 CPUState *t;

-pause_all_vcpus();
-cpu_synchronize_all_states();
 CPU_FOREACH(t) {
-run_on_cpu(t, s390_do_cpu_full_reset, RUN_ON_CPU_NULL);
+if (t != cs) {
+run_on_cpu(t, s390_do_sync_cpu_full_reset, RUN_ON_CPU_NULL);
+}
 }
 s390_cmma_reset();
 subsystem_reset();
 s390_crypto_reset();
-scc->load_normal(CPU(cpu));
-cpu_synchronize_all_post_reset();
-resume_all_vcpus();
+cpu_synchronize_state(cs);
+cpu_reset(cs);
+scc->load_normal(cs);
+cpu_synchronize_post_reset(cs);
 return 0;
 }

-static inline void s390_do_cpu_reset(CPUState *cs, run_on_cpu_data arg)
+static void s390_do_sync_cpu_reset(CPUState *cs, run_on_cpu_data arg)
 {
 S390CPUClass *scc = S390_CPU_GET_CLASS(cs);

+cpu_synchronize_state(cs);
 scc->cpu_reset(cs);
+cpu_synchronize_post_reset(cs);
 }

 static int load_normal_reset(S390CPU *cpu)
 {
 S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
+CPUState *cs = CPU(cpu);
 CPUState *t;

-pause_all_vcpus();
-cpu_synchronize_all_states();
 CPU_FOREACH(t) {
-run_on_cpu(t, s390_do_cpu_reset, RUN_ON_CPU_NULL);
+if (t != cs) {
+run_on_cpu(t, s390_do_sync_cpu_reset, RUN_ON_CPU_NULL);
+}
 }
 s390_cmma_reset();
 subsystem_reset();
-scc->initial_cpu_reset(CPU(cpu));
-scc->load_normal(CPU(cpu));
-cpu_synchronize_all_post_reset();
-resume_all_vcpus();
+cpu_synchronize_state(cs);
+/* scc->initital_cpu_reset() is a superset of scc->cpu_reset() */
+scc->initial_cpu_reset(cs);
+scc->load_normal(cs);
+cpu_synchronize_post_reset(cs);
 return 0;
 }

-- 
2.13.6



-- 

Thanks,

David / dhildenb

[Qemu-devel] [PATCH 06/10] qemu-iotests: turn owner variable into a comment

[Cleber Rosa]

This variables has no real use.  To avoid pretending it does, while
still keeping the information, let's turn it into a comment.

The format chosen is the one already being used on tests 149 and 194.

Signed-off-by: Cleber Rosa 
---
 tests/qemu-iotests/001 | 5 ++---
 tests/qemu-iotests/002 | 5 ++---
 tests/qemu-iotests/003 | 5 ++---
 tests/qemu-iotests/004 | 5 ++---
 tests/qemu-iotests/005 | 5 ++---
 tests/qemu-iotests/007 | 5 ++---
 tests/qemu-iotests/008 | 5 ++---
 tests/qemu-iotests/009 | 5 ++---
 tests/qemu-iotests/010 | 5 ++---
 tests/qemu-iotests/011 | 5 ++---
 tests/qemu-iotests/012 | 5 ++---
 tests/qemu-iotests/013 | 5 ++---
 tests/qemu-iotests/014 | 5 ++---
 tests/qemu-iotests/015 | 5 ++---
 tests/qemu-iotests/017 | 5 ++---
 tests/qemu-iotests/018 | 5 ++---
 tests/qemu-iotests/019 | 5 ++---
 tests/qemu-iotests/020 | 5 ++---
 tests/qemu-iotests/021 | 5 ++---
 tests/qemu-iotests/022 | 5 ++---
 tests/qemu-iotests/023 | 5 ++---
 tests/qemu-iotests/024 | 5 ++---
 tests/qemu-iotests/025 | 5 ++---
 tests/qemu-iotests/026 | 5 ++---
 tests/qemu-iotests/027 | 5 ++---
 tests/qemu-iotests/028 | 5 ++---
 tests/qemu-iotests/029 | 5 ++---
 tests/qemu-iotests/031 | 5 ++---
 tests/qemu-iotests/032 | 5 ++---
 tests/qemu-iotests/033 | 5 ++---
 tests/qemu-iotests/034 | 5 ++---
 tests/qemu-iotests/035 | 5 ++---
 tests/qemu-iotests/036 | 5 ++---
 tests/qemu-iotests/037 | 5 ++---
 tests/qemu-iotests/038 | 5 ++---
 tests/qemu-iotests/039 | 5 ++---
 tests/qemu-iotests/040 | 1 +
 tests/qemu-iotests/042 | 5 ++---
 tests/qemu-iotests/043 | 5 ++---
 tests/qemu-iotests/046 | 5 ++---
 tests/qemu-iotests/047 | 5 ++---
 tests/qemu-iotests/048 | 4 ++--
 tests/qemu-iotests/049 | 5 ++---
 tests/qemu-iotests/050 | 5 ++---
 tests/qemu-iotests/051 | 5 ++---
 tests/qemu-iotests/052 | 5 ++---
 tests/qemu-iotests/053 | 5 ++---
 tests/qemu-iotests/054 | 5 ++---
 tests/qemu-iotests/058 | 5 ++---
 tests/qemu-iotests/059 | 5 ++---
 tests/qemu-iotests/060 | 5 ++---
 tests/qemu-iotests/061 | 5 ++---
 tests/qemu-iotests/062 | 5 ++---
 tests/qemu-iotests/063 | 5 ++---
 tests/qemu-iotests/064 | 5 ++---
 tests/qemu-iotests/066 | 5 ++---
 tests/qemu-iotests/067 | 5 ++---
 tests/qemu-iotests/068 | 5 ++---
 tests/qemu-iotests/069 | 5 ++---
 tests/qemu-iotests/070 | 5 ++---
 tests/qemu-iotests/071 | 5 ++---
 tests/qemu-iotests/072 | 5 ++---
 tests/qemu-iotests/073 | 5 ++---
 tests/qemu-iotests/074 | 3 +--
 tests/qemu-iotests/075 | 5 ++---
 tests/qemu-iotests/076 | 5 ++---
 tests/qemu-iotests/077 | 5 ++---
 tests/qemu-iotests/078 | 5 ++---
 tests/qemu-iotests/079 | 5 ++---
 tests/qemu-iotests/080 | 5 ++---
 tests/qemu-iotests/081 | 5 ++---
 tests/qemu-iotests/082 | 5 ++---
 tests/qemu-iotests/083 | 5 ++---
 tests/qemu-iotests/084 | 5 ++---
 tests/qemu-iotests/085 | 5 ++---
 tests/qemu-iotests/086 | 5 ++---
 tests/qemu-iotests/087 | 5 ++---
 tests/qemu-iotests/088 | 5 ++---
 tests/qemu-iotests/089 | 5 ++---
 tests/qemu-iotests/090 | 5 ++---
 tests/qemu-iotests/091 | 5 ++---
 tests/qemu-iotests/092 | 5 ++---
 tests/qemu-iotests/094 | 5 ++---
 tests/qemu-iotests/095 | 4 ++--
 tests/qemu-iotests/097 | 5 ++---
 tests/qemu-iotests/098 | 5 ++---
 tests/qemu-iotests/099 | 5 ++---
 tests/qemu-iotests/101 | 5 ++---
 tests/qemu-iotests/102 | 5 ++---
 tests/qemu-iotests/103 | 5 ++---
 tests/qemu-iotests/104 | 5 ++---
 tests/qemu-iotests/105 | 5 ++---
 tests/qemu-iotests/106 | 5 ++---
 tests/qemu-iotests/107 | 5 ++---
 tests/qemu-iotests/108 | 5 ++---
 tests/qemu-iotests/109 | 5 ++---
 tests/qemu-iotests/110 | 5 ++---
 tests/qemu-iotests/111 | 5 ++---
 tests/qemu-iotests/112 | 5 ++---
 tests/qemu-iotests/113 | 5 ++---
 tests/qemu-iotests/114 | 5 ++---
 tests/qemu-iotests/115 | 5 ++---
 tests/qemu-iotests/116 | 5 ++---
 tests/qemu-iotests/117 | 5 ++---
 tests/qemu-iotests/119 | 5 ++---
 tests/qemu-iotests/120 | 5 ++---
 tests/qemu-iotests/121 | 5 ++---
 tests/qemu-iotests/122 | 5 ++---
 tests/qemu-iotests/123 | 5 ++---
 tests/qemu-iotests/125 | 5 ++---
 tests/qemu-iotests/126 | 5 ++---
 tests/qemu-iotests/127 | 5 ++---
 tests/qemu-iotests/128 | 5 ++---
 tests/qemu-iotests/130 | 5 ++---
 tests/qemu-iotests/131 | 5 ++---
 tests/qemu-iotests/133 | 5 ++---
 tests/qemu-iotests/134 | 5 ++---
 tests/qemu-iotests/135 | 5 ++---
 tests/qemu-iotests/137 | 5 ++---
 tests/qemu-iotests/138 | 5 ++---
 tests/qemu-iotests/140 | 5 ++---
 tests/qemu-iotests/141 | 5 ++---
 tests/qemu-iotests/142 | 5 ++---
 tests/qemu-iotests/143 | 5 ++---
 tests/qemu-iotests/144 | 5 ++---
 tests/qemu-iotests/145 | 5 ++---
 tests/qemu-iotests/146 | 5 ++---
 tests/qemu-iotests/150 | 5 ++---
 tests/qemu-iotests/153 | 5 ++---
 tests/qemu-iotests/154 | 5 ++---
 tests/qemu-iotests/156 | 5 ++---
 tests/qemu-iotests/157 | 5 ++---
 tests/qemu-iotests/158 | 5 ++---
 tests/qemu-iotests/159 | 4 ++--
 tests/qemu-iotests/160 | 4 ++--
 tests/qemu-iotests/162 | 5 ++---
 tests/qemu-iotests/170 | 4 ++--
 tests/qemu-iotests/171 | 5 ++---
 tests/qemu-iotests/172 | 5 ++---
 tests/qemu-iotests/173 | 4 ++--

[Qemu-devel] [PATCH 05/10] qemu-iotests: define functions used in _cleanup() before its use

[Cleber Rosa]

The functions used in _cleanup() come from common.rc, which currently
gets sourced after _cleanup() is defined and registered as a signal
handler.  When _cleanup() is executed, it has no valid references to
those functions, as BASH won't resolve the reference at that time.

While at it, also fix some tabs versus spaces indentation in
_cleanup() in a few tests.

Signed-off-by: Cleber Rosa 
---
 tests/qemu-iotests/001 |  6 +++---
 tests/qemu-iotests/002 |  6 +++---
 tests/qemu-iotests/003 |  6 +++---
 tests/qemu-iotests/004 |  6 +++---
 tests/qemu-iotests/005 |  6 +++---
 tests/qemu-iotests/007 |  6 +++---
 tests/qemu-iotests/008 |  6 +++---
 tests/qemu-iotests/009 |  6 +++---
 tests/qemu-iotests/010 |  6 +++---
 tests/qemu-iotests/011 |  6 +++---
 tests/qemu-iotests/012 |  6 +++---
 tests/qemu-iotests/013 |  8 
 tests/qemu-iotests/014 |  8 
 tests/qemu-iotests/015 |  6 +++---
 tests/qemu-iotests/017 |  8 
 tests/qemu-iotests/018 |  8 
 tests/qemu-iotests/019 |  8 
 tests/qemu-iotests/020 |  8 
 tests/qemu-iotests/021 |  6 +++---
 tests/qemu-iotests/022 |  8 
 tests/qemu-iotests/023 |  8 
 tests/qemu-iotests/024 |  8 
 tests/qemu-iotests/025 |  8 
 tests/qemu-iotests/026 |  8 
 tests/qemu-iotests/027 |  6 +++---
 tests/qemu-iotests/028 | 10 +-
 tests/qemu-iotests/029 |  8 
 tests/qemu-iotests/031 |  8 
 tests/qemu-iotests/032 |  8 
 tests/qemu-iotests/033 |  6 +++---
 tests/qemu-iotests/034 |  6 +++---
 tests/qemu-iotests/035 |  6 +++---
 tests/qemu-iotests/036 |  8 
 tests/qemu-iotests/037 |  6 +++---
 tests/qemu-iotests/038 |  6 +++---
 tests/qemu-iotests/039 |  6 +++---
 tests/qemu-iotests/042 |  6 +++---
 tests/qemu-iotests/043 |  6 +++---
 tests/qemu-iotests/046 |  6 +++---
 tests/qemu-iotests/047 |  6 +++---
 tests/qemu-iotests/048 |  8 
 tests/qemu-iotests/049 |  6 +++---
 tests/qemu-iotests/050 |  6 +++---
 tests/qemu-iotests/051 |  6 +++---
 tests/qemu-iotests/052 |  6 +++---
 tests/qemu-iotests/053 |  6 +++---
 tests/qemu-iotests/054 |  6 +++---
 tests/qemu-iotests/058 |  8 
 tests/qemu-iotests/059 |  6 +++---
 tests/qemu-iotests/060 |  6 +++---
 tests/qemu-iotests/061 |  6 +++---
 tests/qemu-iotests/062 |  6 +++---
 tests/qemu-iotests/063 |  8 
 tests/qemu-iotests/064 |  6 +++---
 tests/qemu-iotests/066 |  6 +++---
 tests/qemu-iotests/068 |  6 +++---
 tests/qemu-iotests/069 |  6 +++---
 tests/qemu-iotests/070 |  6 +++---
 tests/qemu-iotests/071 |  6 +++---
 tests/qemu-iotests/072 |  6 +++---
 tests/qemu-iotests/073 |  6 +++---
 tests/qemu-iotests/074 |  8 
 tests/qemu-iotests/075 |  6 +++---
 tests/qemu-iotests/076 |  6 +++---
 tests/qemu-iotests/077 |  6 +++---
 tests/qemu-iotests/078 |  6 +++---
 tests/qemu-iotests/079 |  6 +++---
 tests/qemu-iotests/080 |  6 +++---
 tests/qemu-iotests/082 |  6 +++---
 tests/qemu-iotests/084 |  6 +++---
 tests/qemu-iotests/085 |  8 
 tests/qemu-iotests/086 |  6 +++---
 tests/qemu-iotests/088 |  6 +++---
 tests/qemu-iotests/089 |  6 +++---
 tests/qemu-iotests/090 |  6 +++---
 tests/qemu-iotests/091 |  8 
 tests/qemu-iotests/092 |  6 +++---
 tests/qemu-iotests/094 |  9 -
 tests/qemu-iotests/095 |  8 
 tests/qemu-iotests/097 |  8 
 tests/qemu-iotests/098 |  8 
 tests/qemu-iotests/099 |  6 +++---
 tests/qemu-iotests/101 |  6 +++---
 tests/qemu-iotests/102 |  8 
 tests/qemu-iotests/103 |  6 +++---
 tests/qemu-iotests/105 |  6 +++---
 tests/qemu-iotests/106 |  6 +++---
 tests/qemu-iotests/107 |  6 +++---
 tests/qemu-iotests/108 |  6 +++---
 tests/qemu-iotests/109 |  8 
 tests/qemu-iotests/110 |  6 +++---
 tests/qemu-iotests/111 |  6 +++---
 tests/qemu-iotests/112 |  6 +++---
 tests/qemu-iotests/113 |  6 +++---
 tests/qemu-iotests/114 |  6 +++---
 tests/qemu-iotests/115 |  6 +++---
 tests/qemu-iotests/116 |  6 +++---
 tests/qemu-iotests/117 | 10 +-
 tests/qemu-iotests/119 |  6 +++---
 tests/qemu-iotests/120 |  6 +++---
 tests/qemu-iotests/121 |  6 +++---
 tests/qemu-iotests/122 |  6 +++---
 tests/qemu-iotests/123 |  6 +++---
 tests/qemu-iotests/125 |  6 +++---
 tests/qemu-iotests/127 |  8 
 tests/qemu-iotests/130 |  8 
 tests/qemu-iotests/131 |  6 +++---
 tests/qemu-iotests/133 |  6 +++---
 tests/qemu-iotests/134 |  8 
 tests/qemu-iotests/135 |  6 +++---
 tests/qemu-iotests/137 |  8 
 tests/qemu-iotests/138 |  6 +++---
 tests/qemu-iotests/140 |  8 
 tests/qemu-iotests/141 |  8 
 tests/qemu-iotests/142 |  6 +++---
 tests/qemu-iotests/143 |  8 
 tests/qemu-iotests/144 |  8 
 tests/qemu-iotests/145 |  6 +++---
 tests/qemu-iotests/146 |  8 
 tests/qemu-iotests/150 |  6 +++---
 tests/qemu-iotests/153 |  8 
 tests/qemu-iotests/154 |  6 +++---
 tests/qemu-iotests/156 |  8 
 tests/qemu-iotests/157 |  6 +++---
 tests/qemu-iotests/158 |  6 +++---

[Qemu-devel] [PATCH 09/10] qemu-iotests: remove unused "here" variable

[Cleber Rosa]

Another legacy variable that did not convince me it has any
purpose whatsoever.

Signed-off-by: Cleber Rosa 
---
 tests/qemu-iotests/001 | 1 -
 tests/qemu-iotests/002 | 1 -
 tests/qemu-iotests/003 | 1 -
 tests/qemu-iotests/004 | 1 -
 tests/qemu-iotests/005 | 1 -
 tests/qemu-iotests/007 | 1 -
 tests/qemu-iotests/008 | 1 -
 tests/qemu-iotests/009 | 1 -
 tests/qemu-iotests/010 | 1 -
 tests/qemu-iotests/011 | 1 -
 tests/qemu-iotests/012 | 1 -
 tests/qemu-iotests/013 | 1 -
 tests/qemu-iotests/014 | 1 -
 tests/qemu-iotests/015 | 1 -
 tests/qemu-iotests/017 | 1 -
 tests/qemu-iotests/018 | 1 -
 tests/qemu-iotests/019 | 1 -
 tests/qemu-iotests/020 | 1 -
 tests/qemu-iotests/021 | 1 -
 tests/qemu-iotests/022 | 1 -
 tests/qemu-iotests/023 | 1 -
 tests/qemu-iotests/024 | 1 -
 tests/qemu-iotests/025 | 1 -
 tests/qemu-iotests/026 | 1 -
 tests/qemu-iotests/027 | 1 -
 tests/qemu-iotests/028 | 1 -
 tests/qemu-iotests/029 | 1 -
 tests/qemu-iotests/031 | 1 -
 tests/qemu-iotests/032 | 1 -
 tests/qemu-iotests/033 | 1 -
 tests/qemu-iotests/034 | 1 -
 tests/qemu-iotests/035 | 1 -
 tests/qemu-iotests/036 | 1 -
 tests/qemu-iotests/037 | 1 -
 tests/qemu-iotests/038 | 1 -
 tests/qemu-iotests/039 | 1 -
 tests/qemu-iotests/042 | 1 -
 tests/qemu-iotests/043 | 1 -
 tests/qemu-iotests/046 | 1 -
 tests/qemu-iotests/047 | 1 -
 tests/qemu-iotests/049 | 1 -
 tests/qemu-iotests/050 | 1 -
 tests/qemu-iotests/051 | 1 -
 tests/qemu-iotests/052 | 1 -
 tests/qemu-iotests/053 | 1 -
 tests/qemu-iotests/054 | 1 -
 tests/qemu-iotests/058 | 1 -
 tests/qemu-iotests/059 | 1 -
 tests/qemu-iotests/060 | 1 -
 tests/qemu-iotests/061 | 1 -
 tests/qemu-iotests/062 | 1 -
 tests/qemu-iotests/063 | 1 -
 tests/qemu-iotests/064 | 1 -
 tests/qemu-iotests/066 | 1 -
 tests/qemu-iotests/067 | 1 -
 tests/qemu-iotests/068 | 1 -
 tests/qemu-iotests/069 | 1 -
 tests/qemu-iotests/070 | 1 -
 tests/qemu-iotests/071 | 1 -
 tests/qemu-iotests/072 | 1 -
 tests/qemu-iotests/073 | 1 -
 tests/qemu-iotests/075 | 1 -
 tests/qemu-iotests/076 | 1 -
 tests/qemu-iotests/077 | 1 -
 tests/qemu-iotests/078 | 1 -
 tests/qemu-iotests/079 | 1 -
 tests/qemu-iotests/080 | 1 -
 tests/qemu-iotests/081 | 1 -
 tests/qemu-iotests/082 | 1 -
 tests/qemu-iotests/083 | 1 -
 tests/qemu-iotests/084 | 1 -
 tests/qemu-iotests/085 | 1 -
 tests/qemu-iotests/086 | 1 -
 tests/qemu-iotests/087 | 1 -
 tests/qemu-iotests/088 | 1 -
 tests/qemu-iotests/089 | 1 -
 tests/qemu-iotests/090 | 1 -
 tests/qemu-iotests/091 | 1 -
 tests/qemu-iotests/092 | 1 -
 tests/qemu-iotests/094 | 1 -
 tests/qemu-iotests/095 | 1 -
 tests/qemu-iotests/097 | 1 -
 tests/qemu-iotests/098 | 1 -
 tests/qemu-iotests/099 | 1 -
 tests/qemu-iotests/101 | 1 -
 tests/qemu-iotests/102 | 1 -
 tests/qemu-iotests/103 | 1 -
 tests/qemu-iotests/104 | 1 -
 tests/qemu-iotests/105 | 1 -
 tests/qemu-iotests/106 | 1 -
 tests/qemu-iotests/107 | 1 -
 tests/qemu-iotests/108 | 1 -
 tests/qemu-iotests/109 | 1 -
 tests/qemu-iotests/110 | 1 -
 tests/qemu-iotests/111 | 1 -
 tests/qemu-iotests/112 | 1 -
 tests/qemu-iotests/113 | 1 -
 tests/qemu-iotests/114 | 1 -
 tests/qemu-iotests/115 | 1 -
 tests/qemu-iotests/116 | 1 -
 tests/qemu-iotests/117 | 1 -
 tests/qemu-iotests/119 | 1 -
 tests/qemu-iotests/120 | 1 -
 tests/qemu-iotests/121 | 1 -
 tests/qemu-iotests/122 | 1 -
 tests/qemu-iotests/123 | 1 -
 tests/qemu-iotests/125 | 1 -
 tests/qemu-iotests/126 | 1 -
 tests/qemu-iotests/127 | 1 -
 tests/qemu-iotests/128 | 1 -
 tests/qemu-iotests/130 | 1 -
 tests/qemu-iotests/131 | 1 -
 tests/qemu-iotests/133 | 1 -
 tests/qemu-iotests/134 | 1 -
 tests/qemu-iotests/135 | 1 -
 tests/qemu-iotests/137 | 1 -
 tests/qemu-iotests/138 | 1 -
 tests/qemu-iotests/140 | 1 -
 tests/qemu-iotests/141 | 1 -
 tests/qemu-iotests/142 | 1 -
 tests/qemu-iotests/143 | 1 -
 tests/qemu-iotests/144 | 1 -
 tests/qemu-iotests/145 | 1 -
 tests/qemu-iotests/146 | 1 -
 tests/qemu-iotests/150 | 1 -
 tests/qemu-iotests/153 | 1 -
 tests/qemu-iotests/154 | 1 -
 tests/qemu-iotests/156 | 1 -
 tests/qemu-iotests/157 | 1 -
 tests/qemu-iotests/158 | 1 -
 tests/qemu-iotests/159 | 1 -
 tests/qemu-iotests/160 | 1 -
 tests/qemu-iotests/162 | 1 -
 tests/qemu-iotests/170 | 1 -
 tests/qemu-iotests/171 | 1 -
 tests/qemu-iotests/172 | 1 -
 tests/qemu-iotests/173 | 1 -
 tests/qemu-iotests/174 | 1 -
 tests/qemu-iotests/175 | 1 -
 tests/qemu-iotests/176 | 1 -
 tests/qemu-iotests/177 | 1 -
 tests/qemu-iotests/178 | 1 -
 tests/qemu-iotests/179 | 1 -
 tests/qemu-iotests/181 | 1 -
 tests/qemu-iotests/182 | 1 -
 tests/qemu-iotests/183 | 1 -
 tests/qemu-iotests/184 | 1 -
 tests/qemu-iotests/185 | 1 -
 tests/qemu-iotests/186 | 1 -
 tests/qemu-iotests/187 | 1 -
 tests/qemu-iotests/188 | 1 -
 tests/qemu-iotests/189 | 1 -
 tests/qemu-iotests/190 | 1 -
 tests/qemu-iotests/191 | 1 -
 tests/qemu-iotests/192 | 1 -
 tests/qemu-iotests/195 | 1 -
 tests/qemu-iotests/197 | 1 -
 157 files changed, 157 deletions(-)

diff --git a/tests/qemu-iotests/001 b/tests/qemu-iotests/001
index 5830f68ba0..ce671e50e7 100755
--- 

[Qemu-devel] [PATCH 10/10] qemu-iotests: add section on how to write a new I/O test

[Cleber Rosa]

This adds some basic information on how to write a new test.  I'm
aware that some of the information in the wiki (Testing/QemuIoTests)
could also belong here.

Since copying content over won't generate much interesting feedback,
the goal here is to get feedback on the sample_test_templates, general
workflow proposed for writing a new test, etc.

After feedback is received, I can go over and sync both sides (wiki
and README).

Signed-off-by: Cleber Rosa 
---
 tests/qemu-iotests/README  | 44 ++--
 tests/qemu-iotests/sample_test_templates/sample.py | 59 ++
 tests/qemu-iotests/sample_test_templates/sample.sh | 40 +++
 3 files changed, 138 insertions(+), 5 deletions(-)
 create mode 100755 tests/qemu-iotests/sample_test_templates/sample.py
 create mode 100755 tests/qemu-iotests/sample_test_templates/sample.sh

diff --git a/tests/qemu-iotests/README b/tests/qemu-iotests/README
index 6079b401ae..efaf72d5e7 100644
--- a/tests/qemu-iotests/README
+++ b/tests/qemu-iotests/README
@@ -1,20 +1,54 @@
+= This is the QEMU I/O test suite =
 
-=== This is the QEMU I/O test suite ===
-
-* Intro
+== Intro ==
 
 This package contains a simple test suite for the I/O layer of qemu.
 It does not require a guest, but only the qemu, qemu-img and qemu-io
 binaries.  This does limit it to exercise the low-level I/O path only
 but no actual block drivers like ide, scsi or virtio.
 
-* Usage
+== Usage ==
 
 Just run ./check to run all tests for the raw image format, or ./check
 -qcow2 to test the qcow2 image format.  The output of ./check -h explains
 additional options to test further image formats or I/O methods.
 
-* Feedback and patches
+== Writing a QEMU I/O test ==
+
+It's a common practice to start with an existing test that may relate
+to the task you have.  QEMU I/O tests are usually written either in
+shell or Python, so it's also a good idea to pick an existing test
+based on your familiarity with those languages and/or what you
+anticipate about your test.
+
+You can find templates available at "sample_test_templates/", or you
+can start with an existing test, such as 001 (shell based) or 030
+(Python based).
+
+After you pick your template, name it as a three-digits file, starting
+with the next available one.  If `ls -1 ??? | sort -rn | head -1` gives
+you "197", name your test "198".  Finally, add an entry to the "group"
+file, which manages just that, test group classification, allowing a
+user to run all "quick" tests, for instance.
+
+=== Test configuration, expected results and reporting ===
+
+The tests are (mostly) standard executable files, that are executed by
+"./check" as such.  Tests get most of their configuration (directly or
+indirectly) by environment variables.  Some of the framework auxiliary
+code (for instance, "common.rc") defines or changes some of the
+environment variables.  You'll come across tests that reference
+"$TEST_IMG", "$QEMU_IO" and other variables.
+
+The expected results for a test are stored in a file named after the
+(sequential) test number.  For test 001, the expected output (stdout +
+stderr) is stored at 001.out.
+
+Tests that finish successfully should exit with status code 0.  To be
+considered a successful run, a test must also produce output that
+matches what is recorded in the expected output file (say, 001.out).
+
+== Feedback and patches ==
 
 Please send improvements to the test suite, general feedback or just
 reports of failing tests cases to qemu-devel@nongnu.org with a CC:
diff --git a/tests/qemu-iotests/sample_test_templates/sample.py 
b/tests/qemu-iotests/sample_test_templates/sample.py
new file mode 100755
index 00..35a7410b5c
--- /dev/null
+++ b/tests/qemu-iotests/sample_test_templates/sample.py
@@ -0,0 +1,59 @@
+#!/usr/bin/env python
+#
+# DESCRIPTION HERE, such as "Test a complex thing using a simple thing"
+#
+# COPYRIGHT NOTICE HERE, such as "Copyright (C)  Yourself, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+#
+# Creator/Owner: your.em...@example.com
+#
+
+import iotests
+
+
+class Sample(iotests.QMPTestCase):
+
+def setUp(self):
+"""
+Method that runs before test method(s).  Use it to prepare the
+environment that is common to the all tests, but doesn't
+necessarily mean that is part of the feature testing
+specifics.

[Qemu-devel] [PATCH 04/10] qemu-iotests: include (source) filters from common.rc

[Cleber Rosa]

There's an explicit dependency from common.rc on common.filters, that
is, it consumes functions defined there.  Just like common.config is
included in common.rc, it makes sense to also sense common.filter.

This drops the requirement on individual tests to include
common.filter, reducing the amount of boiler plate code (while still
making the comment found on almost every test "get standard
environment, filters and checks" accurate.

Signed-off-by: Cleber Rosa 
---
 tests/qemu-iotests/001   | 1 -
 tests/qemu-iotests/002   | 1 -
 tests/qemu-iotests/003   | 1 -
 tests/qemu-iotests/004   | 1 -
 tests/qemu-iotests/005   | 1 -
 tests/qemu-iotests/007   | 1 -
 tests/qemu-iotests/008   | 1 -
 tests/qemu-iotests/009   | 1 -
 tests/qemu-iotests/010   | 1 -
 tests/qemu-iotests/011   | 1 -
 tests/qemu-iotests/012   | 1 -
 tests/qemu-iotests/013   | 1 -
 tests/qemu-iotests/014   | 1 -
 tests/qemu-iotests/015   | 1 -
 tests/qemu-iotests/017   | 1 -
 tests/qemu-iotests/018   | 1 -
 tests/qemu-iotests/019   | 1 -
 tests/qemu-iotests/020   | 1 -
 tests/qemu-iotests/021   | 1 -
 tests/qemu-iotests/022   | 1 -
 tests/qemu-iotests/023   | 1 -
 tests/qemu-iotests/024   | 1 -
 tests/qemu-iotests/025   | 1 -
 tests/qemu-iotests/026   | 1 -
 tests/qemu-iotests/027   | 1 -
 tests/qemu-iotests/028   | 1 -
 tests/qemu-iotests/029   | 1 -
 tests/qemu-iotests/031   | 1 -
 tests/qemu-iotests/032   | 1 -
 tests/qemu-iotests/033   | 1 -
 tests/qemu-iotests/034   | 1 -
 tests/qemu-iotests/035   | 1 -
 tests/qemu-iotests/036   | 1 -
 tests/qemu-iotests/037   | 1 -
 tests/qemu-iotests/038   | 1 -
 tests/qemu-iotests/039   | 1 -
 tests/qemu-iotests/042   | 1 -
 tests/qemu-iotests/043   | 1 -
 tests/qemu-iotests/046   | 1 -
 tests/qemu-iotests/047   | 1 -
 tests/qemu-iotests/048   | 1 -
 tests/qemu-iotests/049   | 1 -
 tests/qemu-iotests/050   | 1 -
 tests/qemu-iotests/051   | 1 -
 tests/qemu-iotests/052   | 1 -
 tests/qemu-iotests/053   | 1 -
 tests/qemu-iotests/054   | 1 -
 tests/qemu-iotests/058   | 1 -
 tests/qemu-iotests/059   | 1 -
 tests/qemu-iotests/060   | 1 -
 tests/qemu-iotests/061   | 1 -
 tests/qemu-iotests/062   | 1 -
 tests/qemu-iotests/063   | 1 -
 tests/qemu-iotests/064   | 1 -
 tests/qemu-iotests/066   | 1 -
 tests/qemu-iotests/067   | 1 -
 tests/qemu-iotests/068   | 1 -
 tests/qemu-iotests/069   | 1 -
 tests/qemu-iotests/070   | 1 -
 tests/qemu-iotests/071   | 1 -
 tests/qemu-iotests/072   | 1 -
 tests/qemu-iotests/073   | 1 -
 tests/qemu-iotests/074   | 1 -
 tests/qemu-iotests/075   | 1 -
 tests/qemu-iotests/076   | 1 -
 tests/qemu-iotests/077   | 1 -
 tests/qemu-iotests/078   | 1 -
 tests/qemu-iotests/079   | 1 -
 tests/qemu-iotests/080   | 1 -
 tests/qemu-iotests/081   | 1 -
 tests/qemu-iotests/082   | 1 -
 tests/qemu-iotests/083   | 1 -
 tests/qemu-iotests/084   | 1 -
 tests/qemu-iotests/085   | 1 -
 tests/qemu-iotests/086   | 1 -
 tests/qemu-iotests/087   | 1 -
 tests/qemu-iotests/088   | 1 -
 tests/qemu-iotests/089   | 1 -
 tests/qemu-iotests/090   | 1 -
 tests/qemu-iotests/091   | 1 -
 tests/qemu-iotests/092   | 1 -
 tests/qemu-iotests/094   | 1 -
 tests/qemu-iotests/095   | 1 -
 tests/qemu-iotests/097   | 1 -
 tests/qemu-iotests/098   | 1 -
 tests/qemu-iotests/099   | 1 -
 tests/qemu-iotests/101   | 1 -
 tests/qemu-iotests/102   | 1 -
 tests/qemu-iotests/103   | 1 -
 tests/qemu-iotests/104   | 1 -
 tests/qemu-iotests/105   | 1 -
 tests/qemu-iotests/106   | 1 -
 tests/qemu-iotests/107   | 1 -
 tests/qemu-iotests/108   | 1 -
 tests/qemu-iotests/109   | 1 -
 tests/qemu-iotests/110   | 1 -
 tests/qemu-iotests/111   | 1 -
 tests/qemu-iotests/112   | 1 -
 tests/qemu-iotests/113   | 1 -
 tests/qemu-iotests/114   | 1 -
 tests/qemu-iotests/115   | 1 -
 tests/qemu-iotests/116   | 1 -
 tests/qemu-iotests/117   | 1 -
 tests/qemu-iotests/119   | 1 -
 tests/qemu-iotests/120   | 1 -
 tests/qemu-iotests/121   | 1 -
 tests/qemu-iotests/122   | 1 -
 tests/qemu-iotests/123   | 1 -
 tests/qemu-iotests/125   | 1 -
 tests/qemu-iotests/126   | 1 -
 tests/qemu-iotests/127   | 1 -
 tests/qemu-iotests/128   | 1 -
 tests/qemu-iotests/130   | 1 -
 tests/qemu-iotests/131   | 1 -
 tests/qemu-iotests/133   | 1 -
 tests/qemu-iotests/135   | 1 -
 tests/qemu-iotests/137   | 1 -
 tests/qemu-iotests/138   | 1 -
 tests/qemu-iotests/140   | 1 -
 tests/qemu-iotests/141   | 1 -
 tests/qemu-iotests/142   | 1 -
 tests/qemu-iotests/143   | 1 -
 tests/qemu-iotests/144   | 1 -
 tests/qemu-iotests/145   | 1 -
 tests/qemu-iotests/146   | 1 -
 

[Qemu-devel] [PATCH 07/10] qemu-iotests: remove the concept of $seq.full (and boiler plate code)

[Cleber Rosa]

The $seq.full file, in theory, should contain the full output of a
test error.  In practice, it's only used on a single test, and the
boiler plate code to clean it up plagues all other tests.

Let's remove the concept altogether, and record the failure in the
output itself for the one test using this function.

Signed-off-by: Cleber Rosa 
---
 tests/qemu-iotests/001 | 1 -
 tests/qemu-iotests/002 | 1 -
 tests/qemu-iotests/003 | 1 -
 tests/qemu-iotests/004 | 1 -
 tests/qemu-iotests/005 | 1 -
 tests/qemu-iotests/007 | 1 -
 tests/qemu-iotests/008 | 1 -
 tests/qemu-iotests/009 | 1 -
 tests/qemu-iotests/010 | 1 -
 tests/qemu-iotests/011 | 1 -
 tests/qemu-iotests/012 | 1 -
 tests/qemu-iotests/013 | 1 -
 tests/qemu-iotests/014 | 1 -
 tests/qemu-iotests/015 | 1 -
 tests/qemu-iotests/017 | 1 -
 tests/qemu-iotests/018 | 1 -
 tests/qemu-iotests/019 | 1 -
 tests/qemu-iotests/020 | 1 -
 tests/qemu-iotests/021 | 1 -
 tests/qemu-iotests/022 | 1 -
 tests/qemu-iotests/023 | 1 -
 tests/qemu-iotests/024 | 1 -
 tests/qemu-iotests/025 | 1 -
 tests/qemu-iotests/026 | 1 -
 tests/qemu-iotests/027 | 1 -
 tests/qemu-iotests/028 | 1 -
 tests/qemu-iotests/029 | 1 -
 tests/qemu-iotests/031 | 1 -
 tests/qemu-iotests/032 | 1 -
 tests/qemu-iotests/033 | 1 -
 tests/qemu-iotests/034 | 1 -
 tests/qemu-iotests/035 | 1 -
 tests/qemu-iotests/036 | 1 -
 tests/qemu-iotests/037 | 1 -
 tests/qemu-iotests/038 | 1 -
 tests/qemu-iotests/039 | 1 -
 tests/qemu-iotests/042 | 1 -
 tests/qemu-iotests/043 | 1 -
 tests/qemu-iotests/046 | 1 -
 tests/qemu-iotests/047 | 1 -
 tests/qemu-iotests/049 | 1 -
 tests/qemu-iotests/050 | 1 -
 tests/qemu-iotests/051 | 1 -
 tests/qemu-iotests/052 | 1 -
 tests/qemu-iotests/053 | 1 -
 tests/qemu-iotests/054 | 1 -
 tests/qemu-iotests/058 | 1 -
 tests/qemu-iotests/059 | 1 -
 tests/qemu-iotests/060 | 1 -
 tests/qemu-iotests/061 | 1 -
 tests/qemu-iotests/062 | 1 -
 tests/qemu-iotests/063 | 1 -
 tests/qemu-iotests/064 | 1 -
 tests/qemu-iotests/066 | 1 -
 tests/qemu-iotests/067 | 1 -
 tests/qemu-iotests/068 | 1 -
 tests/qemu-iotests/069 | 1 -
 tests/qemu-iotests/070 | 1 -
 tests/qemu-iotests/071 | 1 -
 tests/qemu-iotests/072 | 1 -
 tests/qemu-iotests/073 | 1 -
 tests/qemu-iotests/075 | 1 -
 tests/qemu-iotests/076 | 1 -
 tests/qemu-iotests/077 | 1 -
 tests/qemu-iotests/078 | 1 -
 tests/qemu-iotests/079 | 1 -
 tests/qemu-iotests/080 | 1 -
 tests/qemu-iotests/081 | 1 -
 tests/qemu-iotests/082 | 1 -
 tests/qemu-iotests/083 | 1 -
 tests/qemu-iotests/084 | 1 -
 tests/qemu-iotests/085 | 1 -
 tests/qemu-iotests/086 | 1 -
 tests/qemu-iotests/087 | 1 -
 tests/qemu-iotests/088 | 1 -
 tests/qemu-iotests/089 | 1 -
 tests/qemu-iotests/090 | 1 -
 tests/qemu-iotests/091 | 1 -
 tests/qemu-iotests/092 | 1 -
 tests/qemu-iotests/094 | 1 -
 tests/qemu-iotests/095 | 1 -
 tests/qemu-iotests/097 | 1 -
 tests/qemu-iotests/098 | 1 -
 tests/qemu-iotests/099 | 1 -
 tests/qemu-iotests/101 | 1 -
 tests/qemu-iotests/102 | 1 -
 tests/qemu-iotests/103 | 1 -
 tests/qemu-iotests/104 | 1 -
 tests/qemu-iotests/105 | 1 -
 tests/qemu-iotests/106 | 1 -
 tests/qemu-iotests/107 | 1 -
 tests/qemu-iotests/108 | 1 -
 tests/qemu-iotests/109 | 1 -
 tests/qemu-iotests/110 | 1 -
 tests/qemu-iotests/111 | 1 -
 tests/qemu-iotests/112 | 1 -
 tests/qemu-iotests/113 | 1 -
 tests/qemu-iotests/114 | 1 -
 tests/qemu-iotests/115 | 1 -
 tests/qemu-iotests/116 | 1 -
 tests/qemu-iotests/117 | 1 -
 tests/qemu-iotests/119 | 1 -
 tests/qemu-iotests/120 | 1 -
 tests/qemu-iotests/121 | 1 -
 tests/qemu-iotests/122 | 1 -
 tests/qemu-iotests/123 | 1 -
 tests/qemu-iotests/125 | 1 -
 tests/qemu-iotests/126 | 1 -
 tests/qemu-iotests/127 | 1 -
 tests/qemu-iotests/128 | 1 -
 tests/qemu-iotests/130 | 1 -
 tests/qemu-iotests/131 | 1 -
 tests/qemu-iotests/133 | 1 -
 tests/qemu-iotests/134 | 1 -
 tests/qemu-iotests/135 | 1 -
 tests/qemu-iotests/137 | 1 -
 tests/qemu-iotests/138 | 1 -
 tests/qemu-iotests/140 | 1 -
 tests/qemu-iotests/141 | 1 -
 tests/qemu-iotests/142 | 1 -
 tests/qemu-iotests/143 | 1 -
 tests/qemu-iotests/144 | 1 -
 tests/qemu-iotests/145 | 1 -
 tests/qemu-iotests/146 | 1 -
 tests/qemu-iotests/150 | 1 -
 tests/qemu-iotests/153 | 1 -
 tests/qemu-iotests/154 | 1 -
 tests/qemu-iotests/156 | 1 -
 tests/qemu-iotests/157 | 1 -
 tests/qemu-iotests/158 | 1 -
 tests/qemu-iotests/162 | 1 -
 tests/qemu-iotests/171 | 1 -
 tests/qemu-iotests/172 | 1 -
 tests/qemu-iotests/173 | 1 -
 tests/qemu-iotests/174 | 9 +++--
 tests/qemu-iotests/175 | 1 -
 tests/qemu-iotests/176 | 1 -
 tests/qemu-iotests/178 | 1 -
 tests/qemu-iotests/181 | 1 -
 tests/qemu-iotests/182 | 1 -
 tests/qemu-iotests/183 | 1 -
 tests/qemu-iotests/184 | 1 -
 tests/qemu-iotests/185 | 1 -
 tests/qemu-iotests/186 | 1 -
 tests/qemu-iotests/187 | 1 -
 tests/qemu-iotests/188 | 1 -
 tests/qemu-iotests/189 | 1 -
 tests/qemu-iotests/190 | 1 -
 tests/qemu-iotests/191 | 1 -
 tests/qemu-iotests/192 | 1 -
 tests/qemu-iotests/195 | 1 -
 151 files changed, 7 insertions(+), 152 deletions(-)

diff --git a/tests/qemu-iotests/001 

[Qemu-devel] [PATCH 03/10] qemu-iotests: be strict with expected output

[Cleber Rosa]

The contract between runner (check) and test is one that accepts some
minor differences in the expcted output, as the comparison method
employed is a "diff -w".

This is an exception to a clearer and more straightforward rule of
just requiring the generated output to be *equal* (and not similar) to
the recorded expected output.

Let's drop this exception and make things more predictable.

Signed-off-by: Cleber Rosa 
---
 tests/qemu-iotests/026.out | 92 +++---
 tests/qemu-iotests/049.out |  4 +-
 tests/qemu-iotests/061.out |  4 +-
 tests/qemu-iotests/104.out |  2 +-
 tests/qemu-iotests/109.out | 44 +++---
 tests/qemu-iotests/175.out |  2 +-
 tests/qemu-iotests/check   |  4 +-
 7 files changed, 76 insertions(+), 76 deletions(-)

diff --git a/tests/qemu-iotests/026.out b/tests/qemu-iotests/026.out
index 86a50a2e13..38d76418b7 100644
--- a/tests/qemu-iotests/026.out
+++ b/tests/qemu-iotests/026.out
@@ -3,7 +3,7 @@ Errors while writing 128 kB
 
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
 
-Event: l1_update; errno: 5; imm: off; once: on; write
+Event: l1_update; errno: 5; imm: off; once: on; write 
 write failed: Input/output error
 No errors were found on the image.
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
@@ -13,7 +13,7 @@ write failed: Input/output error
 No errors were found on the image.
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
 
-Event: l1_update; errno: 5; imm: off; once: off; write
+Event: l1_update; errno: 5; imm: off; once: off; write 
 Failed to flush the L2 table cache: Input/output error
 Failed to flush the refcount block cache: Input/output error
 write failed: Input/output error
@@ -31,7 +31,7 @@ write failed: Input/output error
 This means waste of disk space, but no harm to data.
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
 
-Event: l1_update; errno: 28; imm: off; once: on; write
+Event: l1_update; errno: 28; imm: off; once: on; write 
 write failed: No space left on device
 No errors were found on the image.
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
@@ -41,7 +41,7 @@ write failed: No space left on device
 No errors were found on the image.
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
 
-Event: l1_update; errno: 28; imm: off; once: off; write
+Event: l1_update; errno: 28; imm: off; once: off; write 
 Failed to flush the L2 table cache: No space left on device
 Failed to flush the refcount block cache: No space left on device
 write failed: No space left on device
@@ -59,7 +59,7 @@ write failed: No space left on device
 This means waste of disk space, but no harm to data.
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
 
-Event: l2_load; errno: 5; imm: off; once: on; write
+Event: l2_load; errno: 5; imm: off; once: on; write 
 wrote 131072/131072 bytes at offset 0
 128 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 write failed: Input/output error
@@ -75,7 +75,7 @@ read failed: Input/output error
 No errors were found on the image.
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
 
-Event: l2_load; errno: 5; imm: off; once: off; write
+Event: l2_load; errno: 5; imm: off; once: off; write 
 wrote 131072/131072 bytes at offset 0
 128 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 write failed: Input/output error
@@ -91,7 +91,7 @@ read failed: Input/output error
 No errors were found on the image.
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
 
-Event: l2_load; errno: 28; imm: off; once: on; write
+Event: l2_load; errno: 28; imm: off; once: on; write 
 wrote 131072/131072 bytes at offset 0
 128 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 write failed: No space left on device
@@ -107,7 +107,7 @@ read failed: No space left on device
 No errors were found on the image.
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
 
-Event: l2_load; errno: 28; imm: off; once: off; write
+Event: l2_load; errno: 28; imm: off; once: off; write 
 wrote 131072/131072 bytes at offset 0
 128 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 write failed: No space left on device
@@ -123,7 +123,7 @@ read failed: No space left on device
 No errors were found on the image.
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
 
-Event: l2_update; errno: 5; imm: off; once: on; write
+Event: l2_update; errno: 5; imm: off; once: on; write 
 write failed: Input/output error
 No errors were found on the image.
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
@@ -133,7 +133,7 @@ write failed: Input/output error
 No errors were found on the image.
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
 
-Event: l2_update; errno: 5; imm: off; once: off; write
+Event: l2_update; errno: 5; imm: off; once: off; write 
 Failed to flush the L2 table cache: Input/output error
 Failed to flush the refcount block cache: Input/output error
 write failed: Input/output 

[Qemu-devel] [PATCH 01/10] qemu-iotests: make execution of tests agnostic to test type

[Cleber Rosa]

check makes a distinction on how it runs Python based tests.  The
current approach is inconsistent because:

1) a large number of Python tests are already set as executable files
(eg: 030, 040, 041, 044, 045, 055, 056, 057, 065, 093, 118, 147, 149,
155, 165 and 194)

2) a smaller number of Python tests are not set as executable files

3) the true purpose of a shebang line is to make a file executable,
while it currently is used (inconsistently) as a test type flag

4) the same logic could in theory be applied to shell based tests,
that is, if first line contains a shell shebang, run it with
"$SHELL $test_file", but it'd be pointless

IMO, there's no value in the distinction that check makes.  Dropping
this distinction makes the interface simpler: check requires an
executable file.

Signed-off-by: Cleber Rosa 
---
 tests/qemu-iotests/096   | 0
 tests/qemu-iotests/124   | 0
 tests/qemu-iotests/129   | 0
 tests/qemu-iotests/132   | 0
 tests/qemu-iotests/136   | 0
 tests/qemu-iotests/139   | 0
 tests/qemu-iotests/148   | 0
 tests/qemu-iotests/152   | 0
 tests/qemu-iotests/163   | 0
 tests/qemu-iotests/check | 9 ++---
 10 files changed, 2 insertions(+), 7 deletions(-)
 mode change 100644 => 100755 tests/qemu-iotests/096
 mode change 100644 => 100755 tests/qemu-iotests/124
 mode change 100644 => 100755 tests/qemu-iotests/129
 mode change 100644 => 100755 tests/qemu-iotests/132
 mode change 100644 => 100755 tests/qemu-iotests/136
 mode change 100644 => 100755 tests/qemu-iotests/139
 mode change 100644 => 100755 tests/qemu-iotests/148
 mode change 100644 => 100755 tests/qemu-iotests/152
 mode change 100644 => 100755 tests/qemu-iotests/163

diff --git a/tests/qemu-iotests/096 b/tests/qemu-iotests/096
old mode 100644
new mode 100755
diff --git a/tests/qemu-iotests/124 b/tests/qemu-iotests/124
old mode 100644
new mode 100755
diff --git a/tests/qemu-iotests/129 b/tests/qemu-iotests/129
old mode 100644
new mode 100755
diff --git a/tests/qemu-iotests/132 b/tests/qemu-iotests/132
old mode 100644
new mode 100755
diff --git a/tests/qemu-iotests/136 b/tests/qemu-iotests/136
old mode 100644
new mode 100755
diff --git a/tests/qemu-iotests/139 b/tests/qemu-iotests/139
old mode 100644
new mode 100755
diff --git a/tests/qemu-iotests/148 b/tests/qemu-iotests/148
old mode 100644
new mode 100755
diff --git a/tests/qemu-iotests/152 b/tests/qemu-iotests/152
old mode 100644
new mode 100755
diff --git a/tests/qemu-iotests/163 b/tests/qemu-iotests/163
old mode 100644
new mode 100755
diff --git a/tests/qemu-iotests/check b/tests/qemu-iotests/check
index e6b6ff7a04..08741328d0 100755
--- a/tests/qemu-iotests/check
+++ b/tests/qemu-iotests/check
@@ -741,20 +741,15 @@ do
 start=`_wallclock`
 $timestamp && printf %s "[$(date "+%T")]"
 
-if [ "$(head -n 1 "$source_iotests/$seq")" == "#!/usr/bin/env python" 
]; then
-run_command="$PYTHON $seq"
-else
-run_command="./$seq"
-fi
 export OUTPUT_DIR=$PWD
 if $debug; then
 (cd "$source_iotests";
 MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(($RANDOM % 255 + 1))} \
-$run_command -d 2>&1 | tee $tmp.out)
+./$seq -d 2>&1 | tee $tmp.out)
 else
 (cd "$source_iotests";
 MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(($RANDOM % 255 + 1))} \
-$run_command >$tmp.out 2>&1)
+./$seq >$tmp.out 2>&1)
 fi
 sts=$?
 $timestamp && _timestamp
-- 
2.13.6

[Qemu-devel] [PATCH 08/10] qemu-iotests: clean up double comment characters

[Cleber Rosa]

This is a syntactic only change, just to make it consistent with
the style used on all other tests.

Signed-off-by: Cleber Rosa 
---
 tests/qemu-iotests/048 | 37 ++---
 tests/qemu-iotests/074 | 40 
 2 files changed, 38 insertions(+), 39 deletions(-)

diff --git a/tests/qemu-iotests/048 b/tests/qemu-iotests/048
index 531bed217c..3253d77c91 100755
--- a/tests/qemu-iotests/048
+++ b/tests/qemu-iotests/048
@@ -1,23 +1,22 @@
 #!/bin/bash
-##
-## qemu-img compare test
-##
-##
-## Copyright (C) 2013 Red Hat, Inc.
-##
-## This program is free software; you can redistribute it and/or modify
-## it under the terms of the GNU General Public License as published by
-## the Free Software Foundation; either version 2 of the License, or
-## (at your option) any later version.
-##
-## This program is distributed in the hope that it will be useful,
-## but WITHOUT ANY WARRANTY; without even the implied warranty of
-## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-## GNU General Public License for more details.
-##
-## You should have received a copy of the GNU General Public License
-## along with this program.  If not, see .
-##
+#
+# qemu-img compare test
+#
+#
+# Copyright (C) 2013 Red Hat, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
 #
 # Creator/Owner: mreza...@redhat.com
 #
diff --git a/tests/qemu-iotests/074 b/tests/qemu-iotests/074
index d454580067..d09c909bd8 100755
--- a/tests/qemu-iotests/074
+++ b/tests/qemu-iotests/074
@@ -1,24 +1,24 @@
 #!/bin/bash
-##
-## qemu-img compare test (qcow2 only ones)
-##
-##
-## Copyright (C) 2013 Red Hat, Inc.
-##
-## This program is free software; you can redistribute it and/or modify
-## it under the terms of the GNU General Public License as published by
-## the Free Software Foundation; either version 2 of the License, or
-## (at your option) any later version.
-##
-## This program is distributed in the hope that it will be useful,
-## but WITHOUT ANY WARRANTY; without even the implied warranty of
-## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-## GNU General Public License for more details.
-##
-## You should have received a copy of the GNU General Public License
-## along with this program.  If not, see .
-##
-## Creator/Owner: f...@redhat.com
+#
+# qemu-img compare test (qcow2 only ones)
+#
+#
+# Copyright (C) 2013 Red Hat, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+#
+# Creator/Owner: f...@redhat.com
 #
 
 seq=`basename $0`
-- 
2.13.6

[Qemu-devel] [PATCH 00/10] I/O tests cleanups

[Cleber Rosa]

Hi all,

This is a collection of cleanups, simplifications, and hopefully
improvements to the I/O tests.

Please don't mind the "change noise": this almost qualifies as a
collection of trivial patches.  It skips that category (of trivial
patches) because it proposes a few conceptual changes to how tests are
executed and verified.

Thanks!

---

Cleber Rosa (10):
  qemu-iotests: add section on how to write a new I/O test
  qemu-iotests: remove unused "here" variable
  qemu-iotests: clean up double comment characters
  qemu-iotests: remove the concept of $seq.full (and boiler plate code)
  qemu-iotests: turn owner variable into a comment
  qemu-iotests: define functions used in _cleanup() before its use
  qemu-iotests: include (source) filters from common.rc
  qemu-iotests: be strict with expected output
  qemu-iotests: fix filename containing checks
  qemu-iotests: make execution of tests agnostic to test type

 tests/qemu-iotests/001| 14 ++--
 tests/qemu-iotests/002| 14 ++--
 tests/qemu-iotests/003| 14 ++--
 tests/qemu-iotests/004| 14 ++--
 tests/qemu-iotests/005| 14 ++--
 tests/qemu-iotests/007| 14 ++--
 tests/qemu-iotests/008| 14 ++--
 tests/qemu-iotests/009| 14 ++--
 tests/qemu-iotests/010| 14 ++--
 tests/qemu-iotests/011| 14 ++--
 tests/qemu-iotests/012| 14 ++--
 tests/qemu-iotests/013| 16 ++--
 tests/qemu-iotests/014| 16 ++--
 tests/qemu-iotests/015| 14 ++--
 tests/qemu-iotests/017| 16 ++--
 tests/qemu-iotests/018| 16 ++--
 tests/qemu-iotests/019| 16 ++--
 tests/qemu-iotests/020| 16 ++--
 tests/qemu-iotests/021| 14 ++--
 tests/qemu-iotests/022| 16 ++--
 tests/qemu-iotests/023| 16 ++--
 tests/qemu-iotests/024| 16 ++--
 tests/qemu-iotests/025| 16 ++--
 tests/qemu-iotests/026| 16 ++--
 tests/qemu-iotests/026.out| 92 ++---
 tests/qemu-iotests/027| 14 ++--
 tests/qemu-iotests/028| 18 ++--
 tests/qemu-iotests/029| 16 ++--
 tests/qemu-iotests/031| 16 ++--
 tests/qemu-iotests/032| 16 ++--
 tests/qemu-iotests/033| 14 ++--
 tests/qemu-iotests/034| 14 ++--
 tests/qemu-iotests/035| 14 ++--
 tests/qemu-iotests/036| 16 ++--
 tests/qemu-iotests/037| 14 ++--
 tests/qemu-iotests/038| 14 ++--
 tests/qemu-iotests/039| 14 ++--
 tests/qemu-iotests/040|  1 +
 tests/qemu-iotests/042| 14 ++--
 tests/qemu-iotests/043| 14 ++--
 tests/qemu-iotests/046| 14 ++--
 tests/qemu-iotests/047| 14 ++--
 tests/qemu-iotests/048| 52 ++--
 tests/qemu-iotests/049| 14 ++--
 tests/qemu-iotests/049.out|  4 +-
 tests/qemu-iotests/050| 14 ++--
 tests/qemu-iotests/051| 14 ++--
 tests/qemu-iotests/052| 14 ++--
 tests/qemu-iotests/053| 14 ++--
 tests/qemu-iotests/054| 14 ++--
 tests/qemu-iotests/058| 16 ++--
 tests/qemu-iotests/059| 14 ++--
 tests/qemu-iotests/060| 14 ++--
 tests/qemu-iotests/061| 14 ++--
 tests/qemu-iotests/061.out|  4 +-
 tests/qemu-iotests/062| 14 ++--
 tests/qemu-iotests/063| 16 ++--
 tests/qemu-iotests/064| 14 ++--
 tests/qemu-iotests/066| 14 ++--
 tests/qemu-iotests/067|  8 +-
 tests/qemu-iotests/068| 14 ++--
 tests/qemu-iotests/069| 14 ++--
 tests/qemu-iotests/070| 14 ++--
 tests/qemu-iotests/071| 14 ++--
 tests/qemu-iotests/072| 14 ++--
 tests/qemu-iotests/073| 14 ++--
 tests/qemu-iotests/074  

[Qemu-devel] [PATCH 02/10] qemu-iotests: fix filename containing checks

[Cleber Rosa]

Commit cce293a2945 moved some functions from common.config to
common.rc, but the error messages still reference the old file
location.

Signed-off-by: Cleber Rosa 
---
 tests/qemu-iotests/common.rc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/qemu-iotests/common.rc b/tests/qemu-iotests/common.rc
index dbae7d74ba..dcabe4c7cc 100644
--- a/tests/qemu-iotests/common.rc
+++ b/tests/qemu-iotests/common.rc
@@ -169,12 +169,12 @@ if [ ! -e "$TEST_DIR" ]; then
 fi
 
 if [ ! -d "$TEST_DIR" ]; then
-echo "common.config: Error: \$TEST_DIR ($TEST_DIR) is not a directory"
+echo "common.rc: Error: \$TEST_DIR ($TEST_DIR) is not a directory"
 exit 1
 fi
 
 if [ ! -d "$SAMPLE_IMG_DIR" ]; then
-echo "common.config: Error: \$SAMPLE_IMG_DIR ($SAMPLE_IMG_DIR) is not a 
directory"
+echo "common.rc: Error: \$SAMPLE_IMG_DIR ($SAMPLE_IMG_DIR) is not a 
directory"
 exit 1
 fi
 
-- 
2.13.6