Re: [Qemu-devel] [PATCH v2] vl.c: disallow command line fw cfg without opt/

2016-03-18 Thread Laszlo Ersek
On 03/16/16 19:43, Michael S. Tsirkin wrote:
> On Wed, Mar 16, 2016 at 07:35:09PM +0100, Laszlo Ersek wrote:
>> On 03/16/16 19:15, Gabriel L. Somlo wrote:
>>> On Wed, 16 Mar 2016 at 18:50:57 +0200, Michael S. Tsirkin wrote:
 On Wed, Mar 16, 2016 at 05:29:45PM +0100, Markus Armbruster wrote:
> "Michael S. Tsirkin"  writes:
>
>> Allowing arbitary file names on command line is setting us up for
>> failure: future guests will look for a specific QEMU-specified name and
>> will get confused finding a user file there.
>>
>> We do warn but people are conditioned to ignore warnings by now,
>> so at best that will help users debug problem, not avoid it.
>>
>> Disable this by default, so distros don't get to deal with it,
>> but leave an option for developers to configure this in,
>> with scary warnings so people only do it if they know
>> what they are doing.
>>
>> Signed-off-by: Michael S. Tsirkin 
>
> I'm having a hard time to see the point.

 Frankly, I am having a hard time to see the point of exposing fw cfg to
 users at all.  It was designed as an internal interface between QEMU PC
 hardware and firmware.  As a PC maintainer, I do not like it that users
 get to poke at PC internals.

 So it is yet another way to pass binaries to Linux guests.  Don't we
 have enough of these?  But Gerd likes it for some reason, and merged it.
 OK.
>>>
>>> As the author of the feature, I feel I should jump back in and clarify:
>>>
>>> It's a way to pass arbitrary blobs to any type of guest, with two
>>> important properties: 1. asynchronous, and 2. out-of-band. When I
>>> started looking, all existing methods involved either having the host
>>> start polling for the guest to bring up qga and be ready to accept an
>>> out-of-band connection (i.e., *not* asynchronous), or have the guest
>>> mount some special cdrom or floppy image prepared by the host (i.e.,
>>> *not* out of band).
>>>
>>> fw_cfg is both asynchronous and out-of-band, so it appeared to be the
>>> perfect choice.
>>>
 But please find a way to make sure it does not conflict with its current
 usage in PC.  Asking that all files have an "opt/" prefix is one way
 but only if it is enforced.
>>>
>>> Enforcing the "opt/" prefix was clearly on the table when I submitted
>>> the feature (and totally acceptable for my own needs). At the time, however,
>>> most of the advice I received on the list was to leave it as a warning
>>> only (i.e., "mechanism, not policy"), especially since other respondents
>>> expressed interest in passing in non-"/opt" blobs for easier development
>>> and debugging of alternative firmware (such as OVMF, iirc).
>>>
>>> Having a mis-use of this feature become "institutionalized" over time was
>>> seen as a low/negligible risk at the time. Do we have any new reasons
>>> to worry about it ?
>>
>> OVMF uses this feature for a few flags. They are all called
>> "opt/ovmf/...". I followed the advice in "docs/specs/fw_cfg.txt" (which
>> shouldn't be surprising since I seem to have reviewed every patch for
>> that file):
>>
>>> NOTE: Users *SHOULD* choose item names beginning with the prefix "opt/"
>>> when using the "-fw_cfg" command line option, to avoid conflicting with
>>> item names used internally by QEMU. For instance:
>>>
>>> -fw_cfg name=opt/my_item_name,file=./my_blob.bin
>>>
>>> Similarly, QEMU developers *SHOULD NOT* use item names prefixed with
>>> "opt/" when inserting items programmatically, e.g. via fw_cfg_add_file().
>>
>> It says "should", not "must".
> 
> should means "might be ok".

Yes, if there is a pressing reason. And even then, "you have been warned".

> So change it to must then?

I didn't suggest that.

(For consistency, your patch should be attempting to modify the code and
the docs together -- but this doesn't mean that I agree with the patch.)

>> I liked (and like) the "mechanism, not
>> policy" thing. Letting developers pass in whatever they want, for
>> development / debugging / testing purposes, is a plus to me.
>>
>> Thanks
>> Laszlo
> 
> Could you flesh out the development / debugging / testing and
> how is inserting files in PC namespace useful for that?

I don't know -- which is part of the argument. Lack of a ready example
doesn't imply (to me) that the possibility should be excluded.

As Paolo said, I believe we've been through this discussion. I have no
new arguments; the old ones are valid to me still. I won't try to
influence this discussion any further; I only chimed in because OVMF was
mentioned (and because I noticed that the docs would get out of sync
with the code).

Thanks
Laszlo




[Qemu-devel] [PULL v2 11/13] crypto: wire up XTS mode for cipher APIs

2016-03-18 Thread Daniel P. Berrange
Introduce 'XTS' as a permitted mode for the cipher APIs.
With XTS the key provided must be twice the size of the
key normally required for any given algorithm. This is
because the key will be split into two pieces for use
in XTS mode.

Reviewed-by: Eric Blake 
Signed-off-by: Daniel P. Berrange 
---
 crypto/cipher-builtin.c|  85 +---
 crypto/cipher-gcrypt.c | 123 -
 crypto/cipher-nettle.c |  79 --
 crypto/cipher.c|  27 +++--
 qapi/crypto.json   |   3 +-
 tests/test-crypto-cipher.c | 134 -
 6 files changed, 405 insertions(+), 46 deletions(-)

diff --git a/crypto/cipher-builtin.c b/crypto/cipher-builtin.c
index 836ed1a..88963f6 100644
--- a/crypto/cipher-builtin.c
+++ b/crypto/cipher-builtin.c
@@ -21,6 +21,7 @@
 #include "qemu/osdep.h"
 #include "crypto/aes.h"
 #include "crypto/desrfb.h"
+#include "crypto/xts.h"
 
 typedef struct QCryptoCipherBuiltinAESContext QCryptoCipherBuiltinAESContext;
 struct QCryptoCipherBuiltinAESContext {
@@ -30,6 +31,7 @@ struct QCryptoCipherBuiltinAESContext {
 typedef struct QCryptoCipherBuiltinAES QCryptoCipherBuiltinAES;
 struct QCryptoCipherBuiltinAES {
 QCryptoCipherBuiltinAESContext key;
+QCryptoCipherBuiltinAESContext key_tweak;
 uint8_t iv[AES_BLOCK_SIZE];
 };
 typedef struct QCryptoCipherBuiltinDESRFB QCryptoCipherBuiltinDESRFB;
@@ -123,6 +125,30 @@ static void qcrypto_cipher_aes_ecb_decrypt(AES_KEY *key,
 }
 
 
+static void qcrypto_cipher_aes_xts_encrypt(const void *ctx,
+   size_t length,
+   uint8_t *dst,
+   const uint8_t *src)
+{
+const QCryptoCipherBuiltinAESContext *aesctx = ctx;
+
+qcrypto_cipher_aes_ecb_encrypt((AES_KEY *)&aesctx->enc,
+   src, dst, length);
+}
+
+
+static void qcrypto_cipher_aes_xts_decrypt(const void *ctx,
+   size_t length,
+   uint8_t *dst,
+   const uint8_t *src)
+{
+const QCryptoCipherBuiltinAESContext *aesctx = ctx;
+
+qcrypto_cipher_aes_ecb_decrypt((AES_KEY *)&aesctx->dec,
+   src, dst, length);
+}
+
+
 static int qcrypto_cipher_encrypt_aes(QCryptoCipher *cipher,
   const void *in,
   void *out,
@@ -141,6 +167,14 @@ static int qcrypto_cipher_encrypt_aes(QCryptoCipher 
*cipher,
 &ctxt->state.aes.key.enc,
 ctxt->state.aes.iv, 1);
 break;
+case QCRYPTO_CIPHER_MODE_XTS:
+xts_encrypt(&ctxt->state.aes.key,
+&ctxt->state.aes.key_tweak,
+qcrypto_cipher_aes_xts_encrypt,
+qcrypto_cipher_aes_xts_decrypt,
+ctxt->state.aes.iv,
+len, out, in);
+break;
 default:
 g_assert_not_reached();
 }
@@ -167,6 +201,14 @@ static int qcrypto_cipher_decrypt_aes(QCryptoCipher 
*cipher,
 &ctxt->state.aes.key.dec,
 ctxt->state.aes.iv, 0);
 break;
+case QCRYPTO_CIPHER_MODE_XTS:
+xts_decrypt(&ctxt->state.aes.key,
+&ctxt->state.aes.key_tweak,
+qcrypto_cipher_aes_xts_encrypt,
+qcrypto_cipher_aes_xts_decrypt,
+ctxt->state.aes.iv,
+len, out, in);
+break;
 default:
 g_assert_not_reached();
 }
@@ -200,21 +242,46 @@ static int qcrypto_cipher_init_aes(QCryptoCipher *cipher,
 QCryptoCipherBuiltin *ctxt;
 
 if (cipher->mode != QCRYPTO_CIPHER_MODE_CBC &&
-cipher->mode != QCRYPTO_CIPHER_MODE_ECB) {
+cipher->mode != QCRYPTO_CIPHER_MODE_ECB &&
+cipher->mode != QCRYPTO_CIPHER_MODE_XTS) {
 error_setg(errp, "Unsupported cipher mode %d", cipher->mode);
 return -1;
 }
 
 ctxt = g_new0(QCryptoCipherBuiltin, 1);
 
-if (AES_set_encrypt_key(key, nkey * 8, &ctxt->state.aes.key.enc) != 0) {
-error_setg(errp, "Failed to set encryption key");
-goto error;
-}
+if (cipher->mode == QCRYPTO_CIPHER_MODE_XTS) {
+if (AES_set_encrypt_key(key, nkey * 4, &ctxt->state.aes.key.enc) != 0) 
{
+error_setg(errp, "Failed to set encryption key");
+goto error;
+}
 
-if (AES_set_decrypt_key(key, nkey * 8, &ctxt->state.aes.key.dec) != 0) {
-error_setg(errp, "Failed to set decryption key");
-goto error;
+if (AES_set_decrypt_key(key, nkey * 4, &ctxt->state.aes.key.dec) != 0) 
{
+error_setg(errp, "Failed to set decryption key");
+goto error;
+}
+
+if (AES_set_encrypt_key(key + (nkey / 2), nkey * 

Re: [Qemu-devel] [PATCH 2/3] hw/net/spapr_llan: Fix receive buffer handling for better performance

2016-03-18 Thread David Gibson
On Thu, Mar 17, 2016 at 08:30:15AM +0100, Thomas Huth wrote:
> On 17.03.2016 07:23, David Gibson wrote:
> > On Wed, Mar 16, 2016 at 01:16:50PM +0100, Thomas Huth wrote:
> >>
> >> This patch introduces an alternate way of handling the receive
> >> buffers of the spapr-vlan device, resulting in much better
> >> receive performance for the guest.
> [...]
> >> Though it seems at a first glance like PAPR says that we should store
> >> the receive buffer descriptors in the page that is supplied during
> >> the H_REGISTER_LOGICAL_LAN call, chapter 16.4.1.2 in the LoPAPR spec
> >> declares that "the contents of these descriptors are architecturally
> >> opaque, none of these descriptors are manipulated by code above
> >> the architected interfaces".
> > 
> > Aaaahhh!  I remember back when I first implemented this, that exposing
> > the pool of buffer descriptors via DMA seemed a silly and pointless
> > thing to do, but I did so because I thought that's what the spec said.
> > 
> > 16.4.1.2 seems to make it clearer that the page doesn't list actual Rx
> > buffers, but rather opaque handles on internal buffer pools.
> > 
> > I don't know if I just misread this back in 2011 (or whenever it was)
> > or if the PAPR wording at the time was less clear at the time.
> > 
> > I note that you don't actually put the buffer pool pointers into that
> > page in your patch below.  I don't think that matters now, but I
> > wonder if we'd ever want to implement H_MIGRATE_DMA and if we'd need
> > it in that case.
> 
> I also thought about putting the pointers to the pools into that page.
> But: If we put buffer pool pointers into that page, where should the
> buffer pools be located? Still in the memory of the hypervisor? Then
> this sounds like a very baaad design, the guest then could tinker with
> pointers to the host memory, causing very bad side effects or crashes.
> Or should the buffer pools be located in guest memory? That might be OK,
> but how do the pools get allocated in that case?
> 
> So unless you've got a good idea here, I think it's better to keep the
> pointer list and the buffer pools both in host memory for now.

Yes, I think you're right.

> [...]
> >> +/**
> >> + * Enqueuing receive buffer by adding it to one of our receive buffer 
> >> pools
> >> + */
> >> +static target_long spapr_vlan_add_rxbuf_to_pool(VIOsPAPRVLANDevice *dev,
> >> +target_ulong buf)
> >> +{
> >> +int size = VLAN_BD_LEN(buf);
> >> +int pool;
> >> +
> >> +pool = spapr_vlan_get_rx_pool_id(dev, size);
> >> +
> >> +/* No matching pool found? Try to create a new one */
> >> +if (pool < 0) {
> >> +for (pool = RX_MAX_POOLS - 1; pool >= 0 ; pool--) {
> > 
> > I don't think this loop actually accomplishes anything.  Either the
> > last slot is free, in which case you use it, then sort into place, or
> > it's not, in which case you've hit the maximum number of buffer pools.
> 
> Oh, you're right. Well spotted! I'll rework my patch to do it without
> that loop.
> 
>  Thomas
> 
> 



-- 
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] [PATCH v4 07/11] block: m25p80: Dummy cycles for N25Q256/512

2016-03-18 Thread Peter Crosthwaite
On Mon, Feb 22, 2016 at 12:03 AM,   wrote:
> From: Marcin Krzeminski 
>
> This patch handles dummy cycles.
>

More commit message needed:

"Use the setting in the volatile cfg register to correctly set the
number of dummy bytes"

> Signed-off-by: Marcin Krzeminski 
> ---
>  hw/block/m25p80.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
> index 9d5a071..aff28f3 100644
> --- a/hw/block/m25p80.c
> +++ b/hw/block/m25p80.c
> @@ -566,6 +566,10 @@ static void decode_new_cmd(Flash *s, uint32_t value)
>  case DOR:
>  case QOR:
>  s->needed_bytes = get_addr_length(s);
> +if (((s->pi->jedec >> 16) & 0xFF) == JEDEC_NUMONYX) {
> +/* Dummy cycles modeled with bytes writes instead of bits */
> +s->needed_bytes += extract32(s->volatile_cfg, 4, 4);
> +}
>  s->pos = 0;
>  s->len = 0;
>  s->state = STATE_COLLECTING_DATA;
> @@ -579,6 +583,8 @@ static void decode_new_cmd(Flash *s, uint32_t value)
>  break;
>  case JEDEC_NUMONYX:
>  s->needed_bytes = get_addr_length(s);
> +/* Dummy cycles modeled with bytes writes instead of bits */
> +s->needed_bytes += extract32(s->volatile_cfg, 4, 4);
>  break;
>  default:
>  s->needed_bytes = 5;

Following on from before, these defaults are NUMONYX policy based, so
I think your patch is to the default.

Otherwise: Reviewed-by: Peter Crosthwaite 

Regards,
Peter

> @@ -596,6 +602,8 @@ static void decode_new_cmd(Flash *s, uint32_t value)
>  break;
>  case JEDEC_NUMONYX:
>  s->needed_bytes = get_addr_length(s);
> +/* Dummy cycles modeled with bytes writes instead of bits */
> +s->needed_bytes += extract32(s->volatile_cfg, 4, 4);
>  break;
>  default:
>  s->needed_bytes = 8;
> --
> 2.5.0
>



[Qemu-devel] [PATCH 21/49] arm: include cpu-qom.h in files that require ARMCPU

2016-03-18 Thread Paolo Bonzini
Signed-off-by: Paolo Bonzini 
---
 hw/arm/stm32f205_soc.c  | 1 -
 hw/arm/strongarm.h  | 1 +
 include/hw/arm/arm.h| 2 +-
 include/hw/arm/exynos4210.h | 1 +
 include/hw/arm/omap.h   | 1 +
 include/hw/arm/pxa.h| 1 +
 6 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/hw/arm/stm32f205_soc.c b/hw/arm/stm32f205_soc.c
index a5ea1e2..9c1dafb 100644
--- a/hw/arm/stm32f205_soc.c
+++ b/hw/arm/stm32f205_soc.c
@@ -25,7 +25,6 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
 #include "qemu-common.h"
-#include "cpu.h"
 #include "hw/arm/arm.h"
 #include "exec/address-spaces.h"
 #include "hw/arm/stm32f205_soc.h"
diff --git a/hw/arm/strongarm.h b/hw/arm/strongarm.h
index 2893f94..cd32bbd 100644
--- a/hw/arm/strongarm.h
+++ b/hw/arm/strongarm.h
@@ -2,6 +2,7 @@
 #define _STRONGARM_H
 
 #include "exec/memory.h"
+#include "target-arm/cpu-qom.h"
 
 #define SA_CS0  0x
 #define SA_CS1  0x0800
diff --git a/include/hw/arm/arm.h b/include/hw/arm/arm.h
index b2517f9..8b49a98 100644
--- a/include/hw/arm/arm.h
+++ b/include/hw/arm/arm.h
@@ -12,9 +12,9 @@
 #define ARM_MISC_H 1
 
 #include "exec/memory.h"
+#include "target-arm/cpu-qom.h"
 #include "hw/irq.h"
 #include "qemu/notify.h"
-#include "cpu.h"
 
 typedef enum {
 ARM_ENDIANNESS_UNKNOWN = 0,
diff --git a/include/hw/arm/exynos4210.h b/include/hw/arm/exynos4210.h
index 5c1820f..b6d929d 100644
--- a/include/hw/arm/exynos4210.h
+++ b/include/hw/arm/exynos4210.h
@@ -28,6 +28,7 @@
 
 #include "qemu-common.h"
 #include "exec/memory.h"
+#include "target-arm/cpu-qom.h"
 
 #define EXYNOS4210_NCPUS2
 
diff --git a/include/hw/arm/omap.h b/include/hw/arm/omap.h
index 0ad5fb8..f026c8d 100644
--- a/include/hw/arm/omap.h
+++ b/include/hw/arm/omap.h
@@ -20,6 +20,7 @@
 #include "exec/memory.h"
 # define hw_omap_h "omap.h"
 #include "hw/irq.h"
+#include "target-arm/cpu-qom.h"
 
 # define OMAP_EMIFS_BASE   0x
 # define OMAP2_Q0_BASE 0x
diff --git a/include/hw/arm/pxa.h b/include/hw/arm/pxa.h
index 259b852..074feac 100644
--- a/include/hw/arm/pxa.h
+++ b/include/hw/arm/pxa.h
@@ -10,6 +10,7 @@
 # define PXA_H "pxa.h"
 
 #include "exec/memory.h"
+#include "target-arm/cpu-qom.h"
 
 /* Interrupt numbers */
 # define PXA2XX_PIC_SSP3   0
-- 
1.8.3.1





Re: [Qemu-devel] [PATCH v12 8/9] hw/ptimer: Perform delayed tick instead of immediate if delta = 0

2016-03-18 Thread Dmitry Osipenko

09.03.2016 00:08, Peter Crosthwaite пишет:

On Sat, Jan 30, 2016 at 8:43 AM, Dmitry Osipenko  wrote:

It might be necessary by some emulated HW to perform the tick after one
period if delta = 0. Given that it is much less churny to implement immediate
tick by the ptimer user itself, let's make ptimer do the delayed tick.



Isn't this related to previous patch? It is kind of a rounding problem


Ah, you probably meant "Legalize running with delta = load = 0 and abort on 
period = 0" patch. Yes, they could be squashed.


I chose wrong policy at first time, further added MPtimer tests revealed it.

--
Dmitry



Re: [Qemu-devel] [PATCH 2/3] hw/net/spapr_llan: Fix receive buffer handling for better performance

2016-03-18 Thread Thomas Huth
On 17.03.2016 23:33, David Gibson wrote:
> On Thu, Mar 17, 2016 at 04:15:38PM +0100, Thomas Huth wrote:
>> On 17.03.2016 08:30, Thomas Huth wrote:
>>> On 17.03.2016 07:23, David Gibson wrote:
 On Wed, Mar 16, 2016 at 01:16:50PM +0100, Thomas Huth wrote:
>
> This patch introduces an alternate way of handling the receive
> buffers of the spapr-vlan device, resulting in much better
> receive performance for the guest.
>> [...]
> +/**
> + * Enqueuing receive buffer by adding it to one of our receive buffer 
> pools
> + */
> +static target_long spapr_vlan_add_rxbuf_to_pool(VIOsPAPRVLANDevice *dev,
> +target_ulong buf)
> +{
> +int size = VLAN_BD_LEN(buf);
> +int pool;
> +
> +pool = spapr_vlan_get_rx_pool_id(dev, size);
> +
> +/* No matching pool found? Try to create a new one */
> +if (pool < 0) {
> +for (pool = RX_MAX_POOLS - 1; pool >= 0 ; pool--) {

 I don't think this loop actually accomplishes anything.  Either the
 last slot is free, in which case you use it, then sort into place, or
 it's not, in which case you've hit the maximum number of buffer pools.
>>>
>>> Oh, you're right. Well spotted! I'll rework my patch to do it without
>>> that loop.
>>
>> Wait, no, there was a case where this loop is actually really required:
>>
>> 1) All pools are in use and filled with at least one BD
>> 2) User in the guest suddenly decides to change the buffer size of
>>one of the pools in the /sys fs of the guest.
>> 3) Guest driver tries to add buffers with a new size that do not
>>match any size of one of the pools in the host
>> 4) After the pool on the host runs empty which contained the BDs with
>>the size that is not in use anymore, we should recycle that pool
>>for the buffers with the new size instead. Since that buffer pool
>>might not be at the end of the list, we've got to scan all buffers
>>here to make sure we find it.
>>
>> So I think the for-loop should stay as it is.
> 
> Ah, good point.  I think I was assuming that the pools got sorted when
> one was emptied as well, but they're not and I suspect it's not a good
> idea to do so.
> 
> Hmm.. I wonder if there's a brief way of explaining the above to put
> in the comment.

Something like:

/*
 * If the guest used all pools, but changed the size of one pool
 * inbetween, we might need to recycle that pool here (if it has
 * already been emptied). Thus we need to scan all buffer pools
 * here, not only the last one (which has the highest probability
 * of being empty)
 */

?

Or is that too verbose already?

 Thomas




signature.asc
Description: OpenPGP digital signature


[Qemu-devel] [PATCH] block/sheepdog: add error handling to sd_snapshot_delete()

2016-03-18 Thread Takashi Menjo
Errors have been ignored in some code paths in sd_snapshot_delete().
This patch adds error handling.

Signed-off-by: Takashi Menjo 
---
 block/sheepdog.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/block/sheepdog.c b/block/sheepdog.c
index a3aeae4..6492405 100644
--- a/block/sheepdog.c
+++ b/block/sheepdog.c
@@ -2565,6 +2565,7 @@ static int sd_snapshot_delete(BlockDriverState *bs,
 SheepdogVdiRsp *rsp = (SheepdogVdiRsp *)&hdr;
 
 if (!remove_objects(s)) {
+error_report("failed to discard snapshot inode");
 return -1;
 }
 
@@ -2588,6 +2589,7 @@ static int sd_snapshot_delete(BlockDriverState *bs,
 ret = find_vdi_name(s, s->name, snap_id, snap_tag, &vid, true,
 &local_err);
 if (ret) {
+error_report_err(local_err);
 return ret;
 }
 
@@ -2601,6 +2603,7 @@ static int sd_snapshot_delete(BlockDriverState *bs,
  buf, &wlen, &rlen);
 closesocket(fd);
 if (ret) {
+error_setg_errno(errp, -ret, "failed to delete %s", s->name);
 return ret;
 }
 
-- 
2.7.4.windows.1






[Qemu-devel] [PULL v3 09/13] crypto: import an implementation of the XTS cipher mode

2016-03-18 Thread Daniel P. Berrange
The XTS (XEX with tweaked-codebook and ciphertext stealing)
cipher mode is commonly used in full disk encryption. There
is unfortunately no implementation of it in either libgcrypt
or nettle, so we need to provide our own.

The libtomcrypt project provides a repository of crypto
algorithms under a choice of either "public domain" or
the "what the fuck public license".

So this impl is taken from the libtomcrypt GIT repo and
adapted to be compatible with the way we need to call
ciphers provided by nettle/gcrypt.

Reviewed-by: Eric Blake 
Signed-off-by: Daniel P. Berrange 
---
 crypto/Makefile.objs|   1 +
 crypto/xts.c| 230 ++
 include/crypto/xts.h|  86 ++
 tests/.gitignore|   1 +
 tests/Makefile  |   2 +
 tests/test-crypto-xts.c | 423 
 6 files changed, 743 insertions(+)
 create mode 100644 crypto/xts.c
 create mode 100644 include/crypto/xts.h
 create mode 100644 tests/test-crypto-xts.c

diff --git a/crypto/Makefile.objs b/crypto/Makefile.objs
index 454f9db..e6590dc 100644
--- a/crypto/Makefile.objs
+++ b/crypto/Makefile.objs
@@ -18,6 +18,7 @@ crypto-obj-y += ivgen-essiv.o
 crypto-obj-y += ivgen-plain.o
 crypto-obj-y += ivgen-plain64.o
 crypto-obj-y += afsplit.o
+crypto-obj-y += xts.o
 
 # Let the userspace emulators avoid linking gnutls/etc
 crypto-aes-obj-y = aes.o
diff --git a/crypto/xts.c b/crypto/xts.c
new file mode 100644
index 000..9521234
--- /dev/null
+++ b/crypto/xts.c
@@ -0,0 +1,230 @@
+/*
+ * QEMU Crypto XTS cipher mode
+ *
+ * Copyright (c) 2015-2016 Red Hat, Inc.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ *
+ * This code is originally derived from public domain / WTFPL code in
+ * LibTomCrypt crytographic library http://libtom.org. The XTS code
+ * was donated by Elliptic Semiconductor Inc (www.ellipticsemi.com)
+ * to the LibTom Projects
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "crypto/xts.h"
+
+static void xts_mult_x(uint8_t *I)
+{
+int x;
+uint8_t t, tt;
+
+for (x = t = 0; x < 16; x++) {
+tt = I[x] >> 7;
+I[x] = ((I[x] << 1) | t) & 0xFF;
+t = tt;
+}
+if (tt) {
+I[0] ^= 0x87;
+}
+}
+
+
+/**
+ * xts_tweak_uncrypt:
+ * @param ctxt: the cipher context
+ * @param func: the cipher function
+ * @src: buffer providing the cipher text of XTS_BLOCK_SIZE bytes
+ * @dst: buffer to output the plain text of XTS_BLOCK_SIZE bytes
+ * @iv: the initialization vector tweak of XTS_BLOCK_SIZE bytes
+ *
+ * Decrypt data with a tweak
+ */
+static void xts_tweak_decrypt(const void *ctx,
+  xts_cipher_func *func,
+  const uint8_t *src,
+  uint8_t *dst,
+  uint8_t *iv)
+{
+unsigned long x;
+
+/* tweak encrypt block i */
+for (x = 0; x < XTS_BLOCK_SIZE; x++) {
+dst[x] = src[x] ^ iv[x];
+}
+
+func(ctx, XTS_BLOCK_SIZE, dst, dst);
+
+for (x = 0; x < XTS_BLOCK_SIZE; x++) {
+dst[x] = dst[x] ^ iv[x];
+}
+
+/* LFSR the tweak */
+xts_mult_x(iv);
+}
+
+
+void xts_decrypt(const void *datactx,
+ const void *tweakctx,
+ xts_cipher_func *encfunc,
+ xts_cipher_func *decfunc,
+ uint8_t *iv,
+ size_t length,
+ uint8_t *dst,
+ const uint8_t *src)
+{
+uint8_t PP[XTS_BLOCK_SIZE], CC[XTS_BLOCK_SIZE], T[XTS_BLOCK_SIZE];
+unsigned long i, m, mo, lim;
+
+/* get number of blocks */
+m = length >> 4;
+mo = length & 15;
+
+/* must have at least one full block */
+g_assert(m != 0);
+
+if (mo == 0) {
+lim = m;
+} else {
+lim = m - 1;
+}
+
+/* encrypt the iv */
+encfunc(tweakctx, XTS_BLOCK_SIZE, T, iv);
+
+for (i = 0; i < lim; i++) {
+xts_tweak_decrypt(datactx, decfunc, src, dst, T);
+
+src += XTS_BLOCK_SIZE;
+dst += XTS_BLOCK_SIZE;
+}
+
+/* if length is not a multiple of XTS_BLOCK_SIZE then */
+if (mo > 0) {
+memcpy(CC, T, XTS_BLOCK_SIZE);
+xts_mult_x(CC);
+
+/* PP = tweak decrypt block m-1 */
+xts_tweak_decrypt(datactx, decfunc, src, PP, CC);
+
+/* Pm = first length % XTS_BLOCK_SIZE bytes of PP */
+for (i = 0; i < mo;

[Qemu-devel] [PULL 03/21] target-arm: Fix translation level on early translation faults

2016-03-18 Thread Peter Maydell
From: Sergey Sorokin 

Qemu reports translation fault on 1st level instead of 0th level in case of
AArch64 address translation if the translation table walk is disabled or
the address is in the gap between the two regions.

Signed-off-by: Sergey Sorokin 
Message-id: 1457527503-25958-1-git-send-email-afaral...@yandex.ru
Reviewed-by: Peter Maydell 
Signed-off-by: Peter Maydell 
---
 target-arm/helper.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index eaded41..19d5d52 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -7237,7 +7237,7 @@ static bool get_phys_addr_lpae(CPUARMState *env, 
target_ulong address,
 CPUState *cs = CPU(cpu);
 /* Read an LPAE long-descriptor translation table. */
 MMUFaultType fault_type = translation_fault;
-uint32_t level = 1;
+uint32_t level;
 uint32_t epd = 0;
 int32_t t0sz, t1sz;
 uint32_t tg;
@@ -7248,7 +7248,7 @@ static bool get_phys_addr_lpae(CPUARMState *env, 
target_ulong address,
 target_ulong page_size;
 uint32_t attrs;
 int32_t stride = 9;
-int32_t va_size = 32;
+int32_t va_size;
 int inputsize;
 int32_t tbi = 0;
 TCR *tcr = regime_tcr(env, mmu_idx);
@@ -7264,6 +7264,7 @@ static bool get_phys_addr_lpae(CPUARMState *env, 
target_ulong address,
  * support for those page table walks.
  */
 if (arm_el_is_aa64(env, el)) {
+level = 0;
 va_size = 64;
 if (el > 1) {
 if (mmu_idx != ARMMMUIdx_S2NS) {
@@ -7285,6 +7286,8 @@ static bool get_phys_addr_lpae(CPUARMState *env, 
target_ulong address,
 ttbr1_valid = false;
 }
 } else {
+level = 1;
+va_size = 32;
 /* There is no TTBR1 for EL2 */
 if (el == 2) {
 ttbr1_valid = false;
@@ -7407,27 +7410,26 @@ static bool get_phys_addr_lpae(CPUARMState *env, 
target_ulong address,
 /* For stage 2 translations the starting level is specified by the
  * VTCR_EL2.SL0 field (whose interpretation depends on the page size)
  */
-int startlevel = extract32(tcr->raw_tcr, 6, 2);
+uint32_t sl0 = extract32(tcr->raw_tcr, 6, 2);
+uint32_t startlevel;
 bool ok;
 
 if (va_size == 32 || stride == 9) {
 /* AArch32 or 4KB pages */
-level = 2 - startlevel;
+startlevel = 2 - sl0;
 } else {
 /* 16KB or 64KB pages */
-level = 3 - startlevel;
+startlevel = 3 - sl0;
 }
 
 /* Check that the starting level is valid. */
-ok = check_s2_mmu_setup(cpu, va_size == 64, level, inputsize, stride);
+ok = check_s2_mmu_setup(cpu, va_size == 64, startlevel,
+inputsize, stride);
 if (!ok) {
-/* AArch64 reports these as level 0 faults.
- * AArch32 reports these as level 1 faults.
- */
-level = va_size == 64 ? 0 : 1;
 fault_type = translation_fault;
 goto do_fault;
 }
+level = startlevel;
 }
 
 /* Clear the vaddr bits which aren't part of the within-region address,
-- 
1.9.1




[Qemu-devel] [PULL v3 00/13] Merge crypto code for LUKS encryption

2016-03-18 Thread Daniel P. Berrange
The following changes since commit 8c4575472494a5dfedfe05e7b58ca9ce3872ad56:

  Merge remote-tracking branch 'remotes/ehabkost/tags/machine-pull-request' 
into staging (2016-03-17 08:52:58 +)

are available in the git repository at:

  git://github.com/berrange/qemu tags/pull-qcrypto-2016-03-17-3

for you to fetch changes up to 3e308f20edfd65a21c98eb2d8079dacd47957444:

  crypto: implement the LUKS block encryption format (2016-03-17 16:50:40 +)


Merge QCrypto 2016/03/17 v3



Changed in v3:

 - Skip luks test build on OS-X correctly
 - Fix mis-matched enum types

Changed in v2:

 - Report error of RUSAGE_THREAD is not available
 - Use GetThreadTimes on Win32 instead of getrusage
 - Skip pbkdf tests on platforms lacking thread usage info

Daniel P. Berrange (13):
  crypto: add cryptographic random byte source
  crypto: add support for PBKDF2 algorithm
  crypto: add support for generating initialization vectors
  crypto: add support for anti-forensic split algorithm
  crypto: skip testing of unsupported cipher algorithms
  crypto: add support for the cast5-128 cipher algorithm
  crypto: add support for the serpent cipher algorithm
  crypto: add support for the twofish cipher algorithm
  crypto: import an implementation of the XTS cipher mode
  crypto: refactor code for dealing with AES cipher
  crypto: wire up XTS mode for cipher APIs
  crypto: add block encryption framework
  crypto: implement the LUKS block encryption format

 Makefile.objs   |2 +-
 configure   |   32 ++
 crypto/Makefile.objs|   17 +
 crypto/afsplit.c|  158 +
 crypto/block-luks.c | 1328 +++
 crypto/block-luks.h |   28 +
 crypto/block-qcow.c |  173 ++
 crypto/block-qcow.h |   28 +
 crypto/block.c  |  260 +
 crypto/blockpriv.h  |   92 +++
 crypto/cipher-builtin.c |  207 +--
 crypto/cipher-gcrypt.c  |  171 +-
 crypto/cipher-nettle.c  |  197 ++-
 crypto/cipher.c |   41 +-
 crypto/ivgen-essiv.c|  118 
 crypto/ivgen-essiv.h|   28 +
 crypto/ivgen-plain.c|   59 ++
 crypto/ivgen-plain.h|   28 +
 crypto/ivgen-plain64.c  |   59 ++
 crypto/ivgen-plain64.h  |   28 +
 crypto/ivgen.c  |   99 
 crypto/ivgenpriv.h  |   49 ++
 crypto/pbkdf-gcrypt.c   |   68 +++
 crypto/pbkdf-nettle.c   |   65 +++
 crypto/pbkdf-stub.c |   42 ++
 crypto/pbkdf.c  |  109 
 crypto/random-gcrypt.c  |   33 ++
 crypto/random-gnutls.c  |   43 ++
 crypto/random-stub.c|   31 +
 crypto/xts.c|  230 
 include/crypto/afsplit.h|  135 +
 include/crypto/block.h  |  232 
 include/crypto/ivgen.h  |  206 +++
 include/crypto/pbkdf.h  |  152 +
 include/crypto/random.h |   44 ++
 include/crypto/xts.h|   86 +++
 qapi/crypto.json|  146 -
 tests/.gitignore|5 +
 tests/Makefile  |   10 +
 tests/test-crypto-afsplit.c |  193 +++
 tests/test-crypto-block.c   |  362 
 tests/test-crypto-cipher.c  |  215 ++-
 tests/test-crypto-ivgen.c   |  173 ++
 tests/test-crypto-pbkdf.c   |  392 +
 tests/test-crypto-xts.c |  423 ++
 45 files changed, 6488 insertions(+), 109 deletions(-)
 create mode 100644 crypto/afsplit.c
 create mode 100644 crypto/block-luks.c
 create mode 100644 crypto/block-luks.h
 create mode 100644 crypto/block-qcow.c
 create mode 100644 crypto/block-qcow.h
 create mode 100644 crypto/block.c
 create mode 100644 crypto/blockpriv.h
 create mode 100644 crypto/ivgen-essiv.c
 create mode 100644 crypto/ivgen-essiv.h
 create mode 100644 crypto/ivgen-plain.c
 create mode 100644 crypto/ivgen-plain.h
 create mode 100644 crypto/ivgen-plain64.c
 create mode 100644 crypto/ivgen-plain64.h
 create mode 100644 crypto/ivgen.c
 create mode 100644 crypto/ivgenpriv.h
 create mode 100644 crypto/pbkdf-gcrypt.c
 create mode 100644 crypto/pbkdf-nettle.c
 create mode 100644 crypto/pbkdf-stub.c
 create mode 100644 crypto/pbkdf.c
 create mode 100644 crypto/random-gcrypt.c
 create mode 100644 crypto/random-gnutls.c
 create mode 100644 crypto/random-stub.c
 create mode 100644 crypto/xts.c
 create mode 100644 include/crypto/afsplit.h
 create mode 100644 include/crypto/block.h
 create mode 100644 include/crypto/ivgen.h
 create mode 100644 include/crypto/pbkdf.h
 create mode 100644 include/crypto/random.h
 create mode 100644 include/crypto/xts.h
 create mode 100644 tests/test-crypto-afsplit.c
 create mode 100644 tests/test-crypto-block.c
 create mode 100644 tests/test-crypto-ivgen.c
 create mode 100644 tests/test-crypto-pbkdf.c
 create mode 100644 tests/test-crypto-xts.c

-- 
2.5.0




Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it

2016-03-18 Thread Richard Henderson
On 03/15/2016 02:29 AM, Markus Armbruster wrote:
> Headers can
> be read multiple times, which can only hurt compilation time.  You need
> to make an effort to avoid cyclic dependencies and excessive inclusion.

I just want to point out that the preprocessor understands the

#ifndef FOO
#define FOO
...
#endif

idiom, where nothing but comments precedes the #ifndef in the file, and
likewise nothing succeeds the matching #endif.  If FOO is still defined at the
next #include of the file, the preprocessor will skip the #include entirely.

So don't let this be a consideration in the argument.


r~



[Qemu-devel] [PATCH v5 11/28] migration: convert post-copy to use QIOChannelBuffer

2016-03-18 Thread Daniel P. Berrange
The post-copy code does some I/O to/from an intermediate
in-memory buffer rather than direct to the underlying
I/O channel. Switch this code to use QIOChannelBuffer
instead of QEMUSizedBuffer.

Reviewed-by: Dr. David Alan Gilbert 
Signed-off-by: Daniel P. Berrange 
---
 docs/migration.txt  |  4 ++--
 include/sysemu/sysemu.h |  2 +-
 migration/migration.c   | 15 +++
 migration/savevm.c  | 47 ---
 4 files changed, 26 insertions(+), 42 deletions(-)

diff --git a/docs/migration.txt b/docs/migration.txt
index 90209ab..6503c17 100644
--- a/docs/migration.txt
+++ b/docs/migration.txt
@@ -403,8 +403,8 @@ listen thread: --- page -- page -- page 
-- page -- page --
 
 On receipt of CMD_PACKAGED (1)
All the data associated with the package - the ( ... ) section in the
-diagram - is read into memory (into a QEMUSizedBuffer), and the main thread
-recurses into qemu_loadvm_state_main to process the contents of the package (2)
+diagram - is read into memory, and the main thread recurses into
+qemu_loadvm_state_main to process the contents of the package (2)
 which contains commands (3,6) and devices (4...)
 
 On receipt of 'postcopy listen' - 3 -(i.e. the 1st command in the package)
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 3bb8897..ea488de 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -120,7 +120,7 @@ void qemu_savevm_command_send(QEMUFile *f, enum qemu_vm_cmd 
command,
   uint16_t len, uint8_t *data);
 void qemu_savevm_send_ping(QEMUFile *f, uint32_t value);
 void qemu_savevm_send_open_return_path(QEMUFile *f);
-int qemu_savevm_send_packaged(QEMUFile *f, const QEMUSizedBuffer *qsb);
+int qemu_savevm_send_packaged(QEMUFile *f, const uint8_t *buf, size_t len);
 void qemu_savevm_send_postcopy_advise(QEMUFile *f);
 void qemu_savevm_send_postcopy_listen(QEMUFile *f);
 void qemu_savevm_send_postcopy_run(QEMUFile *f);
diff --git a/migration/migration.c b/migration/migration.c
index b4a63a9..51e28b7 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -34,6 +34,7 @@
 #include "qom/cpu.h"
 #include "exec/memory.h"
 #include "exec/address-spaces.h"
+#include "io/channel-buffer.h"
 
 #define MAX_THROTTLE  (32 << 20)  /* Migration transfer speed throttling */
 
@@ -1448,7 +1449,8 @@ static int 
await_return_path_close_on_source(MigrationState *ms)
 static int postcopy_start(MigrationState *ms, bool *old_vm_running)
 {
 int ret;
-const QEMUSizedBuffer *qsb;
+QIOChannelBuffer *bioc;
+QEMUFile *fb;
 int64_t time_at_stop = qemu_clock_get_ms(QEMU_CLOCK_REALTIME);
 migrate_set_state(&ms->state, MIGRATION_STATUS_ACTIVE,
   MIGRATION_STATUS_POSTCOPY_ACTIVE);
@@ -1507,11 +1509,9 @@ static int postcopy_start(MigrationState *ms, bool 
*old_vm_running)
  * So we wrap the device state up in a package with a length at the start;
  * to do this we use a qemu_buf to hold the whole of the device state.
  */
-QEMUFile *fb = qemu_bufopen("w", NULL);
-if (!fb) {
-error_report("Failed to create buffered file");
-goto fail;
-}
+bioc = qio_channel_buffer_new(4096);
+fb = qemu_fopen_channel_output(QIO_CHANNEL(bioc));
+object_unref(OBJECT(bioc));
 
 /*
  * Make sure the receiver can get incoming pages before we send the rest
@@ -1525,10 +1525,9 @@ static int postcopy_start(MigrationState *ms, bool 
*old_vm_running)
 qemu_savevm_send_postcopy_run(fb);
 
 /* <><> end of stuff going into the package */
-qsb = qemu_buf_get(fb);
 
 /* Now send that blob */
-if (qemu_savevm_send_packaged(ms->to_dst_file, qsb)) {
+if (qemu_savevm_send_packaged(ms->to_dst_file, bioc->data, bioc->usage)) {
 goto fail_closefb;
 }
 qemu_fclose(fb);
diff --git a/migration/savevm.c b/migration/savevm.c
index 0a33c22..90a61cb 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -50,6 +50,7 @@
 #include "qemu/iov.h"
 #include "block/snapshot.h"
 #include "block/qapi.h"
+#include "io/channel-buffer.h"
 
 
 #ifndef ETH_P_RARP
@@ -760,10 +761,8 @@ void qemu_savevm_send_open_return_path(QEMUFile *f)
  *0 on success
  *-ve on error
  */
-int qemu_savevm_send_packaged(QEMUFile *f, const QEMUSizedBuffer *qsb)
+int qemu_savevm_send_packaged(QEMUFile *f, const uint8_t *buf, size_t len)
 {
-size_t cur_iov;
-size_t len = qsb_get_length(qsb);
 uint32_t tmp;
 
 if (len > MAX_VM_CMD_PACKAGED_SIZE) {
@@ -777,18 +776,7 @@ int qemu_savevm_send_packaged(QEMUFile *f, const 
QEMUSizedBuffer *qsb)
 trace_qemu_savevm_send_packaged();
 qemu_savevm_command_send(f, MIG_CMD_PACKAGED, 4, (uint8_t *)&tmp);
 
-/* all the data follows (concatinating the iov's) */
-for (cur_iov = 0; cur_iov < qsb->n_iov; cur_iov++) {
-/* The iov entries are partially filled */
-size_t towrite = MIN(qsb->iov[cur_iov].iov_len, len);
-len -= tow

[Qemu-devel] [PULL v1 11/13] crypto: wire up XTS mode for cipher APIs

2016-03-18 Thread Daniel P. Berrange
Introduce 'XTS' as a permitted mode for the cipher APIs.
With XTS the key provided must be twice the size of the
key normally required for any given algorithm. This is
because the key will be split into two pieces for use
in XTS mode.

Reviewed-by: Eric Blake 
Signed-off-by: Daniel P. Berrange 
---
 crypto/cipher-builtin.c|  85 +---
 crypto/cipher-gcrypt.c | 123 -
 crypto/cipher-nettle.c |  79 --
 crypto/cipher.c|  27 +++--
 qapi/crypto.json   |   3 +-
 tests/test-crypto-cipher.c | 134 -
 6 files changed, 405 insertions(+), 46 deletions(-)

diff --git a/crypto/cipher-builtin.c b/crypto/cipher-builtin.c
index 836ed1a..88963f6 100644
--- a/crypto/cipher-builtin.c
+++ b/crypto/cipher-builtin.c
@@ -21,6 +21,7 @@
 #include "qemu/osdep.h"
 #include "crypto/aes.h"
 #include "crypto/desrfb.h"
+#include "crypto/xts.h"
 
 typedef struct QCryptoCipherBuiltinAESContext QCryptoCipherBuiltinAESContext;
 struct QCryptoCipherBuiltinAESContext {
@@ -30,6 +31,7 @@ struct QCryptoCipherBuiltinAESContext {
 typedef struct QCryptoCipherBuiltinAES QCryptoCipherBuiltinAES;
 struct QCryptoCipherBuiltinAES {
 QCryptoCipherBuiltinAESContext key;
+QCryptoCipherBuiltinAESContext key_tweak;
 uint8_t iv[AES_BLOCK_SIZE];
 };
 typedef struct QCryptoCipherBuiltinDESRFB QCryptoCipherBuiltinDESRFB;
@@ -123,6 +125,30 @@ static void qcrypto_cipher_aes_ecb_decrypt(AES_KEY *key,
 }
 
 
+static void qcrypto_cipher_aes_xts_encrypt(const void *ctx,
+   size_t length,
+   uint8_t *dst,
+   const uint8_t *src)
+{
+const QCryptoCipherBuiltinAESContext *aesctx = ctx;
+
+qcrypto_cipher_aes_ecb_encrypt((AES_KEY *)&aesctx->enc,
+   src, dst, length);
+}
+
+
+static void qcrypto_cipher_aes_xts_decrypt(const void *ctx,
+   size_t length,
+   uint8_t *dst,
+   const uint8_t *src)
+{
+const QCryptoCipherBuiltinAESContext *aesctx = ctx;
+
+qcrypto_cipher_aes_ecb_decrypt((AES_KEY *)&aesctx->dec,
+   src, dst, length);
+}
+
+
 static int qcrypto_cipher_encrypt_aes(QCryptoCipher *cipher,
   const void *in,
   void *out,
@@ -141,6 +167,14 @@ static int qcrypto_cipher_encrypt_aes(QCryptoCipher 
*cipher,
 &ctxt->state.aes.key.enc,
 ctxt->state.aes.iv, 1);
 break;
+case QCRYPTO_CIPHER_MODE_XTS:
+xts_encrypt(&ctxt->state.aes.key,
+&ctxt->state.aes.key_tweak,
+qcrypto_cipher_aes_xts_encrypt,
+qcrypto_cipher_aes_xts_decrypt,
+ctxt->state.aes.iv,
+len, out, in);
+break;
 default:
 g_assert_not_reached();
 }
@@ -167,6 +201,14 @@ static int qcrypto_cipher_decrypt_aes(QCryptoCipher 
*cipher,
 &ctxt->state.aes.key.dec,
 ctxt->state.aes.iv, 0);
 break;
+case QCRYPTO_CIPHER_MODE_XTS:
+xts_decrypt(&ctxt->state.aes.key,
+&ctxt->state.aes.key_tweak,
+qcrypto_cipher_aes_xts_encrypt,
+qcrypto_cipher_aes_xts_decrypt,
+ctxt->state.aes.iv,
+len, out, in);
+break;
 default:
 g_assert_not_reached();
 }
@@ -200,21 +242,46 @@ static int qcrypto_cipher_init_aes(QCryptoCipher *cipher,
 QCryptoCipherBuiltin *ctxt;
 
 if (cipher->mode != QCRYPTO_CIPHER_MODE_CBC &&
-cipher->mode != QCRYPTO_CIPHER_MODE_ECB) {
+cipher->mode != QCRYPTO_CIPHER_MODE_ECB &&
+cipher->mode != QCRYPTO_CIPHER_MODE_XTS) {
 error_setg(errp, "Unsupported cipher mode %d", cipher->mode);
 return -1;
 }
 
 ctxt = g_new0(QCryptoCipherBuiltin, 1);
 
-if (AES_set_encrypt_key(key, nkey * 8, &ctxt->state.aes.key.enc) != 0) {
-error_setg(errp, "Failed to set encryption key");
-goto error;
-}
+if (cipher->mode == QCRYPTO_CIPHER_MODE_XTS) {
+if (AES_set_encrypt_key(key, nkey * 4, &ctxt->state.aes.key.enc) != 0) 
{
+error_setg(errp, "Failed to set encryption key");
+goto error;
+}
 
-if (AES_set_decrypt_key(key, nkey * 8, &ctxt->state.aes.key.dec) != 0) {
-error_setg(errp, "Failed to set decryption key");
-goto error;
+if (AES_set_decrypt_key(key, nkey * 4, &ctxt->state.aes.key.dec) != 0) 
{
+error_setg(errp, "Failed to set decryption key");
+goto error;
+}
+
+if (AES_set_encrypt_key(key + (nkey / 2), nkey * 

[Qemu-devel] ODP: [PATCH v4 02/11] block: m25p80: RESET_ENABLE and RESET_MEMORY commnads

2016-03-18 Thread Krzeminski, Marcin (Nokia - PL/Wroclaw)


W dniu 17.03.2016 o 18:42, Peter Crosthwaite pisze:
> "commands" in commit msg
>
> On Mon, Feb 22, 2016 at 12:03 AM,   wrote:
>> From: Marcin Krzeminski 
>>
>> Signed-off-by: Marcin Krzeminski 
>> ---
>>  hw/block/m25p80.c | 35 ++-
>>  1 file changed, 34 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
>> index 124..06b0af3 100644
>> --- a/hw/block/m25p80.c
>> +++ b/hw/block/m25p80.c
>> @@ -233,6 +233,9 @@ typedef enum {
>>  ERASE_4K = 0x20,
>>  ERASE_32K = 0x52,
>>  ERASE_SECTOR = 0xd8,
>> +
>> +RESET_ENABLE = 0x66,
>> +RESET_MEMORY = 0x99,
>>  } FlashCMD;
>>
>>  typedef enum {
>> @@ -260,6 +263,7 @@ typedef struct Flash {
>>  uint8_t cmd_in_progress;
>>  uint64_t cur_addr;
>>  bool write_enable;
>> +bool reset_enable;
>>
>>  int64_t dirty_page;
>>
>> @@ -432,11 +436,29 @@ static void complete_collecting_data(Flash *s)
>>  }
>>  }
>>
>> +static void reset_memory(Flash *s)
>> +{
>> +s->cmd_in_progress = NOP;
>> +s->cur_addr = 0;
>> +s->len = 0;
>> +s->needed_bytes = 0;
>> +s->pos = 0;
>> +s->state = STATE_IDLE;
>> +s->write_enable = false;
>> +s->reset_enable = false;
>> +
>> +DB_PRINT_L(0, "Reset done.\n");
>> +}
>> +
>>  static void decode_new_cmd(Flash *s, uint32_t value)
>>  {
>>  s->cmd_in_progress = value;
>>  DB_PRINT_L(0, "decoded new command:%x\n", value);
>>
>> +if (value != RESET_MEMORY) {
>> +s->reset_enable = false;
>> +}
>> +
>>  switch (value) {
>>
>>  case ERASE_4K:
>> @@ -541,6 +563,14 @@ static void decode_new_cmd(Flash *s, uint32_t value)
>>  break;
>>  case NOP:
>>  break;
>> +case RESET_ENABLE:
>> +s->reset_enable = true;
>> +break;
>> +case RESET_MEMORY:
>> +if (s->reset_enable) {
>> +reset_memory(s);
>> +}
>> +break;
>>  default:
>>  qemu_log_mask(LOG_GUEST_ERROR, "M25P80: Unknown cmd %x\n", value);
>>  break;
>> @@ -622,6 +652,8 @@ static int m25p80_init(SSISlave *ss)
>>  s->size = s->pi->sector_size * s->pi->n_sectors;
>>  s->dirty_page = -1;
>>
>> +reset_memory(s);
>> +
>
> This shouldn't be here, you need to add a Device::reset function. Your
> use case of persisting data through a warn system reset (that we
> discussed previously) is difficult to support with QEMUs current reset
> semantics and your board is out-of-tree. So I think this should be in
> the Device::reset and we need to revisit your unique use case along
> with the addition of your board.
My impression was, that I should remove all "warm reset" additions I made
(including dc::reset) and move reset_memory call to init that is why it is here.
I will move it to dc:reset in v5.

Thanks,
Marcin
>
>
> So with the move to device::reset,
>
> Reviewed-by: Peter Crosthwaite 
>
>>  /* FIXME use a qdev drive property instead of drive_get_next() */
>>  dinfo = drive_get_next(IF_MTD);
>>
>> @@ -654,7 +686,7 @@ static void m25p80_pre_save(void *opaque)
>>
>>  static const VMStateDescription vmstate_m25p80 = {
>>  .name = "xilinx_spi",
>> -.version_id = 1,
>> +.version_id = 2,
>>  .minimum_version_id = 1,
>>  .pre_save = m25p80_pre_save,
>>  .fields = (VMStateField[]) {
>> @@ -666,6 +698,7 @@ static const VMStateDescription vmstate_m25p80 = {
>>  VMSTATE_UINT8(cmd_in_progress, Flash),
>>  VMSTATE_UINT64(cur_addr, Flash),
>>  VMSTATE_BOOL(write_enable, Flash),
>> +VMSTATE_BOOL(reset_enable, Flash),
>>  VMSTATE_END_OF_LIST()
>>  }
>>  };
>> --
>> 2.5.0
>>
>
>




[Qemu-devel] [PATCH 27/49] arm: remove useless cpu.h inclusion

2016-03-18 Thread Paolo Bonzini
Signed-off-by: Paolo Bonzini 
---
 include/hw/arm/digic.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/hw/arm/digic.h b/include/hw/arm/digic.h
index a739d6a..aaefe0b 100644
--- a/include/hw/arm/digic.h
+++ b/include/hw/arm/digic.h
@@ -18,8 +18,6 @@
 #ifndef HW_ARM_DIGIC_H
 #define HW_ARM_DIGIC_H
 
-#include "cpu.h"
-
 #include "hw/timer/digic-timer.h"
 #include "hw/char/digic-uart.h"
 
-- 
1.8.3.1





[Qemu-devel] [PATCH RFC 5/6] virtio-mmio: convert to ioeventfd callbacks

2016-03-18 Thread Cornelia Huck
Convert to the new interface.

Signed-off-by: Cornelia Huck 
---
 hw/virtio/virtio-mmio.c | 128 
 1 file changed, 41 insertions(+), 87 deletions(-)

diff --git a/hw/virtio/virtio-mmio.c b/hw/virtio/virtio-mmio.c
index d4cd91f..d2accbc 100644
--- a/hw/virtio/virtio-mmio.c
+++ b/hw/virtio/virtio-mmio.c
@@ -93,90 +93,59 @@ typedef struct {
 bool ioeventfd_started;
 } VirtIOMMIOProxy;
 
-static int virtio_mmio_set_host_notifier_internal(VirtIOMMIOProxy *proxy,
-  int n, bool assign,
-  bool set_handler)
+static bool virtio_mmio_ioeventfd_started(DeviceState *d)
 {
-VirtIODevice *vdev = virtio_bus_get_device(&proxy->bus);
-VirtQueue *vq = virtio_get_queue(vdev, n);
-EventNotifier *notifier = virtio_queue_get_host_notifier(vq);
-int r = 0;
+VirtIOMMIOProxy *proxy = VIRTIO_MMIO(d);
 
-if (assign) {
-r = event_notifier_init(notifier, 1);
-if (r < 0) {
-error_report("%s: unable to init event notifier: %d",
- __func__, r);
-return r;
-}
-virtio_queue_set_host_notifier_fd_handler(vq, true, set_handler);
-memory_region_add_eventfd(&proxy->iomem, VIRTIO_MMIO_QUEUENOTIFY, 4,
-  true, n, notifier);
-} else {
-memory_region_del_eventfd(&proxy->iomem, VIRTIO_MMIO_QUEUENOTIFY, 4,
-  true, n, notifier);
-virtio_queue_set_host_notifier_fd_handler(vq, false, false);
-event_notifier_cleanup(notifier);
-}
-return r;
+return proxy->ioeventfd_started;
 }
 
-static void virtio_mmio_start_ioeventfd(VirtIOMMIOProxy *proxy)
+static void virtio_mmio_ioeventfd_set_started(DeviceState *d, bool started,
+  bool err)
 {
-VirtIODevice *vdev = virtio_bus_get_device(&proxy->bus);
-int n, r;
+VirtIOMMIOProxy *proxy = VIRTIO_MMIO(d);
 
-if (!kvm_eventfds_enabled() ||
-proxy->ioeventfd_disabled ||
-proxy->ioeventfd_started) {
-return;
-}
+proxy->ioeventfd_started = started;
+}
 
-for (n = 0; n < VIRTIO_QUEUE_MAX; n++) {
-if (!virtio_queue_get_num(vdev, n)) {
-continue;
-}
+static bool virtio_mmio_ioeventfd_disabled(DeviceState *d)
+{
+VirtIOMMIOProxy *proxy = VIRTIO_MMIO(d);
 
-r = virtio_mmio_set_host_notifier_internal(proxy, n, true, true);
-if (r < 0) {
-goto assign_error;
-}
-}
-proxy->ioeventfd_started = true;
-return;
+return !kvm_eventfds_enabled() || proxy->ioeventfd_disabled;
+}
 
-assign_error:
-while (--n >= 0) {
-if (!virtio_queue_get_num(vdev, n)) {
-continue;
-}
+static void virtio_mmio_ioeventfd_set_disabled(DeviceState *d, bool disabled)
+{
+VirtIOMMIOProxy *proxy = VIRTIO_MMIO(d);
 
-r = virtio_mmio_set_host_notifier_internal(proxy, n, false, false);
-assert(r >= 0);
-}
-proxy->ioeventfd_started = false;
-error_report("%s: failed. Fallback to a userspace (slower).", __func__);
+proxy->ioeventfd_disabled = disabled;
 }
 
-static void virtio_mmio_stop_ioeventfd(VirtIOMMIOProxy *proxy)
+static int virtio_mmio_ioeventfd_assign(DeviceState *d,
+EventNotifier *notifier,
+int n, bool assign)
 {
-int r;
-int n;
-VirtIODevice *vdev = virtio_bus_get_device(&proxy->bus);
+VirtIOMMIOProxy *proxy = VIRTIO_MMIO(d);
 
-if (!proxy->ioeventfd_started) {
-return;
+if (assign) {
+memory_region_add_eventfd(&proxy->iomem, VIRTIO_MMIO_QUEUENOTIFY, 4,
+  true, n, notifier);
+} else {
+memory_region_del_eventfd(&proxy->iomem, VIRTIO_MMIO_QUEUENOTIFY, 4,
+  true, n, notifier);
 }
+return 0;
+}
 
-for (n = 0; n < VIRTIO_QUEUE_MAX; n++) {
-if (!virtio_queue_get_num(vdev, n)) {
-continue;
-}
+static void virtio_mmio_start_ioeventfd(VirtIOMMIOProxy *proxy)
+{
+virtio_bus_start_ioeventfd(&proxy->bus);
+}
 
-r = virtio_mmio_set_host_notifier_internal(proxy, n, false, false);
-assert(r >= 0);
-}
-proxy->ioeventfd_started = false;
+static void virtio_mmio_stop_ioeventfd(VirtIOMMIOProxy *proxy)
+{
+virtio_bus_stop_ioeventfd(&proxy->bus, false);
 }
 
 static uint64_t virtio_mmio_read(void *opaque, hwaddr offset, unsigned size)
@@ -498,25 +467,6 @@ assign_error:
 return r;
 }
 
-static int virtio_mmio_set_host_notifier(DeviceState *opaque, int n,
- bool assign)
-{
-VirtIOMMIOProxy *proxy = VIRTIO_MMIO(opaque);
-
-/* Stop using ioeventfd for virtqueue kick if the device starts using host
- * notifiers.  This makes it easy to avoid stepping on each

[Qemu-devel] [PATCH v5 17/28] migration: convert RDMA to use QIOChannel interface

2016-03-18 Thread Daniel P. Berrange
This converts the RDMA code to provide a subclass of QIOChannel
that uses RDMA for the data transport.

This implementation of RDMA does not correctly handle non-blocking
mode. Reads might block if there was not already some pending data
and writes will block until all data is sent. This flawed behaviour
was already present in the existing impl, so appears to not be a
critical problem at this time. It should be on the list of things
to fix in the future though.

The RDMA code would be much better off it it could be split up in
a generic RDMA layer, a QIOChannel impl based on RMDA, and then
the RMDA migration glue. This is left as a future exercise for
the brave.

Reviewed-by: Dr. David Alan Gilbert 
Signed-off-by: Daniel P. Berrange 
---
 migration/rdma.c | 374 ---
 1 file changed, 275 insertions(+), 99 deletions(-)

diff --git a/migration/rdma.c b/migration/rdma.c
index cd33d90..4756149 100644
--- a/migration/rdma.c
+++ b/migration/rdma.c
@@ -2,10 +2,12 @@
  * RDMA protocol and interfaces
  *
  * Copyright IBM, Corp. 2010-2013
+ * Copyright Red Hat, Inc. 2015-2016
  *
  * Authors:
  *  Michael R. Hines 
  *  Jiuxing Liu 
+ *  Daniel P. Berrange 
  *
  * This work is licensed under the terms of the GNU GPL, version 2 or
  * later.  See the COPYING file in the top-level directory.
@@ -372,14 +374,20 @@ typedef struct RDMAContext {
 GHashTable *blockmap;
 } RDMAContext;
 
-/*
- * Interface to the rest of the migration call stack.
- */
-typedef struct QEMUFileRDMA {
+#define TYPE_QIO_CHANNEL_RDMA "qio-channel-rdma"
+#define QIO_CHANNEL_RDMA(obj) \
+OBJECT_CHECK(QIOChannelRDMA, (obj), TYPE_QIO_CHANNEL_RDMA)
+
+typedef struct QIOChannelRDMA QIOChannelRDMA;
+
+
+struct QIOChannelRDMA {
+QIOChannel parent;
 RDMAContext *rdma;
+QEMUFile *file;
 size_t len;
-void *file;
-} QEMUFileRDMA;
+bool blocking; /* XXX we don't actually honour this yet */
+};
 
 /*
  * Main structure for IB Send/Recv control messages.
@@ -2516,15 +2524,19 @@ static void *qemu_rdma_data_init(const char *host_port, 
Error **errp)
  * SEND messages for control only.
  * VM's ram is handled with regular RDMA messages.
  */
-static ssize_t qemu_rdma_put_buffer(void *opaque, const uint8_t *buf,
-int64_t pos, size_t size)
-{
-QEMUFileRDMA *r = opaque;
-QEMUFile *f = r->file;
-RDMAContext *rdma = r->rdma;
-size_t remaining = size;
-uint8_t * data = (void *) buf;
+static ssize_t qio_channel_rdma_writev(QIOChannel *ioc,
+   const struct iovec *iov,
+   size_t niov,
+   int *fds,
+   size_t nfds,
+   Error **errp)
+{
+QIOChannelRDMA *rioc = QIO_CHANNEL_RDMA(ioc);
+QEMUFile *f = rioc->file;
+RDMAContext *rdma = rioc->rdma;
 int ret;
+ssize_t done = 0;
+size_t i;
 
 CHECK_ERROR_STATE();
 
@@ -2538,27 +2550,31 @@ static ssize_t qemu_rdma_put_buffer(void *opaque, const 
uint8_t *buf,
 return ret;
 }
 
-while (remaining) {
-RDMAControlHeader head;
+for (i = 0; i < niov; i++) {
+size_t remaining = iov[i].iov_len;
+uint8_t * data = (void *)iov[i].iov_base;
+while (remaining) {
+RDMAControlHeader head;
 
-r->len = MIN(remaining, RDMA_SEND_INCREMENT);
-remaining -= r->len;
+rioc->len = MIN(remaining, RDMA_SEND_INCREMENT);
+remaining -= rioc->len;
 
-/* Guaranteed to fit due to RDMA_SEND_INCREMENT MIN above */
-head.len = (uint32_t)r->len;
-head.type = RDMA_CONTROL_QEMU_FILE;
+head.len = rioc->len;
+head.type = RDMA_CONTROL_QEMU_FILE;
 
-ret = qemu_rdma_exchange_send(rdma, &head, data, NULL, NULL, NULL);
+ret = qemu_rdma_exchange_send(rdma, &head, data, NULL, NULL, NULL);
 
-if (ret < 0) {
-rdma->error_state = ret;
-return ret;
-}
+if (ret < 0) {
+rdma->error_state = ret;
+return ret;
+}
 
-data += r->len;
+data += rioc->len;
+done += rioc->len;
+}
 }
 
-return size;
+return done;
 }
 
 static size_t qemu_rdma_fill(RDMAContext *rdma, uint8_t *buf,
@@ -2583,41 +2599,74 @@ static size_t qemu_rdma_fill(RDMAContext *rdma, uint8_t 
*buf,
  * RDMA links don't use bytestreams, so we have to
  * return bytes to QEMUFile opportunistically.
  */
-static ssize_t qemu_rdma_get_buffer(void *opaque, uint8_t *buf,
-int64_t pos, size_t size)
-{
-QEMUFileRDMA *r = opaque;
-RDMAContext *rdma = r->rdma;
+static ssize_t qio_channel_rdma_readv(QIOChannel *ioc,
+  const struct iovec *iov,
+ 

[Qemu-devel] [PATCH 08/15] nvdimm acpi: save arg3 of _DSM method

2016-03-18 Thread Xiao Guangrong
Check if the input Arg3 is valid then store it into ARG3 if it is
needed

Signed-off-by: Xiao Guangrong 
---
 hw/acpi/nvdimm.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
index 586c02a..38aba3d 100644
--- a/hw/acpi/nvdimm.c
+++ b/hw/acpi/nvdimm.c
@@ -486,6 +486,7 @@ void nvdimm_init_acpi_state(AcpiNVDIMMState *state, 
MemoryRegion *io,
 static void nvdimm_build_common_dsm(Aml *dev)
 {
 Aml *method, *ifctx, *function, *dsm_mem, *unpatched, *result_size;
+Aml *pckg, *pckg_index, *pckg_buf;
 uint8_t byte_list[1];
 
 method = aml_method(NVDIMM_COMMON_DSM, 5, AML_SERIALIZED);
@@ -522,6 +523,25 @@ static void nvdimm_build_common_dsm(Aml *dev)
 aml_append(method, aml_store(aml_arg(2), aml_name("FUNC")));
 
 /*
+ * The fourth parameter (Arg3) of _DSM is a package which contains
+ * a buffer, the layout of the buffer is specified by UUID (Arg0),
+ * Revision ID (Arg1) and Function Index (Arg2) which are documented
+ * in the DSM Spec.
+ */
+pckg = aml_arg(3);
+ifctx = aml_if(aml_and(aml_equal(aml_object_type(pckg),
+   aml_int(4 /* Package */)) /* It is a Package? */,
+   aml_equal(aml_sizeof(pckg), aml_int(1)) /* 1 element? */,
+   NULL));
+
+pckg_index = aml_local(2);
+pckg_buf = aml_local(3);
+aml_append(ifctx, aml_store(aml_index(pckg, aml_int(0)), pckg_index));
+aml_append(ifctx, aml_store(aml_derefof(pckg_index), pckg_buf));
+aml_append(ifctx, aml_store(pckg_buf, aml_name("ARG3")));
+aml_append(method, ifctx);
+
+/*
  * tell QEMU about the real address of DSM memory, then QEMU
  * gets the control and fills the result in DSM memory.
  */
-- 
1.8.3.1




Re: [Qemu-devel] [PATCH v3 00/13] tests: Introducing docker tests

2016-03-18 Thread Daniel P. Berrange
On Fri, Mar 11, 2016 at 04:16:58PM +, Alex Bennée wrote:
> 
> Fam Zheng  writes:
> 
> > v3 changes:
> 
> I think we are almost there. There a just a few tweaks to be made to
> help text and prompts. Can you ensure that all examples in commit
> messages and help text actually do run as expected?
> 
> Is it proposed this goes through Daniel's treee?

What tree is that you're referring to ? I certainly don't consider
myself the maintainer of all tests in QEMU :-)  I'd say that Fam
is maintainer of tests/docker/ and should thus just send PULL for
it request(s) directly


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|



[Qemu-devel] [PULL v2 08/13] crypto: add support for the twofish cipher algorithm

2016-03-18 Thread Daniel P. Berrange
New cipher algorithms 'twofish-128', 'twofish-192' and
'twofish-256' are defined for the Twofish algorithm.
The gcrypt backend does not support 'twofish-192'.

The nettle and gcrypt cipher backends are updated to
support the new cipher and a test vector added to the
cipher test suite. The new algorithm is enabled in the
LUKS block encryption driver.

Reviewed-by: Eric Blake 
Reviewed-by: Fam Zheng 
Signed-off-by: Daniel P. Berrange 
---
 crypto/cipher-gcrypt.c | 12 
 crypto/cipher-nettle.c | 30 ++
 crypto/cipher.c|  6 ++
 qapi/crypto.json   |  6 +-
 tests/test-crypto-cipher.c | 29 +
 5 files changed, 82 insertions(+), 1 deletion(-)

diff --git a/crypto/cipher-gcrypt.c b/crypto/cipher-gcrypt.c
index a667d59..ce26456 100644
--- a/crypto/cipher-gcrypt.c
+++ b/crypto/cipher-gcrypt.c
@@ -33,6 +33,8 @@ bool qcrypto_cipher_supports(QCryptoCipherAlgorithm alg)
 case QCRYPTO_CIPHER_ALG_SERPENT_128:
 case QCRYPTO_CIPHER_ALG_SERPENT_192:
 case QCRYPTO_CIPHER_ALG_SERPENT_256:
+case QCRYPTO_CIPHER_ALG_TWOFISH_128:
+case QCRYPTO_CIPHER_ALG_TWOFISH_256:
 return true;
 default:
 return false;
@@ -104,6 +106,14 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorithm 
alg,
 gcryalg = GCRY_CIPHER_SERPENT256;
 break;
 
+case QCRYPTO_CIPHER_ALG_TWOFISH_128:
+gcryalg = GCRY_CIPHER_TWOFISH128;
+break;
+
+case QCRYPTO_CIPHER_ALG_TWOFISH_256:
+gcryalg = GCRY_CIPHER_TWOFISH;
+break;
+
 default:
 error_setg(errp, "Unsupported cipher algorithm %d", alg);
 return NULL;
@@ -140,6 +150,8 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorithm 
alg,
 case QCRYPTO_CIPHER_ALG_SERPENT_128:
 case QCRYPTO_CIPHER_ALG_SERPENT_192:
 case QCRYPTO_CIPHER_ALG_SERPENT_256:
+case QCRYPTO_CIPHER_ALG_TWOFISH_128:
+case QCRYPTO_CIPHER_ALG_TWOFISH_256:
 ctx->blocksize = 16;
 break;
 case QCRYPTO_CIPHER_ALG_CAST5_128:
diff --git a/crypto/cipher-nettle.c b/crypto/cipher-nettle.c
index 74b55ab..9b057fd 100644
--- a/crypto/cipher-nettle.c
+++ b/crypto/cipher-nettle.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #if CONFIG_NETTLE_VERSION_MAJOR < 3
 typedef nettle_crypt_func nettle_cipher_func;
@@ -89,6 +90,18 @@ static void serpent_decrypt_wrapper(cipher_ctx_t ctx, 
cipher_length_t length,
 serpent_decrypt(ctx, length, dst, src);
 }
 
+static void twofish_encrypt_wrapper(cipher_ctx_t ctx, cipher_length_t length,
+uint8_t *dst, const uint8_t *src)
+{
+twofish_encrypt(ctx, length, dst, src);
+}
+
+static void twofish_decrypt_wrapper(cipher_ctx_t ctx, cipher_length_t length,
+uint8_t *dst, const uint8_t *src)
+{
+twofish_decrypt(ctx, length, dst, src);
+}
+
 typedef struct QCryptoCipherNettle QCryptoCipherNettle;
 struct QCryptoCipherNettle {
 void *ctx_encrypt;
@@ -110,6 +123,9 @@ bool qcrypto_cipher_supports(QCryptoCipherAlgorithm alg)
 case QCRYPTO_CIPHER_ALG_SERPENT_128:
 case QCRYPTO_CIPHER_ALG_SERPENT_192:
 case QCRYPTO_CIPHER_ALG_SERPENT_256:
+case QCRYPTO_CIPHER_ALG_TWOFISH_128:
+case QCRYPTO_CIPHER_ALG_TWOFISH_192:
+case QCRYPTO_CIPHER_ALG_TWOFISH_256:
 return true;
 default:
 return false;
@@ -200,6 +216,20 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorithm 
alg,
 ctx->blocksize = SERPENT_BLOCK_SIZE;
 break;
 
+case QCRYPTO_CIPHER_ALG_TWOFISH_128:
+case QCRYPTO_CIPHER_ALG_TWOFISH_192:
+case QCRYPTO_CIPHER_ALG_TWOFISH_256:
+ctx->ctx_encrypt = g_new0(struct twofish_ctx, 1);
+ctx->ctx_decrypt = NULL; /* 1 ctx can do both */
+
+twofish_set_key(ctx->ctx_encrypt, nkey, key);
+
+ctx->alg_encrypt = twofish_encrypt_wrapper;
+ctx->alg_decrypt = twofish_decrypt_wrapper;
+
+ctx->blocksize = TWOFISH_BLOCK_SIZE;
+break;
+
 default:
 error_setg(errp, "Unsupported cipher algorithm %d", alg);
 goto error;
diff --git a/crypto/cipher.c b/crypto/cipher.c
index 0f6fe98..89fa5a2 100644
--- a/crypto/cipher.c
+++ b/crypto/cipher.c
@@ -31,6 +31,9 @@ static size_t alg_key_len[QCRYPTO_CIPHER_ALG__MAX] = {
 [QCRYPTO_CIPHER_ALG_SERPENT_128] = 16,
 [QCRYPTO_CIPHER_ALG_SERPENT_192] = 24,
 [QCRYPTO_CIPHER_ALG_SERPENT_256] = 32,
+[QCRYPTO_CIPHER_ALG_TWOFISH_128] = 16,
+[QCRYPTO_CIPHER_ALG_TWOFISH_192] = 24,
+[QCRYPTO_CIPHER_ALG_TWOFISH_256] = 32,
 };
 
 static size_t alg_block_len[QCRYPTO_CIPHER_ALG__MAX] = {
@@ -42,6 +45,9 @@ static size_t alg_block_len[QCRYPTO_CIPHER_ALG__MAX] = {
 [QCRYPTO_CIPHER_ALG_SERPENT_128] = 16,
 [QCRYPTO_CIPHER_ALG_SERPENT_192] = 16,
 [QCRYPTO_CIPHER_ALG_SERPENT_256] = 16,
+[QCRYPTO_CIPHER_ALG_TWOFISH_128] = 16,
+[QCRYPTO_CIPHER_ALG_TWOFISH_192] = 16,
+[QC

[Qemu-devel] [PULL 16/40] ivshmem: Fix harmless misuse of Error

2016-03-18 Thread Markus Armbruster
We reuse errp after passing it host_memory_backend_get_memory().  If
both host_memory_backend_get_memory() and the reuse set an error, the
reuse will fail the assertion in error_setv().  Fortunately,
host_memory_backend_get_memory() can't fail.

Pass it &error_abort to make our assumption explicit, and to get the
assertion failure in the right place should it become invalid.

Signed-off-by: Markus Armbruster 
Reviewed-by: Marc-André Lureau 
Message-Id: <1458066895-20632-17-git-send-email-arm...@redhat.com>
---
 hw/misc/ivshmem.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index 0ac0238..299cf5b 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -842,7 +842,7 @@ static void pci_ivshmem_realize(PCIDevice *dev, Error 
**errp)
 g_warning("size argument ignored with hostmem");
 }
 
-mr = host_memory_backend_get_memory(s->hostmem, errp);
+mr = host_memory_backend_get_memory(s->hostmem, &error_abort);
 s->ivshmem_size = memory_region_size(mr);
 } else if (s->sizearg == NULL) {
 s->ivshmem_size = 4 << 20; /* 4 MB default */
@@ -907,7 +907,8 @@ static void pci_ivshmem_realize(PCIDevice *dev, Error 
**errp)
 
 IVSHMEM_DPRINTF("using hostmem\n");
 
-mr = host_memory_backend_get_memory(MEMORY_BACKEND(s->hostmem), errp);
+mr = host_memory_backend_get_memory(MEMORY_BACKEND(s->hostmem),
+&error_abort);
 vmstate_register_ram(mr, DEVICE(s));
 memory_region_add_subregion(&s->bar, 0, mr);
 pci_register_bar(PCI_DEVICE(s), 2, attr, &s->bar);
@@ -1134,7 +1135,7 @@ static void ivshmem_check_memdev_is_busy(Object *obj, 
const char *name,
 {
 MemoryRegion *mr;
 
-mr = host_memory_backend_get_memory(MEMORY_BACKEND(val), errp);
+mr = host_memory_backend_get_memory(MEMORY_BACKEND(val), &error_abort);
 if (memory_region_is_mapped(mr)) {
 char *path = object_get_canonical_path_component(val);
 error_setg(errp, "can't use already busy memdev: %s", path);
-- 
2.4.3




Re: [Qemu-devel] [PULL v3 00/13] Merge crypto code for LUKS encryption

2016-03-18 Thread Peter Maydell
On 17 March 2016 at 16:53, Daniel P. Berrange  wrote:
> The following changes since commit 8c4575472494a5dfedfe05e7b58ca9ce3872ad56:
>
>   Merge remote-tracking branch 'remotes/ehabkost/tags/machine-pull-request' 
> into staging (2016-03-17 08:52:58 +)
>
> are available in the git repository at:
>
>   git://github.com/berrange/qemu tags/pull-qcrypto-2016-03-17-3
>
> for you to fetch changes up to 3e308f20edfd65a21c98eb2d8079dacd47957444:
>
>   crypto: implement the LUKS block encryption format (2016-03-17 16:50:40 
> +)
>
> 
> Merge QCrypto 2016/03/17 v3
>

Applied, thanks.

-- PMM



[Qemu-devel] [PULL v2 06/13] crypto: add support for the cast5-128 cipher algorithm

2016-03-18 Thread Daniel P. Berrange
A new cipher algorithm 'cast-5-128' is defined for the
Cast-5 algorithm with 128 bit key size. Smaller key sizes
are supported by Cast-5, but nothing in QEMU should use
them, so only 128 bit keys are permitted.

The nettle and gcrypt cipher backends are updated to
support the new cipher and a test vector added to the
cipher test suite. The new algorithm is enabled in the
LUKS block encryption driver.

Reviewed-by: Eric Blake 
Reviewed-by: Fam Zheng 
Signed-off-by: Daniel P. Berrange 
---
 crypto/cipher-gcrypt.c | 18 +-
 crypto/cipher-nettle.c | 26 ++
 crypto/cipher.c|  2 ++
 qapi/crypto.json   |  5 -
 tests/test-crypto-cipher.c |  9 +
 5 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/crypto/cipher-gcrypt.c b/crypto/cipher-gcrypt.c
index 56d4c9d..aa1d8c5 100644
--- a/crypto/cipher-gcrypt.c
+++ b/crypto/cipher-gcrypt.c
@@ -29,6 +29,7 @@ bool qcrypto_cipher_supports(QCryptoCipherAlgorithm alg)
 case QCRYPTO_CIPHER_ALG_AES_128:
 case QCRYPTO_CIPHER_ALG_AES_192:
 case QCRYPTO_CIPHER_ALG_AES_256:
+case QCRYPTO_CIPHER_ALG_CAST5_128:
 return true;
 default:
 return false;
@@ -84,6 +85,10 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorithm alg,
 gcryalg = GCRY_CIPHER_AES256;
 break;
 
+case QCRYPTO_CIPHER_ALG_CAST5_128:
+gcryalg = GCRY_CIPHER_CAST5;
+break;
+
 default:
 error_setg(errp, "Unsupported cipher algorithm %d", alg);
 return NULL;
@@ -113,7 +118,18 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorithm 
alg,
 ctx->blocksize = 8;
 } else {
 err = gcry_cipher_setkey(ctx->handle, key, nkey);
-ctx->blocksize = 16;
+switch (cipher->alg) {
+case QCRYPTO_CIPHER_ALG_AES_128:
+case QCRYPTO_CIPHER_ALG_AES_192:
+case QCRYPTO_CIPHER_ALG_AES_256:
+ctx->blocksize = 16;
+break;
+case QCRYPTO_CIPHER_ALG_CAST5_128:
+ctx->blocksize = 8;
+break;
+default:
+g_assert_not_reached();
+}
 }
 if (err != 0) {
 error_setg(errp, "Cannot set key: %s",
diff --git a/crypto/cipher-nettle.c b/crypto/cipher-nettle.c
index cd2675c..cfa69cc 100644
--- a/crypto/cipher-nettle.c
+++ b/crypto/cipher-nettle.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #if CONFIG_NETTLE_VERSION_MAJOR < 3
 typedef nettle_crypt_func nettle_cipher_func;
@@ -63,6 +64,18 @@ static void des_decrypt_wrapper(cipher_ctx_t ctx, 
cipher_length_t length,
 des_decrypt(ctx, length, dst, src);
 }
 
+static void cast128_encrypt_wrapper(cipher_ctx_t ctx, cipher_length_t length,
+uint8_t *dst, const uint8_t *src)
+{
+cast128_encrypt(ctx, length, dst, src);
+}
+
+static void cast128_decrypt_wrapper(cipher_ctx_t ctx, cipher_length_t length,
+uint8_t *dst, const uint8_t *src)
+{
+cast128_decrypt(ctx, length, dst, src);
+}
+
 typedef struct QCryptoCipherNettle QCryptoCipherNettle;
 struct QCryptoCipherNettle {
 void *ctx_encrypt;
@@ -80,6 +93,7 @@ bool qcrypto_cipher_supports(QCryptoCipherAlgorithm alg)
 case QCRYPTO_CIPHER_ALG_AES_128:
 case QCRYPTO_CIPHER_ALG_AES_192:
 case QCRYPTO_CIPHER_ALG_AES_256:
+case QCRYPTO_CIPHER_ALG_CAST5_128:
 return true;
 default:
 return false;
@@ -143,6 +157,18 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorithm 
alg,
 
 ctx->blocksize = AES_BLOCK_SIZE;
 break;
+
+case QCRYPTO_CIPHER_ALG_CAST5_128:
+ctx->ctx_encrypt = g_new0(struct cast128_ctx, 1);
+ctx->ctx_decrypt = NULL; /* 1 ctx can do both */
+
+cast5_set_key(ctx->ctx_encrypt, nkey, key);
+
+ctx->alg_encrypt = cast128_encrypt_wrapper;
+ctx->alg_decrypt = cast128_decrypt_wrapper;
+
+ctx->blocksize = CAST128_BLOCK_SIZE;
+break;
 default:
 error_setg(errp, "Unsupported cipher algorithm %d", alg);
 goto error;
diff --git a/crypto/cipher.c b/crypto/cipher.c
index 076dff0..9e0a226 100644
--- a/crypto/cipher.c
+++ b/crypto/cipher.c
@@ -27,6 +27,7 @@ static size_t alg_key_len[QCRYPTO_CIPHER_ALG__MAX] = {
 [QCRYPTO_CIPHER_ALG_AES_192] = 24,
 [QCRYPTO_CIPHER_ALG_AES_256] = 32,
 [QCRYPTO_CIPHER_ALG_DES_RFB] = 8,
+[QCRYPTO_CIPHER_ALG_CAST5_128] = 16,
 };
 
 static size_t alg_block_len[QCRYPTO_CIPHER_ALG__MAX] = {
@@ -34,6 +35,7 @@ static size_t alg_block_len[QCRYPTO_CIPHER_ALG__MAX] = {
 [QCRYPTO_CIPHER_ALG_AES_192] = 16,
 [QCRYPTO_CIPHER_ALG_AES_256] = 16,
 [QCRYPTO_CIPHER_ALG_DES_RFB] = 8,
+[QCRYPTO_CIPHER_ALG_CAST5_128] = 8,
 };
 
 static bool mode_need_iv[QCRYPTO_CIPHER_MODE__MAX] = {
diff --git a/qapi/crypto.json b/qapi/crypto.json
index 42b979a..0550ee7 100644
--- a/qapi/crypto.json
+++ b/qapi/crypto.json
@@ -59,11 +59,14 @@
 # @aes-192: AES with 192 bit / 24 byte keys
 # 

[Qemu-devel] [PATCH v4 06/17] block: Drop BB name from bad option error

2016-03-18 Thread Max Reitz
The information which BB is concerned does not seem useful enough to
justify its existence in most other place (which may be related to qemu
printing the -drive parameter in question anyway, and for blockdev-add
the attribution is naturally unambiguous). Furthermore, as of a future
patch, bdrv_get_device_name(bs) will always return the empty string
before bdrv_open_inherit() returns.

Therefore, just dropping that information seems to be the best course of
action.

Signed-off-by: Max Reitz 
---
 block.c   | 6 +++---
 tests/qemu-iotests/051.out| 8 
 tests/qemu-iotests/051.pc.out | 8 
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/block.c b/block.c
index 59a18a3..582a9e8 100644
--- a/block.c
+++ b/block.c
@@ -1671,9 +1671,9 @@ static int bdrv_open_inherit(BlockDriverState **pbs, 
const char *filename,
 error_setg(errp, "Block protocol '%s' doesn't support the option "
"'%s'", drv->format_name, entry->key);
 } else {
-error_setg(errp, "Block format '%s' used by device '%s' doesn't "
-   "support the option '%s'", drv->format_name,
-   bdrv_get_device_name(bs), entry->key);
+error_setg(errp,
+   "Block format '%s' does not support the option '%s'",
+   drv->format_name, entry->key);
 }
 
 ret = -EINVAL;
diff --git a/tests/qemu-iotests/051.out b/tests/qemu-iotests/051.out
index 0f8a8d3..c1291ff 100644
--- a/tests/qemu-iotests/051.out
+++ b/tests/qemu-iotests/051.out
@@ -5,16 +5,16 @@ Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 
backing_file=TEST_DIR/
 === Unknown option ===
 
 Testing: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=,if=none,id=drive0
-QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=,if=none,id=drive0: Block format 
'qcow2' used by device 'drive0' doesn't support the option 'unknown_opt'
+QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=,if=none,id=drive0: Block format 
'qcow2' does not support the option 'unknown_opt'
 
 Testing: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=on,if=none,id=drive0
-QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=on,if=none,id=drive0: Block 
format 'qcow2' used by device 'drive0' doesn't support the option 'unknown_opt'
+QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=on,if=none,id=drive0: Block 
format 'qcow2' does not support the option 'unknown_opt'
 
 Testing: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=1234,if=none,id=drive0
-QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=1234,if=none,id=drive0: Block 
format 'qcow2' used by device 'drive0' doesn't support the option 'unknown_opt'
+QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=1234,if=none,id=drive0: Block 
format 'qcow2' does not support the option 'unknown_opt'
 
 Testing: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=foo,if=none,id=drive0
-QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=foo,if=none,id=drive0: Block 
format 'qcow2' used by device 'drive0' doesn't support the option 'unknown_opt'
+QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=foo,if=none,id=drive0: Block 
format 'qcow2' does not support the option 'unknown_opt'
 
 
 === Unknown protocol option ===
diff --git a/tests/qemu-iotests/051.pc.out b/tests/qemu-iotests/051.pc.out
index 85fc05d..73cc15a 100644
--- a/tests/qemu-iotests/051.pc.out
+++ b/tests/qemu-iotests/051.pc.out
@@ -5,16 +5,16 @@ Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 
backing_file=TEST_DIR/
 === Unknown option ===
 
 Testing: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=,if=none,id=drive0
-QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=,if=none,id=drive0: Block format 
'qcow2' used by device 'drive0' doesn't support the option 'unknown_opt'
+QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=,if=none,id=drive0: Block format 
'qcow2' does not support the option 'unknown_opt'
 
 Testing: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=on,if=none,id=drive0
-QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=on,if=none,id=drive0: Block 
format 'qcow2' used by device 'drive0' doesn't support the option 'unknown_opt'
+QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=on,if=none,id=drive0: Block 
format 'qcow2' does not support the option 'unknown_opt'
 
 Testing: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=1234,if=none,id=drive0
-QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=1234,if=none,id=drive0: Block 
format 'qcow2' used by device 'drive0' doesn't support the option 'unknown_opt'
+QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=1234,if=none,id=drive0: Block 
format 'qcow2' does not support the option 'unknown_opt'
 
 Testi

[Qemu-devel] [PATCH v2 12/16] aio: introduce aio_context_in_iothread

2016-03-18 Thread Paolo Bonzini
This will be used by bdrv_drain (and indirectly by the synchronous I/O
helpers), to choose between aio_poll or QemuEvent.

Reviewed-by: Fam Zheng 
Signed-off-by: Paolo Bonzini 
---
 include/block/aio.h | 7 +++
 iothread.c  | 9 +
 stubs/Makefile.objs | 1 +
 stubs/iothread.c| 8 
 4 files changed, 25 insertions(+)
 create mode 100644 stubs/iothread.c

diff --git a/include/block/aio.h b/include/block/aio.h
index e086e3b..9434665 100644
--- a/include/block/aio.h
+++ b/include/block/aio.h
@@ -435,6 +435,13 @@ static inline bool aio_node_check(AioContext *ctx, bool 
is_external)
 }
 
 /**
+ * @ctx: the aio context
+ *
+ * Return whether we are running in the I/O thread that manages @ctx.
+ */
+bool aio_context_in_iothread(AioContext *ctx);
+
+/**
  * aio_context_setup:
  * @ctx: the aio context
  *
diff --git a/iothread.c b/iothread.c
index f183d38..8d40bb0 100644
--- a/iothread.c
+++ b/iothread.c
@@ -20,6 +20,7 @@
 #include "qmp-commands.h"
 #include "qemu/error-report.h"
 #include "qemu/rcu.h"
+#include "qemu/main-loop.h"
 
 typedef ObjectClass IOThreadClass;
 
@@ -28,6 +29,13 @@ typedef ObjectClass IOThreadClass;
 #define IOTHREAD_CLASS(klass) \
OBJECT_CLASS_CHECK(IOThreadClass, klass, TYPE_IOTHREAD)
 
+static __thread IOThread *my_iothread;
+
+bool aio_context_in_iothread(AioContext *ctx)
+{
+return ctx == (my_iothread ? my_iothread->ctx : qemu_get_aio_context());
+}
+
 static void *iothread_run(void *opaque)
 {
 IOThread *iothread = opaque;
@@ -35,6 +43,7 @@ static void *iothread_run(void *opaque)
 
 rcu_register_thread();
 
+my_iothread = iothread;
 qemu_mutex_lock(&iothread->init_done_lock);
 iothread->thread_id = qemu_get_thread_id();
 qemu_cond_signal(&iothread->init_done_cond);
diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
index e922de9..187cee1 100644
--- a/stubs/Makefile.objs
+++ b/stubs/Makefile.objs
@@ -13,6 +13,7 @@ stub-obj-y += gdbstub.o
 stub-obj-y += get-fd.o
 stub-obj-y += get-next-serial.o
 stub-obj-y += get-vm-name.o
+stub-obj-y += iothread.o
 stub-obj-y += iothread-lock.o
 stub-obj-y += is-daemonized.o
 stub-obj-y += machine-init-done.o
diff --git a/stubs/iothread.c b/stubs/iothread.c
new file mode 100644
index 000..6c02323
--- /dev/null
+++ b/stubs/iothread.c
@@ -0,0 +1,8 @@
+#include "qemu/osdep.h"
+#include "block/aio.h"
+#include "qemu/main-loop.h"
+
+bool aio_context_in_iothread(AioContext *ctx)
+{
+return ctx == qemu_get_aio_context();
+}
-- 
1.8.3.1





[Qemu-devel] [PULL 15/15] qapi: Use anonymous bases in QMP flat unions

2016-03-18 Thread Markus Armbruster
From: Eric Blake 

Now that the generator supports it, we might as well use an
anonymous base rather than breaking out a single-use Base
structure, for all three of our current QMP flat unions.

Oddly enough, this change does not affect the resulting
introspection output (because we already inline the members of
a base type into an object, and had no independent use of the
base type reachable from a command).

The case_whitelist now has to list the name of an implicit
type; which is not too bad (consider it a feature if it makes
it harder for developers to make the whitelist grow :)

Signed-off-by: Eric Blake 
Message-Id: <1458254921-17042-16-git-send-email-ebl...@redhat.com>
Signed-off-by: Markus Armbruster 
---
 qapi-schema.json | 20 ---
 qapi/block-core.json | 98 
 qapi/introspect.json | 12 +--
 scripts/qapi.py  |  2 +-
 4 files changed, 53 insertions(+), 79 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index f253a37..88f9b81 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -753,9 +753,9 @@
   'data': ['x86', 'sparc', 'ppc', 'mips', 'tricore', 'other' ] }
 
 ##
-# @CpuInfoBase:
+# @CpuInfo:
 #
-# Common information about a virtual CPU
+# Information about a virtual CPU
 #
 # @CPU: the index of the virtual CPU
 #
@@ -776,18 +776,10 @@
 # Notes: @halted is a transient state that changes frequently.  By the time the
 #data is sent to the client, the guest may no longer be halted.
 ##
-{ 'struct': 'CpuInfoBase',
-  'data': {'CPU': 'int', 'current': 'bool', 'halted': 'bool',
-   'qom_path': 'str', 'thread_id': 'int', 'arch': 'CpuInfoArch' } }
-
-##
-# @CpuInfo:
-#
-# Information about a virtual CPU
-#
-# Since: 0.14.0
-##
-{ 'union': 'CpuInfo', 'base': 'CpuInfoBase', 'discriminator': 'arch',
+{ 'union': 'CpuInfo',
+  'base': {'CPU': 'int', 'current': 'bool', 'halted': 'bool',
+   'qom_path': 'str', 'thread_id': 'int', 'arch': 'CpuInfoArch' },
+  'discriminator': 'arch',
   'data': { 'x86': 'CpuInfoX86',
 'sparc': 'CpuInfoSPARC',
 'ppc': 'CpuInfoPPC',
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 9bf1b22..b1cf77d 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -1644,57 +1644,6 @@
 'vmdk', 'vpc', 'vvfat' ] }
 
 ##
-# @BlockdevOptionsBase
-#
-# Options that are available for all block devices, independent of the block
-# driver.
-#
-# @driver:block driver name
-# @id:#optional id by which the new block device can be referred 
to.
-# This option is only allowed on the top level of blockdev-add.
-# A BlockBackend will be created by blockdev-add if and only if
-# this option is given.
-# @node-name: #optional the name of a block driver state node (Since 2.0).
-# This option is required on the top level of blockdev-add if
-# the @id option is not given there.
-# @discard:   #optional discard-related options (default: ignore)
-# @cache: #optional cache-related options
-# @aio:   #optional AIO backend (default: threads)
-# @rerror:#optional how to handle read errors on the device
-# (default: report)
-# @werror:#optional how to handle write errors on the device
-# (default: enospc)
-# @read-only: #optional whether the block device should be read-only
-# (default: false)
-# @stats-account-invalid: #optional whether to include invalid
-# operations when computing last access statistics
-# (default: true) (Since 2.5)
-# @stats-account-failed: #optional whether to include failed
-# operations when computing latency and last
-# access statistics (default: true) (Since 2.5)
-# @stats-intervals: #optional list of intervals for collecting I/O
-#   statistics, in seconds (default: none) (Since 2.5)
-# @detect-zeroes: #optional detect and optimize zero writes (Since 2.1)
-# (default: off)
-#
-# Since: 1.7
-##
-{ 'struct': 'BlockdevOptionsBase',
-  'data': { 'driver': 'BlockdevDriver',
-'*id': 'str',
-'*node-name': 'str',
-'*discard': 'BlockdevDiscardOptions',
-'*cache': 'BlockdevCacheOptions',
-'*aio': 'BlockdevAioOptions',
-'*rerror': 'BlockdevOnError',
-'*werror': 'BlockdevOnError',
-'*read-only': 'bool',
-'*stats-account-invalid': 'bool',
-'*stats-account-failed': 'bool',
-'*stats-intervals': ['int'],
-'*detect-zeroes': 'BlockdevDetectZeroesOptions' } }
-
-##
 # @BlockdevOptionsFile
 #
 # Driver specific block device options for the file backend and similar
@@ -2070,12 +2019,55 @@
 ##
 # @BlockdevOptions
 #
-# Options for creating a block device.
+# Options for creating a block devic

Re: [Qemu-devel] [PATCH 0/4] Tweaks around virtio-blk start/stop

2016-03-18 Thread Cornelia Huck
On Wed, 16 Mar 2016 12:09:02 +0100
Paolo Bonzini  wrote:

> On 16/03/2016 11:49, Christian Borntraeger wrote:

> > #3  0x800b713e in virtio_blk_data_plane_start (s=0xba232d80) at 
> > /home/cborntra/REPOS/qemu/hw/block/dataplane/virtio-blk.c:224
> > #4  0x800b4ea0 in virtio_blk_handle_output (vdev=0xb9eee7e8, 
> > vq=0xba305270) at /home/cborntra/REPOS/qemu/hw/block/virtio-blk.c:590
> > #5  0x800ef3dc in virtio_queue_notify_vq (vq=0xba305270) at 
> > /home/cborntra/REPOS/qemu/hw/virtio/virtio.c:1095
> > #6  0x800f1c9c in virtio_queue_host_notifier_read (n=0xba3052c8) at 
> > /home/cborntra/REPOS/qemu/hw/virtio/virtio.c:1785
> > #7  0x800f1e14 in virtio_queue_set_host_notifier_fd_handler 
> > (vq=0xba305270, assign=false, set_handler=false) at 
> > /home/cborntra/REPOS/qemu/hw/virtio/virtio.c:1817
> > #8  0x80109c50 in virtio_ccw_set_guest2host_notifier 
> > (dev=0xb9eed6a0, n=0, assign=false, set_handler=false) at 
> > /home/cborntra/REPOS/qemu/hw/s390x/virtio-ccw.c:97
> > #9  0x80109ef2 in virtio_ccw_stop_ioeventfd (dev=0xb9eed6a0) at 
> > /home/cborntra/REPOS/qemu/hw/s390x/virtio-ccw.c:154
> 
> One bug is here: virtio_ccw_stop_ioeventfd, in this case, should pass
> assign=true to virtio_ccw_set_guest2host_notifier.  (Assuming my
> understanding of assign=true is correct; I think it means "I'm going to
> set up another host notifier handler").

Hm... I copied these semantics from virtio-pci, and they still seem to
be the same. I wonder why we never saw this on virtio-pci?

> In dataplane, instead, all calls to
> virtio_queue_set_host_notifier_fd_handler and
> virtio_queue_aio_set_host_notifier_handler should have assign=true.  The
> ioeventfd is just being moved from one aiocontext to another.

How can a transport know where they are called from?




Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it

2016-03-18 Thread Peter Maydell
On 17 March 2016 at 20:14, Richard Henderson  wrote:
> That works for all of the hosts we care about (ELF and MachO).

...Windows is something other than both of those, right?
Or does it use ELF these days?

thanks
-- PMM



[Qemu-devel] [PULL 02/40] ivshmem-server: Fix and clean up command line help

2016-03-18 Thread Markus Armbruster
Burying error messages in ~20 lines of usage help is bad form.  Print
a single line pointing to -h instead.

Print -h help to stdout rather than stderr.  Fix default of -p.  Clean
up the help text a bit.

Signed-off-by: Markus Armbruster 
Reviewed-by: Marc-André Lureau 
Message-Id: <1458066895-20632-3-git-send-email-arm...@redhat.com>
---
 contrib/ivshmem-server/main.c | 84 +--
 1 file changed, 41 insertions(+), 43 deletions(-)

diff --git a/contrib/ivshmem-server/main.c b/contrib/ivshmem-server/main.c
index cca1061..3332a8c 100644
--- a/contrib/ivshmem-server/main.c
+++ b/contrib/ivshmem-server/main.c
@@ -33,31 +33,32 @@ typedef struct IvshmemServerArgs {
 unsigned n_vectors;
 } IvshmemServerArgs;
 
-/* show ivshmem_server_usage and exit with given error code */
 static void
-ivshmem_server_usage(const char *name, int code)
+ivshmem_server_usage(const char *progname)
 {
-fprintf(stderr, "%s [opts]\n", name);
-fprintf(stderr, "  -h: show this help\n");
-fprintf(stderr, "  -v: verbose mode\n");
-fprintf(stderr, "  -F: foreground mode (default is to daemonize)\n");
-fprintf(stderr, "  -p : path to the PID file (used in daemon\n"
-" mode only).\n"
-" Default=%s\n", IVSHMEM_SERVER_DEFAULT_SHM_PATH);
-fprintf(stderr, "  -S : path to the unix socket\n"
-" to listen to.\n"
-" Default=%s\n", 
IVSHMEM_SERVER_DEFAULT_UNIX_SOCK_PATH);
-fprintf(stderr, "  -m : path to the shared memory.\n"
-" The path corresponds to a POSIX shm name or a\n"
-" hugetlbfs mount point.\n"
-" default=%s\n", IVSHMEM_SERVER_DEFAULT_SHM_PATH);
-fprintf(stderr, "  -l : size of shared memory in bytes. The suffix\n"
-" K, M and G can be used (ex: 1K means 1024).\n"
-" default=%u\n", IVSHMEM_SERVER_DEFAULT_SHM_SIZE);
-fprintf(stderr, "  -n : number of vectors.\n"
-" default=%u\n", IVSHMEM_SERVER_DEFAULT_N_VECTORS);
+printf("Usage: %s [OPTION]...\n"
+   "  -h: show this help\n"
+   "  -v: verbose mode\n"
+   "  -F: foreground mode (default is to daemonize)\n"
+   "  -p : path to the PID file (used in daemon mode only)\n"
+   " default " IVSHMEM_SERVER_DEFAULT_PID_FILE "\n"
+   "  -S : path to the unix socket to listen to\n"
+   " default " IVSHMEM_SERVER_DEFAULT_UNIX_SOCK_PATH "\n"
+   "  -m : POSIX shared memory object name or a hugetlbfs 
mount point\n"
+   " default " IVSHMEM_SERVER_DEFAULT_SHM_PATH "\n"
+   "  -l : size of shared memory in bytes\n"
+   " suffixes K, M and G can be used, e.g. 1K means 1024\n"
+   " default %u\n"
+   "  -n : number of vectors\n"
+   " default %u\n",
+   progname, IVSHMEM_SERVER_DEFAULT_SHM_SIZE,
+   IVSHMEM_SERVER_DEFAULT_N_VECTORS);
+}
 
-exit(code);
+static void
+ivshmem_server_help(const char *progname)
+{
+fprintf(stderr, "Try '%s -h' for more information.\n", progname);
 }
 
 /* parse the program arguments, exit on error */
@@ -68,20 +69,12 @@ ivshmem_server_parse_args(IvshmemServerArgs *args, int 
argc, char *argv[])
 unsigned long long v;
 Error *err = NULL;
 
-while ((c = getopt(argc, argv,
-   "h"  /* help */
-   "v"  /* verbose */
-   "F"  /* foreground */
-   "p:" /* pid_file */
-   "S:" /* unix_socket_path */
-   "m:" /* shm_path */
-   "l:" /* shm_size */
-   "n:" /* n_vectors */
-  )) != -1) {
+while ((c = getopt(argc, argv, "hvFp:S:m:l:n:")) != -1) {
 
 switch (c) {
 case 'h': /* help */
-ivshmem_server_usage(argv[0], 0);
+ivshmem_server_usage(argv[0]);
+exit(0);
 break;
 
 case 'v': /* verbose */
@@ -92,36 +85,39 @@ ivshmem_server_parse_args(IvshmemServerArgs *args, int 
argc, char *argv[])
 args->foreground = 1;
 break;
 
-case 'p': /* pid_file */
+case 'p': /* pid file */
 args->pid_file = optarg;
 break;
 
-case 'S': /* unix_socket_path */
+case 'S': /* unix socket path */
 args->unix_socket_path = optarg;
 break;
 
-case 'm': /* shm_path */
+case 'm': /* shm path */
 args->shm_path = optarg;
 break;
 
-case 'l': /* shm_size */
+case 'l': /* shm size */
 parse_option_size("shm_size", optarg, &args->shm_size, &err);
 if (err) {
 error_report_err(err);
-ivshmem_server_usage(argv[0], 1);
+ivshmem_server_help(argv[0]);
+   

Re: [Qemu-devel] [PATCH 0/4] Tweaks around virtio-blk start/stop

2016-03-18 Thread Cornelia Huck
On Wed, 16 Mar 2016 13:32:59 +0100
Paolo Bonzini  wrote:

> On 16/03/2016 13:22, Cornelia Huck wrote:
> >> > Yeah, it doesn't help that the functions are underdocumented (as in the
> >> > "assign" parameter above).
> > My understanding is:
> > 
> > - 'assign': set up a new notifier (true) or disable it (false)
> > - 'set_handler': use our handler (true) or have it handled elsewhere
> >   (false)
> 
> Right.  So if we're setting up a new notifier in
> virtio_queue_aio_set_host_notifier_handler, virtio_pci_stop_ioeventfd should

...do what? ;)

> 
> > > > I don't think the ->set_host_notifiers() api really allows for this.
> > > 
> > > I think it does, assign is the last argument to k->set_host_notifier().
> > 
> > This depends on whether we want 'assign' to clean up any old notifiers
> > before setting up new ones. I think we want different behaviour for
> > dataplane and vhost.
> 
> I think dataplane and vhost are the same.
> 
> The question is whether ioeventfd=off,vhost=on or
> ioeventfd=off,dataplane=on are valid combinations; I think they aren't.

We should disallow that even temporary, then.

(This would imply that we need to drop the _stop_ioeventfd() call in
->set_host_notifier(), correct?)

> If they aren't, it should be okay to remove the
> virtio_queue_host_notifier_read call in
> virtio_queue_set_host_notifier_fd_handler and
> virtio_queue_aio_set_host_notifier_handler.  That's because a handler
> for the notifier will always be set _somewhere_.  It could be the usual
> ioeventfd handler, the vhost handler or the dataplane handler, but one
> will be there.

It should; but we probably need to do a final read when we stop the
ioeventfd.




[Qemu-devel] [PULL 14/29] block: Move some bdrv_*_all() functions to BB

2016-03-18 Thread Kevin Wolf
From: Max Reitz 

Move bdrv_commit_all() and bdrv_flush_all() to the BlockBackend level.

Signed-off-by: Max Reitz 
Signed-off-by: Kevin Wolf 
---
 block.c | 20 
 block/block-backend.c   | 44 ++--
 block/io.c  | 20 
 include/block/block.h   |  2 --
 stubs/Makefile.objs |  2 +-
 stubs/bdrv-commit-all.c |  8 
 stubs/blk-commit-all.c  |  8 
 7 files changed, 47 insertions(+), 57 deletions(-)
 delete mode 100644 stubs/bdrv-commit-all.c
 create mode 100644 stubs/blk-commit-all.c

diff --git a/block.c b/block.c
index 582a9e8..91c006a 100644
--- a/block.c
+++ b/block.c
@@ -2521,26 +2521,6 @@ ro_cleanup:
 return ret;
 }
 
-int bdrv_commit_all(void)
-{
-BlockDriverState *bs;
-
-QTAILQ_FOREACH(bs, &bdrv_states, device_list) {
-AioContext *aio_context = bdrv_get_aio_context(bs);
-
-aio_context_acquire(aio_context);
-if (bs->drv && bs->backing) {
-int ret = bdrv_commit(bs);
-if (ret < 0) {
-aio_context_release(aio_context);
-return ret;
-}
-}
-aio_context_release(aio_context);
-}
-return 0;
-}
-
 /*
  * Return values:
  * 0- success
diff --git a/block/block-backend.c b/block/block-backend.c
index 68f3662..b3c3d39 100644
--- a/block/block-backend.c
+++ b/block/block-backend.c
@@ -904,11 +904,6 @@ int blk_flush(BlockBackend *blk)
 return bdrv_flush(blk->bs);
 }
 
-int blk_flush_all(void)
-{
-return bdrv_flush_all();
-}
-
 void blk_drain(BlockBackend *blk)
 {
 if (blk->bs) {
@@ -1357,5 +1352,42 @@ BlockBackendRootState *blk_get_root_state(BlockBackend 
*blk)
 
 int blk_commit_all(void)
 {
-return bdrv_commit_all();
+BlockBackend *blk = NULL;
+
+while ((blk = blk_all_next(blk)) != NULL) {
+AioContext *aio_context = blk_get_aio_context(blk);
+
+aio_context_acquire(aio_context);
+if (blk_is_inserted(blk) && blk->bs->backing) {
+int ret = bdrv_commit(blk->bs);
+if (ret < 0) {
+aio_context_release(aio_context);
+return ret;
+}
+}
+aio_context_release(aio_context);
+}
+return 0;
+}
+
+int blk_flush_all(void)
+{
+BlockBackend *blk = NULL;
+int result = 0;
+
+while ((blk = blk_all_next(blk)) != NULL) {
+AioContext *aio_context = blk_get_aio_context(blk);
+int ret;
+
+aio_context_acquire(aio_context);
+if (blk_is_inserted(blk)) {
+ret = blk_flush(blk);
+if (ret < 0 && !result) {
+result = ret;
+}
+}
+aio_context_release(aio_context);
+}
+
+return result;
 }
diff --git a/block/io.c b/block/io.c
index a69bfc4..5f9b6d6 100644
--- a/block/io.c
+++ b/block/io.c
@@ -1445,26 +1445,6 @@ int coroutine_fn bdrv_co_write_zeroes(BlockDriverState 
*bs,
  BDRV_REQ_ZERO_WRITE | flags);
 }
 
-int bdrv_flush_all(void)
-{
-BlockDriverState *bs = NULL;
-int result = 0;
-
-while ((bs = bdrv_next(bs))) {
-AioContext *aio_context = bdrv_get_aio_context(bs);
-int ret;
-
-aio_context_acquire(aio_context);
-ret = bdrv_flush(bs);
-if (ret < 0 && !result) {
-result = ret;
-}
-aio_context_release(aio_context);
-}
-
-return result;
-}
-
 typedef struct BdrvCoGetBlockStatusData {
 BlockDriverState *bs;
 BlockDriverState *base;
diff --git a/include/block/block.h b/include/block/block.h
index eaa6426..ea5be0f 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -274,7 +274,6 @@ int64_t bdrv_get_allocated_file_size(BlockDriverState *bs);
 void bdrv_get_geometry(BlockDriverState *bs, uint64_t *nb_sectors_ptr);
 void bdrv_refresh_limits(BlockDriverState *bs, Error **errp);
 int bdrv_commit(BlockDriverState *bs);
-int bdrv_commit_all(void);
 int bdrv_change_backing_file(BlockDriverState *bs,
 const char *backing_file, const char *backing_fmt);
 void bdrv_register(BlockDriver *bdrv);
@@ -373,7 +372,6 @@ int bdrv_inactivate_all(void);
 /* Ensure contents are flushed to disk.  */
 int bdrv_flush(BlockDriverState *bs);
 int coroutine_fn bdrv_co_flush(BlockDriverState *bs);
-int bdrv_flush_all(void);
 void bdrv_close_all(void);
 void bdrv_drain(BlockDriverState *bs);
 void bdrv_drain_all(void);
diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
index e922de9..9d9f1d0 100644
--- a/stubs/Makefile.objs
+++ b/stubs/Makefile.objs
@@ -1,5 +1,5 @@
 stub-obj-y += arch-query-cpu-def.o
-stub-obj-y += bdrv-commit-all.o
+stub-obj-y += blk-commit-all.o
 stub-obj-y += blockdev-close-all-bdrv-states.o
 stub-obj-y += clock-warp.o
 stub-obj-y += cpu-get-clock.o
diff --git a/stubs/bdrv-commit-all.c b/stubs/bdrv-commit-all.c
deleted file mode 100644
index bf84a1d..000
--- a/stubs/bdrv-commit-all.c
+++ /dev/null
@@ -1,8 +0,0 @@
-#

[Qemu-devel] [PULL 18/40] ivshmem: Clean up register callbacks

2016-03-18 Thread Markus Armbruster
Signed-off-by: Markus Armbruster 
Reviewed-by: Marc-André Lureau 
Message-Id: <1458066895-20632-19-git-send-email-arm...@redhat.com>
---
 hw/misc/ivshmem.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index 51ad255..1debce3 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -121,12 +121,10 @@ static inline uint32_t ivshmem_has_feature(IVShmemState 
*ivs,
 return (ivs->features & (1 << feature));
 }
 
-/* accessing registers - based on rtl8139 */
 static void ivshmem_update_irq(IVShmemState *s)
 {
 PCIDevice *d = PCI_DEVICE(s);
-int isr;
-isr = (s->intrstatus & s->intrmask) & 0x;
+uint32_t isr = s->intrstatus & s->intrmask;
 
 /* don't print ISR resets */
 if (isr) {
@@ -134,7 +132,7 @@ static void ivshmem_update_irq(IVShmemState *s)
 isr ? 1 : 0, s->intrstatus, s->intrmask);
 }
 
-pci_set_irq(d, (isr != 0));
+pci_set_irq(d, isr != 0);
 }
 
 static void ivshmem_IntrMask_write(IVShmemState *s, uint32_t val)
@@ -142,7 +140,6 @@ static void ivshmem_IntrMask_write(IVShmemState *s, 
uint32_t val)
 IVSHMEM_DPRINTF("IntrMask write(w) val = 0x%04x\n", val);
 
 s->intrmask = val;
-
 ivshmem_update_irq(s);
 }
 
@@ -151,7 +148,6 @@ static uint32_t ivshmem_IntrMask_read(IVShmemState *s)
 uint32_t ret = s->intrmask;
 
 IVSHMEM_DPRINTF("intrmask read(w) val = 0x%04x\n", ret);
-
 return ret;
 }
 
@@ -160,7 +156,6 @@ static void ivshmem_IntrStatus_write(IVShmemState *s, 
uint32_t val)
 IVSHMEM_DPRINTF("IntrStatus write(w) val = 0x%04x\n", val);
 
 s->intrstatus = val;
-
 ivshmem_update_irq(s);
 }
 
@@ -170,9 +165,7 @@ static uint32_t ivshmem_IntrStatus_read(IVShmemState *s)
 
 /* reading ISR clears all interrupts */
 s->intrstatus = 0;
-
 ivshmem_update_irq(s);
-
 return ret;
 }
 
-- 
2.4.3




Re: [Qemu-devel] [PATCH v12 2/3] quorum: implement bdrv_add_child() and bdrv_del_child()

2016-03-18 Thread Wen Congyang
On 03/17/2016 06:07 PM, Alberto Garcia wrote:
> On Thu 17 Mar 2016 10:56:09 AM CET, Wen Congyang wrote:
>>> We should have the failure modes documented, and how you'll use it
>>> after failover etc Without that it's really difficult to tell if this
>>> naming is right.
>>
>> For COLO, children.0 is the real disk, children.1 is replication
>> driver.  After failure, children.1 will be removed by the user. If we
>> want to continue do COLO, we need add a new children.1 again.
> 
> What if children.0 fails ?

For COLO, reading from children.1 always fails. if children.0 fails, it
means that reading from the disk fails. The guest vm will see the I/O error.

Thanks
Wen Congyang

> 
> Berto
> 
> 
> .
> 






Re: [Qemu-devel] [PATCH v3 19/40] ivshmem: Clean up MSI-X conditions

2016-03-18 Thread Marc-André Lureau
On Tue, Mar 15, 2016 at 7:34 PM, Markus Armbruster  wrote:
> There are three predicates related to MSI-X:
>
> * ivshmem_has_feature(s, IVSHMEM_MSI) is true unless the non-MSI-X
>   variant of the device is selected with msi=off.
>
> * msix_present() is true when the device has the PCI capability MSI-X.
>   It's initially false, and becomes true during successful realize of
>   the MSI-X variant of the device.  Thus, it's the same as
>   ivshmem_has_feature(s, IVSHMEM_MSI) for realized devices.
>
> * msix_enabled() is true when msix_present() is true and guest software
>   has enabled MSI-X.
>
> Code that differs between the non-MSI-X and the MSI-X variant of the
> device needs to be guarded by ivshmem_has_feature(s, IVSHMEM_MSI) or
> by msix_present(), except the latter works only for realized devices.
>
> Code that depends on whether MSI-X is in use needs to be guarded with
> msix_enabled().
>
> Code review led me to two minor messes:
>
> * ivshmem_vector_notify() calls msix_notify() even when
>   !msix_enabled(), unlike most other MSI-X-capable devices.  As far as
>   I can tell, msix_notify() does nothing when !msix_enabled().  Add
>   the guard anyway.
>
> * Most callers of ivshmem_use_msix() guard it with
>   ivshmem_has_feature(s, IVSHMEM_MSI).  Not necessary, because
>   ivshmem_use_msix() does nothing when !msix_present().  That's
>   ivshmem's only use of msix_present(), though.  Guard it
>   consistently, and drop the now redundant msix_present() check.
>   While there, rename ivshmem_use_msix() to ivshmem_msix_vector_use().
>
> Signed-off-by: Markus Armbruster 

Reviewed-by: Marc-André Lureau 


> ---
>  hw/misc/ivshmem.c | 22 ++
>  1 file changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
> index 1debce3..abcb1c1 100644
> --- a/hw/misc/ivshmem.c
> +++ b/hw/misc/ivshmem.c
> @@ -274,7 +274,9 @@ static void ivshmem_vector_notify(void *opaque)
>
>  IVSHMEM_DPRINTF("interrupt on vector %p %d\n", pdev, vector);
>  if (ivshmem_has_feature(s, IVSHMEM_MSI)) {
> -msix_notify(pdev, vector);
> +if (msix_enabled(pdev)) {
> +msix_notify(pdev, vector);
> +}
>  } else {
>  ivshmem_IntrStatus_write(s, 1);
>  }
> @@ -713,16 +715,11 @@ static void ivshmem_check_version(void *opaque, const 
> uint8_t * buf, int size)
>  /* Select the MSI-X vectors used by device.
>   * ivshmem maps events to vectors statically, so
>   * we just enable all vectors on init and after reset. */
> -static void ivshmem_use_msix(IVShmemState * s)
> +static void ivshmem_msix_vector_use(IVShmemState *s)
>  {
>  PCIDevice *d = PCI_DEVICE(s);
>  int i;
>
> -IVSHMEM_DPRINTF("%s, msix present: %d\n", __func__, msix_present(d));
> -if (!msix_present(d)) {
> -return;
> -}
> -
>  for (i = 0; i < s->vectors; i++) {
>  msix_vector_use(d, i);
>  }
> @@ -734,7 +731,9 @@ static void ivshmem_reset(DeviceState *d)
>
>  s->intrstatus = 0;
>  s->intrmask = 0;
> -ivshmem_use_msix(s);
> +if (ivshmem_has_feature(s, IVSHMEM_MSI)) {
> +ivshmem_msix_vector_use(s);
> +}
>  }
>
>  static int ivshmem_setup_interrupts(IVShmemState *s)
> @@ -748,7 +747,7 @@ static int ivshmem_setup_interrupts(IVShmemState *s)
>  }
>
>  IVSHMEM_DPRINTF("msix initialized (%d vectors)\n", s->vectors);
> -ivshmem_use_msix(s);
> +ivshmem_msix_vector_use(s);
>  }
>
>  return 0;
> @@ -1040,9 +1039,8 @@ static int ivshmem_post_load(void *opaque, int 
> version_id)
>  IVShmemState *s = opaque;
>
>  if (ivshmem_has_feature(s, IVSHMEM_MSI)) {
> -ivshmem_use_msix(s);
> +ivshmem_msix_vector_use(s);
>  }
> -
>  return 0;
>  }
>
> @@ -1070,7 +1068,7 @@ static int ivshmem_load_old(QEMUFile *f, void *opaque, 
> int version_id)
>
>  if (ivshmem_has_feature(s, IVSHMEM_MSI)) {
>  msix_load(pdev, f);
> -ivshmem_use_msix(s);
> +ivshmem_msix_vector_use(s);
>  } else {
>  s->intrstatus = qemu_get_be32(f);
>  s->intrmask = qemu_get_be32(f);
> --
> 2.4.3
>
>



-- 
Marc-André Lureau



[Qemu-devel] [PULL 20/40] ivshmem: Leave INTx alone when using MSI-X

2016-03-18 Thread Markus Armbruster
The ivshmem device can either use MSI-X or legacy INTx for interrupts.

With MSI-X enabled, peer interrupt events trigger an MSI as they
should.  But software can still raise INTx via interrupt status and
mask register in BAR 0.  This is explicitly prohibited by PCI Local
Bus Specification Revision 3.0, section 6.8.3.3:

While enabled for MSI or MSI-X operation, a function is prohibited
from using its INTx# pin (if implemented) to request service (MSI,
MSI-X, and INTx# are mutually exclusive).

Fix the device model to leave INTx alone when using MSI-X.

Document that we claim to use INTx in config space even when we don't.
Unlike other devices, ivshmem does *not* use INTx when configured for
MSI-X and MSI-X isn't enabled by software.

Signed-off-by: Markus Armbruster 
Reviewed-by: Marc-André Lureau 
Reviewed-by: Paolo Bonzini 
Message-Id: <1458066895-20632-21-git-send-email-arm...@redhat.com>
---
 hw/misc/ivshmem.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index abcb1c1..65e3a76 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -126,6 +126,11 @@ static void ivshmem_update_irq(IVShmemState *s)
 PCIDevice *d = PCI_DEVICE(s);
 uint32_t isr = s->intrstatus & s->intrmask;
 
+/* No INTx with msi=on, whether the guest enabled MSI-X or not */
+if (ivshmem_has_feature(s, IVSHMEM_MSI)) {
+return;
+}
+
 /* don't print ISR resets */
 if (isr) {
 IVSHMEM_DPRINTF("Set IRQ to %d (%04x %04x)\n",
@@ -873,6 +878,10 @@ static void pci_ivshmem_realize(PCIDevice *dev, Error 
**errp)
 pci_conf = dev->config;
 pci_conf[PCI_COMMAND] = PCI_COMMAND_IO | PCI_COMMAND_MEMORY;
 
+/*
+ * Note: we don't use INTx with IVSHMEM_MSI at all, so this is a
+ * bald-faced lie then.  But it's a backwards compatible lie.
+ */
 pci_config_set_interrupt_pin(pci_conf, 1);
 
 memory_region_init_io(&s->ivshmem_mmio, OBJECT(s), &ivshmem_mmio_ops, s,
-- 
2.4.3




Re: [Qemu-devel] [PATCH 0/4] Tweaks around virtio-blk start/stop

2016-03-18 Thread Paolo Bonzini


On 17/03/2016 17:08, Christian Borntraeger wrote:
> Good (or bad?) news is the assert also triggers on F23, it just seems
> to take longer.

I guess good news, because we can rule out the kernel (not that I
believed it was a kernel problem, but the thought is always there in
the background...).

The interaction between ioeventfd and dataplane is too complicated.  I
think if we get rid of the start/stop ioeventfd calls (just set up the
ioeventfd as soon as possible and then only set/clear the handlers)
things would be much simpler.

I'll see if I can produce something based on Conny's patches, which are
already a start.  Today I had a short day so I couldn't play with the
bug; out of curiosity, does the bug reproduce with her work + patch 4
from this series + the reentrancy assertion?

Paolo



Re: [Qemu-devel] [PATCH 6/9] log: log QMP commands and replies

2016-03-18 Thread Paolo Bonzini


On 16/03/2016 14:09, Denis V. Lunev wrote:
> really interesting approach with a good place to get in.
> But we will need to modify this a infrastructure a bit.
> Af far as I can see only data from VM to outside world
> is logged. Data being 'read' should be logged too as far
> as I could understand.

Hmm, you're right.  As a start, let's document in the release notes that
the format of the log file is subject to change.

Paolo



[Qemu-devel] [PATCH v2 01/10] ppc: Update SPR definitions

2016-03-18 Thread Cédric Le Goater
From: Benjamin Herrenschmidt 

Add definitions for additional SPR numbers and SPR bit definitions
that will be relevant for subsequent improvements to POWER8 emulation

Also fix the definition of LPIDR which was incorrect (and is different
for server and embedded).

Signed-off-by: Benjamin Herrenschmidt 
Reviewed-by: Thomas Huth 
---
 target-ppc/cpu.h | 54 +++---
 1 file changed, 47 insertions(+), 7 deletions(-)

diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 8d90d862de17..9ce301f18922 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -474,9 +474,17 @@ struct ppc_slb_t {
 #define MSR_RI   1  /* Recoverable interrupt1*/
 #define MSR_LE   0  /* Little-endian mode   1 hflags */
 
-#define LPCR_ILE (1 << (63-38))
-#define LPCR_AIL_SHIFT (63-40)  /* Alternate interrupt location */
-#define LPCR_AIL (3 << LPCR_AIL_SHIFT)
+/* LPCR bits */
+#define LPCR_VPM0 (1ull << (63 - 0))
+#define LPCR_VPM1 (1ull << (63 - 1))
+#define LPCR_ISL  (1ull << (63 - 2))
+#define LPCR_KBV  (1ull << (63 - 3))
+#define LPCR_ILE  (1ull << (63 - 38))
+#define LPCR_MER  (1ull << (63 - 52))
+#define LPCR_LPES0(1ull << (63 - 60))
+#define LPCR_LPES1(1ull << (63 - 61))
+#define LPCR_AIL_SHIFT(63 - 40)  /* Alternate interrupt location */
+#define LPCR_AIL  (3ull << LPCR_AIL_SHIFT)
 
 #define msr_sf   ((env->msr >> MSR_SF)   & 1)
 #define msr_isf  ((env->msr >> MSR_ISF)  & 1)
@@ -1381,6 +1389,10 @@ static inline int cpu_mmu_index (CPUPPCState *env, bool 
ifetch)
 #define SPR_MPC_ICTRL (0x09E)
 #define SPR_MPC_BAR   (0x09F)
 #define SPR_PSPB  (0x09F)
+#define SPR_DAWR  (0x0B4)
+#define SPR_RPR   (0x0BA)
+#define SPR_DAWRX (0x0BC)
+#define SPR_HFSCR (0x0BE)
 #define SPR_VRSAVE(0x100)
 #define SPR_USPRG0(0x100)
 #define SPR_USPRG1(0x101)
@@ -1435,19 +1447,25 @@ static inline int cpu_mmu_index (CPUPPCState *env, bool 
ifetch)
 #define SPR_HSRR1 (0x13B)
 #define SPR_BOOKE_IAC4(0x13B)
 #define SPR_BOOKE_DAC1(0x13C)
-#define SPR_LPIDR (0x13D)
+#define SPR_MMCRH (0x13C)
 #define SPR_DABR2 (0x13D)
 #define SPR_BOOKE_DAC2(0x13D)
+#define SPR_TFMR  (0x13D)
 #define SPR_BOOKE_DVC1(0x13E)
 #define SPR_LPCR  (0x13E)
 #define SPR_BOOKE_DVC2(0x13F)
+#define SPR_LPIDR (0x13F)
 #define SPR_BOOKE_TSR (0x150)
+#define SPR_HMER  (0x150)
+#define SPR_HMEER (0x151)
 #define SPR_PCR   (0x152)
+#define SPR_BOOKE_LPIDR   (0x152)
 #define SPR_BOOKE_TCR (0x154)
 #define SPR_BOOKE_TLB0PS  (0x158)
 #define SPR_BOOKE_TLB1PS  (0x159)
 #define SPR_BOOKE_TLB2PS  (0x15A)
 #define SPR_BOOKE_TLB3PS  (0x15B)
+#define SPR_AMOR  (0x15D)
 #define SPR_BOOKE_MAS7_MAS3   (0x174)
 #define SPR_BOOKE_IVOR0   (0x190)
 #define SPR_BOOKE_IVOR1   (0x191)
@@ -1667,6 +1685,7 @@ static inline int cpu_mmu_index (CPUPPCState *env, bool 
ifetch)
 #define SPR_RCPU_L2U_RA3  (0x32B)
 #define SPR_TAR   (0x32F)
 #define SPR_VTB   (0x351)
+#define SPR_MMCRC (0x353)
 #define SPR_440_INV0  (0x370)
 #define SPR_440_INV1  (0x371)
 #define SPR_440_INV2  (0x372)
@@ -1705,6 +1724,7 @@ static inline int cpu_mmu_index (CPUPPCState *env, bool 
ifetch)
 #define SPR_440_DVLIM (0x398)
 #define SPR_750_WPAR  (0x399)
 #define SPR_440_IVLIM (0x399)
+#define SPR_TSCR  (0x399)
 #define SPR_750_DMAU  (0x39A)
 #define SPR_750_DMAL  (0x39B)
 #define SPR_440_RSTCFG(0x39B)
@@ -1879,9 +1899,10 @@ static inline int cpu_mmu_index (CPUPPCState *env, bool 
ifetch)
 #define   L1CSR1_ICE   0x0001  /* Instruction Cache Enable */
 
 /* HID0 bits */
-#define HID0_DEEPNAP(1 << 24)
-#define HID0_DOZE   (1 << 23)
-#define HID0_NAP(1 << 22)
+#define HID0_DEEPNAP(1 << 24)   /* pre-2.06 */
+#define HID0_DOZE   (1 << 23)   /* pre-2.06 */
+#define HID0_NAP(1 << 22)   /* pre-2.06 */
+#define HID0_HILE   (1ull << (63 - 19)) /* POWER8 */
 
 /*/
 /* PowerPC Instructions types definitions*/
@@ -2230,6 +2251,25 @@ enum {
 PCR_TM_DIS  = 1ull << (63-2), /* Trans. memory disable (POWER8) */
 };
 
+/* HMER/HMEER */
+enum {
+HMER_MALFUNCTION_ALERT  = 1ull << (63 - 0),
+HMER_PROC_RECV_DONE = 1ull << (63 - 2),
+HMER_PROC_RECV_ERROR_MASKED = 1ull << (63 - 3),
+HMER_TFAC_ERROR = 1ull << (63 - 4),
+HMER_TFMR_PARITY_ERROR  = 1ull << (63 - 5),
+HM

Re: [Qemu-devel] [PATCH 3/5] tcg: always keep jump target and tb->jmp_next consistent

2016-03-18 Thread Sergey Fedorov

On 17/03/16 22:31, Paolo Bonzini wrote:


On 17/03/2016 18:57, Richard Henderson wrote:

@@ -951,18 +959,10 @@ static inline void tb_jmp_remove(TranslationBlock *tb, 
int n)
  }
  /* now we can suppress tb(n) from the list */
  *ptb = tb->jmp_next[n];
-
-tb->jmp_next[n] = NULL;
+tb_reset_jump(tb, n);

What's the motivation here?  This implies an extra cache flush.
Where were we resetting the jump previously?  Or is this a bug
in that we *weren't* resetting the jump previously?

Indeed I think this patch can be removed if it has a performance effect
on machines that require icache invalidation.  If it doesn't, it would
be just a small code simplification.


In fact, tb_jmp_remove() is only supposed to remove the TB from a list 
of all TB's jumping to the same TB which is n-th jump destination of the 
given TB. This function is only called in tb_phys_invalidate() for the 
TB being invalidated. Thus we don't have to patch that TB anymore. We 
don't even have to do "tb->jmp_next[n] = NULL" here.


Probably it's time to audit the code that handles direct jumping and 
clean-up/document/rename things to make it more easy to understand? :)


Kind regards,
Sergey



Re: [Qemu-devel] [PATCH 1/4] hw/audio: QOM'ify cs4231.c

2016-03-18 Thread Paolo Bonzini


On 16/03/2016 10:24, xiaoqiang zhao wrote:
> Drop the old SysBus init function and use instance_init
> 
> Signed-off-by: xiaoqiang zhao 
> ---
>  hw/audio/cs4231.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/hw/audio/cs4231.c b/hw/audio/cs4231.c
> index caf97c1..30690f9 100644
> --- a/hw/audio/cs4231.c
> +++ b/hw/audio/cs4231.c
> @@ -145,16 +145,15 @@ static const VMStateDescription vmstate_cs4231 = {
>  }
>  };
>  
> -static int cs4231_init1(SysBusDevice *dev)
> +static void cs4231_init(Object *obj)
>  {
> -CSState *s = CS4231(dev);
> +CSState *s = CS4231(obj);
> +SysBusDevice *dev = SYS_BUS_DEVICE(obj);
>  
> -memory_region_init_io(&s->iomem, OBJECT(s), &cs_mem_ops, s, "cs4321",
> +memory_region_init_io(&s->iomem, obj, &cs_mem_ops, s, "cs4321",
>CS_SIZE);
>  sysbus_init_mmio(dev, &s->iomem);
>  sysbus_init_irq(dev, &s->irq);
> -
> -return 0;
>  }
>  
>  static Property cs4231_properties[] = {
> @@ -164,9 +163,7 @@ static Property cs4231_properties[] = {
>  static void cs4231_class_init(ObjectClass *klass, void *data)
>  {
>  DeviceClass *dc = DEVICE_CLASS(klass);
> -SysBusDeviceClass *k = SYS_BUS_DEVICE_CLASS(klass);
>  
> -k->init = cs4231_init1;
>  dc->reset = cs_reset;
>  dc->vmsd = &vmstate_cs4231;
>  dc->props = cs4231_properties;
> @@ -176,6 +173,7 @@ static const TypeInfo cs4231_info = {
>  .name  = TYPE_CS4231,
>  .parent= TYPE_SYS_BUS_DEVICE,
>  .instance_size = sizeof(CSState),
> +.instance_init = cs4231_init,
>  .class_init= cs4231_class_init,
>  };
>  
> 

Reviewed-by: Paolo Bonzini 



Re: [Qemu-devel] [PATCH] spice: Disallow use of gl + TCP port

2016-03-18 Thread Christophe Fergeau
On Fri, Mar 18, 2016 at 09:17:53AM +0100, Gerd Hoffmann wrote:
> On Mo, 2016-03-14 at 12:41 +0100, Christophe Fergeau wrote:
> > Currently, virgl support has to go through a local unix socket, trying
> > to connect to a VM using -spice gl through spice://localhost:5900 will
> > only result in a black screen.
> > This commit errors out when the user tries to start a VM with both GL
> > support and a port/tls-port set.
> > This would fit better in spice-server, but currently QEMU does not call
> > into spice-server when parsing 'gl' on its command line, so we have to
> > do this check in QEMU instead.
> > 
> > Signed-off-by: Christophe Fergeau 
> 
> Picked up for ui patch queue.

Great thanks!

Fwiw, I've changed it locally to address Eric's comments, but did not
send it as v2 since a discussion was ongoing, here is what it looks in
my local clone now (but I'm fine with either version):


commit c0e10fb17a45a9da14d068a58af3a00e78f82403
Author: Christophe Fergeau 
Date:   Mon Mar 14 12:37:50 2016 +0100

spice: Disallow use of gl + TCP port

Currently, virgl support has to go through a local unix socket, trying
to connect to a VM using -spice gl through spice://localhost:5900 will
only result in a black screen.
This commit errors out when the user tries to start a VM with both GL
support and a port/tls-port set.
This would fit better in spice-server, but currently QEMU does not call
into spice-server when parsing 'gl' on its command line, so we have to
do this check in QEMU instead.

Signed-off-by: Christophe Fergeau 

diff --git a/ui/spice-core.c b/ui/spice-core.c
index 7987a4e..83950fe 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -844,6 +844,10 @@ void qemu_spice_init(void)

 #ifdef HAVE_SPICE_GL
 if (qemu_opt_get_bool(opts, "gl", 0)) {
+if (port || tls_port) {
+error_report("SPICE GL support is local-only for now and 
incompatible with -spice port/tls-port");
+exit(1);
+}
 if (egl_rendernode_init() == 0) {
 display_opengl = 1;
 }


Christophe


signature.asc
Description: PGP signature


Re: [Qemu-devel] [RFC PATCH V2 00/10] Qemu: Add live migration support for SRIOV NIC

2016-03-18 Thread Wei Yang
Hi, Tianyu,

I am testing your V2 patch set in our environment, while facing two issues
now. Have a workaround for the first one and hope you could share some light
on the second one :-)

1. Mismatch for ram_block (Have a workaround)
---
Below is the error message on the destination:

qemu-system-x86_64: Length mismatch: : 0x3000 in != 0x4000: Invalid argument
qemu-system-x86_64: error while loading state for instance 0x0 of device 
'ram'
qemu-system-x86_64: load of migration failed: Invalid argument

With the following command line on source and destination respectively:

git/qemu/x86_64-softmmu/qemu-system-x86_64 --enable-kvm -m 4096 -smp 4 
--nographic -drive file=/root/nfs/rhel.img,format=raw,cache=none -device 
vfio-sriov,host=:03:10.0
git/qemu/x86_64-softmmu/qemu-system-x86_64 --enable-kvm -m 4096 -smp 4 
--nographic -drive file=/root/nfs/rhel.img,format=raw,cache=none -device 
vfio-sriov,host=:03:10.0 --incoming tcp:0:

By some debugging, the reason for this error is the ram_block->idstr of
pass-through MMIO region is not set.

My workaround is to add vmstate_register_ram() in vfio_mmap_region() after
memory_region_init_ram_ptr() returns.

I think this is not a good solution, since the ram_block->idstr is coded
with the VF's BDF. So I guess this will not work when the VF has different BDF
from source to destination respectively.

Maybe my test step is not correct?

2. Failed to migrate the MAC address
---

By adding some code in VF's driver in destination guest, I found the MAC
information has been migrated to destination in adapter->hw.mac. While this is
"reset" by VF's driver, when ixgbevf_migration_task is invoked at the end of
the migration process.

Below is what I have printed:

The ifconfig output from destination:

eth8  Link encap:Ethernet  HWaddr 52:54:00:81:39:F2  
  inet addr:9.31.210.106  Bcast:9.31.255.255  Mask:255.255.0.0
  inet6 addr: fe80::5054:ff:fe81:39f2/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:66 errors:0 dropped:0 overruns:0 frame:0
  TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:21840 (21.3 KiB)  TX bytes:920 (920.0 b)

The log message I printed in destination's VF driver:

ixgbevf: migration end -- 
ixgbevf: original mac:52:54:00:81:39:f2
ixgbevf: after reset mac:52:54:00:92:04:a3
ixgbevf: migration end  ==

I didn't take a close look in the "reset" function, while seems it retrieves
the mac from VF hardware. Hmm... is there some possible way to have the same
mac on both source and destination?

At last, I appreciated all your work and help, learned much from your side.

On Tue, Nov 24, 2015 at 09:35:17PM +0800, Lan Tianyu wrote:
>This patchset is to propose a solution of adding live migration
>support for SRIOV NIC.
>
>During migration, Qemu needs to let VF driver in the VM to know
>migration start and end. Qemu adds faked PCI migration capability
>to help to sync status between two sides during migration.
>
>Qemu triggers VF's mailbox irq via sending MSIX msg when migration
>status is changed. VF driver tells Qemu its mailbox vector index
>via the new PCI capability. In some cases(NIC is suspended or closed),
>VF mailbox irq is freed and VF driver can disable irq injecting via
>new capability.   
>
>VF driver will put down nic before migration and put up again on
>the target machine.
>
>Lan Tianyu (10):
>  Qemu/VFIO: Create head file pci.h to share data struct.
>  Qemu/VFIO: Add new VFIO_GET_PCI_CAP_INFO ioctl cmd definition
>  Qemu/VFIO: Rework vfio_std_cap_max_size() function
>  Qemu/VFIO: Add vfio_find_free_cfg_reg() to find free PCI config space
>regs
>  Qemu/VFIO: Expose PCI config space read/write and msix functions
>  Qemu/PCI: Add macros for faked PCI migration capability
>  Qemu: Add post_load_state() to run after restoring CPU state
>  Qemu: Add save_before_stop callback to run just before stopping VCPU
>during migration
>  Qemu/VFIO: Add SRIOV VF migration support
>  Qemu/VFIO: Misc change for enable migration with VFIO
>
> hw/vfio/Makefile.objs   |   2 +-
> hw/vfio/pci.c   | 196 +---
> hw/vfio/pci.h   | 168 +
> hw/vfio/sriov.c | 178 
> include/hw/pci/pci_regs.h   |  19 +
> include/migration/vmstate.h |   5 ++
> include/sysemu/sysemu.h |   1 +
> linux-headers/linux/vfio.h  |  16 
> migration/migration.c   |   3 +-
> migration/savevm.c  |  28 +++
> 10 files changed, 459 insertions(+), 157 deletions(-)
> create mode 100644 hw/vfio/pci.h
> create mode 100644 hw/vfio/sriov.c
>
>-- 
>1.9.3
>
>

--

[Qemu-devel] [PATCH v6 12/16] qapi: Don't special-case simple union wrappers

2016-03-18 Thread Eric Blake
Simple unions were carrying a special case that hid their 'data'
QMP member from the resulting C struct, via the hack method
QAPISchemaObjectTypeVariant.simple_union_type().  But by using
the work we started by unboxing flat union and alternate
branches, coupled with the ability to visit the members of an
implicit type, we can now expose the simple union's implicit
type in qapi-types.h:

| struct q_obj_ImageInfoSpecificQCow2_wrapper {
| ImageInfoSpecificQCow2 *data;
| };
|
| struct q_obj_ImageInfoSpecificVmdk_wrapper {
| ImageInfoSpecificVmdk *data;
| };
...
| struct ImageInfoSpecific {
| ImageInfoSpecificKind type;
| union { /* union tag is @type */
| void *data;
|-ImageInfoSpecificQCow2 *qcow2;
|-ImageInfoSpecificVmdk *vmdk;
|+q_obj_ImageInfoSpecificQCow2_wrapper qcow2;
|+q_obj_ImageInfoSpecificVmdk_wrapper vmdk;
| } u;
| };

Doing this removes asymmetry between QAPI's QMP side and its
C side (both sides now expose 'data'), and means that the
treatment of a simple union as sugar for a flat union is now
equivalent in both languages (previously the two approaches used
a different layer of dereferencing, where the simple union could
be converted to a flat union with equivalent C layout but
different {} on the wire, or to an equivalent QMP wire form
but with different C representation).  Using the implicit type
also lets us get rid of the simple_union_type() hack.

Of course, now all clients of simple unions have to adjust from
using su->u.member to using su->u.member.data; while this touches
a number of files in the tree, some earlier cleanup patches
helped minimize the change to the initialization of a temporary
variable rather than every single member access.  The generated
qapi-visit.c code is also affected by the layout change:

|@@ -7393,10 +7393,10 @@ void visit_type_ImageInfoSpecific_member
| }
| switch (obj->type) {
| case IMAGE_INFO_SPECIFIC_KIND_QCOW2:
|-visit_type_ImageInfoSpecificQCow2(v, "data", &obj->u.qcow2, &err);
|+visit_type_q_obj_ImageInfoSpecificQCow2_wrapper_members(v, 
&obj->u.qcow2, &err);
| break;
| case IMAGE_INFO_SPECIFIC_KIND_VMDK:
|-visit_type_ImageInfoSpecificVmdk(v, "data", &obj->u.vmdk, &err);
|+visit_type_q_obj_ImageInfoSpecificVmdk_wrapper_members(v, 
&obj->u.vmdk, &err);
| break;
| default:
| abort();

Signed-off-by: Eric Blake 

---
v6: no change
v5: rebase to q_obj naming change, hoist assertion earlier in series
v4: improve commit message, rebase onto exposed implicit types
[no v3]
v2: rebase onto s/fields/members/ change, changes in master; pick
up missing net/ files
---
 scripts/qapi.py | 10 -
 scripts/qapi-types.py   |  8 +---
 scripts/qapi-visit.py   | 22 ++-
 backends/baum.c |  2 +-
 backends/msmouse.c  |  2 +-
 block/nbd.c |  6 +--
 block/qcow2.c   |  6 +--
 block/vmdk.c|  8 ++--
 blockdev.c  | 24 ++--
 hmp.c   |  8 ++--
 hw/char/escc.c  |  2 +-
 hw/input/hid.c  |  8 ++--
 hw/input/ps2.c  |  6 +--
 hw/input/virtio-input-hid.c |  8 ++--
 hw/mem/pc-dimm.c|  2 +-
 net/dump.c  |  2 +-
 net/hub.c   |  2 +-
 net/l2tpv3.c|  2 +-
 net/net.c   |  4 +-
 net/netmap.c|  2 +-
 net/slirp.c |  2 +-
 net/socket.c|  2 +-
 net/tap-win32.c |  2 +-
 net/tap.c   |  4 +-
 net/vde.c   |  2 +-
 net/vhost-user.c|  2 +-
 numa.c  |  4 +-
 qemu-char.c | 82 +
 qemu-nbd.c  |  6 +--
 replay/replay-input.c   | 44 +++---
 spice-qemu-char.c   | 14 ---
 tests/test-io-channel-socket.c  | 40 ++--
 tests/test-qmp-commands.c   |  2 +-
 tests/test-qmp-input-visitor.c  | 25 +++--
 tests/test-qmp-output-visitor.c | 24 ++--
 tpm.c   |  2 +-
 ui/console.c|  4 +-
 ui/input-keymap.c   | 10 ++---
 ui/input-legacy.c   |  8 ++--
 ui/input.c  | 34 -
 ui/vnc-auth-sasl.c  |  3 +-
 ui/vnc.c| 29 ---
 util/qemu-sockets.c | 35 +-
 43 files changed, 246 insertions(+), 268 deletions(-)

diff --git a/scripts/qapi.py b/scripts/qapi.py
index 08d63bf..d91af94 100644
--- a/scripts/qapi.py
+++ b/scripts/qapi.py
@@ -1115,16 +1115,6 @@ class 
QAPISchemaObjectTypeVariant(QAPISchemaObjectTypeMember):
 def __init__(self, name, typ):
 QAPISchemaObjectTypeMember.__init__(self, name, ty

Re: [Qemu-devel] [PATCH v3] Sort the fw_cfg file list

2016-03-18 Thread Michael S. Tsirkin
On Wed, Mar 16, 2016 at 01:47:08PM -0500, miny...@acm.org wrote:
> From: Gerd Hoffmann 
> 
> Entries are inserted in filename order instead of being
> appended to the end in case sorting is enabled.
> 
> This will avoid any future issues of moving the file creation
> around, it doesn't matter what order they are created now,
> the will always be in filename order.
> 
> Signed-off-by: Gerd Hoffmann 
> 
> Added machine type handling for compatibility.  This was
> a fairly complex change, this will preserve the order of fw_cfg
> for older versions no matter what order the firmware files
> actually come in.  A list is kept of the correct legacy order
> and the entries will be inserted based upon their order in
> the list.  Except that some entries are ordered (in a specific
> area of the list) based upon what order they appear on the
> command line.  Special handling is added for those entries.
> 
> Signed-off-by: Corey Minyard 
> ---
> 
> A new version of the sorted fw_cfg, with new backwards
> compatibility code.  This is bigger than I would like, but
> I can't think of a good way to split it up that would make
> much sense.
> 
> This is more for review, anyway, I'm sure there are issues with
> this.
> 
> I'm not too excited about fw_cfg_set_order_override(), but I can't
> think of a better way to handle this.  You can't use filename or
> prefixes, the same filenames appear in different places for VGA
> ROMs depending on if they are PCI or ISA.

I don't see another good solution either.
However, I would like to make these NOPs with
new machine types.

This way down the road we can drop this mess.


>  hw/i386/pc.c  |   4 ++
>  hw/i386/pc_piix.c |   1 +
>  hw/i386/pc_q35.c  |   1 +
>  hw/nvram/fw_cfg.c | 127 
> +++---
>  include/hw/boards.h   |   3 +-
>  include/hw/nvram/fw_cfg.h |   7 +++
>  vl.c  |   4 ++
>  7 files changed, 138 insertions(+), 9 deletions(-)
> 
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 56ec6cd..707753b 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -1406,6 +1406,7 @@ DeviceState *pc_vga_init(ISABus *isa_bus, PCIBus 
> *pci_bus)
>  {
>  DeviceState *dev = NULL;
>  
> +fw_cfg_set_order_override(FW_CFG_ORDER_OVERRIDE_VGA);
>  if (pci_bus) {
>  PCIDevice *pcidev = pci_vga_init(pci_bus);
>  dev = pcidev ? &pcidev->qdev : NULL;
> @@ -1413,6 +1414,7 @@ DeviceState *pc_vga_init(ISABus *isa_bus, PCIBus 
> *pci_bus)
>  ISADevice *isadev = isa_vga_init(isa_bus);
>  dev = isadev ? DEVICE(isadev) : NULL;
>  }
> +fw_cfg_reset_order_override();
>  return dev;
>  }
>  
> @@ -1541,6 +1543,7 @@ void pc_nic_init(ISABus *isa_bus, PCIBus *pci_bus)
>  {
>  int i;
>  
> +fw_cfg_set_order_override(FW_CFG_ORDER_OVERRIDE_NIC);
>  for (i = 0; i < nb_nics; i++) {
>  NICInfo *nd = &nd_table[i];
>  
> @@ -1550,6 +1553,7 @@ void pc_nic_init(ISABus *isa_bus, PCIBus *pci_bus)
>  pci_nic_init_nofail(nd, pci_bus, "e1000", NULL);
>  }
>  }
> +fw_cfg_reset_order_override();
>  }
>  
>  void pc_pci_device_init(PCIBus *pci_bus)
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 6f8c2cd..447703b 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -429,6 +429,7 @@ static void pc_i440fx_2_5_machine_options(MachineClass *m)
>  m->alias = NULL;
>  m->is_default = 0;
>  pcmc->save_tsc_khz = false;
> +m->legacy_fw_cfg_order = 1;
>  SET_MACHINE_COMPAT(m, PC_COMPAT_2_5);
>  }
>  
> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> index 46522c9..04f3609 100644
> --- a/hw/i386/pc_q35.c
> +++ b/hw/i386/pc_q35.c
> @@ -291,6 +291,7 @@ static void pc_q35_2_5_machine_options(MachineClass *m)
>  pc_q35_2_6_machine_options(m);
>  m->alias = NULL;
>  pcmc->save_tsc_khz = false;
> +m->legacy_fw_cfg_order = 1;
>  SET_MACHINE_COMPAT(m, PC_COMPAT_2_5);
>  }
>  
> diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
> index 7866248..1693f26 100644
> --- a/hw/nvram/fw_cfg.c
> +++ b/hw/nvram/fw_cfg.c
> @@ -28,6 +28,7 @@
>  #include "hw/isa/isa.h"
>  #include "hw/nvram/fw_cfg.h"
>  #include "hw/sysbus.h"
> +#include "hw/boards.h"
>  #include "trace.h"
>  #include "qemu/error-report.h"
>  #include "qemu/config-file.h"
> @@ -68,6 +69,7 @@ struct FWCfgState {
>  /*< public >*/
>  
>  FWCfgEntry entries[2][FW_CFG_MAX_ENTRY];
> +int entry_order[FW_CFG_MAX_ENTRY];
>  FWCfgFiles *files;
>  uint16_t cur_entry;
>  uint32_t cur_offset;
> @@ -664,12 +666,88 @@ void fw_cfg_add_i64(FWCfgState *s, uint16_t key, 
> uint64_t value)
>  fw_cfg_add_bytes(s, key, copy, sizeof(value));
>  }
>  
> +static int fw_cfg_order_override = -1;
> +
> +void fw_cfg_set_order_override(int order)
> +{
> +assert(fw_cfg_order_override == -1);
> +fw_cfg_order_override = order;
> +}
> +
> +void fw_cfg_reset_order_override(void)
> +{
> +assert(fw_cfg_order_override != -1);
> + 

Re: [Qemu-devel] [PATCH v2 02/10] ppc: Add macros to register hypervisor mode SPRs

2016-03-18 Thread Thomas Huth
On 16.03.2016 14:13, Cédric Le Goater wrote:
> From: Benjamin Herrenschmidt 
> 
> The current set of spr_register_* macros only take the user and
> supervisor function pointers. To make the transition easy, we
> don't change that but we add "_hv" variants that can be used to
> register all 3 sets.
> 
> To simplify the transition, users of the "old" macro will set the
> hypervisor callback to be the same as the supervisor one. The new
> registration function only needs to be used for registers that are
> either hypervisor only or behave differently in HV mode.
> 
> Signed-off-by: Benjamin Herrenschmidt 
> Reviewed-by: David Gibson 
> [clg: fixed else if condition in gen_op_mfspr() ]
> Signed-off-by: Cédric Le Goater 
> ---
>  target-ppc/translate.c  | 26 --
>  target-ppc/translate_init.c | 35 +++
>  2 files changed, 47 insertions(+), 14 deletions(-)
> 
[...]

Reviewed-by: Thomas Huth 




Re: [Qemu-devel] [PULL 00/21] target-arm queue

2016-03-18 Thread Peter Maydell
On 16 March 2016 at 17:18, Peter Maydell  wrote:
> Here's the target-arm queue; I'm a bit hesitant about the late-landing
> various new board/SoC patches, but they won't affect anybody who isn't
> trying to use those boards, so I think it's OK.
>
> (There are a few other patches on list which I definitely want to
> get in before rc0 but they need a bit more review time I think.)
>
> thanks
> -- PMM
>
>
> The following changes since commit 0ebc03bc065329eaefb6493f5fa7df08df528f2a:
>
>   util/base64.c: Clean includes (2016-03-16 12:48:11 +)
>
> are available in the git repository at:
>
>   git://git.linaro.org/people/pmaydell/qemu-arm.git 
> tags/pull-target-arm-20160316
>
> for you to fetch changes up to 10b27d1ab391dbf36f92e1a33179662082401d7a:
>
>   sd: Fix "info qtree" on boards with SD cards (2016-03-16 17:12:46 +)

Respin with fix now applied to master.

-- PMM



[Qemu-devel] [PATCH v5 0/7] Add new LUKS block driver (for 2.6)

2016-03-18 Thread Daniel P. Berrange
This series is just the block layer parts needed to add
a LUKS driver to QEMU. It was previously posted as part
of the larger series

  v1: https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg04748.html
  v2: https://lists.gnu.org/archive/html/qemu-block/2016-01/msg00534.html
  v3: https://lists.gnu.org/archive/html/qemu-devel/2016-02/msg03176.html
  v4: https://lists.gnu.org/archive/html/qemu-devel/2016-02/msg06552.html

The crypto subsystem pieces that this series depends on have
been submitted for merge

  https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg04371.html

In this posting I am only proposing merge of the generic
LUKS driver. This can be added as a layer above any of the
existing drivers for accessing LUKS formatted volumes.

When creating new volumes, however, only the file backend
can be used, since the block driver API doesn't allow for
arbitrary stacking of protocols when creating images.

The integration with the qcow2 driver to replace the existing
built-in AES-CBC code is dropped from this series, postponed
until the 2.7 development cycle.

There is a QEMU I/O test 149 that exercises the LUKS driver
and checks for compatibility with the dm-crypt/cryptsetup
impl.


Daniel P. Berrange (7):
  block: add flag to indicate that no I/O will be performed
  qemu-img/qemu-io: don't prompt for passwords if not required
  tests: redirect stderr to stdout for iotests
  tests: refactor python I/O tests helper main method
  tests: add output filter to python I/O tests helper
  block: add generic full disk encryption driver
  block: drop support for using qcow[2] encryption with system emulators

 block.c   |   17 +-
 block/Makefile.objs   |2 +
 block/crypto.c|  587 +
 block/io.c|2 +
 block/qcow.c  |   11 +
 block/qcow2.c |   11 +
 include/block/block.h |2 +
 qapi/block-core.json  |   22 +-
 qemu-img.c|   45 +-
 qemu-io.c |2 +-
 tests/qemu-iotests/049.out|6 -
 tests/qemu-iotests/087.out|   22 +-
 tests/qemu-iotests/134.out|   18 -
 tests/qemu-iotests/149|  521 
 tests/qemu-iotests/149.out| 1880 +
 tests/qemu-iotests/common |7 +
 tests/qemu-iotests/group  |1 +
 tests/qemu-iotests/iotests.py |   48 +-
 18 files changed, 3118 insertions(+), 86 deletions(-)
 create mode 100644 block/crypto.c
 create mode 100755 tests/qemu-iotests/149
 create mode 100644 tests/qemu-iotests/149.out

-- 
2.5.0




[Qemu-devel] [PULL 29/40] ivshmem: Simplify how we cope with short reads from server

2016-03-18 Thread Markus Armbruster
Short reads from a UNIX domain sockets are exceedingly unlikely when
the other side always sends eight bytes and we always read eight
bytes.  We cope with them anyway.  However, the code doing that is
rather convoluted.  Dumb it down radically.

Signed-off-by: Markus Armbruster 
Reviewed-by: Marc-André Lureau 
Message-Id: <1458066895-20632-30-git-send-email-arm...@redhat.com>
---
 hw/misc/ivshmem.c | 75 ---
 1 file changed, 16 insertions(+), 59 deletions(-)

diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index c1a75db..7b9e769 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -26,7 +26,6 @@
 #include "migration/migration.h"
 #include "qemu/error-report.h"
 #include "qemu/event_notifier.h"
-#include "qemu/fifo8.h"
 #include "sysemu/char.h"
 #include "sysemu/hostmem.h"
 #include "qapi/visitor.h"
@@ -80,7 +79,6 @@ typedef struct IVShmemState {
 uint32_t intrstatus;
 
 CharDriverState *server_chr;
-Fifo8 incoming_fifo;
 MemoryRegion ivshmem_mmio;
 
 /* We might need to register the BAR before we actually have the memory.
@@ -99,6 +97,8 @@ typedef struct IVShmemState {
 uint32_t vectors;
 uint32_t features;
 MSIVector *msi_vectors;
+uint64_t msg_buf;   /* buffer for receiving server messages */
+int msg_buffered_bytes; /* #bytes in @msg_buf */
 
 Error *migration_blocker;
 
@@ -255,11 +255,6 @@ static const MemoryRegionOps ivshmem_mmio_ops = {
 },
 };
 
-static int ivshmem_can_receive(void * opaque)
-{
-return sizeof(int64_t);
-}
-
 static void ivshmem_vector_notify(void *opaque)
 {
 MSIVector *entry = opaque;
@@ -459,53 +454,6 @@ static void resize_peers(IVShmemState *s, int nb_peers)
 }
 }
 
-static bool fifo_update_and_get(IVShmemState *s, const uint8_t *buf, int size,
-void *data, size_t len)
-{
-const uint8_t *p;
-uint32_t num;
-
-assert(len <= sizeof(int64_t)); /* limitation of the fifo */
-if (fifo8_is_empty(&s->incoming_fifo) && size == len) {
-memcpy(data, buf, size);
-return true;
-}
-
-IVSHMEM_DPRINTF("short read of %d bytes\n", size);
-
-num = MIN(size, sizeof(int64_t) - fifo8_num_used(&s->incoming_fifo));
-fifo8_push_all(&s->incoming_fifo, buf, num);
-
-if (fifo8_num_used(&s->incoming_fifo) < len) {
-assert(num == 0);
-return false;
-}
-
-size -= num;
-buf += num;
-p = fifo8_pop_buf(&s->incoming_fifo, len, &num);
-assert(num == len);
-
-memcpy(data, p, len);
-
-if (size > 0) {
-fifo8_push_all(&s->incoming_fifo, buf, size);
-}
-
-return true;
-}
-
-static bool fifo_update_and_get_i64(IVShmemState *s,
-const uint8_t *buf, int size, int64_t *i64)
-{
-if (fifo_update_and_get(s, buf, size, i64, sizeof(*i64))) {
-*i64 = GINT64_FROM_LE(*i64);
-return true;
-}
-
-return false;
-}
-
 static void ivshmem_add_kvm_msi_virq(IVShmemState *s, int vector,
  Error **errp)
 {
@@ -658,6 +606,14 @@ static void process_msg(IVShmemState *s, int64_t msg, int 
fd, Error **errp)
 }
 }
 
+static int ivshmem_can_receive(void *opaque)
+{
+IVShmemState *s = opaque;
+
+assert(s->msg_buffered_bytes < sizeof(s->msg_buf));
+return sizeof(s->msg_buf) - s->msg_buffered_bytes;
+}
+
 static void ivshmem_read(void *opaque, const uint8_t *buf, int size)
 {
 IVShmemState *s = opaque;
@@ -665,9 +621,14 @@ static void ivshmem_read(void *opaque, const uint8_t *buf, 
int size)
 int fd;
 int64_t msg;
 
-if (!fifo_update_and_get_i64(s, buf, size, &msg)) {
+assert(size >= 0 && s->msg_buffered_bytes + size <= sizeof(s->msg_buf));
+memcpy((unsigned char *)&s->msg_buf + s->msg_buffered_bytes, buf, size);
+s->msg_buffered_bytes += size;
+if (s->msg_buffered_bytes < sizeof(s->msg_buf)) {
 return;
 }
+msg = le64_to_cpu(s->msg_buf);
+s->msg_buffered_bytes = 0;
 
 fd = qemu_chr_fe_get_msgfd(s->server_chr);
 IVSHMEM_DPRINTF("posn is %" PRId64 ", fd is %d\n", msg, fd);
@@ -1022,8 +983,6 @@ static void pci_ivshmem_realize(PCIDevice *dev, Error 
**errp)
 }
 }
 
-fifo8_create(&s->incoming_fifo, sizeof(int64_t));
-
 if (s->role_val == IVSHMEM_PEER) {
 error_setg(&s->migration_blocker,
"Migration is disabled when using feature 'peer mode' in 
device 'ivshmem'");
@@ -1036,8 +995,6 @@ static void pci_ivshmem_exit(PCIDevice *dev)
 IVShmemState *s = IVSHMEM(dev);
 int i;
 
-fifo8_destroy(&s->incoming_fifo);
-
 if (s->migration_blocker) {
 migrate_del_blocker(s->migration_blocker);
 error_free(s->migration_blocker);
-- 
2.4.3




[Qemu-devel] [PULL v1 13/13] crypto: implement the LUKS block encryption format

2016-03-18 Thread Daniel P. Berrange
Provide a block encryption implementation that follows the
LUKS/dm-crypt specification.

This supports all combinations of hash, cipher algorithm,
cipher mode and iv generator that are implemented by the
current crypto layer.

There is support for opening existing volumes formatted
by dm-crypt, and for formatting new volumes. In the latter
case it will only use key slot 0.

Reviewed-by: Eric Blake 
Signed-off-by: Daniel P. Berrange 
---
 crypto/Makefile.objs  |1 +
 crypto/block-luks.c   | 1328 +
 crypto/block-luks.h   |   28 +
 crypto/block.c|2 +
 qapi/crypto.json  |   49 +-
 tests/test-crypto-block.c |  116 +++-
 6 files changed, 1520 insertions(+), 4 deletions(-)
 create mode 100644 crypto/block-luks.c
 create mode 100644 crypto/block-luks.h

diff --git a/crypto/Makefile.objs b/crypto/Makefile.objs
index 3ddeb42..9f2c87e 100644
--- a/crypto/Makefile.objs
+++ b/crypto/Makefile.objs
@@ -21,6 +21,7 @@ crypto-obj-y += afsplit.o
 crypto-obj-y += xts.o
 crypto-obj-y += block.o
 crypto-obj-y += block-qcow.o
+crypto-obj-y += block-luks.o
 
 # Let the userspace emulators avoid linking gnutls/etc
 crypto-aes-obj-y = aes.o
diff --git a/crypto/block-luks.c b/crypto/block-luks.c
new file mode 100644
index 000..58c1b94
--- /dev/null
+++ b/crypto/block-luks.c
@@ -0,0 +1,1328 @@
+/*
+ * QEMU Crypto block device encryption LUKS format
+ *
+ * Copyright (c) 2015-2016 Red Hat, Inc.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ *
+ */
+
+#include "qemu/osdep.h"
+
+#include "crypto/block-luks.h"
+
+#include "crypto/hash.h"
+#include "crypto/afsplit.h"
+#include "crypto/pbkdf.h"
+#include "crypto/secret.h"
+#include "crypto/random.h"
+
+#ifdef CONFIG_UUID
+#include 
+#endif
+
+#include "qemu/coroutine.h"
+
+/*
+ * Reference for the LUKS format implemented here is
+ *
+ *   docs/on-disk-format.pdf
+ *
+ * in 'cryptsetup' package source code
+ *
+ * This file implements the 1.2.1 specification, dated
+ * Oct 16, 2011.
+ */
+
+typedef struct QCryptoBlockLUKS QCryptoBlockLUKS;
+typedef struct QCryptoBlockLUKSHeader QCryptoBlockLUKSHeader;
+typedef struct QCryptoBlockLUKSKeySlot QCryptoBlockLUKSKeySlot;
+
+
+/* The following constants are all defined by the LUKS spec */
+#define QCRYPTO_BLOCK_LUKS_VERSION 1
+
+#define QCRYPTO_BLOCK_LUKS_MAGIC_LEN 6
+#define QCRYPTO_BLOCK_LUKS_CIPHER_NAME_LEN 32
+#define QCRYPTO_BLOCK_LUKS_CIPHER_MODE_LEN 32
+#define QCRYPTO_BLOCK_LUKS_HASH_SPEC_LEN 32
+#define QCRYPTO_BLOCK_LUKS_DIGEST_LEN 20
+#define QCRYPTO_BLOCK_LUKS_SALT_LEN 32
+#define QCRYPTO_BLOCK_LUKS_UUID_LEN 40
+#define QCRYPTO_BLOCK_LUKS_NUM_KEY_SLOTS 8
+#define QCRYPTO_BLOCK_LUKS_STRIPES 4000
+#define QCRYPTO_BLOCK_LUKS_MIN_SLOT_KEY_ITERS 1000
+#define QCRYPTO_BLOCK_LUKS_MIN_MASTER_KEY_ITERS 1000
+#define QCRYPTO_BLOCK_LUKS_KEY_SLOT_OFFSET 4096
+
+#define QCRYPTO_BLOCK_LUKS_KEY_SLOT_DISABLED 0xDEAD
+#define QCRYPTO_BLOCK_LUKS_KEY_SLOT_ENABLED 0x00AC71F3
+
+#define QCRYPTO_BLOCK_LUKS_SECTOR_SIZE 512LL
+
+static const char qcrypto_block_luks_magic[QCRYPTO_BLOCK_LUKS_MAGIC_LEN] = {
+'L', 'U', 'K', 'S', 0xBA, 0xBE
+};
+
+typedef struct QCryptoBlockLUKSNameMap QCryptoBlockLUKSNameMap;
+struct QCryptoBlockLUKSNameMap {
+const char *name;
+int id;
+};
+
+typedef struct QCryptoBlockLUKSCipherSizeMap QCryptoBlockLUKSCipherSizeMap;
+struct QCryptoBlockLUKSCipherSizeMap {
+uint32_t key_bytes;
+int id;
+};
+typedef struct QCryptoBlockLUKSCipherNameMap QCryptoBlockLUKSCipherNameMap;
+struct QCryptoBlockLUKSCipherNameMap {
+const char *name;
+const QCryptoBlockLUKSCipherSizeMap *sizes;
+};
+
+
+static const QCryptoBlockLUKSCipherSizeMap
+qcrypto_block_luks_cipher_size_map_aes[] = {
+{ 16, QCRYPTO_CIPHER_ALG_AES_128 },
+{ 24, QCRYPTO_CIPHER_ALG_AES_192 },
+{ 32, QCRYPTO_CIPHER_ALG_AES_256 },
+{ 0, 0 },
+};
+
+static const QCryptoBlockLUKSCipherSizeMap
+qcrypto_block_luks_cipher_size_map_cast5[] = {
+{ 16, QCRYPTO_CIPHER_ALG_CAST5_128 },
+{ 0, 0 },
+};
+
+static const QCryptoBlockLUKSCipherSizeMap
+qcrypto_block_luks_cipher_size_map_serpent[] = {
+{ 16, QCRYPTO_CIPHER_ALG_SERPENT_128 },
+{ 24, QCRYPTO_CIPHER_ALG_SERPENT_192 },
+{ 32, QCRYPTO_CIPHER_ALG_SERPENT_256 },
+{ 0, 0 },
+};
+
+static const QCryptoBlockLUKSCipherSizeMap
+qcrypto_block_luks_cipher_size_map_twofis

Re: [Qemu-devel] [PATCH] exec: fix error handling in file_ram_alloc

2016-03-18 Thread Laszlo Ersek
On 03/17/16 23:51, Paolo Bonzini wrote:
> One instance of double closing, and invalid close(-1) in some cases
> of "goto error".
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  exec.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/exec.c b/exec.c
> index f398d21..5c16f41 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -1238,7 +1238,7 @@ static void *file_ram_alloc(RAMBlock *block,
>  char *sanitized_name;
>  char *c;
>  void *area;
> -int fd;
> +int fd = -1;
>  int64_t page_size;
>  
>  if (kvm_enabled() && !kvm_has_sync_mmu()) {
> @@ -1320,7 +1320,6 @@ static void *file_ram_alloc(RAMBlock *block,
>  if (area == MAP_FAILED) {
>  error_setg_errno(errp, errno,
>   "unable to map backing store for guest RAM");
> -close(fd);
>  goto error;
>  }
>  
> @@ -1335,7 +1334,9 @@ error:
>  if (unlink_on_error) {
>  unlink(path);
>  }
> -close(fd);
> +if (fd != -1) {
> +close(fd);
> +}
>  return NULL;
>  }
>  #endif
> 

Reviewed-by: Laszlo Ersek 




Re: [Qemu-devel] [PATCH v1 0/2] Fix build problems with nettle < 3.0.0

2016-03-18 Thread Eduardo Habkost
On Fri, Mar 18, 2016 at 01:21:54PM +, Daniel P. Berrange wrote:
> This series fixes two build problems identified by people using
> 2.x series of nettle
> 
>   https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg04420.html
> 
> 
> Daniel P. Berrange (2):
>   crypto: add compat cast5_set_key with  nettle < 3.0.0
>   crypto: fix cipher function signature mismatch with nettle & xts

Fixes the issues I was seeing. Thanks!

Tested-by: Eduardo Habkost 

-- 
Eduardo



Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it

2016-03-18 Thread Stefan Hajnoczi
On Tue, Mar 15, 2016 at 01:56:47PM +, Dr. David Alan Gilbert wrote:
> > This would put trace_foo() in generated-tracers-virtio-blk.h and
> > trace_bar() in generated-tracers-memory.h.  Source files using tracing
> > would need to include headers for relevant sections.
> > 
> > This way we can narrow the scope of tracing headers and prevent global
> > recompilation.
> > 
> > The fly in the ointment is that trace/control.h defines enum
> > TraceEventID, a global numbering of all trace events.  The enum is used
> > in trace/contro.h APIs and also in the simpletrace file format.
> > 
> > If ./trace-event is modified the numbering of trace events could change.
> > This would require global recompilation :(.
> > 
> > So in order to avoid global recompilation we need to eliminate enum
> > TraceEventID.  Perhaps it's possible to use TraceEvent* instead of
> > TraceEventID.  For the simpletrace backend we would continue to use a
> > global ordering but that only affects generated-tracers.c and not header
> > files (thankfully!).
> 
> I think the hardest part is going to be understanding all of the different
> tracers and the things they need to know; like that thing about simpletrace
> needing the single ordering;  I don't know what the other backends need
> but I bet they've each got their own surprise.
> 
> (And yes, I'd love to split them up - I tend to use traceing quite a bit
> in migration now and trying to do a bisect over a big migration patch
> series takes ages mostly because of the trace.h changes)

Yes, this is the hard part.  The simpletrace.py pretty-printing script
takes a trace-events file as input.  I suppose it could alphabetically
sort the trace-events filenames from the command-line to produce a
global ordering of trace event IDs.  Of course that doesn't work
properly if the script is invoked with relative paths from a
sub-directory...

Perhaps we need a new script during the QEMU build process that produces
a trace-event-ids.csv file.  Then simpletrace.py could take that instead
of processing ./trace-events.

Stefan


signature.asc
Description: PGP signature


[Qemu-devel] [PATCH for-2.6 05/14] pc-bios/s390-ccw: update virtio implementation to allow up to 3 vrings

2016-03-18 Thread Cornelia Huck
From: "Eugene (jno) Dvurechenski" 

Add ability to work with up to 3 vrings, which is required for
virtio-scsi implementation.
Implement the optional cookie to speed up processing of virtio
notifications.

Reviewed-by: Cornelia Huck 
Signed-off-by: Eugene (jno) Dvurechenski 
Signed-off-by: Cornelia Huck 
---
 pc-bios/s390-ccw/main.c |   1 -
 pc-bios/s390-ccw/s390-ccw.h |   1 -
 pc-bios/s390-ccw/virtio.c   | 140 +++-
 pc-bios/s390-ccw/virtio.h   |   4 ++
 4 files changed, 90 insertions(+), 56 deletions(-)

diff --git a/pc-bios/s390-ccw/main.c b/pc-bios/s390-ccw/main.c
index 7f192f3..6bf44a7 100644
--- a/pc-bios/s390-ccw/main.c
+++ b/pc-bios/s390-ccw/main.c
@@ -12,7 +12,6 @@
 #include "virtio.h"
 
 char stack[PAGE_SIZE * 8] __attribute__((__aligned__(PAGE_SIZE)));
-char ring_area[PAGE_SIZE * 8] __attribute__((__aligned__(PAGE_SIZE)));
 uint64_t boot_value;
 static SubChannelId blk_schid = { .one = 1 };
 
diff --git a/pc-bios/s390-ccw/s390-ccw.h b/pc-bios/s390-ccw/s390-ccw.h
index a5c0684..3e00d42 100644
--- a/pc-bios/s390-ccw/s390-ccw.h
+++ b/pc-bios/s390-ccw/s390-ccw.h
@@ -61,7 +61,6 @@ void consume_sclp_int(void);
 void panic(const char *string);
 void write_subsystem_identification(void);
 extern char stack[PAGE_SIZE * 8] __attribute__((__aligned__(PAGE_SIZE)));
-extern char ring_area[PAGE_SIZE * 8] __attribute__((__aligned__(PAGE_SIZE)));
 extern uint64_t boot_value;
 
 /* sclp-ascii.c */
diff --git a/pc-bios/s390-ccw/virtio.c b/pc-bios/s390-ccw/virtio.c
index 64c6e07..d366aa3 100644
--- a/pc-bios/s390-ccw/virtio.c
+++ b/pc-bios/s390-ccw/virtio.c
@@ -11,29 +11,35 @@
 #include "s390-ccw.h"
 #include "virtio.h"
 
-static VRing block;
+static VRing block[VIRTIO_MAX_VQS];
+static char ring_area[VIRTIO_RING_SIZE * VIRTIO_MAX_VQS]
+ __attribute__((__aligned__(PAGE_SIZE)));
+static int nr_vqs = 1;
 
 static char chsc_page[PAGE_SIZE] __attribute__((__aligned__(PAGE_SIZE)));
 
+/* virtio spec v1.0 para 4.3.3.2 */
 static long kvm_hypercall(unsigned long nr, unsigned long param1,
-  unsigned long param2)
+  unsigned long param2, unsigned long param3)
 {
 register ulong r_nr asm("1") = nr;
 register ulong r_param1 asm("2") = param1;
 register ulong r_param2 asm("3") = param2;
+register ulong r_param3 asm("4") = param3;
 register long retval asm("2");
 
 asm volatile ("diag 2,4,0x500"
   : "=d" (retval)
-  : "d" (r_nr), "0" (r_param1), "r"(r_param2)
+  : "d" (r_nr), "0" (r_param1), "r"(r_param2), "d"(r_param3)
   : "memory", "cc");
 
 return retval;
 }
 
-static void virtio_notify(SubChannelId schid)
+static long virtio_notify(SubChannelId schid, int vq_idx, long cookie)
 {
-kvm_hypercall(KVM_S390_VIRTIO_CCW_NOTIFY, *(u32 *)&schid, 0);
+return kvm_hypercall(KVM_S390_VIRTIO_CCW_NOTIFY, *(u32 *)&schid,
+ vq_idx, cookie);
 }
 
 /***
@@ -106,15 +112,17 @@ static void virtio_reset(SubChannelId schid)
 run_ccw(schid, CCW_CMD_VDEV_RESET, NULL, 0);
 }
 
-static void vring_init(VRing *vr, unsigned int num, void *p,
-   unsigned long align)
+static void vring_init(VRing *vr, VqInfo *info)
 {
+void *p = (void *) info->queue;
+
 debug_print_addr("init p", p);
-vr->num = num;
+vr->id = info->index;
+vr->num = info->num;
 vr->desc = p;
-vr->avail = p + num * sizeof(VRingDesc);
-vr->used = (void *)(((unsigned long)&vr->avail->ring[num] + align-1)
-& ~(align - 1));
+vr->avail = p + info->num * sizeof(VRingDesc);
+vr->used = (void *)(((unsigned long)&vr->avail->ring[info->num]
+   + info->align - 1) & ~(info->align - 1));
 
 /* Zero out all relevant field */
 vr->avail->flags = 0;
@@ -125,13 +133,15 @@ static void vring_init(VRing *vr, unsigned int num, void 
*p,
 vr->used->idx = 0;
 vr->used_idx = 0;
 vr->next_idx = 0;
+vr->cookie = 0;
 
 debug_print_addr("init vr", vr);
 }
 
-static void vring_notify(SubChannelId schid)
+static bool vring_notify(VRing *vr)
 {
-virtio_notify(schid);
+vr->cookie = virtio_notify(vr->schid, vr->id, vr->cookie);
+return vr->cookie >= 0;
 }
 
 static void vring_send_buf(VRing *vr, void *p, int len, int flags)
@@ -167,6 +177,21 @@ ulong get_second(void)
 return (get_clock() >> 12) / 100;
 }
 
+static int vr_poll(VRing *vr)
+{
+if (vr->used->idx == vr->used_idx) {
+vring_notify(vr);
+yield();
+return 0;
+}
+
+vr->used_idx = vr->used->idx;
+vr->next_idx = 0;
+vr->desc[0].len = 0;
+vr->desc[0].flags = 0;
+return 1; /* vr has been updated */
+}
+
 /*
  * Wait for the host to reply.
  *
@@ -174,28 +199,24 @@ ulong get_second(void)
  *
  * Returns 0 on success, 1 on timeout.
  */
-static int vring_wait_reply(VRing *vr, int timeout)
+static int vri

Re: [Qemu-devel] [PATCH 00/15] Clean up around osdep.h and qemu-common.h

2016-03-18 Thread Paolo Bonzini


On 18/03/2016 10:05, Peter Maydell wrote:
> If Paolo wants to provide an R-by I'm happy to take them for
> 2.6 -- the possible failure modes are basically just "something
> stops compiling" which should be an easy fix if it happens.
> You could make my life easier by sticking them in a pullreq.

Reviewed-by: Paolo Bonzini 

A bunch more of files need qapi/error.h now, but it's mechanical so no
need to repost.

Paolo



Re: [Qemu-devel] [PATCH 4/5] tcg: reorder removal from lists in tb_phys_invalidate

2016-03-18 Thread Sergey Fedorov

On 17/03/16 18:09, Paolo Bonzini wrote:


On 17/03/2016 14:46, sergey.fedo...@linaro.org wrote:

  void tb_phys_invalidate(TranslationBlock *tb, tb_page_addr_t page_addr)
  {
-CPUState *cpu;
  PageDesc *p;
  unsigned int h, n1;
+tb_page_addr_t pc;
  tb_page_addr_t phys_pc;
  TranslationBlock *tb1, *tb2;
  
-/* remove the TB from the hash list */

-phys_pc = tb->page_addr[0] + (tb->pc & ~TARGET_PAGE_MASK);
-h = tb_phys_hash_func(phys_pc);
-tb_hash_remove(&tcg_ctx.tb_ctx.tb_phys_hash[h], tb);
-
-/* remove the TB from the page list */
-if (tb->page_addr[0] != page_addr) {
-p = page_find(tb->page_addr[0] >> TARGET_PAGE_BITS);
-tb_page_remove(&p->first_tb, tb);
-invalidate_page_bitmap(p);
-}
-if (tb->page_addr[1] != -1 && tb->page_addr[1] != page_addr) {
-p = page_find(tb->page_addr[1] >> TARGET_PAGE_BITS);
-tb_page_remove(&p->first_tb, tb);
-invalidate_page_bitmap(p);
-}
-
-tcg_ctx.tb_ctx.tb_invalidated_flag = 1;
-

Did you investigate the removal of this setting of tb_invalidated_flag?

My recollection is that it is okay to remove it because at worse it
would cause a tb_add_jump from an invalidated source to a valid
destination.  This should be harmless as long as the source has been
tb_phys_invalidated and not tb_flushed.  But this needs to be checked.


Thanks for pointing that. I should investigate it to make sure, although 
arm32/arm64/x86_64 Linux boots fine as well as the latest Alex's 
kmv-unit-tests pass.


Kind regards,
Sergey



[Qemu-devel] [PULL 33/40] ivshmem: Inline check_shm_size() into its only caller

2016-03-18 Thread Markus Armbruster
Improve the error messages while there.

Signed-off-by: Markus Armbruster 
Message-Id: <1458066895-20632-34-git-send-email-arm...@redhat.com>
Reviewed-by: Marc-André Lureau 
---
 hw/misc/ivshmem.c | 37 +++--
 1 file changed, 11 insertions(+), 26 deletions(-)

diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index 1b1de65..e6282ab 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -343,29 +343,6 @@ static void watch_vector_notifier(IVShmemState *s, 
EventNotifier *n,
 NULL, &s->msi_vectors[vector]);
 }
 
-static int check_shm_size(IVShmemState *s, int fd, Error **errp)
-{
-/* check that the guest isn't going to try and map more memory than the
- * the object has allocated return -1 to indicate error */
-
-struct stat buf;
-
-if (fstat(fd, &buf) < 0) {
-error_setg(errp, "exiting: fstat on fd %d failed: %s",
-   fd, strerror(errno));
-return -1;
-}
-
-if (s->ivshmem_size > buf.st_size) {
-error_setg(errp, "Requested memory size greater"
-   " than shared object size (%zu > %" PRIu64")",
-   s->ivshmem_size, (uint64_t)buf.st_size);
-return -1;
-} else {
-return 0;
-}
-}
-
 static void ivshmem_add_eventfd(IVShmemState *s, int posn, int i)
 {
 memory_region_add_eventfd(&s->ivshmem_mmio,
@@ -480,7 +457,7 @@ static void setup_interrupt(IVShmemState *s, int vector, 
Error **errp)
 
 static void process_msg_shmem(IVShmemState *s, int fd, Error **errp)
 {
-Error *err = NULL;
+struct stat buf;
 void *ptr;
 
 if (s->ivshmem_bar2) {
@@ -489,8 +466,16 @@ static void process_msg_shmem(IVShmemState *s, int fd, 
Error **errp)
 return;
 }
 
-if (check_shm_size(s, fd, &err) == -1) {
-error_propagate(errp, err);
+if (fstat(fd, &buf) < 0) {
+error_setg_errno(errp, errno,
+"can't determine size of shared memory sent by server");
+close(fd);
+return;
+}
+
+if (s->ivshmem_size > buf.st_size) {
+error_setg(errp, "server sent only %zd bytes of shared memory",
+   (size_t)buf.st_size);
 close(fd);
 return;
 }
-- 
2.4.3




[Qemu-devel] [PULL 13/21] hw/intc: Add (new) ASPEED VIC device model

2016-03-18 Thread Peter Maydell
From: Andrew Jeffery 

Implement a basic ASPEED VIC device model for the AST2400 SoC[1], with
enough functionality to boot an aspeed_defconfig Linux kernel. The model
implements the 'new' (revised) register set: While the hardware exposes
both the new and legacy register sets, accesses to the model's legacy
register set will not be serviced (however the access will be logged).

[1] http://www.aspeedtech.com/products.php?fPath=20&rId=376

Signed-off-by: Andrew Jeffery 
Message-id: 1458096317-25223-3-git-send-email-and...@aj.id.au
Reviewed-by: Peter Maydell 
Signed-off-by: Peter Maydell 
---
 hw/intc/Makefile.objs|   1 +
 hw/intc/aspeed_vic.c | 339 +++
 include/hw/intc/aspeed_vic.h |  48 ++
 trace-events |   7 +
 4 files changed, 395 insertions(+)
 create mode 100644 hw/intc/aspeed_vic.c
 create mode 100644 include/hw/intc/aspeed_vic.h

diff --git a/hw/intc/Makefile.objs b/hw/intc/Makefile.objs
index 6a13a39..0e47f0f 100644
--- a/hw/intc/Makefile.objs
+++ b/hw/intc/Makefile.objs
@@ -31,3 +31,4 @@ obj-$(CONFIG_XICS_KVM) += xics_kvm.o
 obj-$(CONFIG_ALLWINNER_A10_PIC) += allwinner-a10-pic.o
 obj-$(CONFIG_S390_FLIC) += s390_flic.o
 obj-$(CONFIG_S390_FLIC_KVM) += s390_flic_kvm.o
+obj-$(CONFIG_ASPEED_SOC) += aspeed_vic.o
diff --git a/hw/intc/aspeed_vic.c b/hw/intc/aspeed_vic.c
new file mode 100644
index 000..19a0ff7
--- /dev/null
+++ b/hw/intc/aspeed_vic.c
@@ -0,0 +1,339 @@
+/*
+ * ASPEED Interrupt Controller (New)
+ *
+ * Andrew Jeffery 
+ *
+ * Copyright 2015, 2016 IBM Corp.
+ *
+ * This code is licensed under the GPL version 2 or later.  See
+ * the COPYING file in the top-level directory.
+ */
+
+/* The hardware exposes two register sets, a legacy set and a 'new' set. The
+ * model implements the 'new' register set, and logs warnings on accesses to
+ * the legacy IO space.
+ *
+ * The hardware uses 32bit registers to manage 51 IRQs, with low and high
+ * registers for each conceptual register. The device model's implementation
+ * uses 64bit data types to store both low and high register values (in the one
+ * member), but must cope with access offset values in multiples of 4 passed to
+ * the callbacks. As such the read() and write() implementations process the
+ * provided offset to understand whether the access is requesting the lower or
+ * upper 32 bits of the 64bit member.
+ *
+ * Additionally, the "Interrupt Enable", "Edge Status" and "Software Interrupt"
+ * fields have separate "enable"/"status" and "clear" registers, where set bits
+ * are written to one or the other to change state (avoiding a
+ * read-modify-write sequence).
+ */
+
+#include "qemu/osdep.h"
+#include 
+#include "hw/intc/aspeed_vic.h"
+#include "qemu/bitops.h"
+#include "trace.h"
+
+#define AVIC_NEW_BASE_OFFSET 0x80
+
+#define AVIC_L_MASK 0xU
+#define AVIC_H_MASK 0x0007U
+#define AVIC_EVENT_W_MASK (0x78000ULL << 32)
+
+static void aspeed_vic_update(AspeedVICState *s)
+{
+uint64_t new = (s->raw & s->enable);
+uint64_t flags;
+
+flags = new & s->select;
+trace_aspeed_vic_update_fiq(!!flags);
+qemu_set_irq(s->fiq, !!flags);
+
+flags = new & ~s->select;
+trace_aspeed_vic_update_irq(!!flags);
+qemu_set_irq(s->irq, !!flags);
+}
+
+static void aspeed_vic_set_irq(void *opaque, int irq, int level)
+{
+uint64_t irq_mask;
+bool raise;
+AspeedVICState *s = (AspeedVICState *)opaque;
+
+if (irq > ASPEED_VIC_NR_IRQS) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: Invalid interrupt number: %d\n",
+  __func__, irq);
+return;
+}
+
+trace_aspeed_vic_set_irq(irq, level);
+
+irq_mask = BIT(irq);
+if (s->sense & irq_mask) {
+/* level-triggered */
+if (s->event & irq_mask) {
+/* high-sensitive */
+raise = level;
+} else {
+/* low-sensitive */
+raise = !level;
+}
+s->raw = deposit64(s->raw, irq, 1, raise);
+} else {
+uint64_t old_level = s->level & irq_mask;
+
+/* edge-triggered */
+if (s->dual_edge & irq_mask) {
+raise = (!!old_level) != (!!level);
+} else {
+if (s->event & irq_mask) {
+/* rising-sensitive */
+raise = !old_level && level;
+} else {
+/* falling-sensitive */
+raise = old_level && !level;
+}
+}
+if (raise) {
+s->raw = deposit64(s->raw, irq, 1, raise);
+}
+}
+s->level = deposit64(s->level, irq, 1, level);
+aspeed_vic_update(s);
+}
+
+static uint64_t aspeed_vic_read(void *opaque, hwaddr offset, unsigned size)
+{
+uint64_t val;
+const bool high = !!(offset & 0x4);
+hwaddr n_offset = (offset & ~0x4);
+AspeedVICState *s = (AspeedVICState *)opaque;
+
+if (offset < AVIC_NEW_BASE_OFFSET) {
+qemu_log_mask(LOG_UNIMP, "%s: Ignoring read from legacy registers "
+ 

[Qemu-devel] [PATCH v5 1/7] block: add flag to indicate that no I/O will be performed

2016-03-18 Thread Daniel P. Berrange
When opening an image it is useful to know whether the caller
intends to perform I/O on the image or not. In the case of
encrypted images this will allow the block driver to avoid
having to prompt for decryption keys when we merely want to
query header metadata about the image. eg qemu-img info

This flag is enforced at the top level only, since even if
we don't want todo I/O on the 'qcow2' file payload, the
underlying 'file' driver will still need todo I/O to read
the qcow2 header, for example.

Reviewed-by: Eric Blake 
Signed-off-by: Daniel P. Berrange 
---
 block.c   |  5 +++--
 block/io.c|  2 ++
 include/block/block.h |  1 +
 qemu-img.c| 44 ++--
 4 files changed, 28 insertions(+), 24 deletions(-)

diff --git a/block.c b/block.c
index 59a18a3..4d1a9d3 100644
--- a/block.c
+++ b/block.c
@@ -706,7 +706,8 @@ static void bdrv_inherited_options(int *child_flags, QDict 
*child_options,
 flags |= BDRV_O_UNMAP;
 
 /* Clear flags that only apply to the top layer */
-flags &= ~(BDRV_O_SNAPSHOT | BDRV_O_NO_BACKING | BDRV_O_COPY_ON_READ);
+flags &= ~(BDRV_O_SNAPSHOT | BDRV_O_NO_BACKING | BDRV_O_COPY_ON_READ |
+   BDRV_O_NO_IO);
 
 *child_flags = flags;
 }
@@ -726,7 +727,7 @@ static void bdrv_inherited_fmt_options(int *child_flags, 
QDict *child_options,
 child_file.inherit_options(child_flags, child_options,
parent_flags, parent_options);
 
-*child_flags &= ~BDRV_O_PROTOCOL;
+*child_flags &= ~(BDRV_O_PROTOCOL | BDRV_O_NO_IO);
 }
 
 const BdrvChildRole child_format = {
diff --git a/block/io.c b/block/io.c
index a69bfc4..010e25a 100644
--- a/block/io.c
+++ b/block/io.c
@@ -862,6 +862,7 @@ static int coroutine_fn 
bdrv_aligned_preadv(BlockDriverState *bs,
 assert((offset & (BDRV_SECTOR_SIZE - 1)) == 0);
 assert((bytes & (BDRV_SECTOR_SIZE - 1)) == 0);
 assert(!qiov || bytes == qiov->size);
+assert((bs->open_flags & BDRV_O_NO_IO) == 0);
 
 /* Handle Copy on Read and associated serialisation */
 if (flags & BDRV_REQ_COPY_ON_READ) {
@@ -1148,6 +1149,7 @@ static int coroutine_fn 
bdrv_aligned_pwritev(BlockDriverState *bs,
 assert((offset & (BDRV_SECTOR_SIZE - 1)) == 0);
 assert((bytes & (BDRV_SECTOR_SIZE - 1)) == 0);
 assert(!qiov || bytes == qiov->size);
+assert((bs->open_flags & BDRV_O_NO_IO) == 0);
 
 waited = wait_serialising_requests(req);
 assert(!waited || !req->serialising);
diff --git a/include/block/block.h b/include/block/block.h
index eaa6426..bb8e97d 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -93,6 +93,7 @@ typedef struct HDGeometry {
 #define BDRV_O_PROTOCOL0x8000  /* if no block driver is explicitly given:
   select an appropriate protocol driver,
   ignoring the format layer */
+#define BDRV_O_NO_IO   0x1 /* don't initialize for I/O */
 
 #define BDRV_O_CACHE_MASK  (BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NO_FLUSH)
 
diff --git a/qemu-img.c b/qemu-img.c
index 3103150..a03e501 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -224,13 +224,13 @@ static int print_block_option_help(const char *filename, 
const char *fmt)
 
 
 static int img_open_password(BlockBackend *blk, const char *filename,
- bool require_io, bool quiet)
+ int flags, bool quiet)
 {
 BlockDriverState *bs;
 char password[256];
 
 bs = blk_bs(blk);
-if (bdrv_is_encrypted(bs) && require_io) {
+if (bdrv_is_encrypted(bs) && !(flags & BDRV_O_NO_IO)) {
 qprintf(quiet, "Disk image '%s' is encrypted.\n", filename);
 if (qemu_read_password(password, sizeof(password)) < 0) {
 error_report("No password given");
@@ -248,7 +248,7 @@ static int img_open_password(BlockBackend *blk, const char 
*filename,
 static BlockBackend *img_open_opts(const char *id,
const char *optstr,
QemuOpts *opts, int flags,
-   bool require_io, bool quiet)
+   bool quiet)
 {
 QDict *options;
 Error *local_err = NULL;
@@ -260,7 +260,7 @@ static BlockBackend *img_open_opts(const char *id,
 return NULL;
 }
 
-if (img_open_password(blk, optstr, require_io, quiet) < 0) {
+if (img_open_password(blk, optstr, flags, quiet) < 0) {
 blk_unref(blk);
 return NULL;
 }
@@ -269,7 +269,7 @@ static BlockBackend *img_open_opts(const char *id,
 
 static BlockBackend *img_open_file(const char *id, const char *filename,
const char *fmt, int flags,
-   bool require_io, bool quiet)
+   bool quiet)
 {
 BlockBackend *blk;
 Error *local_err = NULL;
@@ -286,7 +286,7 @@ static BlockBackend *img_open_file(const char *id, c

Re: [Qemu-devel] [PATCH] qemu-ga: drop unused local err variable

2016-03-18 Thread Michael Roth
Quoting Stefan Hajnoczi (2016-03-16 10:16:02)
> Commit 125b310e1d62e3a1dc1e7758563e598957ca7ae4 ("qemu-ga: move
> channel/transport functionality into wrapper class") stopped using the
> local err variable in channel_event_cb().
> 
> This patch deletes the unused variable.
> 
> Signed-off-by: Stefan Hajnoczi 

Thanks, applied to qga tree:

  https://github.com/mdroth/qemu/commits/qga

> ---
>  qga/main.c | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/qga/main.c b/qga/main.c
> index 0a168e2..743c5c1 100644
> --- a/qga/main.c
> +++ b/qga/main.c
> @@ -618,13 +618,7 @@ static gboolean channel_event_cb(GIOCondition condition, 
> gpointer data)
>  GAState *s = data;
>  gchar buf[QGA_READ_COUNT_DEFAULT+1];
>  gsize count;
> -GError *err = NULL;
>  GIOStatus status = ga_channel_read(s->channel, buf, 
> QGA_READ_COUNT_DEFAULT, &count);
> -if (err != NULL) {
> -g_warning("error reading channel: %s", err->message);
> -g_error_free(err);
> -return false;
> -}
>  switch (status) {
>  case G_IO_STATUS_ERROR:
>  g_warning("error reading channel");
> -- 
> 2.5.0
> 




[Qemu-devel] [PULL 10/40] ivshmem: Rewrite specification document

2016-03-18 Thread Markus Armbruster
This started as an attempt to update ivshmem_device_spec.txt for
clarity, accuracy and completeness while working on its code, and
quickly became a full rewrite.  Since the diff would be useless
anyway, I'm using the opportunity to rename the file to
ivshmem-spec.txt.

I tried hard to ensure the new text contradicts neither the old text
nor the code.  If the new text contradicts the old text but not the
code, it's probably a bug in the old text.  If the new text
contradicts both, its probably a bug in the new text.

Signed-off-by: Markus Armbruster 
Reviewed-by: Marc-André Lureau 
Message-Id: <1458066895-20632-11-git-send-email-arm...@redhat.com>
---
 docs/specs/ivshmem-spec.txt| 243 +
 docs/specs/ivshmem_device_spec.txt | 161 
 2 files changed, 243 insertions(+), 161 deletions(-)
 create mode 100644 docs/specs/ivshmem-spec.txt
 delete mode 100644 docs/specs/ivshmem_device_spec.txt

diff --git a/docs/specs/ivshmem-spec.txt b/docs/specs/ivshmem-spec.txt
new file mode 100644
index 000..0e9185a
--- /dev/null
+++ b/docs/specs/ivshmem-spec.txt
@@ -0,0 +1,243 @@
+= Device Specification for Inter-VM shared memory device =
+
+The Inter-VM shared memory device (ivshmem) is designed to share a
+memory region between multiple QEMU processes running different guests
+and the host.  In order for all guests to be able to pick up the
+shared memory area, it is modeled by QEMU as a PCI device exposing
+said memory to the guest as a PCI BAR.
+
+The device can use a shared memory object on the host directly, or it
+can obtain one from an ivshmem server.
+
+In the latter case, the device can additionally interrupt its peers, and
+get interrupted by its peers.
+
+
+== Configuring the ivshmem PCI device ==
+
+There are two basic configurations:
+
+- Just shared memory: -device ivshmem,shm=NAME,...
+
+  This uses shared memory object NAME.
+
+- Shared memory plus interrupts: -device ivshmem,chardev=CHR,vectors=N,...
+
+  An ivshmem server must already be running on the host.  The device
+  connects to the server's UNIX domain socket via character device
+  CHR.
+
+  Each peer gets assigned a unique ID by the server.  IDs must be
+  between 0 and 65535.
+
+  Interrupts are message-signaled by default (MSI-X).  With msi=off
+  the device has no MSI-X capability, and uses legacy INTx instead.
+  vectors=N configures the number of vectors to use.
+
+For more details on ivshmem device properties, see The QEMU Emulator
+User Documentation (qemu-doc.*).
+
+
+== The ivshmem PCI device's guest interface ==
+
+The device has vendor ID 1af4, device ID 1110, revision 0.
+
+=== PCI BARs ===
+
+The ivshmem PCI device has two or three BARs:
+
+- BAR0 holds device registers (256 Byte MMIO)
+- BAR1 holds MSI-X table and PBA (only when using MSI-X)
+- BAR2 maps the shared memory object
+
+There are two ways to use this device:
+
+- If you only need the shared memory part, BAR2 suffices.  This way,
+  you have access to the shared memory in the guest and can use it as
+  you see fit.  Memnic, for example, uses ivshmem this way from guest
+  user space (see http://dpdk.org/browse/memnic).
+
+- If you additionally need the capability for peers to interrupt each
+  other, you need BAR0 and, if using MSI-X, BAR1.  You will most
+  likely want to write a kernel driver to handle interrupts.  Requires
+  the device to be configured for interrupts, obviously.
+
+If the device is configured for interrupts, BAR2 is initially invalid.
+It becomes safely accessible only after the ivshmem server provided
+the shared memory.  Guest software should wait for the IVPosition
+register (described below) to become non-negative before accessing
+BAR2.
+
+The device is not capable to tell guest software whether it is
+configured for interrupts.
+
+=== PCI device registers ===
+
+BAR 0 contains the following registers:
+
+Offset  Size  Access  On reset  Function
+0 4   read/write0   Interrupt Mask
+bit 0: peer interrupt
+bit 1..31: reserved
+4 4   read/write0   Interrupt Status
+bit 0: peer interrupt
+bit 1..31: reserved
+8 4   read-only   0 or -1   IVPosition
+   12 4   write-only  N/A   Doorbell
+bit 0..15: vector
+bit 16..31: peer ID
+   16   240   noneN/A   reserved
+
+Software should only access the registers as specified in column
+"Access".  Reserved bits should be ignored on read, and preserved on
+write.
+
+Interrupt Status and Mask Register together control the legacy INTx
+interrupt when the device has no MSI-X capability: INTx is asserted
+when the bit-wise AND of Status and Mask is non-zero and the device
+has no MSI-X capability.  Interrupt Status Register bit 0 

[Qemu-devel] [PULL v2 07/13] crypto: add support for the serpent cipher algorithm

2016-03-18 Thread Daniel P. Berrange
New cipher algorithms 'serpent-128', 'serpent-192' and
'serpent-256' are defined for the Serpent algorithm.

The nettle and gcrypt cipher backends are updated to
support the new cipher and a test vector added to the
cipher test suite. The new algorithm is enabled in the
LUKS block encryption driver.

Reviewed-by: Eric Blake 
Reviewed-by: Fam Zheng 
Signed-off-by: Daniel P. Berrange 
---
 crypto/cipher-gcrypt.c | 18 ++
 crypto/cipher-nettle.c | 31 +++
 crypto/cipher.c|  6 ++
 qapi/crypto.json   |  6 +-
 tests/test-crypto-cipher.c | 39 +++
 5 files changed, 99 insertions(+), 1 deletion(-)

diff --git a/crypto/cipher-gcrypt.c b/crypto/cipher-gcrypt.c
index aa1d8c5..a667d59 100644
--- a/crypto/cipher-gcrypt.c
+++ b/crypto/cipher-gcrypt.c
@@ -30,6 +30,9 @@ bool qcrypto_cipher_supports(QCryptoCipherAlgorithm alg)
 case QCRYPTO_CIPHER_ALG_AES_192:
 case QCRYPTO_CIPHER_ALG_AES_256:
 case QCRYPTO_CIPHER_ALG_CAST5_128:
+case QCRYPTO_CIPHER_ALG_SERPENT_128:
+case QCRYPTO_CIPHER_ALG_SERPENT_192:
+case QCRYPTO_CIPHER_ALG_SERPENT_256:
 return true;
 default:
 return false;
@@ -89,6 +92,18 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorithm alg,
 gcryalg = GCRY_CIPHER_CAST5;
 break;
 
+case QCRYPTO_CIPHER_ALG_SERPENT_128:
+gcryalg = GCRY_CIPHER_SERPENT128;
+break;
+
+case QCRYPTO_CIPHER_ALG_SERPENT_192:
+gcryalg = GCRY_CIPHER_SERPENT192;
+break;
+
+case QCRYPTO_CIPHER_ALG_SERPENT_256:
+gcryalg = GCRY_CIPHER_SERPENT256;
+break;
+
 default:
 error_setg(errp, "Unsupported cipher algorithm %d", alg);
 return NULL;
@@ -122,6 +137,9 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorithm 
alg,
 case QCRYPTO_CIPHER_ALG_AES_128:
 case QCRYPTO_CIPHER_ALG_AES_192:
 case QCRYPTO_CIPHER_ALG_AES_256:
+case QCRYPTO_CIPHER_ALG_SERPENT_128:
+case QCRYPTO_CIPHER_ALG_SERPENT_192:
+case QCRYPTO_CIPHER_ALG_SERPENT_256:
 ctx->blocksize = 16;
 break;
 case QCRYPTO_CIPHER_ALG_CAST5_128:
diff --git a/crypto/cipher-nettle.c b/crypto/cipher-nettle.c
index cfa69cc..74b55ab 100644
--- a/crypto/cipher-nettle.c
+++ b/crypto/cipher-nettle.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #if CONFIG_NETTLE_VERSION_MAJOR < 3
 typedef nettle_crypt_func nettle_cipher_func;
@@ -76,6 +77,18 @@ static void cast128_decrypt_wrapper(cipher_ctx_t ctx, 
cipher_length_t length,
 cast128_decrypt(ctx, length, dst, src);
 }
 
+static void serpent_encrypt_wrapper(cipher_ctx_t ctx, cipher_length_t length,
+uint8_t *dst, const uint8_t *src)
+{
+serpent_encrypt(ctx, length, dst, src);
+}
+
+static void serpent_decrypt_wrapper(cipher_ctx_t ctx, cipher_length_t length,
+uint8_t *dst, const uint8_t *src)
+{
+serpent_decrypt(ctx, length, dst, src);
+}
+
 typedef struct QCryptoCipherNettle QCryptoCipherNettle;
 struct QCryptoCipherNettle {
 void *ctx_encrypt;
@@ -94,6 +107,9 @@ bool qcrypto_cipher_supports(QCryptoCipherAlgorithm alg)
 case QCRYPTO_CIPHER_ALG_AES_192:
 case QCRYPTO_CIPHER_ALG_AES_256:
 case QCRYPTO_CIPHER_ALG_CAST5_128:
+case QCRYPTO_CIPHER_ALG_SERPENT_128:
+case QCRYPTO_CIPHER_ALG_SERPENT_192:
+case QCRYPTO_CIPHER_ALG_SERPENT_256:
 return true;
 default:
 return false;
@@ -169,6 +185,21 @@ QCryptoCipher *qcrypto_cipher_new(QCryptoCipherAlgorithm 
alg,
 
 ctx->blocksize = CAST128_BLOCK_SIZE;
 break;
+
+case QCRYPTO_CIPHER_ALG_SERPENT_128:
+case QCRYPTO_CIPHER_ALG_SERPENT_192:
+case QCRYPTO_CIPHER_ALG_SERPENT_256:
+ctx->ctx_encrypt = g_new0(struct serpent_ctx, 1);
+ctx->ctx_decrypt = NULL; /* 1 ctx can do both */
+
+serpent_set_key(ctx->ctx_encrypt, nkey, key);
+
+ctx->alg_encrypt = serpent_encrypt_wrapper;
+ctx->alg_decrypt = serpent_decrypt_wrapper;
+
+ctx->blocksize = SERPENT_BLOCK_SIZE;
+break;
+
 default:
 error_setg(errp, "Unsupported cipher algorithm %d", alg);
 goto error;
diff --git a/crypto/cipher.c b/crypto/cipher.c
index 9e0a226..0f6fe98 100644
--- a/crypto/cipher.c
+++ b/crypto/cipher.c
@@ -28,6 +28,9 @@ static size_t alg_key_len[QCRYPTO_CIPHER_ALG__MAX] = {
 [QCRYPTO_CIPHER_ALG_AES_256] = 32,
 [QCRYPTO_CIPHER_ALG_DES_RFB] = 8,
 [QCRYPTO_CIPHER_ALG_CAST5_128] = 16,
+[QCRYPTO_CIPHER_ALG_SERPENT_128] = 16,
+[QCRYPTO_CIPHER_ALG_SERPENT_192] = 24,
+[QCRYPTO_CIPHER_ALG_SERPENT_256] = 32,
 };
 
 static size_t alg_block_len[QCRYPTO_CIPHER_ALG__MAX] = {
@@ -36,6 +39,9 @@ static size_t alg_block_len[QCRYPTO_CIPHER_ALG__MAX] = {
 [QCRYPTO_CIPHER_ALG_AES_256] = 16,
 [QCRYPTO_CIPHER_ALG_DES_RFB] = 8,
 [QCRYPTO_CIPHER_ALG_CAST5_128] = 8

[Qemu-devel] [PATCH v2 10/16] nfs: replace aio_poll with bdrv_drain

2016-03-18 Thread Paolo Bonzini
Reviewed-by: Fam Zheng 
Signed-off-by: Paolo Bonzini 
---
 block/nfs.c | 50 ++
 1 file changed, 30 insertions(+), 20 deletions(-)

diff --git a/block/nfs.c b/block/nfs.c
index 7220e89..5cebb83 100644
--- a/block/nfs.c
+++ b/block/nfs.c
@@ -48,6 +48,7 @@ typedef struct NFSClient {
 } NFSClient;
 
 typedef struct NFSRPC {
+BlockDriverState *bs;
 int ret;
 int complete;
 QEMUIOVector *iov;
@@ -87,11 +88,12 @@ static void nfs_process_write(void *arg)
 nfs_set_events(client);
 }
 
-static void nfs_co_init_task(NFSClient *client, NFSRPC *task)
+static void nfs_co_init_task(BlockDriverState *bs, NFSRPC *task)
 {
 *task = (NFSRPC) {
 .co = qemu_coroutine_self(),
-.client = client,
+.bs = bs,
+.client = bs->opaque,
 };
 }
 
@@ -109,6 +111,7 @@ nfs_co_generic_cb(int ret, struct nfs_context *nfs, void 
*data,
 {
 NFSRPC *task = private_data;
 task->ret = ret;
+assert(!task->st);
 if (task->ret > 0 && task->iov) {
 if (task->ret <= task->iov->size) {
 qemu_iovec_from_buf(task->iov, 0, data, task->ret);
@@ -116,19 +119,12 @@ nfs_co_generic_cb(int ret, struct nfs_context *nfs, void 
*data,
 task->ret = -EIO;
 }
 }
-if (task->ret == 0 && task->st) {
-memcpy(task->st, data, sizeof(struct stat));
-}
 if (task->ret < 0) {
 error_report("NFS Error: %s", nfs_get_error(nfs));
 }
-if (task->co) {
-task->bh = aio_bh_new(task->client->aio_context,
-  nfs_co_generic_bh_cb, task);
-qemu_bh_schedule(task->bh);
-} else {
-task->complete = 1;
-}
+task->bh = aio_bh_new(task->client->aio_context,
+  nfs_co_generic_bh_cb, task);
+qemu_bh_schedule(task->bh);
 }
 
 static int coroutine_fn nfs_co_readv(BlockDriverState *bs,
@@ -138,7 +134,7 @@ static int coroutine_fn nfs_co_readv(BlockDriverState *bs,
 NFSClient *client = bs->opaque;
 NFSRPC task;
 
-nfs_co_init_task(client, &task);
+nfs_co_init_task(bs, &task);
 task.iov = iov;
 
 if (nfs_pread_async(client->context, client->fh,
@@ -173,7 +169,7 @@ static int coroutine_fn nfs_co_writev(BlockDriverState *bs,
 NFSRPC task;
 char *buf = NULL;
 
-nfs_co_init_task(client, &task);
+nfs_co_init_task(bs, &task);
 
 buf = g_try_malloc(nb_sectors * BDRV_SECTOR_SIZE);
 if (nb_sectors && buf == NULL) {
@@ -209,7 +205,7 @@ static int coroutine_fn nfs_co_flush(BlockDriverState *bs)
 NFSClient *client = bs->opaque;
 NFSRPC task;
 
-nfs_co_init_task(client, &task);
+nfs_co_init_task(bs, &task);
 
 if (nfs_fsync_async(client->context, client->fh, nfs_co_generic_cb,
 &task) != 0) {
@@ -469,6 +465,21 @@ static int nfs_has_zero_init(BlockDriverState *bs)
 return client->has_zero_init;
 }
 
+static void
+nfs_get_allocated_file_size_cb(int ret, struct nfs_context *nfs, void *data,
+   void *private_data)
+{
+NFSRPC *task = private_data;
+task->ret = ret;
+if (task->ret == 0) {
+memcpy(task->st, data, sizeof(struct stat));
+}
+if (task->ret < 0) {
+error_report("NFS Error: %s", nfs_get_error(nfs));
+}
+bdrv_dec_in_flight(task->bs);
+}
+
 static int64_t nfs_get_allocated_file_size(BlockDriverState *bs)
 {
 NFSClient *client = bs->opaque;
@@ -480,16 +491,15 @@ static int64_t 
nfs_get_allocated_file_size(BlockDriverState *bs)
 return client->st_blocks * 512;
 }
 
+bdrv_inc_in_flight(bs);
+task.bs = bs;
 task.st = &st;
-if (nfs_fstat_async(client->context, client->fh, nfs_co_generic_cb,
+if (nfs_fstat_async(client->context, client->fh, 
nfs_get_allocated_file_size_cb,
 &task) != 0) {
 return -ENOMEM;
 }
 
-while (!task.complete) {
-nfs_set_events(client);
-aio_poll(client->aio_context, true);
-}
+bdrv_drain(bs);
 
 return (task.ret < 0 ? task.ret : st.st_blocks * 512);
 }
-- 
1.8.3.1





[Qemu-devel] [PATCH v4 00/17] blockdev: Further BlockBackend work

2016-03-18 Thread Max Reitz
This series appears to reinvent itself with every revision. This time,
its main implication is that BBs are no longer automatically treated as
monitor-owned, and that a BB's name is tightly tied to the monitor
reference (it is considered equivalent to that reference).


v4:
- Tightly tied a BB's name to the monitor reference [Kevin]
  - Added two patches from my "blockdev: (Nearly) free clean-up work"
series which are required so a BB does not need to have a name when
bdrv_open() is invoked for its BDS tree
- Added a missing monitor_remove_blk() to the error path of
  hmp_drive_add() [Kevin]
- v3 just made blk_backends contain all BBs and then added another
  list called monitor_block_backends. v4 instead renames blk_backends to
  monitor_block_backends (because both are supposed to be the same,
  basically) and then adds a new list containing all BBs.
  [Markus/Kevin]
- blk_hide_on_behalf_of_hmp_drive_del() does a bit more than what
  monitor_remove_blk() does; namely, it invokes bdrv_make_anon() on the
  BDS. We should probably continue to do so.
- Use blk_is_inserted() instead of blk_is_available() for
  blk_commit_all() [Kevin]


Patch justifications:
- 1: General clean-up.
- 2: Clean-up which is nice to have for patch 7 which renames
 blk_backends to monitor_block_backends.
- 3: In order to move bdrv_commit_all() to the BB level (patch 12),
 first we need to introduce a BB-level function...
- 4: ...and then we have to use it.
- 5: After this series, BBs will no longer have a name before
 monitor_add_blk() is called; therefore, we should not try to print
 the device name when an image is opened (the filename is more
 interesting anyway)
- 6: Similarily to patch 5, this removes the device name from an error
 message emitted during image opening.
- 7: blk_backends to me personally implies this was a list of all
 BlockBackends. It actually is not. Therefore, this patch renames it
 to a more precise monitor_block_backends.
- 8: As this series makes it more clear that not all BlockBackends need
 to be referenced by the monitor, this patch consequently adds a
 list of truly and unconditionally all BlockBackends for whenever we
 need to iterate through really all of them.
- 9: This patch moves the name management for BlockBackends from
 blk_new(), blk_delete() and blk_hide_on_behalf_of_hmp_drive_del()
 into new functions monitor_add_blk() and monitor_remove_blk().
 These functions are still invoked in blk_new() etc., so nothing
 changes to the outside yet.
- 10: This patch drops the implicit calls of monitor_add_blk() and
  monitor_remove_blk() and thus makes the distinction between a BB's
  existence and whether it is owned by the monitor externally
  visible.
- 11: Clean-up patch.
- 12: More or less a clean-up patch.
- 13: Required so we can drop bdrv_states.
- 14: Required so we can drop bdrv_states.
- 15: Required so we can drop bdrv_states.
- 16: Clean-up and required so we can drop bdrv_states.
- 17: Clean-up and preparation for the follow-up series.


git backport-diff against v3:

Key:
[] : patches are identical
[] : number of functional differences between upstream/downstream patch
[down] : patch is downstream-only
The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively

001/17:[] [--] 'monitor: Use BB list for BB name completion'
002/17:[down] 'block: Use blk_next() in block-backend.c'
003/17:[] [--] 'block: Add blk_commit_all()'
004/17:[] [--] 'block: Use blk_{commit,flush}_all() consistently'
005/17:[down] 'qapi: Drop QERR_UNKNOWN_BLOCK_FORMAT_FEATURE'
006/17:[down] 'block: Drop BB name from bad option error'
007/17:[down] 'blockdev: Rename blk_backends'
008/17:[down] 'blockdev: Add list of all BlockBackends'
009/17:[down] 'blockdev: Separate BB name management'
010/17:[down] 'blockdev: Split monitor reference from BB creation'
011/17:[0014] [FC] 'blockdev: Remove blk_hide_on_behalf_of_hmp_drive_del()'
012/17:[0002] [FC] 'block: Move some bdrv_*_all() functions to BB'
013/17:[0002] [FC] 'block: Add bdrv_next_monitor_owned()'
014/17:[] [-C] 'block: Add blk_next_root_bs()'
015/17:[] [--] 'block: Rewrite bdrv_next()'
016/17:[] [--] 'block: Use bdrv_next() instead of bdrv_states'
017/17:[] [-C] 'block: Remove bdrv_states list'


Max Reitz (17):
  monitor: Use BB list for BB name completion
  block: Use blk_next() in block-backend.c
  block: Add blk_commit_all()
  block: Use blk_{commit,flush}_all() consistently
  qapi: Drop QERR_UNKNOWN_BLOCK_FORMAT_FEATURE
  block: Drop BB name from bad option error
  blockdev: Rename blk_backends
  blockdev: Add list of all BlockBackends
  blockdev: Separate BB name management
  blockdev: Split monitor reference from BB creation
  blockdev: Remove blk_hide_on_behalf_of_hmp_drive_del()
  block: Move some bdrv_*_all() functions to BB
  block: Add bdrv_next_monitor_owned()
  block: Add blk_next_root_bs()
  block: Rewrite bdrv_next(

Re: [Qemu-devel] [PATCH 0/2] e1000: Introducing an upper bound of interrupts

2016-03-18 Thread Denis V. Lunev

On 03/17/2016 10:37 AM, Sameeh Jubran wrote:

This patch series introduces an upper bound for the number of interrupts
per second. This feature is supported by the real hardware, however up
until now it wasn't implemented in e1000. This feature is very
significant, it can prevent an interrupt storm by giving the driver
a bounded inter-interrupt interval to handle interrupts.

This patch was made after observing an interrupt storm in Windows 10
when disabling e1000.

How reproducible:

Steps to reproduce:
1. Start Win 10 guest with e1000 device.
2. Go to device manager and try to disable and enable the device.
3. After several enable/disable to the device the guest hangs when
the device is being disabled.

Actual results:
Guest hang after click OK button.

Expected results:
Device is disabled.

After applying the patch the guest no longer hangs, and an Iperf test
ran successfully.

Sameeh Jubran (2):
   e1000: Fixing interrupts pace.
   Revert "e1000: fix hang of win2k12 shutdown with flood ping"

  hw/net/e1000.c | 13 -
  1 file changed, 8 insertions(+), 5 deletions(-)


In general I support the idea to have the minimal limit
and drop original patch.

Though I'd better keep the same delay as it was. The limit
for physical card is good for physical card. They have
limitations which are not available in virtualization
world.

AFAIR I have used 250 as the number from the article
of the original author of ITR support as the best value.

Den



Re: [Qemu-devel] [PATCH v4 6/9] hw/timer: QOM'ify milkymist_sysctl

2016-03-18 Thread michael
[I had some problems with my mailserver and the v5 version didn't make 
it through. I know there is a v5 version of this patch series and I've 
tested with the v5 version]


Am 2016-02-22 04:15, schrieb xiaoqiang zhao:

* split the old SysBus init function into an instance_init
  and a Device realize function
* use DeviceClass::realize instead of SysBusDeviceClass::init

Reviewed-by: Peter Maydell 
Signed-off-by: xiaoqiang zhao 


Acked-by: Michael Walle 
Tested-by: Michael Walle 

-michael



[Qemu-devel] [PULL 08/29] block: Drop BB name from bad option error

2016-03-18 Thread Kevin Wolf
From: Max Reitz 

The information which BB is concerned does not seem useful enough to
justify its existence in most other place (which may be related to qemu
printing the -drive parameter in question anyway, and for blockdev-add
the attribution is naturally unambiguous). Furthermore, as of a future
patch, bdrv_get_device_name(bs) will always return the empty string
before bdrv_open_inherit() returns.

Therefore, just dropping that information seems to be the best course of
action.

Signed-off-by: Max Reitz 
Signed-off-by: Kevin Wolf 
---
 block.c   | 6 +++---
 tests/qemu-iotests/051.out| 8 
 tests/qemu-iotests/051.pc.out | 8 
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/block.c b/block.c
index 59a18a3..582a9e8 100644
--- a/block.c
+++ b/block.c
@@ -1671,9 +1671,9 @@ static int bdrv_open_inherit(BlockDriverState **pbs, 
const char *filename,
 error_setg(errp, "Block protocol '%s' doesn't support the option "
"'%s'", drv->format_name, entry->key);
 } else {
-error_setg(errp, "Block format '%s' used by device '%s' doesn't "
-   "support the option '%s'", drv->format_name,
-   bdrv_get_device_name(bs), entry->key);
+error_setg(errp,
+   "Block format '%s' does not support the option '%s'",
+   drv->format_name, entry->key);
 }
 
 ret = -EINVAL;
diff --git a/tests/qemu-iotests/051.out b/tests/qemu-iotests/051.out
index 0f8a8d3..c1291ff 100644
--- a/tests/qemu-iotests/051.out
+++ b/tests/qemu-iotests/051.out
@@ -5,16 +5,16 @@ Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 
backing_file=TEST_DIR/
 === Unknown option ===
 
 Testing: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=,if=none,id=drive0
-QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=,if=none,id=drive0: Block format 
'qcow2' used by device 'drive0' doesn't support the option 'unknown_opt'
+QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=,if=none,id=drive0: Block format 
'qcow2' does not support the option 'unknown_opt'
 
 Testing: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=on,if=none,id=drive0
-QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=on,if=none,id=drive0: Block 
format 'qcow2' used by device 'drive0' doesn't support the option 'unknown_opt'
+QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=on,if=none,id=drive0: Block 
format 'qcow2' does not support the option 'unknown_opt'
 
 Testing: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=1234,if=none,id=drive0
-QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=1234,if=none,id=drive0: Block 
format 'qcow2' used by device 'drive0' doesn't support the option 'unknown_opt'
+QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=1234,if=none,id=drive0: Block 
format 'qcow2' does not support the option 'unknown_opt'
 
 Testing: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=foo,if=none,id=drive0
-QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=foo,if=none,id=drive0: Block 
format 'qcow2' used by device 'drive0' doesn't support the option 'unknown_opt'
+QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=foo,if=none,id=drive0: Block 
format 'qcow2' does not support the option 'unknown_opt'
 
 
 === Unknown protocol option ===
diff --git a/tests/qemu-iotests/051.pc.out b/tests/qemu-iotests/051.pc.out
index 85fc05d..73cc15a 100644
--- a/tests/qemu-iotests/051.pc.out
+++ b/tests/qemu-iotests/051.pc.out
@@ -5,16 +5,16 @@ Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 
backing_file=TEST_DIR/
 === Unknown option ===
 
 Testing: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=,if=none,id=drive0
-QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=,if=none,id=drive0: Block format 
'qcow2' used by device 'drive0' doesn't support the option 'unknown_opt'
+QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=,if=none,id=drive0: Block format 
'qcow2' does not support the option 'unknown_opt'
 
 Testing: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=on,if=none,id=drive0
-QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=on,if=none,id=drive0: Block 
format 'qcow2' used by device 'drive0' doesn't support the option 'unknown_opt'
+QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=on,if=none,id=drive0: Block 
format 'qcow2' does not support the option 'unknown_opt'
 
 Testing: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=1234,if=none,id=drive0
-QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=1234,if=none,id=drive0: Block 
format 'qcow2' used by device 'drive0' doesn't support the option 'unknown_opt'
+QEMU_PROG: -drive 
file=TEST_DIR/t.qcow2,format=qcow2,unknown_opt=1234,if=none,id=drive0: Block 
format 'qcow2' does 

[Qemu-devel] [PATCH for-2.6 08/14] pc-bios/s390-ccw: add simplified virtio call

2016-03-18 Thread Cornelia Huck
From: "Eugene (jno) Dvurechenski" 

Add virtio_run(VirtioCmd) call to use simple declarative approach.

Signed-off-by: Eugene (jno) Dvurechenski 
Signed-off-by: Cornelia Huck 
---
 pc-bios/s390-ccw/virtio.c | 17 +
 pc-bios/s390-ccw/virtio.h |  9 +
 2 files changed, 26 insertions(+)

diff --git a/pc-bios/s390-ccw/virtio.c b/pc-bios/s390-ccw/virtio.c
index 56734af..4ab4d47 100644
--- a/pc-bios/s390-ccw/virtio.c
+++ b/pc-bios/s390-ccw/virtio.c
@@ -225,6 +225,23 @@ static int vring_wait_reply(void)
 return 1;
 }
 
+int virtio_run(VDev *vdev, int vqid, VirtioCmd *cmd)
+{
+VRing *vr = &vdev->vrings[vqid];
+int i = 0;
+
+do {
+vring_send_buf(vr, cmd[i].data, cmd[i].size,
+   cmd[i].flags | (i ? VRING_HIDDEN_IS_CHAIN : 0));
+} while (cmd[i++].flags & VRING_DESC_F_NEXT);
+
+vring_wait_reply();
+if (drain_irqs(vr->schid)) {
+return -1;
+}
+return 0;
+}
+
 /***
  *   Virtio block  *
  ***/
diff --git a/pc-bios/s390-ccw/virtio.h b/pc-bios/s390-ccw/virtio.h
index 7b227db..57c71a2 100644
--- a/pc-bios/s390-ccw/virtio.h
+++ b/pc-bios/s390-ccw/virtio.h
@@ -248,4 +248,13 @@ typedef struct VDev VDev;
 VDev *virtio_get_device(void);
 VirtioDevType virtio_get_device_type(void);
 
+struct VirtioCmd {
+void *data;
+int size;
+int flags;
+};
+typedef struct VirtioCmd VirtioCmd;
+
+int virtio_run(VDev *vdev, int vqid, VirtioCmd *cmd);
+
 #endif /* VIRTIO_H */
-- 
2.7.4




Re: [Qemu-devel] [PATCH v4] net: Allocating Large sized arrays to heap

2016-03-18 Thread Stefan Hajnoczi
On Thu, Mar 17, 2016 at 09:17:40PM +0530, Pooja Dhannawat wrote:
> nc_sendv_compat has a huge stack usage of 69680 bytes approx.
> Moving large arrays to heap to reduce stack usage.
> 
> Signed-off-by: Pooja Dhannawat 
> ---
>  net/net.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature


[Qemu-devel] [PULL 06/21] i.MX: Allow GPT timer to rollover.

2016-03-18 Thread Peter Maydell
From: Jean-Christophe Dubois 

GPT timer need to rollover when it reaches 0x.

It also need to reset to 0 when in "restart mode" and crossing the
compare 1 register.

Reviewed-by: Peter Maydell 
Signed-off-by: Jean-Christophe Dubois 
Message-id: 
6e2b36117a249a78bf822dd59a390368f407136e.1456868959.git@tribudubois.net
Signed-off-by: Peter Maydell 
---
 hw/timer/imx_gpt.c | 27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/hw/timer/imx_gpt.c b/hw/timer/imx_gpt.c
index 5cdc3b3..916577b 100644
--- a/hw/timer/imx_gpt.c
+++ b/hw/timer/imx_gpt.c
@@ -134,7 +134,7 @@ static inline uint32_t imx_gpt_find_limit(uint32_t count, 
uint32_t reg,
 static void imx_gpt_compute_next_timeout(IMXGPTState *s, bool event)
 {
 uint32_t timeout = GPT_TIMER_MAX;
-uint32_t count = 0;
+uint32_t count;
 long long limit;
 
 if (!(s->cr & GPT_CR_EN)) {
@@ -142,20 +142,23 @@ static void imx_gpt_compute_next_timeout(IMXGPTState *s, 
bool event)
 return;
 }
 
-if (event) {
-/* This is a timer event  */
+/* update the count */
+count = imx_gpt_update_count(s);
 
-if ((s->cr & GPT_CR_FRR)  && (s->next_timeout != GPT_TIMER_MAX)) {
-/*
- * if we are in free running mode and we have not reached
- * the GPT_TIMER_MAX limit, then update the count
+if (event) {
+/*
+ * This is an event (the ptimer reached 0 and stopped), and the
+ * timer counter is now equal to s->next_timeout.
+ */
+if (!(s->cr & GPT_CR_FRR) && (count == s->ocr1)) {
+/* We are in restart mode and we crossed the compare channel 1
+ * value. We need to reset the counter to 0.
  */
-count = imx_gpt_update_count(s);
+count = s->cnt = s->next_timeout = 0;
+} else if (count == GPT_TIMER_MAX) {
+/* We reached GPT_TIMER_MAX so we need to rollover */
+count = s->cnt = s->next_timeout = 0;
 }
-} else {
-/* not a timer event, then just update the count */
-
-count = imx_gpt_update_count(s);
 }
 
 /* now, find the next timeout related to count */
-- 
1.9.1




[Qemu-devel] [RFC v1 00/11] Base enabling patches for MTTCG

2016-03-18 Thread Alex Bennée
Hi,

This RFC patch set aims to provide the basic framework for MTTCG. I've
tried to pull together the non-contentious bits that other trees can
then build on. This is because we have multiple potential solutions
for things like deferring work and handling atomics. The idea being
that those bits could be added on and when a given architecture combo
is ready multi-threading can be turned on automatically for known good
combinations. Without the additional work just blindly turning on
MTTCG is likely to fail horribly ;-)

The branch can be found at:

  https://github.com/stsquad/qemu/tree/mttcg/base-patches-v1

It has Serge's tcg-cleanups branch as it's base as those are TCG
clean-ups not directly tied to MTTCG which will hopefully get merged
in due course well before these patches.

The main changes I've made from Fred's last tree are:
  - a new option -tcg mttcg=on|off
  - the kick timer to prevent lock clean-ups breaking single-threaded -smp
  - pulled in a fix from Emilio for locking interrupt handling

Where I've made tweaks to existing patches I've added [] comments and
some revision history below the ---.

What's left
===

This series still boots a full virtio based Debian arm in single
threaded mode although currently "shutdown -h now" hangs once the
guest is shutdown as the iowait hangs on the final condition.

There are a few checkpatch things that need to be addressed with
regards to barrier comments.

Any comments welcome, does this look like a sane approach? Can we
agree a common base on which everything else can be built on?

Cheers,

Alex

Alex Bennée (3):
  target-arm/psci.c: wake up sleeping CPUs
  tcg: cpus rm tcg_exec_all()
  tcg: add kick timer for single-threaded vCPU emulation

Emilio G. Cota (1):
  tcg: grab iothread lock in cpu-exec interrupt handling

KONRAD Frederic (5):
  tcg: move tb_find_fast outside the tb_lock critical section
  tcg: protect TBContext with tb_lock.
  tcg: add options for enabling MTTCG
  tcg: drop global lock during TCG code execution
  tcg: enable thread-per-vCPU

Paolo Bonzini (2):
  cpu-exec: elide more icount code if CONFIG_USER_ONLY
  tcg: comment on which functions have to be called with tb_lock held

 cpu-exec-common.c   |   1 -
 cpu-exec.c  | 128 +--
 cpus.c  | 323 +++-
 cputlb.c|   4 +
 exec.c  |  16 +++
 hw/i386/kvmvapic.c  |   6 +
 include/exec/exec-all.h |   5 +-
 include/qom/cpu.h   |  20 +++
 include/sysemu/cpus.h   |   2 +
 qemu-options.hx |  14 +++
 softmmu_template.h  |  17 +++
 target-arm/psci.c   |   2 +
 tcg/tcg.h   |   3 +
 translate-all.c | 110 +
 vl.c|  12 +-
 15 files changed, 477 insertions(+), 186 deletions(-)

-- 
2.7.3




[Qemu-devel] [PULL 07/40] ivshmem-test: Improve test case /ivshmem/single

2016-03-18 Thread Markus Armbruster
Test state of registers after reset.

Test reading Interrupt Status clears it.

Test (invalid) read of Doorbell.

Add more comments.

Signed-off-by: Markus Armbruster 
Reviewed-by: Marc-André Lureau 
Message-Id: <1458066895-20632-8-git-send-email-arm...@redhat.com>
---
 tests/ivshmem-test.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/tests/ivshmem-test.c b/tests/ivshmem-test.c
index da6ca0d..a48dc49 100644
--- a/tests/ivshmem-test.c
+++ b/tests/ivshmem-test.c
@@ -143,32 +143,41 @@ static void test_ivshmem_single(void)
 setup_vm(&state);
 s = &state;
 
-/* valid io */
-out_reg(s, INTRMASK, 0);
-in_reg(s, INTRSTATUS);
-in_reg(s, IVPOSITION);
+/* initial state of readable registers */
+g_assert_cmpuint(in_reg(s, INTRMASK), ==, 0);
+g_assert_cmpuint(in_reg(s, INTRSTATUS), ==, 0);
+g_assert_cmpuint(in_reg(s, IVPOSITION), ==, 0);
 
+/* trigger interrupt via registers */
 out_reg(s, INTRMASK, 0x);
 g_assert_cmpuint(in_reg(s, INTRMASK), ==, 0x);
 out_reg(s, INTRSTATUS, 1);
-/* XXX: intercept IRQ, not seen in resp */
+/* check interrupt status */
 g_assert_cmpuint(in_reg(s, INTRSTATUS), ==, 1);
+/* reading clears */
+g_assert_cmpuint(in_reg(s, INTRSTATUS), ==, 0);
+/* TODO intercept actual interrupt (needs qtest work) */
 
-/* invalid io */
+/* invalid register access */
 out_reg(s, IVPOSITION, 1);
+in_reg(s, DOORBELL);
+
+/* ring the (non-functional) doorbell */
 out_reg(s, DOORBELL, 8 << 16);
 
+/* write shared memory */
 for (i = 0; i < G_N_ELEMENTS(data); i++) {
 data[i] = i;
 }
 qtest_memwrite(s->qtest, (uintptr_t)s->mem_base, data, sizeof(data));
 
+/* verify write */
 for (i = 0; i < G_N_ELEMENTS(data); i++) {
 g_assert_cmpuint(((uint32_t *)tmpshmem)[i], ==, i);
 }
 
+/* read it back and verify read */
 memset(data, 0, sizeof(data));
-
 qtest_memread(s->qtest, (uintptr_t)s->mem_base, data, sizeof(data));
 for (i = 0; i < G_N_ELEMENTS(data); i++) {
 g_assert_cmpuint(data[i], ==, i);
-- 
2.4.3




[Qemu-devel] [PULL 19/21] bcm2835_property: implement framebuffer control/configuration properties

2016-03-18 Thread Peter Maydell
From: Grégory ESTRADE 

The property channel driver now interfaces with the framebuffer device
to query and set framebuffer parameters. As a result of this, the "get
ARM RAM size" query now correctly returns the video RAM base address
(not total RAM size), and the ram-size property is no longer relevant
here.

Signed-off-by: Grégory ESTRADE 
Reviewed-by: Peter Maydell 
Signed-off-by: Andrew Baumann 
Message-id: 1457467526-8840-5-git-send-email-andrew.baum...@microsoft.com
[AB: cleanup/refactoring for upstream submission]
Signed-off-by: Andrew Baumann 
Reviewed-by: Peter Maydell 
Signed-off-by: Peter Maydell 
---
 hw/arm/bcm2835_peripherals.c   |   8 +--
 hw/arm/raspi.c |   7 +-
 hw/misc/bcm2835_property.c | 139 -
 include/hw/misc/bcm2835_property.h |   5 +-
 4 files changed, 144 insertions(+), 15 deletions(-)

diff --git a/hw/arm/bcm2835_peripherals.c b/hw/arm/bcm2835_peripherals.c
index c2fe6b7..4d74a18 100644
--- a/hw/arm/bcm2835_peripherals.c
+++ b/hw/arm/bcm2835_peripherals.c
@@ -79,6 +79,8 @@ static void bcm2835_peripherals_init(Object *obj)
   "board-rev", &error_abort);
 qdev_set_parent_bus(DEVICE(&s->property), sysbus_get_default());
 
+object_property_add_const_link(OBJECT(&s->property), "fb",
+   OBJECT(&s->fb), &error_abort);
 object_property_add_const_link(OBJECT(&s->property), "dma-mr",
OBJECT(&s->gpu_bus_mr), &error_abort);
 
@@ -211,12 +213,6 @@ static void bcm2835_peripherals_realize(DeviceState *dev, 
Error **errp)
qdev_get_gpio_in(DEVICE(&s->mboxes), MBOX_CHAN_FB));
 
 /* Property channel */
-object_property_set_int(OBJECT(&s->property), ram_size, "ram-size", &err);
-if (err) {
-error_propagate(errp, err);
-return;
-}
-
 object_property_set_bool(OBJECT(&s->property), true, "realized", &err);
 if (err) {
 error_propagate(errp, err);
diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 5498209..83fe809 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -164,11 +164,6 @@ static void raspi2_machine_init(MachineClass *mc)
 mc->no_floppy = 1;
 mc->no_cdrom = 1;
 mc->max_cpus = BCM2836_NCPUS;
-
-/* XXX: Temporary restriction in RAM size from the full 1GB. Since
- * we do not yet support the framebuffer / GPU, we need to limit
- * RAM usable by the OS to sit below the peripherals.
- */
-mc->default_ram_size = 0x3F00; /* BCM2836_PERI_BASE */
+mc->default_ram_size = 1024 * 1024 * 1024;
 };
 DEFINE_MACHINE("raspi2", raspi2_machine_init)
diff --git a/hw/misc/bcm2835_property.c b/hw/misc/bcm2835_property.c
index 41fbbe3..15dcc02 100644
--- a/hw/misc/bcm2835_property.c
+++ b/hw/misc/bcm2835_property.c
@@ -17,6 +17,11 @@ static void bcm2835_property_mbox_push(BCM2835PropertyState 
*s, uint32_t value)
 uint32_t tot_len;
 size_t resplen;
 uint32_t tmp;
+int n;
+uint32_t offset, length, color;
+uint32_t xres, yres, xoffset, yoffset, bpp, pixo, alpha;
+uint32_t *newxres = NULL, *newyres = NULL, *newxoffset = NULL,
+*newyoffset = NULL, *newbpp = NULL, *newpixo = NULL, *newalpha = NULL;
 
 value &= ~0xf;
 
@@ -60,7 +65,14 @@ static void bcm2835_property_mbox_push(BCM2835PropertyState 
*s, uint32_t value)
 /* base */
 stl_le_phys(&s->dma_as, value + 12, 0);
 /* size */
-stl_le_phys(&s->dma_as, value + 16, s->ram_size);
+stl_le_phys(&s->dma_as, value + 16, s->fbdev->vcram_base);
+resplen = 8;
+break;
+case 0x00010006: /* Get VC memory */
+/* base */
+stl_le_phys(&s->dma_as, value + 12, s->fbdev->vcram_base);
+/* size */
+stl_le_phys(&s->dma_as, value + 16, s->fbdev->vcram_size);
 resplen = 8;
 break;
 case 0x00028001: /* Set power state */
@@ -122,6 +134,114 @@ static void 
bcm2835_property_mbox_push(BCM2835PropertyState *s, uint32_t value)
 resplen = 8;
 break;
 
+/* Frame buffer */
+
+case 0x00040001: /* Allocate buffer */
+stl_le_phys(&s->dma_as, value + 12, s->fbdev->base);
+stl_le_phys(&s->dma_as, value + 16, s->fbdev->size);
+resplen = 8;
+break;
+case 0x00048001: /* Release buffer */
+resplen = 0;
+break;
+case 0x00040002: /* Blank screen */
+resplen = 4;
+break;
+case 0x00040003: /* Get display width/height */
+case 0x00040004:
+stl_le_phys(&s->dma_as, value + 12, s->fbdev->xres);
+stl_le_phys(&s->dma_as, value + 16, s->fbdev->yres);
+resplen = 8;
+break;
+case 0x00044003: /* Test display width/height */
+case 0x00044004:
+resplen = 8;
+break;
+case 0x000

Re: [Qemu-devel] [PATCH 2/5] trace: [all] Add "guest_vmem" event

2016-03-18 Thread Lluís Vilanova
Peter Maydell writes:

> On 23 February 2016 at 18:22, Lluís Vilanova  wrote:
>> Signed-off-by: Lluís Vilanova 

>> +### Guest events, keep at bottom
>> +
>> +# @vaddr: Access' virtual address.
>> +# @size : Access' size (bytes).
>> +# @store: Whether the access is a store.
>> +#
>> +# Start virtual memory access (before any potential access violation).
>> +#
>> +# Does not include memory accesses performed by devices.
>> +#
>> +# Targets: TCG(all)
>> +disable vcpu tcg guest_vmem(TCGv vaddr, uint8_t size, uint8_t store) 
>> "size=%d store=%d", "vaddr=0x%016"PRIx64" size=%d store=%d"

> Shouldn't we also be tracing some of the other information in the memop?
> In particular, endianness of the access seems useful. You could also
> say whether we're zero- or sign-extending the access, though I guess
> you could defend not printing that since we don't print anything about
> what the target- code does with the loaded data.

> Otherwise I think this looks OK (though the various paths memory accesses
> take are a bit opaque since I've forgotten how this bit of QEMU works).

M, the endianness seems more of a vCPU property than one of the memory
access. A separate event could be added for that (e.g., at vCPU
initalization/hot-plug and whenever it is dynamically changed like in ARM).

For the sign extension and memory value, what about adding multiple events?
What I did for instructions is have a simple event and one with extended
information, so that we can tweak performance of a tracing QEMU by choosing one
or the other.  We could do the same for memory accesses (e.g., also show the
memory value, sign extension and physical address).



Re: [Qemu-devel] [PATCH v5 6/7] block: add generic full disk encryption driver

2016-03-18 Thread Daniel P. Berrange
On Fri, Mar 18, 2016 at 01:09:35PM +0100, Kevin Wolf wrote:
> Am 17.03.2016 um 18:51 hat Daniel P. Berrange geschrieben:
> > Add a block driver that is capable of supporting any full disk
> > encryption format. This utilizes the previously added block
> > encryption code, and at this time supports the LUKS format.
> > 
> > The driver code is capable of supporting any format supported
> > by the QCryptoBlock module, so it registers one block driver
> > for each format. This patch only registers the "luks" driver
> > since the "qcow" driver is there only for back-compatibility
> > with existing qcow built-in encryption.
> > 
> > New LUKS compatible volumes can be formatted using qemu-img
> > with defaults for all settings.
> > 
> > $ qemu-img create --object secret,data=123456,id=sec0 \
> >   -f luks -o key-secret=sec0 demo.luks 10G
> > 
> > Alternatively the cryptographic settings can be explicitly
> > set
> > 
> > $ qemu-img create --object secret,data=123456,id=sec0 \
> >   -f luks -o key-secret=sec0,cipher-alg=aes-256,\
> >  cipher-mode=cbc,ivgen-alg=plain64,hash-alg=sha256 \
> >   demo.luks 10G
> > 
> > And query its size
> > 
> > $ qemu-img info demo.img
> > image: demo.img
> > file format: luks
> > virtual size: 10G (10737418240 bytes)
> > disk size: 132K
> > encrypted: yes
> > 
> > Note that it was not necessary to provide the password
> > when querying info for the volume. The password is only
> > required when performing I/O on the volume
> > 
> > All volumes created by this new 'luks' driver should be
> > capable of being opened by the kernel dm-crypt driver.
> > 
> > The only algorithms listed in the LUKS spec that are
> > not currently supported by this impl are sha512 and
> > ripemd160 hashes and cast6 cipher.
> > 
> > A new I/O test is added which is used to validate the
> > interoperability of the QEMU implementation of LUKS,
> > with the dm-crypt/cryptsetup implementation. Due to
> > the need to run cryptsetup as root, this test requires
> > that the user have password-less sudo configured.
> > 
> > The test is set to only run against the 'luks' format
> > so needs to be manually invoked with
> > 
> >   cd tests/qemu-iotests
> >   ./check -luks 149
> > 
> > Reviewed-by: Eric Blake 
> > Signed-off-by: Daniel P. Berrange 
> 
> This is a huge patch. I'm not sure if it wouldn't be better to split off
> the test. I also think that having some test cases that don't require
> root privileges would be helpful, so maybe the test can be split in two
> halves as well, one requiring passwordless sudo and the other without
> special requirements.

I can certainly split off the test, however, I don't think it can be
split into 2 as you describe, as both halves of the two require sudo
privileges. So in one half we're creating images with dm-crypt and
processing them with qemu, and in the other half we're creating images
with qemu-img and processing them with dm-crypt.

This test was specifically designed to validate dm-crypt interoperability,
and my intention was that "pure" QEMU block driver testing of it would be
covered by the various pre-existing I/O tests. The problem is that I need
to update those existing tests to know how to pass the right args to
qemu-img to setup passwords. If I can do that, then we'll have some good
testing cover of the luks driver without needing sudo.

So I'll look at converting a couple of key pre-existing tests to get
such coverage, and put this test in its own patch.


> > +static ssize_t block_crypto_init_func(QCryptoBlock *block,
> > +  size_t headerlen,
> > +  Error **errp,
> > +  void *opaque)
> > +{
> > +struct BlockCryptoCreateData *data = opaque;
> > +int ret;
> > +
> > +/* User provided size should reflect amount of space made
> > + * available to the guest, so we must take account of that
> > + * which will be used by the crypto header
> > + */
> > +data->size += headerlen;
> > +
> > +qemu_opt_set_number(data->opts, BLOCK_OPT_SIZE, data->size, 
> > &error_abort);
> > +ret = bdrv_create_file(data->filename, data->opts, errp);
> > +if (ret < 0) {
> > +return -1;
> > +}
> > +
> > +ret = bdrv_open(&data->bs, data->filename, NULL, NULL,
> > +BDRV_O_RDWR | BDRV_O_PROTOCOL, errp);
> 
> We should probably use blk_open() here like the other image format
> drivers do now, and preferably use blk_*() functions to access the
> image.
> 
> You will also want to specify BDRV_O_CACHE_WB (while it exists, I'm
> going to remove it soon).

Ok, will do.


> > +static QCryptoBlockOpenOptions *
> > +block_crypto_open_opts_init(QCryptoBlockFormat format,
> > +QemuOpts *opts,
> > +Error **errp)
> > +{
> > +OptsVisitor *ov;
> > +QCryptoBlockOpenOptions *ret = NULL;
> > +Error *local_err = NULL;
> > +
> > +ret =

Re: [Qemu-devel] [PATCH v2] firmware: qemu_fw_cfg.c: hold ACPI global lock during device access

2016-03-18 Thread Gabriel L. Somlo
On Wed, Mar 16, 2016 at 06:57:01PM +0200, Michael S. Tsirkin wrote:
> On Tue, Mar 08, 2016 at 01:30:50PM -0500, Gabriel Somlo wrote:
> > Allowing for the future possibility of implementing AML-based
> > (i.e., firmware-triggered) access to the QEMU fw_cfg device,
> > acquire the global ACPI lock when accessing the device on behalf
> > of the guest-side sysfs driver, to prevent any potential race
> > conditions.
> > 
> > Suggested-by: Michael S. Tsirkin 
> > Signed-off-by: Gabriel Somlo 
> 
> So this patch makes sense of course.
> 
> 
> Given the recent discussion on QEMU mailing list,
> I think there is an additional patch that we need:
> filter the files exposed to userspace by "opt/" prefix.
> 
> This will ensure that we can change all other fw cfg files
> at will without breaking guest scripts.
> 
> Gabriel, could you code this up? Or do you see a
> pressing need to expose internal QEMU registers to
> userspace?

I'd be happy to update the docs to (better) emphasisze that:

1 the only way to guarantee any particular item shows up in
  guest-side fw_cfg sysfs is manually putting it there via the
  host-side command line

- and BTW, unless you prefixed it with "opt/..." you
  are off the reservation, and it might collide with
  qemu->firmware communications.

2 anything one didn't place there themselves via the qemu
  command line is informational only, might change or go away
  at any time, and developing expectations about it based on
  past observation is done at the observer's own risk.

While I don't *personally* care about items outside of "opt/", I'm a bit
uncomfortable actively *hiding* them from userspace -- I could easily
imagine the ability to see (read-only) fw_cfg content from userspace
being a handy debugging/troubleshooting tool. It's back to separating
between mechanism and policy: hiding things from userspace would IMHO
fall into the policy enforcement side of things, and I'm still unclear
about the failure scenario we'd be trying to prevent, and its likelihood.

Thanks,
--Gabriel
 
> > ---
> > 
> > Changes since v1:
> > - no more "#ifdef CONFIG_ACPI"; instead we proceed if
> >   acpi_acquire_global_lock() returns either OK or NOT_CONFIGURED,
> >   and only throw a warning/error message otherwise.
> > 
> > - didn't get any *negative* feedback from the QEMU crowd, so
> >   this is now a bona-fide "please apply this", rather than just
> >   an RFC :)
> > 
> > - tested on ACPI-enabled x86_64, and acpi_less ARM (32 and 64 bit)
> >   QEMU VMs (I don't have handy access to an ACPI-enabled ARM VM)
> > 
> > Thanks much,
> >   --Gabriel
> > 
> >  drivers/firmware/qemu_fw_cfg.c | 16 
> >  1 file changed, 16 insertions(+)
> > 
> > diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c
> > index 7bba76c..a44dc32 100644
> > --- a/drivers/firmware/qemu_fw_cfg.c
> > +++ b/drivers/firmware/qemu_fw_cfg.c
> > @@ -77,12 +77,28 @@ static inline u16 fw_cfg_sel_endianness(u16 key)
> >  static inline void fw_cfg_read_blob(u16 key,
> > void *buf, loff_t pos, size_t count)
> >  {
> > +   u32 glk;
> > +   acpi_status status;
> > +
> > +   /* If we have ACPI, ensure mutual exclusion against any potential
> > +* device access by the firmware, e.g. via AML methods:
> > +*/
> > +   status = acpi_acquire_global_lock(ACPI_WAIT_FOREVER, &glk);
> > +   if (ACPI_FAILURE(status) && status != AE_NOT_CONFIGURED) {
> > +   /* Should never get here */
> > +   WARN(1, "fw_cfg_read_blob: Failed to lock ACPI!\n");
> > +   memset(buf, 0, count);
> > +   return;
> > +   }
> > +
> > mutex_lock(&fw_cfg_dev_lock);
> > iowrite16(fw_cfg_sel_endianness(key), fw_cfg_reg_ctrl);
> > while (pos-- > 0)
> > ioread8(fw_cfg_reg_data);
> > ioread8_rep(fw_cfg_reg_data, buf, count);
> > mutex_unlock(&fw_cfg_dev_lock);
> > +
> > +   acpi_release_global_lock(glk);
> >  }
> >  
> >  /* clean up fw_cfg device i/o */
> > -- 
> > 2.4.3



Re: [Qemu-devel] Timer interrupts for -M raspi2

2016-03-18 Thread Antonio Huete Jiménez

Hi Andrew,

Yeah, that's what I think. I believe I must be overlooking something  
but I just can't find what.


With regards to the ARM Generic timer, I have set the enable bit[0]  
for CNTP_CTL and also I've set CNTP_TVAL, that's why I think the  
interrupt is triggered on the real hardware.


I'm hoping anywone here can give me a hint on what I might be doing wrong.

In any case thanks a lot for your help and patience :-)

Best regards,
Antonio Huete

Andrew Baumann  escribió:


Hi Antonio,


From: Antonio Huete Jiménez [mailto:tuxi...@quantumachine.net]
Sent: Wednesday, 16 March 2016 4:24 PM

Hi Andrew,

I thought the timer that was not implemented was the local timer
(located at 0x4034) and that the core timers interrupt control
registers starting at 0x4040 were the per-core timers.


Oh, sorry, you're right; I replied too quickly.

Yes, that should work. Bits 0 and 3 are wired up to what qemu refers  
to as GTIMER_PHYS and GTIMER_VIRT respectively. (The other two  
timers aren't currently connected; I can't remember if that's  
because they weren't modelled by core QEMU when I was implementing  
the device model, or just because I wasn't sure how to route them  
and never came back to fix it.)


If you are seeing interrupts on real hardware and not on qemu, then  
it may be because the board performs some additional setup that you  
are relying on. I'm hardly an expert on ARM, but I would imagine you  
need to also need to setup the timer's control and count registers  
(using mcr/mrc) to get it ticking. The write to 0x4040 simply  
enables the interrupt.



Can you please point me to the documentation about this ARM per-core
timers?


Here's a starting point to some docs (just from a quick search):
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0438c/BGBBIJCB.html

Cheers,
Andrew


Andrew Baumann  escribió:

> Hi Antonio,
>
>> From: Antonio Huete Jiménez [mailto:tuxi...@quantumachine.net]
>> Sent: Wednesday, 16 March 2016 3:40 PM
>>
>> Hi,
>>
>> I am experiencing what I think it's an issue with -M raspi2 and
>> interrupts in a baremetal application.
>>
>> According to this document
>>
(https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2
>> 836/QA7_rev3.4.pdf), and if I understood it correctly, you can enable
timer
>> interrupts for core0 by setting bit 0 at 0x4040 and you can trigger
them
>> by using the ARM Generic
>> Timer.
>>
>> With this procedure I can reliably trigger that timer interrupt in the
>> real hardware by setting CNTP_CTL and CNTP_TVAL but on qemu it
doesn't
>> seem to be triggered.
>>
>> Can somebody please tell me what I might be doing wrong?
>
> I don't think you're doing anything wrong; we just don't model this
> timer hardware yet (neither Linux nor Windows needs it). If you want
> to take a stab at adding it, the relevant hardware emulation is
> hw/intc/bcm2836_control.c.
>
> If you're willing to use different timer sources, then I suggest
> looking at the ARM per-core timers. I also have Gregory's emulation
> code for the other bcm2835 timers in my private github, and I hope
> to submit to upstream qemu after the current freeze, since it is
> needed for pi1 Linux support.
>
> Cheers,
> Andrew








[Qemu-devel] [PULL 21/40] ivshmem: Assert interrupts are set up once

2016-03-18 Thread Markus Armbruster
An interrupt is set up when the interrupt's file descriptor is
received.  Each message applies to the next interrupt vector.
Therefore, each vector cannot be set up more than once.

ivshmem_add_kvm_msi_virq() half-heartedly tries not to rely on this by
doing nothing then, but that's not going to recover from this error
should it become possible in the future.  watch_vector_notifier()
doesn't even try.

Simply assert what is the case, so we get alerted if we ever screw it
up.

Signed-off-by: Markus Armbruster 
Reviewed-by: Marc-André Lureau 
Message-Id: <1458066895-20632-22-git-send-email-arm...@redhat.com>
---
 hw/misc/ivshmem.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index 65e3a76..61e21cd 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -349,7 +349,7 @@ static void watch_vector_notifier(IVShmemState *s, 
EventNotifier *n,
 {
 int eventfd = event_notifier_get_fd(n);
 
-/* if MSI is supported we need multiple interrupts */
+assert(!s->msi_vectors[vector].pdev);
 s->msi_vectors[vector].pdev = PCI_DEVICE(s);
 
 qemu_set_fd_handler(eventfd, ivshmem_vector_notify,
@@ -535,10 +535,7 @@ static int ivshmem_add_kvm_msi_virq(IVShmemState *s, int 
vector)
 int ret;
 
 IVSHMEM_DPRINTF("ivshmem_add_kvm_msi_virq vector:%d\n", vector);
-
-if (s->msi_vectors[vector].pdev != NULL) {
-return 0;
-}
+assert(!s->msi_vectors[vector].pdev);
 
 ret = kvm_irqchip_add_msi_route(kvm_state, msg, pdev);
 if (ret < 0) {
-- 
2.4.3




[Qemu-devel] [PULL 21/29] block: Use blk_co_preadv() for blk_read()

2016-03-18 Thread Kevin Wolf
This patch introduces blk_co_preadv() as a central function on the
BlockBackend level that is supposed to handle all read requests from the
BB to its root BDS eventually.

Signed-off-by: Kevin Wolf 
---
 block/block-backend.c | 64 ---
 block/io.c|  5 +---
 include/block/block_int.h |  4 +++
 3 files changed, 65 insertions(+), 8 deletions(-)

diff --git a/block/block-backend.c b/block/block-backend.c
index 5de7850..c058785 100644
--- a/block/block-backend.c
+++ b/block/block-backend.c
@@ -22,6 +22,8 @@
 /* Number of coroutines to reserve per attached device model */
 #define COROUTINE_POOL_RESERVATION 64
 
+#define NOT_DONE 0x7fff /* used while emulated sync operation in progress 
*/
+
 static AioContext *blk_aiocb_get_aio_context(BlockAIOCB *acb);
 
 struct BlockBackend {
@@ -693,15 +695,69 @@ static int blk_check_request(BlockBackend *blk, int64_t 
sector_num,
   nb_sectors * BDRV_SECTOR_SIZE);
 }
 
-int blk_read(BlockBackend *blk, int64_t sector_num, uint8_t *buf,
- int nb_sectors)
+static int coroutine_fn blk_co_preadv(BlockBackend *blk, int64_t offset,
+  unsigned int bytes, QEMUIOVector *qiov,
+  BdrvRequestFlags flags)
 {
-int ret = blk_check_request(blk, sector_num, nb_sectors);
+int ret = blk_check_byte_request(blk, offset, bytes);
 if (ret < 0) {
 return ret;
 }
 
-return bdrv_read(blk_bs(blk), sector_num, buf, nb_sectors);
+return bdrv_co_do_preadv(blk_bs(blk), offset, bytes, qiov, flags);
+}
+
+typedef struct BlkRwCo {
+BlockBackend *blk;
+int64_t offset;
+QEMUIOVector *qiov;
+int ret;
+BdrvRequestFlags flags;
+} BlkRwCo;
+
+static void blk_read_entry(void *opaque)
+{
+BlkRwCo *rwco = opaque;
+
+rwco->ret = blk_co_preadv(rwco->blk, rwco->offset, rwco->qiov->size,
+  rwco->qiov, rwco->flags);
+}
+
+int blk_read(BlockBackend *blk, int64_t sector_num, uint8_t *buf,
+ int nb_sectors)
+{
+AioContext *aio_context;
+QEMUIOVector qiov;
+struct iovec iov;
+Coroutine *co;
+BlkRwCo rwco;
+
+if (nb_sectors < 0 || nb_sectors > BDRV_REQUEST_MAX_SECTORS) {
+return -EINVAL;
+}
+
+iov = (struct iovec) {
+.iov_base = buf,
+.iov_len = nb_sectors * BDRV_SECTOR_SIZE,
+};
+qemu_iovec_init_external(&qiov, &iov, 1);
+
+rwco = (BlkRwCo) {
+.blk= blk,
+.offset = sector_num << BDRV_SECTOR_BITS,
+.qiov   = &qiov,
+.ret= NOT_DONE,
+};
+
+co = qemu_coroutine_create(blk_read_entry);
+qemu_coroutine_enter(co, &rwco);
+
+aio_context = blk_get_aio_context(blk);
+while (rwco.ret == NOT_DONE) {
+aio_poll(aio_context, true);
+}
+
+return rwco.ret;
 }
 
 int blk_read_unthrottled(BlockBackend *blk, int64_t sector_num, uint8_t *buf,
diff --git a/block/io.c b/block/io.c
index 5f9b6d6..c7084e4 100644
--- a/block/io.c
+++ b/block/io.c
@@ -44,9 +44,6 @@ static int coroutine_fn bdrv_co_readv_em(BlockDriverState *bs,
 static int coroutine_fn bdrv_co_writev_em(BlockDriverState *bs,
  int64_t sector_num, int nb_sectors,
  QEMUIOVector *iov);
-static int coroutine_fn bdrv_co_do_preadv(BlockDriverState *bs,
-int64_t offset, unsigned int bytes, QEMUIOVector *qiov,
-BdrvRequestFlags flags);
 static int coroutine_fn bdrv_co_do_pwritev(BlockDriverState *bs,
 int64_t offset, unsigned int bytes, QEMUIOVector *qiov,
 BdrvRequestFlags flags);
@@ -939,7 +936,7 @@ out:
 /*
  * Handle a read request in coroutine context
  */
-static int coroutine_fn bdrv_co_do_preadv(BlockDriverState *bs,
+int coroutine_fn bdrv_co_do_preadv(BlockDriverState *bs,
 int64_t offset, unsigned int bytes, QEMUIOVector *qiov,
 BdrvRequestFlags flags)
 {
diff --git a/include/block/block_int.h b/include/block/block_int.h
index c031db4..b78be8d 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -508,6 +508,10 @@ extern BlockDriver bdrv_qcow2;
  */
 void bdrv_setup_io_funcs(BlockDriver *bdrv);
 
+int coroutine_fn bdrv_co_do_preadv(BlockDriverState *bs,
+int64_t offset, unsigned int bytes, QEMUIOVector *qiov,
+BdrvRequestFlags flags);
+
 int get_tmp_filename(char *filename, int size);
 BlockDriver *bdrv_probe_all(const uint8_t *buf, int buf_size,
 const char *filename);
-- 
1.8.3.1




Re: [Qemu-devel] [PATCH] qdev_try_create(): Assert that devices we put onto the system bus are SysBusDevices

2016-03-18 Thread Peter Maydell
On 16 March 2016 at 14:14, Andreas Färber  wrote:
> Am 16.03.2016 um 15:11 schrieb Peter Maydell:
>> If qdev_try_create() is passed NULL for the bus, it will automatically
>> put the newly created device onto the default system bus. However
>> if the device is not actually a SysBusDevice then this will result
>> in later crashes (for instance when running the monitor "info qtree"
>> command) because code reasonably assumes that all devices on the system
>> bus are system bus devices.
>>
>> Generally the mistake is that the calling code should create the
>> object with object_new(TYPE_FOO) rather than qdev_create(NULL, TYPE_FOO);
>> see commit 6749695eaaf346c1 for an example of fixing this bug.
>>
>> Assert in qdev_try_create() if the device isn't suitable to put on
>> the system bus, so that this mistake results in failure earlier
>> and more reliably.
>>
>> Signed-off-by: Peter Maydell 
>> ---
>> This needs to go in after http://patchwork.ozlabs.org/patch/597716/
>> as otherwise the bug fixed by that patch will become a 'make check'
>> failure.
>
> Looks strange, but okay,

You mean the way we use what looks like a cast macro and ignore
the result? Yeah, I thought that was a little odd-looking. Happy
to do it some other way if you have an alternative suggestion.

> Reviewed-by: Andreas Färber 
>
> Through whose queue?

I'm happy to take it via the target-arm queue, since I was planning
to take the sd.c fix that way and this one needs to go after it,
if that works for you.

thanks
-- PMM



Re: [Qemu-devel] [PATCH v2] vl.c: disallow command line fw cfg without opt/

2016-03-18 Thread Paolo Bonzini
I frankly think it's overengineered, but it's already much better and if
it helps converging to a compromise why not.

Alternatives to your proposals follow:

On 17/03/2016 14:13, Michael S. Tsirkin wrote:
> 
> QEMU command line:
>   A. -fw-cfg RFQDN/PATH prepends usr/. So users will not get conflicts
>  with QEMU hardware

Alternative: no need to prepend usr/, I think.

>   B. -fw-cfg org.qemu/unsupported/XXX as a hack, removes
>   org.qemu/unsupported/ and leaves just XXX,
>   for people who want to break^?^?^?^?^?debug QEMU hardware

Alternative: fail on:

- a blacklist of etc/* files including etc/system-states,
etc/smbios/smbios-tables, etc/smbios/smbios-anchor,
etc/reserved-memory-end, etc/pvpanic-port, etc/e820, and possibly
etc/boot-menu-wait

- on all org.qemu/* files

- iff etc/boot-menu-wait is blacklisted, fail on
org.seabios/boot-menu-wait too.

Everything else is passed through.  No hacks required.

>   C. -fw-cfg opt/FOO accepts any path, for backwards compatibility

Implicit in my proposed alternative to A.

>   D. any other use fails

Replaced by my alternative to B.  RFQDN is just a best practice, and it
is not enforced except as proposed in B.  For the same reason, no
changes are required in the Linux driver.

> OVMF:
>   Can use the compatible opt/ovmf/ for now. [snip]
>   Long term: Gradually transition OVMF to look up paths in usr/org.uefi/:
>   if nothing is found there, look up in opt/ovmf/ for backwards
>   compatibility.

Agreed except it would be org.tianocore.edk2.ovmf/ rather than usr/org.uefi.

Likewise SeaBIOS would switch from etc/ to an org.seabios/ prefix (for
stuff usable from both Coreboot and QEMU, e.g.
org.seabios/bootsplash.bmp) or org.qemu/ (for stuff that is specific to
QEMU).

Files that could be moved from etc/ to org.qemu/ correspond to the ones
that are blacklisted in (B), e.g. etc/system-states ->
org.qemu/system-states.

Paolo



[Qemu-devel] [PATCH 2/2] ARM: Virt: Use gpio_key for power button

2016-03-18 Thread Shannon Zhao
From: Shannon Zhao 

There is a problem for power button that it will not work if an early
system_powerdown request happens before guest gpio driver loads.

Fix this problem by using gpio_key.

Signed-off-by: Shannon Zhao 
---
 hw/arm/virt.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 95331a5..10e385d 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -581,11 +581,11 @@ static void create_rtc(const VirtBoardInfo *vbi, qemu_irq 
*pic)
 g_free(nodename);
 }
 
-static DeviceState *pl061_dev;
+static DeviceState *gpio_key_dev;
 static void virt_powerdown_req(Notifier *n, void *opaque)
 {
 /* use gpio Pin 3 for power button event */
-qemu_set_irq(qdev_get_gpio_in(pl061_dev, 3), 1);
+qemu_set_irq(qdev_get_gpio_in(gpio_key_dev, 0), 1);
 }
 
 static Notifier virt_system_powerdown_notifier = {
@@ -595,6 +595,7 @@ static Notifier virt_system_powerdown_notifier = {
 static void create_gpio(const VirtBoardInfo *vbi, qemu_irq *pic)
 {
 char *nodename;
+DeviceState *pl061_dev;
 hwaddr base = vbi->memmap[VIRT_GPIO].base;
 hwaddr size = vbi->memmap[VIRT_GPIO].size;
 int irq = vbi->irqmap[VIRT_GPIO];
@@ -617,6 +618,8 @@ static void create_gpio(const VirtBoardInfo *vbi, qemu_irq 
*pic)
 qemu_fdt_setprop_string(vbi->fdt, nodename, "clock-names", "apb_pclk");
 qemu_fdt_setprop_cell(vbi->fdt, nodename, "phandle", phandle);
 
+gpio_key_dev = sysbus_create_simple("gpio_key", -1,
+qdev_get_gpio_in(pl061_dev, 3));
 qemu_fdt_add_subnode(vbi->fdt, "/gpio-keys");
 qemu_fdt_setprop_string(vbi->fdt, "/gpio-keys", "compatible", "gpio-keys");
 qemu_fdt_setprop_cell(vbi->fdt, "/gpio-keys", "#size-cells", 0);
-- 
2.0.4





Re: [Qemu-devel] [PATCH][RFC] IOMMU: Add Support to VFIO devices with vIOMMU present

2016-03-18 Thread Aviv B.D.
On Tue, Mar 15, 2016 at 12:53 PM, Michael S. Tsirkin  wrote:

> On Sat, Mar 12, 2016 at 06:13:17PM +0200, Aviv B.D. wrote:
> > From: "Aviv B.D." 
> >
> >  * Fix bug that prevent qemu from starting up when vIOMMU and VFIO
> > device are present.
> >  * Advertise Cache Mode capability in iommu cap register.
> >  * Register every VFIO device with IOMMU state.
> >  * On page cache invalidation in vIOMMU, check if the domain belong to
> >VFIO device and mirror the guest requests to host.
> >
> > Not working (Yet!):
> >  * Tested only with network interface card (ixgbevf) and
> > intel_iommu=strict in guest's kernel command line.
> >  * Lock up under high load.
> >  * Errors on guest poweroff.
> >  * High relative latency compare to VFIO without IOMMU.
> >
> > Signed-off-by: Aviv B.D. 
>
> Thanks, this is very interesting.
> So this needs some cleanup, and some issues that will have to be addressed.
> See below.
> Thanks!
>
> Thanks!

>
> > ---
> >  hw/i386/intel_iommu.c  | 76
> ++
> >  hw/i386/intel_iommu_internal.h |  1 +
> >  hw/vfio/common.c   | 12 +--
> >  include/hw/i386/intel_iommu.h  |  4 +++
> >  include/hw/vfio/vfio-common.h  |  1 +
> >  5 files changed, 85 insertions(+), 9 deletions(-)
> >
> > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> > index 347718f..046688f 100644
> > --- a/hw/i386/intel_iommu.c
> > +++ b/hw/i386/intel_iommu.c
> > @@ -43,6 +44,9 @@ static int vtd_dbgflags = VTD_DBGBIT(GENERAL) |
> VTD_DBGBIT
> > (CSR);
> >  #define VTD_DPRINTF(what, fmt, ...) do {} while (0)
> >  #endif
> >
> > +static int vtd_dev_to_context_entry(IntelIOMMUState *s, uint8_t bus_num,
> > +uint8_t devfn, VTDContextEntry *ce);
> > +
> >  static void vtd_define_quad(IntelIOMMUState *s, hwaddr addr, uint64_t
> val,
> >  uint64_t wmask, uint64_t w1cmask)
> >  {
> > @@ -126,6 +130,19 @@ static uint32_t
> vtd_set_clear_mask_long(IntelIOMMUState
> > *s, hwaddr addr,
> >  return new_val;
> >  }
> >
> > +static uint16_t vtd_get_did_dev(IntelIOMMUState *s, uint8_t bus_num,
> uint8_t
> > devfn)
> > +{
> > +VTDContextEntry ce;
> > +int ret_fr;
> > +
> > +ret_fr = vtd_dev_to_context_entry(s, bus_num, devfn, &ce);
> > +if (ret_fr){
> > +return -1;
> > +}
> > +
> > +return VTD_CONTEXT_ENTRY_DID(ce.hi);
> > +}
> > +
> >  static uint64_t vtd_set_clear_mask_quad(IntelIOMMUState *s, hwaddr addr,
> >  uint64_t clear, uint64_t mask)
> >  {
> > @@ -711,9 +728,9 @@ static int vtd_dev_to_context_entry(IntelIOMMUState
> *s,
> > uint8_t bus_num,
> >  }
> >
> >  if (!vtd_context_entry_present(ce)) {
> > -VTD_DPRINTF(GENERAL,
> > +/*VTD_DPRINTF(GENERAL,
> >  "error: context-entry #%"PRIu8 "(bus #%"PRIu8 ") "
> > -"is not present", devfn, bus_num);
> > +"is not present", devfn, bus_num);*/
> >  return -VTD_FR_CONTEXT_ENTRY_P;
> >  } else if ((ce->hi & VTD_CONTEXT_ENTRY_RSVD_HI) ||
> > (ce->lo & VTD_CONTEXT_ENTRY_RSVD_LO)) {
> > @@ -1020,14 +1037,53 @@ static void
> vtd_iotlb_page_invalidate(IntelIOMMUState
> > *s, uint16_t domain_id,
> >hwaddr addr, uint8_t am)
> >  {
> >  VTDIOTLBPageInvInfo info;
> > +VFIOGuestIOMMU * giommu;
> > +bool flag = false;
> >
> >  assert(am <= VTD_MAMV);
> >  info.domain_id = domain_id;
> >  info.addr = addr;
> >  info.mask = ~((1 << am) - 1);
> > +
> > +QLIST_FOREACH(giommu, &(s->giommu_list), iommu_next){
> > +VTDAddressSpace *vtd_as = container_of(giommu->iommu,
> VTDAddressSpace,
> > iommu);
> > +uint16_t vfio_source_id =
> vtd_make_source_id(pci_bus_num(vtd_as->bus),
> > vtd_as->devfn);
> > +uint16_t vfio_domain_id = vtd_get_did_dev(s,
> pci_bus_num(vtd_as->bus),
> > vtd_as->devfn);
> > +if (vfio_domain_id != (uint16_t)-1 &&
> > +domain_id == vfio_domain_id){
> > +VTDIOTLBEntry *iotlb_entry = vtd_lookup_iotlb(s,
> vfio_source_id,
> > addr);
> > +if (iotlb_entry != NULL){
> > +IOMMUTLBEntry entry;
> > +VTD_DPRINTF(GENERAL, "Remove addr 0x%"PRIx64 " mask
> %d", addr,
> > am);
> > +entry.iova = addr & VTD_PAGE_MASK_4K;
> > +entry.translated_addr =
> vtd_get_slpte_addr(iotlb_entry->slpte)
> > & VTD_PAGE_MASK_4K;
> > +entry.addr_mask = ~VTD_PAGE_MASK_4K;
> > +entry.perm = IOMMU_NONE;
> > +memory_region_notify_iommu(giommu->iommu, entry);
> > +flag = true;
> > +
> > +}
> > +}
> > +
> > +}
> > +
> >  g_hash_table_foreach_remove(s->iotlb, vtd_hash_remove_by_page,
> &info);
> > -}
> >
> > +QLIST_FOREACH(giommu, &(s->giommu_list), iommu_next){
> > +VTDAddressSpace *vtd_as = 

Re: [Qemu-devel] [PATCH 4/4] hw/audio: QOM'ify milkymist-ac97.c

2016-03-18 Thread xiaoqiang zhao



在 2016年03月17日 00:30, Paolo Bonzini 写道:


On 16/03/2016 10:24, xiaoqiang zhao wrote:

  s->voice_out = AUD_open_out(&s->card, s->voice_out,
  "mm_ac97.out", s, ac97_out_cb, &as);
  

AUD_open_out should not be done before realize.

Paolo

I wil move it to DeviceClasss::realize in the  next version.
Thank you Paolo !




Re: [Qemu-devel] [PATCH v6 16/16] qapi: Consolidate object visitors

2016-03-18 Thread Markus Armbruster
Eric Blake  writes:

> Rather than having two separate visitor callbacks with items
> already broken out, pass the actual QAPISchemaObjectType object
> to the visitor.  This lets the visitor access things like
> type.is_implicit() without needing another parameter, resolving
> a TODO from previous patches.
>
> For convenience and consistency, the 'name' and 'info' parameters
> are still provided, even though they are now redundant with
> 'typ.name' and 'typ.info'.
>
> Signed-off-by: Eric Blake 

$ for i in `git-ls-files tests/qapi-schema/\*.out`; do diff -q $i 
bld-x86/${i%.out}.test.out; done
Files tests/qapi-schema/comments.out and 
bld-x86/tests/qapi-schema/comments.test.out differ
Files tests/qapi-schema/empty.out and bld-x86/tests/qapi-schema/empty.test.out 
differ
Files tests/qapi-schema/event-case.out and 
bld-x86/tests/qapi-schema/event-case.test.out differ
Files tests/qapi-schema/ident-with-escape.out and 
bld-x86/tests/qapi-schema/ident-with-escape.test.out differ
Files tests/qapi-schema/include-relpath.out and 
bld-x86/tests/qapi-schema/include-relpath.test.out differ
Files tests/qapi-schema/include-repetition.out and 
bld-x86/tests/qapi-schema/include-repetition.test.out differ
Files tests/qapi-schema/include-simple.out and 
bld-x86/tests/qapi-schema/include-simple.test.out differ
Files tests/qapi-schema/indented-expr.out and 
bld-x86/tests/qapi-schema/indented-expr.test.out differ
Files tests/qapi-schema/qapi-schema-test.out and 
bld-x86/tests/qapi-schema/qapi-schema-test.test.out differ

> ---
> v6: new patch

Let's punt this one to a later iteration.



[Qemu-devel] [PULL 13/15] qapi: Make BlockdevOptions doc example closer to reality

2016-03-18 Thread Markus Armbruster
From: Eric Blake 

Although we don't want to repeat the entire BlockdevOptions
QMP command in the example, it helps if we aren't needlessly
diverging (the initial example was written before we had
committed the actual QMP interface).  Use names that match what
is found in qapi/block-core.json, such as '*read-only' rather
than 'readonly', or 'BlockdevRef' rather than 'BlockRef'.

For the simple union example, invent BlockdevOptionsSimple so
that later text is unambiguous which of the two union forms is
meant (telling the user to refer back to two 'BlockdevOptions'
wasn't nice, and QMP has only the flat union form).

Also, mention that the discriminator of a flat union is
non-optional.

Signed-off-by: Eric Blake 
Message-Id: <1458254921-17042-14-git-send-email-ebl...@redhat.com>
Signed-off-by: Markus Armbruster 
---
 docs/qapi-code-gen.txt | 74 +-
 1 file changed, 37 insertions(+), 37 deletions(-)

diff --git a/docs/qapi-code-gen.txt b/docs/qapi-code-gen.txt
index c648f76..12af1b8 100644
--- a/docs/qapi-code-gen.txt
+++ b/docs/qapi-code-gen.txt
@@ -297,22 +297,22 @@ be empty.
 A simple union type defines a mapping from automatic discriminator
 values to data types like in this example:
 
- { 'struct': 'FileOptions', 'data': { 'filename': 'str' } }
- { 'struct': 'Qcow2Options',
-   'data': { 'backing-file': 'str', 'lazy-refcounts': 'bool' } }
+ { 'struct': 'BlockdevOptionsFile', 'data': { 'filename': 'str' } }
+ { 'struct': 'BlockdevOptionsQcow2',
+   'data': { 'backing': 'str', '*lazy-refcounts': 'bool' } }
 
- { 'union': 'BlockdevOptions',
-   'data': { 'file': 'FileOptions',
- 'qcow2': 'Qcow2Options' } }
+ { 'union': 'BlockdevOptionsSimple',
+   'data': { 'file': 'BlockdevOptionsFile',
+ 'qcow2': 'BlockdevOptionsQcow2' } }
 
 In the Client JSON Protocol, a simple union is represented by a
 dictionary that contains the 'type' member as a discriminator, and a
 'data' member that is of the specified data type corresponding to the
 discriminator value, as in these examples:
 
- { "type": "file", "data" : { "filename": "/some/place/my-image" } }
- { "type": "qcow2", "data" : { "backing-file": "/some/place/my-image",
-   "lazy-refcounts": true } }
+ { "type": "file", "data": { "filename": "/some/place/my-image" } }
+ { "type": "qcow2", "data": { "backing": "/some/place/my-image",
+  "lazy-refcounts": true } }
 
 The generated C code uses a struct containing a union. Additionally,
 an implicit C enum 'NameKind' is created, corresponding to the union
@@ -325,29 +325,29 @@ avoids nesting on the wire.  All branches of the union 
must be
 complex types, and the top-level members of the union dictionary on
 the wire will be combination of members from both the base type and the
 appropriate branch type (when merging two dictionaries, there must be
-no keys in common).  The 'discriminator' member must be the name of an
-enum-typed member of the base struct.
+no keys in common).  The 'discriminator' member must be the name of a
+non-optional enum-typed member of the base struct.
 
 The following example enhances the above simple union example by
-adding a common member 'readonly', renaming the discriminator to
-something more applicable, and reducing the number of {} required on
-the wire:
+adding an optional common member 'read-only', renaming the
+discriminator to something more applicable than the simple union's
+default of 'type', and reducing the number of {} required on the wire:
 
  { 'enum': 'BlockdevDriver', 'data': [ 'file', 'qcow2' ] }
- { 'struct': 'BlockdevCommonOptions',
-   'data': { 'driver': 'BlockdevDriver', 'readonly': 'bool' } }
+ { 'struct': 'BlockdevOptionsBase',
+   'data': { 'driver': 'BlockdevDriver', '*read-only': 'bool' } }
  { 'union': 'BlockdevOptions',
-   'base': 'BlockdevCommonOptions',
+   'base': 'BlockdevOptionsBase',
'discriminator': 'driver',
-   'data': { 'file': 'FileOptions',
- 'qcow2': 'Qcow2Options' } }
+   'data': { 'file': 'BlockdevOptionsFile',
+ 'qcow2': 'BlockdevOptionsQcow2' } }
 
 Resulting in these JSON objects:
 
- { "driver": "file", "readonly": true,
+ { "driver": "file", "read-only": true,
"filename": "/some/place/my-image" }
- { "driver": "qcow2", "readonly": false,
-   "backing-file": "/some/place/my-image", "lazy-refcounts": true }
+ { "driver": "qcow2", "read-only": false,
+   "backing": "/some/place/my-image", "lazy-refcounts": true }
 
 Notice that in a flat union, the discriminator name is controlled by
 the user, but because it must map to a base member with enum type, the
@@ -382,7 +382,7 @@ data types (string, integer, number, or object, but 
currently not
 array) on the wire.  The definition is similar to a simple union type,
 where each branch of the union names a QAPI type.  For example:
 
- { 'alternate': 'BlockRef',
+ { 'alternate': 'BlockdevRef',
'data': { 'definition': 'BlockdevOptions',
 

Re: [Qemu-devel] [PATCH v3 0/2] spapr: QMP: add query-hotpluggable-cpus

2016-03-18 Thread Igor Mammedov
On Wed, 16 Mar 2016 20:29:59 +0100
Christian Borntraeger  wrote:

> On 03/15/2016 02:24 PM, Igor Mammedov wrote:
> > Changes since v2:
> >  - rebase on top of hte lates spapr cpu hotpug series
> >  - add 'vcpus-count' field, pkre...@redhat.com
> >  - s/CpuInstanceProps/CpuInstanceProperties/
> >  - use '#optional' marker
> >  - make "props" as always present even if it's empty
> >  - fix JSON examples
> >  - fix minor typos
> >  - drop pre_plug spapr impl out of series as not related to QMP command
> >  - drop generic pre hotplug callback as not related to QMP command
> > 
> > Changes since RFC:
> >  - drop arch_id
> >  - move CPU properties into separate structure
> >  - target implements its own qmp callback version
> >  - rebased on top of [RFC PATCH v1 00/10] Core based CPU hotplug for 
> > PowerPC sPAPR
> >   
> > https://www.mail-archive.com/qemu-devel@nongnu.org/msg357567.html
> > - convert slot name to core id hack
> > - drop links
> > - add generic pre hotplug callback
> > - implement query-hotpluggable-cpus
> > 
> > The first patch (QMP API) in this series could go in first
> > allowing individual targets to post their hotplug
> > implementation independently on top of it.
> > 
> > Igor Mammedov (2):
> >   QMP: add query-hotpluggable-cpus
> >   spapr: implement query-hotpluggable-cpus QMP command
> > 
> >  hw/ppc/spapr.c  | 32 +++  
> 
> i might have just missed that, do we also have the x86 implementation already 
> available as
> RFC somewhere?
device_add x86-cpu, hasn't been posted yet, but I'm working on it.
If you are asking about query-hotpluggable-cpus command with
x86 backend then it's been posted as v1 of this RFC
https://patchwork.ozlabs.org/patch/583036/

and current v3 is what QMP interface evolved to based on feedback
for QEMU and libvirt developers.

x86 backend shouldn't be hard to respin as prerequisite patches
for it were just merged, I plan to stick that patch in
device_add enablement series.



[Qemu-devel] [PATCH 1/2] e1000: Fixing interrupts pace.

2016-03-18 Thread Sameeh Jubran
This patch introduces an upper bound for number of interrupts
per second. Without this bound an interrupt storm can occur as
it has been observed on Windows 10 when disabling the device.

According to the SPEC - Intel PCI/PCI-X Family of Gigabit
Ethernet Controllers Software Developer's Manual, section
13.4.18 - the Ethernet controller guarantees a maximum
observable interrupt rate of 7813 interrupts/sec. If there is
no upper bound this could lead to an interrupt storm by e1000
(when mit_delay < 500) causing interrupts to fire at a very high
pace.
Thus if mit_delay < 500 then the delay should be set to the
minimum delay possible which is 500. This can be calculated
easily as follows:

Interval = 10^9 / (7813 * 256) = 500.

Signed-off-by: Sameeh Jubran 
---
 hw/net/e1000.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/hw/net/e1000.c b/hw/net/e1000.c
index 0387fa0..09b9ab5 100644
--- a/hw/net/e1000.c
+++ b/hw/net/e1000.c
@@ -357,6 +357,14 @@ set_interrupt_cause(E1000State *s, int index, uint32_t val)
 }
 mit_update_delay(&mit_delay, s->mac_reg[ITR]);
 
+/*
+ * According to e1000 SPEC, the Ethernet controller guarantees
+ * a maximum observable interrupt rate of 7813 interrupts/sec.
+ * Thus if mit_delay < 500 then the delay should be set to the
+ * minimum delay possible which is 500.
+ */
+mit_delay = (mit_delay < 500) ? 500 : mit_delay;
+
 if (mit_delay) {
 s->mit_timer_on = 1;
 timer_mod(s->mit_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
-- 
2.5.0




Re: [Qemu-devel] [PATCH V4] hw/pxb: add chassis_nr property

2016-03-18 Thread Cao jin

hi

On 03/15/2016 07:44 PM, Marcel Apfelbaum wrote:

On 03/15/2016 10:00 AM, Cao jin wrote:




And I have another personal question: In qemu design, it seems every
pci bridge reside in a separate chassis, what`s benefit?  why don`t
put them all in the main chassis?


Please have a look on pci-to-pci bridge specification, chapter 13, slot
numbering.



thanks for the hint.
I still have a question: in docs/pci_expander_bridge.txt, it says: 
create a TYPE_PCI_BRIDGE_DEV to enable hotplug support.

But I didn`t see it can hotplug as following step:

1: ./qemu-system-x86_64 -device pxb,id=br,bus=pci.0,bus_nr=2 -hda 
linux.img -smp 2 --enable-kvm -m 1024 -monitor stdio


2: in monitor, type: device_add e1000,bus=br
result: no message output to monitor, and don`t see e1000 nic in guest

Is is a bug or I test it in a wrong way?

--
Yours Sincerely,

Cao jin





Re: [Qemu-devel] [PATCH 1/3] hw/net/spapr_llan: Extract rx buffer code into separate functions

2016-03-18 Thread Laurent Vivier


On 16/03/2016 13:16, Thomas Huth wrote:
> Refactor the code a little bit by extracting the code that reads
> and writes the receive buffer list page into separate functions.
> There should be no functional change in this patch, this is just
> a preparation for the upcoming extensions that introduce receive
> buffer pools.
> 
> Signed-off-by: Thomas Huth 

Reviewed-by: Laurent Vivier 

> ---
>  hw/net/spapr_llan.c | 106 
> ++--
>  1 file changed, 70 insertions(+), 36 deletions(-)
> 
> diff --git a/hw/net/spapr_llan.c b/hw/net/spapr_llan.c
> index 5237b4d..39a1dd1 100644
> --- a/hw/net/spapr_llan.c
> +++ b/hw/net/spapr_llan.c
> @@ -103,6 +103,42 @@ static int spapr_vlan_can_receive(NetClientState *nc)
>  return (dev->isopen && dev->rx_bufs > 0);
>  }
>  
> +/**
> + * Get buffer descriptor from the receive buffer list page that has been
> + * supplied by the guest with the H_REGISTER_LOGICAL_LAN call
> + */
> +static vlan_bd_t spapr_vlan_get_rx_bd_from_page(VIOsPAPRVLANDevice *dev,
> +size_t size)
> +{
> +int buf_ptr = dev->use_buf_ptr;
> +vlan_bd_t bd;
> +
> +do {
> +buf_ptr += 8;
> +if (buf_ptr >= VLAN_RX_BDS_LEN + VLAN_RX_BDS_OFF) {
> +buf_ptr = VLAN_RX_BDS_OFF;
> +}
> +
> +bd = vio_ldq(&dev->sdev, dev->buf_list + buf_ptr);
> +DPRINTF("use_buf_ptr=%d bd=0x%016llx\n",
> +buf_ptr, (unsigned long long)bd);
> +} while ((!(bd & VLAN_BD_VALID) || VLAN_BD_LEN(bd) < size + 8)
> + && buf_ptr != dev->use_buf_ptr);
> +
> +if (!(bd & VLAN_BD_VALID) || VLAN_BD_LEN(bd) < size + 8) {
> +/* Failed to find a suitable buffer */
> +return 0;
> +}
> +
> +/* Remove the buffer from the pool */
> +dev->use_buf_ptr = buf_ptr;
> +vio_stq(&dev->sdev, dev->buf_list + dev->use_buf_ptr, 0);
> +
> +DPRINTF("Found buffer: ptr=%d rxbufs=%d\n", dev->use_buf_ptr, 
> dev->rx_bufs);
> +
> +return bd;
> +}
> +
>  static ssize_t spapr_vlan_receive(NetClientState *nc, const uint8_t *buf,
>size_t size)
>  {
> @@ -110,7 +146,6 @@ static ssize_t spapr_vlan_receive(NetClientState *nc, 
> const uint8_t *buf,
>  VIOsPAPRDevice *sdev = VIO_SPAPR_DEVICE(dev);
>  vlan_bd_t rxq_bd = vio_ldq(sdev, dev->buf_list + VLAN_RXQ_BD_OFF);
>  vlan_bd_t bd;
> -int buf_ptr = dev->use_buf_ptr;
>  uint64_t handle;
>  uint8_t control;
>  
> @@ -125,29 +160,12 @@ static ssize_t spapr_vlan_receive(NetClientState *nc, 
> const uint8_t *buf,
>  return -1;
>  }
>  
> -do {
> -buf_ptr += 8;
> -if (buf_ptr >= (VLAN_RX_BDS_LEN + VLAN_RX_BDS_OFF)) {
> -buf_ptr = VLAN_RX_BDS_OFF;
> -}
> -
> -bd = vio_ldq(sdev, dev->buf_list + buf_ptr);
> -DPRINTF("use_buf_ptr=%d bd=0x%016llx\n",
> -buf_ptr, (unsigned long long)bd);
> -} while ((!(bd & VLAN_BD_VALID) || (VLAN_BD_LEN(bd) < (size + 8)))
> - && (buf_ptr != dev->use_buf_ptr));
> -
> -if (!(bd & VLAN_BD_VALID) || (VLAN_BD_LEN(bd) < (size + 8))) {
> -/* Failed to find a suitable buffer */
> +bd = spapr_vlan_get_rx_bd_from_page(dev, size);
> +if (!bd) {
>  return -1;
>  }
>  
> -/* Remove the buffer from the pool */
>  dev->rx_bufs--;
> -dev->use_buf_ptr = buf_ptr;
> -vio_stq(sdev, dev->buf_list + dev->use_buf_ptr, 0);
> -
> -DPRINTF("Found buffer: ptr=%d num=%d\n", dev->use_buf_ptr, dev->rx_bufs);
>  
>  /* Transfer the packet data */
>  if (spapr_vio_dma_write(sdev, VLAN_BD_ADDR(bd) + 8, buf, size) < 0) {
> @@ -372,6 +390,32 @@ static target_ulong h_free_logical_lan(PowerPCCPU *cpu,
>  return H_SUCCESS;
>  }
>  
> +static target_long spapr_vlan_add_rxbuf_to_page(VIOsPAPRVLANDevice *dev,
> +target_ulong buf)
> +{
> +vlan_bd_t bd;
> +
> +if (dev->rx_bufs >= VLAN_MAX_BUFS) {
> +return H_RESOURCE;
> +}
> +
> +do {
> +dev->add_buf_ptr += 8;
> +if (dev->add_buf_ptr >= VLAN_RX_BDS_LEN + VLAN_RX_BDS_OFF) {
> +dev->add_buf_ptr = VLAN_RX_BDS_OFF;
> +}
> +
> +bd = vio_ldq(&dev->sdev, dev->buf_list + dev->add_buf_ptr);
> +} while (bd & VLAN_BD_VALID);
> +
> +vio_stq(&dev->sdev, dev->buf_list + dev->add_buf_ptr, buf);
> +
> +DPRINTF("h_add_llan_buf():  Added buf  ptr=%d  rx_bufs=%d 
> bd=0x%016llx\n",
> +dev->add_buf_ptr, dev->rx_bufs, (unsigned long long)buf);
> +
> +return 0;
> +}
> +
>  static target_ulong h_add_logical_lan_buffer(PowerPCCPU *cpu,
>   sPAPRMachineState *spapr,
>   target_ulong opcode,
> @@ -381,7 +425,7 @@ static target_ulong h_add_logical_lan_buffer(PowerPCCPU 
> *cpu,
>  target_ulong buf = args[1];
>  VIOsPAPRDevice *sdev = spapr_vio

[Qemu-devel] [PULL 14/21] hw/arm: Add ASPEED AST2400 SoC model

2016-03-18 Thread Peter Maydell
From: Andrew Jeffery 

While the ASPEED AST2400 SoC[1] has a broad range of capabilities this
implementation is minimal, comprising an ARM926 processor, ASPEED VIC
and timer devices, and a 8250 UART.

[1] http://www.aspeedtech.com/products.php?fPath=20&rId=376

Signed-off-by: Andrew Jeffery 
Message-id: 1458096317-25223-4-git-send-email-and...@aj.id.au
Reviewed-by: Peter Maydell 
Signed-off-by: Peter Maydell 
---
 hw/arm/Makefile.objs |   1 +
 hw/arm/ast2400.c | 137 +++
 include/hw/arm/ast2400.h |  35 
 3 files changed, 173 insertions(+)
 create mode 100644 hw/arm/ast2400.c
 create mode 100644 include/hw/arm/ast2400.h

diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index a711e4d..f333b7f 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -16,3 +16,4 @@ obj-$(CONFIG_STM32F205_SOC) += stm32f205_soc.o
 obj-$(CONFIG_XLNX_ZYNQMP) += xlnx-zynqmp.o xlnx-ep108.o
 obj-$(CONFIG_FSL_IMX25) += fsl-imx25.o imx25_pdk.o
 obj-$(CONFIG_FSL_IMX31) += fsl-imx31.o kzm.o
+obj-$(CONFIG_ASPEED_SOC) += ast2400.o
diff --git a/hw/arm/ast2400.c b/hw/arm/ast2400.c
new file mode 100644
index 000..daa5518
--- /dev/null
+++ b/hw/arm/ast2400.c
@@ -0,0 +1,137 @@
+/*
+ * AST2400 SoC
+ *
+ * Andrew Jeffery 
+ * Jeremy Kerr 
+ *
+ * Copyright 2016 IBM Corp.
+ *
+ * This code is licensed under the GPL version 2 or later.  See
+ * the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "exec/address-spaces.h"
+#include "hw/arm/ast2400.h"
+#include "hw/char/serial.h"
+
+#define AST2400_UART_5_BASE  0x00184000
+#define AST2400_IOMEM_SIZE   0x0020
+#define AST2400_IOMEM_BASE   0x1E60
+#define AST2400_VIC_BASE 0x1E6C
+#define AST2400_TIMER_BASE   0x1E782000
+
+static const int uart_irqs[] = { 9, 32, 33, 34, 10 };
+static const int timer_irqs[] = { 16, 17, 18, 35, 36, 37, 38, 39, };
+
+/*
+ * IO handlers: simply catch any reads/writes to IO addresses that aren't
+ * handled by a device mapping.
+ */
+
+static uint64_t ast2400_io_read(void *p, hwaddr offset, unsigned size)
+{
+qemu_log_mask(LOG_UNIMP, "%s: 0x%" HWADDR_PRIx " [%u]\n",
+  __func__, offset, size);
+return 0;
+}
+
+static void ast2400_io_write(void *opaque, hwaddr offset, uint64_t value,
+unsigned size)
+{
+qemu_log_mask(LOG_UNIMP, "%s: 0x%" HWADDR_PRIx " <- 0x%" PRIx64 " [%u]\n",
+  __func__, offset, value, size);
+}
+
+static const MemoryRegionOps ast2400_io_ops = {
+.read = ast2400_io_read,
+.write = ast2400_io_write,
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static void ast2400_init(Object *obj)
+{
+AST2400State *s = AST2400(obj);
+
+s->cpu = cpu_arm_init("arm926");
+
+object_initialize(&s->vic, sizeof(s->vic), TYPE_ASPEED_VIC);
+object_property_add_child(obj, "vic", OBJECT(&s->vic), NULL);
+qdev_set_parent_bus(DEVICE(&s->vic), sysbus_get_default());
+
+object_initialize(&s->timerctrl, sizeof(s->timerctrl), TYPE_ASPEED_TIMER);
+object_property_add_child(obj, "timerctrl", OBJECT(&s->timerctrl), NULL);
+qdev_set_parent_bus(DEVICE(&s->timerctrl), sysbus_get_default());
+}
+
+static void ast2400_realize(DeviceState *dev, Error **errp)
+{
+int i;
+AST2400State *s = AST2400(dev);
+Error *err = NULL;
+
+/* IO space */
+memory_region_init_io(&s->iomem, NULL, &ast2400_io_ops, NULL,
+"ast2400.io", AST2400_IOMEM_SIZE);
+memory_region_add_subregion_overlap(get_system_memory(), 
AST2400_IOMEM_BASE,
+&s->iomem, -1);
+
+/* VIC */
+object_property_set_bool(OBJECT(&s->vic), true, "realized", &err);
+if (err) {
+error_propagate(errp, err);
+return;
+}
+sysbus_mmio_map(SYS_BUS_DEVICE(&s->vic), 0, AST2400_VIC_BASE);
+sysbus_connect_irq(SYS_BUS_DEVICE(&s->vic), 0,
+   qdev_get_gpio_in(DEVICE(s->cpu), ARM_CPU_IRQ));
+sysbus_connect_irq(SYS_BUS_DEVICE(&s->vic), 1,
+   qdev_get_gpio_in(DEVICE(s->cpu), ARM_CPU_FIQ));
+
+/* Timer */
+object_property_set_bool(OBJECT(&s->timerctrl), true, "realized", &err);
+if (err) {
+error_propagate(errp, err);
+return;
+}
+sysbus_mmio_map(SYS_BUS_DEVICE(&s->timerctrl), 0, AST2400_TIMER_BASE);
+for (i = 0; i < ARRAY_SIZE(timer_irqs); i++) {
+qemu_irq irq = qdev_get_gpio_in(DEVICE(&s->vic), timer_irqs[i]);
+sysbus_connect_irq(SYS_BUS_DEVICE(&s->timerctrl), i, irq);
+}
+
+/* UART - attach an 8250 to the IO space as our UART5 */
+if (serial_hds[0]) {
+qemu_irq uart5 = qdev_get_gpio_in(DEVICE(&s->vic), uart_irqs[4]);
+serial_mm_init(&s->iomem, AST2400_UART_5_BASE, 2,
+   uart5, 38400, serial_hds[0], DEVICE_LITTLE_ENDIAN);
+}
+}
+
+static void ast2400_class_init(ObjectClass *oc, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(oc);
+
+dc->realize = ast2400_realize;
+
+/*

[Qemu-devel] [PATCH v2 1/4] hw/audio: QOM'ify cs4231.c

2016-03-18 Thread xiaoqiang zhao
Drop the old SysBus init function and use instance_init

Signed-off-by: xiaoqiang zhao 
---
 hw/audio/cs4231.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/hw/audio/cs4231.c b/hw/audio/cs4231.c
index caf97c1..30690f9 100644
--- a/hw/audio/cs4231.c
+++ b/hw/audio/cs4231.c
@@ -145,16 +145,15 @@ static const VMStateDescription vmstate_cs4231 = {
 }
 };
 
-static int cs4231_init1(SysBusDevice *dev)
+static void cs4231_init(Object *obj)
 {
-CSState *s = CS4231(dev);
+CSState *s = CS4231(obj);
+SysBusDevice *dev = SYS_BUS_DEVICE(obj);
 
-memory_region_init_io(&s->iomem, OBJECT(s), &cs_mem_ops, s, "cs4321",
+memory_region_init_io(&s->iomem, obj, &cs_mem_ops, s, "cs4321",
   CS_SIZE);
 sysbus_init_mmio(dev, &s->iomem);
 sysbus_init_irq(dev, &s->irq);
-
-return 0;
 }
 
 static Property cs4231_properties[] = {
@@ -164,9 +163,7 @@ static Property cs4231_properties[] = {
 static void cs4231_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
-SysBusDeviceClass *k = SYS_BUS_DEVICE_CLASS(klass);
 
-k->init = cs4231_init1;
 dc->reset = cs_reset;
 dc->vmsd = &vmstate_cs4231;
 dc->props = cs4231_properties;
@@ -176,6 +173,7 @@ static const TypeInfo cs4231_info = {
 .name  = TYPE_CS4231,
 .parent= TYPE_SYS_BUS_DEVICE,
 .instance_size = sizeof(CSState),
+.instance_init = cs4231_init,
 .class_init= cs4231_class_init,
 };
 
-- 
2.1.4





Re: [Qemu-devel] [RFC PATCH v2 0/9] Core based CPU hotplug for PowerPC sPAPR

2016-03-18 Thread Igor Mammedov
On Wed, 16 Mar 2016 09:18:03 +0530
Bharata B Rao  wrote:

> On Mon, Mar 14, 2016 at 10:47:28AM +0100, Igor Mammedov wrote:
> > On Fri, 11 Mar 2016 10:24:29 +0530
> > Bharata B Rao  wrote:
> >   
> > > Hi,
> > > 
> > > This is the next version of "Core based CPU hotplug for PowerPC sPAPR" 
> > > that
> > > was posted at
> > > https://lists.gnu.org/archive/html/qemu-ppc/2016-03/msg00081.html
> > > 
> > > device_add semantics
> > > 
> > > For -smp 16,sockets=1,cores=2,threads=8,maxcpus=32
> > > (qemu) device_add 
> > > spapr-cpu-core,id=core2,core=16,cpu_model=host[,threads=8]  
> > do you plan to allow user to hotplug different cpu_models?
> > If not it would be better to hide cpu_model from user
> > and set it from machine pre_plug handler.  
> 
> In my earlier implementations I derived cpu model from -cpu and threads from
> -smp,threads= commandline options and never exposed them to device_add
> command.
> 
> Though we don't support heterogenous systems (different cpu models and/or
> threads) now, it was felt that it should be easy enough to support such
> systems if required in future, that's how cpu_model and threads became
> options for device_add.
> 
> One of the things that David felt was missing from my earlier QMP query
> command (and which is true in your QMP query implementation also) is that
> we aren't exporting cpu_model at all, at least for not-yet-plugged cores.
> So should we include that or let management figure that out since it
> would already know about the CPU model.
1.
so since you are not planning supporting heterogeneous setup yet,
I'd suggest to refrain from making user to provide cpu_model at
device_add time. Instead make machine code to set it for cores it
creates before core.realize() (yet another use for pre_plug()).

That way mgmt doesn't have to figure out what cpu_model to set at
device_add time and doesn't have find out what property to use for it.

2.
If you still insist on providing cpu_model property at
device_add time, you'd better extend QMP command query-hotpluggable-cpus
to provide it in 'props' list along with valid value.

But I'd go with #1 as questions of using cpu_model-s vs QOM types and
discovery of mapping of cpu-model to QOM types is not clear yet
and need to be discussed further.


> 
> Regards,
> Bharata.
> 
> 




Re: [Qemu-devel] [PATCH v2] vl.c: disallow command line fw cfg without opt/

2016-03-18 Thread Michael S. Tsirkin
On Wed, Mar 16, 2016 at 07:35:09PM +0100, Laszlo Ersek wrote:
> OVMF uses this feature for a few flags. They are all called
> "opt/ovmf/...". I followed the advice in "docs/specs/fw_cfg.txt" (which
> shouldn't be surprising since I seem to have reviewed every patch for
> that file):

Wait a second.  You are saying upsteam OVMF puts files there.
If users add their own flags that happen to be in opt/ovmf/ then
what happens? And how do they *know* they should avoid that?
There's no warning, guest just breaks in various ways.

This is exactly the kind of mess I was worried about. We have a global
namespace with no way to control what goes where.

opt/ was for end users not firmware.

The right thing to do would be for ovmf to reserve itself
a directory under root.

This really needs more thought.  For now I'd suggest we drop the whole
interface from 2.6 and come back to it after 2.6.

-- 
MST



Re: [Qemu-devel] [PATCH 0/4] Tweaks around virtio-blk start/stop

2016-03-18 Thread Paolo Bonzini


On 16/03/2016 13:42, Cornelia Huck wrote:
> On Wed, 16 Mar 2016 13:32:59 +0100
> Paolo Bonzini  wrote:
> 
>> On 16/03/2016 13:22, Cornelia Huck wrote:
> Yeah, it doesn't help that the functions are underdocumented (as in the
> "assign" parameter above).
>>> My understanding is:
>>>
>>> - 'assign': set up a new notifier (true) or disable it (false)
>>> - 'set_handler': use our handler (true) or have it handled elsewhere
>>>   (false)
>>
>> Right.  So if we're setting up a new notifier in
>> virtio_queue_aio_set_host_notifier_handler, virtio_pci_stop_ioeventfd should

... not call virtio_queue_host_notifier_read.

> I don't think the ->set_host_notifiers() api really allows for this.

 I think it does, assign is the last argument to k->set_host_notifier().
>>>
>>> This depends on whether we want 'assign' to clean up any old notifiers
>>> before setting up new ones. I think we want different behaviour for
>>> dataplane and vhost.
>>
>> I think dataplane and vhost are the same.
>>
>> The question is whether ioeventfd=off,vhost=on or
>> ioeventfd=off,dataplane=on are valid combinations; I think they aren't.
> 
> We should disallow that even temporary, then.
> 
> (This would imply that we need to drop the _stop_ioeventfd() call in
> ->set_host_notifier(), correct?)

No, it would not.  ioeventfd=off,vhost=on would mean: "when vhost is
off, use vCPU thread notification".

When turning on vhost you'd still stop ioeventfd (i.e. stop processing
the virtqueue in QEMU's main iothread), but you don't need to do
anything to the event notifier.  vhost will pick it up and work on the
virtqueue if necessary.  Likewise for dataplane.

>> If they aren't, it should be okay to remove the
>> virtio_queue_host_notifier_read call in
>> virtio_queue_set_host_notifier_fd_handler and
>> virtio_queue_aio_set_host_notifier_handler.  That's because a handler
>> for the notifier will always be set _somewhere_.  It could be the usual
>> ioeventfd handler, the vhost handler or the dataplane handler, but one
>> will be there.
> 
> It should; but we probably need to do a final read when we stop the
> ioeventfd.

I was thinking of handing the final read directly to the next guy who
polls the event notifier instead.  So, when called from vhost or
dataplane, virtio_pci_stop_ioeventfd would use
assign=true/set_handler=false ("a new notifier is going to be set up by
the caller").

The host notifier API unfortunately is full of indirections.  I'm not
sure how many of them are actually necessary.

Paolo

Paolo



Re: [Qemu-devel] basic block tracing question

2016-03-18 Thread Tim Newsham
On Wed, Mar 16, 2016 at 10:52 AM, Peter Maydell 
wrote:

>
> If you only emit tracing information after the TB has executed and
> returned then you will miss the case where we execute half a TB
> and take an exception (eg load/store that page faulted, or system call),
> because in that case we'll longjmp() out of the generated code. That's
> one of the reasons why the tracing we have in upstream traces before
> TB execution.
>

What happens when the basic block gets interrupted mid execution
and restarted?  Will execution jump to the middle of the translated
basic block, or will a new translation be performed starting at the
midpoint?

Firstly, are you running with -d nochain to disable QEMU's chaining
> of TBs? (If not, then when we chain TBs together you'll only get
> exec tracing for the first one, which is a good way to get confused.
> The default tracing will tell you when we chain TBs together so you
> can sort of unconfuse yourself, but it's easier to just turn it off
> if you care about the TB logging.)
>

I was not using "-d nochain".  Thank you!


> thanks
> -- PMM
>


-- 
Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com


[Qemu-devel] [PATCH v6 07/16] qapi-event: Utilize implicit struct visits

2016-03-18 Thread Eric Blake
Rather than generate inline per-member visits, take advantage
of the 'visit_type_FOO_members()' function for emitting events.
This is possible now that implicit structs can be visited like
any other.  Generated code shrinks accordingly; by initializing
a struct based on parameters, through a new gen_param_var()
helper, like:

|@@ -338,6 +250,9 @@ void qapi_event_send_block_job_error(con
| QMPEventFuncEmit emit = qmp_event_get_func_emit();
| QmpOutputVisitor *qov;
| Visitor *v;
|+q_obj_BLOCK_JOB_ERROR_arg param = {
|+(char *)device, operation, action
|+};
|
| if (!emit) {
| return;
@@ -351,19 +266,7 @@ void qapi_event_send_block_job_error(con
| if (err) {
| goto out;
| }
|-visit_type_str(v, "device", (char **)&device, &err);
|-if (err) {
|-goto out_obj;
|-}
|-visit_type_IoOperationType(v, "operation", &operation, &err);
|-if (err) {
|-goto out_obj;
|-}
|-visit_type_BlockErrorAction(v, "action", &action, &err);
|-if (err) {
|-goto out_obj;
|-}
|-out_obj:
|+visit_type_q_obj_BLOCK_JOB_ERROR_arg_members(v, ¶m, &err);
| visit_end_struct(v, err ? NULL : &err);

Notice that the initialization of 'param' has to cast away const
(just as the old gen_visit_members() had to do): we can't change
the signature of the user function (which uses 'const char *'), but
have to assign it to a non-const QAPI object (which requires
'char *').

While touching this, document with a FIXME comment that there is
still a potential collision between QMP members and our choice of
local variable names within qapi_event_send_FOO().

This patch also paves the way for some followup simplifications
in the generator, in subsequent patches.

Signed-off-by: Eric Blake 

---
v6: split into two patches, move FIXME here from patch 6
v5: move qapi.py:gen_struct_init() to qapi-event.py:gen_param_var(),
improve commit message
v4: new patch
---
 scripts/qapi-event.py | 48 ++--
 1 file changed, 38 insertions(+), 10 deletions(-)

diff --git a/scripts/qapi-event.py b/scripts/qapi-event.py
index 27af206..9b5c5b5 100644
--- a/scripts/qapi-event.py
+++ b/scripts/qapi-event.py
@@ -28,7 +28,37 @@ def gen_event_send_decl(name, arg_type):
  proto=gen_event_send_proto(name, arg_type))


+# Declare and initialize an object 'qapi' using parameters from gen_params()
+def gen_param_var(typ):
+assert not typ.variants
+ret = mcgen('''
+%(c_name)s param = {
+''',
+c_name=typ.c_name())
+sep = ''
+for memb in typ.members:
+ret += sep
+sep = ', '
+if memb.optional:
+ret += 'has_' + c_name(memb.name) + sep
+if memb.type.name == 'str':
+# Cast away const added in gen_params()
+ret += '(char *)'
+ret += c_name(memb.name)
+ret += mcgen('''
+
+};
+''')
+return ret
+
+
 def gen_event_send(name, arg_type):
+# FIXME: Our declaration of local variables (and of 'errp' in the
+# parameter list) can collide with exploded members of the event's
+# data type passed in as parameters.  If this collision ever hits in
+# practice, we can rename our local variables with a leading _ prefix,
+# or split the code into a wrapper function that creates a boxed
+# 'param' object then calls another to do the real work.
 ret = mcgen('''

 %(proto)s
@@ -43,10 +73,11 @@ def gen_event_send(name, arg_type):
 ret += mcgen('''
 QmpOutputVisitor *qov;
 Visitor *v;
-
 ''')
+ret += gen_param_var(arg_type)

 ret += mcgen('''
+
 emit = qmp_event_get_func_emit();
 if (!emit) {
 return;
@@ -58,26 +89,23 @@ def gen_event_send(name, arg_type):
  name=name)

 if arg_type and arg_type.members:
-assert not arg_type.variants
 ret += mcgen('''
 qov = qmp_output_visitor_new();
 v = qmp_output_get_visitor(qov);

 visit_start_struct(v, "%(name)s", NULL, 0, &err);
-''',
- name=name)
-ret += gen_err_check()
-ret += gen_visit_members(arg_type.members, need_cast=True,
- label='out_obj')
-ret += mcgen('''
-out_obj:
+if (err) {
+goto out;
+}
+visit_type_%(c_name)s_members(v, ¶m, &err);
 visit_end_struct(v, err ? NULL : &err);
 if (err) {
 goto out;
 }

 qdict_put_obj(qmp, "data", qmp_output_get_qobject(qov));
-''')
+''',
+ name=name, c_name=arg_type.c_name())

 ret += mcgen('''
 emit(%(c_enum)s, qmp, &err);
-- 
2.5.0




[Qemu-devel] [PATCH 03/20] qemu-io: Call blk_set_enable_write_cache() explicitly

2016-03-18 Thread Kevin Wolf
Signed-off-by: Kevin Wolf 
---
 qemu-io.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/qemu-io.c b/qemu-io.c
index d7c2f26..260b024 100644
--- a/qemu-io.c
+++ b/qemu-io.c
@@ -50,7 +50,7 @@ static const cmdinfo_t close_cmd = {
 .oneline= "close the current open file",
 };
 
-static int openfile(char *name, int flags, QDict *opts)
+static int openfile(char *name, int flags, bool writethrough, QDict *opts)
 {
 Error *local_err = NULL;
 BlockDriverState *bs;
@@ -82,6 +82,7 @@ static int openfile(char *name, int flags, QDict *opts)
 }
 }
 
+blk_set_enable_write_cache(qemuio_blk, !writethrough);
 
 return 0;
 
@@ -136,6 +137,7 @@ static int open_f(BlockBackend *blk, int argc, char **argv)
 {
 int flags = 0;
 int readonly = 0;
+bool writethrough = true;
 int c;
 QemuOpts *qopts;
 QDict *opts;
@@ -146,7 +148,8 @@ static int open_f(BlockBackend *blk, int argc, char **argv)
 flags |= BDRV_O_SNAPSHOT;
 break;
 case 'n':
-flags |= BDRV_O_NOCACHE | BDRV_O_CACHE_WB;
+flags |= BDRV_O_NOCACHE;
+writethrough = false;
 break;
 case 'r':
 readonly = 1;
@@ -184,9 +187,9 @@ static int open_f(BlockBackend *blk, int argc, char **argv)
 qemu_opts_reset(&empty_opts);
 
 if (optind == argc - 1) {
-return openfile(argv[optind], flags, opts);
+return openfile(argv[optind], flags, writethrough, opts);
 } else if (optind == argc) {
-return openfile(NULL, flags, opts);
+return openfile(NULL, flags, writethrough, opts);
 } else {
 QDECREF(opts);
 return qemuio_command_usage(&open_cmd);
@@ -427,6 +430,7 @@ int main(int argc, char **argv)
 int c;
 int opt_index = 0;
 int flags = BDRV_O_UNMAP;
+bool writethrough = true;
 Error *local_error = NULL;
 QDict *opts = NULL;
 const char *format = NULL;
@@ -448,7 +452,8 @@ int main(int argc, char **argv)
 flags |= BDRV_O_SNAPSHOT;
 break;
 case 'n':
-flags |= BDRV_O_NOCACHE | BDRV_O_CACHE_WB;
+flags |= BDRV_O_NOCACHE;
+writethrough = false;
 break;
 case 'd':
 if (bdrv_parse_discard_flags(optarg, &flags) < 0) {
@@ -472,7 +477,7 @@ int main(int argc, char **argv)
 flags |= BDRV_O_NATIVE_AIO;
 break;
 case 't':
-if (bdrv_parse_cache_flags(optarg, &flags) < 0) {
+if (bdrv_parse_cache_mode(optarg, &flags, &writethrough) < 0) {
 error_report("Invalid cache option: %s", optarg);
 exit(1);
 }
@@ -554,13 +559,13 @@ int main(int argc, char **argv)
 exit(1);
 }
 opts = qemu_opts_to_qdict(qopts, NULL);
-openfile(NULL, flags, opts);
+openfile(NULL, flags, writethrough, opts);
 } else {
 if (format) {
 opts = qdict_new();
 qdict_put(opts, "driver", qstring_from_str(format));
 }
-openfile(argv[optind], flags, opts);
+openfile(argv[optind], flags, writethrough, opts);
 }
 }
 command_loop();
-- 
1.8.3.1




Re: [Qemu-devel] [PATCH v4 3/9] hw/timer: QOM'ify lm32_timer

2016-03-18 Thread Peter Maydell
On 17 March 2016 at 14:59,   wrote:
> [I had some problems with my mailserver and the v5 version didn't make it
> through. I know there is a v5 version of this patch series and I've tested
> with the v5 version]
>
>
> Am 2016-02-22 04:15, schrieb xiaoqiang zhao:
>>
>> * split the old SysBus init function into an instance_init
>>   and a Device realize function
>> * use DeviceClass::realize instead of SysBusDeviceClass::init
>>
>> Reviewed-by: Peter Maydell 
>> Signed-off-by: xiaoqiang zhao 
>
>
> Signed-off-by: Michael Walle 

Signed-off-by: doesn't make much sense in this situation -- did
you want Acked-by, Reviewed-by, Tested-by, or some combination
of those ?

thanks
-- PMM



[Qemu-devel] [PATCH v5 18/28] migration: convert savevm to use QIOChannel for writing to files

2016-03-18 Thread Daniel P. Berrange
Convert the exec savevm code to use QIOChannel and QEMUFileChannel,
instead of the stdio APIs.

Reviewed-by: Dr. David Alan Gilbert 
Signed-off-by: Daniel P. Berrange 
---
 migration/savevm.c   |  8 +---
 tests/Makefile   |  4 ++--
 tests/test-vmstate.c | 11 ++-
 3 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/migration/savevm.c b/migration/savevm.c
index 90a61cb..5f0309d 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -51,6 +51,7 @@
 #include "block/snapshot.h"
 #include "block/qapi.h"
 #include "io/channel-buffer.h"
+#include "io/channel-file.h"
 
 
 #ifndef ETH_P_RARP
@@ -2046,6 +2047,7 @@ void hmp_savevm(Monitor *mon, const QDict *qdict)
 void qmp_xen_save_devices_state(const char *filename, Error **errp)
 {
 QEMUFile *f;
+QIOChannelFile *ioc;
 int saved_vm_running;
 int ret;
 
@@ -2053,11 +2055,11 @@ void qmp_xen_save_devices_state(const char *filename, 
Error **errp)
 vm_stop(RUN_STATE_SAVE_VM);
 global_state_store_running();
 
-f = qemu_fopen(filename, "wb");
-if (!f) {
-error_setg_file_open(errp, errno, filename);
+ioc = qio_channel_file_new_path(filename, O_WRONLY | O_CREAT, 0660, errp);
+if (!ioc) {
 goto the_end;
 }
+f = qemu_fopen_channel_output(QIO_CHANNEL(ioc));
 ret = qemu_save_device_state(f);
 qemu_fclose(f);
 if (ret < 0) {
diff --git a/tests/Makefile b/tests/Makefile
index 63b0a0a..a881324 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -429,8 +429,8 @@ tests/test-qdev-global-props$(EXESUF): 
tests/test-qdev-global-props.o \
$(test-qapi-obj-y)
 tests/test-vmstate$(EXESUF): tests/test-vmstate.o \
migration/vmstate.o migration/qemu-file.o \
-migration/qemu-file-unix.o qjson.o \
-   $(test-qom-obj-y)
+migration/qemu-file-channel.o qjson.o \
+   $(test-io-obj-y)
 tests/test-timed-average$(EXESUF): tests/test-timed-average.o qemu-timer.o \
$(test-util-obj-y)
 tests/test-base64$(EXESUF): tests/test-base64.o \
diff --git a/tests/test-vmstate.c b/tests/test-vmstate.c
index f337cf6..d19b16a 100644
--- a/tests/test-vmstate.c
+++ b/tests/test-vmstate.c
@@ -29,6 +29,7 @@
 #include "migration/migration.h"
 #include "migration/vmstate.h"
 #include "qemu/coroutine.h"
+#include "io/channel-file.h"
 
 static char temp_file[] = "/tmp/vmst.test.XX";
 static int temp_fd;
@@ -49,11 +50,17 @@ void yield_until_fd_readable(int fd)
 static QEMUFile *open_test_file(bool write)
 {
 int fd = dup(temp_fd);
+QIOChannel *ioc;
 lseek(fd, 0, SEEK_SET);
 if (write) {
 g_assert_cmpint(ftruncate(fd, 0), ==, 0);
 }
-return qemu_fdopen(fd, write ? "wb" : "rb");
+ioc = QIO_CHANNEL(qio_channel_file_new_fd(fd));
+if (write) {
+return qemu_fopen_channel_output(ioc);
+} else {
+return qemu_fopen_channel_input(ioc);
+}
 }
 
 #define SUCCESS(val) \
@@ -469,6 +476,8 @@ int main(int argc, char **argv)
 {
 temp_fd = mkstemp(temp_file);
 
+module_call_init(MODULE_INIT_QOM);
+
 g_test_init(&argc, &argv, NULL);
 g_test_add_func("/vmstate/simple/primitive", test_simple_primitive);
 g_test_add_func("/vmstate/versioned/load/v1", test_load_v1);
-- 
2.5.0




  1   2   >