Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 0/3] Enable MTTCG on PPC64

[Nikunj A Dadhania]

Alex Bennée  writes:

> luigi burdo  writes:
>
>> Hi David and Nikuji,
>>
>> can i suggest to remove the message:
>>
>>
>> Guest not yet converted to MTTCG - you may get unexpected results
>> where the mttcg is enabled?
>
> Have you declared the memory ordering for the guest?

No, I havent done that yet, will send a patch.

>> another thing im finding  is this message
>> Guest expects a stronger memory ordering than the host provides
>> This may cause strange/hard to debug errors
>
> See ca759f9e387db87e1719911f019bc60c74be9ed8 for an example.

Regards
Nikunj

Re: [Qemu-devel] [PATCH 15/21] ppc/pnv: add initial IPMI sensors for the BMC simulator

[David Gibson]

On Wed, Apr 05, 2017 at 02:41:40PM +0200, Cédric Le Goater wrote:
> Skiboot, the firmware for the PowerNV platform, expects the BMC to
> provide some specific IPMI sensors. These sensors are exposed in the
> device tree and their values are updated by the firmware at boot time.
> 
> Sensors of interest are :
> 
>   "FW Boot Progress"
>   "Boot Count"
> 
> As such a device is defined on the command line, we can only detect
> its presence at reset time.
> 
> Signed-off-by: Cédric Le Goater 
> ---
>  hw/ppc/Makefile.objs |  2 +-
>  hw/ppc/pnv.c | 17 +++
>  hw/ppc/pnv_bmc.c | 81 
> 
>  include/hw/ppc/pnv.h |  7 +
>  4 files changed, 106 insertions(+), 1 deletion(-)
>  create mode 100644 hw/ppc/pnv_bmc.c
> 
> diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
> index ef67ea820158..7efc68674819 100644
> --- a/hw/ppc/Makefile.objs
> +++ b/hw/ppc/Makefile.objs
> @@ -6,7 +6,7 @@ obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o 
> spapr_rtas.o
>  obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o spapr_rng.o
>  obj-$(CONFIG_PSERIES) += spapr_cpu_core.o spapr_ovec.o
>  # IBM PowerNV
> -obj-$(CONFIG_POWERNV) += pnv.o pnv_xscom.o pnv_core.o pnv_lpc.o pnv_psi.o 
> pnv_occ.o
> +obj-$(CONFIG_POWERNV) += pnv.o pnv_xscom.o pnv_core.o pnv_lpc.o pnv_psi.o 
> pnv_occ.o pnv_bmc.o
>  ifeq ($(CONFIG_PCI)$(CONFIG_PSERIES)$(CONFIG_LINUX), yyy)
>  obj-y += spapr_pci_vfio.o
>  endif
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index dfa1cf849b35..c7caecad0aa6 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -35,6 +35,7 @@
>  #include "qapi/visitor.h"
>  #include "monitor/monitor.h"
>  #include "hw/intc/intc.h"
> +#include "hw/ipmi/ipmi.h"
>  
>  #include "hw/ppc/xics.h"
>  #include "hw/ppc/pnv_xscom.h"
> @@ -458,16 +459,32 @@ static void *powernv_create_fdt(MachineState *machine)
>  }
>  
>  powernv_populate_isa(pnv->isa_bus, fdt);
> +
> +if (pnv->bmc) {
> +pnv_bmc_populate_sensors(pnv->bmc, fdt);
> +}
> +
>  return fdt;
>  }
>  
>  static void ppc_powernv_reset(void)
>  {
>  MachineState *machine = MACHINE(qdev_get_machine());
> +PnvMachineState *pnv = POWERNV_MACHINE(machine);
>  void *fdt;
>  
>  qemu_devices_reset();
>  
> +/* OpenPOWER systems have a BMC, which can be defined on the
> + * command line with:
> + *
> + *   -device ipmi-bmc-sim,id=bmc0
> + *
> + * This is the internal simulator but it could also be an external
> + * BMC.
> + */
> +pnv->bmc = object_resolve_path_type("", TYPE_IPMI_BMC, NULL);

I'd suggest typing the pointer and doing the cast/test here, rather
than in the functions that need to manipulate it.

>  fdt = powernv_create_fdt(machine);
>  
>  /* Pack resulting tree */
> diff --git a/hw/ppc/pnv_bmc.c b/hw/ppc/pnv_bmc.c
> new file mode 100644
> index ..2998530dc4c0
> --- /dev/null
> +++ b/hw/ppc/pnv_bmc.c
> @@ -0,0 +1,81 @@
> +/*
> + * QEMU PowerNV, BMC related functions
> + *
> + * Copyright (c) 2016-2017, IBM Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License, version 2, as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, see .
> + */
> +
> +#include "qemu/osdep.h"
> +#include "hw/hw.h"
> +#include "sysemu/sysemu.h"
> +#include "target/ppc/cpu.h"
> +#include "qapi/error.h"
> +#include "qemu/log.h"
> +#include "hw/ipmi/ipmi.h"
> +#include "hw/ppc/fdt.h"
> +
> +#include "hw/ppc/pnv.h"
> +
> +#include 
> +
> +/* TODO: include definition in ipmi.h */
> +#define IPMI_SDR_FULL_TYPE 1
> +
> +void pnv_bmc_populate_sensors(Object *bmc, void *fdt)
> +{
> +int offset;
> +int i;
> +const struct ipmi_sdr_compact *sdr;
> +uint16_t nextrec;
> +
> +offset = fdt_add_subnode(fdt, 0, "/bmc");
> +_FDT(offset);
> +
> +_FDT((fdt_setprop_string(fdt, offset, "name", "bmc")));
> +_FDT((fdt_setprop_cell(fdt, offset, "#address-cells", 0x1)));
> +_FDT((fdt_setprop_cell(fdt, offset, "#size-cells", 0x0)));
> +
> +offset = fdt_add_subnode(fdt, offset, "sensors");
> +_FDT(offset);
> +
> +_FDT((fdt_setprop_cell(fdt, offset, "#address-cells", 0x1)));
> +_FDT((fdt_setprop_cell(fdt, offset, "#size-cells", 0x0)));
> +
> +for (i = 0; !ipmi_bmc_sdr_find(IPMI_BMC(bmc), i, , ); i++) {
> +int off;
> +char *name;
> +
> +if (sdr->header.rec_type != IPMI_SDR_COMPACT_TYPE ||
> +sdr->header.rec_type != IPMI_SDR_FULL_TYPE) {

Um.. the 

Re: [Qemu-devel] [PATCH 16/21] ppc/pnv: generate an OEM SEL event on shutdown

[David Gibson]

On Wed, Apr 05, 2017 at 02:41:41PM +0200, Cédric Le Goater wrote:
> OpenPOWER systems expect to be notified with such an event before a
> shutdown or a reboot. An OEM SEL message is sent with specific
> identifiers and a user data containing the request : OFF or REBOOT.
> 
> Signed-off-by: Cédric Le Goater 

Reviewed-by: David Gibson 

> ---
>  hw/ppc/pnv.c | 14 ++
>  hw/ppc/pnv_bmc.c | 42 ++
>  include/hw/ppc/pnv.h |  3 +++
>  3 files changed, 59 insertions(+)
> 
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index c7caecad0aa6..df0a88c3e252 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -467,6 +467,15 @@ static void *powernv_create_fdt(MachineState *machine)
>  return fdt;
>  }
>  
> +static void pnv_powerdown_notify(Notifier *n, void *opaque)
> +{
> +PnvMachineState *pnv = POWERNV_MACHINE(qdev_get_machine());
> +
> +if (pnv->bmc) {
> +pnv_bmc_powerdown(pnv->bmc);
> +}
> +}
> +
>  static void ppc_powernv_reset(void)
>  {
>  MachineState *machine = MACHINE(qdev_get_machine());
> @@ -662,6 +671,11 @@ static void ppc_powernv_init(MachineState *machine)
>  
>  /* Create an RTC ISA device too */
>  rtc_init(pnv->isa_bus, 2000, NULL);
> +
> +/* OpenPOWER systems use a IPMI SEL Event message to notify the
> + * host to powerdown */
> +pnv->powerdown_notifier.notify = pnv_powerdown_notify;
> +qemu_register_powerdown_notifier(>powerdown_notifier);
>  }
>  
>  /*
> diff --git a/hw/ppc/pnv_bmc.c b/hw/ppc/pnv_bmc.c
> index 2998530dc4c0..d9ed774acbac 100644
> --- a/hw/ppc/pnv_bmc.c
> +++ b/hw/ppc/pnv_bmc.c
> @@ -32,6 +32,48 @@
>  /* TODO: include definition in ipmi.h */
>  #define IPMI_SDR_FULL_TYPE 1
>  
> +/*
> + * OEM SEL Event data packet sent by BMC in response of a Read Event
> + * Message Buffer command
> + */
> +typedef struct OemSel {
> +/* SEL header */
> +uint8_t id[2];
> +uint8_t type;
> +uint8_t timestamp[4];
> +uint8_t manuf_id[3];
> +
> +/* OEM SEL data (6 bytes) follows */
> +uint8_t netfun;
> +uint8_t cmd;
> +uint8_t data[4];
> +} OemSel;
> +
> +#define SOFT_OFF0x00
> +#define SOFT_REBOOT 0x01
> +
> +static void pnv_gen_oem_sel(Object *obj, uint8_t reboot)
> +{
> +/* IPMI SEL Event are 16 bytes long */
> +OemSel sel = {
> +.id= { 0x55 , 0x55 },
> +.type  = 0xC0, /* OEM */
> +.manuf_id  = { 0x0, 0x0, 0x0 },
> +.timestamp = { 0x0, 0x0, 0x0, 0x0 },
> +.netfun= 0x3A, /* IBM */
> +.cmd   = 0x04, /* AMI OEM SEL Power Notification */
> +.data  = { reboot, 0xFF, 0xFF, 0xFF },
> +};
> +
> +ipmi_bmc_gen_event(IPMI_BMC(obj), (uint8_t *) ,
> +   0 /* do not log the event */);
> +}
> +
> +void pnv_bmc_powerdown(Object *obj)
> +{
> +pnv_gen_oem_sel(obj, SOFT_OFF);
> +}
> +
>  void pnv_bmc_populate_sensors(Object *bmc, void *fdt)
>  {
>  int offset;
> diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
> index 050763f6cf54..b70a13bd4175 100644
> --- a/include/hw/ppc/pnv.h
> +++ b/include/hw/ppc/pnv.h
> @@ -132,6 +132,8 @@ typedef struct PnvMachineState {
>  uint32_t cpld_irqstate;
>  
>  Object   *bmc;
> +
> +Notifier powerdown_notifier;
>  } PnvMachineState;
>  
>  #define PNV_FDT_ADDR  0x0100
> @@ -141,6 +143,7 @@ typedef struct PnvMachineState {
>   * BMC helpers
>   */
>  void pnv_bmc_populate_sensors(Object *objbmc, void *fdt);
> +void pnv_bmc_powerdown(Object *objbmc);
>  
>  /*
>   * POWER8 MMIO base addresses

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 17/21] qdev: Add a hook for a bus to device if it can add devices

[David Gibson]

On Wed, Apr 05, 2017 at 02:41:42PM +0200, Cédric Le Goater wrote:
> From: Benjamin Herrenschmidt 
> 
> This allows a bus class to tell whether a given bus has room for
> any new device. max_dev isn't sufficient as the rules can depend
> on some arguments or can differ between instances of a bus. This
> will be used by PCI in subsequent patches
> 
> Signed-off-by: Benjamin Herrenschmidt 
> [clg: updated for qemu-2.9 ]
> Signed-off-by: Cédric Le Goater 
> ---
>  include/hw/qdev-core.h |  1 +
>  qdev-monitor.c | 14 +-
>  2 files changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
> index b44b47676576..867662ba5352 100644
> --- a/include/hw/qdev-core.h
> +++ b/include/hw/qdev-core.h
> @@ -201,6 +201,7 @@ struct BusClass {
>   */
>  char *(*get_fw_dev_path)(DeviceState *dev);
>  void (*reset)(BusState *bus);
> +bool (*can_add_device)(BusState *bus, QemuOpts *opts);
>  BusRealize realize;
>  BusUnrealize unrealize;
>  
> diff --git a/qdev-monitor.c b/qdev-monitor.c
> index 5f2fcdfc4551..c6eca929c473 100644
> --- a/qdev-monitor.c
> +++ b/qdev-monitor.c
> @@ -415,7 +415,7 @@ static inline bool qbus_is_full(BusState *bus)
>   * Return the bus if found, else %NULL.
>   */
>  static BusState *qbus_find_recursive(BusState *bus, const char *name,
> - const char *bus_typename)
> + const char *bus_typename, QemuOpts 
> *opts)
>  {
>  BusChild *kid;
>  BusState *pick, *child, *ret;
> @@ -429,7 +429,10 @@ static BusState *qbus_find_recursive(BusState *bus, 
> const char *name,
>  }
>  
>  if (match && !qbus_is_full(bus)) {
> -return bus; /* root matches and isn't full */
> +BusClass *bc = BUS_GET_CLASS(bus);
> +if (!bc->can_add_device || bc->can_add_device(bus, opts)) {
> +return bus; /* root matches and isn't full */

Seems like qbus_is_full() should be changed to use the can_add_device
hook, rather than changing the caller here.  Essentially the current
max_devs implementation would become the fallback if the bus doesn't
define a bus specific test.

> +}
>  }
>  
>  pick = match ? bus : NULL;
> @@ -437,7 +440,7 @@ static BusState *qbus_find_recursive(BusState *bus, const 
> char *name,
>  QTAILQ_FOREACH(kid, >children, sibling) {
>  DeviceState *dev = kid->child;
>  QLIST_FOREACH(child, >child_bus, sibling) {
> -ret = qbus_find_recursive(child, name, bus_typename);
> +ret = qbus_find_recursive(child, name, bus_typename, opts);
>  if (ret && !qbus_is_full(ret)) {
>  return ret; /* a descendant matches and isn't full */
>  }
> @@ -467,7 +470,7 @@ static BusState *qbus_find(const char *path, Error **errp)
>  assert(!path[0]);
>  elem[0] = len = 0;
>  }
> -bus = qbus_find_recursive(sysbus_get_default(), elem, NULL);
> +bus = qbus_find_recursive(sysbus_get_default(), elem, NULL, NULL);
>  if (!bus) {
>  error_setg(errp, "Bus '%s' not found", elem);
>  return NULL;
> @@ -591,7 +594,8 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error **errp)
>  return NULL;
>  }
>  } else if (dc->bus_type != NULL) {
> -bus = qbus_find_recursive(sysbus_get_default(), NULL, dc->bus_type);
> +bus = qbus_find_recursive(sysbus_get_default(), NULL, dc->bus_type,
> +  opts);
>  if (!bus || qbus_is_full(bus)) {
>  error_setg(errp, "No '%s' bus found for device '%s'",
> dc->bus_type, driver);

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 14/21] ppc/pnv: populate device tree for IPMI BT devices

[David Gibson]

On Wed, Apr 05, 2017 at 02:41:39PM +0200, Cédric Le Goater wrote:
> When an ipmi-bt device [1] is defined on the ISA bus, we need to
> populate the device tree with the object properties. Such devices are
> created with the command line options :
> 
>-device ipmi-bmc-sim,id=bmc0 -device isa-ipmi-bt,bmc=bmc0,irq=10
> 
> [1] https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg03168.html
> 
> Signed-off-by: Cédric Le Goater 
> ---
>  hw/ppc/pnv.c | 35 +++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index 00e594a0cbe3..dfa1cf849b35 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -332,6 +332,39 @@ static void powernv_populate_serial(ISADevice *d, void 
> *fdt, int lpc_off)
>  _FDT((fdt_setprop_string(fdt, node, "device_type", "serial")));
>  }
>  
> +static void powernv_populate_ipmi_bt(ISADevice *d, void *fdt, int lpc_off)
> +{
> +const char compatible[] = "bt\0ipmi-bt";
> +uint32_t io_base = 0x0;
> +uint32_t io_regs[] = {
> +cpu_to_be32(1),
> +cpu_to_be32(io_base),

Best not to include this part of the initializer, since you have to
overwrite it later anyway.  Either just use 0 with a /*placeholder */
comment, or use designated array initializers.

> +cpu_to_be32(3)
> +};
> +uint32_t irq;
> +char *name;
> +int node;
> +
> +io_base = object_property_get_int(OBJECT(d), "ioport", _fatal);
> +io_regs[1] = cpu_to_be32(io_base);
> +
> +irq = object_property_get_int(OBJECT(d), "irq", _fatal);
> +
> +name = g_strdup_printf("%s@i%x", qdev_fw_name(DEVICE(d)), io_base);
> +node = fdt_add_subnode(fdt, lpc_off, name);
> +_FDT(node);
> +g_free(name);
> +
> +fdt_setprop(fdt, node, "reg", io_regs, sizeof(io_regs));
> +fdt_setprop(fdt, node, "compatible", compatible, sizeof(compatible));
> +
> +/* Mark it as reserved to avoid Linux trying to claim it */
> +_FDT((fdt_setprop_string(fdt, node, "status", "reserved")));
> +_FDT((fdt_setprop_cell(fdt, node, "interrupts", irq)));
> +_FDT((fdt_setprop_cell(fdt, node, "interrupt-parent",
> +   fdt_get_phandle(fdt, lpc_off;
> +}
> +
>  typedef struct ForeachPopulateArgs {
>  void *fdt;
>  int offset;
> @@ -346,6 +379,8 @@ static int powernv_populate_isa_device(DeviceState *dev, 
> void *opaque)
>  powernv_populate_rtc(d, args->fdt, args->offset);
>  } else if (object_dynamic_cast(OBJECT(dev), TYPE_ISA_SERIAL)) {
>  powernv_populate_serial(d, args->fdt, args->offset);
> +} else if (object_dynamic_cast(OBJECT(dev), "isa-ipmi-bt")) {
> +powernv_populate_ipmi_bt(d, args->fdt, args->offset);
>  } else {
>  error_report("unknown isa device %s@i%x", qdev_fw_name(dev),
>   d->ioport_id);

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 18/21] pci: Use the new pci_can_add_device() to enforce devfn_min/max

[David Gibson]

On Wed, Apr 05, 2017 at 02:41:43PM +0200, Cédric Le Goater wrote:
> From: Benjamin Herrenschmidt 
> 
> This adds a devfn_max field to PCIBus and adds a pci_can_add_device()
> function which, if no "addr" (aka devfn) is specified, will tell whether
> there is any slot free between devfn_min and devfn_max.
> 
> When devfn_max is 0 (default), it will be ignored (no constraints).
> 
> This will be used by some PCI root complex implementations that support
> only one direct child to avoid having qemu put dumb devices at different
> slot numbers.
> 
> Signed-off-by: Benjamin Herrenschmidt 
> [clg: updated for qemu-2.9 ]
> Signed-off-by: Cédric Le Goater 
> ---
>  hw/pci/pci.c | 22 ++
>  include/hw/pci/pci_bus.h |  1 +
>  2 files changed, 23 insertions(+)
> 
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index 259483b1c01a..817ad14ed987 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -143,6 +143,27 @@ static uint16_t pcibus_numa_node(PCIBus *bus)
>  return NUMA_NODE_UNASSIGNED;
>  }
>  
> +static bool pci_can_add_device(BusState *bus, QemuOpts *opts)
> +{
> +unsigned int devfn, max;
> +PCIBus *pbus = PCI_BUS(bus);
> +
> +/* If address is specified, say yes and let it fail if that doesn't work 
> */
> +if (qemu_opt_get(opts, "addr") != NULL) {

Ah, so these are options for the device to add, not for the bus.  I'm
not entirely sure that device options are standardized enough to do
this safely.

Could you use an initialized, but not realized, device pointer instead?


> +return true;
> +}
> +max = ARRAY_SIZE(pbus->devices);
> +if (pbus->devfn_max && pbus->devfn_max < max) {
> +max = pbus->devfn_max;
> +}
> +for (devfn = pbus->devfn_min ; devfn < max; devfn += PCI_FUNC_MAX) {
> +if (!pbus->devices[devfn]) {
> +break;
> +}
> +}
> +return devfn < max;
> +}
> +
>  static void pci_bus_class_init(ObjectClass *klass, void *data)
>  {
>  BusClass *k = BUS_CLASS(klass);
> @@ -154,6 +175,7 @@ static void pci_bus_class_init(ObjectClass *klass, void 
> *data)
>  k->realize = pci_bus_realize;
>  k->unrealize = pci_bus_unrealize;
>  k->reset = pcibus_reset;
> +k->can_add_device = pci_can_add_device;
>  
>  pbc->is_root = pcibus_is_root;
>  pbc->bus_num = pcibus_num;
> diff --git a/include/hw/pci/pci_bus.h b/include/hw/pci/pci_bus.h
> index 5484a9b5c573..05c9dd22a8fa 100644
> --- a/include/hw/pci/pci_bus.h
> +++ b/include/hw/pci/pci_bus.h
> @@ -23,6 +23,7 @@ struct PCIBus {
>  PCIIOMMUFunc iommu_fn;
>  void *iommu_opaque;
>  uint8_t devfn_min;
> +uint8_t devfn_max;
>  pci_set_irq_fn set_irq;
>  pci_map_irq_fn map_irq;
>  pci_route_irq_fn route_intx_to_irq;

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 12/21] ppc/pnv: populate device tree for RTC devices

[David Gibson]

On Wed, Apr 05, 2017 at 02:41:37PM +0200, Cédric Le Goater wrote:
> The code could be common to any ISA device but we are missing the IO
> length.
> 
> Signed-off-by: Cédric Le Goater 

Reviewed-by: David Gibson 

> ---
>  hw/ppc/pnv.c | 30 ++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index a3c8f6594d10..2f9c41e350d4 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -281,6 +281,26 @@ static void powernv_populate_chip(PnvChip *chip, void 
> *fdt)
>  g_free(typename);
>  }
>  
> +static void powernv_populate_rtc(ISADevice *d, void *fdt, int lpc_off)
> +{
> +uint32_t io_base = d->ioport_id;
> +uint32_t io_regs[] = {
> +cpu_to_be32(1),
> +cpu_to_be32(io_base),
> +cpu_to_be32(2)
> +};
> +char *name;
> +int node;
> +
> +name = g_strdup_printf("%s@i%x", qdev_fw_name(DEVICE(d)), io_base);
> +node = fdt_add_subnode(fdt, lpc_off, name);
> +_FDT(node);
> +g_free(name);
> +
> +_FDT((fdt_setprop(fdt, node, "reg", io_regs, sizeof(io_regs;
> +_FDT((fdt_setprop_string(fdt, node, "compatible", "pnpPNP,b00")));
> +}
> +
>  typedef struct ForeachPopulateArgs {
>  void *fdt;
>  int offset;
> @@ -288,6 +308,16 @@ typedef struct ForeachPopulateArgs {
>  
>  static int powernv_populate_isa_device(DeviceState *dev, void *opaque)
>  {
> +ForeachPopulateArgs *args = opaque;
> +ISADevice *d = ISA_DEVICE(dev);
> +
> +if (object_dynamic_cast(OBJECT(dev), TYPE_MC146818_RTC)) {
> +powernv_populate_rtc(d, args->fdt, args->offset);
> +} else {
> +error_report("unknown isa device %s@i%x", qdev_fw_name(dev),
> + d->ioport_id);
> +}
> +
>  return 0;
>  }
>  

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 11/21] ppc/pnv: scan ISA bus to populate device tree

[David Gibson]

On Wed, Apr 05, 2017 at 02:41:36PM +0200, Cédric Le Goater wrote:
> This is an empty shell that we will use to include nodes in the device
> tree for ISA devices. We expect RTC, UART and IPMI BT devices.
> 
> Signed-off-by: Cédric Le Goater 

This is so simple, I'd probably fold it into the next patch.  But
apart from that.

Reviewed-by: David Gibson 

> ---
>  hw/ppc/pnv.c | 32 
>  1 file changed, 32 insertions(+)
> 
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index 493c7eed7980..a3c8f6594d10 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -281,6 +281,36 @@ static void powernv_populate_chip(PnvChip *chip, void 
> *fdt)
>  g_free(typename);
>  }
>  
> +typedef struct ForeachPopulateArgs {
> +void *fdt;
> +int offset;
> +} ForeachPopulateArgs;
> +
> +static int powernv_populate_isa_device(DeviceState *dev, void *opaque)
> +{
> +return 0;
> +}
> +
> +static void powernv_populate_isa(ISABus *bus, void *fdt)
> +{
> +int lpc_offset;
> +ForeachPopulateArgs args;
> +
> +lpc_offset = fdt_node_offset_by_compatible(fdt, -1, "ibm,lpc");
> +if (lpc_offset < 0) {
> +error_report("Could find the lpc node !?");
> +return;
> +}
> +
> +args.fdt = fdt;
> +args.offset = lpc_offset;
> +
> +/* ISA devices are not necessarily parented to the ISA bus so we
> + * can not use object_child_foreach() */
> +qbus_walk_children(BUS(bus), powernv_populate_isa_device,
> +   NULL, NULL, NULL, );
> +}
> +
>  static void *powernv_create_fdt(MachineState *machine)
>  {
>  const char plat_compat[] = "qemu,powernv\0ibm,powernv";
> @@ -328,6 +358,8 @@ static void *powernv_create_fdt(MachineState *machine)
>  for (i = 0; i < pnv->num_chips; i++) {
>  powernv_populate_chip(pnv->chips[i], fdt);
>  }
> +
> +powernv_populate_isa(pnv->isa_bus, fdt);
>  return fdt;
>  }
>  

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 13/21] ppc/pnv: populate device tree for serial devices

[David Gibson]

On Wed, Apr 05, 2017 at 02:41:38PM +0200, Cédric Le Goater wrote:
> Signed-off-by: Cédric Le Goater 

Reviewed-by: David Gibson 

> ---
>  hw/ppc/pnv.c | 33 +
>  1 file changed, 33 insertions(+)
> 
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index 2f9c41e350d4..00e594a0cbe3 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -301,6 +301,37 @@ static void powernv_populate_rtc(ISADevice *d, void 
> *fdt, int lpc_off)
>  _FDT((fdt_setprop_string(fdt, node, "compatible", "pnpPNP,b00")));
>  }
>  
> +static void powernv_populate_serial(ISADevice *d, void *fdt, int lpc_off)
> +{
> +const char compatible[] = "ns16550\0pnpPNP,501";
> +uint32_t io_base = d->ioport_id;
> +uint32_t io_regs[] = {
> +cpu_to_be32(1),
> +cpu_to_be32(io_base),
> +cpu_to_be32(8)
> +};
> +char *name;
> +int node;
> +
> +name = g_strdup_printf("%s@i%x", qdev_fw_name(DEVICE(d)), io_base);
> +node = fdt_add_subnode(fdt, lpc_off, name);
> +_FDT(node);
> +g_free(name);
> +
> +_FDT((fdt_setprop(fdt, node, "reg", io_regs, sizeof(io_regs;
> +_FDT((fdt_setprop(fdt, node, "compatible", compatible,
> +  sizeof(compatible;
> +
> +_FDT((fdt_setprop_cell(fdt, node, "clock-frequency", 1843200)));
> +_FDT((fdt_setprop_cell(fdt, node, "current-speed", 115200)));
> +_FDT((fdt_setprop_cell(fdt, node, "interrupts", d->isairq[0])));
> +_FDT((fdt_setprop_cell(fdt, node, "interrupt-parent",
> +   fdt_get_phandle(fdt, lpc_off;
> +
> +/* This is needed by Linux */
> +_FDT((fdt_setprop_string(fdt, node, "device_type", "serial")));
> +}
> +
>  typedef struct ForeachPopulateArgs {
>  void *fdt;
>  int offset;
> @@ -313,6 +344,8 @@ static int powernv_populate_isa_device(DeviceState *dev, 
> void *opaque)
>  
>  if (object_dynamic_cast(OBJECT(dev), TYPE_MC146818_RTC)) {
>  powernv_populate_rtc(d, args->fdt, args->offset);
> +} else if (object_dynamic_cast(OBJECT(dev), TYPE_ISA_SERIAL)) {
> +powernv_populate_serial(d, args->fdt, args->offset);
>  } else {
>  error_report("unknown isa device %s@i%x", qdev_fw_name(dev),
>   d->ioport_id);

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


signature.asc
Description: PGP signature

[Qemu-devel] [Bug 1662050] Re: qemu-img convert a overlay qcow2 image into a entire image

[wayen]

Hi Lidong Chen:
I used QEMU 2.0.0 on Ubuntu 14.04.
Do you mean your patch can make qemu-img convert qcow2 overlay into a new 
overlay?

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

Title:
  qemu-img convert a overlay qcow2 image into a entire image

Status in QEMU:
  Incomplete

Bug description:
  I have a base image file "base.qcow2" and a delta qcow2 image file
  "delta.qcow2" whose backing file is "base.qcow2".

  Now I use qemu-img to convert "delta.qcow2" and will get a new image
  file "new.qcow2" which is entire and equivalent to combination of
  "base.qcow2" and "delta.qcow2".

  In fact,I don't want to get a complete image.I just want to convert
  delta qcow2 image file "A" to a New delta overlay qcow2 image "B"
  which is equivalent to "A". So the "new.qcow2" is not what i want. I
  have to admit that this is not bug. Could you please take this as a
  new feature and enable qemu-img to convert qcow2 overlay itself?

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1662050/+subscriptions

Re: [Qemu-devel] [PATCH v9 1/9] memory: add section range info for IOMMU notifier

[David Gibson]

On Fri, Apr 07, 2017 at 06:59:07PM +0800, Peter Xu wrote:
> In this patch, IOMMUNotifier.{start|end} are introduced to store section
> information for a specific notifier. When notification occurs, we not
> only check the notification type (MAP|UNMAP), but also check whether the
> notified iova range overlaps with the range of specific IOMMU notifier,
> and skip those notifiers if not in the listened range.
> 
> When removing an region, we need to make sure we removed the correct
> VFIOGuestIOMMU by checking the IOMMUNotifier.start address as well.
> 
> This patch is solving the problem that vfio-pci devices receive
> duplicated UNMAP notification on x86 platform when vIOMMU is there. The
> issue is that x86 IOMMU has a (0, 2^64-1) IOMMU region, which is
> splitted by the (0xfee0, 0xfeef) IRQ region. AFAIK
> this (splitted IOMMU region) is only happening on x86.
> 
> This patch also helps vhost to leverage the new interface as well, so
> that vhost won't get duplicated cache flushes. In that sense, it's an
> slight performance improvement.
> 
> Suggested-by: David Gibson 
> Reviewed-by: Eric Auger 
> Reviewed-by: Michael S. Tsirkin 
> Acked-by: Alex Williamson 
> Signed-off-by: Peter Xu 
> ---
>  hw/vfio/common.c  | 12 +---
>  hw/virtio/vhost.c | 10 --
>  include/exec/memory.h | 19 ++-
>  memory.c  |  9 +
>  4 files changed, 44 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index f3ba9b9..6b33b9f 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -478,8 +478,13 @@ static void vfio_listener_region_add(MemoryListener 
> *listener,
>  giommu->iommu_offset = section->offset_within_address_space -
> section->offset_within_region;
>  giommu->container = container;
> -giommu->n.notify = vfio_iommu_map_notify;
> -giommu->n.notifier_flags = IOMMU_NOTIFIER_ALL;
> +llend = int128_add(int128_make64(section->offset_within_region),
> +   section->size);
> +llend = int128_sub(llend, int128_one());
> +iommu_notifier_init(>n, vfio_iommu_map_notify,
> +IOMMU_NOTIFIER_ALL,
> +section->offset_within_region,
> +int128_get64(llend));

Seems to me it would make sense to put the fiddling around to convert
the MemoryRegionSection into the necessary values would make sense to
go inside iommu_notifier_init().

>  QLIST_INSERT_HEAD(>giommu_list, giommu, giommu_next);
>  
>  memory_region_register_iommu_notifier(giommu->iommu, >n);
> @@ -550,7 +555,8 @@ static void vfio_listener_region_del(MemoryListener 
> *listener,
>  VFIOGuestIOMMU *giommu;
>  
>  QLIST_FOREACH(giommu, >giommu_list, giommu_next) {
> -if (giommu->iommu == section->mr) {
> +if (giommu->iommu == section->mr &&
> +giommu->n.start == section->offset_within_region) {

This test should be sufficient, but I'd be a bit more comfortable if
there was a test and assert() that the end matches as well.  I also
wonder if remove-matching-notifier helper would be useful here.
Although vhost doesn't appear to ever remove, so maybe it's premature.

>  memory_region_unregister_iommu_notifier(giommu->iommu,
>  >n);
>  QLIST_REMOVE(giommu, giommu_next);
> diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
> index 613494d..185b95b 100644
> --- a/hw/virtio/vhost.c
> +++ b/hw/virtio/vhost.c
> @@ -736,14 +736,20 @@ static void vhost_iommu_region_add(MemoryListener 
> *listener,
>  struct vhost_dev *dev = container_of(listener, struct vhost_dev,
>   iommu_listener);
>  struct vhost_iommu *iommu;
> +Int128 end;
>  
>  if (!memory_region_is_iommu(section->mr)) {
>  return;
>  }
>  
>  iommu = g_malloc0(sizeof(*iommu));
> -iommu->n.notify = vhost_iommu_unmap_notify;
> -iommu->n.notifier_flags = IOMMU_NOTIFIER_UNMAP;
> +end = int128_add(int128_make64(section->offset_within_region),
> + section->size);
> +end = int128_sub(end, int128_one());
> +iommu_notifier_init(>n, vhost_iommu_unmap_notify,
> +IOMMU_NOTIFIER_UNMAP,
> +section->offset_within_region,
> +int128_get64(end));
>  iommu->mr = section->mr;
>  iommu->iommu_offset = section->offset_within_address_space -
>section->offset_within_region;
> diff --git a/include/exec/memory.h b/include/exec/memory.h
> index f20b191..0840c89 100644
> --- a/include/exec/memory.h
> +++ b/include/exec/memory.h
> @@ -77,13 +77,30 @@ typedef enum {
>  
>  #define 

Re: [Qemu-devel] [Bug 1662050] Re: qemu-img convert a overlay qcow2 image into a entire image

[858585 jemmy]

Hi wayen:
Which version are you used?
I also find this problem on old version qemu, and i write a patch
for it. It works.
I'm not sure the mainline version have solve this problem.
what command are you used?

On Mon, Apr 10, 2017 at 10:14 AM, wayen <1662...@bugs.launchpad.net> wrote:
> Is there any way to remove holes from qcow2 overlay images? It's very
> important to me. I am looking forward to your reply.
>
> --
> You received this bug notification because you are a member of qemu-
> devel-ml, which is subscribed to QEMU.
> https://bugs.launchpad.net/bugs/1662050
>
> Title:
>   qemu-img convert a overlay qcow2 image into a entire image
>
> Status in QEMU:
>   Incomplete
>
> Bug description:
>   I have a base image file "base.qcow2" and a delta qcow2 image file
>   "delta.qcow2" whose backing file is "base.qcow2".
>
>   Now I use qemu-img to convert "delta.qcow2" and will get a new image
>   file "new.qcow2" which is entire and equivalent to combination of
>   "base.qcow2" and "delta.qcow2".
>
>   In fact,I don't want to get a complete image.I just want to convert
>   delta qcow2 image file "A" to a New delta overlay qcow2 image "B"
>   which is equivalent to "A". So the "new.qcow2" is not what i want. I
>   have to admit that this is not bug. Could you please take this as a
>   new feature and enable qemu-img to convert qcow2 overlay itself?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1662050/+subscriptions
>

[Qemu-devel] 答复: 转发: Re: [PATCH] vhost: skip RAM device memory sections

[lu.zhipeng]

i have been tested many times,i confirm ram device region  references is not be 
dropped,when detaching vhost net.


So far ，i do not  have  better idea to drop the references.  the ram device 
momery is special .


i think vhost listening the RAM devicemomery is not necessary. skip RAM device 
memory sections



















芦志朋 luzhipeng






IT开发工程师 IT Development
Engineer
操作系统产品部/中心研究院/系统产品 OS Product Dept./Central R＆D Institute/System Product









四川省成都市天府大道中段800号
E: lu.zhip...@zte.com.cn 
www.zte.com.cn






原始邮件



发件人：王广10165992
收件人：芦志朋10108272
抄送人：杨斌10080747
日 期 ：2017年04月10日 09:05
主 题 ：转发: Re: [Qemu-devel] [PATCH] vhost: skip RAM device memory sections


























发件人： ＜m...@redhat.com＞
收件人：芦志朋10108272
抄送人： ＜qemu-devel@nongnu.org＞王广10165992
日 期 ：2017年04月07日 23:52
主 题 ：Re: [Qemu-devel] [PATCH] vhost: skip RAM device memory sections





On Sat, Apr 08, 2017 at 09:24:10AM +0800, ZhiPeng Lu wrote:
＞ A RAM device represents a mapping to a physical device, such as to a PCI
＞ * MMIO BAR of an vfio-pci assigned device.
＞ Vhost listens to this region,and increases the region's reference count
＞ while passthrough?for?network adapters (Physical Function, PF or Virtual 
Function, VF).
＞ After detaching   network adapters with  vhost backend dirver or vhost user 
dirver,
＞ it unregister vhost listen function  by memory_listener_unregister.

Shouldn't that drop all references? That might be a cleaner fix.

＞ After detaching the passthrough pf  or vf,
＞ the RAM device region's reference by  vhost listener increated can not be 
released,
＞ due to vhost listen function does not exist.So let's just skip RAM device 
memory.
＞ 
＞ Signed-off-by: ZhiPeng Lu ＜lu.zhip...@zte.com.cn＞
＞ ---
＞  hw/virtio/vhost.c | 3 ++-
＞  1 file changed, 2 insertions(+), 1 deletion(-)
＞ 
＞ diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
＞ index 613494d..c1ff98f 100644
＞ --- a/hw/virtio/vhost.c
＞ +++ b/hw/virtio/vhost.c
＞ @@ -611,7 +611,8 @@ static void vhost_set_memory(MemoryListener *listener,
＞  static bool vhost_section(MemoryRegionSection *section)
＞  {
＞  return memory_region_is_ram(section-＞mr) &&
＞ -!memory_region_is_rom(section-＞mr)
＞ +!memory_region_is_rom(section-＞mr) &&
＞ +!memory_region_is_skip_dump(section-＞mr)
＞  }
＞  
＞  static void vhost_begin(MemoryListener *listener)
＞ -- 
＞ 1.8.3.1
＞

[Qemu-devel] [PATCH v3 1/2] block: Make bdrv_parent_drained_begin/end public

[Fam Zheng]

Signed-off-by: Fam Zheng 
---
 block/io.c|  4 ++--
 include/block/block.h | 16 
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/block/io.c b/block/io.c
index 7321dda..9598646 100644
--- a/block/io.c
+++ b/block/io.c
@@ -44,7 +44,7 @@ static void coroutine_fn bdrv_co_do_rw(void *opaque);
 static int coroutine_fn bdrv_co_do_pwrite_zeroes(BlockDriverState *bs,
 int64_t offset, int count, BdrvRequestFlags flags);
 
-static void bdrv_parent_drained_begin(BlockDriverState *bs)
+void bdrv_parent_drained_begin(BlockDriverState *bs)
 {
 BdrvChild *c;
 
@@ -55,7 +55,7 @@ static void bdrv_parent_drained_begin(BlockDriverState *bs)
 }
 }
 
-static void bdrv_parent_drained_end(BlockDriverState *bs)
+void bdrv_parent_drained_end(BlockDriverState *bs)
 {
 BdrvChild *c;
 
diff --git a/include/block/block.h b/include/block/block.h
index 3e09222..488a07e 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -573,6 +573,22 @@ void bdrv_io_plug(BlockDriverState *bs);
 void bdrv_io_unplug(BlockDriverState *bs);
 
 /**
+ * bdrv_parent_drained_begin:
+ *
+ * Begin a quiesced section of all users of @bs. This is part of
+ * bdrv_drained_begin.
+ */
+void bdrv_parent_drained_begin(BlockDriverState *bs);
+
+/**
+ * bdrv_parent_drained_end:
+ *
+ * End a quiesced section of all users of @bs. This is part of
+ * bdrv_drained_end.
+ */
+void bdrv_parent_drained_end(BlockDriverState *bs);
+
+/**
  * bdrv_drained_begin:
  *
  * Begin a quiesced section for exclusive access to the BDS, by disabling
-- 
2.9.3

[Qemu-devel] [Bug 1662050] Re: qemu-img convert a overlay qcow2 image into a entire image

[wayen]

Is there any way to remove holes from qcow2 overlay images? It's very
important to me. I am looking forward to your reply.

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

Title:
  qemu-img convert a overlay qcow2 image into a entire image

Status in QEMU:
  Incomplete

Bug description:
  I have a base image file "base.qcow2" and a delta qcow2 image file
  "delta.qcow2" whose backing file is "base.qcow2".

  Now I use qemu-img to convert "delta.qcow2" and will get a new image
  file "new.qcow2" which is entire and equivalent to combination of
  "base.qcow2" and "delta.qcow2".

  In fact,I don't want to get a complete image.I just want to convert
  delta qcow2 image file "A" to a New delta overlay qcow2 image "B"
  which is equivalent to "A". So the "new.qcow2" is not what i want. I
  have to admit that this is not bug. Could you please take this as a
  new feature and enable qemu-img to convert qcow2 overlay itself?

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1662050/+subscriptions

[Qemu-devel] [PATCH v3 2/2] block: Quiesce old aio context during bdrv_set_aio_context

[Fam Zheng]

The fact that the bs->aio_context is changing can confuse the dataplane
iothread, because of the now fine granularity aio context lock.
bdrv_drain should rather be a bdrv_drained_begin/end pair, but since
bs->aio_context is changing, we can just use aio_disable_external and
bdrv_parent_drained_begin.

Reported-by: Ed Swierk 
Signed-off-by: Fam Zheng 
---
 block.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/block.c b/block.c
index b8a3011..a995a8e 100644
--- a/block.c
+++ b/block.c
@@ -4396,11 +4396,12 @@ void bdrv_attach_aio_context(BlockDriverState *bs,
 
 void bdrv_set_aio_context(BlockDriverState *bs, AioContext *new_context)
 {
-AioContext *ctx;
+AioContext *ctx = bdrv_get_aio_context(bs);
 
+aio_disable_external(ctx);
+bdrv_parent_drained_begin(bs);
 bdrv_drain(bs); /* ensure there are no in-flight requests */
 
-ctx = bdrv_get_aio_context(bs);
 while (aio_poll(ctx, false)) {
 /* wait for all bottom halves to execute */
 }
@@ -4412,6 +4413,8 @@ void bdrv_set_aio_context(BlockDriverState *bs, 
AioContext *new_context)
  */
 aio_context_acquire(new_context);
 bdrv_attach_aio_context(bs, new_context);
+bdrv_parent_drained_end(bs);
+aio_enable_external(ctx);
 aio_context_release(new_context);
 }
 
-- 
2.9.3

[Qemu-devel] [PATCH v3 0/2] block: Quiesce old aio context during bdrv_set_aio_context

[Fam Zheng]

v3: Use bdrv_parent_drained_begin/end. [Kevin]
Do it before releasing new_context. [Stefan]

Fam Zheng (2):
  block: Make bdrv_parent_drained_begin/end public
  block: Quiesce old aio context during bdrv_set_aio_context

 block.c   |  7 +--
 block/io.c|  4 ++--
 include/block/block.h | 16 
 3 files changed, 23 insertions(+), 4 deletions(-)

-- 
2.9.3

[Qemu-devel] [Bug 1662050] Re: qemu-img convert a overlay qcow2 image into a entire image

[wayen]

Is there any way to remove holes from sparse qcow2 overlay? It's very
important to me. I am looking forward to your reply.

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

Title:
  qemu-img convert a overlay qcow2 image into a entire image

Status in QEMU:
  Incomplete

Bug description:
  I have a base image file "base.qcow2" and a delta qcow2 image file
  "delta.qcow2" whose backing file is "base.qcow2".

  Now I use qemu-img to convert "delta.qcow2" and will get a new image
  file "new.qcow2" which is entire and equivalent to combination of
  "base.qcow2" and "delta.qcow2".

  In fact,I don't want to get a complete image.I just want to convert
  delta qcow2 image file "A" to a New delta overlay qcow2 image "B"
  which is equivalent to "A". So the "new.qcow2" is not what i want. I
  have to admit that this is not bug. Could you please take this as a
  new feature and enable qemu-img to convert qcow2 overlay itself?

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1662050/+subscriptions

Re: [Qemu-devel] [PATCH v2] migration/block: use blk_pwrite_zeroes for each zero cluster

[858585 jemmy]

On Mon, Apr 10, 2017 at 9:47 AM, Fam Zheng  wrote:
> On Sat, 04/08 21:29, 858585 jemmy wrote:
>> On Sat, Apr 8, 2017 at 12:52 PM, 858585 jemmy  wrote:
>> > On Fri, Apr 7, 2017 at 6:10 PM, Fam Zheng  wrote:
>> >> On Fri, 04/07 16:44, jemmy858...@gmail.com wrote:
>> >>> From: Lidong Chen 
>> >>>
>> >>> BLOCK_SIZE is (1 << 20), qcow2 cluster size is 65536 by default,
>> >>> this maybe cause the qcow2 file size is bigger after migration.
>> >>> This patch check each cluster, use blk_pwrite_zeroes for each
>> >>> zero cluster.
>> >>>
>> >>> Signed-off-by: Lidong Chen 
>> >>> ---
>> >>>  migration/block.c | 37 +++--
>> >>>  1 file changed, 35 insertions(+), 2 deletions(-)
>> >>>
>> >>> diff --git a/migration/block.c b/migration/block.c
>> >>> index 7734ff7..c32e046 100644
>> >>> --- a/migration/block.c
>> >>> +++ b/migration/block.c
>> >>> @@ -885,6 +885,11 @@ static int block_load(QEMUFile *f, void *opaque, 
>> >>> int version_id)
>> >>>  int64_t total_sectors = 0;
>> >>>  int nr_sectors;
>> >>>  int ret;
>> >>> +int i;
>> >>> +int64_t addr_offset;
>> >>> +uint8_t *buf_offset;
>> >>
>> >> Poor variable names, they are not offset, maybe "cur_addr" and "cur_buf"? 
>> >> And
>> >> they can be moved to the loop block below.
>> > ok, i will change.
>> >
>> >>
>> >>> +BlockDriverInfo bdi;
>> >>> +int cluster_size;
>> >>>
>> >>>  do {
>> >>>  addr = qemu_get_be64(f);
>> >>> @@ -934,8 +939,36 @@ static int block_load(QEMUFile *f, void *opaque, 
>> >>> int version_id)
>> >>>  } else {
>> >>>  buf = g_malloc(BLOCK_SIZE);
>> >>>  qemu_get_buffer(f, buf, BLOCK_SIZE);
>> >>> -ret = blk_pwrite(blk, addr * BDRV_SECTOR_SIZE, buf,
>> >>> - nr_sectors * BDRV_SECTOR_SIZE, 0);
>> >>> +
>> >>> +ret = bdrv_get_info(blk_bs(blk), );
>> >>> +cluster_size = bdi.cluster_size;
>> >>> +
>> >>> +if (ret == 0 && cluster_size > 0 &&
>> >>> +cluster_size < BLOCK_SIZE &&
>> >>
>> >> I think cluster_size == BLOCK_SIZE should work too.
>> > This case the (flags & BLK_MIG_FLAG_ZERO_BLOCK) should be true,
>> > and will invoke blk_pwrite_zeroes before apply this patch.
>> > but maybe the source qemu maybe not enabled zero flag.
>> > so i think cluster_size <= BLOCK_SIZE is ok.
>> >
>> >>
>> >>> +BLOCK_SIZE % cluster_size == 0) {
>> >>> +for (i = 0; i < BLOCK_SIZE / cluster_size; i++) {
>> >>> +addr_offset = addr * BDRV_SECTOR_SIZE
>> >>> ++ i * cluster_size;
>> >>> +buf_offset = buf + i * cluster_size;
>> >>> +
>> >>> +if (buffer_is_zero(buf_offset, cluster_size)) {
>> >>> +ret = blk_pwrite_zeroes(blk, addr_offset,
>> >>> +cluster_size,
>> >>> +BDRV_REQ_MAY_UNMAP);
>> >>> +} else {
>> >>> + ret = blk_pwrite(blk, addr_offset, 
>> >>> buf_offset,
>> >>> +  cluster_size, 0);
>> >>> +}
>> >>> +
>> >>> +if (ret < 0) {
>> >>> +g_free(buf);
>> >>> +return ret;
>> >>> +}
>> >>> +}
>> >>> +} else {
>> >>> +ret = blk_pwrite(blk, addr * BDRV_SECTOR_SIZE, buf,
>> >>> + nr_sectors * BDRV_SECTOR_SIZE, 0);
>> >>> +}
>> >>>  g_free(buf);
>> >>>  }
>> >>>
>> >>> --
>> >>> 1.8.3.1
>> >>>
>> >>
>> >> Is it possible use (source) cluster size as the transfer chunk size, 
>> >> instead of
>> >> BDRV_SECTORS_PER_DIRTY_CHUNK? Then the existing BLK_MIG_FLAG_ZERO_BLOCK 
>> >> logic
>> >> can help and you don't need to send zero bytes on the wire. This may 
>> >> still not
>> >> be optimal if dest has larger cluster, but it should cover the common use 
>> >> case
>> >> well.
>> >
>> > yes, i also think BDRV_SECTORS_PER_DIRTY_CHUNK is too large.
>> > This have two disadvantage:
>> > 1. it will cause the dest qcow2 file size is bigger after migration.
>> > 2. it will cause transfer not necessary data, and maybe cause the
>> > migration can't be successful.
>> >
>> > in my production environment, some vm only write 2MB/s, the dirty
>> > block migrate speed is 70MB/s.
>> > but it still migration timeout.
>> >
>> > but if we change the size of BDRV_SECTORS_PER_DIRTY_CHUNK, it will
>> > break the protocol.
>> > the old version qemu will not be able to migrate to new version qemu.
>> > there are not information 

[Qemu-devel] 答复: 转发: Re: [PATCH] vhost: skip RAM device memory sections

[lu.zhipeng]

i'm sorry ，it should be memory_region_is_ram_device in  new  version qemu , 
memory_region_is_skip_dump is in older version qemu.













芦志朋 luzhipeng






IT开发工程师 IT Development
Engineer
操作系统产品部/中心研究院/系统产品 OS Product Dept./Central R＆D Institute/System Product









四川省成都市天府大道中段800号
E: lu.zhip...@zte.com.cn 
www.zte.com.cn






原始邮件



发件人：王广10165992
收件人：芦志朋10108272
抄送人：杨斌10080747
日 期 ：2017年04月10日 09:05
主 题 ：转发: Re: [Qemu-devel] [PATCH] vhost: skip RAM device memory sections





























发件人： ＜pbonz...@redhat.com＞
收件人：王广10165992 ＜m...@redhat.com＞
抄送人：芦志朋10108272 ＜qemu-devel@nongnu.org＞
日 期 ：2017年04月08日 01:24
主 题 ：Re: [Qemu-devel] [PATCH] vhost: skip RAM device memory sections







On 08/04/2017 09:16, Wang guang wrote:
＞ From: ZhiPeng Lu ＜lu.zhip...@zte.com.cn＞
＞ 
＞ A RAM device represents a mapping to a physical device, such as to a PCI
＞ * MMIO BAR of an vfio-pci assigned device.
＞ Vhost listens to this region,and increases the region's reference count
＞ while passthrough?for?network adapters (Physical Function, PF or Virtual 
Function, VF).
＞ After detaching   network adapters with  vhost backend dirver or vhost user 
dirver,
＞ it unregister vhost listen function  by memory_listener_unregister.
＞ After detaching the passthrough pf  or vf,
＞ the RAM device region's reference by  vhost listener increated can not be 
released,
＞ due to vhost listen function does not exist.So let's just skip RAM device 
memory.
＞ 
＞ Signed-off-by: ZhiPeng Lu ＜lu.zhip...@zte.com.cn＞
＞ ---
＞  hw/virtio/vhost.c | 3 ++-
＞  1 file changed, 2 insertions(+), 1 deletion(-)
＞ 
＞ diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
＞ index 613494d..c1ff98f 100644
＞ --- a/hw/virtio/vhost.c
＞ +++ b/hw/virtio/vhost.c
＞ @@ -611,7 +611,8 @@ static void vhost_set_memory(MemoryListener *listener,
＞  static bool vhost_section(MemoryRegionSection *section)
＞  {
＞  return memory_region_is_ram(section-＞mr) &&
＞ -!memory_region_is_rom(section-＞mr)
＞ +!memory_region_is_rom(section-＞mr) &&
＞ +!memory_region_is_skip_dump(section-＞mr)
＞  }

Why not memory_region_is_ram_device?

Paolo

Re: [Qemu-devel] [PATCH v2] migration/block: use blk_pwrite_zeroes for each zero cluster

[Fam Zheng]

On Sat, 04/08 21:29, 858585 jemmy wrote:
> On Sat, Apr 8, 2017 at 12:52 PM, 858585 jemmy  wrote:
> > On Fri, Apr 7, 2017 at 6:10 PM, Fam Zheng  wrote:
> >> On Fri, 04/07 16:44, jemmy858...@gmail.com wrote:
> >>> From: Lidong Chen 
> >>>
> >>> BLOCK_SIZE is (1 << 20), qcow2 cluster size is 65536 by default,
> >>> this maybe cause the qcow2 file size is bigger after migration.
> >>> This patch check each cluster, use blk_pwrite_zeroes for each
> >>> zero cluster.
> >>>
> >>> Signed-off-by: Lidong Chen 
> >>> ---
> >>>  migration/block.c | 37 +++--
> >>>  1 file changed, 35 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/migration/block.c b/migration/block.c
> >>> index 7734ff7..c32e046 100644
> >>> --- a/migration/block.c
> >>> +++ b/migration/block.c
> >>> @@ -885,6 +885,11 @@ static int block_load(QEMUFile *f, void *opaque, int 
> >>> version_id)
> >>>  int64_t total_sectors = 0;
> >>>  int nr_sectors;
> >>>  int ret;
> >>> +int i;
> >>> +int64_t addr_offset;
> >>> +uint8_t *buf_offset;
> >>
> >> Poor variable names, they are not offset, maybe "cur_addr" and "cur_buf"? 
> >> And
> >> they can be moved to the loop block below.
> > ok, i will change.
> >
> >>
> >>> +BlockDriverInfo bdi;
> >>> +int cluster_size;
> >>>
> >>>  do {
> >>>  addr = qemu_get_be64(f);
> >>> @@ -934,8 +939,36 @@ static int block_load(QEMUFile *f, void *opaque, int 
> >>> version_id)
> >>>  } else {
> >>>  buf = g_malloc(BLOCK_SIZE);
> >>>  qemu_get_buffer(f, buf, BLOCK_SIZE);
> >>> -ret = blk_pwrite(blk, addr * BDRV_SECTOR_SIZE, buf,
> >>> - nr_sectors * BDRV_SECTOR_SIZE, 0);
> >>> +
> >>> +ret = bdrv_get_info(blk_bs(blk), );
> >>> +cluster_size = bdi.cluster_size;
> >>> +
> >>> +if (ret == 0 && cluster_size > 0 &&
> >>> +cluster_size < BLOCK_SIZE &&
> >>
> >> I think cluster_size == BLOCK_SIZE should work too.
> > This case the (flags & BLK_MIG_FLAG_ZERO_BLOCK) should be true,
> > and will invoke blk_pwrite_zeroes before apply this patch.
> > but maybe the source qemu maybe not enabled zero flag.
> > so i think cluster_size <= BLOCK_SIZE is ok.
> >
> >>
> >>> +BLOCK_SIZE % cluster_size == 0) {
> >>> +for (i = 0; i < BLOCK_SIZE / cluster_size; i++) {
> >>> +addr_offset = addr * BDRV_SECTOR_SIZE
> >>> ++ i * cluster_size;
> >>> +buf_offset = buf + i * cluster_size;
> >>> +
> >>> +if (buffer_is_zero(buf_offset, cluster_size)) {
> >>> +ret = blk_pwrite_zeroes(blk, addr_offset,
> >>> +cluster_size,
> >>> +BDRV_REQ_MAY_UNMAP);
> >>> +} else {
> >>> + ret = blk_pwrite(blk, addr_offset, 
> >>> buf_offset,
> >>> +  cluster_size, 0);
> >>> +}
> >>> +
> >>> +if (ret < 0) {
> >>> +g_free(buf);
> >>> +return ret;
> >>> +}
> >>> +}
> >>> +} else {
> >>> +ret = blk_pwrite(blk, addr * BDRV_SECTOR_SIZE, buf,
> >>> + nr_sectors * BDRV_SECTOR_SIZE, 0);
> >>> +}
> >>>  g_free(buf);
> >>>  }
> >>>
> >>> --
> >>> 1.8.3.1
> >>>
> >>
> >> Is it possible use (source) cluster size as the transfer chunk size, 
> >> instead of
> >> BDRV_SECTORS_PER_DIRTY_CHUNK? Then the existing BLK_MIG_FLAG_ZERO_BLOCK 
> >> logic
> >> can help and you don't need to send zero bytes on the wire. This may still 
> >> not
> >> be optimal if dest has larger cluster, but it should cover the common use 
> >> case
> >> well.
> >
> > yes, i also think BDRV_SECTORS_PER_DIRTY_CHUNK is too large.
> > This have two disadvantage:
> > 1. it will cause the dest qcow2 file size is bigger after migration.
> > 2. it will cause transfer not necessary data, and maybe cause the
> > migration can't be successful.
> >
> > in my production environment, some vm only write 2MB/s, the dirty
> > block migrate speed is 70MB/s.
> > but it still migration timeout.
> >
> > but if we change the size of BDRV_SECTORS_PER_DIRTY_CHUNK, it will
> > break the protocol.
> > the old version qemu will not be able to migrate to new version qemu.
> > there are not information about the length about the migration buffer.
> >
> > so i think we should add new flags to indicate that there are an
> > additional byte about the length
> > of migration buffer. i will 

Re: [Qemu-devel] [PATCH v3] migration/block: use blk_pwrite_zeroes for each zero cluster

[Fam Zheng]

On Mon, 04/10 09:10, 858585 jemmy wrote:
> >> +if (ret < 0) {
> >> +g_free(buf);
> >> +return ret;
> >> +}
> >
> > This if block is not necessary because...
> 
> Hi Fam:
>   It's necessary to check each cluster is written successfully.
>   if we remove this if block, it maybe ignore some error, and only check
>   the last cluster.
>   Thanks.

Yes, I missed the fact it is in the loop body. My bad. Thanks for pointint out:

Reviewed-by: Fam Zheng 

Re: [Qemu-devel] [PATCH v2 5/6] coroutine: Explicitly specify AioContext when entering coroutine

[Fam Zheng]

On Mon, 04/10 08:56, Paolo Bonzini wrote:
> 
> 
> On 07/04/2017 23:14, Kevin Wolf wrote:
> > One part of the reason is that
> > BDRV_POLL_WHILE() drops the lock since commit c9d1a561, so just calling
> > aio_context_acquire() doesn't protect you any more if there is any
> > chance that a nested function calls BDRV_POLL_WHILE().
> 
> Hi guys, sorry for the late reply.
> 
> There wasn't actually much that changed in commit c9d1a561.  Everything
> that could break was also broken before.
> 
> With commit c9d1a561 the logic is
> 
>   aio_context_acquire
>   prepare I/O
>   aio_context_release
>   poll main AioContext
>   aio_context_acquire
>   aio_poll secondary AioContext
>   complete I/O
>   <-- bdrv_wakeup
>   aio_context_acquire
>   aio_context_release
>   Sync I/O is complete
> 
> while before it was
> 
>   aio_context_acquire
>   prepare I/O
>   aio_poll secondary AioContext
>   complete I/O
>   Sync I/O is complete
> 
> The code that can run in "aio_poll secondary AioContext" is the same in
> both cases.

This is not completely true. Before this fact, a blocked aio_context_acquire()
in virtio_scsi_data_plane_handle_cmd() wouldn't be woken up during the sync I/O.
Of course the aio context pushdown (9d4566544) happened after c9d1a561, so this
is a compound consequence of the two.

Also, not polling for at least once in bdrv_drain_poll if
!bdrv_requests_pending(bs), since 997235485, made the situation a bit worse -
virtio_scsi_data_plane_handle_cmd could have returned before
bdrv_drained_begin() returns if we do the BDRV_POLL_WHILE body at least once
even if cond is false.

> The difference is that, after c9d1a561, it always runs in
> one thread which eliminates the need for RFifoLock's contention
> callbacks (and a bunch of bdrv_drain_all deadlocks that arose from the
> combination of contention callbacks and recursive locking).
> 
> The patch that introduced the bug is the one that introduced the "home
> AioContext" co->ctx for coroutines, because now you have
> 
>   aio_context_acquire
>   prepare I/O
>   aio_context_release
>   poll main AioContext
>   aio_context_acquire
>   aio_poll secondary AioContext
>   aio_co_wake
>   complete I/O
>   bdrv_wakeup
>   aio_context_acquire
>   aio_context_release
>   Sync I/O is complete
> 
> and if "complete I/O" causes anything to happen in the iothread, bad
> things happen.
> 
> I think Fam's analysis is right.  This patch will hopefully be reverted
> in 2.10, but right now it's the right thing to do.  However, I don't
> like very much adding an argument to qemu_coroutine_enter because:
> 
> 1) coroutines can be used without AioContexts (CoMutex has a dependency
> on aio_co_wake, but it is hidden behind the API and if you have a single
> AioContext you could just define aio_co_wake to be qemu_coroutine_enter).
> 
> 2) the value that is assigned to co->ctx is not the AioContext in which
> the coroutine is running.
> 
> It would be better to split aio_co_wake so that aio_co_wake is
> 
> /* Read coroutine before co->ctx.  Matches smp_wmb in
>  * qemu_coroutine_enter.
>  */
> smp_read_barrier_depends();
> ctx = atomic_read(>ctx);
> aio_co_enter(ctx, co);
> 
> and aio_co_enter is the rest of the logic.

Is aio_co_enter what solves 1) for you too? If so I can add it in v3.

Fam

> 
> Then the coroutine code always runs in the right thread, which obviously
> is thread-safe.
> 
> Paolo
> 

Re: [Qemu-devel] [PATCH v3] migration/block: use blk_pwrite_zeroes for each zero cluster

[858585 jemmy]

On Mon, Apr 10, 2017 at 8:51 AM, Fam Zheng  wrote:
> On Sun, 04/09 20:37, jemmy858...@gmail.com wrote:
>> From: Lidong Chen 
>>
>> BLOCK_SIZE is (1 << 20), qcow2 cluster size is 65536 by default,
>> this maybe cause the qcow2 file size is bigger after migration.
>> This patch check each cluster, use blk_pwrite_zeroes for each
>> zero cluster.
>>
>> Signed-off-by: Lidong Chen 
>> ---
>>  migration/block.c | 38 --
>>  1 file changed, 36 insertions(+), 2 deletions(-)
>>
>> diff --git a/migration/block.c b/migration/block.c
>> index 7734ff7..fe613db 100644
>> --- a/migration/block.c
>> +++ b/migration/block.c
>> @@ -885,6 +885,8 @@ static int block_load(QEMUFile *f, void *opaque, int 
>> version_id)
>>  int64_t total_sectors = 0;
>>  int nr_sectors;
>>  int ret;
>> +BlockDriverInfo bdi;
>> +int cluster_size;
>>
>>  do {
>>  addr = qemu_get_be64(f);
>> @@ -934,8 +936,40 @@ static int block_load(QEMUFile *f, void *opaque, int 
>> version_id)
>>  } else {
>>  buf = g_malloc(BLOCK_SIZE);
>>  qemu_get_buffer(f, buf, BLOCK_SIZE);
>> -ret = blk_pwrite(blk, addr * BDRV_SECTOR_SIZE, buf,
>> - nr_sectors * BDRV_SECTOR_SIZE, 0);
>> +
>> +ret = bdrv_get_info(blk_bs(blk), );
>> +cluster_size = bdi.cluster_size;
>> +
>> +if (ret == 0 && cluster_size > 0 &&
>> +cluster_size <= BLOCK_SIZE &&
>> +BLOCK_SIZE % cluster_size == 0) {
>> +int i;
>> +int64_t cur_addr;
>> +uint8_t *cur_buf;
>> +
>> +for (i = 0; i < BLOCK_SIZE / cluster_size; i++) {
>> +cur_addr = addr * BDRV_SECTOR_SIZE
>> ++ i * cluster_size;
>> +cur_buf = buf + i * cluster_size;
>> +
>> +if (buffer_is_zero(cur_buf, cluster_size)) {
>> +ret = blk_pwrite_zeroes(blk, cur_addr,
>> +cluster_size,
>> +BDRV_REQ_MAY_UNMAP);
>> +} else {
>> + ret = blk_pwrite(blk, cur_addr, cur_buf,
>> +  cluster_size, 0);
>> +}
>> +
>> +if (ret < 0) {
>> +g_free(buf);
>> +return ret;
>> +}
>
> This if block is not necessary because...

Hi Fam:
  It's necessary to check each cluster is written successfully.
  if we remove this if block, it maybe ignore some error, and only check
  the last cluster.
  Thanks.

>
>> +}
>> +} else {
>> +ret = blk_pwrite(blk, addr * BDRV_SECTOR_SIZE, buf,
>> + nr_sectors * BDRV_SECTOR_SIZE, 0);
>> +}
>>  g_free(buf);
> ...
>
>
> if (ret < 0) {
> return ret;
> }
>>  }
>>
>> --
>> 1.8.3.1
>>
>>
>
> If you remove that:
>
> Reviewed-by: Fam Zheng 

Re: [Qemu-devel] [PATCH v2 5/6] coroutine: Explicitly specify AioContext when entering coroutine

[Paolo Bonzini]

On 07/04/2017 23:14, Kevin Wolf wrote:
> One part of the reason is that
> BDRV_POLL_WHILE() drops the lock since commit c9d1a561, so just calling
> aio_context_acquire() doesn't protect you any more if there is any
> chance that a nested function calls BDRV_POLL_WHILE().

Hi guys, sorry for the late reply.

There wasn't actually much that changed in commit c9d1a561.  Everything
that could break was also broken before.

With commit c9d1a561 the logic is

aio_context_acquire
prepare I/O
aio_context_release
poll main AioContext
aio_context_acquire
aio_poll secondary AioContext
complete I/O
<-- bdrv_wakeup
aio_context_acquire
aio_context_release
Sync I/O is complete

while before it was

aio_context_acquire
prepare I/O
aio_poll secondary AioContext
complete I/O
Sync I/O is complete

The code that can run in "aio_poll secondary AioContext" is the same in
both cases.  The difference is that, after c9d1a561, it always runs in
one thread which eliminates the need for RFifoLock's contention
callbacks (and a bunch of bdrv_drain_all deadlocks that arose from the
combination of contention callbacks and recursive locking).

The patch that introduced the bug is the one that introduced the "home
AioContext" co->ctx for coroutines, because now you have

aio_context_acquire
prepare I/O
aio_context_release
poll main AioContext
aio_context_acquire
aio_poll secondary AioContext
aio_co_wake
complete I/O
bdrv_wakeup
aio_context_acquire
aio_context_release
Sync I/O is complete

and if "complete I/O" causes anything to happen in the iothread, bad
things happen.

I think Fam's analysis is right.  This patch will hopefully be reverted
in 2.10, but right now it's the right thing to do.  However, I don't
like very much adding an argument to qemu_coroutine_enter because:

1) coroutines can be used without AioContexts (CoMutex has a dependency
on aio_co_wake, but it is hidden behind the API and if you have a single
AioContext you could just define aio_co_wake to be qemu_coroutine_enter).

2) the value that is assigned to co->ctx is not the AioContext in which
the coroutine is running.

It would be better to split aio_co_wake so that aio_co_wake is

/* Read coroutine before co->ctx.  Matches smp_wmb in
 * qemu_coroutine_enter.
 */
smp_read_barrier_depends();
ctx = atomic_read(>ctx);
aio_co_enter(ctx, co);

and aio_co_enter is the rest of the logic.

Then the coroutine code always runs in the right thread, which obviously
is thread-safe.

Paolo

Re: [Qemu-devel] [PATCH v3] migration/block: use blk_pwrite_zeroes for each zero cluster

[Fam Zheng]

On Sun, 04/09 20:37, jemmy858...@gmail.com wrote:
> From: Lidong Chen 
> 
> BLOCK_SIZE is (1 << 20), qcow2 cluster size is 65536 by default,
> this maybe cause the qcow2 file size is bigger after migration.
> This patch check each cluster, use blk_pwrite_zeroes for each
> zero cluster.
> 
> Signed-off-by: Lidong Chen 
> ---
>  migration/block.c | 38 --
>  1 file changed, 36 insertions(+), 2 deletions(-)
> 
> diff --git a/migration/block.c b/migration/block.c
> index 7734ff7..fe613db 100644
> --- a/migration/block.c
> +++ b/migration/block.c
> @@ -885,6 +885,8 @@ static int block_load(QEMUFile *f, void *opaque, int 
> version_id)
>  int64_t total_sectors = 0;
>  int nr_sectors;
>  int ret;
> +BlockDriverInfo bdi;
> +int cluster_size;
>  
>  do {
>  addr = qemu_get_be64(f);
> @@ -934,8 +936,40 @@ static int block_load(QEMUFile *f, void *opaque, int 
> version_id)
>  } else {
>  buf = g_malloc(BLOCK_SIZE);
>  qemu_get_buffer(f, buf, BLOCK_SIZE);
> -ret = blk_pwrite(blk, addr * BDRV_SECTOR_SIZE, buf,
> - nr_sectors * BDRV_SECTOR_SIZE, 0);
> +
> +ret = bdrv_get_info(blk_bs(blk), );
> +cluster_size = bdi.cluster_size;
> +
> +if (ret == 0 && cluster_size > 0 &&
> +cluster_size <= BLOCK_SIZE &&
> +BLOCK_SIZE % cluster_size == 0) {
> +int i;
> +int64_t cur_addr;
> +uint8_t *cur_buf;
> +
> +for (i = 0; i < BLOCK_SIZE / cluster_size; i++) {
> +cur_addr = addr * BDRV_SECTOR_SIZE
> ++ i * cluster_size;
> +cur_buf = buf + i * cluster_size;
> +
> +if (buffer_is_zero(cur_buf, cluster_size)) {
> +ret = blk_pwrite_zeroes(blk, cur_addr,
> +cluster_size,
> +BDRV_REQ_MAY_UNMAP);
> +} else {
> + ret = blk_pwrite(blk, cur_addr, cur_buf,
> +  cluster_size, 0);
> +}
> +
> +if (ret < 0) {
> +g_free(buf);
> +return ret;
> +}

This if block is not necessary because...

> +}
> +} else {
> +ret = blk_pwrite(blk, addr * BDRV_SECTOR_SIZE, buf,
> + nr_sectors * BDRV_SECTOR_SIZE, 0);
> +}
>  g_free(buf);
...


if (ret < 0) {
return ret;
}
>  }
>  
> -- 
> 1.8.3.1
> 
> 

If you remove that:

Reviewed-by: Fam Zheng 

Re: [Qemu-devel] [Xen-devel] [RFC/BUG] xen-mapcache: buggy invalidate map cache?

[Alexey G]

On Mon, 10 Apr 2017 00:36:02 +0800
hrg  wrote:

Hi,

> On Sun, Apr 9, 2017 at 11:55 PM, hrg  wrote:
> > On Sun, Apr 9, 2017 at 11:52 PM, hrg  wrote:  
> >> Hi,
> >>
> >> In xen_map_cache_unlocked(), map to guest memory maybe in entry->next
> >> instead of first level entry (if map to rom other than guest memory
> >> comes first), while in xen_invalidate_map_cache(), when VM ballooned
> >> out memory, qemu did not invalidate cache entries in linked
> >> list(entry->next), so when VM balloon back in memory, gfns probably
> >> mapped to different mfns, thus if guest asks device to DMA to these
> >> GPA, qemu may DMA to stale MFNs.
> >>
> >> So I think in xen_invalidate_map_cache() linked lists should also be
> >> checked and invalidated.
> >>
> >> What’s your opinion? Is this a bug? Is my analyze correct?  
> >
> > Added Jun Nakajima and Alexander Graf  
> And correct Stefano Stabellini's email address.

There is a real issue with the xen-mapcache corruption in fact. I encountered
it a few months ago while experimenting with Q35 support on Xen. Q35 emulation
uses an AHCI controller by default, along with NCQ mode enabled. The issue can
be (somewhat) easily reproduced there, though using a normal i440 emulation
might possibly allow to reproduce the issue as well, using a dedicated test
code from a guest side. In case of Q35+NCQ the issue can be reproduced "as is".

The issue occurs when a guest domain performs an intensive disk I/O, ex. while
guest OS booting. QEMU crashes with "Bad ram offset 980aa000"
message logged, where the address is different each time. The hard thing with
this issue is that it has a very low reproducibility rate.

The corruption happens when there are multiple I/O commands in the NCQ queue.
So there are overlapping emulated DMA operations in flight and QEMU uses a
sequence of mapcache actions which can be executed in the "wrong" order thus
leading to an inconsistent xen-mapcache - so a bad address from the wrong
entry is returned.

The bad thing with this issue is that QEMU crash due to "Bad ram offset"
appearance is a relatively good situation in the sense that this is a caught
error. But there might be a much worse (artificial) situation where the returned
address looks valid but points to a different mapped memory.

The fix itself is not hard (ex. an additional checked field in MapCacheEntry),
but there is a need of some reliable way to test it considering the low
reproducibility rate.

Regards,
Alex

Re: [Qemu-devel] [PATCH v2 0/3] Enable MTTCG on PPC64

[Richard Henderson]

On 04/07/2017 11:51 PM, David Gibson wrote:

On Fri, Apr 07, 2017 at 11:37:49AM +0530, Nikunj A Dadhania wrote:

The series enables Multi-Threaded TCG on PPC64

Patch 01: Use atomic_cmpxchg in store conditional
  02: Handle first write to page during atomic operation
  03: Generate memory barriers for sync/isync and load/store conditional

Patches are based on ppc-for-2.10


Applied to ppc-for-2.10.  Anyone object to that for 2/3, which isn't
within ppc code?


Please go ahead.  If there was another queue it might have gone in, it would 
probably be tcg-next, and I don't have anything else pending at the moment.



r~

Re: [Qemu-devel] [RFC/BUG] xen-mapcache: buggy invalidate map cache?

[hrg]

On Sun, Apr 9, 2017 at 11:55 PM, hrg  wrote:
> On Sun, Apr 9, 2017 at 11:52 PM, hrg  wrote:
>> Hi,
>>
>> In xen_map_cache_unlocked(), map to guest memory maybe in entry->next
>> instead of first level entry (if map to rom other than guest memory
>> comes first), while in xen_invalidate_map_cache(), when VM ballooned
>> out memory, qemu did not invalidate cache entries in linked
>> list(entry->next), so when VM balloon back in memory, gfns probably
>> mapped to different mfns, thus if guest asks device to DMA to these
>> GPA, qemu may DMA to stale MFNs.
>>
>> So I think in xen_invalidate_map_cache() linked lists should also be
>> checked and invalidated.
>>
>> What’s your opinion? Is this a bug? Is my analyze correct?
>
> Added Jun Nakajima and Alexander Graf
And correct Stefano Stabellini's email address.

Re: [Qemu-devel] [RFC/BUG] xen-mapcache: buggy invalidate map cache?

[hrg]

On Sun, Apr 9, 2017 at 11:52 PM, hrg  wrote:
> Hi,
>
> In xen_map_cache_unlocked(), map to guest memory maybe in entry->next
> instead of first level entry (if map to rom other than guest memory
> comes first), while in xen_invalidate_map_cache(), when VM ballooned
> out memory, qemu did not invalidate cache entries in linked
> list(entry->next), so when VM balloon back in memory, gfns probably
> mapped to different mfns, thus if guest asks device to DMA to these
> GPA, qemu may DMA to stale MFNs.
>
> So I think in xen_invalidate_map_cache() linked lists should also be
> checked and invalidated.
>
> What’s your opinion? Is this a bug? Is my analyze correct?

Added Jun Nakajima and Alexander Graf

[Qemu-devel] [RFC/BUG] xen-mapcache: buggy invalidate map cache?

[hrg]

Hi,

In xen_map_cache_unlocked(), map to guest memory maybe in entry->next
instead of first level entry (if map to rom other than guest memory
comes first), while in xen_invalidate_map_cache(), when VM ballooned
out memory, qemu did not invalidate cache entries in linked
list(entry->next), so when VM balloon back in memory, gfns probably
mapped to different mfns, thus if guest asks device to DMA to these
GPA, qemu may DMA to stale MFNs.

So I think in xen_invalidate_map_cache() linked lists should also be
checked and invalidated.

What’s your opinion? Is this a bug? Is my analyze correct?

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 0/3] Enable MTTCG on PPC64

[Alex Bennée]

luigi burdo  writes:

> Hi David and Nikuji,
>
> can i suggest to remove the message:
>
>
> Guest not yet converted to MTTCG - you may get unexpected results
> where the mttcg is enabled?

Have you declared the memory ordering for the guest?

>
> another thing im finding  is this message
> Guest expects a stronger memory ordering than the host provides
> This may cause strange/hard to debug errors

See ca759f9e387db87e1719911f019bc60c74be9ed8 for an example.

>
>
> I have 8 gb on my machine and this message come if i gave 512mb on the guest 
> too.
>
> Is possible know where the mttcg is already enabled?
>
> i see on x86,i386,arm too if i set thread=multy the qemu start using the 
> other host cores is on this guest system enabled?
>
> if yes i have the same messages of ppc64 too :
>
> Guest not yet converted to MTTCG - you may get unexpected results
>
> and
>
> Guest expects a stronger memory ordering than the host provides
> This may cause strange/hard to debug errors
>
>
> Ciao
>
> Luigi
>
>
> Applied to ppc-for-2.10.  Anyone object to that for 2/3, which isn't
> within ppc code?


--
Alex Bennée

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 0/3] Enable MTTCG on PPC64

[Alex Bennée]

luigi burdo  writes:

> Hi, on info is mttcg using an amouth of ram for cpu caching and
> translating operations like was did in past by emulators like
> virtualpc,realpc, bluelabel or softwindows?

It's a fixed buffer. You can see if it being flushed by running:

  info jit

On the QEMU monitor console.

>
> in case of yes is possible increase it from the command line?
>
> Thanks
>
> Luigi


--
Alex Bennée

Re: [Qemu-devel] [PATCH v3] migration/block:limit the time used for block migration

[858585 jemmy]

On Fri, Apr 7, 2017 at 7:33 PM, Stefan Hajnoczi  wrote:
> On Fri, Apr 07, 2017 at 09:30:33AM +0800, 858585 jemmy wrote:
>> On Thu, Apr 6, 2017 at 10:02 PM, Stefan Hajnoczi  wrote:
>> > On Wed, Apr 05, 2017 at 05:27:58PM +0800, jemmy858...@gmail.com wrote:
>> >> From: Lidong Chen 
>> >>
>> >> when migration with high speed, mig_save_device_bulk invoke
>> >> bdrv_is_allocated too frequently, and cause vnc reponse slowly.
>> >> this patch limit the time used for bdrv_is_allocated.
>> >
>> > bdrv_is_allocated() is supposed to yield back to the event loop if it
>> > needs to block.  If your VNC session is experiencing jitter then it's
>> > probably because a system call in the bdrv_is_allocated() code path is
>> > synchronous when it should be asynchronous.
>> >
>> > You could try to identify the system call using strace -f -T.  In the
>> > output you'll see the duration of each system call.  I guess there is a
>> > file I/O system call that is taking noticable amounts of time.
>>
>> yes, i find the reason where bdrv_is_allocated needs to block.
>>
>> the mainly reason is caused by qemu_co_mutex_lock invoked by
>> qcow2_co_get_block_status.
>> qemu_co_mutex_lock(>lock);
>> ret = qcow2_get_cluster_offset(bs, sector_num << 9, ,
>>_offset);
>> qemu_co_mutex_unlock(>lock);
>>
>> other reason is caused by l2_load invoked by
>> qcow2_get_cluster_offset.
>>
>> /* load the l2 table in memory */
>>
>> ret = l2_load(bs, l2_offset, _table);
>> if (ret < 0) {
>> return ret;
>> }
>
> The migration thread is holding the QEMU global mutex, the AioContext,
> and the qcow2 s->lock while the L2 table is read from disk.
>
> The QEMU global mutex is needed for block layer operations that touch
> the global drives list.  bdrv_is_allocated() can be called without the
> global mutex.
>
> The VNC server's file descriptor is not in the BDS AioContext.
> Therefore it can be processed while the migration thread holds the
> AioContext and qcow2 s->lock.
>
> Does the following patch solve the problem?
>
> diff --git a/migration/block.c b/migration/block.c
> index 7734ff7..072fc20 100644
> --- a/migration/block.c
> +++ b/migration/block.c
> @@ -276,6 +276,7 @@ static int mig_save_device_bulk(QEMUFile *f, 
> BlkMigDevState *bmds)
>  if (bmds->shared_base) {
>  qemu_mutex_lock_iothread();
>  aio_context_acquire(blk_get_aio_context(bb));
> +qemu_mutex_unlock_iothread();
>  /* Skip unallocated sectors; intentionally treats failure as
>   * an allocated sector */
>  while (cur_sector < total_sectors &&
> @@ -283,6 +284,7 @@ static int mig_save_device_bulk(QEMUFile *f, 
> BlkMigDevState *bmds)
>MAX_IS_ALLOCATED_SEARCH, _sectors)) {
>  cur_sector += nr_sectors;
>  }
> +qemu_mutex_lock_iothread();
>  aio_context_release(blk_get_aio_context(bb));
>  qemu_mutex_unlock_iothread();
>  }
>

this patch don't work. the qemu lockup.
the stack of main thread.
(gdb) bt
#0  0x7f4256c89264 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x7f4256c84523 in _L_lock_892 () from /lib64/libpthread.so.0
#2  0x7f4256c84407 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x00949f47 in qemu_mutex_lock (mutex=0x1b04a60) at
util/qemu-thread-posix.c:60
#4  0x009424cf in aio_context_acquire (ctx=0x1b04a00) at
util/async.c:484
#5  0x00942b86 in thread_pool_completion_bh (opaque=0x1b25a10)
at util/thread-pool.c:168
#6  0x00941610 in aio_bh_call (bh=0x1b1d570) at util/async.c:90
#7  0x009416bb in aio_bh_poll (ctx=0x1b04a00) at util/async.c:118
#8  0x00946baa in aio_dispatch (ctx=0x1b04a00) at util/aio-posix.c:429
#9  0x00941b30 in aio_ctx_dispatch (source=0x1b04a00,
callback=0, user_data=0x0)
at util/async.c:261
#10 0x7f4257670f0e in g_main_context_dispatch () from
/lib64/libglib-2.0.so.0
#11 0x00945282 in glib_pollfds_poll () at util/main-loop.c:213
#12 0x009453a3 in os_host_main_loop_wait (timeout=754229747)
at util/main-loop.c:261
#13 0x0094546e in main_loop_wait (nonblocking=0) at util/main-loop.c:517
#14 0x005c7664 in main_loop () at vl.c:1898
#15 0x005ceb27 in main (argc=49, argv=0x7fff7907ab28,
envp=0x7fff7907acb8) at vl.c:4709

the stack of migration thread.
(gdb) bt
#0  0x7f4256c89264 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x7f4256c84508 in _L_lock_854 () from /lib64/libpthread.so.0
#2  0x7f4256c843d7 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x00949f47 in qemu_mutex_lock (mutex=0xfc5200) at
util/qemu-thread-posix.c:60
#4  0x00459e08 in qemu_mutex_lock_iothread () at /root/qemu/cpus.c:1516
#5  0x007d2e04 in mig_save_device_bulk (f=0x2489720,
bmds=0x7f4258f0)
at migration/block.c:287
#6  

[Qemu-devel] [PATCH v3] migration/block: use blk_pwrite_zeroes for each zero cluster

[jemmy858585]

From: Lidong Chen 

BLOCK_SIZE is (1 << 20), qcow2 cluster size is 65536 by default,
this maybe cause the qcow2 file size is bigger after migration.
This patch check each cluster, use blk_pwrite_zeroes for each
zero cluster.

Signed-off-by: Lidong Chen 
---
 migration/block.c | 38 --
 1 file changed, 36 insertions(+), 2 deletions(-)

diff --git a/migration/block.c b/migration/block.c
index 7734ff7..fe613db 100644
--- a/migration/block.c
+++ b/migration/block.c
@@ -885,6 +885,8 @@ static int block_load(QEMUFile *f, void *opaque, int 
version_id)
 int64_t total_sectors = 0;
 int nr_sectors;
 int ret;
+BlockDriverInfo bdi;
+int cluster_size;
 
 do {
 addr = qemu_get_be64(f);
@@ -934,8 +936,40 @@ static int block_load(QEMUFile *f, void *opaque, int 
version_id)
 } else {
 buf = g_malloc(BLOCK_SIZE);
 qemu_get_buffer(f, buf, BLOCK_SIZE);
-ret = blk_pwrite(blk, addr * BDRV_SECTOR_SIZE, buf,
- nr_sectors * BDRV_SECTOR_SIZE, 0);
+
+ret = bdrv_get_info(blk_bs(blk), );
+cluster_size = bdi.cluster_size;
+
+if (ret == 0 && cluster_size > 0 &&
+cluster_size <= BLOCK_SIZE &&
+BLOCK_SIZE % cluster_size == 0) {
+int i;
+int64_t cur_addr;
+uint8_t *cur_buf;
+
+for (i = 0; i < BLOCK_SIZE / cluster_size; i++) {
+cur_addr = addr * BDRV_SECTOR_SIZE
++ i * cluster_size;
+cur_buf = buf + i * cluster_size;
+
+if (buffer_is_zero(cur_buf, cluster_size)) {
+ret = blk_pwrite_zeroes(blk, cur_addr,
+cluster_size,
+BDRV_REQ_MAY_UNMAP);
+} else {
+ ret = blk_pwrite(blk, cur_addr, cur_buf,
+  cluster_size, 0);
+}
+
+if (ret < 0) {
+g_free(buf);
+return ret;
+}
+}
+} else {
+ret = blk_pwrite(blk, addr * BDRV_SECTOR_SIZE, buf,
+ nr_sectors * BDRV_SECTOR_SIZE, 0);
+}
 g_free(buf);
 }
 
-- 
1.8.3.1

[Qemu-devel] [Qemu-devel RFC v2 2/4] msf2: Microsemi Smartfusion2 System Register block.

[Subbaraya Sundeep]

Added Sytem register block of Smartfusion2.
This block has PLL registers which are accessed by guest.

Signed-off-by: Subbaraya Sundeep 
---
 hw/misc/Makefile.objs |   1 +
 hw/misc/msf2_sysreg.c | 168 ++
 2 files changed, 169 insertions(+)
 create mode 100644 hw/misc/msf2_sysreg.c

diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index c8b4893..aee53df 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -56,3 +56,4 @@ obj-$(CONFIG_EDU) += edu.o
 obj-$(CONFIG_HYPERV_TESTDEV) += hyperv_testdev.o
 obj-$(CONFIG_AUX) += auxbus.o
 obj-$(CONFIG_ASPEED_SOC) += aspeed_scu.o aspeed_sdmc.o
+obj-$(CONFIG_MSF2) += msf2_sysreg.o
diff --git a/hw/misc/msf2_sysreg.c b/hw/misc/msf2_sysreg.c
new file mode 100644
index 000..4873463
--- /dev/null
+++ b/hw/misc/msf2_sysreg.c
@@ -0,0 +1,168 @@
+/*
+ * System Register block model of Microsemi SmartFusion2.
+ *
+ * Copyright (c) 2017 Subbaraya Sundeep 
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "hw/hw.h"
+#include "qemu/timer.h"
+#include "hw/sysbus.h"
+#include "sysemu/sysemu.h"
+#include "qemu/log.h"
+
+#ifndef MSF2_SYSREG_ERR_DEBUG
+#define MSF2_SYSREG_ERR_DEBUG 0
+#endif
+
+#define DB_PRINT(...) do { \
+if (MSF2_SYSREG_ERR_DEBUG) { \
+fprintf(stderr,  ": %s: ", __func__); \
+fprintf(stderr, ## __VA_ARGS__); \
+} \
+} while (0);
+
+#define R_PSS_RST_CTRL_SOFT_RST 0x1
+
+enum {
+ESRAM_CR= 0x00 / 4,
+ESRAM_MAX_LAT,
+DDR_CR,
+ENVM_CR,
+ENVM_REMAP_BASE_CR,
+ENVM_REMAP_FAB_CR,
+CC_CR,
+CC_REGION_CR,
+CC_LOCK_BASE_ADDR_CR,
+CC_FLUSH_INDX_CR,
+DDRB_BUF_TIMER_CR,
+DDRB_NB_ADDR_CR,
+DDRB_NB_SIZE_CR,
+DDRB_CR,
+
+SOFT_RESET_CR  = 0x48 / 4,
+M3_CR,
+
+GPIO_SYSRESET_SEL_CR = 0x58 / 4,
+
+MDDR_CR = 0x60 / 4,
+
+MSSDDR_PLL_STATUS_LOW_CR = 0x90 / 4,
+MSSDDR_PLL_STATUS_HIGH_CR,
+MSSDDR_FACC1_CR,
+MSSDDR_FACC2_CR,
+
+MSSDDR_PLL_STATUS = 0x150 / 4,
+
+};
+
+#define MSF2_SYSREG_MMIO_SIZE 0x300
+#define MSF2_SYSREG_NUM_REGS  (MSF2_SYSREG_MMIO_SIZE / 4)
+
+#define TYPE_MSF2_SYSREG  "msf2-sysreg"
+#define MSF2_SYSREG(obj)  OBJECT_CHECK(Sf2SysregState, (obj), TYPE_MSF2_SYSREG)
+
+typedef struct Sf2SysregState {
+SysBusDevice parent_obj;
+
+MemoryRegion iomem;
+
+uint32_t regs[MSF2_SYSREG_NUM_REGS];
+} Sf2SysregState;
+
+static void msf2_sysreg_reset(DeviceState *d)
+{
+Sf2SysregState *s = MSF2_SYSREG(d);
+
+DB_PRINT("RESET\n");
+
+s->regs[MSSDDR_PLL_STATUS_LOW_CR] = 0x02420041;
+s->regs[MSSDDR_FACC1_CR] = 0x0A482124;
+s->regs[MSSDDR_PLL_STATUS] = 0x3;
+}
+
+static uint64_t msf2_sysreg_read(void *opaque, hwaddr offset,
+unsigned size)
+{
+Sf2SysregState *s = opaque;
+offset /= 4;
+uint32_t ret = s->regs[offset];
+
+DB_PRINT("addr: %08" HWADDR_PRIx " data: %08" PRIx32 "\n", offset * 4, 
ret);
+
+   return ret;
+}
+
+static void msf2_sysreg_write(void *opaque, hwaddr offset,
+  uint64_t val, unsigned size)
+{
+Sf2SysregState *s = (Sf2SysregState *)opaque;
+offset /= 4;
+
+DB_PRINT("addr: %08" HWADDR_PRIx " data: %08" PRIx64 "\n", offset * 4, 
val);
+
+switch (offset) {
+case MSSDDR_PLL_STATUS:
+break;
+
+default:
+s->regs[offset] = val;
+break;
+}
+}
+
+static const MemoryRegionOps sysreg_ops = {
+.read = msf2_sysreg_read,
+.write = msf2_sysreg_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+};
+
+static void msf2_sysreg_init(Object *obj)
+{
+Sf2SysregState *s = MSF2_SYSREG(obj);
+
+memory_region_init_io(>iomem, obj, _ops, s, "sysreg",
+  MSF2_SYSREG_MMIO_SIZE);
+sysbus_init_mmio(SYS_BUS_DEVICE(obj), >iomem);
+}
+
+static const VMStateDescription vmstate_msf2_sysreg = {
+.name = "msf2_sysreg",
+.version_id = 2,
+.minimum_version_id = 2,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32_ARRAY(regs, Sf2SysregState, MSF2_SYSREG_NUM_REGS),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static void msf2_sysreg_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+
+dc->vmsd = _msf2_sysreg;
+dc->reset = msf2_sysreg_reset;
+}
+
+static const TypeInfo msf2_sysreg_info = {
+.class_init = msf2_sysreg_class_init,
+.name  = TYPE_MSF2_SYSREG,
+.parent = TYPE_SYS_BUS_DEVICE,
+.instance_size  = sizeof(Sf2SysregState),
+.instance_init = msf2_sysreg_init,
+};
+
+static void 

[Qemu-devel] [Qemu-devel RFC v2 4/4] msf2: Add Emcraft's Smartfusion2 SOM kit.

[Subbaraya Sundeep]

Emulated Emcraft's Smartfusion2 System On Module starter
kit.

Signed-off-by: Subbaraya Sundeep 
---
 default-configs/arm-softmmu.mak |   1 +
 hw/arm/Makefile.objs|   2 +-
 hw/arm/msf2_soc.c   | 141 
 3 files changed, 143 insertions(+), 1 deletion(-)
 create mode 100644 hw/arm/msf2_soc.c

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 1e3bd2b..379f7e1 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -121,3 +121,4 @@ CONFIG_ACPI=y
 CONFIG_SMBIOS=y
 CONFIG_ASPEED_SOC=y
 CONFIG_GPIO_KEY=y
+CONFIG_MSF2=y
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 4c5c4ee..cce2759 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -1,7 +1,7 @@
 obj-y += boot.o collie.o exynos4_boards.o gumstix.o highbank.o
 obj-$(CONFIG_DIGIC) += digic_boards.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 += omap_sx1.o palm.o realview.o spitz.o stellaris.o msf2_soc.o
 obj-y += tosa.o versatilepb.o vexpress.o virt.o xilinx_zynq.o z2.o
 obj-$(CONFIG_ACPI) += virt-acpi-build.o
 obj-y += netduino2.o
diff --git a/hw/arm/msf2_soc.c b/hw/arm/msf2_soc.c
new file mode 100644
index 000..7277b51
--- /dev/null
+++ b/hw/arm/msf2_soc.c
@@ -0,0 +1,141 @@
+/*
+ * Smartfusion2 SOM starter kit(from Emcraft) emulation.
+ *
+ * Copyright (c) 2017 Subbaraya Sundeep 
+ *
+ * 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.
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "qemu-common.h"
+#include "hw/arm/arm.h"
+#include "exec/address-spaces.h"
+#include "hw/sysbus.h"
+#include "hw/char/serial.h"
+#include "hw/boards.h"
+#include "sysemu/block-backend.h"
+#include "hw/ssi/ssi.h"
+
+#define MSF2_NUM_USARTS   1
+#define MSF2_NUM_TIMERS   2
+
+#define ENVM_BASE_ADDRESS 0x6000
+#define ENVM_SIZE (128 * 1024)
+
+#define DDR_BASE_ADDRESS  0xA000
+#define DDR_SIZE  (64 * 1024 * 1024)
+
+#define SRAM_BASE_ADDRESS 0x2000
+#define SRAM_SIZE (64 * 1024)
+
+#define MSF2_TIMER_BASE   0x40004000
+#define MSF2_UART0_BASE   0x4000
+#define MSF2_SYSREG_BASE  0x40038000
+#define MSF2_SPI0_BASE0x40001000
+
+#define MSF2_SPI0_IRQ 2
+#define MSF2_UART0_IRQ10
+#define MSF2_TIMER_IRQ0   14
+#define MSF2_TIMER_IRQ1   15
+
+static void msf2_init(MachineState *machine)
+{
+const char *kernel_filename = NULL;
+DeviceState *dev, *nvic;
+MemoryRegion *system_memory = get_system_memory();
+MemoryRegion *nvm = g_new(MemoryRegion, 1);
+MemoryRegion *nvm_alias = g_new(MemoryRegion, 1);
+MemoryRegion *sram = g_new(MemoryRegion, 1);
+MemoryRegion *ddr = g_new(MemoryRegion, 1);
+QemuOpts *machine_opts = qemu_get_machine_opts();
+SysBusDevice *busdev;
+DriveInfo *dinfo = drive_get_next(IF_MTD);
+qemu_irq cs_line;
+SSIBus *spi;
+
+kernel_filename = qemu_opt_get(machine_opts, "kernel");
+
+memory_region_init_ram(nvm, NULL, "MSF2.envm", ENVM_SIZE,
+   _fatal);
+memory_region_init_alias(nvm_alias, NULL, "MSF2.flash.alias",
+ nvm, 0, ENVM_SIZE);
+vmstate_register_ram_global(nvm);
+
+memory_region_set_readonly(nvm, true);
+memory_region_set_readonly(nvm_alias, true);
+
+memory_region_add_subregion(system_memory, ENVM_BASE_ADDRESS, nvm);
+memory_region_add_subregion(system_memory, 0, nvm_alias);
+
+memory_region_init_ram(ddr, NULL, "MSF2.ddr", DDR_SIZE,
+   _fatal);
+vmstate_register_ram_global(ddr);
+memory_region_add_subregion(system_memory, DDR_BASE_ADDRESS, ddr);
+
+memory_region_init_ram(sram, NULL, "MSF2.sram", SRAM_SIZE,
+   _fatal);
+

[Qemu-devel] [Qemu-devel RFC v2 3/4] msf2: Add Smartfusion2 SPI controller

[Subbaraya Sundeep]

Modelled Microsemi's Smartfusion2 SPI controller.

Signed-off-by: Subbaraya Sundeep 
---
 hw/ssi/Makefile.objs |   1 +
 hw/ssi/msf2_spi.c| 449 +++
 2 files changed, 450 insertions(+)
 create mode 100644 hw/ssi/msf2_spi.c

diff --git a/hw/ssi/Makefile.objs b/hw/ssi/Makefile.objs
index 487add2..86445d7 100644
--- a/hw/ssi/Makefile.objs
+++ b/hw/ssi/Makefile.objs
@@ -4,6 +4,7 @@ common-obj-$(CONFIG_XILINX_SPI) += xilinx_spi.o
 common-obj-$(CONFIG_XILINX_SPIPS) += xilinx_spips.o
 common-obj-$(CONFIG_ASPEED_SOC) += aspeed_smc.o
 common-obj-$(CONFIG_STM32F2XX_SPI) += stm32f2xx_spi.o
+common-obj-$(CONFIG_MSF2) += msf2_spi.o
 
 obj-$(CONFIG_OMAP) += omap_spi.o
 obj-$(CONFIG_IMX) += imx_spi.o
diff --git a/hw/ssi/msf2_spi.c b/hw/ssi/msf2_spi.c
new file mode 100644
index 000..6054cd8
--- /dev/null
+++ b/hw/ssi/msf2_spi.c
@@ -0,0 +1,449 @@
+/*
+ * SPI controller model of Microsemi Smartfusion2.
+ *
+ * Copyright (C) 2017 Subbaraya Sundeep 
+ *
+ * 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.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/sysbus.h"
+#include "sysemu/sysemu.h"
+#include "qemu/log.h"
+#include "qemu/fifo32.h"
+
+#include "hw/ssi/ssi.h"
+
+#ifdef MSF2_SPI_ERR_DEBUG
+#define DB_PRINT(...) do { \
+fprintf(stderr,  ": %s: ", __func__); \
+fprintf(stderr, ## __VA_ARGS__); \
+} while (0);
+#else
+#define DB_PRINT(...)
+#endif
+
+#define FIFO_CAPACITY 32
+#define FIFO_CAPACITY 32
+
+#define R_CONTROL 0
+#define R_DFSIZE  1
+#define R_STATUS  2
+#define R_INTCLR  3
+#define R_RX  4
+#define R_TX  5
+#define R_CLKGEN  6
+#define R_SS  7
+#define R_MIS 8
+#define R_RIS 9
+#define R_CONTROL210
+#define R_COMMAND 11
+#define R_PKTSIZE 12
+#define R_CMDSIZE 13
+#define R_HWSTATUS14
+#define R_STAT8   15
+#define R_MAX 16
+
+#define S_RXFIFOFUL   (1 << 4)
+#define S_RXFIFOFULNXT(1 << 5)
+#define S_RXFIFOEMP   (1 << 6)
+#define S_RXFIFOEMPNXT(1 << 7)
+#define S_TXFIFOFUL   (1 << 8)
+#define S_TXFIFOFULNXT(1 << 9)
+#define S_TXFIFOEMP   (1 << 10)
+#define S_TXFIFOEMPNXT(1 << 11)
+#define S_FRAMESTART  (1 << 12)
+#define S_SSEL(1 << 13)
+#define S_ACTIVE  (1 << 14)
+
+#define C_ENABLE  (1 << 0)
+#define C_MODE(1 << 1)
+#define C_INTRXDATA   (1 << 4)
+#define C_INTTXDATA   (1 << 5)
+#define C_INTRXOVRFLO (1 << 6)
+#define C_SPS (1 << 26)
+#define C_BIGFIFO (1 << 29)
+#define C_RESET   (1 << 31)
+
+#define FRAMESZ_MASK  0x1F
+#define FMCOUNT_MASK  0x0000
+#define FMCOUNT_SHIFT 8
+
+#define TXDONE(1 << 0)
+#define RXRDY (1 << 1)
+#define RXCHOVRF  (1 << 2)
+
+#define TYPE_MSF2_SPI   "msf2-spi"
+#define MSF2_SPI(obj)   OBJECT_CHECK(Msf2SPI, (obj), TYPE_MSF2_SPI)
+
+typedef struct Msf2SPI {
+SysBusDevice parent_obj;
+
+MemoryRegion mmio;
+
+qemu_irq irq;
+
+qemu_irq cs_line;
+
+SSIBus *spi;
+
+Fifo32 rx_fifo;
+Fifo32 tx_fifo;
+
+int fifo_depth;
+uint32_t frame_count;
+bool enabled;
+
+uint32_t regs[R_MAX];
+} Msf2SPI;
+
+static void txfifo_reset(Msf2SPI *s)
+{
+fifo32_reset(>tx_fifo);
+
+s->regs[R_STATUS] &= ~S_TXFIFOFUL;
+s->regs[R_STATUS] |= S_TXFIFOEMP;
+}
+
+static void rxfifo_reset(Msf2SPI *s)
+{
+fifo32_reset(>rx_fifo);
+
+s->regs[R_STATUS] &= ~S_RXFIFOFUL;
+s->regs[R_STATUS] |= S_RXFIFOEMP;
+}
+
+static void set_fifodepth(Msf2SPI *s)
+{
+int size = s->regs[R_DFSIZE] & FRAMESZ_MASK;
+
+if (0 <= size && size <= 8) {
+s->fifo_depth = 32;
+}
+if (9 <= size && size <= 16) {
+s->fifo_depth = 16;
+}
+if (17 <= size && size <= 32) {
+s->fifo_depth 

[Qemu-devel] [Qemu-devel RFC v2 0/4] Add support for Smartfusion2 SoC

[Subbaraya Sundeep]

Hi Qemu-devel,

I am trying to add Smartfusion2 SoC.
SoC is from Microsemi and System on Module(SOM)
board is from Emcraft systems. Smartfusion2 has hardened
Microcontroller(Cortex-M3)based Sub System and FPGA fabric.
At the moment only system timer, sysreg and SPI
controller are modelled.

Testing:
./arm-softmmu/qemu-system-arm -M smartfusion2-som -serial mon:stdio \
-kernel u-boot.bin -display none -drive file=spi.bin,if=mtd,format=raw

U-boot is from Emcraft with modified SPI driver not to use PDMA.
Linux is 4.5 linux with Smartfusion2 SoC dts and clocksource 
driver added by myself @
https://github.com/Subbaraya-Sundeep/linux.git

Baremetal elfs from Microsemi Softconsole IDE are also working.

Changes from v1:
Added SPI controller.

Thanks,
Sundeep

Subbaraya Sundeep (4):
  msf2: Add Smartfusion2 System timer
  msf2: Microsemi Smartfusion2 System Register block.
  msf2: Add Smartfusion2 SPI controller
  msf2: Add Emcraft's Smartfusion2 SOM kit.

 default-configs/arm-softmmu.mak |   1 +
 hw/arm/Makefile.objs|   2 +-
 hw/arm/msf2_soc.c   | 141 +
 hw/misc/Makefile.objs   |   1 +
 hw/misc/msf2_sysreg.c   | 168 +++
 hw/ssi/Makefile.objs|   1 +
 hw/ssi/msf2_spi.c   | 449 
 hw/timer/Makefile.objs  |   1 +
 hw/timer/msf2_timer.c   | 273 
 9 files changed, 1036 insertions(+), 1 deletion(-)
 create mode 100644 hw/arm/msf2_soc.c
 create mode 100644 hw/misc/msf2_sysreg.c
 create mode 100644 hw/ssi/msf2_spi.c
 create mode 100644 hw/timer/msf2_timer.c

-- 
2.5.0

[Qemu-devel] [Qemu-devel RFC v2 1/4] msf2: Add Smartfusion2 System timer

[Subbaraya Sundeep]

Modelled System Timer in Microsemi's Smartfusion2 Soc.
Timer has two 32bit down counters and two interrupts.

Signed-off-by: Subbaraya Sundeep 
---
 hw/timer/Makefile.objs |   1 +
 hw/timer/msf2_timer.c  | 273 +
 2 files changed, 274 insertions(+)
 create mode 100644 hw/timer/msf2_timer.c

diff --git a/hw/timer/Makefile.objs b/hw/timer/Makefile.objs
index dd6f27e..0bdf1e1 100644
--- a/hw/timer/Makefile.objs
+++ b/hw/timer/Makefile.objs
@@ -41,3 +41,4 @@ common-obj-$(CONFIG_STM32F2XX_TIMER) += stm32f2xx_timer.o
 common-obj-$(CONFIG_ASPEED_SOC) += aspeed_timer.o
 
 common-obj-$(CONFIG_SUN4V_RTC) += sun4v-rtc.o
+common-obj-$(CONFIG_MSF2) += msf2_timer.o
diff --git a/hw/timer/msf2_timer.c b/hw/timer/msf2_timer.c
new file mode 100644
index 000..962ada4
--- /dev/null
+++ b/hw/timer/msf2_timer.c
@@ -0,0 +1,273 @@
+/*
+ * Timer block model of Microsemi SmartFusion2.
+ *
+ * Copyright (c) 2017 Subbaraya Sundeep .
+ *
+ * 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.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/sysbus.h"
+#include "hw/ptimer.h"
+#include "qemu/log.h"
+#include "qemu/main-loop.h"
+
+#define D(x)
+
+#define NUM_TIMERS 2
+
+#define R_VAL  0
+#define R_LOADVAL  1
+#define R_BGLOADVAL2
+#define R_CTRL 3
+#define R_RIS  4
+#define R_MIS  5
+#define R_MAX  6
+
+#define TIMER_CTRL_ENBL (1 << 0)
+#define TIMER_CTRL_ONESHOT  (1 << 1)
+#define TIMER_CTRL_INTR (1 << 2)
+#define TIMER_RIS_ACK   (1 << 0)
+#define TIMER_RST_CLR   (1 << 6)
+
+struct msf2_timer {
+QEMUBH *bh;
+ptimer_state *ptimer;
+void *parent;
+int nr; /* for debug.  */
+
+unsigned long timer_div;
+
+uint32_t regs[R_MAX];
+qemu_irq irq;
+};
+
+#define TYPE_MSF2_TIMER "msf2-timer"
+#define MSF2_TIMER(obj) \
+OBJECT_CHECK(struct timerblock, (obj), TYPE_MSF2_TIMER)
+
+struct timerblock {
+SysBusDevice parent_obj;
+
+MemoryRegion mmio;
+uint32_t freq_hz;
+struct msf2_timer *timers;
+};
+
+static inline unsigned int timer_from_addr(hwaddr addr)
+{
+/* Timers get a 6x32bit control reg area each.  */
+return addr / R_MAX;
+}
+
+static void timer_update_irq(struct msf2_timer *st)
+{
+int isr;
+int ier;
+
+isr = !!(st->regs[R_RIS] & TIMER_RIS_ACK);
+ier = !!(st->regs[R_CTRL] & TIMER_CTRL_INTR);
+
+qemu_set_irq(st->irq, (ier && isr));
+}
+
+static uint64_t
+timer_read(void *opaque, hwaddr addr, unsigned int size)
+{
+struct timerblock *t = opaque;
+struct msf2_timer *st;
+uint32_t r = 0;
+unsigned int timer;
+int isr;
+int ier;
+
+addr >>= 2;
+timer = timer_from_addr(addr);
+st = >timers[timer];
+
+if (timer) {
+addr -= 6;
+}
+
+switch (addr) {
+case R_VAL:
+r = ptimer_get_count(st->ptimer);
+D(qemu_log("msf2_timer t=%d read counter=%x\n", timer, r));
+break;
+
+case R_MIS:
+isr = !!(st->regs[R_RIS] & TIMER_RIS_ACK);
+ier = !!(st->regs[R_CTRL] & TIMER_CTRL_INTR);
+r = ier && isr;
+break;
+
+default:
+if (addr < ARRAY_SIZE(st->regs)) {
+r = st->regs[addr];
+}
+break;
+}
+D(fprintf(stderr, "%s timer=%d %x=%x\n", __func__, timer, addr * 4, r));
+return r;
+}
+
+static void timer_update(struct msf2_timer *st)
+{
+uint64_t count;
+
+D(fprintf(stderr, "%s timer=%d\n", __func__, st->nr));
+
+if (!(st->regs[R_CTRL] & TIMER_CTRL_ENBL)) {
+ptimer_stop(st->ptimer);
+return;
+}
+
+count = st->regs[R_LOADVAL];
+ptimer_set_limit(st->ptimer, count, 1);
+ptimer_run(st->ptimer, 1);
+}
+
+static void
+timer_write(void *opaque, hwaddr addr,
+uint64_t val64, unsigned int size)
+{
+struct timerblock *t = opaque;
+struct msf2_timer *st;
+unsigned int timer;
+uint32_t value = 

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 0/3] Enable MTTCG on PPC64

[luigi burdo]

Hi David and Nikuji,

can i suggest to remove the message:


Guest not yet converted to MTTCG - you may get unexpected results
where the mttcg is enabled?

another thing im finding  is this message
Guest expects a stronger memory ordering than the host provides
This may cause strange/hard to debug errors


I have 8 gb on my machine and this message come if i gave 512mb on the guest 
too.

Is possible know where the mttcg is already enabled?

i see on x86,i386,arm too if i set thread=multy the qemu start using the other 
host cores is on this guest system enabled?

if yes i have the same messages of ppc64 too :

Guest not yet converted to MTTCG - you may get unexpected results

and

Guest expects a stronger memory ordering than the host provides
This may cause strange/hard to debug errors


Ciao

Luigi


Applied to ppc-for-2.10.  Anyone object to that for 2/3, which isn't
within ppc code?

--
David Gibson

Re: [Qemu-devel] [PATCH v2 0/3] Enable MTTCG on PPC64

[David Gibson]

On Fri, Apr 07, 2017 at 11:37:49AM +0530, Nikunj A Dadhania wrote:
> The series enables Multi-Threaded TCG on PPC64
> 
> Patch 01: Use atomic_cmpxchg in store conditional
>   02: Handle first write to page during atomic operation
>   03: Generate memory barriers for sync/isync and load/store conditional
> 
> Patches are based on ppc-for-2.10

Applied to ppc-for-2.10.  Anyone object to that for 2/3, which isn't
within ppc code?

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] What is the best commit for record-replay?

[Pranith Kumar]

On Thu, Mar 23, 2017 at 4:05 AM, Igor R  wrote:
> Hi,
>
> I'm trying to use the deterministic record/replay feature, and I would
> like to know which commit I should take to get it work.
> In RC0 it seems to be broken. I tried pre-MTTCG commit 2421f381dc, as

Can you retry with the latest rc? There were some fixes regarding rr since rc0.

Thanks,
--
Pranith

Re: [Qemu-devel] [Bug 1020309] Re: qemu-system-ppc: no keyboard after savevm/loadvm

[Thomas Eschenbacher]

Thomas Huth wrote:

> Triaging old bug tickets ... can you still reproduce this issue with the
> latest version of QEMU (version 2.9)?
> 
> ** Changed in: qemu
>Status: New => Incomplete
> 

Hello Thomas,

here my answer per email:

I re-tested that simple sequence above and it seems to work now,
using qemu-2.8.0 !

I did not use qemu-ppc again in the past five years, so I can not tell
you "when" this got fixed (which exact version). At least it seems to
work "now" :-)



Unfortunately that stupid bugtracker seems to be broken, here what I get
when I press the button to send the "Post Comment" button:

Error

 http://www.w3.org/1999/xhtml; xml:lang="en"
lang="en" dir="ltr">   Error:
Launchpad system errorvar LP = { cache: {}, links: {} }; 
var cookie_scope = '; Path=/; Secure;
Domain=.launchpad.net'; 
 var raw = null; if (LP.devmode) { raw =
'raw'; } YUI.GlobalConfig = { combine: true, comboBase:
'/+combo/rev18343/?', root: 'yui/', filter: raw, debug: false, fetchCSS:
false, maxURLLength: 2000, groups: { lp: { combine: true, base:
'/+combo/rev18343/?lp/', comboBase: '/+combo/rev18343/?', root: 'lp/',
// comes from including lp/meta.js modules: LP_MODULES, fetchCSS: false
} } }  // we need this to create
a single YUI instance all events and code // talks across. All instances
of YUI().use should be based off of // LPJS instead. LPJS = new YUI();
 
//   //): ' + e); }); } break; } } }
function selectWidget(widget_name, event) { if (event && (event.keyCode
=== 9 || event.keyCode === 13)) { // Avoid firing if user is tabbing
through or simply pressing // enter to submit the form. return; }
document.getElementById(widget_name).checked = true; } //]]> 
 http://schema.org/WebPage; class="tab-unknown main_only public
yui3-skin-sam">  Thomas Eschenbacher
(thomas-eschenbacher)   Launchpad.net

 

  No
REFERER Header Launchpad requires a
REFERER header to perform this action. There is no
REFERER header present. This can be caused by configuring
your browser to block REFERER headers. Unblock
REFERER headers for launchpad.net and try again, or see https://answers.launchpad.net/launchpad/+faq/1024;>the FAQ Why
does Launchpad require a REFERER header? for more
information. You can also join the #launchpad IRC support
channel on chat.freenode.net for further assistance. 
   https://launchpad.net/;>
 https://launchpad.net/+tour;>Take the
tour  https://help.launchpad.net/;>Read
the guide  https://launchpad.net/+search;>  
 2004-2016 http://canonical.com/;>CanonicalLtd. 
https://launchpad.net/legal;>Terms of use
 Contact Launchpad Support
 http://blog.launchpad.net/;>Blog
 http://www.canonical.com/about-canonical/careers;>Careers
 https://twitter.com/launchpadstatus;>System
status   r18343 (https://dev.launchpad.net/;>Get the code!)  
  LP.links['me'] =
'/~thomas-eschenbacher'; LP.cache = {"related_features": {}};
  

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

Title:
  qemu-system-ppc: no keyboard after savevm/loadvm

Status in QEMU:
  Incomplete

Bug description:
  Here the steps to reproduce:

  1. qemu-img create -f qcow2 test.qcow2 100M
  2. qemu-system-ppc -m 1024 -hda test.qcow2
  3. change to the console via Ctrl-Alt-2 and save a snapshot: