Re: [Qemu-devel] [PATCH v5 1/1] crypto: add virtio-crypto driver

[kbuild test robot]

Hi Gonglei,

[auto build test ERROR on cryptodev/master]
[also build test ERROR on v4.9-rc7 next-20161202]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Gonglei/crypto-add-virtio-crypto-driver/20161202-190424
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   In file included from arch/sparc/include/asm/topology.h:4:0,
from include/linux/topology.h:35,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/crypto/virtio/virtio_crypto_mgr.c:21:
   drivers/crypto/virtio/virtio_crypto_common.h: In function 
'virtio_crypto_get_current_node':
>> arch/sparc/include/asm/topology_64.h:44:44: error: implicit declaration of 
>> function 'cpu_data' [-Werror=implicit-function-declaration]
#define topology_physical_package_id(cpu) (cpu_data(cpu).proc_id)
   ^
   drivers/crypto/virtio/virtio_crypto_common.h:116:9: note: in expansion of 
macro 'topology_physical_package_id'
 return topology_physical_package_id(smp_processor_id());
^~~~
>> arch/sparc/include/asm/topology_64.h:44:57: error: request for member 
>> 'proc_id' in something not a structure or union
#define topology_physical_package_id(cpu) (cpu_data(cpu).proc_id)
^
   drivers/crypto/virtio/virtio_crypto_common.h:116:9: note: in expansion of 
macro 'topology_physical_package_id'
 return topology_physical_package_id(smp_processor_id());
^~~~
   cc1: some warnings being treated as errors

vim +/cpu_data +44 arch/sparc/include/asm/topology_64.h

f5e706ad include/asm-sparc/topology_64.h  Sam Ravnborg2008-07-17  
28  
9d079337 arch/sparc/include/asm/topology_64.h David Miller2009-01-11  
29  #define cpumask_of_pcibus(bus)\
9d079337 arch/sparc/include/asm/topology_64.h David Miller2009-01-11  
30(pcibus_to_node(bus) == -1 ? \
e9b37512 arch/sparc/include/asm/topology_64.h Rusty Russell   2009-03-16  
31 cpu_all_mask : \
9d079337 arch/sparc/include/asm/topology_64.h David Miller2009-01-11  
32 cpumask_of_node(pcibus_to_node(bus)))
f5e706ad include/asm-sparc/topology_64.h  Sam Ravnborg2008-07-17  
33  
52708d69 arch/sparc/include/asm/topology_64.h Nitin Gupta 2015-11-02  
34  int __node_distance(int, int);
52708d69 arch/sparc/include/asm/topology_64.h Nitin Gupta 2015-11-02  
35  #define node_distance(a, b) __node_distance(a, b)
52708d69 arch/sparc/include/asm/topology_64.h Nitin Gupta 2015-11-02  
36  
f5e706ad include/asm-sparc/topology_64.h  Sam Ravnborg2008-07-17  
37  #else /* CONFIG_NUMA */
f5e706ad include/asm-sparc/topology_64.h  Sam Ravnborg2008-07-17  
38  
f5e706ad include/asm-sparc/topology_64.h  Sam Ravnborg2008-07-17  
39  #include 
f5e706ad include/asm-sparc/topology_64.h  Sam Ravnborg2008-07-17  
40  
f5e706ad include/asm-sparc/topology_64.h  Sam Ravnborg2008-07-17  
41  #endif /* !(CONFIG_NUMA) */
f5e706ad include/asm-sparc/topology_64.h  Sam Ravnborg2008-07-17  
42  
f5e706ad include/asm-sparc/topology_64.h  Sam Ravnborg2008-07-17  
43  #ifdef CONFIG_SMP
f5e706ad include/asm-sparc/topology_64.h  Sam Ravnborg2008-07-17 
@44  #define topology_physical_package_id(cpu) (cpu_data(cpu).proc_id)
f5e706ad include/asm-sparc/topology_64.h  Sam Ravnborg2008-07-17  
45  #define topology_core_id(cpu) (cpu_data(cpu).core_id)
acc455cf arch/sparc/include/asm/topology_64.h chris hyser 2015-04-22  
46  #define topology_core_cpumask(cpu)(_core_sib_map[cpu])
06931e62 arch/sparc/include/asm/topology_64.h Bartosz Golaszewski 2015-05-26  
47  #define topology_sibling_cpumask(cpu) (_cpu(cpu_sibling_map, 
cpu))
f5e706ad include/asm-sparc/topology_64.h  Sam Ravnborg2008-07-17  
48  #endif /* CONFIG_SMP */
f5e706ad include/asm-sparc/topology_64.h  Sam Ravnborg2008-07-17  
49  
3905c54f arch/sparc/include/asm/topology_64.h Stephen Rothwell2011-04-12  
50  extern cpumask_t cpu_core_map[NR_CPUS];
acc455cf arch/sparc/include/asm/topology_64.h chris hyser 2015-04-22  
51  extern cpumask_t 

[Qemu-devel] [PULL 1/4] target-mips: Fix Loongson pandn instruction.

[Yongbok Kim]

From: Heiher 

pandn FD, FS, FT
Operation: FD = ((NOT FS) AND FT)

Signed-off-by: Heiher 
Signed-off-by: Fuxin Zhang 
Reviewed-by: Yongbok Kim 
Signed-off-by: Yongbok Kim 
---
 target-mips/translate.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/target-mips/translate.c b/target-mips/translate.c
index d8dde7a..5ad97c7 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -3945,9 +3945,12 @@ static void gen_loongson_multimedia(DisasContext *ctx, 
int rd, int rs, int rt)
 LMI_DIRECT(XOR_CP2, xor, xor);
 LMI_DIRECT(NOR_CP2, nor, nor);
 LMI_DIRECT(AND_CP2, and, and);
-LMI_DIRECT(PANDN, pandn, andc);
 LMI_DIRECT(OR, or, or);
 
+case OPC_PANDN:
+tcg_gen_andc_i64(t0, t1, t0);
+break;
+
 case OPC_PINSRH_0:
 tcg_gen_deposit_i64(t0, t0, t1, 0, 16);
 break;
-- 
2.7.4

[Qemu-devel] [PULL 3/4] target-mips: Fix Loongson multimedia instructions.

[Yongbok Kim]

From: Heiher 

Needed to emit FPU exception on Loongson multimedia instructions
executing if Status:CU1 is clear. or FPR changes may be missed
on Linux.

Signed-off-by: Heiher 
Signed-off-by: Fuxin Zhang 
Reviewed-by: Yongbok Kim 
Signed-off-by: Yongbok Kim 
---
 target-mips/translate.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target-mips/translate.c b/target-mips/translate.c
index e26f742..57b824f 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -3871,6 +3871,7 @@ static void gen_loongson_multimedia(DisasContext *ctx, 
int rd, int rs, int rt)
 break;
 }
 
