Re: [Qemu-devel] [PATCH] block: Make op blockers recursive

[Fam Zheng]

On Fri, 08/22 18:11, Benoît Canet wrote:
 Since the block layer code is starting to modify the BDS graph right in the
 middle of BDS chains (block-mirror's replace parameter for example) QEMU needs
 to properly block and unblock whole BDS subtrees; recursion is a neat way to
 achieve this task.
 
 This patch also takes care of modifying the op blockers users.

Is this going to replace backing_blocker?

I think it is too general an approach to control the operation properly,
because the op blocker may not work in the same way for all types of BDS
connections.  In other words, the choosing of op blockers are likely
conditional on graph edge types, that's why backing_blocker was added here. For
example, A VMDK extent connection will probably need a different set of
blockers than bs-file connection.

So could you explain in which cases is the recursive blocking/unblocking
useful?

Fam

 
 Signed-off-by: Benoit Canet benoit.ca...@nodalink.com
 ---
  block.c   | 69 
 ---
  block/blkverify.c | 21 +++
  block/commit.c|  3 +++
  block/mirror.c| 17 
  block/quorum.c| 25 +
  block/stream.c|  3 +++
  block/vmdk.c  | 34 +++
  include/block/block.h |  2 +-
  include/block/block_int.h |  6 +
  9 files changed, 171 insertions(+), 9 deletions(-)
 
 diff --git a/block.c b/block.c
 index 6fa0201..d964b6c 100644
 --- a/block.c
 +++ b/block.c
 @@ -5446,7 +5446,9 @@ bool bdrv_op_is_blocked(BlockDriverState *bs, 
 BlockOpType op, Error **errp)
  return false;
  }
  
 -void bdrv_op_block(BlockDriverState *bs, BlockOpType op, Error *reason)
 +/* do the real work of blocking a BDS */
 +static void bdrv_do_op_block(BlockDriverState *bs, BlockOpType op,
 + Error *reason)
  {
  BdrvOpBlocker *blocker;
  assert((int) op = 0  op  BLOCK_OP_TYPE_MAX);
 @@ -5456,7 +5458,9 @@ void bdrv_op_block(BlockDriverState *bs, BlockOpType 
 op, Error *reason)
  QLIST_INSERT_HEAD(bs-op_blockers[op], blocker, list);
  }
  
 -void bdrv_op_unblock(BlockDriverState *bs, BlockOpType op, Error *reason)
 +/* do the real work of unblocking a BDS */
 +static void bdrv_do_op_unblock(BlockDriverState *bs, BlockOpType op,
 +   Error *reason)
  {
  BdrvOpBlocker *blocker, *next;
  assert((int) op = 0  op  BLOCK_OP_TYPE_MAX);
 @@ -5468,6 +5472,65 @@ void bdrv_op_unblock(BlockDriverState *bs, BlockOpType 
 op, Error *reason)
  }
  }
  
 +static bool bdrv_op_is_blocked_by(BlockDriverState *bs, BlockOpType op,
 +  Error *reason)
 +{
 +BdrvOpBlocker *blocker, *next;
 +assert((int) op = 0  op  BLOCK_OP_TYPE_MAX);
 +QLIST_FOREACH_SAFE(blocker, bs-op_blockers[op], list, next) {
 +if (blocker-reason == reason) {
 +return true;
 +}
 +}
 +return false;
 +}
 +
 +/* block recursively a BDS */
 +void bdrv_op_block(BlockDriverState *bs, BlockOpType op, Error *reason)
 +{
 +if (!bs) {
 +return;
 +}
 +
 +/* prevent recursion loop */
 +if (bdrv_op_is_blocked_by(bs, op, reason)) {
 +return;
 +}
 +
 +/* block first for recursion loop protection to work */
 +bdrv_do_op_block(bs, op, reason);
 +
 +bdrv_op_block(bs-file, op, reason);
 +bdrv_op_block(bs-backing_hd, op, reason);
 +
 +if (bs-drv  bs-drv-bdrv_op_recursive_block) {
 +bs-drv-bdrv_op_recursive_block(bs, op, reason);
 +}
 +}
 +
 +/* unblock recursively a BDS */
 +void bdrv_op_unblock(BlockDriverState *bs, BlockOpType op, Error *reason)
 +{
 +if (!bs) {
 +return;
 +}
 +
 +/* prevent recursion loop */
 +if (!bdrv_op_is_blocked_by(bs, op, reason)) {
 +return;
 +}
 +
 +/* unblock first for recursion loop protection to work */
 +bdrv_do_op_unblock(bs, op, reason);
 +
 +bdrv_op_unblock(bs-file, op, reason);
 +bdrv_op_unblock(bs-backing_hd, op, reason);
 +
 +if (bs-drv  bs-drv-bdrv_op_recursive_unblock) {
 +bs-drv-bdrv_op_recursive_unblock(bs, op, reason);
 +}
 +}
 +
  void bdrv_op_block_all(BlockDriverState *bs, Error *reason)
  {
  int i;
 @@ -5848,7 +5911,7 @@ BlockDriverState *check_to_replace_node(const char 
 *node_name, Error **errp)
  return NULL;
  }
  
 -if (bdrv_op_is_blocked(to_replace_bs, BLOCK_OP_TYPE_REPLACE, errp)) {
 +if (bdrv_op_is_blocked(to_replace_bs, BLOCK_OP_TYPE_MIRROR_REPLACE, 
 errp)) {
  return NULL;
  }
  
 diff --git a/block/blkverify.c b/block/blkverify.c
 index 621b785..75ec3df 100644
 --- a/block/blkverify.c
 +++ b/block/blkverify.c
 @@ -320,6 +320,24 @@ static void 
 blkverify_attach_aio_context(BlockDriverState *bs,
  bdrv_attach_aio_context(s-test_file, new_context);
  }
  
 +static void blkverify_op_recursive_block(BlockDriverState *bs, BlockOpType 
 op,
 +  

Re: [Qemu-devel] [PATCH v2 4/4] ioh3420: Enable ARI forwarding

[Gonglei (Arei)]

 From: Michael S. Tsirkin [mailto:m...@redhat.com]
 Subject: Re: [PATCH v2 4/4] ioh3420: Enable ARI forwarding
 
 On Sun, Aug 24, 2014 at 03:32:20PM +0200, Knut Omang wrote:
  Signed-off-by: Knut Omang knut.om...@oracle.com
 
 BTW pcie_cap_is_arifwd_enabled is still unused.

Not yet, but I have posted a patch series:

[PATCH v2 0/2] add check for PCIe root ports and downstream ports

Which we used this function to check ARI Forwarding is enabled or not.
I hope you can help me review it, thanks a lot!

BTW, I will rebase my patches on Kunt's patch series. And will do some fixes 
about Hu Tao's and Marcel Apfelbaum's comments.

 We really should use it to make ARI work properly, right?
 
Yes. I think we should.

Best regards,
-Gonglei

  ---
   hw/pci-bridge/ioh3420.c | 2 ++
   1 file changed, 2 insertions(+)
 
  diff --git a/hw/pci-bridge/ioh3420.c b/hw/pci-bridge/ioh3420.c
  index e6674a1..cce2fdd 100644
  --- a/hw/pci-bridge/ioh3420.c
  +++ b/hw/pci-bridge/ioh3420.c
  @@ -85,6 +85,7 @@ static void ioh3420_reset(DeviceState *qdev)
   pcie_cap_root_reset(d);
   pcie_cap_deverr_reset(d);
   pcie_cap_slot_reset(d);
  +pcie_cap_arifwd_reset(d);
   pcie_aer_root_reset(d);
   pci_bridge_reset(qdev);
   pci_bridge_disable_base_limit(d);
  @@ -119,6 +120,7 @@ static int ioh3420_initfn(PCIDevice *d)
   goto err_msi;
   }
 
  +pcie_cap_arifwd_init(d);
   pcie_cap_deverr_init(d);
   pcie_cap_slot_init(d, s-slot);
   pcie_chassis_create(s-chassis);
  --
  1.9.0

Re: [Qemu-devel] [PATCH v2 2/3] qdev: add cleanup logic in device_set_realized() to avoid resource leak

[Gonglei (Arei)]

Ping, please.

Any comments? Thanks.

Best regards,
-Gonglei


 -Original Message-
 From: Gonglei (Arei)
 Sent: Thursday, August 21, 2014 10:11 AM
 To: qemu-devel@nongnu.org
 Cc: m...@redhat.com; Huangweidong (C); pbonz...@redhat.com;
 afaer...@suse.de; imamm...@redhat.com; peter.crosthwa...@xilinx.com;
 Huangpeng (Peter); Luonengjun; Gonglei (Arei)
 Subject: [PATCH v2 2/3] qdev: add cleanup logic in device_set_realized() to
 avoid resource leak
 
 From: Gonglei arei.gong...@huawei.com
 
 At present, this function doesn't have partial cleanup implemented,
 which will cause resource leak in some scenarios.
 
 Example:
 
 1. Assuming that dc-realize(dev, local_err) execute successful
and local_err == NULL;
 2. Executing device hotplug in hotplug_handler_plug(), but failed
   (It is prone to occur). Then local_err != NULL;
 3. error_propagate(errp, local_err) and return. But the resources
  which been allocated in dc-realize() will be leaked.
  Simple backtrace:
   dc-realize()
|-device_realize
 |-pci_qdev_init()
 |-do_pci_register_device()
 |-etc.
 
 Adding fuller cleanup logic which assure that function can
 goto appropriate error label as local_err population is
 detected as each relevant point.
 
 Signed-off-by: Gonglei arei.gong...@huawei.com
 ---
  hw/core/qdev.c | 58
 ++
  1 file changed, 38 insertions(+), 20 deletions(-)
 
 diff --git a/hw/core/qdev.c b/hw/core/qdev.c
 index 4a1ac5b..c1a36f0 100644
 --- a/hw/core/qdev.c
 +++ b/hw/core/qdev.c
 @@ -834,12 +834,14 @@ static void device_set_realized(Object *obj, bool
 value, Error **errp)
  dc-realize(dev, local_err);
  }
 
 -if (dev-parent_bus  dev-parent_bus-hotplug_handler 
 -local_err == NULL) {
 +if (local_err != NULL) {
 +goto fail;
 +}
 +
 +if (dev-parent_bus  dev-parent_bus-hotplug_handler) {
  hotplug_handler_plug(dev-parent_bus-hotplug_handler,
   dev, local_err);
 -} else if (local_err == NULL 
 -   object_dynamic_cast(qdev_get_machine(),
 TYPE_MACHINE)) {
 +} else if (object_dynamic_cast(qdev_get_machine(),
 TYPE_MACHINE)) {
  HotplugHandler *hotplug_ctrl;
  MachineState *machine = MACHINE(qdev_get_machine());
  MachineClass *mc = MACHINE_GET_CLASS(machine);
 @@ -852,21 +854,25 @@ static void device_set_realized(Object *obj, bool
 value, Error **errp)
  }
  }
 
 -if (qdev_get_vmsd(dev)  local_err == NULL) {
 +if (local_err != NULL) {
 +goto post_realize_fail;
 +}
 +
 +if (qdev_get_vmsd(dev)) {
  vmstate_register_with_alias_id(dev, -1, qdev_get_vmsd(dev),
 dev,
 dev-instance_id_alias,
 
 dev-alias_required_for_version);
  }
 -if (local_err == NULL) {
 -QLIST_FOREACH(bus, dev-child_bus, sibling) {
 -object_property_set_bool(OBJECT(bus), true, realized,
 - local_err);
 -if (local_err != NULL) {
 -break;
 -}
 +
 +QLIST_FOREACH(bus, dev-child_bus, sibling) {
 +object_property_set_bool(OBJECT(bus), true, realized,
 + local_err);
 +if (local_err != NULL) {
 +goto set_bool_fail;
  }
  }
 -if (dev-hotplugged  local_err == NULL) {
 +
 +if (dev-hotplugged) {
  device_reset(dev);
  }
  dev-pending_deleted_event = false;
 @@ -875,24 +881,36 @@ static void device_set_realized(Object *obj, bool
 value, Error **errp)
  object_property_set_bool(OBJECT(bus), false, realized,
   local_err);
  if (local_err != NULL) {
 -break;
 +goto fail;
  }
  }
 -if (qdev_get_vmsd(dev)  local_err == NULL) {
 +if (qdev_get_vmsd(dev)) {
  vmstate_unregister(dev, qdev_get_vmsd(dev), dev);
  }
 -if (dc-unrealize  local_err == NULL) {
 +if (dc-unrealize) {
  dc-unrealize(dev, local_err);
  }
  dev-pending_deleted_event = true;
 -}
 
 -if (local_err != NULL) {
 -error_propagate(errp, local_err);
 -return;
 +if (local_err != NULL) {
 +goto fail;
 +}
  }
 
  dev-realized = value;
 +return;
 +
 +set_bool_fail:
 +if (qdev_get_vmsd(dev)) {
 +vmstate_unregister(dev, qdev_get_vmsd(dev), dev);
 +}
 +post_realize_fail:
 +if (dc-unrealize) {
 +dc-unrealize(dev, NULL);
 +}
 +fail:
 +error_propagate(errp, local_err);
 +return;
  }
 
  static bool device_get_hotpluggable(Object *obj, Error **errp)
 --
 

Re: [Qemu-devel] [PATCH v2 00/14] GPIO/IRQ QOMification: Phase 2 - Getting rid of SYSBUS IRQs

[Peter Crosthwaite]

Ping!

Andreas, are you able to take this?

Regards,
Peter

On Thu, Aug 21, 2014 at 7:23 PM, Alexander Graf ag...@suse.de wrote:


 On 15.08.14 07:29, Peter Crosthwaite wrote:
 Hi All,

 So phase one was the QOMification of qemu_irq. This is the next step.
 We start to setup GPIOs as proper QOM objects. Inputs are child objects
 of their device. Outputs are settable Links and connection is made
 via proper setting of a QOM link.

 We then cleanup Sysbus to simply re-use device level GPIOs and get rid
 of it's special IRQ handling code.

 Depends of my pending QOM array property stuff (the [*] series):

 https://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg04116.html

 Changed since v1:
 Addressed Alex review
 Dropped IRQ g_new0 changes

 Reviewed-by: Alexander Graf ag...@suse.de


 Alex

Re: [Qemu-devel] [question] e1000 interrupt storm happened becauseof its corresponding ioapic-irr bit always set

[Zhang Haoyu]

 Hi, all

 I use a qemu-1.4.1/qemu-2.0.0 to run win7 guest, and encounter e1000 NIC 
 interrupt storm, 
 because if (!ent-fields.mask  (ioapic-irr  (1  i))) is always true 
 in __kvm_ioapic_update_eoi().

 Any ideas?

We meet this several times: search the autoneg patches for an example of
workaround for this in qemu, and patch kvm: ioapic: conditionally delay
irq delivery during eoi broadcast for an workaround in kvm (rejected).

Thanks, Jason,
I searched e1000 autoneg in gmane.comp.emulators.qemu, and found below 
patches, 
http://thread.gmane.org/gmane.comp.emulators.qemu/143001/focus=143007
http://thread.gmane.org/gmane.comp.emulators.qemu/284105/focus=284765
http://thread.gmane.org/gmane.comp.emulators.qemu/186159/focus=187351
which one tries to fix this problem, or all of them?

That was probably caused by something wrong in e1000 emulation which
causes interrupt to be injected into windows guest before its interrupt
handler is registered. And Windows guest does not have a mechanism to
detect and disable irq in such condition.

Sorry, I don't understand,
I think one interrupt should not been enabled before its handler is 
successfully registered, 
is it possible that e1000 emulation inject the interrupt before the interrupt 
is succesfully enabled?

Thanks,
Zhang Haoyu
 
e1000 emulation is far from stable and complete (e.g run e1000 ethtool
selftest in linux guest may see lots of errors). It's complicate and
subtle (even has undocumented registers and behaviour). You should
better consider to use virtio which are more stable and fast in a kvm
guest (unless some intel guys are involved to improve e1000 emulation).

Thanks

 Thanks,
 Zhang Haoyu

Re: [Qemu-devel] [question] e1000 interrupt storm happened becauseof its corresponding ioapic-irr bit always set

[Jason Wang]

On 08/25/2014 03:17 PM, Zhang Haoyu wrote:
 Hi, all

 I use a qemu-1.4.1/qemu-2.0.0 to run win7 guest, and encounter e1000 NIC 
 interrupt storm, 
 because if (!ent-fields.mask  (ioapic-irr  (1  i))) is always true 
 in __kvm_ioapic_update_eoi().

 Any ideas?
 We meet this several times: search the autoneg patches for an example of
 workaround for this in qemu, and patch kvm: ioapic: conditionally delay
 irq delivery during eoi broadcast for an workaround in kvm (rejected).

 Thanks, Jason,
 I searched e1000 autoneg in gmane.comp.emulators.qemu, and found below 
 patches, 
 http://thread.gmane.org/gmane.comp.emulators.qemu/143001/focus=143007

This series is the first try to fix the guest hang during guest
hibernation or driver enable/disable.
 http://thread.gmane.org/gmane.comp.emulators.qemu/284105/focus=284765
 http://thread.gmane.org/gmane.comp.emulators.qemu/186159/focus=187351

Those are follow-up that tries to fix the bugs introduced by the autoneg
hack.
 which one tries to fix this problem, or all of them?

As you can see, those kinds of hacking may not as good as we expect
since we don't know exactly how e1000 works. Only the register function
description from Intel's manual may not be sufficient. And you can
search e1000 in the archives and you can find some behaviour of e1000
registers were not fictionalized like what spec said. It was really
suggested to use virtio-net instead of e1000 in guest. 

 That was probably caused by something wrong in e1000 emulation which
 causes interrupt to be injected into windows guest before its interrupt
 handler is registered. And Windows guest does not have a mechanism to
 detect and disable irq in such condition.

 Sorry, I don't understand,
 I think one interrupt should not been enabled before its handler is 
 successfully registered, 
 is it possible that e1000 emulation inject the interrupt before the interrupt 
 is succesfully enabled?

 Thanks,
 Zhang Haoyu
  
 e1000 emulation is far from stable and complete (e.g run e1000 ethtool
 selftest in linux guest may see lots of errors). It's complicate and
 subtle (even has undocumented registers and behaviour). You should
 better consider to use virtio which are more stable and fast in a kvm
 guest (unless some intel guys are involved to improve e1000 emulation).

 Thanks
 Thanks,
 Zhang Haoyu


 --
 To unsubscribe from this list: send the line unsubscribe kvm in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] [bisected] VNC server can't get all sent chars correctly

[Markus Armbruster]

Michael Tokarev m...@tls.msk.ru writes:

 There's a bug filed against debian qemu package, there:

  http://bugs.debian.org/758881

 which says about problems sending keypress events over VNC to
 a qemu guest, -- some keypresses gets lost, at least.

 The bisection between qemu 2.0 and 2.1 leads to this commit:

 commit 2858ab09e6f708e381fc1a1cc87e747a690c4884
 Author: Gonglei arei.gong...@huawei.com
 Date:   Thu Apr 24 20:06:19 2014 +0800

 ps2: set ps/2 output buffer size as the same as kernel

 According to the PS/2 Mouse/Keyboard Protocol, the keyboard outupt buffer 
 size
 is 16 bytes. And the PS2_QUEUE_SIZE 256 was introduced in Qemu from the 
 very
 beginning.

 When I started a  redhat5.6 32bit guest, meanwhile tapped the keyboard as 
 quickly as
 possible, the screen would show me i8042.c: No controller found. As a 
 result,
 I couldn't use the keyboard in the VNC client.

 Previous discussion about the issue in maillist:
 http://thread.gmane.org/gmane.comp.emulators.qemu/43294/focus=47180

 This patch has been tested on redhat5.6 32-bit/suse11sp3 64-bit guests.
 More easy meathod to reproduce:
 1.boot a guest with libvirt.
 2.connect to VNC client.
 3.as you see the BIOS, bootloader, Linux booting, run the follow simply 
 shell script:
 for((i=0;i1000;i++)) do virsh send-key redhat5.6 KEY_A; done

 Actual results:
 dmesg show i8042.c: No controller found. And the keyboard is out of 
 work.

 Signed-off-by: Gonglei arei.gong...@huawei.com
 Reviewed-by: Juan Quintela quint...@redhat.com
 Signed-off-by: Gerd Hoffmann kra...@redhat.com


 So it looks like something else is not right here.  Before this patch,
 it wasn't possible to use keyboard with VNC client with redhat 5 guest.
 Now, it isn't possible to use keyboard with VNC in another scenario which
 worked before (so it is a regression compared with 2.0 version).

 What do we do with this? :)

Suggest to add a tracepoint to the place that drops keystrokes due to
buffer being full, to verify that's really what happens.  Quick glance
at the code suggests ps2_queue().

Re: [Qemu-devel] [question] e1000 interrupt storm happened becauseof its corresponding ioapic-irr bit always set

[Jason Wang]

On 08/25/2014 03:17 PM, Zhang Haoyu wrote:
 Hi, all
 
  I use a qemu-1.4.1/qemu-2.0.0 to run win7 guest, and encounter e1000 NIC 
  interrupt storm, 
  because if (!ent-fields.mask  (ioapic-irr  (1  i))) is always 
  true in __kvm_ioapic_update_eoi().
 
  Any ideas?
 
 We meet this several times: search the autoneg patches for an example of
 workaround for this in qemu, and patch kvm: ioapic: conditionally delay
 irq delivery during eoi broadcast for an workaround in kvm (rejected).
 
 Thanks, Jason,
 I searched e1000 autoneg in gmane.comp.emulators.qemu, and found below 
 patches, 
 http://thread.gmane.org/gmane.comp.emulators.qemu/143001/focus=143007
 http://thread.gmane.org/gmane.comp.emulators.qemu/284105/focus=284765
 http://thread.gmane.org/gmane.comp.emulators.qemu/186159/focus=187351
 which one tries to fix this problem, or all of them?

 That was probably caused by something wrong in e1000 emulation which
 causes interrupt to be injected into windows guest before its interrupt
 handler is registered. And Windows guest does not have a mechanism to
 detect and disable irq in such condition.
 
 Sorry, I don't understand,
 I think one interrupt should not been enabled before its handler is 
 successfully registered, 
 is it possible that e1000 emulation inject the interrupt before the interrupt 
 is succesfully enabled?

There's no way for qemu to know whether or not the irq handler was
registered in guest. So if qemu behaves differently with a physical
card, it may lead the interrupt to be injected into guest too early. You
can search redhat bugzilla for lots of related bugs, some even with
in-depth analysis.

Thanks

 Thanks,
 Zhang Haoyu
  

Re: [Qemu-devel] [bisected] VNC server can't get all sent chars correctly

[Gonglei (Arei)]

 From: Markus Armbruster [mailto:arm...@redhat.com]
 Sent: Monday, August 25, 2014 3:30 PM
 To: Michael Tokarev
 Cc: qemu-devel; Gonglei (Arei); Gabriele Giacone; Gerd Hoffmann;
 758...@bugs.debian.org
 Subject: Re: [Qemu-devel] [bisected] VNC server can't get all sent chars
 correctly
 
 Michael Tokarev m...@tls.msk.ru writes:
 
  There's a bug filed against debian qemu package, there:
 
   http://bugs.debian.org/758881
 
  which says about problems sending keypress events over VNC to
  a qemu guest, -- some keypresses gets lost, at least.
 
  The bisection between qemu 2.0 and 2.1 leads to this commit:
 
  commit 2858ab09e6f708e381fc1a1cc87e747a690c4884
  Author: Gonglei arei.gong...@huawei.com
  Date:   Thu Apr 24 20:06:19 2014 +0800
 
  ps2: set ps/2 output buffer size as the same as kernel
 
  According to the PS/2 Mouse/Keyboard Protocol, the keyboard outupt
 buffer size
  is 16 bytes. And the PS2_QUEUE_SIZE 256 was introduced in Qemu from
 the very
  beginning.
 
  When I started a  redhat5.6 32bit guest, meanwhile tapped the
 keyboard as quickly as
  possible, the screen would show me i8042.c: No controller found. As a
 result,
  I couldn't use the keyboard in the VNC client.
 
  Previous discussion about the issue in maillist:
 
 http://thread.gmane.org/gmane.comp.emulators.qemu/43294/focus=47180
 
  This patch has been tested on redhat5.6 32-bit/suse11sp3 64-bit
 guests.
  More easy meathod to reproduce:
  1.boot a guest with libvirt.
  2.connect to VNC client.
  3.as you see the BIOS, bootloader, Linux booting, run the follow simply
 shell script:
  for((i=0;i1000;i++)) do virsh send-key redhat5.6 KEY_A; done
 
  Actual results:
  dmesg show i8042.c: No controller found. And the keyboard is out of
 work.
 
  Signed-off-by: Gonglei arei.gong...@huawei.com
  Reviewed-by: Juan Quintela quint...@redhat.com
  Signed-off-by: Gerd Hoffmann kra...@redhat.com
 
 
  So it looks like something else is not right here.  Before this patch,
  it wasn't possible to use keyboard with VNC client with redhat 5 guest.
  Now, it isn't possible to use keyboard with VNC in another scenario which
  worked before (so it is a regression compared with 2.0 version).
 
  What do we do with this? :)
 
 Suggest to add a tracepoint to the place that drops keystrokes due to
 buffer being full, to verify that's really what happens.  Quick glance
 at the code suggests ps2_queue().

+1  :)

Best regards,
-Gonglei

Re: [Qemu-devel] [Qemu-trivial] [PATCH] libdecnumber: Fix warnings from smatch (missing static, boolean operations)

[Markus Armbruster]

Stefan Weil s...@weilnetz.de writes:

 Am 24.08.2014 11:21, schrieb Michael Tokarev:
 Applied to -trivial, thank you!

 But I've a small concern - should we really do this on external sources,
 and divirge from upstream needlessly?

 Thanks,

 /mjt

 In general, I agree. In this case, the code was part of gcc, and newer
 versions of gcc use GPL 3 which is incompatible with QEMU, so I assume
 that the code in QEMU is no longer available from a maintained
 upstream.

Upstream switched to another license != upstream is no longer
maintained.

If you license your contribution under GPLv2+, both upstream and
downstream should be able to use it just fine.

Have you checked the current upstream code for presence of these issues?

Re: [Qemu-devel] [PATCH] vmxnet3: Pad short frames to minimum size (60 bytes)

[Markus Armbruster]

Dmitry Fleytman dmi...@daynix.com writes:

 On Aug 24, 2014, at 16:10 PM, Michael Tokarev m...@tls.msk.ru wrote:

 24.08.2014 16:28, Dmitry Fleytman wrote:
 
 Hi Michael,
 
 I’m the maintainer of vmxnet3/pvscsi devices in QEMU. Thanks for CC’ing me.
 
 Maybe you can add yourself to MAINTAINERS file as well? :)

 Yes, this should be done.
 How we do this? Should I send a patch for MAINTAINETRS?

Yes.

Re: [Qemu-devel] [PATCH v2 3/4] ioh3420: Remove obsoleted, unused ioh3420_init function

[Gonglei (Arei)]

 -Original Message-
 From: Knut Omang [mailto:knut.om...@oracle.com]
 Sent: Sunday, August 24, 2014 9:32 PM
 To: qemu-devel@nongnu.org
 Cc: Michael S. Tsirkin; Alexey Kardashevskiy; Juan Quintela; Marcel Apfelbaum;
 Markus Armbruster; Paolo Bonzini; Gonglei (Arei); Igor Mammedov; Knut
 Omang
 Subject: [PATCH v2 3/4] ioh3420: Remove obsoleted, unused ioh3420_init
 function
 
 Signed-off-by: Knut Omang knut.om...@oracle.com
 ---
  hw/pci-bridge/ioh3420.c | 24 
  1 file changed, 24 deletions(-)
 
 diff --git a/hw/pci-bridge/ioh3420.c b/hw/pci-bridge/ioh3420.c
 index aed2bf1..e6674a1 100644
 --- a/hw/pci-bridge/ioh3420.c
 +++ b/hw/pci-bridge/ioh3420.c
 @@ -157,30 +157,6 @@ static void ioh3420_exitfn(PCIDevice *d)
  pci_bridge_exitfn(d);
  }
 
 -PCIESlot *ioh3420_init(PCIBus *bus, int devfn, bool multifunction,
 - const char *bus_name, pci_map_irq_fn
 map_irq,
 - uint8_t port, uint8_t chassis, uint16_t slot)
 -{
 -PCIDevice *d;
 -PCIBridge *br;
 -DeviceState *qdev;
 -
 -d = pci_create_multifunction(bus, devfn, multifunction, ioh3420);
 -if (!d) {
 -return NULL;
 -}
 -br = PCI_BRIDGE(d);
 -
 -qdev = DEVICE(d);
 -pci_bridge_map_irq(br, bus_name, map_irq);
 -qdev_prop_set_uint8(qdev, port, port);
 -qdev_prop_set_uint8(qdev, chassis, chassis);
 -qdev_prop_set_uint16(qdev, slot, slot);
 -qdev_init_nofail(qdev);
 -
 -return PCIE_SLOT(d);
 -}
 -
  static Property ioh3420_props[] = {
  DEFINE_PROP_BIT(COMPAT_PROP_PCP, PCIDevice, cap_present,
  QEMU_PCIE_SLTCAP_PCP_BITNR, true),
 --
 1.9.0

That's OK. But the declaration of header file should also be removed.
I noticed MST have pulled into master tree. So, maybe I can post
another patch to fix this trivial problem.

Best regards,
-Gonglei

[Qemu-devel] reporting 9pfs init errors

[Michael Tokarev]

Hello.

I've a bugreport against debian qemu package which basically
states that 9pfs does not work.  After some digging it turned
out to be error reporting problem, plain and simple.  The
error message is:

qemu-system-x86_64: -device 
virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=pwk,bus=pci.0,addr=0x7: 
Virtio-9p Failed to initialize fs-driver with id:fsdev-fs0 and export 
path:/home/stevie/Documents/PWK
qemu-system-x86_64: -device 
virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=pwk,bus=pci.0,addr=0x7: Device 
initialization failed.
qemu-system-x86_64: -device 
virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=pwk,bus=pci.0,addr=0x7: Device 
'virtio-9p-pci' could not be initialized

and the actual problem is that the path is not accessible from
libvirt-spawned qemu due to permission denied (EPERM) error
returned from statfs() call.

The same happens when you mistype the pathname, or some other
problem, -- in all cases it might be very difficult to find the
actual cause, sort of strace'ing qemu process when it is at
all possible.

In this case, the prob is in hw/9pfs/virtio-9p-local.c:local_init(),
the failing syscall is statfs().  But the thing is -- this init()
method does not have Error argument to push error message, while
upper layer, hw/9pfs/virtio-9p-device.c:virtio_9p_device_realize(),
uses Error objects.

In hw/9pfs/virtio-9p-proxy.c:proxy_init() (which implements the
same init() method), there's a fprintf(stderr) which is used to
report error (not even error_report()!).  (And by the way, there,
if socket init fails, there's no error reporting or checking at
all).

Should we revisit error checking and reporting for 9pfs somehow,
so it is easier for the users?

Thanks,

/mjt

[Qemu-devel] [PATCH] ioh3420: Remove unused ioh3420_init() declaration

[arei.gonglei]

From: Gonglei arei.gong...@huawei.com

Signed-off-by: Gonglei arei.gong...@huawei.com
---
 hw/pci-bridge/ioh3420.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/hw/pci-bridge/ioh3420.h b/hw/pci-bridge/ioh3420.h
index 7776e5b..ea423cb 100644
--- a/hw/pci-bridge/ioh3420.h
+++ b/hw/pci-bridge/ioh3420.h
@@ -3,8 +3,4 @@
 
 #include hw/pci/pcie_port.h
 
-PCIESlot *ioh3420_init(PCIBus *bus, int devfn, bool multifunction,
-   const char *bus_name, pci_map_irq_fn map_irq,
-   uint8_t port, uint8_t chassis, uint16_t slot);
-
 #endif /* QEMU_IOH3420_H */
-- 
1.7.12.4

Re: [Qemu-devel] [PATCH v3] trace: [qmp] Add QAPI/QMP commands to query and control event tracing state

[Markus Armbruster]

Lluís Vilanova vilan...@ac.upc.edu writes:

 Eric Blake writes:

 On 08/21/2014 11:52 AM, Lluís Vilanova wrote:
 Also removes old trace-event, trace-file and info trace-events HMP
 commands.
 
 Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu
 ---
 monitor.c   |   24 +++-
 qapi-schema.json|3 ++
 qapi/trace.json |   44 +
 qmp-commands.hx |   27 ++
 trace/Makefile.objs |1 +
 trace/control.c |   13 -
 trace/control.h |7 -
 trace/qmp.c | 77
 +++
 8 files changed, 162 insertions(+), 34 deletions(-)
 create mode 100644 qapi/trace.json
 create mode 100644 trace/qmp.c
 

 +++ b/qapi/trace.json
 @@ -0,0 +1,44 @@
 +# -*- mode: python -*-
 +

 No copyright statement (but you are just following (poor) existing
 practice).

 Will add.


 +##
 +# @TraceEventState:
 +#
 +# State of a tracing event.
 +#
 +# @name: Event name.
 +# @sstatic: Static tracing state.
 +# @sdynamic: Dynamic tracing state.

 Does the leading 's' add any value?  QAPI doesn't have to use obscure
 abbreviations.

 It felt wrong to have a JSON attribute named differently from the C struct
 (static is a reserved word).


 +#
 +# Since 2.2
 +##
 +{ 'type': 'TraceEventState',
 +  'data': {'name': 'str', 'sstatic': 'bool', 'sdynamic': 'bool'} }

 Are all four states between the combinations of the two bools possible,
 or is this more of a tri-state setting (default, sstatic, or sdynamic),
 in which case a single parameter of enum type would be better than two
 bools?

 I can certainly change it to an state enum:

 * unavailable: statically disabled
 * disabled   : statically enabled, dynamically disabled
 * enabled: statically enabled, dynamically enabled

Yes, please; it's neater.

 +
 +##
 +# @trace-event-get-state:
 +#
 +# Query the state of events.
 +#
 +# @name: Event name pattern.

 glob? regex? Is the pattern anchored or just substring analysis?
 Case-sensitive?

 It's the same pattern matching used internally in QEMU (case-sensitive
 globbing).

