Re: [Qemu-devel] [PATCH v2 03/16] block: introduce bdrv_no_throttling_begin/end

[Fam Zheng]

On Wed, 03/16 15:16, Paolo Bonzini wrote:
> Extract the handling of throttling from bdrv_flush_io_queue.
> 
> Signed-off-by: Paolo Bonzini 

Reviewed-by: Fam Zheng 

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

[Paolo Bonzini]

On 16/03/2016 12:56, Cornelia Huck wrote:
> On Wed, 16 Mar 2016 12:48:22 +0100
> Paolo Bonzini  wrote:
> 
>>
>>
>> On 16/03/2016 12:32, Cornelia Huck wrote:
>>> 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?
>>
>> Just because we never ran the right tests, probably.  The bug is indeed
>> in virtio-pci as well (I didn't check mmio).
> 
> Somebody should probably do a writeup on the expected behaviour, as
> this always ends in mental gymnastics (at least for me :)

Yeah, it doesn't help that the functions are underdocumented (as in the
"assign" parameter above).

>>
 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?
>>
>> That's a bug in dataplane.  The calls should be changed in
>> hw/block/dataplane/virtio-blk.c
> 
> 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().

Paolo

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

[Dr. David Alan Gilbert]

* Wen Congyang (we...@cn.fujitsu.com) wrote:
> On 03/17/2016 05:10 PM, Alberto Garcia wrote:
> > On Thu 17 Mar 2016 02:22:40 AM CET, Wen Congyang  
> > wrote:
> >> @@ -81,6 +82,8 @@ typedef struct BDRVQuorumState {
> >>   bool rewrite_corrupted;/* true if the driver must 
> >> rewrite-on-read corrupted
> >>   * block if Quorum is reached.
> >>   */
> >> +unsigned long *index_bitmap;
> 
>  Hi Berto
> 
>  *NOTE*, In the old version, we just used "bs->node_name", but in the
>  lastest one, as Kevin suggested we introduce
>  "child->child_name"(formart as "children.xxx"), this is the key cause
>  why we need this two functions here.
> >>>
> >>> I'm sorry I missed this discussion earlier. Your code seems technically
> >>> correct but I have several questions:
> >>>
> >>> - I read that one of the reasons for this change is that "In theory, the
> >>>   same node could be attached twice to the same parent in different
> >>>   roles.". Is there any example of that? What's the use case?
> >>
> >> Kevin may know the case.
> > 
> > Kevin, do you have an example?
> > 
> >>> - How do you obtain the child name?
> >>
> >> IIRC, the answer is no now. I think we can improve 'info block' output
> > 
> > Okay, but then we should extend that first, otherwise this API cannot be
> > used.
> > 
> >>> - I see that if you have children.0 and children.1 (let's say hd0.qcow2
> >>>   and hd1.qcow2), then you remove children.0 and add it again, it will
> >>>   keep the 'children.0' name (that's what the bitmap is for if I'm
> >>>   understanding it correctly). However the position in the s->children
> >>>   array will change because you do memmove() when you remove children.0
> >>>   and then add it again to the end of the array.
> >>>
> >>>   Initial status:
> >>>
> >>> s->children[0] <--> "children.0" (hd0.qcow2)
> >>> s->children[1] <--> "children.1" (hd1.qcow2)
> >>>
> >>>   children.0 (hd0.qcow2) is removed:
> >>>
> >>> s->children[0] <--> "children.1" (hd1.qcow2)
> >>>
> >>>   children.0 (hd0.qcow2) is added again:
> >>>
> >>> s->children[0] <--> "children.1" (hd1.qcow2)
> >>> s->children[1] <--> "children.0" (hd0.qcow2)
> >>
> >> Yes, it is correct.
> >>
> >>>
> >>>   Is this correct? Is this the indented behavior? Since you are reading
> >>>   in FIFO mode, now hd1.qcow2 will always be read first, so if
> >>>   children.1 was the secondary disk, it has just become the primary.
> >>
> >> Yes.
> > 
> > And don't you need a way to control the order in which the disks must be
> > read for COLO?
> 
> I think in fifo mode, we should read the disk first that is added earlier.
> 
> We don't need a way to control the order now.

Can you document fully how it's used in COLO then?
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.
The children.0 notation is really confusing in the way that Berto
describes; I hit this a couple of months ago and it really doesn't
make sense.

Dave

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

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

[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 

Re: [Qemu-devel] [PATCH 1/2] quorum: Emit QUORUM_REPORT_BAD for reads in fifo mode

[Max Reitz]

On 15.03.2016 10:41, Alberto Garcia wrote:
> If there's an I/O error in one of Quorum children then QEMU
> should emit QUORUM_REPORT_BAD. However this is not working with
> read-pattern=fifo. This patch fixes this problem.
> 
> Signed-off-by: Alberto Garcia 
> ---
>  block/quorum.c | 17 +
>  1 file changed, 9 insertions(+), 8 deletions(-)

Reviewed-by: Max Reitz 



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH v4 03/17] block: Add blk_commit_all()

[Max Reitz]

Later, we will remove bdrv_commit_all() and move its contents here, and
in order to replace bdrv_commit_all() calls by calls to blk_commit_all()
before doing so, we need to add it as an alias now.

Signed-off-by: Max Reitz 
Reviewed-by: Kevin Wolf 
---
 block/block-backend.c  | 5 +
 include/sysemu/block-backend.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/block/block-backend.c b/block/block-backend.c
index 7a04e10..e75b8fe 100644
--- a/block/block-backend.c
+++ b/block/block-backend.c
@@ -1329,3 +1329,8 @@ BlockBackendRootState *blk_get_root_state(BlockBackend 
*blk)
 {
 return >root_state;
 }
+
+int blk_commit_all(void)
+{
+return bdrv_commit_all();
+}
diff --git a/include/sysemu/block-backend.h b/include/sysemu/block-backend.h
index 00d69ba..84612ce 100644
--- a/include/sysemu/block-backend.h
+++ b/include/sysemu/block-backend.h
@@ -127,6 +127,7 @@ int blk_co_discard(BlockBackend *blk, int64_t sector_num, 
int nb_sectors);
 int blk_co_flush(BlockBackend *blk);
 int blk_flush(BlockBackend *blk);
 int blk_flush_all(void);
+int blk_commit_all(void);
 void blk_drain(BlockBackend *blk);
 void blk_drain_all(void);
 void blk_set_on_error(BlockBackend *blk, BlockdevOnError on_read_error,
-- 
2.7.3

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

[Thomas Huth]

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.

[...]
>> +/**
>> + * 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




signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PULL 34/40] qdev: New DEFINE_PROP_ON_OFF_AUTO

[Markus Armbruster]

Signed-off-by: Markus Armbruster 
Reviewed-by: Marc-André Lureau 
Message-Id: <1458066895-20632-35-git-send-email-arm...@redhat.com>
---
 hw/core/qdev-properties.c| 10 ++
 include/hw/qdev-properties.h |  3 +++
 2 files changed, 13 insertions(+)

diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
index bc89800..d2f5a08 100644
--- a/hw/core/qdev-properties.c
+++ b/hw/core/qdev-properties.c
@@ -516,6 +516,16 @@ PropertyInfo qdev_prop_macaddr = {
 .set   = set_mac,
 };
 
+/* --- on/off/auto --- */
+
+PropertyInfo qdev_prop_on_off_auto = {
+.name = "OnOffAuto",
+.description = "on/off/auto",
+.enum_table = OnOffAuto_lookup,
+.get = get_enum,
+.set = set_enum,
+};
+
 /* --- lost tick policy --- */
 
 QEMU_BUILD_BUG_ON(sizeof(LostTickPolicy) != sizeof(int));
diff --git a/include/hw/qdev-properties.h b/include/hw/qdev-properties.h
index 03a1b91..0586cac 100644
--- a/include/hw/qdev-properties.h
+++ b/include/hw/qdev-properties.h
@@ -18,6 +18,7 @@ extern PropertyInfo qdev_prop_string;
 extern PropertyInfo qdev_prop_chr;
 extern PropertyInfo qdev_prop_ptr;
 extern PropertyInfo qdev_prop_macaddr;
+extern PropertyInfo qdev_prop_on_off_auto;
 extern PropertyInfo qdev_prop_losttickpolicy;
 extern PropertyInfo qdev_prop_bios_chs_trans;
 extern PropertyInfo qdev_prop_fdc_drive_type;
@@ -155,6 +156,8 @@ extern PropertyInfo qdev_prop_arraylen;
 DEFINE_PROP(_n, _s, _f, qdev_prop_drive, BlockBackend *)
 #define DEFINE_PROP_MACADDR(_n, _s, _f) \
 DEFINE_PROP(_n, _s, _f, qdev_prop_macaddr, MACAddr)
+#define DEFINE_PROP_ON_OFF_AUTO(_n, _s, _f, _d) \
+DEFINE_PROP_DEFAULT(_n, _s, _f, _d, qdev_prop_on_off_auto, OnOffAuto)
 #define DEFINE_PROP_LOSTTICKPOLICY(_n, _s, _f, _d) \
 DEFINE_PROP_DEFAULT(_n, _s, _f, _d, qdev_prop_losttickpolicy, \
 LostTickPolicy)
-- 
2.4.3

[Qemu-devel] [PATCH for-2.6 06/14] pc-bios/s390-ccw: add vdev object to store all device details

[Cornelia Huck]

From: "Eugene (jno) Dvurechenski" 

Add VDev "object" as a container for all device-related items.
The default object is static.

Leverage dependency on many different device-related globals.
Make them syntactically visible.

Signed-off-by: Eugene (jno) Dvurechenski 
Signed-off-by: Cornelia Huck 
---
 pc-bios/s390-ccw/virtio.c | 181 +-
 pc-bios/s390-ccw/virtio.h |  18 +
 2 files changed, 116 insertions(+), 83 deletions(-)

diff --git a/pc-bios/s390-ccw/virtio.c b/pc-bios/s390-ccw/virtio.c
index d366aa3..6bf0c38 100644
--- a/pc-bios/s390-ccw/virtio.c
+++ b/pc-bios/s390-ccw/virtio.c
@@ -11,13 +11,34 @@
 #include "s390-ccw.h"
 #include "virtio.h"
 
+#define VRING_WAIT_REPLY_TIMEOUT 3
+
 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)));
 
+static VDev vdev = {
+.nr_vqs = 1,
+.vrings = block,
+.cmd_vr_idx = 0,
+.ring_area = ring_area,
+.wait_reply_timeout = VRING_WAIT_REPLY_TIMEOUT,
+.guessed_disk_nature = false,
+.schid = { .one = 1 },
+};
+
+VDev *virtio_get_device(void)
+{
+return 
+}
+
+VirtioDevType virtio_get_device_type(void)
+{
+return vdev.senseid.cu_model;
+}
+
 /* virtio spec v1.0 para 4.3.3.2 */
 static long kvm_hypercall(unsigned long nr, unsigned long param1,
   unsigned long param2, unsigned long param3)
@@ -65,7 +86,7 @@ static int drain_irqs(SubChannelId schid)
 }
 }
 
-static int run_ccw(SubChannelId schid, int cmd, void *ptr, int len)
+static int run_ccw(VDev *vdev, int cmd, void *ptr, int len)
 {
 Ccw1 ccw = {};
 CmdOrb orb = {};
@@ -73,9 +94,9 @@ static int run_ccw(SubChannelId schid, int cmd, void *ptr, 
int len)
 int r;
 
 /* start command processing */
-stsch_err(schid, );
+stsch_err(vdev->schid, );
 schib.scsw.ctrl = SCSW_FCTL_START_FUNC;
-msch(schid, );
+msch(vdev->schid, );
 
 /* start subchannel command */
 orb.fmt = 1;
@@ -86,32 +107,18 @@ static int run_ccw(SubChannelId schid, int cmd, void *ptr, 
int len)
 ccw.cda = (long)ptr;
 ccw.count = len;
 
-r = ssch(schid, );
+r = ssch(vdev->schid, );
 /*
  * XXX Wait until device is done processing the CCW. For now we can
  * assume that a simple tsch will have finished the CCW processing,
  * but the architecture allows for asynchronous operation
  */
 if (!r) {
-r = drain_irqs(schid);
+r = drain_irqs(vdev->schid);
 }
 return r;
 }
 
-static void virtio_set_status(SubChannelId schid,
-  unsigned long dev_addr)
-{
-unsigned char status = dev_addr;
-if (run_ccw(schid, CCW_CMD_WRITE_STATUS, , sizeof(status))) {
-panic("Could not write status to host!\n");
-}
-}
-
-static void virtio_reset(SubChannelId schid)
-{
-run_ccw(schid, CCW_CMD_VDEV_RESET, NULL, 0);
-}
-
 static void vring_init(VRing *vr, VqInfo *info)
 {
 void *p = (void *) info->queue;
@@ -199,22 +206,22 @@ static int vr_poll(VRing *vr)
  *
  * Returns 0 on success, 1 on timeout.
  */
-static int vring_wait_reply(int timeout)
+static int vring_wait_reply(void)
 {
-ulong target_second = get_second() + timeout;
+ulong target_second = get_second() + vdev.wait_reply_timeout;
 
 /* Wait for any queue to be updated by the host */
 do {
 int i, r = 0;
 
-for (i = 0; i < nr_vqs; i++) {
-r += vr_poll([i]);
+for (i = 0; i < vdev.nr_vqs; i++) {
+r += vr_poll([i]);
 }
 yield();
 if (r) {
 return 0;
 }
-} while (!timeout || (get_second() < target_second));
+} while (!vdev.wait_reply_timeout || (get_second() < target_second));
 
 return 1;
 }
@@ -227,29 +234,28 @@ int virtio_read_many(ulong sector, void *load_addr, int 
sec_num)
 {
 VirtioBlkOuthdr out_hdr;
 u8 status;
-int r;
+VRing *vr = [vdev.cmd_vr_idx];
 
 /* Tell the host we want to read */
 out_hdr.type = VIRTIO_BLK_T_IN;
 out_hdr.ioprio = 99;
 out_hdr.sector = virtio_sector_adjust(sector);
 
-vring_send_buf([0], _hdr, sizeof(out_hdr), VRING_DESC_F_NEXT);
+vring_send_buf(vr, _hdr, sizeof(out_hdr), VRING_DESC_F_NEXT);
 
 /* This is where we want to receive data */
-vring_send_buf([0], load_addr, virtio_get_block_size() * sec_num,
+vring_send_buf(vr, load_addr, virtio_get_block_size() * sec_num,
VRING_DESC_F_WRITE | VRING_HIDDEN_IS_CHAIN |
VRING_DESC_F_NEXT);
 
 /* status field */
-vring_send_buf([0], , sizeof(u8), VRING_DESC_F_WRITE |
-   VRING_HIDDEN_IS_CHAIN);
+vring_send_buf(vr, , sizeof(u8),
+   VRING_DESC_F_WRITE | 

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

[Pooja Dhannawat]

On Friday, March 18, 2016, Paolo Bonzini  wrote:
>
>
> On 18/03/2016 14:49, Pooja Dhannawat wrote:
>>
>>
>> If it is greater than the accepted level, the on-stack
>> buffer is not
>> used and you allocate one that has the right size on the
heap.
>>
>> Yes Okay. Thank you for the comments.
>> I had one more question.
>> size = qemu_recv(s->fd, buf1, sizeof(buf1), 0);
>> The one above returns bytes read into buf1 (if large then bytes
>> equivalent to len(buf1) is read) ?
>> If true, size is the correct measure of buf1? Hence, I should
>> compare the allowed stack size to "size" variable?
>>
>>So isnt here size should be compared to "size" varibale paolo?
>>
>> So instead of comparing with NET_BUFSIZE, should I compare with "size"
>> variable? Can you help me with this?
>
> I was a bit confused myself; this function actually is a bit different
> from the others because it does not really need a large buffer.  The
> function already takes care of moving data in pieces from buf1 to
> s->buf.  If you make the buffer smaller, the only change is that one
> call to net_socket_send will process fewer bytes.
>
> So you can just send a trivial patch that changes the size of the array
> to something like 2048.
>
> Thanks, and sorry for putting you on a false track!
>
No, it's completely fine,  I really appreciate your help.
> Paolo
>

Re: [Qemu-devel] [PATCH 1/5] tcg: code_bitmap is not used by user-mode emulation

[Peter Maydell]

On 17 March 2016 at 13:46,   wrote:
> From: Paolo Bonzini 
>
> Signed-off-by: Paolo Bonzini 
> Signed-off-by: Sergey Fedorov 
> ---
>  translate-all.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/translate-all.c b/translate-all.c
> index e9f409b762ab..f17ace1ae899 100644
> --- a/translate-all.c
> +++ b/translate-all.c
> @@ -784,6 +784,9 @@ void tb_free(TranslationBlock *tb)
>
>  static inline void invalidate_page_bitmap(PageDesc *p)
>  {
> +#ifndef CONFIG_SOFTMMU
> +assert(p->code_bitmap == NULL);
> +#endif
>  g_free(p->code_bitmap);
>  p->code_bitmap = NULL;
>  p->code_write_count = 0;
> @@ -1018,6 +1021,7 @@ void tb_phys_invalidate(TranslationBlock *tb, 
> tb_page_addr_t page_addr)
>  tcg_ctx.tb_ctx.tb_phys_invalidate_count++;
>  }

You could pretty much take this another step and actually
make the field in the struct be only present ifdef CONFIG_SOFTMMU...

thanks
-- PMM

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

[Dr. David Alan Gilbert]

* Stefan Hajnoczi (stefa...@redhat.com) wrote:
> 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.

Well that sounds easy - but is it easy to avoid using those fixed IDs
in any of the trace.h functions that are included everywhere (without
making them more expensive).

Dave

> Stefan


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

Re: [Qemu-devel] [Qemu-block] [PATCH v16 2/8] Backup: clear all bitmap when doing block checkpoint

[Changlong Xie]

On 03/17/2016 02:48 AM, Jeff Cody wrote:

On Fri, Mar 11, 2016 at 06:34:09PM +0800, Changlong Xie wrote:

From: Wen Congyang 

Signed-off-by: Wen Congyang 
Signed-off-by: zhanghailiang 
Signed-off-by: Gonglei 
Signed-off-by: Changlong Xie 
---
  block/backup.c| 15 +++
  include/block/block_int.h |  2 ++
  2 files changed, 17 insertions(+)

diff --git a/block/backup.c b/block/backup.c
index 0f1b1bc..b2ba939 100644
--- a/block/backup.c
+++ b/block/backup.c
@@ -256,6 +256,21 @@ static void backup_abort(BlockJob *job)
  }
  }

+void backup_do_checkpoint(BlockJob *job, Error **errp)
+{
+BackupBlockJob *backup_job = container_of(job, BackupBlockJob, common);
+
+assert(job->driver->job_type == BLOCK_JOB_TYPE_BACKUP);
+
+if (backup_job->sync_mode != MIRROR_SYNC_MODE_NONE) {
+error_setg(errp, "The backup job only supports block checkpoint in"
+   " sync=none mode");
+return;
+}
+
+hbitmap_reset_all(backup_job->bitmap);


This variable changed name and type, it is a simple bitmap now called
'done_bitmap' (backup_job->done_bitmap), and type 'unsigned long *'.


Thanks for pointing it out, will fix in next version.

Thanks
-Xie



+}
+
  static const BlockJobDriver backup_job_driver = {
  .instance_size  = sizeof(BackupBlockJob),
  .job_type   = BLOCK_JOB_TYPE_BACKUP,
diff --git a/include/block/block_int.h b/include/block/block_int.h
index 704efe5..48f0f1f 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -699,6 +699,8 @@ void backup_start(BlockDriverState *bs, BlockDriverState 
*target,
BlockCompletionFunc *cb, void *opaque,
BlockJobTxn *txn, Error **errp);

+void backup_do_checkpoint(BlockJob *job, Error **errp);
+
  void blk_set_bs(BlockBackend *blk, BlockDriverState *bs);

  void blk_dev_change_media_cb(BlockBackend *blk, bool load);
--
1.9.3







.

[Qemu-devel] [PATCH v2 05/10] ppc: Add dummy SPR_IC for POWER8

[Cédric Le Goater]

From: Benjamin Herrenschmidt 

It's supposed to be an instruction counter. For now make us not
crash when accessing it.

Signed-off-by: Benjamin Herrenschmidt 
Reviewed-by: Thomas Huth 
Reviewed-by: David Gibson 
---

 This is required for patch "ppc: A couple more dummy POWER8 Book4 regs"

 target-ppc/cpu.h|  1 +
 target-ppc/translate_init.c | 12 
 2 files changed, 13 insertions(+)

diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index a7da0d3e95a9..167c73f863b3 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -1685,6 +1685,7 @@ static inline int cpu_mmu_index (CPUPPCState *env, bool 
ifetch)
 #define SPR_MPC_MD_DBRAM1 (0x32A)
 #define SPR_RCPU_L2U_RA3  (0x32B)
 #define SPR_TAR   (0x32F)
+#define SPR_IC(0x350)
 #define SPR_VTB   (0x351)
 #define SPR_MMCRC (0x353)
 #define SPR_440_INV0  (0x370)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index aaf8ad79361e..fa8d217295b9 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7924,6 +7924,17 @@ static void gen_spr_power8_pspb(CPUPPCState *env)
  KVM_REG_PPC_PSPB, 0);
 }
 
+static void gen_spr_power8_ic(CPUPPCState *env)
+{
+#if !defined(CONFIG_USER_ONLY)
+spr_register_hv(env, SPR_IC, "IC",
+SPR_NOACCESS, SPR_NOACCESS,
+_read_generic, SPR_NOACCESS,
+_read_generic, _write_generic,
+0);
+#endif
+}
+
 static void init_proc_book3s_64(CPUPPCState *env, int version)
 {
 gen_spr_ne_601(env);
@@ -7976,6 +7987,7 @@ static void init_proc_book3s_64(CPUPPCState *env, int 
version)
 gen_spr_power8_tm(env);
 gen_spr_power8_pspb(env);
 gen_spr_vtb(env);
+gen_spr_power8_ic(env);
 }
 if (version < BOOK3S_CPU_POWER8) {
 gen_spr_book3s_dbg(env);
-- 
2.1.4

[Qemu-devel] [PULL 10/21] i.MX: Add i.MX6 CCM and ANALOG device.

[Peter Maydell]

From: Jean-Christophe Dubois 

Reviewed-by: Peter Maydell 
Signed-off-by: Jean-Christophe Dubois 
Message-id: 
9fa80b4d8c5d0f50c94e77d74f952a7a665e168f.1456868959.git@tribudubois.net
Signed-off-by: Peter Maydell 
---
 hw/misc/Makefile.objs  |   1 +
 hw/misc/imx6_ccm.c | 774 +
 include/hw/misc/imx6_ccm.h | 197 
 3 files changed, 972 insertions(+)
 create mode 100644 hw/misc/imx6_ccm.c
 create mode 100644 include/hw/misc/imx6_ccm.h

diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index ea6cd3c..44ac2e1 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -28,6 +28,7 @@ obj-$(CONFIG_EXYNOS4) += exynos4210_pmu.o
 obj-$(CONFIG_IMX) += imx_ccm.o
 obj-$(CONFIG_IMX) += imx31_ccm.o
 obj-$(CONFIG_IMX) += imx25_ccm.o
+obj-$(CONFIG_IMX) += imx6_ccm.o
 obj-$(CONFIG_MILKYMIST) += milkymist-hpdmc.o
 obj-$(CONFIG_MILKYMIST) += milkymist-pfpu.o
 obj-$(CONFIG_MAINSTONE) += mst_fpga.o
diff --git a/hw/misc/imx6_ccm.c b/hw/misc/imx6_ccm.c
new file mode 100644
index 000..4e1d49d
--- /dev/null
+++ b/hw/misc/imx6_ccm.c
@@ -0,0 +1,774 @@
+/*
+ * IMX6 Clock Control Module
+ *
+ * Copyright (c) 2015 Jean-Christophe Dubois 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ * To get the timer frequencies right, we need to emulate at least part of
+ * the CCM.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/misc/imx6_ccm.h"
+
+#ifndef DEBUG_IMX6_CCM
+#define DEBUG_IMX6_CCM 0
+#endif
+
+#define DPRINTF(fmt, args...) \
+do { \
+if (DEBUG_IMX6_CCM) { \
+fprintf(stderr, "[%s]%s: " fmt , TYPE_IMX6_CCM, \
+ __func__, ##args); \
+} \
+} while (0)
+
+static char const *imx6_ccm_reg_name(uint32_t reg)
+{
+static char unknown[20];
+
+switch (reg) {
+case CCM_CCR:
+return "CCR";
+case CCM_CCDR:
+return "CCDR";
+case CCM_CSR:
+return "CSR";
+case CCM_CCSR:
+return "CCSR";
+case CCM_CACRR:
+return "CACRR";
+case CCM_CBCDR:
+return "CBCDR";
+case CCM_CBCMR:
+return "CBCMR";
+case CCM_CSCMR1:
+return "CSCMR1";
+case CCM_CSCMR2:
+return "CSCMR2";
+case CCM_CSCDR1:
+return "CSCDR1";
+case CCM_CS1CDR:
+return "CS1CDR";
+case CCM_CS2CDR:
+return "CS2CDR";
+case CCM_CDCDR:
+return "CDCDR";
+case CCM_CHSCCDR:
+return "CHSCCDR";
+case CCM_CSCDR2:
+return "CSCDR2";
+case CCM_CSCDR3:
+return "CSCDR3";
+case CCM_CDHIPR:
+return "CDHIPR";
+case CCM_CTOR:
+return "CTOR";
+case CCM_CLPCR:
+return "CLPCR";
+case CCM_CISR:
+return "CISR";
+case CCM_CIMR:
+return "CIMR";
+case CCM_CCOSR:
+return "CCOSR";
+case CCM_CGPR:
+return "CGPR";
+case CCM_CCGR0:
+return "CCGR0";
+case CCM_CCGR1:
+return "CCGR1";
+case CCM_CCGR2:
+return "CCGR2";
+case CCM_CCGR3:
+return "CCGR3";
+case CCM_CCGR4:
+return "CCGR4";
+case CCM_CCGR5:
+return "CCGR5";
+case CCM_CCGR6:
+return "CCGR6";
+case CCM_CMEOR:
+return "CMEOR";
+default:
+sprintf(unknown, "%d ?", reg);
+return unknown;
+}
+}
+
+static char const *imx6_analog_reg_name(uint32_t reg)
+{
+static char unknown[20];
+
+switch (reg) {
+case CCM_ANALOG_PLL_ARM:
+return "PLL_ARM";
+case CCM_ANALOG_PLL_ARM_SET:
+return "PLL_ARM_SET";
+case CCM_ANALOG_PLL_ARM_CLR:
+return "PLL_ARM_CLR";
+case CCM_ANALOG_PLL_ARM_TOG:
+return "PLL_ARM_TOG";
+case CCM_ANALOG_PLL_USB1:
+return "PLL_USB1";
+case CCM_ANALOG_PLL_USB1_SET:
+return "PLL_USB1_SET";
+case CCM_ANALOG_PLL_USB1_CLR:
+return "PLL_USB1_CLR";
+case CCM_ANALOG_PLL_USB1_TOG:
+return "PLL_USB1_TOG";
+case CCM_ANALOG_PLL_USB2:
+return "PLL_USB2";
+case CCM_ANALOG_PLL_USB2_SET:
+return "PLL_USB2_SET";
+case CCM_ANALOG_PLL_USB2_CLR:
+return "PLL_USB2_CLR";
+case CCM_ANALOG_PLL_USB2_TOG:
+return "PLL_USB2_TOG";
+case CCM_ANALOG_PLL_SYS:
+return "PLL_SYS";
+case CCM_ANALOG_PLL_SYS_SET:
+return "PLL_SYS_SET";
+case CCM_ANALOG_PLL_SYS_CLR:
+return "PLL_SYS_CLR";
+case CCM_ANALOG_PLL_SYS_TOG:
+return "PLL_SYS_TOG";
+case CCM_ANALOG_PLL_SYS_SS:
+return "PLL_SYS_SS";
+case CCM_ANALOG_PLL_SYS_NUM:
+return "PLL_SYS_NUM";
+case CCM_ANALOG_PLL_SYS_DENOM:
+return "PLL_SYS_DENOM";
+case CCM_ANALOG_PLL_AUDIO:
+return "PLL_AUDIO";
+case CCM_ANALOG_PLL_AUDIO_SET:
+return 

Re: [Qemu-devel] [PATCH v3 26/40] ivshmem: Propagate errors through ivshmem_recv_setup()

[Marc-André Lureau]

On Tue, Mar 15, 2016 at 7:34 PM, Markus Armbruster  wrote:
> This kills off the funny state described in the previous commit.
>
> Simplify ivshmem_io_read() accordingly, and update documentation.
>
> Signed-off-by: Markus Armbruster 

Reviewed-by: Marc-André Lureau 




> ---
>  docs/specs/ivshmem-spec.txt |  20 +++
>  hw/misc/ivshmem.c   | 129 
> 
>  qemu-doc.texi   |   9 +---
>  3 files changed, 95 insertions(+), 63 deletions(-)
>
> diff --git a/docs/specs/ivshmem-spec.txt b/docs/specs/ivshmem-spec.txt
> index 0cd63ad..4c33973 100644
> --- a/docs/specs/ivshmem-spec.txt
> +++ b/docs/specs/ivshmem-spec.txt
> @@ -62,11 +62,11 @@ There are two ways to use this device:
>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.
> +Before QEMU 2.6.0, BAR2 can initially be invalid if the device is
> +configured for interrupts.  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.
> @@ -82,7 +82,7 @@ BAR 0 contains the following registers:
>  4 4   read/write0   Interrupt Status
>  bit 0: peer interrupt
>  bit 1..31: reserved
> -8 4   read-only   0 or -1   IVPosition
> +8 4   read-only   0 or ID   IVPosition
> 12 4   write-only  N/A   Doorbell
>  bit 0..15: vector
>  bit 16..31: peer ID
> @@ -100,12 +100,14 @@ when an interrupt request from a peer is received.  
> Reading the
>  register clears it.
>
>  IVPosition Register: if the device is not configured for interrupts,
> -this is zero.  Else, it's -1 for a short while after reset, then
> -changes to the device's ID (between 0 and 65535).
> +this is zero.  Else, it is the device's ID (between 0 and 65535).
> +
> +Before QEMU 2.6.0, the register may read -1 for a short while after
> +reset.
>
>  There is no good way for software to find out whether the device is
>  configured for interrupts.  A positive IVPosition means interrupts,
> -but zero could be either.  The initial -1 cannot be reliably observed.
> +but zero could be either.
>
>  Doorbell Register: writing this register requests to interrupt a peer.
>  The written value's high 16 bits are the ID of the peer to interrupt,
> diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
> index ad16828..7f439c3 100644
> --- a/hw/misc/ivshmem.c
> +++ b/hw/misc/ivshmem.c
> @@ -234,12 +234,7 @@ static uint64_t ivshmem_io_read(void *opaque, hwaddr 
> addr,
>  break;
>
>  case IVPOSITION:
> -/* return my VM ID if the memory is mapped */
> -if (memory_region_is_mapped(>ivshmem)) {
> -ret = s->vm_id;
> -} else {
> -ret = -1;
> -}
> +ret = s->vm_id;
>  break;
>
>  default:
> @@ -511,7 +506,8 @@ static bool fifo_update_and_get_i64(IVShmemState *s,
>  return false;
>  }
>
> -static int ivshmem_add_kvm_msi_virq(IVShmemState *s, int vector)
> +static void ivshmem_add_kvm_msi_virq(IVShmemState *s, int vector,
> + Error **errp)
>  {
>  PCIDevice *pdev = PCI_DEVICE(s);
>  MSIMessage msg = msix_get_message(pdev, vector);
> @@ -522,22 +518,21 @@ static int ivshmem_add_kvm_msi_virq(IVShmemState *s, 
> int vector)
>
>  ret = kvm_irqchip_add_msi_route(kvm_state, msg, pdev);
>  if (ret < 0) {
> -error_report("ivshmem: kvm_irqchip_add_msi_route failed");
> -return -1;
> +error_setg(errp, "kvm_irqchip_add_msi_route failed");
> +return;
>  }
>
>  s->msi_vectors[vector].virq = ret;
>  s->msi_vectors[vector].pdev = pdev;
> -
> -return 0;
>  }
>
> -static void setup_interrupt(IVShmemState *s, int vector)
> +static void setup_interrupt(IVShmemState *s, int vector, Error **errp)
>  {
>  EventNotifier *n = >peers[s->vm_id].eventfds[vector];
>  bool with_irqfd = kvm_msi_via_irqfd_enabled() &&
>  ivshmem_has_feature(s, IVSHMEM_MSI);
>  PCIDevice *pdev = PCI_DEVICE(s);
> +Error *err = NULL;
>
>  IVSHMEM_DPRINTF("setting up interrupt for vector: %d\n", vector);
>
> @@ -546,13 +541,16 @@ static void 

Re: [Qemu-devel] Hi good afternoon, some small support

[Stefan Hajnoczi]

On Fri, Mar 04, 2016 at 08:52:37PM +, Sanchez, Juan Carlos (GE Aviation) 
wrote:
>   I am trying to execute an image created by ARM in QEMU using windows 
> OS, could you give me guide to example the command line? 
> 
> The command line in Unix work well, but I don't understood all the options. 
> This the reason that I looking for some help
> 
> /home/nhcu02t/yocto_i686/prebuild/sysroots/i686-pokysdk-linux/usr/bin/qemu-system-arm
>  -kernel zImage-qemuarm.bin -net nic,model=virtio -net 
> tap,vlan=0,ifname=tap0,script=no,downscript=no -M versatilepb -drive 
> file=/home/nhcu02t/yocto_org_built/images/qemuarm/core-image-minimal-qemuarm.ext4,if=virtio,format=raw
>  -no-reboot -show-cursor -usb -usbdevice wacom-tablet -no-reboot -m 128 
> -serial mon:vc -serial null --append "root=/dev/vda rw console=ttyAMA0,115200 
> console=tty ip=192.168.7.2::192.168.7.1:255.255.255.0 mem=128M highres=off 
> rootfstype=ext4 "
> 
> 
> I accept any help that you provide me.

Did you look at the documentation?

This should help you understand most of the options:
http://qemu.weilnetz.de/qemu-doc.html

If you have specific questions, feel free to ask.

Stefan


signature.asc
Description: PGP signature

[Qemu-devel] [PATCH v5 15/28] migration: convert fd socket protocol to use QIOChannel

[Daniel P. Berrange]

Convert the fd socket migration protocol driver to use
QIOChannel and QEMUFileChannel, instead of plain sockets
APIs. It can be unconditionally built because the
QIOChannel APIs it uses will take care to report suitable
error messages if needed.

Reviewed-by: Dr. David Alan Gilbert 
Signed-off-by: Daniel P. Berrange 
---
 migration/Makefile.objs |  4 +--
 migration/fd.c  | 76 +++--
 migration/migration.c   |  4 ---
 trace-events|  4 +++
 4 files changed, 35 insertions(+), 53 deletions(-)

diff --git a/migration/Makefile.objs b/migration/Makefile.objs
index 59e8c09..0987bb6 100644
--- a/migration/Makefile.objs
+++ b/migration/Makefile.objs
@@ -1,11 +1,11 @@
-common-obj-y += migration.o socket.o
+common-obj-y += migration.o socket.o fd.o
 common-obj-y += vmstate.o
 common-obj-y += qemu-file.o qemu-file-buf.o qemu-file-unix.o qemu-file-stdio.o
 common-obj-y += qemu-file-channel.o
 common-obj-y += xbzrle.o postcopy-ram.o
 
 common-obj-$(CONFIG_RDMA) += rdma.o
-common-obj-$(CONFIG_POSIX) += exec.o fd.o
+common-obj-$(CONFIG_POSIX) += exec.o
 
 common-obj-y += block.o
 
diff --git a/migration/fd.c b/migration/fd.c
index 085dd7c..1a7fd43 100644
--- a/migration/fd.c
+++ b/migration/fd.c
@@ -1,10 +1,11 @@
 /*
  * QEMU live migration via generic fd
  *
- * Copyright Red Hat, Inc. 2009
+ * Copyright Red Hat, Inc. 2009-2016
  *
  * Authors:
  *  Chris Lalancette 
+ *  Daniel P. Berrange 
  *
  * This work is licensed under the terms of the GNU GPL, version 2.  See
  * the COPYING file in the top-level directory.
@@ -14,76 +15,57 @@
  */
 
 #include "qemu/osdep.h"
-#include "qemu-common.h"
-#include "qemu/main-loop.h"
-#include "qemu/sockets.h"
 #include "migration/migration.h"
 #include "monitor/monitor.h"
-#include "migration/qemu-file.h"
-#include "block/block.h"
+#include "io/channel-util.h"
+#include "trace.h"
 
-//#define DEBUG_MIGRATION_FD
-
-#ifdef DEBUG_MIGRATION_FD
-#define DPRINTF(fmt, ...) \
-do { printf("migration-fd: " fmt, ## __VA_ARGS__); } while (0)
-#else
-#define DPRINTF(fmt, ...) \
-do { } while (0)
-#endif
-
-static bool fd_is_socket(int fd)
-{
-struct stat stat;
-int ret = fstat(fd, );
-if (ret == -1) {
-/* When in doubt say no */
-return false;
-}
-return S_ISSOCK(stat.st_mode);
-}
 
 void fd_start_outgoing_migration(MigrationState *s, const char *fdname, Error 
**errp)
 {
+QIOChannel *ioc;
 int fd = monitor_get_fd(cur_mon, fdname, errp);
 if (fd == -1) {
 return;
 }
 
-if (fd_is_socket(fd)) {
-s->to_dst_file = qemu_fopen_socket(fd, "wb");
-} else {
-s->to_dst_file = qemu_fdopen(fd, "wb");
+trace_migration_fd_outgoing(fd);
+ioc = qio_channel_new_fd(fd, errp);
+if (!ioc) {
+close(fd);
+return;
 }
 
-migrate_fd_connect(s);
+migration_set_outgoing_channel(s, ioc);
+object_unref(OBJECT(ioc));
 }
 
-static void fd_accept_incoming_migration(void *opaque)
+static gboolean fd_accept_incoming_migration(QIOChannel *ioc,
+ GIOCondition condition,
+ gpointer opaque)
 {
-QEMUFile *f = opaque;
-
-qemu_set_fd_handler(qemu_get_fd(f), NULL, NULL, NULL);
-process_incoming_migration(f);
+migration_set_incoming_channel(migrate_get_current(), ioc);
+object_unref(OBJECT(ioc));
+return FALSE; /* unregister */
 }
 
 void fd_start_incoming_migration(const char *infd, Error **errp)
 {
+QIOChannel *ioc;
 int fd;
-QEMUFile *f;
-
-DPRINTF("Attempting to start an incoming migration via fd\n");
 
 fd = strtol(infd, NULL, 0);
-if (fd_is_socket(fd)) {
-f = qemu_fopen_socket(fd, "rb");
-} else {
-f = qemu_fdopen(fd, "rb");
-}
-if(f == NULL) {
-error_setg_errno(errp, errno, "failed to open the source descriptor");
+trace_migration_fd_incoming(fd);
+
+ioc = qio_channel_new_fd(fd, errp);
+if (!ioc) {
+close(fd);
 return;
 }
 
-qemu_set_fd_handler(fd, fd_accept_incoming_migration, NULL, f);
+qio_channel_add_watch(ioc,
+  G_IO_IN,
+  fd_accept_incoming_migration,
+  NULL,
+  NULL);
 }
diff --git a/migration/migration.c b/migration/migration.c
index 909a399..1502f46 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -317,10 +317,8 @@ void qemu_start_incoming_migration(const char *uri, Error 
**errp)
 #endif
 } else if (strstart(uri, "unix:", )) {
 unix_start_incoming_migration(p, errp);
-#if !defined(WIN32)
 } else if (strstart(uri, "fd:", )) {
 fd_start_incoming_migration(p, errp);
-#endif
 } else {
 error_setg(errp, "unknown migration protocol: %s", uri);
 }
@@ -1068,10 +1066,8 @@ void 

Re: [Qemu-devel] [Qemu-arm] [PATCH] hw/arm/bcm2836: Wire up CPU timer interrupts correctly

[Thomas Hanson]

On Mar 17, 2016 4:33 AM, "Peter Maydell"  wrote:
>
> Wire up the CPU timer interrupts in the right order, with the
> nonsecure physical timer on cntpnsirq, the hyp timer on cnthpirq,
> and the secure physical timer on cntpsirq. (We did get the
> virt timer right, at least.)
>
> Reported-by: Antonio Huete Jiménez 
> Signed-off-by: Peter Maydell 
> ---
>  hw/arm/bcm2836.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/hw/arm/bcm2836.c b/hw/arm/bcm2836.c
> index 89a6b35..1cefe41 100644
> --- a/hw/arm/bcm2836.c
> +++ b/hw/arm/bcm2836.c
> @@ -136,9 +136,13 @@ static void bcm2836_realize(DeviceState *dev, Error
**errp)
>
>  /* Connect timers from the CPU to the interrupt controller */
>  qdev_connect_gpio_out(DEVICE(>cpus[n]), GTIMER_PHYS,
> -qdev_get_gpio_in_named(DEVICE(>control), "cntpsirq",
n));
> +qdev_get_gpio_in_named(DEVICE(>control), "cntpnsirq",
n));
>  qdev_connect_gpio_out(DEVICE(>cpus[n]), GTIMER_VIRT,
>  qdev_get_gpio_in_named(DEVICE(>control), "cntvirq",
n));
> +qdev_connect_gpio_out(DEVICE(>cpus[n]), GTIMER_HYP,
> +qdev_get_gpio_in_named(DEVICE(>control), "cnthpirq",
n));
> +qdev_connect_gpio_out(DEVICE(>cpus[n]), GTIMER_SEC,
> +qdev_get_gpio_in_named(DEVICE(>control), "cntpsirq",
n));
>  }
>  }
>
> --
> 1.9.1
>
>

What drives the order?

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

[xiaoqiang zhao]

* Drop the old SysBus init function and use instance_init
* Move AUD_open_in / AUD_open_out function into realize stage

Signed-off-by: xiaoqiang zhao 
---
 hw/audio/milkymist-ac97.c | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/hw/audio/milkymist-ac97.c b/hw/audio/milkymist-ac97.c
index 6a3b536..5075c2b 100644
--- a/hw/audio/milkymist-ac97.c
+++ b/hw/audio/milkymist-ac97.c
@@ -284,16 +284,26 @@ static int ac97_post_load(void *opaque, int version_id)
 return 0;
 }
 
-static int milkymist_ac97_init(SysBusDevice *dev)
+static void milkymist_ac97_init(Object *obj)
 {
-MilkymistAC97State *s = MILKYMIST_AC97(dev);
+MilkymistAC97State *s = MILKYMIST_AC97(obj);
+SysBusDevice *dev = SYS_BUS_DEVICE(obj);
 
-struct audsettings as;
 sysbus_init_irq(dev, >crrequest_irq);
 sysbus_init_irq(dev, >crreply_irq);
 sysbus_init_irq(dev, >dmar_irq);
 sysbus_init_irq(dev, >dmaw_irq);
 
+memory_region_init_io(>regs_region, obj, _mmio_ops, s,
+"milkymist-ac97", R_MAX * 4);
+sysbus_init_mmio(dev, >regs_region);
+}
+
+static void milkymist_ac97_realize(DeviceState *dev, Error **errp)
+{
+MilkymistAC97State *s = MILKYMIST_AC97(dev);
+struct audsettings as;
+
 AUD_register_card("Milkymist AC'97", >card);
 
 as.freq = 48000;
@@ -305,12 +315,6 @@ static int milkymist_ac97_init(SysBusDevice *dev)
 "mm_ac97.in", s, ac97_in_cb, );
 s->voice_out = AUD_open_out(>card, s->voice_out,
 "mm_ac97.out", s, ac97_out_cb, );
-
-memory_region_init_io(>regs_region, OBJECT(s), _mmio_ops, s,
-"milkymist-ac97", R_MAX * 4);
-sysbus_init_mmio(dev, >regs_region);
-
-return 0;
 }
 
 static const VMStateDescription vmstate_milkymist_ac97 = {
@@ -327,9 +331,8 @@ static const VMStateDescription vmstate_milkymist_ac97 = {
 static void milkymist_ac97_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
-SysBusDeviceClass *k = SYS_BUS_DEVICE_CLASS(klass);
 
-k->init = milkymist_ac97_init;
+dc->realize = milkymist_ac97_realize;
 dc->reset = milkymist_ac97_reset;
 dc->vmsd = _milkymist_ac97;
 }
@@ -338,6 +341,7 @@ static const TypeInfo milkymist_ac97_info = {
 .name  = TYPE_MILKYMIST_AC97,
 .parent= TYPE_SYS_BUS_DEVICE,
 .instance_size = sizeof(MilkymistAC97State),
+.instance_init = milkymist_ac97_init,
 .class_init= milkymist_ac97_class_init,
 };
 
-- 
2.1.4

Re: [Qemu-devel] [PATCH v2 08/10] ppc: Add POWER8 IAMR register

[Cédric Le Goater]

On 03/16/2016 06:46 PM, Thomas Huth wrote:
> That should be now a "if (has_iamr)" instead of "if (!has_iamr)",
> shouldn't it?

yes  

I will send an update for this patch only. Sorry for the noise. 

C. 

[Qemu-devel] [RFC v2 5/6] hw/arm: boot

[Baptiste Reynal]

From: Christian Pinto 

This patch modifies the boot process of an ARM machine in otrder to check
whether if it is a slave, by checking the slave machine flag.

When the slave flag is on, no kernel, dtb or initrd are loaded into memory.
The boot address of each core is set to the start address of the RAM,
that depends on the machine model executed.

Signed-off-by: Christian Pinto 
---
 hw/arm/boot.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index bef451b..ee0c4a1 100644
--- a/hw/arm/boot.c
+++ b/hw/arm/boot.c
@@ -590,6 +590,19 @@ static void arm_load_kernel_notify(Notifier *notifier, 
void *data)
 /* Load the kernel.  */
 if (!info->kernel_filename || info->firmware_loaded) {
 
+if (!info->kernel_filename && machine_slave(current_machine)) {
+/* If a machine is booted as a slave instance there is no need to
+ * provide the DTB blob or kernel image, that will instead
+ * be copied into memory later by a master instance.
+ * The boot address is set to be at the beginning of the RAM.
+ */
+info->entry = info->loader_start;
+CPU_FOREACH(cs) {
+ARM_CPU(cs)->env.boot_info = info;
+}
+return;
+}
+
 if (have_dtb(info)) {
 /* If we have a device tree blob, but no kernel to supply it to (or
  * the kernel is supposed to be loaded by the bootloader), copy the
-- 
2.7.3

[Qemu-devel] [PATCH] quorum: add child name into filename

[Wen Congyang]

The monitor command 'query-block' or 'info block' will output the filename.
So we can get each children's child-name after this patch. This useful for
dynamic reconfiguration.

Signed-off-by: Wen Congyang 
---
 block/quorum.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/block/quorum.c b/block/quorum.c
index da15465..182766a 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -1036,9 +1036,13 @@ static void quorum_refresh_filename(BlockDriverState 
*bs, QDict *options)
 
 children = qlist_new();
 for (i = 0; i < s->num_children; i++) {
-QINCREF(s->children[i]->bs->full_open_options);
-qlist_append_obj(children,
- QOBJECT(s->children[i]->bs->full_open_options));
+QDict *child_opts;
+const char *child_name = s->children[i]->name;
+
+child_opts = 
qdict_clone_shallow(s->children[i]->bs->full_open_options);
+qdict_put_obj(child_opts, "child-name",
+  QOBJECT(qstring_from_str(child_name)));
+qlist_append_obj(children, QOBJECT(child_opts));
 }
 
 opts = qdict_new();
-- 
2.5.0

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

[tu bo]

On 03/16/2016 09:38 PM, Christian Borntraeger wrote:

On 03/16/2016 01:55 PM, Paolo Bonzini wrote:



On 16/03/2016 12:24, Christian Borntraeger wrote:

On 03/16/2016 12:09 PM, 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


If you just remove the calls to virtio_queue_host_notifier_read, here
and in virtio_queue_aio_set_host_notifier_fd_handler, does it work
(keeping patches 2-4 in)?


With these changes and patch 2-4 it does no longer locks up.
I keep it running some hour to check if a crash happens.

Tu Bo, your setup is currently better suited for reproducing. Can you also 
check?


remove the calls to virtio_queue_host_notifier_read, and keeping patches 
2-4 in,


I got same crash as before,
(gdb) bt
#0  bdrv_co_do_rw (opaque=0x0) at block/io.c:2172
#1  0x02aa0c65d786 in coroutine_trampoline (i0=, 
i1=-2013204784) at util/coroutine-ucontext.c:79

#2  0x03ff99ad150a in __makecontext_ret () from /lib64/libc.so.6






Paolo


#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

[Qemu-devel] [PULL 12/21] hw/timer: Add ASPEED timer device model

[Peter Maydell]

From: Andrew Jeffery 

Implement basic ASPEED timer functionality for the AST2400 SoC[1]: Up to
8 timers can independently be configured, enabled, reset and disabled.
Some hardware features are not implemented, namely clock value matching
and pulse generation, but the implementation is enough to boot the Linux
kernel configured with aspeed_defconfig.

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

Signed-off-by: Andrew Jeffery 
Message-id: 1458096317-25223-2-git-send-email-and...@aj.id.au
Reviewed-by: Peter Maydell 
Signed-off-by: Peter Maydell 
---
 default-configs/arm-softmmu.mak |   1 +
 hw/timer/Makefile.objs  |   1 +
 hw/timer/aspeed_timer.c | 449 
 include/hw/timer/aspeed_timer.h |  59 ++
 trace-events|   9 +
 5 files changed, 519 insertions(+)
 create mode 100644 hw/timer/aspeed_timer.c
 create mode 100644 include/hw/timer/aspeed_timer.h

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index a9f82a1..2bcd236 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -110,3 +110,4 @@ CONFIG_IOH3420=y
 CONFIG_I82801B11=y
 CONFIG_ACPI=y
 CONFIG_SMBIOS=y
+CONFIG_ASPEED_SOC=y
diff --git a/hw/timer/Makefile.objs b/hw/timer/Makefile.objs
index 5cfea6e..003c14f 100644
--- a/hw/timer/Makefile.objs
+++ b/hw/timer/Makefile.objs
@@ -32,3 +32,4 @@ obj-$(CONFIG_MC146818RTC) += mc146818rtc.o
 obj-$(CONFIG_ALLWINNER_A10_PIT) += allwinner-a10-pit.o
 
 common-obj-$(CONFIG_STM32F2XX_TIMER) += stm32f2xx_timer.o
+common-obj-$(CONFIG_ASPEED_SOC) += aspeed_timer.o
diff --git a/hw/timer/aspeed_timer.c b/hw/timer/aspeed_timer.c
new file mode 100644
index 000..51e8303
--- /dev/null
+++ b/hw/timer/aspeed_timer.c
@@ -0,0 +1,449 @@
+/*
+ * ASPEED AST2400 Timer
+ *
+ * Andrew Jeffery 
+ *
+ * Copyright (C) 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 "hw/ptimer.h"
+#include "hw/sysbus.h"
+#include "hw/timer/aspeed_timer.h"
+#include "qemu-common.h"
+#include "qemu/bitops.h"
+#include "qemu/main-loop.h"
+#include "qemu/timer.h"
+#include "trace.h"
+
+#define TIMER_NR_REGS 4
+
+#define TIMER_CTRL_BITS 4
+#define TIMER_CTRL_MASK ((1 << TIMER_CTRL_BITS) - 1)
+
+#define TIMER_CLOCK_USE_EXT true
+#define TIMER_CLOCK_EXT_HZ 100
+#define TIMER_CLOCK_USE_APB false
+#define TIMER_CLOCK_APB_HZ 2400
+
+#define TIMER_REG_STATUS 0
+#define TIMER_REG_RELOAD 1
+#define TIMER_REG_MATCH_FIRST 2
+#define TIMER_REG_MATCH_SECOND 3
+
+#define TIMER_FIRST_CAP_PULSE 4
+
+enum timer_ctrl_op {
+op_enable = 0,
+op_external_clock,
+op_overflow_interrupt,
+op_pulse_enable
+};
+
+/**
+ * Avoid mutual references between AspeedTimerCtrlState and AspeedTimer
+ * structs, as it's a waste of memory. The ptimer BH callback needs to know
+ * whether a specific AspeedTimer is enabled, but this information is held in
+ * AspeedTimerCtrlState. So, provide a helper to hoist ourselves from an
+ * arbitrary AspeedTimer to AspeedTimerCtrlState.
+ */
+static inline AspeedTimerCtrlState *timer_to_ctrl(AspeedTimer *t)
+{
+const AspeedTimer (*timers)[] = (void *)t - (t->id * sizeof(*t));
+return container_of(timers, AspeedTimerCtrlState, timers);
+}
+
+static inline bool timer_ctrl_status(AspeedTimer *t, enum timer_ctrl_op op)
+{
+return !!(timer_to_ctrl(t)->ctrl & BIT(t->id * TIMER_CTRL_BITS + op));
+}
+
+static inline bool timer_enabled(AspeedTimer *t)
+{
+return timer_ctrl_status(t, op_enable);
+}
+
+static inline bool timer_overflow_interrupt(AspeedTimer *t)
+{
+return timer_ctrl_status(t, op_overflow_interrupt);
+}
+
+static inline bool timer_can_pulse(AspeedTimer *t)
+{
+return t->id >= TIMER_FIRST_CAP_PULSE;
+}
+
+static void aspeed_timer_expire(void *opaque)
+{
+AspeedTimer *t = opaque;
+
+/* Only support interrupts on match values of zero for the moment - this is
+ * sufficient to boot an aspeed_defconfig Linux kernel.
+ *
+ * TODO: matching on arbitrary values (see e.g. hw/timer/a9gtimer.c)
+ */
+bool match = !(t->match[0] && t->match[1]);
+bool interrupt = timer_overflow_interrupt(t) || match;
+if (timer_enabled(t) && interrupt) {
+t->level = !t->level;
+qemu_set_irq(t->irq, t->level);
+}
+}
+
+static uint64_t aspeed_timer_get_value(AspeedTimer *t, int reg)
+{
+uint64_t value;
+
+switch (reg) {
+case TIMER_REG_STATUS:
+value = ptimer_get_count(t->timer);
+break;
+case TIMER_REG_RELOAD:
+value = t->reload;
+break;
+case TIMER_REG_MATCH_FIRST:
+case TIMER_REG_MATCH_SECOND:
+value = t->match[reg - 2];
+break;
+default:
+qemu_log_mask(LOG_UNIMP, "%s: Programming error: unexpected reg: %d\n",
+  

[Qemu-devel] [PATCH] arm: fix machine description

[Michael S. Tsirkin]

Fix what is clearly a copy-and-paste bug.

Fixes: c29196904b ("target-arm: Add virt class and machine types").
Cc: Greg Bellows 
Signed-off-by: Michael S. Tsirkin 
---
 hw/arm/virt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 8c6c996..9cf94e9 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1382,7 +1382,7 @@ static void virt_class_init(ObjectClass *oc, void *data)
 {
 MachineClass *mc = MACHINE_CLASS(oc);
 
-mc->desc = "ARM Virtual Machine",
+mc->desc = "ARM Virtual Machine";
 mc->init = machvirt_init;
 /* Start max_cpus at the maximum QEMU supports. We'll further restrict
  * it later in machvirt_init, where we have more information about the
-- 
MST

Re: [Qemu-devel] [PATCH 09/16] block: wait for all pending I/O when doing synchronous requests

[Stefan Hajnoczi]

On Tue, Feb 16, 2016 at 06:56:21PM +0100, Paolo Bonzini wrote:
> Synchronous I/O should in general happen either in the main thread (e.g.
> for bdrv_open and bdrv_create) or between bdrv_drained_begin and
> bdrv_drained_end.  Therefore, the simplest way to wait for it to finish
> is to wait for _all_ pending I/O to complete.

This seems okay although it opens the door to performance degradation
due to waiting for all requests instead of one specific request.  That
shouldn't be a problem since synchronous code paths are usually not
intended to have parallel I/O going on at the same time.


signature.asc
Description: PGP signature

[Qemu-devel] [PULL v1 02/13] crypto: add support for PBKDF2 algorithm

[Daniel P. Berrange]

The LUKS data format includes use of PBKDF2 (Password-Based
Key Derivation Function). The Nettle library can provide
an implementation of this, but we don't want code directly
depending on a specific crypto library backend. Introduce
a new include/crypto/pbkdf.h header which defines a QEMU
API for invoking PBKDK2. The initial implementations are
backed by nettle & gcrypt, which are commonly available
with distros shipping GNUTLS.

The test suite data is taken from the cryptsetup codebase
under the LGPLv2.1+ license. This merely aims to verify
that whatever backend we provide for this function in QEMU
will comply with the spec.

Reviewed-by: Fam Zheng 
Reviewed-by: Eric Blake 
Signed-off-by: Daniel P. Berrange 
---
 configure |  18 +++
 crypto/Makefile.objs  |   4 +
 crypto/pbkdf-gcrypt.c |  68 
 crypto/pbkdf-nettle.c |  65 
 crypto/pbkdf-stub.c   |  42 +
 crypto/pbkdf.c|  77 +
 include/crypto/pbkdf.h| 152 ++
 tests/.gitignore  |   1 +
 tests/Makefile|   2 +
 tests/test-crypto-pbkdf.c | 388 ++
 10 files changed, 817 insertions(+)
 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 include/crypto/pbkdf.h
 create mode 100644 tests/test-crypto-pbkdf.c

diff --git a/configure b/configure
index 71c1e2b..b88d0db 100755
--- a/configure
+++ b/configure
@@ -309,6 +309,7 @@ gnutls_hash=""
 gnutls_rnd=""
 nettle=""
 gcrypt=""
+gcrypt_kdf="no"
 vte=""
 virglrenderer=""
 tpm="yes"
@@ -2302,6 +2303,19 @@ if test "$gcrypt" != "no"; then
 if test -z "$nettle"; then
nettle="no"
 fi
+
+cat > $TMPC << EOF
+#include 
+int main(void) {
+  gcry_kdf_derive(NULL, 0, GCRY_KDF_PBKDF2,
+  GCRY_MD_SHA256,
+  NULL, 0, 0, 0, NULL);
+ return 0;
+}
+EOF
+if compile_prog "$gcrypt_cflags" "$gcrypt_libs" ; then
+gcrypt_kdf=yes
+fi
 else
 if test "$gcrypt" = "yes"; then
 feature_not_found "gcrypt" "Install gcrypt devel"
@@ -4726,6 +4740,7 @@ echo "GNUTLS support$gnutls"
 echo "GNUTLS hash   $gnutls_hash"
 echo "GNUTLS rnd$gnutls_rnd"
 echo "libgcrypt $gcrypt"
+echo "libgcrypt kdf $gcrypt_kdf"
 if test "$nettle" = "yes"; then
 echo "nettle$nettle ($nettle_version)"
 else
@@ -5108,6 +5123,9 @@ if test "$gnutls_rnd" = "yes" ; then
 fi
 if test "$gcrypt" = "yes" ; then
   echo "CONFIG_GCRYPT=y" >> $config_host_mak
+  if test "$gcrypt_kdf" = "yes" ; then
+echo "CONFIG_GCRYPT_KDF=y" >> $config_host_mak
+  fi
 fi
 if test "$nettle" = "yes" ; then
   echo "CONFIG_NETTLE=y" >> $config_host_mak
diff --git a/crypto/Makefile.objs b/crypto/Makefile.objs
index 967418c..7122cc8 100644
--- a/crypto/Makefile.objs
+++ b/crypto/Makefile.objs
@@ -10,8 +10,12 @@ crypto-obj-y += tlssession.o
 crypto-obj-y += secret.o
 crypto-obj-$(CONFIG_GCRYPT) += random-gcrypt.o
 crypto-obj-$(if $(CONFIG_GCRYPT),n,$(CONFIG_GNUTLS_RND)) += random-gnutls.o
+crypto-obj-y += pbkdf.o
+crypto-obj-$(CONFIG_NETTLE) += pbkdf-nettle.o
+crypto-obj-$(if $(CONFIG_NETTLE),n,$(CONFIG_GCRYPT_KDF)) += pbkdf-gcrypt.o
 
 # Let the userspace emulators avoid linking gnutls/etc
 crypto-aes-obj-y = aes.o
 
 stub-obj-y += random-stub.o
+stub-obj-y += pbkdf-stub.o
diff --git a/crypto/pbkdf-gcrypt.c b/crypto/pbkdf-gcrypt.c
new file mode 100644
index 000..885614d
--- /dev/null
+++ b/crypto/pbkdf-gcrypt.c
@@ -0,0 +1,68 @@
+/*
+ * QEMU Crypto PBKDF support (Password-Based Key Derivation Function)
+ *
+ * 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/pbkdf.h"
+#include "gcrypt.h"
+
+bool qcrypto_pbkdf2_supports(QCryptoHashAlgorithm hash)
+{
+switch (hash) {
+case QCRYPTO_HASH_ALG_MD5:
+case QCRYPTO_HASH_ALG_SHA1:
+case QCRYPTO_HASH_ALG_SHA256:
+return true;
+default:
+return false;
+}
+}
+
+int qcrypto_pbkdf2(QCryptoHashAlgorithm hash,
+   const uint8_t *key, size_t nkey,
+   const uint8_t *salt, size_t nsalt,
+  

[Qemu-devel] [PULL 11/40] ivshmem: Add missing newlines to debug printfs

[Markus Armbruster]

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

diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index 1838bc8..11cbc03 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -568,10 +568,10 @@ static void setup_interrupt(IVShmemState *s, int vector)
 IVSHMEM_DPRINTF("setting up interrupt for vector: %d\n", vector);
 
 if (!with_irqfd) {
-IVSHMEM_DPRINTF("with eventfd");
+IVSHMEM_DPRINTF("with eventfd\n");
 watch_vector_notifier(s, n, vector);
 } else if (msix_enabled(pdev)) {
-IVSHMEM_DPRINTF("with irqfd");
+IVSHMEM_DPRINTF("with irqfd\n");
 if (ivshmem_add_kvm_msi_virq(s, vector) < 0) {
 return;
 }
@@ -582,7 +582,7 @@ static void setup_interrupt(IVShmemState *s, int vector)
 }
 } else {
 /* it will be delayed until msix is enabled, in write_config */
-IVSHMEM_DPRINTF("with irqfd, delayed until msix enabled");
+IVSHMEM_DPRINTF("with irqfd, delayed until msix enabled\n");
 }
 }
 
-- 
2.4.3

[Qemu-devel] [PULL 35/40] ivshmem: Replace int role_val by OnOffAuto master

[Markus Armbruster]

In preparation of making it a qdev property.

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

diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index e6282ab..f903fae 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -43,9 +43,6 @@
 #define IVSHMEM_IOEVENTFD   0
 #define IVSHMEM_MSI 1
 
-#define IVSHMEM_PEER0
-#define IVSHMEM_MASTER  1
-
 #define IVSHMEM_REG_BAR_SIZE 0x100
 
 #define IVSHMEM_DEBUG 0
@@ -97,12 +94,12 @@ typedef struct IVShmemState {
 uint64_t msg_buf;   /* buffer for receiving server messages */
 int msg_buffered_bytes; /* #bytes in @msg_buf */
 
+OnOffAuto master;
 Error *migration_blocker;
 
 char * shmobj;
 char * sizearg;
 char * role;
-int role_val;   /* scalar to avoid multiple string comparisons */
 } IVShmemState;
 
 /* registers for the Inter-VM shared memory device */
@@ -118,6 +115,12 @@ static inline uint32_t ivshmem_has_feature(IVShmemState 
*ivs,
 return (ivs->features & (1 << feature));
 }
 
+static inline bool ivshmem_is_master(IVShmemState *s)
+{
+assert(s->master != ON_OFF_AUTO_AUTO);
+return s->master == ON_OFF_AUTO_ON;
+}
+
 static void ivshmem_update_irq(IVShmemState *s)
 {
 PCIDevice *d = PCI_DEVICE(s);
@@ -856,15 +859,15 @@ static void pci_ivshmem_realize(PCIDevice *dev, Error 
**errp)
 /* check that role is reasonable */
 if (s->role) {
 if (strncmp(s->role, "peer", 5) == 0) {
-s->role_val = IVSHMEM_PEER;
+s->master = ON_OFF_AUTO_OFF;
 } else if (strncmp(s->role, "master", 7) == 0) {
-s->role_val = IVSHMEM_MASTER;
+s->master = ON_OFF_AUTO_ON;
 } else {
 error_setg(errp, "'role' must be 'peer' or 'master'");
 return;
 }
 } else {
-s->role_val = IVSHMEM_MASTER; /* default */
+s->master = ON_OFF_AUTO_AUTO;
 }
 
 pci_conf = dev->config;
@@ -926,7 +929,11 @@ static void pci_ivshmem_realize(PCIDevice *dev, Error 
**errp)
 vmstate_register_ram(s->ivshmem_bar2, DEVICE(s));
 pci_register_bar(PCI_DEVICE(s), 2, attr, s->ivshmem_bar2);
 
-if (s->role_val == IVSHMEM_PEER) {
+if (s->master == ON_OFF_AUTO_AUTO) {
+s->master = s->vm_id == 0 ? ON_OFF_AUTO_ON : ON_OFF_AUTO_OFF;
+}
+
+if (!ivshmem_is_master(s)) {
 error_setg(>migration_blocker,
"Migration is disabled when using feature 'peer mode' in 
device 'ivshmem'");
 migrate_add_blocker(s->migration_blocker);
@@ -990,7 +997,7 @@ static int ivshmem_pre_load(void *opaque)
 {
 IVShmemState *s = opaque;
 
-if (s->role_val == IVSHMEM_PEER) {
+if (!ivshmem_is_master(s)) {
 error_report("'peer' devices are not migratable");
 return -EINVAL;
 }
@@ -1020,9 +1027,9 @@ static int ivshmem_load_old(QEMUFile *f, void *opaque, 
int version_id)
 return -EINVAL;
 }
 
-if (s->role_val == IVSHMEM_PEER) {
-error_report("'peer' devices are not migratable");
-return -EINVAL;
+ret = ivshmem_pre_load(s);
+if (ret) {
+return ret;
 }
 
 ret = pci_device_load(pdev, f);
-- 
2.4.3

[Qemu-devel] [PULL 26/40] ivshmem: Propagate errors through ivshmem_recv_setup()

[Markus Armbruster]

This kills off the funny state described in the previous commit.

Simplify ivshmem_io_read() accordingly, and update documentation.

Signed-off-by: Markus Armbruster 
Message-Id: <1458066895-20632-27-git-send-email-arm...@redhat.com>
Reviewed-by: Marc-André Lureau 
---
 docs/specs/ivshmem-spec.txt |  20 +++
 hw/misc/ivshmem.c   | 129 
 qemu-doc.texi   |   9 +---
 3 files changed, 95 insertions(+), 63 deletions(-)

diff --git a/docs/specs/ivshmem-spec.txt b/docs/specs/ivshmem-spec.txt
index 0cd63ad..4c33973 100644
--- a/docs/specs/ivshmem-spec.txt
+++ b/docs/specs/ivshmem-spec.txt
@@ -62,11 +62,11 @@ There are two ways to use this device:
   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.
+Before QEMU 2.6.0, BAR2 can initially be invalid if the device is
+configured for interrupts.  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.
@@ -82,7 +82,7 @@ BAR 0 contains the following registers:
 4 4   read/write0   Interrupt Status
 bit 0: peer interrupt
 bit 1..31: reserved
-8 4   read-only   0 or -1   IVPosition
+8 4   read-only   0 or ID   IVPosition
12 4   write-only  N/A   Doorbell
 bit 0..15: vector
 bit 16..31: peer ID
@@ -100,12 +100,14 @@ when an interrupt request from a peer is received.  
Reading the
 register clears it.
 
 IVPosition Register: if the device is not configured for interrupts,
-this is zero.  Else, it's -1 for a short while after reset, then
-changes to the device's ID (between 0 and 65535).
+this is zero.  Else, it is the device's ID (between 0 and 65535).
+
+Before QEMU 2.6.0, the register may read -1 for a short while after
+reset.
 
 There is no good way for software to find out whether the device is
 configured for interrupts.  A positive IVPosition means interrupts,
-but zero could be either.  The initial -1 cannot be reliably observed.
+but zero could be either.
 
 Doorbell Register: writing this register requests to interrupt a peer.
 The written value's high 16 bits are the ID of the peer to interrupt,
diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index ad16828..7f439c3 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -234,12 +234,7 @@ static uint64_t ivshmem_io_read(void *opaque, hwaddr addr,
 break;
 
 case IVPOSITION:
-/* return my VM ID if the memory is mapped */
-if (memory_region_is_mapped(>ivshmem)) {
-ret = s->vm_id;
-} else {
-ret = -1;
-}
+ret = s->vm_id;
 break;
 
 default:
@@ -511,7 +506,8 @@ static bool fifo_update_and_get_i64(IVShmemState *s,
 return false;
 }
 
-static int ivshmem_add_kvm_msi_virq(IVShmemState *s, int vector)
+static void ivshmem_add_kvm_msi_virq(IVShmemState *s, int vector,
+ Error **errp)
 {
 PCIDevice *pdev = PCI_DEVICE(s);
 MSIMessage msg = msix_get_message(pdev, vector);
@@ -522,22 +518,21 @@ static int ivshmem_add_kvm_msi_virq(IVShmemState *s, int 
vector)
 
 ret = kvm_irqchip_add_msi_route(kvm_state, msg, pdev);
 if (ret < 0) {
-error_report("ivshmem: kvm_irqchip_add_msi_route failed");
-return -1;
+error_setg(errp, "kvm_irqchip_add_msi_route failed");
+return;
 }
 
 s->msi_vectors[vector].virq = ret;
 s->msi_vectors[vector].pdev = pdev;
-
-return 0;
 }
 
-static void setup_interrupt(IVShmemState *s, int vector)
+static void setup_interrupt(IVShmemState *s, int vector, Error **errp)
 {
 EventNotifier *n = >peers[s->vm_id].eventfds[vector];
 bool with_irqfd = kvm_msi_via_irqfd_enabled() &&
 ivshmem_has_feature(s, IVSHMEM_MSI);
 PCIDevice *pdev = PCI_DEVICE(s);
+Error *err = NULL;
 
 IVSHMEM_DPRINTF("setting up interrupt for vector: %d\n", vector);
 
@@ -546,13 +541,16 @@ static void setup_interrupt(IVShmemState *s, int vector)
 watch_vector_notifier(s, n, vector);
 } else if (msix_enabled(pdev)) {
 IVSHMEM_DPRINTF("with irqfd\n");
-if (ivshmem_add_kvm_msi_virq(s, vector) < 0) {
+

[Qemu-devel] [PATCH v5 28/28] migration: remove qemu_get_fd method from QEMUFile

[Daniel P. Berrange]

Now that there is a set_blocking callback in QEMUFileOps,
and all users needing non-blocking support have been
converted to QIOChannel, there is no longer any codepath
requiring the qemu_get_fd() method for QEMUFile. Remove it
to avoid further code being introduced with an expectation
of direct file handle access.

Reviewed-by: Dr. David Alan Gilbert 
Signed-off-by: Daniel P. Berrange 
---
 include/migration/qemu-file.h |  1 -
 migration/qemu-file.c | 14 --
 2 files changed, 15 deletions(-)

diff --git a/include/migration/qemu-file.h b/include/migration/qemu-file.h
index 36af5f4..2409a98 100644
--- a/include/migration/qemu-file.h
+++ b/include/migration/qemu-file.h
@@ -103,7 +103,6 @@ typedef int (QEMUFileShutdownFunc)(void *opaque, bool rd, 
bool wr);
 typedef struct QEMUFileOps {
 QEMUFileGetBufferFunc *get_buffer;
 QEMUFileCloseFunc *close;
-QEMUFileGetFD *get_fd;
 QEMUFileSetBlocking *set_blocking;
 QEMUFileWritevBufferFunc *writev_buffer;
 QEMURetPathFunc *get_return_path;
diff --git a/migration/qemu-file.c b/migration/qemu-file.c
index 6790040..8aea1c7 100644
--- a/migration/qemu-file.c
+++ b/migration/qemu-file.c
@@ -268,14 +268,6 @@ static ssize_t qemu_fill_buffer(QEMUFile *f)
 return len;
 }
 
-int qemu_get_fd(QEMUFile *f)
-{
-if (f->ops->get_fd) {
-return f->ops->get_fd(f->opaque);
-}
-return -1;
-}
-
 void qemu_update_position(QEMUFile *f, size_t size)
 {
 f->pos += size;
@@ -688,11 +680,5 @@ void qemu_file_set_blocking(QEMUFile *f, bool block)
 {
 if (f->ops->set_blocking) {
 f->ops->set_blocking(f->opaque, block);
-} else {
-if (block) {
-qemu_set_block(qemu_get_fd(f));
-} else {
-qemu_set_nonblock(qemu_get_fd(f));
-}
 }
 }
-- 
2.5.0

[Qemu-devel] kvm ept fault BUG_ON()

[Stefanos Gerangelos]

Hi,

apologies if I am not posting to the appropriate list(s).

I am using QEMU-KVM and try to implement a simple character device which
offers mmap() functionality of host device memory to guest userspace.
For this purpose, I have written a dummy guest driver which communicates
with a qemu backend device.

Specifically, the guest driver allocates a page and passes the
associated address to qemu, which then translates it to host virtual
address (cpu_physical_memory_map()). It then calls mmap() with MAP_FIXED
and this host virtual address, which succeeds, and sends back the
response.

The problem arises here, when guest (either in kernespace or in
userspace via remap_pfn_range()) tries to access the relevant address
and faults with EPT. The path goes to handle_ept_violation() in kvm
module and eventually BUG_ON() is triggered at:

virt/kvm/kvm_main.c:1252 (version 3.16):

-- cut here --

pfn = ((addr - vma->vm_start) >> PAGE_SHIFT) +
vma->vm_pgoff;
BUG_ON(!kvm_is_mmio_pfn(pfn));

-- cut here --

addr == vma->vm_start and pfn is assigned the value of vma->vm_pgoff !!


What am I missing here? Is this scenario invalid? Can you please shed
some light?

Thanks in advance!


--Stefanos



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [RFC v2 4/6] hw/misc: sdm virtio device

[Baptiste Reynal]

This is the virtio implementation for an SDM device.

Parameters are:
comm=[sdm_communication_id] specifies the communication channel
master=[true/false] - configure the SDM device as master or slave
num_slaves=[slave_number] - if master is true, specifies the number
of slaves
len-signals=[signals_number] - specifies the number of signals
signals[x]=[signal_id] - add a signal to the device, with the ID x

Signed-off-by: Christian Pinto 
Signed-off-by: Baptiste Reynal 
---
 hw/virtio/Makefile.objs  |   1 +
 hw/virtio/virtio-sdm.c   | 262 +++
 include/hw/virtio/virtio-sdm.h   |  60 +
 linux-headers/linux/virtio_sdm.h |  52 
 4 files changed, 375 insertions(+)
 create mode 100644 hw/virtio/virtio-sdm.c
 create mode 100644 include/hw/virtio/virtio-sdm.h
 create mode 100644 linux-headers/linux/virtio_sdm.h

diff --git a/hw/virtio/Makefile.objs b/hw/virtio/Makefile.objs
index 19b224a..7e44bc4 100644
--- a/hw/virtio/Makefile.objs
+++ b/hw/virtio/Makefile.objs
@@ -2,6 +2,7 @@ common-obj-y += virtio-rng.o
 common-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
 common-obj-y += virtio-bus.o
 common-obj-y += virtio-mmio.o
+obj-$(CONFIG_SDM) += virtio-sdm.o
 obj-$(CONFIG_VIRTIO) += dataplane/
 
 obj-y += virtio.o virtio-balloon.o 
diff --git a/hw/virtio/virtio-sdm.c b/hw/virtio/virtio-sdm.c
new file mode 100644
index 000..66986c7
--- /dev/null
+++ b/hw/virtio/virtio-sdm.c
@@ -0,0 +1,262 @@
+/*
+ * Copyright (C) 2016 - Virtual Open Systems
+ * Authors: Christian Pinto 
+ *  Baptiste Reynal 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+#include "qemu/iov.h"
+#include "qemu/error-report.h"
+#include "hw/virtio/virtio.h"
+#include "hw/virtio/virtio-sdm.h"
+
+typedef void (*cmd_handler)(VirtIOSdm *sdm, union sdm_cmd_params);
+/**
+ * Command handler for signal type commands.
+ * Invoked when the command is received from the guest
+ */
+static void handler_signal(VirtIOSdm *sdm, union sdm_cmd_params params)
+{
+SDMSignalData signal;
+DEBUG_PRINT("handler_signal: SIGNAL %d, SLAVE_ID %d\n", params.sig.type,
+params.sig.slave_id);
+
+signal.type = params.sig.type;
+signal.slave = params.sig.slave_id;
+memcpy(, , 2 * sizeof(uint32_t));
+
+sdm_communication_signal(sdm->sdmc, SDM_DEVICE(sdm),  );
+}
+
+static cmd_handler sdm_cmd_handlers[] = {
+[SDM_SIGNAL_CMD]= handler_signal,
+};
+
+/**
+ * Send a command to the guest virtio-driver
+ */
+static void send_cmd_to_guest(VirtIOSdm *sdm,
+struct sdm_cmd cmd)
+{
+VirtQueueElement elem;
+VirtIODevice *vdev = VIRTIO_DEVICE(sdm);
+
+if (!virtqueue_pop(sdm->hg_vq, )) {
+return;
+}
+
+if (iov_from_buf(elem.in_sg, elem.in_num, 0, , sizeof(cmd))) {
+virtqueue_push(sdm->hg_vq, , sizeof(cmd));
+virtio_notify(vdev, sdm->hg_vq);
+DEBUG_PRINT("Sending command %d of type %d\n",
+cmd.cmd, cmd.params.sig.type);
+} else {
+error_report("virtio-idm - Failed to issue command id 0x%x\n", 
cmd.cmd);
+}
+}
+
+/**
+ * guest -> host virtqueue handler.
+ * Calls the handler assoociated to the command received over the virtqueue
+ */
+static void handle_guest_host_queue(VirtIODevice *vdev, VirtQueue *vq)
+{
+VirtQueueElement elem;
+struct sdm_cmd cmd;
+
+if (!virtqueue_pop(vq, )) {
+return;
+}
+
+if (!iov_to_buf(elem.out_sg, elem.out_num, 0, , sizeof(cmd))) {
+return;
+}
+
+DEBUG_PRINT("Command received 0x%x\n", cmd.cmd);
+
+if (cmd.cmd >= ARRAY_SIZE(sdm_cmd_handlers) ||
+!sdm_cmd_handlers[cmd.params.sig.type]) {
+error_report("virtio-idm - unrecognized command %x\n", cmd.cmd);
+return;
+}
+
+sdm_cmd_handlers[cmd.params.sig.type](VIRTIO_SDM(vdev), cmd.params);
+}
+
+/**
+ * Guest sends commands over this virtqueue only to add an empty
+ * buffer to be later used by the host.
+ */
+static void handle_host_guest_queue(VirtIODevice *vdev, VirtQueue *vq)
+{
+VirtIOSdm *sdm = VIRTIO_SDM(vdev);
+
+sdm->busy = false;
+}
+
+static uint64_t get_features(VirtIODevice *vdev, uint64_t requested_features,
+Error **errp)
+{
+return requested_features;
+}
+
+static void virtio_sdm_device_realize(DeviceState *dev, Error **errp)
+{
+VirtIODevice *vdev = VIRTIO_DEVICE(dev);
+VirtIOSdm *sdm = VIRTIO_SDM(dev);
+int i;
+
+virtio_init(vdev, "virtio-sdm", 

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

[Jaya Tiwari]

On Fri, Mar 18, 2016 at 6:57 PM, Jaya Tiwari 
wrote:

>
>
> On Fri, Mar 18, 2016 at 5:21 PM, Paolo Bonzini 
> wrote:
>
>>
>>
>> On 18/03/2016 12:24, Pooja Dhannawat wrote:
>> >
>> >
>> > On Fri, Mar 18, 2016 at 4:20 AM, Paolo Bonzini > > > wrote:
>> >
>> >
>> >
>> > On 17/03/2016 16:31, Pooja Dhannawat wrote:
>> > >
>> > >
>> > > On Thu, Mar 17, 2016 at 8:20 PM, Stefan Hajnoczi <
>> stefa...@gmail.com 
>> > > >> wrote:
>> > >
>> > > On Tue, Mar 15, 2016 at 09:29:58PM +0530, Pooja Dhannawat
>> wrote:
>> > > > @@ -170,8 +170,8 @@ static void net_socket_send(void
>> *opaque)
>> > > >  s->index = 0;
>> > > >  s->packet_len = 0;
>> > > >  s->nc.link_down = true;
>> > > > -memset(s->buf, 0, sizeof(s->buf));
>> > >
>> > > This change is unrelated to allocating buf1 on the heap.
>> What is the
>> > > purpose of this line?
>> > >
>> > >
>> > > I moved buf from stack to Heap, used g_new(), but I got your
>> point if we
>> > > need to initialize it with 0 then I have to keep that one.
>> > >
>> > > Other wise doing so it gets whatever garbage it has already.
>> >
>> > This is s->buf, not buf.  Also, the BiteSizedTasks page says "Make
>> the
>> > stack array smaller and allocate on the heap in the rare case that
>> the
>> > data does not fit in the small array".
>> >
>> > So here, should I check with stack consumption(size of array) and if it
>> > is greater than accepted level, then only keep on heap?
>>
>> If it is greater than the accepted level, the on-stack buffer is not
>> used and you allocate one that has the right size on the heap.
>>
> Yes Okay. Thank you for the comments.
> I had one more question.
> size = qemu_recv(s->fd, buf1, sizeof(buf1), 0);
> The one above returns bytes read into buf1 (if large then bytes equivalent
> to len(buf1) is read) ?
> If true, size is the correct measure of buf1? Hence, I should compare the
> allowed stack size to "size" variable?
>
   So isnt here size should be compared to "size" varibale paolo?

>
>> Paolo
>>
>> > If no, Can you please help me with this one?
>> >
>> > Paolo
>> >
>> >
>>
>>
>
>
> --
> Regards,
> Jaya
>



-- 
Regards,
Jaya

[Qemu-devel] [Patch v2 1/1] blizzard: Remove support for DEPTH != 32

[Pooja Dhannawat]

On Friday, March 18, 2016, Gerd Hoffmann  wrote:
>
> On Mo, 2016-03-14 at 15:22 +, Peter Maydell wrote:
> > On 14 March 2016 at 15:04, Pooja Dhannawat 
wrote:
> > > Removing support for DEPTH != 32 from blizzard template header
> > > and file that includes it, as macro DEPTH == 32 only used.
> > >
> > > Signed-off-by: Pooja Dhannawat 
> > > ---
> > >  hw/display/blizzard.c  | 24 
> > >  hw/display/blizzard_template.h | 30 +-
> > >  2 files changed, 1 insertion(+), 53 deletions(-)
>
> > So are there any cases now when
> > surface_bits_per_pixel(qemu_console_surface(c)) can return
> > zero? (I don't understand the 'case 0' code in this switch
> > at all...)
>
> Looks like a somewhat strange way to zero-fill the function pointer
> array.  Looks like a historical leftover.
>
> As blizzard uses qemu_console_resize() you will always get a surface
> with the default depth (32bpp).  So dropping the whole "switch { ... }"
> block (except for the "case 32:" lines) and adding an
> "assert(surface_bits_per_pixel(surface)==32)" should work just fine.
>
Thank you Gerd, for clearing and helping with  above question.

>
> cheers,
>   Gerd
>

[Qemu-devel] [PATCH v1 1/2] crypto: add compat cast5_set_key with nettle < 3.0.0

[Daniel P. Berrange]

Prior to the nettle 3.0.0 release, the cast5_set_key function
was actually named cast128_set_key, so we must add a compatibility
definition.

Signed-off-by: Daniel P. Berrange 
---
 crypto/cipher-nettle.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/crypto/cipher-nettle.c b/crypto/cipher-nettle.c
index 3c982e4..bec4f1c 100644
--- a/crypto/cipher-nettle.c
+++ b/crypto/cipher-nettle.c
@@ -34,6 +34,8 @@ typedef nettle_crypt_func nettle_cipher_func;
 
 typedef void *   cipher_ctx_t;
 typedef unsigned cipher_length_t;
+
+#define cast5_set_key cast128_set_key
 #else
 typedef const void * cipher_ctx_t;
 typedef size_t   cipher_length_t;
-- 
2.5.0

[Qemu-devel] [Bug 1546445] Re: support vhost user without specifying vhostforce

[Corey Bryant]

** Changed in: qemu (Ubuntu Vivid)
   Status: In Progress => Invalid

** Changed in: qemu (Ubuntu Vivid)
 Assignee: Liang Chen (cbjchen) => (unassigned)

** No longer affects: qemu (Ubuntu Vivid)

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

Title:
  support vhost user without specifying vhostforce

Status in Ubuntu Cloud Archive:
  In Progress
Status in Ubuntu Cloud Archive kilo series:
  In Progress
Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Wily:
  Fix Released

Bug description:
  [Impact]

   * vhost-user falls back to virtio-net which causes performance lose
  without specifying the vhostforce option. But it should be the default
  behavior for vhost-user, since guests using PMD doesn't support msi-x.

  [Test Case]

create a vhost-user virtio backend without specifying the vhostforce 
option, i.e. -netdev 
type=vhost-user,id=mynet1,chardev=
start the VM
vhost-user is not enabled

  [Regression Potential]

   * none

  vhost user nic doesn't support non msi guests(like pxe stage) by default.
  Vhost user nic can't fall back to qemu like normal vhost net nic does. So we 
should
  enable it for non msi guests.

  The problem has been fix in qemu upstream  -
  
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=24f938a682d934b133863eb421aac33592f7a09e.
  And the patch needs to be backported to 1:2.2+dfsg-5expubuntu9.8 .

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1546445/+subscriptions

Re: [Qemu-devel] [RFC v1 09/11] tcg: drop global lock during TCG code execution

[Paolo Bonzini]

On 18/03/2016 17:18, Alex Bennée wrote:
> From: KONRAD Frederic 
> 
> This finally allows TCG to benefit from the iothread introduction: Drop
> the global mutex while running pure TCG CPU code. Reacquire the lock
> when entering MMIO or PIO emulation, or when leaving the TCG loop.
> 
> We have to revert a few optimization for the current TCG threading
> model, namely kicking the TCG thread in qemu_mutex_lock_iothread and not
> kicking it in qemu_cpu_kick. We also need to disable RAM block
> reordering until we have a more efficient locking mechanism at hand.
> 
> Still, a Linux x86 UP guest and my Musicpal ARM model boot fine here.
> These numbers demonstrate where we gain something:
> 
> 20338 jan   20   0  331m  75m 6904 R   99  0.9   0:50.95 qemu-system-arm
> 20337 jan   20   0  331m  75m 6904 S   20  0.9   0:26.50 qemu-system-arm
> 
> The guest CPU was fully loaded, but the iothread could still run mostly
> independent on a second core. Without the patch we don't get beyond
> 
> 32206 jan   20   0  330m  73m 7036 R   82  0.9   1:06.00 qemu-system-arm
> 32204 jan   20   0  330m  73m 7036 S   21  0.9   0:17.03 qemu-system-arm
> 
> We don't benefit significantly, though, when the guest is not fully
> loading a host CPU.
> 
> Message-Id: <1439220437-23957-10-git-send-email-fred.kon...@greensocs.com>
> Signed-off-by: KONRAD Frederic 
> [AJB: -smp single-threaded fix, rm old info from commit msg]
> Signed-off-by: Alex Bennée 

You should probably squash this and patch 10 together.

Paolo

[Qemu-devel] [PATCH for-2.6 14/14] s390-ccw.img: rebuild image

[Cornelia Huck]

Contains the following changes:

pc-bios/s390-ccw: add more disk layout checks
pc-bios/s390-ccw: virtio_panic -> panic
pc-bios/s390-ccw: add utility functions and "export" some others
pc-bios/s390-ccw: qemuize types
pc-bios/s390-ccw: update virtio implementation to allow up to 3 vrings
pc-bios/s390-ccw: add vdev object to store all device details
pc-bios/s390-ccw: make provisions for different backends
pc-bios/s390-ccw: add simplified virtio call
pc-bios/s390-ccw: add scsi definitions
pc-bios/s390-ccw: add virtio-scsi implementation
pc-bios/s390-ccw: enable virtio-scsi
pc-bios/s390-ccw: enhance bootmap detection
pc-bios/s390-ccw: disambiguation of "No zIPL magic" message

Signed-off-by: Cornelia Huck 
---
 pc-bios/s390-ccw.img | Bin 17760 -> 26424 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/pc-bios/s390-ccw.img b/pc-bios/s390-ccw.img
index 
bd8f21050fd7c396eb0e37213d284fe557caa01e..d3978ba0506cb24050f596b2e4e710dec3486fba
 100644
GIT binary patch
literal 26424
zcmeHwdw5jkwfCA!k|7CUCxkEw2s<%qK#UVWjHq=c7Yr9+LxK)%Pf17uNe#)E3>2-^
zsMMmTwIK!Ttu<9)Q>=EN){YqPJ)rg{aT9J0N(7>cut?^
zJAXRQGxNUteb>A0YrVHkxVdu40;khK@sEpgP`4VA?y=haX1Qjclzu9uapb2g%EWUr

[Qemu-devel] [PATCH for-2.6 13/14] pc-bios/s390-ccw: disambiguation of "No zIPL magic" message

[Cornelia Huck]

From: "Eugene (jno) Dvurechenski" 

Don't indicate the same error message for different conditions.

Signed-off-by: Eugene (jno) Dvurechenski 
Signed-off-by: Cornelia Huck 
---
 pc-bios/s390-ccw/bootmap.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/pc-bios/s390-ccw/bootmap.c b/pc-bios/s390-ccw/bootmap.c
index 54e0f17..611102e 100644
--- a/pc-bios/s390-ccw/bootmap.c
+++ b/pc-bios/s390-ccw/bootmap.c
@@ -84,7 +84,7 @@ static const int max_bprs_entries = sizeof(_bprs) / 
sizeof(ExtEckdBlockPtr);
 
 static inline void verify_boot_info(BootInfo *bip)
 {
-IPL_assert(magic_match(bip->magic, ZIPL_MAGIC), "No zIPL magic");
+IPL_assert(magic_match(bip->magic, ZIPL_MAGIC), "No zIPL sig in BootInfo");
 IPL_assert(bip->version == BOOT_INFO_VERSION, "Wrong zIPL version");
 IPL_assert(bip->bp_type == BOOT_INFO_BP_TYPE_IPL, "DASD is not for IPL");
 IPL_assert(bip->dev_type == BOOT_INFO_DEV_TYPE_ECKD, "DASD is not ECKD");
@@ -416,7 +416,7 @@ static void zipl_run(ScsiBlockPtr *pte)
 read_block(pte->blockno, tmp_sec, "Cannot read header");
 header = (ComponentHeader *)tmp_sec;
 
-IPL_assert(magic_match(tmp_sec, ZIPL_MAGIC), "No zIPL magic");
+IPL_assert(magic_match(tmp_sec, ZIPL_MAGIC), "No zIPL magic in header");
 IPL_assert(header->type == ZIPL_COMP_HEADER_IPL, "Bad header type");
 
 dputs("start loading images\n");
@@ -465,7 +465,7 @@ static void ipl_scsi(void)
 read_block(mbr->blockptr.blockno, sec,
"Error reading Program Table");
 
-IPL_assert(magic_match(sec, ZIPL_MAGIC), "No zIPL magic");
+IPL_assert(magic_match(sec, ZIPL_MAGIC), "No zIPL magic in PT");
 
 ns_end = sec + virtio_get_block_size();
 for (ns = (sec + pte_len); (ns + pte_len) < ns_end; ns += pte_len) {
-- 
2.7.4

[Qemu-devel] [PULL 01/40] target-ppc: Document TOCTTOU in hugepage support

[Markus Armbruster]

The code to find the minimum page size is is vulnerable to TOCTTOU.
Added in commit 2d103aa "target-ppc: fix hugepage support when using
memory-backend-file" (v2.4.0).  Since I can't fix it myself right now,
add a FIXME comment.

Cc: Paolo Bonzini 
Cc: Michael Roth 
Signed-off-by: Markus Armbruster 
Message-Id: <1458066895-20632-2-git-send-email-arm...@redhat.com>
Reviewed-by: Marc-André Lureau 
---
 target-ppc/kvm.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 776336b..2fc9931 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -333,6 +333,12 @@ static long gethugepagesize(const char *mem_path)
 return fs.f_bsize;
 }
 
+/*
+ * FIXME TOCTTOU: this iterates over memory backends' mem-path, which
+ * may or may not name the same files / on the same filesystem now as
+ * when we actually open and map them.  Iterate over the file
+ * descriptors instead, and use qemu_fd_getpagesize().
+ */
 static int find_max_supported_pagesize(Object *obj, void *opaque)
 {
 char *mem_path;
-- 
2.4.3

Re: [Qemu-devel] [PATCH v2 10/12] spice/gl: create dummy primary surface (RfC)

[Marc-André Lureau]

Hi

On Fri, Mar 18, 2016 at 2:17 PM, Gerd Hoffmann  wrote:
> Ping Marc?  Any comment on this?


Could you send a rebased series, for the patches that lead to the
issue? I assume "render DisplaySurface via opengl" patch?

-- 
Marc-André Lureau

Re: [Qemu-devel] [PATCH v2 10/12] spice/gl: create dummy primary surface (RfC)

[Gerd Hoffmann]

On Fr, 2016-02-19 at 10:14 +0100, Gerd Hoffmann wrote:
> Current spice client expects we create a primary surface,
> even if we do display updates using dma-bufs exclusively.
> 
> So just do that to get things going.
> 
> Not fully clear whenever that is intentional or a bug on
> the spice side, so I keep this as separate patch for now.
> 
> I think this should either be squashed into the previous
> patch, or dropped after fixing things on the spice side.

Ping Marc?  Any comment on this?

thanks,
  Gerd