+check_cp1_enabled(ctx);
 gen_load_fpr64(ctx, t0, rs);
 gen_load_fpr64(ctx, t1, rt);
 
-- 
2.7.4

[Qemu-devel] [PULL 2/4] target-mips: Fix Loongson multimedia 'or' instruction.

[Yongbok Kim]

From: Heiher 

Signed-off-by: Heiher 
Signed-off-by: Fuxin Zhang 
Reviewed-by: Yongbok Kim 
Signed-off-by: Yongbok Kim 
---
 target-mips/translate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target-mips/translate.c b/target-mips/translate.c
index 5ad97c7..e26f742 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -3945,7 +3945,7 @@ static void gen_loongson_multimedia(DisasContext *ctx, 
int rd, int rs, int rt)
 LMI_DIRECT(XOR_CP2, xor, xor);
 LMI_DIRECT(NOR_CP2, nor, nor);
 LMI_DIRECT(AND_CP2, and, and);
-LMI_DIRECT(OR, or, or);
+LMI_DIRECT(OR_CP2, or, or);
 
 case OPC_PANDN:
 tcg_gen_andc_i64(t0, t1, t0);
-- 
2.7.4

[Qemu-devel] [PULL 0/4] target-mips queue

[Yongbok Kim]

Hi,

This is pull-req for target-mips.

Regards,
Yongbok

The following changes since commit bd8ef5060dd2124a54578241da9a572faf7658dd:

  Merge remote-tracking branch 'dgibson/tags/ppc-for-2.8-20161201' into staging 
(2016-12-01 13:39:29 +)

are available in the git repository at:

  git://github.com/yongbok/upstream-qemu.git tags/mips-20161204

for you to fetch changes up to e6e2784cacd4cfec149a7690976b9ff15e541c4d:

  target-mips: fix bad shifts in {dextp|dextpdp} (2016-12-04 00:57:06 +)


MIPS patches 2016-12-04

Changes:
* Fix Loongson instructions
* Fix bad shifts in {dextp|dextpdp}


Heiher (3):
  target-mips: Fix Loongson pandn instruction.
  target-mips: Fix Loongson multimedia 'or' instruction.
  target-mips: Fix Loongson multimedia instructions.

Yongbok Kim (1):
  target-mips: fix bad shifts in {dextp|dextpdp}

 target-mips/dsp_helper.c | 4 ++--
 target-mips/translate.c  | 8 ++--
 2 files changed, 8 insertions(+), 4 deletions(-)

[Qemu-devel] [PULL 4/4] target-mips: fix bad shifts in {dextp|dextpdp}

[Yongbok Kim]

Fixed issues in the MIPSDSP64 instructions dextp and dextpdp.
Shifting can go out of 32 bit range.

https://bugs.launchpad.net/qemu/+bug/1631625

Reported-by: Thomas Huth 
Reported-by: Jia Liu 
Signed-off-by: Yongbok Kim 
Reviewed-by: Thomas Huth 
---
 target-mips/dsp_helper.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target-mips/dsp_helper.c b/target-mips/dsp_helper.c
