[Qemu-devel] [PATCH] dp8393x: Flush packets when link comes up

[Fam Zheng]

.can_receive callback changes semantics that once return 0, backend will
try sending again until explicitly flushed, change the device to meet
that.

dp8393x_can_receive checks SONIC_CR_RXEN bit in SONIC_CR register and
SONIC_ISR_RBE bit in SONIC_ISR register, try flushing the queue when
either bit is being updated.

Signed-off-by: Fam Zheng 
---
 hw/net/dp8393x.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
index cd889bc..451ff72 100644
--- a/hw/net/dp8393x.c
+++ b/hw/net/dp8393x.c
@@ -327,9 +327,14 @@ static void dp8393x_do_stop_timer(dp8393xState *s)
 dp8393x_update_wt_regs(s);
 }
 
+static int dp8393x_can_receive(NetClientState *nc);
+
 static void dp8393x_do_receiver_enable(dp8393xState *s)
 {
 s->regs[SONIC_CR] &= ~SONIC_CR_RXDIS;
+if (dp8393x_can_receive(s->nic->ncs)) {
+qemu_flush_queued_packets(qemu_get_queue(s->nic));
+}
 }
 
 static void dp8393x_do_receiver_disable(dp8393xState *s)
@@ -569,6 +574,9 @@ static void dp8393x_write(void *opaque, hwaddr addr, 
uint64_t data,
 dp8393x_do_read_rra(s);
 }
 dp8393x_update_irq(s);
+if (dp8393x_can_receive(s->nic->ncs)) {
+qemu_flush_queued_packets(qemu_get_queue(s->nic));
+}
 break;
 /* Ignore least significant bit */
 case SONIC_RSA:
-- 
2.4.3

Re: [Qemu-devel] [PATCH v10 14/21] i.MX: Add SOC support for i.MX31

[Peter Crosthwaite]

Needs a short paragraph. List out the initally support peripherals.

On Sun, Jul 5, 2015 at 5:05 PM, Jean-Christophe Dubois
 wrote:
> Signed-off-by: Jean-Christophe Dubois 
> ---
>
> Changes since v1:
> * not present on v1
>
> Changes since v2:
> * not present on v2
>
> Changes since v3:
> * not present on v3
>
> Changes since v4:
> * not present on v4
>
> Changes since v5:
> * not present on v5
>
> Changes since v6:
> * not present on v6
>
> Changes since v7:
> * not present on v7
>
> Changes since v8:
> * use defines instead of hardcoded values for IRQ and ADDR
> * Add i.MX31 SOC support
>
> Changes since v9:
> * no change.
>
>  default-configs/arm-softmmu.mak |   2 +
>  hw/arm/Makefile.objs|   1 +
>  hw/arm/fsl-imx31.c  | 219 
> 
>  include/hw/arm/fsl-imx31.h  |  99 ++
>  4 files changed, 321 insertions(+)
>  create mode 100644 hw/arm/fsl-imx31.c
>  create mode 100644 include/hw/arm/fsl-imx31.h
>
> diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
> index 74f1db3..3f86e7e 100644
> --- a/default-configs/arm-softmmu.mak
> +++ b/default-configs/arm-softmmu.mak
> @@ -98,6 +98,8 @@ CONFIG_ALLWINNER_A10_PIT=y
>  CONFIG_ALLWINNER_A10_PIC=y
>  CONFIG_ALLWINNER_A10=y
>
> +CONFIG_FSL_IMX31=y
> +
>  CONFIG_XIO3130=y
>  CONFIG_IOH3420=y
>  CONFIG_I82801B11=y
> diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
> index cf346c1..f35f731 100644
> --- a/hw/arm/Makefile.objs
> +++ b/hw/arm/Makefile.objs
> @@ -13,3 +13,4 @@ obj-y += omap1.o omap2.o strongarm.o
>  obj-$(CONFIG_ALLWINNER_A10) += allwinner-a10.o cubieboard.o
>  obj-$(CONFIG_STM32F205_SOC) += stm32f205_soc.o
>  obj-$(CONFIG_XLNX_ZYNQMP) += xlnx-zynqmp.o xlnx-ep108.o
> +obj-$(CONFIG_FSL_IMX31) += fsl-imx31.o
> diff --git a/hw/arm/fsl-imx31.c b/hw/arm/fsl-imx31.c
> new file mode 100644
> index 000..809070b
> --- /dev/null
> +++ b/hw/arm/fsl-imx31.c
> @@ -0,0 +1,219 @@
> +/*
> + * Copyright (c) 2013 Jean-Christophe Dubois 
> + *
> + * i.MX31 SOC emulation.
> + *
> + * Based on hw/arm/fsl-imx31.c
> + *
> + *  This program is free software; you can redistribute it and/or modify it
> + *  under the terms of the GNU General Public License as published by the
> + *  Free Software Foundation; either version 2 of the License, or
> + *  (at your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + *  FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
> + *  for more details.
> + *
> + *  You should have received a copy of the GNU General Public License along
> + *  with this program; if not, see .
> + */
> +
> +#include "hw/arm/fsl-imx31.h"
> +#include "sysemu/sysemu.h"
> +#include "exec/address-spaces.h"
> +
> +static void fsl_imx31_init(Object *obj)
> +{
> +FslImx31State *s = FSL_IMX31(obj);
> +int i;
> +
> +object_initialize(&s->cpu, sizeof(s->cpu), "arm1136-" TYPE_ARM_CPU);
> +
> +object_initialize(&s->avic, sizeof(s->avic), TYPE_IMX_AVIC);
> +qdev_set_parent_bus(DEVICE(&s->avic), sysbus_get_default());
> +
> +object_initialize(&s->ccm, sizeof(s->ccm), TYPE_IMX_CCM);
> +qdev_set_parent_bus(DEVICE(&s->ccm), sysbus_get_default());
> +
> +for (i = 0; i < FSL_IMX31_NUM_UARTS; i++) {
> +if (i >= MAX_SERIAL_PORTS) {
> +break;
> +}

You don't need this bail-out. For SoCs, the device should always be
created. If QEMU can't attach the serial port to anything that is ok.
If the UART model can't handle being un-attached (chr == NULL) it
should be patched (but thats out of scope for the moment I think).

> +object_initialize(&s->uart[i], sizeof(s->uart[i]), TYPE_IMX_SERIAL);
> +qdev_set_parent_bus(DEVICE(&s->uart[i]), sysbus_get_default());
> +}
> +
> +for (i = 0; i < FSL_IMX31_NUM_GPTS; i++) {
> +object_initialize(&s->gpt[i], sizeof(s->gpt[i]), TYPE_IMX_GPT);
> +qdev_set_parent_bus(DEVICE(&s->gpt[i]), sysbus_get_default());
> +}
> +
> +for (i = 0; i < FSL_IMX31_NUM_EPITS; i++) {
> +object_initialize(&s->epit[i], sizeof(s->epit[i]), TYPE_IMX_EPIT);
> +qdev_set_parent_bus(DEVICE(&s->epit[i]), sysbus_get_default());
> +}
> +}
> +
> +static void fsl_imx31_realize(DeviceState *dev, Error **errp)
> +{
> +FslImx31State *s = FSL_IMX31(dev);
> +uint16_t i;
> +Error *err = NULL;
> +
> +/* Initialize the CPU */

Self documented, drop comment.

> +object_property_set_bool(OBJECT(&s->cpu), true, "realized", &err);
> +if (err) {
> +error_propagate((errp), (err));

parentheses not needed (x2). Happens a few times below as well.

> +return;
> +}
> +
> +/* Initialize the PIC */

What is PIC? I would just say 'interrupt controller" (if you are going
for programmable-int

Re: [Qemu-devel] [PATCH pic32 v2 5/5] Two new machine platforms: pic32mz7 and pic32mz.

[Antony Pavlov]

On Sun, 5 Jul 2015 21:18:11 -0700
Serge Vakulenko  wrote:

> On Wed, Jul 1, 2015 at 6:41 AM, Aurelien Jarno  wrote:
> > On 2015-06-30 21:12, Serge Vakulenko wrote:
> >> Signed-off-by: Serge Vakulenko 
> >> ---
> >>  hw/mips/Makefile.objs   |3 +
> >>  hw/mips/mips_pic32mx7.c | 1652 +
> >>  hw/mips/mips_pic32mz.c  | 2840 
> >> +++
> >>  hw/mips/pic32_ethernet.c|  557 +
> >>  hw/mips/pic32_gpio.c|   39 +
> >>  hw/mips/pic32_load_hex.c|  238 
> >>  hw/mips/pic32_peripherals.h |  210 
> >>  hw/mips/pic32_sdcard.c  |  428 +++
> >>  hw/mips/pic32_spi.c |  121 ++
> >>  hw/mips/pic32_uart.c|  228 
> >>  hw/mips/pic32mx.h   | 1290 
> >>  hw/mips/pic32mz.h   | 2093 +++
> >>  12 files changed, 9699 insertions(+)
> >>  create mode 100644 hw/mips/mips_pic32mx7.c
> >>  create mode 100644 hw/mips/mips_pic32mz.c
> >>  create mode 100644 hw/mips/pic32_ethernet.c
> >>  create mode 100644 hw/mips/pic32_gpio.c
> >>  create mode 100644 hw/mips/pic32_load_hex.c
> >>  create mode 100644 hw/mips/pic32_peripherals.h
> >>  create mode 100644 hw/mips/pic32_sdcard.c
> >>  create mode 100644 hw/mips/pic32_spi.c
> >>  create mode 100644 hw/mips/pic32_uart.c
> >>  create mode 100644 hw/mips/pic32mx.h
> >>  create mode 100644 hw/mips/pic32mz.h
> >
> > This patch is huge, and needs to be splitted to ease the review.
> 
> I'll prepare a new patch set, with every new file put into a separate
> message. Other issues fixed as well.

Putting every new file into a separate message is a nonsense.
Please separate __logical changes__ into a single patch.

-- 
Best regards,
  Antony Pavlov

Re: [Qemu-devel] TAP network breaks after debugger break-in

[Max Filippov]

On Mon, Jul 6, 2015 at 4:55 AM, Fam Zheng  wrote:
> On Sat, 07/04 10:47, Max Filippov wrote:
>> Hello,
>>
>> I'm using QEMU with TAP network and after the commit
>> 0a2df857a703 "Merge remote-tracking branch
>> 'remotes/stefanha/tags/net-pull-request' into staging"
>> I've noticed that activation of debugger connected to QEMU's
>> gdbstub during network I/O almost always breaks network
>> connection: network stops working completely after return
>> from the debugger.
>>
>> Stefan, Fam, any hint on where to start debugging it?
>>
>
> Which NIC are you using?

opencores_eth.

-- 
Thanks.
-- Max

Re: [Qemu-devel] [PATCH COLO-Frame v6 03/31] COLO: migrate colo related info to slave

[zhanghailiang]

On 2015/7/4 2:03, Dr. David Alan Gilbert wrote:

* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:

We can know if VM in destination should go into COLO mode by refer to
the info that has been migrated from PVM.

Signed-off-by: zhanghailiang 
Signed-off-by: Yang Hongyang 
Signed-off-by: Lai Jiangshan 
Signed-off-by: Gonglei 
---
  include/migration/migration-colo.h |  2 ++
  migration/Makefile.objs|  1 +
  migration/colo-comm.c  | 47 ++
  trace-events   |  3 +++
  vl.c   |  5 +++-
  5 files changed, 57 insertions(+), 1 deletion(-)
  create mode 100644 migration/colo-comm.c

diff --git a/include/migration/migration-colo.h 
b/include/migration/migration-colo.h
index c6d0c51..e20a0c1 100644
--- a/include/migration/migration-colo.h
+++ b/include/migration/migration-colo.h
@@ -14,7 +14,9 @@
  #define QEMU_MIGRATION_COLO_H

  #include "qemu-common.h"
+#include "migration/migration.h"

  bool colo_supported(void);
+void colo_info_mig_init(void);

  #endif
diff --git a/migration/Makefile.objs b/migration/Makefile.objs
index 5a25d39..cb7bd30 100644
--- a/migration/Makefile.objs
+++ b/migration/Makefile.objs
@@ -1,5 +1,6 @@
  common-obj-y += migration.o tcp.o
  common-obj-$(CONFIG_COLO) += colo.o
+common-obj-y += colo-comm.o
  common-obj-y += vmstate.o
  common-obj-y += qemu-file.o qemu-file-buf.o qemu-file-unix.o qemu-file-stdio.o
  common-obj-y += xbzrle.o
diff --git a/migration/colo-comm.c b/migration/colo-comm.c
new file mode 100644
index 000..0b76eb4
--- /dev/null
+++ b/migration/colo-comm.c
@@ -0,0 +1,47 @@
+/*
+ * COarse-grain LOck-stepping Virtual Machines for Non-stop Service (COLO)
+ * (a.k.a. Fault Tolerance or Continuous Replication)
+ *
+ * Copyright (c) 2015 HUAWEI TECHNOLOGIES CO., LTD.
+ * Copyright (c) 2015 FUJITSU LIMITED
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * 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 
+#include "trace.h"
+
+static bool colo_requested;
+
+/* save */
+static void colo_info_save(QEMUFile *f, void *opaque)
+{
+qemu_put_byte(f, migrate_enable_colo());
+}
+
+/* restore */
+static int colo_info_load(QEMUFile *f, void *opaque, int version_id)
+{
+int value = qemu_get_byte(f);
+
+if (value && !colo_requested) {
+trace_colo_info_load("COLO request!");
+}
+colo_requested = value;
+
+return 0;
+}
+
+static SaveVMHandlers savevm_colo_info_handlers = {
+.save_state = colo_info_save,
+.load_state = colo_info_load,
+};
+
+void colo_info_mig_init(void)
+{
+register_savevm_live(NULL, "colo", -1, 1,
+ &savevm_colo_info_handlers, NULL);
+}
diff --git a/trace-events b/trace-events
index 52b7efa..3f63019 100644
--- a/trace-events
+++ b/trace-events
@@ -1466,6 +1466,9 @@ rdma_start_incoming_migration_after_rdma_listen(void) ""
  rdma_start_outgoing_migration_after_rdma_connect(void) ""
  rdma_start_outgoing_migration_after_rdma_source_init(void) ""

+# migration/colo-comm.c
+colo_info_load(const char *msg) "%s"
+
  # kvm-all.c
  kvm_ioctl(int type, void *arg) "type 0x%x, arg %p"
  kvm_vm_ioctl(int type, void *arg) "type 0x%x, arg %p"
diff --git a/vl.c b/vl.c
index 2201e27..988567a 100644
--- a/vl.c
+++ b/vl.c
@@ -90,6 +90,7 @@ int main(int argc, char **argv)
  #include "sysemu/dma.h"
  #include "audio/audio.h"
  #include "migration/migration.h"
+#include "migration/migration-colo.h"
  #include "sysemu/kvm.h"
  #include "qapi/qmp/qjson.h"
  #include "qemu/option.h"
@@ -4261,7 +4262,9 @@ int main(int argc, char **argv, char **envp)

  blk_mig_init();
  ram_mig_init();
-
+#ifdef CONFIG_COLO
+colo_info_mig_init();
+#endif


Does't this still break migration compatibility?  I wouldn't


Yes, it will break migration if the QEMU in destination and source not 
enable/disable (configure) this
feature together, also not compatible with old version on migration.


want to have to have two QEMU builds on a system, one built with COLO
and one built without COLO.   You need to arrange for the
section to only be sent if COLO is enabled (i.e. migrate_set_capability colo 
on).
One way to do that would be to use the new QEMU optional sections
that Juan added recently.



Hmm, his method can address the above problems, (though, we will still fail 
when we configure
with --enable-colo in source side and --disable-colo in destination, but that 
is what
we want, we should not go into colo mode if secondary host is not enable this 
feature).
I will look into his patch, and fix that in next version, thanks,

zhanghailiang


Dave


  /* If the currently selected machine wishes to override the units-per-bus
   * property of its default HBA interface type, do so now. */
  if (machine_class->units_per_default_bus) {
--
1.7.12.4



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

.

Re: [Qemu-devel] [PATCH v10 15/21] i.MX: KZM now uses the standalone i.MX31 SOC support

[Peter Crosthwaite]

On Sun, Jul 5, 2015 at 5:05 PM, Jean-Christophe Dubois
 wrote:
> Tested by booting a minimal linux system on the emulated plateform

"Linux" "platform"

>
> Note: Qdev construction helper functions are removed with this patch.
>

So is the goal of the inline header movements to minimise the file
scope of this patch? I would say it is ok to have this one touch them
all or if you are worried about it, what I suggest is you do the soc
conversion as a patch and leave the _create helpers as dead functions.
GCC won't complain about non-static unused functions so it is ok to
leave them dead.

> Signed-off-by: Jean-Christophe Dubois 
> ---
>
> Changes since v1:
> * not present on v1
>
> Changes since v2:
> * not present on v2
>
> Changes since v3:
> * not present on v3
>
> Changes since v4:
> * not present on v4
>
> Changes since v5:
> * not present on v5
>
> Changes since v6:
> * not present on v6
>
> Changes since v7:
> * update KZM target to use new emulators
>
> Changes since v8:
> * update KZM to user i.MX31 SOC
> * rework SDRAM memory initialisation
>
> Changes since v9:
> * remove all Qdev construction helper fucntions.
>
>  hw/arm/Makefile.objs |   4 +-
>  hw/arm/kzm.c | 213 
> ++-
>  include/hw/arm/imx.h |  72 -
>  3 files changed, 112 insertions(+), 177 deletions(-)
>  delete mode 100644 include/hw/arm/imx.h
>
> diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
> index f35f731..2fbe344 100644
> --- a/hw/arm/Makefile.objs
> +++ b/hw/arm/Makefile.objs
> @@ -1,6 +1,6 @@
>  obj-y += boot.o collie.o exynos4_boards.o gumstix.o highbank.o
>  obj-$(CONFIG_DIGIC) += digic_boards.o
> -obj-y += integratorcp.o kzm.o mainstone.o musicpal.o nseries.o
> +obj-y += integratorcp.o mainstone.o musicpal.o nseries.o
>  obj-y += omap_sx1.o palm.o realview.o spitz.o stellaris.o
>  obj-y += tosa.o versatilepb.o vexpress.o virt.o xilinx_zynq.o z2.o
>  obj-$(CONFIG_ACPI) += virt-acpi-build.o
> @@ -13,4 +13,4 @@ obj-y += omap1.o omap2.o strongarm.o
>  obj-$(CONFIG_ALLWINNER_A10) += allwinner-a10.o cubieboard.o
>  obj-$(CONFIG_STM32F205_SOC) += stm32f205_soc.o
>  obj-$(CONFIG_XLNX_ZYNQMP) += xlnx-zynqmp.o xlnx-ep108.o
> -obj-$(CONFIG_FSL_IMX31) += fsl-imx31.o
> +obj-$(CONFIG_FSL_IMX31) += fsl-imx31.o kzm.o
> diff --git a/hw/arm/kzm.c b/hw/arm/kzm.c
> index d7af230..6925833 100644
> --- a/hw/arm/kzm.c
> +++ b/hw/arm/kzm.c
> @@ -13,131 +13,138 @@
>   * i.MX31 SoC
>   */
>
> -#include "hw/sysbus.h"
> +#include "hw/arm/fsl-imx31.h"
> +#include "hw/boards.h"
> +#include "qemu/error-report.h"
>  #include "exec/address-spaces.h"
> -#include "hw/hw.h"
> -#include "hw/arm/arm.h"
> -#include "hw/devices.h"
>  #include "net/net.h"
> -#include "sysemu/sysemu.h"
> -#include "hw/boards.h"
> +#include "hw/devices.h"
>  #include "hw/char/serial.h"
> -#include "hw/intc/imx_avic.h"
> -#include "hw/arm/imx.h"
> -
> -/* Memory map for Kzm Emulation Baseboard:
> - * 0x-0x3fff 16k secure ROM   IGNORED
> - * 0x4000-0x00407fff Reserved IGNORED
> - * 0x00404000-0x00407fff ROM  IGNORED
> - * 0x00408000-0x0fff Reserved IGNORED
> - * 0x1000-0x1fffbfff RAM aliasing IGNORED
> - * 0x1fffc000-0x1fff RAM  EMULATED
> - * 0x2000-0x2fff Reserved IGNORED
> - * 0x3000-0x7fff I.MX31 Internal Register Space
> - *   0x43f0 IO_AREA0
> - *   0x43f9 UART1 EMULATED
> - *   0x43f94000 UART2 EMULATED
> - *   0x6800 AVIC  EMULATED
> - *   0x53f8 CCM   EMULATED
> - *   0x53f94000 PIT 1 EMULATED
> - *   0x53f98000 PIT 2 EMULATED
> - *   0x53f9 GPT   EMULATED
> - * 0x8000-0x87ff RAM  EMULATED
> - * 0x8800-0x8fff RAM Aliasing EMULATED
> - * 0xa000-0xafff NAND Flash   IGNORED
> - * 0xb000-0xb3ff Unavailable  IGNORED
> - * 0xb400-0xb4000fff 8-bit free space IGNORED
> - * 0xb4001000-0xb400100f Board controlIGNORED
> - *  0xb4001003   DIP switch
> - * 0xb4001010-0xb400101f 7-segment LEDIGNORED
> - * 0xb4001020-0xb400102f LED  IGNORED
> - * 0xb4001030-0xb400103f LED  IGNORED
> - * 0xb4001040-0xb400104f FPGA, UART   EMULATED
> - * 0xb4001050-0xb400105f FPGA, UART   EMULATED
> - * 0xb4001060-0xb40f FPGA IGNORED
> - * 0xb600-0xb61f LAN controller   EMULATED
> - * 0xb620-0xb62f FPGA NAND Controller IGNORED
> - * 0xb630-0xb7ff Free IGNORED
> - * 0xb800-0xb8004fff Memory control registers IGNORED
> - * 0xc000-0xc3

Re: [Qemu-devel] TAP network breaks after debugger break-in

[Fam Zheng]

On Mon, 07/06 10:27, Max Filippov wrote:
> On Mon, Jul 6, 2015 at 4:55 AM, Fam Zheng  wrote:
> > On Sat, 07/04 10:47, Max Filippov wrote:
> >> Hello,
> >>
> >> I'm using QEMU with TAP network and after the commit
> >> 0a2df857a703 "Merge remote-tracking branch
> >> 'remotes/stefanha/tags/net-pull-request' into staging"
> >> I've noticed that activation of debugger connected to QEMU's
> >> gdbstub during network I/O almost always breaks network
> >> connection: network stops working completely after return
> >> from the debugger.
> >>
> >> Stefan, Fam, any hint on where to start debugging it?
> >>
> >
> > Which NIC are you using?
> 
> opencores_eth.
> 

Does reverting a90a7425cf592a3afeff3eaf32f543b83050ee5c work?

Fam

Re: [Qemu-devel] TAP network breaks after debugger break-in

[Fam Zheng]

On Mon, 07/06 15:36, Fam Zheng wrote:
> On Mon, 07/06 10:27, Max Filippov wrote:
> > On Mon, Jul 6, 2015 at 4:55 AM, Fam Zheng  wrote:
> > > On Sat, 07/04 10:47, Max Filippov wrote:
> > >> Hello,
> > >>
> > >> I'm using QEMU with TAP network and after the commit
> > >> 0a2df857a703 "Merge remote-tracking branch
> > >> 'remotes/stefanha/tags/net-pull-request' into staging"
> > >> I've noticed that activation of debugger connected to QEMU's
> > >> gdbstub during network I/O almost always breaks network
> > >> connection: network stops working completely after return
> > >> from the debugger.
> > >>
> > >> Stefan, Fam, any hint on where to start debugging it?
> > >>
> > >
> > > Which NIC are you using?
> > 
> > opencores_eth.
> > 
> 
> Does reverting a90a7425cf592a3afeff3eaf32f543b83050ee5c work?
> 

Sorry, there are dependencies, I should say "bisect between a90a7425cf5 and
a90a7425cf5^" :)

Fam

Re: [Qemu-devel] [PATCH v10 18/21] i.MX: Add SOC support for i.MX25

[Peter Crosthwaite]

Many of the same comments I had before for IMX31 apply.

Liviu, CCd is actually working on a simlar problem for multiple SoCs
of the same family using a mostly the same definition. I think the
same applies to the i.MXxx families.

How I suggest this can one can be done to avoid the code dup is:

1: create a base abstract class for the SoC. TYPE_IMX "fxl,imxxx"
2: define class struct members for your serial epit and gpt tables.
Add addresses and IRQs for singletons like CCM if they need to be
parameterised as well.
3: _init and _realize for the abstract class can then pull the tabular
data out of the class to create.
4: define iMX25 and iMX31 which in their class_init populate all the
tables using the data from the headers.

See m25p80.c for an example of multiple dev definitions based on an
abstract class and a table.

On Sun, Jul 5, 2015 at 5:05 PM, Jean-Christophe Dubois
 wrote:
> Signed-off-by: Jean-Christophe Dubois 
> ---
>
> Changes since v1:
> * not present on v1
>
> Changes since v2:
> * not present on v2
>
> Changes since v3:
> * not present on v3
>
> Changes since v4:
> * not present on v4
>
> Changes since v5:
> * not present on v5
>
> Changes since v6:
> * not present on v6
>
> Changes since v7:
> * Added a SOC specific file for i.MX25
>
> Changes since v8:
> * use defines instead of hardcoded values for IRQ and ADDR
> * reworked the memory allocation for SOC memory
>
> Changes since v9:
> * no change
>
>  default-configs/arm-softmmu.mak |   1 +
>  hw/arm/Makefile.objs|   1 +
>  hw/arm/fsl-imx25.c  | 272 
> 
>  include/hw/arm/fsl-imx25.h  | 234 ++
>  4 files changed, 508 insertions(+)
>  create mode 100644 hw/arm/fsl-imx25.c
>  create mode 100644 include/hw/arm/fsl-imx25.h
>
> diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
> index 5fa84c6..bf7572b 100644
> --- a/default-configs/arm-softmmu.mak
> +++ b/default-configs/arm-softmmu.mak
> @@ -100,6 +100,7 @@ CONFIG_ALLWINNER_A10_PIC=y
>  CONFIG_ALLWINNER_A10=y
>
>  CONFIG_FSL_IMX31=y
> +CONFIG_FSL_IMX25=y
>
>  CONFIG_IMX_I2C=y
>
> diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
> index 2fbe344..b83aaca 100644
> --- a/hw/arm/Makefile.objs
> +++ b/hw/arm/Makefile.objs
> @@ -13,4 +13,5 @@ obj-y += omap1.o omap2.o strongarm.o
>  obj-$(CONFIG_ALLWINNER_A10) += allwinner-a10.o cubieboard.o
>  obj-$(CONFIG_STM32F205_SOC) += stm32f205_soc.o
>  obj-$(CONFIG_XLNX_ZYNQMP) += xlnx-zynqmp.o xlnx-ep108.o
> +obj-$(CONFIG_FSL_IMX25) += fsl-imx25.o
>  obj-$(CONFIG_FSL_IMX31) += fsl-imx31.o kzm.o
> diff --git a/hw/arm/fsl-imx25.c b/hw/arm/fsl-imx25.c
> new file mode 100644
> index 000..8325a9c
> --- /dev/null
> +++ b/hw/arm/fsl-imx25.c
> @@ -0,0 +1,272 @@
> +/*
> + * Copyright (c) 2013 Jean-Christophe Dubois 
> + *
> + * i.MX25 SOC emulation.
> + *
> + * Based on hw/arm/xlnx-zynqmp.c
> + *
> + * Copyright (C) 2015 Xilinx Inc
> + * Written by Peter Crosthwaite 
> + *
> + *  This program is free software; you can redistribute it and/or modify it
> + *  under the terms of the GNU General Public License as published by the
> + *  Free Software Foundation; either version 2 of the License, or
> + *  (at your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + *  FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
> + *  for more details.
> + *
> + *  You should have received a copy of the GNU General Public License along
> + *  with this program; if not, see .
> + */
> +
> +#include "hw/arm/fsl-imx25.h"
> +#include "sysemu/sysemu.h"
> +#include "exec/address-spaces.h"
> +
> +static void fsl_imx25_init(Object *obj)
> +{
> +FslImx25State *s = FSL_IMX25(obj);
> +int i;
> +
> +object_initialize(&s->cpu, sizeof(s->cpu), "arm926-" TYPE_ARM_CPU);
> +
> +object_initialize(&s->avic, sizeof(s->avic), TYPE_IMX_AVIC);
> +qdev_set_parent_bus(DEVICE(&s->avic), sysbus_get_default());
> +
> +object_initialize(&s->ccm, sizeof(s->ccm), TYPE_IMX_CCM);
> +qdev_set_parent_bus(DEVICE(&s->ccm), sysbus_get_default());
> +
> +for (i = 0; i < FSL_IMX25_NUM_UARTS; i++) {
> +if (i >= MAX_SERIAL_PORTS) {
> +break;
> +}
> +object_initialize(&s->uart[i], sizeof(s->uart[i]), TYPE_IMX_SERIAL);
> +qdev_set_parent_bus(DEVICE(&s->uart[i]), sysbus_get_default());
> +}
> +
> +for (i = 0; i < FSL_IMX25_NUM_GPTS; i++) {
> +object_initialize(&s->gpt[i], sizeof(s->gpt[i]), TYPE_IMX_GPT);
> +qdev_set_parent_bus(DEVICE(&s->gpt[i]), sysbus_get_default());
> +}
> +
> +for (i = 0; i < FSL_IMX25_NUM_EPITS; i++) {
> +object_initialize(&s->epit[i], sizeof(s->epit[i]), TYPE_IMX_EPIT);
> +qdev_set_parent_bus(DEVICE(&s->epit[i]),

Re: [Qemu-devel] [PATCH v10 19/21] i.MX: Add the i.MX25 3DS PDK plateform

[Peter Crosthwaite]

On Sun, Jul 5, 2015 at 5:05 PM, Jean-Christophe Dubois
 wrote:
> Signed-off-by: Jean-Christophe Dubois 
> ---
>
> Changes since v1:
> * Added a ds1338 I2C device for qtest purpose.
>
> Changes since v2:
> * none
>
> Changes since v3:
> * Rework GPL header
> * use I2C constructor helper.
>
> Changes since v4:
> * use sysbus_create_simple() instead of I2C constructor helper
>
> Changes since v5:
> * Add ds1338 only for qtest mode.
> * small comment fixes.
>
> Changes since v6:
> * Allow for more than 4 serial if suppoted by Qemu.
>
> Changes since v7:
> * Move the SOC part into its own file.
>
> Changes since v8:
> * rework SDRAM memory initialisation
>
> Changes since v9:
> * no change
>
>  hw/arm/Makefile.objs |   2 +-
>  hw/arm/imx25_3ds.c   | 170 
> +++
>  2 files changed, 171 insertions(+), 1 deletion(-)
>  create mode 100644 hw/arm/imx25_3ds.c
>
> diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
> index b83aaca..dc11c0a 100644
> --- a/hw/arm/Makefile.objs
> +++ b/hw/arm/Makefile.objs
> @@ -13,5 +13,5 @@ obj-y += omap1.o omap2.o strongarm.o
>  obj-$(CONFIG_ALLWINNER_A10) += allwinner-a10.o cubieboard.o
>  obj-$(CONFIG_STM32F205_SOC) += stm32f205_soc.o
>  obj-$(CONFIG_XLNX_ZYNQMP) += xlnx-zynqmp.o xlnx-ep108.o
> -obj-$(CONFIG_FSL_IMX25) += fsl-imx25.o
> +obj-$(CONFIG_FSL_IMX25) += fsl-imx25.o imx25_3ds.o
>  obj-$(CONFIG_FSL_IMX31) += fsl-imx31.o kzm.o
> diff --git a/hw/arm/imx25_3ds.c b/hw/arm/imx25_3ds.c
> new file mode 100644
> index 000..fef462a
> --- /dev/null
> +++ b/hw/arm/imx25_3ds.c
> @@ -0,0 +1,170 @@
> +/*
> + * Copyright (c) 2013 Jean-Christophe Dubois 
> + *
> + * 3Dstack Board System emulation.
> + *

Should it be called the PDK board?

Regards,
Peter

> + * Based on hw/arm/kzm.c
> + *
> + * Copyright (c) 2008 OKL and 2011 NICTA
> + * Written by Hans at OK-Labs
> + * Updated by Peter Chubb.
> + *
> + *  This program is free software; you can redistribute it and/or modify it
> + *  under the terms of the GNU General Public License as published by the
> + *  Free Software Foundation; either version 2 of the License, or
> + *  (at your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + *  FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
> + *  for more details.
> + *
> + *  You should have received a copy of the GNU General Public License along
> + *  with this program; if not, see .
> + */
> +
> +#include "hw/arm/fsl-imx25.h"
> +#include "hw/boards.h"
> +#include "qemu/error-report.h"
> +#include "exec/address-spaces.h"
> +#include "sysemu/qtest.h"
> +#include "hw/i2c/i2c.h"
> +
> +/* Memory map for 3D-Stack Emulation Baseboard:
> + * 0x-0x7fff See i.MX25 SOC fr support
> + * 0x8000-0x87ff RAM + Alias  EMULATED
> + * 0x9000-0x9fff RAM + Alias  EMULATED
> + * 0xa000-0xa7ff FlashIGNORED
> + * 0xa800-0xafff FlashIGNORED
> + * 0xb000-0xb1ff SRAM IGNORED
> + * 0xb200-0xb3ff SRAM IGNORED
> + * 0xb400-0xb5ff CS4  IGNORED
> + * 0xb600-0xb8000fff Reserved IGNORED
> + * 0xb8001000-0xb8001fff SDRAM CTRL reg   IGNORED
> + * 0xb8002000-0xb8002fff WEIM CTRL regIGNORED
> + * 0xb8003000-0xb8003fff M3IF CTRL regIGNORED
> + * 0xb8004000-0xb8004fff EMI CTRL reg IGNORED
> + * 0xb8005000-0xbaff Reserved IGNORED
> + * 0xbb00-0xbb000fff NAND flash area buf  IGNORED
> + * 0xbb001000-0xbb0011ff NAND flash reserved  IGNORED
> + * 0xbb001200-0xbb001dff Reserved IGNORED
> + * 0xbb001e00-0xbb001fff NAN flash CTRL reg   IGNORED
> + * 0xbb012000-0xbfff Reserved IGNORED
> + * 0xc000-0x Reserved IGNORED
> + */
> +
> +typedef struct imx25_3ds {
> +FslImx25State soc;
> +MemoryRegion ram[2];
> +MemoryRegion ram_alias;
> +} imx25_3ds;
> +
> +#define IMX25_3DS_ADDRESS   (FSL_IMX25_SDRAM0_ADDR)
> +
> +static struct arm_boot_info imx25_3ds_binfo;
> +
> +static void imx25_3ds_init(MachineState *machine)
> +{
> +imx25_3ds *s = g_new0(imx25_3ds, 1);
> +Error *err = NULL;
> +unsigned int ram_size;
> +int i;
> +
> +object_initialize(&s->soc, sizeof(s->soc), TYPE_FSL_IMX25);
> +object_property_add_child(OBJECT(machine), "soc", OBJECT(&s->soc),
> +  &error_abort);
> +
> +object_property_set_bool(OBJECT(&s->soc), true, "realized", &err);
> +if (err != NULL) {
> +error_report("%s", error_get_pretty(err));
> +exit(1);
> +}
> +
> +/* We need to initialize our memory */
> +
> +if (machine->ram_size > (FSL_IMX25_SDRAM0_SIZE + FSL_IMX25_SDRAM1_SIZE)) 
> {
> +   error_repor

Re: [Qemu-devel] TAP network breaks after debugger break-in

[Max Filippov]

On Mon, Jul 6, 2015 at 10:36 AM, Fam Zheng  wrote:
> On Mon, 07/06 10:27, Max Filippov wrote:
>> On Mon, Jul 6, 2015 at 4:55 AM, Fam Zheng  wrote:
>> > On Sat, 07/04 10:47, Max Filippov wrote:
>> >> Hello,
>> >>
>> >> I'm using QEMU with TAP network and after the commit
>> >> 0a2df857a703 "Merge remote-tracking branch
>> >> 'remotes/stefanha/tags/net-pull-request' into staging"
>> >> I've noticed that activation of debugger connected to QEMU's
>> >> gdbstub during network I/O almost always breaks network
>> >> connection: network stops working completely after return
>> >> from the debugger.
>> >>
>> >> Stefan, Fam, any hint on where to start debugging it?
>> >>
>> >
>> > Which NIC are you using?
>>
>> opencores_eth.
>>
>
> Does reverting a90a7425cf592a3afeff3eaf32f543b83050ee5c work?

Looks like it does, though the revert isn't clean.

-- 
Thanks.
-- Max

Re: [Qemu-devel] [PATCH] virtio-pci: implement cfg capability

[Paolo Bonzini]

On 04/07/2015 23:19, Michael S. Tsirkin wrote:
> The fact that address_space_write/_read actually does a byteswap if
> host!=target endian should probably be documented.

FWIW, it's not if host != target endian.  It's if memory region
endianness != target endianness.  See memory_region_wrong_endianness.

> Or maybe it should be changed: it seems likely that non-target-specific 
> devices
> that use it do this incorrectly ATM. In particular, dma_memory_rw_relaxed 
> calls
> address_space_rw and since DMA originates with devices I think there's very
> little chance that these actually want a different behaviour depending on the
> target endian-ness.
> 
> Most likely, these only work correctly because DMA outside RAM
> is highly unusual.

They work correctly because of that, and because most devices *and*
targets are little endian so you have no swap.  On ppc64, which has
TARGET_WORDS_BIGENDIAN, it probably wouldn't work correctly.

Paolo

Re: [Qemu-devel] [PATCH pic32 v2 5/5] Two new machine platforms: pic32mz7 and pic32mz.

[Antony Pavlov]

On Sun, 5 Jul 2015 21:27:04 -0700
Serge Vakulenko  wrote:

> On Wed, Jul 1, 2015 at 10:56 PM, Antony Pavlov  
> wrote:
> > On Tue, 30 Jun 2015 21:12:34 -0700
> > Serge Vakulenko  wrote:
> >
> >> Signed-off-by: Serge Vakulenko 
> >> ---
> >>  hw/mips/Makefile.objs   |3 +
> >>  hw/mips/mips_pic32mx7.c | 1652 +
> >>  hw/mips/mips_pic32mz.c  | 2840 
> >> +++
> >>  hw/mips/pic32_ethernet.c|  557 +
> >>  hw/mips/pic32_gpio.c|   39 +
> >>  hw/mips/pic32_load_hex.c|  238 
> >>  hw/mips/pic32_peripherals.h |  210 
> >>  hw/mips/pic32_sdcard.c  |  428 +++
> >>  hw/mips/pic32_spi.c |  121 ++
> >>  hw/mips/pic32_uart.c|  228 
> >>  hw/mips/pic32mx.h   | 1290 
> >>  hw/mips/pic32mz.h   | 2093 +++
> >>  12 files changed, 9699 insertions(+)
> >>  create mode 100644 hw/mips/mips_pic32mx7.c
> >>  create mode 100644 hw/mips/mips_pic32mz.c
> >>  create mode 100644 hw/mips/pic32_ethernet.c
> >>  create mode 100644 hw/mips/pic32_gpio.c
> >>  create mode 100644 hw/mips/pic32_load_hex.c
> >>  create mode 100644 hw/mips/pic32_peripherals.h
> >>  create mode 100644 hw/mips/pic32_sdcard.c
> >>  create mode 100644 hw/mips/pic32_spi.c
> >>  create mode 100644 hw/mips/pic32_uart.c
> >>  create mode 100644 hw/mips/pic32mx.h
> >>  create mode 100644 hw/mips/pic32mz.h
> >>
> >> diff --git a/hw/mips/Makefile.objs b/hw/mips/Makefile.objs
> >> index 9633f3a..dcbaec9 100644
> >> --- a/hw/mips/Makefile.objs
> >> +++ b/hw/mips/Makefile.objs
> >> @@ -3,3 +3,6 @@ obj-y += addr.o cputimer.o mips_int.o
> >>  obj-$(CONFIG_JAZZ) += mips_jazz.o
> >>  obj-$(CONFIG_FULONG) += mips_fulong2e.o
> >>  obj-y += gt64xxx_pci.o
> >> +obj-y += mips_pic32mz.o mips_pic32mx7.o
> >> +obj-y += pic32_load_hex.o pic32_sdcard.o pic32_spi.o pic32_uart.o 
> >> pic32_gpio.o
> >> +obj-y += pic32_ethernet.o
> >
> > Can we move mips-unrelated stuff to the appropriate dirs?
> > E.g. pic32_gpio.c can to go to hw/gpio.
> 
> All these files are pic32-related. They depend on pic32_t data
> structure declared in pic32_peripherals.h and register definitions in
> pic32mx.h and pic32mz.h. I see no point to move them around.

But why hw/gpio/pic32_gpio.c can't include pic32_peripherals.h?
You can see that mainline qemu.git/hw/mips/ does not contain any header file,
so just put your header files into the proper dir (I suppose 
qemu.git/include/hw/mips).


> > Also please use separate patch for every peripheral controller (see 
> > Aurelien's comment).
> 
> Agreed.
> 
> >> diff --git a/hw/mips/mips_pic32mx7.c b/hw/mips/mips_pic32mx7.c
> >> new file mode 100644
> >> index 000..1d8ffb5
> >> --- /dev/null
> >> +++ b/hw/mips/mips_pic32mx7.c
> >> @@ -0,0 +1,1652 @@
> >> +/*
> >> + * QEMU support for Microchip PIC32MX7 microcontroller.
> >> + *
> >> + * Copyright (c) 2015 Serge Vakulenko
> >> + *
> >> + * Permission is hereby granted, free of charge, to any person obtaining 
> >> a copy
> >> + * of this software and associated documentation files (the "Software"), 
> >> to deal
> >> + * in the Software without restriction, including without limitation the 
> >> rights
> >> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or 
> >> sell
> >> + * copies of the Software, and to permit persons to whom the Software is
> >> + * furnished to do so, subject to the following conditions:
> >> + *
> >> + * The above copyright notice and this permission notice shall be 
> >> included in
> >> + * all copies or substantial portions of the Software.
> >> + *
> >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> >> EXPRESS OR
> >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> >> MERCHANTABILITY,
> >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> >> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> >> OTHER
> >> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
> >> ARISING FROM,
> >> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS 
> >> IN
> >> + * THE SOFTWARE.
> >> + */
> >> +
> >> +/* Only 32-bit little endian mode supported. */
> >> +#include "config.h"
> >> +#if !defined TARGET_MIPS64 && !defined TARGET_WORDS_BIGENDIAN
> >
> > Please don't use C preprocessor directive for conditional compilation of 
> > the whole file.
> > Use Makefile instead. See CONFIG_FULONG for example (fulong2e is 
> > mips64le-only).
> 
> Makes sense.
> 
> Thanks,
> --Serge
> 
> > --
> > Best regards,
> >   Antony Pavlov


-- 
-- 
Best regards,
  Antony Pavlov

[Qemu-devel] [BUG/RFC] Two cpus are not brought up normally in SLES11 sp3 VM after reboot

[zhanghailiang]

Hi,

Recently we encountered a problem in our project: 2 CPUs in VM are not brought 
up normally after reboot.

Our host is using KVM kmod 3.6 and QEMU 2.1.
A SLES 11 sp3 VM configured with 8 vcpus,
cpu model is configured with 'host-passthrough'.

After VM's first time started up, everything seems to be OK.
and then VM is paniced and rebooted.
After reboot, only 6 cpus are brought up in VM, cpu1 and cpu7 are not online.

This is the only message we can get from VM:
VM dmesg shows:
[0.069867] Booting Node   0, Processors  #1
[5.060042] CPU1: Stuck ??
[5.060499]  #2
[5.088322] kvm-clock: cpu 2, msr 6:3fc90901, secondary cpu clock
[5.088335] KVM setup async PF for cpu 2
[5.092967] NMI watchdog enabled, takes one hw-pmu counter.
[5.094405]  #3
[5.108324] kvm-clock: cpu 3, msr 6:3fcd0901, secondary cpu clock
[5.108333] KVM setup async PF for cpu 3
[5.113553] NMI watchdog enabled, takes one hw-pmu counter.
[5.114970]  #4
[5.128325] kvm-clock: cpu 4, msr 6:3fd10901, secondary cpu clock
[5.128336] KVM setup async PF for cpu 4
[5.134576] NMI watchdog enabled, takes one hw-pmu counter.
[5.135998]  #5
[5.152324] kvm-clock: cpu 5, msr 6:3fd50901, secondary cpu clock
[5.152334] KVM setup async PF for cpu 5
[5.154764] NMI watchdog enabled, takes one hw-pmu counter.
[5.156467]  #6
[5.172327] kvm-clock: cpu 6, msr 6:3fd90901, secondary cpu clock
[5.172341] KVM setup async PF for cpu 6
[5.180738] NMI watchdog enabled, takes one hw-pmu counter.
[5.182173]  #7 Ok.
[   10.170815] CPU7: Stuck ??
[   10.171648] Brought up 6 CPUs
[   10.172394] Total of 6 processors activated (28799.97 BogoMIPS).

From host, we found that QEMU vcpu1 thread and vcpu7 thread were not consuming 
any cpu (Should be in idle state),
All of VCPUs' stacks in host is like bellow:

[] kvm_vcpu_block+0x65/0xa0 [kvm]
[] __vcpu_run+0xd1/0x260 [kvm]
[] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 [kvm]
[] kvm_vcpu_ioctl+0x38e/0x580 [kvm]
[] do_vfs_ioctl+0x8b/0x3b0
[] sys_ioctl+0xa1/0xb0
[] system_call_fastpath+0x16/0x1b
[<2ab9fe1f99a7>] 0x2ab9fe1f99a7
[] 0x

We looked into the kernel codes that could leading to the above 'Stuck' warning,
and found that the only possible is the emulation of 'cpuid' instruct in 
kvm/qemu has something wrong.
But since we can’t reproduce this problem, we are not quite sure.
Is there any possible that the cupid emulation in kvm/qemu has some bug ?

Has anyone come across these problem before? Or any idea?

Thanks,
zhanghailiang

Re: [Qemu-devel] TAP network breaks after debugger break-in

[Fam Zheng]

On Mon, 07/06 10:45, Max Filippov wrote:
> On Mon, Jul 6, 2015 at 10:36 AM, Fam Zheng  wrote:
> > On Mon, 07/06 10:27, Max Filippov wrote:
> >> On Mon, Jul 6, 2015 at 4:55 AM, Fam Zheng  wrote:
> >> > On Sat, 07/04 10:47, Max Filippov wrote:
> >> >> Hello,
> >> >>
> >> >> I'm using QEMU with TAP network and after the commit
> >> >> 0a2df857a703 "Merge remote-tracking branch
> >> >> 'remotes/stefanha/tags/net-pull-request' into staging"
> >> >> I've noticed that activation of debugger connected to QEMU's
> >> >> gdbstub during network I/O almost always breaks network
> >> >> connection: network stops working completely after return
> >> >> from the debugger.
> >> >>
> >> >> Stefan, Fam, any hint on where to start debugging it?
> >> >>
> >> >
> >> > Which NIC are you using?
> >>
> >> opencores_eth.
> >>
> >
> > Does reverting a90a7425cf592a3afeff3eaf32f543b83050ee5c work?
> 
> Looks like it does, though the revert isn't clean.

I can't really tell what happened to opencores_eth because it has proper
open_eth_notify_can_receive() calls that should flush the queue as expected
since a90a7425cf592a3afeff3eaf32f543b83050ee5c (some other NICs are broken
because of missing such flushes).

FWIW, what is changed by that patch is that if NIC's .can_receive() callback
returns 0, it should later call qemu_flush_queued_packets() explicitly, when
conditions becomes ready again (i.e. .can_receive() would return true on next
invocation).

Fam

Re: [Qemu-devel] [PATCH pic32 v3 13/16] pic32: add file pic32_spi.c

[Peter Crosthwaite]

On Sun, Jul 5, 2015 at 11:15 PM, Serge Vakulenko
 wrote:
> Implement pic32 SPI peripheral interface.
>
> Signed-off-by: Serge Vakulenko 
> ---
>  hw/mips/pic32_spi.c | 121 
> 

SPI controllers go in hw/ssi.

>  1 file changed, 121 insertions(+)
>  create mode 100644 hw/mips/pic32_spi.c
>
> diff --git a/hw/mips/pic32_spi.c b/hw/mips/pic32_spi.c
> new file mode 100644
> index 000..52b1579
> --- /dev/null
> +++ b/hw/mips/pic32_spi.c
> @@ -0,0 +1,121 @@
> +/*
> + * SPI ports.
> + *
> + * Copyright (C) 2014-2015 Serge Vakulenko
> + *
> + * Permission to use, copy, modify, and distribute this software
> + * and its documentation for any purpose and without fee is hereby
> + * granted, provided that the above copyright notice appear in all
> + * copies and that both that the copyright notice and this
> + * permission notice and warranty disclaimer appear in supporting
> + * documentation, and that the name of the author not be used in
> + * advertising or publicity pertaining to distribution of the
> + * software without specific, written prior permission.
> + *
> + * The author disclaim all warranties with regard to this
> + * software, including all implied warranties of merchantability
> + * and fitness.  In no event shall the author be liable for any
> + * special, indirect or consequential damages or any damages
> + * whatsoever resulting from loss of use, data or profits, whether
> + * in an action of contract, negligence or other tortious action,
> + * arising out of or in connection with the use or performance of
> + * this software.
> + */
> +#include "hw/hw.h"
> +#include "pic32_peripherals.h"
> +

Devices should have their own header rather than share with other devs
of the same family.

> +#include "pic32mz.h"
> +
> +#define SPI_IRQ_FAULT   0   /* error irq offset */
> +#define SPI_IRQ_TX  1   /* transmitter irq offset */
> +#define SPI_IRQ_RX  2   /* receiver irq offset */
> +
> +unsigned pic32_spi_readbuf(pic32_t *s, int unit)
> +{
> +spi_t *p = &s->spi[unit];

This looks like it is retrieving its own state from the chip
container. Rather the device should be self container and the higher
layers (chip level?) should pass is the single SPI controller to these
APIs.

> +unsigned result = p->buf[p->rfifo];
> +
> +if (VALUE(p->con) & PIC32_SPICON_ENHBUF) {
> +p->rfifo++;
> +p->rfifo &= 3;
> +}
> +if (VALUE(p->stat) & PIC32_SPISTAT_SPIRBF) {
> +VALUE(p->stat) &= ~PIC32_SPISTAT_SPIRBF;
> +/*s->irq_clear(s, p->irq + SPI_IRQ_RX);*/
> +}
> +return result;
> +}
> +
> +void pic32_spi_writebuf(pic32_t *s, int unit, unsigned val)
> +{
> +spi_t *p = &s->spi[unit];
> +
> +/* Perform SD card i/o on configured SPI port. */
> +if (unit == s->sdcard_spi_port) {

The SPI controller should be self-contained, and not have SD
awareness. Connection of SPI to SD needs to happen on chip, board or
machine level.

I think MIPS may be a little out of date with device modelling style.
I would look further afield for template code. For a simple SPI
controller that is (more) up to date style wise I suggest
xilinx_spi.c.

Regards,
Peter

> +unsigned result = 0;
> +
> +if (VALUE(p->con) & PIC32_SPICON_MODE32) {
> +/* 32-bit data width */
> +result  = (unsigned char) pic32_sdcard_io(s, val >> 24) << 24;
> +result |= (unsigned char) pic32_sdcard_io(s, val >> 16) << 16;
> +result |= (unsigned char) pic32_sdcard_io(s, val >> 8) << 8;
> +result |= (unsigned char) pic32_sdcard_io(s, val);
> +
> +} else if (VALUE(p->con) & PIC32_SPICON_MODE16) {
> +/* 16-bit data width */
> +result = (unsigned char) pic32_sdcard_io(s, val >> 8) << 8;
> +result |= (unsigned char) pic32_sdcard_io(s, val);
> +
> +} else {
> +/* 8-bit data width */
> +result = (unsigned char) pic32_sdcard_io(s, val);
> +}
> +p->buf[p->wfifo] = result;
> +} else {
> +/* No device */
> +p->buf[p->wfifo] = ~0;
> +}
> +if (VALUE(p->stat) & PIC32_SPISTAT_SPIRBF) {
> +VALUE(p->stat) |= PIC32_SPISTAT_SPIROV;
> +/*s->irq_raise(s, p->irq + SPI_IRQ_FAULT);*/
> +} else if (VALUE(p->con) & PIC32_SPICON_ENHBUF) {
> +p->wfifo++;
> +p->wfifo &= 3;
> +if (p->wfifo == p->rfifo) {
> +VALUE(p->stat) |= PIC32_SPISTAT_SPIRBF;
> +/*s->irq_raise(s, p->irq + SPI_IRQ_RX);*/
> +}
> +} else {
> +VALUE(p->stat) |= PIC32_SPISTAT_SPIRBF;
> +/*s->irq_raise(s, p->irq + SPI_IRQ_RX);*/
> +}
> +}
> +
> +void pic32_spi_control(pic32_t *s, int unit)
> +{
> +spi_t *p = &s->spi[unit];
> +
> +if (!(VALUE(p->con) & PIC32_SPICON_ON)) {
> +s->irq_clear(s, p->irq + SPI_IRQ_FAULT);
> +s->irq_clear(s, p->irq + SPI_IRQ_RX);
> +s->ir

Re: [Qemu-devel] [PATCH pic32 v3 05/16] pic32: add file pic32_peripherals.h

[Peter Crosthwaite]

On Sun, Jul 5, 2015 at 11:14 PM, Serge Vakulenko
 wrote:
> Data definitions and function declarations for simulation
> of pic32 microcontrollers.
>
> Signed-off-by: Serge Vakulenko 
> ---
>  hw/mips/pic32_peripherals.h | 210 
> 
>  1 file changed, 210 insertions(+)
>  create mode 100644 hw/mips/pic32_peripherals.h
>
> diff --git a/hw/mips/pic32_peripherals.h b/hw/mips/pic32_peripherals.h
> new file mode 100644
> index 000..4435991
> --- /dev/null
> +++ b/hw/mips/pic32_peripherals.h
> @@ -0,0 +1,210 @@
> +/*
> + * Define memory map for PIC32 microcontroller.
> + *
> + * Copyright (C) 2015 Serge Vakulenko
> + *
> + * Permission to use, copy, modify, and distribute this software
> + * and its documentation for any purpose and without fee is hereby
> + * granted, provided that the above copyright notice appear in all
> + * copies and that both that the copyright notice and this
> + * permission notice and warranty disclaimer appear in supporting
> + * documentation, and that the name of the author not be used in
> + * advertising or publicity pertaining to distribution of the
> + * software without specific, written prior permission.
> + *
> + * The author disclaim all warranties with regard to this
> + * software, including all implied warranties of merchantability
> + * and fitness.  In no event shall the author be liable for any
> + * special, indirect or consequential damages or any damages
> + * whatsoever resulting from loss of use, data or profits, whether
> + * in an action of contract, negligence or other tortious action,
> + * arising out of or in connection with the use or performance of
> + * this software.
> + */
> +#include "hw/sysbus.h"  /* SysBusDevice */
> +#include "net/net.h"
> +
> +#define IO_MEM_SIZE (1024*1024) /* 1 Mbyte */
> +
> +typedef struct _uart_t uart_t;
> +typedef struct _spi_t spi_t;
> +typedef struct _sdcard_t sdcard_t;
> +typedef struct _pic32_t pic32_t;
> +typedef struct _eth_t eth_t;
> +
> +/*
> + * UART private data.
> + */
> +struct _uart_t {

All typenames must be CamelCase.

scripts/checkpatch.pl should catch these.

> +pic32_t *mcu;   /* back pointer to pic32 object */
> +unsignedirq;/* interrupt number */
> +int oactive;/* output active */
> +unsignedsta;/* UxSTA address */
> +unsignedmode;   /* UxMODE address */
> +unsignedrxbyte; /* received byte */
> +CharDriverState *chr;   /* pointer to serial_hds[i] */
> +QEMUTimer   *transmit_timer;/* needed to delay TX interrupt */
> +};
> +
> +/*
> + * SPI private data.
> + */
> +struct _spi_t {
> +unsignedbuf[4]; /* transmit and receive buffer */
> +unsignedrfifo;  /* read fifo counter */
> +unsignedwfifo;  /* write fifo counter */
> +unsignedirq;/* interrupt numbers */
> +unsignedcon;/* SPIxCON address */
> +unsignedstat;   /* SPIxSTAT address */
> +};
> +
> +/*
> + * SD card private data.
> + */
> +struct _sdcard_t {
> +const char  *name;  /* Device name */
> +unsignedgpio_port;  /* GPIO port number of CS0 signal */
> +unsignedgpio_cs;/* GPIO pin mask of CS0 signal */
> +unsignedkbytes; /* Disk size */
> +int unit;   /* Index (sd0 or sd1) */
> +int fd; /* Image file */
> +int select; /* Selected */
> +int read_multiple;  /* Read-multiple mode */
> +unsignedblen;   /* Block length */
> +unsignedwbecnt; /* Write block erase count */
> +unsignedoffset; /* Read/write offset */
> +unsignedcount;  /* Byte count */
> +unsignedlimit;  /* Reply length */
> +unsignedchar buf[1024 + 16];
> +};
> +
> +/*
> + * PIC32 data structure.
> + */
> +struct _pic32_t {
> +SysBusDevice parent_obj;
> +MIPSCPU *cpu;   /* back pointer to cpu object */
> +uint32_t*iomem; /* backing storage for I/O area */
> +
> +int board_type; /* board variant */
> +int stop_on_reset;  /* halt simulation on soft reset */
> +unsignedsyskey_unlock;  /* syskey state */
> +
> +#define NUM_UART 6  /* number of UART ports */
> +uart_t  uart[NUM_UART]; /* UART data */
> +
> +#define NUM_SPI 6   /* max number of SPI ports */
> +spi_t   spi[NUM_SPI];   /* SPI data */
> +
> +unsignedsdcard_spi_port;/* SPI port number of SD card */
> +sdcard_tsdcard[2];  

Re: [Qemu-devel] [PATCH v10 02/21] i.MX: Move serial initialization to init/realize of DeviceClass.

[jcd]

- Le 6 Juil 15, à 8:40, Peter Crosthwaite  a 
écrit : 

> On Sun, Jul 5, 2015 at 5:04 PM, Jean-Christophe Dubois
>  wrote:
> > Move constructor to DeviceClass methods
> > * imx_serial_init
> > * imx_serial_realize

> > imx32_serial_properties is renamed to imx_serial_properties.

> > The Qdev construction helper is moved to an include file as an
> > inline function. This function is going to be removed soon.

> > Signed-off-by: Jean-Christophe Dubois 
> > ---

> > Changes since v1:
> > * not present on v1

> > Changes since v2:
> > * not present on v2

> > Changes since v3:
> > * not present on v3

> > Changes since v4:
> > * not present on v4

> > Changes since v5:
> > * not present on v5

> > Changes since v6:
> > * not present on v6

> > Changes since v7:
> > * not present on v7

> > Changes since v8:
> > * Remove Qdev construction helper

> > Changes since v9:
> > * Qdev construction helper is reintegrated and moved to a header file
> > as an inline function.

> > hw/char/imx_serial.c | 70 
> > +++-
> > include/hw/arm/imx.h | 30 +-
> > 2 files changed, 49 insertions(+), 51 deletions(-)

> > diff --git a/hw/char/imx_serial.c b/hw/char/imx_serial.c
> > index 1dcb325..ef5af05 100644
> > --- a/hw/char/imx_serial.c
> > +++ b/hw/char/imx_serial.c
> > @@ -21,7 +21,6 @@
> > #include "hw/char/imx_serial.h"
> > #include "sysemu/sysemu.h"
> > #include "sysemu/char.h"
> > -#include "hw/arm/imx.h"

> > //#define DEBUG_SERIAL 1
> > #ifdef DEBUG_SERIAL
> > @@ -38,13 +37,13 @@ do { printf("imx_serial: " fmt , ##args); } while (0)
> > //#define DEBUG_IMPLEMENTATION 1
> > #ifdef DEBUG_IMPLEMENTATION
> > # define IPRINTF(fmt, args...) \
> > - do { fprintf(stderr, "imx_serial: " fmt, ##args); } while (0)
> > + do { fprintf(stderr, "%s: " fmt, TYPE_IMX_SERIAL, ##args); } while (0)
> > #else
> > # define IPRINTF(fmt, args...) do {} while (0)
> > #endif

> > static const VMStateDescription vmstate_imx_serial = {
> > - .name = "imx-serial",
> > + .name = TYPE_IMX_SERIAL,
> > .version_id = 1,
> > .minimum_version_id = 1,
> > .fields = (VMStateField[]) {
> > @@ -299,22 +298,18 @@ static void imx_event(void *opaque, int event)
> > }
> > }

> > -
> > static const struct MemoryRegionOps imx_serial_ops = {
> > .read = imx_serial_read,
> > .write = imx_serial_write,
> > .endianness = DEVICE_NATIVE_ENDIAN,
> > };

> > -static int imx_serial_init(SysBusDevice *dev)
> > +static void imx_serial_realize(DeviceState *dev, Error **errp)
> > {
> > IMXSerialState *s = IMX_SERIAL(dev);

> > -
> > - memory_region_init_io(&s->iomem, OBJECT(s), &imx_serial_ops, s,
> > - "imx-serial", 0x1000);
> > - sysbus_init_mmio(dev, &s->iomem);
> > - sysbus_init_irq(dev, &s->irq);
> > + /* FIXME use a qdev chardev prop instead of qemu_char_get_next_serial() */
> > + s->chr = qemu_char_get_next_serial();

> > if (s->chr) {
> > qemu_chr_add_handlers(s->chr, imx_can_receive, imx_receive,
> > @@ -323,45 +318,20 @@ static int imx_serial_init(SysBusDevice *dev)
> > DPRINTF("No char dev for uart at 0x%lx\n",
> > (unsigned long)s->iomem.ram_addr);
> > }
> > -
> > - return 0;
> > }

> > -void imx_serial_create(int uart, const hwaddr addr, qemu_irq irq)
> > +static void imx_serial_init(Object *obj)
> > {
> > - DeviceState *dev;
> > - SysBusDevice *bus;
> > - CharDriverState *chr;
> > - const char chr_name[] = "serial";
> > - char label[ARRAY_SIZE(chr_name) + 1];
> > -
> > - dev = qdev_create(NULL, TYPE_IMX_SERIAL);
> > -
> > - if (uart >= MAX_SERIAL_PORTS) {
> > - hw_error("Cannot assign uart %d: QEMU supports only %d ports\n",
> > - uart, MAX_SERIAL_PORTS);
> > - }
> > - chr = serial_hds[uart];
> > - if (!chr) {
> > - snprintf(label, ARRAY_SIZE(label), "%s%d", chr_name, uart);
> > - chr = qemu_chr_new(label, "null", NULL);
> > - if (!(chr)) {
> > - hw_error("Can't assign serial port to imx-uart%d.\n", uart);
> > - }
> > - }
> > -
> > - qdev_prop_set_chr(dev, "chardev", chr);

> I'm confused as to why you needed to replace the qdev_prop_set_chr
> logic with qemu_get_char_get_next_serial(). Can you give some details
> on why we want to do this?
I am just following the general ARM template of other serial drivers. I am not 
proficient enough in Qemu wizardry to proprose my own thing in this regard. 
So far no other ARM plateform (except strongarm?) seems to be using "chardev" 
and all seems to be using qemu_get_char_get_next_serial() even if it is 
supposed to be deprecated some day (even the cadence serial driver). 

> > - bus = SYS_BUS_DEVICE(dev);
> > - qdev_init_nofail(dev);
> > - if (addr != (hwaddr)-1) {
> > - sysbus_mmio_map(bus, 0, addr);
> > - }
> > - sysbus_connect_irq(bus, 0, irq);
> > + SysBusDevice *sbd = SYS_BUS_DEVICE(obj);
> > + IMXSerialState *s = IMX_SERIAL(obj);

> > + memory_region_init_io(&s->iomem, obj, &imx_serial_ops, s,
> > + TYPE_IMX_SERIAL, 0x1000);
> > + sysbus_init_mmio(sbd, &s->iomem);
> > + sysbus_init_irq(sbd, &s->irq);
> > }

> > -
> > -static Property imx32_serial_p

Re: [Qemu-devel] [PATCH pic32 v3 14/16] pic32: add file pic32_sdcard.c

[Peter Crosthwaite]

On Sun, Jul 5, 2015 at 11:15 PM, Serge Vakulenko
 wrote:
> Implement access to SD card, attached to pic32 SPI port.
>

Can you use sd.c SD card definition?

> Signed-off-by: Serge Vakulenko 
> ---
>  hw/mips/pic32_sdcard.c | 428 
> +
>  1 file changed, 428 insertions(+)
>  create mode 100644 hw/mips/pic32_sdcard.c
>
> diff --git a/hw/mips/pic32_sdcard.c b/hw/mips/pic32_sdcard.c
> new file mode 100644
> index 000..7611233
> --- /dev/null
> +++ b/hw/mips/pic32_sdcard.c
> @@ -0,0 +1,428 @@
> +/*
> + * SD/MMC card emulation.
> + *
> + * Copyright (C) 2011-2015 Serge Vakulenko
> + *
> + * Permission to use, copy, modify, and distribute this software
> + * and its documentation for any purpose and without fee is hereby
> + * granted, provided that the above copyright notice appear in all
> + * copies and that both that the copyright notice and this
> + * permission notice and warranty disclaimer appear in supporting
> + * documentation, and that the name of the author not be used in
> + * advertising or publicity pertaining to distribution of the
> + * software without specific, written prior permission.
> + *
> + * The author disclaim all warranties with regard to this
> + * software, including all implied warranties of merchantability
> + * and fitness.  In no event shall the author be liable for any
> + * special, indirect or consequential damages or any damages
> + * whatsoever resulting from loss of use, data or profits, whether
> + * in an action of contract, negligence or other tortious action,
> + * arising out of or in connection with the use or performance of
> + * this software.
> + */
> +#include "hw/hw.h"
> +#include "pic32_peripherals.h"
> +
> +/*
> + * Definitions for MMC/SDC commands.
> + */
> +#define CMD_GO_IDLE (0x40+0)/* CMD0 */
> +#define CMD_SEND_OP_SDC (0x40+41)   /* ACMD41 (SDC) */
> +#define CMD_SET_BLEN(0x40+16)
> +#define CMD_SEND_IF_COND(0x40+8)
> +#define CMD_SEND_CSD(0x40+9)
> +#define CMD_STOP(0x40+12)
> +#define CMD_READ_SINGLE (0x40+17)
> +#define CMD_READ_MULTIPLE   (0x40+18)
> +#define CMD_SET_WBECNT  (0x40+23)   /* ACMD23 */
> +#define CMD_WRITE_SINGLE(0x40+24)
> +#define CMD_WRITE_MULTIPLE  (0x40+25)
> +#define CMD_APP (0x40+55)   /* CMD55 */
> +
> +#define DATA_START_BLOCK0xFE/* start data for single block */
> +#define STOP_TRAN_TOKEN 0xFD/* stop token for write multiple */
> +#define WRITE_MULTIPLE_TOKEN0xFC/* start data for write multiple */
> +
> +/*
> + * TODO: add option to enable tracing.
> + */
> +#define TRACE   0
> +
> +static void read_data(int fd, unsigned offset,
> +unsigned char *buf, unsigned blen)
> +{
> +int result;
> +
> +/* Fill uninitialized blocks by FF: simulate real flash media. */
> +memset(buf, 0xFF, blen);
> +
> +result = pread(fd, buf, blen, offset);
> +if (result < 0) {
> +printf("sdcard: pread failed, %u bytes, offset %#x: %s\n",
> +blen, offset, strerror(errno));
> +return;
> +}
> +if (result != blen) {
> +/* Partial file read, return zeroes. */
> +memset(buf, 0, blen);
> +}
> +#if 0
> +printf("(%#x)\n", offset);
> +int i, k;
> +for (i = 0; i < blen; i += 32) {
> +for (k = 0; k < 32; k++) {
> +printf(" %02x", buf[i+k]);
> +}
> +printf("\n");
> +}
> +#endif
> +}
> +
> +static void write_data(int fd, unsigned offset,
> +unsigned char *buf, unsigned blen)
> +{
> +if (pwrite(fd, buf, blen, offset) != blen) {
> +printf("sdcard: pwrite failed, offset %#x\n", offset);
> +return;
> +}
> +}
> +
> +static void card_reset(sdcard_t *d)
> +{
> +d->select = 0;
> +d->blen = 512;
> +d->count = 0;
> +}
> +
> +/*
> + * Reset sdcard.
> + */
> +void pic32_sdcard_reset(pic32_t *s)
> +{
> +card_reset(&s->sdcard[0]);
> +card_reset(&s->sdcard[1]);
> +}
> +
> +/*
> + * Initialize SD card.
> + */
> +void pic32_sdcard_init(pic32_t *s, int unit, const char *name,
> +const char *filename, int cs_port, int cs_pin)
> +{
> +sdcard_t *d = &s->sdcard[unit];
> +struct stat st;
> +
> +memset(d, 0, sizeof(*d));
> +d->name = name;
> +if (!filename) {
> +/* No SD card installed. */
> +return;
> +}
> +d->gpio_port = cs_port;
> +d->gpio_cs = (cs_pin >= 0) ? (1 << cs_pin) : 0;
> +
> +d->fd = open(filename, O_RDWR);

Storage media is managed by QEMUs block layer rather than devs doing
their own file ops. Using sd.c will handle this for you. Note there is
SPI sd support (although it is a little dated). check ssi-sd.c.

Regards,
Peter

> +if (d->fd < 0) {
> +/* Fatal: no image available. */
> +perror(filename);
> +exit(1);
> +}

Re: [Qemu-devel] [PATCH pic32 v3 11/16] pic32: add file pic32_uart.c

[Peter Crosthwaite]

On Sun, Jul 5, 2015 at 11:14 PM, Serge Vakulenko
 wrote:
> Implement pic32 UART peripheral interface.
>
> Signed-off-by: Serge Vakulenko 
> ---
>  hw/mips/pic32_uart.c | 228 
> +++
>  1 file changed, 228 insertions(+)
>  create mode 100644 hw/mips/pic32_uart.c
>
> diff --git a/hw/mips/pic32_uart.c b/hw/mips/pic32_uart.c
> new file mode 100644
> index 000..34056cf
> --- /dev/null
> +++ b/hw/mips/pic32_uart.c
> @@ -0,0 +1,228 @@
> +/*
> + * UART ports.
> + *
> + * Copyright (C) 2014-2015 Serge Vakulenko
> + *
> + * Permission to use, copy, modify, and distribute this software
> + * and its documentation for any purpose and without fee is hereby
> + * granted, provided that the above copyright notice appear in all
> + * copies and that both that the copyright notice and this
> + * permission notice and warranty disclaimer appear in supporting
> + * documentation, and that the name of the author not be used in
> + * advertising or publicity pertaining to distribution of the
> + * software without specific, written prior permission.
> + *
> + * The author disclaim all warranties with regard to this
> + * software, including all implied warranties of merchantability
> + * and fitness.  In no event shall the author be liable for any
> + * special, indirect or consequential damages or any damages
> + * whatsoever resulting from loss of use, data or profits, whether
> + * in an action of contract, negligence or other tortious action,
> + * arising out of or in connection with the use or performance of
> + * this software.
> + */
> +#include "hw/hw.h"
> +#include "hw/char/serial.h"
> +#include "sysemu/char.h"
> +#include "pic32_peripherals.h"
> +
> +#include "pic32mz.h"
> +
> +#define UART_IRQ_ERR0   /* error irq offset */
> +#define UART_IRQ_RX 1   /* receiver irq offset */
> +#define UART_IRQ_TX 2   /* transmitter irq offset */
> +
> +/*
> + * Read of UxRXREG register.
> + */
> +unsigned pic32_uart_get_char(pic32_t *s, int unit)
> +{
> +uart_t *u = &s->uart[unit];
> +unsigned value;
> +
> +/* Read a byte from input queue. */
> +value = u->rxbyte;
> +VALUE(u->sta) &= ~PIC32_USTA_URXDA;
> +
> +s->irq_clear(s, u->irq + UART_IRQ_RX);
> +return value;
> +}
> +
> +/*
> + * Write to UxTXREG register.
> + */
> +void pic32_uart_put_char(pic32_t *s, int unit, unsigned char byte)
> +{
> +uart_t *u = &s->uart[unit];
> +
> +if (!u->chr) {
> +printf("--- %s(unit = %u) serial port not configured\n",
> +__func__, unit);

helpful messages should use qemu_log. I would wrap this conditional
compile macro so it can be turned off.

> +return;
> +}
> +
> +/* Send the byte. */
> +if (qemu_chr_fe_write(u->chr, &byte, 1) != 1) {

qemu_chr_fe_write_all will brute force it for you with a busy-wait
which is probably better than dropping the char.

> +/* TODO: suspend simulation until serial port ready. */
> +printf("--- %s(unit = %u) failed\n", __func__, unit);
> +return;
> +}
> +
> +if ((VALUE(u->mode) & PIC32_UMODE_ON) &&
> +(VALUE(u->sta) & PIC32_USTA_UTXEN))
> +{
> +VALUE(u->sta) |= PIC32_USTA_UTXBF;
> +VALUE(u->sta) &= ~PIC32_USTA_TRMT;
> +
> +/* Generate TX interrupt with some delay. */

Why? generally we don't try and emulate such delays. Do you have
guests that depend on this delay?

Regards,
Peter

> +timer_mod(u->transmit_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
> +get_ticks_per_sec() / 5000);
> +u->oactive = 1;
> +}
> +}
> +
> +/*
> + * Called before reading a value of UxBRG, UxMODE or UxSTA registers.
> + */
> +void pic32_uart_poll_status(pic32_t *s, int unit)
> +{
> +uart_t *u = &s->uart[unit];
> +
> +/* Keep receiver idle, transmit shift register always empty. */
> +VALUE(u->sta) |= PIC32_USTA_RIDLE;
> +
> +/*printf("<%x>", VALUE(u->sta)); fflush(stdout);*/
> +}
> +
> +/*
> + * Write to UxMODE register.
> + */
> +void pic32_uart_update_mode(pic32_t *s, int unit)
> +{
> +uart_t *u = &s->uart[unit];
> +
> +if (!(VALUE(u->mode) & PIC32_UMODE_ON)) {
> +s->irq_clear(s, u->irq + UART_IRQ_RX);
> +s->irq_clear(s, u->irq + UART_IRQ_TX);
> +VALUE(u->sta) &= ~(PIC32_USTA_URXDA | PIC32_USTA_FERR |
> +   PIC32_USTA_PERR | PIC32_USTA_UTXBF);
> +VALUE(u->sta) |= PIC32_USTA_RIDLE | PIC32_USTA_TRMT;
> +}
> +}
> +
> +/*
> + * Write to UxSTA register.
> + */
> +void pic32_uart_update_status(pic32_t *s, int unit)
> +{
> +uart_t *u = &s->uart[unit];
> +
> +if (!(VALUE(u->sta) & PIC32_USTA_URXEN)) {
> +s->irq_clear(s, u->irq + UART_IRQ_RX);
> +VALUE(u->sta) &= ~(PIC32_USTA_URXDA | PIC32_USTA_FERR |
> +   PIC32_USTA_PERR);
> +}
> +if (!(VALUE(u->sta) & PIC32_USTA_UTXEN)) {
> +s->irq_clear(s, u->irq + UART_IRQ_TX);
> +VAL

[Qemu-devel] [PATCH v5 00/11] Fix exceptions handling for MIPS, PowerPC, and i386

[Pavel Dovgalyuk]

QEMU targets ISAs contain instruction that can break the execution
flow with exceptions. When exception breaks the execution of the translation
block it may corrupt PC and icount values.

This set of patches fixes exception handling for MIPS, PowerPC, and i386 
targets.

Incorrect execution for i386 is causes by exceptions raised by MMU functions.
MMU helper functions are called from generated code and other helper
functions. In both cases they try to get function's return address for
restoring virtual CPU state.

When MMU helper is called from some other helper function
(like helper_maskmov_xmm) through cpu_st* function, the return address
will point to that helper. That is why CPU state cannot be restored in
the case of MMU fault.

This bug can occur when maskmov instruction is located in the middle of the
translation block.

Execution sequence for this example:

TB start:
PC1: instr1
 instr2
PC2: maskmov 
 
PC1: instr1
 instr2
 maskmov

At the start of TB execution guest PC points to instr1. When page fault occurs
QEMU tries to restore guest PC (which should be equal to PC2). It reads host PC
from the call stack and checks whether it points to TB or not. Bug in ldst
helpers implementation provides incorrect host PC, which is not located within
the TB. That's why QEMU cannot recover guest PC and it remains the same (PC1).
After page fault processing QEMU restarts TB and executes instr1 and instr2
for the second time, because guest PC was not recovered.

Bugs in helper functions for other targets do not break the execution in 
regular TCG mode, because PC value is updated before calling the functions 
that can raise an exception. But icount value cannot be updated this way. 
Therefore exceptions make execution in icount mode non-determinisic.
In icount mode every translation block looks as follows:

if icount < n then exit
icount -= n
instr1
instr2
...
instrn
exit

When one of these instructions initiates an exception, icount should be 
restored and adjusted number of instructions should be subtracted from icount
instead of initial n.

tlb_fill function passes retaddr to raise_exception, which allows restoring
current instructions in TB and correct icount calculation.

When exception triggered with other function (e.g. by embedding call to 
exception raising helper into TB), then PC is not passed as retaddr and
correct icount is not recovered. In such cases icount will be decreased 
by the value equal to the size of TB.

This behavior leads to incorrect values of virtual clock and 
non-deterministic execution of the code.

These patches passes pointer to the translation block code to the exception
handler. It allows correct restoring of PC and icount values.

v5 changes:
 * Added helper functions for usermode ldst (as suggested by Aurelien Jarno)
 * Fixed memory helpers for MIPS (as suggested by Aurelien Jarno)
 * Added _ra version of raise_exception functions (as suggested by Richard 
Henderson)
 * Split i386 patch into several parts (as suggested by Richard Henderson)

v4 changes:
 * Fixed exceptions handling for PowerPC
 * Fixed passing of mmu_idx into helpers (as suggested by Aurelien Jarno)
 * Added cpu_loop_exit_restore function (as suggested by Aurelien Jarno)
 * Fixed exceptions handling in compare helper functions for MIPS (as suggested 
by Aurelien Jarno)
 * Removed several CPU state saving calls for MIPS (as suggested by Aurelien 
Jarno)

v3 changes:
 * Modified exception handling for syscall (as suggested by Aurelien Jarno)
 * Removed redundant calls to save_cpu_state (as suggested by Aurelien Jarno)
 * Removed helper_call* functions from softmmu (as suggested by Paolo Bonzini)

v2 changes:
 * Added softmmu functions to pass TB return value into memory operations 
handlers
 * Fixed memory operations handling for MIPS
 * Disabled updates of the PC that are overridden with cpu_restore_state
 * Fixed memory operations and exceptions invoked by i386 helpers

---

Pavel Dovgalyuk (11):
  softmmu: add helper function to pass through retaddr
  cpu-exec: introduce loop exit with restore function
  target-mips: improve exceptions handling
  target-i386: introduce new raise_exception functions
  target-i386: exception handling for FPU instructions
  target-i386: exception handling for div instructions
  target-i386: exception handling for memory helpers
  target-i386: exception handling for seg_helper functions
  target-i386: exception handling for other helper functions
  target-i386: remove useless PC updates
  target-ppc: exceptions handling in icount mode


 cpu-exec.c|9 
 include/exec/cpu_ldst_template.h  |   59 ++-
 include/exec/cpu_ldst_useronly_template.h |   25 +
 include/exec/exec-all.h   |1 
 softmmu_template.h|6 
 target-i386/cc_helper.c   |2 
 target-i386/cpu.h |4 
 target-i386/excp_helper.c   

[Qemu-devel] [PATCH v5 02/11] cpu-exec: introduce loop exit with restore function

[Pavel Dovgalyuk]

This patch introduces loop exit function, which also
restores guest CPU state according to the value of host
program counter.

Reviewed-by: Richard Henderson 
Reviewed-by: Aurelien Jarno 

Signed-off-by: Pavel Dovgalyuk 
---
 cpu-exec.c  |9 +
 include/exec/exec-all.h |1 +
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/cpu-exec.c b/cpu-exec.c
index 0734af2..0b5449e 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -134,6 +134,15 @@ void cpu_loop_exit(CPUState *cpu)
 siglongjmp(cpu->jmp_env, 1);
 }
 
+void cpu_loop_exit_restore(CPUState *cpu, uintptr_t pc)
+{
+if (pc) {
+cpu_restore_state(cpu, pc);
+}
+cpu->current_tb = NULL;
+siglongjmp(cpu->jmp_env, 1);
+}
+
 /* exit the current TB from a signal handler. The host registers are
restored in a state compatible with the CPU emulator
  */
diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
index 682cb07..6a0ccb6 100644
--- a/include/exec/exec-all.h
+++ b/include/exec/exec-all.h
@@ -90,6 +90,7 @@ TranslationBlock *tb_gen_code(CPUState *cpu,
   int cflags);
 void cpu_exec_init(CPUArchState *env);
 void QEMU_NORETURN cpu_loop_exit(CPUState *cpu);
+void QEMU_NORETURN cpu_loop_exit_restore(CPUState *cpu, uintptr_t pc);
 
 #if !defined(CONFIG_USER_ONLY)
 //bool qemu_in_vcpu_thread(void);

[Qemu-devel] [PATCH v5 04/11] target-i386: introduce new raise_exception functions

[Pavel Dovgalyuk]

This patch introduces new versions of raise_exception functions
that receive TB return address as an argument.

Signed-off-by: Pavel Dovgalyuk 
---
 target-i386/cpu.h |4 
 target-i386/excp_helper.c |   26 +++---
 2 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 603aaf0..e7005a6 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -1263,8 +1263,12 @@ void cpu_x86_inject_mce(Monitor *mon, X86CPU *cpu, int 
bank,
 
 /* excp_helper.c */
 void QEMU_NORETURN raise_exception(CPUX86State *env, int exception_index);
+void QEMU_NORETURN raise_exception_ra(CPUX86State *env, int exception_index,
+  uintptr_t retaddr);
 void QEMU_NORETURN raise_exception_err(CPUX86State *env, int exception_index,
int error_code);
+void QEMU_NORETURN raise_exception_err_ra(CPUX86State *env, int 
exception_index,
+  int error_code, uintptr_t retaddr);
 void QEMU_NORETURN raise_interrupt(CPUX86State *nenv, int intno, int is_int,
int error_code, int next_eip_addend);
 
diff --git a/target-i386/excp_helper.c b/target-i386/excp_helper.c
index 99fca84..bc2092e 100644
--- a/target-i386/excp_helper.c
+++ b/target-i386/excp_helper.c
@@ -23,10 +23,10 @@
 #include "exec/helper-proto.h"
 
 #if 0
-#define raise_exception_err(env, a, b)  \
+#define raise_exception_err(env, a, b, c)   \
 do {\
 qemu_log("raise_exception line=%d\n", __LINE__);\
-(raise_exception_err)(env, a, b);   \
+(raise_exception_err)(env, a, b, c);\
 } while (0)
 #endif
 
@@ -92,7 +92,8 @@ static int check_exception(CPUX86State *env, int intno, int 
*error_code)
  */
 static void QEMU_NORETURN raise_interrupt2(CPUX86State *env, int intno,
int is_int, int error_code,
-   int next_eip_addend)
+   int next_eip_addend,
+   uintptr_t retaddr)
 {
 CPUState *cs = CPU(x86_env_get_cpu(env));
 
@@ -108,7 +109,7 @@ static void QEMU_NORETURN raise_interrupt2(CPUX86State 
*env, int intno,
 env->error_code = error_code;
 env->exception_is_int = is_int;
 env->exception_next_eip = env->eip + next_eip_addend;
-cpu_loop_exit(cs);
+cpu_loop_exit_restore(cs, retaddr);
 }
 
 /* shortcuts to generate exceptions */
@@ -116,16 +117,27 @@ static void QEMU_NORETURN raise_interrupt2(CPUX86State 
*env, int intno,
 void QEMU_NORETURN raise_interrupt(CPUX86State *env, int intno, int is_int,
int error_code, int next_eip_addend)
 {
-raise_interrupt2(env, intno, is_int, error_code, next_eip_addend);
+raise_interrupt2(env, intno, is_int, error_code, next_eip_addend, 0);
 }
 
 void raise_exception_err(CPUX86State *env, int exception_index,
  int error_code)
 {
-raise_interrupt2(env, exception_index, 0, error_code, 0);
+raise_interrupt2(env, exception_index, 0, error_code, 0, 0);
+}
+
+void raise_exception_err_ra(CPUX86State *env, int exception_index,
+int error_code, uintptr_t retaddr)
+{
+raise_interrupt2(env, exception_index, 0, error_code, 0, retaddr);
 }
 
 void raise_exception(CPUX86State *env, int exception_index)
 {
-raise_interrupt2(env, exception_index, 0, 0, 0);
+raise_interrupt2(env, exception_index, 0, 0, 0, 0);
+}
+
+void raise_exception_ra(CPUX86State *env, int exception_index, uintptr_t 
retaddr)
+{
+raise_interrupt2(env, exception_index, 0, 0, 0, retaddr);
 }

[Qemu-devel] [PATCH v5 09/11] target-i386: exception handling for other helper functions

[Pavel Dovgalyuk]

This patch fixes exception handling for other helper functions.

Signed-off-by: Pavel Dovgalyuk 
---
 target-i386/cc_helper.c   |2 +-
 target-i386/misc_helper.c |   10 +-
 target-i386/ops_sse.h |2 +-
 target-i386/svm_helper.c  |4 ++--
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/target-i386/cc_helper.c b/target-i386/cc_helper.c
index ecbf0ec..d5b7c7b 100644
--- a/target-i386/cc_helper.c
+++ b/target-i386/cc_helper.c
@@ -378,7 +378,7 @@ void helper_sti_vm(CPUX86State *env)
 {
 env->eflags |= VIF_MASK;
 if (env->eflags & VIP_MASK) {
-raise_exception(env, EXCP0D_GPF);
+raise_exception_ra(env, EXCP0D_GPF, GETPC());
 }
 }
 #endif
diff --git a/target-i386/misc_helper.c b/target-i386/misc_helper.c
index 52c5d65..c8e7ee9 100644
--- a/target-i386/misc_helper.c
+++ b/target-i386/misc_helper.c
@@ -220,7 +220,7 @@ void helper_rdtsc(CPUX86State *env)
 uint64_t val;
 
 if ((env->cr[4] & CR4_TSD_MASK) && ((env->hflags & HF_CPL_MASK) != 0)) {
-raise_exception(env, EXCP0D_GPF);
+raise_exception_ra(env, EXCP0D_GPF, GETPC());
 }
 cpu_svm_check_intercept_param(env, SVM_EXIT_RDTSC, 0);
 
@@ -238,13 +238,13 @@ void helper_rdtscp(CPUX86State *env)
 void helper_rdpmc(CPUX86State *env)
 {
 if ((env->cr[4] & CR4_PCE_MASK) && ((env->hflags & HF_CPL_MASK) != 0)) {
-raise_exception(env, EXCP0D_GPF);
+raise_exception_ra(env, EXCP0D_GPF, GETPC());
 }
 cpu_svm_check_intercept_param(env, SVM_EXIT_RDPMC, 0);
 
 /* currently unimplemented */
 qemu_log_mask(LOG_UNIMP, "x86: unimplemented rdpmc\n");
-raise_exception_err(env, EXCP06_ILLOP, 0);
+raise_exception_err_ra(env, EXCP06_ILLOP, 0, GETPC());
 }
 
 #if defined(CONFIG_USER_ONLY)
@@ -589,7 +589,7 @@ void helper_hlt(CPUX86State *env, int next_eip_addend)
 void helper_monitor(CPUX86State *env, target_ulong ptr)
 {
 if ((uint32_t)env->regs[R_ECX] != 0) {
-raise_exception(env, EXCP0D_GPF);
+raise_exception_ra(env, EXCP0D_GPF, GETPC());
 }
 /* XXX: store address? */
 cpu_svm_check_intercept_param(env, SVM_EXIT_MONITOR, 0);
@@ -601,7 +601,7 @@ void helper_mwait(CPUX86State *env, int next_eip_addend)
 X86CPU *cpu;
 
 if ((uint32_t)env->regs[R_ECX] != 0) {
-raise_exception(env, EXCP0D_GPF);
+raise_exception_ra(env, EXCP0D_GPF, GETPC());
 }
 cpu_svm_check_intercept_param(env, SVM_EXIT_MWAIT, 0);
 env->eip += next_eip_addend;
diff --git a/target-i386/ops_sse.h b/target-i386/ops_sse.h
index 0765073..8c8e53b 100644
--- a/target-i386/ops_sse.h
+++ b/target-i386/ops_sse.h
@@ -483,7 +483,7 @@ void glue(helper_maskmov, SUFFIX)(CPUX86State *env, Reg *d, 
Reg *s,
 
 for (i = 0; i < (8 << SHIFT); i++) {
 if (s->B(i) & 0x80) {
-cpu_stb_data(env, a0 + i, d->B(i));
+cpu_stb_data_ra(env, a0 + i, d->B(i), GETPC());
 }
 }
 }
diff --git a/target-i386/svm_helper.c b/target-i386/svm_helper.c
index f1fabf5..cc8c2ec 100644
--- a/target-i386/svm_helper.c
+++ b/target-i386/svm_helper.c
@@ -354,7 +354,7 @@ void helper_vmrun(CPUX86State *env, int aflag, int 
next_eip_addend)
 void helper_vmmcall(CPUX86State *env)
 {
 cpu_svm_check_intercept_param(env, SVM_EXIT_VMMCALL, 0);
-raise_exception(env, EXCP06_ILLOP);
+raise_exception_ra(env, EXCP06_ILLOP, GETPC());
 }
 
 void helper_vmload(CPUX86State *env, int aflag)
@@ -457,7 +457,7 @@ void helper_skinit(CPUX86State *env)
 {
 cpu_svm_check_intercept_param(env, SVM_EXIT_SKINIT, 0);
 /* XXX: not implemented */
-raise_exception(env, EXCP06_ILLOP);
+raise_exception_ra(env, EXCP06_ILLOP, GETPC());
 }
 
 void helper_invlpga(CPUX86State *env, int aflag)

[Qemu-devel] [PATCH v5 01/11] softmmu: add helper function to pass through retaddr

[Pavel Dovgalyuk]

This patch introduces several helpers to pass return address
which points to the TB. Correct return address allows correct
restoring of the guest PC and icount. These functions should be used when
helpers embedded into TB invoke memory operations.

Reviewed-by: Richard Henderson 

Signed-off-by: Pavel Dovgalyuk 
---
 include/exec/cpu_ldst_template.h  |   59 +
 include/exec/cpu_ldst_useronly_template.h |   25 
 softmmu_template.h|6 ---
 tcg/tcg.h |   23 +++
 4 files changed, 99 insertions(+), 14 deletions(-)

diff --git a/include/exec/cpu_ldst_template.h b/include/exec/cpu_ldst_template.h
index 95ab750..3091c00 100644
--- a/include/exec/cpu_ldst_template.h
+++ b/include/exec/cpu_ldst_template.h
@@ -27,20 +27,24 @@
 #define SUFFIX q
 #define USUFFIX q
 #define DATA_TYPE uint64_t
+#define SHIFT 3
 #elif DATA_SIZE == 4
 #define SUFFIX l
 #define USUFFIX l
 #define DATA_TYPE uint32_t
+#define SHIFT 2
 #elif DATA_SIZE == 2
 #define SUFFIX w
 #define USUFFIX uw
 #define DATA_TYPE uint16_t
 #define DATA_STYPE int16_t
+#define SHIFT 1
 #elif DATA_SIZE == 1
 #define SUFFIX b
 #define USUFFIX ub
 #define DATA_TYPE uint8_t
 #define DATA_STYPE int8_t
+#define SHIFT 0
 #else
 #error unsupported data size
 #endif
@@ -54,27 +58,36 @@
 #ifdef SOFTMMU_CODE_ACCESS
 #define ADDR_READ addr_code
 #define MMUSUFFIX _cmmu
+#define URETSUFFIX SUFFIX
+#define SRETSUFFIX SUFFIX
 #else
 #define ADDR_READ addr_read
 #define MMUSUFFIX _mmu
+#define URETSUFFIX USUFFIX
+#define SRETSUFFIX glue(s, SUFFIX)
 #endif
 
 /* generic load/store macros */
 
 static inline RES_TYPE
-glue(glue(cpu_ld, USUFFIX), MEMSUFFIX)(CPUArchState *env, target_ulong ptr)
+glue(glue(glue(cpu_ld, USUFFIX), MEMSUFFIX), _ra)(CPUArchState *env,
+  target_ulong ptr,
+  uintptr_t retaddr)
 {
 int page_index;
 RES_TYPE res;
 target_ulong addr;
 int mmu_idx;
+TCGMemOpIdx oi;
 
 addr = ptr;
 page_index = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);
 mmu_idx = CPU_MMU_INDEX;
 if (unlikely(env->tlb_table[mmu_idx][page_index].ADDR_READ !=
  (addr & (TARGET_PAGE_MASK | (DATA_SIZE - 1) {
-res = glue(glue(helper_ld, SUFFIX), MMUSUFFIX)(env, addr, mmu_idx);
+oi = make_memop_idx(SHIFT, mmu_idx);
+res = glue(glue(helper_ret_ld, URETSUFFIX), MMUSUFFIX)(env, addr,
+oi, retaddr);
 } else {
 uintptr_t hostaddr = addr + env->tlb_table[mmu_idx][page_index].addend;
 res = glue(glue(ld, USUFFIX), _p)((uint8_t *)hostaddr);
@@ -82,27 +95,43 @@ glue(glue(cpu_ld, USUFFIX), MEMSUFFIX)(CPUArchState *env, 
target_ulong ptr)
 return res;
 }
 
+static inline RES_TYPE
+glue(glue(cpu_ld, USUFFIX), MEMSUFFIX)(CPUArchState *env, target_ulong ptr)
+{
+return glue(glue(glue(cpu_ld, USUFFIX), MEMSUFFIX), _ra)(env, ptr, 0);
+}
+
 #if DATA_SIZE <= 2
 static inline int
-glue(glue(cpu_lds, SUFFIX), MEMSUFFIX)(CPUArchState *env, target_ulong ptr)
+glue(glue(glue(cpu_lds, SUFFIX), MEMSUFFIX), _ra)(CPUArchState *env,
+  target_ulong ptr,
+  uintptr_t retaddr)
 {
 int res, page_index;
 target_ulong addr;
 int mmu_idx;
+TCGMemOpIdx oi;
 
 addr = ptr;
 page_index = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);
 mmu_idx = CPU_MMU_INDEX;
 if (unlikely(env->tlb_table[mmu_idx][page_index].ADDR_READ !=
  (addr & (TARGET_PAGE_MASK | (DATA_SIZE - 1) {
-res = (DATA_STYPE)glue(glue(helper_ld, SUFFIX),
-   MMUSUFFIX)(env, addr, mmu_idx);
+oi = make_memop_idx(SHIFT, mmu_idx);
+res = (DATA_STYPE)glue(glue(helper_ret_ld, SRETSUFFIX),
+   MMUSUFFIX)(env, addr, oi, retaddr);
 } else {
 uintptr_t hostaddr = addr + env->tlb_table[mmu_idx][page_index].addend;
 res = glue(glue(lds, SUFFIX), _p)((uint8_t *)hostaddr);
 }
 return res;
 }
+
+static inline int
+glue(glue(cpu_lds, SUFFIX), MEMSUFFIX)(CPUArchState *env, target_ulong ptr)
+{
+return glue(glue(glue(cpu_lds, SUFFIX), MEMSUFFIX), _ra)(env, ptr, 0);
+}
 #endif
 
 #ifndef SOFTMMU_CODE_ACCESS
@@ -110,25 +139,36 @@ glue(glue(cpu_lds, SUFFIX), MEMSUFFIX)(CPUArchState *env, 
target_ulong ptr)
 /* generic store macro */
 
 static inline void
-glue(glue(cpu_st, SUFFIX), MEMSUFFIX)(CPUArchState *env, target_ulong ptr,
-  RES_TYPE v)
+glue(glue(glue(cpu_st, SUFFIX), MEMSUFFIX), _ra)(CPUArchState *env,
+ target_ulong ptr,
+ RES_TYPE v, uintptr_t retaddr)
 {
 int page_index;
 target_ulong addr;
 int mmu_idx;
+  

[Qemu-devel] [PATCH v5 05/11] target-i386: exception handling for FPU instructions

[Pavel Dovgalyuk]

This patch fixes exception handling for FPU instructions.

Signed-off-by: Pavel Dovgalyuk 
---
 target-i386/fpu_helper.c |  146 +-
 1 files changed, 80 insertions(+), 66 deletions(-)

diff --git a/target-i386/fpu_helper.c b/target-i386/fpu_helper.c
index 30d34d5..360f228 100644
--- a/target-i386/fpu_helper.c
+++ b/target-i386/fpu_helper.c
@@ -68,22 +68,24 @@ static inline void fpop(CPUX86State *env)
 env->fpstt = (env->fpstt + 1) & 7;
 }
 
-static inline floatx80 helper_fldt(CPUX86State *env, target_ulong ptr)
+static inline floatx80 helper_fldt(CPUX86State *env, target_ulong ptr,
+   uintptr_t retaddr)
 {
 CPU_LDoubleU temp;
 
-temp.l.lower = cpu_ldq_data(env, ptr);
-temp.l.upper = cpu_lduw_data(env, ptr + 8);
+temp.l.lower = cpu_ldq_data_ra(env, ptr, retaddr);
+temp.l.upper = cpu_lduw_data_ra(env, ptr + 8, retaddr);
 return temp.d;
 }
 
-static inline void helper_fstt(CPUX86State *env, floatx80 f, target_ulong ptr)
+static inline void helper_fstt(CPUX86State *env, floatx80 f, target_ulong ptr,
+   uintptr_t retaddr)
 {
 CPU_LDoubleU temp;
 
 temp.d = f;
-cpu_stq_data(env, ptr, temp.l.lower);
-cpu_stw_data(env, ptr + 8, temp.l.upper);
+cpu_stq_data_ra(env, ptr, temp.l.lower, retaddr);
+cpu_stw_data_ra(env, ptr + 8, temp.l.upper, retaddr);
 }
 
 /* x87 FPU helpers */
@@ -126,10 +128,10 @@ static inline floatx80 helper_fdiv(CPUX86State *env, 
floatx80 a, floatx80 b)
 return floatx80_div(a, b, &env->fp_status);
 }
 
-static void fpu_raise_exception(CPUX86State *env)
+static void fpu_raise_exception(CPUX86State *env, uintptr_t retaddr)
 {
 if (env->cr[0] & CR0_NE_MASK) {
-raise_exception(env, EXCP10_COPR);
+raise_exception_ra(env, EXCP10_COPR, retaddr);
 }
 #if !defined(CONFIG_USER_ONLY)
 else {
@@ -314,14 +316,14 @@ void helper_fldt_ST0(CPUX86State *env, target_ulong ptr)
 int new_fpstt;
 
 new_fpstt = (env->fpstt - 1) & 7;
-env->fpregs[new_fpstt].d = helper_fldt(env, ptr);
+env->fpregs[new_fpstt].d = helper_fldt(env, ptr, GETPC());
 env->fpstt = new_fpstt;
 env->fptags[new_fpstt] = 0; /* validate stack entry */
 }
 
 void helper_fstt_ST0(CPUX86State *env, target_ulong ptr)
 {
-helper_fstt(env, ST0, ptr);
+helper_fstt(env, ST0, ptr, GETPC());
 }
 
 void helper_fpush(CPUX86State *env)
@@ -604,7 +606,7 @@ void helper_fclex(CPUX86State *env)
 void helper_fwait(CPUX86State *env)
 {
 if (env->fpus & FPUS_SE) {
-fpu_raise_exception(env);
+fpu_raise_exception(env, GETPC());
 }
 }
 
@@ -634,11 +636,11 @@ void helper_fbld_ST0(CPUX86State *env, target_ulong ptr)
 
 val = 0;
 for (i = 8; i >= 0; i--) {
-v = cpu_ldub_data(env, ptr + i);
+v = cpu_ldub_data_ra(env, ptr + i, GETPC());
 val = (val * 100) + ((v >> 4) * 10) + (v & 0xf);
 }
 tmp = int64_to_floatx80(val, &env->fp_status);
-if (cpu_ldub_data(env, ptr + 9) & 0x80) {
+if (cpu_ldub_data_ra(env, ptr + 9, GETPC()) & 0x80) {
 tmp = floatx80_chs(tmp);
 }
 fpush(env);
@@ -655,10 +657,10 @@ void helper_fbst_ST0(CPUX86State *env, target_ulong ptr)
 mem_ref = ptr;
 mem_end = mem_ref + 9;
 if (val < 0) {
-cpu_stb_data(env, mem_end, 0x80);
+cpu_stb_data_ra(env, mem_end, 0x80, GETPC());
 val = -val;
 } else {
-cpu_stb_data(env, mem_end, 0x00);
+cpu_stb_data_ra(env, mem_end, 0x00, GETPC());
 }
 while (mem_ref < mem_end) {
 if (val == 0) {
@@ -667,10 +669,10 @@ void helper_fbst_ST0(CPUX86State *env, target_ulong ptr)
 v = val % 100;
 val = val / 100;
 v = ((v / 10) << 4) | (v % 10);
-cpu_stb_data(env, mem_ref++, v);
+cpu_stb_data_ra(env, mem_ref++, v, GETPC());
 }
 while (mem_ref < mem_end) {
-cpu_stb_data(env, mem_ref++, 0);
+cpu_stb_data_ra(env, mem_ref++, 0, GETPC());
 }
 }
 
@@ -978,7 +980,8 @@ void helper_fxam_ST0(CPUX86State *env)
 }
 }
 
-void helper_fstenv(CPUX86State *env, target_ulong ptr, int data32)
+static void do_fstenv(CPUX86State *env, target_ulong ptr, int data32,
+  uintptr_t retaddr)
 {
 int fpus, fptag, exp, i;
 uint64_t mant;
@@ -1006,37 +1009,43 @@ void helper_fstenv(CPUX86State *env, target_ulong ptr, 
int data32)
 }
 if (data32) {
 /* 32 bit */
-cpu_stl_data(env, ptr, env->fpuc);
-cpu_stl_data(env, ptr + 4, fpus);
-cpu_stl_data(env, ptr + 8, fptag);
-cpu_stl_data(env, ptr + 12, 0); /* fpip */
-cpu_stl_data(env, ptr + 16, 0); /* fpcs */
-cpu_stl_data(env, ptr + 20, 0); /* fpoo */
-cpu_stl_data(env, ptr + 24, 0); /* fpos */
+cpu_stl_data_ra(env, ptr, env->fpuc, retaddr);
+cpu_stl_data_ra(env, ptr + 4, fpus, retaddr);
+cpu_stl_data_ra(env, ptr + 8, fptag, retaddr);
+cpu_stl_data_ra(en

[Qemu-devel] [PATCH v5 06/11] target-i386: exception handling for div instructions

[Pavel Dovgalyuk]

This patch fixes exception handling for div instructions.

Signed-off-by: Pavel Dovgalyuk 
---
 target-i386/int_helper.c |   32 
 1 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/target-i386/int_helper.c b/target-i386/int_helper.c
index b0d78e6..3dcd25f 100644
--- a/target-i386/int_helper.c
+++ b/target-i386/int_helper.c
@@ -48,11 +48,11 @@ void helper_divb_AL(CPUX86State *env, target_ulong t0)
 num = (env->regs[R_EAX] & 0x);
 den = (t0 & 0xff);
 if (den == 0) {
-raise_exception(env, EXCP00_DIVZ);
+raise_exception_ra(env, EXCP00_DIVZ, GETPC());
 }
 q = (num / den);
 if (q > 0xff) {
-raise_exception(env, EXCP00_DIVZ);
+raise_exception_ra(env, EXCP00_DIVZ, GETPC());
 }
 q &= 0xff;
 r = (num % den) & 0xff;
@@ -66,11 +66,11 @@ void helper_idivb_AL(CPUX86State *env, target_ulong t0)
 num = (int16_t)env->regs[R_EAX];
 den = (int8_t)t0;
 if (den == 0) {
-raise_exception(env, EXCP00_DIVZ);
+raise_exception_ra(env, EXCP00_DIVZ, GETPC());
 }
 q = (num / den);
 if (q != (int8_t)q) {
-raise_exception(env, EXCP00_DIVZ);
+raise_exception_ra(env, EXCP00_DIVZ, GETPC());
 }
 q &= 0xff;
 r = (num % den) & 0xff;
@@ -84,11 +84,11 @@ void helper_divw_AX(CPUX86State *env, target_ulong t0)
 num = (env->regs[R_EAX] & 0x) | ((env->regs[R_EDX] & 0x) << 16);
 den = (t0 & 0x);
 if (den == 0) {
-raise_exception(env, EXCP00_DIVZ);
+raise_exception_ra(env, EXCP00_DIVZ, GETPC());
 }
 q = (num / den);
 if (q > 0x) {
-raise_exception(env, EXCP00_DIVZ);
+raise_exception_ra(env, EXCP00_DIVZ, GETPC());
 }
 q &= 0x;
 r = (num % den) & 0x;
@@ -103,11 +103,11 @@ void helper_idivw_AX(CPUX86State *env, target_ulong t0)
 num = (env->regs[R_EAX] & 0x) | ((env->regs[R_EDX] & 0x) << 16);
 den = (int16_t)t0;
 if (den == 0) {
-raise_exception(env, EXCP00_DIVZ);
+raise_exception_ra(env, EXCP00_DIVZ, GETPC());
 }
 q = (num / den);
 if (q != (int16_t)q) {
-raise_exception(env, EXCP00_DIVZ);
+raise_exception_ra(env, EXCP00_DIVZ, GETPC());
 }
 q &= 0x;
 r = (num % den) & 0x;
@@ -123,12 +123,12 @@ void helper_divl_EAX(CPUX86State *env, target_ulong t0)
 num = ((uint32_t)env->regs[R_EAX]) | 
((uint64_t)((uint32_t)env->regs[R_EDX]) << 32);
 den = t0;
 if (den == 0) {
-raise_exception(env, EXCP00_DIVZ);
+raise_exception_ra(env, EXCP00_DIVZ, GETPC());
 }
 q = (num / den);
 r = (num % den);
 if (q > 0x) {
-raise_exception(env, EXCP00_DIVZ);
+raise_exception_ra(env, EXCP00_DIVZ, GETPC());
 }
 env->regs[R_EAX] = (uint32_t)q;
 env->regs[R_EDX] = (uint32_t)r;
@@ -142,12 +142,12 @@ void helper_idivl_EAX(CPUX86State *env, target_ulong t0)
 num = ((uint32_t)env->regs[R_EAX]) | 
((uint64_t)((uint32_t)env->regs[R_EDX]) << 32);
 den = t0;
 if (den == 0) {
-raise_exception(env, EXCP00_DIVZ);
+raise_exception_ra(env, EXCP00_DIVZ, GETPC());
 }
 q = (num / den);
 r = (num % den);
 if (q != (int32_t)q) {
-raise_exception(env, EXCP00_DIVZ);
+raise_exception_ra(env, EXCP00_DIVZ, GETPC());
 }
 env->regs[R_EAX] = (uint32_t)q;
 env->regs[R_EDX] = (uint32_t)r;
@@ -379,12 +379,12 @@ void helper_divq_EAX(CPUX86State *env, target_ulong t0)
 uint64_t r0, r1;
 
 if (t0 == 0) {
-raise_exception(env, EXCP00_DIVZ);
+raise_exception_ra(env, EXCP00_DIVZ, GETPC());
 }
 r0 = env->regs[R_EAX];
 r1 = env->regs[R_EDX];
 if (div64(&r0, &r1, t0)) {
-raise_exception(env, EXCP00_DIVZ);
+raise_exception_ra(env, EXCP00_DIVZ, GETPC());
 }
 env->regs[R_EAX] = r0;
 env->regs[R_EDX] = r1;
@@ -395,12 +395,12 @@ void helper_idivq_EAX(CPUX86State *env, target_ulong t0)
 uint64_t r0, r1;
 
 if (t0 == 0) {
-raise_exception(env, EXCP00_DIVZ);
+raise_exception_ra(env, EXCP00_DIVZ, GETPC());
 }
 r0 = env->regs[R_EAX];
 r1 = env->regs[R_EDX];
 if (idiv64(&r0, &r1, t0)) {
-raise_exception(env, EXCP00_DIVZ);
+raise_exception_ra(env, EXCP00_DIVZ, GETPC());
 }
 env->regs[R_EAX] = r0;
 env->regs[R_EDX] = r1;

[Qemu-devel] [PATCH v5 10/11] target-i386: remove useless PC updates

[Pavel Dovgalyuk]

This patch removes useless PC updates before executing instructions.
PC can be recovered with correct exception handling by using TB return address.

Signed-off-by: Pavel Dovgalyuk 
---
 target-i386/translate.c |   25 -
 1 files changed, 0 insertions(+), 25 deletions(-)

diff --git a/target-i386/translate.c b/target-i386/translate.c
index 7a1bdee..14b3465 100644
--- a/target-i386/translate.c
+++ b/target-i386/translate.c
@@ -2303,7 +2303,6 @@ static void gen_movl_seg_T0(DisasContext *s, int seg_reg, 
target_ulong cur_eip)
 if (s->pe && !s->vm86) {
 /* XXX: optimize by finding processor state dynamically */
 gen_update_cc_op(s);
-gen_jmp_im(cur_eip);
 tcg_gen_trunc_tl_i32(cpu_tmp2_i32, cpu_T[0]);
 gen_helper_load_seg(cpu_env, tcg_const_i32(seg_reg), cpu_tmp2_i32);
 /* abort translation because the addseg value may change or
@@ -4842,21 +4841,17 @@ static target_ulong disas_insn(CPUX86State *env, 
DisasContext *s,
 case 6: /* div */
 switch(ot) {
 case MO_8:
-gen_jmp_im(pc_start - s->cs_base);
 gen_helper_divb_AL(cpu_env, cpu_T[0]);
 break;
 case MO_16:
-gen_jmp_im(pc_start - s->cs_base);
 gen_helper_divw_AX(cpu_env, cpu_T[0]);
 break;
 default:
 case MO_32:
-gen_jmp_im(pc_start - s->cs_base);
 gen_helper_divl_EAX(cpu_env, cpu_T[0]);
 break;
 #ifdef TARGET_X86_64
 case MO_64:
-gen_jmp_im(pc_start - s->cs_base);
 gen_helper_divq_EAX(cpu_env, cpu_T[0]);
 break;
 #endif
@@ -4865,21 +4860,17 @@ static target_ulong disas_insn(CPUX86State *env, 
DisasContext *s,
 case 7: /* idiv */
 switch(ot) {
 case MO_8:
-gen_jmp_im(pc_start - s->cs_base);
 gen_helper_idivb_AL(cpu_env, cpu_T[0]);
 break;
 case MO_16:
-gen_jmp_im(pc_start - s->cs_base);
 gen_helper_idivw_AX(cpu_env, cpu_T[0]);
 break;
 default:
 case MO_32:
-gen_jmp_im(pc_start - s->cs_base);
 gen_helper_idivl_EAX(cpu_env, cpu_T[0]);
 break;
 #ifdef TARGET_X86_64
 case MO_64:
-gen_jmp_im(pc_start - s->cs_base);
 gen_helper_idivq_EAX(cpu_env, cpu_T[0]);
 break;
 #endif
@@ -5212,7 +5203,6 @@ static target_ulong disas_insn(CPUX86State *env, 
DisasContext *s,
 if (dflag == MO_64) {
 if (!(s->cpuid_ext_features & CPUID_EXT_CX16))
 goto illegal_op;
-gen_jmp_im(pc_start - s->cs_base);
 gen_update_cc_op(s);
 gen_lea_modrm(env, s, modrm);
 gen_helper_cmpxchg16b(cpu_env, cpu_A0);
@@ -5221,7 +5211,6 @@ static target_ulong disas_insn(CPUX86State *env, 
DisasContext *s,
 {
 if (!(s->cpuid_features & CPUID_CX8))
 goto illegal_op;
-gen_jmp_im(pc_start - s->cs_base);
 gen_update_cc_op(s);
 gen_lea_modrm(env, s, modrm);
 gen_helper_cmpxchg8b(cpu_env, cpu_A0);
@@ -5838,7 +5827,6 @@ static target_ulong disas_insn(CPUX86State *env, 
DisasContext *s,
 break;
 case 0x0c: /* fldenv mem */
 gen_update_cc_op(s);
-gen_jmp_im(pc_start - s->cs_base);
 gen_helper_fldenv(cpu_env, cpu_A0, tcg_const_i32(dflag - 1));
 break;
 case 0x0d: /* fldcw mem */
@@ -5848,7 +5836,6 @@ static target_ulong disas_insn(CPUX86State *env, 
DisasContext *s,
 break;
 case 0x0e: /* fnstenv mem */
 gen_update_cc_op(s);
-gen_jmp_im(pc_start - s->cs_base);
 gen_helper_fstenv(cpu_env, cpu_A0, tcg_const_i32(dflag - 1));
 break;
 case 0x0f: /* fnstcw mem */
@@ -5858,23 +5845,19 @@ static target_ulong disas_insn(CPUX86State *env, 
DisasContext *s,
 break;
 case 0x1d: /* fldt mem */
 gen_update_cc_op(s);
-gen_jmp_im(pc_start - s->cs_base);
 gen_helper_fldt_ST0(cpu_env, cpu_A0);
 break;
 case 0x1f: /* fstpt mem */
 gen_update_cc_op(s);
-gen_jmp_im(pc_start - s->cs_base);
 gen_helper_fstt_ST0(cpu_env, cpu_A0);
 gen_helper_fpop(cpu_env);
 break;
 case 0x2c: /* frstor mem */
 gen_update_cc_op(s);
-gen_jmp_im(pc_start - s->cs_base);
 gen_helper_frstor(cpu_env, cpu_A0, tcg_const_i32(dflag - 1));
 break;
 case 0x2e: /* fnsave mem */
 gen_update_cc_op(s);
-  

[Qemu-devel] [PATCH v5 08/11] target-i386: exception handling for seg_helper functions

[Pavel Dovgalyuk]

This patch fixes exception handling for seg_helper functions.

Signed-off-by: Pavel Dovgalyuk 
---
 target-i386/seg_helper.c |  646 +++---
 1 files changed, 330 insertions(+), 316 deletions(-)

diff --git a/target-i386/seg_helper.c b/target-i386/seg_helper.c
index a99475c..315caab 100644
--- a/target-i386/seg_helper.c
+++ b/target-i386/seg_helper.c
@@ -68,7 +68,8 @@
 
 /* return non zero if error */
 static inline int load_segment(CPUX86State *env, uint32_t *e1_ptr,
-   uint32_t *e2_ptr, int selector)
+   uint32_t *e2_ptr, int selector,
+   uintptr_t retaddr)
 {
 SegmentCache *dt;
 int index;
@@ -84,8 +85,8 @@ static inline int load_segment(CPUX86State *env, uint32_t 
*e1_ptr,
 return -1;
 }
 ptr = dt->base + index;
-*e1_ptr = cpu_ldl_kernel(env, ptr);
-*e2_ptr = cpu_ldl_kernel(env, ptr + 4);
+*e1_ptr = cpu_ldl_kernel_ra(env, ptr, retaddr);
+*e2_ptr = cpu_ldl_kernel_ra(env, ptr + 4, retaddr);
 return 0;
 }
 
@@ -124,7 +125,8 @@ static inline void load_seg_vm(CPUX86State *env, int seg, 
int selector)
 }
 
 static inline void get_ss_esp_from_tss(CPUX86State *env, uint32_t *ss_ptr,
-   uint32_t *esp_ptr, int dpl)
+   uint32_t *esp_ptr, int dpl,
+   uintptr_t retaddr)
 {
 X86CPU *cpu = x86_env_get_cpu(env);
 int type, index, shift;
@@ -153,60 +155,61 @@ static inline void get_ss_esp_from_tss(CPUX86State *env, 
uint32_t *ss_ptr,
 shift = type >> 3;
 index = (dpl * 4 + 2) << shift;
 if (index + (4 << shift) - 1 > env->tr.limit) {
-raise_exception_err(env, EXCP0A_TSS, env->tr.selector & 0xfffc);
+raise_exception_err_ra(env, EXCP0A_TSS, env->tr.selector & 0xfffc, 
retaddr);
 }
 if (shift == 0) {
-*esp_ptr = cpu_lduw_kernel(env, env->tr.base + index);
-*ss_ptr = cpu_lduw_kernel(env, env->tr.base + index + 2);
+*esp_ptr = cpu_lduw_kernel_ra(env, env->tr.base + index, retaddr);
+*ss_ptr = cpu_lduw_kernel_ra(env, env->tr.base + index + 2, retaddr);
 } else {
-*esp_ptr = cpu_ldl_kernel(env, env->tr.base + index);
-*ss_ptr = cpu_lduw_kernel(env, env->tr.base + index + 4);
+*esp_ptr = cpu_ldl_kernel_ra(env, env->tr.base + index, retaddr);
+*ss_ptr = cpu_lduw_kernel_ra(env, env->tr.base + index + 4, retaddr);
 }
 }
 
-static void tss_load_seg(CPUX86State *env, int seg_reg, int selector, int cpl)
+static void tss_load_seg(CPUX86State *env, int seg_reg, int selector, int cpl,
+ uintptr_t retaddr)
 {
 uint32_t e1, e2;
 int rpl, dpl;
 
 if ((selector & 0xfffc) != 0) {
-if (load_segment(env, &e1, &e2, selector) != 0) {
-raise_exception_err(env, EXCP0A_TSS, selector & 0xfffc);
+if (load_segment(env, &e1, &e2, selector, retaddr) != 0) {
+raise_exception_err_ra(env, EXCP0A_TSS, selector & 0xfffc, 
retaddr);
 }
 if (!(e2 & DESC_S_MASK)) {
-raise_exception_err(env, EXCP0A_TSS, selector & 0xfffc);
+raise_exception_err_ra(env, EXCP0A_TSS, selector & 0xfffc, 
retaddr);
 }
 rpl = selector & 3;
 dpl = (e2 >> DESC_DPL_SHIFT) & 3;
 if (seg_reg == R_CS) {
 if (!(e2 & DESC_CS_MASK)) {
-raise_exception_err(env, EXCP0A_TSS, selector & 0xfffc);
+raise_exception_err_ra(env, EXCP0A_TSS, selector & 0xfffc, 
retaddr);
 }
 if (dpl != rpl) {
-raise_exception_err(env, EXCP0A_TSS, selector & 0xfffc);
+raise_exception_err_ra(env, EXCP0A_TSS, selector & 0xfffc, 
retaddr);
 }
 } else if (seg_reg == R_SS) {
 /* SS must be writable data */
 if ((e2 & DESC_CS_MASK) || !(e2 & DESC_W_MASK)) {
-raise_exception_err(env, EXCP0A_TSS, selector & 0xfffc);
+raise_exception_err_ra(env, EXCP0A_TSS, selector & 0xfffc, 
retaddr);
 }
 if (dpl != cpl || dpl != rpl) {
-raise_exception_err(env, EXCP0A_TSS, selector & 0xfffc);
+raise_exception_err_ra(env, EXCP0A_TSS, selector & 0xfffc, 
retaddr);
 }
 } else {
 /* not readable code */
 if ((e2 & DESC_CS_MASK) && !(e2 & DESC_R_MASK)) {
-raise_exception_err(env, EXCP0A_TSS, selector & 0xfffc);
+raise_exception_err_ra(env, EXCP0A_TSS, selector & 0xfffc, 
retaddr);
 }
 /* if data or non conforming code, checks the rights */
 if (((e2 >> DESC_TYPE_SHIFT) & 0xf) < 12) {
 if (dpl < cpl || dpl < rpl) {
-raise_exception_err(env, EXCP0A_TSS, selector & 0xfffc);
+raise_exception_err_ra(env, EXCP0A_TSS, selector & 0

[Qemu-devel] [PATCH v5 03/11] target-mips: improve exceptions handling

[Pavel Dovgalyuk]

This patch improves exception handling in MIPS.
Instructions generate several types of exceptions.
When exception is generated, it breaks the execution of the current translation
block. Implementation of the exceptions handling does not correctly
restore icount for the instruction which caused the exception. In most cases
icount will be decreased by the value equal to the size of TB.
This patch passes pointer to the translation block internals to the exception
handler. It allows correct restoring of the icount value.

v3 changes:
This patch stops translation when instruction which always generates exception
is translated. This improves the performance of the patched version compared
to original one.

Signed-off-by: Pavel Dovgalyuk 
---
 target-mips/cpu.h|   23 +++
 target-mips/helper.h |1 
 target-mips/msa_helper.c |  158 +++-
 target-mips/op_helper.c  |  169 ++---
 target-mips/translate.c  |  363 ++
 5 files changed, 359 insertions(+), 355 deletions(-)

diff --git a/target-mips/cpu.h b/target-mips/cpu.h
index 474a0e3..ae3d772 100644
--- a/target-mips/cpu.h
+++ b/target-mips/cpu.h
@@ -1049,4 +1049,27 @@ static inline void cpu_mips_store_cause(CPUMIPSState 
*env, target_ulong val)
 }
 #endif
 
+static inline void QEMU_NORETURN do_raise_exception_err(CPUMIPSState *env,
+uint32_t exception,
+int error_code,
+uintptr_t pc)
+{
+CPUState *cs = CPU(mips_env_get_cpu(env));
+
+if (exception < EXCP_SC) {
+qemu_log("%s: %d %d\n", __func__, exception, error_code);
+}
+cs->exception_index = exception;
+env->error_code = error_code;
+
+cpu_loop_exit_restore(cs, pc);
+}
+
+static inline void QEMU_NORETURN do_raise_exception(CPUMIPSState *env,
+uint32_t exception,
+uintptr_t pc)
+{
+do_raise_exception_err(env, exception, 0, pc);
+}
+
 #endif /* !defined (__MIPS_CPU_H__) */
diff --git a/target-mips/helper.h b/target-mips/helper.h
index 2b28e87..d8cc766 100644
--- a/target-mips/helper.h
+++ b/target-mips/helper.h
@@ -1,5 +1,6 @@
 DEF_HELPER_3(raise_exception_err, noreturn, env, i32, int)
 DEF_HELPER_2(raise_exception, noreturn, env, i32)
+DEF_HELPER_1(raise_exception_debug, noreturn, env)
 
 DEF_HELPER_1(do_semihosting, void, env)
 
diff --git a/target-mips/msa_helper.c b/target-mips/msa_helper.c
index 26ffdc7..b907b02 100644
--- a/target-mips/msa_helper.c
+++ b/target-mips/msa_helper.c
@@ -1352,7 +1352,7 @@ void helper_msa_ctcmsa(CPUMIPSState *env, target_ulong 
elm, uint32_t cd)
 /* check exception */
 if ((GET_FP_ENABLE(env->active_tc.msacsr) | FP_UNIMPLEMENTED)
 & GET_FP_CAUSE(env->active_tc.msacsr)) {
-helper_raise_exception(env, EXCP_MSAFPE);
+do_raise_exception(env, EXCP_MSAFPE, GETPC());
 }
 break;
 }
@@ -1505,14 +1505,14 @@ static inline void clear_msacsr_cause(CPUMIPSState *env)
 SET_FP_CAUSE(env->active_tc.msacsr, 0);
 }
 
-static inline void check_msacsr_cause(CPUMIPSState *env)
+static inline void check_msacsr_cause(CPUMIPSState *env, uintptr_t retaddr)
 {
 if ((GET_FP_CAUSE(env->active_tc.msacsr) &
 (GET_FP_ENABLE(env->active_tc.msacsr) | FP_UNIMPLEMENTED)) == 0) {
 UPDATE_FP_FLAGS(env->active_tc.msacsr,
 GET_FP_CAUSE(env->active_tc.msacsr));
 } else {
-helper_raise_exception(env, EXCP_MSAFPE);
+do_raise_exception(env, EXCP_MSAFPE, retaddr);
 }
 }
 
@@ -1851,7 +1851,8 @@ static inline int32 float64_to_q32(float64 a, 
float_status *status)
 } while (0)
 
 static inline void compare_af(CPUMIPSState *env, wr_t *pwd, wr_t *pws,
-  wr_t *pwt, uint32_t df, int quiet)
+  wr_t *pwt, uint32_t df, int quiet,
+  uintptr_t retaddr)
 {
 wr_t wx, *pwx = &wx;
 uint32_t i;
@@ -1873,13 +1874,14 @@ static inline void compare_af(CPUMIPSState *env, wr_t 
*pwd, wr_t *pws,
 assert(0);
 }
 
-check_msacsr_cause(env);
+check_msacsr_cause(env, retaddr);
 
 msa_move_v(pwd, pwx);
 }
 
 static inline void compare_un(CPUMIPSState *env, wr_t *pwd, wr_t *pws,
-  wr_t *pwt, uint32_t df, int quiet)
+  wr_t *pwt, uint32_t df, int quiet,
+  uintptr_t retaddr)
 {
 wr_t wx, *pwx = &wx;
 uint32_t i;
@@ -1903,13 +1905,14 @@ static inline void compare_un(CPUMIPSState *env, wr_t 
*pwd, wr_t *pws,
 assert(0);
 }
 
-check_msacsr_cause(env);
+check_msacsr_cause(env, retaddr);
 
 msa_move_v(pwd, pwx);
 }
 
 static inline void compare_eq(CPUMIPSState *env, wr_t *pwd, wr_t *pws,
-

Re: [Qemu-devel] [PATCH COLO-Frame v6 03/31] COLO: migrate colo related info to slave

[Dr. David Alan Gilbert]

* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:
> On 2015/7/4 2:03, Dr. David Alan Gilbert wrote:
> >* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:
> >>We can know if VM in destination should go into COLO mode by refer to
> >>the info that has been migrated from PVM.
> >>
> >>Signed-off-by: zhanghailiang 
> >>Signed-off-by: Yang Hongyang 
> >>Signed-off-by: Lai Jiangshan 
> >>Signed-off-by: Gonglei 
> >>---
> >>  include/migration/migration-colo.h |  2 ++
> >>  migration/Makefile.objs|  1 +
> >>  migration/colo-comm.c  | 47 
> >> ++
> >>  trace-events   |  3 +++
> >>  vl.c   |  5 +++-
> >>  5 files changed, 57 insertions(+), 1 deletion(-)
> >>  create mode 100644 migration/colo-comm.c
> >>
> >>diff --git a/include/migration/migration-colo.h 
> >>b/include/migration/migration-colo.h
> >>index c6d0c51..e20a0c1 100644
> >>--- a/include/migration/migration-colo.h
> >>+++ b/include/migration/migration-colo.h
> >>@@ -14,7 +14,9 @@
> >>  #define QEMU_MIGRATION_COLO_H
> >>
> >>  #include "qemu-common.h"
> >>+#include "migration/migration.h"
> >>
> >>  bool colo_supported(void);
> >>+void colo_info_mig_init(void);
> >>
> >>  #endif
> >>diff --git a/migration/Makefile.objs b/migration/Makefile.objs
> >>index 5a25d39..cb7bd30 100644
> >>--- a/migration/Makefile.objs
> >>+++ b/migration/Makefile.objs
> >>@@ -1,5 +1,6 @@
> >>  common-obj-y += migration.o tcp.o
> >>  common-obj-$(CONFIG_COLO) += colo.o
> >>+common-obj-y += colo-comm.o
> >>  common-obj-y += vmstate.o
> >>  common-obj-y += qemu-file.o qemu-file-buf.o qemu-file-unix.o 
> >> qemu-file-stdio.o
> >>  common-obj-y += xbzrle.o
> >>diff --git a/migration/colo-comm.c b/migration/colo-comm.c
> >>new file mode 100644
> >>index 000..0b76eb4
> >>--- /dev/null
> >>+++ b/migration/colo-comm.c
> >>@@ -0,0 +1,47 @@
> >>+/*
> >>+ * COarse-grain LOck-stepping Virtual Machines for Non-stop Service (COLO)
> >>+ * (a.k.a. Fault Tolerance or Continuous Replication)
> >>+ *
> >>+ * Copyright (c) 2015 HUAWEI TECHNOLOGIES CO., LTD.
> >>+ * Copyright (c) 2015 FUJITSU LIMITED
> >>+ * Copyright (c) 2015 Intel Corporation
> >>+ *
> >>+ * 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 
> >>+#include "trace.h"
> >>+
> >>+static bool colo_requested;
> >>+
> >>+/* save */
> >>+static void colo_info_save(QEMUFile *f, void *opaque)
> >>+{
> >>+qemu_put_byte(f, migrate_enable_colo());
> >>+}
> >>+
> >>+/* restore */
> >>+static int colo_info_load(QEMUFile *f, void *opaque, int version_id)
> >>+{
> >>+int value = qemu_get_byte(f);
> >>+
> >>+if (value && !colo_requested) {
> >>+trace_colo_info_load("COLO request!");
> >>+}
> >>+colo_requested = value;
> >>+
> >>+return 0;
> >>+}
> >>+
> >>+static SaveVMHandlers savevm_colo_info_handlers = {
> >>+.save_state = colo_info_save,
> >>+.load_state = colo_info_load,
> >>+};
> >>+
> >>+void colo_info_mig_init(void)
> >>+{
> >>+register_savevm_live(NULL, "colo", -1, 1,
> >>+ &savevm_colo_info_handlers, NULL);
> >>+}
> >>diff --git a/trace-events b/trace-events
> >>index 52b7efa..3f63019 100644
> >>--- a/trace-events
> >>+++ b/trace-events
> >>@@ -1466,6 +1466,9 @@ rdma_start_incoming_migration_after_rdma_listen(void) 
> >>""
> >>  rdma_start_outgoing_migration_after_rdma_connect(void) ""
> >>  rdma_start_outgoing_migration_after_rdma_source_init(void) ""
> >>
> >>+# migration/colo-comm.c
> >>+colo_info_load(const char *msg) "%s"
> >>+
> >>  # kvm-all.c
> >>  kvm_ioctl(int type, void *arg) "type 0x%x, arg %p"
> >>  kvm_vm_ioctl(int type, void *arg) "type 0x%x, arg %p"
> >>diff --git a/vl.c b/vl.c
> >>index 2201e27..988567a 100644
> >>--- a/vl.c
> >>+++ b/vl.c
> >>@@ -90,6 +90,7 @@ int main(int argc, char **argv)
> >>  #include "sysemu/dma.h"
> >>  #include "audio/audio.h"
> >>  #include "migration/migration.h"
> >>+#include "migration/migration-colo.h"
> >>  #include "sysemu/kvm.h"
> >>  #include "qapi/qmp/qjson.h"
> >>  #include "qemu/option.h"
> >>@@ -4261,7 +4262,9 @@ int main(int argc, char **argv, char **envp)
> >>
> >>  blk_mig_init();
> >>  ram_mig_init();
> >>-
> >>+#ifdef CONFIG_COLO
> >>+colo_info_mig_init();
> >>+#endif
> >
> >Does't this still break migration compatibility?  I wouldn't
> 
> Yes, it will break migration if the QEMU in destination and source not 
> enable/disable (configure) this
> feature together, also not compatible with old version on migration.
> 
> >want to have to have two QEMU builds on a system, one built with COLO
> >and one built without COLO.   You need to arrange for the
> >section to only be sent if COLO is enabled (i.e. migrate_set_capability colo 
> >on).
> >One way to do that would be to use the new QEMU optional sections
> >that Juan added recently.
> >
> 
> Hmm, his method can addre

[Qemu-devel] [PATCH v5 07/11] target-i386: exception handling for memory helpers

[Pavel Dovgalyuk]

This patch fixes exception handling for memory helpers.

Signed-off-by: Pavel Dovgalyuk 
---
 target-i386/mem_helper.c |   39 ++-
 1 files changed, 18 insertions(+), 21 deletions(-)

diff --git a/target-i386/mem_helper.c b/target-i386/mem_helper.c
index 1aec8a5..95b1f53 100644
--- a/target-i386/mem_helper.c
+++ b/target-i386/mem_helper.c
@@ -41,13 +41,14 @@ void helper_cmpxchg8b(CPUX86State *env, target_ulong a0)
 int eflags;
 
 eflags = cpu_cc_compute_all(env, CC_OP);
-d = cpu_ldq_data(env, a0);
+d = cpu_ldq_data_ra(env, a0, GETPC());
 if (d == (((uint64_t)env->regs[R_EDX] << 32) | 
(uint32_t)env->regs[R_EAX])) {
-cpu_stq_data(env, a0, ((uint64_t)env->regs[R_ECX] << 32) | 
(uint32_t)env->regs[R_EBX]);
+cpu_stq_data_ra(env, a0, ((uint64_t)env->regs[R_ECX] << 32)
+  | (uint32_t)env->regs[R_EBX], GETPC());
 eflags |= CC_Z;
 } else {
 /* always do the store */
-cpu_stq_data(env, a0, d);
+cpu_stq_data_ra(env, a0, d, GETPC());
 env->regs[R_EDX] = (uint32_t)(d >> 32);
 env->regs[R_EAX] = (uint32_t)d;
 eflags &= ~CC_Z;
@@ -62,19 +63,19 @@ void helper_cmpxchg16b(CPUX86State *env, target_ulong a0)
 int eflags;
 
 if ((a0 & 0xf) != 0) {
-raise_exception(env, EXCP0D_GPF);
+raise_exception_ra(env, EXCP0D_GPF, GETPC());
 }
 eflags = cpu_cc_compute_all(env, CC_OP);
-d0 = cpu_ldq_data(env, a0);
-d1 = cpu_ldq_data(env, a0 + 8);
+d0 = cpu_ldq_data_ra(env, a0, GETPC());
+d1 = cpu_ldq_data_ra(env, a0 + 8, GETPC());
 if (d0 == env->regs[R_EAX] && d1 == env->regs[R_EDX]) {
-cpu_stq_data(env, a0, env->regs[R_EBX]);
-cpu_stq_data(env, a0 + 8, env->regs[R_ECX]);
+cpu_stq_data_ra(env, a0, env->regs[R_EBX], GETPC());
+cpu_stq_data_ra(env, a0 + 8, env->regs[R_ECX], GETPC());
 eflags |= CC_Z;
 } else {
 /* always do the store */
-cpu_stq_data(env, a0, d0);
-cpu_stq_data(env, a0 + 8, d1);
+cpu_stq_data_ra(env, a0, d0, GETPC());
+cpu_stq_data_ra(env, a0 + 8, d1, GETPC());
 env->regs[R_EDX] = d1;
 env->regs[R_EAX] = d0;
 eflags &= ~CC_Z;
@@ -87,11 +88,11 @@ void helper_boundw(CPUX86State *env, target_ulong a0, int v)
 {
 int low, high;
 
-low = cpu_ldsw_data(env, a0);
-high = cpu_ldsw_data(env, a0 + 2);
+low = cpu_ldsw_data_ra(env, a0, GETPC());
+high = cpu_ldsw_data_ra(env, a0 + 2, GETPC());
 v = (int16_t)v;
 if (v < low || v > high) {
-raise_exception(env, EXCP05_BOUND);
+raise_exception_ra(env, EXCP05_BOUND, GETPC());
 }
 }
 
@@ -99,10 +100,10 @@ void helper_boundl(CPUX86State *env, target_ulong a0, int 
v)
 {
 int low, high;
 
-low = cpu_ldl_data(env, a0);
-high = cpu_ldl_data(env, a0 + 4);
+low = cpu_ldl_data_ra(env, a0, GETPC());
+high = cpu_ldl_data_ra(env, a0 + 4, GETPC());
 if (v < low || v > high) {
-raise_exception(env, EXCP05_BOUND);
+raise_exception_ra(env, EXCP05_BOUND, GETPC());
 }
 }
 
@@ -122,11 +123,7 @@ void tlb_fill(CPUState *cs, target_ulong addr, int 
is_write, int mmu_idx,
 X86CPU *cpu = X86_CPU(cs);
 CPUX86State *env = &cpu->env;
 
-if (retaddr) {
-/* now we have a real cpu fault */
-cpu_restore_state(cs, retaddr);
-}
-raise_exception_err(env, cs->exception_index, env->error_code);
+raise_exception_err_ra(env, cs->exception_index, env->error_code, 
retaddr);
 }
 }
 #endif

[Qemu-devel] [PATCH v5 11/11] target-ppc: exceptions handling in icount mode

[Pavel Dovgalyuk]

This patch fixes exception handling in PowerPC.
Instructions generate several types of exceptions.
When exception is generated, it breaks the execution of the current translation
block. Implementation of the exceptions handling does not correctly
restore icount for the instruction which caused the exception. In most cases
icount will be decreased by the value equal to the size of TB.
This patch passes pointer to the translation block internals to the exception
handler. It allows correct restoring of the icount value.

Signed-off-by: Pavel Dovgalyuk 
---
 target-ppc/cpu.h |3 +
 target-ppc/excp_helper.c |   38 ++--
 target-ppc/fpu_helper.c  |  191 ++
 target-ppc/helper.h  |1 
 target-ppc/mem_helper.c  |6 +
 target-ppc/misc_helper.c |8 +-
 target-ppc/mmu-hash64.c  |   12 +--
 target-ppc/mmu_helper.c  |   18 ++--
 target-ppc/timebase_helper.c |   20 ++--
 target-ppc/translate.c   |   84 +-
 10 files changed, 167 insertions(+), 214 deletions(-)

diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index c05c503..27aaff8 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -2328,4 +2328,7 @@ int ppc_get_vcpu_dt_id(PowerPCCPU *cpu);
  */
 PowerPCCPU *ppc_get_vcpu_by_dt_id(int cpu_dt_id);
 
+void raise_exception_err(CPUPPCState *env, uint32_t exception,
+ uint32_t error_code, uintptr_t pc);
+
 #endif /* !defined (__CPU_PPC_H__) */
diff --git a/target-ppc/excp_helper.c b/target-ppc/excp_helper.c
index b803475..5402e0d 100644
--- a/target-ppc/excp_helper.c
+++ b/target-ppc/excp_helper.c
@@ -846,8 +846,8 @@ static void cpu_dump_rfi(target_ulong RA, target_ulong msr)
 /*/
 /* Exceptions processing helpers */
 
-void helper_raise_exception_err(CPUPPCState *env, uint32_t exception,
-uint32_t error_code)
+void raise_exception_err(CPUPPCState *env, uint32_t exception,
+ uint32_t error_code, uintptr_t pc)
 {
 CPUState *cs = CPU(ppc_env_get_cpu(env));
 
@@ -856,12 +856,29 @@ void helper_raise_exception_err(CPUPPCState *env, 
uint32_t exception,
 #endif
 cs->exception_index = exception;
 env->error_code = error_code;
-cpu_loop_exit(cs);
+cpu_loop_exit_restore(cs, pc);
+}
+
+void helper_raise_exception_err(CPUPPCState *env, uint32_t exception,
+uint32_t error_code)
+{
+raise_exception_err(env, exception, error_code, GETPC());
+}
+
+void helper_raise_exception_end(CPUPPCState *env, uint32_t exception,
+uint32_t error_code)
+{
+raise_exception_err(env, exception, error_code, 0);
 }
 
 void helper_raise_exception(CPUPPCState *env, uint32_t exception)
 {
-helper_raise_exception_err(env, exception, 0);
+raise_exception_err(env, exception, 0, GETPC());
+}
+
+static void raise_exception(CPUPPCState *env, uint32_t exception, uintptr_t pc)
+{
+raise_exception_err(env, exception, 0, pc);
 }
 
 #if !defined(CONFIG_USER_ONLY)
@@ -873,7 +890,8 @@ void helper_store_msr(CPUPPCState *env, target_ulong val)
 if (val != 0) {
 cs = CPU(ppc_env_get_cpu(env));
 cs->interrupt_request |= CPU_INTERRUPT_EXITTB;
-helper_raise_exception(env, val);
+/* nip is updated by generated code */
+raise_exception(env, val, 0);
 }
 }
 
@@ -971,8 +989,9 @@ void helper_tw(CPUPPCState *env, target_ulong arg1, 
target_ulong arg2,
   ((int32_t)arg1 == (int32_t)arg2 && (flags & 0x04)) ||
   ((uint32_t)arg1 < (uint32_t)arg2 && (flags & 0x02)) ||
   ((uint32_t)arg1 > (uint32_t)arg2 && (flags & 0x01) {
-helper_raise_exception_err(env, POWERPC_EXCP_PROGRAM,
-   POWERPC_EXCP_TRAP);
+/* nip is updated in TB */
+raise_exception_err(env, POWERPC_EXCP_PROGRAM,
+POWERPC_EXCP_TRAP, 0);
 }
 }
 
@@ -985,8 +1004,9 @@ void helper_td(CPUPPCState *env, target_ulong arg1, 
target_ulong arg2,
   ((int64_t)arg1 == (int64_t)arg2 && (flags & 0x04)) ||
   ((uint64_t)arg1 < (uint64_t)arg2 && (flags & 0x02)) ||
   ((uint64_t)arg1 > (uint64_t)arg2 && (flags & 0x01) {
-helper_raise_exception_err(env, POWERPC_EXCP_PROGRAM,
-   POWERPC_EXCP_TRAP);
+/* nip is updated in TB */
+raise_exception_err(env, POWERPC_EXCP_PROGRAM,
+POWERPC_EXCP_TRAP, 0);
 }
 }
 #endif
diff --git a/target-ppc/fpu_helper.c b/target-ppc/fpu_helper.c
index 6cceffc..088ad06 100644
--- a/target-ppc/fpu_helper.c
+++ b/target-ppc/fpu_helper.c
@@ -116,7 +116,7 @@ void helper_compute_fprf(CPUPPCState *env, uint64_t arg)
 
 /* Floating-point invalid operations exception */
 static inline uint64_t fload_invalid_op_excp(CPUPPCState *env, 

[Qemu-devel] Can the backing file of qcow2 points to a snapshot of base file?

[vt]

Hi.

If a base qcow2 image snapshot chain like this:

base.qcow2: [A] -> [B] -> [C]

[C] is the current image where guest read/write to,usually we create a new 
image base on the base.qcow2 like this

qemu-img create -f qcow2 -o backing_file=/path/base.qcow2 new.qcow2

so the data of new.qcow2 is from [C] of base.qcow2, assuming the new.qcow2 has 
not been write to since created.

What I want is that the data of new.qcow2 is from [B] of base.qcow2, like this:

qemu-img create -f qcow2 -o backing_file=/path/base.qcow2,backing_snapshot=B  
new.qcow2

Can the qemu support it now?

Thanks



vt

Re: [Qemu-devel] [PATCH] virtio-pci: implement cfg capability

[Michael S. Tsirkin]

On Mon, Jul 06, 2015 at 09:46:14AM +0200, Paolo Bonzini wrote:
> 
> 
> On 04/07/2015 23:19, Michael S. Tsirkin wrote:
> > The fact that address_space_write/_read actually does a byteswap if
> > host!=target endian should probably be documented.
> 
> FWIW, it's not if host != target endian.  It's if memory region
> endianness != target endianness.  See memory_region_wrong_endianness.

Right. What I meant is that if device != host then we want a byteswap
anyway.  E.g. if device says it's BE and system is LE, then it does want
to get byte 0 as MSB in the uint32 it gets.

IOW we want byteswap if host != MR.
Instead we get a byteswap if target != MR.

This is the same unless host != target.


> > Or maybe it should be changed: it seems likely that non-target-specific 
> > devices
> > that use it do this incorrectly ATM. In particular, dma_memory_rw_relaxed 
> > calls
> > address_space_rw and since DMA originates with devices I think there's very
> > little chance that these actually want a different behaviour depending on 
> > the
> > target endian-ness.
> > 
> > Most likely, these only work correctly because DMA outside RAM
> > is highly unusual.
> 
> They work correctly because of that, and because most devices *and*
> targets are little endian so you have no swap.  On ppc64, which has
> TARGET_WORDS_BIGENDIAN, it probably wouldn't work correctly.
> 
> Paolo

Also, by luck, some values work the same whatever the endian-ness.
E.g. dma_memory_set fills the buffer with a given pattern, so
nothing changes if you byte-swap it.

Here's an example that's wrong: dp8393x. Typically it's accessing
memory for DMA, so there's no byteswap. Works fine.

But should device attempt to access another device memory,
it would break because MIPS target is BE.

Cc Hervé for confirmation.

I conclude that virtio is not so special in needing a variant
of address_space_rw that assumes host endian format for the data.

-- 
MST

Re: [Qemu-devel] [PATCH pic32 v2 1/5] Speed of MIPS CPU timer made configurable per platform.

[Aurelien Jarno]

On 2015-07-05 16:25, Serge Vakulenko wrote:
> On Wed, Jul 1, 2015 at 3:02 AM, Aurelien Jarno  wrote:
> > On 2015-06-30 21:12, Serge Vakulenko wrote:
> >> @@ -153,5 +153,6 @@ void cpu_mips_clock_init (CPUMIPSState *env)
> >>   */
> >>  if (!kvm_enabled()) {
> >>  env->timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, &mips_timer_cb, 
> >> env);
> >> +env->count_freq = count_freq;
> >>  }
> >>  }
> >
> > So it means the value passed as an argument to this function is ignored
> > in the KVM case. I guess we want to be able to tell the kernel about the
> > request frequency.
> 
> Sound like a new feature request for MIPS KVM developers. I cannot
> find any such possibility in the current KVM API.

Ok.

> My patch changes nothing for existing platforms like Malta, Fulong or
> MIPSsim. Everything continues to work as it is. Only for pic32mx7 cpu
> the clock rate is decreased to 40MHz. I'm not sure anybody could ever
> run KVM on this processor. :)

Yes, but you give the possibility to tweak the speed, so later someone
might wrongly pass a value different than 100MHz for a CPU usable with
KVM.

The way to go is to do add a comment with an assert:

  if (kvm_enabled()) {
  /* FIXME: KVM only supports a 100MHz clock. */
  assert(count_freq == 100*1000*1000);
  } else {
  env->timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, &mips_timer_cb, env);
  env->count_freq = count_freq;
  }


-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] [PATCH pic32 v2 2/5] Fixed random index generation for TLBWR instruction. It was not quite random and did not skip Wired entries.

[Aurelien Jarno]

On 2015-07-05 17:03, Serge Vakulenko wrote:
> On Wed, Jul 1, 2015 at 3:11 AM, Aurelien Jarno  wrote:
> > On 2015-06-30 21:12, Serge Vakulenko wrote:
> >> Signed-off-by: Serge Vakulenko 
> >> ---
> >>  hw/mips/cputimer.c | 18 +-
> >>  1 file changed, 5 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/hw/mips/cputimer.c b/hw/mips/cputimer.c
> >> index 4f02a9f..94a29df 100644
> >> --- a/hw/mips/cputimer.c
> >> +++ b/hw/mips/cputimer.c
> >> @@ -25,21 +25,13 @@
> >>  #include "qemu/timer.h"
> >>  #include "sysemu/kvm.h"
> >>
> >> -#define TIMER_FREQ   100 * 1000 * 1000
> >> -
> >> -/* XXX: do not use a global */
> >> +/* Generate a random TLB index.
> >> + * Skip wired entries. */
> >>  uint32_t cpu_mips_get_random (CPUMIPSState *env)
> >>  {
> >> -static uint32_t lfsr = 1;
> >> -static uint32_t prev_idx = 0;
> >> -uint32_t idx;
> >> -/* Don't return same value twice, so get another value */
> >> -do {
> >> -lfsr = (lfsr >> 1) ^ (-(lfsr & 1u) & 0xd001u);
> >> -idx = lfsr % (env->tlb->nb_tlb - env->CP0_Wired) + env->CP0_Wired;
> >> -} while (idx == prev_idx);
> >> -prev_idx = idx;
> >> -return idx;
> >> +env->CP0_Random = env->CP0_Wired +
> >> +random() % (env->tlb->nb_tlb - env->CP0_Wired);
> >> +return env->CP0_Random;
> >>  }
> >>
> >>  /* MIPS R4K timer */
> >
> > Can you please give us more details about what issue you are trying to
> > fix there? Especially I don't understand about the "skip wired entries"
> > part. It seems the original code handles the wired entries correctly,
> > and at least your patch doesn't seem to change anything regarded that
> > part.
> 
> The original code looks fine by itself. But when you try to run in for
> nb_tlb=16 and CP0_Wired=1, you get a sequence:
> 
> 15, 6, 7, 2, 7, 2, 7, 2, 7, 2, 7, 2, 7, 2, 7, 2, 7, 2, 7, 2, 7, 2, 7,
> 2, 7, 2, 7, 2...
> 
> This is what happens when 4.4bsd kernel starts on pic32mz processor.
> It makes the VM subsystem a bit crazy. Later the sequence becomes
> better, but I think it makes sense to improve it somehow.
> 

Thanks for the explanation, I know understand the issue and I agree it
should be fixed.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] [PATCH pic32 v2 4/5] Two new processor variants: M4K and microAptivP.

[Aurelien Jarno]

On 2015-07-05 20:48, Serge Vakulenko wrote:
> On Wed, Jul 1, 2015 at 6:37 AM, Aurelien Jarno  wrote:
> > On 2015-06-30 21:12, Serge Vakulenko wrote:
> >> Signed-off-by: Serge Vakulenko 
> >> ---
> >>  target-mips/cpu.h|  2 ++
> >>  target-mips/translate_init.c | 46 
> >> 
> >>  2 files changed, 48 insertions(+)
> >>
> >> diff --git a/target-mips/cpu.h b/target-mips/cpu.h
> >> index ab830ee..9f5890c 100644
> >> --- a/target-mips/cpu.h
> >> +++ b/target-mips/cpu.h
> >> @@ -394,6 +394,7 @@ struct CPUMIPSState {
> >>  #define CP0C0_M31
> >>  #define CP0C0_K23  28
> >>  #define CP0C0_KU   25
> >> +#define CP0C0_SB   21
> >
> > Bits in the range 16:24 are implementation specific, so I do wonder if
> > we want to have this bit there. At least we should mark it as
> > implementation specific.
> 
> I tried to make the configuration as close as possible to a real PIC32
> microcontroller - that's why I added Config0.SB and Config7.WII bits.
> These bits are described in appropriate Microchip docs. As they are
> not relevant for the simulation purposes, I'll better remove them for
> simplicity.

It's fine if they are needed, but I suggest in that case to chose a name
showing it's PIC32 specific, something like CP0C0_PIC32_SB.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] [PATCH pic32 v3 01/16] pic32: make the CPU clock frequency configurable per platform

[Aurelien Jarno]

On 2015-07-05 23:14, Serge Vakulenko wrote:
> Currently the clock rate for all MIPS platforms is fixed at 100MHz.
> Need to make it 40MHz for pic32mx7.
> 
> Signed-off-by: Serge Vakulenko 
> ---
>  hw/mips/cputimer.c| 15 +++
>  hw/mips/mips_fulong2e.c   |  2 +-
>  hw/mips/mips_jazz.c   |  2 +-
>  hw/mips/mips_malta.c  |  4 ++--
>  hw/mips/mips_mipssim.c|  2 +-
>  hw/mips/mips_r4k.c|  2 +-
>  include/hw/mips/cpudevs.h |  2 +-
>  target-mips/cpu.h |  1 +
>  8 files changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/hw/mips/cputimer.c b/hw/mips/cputimer.c
> index 577c9ae..75917cf 100644
> --- a/hw/mips/cputimer.c
> +++ b/hw/mips/cputimer.c
> @@ -25,8 +25,6 @@
>  #include "qemu/timer.h"
>  #include "sysemu/kvm.h"
>  
> -#define TIMER_FREQ   100 * 1000 * 1000
> -
>  /* XXX: do not use a global */
>  uint32_t cpu_mips_get_random (CPUMIPSState *env)
>  {
> @@ -50,8 +48,8 @@ static void cpu_mips_timer_update(CPUMIPSState *env)
>  
>  now = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
>  wait = env->CP0_Compare - env->CP0_Count -
> - (uint32_t)muldiv64(now, TIMER_FREQ, get_ticks_per_sec());
> -next = now + muldiv64(wait, get_ticks_per_sec(), TIMER_FREQ);
> +(uint32_t)muldiv64(now, env->count_freq, get_ticks_per_sec());
> +next = now + muldiv64(wait, get_ticks_per_sec(), env->count_freq);
>  timer_mod(env->timer, next);
>  }
>  
> @@ -80,7 +78,7 @@ uint32_t cpu_mips_get_count (CPUMIPSState *env)
>  }
>  
>  return env->CP0_Count +
> -(uint32_t)muldiv64(now, TIMER_FREQ, get_ticks_per_sec());
> +(uint32_t)muldiv64(now, env->count_freq, get_ticks_per_sec());
>  }
>  }
>  
> @@ -97,7 +95,7 @@ void cpu_mips_store_count (CPUMIPSState *env, uint32_t 
> count)
>  /* Store new count register */
>  env->CP0_Count =
>  count - (uint32_t)muldiv64(qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL),
> -   TIMER_FREQ, get_ticks_per_sec());
> +   env->count_freq, get_ticks_per_sec());
>  /* Update timer timer */
>  cpu_mips_timer_update(env);
>  }
> @@ -122,7 +120,7 @@ void cpu_mips_stop_count(CPUMIPSState *env)
>  {
>  /* Store the current value */
>  env->CP0_Count += 
> (uint32_t)muldiv64(qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL),
> - TIMER_FREQ, get_ticks_per_sec());
> + env->count_freq, 
> get_ticks_per_sec());
>  }
>  
>  static void mips_timer_cb (void *opaque)
> @@ -145,7 +143,7 @@ static void mips_timer_cb (void *opaque)
>  env->CP0_Count--;
>  }
>  
> -void cpu_mips_clock_init (CPUMIPSState *env)
> +void cpu_mips_clock_init(CPUMIPSState *env, unsigned count_freq)
>  {
>  /*
>   * If we're in KVM mode, don't create the periodic timer, that is 
> handled in
> @@ -153,5 +151,6 @@ void cpu_mips_clock_init (CPUMIPSState *env)
>   */
>  if (!kvm_enabled()) {
>  env->timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, &mips_timer_cb, env);
> +env->count_freq = count_freq;
>  }
>  }

As said in my other email, you should check that the requested frequency
is 100MHz in KVM mode, for example with an assert.

Otherwise looks fine.

> diff --git a/hw/mips/mips_fulong2e.c b/hw/mips/mips_fulong2e.c
> index dea941a..5decc30 100644
> --- a/hw/mips/mips_fulong2e.c
> +++ b/hw/mips/mips_fulong2e.c
> @@ -343,7 +343,7 @@ static void mips_fulong2e_init(MachineState *machine)
>  
>  /* Init internal devices */
>  cpu_mips_irq_init_cpu(env);
> -cpu_mips_clock_init(env);
> +cpu_mips_clock_init(env, 100*1000*1000);
>  
>  /* North bridge, Bonito --> IP2 */
>  pci_bus = bonito_init((qemu_irq *)&(env->irq[2]));
> diff --git a/hw/mips/mips_jazz.c b/hw/mips/mips_jazz.c
> index 9d60633..02629fa 100644
> --- a/hw/mips/mips_jazz.c
> +++ b/hw/mips/mips_jazz.c
> @@ -210,7 +210,7 @@ static void mips_jazz_init(MachineState *machine,
>  
>  /* Init CPU internal devices */
>  cpu_mips_irq_init_cpu(env);
> -cpu_mips_clock_init(env);
> +cpu_mips_clock_init(env, 100*1000*1000);
>  
>  /* Chipset */
>  rc4030 = rc4030_init(&dmas, &rc4030_dma_mr);
> diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
> index 3082e75..0393017 100644
> --- a/hw/mips/mips_malta.c
> +++ b/hw/mips/mips_malta.c
> @@ -988,7 +988,7 @@ void mips_malta_init(MachineState *machine)
>  
>  /* Init internal devices */
>  cpu_mips_irq_init_cpu(env);
> -cpu_mips_clock_init(env);
> +cpu_mips_clock_init(env, 100*1000*1000);
>  qemu_register_reset(main_cpu_reset, cpu);
>  }
>  cpu = MIPS_CPU(first_cpu);
> @@ -1144,7 +1144,7 @@ void mips_malta_init(MachineState *machine)
>  
>  /* Init internal devices */
>  cpu_mips_irq_init_cpu(env);
> -cpu_mips_clock_init(env);
> +cpu_mips_clock_init(env, 100*1000*1000);
>  
>  /*
>   * We have a 

Re: [Qemu-devel] [PATCH] cpu_defs: Simplify CPUTLB padding logic

[Paolo Bonzini]

On 05/07/2015 23:08, Peter Crosthwaite wrote:
> There was a complicated subtractive arithmetic for determining the
> padding on the CPUTLBEntry structure. Simplify this with a union.
> 
> Signed-off-by: Peter Crosthwaite 
> ---
>  include/exec/cpu-defs.h | 23 ---
>  1 file changed, 12 insertions(+), 11 deletions(-)
> 
> diff --git a/include/exec/cpu-defs.h b/include/exec/cpu-defs.h
> index 98b9cff..5093be2 100644
> --- a/include/exec/cpu-defs.h
> +++ b/include/exec/cpu-defs.h
> @@ -105,17 +105,18 @@ typedef struct CPUTLBEntry {
> bit 3  : indicates that the entry is invalid
> bit 2..0   : zero
>  */
> -target_ulong addr_read;
> -target_ulong addr_write;
> -target_ulong addr_code;
> -/* Addend to virtual address to get host address.  IO accesses
> -   use the corresponding iotlb value.  */
> -uintptr_t addend;
> -/* padding to get a power of two size */
> -uint8_t dummy[(1 << CPU_TLB_ENTRY_BITS) -
> -  (sizeof(target_ulong) * 3 +
> -   ((-sizeof(target_ulong) * 3) & (sizeof(uintptr_t) - 1)) +
> -   sizeof(uintptr_t))];
> +union {

The struct CPUTLBEntry can be changed to union CPUTLBEntry directly,
with no need for the anonymous struct.

> +struct {
> +target_ulong addr_read;
> +target_ulong addr_write;
> +target_ulong addr_code;
> +/* Addend to virtual address to get host address.  IO accesses
> +   use the corresponding iotlb value.  */
> +uintptr_t addend;
> +};

Which compiler version started implementing anonymous structs?

Or can we just add

 __attribute__((__aligned__(1 << CPU_TLB_ENTRY_BITS)))

to the struct?  I'm not sure if it affects the sizeof too, so that
requires some care.  Alternatively, an

uint8_t padding[0]
__attribute__((__aligned__(1 << CPU_TLB_ENTRY_BITS)));

could maybe work?  Neither is exactly the same, as they also bump the
alignment of the overall struct, but they do not require anonymous structs.

Paolo

> +/* padding to get a power of two size */
> +uint8_t dummy[1 << CPU_TLB_ENTRY_BITS];
> +};
>  } CPUTLBEntry;
>  
>  QEMU_BUILD_BUG_ON(sizeof(CPUTLBEntry) != (1 << CPU_TLB_ENTRY_BITS));
> 

Re: [Qemu-devel] [PATCH v10 02/21] i.MX: Move serial initialization to init/realize of DeviceClass.

[Peter Crosthwaite]

On Mon, Jul 6, 2015 at 1:01 AM,   wrote:
>
>
> - Le 6 Juil 15, à 8:40, Peter Crosthwaite 
> a écrit :
>
> On Sun, Jul 5, 2015 at 5:04 PM, Jean-Christophe Dubois
>  wrote:
>> Move constructor to DeviceClass methods
>>  * imx_serial_init
>>  * imx_serial_realize
>>
>> imx32_serial_properties is renamed to imx_serial_properties.
>>
>> The Qdev construction helper is moved to an include file as an
>> inline function. This function is going to be removed soon.
>>
>> Signed-off-by: Jean-Christophe Dubois 
>> ---
>>
>> Changes since v1:
>> * not present on v1
>>
>> Changes since v2:
>> * not present on v2
>>
>> Changes since v3:
>> * not present on v3
>>
>> Changes since v4:
>> * not present on v4
>>
>> Changes since v5:
>> * not present on v5
>>
>> Changes since v6:
>> * not present on v6
>>
>> Changes since v7:
>> * not present on v7
>>
>> Changes since v8:
>> * Remove Qdev construction helper
>>
>> Changes since v9:
>> * Qdev construction helper is reintegrated and moved to a header file
>>   as an inline function.
>>
>>  hw/char/imx_serial.c | 70
>> +++-
>>  include/hw/arm/imx.h | 30 +-
>>  2 files changed, 49 insertions(+), 51 deletions(-)
>>
>> diff --git a/hw/char/imx_serial.c b/hw/char/imx_serial.c
>> index 1dcb325..ef5af05 100644
>> --- a/hw/char/imx_serial.c
>> +++ b/hw/char/imx_serial.c
>> @@ -21,7 +21,6 @@
>>  #include "hw/char/imx_serial.h"
>>  #include "sysemu/sysemu.h"
>>  #include "sysemu/char.h"
>> -#include "hw/arm/imx.h"
>>
>>  //#define DEBUG_SERIAL 1
>>  #ifdef DEBUG_SERIAL
>> @@ -38,13 +37,13 @@ do { printf("imx_serial: " fmt , ##args); } while (0)
>>  //#define DEBUG_IMPLEMENTATION 1
>>  #ifdef DEBUG_IMPLEMENTATION
>>  #  define IPRINTF(fmt, args...) \
>> -do  { fprintf(stderr, "imx_serial: " fmt, ##args); } while (0)
>> +do  { fprintf(stderr, "%s: " fmt, TYPE_IMX_SERIAL, ##args); } while
>> (0)
>>  #else
>>  #  define IPRINTF(fmt, args...) do {} while (0)
>>  #endif
>>
>>  static const VMStateDescription vmstate_imx_serial = {
>> -.name = "imx-serial",
>> +.name = TYPE_IMX_SERIAL,
>>  .version_id = 1,
>>  .minimum_version_id = 1,
>>  .fields = (VMStateField[]) {
>> @@ -299,22 +298,18 @@ static void imx_event(void *opaque, int event)
>>  }
>>  }
>>
>> -
>>  static const struct MemoryRegionOps imx_serial_ops = {
>>  .read = imx_serial_read,
>>  .write = imx_serial_write,
>>  .endianness = DEVICE_NATIVE_ENDIAN,
>>  };
>>
>> -static int imx_serial_init(SysBusDevice *dev)
>> +static void imx_serial_realize(DeviceState *dev, Error **errp)
>>  {
>>  IMXSerialState *s = IMX_SERIAL(dev);
>>
>> -
>> -memory_region_init_io(&s->iomem, OBJECT(s), &imx_serial_ops, s,
>> -  "imx-serial", 0x1000);
>> -sysbus_init_mmio(dev, &s->iomem);
>> -sysbus_init_irq(dev, &s->irq);
>> +/* FIXME use a qdev chardev prop instead of
>> qemu_char_get_next_serial() */
>> +s->chr = qemu_char_get_next_serial();
>>
>>  if (s->chr) {
>>  qemu_chr_add_handlers(s->chr, imx_can_receive, imx_receive,
>> @@ -323,45 +318,20 @@ static int imx_serial_init(SysBusDevice *dev)
>>  DPRINTF("No char dev for uart at 0x%lx\n",
>>  (unsigned long)s->iomem.ram_addr);
>>  }
>> -
>> -return 0;
>>  }
>>
>> -void imx_serial_create(int uart, const hwaddr addr, qemu_irq irq)
>> +static void imx_serial_init(Object *obj)
>>  {
>> -DeviceState *dev;
>> -SysBusDevice *bus;
>> -CharDriverState *chr;
>> -const char chr_name[] = "serial";
>> -char label[ARRAY_SIZE(chr_name) + 1];
>> -
>> -dev = qdev_create(NULL, TYPE_IMX_SERIAL);
>> -
>> -if (uart >= MAX_SERIAL_PORTS) {
>> -hw_error("Cannot assign uart %d: QEMU supports only %d ports\n",
>> - uart, MAX_SERIAL_PORTS);
>> -}
>> -chr = serial_hds[uart];
>> -if (!chr) {
>> -snprintf(label, ARRAY_SIZE(label), "%s%d", chr_name, uart);
>> -chr = qemu_chr_new(label, "null", NULL);
>> -if (!(chr)) {
>> -hw_error("Can't assign serial port to imx-uart%d.\n", uart);
>> -}
>> -}
>> -
>> -qdev_prop_set_chr(dev, "chardev", chr);
>
> I'm confused as to why you needed to replace the qdev_prop_set_chr
> logic with qemu_get_char_get_next_serial(). Can you give some details
> on why we want to do this?
>
>
> I am just following the general ARM template of other serial drivers. I am
> not proficient enough in Qemu wizardry to proprose my own thing in this
> regard.
> So far no other ARM plateform (except strongarm?) seems to be using
> "chardev" and all seems to be using qemu_get_char_get_next_serial() even if
> it is supposed to be deprecated some day (even the cadence serial driver).
>

I wonder if this one is right, and everyone else is wrong.
Propertyified chr is better than the devs using
qemu_chr_get_next_serial.

>
>> -bus = SYS_BUS_DEVICE(dev);
>> -qdev_i

Re: [Qemu-devel] [PATCH pic32 v3 02/16] pic32: use LCG algorithm for generated random index of TLBWR instruction

[Aurelien Jarno]

On 2015-07-05 23:14, Serge Vakulenko wrote:
> The LFSR algorithm, used for generating random TLB indexes for TLBWR 
> instruction,
> was inclined to produce a degenerate sequence in some cases.
> For example, for 16-entry TLB size and Wired=1, it gives: 15, 6, 7, 2,
> 7, 2, 7, 2, 7, 2, 7, 2, 7, 2, 7, 2, 7, 2, 7, 2, 7, 2, 7, 2, 7, 2, 7, 2...
> When replaced with LCG algorithm from ISO/IEC 9899 standard, the sequence
> looks much better, with about the same computational effort needed.
> 
> Signed-off-by: Serge Vakulenko 
> ---
>  hw/mips/cputimer.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/mips/cputimer.c b/hw/mips/cputimer.c
> index 75917cf..58707ed 100644
> --- a/hw/mips/cputimer.c
> +++ b/hw/mips/cputimer.c
> @@ -28,13 +28,16 @@
>  /* XXX: do not use a global */
>  uint32_t cpu_mips_get_random (CPUMIPSState *env)
>  {
> -static uint32_t lfsr = 1;
> +static uint32_t seed = 1;
>  static uint32_t prev_idx = 0;
>  uint32_t idx;
>  /* Don't return same value twice, so get another value */
>  do {
> -lfsr = (lfsr >> 1) ^ (-(lfsr & 1u) & 0xd001u);
> -idx = lfsr % (env->tlb->nb_tlb - env->CP0_Wired) + env->CP0_Wired;
> +/* Use a simple algorithm of Linear Congruential Generator
> + * from ISO/IEC 9899 standard. */
> +seed = 1103515245 * seed + 12345;
> +idx = (seed >> 16) % (env->tlb->nb_tlb - env->CP0_Wired) +
> +env->CP0_Wired;
>  } while (idx == prev_idx);
>  prev_idx = idx;
>  return idx;

This is indeed better, it seems the generated values are also better in
the standard Linux case (16 entries, wired = 0).

Reviewed-by: Aurelien Jarno 

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] [PATCH] virtio-pci: implement cfg capability

[Paolo Bonzini]

On 06/07/2015 10:33, Michael S. Tsirkin wrote:
> Also, by luck, some values work the same whatever the endian-ness.
> E.g. dma_memory_set fills the buffer with a given pattern, so
> nothing changes if you byte-swap it.
> 
> Here's an example that's wrong: dp8393x. Typically it's accessing
> memory for DMA, so there's no byteswap. Works fine.
> 
> But should device attempt to access another device memory,
> it would break because MIPS target is BE.
> 
> Cc Hervé for confirmation.
> 
> I conclude that virtio is not so special in needing a variant
> of address_space_rw that assumes host endian format for the data.

Why host endian and not device (in this case little) endian?

Paolo

Re: [Qemu-devel] [PATCH] exec: skip MMIO regions correctly in cpu_physical_memory_write_rom_internal

[Alexander Graf]

On 07/04/15 01:00, Laurent Vivier wrote:


On 04/07/2015 00:42, Paolo Bonzini wrote:

Loading the BIOS in the mac99 machine is interesting, because there is a
PROM in the middle of the BIOS region (from 16K to 32K).  Before memory
region accesses were clamped, when QEMU was asked to load a BIOS from
0xfff0 to 0x it would put even those 16K from the BIOS file
into the region.  This is weird because those 16K were not actually
visible between 0xfff04000 and 0xfff07fff.  However, it worked.

After clamping was added, this also worked.  In this case, the
cpu_physical_memory_write_rom_internal function split the write in
three parts: the first 16K were copied, the PROM area (second 16K) were
ignored, then the rest was copied.

Problems then started with commit 965eb2f (exec: do not clamp accesses
to MMIO regions, 2015-06-17).  Clamping accesses is not done for MMIO
regions because they can overlap wildly, and MMIO registers can be
expected to perform full-width accesses based only on their address
(with no respect for adjacent registers that could decode to completely
different MemoryRegions).  However, this lack of clamping also applied
to the PROM area!  cpu_physical_memory_write_rom_internal thus failed
to copy the third range above, i.e. only copied the first 16K of the BIOS.

In effect, address_space_translate is expecting _something else_ to do
the clamping for MMIO regions if the incoming length is large.  This
"something else" is memory_access_size in the case of address_space_rw,
so use the same logic in cpu_physical_memory_write_rom_internal.

The fix is just one line, but also add a comment explaining why there
is no clamping for MMIO regions, and what it means for the callers.

Reported-by: Alexander Graf 
Fixes: 965eb2f
Signed-off-by: Paolo Bonzini 

Reviewed-by: Laurent Vivier 
Tested-by: Laurent Vivier 



Thanks, I've applied this to ppc-next to fix up the mac99 target. But 
I'd be happy to see it in the tree before my next pull request ;)



Alex

Re: [Qemu-devel] [PATCH] target-ppc: fix hugepage support when using memory-backend-file

[Alexander Graf]

On 07/03/15 09:18, David Gibson wrote:

On Thu, Jul 02, 2015 at 03:46:14PM -0500, Michael Roth wrote:

Current PPC code relies on -mem-path being used in order for
hugepage support to be detected. With the introduction of
MemoryBackendFile we can now handle this via:
   -object memory-file-backend,mem-path=...,id=hugemem0 \
   -numa node,id=mem0,memdev=hugemem0

Management tools like libvirt treat the 2 approaches as
interchangeable in some cases, which can lead to user-visible
regressions even for previously supported guest configurations.

Fix these by also iterating through any configured memory
backends that may be backed by hugepages.

Since the old code assumed hugepages always backed the entirety
of guest memory, play it safe an pick the minimum across the
max pages sizes for all backends, even ones that aren't backed
by hugepages.

Cc: qemu-sta...@nongnu.org
Signed-off-by: Michael Roth 

Reviewed-by: David Gibson 



Thanks, applied to ppc-next.


Alex

Re: [Qemu-devel] [PATCH COLO-Frame v6 03/31] COLO: migrate colo related info to slave

[zhanghailiang]

On 2015/7/6 16:29, Dr. David Alan Gilbert wrote:

* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:

On 2015/7/4 2:03, Dr. David Alan Gilbert wrote:

* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:

We can know if VM in destination should go into COLO mode by refer to
the info that has been migrated from PVM.

Signed-off-by: zhanghailiang 
Signed-off-by: Yang Hongyang 
Signed-off-by: Lai Jiangshan 
Signed-off-by: Gonglei 
---
  include/migration/migration-colo.h |  2 ++
  migration/Makefile.objs|  1 +
  migration/colo-comm.c  | 47 ++
  trace-events   |  3 +++
  vl.c   |  5 +++-
  5 files changed, 57 insertions(+), 1 deletion(-)
  create mode 100644 migration/colo-comm.c

diff --git a/include/migration/migration-colo.h 
b/include/migration/migration-colo.h
index c6d0c51..e20a0c1 100644
--- a/include/migration/migration-colo.h
+++ b/include/migration/migration-colo.h
@@ -14,7 +14,9 @@
  #define QEMU_MIGRATION_COLO_H

  #include "qemu-common.h"
+#include "migration/migration.h"

  bool colo_supported(void);
+void colo_info_mig_init(void);

  #endif
diff --git a/migration/Makefile.objs b/migration/Makefile.objs
index 5a25d39..cb7bd30 100644
--- a/migration/Makefile.objs
+++ b/migration/Makefile.objs
@@ -1,5 +1,6 @@
  common-obj-y += migration.o tcp.o
  common-obj-$(CONFIG_COLO) += colo.o
+common-obj-y += colo-comm.o
  common-obj-y += vmstate.o
  common-obj-y += qemu-file.o qemu-file-buf.o qemu-file-unix.o qemu-file-stdio.o
  common-obj-y += xbzrle.o
diff --git a/migration/colo-comm.c b/migration/colo-comm.c
new file mode 100644
index 000..0b76eb4
--- /dev/null
+++ b/migration/colo-comm.c
@@ -0,0 +1,47 @@
+/*
+ * COarse-grain LOck-stepping Virtual Machines for Non-stop Service (COLO)
+ * (a.k.a. Fault Tolerance or Continuous Replication)
+ *
+ * Copyright (c) 2015 HUAWEI TECHNOLOGIES CO., LTD.
+ * Copyright (c) 2015 FUJITSU LIMITED
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * 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 
+#include "trace.h"
+
+static bool colo_requested;
+
+/* save */
+static void colo_info_save(QEMUFile *f, void *opaque)
+{
+qemu_put_byte(f, migrate_enable_colo());
+}
+
+/* restore */
+static int colo_info_load(QEMUFile *f, void *opaque, int version_id)
+{
+int value = qemu_get_byte(f);
+
+if (value && !colo_requested) {
+trace_colo_info_load("COLO request!");
+}
+colo_requested = value;
+
+return 0;
+}
+
+static SaveVMHandlers savevm_colo_info_handlers = {
+.save_state = colo_info_save,
+.load_state = colo_info_load,
+};
+
+void colo_info_mig_init(void)
+{
+register_savevm_live(NULL, "colo", -1, 1,
+ &savevm_colo_info_handlers, NULL);
+}
diff --git a/trace-events b/trace-events
index 52b7efa..3f63019 100644
--- a/trace-events
+++ b/trace-events
@@ -1466,6 +1466,9 @@ rdma_start_incoming_migration_after_rdma_listen(void) ""
  rdma_start_outgoing_migration_after_rdma_connect(void) ""
  rdma_start_outgoing_migration_after_rdma_source_init(void) ""

+# migration/colo-comm.c
+colo_info_load(const char *msg) "%s"
+
  # kvm-all.c
  kvm_ioctl(int type, void *arg) "type 0x%x, arg %p"
  kvm_vm_ioctl(int type, void *arg) "type 0x%x, arg %p"
diff --git a/vl.c b/vl.c
index 2201e27..988567a 100644
--- a/vl.c
+++ b/vl.c
@@ -90,6 +90,7 @@ int main(int argc, char **argv)
  #include "sysemu/dma.h"
  #include "audio/audio.h"
  #include "migration/migration.h"
+#include "migration/migration-colo.h"
  #include "sysemu/kvm.h"
  #include "qapi/qmp/qjson.h"
  #include "qemu/option.h"
@@ -4261,7 +4262,9 @@ int main(int argc, char **argv, char **envp)

  blk_mig_init();
  ram_mig_init();
-
+#ifdef CONFIG_COLO
+colo_info_mig_init();
+#endif


Does't this still break migration compatibility?  I wouldn't


Yes, it will break migration if the QEMU in destination and source not 
enable/disable (configure) this
feature together, also not compatible with old version on migration.


want to have to have two QEMU builds on a system, one built with COLO
and one built without COLO.   You need to arrange for the
section to only be sent if COLO is enabled (i.e. migrate_set_capability colo 
on).
One way to do that would be to use the new QEMU optional sections
that Juan added recently.



Hmm, his method can address the above problems, (though, we will still fail 
when we configure
with --enable-colo in source side and --disable-colo in destination, but that 
is what
we want, we should not go into colo mode if secondary host is not enable this 
feature).
I will look into his patch, and fix that in next version, thanks,


It must not break compatibility with migration however the 
--enable-colo/disable-colo on the
source destination; it should only break if the migrate_set_capability colo on  
 is set on
one and not the other

Re: [Qemu-devel] [PATCH] exec: skip MMIO regions correctly in cpu_physical_memory_write_rom_internal

[Paolo Bonzini]

On 06/07/2015 10:51, Alexander Graf wrote:
> On 07/04/15 01:00, Laurent Vivier wrote:
>>
>> On 04/07/2015 00:42, Paolo Bonzini wrote:
>>> Loading the BIOS in the mac99 machine is interesting, because there is a
>>> PROM in the middle of the BIOS region (from 16K to 32K).  Before memory
>>> region accesses were clamped, when QEMU was asked to load a BIOS from
>>> 0xfff0 to 0x it would put even those 16K from the BIOS file
>>> into the region.  This is weird because those 16K were not actually
>>> visible between 0xfff04000 and 0xfff07fff.  However, it worked.
>>>
>>> After clamping was added, this also worked.  In this case, the
>>> cpu_physical_memory_write_rom_internal function split the write in
>>> three parts: the first 16K were copied, the PROM area (second 16K) were
>>> ignored, then the rest was copied.
>>>
>>> Problems then started with commit 965eb2f (exec: do not clamp accesses
>>> to MMIO regions, 2015-06-17).  Clamping accesses is not done for MMIO
>>> regions because they can overlap wildly, and MMIO registers can be
>>> expected to perform full-width accesses based only on their address
>>> (with no respect for adjacent registers that could decode to completely
>>> different MemoryRegions).  However, this lack of clamping also applied
>>> to the PROM area!  cpu_physical_memory_write_rom_internal thus failed
>>> to copy the third range above, i.e. only copied the first 16K of the
>>> BIOS.
>>>
>>> In effect, address_space_translate is expecting _something else_ to do
>>> the clamping for MMIO regions if the incoming length is large.  This
>>> "something else" is memory_access_size in the case of address_space_rw,
>>> so use the same logic in cpu_physical_memory_write_rom_internal.
>>>
>>> The fix is just one line, but also add a comment explaining why there
>>> is no clamping for MMIO regions, and what it means for the callers.
>>>
>>> Reported-by: Alexander Graf 
>>> Fixes: 965eb2f
>>> Signed-off-by: Paolo Bonzini 
>> Reviewed-by: Laurent Vivier 
>> Tested-by: Laurent Vivier 
>>
> 
> Thanks, I've applied this to ppc-next to fix up the mac99 target. But
> I'd be happy to see it in the tree before my next pull request ;)

Sending pull request later today.

Paolo

Re: [Qemu-devel] [BUG/RFC] Two cpus are not brought up normally in SLES11 sp3 VM after reboot

[Paolo Bonzini]

On 06/07/2015 09:54, zhanghailiang wrote:
> 
> From host, we found that QEMU vcpu1 thread and vcpu7 thread were not
> consuming any cpu (Should be in idle state),
> All of VCPUs' stacks in host is like bellow:
> 
> [] kvm_vcpu_block+0x65/0xa0 [kvm]
> [] __vcpu_run+0xd1/0x260 [kvm]
> [] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 [kvm]
> [] kvm_vcpu_ioctl+0x38e/0x580 [kvm]
> [] do_vfs_ioctl+0x8b/0x3b0
> [] sys_ioctl+0xa1/0xb0
> [] system_call_fastpath+0x16/0x1b
> [<2ab9fe1f99a7>] 0x2ab9fe1f99a7
> [] 0x
> 
> We looked into the kernel codes that could leading to the above 'Stuck'
> warning,
> and found that the only possible is the emulation of 'cpuid' instruct in
> kvm/qemu has something wrong.
> But since we can’t reproduce this problem, we are not quite sure.
> Is there any possible that the cupid emulation in kvm/qemu has some bug ?

Can you explain the relationship to the cpuid emulation?  What do the
traces say about vcpus 1 and 7?

Paolo

Re: [Qemu-devel] [PATCH] cpu_defs: Simplify CPUTLB padding logic

[Peter Crosthwaite]

On Mon, Jul 6, 2015 at 1:43 AM, Paolo Bonzini  wrote:
>
>
> On 05/07/2015 23:08, Peter Crosthwaite wrote:
>> There was a complicated subtractive arithmetic for determining the
>> padding on the CPUTLBEntry structure. Simplify this with a union.
>>
>> Signed-off-by: Peter Crosthwaite 
>> ---
>>  include/exec/cpu-defs.h | 23 ---
>>  1 file changed, 12 insertions(+), 11 deletions(-)
>>
>> diff --git a/include/exec/cpu-defs.h b/include/exec/cpu-defs.h
>> index 98b9cff..5093be2 100644
>> --- a/include/exec/cpu-defs.h
>> +++ b/include/exec/cpu-defs.h
>> @@ -105,17 +105,18 @@ typedef struct CPUTLBEntry {
>> bit 3  : indicates that the entry is invalid
>> bit 2..0   : zero
>>  */
>> -target_ulong addr_read;
>> -target_ulong addr_write;
>> -target_ulong addr_code;
>> -/* Addend to virtual address to get host address.  IO accesses
>> -   use the corresponding iotlb value.  */
>> -uintptr_t addend;
>> -/* padding to get a power of two size */
>> -uint8_t dummy[(1 << CPU_TLB_ENTRY_BITS) -
>> -  (sizeof(target_ulong) * 3 +
>> -   ((-sizeof(target_ulong) * 3) & (sizeof(uintptr_t) - 1)) +
>> -   sizeof(uintptr_t))];
>> +union {
>
> The struct CPUTLBEntry can be changed to union CPUTLBEntry directly,
> with no need for the anonymous struct.
>

True. Code gets even simpler! :)

>> +struct {
>> +target_ulong addr_read;
>> +target_ulong addr_write;
>> +target_ulong addr_code;
>> +/* Addend to virtual address to get host address.  IO accesses
>> +   use the corresponding iotlb value.  */
>> +uintptr_t addend;
>> +};
>
> Which compiler version started implementing anonymous structs?
>

ISO C11 standardises it apparently. But various parts of the tree use
them now. target-arm/cpu.h, target-i386/kvm.c,
linux-user/syscall_defs.h and linux-headers/linux/kvm.h have liberal
use to name a few. I have seen it used in devs from time to time for
unionifying individual registers with an array form for SW access.

This led me to consider it open season on anonymous structs and unions.

> Or can we just add
>
>  __attribute__((__aligned__(1 << CPU_TLB_ENTRY_BITS)))
>

Is that more or less standard than anonymous structs?

Regards,
Peter

> to the struct?  I'm not sure if it affects the sizeof too, so that
> requires some care.  Alternatively, an
>
> uint8_t padding[0]
> __attribute__((__aligned__(1 << CPU_TLB_ENTRY_BITS)));
>
> could maybe work?  Neither is exactly the same, as they also bump the
> alignment of the overall struct, but they do not require anonymous structs.
>
> Paolo
>
>> +/* padding to get a power of two size */
>> +uint8_t dummy[1 << CPU_TLB_ENTRY_BITS];
>> +};
>>  } CPUTLBEntry;
>>
>>  QEMU_BUILD_BUG_ON(sizeof(CPUTLBEntry) != (1 << CPU_TLB_ENTRY_BITS));
>>
>

Re: [Qemu-devel] [PATCH] cpu_defs: Simplify CPUTLB padding logic

[Paolo Bonzini]

On 06/07/2015 10:58, Peter Crosthwaite wrote:
>> > Which compiler version started implementing anonymous structs?
>> >
> ISO C11 standardises it apparently. But various parts of the tree use
> them now. target-arm/cpu.h, target-i386/kvm.c,
> linux-user/syscall_defs.h and linux-headers/linux/kvm.h have liberal
> use to name a few. I have seen it used in devs from time to time for
> unionifying individual registers with an array form for SW access.
> 
> This led me to consider it open season on anonymous structs and unions.

Ok, I wasn't sure about anonymous structs.  We definitely use anonymous
unions a lot.

>> > Or can we just add
>> >
>> >  __attribute__((__aligned__(1 << CPU_TLB_ENTRY_BITS)))
>> >
> Is that more or less standard than anonymous structs?

Not standard (though there is something in C11 too) but decades old as a
GCC extension.

Paolo

Re: [Qemu-devel] [PATCH pic32 v3 05/16] pic32: add file pic32_peripherals.h

[Aurelien Jarno]

On 2015-07-05 23:14, Serge Vakulenko wrote:
> Data definitions and function declarations for simulation
> of pic32 microcontrollers.
> 
> Signed-off-by: Serge Vakulenko 
> ---
>  hw/mips/pic32_peripherals.h | 210 
> 
>  1 file changed, 210 insertions(+)
>  create mode 100644 hw/mips/pic32_peripherals.h
> 
> diff --git a/hw/mips/pic32_peripherals.h b/hw/mips/pic32_peripherals.h
> new file mode 100644
> index 000..4435991
> --- /dev/null
> +++ b/hw/mips/pic32_peripherals.h
> @@ -0,0 +1,210 @@
> +/*
> + * Define memory map for PIC32 microcontroller.
> + *
> + * Copyright (C) 2015 Serge Vakulenko
> + *
> + * Permission to use, copy, modify, and distribute this software
> + * and its documentation for any purpose and without fee is hereby
> + * granted, provided that the above copyright notice appear in all
> + * copies and that both that the copyright notice and this
> + * permission notice and warranty disclaimer appear in supporting
> + * documentation, and that the name of the author not be used in
> + * advertising or publicity pertaining to distribution of the
> + * software without specific, written prior permission.
> + *
> + * The author disclaim all warranties with regard to this
> + * software, including all implied warranties of merchantability
> + * and fitness.  In no event shall the author be liable for any
> + * special, indirect or consequential damages or any damages
> + * whatsoever resulting from loss of use, data or profits, whether
> + * in an action of contract, negligence or other tortious action,
> + * arising out of or in connection with the use or performance of
> + * this software.
> + */
> +#include "hw/sysbus.h"  /* SysBusDevice */
> +#include "net/net.h"
> +
> +#define IO_MEM_SIZE (1024*1024) /* 1 Mbyte */
> +
> +typedef struct _uart_t uart_t;
> +typedef struct _spi_t spi_t;
> +typedef struct _sdcard_t sdcard_t;
> +typedef struct _pic32_t pic32_t;
> +typedef struct _eth_t eth_t;
> +
> +/*
> + * UART private data.
> + */
> +struct _uart_t {
> +pic32_t *mcu;   /* back pointer to pic32 object */
> +unsignedirq;/* interrupt number */
> +int oactive;/* output active */
> +unsignedsta;/* UxSTA address */
> +unsignedmode;   /* UxMODE address */
> +unsignedrxbyte; /* received byte */
> +CharDriverState *chr;   /* pointer to serial_hds[i] */
> +QEMUTimer   *transmit_timer;/* needed to delay TX interrupt */
> +};
> +
> +/*
> + * SPI private data.
> + */
> +struct _spi_t {
> +unsignedbuf[4]; /* transmit and receive buffer */
> +unsignedrfifo;  /* read fifo counter */
> +unsignedwfifo;  /* write fifo counter */
> +unsignedirq;/* interrupt numbers */
> +unsignedcon;/* SPIxCON address */
> +unsignedstat;   /* SPIxSTAT address */
> +};
> +
> +/*
> + * SD card private data.
> + */
> +struct _sdcard_t {
> +const char  *name;  /* Device name */
> +unsignedgpio_port;  /* GPIO port number of CS0 signal */
> +unsignedgpio_cs;/* GPIO pin mask of CS0 signal */
> +unsignedkbytes; /* Disk size */
> +int unit;   /* Index (sd0 or sd1) */
> +int fd; /* Image file */
> +int select; /* Selected */
> +int read_multiple;  /* Read-multiple mode */
> +unsignedblen;   /* Block length */
> +unsignedwbecnt; /* Write block erase count */
> +unsignedoffset; /* Read/write offset */
> +unsignedcount;  /* Byte count */
> +unsignedlimit;  /* Reply length */
> +unsignedchar buf[1024 + 16];
> +};
> +
> +/*
> + * PIC32 data structure.
> + */
> +struct _pic32_t {
> +SysBusDevice parent_obj;
> +MIPSCPU *cpu;   /* back pointer to cpu object */
> +uint32_t*iomem; /* backing storage for I/O area */
> +
> +int board_type; /* board variant */
> +int stop_on_reset;  /* halt simulation on soft reset */
> +unsignedsyskey_unlock;  /* syskey state */
> +
> +#define NUM_UART 6  /* number of UART ports */
> +uart_t  uart[NUM_UART]; /* UART data */
> +
> +#define NUM_SPI 6   /* max number of SPI ports */
> +spi_t   spi[NUM_SPI];   /* SPI data */
> +
> +unsignedsdcard_spi_port;/* SPI port number of SD card */
> +sdcard_tsdcard[2];  /* SD card data */
> +
> +DeviceState *eth_dev;   /* Ethernet

Re: [Qemu-devel] [PATCH] virtio-pci: implement cfg capability

[Michael S. Tsirkin]

On Mon, Jul 06, 2015 at 10:46:31AM +0200, Paolo Bonzini wrote:
> 
> 
> On 06/07/2015 10:33, Michael S. Tsirkin wrote:
> > Also, by luck, some values work the same whatever the endian-ness.
> > E.g. dma_memory_set fills the buffer with a given pattern, so
> > nothing changes if you byte-swap it.
> > 
> > Here's an example that's wrong: dp8393x. Typically it's accessing
> > memory for DMA, so there's no byteswap. Works fine.
> > 
> > But should device attempt to access another device memory,
> > it would break because MIPS target is BE.
> > 
> > Cc Hervé for confirmation.
> > 
> > I conclude that virtio is not so special in needing a variant
> > of address_space_rw that assumes host endian format for the data.
> 
> Why host endian and not device (in this case little) endian?
> 
> Paolo

It's the endian of the originator of the transaction.
And emulated device code is all compiled in host endian-ness.

-- 
MST

Re: [Qemu-devel] [PATCH] virtio-pci: implement cfg capability

[Peter Maydell]

On 6 July 2015 at 10:06, Michael S. Tsirkin  wrote:
> On Mon, Jul 06, 2015 at 10:46:31AM +0200, Paolo Bonzini wrote:
>> Why host endian and not device (in this case little) endian?

> It's the endian of the originator of the transaction.
> And emulated device code is all compiled in host endian-ness.

But address_space_rw() is just the "memcpy bytes to the
target's memory" operation -- if you have a pile of bytes
then there are no endianness concerns. If you don't have
a pile of bytes then you need to know the structure of
the data you're DMAing around, and you should probably
have a loop doing things with the specify-the-width functions.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v4] arm_mptimer: Respect IT bit state

[Peter Maydell]

On 6 July 2015 at 02:27, Dmitry Osipenko  wrote:
> The timer should fire the interrupt only if the IT (interrupt enable) bit
> state of the control register is enabled.
>
> Signed-off-by: Dmitry Osipenko 
> Reviewed-by: Peter Crosthwaite 

If you need to update a patch, please resend the whole series,
not just one patch from it. (This is one of the things we talk
about on http://wiki.qemu.org/Contribute/SubmitAPatch -- the
v2/3/4 etc version number applies to a series, not a single
patch). Otherwise it gets very confusing because it's hard to
see if you're really looking at the most recent version of the
patchset, and as Peter C says, some patch handling tools don't
cope with the failure to thread a series properly.

I'll pick these up manually since there are only two patches
here, but for future submissions it would be really helpful
if you could fix this. We generally recommend using git
format-patch/send-email to put together the series and its
cover letter with the right references headers.

thanks
-- PMM

Re: [Qemu-devel] [PATCH pic32 v2 3/5] Added support for external interrupt controller (EIC) mode.

[Aurelien Jarno]

On 2015-07-05 20:05, Serge Vakulenko wrote:
> >>  } else {
> >>  /* A MIPS configured with compatibility or VInt (Vectored 
> >> Interrupts)
> >> diff --git a/target-mips/helper.c b/target-mips/helper.c
> >> index 8e3204a..7e25998 100644
> >> --- a/target-mips/helper.c
> >> +++ b/target-mips/helper.c
> >> @@ -574,23 +574,31 @@ void mips_cpu_do_interrupt(CPUState *cs)
> >>  unsigned int vector;
> >>  unsigned int pending = (env->CP0_Cause & CP0Ca_IP_mask) >> 8;
> >>
> >> -pending &= env->CP0_Status >> 8;
> >>  /* Compute the Vector Spacing.  */
> >>  spacing = (env->CP0_IntCtl >> CP0IntCtl_VS) & ((1 << 6) - 1);
> >>  spacing <<= 5;
> >>
> >> -if (env->CP0_Config3 & (1 << CP0C3_VInt)) {
> >> +if (env->CP0_Config3 & (1 << CP0C3_VEIC)) {
> >> +/* For VEIC mode, the external interrupt controller feeds 
> >> the
> >> + * vector through the CP0Cause IP lines. */
> >> +vector = pending;
> >> +
> >> +/* Architecturally, this is chip-specific behavior.
> >> + * TODO: some processors, like PIC32MZ,
> >> + * provide vector in a different way.
> >> + * Some processors, like PIC32, have a separate
> >> + * bit INTCON.MVEC to explicitly enable vectored mode,
> >> + * disabled by default. */
> >> +spacing = 0;
> >> +} else {
> >>  /* For VInt mode, the MIPS computes the vector 
> >> internally.  */
> >> +pending &= env->CP0_Status >> 8;
> >>  for (vector = 7; vector > 0; vector--) {
> >>  if (pending & (1 << vector)) {
> >>  /* Found it.  */
> >>  break;
> >>  }
> >>  }
> >> -} else {
> >> -/* For VEIC mode, the external interrupt controller feeds 
> >> the
> >> -   vector through the CP0Cause IP lines.  */
> >> -vector = pending;
> >>  }
> >
> > The changes looks correct, but I do wonder why you swap the test on
> > CP0_Config3. It would be less changes to just move the pending masking
> > with CP0_Status inside the VInt mode.
> 
> According to MIPS PRA spec (MD00090), VInt bit becomes do-not-care
> when Config3.VEIC is enabled. So it makes little sense to rely on it's
> value here. And it makes it easier to understand this way. EIC and
> VInt modes are quite different: better not to mix them up.

Ok I understand now.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] [PATCH v2] thread-win32: fix GetThreadContext() permanently fails

[Fabien Chouteau]

On 07/02/2015 09:09 PM, Zavadovsky Yan wrote:
> I tested this patch on my 4-cores cpu.
> Debug and release builds both.
> Win32 and Win64 binaries both. (I used old Fedora 17-18 with SJLJ mingw-w64 
> to crossbuild for Win64.)
> With default Qemu BIOS and with myself-builded OVMF(also debug and release) 
> from EDK2.
> 
> Also I did some synthetic tests with sample from this article:
> http://blogs.msdn.com/b/oldnewthing/archive/2015/02/05/10591215.aspx
> modified as I described here:
> http://lists.nongnu.org/archive/html/qemu-devel/2015-06/msg06894.html
> 

That's good for me.

Thanks Yan,

Re: [Qemu-devel] [PATCH pic32 v2 3/5] Added support for external interrupt controller (EIC) mode.

[Aurelien Jarno]

On 2015-07-05 20:31, Serge Vakulenko wrote:
> On Sun, Jul 5, 2015 at 8:05 PM, Serge Vakulenko
>  wrote:
> > On Wed, Jul 1, 2015 at 4:07 AM, Aurelien Jarno  wrote:
> >> On 2015-06-30 21:12, Serge Vakulenko wrote:
> >>> diff --git a/target-mips/cpu.h b/target-mips/cpu.h
> >>> index c476166..ab830ee 100644
> >>> --- a/target-mips/cpu.h
> >>> +++ b/target-mips/cpu.h
> >>> @@ -664,7 +669,9 @@ static inline int 
> >>> cpu_mips_hw_interrupts_pending(CPUMIPSState *env)
> >>>  if (env->CP0_Config3 & (1 << CP0C3_VEIC)) {
> >>>  /* A MIPS configured with a vectorizing external interrupt 
> >>> controller
> >>> will feed a vector into the Cause pending lines. The core 
> >>> treats
> >>> -   the status lines as a vector level, not as indiviual masks.  
> >>> */
> >>> +   the status lines as a vector level, not as individual masks.  
> >>> */
> >>> +pending >>= CP0Ca_IP + 2;
> >>> +status >>= CP0Ca_IP + 2;
> >>>  r = pending > status;
> >>
> >> I don't think it's needed. As the pending and status field have been
> >> masked above, we don't need to shift them to do the comparison.
> 
> This is not true. The values still need to be shifted to get rid of
> soft interrupt bits, otherwise the comparison becomes incorrect.

It means we need to have a different mask with the internal interrupt
controller and with the external one. I therefore think it's better to
do the masking differently. For that you can add a CP0Ca_RIPL_mask
constant and use it for the VEIC case, and move the current masking in
the non VEIC case.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] [PATCH pic32 v3 03/16] pic32: add support for external interrupt controller mode (EIC)

[Aurelien Jarno]

On 2015-07-05 23:14, Serge Vakulenko wrote:
> EIC is required for pic32 microcontroller.
> 
> Signed-off-by: Serge Vakulenko 
> ---
>  hw/mips/cputimer.c   | 17 +++--
>  hw/mips/mips_int.c   |  8 +++-
>  target-mips/cpu.h|  8 +++-
>  target-mips/helper.c | 18 --
>  4 files changed, 41 insertions(+), 10 deletions(-)
> 
> diff --git a/hw/mips/cputimer.c b/hw/mips/cputimer.c
> index 58707ed..dab532d 100644
> --- a/hw/mips/cputimer.c
> +++ b/hw/mips/cputimer.c
> @@ -63,7 +63,13 @@ static void cpu_mips_timer_expire(CPUMIPSState *env)
>  if (env->insn_flags & ISA_MIPS32R2) {
>  env->CP0_Cause |= 1 << CP0Ca_TI;
>  }
> -qemu_irq_raise(env->irq[(env->CP0_IntCtl >> CP0IntCtl_IPTI) & 0x7]);
> +if (env->CP0_Config3 & (1 << CP0C3_VEIC)) {
> +/* External interrupt controller mode. */
> +qemu_irq_raise(env->eic_timer_irq);
> +} else {
> +/* Legacy or vectored interrupt mode. */
> +qemu_irq_raise(env->irq[(env->CP0_IntCtl >> CP0IntCtl_IPTI) & 0x7]);
> +}
>  }
>  
>  uint32_t cpu_mips_get_count (CPUMIPSState *env)
> @@ -111,7 +117,14 @@ void cpu_mips_store_compare (CPUMIPSState *env, uint32_t 
> value)
>  cpu_mips_timer_update(env);
>  if (env->insn_flags & ISA_MIPS32R2)
>  env->CP0_Cause &= ~(1 << CP0Ca_TI);
> -qemu_irq_lower(env->irq[(env->CP0_IntCtl >> CP0IntCtl_IPTI) & 0x7]);
> +
> +if (env->CP0_Config3 & (1 << CP0C3_VEIC)) {
> +/* External interrupt controller mode. */
> +qemu_irq_lower(env->eic_timer_irq);
> +} else {
> +/* Legacy or vectored interrupt mode. */
> +qemu_irq_lower(env->irq[(env->CP0_IntCtl >> CP0IntCtl_IPTI) & 0x7]);
> +}
>  }
>  
>  void cpu_mips_start_count(CPUMIPSState *env)
> diff --git a/hw/mips/mips_int.c b/hw/mips/mips_int.c
> index d740046..eb92439 100644
> --- a/hw/mips/mips_int.c
> +++ b/hw/mips/mips_int.c
> @@ -74,5 +74,11 @@ void cpu_mips_soft_irq(CPUMIPSState *env, int irq, int 
> level)
>  return;
>  }
>  
> -qemu_set_irq(env->irq[irq], level);
> +if (env->CP0_Config3 & (1 << CP0C3_VEIC)) {
> +/* External interrupt controller mode. */
> +qemu_set_irq(env->eic_soft_irq[irq], level);
> +} else {
> +/* Legacy or vectored interrupt mode. */
> +qemu_set_irq(env->irq[irq], level);
> +}
>  }
> diff --git a/target-mips/cpu.h b/target-mips/cpu.h
> index c476166..9513f02 100644
> --- a/target-mips/cpu.h
> +++ b/target-mips/cpu.h
> @@ -596,6 +596,10 @@ struct CPUMIPSState {
>  void *irq[8];
>  QEMUTimer *timer; /* Internal timer */
>  unsigned count_freq; /* rate of Count register */
> +
> +/* Fields for external interrupt controller. */
> +void *eic_timer_irq;
> +void *eic_soft_irq[2];
>  };
>  
>  #include "cpu-qom.h"
> @@ -664,7 +668,9 @@ static inline int 
> cpu_mips_hw_interrupts_pending(CPUMIPSState *env)
>  if (env->CP0_Config3 & (1 << CP0C3_VEIC)) {
>  /* A MIPS configured with a vectorizing external interrupt controller
> will feed a vector into the Cause pending lines. The core treats
> -   the status lines as a vector level, not as indiviual masks.  */
> +   the status lines as a vector level, not as individual masks. */
> +pending >>= CP0Ca_IP + 2;
> +status >>= CP0Ca_IP + 2;

As said in the other email, it's probably better to add a CP0Ca_RIPL_mask
and used a different masking in the VEIC and non VEIC case. This way we
avoid the hardcoded + 2.

Otherwise this patch looks fine.

>  r = pending > status;
>  } else {
>  /* A MIPS configured with compatibility or VInt (Vectored Interrupts)
> diff --git a/target-mips/helper.c b/target-mips/helper.c
> index 8e3204a..6fe5212 100644
> --- a/target-mips/helper.c
> +++ b/target-mips/helper.c
> @@ -574,23 +574,29 @@ void mips_cpu_do_interrupt(CPUState *cs)
>  unsigned int vector;
>  unsigned int pending = (env->CP0_Cause & CP0Ca_IP_mask) >> 8;
>  
> -pending &= env->CP0_Status >> 8;
>  /* Compute the Vector Spacing.  */
>  spacing = (env->CP0_IntCtl >> CP0IntCtl_VS) & ((1 << 6) - 1);
>  spacing <<= 5;
>  
> -if (env->CP0_Config3 & (1 << CP0C3_VInt)) {
> +if (env->CP0_Config3 & (1 << CP0C3_VEIC)) {
> +/* For VEIC mode, the external interrupt controller feeds the
> + * vector through the CP0Cause IP lines. */
> +vector = pending;
> +
> +/* Architecturally, this is chip-specific behavior.
> + * Some processors, like PIC32, have a separate
> + * bit INTCON.MVEC to explicitly enable vectored mode,
> + * disabled by default. */
> +spacing = 0;
> +} else {
>  /* For VInt mode, the MIPS computes the vector internally.  
> */
> +pending &= env->CP0_Status >> 8;
> 

Re: [Qemu-devel] [PATCH pic32 v3 04/16] pic32: add two MIPS processor variants: M4K and microAptivUP

[Aurelien Jarno]

On 2015-07-05 23:14, Serge Vakulenko wrote:
> Needed for pic32mx (M4K) and pic32mz (microAptivUP) simulation.
> 
> Signed-off-by: Serge Vakulenko 
> ---
>  target-mips/translate_init.c | 46 
> 
>  1 file changed, 46 insertions(+)
> 
> diff --git a/target-mips/translate_init.c b/target-mips/translate_init.c
> index ddfaff8..8786321 100644
> --- a/target-mips/translate_init.c
> +++ b/target-mips/translate_init.c
> @@ -190,6 +190,26 @@ static const mips_def_t mips_defs[] =
>  .mmu_type = MMU_TYPE_FMT,
>  },
>  {
> +/* Configuration for Microchip PIC32MX microcontroller. */
> +.name = "M4K",
> +.CP0_PRid = 0x00018700,
> +.CP0_Config0 = MIPS_CONFIG0 | (2 << CP0C0_K23) | (2 << CP0C0_KU) |
> +   (1 << CP0C0_BM) | (1 << CP0C0_AR) |
> +   (MMU_TYPE_FMT << CP0C0_MT),
> +.CP0_Config1 = (1U << CP0C1_M) | (1 << CP0C1_CA) | (1 << CP0C1_EP),
> +.CP0_Config2 = MIPS_CONFIG2,
> +.CP0_Config3 = (1 << CP0C3_VEIC) | (1 << CP0C3_VInt),
> +.CP0_LLAddr_rw_bitmask = 0,
> +.CP0_LLAddr_shift = 4,
> +.SYNCI_Step = 32,
> +.CCRes = 2,
> +.CP0_Status_rw_bitmask = 0x1258FF17,
> +.SEGBITS = 32,
> +.PABITS = 32,
> +.insn_flags = CPU_MIPS32R2 | ASE_MIPS16,
> +.mmu_type = MMU_TYPE_FMT,
> +},
> +{
>  .name = "4KEc",
>  .CP0_PRid = 0x00019000,
>  .CP0_Config0 = MIPS_CONFIG0 | (0x1 << CP0C0_AR) |
> @@ -389,6 +409,32 @@ static const mips_def_t mips_defs[] =
>  .mmu_type = MMU_TYPE_R4000,
>  },
>  {
> +/* Configuration for Microchip PIC32MZ microcontroller. */
> +.name = "microAptivUP",
> +.CP0_PRid = 0x00019e00,
> +.CP0_Config0 = MIPS_CONFIG0 | (0x1 << CP0C0_AR) |
> +(MMU_TYPE_R4000 << CP0C0_MT),
> +.CP0_Config1 = MIPS_CONFIG1 | (15 << CP0C1_MMU) | (1 << CP0C1_PC),
> +.CP0_Config2 = MIPS_CONFIG2,
> +.CP0_Config3 = (1 << CP0C3_M) | (1 << CP0C3_IPLW) | (1 << CP0C3_MCU) 
> |
> +(2 << CP0C3_ISA) | (1 << CP0C3_ULRI) | (1 << CP0C3_RXI) |
> +(1 << CP0C3_DSP2P) | (1 << CP0C3_DSPP) | (1 << 
> CP0C3_VEIC) |
> +(1 << CP0C3_VInt),
> +.CP0_Config4 = (1 << CP0C4_M),
> +.CP0_Config5 = (1 << CP0C5_NFExists),
> +.CP0_Config6 = 0,
> +.CP0_Config7 = 0,
> +.CP0_LLAddr_rw_bitmask = 0,
> +.CP0_LLAddr_shift = 4,
> +.SYNCI_Step = 32,
> +.CCRes = 2,
> +.CP0_Status_rw_bitmask = 0x1278FF17,
> +.SEGBITS = 32,
> +.PABITS = 32,
> +.insn_flags = CPU_MIPS32R2 | ASE_MICROMIPS | ASE_DSP | ASE_DSPR2,
> +.mmu_type = MMU_TYPE_R4000,
> +},
> +{
>  /* A generic CPU providing MIPS32 Release 5 features.
> FIXME: Eventually this should be replaced by a real CPU model. */
>  .name = "mips32r5-generic",

Reviewed-by: Aurelien Jarno 

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] [PATCH COLO-BLOCK v7 00/17] Block replication for continuous checkpoints

[Dr. David Alan Gilbert]

* Wen Congyang (ghost...@gmail.com) wrote:
> At 2015/7/3 23:30, Dr. David Alan Gilbert Wrote:
> >* Wen Congyang (we...@cn.fujitsu.com) wrote:
> >>Block replication is a very important feature which is used for
> >>continuous checkpoints(for example: COLO).
> >>
> >>Usage:
> >>Please refer to docs/block-replication.txt
> >>
> >>You can get the patch here:
> >>https://github.com/wencongyang/qemu-colo/commits/block-replication-v7
> >>
> >>You can get ths patch with framework here:
> >>https://github.com/wencongyang/qemu-colo/commits/colo_framework_v7.2
> >
> >Hi,
> >   I seem to be having problems with the new listed syntax on the wiki;
> >on the secondary I'm getting the error
> >
> >  Block format 'replication' used by device 'virtio0' doesn't support the 
> > option 'export'
> >
> >./try/bin/qemu-system-x86_64 -enable-kvm -nographic \
> >  -boot c -m 4096 -smp 4 -S \
> >  -name debug-threads=on -trace events=trace-file \
> >  -netdev tap,id=hn0,script=$PWD/ifup-slave,\
> >downscript=no,colo_script=$PWD/qemu/scripts/colo-proxy-script.sh,colo_nicname=em4
> > \
> >  -device e1000,mac=9c:da:4d:1c:b5:89,id=net-pci0,netdev=hn0 \
> >  -device virtio-rng-pci \
> >  -drive 
> > if=none,driver=raw,file=/home/localvms/bugzilla.raw,id=colo1,cache=none,aio=native
> >  \
> >  -drive 
> > if=virtio,driver=replication,mode=secondary,export=colo1,throttling.bps-total-max=7000,\
> >file.file.filename=$TMPDISKS/colo-active-disk.qcow2,\
> >file.driver=qcow2,\
> >file.backing.file.filename=$TMPDISKS/colo-hidden-disk.qcow2,\
> >file.backing.driver=qcow2,\
> >file.backing.backing.backing_reference=colo1,\
> >file.backing.allow-write-backing-file=on \
> >  -incoming tcp:0:
> 
> Sorry, the option export is removed, because we use the qmp command
> nbd-server-add to let a BB be NBD server.

If I remove the export=  the secondary starts, but then when I issue the 
child_add
on the primary I get the error:

Server requires an export name

on the secondary I had done:

(qemu) nbd_server_start :8889
(qemu) nbd_server_add -w colo1

Can you please confirm your exact command line and sequence needed with this 
7.2 set please.

> 
> >This is using 6fd6ce32 from the colo_framework_v7.2  tag.
> >
> >What have I missed?
> >
> >Dave
> >P.S. the name 'file.backing.backing.backing_reference' is not nice!
> 
> Which name is better? My native language is not English, so any such
> suggestion is welcome.

My only problem is the way that 'backing' is repeated 3 times; that seems
odd!

Dave

> 
> Thanks
> Wen Congyang
> 
> >
> >>
> >>TODO:
> >>1. Continuous block replication. It will be started after basic functions
> >>are accepted.
> >>
> >>Changs Log:
> >>V7:
> >>1. Implement adding/removing quorum child. Remove the option non-connect.
> >>2. Simplify the backing refrence option according to Stefan Hajnoczi's 
> >>suggestion
> >>V6:
> >>1. Rebase to the newest qemu.
> >>V5:
> >>1. Address the comments from Gong Lei
> >>2. Speed the failover up. The secondary vm can take over very quickly even
> >>if there are too many I/O requests.
> >>V4:
> >>1. Introduce a new driver replication to avoid touch nbd and qcow2.
> >>V3:
> >>1: use error_setg() instead of error_set()
> >>2. Add a new block job API
> >>3. Active disk, hidden disk and nbd target uses the same AioContext
> >>4. Add a testcase to test new hbitmap API
> >>V2:
> >>1. Redesign the secondary qemu(use image-fleecing)
> >>2. Use Error objects to return error message
> >>3. Address the comments from Max Reitz and Eric Blake
> >>
> >>
> >>Wen Congyang (17):
> >>   Add new block driver interface to add/delete a BDS's child
> >>   quorum: implement block driver interfaces add/delete a BDS's child
> >>   hmp: add monitor command to add/remove a child
> >>   introduce a new API qemu_opts_absorb_qdict_by_index()
> >>   quorum: allow ignoring child errors
> >>   introduce a new API to enable/disable attach device model
> >>   introduce a new API to check if blk is attached
> >>   block: make bdrv_put_ref_bh_schedule() as a public API
> >>   Backup: clear all bitmap when doing block checkpoint
> >>   allow writing to the backing file
> >>   Allow creating backup jobs when opening BDS
> >>   block: Allow references for backing files
> >>   docs: block replication's description
> >>   Add new block driver interfaces to control block replication
> >>   skip nbd_target when starting block replication
> >>   quorum: implement block driver interfaces for block replication
> >>   Implement new driver for block replication
> >>
> >>  block.c| 198 +-
> >>  block/Makefile.objs|   3 +-
> >>  block/backup.c |  13 ++
> >>  block/block-backend.c  |  33 +++
> >>  block/quorum.c | 244 ++-
> >>  block/replication.c| 443 
> >> +
> >>  blockdev.c |  90 ++---
> >>  blockjob.c   

[Qemu-devel] vpc size reporting problem

[Chun Yan Liu]

While testing with a 1GB VHD file created on win7, found that the VHD file
size reported on Windows is different from that is reported by qemu-img
info or within a Linux KVM guest.

Created a dynamic VHD file on win7, on Windows, it is reported 1024MB
(2097152 sectors). But with qemu-img info or within a Linux KVM guest,
it is reported 1023MB (2096640 sectors).

The values in the footer_buf are as follows:
creator_app: "win "
cylinders: 0x820 (2080)
heads: 0x10 (16)
cyl/sec: 0x3f (63)
current_size: 0x4000 (1G)

So, if using current_size, it's correct; but using CHS will get a smaller size.

Should we add a check in this case and use "current_size" instead of
CHS?

BTW, before commit 0444dceee, there is a similar check for 'd2v',
if creator_app is 'd2v', using "size" instead of CHS. But in commit
0444dceee, this check is removed. To me, the new check and 'd2v'
check seem to be two different cases, why removing 'd2v' check?

Thanks,
Chunyan

[Qemu-devel] [PULL 1/7] target-arm: fix write helper for TLBI ALLE1IS

[Peter Maydell]

From: Sergey Fedorov 

TLBI ALLE1IS is an operation that does invalidate TLB entries on all PEs
in the same Inner Sharable domain, not just on the current CPU. So we
must use tlbiall_is_write() here.

Signed-off-by: Sergey Fedorov 
Message-id: 1435676538-31345-1-git-send-email-serge.f...@gmail.com
Reviewed-by: Peter Maydell 
Signed-off-by: Peter Maydell 
---
 target-arm/helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index aa34159..b87afe7 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -2441,7 +2441,7 @@ static const ARMCPRegInfo v8_cp_reginfo[] = {
 { .name = "TLBI_ALLE1IS", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 3, .opc2 = 4,
   .access = PL2_W, .type = ARM_CP_NO_RAW,
-  .writefn = tlbiall_write },
+  .writefn = tlbiall_is_write },
 { .name = "TLBI_VMALLE1IS", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 0, .crn = 8, .crm = 3, .opc2 = 0,
   .access = PL1_W, .type = ARM_CP_NO_RAW,
-- 
1.9.1

[Qemu-devel] [PULL 0/7] target-arm queue

[Peter Maydell]

target-arm queue before hardfreeze: these are pretty much all
bugfixes.

-- PMM

The following changes since commit f50a1640fb82708a5d528dee1ace42a224b95b15:

  Merge remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into 
staging (2015-07-05 20:35:47 +0100)

are available in the git repository at:


  git://git.linaro.org/people/pmaydell/qemu-arm.git 
tags/pull-target-arm-20150706

for you to fetch changes up to 257621a9566054472d1d55a819880d0f9da02bda:

  arm_mptimer: Respect IT bit state (2015-07-06 10:26:35 +0100)


target-arm queue:
 * TLBI ALLEI1IS should operate on all CPUs, not just this one
 * Fix interval interrupt of cadence ttc in decrement mode
 * Implement YIELD insn to yield in ARM and Thumb translators
 * ARM GIC: reset all registers
 * arm_mptimer: fix timer shutdown and mode change
 * arm_mptimer: respect IT bit state


Dmitry Osipenko (2):
  arm_mptimer: Fix timer shutdown and mode change
  arm_mptimer: Respect IT bit state

Johannes Schlatow (1):
  Fix interval interrupt of cadence ttc when timer is in decrement mode

Peter Maydell (3):
  target-arm: Split DISAS_YIELD from DISAS_WFE
  target-arm: Implement YIELD insn to yield in ARM and Thumb translators
  hw/intc/arm_gic_common.c: Reset all registers

Sergey Fedorov (1):
  target-arm: fix write helper for TLBI ALLE1IS

 hw/intc/arm_gic_common.c   | 21 ++---
 hw/timer/arm_mptimer.c | 13 ++---
 hw/timer/cadence_ttc.c |  9 -
 target-arm/helper.c|  2 +-
 target-arm/helper.h|  1 +
 target-arm/op_helper.c | 18 +++---
 target-arm/translate-a64.c |  6 ++
 target-arm/translate.c |  7 +++
 target-arm/translate.h |  1 +
 9 files changed, 63 insertions(+), 15 deletions(-)

Re: [Qemu-devel] [BUG/RFC] Two cpus are not brought up normally in SLES11 sp3 VM after reboot

[zhanghailiang]

On 2015/7/6 16:45, Paolo Bonzini wrote:



On 06/07/2015 09:54, zhanghailiang wrote:


 From host, we found that QEMU vcpu1 thread and vcpu7 thread were not
consuming any cpu (Should be in idle state),
All of VCPUs' stacks in host is like bellow:

[] kvm_vcpu_block+0x65/0xa0 [kvm]
[] __vcpu_run+0xd1/0x260 [kvm]
[] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 [kvm]
[] kvm_vcpu_ioctl+0x38e/0x580 [kvm]
[] do_vfs_ioctl+0x8b/0x3b0
[] sys_ioctl+0xa1/0xb0
[] system_call_fastpath+0x16/0x1b
[<2ab9fe1f99a7>] 0x2ab9fe1f99a7
[] 0x

We looked into the kernel codes that could leading to the above 'Stuck'
warning,
and found that the only possible is the emulation of 'cpuid' instruct in
kvm/qemu has something wrong.
But since we can’t reproduce this problem, we are not quite sure.
Is there any possible that the cupid emulation in kvm/qemu has some bug ?


Can you explain the relationship to the cpuid emulation?  What do the
traces say about vcpus 1 and 7?


OK, we searched the VM's kernel codes with the 'Stuck' message, and  it is 
located in
do_boot_cpu(). It's in BSP context, the call process is:
BSP executes start_kernel() -> smp_init() -> smp_boot_cpus() -> do_boot_cpu() 
-> wakeup_secondary_via_INIT() to trigger APs.
It will wait 5s for APs to startup, if some AP not startup normally, it will 
print 'CPU%d Stuck' or 'CPU%d: Not responding'.

If it prints 'Stuck', it means the AP has received the SIPI interrupt and 
begins to execute the code
'ENTRY(trampoline_data)' (trampoline_64.S) , but be stuck in some places before 
smp_callin()(smpboot.c).
The follow is the starup process of BSP and AP.
BSP:
start_kernel()
  ->smp_init()
 ->smp_boot_cpus()
   ->do_boot_cpu()
   ->start_ip = trampoline_address(); //set the address that AP will go 
to execute
   ->wakeup_secondary_cpu_via_init(); // kick the secondary CPU
   ->for (timeout = 0; timeout < 5; timeout++)
   if (cpumask_test_cpu(cpu, cpu_callin_mask)) break;// check if AP 
startup or not

APs:
ENTRY(trampoline_data) (trampoline_64.S)
  ->ENTRY(secondary_startup_64) (head_64.S)
 ->start_secondary() (smpboot.c)
->cpu_init();
->smp_callin();
->cpumask_set_cpu(cpuid, cpu_callin_mask); ->Note: if AP comes 
here, the BSP will not prints the error message.

From above call process, we can be sure that, the AP has been stuck between 
trampoline_data and the cpumask_set_cpu() in
smp_callin(), we look through these codes path carefully, and only found a 
'hlt' instruct that could block the process.
It is located in trampoline_data():

ENTRY(trampoline_data)
...

callverify_cpu  # Verify the cpu supports long mode
testl   %eax, %eax  # Check for return code
jnz no_longmode

...

no_longmode:
hlt
jmp no_longmode

For the process verify_cpu(),
we can only find the 'cpuid' sensitive instruct that could lead VM exit from 
No-root mode.
This is why we doubt if cpuid emulation is wrong in KVM/QEMU that leading to 
the fail in verify_cpu.

From the message in VM, we know vcpu1 and vcpu7 is something wrong.
[5.060042] CPU1: Stuck ??
[   10.170815] CPU7: Stuck ??
[   10.171648] Brought up 6 CPUs

Besides, the follow is the cpus message got from host.
80FF72F5-FF6D-E411-A8C8-00821800:/home/fsp/hrg # virsh qemu-monitor-command 
instance-000
* CPU #0: pc=0x7f64160c683d thread_id=68570
  CPU #1: pc=0x810301f1 (halted) thread_id=68573
  CPU #2: pc=0x810301e2 (halted) thread_id=68575
  CPU #3: pc=0x810301e2 (halted) thread_id=68576
  CPU #4: pc=0x810301e2 (halted) thread_id=68577
  CPU #5: pc=0x810301e2 (halted) thread_id=68578
  CPU #6: pc=0x810301e2 (halted) thread_id=68583
  CPU #7: pc=0x810301f1 (halted) thread_id=68584

Oh, i also forgot to mention in the above message that, we have bond each vCPU 
to different physical CPU in
host.

Thanks,
zhanghailiang

[Qemu-devel] [PULL 5/7] hw/intc/arm_gic_common.c: Reset all registers

[Peter Maydell]

The arm_gic_common reset function was missing reset code for
several of the GIC's state fields:
 * bpr[]
 * abpr[]
 * priority1[]
 * priority2[]
 * sgi_pending[]
 * irq_target[] (SMP configurations only)

These probably went unnoticed because most guests will either
never touch them, or will write to them in the process of
configuring the GIC before enabling interrupts.

Signed-off-by: Peter Maydell 
Message-id: 1435602345-32210-1-git-send-email-peter.mayd...@linaro.org
Reviewed-by: Edgar E. Iglesias 
---
 hw/intc/arm_gic_common.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/hw/intc/arm_gic_common.c b/hw/intc/arm_gic_common.c
index 044ad66..a64d071 100644
--- a/hw/intc/arm_gic_common.c
+++ b/hw/intc/arm_gic_common.c
@@ -123,7 +123,7 @@ static void arm_gic_common_realize(DeviceState *dev, Error 
**errp)
 static void arm_gic_common_reset(DeviceState *dev)
 {
 GICState *s = ARM_GIC_COMMON(dev);
-int i;
+int i, j;
 memset(s->irq_state, 0, GIC_MAXIRQ * sizeof(gic_irq_state));
 for (i = 0 ; i < s->num_cpu; i++) {
 if (s->revision == REV_11MPCORE) {
@@ -135,15 +135,30 @@ static void arm_gic_common_reset(DeviceState *dev)
 s->running_irq[i] = 1023;
 s->running_priority[i] = 0x100;
 s->cpu_ctlr[i] = 0;
+s->bpr[i] = GIC_MIN_BPR;
+s->abpr[i] = GIC_MIN_ABPR;
+for (j = 0; j < GIC_INTERNAL; j++) {
+s->priority1[j][i] = 0;
+}
+for (j = 0; j < GIC_NR_SGIS; j++) {
+s->sgi_pending[j][i] = 0;
+}
 }
 for (i = 0; i < GIC_NR_SGIS; i++) {
 GIC_SET_ENABLED(i, ALL_CPU_MASK);
 GIC_SET_EDGE_TRIGGER(i);
 }
-if (s->num_cpu == 1) {
+
+for (i = 0; i < ARRAY_SIZE(s->priority2); i++) {
+s->priority2[i] = 0;
+}
+
+for (i = 0; i < GIC_MAXIRQ; i++) {
 /* For uniprocessor GICs all interrupts always target the sole CPU */
-for (i = 0; i < GIC_MAXIRQ; i++) {
+if (s->num_cpu == 1) {
 s->irq_target[i] = 1;
+} else {
+s->irq_target[i] = 0;
 }
 }
 s->ctlr = 0;
-- 
1.9.1

[Qemu-devel] [PULL 3/7] target-arm: Split DISAS_YIELD from DISAS_WFE

[Peter Maydell]

Currently we use DISAS_WFE for both WFE and YIELD instructions.
This is functionally correct because at the moment both of them
are implemented as "yield this CPU back to the top level loop so
another CPU has a chance to run". However it's rather confusing
that YIELD ends up calling HELPER(wfe), and if we ever want to
implement real behaviour for WFE and SEV it's likely to trip us up.

Split out the yield codepath to use DISAS_YIELD and a new
HELPER(yield) function, and have HELPER(wfe) call HELPER(yield).

Signed-off-by: Peter Maydell 
Message-id: 1435672316-3311-2-git-send-email-peter.mayd...@linaro.org
Reviewed-by: Peter Crosthwaite 
---
 target-arm/helper.h|  1 +
 target-arm/op_helper.c | 18 +++---
 target-arm/translate-a64.c |  6 ++
 target-arm/translate.h |  1 +
 4 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/target-arm/helper.h b/target-arm/helper.h
index fc885de..827b33d 100644
--- a/target-arm/helper.h
+++ b/target-arm/helper.h
@@ -50,6 +50,7 @@ DEF_HELPER_2(exception_internal, void, env, i32)
 DEF_HELPER_4(exception_with_syndrome, void, env, i32, i32, i32)
 DEF_HELPER_1(wfi, void, env)
 DEF_HELPER_1(wfe, void, env)
+DEF_HELPER_1(yield, void, env)
 DEF_HELPER_1(pre_hvc, void, env)
 DEF_HELPER_2(pre_smc, void, env, i32)
 
diff --git a/target-arm/op_helper.c b/target-arm/op_helper.c
index 7fa32c4..663c05d 100644
--- a/target-arm/op_helper.c
+++ b/target-arm/op_helper.c
@@ -323,13 +323,25 @@ void HELPER(wfi)(CPUARMState *env)
 
 void HELPER(wfe)(CPUARMState *env)
 {
-CPUState *cs = CPU(arm_env_get_cpu(env));
-
-/* Don't actually halt the CPU, just yield back to top
+/* This is a hint instruction that is semantically different
+ * from YIELD even though we currently implement it identically.
+ * Don't actually halt the CPU, just yield back to top
  * level loop. This is not going into a "low power state"
  * (ie halting until some event occurs), so we never take
  * a configurable trap to a different exception level.
  */
+HELPER(yield)(env);
+}
+
+void HELPER(yield)(CPUARMState *env)
+{
+ARMCPU *cpu = arm_env_get_cpu(env);
+CPUState *cs = CPU(cpu);
+
+/* This is a non-trappable hint instruction that generally indicates
+ * that the guest is currently busy-looping. Yield control back to the
+ * top level loop so that a more deserving VCPU has a chance to run.
+ */
 cs->exception_index = EXCP_YIELD;
 cpu_loop_exit(cs);
 }
diff --git a/target-arm/translate-a64.c b/target-arm/translate-a64.c
index e077f2d..689f2be 100644
--- a/target-arm/translate-a64.c
+++ b/target-arm/translate-a64.c
@@ -1199,6 +1199,8 @@ static void handle_hint(DisasContext *s, uint32_t insn,
 s->is_jmp = DISAS_WFI;
 return;
 case 1: /* YIELD */
+s->is_jmp = DISAS_YIELD;
+return;
 case 2: /* WFE */
 s->is_jmp = DISAS_WFE;
 return;
@@ -11107,6 +11109,10 @@ void gen_intermediate_code_internal_a64(ARMCPU *cpu,
 gen_a64_set_pc_im(dc->pc);
 gen_helper_wfe(cpu_env);
 break;
+case DISAS_YIELD:
+gen_a64_set_pc_im(dc->pc);
+gen_helper_yield(cpu_env);
+break;
 case DISAS_WFI:
 /* This is a special case because we don't want to just halt the 
CPU
  * if trying to debug across a WFI.
diff --git a/target-arm/translate.h b/target-arm/translate.h
index bcdcf11..9ab978f 100644
--- a/target-arm/translate.h
+++ b/target-arm/translate.h
@@ -103,6 +103,7 @@ static inline int default_exception_el(DisasContext *s)
 #define DISAS_WFE 7
 #define DISAS_HVC 8
 #define DISAS_SMC 9
+#define DISAS_YIELD 10
 
 #ifdef TARGET_AARCH64
 void a64_translate_init(void);
-- 
1.9.1

[Qemu-devel] [PULL 4/7] target-arm: Implement YIELD insn to yield in ARM and Thumb translators

[Peter Maydell]

Implement the YIELD instruction in the ARM and Thumb translators to
actually yield control back to the top level loop rather than being
a simple no-op. (We already do this for A64.)

Signed-off-by: Peter Maydell 
Reviewed-by: Peter Crosthwaite 
Message-id: 1435672316-3311-3-git-send-email-peter.mayd...@linaro.org
---
 target-arm/translate.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/target-arm/translate.c b/target-arm/translate.c
index 971b6db..69ac18c 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -4080,6 +4080,10 @@ static void gen_rfe(DisasContext *s, TCGv_i32 pc, 
TCGv_i32 cpsr)
 static void gen_nop_hint(DisasContext *s, int val)
 {
 switch (val) {
+case 1: /* yield */
+gen_set_pc_im(s, s->pc);
+s->is_jmp = DISAS_YIELD;
+break;
 case 3: /* wfi */
 gen_set_pc_im(s, s->pc);
 s->is_jmp = DISAS_WFI;
@@ -11459,6 +11463,9 @@ static inline void 
gen_intermediate_code_internal(ARMCPU *cpu,
 case DISAS_WFE:
 gen_helper_wfe(cpu_env);
 break;
+case DISAS_YIELD:
+gen_helper_yield(cpu_env);
+break;
 case DISAS_SWI:
 gen_exception(EXCP_SWI, syn_aa32_svc(dc->svc_imm, dc->thumb),
   default_exception_el(dc));
-- 
1.9.1

[Qemu-devel] [PULL 7/7] arm_mptimer: Respect IT bit state

[Peter Maydell]

From: Dmitry Osipenko 

The timer should fire the interrupt only if the IT (interrupt enable) bit
state of the control register is enabled.

Signed-off-by: Dmitry Osipenko 
Reviewed-by: Peter Crosthwaite 
Signed-off-by: Peter Maydell 
---
 hw/timer/arm_mptimer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/timer/arm_mptimer.c b/hw/timer/arm_mptimer.c
index 0e132b1..3e59c2a 100644
--- a/hw/timer/arm_mptimer.c
+++ b/hw/timer/arm_mptimer.c
@@ -38,7 +38,7 @@ static inline int get_current_cpu(ARMMPTimerState *s)
 
 static inline void timerblock_update_irq(TimerBlock *tb)
 {
-qemu_set_irq(tb->irq, tb->status);
+qemu_set_irq(tb->irq, tb->status && (tb->control & 4));
 }
 
 /* Return conversion factor from mpcore timer ticks to qemu timer ticks.  */
-- 
1.9.1

[Qemu-devel] [PULL 2/7] Fix interval interrupt of cadence ttc when timer is in decrement mode

[Peter Maydell]

From: Johannes Schlatow 

The interval interrupt is not set if the timer is in decrement mode.
This is because x >=0 and x < interval after leaving the while-loop.

Signed-off-by: Johannes Schlatow 
Message-id: 20150630135821.51f3b4fd@johanness-latitude
Reviewed-by: Peter Crosthwaite 
Signed-off-by: Peter Maydell 
---
 hw/timer/cadence_ttc.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/hw/timer/cadence_ttc.c b/hw/timer/cadence_ttc.c
index d46db3c..35bc880 100644
--- a/hw/timer/cadence_ttc.c
+++ b/hw/timer/cadence_ttc.c
@@ -208,15 +208,14 @@ static void cadence_timer_sync(CadenceTimerState *s)
 s->reg_intr |= (2 << i);
 }
 }
+if ((x < 0) || (x >= interval)) {
+s->reg_intr |= (s->reg_count & COUNTER_CTRL_INT) ?
+COUNTER_INTR_IV : COUNTER_INTR_OV;
+}
 while (x < 0) {
 x += interval;
 }
 s->reg_value = (uint32_t)(x % interval);
-
-if (s->reg_value != x) {
-s->reg_intr |= (s->reg_count & COUNTER_CTRL_INT) ?
-COUNTER_INTR_IV : COUNTER_INTR_OV;
-}
 cadence_timer_update(s);
 }
 
-- 
1.9.1

Re: [Qemu-devel] [PATCH] virtio-pci: implement cfg capability

[Michael S. Tsirkin]

On Mon, Jul 06, 2015 at 10:11:18AM +0100, Peter Maydell wrote:
> On 6 July 2015 at 10:06, Michael S. Tsirkin  wrote:
> > On Mon, Jul 06, 2015 at 10:46:31AM +0200, Paolo Bonzini wrote:
> >> Why host endian and not device (in this case little) endian?
> 
> > It's the endian of the originator of the transaction.
> > And emulated device code is all compiled in host endian-ness.
> 
> But address_space_rw() is just the "memcpy bytes to the
> target's memory" operation -- if you have a pile of bytes
> then there are no endianness concerns. If you don't have
> a pile of bytes then you need to know the structure of
> the data you're DMAing around, and you should probably
> have a loop doing things with the specify-the-width functions.
> 
> thanks
> -- PMM

Absolutely. But what if DMA happens to target another device
and not memory? Device needs some endian-ness so it needs
to be converted to that.

-- 
MST

[Qemu-devel] [PULL 6/7] arm_mptimer: Fix timer shutdown and mode change

[Peter Maydell]

From: Dmitry Osipenko 

The running timer can't be stopped because timer control code just
doesn't handle disabling the timer. Fix it by deleting the timer if
the enable bit is cleared.

The timer won't start periodic ticking if a ONE-SHOT -> PERIODIC mode
change happens after a one-shot tick was completed. Fix it by
re-starting ticking if the timer isn't ticking right now.

To avoid code churning, these two fixes are squashed in one commit.

Signed-off-by: Dmitry Osipenko 
Reviewed-by: Peter Crosthwaite 
Signed-off-by: Peter Maydell 
---
 hw/timer/arm_mptimer.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/hw/timer/arm_mptimer.c b/hw/timer/arm_mptimer.c
index 8b93b3c..0e132b1 100644
--- a/hw/timer/arm_mptimer.c
+++ b/hw/timer/arm_mptimer.c
@@ -122,11 +122,18 @@ static void timerblock_write(void *opaque, hwaddr addr,
 case 8: /* Control.  */
 old = tb->control;
 tb->control = value;
-if (((old & 1) == 0) && (value & 1)) {
-if (tb->count == 0 && (tb->control & 2)) {
+if (value & 1) {
+if ((old & 1) && (tb->count != 0)) {
+/* Do nothing if timer is ticking right now.  */
+break;
+}
+if (tb->control & 2) {
 tb->count = tb->load;
 }
 timerblock_reload(tb, 1);
+} else if (old & 1) {
+/* Shutdown the timer.  */
+timer_del(tb->timer);
 }
 break;
 case 12: /* Interrupt status.  */
-- 
1.9.1

Re: [Qemu-devel] [PATCH] virtio-pci: implement cfg capability

[Peter Maydell]

On 6 July 2015 at 11:03, Michael S. Tsirkin  wrote:
> On Mon, Jul 06, 2015 at 10:11:18AM +0100, Peter Maydell wrote:
>> But address_space_rw() is just the "memcpy bytes to the
>> target's memory" operation -- if you have a pile of bytes
>> then there are no endianness concerns. If you don't have
>> a pile of bytes then you need to know the structure of
>> the data you're DMAing around, and you should probably
>> have a loop doing things with the specify-the-width functions.

> Absolutely. But what if DMA happens to target another device
> and not memory? Device needs some endian-ness so it needs
> to be converted to that.

Yes, and address_space_rw() already deals with conversion to
that device's specified endianness.

-- PMM

Re: [Qemu-devel] [PATCH COLO-BLOCK v7 00/17] Block replication for continuous checkpoints

[Wen Congyang]

On 07/06/2015 05:42 PM, Dr. David Alan Gilbert wrote:
> * Wen Congyang (ghost...@gmail.com) wrote:
>> At 2015/7/3 23:30, Dr. David Alan Gilbert Wrote:
>>> * Wen Congyang (we...@cn.fujitsu.com) wrote:
 Block replication is a very important feature which is used for
 continuous checkpoints(for example: COLO).

 Usage:
 Please refer to docs/block-replication.txt

 You can get the patch here:
 https://github.com/wencongyang/qemu-colo/commits/block-replication-v7

 You can get ths patch with framework here:
 https://github.com/wencongyang/qemu-colo/commits/colo_framework_v7.2
>>>
>>> Hi,
>>>   I seem to be having problems with the new listed syntax on the wiki;
>>> on the secondary I'm getting the error
>>>
>>>  Block format 'replication' used by device 'virtio0' doesn't support the 
>>> option 'export'
>>>
>>> ./try/bin/qemu-system-x86_64 -enable-kvm -nographic \
>>>  -boot c -m 4096 -smp 4 -S \
>>>  -name debug-threads=on -trace events=trace-file \
>>>  -netdev tap,id=hn0,script=$PWD/ifup-slave,\
>>> downscript=no,colo_script=$PWD/qemu/scripts/colo-proxy-script.sh,colo_nicname=em4
>>>  \
>>>  -device e1000,mac=9c:da:4d:1c:b5:89,id=net-pci0,netdev=hn0 \
>>>  -device virtio-rng-pci \
>>>  -drive 
>>> if=none,driver=raw,file=/home/localvms/bugzilla.raw,id=colo1,cache=none,aio=native
>>>  \
>>>  -drive 
>>> if=virtio,driver=replication,mode=secondary,export=colo1,throttling.bps-total-max=7000,\
>>> file.file.filename=$TMPDISKS/colo-active-disk.qcow2,\
>>> file.driver=qcow2,\
>>> file.backing.file.filename=$TMPDISKS/colo-hidden-disk.qcow2,\
>>> file.backing.driver=qcow2,\
>>> file.backing.backing.backing_reference=colo1,\
>>> file.backing.allow-write-backing-file=on \
>>>  -incoming tcp:0:
>>
>> Sorry, the option export is removed, because we use the qmp command
>> nbd-server-add to let a BB be NBD server.
> 
> If I remove the export=  the secondary starts, but then when I issue the 
> child_add
> on the primary I get the error:
> 
> Server requires an export name
> 
> on the secondary I had done:
> 
> (qemu) nbd_server_start :8889
> (qemu) nbd_server_add -w colo1
> 
> Can you please confirm your exact command line and sequence needed with this 
> 7.2 set please.

This is the child_add command that I used:

child_add disk1 
child.driver=replication,child.mode=primary,child.file.host=$nbd_host,child.file.port=$nbd_port,child.file.export=colo1,child.file.driver=nbd,child.ignore-errors=on

I guess you remove export from this command too.

Thanks
Wen Congyang

> 
>>
>>> This is using 6fd6ce32 from the colo_framework_v7.2  tag.
>>>
>>> What have I missed?
>>>
>>> Dave
>>> P.S. the name 'file.backing.backing.backing_reference' is not nice!
>>
>> Which name is better? My native language is not English, so any such
>> suggestion is welcome.
> 
> My only problem is the way that 'backing' is repeated 3 times; that seems
> odd!
> 
> Dave
> 
>>
>> Thanks
>> Wen Congyang
>>
>>>

 TODO:
 1. Continuous block replication. It will be started after basic functions
are accepted.

 Changs Log:
 V7:
 1. Implement adding/removing quorum child. Remove the option non-connect.
 2. Simplify the backing refrence option according to Stefan Hajnoczi's 
 suggestion
 V6:
 1. Rebase to the newest qemu.
 V5:
 1. Address the comments from Gong Lei
 2. Speed the failover up. The secondary vm can take over very quickly even
if there are too many I/O requests.
 V4:
 1. Introduce a new driver replication to avoid touch nbd and qcow2.
 V3:
 1: use error_setg() instead of error_set()
 2. Add a new block job API
 3. Active disk, hidden disk and nbd target uses the same AioContext
 4. Add a testcase to test new hbitmap API
 V2:
 1. Redesign the secondary qemu(use image-fleecing)
 2. Use Error objects to return error message
 3. Address the comments from Max Reitz and Eric Blake


 Wen Congyang (17):
   Add new block driver interface to add/delete a BDS's child
   quorum: implement block driver interfaces add/delete a BDS's child
   hmp: add monitor command to add/remove a child
   introduce a new API qemu_opts_absorb_qdict_by_index()
   quorum: allow ignoring child errors
   introduce a new API to enable/disable attach device model
   introduce a new API to check if blk is attached
   block: make bdrv_put_ref_bh_schedule() as a public API
   Backup: clear all bitmap when doing block checkpoint
   allow writing to the backing file
   Allow creating backup jobs when opening BDS
   block: Allow references for backing files
   docs: block replication's description
   Add new block driver interfaces to control block replication
   skip nbd_target when starting block replication
   quorum: implement block driver interfaces for block replication
   Implement new driver for block replicat

Re: [Qemu-devel] [PATCH] blockjob: Don't sleep too short

[Alexandre DERUMIER]

Works fine here,

Thanks !

- Mail original -
De: "Fam Zheng" 
À: "qemu-devel" 
Cc: "Kevin Wolf" , "Jeff Cody" , 
qemu-bl...@nongnu.org, mre...@redhat.com, js...@redhat.com, "aderumier" 
, "stefanha" , "pbonzini" 

Envoyé: Lundi 6 Juillet 2015 05:28:11
Objet: [PATCH] blockjob: Don't sleep too short

block_job_sleep_ns is called by block job coroutines to yield the 
execution to VCPU threads and monitor etc. It is pointless to sleep for 
0 or a few nanoseconds, because that equals to a "yield + enter" with no 
intermission in between (the timer fires immediately in the same 
iteration of event loop), which means other code still doesn't get a 
fair share of main loop / BQL. 

Trim the sleep duration with a minimum value. 

Reported-by: Alexandre DERUMIER  
Signed-off-by: Fam Zheng  
--- 
blockjob.c | 2 ++ 
include/block/blockjob.h | 4 +++- 
2 files changed, 5 insertions(+), 1 deletion(-) 

diff --git a/blockjob.c b/blockjob.c 
index ec46fad..b17ed1f 100644 
--- a/blockjob.c 
+++ b/blockjob.c 
@@ -238,6 +238,8 @@ void block_job_sleep_ns(BlockJob *job, QEMUClockType type, 
int64_t ns) 
return; 
} 

+ ns = MAX(ns, BLOCK_JOB_SLEEP_NS_MIN); 
+ 
job->busy = false; 
if (block_job_is_paused(job)) { 
qemu_coroutine_yield(); 
diff --git a/include/block/blockjob.h b/include/block/blockjob.h 
index 57d8ef1..3deb731 100644 
--- a/include/block/blockjob.h 
+++ b/include/block/blockjob.h 
@@ -146,11 +146,13 @@ void *block_job_create(const BlockJobDriver *driver, 
BlockDriverState *bs, 
int64_t speed, BlockCompletionFunc *cb, 
void *opaque, Error **errp); 

+#define BLOCK_JOB_SLEEP_NS_MIN 1000L 
/** 
* block_job_sleep_ns: 
* @job: The job that calls the function. 
* @clock: The clock to sleep on. 
- * @ns: How many nanoseconds to stop for. 
+ * @ns: How many nanoseconds to stop for. It sleeps at least 
+ * for BLOCK_JOB_SLEEP_NS_MIN ns, even if a smaller value is specified. 
* 
* Put the job to sleep (assuming that it wasn't canceled) for @ns 
* nanoseconds. Canceling the job will interrupt the wait immediately. 
-- 
2.4.3 

Re: [Qemu-devel] [PATCH v5 01/11] softmmu: add helper function to pass through retaddr

[Aurelien Jarno]

On 2015-07-06 11:25, Pavel Dovgalyuk wrote:
> This patch introduces several helpers to pass return address
> which points to the TB. Correct return address allows correct
> restoring of the guest PC and icount. These functions should be used when
> helpers embedded into TB invoke memory operations.
> 
> Reviewed-by: Richard Henderson 

Given that you have changed the patch, the reviewed-by should have been
removed.

> Signed-off-by: Pavel Dovgalyuk 
> ---
>  include/exec/cpu_ldst_template.h  |   59 
> +
>  include/exec/cpu_ldst_useronly_template.h |   25 
>  softmmu_template.h|6 ---
>  tcg/tcg.h |   23 +++
>  4 files changed, 99 insertions(+), 14 deletions(-)
> 

That said it looks fine to me, so you can add mine:

Reviewed-by: Aurelien Jarno 

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] [PATCH v5 02/11] cpu-exec: introduce loop exit with restore function

[Aurelien Jarno]

On 2015-07-06 11:25, Pavel Dovgalyuk wrote:
> This patch introduces loop exit function, which also
> restores guest CPU state according to the value of host
> program counter.
> 
> Reviewed-by: Richard Henderson 
> Reviewed-by: Aurelien Jarno 
> 
> Signed-off-by: Pavel Dovgalyuk 
> ---
>  cpu-exec.c  |9 +
>  include/exec/exec-all.h |1 +
>  2 files changed, 10 insertions(+), 0 deletions(-)
> 
> diff --git a/cpu-exec.c b/cpu-exec.c
> index 0734af2..0b5449e 100644
> --- a/cpu-exec.c
> +++ b/cpu-exec.c
> @@ -134,6 +134,15 @@ void cpu_loop_exit(CPUState *cpu)
>  siglongjmp(cpu->jmp_env, 1);
>  }
>  
> +void cpu_loop_exit_restore(CPUState *cpu, uintptr_t pc)
> +{
> +if (pc) {
> +cpu_restore_state(cpu, pc);
> +}
> +cpu->current_tb = NULL;
> +siglongjmp(cpu->jmp_env, 1);
> +}
> +
>  /* exit the current TB from a signal handler. The host registers are
> restored in a state compatible with the CPU emulator
>   */
> diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
> index 682cb07..6a0ccb6 100644
> --- a/include/exec/exec-all.h
> +++ b/include/exec/exec-all.h
> @@ -90,6 +90,7 @@ TranslationBlock *tb_gen_code(CPUState *cpu,
>int cflags);
>  void cpu_exec_init(CPUArchState *env);
>  void QEMU_NORETURN cpu_loop_exit(CPUState *cpu);
> +void QEMU_NORETURN cpu_loop_exit_restore(CPUState *cpu, uintptr_t pc);
>  
>  #if !defined(CONFIG_USER_ONLY)
>  //bool qemu_in_vcpu_thread(void);

Note that this line is not commented in QEMU master, so your patch
doesn't apply cleanly.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] [PATCH v5 03/11] target-mips: improve exceptions handling

[Aurelien Jarno]

On 2015-07-06 11:25, Pavel Dovgalyuk wrote:
> This patch improves exception handling in MIPS.
> Instructions generate several types of exceptions.
> When exception is generated, it breaks the execution of the current 
> translation
> block. Implementation of the exceptions handling does not correctly
> restore icount for the instruction which caused the exception. In most cases
> icount will be decreased by the value equal to the size of TB.
> This patch passes pointer to the translation block internals to the exception
> handler. It allows correct restoring of the icount value.
> 
> v3 changes:
> This patch stops translation when instruction which always generates exception
> is translated. This improves the performance of the patched version compared
> to original one.
> 
> Signed-off-by: Pavel Dovgalyuk 
> ---
>  target-mips/cpu.h|   23 +++
>  target-mips/helper.h |1 
>  target-mips/msa_helper.c |  158 +++-
>  target-mips/op_helper.c  |  169 ++---
>  target-mips/translate.c  |  363 
> ++
>  5 files changed, 359 insertions(+), 355 deletions(-)

Reviewed-by: Aurelien Jarno 

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] [PATCH] virtio-pci: implement cfg capability

[Michael S. Tsirkin]

On Mon, Jul 06, 2015 at 11:04:24AM +0100, Peter Maydell wrote:
> On 6 July 2015 at 11:03, Michael S. Tsirkin  wrote:
> > On Mon, Jul 06, 2015 at 10:11:18AM +0100, Peter Maydell wrote:
> >> But address_space_rw() is just the "memcpy bytes to the
> >> target's memory" operation -- if you have a pile of bytes
> >> then there are no endianness concerns. If you don't have
> >> a pile of bytes then you need to know the structure of
> >> the data you're DMAing around, and you should probably
> >> have a loop doing things with the specify-the-width functions.
> 
> > Absolutely. But what if DMA happens to target another device
> > and not memory? Device needs some endian-ness so it needs
> > to be converted to that.
> 
> Yes, and address_space_rw() already deals with conversion to
> that device's specified endianness.
> 
> -- PMM

Yes, but incorrectly if target endian != host endian.
For example, LE target and LE device on BE host.

IO callbacks always get a native endian format so they expect to get
byte 0 of the buffer in MSB on this host.


-- 
MST

[Qemu-devel] [PULL for-2.4 0/2] xtensa queue 2015-07-06

[Max Filippov]

Hi Peter,

please pull my current queue for xtensa.

The following changes since commit f50a1640fb82708a5d528dee1ace42a224b95b15:

  Merge remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into 
staging (2015-07-05 20:35:47 +0100)

are available in the git repository at:


  git://github.com/OSLL/qemu-xtensa.git tags/20150706-xtensa

for you to fetch changes up to 1479073b7e849fa03e5892eea0e0b5dadde1a98a:

  target-xtensa: fix gdb register map construction (2015-07-06 13:25:12 +0300)


Xtensa fixes:

- add 64-bit floating point registers;
- fix gdb register map construction.


Max Filippov (2):
  target-xtensa: add 64-bit floating point registers
  target-xtensa: fix gdb register map construction

 target-xtensa/core-dc232b.c  |  2 +-
 target-xtensa/core-dc233c.c  |  2 +-
 target-xtensa/core-fsf.c |  7 ++-
 target-xtensa/cpu.h  | 19 ++-
 target-xtensa/gdbstub.c  | 25 +
 target-xtensa/helper.c   | 14 ++
 target-xtensa/import_core.sh |  6 ++
 target-xtensa/overlay_tool.h |  4 +++-
 target-xtensa/translate.c|  7 ---
 9 files changed, 70 insertions(+), 16 deletions(-)

Re: [Qemu-devel] [PATCH] virtio: Notice when the system doesn't support MSIx at all

[Peter Maydell]

On 3 July 2015 at 09:22, Mark Cave-Ayland  wrote:
> On 19/05/15 21:29, Richard Henderson wrote:
>
>> And do not issue an error_report in that case.
>>
>> Signed-off-by: Richard Henderson 
>> ---
>>  hw/virtio/virtio-pci.c | 15 ++-
>>  1 file changed, 10 insertions(+), 5 deletions(-)
>> --
>>
>> This seems to be about the only sane way to test the value of
>> msi_supported from here.  Thoughts?

> Ping? Any chance of getting this applied for 2.4 since it's something
> that I do get emails about for SPARC64?

Michael would like a respin with the commit message correction
he suggested. RTH -- could you send out a fixed up version, please?

thanks
-- PMM

Re: [Qemu-devel] vpc size reporting problem

[Peter Lieven]

Am 06.07.2015 um 11:44 schrieb Chun Yan Liu:

While testing with a 1GB VHD file created on win7, found that the VHD file
size reported on Windows is different from that is reported by qemu-img
info or within a Linux KVM guest.

Created a dynamic VHD file on win7, on Windows, it is reported 1024MB
(2097152 sectors). But with qemu-img info or within a Linux KVM guest,
it is reported 1023MB (2096640 sectors).

The values in the footer_buf are as follows:
creator_app: "win "
cylinders: 0x820 (2080)
heads: 0x10 (16)
cyl/sec: 0x3f (63)
current_size: 0x4000 (1G)

So, if using current_size, it's correct; but using CHS will get a smaller size.

Should we add a check in this case and use "current_size" instead of
CHS?


As far as I remember the issue was and still is that there is no official spec 
that says
use current_size in case A and CHS in case B.

If currrent_size is greater than CHS and Windows would use CHS (we don't
know that) we might run into issues if Qemu uses current_size. In this
cas we would write data beyond the end of the container (from Windows
perspective).



BTW, before commit 0444dceee, there is a similar check for 'd2v',
if creator_app is 'd2v', using "size" instead of CHS. But in commit
0444dceee, this check is removed. To me, the new check and 'd2v'
check seem to be two different cases, why removing 'd2v' check?


d2v always writes a magic combination of 65535x16x255 for CHS. So commit
0444dceee just changed the behaviour to always use current_size in
case CHS is 65535x16x255 (including d2v).

I personally wouldn't mind to always use current_size that is what e.g. 
VirtualBox does.
Or use current_size if it is greater than the size derived from CHS. But this 
might
break things.

Peter

Re: [Qemu-devel] [PATCH v2 1/1] KVM s390 pci infrastructure modelling

[Michael S. Tsirkin]

On Mon, Jul 06, 2015 at 10:06:50AM +0800, Hong Bo Li wrote:
> 
> 
> On 7/5/2015 2:25, Michael S. Tsirkin wrote:
> >On Fri, Jul 03, 2015 at 07:09:59PM +0800, Hong Bo Li wrote:
> >>>But I would like to note that pci device drivers require driver handshake
> >>>before device goes away.
> >>>IIUC s390 hotplug is immediate, which is a problem.
> >>>Maybe doing the change will help make sure device removal is acked
> >>>by guest before it happens?
> >>>
> >>I did some prototype today. If define zpci first, the progress of unplug
> >>will get complicated.
> >The point is that you don't have to remove the zpci device at all.
> >Remove pci device from zpci.
> >
> >I think the complication you refer to is the guest ack of
> >the removal, isn't it?
> >It's complicated, but it has a chance to actually work with
> >pci device drivers.
> >
> >This, as opposed to just removing the device whenever host
> >tells us to.
> 
> This patch supports the ack in this way:
> After unplugging, the guest will do some cleanup work and disable the zpci 
> device.
> The "is_unplugged" flag in this patch is used to do this ack. Only after the 
> device
> be disabled, we can remove the zpci device from list and do unparent.
> 
> The complication I mean is:
> 1. If we define zpci first, the user can unplug a s390 pci device in two ways:
> a) unplug the vfio pci device first, unplug the zpci device second.
> If the user only tell us to unplug the vfio pci, after the ack, we 
> will
>   still need to wait for the unplug zpci cmd from user,  before that,
>   we have to maintain a useless zpci in list.
> 
> b) Unplug the zpci device directly. This will cause the unplugging of 
> vfio pci
>   automatically. Then on s390, we have a different unplug cmd comparing to
>   other platform.
> 
> 2. If we define vfio pci first,  the user can unplug a s390 pci device in two 
> ways:
> a) Unplug the zpci first, unplug the vfio pci device second.
>We don't need to maintain the extra s390 zpci structure, after ack, we 
> can
>   remove the zpci from list and do unparent.
> b) Unplug the vfio pci directly. This will cause the unplugging of zpci
>automatically.  Then on s390, we have a same unplug cmd comparing to
>other platform.

You can do the automatic unplug of zpci in 1 as well, can you not?


> The ack of these two methods are the same.
> 
> 
> >>So I prefer defining vfio pci first.
> >>And it looks like the vfio pci is the basic device, if we want this
> >>vfio pci to work on s390, we have to define a zpci device to give some
> >>additional information to it.
> >if vfio connects to the bus internal to zpci, it can get
> >things from the bus in a natural way.
> >
> >If zpci is connected to vfio, it becomes much messier.
> >
> 
> For these two ways, the vfio pci both connect to the s390 pci root bus.
> And zpci devices connect to the s390-pci-fac-bus, there is no difference.

What if you don't specify zpci? Does vfio still work?
If no then we have to conclude that vfio is connected through
zpci not alongside it.

-- 
MST

Re: [Qemu-devel] [BUG/RFC] Two cpus are not brought up normally in SLES11 sp3 VM after reboot

[Paolo Bonzini]

On 06/07/2015 11:59, zhanghailiang wrote:
> 
> 
> Besides, the follow is the cpus message got from host.
> 80FF72F5-FF6D-E411-A8C8-00821800:/home/fsp/hrg # virsh
> qemu-monitor-command instance-000
> * CPU #0: pc=0x7f64160c683d thread_id=68570
>   CPU #1: pc=0x810301f1 (halted) thread_id=68573
>   CPU #2: pc=0x810301e2 (halted) thread_id=68575
>   CPU #3: pc=0x810301e2 (halted) thread_id=68576
>   CPU #4: pc=0x810301e2 (halted) thread_id=68577
>   CPU #5: pc=0x810301e2 (halted) thread_id=68578
>   CPU #6: pc=0x810301e2 (halted) thread_id=68583
>   CPU #7: pc=0x810301f1 (halted) thread_id=68584
> 
> Oh, i also forgot to mention in the above message that, we have bond
> each vCPU to different physical CPU in
> host.

Can you capture a trace on the host (trace-cmd record -e kvm) and send
it privately?  Please note which CPUs get stuck, since I guess it's not
always 1 and 7.

Paolo

Re: [Qemu-devel] [PATCH pic32 v3 08/16] pic32: add file mips_pic32mx7.c

[Antony Pavlov]

On Sun,  5 Jul 2015 23:14:56 -0700
Serge Vakulenko  wrote:

> This file implements a platform for Microchip PIC32MX7 microcontroller,
> with three boards (machine types) supported:
> 
> pic32mx7-explorer16  PIC32MX7 microcontroller on Microchip Explorer-16 board
> pic32mx7-max32   PIC32MX7 microcontroller on chipKIT Max32 board
> pic32mx7-maximitePIC32MX7 microcontroller on Geoff's Maximite computer
> 
> Signed-off-by: Serge Vakulenko 
> ---
>  hw/mips/mips_pic32mx7.c | 1641 
> +++
>  1 file changed, 1641 insertions(+)
>  create mode 100644 hw/mips/mips_pic32mx7.c
> 
> diff --git a/hw/mips/mips_pic32mx7.c b/hw/mips/mips_pic32mx7.c
> new file mode 100644
> index 000..21dd115
> --- /dev/null
> +++ b/hw/mips/mips_pic32mx7.c
...
> +printf("Processor: %s\n", cpu_model);
> +if (qemu_logfile) {
> +fprintf(qemu_logfile, "Processor: %s\n", cpu_model);
> +}

Please use qemu_log().


...


> +static QEMUMachine pic32_board[3] = {

please use pic32_board[] instead of pic32_board[3] (e.g. see mips_defs[] 
definition in target-mips/translate_init.c).

> +{
> +.name   = "pic32mx7-max32",
> +.desc   = "PIC32MX7 microcontroller on chipKIT Max32 board",
> +.init   = pic32_init_max32,
> +.max_cpus   = 1,
> +},
> +{
> +.name   = "pic32mx7-maximite",
> +.desc   = "PIC32MX7 microcontroller on Geoff's Maximite board",
> +.init   = pic32_init_maximite,
> +.max_cpus   = 1,
> +},
> +{
> +.name   = "pic32mx7-explorer16",
> +.desc   = "PIC32MX7 microcontroller on Microchip Explorer-16 
> board",
> +.init   = pic32_init_explorer16,
> +.max_cpus   = 1,
> +},
> +};
> +
> +static void pic32_machine_init(void)
> +{
> +qemu_register_machine(&pic32_board[0]);
> +qemu_register_machine(&pic32_board[1]);
> +qemu_register_machine(&pic32_board[2]);

Use cycle and ARRAY_SIZE() here (see again mips_defs[] handling).

> +}
> +
> +type_init(pic32_register_types)
> +machine_init(pic32_machine_init);
> -- 
> 2.2.2
> 
> 


-- 
-- 
Best regards,
  Antony Pavlov

Re: [Qemu-devel] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table

[Paolo Bonzini]

On 04/07/2015 03:12, Alexey Kardashevskiy wrote:
>>
>>> One step back :) Whole dance is what here? There are:
>>> 1) del+set_size(0)
>>> 2) set_size(not zero)+add
>>
>> Then no need for begin/commit. :)
> 
> I got a new problem here - set_size(0) + set_size(not 0) do not invoke
> region_del/region_add which does not seem right. As the result,
> vfio_listener_region_del() never gets called and the IOMMU MR notifier
> stays in the container->giommu_list. What is the correct solution to this?
> 
> Incorrect (most likely :) ) solution is in
> [PATCH qemu v9 13/13] spapr_pci/spapr_pci_vfio: Support Dynamic DMA
> Windows (DDW)
> where I explicitely do  memory_region_del_subregion() +
> memory_region_add_subregion() which seems to do the right job.

I would like a comment there explaining the problem (i.e. what you would
have done, what you expected and what were the actual results: it's not
even that clear from this email), but it doesn't seem like an awful
thing to do.

Paolo

Re: [Qemu-devel] [PATCH qemu v10 14/14] spapr_pci/spapr_pci_vfio: Support Dynamic DMA Windows (DDW)

[David Gibson]

On Mon, Jul 06, 2015 at 12:11:10PM +1000, Alexey Kardashevskiy wrote:
> This adds support for Dynamic DMA Windows (DDW) option defined by
> the SPAPR specification which allows to have additional DMA window(s)
> 
> This implements DDW for emulated and VFIO devices. As all TCE root regions
> are mapped at 0 and 64bit long (and actual tables are child regions),
> this replaces memory_region_add_subregion() with _overlap() to make
> QEMU memory API happy.
> 
> This reserves RTAS token numbers for DDW calls.
> 
> This implements helpers to interact with VFIO kernel interface.
> 
> This changes the TCE table migration descriptor to support dynamic
> tables as from now on, PHB will create as many stub TCE table objects
> as PHB can possibly support but not all of them might be initialized at
> the time of migration because DDW might or might not be requested by
> the guest.
> 
> The "ddw" property is enabled by default on a PHB but for compatibility
> the pseries-2.3 machine and older disable it.
> 
> This implements DDW for VFIO. The host kernel support is required.
> This adds a "levels" property to PHB to control the number of levels
> in the actual TCE table allocated by the host kernel, 0 is the default
> value to tell QEMU to calculate the correct value. Current hardware
> supports up to 5 levels.
> 
> The existing linux guests try creating one additional huge DMA window
> with 64K or 16MB pages and map the entire guest RAM to. If succeeded,
> the guest switches to dma_direct_ops and never calls TCE hypercalls
> (H_PUT_TCE,...) again. This enables VFIO devices to use the entire RAM
> and not waste time on map/unmap later. This adds a "dma64_win_addr"
> property which is a bus address for the 64bit window and by default
> set to 0x800... as this is what the modern POWER8 hardware
> uses and this allows having emulated and VFIO devices on the same bus.
> 
> This adds 4 RTAS handlers:
> * ibm,query-pe-dma-window
> * ibm,create-pe-dma-window
> * ibm,remove-pe-dma-window
> * ibm,reset-pe-dma-window
> These are registered from type_init() callback.
> 
> These RTAS handlers are implemented in a separate file to avoid polluting
> spapr_iommu.c with PCI.
> 
> Signed-off-by: Alexey Kardashevskiy 
> ---
> Changes:
> v10:
> * added dma64_win_addr property to PHB
> * removed redundand check for "!migtable" in spapr_tce_table_post_load()
> 
> v9:
> * fixed default 64bit window start (from mdroth)
> * fixed type cast in dma window update code (from mdroth)
> * spapr_phb_dma_update() now can fail and cause hotplug failure if
> hardware TCE table cannot be mapped to the same bus address as the emulated 
> one
> 
> v7:
> * fixed uninitialized variables
> 
> v6:
> * rework as there is no more special device for VFIO PHB
> 
> v5:
> * total rework
> * enabled for machines >2.3
> * fixed migration
> * merged rtas handlers here
> 
> v4:
> * reset handler is back in generalized form
> 
> v3:
> * removed reset
> * windows_num is now 1 or bigger rather than 0-based value and it is only
> changed in PHB code, not in RTAS
> * added page mask check in create()
> * added SPAPR_PCI_DDW_MAX_WINDOWS to track how many windows are already
> created
> 
> v2:
> * tested on hacked emulated E1000
> * implemented DDW reset on the PHB reset
> * spapr_pci_ddw_remove/spapr_pci_ddw_reset are public for reuse by VFIO
> ---
>  hw/ppc/Makefile.objs|   3 +
>  hw/ppc/spapr.c  |   5 +
>  hw/ppc/spapr_iommu.c|  32 -
>  hw/ppc/spapr_pci.c  | 110 ++--
>  hw/ppc/spapr_pci_vfio.c |  88 +
>  hw/ppc/spapr_rtas_ddw.c | 300 
> 
>  hw/vfio/common.c|   2 +
>  include/hw/pci-host/spapr.h |  21 +++-
>  include/hw/ppc/spapr.h  |  17 ++-
>  trace-events|   6 +
>  10 files changed, 568 insertions(+), 16 deletions(-)
>  create mode 100644 hw/ppc/spapr_rtas_ddw.c
> 
> diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
> index c8ab06e..0b2ff6d 100644
> --- a/hw/ppc/Makefile.objs
> +++ b/hw/ppc/Makefile.objs
> @@ -7,6 +7,9 @@ obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o
>  ifeq ($(CONFIG_PCI)$(CONFIG_PSERIES)$(CONFIG_LINUX), yyy)
>  obj-y += spapr_pci_vfio.o
>  endif
> +ifeq ($(CONFIG_PCI)$(CONFIG_PSERIES), yy)
> +obj-y += spapr_rtas_ddw.o
> +endif
>  # PowerPC 4xx boards
>  obj-y += ppc405_boards.o ppc4xx_devs.o ppc405_uc.o ppc440_bamboo.o
>  obj-y += ppc4xx_pci.o
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 5ca817c..d50d50b 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -1860,6 +1860,11 @@ static const TypeInfo spapr_machine_info = {
>  .driver   = "spapr-pci-host-bridge",\
>  .property = "dynamic-reconfiguration",\
>  .value= "off",\
> +},\
> +{\
> +.driver   = TYPE_SPAPR_PCI_HOST_BRIDGE,\
> +.property = "ddw",\
> +.value= stringify(off),\
>  },
>  
>  #define SPAPR_COMP

Re: [Qemu-devel] [PATCH qemu v10 05/14] spapr_iommu: Introduce "enabled" state for TCE table

[David Gibson]

On Mon, Jul 06, 2015 at 12:11:01PM +1000, Alexey Kardashevskiy wrote:
> Currently TCE tables are created once at start and their size never
> changes. We are going to change that by introducing a Dynamic DMA windows
> support where DMA configuration may change during the guest execution.
> 
> This changes spapr_tce_new_table() to create an empty stub object. Only
> LIOBN is assigned by the time of creation. It still will be called once
> at the owner object (VIO or PHB) creation.
> 
> This introduces an "enabled" state for TCE table objects with two
> helper functions - spapr_tce_table_enable()/spapr_tce_table_disable().
> spapr_tce_table_enable() receives TCE table parameters and allocates
> a guest view of the TCE table (in the user space or KVM).
> spapr_tce_table_disable() disposes the table.
> 
> Follow up patches will disable+enable tables on reset (system reset
> or DDW reset).
> 
> No visible change in behaviour is expected except the actual table
> will be reallocated every reset. We might optimize this later.
> 
> The other way to implement this would be dynamically create/remove
> the TCE table QOM objects but this would make migration impossible
> as migration expects all QOM objects to exist at the receiver
> so we have to have TCE table objects created when migration begins.
> 
> spapr_tce_table_do_enable() is separated from from spapr_tce_table_enable()
> as later it will be called at the sPAPRTCETable post-migration stage when
> it has all the properties set after the migration.
> 
> Signed-off-by: Alexey Kardashevskiy 

Reviewed-by: David Gibson 

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


pgpN0RELpGb82.pgp
Description: PGP signature

Re: [Qemu-devel] [PATCH] target-ppc: fix hugepage support when using memory-backend-file

[David Gibson]

On Mon, Jul 06, 2015 at 10:53:47AM +0200, Alexander Graf wrote:
> On 07/03/15 09:18, David Gibson wrote:
> >On Thu, Jul 02, 2015 at 03:46:14PM -0500, Michael Roth wrote:
> >>Current PPC code relies on -mem-path being used in order for
> >>hugepage support to be detected. With the introduction of
> >>MemoryBackendFile we can now handle this via:
> >>   -object memory-file-backend,mem-path=...,id=hugemem0 \
> >>   -numa node,id=mem0,memdev=hugemem0
> >>
> >>Management tools like libvirt treat the 2 approaches as
> >>interchangeable in some cases, which can lead to user-visible
> >>regressions even for previously supported guest configurations.
> >>
> >>Fix these by also iterating through any configured memory
> >>backends that may be backed by hugepages.
> >>
> >>Since the old code assumed hugepages always backed the entirety
> >>of guest memory, play it safe an pick the minimum across the
> >>max pages sizes for all backends, even ones that aren't backed
> >>by hugepages.
> >>
> >>Cc: qemu-sta...@nongnu.org
> >>Signed-off-by: Michael Roth 
> >Reviewed-by: David Gibson 
> >
> 
> Thanks, applied to ppc-next.

Hrm.. I see that you've pushed out ppc-next with this patch, but looks
like it hasn't been rebased on latest master.

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


pgpBtI2bh5kSv.pgp
Description: PGP signature

Re: [Qemu-devel] [PATCH qemu v10 00/14] spapr: vfio: Enable Dynamic DMA windows (DDW)

[David Gibson]

On Mon, Jul 06, 2015 at 12:10:56PM +1000, Alexey Kardashevskiy wrote:
> 
> (cut-n-paste from kernel patchset)
> 
> Each Partitionable Endpoint (IOMMU group) has an address range on a PCI bus
> where devices are allowed to do DMA. These ranges are called DMA windows.
> By default, there is a single DMA window, 1 or 2GB big, mapped at zero
> on a PCI bus.
> 
> PAPR defines a DDW RTAS API which allows pseries guests
> querying the hypervisor about DDW support and capabilities (page size mask
> for now). A pseries guest may request an additional (to the default)
> DMA windows using this RTAS API.
> The existing pseries Linux guests request an additional window as big as
> the guest RAM and map the entire guest window which effectively creates
> direct mapping of the guest memory to a PCI bus.
> 
> This patchset reworks PPC64 IOMMU code and adds necessary structures
> to support big windows.
> 
> Once a Linux guest discovers the presence of DDW, it does:
> 1. query hypervisor about number of available windows and page size masks;
> 2. create a window with the biggest possible page size (today 4K/64K/16M);
> 3. map the entire guest RAM via H_PUT_TCE* hypercalls;
> 4. switche dma_ops to direct_dma_ops on the selected PE.
> 
> Once this is done, H_PUT_TCE is not called anymore for 64bit devices and
> the guest does not waste time on DMA map/unmap operations.
> 
> Note that 32bit devices won't use DDW and will keep using the default
> DMA window so KVM optimizations will be required (to be posted later).
> 
> This patchset adds DDW support for pseries. The host kernel changes are
> required, available in the current upstream.
> 
> This patchset is based on git://github.com/dgibson/qemu.git spapr-next branch.
> 
> Please comment. Thanks!

I've applied this to my "spapr-dev" branch.  Here's what needs to
happen before I move it into spapr-next (which is what I'll be pushing
to Alex Graf).

 * For you and Gavin to test it to see that DDW and EEH work properly
   together
 * Some word from Alex W on how he wants to go about merging 12-13/14
 * Some indication about who should be merging 2/14
 * Review from at least one more person - I've looked at so many
   versions of the ddw patches I no longer trust that I've got it all
   straight in my head

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


pgpYYaFjXinUt.pgp
Description: PGP signature

Re: [Qemu-devel] [PATCH qemu v10 10/14] spapr_pci: Enable vfio-pci hotplug

[David Gibson]

On Mon, Jul 06, 2015 at 12:11:06PM +1000, Alexey Kardashevskiy wrote:
> sPAPR IOMMU is managing two copies of an TCE table:
> 1) a guest view of the table - this is what emulated devices use and
> this is where H_GET_TCE reads from;
> 2) a hardware TCE table - only present if there is at least one vfio-pci
> device on a PHB; it is updated via a memory listener on a PHB address
> space which forwards map/unmap requests to vfio-pci IOMMU host driver.
> 
> At the moment presence of vfio-pci devices on a bus affect the way
> the guest view table is allocated. If there is no vfio-pci on a PHB
> and the host kernel supports KVM acceleration of H_PUT_TCE, a table
> is allocated in KVM. However, if there is vfio-pci and we do yet not
> support KVM acceleration for these, the table has to be allocated
> by the userspace.
> 
> When vfio-pci device is hotplugged and there were no vfio-pci devices
> already, the guest view table could have been allocated by KVM which
> means that H_PUT_TCE is handled by the host kernel and since we
> do not support vfio-pci in KVM, the hardware table will not be updated.
> 
> This reallocates the guest view table in QEMU if the first vfio-pci
> device has just been plugged. spapr_tce_realloc_userspace() handles this.
> 
> This replays all the mappings to make sure that the tables are in sync.
> This will not have a visible effect though as for a new device
> the guest kernel will allocate-and-map new addresses and therefore
> existing mappings from emulated devices will not be used by vfio-pci
> devices.
> 
> This adds calls to spapr_phb_dma_capabilities_update() in PCI hotplug
> hooks.
> 
> Signed-off-by: Alexey Kardashevskiy 

Reviewed-by: David Gibson 

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


pgpWihGCRXEsd.pgp
Description: PGP signature

Re: [Qemu-devel] [PATCH qemu v10 12/14] vfio: Unregister IOMMU notifiers when container is destroyed

[David Gibson]

On Mon, Jul 06, 2015 at 12:11:08PM +1000, Alexey Kardashevskiy wrote:
> On systems with guest visible IOMMU, adding a new memory region onto
> PCI bus calls vfio_listener_region_add() for every DMA window. This
> installs a notifier for IOMMU memory regions. The notifier is supposed
> to be removed by vfio_listener_region_del(), however in the case of mixed
> PHB (emulated + VFIO devices) when last VFIO device is unplugged and
> container gets destroyed, all existing DMA windows stay alive altogether
> with the notifiers which are on the linked list which head was in
> the destroyed container.
> 
> This unregisters IOMMU memory region notifier when a container is
> destroyed.
> 
> Signed-off-by: Alexey Kardashevskiy 

Reviewed-by: David Gibson 

Alex,

I think this is correct, but you've probably got a better
understanding of it.  Will you take this through your tree?


> ---
> Changes:
> v10:
> * new to the patchset
> ---
>  hw/vfio/common.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index 89ef37b..8eacfd7 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -772,11 +772,19 @@ static void vfio_disconnect_container(VFIOGroup *group)
>  
>  if (QLIST_EMPTY(&container->group_list)) {
>  VFIOAddressSpace *space = container->space;
> +VFIOGuestIOMMU *giommu, *tmp;
>  
>  if (container->iommu_data.release) {
>  container->iommu_data.release(container);
>  }
>  QLIST_REMOVE(container, next);
> +
> +QLIST_FOREACH_SAFE(giommu, &container->giommu_list, giommu_next, 
> tmp) {
> +memory_region_unregister_iommu_notifier(&giommu->n);
> +QLIST_REMOVE(giommu, giommu_next);
> +g_free(giommu);
> +}
> +
>  trace_vfio_disconnect_container(container->fd);
>  close(container->fd);
>  g_free(container);

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


pgpFMxaGOaPJ2.pgp
Description: PGP signature

Re: [Qemu-devel] [PATCH qemu v10 01/14] linux-headers: Update to 4.2-rc1

[Paolo Bonzini]

On 06/07/2015 04:10, Alexey Kardashevskiy wrote:
> This updates linux-headers against master 4.2-rc1 (commit
> d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754). This is the result of
> ./scripts/update-linux-headers.sh work.
> 
> Cc: Paolo Bonzini 
> Cc: Michael S. Tsirkin 
> Signed-off-by: Alexey Kardashevskiy 
> ---
> 
> This is for DDW support on sPAPR.
> ---
>  include/standard-headers/linux/input.h  |  10 +-
>  include/standard-headers/linux/virtio_balloon.h |   1 +
>  include/standard-headers/linux/virtio_gpu.h |   2 +
>  linux-headers/asm-x86/hyperv.h  |  11 ++
>  linux-headers/linux/kvm.h   |   2 +-
>  linux-headers/linux/vfio.h  | 102 -
>  linux-headers/linux/virtio_pci.h| 192 
> 
>  7 files changed, 121 insertions(+), 199 deletions(-)
>  delete mode 100644 linux-headers/linux/virtio_pci.h
> 
> diff --git a/include/standard-headers/linux/input.h 
> b/include/standard-headers/linux/input.h
> index b94d365..a459dd2 100644
> --- a/include/standard-headers/linux/input.h
> +++ b/include/standard-headers/linux/input.h
> @@ -367,7 +367,8 @@ struct input_keymap_entry {
>  #define KEY_MSDOS151
>  #define KEY_COFFEE   152 /* AL Terminal Lock/Screensaver */
>  #define KEY_SCREENLOCK   KEY_COFFEE
> -#define KEY_DIRECTION153
> +#define KEY_ROTATE_DISPLAY   153 /* Display orientation for e.g. tablets 
> */
> +#define KEY_DIRECTIONKEY_ROTATE_DISPLAY
>  #define KEY_CYCLEWINDOWS 154
>  #define KEY_MAIL 155
>  #define KEY_BOOKMARKS156 /* AC Bookmarks */
> @@ -700,6 +701,10 @@ struct input_keymap_entry {
>  #define KEY_NUMERIC_90x209
>  #define KEY_NUMERIC_STAR 0x20a
>  #define KEY_NUMERIC_POUND0x20b
> +#define KEY_NUMERIC_A0x20c   /* Phone key A - HUT Telephony 
> 0xb9 */
> +#define KEY_NUMERIC_B0x20d
> +#define KEY_NUMERIC_C0x20e
> +#define KEY_NUMERIC_D0x20f
>  
>  #define KEY_CAMERA_FOCUS 0x210
>  #define KEY_WPS_BUTTON   0x211   /* WiFi Protected Setup key */
> @@ -971,7 +976,8 @@ struct input_keymap_entry {
>   */
>  #define MT_TOOL_FINGER   0
>  #define MT_TOOL_PEN  1
> -#define MT_TOOL_MAX  1
> +#define MT_TOOL_PALM 2
> +#define MT_TOOL_MAX  2
>  
>  /*
>   * Values describing the status of a force-feedback effect
> diff --git a/include/standard-headers/linux/virtio_balloon.h 
> b/include/standard-headers/linux/virtio_balloon.h
> index 88ada1d..2e2a6dc 100644
> --- a/include/standard-headers/linux/virtio_balloon.h
> +++ b/include/standard-headers/linux/virtio_balloon.h
> @@ -26,6 +26,7 @@
>   * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
>   * SUCH DAMAGE. */
>  #include "standard-headers/linux/types.h"
> +#include "standard-headers/linux/virtio_types.h"
>  #include "standard-headers/linux/virtio_ids.h"
>  #include "standard-headers/linux/virtio_config.h"
>  
> diff --git a/include/standard-headers/linux/virtio_gpu.h 
> b/include/standard-headers/linux/virtio_gpu.h
> index cfcfb46..72ef815 100644
> --- a/include/standard-headers/linux/virtio_gpu.h
> +++ b/include/standard-headers/linux/virtio_gpu.h
> @@ -38,6 +38,8 @@
>  #ifndef VIRTIO_GPU_HW_H
>  #define VIRTIO_GPU_HW_H
>  
> +#include "standard-headers/linux/types.h"
> +
>  enum virtio_gpu_ctrl_type {
>   VIRTIO_GPU_UNDEFINED = 0,
>  
> diff --git a/linux-headers/asm-x86/hyperv.h b/linux-headers/asm-x86/hyperv.h
> index ce6068d..8fba544 100644
> --- a/linux-headers/asm-x86/hyperv.h
> +++ b/linux-headers/asm-x86/hyperv.h
> @@ -199,6 +199,17 @@
>  #define HV_X64_MSR_STIMER3_CONFIG0x40B6
>  #define HV_X64_MSR_STIMER3_COUNT 0x40B7
>  
> +/* Hyper-V guest crash notification MSR's */
> +#define HV_X64_MSR_CRASH_P0  0x4100
> +#define HV_X64_MSR_CRASH_P1  0x4101
> +#define HV_X64_MSR_CRASH_P2  0x4102
> +#define HV_X64_MSR_CRASH_P3  0x4103
> +#define HV_X64_MSR_CRASH_P4  0x4104
> +#define HV_X64_MSR_CRASH_CTL 0x4105
> +#define HV_X64_MSR_CRASH_CTL_NOTIFY  (1ULL << 63)
> +#define HV_X64_MSR_CRASH_PARAMS  \
> + (1 + (HV_X64_MSR_CRASH_P4 - HV_X64_MSR_CRASH_P0))
> +
>  #define HV_X64_MSR_HYPERCALL_ENABLE  0x0001
>  #define HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_SHIFT  12
>  #define HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_MASK   \
> diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
> index fad9e5c..3bac873 100644
> --- a/linux-headers/linux/kvm.h
> +++ b/linux-headers/linux/kvm.h
> @@ -897,7 +897,7 @@ struct kvm_xen_hvm_config {
>   *
>   * KVM_IRQFD_FLAG_RESAMPLE indicates resamplefd is valid and specifies
>   * the irqfd to operate in resampling mode for level trigger

Re: [Qemu-devel] How to break cpu_tb_exec()?

[Lluís Vilanova]

Jun Koi writes:

> On Sat, Jul 4, 2015 at 1:12 AM, Peter Maydell  
> wrote:
> On 3 July 2015 at 18:10, Jun Koi  wrote:
>> On Sat, Jul 4, 2015 at 1:06 AM, Peter Maydell 
>> wrote:
>>> On 3 July 2015 at 18:02, Jun Koi  wrote:
>>> > If this is true, then what if this TB is running infinitely, and do not
>>> > return, or it is in a very long loop? In this case, TCG thread cannot
> be
>>> > interrupted?
>>> 
>>> Every TB starts with a little bit of generated code that checks
>>> the 'tcg_exit_req' flag in the CPUState for the CPU (see the
>>> gen_tb_start() function). If some other part of QEMU wants the
>>> CPU to stop running guest code and return to the top level loop,
>>> it calls cpu_exit() which sets this flag.
>> 
>> 
>> But this does not answer my question yet: if we the flag is only
>> enable when TB already enters the "long loop", then nothing can break
>> this TB execution?

> We check the flag for every TB we execute. Therefore in any
> loop we must check the flag each time round the loop. So
> if another thread sets the flag, we will exit.

> (A TB is always ended by any kind of branch instruction,
> so you can't have a loop within a single TB. A tight loop
> turns into a TB that ends with "branch back to the start
> of this TB", but that will re-execute the flag-check code.)


> Oh right, this tight loop is my main concern. It makes sense now.

I'm not sure if "rep"-style x86 instructions loop inside the same TB, though.


Cheers,
  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] [PATCH qemu v10 14/14] spapr_pci/spapr_pci_vfio: Support Dynamic DMA Windows (DDW)

[Alexey Kardashevskiy]

On 07/06/2015 09:06 PM, David Gibson wrote:

On Mon, Jul 06, 2015 at 12:11:10PM +1000, Alexey Kardashevskiy wrote:

This adds support for Dynamic DMA Windows (DDW) option defined by
the SPAPR specification which allows to have additional DMA window(s)

This implements DDW for emulated and VFIO devices. As all TCE root regions
are mapped at 0 and 64bit long (and actual tables are child regions),
this replaces memory_region_add_subregion() with _overlap() to make
QEMU memory API happy.

This reserves RTAS token numbers for DDW calls.

This implements helpers to interact with VFIO kernel interface.

This changes the TCE table migration descriptor to support dynamic
tables as from now on, PHB will create as many stub TCE table objects
as PHB can possibly support but not all of them might be initialized at
the time of migration because DDW might or might not be requested by
the guest.

The "ddw" property is enabled by default on a PHB but for compatibility
the pseries-2.3 machine and older disable it.

This implements DDW for VFIO. The host kernel support is required.
This adds a "levels" property to PHB to control the number of levels
in the actual TCE table allocated by the host kernel, 0 is the default
value to tell QEMU to calculate the correct value. Current hardware
supports up to 5 levels.

The existing linux guests try creating one additional huge DMA window
with 64K or 16MB pages and map the entire guest RAM to. If succeeded,
the guest switches to dma_direct_ops and never calls TCE hypercalls
(H_PUT_TCE,...) again. This enables VFIO devices to use the entire RAM
and not waste time on map/unmap later. This adds a "dma64_win_addr"
property which is a bus address for the 64bit window and by default
set to 0x800... as this is what the modern POWER8 hardware
uses and this allows having emulated and VFIO devices on the same bus.

This adds 4 RTAS handlers:
* ibm,query-pe-dma-window
* ibm,create-pe-dma-window
* ibm,remove-pe-dma-window
* ibm,reset-pe-dma-window
These are registered from type_init() callback.

These RTAS handlers are implemented in a separate file to avoid polluting
spapr_iommu.c with PCI.

Signed-off-by: Alexey Kardashevskiy 
---
Changes:
v10:
* added dma64_win_addr property to PHB
* removed redundand check for "!migtable" in spapr_tce_table_post_load()

v9:
* fixed default 64bit window start (from mdroth)
* fixed type cast in dma window update code (from mdroth)
* spapr_phb_dma_update() now can fail and cause hotplug failure if
hardware TCE table cannot be mapped to the same bus address as the emulated one

v7:
* fixed uninitialized variables

v6:
* rework as there is no more special device for VFIO PHB

v5:
* total rework
* enabled for machines >2.3
* fixed migration
* merged rtas handlers here

v4:
* reset handler is back in generalized form

v3:
* removed reset
* windows_num is now 1 or bigger rather than 0-based value and it is only
changed in PHB code, not in RTAS
* added page mask check in create()
* added SPAPR_PCI_DDW_MAX_WINDOWS to track how many windows are already
created

v2:
* tested on hacked emulated E1000
* implemented DDW reset on the PHB reset
* spapr_pci_ddw_remove/spapr_pci_ddw_reset are public for reuse by VFIO
---
  hw/ppc/Makefile.objs|   3 +
  hw/ppc/spapr.c  |   5 +
  hw/ppc/spapr_iommu.c|  32 -
  hw/ppc/spapr_pci.c  | 110 ++--
  hw/ppc/spapr_pci_vfio.c |  88 +
  hw/ppc/spapr_rtas_ddw.c | 300 
  hw/vfio/common.c|   2 +
  include/hw/pci-host/spapr.h |  21 +++-
  include/hw/ppc/spapr.h  |  17 ++-
  trace-events|   6 +
  10 files changed, 568 insertions(+), 16 deletions(-)
  create mode 100644 hw/ppc/spapr_rtas_ddw.c

diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
index c8ab06e..0b2ff6d 100644
--- a/hw/ppc/Makefile.objs
+++ b/hw/ppc/Makefile.objs
@@ -7,6 +7,9 @@ obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o
  ifeq ($(CONFIG_PCI)$(CONFIG_PSERIES)$(CONFIG_LINUX), yyy)
  obj-y += spapr_pci_vfio.o
  endif
+ifeq ($(CONFIG_PCI)$(CONFIG_PSERIES), yy)
+obj-y += spapr_rtas_ddw.o
+endif
  # PowerPC 4xx boards
  obj-y += ppc405_boards.o ppc4xx_devs.o ppc405_uc.o ppc440_bamboo.o
  obj-y += ppc4xx_pci.o
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 5ca817c..d50d50b 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1860,6 +1860,11 @@ static const TypeInfo spapr_machine_info = {
  .driver   = "spapr-pci-host-bridge",\
  .property = "dynamic-reconfiguration",\
  .value= "off",\
+},\
+{\
+.driver   = TYPE_SPAPR_PCI_HOST_BRIDGE,\
+.property = "ddw",\
+.value= stringify(off),\
  },

  #define SPAPR_COMPAT_2_2 \
diff --git a/hw/ppc/spapr_iommu.c b/hw/ppc/spapr_iommu.c
index 2d99c3b..b54c3d8 100644
--- a/hw/ppc/spapr_iommu.c
+++ b/hw/ppc/spapr_iommu.c
@@ -136,6 +136,15 @@ static IOMMUTLBEntry 
spap

Re: [Qemu-devel] TAP network breaks after debugger break-in

[Max Filippov]

On Mon, Jul 6, 2015 at 10:57 AM, Fam Zheng  wrote:
> On Mon, 07/06 10:45, Max Filippov wrote:
>> On Mon, Jul 6, 2015 at 10:36 AM, Fam Zheng  wrote:
>> > On Mon, 07/06 10:27, Max Filippov wrote:
>> >> On Mon, Jul 6, 2015 at 4:55 AM, Fam Zheng  wrote:
>> >> > On Sat, 07/04 10:47, Max Filippov wrote:
>> >> >> Hello,
>> >> >>
>> >> >> I'm using QEMU with TAP network and after the commit
>> >> >> 0a2df857a703 "Merge remote-tracking branch
>> >> >> 'remotes/stefanha/tags/net-pull-request' into staging"
>> >> >> I've noticed that activation of debugger connected to QEMU's
>> >> >> gdbstub during network I/O almost always breaks network
>> >> >> connection: network stops working completely after return
>> >> >> from the debugger.
>> >> >>
>> >> >> Stefan, Fam, any hint on where to start debugging it?
>> >> >>
>> >> >
>> >> > Which NIC are you using?
>> >>
>> >> opencores_eth.
>> >>
>> >
>> > Does reverting a90a7425cf592a3afeff3eaf32f543b83050ee5c work?
>>
>> Looks like it does, though the revert isn't clean.
>
> I can't really tell what happened to opencores_eth because it has proper
> open_eth_notify_can_receive() calls that should flush the queue as expected
> since a90a7425cf592a3afeff3eaf32f543b83050ee5c (some other NICs are broken
> because of missing such flushes).
>
> FWIW, what is changed by that patch is that if NIC's .can_receive() callback
> returns 0, it should later call qemu_flush_queued_packets() explicitly, when
> conditions becomes ready again (i.e. .can_receive() would return true on next
> invocation).

Ok, what I see is the following:

#0  tap_update_fd_handler (s=0x55fbe290) at qemu/net/tap.c:69
#1  0x556ec0d1 in tap_read_poll (s=0x55fbe290,
enable=false) at qemu/net/tap.c:80
#2  0x556ec68d in tap_send (opaque=0x55fbe290) at qemu/net/tap.c:202

tap_read_poll is called with 'enable' set to false from tap_send, because size
returned from qemu_send_packet_async is 0, because of this piece of code
in the qemu_net_queue_send:

if (queue->delivering || !qemu_can_send_packet(sender)) {
qemu_net_queue_append(queue, sender, flags, data, size, sent_cb);
return 0;
}

Previously this function wasn't called after qemu_can_send_packet returns 0,
which was changed by the patch a90a7425cf592a.

tap_read_poll is never called with 'enable' set to true after that.

-- 
Thanks.
-- Max

Re: [Qemu-devel] [PATCH] cpu_defs: Simplify CPUTLB padding logic

[Richard Henderson]

On 07/06/2015 09:43 AM, Paolo Bonzini wrote:



On 05/07/2015 23:08, Peter Crosthwaite wrote:

There was a complicated subtractive arithmetic for determining the
padding on the CPUTLBEntry structure. Simplify this with a union.

Signed-off-by: Peter Crosthwaite 
---
  include/exec/cpu-defs.h | 23 ---
  1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/include/exec/cpu-defs.h b/include/exec/cpu-defs.h
index 98b9cff..5093be2 100644
--- a/include/exec/cpu-defs.h
+++ b/include/exec/cpu-defs.h
@@ -105,17 +105,18 @@ typedef struct CPUTLBEntry {
 bit 3  : indicates that the entry is invalid
 bit 2..0   : zero
  */
-target_ulong addr_read;
-target_ulong addr_write;
-target_ulong addr_code;
-/* Addend to virtual address to get host address.  IO accesses
-   use the corresponding iotlb value.  */
-uintptr_t addend;
-/* padding to get a power of two size */
-uint8_t dummy[(1 << CPU_TLB_ENTRY_BITS) -
-  (sizeof(target_ulong) * 3 +
-   ((-sizeof(target_ulong) * 3) & (sizeof(uintptr_t) - 1)) +
-   sizeof(uintptr_t))];
+union {


The struct CPUTLBEntry can be changed to union CPUTLBEntry directly,
with no need for the anonymous struct.


Um, no it can't.  That would put all of the members at the same address.


Which compiler version started implementing anonymous structs?


A long long time ago -- gcc 2 era.


Or can we just add

 __attribute__((__aligned__(1 << CPU_TLB_ENTRY_BITS)))


The structure isn't currently aligned, and it needn't be.  We only need the 
size to be a power of two for the addressing.




r~

Re: [Qemu-devel] [PATCH] disas: Defeature print_target_address

[Richard Henderson]

On 07/05/2015 09:50 PM, Peter Crosthwaite wrote:

It does not work in multi-arch as it requires the CPU specific
TARGET_VIRT_ADDR_SPACE_BITS global define. Just use the generic
version that does no masking. Targets should be responsible for
passing in a sane virtual address.

Signed-off-by: Peter Crosthwaite
---
Depends on "Unify and QOMify (target|monitor)_disas" series

  disas.c | 12 ++--
  1 file changed, 2 insertions(+), 10 deletions(-)


Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH qom v4 0/7] Unify and QOMify (target|monitor)_disas

[Richard Henderson]

On 07/05/2015 09:48 PM, Peter Crosthwaite wrote:

Ping!

If this or orphaned, I'd like to send the PULL on the H-freeze.


Didn't all this get reviewed?  I thought it did...


r~



Regards,
Peter

On Tue, Jun 23, 2015 at 8:57 PM, Peter Crosthwaite
 wrote:

These two functions are mostly trying to do the same thing, which is
disassemble a target instruction (sequence) for printfing. The
architecture specific setup is largely duped between the two functions.

The approach is to add a single QOM hook on the CPU level to setup the
disassembler (P1&2). The two stage flags system is removed. That is,
the old scheme, is for the translate/montitor code to pass in flags
that disas.c then interprets. Instead the entire job of setting up arch
specifics is outsourced to target-specific code (via the new QOM hook)
removing the need for the flags system. Both monitor_disas and
target_disas then calls this singly defined hook if it is available.

Three architectures (microblaze, cris and ARM) are patched
to use the new QOMification and at the same time, make the
monitor_disas consistent with target_disas. The #if defined TARGET_FOO
for each is removed from disas.c (bringing us closer to the exciting
goal of no #ifdef TARGET_FOO in system mode code).

Microblaze is trivial, the target_disas setup is directly applicable
to monitor_disas to bring in microblaze monitor disas support (P5).

Cris had a small hiccup, a patch is needed to handle monitor_disas's
0 buffer length (P6). Then cris is patched to enable monitor disas
in same way as microblaze (P7).

ARM is the harder. The vixl A64 disas was hardcoded to fprintf with
a statically inited output stream (matching target_disas). The vixl
printfery is patched to be runtime variable (P3). P4 brings
ARM monitor disassembly online (via using the target_disas
implementation as the QOMified implementation).

Changed since v3:
Minor commit message tweaks.
Fix CPP contructor argument order.

Changed since v2 (RTH/PMM review):
Rebased on monitor+disas ENV_GET_CPU removal
Fixed minor comments (see indiv patches).

Changed since v1 (RTH review):
Use QOMified approach.
Remove flags system.
Limit scope to only the 3 converted arches
Addressed comments on CPP constructor changes

Peter Crosthwaite (7):
   disas: Add print_insn to disassemble info
   disas: QOMify target specific setup
   disas: arm-a64: Make printfer and stream variable
   disas: arm: QOMify target specific disas setup
   disas: microblaze: QOMify target specific disas setup
   disas: cris: Fix 0 buffer length case
   disas: cris: QOMify target specific disas setup

  disas.c | 119 ++--
  disas/arm-a64.cc|  22 +++--
  disas/cris.c|   6 +--
  include/disas/bfd.h |   6 +++
  include/qom/cpu.h   |   4 ++
  target-arm/cpu.c|  35 ++
  target-cris/cpu.c   |  16 +++
  target-microblaze/cpu.c |   8 
  8 files changed, 133 insertions(+), 83 deletions(-)

--
1.9.1

Re: [Qemu-devel] [PATCH qom v4 0/7] Unify and QOMify (target|monitor)_disas

[Andreas Färber]

Am 06.07.2015 um 13:44 schrieb Richard Henderson:
> On 07/05/2015 09:48 PM, Peter Crosthwaite wrote:
>> Ping!
>>
>> If this or orphaned, I'd like to send the PULL on the H-freeze.
> 
> Didn't all this get reviewed?  I thought it did...

If everything is reviewed I could take it for my CPU pull later today.
Not sure if we'll run into a cpu.h conflict otherwise.

af

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)

Re: [Qemu-devel] [PATCH] target-ppc: fix hugepage support when using memory-backend-file

[Alexander Graf]

On 07/06/15 13:09, David Gibson wrote:

On Mon, Jul 06, 2015 at 10:53:47AM +0200, Alexander Graf wrote:

On 07/03/15 09:18, David Gibson wrote:

On Thu, Jul 02, 2015 at 03:46:14PM -0500, Michael Roth wrote:

Current PPC code relies on -mem-path being used in order for
hugepage support to be detected. With the introduction of
MemoryBackendFile we can now handle this via:
   -object memory-file-backend,mem-path=...,id=hugemem0 \
   -numa node,id=mem0,memdev=hugemem0

Management tools like libvirt treat the 2 approaches as
interchangeable in some cases, which can lead to user-visible
regressions even for previously supported guest configurations.

Fix these by also iterating through any configured memory
backends that may be backed by hugepages.

Since the old code assumed hugepages always backed the entirety
of guest memory, play it safe an pick the minimum across the
max pages sizes for all backends, even ones that aren't backed
by hugepages.

Cc: qemu-sta...@nongnu.org
Signed-off-by: Michael Roth 

Reviewed-by: David Gibson 


Thanks, applied to ppc-next.

Hrm.. I see that you've pushed out ppc-next with this patch, but looks
like it hasn't been rebased on latest master.


Yup. Done now.


Alex