Please document it.

 +#
 +# Returns: @TraceEventState of the matched events
 +#
 +# Since 2.2
 +##
 +{ 'command': 'trace-event-get-state',
 +  'data': {'name': 'str'},
 +  'returns': ['TraceEventState'] }

 What if I want ALL events?  Can name be made optional to avoid any
 filtering?

 I use * as the name, which seems simple enough to me.

Good enough for me, too.

 +
 +##
 +# @trace-event-set-state:
 +#
 +# Set the dynamic state of events.
 +#
 +# @name: Event name pattern.

 Same comments about pattern as before.

 +# @state: Dynamic tracing state.
 +# @keepgoing: #optional Apply changes even if not all events can be 
 changed.

 keep-going - use dash to separate words for legibility

 Ok.


 +#
 +# Since 2.2
 +##
 +{ 'command': 'trace-event-set-state',
 +  'data': {'name': 'str', 'state': 'bool', '*keepgoing': 'bool'} }

 This only lets me set the state of one name at a time.  Oh, unless I'm
 setting a pattern, and it then sets the state of all names that match
 that pattern.  I'm wondering if you should have 'name':['str'] to allow
 me to set multiple names/patterns in one go, instead of having to call
 the command multiple times; but it's probably not worth the complexity.

 I agree with the complexity comment. Also, the keepgoing is useful to set 
 events
 using a pattern, even if some of them are statically disabled (otherwise it
 gives an error).

Yes, let's keep this simple.

However, I feel keepgoing is unnecessarily vague.  Its purpose is to
enable use of a pattern in the presence of disabled events.  I'd prefer
to nail it down to exactly that purpose rather than having it cover
arbitrary, unspecified errors.

A few ideas on how to do that:

* Have a flag to modify the semantics of the pattern: either match all
  events, or match just disabled and enabled events, not unavailable
  events.

* To find out what a trace-event-set-state actually does, you need to
  trace-event-get-state the same pattern.  We could make
  trace-event-set-state return the events it changed, so you never have
  to trace-event-get-state, but it's probably not worthwhile.

[...]

Re: [Qemu-devel] [PATCH 1/4] hd-geometry.c: Integrate HDIO_GETGEO in guessing for target-s390x

[Christian Borntraeger]

On 20/08/14 15:10, Paolo Bonzini wrote:
 Il 20/08/2014 11:35, Christian Borntraeger ha scritto:
 On 20/08/14 10:19, Paolo Bonzini wrote:
 Il 29/07/2014 14:27, Ekaterina Tumanova ha scritto:
 The new HDIO_GETGEO logic is required for two use cases:
 a) Support for geometries of Direct Attached Storage Disks (DASD)
 on s390x configured as backing of virtio block devices.

 Is this still relevant now that QEMU can emulate 512-byte sectors on top
 of host devices with 4k sectors?

 Yes, the geometry and the block size define the layout of the DASD disk 
 format. This defines how the ibm disk layout partition table looks like. So 
 partition detection of the IBM layout only works if values are correct. (see 
 linux block/partitions/ibm.c. it needs these values to correctly locate the 
 data structures).

 Furthermore, if you do an mkfs in the host and the guest sees a different 
 block size all kind of strange things will happen when mounting, no?


 b) Support for FCP attached SCSI disks that do not yet have a
 partition table. Without this patch, fdisk -l on the host would
 return different results then fdisk -l in the guest.

 Can you provide an example?

 scsi disk in the host:
 [root@host ~]#  sfdisk -g 
 /dev/disk/by-id/wwn-0x6005076305ffc1ae2593
 /dev/disk/by-id/wwn-0x6005076305ffc1ae2593: 1011 cylinders, 34 
 heads, 61 sectors/track

 same scsi disk in the guest as virtio-blk:
 scsi disk in the guest:
 [root@guest ~]# sfdisk -g /dev/disk/by-id/virtio-d20
 /dev/disk/by-id/virtio-d20: 2080 cylinders, 16 heads, 63 sectors/track

 16/63 is currently hardcoded by QEMU, no matter what the host thinks. This 
 gets overridden as soon as there is a partition table.

 command line was:
 -drive 
 file=/dev/disk/by-id/scsi-36005076305ffc1ae2593,if=none,id=drive-virtio-disk20,format=raw,serial=d20,cache=none,aio=native
 
 But this risks changing whenever you move data from a disk to another
 disk, or if you move a virtual DASD disk from physical DASD to physical
 SCSI.
 
 If s390 is so sensitive to the head count and number of sectors/track
 (on x86 everything is done with LBAs nowadays, even in the firmware), I
 think whatever management layer you use should always specify them
 explicitly.

Only the DASD disks are so sensitive. The SCSI geometry is just a cosmetic 
thing, but it doesnt hurt. So for anything that comes via FCP SCSI we dont have 
a series issue besides the cosmetic thing. (Well, unless you have a storage 
server with 4k scsi disks, then it also becomes an issue on x86 - already seen 
on Flash Systems and other storage servers).
 
 I'm not saying this patch shouldn't be included---but it should be
 treated as a handy thing for developers rather than as a definitive fix.

Yes. I would even suggest, that for image files you better use a SCSI disk 
image (which then has the normal partition layout as x86). 
Of course, there are reasons to have image files to hold DASD images, but then 
you have to manually specify geo/ss. In fact, libvirt always supported to 
specify the geometry and Viktor from our team did the sector size support in 
libvirt with:

commit 5cc50ad7a4e139261079a5848859c84cab3b0c7c
Author: Viktor Mihajlovski mihaj...@linux.vnet.ibm.com
AuthorDate: Wed Aug 29 17:48:30 2012 +0200
Commit: Eric Blake ebl...@redhat.com
CommitDate: Fri Aug 31 11:27:27 2012 -0700

conf: Support for Block Device IO Limits

Introducing a new iolimits element allowing to override certain
properties of a guest block device like the physical and logical
block size.
This can be useful for platforms with 'non-standard' disk formats
like S390 DASD with its 4K block size.

Signed-off-by: Viktor Mihajlovski mihaj...@linux.vnet.ibm.com


commit 277a49bce73da908c965e466b03f5fc97f04cae1
Author: Viktor Mihajlovski mihaj...@linux.vnet.ibm.com
AuthorDate: Wed Aug 29 17:48:31 2012 +0200
Commit: Eric Blake ebl...@redhat.com
CommitDate: Fri Aug 31 11:27:47 2012 -0700

qemu: Support for Block Device IO Limits.

Implementation of iolimits for the qemu driver with
capability probing for block size attribute and
command line generation for block sizes.
Including testcase for qemuxml2argvtest.

Signed-off-by: Viktor Mihajlovski mihaj...@linux.vnet.ibm.com

some time ago.

So this detection is mostly important for DASD disk passthrough as the defaults 
are plainly wrong for those disks. (Under LPAR and z/VM the disks work out of 
the box, so a proper detection really helps).
As far as I can see the patches only affect disks, that are raw or 
host_device. So it would be good, if Kevin and Stefan could take a look at 
the overall design. If they/you come up with a totally different approach, that 
is also fine.
Kate was away last week, so hopefully she can continue to drive the discussion 
with you folks, when she is back.

Christian

Re: [Qemu-devel] [PATCH] acpi-build: Set FORCE_APIC_CLUSTER_MODEL bit of FADT flags

[zhanghailiang]

Hi,

Ping...

Are there any news about this patch?

Thanks,
zhanghailiang

If we start Windows 2008 R2 DataCenter with number of cpu less than 8,
The system will use APIC Flat Logical destination mode as default configuration,
Which has an upper limit of 8 CPUs.

The fault is that VM can not show all processors within Task Manager if
we hot-add cpus when the number of cpus in VM extends the limit of 8.

If we use cluster destination model, the problem will be solved.

Signed-off-by: huangzhichaohuangzhic...@huawei.com
Signed-off-by: zhanghailiangzhang.zhanghaili...@huawei.com
---
  hw/i386/acpi-build.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 10b84d0..fed4501 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -545,7 +545,8 @@ static void fadt_setup(AcpiFadtDescriptorRev1 *fadt, 
AcpiPmInfo *pm)
(1  ACPI_FADT_F_PROC_C1) |
(1  ACPI_FADT_F_SLP_BUTTON) |
(1  ACPI_FADT_F_RTC_S4));
-fadt-flags |= cpu_to_le32(1  ACPI_FADT_F_USE_PLATFORM_CLOCK);
+fadt-flags |= cpu_to_le32(1  ACPI_FADT_F_USE_PLATFORM_CLOCK |
+   1  ACPI_FADT_F_FORCE_APIC_CLUSTER_MODEL);
  }

Re: [Qemu-devel] [question] e1000 interrupt storm happened becauseof its correspondingioapic-irr bit always set

[Zhang Haoyu]

 Hi, all

 I use a qemu-1.4.1/qemu-2.0.0 to run win7 guest, and encounter e1000 NIC 
 interrupt storm, 
 because if (!ent-fields.mask  (ioapic-irr  (1  i))) is always 
 true in __kvm_ioapic_update_eoi().

 Any ideas?
 We meet this several times: search the autoneg patches for an example of
 workaround for this in qemu, and patch kvm: ioapic: conditionally delay
 irq delivery during eoi broadcast for an workaround in kvm (rejected).

 Thanks, Jason,
 I searched e1000 autoneg in gmane.comp.emulators.qemu, and found below 
 patches, 
 http://thread.gmane.org/gmane.comp.emulators.qemu/143001/focus=143007

This series is the first try to fix the guest hang during guest
hibernation or driver enable/disable.
 http://thread.gmane.org/gmane.comp.emulators.qemu/284105/focus=284765
 http://thread.gmane.org/gmane.comp.emulators.qemu/186159/focus=187351

Those are follow-up that tries to fix the bugs introduced by the autoneg
hack.
 which one tries to fix this problem, or all of them?

As you can see, those kinds of hacking may not as good as we expect
since we don't know exactly how e1000 works. Only the register function
description from Intel's manual may not be sufficient. And you can
search e1000 in the archives and you can find some behaviour of e1000
registers were not fictionalized like what spec said. It was really
suggested to use virtio-net instead of e1000 in guest. 

We support both, virtio-net is the recommended option, 
with regard to some guest (e.g., windows server 2000), virtio-net is not 
supported, e1000 is the last option.
 

 That was probably caused by something wrong in e1000 emulation which
 causes interrupt to be injected into windows guest before its interrupt
 handler is registered. And Windows guest does not have a mechanism to
 detect and disable irq in such condition.

 Sorry, I don't understand,
 I think one interrupt should not been enabled before its handler is 
 successfully registered, 
 is it possible that e1000 emulation inject the interrupt before the 
 interrupt is succesfully enabled?

 Thanks,
 Zhang Haoyu
  
 e1000 emulation is far from stable and complete (e.g run e1000 ethtool
 selftest in linux guest may see lots of errors). It's complicate and
 subtle (even has undocumented registers and behaviour). You should
 better consider to use virtio which are more stable and fast in a kvm
 guest (unless some intel guys are involved to improve e1000 emulation).

 Thanks
 Thanks,
 Zhang Haoyu

[Qemu-devel] [PATCH v6 0/7] Virtio PCI libqos driver

[Marc Marí]

v3: Solved problems, added indirect descriptor support and test for
configuration changes
v4: Solved bugs, changed some interfaces, added MSI-X and event_idx support.
v5: Simplified virtio-blk-test, solved bugs, avoid patches already merged.
v6: Solve bugs (qpci_iomap changed prototype)

Marc Marí (7):
  tests: Functions bus_foreach and device_find from libqos virtio API
  tests: Add virtio device initialization
  libqos: Added basic virtqueue support to virtio implementation
  libqos: Added indirect descriptor support to virtio implementation
  libqos: Added test case for configuration changes in virtio-blk test
  libqos: Added MSI-X support
  libqos: Added EVENT_IDX support

 tests/Makefile|3 +-
 tests/libqos/pci.c|  111 +++-
 tests/libqos/pci.h|   10 +
 tests/libqos/virtio-pci.c |  339 
 tests/libqos/virtio-pci.h |   61 +
 tests/libqos/virtio.c |  257 +++
 tests/libqos/virtio.h |  182 +
 tests/virtio-blk-test.c   |  622 -
 8 files changed, 1574 insertions(+), 11 deletions(-)
 create mode 100644 tests/libqos/virtio-pci.c
 create mode 100644 tests/libqos/virtio-pci.h
 create mode 100644 tests/libqos/virtio.c
 create mode 100644 tests/libqos/virtio.h

-- 
1.7.10.4

[Qemu-devel] [PATCH v6 2/7] tests: Add virtio device initialization

[Marc Marí]

Add functions to read and write virtio header fields.
Add status bit setting in virtio-blk-device.

Signed-off-by: Marc Marí marc.mari.barc...@gmail.com
---
 tests/Makefile|2 +-
 tests/libqos/virtio-pci.c |   67 +
 tests/libqos/virtio-pci.h |   18 
 tests/libqos/virtio.c |   55 +
 tests/libqos/virtio.h |   30 
 tests/virtio-blk-test.c   |   31 ++---
 6 files changed, 198 insertions(+), 5 deletions(-)
 create mode 100644 tests/libqos/virtio.c

diff --git a/tests/Makefile b/tests/Makefile
index a1936f1..ff631fe 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -294,7 +294,7 @@ libqos-obj-y += tests/libqos/i2c.o
 libqos-pc-obj-y = $(libqos-obj-y) tests/libqos/pci-pc.o
 libqos-pc-obj-y += tests/libqos/malloc-pc.o
 libqos-omap-obj-y = $(libqos-obj-y) tests/libqos/i2c-omap.o
-libqos-virtio-obj-y = $(libqos-obj-y) $(libqos-pc-obj-y) 
tests/libqos/virtio-pci.o
+libqos-virtio-obj-y = $(libqos-obj-y) $(libqos-pc-obj-y) tests/libqos/virtio.o 
tests/libqos/virtio-pci.o
 
 tests/rtc-test$(EXESUF): tests/rtc-test.o
 tests/m48t59-test$(EXESUF): tests/m48t59-test.o
diff --git a/tests/libqos/virtio-pci.c b/tests/libqos/virtio-pci.c
index fde1b1f..c78e7dc 100644
--- a/tests/libqos/virtio-pci.c
+++ b/tests/libqos/virtio-pci.c
@@ -55,6 +55,61 @@ static void qvirtio_pci_assign_device(QVirtioDevice *d, void 
*data)
 *vpcidev = (QVirtioPCIDevice *)d;
 }
 
+static uint8_t qvirtio_pci_config_readb(QVirtioDevice *d, void *addr)
+{
+QVirtioPCIDevice *dev = (QVirtioPCIDevice *)d;
+return qpci_io_readb(dev-pdev, addr);
+}
+
+static uint16_t qvirtio_pci_config_readw(QVirtioDevice *d, void *addr)
+{
+QVirtioPCIDevice *dev = (QVirtioPCIDevice *)d;
+return qpci_io_readw(dev-pdev, addr);
+}
+
+static uint32_t qvirtio_pci_config_readl(QVirtioDevice *d, void *addr)
+{
+QVirtioPCIDevice *dev = (QVirtioPCIDevice *)d;
+return qpci_io_readl(dev-pdev, addr);
+}
+
+static uint64_t qvirtio_pci_config_readq(QVirtioDevice *d, void *addr)
+{
+QVirtioPCIDevice *dev = (QVirtioPCIDevice *)d;
+int i;
+union {
+uint8_t bytes[8];
+uint64_t u64;
+} quad;
+
+for (i = 0; i  8; ++i) {
+quad.bytes[i] = qpci_io_readb(dev-pdev, addr + i);
+}
+
+return quad.u64;
+}
+
+static uint8_t qvirtio_pci_get_status(QVirtioDevice *d)
+{
+QVirtioPCIDevice *dev = (QVirtioPCIDevice *)d;
+return qpci_io_readb(dev-pdev, dev-addr + QVIRTIO_DEVICE_STATUS);
+}
+
+static void qvirtio_pci_set_status(QVirtioDevice *d, uint8_t status)
+{
+QVirtioPCIDevice *dev = (QVirtioPCIDevice *)d;
+qpci_io_writeb(dev-pdev, dev-addr + QVIRTIO_DEVICE_STATUS, status);
+}
+
+const QVirtioBus qvirtio_pci = {
+.config_readb = qvirtio_pci_config_readb,
+.config_readw = qvirtio_pci_config_readw,
+.config_readl = qvirtio_pci_config_readl,
+.config_readq = qvirtio_pci_config_readq,
+.get_status = qvirtio_pci_get_status,
+.set_status = qvirtio_pci_set_status,
+};
+
 void qvirtio_pci_foreach(QPCIBus *bus, uint16_t device_type,
 void (*func)(QVirtioDevice *d, void *data), void *data)
 {
@@ -73,3 +128,15 @@ QVirtioPCIDevice *qvirtio_pci_device_find(QPCIBus *bus, 
uint16_t device_type)
 
 return dev;
 }
+
+void qvirtio_pci_device_enable(QVirtioPCIDevice *d)
+{
+qpci_device_enable(d-pdev);
+d-addr = qpci_iomap(d-pdev, 0, NULL);
+g_assert(d-addr != NULL);
+}
+
+void qvirtio_pci_device_disable(QVirtioPCIDevice *d)
+{
+qpci_iounmap(d-pdev, d-addr);
+}
diff --git a/tests/libqos/virtio-pci.h b/tests/libqos/virtio-pci.h
index 5101abb..26f902e 100644
--- a/tests/libqos/virtio-pci.h
+++ b/tests/libqos/virtio-pci.h
@@ -13,12 +13,30 @@
 #include libqos/virtio.h
 #include libqos/pci.h
 
+#define QVIRTIO_DEVICE_FEATURES 0x00
+#define QVIRTIO_GUEST_FEATURES  0x04
+#define QVIRTIO_QUEUE_ADDRESS   0x08
+#define QVIRTIO_QUEUE_SIZE  0x0C
+#define QVIRTIO_QUEUE_SELECT0x0E
+#define QVIRTIO_QUEUE_NOTIFY0x10
+#define QVIRTIO_DEVICE_STATUS   0x12
+#define QVIRTIO_ISR_STATUS  0x13
+#define QVIRTIO_MSIX_CONF_VECTOR0x14
+#define QVIRTIO_MSIX_QUEUE_VECTOR   0x16
+#define QVIRTIO_DEVICE_SPECIFIC_MSIX0x18
+#define QVIRTIO_DEVICE_SPECIFIC_NO_MSIX 0x14
+
 typedef struct QVirtioPCIDevice {
 QVirtioDevice vdev;
 QPCIDevice *pdev;
+void *addr;
 } QVirtioPCIDevice;
 
+extern const QVirtioBus qvirtio_pci;
+
 void qvirtio_pci_foreach(QPCIBus *bus, uint16_t device_type,
 void (*func)(QVirtioDevice *d, void *data), void *data);
 QVirtioPCIDevice *qvirtio_pci_device_find(QPCIBus *bus, uint16_t device_type);
+void qvirtio_pci_device_enable(QVirtioPCIDevice *d);
+void qvirtio_pci_device_disable(QVirtioPCIDevice *d);
 #endif
diff --git a/tests/libqos/virtio.c b/tests/libqos/virtio.c
new file mode 100644
index 000..577d679
--- 

[Qemu-devel] [PATCH v6 1/7] tests: Functions bus_foreach and device_find from libqos virtio API

[Marc Marí]

Virtio header has been changed to compile and work with a real device.
Functions bus_foreach and device_find have been implemented for PCI.
Virtio-blk test case now opens a fake device.

Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Signed-off-by: Marc Marí marc.mari.barc...@gmail.com
---
 tests/Makefile|3 +-
 tests/libqos/virtio-pci.c |   75 +
 tests/libqos/virtio-pci.h |   24 +++
 tests/libqos/virtio.h |   23 ++
 tests/virtio-blk-test.c   |   61 +++-
 5 files changed, 177 insertions(+), 9 deletions(-)
 create mode 100644 tests/libqos/virtio-pci.c
 create mode 100644 tests/libqos/virtio-pci.h
 create mode 100644 tests/libqos/virtio.h

diff --git a/tests/Makefile b/tests/Makefile
index 837e9c8..a1936f1 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -294,6 +294,7 @@ libqos-obj-y += tests/libqos/i2c.o
 libqos-pc-obj-y = $(libqos-obj-y) tests/libqos/pci-pc.o
 libqos-pc-obj-y += tests/libqos/malloc-pc.o
 libqos-omap-obj-y = $(libqos-obj-y) tests/libqos/i2c-omap.o
+libqos-virtio-obj-y = $(libqos-obj-y) $(libqos-pc-obj-y) 
tests/libqos/virtio-pci.o
 
 tests/rtc-test$(EXESUF): tests/rtc-test.o
 tests/m48t59-test$(EXESUF): tests/m48t59-test.o
@@ -315,7 +316,7 @@ tests/vmxnet3-test$(EXESUF): tests/vmxnet3-test.o
 tests/ne2000-test$(EXESUF): tests/ne2000-test.o
 tests/wdt_ib700-test$(EXESUF): tests/wdt_ib700-test.o
 tests/virtio-balloon-test$(EXESUF): tests/virtio-balloon-test.o
-tests/virtio-blk-test$(EXESUF): tests/virtio-blk-test.o
+tests/virtio-blk-test$(EXESUF): tests/virtio-blk-test.o $(libqos-virtio-obj-y)
 tests/virtio-net-test$(EXESUF): tests/virtio-net-test.o
 tests/virtio-rng-test$(EXESUF): tests/virtio-rng-test.o
 tests/virtio-scsi-test$(EXESUF): tests/virtio-scsi-test.o
diff --git a/tests/libqos/virtio-pci.c b/tests/libqos/virtio-pci.c
new file mode 100644
index 000..fde1b1f
--- /dev/null
+++ b/tests/libqos/virtio-pci.c
@@ -0,0 +1,75 @@
+/*
+ * libqos virtio PCI driver
+ *
+ * Copyright (c) 2014 Marc Marí
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include glib.h
+#include libqtest.h
+#include libqos/virtio.h
+#include libqos/virtio-pci.h
+#include libqos/pci.h
+#include libqos/pci-pc.h
+
+#include hw/pci/pci_regs.h
+
+typedef struct QVirtioPCIForeachData {
+void (*func)(QVirtioDevice *d, void *data);
+uint16_t device_type;
+void *user_data;
+} QVirtioPCIForeachData;
+
+static QVirtioPCIDevice *qpcidevice_to_qvirtiodevice(QPCIDevice *pdev)
+{
+QVirtioPCIDevice *vpcidev;
+vpcidev = g_malloc0(sizeof(*vpcidev));
+
+if (pdev) {
+vpcidev-pdev = pdev;
+vpcidev-vdev.device_type =
+qpci_config_readw(vpcidev-pdev, PCI_SUBSYSTEM_ID);
+}
+
+return vpcidev;
+}
+
+static void qvirtio_pci_foreach_callback(
+QPCIDevice *dev, int devfn, void *data)
+{
+QVirtioPCIForeachData *d = data;
+QVirtioPCIDevice *vpcidev = qpcidevice_to_qvirtiodevice(dev);
+
+if (vpcidev-vdev.device_type == d-device_type) {
+d-func(vpcidev-vdev, d-user_data);
+} else {
+g_free(vpcidev);
+}
+}
+
+static void qvirtio_pci_assign_device(QVirtioDevice *d, void *data)
+{
+QVirtioPCIDevice **vpcidev = data;
+*vpcidev = (QVirtioPCIDevice *)d;
+}
+
+void qvirtio_pci_foreach(QPCIBus *bus, uint16_t device_type,
+void (*func)(QVirtioDevice *d, void *data), void *data)
+{
+QVirtioPCIForeachData d = { .func = func,
+.device_type = device_type,
+.user_data = data };
+
+qpci_device_foreach(bus, QVIRTIO_VENDOR_ID, -1,
+qvirtio_pci_foreach_callback, d);
+}
+
+QVirtioPCIDevice *qvirtio_pci_device_find(QPCIBus *bus, uint16_t device_type)
+{
+QVirtioPCIDevice *dev = NULL;
+qvirtio_pci_foreach(bus, device_type, qvirtio_pci_assign_device, dev);
+
+return dev;
+}
diff --git a/tests/libqos/virtio-pci.h b/tests/libqos/virtio-pci.h
new file mode 100644
index 000..5101abb
--- /dev/null
+++ b/tests/libqos/virtio-pci.h
@@ -0,0 +1,24 @@
+/*
+ * libqos virtio PCI definitions
+ *
+ * Copyright (c) 2014 Marc Marí
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#ifndef LIBQOS_VIRTIO_PCI_H
+#define LIBQOS_VIRTIO_PCI_H
+
+#include libqos/virtio.h
+#include libqos/pci.h
+
+typedef struct QVirtioPCIDevice {
+QVirtioDevice vdev;
+QPCIDevice *pdev;
+} QVirtioPCIDevice;
+
+void qvirtio_pci_foreach(QPCIBus *bus, uint16_t device_type,
+void (*func)(QVirtioDevice *d, void *data), void *data);
+QVirtioPCIDevice *qvirtio_pci_device_find(QPCIBus *bus, uint16_t device_type);
+#endif
diff --git a/tests/libqos/virtio.h b/tests/libqos/virtio.h
new file mode 100644
index 

[Qemu-devel] [PATCH v6 3/7] libqos: Added basic virtqueue support to virtio implementation

[Marc Marí]

Add status changing and feature negotiation.
Add basic virtqueue support for adding and sending virtqueue requests.
Add ISR checking.

Signed-off-by: Marc Marí marc.mari.barc...@gmail.com
---
 tests/libqos/virtio-pci.c |   82 +
 tests/libqos/virtio-pci.h |2 +
 tests/libqos/virtio.c |  100 +
 tests/libqos/virtio.h |   99 +
 tests/virtio-blk-test.c   |  178 -
 5 files changed, 458 insertions(+), 3 deletions(-)

diff --git a/tests/libqos/virtio-pci.c b/tests/libqos/virtio-pci.c
index c78e7dc..b504203 100644
--- a/tests/libqos/virtio-pci.c
+++ b/tests/libqos/virtio-pci.c
@@ -13,6 +13,8 @@
 #include libqos/virtio-pci.h
 #include libqos/pci.h
 #include libqos/pci-pc.h
+#include libqos/malloc.h
+#include libqos/malloc-pc.h
 
 #include hw/pci/pci_regs.h
 
@@ -89,6 +91,18 @@ static uint64_t qvirtio_pci_config_readq(QVirtioDevice *d, 
void *addr)
 return quad.u64;
 }
 
+static uint32_t qvirtio_pci_get_features(QVirtioDevice *d)
+{
+QVirtioPCIDevice *dev = (QVirtioPCIDevice *)d;
+return qpci_io_readl(dev-pdev, dev-addr + QVIRTIO_DEVICE_FEATURES);
+}
+
+static void qvirtio_pci_set_features(QVirtioDevice *d, uint32_t features)
+{
+QVirtioPCIDevice *dev = (QVirtioPCIDevice *)d;
+qpci_io_writel(dev-pdev, dev-addr + QVIRTIO_GUEST_FEATURES, features);
+}
+
 static uint8_t qvirtio_pci_get_status(QVirtioDevice *d)
 {
 QVirtioPCIDevice *dev = (QVirtioPCIDevice *)d;
@@ -101,13 +115,81 @@ static void qvirtio_pci_set_status(QVirtioDevice *d, 
uint8_t status)
 qpci_io_writeb(dev-pdev, dev-addr + QVIRTIO_DEVICE_STATUS, status);
 }
 
+static uint8_t qvirtio_pci_get_isr_status(QVirtioDevice *d)
+{
+QVirtioPCIDevice *dev = (QVirtioPCIDevice *)d;
+return qpci_io_readb(dev-pdev, dev-addr + QVIRTIO_ISR_STATUS);
+}
+
+static void qvirtio_pci_queue_select(QVirtioDevice *d, uint16_t index)
+{
+QVirtioPCIDevice *dev = (QVirtioPCIDevice *)d;
+qpci_io_writeb(dev-pdev, dev-addr + QVIRTIO_QUEUE_SELECT, index);
+}
+
+static uint16_t qvirtio_pci_get_queue_size(QVirtioDevice *d)
+{
+QVirtioPCIDevice *dev = (QVirtioPCIDevice *)d;
+return qpci_io_readw(dev-pdev, dev-addr + QVIRTIO_QUEUE_SIZE);
+}
+
+static void qvirtio_pci_set_queue_address(QVirtioDevice *d, uint32_t pfn)
+{
+QVirtioPCIDevice *dev = (QVirtioPCIDevice *)d;
+qpci_io_writel(dev-pdev, dev-addr + QVIRTIO_QUEUE_ADDRESS, pfn);
+}
+
+static QVirtQueue *qvirtio_pci_virtqueue_setup(QVirtioDevice *d,
+QGuestAllocator *alloc, uint16_t index)
+{
+uint64_t addr;
+QVirtQueue *vq;
+
+vq = g_malloc0(sizeof(*vq));
+
+qvirtio_pci_queue_select(d, index);
+vq-index = index;
+vq-size = qvirtio_pci_get_queue_size(d);
+vq-free_head = 0;
+vq-num_free = vq-size;
+vq-align = QVIRTIO_PCI_ALIGN;
+
+/* Check different than 0 */
+g_assert_cmpint(vq-size, !=, 0);
+
+/* Check power of 2 */
+g_assert_cmpint(vq-size  (vq-size - 1), ==, 0);
+
+addr = guest_alloc(alloc, qvring_size(vq-size, QVIRTIO_PCI_ALIGN));
+qvring_init(alloc, vq, addr);
+qvirtio_pci_set_queue_address(d, vq-desc / QVIRTIO_PCI_ALIGN);
+
+/* TODO: MSI-X configuration */
+
+return vq;
+}
+
+static void qvirtio_pci_virtqueue_kick(QVirtioDevice *d, QVirtQueue *vq)
+{
+QVirtioPCIDevice *dev = (QVirtioPCIDevice *)d;
+qpci_io_writew(dev-pdev, dev-addr + QVIRTIO_QUEUE_NOTIFY, vq-index);
+}
+
 const QVirtioBus qvirtio_pci = {
 .config_readb = qvirtio_pci_config_readb,
 .config_readw = qvirtio_pci_config_readw,
 .config_readl = qvirtio_pci_config_readl,
 .config_readq = qvirtio_pci_config_readq,
+.get_features = qvirtio_pci_get_features,
+.set_features = qvirtio_pci_set_features,
 .get_status = qvirtio_pci_get_status,
 .set_status = qvirtio_pci_set_status,
+.get_isr_status = qvirtio_pci_get_isr_status,
+.queue_select = qvirtio_pci_queue_select,
+.get_queue_size = qvirtio_pci_get_queue_size,
+.set_queue_address = qvirtio_pci_set_queue_address,
+.virtqueue_setup = qvirtio_pci_virtqueue_setup,
+.virtqueue_kick = qvirtio_pci_virtqueue_kick,
 };
 
 void qvirtio_pci_foreach(QPCIBus *bus, uint16_t device_type,
diff --git a/tests/libqos/virtio-pci.h b/tests/libqos/virtio-pci.h
index 26f902e..40bd12d 100644
--- a/tests/libqos/virtio-pci.h
+++ b/tests/libqos/virtio-pci.h
@@ -26,6 +26,8 @@
 #define QVIRTIO_DEVICE_SPECIFIC_MSIX0x18
 #define QVIRTIO_DEVICE_SPECIFIC_NO_MSIX 0x14
 
+#define QVIRTIO_PCI_ALIGN   4096
+
 typedef struct QVirtioPCIDevice {
 QVirtioDevice vdev;
 QPCIDevice *pdev;
diff --git a/tests/libqos/virtio.c b/tests/libqos/virtio.c
index 577d679..de92642 100644
--- a/tests/libqos/virtio.c
+++ b/tests/libqos/virtio.c
@@ -35,6 +35,23 @@ uint64_t qvirtio_config_readq(const QVirtioBus *bus, 
QVirtioDevice *d,
 return bus-config_readq(d, addr);
 }
 
+uint32_t qvirtio_get_features(const 

[Qemu-devel] [PATCH v6 4/7] libqos: Added indirect descriptor support to virtio implementation

[Marc Marí]

Add functions necessary for working with indirect descriptors.
Add test using new functions.

Signed-off-by: Marc Marí marc.mari.barc...@gmail.com
---
 tests/libqos/virtio-pci.c |   10 +
 tests/libqos/virtio.c |   64 +
 tests/libqos/virtio.h |   22 +-
 tests/virtio-blk-test.c   |  100 +
 4 files changed, 195 insertions(+), 1 deletion(-)

diff --git a/tests/libqos/virtio-pci.c b/tests/libqos/virtio-pci.c
index b504203..5c39ddf 100644
--- a/tests/libqos/virtio-pci.c
+++ b/tests/libqos/virtio-pci.c
@@ -103,6 +103,12 @@ static void qvirtio_pci_set_features(QVirtioDevice *d, 
uint32_t features)
 qpci_io_writel(dev-pdev, dev-addr + QVIRTIO_GUEST_FEATURES, features);
 }
 
+static uint32_t qvirtio_pci_get_guest_features(QVirtioDevice *d)
+{
+QVirtioPCIDevice *dev = (QVirtioPCIDevice *)d;
+return qpci_io_readl(dev-pdev, dev-addr + QVIRTIO_GUEST_FEATURES);
+}
+
 static uint8_t qvirtio_pci_get_status(QVirtioDevice *d)
 {
 QVirtioPCIDevice *dev = (QVirtioPCIDevice *)d;
@@ -142,10 +148,12 @@ static void qvirtio_pci_set_queue_address(QVirtioDevice 
*d, uint32_t pfn)
 static QVirtQueue *qvirtio_pci_virtqueue_setup(QVirtioDevice *d,
 QGuestAllocator *alloc, uint16_t index)
 {
+uint32_t feat;
 uint64_t addr;
 QVirtQueue *vq;
 
 vq = g_malloc0(sizeof(*vq));
+feat = qvirtio_pci_get_guest_features(d);
 
 qvirtio_pci_queue_select(d, index);
 vq-index = index;
@@ -153,6 +161,7 @@ static QVirtQueue 
*qvirtio_pci_virtqueue_setup(QVirtioDevice *d,
 vq-free_head = 0;
 vq-num_free = vq-size;
 vq-align = QVIRTIO_PCI_ALIGN;
+vq-indirect = (feat  QVIRTIO_F_RING_INDIRECT_DESC) != 0;
 
 /* Check different than 0 */
 g_assert_cmpint(vq-size, !=, 0);
@@ -182,6 +191,7 @@ const QVirtioBus qvirtio_pci = {
 .config_readq = qvirtio_pci_config_readq,
 .get_features = qvirtio_pci_get_features,
 .set_features = qvirtio_pci_set_features,
+.get_guest_features = qvirtio_pci_get_guest_features,
 .get_status = qvirtio_pci_get_status,
 .set_status = qvirtio_pci_set_status,
 .get_isr_status = qvirtio_pci_get_isr_status,
diff --git a/tests/libqos/virtio.c b/tests/libqos/virtio.c
index de92642..b1cab1f 100644
--- a/tests/libqos/virtio.c
+++ b/tests/libqos/virtio.c
@@ -116,6 +116,51 @@ void qvring_init(const QGuestAllocator *alloc, QVirtQueue 
*vq, uint64_t addr)
 writew(vq-used, 0);
 }
 
+QVRingIndirectDesc *qvring_indirect_desc_setup(QVirtioDevice *d,
+QGuestAllocator *alloc, uint16_t elem)
+{
+int i;
+QVRingIndirectDesc *indirect = g_malloc(sizeof(*indirect));
+
+indirect-index = 0;
+indirect-elem = elem;
+indirect-desc = guest_alloc(alloc, sizeof(QVRingDesc)*elem);
+
+for (i = 0; i  elem - 1; ++i) {
+/* indirect-desc[i].addr */
+writeq(indirect-desc + (16 * i), 0);
+/* indirect-desc[i].flags */
+writew(indirect-desc + (16 * i) + 12, QVRING_DESC_F_NEXT);
+/* indirect-desc[i].next */
+writew(indirect-desc + (16 * i) + 14, i + 1);
+}
+
+return indirect;
+}
+
+void qvring_indirect_desc_add(QVRingIndirectDesc *indirect, uint64_t data,
+uint32_t len, bool write)
+{
+uint16_t flags;
+
+g_assert_cmpint(indirect-index, , indirect-elem);
+
+flags = readw(indirect-desc + (16 * indirect-index) + 12);
+
+if (write) {
+flags |= QVRING_DESC_F_WRITE;
+}
+
+/* indirect-desc[indirect-index].addr */
+writeq(indirect-desc + (16 * indirect-index), data);
+/* indirect-desc[indirect-index].len */
+writel(indirect-desc + (16 * indirect-index) + 8, len);
+/* indirect-desc[indirect-index].flags */
+writew(indirect-desc + (16 * indirect-index) + 12, flags);
+
+indirect-index++;
+}
+
 uint32_t qvirtqueue_add(QVirtQueue *vq, uint64_t data, uint32_t len, bool 
write,
 bool next)
 {
@@ -140,6 +185,25 @@ uint32_t qvirtqueue_add(QVirtQueue *vq, uint64_t data, 
uint32_t len, bool write,
 return vq-free_head++; /* Return and increase, in this order */
 }
 
+uint32_t qvirtqueue_add_indirect(QVirtQueue *vq, QVRingIndirectDesc *indirect)
+{
+g_assert(vq-indirect);
+g_assert_cmpint(vq-size, =, indirect-elem);
+g_assert_cmpint(indirect-index, ==, indirect-elem);
+
+vq-num_free--;
+
+/* vq-desc[vq-free_head].addr */
+writeq(vq-desc + (16 * vq-free_head), indirect-desc);
+/* vq-desc[vq-free_head].len */
+writel(vq-desc + (16 * vq-free_head) + 8,
+sizeof(QVRingDesc) * indirect-elem);
+/* vq-desc[vq-free_head].flags */
+writew(vq-desc + (16 * vq-free_head) + 12, QVRING_DESC_F_INDIRECT);
+
+return vq-free_head++; /* Return and increase, in this order */
+}
+
 void qvirtqueue_kick(const 

[Qemu-devel] [PATCH v6 5/7] libqos: Added test case for configuration changes in virtio-blk test

[Marc Marí]

Signed-off-by: Marc Marí marc.mari.barc...@gmail.com
---
 tests/virtio-blk-test.c |   34 ++
 1 file changed, 34 insertions(+)

diff --git a/tests/virtio-blk-test.c b/tests/virtio-blk-test.c
index 95e6861..07ae754 100644
--- a/tests/virtio-blk-test.c
+++ b/tests/virtio-blk-test.c
@@ -359,6 +359,39 @@ static void pci_indirect(void)
 test_end();
 }
 
+static void pci_config(void)
+{
+QVirtioPCIDevice *dev;
+QPCIBus *bus;
+int n_size = TEST_IMAGE_SIZE / 2;
+void *addr;
+uint64_t capacity;
+
+bus = test_start();
+
+dev = virtio_blk_init(bus);
+
+/* MSI-X is not enabled */
+addr = dev-addr + QVIRTIO_DEVICE_SPECIFIC_NO_MSIX;
+
+capacity = qvirtio_config_readq(qvirtio_pci, dev-vdev, addr);
+g_assert_cmpint(capacity, ==, TEST_IMAGE_SIZE / 512);
+
+qvirtio_set_driver_ok(qvirtio_pci, dev-vdev);
+
+qmp({ 'execute': 'block_resize', 'arguments': { 'device': 'drive0', 
+ 'size': %d } }, n_size);
+g_assert(qvirtio_wait_isr(qvirtio_pci, dev-vdev, 0x2,
+QVIRTIO_BLK_TIMEOUT));
+
+capacity = qvirtio_config_readq(qvirtio_pci, dev-vdev, addr);
+g_assert_cmpint(capacity, ==, n_size / 512);
+
+qvirtio_pci_device_disable(dev);
+g_free(dev);
+test_end();
+}
+
 int main(int argc, char **argv)
 {
 int ret;
@@ -367,6 +400,7 @@ int main(int argc, char **argv)
 
 g_test_add_func(/virtio/blk/pci/basic, pci_basic);
 g_test_add_func(/virtio/blk/pci/indirect, pci_indirect);
+g_test_add_func(/virtio/blk/pci/config, pci_config);
 
 ret = g_test_run();
 
-- 
1.7.10.4

[Qemu-devel] [PATCH v6 7/7] libqos: Added EVENT_IDX support

[Marc Marí]

Added avail_event and NO_NOTIFY check before notifying.
Added used_event setting.

Signed-off-by: Marc Marí marc.mari.barc...@gmail.com
---
 tests/libqos/virtio-pci.c |1 +
 tests/libqos/virtio.c |   27 +-
 tests/libqos/virtio.h |5 ++
 tests/virtio-blk-test.c   |  124 +
 4 files changed, 156 insertions(+), 1 deletion(-)

diff --git a/tests/libqos/virtio-pci.c b/tests/libqos/virtio-pci.c
index 3df73b7..0260411 100644
--- a/tests/libqos/virtio-pci.c
+++ b/tests/libqos/virtio-pci.c
@@ -199,6 +199,7 @@ static QVirtQueue 
*qvirtio_pci_virtqueue_setup(QVirtioDevice *d,
 vqpci-vq.num_free = vqpci-vq.size;
 vqpci-vq.align = QVIRTIO_PCI_ALIGN;
 vqpci-vq.indirect = (feat  QVIRTIO_F_RING_INDIRECT_DESC) != 0;
+vqpci-vq.event = (feat  QVIRTIO_F_RING_EVENT_IDX) != 0;
 
 vqpci-msix_entry = -1;
 vqpci-msix_addr = 0;
diff --git a/tests/libqos/virtio.c b/tests/libqos/virtio.c
index 16eaf79..128dbd0 100644
--- a/tests/libqos/virtio.c
+++ b/tests/libqos/virtio.c
@@ -124,9 +124,13 @@ void qvring_init(const QGuestAllocator *alloc, QVirtQueue 
*vq, uint64_t addr)
 writew(vq-avail, 0);
 /* vq-avail-idx */
 writew(vq-avail + 2, 0);
+/* vq-avail-used_event */
+writew(vq-avail + 4 + (2 * vq-size), 0);
 
 /* vq-used-flags */
 writew(vq-used, 0);
+/* vq-used-avail_event */
+writew(vq-used+2+(sizeof(struct QVRingUsedElem)*vq-size), 0);
 }
 
 QVRingIndirectDesc *qvring_indirect_desc_setup(QVirtioDevice *d,
@@ -222,11 +226,32 @@ void qvirtqueue_kick(const QVirtioBus *bus, QVirtioDevice 
*d, QVirtQueue *vq,
 {
 /* vq-avail-idx */
 uint16_t idx = readl(vq-avail + 2);
+/* vq-used-flags */
+uint16_t flags;
+/* vq-used-avail_event */
+uint16_t avail_event;
 
 /* vq-avail-ring[idx % vq-size] */
 writel(vq-avail + 4 + (2 * (idx % vq-size)), free_head);
 /* vq-avail-idx */
 writel(vq-avail + 2, idx + 1);
 
-bus-virtqueue_kick(d, vq);
+/* Must read after idx is updated */
+flags = readw(vq-avail);
+avail_event = readw(vq-used + 4 +
+(sizeof(struct QVRingUsedElem) * vq-size));
+
+/*  1 because we add elements to avail queue one by one */
+if ((flags  QVRING_USED_F_NO_NOTIFY) == 0 
+(!vq-event || (uint16_t)(idx-avail_event)  1)) {
+bus-virtqueue_kick(d, vq);
+}
+}
+
+void qvirtqueue_set_used_event(QVirtQueue *vq, uint16_t idx)
+{
+g_assert(vq-event);
+
+/* vq-avail-used_event */
+writew(vq-avail + 4 + (2 * vq-size), idx);
 }
diff --git a/tests/libqos/virtio.h b/tests/libqos/virtio.h
index cebccd2..70b3376 100644
--- a/tests/libqos/virtio.h
+++ b/tests/libqos/virtio.h
@@ -26,6 +26,7 @@
 #define QVIRTIO_F_ANY_LAYOUT0x0800
 #define QVIRTIO_F_RING_INDIRECT_DESC0x1000
 #define QVIRTIO_F_RING_EVENT_IDX0x2000
+#define QVIRTIO_F_BAD_FEATURE   0x4000
 
 #define QVRING_DESC_F_NEXT  0x1
 #define QVRING_DESC_F_WRITE 0x2
@@ -57,6 +58,7 @@ typedef struct QVRingAvail {
 uint16_t flags;
 uint16_t idx;
 uint16_t ring[0]; /* This is an array of uint16_t */
+uint16_t used_event;
 } QVRingAvail;
 
 typedef struct QVRingUsedElem {
@@ -68,6 +70,7 @@ typedef struct QVRingUsed {
 uint16_t flags;
 uint16_t idx;
 QVRingUsedElem ring[0]; /* This is an array of QVRingUsedElem structs */
+uint16_t avail_event;
 } QVRingUsed;
 
 typedef struct QVirtQueue {
@@ -80,6 +83,7 @@ typedef struct QVirtQueue {
 uint32_t num_free;
 uint32_t align;
 bool indirect;
+bool event;
 } QVirtQueue;
 
 typedef struct QVRingIndirectDesc {
@@ -174,4 +178,5 @@ uint32_t qvirtqueue_add_indirect(QVirtQueue *vq, 
QVRingIndirectDesc *indirect);
 void qvirtqueue_kick(const QVirtioBus *bus, QVirtioDevice *d, QVirtQueue *vq,
 uint32_t 
free_head);
 
+void qvirtqueue_set_used_event(QVirtQueue *vq, uint16_t idx);
 #endif
diff --git a/tests/virtio-blk-test.c b/tests/virtio-blk-test.c
index 026abc2..fdc6ffe 100644
--- a/tests/virtio-blk-test.c
+++ b/tests/virtio-blk-test.c
@@ -478,6 +478,129 @@ static void pci_msix(void)
 
 qvirtqueue_kick(qvirtio_pci, dev-vdev, vqpci-vq, free_head);
 
+
+g_assert(qvirtio_wait_queue_isr(qvirtio_pci, dev-vdev, vqpci-vq,
+QVIRTIO_BLK_TIMEOUT));
+
+status = readb(req_addr + 528);
+g_assert_cmpint(status, ==, 0);
+
+data = g_malloc0(512);
+memread(req_addr + 16, data, 512);
+g_assert_cmpstr(data, ==, TEST);
+g_free(data);
+
+guest_free(alloc, req_addr);
+
+/* End test */
+guest_free(alloc, (uint64_t)vqpci-vq.desc);
+qpci_msix_disable(dev-pdev);
+qvirtio_pci_device_disable(dev);
+g_free(dev);
+test_end();
+}
+
+static void pci_idx(void)
+{
+QVirtioPCIDevice *dev;
+QPCIBus *bus;
+QVirtQueuePCI *vqpci;
+QGuestAllocator 

[Qemu-devel] [PATCH v6 6/7] libqos: Added MSI-X support

[Marc Marí]

Added MSI-X support for qtest PCI.
Added MSI-X support for virtio-pci.
Added MSI-X test case in virtio-blk-test.

Signed-off-by: Marc Marí marc.mari.barc...@gmail.com
---
 tests/libqos/pci.c|  111 +++-
 tests/libqos/pci.h|   10 +++
 tests/libqos/virtio-pci.c |  142 ++-
 tests/libqos/virtio-pci.h |   17 +
 tests/libqos/virtio.c |   17 -
 tests/libqos/virtio.h |   11 ++-
 tests/virtio-blk-test.c   |  180 -
 7 files changed, 426 insertions(+), 62 deletions(-)

diff --git a/tests/libqos/pci.c b/tests/libqos/pci.c
index ce0b308..d5ce683 100644
--- a/tests/libqos/pci.c
+++ b/tests/libqos/pci.c
@@ -15,8 +15,6 @@
 #include hw/pci/pci_regs.h
 #include glib.h
 
-#include stdio.h
-
 void qpci_device_foreach(QPCIBus *bus, int vendor_id, int device_id,
  void (*func)(QPCIDevice *dev, int devfn, void *data),
  void *data)
@@ -75,6 +73,115 @@ void qpci_device_enable(QPCIDevice *dev)
 qpci_config_writew(dev, PCI_COMMAND, cmd);
 }
 
+uint8_t qpci_find_capability(QPCIDevice *dev, uint8_t id)
+{
+uint8_t cap;
+uint8_t addr = qpci_config_readb(dev, PCI_CAPABILITY_LIST);
+
+do {
+cap = qpci_config_readb(dev, addr);
+if (cap != id) {
+addr = qpci_config_readb(dev, addr + PCI_CAP_LIST_NEXT);
+}
+} while (cap != id  addr != 0);
+
+return addr;
+}
+
+void qpci_msix_enable(QPCIDevice *dev)
+{
+uint8_t addr;
+uint16_t val;
+uint32_t table;
+uint8_t bir_table;
+uint8_t bir_pba;
+void *offset;
+
+addr = qpci_find_capability(dev, PCI_CAP_ID_MSIX);
+g_assert_cmphex(addr, !=, 0);
+
+val = qpci_config_readw(dev, addr + PCI_MSIX_FLAGS);
+qpci_config_writew(dev, addr + PCI_MSIX_FLAGS, val | 
PCI_MSIX_FLAGS_ENABLE);
+
+table = qpci_config_readl(dev, addr + PCI_MSIX_TABLE);
+bir_table = table  PCI_MSIX_FLAGS_BIRMASK;
+offset = qpci_iomap(dev, bir_table, NULL);
+dev-msix_table = offset + (table  ~PCI_MSIX_FLAGS_BIRMASK);
+
+table = qpci_config_readl(dev, addr + PCI_MSIX_PBA);
+bir_pba = table  PCI_MSIX_FLAGS_BIRMASK;
+if (bir_pba != bir_table) {
+offset = qpci_iomap(dev, bir_pba, NULL);
+}
+dev-msix_pba = offset + (table  ~PCI_MSIX_FLAGS_BIRMASK);
+
+g_assert(dev-msix_table != NULL);
+g_assert(dev-msix_pba != NULL);
+dev-msix_enabled = true;
+}
+
+void qpci_msix_disable(QPCIDevice *dev)
+{
+uint8_t addr;
+uint16_t val;
+
+g_assert(dev-msix_enabled);
+addr = qpci_find_capability(dev, PCI_CAP_ID_MSIX);
+g_assert_cmphex(addr, !=, 0);
+val = qpci_config_readw(dev, addr + PCI_MSIX_FLAGS);
+qpci_config_writew(dev, addr + PCI_MSIX_FLAGS,
+val  ~PCI_MSIX_FLAGS_ENABLE);
+
+qpci_iounmap(dev, dev-msix_table);
+qpci_iounmap(dev, dev-msix_pba);
+dev-msix_enabled = 0;
+dev-msix_table = NULL;
+dev-msix_pba = NULL;
+}
+
+bool qpci_msix_pending(QPCIDevice *dev, uint16_t entry)
+{
+uint32_t pba_entry;
+uint8_t bit_n = entry % 32;
+void *addr = dev-msix_pba + (entry / 32) * PCI_MSIX_ENTRY_SIZE / 4;
+
+g_assert(dev-msix_enabled);
+pba_entry = qpci_io_readl(dev, addr);
+qpci_io_writel(dev, addr, pba_entry  ~(1  bit_n));
+return (pba_entry  (1  bit_n)) != 0;
+}
+
+bool qpci_msix_masked(QPCIDevice *dev, uint16_t entry)
+{
+uint8_t addr;
+uint16_t val;
+void *vector_addr = dev-msix_table + (entry * PCI_MSIX_ENTRY_SIZE);
+
+g_assert(dev-msix_enabled);
+addr = qpci_find_capability(dev, PCI_CAP_ID_MSIX);
+g_assert_cmphex(addr, !=, 0);
+val = qpci_config_readw(dev, addr + PCI_MSIX_FLAGS);
+
+if (val  PCI_MSIX_FLAGS_MASKALL) {
+return true;
+} else {
+return (qpci_io_readl(dev, vector_addr + PCI_MSIX_ENTRY_VECTOR_CTRL)
+ PCI_MSIX_ENTRY_CTRL_MASKBIT) != 
0;
+}
+}
+
+uint16_t qpci_msix_table_size(QPCIDevice *dev)
+{
+uint8_t addr;
+uint16_t control;
+
+addr = qpci_find_capability(dev, PCI_CAP_ID_MSIX);
+g_assert_cmphex(addr, !=, 0);
+
+control = qpci_config_readw(dev, addr + PCI_MSIX_FLAGS);
+return (control  PCI_MSIX_FLAGS_QSIZE) + 1;
+}
+
 uint8_t qpci_config_readb(QPCIDevice *dev, uint8_t offset)
 {
 return dev-bus-config_readb(dev-bus, dev-devfn, offset);
diff --git a/tests/libqos/pci.h b/tests/libqos/pci.h
index 9ee048b..d51eb9e 100644
--- a/tests/libqos/pci.h
+++ b/tests/libqos/pci.h
@@ -14,6 +14,7 @@
 #define LIBQOS_PCI_H
 
 #include stdint.h
+#include libqtest.h
 
 #define QPCI_DEVFN(dev, fn) (((dev)  3) | (fn))
 
@@ -49,6 +50,9 @@ struct QPCIDevice
 {
 QPCIBus *bus;
 int devfn;
+bool msix_enabled;
+void *msix_table;
+void *msix_pba;
 };
 
 void qpci_device_foreach(QPCIBus *bus, int vendor_id, int device_id,
@@ -57,6 +61,12 @@ void qpci_device_foreach(QPCIBus *bus, int 

[Qemu-devel] [PATCH] device_tree.c: redirect load_device_tree err message to stderr

[john.liuli]

From: Li Liu john.li...@huawei.com

Signed-off-by: Li Liu john.li...@huawei.com
---
 device_tree.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/device_tree.c b/device_tree.c
index ca83504..ccdb039 100644
--- a/device_tree.c
+++ b/device_tree.c
@@ -79,7 +79,7 @@ void *load_device_tree(const char *filename_path, int *sizep)
 *sizep = 0;
 dt_size = get_image_size(filename_path);
 if (dt_size  0) {
-printf(Unable to get size of device tree file '%s'\n,
+fprintf(stderr, Unable to get size of device tree file '%s'\n,
 filename_path);
 goto fail;
 }
@@ -92,20 +92,20 @@ void *load_device_tree(const char *filename_path, int 
*sizep)
 
 dt_file_load_size = load_image(filename_path, fdt);
 if (dt_file_load_size  0) {
-printf(Unable to open device tree file '%s'\n,
+fprintf(stderr, Unable to open device tree file '%s'\n,
filename_path);
 goto fail;
 }
 
 ret = fdt_open_into(fdt, fdt, dt_size);
 if (ret) {
-printf(Unable to copy device tree in memory\n);
+fprintf(stderr, Unable to copy device tree in memory\n);
 goto fail;
 }
 
 /* Check sanity of device tree */
 if (fdt_check_header(fdt)) {
-printf (Device tree file loaded into memory is invalid: %s\n,
+fprintf(stderr, Device tree file loaded into memory is invalid: %s\n,
 filename_path);
 goto fail;
 }
-- 
1.7.9.5

Re: [Qemu-devel] [PATCH v2 2/2] pci: add check for pcie root ports and downstream ports

[Knut Omang]

On Thu, 2014-08-21 at 17:47 +0800, arei.gong...@huawei.com wrote:
 From: Gonglei arei.gong...@huawei.com
 
 If ARI Forwarding is disabled, according to PCIe spec
 section 7.3.1, only slot 0 with the device attached to
 logic bus representing the link from downstream
 ports and root ports.
 
 So, adding check for PCIe downstream ports and root ports,
 which avoid useless operation, both hotplug and coldplug.
 
 Signed-off-by: Gonglei arei.gong...@huawei.com
 ---
  hw/pci/pci.c | 51 +++
  1 file changed, 51 insertions(+)
 
 diff --git a/hw/pci/pci.c b/hw/pci/pci.c
 index daeaeac..aa0af0c 100644
 --- a/hw/pci/pci.c
 +++ b/hw/pci/pci.c
 @@ -773,6 +773,52 @@ static int pci_init_multifunction(PCIBus *bus, PCIDevice 
 *dev)
  return 0;
  }
  
 +static int pci_check_pcie_port(PCIBus *bus, PCIDevice *dev)
 +{
 +Object *obj = OBJECT(bus);
 +
 +if (pci_bus_is_root(bus)) {
 +return 0;
 +}
 +
 +if (object_dynamic_cast(obj, TYPE_PCIE_BUS)) {
 +DeviceState *parent = qbus_get_parent(BUS(obj));
 +PCIDevice *pci_dev = PCI_DEVICE(parent);
 +uint8_t port_type;
 +/*
 + * Root ports and downstream ports of switches are the hot
 + * pluggable ports in a PCI Express hierarchy.
 + * PCI Express supports chip-to-chip interconnect, a PCIe link can
 + * only connect one pci device/Switch/EndPoint or PCI-bridge.
 + *
 + * 7.3. Configuration Transaction Rules (PCI Express specification 
 3.0)
 + * 7.3.1. Device Number
 + *
 + * Downstream Ports that do not have ARI Forwarding enabled must
 + * associate only Device 0 with the device attached to the Logical 
 Bus
 + * representing the Link from the Port.
 + *
 + * If ARI Forwarding is not enabled on root ports and downstream
 + * ports, only support the devices with slot non-0, regardless of
 + * hotplug or coldplug.
 + */

My interpretation of this section of the spec is that if ARI forwarding
is not available, only the normal 8 functions can be accessed for each
device, eg. device/functions 0.0 - 0.7  - if a device has more than 8
functions, it will need the second device's namespace, eg. devfn 1.0++,
which would not be routed correctly in a non-ari forward capable device.

As far as I understand, with this fix you restrict an non-ARI capable
switch to only expose one device?

Knut

 +port_type = pcie_cap_get_type(pci_dev);
 +if (port_type == PCI_EXP_TYPE_DOWNSTREAM ||
 +port_type == PCI_EXP_TYPE_ROOT_PORT) {
 +if (!pcie_cap_is_ari_enabled(pci_dev)) {
 +if (PCI_SLOT(dev-devfn) != 0) {
 +error_report(PCIe: Port's ARI Forwarding is disabled, 
 + device can't be populated in slot %d,
 + PCI_SLOT(dev-devfn));
 +return -1;
 +}
 +}
 +}
 +}
 +
 +return 0;
 +}
 +
  static void pci_config_alloc(PCIDevice *pci_dev)
  {
  int config_size = pci_config_size(pci_dev);
 @@ -827,6 +873,11 @@ static PCIDevice *do_pci_register_device(PCIDevice 
 *pci_dev, PCIBus *bus,
  
  pci_dev-bus = bus;
  pci_dev-devfn = devfn;
 +
 +if (pci_check_pcie_port(bus, pci_dev)) {
 +return NULL;
 +}
 +
  dma_as = pci_device_iommu_address_space(pci_dev);
  
  memory_region_init_alias(pci_dev-bus_master_enable_region,

Re: [Qemu-devel] [PATCH] block: Make op blockers recursive

[Benoît Canet]

On Mon, Aug 25, 2014 at 02:04:24PM +0800, Fam Zheng wrote:
 On Fri, 08/22 18:11, Benoît Canet wrote:
  Since the block layer code is starting to modify the BDS graph right in the
  middle of BDS chains (block-mirror's replace parameter for example) QEMU 
  needs
  to properly block and unblock whole BDS subtrees; recursion is a neat way to
  achieve this task.
  
  This patch also takes care of modifying the op blockers users.
 
 Is this going to replace backing_blocker?
 
 I think it is too general an approach to control the operation properly,
 because the op blocker may not work in the same way for all types of BDS
 connections.  In other words, the choosing of op blockers are likely
 conditional on graph edge types, that's why backing_blocker was added here. 
 For
 example, A VMDK extent connection will probably need a different set of
 blockers than bs-file connection.
 
 So could you explain in which cases is the recursive blocking/unblocking
 useful?

It's designed for the new crop of block operations operating on BDS located in
the middle of the backing chain: Jeff's patches, intermediate live streaming or
intermediate mirroring.
Recursively blocking BDS allows to do these operations safely.

Best regards

Benoît


 
 Fam
 
  
  Signed-off-by: Benoit Canet benoit.ca...@nodalink.com
  ---
   block.c   | 69 
  ---
   block/blkverify.c | 21 +++
   block/commit.c|  3 +++
   block/mirror.c| 17 
   block/quorum.c| 25 +
   block/stream.c|  3 +++
   block/vmdk.c  | 34 +++
   include/block/block.h |  2 +-
   include/block/block_int.h |  6 +
   9 files changed, 171 insertions(+), 9 deletions(-)
  
  diff --git a/block.c b/block.c
  index 6fa0201..d964b6c 100644
  --- a/block.c
  +++ b/block.c
  @@ -5446,7 +5446,9 @@ bool bdrv_op_is_blocked(BlockDriverState *bs, 
  BlockOpType op, Error **errp)
   return false;
   }
   
  -void bdrv_op_block(BlockDriverState *bs, BlockOpType op, Error *reason)
  +/* do the real work of blocking a BDS */
  +static void bdrv_do_op_block(BlockDriverState *bs, BlockOpType op,
  + Error *reason)
   {
   BdrvOpBlocker *blocker;
   assert((int) op = 0  op  BLOCK_OP_TYPE_MAX);
  @@ -5456,7 +5458,9 @@ void bdrv_op_block(BlockDriverState *bs, BlockOpType 
  op, Error *reason)
   QLIST_INSERT_HEAD(bs-op_blockers[op], blocker, list);
   }
   
  -void bdrv_op_unblock(BlockDriverState *bs, BlockOpType op, Error *reason)
  +/* do the real work of unblocking a BDS */
  +static void bdrv_do_op_unblock(BlockDriverState *bs, BlockOpType op,
  +   Error *reason)
   {
   BdrvOpBlocker *blocker, *next;
   assert((int) op = 0  op  BLOCK_OP_TYPE_MAX);
  @@ -5468,6 +5472,65 @@ void bdrv_op_unblock(BlockDriverState *bs, 
  BlockOpType op, Error *reason)
   }
   }
   
  +static bool bdrv_op_is_blocked_by(BlockDriverState *bs, BlockOpType op,
  +  Error *reason)
  +{
  +BdrvOpBlocker *blocker, *next;
  +assert((int) op = 0  op  BLOCK_OP_TYPE_MAX);
  +QLIST_FOREACH_SAFE(blocker, bs-op_blockers[op], list, next) {
  +if (blocker-reason == reason) {
  +return true;
  +}
  +}
  +return false;
  +}
  +
  +/* block recursively a BDS */
  +void bdrv_op_block(BlockDriverState *bs, BlockOpType op, Error *reason)
  +{
  +if (!bs) {
  +return;
  +}
  +
  +/* prevent recursion loop */
  +if (bdrv_op_is_blocked_by(bs, op, reason)) {
  +return;
  +}
  +
  +/* block first for recursion loop protection to work */
  +bdrv_do_op_block(bs, op, reason);
  +
  +bdrv_op_block(bs-file, op, reason);
  +bdrv_op_block(bs-backing_hd, op, reason);
  +
  +if (bs-drv  bs-drv-bdrv_op_recursive_block) {
  +bs-drv-bdrv_op_recursive_block(bs, op, reason);
  +}
  +}
  +
  +/* unblock recursively a BDS */
  +void bdrv_op_unblock(BlockDriverState *bs, BlockOpType op, Error *reason)
  +{
  +if (!bs) {
  +return;
  +}
  +
  +/* prevent recursion loop */
  +if (!bdrv_op_is_blocked_by(bs, op, reason)) {
  +return;
  +}
  +
  +/* unblock first for recursion loop protection to work */
  +bdrv_do_op_unblock(bs, op, reason);
  +
  +bdrv_op_unblock(bs-file, op, reason);
  +bdrv_op_unblock(bs-backing_hd, op, reason);
  +
  +if (bs-drv  bs-drv-bdrv_op_recursive_unblock) {
  +bs-drv-bdrv_op_recursive_unblock(bs, op, reason);
  +}
  +}
  +
   void bdrv_op_block_all(BlockDriverState *bs, Error *reason)
   {
   int i;
  @@ -5848,7 +5911,7 @@ BlockDriverState *check_to_replace_node(const char 
  *node_name, Error **errp)
   return NULL;
   }
   
  -if (bdrv_op_is_blocked(to_replace_bs, BLOCK_OP_TYPE_REPLACE, errp)) {
  +if 

Re: [Qemu-devel] [PATCH] qemu-iotests: stop using /tmp directly

[Benoît Canet]

The Sunday 24 Aug 2014 à 21:54:51 (+0200), Peter Wu wrote :
 On Friday 22 August 2014 20:58:34 Benoît Canet wrote:
  The Friday 22 Aug 2014 à 13:25:43 (+0200), Peter Wu wrote :
   Before this patch you could not run multiple tests concurrently as they
   might clobber each other test files. This patch solves that by using
   random temporary directory instead of `/tmp` (for writing output in the
   individual tests and valgrind logs).
   
   Furthermore, this patch stops removing everything in `/tmp/` matching a
   certain pattern (`/tmp/*.{err,out,time}`). These might not be a property
   of QEMU.
   
   Running multiple concurrent tests in the same object directory is still
   not supported though as the scratch directory and .bad and .notrun files
   still interfere with each other. Also not touched is the situation that
   /tmp/check.log and /tmp/check.sts are hard-coded (and thus unusable in
   concurrent tests).
   
   Signed-off-by: Peter Wu pe...@lekensteyn.nl
   ---
   Hi,
   
   This patch introduces a dependency on mktemp of coreutils. I could still 
   not get
   concurrent tests to work fully reliably (test 030 failed randomly with 
   QED):
  
  Do we care about the BSDs ?
  
  See the link in the anwser of: 
  http://stackoverflow.com/questions/2792675/how-portable-is-mktemp1
  
  --tmpdir seems to be a GNUism.
 
 And `-t` differs between FreeBSD and others too. There is probably nobody who
 cares about locations other than /tmp, so what about:
 
 QEMU_IOTESTS_TMPDIR=$(mktemp -d /tmp/qemu-iotests.)
 
 What do you think of the idea of the patch in general?

I think it could be usefull for continuous integration setup.

Best regards

Benoît


 
 Kind regards,
 Peter
 https://lekensteyn.nl
 
   FAIL: test_ignore (__main__.TestEIO)
   --
   Traceback (most recent call last):
 File 030, line 223, in test_ignore
   self.assert_qmp(result, 'return[0]/paused', False)
 File /tmp/qemu/tests/qemu-iotests/iotests.py, line 233, in 
   assert_qmp
   result = self.dictpath(d, path)
 File /tmp/qemu/tests/qemu-iotests/iotests.py, line 221, in 
   dictpath
   self.fail('invalid index %s in path %s in %s' % (idx, path, 
   str(d)))
   AssertionError: invalid index 0 in path return[0]/paused in []
   
   I still think that the patches are valuable though, it reduces 
   predictable file
   names.
   
   Kind regards,
   Peter
   ---
tests/qemu-iotests/001   | 2 +-
tests/qemu-iotests/002   | 2 +-
tests/qemu-iotests/003   | 2 +-
tests/qemu-iotests/004   | 2 +-
tests/qemu-iotests/005   | 2 +-
tests/qemu-iotests/006   | 2 +-
tests/qemu-iotests/007   | 2 +-
tests/qemu-iotests/008   | 2 +-
tests/qemu-iotests/009   | 2 +-
tests/qemu-iotests/010   | 2 +-
tests/qemu-iotests/011   | 2 +-
tests/qemu-iotests/012   | 2 +-
tests/qemu-iotests/013   | 2 +-
tests/qemu-iotests/014   | 2 +-
tests/qemu-iotests/015   | 2 +-
tests/qemu-iotests/016   | 2 +-
tests/qemu-iotests/017   | 2 +-
tests/qemu-iotests/018   | 2 +-
tests/qemu-iotests/019   | 2 +-
tests/qemu-iotests/020   | 2 +-
tests/qemu-iotests/021   | 2 +-
tests/qemu-iotests/022   | 2 +-
tests/qemu-iotests/023   | 2 +-
tests/qemu-iotests/024   | 2 +-
tests/qemu-iotests/025   | 2 +-
tests/qemu-iotests/026   | 2 +-
tests/qemu-iotests/027   | 2 +-
tests/qemu-iotests/028   | 2 +-
tests/qemu-iotests/029   | 2 +-
tests/qemu-iotests/031   | 2 +-
tests/qemu-iotests/032   | 2 +-
tests/qemu-iotests/033   | 2 +-
tests/qemu-iotests/034   | 2 +-
tests/qemu-iotests/035   | 2 +-
tests/qemu-iotests/036   | 2 +-
tests/qemu-iotests/037   | 2 +-
tests/qemu-iotests/038   | 2 +-
tests/qemu-iotests/039   | 2 +-
tests/qemu-iotests/042   | 2 +-
tests/qemu-iotests/043   | 2 +-
tests/qemu-iotests/046   | 2 +-
tests/qemu-iotests/047   | 2 +-
tests/qemu-iotests/049   | 2 +-
tests/qemu-iotests/050   | 2 +-
tests/qemu-iotests/051   | 2 +-
tests/qemu-iotests/052   | 2 +-
tests/qemu-iotests/053   | 2 +-
tests/qemu-iotests/054   | 2 +-
tests/qemu-iotests/058   | 2 +-
tests/qemu-iotests/059   | 2 +-
tests/qemu-iotests/060   | 2 +-
tests/qemu-iotests/061   | 2 +-
tests/qemu-iotests/062   | 2 +-
tests/qemu-iotests/063   | 2 +-
tests/qemu-iotests/064   | 2 +-
tests/qemu-iotests/066   | 2 +-
tests/qemu-iotests/067   | 2 +-
tests/qemu-iotests/068   | 2 +-
tests/qemu-iotests/069   | 2 +-
tests/qemu-iotests/070   | 2 +-
tests/qemu-iotests/071   | 2 +-
tests/qemu-iotests/072   | 2 +-

[Qemu-devel] linux-user: enabling binfmt P flag

[Riku Voipio]

Hi,

After weekend, I think the solution to using the P flag is to
go back to Joakim's original patch:

http://lists.gnu.org/archive/html/qemu-devel/2014-07/msg02269.html

With this, we get:

If you continue to use qemu-x-static in your binfmt_misc registration,
nothing changes - both old and new qemu work using the old binfmt
registration.

If you rename the binary qemu-x-binfmt, you need to update the
binfmt_misc register to have P flag and new binary  - you get correct
argv with new qemu. Any old qemu you still have around, will stop
working. But with file not found error rather than obscurely eating
one of the arguments and running regardless.

This leaves us with one case - people who are used to running
qemu-x-static ./binary to test single binaries. Distro's will need
leave a symlink from qemu-x-binfmt qemu-x-static. The -binfmt string
check doesn't trigger, and qemu works as before.

The key point: this way nobody's working setup will break, unless they
update binfmt registration. As long as the change is done by users
them self (I need correct argv0 - I will update binfmt), there is very
little surprise for anyone. 

There will be some fallout once *distributions* change the binfmt - users
will notice their existing qemu chroots stop working with a file not
found error for any binary they try to run.

If we find even this breakage too much, I'm not sure this can be fixed.

Riku

Re: [Qemu-devel] [PATCH v2 4/4] ioh3420: Enable ARI forwarding

[Knut Omang]

On Mon, 2014-08-25 at 06:09 +, Gonglei (Arei) wrote:
  From: Michael S. Tsirkin [mailto:m...@redhat.com]
  Subject: Re: [PATCH v2 4/4] ioh3420: Enable ARI forwarding
  
  On Sun, Aug 24, 2014 at 03:32:20PM +0200, Knut Omang wrote:
   Signed-off-by: Knut Omang knut.om...@oracle.com
  
  BTW pcie_cap_is_arifwd_enabled is still unused.
 
 Not yet, but I have posted a patch series:
 
 [PATCH v2 0/2] add check for PCIe root ports and downstream ports
 
 Which we used this function to check ARI Forwarding is enabled or not.
 I hope you can help me review it, thanks a lot!
 
 BTW, I will rebase my patches on Kunt's patch series. And will do some fixes 
 about Hu Tao's and Marcel Apfelbaum's comments.
 
  We really should use it to make ARI work properly, right?
  
 Yes. I think we should.

Modelling the real world, one way to go with multifunction devices would
be to introduce a separate concept of a PCIFunction object in the
current Qemu model, and let each device have 1 or more such function
objects associated with them. 

The simpler way to implement a true multifunction device would just be
to add one PCIDevice object at the right bus, devfn for each additional
function that are associated with the master device. 

I have implemented the latter approach in a simple SR/IOV emulation
implementation - will post a patch for that shortly, as it seems to be
relevant for this discussion.

With that approach (which came out pleasantly simple wrt changes in the
code) the role of the ARI forwarding bit would be to do nothing when
enabled, as ARI forwarding works with no changes, but make ARI
forwarding, when disabled or not available, makes the additional
functions beyond #8 not addressable from the outside (which in my view
is what a modified version of Gonglei's patch should do)

Knut

 Best regards,
 -Gonglei
 
   ---
hw/pci-bridge/ioh3420.c | 2 ++
1 file changed, 2 insertions(+)
  
   diff --git a/hw/pci-bridge/ioh3420.c b/hw/pci-bridge/ioh3420.c
   index e6674a1..cce2fdd 100644
   --- a/hw/pci-bridge/ioh3420.c
   +++ b/hw/pci-bridge/ioh3420.c
   @@ -85,6 +85,7 @@ static void ioh3420_reset(DeviceState *qdev)
pcie_cap_root_reset(d);
pcie_cap_deverr_reset(d);
pcie_cap_slot_reset(d);
   +pcie_cap_arifwd_reset(d);
pcie_aer_root_reset(d);
pci_bridge_reset(qdev);
pci_bridge_disable_base_limit(d);
   @@ -119,6 +120,7 @@ static int ioh3420_initfn(PCIDevice *d)
goto err_msi;
}
  
   +pcie_cap_arifwd_init(d);
pcie_cap_deverr_init(d);
pcie_cap_slot_init(d, s-slot);
pcie_chassis_create(s-chassis);
   --
   1.9.0
 

Re: [Qemu-devel] linux-user: enabling binfmt P flag

[Alexander Graf]

On 25.08.14 11:09, Riku Voipio wrote:
 Hi,
 
 After weekend, I think the solution to using the P flag is to
 go back to Joakim's original patch:
 
 http://lists.gnu.org/archive/html/qemu-devel/2014-07/msg02269.html
 
 With this, we get:
 
 If you continue to use qemu-x-static in your binfmt_misc registration,
 nothing changes - both old and new qemu work using the old binfmt
 registration.
 
 If you rename the binary qemu-x-binfmt, you need to update the
 binfmt_misc register to have P flag and new binary  - you get correct
 argv with new qemu. Any old qemu you still have around, will stop
 working. But with file not found error rather than obscurely eating
 one of the arguments and running regardless.
 
 This leaves us with one case - people who are used to running
 qemu-x-static ./binary to test single binaries. Distro's will need
 leave a symlink from qemu-x-binfmt qemu-x-static. The -binfmt string
 check doesn't trigger, and qemu works as before.
 
 The key point: this way nobody's working setup will break, unless they
 update binfmt registration. As long as the change is done by users
 them self (I need correct argv0 - I will update binfmt), there is very
 little surprise for anyone. 
 
 There will be some fallout once *distributions* change the binfmt - users
 will notice their existing qemu chroots stop working with a file not
 found error for any binary they try to run.
 
 If we find even this breakage too much, I'm not sure this can be fixed.

I would very much prefer if we could stick with only a single binary.
And yes, switching semantics when you use binfmt wrappers will hurt for
a short while, but after that everyone will have their setups changed
and we're safe for the future.


Alex

Re: [Qemu-devel] [PATCH v2 3/4] ioh3420: Remove obsoleted, unused ioh3420_init function

[Knut Omang]

On Mon, 2014-08-25 at 07:47 +, Gonglei (Arei) wrote:
  -Original Message-
  From: Knut Omang [mailto:knut.om...@oracle.com]
  Sent: Sunday, August 24, 2014 9:32 PM
  To: qemu-devel@nongnu.org
  Cc: Michael S. Tsirkin; Alexey Kardashevskiy; Juan Quintela; Marcel 
  Apfelbaum;
  Markus Armbruster; Paolo Bonzini; Gonglei (Arei); Igor Mammedov; Knut
  Omang
  Subject: [PATCH v2 3/4] ioh3420: Remove obsoleted, unused ioh3420_init
  function
  
  Signed-off-by: Knut Omang knut.om...@oracle.com
  ---
   hw/pci-bridge/ioh3420.c | 24 
   1 file changed, 24 deletions(-)
  
  diff --git a/hw/pci-bridge/ioh3420.c b/hw/pci-bridge/ioh3420.c
  index aed2bf1..e6674a1 100644
  --- a/hw/pci-bridge/ioh3420.c
  +++ b/hw/pci-bridge/ioh3420.c
  @@ -157,30 +157,6 @@ static void ioh3420_exitfn(PCIDevice *d)
   pci_bridge_exitfn(d);
   }
  
  -PCIESlot *ioh3420_init(PCIBus *bus, int devfn, bool multifunction,
  - const char *bus_name, pci_map_irq_fn
  map_irq,
  - uint8_t port, uint8_t chassis, uint16_t slot)
  -{
  -PCIDevice *d;
  -PCIBridge *br;
  -DeviceState *qdev;
  -
  -d = pci_create_multifunction(bus, devfn, multifunction, ioh3420);
  -if (!d) {
  -return NULL;
  -}
  -br = PCI_BRIDGE(d);
  -
  -qdev = DEVICE(d);
  -pci_bridge_map_irq(br, bus_name, map_irq);
  -qdev_prop_set_uint8(qdev, port, port);
  -qdev_prop_set_uint8(qdev, chassis, chassis);
  -qdev_prop_set_uint16(qdev, slot, slot);
  -qdev_init_nofail(qdev);
  -
  -return PCIE_SLOT(d);
  -}
  -
   static Property ioh3420_props[] = {
   DEFINE_PROP_BIT(COMPAT_PROP_PCP, PCIDevice, cap_present,
   QEMU_PCIE_SLTCAP_PCP_BITNR, true),
  --
  1.9.0
 
 That's OK. But the declaration of header file should also be removed.
 I noticed MST have pulled into master tree. So, maybe I can post
 another patch to fix this trivial problem.

Yes, definitely, an obvious mistake from me, sorry.
Don't understand how I could have overlooked that..

Knut

 Best regards,
 -Gonglei

Re: [Qemu-devel] [PATCH] ioh3420: Remove unused ioh3420_init() declaration

[Knut Omang]

On Mon, 2014-08-25 at 15:54 +0800, arei.gong...@huawei.com wrote:
 From: Gonglei arei.gong...@huawei.com
 
 Signed-off-by: Gonglei arei.gong...@huawei.com
 ---
  hw/pci-bridge/ioh3420.h | 4 
  1 file changed, 4 deletions(-)
 
 diff --git a/hw/pci-bridge/ioh3420.h b/hw/pci-bridge/ioh3420.h
 index 7776e5b..ea423cb 100644
 --- a/hw/pci-bridge/ioh3420.h
 +++ b/hw/pci-bridge/ioh3420.h
 @@ -3,8 +3,4 @@
  
  #include hw/pci/pcie_port.h
  
 -PCIESlot *ioh3420_init(PCIBus *bus, int devfn, bool multifunction,
 -   const char *bus_name, pci_map_irq_fn map_irq,
 -   uint8_t port, uint8_t chassis, uint16_t slot);
 -
  #endif /* QEMU_IOH3420_H */

Reviewed-by: Knut Omang knut.om...@oracle.com

Knut

Re: [Qemu-devel] [PATCH 01/15] hw/intc/arm_gic: Request FIQ sources

[Sergey Fedorov]

On 22.08.2014 14:29, Fabian Aggeler wrote:
 Preparing for FIQ lines from GIC to CPUs, which is needed for GIC
 Security Extensions.

 Signed-off-by: Fabian Aggeler aggel...@ethz.ch
 ---
  hw/intc/arm_gic.c| 3 +++
  include/hw/intc/arm_gic_common.h | 1 +
  2 files changed, 4 insertions(+)

 diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
 index 1532ef9..b27bd0e 100644
 --- a/hw/intc/arm_gic.c
 +++ b/hw/intc/arm_gic.c
 @@ -786,6 +786,9 @@ void gic_init_irqs_and_distributor(GICState *s, int 
 num_irq)
  for (i = 0; i  NUM_CPU(s); i++) {
  sysbus_init_irq(sbd, s-parent_irq[i]);
  }
 +for (i = 0; i  NUM_CPU(s); i++) {
 +sysbus_init_irq(sbd, s-parent_fiq[i]);
 +}

Hi Fabian,

I would suggest to provide a way to get a sysbus IRQ/FIQ number for each
processor, e.g. a dedicated macro. Maybe it could be easier to
accomplish this by initializing IRQ and FIQ interleaved or by always
initializing GIC_NCPU IRQs/FIQs.

Regards,
Sergey

  memory_region_init_io(s-iomem, OBJECT(s), gic_dist_ops, s,
gic_dist, 0x1000);
  }
 diff --git a/include/hw/intc/arm_gic_common.h 
 b/include/hw/intc/arm_gic_common.h
 index f6887ed..01c6f24 100644
 --- a/include/hw/intc/arm_gic_common.h
 +++ b/include/hw/intc/arm_gic_common.h
 @@ -50,6 +50,7 @@ typedef struct GICState {
  /* public */
  
  qemu_irq parent_irq[GIC_NCPU];
 +qemu_irq parent_fiq[GIC_NCPU];
  bool enabled;
  bool cpu_enabled[GIC_NCPU];
  

Re: [Qemu-devel] [PATCH 03/15] hw/intc/arm_gic: Add Security Extensions property

[Sergey Fedorov]

On 22.08.2014 14:29, Fabian Aggeler wrote:
 The existing implementation does not support Security Extensions mentioned
 in the GICv1 and GICv2 architecture specification. Security Extensions are
 not available on all GICs. This property makes it possible to enable Security 
 Extensions.

 It also makes GICD_TYPER/ICDICTR.SecurityExtn RAO for GICs which implement
 Security Extensions.

 Signed-off-by: Fabian Aggeler aggel...@ethz.ch
 ---
  hw/intc/arm_gic.c| 5 -
  hw/intc/arm_gic_common.c | 1 +
  include/hw/intc/arm_gic_common.h | 1 +
  3 files changed, 6 insertions(+), 1 deletion(-)

 diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
 index b27bd0e..75b5121 100644
 --- a/hw/intc/arm_gic.c
 +++ b/hw/intc/arm_gic.c
 @@ -297,7 +297,10 @@ static uint32_t gic_dist_readb(void *opaque, hwaddr 
 offset)
  if (offset == 0)
  return s-enabled;
  if (offset == 4)
 -return ((s-num_irq / 32) - 1) | ((NUM_CPU(s) - 1)  5);
 +/* Interrupt Controller Type Register */
 +return ((s-num_irq / 32) - 1)
 +| ((NUM_CPU(s) - 1)  5)
 +| (s-security_extn  10);
  if (offset  0x08)
  return 0;
  if (offset = 0x80) {
 diff --git a/hw/intc/arm_gic_common.c b/hw/intc/arm_gic_common.c
 index 6d884ec..302a056 100644
 --- a/hw/intc/arm_gic_common.c
 +++ b/hw/intc/arm_gic_common.c
 @@ -149,6 +149,7 @@ static Property arm_gic_common_properties[] = {
   * (Internally, 0x also indicates not a GIC but an NVIC.)
   */
  DEFINE_PROP_UINT32(revision, GICState, revision, 1),
 +DEFINE_PROP_UINT8(security-extn, GICState, security_extn, 0),

Why don't use bool type and DEFINE_PROP_BOOL for this field?

Regards,
Sergey.

  DEFINE_PROP_END_OF_LIST(),
  };
  
 diff --git a/include/hw/intc/arm_gic_common.h 
 b/include/hw/intc/arm_gic_common.h
 index 01c6f24..4e25017 100644
 --- a/include/hw/intc/arm_gic_common.h
 +++ b/include/hw/intc/arm_gic_common.h
 @@ -105,6 +105,7 @@ typedef struct GICState {
  MemoryRegion cpuiomem[GIC_NCPU + 1]; /* CPU interfaces */
  uint32_t num_irq;
  uint32_t revision;
 +uint8_t security_extn;
  int dev_fd; /* kvm device fd if backed by kvm vgic support */
  } GICState;
  

Re: [Qemu-devel] [PATCH v2 2/2] pci: add check for pcie root ports and downstream ports

[Gonglei (Arei)]

 -Original Message-
 From: Knut Omang [mailto:knut.om...@oracle.com]
 Subject: Re: [Qemu-devel] [PATCH v2 2/2] pci: add check for pcie root ports 
 and
 downstream ports
 
 On Thu, 2014-08-21 at 17:47 +0800, arei.gong...@huawei.com wrote:
  From: Gonglei arei.gong...@huawei.com
 
  If ARI Forwarding is disabled, according to PCIe spec
  section 7.3.1, only slot 0 with the device attached to
  logic bus representing the link from downstream
  ports and root ports.
 
  So, adding check for PCIe downstream ports and root ports,
  which avoid useless operation, both hotplug and coldplug.
 
  Signed-off-by: Gonglei arei.gong...@huawei.com
  ---
   hw/pci/pci.c | 51
 +++
   1 file changed, 51 insertions(+)
 
  diff --git a/hw/pci/pci.c b/hw/pci/pci.c
  index daeaeac..aa0af0c 100644
  --- a/hw/pci/pci.c
  +++ b/hw/pci/pci.c
  @@ -773,6 +773,52 @@ static int pci_init_multifunction(PCIBus *bus,
 PCIDevice *dev)
   return 0;
   }
 
  +static int pci_check_pcie_port(PCIBus *bus, PCIDevice *dev)
  +{
  +Object *obj = OBJECT(bus);
  +
  +if (pci_bus_is_root(bus)) {
  +return 0;
  +}
  +
  +if (object_dynamic_cast(obj, TYPE_PCIE_BUS)) {
  +DeviceState *parent = qbus_get_parent(BUS(obj));
  +PCIDevice *pci_dev = PCI_DEVICE(parent);
  +uint8_t port_type;
  +/*
  + * Root ports and downstream ports of switches are the hot
  + * pluggable ports in a PCI Express hierarchy.
  + * PCI Express supports chip-to-chip interconnect, a PCIe link can
  + * only connect one pci device/Switch/EndPoint or PCI-bridge.
  + *
  + * 7.3. Configuration Transaction Rules (PCI Express specification
 3.0)
  + * 7.3.1. Device Number
  + *
  + * Downstream Ports that do not have ARI Forwarding enabled
 must
  + * associate only Device 0 with the device attached to the Logical
 Bus
  + * representing the Link from the Port.
  + *
  + * If ARI Forwarding is not enabled on root ports and downstream
  + * ports, only support the devices with slot non-0, regardless of
  + * hotplug or coldplug.
  + */
 
 My interpretation of this section of the spec is that if ARI forwarding
 is not available, only the normal 8 functions can be accessed for each
 device, eg. device/functions 0.0 - 0.7  - if a device has more than 8
 functions, it will need the second device's namespace, eg. devfn 1.0++,
 which would not be routed correctly in a non-ari forward capable device.
 
Yes.

 As far as I understand, with this fix you restrict an non-ARI capable
 switch to only expose one device?
 
Yes. Otherwise it will confuse users who configure a device with 'slot  0 ',
and the interface return OK, but the guest os report errors as below:

[ 159.035250] Pciehp :05:00.0:pcie24: Button pressed on Slot (0 - 4)
[ 159.035274] Pciehp :05:00.0:pcie24: Card present on Slot (0 - 4)
[ 159.036517] Pciehp :05:00.0:pcie24: PCI slot #0 - 4 - powering on due to 
button press.
[ 159.188049] Pciehp :05:00.0:pcie24: Failed to check link status
[ 159.201968] Pciehp :05:00.0:pcie24: Card not present on Slot (0 - 4)
[ 159.202529] Pciehp :05:00.0:pcie24: Already disabled on Slot (0 - 4)

Best regards,
-Gonglei

 Knut
 
  +port_type = pcie_cap_get_type(pci_dev);
  +if (port_type == PCI_EXP_TYPE_DOWNSTREAM ||
  +port_type == PCI_EXP_TYPE_ROOT_PORT) {
  +if (!pcie_cap_is_ari_enabled(pci_dev)) {
  +if (PCI_SLOT(dev-devfn) != 0) {
  +error_report(PCIe: Port's ARI Forwarding is
 disabled, 
  + device can't be populated in
 slot %d,
  + PCI_SLOT(dev-devfn));
  +return -1;
  +}
  +}
  +}
  +}
  +
  +return 0;
  +}
  +
   static void pci_config_alloc(PCIDevice *pci_dev)
   {
   int config_size = pci_config_size(pci_dev);
  @@ -827,6 +873,11 @@ static PCIDevice
 *do_pci_register_device(PCIDevice *pci_dev, PCIBus *bus,
 
   pci_dev-bus = bus;
   pci_dev-devfn = devfn;
  +
  +if (pci_check_pcie_port(bus, pci_dev)) {
  +return NULL;
  +}
  +
   dma_as = pci_device_iommu_address_space(pci_dev);
 
   memory_region_init_alias(pci_dev-bus_master_enable_region,
 

Re: [Qemu-devel] [Fwd: [PATCH v4 07/21] iscsi: Handle failure for potentially large allocations]

[Paolo Bonzini]

Il 24/08/2014 21:31, Peter Lieven ha scritto:
 Am 24.08.2014 um 18:30 schrieb Paolo Bonzini:
 Il 22/08/2014 10:42, Kevin Wolf ha scritto:
 Unfortunately, I missed that one. The zeroblock is typicalls 512 Byte or 
 4K depending
 on the blocksize.
 I don't remember the details, but I think when I went through all
 drivers, I couldn't convince myself that a reasonable block size is
 enforced somewhere. So I just went ahead and converted the call to be on
 the safe side. It can never hurt anyway.
 Yeah, a malicious iSCSI target could have unreasonable block sizes.
 Maybe we should just allow 512b or 4kb blocksize and refuse
 all other?

At least CDs and DVDs use 2kb blocksize. :)

Paolo

Re: [Qemu-devel] [PATCH] block: Make op blockers recursive

[Fam Zheng]

On Mon, 08/25 09:06, Benoît Canet wrote:
 On Mon, Aug 25, 2014 at 02:04:24PM +0800, Fam Zheng wrote:
  On Fri, 08/22 18:11, Benoît Canet wrote:
   Since the block layer code is starting to modify the BDS graph right in 
   the
   middle of BDS chains (block-mirror's replace parameter for example) QEMU 
   needs
   to properly block and unblock whole BDS subtrees; recursion is a neat way 
   to
   achieve this task.
   
   This patch also takes care of modifying the op blockers users.
  
  Is this going to replace backing_blocker?
  
  I think it is too general an approach to control the operation properly,
  because the op blocker may not work in the same way for all types of BDS
  connections.  In other words, the choosing of op blockers are likely
  conditional on graph edge types, that's why backing_blocker was added here. 
  For
  example, A VMDK extent connection will probably need a different set of
  blockers than bs-file connection.
  
  So could you explain in which cases is the recursive blocking/unblocking
  useful?
 
 It's designed for the new crop of block operations operating on BDS located in
 the middle of the backing chain: Jeff's patches, intermediate live streaming 
 or
 intermediate mirroring.
 Recursively blocking BDS allows to do these operations safely.

Sorry I may be slow on this, but it's still not clear to me.

That doesn't immediately show how backing_blocker doesn't work. These
operations are in the category of operations that update graph topology,
meaning that they drop, add or swap some nodes in the middle of the chain. It
is not safe because there are used by the other nodes, but they are supposed to
be protected by backing_blocker. Could you be more specific?

I can think of something more than backing_hd: there are also link types other
than backing_hd, for example -file, (vmdk)-extents or (quorum)-qcrs, etc.
They should be protected as well.

But it seems to me that these are not recursive association, so we don't need
to apply the blocker recursively. Shouldn't it be enough to only block bs-file
when assigning this pointer, and unblock it when unassigning?

I'm not trying to push back this series. I am asking just because that my
understanding to the question still needs some forging.

Fam

Re: [Qemu-devel] [bisected] VNC server can't get all sent chars correctly

[Gerd Hoffmann]

On Sa, 2014-08-23 at 12:56 +0400, Michael Tokarev wrote:
 There's a bug filed against debian qemu package, there:
 
  http://bugs.debian.org/758881
 
 which says about problems sending keypress events over VNC to
 a qemu guest, -- some keypresses gets lost, at least.

 So it looks like something else is not right here.  Before this patch,
 it wasn't possible to use keyboard with VNC client with redhat 5 guest.
 Now, it isn't possible to use keyboard with VNC in another scenario which
 worked before (so it is a regression compared with 2.0 version).

qemu 2.1 hardware emulation is more correct (ps/2 kbd queue size being
16 bytes instead of 256, matching real hardware).  That may trip up
software depending on old, broken behavior.

IMO vncdotool should be fixed to add small delays between keyboard
events, as if a real person is typing, instead of sending the key events
at the maximum possible speed.

I'm sure you can hit the issue with qemu 2.0 too, you just need longer
user input strings to trigger it, so it is less likely to happen.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 03/15] hw/intc/arm_gic: Add Security Extensions property

[Aggeler Fabian]

On 25 Aug 2014, at 11:20, Sergey Fedorov serge.f...@gmail.com wrote:

 On 22.08.2014 14:29, Fabian Aggeler wrote:
 The existing implementation does not support Security Extensions mentioned
 in the GICv1 and GICv2 architecture specification. Security Extensions are
 not available on all GICs. This property makes it possible to enable 
 Security Extensions.
 
 It also makes GICD_TYPER/ICDICTR.SecurityExtn RAO for GICs which implement
 Security Extensions.
 
 Signed-off-by: Fabian Aggeler aggel...@ethz.ch
 ---
 hw/intc/arm_gic.c| 5 -
 hw/intc/arm_gic_common.c | 1 +
 include/hw/intc/arm_gic_common.h | 1 +
 3 files changed, 6 insertions(+), 1 deletion(-)
 
 diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
 index b27bd0e..75b5121 100644
 --- a/hw/intc/arm_gic.c
 +++ b/hw/intc/arm_gic.c
 @@ -297,7 +297,10 @@ static uint32_t gic_dist_readb(void *opaque, hwaddr 
 offset)
 if (offset == 0)
 return s-enabled;
 if (offset == 4)
 -return ((s-num_irq / 32) - 1) | ((NUM_CPU(s) - 1)  5);
 +/* Interrupt Controller Type Register */
 +return ((s-num_irq / 32) - 1)
 +| ((NUM_CPU(s) - 1)  5)
 +| (s-security_extn  10);
 if (offset  0x08)
 return 0;
 if (offset = 0x80) {
 diff --git a/hw/intc/arm_gic_common.c b/hw/intc/arm_gic_common.c
 index 6d884ec..302a056 100644
 --- a/hw/intc/arm_gic_common.c
 +++ b/hw/intc/arm_gic_common.c
 @@ -149,6 +149,7 @@ static Property arm_gic_common_properties[] = {
  * (Internally, 0x also indicates not a GIC but an NVIC.)
  */
 DEFINE_PROP_UINT32(revision, GICState, revision, 1),
 +DEFINE_PROP_UINT8(security-extn, GICState, security_extn, 0),
 
 Why don't use bool type and DEFINE_PROP_BOOL for this field?
 
 Regards,
 Sergey.

I used an uint8 to be able to shift the security_extn field in the return value 
of the
Interrupt Controller Type Register (see above). 

@Edgar: how did you add Virtualization Extensions to the GIC implementation? 
Does it make sense to combine the extensions into one QOM property?

Best,
Fabian

 
 DEFINE_PROP_END_OF_LIST(),
 };
 
 diff --git a/include/hw/intc/arm_gic_common.h 
 b/include/hw/intc/arm_gic_common.h
 index 01c6f24..4e25017 100644
 --- a/include/hw/intc/arm_gic_common.h
 +++ b/include/hw/intc/arm_gic_common.h
 @@ -105,6 +105,7 @@ typedef struct GICState {
 MemoryRegion cpuiomem[GIC_NCPU + 1]; /* CPU interfaces */
 uint32_t num_irq;
 uint32_t revision;
 +uint8_t security_extn;
 int dev_fd; /* kvm device fd if backed by kvm vgic support */
 } GICState;

Re: [Qemu-devel] [PATCH] hw/intc/arm_gic: honor target mask in gic_update()

[Sergey Fedorov]

Ping.

On 13.08.2014 20:31, Sergey Fedorov wrote:
 Take IRQ target mask into account when determining the highest priority
 pending interrupt.

 Signed-off-by: Sergey Fedorov serge.f...@gmail.com
 ---
  hw/intc/arm_gic.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
 index 1532ef9..a5ad7b9 100644
 --- a/hw/intc/arm_gic.c
 +++ b/hw/intc/arm_gic.c
 @@ -66,7 +66,8 @@ void gic_update(GICState *s)
  best_prio = 0x100;
  best_irq = 1023;
  for (irq = 0; irq  s-num_irq; irq++) {
 -if (GIC_TEST_ENABLED(irq, cm)  gic_test_pending(s, irq, cm)) {
 +if (GIC_TEST_ENABLED(irq, cm)  gic_test_pending(s, irq, cm) 
 +(irq  GIC_INTERNAL || GIC_TARGET(irq)  cm)) {
  if (GIC_GET_PRIORITY(irq, cpu)  best_prio) {
  best_prio = GIC_GET_PRIORITY(irq, cpu);
  best_irq = irq;

Re: [Qemu-devel] [PATCH] qemu-iotests: stop using /tmp directly

[Fam Zheng]

On Fri, 08/22 13:25, Peter Wu wrote:
 Before this patch you could not run multiple tests concurrently as they
 might clobber each other test files. This patch solves that by using
 random temporary directory instead of `/tmp` (for writing output in the
 individual tests and valgrind logs).
 
 Furthermore, this patch stops removing everything in `/tmp/` matching a
 certain pattern (`/tmp/*.{err,out,time}`). These might not be a property
 of QEMU.
 
 Running multiple concurrent tests in the same object directory is still
 not supported though as the scratch directory and .bad and .notrun files
 still interfere with each other. Also not touched is the situation that
 /tmp/check.log and /tmp/check.sts are hard-coded (and thus unusable in
 concurrent tests).
 
 Signed-off-by: Peter Wu pe...@lekensteyn.nl
 ---
 Hi,
 
 This patch introduces a dependency on mktemp of coreutils. I could still not 
 get
 concurrent tests to work fully reliably (test 030 failed randomly with QED):
 
 FAIL: test_ignore (__main__.TestEIO)
 --
 Traceback (most recent call last):
   File 030, line 223, in test_ignore
 self.assert_qmp(result, 'return[0]/paused', False)
   File /tmp/qemu/tests/qemu-iotests/iotests.py, line 233, in assert_qmp
 result = self.dictpath(d, path)
   File /tmp/qemu/tests/qemu-iotests/iotests.py, line 221, in dictpath
 self.fail('invalid index %s in path %s in %s' % (idx, path, 
 str(d)))
 AssertionError: invalid index 0 in path return[0]/paused in []
 
 I still think that the patches are valuable though, it reduces predictable 
 file
 names.
 
 Kind regards,
 Peter
 ---
  tests/qemu-iotests/001   | 2 +-
  tests/qemu-iotests/002   | 2 +-
  tests/qemu-iotests/003   | 2 +-
  tests/qemu-iotests/004   | 2 +-
  tests/qemu-iotests/005   | 2 +-
  tests/qemu-iotests/006   | 2 +-
  tests/qemu-iotests/007   | 2 +-
  tests/qemu-iotests/008   | 2 +-
  tests/qemu-iotests/009   | 2 +-
  tests/qemu-iotests/010   | 2 +-
  tests/qemu-iotests/011   | 2 +-
  tests/qemu-iotests/012   | 2 +-
  tests/qemu-iotests/013   | 2 +-
  tests/qemu-iotests/014   | 2 +-
  tests/qemu-iotests/015   | 2 +-
  tests/qemu-iotests/016   | 2 +-
  tests/qemu-iotests/017   | 2 +-
  tests/qemu-iotests/018   | 2 +-
  tests/qemu-iotests/019   | 2 +-
  tests/qemu-iotests/020   | 2 +-
  tests/qemu-iotests/021   | 2 +-
  tests/qemu-iotests/022   | 2 +-
  tests/qemu-iotests/023   | 2 +-
  tests/qemu-iotests/024   | 2 +-
  tests/qemu-iotests/025   | 2 +-
  tests/qemu-iotests/026   | 2 +-
  tests/qemu-iotests/027   | 2 +-
  tests/qemu-iotests/028   | 2 +-
  tests/qemu-iotests/029   | 2 +-
  tests/qemu-iotests/031   | 2 +-
  tests/qemu-iotests/032   | 2 +-
  tests/qemu-iotests/033   | 2 +-
  tests/qemu-iotests/034   | 2 +-
  tests/qemu-iotests/035   | 2 +-
  tests/qemu-iotests/036   | 2 +-
  tests/qemu-iotests/037   | 2 +-
  tests/qemu-iotests/038   | 2 +-
  tests/qemu-iotests/039   | 2 +-
  tests/qemu-iotests/042   | 2 +-
  tests/qemu-iotests/043   | 2 +-
  tests/qemu-iotests/046   | 2 +-
  tests/qemu-iotests/047   | 2 +-
  tests/qemu-iotests/049   | 2 +-
  tests/qemu-iotests/050   | 2 +-
  tests/qemu-iotests/051   | 2 +-
  tests/qemu-iotests/052   | 2 +-
  tests/qemu-iotests/053   | 2 +-
  tests/qemu-iotests/054   | 2 +-
  tests/qemu-iotests/058   | 2 +-
  tests/qemu-iotests/059   | 2 +-
  tests/qemu-iotests/060   | 2 +-
  tests/qemu-iotests/061   | 2 +-
  tests/qemu-iotests/062   | 2 +-
  tests/qemu-iotests/063   | 2 +-
  tests/qemu-iotests/064   | 2 +-
  tests/qemu-iotests/066   | 2 +-
  tests/qemu-iotests/067   | 2 +-
  tests/qemu-iotests/068   | 2 +-
  tests/qemu-iotests/069   | 2 +-
  tests/qemu-iotests/070   | 2 +-
  tests/qemu-iotests/071   | 2 +-
  tests/qemu-iotests/072   | 2 +-
  tests/qemu-iotests/073   | 2 +-
  tests/qemu-iotests/075   | 2 +-
  tests/qemu-iotests/076   | 2 +-
  tests/qemu-iotests/077   | 2 +-
  tests/qemu-iotests/078   | 2 +-
  tests/qemu-iotests/079   | 2 +-
  tests/qemu-iotests/080   | 2 +-
  tests/qemu-iotests/081   | 2 +-
  tests/qemu-iotests/082   | 2 +-
  tests/qemu-iotests/083   | 2 +-
  tests/qemu-iotests/084   | 2 +-
  tests/qemu-iotests/086   | 2 +-
  tests/qemu-iotests/087   | 2 +-
  tests/qemu-iotests/088   | 2 +-
  tests/qemu-iotests/089   | 2 +-
  tests/qemu-iotests/090   | 2 +-
  tests/qemu-iotests/092   | 2 +-
  tests/qemu-iotests/check | 9 ++---
  tests/qemu-iotests/common.rc | 7 ---
  81 files changed, 89 insertions(+), 85 deletions(-)
 
 diff --git a/tests/qemu-iotests/001 b/tests/qemu-iotests/001
 index 4e16469..6472c67 100755
 --- a/tests/qemu-iotests/001
 +++ 

Re: [Qemu-devel] [PATCH] ioh3420: Remove unused ioh3420_init() declaration

[Markus Armbruster]

arei.gong...@huawei.com writes:

 From: Gonglei arei.gong...@huawei.com

 Signed-off-by: Gonglei arei.gong...@huawei.com
 ---
  hw/pci-bridge/ioh3420.h | 4 
  1 file changed, 4 deletions(-)

 diff --git a/hw/pci-bridge/ioh3420.h b/hw/pci-bridge/ioh3420.h
 index 7776e5b..ea423cb 100644
 --- a/hw/pci-bridge/ioh3420.h
 +++ b/hw/pci-bridge/ioh3420.h
 @@ -3,8 +3,4 @@
  
  #include hw/pci/pcie_port.h
  
 -PCIESlot *ioh3420_init(PCIBus *bus, int devfn, bool multifunction,
 -   const char *bus_name, pci_map_irq_fn map_irq,
 -   uint8_t port, uint8_t chassis, uint16_t slot);
 -
  #endif /* QEMU_IOH3420_H */

Breaks the build

qemu/hw/pci-bridge/ioh3420.c:159:11: warning: no previous prototype for 
‘ioh3420_init’ [-Wmissing-prototypes]

because it removes the prototype of an unused function.  Keep both for
future use, or remove both.

Re: [Qemu-devel] [PATCH v2 2/2] pci: add check for pcie root ports and downstream ports

[Knut Omang]

On Mon, 2014-08-25 at 09:23 +, Gonglei (Arei) wrote:
  -Original Message-
  From: Knut Omang [mailto:knut.om...@oracle.com]
  Subject: Re: [Qemu-devel] [PATCH v2 2/2] pci: add check for pcie root ports 
  and
  downstream ports
  
  On Thu, 2014-08-21 at 17:47 +0800, arei.gong...@huawei.com wrote:
   From: Gonglei arei.gong...@huawei.com
  
   If ARI Forwarding is disabled, according to PCIe spec
   section 7.3.1, only slot 0 with the device attached to
   logic bus representing the link from downstream
   ports and root ports.
  
   So, adding check for PCIe downstream ports and root ports,
   which avoid useless operation, both hotplug and coldplug.
  
   Signed-off-by: Gonglei arei.gong...@huawei.com
   ---
hw/pci/pci.c | 51
  +++
1 file changed, 51 insertions(+)
  
   diff --git a/hw/pci/pci.c b/hw/pci/pci.c
   index daeaeac..aa0af0c 100644
   --- a/hw/pci/pci.c
   +++ b/hw/pci/pci.c
   @@ -773,6 +773,52 @@ static int pci_init_multifunction(PCIBus *bus,
  PCIDevice *dev)
return 0;
}
  
   +static int pci_check_pcie_port(PCIBus *bus, PCIDevice *dev)
   +{
   +Object *obj = OBJECT(bus);
   +
   +if (pci_bus_is_root(bus)) {
   +return 0;
   +}
   +
   +if (object_dynamic_cast(obj, TYPE_PCIE_BUS)) {
   +DeviceState *parent = qbus_get_parent(BUS(obj));
   +PCIDevice *pci_dev = PCI_DEVICE(parent);
   +uint8_t port_type;
   +/*
   + * Root ports and downstream ports of switches are the hot
   + * pluggable ports in a PCI Express hierarchy.
   + * PCI Express supports chip-to-chip interconnect, a PCIe link 
   can
   + * only connect one pci device/Switch/EndPoint or PCI-bridge.
   + *
   + * 7.3. Configuration Transaction Rules (PCI Express 
   specification
  3.0)
   + * 7.3.1. Device Number
   + *
   + * Downstream Ports that do not have ARI Forwarding enabled
  must
   + * associate only Device 0 with the device attached to the 
   Logical
  Bus
   + * representing the Link from the Port.
   + *
   + * If ARI Forwarding is not enabled on root ports and downstream
   + * ports, only support the devices with slot non-0, regardless of
   + * hotplug or coldplug.
   + */
  
  My interpretation of this section of the spec is that if ARI forwarding
  is not available, only the normal 8 functions can be accessed for each
  device, eg. device/functions 0.0 - 0.7  - if a device has more than 8
  functions, it will need the second device's namespace, eg. devfn 1.0++,
  which would not be routed correctly in a non-ari forward capable device.
  
 Yes.
 
  As far as I understand, with this fix you restrict an non-ARI capable
  switch to only expose one device?
  
 Yes. Otherwise it will confuse users who configure a device with 'slot  0 ',
 and the interface return OK, but the guest os report errors as below:
 
 [ 159.035250] Pciehp :05:00.0:pcie24: Button pressed on Slot (0 - 4)
 [ 159.035274] Pciehp :05:00.0:pcie24: Card present on Slot (0 - 4)
 [ 159.036517] Pciehp :05:00.0:pcie24: PCI slot #0 - 4 - powering on due 
 to button press.
 [ 159.188049] Pciehp :05:00.0:pcie24: Failed to check link status
 [ 159.201968] Pciehp :05:00.0:pcie24: Card not present on Slot (0 - 4)
 [ 159.202529] Pciehp :05:00.0:pcie24: Already disabled on Slot (0 - 4)

Ah - I see!
I think this also explains why I have been seeing this error and failure
to hotplug recently (with an ARIfwd enabled root port and an ARI capable
device)...

It seems your patch is preventing this from happening in the non-arifwd
case, but will still be a problem with a single ARI capable device if
ARIfwd is enabled, even if no more than one function is exposed by the
device?

Best regards,

Knut

 Best regards,
 -Gonglei
 
  Knut
  
   +port_type = pcie_cap_get_type(pci_dev);
   +if (port_type == PCI_EXP_TYPE_DOWNSTREAM ||
   +port_type == PCI_EXP_TYPE_ROOT_PORT) {
   +if (!pcie_cap_is_ari_enabled(pci_dev)) {
   +if (PCI_SLOT(dev-devfn) != 0) {
   +error_report(PCIe: Port's ARI Forwarding is
  disabled, 
   + device can't be populated in
  slot %d,
   + PCI_SLOT(dev-devfn));
   +return -1;
   +}
   +}
   +}
   +}
   +
   +return 0;
   +}
   +
static void pci_config_alloc(PCIDevice *pci_dev)
{
int config_size = pci_config_size(pci_dev);
   @@ -827,6 +873,11 @@ static PCIDevice
  *do_pci_register_device(PCIDevice *pci_dev, PCIBus *bus,
  
pci_dev-bus = bus;
pci_dev-devfn = devfn;
   +
   +if (pci_check_pcie_port(bus, pci_dev)) {
   +return NULL;
   +}
   +
dma_as = pci_device_iommu_address_space(pci_dev);
  

Re: [Qemu-devel] [Fwd: [PATCH v4 07/21] iscsi: Handle failure for potentially large allocations]

[Peter Lieven]

On 25.08.2014 10:56, Paolo Bonzini wrote:

Il 24/08/2014 21:31, Peter Lieven ha scritto:

Am 24.08.2014 um 18:30 schrieb Paolo Bonzini:

Il 22/08/2014 10:42, Kevin Wolf ha scritto:

Unfortunately, I missed that one. The zeroblock is typicalls 512 Byte or 4K 
depending
on the blocksize.

I don't remember the details, but I think when I went through all
drivers, I couldn't convince myself that a reasonable block size is
enforced somewhere. So I just went ahead and converted the call to be on
the safe side. It can never hurt anyway.

Yeah, a malicious iSCSI target could have unreasonable block sizes.

Maybe we should just allow 512b or 4kb blocksize and refuse
all other?

At least CDs and DVDs use 2kb blocksize. :)


power of 2  = 4096 ?



Paolo

Re: [Qemu-devel] [PATCH 03/15] hw/intc/arm_gic: Add Security Extensions property

[Sergey Fedorov]

On 25.08.2014 13:39, Aggeler Fabian wrote:
 On 25 Aug 2014, at 11:20, Sergey Fedorov serge.f...@gmail.com wrote:

 On 22.08.2014 14:29, Fabian Aggeler wrote:
 The existing implementation does not support Security Extensions mentioned
 in the GICv1 and GICv2 architecture specification. Security Extensions are
 not available on all GICs. This property makes it possible to enable 
 Security Extensions.

 It also makes GICD_TYPER/ICDICTR.SecurityExtn RAO for GICs which implement
 Security Extensions.

 Signed-off-by: Fabian Aggeler aggel...@ethz.ch
 ---
 hw/intc/arm_gic.c| 5 -
 hw/intc/arm_gic_common.c | 1 +
 include/hw/intc/arm_gic_common.h | 1 +
 3 files changed, 6 insertions(+), 1 deletion(-)

 diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
 index b27bd0e..75b5121 100644
 --- a/hw/intc/arm_gic.c
 +++ b/hw/intc/arm_gic.c
 @@ -297,7 +297,10 @@ static uint32_t gic_dist_readb(void *opaque, hwaddr 
 offset)
 if (offset == 0)
 return s-enabled;
 if (offset == 4)
 -return ((s-num_irq / 32) - 1) | ((NUM_CPU(s) - 1)  5);
 +/* Interrupt Controller Type Register */
 +return ((s-num_irq / 32) - 1)
 +| ((NUM_CPU(s) - 1)  5)
 +| (s-security_extn  10);
 if (offset  0x08)
 return 0;
 if (offset = 0x80) {
 diff --git a/hw/intc/arm_gic_common.c b/hw/intc/arm_gic_common.c
 index 6d884ec..302a056 100644
 --- a/hw/intc/arm_gic_common.c
 +++ b/hw/intc/arm_gic_common.c
 @@ -149,6 +149,7 @@ static Property arm_gic_common_properties[] = {
  * (Internally, 0x also indicates not a GIC but an NVIC.)
  */
 DEFINE_PROP_UINT32(revision, GICState, revision, 1),
 +DEFINE_PROP_UINT8(security-extn, GICState, security_extn, 0),
 Why don't use bool type and DEFINE_PROP_BOOL for this field?

 Regards,
 Sergey.
 I used an uint8 to be able to shift the security_extn field in the return 
 value of the
 Interrupt Controller Type Register (see above). 

But uint8 type wouldn't be enough to shift 10 bits left, isn't it?
AFAIU, integer promotion should convert bool to int in this case.

Best,
Sergey


 @Edgar: how did you add Virtualization Extensions to the GIC implementation? 
 Does it make sense to combine the extensions into one QOM property?

 Best,
 Fabian

 DEFINE_PROP_END_OF_LIST(),
 };

 diff --git a/include/hw/intc/arm_gic_common.h 
 b/include/hw/intc/arm_gic_common.h
 index 01c6f24..4e25017 100644
 --- a/include/hw/intc/arm_gic_common.h
 +++ b/include/hw/intc/arm_gic_common.h
 @@ -105,6 +105,7 @@ typedef struct GICState {
 MemoryRegion cpuiomem[GIC_NCPU + 1]; /* CPU interfaces */
 uint32_t num_irq;
 uint32_t revision;
 +uint8_t security_extn;
 int dev_fd; /* kvm device fd if backed by kvm vgic support */
 } GICState;

[Qemu-devel] [RFC PATCH] vmstate: Enable custom migration block name check

[Alexey Kardashevskiy]

This adds a callback to support custom names for migration blocks.

Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---

RFC! not a real patch!

There was a problem a while ago how to migrate sPAPR TCE tables - they
needed unique id + instance_id and there 2 approaches for that:

1. Put them on a virtual made-up TCE bus, LIOBN (logical bus number) is
an unique ID and this would give TCE tables unique names like
liobn@8000/spapr_iommu, instance id would always be 0.

vmstate_spapr_tce_table would be registered via DeviceClass::vmsd pointer.

2. Do not register vmsd via DeviceClass and use explicit call of
vmstate_register() using LIOBN as an instance id. This way TCE tables would
get spapr_iommu name and unique id == LIOBN.

Approach 2 is used by upstream.

Both 1 and 2 were suggested by maintainers :) However with 1 month delay
and I started using 1) in our internal build of powerkvm.

In the current version of our internal powerkvm thing I used 2) as this
is what upstream uses.


The proposed patch is a part of a hack to allow migration
liobn@8000/spapr_iommu + 0  to   spapr_iommu + 8000.


Is this too horrible to be considered as a patch for upstream?
I am not going to push the second part of the hack anyway.

Is there any other way to implement the hack I want without toching these files?

Thanks!


---
 include/migration/vmstate.h | 1 +
 savevm.c| 6 ++
 2 files changed, 7 insertions(+)

diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h
index 2759908..86afd9a 100644
--- a/include/migration/vmstate.h
+++ b/include/migration/vmstate.h
@@ -134,6 +134,7 @@ struct VMStateDescription {
 int (*pre_load)(void *opaque);
 int (*post_load)(void *opaque, int version_id);
 void (*pre_save)(void *opaque);
+bool (*compat_name)(void *opaque, const char *idstr, int instance_id);
 VMStateField *fields;
 const VMStateSubsection *subsections;
 };
diff --git a/savevm.c b/savevm.c
index 22123be..60e7dd8 100644
--- a/savevm.c
+++ b/savevm.c
@@ -731,6 +731,12 @@ static SaveStateEntry *find_se(const char *idstr, int 
instance_id)
  instance_id == se-alias_id))
 return se;
 }
+
+/* Migrating from a weird custom version? */
+if (se-vmsd  se-vmsd-compat_name 
+se-vmsd-compat_name(se-opaque, idstr, instance_id)) {
+return se;
+}
 }
 return NULL;
 }
-- 
2.0.0

Re: [Qemu-devel] [RFC PATCH] vmstate: Enable custom migration block name check

[Alexander Graf]

On 25.08.14 12:22, Alexey Kardashevskiy wrote:
 This adds a callback to support custom names for migration blocks.
 
 Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
 ---
 
 RFC! not a real patch!
 
 There was a problem a while ago how to migrate sPAPR TCE tables - they
 needed unique id + instance_id and there 2 approaches for that:
 
 1. Put them on a virtual made-up TCE bus, LIOBN (logical bus number) is
 an unique ID and this would give TCE tables unique names like
 liobn@8000/spapr_iommu, instance id would always be 0.
 
 vmstate_spapr_tce_table would be registered via DeviceClass::vmsd pointer.
 
 2. Do not register vmsd via DeviceClass and use explicit call of
 vmstate_register() using LIOBN as an instance id. This way TCE tables would
 get spapr_iommu name and unique id == LIOBN.
 
 Approach 2 is used by upstream.
 
 Both 1 and 2 were suggested by maintainers :) However with 1 month delay
 and I started using 1) in our internal build of powerkvm.
 
 In the current version of our internal powerkvm thing I used 2) as this
 is what upstream uses.
 
 
 The proposed patch is a part of a hack to allow migration
 liobn@8000/spapr_iommu + 0  to   spapr_iommu + 8000.
 
 
 Is this too horrible to be considered as a patch for upstream?

Is there any reason you can't keep this patch in your downstream fork
along with the user of it? :)


Alex

Re: [Qemu-devel] [PATCH] ioh3420: Remove unused ioh3420_init() declaration

[Knut Omang]

On Mon, 2014-08-25 at 11:48 +0200, Markus Armbruster wrote:
 arei.gong...@huawei.com writes:
 
  From: Gonglei arei.gong...@huawei.com
 
  Signed-off-by: Gonglei arei.gong...@huawei.com
  ---
   hw/pci-bridge/ioh3420.h | 4 
   1 file changed, 4 deletions(-)
 
  diff --git a/hw/pci-bridge/ioh3420.h b/hw/pci-bridge/ioh3420.h
  index 7776e5b..ea423cb 100644
  --- a/hw/pci-bridge/ioh3420.h
  +++ b/hw/pci-bridge/ioh3420.h
  @@ -3,8 +3,4 @@
   
   #include hw/pci/pcie_port.h
   
  -PCIESlot *ioh3420_init(PCIBus *bus, int devfn, bool multifunction,
  -   const char *bus_name, pci_map_irq_fn map_irq,
  -   uint8_t port, uint8_t chassis, uint16_t slot);
  -
   #endif /* QEMU_IOH3420_H */
 
 Breaks the build
 
 qemu/hw/pci-bridge/ioh3420.c:159:11: warning: no previous prototype for 
 ‘ioh3420_init’ [-Wmissing-prototypes]
 
 because it removes the prototype of an unused function.  Keep both for
 future use, or remove both.

Michael just pulled in my patch 
([PULL 09/11] ioh3420: Remove obsoleted, unused ioh3420_init function)

which removed the definition as a result of the review feedback,
unfortunately I overlooked the declaration in the header file.

Again, sorry for the confusion,

Knut

Re: [Qemu-devel] [PATCH v12 0/6] qcow2, raw: add preallocation=full and preallocation=falloc

[Richard W.M. Jones]

On Mon, Aug 25, 2014 at 01:18:30PM +0800, Hu Tao wrote:
 On Fri, Aug 22, 2014 at 05:00:08PM +0100, Richard W.M. Jones wrote:
  What is proposed to be called 'preallocation=falloc' should fall back
  to other methods (eg. writing random, writing zeroes).  It should
  also be called something more useful like 'preallocation=best'.
 
 What if user cares about time(writing zeroes or non-zeroes is
 time-consuming) and wants falloc only sometimes? I think this is the
 main difference between preallocation=falloc and preallocation=full.

So fallocate fails, and then what?

The user wants something which just works, not something which will
fail inexplicably.  As a rule of thumb, end users and higher layers of
the virt stack have absolutely no idea about the details of what
happens in qemu, and requiring to have this knowledge is impossible.

If it takes too long, that's a performance problem to look into --
fixed by using a filesystem that uses extents.

  What is proposed to be called 'preallocation=full' should not write
  just zeroes.  It needs to write random data since otherwise lower
  layers could discard those writes and that would mean metadata
  allocations could still take time (or fail).  It could also be called
  something more useful, say, 'preallocation=tryveryhard'.
 
 I agree with you on this one, but does it need to be random? does ~0 work?

As I said in the other part of this email, I don't actually think
we should implement such an option.  A simple preallocation option
that just works most of the time is fine.

However since you asked, ~0 will not work.  For a long time SANs have
been able to detect the same data in two blocks and combine them, a
process called 'deduplication'.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

Re: [Qemu-devel] [PATCH 0/2] pflash (UEFI varstore) migration shortcut for libvirt

[Paolo Bonzini]

Il 23/08/2014 12:19, Laszlo Ersek ha scritto:
 Libvirt is growing support for x86_64 OVMF guests:
 
 http://www.redhat.com/archives/libvir-list/2014-August/msg01045.html
 
 An important feature of such guests is the persistent store for
 non-volatile UEFI variables. This is implemented with if=pflash drives.
 The referenced libvirt patchset sets up the varstore files for
 single-host use.
 
 Wrt. migration, two choices have been considered:
 (a) full-blown live storage migration for the drives backing pflash
 devices,
 (b) vs. a shortcut that exploits the special nature of pflash drives
 (namely, their minuscule size, and a RAMBlock that keeps the full
 contents of each pflash drive visible to the guest, and is
 up-to-date, at all times.)
 
 Patch 1/2 is a trivial cleanup (some DPRINTF() calls in pflash_cfi01
 have bit-rotted). Patch 2/2 seeks to implement choice (b), which is what
 the libvirt patchset relies on for migration.
 
 Thanks,
 Laszlo
 
 Laszlo Ersek (2):
   pflash_cfi01: fixup stale DPRINTF() calls
   pflash_cfi01: write flash contents to bdrv on incoming migration
 
  hw/block/pflash_cfi01.c | 18 --
  1 file changed, 16 insertions(+), 2 deletions(-)
 

Reviewed-by: Paolo Bonzini pbonz...@redhat.com

Alexey/David, I think hw/nvram/spapr_nvram.c should do the same.  It
doesn't have a vmstate, but you can probably use
qemu_add_vm_change_state_handler to the same effect.

Paolo

Re: [Qemu-devel] [PATCH 2/2] block/iscsi: handle failure on malloc of the allocationmap

[Paolo Bonzini]

Il 22/08/2014 11:26, Peter Lieven ha scritto:
 Signed-off-by: Peter Lieven p...@kamp.de
 ---
  block/iscsi.c |   22 +++---
  1 file changed, 15 insertions(+), 7 deletions(-)
 
 diff --git a/block/iscsi.c b/block/iscsi.c
 index ed883c3..131357c 100644
 --- a/block/iscsi.c
 +++ b/block/iscsi.c
 @@ -325,6 +325,19 @@ static bool is_request_lun_aligned(int64_t sector_num, 
 int nb_sectors,
  return 1;
  }
  
 +static unsigned long *iscsi_allocationmap_init(IscsiLun *iscsilun)
 +{
 +unsigned long *ptr;
 +ptr = bitmap_try_new(DIV_ROUND_UP(sector_lun2qemu(iscsilun-num_blocks,
 +  iscsilun),
 +  iscsilun-cluster_sectors));
 +if (ptr == NULL) {
 +error_report(iSCSI: could not initialize allocationmap. 
 + Out of memory.);
 +}
 +return ptr;
 +}
 +
  static void iscsi_allocationmap_set(IscsiLun *iscsilun, int64_t sector_num,
  int nb_sectors)
  {
 @@ -1413,9 +1426,7 @@ static int iscsi_open(BlockDriverState *bs, QDict 
 *options, int flags,
  iscsilun-cluster_sectors = (iscsilun-bl.opt_unmap_gran *
   iscsilun-block_size)  
 BDRV_SECTOR_BITS;
  if (iscsilun-lbprz  !(bs-open_flags  BDRV_O_NOCACHE)) {
 -iscsilun-allocationmap =
 -bitmap_new(DIV_ROUND_UP(bs-total_sectors,
 -iscsilun-cluster_sectors));
 +iscsilun-allocationmap = iscsi_allocationmap_init(iscsilun);
  }
  }

iscsi_open has an Error ** argument.  Please pass it to
iscsi_allocationmap_init and use error_setg instead of error_report.


 @@ -1508,10 +1519,7 @@ static int iscsi_truncate(BlockDriverState *bs, 
 int64_t offset)
  
  if (iscsilun-allocationmap != NULL) {
  g_free(iscsilun-allocationmap);
 -iscsilun-allocationmap =
 -bitmap_new(DIV_ROUND_UP(sector_lun2qemu(iscsilun-num_blocks,
 -iscsilun),
 -iscsilun-cluster_sectors));
 +iscsilun-allocationmap = iscsi_allocationmap_init(iscsilun);

Here you may have to use qerror_report_err, though I guess the failure
need not be fatal and you can leave the allocationmap set to NULL.

Paolo

  }
  
  return 0;
 

Re: [Qemu-devel] latest rc: virtio-blk hangs forever after migration

[Paolo Bonzini]

Il 24/08/2014 22:14, Andrey Korolyov ha scritto:
 Forgot to mention, _actual_ patch from above. Adding
 cpu_synchronize_all_states() bringing old bug with lost interrupts
 back.

Are you adding it before or after cpu_clean_all_dirty?

Paolo

[Qemu-devel] [PATCH V3] net: Fix dealing with packets when runstate changes

[zhanghailiang]

For all NICs(except virtio-net) emulated by qemu,
Such as e1000, rtl8139, pcnet and ne2k_pci,
Qemu can still receive packets when VM is not running.
If this happened in *migration's* last PAUSE VM stage,
The new dirty RAM related to the packets will be missed,
And this will lead serious network fault in VM.

To avoid this, we forbid receiving packets in generic net code when
VM is not running. Also, when the runstate changes back to running,
we definitely need to flush queues to get packets flowing again.

Here we implement this in the net layer:
(1) Judge the vm runstate in qemu_can_send_packet
(2) Add a member 'VMChangeStateEntry *vmstate' to struct NICState,
Which will listen for VM runstate changes.
(3) Register a handler function for VMstate change.
When vm changes back to running, we flush all queues in the callback function.
(4) Remove checking vm state in virtio_net_can_receive

Signed-off-by: zhanghailiang zhang.zhanghaili...@huawei.com
---
 v3:
- change the 'vmstate' to 'vm_running'

 v2:
- remove the superfluous check of nc-received_disabled 
---
hw/net/virtio-net.c |  4 
 include/net/net.h   |  2 ++
 net/net.c   | 31 +++
 3 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 268eff9..287d762 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -839,10 +839,6 @@ static int virtio_net_can_receive(NetClientState *nc)
 VirtIODevice *vdev = VIRTIO_DEVICE(n);
 VirtIONetQueue *q = virtio_net_get_subqueue(nc);
 
-if (!vdev-vm_running) {
-return 0;
-}
-
 if (nc-queue_index = n-curr_queues) {
 return 0;
 }
diff --git a/include/net/net.h b/include/net/net.h
index ed594f9..a294277 100644
--- a/include/net/net.h
+++ b/include/net/net.h
@@ -8,6 +8,7 @@
 #include net/queue.h
 #include migration/vmstate.h
 #include qapi-types.h
+#include sysemu/sysemu.h
 
 #define MAX_QUEUE_NUM 1024
 
@@ -96,6 +97,7 @@ typedef struct NICState {
 NICConf *conf;
 void *opaque;
 bool peer_deleted;
+VMChangeStateEntry *vmstate;
 } NICState;
 
 NetClientState *qemu_find_netdev(const char *id);
diff --git a/net/net.c b/net/net.c
index 6d930ea..cb4f48a 100644
--- a/net/net.c
+++ b/net/net.c
@@ -242,6 +242,28 @@ NetClientState *qemu_new_net_client(NetClientInfo *info,
 return nc;
 }
 
+static void nic_vmstate_change_handler(void *opaque,
+   int running,
+   RunState state)
+{
+NICState *nic = opaque;
+NetClientState *nc;
+int i, queues;
+
+if (!running) {
+return;
+}
+
+queues = MAX(1, nic-conf-peers.queues);
+for (i = 0; i  queues; i++) {
+nc = nic-ncs[i];
+if (nc-info-can_receive  !nc-info-can_receive(nc)) {
+continue;
+}
+qemu_flush_queued_packets(nc);
+}
+}
+
 NICState *qemu_new_nic(NetClientInfo *info,
NICConf *conf,
const char *model,
@@ -259,6 +281,8 @@ NICState *qemu_new_nic(NetClientInfo *info,
 nic-ncs = (void *)nic + info-size;
 nic-conf = conf;
 nic-opaque = opaque;
+nic-vmstate = qemu_add_vm_change_state_handler(nic_vmstate_change_handler,
+nic);
 
 for (i = 0; i  queues; i++) {
 qemu_net_client_setup(nic-ncs[i], info, peers[i], model, name,
@@ -379,6 +403,7 @@ void qemu_del_nic(NICState *nic)
 qemu_free_net_client(nc);
 }
 
+qemu_del_vm_change_state_handler(nic-vmstate);
 g_free(nic);
 }
 
@@ -452,6 +477,12 @@ void qemu_set_vnet_hdr_len(NetClientState *nc, int len)
 
 int qemu_can_send_packet(NetClientState *sender)
 {
+int vm_running = runstate_is_running();
+
+if (!vm_running) {
+return 0;
+}
+
 if (!sender-peer) {
 return 1;
 }
-- 
1.7.12.4

Re: [Qemu-devel] [PATCH v2 2/2] pci: add check for pcie root ports and downstream ports

[Gonglei (Arei)]

 From: Knut Omang [mailto:knut.om...@oracle.com]
 Sent: Monday, August 25, 2014 5:51 PM
 Subject: Re: [Qemu-devel] [PATCH v2 2/2] pci: add check for pcie root ports 
 and
 downstream ports
 
 On Mon, 2014-08-25 at 09:23 +, Gonglei (Arei) wrote:
   -Original Message-
   From: Knut Omang [mailto:knut.om...@oracle.com]
   Subject: Re: [Qemu-devel] [PATCH v2 2/2] pci: add check for pcie root 
   ports
 and
   downstream ports
  
   On Thu, 2014-08-21 at 17:47 +0800, arei.gong...@huawei.com wrote:
From: Gonglei arei.gong...@huawei.com
   
If ARI Forwarding is disabled, according to PCIe spec
section 7.3.1, only slot 0 with the device attached to
logic bus representing the link from downstream
ports and root ports.
   
So, adding check for PCIe downstream ports and root ports,
which avoid useless operation, both hotplug and coldplug.
   
Signed-off-by: Gonglei arei.gong...@huawei.com
---
 hw/pci/pci.c | 51
   +++
 1 file changed, 51 insertions(+)
   
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index daeaeac..aa0af0c 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -773,6 +773,52 @@ static int pci_init_multifunction(PCIBus *bus,
   PCIDevice *dev)
 return 0;
 }
   
+static int pci_check_pcie_port(PCIBus *bus, PCIDevice *dev)
+{
+Object *obj = OBJECT(bus);
+
+if (pci_bus_is_root(bus)) {
+return 0;
+}
+
+if (object_dynamic_cast(obj, TYPE_PCIE_BUS)) {
+DeviceState *parent = qbus_get_parent(BUS(obj));
+PCIDevice *pci_dev = PCI_DEVICE(parent);
+uint8_t port_type;
+/*
+ * Root ports and downstream ports of switches are the hot
+ * pluggable ports in a PCI Express hierarchy.
+ * PCI Express supports chip-to-chip interconnect, a PCIe link
 can
+ * only connect one pci device/Switch/EndPoint or PCI-bridge.
+ *
+ * 7.3. Configuration Transaction Rules (PCI Express
 specification
   3.0)
+ * 7.3.1. Device Number
+ *
+ * Downstream Ports that do not have ARI Forwarding
 enabled
   must
+ * associate only Device 0 with the device attached to the
 Logical
   Bus
+ * representing the Link from the Port.
+ *
+ * If ARI Forwarding is not enabled on root ports and
 downstream
+ * ports, only support the devices with slot non-0, regardless
 of
+ * hotplug or coldplug.
+ */
  
   My interpretation of this section of the spec is that if ARI forwarding
   is not available, only the normal 8 functions can be accessed for each
   device, eg. device/functions 0.0 - 0.7  - if a device has more than 8
   functions, it will need the second device's namespace, eg. devfn 1.0++,
   which would not be routed correctly in a non-ari forward capable device.
  
  Yes.
 
   As far as I understand, with this fix you restrict an non-ARI capable
   switch to only expose one device?
  
  Yes. Otherwise it will confuse users who configure a device with 'slot  0 
  ',
  and the interface return OK, but the guest os report errors as below:
 
  [ 159.035250] Pciehp :05:00.0:pcie24: Button pressed on Slot (0 - 4)
  [ 159.035274] Pciehp :05:00.0:pcie24: Card present on Slot (0 - 4)
  [ 159.036517] Pciehp :05:00.0:pcie24: PCI slot #0 - 4 - powering on due
 to button press.
  [ 159.188049] Pciehp :05:00.0:pcie24: Failed to check link status
  [ 159.201968] Pciehp :05:00.0:pcie24: Card not present on Slot (0 - 4)
  [ 159.202529] Pciehp :05:00.0:pcie24: Already disabled on Slot (0 - 4)
 
 Ah - I see!
 I think this also explains why I have been seeing this error and failure
 to hotplug recently (with an ARIfwd enabled root port and an ARI capable
 device)...
 
 It seems your patch is preventing this from happening in the non-arifwd
 case, but will still be a problem with a single ARI capable device if
 ARIfwd is enabled, even if no more than one function is exposed by the
 device?
 
Sorry for my poor English. 
What's your mean about  a single ARI capable device... ?

Best regards,
-Gonglei

Re: [Qemu-devel] latest rc: virtio-blk hangs forever after migration

[Andrey Korolyov]

On Mon, Aug 25, 2014 at 2:45 PM, Paolo Bonzini pbonz...@redhat.com wrote:
 Il 24/08/2014 22:14, Andrey Korolyov ha scritto:
 Forgot to mention, _actual_ patch from above. Adding
 cpu_synchronize_all_states() bringing old bug with lost interrupts
 back.

 Are you adding it before or after cpu_clean_all_dirty?

 Paolo

I`ve added right before, as suggested.

Re: [Qemu-devel] [libvirt] Mentors wanted for Outreach Program for Women October 2014

[Martin Kletzander]

On Thu, Aug 21, 2014 at 09:06:39PM +0100, Stefan Hajnoczi wrote:

Dear mentors and core contributors,
Outreach Program for Women is starting the next round in October 2014.
OPW funds women to work on open source software for 12 weeks with the
help of mentors:
https://wiki.gnome.org/OutreachProgramForWomen/

We just completed a successful round of OPW and Google Summer of Code.
Other organizations have also been participating successfully in OPW
like the Linux kernel with Greg KH and other mentors.

Would you like to mentor in OPW October 2014?



I could use some of my time to help others participate in the
community.


Regular code contributors to QEMU, KVM, and libvirt are eligible to
participate as mentors.

We also need project ideas that are achievable in 12 weeks by someone
skilled in programming but not necessarily familiar with open source
or our codebase.  Ideas welcome!



It's just a matter of ideas.  Maybe we could revisit some of those we
had for GSoC.  If I'm reading the deadline for project ideas is
October 22nd, so I think we'll definitely come up with something.

In first pitch this might be a rewriting of storage driver to handle
jobs (our failed GSoC project from this year), and if admin API gets
added, there will be many APIs and ideas how to expand it.

Martin


Stefan



signature.asc
Description: Digital signature

Re: [Qemu-devel] [PATCH v2 2/2] pci: add check for pcie root ports and downstream ports

[Knut Omang]

On Mon, 2014-08-25 at 10:51 +, Gonglei (Arei) wrote:
  From: Knut Omang [mailto:knut.om...@oracle.com]
  Sent: Monday, August 25, 2014 5:51 PM
  Subject: Re: [Qemu-devel] [PATCH v2 2/2] pci: add check for pcie root ports 
  and
  downstream ports
  
  On Mon, 2014-08-25 at 09:23 +, Gonglei (Arei) wrote:
-Original Message-
From: Knut Omang [mailto:knut.om...@oracle.com]
Subject: Re: [Qemu-devel] [PATCH v2 2/2] pci: add check for pcie root 
ports
  and
downstream ports
   
On Thu, 2014-08-21 at 17:47 +0800, arei.gong...@huawei.com wrote:
 From: Gonglei arei.gong...@huawei.com

 If ARI Forwarding is disabled, according to PCIe spec
 section 7.3.1, only slot 0 with the device attached to
 logic bus representing the link from downstream
 ports and root ports.

 So, adding check for PCIe downstream ports and root ports,
 which avoid useless operation, both hotplug and coldplug.

 Signed-off-by: Gonglei arei.gong...@huawei.com
 ---
  hw/pci/pci.c | 51
+++
  1 file changed, 51 insertions(+)

 diff --git a/hw/pci/pci.c b/hw/pci/pci.c
 index daeaeac..aa0af0c 100644
 --- a/hw/pci/pci.c
 +++ b/hw/pci/pci.c
 @@ -773,6 +773,52 @@ static int pci_init_multifunction(PCIBus *bus,
PCIDevice *dev)
  return 0;
  }

 +static int pci_check_pcie_port(PCIBus *bus, PCIDevice *dev)
 +{
 +Object *obj = OBJECT(bus);
 +
 +if (pci_bus_is_root(bus)) {
 +return 0;
 +}
 +
 +if (object_dynamic_cast(obj, TYPE_PCIE_BUS)) {
 +DeviceState *parent = qbus_get_parent(BUS(obj));
 +PCIDevice *pci_dev = PCI_DEVICE(parent);
 +uint8_t port_type;
 +/*
 + * Root ports and downstream ports of switches are the hot
 + * pluggable ports in a PCI Express hierarchy.
 + * PCI Express supports chip-to-chip interconnect, a PCIe 
 link
  can
 + * only connect one pci device/Switch/EndPoint or PCI-bridge.
 + *
 + * 7.3. Configuration Transaction Rules (PCI Express
  specification
3.0)
 + * 7.3.1. Device Number
 + *
 + * Downstream Ports that do not have ARI Forwarding
  enabled
must
 + * associate only Device 0 with the device attached to the
  Logical
Bus
 + * representing the Link from the Port.
 + *
 + * If ARI Forwarding is not enabled on root ports and
  downstream
 + * ports, only support the devices with slot non-0, 
 regardless
  of
 + * hotplug or coldplug.
 + */
   
My interpretation of this section of the spec is that if ARI forwarding
is not available, only the normal 8 functions can be accessed for each
device, eg. device/functions 0.0 - 0.7  - if a device has more than 8
functions, it will need the second device's namespace, eg. devfn 1.0++,
which would not be routed correctly in a non-ari forward capable device.
   
   Yes.
  
As far as I understand, with this fix you restrict an non-ARI capable
switch to only expose one device?
   
   Yes. Otherwise it will confuse users who configure a device with 'slot  
   0 ',
   and the interface return OK, but the guest os report errors as below:
  
   [ 159.035250] Pciehp :05:00.0:pcie24: Button pressed on Slot (0 - 4)
   [ 159.035274] Pciehp :05:00.0:pcie24: Card present on Slot (0 - 4)
   [ 159.036517] Pciehp :05:00.0:pcie24: PCI slot #0 - 4 - powering on 
   due
  to button press.
   [ 159.188049] Pciehp :05:00.0:pcie24: Failed to check link status
   [ 159.201968] Pciehp :05:00.0:pcie24: Card not present on Slot (0 - 4)
   [ 159.202529] Pciehp :05:00.0:pcie24: Already disabled on Slot (0 - 4)
  
  Ah - I see!
  I think this also explains why I have been seeing this error and failure
  to hotplug recently (with an ARIfwd enabled root port and an ARI capable
  device)...
  
  It seems your patch is preventing this from happening in the non-arifwd
  case, but will still be a problem with a single ARI capable device if
  ARIfwd is enabled, even if no more than one function is exposed by the
  device?
  
 Sorry for my poor English. 
 What's your mean about  a single ARI capable device... ?

I just meant a single device with an ARI PCI express extended
capability, as opposed to the situation you describe (if I understand
right) where there are multiple PCIe devices involved, each in different
slots on the same switch.

This can happen if a device provides a potential for more than 8
functions, and as such cross into the function space of the next
slot, in my case on a root port which physically speaking has only a
single slot, but where the device nonetheless are able to respond to and
send requests on devfn 1.x.

Knut

 Best regards,
 -Gonglei

Re: [Qemu-devel] [PATCH] exec: save exception_index field

[Pavel Dovgaluk]

 From: Andreas Färber [mailto:afaer...@suse.de]
 Am 31.07.2014 07:41, schrieb Pavel Dovgaluk:
  This patch adds subsection with exception_index field to the VMState for
  correct saving the CPU state.
  Without this patch simulator could miss the pending exception in the saved
  virtual machine state.
 
  Signed-off-by: Pavel Dovgalyuk pavel.dovga...@ispras.ru
  ---
   exec.c |   35 +++
   1 files changed, 35 insertions(+), 0 deletions(-)
 
 Doh, this resolves my request from the big series,
 
 Reviewed-by: Andreas Färber afaer...@suse.de
 
 I'll wait for more review before I take it, please keep me CC'ed.

No more reviews yet.
Will this patch be applied?

Pavel Dovgalyuk

Re: [Qemu-devel] linux-user: enabling binfmt P flag

[Joakim Tjernlund]

Alexander Graf ag...@suse.de wrote on 2014/08/25 11:14:58:
 
 On 25.08.14 11:09, Riku Voipio wrote:
  Hi,
  
  After weekend, I think the solution to using the P flag is to
  go back to Joakim's original patch:
  
  http://lists.gnu.org/archive/html/qemu-devel/2014-07/msg02269.html
  
  With this, we get:
  
  If you continue to use qemu-x-static in your binfmt_misc registration,
  nothing changes - both old and new qemu work using the old binfmt
  registration.
  
  If you rename the binary qemu-x-binfmt, you need to update the
  binfmt_misc register to have P flag and new binary  - you get correct
  argv with new qemu. Any old qemu you still have around, will stop
  working. But with file not found error rather than obscurely eating
  one of the arguments and running regardless.
  
  This leaves us with one case - people who are used to running
  qemu-x-static ./binary to test single binaries. Distro's will need
  leave a symlink from qemu-x-binfmt qemu-x-static. The -binfmt string
  check doesn't trigger, and qemu works as before.
  
  The key point: this way nobody's working setup will break, unless they
  update binfmt registration. As long as the change is done by users
  them self (I need correct argv0 - I will update binfmt), there is 
very
  little surprise for anyone. 
  
  There will be some fallout once *distributions* change the binfmt - 
users
  will notice their existing qemu chroots stop working with a file not
  found error for any binary they try to run.
  
  If we find even this breakage too much, I'm not sure this can be 
fixed.
 
 I would very much prefer if we could stick with only a single binary.
 And yes, switching semantics when you use binfmt wrappers will hurt for
 a short while, but after that everyone will have their setups changed
 and we're safe for the future.

Yes, but as this is going to break something whatever we do I feel it is 
better
move towards always requiring P flag as this how binfmt should have been 
impl.
from the beginning and have users switch over now.
Then ask the kernel folks for a way to explicitly see what flags are used
from within linux-user so you can adapt automatically.

 Jocke 

Re: [Qemu-devel] [PATCH v3] trace: [qmp] Add QAPI/QMP commands to query and control event tracing state

[Lluís Vilanova]

Markus Armbruster writes:

 Lluís Vilanova vilan...@ac.upc.edu writes:
 Eric Blake writes:
 
 On 08/21/2014 11:52 AM, Lluís Vilanova wrote:
[...]
 +#
 +# Since 2.2
 +##
 +{ 'command': 'trace-event-set-state',
 +  'data': {'name': 'str', 'state': 'bool', '*keepgoing': 'bool'} }
 
 This only lets me set the state of one name at a time.  Oh, unless I'm
 setting a pattern, and it then sets the state of all names that match
 that pattern.  I'm wondering if you should have 'name':['str'] to allow
 me to set multiple names/patterns in one go, instead of having to call
 the command multiple times; but it's probably not worth the complexity.
 
 I agree with the complexity comment. Also, the keepgoing is useful to set 
 events
 using a pattern, even if some of them are statically disabled (otherwise it
 gives an error).

 Yes, let's keep this simple.

 However, I feel keepgoing is unnecessarily vague.  Its purpose is to
 enable use of a pattern in the presence of disabled events.  I'd prefer
 to nail it down to exactly that purpose rather than having it cover
 arbitrary, unspecified errors.

 A few ideas on how to do that:

 * Have a flag to modify the semantics of the pattern: either match all
   events, or match just disabled and enabled events, not unavailable
   events.

 * To find out what a trace-event-set-state actually does, you need to
   trace-event-get-state the same pattern.  We could make
   trace-event-set-state return the events it changed, so you never have
   to trace-event-get-state, but it's probably not worthwhile.

 [...]

I've renamed it to ignore-unavailable (off by default).


Thanks,
  Lluis

-- 
 And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer.
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth

Re: [Qemu-devel] 9p mapped-* security model infos are architecture-specific

[Michael Tokarev]

I haven't noticed this email - which is almost a month old now - until today.
So replying now...

30.07.2014 21:43, Aneesh Kumar K.V wrote:
 Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com writes:
 
 Michael Tokarev m...@tls.msk.ru writes:

 Apparently the the mapped-* security models results in a raw bytes
 being dumped to host without any architecture normalization (in
 host byte order).  This may even lead to security issues in guest
 when the same files are served from another host for example.

 This bug has been initially submitted against debian qemu package, see
 http://bugs.debian.org/755740


 Thanks for reporting the bug. Yes we do have issue with
 mapped-xattr. But mapped-file should be ok. We record the uid/gid as
 string in the file.
 
 What would be the best way to fix this in a backward compatible way ?
 Considering most of the users will be little endian host, we could do always
 store in little endian format which of-course will break big-endian
 hosts. We could possibly ask them to update xattr using external tools ?

If there's no way to _detect_ the used format (maybe doing some guessing, --
if that's possible to do in a reliable way, it should be good), that's
one of 2 possible options as I see it: that or introduce a new format
entirely, maybe with another attribute name.

It might not be even required to use an external tool for conversion.
Again, if qemu is able to detect wrong endiannes, it might just
update things itself, or print a warning and switch to an old format,
or something like that.

But the guessing idea might not be as bad really.  I haven't looked
closely which information is stored in there, -- but it is possible
that some fields should have zeros in some bytes for example, and
if these aren't zero but becomes zeros after endianness conversion
that might be a good indicator.

I'm not sure the runtime code should be able to work with both formats
at the same time.  Actually, I'm not sure this is a big issue to
start with -- indeed, you said it already, majority of users of 9pfs
should be little endian hosts, -- are there any big endian hosts
using this, at all? :)  How about trying to detect (preferrable at
init time) and refusing to start if old/wrong format is detected.

Maybe have a compile-time define to use native or little endian
format is a good idea too.

Bastian, since you discovered this issue, you might be using
a host with uncommon endianness, what do you think?

Thanks,

/mjt

 diff --git a/hw/9pfs/virtio-9p-local.c b/hw/9pfs/virtio-9p-local.c
 index 3b0b6a9b1d7d..cd662410420e 100644
 --- a/hw/9pfs/virtio-9p-local.c
 +++ b/hw/9pfs/virtio-9p-local.c
 @@ -135,17 +135,17 @@ static int local_lstat(FsContext *fs_ctx, V9fsPath 
 *fs_path, struct stat *stbuf)
  mode_t tmp_mode;
  dev_t tmp_dev;
  if (getxattr(buffer, user.virtfs.uid, tmp_uid, sizeof(uid_t))  
 0) {
 -stbuf-st_uid = tmp_uid;
 +stbuf-st_uid = le32_to_cpu(tmp_uid);
  }
  if (getxattr(buffer, user.virtfs.gid, tmp_gid, sizeof(gid_t))  
 0) {
 -stbuf-st_gid = tmp_gid;
 +stbuf-st_gid = le32_to_cpu(tmp_gid);
  }
  if (getxattr(buffer, user.virtfs.mode,
  tmp_mode, sizeof(mode_t))  0) {
 -stbuf-st_mode = tmp_mode;
 +stbuf-st_mode = le32_to_cpu(tmp_mode);
  }
  if (getxattr(buffer, user.virtfs.rdev, tmp_dev, sizeof(dev_t))  
 0) {
 -stbuf-st_rdev = tmp_dev;
 +stbuf-st_rdev = le64_to_cpu(tmp_dev);
  }
  } else if (fs_ctx-export_flags  V9FS_SM_MAPPED_FILE) {
  local_mapped_file_attr(fs_ctx, path, stbuf);
 @@ -255,29 +255,29 @@ static int local_set_xattr(const char *path, FsCred 
 *credp)
  int err;
  
  if (credp-fc_uid != -1) {
 -err = setxattr(path, user.virtfs.uid, credp-fc_uid, 
 sizeof(uid_t),
 -0);
 +uint32_t tmp_uid = cpu_to_le32(credp-fc_uid);
 +err = setxattr(path, user.virtfs.uid, tmp_uid, sizeof(uid_t), 0);
  if (err) {
  return err;
  }
  }
  if (credp-fc_gid != -1) {
 -err = setxattr(path, user.virtfs.gid, credp-fc_gid, 
 sizeof(gid_t),
 -0);
 +uint32_t tmp_gid = cpu_to_le32(credp-fc_gid);
 +err = setxattr(path, user.virtfs.gid, tmp_gid, sizeof(gid_t), 0);
  if (err) {
  return err;
  }
  }
  if (credp-fc_mode != -1) {
 -err = setxattr(path, user.virtfs.mode, credp-fc_mode,
 -sizeof(mode_t), 0);
 +uint32_t tmp_mode = cpu_to_le32(credp-fc_mode);
 +err = setxattr(path, user.virtfs.mode, tmp_mode, sizeof(mode_t), 
 0);
  if (err) {
  return err;
  }
  }
  if (credp-fc_rdev != -1) {
 -err = setxattr(path, user.virtfs.rdev, credp-fc_rdev,
 -sizeof(dev_t), 0);
 +uint64_t tmp_rdev = cpu_to_le32(credp-fc_rdev);
 +err = 

Re: [Qemu-devel] [RFC PATCH] vmstate: Enable custom migration block name check

[Alexey Kardashevskiy]

On 08/25/2014 08:23 PM, Alexander Graf wrote:
 
 
 On 25.08.14 12:22, Alexey Kardashevskiy wrote:
 This adds a callback to support custom names for migration blocks.

 Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
 ---

 RFC! not a real patch!

 There was a problem a while ago how to migrate sPAPR TCE tables - they
 needed unique id + instance_id and there 2 approaches for that:

 1. Put them on a virtual made-up TCE bus, LIOBN (logical bus number) is
 an unique ID and this would give TCE tables unique names like
 liobn@8000/spapr_iommu, instance id would always be 0.

 vmstate_spapr_tce_table would be registered via DeviceClass::vmsd pointer.

 2. Do not register vmsd via DeviceClass and use explicit call of
 vmstate_register() using LIOBN as an instance id. This way TCE tables would
 get spapr_iommu name and unique id == LIOBN.

 Approach 2 is used by upstream.

 Both 1 and 2 were suggested by maintainers :) However with 1 month delay
 and I started using 1) in our internal build of powerkvm.

 In the current version of our internal powerkvm thing I used 2) as this
 is what upstream uses.


 The proposed patch is a part of a hack to allow migration
 liobn@8000/spapr_iommu + 0  to   spapr_iommu + 8000.


 Is this too horrible to be considered as a patch for upstream?
 
 Is there any reason you can't keep this patch in your downstream fork
 along with the user of it? :)


I can and most likely will. But someone else could benefit from it sometime
later, dunno, there are already manymany callbacks, why not one more :)

But mostly - I actually want to know if what patch does can be done without
it. Enormous amount of callbacks and flags tell me that it is possible, I
am just not smart enough to see it :)



-- 
Alexey

[Qemu-devel] [PATCH v41/2] trace: [qmp] Add commands to query and control event tracing state

[Lluís Vilanova]

Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu
---
 qapi-schema.json|3 ++
 qapi/trace.json |   65 
 qmp-commands.hx |   35 
 trace/Makefile.objs |1 +
 trace/qmp.c |   75 +++
 5 files changed, 179 insertions(+)
 create mode 100644 qapi/trace.json
 create mode 100644 trace/qmp.c

diff --git a/qapi-schema.json b/qapi-schema.json
index 341f417..42b90df 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -11,6 +11,9 @@
 # QAPI event definitions
 { 'include': 'qapi/event.json' }
 
+# Tracing commands
+{ 'include': 'qapi/trace.json' }
+
 ##
 # LostTickPolicy:
 #
diff --git a/qapi/trace.json b/qapi/trace.json
new file mode 100644
index 000..06c613c
--- /dev/null
+++ b/qapi/trace.json
@@ -0,0 +1,65 @@
+# -*- mode: python -*-
+#
+# Copyright (C) 2011-2014 Lluís Vilanova vilan...@ac.upc.edu
+#
+# This work is licensed under the terms of the GNU GPL, version 2 or later.
+# See the COPYING file in the top-level directory.
+
+
+##
+# @TraceEventState:
+#
+# State of a tracing event.
+#
+# @unavailable: The event is statically disabled.
+#
+# @disabled: The event is dynamically disabled.
+#
+# @enabled: The event is dynamically enabled.
+#
+# Since 2.2
+##
+{ 'enum': 'TraceEventState',
+  'data': ['unavailable', 'disabled', 'enabled'] }
+
+##
+# @TraceEventInfo:
+#
+# Information of a tracing event.
+#
+# @name: Event name.
+# @state: Tracing state.
+#
+# Since 2.2
+##
+{ 'type': 'TraceEventInfo',
+  'data': {'name': 'str', 'state': 'TraceEventState'} }
+
+##
+# @trace-event-get-state:
+#
+# Query the state of events.
+#
+# @name: Event name pattern (case-sensitive glob).
+#
+# Returns: a list of @TraceEventInfo for the matching events
+#
+# Since 2.2
+##
+{ 'command': 'trace-event-get-state',
+  'data': {'name': 'str'},
+  'returns': ['TraceEventInfo'] }
+
+##
+# @trace-event-set-state:
+#
+# Set the dynamic tracing state of events.
+#
+# @name: Event name pattern (case-sensitive glob).
+# @enable: Whether to enable tracing.
+# @ignore-unavailable: #optional Do not match unavailable events with @name.
+#
+# Since 2.2
+##
+{ 'command': 'trace-event-set-state',
+  'data': {'name': 'str', 'enable': 'bool', '*ignore-unavailable': 'bool'} }
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 4be4765..b605517 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -3753,5 +3753,40 @@ Example:
 
 - { execute: rtc-reset-reinjection }
 - { return: {} }
+EQMP
+
+{
+.name   = trace-event-get-state,
+.args_type  = name:s,
+.mhandler.cmd_new = qmp_marshal_input_trace_event_get_state,
+},
+
+SQMP
+trace-event-get-state
+-
+
+Query the state of events.
+
+Example:
+
+- { execute: trace-event-get-state, arguments: { name: 
qemu_memalign } }
+- { return: [ { name: qemu_memalign, state: disabled } ] }
+EQMP
+
+{
+.name   = trace-event-set-state,
+.args_type  = name:s,enable:b,ignore-unavailable:b?,
+.mhandler.cmd_new = qmp_marshal_input_trace_event_set_state,
+},
 
+SQMP
+trace-event-set-state
+-
+
+Set the state of events.
+
+Example:
+
+- { execute: trace-event-set-state, arguments: { name: 
qemu_memalign, enable: true } }
+- { return: {} }
 EQMP
diff --git a/trace/Makefile.objs b/trace/Makefile.objs
index 387f191..01b3718 100644
--- a/trace/Makefile.objs
+++ b/trace/Makefile.objs
@@ -145,3 +145,4 @@ util-obj-$(CONFIG_TRACE_FTRACE) += ftrace.o
 util-obj-$(CONFIG_TRACE_UST) += generated-ust.o
 util-obj-y += control.o
 util-obj-y += generated-tracers.o
+util-obj-y += qmp.o
diff --git a/trace/qmp.c b/trace/qmp.c
new file mode 100644
index 000..0b19489
--- /dev/null
+++ b/trace/qmp.c
@@ -0,0 +1,75 @@
+/*
+ * QMP commands for tracing events.
+ *
+ * Copyright (C) 2014 Lluís Vilanova vilan...@ac.upc.edu
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include qemu/typedefs.h
+#include qmp-commands.h
+#include trace/control.h
+
+
+TraceEventInfoList *qmp_trace_event_get_state(const char *name, Error **errp)
+{
+TraceEventInfoList *events = NULL;
+bool found = false;
+TraceEvent *ev;
+
+ev = NULL;
+while ((ev = trace_event_pattern(name, ev)) != NULL) {
+TraceEventInfoList *elem = g_new(TraceEventInfoList, 1);
+elem-value = g_new(TraceEventInfo, 1);
+elem-value-name = g_strdup(trace_event_get_name(ev));
+if (!trace_event_get_state_static(ev)) {
+elem-value-state = TRACE_EVENT_STATE_UNAVAILABLE;
+} else if (!trace_event_get_state_dynamic(ev)) {
+elem-value-state = TRACE_EVENT_STATE_DISABLED;
+} else {
+elem-value-state = TRACE_EVENT_STATE_ENABLED;
+}
+elem-next = events;
+events = elem;
+found = true;
+}
+
+if (!found  

[Qemu-devel] [PATCH v4 1/2] trace: [qmp] Add commands to query and control event tracing state

[Lluís Vilanova]

Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu
---
 qapi-schema.json|3 ++
 qapi/trace.json |   65 
 qmp-commands.hx |   35 
 trace/Makefile.objs |1 +
 trace/qmp.c |   75 +++
 5 files changed, 179 insertions(+)
 create mode 100644 qapi/trace.json
 create mode 100644 trace/qmp.c

diff --git a/qapi-schema.json b/qapi-schema.json
index 341f417..42b90df 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -11,6 +11,9 @@
 # QAPI event definitions
 { 'include': 'qapi/event.json' }
 
+# Tracing commands
+{ 'include': 'qapi/trace.json' }
+
 ##
 # LostTickPolicy:
 #
diff --git a/qapi/trace.json b/qapi/trace.json
new file mode 100644
index 000..06c613c
--- /dev/null
+++ b/qapi/trace.json
@@ -0,0 +1,65 @@
+# -*- mode: python -*-
+#
+# Copyright (C) 2011-2014 Lluís Vilanova vilan...@ac.upc.edu
+#
+# This work is licensed under the terms of the GNU GPL, version 2 or later.
+# See the COPYING file in the top-level directory.
+
+
+##
+# @TraceEventState:
+#
+# State of a tracing event.
+#
+# @unavailable: The event is statically disabled.
+#
+# @disabled: The event is dynamically disabled.
+#
+# @enabled: The event is dynamically enabled.
+#
+# Since 2.2
+##
+{ 'enum': 'TraceEventState',
+  'data': ['unavailable', 'disabled', 'enabled'] }
+
+##
+# @TraceEventInfo:
+#
+# Information of a tracing event.
+#
+# @name: Event name.
+# @state: Tracing state.
+#
+# Since 2.2
+##
+{ 'type': 'TraceEventInfo',
+  'data': {'name': 'str', 'state': 'TraceEventState'} }
+
+##
+# @trace-event-get-state:
+#
+# Query the state of events.
+#
+# @name: Event name pattern (case-sensitive glob).
+#
+# Returns: a list of @TraceEventInfo for the matching events
+#
+# Since 2.2
+##
+{ 'command': 'trace-event-get-state',
+  'data': {'name': 'str'},
+  'returns': ['TraceEventInfo'] }
+
+##
+# @trace-event-set-state:
+#
+# Set the dynamic tracing state of events.
+#
+# @name: Event name pattern (case-sensitive glob).
+# @enable: Whether to enable tracing.
+# @ignore-unavailable: #optional Do not match unavailable events with @name.
+#
+# Since 2.2
+##
+{ 'command': 'trace-event-set-state',
+  'data': {'name': 'str', 'enable': 'bool', '*ignore-unavailable': 'bool'} }
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 4be4765..b605517 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -3753,5 +3753,40 @@ Example:
 
 - { execute: rtc-reset-reinjection }
 - { return: {} }
+EQMP
+
+{
+.name   = trace-event-get-state,
+.args_type  = name:s,
+.mhandler.cmd_new = qmp_marshal_input_trace_event_get_state,
+},
+
+SQMP
+trace-event-get-state
+-
+
+Query the state of events.
+
+Example:
+
+- { execute: trace-event-get-state, arguments: { name: 
qemu_memalign } }
+- { return: [ { name: qemu_memalign, state: disabled } ] }
+EQMP
+
+{
+.name   = trace-event-set-state,
+.args_type  = name:s,enable:b,ignore-unavailable:b?,
+.mhandler.cmd_new = qmp_marshal_input_trace_event_set_state,
+},
 
+SQMP
+trace-event-set-state
+-
+
+Set the state of events.
+
+Example:
+
+- { execute: trace-event-set-state, arguments: { name: 
qemu_memalign, enable: true } }
+- { return: {} }
 EQMP
diff --git a/trace/Makefile.objs b/trace/Makefile.objs
index 387f191..01b3718 100644
--- a/trace/Makefile.objs
+++ b/trace/Makefile.objs
@@ -145,3 +145,4 @@ util-obj-$(CONFIG_TRACE_FTRACE) += ftrace.o
 util-obj-$(CONFIG_TRACE_UST) += generated-ust.o
 util-obj-y += control.o
 util-obj-y += generated-tracers.o
+util-obj-y += qmp.o
diff --git a/trace/qmp.c b/trace/qmp.c
new file mode 100644
index 000..0b19489
--- /dev/null
+++ b/trace/qmp.c
@@ -0,0 +1,75 @@
+/*
+ * QMP commands for tracing events.
+ *
+ * Copyright (C) 2014 Lluís Vilanova vilan...@ac.upc.edu
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include qemu/typedefs.h
+#include qmp-commands.h
+#include trace/control.h
+
+
+TraceEventInfoList *qmp_trace_event_get_state(const char *name, Error **errp)
+{
+TraceEventInfoList *events = NULL;
+bool found = false;
+TraceEvent *ev;
+
+ev = NULL;
+while ((ev = trace_event_pattern(name, ev)) != NULL) {
+TraceEventInfoList *elem = g_new(TraceEventInfoList, 1);
+elem-value = g_new(TraceEventInfo, 1);
+elem-value-name = g_strdup(trace_event_get_name(ev));
+if (!trace_event_get_state_static(ev)) {
+elem-value-state = TRACE_EVENT_STATE_UNAVAILABLE;
+} else if (!trace_event_get_state_dynamic(ev)) {
+elem-value-state = TRACE_EVENT_STATE_DISABLED;
+} else {
+elem-value-state = TRACE_EVENT_STATE_ENABLED;
+}
+elem-next = events;
+events = elem;
+found = true;
+}
+
+if (!found  

Re: [Qemu-devel] [PATCH 2/2] block/iscsi: handle failure on malloc of the allocationmap

[Paolo Bonzini]

Il 25/08/2014 13:10, Peter Lieven ha scritto:
 On 25.08.2014 12:37, Paolo Bonzini wrote:
 Il 22/08/2014 11:26, Peter Lieven ha scritto:
 Signed-off-by: Peter Lieven p...@kamp.de
 ---
   block/iscsi.c |   22 +++---
   1 file changed, 15 insertions(+), 7 deletions(-)

 diff --git a/block/iscsi.c b/block/iscsi.c
 index ed883c3..131357c 100644
 --- a/block/iscsi.c
 +++ b/block/iscsi.c
 @@ -325,6 +325,19 @@ static bool is_request_lun_aligned(int64_t
 sector_num, int nb_sectors,
   return 1;
   }
   +static unsigned long *iscsi_allocationmap_init(IscsiLun *iscsilun)
 +{
 +unsigned long *ptr;
 +ptr =
 bitmap_try_new(DIV_ROUND_UP(sector_lun2qemu(iscsilun-num_blocks,
 +  iscsilun),
 +  iscsilun-cluster_sectors));
 +if (ptr == NULL) {
 +error_report(iSCSI: could not initialize allocationmap. 
 + Out of memory.);
 +}
 +return ptr;
 +}
 +
   static void iscsi_allocationmap_set(IscsiLun *iscsilun, int64_t
 sector_num,
   int nb_sectors)
   {
 @@ -1413,9 +1426,7 @@ static int iscsi_open(BlockDriverState *bs,
 QDict *options, int flags,
   iscsilun-cluster_sectors = (iscsilun-bl.opt_unmap_gran *
iscsilun-block_size) 
 BDRV_SECTOR_BITS;
   if (iscsilun-lbprz  !(bs-open_flags  BDRV_O_NOCACHE)) {
 -iscsilun-allocationmap =
 -bitmap_new(DIV_ROUND_UP(bs-total_sectors,
 -iscsilun-cluster_sectors));
 +iscsilun-allocationmap =
 iscsi_allocationmap_init(iscsilun);
   }
   }
 iscsi_open has an Error ** argument.  Please pass it to
 iscsi_allocationmap_init and use error_setg instead of error_report.
 
 I could pass the Error argument and use error_report only if the pointer
 is null.

No, NULL means I don't care about errors, or I don't care about precise
error messages and will use the return value to check for errors.

 @@ -1508,10 +1519,7 @@ static int iscsi_truncate(BlockDriverState
 *bs, int64_t offset)
 if (iscsilun-allocationmap != NULL) {
   g_free(iscsilun-allocationmap);
 -iscsilun-allocationmap =
 -   
 bitmap_new(DIV_ROUND_UP(sector_lun2qemu(iscsilun-num_blocks,
 -iscsilun),
 -iscsilun-cluster_sectors));
 +iscsilun-allocationmap = iscsi_allocationmap_init(iscsilun);
 Here you may have to use qerror_report_err, though I guess the failure
 need not be fatal and you can leave the allocationmap set to NULL.
 
 That was the plan. I would also not fail on iscsi_open or would you?

Hmm, good question.  If so, the patch is correct with error_report.  I
thought a failure in iscsi_open would be less surprising.  The question
then is, do we need an option to disable allocationmap queries?

Paolo

Re: [Qemu-devel] [PATCH v8 0/5] cpus: Add generic nmi monitor command support

[Paolo Bonzini]

Il 20/08/2014 14:16, Alexey Kardashevskiy ha scritto:
 This adds an nmi monitor command handler per CPUs.
 x86, s390 and ppc CPUS are supported.
 
 Please comment. Thanks.
 
 Changes:
 v8:
 * adjusted commit log for s390 patch
 * fixed missing static in 1/4
 
 v7:
 * fixed typenames, function names, copyrights
 * s390x QOM'ed for later addition of the NMI interface
 * Since none of x86 machines is QOM'ed, postpone migration to new interface 
 for x86
 
 v6:
 * back 5 steps and make it an interface again
 
 v5:
 * added Error** to the callback
 * fixed some comments
 
 v4:
 * now it is not nmi() but nmi_monitor_handler() to avoid confusion
 
 v3:
 * patches reorganized
 * comments from v2 addressed, more details are in individual commit logs
 
 v2:
 * moved from machine interface to CPUClass callback
 * s390 and x86 moved to target-s390/target-i386
 * x86 handler delivers to the current CPU only now
 
 
 
 
 Alexey Kardashevskiy (5):
   cpus: Define callback for QEMU nmi command
   s390x: Convert QEMUMachine to MachineClass
   s390x: Migrate to new NMI interface
   spapr: Add support for new NMI interface
   pc_piix: Migrate to new NMI interface
 
  cpus.c | 31 ++---
  hmp-commands.hx|  6 ++--
  hw/core/Makefile.objs  |  1 +
  hw/core/nmi.c  | 84 
 ++
  hw/i386/pc_piix.c  | 42 +++
  hw/ppc/spapr.c | 21 
  hw/s390x/s390-virtio-ccw.c | 49 ++-
  hw/s390x/s390-virtio.c | 59 ++--
  hw/s390x/s390-virtio.h |  3 ++
  include/hw/nmi.h   | 49 +++
  qapi-schema.json   |  4 +--
  qmp-commands.hx|  3 +-
  target-ppc/cpu-qom.h   |  1 +
  target-ppc/excp_helper.c   |  8 +
  14 files changed, 291 insertions(+), 70 deletions(-)
  create mode 100644 hw/core/nmi.c
  create mode 100644 include/hw/nmi.h
 

Applying patches 1-4 to uq/master.  PC will wait for the QOM machine
conversion.

Paolo

Re: [Qemu-devel] [RFC PATCH v3 07/49] kvmapic: fixing loading vmstate

[Pavel Dovgaluk]

 From: Paolo Bonzini [mailto:pbonz...@redhat.com]
 Il 31/07/2014 17:21, Pavel Dovgalyuk ha scritto:
  Pre load is necessary, because we switched off resetting VM while
  loading in the replay mode.
 
 Then you should not add it now, but rather when you add replay.  Treat
 this part of the series as merely fixing migration bugs.  In fact, I
 suggest that you start by progressively refining these patches.  You can
 also post the other patches that I mentioned were good to go in my
 review of v1.  Then pass to the next steps (in the meanwhile, Fred's
 icount reverse-exec patches might get merged too).

 Do you mean, that I should separate the migration patches from 
the replay ones and submit them in another series?

Pavel Dovgalyuk

Re: [Qemu-devel] [PATCH 2/2] block/iscsi: handle failure on malloc of the allocationmap

[Paolo Bonzini]

Il 25/08/2014 13:26, Peter Lieven ha scritto:

 Hmm, good question.  If so, the patch is correct with error_report.  I
 thought a failure in iscsi_open would be less surprising.  The question
 then is, do we need an option to disable allocationmap queries?
 
 We have cache=none...

Doh, right.  Then I think iscsi_open should fail if it cannot allocate
the map.

Paolo

Re: [Qemu-devel] [RFC PATCH v3 07/49] kvmapic: fixing loading vmstate

[Paolo Bonzini]

Il 25/08/2014 13:40, Pavel Dovgaluk ha scritto:
  Do you mean, that I should separate the migration patches from 
 the replay ones and submit them in another series?

Yes, that will help getting the less controversial pieces in first.

Paolo

Re: [Qemu-devel] [PATCH RESEND 0/2] Fix leaks on object_property_add_str() setters

[Paolo Bonzini]

Il 24/08/2014 13:16, Michael S. Tsirkin ha scritto:
 
 Are these appropriate for 2.1.1?
 Add Cc stable?

I think so.

Paolo

Re: [Qemu-devel] [PATCH] translate-all.c: fix debug memory maps printing

[Paolo Bonzini]

Il 11/08/2014 12:28, Mikhail Ilyin ha scritto:
 Fix memory maps textualizing function. The output was not correct because of
 wrong base address calculation. The initial address has to be shifted also
 for TARGET_PAGE_BITS.
 
 Signed-off-by: Mikhail Ilyin m.i...@samsung.com
 ---
  translate-all.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)
 
 diff --git a/translate-all.c b/translate-all.c
 index 8f7e11b..cb7a33d 100644
 --- a/translate-all.c
 +++ b/translate-all.c
 @@ -1728,9 +1728,8 @@ int walk_memory_regions(void *priv, 
 walk_memory_regions_fn fn)
  data.prot = 0;
  
  for (i = 0; i  V_L1_SIZE; i++) {
 -int rc = walk_memory_regions_1(data, (abi_ulong)i  V_L1_SHIFT,
 +int rc = walk_memory_regions_1(data, (abi_ulong)i  (V_L1_SHIFT + 
 TARGET_PAGE_BITS),
 V_L1_SHIFT / V_L2_BITS - 1, l1_map + 
 i);
 -
  if (rc != 0) {
  return rc;
  }
 

Thanks, this is simple enough that I've queued it.

Paolo

Re: [Qemu-devel] [PATCH] ioh3420: Remove unused ioh3420_init() declaration

[Markus Armbruster]

Knut Omang knut.om...@oracle.com writes:

 On Mon, 2014-08-25 at 11:48 +0200, Markus Armbruster wrote:
 arei.gong...@huawei.com writes:
 
  From: Gonglei arei.gong...@huawei.com
 
  Signed-off-by: Gonglei arei.gong...@huawei.com
  ---
   hw/pci-bridge/ioh3420.h | 4 
   1 file changed, 4 deletions(-)
 
  diff --git a/hw/pci-bridge/ioh3420.h b/hw/pci-bridge/ioh3420.h
  index 7776e5b..ea423cb 100644
  --- a/hw/pci-bridge/ioh3420.h
  +++ b/hw/pci-bridge/ioh3420.h
  @@ -3,8 +3,4 @@
   
   #include hw/pci/pcie_port.h
   
  -PCIESlot *ioh3420_init(PCIBus *bus, int devfn, bool multifunction,
  -   const char *bus_name, pci_map_irq_fn map_irq,
  -   uint8_t port, uint8_t chassis, uint16_t slot);
  -
   #endif /* QEMU_IOH3420_H */
 
 Breaks the build
 
 qemu/hw/pci-bridge/ioh3420.c:159:11: warning: no previous
 prototype for ‘ioh3420_init’ [-Wmissing-prototypes]
 
 because it removes the prototype of an unused function.  Keep both for
 future use, or remove both.

 Michael just pulled in my patch 
 ([PULL 09/11] ioh3420: Remove obsoleted, unused ioh3420_init function)

 which removed the definition as a result of the review feedback,
 unfortunately I overlooked the declaration in the header file.

 Again, sorry for the confusion,

Gonglei, please make sure to state patch prerequisites.  In this case,
you should've pointed to Knut's patch in the commit message.

Re: [Qemu-devel] [PATCH] translate-all.c: fix debug memory maps printing

[Paolo Bonzini]

Il 25/08/2014 13:45, Paolo Bonzini ha scritto:
 Il 11/08/2014 12:28, Mikhail Ilyin ha scritto:
 Fix memory maps textualizing function. The output was not correct because of
 wrong base address calculation. The initial address has to be shifted also
 for TARGET_PAGE_BITS.

 Signed-off-by: Mikhail Ilyin m.i...@samsung.com
 ---
  translate-all.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

 diff --git a/translate-all.c b/translate-all.c
 index 8f7e11b..cb7a33d 100644
 --- a/translate-all.c
 +++ b/translate-all.c
 @@ -1728,9 +1728,8 @@ int walk_memory_regions(void *priv, 
 walk_memory_regions_fn fn)
  data.prot = 0;
  
  for (i = 0; i  V_L1_SIZE; i++) {
 -int rc = walk_memory_regions_1(data, (abi_ulong)i  V_L1_SHIFT,
 +int rc = walk_memory_regions_1(data, (abi_ulong)i  (V_L1_SHIFT + 
 TARGET_PAGE_BITS),
 V_L1_SHIFT / V_L2_BITS - 1, l1_map + 
 i);
 -
  if (rc != 0) {
  return rc;
  }

 
 Thanks, this is simple enough that I've queued it.

Ouch, I spoke too soon.

This patch fails to compile for MIPS N32 (a 32-bit ABI with a 64-bit
virtual address space).  I'm not sure if there is a simple fix.
walk_memory_regions and its user should be changed to use target_ulong
instead of abi_ulong.  access_ok probably needs to be changed in the
same way too.  Riku, do you have any ideas (or free cycles to do the
change)?

Paolo

Re: [Qemu-devel] [PATCH] ioh3420: Remove unused ioh3420_init() declaration

[Gonglei (Arei)]

 From: Markus Armbruster [mailto:arm...@redhat.com]
 Sent: Monday, August 25, 2014 7:51 PM
 Subject: Re: [Qemu-devel] [PATCH] ioh3420: Remove unused ioh3420_init()
 declaration
 
 Knut Omang knut.om...@oracle.com writes:
 
  On Mon, 2014-08-25 at 11:48 +0200, Markus Armbruster wrote:
  arei.gong...@huawei.com writes:
 
   From: Gonglei arei.gong...@huawei.com
  
   Signed-off-by: Gonglei arei.gong...@huawei.com
   ---
hw/pci-bridge/ioh3420.h | 4 
1 file changed, 4 deletions(-)
  
   diff --git a/hw/pci-bridge/ioh3420.h b/hw/pci-bridge/ioh3420.h
   index 7776e5b..ea423cb 100644
   --- a/hw/pci-bridge/ioh3420.h
   +++ b/hw/pci-bridge/ioh3420.h
   @@ -3,8 +3,4 @@
  
#include hw/pci/pcie_port.h
  
   -PCIESlot *ioh3420_init(PCIBus *bus, int devfn, bool multifunction,
   -   const char *bus_name, pci_map_irq_fn
 map_irq,
   -   uint8_t port, uint8_t chassis, uint16_t slot);
   -
#endif /* QEMU_IOH3420_H */
 
  Breaks the build
 
  qemu/hw/pci-bridge/ioh3420.c:159:11: warning: no previous
  prototype for ‘ioh3420_init’ [-Wmissing-prototypes]
 
  because it removes the prototype of an unused function.  Keep both for
  future use, or remove both.
 
  Michael just pulled in my patch
  ([PULL 09/11] ioh3420: Remove obsoleted, unused ioh3420_init function)
 
  which removed the definition as a result of the review feedback,
  unfortunately I overlooked the declaration in the header file.
 
  Again, sorry for the confusion,
 
 Gonglei, please make sure to state patch prerequisites.  In this case,
 you should've pointed to Knut's patch in the commit message.

OK. Thanks for your point, Markus! 
v2 will be post.

Best regards,
-Gonglei

[Qemu-devel] [PATCH] vl: process -object after other backend options

[Paolo Bonzini]

QOM backends can refer to chardevs, but not vice versa.  So
process -chardev and -fsdev options before -object

This fixes the rng-egd backend to virtio-rng.

Reported-by: Amos Kong ak...@redhat.com
Cc: qemu-sta...@nongnu.org
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
 vl.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/vl.c b/vl.c
index b796c67..1d8eb27 100644
--- a/vl.c
+++ b/vl.c
@@ -4033,11 +4033,6 @@ int main(int argc, char **argv, char **envp)
 qemu_set_version(machine_class-hw_version);
 }
 
-if (qemu_opts_foreach(qemu_find_opts(object),
-  object_create, NULL, 0) != 0) {
-exit(1);
-}
-
 /* Init CPU def lists, based on config
  * - Must be called after all the qemu_read_config_file() calls
  * - Must be called before list_cpus()
@@ -4256,6 +4251,11 @@ int main(int argc, char **argv, char **envp)
 exit(1);
 }
 
+if (qemu_opts_foreach(qemu_find_opts(object),
+  object_create, NULL, 0) != 0) {
+exit(1);
+}
+
 configure_accelerator(machine_class);
 
 if (qtest_chrdev) {
-- 
1.8.3.1

[Qemu-devel] [PATCH v2] ioh3420: Remove unused ioh3420_init() declaration

[arei.gonglei]

From: Gonglei arei.gong...@huawei.com

This patch based on Knut's patch:

ioh3420: Remove unused ioh3420_init() declaration

which has been pulled on the fly.

Signed-off-by: Gonglei arei.gong...@huawei.com
Reviewed-by: Knut Omang knut.om...@oracle.com
---
v2:
 - add commit message to state the patch's prerequisites.
 - add 'Reviewed-by' tag
---
 hw/pci-bridge/ioh3420.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/hw/pci-bridge/ioh3420.h b/hw/pci-bridge/ioh3420.h
index 7776e5b..ea423cb 100644
--- a/hw/pci-bridge/ioh3420.h
+++ b/hw/pci-bridge/ioh3420.h
@@ -3,8 +3,4 @@
 
 #include hw/pci/pcie_port.h
 
-PCIESlot *ioh3420_init(PCIBus *bus, int devfn, bool multifunction,
-   const char *bus_name, pci_map_irq_fn map_irq,
-   uint8_t port, uint8_t chassis, uint16_t slot);
-
 #endif /* QEMU_IOH3420_H */
-- 
1.7.12.4

Re: [Qemu-devel] [PATCH 0/6] add dumpdts ability to convert dtb to dts

[Peter Maydell]

On 25 August 2014 05:00, john.liuli john.li...@huawei.com wrote:
 From: Li Liu john.li...@huawei.com

 This patchset let qemu can convert dtb file to dts for two demands:

 Some archtectures may generate the dtb file dynamically through
 qemu device tree functions. So this let it's possiable to dump final
 dtb to dts and save it as a reference.

 For novices to debugging the issues caused by wrong dtb parameters.
 It will be easy to check the dts directly without copying the
 dtb which may be generated by 'dumpdtb' to the PC and dtc or fdtdump
 it.

 The outputed dts format is compatile with 'dtc -I dtb -O dts xxx.dtb'.
 There's a new parameter 'dumpdts' which is similar to 'dumpdtb'. so try
 it like '-machine dumpdts=/tmp/xxx.dts'.

Hi. Thanks for this patchset, but I'm afraid this doesn't
seem to me like something that should be in QEMU.
As you say, you can easily turn the dtb blob into a source file
with dtc. That gets you a definitely-correct disassembly of the
blob, and we don't need to maintain a possibly-buggy
reimplementation of the dtb disassembler in QEMU.

thanks
-- PMM

Re: [Qemu-devel] [PATCH 01/15] hw/intc/arm_gic: Request FIQ sources

[Peter Maydell]

On 25 August 2014 10:16, Sergey Fedorov serge.f...@gmail.com wrote:
 On 22.08.2014 14:29, Fabian Aggeler wrote:
 Preparing for FIQ lines from GIC to CPUs, which is needed for GIC
 Security Extensions.

 Signed-off-by: Fabian Aggeler aggel...@ethz.ch
 ---
  hw/intc/arm_gic.c| 3 +++
  include/hw/intc/arm_gic_common.h | 1 +
  2 files changed, 4 insertions(+)

 diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
 index 1532ef9..b27bd0e 100644
 --- a/hw/intc/arm_gic.c
 +++ b/hw/intc/arm_gic.c
 @@ -786,6 +786,9 @@ void gic_init_irqs_and_distributor(GICState *s, int 
 num_irq)
  for (i = 0; i  NUM_CPU(s); i++) {
  sysbus_init_irq(sbd, s-parent_irq[i]);
  }
 +for (i = 0; i  NUM_CPU(s); i++) {
 +sysbus_init_irq(sbd, s-parent_fiq[i]);
 +}

 Hi Fabian,

 I would suggest to provide a way to get a sysbus IRQ/FIQ number for each
 processor, e.g. a dedicated macro. Maybe it could be easier to
 accomplish this by initializing IRQ and FIQ interleaved or by always
 initializing GIC_NCPU IRQs/FIQs.

Using named GPIO registers is the way to go here,
or at least it will be once Peter C's patchset to make
sysbus IRQs just be legacy syntax for GPIOs goes in.

-- PMM

Re: [Qemu-devel] linux-user: enabling binfmt P flag

[Alexander Graf]

On 25.08.14 14:42, Riku Voipio wrote:
 On Mon, Aug 25, 2014 at 11:14:58AM +0200, Alexander Graf wrote:


 On 25.08.14 11:09, Riku Voipio wrote:
 Hi,

 After weekend, I think the solution to using the P flag is to
 go back to Joakim's original patch:

 http://lists.gnu.org/archive/html/qemu-devel/2014-07/msg02269.html

 With this, we get:

 If you continue to use qemu-x-static in your binfmt_misc registration,
 nothing changes - both old and new qemu work using the old binfmt
 registration.

 If you rename the binary qemu-x-binfmt, you need to update the
 binfmt_misc register to have P flag and new binary  - you get correct
 argv with new qemu. Any old qemu you still have around, will stop
 working. But with file not found error rather than obscurely eating
 one of the arguments and running regardless.

 This leaves us with one case - people who are used to running
 qemu-x-static ./binary to test single binaries. Distro's will need
 leave a symlink from qemu-x-binfmt qemu-x-static. The -binfmt string
 check doesn't trigger, and qemu works as before.

 The key point: this way nobody's working setup will break, unless they
 update binfmt registration. As long as the change is done by users
 them self (I need correct argv0 - I will update binfmt), there is very
 little surprise for anyone. 

 There will be some fallout once *distributions* change the binfmt - users
 will notice their existing qemu chroots stop working with a file not
 found error for any binary they try to run.

 If we find even this breakage too much, I'm not sure this can be fixed.
  
 I would very much prefer if we could stick with only a single binary.
 And yes, switching semantics when you use binfmt wrappers will hurt for
 a short while, but after that everyone will have their setups changed
 and we're safe for the future.
  
 I don't really the unpredictable nature of the breakage. Take 
 $ rm a b c
 
 With P flag:/bin/rm rm a b c
 Without P flag: /bin/rm a b c
 
 If we use old qemu with P flag: qemu will run /bin/rm with argv: /bin/rm rm 
 a b c
  - tries to delete rm
 If we use new qemu without P flag, qemu will run /bin/rm with argv: a b c 
  - fails to delete a
 
 This is the black magic errors that drive users nuts when they try to debug 
 what
 is happening... File not found when the qemu binary is not in the
 right place is confusing enough.

Yes, but is anyone actually using the P flag? We've never advertised
anywhere that QEMU supports it.

Maybe we should just make the next version be 3.0 and declare it a major
ABI breakage ;).


Alex

Re: [Qemu-devel] Bug#758881: [bisected] VNC server can't get all sent chars correctly

[Gabriele Giacone]

[ CC'ing Marc Sibson, vncdotool developer ]

Hi Marc, thread starts at
http://thread.gmane.org/gmane.comp.emulators.qemu/292614

On Mon, Aug 25, 2014 at 11:37 AM, Gerd Hoffmann kra...@redhat.com wrote:
 On Sa, 2014-08-23 at 12:56 +0400, Michael Tokarev wrote:
 There's a bug filed against debian qemu package, there:

  http://bugs.debian.org/758881

 which says about problems sending keypress events over VNC to
 a qemu guest, -- some keypresses gets lost, at least.

 So it looks like something else is not right here.  Before this patch,
 it wasn't possible to use keyboard with VNC client with redhat 5 guest.
 Now, it isn't possible to use keyboard with VNC in another scenario which
 worked before (so it is a regression compared with 2.0 version).

 qemu 2.1 hardware emulation is more correct (ps/2 kbd queue size being
 16 bytes instead of 256, matching real hardware).  That may trip up
 software depending on old, broken behavior.

 IMO vncdotool should be fixed to add small delays between keyboard
 events, as if a real person is typing, instead of sending the key events
 at the maximum possible speed.

 I'm sure you can hit the issue with qemu 2.0 too, you just need longer
 user input strings to trigger it, so it is less likely to happen.

I do confirm some chars don't get received with qemu 2.0 as well, e.g.
by sending insecureinsecure: received string is ecure, first 11
missing.

Thanks,
-- 
G..e

Re: [Qemu-devel] linux-user: enabling binfmt P flag

[Laurent Vivier]

 Le 25 août 2014 à 14:46, Alexander Graf ag...@suse.de a écrit :




 On 25.08.14 14:42, Riku Voipio wrote:
  On Mon, Aug 25, 2014 at 11:14:58AM +0200, Alexander Graf wrote:
 
 
  On 25.08.14 11:09, Riku Voipio wrote:
  Hi,
 
  After weekend, I think the solution to using the P flag is to
  go back to Joakim's original patch:
 
  http://lists.gnu.org/archive/html/qemu-devel/2014-07/msg02269.html
 
  With this, we get:
 
  If you continue to use qemu-x-static in your binfmt_misc registration,
  nothing changes - both old and new qemu work using the old binfmt
  registration.
 
  If you rename the binary qemu-x-binfmt, you need to update the
  binfmt_misc register to have P flag and new binary - you get correct
  argv with new qemu. Any old qemu you still have around, will stop
  working. But with file not found error rather than obscurely eating
  one of the arguments and running regardless.
 
  This leaves us with one case - people who are used to running
  qemu-x-static ./binary to test single binaries. Distro's will need
  leave a symlink from qemu-x-binfmt qemu-x-static. The -binfmt string
  check doesn't trigger, and qemu works as before.
 
  The key point: this way nobody's working setup will break, unless they
  update binfmt registration. As long as the change is done by users
  them self (I need correct argv0 - I will update binfmt), there is very
  little surprise for anyone.
 
  There will be some fallout once *distributions* change the binfmt - users
  will notice their existing qemu chroots stop working with a file not
  found error for any binary they try to run.
 
  If we find even this breakage too much, I'm not sure this can be fixed.
 
  I would very much prefer if we could stick with only a single binary.
  And yes, switching semantics when you use binfmt wrappers will hurt for
  a short while, but after that everyone will have their setups changed
  and we're safe for the future.
 
  I don't really the unpredictable nature of the breakage. Take
  $ rm a b c
 
  With P flag: /bin/rm rm a b c
  Without P flag: /bin/rm a b c
 
  If we use old qemu with P flag: qemu will run /bin/rm with argv: /bin/rm rm
  a b c
  - tries to delete rm
  If we use new qemu without P flag, qemu will run /bin/rm with argv: a b c
  - fails to delete a
 
  This is the black magic errors that drive users nuts when they try to debug
  what
  is happening... File not found when the qemu binary is not in the
  right place is confusing enough.

 Yes, but is anyone actually using the P flag? We've never advertised
 anywhere that QEMU supports it.

 Maybe we should just make the next version be 3.0 and declare it a major
 ABI breakage ;).

You can also add the feature and let's the configure manages if it must be
enabled or not.

Regards,
Laurent

Re: [Qemu-devel] [PATCH v2 5/7] util: Move throttle.c out to top level

[Paolo Bonzini]

Il 22/08/2014 12:54, Fam Zheng ha scritto:
 It is only used by block code and has dependency on timers, so move it
 out to allow util to be linked unconditionally.
 
 Signed-off-by: Fam Zheng f...@redhat.com
 ---
  Makefile.objs | 2 +-
  util/throttle.c = throttle.c | 0
  util/Makefile.objs| 1 -
  3 files changed, 1 insertion(+), 2 deletions(-)
  rename util/throttle.c = throttle.c (100%)
 
 diff --git a/Makefile.objs b/Makefile.objs
 index 97db978..6445ce9 100644
 --- a/Makefile.objs
 +++ b/Makefile.objs
 @@ -7,7 +7,7 @@ util-obj-y = util/ qobject/ qapi/ qapi-types.o qapi-visit.o 
 qapi-event.o
  # block-obj-y is code used by both qemu system emulation and qemu-img
  
  block-obj-y = async.o thread-pool.o
 -block-obj-y += nbd.o block.o blockjob.o
 +block-obj-y += nbd.o block.o blockjob.o throttle.o
  block-obj-y += main-loop.o iohandler.o qemu-timer.o
  block-obj-$(CONFIG_POSIX) += aio-posix.o
  block-obj-$(CONFIG_WIN32) += aio-win32.o
 diff --git a/util/throttle.c b/throttle.c
 similarity index 100%
 rename from util/throttle.c
 rename to throttle.c
 diff --git a/util/Makefile.objs b/util/Makefile.objs
 index 65a36f6..5940acc 100644
 --- a/util/Makefile.objs
 +++ b/util/Makefile.objs
 @@ -10,7 +10,6 @@ util-obj-y += iov.o aes.o qemu-config.o qemu-sockets.o 
 uri.o notify.o
  util-obj-y += qemu-option.o qemu-progress.o
  util-obj-y += hexdump.o
  util-obj-y += crc32c.o
 -util-obj-y += throttle.o
  util-obj-y += getauxval.o
  util-obj-y += readline.o
  util-obj-y += rfifolock.o
 

Reviewed-by: Paolo Bonzini pbonz...@redhat.com

Stefan, would you pick this up in the block branch already?

Paolo

Re: [Qemu-devel] [PATCH 00/35] pc: ACPI memory hotplug

[Anshul Makkar]

Hi,

I am testing memory hotadd/remove functionality for Windows guest
(currently 2012 server). Memory hot remove is not working.

As mentioned in the mail chain, hot remove on Windows is not supported.So
just wanted to check if its still not supported or has been supported or
its a work in progress. If its already been supported or still a work in
progress, please can you share the relevant links/patches.

Sorry, if I have missed any latest patches that support Windows memory hot
remove.

Thanks
Anshul Makkar

On Wed, May 7, 2014 at 11:15 AM, Stefan Priebe - Profihost AG 
s.pri...@profihost.ag wrote:

 ax number of supported DIMM devices 255 (due to ACPI object name
 limit), could be increased creating several containers and putting
 DIMMs there. (exercise for future)

Re: [Qemu-devel] [PATCH 00/35] pc: ACPI memory hotplug

[Paolo Bonzini]

Il 25/08/2014 15:28, Anshul Makkar ha scritto:
 
 I am testing memory hotadd/remove functionality for Windows guest
 (currently 2012 server). Memory hot remove is not working.
 
 As mentioned in the mail chain, hot remove on Windows is not
 supported.So just wanted to check if its still not supported or has been
 supported or its a work in progress. If its already been supported or
 still a work in progress, please can you share the relevant links/patches.
 
 Sorry, if I have missed any latest patches that support Windows memory
 hot remove.

Hot remove is not implemented yet.

Paolo

Re: [Qemu-devel] linux-user: enabling binfmt P flag

[Joakim Tjernlund]

Riku Voipio riku.voi...@iki.fi wrote on 2014/08/25 14:42:57:
 
 On Mon, Aug 25, 2014 at 11:14:58AM +0200, Alexander Graf wrote:
  
  
  On 25.08.14 11:09, Riku Voipio wrote:
   Hi,
   
   After weekend, I think the solution to using the P flag is to
   go back to Joakim's original patch:
   
   http://lists.gnu.org/archive/html/qemu-devel/2014-07/msg02269.html
   
   With this, we get:
   
   If you continue to use qemu-x-static in your binfmt_misc 
registration,
   nothing changes - both old and new qemu work using the old binfmt
   registration.
   
   If you rename the binary qemu-x-binfmt, you need to update the
   binfmt_misc register to have P flag and new binary  - you get 
correct
   argv with new qemu. Any old qemu you still have around, will stop
   working. But with file not found error rather than obscurely 
eating
   one of the arguments and running regardless.
   
   This leaves us with one case - people who are used to running
   qemu-x-static ./binary to test single binaries. Distro's will need
   leave a symlink from qemu-x-binfmt qemu-x-static. The -binfmt 
string
   check doesn't trigger, and qemu works as before.
   
   The key point: this way nobody's working setup will break, unless 
they
   update binfmt registration. As long as the change is done by users
   them self (I need correct argv0 - I will update binfmt), there is 
very
   little surprise for anyone. 
   
   There will be some fallout once *distributions* change the binfmt - 
users
   will notice their existing qemu chroots stop working with a file 
not
   found error for any binary they try to run.
   
   If we find even this breakage too much, I'm not sure this can be 
fixed.
 
  I would very much prefer if we could stick with only a single binary.
  And yes, switching semantics when you use binfmt wrappers will hurt 
for
  a short while, but after that everyone will have their setups changed
  and we're safe for the future.
 
 I don't really the unpredictable nature of the breakage. Take 
 $ rm a b c
 
 With P flag:/bin/rm rm a b c
 Without P flag: /bin/rm a b c
 
 If we use old qemu with P flag: qemu will run /bin/rm with argv: 
/bin/rm rm a b c
  - tries to delete rm
 If we use new qemu without P flag, qemu will run /bin/rm with argv: a b 
c 
  - fails to delete a
 
 This is the black magic errors that drive users nuts when they try to 
debug what
 is happening... File not found when the qemu binary is not in the
 right place is confusing enough.

Then consider when you run a LXC without P flag. bash expects argv0=-bash 
to be a 
login shell and source profile files. This can result in even worse 
black magic errors

Either way stuff may break :(
Oh well, perhaps the binfmt wrapper is the best although then you
will be stuck with the -binfmt magic handling in QEMU for a long time.

 Jocke

Re: [Qemu-devel] [PATCH v12 0/6] qcow2, raw: add preallocation=full and preallocation=falloc

[Richard W.M. Jones]

On Mon, Aug 25, 2014 at 01:18:30PM +0800, Hu Tao wrote:
 What if user cares about time(writing zeroes or non-zeroes is
 time-consuming) and wants falloc only sometimes? I think this is the
 main difference between preallocation=falloc and preallocation=full.

Also posix_fallocate in glibc falls back to writing zeroes when the
kernel/VFS doesn't support a true fallocate.  So I'm afraid your patch
5/6 has a slow path, at least on common Linux distros.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

[Qemu-devel] [PATCH 0/5] target-ppc: Add FWNMI support in QEMU for powerKVM guests

[Aravinda Prasad]

This series of patches add support for fwnmi in powerKVM guests.

Currently upon machine check exception, if the address in
error belongs to guest then KVM invokes guest's NMI interrupt
vector 0x200.

This patch series adds functionality where the guest's 0x200
interrupt vector is patched such that QEMU gets control. QEMU
then builds error log and reports the error to OS registered
machine check handlers through RTAS space.

Apart from this, the patch series also takes care of synchronization
when multiple processors encounter machine check at or about the
same time.

The patch set was tested by simulating a machine check error in
the guest.

---

Aravinda Prasad (5):
  target-ppc: Extend rtas-blob
  target-ppc: Register and handle HCALL to receive updated RTAS region
  target-ppc: Build error log
  target-ppc: Handle ibm,nmi-register RTAS call
  target-ppc: Handle cases when multi-processors get machine-check


 hw/ppc/spapr.c  |   13 ++-
 hw/ppc/spapr_hcall.c|  168 +++
 hw/ppc/spapr_rtas.c |  101 +++
 include/hw/ppc/spapr.h  |   15 +++
 pc-bios/spapr-rtas/spapr-rtas.S |   12 +++
 5 files changed, 301 insertions(+), 8 deletions(-)

-- 
Aravinda Prasad

[Qemu-devel] [PATCH 1/5] target-ppc: Extend rtas-blob

[Aravinda Prasad]

Extend rtas-blob to accommodate error log. Error log
structure is saved in rtas space upon a machine check
exception.

Signed-off-by: Aravinda Prasad aravi...@linux.vnet.ibm.com
---
 hw/ppc/spapr.c  |   13 ++---
 hw/ppc/spapr_rtas.c |4 ++--
 include/hw/ppc/spapr.h  |2 +-
 pc-bios/spapr-rtas/spapr-rtas.S |   12 
 4 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index d01978f..1120988 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -85,6 +85,12 @@
 
 #define HTAB_SIZE(spapr)(1ULL  ((spapr)-htab_shift))
 
+/*
+ * The rtas-entry-offset should match the value specified in
+ * spapr-rtas.S
+ */
+#define RTAS_ENTRY_OFFSET   0x1000
+
 typedef struct sPAPRMachineState sPAPRMachineState;
 
 #define TYPE_SPAPR_MACHINE  spapr-machine
@@ -670,7 +676,8 @@ static int spapr_populate_memory(sPAPREnvironment *spapr, 
void *fdt)
 static void spapr_finalize_fdt(sPAPREnvironment *spapr,
hwaddr fdt_addr,
hwaddr rtas_addr,
-   hwaddr rtas_size)
+   hwaddr rtas_size,
+   hwaddr rtas_entry)
 {
 int ret, i;
 size_t cb = 0;
@@ -705,7 +712,7 @@ static void spapr_finalize_fdt(sPAPREnvironment *spapr,
 }
 
 /* RTAS */
-ret = spapr_rtas_device_tree_setup(fdt, rtas_addr, rtas_size);
+ret = spapr_rtas_device_tree_setup(fdt, rtas_addr, rtas_size, rtas_entry);
 if (ret  0) {
 fprintf(stderr, Couldn't set up RTAS device tree properties\n);
 }
@@ -808,7 +815,7 @@ static void ppc_spapr_reset(void)
 
 /* Load the fdt */
 spapr_finalize_fdt(spapr, spapr-fdt_addr, spapr-rtas_addr,
-   spapr-rtas_size);
+   spapr-rtas_size, spapr-rtas_addr + RTAS_ENTRY_OFFSET);
 
 /* Set up the entry state */
 first_ppc_cpu = POWERPC_CPU(first_cpu);
diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
index 9ba1ba6..02ddbf9 100644
--- a/hw/ppc/spapr_rtas.c
+++ b/hw/ppc/spapr_rtas.c
@@ -328,7 +328,7 @@ void spapr_rtas_register(int token, const char *name, 
spapr_rtas_fn fn)
 }
 
 int spapr_rtas_device_tree_setup(void *fdt, hwaddr rtas_addr,
- hwaddr rtas_size)
+ hwaddr rtas_size, hwaddr rtas_entry)
 {
 int ret;
 int i;
@@ -349,7 +349,7 @@ int spapr_rtas_device_tree_setup(void *fdt, hwaddr 
rtas_addr,
 }
 
 ret = qemu_fdt_setprop_cell(fdt, /rtas, linux,rtas-entry,
-rtas_addr);
+rtas_entry);
 if (ret  0) {
 fprintf(stderr, Couldn't add linux,rtas-entry property: %s\n,
 fdt_strerror(ret));
diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index bbba51a..dedfa67 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -436,7 +436,7 @@ target_ulong spapr_rtas_call(PowerPCCPU *cpu, 
sPAPREnvironment *spapr,
  uint32_t token, uint32_t nargs, target_ulong args,
  uint32_t nret, target_ulong rets);
 int spapr_rtas_device_tree_setup(void *fdt, hwaddr rtas_addr,
- hwaddr rtas_size);
+ hwaddr rtas_size, hwaddr rtas_entry);
 
 #define SPAPR_TCE_PAGE_SHIFT   12
 #define SPAPR_TCE_PAGE_SIZE(1ULL  SPAPR_TCE_PAGE_SHIFT)
diff --git a/pc-bios/spapr-rtas/spapr-rtas.S b/pc-bios/spapr-rtas/spapr-rtas.S
index 903bec2..8c9b17e 100644
--- a/pc-bios/spapr-rtas/spapr-rtas.S
+++ b/pc-bios/spapr-rtas/spapr-rtas.S
@@ -30,6 +30,18 @@
 
 .globl _start
 _start:
+   /*
+* Reserve space for error log in RTAS blob.
+*
+* Either we can reserve initial bytes for error log followed by
+* rtas-entry or space can be reserved after rtas-entry. I prefer
+* former, as we already have rtas-base and rtas-entry (currently
+* both pointing to rtas-base) defined in qemu and we can update
+* rtas-entry to point to an offset from rtas-base. This avoids
+* unnecessary definition of rtas-error-offset while keeping
+* rtas-entry redundant.
+*/
+   . = 0x1000
mr  4,3
lis 3,KVMPPC_H_RTAS@h
ori 3,3,KVMPPC_H_RTAS@l

[Qemu-devel] [PATCH 5/5] target-ppc: Handle cases when multi-processors get machine-check

[Aravinda Prasad]

It is possible for multi-processors to experience machine
check at or about the same time. As per PAPR, subsequent
processors serialize waiting for the first processor to
issue the ibm,nmi-interlock call.

The second processor retries if the first processor which
received a machine check is still reading the error log
and is yet to issue ibm,nmi-interlock call.

This patch implements this functionality.

Signed-off-by: Aravinda Prasad aravi...@linux.vnet.ibm.com
---
 hw/ppc/spapr_hcall.c |   13 +
 hw/ppc/spapr_rtas.c  |8 +++-
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index be063f4..542d0b7 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -94,6 +94,9 @@ struct rtas_mc_log {
 struct rtas_error_log err_log;
 };
 
+/* Whether machine check handling is in progress by any CPU */
+bool mc_in_progress;
+
 static void do_spr_sync(void *arg)
 {
 struct SPRSyncState *s = arg;
@@ -674,6 +677,16 @@ static target_ulong h_report_mc_err(PowerPCCPU *cpu, 
sPAPREnvironment *spapr,
 PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
 
 /*
+ * No need for lock. Only one thread can be executing
+ * inside an hcall
+ */
+if (mc_in_progress == 1) {
+return 0;
+}
+
+mc_in_progress = 1;
+
+/*
  * We save the original r3 register in SPRG2 in 0x200 vector,
  * which is patched during call to ibm.nmi-register. Original
  * r3 is required to be included in error log
diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
index 1135d2b..8fe4db2 100644
--- a/hw/ppc/spapr_rtas.c
+++ b/hw/ppc/spapr_rtas.c
@@ -36,6 +36,8 @@
 
 #include libfdt.h
 
+extern bool mc_in_progress;
+
 static void rtas_display_character(PowerPCCPU *cpu, sPAPREnvironment *spapr,
uint32_t token, uint32_t nargs,
target_ulong args,
@@ -303,6 +305,9 @@ static void rtas_ibm_nmi_register(PowerPCCPU *cpu,
 0x6063f004,/* ori r3,r3,f004  */
 /* Issue H_CALL */
 0x4422,/*  sc  1 */
+0x2fa3,/* cmplwi r3,0 */
+0x409e0008,/* bne continue */
+0x4800020a,/* retry KVMPPC_H_REPORT_ERR */
 0x7c9243a6,/* mtspr r4 sprg2 */
 0xe883,/* ld r4, 0(r3) */
 0x7c9a03a6,/* mtspr r4, srr0 */
@@ -333,7 +338,7 @@ static void rtas_ibm_nmi_register(PowerPCCPU *cpu,
  * machine check address requested by OS
  */
 branch_inst |= guest_machine_check_addr;
-memcpy(trampoline[11], branch_inst, sizeof(branch_inst));
+memcpy(trampoline[14], branch_inst, sizeof(branch_inst));
 
 /* Handle all Host/Guest LE/BE combinations */
 if ((*pcc-interrupts_big_endian)(cpu)) {
@@ -359,6 +364,7 @@ static void rtas_ibm_nmi_interlock(PowerPCCPU *cpu,
target_ulong args,
uint32_t nret, target_ulong rets)
 {
+mc_in_progress = 0;
 rtas_st(rets, 0, RTAS_OUT_SUCCESS);
 }
 

[Qemu-devel] [PATCH 4/5] target-ppc: Handle ibm, nmi-register RTAS call

[Aravinda Prasad]

This patch adds FWNMI support in qemu for powerKVM
guests by handling the ibm,nmi-register rtas call.
Whenever OS issues ibm,nmi-register RTAS call, the
machine check notification address is saved and the
machine check interrupt vector 0x200 is patched to
issue a private hcall.

Signed-off-by: Aravinda Prasad aravi...@linux.vnet.ibm.com
---
 hw/ppc/spapr_rtas.c|   91 
 include/hw/ppc/spapr.h |8 
 2 files changed, 98 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
index 02ddbf9..1135d2b 100644
--- a/hw/ppc/spapr_rtas.c
+++ b/hw/ppc/spapr_rtas.c
@@ -277,6 +277,91 @@ static void rtas_ibm_set_system_parameter(PowerPCCPU *cpu,
 rtas_st(rets, 0, ret);
 }
 
+static void rtas_ibm_nmi_register(PowerPCCPU *cpu,
+  sPAPREnvironment *spapr,
+  uint32_t token, uint32_t nargs,
+  target_ulong args,
+  uint32_t nret, target_ulong rets)
+{
+int i;
+uint32_t branch_inst = 0x4802;
+target_ulong guest_machine_check_addr;
+PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
+/*
+ * Trampoline saves r3 in sprg2 and issues private hcall
+ * to request qemu to build error log. QEMU builds the
+ * error log, copies to rtas-blob and returns the address.
+ * The initial 16 bytes in rtas-blob consists of saved srr0
+ * and srr1 which we restore and pass on the actual error
+ * log address to OS handled mcachine check notification
+ * routine
+ */
+uint32_t trampoline[] = {
+0x7c7243a6,/* mtspr   SPRN_SPRG2,r3 */
+0x3860,/* li  r3,0   */
+/* 0xf004 is the KVMPPC_H_REPORT_ERR private HCALL */
+0x6063f004,/* ori r3,r3,f004  */
+/* Issue H_CALL */
+0x4422,/*  sc  1 */
+0x7c9243a6,/* mtspr r4 sprg2 */
+0xe883,/* ld r4, 0(r3) */
+0x7c9a03a6,/* mtspr r4, srr0 */
+0xe8830008,/* ld r4, 8(r3) */
+0x7c9b03a6,/* mtspr r4, srr1 */
+0x38630010,/* addi r3,r3,16 */
+0x7c9242a6,/* mfspr r4 sprg2 */
+0x4802,/* Branch to address registered
+* by OS. The branch address is
+* patched below */
+0x4800,/* b . */
+};
+int total_inst = sizeof(trampoline) / sizeof(uint32_t);
+
+/* Store the system reset and machine check address */
+guest_machine_check_addr = rtas_ld(args, 1);
+
+/* Safety Check */
+if (sizeof(trampoline) = MC_INTERRUPT_VECTOR_SIZE) {
+fprintf(stderr, Unable to register ibm,nmi_register: 
+Trampoline size exceeded\n);
+rtas_st(rets, 0, RTAS_OUT_NOT_SUPPORTED);
+return;
+}
+
+/*
+ * Update the branch instruction in trampoline with the absolute
+ * machine check address requested by OS
+ */
+branch_inst |= guest_machine_check_addr;
+memcpy(trampoline[11], branch_inst, sizeof(branch_inst));
+
+/* Handle all Host/Guest LE/BE combinations */
+if ((*pcc-interrupts_big_endian)(cpu)) {
+for (i = 0; i  total_inst; i++) {
+trampoline[i] = cpu_to_be32(trampoline[i]);
+}
+} else {
+for (i = 0; i  total_inst; i++) {
+trampoline[i] = cpu_to_le32(trampoline[i]);
+}
+}
+
+/* Patch 0x200 NMI interrupt vector memory area of guest */
+cpu_physical_memory_write(MC_INTERRUPT_VECTOR, trampoline,
+  sizeof(trampoline));
+
+rtas_st(rets, 0, RTAS_OUT_SUCCESS);
+}
+
+static void rtas_ibm_nmi_interlock(PowerPCCPU *cpu,
+   sPAPREnvironment *spapr,
+   uint32_t token, uint32_t nargs,
+   target_ulong args,
+   uint32_t nret, target_ulong rets)
+{
+rtas_st(rets, 0, RTAS_OUT_SUCCESS);
+}
+
 static struct rtas_call {
 const char *name;
 spapr_rtas_fn fn;
@@ -404,6 +489,12 @@ static void core_rtas_register_types(void)
 spapr_rtas_register(RTAS_IBM_SET_SYSTEM_PARAMETER,
 ibm,set-system-parameter,
 rtas_ibm_set_system_parameter);
+spapr_rtas_register(RTAS_IBM_NMI_REGISTER,
+ibm,nmi-register,
+rtas_ibm_nmi_register);
+spapr_rtas_register(RTAS_IBM_NMI_INTERLOCK,
+ibm,nmi-interlock,
+rtas_ibm_nmi_interlock);
 }
 
 type_init(core_rtas_register_types)
diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index 57199f5..8c854ca 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -386,8 +386,10 @@ int spapr_allocate_irq_block(int num, bool lsi, bool msi);
 #define RTAS_IBM_CONFIGURE_CONNECTOR(RTAS_TOKEN_BASE + 0x1E)
 

[Qemu-devel] [PATCH 2/5] target-ppc: Register and handle HCALL to receive updated RTAS region

[Aravinda Prasad]

Receive updates from SLOF about the updated rtas-base.
A separate patch for SLOF [1] adds functionality to invoke a
a private HCALL whenever OS issues instantiate-rtas with
a new rtas-base.

This is required as qemu needs to know the updated rtas-base
as it allocates error reporting structure in RTAS space upon
a machine check exception.

[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-August/120386.html

Signed-off-by: Aravinda Prasad aravi...@linux.vnet.ibm.com
---
 hw/ppc/spapr_hcall.c   |8 
 include/hw/ppc/spapr.h |3 ++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 467858c..118ee77 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -579,6 +579,13 @@ static target_ulong h_rtas(PowerPCCPU *cpu, 
sPAPREnvironment *spapr,
nret, rtas_r3 + 12 + 4*nargs);
 }
 
+static target_ulong h_rtas_update(PowerPCCPU *cpu, sPAPREnvironment *spapr,
+  target_ulong opcode, target_ulong *args)
+{
+spapr-rtas_addr = args[0];
+return 0;
+}
+
 static target_ulong h_logical_load(PowerPCCPU *cpu, sPAPREnvironment *spapr,
target_ulong opcode, target_ulong *args)
 {
@@ -1003,6 +1010,7 @@ static void hypercall_register_types(void)
 
 /* qemu/KVM-PPC specific hcalls */
 spapr_register_hypercall(KVMPPC_H_RTAS, h_rtas);
+spapr_register_hypercall(KVMPPC_H_RTAS_UPDATE, h_rtas_update);
 
 spapr_register_hypercall(H_SET_MODE, h_set_mode);
 
diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index dedfa67..fb8cc63 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -309,7 +309,8 @@ typedef struct sPAPREnvironment {
 #define KVMPPC_H_LOGICAL_MEMOP  (KVMPPC_HCALL_BASE + 0x1)
 /* Client Architecture support */
 #define KVMPPC_H_CAS(KVMPPC_HCALL_BASE + 0x2)
-#define KVMPPC_HCALL_MAXKVMPPC_H_CAS
+#define KVMPPC_H_RTAS_UPDATE(KVMPPC_HCALL_BASE + 0x3)
+#define KVMPPC_HCALL_MAXKVMPPC_H_RTAS_UPDATE
 
 extern sPAPREnvironment *spapr;
 

Re: [Qemu-devel] [Qemu-trivial] [PATCH] libdecnumber: Fix warnings from smatch (missing static, boolean operations)

[Tom Musta]

On 8/24/2014 4:42 AM, Stefan Weil wrote:
 Am 24.08.2014 11:21, schrieb Michael Tokarev:
 Applied to -trivial, thank you!

 But I've a small concern - should we really do this on external sources,
 and divirge from upstream needlessly?

 Thanks,

 /mjt
 
 In general, I agree. In this case, the code was part of gcc, and newer 
 versions of gcc use GPL 3 which is incompatible with QEMU, so I assume that 
 the code in QEMU is no longer available from a maintained upstream.
 
 Stefan
 
 
 

Yes.  We had to effectively fork a copy the code to deal with the license 
issues.

FWIW ... Alex has suggested a reformat of the libdecnumber code to make it 
compatible with QEMU formatting 
(http://lists.nongnu.org/archive/html/qemu-ppc/2014-05/msg00085.html).  This is 
on my todo list.  Obviously, such a reformat would make it even
harder to synchronize with upstream gcc.

[Qemu-devel] [PATCH 3/5] target-ppc: Build error log

[Aravinda Prasad]

Whenever there is a physical memory error due to bit
flips, which cannot be corrected by hardware, the error
is passed on to the kernel. If the memory address in
error belongs to guest address space then guest kernel
is responsible to take action. Hence the error is passed
on to guest via KVM by invoking 0x200 NMI vector.

However, guest OS, as per PAPR, expects an error log
upon such error. This patch registers a new hcall
which is issued from 0x200 interrupt vector and builds
the error log, copies the error log to rtas space and
passes the address of the error log to guest

Enhancement to KVM to perform above functionality is
already in upstream kernel.

Signed-off-by: Aravinda Prasad aravi...@linux.vnet.ibm.com
---
 hw/ppc/spapr_hcall.c   |  147 
 include/hw/ppc/spapr.h |4 +
 2 files changed, 150 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 118ee77..be063f4 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -14,6 +14,86 @@ struct SPRSyncState {
 target_ulong mask;
 };
 
+#define SEVERITY_SHIFT 0x5
+#define DISPOSITION_SHIFT  0x3
+#define INITIATOR_SHIFT0x4
+
+/*
+ * Only required RTAS event severity, disposition, initiator
+ * target and type are copied from arch/powerpc/include/asm/rtas.h
+ */
+
+/* RTAS event severity */
+#define RTAS_SEVERITY_ERROR_SYNC0x3
+
+/* RTAS event disposition */
+#define RTAS_DISP_NOT_RECOVERED 0x2
+
+/* RTAS event initiator */
+#define RTAS_INITIATOR_MEMORY   0x4
+
+/* RTAS event target */
+#define RTAS_TARGET_MEMORY  0x4
+
+/* RTAS event type */
+#define RTAS_TYPE_ECC_UNCORR0x09
+
+/*
+ * Currently KVM only passes on the uncorrected machine
+ * check memory error to guest. Other machine check errors
+ * such as SLB multi-hit and TLB multi-hit are recovered
+ * in KVM and are not passed on to guest.
+ *
+ * DSISR Bit for uncorrected machine check error. Copied
+ * from arch/powerpc/include/asm/mce.h
+ */
+#define PPC_BITLSHIFT(be)   (64 - 1 - (be))
+#define PPC_BIT(bit)(1UL  PPC_BITLSHIFT(bit))
+#define P7_DSISR_MC_UE  (PPC_BIT(48))  /* P8 too */
+
+/* Adopted from kernel source arch/powerpc/include/asm/rtas.h */
+struct rtas_error_log {
+/* Byte 0 */
+uint8_t byte0;  /* Architectural version */
+
+/* Byte 1 */
+uint8_t byte1;
+/* 
+ * XXX  3: Severity level of error
+ *XX2: Degree of recovery
+ *  X   1: Extended log present?
+ *   XX 2: Reserved
+ */
+
+/* Byte 2 */
+uint8_t byte2;
+/* 
+ *  4: Initiator of event
+ *  4: Target of failed operation
+ */
+uint8_t byte3;  /* General event or error*/
+};
+
+/*
+ * Data format in RTAS-Blob
+ *
+ * This structure contains error information related to Machine
+ * Check exception. This is filled up and copied to rtas-blob
+ * upon machine check exception.
+ */
+struct rtas_mc_log {
+target_ulong srr0;
+target_ulong srr1;
+/*
+ * Beginning of error log address. This is properly
+ * populated and passed on to OS registered machine
+ * check notification routine upon machine check
+ * exception
+ */
+target_ulong r3;
+struct rtas_error_log err_log;
+};
+
 static void do_spr_sync(void *arg)
 {
 struct SPRSyncState *s = arg;
@@ -586,6 +666,72 @@ static target_ulong h_rtas_update(PowerPCCPU *cpu, 
sPAPREnvironment *spapr,
 return 0;
 }
 
+static target_ulong h_report_mc_err(PowerPCCPU *cpu, sPAPREnvironment *spapr,
+ target_ulong opcode, target_ulong *args)
+{
+struct rtas_mc_log mc_log;
+CPUPPCState *env = cpu-env;
+PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
+
+/*
+ * We save the original r3 register in SPRG2 in 0x200 vector,
+ * which is patched during call to ibm.nmi-register. Original
+ * r3 is required to be included in error log
+ */
+mc_log.r3 = env-spr[SPR_SPRG2];
+
+/*
+ * SRR0 and SRR1 contains nip and msr at the time of exception
+ * and are clobbered when we return from this hcall
+ * and hence need to be properly restored. We save srr0
+ * and srr1 in rtas blob and restore it in 0x200 vector
+ * before branching to OS registered machine check handler
+ */
+mc_log.srr0 = env-spr[SPR_SRR0];
+mc_log.srr1 = env-spr[SPR_SRR1];
+
+/* Set error log fields */
+mc_log.err_log.byte0 = 0x00;
+mc_log.err_log.byte1 = (RTAS_SEVERITY_ERROR_SYNC  SEVERITY_SHIFT);
+mc_log.err_log.byte1 |= (RTAS_DISP_NOT_RECOVERED  DISPOSITION_SHIFT);
+mc_log.err_log.byte2 = (RTAS_INITIATOR_MEMORY  INITIATOR_SHIFT);
+mc_log.err_log.byte2 |= RTAS_TARGET_MEMORY;
+
+if (env-spr[SPR_DSISR]  P7_DSISR_MC_UE) {
+mc_log.err_log.byte3 = RTAS_TYPE_ECC_UNCORR;
+} else {
+mc_log.err_log.byte3 = 0x0;
+}
+
+/* 

Re: [Qemu-devel] linux-user: enabling binfmt P flag

[Riku Voipio]

Hi,

On Mon, Aug 25, 2014 at 03:39:19PM +0200, Joakim Tjernlund wrote:
 Then consider when you run a LXC without P flag. 

Please remember that your usecase of running Qemu in LXC is a new feature,
never before supported. Adding new features is always nice. However, it must
not happen with expense of regressing already working features
(traditional chroot).

Riku

Re: [Qemu-devel] Mousegrab broken with vfio in 2.1.0 (was: [PATCH 00/25] qemu gtk ui overhaul)

[Gerd Hoffmann]

On Do, 2014-08-07 at 00:22 +0200, Benedikt Morbach wrote:
 I think one of those gtk patches broke mouse/keyboard grab for my
 Windows 8 vfio/vga-passthrough setup in 2.1.0 and I was instructed on
 IRC to report that here.
 
 With 2.0.0 I got a black qemu window with This VM has no graphic
 display device, which I could click on to get a mouse grab.

Yes, this is (intentionally) gone in 2.1.
No vga - no graphic display.

 If I press Ctrl-Alt-g or use the corresponding menu entry, the gtk
 window grabs the input devices and the titlebar changes to press
 Ctrl-Alt-g to release grab, but none of the input reaches the vm.

It shouldn't allow the grab in the first place.

But, yes, any input (grab being active or not) is only routed to the
guest in case a graphic display tab is the active one.  You don't want
the guest see the stuff you are typing into the qemu monitor.

 If I drop the -vga none I can get a mouse-grab, but the passed-through
 gpu won't work, so this is no option for me.

Worth trying: '-vga none -device secondary-vga'.


How does your setup look like?  Two gfx cards, one for the host, one for
the guest?  Then have qemu running on the host display, let qemu grab
the input and feed mouse (kbd too?) input to the guest that way?

It's a bit strange, but I think we don't have a better way to do it
(without additional physical devices).  In case you have a spare usb
mouse you can simply plug it in and use usb-host to assign it to the
guest, which is probably more comfortable than grabbing/ungrabbing when
switching between host and guest.


cheers,
  Gerd

Re: [Qemu-devel] linux-user: enabling binfmt P flag

[Joakim Tjernlund]

Riku Voipio riku.voi...@iki.fi wrote on 2014/08/25 15:55:55:
 
 Hi,
 
 On Mon, Aug 25, 2014 at 03:39:19PM +0200, Joakim Tjernlund wrote:
  Then consider when you run a LXC without P flag. 
 
 Please remember that your usecase of running Qemu in LXC is a new 
feature,
 never before supported. Adding new features is always nice. However, it 
must
 not happen with expense of regressing already working features
 (traditional chroot).

OK, but traditional chroot is unaffected with my patch. Only binfmt
users which uses the binfmt flag O will have to change to PO. How
many is that? 

 Jocke

Re: [Qemu-devel] [PATCH 1/2] usb: Fix bootindex for portnr 9

[Markus Armbruster]

Gerd Hoffmann kra...@redhat.com writes:

 On Fr, 2014-08-15 at 13:32 +0200, Markus Armbruster wrote:
 We identify devices by their Open Firmware device paths.  The encoding
 of the host controller and hub port numbers is incorrect:
 usb_get_fw_dev_path() formats them in decimal, while SeaBIOS uses
 hexadecimal.  When some port number  9, SeaBIOS will miss the
 bootindex (lucky case), or apply it to another device (unlucky case).
 
 The relevant spec[*] agrees with SeaBIOS (and OVMF, for that matter).
 Change %d to %x.
 
 Bug can bite only with host controllers or hubs sporting more than ten
 ports.  I'm not aware of any.

 fyi: xhci can be configured with up to 15 ports (default is 4 ports
 though).

Would be nice to put that into the commit message, between my S-o-B and
yours.

 Applied to usb patch queue.

Thanks!