index df7d220..dc70793 100644
--- a/target-mips/dsp_helper.c
+++ b/target-mips/dsp_helper.c
@@ -3477,7 +3477,7 @@ target_ulong helper_dextp(target_ulong ac, target_ulong 
size, CPUMIPSState *env)
 
 if (sub >= -1) {
 temp = (tempB << (64 - len)) | (tempA >> len);
-temp = temp & ((0x01 << (size + 1)) - 1);
+temp = temp & ((1ULL << (size + 1)) - 1);
 set_DSPControl_efi(0, env);
 } else {
 set_DSPControl_efi(1, env);
@@ -3506,7 +3506,7 @@ target_ulong helper_dextpdp(target_ulong ac, target_ulong 
size,
 
 if (sub >= -1) {
 temp = (tempB << (64 - len)) | (tempA >> len);
-temp = temp & ((0x01 << (size + 1)) - 1);
+temp = temp & ((1ULL << (size + 1)) - 1);
 set_DSPControl_pos(sub, env);
 set_DSPControl_efi(0, env);
 } else {
-- 
2.7.4

Re: [Qemu-devel] [PATCH 2/7] target-ppc: Implement unsigned quadword left/right shift and unit tests

[Richard Henderson]

On 12/02/2016 09:00 PM, Jose Ricardo Ziviani wrote:

+++ b/include/qemu/host-utils.h
@@ -29,6 +29,33 @@
 #include "qemu/bswap.h"

 #ifdef CONFIG_INT128
+static inline void urshift(uint64_t *plow, uint64_t *phigh, uint32_t shift)
+{
+__uint128_t val = ((__uint128_t)*phigh << 64) | *plow;
+val >>= (shift & 127);
+*phigh = val >> 64;
+*plow = val & 0x;
+}
+
+static inline void ulshift(uint64_t *plow, uint64_t *phigh,
+   uint32_t shift, bool *overflow)
+{
+__uint128_t val = ((__uint128_t)*phigh << 64) | *plow;
+
+if (shift == 0) {
+return;
+}
+
+if (shift > 127 || (val >> (128 - (shift & 127))) != 0) {
+*overflow = true;
+}
+
+val <<= (shift & 127);
+
+*phigh = val >> 64;
+*plow = val & 0x;
+}
+


This belongs in qemu/int128.h, not here.  And certainly not predicated on 
CONFIG_INT128.



r~

Re: [Qemu-devel] [RFC] target-ppc/fpu_helper.c: Use C99 code to speed up floating point unit

[Richard Henderson]

On 12/03/2016 09:07 AM, Programmingkid wrote:

Yes it would be. The commit message never stated why he wanted to switch
to floating point softfloat routines. These are my guesses:

...

- Different hosts produced different results and instead wanted consistency?


This is the correct answer.  There are quite a lot of differences between 
floating point across different cpus.  Which means that it's actually rare that 
the host and guest floating point are exactly alike.



r~

Re: [Qemu-devel] [PATCH v4 14/64] target-arm: Use new deposit and extract ops

[Richard Henderson]

On 12/01/2016 09:19 AM, Alex Bennée wrote:

In fact we seem to have subtly reversed the test here but ri <= si is
not exactly equivalent to si >= ri.

My version is as follows:

/* Recognize simple(r) extractions.  */
if (si >= ri) {
/* Wd = Wn */
len = (si - ri) + 1;
if (opc == 0) { /* SBFM: ASR, SBFX, SXTB, SXTH, SXTW */
tcg_gen_sextract_i64(tcg_rd, tcg_tmp, ri, len);
goto done;
} else if (opc == 2) { /* UBFM: UBFX, LSR, UXTB, UXTH */
tcg_gen_extract_i64(tcg_rd, tcg_tmp, ri, len);
return;
}
/* opc == 1, BXFIL fall through to deposit */
tcg_gen_extract_i64(tcg_tmp, tcg_tmp, ri, len);
pos = 0;
} else {
/* Handle the ri > si case with a deposit
 * Wd<32+s-r,32-r> = Wn
 */
len = si + 1;
pos = (bitsize - ri) & (bitsize - 1);
}

I've tested that with risu and all the bitfield tests seem ok.


Thanks.  Merged.


r~

[Qemu-devel] [PATCH] qcow2: Discard/zero clusters by byte count

[Eric Blake]

Passing a byte offset, but sector count, when we ultimately
want to operate on cluster granularity, is madness.  Clean up
the interfaces to take byte offset and count.  Rename
qcow2_discard_clusters() and qcow2_zero_clusters() to the
shorter qcow2_discard() and qcow2_zero() to make sure backports
don't get confused by changed units.

Signed-off-by: Eric Blake 
---

2.9 material, depends on 'Don't strand clusters near 2G intervals
during commit'

 block/qcow2.h  |  8 
 block/qcow2-cluster.c  | 20 +++-
 block/qcow2-snapshot.c |  7 +++
 block/qcow2.c  | 22 ++
 4 files changed, 28 insertions(+), 29 deletions(-)

diff --git a/block/qcow2.h b/block/qcow2.h
index 1823414..a0d169b 100644
--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -543,10 +543,10 @@ uint64_t 
qcow2_alloc_compressed_cluster_offset(BlockDriverState *bs,
  int compressed_size);

 int qcow2_alloc_cluster_link_l2(BlockDriverState *bs, QCowL2Meta *m);
-int qcow2_discard_clusters(BlockDriverState *bs, uint64_t offset,
-int nb_sectors, enum qcow2_discard_type type, bool full_discard);
-int qcow2_zero_clusters(BlockDriverState *bs, uint64_t offset, int nb_sectors,
-int flags);
+int qcow2_discard(BlockDriverState *bs, uint64_t offset, uint64_t count,
+  enum qcow2_discard_type type, bool full_discard);
+int qcow2_zero(BlockDriverState *bs, uint64_t offset, uint64_t count,
+   int flags);

 int qcow2_expand_zero_clusters(BlockDriverState *bs,
BlockDriverAmendStatusCB *status_cb,
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 928c1e2..3ee0815 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -1511,19 +1511,17 @@ static int discard_single_l2(BlockDriverState *bs, 
uint64_t offset,
 return nb_clusters;
 }

-int qcow2_discard_clusters(BlockDriverState *bs, uint64_t offset,
-int nb_sectors, enum qcow2_discard_type type, bool full_discard)
+int qcow2_discard(BlockDriverState *bs, uint64_t offset, uint64_t count,
+  enum qcow2_discard_type type, bool full_discard)
 {
 BDRVQcow2State *s = bs->opaque;
 uint64_t end_offset;
 uint64_t nb_clusters;
 int ret;

-end_offset = offset + (nb_sectors << BDRV_SECTOR_BITS);
-
-/* Round start up and end down */
+/* Round start up and end down to cluster boundary */
+end_offset = start_of_cluster(s, offset + count);
 offset = align_offset(offset, s->cluster_size);
-end_offset = start_of_cluster(s, end_offset);

 if (offset > end_offset) {
 return 0;
@@ -1595,20 +1593,24 @@ static int zero_single_l2(BlockDriverState *bs, 
uint64_t offset,
 return nb_clusters;
 }

-int qcow2_zero_clusters(BlockDriverState *bs, uint64_t offset, int nb_sectors,
-int flags)
+int qcow2_zero(BlockDriverState *bs, uint64_t offset, uint64_t count,
+   int flags)
 {
 BDRVQcow2State *s = bs->opaque;
 uint64_t nb_clusters;
 int ret;

+/* Block layer guarantees cluster alignment */
+assert(QEMU_IS_ALIGNED(offset, s->cluster_size));
+assert(QEMU_IS_ALIGNED(count, s->cluster_size));
+
 /* The zero flag is only supported by version 3 and newer */
 if (s->qcow_version < 3) {
 return -ENOTSUP;
 }

 /* Each L2 table is handled by its own loop iteration */
-nb_clusters = size_to_clusters(s, nb_sectors << BDRV_SECTOR_BITS);
+nb_clusters = size_to_clusters(s, count);

 s->cache_discards = true;

diff --git a/block/qcow2-snapshot.c b/block/qcow2-snapshot.c
index 0324243..fd088e5 100644
--- a/block/qcow2-snapshot.c
+++ b/block/qcow2-snapshot.c
@@ -440,10 +440,9 @@ int qcow2_snapshot_create(BlockDriverState *bs, 
QEMUSnapshotInfo *sn_info)

 /* The VM state isn't needed any more in the active L1 table; in fact, it
  * hurts by causing expensive COW for the next snapshot. */
-qcow2_discard_clusters(bs, qcow2_vm_state_offset(s),
-   align_offset(sn->vm_state_size, s->cluster_size)
->> BDRV_SECTOR_BITS,
-   QCOW2_DISCARD_NEVER, false);
+qcow2_discard(bs, qcow2_vm_state_offset(s),
+  align_offset(sn->vm_state_size, s->cluster_size),
+  QCOW2_DISCARD_NEVER, false);

 #ifdef DEBUG_ALLOC
 {
diff --git a/block/qcow2.c b/block/qcow2.c
index 369b542..601831f 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -2487,7 +2487,7 @@ static coroutine_fn int 
qcow2_co_pwrite_zeroes(BlockDriverState *bs,
 trace_qcow2_pwrite_zeroes(qemu_coroutine_self(), offset, count);

 /* Whatever is left can use real zero clusters */
-ret = qcow2_zero_clusters(bs, offset, count >> BDRV_SECTOR_BITS, flags);
+ret = qcow2_zero(bs, offset, count, flags);
 qemu_co_mutex_unlock(>lock);

 return ret;
@@ -2505,8 +2505,7 @@ static coroutine_fn int 

[Qemu-devel] [PATCH for-2.8] qcow2: Don't strand clusters near 2G intervals during commit

[Eric Blake]

The qcow2_make_empty() function is reached during 'qemu-img commit',
in order to clear out ALL clusters of an image.  However, if the
image cannot use the fast code path (true if the image is format
0.10, or if the image contains a snapshot), the cluster size is
larger than 512, and the image is larger than 2G in size, then our
choice of sector_step causes problems.  Since it is not cluster
aligned, but qcow2_discard_clusters() silently ignores an unaligned
head or tail, we are leaving clusters allocated.

Enhance the testsuite to expose the flaw, and patch the problem by
ensuring our step size is aligned.

[qcow2_discard_clusters() is a GROSS interface: it takes a mix of
byte offset and sector count to perform cluster operations. But
fixing it to use a saner byte/byte rather than byte/sector interface,
and/or asserting that the counts are now aligned thanks to both
this patch and commit 3482b9b, is material for another day.]

Signed-off-by: Eric Blake 
---
 block/qcow2.c  |   3 +-
 tests/qemu-iotests/097 |  41 +---
 tests/qemu-iotests/097.out | 249 +
 3 files changed, 210 insertions(+), 83 deletions(-)

diff --git a/block/qcow2.c b/block/qcow2.c
index ed9e0f3..369b542 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -2808,7 +2808,8 @@ static int qcow2_make_empty(BlockDriverState *bs)
 {
 BDRVQcow2State *s = bs->opaque;
 uint64_t start_sector;
-int sector_step = INT_MAX / BDRV_SECTOR_SIZE;
+int sector_step = QEMU_ALIGN_DOWN(INT_MAX / BDRV_SECTOR_SIZE,
+  s->cluster_size);
 int l1_clusters, ret = 0;

 l1_clusters = DIV_ROUND_UP(s->l1_size, s->cluster_size / sizeof(uint64_t));
diff --git a/tests/qemu-iotests/097 b/tests/qemu-iotests/097
index 01d8dd0..4c33e80 100755
--- a/tests/qemu-iotests/097
+++ b/tests/qemu-iotests/097
@@ -46,7 +46,7 @@ _supported_proto file
 _supported_os Linux


-# Four passes:
+# Four main passes:
 #  0: Two-layer backing chain, commit to upper backing file (implicitly)
 # (in this case, the top image will be emptied)
 #  1: Two-layer backing chain, commit to upper backing file (explicitly)
@@ -56,22 +56,30 @@ _supported_os Linux
 #  3: Two-layer backing chain, commit to lower backing file
 # (in this case, the top image will implicitly stay unchanged)
 #
+# Each pass is run twice, since qcow2 has different code paths for cleaning
+# an image depending on whether it has a snapshot.
+#
 # 020 already tests committing, so this only tests whether image chains are
 # working properly and that all images above the base are emptied; therefore,
-# no complicated patterns are necessary
+# no complicated patterns are necessary.  Check near the 2G mark, as qcow2
+# has been buggy at that boundary in the past.
 for i in 0 1 2 3; do
+for j in 0 1; do

 echo
-echo "=== Test pass $i ==="
+echo "=== Test pass $i.$j ==="
 echo

-TEST_IMG="$TEST_IMG.base" _make_test_img 64M
-TEST_IMG="$TEST_IMG.itmd" _make_test_img -b "$TEST_IMG.base" 64M
-_make_test_img -b "$TEST_IMG.itmd" 64M
+TEST_IMG="$TEST_IMG.base" _make_test_img 2100M
+TEST_IMG="$TEST_IMG.itmd" _make_test_img -b "$TEST_IMG.base" 2100M
+_make_test_img -b "$TEST_IMG.itmd" 2100M
+if [ $j -eq 0 ]; then
+$QEMU_IMG snapshot -c snap "$TEST_IMG"
+fi

-$QEMU_IO -c 'write -P 1 0 192k' "$TEST_IMG.base" | _filter_qemu_io
-$QEMU_IO -c 'write -P 2 64k 128k' "$TEST_IMG.itmd" | _filter_qemu_io
-$QEMU_IO -c 'write -P 3 128k 64k' "$TEST_IMG" | _filter_qemu_io
+$QEMU_IO -c 'write -P 1 0x7ffd 192k' "$TEST_IMG.base" | _filter_qemu_io
+$QEMU_IO -c 'write -P 2 0x7ffe 128k' "$TEST_IMG.itmd" | _filter_qemu_io
+$QEMU_IO -c 'write -P 3 0x7fff 64k' "$TEST_IMG" | _filter_qemu_io

 if [ $i -lt 3 ]; then
 if [ $i == 0 ]; then
@@ -88,12 +96,12 @@ if [ $i -lt 3 ]; then
 fi

 # Bottom should be unchanged
-$QEMU_IO -c 'read -P 1 0 192k' "$TEST_IMG.base" | _filter_qemu_io
+$QEMU_IO -c 'read -P 1 0x7ffd 192k' "$TEST_IMG.base" | _filter_qemu_io

 # Intermediate should contain changes from top
-$QEMU_IO -c 'read -P 1 0 64k' "$TEST_IMG.itmd" | _filter_qemu_io
-$QEMU_IO -c 'read -P 2 64k 64k' "$TEST_IMG.itmd" | _filter_qemu_io
-$QEMU_IO -c 'read -P 3 128k 64k' "$TEST_IMG.itmd" | _filter_qemu_io
+$QEMU_IO -c 'read -P 1 0x7ffd 64k' "$TEST_IMG.itmd" | _filter_qemu_io
+$QEMU_IO -c 'read -P 2 0x7ffe 64k' "$TEST_IMG.itmd" | _filter_qemu_io
+$QEMU_IO -c 'read -P 3 0x7fff 64k' "$TEST_IMG.itmd" | _filter_qemu_io

 # And in pass 0, the top image should be empty, whereas in both other 
passes
 # it should be unchanged (which is both checked by qemu-img map)
@@ -101,9 +109,9 @@ else
 $QEMU_IMG commit -b "$TEST_IMG.base" "$TEST_IMG"

 # Bottom should contain all changes
-$QEMU_IO -c 'read -P 1 0 64k' "$TEST_IMG.base" | _filter_qemu_io
-$QEMU_IO -c 'read -P 2 64k 64k' "$TEST_IMG.base" | _filter_qemu_io
-$QEMU_IO -c 'read -P 3 128k 64k' 

Re: [Qemu-devel] [RFC] target-ppc/fpu_helper.c: Use C99 code to speed up floating point unit

[Programmingkid]

On Dec 3, 2016, at 3:44 AM, Paolo Bonzini wrote:

> 
> 
> On 03/12/2016 06:59, Programmingkid wrote:
>> The floating point code used in fpu_helper.c can be sped up by using
>> the IEEE 754 support added to the C99 standard. To test this code out
>> simply set and unset the I_NEED_SPEED macro. The program to test out
>> each version of the helper_fmadd() function is below the patch. It
>> needs to be ran in the guest. The emulator to use is qemu-system-ppc.
>> I used a Mac OS X guest, but the test program would compile on a
>> Linux guest.
>> 
>> This patch does make the fused multiply-add instruction fmadd work
>> faster and still give a correct result.
>> 
>> This documentation might be of help to those who want to learn more
>> about C99's IEEE 754 support: 
>> http://grouper.ieee.org/groups/754/meeting-materials/2001-07-18-c99.pdf
> 
> You're undoing what was done in 2007:
> 
> commit 76a66253e5e48f1744f689041c1c21cedcaff630
> Author: j_mayer 
> Date:   Wed Mar 7 08:32:30 2007 +
> 
>Great PowerPC emulation code resynchronisation and improvments:
> ...
>- Micro-operation fixes:
> ...
>  * use softfloat routines for all floating-point operations
> 
> Paolo

Yes it would be. The commit message never stated why he wanted to switch
to floating point softfloat routines. These are my guesses:

- Different versions of gcc might have produced different results?
- Different hosts produced different results and instead wanted consistency?
- Author did not know about the C99 numerics support?

The C99 standard will keep results accurate on both different versions of 
gcc and different host architecture. It will also give us speed over
the softfloat routines. 

Re: [Qemu-devel] New wiki page: http://wiki.qemu.org/Hosts

[Programmingkid]

On Dec 3, 2016, at 3:57 AM, Thomas Huth wrote:

> On 02.12.2016 23:59, Programmingkid wrote:
>> I thought we could use a Hosts page to sort all the host documentation we 
>> have. It is located here: http://wiki.qemu.org/Hosts
> 
> Since it's documentation, shouldn't this rather go to
> /Documentation/Hosts instead of /Hosts ?

It is easier to type http://wiki.qemu.org/Hosts than 
http://wiki.qemu.org/Documentation/Hosts. Otherwise I don't have any objection 
to such a change. 

Re: [Qemu-devel] New wiki page: http://wiki.qemu.org/Hosts

[Programmingkid]

On Dec 3, 2016, at 3:41 AM, Paolo Bonzini wrote:

> 
> 
> On 02/12/2016 23:59, Programmingkid wrote:
>> I thought we could use a Hosts page to sort all the host documentation we 
>> have. It is located here: http://wiki.qemu.org/Hosts
>> 
>> Here is what I have so far:
>> 
>> AIX
>> Darwin
>> FreeBSD, NetBSD, OpenBSD
>> Linux
>> Mac OS X
>> Solaris
>> Windows
>> 
> 
> Since this stuff changes rarely, it should be in the source tree
> instead.  You can link to the source tree from the wiki with something
> like this:
> 
> {{src|path=BUILDING|description=the BUILDING file in the source tree}}
> 
> Would you like to make a patch moving the information from the wiki to
> such a file?

I'm not quite sure how to do that. 

When I tried out your link it failed to open the file. The file isn't found. 

[Qemu-devel] [PATCH v2 1/1] virtio crypto device specification: asymmetric crypto service

[Xin Zeng]

This patch introduces asymmetric crypto service into virtio crypto
device spec. The asymmetric crypto service can be referred as signature,
verification, encryption, decryption, key generation and key exchange.
This patch depends on virtio crypto device spec patch:
https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg02211.html

Changes since v1:
- Remove virtio_crypto_buf  to be consistent buffer structure with other
  virtio devices. [Lei]
- Use "MUST" instead of "SHOULD" in some places. [Lei]

Changes since v0:
- Use devicenormative/drivernormative instead of self-defined
  device/driver label.  [Lei]
- Change the error code of verification to general virtio_crypto
  error code. [Lei]
- Use macro instead of enum in verification result. [Lei]
- Fix the incorrect label value for paragraph and section. [Lei]

Please help to review, thanks!

Signed-off-by: Xin Zeng 
---
 virtio-crypto.tex | 1113 -
 1 file changed, 1110 insertions(+), 3 deletions(-)

diff --git a/virtio-crypto.tex b/virtio-crypto.tex
index 9f7faf0..c7a5a19 100644
--- a/virtio-crypto.tex
+++ b/virtio-crypto.tex
@@ -6,7 +6,7 @@ decryption requests are placed in the data queue and are 
ultimately handled by t
 backend crypto accelerators. The second queue is the control queue used to 
create 
 or destroy sessions for symmetric algorithms and will control some advanced
 features in the future. The virtio crypto device provides the following crypto
-services: CIPHER, MAC, HASH, and AEAD.
+services: CIPHER, MAC, HASH, AEAD and ASYM.
 
 
 \subsection{Device ID}\label{sec:Device Types / Crypto Device / Device ID}
@@ -44,11 +44,15 @@ struct virtio_crypto_config {
 le32 mac_algo_l;
 le32 mac_algo_h;
 le32 aead_algo;
+le32 asym_algo;
+/*Rsa padding capabilities*/
+le32 rsa_padding;
 /* Maximum length of cipher key */
 le32 max_cipher_key_len;
 /* Maximum length of authenticated key */
 le32 max_auth_key_len;
-le32 reserve;
+le32 reserved;
+
 /* Maximum size of each crypto request's content */
 le64 max_size;
 };
@@ -76,6 +80,8 @@ The following services are defined:
 #define VIRTIO_CRYPTO_SERVICE_MAC2
 /* AEAD (Authenticated Encryption with Associated Data) service */
 #define VIRTIO_CRYPTO_SERVICE_AEAD   3
+/* ASYM (Asymmetric crypto algorithms) service */
+#define VIRTIO_CRYPTO_SERVICE_ASYM   4
 \end{lstlisting}
 
 The last driver-read-only fields specify detailed algorithms masks 
@@ -149,6 +155,28 @@ The following AEAD algorithms are defined:
 #define VIRTIO_CRYPTO_AEAD_CHACHA20_POLY1305  3
 \end{lstlisting}
 
+The following asymmetric algorithms are defined:
+
+\begin{lstlisting}
+#define VIRTIO_CRYPTO_ASYM_NONE   0
+#define VIRTIO_CRYPTO_ASYM_RSA1
+#define VIRTIO_CRYPTO_ASYM_DSA2
+#define VIRTIO_CRYPTO_ASYM_DH 3
+#define VIRTIO_CRYPTO_ASYM_ECDSA  4
+#define VIRTIO_CRYPTO_ASYM_ECDH   5
+\end{lstlisting}
+
+The following rsa padding capabilities are defined:
+
+\begin{lstlisting}
+#define VIRTIO_CRYPTO_RSA_NO_PADDING  0
+#define VIRTIO_CRYPTO_RSA_PKCS1_PADDING   1
+#define VIRTIO_CRYPTO_RSA_SSLV23_PADDING  2
+#define VIRTIO_CRYPTO_RSA_PKCS1_OAEP_PADDING  3
+#define VIRTIO_CRYPTO_RSA_X931_PADDING4
+#define VIRTIO_CRYPTO_RSA_PKCS1_PSS_PADDING   5
+\end{lstlisting}
+
 \begin{note}
 Any other value is reserved for future use.
 \end{note}
@@ -164,6 +192,7 @@ Any other value is reserved for future use.
 \item The device MUST set \field{max_size} to show the maximum size of crypto 
request the device supports.
 \item The device MUST set \field{max_cipher_key_len} to show the maximum 
length of cipher key if the device supports CIPHER service.
 \item The device MUST set \field{max_auth_key_len} to show the maximum length 
of authenticated key if the device supports MAC service.
+\item The device MUST set \field{rsa_padding} to show the padding capabilities 
offered by the device.
 \end{itemize*}
 
 \drivernormative{\subsubsection}{Device configuration layout}{Device Types / 
Crypto Device / Device configuration layout}
@@ -178,6 +207,7 @@ Any other value is reserved for future use.
 \item The driver SHOULD read \field{max_size} to discover the maximum size of 
crypto request the device supports.
 \item The driver SHOULD read \field{max_cipher_key_len} to discover the 
maximum length of cipher key the device supports.
 \item The driver SHOULD read \field{max_auth_key_len} to discover the maximum 
length of authenticated key the device supports.
+\item The driver MAY read \field{rsa_padding} to discover the padding 
capabilities offered by the device.
 \end{itemize*}
 
 \subsection{Device Initialization}\label{sec:Device Types / Crypto Device / 
Device Initialization}
@@ -257,6 +287,18 @@ struct virtio_crypto_op_header {
 VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x00)
 #define VIRTIO_CRYPTO_AEAD_DECRYPT \
 VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x01)
+#define 

Re: [Qemu-devel] [PATCH v1 1/1] virtio crypto device specification: asymmetric crypto service

[Zeng, Xin]

Hi, Lei:
   Thanks for the comments. 

On Wednesday, November 30, 2016 9:25 AM, Gonglei (Arei) wrote:
> >
> >
> >  \subsection{Device ID}\label{sec:Device Types / Crypto Device / Device ID}
> > @@ -44,7 +44,9 @@ struct virtio_crypto_config {
> >  le32 mac_algo_l;
> >  le32 mac_algo_h;
> >  le32 aead_algo;
> > -le32 reserve;
> > +le32 asym_algo;
> > +le32 rsa_padding;
> > +le32 reserved;
> >  };
> 
> Please rebased on the latest virtio crypto spec,
> the config structure had been changed.
> 

Sure.

> >  \end{lstlisting}
> >
> > @@ -70,6 +72,8 @@ The following services are defined:
> >  #define VIRTIO_CRYPTO_SERVICE_MAC(2)
> >  /* AEAD (Authenticated Encryption with Associated Data) service */
> >  #define VIRTIO_CRYPTO_SERVICE_AEAD   (3)
> > +/* ASYM (Asymmetric crypto algorithms) service */
> > +#define VIRTIO_CRYPTO_SERVICE_ASYM   (4)
> >  \end{lstlisting}
> >
> >  The last driver-read-only fields specify detailed algorithms masks
> > @@ -143,6 +147,28 @@ The following AEAD algorithms are defined:
> >  #define VIRTIO_CRYPTO_AEAD_CHACHA20_POLY1305  3
> >  \end{lstlisting}
> >
> > +The following asymmetric algorithms are defined:
> > +
> > +\begin{lstlisting}
> > +#define VIRTIO_CRYPTO_ASYM_NONE0
> > +#define VIRTIO_CRYPTO_ASYM_RSA 1
> > +#define VIRTIO_CRYPTO_ASYM_DSA 2
> > +#define VIRTIO_CRYPTO_ASYM_DH  3
> > +#define VIRTIO_CRYPTO_ASYM_ECDSA   4
> > +#define VIRTIO_CRYPTO_ASYM_ECDH   5
> 
> Mixing tab and space.
> 

Will fix it in next version.

> > +\end{lstlisting}
> > +
> > +The following rsa padding capabilities are defined:
> > +
> 
> What're the padding capabilities used for?
> I think we should add some explanation for them.
> 

Makes sense, let's explain it more.

> > +\begin{lstlisting}
> > +#define VIRTIO_CRYPTO_RSA_NO_PADDING 0
> > +#define VIRTIO_CRYPTO_RSA_PKCS1_PADDING  1
> > +#define VIRTIO_CRYPTO_RSA_SSLV23_PADDING 2
> > +#define VIRTIO_CRYPTO_RSA_PKCS1_OAEP_PADDING 3
> > +#define VIRTIO_CRYPTO_RSA_X931_PADDING   4
> > +#define VIRTIO_CRYPTO_RSA_PKCS1_PSS_PADDING  5
> > +\end{lstlisting}
> > +
> >  \begin{note}
> >  Any other value is reserved for future use.
> >  \end{note}
> > @@ -241,6 +267,18 @@ struct virtio_crypto_op_header {
> >  VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x00)
> >  #define VIRTIO_CRYPTO_AEAD_DECRYPT \
> >  VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x01)
> > +#define VIRTIO_CRYPTO_ASYM_SIGN\
> > +VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x00)
> > +#define VIRTIO_CRYPTO_ASYM_VERIFY \
> > +VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x01)
> > +#define VIRTIO_CRYPTO_ASYM_ENCRYPT  \
> > +VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x02)
> > +#define VIRTIO_CRYPTO_ASYM_DECRYPT  \
> > +VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x03)
> > +#define VIRTIO_CRYPTO_ASYM_KEY_GEN  \
> > +VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x04)
> > +#define VIRTIO_CRYPTO_ASYM_KEY_EXCHG \
> > +VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_ASYM, 0x05)
> >  le32 opcode;
> >  /* algo should be service-specific algorithms */
> >  le32 algo;
> > @@ -548,6 +586,23 @@ struct virtio_crypto_op_data_req {
> >  struct virtio_crypto_hash_data_req  hash_req;
> >  struct virtio_crypto_mac_data_req   mac_req;
> >  struct virtio_crypto_aead_data_req  aead_req;
> > +
> > +struct virtio_crypto_ecdsa_sign_req ecdsa_sign_req;
> > +struct virtio_crypto_dsa_sign_req dsa_sign_req;
> > +struct virtio_crypto_rsa_sign_req rsa_sign_req;
> > +struct virtio_crypto_ecdsa_verify_req ecdsa_verify_req;
> > +struct virtio_crypto_dsa_verify_req dsa_verify_req;
> > +struct virtio_crypto_rsa_verify_req rsa_verify_req;
> > +struct virtio_crypto_rsa_enc_req rsa_enc_req
> > +struct virtio_crypto_rsa_dec_req rsa_dec_req;
> > +struct virtio_crypto_rsa_keygen_req rsa_keygen_req;
> > +struct virtio_crypto_dsa_keygen_req dsa_keygen_req;
> > +struct virtio_crypto_ec_keygen_req ec_keygen_req;
> > +struct virtio_crypto_dh_keyexchg_param_gen_req
> > dh_keyexchg_param_gen_req;
> > +struct virtio_crypto_dh_keyexchg_key_gen_req
> > dh_keyexchg_key_gen_req;
> > +struct virtio_crypto_dh_keyexchg_key_compute_req
> > dh_keyexchg_key_compute_req;
> > +struct virtio_crypto_ecdh_keyexchg_key_gen_req
> > ecdh_keyexchg_key_gen_req;
> > +struct virtio_crypto_ecdh_keyexchg_key_compute_req
> > ecdh_keyexchg_key_compute_req;
> >  } u;
> >  };
> >  \end{lstlisting}
> > @@ -996,4 +1051,908 @@ pointed by \field{dst_data_addr} and
> > \field{digest_result_addr} in struct virtio
> >  \item The device MUST copy the digest result to the guest memory
> recorded
> > by \field{digest_result_addr} field in struct virtio_crypto_aead_input.
> >  \item The device MUST set the \field{status} field in strut
> > 

Re: [Qemu-devel] [PATCH v3] doc: Add NBD_CMD_BLOCK_STATUS extension

[Alex Bligh]

> On 2 Dec 2016, at 20:39, John Snow  wrote:
> 
> OK. We do certainly support multiple bitmaps being active at a time in
> QEMU, but I had personally always envisioned that you'd associate them
> one-at-a-time when starting the NBD export of a particular device.
> 
> I don't have a use case in my head where two distinct bitmaps being
> exposed simultaneously offer any particular benefit, but maybe there is
> something. I'm sure there is.

The obvious case is an allocation bitmap, and a dirty bitmap.

It's possible one might want more than one dirty bitmap at once.
Perhaps two sorts of backup, or perhaps live migrate of storage
backed by NBD, or perhaps inspecting the *state* of live migration
via NBD and a bitmap, or perhaps determining what extents in
a QCOW image are in that image itself (as opposed to the image
on which it is based).

I tried to pick some QEMU-like ones, but I am sure there are
examples that would work outside of QEMU.

-- 
Alex Bligh

Re: [Qemu-devel] [PATCH] target-mips: fix bad shifts in {dextp|dextpdp}

[Thomas Huth]

On 30.11.2016 17:44, Yongbok Kim wrote:
> Fixed issues in the MIPSDSP64 instructions dextp and dextpdp.
> Shifting can go out of 32 bit range.
> 
> https://bugs.launchpad.net/qemu/+bug/1631625
> 
> Reported-by: Thomas Huth 
> Reported-by: Jia Liu 
> Signed-off-by: Yongbok Kim 
> ---
>  target-mips/dsp_helper.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/target-mips/dsp_helper.c b/target-mips/dsp_helper.c
> index df7d220..dc70793 100644
> --- a/target-mips/dsp_helper.c
> +++ b/target-mips/dsp_helper.c
> @@ -3477,7 +3477,7 @@ target_ulong helper_dextp(target_ulong ac, target_ulong 
> size, CPUMIPSState *env)
>  
>  if (sub >= -1) {
>  temp = (tempB << (64 - len)) | (tempA >> len);
> -temp = temp & ((0x01 << (size + 1)) - 1);
> +temp = temp & ((1ULL << (size + 1)) - 1);
>  set_DSPControl_efi(0, env);
>  } else {
>  set_DSPControl_efi(1, env);
> @@ -3506,7 +3506,7 @@ target_ulong helper_dextpdp(target_ulong ac, 
> target_ulong size,
>  
>  if (sub >= -1) {
>  temp = (tempB << (64 - len)) | (tempA >> len);
> -temp = temp & ((0x01 << (size + 1)) - 1);
> +temp = temp & ((1ULL << (size + 1)) - 1);
>  set_DSPControl_pos(sub, env);
>  set_DSPControl_efi(0, env);
>  } else {
> 

Reviewed-by: Thomas Huth 

Re: [Qemu-devel] [PATCH 02/20] blockjob: introduce .drain callback for jobs

[Paolo Bonzini]

- Original Message -
> From: "Vladimir Sementsov-Ogievskiy" 
> To: "Paolo Bonzini" , qemu-devel@nongnu.org
> Cc: kw...@redhat.com, f...@redhat.com, stefa...@redhat.com
> Sent: Friday, December 2, 2016 3:01:30 PM
> Subject: Re: [Qemu-devel] [PATCH 02/20] blockjob: introduce .drain callback 
> for jobs
> 
> 27.10.2016 13:48, Paolo Bonzini wrote:
> > This is required to decouple block jobs from running in an
> > AioContext.  With multiqueue block devices, a BlockDriverState
> > does not really belong to a single AioContext.
> >
> > The solution is to first wait until all I/O operations are
> > complete; then loop in the main thread for the block job to
> > complete entirely.
>
> Looks like I have a problem with this. block_job_drain enters the job
> only if job.busy = false. But what if job yielded with busy = true?
> 
> My case is the following: in the job I call co_aio_sleep_ns() for some
> time without setting job.busy to false, and it looks like timer doesn't
> work while we are in "while() { block_job_drain() }" loop. If I just set
> "job.busy = false" and "job.busy = true" around co_aio_sleep_ns() all
> start to work.
> 
> I don't want set job.busy to false, because actually job is working -
> several additional coroutines do their work, only the main one (job.co)
> do nothing. I can remove timer, and make other coroutines wake up the
> main one when it needed, and, anyway it looks like better way..
> 
> But the question is: is it ok, that we can't use sleep timer in the job,
> without setting busy = true? Is it right that only io can wake up block
> job coroutine, if it yielded without setting busy=false?

That's more or less correct.  See for example mirror.c.  Whenever it yields
with busy=false, mirror_write_complete will wake the coroutine.

Note that it's also okay to use co_aio_sleep_ns if I/O and _also_ wake the
coroutine on I/O.  Reentering a coroutine automatically interrupts the sleep.

Paolo

> > +while (!job->deferred_to_main_loop && !job->completed) {
> > +block_job_drain(job);
> > +}
> >   while (!job->completed) {
> > -aio_poll(block_job_get_aio_context(job), true);
> > +aio_poll(qemu_get_aio_context(), true);
> >   }
> >   ret = (job->cancelled && job->ret == 0) ? -ECANCELED : job->ret;
> >   block_job_unref(job);
> >
> 
> 
> --
> Best regards,
> Vladimir
> 
> 

Re: [Qemu-devel] New wiki page: http://wiki.qemu.org/Hosts

[Thomas Huth]

On 02.12.2016 23:59, Programmingkid wrote:
> I thought we could use a Hosts page to sort all the host documentation we 
> have. It is located here: http://wiki.qemu.org/Hosts

Since it's documentation, shouldn't this rather go to
/Documentation/Hosts instead of /Hosts ?

 Thomas

Re: [Qemu-devel] [Xen-devel] [PATCH v2 4/4] 9pfs: introduce init_out/in_iov_from_pdu

[Greg Kurz]

On Fri, 2 Dec 2016 11:02:44 -0800 (PST)
Stefano Stabellini  wrote:

> On Fri, 2 Dec 2016, Greg Kurz wrote:
> > On Mon, 28 Nov 2016 13:27:24 -0800
> > Stefano Stabellini  wrote:
> >   
> > > Not all 9pfs transports share memory between request and response. For
> > > those who don't, it is necessary to know how much memory is required in
> > > the response.
> > > 
> > > Split the existing init_iov_from_pdu function in two:
> > > init_out_iov_from_pdu (for writes) and init_in_iov_from_pdu (for reads).
> > > init_in_iov_from_pdu takes an additional size parameter to specify the
> > > memory required for the response message.
> > > 
> > > Signed-off-by: Stefano Stabellini 
> > > ---  
> > 
> > Reviewed-by: Greg Kurz   
> 
> Thanks Greg! I assume you are going to apply them to your tree, right?
> 

Done.

https://github.com/gkurz/qemu/commits/9p-next

Cheers.

--
Greg

> Thanks again,
> 
> Stefano
> 
> 
> > >  hw/9pfs/9p.c   |  6 +-
> > >  hw/9pfs/9p.h   |  6 --
> > >  hw/9pfs/virtio-9p-device.c | 28 ++--
> > >  3 files changed, 27 insertions(+), 13 deletions(-)
> > > 
> > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> > > index 79d7201..ce1f9d9 100644
> > > --- a/hw/9pfs/9p.c
> > > +++ b/hw/9pfs/9p.c
> > > @@ -1652,7 +1652,11 @@ static void v9fs_init_qiov_from_pdu(QEMUIOVector 
> > > *qiov, V9fsPDU *pdu,
> > >  struct iovec *iov;
> > >  unsigned int niov;
> > >  
> > > -pdu->s->transport->init_iov_from_pdu(pdu, , , is_write);
> > > +if (is_write) {
> > > +pdu->s->transport->init_out_iov_from_pdu(pdu, , );
> > > +} else {
> > > +pdu->s->transport->init_in_iov_from_pdu(pdu, , , size);
> > > +}
> > >  
> > >  qemu_iovec_init_external(, iov, niov);
> > >  qemu_iovec_init(qiov, niov);
> > > diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h
> > > index c8c9aa8..4c4feaf 100644
> > > --- a/hw/9pfs/9p.h
> > > +++ b/hw/9pfs/9p.h
> > > @@ -349,8 +349,10 @@ struct V9fsTransport {
> > >  va_list ap);
> > >  ssize_t (*pdu_vunmarshal)(V9fsPDU *pdu, size_t offset, const 
> > > char *fmt,
> > >va_list ap);
> > > -void(*init_iov_from_pdu)(V9fsPDU *pdu, struct iovec **piov,
> > > - unsigned int *pniov, bool is_write);
> > > +void(*init_in_iov_from_pdu)(V9fsPDU *pdu, struct iovec 
> > > **piov,
> > > +unsigned int *pniov, size_t 
> > > size);
> > > +void(*init_out_iov_from_pdu)(V9fsPDU *pdu, struct iovec 
> > > **piov,
> > > + unsigned int *pniov);
> > >  void(*push_and_notify)(V9fsPDU *pdu);
> > >  };
> > >  
> > > diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
> > > index 273425b..27a4a32 100644
> > > --- a/hw/9pfs/virtio-9p-device.c
> > > +++ b/hw/9pfs/virtio-9p-device.c
> > > @@ -171,26 +171,34 @@ static ssize_t virtio_pdu_vunmarshal(V9fsPDU *pdu, 
> > > size_t offset,
> > >  return v9fs_iov_vunmarshal(elem->out_sg, elem->out_num, offset, 1, 
> > > fmt, ap);
> > >  }
> > >  
> > > -static void virtio_init_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov,
> > > - unsigned int *pniov, bool is_write)
> > > +/* The size parameter is used by other transports. Do not drop it. */
> > > +static void virtio_init_in_iov_from_pdu(V9fsPDU *pdu, struct iovec 
> > > **piov,
> > > +unsigned int *pniov, size_t size)
> > >  {
> > >  V9fsState *s = pdu->s;
> > >  V9fsVirtioState *v = container_of(s, V9fsVirtioState, state);
> > >  VirtQueueElement *elem = v->elems[pdu->idx];
> > >  
> > > -if (is_write) {
> > > -*piov = elem->out_sg;
> > > -*pniov = elem->out_num;
> > > -} else {
> > > -*piov = elem->in_sg;
> > > -*pniov = elem->in_num;
> > > -}
> > > +*piov = elem->in_sg;
> > > +*pniov = elem->in_num;
> > > +}
> > > +
> > > +static void virtio_init_out_iov_from_pdu(V9fsPDU *pdu, struct iovec 
> > > **piov,
> > > + unsigned int *pniov)
> > > +{
> > > +V9fsState *s = pdu->s;
> > > +V9fsVirtioState *v = container_of(s, V9fsVirtioState, state);
> > > +VirtQueueElement *elem = v->elems[pdu->idx];
> > > +
> > > +*piov = elem->out_sg;
> > > +*pniov = elem->out_num;
> > >  }
> > >  
> > >  static const struct V9fsTransport virtio_9p_transport = {
> > >  .pdu_vmarshal = virtio_pdu_vmarshal,
> > >  .pdu_vunmarshal = virtio_pdu_vunmarshal,
> > > -.init_iov_from_pdu = virtio_init_iov_from_pdu,
> > > +.init_in_iov_from_pdu = virtio_init_in_iov_from_pdu,
> > > +.init_out_iov_from_pdu = virtio_init_out_iov_from_pdu,
> > >  .push_and_notify = virtio_9p_push_and_notify,
> > >  };
> > >
> > 
> > 
> 

Re: [Qemu-devel] [RFC] target-ppc/fpu_helper.c: Use C99 code to speed up floating point unit

[Paolo Bonzini]

On 03/12/2016 06:59, Programmingkid wrote:
> The floating point code used in fpu_helper.c can be sped up by using
> the IEEE 754 support added to the C99 standard. To test this code out
> simply set and unset the I_NEED_SPEED macro. The program to test out
> each version of the helper_fmadd() function is below the patch. It
> needs to be ran in the guest. The emulator to use is qemu-system-ppc.
> I used a Mac OS X guest, but the test program would compile on a
> Linux guest.
> 
> This patch does make the fused multiply-add instruction fmadd work
> faster and still give a correct result.
> 
> This documentation might be of help to those who want to learn more
> about C99's IEEE 754 support: 
> http://grouper.ieee.org/groups/754/meeting-materials/2001-07-18-c99.pdf

You're undoing what was done in 2007:

commit 76a66253e5e48f1744f689041c1c21cedcaff630
Author: j_mayer 
Date:   Wed Mar 7 08:32:30 2007 +

Great PowerPC emulation code resynchronisation and improvments:
...
- Micro-operation fixes:
...
  * use softfloat routines for all floating-point operations

Paolo

Re: [Qemu-devel] New wiki page: http://wiki.qemu.org/Hosts

[Paolo Bonzini]

On 02/12/2016 23:59, Programmingkid wrote:
> I thought we could use a Hosts page to sort all the host documentation we 
> have. It is located here: http://wiki.qemu.org/Hosts
> 
> Here is what I have so far:
> 
> AIX
> Darwin
> FreeBSD, NetBSD, OpenBSD
> Linux
> Mac OS X
> Solaris
> Windows
> 

Since this stuff changes rarely, it should be in the source tree
instead.  You can link to the source tree from the wiki with something
like this:

{{src|path=BUILDING|description=the BUILDING file in the source tree}}

Would you like to make a patch moving the information from the wiki to
such a file?

Paolo