[Qemu-devel] [RFC 1/5] pci: Rename root bus initialization functions for clarity

2017-10-03 Thread David Gibson
pci_bus_init(), pci_bus_new_inplace(), pci_bus_new() and pci_register_bus()
are misleadingly named.  They're not used for initializing *any* PCI bus,
but only for a root PCI bus.

Non-root buses - i.e. ones under a logical PCI to PCI bridge - are instead
created with a direct qbus_create_inplace() (see pci_bridge_initfn()).

This patch renames the functions to make it clear they're only used for
a root bus.

Signed-off-by: David Gibson 
---
 hw/alpha/typhoon.c  |  8 +++
 hw/mips/gt64xxx_pci.c   | 12 +-
 hw/pci-bridge/pci_expander_bridge.c |  4 ++--
 hw/pci-host/apb.c   | 10 
 hw/pci-host/bonito.c|  8 +++
 hw/pci-host/gpex.c  |  6 ++---
 hw/pci-host/grackle.c   | 14 +--
 hw/pci-host/piix.c  |  4 ++--
 hw/pci-host/ppce500.c   |  6 ++---
 hw/pci-host/prep.c  |  4 ++--
 hw/pci-host/q35.c   |  7 +++---
 hw/pci-host/uninorth.c  | 24 +--
 hw/pci-host/versatile.c |  6 ++---
 hw/pci-host/xilinx-pcie.c   |  6 ++---
 hw/pci/pci.c| 48 +++--
 hw/ppc/ppc4xx_pci.c |  6 ++---
 hw/ppc/spapr_pci.c  |  8 +++
 hw/s390x/s390-pci-bus.c |  8 +++
 hw/sh4/sh_pci.c | 12 +-
 include/hw/pci/pci.h| 25 +--
 20 files changed, 115 insertions(+), 111 deletions(-)

diff --git a/hw/alpha/typhoon.c b/hw/alpha/typhoon.c
index ae11e012c7..6a40869488 100644
--- a/hw/alpha/typhoon.c
+++ b/hw/alpha/typhoon.c
@@ -881,10 +881,10 @@ PCIBus *typhoon_init(ram_addr_t ram_size, ISABus 
**isa_bus,
 memory_region_add_subregion(addr_space, 0x801fc00ULL,
 &s->pchip.reg_io);
 
-b = pci_register_bus(dev, "pci",
- typhoon_set_irq, sys_map_irq, s,
- &s->pchip.reg_mem, &s->pchip.reg_io,
- 0, 64, TYPE_PCI_BUS);
+b = pci_register_root_bus(dev, "pci",
+  typhoon_set_irq, sys_map_irq, s,
+  &s->pchip.reg_mem, &s->pchip.reg_io,
+  0, 64, TYPE_PCI_BUS);
 phb->bus = b;
 qdev_init_nofail(dev);
 
diff --git a/hw/mips/gt64xxx_pci.c b/hw/mips/gt64xxx_pci.c
index 5a9dad9aae..a9c222a967 100644
--- a/hw/mips/gt64xxx_pci.c
+++ b/hw/mips/gt64xxx_pci.c
@@ -1171,12 +1171,12 @@ PCIBus *gt64120_register(qemu_irq *pic)
 phb = PCI_HOST_BRIDGE(dev);
 memory_region_init(&d->pci0_mem, OBJECT(dev), "pci0-mem", UINT32_MAX);
 address_space_init(&d->pci0_mem_as, &d->pci0_mem, "pci0-mem");
-phb->bus = pci_register_bus(dev, "pci",
-gt64120_pci_set_irq, gt64120_pci_map_irq,
-pic,
-&d->pci0_mem,
-get_system_io(),
-PCI_DEVFN(18, 0), 4, TYPE_PCI_BUS);
+phb->bus = pci_register_root_bus(dev, "pci",
+ gt64120_pci_set_irq, gt64120_pci_map_irq,
+ pic,
+ &d->pci0_mem,
+ get_system_io(),
+ PCI_DEVFN(18, 0), 4, TYPE_PCI_BUS);
 qdev_init_nofail(dev);
 memory_region_init_io(&d->ISD_mem, OBJECT(dev), &isd_mem_ops, d, 
"isd-mem", 0x1000);
 
diff --git a/hw/pci-bridge/pci_expander_bridge.c 
b/hw/pci-bridge/pci_expander_bridge.c
index 8c8ac737ad..b2fa829e29 100644
--- a/hw/pci-bridge/pci_expander_bridge.c
+++ b/hw/pci-bridge/pci_expander_bridge.c
@@ -230,9 +230,9 @@ static void pxb_dev_realize_common(PCIDevice *dev, bool 
pcie, Error **errp)
 
 ds = qdev_create(NULL, TYPE_PXB_HOST);
 if (pcie) {
-bus = pci_bus_new(ds, dev_name, NULL, NULL, 0, TYPE_PXB_PCIE_BUS);
+bus = pci_root_bus_new(ds, dev_name, NULL, NULL, 0, TYPE_PXB_PCIE_BUS);
 } else {
-bus = pci_bus_new(ds, "pxb-internal", NULL, NULL, 0, TYPE_PXB_BUS);
+bus = pci_root_bus_new(ds, "pxb-internal", NULL, NULL, 0, 
TYPE_PXB_BUS);
 bds = qdev_create(BUS(bus), "pci-bridge");
 bds->id = dev_name;
 qdev_prop_set_uint8(bds, PCI_BRIDGE_DEV_PROP_CHASSIS_NR, pxb->bus_nr);
diff --git a/hw/pci-host/apb.c b/hw/pci-host/apb.c
index 1edf57f600..20c4be36ff 100644
--- a/hw/pci-host/apb.c
+++ b/hw/pci-host/apb.c
@@ -689,11 +689,11 @@ PCIBus *pci_apb_init(hwaddr special_base,
 dev = qdev_create(NULL, TYPE_APB);
 d = APB_DEVICE(dev);
 phb = PCI_HOST_BRIDGE(dev);
-phb->bus = pci_register_bus(DEVICE(phb), "pci",
-pci_apb_set_irq, pci_pbm_map_irq, d,
-&d->pci_mmio,
-get_system_io(),
-0, 32, TYPE_PCI_BUS);
+

[Qemu-devel] [RFC 3/5] pci: Fold pci_bus.h into pci.h

2017-10-03 Thread David Gibson
include/hw/pci/pci_bus.h is now very small and can only safely be included
after hw/pci/pci.h.  So, just fold it into pci.h.

Signed-off-by: David Gibson 
---
 hw/acpi/pcihp.c |  1 -
 hw/i386/acpi-build.c|  1 -
 hw/i386/amd_iommu.h |  1 -
 hw/i386/intel_iommu.c   |  1 -
 hw/i386/pc.c|  1 -
 hw/isa/lpc_ich9.c   |  1 -
 hw/pci-bridge/dec.c |  1 -
 hw/pci-bridge/pci_bridge_dev.c  |  1 -
 hw/pci-bridge/pci_expander_bridge.c |  1 -
 hw/pci-bridge/pcie_pci_bridge.c |  1 -
 hw/pci-host/apb.c   |  1 -
 hw/pci-host/prep.c  |  1 -
 hw/pci-host/versatile.c |  1 -
 hw/pci/pci.c|  1 -
 hw/pci/pci_bridge.c |  1 -
 hw/pci/pci_host.c   |  1 -
 hw/pci/pcie.c   |  1 -
 hw/pci/pcie_aer.c   |  1 -
 hw/pci/shpc.c   |  1 -
 hw/ppc/spapr_pci.c  |  1 -
 hw/s390x/s390-pci-bus.c |  1 -
 include/hw/i386/ich9.h  |  1 -
 include/hw/pci/pci.h| 44 --
 include/hw/pci/pci_bridge.h |  1 -
 include/hw/pci/pci_bus.h| 47 -
 include/hw/pci/pcie_port.h  |  1 -
 26 files changed, 42 insertions(+), 73 deletions(-)
 delete mode 100644 include/hw/pci/pci_bus.h

diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
index 7da51c0569..0da905ab3a 100644
--- a/hw/acpi/pcihp.c
+++ b/hw/acpi/pcihp.c
@@ -34,7 +34,6 @@
 #include "sysemu/sysemu.h"
 #include "exec/ioport.h"
 #include "exec/address-spaces.h"
-#include "hw/pci/pci_bus.h"
 #include "qapi/error.h"
 #include "qom/qom-qobject.h"
 
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 2af37a9129..6ad54e1e5b 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -51,7 +51,6 @@
 #include "hw/acpi/piix4.h"
 #include "hw/acpi/pcihp.h"
 #include "hw/i386/ich9.h"
-#include "hw/pci/pci_bus.h"
 #include "hw/pci-host/q35.h"
 #include "hw/i386/x86-iommu.h"
 
diff --git a/hw/i386/amd_iommu.h b/hw/i386/amd_iommu.h
index d370ae3549..b587f6b49f 100644
--- a/hw/i386/amd_iommu.h
+++ b/hw/i386/amd_iommu.h
@@ -27,7 +27,6 @@
 #include "hw/sysbus.h"
 #include "sysemu/dma.h"
 #include "hw/i386/pc.h"
-#include "hw/pci/pci_bus.h"
 #include "hw/i386/x86-iommu.h"
 
 /* Capability registers */
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 3a5bb0bc2e..3ef4bfbe05 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -26,7 +26,6 @@
 #include "exec/address-spaces.h"
 #include "intel_iommu_internal.h"
 #include "hw/pci/pci.h"
-#include "hw/pci/pci_bus.h"
 #include "hw/i386/pc.h"
 #include "hw/i386/apic-msidef.h"
 #include "hw/boards.h"
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 05985d4927..5fd778a627 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -31,7 +31,6 @@
 #include "hw/block/fdc.h"
 #include "hw/ide.h"
 #include "hw/pci/pci.h"
-#include "hw/pci/pci_bus.h"
 #include "hw/nvram/fw_cfg.h"
 #include "hw/timer/hpet.h"
 #include "hw/smbios/smbios.h"
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index 39f56ba44e..7b4ebbc0c7 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -44,7 +44,6 @@
 #include "hw/i386/ich9.h"
 #include "hw/acpi/acpi.h"
 #include "hw/acpi/ich9.h"
-#include "hw/pci/pci_bus.h"
 #include "exec/address-spaces.h"
 #include "sysemu/sysemu.h"
 #include "qom/cpu.h"
diff --git a/hw/pci-bridge/dec.c b/hw/pci-bridge/dec.c
index 84492d5e5f..ae4b9697ed 100644
--- a/hw/pci-bridge/dec.c
+++ b/hw/pci-bridge/dec.c
@@ -29,7 +29,6 @@
 #include "hw/pci/pci.h"
 #include "hw/pci/pci_host.h"
 #include "hw/pci/pci_bridge.h"
-#include "hw/pci/pci_bus.h"
 
 /* debug DEC */
 //#define DEBUG_DEC
diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c
index d56f6638c2..bc3c8d9f57 100644
--- a/hw/pci-bridge/pci_bridge_dev.c
+++ b/hw/pci-bridge/pci_bridge_dev.c
@@ -27,7 +27,6 @@
 #include "hw/pci/shpc.h"
 #include "hw/pci/slotid_cap.h"
 #include "exec/memory.h"
-#include "hw/pci/pci_bus.h"
 #include "hw/hotplug.h"
 
 #define TYPE_PCI_BRIDGE_DEV  "pci-bridge"
diff --git a/hw/pci-bridge/pci_expander_bridge.c 
b/hw/pci-bridge/pci_expander_bridge.c
index b2fa829e29..5652cf06e9 100644
--- a/hw/pci-bridge/pci_expander_bridge.c
+++ b/hw/pci-bridge/pci_expander_bridge.c
@@ -13,7 +13,6 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
 #include "hw/pci/pci.h"
-#include "hw/pci/pci_bus.h"
 #include "hw/pci/pci_host.h"
 #include "hw/pci/pci_bridge.h"
 #include "hw/i386/pc.h"
diff --git a/hw/pci-bridge/pcie_pci_bridge.c b/hw/pci-bridge/pcie_pci_bridge.c
index 88db143633..85fd053fbd 100644
--- a/hw/pci-bridge/pcie_pci_bridge.c
+++ b/hw/pci-bridge/pcie_pci_bridge.c
@@ -10,7 +10,6 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
 #include "hw/pci/pci.h"
-#include "hw/pci/pci_bus.h"
 #include "hw/pci/pci_bridge.h"
 #include "hw/pci/msi.h"

[Qemu-devel] [RFC 4/5] pci: Simplify pci_bus_is_root()

2017-10-03 Thread David Gibson
pci_bus_is_root() currently relies on a method in the PCIBusClass.
But it's always known if a PCI bus is a root bus when we create it, so
using a dynamic method is overkill.

This replaces it with an IS_ROOT bit in a new flags field, which is set on
root buses and otherwise clear.  As a bonus this removes the special
is_root logic from pci_expander_bridge, since it already creates its bus
as a root bus.

Signed-off-by: David Gibson 

# Conflicts:
#   include/hw/pci/pci_bus.h
---
 hw/pci-bridge/pci_expander_bridge.c |  6 --
 hw/pci/pci.c| 14 ++
 include/hw/pci/pci.h| 12 +++-
 3 files changed, 13 insertions(+), 19 deletions(-)

diff --git a/hw/pci-bridge/pci_expander_bridge.c 
b/hw/pci-bridge/pci_expander_bridge.c
index 5652cf06e9..11dfa9258e 100644
--- a/hw/pci-bridge/pci_expander_bridge.c
+++ b/hw/pci-bridge/pci_expander_bridge.c
@@ -65,11 +65,6 @@ static int pxb_bus_num(PCIBus *bus)
 return pxb->bus_nr;
 }
 
-static bool pxb_is_root(PCIBus *bus)
-{
-return true; /* by definition */
-}
-
 static uint16_t pxb_bus_numa_node(PCIBus *bus)
 {
 PXBDev *pxb = convert_to_pxb(bus->parent_dev);
@@ -82,7 +77,6 @@ static void pxb_bus_class_init(ObjectClass *class, void *data)
 PCIBusClass *pbc = PCI_BUS_CLASS(class);
 
 pbc->bus_num = pxb_bus_num;
-pbc->is_root = pxb_is_root;
 pbc->numa_node = pxb_bus_numa_node;
 }
 
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index ffaa449ec1..4baf591562 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -126,14 +126,9 @@ static void pci_bus_unrealize(BusState *qbus, Error **errp)
 vmstate_unregister(NULL, &vmstate_pcibus, bus);
 }
 
-static bool pcibus_is_root(PCIBus *bus)
-{
-return !bus->parent_dev;
-}
-
 static int pcibus_num(PCIBus *bus)
 {
-if (pcibus_is_root(bus)) {
+if (pci_bus_is_root(bus)) {
 return 0; /* pci host bridge */
 }
 return bus->parent_dev->config[PCI_SECONDARY_BUS];
@@ -156,7 +151,6 @@ static void pci_bus_class_init(ObjectClass *klass, void 
*data)
 k->unrealize = pci_bus_unrealize;
 k->reset = pcibus_reset;
 
-pbc->is_root = pcibus_is_root;
 pbc->bus_num = pcibus_num;
 pbc->numa_node = pcibus_numa_node;
 }
@@ -385,6 +379,7 @@ static void pci_root_bus_init(PCIBus *bus, DeviceState 
*parent,
 bus->slot_reserved_mask = 0x0;
 bus->address_space_mem = address_space_mem;
 bus->address_space_io = address_space_io;
+bus->flags |= PCI_BUS_IS_ROOT;
 
 /* host bridge */
 QLIST_INIT(&bus->child);
@@ -397,11 +392,6 @@ bool pci_bus_is_express(PCIBus *bus)
 return object_dynamic_cast(OBJECT(bus), TYPE_PCIE_BUS);
 }
 
-bool pci_bus_is_root(PCIBus *bus)
-{
-return PCI_BUS_GET_CLASS(bus)->is_root(bus);
-}
-
 void pci_root_bus_new_inplace(PCIBus *bus, size_t bus_size, DeviceState 
*parent,
   const char *name,
   MemoryRegion *address_space_mem,
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index 77d92a3dc4..cbb3386207 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -404,6 +404,11 @@ typedef AddressSpace *(*PCIIOMMUFunc)(PCIBus *, void *, 
int);
 #define PCI_BUS_GET_CLASS(obj) OBJECT_GET_CLASS(PCIBusClass, (obj), 
TYPE_PCI_BUS)
 #define TYPE_PCIE_BUS "PCIE"
 
+enum PCIBusFlags {
+/* This bus is the root of a PCI domain */
+PCI_BUS_IS_ROOT = 0x0001,
+};
+
 typedef struct PCIBusClass {
 /*< private >*/
 BusClass parent_class;
@@ -416,6 +421,7 @@ typedef struct PCIBusClass {
 
 struct PCIBus {
 BusState qbus;
+enum PCIBusFlags flags;
 PCIIOMMUFunc iommu_fn;
 void *iommu_opaque;
 uint8_t devfn_min;
@@ -440,8 +446,12 @@ struct PCIBus {
 Notifier machine_done;
 };
 
+static inline bool pci_bus_is_root(PCIBus *bus)
+{
+return !!(bus->flags & PCI_BUS_IS_ROOT);
+}
+
 bool pci_bus_is_express(PCIBus *bus);
-bool pci_bus_is_root(PCIBus *bus);
 void pci_root_bus_new_inplace(PCIBus *bus, size_t bus_size, DeviceState 
*parent,
   const char *name,
   MemoryRegion *address_space_mem,
-- 
2.13.6




Re: [Qemu-devel] [PATCH 10/38] m68k: an5206: use generic cpu_model parsing

2017-10-03 Thread Thomas Huth
On 02.10.2017 11:07, Igor Mammedov wrote:
> Signed-off-by: Igor Mammedov 
> ---
> CC: h...@tuxfamily.org
> CC: laur...@vivier.eu
> ---
>  hw/m68k/an5206.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/m68k/an5206.c b/hw/m68k/an5206.c
> index 9002c46..0cedc54 100644
> --- a/hw/m68k/an5206.c
> +++ b/hw/m68k/an5206.c
> @@ -28,7 +28,6 @@
>  static void an5206_init(MachineState *machine)
>  {
>  ram_addr_t ram_size = machine->ram_size;
> -const char *cpu_model = machine->cpu_model;
>  const char *kernel_filename = machine->kernel_filename;
>  M68kCPU *cpu;
>  CPUM68KState *env;
> @@ -39,10 +38,7 @@ static void an5206_init(MachineState *machine)
>  MemoryRegion *ram = g_new(MemoryRegion, 1);
>  MemoryRegion *sram = g_new(MemoryRegion, 1);
>  
> -if (!cpu_model) {
> -cpu_model = "m5206";
> -}
> -cpu = M68K_CPU(cpu_generic_init(TYPE_M68K_CPU, cpu_model));
> +cpu = M68K_CPU(cpu_create(machine->cpu_type));
>  env = &cpu->env;
>  
>  /* Initialize CPU registers.  */
> @@ -94,6 +90,7 @@ static void an5206_machine_init(MachineClass *mc)
>  {
>  mc->desc = "Arnewsh 5206";
>  mc->init = an5206_init;
> +mc->default_cpu_type = M68K_CPU_TYPE_NAME("m5206");
>  }
>  
>  DEFINE_MACHINE("an5206", an5206_machine_init)
> 

Acked-by: Thomas Huth 



Re: [Qemu-devel] [PATCH 0/3] blockjobs: add explicit job culling

2017-10-03 Thread Vladimir Sementsov-Ogievskiy

03.10.2017 06:15, John Snow wrote:

For jobs that complete when a monitor isn't looking, there's no way to
tell what the job's final return code was. We need to allow jobs to
remain in the list until queried for reliable management.

This is an RFC; tests are on the way.
(Tested only manually via qmp-shell for now.)


That's a cool feature!
What about transactions support?



John Snow (3):
   blockjob: add manual-cull property
   qmp: add block-job-cull command
   blockjob: expose manual-cull property

  block/backup.c   | 20 +-
  block/commit.c   |  2 +-
  block/mirror.c   |  2 +-
  block/replication.c  |  5 +++--
  block/stream.c   |  2 +-
  block/trace-events   |  1 +
  blockdev.c   | 28 +
  blockjob.c   | 46 +++--
  include/block/block_int.h|  8 +---
  include/block/blockjob.h | 21 +++
  include/block/blockjob_int.h |  2 +-
  qapi/block-core.json | 49 
  tests/test-blockjob-txn.c|  2 +-
  tests/test-blockjob.c|  2 +-
  14 files changed, 155 insertions(+), 35 deletions(-)




--
Best regards,
Vladimir




Re: [Qemu-devel] [RFC PATCH qemu v2] ppc/spapr: Receive and store device tree blob from SLOF

2017-10-03 Thread David Gibson
On Tue, Oct 03, 2017 at 07:48:27PM +1100, Alexey Kardashevskiy wrote:
> On 03/10/17 17:40, David Gibson wrote:
> > On Tue, Oct 03, 2017 at 04:17:01PM +1100, Alexey Kardashevskiy wrote:
> >> SLOF receives a device tree and updates it with various properties
> >> before switching to the guest kernel and QEMU is not aware of any changes
> >> made by SLOF. Since there is no real RTAS and QEMU implements it,
> >> it makes sense to pass the SLOF device tree to QEMU so the latter could
> >> implement RTAS related tasks better.
> >>
> >> Specifially, now QEMU can find out the actual XICS phandle (for PHB
> >> hotplug) and the RTAS linux,rtas-entry/base properties (for firmware
> >> assisted NMI - FWNMI).
> >>
> >> This stores the initial DT blob in the sPAPR machine and replaces it
> >> in the KVMPPC_H_UPDATE_DT (new private hypercall) handler.
> >>
> >> This implements a very basic validity check of the new blob - magic and
> >> size are checked; the new blob size should not increase more than twice.
> >>
> >> This requires SLOF update: "fdt: Pass the resulting device tree to QEMU".
> >>
> >> Signed-off-by: Alexey Kardashevskiy 
> >> ---
> >>
> >> I could store just a size of the QEMU's blob, or a tree, not sure
> >> which one makes more sense here.
> >>
> >> This allows up to 2 times blob increase. Not 1.5 just to avoid
> >> float/double, just looks a bit ugly imho.
> >> ---
> >>  include/hw/ppc/spapr.h |  4 +++-
> >>  hw/ppc/spapr.c |  4 +++-
> >>  hw/ppc/spapr_hcall.c   | 33 +
> >>  hw/ppc/trace-events|  2 ++
> >>  4 files changed, 41 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> >> index a805b817a5..09f3a54dc2 100644
> >> --- a/include/hw/ppc/spapr.h
> >> +++ b/include/hw/ppc/spapr.h
> >> @@ -92,6 +92,7 @@ struct sPAPRMachineState {
> >>  int vrma_adjust;
> >>  ssize_t rtas_size;
> >>  void *rtas_blob;
> >> +void *fdt_blob;
> >>  long kernel_size;
> >>  bool kernel_le;
> >>  uint32_t initrd_base;
> >> @@ -400,7 +401,8 @@ struct sPAPRMachineState {
> >>  #define KVMPPC_H_LOGICAL_MEMOP  (KVMPPC_HCALL_BASE + 0x1)
> >>  /* Client Architecture support */
> >>  #define KVMPPC_H_CAS(KVMPPC_HCALL_BASE + 0x2)
> >> -#define KVMPPC_HCALL_MAXKVMPPC_H_CAS
> >> +#define KVMPPC_H_UPDATE_DT  (KVMPPC_HCALL_BASE + 0x3)
> >> +#define KVMPPC_HCALL_MAXKVMPPC_H_UPDATE_DT
> >>  
> >>  typedef struct sPAPRDeviceTreeUpdateHeader {
> >>  uint32_t version_id;
> >> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> >> index 17ea77618c..b471f7e1ff 100644
> >> --- a/hw/ppc/spapr.c
> >> +++ b/hw/ppc/spapr.c
> >> @@ -1453,7 +1453,9 @@ static void ppc_spapr_reset(void)
> >>  /* Load the fdt */
> >>  qemu_fdt_dumpdtb(fdt, fdt_totalsize(fdt));
> >>  cpu_physical_memory_write(fdt_addr, fdt, fdt_totalsize(fdt));
> >> -g_free(fdt);
> >> +g_free(spapr->fdt_blob);
> >> +spapr->fdt_blob = fdt;
> >> +spapr->fdt_size = fdt_totalsize(fdt);
> >>  
> >>  /* Set up the entry state */
> >>  first_ppc_cpu = POWERPC_CPU(first_cpu);
> >> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> >> index 57bb411394..a11831d3b2 100644
> >> --- a/hw/ppc/spapr_hcall.c
> >> +++ b/hw/ppc/spapr_hcall.c
> >> @@ -1635,6 +1635,37 @@ static target_ulong 
> >> h_client_architecture_support(PowerPCCPU *cpu,
> >>  return H_SUCCESS;
> >>  }
> >>  
> >> +static target_ulong h_update_dt(PowerPCCPU *cpu, sPAPRMachineState *spapr,
> >> +target_ulong opcode, target_ulong *args)
> >> +{
> >> +target_ulong dt = ppc64_phys_to_real(args[0]);
> >> +struct fdt_header hdr = { 0 };
> >> +unsigned cb, magic, old_cb = fdt_totalsize(spapr->fdt_blob);
> >> +
> >> +cpu_physical_memory_read(dt, &hdr, sizeof(hdr));
> >> +cb = fdt32_to_cpu(hdr.totalsize);
> >> +magic = fdt32_to_cpu(hdr.magic);
> >> +if (magic != FDT_MAGIC || cb / old_cb > 2) {
> > 
> > Uh.. no.  This prevents the guest from gobbling arbitrary amounts of
> > qemu RAM _in one go_, but it can still call h_update_dt arbitrarily
> > often, doubling the amount of memory consumed each time.
> > 
> > You need to compare the updated DT size with the _original_ DT size,
> > not just the last DT size.
> 
> 
> Ah, right. Does it still make sense to store the original DT in the
> machine?

I think so.  Doing so will probably make the fallback easier where we
use the original tree we gave to the guest, if h_update_dt was never
called.

> >> +trace_spapr_update_dt_failed(old_cb, cb, magic);
> >> +return H_PARAMETER;
> >> +}
> > 
> > Still needs more sanity checks here.  At least check version and that
> > each of the sub-blocks fits correctly within totalsize.
> > 
> > Maybe I should add an fdt_fsck() function to libfdt, hmm...
> 
> 
> ookay, I just assumed libfdt checks for subblock sizes.

Well.. it does.  Or at least should.  But for something so basic, I'd
prefe

Re: [Qemu-devel] [PATCH 11/38] m68k: mcf5208: use generic cpu_model parsing

2017-10-03 Thread Thomas Huth
On 02.10.2017 11:07, Igor Mammedov wrote:
> Signed-off-by: Igor Mammedov 
> ---
> CC: laur...@vivier.eu
> CC: h...@tuxfamily.org
> ---
>  hw/m68k/mcf5208.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c
> index b9dde75..cfac845 100644
> --- a/hw/m68k/mcf5208.c
> +++ b/hw/m68k/mcf5208.c
> @@ -217,7 +217,6 @@ static void mcf_fec_init(MemoryRegion *sysmem, NICInfo 
> *nd, hwaddr base,
>  static void mcf5208evb_init(MachineState *machine)
>  {
>  ram_addr_t ram_size = machine->ram_size;
> -const char *cpu_model = machine->cpu_model;
>  const char *kernel_filename = machine->kernel_filename;
>  M68kCPU *cpu;
>  CPUM68KState *env;
> @@ -229,10 +228,7 @@ static void mcf5208evb_init(MachineState *machine)
>  MemoryRegion *ram = g_new(MemoryRegion, 1);
>  MemoryRegion *sram = g_new(MemoryRegion, 1);
>  
> -if (!cpu_model) {
> -cpu_model = "m5208";
> -}
> -cpu = M68K_CPU(cpu_generic_init(TYPE_M68K_CPU, cpu_model));
> +cpu = M68K_CPU(cpu_create(machine->cpu_type));
>  env = &cpu->env;
>  
>  /* Initialize CPU registers.  */
> @@ -321,6 +317,7 @@ static void mcf5208evb_machine_init(MachineClass *mc)
>  mc->desc = "MCF5206EVB";
>  mc->init = mcf5208evb_init;
>  mc->is_default = 1;
> +mc->default_cpu_type = M68K_CPU_TYPE_NAME("m5208");
>  }
>  
>  DEFINE_MACHINE("mcf5208evb", mcf5208evb_machine_init)
> 

Acked-by: Thomas Huth 



Re: [Qemu-devel] [PATCH v4 14/23] qemu-img: Speed up compare on pre-allocated larger file

2017-10-03 Thread Vladimir Sementsov-Ogievskiy

13.09.2017 19:03, Eric Blake wrote:

Compare the following images with all-zero contents:
$ truncate --size 1M A
$ qemu-img create -f qcow2 -o preallocation=off B 1G
$ qemu-img create -f qcow2 -o preallocation=metadata C 1G

On my machine, the difference is noticeable for pre-patch speeds,
with more than an order of magnitude in difference caused by the
choice of preallocation in the qcow2 file:

$ time ./qemu-img compare -f raw -F qcow2 A B
Warning: Image size mismatch!
Images are identical.

real0m0.014s
user0m0.007s
sys 0m0.007s

$ time ./qemu-img compare -f raw -F qcow2 A C
Warning: Image size mismatch!
Images are identical.

real0m0.341s
user0m0.144s
sys 0m0.188s

Why? Because bdrv_is_allocated() returns false for image B but
true for image C, throwing away the fact that both images know
via lseek(SEEK_HOLE) that the entire image still reads as zero.
 From there, qemu-img ends up calling bdrv_pread() for every byte
of the tail, instead of quickly looking for the next allocation.
The solution: use block_status instead of is_allocated, giving:

$ time ./qemu-img compare -f raw -F qcow2 A C
Warning: Image size mismatch!
Images are identical.

real0m0.014s
user0m0.011s
sys 0m0.003s

which is on par with the speeds for no pre-allocation.

Signed-off-by: Eric Blake 

---
v3: new patch
---
  qemu-img.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/qemu-img.c b/qemu-img.c
index f8423e9b3f..f5ab29d176 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -1477,11 +1477,11 @@ static int img_compare(int argc, char **argv)
  while (sector_num < progress_base) {
  int64_t count;

-ret = bdrv_is_allocated_above(blk_bs(blk_over), NULL,
+ret = bdrv_block_status_above(blk_bs(blk_over), NULL,
sector_num * BDRV_SECTOR_SIZE,
(progress_base - sector_num) *
BDRV_SECTOR_SIZE,
-  &count);
+  &count, NULL);
  if (ret < 0) {
  ret = 3;
  error_report("Sector allocation test failed for %s",
@@ -1489,11 +1489,11 @@ static int img_compare(int argc, char **argv)
  goto out;

  }
-/* TODO relax this once bdrv_is_allocated_above does not enforce
+/* TODO relax this once bdrv_block_status_above does not enforce
   * sector alignment */
  assert(QEMU_IS_ALIGNED(count, BDRV_SECTOR_SIZE));
  nb_sectors = count >> BDRV_SECTOR_BITS;
-if (ret) {
+if (ret & BDRV_BLOCK_ALLOCATED && !(ret & BDRV_BLOCK_ZERO)) {
  nb_sectors = MIN(nb_sectors, IO_BUF_SIZE >> BDRV_SECTOR_BITS);
  ret = check_empty_sectors(blk_over, sector_num, nb_sectors,
filename_over, buf1, quiet);


Reviewed-by: Vladimir Sementsov-Ogievskiy 

--
Best regards,
Vladimir



[Qemu-devel] [Bug 1321464] Re: qemu/block/qcow2.c:1942: possible performance problem ?

2017-10-03 Thread Thomas Huth
Thanks for reporting this, but it looks like the related code has been
removed a while ago (there is no more "pad_buf" in qcow.c or qcow2.c),
so closing this ticket. If you still can reproduce the (same or similar)
problem with the latest version of QEMU, please open a new ticket
instead.

** Changed in: qemu
   Status: New => Won't Fix

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

Title:
  qemu/block/qcow2.c:1942: possible performance problem ?

Status in QEMU:
  Won't Fix

Bug description:
  I just ran static analyser cppcheck over today (20140520) qemu source
  code.

  It said many things, including

  [qemu/block/qcow2.c:1942] -> [qemu/block/qcow2.c:1943]: (performance) Buffer 
'pad_buf' is being writ
  ten before its old content has been used.

  Source code is

  memset(pad_buf, 0, s->cluster_size);
  memcpy(pad_buf, buf, nb_sectors * BDRV_SECTOR_SIZE);

  Worth tuning ?

  Similar problem here

  [qemu/block/qcow.c:815] -> [qemu/block/qcow.c:816]: (performance) Buffer 
'pad_buf' is being written 
  before its old content has been used.

  and

  [qemu/hw/i386/acpi-build.c:1265] -> [qemu/hw/i386/acpi-build.c:1267]: 
(performance) Buffer 'dsdt' is
   being written before its old content has been used.

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



[Qemu-devel] [PATCH] hw/block/onenand: Remove dead code block

2017-10-03 Thread Thomas Huth
The condition of the for-loop makes sure that b is always smaller
than s->blocks, so the "if (b >= s->blocks)" statement is completely
superfluous here.

Buglink: https://bugs.launchpad.net/qemu/+bug/1715007
Signed-off-by: Thomas Huth 
---
 hw/block/onenand.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/hw/block/onenand.c b/hw/block/onenand.c
index 30e40f3..de65c9e 100644
--- a/hw/block/onenand.c
+++ b/hw/block/onenand.c
@@ -520,10 +520,6 @@ static void onenand_command(OneNANDState *s)
 s->intstatus |= ONEN_INT;
 
 for (b = 0; b < s->blocks; b ++) {
-if (b >= s->blocks) {
-s->status |= ONEN_ERR_CMD;
-break;
-}
 if (s->blockwp[b] == ONEN_LOCK_LOCKTIGHTEN)
 break;
 
-- 
1.8.3.1




Re: [Qemu-devel] [PATCH v1.1 DRAFT] nbd: Minimal structured read for client

2017-10-03 Thread Vladimir Sementsov-Ogievskiy

Eric?


27.09.2017 18:10, Vladimir Sementsov-Ogievskiy wrote:

Minimal implementation: drop most of additional error information.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---

Hi!

Here is a draft of how to refactor reply-payload receiving if you don't
like my previous simple (but not flexible) try. Ofcourse, if we agree on this
approach this patch should be splitted into several ones and many things
(error handling) should be improved.

The idea is:

nbd_read_reply_entry reads only reply header through nbd/client.c code.

Then, the payload is read through block/nbd-client-cmds.c:
simple payload: generic per-command handler, however it should only exist
   for CMD_READ
structured NONE: no payload, handle in nbd_co_receive_one_chunk
structured error: read by nbd_handle_structured_error_payload
   defined in block/nbd-client-cmds.c
structured success: read by per-[command X reply-type] handler
   defined in block/nbd-client-cmds.c

For now nbd-client-cmds.c looks more like nbd-payload.c, but, may be, we
should move command sending special-casing (CMD_WRITE) to it too..

Don't waste time on careful reviewing this patch, let's consider first
the concept of nbd-client-cmds.c,

  block/nbd-client.h  |  10 +++
  include/block/nbd.h |  82 --
  nbd/nbd-internal.h  |  25 --
  block/nbd-client-cmds.c | 220 
  block/nbd-client.c  | 118 --
  nbd/client.c| 128 
  block/Makefile.objs |   2 +-
  7 files changed, 475 insertions(+), 110 deletions(-)
  create mode 100644 block/nbd-client-cmds.c

diff --git a/block/nbd-client.h b/block/nbd-client.h
index b435754b82..abb88e4ea5 100644
--- a/block/nbd-client.h
+++ b/block/nbd-client.h
@@ -35,6 +35,8 @@ typedef struct NBDClientSession {
  NBDClientRequest requests[MAX_NBD_REQUESTS];
  NBDReply reply;
  bool quit;
+
+bool structured_reply;
  } NBDClientSession;
  
  NBDClientSession *nbd_get_client_session(BlockDriverState *bs);

@@ -60,4 +62,12 @@ void nbd_client_detach_aio_context(BlockDriverState *bs);
  void nbd_client_attach_aio_context(BlockDriverState *bs,
 AioContext *new_context);
  
+int nbd_handle_structured_payload(QIOChannel *ioc, int cmd,

+  NBDStructuredReplyChunk *reply, void 
*opaque);
+int nbd_handle_simple_payload(QIOChannel *ioc, int cmd, void *opaque);
+
+int nbd_handle_structured_error_payload(QIOChannel *ioc,
+NBDStructuredReplyChunk *reply,
+int *request_ret);
+
  #endif /* NBD_CLIENT_H */
diff --git a/include/block/nbd.h b/include/block/nbd.h
index 314f2f9bbc..b9a4e1dfa9 100644
--- a/include/block/nbd.h
+++ b/include/block/nbd.h
@@ -57,12 +57,6 @@ struct NBDRequest {
  };
  typedef struct NBDRequest NBDRequest;
  
-struct NBDReply {

-uint64_t handle;
-uint32_t error;
-};
-typedef struct NBDReply NBDReply;
-
  typedef struct NBDSimpleReply {
  uint32_t magic;  /* NBD_SIMPLE_REPLY_MAGIC */
  uint32_t error;
@@ -77,6 +71,24 @@ typedef struct NBDStructuredReplyChunk {
  uint32_t length; /* length of payload */
  } QEMU_PACKED NBDStructuredReplyChunk;
  
+typedef union NBDReply {

+NBDSimpleReply simple;
+NBDStructuredReplyChunk structured;
+struct {
+uint32_t magic;
+uint32_t _skip;
+uint64_t handle;
+} QEMU_PACKED;
+} NBDReply;
+
+#define NBD_SIMPLE_REPLY_MAGIC  0x67446698
+#define NBD_STRUCTURED_REPLY_MAGIC  0x668e33ef
+
+static inline bool nbd_reply_is_simple(NBDReply *reply)
+{
+return reply->magic == NBD_SIMPLE_REPLY_MAGIC;
+}
+
  typedef struct NBDStructuredRead {
  NBDStructuredReplyChunk h;
  uint64_t offset;
@@ -88,6 +100,11 @@ typedef struct NBDStructuredError {
  uint16_t message_length;
  } QEMU_PACKED NBDStructuredError;
  
+typedef struct NBDPayloadOffsetHole {

+uint64_t offset;
+uint32_t hole_size;
+} QEMU_PACKED NBDPayloadOffsetHole;
+
  /* Transmission (export) flags: sent from server to client during handshake,
 but describe what will happen during transmission */
  #define NBD_FLAG_HAS_FLAGS (1 << 0) /* Flags are there */
@@ -178,12 +195,54 @@ enum {
  
  #define NBD_SREP_TYPE_NONE  0

  #define NBD_SREP_TYPE_OFFSET_DATA   1
+#define NBD_SREP_TYPE_OFFSET_HOLE   2
  #define NBD_SREP_TYPE_ERROR NBD_SREP_ERR(1)
+#define NBD_SREP_TYPE_ERROR_OFFSET  NBD_SREP_ERR(2)
+
+static inline bool nbd_srep_type_is_error(int type)
+{
+return type & (1 << 15);
+}
+
+/* NBD errors are based on errno numbers, so there is a 1:1 mapping,
+ * but only a limited set of errno values is specified in the protocol.
+ * Everything else is squashed to EINVAL.
+ */
+#define NBD_SUCCESS0
+#define NBD_EPERM  1
+#define NBD_EIO5
+#define NBD_ENOMEM 12
+#define NBD_EINVAL 22
+#define NBD_ENOSPC 28
+#define NBD_

Re: [Qemu-devel] [PATCH v3 0/9] virtio: enhance virtio_error messages

2017-10-03 Thread Ladi Prosek
On Thu, Sep 14, 2017 at 7:59 AM, Ladi Prosek  wrote:
> On Fri, Jul 21, 2017 at 5:21 PM, Stefan Hajnoczi  wrote:
>> On Mon, Jul 17, 2017 at 10:11:43AM +0200, Ladi Prosek wrote:
>>> Output like "Virtqueue size exceeded" is not much useful in identifying the
>>> culprit. This series beefs up virtio_error to print the virtio device name
>>> and id, and introduces virtqueue_error which additionally includes the index
>>> of the virtqueue where the error occured.
>>>
>>> Patches 1 to 3 lay the groundwork, patches 4 to 8 convert virtio devices to
>>> use virtqueue_error instead of virtio_error. Patch 9 adds virtio_error and
>>> virtqueue_error to the list of error funcs in checkpatch.pl.
>>>
>>> v1->v2:
>>> * Modified virtio_error and added virtqueue_error (Stefan)
>>> * Now also printing device id (Stefan)
>>> * Went over all virtio_error call sites and converted them to 
>>> virtqueue_error
>>>   as appropriate; added virtio device maintainers to cc
>>>
>>> v2->v3:
>>> * Removed patch 1 (Stefan, Markus)
>>> * Split patch 3 into 2 (adds virtqueue_error) and 3 (makes virtio.c call it)
>>>   (Cornelia)
>>> * Added patch 9 to modify $qemu_error_funcs in checkpatch.pl (Greg)
>>> * s/includes queue index/includes the queue index/ in patch 3-9 commit
>>>   messages (Cornelia)
>>> * Fixed virtio_get_device_id to return empty string instead of NULL if the
>>>   device doesn't have an id (Stefan)
>>> * Simplified the change in virtio-crypto.c to use vcrypto->ctrl_vq instead
>>>   of propagating the vq pointer in function arguments (Cornelia, Gonglei)
>>>
>>> Ladi Prosek (9):
>>>   virtio: enhance virtio_error messages
>>>   virtio: introduce virtqueue_error
>>>   virtio: use virtqueue_error for errors with queue context
>>>   virtio-9p: use virtqueue_error for errors with queue context
>>>   virtio-blk: use virtqueue_error for errors with queue context
>>>   virtio-net: use virtqueue_error for errors with queue context
>>>   virtio-scsi: use virtqueue_error for errors with queue context
>>>   virtio-crypto: use virtqueue_error for errors with queue context
>>>   checkpatch: add virtio_error and virtqueue_error to error funcs
>>>
>>>  hw/9pfs/virtio-9p-device.c |  37 ++
>>>  hw/block/virtio-blk.c  |   6 +--
>>>  hw/net/virtio-net.c|  24 -
>>>  hw/scsi/virtio-scsi.c  |   2 +-
>>>  hw/virtio/virtio-crypto.c  |  49 ++-
>>>  hw/virtio/virtio.c | 119 
>>> +++--
>>>  include/hw/virtio/virtio.h |   1 +
>>>  scripts/checkpatch.pl  |   4 +-
>>>  8 files changed, 143 insertions(+), 99 deletions(-)
>>
>> Looks good.  QEMU is currently in freeze for the 2.10 release.  You may
>> need to resend so Michael Tsirkin can merge it after the release, or if
>> he maintainers a -next branch he could merge it right away.
>
> Should I resend the series, Michael?

Ping. The series applies cleanly on current master.



[Qemu-devel] [Bug 1660035] Re: hw/timer/altera_timer.c:207: bad size in memset ?

2017-10-03 Thread Thomas Huth
This problem should have been fixed with QEMU v2.10.0:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=cc16ee9d4ecec35ea04e

** Changed in: qemu
   Status: New => Fix Released

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

Title:
  hw/timer/altera_timer.c:207: bad size in memset ?

Status in QEMU:
  Fix Released

Bug description:
  hw/timer/altera_timer.c:207:5: warning: ‘memset’ used with length
  equal to number of elements without multiplication by element size
  [-Wmemset-elt-size]

  Source code is

   memset(t->regs, 0, ARRAY_SIZE(t->regs));

  Maybe better code

   memset(t->regs, 0, R_MAX * sizeof( uint32_t));

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



Re: [Qemu-devel] [Qemu-block] [PATCH 8/8] nbd: Minimal structured read for client

2017-10-03 Thread Paolo Bonzini
On 26/09/2017 00:19, Eric Blake wrote:
>> +/* here we deal with successful structured reply */
>> +switch (s->reply.type) {
>> +QEMUIOVector sub_qiov;
>> +case NBD_SREP_TYPE_OFFSET_DATA:
> This is putting a LOT of smarts directly into the receive routine.
> Here's where I was previously wondering (and I think Paolo as well)
> whether it might be better to split the efforts: the generic function
> reads off the chunk information and any payload, but a per-command
> callback function then parses the chunks.  Especially since the
> definition of the chunks differs on a per-command basis (yes, the NBD
> spec will try to not reuse an SREP chunk type across multiple commands
> unless the semantics are similar, but that's a bit more fragile).  This
> particularly matters given my statement above that you want a
> discriminated union, rather than a struct that contains unused fields,
> for handling different SREP chunk types.

I think there should be two kinds of replies: 1) read directly into a
QEMUIOVector, using structured replies only as an encapsulation of the
payload; 2) read a chunk at a time into malloc-ed memory, yielding back
to the calling coroutine after receiving one complete chunk.

In the end this probably means that you have a read_chunk_header
function and a read_chunk function.  READ has a loop that calls
read_chunk_header followed by direct reading into the QEMUIOVector,
while everyone else calls read_chunk.

Maybe qio_channel_readv/writev_full could have "offset" and "bytes"
arguments.  Most code in iov_send_recv could be cut-and-pasted.  (When
sheepdog is converted to QIOChannel, iov_send_recv can go away).

Paolo



[Qemu-devel] [PATCH] target/ppc: Remove unused PPC 460 and 460F definitions

2017-10-03 Thread Thomas Huth
We don't have any 460 or 460F CPUs in QEMU, so the init functions
are just dead code. Let's simply remove them (translate_init.c
is already big enough without them).

Signed-off-by: Thomas Huth 
---
 target/ppc/translate_init.c | 217 
 1 file changed, 217 deletions(-)

diff --git a/target/ppc/translate_init.c b/target/ppc/translate_init.c
index c6399a3..0d6379f 100644
--- a/target/ppc/translate_init.c
+++ b/target/ppc/translate_init.c
@@ -4176,223 +4176,6 @@ POWERPC_FAMILY(440x5wDFPU)(ObjectClass *oc, void *data)
  POWERPC_FLAG_DE | POWERPC_FLAG_BUS_CLK;
 }
 
-static void init_proc_460 (CPUPPCState *env)
-{
-/* Time base */
-gen_tbl(env);
-gen_spr_BookE(env, 0xULL);
-gen_spr_440(env);
-gen_spr_usprgh(env);
-/* Processor identification */
-spr_register(env, SPR_BOOKE_PIR, "PIR",
- SPR_NOACCESS, SPR_NOACCESS,
- &spr_read_generic, &spr_write_pir,
- 0x);
-/* XXX : not implemented */
-spr_register(env, SPR_BOOKE_IAC3, "IAC3",
- SPR_NOACCESS, SPR_NOACCESS,
- &spr_read_generic, &spr_write_generic,
- 0x);
-/* XXX : not implemented */
-spr_register(env, SPR_BOOKE_IAC4, "IAC4",
- SPR_NOACCESS, SPR_NOACCESS,
- &spr_read_generic, &spr_write_generic,
- 0x);
-/* XXX : not implemented */
-spr_register(env, SPR_BOOKE_DVC1, "DVC1",
- SPR_NOACCESS, SPR_NOACCESS,
- &spr_read_generic, &spr_write_generic,
- 0x);
-/* XXX : not implemented */
-spr_register(env, SPR_BOOKE_DVC2, "DVC2",
- SPR_NOACCESS, SPR_NOACCESS,
- &spr_read_generic, &spr_write_generic,
- 0x);
-/* XXX : not implemented */
-spr_register(env, SPR_BOOKE_MCSR, "MCSR",
- SPR_NOACCESS, SPR_NOACCESS,
- &spr_read_generic, &spr_write_generic,
- 0x);
-spr_register(env, SPR_BOOKE_MCSRR0, "MCSRR0",
- SPR_NOACCESS, SPR_NOACCESS,
- &spr_read_generic, &spr_write_generic,
- 0x);
-spr_register(env, SPR_BOOKE_MCSRR1, "MCSRR1",
- SPR_NOACCESS, SPR_NOACCESS,
- &spr_read_generic, &spr_write_generic,
- 0x);
-/* XXX : not implemented */
-spr_register(env, SPR_440_CCR1, "CCR1",
- SPR_NOACCESS, SPR_NOACCESS,
- &spr_read_generic, &spr_write_generic,
- 0x);
-/* XXX : not implemented */
-spr_register(env, SPR_DCRIPR, "SPR_DCRIPR",
- &spr_read_generic, &spr_write_generic,
- &spr_read_generic, &spr_write_generic,
- 0x);
-/* Memory management */
-#if !defined(CONFIG_USER_ONLY)
-env->nb_tlb = 64;
-env->nb_ways = 1;
-env->id_tlbs = 0;
-env->tlb_type = TLB_EMB;
-#endif
-init_excp_BookE(env);
-env->dcache_line_size = 32;
-env->icache_line_size = 32;
-/* XXX: TODO: allocate internal IRQ controller */
-
-SET_FIT_PERIOD(12, 16, 20, 24);
-SET_WDT_PERIOD(20, 24, 28, 32);
-}
-
-POWERPC_FAMILY(460)(ObjectClass *oc, void *data)
-{
-DeviceClass *dc = DEVICE_CLASS(oc);
-PowerPCCPUClass *pcc = POWERPC_CPU_CLASS(oc);
-
-dc->desc = "PowerPC 460 (guessed)";
-pcc->init_proc = init_proc_460;
-pcc->check_pow = check_pow_nocheck;
-pcc->insns_flags = PPC_INSNS_BASE | PPC_STRING |
-   PPC_DCR | PPC_DCRX  | PPC_DCRUX |
-   PPC_WRTEE | PPC_MFAPIDI | PPC_MFTB |
-   PPC_CACHE | PPC_CACHE_ICBI |
-   PPC_CACHE_DCBZ | PPC_CACHE_DCBA |
-   PPC_MEM_TLBSYNC | PPC_TLBIVA |
-   PPC_BOOKE | PPC_4xx_COMMON | PPC_405_MAC |
-   PPC_440_SPEC;
-pcc->msr_mask = (1ull << MSR_POW) |
-(1ull << MSR_CE) |
-(1ull << MSR_EE) |
-(1ull << MSR_PR) |
-(1ull << MSR_FP) |
-(1ull << MSR_ME) |
-(1ull << MSR_FE0) |
-(1ull << MSR_DWE) |
-(1ull << MSR_DE) |
-(1ull << MSR_FE1) |
-(1ull << MSR_IR) |
-(1ull << MSR_DR);
-pcc->mmu_model = POWERPC_MMU_BOOKE;
-pcc->excp_model = POWERPC_EXCP_BOOKE;
-pcc->bus_model = PPC_FLAGS_INPUT_BookE;
-pcc->bfd_mach = bfd_mach_ppc_403;
-pcc->flags = POWERPC_FLAG_CE | POWERPC_FLAG_DWE |
- POWERPC_FLAG_DE | POWERPC_FLAG_BUS_CLK;
-}
-
-static void init_proc_460F(CPUPPCState *env)
-{
-/* Time base */
-gen_tbl(env);
-gen_spr_BookE(env, 0xULL);
-gen_spr_440(env);
-gen_spr_usprgh(env);
-/* Processor identification */

Re: [Qemu-devel] [Qemu-trivial] [PATCH] hw/block/onenand: Remove dead code block

2017-10-03 Thread Laurent Vivier
On 03/10/2017 11:57, Thomas Huth wrote:
> The condition of the for-loop makes sure that b is always smaller
> than s->blocks, so the "if (b >= s->blocks)" statement is completely
> superfluous here.
> 
> Buglink: https://bugs.launchpad.net/qemu/+bug/1715007
> Signed-off-by: Thomas Huth 
> ---
>  hw/block/onenand.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/hw/block/onenand.c b/hw/block/onenand.c
> index 30e40f3..de65c9e 100644
> --- a/hw/block/onenand.c
> +++ b/hw/block/onenand.c
> @@ -520,10 +520,6 @@ static void onenand_command(OneNANDState *s)
>  s->intstatus |= ONEN_INT;
>  
>  for (b = 0; b < s->blocks; b ++) {
> -if (b >= s->blocks) {
> -s->status |= ONEN_ERR_CMD;
> -break;
> -}
>  if (s->blockwp[b] == ONEN_LOCK_LOCKTIGHTEN)
>  break;
>  
> 

Looks like a bad cut'n'paste from case 0x23.

Reviewed-by: Laurent Vivier 



[Qemu-devel] [PULL 3/6] linux-headers: sync against v4.14-rc1

2017-10-03 Thread Paolo Bonzini
From: Alexey Perevalov 

Signed-off-by: Alexey Perevalov 
Message-Id: <1506085187-24259-2-git-send-email-a.pereva...@samsung.com>
Signed-off-by: Paolo Bonzini 
---
 include/standard-headers/asm-x86/hyperv.h| 19 ++---
 include/standard-headers/linux/pci_regs.h| 42 
 include/standard-headers/linux/virtio_ring.h |  4 +--
 linux-headers/asm-s390/kvm.h |  6 
 linux-headers/linux/kvm.h|  3 +-
 linux-headers/linux/userfaultfd.h| 16 ++-
 6 files changed, 64 insertions(+), 26 deletions(-)

diff --git a/include/standard-headers/asm-x86/hyperv.h 
b/include/standard-headers/asm-x86/hyperv.h
index fac7651..5f95d5e 100644
--- a/include/standard-headers/asm-x86/hyperv.h
+++ b/include/standard-headers/asm-x86/hyperv.h
@@ -149,12 +149,9 @@
  */
 #define HV_X64_DEPRECATING_AEOI_RECOMMENDED(1 << 9)
 
-/*
- * HV_VP_SET available
- */
+/* Recommend using the newer ExProcessorMasks interface */
 #define HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED  (1 << 11)
 
-
 /*
  * Crash notification flag.
  */
@@ -242,7 +239,11 @@
(~((1ull << HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_SHIFT) - 1))
 
 /* Declare the various hypercall operations. */
+#define HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE 0x0002
+#define HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST  0x0003
 #define HVCALL_NOTIFY_LONG_SPIN_WAIT   0x0008
+#define HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX  0x0013
+#define HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX   0x0014
 #define HVCALL_POST_MESSAGE0x005c
 #define HVCALL_SIGNAL_EVENT0x005d
 
@@ -259,6 +260,16 @@
 #define HV_PROCESSOR_POWER_STATE_C22
 #define HV_PROCESSOR_POWER_STATE_C33
 
+#define HV_FLUSH_ALL_PROCESSORSBIT(0)
+#define HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACESBIT(1)
+#define HV_FLUSH_NON_GLOBAL_MAPPINGS_ONLY  BIT(2)
+#define HV_FLUSH_USE_EXTENDED_RANGE_FORMAT BIT(3)
+
+enum HV_GENERIC_SET_FORMAT {
+   HV_GENERIC_SET_SPARCE_4K,
+   HV_GENERIC_SET_ALL,
+};
+
 /* hypercall status code */
 #define HV_STATUS_SUCCESS  0
 #define HV_STATUS_INVALID_HYPERCALL_CODE   2
diff --git a/include/standard-headers/linux/pci_regs.h 
b/include/standard-headers/linux/pci_regs.h
index c22d3eb..f8d5804 100644
--- a/include/standard-headers/linux/pci_regs.h
+++ b/include/standard-headers/linux/pci_regs.h
@@ -513,6 +513,7 @@
 #define  PCI_EXP_DEVSTA_URD0x0008  /* Unsupported Request Detected */
 #define  PCI_EXP_DEVSTA_AUXPD  0x0010  /* AUX Power Detected */
 #define  PCI_EXP_DEVSTA_TRPND  0x0020  /* Transactions Pending */
+#define PCI_CAP_EXP_RC_ENDPOINT_SIZEOF_V1  12  /* v1 endpoints without 
link end here */
 #define PCI_EXP_LNKCAP 12  /* Link Capabilities */
 #define  PCI_EXP_LNKCAP_SLS0x000f /* Supported Link Speeds */
 #define  PCI_EXP_LNKCAP_SLS_2_5GB 0x0001 /* LNKCAP2 SLS Vector bit 0 */
@@ -556,7 +557,7 @@
 #define  PCI_EXP_LNKSTA_DLLLA  0x2000  /* Data Link Layer Link Active */
 #define  PCI_EXP_LNKSTA_LBMS   0x4000  /* Link Bandwidth Management Status */
 #define  PCI_EXP_LNKSTA_LABS   0x8000  /* Link Autonomous Bandwidth Status */
-#define PCI_CAP_EXP_ENDPOINT_SIZEOF_V1 20  /* v1 endpoints end here */
+#define PCI_CAP_EXP_ENDPOINT_SIZEOF_V1 20  /* v1 endpoints with link end 
here */
 #define PCI_EXP_SLTCAP 20  /* Slot Capabilities */
 #define  PCI_EXP_SLTCAP_ABP0x0001 /* Attention Button Present */
 #define  PCI_EXP_SLTCAP_PCP0x0002 /* Power Controller Present */
@@ -639,7 +640,7 @@
 #define  PCI_EXP_DEVCTL2_OBFF_MSGB_EN  0x4000  /* Enable OBFF Message type B */
 #define  PCI_EXP_DEVCTL2_OBFF_WAKE_EN  0x6000  /* OBFF using WAKE# signaling */
 #define PCI_EXP_DEVSTA242  /* Device Status 2 */
-#define PCI_CAP_EXP_ENDPOINT_SIZEOF_V2 44  /* v2 endpoints end here */
+#define PCI_CAP_EXP_RC_ENDPOINT_SIZEOF_V2  44  /* v2 endpoints without 
link end here */
 #define PCI_EXP_LNKCAP244  /* Link Capabilities 2 */
 #define  PCI_EXP_LNKCAP2_SLS_2_5GB 0x0002 /* Supported Speed 2.5GT/s */
 #define  PCI_EXP_LNKCAP2_SLS_5_0GB 0x0004 /* Supported Speed 5.0GT/s */
@@ -647,6 +648,7 @@
 #define  PCI_EXP_LNKCAP2_CROSSLINK 0x0100 /* Crosslink supported */
 #define PCI_EXP_LNKCTL248  /* Link Control 2 */
 #define PCI_EXP_LNKSTA250  /* Link Status 2 */
+#define PCI_CAP_EXP_ENDPOINT_SIZEOF_V2 52  /* v2 endpoints with link end 
here */
 #define PCI_EXP_SLTCAP252  /* Slot Capabilities 2 */
 #define PCI_EXP_SLTCTL256  /* Slot Control 2 */
 #define PCI_EXP_SLTSTA258  /* Slot Status 2 */
@@ -733,23 +735,17 @@
 #define  PCI_ERR_CAP_ECRC_CHKE 0x0100  /* ECRC Check Enable */
 #define PCI_ERR_HEADER_LOG 28  /* Header Log Register (16 bytes) */
 #define PCI_ERR_ROOT_COMMAND   44  

[Qemu-devel] [PULL 2/6] iothread: Make iothread_stop() idempotent

2017-10-03 Thread Paolo Bonzini
From: Eduardo Habkost 

Currently, iothread_stop_all() makes all iothread objects unsafe
to be destroyed, because qemu_thread_join() ends up being called
twice.

To fix this, make iothread_stop() idempotent by checking
thread->stopped.

Fixes the following crash:

  qemu-system-x86_64 -object iothread,id=iothread0 -monitor stdio -display none
  QEMU 2.10.50 monitor - type 'help' for more information
  (qemu) quit
  qemu: qemu_thread_join: No such process
  Aborted (core dumped)

Reported-by: Christian Borntraeger 
Signed-off-by: Eduardo Habkost 
Message-Id: <20170926130028.12471-1-ehabk...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 iothread.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/iothread.c b/iothread.c
index 44c8944..59d0850 100644
--- a/iothread.c
+++ b/iothread.c
@@ -85,7 +85,7 @@ static int iothread_stop(Object *object, void *opaque)
 IOThread *iothread;
 
 iothread = (IOThread *)object_dynamic_cast(object, TYPE_IOTHREAD);
-if (!iothread || !iothread->ctx) {
+if (!iothread || !iothread->ctx || iothread->stopping) {
 return 0;
 }
 iothread->stopping = true;
-- 
1.8.3.1





[Qemu-devel] [PULL 0/6] Misc patches for 2017-10-03

2017-10-03 Thread Paolo Bonzini
The following changes since commit ab161529261928ae7f3556e3220829c34b2686ec:

  Merge remote-tracking branch 'remotes/dgilbert/tags/pull-migration-20170927a' 
into staging (2017-09-27 22:44:51 +0100)

are available in the git repository at:


  git://github.com/bonzini/qemu.git tags/for-upstream

for you to fetch changes up to 346b1215b1e9f7cc6d8fe9fb6f3c2778b890afb6:

  kvmclock: use the updated system_timer_msr (2017-10-02 14:39:51 +0200)


* iothread bugfix (Eduardo)
* Linux headers sync (Dave)
* .gitignore fix (Eric)
* KVM capability check fixes (Greg)
* kvmclock fix (Jim)


Alexey Perevalov (1):
  linux-headers: sync against v4.14-rc1

Eduardo Habkost (1):
  iothread: Make iothread_stop() idempotent

Eric Blake (1):
  scsi: Ignore executable for in-tree builds

Greg Kurz (2):
  kvm: check KVM_CAP_SYNC_MMU with kvm_vm_check_extension()
  kvm: check KVM_CAP_NR_VCPUS with kvm_vm_check_extension()

Jim Somerville (1):
  kvmclock: use the updated system_timer_msr

 .gitignore   |  1 +
 accel/kvm/kvm-all.c  | 51 +++-
 accel/stubs/kvm-stub.c   |  4 +--
 hw/i386/kvm/clock.c  |  3 +-
 include/standard-headers/asm-x86/hyperv.h| 19 ---
 include/standard-headers/linux/pci_regs.h| 42 +--
 include/standard-headers/linux/virtio_ring.h |  4 +--
 include/sysemu/kvm.h |  2 +-
 iothread.c   |  2 +-
 linux-headers/asm-s390/kvm.h |  6 
 linux-headers/linux/kvm.h|  3 +-
 linux-headers/linux/userfaultfd.h| 16 -
 12 files changed, 98 insertions(+), 55 deletions(-)
-- 
1.8.3.1




[Qemu-devel] [PULL 1/6] scsi: Ignore executable for in-tree builds

2017-10-03 Thread Paolo Bonzini
From: Eric Blake 

The new qemu-pr-helper (commit b855f8d17) should not be checked in,
even when doing in-tree builds.

Signed-off-by: Eric Blake 
Message-Id: <20170926151421.14557-1-ebl...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index 40acfcb..3a7e01d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -49,6 +49,7 @@
 /qemu-version.h
 /qemu-version.h.tmp
 /module_block.h
+/scsi/qemu-pr-helper
 /vscclient
 /vhost-user-scsi
 /fsdev/virtfs-proxy-helper
-- 
1.8.3.1





[Qemu-devel] [PULL 4/6] kvm: check KVM_CAP_SYNC_MMU with kvm_vm_check_extension()

2017-10-03 Thread Paolo Bonzini
From: Greg Kurz 

On a server-class ppc host, this capability depends on the KVM type,
ie, HV or PR. If both KVM are present in the kernel, we will always
get the HV specific value, even if we explicitely requested PR on
the command line.

This can have an impact if we're using hugepages or a balloon device.

Since we've already created the VM at the time any user calls
kvm_has_sync_mmu(), switching to kvm_vm_check_extension() is
enough to fix any potential issue.

It is okay for the other archs that also implement KVM_CAP_SYNC_MMU,
ie, mips, s390, x86 and arm, because they don't depend on the VM being
created or not.

While here, let's cache the state of this extension in a bool variable,
since it has several users in the code, as suggested by Thomas Huth.

Signed-off-by: Greg Kurz 
Message-Id: <150600965332.30533.14702405809647835716.st...@bahia.lan>
Reviewed-by: David Gibson 
Signed-off-by: Paolo Bonzini 
---
 accel/kvm/kvm-all.c| 8 +---
 accel/stubs/kvm-stub.c | 4 ++--
 include/sysemu/kvm.h   | 2 +-
 3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 4f1997d..f54a337 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -87,6 +87,7 @@ struct KVMState
 #endif
 int many_ioeventfds;
 int intx_set_mask;
+bool sync_mmu;
 /* The man page (and posix) say ioctl numbers are signed int, but
  * they're not.  Linux, glibc and *BSD all treat ioctl numbers as
  * unsigned, and treating them as signed here can break things */
@@ -1664,6 +1665,8 @@ static int kvm_init(MachineState *ms)
 
 s->many_ioeventfds = kvm_check_many_ioeventfds();
 
+s->sync_mmu = !!kvm_vm_check_extension(kvm_state, KVM_CAP_SYNC_MMU);
+
 return 0;
 
 err:
@@ -2130,10 +2133,9 @@ int kvm_device_access(int fd, int group, uint64_t attr,
 return err;
 }
 
-/* Return 1 on success, 0 on failure */
-int kvm_has_sync_mmu(void)
+bool kvm_has_sync_mmu(void)
 {
-return kvm_check_extension(kvm_state, KVM_CAP_SYNC_MMU);
+return kvm_state->sync_mmu;
 }
 
 int kvm_has_vcpu_events(void)
diff --git a/accel/stubs/kvm-stub.c b/accel/stubs/kvm-stub.c
index 3965c52..c964af3 100644
--- a/accel/stubs/kvm-stub.c
+++ b/accel/stubs/kvm-stub.c
@@ -64,9 +64,9 @@ int kvm_cpu_exec(CPUState *cpu)
 abort();
 }
 
-int kvm_has_sync_mmu(void)
+bool kvm_has_sync_mmu(void)
 {
-return 0;
+return false;
 }
 
 int kvm_has_many_ioeventfds(void)
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index 3a458f5..bbf12a1 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -207,7 +207,7 @@ extern KVMState *kvm_state;
 /* external API */
 
 bool kvm_has_free_slot(MachineState *ms);
-int kvm_has_sync_mmu(void);
+bool kvm_has_sync_mmu(void);
 int kvm_has_vcpu_events(void);
 int kvm_has_robust_singlestep(void);
 int kvm_has_debugregs(void);
-- 
1.8.3.1





[Qemu-devel] [PULL 5/6] kvm: check KVM_CAP_NR_VCPUS with kvm_vm_check_extension()

2017-10-03 Thread Paolo Bonzini
From: Greg Kurz 

On a modern server-class ppc host with the following CPU topology:

Architecture:  ppc64le
Byte Order:Little Endian
CPU(s):32
On-line CPU(s) list:   0,8,16,24
Off-line CPU(s) list:  1-7,9-15,17-23,25-31
Thread(s) per core:1

If both KVM PR and KVM HV loaded and we pass:

-machine pseries,accel=kvm,kvm-type=PR -smp 8

We expect QEMU to warn that this exceeds the number of online CPUs:

Warning: Number of SMP cpus requested (8) exceeds the recommended
 cpus supported by KVM (4)
Warning: Number of hotpluggable cpus requested (8) exceeds the
 recommended cpus supported by KVM (4)

but nothing is printed...

This happens because on ppc the KVM_CAP_NR_VCPUS capability is VM
specific  ndreally depends on the KVM type, but we currently use it
as a global capability. And KVM returns a fallback value based on
KVM HV being present. Maybe KVM on POWER shouldn't presume anything
as long as it doesn't have a VM, but in all cases, we should call
KVM_CREATE_VM first and use KVM_CAP_NR_VCPUS as a VM capability.

This patch hence changes kvm_recommended_vcpus() accordingly and
moves the sanity checking of smp_cpus after the VM creation.

It is okay for the other archs that also implement KVM_CAP_NR_VCPUS,
ie, mips, s390, x86 and arm, because they don't depend on the VM
being created or not.

Signed-off-by: Greg Kurz 
Reviewed-by: David Gibson 
Reviewed-by: Thomas Huth 
Message-Id: <150600966286.30533.10909862523552370889.st...@bahia.lan>
Signed-off-by: Paolo Bonzini 
---
 accel/kvm/kvm-all.c | 43 ++-
 1 file changed, 22 insertions(+), 21 deletions(-)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index f54a337..90c88b5 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -1440,7 +1440,7 @@ static void kvm_irqchip_create(MachineState *machine, 
KVMState *s)
  */
 static int kvm_recommended_vcpus(KVMState *s)
 {
-int ret = kvm_check_extension(s, KVM_CAP_NR_VCPUS);
+int ret = kvm_vm_check_extension(s, KVM_CAP_NR_VCPUS);
 return (ret) ? ret : 4;
 }
 
@@ -1530,26 +1530,6 @@ static int kvm_init(MachineState *ms)
 s->nr_slots = 32;
 }
 
-/* check the vcpu limits */
-soft_vcpus_limit = kvm_recommended_vcpus(s);
-hard_vcpus_limit = kvm_max_vcpus(s);
-
-while (nc->name) {
-if (nc->num > soft_vcpus_limit) {
-warn_report("Number of %s cpus requested (%d) exceeds "
-"the recommended cpus supported by KVM (%d)",
-nc->name, nc->num, soft_vcpus_limit);
-
-if (nc->num > hard_vcpus_limit) {
-fprintf(stderr, "Number of %s cpus requested (%d) exceeds "
-"the maximum cpus supported by KVM (%d)\n",
-nc->name, nc->num, hard_vcpus_limit);
-exit(1);
-}
-}
-nc++;
-}
-
 kvm_type = qemu_opt_get(qemu_get_machine_opts(), "kvm-type");
 if (mc->kvm_type) {
 type = mc->kvm_type(kvm_type);
@@ -1584,6 +1564,27 @@ static int kvm_init(MachineState *ms)
 }
 
 s->vmfd = ret;
+
+/* check the vcpu limits */
+soft_vcpus_limit = kvm_recommended_vcpus(s);
+hard_vcpus_limit = kvm_max_vcpus(s);
+
+while (nc->name) {
+if (nc->num > soft_vcpus_limit) {
+warn_report("Number of %s cpus requested (%d) exceeds "
+"the recommended cpus supported by KVM (%d)",
+nc->name, nc->num, soft_vcpus_limit);
+
+if (nc->num > hard_vcpus_limit) {
+fprintf(stderr, "Number of %s cpus requested (%d) exceeds "
+"the maximum cpus supported by KVM (%d)\n",
+nc->name, nc->num, hard_vcpus_limit);
+exit(1);
+}
+}
+nc++;
+}
+
 missing_cap = kvm_check_extension_list(s, kvm_required_capabilites);
 if (!missing_cap) {
 missing_cap =
-- 
1.8.3.1





[Qemu-devel] [PULL 6/6] kvmclock: use the updated system_timer_msr

2017-10-03 Thread Paolo Bonzini
From: Jim Somerville 

Fixes e2b6c17 (kvmclock: update system_time_msr address forcibly)
which makes a call to get the latest value of the address
stored in system_timer_msr, but then uses the old address anyway.

Signed-off-by: Jim Somerville 
Message-Id: 
<59b67db0bd15a46ab47c3aa657c81a4c11f168ea.1506702472.git.jim.somervi...@windriver.com>
Cc: qemu-sta...@nongnu.org
Signed-off-by: Paolo Bonzini 
---
 hw/i386/kvm/clock.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/i386/kvm/clock.c b/hw/i386/kvm/clock.c
index 75ad1ba..1707434 100644
--- a/hw/i386/kvm/clock.c
+++ b/hw/i386/kvm/clock.c
@@ -62,7 +62,7 @@ static uint64_t kvmclock_current_nsec(KVMClockState *s)
 {
 CPUState *cpu = first_cpu;
 CPUX86State *env = cpu->env_ptr;
-hwaddr kvmclock_struct_pa = env->system_time_msr & ~1ULL;
+hwaddr kvmclock_struct_pa;
 uint64_t migration_tsc = env->tsc;
 struct pvclock_vcpu_time_info time;
 uint64_t delta;
@@ -77,6 +77,7 @@ static uint64_t kvmclock_current_nsec(KVMClockState *s)
 return 0;
 }
 
+kvmclock_struct_pa = env->system_time_msr & ~1ULL;
 cpu_physical_memory_read(kvmclock_struct_pa, &time, sizeof(time));
 
 assert(time.tsc_timestamp <= migration_tsc);
-- 
1.8.3.1




Re: [Qemu-devel] [PATCH 22/38] xtensa: cleanup cpu type name composition

2017-10-03 Thread Igor Mammedov
On Mon, 2 Oct 2017 17:35:39 -0300
Philippe Mathieu-Daudé  wrote:

> On 10/02/2017 06:08 AM, Igor Mammedov wrote:
> > use new XTENSA_CPU_TYPE_NAME to compose CPU type name
> > to bring xtensa in line with all other targets that
> > will similar macro.
> > 
> > Signed-off-by: Igor Mammedov 
> > ---
> > CC: jcmvb...@gmail.com
> > ---
> >   target/xtensa/cpu.h| 4 
> >   target/xtensa/cpu.c| 2 +-
> >   target/xtensa/helper.c | 2 +-
> >   3 files changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/target/xtensa/cpu.h b/target/xtensa/cpu.h
> > index 4803331..b17d7d9 100644
> > --- a/target/xtensa/cpu.h
> > +++ b/target/xtensa/cpu.h
> > @@ -469,11 +469,15 @@ void xtensa_cpu_do_unaligned_access(CPUState *cpu, 
> > vaddr addr,
> >   #define cpu_signal_handler cpu_xtensa_signal_handler
> >   #define cpu_list xtensa_cpu_list
> >   
> > +#define XTENSA_CPU_TYPE_SUFFIX "-" TYPE_XTENSA_CPU
> > +#define XTENSA_CPU_TYPE_NAME(model) model XTENSA_CPU_TYPE_SUFFIX
> > +
> >   #ifdef TARGET_WORDS_BIGENDIAN
> >   #define XTENSA_DEFAULT_CPU_MODEL "fsf"
> >   #else
> >   #define XTENSA_DEFAULT_CPU_MODEL "dc232b"
> >   #endif
> > +#define XTENSA_DEFAULT_CPU_TYPE 
> > XTENSA_CPU_TYPE_NAME(XTENSA_DEFAULT_CPU_MODEL)  
> 
> I see XTENSA_DEFAULT_CPU_MODEL is used in mc->desc, any idea to be able 
> to use this instead?
mc-desc is the reason why I've left XTENSA_DEFAULT_CPU_MODEL as is, and
having that there were no point in adding yet another ifdef for type,
XTENSA_DEFAULT_CPU_MODEL works just fine here.

> 
> #ifdef TARGET_WORDS_BIGENDIAN
> # define XTENSA_DEFAULT_CPU_TYPE XTENSA_CPU_TYPE_NAME("fsf")
> #else
> # define XTENSA_DEFAULT_CPU_TYPE XTENSA_CPU_TYPE_NAME("dc232b")
> #endif
> 
> >   
> >   #define cpu_init(cpu_model) cpu_generic_init(TYPE_XTENSA_CPU, cpu_model)
> >   
> > diff --git a/target/xtensa/cpu.c b/target/xtensa/cpu.c
> > index dcdc765..b5f7079 100644
> > --- a/target/xtensa/cpu.c
> > +++ b/target/xtensa/cpu.c
> > @@ -83,7 +83,7 @@ static ObjectClass *xtensa_cpu_class_by_name(const char 
> > *cpu_model)
> >   ObjectClass *oc;
> >   char *typename;
> >   
> > -typename = g_strdup_printf("%s-" TYPE_XTENSA_CPU, cpu_model);
> > +typename = g_strdup_printf(XTENSA_CPU_TYPE_NAME("%s"), cpu_model);
> >   oc = object_class_by_name(typename);
> >   g_free(typename);
> >   if (oc == NULL || !object_class_dynamic_cast(oc, TYPE_XTENSA_CPU) ||
> > diff --git a/target/xtensa/helper.c b/target/xtensa/helper.c
> > index e8fba20..216f198 100644
> > --- a/target/xtensa/helper.c
> > +++ b/target/xtensa/helper.c
> > @@ -76,7 +76,7 @@ void xtensa_register_core(XtensaConfigList *node)
> >   
> >   node->next = xtensa_cores;
> >   xtensa_cores = node;
> > -type.name = g_strdup_printf("%s-" TYPE_XTENSA_CPU, node->config->name);
> > +type.name = g_strdup_printf(XTENSA_CPU_TYPE_NAME("%s"), 
> > node->config->name);
> >   type_register(&type);
> >   g_free((gpointer)type.name);
> >   }
> >   




[Qemu-devel] [Bug 1318474] Re: QEMU update causes Windows reactivation

2017-10-03 Thread Thomas Huth
How did you start QEMU with the new version here? You might need to
specify the correct machine type with the new version to avoid that the
guest sees different hardware (e.g. with the "-machine pc-i440fx-2.0"
option).

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  QEMU update causes Windows reactivation

Status in QEMU:
  Incomplete

Bug description:
  After updating QEMU the guest OS's detect new hardware. As a result
  any Windows OS sees it as a significant change in hardware and require
  a reactivation.

  Host OS: Ubuntu 14.04 64-bit

  Guest OS's:
  Windows Server 2003 R2 Enterprise
  Windows Server 2008 R2 Enterprise
  Windows Server 2008 R2 Web
  Windows Server 2008 R2 Data Center

  QEMU version: 2.0.0

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



[Qemu-devel] [Bug 700276] Re: QEMU crashed when GDB request a big size variable information

2017-10-03 Thread Thomas Huth
Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  QEMU crashed when GDB request a big size variable information

Status in QEMU:
  Incomplete

Bug description:
  Hello,
  My host is Fedora 13. My QEMU version is 0.13.0, I use QEMU with GDB to debug 
Linux kernel(Version 2.6.36.2).

  I use QEMU like this:"qemu -s -S -kernel build/arch/i386/boot/bzImage -hda 
/dev/zero"
  When GDB connected with QEMU, and use gdb command print to look big size 
variable, the qemu is crash down. for example, when I look a task_struct 
variable 'init_task'(print init_task ), the qemu produce the below message and 
exit.

  *** stack smashing detected ***: qemu terminated
  === Backtrace: =
  /lib/libc.so.6(__fortify_fail+0x4d)[0x78a31d]
  /lib/libc.so.6[0x78a2ca]
  qemu[0x8059e21]
  qemu[0x805a0cf]
  qemu[0x80d12a1]
  qemu[0x8189cb8]
  qemu[0x818c3b0]
  /lib/libc.so.6(__libc_start_main+0xe6)[0x6a8cc6]
  ...
  adbf7000-adbf8000 rw-p  00:00 0 
  adbf8000-ae3f8000 rw-p  00:00 0 
  ae3f8000-ae742000 rw-p  00:00 0 
  ae742000-ae762000 rw-p  00:00 0 
  ae762000-ae764000 rw-p  00:00 0 
  ae764000-ae784000 rw-p  00:00 0 
  ae784000-ae786000 rw-p  00:00 0 
  ae786000-b6786000 rw-p  00:00 0 
  b6786000-b7894000 rw-p  00:00 0 
  b78aa000-b78ab000 rw-p  00:00 0 
  bfe95000-bfeaa000 rw-p  00:00 0  [stack]
  已放弃 (core dumped)

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



[Qemu-devel] [Bug 1320360] Re: usb passthrough not working anymore

2017-10-03 Thread Thomas Huth
Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  usb passthrough not working anymore

Status in QEMU:
  Incomplete

Bug description:
  Hi,

  I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7
  as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but
  starting with qemu 2.0.0 passthrough stop working. I can still add the
  usb device but when I start the guest following message appears:

  "unable to execute QEMU command 'device_add': 'usb-host' is not a
  valid device model name"

  Then the guest will not start.

  I try it with different usb devices (iphone, stick, hdd), always the
  same error.

  Are there any news / hints about this ?

  Regards

  Martin

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



[Qemu-devel] [Bug 1321684] Re: block_stream command stalls

2017-10-03 Thread Thomas Huth
Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  block_stream command stalls

Status in QEMU:
  Incomplete

Bug description:
  block_stream command stalls near finishing.
  I tried 1.7.1, 2.0.0 and the master versions. All of them stalled.
  But the 1.1.2 could finish the job.

  Here is how to reproduce it:

  $ sudo $QEMU \
  -enable-kvm  -cpu qemu64  -m 1024  \
  -monitor stdio \
  -drive file=./i1,if=none,id=drive_0,cache=none,aio=native -device 
virtio-blk-pci,drive=drive_0,bus=pci.0,addr=0x5 \

  QEMU 2.0.50 monitor - type 'help' for more information
  (qemu) VNC server running on `127.0.0.1:5900'
  (qemu) snapshot_blkdev drive_0 s1
  Formatting 's1', fmt=qcow2 size=26843545600 backing_file='./i1' 
backing_fmt='qcow2' encryption=off cluster_size=65536 lazy_refcounts=off 
  (qemu) block_stream drive_0 
  (qemu) info block-jobs 
  Streaming device drive_0: Completed 400818176 of 26843545600 bytes, speed 
limit 0 bytes/s
  (qemu) info block-jobs 
  Streaming device drive_0: Completed 904396800 of 26843545600 bytes, speed 
limit 0 bytes/s
  (qemu) info block-jobs 
  Streaming device drive_0: Completed 23401070592 of 26843545600 bytes, speed 
limit 0 bytes/s
  (qemu) info block-jobs 
  Streaming device drive_0: Completed 26513768448 of 26843545600 bytes, speed 
limit 0 bytes/s
  (qemu) main-loop: WARNING: I/O thread spun for 1000 iterations
  info block-jobs 
  Streaming device drive_0: Completed 26841513984 of 26843545600 bytes, speed 
limit 0 bytes/s
  (qemu) info block-jobs 
  Streaming device drive_0: Completed 26841513984 of 26843545600 bytes, speed 
limit 0 bytes/s
  (qemu) info block-jobs 
  Streaming device drive_0: Completed 26841513984 of 26843545600 bytes, speed 
limit 0 bytes/s

   here, the progress stopped at 26841513984 

  
  $ qemu-img info i1 
  image: i1
  file format: qcow2
  virtual size: 25G (26843545600 bytes)
  disk size: 1.0G
  cluster_size: 2097152
  Format specific information:
  compat: 1.1
  lazy refcounts: false

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



[Qemu-devel] [Bug 1327608] Re: monitor socked path is cut a 105 characters

2017-10-03 Thread Thomas Huth
Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?

** Changed in: qemu
   Status: New => Incomplete

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

Title:
  monitor socked path is cut a 105 characters

Status in QEMU:
  Incomplete

Bug description:
  Starting a VM like so:

  /usr/bin/qemu-system-x86_64 -machine accel=kvm -monitor
  unix:/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt
  /lv-gentoosummerschool/gentoo-summerschool/gentoo-
  summerschool.img.monitor,server,nowait -name gentoo-summerschool
  -chardev
  socket,id=monitor,path=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J
  /vg-virt/lv-gentoosummerschool/gentoo-
  summerschool/monitor.sock,server,nowait -monitor chardev:monitor
  -chardev
  socket,id=serial0,path=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J
  /vg-virt/lv-gentoosummerschool/gentoo-
  summerschool/console.sock,server,nowait -serial chardev:serial0
  -enable-kvm -cpu kvm64 -smp 2 -netdev
  tap,id=net0,script=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J
  /vg-virt/lv-gentoosummerschool/gentoo-summerschool/qemu-ifup.bash
  -device e1000,netdev=net0,mac=00:00:00:00:00:02 -drive
  id=disk,file=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J
  /vg-virt/lv-gentoosummerschool/gentoo-summerschool/gentoo-
  summerschool.img,if=none -device ahci,id=ahci -device ide-
  drive,drive=disk,bus=ahci.0 -m 2048 -vga qxl -spice
  port=2002,addr=192.168.4.2,password=NO-thats-not-my-pwd -device
  virtio-serial-pci -device
  virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev
  spicevmc,id=spicechannel0,name=vdagent

  
  The path: 

  unix:/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt
  /lv-gentoosummerschool/gentoo-summerschool/gentoo-
  summerschool.img.monitor

  ...is cut like so when I try to shutdown:

  pink ~ # echo system_powerdown | socat - 
UNIX-CONNECT:/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschool/gentoo-summerschool.img.monitor
  2014/06/08 06:39:01 socat[2344] E connect(3, AF=1 
"/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschoo",
 110): No such file or directory
  pink ~ # 

  
  It does work with a sorter path like: 
  pink ~ # echo system_powerdown | socat - 
UNIX-CONNECT:'/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/my.img.monitor'
 
  QEMU 1.5.3 monitor - type 'help' for more information
  (qemu) system_powerdown
  (qemu) pink ~ #

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



Re: [Qemu-devel] [Xen-devel] [PATCH] migration, xen: Fix block image lock issue on live migration

2017-10-03 Thread Roger Pau Monné
On Mon, Oct 02, 2017 at 04:30:58PM +, Anthony PERARD wrote:
> When doing a live migration of a Xen guest with libxl, the images for
> block devices are locked by the original QEMU process, and this prevent
> the QEMU at the destination to take the lock and the migration fail.
> 
> From QEMU point of view, once the RAM of a domain is migrated, there is
> two QMP commands, "stop" then "xen-save-devices-state", at which point a
> new QEMU is spawned at the destination.
> 
> Release locks in "xen-save-devices-state" so the destination can takes
> them.

What happens if the migration fails on the destination? Will QEMU pick
the lock again when resuming on the source in this case?

Thanks, Roger.



Re: [Qemu-devel] [Xen-devel] [PATCH] migration, xen: Fix block image lock issue on live migration

2017-10-03 Thread Anthony PERARD
On Tue, Oct 03, 2017 at 12:33:37PM +0100, Roger Pau Monné wrote:
> On Mon, Oct 02, 2017 at 04:30:58PM +, Anthony PERARD wrote:
> > When doing a live migration of a Xen guest with libxl, the images for
> > block devices are locked by the original QEMU process, and this prevent
> > the QEMU at the destination to take the lock and the migration fail.
> > 
> > From QEMU point of view, once the RAM of a domain is migrated, there is
> > two QMP commands, "stop" then "xen-save-devices-state", at which point a
> > new QEMU is spawned at the destination.
> > 
> > Release locks in "xen-save-devices-state" so the destination can takes
> > them.
> 
> What happens if the migration fails on the destination? Will QEMU pick
> the lock again when resuming on the source in this case?

Yes, calling the QMP command "cont" to resume the activity makes QEMU
take the lock again, and libxl would call "cont". (I don't think you can
pick this kind of lock ;-). )

-- 
Anthony PERARD



Re: [Qemu-devel] [PATCH 07/43] windbg: added chardev

2017-10-03 Thread Ladi Prosek
On Tue, Sep 26, 2017 at 1:04 PM, Mihail Abakumov
 wrote:
> Added chardev for listening to windbg. Target device is a parameter in the 
> '-windbg' option.
>
> Signed-off-by: Mihail Abakumov 
> Signed-off-by: Pavel Dovgalyuk 
> Signed-off-by: Dmitriy Koltunov 
> ---
>  windbgstub.c |   26 ++
>  1 file changed, 26 insertions(+)
>
> diff --git a/windbgstub.c b/windbgstub.c
> index 60a380c213..378d1b911f 100755
> --- a/windbgstub.c
> +++ b/windbgstub.c
> @@ -10,6 +10,7 @@
>   */
>
>  #include "qemu/osdep.h"
> +#include "qapi/error.h"
>  #include "chardev/char.h"
>  #include "chardev/char-fe.h"
>  #include "exec/windbgstub.h"
> @@ -18,12 +19,26 @@
>  typedef struct WindbgState {
>  bool is_loaded;
>
> +CharBackend chr;
> +
>  uint32_t ctrl_packet_id;
>  uint32_t data_packet_id;
>  } WindbgState;
>
>  static WindbgState *windbg_state;
>
> +static int windbg_chr_can_receive(void *opaque)
> +{
> +return PACKET_MAX_SIZE;
> +}
> +
> +static void windbg_chr_receive(void *opaque, const uint8_t *buf, int size)
> +{
> +if (windbg_state->is_loaded) {
> +/* T0D0: parse data */
> +}
> +}
> +
>  static void windbg_exit(void)
>  {
>  g_free(windbg_state);
> @@ -31,6 +46,8 @@ static void windbg_exit(void)
>
>  int windbg_server_start(const char *device)
>  {
> +Chardev *chr = NULL;
> +
>  if (windbg_state) {
>  WINDBG_ERROR("Multiple instances are not supported");
>  exit(1);
> @@ -40,6 +57,15 @@ int windbg_server_start(const char *device)
>  windbg_state->ctrl_packet_id = RESET_PACKET_ID;
>  windbg_state->data_packet_id = INITIAL_PACKET_ID;
>
> +chr = qemu_chr_new_noreplay(WINDBG, device);
> +if (!chr) {

This should generate error output. Passing "-windbg bogus" makes QEMU
exit silently.
-gdb seems to have the same problem.

> +return -1;
> +}
> +
> +qemu_chr_fe_init(&windbg_state->chr, chr, &error_abort);
> +qemu_chr_fe_set_handlers(&windbg_state->chr, windbg_chr_can_receive,
> + windbg_chr_receive, NULL, NULL, NULL, NULL, 
> true);
> +
>  atexit(windbg_exit);
>  return 0;
>  }
>



Re: [Qemu-devel] [PATCH v3 5/6] s390x/css: activate ChannelSubSys migration

2017-10-03 Thread Thomas Huth
On 11.07.2017 16:54, Halil Pasic wrote:
> Turn on migration for the channel subsystem for the next machine.  For
> legacy machines we still have to do things the old way.
> 
> Signed-off-by: Halil Pasic 
> Reviewed-by: Cornelia Huck 
> ---
>  hw/s390x/css.c | 5 +
>  hw/s390x/s390-virtio-ccw.c | 9 -
>  include/hw/s390x/css.h | 4 
>  3 files changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/s390x/css.c b/hw/s390x/css.c
> index 20b5fbed68..b89b60751a 100644
> --- a/hw/s390x/css.c
> +++ b/hw/s390x/css.c
> @@ -407,6 +407,11 @@ static int subch_dev_post_load(void *opaque, int 
> version_id)
>  return 0;
>  }
>  
> +void css_register_vmstate(void)
> +{
> +vmstate_register(NULL, 0, &vmstate_css, &channel_subsys);
> +}
> +
>  IndAddr *get_indicator(hwaddr ind_addr, int len)
>  {
>  IndAddr *indicator;
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index 751febb87a..20e3f06519 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -206,7 +206,7 @@ static void ccw_machine_class_init(ObjectClass *oc, void 
> *data)
>  
>  s390mc->ri_allowed = true;
>  s390mc->cpu_model_allowed = true;
> -s390mc->css_migration_enabled = false; /* TODO: set to true */
> +s390mc->css_migration_enabled = true;
>  mc->init = ccw_init;
>  mc->reset = s390_machine_reset;
>  mc->hot_add_cpu = s390_hot_add_cpu;
> @@ -482,10 +482,9 @@ bool css_migration_enabled(void)
>  
>  static void ccw_machine_2_10_instance_options(MachineState *machine)
>  {
> -/*
> - * TODO Once preparations are done register vmstate for the css if
> - * css_migration_enabled().
> - */
> +if (css_migration_enabled()) {
> +css_register_vmstate();
> +}
>  }

The location for the above hunk seems to be quite unfortunate: For the
s390-ccw-virtio-2.11 machine, we now do not call css_register_vmstate()
anymore.

Maybe this should rather go into ccw_init() instead?

 Thomas



Re: [Qemu-devel] [PATCH 08/43] windbg: hook to wrmsr operation

2017-10-03 Thread Ladi Prosek
On Tue, Sep 26, 2017 at 1:04 PM, Mihail Abakumov
 wrote:
> Inserted hook to wrmsr operation. Windows Kernel put address on KPCR struct 
> to fs/gs (x32/x64) register. Needs catch this moment and allow windbg server 
> handle packets.
>
> Signed-off-by: Mihail Abakumov 
> Signed-off-by: Pavel Dovgalyuk 
> Signed-off-by: Dmitriy Koltunov 
> ---
>  include/exec/windbgstub-utils.h |3 +++
>  include/exec/windbgstub.h   |1 +
>  target/i386/misc_helper.c   |3 +++
>  windbgstub-utils.c  |8 
>  windbgstub.c|8 
>  5 files changed, 23 insertions(+)
>
> diff --git a/include/exec/windbgstub-utils.h b/include/exec/windbgstub-utils.h
> index 65f336e4bf..90fb766839 100755
> --- a/include/exec/windbgstub-utils.h
> +++ b/include/exec/windbgstub-utils.h
> @@ -62,4 +62,7 @@
>  _t;   \
>  })
>
> +bool windbg_on_load(void);
> +void windbg_on_exit(void);
> +
>  #endif
> diff --git a/include/exec/windbgstub.h b/include/exec/windbgstub.h
> index 703fc26b8f..2dbf1b1f13 100755
> --- a/include/exec/windbgstub.h
> +++ b/include/exec/windbgstub.h
> @@ -15,6 +15,7 @@
>  #define WINDBG "windbg"
>  #define WINDBG_DEBUG_ON false
>
> +void windbg_try_load(void);
>  int windbg_server_start(const char *device);
>
>  #endif
> diff --git a/target/i386/misc_helper.c b/target/i386/misc_helper.c
> index 628f64aad5..ec1fcd2899 100644
> --- a/target/i386/misc_helper.c
> +++ b/target/i386/misc_helper.c
> @@ -24,6 +24,7 @@
>  #include "exec/exec-all.h"
>  #include "exec/cpu_ldst.h"
>  #include "exec/address-spaces.h"
> +#include "exec/windbgstub.h"
>
>  void helper_outb(CPUX86State *env, uint32_t port, uint32_t data)
>  {
> @@ -385,6 +386,8 @@ void helper_wrmsr(CPUX86State *env)
>  /* XXX: exception? */
>  break;
>  }
> +
> +windbg_try_load();

Most people use QEMU with KVM and won't ever hit this code. Does your
work rely on TCG only for FS/GS write interception?

If KVM is out of scope for you, you should at least make sure that
users won't expect -windbg to work with it. So either fall back to TCG
if -windbg is passed or issue a warning.

>  }
>
>  void helper_rdmsr(CPUX86State *env)
> diff --git a/windbgstub-utils.c b/windbgstub-utils.c
> index dc5e505c63..b5fb6db3f2 100755
> --- a/windbgstub-utils.c
> +++ b/windbgstub-utils.c
> @@ -10,3 +10,11 @@
>   */
>
>  #include "exec/windbgstub-utils.h"
> +
> +bool windbg_on_load(void)
> +{
> +return false;
> +}
> +
> +void windbg_on_exit(void)
> +{}
> diff --git a/windbgstub.c b/windbgstub.c
> index 378d1b911f..99c3ef9b14 100755
> --- a/windbgstub.c
> +++ b/windbgstub.c
> @@ -39,8 +39,16 @@ static void windbg_chr_receive(void *opaque, const uint8_t 
> *buf, int size)
>  }
>  }
>
> +void windbg_try_load(void)
> +{
> +if (windbg_state && !windbg_state->is_loaded) {
> +windbg_state->is_loaded = windbg_on_load();
> +}
> +}
> +
>  static void windbg_exit(void)
>  {
> +windbg_on_exit();
>  g_free(windbg_state);
>  }
>
>



Re: [Qemu-devel] [PATCH 01/38] qom: add helper type_init_from_array()

2017-10-03 Thread Igor Mammedov
On Mon, 2 Oct 2017 16:24:04 -0300
Eduardo Habkost  wrote:

> On Mon, Oct 02, 2017 at 11:07:43AM +0200, Igor Mammedov wrote:
> > it will help to remove code duplication in places
> > that currently open code registration of several
> > types.
> > 
> > Signed-off-by: Igor Mammedov 
> > ---
> > I'm going to use it for CPU types in followup patches
> > 
> > CC: ehabk...@redhat.com
> > ---
> >  include/qemu/module.h | 10 ++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/include/qemu/module.h b/include/qemu/module.h
> > index 56dd218..29f9089 100644
> > --- a/include/qemu/module.h
> > +++ b/include/qemu/module.h
> > @@ -52,6 +52,16 @@ typedef enum {
> >  #define type_init(function) module_init(function, MODULE_INIT_QOM)
> >  #define trace_init(function) module_init(function, MODULE_INIT_TRACE)
> >  
> > +#define type_init_from_array(array)
> > \  
> 
> So we're moving from a imperative way to register types to a
> declarative way.  Sounds nice.
> 
> You are also adding a way to register a TypeInfo array easily.
> That's nice, too.
> 
> But, why do we need to address both at the same time?  I think
> this adds some confusing gaps to the module/QOM APIs:
> 
> * If you want to register a type at runtime, there are only
>   functions to register a single type (type_register(),
>   type_register_static().  What if I want to register a TypeInfo
>   array from an existing type_init() function?
> * If you want to declare types to be registered automatically at
>   module_call_init(MODULE_INIT_QOM), you are adding a helper that
>   avoids manual type_register*() calls, but only for arrays.
>   What if I want to register a single type?  (There are 440+
>   functions containing a single type_register*() call in the
>   tree)
just array is sufficient for code touched in this series.
I'll add helper for single type as well, but I'd leave for someone
else to use it (i.e. do cleanup).

> I have two suggestions:
> 
> * Adding a type_register_static_array() helper first, call it
>   from a type_init() function, and think about a module.h-based
>   helper for arrays later.
> 
> * (For later) adding a module_init() helper that works for
>   registering a single type too. So, this very common pattern:
> 
>   static const TypeInfo FOO_type = {
>   /* ... */
>   };
>   
>   static void register_FOO_type(void)
>   {
>   type_register_static(&FOO_type);
>   }
>   
>   QOM_TYPE(register_FOO_type);
> 
>   could be written as:
> 
>   static const TypeInfo FOO_type = {
>   /* ... */
>   };
>   
>   QOM_TYPE(FOO_type);
> 
> (I'm suggesting QOM_TYPE as the macro name, but I'm not sure
> about it.  But I think type_init_*() is confusing because it
> doesn't work like the other *_init() helpers in module.h)
> 
> QOM_TYPE(T) could be just a shortcut to:
> QOM_TYPES_PTR(&T, 1).
QOM here seems redundant, how about
REGISTER_STATIC_TYPE/REGISTER_STATIC_TYPES

> 
> Your type_init_from_array(A) helper could be just a shortcut to:
> QOM_TYPES_PTR(A, ARRAY_SIZE(A)).
> 
> > +static void do_qemu_init_ ## array(void)   
> > \
> > +{  
> > \
> > +int i; 
> > \
> > +for (i = 0; i < ARRAY_SIZE(array); i++) {  
> > \
> > +type_register_static(&array[i]);   
> > \  
> 
> type_register_static() is in qom/object.[ch], and module.[ch] has
> no dependency on QOM at all.  I believe this belongs in
> qom/object.h, not module.h.
ok

> 
> > +}  
> > \
> > +}  
> > \
> > +module_init(do_qemu_init_ ## array, MODULE_INIT_QOM)  
> 
> Why not use type_init(do_qemu_init_ ## array)?
I'll will use it in v2

> 
> > +  
> 
> Also for later: this is not the first time we generate function
> bodies on the fly for module_init().  Maybe module_init could
> support a void* data argument?
> 
> >  #define block_module_load_one(lib) module_load_one("block-", lib)
> >  
> >  void register_module_init(void (*fn)(void), module_init_type type);
> > -- 
> > 2.7.4
> >   
> 




Re: [Qemu-devel] [PATCH 09/43] windbg: handler of fs/gs register

2017-10-03 Thread Ladi Prosek
On Tue, Sep 26, 2017 at 1:04 PM, Mihail Abakumov
 wrote:
> Added handler of fs/gs register. It tries to find and check KPCR and version 
> address.
>
> Signed-off-by: Mihail Abakumov 
> Signed-off-by: Pavel Dovgalyuk 
> Signed-off-by: Dmitriy Koltunov 
> ---
>  include/exec/windbgstub-utils.h |5 +++
>  windbgstub-utils.c  |   63 
> ++-
>  2 files changed, 66 insertions(+), 2 deletions(-)
>
> diff --git a/include/exec/windbgstub-utils.h b/include/exec/windbgstub-utils.h
> index 90fb766839..f2402ebb34 100755
> --- a/include/exec/windbgstub-utils.h
> +++ b/include/exec/windbgstub-utils.h
> @@ -62,6 +62,11 @@
>  _t;   \
>  })
>
> +typedef struct InitedAddr {
> +target_ulong addr;
> +bool is_init;
> +} InitedAddr;
> +
>  bool windbg_on_load(void);
>  void windbg_on_exit(void);
>
> diff --git a/windbgstub-utils.c b/windbgstub-utils.c
> index b5fb6db3f2..662096647e 100755
> --- a/windbgstub-utils.c
> +++ b/windbgstub-utils.c
> @@ -11,10 +11,69 @@
>
>  #include "exec/windbgstub-utils.h"
>
> +#ifdef TARGET_X86_64
> +# define OFFSET_SELF_PCR 0x18
> +# define OFFSET_VERS 0x108
> +#else
> +# define OFFSET_SELF_PCR 0x1C
> +# define OFFSET_VERS 0x34
> +#endif
> +
> +typedef struct KDData {
> +InitedAddr KPCR;
> +InitedAddr version;
> +} KDData;
> +
> +static KDData *kd;
> +
>  bool windbg_on_load(void)
>  {
> -return false;
> +CPUState *cpu = qemu_get_cpu(0);
> +CPUArchState *env = cpu->env_ptr;
> +
> +if (!kd) {
> +kd = g_new0(KDData, 1);
> +}
> +
> +if (!kd->KPCR.is_init) {
> +
> + #ifdef TARGET_X86_64
> +kd->KPCR.addr = env->segs[R_GS].base;
> + #else
> +kd->KPCR.addr = env->segs[R_FS].base;
> + #endif

What if Windows is rebooted and FS/GS changes? Do you need to flip
KPCR.is_init back to false on system reset?

> +static target_ulong prev_KPCR;
> +if (!kd->KPCR.addr || prev_KPCR == kd->KPCR.addr) {
> +return false;
> +}
> +prev_KPCR = kd->KPCR.addr;
> +
> +if (kd->KPCR.addr != READ_VMEM(cpu, kd->KPCR.addr + OFFSET_SELF_PCR,
> +   target_ulong)) {
> +return false;
> +}
> +
> +kd->KPCR.is_init = true;
> +}
> +
> +if (!kd->version.is_init && kd->KPCR.is_init) {
> +kd->version.addr = READ_VMEM(cpu, kd->KPCR.addr + OFFSET_VERS,
> + target_ulong);
> +if (!kd->version.addr) {
> +return false;
> +}
> +kd->version.is_init = true;
> +}
> +
> +WINDBG_DEBUG("windbg_on_load: KPCR " FMT_ADDR, kd->KPCR.addr);
> +WINDBG_DEBUG("windbg_on_load: version " FMT_ADDR, kd->version.addr);
> +
> +return true;
>  }
>
>  void windbg_on_exit(void)
> -{}
> +{
> +g_free(kd);
> +kd = NULL;
> +}
>



[Qemu-devel] [PATCH] qom: add helpers REGISTER_STATIC_TYPE[S]()

2017-10-03 Thread Igor Mammedov
it will help to remove code duplication in places
that currently open code registration of static
type[s] and remove necessity to declare function
for type_init() to call, when only static types
need to be registered.

Signed-off-by: Igor Mammedov 
---
I'm going to use it for CPU types in followup patches

CC: ehabk...@redhat.com
---
 include/qemu/module.h | 10 ++
 include/qom/object.h  | 10 ++
 qom/object.c  |  9 +
 3 files changed, 29 insertions(+)

diff --git a/include/qemu/module.h b/include/qemu/module.h
index 56dd218..60dd632 100644
--- a/include/qemu/module.h
+++ b/include/qemu/module.h
@@ -52,6 +52,16 @@ typedef enum {
 #define type_init(function) module_init(function, MODULE_INIT_QOM)
 #define trace_init(function) module_init(function, MODULE_INIT_TRACE)
 
+#define REGISTER_STATIC_TYPES(t, nr)\
+static void do_qemu_init_ ## t(void)\
+{   \
+type_register_static_array(t, nr);  \
+}   \
+type_init(do_qemu_init_ ## t)
+
+#define REGISTER_STATIC_TYPE(t) \
+REGISTER_STATIC_TYPES(t, 1)
+
 #define block_module_load_one(lib) module_load_one("block-", lib)
 
 void register_module_init(void (*fn)(void), module_init_type type);
diff --git a/include/qom/object.h b/include/qom/object.h
index f3e5cff..17fcadd 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -789,6 +789,16 @@ Type type_register_static(const TypeInfo *info);
 Type type_register(const TypeInfo *info);
 
 /**
+ * type_register_static_array:
+ * @infos: The array of the new type #TypeInfo structures.
+ * @nr_infos: number of entries in @infos
+ *
+ * @infos and all of the strings it points to should exist for the life time
+ * that the type is registered.
+ */
+void type_register_static_array(const TypeInfo *infos, int nr_infos);
+
+/**
  * object_class_dynamic_cast_assert:
  * @klass: The #ObjectClass to attempt to cast.
  * @typename: The QOM typename of the class to cast to.
diff --git a/qom/object.c b/qom/object.c
index 3e18537..40b1729 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -151,6 +151,15 @@ TypeImpl *type_register_static(const TypeInfo *info)
 return type_register(info);
 }
 
+void type_register_static_array(const TypeInfo *infos, int nr_infos)
+{
+int i;
+
+for (i = 0; i < nr_infos; i++) {
+assert(type_register_static(&infos[i]));
+}
+}
+
 static TypeImpl *type_get_by_name(const char *name)
 {
 if (name == NULL) {
-- 
2.7.4




Re: [Qemu-devel] [PATCH 00/43] Windbg supporting

2017-10-03 Thread Mihail Abakumov

Stefan Hajnoczi писал 2017-10-02 22:43:

On Tue, Sep 26, 2017 at 02:04:06PM +0300, Mihail Abakumov wrote:
We made the debugger module WinDbg (like GDB) for QEMU. This is the 
replacement of the remote stub in Windows kernel. Used for remote 
Windows kernel debugging without debugging mode.


How do the feature sets of the GDB remote protocol and WinDbg protocol
compare?  (I don't mean the debuggers themselves, but just the
protocols.)

Stefan


The GDB remote protocol is symbolic. The WinDbg remote protocol is a 
higher level protocol. Interaction occurs through packets. The 
structures of these packets are defined in windbgkd.h header file.


Mihail Abakumov



Re: [Qemu-devel] [PATCH 15/43] windbg: sized data buffer

2017-10-03 Thread Ladi Prosek
On Tue, Sep 26, 2017 at 1:05 PM, Mihail Abakumov
 wrote:
> Defined useful sized data buffer. It contains pointer to data and size of 
> this data. Also, defined some macroses for init and free.

"macros" instead of "macroses", same in patch 31.

> Signed-off-by: Mihail Abakumov 
> Signed-off-by: Pavel Dovgalyuk 
> Signed-off-by: Dmitriy Koltunov 
> ---
>  include/exec/windbgstub-utils.h |   15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/include/exec/windbgstub-utils.h b/include/exec/windbgstub-utils.h
> index cf2996d8cb..791721d472 100755
> --- a/include/exec/windbgstub-utils.h
> +++ b/include/exec/windbgstub-utils.h
> @@ -86,6 +86,21 @@ typedef struct PacketData {
>  uint16_t extra_size;
>  } PacketData;
>
> +typedef struct SizedBuf {
> +uint8_t *data;
> +size_t size;
> +} SizedBuf;
> +
> +#define SBUF_INIT(buf, mem_ptr, len) do { \
> +buf.data = mem_ptr;   \
> +buf.size = len;   \
> +} while (false)
> +#define SBUF_MALLOC(buf, size) SBUF_INIT(buf, g_malloc0(size), size)
> +#define SBUF_FREE(buf) do { \
> +g_free(buf.data);   \
> +buf.data = NULL;\
> +buf.size = 0;   \
> +} while (false)
>  bool windbg_on_load(void);
>  void windbg_on_exit(void);
>
>



Re: [Qemu-devel] [PATCH 15/43] windbg: sized data buffer

2017-10-03 Thread Ladi Prosek
On Tue, Sep 26, 2017 at 1:05 PM, Mihail Abakumov
 wrote:
> Defined useful sized data buffer. It contains pointer to data and size of 
> this data. Also, defined some macroses for init and free.

"macros" instead of "macroses", same in patch 31.

> Signed-off-by: Mihail Abakumov 
> Signed-off-by: Pavel Dovgalyuk 
> Signed-off-by: Dmitriy Koltunov 
> ---
>  include/exec/windbgstub-utils.h |   15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/include/exec/windbgstub-utils.h b/include/exec/windbgstub-utils.h
> index cf2996d8cb..791721d472 100755
> --- a/include/exec/windbgstub-utils.h
> +++ b/include/exec/windbgstub-utils.h
> @@ -86,6 +86,21 @@ typedef struct PacketData {
>  uint16_t extra_size;
>  } PacketData;
>
> +typedef struct SizedBuf {
> +uint8_t *data;
> +size_t size;
> +} SizedBuf;
> +
> +#define SBUF_INIT(buf, mem_ptr, len) do { \
> +buf.data = mem_ptr;   \
> +buf.size = len;   \
> +} while (false)
> +#define SBUF_MALLOC(buf, size) SBUF_INIT(buf, g_malloc0(size), size)
> +#define SBUF_FREE(buf) do { \
> +g_free(buf.data);   \
> +buf.data = NULL;\
> +buf.size = 0;   \
> +} while (false)
>  bool windbg_on_load(void);
>  void windbg_on_exit(void);
>
>



Re: [Qemu-devel] [PATCH 19/43] windbg: implemented windbg_process_control_packet

2017-10-03 Thread Ladi Prosek
On Tue, Sep 26, 2017 at 1:05 PM, Mihail Abakumov
 wrote:
> Signed-off-by: Mihail Abakumov 
> Signed-off-by: Pavel Dovgalyuk 
> Signed-off-by: Dmitriy Koltunov 
> ---
>  windbgstub.c |   26 +-
>  1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/windbgstub.c b/windbgstub.c
> index 3a13d22349..b8053102dd 100755
> --- a/windbgstub.c
> +++ b/windbgstub.c
> @@ -126,7 +126,31 @@ static void windbg_process_data_packet(ParsingContext 
> *ctx)
>  {}
>
>  static void windbg_process_control_packet(ParsingContext *ctx)
> -{}
> +{
> +switch (ctx->packet.PacketType) {
> +case PACKET_TYPE_KD_ACKNOWLEDGE:
> +break;
> +
> +case PACKET_TYPE_KD_RESET:
> +{
> +SizedBuf buf = kd_gen_load_symbols_sc(qemu_get_cpu(0));
> +
> +windbg_send_data_packet(buf.data, buf.size,
> +PACKET_TYPE_KD_STATE_CHANGE64);
> +windbg_send_control_packet(ctx->packet.PacketType);
> +windbg_state->ctrl_packet_id = INITIAL_PACKET_ID;
> +SBUF_FREE(buf);
> +break;
> +}
> +default:
> +WINDBG_ERROR("Catched unsupported control packet 0x%x",

"caught" instead of "catched", same in patches 20 and 21.

> + ctx->packet.PacketType);
> +
> +windbg_state->ctrl_packet_id = 0;
> +windbg_send_control_packet(PACKET_TYPE_KD_RESEND);
> +break;
> +}
> +}
>
>  static void windbg_ctx_handler(ParsingContext *ctx)
>  {
>



Re: [Qemu-devel] [PATCH 22/43] windbg: implemented kd_api_read_virtual_memory and kd_api_read_virtual_memory

2017-10-03 Thread Ladi Prosek
nit: The subject line has "kd_api_read_virtual_memory" twice in it.
Was probably meant to be

[PATCH 22/43] windbg: implemented kd_api_read_virtual_memory and
kd_api_write_virtual_memory


On Tue, Sep 26, 2017 at 1:06 PM, Mihail Abakumov
 wrote:
> Signed-off-by: Mihail Abakumov 
> Signed-off-by: Pavel Dovgalyuk 
> Signed-off-by: Dmitriy Koltunov 
> ---
>  include/exec/windbgstub-utils.h |2 ++
>  windbgstub-utils.c  |   47 
> +++
>  windbgstub.c|8 +++
>  3 files changed, 57 insertions(+)
>
> diff --git a/include/exec/windbgstub-utils.h b/include/exec/windbgstub-utils.h
> index ca21af7c91..c1ff1cec57 100755
> --- a/include/exec/windbgstub-utils.h
> +++ b/include/exec/windbgstub-utils.h
> @@ -102,6 +102,8 @@ typedef struct SizedBuf {
>  buf.size = 0;   \
>  } while (false)
>
> +void kd_api_read_virtual_memory(CPUState *cpu, PacketData *pd);
> +void kd_api_write_virtual_memory(CPUState *cpu, PacketData *pd);
>  void kd_api_unsupported(CPUState *cpu, PacketData *pd);
>
>  SizedBuf kd_gen_exception_sc(CPUState *cpu);
> diff --git a/windbgstub-utils.c b/windbgstub-utils.c
> index e7b381f829..1bde60a1e9 100755
> --- a/windbgstub-utils.c
> +++ b/windbgstub-utils.c
> @@ -30,6 +30,53 @@ typedef struct KDData {
>
>  static KDData *kd;
>
> +void kd_api_read_virtual_memory(CPUState *cpu, PacketData *pd)
> +{
> +DBGKD_READ_MEMORY64 *mem = &pd->m64.u.ReadMemory;
> +uint32_t len;
> +target_ulong addr;
> +int err;
> +
> +len = MIN(ldl_p(&mem->TransferCount), PACKET_MAX_SIZE - M64_SIZE);
> +addr = ldtul_p(&mem->TargetBaseAddress);
> +err = cpu_memory_rw_debug(cpu, addr, pd->extra, len, 0);
> +
> +if (!err) {
> +pd->extra_size = len;
> +mem->ActualBytesRead = ldl_p(&len);
> +} else {
> +pd->extra_size = 0;
> +mem->ActualBytesRead = 0;
> +pd->m64.ReturnStatus = STATUS_UNSUCCESSFUL;
> +
> +WINDBG_DEBUG("read_virtual_memory: No physical page mapped: " 
> FMT_ADDR,
> + (target_ulong) mem->TargetBaseAddress);
> +}
> +}
> +
> +void kd_api_write_virtual_memory(CPUState *cpu, PacketData *pd)
> +{
> +DBGKD_WRITE_MEMORY64 *mem = &pd->m64.u.WriteMemory;
> +uint32_t len;
> +target_ulong addr;
> +int err;
> +
> +len = MIN(ldl_p(&mem->TransferCount), pd->extra_size);
> +addr = ldtul_p(&mem->TargetBaseAddress);
> +err = cpu_memory_rw_debug(cpu, addr, pd->extra, len, 1);
> +
> +pd->extra_size = 0;
> +if (!err) {
> +mem->ActualBytesWritten = ldl_p(&len);
> +} else {
> +mem->ActualBytesWritten = 0;
> +pd->m64.ReturnStatus = STATUS_UNSUCCESSFUL;
> +
> +WINDBG_DEBUG("read_write_memory: No physical page mapped: " FMT_ADDR,
> + (target_ulong) mem->TargetBaseAddress);
> +}
> +}
> +
>  void kd_api_unsupported(CPUState *cpu, PacketData *pd)
>  {
>  WINDBG_ERROR("Catched unimplemented api %s",
> diff --git a/windbgstub.c b/windbgstub.c
> index 50b4ef0dea..327fe83f70 100755
> --- a/windbgstub.c
> +++ b/windbgstub.c
> @@ -133,6 +133,14 @@ static void 
> windbg_process_manipulate_packet(ParsingContext *ctx)
>
>  switch (ctx->data.m64.ApiNumber) {
>
> +case DbgKdReadVirtualMemoryApi:
> +kd_api_read_virtual_memory(cpu, &ctx->data);
> +break;
> +
> +case DbgKdWriteVirtualMemoryApi:
> +kd_api_write_virtual_memory(cpu, &ctx->data);
> +break;
> +
>  default:
>  kd_api_unsupported(cpu, &ctx->data);
>  break;
>



Re: [Qemu-devel] [Qemu-block] [PATCH 8/8] nbd: Minimal structured read for client

2017-10-03 Thread Vladimir Sementsov-Ogievskiy

03.10.2017 13:07, Paolo Bonzini wrote:

On 26/09/2017 00:19, Eric Blake wrote:

+/* here we deal with successful structured reply */
+switch (s->reply.type) {
+QEMUIOVector sub_qiov;
+case NBD_SREP_TYPE_OFFSET_DATA:

This is putting a LOT of smarts directly into the receive routine.
Here's where I was previously wondering (and I think Paolo as well)
whether it might be better to split the efforts: the generic function
reads off the chunk information and any payload, but a per-command
callback function then parses the chunks.  Especially since the
definition of the chunks differs on a per-command basis (yes, the NBD
spec will try to not reuse an SREP chunk type across multiple commands
unless the semantics are similar, but that's a bit more fragile).  This
particularly matters given my statement above that you want a
discriminated union, rather than a struct that contains unused fields,
for handling different SREP chunk types.

I think there should be two kinds of replies: 1) read directly into a
QEMUIOVector, using structured replies only as an encapsulation of the


who should read to qiov? reply_entry, or calling coroutine?.. 
reply_entry should anyway
parse reply, to understand should it read it all or read it to qiov (or 
yield back, and then

calling coroutine will read to qiov)..


payload; 2) read a chunk at a time into malloc-ed memory, yielding back
to the calling coroutine after receiving one complete chunk.

In the end this probably means that you have a read_chunk_header
function and a read_chunk function.  READ has a loop that calls
read_chunk_header followed by direct reading into the QEMUIOVector,
while everyone else calls read_chunk.

Maybe qio_channel_readv/writev_full could have "offset" and "bytes"
arguments.  Most code in iov_send_recv could be cut-and-pasted.  (When
sheepdog is converted to QIOChannel, iov_send_recv can go away).

Paolo



--
Best regards,
Vladimir




Re: [Qemu-devel] [Bug 1327608] Re: monitor socked path is cut a 105 characters

2017-10-03 Thread Eric Blake
On 10/03/2017 05:47 AM, Thomas Huth wrote:
> Triaging old bug tickets... can you still reproduce this issue with the
> latest version of QEMU? Or could we close this ticket nowadays?

This may be fixed by:

commit ad9579aaa16d5b385922d49edac2c96c79bcfb62
Author: Daniel P. Berrange 
Date:   Thu May 25 16:53:00 2017 +0100

sockets: improve error reporting if UNIX socket path is too long

The 'struct sockaddr_un' only allows 108 bytes for the socket
path.

If the user supplies a path, QEMU uses snprintf() to silently
truncate it when too long. This is undesirable because the user
will then be unable to connect to the path they asked for.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH] hw/gen_pcie_root_port: properly set

2017-10-03 Thread Marcel Apfelbaum

On 03/10/2017 0:49, Laszlo Ersek wrote:

On 10/02/17 12:31, Marcel Apfelbaum wrote:

IO_LIMIT and IO_BASE registers should not be writable if
gen_pcie_root_port's io-reserve property is set to 0.
The COMMAND register should have the IO flag read only.


Signed-off-by: Marcel Apfelbaum 
---
  hw/pci-bridge/gen_pcie_root_port.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/hw/pci-bridge/gen_pcie_root_port.c 
b/hw/pci-bridge/gen_pcie_root_port.c
index ed03ffc764..ad4e6aa7ff 100644
--- a/hw/pci-bridge/gen_pcie_root_port.c
+++ b/hw/pci-bridge/gen_pcie_root_port.c
@@ -85,6 +85,13 @@ static void gen_rp_realize(DeviceState *dev, Error **errp)
  rpc->parent_class.exit(d);
  return;
  }
+
+if (!grp->io_reserve) {
+pci_word_test_and_clear_mask(d->wmask + PCI_COMMAND,
+ PCI_COMMAND_IO);
+d->wmask[PCI_IO_BASE] = 0;
+d->wmask[PCI_IO_LIMIT] = 0;
+}
  }
  
  static const VMStateDescription vmstate_rp_dev = {




The patch looks good to me (which doesn't mean much, honestly :) ), but
I think the subject line is truncated. You left off what exactly should
be set properly. (IO base, IO limit, and command registers, presumably.)



Strange, thanks for pointing it out.
I'll send a V2.

Thanks,
Marcel


Thanks!
Laszlo






Re: [Qemu-devel] [PATCH 26/43] windbg: implemented windbg_read_context

2017-10-03 Thread Ladi Prosek
On Tue, Sep 26, 2017 at 1:06 PM, Mihail Abakumov
 wrote:
> Signed-off-by: Mihail Abakumov 
> Signed-off-by: Pavel Dovgalyuk 
> Signed-off-by: Dmitriy Koltunov 
> ---
>  windbgstub-utils.c |   90 
> +++-
>  1 file changed, 89 insertions(+), 1 deletion(-)
>
> diff --git a/windbgstub-utils.c b/windbgstub-utils.c
> index c3ae2ddf5b..23bf4be9f0 100755
> --- a/windbgstub-utils.c
> +++ b/windbgstub-utils.c
> @@ -280,7 +280,95 @@ static KDData *kd;
>  static int windbg_read_context(CPUState *cpu, uint8_t *buf, int len,
> int offset)
>  {
> -return 0;
> +const bool new_mem = (len != sizeof(CPU_CONTEXT) || offset != 0);
> +CPUArchState *env = cpu->env_ptr;
> +CPU_CONTEXT *cc;
> +int err = 0;
> +
> +if (new_mem) {
> +cc = g_new(CPU_CONTEXT, 1);
> +} else {
> +cc = (CPU_CONTEXT *) buf;
> +}
> +
> +memset(cc, 0, len);

This overruns the buffer if len > sizeof(CPU_CONTEXT).

> +
> +cc->ContextFlags = CPU_CONTEXT_ALL;
> +
> +if (cc->ContextFlags & CPU_CONTEXT_SEGMENTS) {
> +cc->SegCs = lduw_p(&env->segs[R_CS].selector);
> +cc->SegDs = lduw_p(&env->segs[R_DS].selector);
> +cc->SegEs = lduw_p(&env->segs[R_ES].selector);
> +cc->SegFs = lduw_p(&env->segs[R_FS].selector);
> +cc->SegGs = lduw_p(&env->segs[R_GS].selector);
> +cc->SegSs = lduw_p(&env->segs[R_SS].selector);
> +}
> +
> +if (cc->ContextFlags & CPU_CONTEXT_DEBUG_REGISTERS) {
> +cc->Dr0 = ldtul_p(&env->dr[0]);
> +cc->Dr1 = ldtul_p(&env->dr[1]);
> +cc->Dr2 = ldtul_p(&env->dr[2]);
> +cc->Dr3 = ldtul_p(&env->dr[3]);
> +cc->Dr6 = ldtul_p(&env->dr[6]);
> +cc->Dr7 = ldtul_p(&env->dr[7]);
> +}
> +
> +if (cc->ContextFlags & CPU_CONTEXT_INTEGER) {
> +cc->Edi= ldl_p(&env->regs[R_EDI]);
> +cc->Esi= ldl_p(&env->regs[R_ESI]);
> +cc->Ebx= ldl_p(&env->regs[R_EBX]);
> +cc->Edx= ldl_p(&env->regs[R_EDX]);
> +cc->Ecx= ldl_p(&env->regs[R_ECX]);
> +cc->Eax= ldl_p(&env->regs[R_EAX]);
> +cc->Ebp= ldl_p(&env->regs[R_EBP]);
> +cc->Esp= ldl_p(&env->regs[R_ESP]);
> +
> +cc->Eip= ldl_p(&env->eip);
> +cc->EFlags = ldl_p(&env->eflags);
> +}
> +
> +if (cc->ContextFlags & CPU_CONTEXT_FLOATING_POINT) {
> +uint32_t swd = 0, twd = 0;
> +swd = env->fpus & ~(7 << 11);
> +swd |= (env->fpstt & 7) << 11;
> +int i;
> +for (i = 0; i < 8; ++i) {
> +twd |= (!env->fptags[i]) << i;
> +}
> +
> +cc->FloatSave.ControlWord= ldl_p(&env->fpuc);
> +cc->FloatSave.StatusWord = ldl_p(&swd);
> +cc->FloatSave.TagWord= ldl_p(&twd);
> +cc->FloatSave.ErrorOffset= ldl_p(PTR(env->fpip));
> +cc->FloatSave.ErrorSelector  = ldl_p(PTR(env->fpip) + 32);
> +cc->FloatSave.DataOffset = ldl_p(PTR(env->fpdp));
> +cc->FloatSave.DataSelector   = ldl_p(PTR(env->fpdp) + 32);
> +cc->FloatSave.Cr0NpxState= ldl_p(&env->xcr0);
> +
> +for (i = 0; i < 8; ++i) {
> +memcpy(PTR(cc->FloatSave.RegisterArea[i * 10]),
> +   PTR(env->fpregs[i]), 10);
> +}
> +}
> +
> +if (cc->ContextFlags & CPU_CONTEXT_EXTENDED_REGISTERS) {
> +uint8_t *ptr = cc->ExtendedRegisters + 160;
> +int i;
> +for (i = 0; i < 8; ++i, ptr += 16) {
> +stq_p(ptr, env->xmm_regs[i].ZMM_Q(0));
> +stq_p(ptr + 8, env->xmm_regs[i].ZMM_Q(1));
> +}
> +
> +stl_p(cc->ExtendedRegisters + 24, env->mxcsr);
> +}
> +
> +cc->ContextFlags = ldl_p(&cc->ContextFlags);
> +
> +if (new_mem) {
> +memcpy(buf, (uint8_t *) cc + offset, len);
> +g_free(cc);
> +}
> +return err;
>  }
>
>  static int windbg_write_context(CPUState *cpu, uint8_t *buf, int len,
>



Re: [Qemu-devel] [PATCH 28/43] windbg: implemented windbg_read_ks_regs

2017-10-03 Thread Ladi Prosek
On Tue, Sep 26, 2017 at 1:06 PM, Mihail Abakumov
 wrote:
> Signed-off-by: Mihail Abakumov 
> Signed-off-by: Pavel Dovgalyuk 
> Signed-off-by: Dmitriy Koltunov 
> ---
>  windbgstub-utils.c |   38 ++
>  1 file changed, 38 insertions(+)
>
> diff --git a/windbgstub-utils.c b/windbgstub-utils.c
> index 73ff98dfbc..537ba9e2aa 100755
> --- a/windbgstub-utils.c
> +++ b/windbgstub-utils.c
> @@ -587,6 +587,44 @@ static int windbg_write_context(CPUState *cpu, uint8_t 
> *buf, int len,
>  static int windbg_read_ks_regs(CPUState *cpu, uint8_t *buf, int len,
> int offset)
>  {
> +CPUArchState *env = cpu->env_ptr;
> +const bool new_mem = (len != sizeof(CPU_KSPECIAL_REGISTERS)
> +   || offset != 0);
> +CPU_KSPECIAL_REGISTERS *ckr;
> +if (new_mem) {
> +ckr = g_new(CPU_KSPECIAL_REGISTERS, 1);
> +} else {
> +ckr = (CPU_KSPECIAL_REGISTERS *) buf;
> +}
> +
> +memset(ckr, 0, len);

Buffer overrun on len > sizeof(CPU_KSPECIAL_REGISTERS).

> +ckr->Cr0 = ldl_p(&env->cr[0]);
> +ckr->Cr2 = ldl_p(&env->cr[2]);
> +ckr->Cr3 = ldl_p(&env->cr[3]);
> +ckr->Cr4 = ldl_p(&env->cr[4]);
> +
> +ckr->KernelDr0 = ldtul_p(&env->dr[0]);
> +ckr->KernelDr1 = ldtul_p(&env->dr[1]);
> +ckr->KernelDr2 = ldtul_p(&env->dr[2]);
> +ckr->KernelDr3 = ldtul_p(&env->dr[3]);
> +ckr->KernelDr6 = ldtul_p(&env->dr[6]);
> +ckr->KernelDr7 = ldtul_p(&env->dr[7]);
> +
> +ckr->Gdtr.Pad = lduw_p(&env->gdt.selector);
> +ckr->Idtr.Pad = lduw_p(&env->idt.selector);
> +
> +ckr->Gdtr.Limit = lduw_p(&env->gdt.limit);
> +ckr->Gdtr.Base  = ldtul_p(&env->gdt.base);
> +ckr->Idtr.Limit = lduw_p(&env->idt.limit);
> +ckr->Idtr.Base  = ldtul_p(&env->idt.base);
> +ckr->Tr = lduw_p(&env->tr.selector);
> +ckr->Ldtr   = lduw_p(&env->ldt.selector);
> +
> +if (new_mem) {
> +memcpy(buf, (uint8_t *) ckr + offset, len);
> +g_free(ckr);
> +}
>  return 0;
>  }
>
>



[Qemu-devel] [PATCH v4 0/2] virtio: introduce `info virtio' hmp command

2017-10-03 Thread Jan Dakinevich
v4:
 * Implement `query-virtio' QMP
 * Split the work into QMP and HMP parts

v3: http://lists.nongnu.org/archive/html/qemu-devel/2017-09/msg07565.html
v2: http://lists.nongnu.org/archive/html/qemu-devel/2017-09/msg07527.html
v1: http://lists.nongnu.org/archive/html/qemu-devel/2017-09/msg07247.html

Jan Dakinevich (2):
  virtio: introduce `query-virtio' QMP command
  virtio: add `info virtio' HMP command

 hmp-commands-info.hx|  14 ++
 hmp.c   |  79 ++
 hmp.h   |   1 +
 hw/block/virtio-blk.c   |  21 +
 hw/char/virtio-serial-bus.c |  15 +++
 hw/display/virtio-gpu.c |  13 ++
 hw/net/virtio-net.c |  35 +++
 hw/scsi/virtio-scsi.c   |  16 +++
 hw/virtio/Makefile.objs |   2 +
 hw/virtio/virtio-balloon.c  |  15 +++
 hw/virtio/virtio-stub.c |   9 
 hw/virtio/virtio.c  | 101 
 include/hw/virtio/virtio.h  |   2 +
 qapi-schema.json|   1 +
 qapi/virtio.json|  94 +
 15 files changed, 418 insertions(+)
 create mode 100644 hw/virtio/virtio-stub.c
 create mode 100644 qapi/virtio.json

-- 
2.1.4




[Qemu-devel] [PATCH v4 2/2] virtio: add `info virtio' HMP command

2017-10-03 Thread Jan Dakinevich
The command prints data from `query-virtio' QMP in human-readable
format.

Cc: Denis V. Lunev 
Signed-off-by: Jan Dakinevich 
---
 hmp-commands-info.hx | 14 ++
 hmp.c| 79 
 hmp.h|  1 +
 3 files changed, 94 insertions(+)

diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
index 4f1ece9..2550027 100644
--- a/hmp-commands-info.hx
+++ b/hmp-commands-info.hx
@@ -868,6 +868,20 @@ ETEXI
 },
 
 STEXI
+@item info virtio
+@findex virtio
+Display guest and host fetures for all virtio devices.
+ETEXI
+
+{
+.name   = "virtio",
+.args_type  = "",
+.params = "",
+.help   = "show virtio info",
+.cmd= hmp_info_virtio,
+},
+
+STEXI
 @end table
 ETEXI
 
diff --git a/hmp.c b/hmp.c
index ace729d..c4dd280 100644
--- a/hmp.c
+++ b/hmp.c
@@ -43,6 +43,7 @@
 #include "hw/intc/intc.h"
 #include "migration/snapshot.h"
 #include "migration/misc.h"
+#include "hw/virtio/virtio.h"
 
 #ifdef CONFIG_SPICE
 #include 
@@ -2894,3 +2895,81 @@ void hmp_info_memory_size_summary(Monitor *mon, const 
QDict *qdict)
 }
 hmp_handle_error(mon, &err);
 }
+
+#define HMP_INFO_VIRTIO_INDENT 2
+#define HMP_INFO_VIRTIO_FIELD 32
+
+static void hmp_info_virtio_print_status(Monitor *mon, VirtioInfo *info,
+ VirtioInfoDevice *device)
+{
+VirtioInfoBitList *lbit;
+const char *comma = "";
+
+for (lbit = info->status_names; lbit; lbit = lbit->next) {
+if (!(device->status & (1ull << lbit->value->bit))) {
+continue;
+}
+monitor_printf(mon, "%s%s", comma, lbit->value->name);
+comma = ",";
+}
+monitor_printf(mon, "\n");
+}
+
+static void hmp_info_virtio_print_features(Monitor *mon,
+   VirtioInfoBitList *list,
+   VirtioInfoDevice *device)
+{
+VirtioInfoBitList *lbit;
+
+for (lbit = list; lbit; lbit = lbit->next) {
+const char *ack = virtio_has_feature(device->guest_features,
+ lbit->value->bit) ? "acked" : "";
+if (!virtio_has_feature(device->host_features, lbit->value->bit)) {
+continue;
+}
+monitor_printf(mon, "%*s%*s%*s\n", HMP_INFO_VIRTIO_INDENT, "",
+   HMP_INFO_VIRTIO_FIELD, lbit->value->name,
+   HMP_INFO_VIRTIO_FIELD, ack);
+}
+}
+
+static void hmp_info_virtio_print(Monitor *mon, VirtioInfo *info,
+  VirtioInfoDevice *device)
+{
+Object *obj = object_resolve_path(device->qom_path, NULL);
+char *path = qdev_get_dev_path(DEVICE(obj));
+
+monitor_printf(mon, "%s at %s\n", object_get_typename(obj), path);
+g_free(path);
+
+monitor_printf(mon, "%*sstatus:   0x%02"PRIx64" ",
+   HMP_INFO_VIRTIO_INDENT, "", device->status);
+hmp_info_virtio_print_status(mon, info, device);
+
+monitor_printf(mon, "%*shost features:0x%016"PRIx64"\n",
+   HMP_INFO_VIRTIO_INDENT, "", device->host_features);
+monitor_printf(mon, "%*sguest features:   0x%016"PRIx64"\n",
+   HMP_INFO_VIRTIO_INDENT, "", device->guest_features);
+
+monitor_printf(mon, "%*scommon features:\n", HMP_INFO_VIRTIO_INDENT, "");
+hmp_info_virtio_print_features(mon, info->feature_names, device);
+
+monitor_printf(mon, "%*sspecific features:\n", HMP_INFO_VIRTIO_INDENT, "");
+hmp_info_virtio_print_features(mon, device->feature_names, device);
+}
+
+void hmp_info_virtio(Monitor *mon, const QDict *qdict)
+{
+Error *err = NULL;
+VirtioInfo *info;
+VirtioInfoDeviceList *ldevice;
+
+info = qmp_query_virtio(&err);
+if (err) {
+return;
+}
+
+for (ldevice = info->devices; ldevice; ldevice = ldevice->next) {
+hmp_info_virtio_print(mon, info, ldevice->value);
+}
+}
diff --git a/hmp.h b/hmp.h
index 3605003..3e8f30a 100644
--- a/hmp.h
+++ b/hmp.h
@@ -146,5 +146,6 @@ void hmp_info_ramblock(Monitor *mon, const QDict *qdict);
 void hmp_hotpluggable_cpus(Monitor *mon, const QDict *qdict);
 void hmp_info_vm_generation_id(Monitor *mon, const QDict *qdict);
 void hmp_info_memory_size_summary(Monitor *mon, const QDict *qdict);
+void hmp_info_virtio(Monitor *mon, const QDict *qdict);
 
 #endif
-- 
2.1.4




[Qemu-devel] [PATCH v4 1/2] virtio: introduce `query-virtio' QMP command

2017-10-03 Thread Jan Dakinevich
The command is intended for gathering virtio information such as status,
feature bits, negotiation status. It is convenient and useful for debug
purpose.

The commands returns generic virtio information for virtio such as
common feature names and status bits names and information for all
attached to current machine devices.

To retrieve names of device-specific features `get_feature_name'
callback in VirtioDeviceClass also was introduced.

Cc: Denis V. Lunev 
Signed-off-by: Jan Dakinevich 
---
 hw/block/virtio-blk.c   |  21 +
 hw/char/virtio-serial-bus.c |  15 +++
 hw/display/virtio-gpu.c |  13 ++
 hw/net/virtio-net.c |  35 +++
 hw/scsi/virtio-scsi.c   |  16 +++
 hw/virtio/Makefile.objs |   2 +
 hw/virtio/virtio-balloon.c  |  15 +++
 hw/virtio/virtio-stub.c |   9 
 hw/virtio/virtio.c  | 101 
 include/hw/virtio/virtio.h  |   2 +
 qapi-schema.json|   1 +
 qapi/virtio.json|  94 +
 12 files changed, 324 insertions(+)
 create mode 100644 hw/virtio/virtio-stub.c
 create mode 100644 qapi/virtio.json

diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 05d1440..c77f651 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -1017,6 +1017,26 @@ static Property virtio_blk_properties[] = {
 DEFINE_PROP_END_OF_LIST(),
 };
 
+static const char *virtio_blk_get_feature_name(VirtIODevice *vdev,
+   unsigned feature)
+{
+static const char *names[] = {
+[VIRTIO_BLK_F_BARRIER] = "barrier",
+[VIRTIO_BLK_F_SIZE_MAX] = "size_max",
+[VIRTIO_BLK_F_SEG_MAX] = "seg_max",
+[VIRTIO_BLK_F_RO] = "ro",
+[VIRTIO_BLK_F_BLK_SIZE] = "blk_size",
+[VIRTIO_BLK_F_SCSI] = "scsi",
+[VIRTIO_BLK_F_TOPOLOGY] = "topology",
+[VIRTIO_BLK_F_FLUSH] = "flush",
+[VIRTIO_BLK_F_MQ] = "mq",
+};
+if (feature >= ARRAY_SIZE(names)) {
+return NULL;
+}
+return names[feature];
+}
+
 static void virtio_blk_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
@@ -1030,6 +1050,7 @@ static void virtio_blk_class_init(ObjectClass *klass, 
void *data)
 vdc->get_config = virtio_blk_update_config;
 vdc->set_config = virtio_blk_set_config;
 vdc->get_features = virtio_blk_get_features;
+vdc->get_feature_name = virtio_blk_get_feature_name;
 vdc->set_status = virtio_blk_set_status;
 vdc->reset = virtio_blk_reset;
 vdc->save = virtio_blk_save_device;
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 9470bd7..41f4466 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -1156,6 +1156,20 @@ static Property virtio_serial_properties[] = {
 DEFINE_PROP_END_OF_LIST(),
 };
 
+static const char *virtio_serial_get_feature_name(VirtIODevice *vdev,
+  unsigned feature)
+{
+static const char *names[] = {
+[VIRTIO_CONSOLE_F_SIZE] = "size",
+[VIRTIO_CONSOLE_F_MULTIPORT] = "multiport",
+[VIRTIO_CONSOLE_F_EMERG_WRITE] = "emerg_write",
+};
+if (feature >= ARRAY_SIZE(names)) {
+return NULL;
+}
+return names[feature];
+}
+
 static void virtio_serial_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
@@ -1170,6 +1184,7 @@ static void virtio_serial_class_init(ObjectClass *klass, 
void *data)
 vdc->realize = virtio_serial_device_realize;
 vdc->unrealize = virtio_serial_device_unrealize;
 vdc->get_features = get_features;
+vdc->get_feature_name = virtio_serial_get_feature_name;
 vdc->get_config = get_config;
 vdc->set_config = set_config;
 vdc->set_status = set_status;
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 3a8f1e1..49aa214 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1307,6 +1307,18 @@ static Property virtio_gpu_properties[] = {
 DEFINE_PROP_END_OF_LIST(),
 };
 
+static const char *virtio_gpu_get_feature_name(VirtIODevice *vdev,
+   unsigned feature)
+{
+static const char *names[] = {
+[VIRTIO_GPU_F_VIRGL] = "virgl",
+};
+if (feature >= ARRAY_SIZE(names)) {
+return NULL;
+}
+return names[feature];
+}
+
 static void virtio_gpu_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
@@ -1317,6 +1329,7 @@ static void virtio_gpu_class_init(ObjectClass *klass, 
void *data)
 vdc->get_config = virtio_gpu_get_config;
 vdc->set_config = virtio_gpu_set_config;
 vdc->get_features = virtio_gpu_get_features;
+vdc->get_feature_name = virtio_gpu_get_feature_name;
 vdc->set_features = virtio_gpu_set_features;
 
 vdc->reset = virtio_gpu_reset;
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-n

Re: [Qemu-devel] [PULL 0/5] Docker testing patches

2017-10-03 Thread Peter Maydell
On 29 September 2017 at 04:18, Fam Zheng  wrote:
> The following changes since commit ab161529261928ae7f3556e3220829c34b2686ec:
>
>   Merge remote-tracking branch 
> 'remotes/dgilbert/tags/pull-migration-20170927a' into staging (2017-09-27 
> 22:44:51 +0100)
>
> are available in the git repository at:
>
>   git://github.com/famz/qemu.git tags/docker-testing-pull-request
>
> for you to fetch changes up to 36ac78e65a0695f0e397865cceaf4ab5c4e52c64:
>
>   docker: Don't mount ccache db if NOUSER=1 (2017-09-29 11:14:15 +0800)
>
> 
>
> 
>
> Alex Bennée (1):
>   tests/docker/run: don't source /etc/profile
>
> Fam Zheng (3):
>   docker: Fix test-mingw
>   docker: test-block: Don't continue if build fails
>   docker: Don't mount ccache db if NOUSER=1
>
> Paolo Bonzini (1):
>   docker: add installation to build tests
>

Applied, thanks.

-- PMM



Re: [Qemu-devel] [PATCH 33/43] windbg: implemented windbg_hw_breakpoint_insert and windbg_hw_breakpoint_remove

2017-10-03 Thread Ladi Prosek
On Tue, Sep 26, 2017 at 1:07 PM, Mihail Abakumov
 wrote:
> Signed-off-by: Mihail Abakumov 
> Signed-off-by: Pavel Dovgalyuk 
> Signed-off-by: Dmitriy Koltunov 
> ---
>  windbgstub-utils.c |   60 
> 
>  1 file changed, 60 insertions(+)
>
> diff --git a/windbgstub-utils.c b/windbgstub-utils.c
> index e33789725e..05caf98c0c 100755
> --- a/windbgstub-utils.c
> +++ b/windbgstub-utils.c
> @@ -294,11 +294,71 @@ static KDData *kd;
>
>  static int windbg_hw_breakpoint_insert(CPUState *cpu, int index)
>  {
> +CPUArchState *env = cpu->env_ptr;
> +
> +if (!IS_BP_ENABLED(env->dr[7], index)) {

nit: This is already checked by both callers.

> +return 0;
> +}
> +
> +target_ulong addr = env->dr[index];
> +int type = BP_TYPE(env->dr[7], index);
> +int len = BP_LEN(env->dr[7], index);
> +int err = 0;
> +
> +switch (type) {
> +case DR7_TYPE_DATA_WR:
> +err = cpu_watchpoint_insert(cpu, addr, len, BP_MEM_WRITE | BP_GDB,
> +&env->cpu_watchpoint[index]);
> +break;
> +case DR7_TYPE_DATA_RW:
> +err = cpu_watchpoint_insert(cpu, addr, len, BP_MEM_ACCESS | BP_GDB,
> +&env->cpu_watchpoint[index]);
> +break;
> +case DR7_TYPE_BP_INST:
> +err = cpu_breakpoint_insert(cpu, addr, BP_GDB,
> +&env->cpu_breakpoint[index]);
> +break;
> +case DR7_TYPE_IO_RW:
> +return HF_IOBPT_MASK;
> +default:
> +return 0;
> +}
> +
> +if (!err) {
> +WINDBG_DEBUG("hw_breakpoint_insert: index(%d), " FMT_ADDR,
> + index, addr);
> +} else {
> +env->cpu_breakpoint[index] = NULL;
> +WINDBG_ERROR("hw_breakpoint_insert: index(%d), " FMT_ADDR ", " 
> FMT_ERR,
> + index, addr, err);
> +}
>  return 0;
>  }
>
>  static int windbg_hw_breakpoint_remove(CPUState *cpu, int index)
>  {
> +CPUArchState *env = cpu->env_ptr;
> +int type = BP_TYPE(env->dr[7], index);
> +
> +switch (type) {
> +case DR7_TYPE_BP_INST:
> +if (env->cpu_breakpoint[index]) {
> +cpu_breakpoint_remove_by_ref(cpu, env->cpu_breakpoint[index]);
> +}
> +break;
> +case DR7_TYPE_DATA_WR:
> +case DR7_TYPE_DATA_RW:
> +if (env->cpu_watchpoint[index]) {
> +cpu_watchpoint_remove_by_ref(cpu, env->cpu_watchpoint[index]);
> +}
> +break;
> +default:
> +return 0;
> +}
> +
> +env->cpu_breakpoint[index] = NULL;
> +WINDBG_DEBUG("hw_breakpoint_remove: index(%d), " FMT_ADDR,
> + index, env->dr[index]);
>  return 0;
>  }
>
>



Re: [Qemu-devel] [Qemu-block] [PATCH 8/8] nbd: Minimal structured read for client

2017-10-03 Thread Vladimir Sementsov-Ogievskiy

03.10.2017 13:07, Paolo Bonzini wrote:

On 26/09/2017 00:19, Eric Blake wrote:

+/* here we deal with successful structured reply */
+switch (s->reply.type) {
+QEMUIOVector sub_qiov;
+case NBD_SREP_TYPE_OFFSET_DATA:

This is putting a LOT of smarts directly into the receive routine.
Here's where I was previously wondering (and I think Paolo as well)
whether it might be better to split the efforts: the generic function
reads off the chunk information and any payload, but a per-command
callback function then parses the chunks.  Especially since the
definition of the chunks differs on a per-command basis (yes, the NBD
spec will try to not reuse an SREP chunk type across multiple commands
unless the semantics are similar, but that's a bit more fragile).  This
particularly matters given my statement above that you want a
discriminated union, rather than a struct that contains unused fields,
for handling different SREP chunk types.

I think there should be two kinds of replies: 1) read directly into a
QEMUIOVector, using structured replies only as an encapsulation of the
payload; 2) read a chunk at a time into malloc-ed memory, yielding back
to the calling coroutine after receiving one complete chunk.

In the end this probably means that you have a read_chunk_header
function and a read_chunk function.  READ has a loop that calls
read_chunk_header followed by direct reading into the QEMUIOVector,
while everyone else calls read_chunk.


accordingly to spec, we can receive several error reply chunks to any 
request,

so loop, receiving them should be common for all requests I think



Maybe qio_channel_readv/writev_full could have "offset" and "bytes"
arguments.  Most code in iov_send_recv could be cut-and-pasted.  (When
sheepdog is converted to QIOChannel, iov_send_recv can go away).

Paolo



--
Best regards,
Vladimir




Re: [Qemu-devel] [PATCH 06/38] lm32: cleanup cpu type name composition

2017-10-03 Thread Michael Walle

Am 2017-10-02 11:07, schrieb Igor Mammedov:

introduce LM32_CPU_TYPE_NAME macro and consistently use it
to construct cpu type names. While at it replace dynamic
cpu type name composition with static data.

Signed-off-by: Igor Mammedov 
---
CC: mich...@walle.cc
---
 target/lm32/cpu.h |  3 +++
 target/lm32/cpu.c | 74 
+--

 2 files changed, 25 insertions(+), 52 deletions(-)



Acked-by: Michael Walle 



Re: [Qemu-devel] [PATCH 08/38] lm32: lm32_boards: use generic cpu_model parsing

2017-10-03 Thread Michael Walle

Am 2017-10-02 11:07, schrieb Igor Mammedov:

Signed-off-by: Igor Mammedov 
---
CC: mich...@walle.cc
---
 hw/lm32/lm32_boards.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)



Acked-by: Michael Walle 



Re: [Qemu-devel] [PATCH 07/38] lm32: milkymist: use generic cpu_model parsing

2017-10-03 Thread Michael Walle

Am 2017-10-02 11:07, schrieb Igor Mammedov:

Signed-off-by: Igor Mammedov 
---
CC: mich...@walle.cc
---
 hw/lm32/milkymist.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)



Acked-by: Michael Walle 



Re: [Qemu-devel] [RFC 24/29] vhost+postcopy: Lock around set_mem_table

2017-10-03 Thread Dr. David Alan Gilbert
* Dr. David Alan Gilbert (dgilb...@redhat.com) wrote:
> * Maxime Coquelin (maxime.coque...@redhat.com) wrote:
> > 
> > 
> > On 06/28/2017 09:00 PM, Dr. David Alan Gilbert (git) wrote:
> > > From: "Dr. David Alan Gilbert"
> > > 
> > > **HACK - better solution needed **
> > > We have the situation where:
> > > 
> > >   qemu  bridge
> > > 
> > >   send set_mem_table
> > >map memory
> > >a)  mark area with UFD
> > >send reply with map addresses
> > >b)  start using
> > >c) receive reply
> > > 
> > >As soon as (a) happens qemu might start seeing faults
> > > from memory accesses (but doesn't until b); but it can't
> > > process those faults until (c) when it's received the
> > > mmap addresses.
> > > 
> > > Make the fault handler spin until it gets the reply in (c).
> > > 
> > > At the very least this needs some proper locks, but preferably
> > > we need to split the message.
> > 
> > Yes, maybe the slave channel could be used to send the ufds with
> > a dedicated request? The backend would set the reply-ack flag, so that
> > it starts accessing the guest memory only when Qemu is ready to handle
> > faults.
> 
> Yes, that would make life a lot easier.
> 
> > Note that the slave channel support has not been implemented in Qemu's
> > libvhost-user yet, but this is something I can do if we feel the need.
> 
> Can you tell me a bit about how the slave channel works?

I've looked at the slave-channel; and I'm worried that it's not suitable
for this case.
The problem is that 'slave_read' is wired to a fd_handler that I think
is serviced by the main thread, and while postcopy is running I don't
want to rely on the operation of the main thread (since it could be
blocked by a page fault).
I could still use an explicit ack at that point though over the main
channel I think (or use the slave synchronously?).

Dave

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



Re: [Qemu-devel] [PULL 0/5] Ui 20170929 patches

2017-10-03 Thread Peter Maydell
On 29 September 2017 at 11:21, Gerd Hoffmann  wrote:
> The following changes since commit ab161529261928ae7f3556e3220829c34b2686ec:
>
>   Merge remote-tracking branch 
> 'remotes/dgilbert/tags/pull-migration-20170927a' into staging (2017-09-27 
> 22:44:51 +0100)
>
> are available in the git repository at:
>
>   git://git.kraxel.org/qemu tags/ui-20170929-pull-request
>
> for you to fetch changes up to 7364dbdabb7824d5bde1e341bb6d928282f01c83:
>
>   ui: add tracing of VNC authentication process (2017-09-29 10:36:34 +0200)
>
> 
> ui and input patches.
>
> 
>
> Daniel P. Berrange (2):
>   ui: add tracing of VNC operations related to QIOChannel
>   ui: add tracing of VNC authentication process
>
> Gerd Hoffmann (3):
>   console: purge curses bits from console.h
>   egl: misc framebuffer helper improvements.
>   virtio-input: send rel-wheel events for wheel buttons

Applied, thanks.

-- PMM



Re: [Qemu-devel] [PATCH] qom: add helpers REGISTER_STATIC_TYPE[S]()

2017-10-03 Thread Philippe Mathieu-Daudé
Hi Igor,

On 10/03/2017 09:14 AM, Igor Mammedov wrote:
> it will help to remove code duplication in places
> that currently open code registration of static
> type[s] and remove necessity to declare function
> for type_init() to call, when only static types
> need to be registered.
> 
> Signed-off-by: Igor Mammedov 
> ---
> I'm going to use it for CPU types in followup patches
> 
> CC: ehabk...@redhat.com
> ---
>  include/qemu/module.h | 10 ++
>  include/qom/object.h  | 10 ++
>  qom/object.c  |  9 +
>  3 files changed, 29 insertions(+)
> 
> diff --git a/include/qemu/module.h b/include/qemu/module.h
> index 56dd218..60dd632 100644
> --- a/include/qemu/module.h
> +++ b/include/qemu/module.h
> @@ -52,6 +52,16 @@ typedef enum {
>  #define type_init(function) module_init(function, MODULE_INIT_QOM)
>  #define trace_init(function) module_init(function, MODULE_INIT_TRACE)
>  
> +#define REGISTER_STATIC_TYPES(t, nr)\

ok

> +static void do_qemu_init_ ## t(void)\
> +{   \
> +type_register_static_array(t, nr);  \
> +}   \
> +type_init(do_qemu_init_ ## t)
> +
> +#define REGISTER_STATIC_TYPE(t) \

eh why not...

What's your plan for your "generalize parsing of cpu_model (2)" series?
re-post the whole? If you just change this macro you can keep my R-b for it.

> +REGISTER_STATIC_TYPES(t, 1)
> +
>  #define block_module_load_one(lib) module_load_one("block-", lib)
>  
>  void register_module_init(void (*fn)(void), module_init_type type);
> diff --git a/include/qom/object.h b/include/qom/object.h
> index f3e5cff..17fcadd 100644
> --- a/include/qom/object.h
> +++ b/include/qom/object.h
> @@ -789,6 +789,16 @@ Type type_register_static(const TypeInfo *info);
>  Type type_register(const TypeInfo *info);
>  
>  /**
> + * type_register_static_array:
> + * @infos: The array of the new type #TypeInfo structures.
> + * @nr_infos: number of entries in @infos
> + *
> + * @infos and all of the strings it points to should exist for the life time
> + * that the type is registered.
> + */
> +void type_register_static_array(const TypeInfo *infos, int nr_infos);
> +
> +/**
>   * object_class_dynamic_cast_assert:
>   * @klass: The #ObjectClass to attempt to cast.
>   * @typename: The QOM typename of the class to cast to.
> diff --git a/qom/object.c b/qom/object.c
> index 3e18537..40b1729 100644
> --- a/qom/object.c
> +++ b/qom/object.c
> @@ -151,6 +151,15 @@ TypeImpl *type_register_static(const TypeInfo *info)
>  return type_register(info);
>  }
>  
> +void type_register_static_array(const TypeInfo *infos, int nr_infos)
> +{
> +int i;
> +
> +for (i = 0; i < nr_infos; i++) {
> +assert(type_register_static(&infos[i]));
> +}
> +}

Reviewed-by: Philippe Mathieu-Daudé 

> +
>  static TypeImpl *type_get_by_name(const char *name)
>  {
>  if (name == NULL) {
> 



Re: [Qemu-devel] [PATCH 09/38] m68k: cleanup cpu type name composition

2017-10-03 Thread Philippe Mathieu-Daudé
On 10/02/2017 06:07 AM, Igor Mammedov wrote:
> use new M68K_CPU_TYPE_NAME to compose CPU type names
> and get rid of intermediate M68kCPUInfo/register_cpu_type()
> which is replaced by static TypeInfo array.
> 
> Signed-off-by: Igor Mammedov 

Reviewed-by: Philippe Mathieu-Daudé 

> ---
> CC: laur...@vivier.eu
> ---
>  target/m68k/cpu.h |  3 +++
>  target/m68k/cpu.c | 75 
> ---
>  2 files changed, 30 insertions(+), 48 deletions(-)
> 
> diff --git a/target/m68k/cpu.h b/target/m68k/cpu.h
> index d936547..afae5f6 100644
> --- a/target/m68k/cpu.h
> +++ b/target/m68k/cpu.h
> @@ -323,6 +323,9 @@ void register_m68k_insns (CPUM68KState *env);
>  
>  #define cpu_init(cpu_model) cpu_generic_init(TYPE_M68K_CPU, cpu_model)
>  
> +#define M68K_CPU_TYPE_SUFFIX "-" TYPE_M68K_CPU
> +#define M68K_CPU_TYPE_NAME(model) model M68K_CPU_TYPE_SUFFIX
> +
>  #define cpu_signal_handler cpu_m68k_signal_handler
>  #define cpu_list m68k_cpu_list
>  
> diff --git a/target/m68k/cpu.c b/target/m68k/cpu.c
> index 8c70e08..f0f90e9 100644
> --- a/target/m68k/cpu.c
> +++ b/target/m68k/cpu.c
> @@ -87,7 +87,7 @@ static ObjectClass *m68k_cpu_class_by_name(const char 
> *cpu_model)
>  ObjectClass *oc;
>  char *typename;
>  
> -typename = g_strdup_printf("%s-" TYPE_M68K_CPU, cpu_model);
> +typename = g_strdup_printf(M68K_CPU_TYPE_NAME("%s"), cpu_model);
>  oc = object_class_by_name(typename);
>  g_free(typename);
>  if (oc != NULL && (object_class_dynamic_cast(oc, TYPE_M68K_CPU) == NULL 
> ||
> @@ -202,23 +202,6 @@ static void any_cpu_initfn(Object *obj)
>  m68k_set_feature(env, M68K_FEATURE_WORD_INDEX);
>  }
>  
> -typedef struct M68kCPUInfo {
> -const char *name;
> -void (*instance_init)(Object *obj);
> -} M68kCPUInfo;
> -
> -static const M68kCPUInfo m68k_cpus[] = {
> -{ .name = "m68000", .instance_init = m68000_cpu_initfn },
> -{ .name = "m68020", .instance_init = m68020_cpu_initfn },
> -{ .name = "m68030", .instance_init = m68030_cpu_initfn },
> -{ .name = "m68040", .instance_init = m68040_cpu_initfn },
> -{ .name = "m68060", .instance_init = m68060_cpu_initfn },
> -{ .name = "m5206", .instance_init = m5206_cpu_initfn },
> -{ .name = "m5208", .instance_init = m5208_cpu_initfn },
> -{ .name = "cfv4e", .instance_init = cfv4e_cpu_initfn },
> -{ .name = "any",   .instance_init = any_cpu_initfn },
> -};
> -
>  static void m68k_cpu_realizefn(DeviceState *dev, Error **errp)
>  {
>  CPUState *cs = CPU(dev);
> @@ -295,36 +278,32 @@ static void m68k_cpu_class_init(ObjectClass *c, void 
> *data)
>  dc->vmsd = &vmstate_m68k_cpu;
>  }
>  
> -static void register_cpu_type(const M68kCPUInfo *info)
> -{
> -TypeInfo type_info = {
> -.parent = TYPE_M68K_CPU,
> -.instance_init = info->instance_init,
> -};
> -
> -type_info.name = g_strdup_printf("%s-" TYPE_M68K_CPU, info->name);
> -type_register(&type_info);
> -g_free((void *)type_info.name);
> -}
> +#define DEFINE_M68K_CPU_TYPE(cpu_model, initfn) \
> +{   \
> +.name = M68K_CPU_TYPE_NAME(cpu_model),  \
> +.instance_init = initfn,\
> +.parent = TYPE_M68K_CPU,\
> +}
>  
> -static const TypeInfo m68k_cpu_type_info = {
> -.name = TYPE_M68K_CPU,
> -.parent = TYPE_CPU,
> -.instance_size = sizeof(M68kCPU),
> -.instance_init = m68k_cpu_initfn,
> -.abstract = true,
> -.class_size = sizeof(M68kCPUClass),
> -.class_init = m68k_cpu_class_init,
> +static const TypeInfo m68k_cpus_type_infos[] = {
> +{ /* base class should be registered first */
> +.name = TYPE_M68K_CPU,
> +.parent = TYPE_CPU,
> +.instance_size = sizeof(M68kCPU),
> +.instance_init = m68k_cpu_initfn,
> +.abstract = true,
> +.class_size = sizeof(M68kCPUClass),
> +.class_init = m68k_cpu_class_init,
> +},
> +DEFINE_M68K_CPU_TYPE("m68000", m68000_cpu_initfn),
> +DEFINE_M68K_CPU_TYPE("m68020", m68020_cpu_initfn),
> +DEFINE_M68K_CPU_TYPE("m68030", m68030_cpu_initfn),
> +DEFINE_M68K_CPU_TYPE("m68040", m68040_cpu_initfn),
> +DEFINE_M68K_CPU_TYPE("m68060", m68060_cpu_initfn),
> +DEFINE_M68K_CPU_TYPE("m5206", m5206_cpu_initfn),
> +DEFINE_M68K_CPU_TYPE("m5208", m5208_cpu_initfn),
> +DEFINE_M68K_CPU_TYPE("cfv4e", cfv4e_cpu_initfn),
> +DEFINE_M68K_CPU_TYPE("any", any_cpu_initfn),
>  };
>  
> -static void m68k_cpu_register_types(void)
> -{
> -int i;
> -
> -type_register_static(&m68k_cpu_type_info);
> -for (i = 0; i < ARRAY_SIZE(m68k_cpus); i++) {
> -register_cpu_type(&m68k_cpus[i]);
> -}
> -}
> -
> -type_init(m68k_cpu_register_types)
> +type_init_from_array(m68k_cpus_type_infos)
> 



Re: [Qemu-devel] [PATCH 10/38] m68k: an5206: use generic cpu_model parsing

2017-10-03 Thread Philippe Mathieu-Daudé
On 10/02/2017 06:07 AM, Igor Mammedov wrote:
> Signed-off-by: Igor Mammedov 

Reviewed-by: Philippe Mathieu-Daudé 

> ---
> CC: h...@tuxfamily.org
> CC: laur...@vivier.eu
> ---
>  hw/m68k/an5206.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/m68k/an5206.c b/hw/m68k/an5206.c
> index 9002c46..0cedc54 100644
> --- a/hw/m68k/an5206.c
> +++ b/hw/m68k/an5206.c
> @@ -28,7 +28,6 @@
>  static void an5206_init(MachineState *machine)
>  {
>  ram_addr_t ram_size = machine->ram_size;
> -const char *cpu_model = machine->cpu_model;
>  const char *kernel_filename = machine->kernel_filename;
>  M68kCPU *cpu;
>  CPUM68KState *env;
> @@ -39,10 +38,7 @@ static void an5206_init(MachineState *machine)
>  MemoryRegion *ram = g_new(MemoryRegion, 1);
>  MemoryRegion *sram = g_new(MemoryRegion, 1);
>  
> -if (!cpu_model) {
> -cpu_model = "m5206";
> -}
> -cpu = M68K_CPU(cpu_generic_init(TYPE_M68K_CPU, cpu_model));
> +cpu = M68K_CPU(cpu_create(machine->cpu_type));
>  env = &cpu->env;
>  
>  /* Initialize CPU registers.  */
> @@ -94,6 +90,7 @@ static void an5206_machine_init(MachineClass *mc)
>  {
>  mc->desc = "Arnewsh 5206";
>  mc->init = an5206_init;
> +mc->default_cpu_type = M68K_CPU_TYPE_NAME("m5206");
>  }
>  
>  DEFINE_MACHINE("an5206", an5206_machine_init)
> 



Re: [Qemu-devel] [PATCH 11/38] m68k: mcf5208: use generic cpu_model parsing

2017-10-03 Thread Philippe Mathieu-Daudé
On 10/02/2017 06:07 AM, Igor Mammedov wrote:
> Signed-off-by: Igor Mammedov 

Reviewed-by: Philippe Mathieu-Daudé 

> ---
> CC: laur...@vivier.eu
> CC: h...@tuxfamily.org
> ---
>  hw/m68k/mcf5208.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c
> index b9dde75..cfac845 100644
> --- a/hw/m68k/mcf5208.c
> +++ b/hw/m68k/mcf5208.c
> @@ -217,7 +217,6 @@ static void mcf_fec_init(MemoryRegion *sysmem, NICInfo 
> *nd, hwaddr base,
>  static void mcf5208evb_init(MachineState *machine)
>  {
>  ram_addr_t ram_size = machine->ram_size;
> -const char *cpu_model = machine->cpu_model;
>  const char *kernel_filename = machine->kernel_filename;
>  M68kCPU *cpu;
>  CPUM68KState *env;
> @@ -229,10 +228,7 @@ static void mcf5208evb_init(MachineState *machine)
>  MemoryRegion *ram = g_new(MemoryRegion, 1);
>  MemoryRegion *sram = g_new(MemoryRegion, 1);
>  
> -if (!cpu_model) {
> -cpu_model = "m5208";
> -}
> -cpu = M68K_CPU(cpu_generic_init(TYPE_M68K_CPU, cpu_model));
> +cpu = M68K_CPU(cpu_create(machine->cpu_type));
>  env = &cpu->env;
>  
>  /* Initialize CPU registers.  */
> @@ -321,6 +317,7 @@ static void mcf5208evb_machine_init(MachineClass *mc)
>  mc->desc = "MCF5206EVB";
>  mc->init = mcf5208evb_init;
>  mc->is_default = 1;
> +mc->default_cpu_type = M68K_CPU_TYPE_NAME("m5208");
>  }
>  
>  DEFINE_MACHINE("mcf5208evb", mcf5208evb_machine_init)
> 



Re: [Qemu-devel] [PATCH 23/38] xtensa: sim: use generic cpu_model parsing

2017-10-03 Thread Philippe Mathieu-Daudé
On 10/02/2017 06:08 AM, Igor Mammedov wrote:
> Signed-off-by: Igor Mammedov 

Reviewed-by: Philippe Mathieu-Daudé 

> ---
> CC: jcmvb...@gmail.com
> ---
>  hw/xtensa/sim.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/xtensa/sim.c b/hw/xtensa/sim.c
> index b3580b1..2bb883b 100644
> --- a/hw/xtensa/sim.c
> +++ b/hw/xtensa/sim.c
> @@ -75,16 +75,11 @@ static void xtensa_sim_init(MachineState *machine)
>  XtensaCPU *cpu = NULL;
>  CPUXtensaState *env = NULL;
>  ram_addr_t ram_size = machine->ram_size;
> -const char *cpu_model = machine->cpu_model;
>  const char *kernel_filename = machine->kernel_filename;
>  int n;
>  
> -if (!cpu_model) {
> -cpu_model = XTENSA_DEFAULT_CPU_MODEL;
> -}
> -
>  for (n = 0; n < smp_cpus; n++) {
> -cpu = XTENSA_CPU(cpu_generic_init(TYPE_XTENSA_CPU, cpu_model));
> +cpu = XTENSA_CPU(cpu_create(machine->cpu_type));
>  env = &cpu->env;
>  
>  env->sregs[PRID] = n;
> @@ -133,6 +128,7 @@ static void xtensa_sim_machine_init(MachineClass *mc)
>  mc->init = xtensa_sim_init;
>  mc->max_cpus = 4;
>  mc->no_serial = 1;
> +mc->default_cpu_type = XTENSA_DEFAULT_CPU_TYPE;
>  }
>  
>  DEFINE_MACHINE("sim", xtensa_sim_machine_init)
> 



Re: [Qemu-devel] [PATCH 22/38] xtensa: cleanup cpu type name composition

2017-10-03 Thread Philippe Mathieu-Daudé
On 10/03/2017 07:37 AM, Igor Mammedov wrote:
> On Mon, 2 Oct 2017 17:35:39 -0300
> Philippe Mathieu-Daudé  wrote:
> 
>> On 10/02/2017 06:08 AM, Igor Mammedov wrote:
>>> use new XTENSA_CPU_TYPE_NAME to compose CPU type name
>>> to bring xtensa in line with all other targets that
>>> will similar macro.
>>>
>>> Signed-off-by: Igor Mammedov 
>>> ---
>>> CC: jcmvb...@gmail.com
>>> ---
>>>   target/xtensa/cpu.h| 4 
>>>   target/xtensa/cpu.c| 2 +-
>>>   target/xtensa/helper.c | 2 +-
>>>   3 files changed, 6 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/target/xtensa/cpu.h b/target/xtensa/cpu.h
>>> index 4803331..b17d7d9 100644
>>> --- a/target/xtensa/cpu.h
>>> +++ b/target/xtensa/cpu.h
>>> @@ -469,11 +469,15 @@ void xtensa_cpu_do_unaligned_access(CPUState *cpu, 
>>> vaddr addr,
>>>   #define cpu_signal_handler cpu_xtensa_signal_handler
>>>   #define cpu_list xtensa_cpu_list
>>>   
>>> +#define XTENSA_CPU_TYPE_SUFFIX "-" TYPE_XTENSA_CPU
>>> +#define XTENSA_CPU_TYPE_NAME(model) model XTENSA_CPU_TYPE_SUFFIX
>>> +
>>>   #ifdef TARGET_WORDS_BIGENDIAN
>>>   #define XTENSA_DEFAULT_CPU_MODEL "fsf"
>>>   #else
>>>   #define XTENSA_DEFAULT_CPU_MODEL "dc232b"
>>>   #endif
>>> +#define XTENSA_DEFAULT_CPU_TYPE 
>>> XTENSA_CPU_TYPE_NAME(XTENSA_DEFAULT_CPU_MODEL)  
>>
>> I see XTENSA_DEFAULT_CPU_MODEL is used in mc->desc, any idea to be able 
>> to use this instead?
> mc-desc is the reason why I've left XTENSA_DEFAULT_CPU_MODEL as is, and
> having that there were no point in adding yet another ifdef for type,
> XTENSA_DEFAULT_CPU_MODEL works just fine here.

Fine enough,

Reviewed-by: Philippe Mathieu-Daudé 

> 
>>
>> #ifdef TARGET_WORDS_BIGENDIAN
>> # define XTENSA_DEFAULT_CPU_TYPE XTENSA_CPU_TYPE_NAME("fsf")
>> #else
>> # define XTENSA_DEFAULT_CPU_TYPE XTENSA_CPU_TYPE_NAME("dc232b")
>> #endif
>>
>>>   
>>>   #define cpu_init(cpu_model) cpu_generic_init(TYPE_XTENSA_CPU, cpu_model)
>>>   
>>> diff --git a/target/xtensa/cpu.c b/target/xtensa/cpu.c
>>> index dcdc765..b5f7079 100644
>>> --- a/target/xtensa/cpu.c
>>> +++ b/target/xtensa/cpu.c
>>> @@ -83,7 +83,7 @@ static ObjectClass *xtensa_cpu_class_by_name(const char 
>>> *cpu_model)
>>>   ObjectClass *oc;
>>>   char *typename;
>>>   
>>> -typename = g_strdup_printf("%s-" TYPE_XTENSA_CPU, cpu_model);
>>> +typename = g_strdup_printf(XTENSA_CPU_TYPE_NAME("%s"), cpu_model);
>>>   oc = object_class_by_name(typename);
>>>   g_free(typename);
>>>   if (oc == NULL || !object_class_dynamic_cast(oc, TYPE_XTENSA_CPU) ||
>>> diff --git a/target/xtensa/helper.c b/target/xtensa/helper.c
>>> index e8fba20..216f198 100644
>>> --- a/target/xtensa/helper.c
>>> +++ b/target/xtensa/helper.c
>>> @@ -76,7 +76,7 @@ void xtensa_register_core(XtensaConfigList *node)
>>>   
>>>   node->next = xtensa_cores;
>>>   xtensa_cores = node;
>>> -type.name = g_strdup_printf("%s-" TYPE_XTENSA_CPU, node->config->name);
>>> +type.name = g_strdup_printf(XTENSA_CPU_TYPE_NAME("%s"), 
>>> node->config->name);
>>>   type_register(&type);
>>>   g_free((gpointer)type.name);
>>>   }
>>>   
> 



Re: [Qemu-devel] [Qemu-block] [PATCH 8/8] nbd: Minimal structured read for client

2017-10-03 Thread Vladimir Sementsov-Ogievskiy

03.10.2017 15:58, Vladimir Sementsov-Ogievskiy wrote:

03.10.2017 13:07, Paolo Bonzini wrote:

On 26/09/2017 00:19, Eric Blake wrote:

+    /* here we deal with successful structured reply */
+    switch (s->reply.type) {
+    QEMUIOVector sub_qiov;
+    case NBD_SREP_TYPE_OFFSET_DATA:

This is putting a LOT of smarts directly into the receive routine.
Here's where I was previously wondering (and I think Paolo as well)
whether it might be better to split the efforts: the generic function
reads off the chunk information and any payload, but a per-command
callback function then parses the chunks.  Especially since the
definition of the chunks differs on a per-command basis (yes, the NBD
spec will try to not reuse an SREP chunk type across multiple commands
unless the semantics are similar, but that's a bit more fragile).  This
particularly matters given my statement above that you want a
discriminated union, rather than a struct that contains unused fields,
for handling different SREP chunk types.

I think there should be two kinds of replies: 1) read directly into a
QEMUIOVector, using structured replies only as an encapsulation of the
payload; 2) read a chunk at a time into malloc-ed memory, yielding back
to the calling coroutine after receiving one complete chunk.

In the end this probably means that you have a read_chunk_header
function and a read_chunk function.  READ has a loop that calls
read_chunk_header followed by direct reading into the QEMUIOVector,
while everyone else calls read_chunk.


accordingly to spec, we can receive several error reply chunks to any 
request,

so loop, receiving them should be common for all requests I think


as well as handling error chunks should be common.. What do you think 
about my DRAFT proposal?







Maybe qio_channel_readv/writev_full could have "offset" and "bytes"
arguments.  Most code in iov_send_recv could be cut-and-pasted. (When
sheepdog is converted to QIOChannel, iov_send_recv can go away).

Paolo






--
Best regards,
Vladimir




Re: [Qemu-devel] [PATCHv2] dma/i82374: avoid double creation of i82374 device

2017-10-03 Thread Eduardo Habkost
On Mon, Oct 02, 2017 at 02:50:07PM +0200, Paolo Bonzini wrote:
> On 29/09/2017 21:31, Eduardo Habkost wrote:
> >> -void DMA_init(ISABus *bus, int high_page_enable)
> >> +void DMA_init(ISABus *bus, int high_page_enable, Error **errp)
> > 
> > If you make the function return a boolean to indicate success (in
> > addition to setting *errp), you avoid the need for a local_err
> > variable on the caller.
> 
> I think in this case, rather than a bool, it would be better to return 0
> or -EBUSY.  A check for "< 0" would be more self-explanatory in the caller.

I'm OK with that, too.

We really need to document the available and preferred error
reporting styles somewhere (probably on qapi/error.h).  We
discussed that a lot recently[1], but the conclusions were not
documented anywhere.

[1] https://www.mail-archive.com/qemu-devel@nongnu.org/msg461702.html

-- 
Eduardo



Re: [Qemu-devel] [PATCH 24/38] xtensa: lx60/lx200/ml605/kc705: use generic cpu_model parsing

2017-10-03 Thread Philippe Mathieu-Daudé
On 10/02/2017 06:08 AM, Igor Mammedov wrote:
> Signed-off-by: Igor Mammedov 

Reviewed-by: Philippe Mathieu-Daudé 

> ---
> CC: jcmvb...@gmail.com
> ---
>  hw/xtensa/xtfpga.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/xtensa/xtfpga.c b/hw/xtensa/xtfpga.c
> index a19cceb..1971ecf 100644
> --- a/hw/xtensa/xtfpga.c
> +++ b/hw/xtensa/xtfpga.c
> @@ -220,19 +220,14 @@ static void lx_init(const LxBoardDesc *board, 
> MachineState *machine)
>  DriveInfo *dinfo;
>  pflash_t *flash = NULL;
>  QemuOpts *machine_opts = qemu_get_machine_opts();
> -const char *cpu_model = machine->cpu_model;
>  const char *kernel_filename = qemu_opt_get(machine_opts, "kernel");
>  const char *kernel_cmdline = qemu_opt_get(machine_opts, "append");
>  const char *dtb_filename = qemu_opt_get(machine_opts, "dtb");
>  const char *initrd_filename = qemu_opt_get(machine_opts, "initrd");
>  int n;
>  
> -if (!cpu_model) {
> -cpu_model = XTENSA_DEFAULT_CPU_MODEL;
> -}
> -
>  for (n = 0; n < smp_cpus; n++) {
> -cpu = XTENSA_CPU(cpu_generic_init(TYPE_XTENSA_CPU, cpu_model));
> +cpu = XTENSA_CPU(cpu_create(machine->cpu_type));
>  env = &cpu->env;
>  
>  env->sregs[PRID] = n;
> @@ -454,6 +449,7 @@ static void xtensa_lx60_class_init(ObjectClass *oc, void 
> *data)
>  mc->desc = "lx60 EVB (" XTENSA_DEFAULT_CPU_MODEL ")";
>  mc->init = xtensa_lx60_init;
>  mc->max_cpus = 4;
> +mc->default_cpu_type = XTENSA_DEFAULT_CPU_TYPE;
>  }
>  
>  static const TypeInfo xtensa_lx60_type = {
> @@ -469,6 +465,7 @@ static void xtensa_lx200_class_init(ObjectClass *oc, void 
> *data)
>  mc->desc = "lx200 EVB (" XTENSA_DEFAULT_CPU_MODEL ")";
>  mc->init = xtensa_lx200_init;
>  mc->max_cpus = 4;
> +mc->default_cpu_type = XTENSA_DEFAULT_CPU_TYPE;
>  }
>  
>  static const TypeInfo xtensa_lx200_type = {
> @@ -484,6 +481,7 @@ static void xtensa_ml605_class_init(ObjectClass *oc, void 
> *data)
>  mc->desc = "ml605 EVB (" XTENSA_DEFAULT_CPU_MODEL ")";
>  mc->init = xtensa_ml605_init;
>  mc->max_cpus = 4;
> +mc->default_cpu_type = XTENSA_DEFAULT_CPU_TYPE;
>  }
>  
>  static const TypeInfo xtensa_ml605_type = {
> @@ -499,6 +497,7 @@ static void xtensa_kc705_class_init(ObjectClass *oc, void 
> *data)
>  mc->desc = "kc705 EVB (" XTENSA_DEFAULT_CPU_MODEL ")";
>  mc->init = xtensa_kc705_init;
>  mc->max_cpus = 4;
> +mc->default_cpu_type = XTENSA_DEFAULT_CPU_TYPE;
>  }
>  
>  static const TypeInfo xtensa_kc705_type = {
> 



Re: [Qemu-devel] [PATCH 12/38] moxie: fix qemu-system-moxie failing to start with CLI "-cpu MoxieLite"

2017-10-03 Thread Philippe Mathieu-Daudé
On 10/02/2017 06:07 AM, Igor Mammedov wrote:
> It 'works' with default CPU only because of bug in
> moxie_cpu_class_by_name() where it treats cpu_model
> as type name and default cpu_model also happens to be
> type name. But specifying explicitly cpu on CLI,
> ex: '-cpu MoxieLite', makes QEMU fail since
> moxie_cpu_class_by_name() doesn't traslate cpu_model
> to cpu type and fails to find corresponding object class.
> 
> Fix moxie_cpu_class_by_name() to do proper
>cpu_model -> cpu type
> translation and fix default cpu_model to be cpu_model
> instead of being typename.
> 
> Signed-off-by: Igor Mammedov 

Reviewed-by: Philippe Mathieu-Daudé 

> ---
> CC: gr...@moxielogic.com
> ---
>  hw/moxie/moxiesim.c | 2 +-
>  target/moxie/cpu.c  | 7 ++-
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/moxie/moxiesim.c b/hw/moxie/moxiesim.c
> index 5ea8dd3..01b9f34 100644
> --- a/hw/moxie/moxiesim.c
> +++ b/hw/moxie/moxiesim.c
> @@ -116,7 +116,7 @@ static void moxiesim_init(MachineState *machine)
>  
>  /* Init CPUs. */
>  if (cpu_model == NULL) {
> -cpu_model = "MoxieLite-moxie-cpu";
> +cpu_model = "MoxieLite";
>  }
>  cpu = MOXIE_CPU(cpu_generic_init(TYPE_MOXIE_CPU, cpu_model));
>  env = &cpu->env;
> diff --git a/target/moxie/cpu.c b/target/moxie/cpu.c
> index 30bd44f..d4626a1 100644
> --- a/target/moxie/cpu.c
> +++ b/target/moxie/cpu.c
> @@ -89,7 +89,12 @@ static void moxie_cpu_initfn(Object *obj)
>  
>  static ObjectClass *moxie_cpu_class_by_name(const char *cpu_model)
>  {
> -ObjectClass *oc = object_class_by_name(cpu_model);
> +ObjectClass *oc;
> +char *typename;
> +
> +typename = g_strdup_printf("%s-" TYPE_MOXIE_CPU, cpu_model);
> +oc = object_class_by_name(typename);
> +g_free(typename);
>  if (oc != NULL && (!object_class_dynamic_cast(oc, TYPE_MOXIE_CPU) ||
> object_class_is_abstract(oc))) {
>  return NULL;
> 



Re: [Qemu-devel] [PATCH v4 4/9] disas: Support the Capstone disassembler library

2017-10-03 Thread Philippe Mathieu-Daudé
On 10/02/2017 10:51 PM, Richard Henderson wrote:
> On 10/02/2017 02:45 PM, Philippe Mathieu-Daudé wrote:
>> On 10/02/2017 03:34 PM, Richard Henderson wrote:
>>> On 10/02/2017 09:36 AM, Philippe Mathieu-Daudé wrote:
 Maybe some defines like:

 #define LARGEST_TARGET_INSTR_SIZE 32

 #define MINIMUM_TARGET_PAGE_SIZE 1024
>>>
>>> Eh.  If I weren't simply pulling numbers out of my hat, perhaps.
>>> Does it really make things clearer beyond sizeof or a great big comment?
>>
>> big comment is great!
> 
> Like the one that's already there?

Yes, sorry for being that unclear, I wanted to say "_this_ big comment
_is_ great!". I suppose I think about using #defines because my English
isn't that conveying than yours :)

> 
> +/* We want to read memory for one insn, but generically we do not
> +   know how much memory that is.  We have a small buffer which is
> +   known to be sufficient for all supported targets.  Try to not
> +   read beyond the page, Just In Case.  For even more simplicity,
> +   ignore the actual target page size and use a 1k boundary.  If
> +   that turns out to be insufficient, we'll come back around the
> +   loop and read more.  */
> 
> 
> r~
> 



[Qemu-devel] [RFH PATCH 00/10] i386: hvf: miscellaneous cleanups

2017-10-03 Thread Paolo Bonzini
This is an initial set of (untested!) cleanups for the HVF code.
If anyone could pick them up, I think they represent the bare minimum
that has to be done before we can commit HVF support to master.
It's by no means the end, but the existing MMU code in target/i386 could
definitely stand a rewrite, and HVF could then use it as well.

They are available at git://github.com/bonzini/qemu.git, branch hvf.

Alex (both of them), Sergio, anyone else who can help?

Paolo

Paolo Bonzini (10):
  i386: hvf: move all hvf files in the same directory
  i386: hvf: header cleanup
  i386: hvf: unify register enums between HVF and the rest
  i386: hvf: remove more dead emulator code
  i386: hvf: remove ZERO_INIT macro
  i386: hvf: abort on decoding error
  i386: hvf: simplify flag handling
  i386: hvf: remove addr_t
  i386: hvf: simplify and fix in/out handling
  i386: hvf: cleanup x86_gen.h

 target/i386/Makefile.objs|   2 +-
 target/i386/cpu.h|  62 ---
 target/i386/hvf-utils/panic.h|  45 +
 target/i386/hvf-utils/x86_flags.h| 243 ---
 target/i386/{hvf-utils => hvf}/Makefile.objs |   1 +
 target/i386/{hvf-utils => hvf}/README.md |   0
 target/i386/{ => hvf}/hvf-i386.h |   2 +-
 target/i386/{hvf-all.c => hvf/hvf.c} |  36 ++--
 target/i386/{hvf-utils => hvf}/vmcs.h|   0
 target/i386/{hvf-utils => hvf}/vmx.h |  10 +-
 target/i386/{hvf-utils => hvf}/x86.c |  23 +--
 target/i386/{hvf-utils => hvf}/x86.h | 167 ++
 target/i386/{hvf-utils => hvf}/x86_cpuid.c   |   0
 target/i386/{hvf-utils => hvf}/x86_cpuid.h   |   0
 target/i386/{hvf-utils => hvf}/x86_decode.c  | 144 
 target/i386/{hvf-utils => hvf}/x86_decode.h  |  23 ++-
 target/i386/{hvf-utils => hvf}/x86_descr.c   |  26 +--
 target/i386/{hvf-utils => hvf}/x86_descr.h   |  21 ++-
 target/i386/{hvf-utils => hvf}/x86_emu.c | 238 ++
 target/i386/{hvf-utils => hvf}/x86_emu.h |  14 +-
 target/i386/{hvf-utils => hvf}/x86_flags.c   | 237 --
 target/i386/hvf/x86_flags.h  |  77 +
 target/i386/{hvf-utils => hvf}/x86_gen.h |   4 -
 target/i386/{hvf-utils => hvf}/x86_mmu.c |  36 ++--
 target/i386/{hvf-utils => hvf}/x86_mmu.h |   8 +-
 target/i386/{hvf-utils => hvf}/x86_task.c|  65 +++
 target/i386/{hvf-utils => hvf}/x86_task.h|   0
 target/i386/{hvf-utils => hvf}/x86hvf.c  |  32 ++--
 target/i386/{hvf-utils => hvf}/x86hvf.h  |   0
 29 files changed, 624 insertions(+), 892 deletions(-)
 create mode 100644 target/i386/hvf-utils/panic.h
 delete mode 100644 target/i386/hvf-utils/x86_flags.h
 rename target/i386/{hvf-utils => hvf}/Makefile.objs (87%)
 rename target/i386/{hvf-utils => hvf}/README.md (100%)
 rename target/i386/{ => hvf}/hvf-i386.h (97%)
 rename target/i386/{hvf-all.c => hvf/hvf.c} (97%)
 rename target/i386/{hvf-utils => hvf}/vmcs.h (100%)
 rename target/i386/{hvf-utils => hvf}/vmx.h (97%)
 rename target/i386/{hvf-utils => hvf}/x86.c (88%)
 rename target/i386/{hvf-utils => hvf}/x86.h (71%)
 rename target/i386/{hvf-utils => hvf}/x86_cpuid.c (100%)
 rename target/i386/{hvf-utils => hvf}/x86_cpuid.h (100%)
 rename target/i386/{hvf-utils => hvf}/x86_decode.c (96%)
 rename target/i386/{hvf-utils => hvf}/x86_decode.h (94%)
 rename target/i386/{hvf-utils => hvf}/x86_descr.c (82%)
 rename target/i386/{hvf-utils => hvf}/x86_descr.h (75%)
 rename target/i386/{hvf-utils => hvf}/x86_emu.c (84%)
 rename target/i386/{hvf-utils => hvf}/x86_emu.h (75%)
 rename target/i386/{hvf-utils => hvf}/x86_flags.c (57%)
 create mode 100644 target/i386/hvf/x86_flags.h
 rename target/i386/{hvf-utils => hvf}/x86_gen.h (93%)
 rename target/i386/{hvf-utils => hvf}/x86_mmu.c (85%)
 rename target/i386/{hvf-utils => hvf}/x86_mmu.h (84%)
 rename target/i386/{hvf-utils => hvf}/x86_task.c (81%)
 rename target/i386/{hvf-utils => hvf}/x86_task.h (100%)
 rename target/i386/{hvf-utils => hvf}/x86hvf.c (93%)
 rename target/i386/{hvf-utils => hvf}/x86hvf.h (100%)

-- 
2.13.6




[Qemu-devel] [PATCH 06/10] i386: hvf: abort on decoding error

2017-10-03 Thread Paolo Bonzini
Rather than unsupported situations, some VM_PANIC calls actually
are caused by internal errors.  Convert them to just abort.

Signed-off-by: Paolo Bonzini 
---
 target/i386/hvf/hvf.c |  2 +-
 target/i386/hvf/x86_emu.c | 10 --
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/target/i386/hvf/hvf.c b/target/i386/hvf/hvf.c
index ae3ecad2a4..f2dc37d826 100644
--- a/target/i386/hvf/hvf.c
+++ b/target/i386/hvf/hvf.c
@@ -767,7 +767,7 @@ int hvf_vcpu_exec(CPUState *cpu)
 env->hvf_emul->fetch_rip = rip;
 
 decode_instruction(env, &decode);
-VM_PANIC_ON(ins_len != decode.len);
+assert(ins_len == decode.len);
 exec_instruction(env, &decode);
 store_regs(cpu);
 
diff --git a/target/i386/hvf/x86_emu.c b/target/i386/hvf/x86_emu.c
index 3a995fe687..63c2b5a54d 100644
--- a/target/i386/hvf/x86_emu.c
+++ b/target/i386/hvf/x86_emu.c
@@ -146,7 +146,7 @@ addr_t read_reg(CPUX86State *env, int reg, int size)
 case 8:
 return env->hvf_emul->regs[reg].rrx;
 default:
-VM_PANIC_ON("read_reg size");
+abort();
 }
 return 0;
 }
@@ -167,7 +167,7 @@ void write_reg(CPUX86State *env, int reg, addr_t val, int 
size)
 env->hvf_emul->regs[reg].rrx = val;
 break;
 default:
-VM_PANIC_ON("write_reg size");
+abort();
 }
 }
 
@@ -189,8 +189,7 @@ addr_t read_val_from_reg(addr_t reg_ptr, int size)
 val = *(uint64_t *)reg_ptr;
 break;
 default:
-VM_PANIC_ON_EX(1, "read_val: Unknown size %d\n", size);
-break;
+abort();
 }
 return val;
 }
@@ -211,8 +210,7 @@ void write_val_to_reg(addr_t reg_ptr, addr_t val, int size)
 *(uint64_t *)reg_ptr = val;
 break;
 default:
-VM_PANIC("write_val: Unknown size\n");
-break;
+abort();
 }
 }
 
-- 
2.13.6





[Qemu-devel] [PATCH 04/10] i386: hvf: remove more dead emulator code

2017-10-03 Thread Paolo Bonzini
Signed-off-by: Paolo Bonzini 
---
 target/i386/hvf/hvf.c|  2 --
 target/i386/hvf/x86.h|  5 -
 target/i386/hvf/x86_decode.c | 22 +++---
 target/i386/hvf/x86_emu.c| 25 -
 target/i386/hvf/x86_flags.c  | 10 --
 target/i386/hvf/x86_flags.h  |  1 -
 target/i386/hvf/x86_mmu.c|  6 ++
 target/i386/hvf/x86_task.c   | 10 --
 8 files changed, 21 insertions(+), 60 deletions(-)

diff --git a/target/i386/hvf/hvf.c b/target/i386/hvf/hvf.c
index 863226cc9a..ae3ecad2a4 100644
--- a/target/i386/hvf/hvf.c
+++ b/target/i386/hvf/hvf.c
@@ -739,7 +739,6 @@ int hvf_vcpu_exec(CPUState *cpu)
 uint32_t port =  exit_qual >> 16;
 /*uint32_t rep = (exit_qual & 0x20) != 0;*/
 
-#if 1
 if (!string && in) {
 uint64_t val = 0;
 load_regs(cpu);
@@ -762,7 +761,6 @@ int hvf_vcpu_exec(CPUState *cpu)
 macvm_set_rip(cpu, rip + ins_len);
 break;
 }
-#endif
 struct x86_decode decode;
 
 load_regs(cpu);
diff --git a/target/i386/hvf/x86.h b/target/i386/hvf/x86.h
index 650bb718bf..94ac67b5cb 100644
--- a/target/i386/hvf/x86.h
+++ b/target/i386/hvf/x86.h
@@ -103,10 +103,6 @@ typedef struct x86_reg_flags {
 };
 } __attribute__ ((__packed__)) x86_reg_flags;
 
-typedef struct x86_efer {
-uint64_t efer;
-} __attribute__ ((__packed__)) x86_efer;
-
 typedef enum x86_reg_cr0 {
 CR0_PE =(1L << 0),
 CR0_MP =(1L << 1),
@@ -306,7 +302,6 @@ typedef struct HVFX86EmulatorState {
 struct x86_register regs[16];
 struct x86_reg_flags   rflags;
 struct lazy_flags   lflags;
-struct x86_efer efer;
 uint8_t mmio_buf[4096];
 } HVFX86EmulatorState;
 
diff --git a/target/i386/hvf/x86_decode.c b/target/i386/hvf/x86_decode.c
index 86e7c4ee7a..24c732d9f1 100644
--- a/target/i386/hvf/x86_decode.c
+++ b/target/i386/hvf/x86_decode.c
@@ -630,7 +630,7 @@ static void decode_aegroup(CPUX86State *env, struct 
x86_decode *decode)
 }
 break;
 default:
-VM_PANIC_ON_EX(1, "0xae: reg %d\n", decode->modrm.reg);
+VM_PANIC_EX("0xae: reg %d\n", decode->modrm.reg);
 break;
 }
 }
@@ -654,14 +654,14 @@ static void decode_d9_4(CPUX86State *env, struct 
x86_decode *decode)
 decode->cmd = X86_DECODE_CMD_FABS;
 break;
 case 0xe4:
-VM_PANIC_ON_EX(1, "FTST");
+VM_PANIC("FTST");
 break;
 case 0xe5:
 /* FXAM */
 decode->cmd = X86_DECODE_CMD_FXAM;
 break;
 default:
-VM_PANIC_ON_EX(1, "FLDENV");
+VM_PANIC("FLDENV");
 break;
 }
 }
@@ -670,16 +670,16 @@ static void decode_db_4(CPUX86State *env, struct 
x86_decode *decode)
 {
 switch (decode->modrm.modrm) {
 case 0xe0:
-VM_PANIC_ON_EX(1, "unhandled FNENI: %x %x\n", decode->opcode[0],
-   decode->modrm.modrm);
+VM_PANIC_EX("unhandled FNENI: %x %x\n", decode->opcode[0],
+decode->modrm.modrm);
 break;
 case 0xe1:
-VM_PANIC_ON_EX(1, "unhandled FNDISI: %x %x\n", decode->opcode[0],
-   decode->modrm.modrm);
+VM_PANIC_EX("unhandled FNDISI: %x %x\n", decode->opcode[0],
+decode->modrm.modrm);
 break;
 case 0xe2:
-VM_PANIC_ON_EX(1, "unhandled FCLEX: %x %x\n", decode->opcode[0],
-   decode->modrm.modrm);
+VM_PANIC_EX("unhandled FCLEX: %x %x\n", decode->opcode[0],
+decode->modrm.modrm);
 break;
 case 0xe3:
 decode->cmd = X86_DECODE_CMD_FNINIT;
@@ -688,8 +688,8 @@ static void decode_db_4(CPUX86State *env, struct x86_decode 
*decode)
 decode->cmd = X86_DECODE_CMD_FNSETPM;
 break;
 default:
-VM_PANIC_ON_EX(1, "unhandled fpu opcode: %x %x\n", decode->opcode[0],
-   decode->modrm.modrm);
+VM_PANIC_EX("unhandled fpu opcode: %x %x\n", decode->opcode[0],
+decode->modrm.modrm);
 break;
 }
 }
diff --git a/target/i386/hvf/x86_emu.c b/target/i386/hvf/x86_emu.c
index b64e490c2d..3a995fe687 100644
--- a/target/i386/hvf/x86_emu.c
+++ b/target/i386/hvf/x86_emu.c
@@ -837,7 +837,6 @@ void simulate_wrmsr(struct CPUState *cpu)
 abort();
 break;
 case MSR_EFER:
-env->hvf_emul->efer.efer = data;
 /*printf("new efer %llx\n", EFER(cpu));*/
 wvmcs(cpu->hvf_fd, VMCS_GUEST_IA32_EFER, data);
 if (data & MSR_EFER_NXE) {
@@ -1511,23 +1510,15 @@ bool exec_instruction(struct CPUX86State *env, struct 
x86_decode *ins)
 printf("%d, %llx: exec_instruction %s\n", hvf_vcpu_id(cpu),  RIP(cpu),
   decode_cmd_to_string(ins->cmd));*/
 
-if (0 && ins->is_fpu) {
-VM_PANIC("emulate fpu\n");
-} else {
-if (!_cmd_handler[ins->cmd].handler) {
-printf("Unimplemented handler (%llx) for %d (%x 

[Qemu-devel] [PATCH 02/10] i386: hvf: header cleanup

2017-10-03 Thread Paolo Bonzini
Remove inclusions of system headers and avoid "pragma once".

Signed-off-by: Paolo Bonzini 
---
 target/i386/hvf/x86.h| 8 +++-
 target/i386/hvf/x86_decode.h | 9 -
 target/i386/hvf/x86_descr.h  | 5 -
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/target/i386/hvf/x86.h b/target/i386/hvf/x86.h
index 7fd8fede80..ae957fc895 100644
--- a/target/i386/hvf/x86.h
+++ b/target/i386/hvf/x86.h
@@ -16,12 +16,9 @@
  * License along with this program; if not, see .
  */
 
-#pragma once
+#ifndef HVF_X86_H
+#define HVF_X86_H 1
 
-#include 
-#include 
-#include 
-#include 
 #include "qemu-common.h"
 #include "x86_gen.h"
 
@@ -474,3 +471,4 @@ static inline uint64_t rdtscp(void)
 return tsc;
 }
 
+#endif
diff --git a/target/i386/hvf/x86_decode.h b/target/i386/hvf/x86_decode.h
index 329131360f..50957819f6 100644
--- a/target/i386/hvf/x86_decode.h
+++ b/target/i386/hvf/x86_decode.h
@@ -15,12 +15,9 @@
  * License along with this program; if not, see .
  */
 
-#pragma once
+#ifndef HVF_X86_DECODE_H
+#define HVF_X86_DECODE_H 1
 
-#include 
-#include 
-#include 
-#include 
 #include "qemu-common.h"
 #include "x86.h"
 #include "cpu.h"
@@ -323,3 +320,5 @@ void calc_modrm_operand64(CPUX86State *env, struct 
x86_decode *decode,
   struct x86_decode_op *op);
 void set_addressing_size(CPUX86State *env, struct x86_decode *decode);
 void set_operand_size(CPUX86State *env, struct x86_decode *decode);
+
+#endif
diff --git a/target/i386/hvf/x86_descr.h b/target/i386/hvf/x86_descr.h
index 1285dd3897..034d8e95c5 100644
--- a/target/i386/hvf/x86_descr.h
+++ b/target/i386/hvf/x86_descr.h
@@ -16,7 +16,8 @@
  * License along with this program; if not, see .
  */
 
-#pragma once
+#ifndef HVF_X86_DESCR_H
+#define HVF_X86_DESCR_H 1
 
 #include "x86.h"
 
@@ -53,3 +54,5 @@ uint32_t vmx_read_segment_ar(CPUState *cpu, x86_reg_segment 
seg);
 void vmx_segment_to_x86_descriptor(struct CPUState *cpu,
struct vmx_segment *vmx_desc,
struct x86_segment_descriptor *desc);
+
+#endif
-- 
2.13.6





[Qemu-devel] [PATCH 01/10] i386: hvf: move all hvf files in the same directory

2017-10-03 Thread Paolo Bonzini
Just call it hvf/, no need for the "utils" suffix.

Signed-off-by: Paolo Bonzini 
---
 target/i386/Makefile.objs|  2 +-
 target/i386/cpu.h|  2 +-
 target/i386/{hvf-utils => hvf}/Makefile.objs |  1 +
 target/i386/{hvf-utils => hvf}/README.md |  0
 target/i386/{ => hvf}/hvf-i386.h |  2 +-
 target/i386/{hvf-all.c => hvf/hvf.c} | 20 ++--
 target/i386/{hvf-utils => hvf}/vmcs.h|  0
 target/i386/{hvf-utils => hvf}/vmx.h |  0
 target/i386/{hvf-utils => hvf}/x86.c |  0
 target/i386/{hvf-utils => hvf}/x86.h |  0
 target/i386/{hvf-utils => hvf}/x86_cpuid.c   |  0
 target/i386/{hvf-utils => hvf}/x86_cpuid.h   |  0
 target/i386/{hvf-utils => hvf}/x86_decode.c  |  0
 target/i386/{hvf-utils => hvf}/x86_decode.h  |  0
 target/i386/{hvf-utils => hvf}/x86_descr.c   |  0
 target/i386/{hvf-utils => hvf}/x86_descr.h   |  0
 target/i386/{hvf-utils => hvf}/x86_emu.c |  0
 target/i386/{hvf-utils => hvf}/x86_emu.h |  0
 target/i386/{hvf-utils => hvf}/x86_flags.c   |  0
 target/i386/{hvf-utils => hvf}/x86_flags.h   |  0
 target/i386/{hvf-utils => hvf}/x86_gen.h |  0
 target/i386/{hvf-utils => hvf}/x86_mmu.c |  0
 target/i386/{hvf-utils => hvf}/x86_mmu.h |  0
 target/i386/{hvf-utils => hvf}/x86_task.c| 20 ++--
 target/i386/{hvf-utils => hvf}/x86_task.h|  0
 target/i386/{hvf-utils => hvf}/x86hvf.c  |  0
 target/i386/{hvf-utils => hvf}/x86hvf.h  |  0
 27 files changed, 24 insertions(+), 23 deletions(-)
 rename target/i386/{hvf-utils => hvf}/Makefile.objs (87%)
 rename target/i386/{hvf-utils => hvf}/README.md (100%)
 rename target/i386/{ => hvf}/hvf-i386.h (97%)
 rename target/i386/{hvf-all.c => hvf/hvf.c} (98%)
 rename target/i386/{hvf-utils => hvf}/vmcs.h (100%)
 rename target/i386/{hvf-utils => hvf}/vmx.h (100%)
 rename target/i386/{hvf-utils => hvf}/x86.c (100%)
 rename target/i386/{hvf-utils => hvf}/x86.h (100%)
 rename target/i386/{hvf-utils => hvf}/x86_cpuid.c (100%)
 rename target/i386/{hvf-utils => hvf}/x86_cpuid.h (100%)
 rename target/i386/{hvf-utils => hvf}/x86_decode.c (100%)
 rename target/i386/{hvf-utils => hvf}/x86_decode.h (100%)
 rename target/i386/{hvf-utils => hvf}/x86_descr.c (100%)
 rename target/i386/{hvf-utils => hvf}/x86_descr.h (100%)
 rename target/i386/{hvf-utils => hvf}/x86_emu.c (100%)
 rename target/i386/{hvf-utils => hvf}/x86_emu.h (100%)
 rename target/i386/{hvf-utils => hvf}/x86_flags.c (100%)
 rename target/i386/{hvf-utils => hvf}/x86_flags.h (100%)
 rename target/i386/{hvf-utils => hvf}/x86_gen.h (100%)
 rename target/i386/{hvf-utils => hvf}/x86_mmu.c (100%)
 rename target/i386/{hvf-utils => hvf}/x86_mmu.h (100%)
 rename target/i386/{hvf-utils => hvf}/x86_task.c (95%)
 rename target/i386/{hvf-utils => hvf}/x86_task.h (100%)
 rename target/i386/{hvf-utils => hvf}/x86hvf.c (100%)
 rename target/i386/{hvf-utils => hvf}/x86hvf.h (100%)

diff --git a/target/i386/Makefile.objs b/target/i386/Makefile.objs
index 0bef89c099..44103a693b 100644
--- a/target/i386/Makefile.objs
+++ b/target/i386/Makefile.objs
@@ -12,5 +12,5 @@ obj-$(CONFIG_HAX) += hax-all.o hax-mem.o hax-windows.o
 endif
 ifdef CONFIG_DARWIN
 obj-$(CONFIG_HAX) += hax-all.o hax-mem.o hax-darwin.o
-obj-$(CONFIG_HVF) += hvf-utils/ hvf-all.o
+obj-$(CONFIG_HVF) += hvf/
 endif
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 0ae99ef424..238d3e3535 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -24,7 +24,7 @@
 #include "cpu-qom.h"
 #include "hyperv-proto.h"
 #if defined(CONFIG_HVF)
-#include "target/i386/hvf-utils/x86.h"
+#include "target/i386/hvf/x86.h"
 #endif
 
 #ifdef TARGET_X86_64
diff --git a/target/i386/hvf-utils/Makefile.objs b/target/i386/hvf/Makefile.objs
similarity index 87%
rename from target/i386/hvf-utils/Makefile.objs
rename to target/i386/hvf/Makefile.objs
index 79d8969ca8..927b86bc67 100644
--- a/target/i386/hvf-utils/Makefile.objs
+++ b/target/i386/hvf/Makefile.objs
@@ -1 +1,2 @@
+obj-y += hvf.o
 obj-y += x86.o x86_cpuid.o x86_decode.o x86_descr.o x86_emu.o x86_flags.o 
x86_mmu.o x86hvf.o x86_task.o
diff --git a/target/i386/hvf-utils/README.md b/target/i386/hvf/README.md
similarity index 100%
rename from target/i386/hvf-utils/README.md
rename to target/i386/hvf/README.md
diff --git a/target/i386/hvf-i386.h b/target/i386/hvf/hvf-i386.h
similarity index 97%
rename from target/i386/hvf-i386.h
rename to target/i386/hvf/hvf-i386.h
index 797718ce34..2232501552 100644
--- a/target/i386/hvf-i386.h
+++ b/target/i386/hvf/hvf-i386.h
@@ -18,7 +18,7 @@
 
 #include "sysemu/hvf.h"
 #include "cpu.h"
-#include "hvf-utils/x86.h"
+#include "x86.h"
 
 #define HVF_MAX_VCPU 0x10
 #define MAX_VM_ID 0x40
diff --git a/target/i386/hvf-all.c b/target/i386/hvf/hvf.c
similarity index 98%
rename from target/i386/hvf-all.c
rename to target/i386/hvf/hvf.c
index 81d9b64eae..863226cc9a 100644
--- a/target/i386/hvf-all.c
+++ b/target/i386/hvf/hvf.c
@@ -24,16 +24,16 @@
 
 #include "s

[Qemu-devel] [PATCH 03/10] i386: hvf: unify register enums between HVF and the rest

2017-10-03 Thread Paolo Bonzini
Signed-off-by: Paolo Bonzini 
---
 target/i386/cpu.h|  60 +++---
 target/i386/hvf/vmx.h|  10 +--
 target/i386/hvf/x86.c|  10 +--
 target/i386/hvf/x86.h| 145 +--
 target/i386/hvf/x86_decode.c |  80 
 target/i386/hvf/x86_decode.h |   2 +-
 target/i386/hvf/x86_descr.c  |  26 
 target/i386/hvf/x86_descr.h  |  16 ++---
 target/i386/hvf/x86_emu.c|  66 ++--
 target/i386/hvf/x86_task.c   |  48 +++---
 target/i386/hvf/x86hvf.c |  32 +-
 11 files changed, 224 insertions(+), 271 deletions(-)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 238d3e3535..fb38de7b0e 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -59,30 +59,42 @@
 #include "fpu/softfloat.h"
 #endif
 
-#define R_EAX 0
-#define R_ECX 1
-#define R_EDX 2
-#define R_EBX 3
-#define R_ESP 4
-#define R_EBP 5
-#define R_ESI 6
-#define R_EDI 7
-
-#define R_AL 0
-#define R_CL 1
-#define R_DL 2
-#define R_BL 3
-#define R_AH 4
-#define R_CH 5
-#define R_DH 6
-#define R_BH 7
-
-#define R_ES 0
-#define R_CS 1
-#define R_SS 2
-#define R_DS 3
-#define R_FS 4
-#define R_GS 5
+enum {
+R_RAX = 0,
+R_RCX = 1,
+R_RDX = 2,
+R_RBX = 3,
+R_RSP = 4,
+R_RBP = 5,
+R_RSI = 6,
+R_RDI = 7,
+R_R8 = 8,
+R_R9 = 9,
+R_R10 = 10,
+R_R11 = 11,
+R_R12 = 12,
+R_R13 = 13,
+R_R14 = 14,
+R_R15 = 15,
+
+R_AL = 0,
+R_CL = 1,
+R_DL = 2,
+R_BL = 3,
+R_AH = 4,
+R_CH = 5,
+R_DH = 6,
+R_BH = 7,
+};
+
+typedef enum X86Seg {
+R_ES = 0,
+R_CS = 1,
+R_SS = 2,
+R_DS = 3,
+R_FS = 4,
+R_GS = 5,
+} X86Seg;
 
 /* segment descriptor fields */
 #define DESC_G_SHIFT23
diff --git a/target/i386/hvf/vmx.h b/target/i386/hvf/vmx.h
index 102075d0d4..9dfcd2f2eb 100644
--- a/target/i386/hvf/vmx.h
+++ b/target/i386/hvf/vmx.h
@@ -88,14 +88,14 @@ static void enter_long_mode(hv_vcpuid_t vcpu, uint64_t cr0, 
uint64_t efer)
 {
 uint64_t entry_ctls;
 
-efer |= EFER_LMA;
+efer |= MSR_EFER_LMA;
 wvmcs(vcpu, VMCS_GUEST_IA32_EFER, efer);
 entry_ctls = rvmcs(vcpu, VMCS_ENTRY_CTLS);
 wvmcs(vcpu, VMCS_ENTRY_CTLS, rvmcs(vcpu, VMCS_ENTRY_CTLS) |
   VM_ENTRY_GUEST_LMA);
 
 uint64_t guest_tr_ar = rvmcs(vcpu, VMCS_GUEST_TR_ACCESS_RIGHTS);
-if ((efer & EFER_LME) &&
+if ((efer & MSR_EFER_LME) &&
 (guest_tr_ar & AR_TYPE_MASK) != AR_TYPE_BUSY_64_TSS) {
 wvmcs(vcpu, VMCS_GUEST_TR_ACCESS_RIGHTS,
   (guest_tr_ar & ~AR_TYPE_MASK) | AR_TYPE_BUSY_64_TSS);
@@ -109,7 +109,7 @@ static void exit_long_mode(hv_vcpuid_t vcpu, uint64_t cr0, 
uint64_t efer)
 entry_ctls = rvmcs(vcpu, VMCS_ENTRY_CTLS);
 wvmcs(vcpu, VMCS_ENTRY_CTLS, entry_ctls & ~VM_ENTRY_GUEST_LMA);
 
-efer &= ~EFER_LMA;
+efer &= ~MSR_EFER_LMA;
 wvmcs(vcpu, VMCS_GUEST_IA32_EFER, efer);
 }
 
@@ -121,7 +121,7 @@ static inline void macvm_set_cr0(hv_vcpuid_t vcpu, uint64_t 
cr0)
 uint64_t old_cr0 = rvmcs(vcpu, VMCS_GUEST_CR0);
 
 if ((cr0 & CR0_PG) && (rvmcs(vcpu, VMCS_GUEST_CR4) & CR4_PAE) &&
-!(efer & EFER_LME)) {
+!(efer & MSR_EFER_LME)) {
 address_space_rw(&address_space_memory,
  rvmcs(vcpu, VMCS_GUEST_CR3) & ~0x1f,
  MEMTXATTRS_UNSPECIFIED,
@@ -138,7 +138,7 @@ static inline void macvm_set_cr0(hv_vcpuid_t vcpu, uint64_t 
cr0)
 cr0 &= ~CR0_CD;
 wvmcs(vcpu, VMCS_GUEST_CR0, cr0 | CR0_NE | CR0_ET);
 
-if (efer & EFER_LME) {
+if (efer & MSR_EFER_LME) {
 if (!(old_cr0 & CR0_PG) && (cr0 & CR0_PG)) {
 enter_long_mode(vcpu, cr0, efer);
 }
diff --git a/target/i386/hvf/x86.c b/target/i386/hvf/x86.c
index 625ea6cac0..ca0ec2968a 100644
--- a/target/i386/hvf/x86.c
+++ b/target/i386/hvf/x86.c
@@ -134,13 +134,13 @@ bool x86_is_v8086(struct CPUState *cpu)
 
 bool x86_is_long_mode(struct CPUState *cpu)
 {
-return rvmcs(cpu->hvf_fd, VMCS_GUEST_IA32_EFER) & EFER_LMA;
+return rvmcs(cpu->hvf_fd, VMCS_GUEST_IA32_EFER) & MSR_EFER_LMA;
 }
 
 bool x86_is_long64_mode(struct CPUState *cpu)
 {
 struct vmx_segment desc;
-vmx_read_segment_descriptor(cpu, &desc, REG_SEG_CS);
+vmx_read_segment_descriptor(cpu, &desc, R_CS);
 
 return x86_is_long_mode(cpu) && ((desc.ar >> 13) & 1);
 }
@@ -157,13 +157,13 @@ bool x86_is_pae_enabled(struct CPUState *cpu)
 return cr4 & CR4_PAE;
 }
 
-addr_t linear_addr(struct CPUState *cpu, addr_t addr, x86_reg_segment seg)
+addr_t linear_addr(struct CPUState *cpu, addr_t addr, X86Seg seg)
 {
 return vmx_read_segment_base(cpu, seg) + addr;
 }
 
 addr_t linear_addr_size(struct CPUState *cpu, addr_t addr, int size,
-x86_reg_segment seg)
+X86Seg seg)
 {
 switch (size) {
 case 2:
@@ -180,5 +180,5 @@ addr_t linear_addr_size(struct CPUState *cpu, addr_t addr, 
int size,
 
 addr_t linear_rip(struct CPUState *cp

[Qemu-devel] [PATCH 05/10] i386: hvf: remove ZERO_INIT macro

2017-10-03 Thread Paolo Bonzini
Signed-off-by: Paolo Bonzini 
---
 target/i386/hvf/x86.c| 3 ++-
 target/i386/hvf/x86_decode.c | 3 +--
 target/i386/hvf/x86_gen.h| 2 --
 3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/target/i386/hvf/x86.c b/target/i386/hvf/x86.c
index ca0ec2968a..8002a41d30 100644
--- a/target/i386/hvf/x86.c
+++ b/target/i386/hvf/x86.c
@@ -53,7 +53,8 @@ bool x86_read_segment_descriptor(struct CPUState *cpu,
 addr_t base;
 uint32_t limit;
 
-ZERO_INIT(*desc);
+memset(desc, 0, sizeof(*desc));
+
 /* valid gdt descriptors start from index 1 */
 if (!sel.index && GDT_SEL == sel.ti) {
 return false;
diff --git a/target/i386/hvf/x86_decode.c b/target/i386/hvf/x86_decode.c
index 24c732d9f1..08b6036f2e 100644
--- a/target/i386/hvf/x86_decode.c
+++ b/target/i386/hvf/x86_decode.c
@@ -2090,8 +2090,7 @@ static void decode_opcodes(CPUX86State *env, struct 
x86_decode *decode)
 
 uint32_t decode_instruction(CPUX86State *env, struct x86_decode *decode)
 {
-ZERO_INIT(*decode);
-
+memset(decode, 0, sizeof(*decode));
 decode_prefix(env, decode);
 set_addressing_size(env, decode);
 set_operand_size(env, decode);
diff --git a/target/i386/hvf/x86_gen.h b/target/i386/hvf/x86_gen.h
index 2045b0e69d..d33dea842e 100644
--- a/target/i386/hvf/x86_gen.h
+++ b/target/i386/hvf/x86_gen.h
@@ -48,6 +48,4 @@ typedef uint64_t addr_t;
 } \
 }
 
-#define ZERO_INIT(obj) memset((void *) &obj, 0, sizeof(obj))
-
 #endif
-- 
2.13.6





Re: [Qemu-devel] [PATCH v4 00/14] add support for Hypervisor.framework in QEMU

2017-10-03 Thread Paolo Bonzini
On 13/09/2017 11:05, Sergio Andres Gomez Del Real wrote:
> 
> Changes in v4:
>  (1) Use g_new0 instead of g_malloc.
>  (2) hvf TODO's in cpu.c explained: in-kernel irqchip.
>  (3) Introduce ins_len field in patch where actually used.
>  (4) Remove outdated comment "/* Definition of hvf_state is here */"
>  (5) Treat vcpu_dirty as boolean throughout.
>  (6) checkpatch.pl patch only does styling changes.
>  (8) Add comment documenting meaning of -1 returned by
>  apic_get_highest_priority_irr.
>  (9) Add TODO to move hvf's synchronization functions inside
>  cpu_synchronize_*, along with kvm's and hax's.
> 

Thanks Sergio, this is a good start.  I have done a few more cleanup and
sent my patches which, however, I could not test.  In any case, it seems
feasible to get this done for 2.11!

Regards,

Paolo

> 
> Changes in v3:
>  (1) Fixed licensing issues in patch 3.
>  (2) Revert to late adding of compilation rules in Makefile.objs (patch 8/14);
>  files aren't ready to compile earlier.
>  (3) Make a single patch just for fixing style (patch 4/14).
>  (4) Fix data type for hvf_fd field.
>  (5) Add comment that return value of -1 in apic function added in 7/14 means
>  "no interrupt".
> 
> 
> 
> Changes in v2:
>  (1) Removed legacy option "-enable-hvf" in favor of "-M accel=hvf"
>  (2) Added missing copyright headers; replace fprintfs for error_report;
>  improved commit description.
>  (3) Moved patch that adds compilation rules in Makefile.objs right after
>  the patch that adds the new files from Google's repo.
>  (4) Removed conditional macros from cpus.c and cpu.c
>  (5) Moved patch that fixes coding style to patch # 3
>  (6) Fix commit message in apic patch
>  (7) Squash some commits to avoid code churn
> 
> 
> The following patchset adds to QEMU the supporting for macOS's native
> hypervisor, Hypervisor.framework (hvf). The code base is taken from
> Google's Android emulator at
> https://android.googlesource.com/platform/external/qemu/+/emu-master-dev.
> Notably missing is support for live migration.
> 
> Apart from general code refactoring, some additional features were 
> implemented:
> retrieve the set of features supported by host cpu and hvf (cpuid);
> dirty page tracking for VGA memory area; reimplementation of the event
> injection mechanism to allow injection of exceptions during vmexits, which is
> exemplified by the injection of a GP fault when the guest vmexits due to
> execution of the vmcall instruction; changing the emulator's use of CPUState
> structure in favor of CPUX86State, so as to in the future remove data 
> structures
> that are uselessly specific to hvf and unified some of the state between 
> kvm/tcg
> and hvf.
> Some features initially planned to implement that didn't make it include:
> page fault handling in the emulator and implementing the dummy_signal to 
> handle
> the SIG_IPI signal without race conditions. Hopefully these can be implemented
> in the near future.
> Event injection was tested through the eventinj kvm test. The latest Debian 
> and
> Damn Small Linux images were executed, although by now ways it was an
> exhaustive testing.
> 
> Sergio Andres Gomez Del Real (14):
>   hvf: add support for Hypervisor.framework in the configure script
>   hvf: add code base from Google's QEMU repository
>   hvf: fix licensing issues; isolate task handling code (GPL v2-only)
>   hvf: run hvf code through checkpatch.pl and fix style issues
>   hvf: add code to cpus.c and do refactoring in preparation for
> compiling
>   hvf: handle fields from CPUState and CPUX86State
>   apic: add function to apic that will be used by hvf
>   hvf: add compilation rules to Makefile.objs
>   hvf: use new helper functions for put/get xsave
>   hvf: implement hvf_get_supported_cpuid
>   hvf: refactor cpuid code
>   hvf: implement vga dirty page tracking
>   hvf: refactor event injection code for hvf
>   hvf: inject General Protection Fault when vmexit through vmcall
> 
>  configure   |   38 +
>  cpus.c  |   89 ++
>  hw/intc/apic.c  |   12 +
>  include/hw/i386/apic.h  |1 +
>  include/qom/cpu.h   |2 +
>  include/sysemu/hvf.h|  181 +++
>  qemu-options.hx |   10 +-
>  target/i386/Makefile.objs   |1 +
>  target/i386/cpu-qom.h   |4 +-
>  target/i386/cpu.c   |   80 +-
>  target/i386/cpu.h   |   34 +-
>  target/i386/hvf-all.c   |  963 +++
>  target/i386/hvf-i386.h  |   50 +
>  target/i386/hvf-utils/Makefile.objs |1 +
>  target/i386/hvf-utils/README.md |7 +
>  target/i386/hvf-utils/vmcs.h|  371 ++
>  target/i386/hvf-utils/vmx.h |  222 
>  target/i386/hvf-utils/x86.c |  184 +++
>  target/i386/hvf-utils/x86.h

[Qemu-devel] [PATCH 09/10] i386: hvf: simplify and fix in/out handling

2017-10-03 Thread Paolo Bonzini
Reading a 32-bit port should clear the upper 32-bits of the register.

Signed-off-by: Paolo Bonzini 
---
 target/i386/hvf/hvf.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/target/i386/hvf/hvf.c b/target/i386/hvf/hvf.c
index 5194b94591..35e39afefd 100644
--- a/target/i386/hvf/hvf.c
+++ b/target/i386/hvf/hvf.c
@@ -748,16 +748,16 @@ int hvf_vcpu_exec(CPUState *cpu)
 } else if (size == 2) {
 AX(env) = val;
 } else if (size == 4) {
-RAX(env) = (uint32_t)val;
+RRX(env) = (uint32_t)val;
 } else {
-VM_PANIC("size");
+RRX(env) = (uint64_t)val;
 }
 RIP(env) += ins_len;
 store_regs(cpu);
 break;
 } else if (!string && !in) {
-RAX(env) = rreg(cpu->hvf_fd, HV_X86_RAX);
-hvf_handle_io(env, port, &RAX(env), 1, size, 1);
+RRX(env) = rreg(cpu->hvf_fd, HV_X86_RAX);
+hvf_handle_io(env, port, &RRX(env), 1, size, 1);
 macvm_set_rip(cpu, rip + ins_len);
 break;
 }
-- 
2.13.6





Re: [Qemu-devel] [PATCH 38/43] windbg: implemented kd_api_read_physical_memory and kd_api_write_physical_memory

2017-10-03 Thread Ladi Prosek
On Tue, Sep 26, 2017 at 1:07 PM, Mihail Abakumov
 wrote:
> Signed-off-by: Mihail Abakumov 
> Signed-off-by: Pavel Dovgalyuk 
> Signed-off-by: Dmitriy Koltunov 
> ---
>  include/exec/windbgstub-utils.h |2 ++
>  windbgstub-utils.c  |   28 
>  windbgstub.c|8 
>  3 files changed, 38 insertions(+)
>
> diff --git a/include/exec/windbgstub-utils.h b/include/exec/windbgstub-utils.h
> index 07e11c0494..d390bc1dfe 100755
> --- a/include/exec/windbgstub-utils.h
> +++ b/include/exec/windbgstub-utils.h
> @@ -113,6 +113,8 @@ void kd_api_read_control_space(CPUState *cpu, PacketData 
> *pd);
>  void kd_api_write_control_space(CPUState *cpu, PacketData *pd);
>  void kd_api_read_io_space(CPUState *cpu, PacketData *pd);
>  void kd_api_write_io_space(CPUState *cpu, PacketData *pd);
> +void kd_api_read_physical_memory(CPUState *cpu, PacketData *pd);
> +void kd_api_write_physical_memory(CPUState *cpu, PacketData *pd);
>  void kd_api_unsupported(CPUState *cpu, PacketData *pd);
>
>  SizedBuf kd_gen_exception_sc(CPUState *cpu);
> diff --git a/windbgstub-utils.c b/windbgstub-utils.c
> index 6bf9868e51..1fba54f9d9 100755
> --- a/windbgstub-utils.c
> +++ b/windbgstub-utils.c
> @@ -1170,6 +1170,34 @@ void kd_api_write_io_space(CPUState *cpu, PacketData 
> *pd)
>  pd->m64.ReturnStatus = STATUS_SUCCESS;
>  }
>
> +void kd_api_read_physical_memory(CPUState *cpu, PacketData *pd)
> +{
> +DBGKD_READ_MEMORY64 *mem = &pd->m64.u.ReadMemory;
> +uint32_t len;
> +target_ulong addr;
> +
> +len = MIN(ldl_p(&mem->TransferCount), PACKET_MAX_SIZE - M64_SIZE);
> +addr = ldtul_p(&mem->TargetBaseAddress);
> +
> +cpu_physical_memory_rw(addr, pd->extra, len, 0);
> +pd->extra_size = len;
> +mem->ActualBytesRead = ldl_p(&len);

stl_p(&mem->ActualBytesRead, len)

And the same pattern is in many other places. Stores to potentially
unaligned memory locations with the right endianness should be done
with st* not ld*.

> +}
> +
> +void kd_api_write_physical_memory(CPUState *cpu, PacketData *pd)
> +{
> +DBGKD_WRITE_MEMORY64 *mem = &pd->m64.u.WriteMemory;
> +uint32_t len;
> +target_ulong addr;
> +
> +len = MIN(ldl_p(&mem->TransferCount), pd->extra_size);
> +addr = ldtul_p(&mem->TargetBaseAddress);
> +
> +cpu_physical_memory_rw(addr, pd->extra, len, 1);
> +pd->extra_size = 0;
> +mem->ActualBytesWritten = ldl_p(&len);
> +}
> +
>  void kd_api_unsupported(CPUState *cpu, PacketData *pd)
>  {
>  WINDBG_ERROR("Catched unimplemented api %s",
> diff --git a/windbgstub.c b/windbgstub.c
> index 0363d9a5c8..118e9dd697 100755
> --- a/windbgstub.c
> +++ b/windbgstub.c
> @@ -182,6 +182,14 @@ static void 
> windbg_process_manipulate_packet(ParsingContext *ctx)
>  kd_api_write_control_space(cpu, &ctx->data);
>  break;
>
> +case DbgKdReadPhysicalMemoryApi:
> +kd_api_read_physical_memory(cpu, &ctx->data);
> +break;
> +
> +case DbgKdWritePhysicalMemoryApi:
> +kd_api_write_physical_memory(cpu, &ctx->data);
> +break;
> +
>  case DbgKdClearAllInternalBreakpointsApi:
>  return;
>
>



Re: [Qemu-devel] [PATCH] hw/arm/xlnx-zynqmp: Mark the "xlnx, zynqmp" device with user_creatable = false

2017-10-03 Thread Peter Maydell
On 26 September 2017 at 16:51, Thomas Huth  wrote:
> The device uses serial_hds in its realize function and thus can't be
> used twice. Apart from that, the comma in its name makes it quite hard
> to use for the user anyway, since a comma is normally used to separate
> the device name from its properties when using the "-device" parameter
> or the "device_add" HMP command.
>
> Signed-off-by: Thomas Huth 
> ---
>  hw/arm/xlnx-zynqmp.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/hw/arm/xlnx-zynqmp.c b/hw/arm/xlnx-zynqmp.c
> index 2b27daf..d4b6560 100644
> --- a/hw/arm/xlnx-zynqmp.c
> +++ b/hw/arm/xlnx-zynqmp.c
> @@ -440,6 +440,8 @@ static void xlnx_zynqmp_class_init(ObjectClass *oc, void 
> *data)
>
>  dc->props = xlnx_zynqmp_props;
>  dc->realize = xlnx_zynqmp_realize;
> +/* Reason: Uses serial_hds in realize function, thus can't be used twice 
> */
> +dc->user_creatable = false;
>  }
>
>  static const TypeInfo xlnx_zynqmp_type_info = {



Applied to target-arm.next, thanks.

-- PMM



[Qemu-devel] [PATCH 10/10] i386: hvf: cleanup x86_gen.h

2017-10-03 Thread Paolo Bonzini
This only includes VM_PANIC now.  No need to include it from headers.

Signed-off-by: Paolo Bonzini 
---
 target/i386/hvf-utils/panic.h | 45 +++
 target/i386/hvf/x86.h |  1 -
 target/i386/hvf/x86_decode.c  |  3 +--
 target/i386/hvf/x86_emu.c |  2 +-
 target/i386/hvf/x86_flags.c   |  1 +
 target/i386/hvf/x86_flags.h   |  1 -
 target/i386/hvf/x86_mmu.c |  1 +
 target/i386/hvf/x86_mmu.h |  2 --
 target/i386/hvf/x86_task.c|  1 +
 9 files changed, 50 insertions(+), 7 deletions(-)
 create mode 100644 target/i386/hvf-utils/panic.h

diff --git a/target/i386/hvf-utils/panic.h b/target/i386/hvf-utils/panic.h
new file mode 100644
index 00..411ef43a5b
--- /dev/null
+++ b/target/i386/hvf-utils/panic.h
@@ -0,0 +1,45 @@
+/*
+ * Copyright (C) 2016 Veertu Inc,
+ * Copyright (C) 2017 Google Inc,
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this program; if not, see .
+ */
+#ifndef HVF_PANIC_H
+#define HVF_PANIC_H
+
+#define VM_PANIC(x) {\
+printf("%s\n", x); \
+abort(); \
+}
+
+#define VM_PANIC_ON(x) {\
+if (x) { \
+printf("%s\n", #x); \
+abort(); \
+} \
+}
+
+#define VM_PANIC_EX(...) {\
+printf(__VA_ARGS__); \
+abort(); \
+}
+
+#define VM_PANIC_ON_EX(x, ...) {\
+if (x) { \
+printf(__VA_ARGS__); \
+abort(); \
+} \
+}
+
+#endif
diff --git a/target/i386/hvf/x86.h b/target/i386/hvf/x86.h
index a7fc65a487..595d5aca04 100644
--- a/target/i386/hvf/x86.h
+++ b/target/i386/hvf/x86.h
@@ -20,7 +20,6 @@
 #define HVF_X86_H 1
 
 #include "qemu-common.h"
-#include "x86_gen.h"
 
 typedef struct x86_register {
 union {
diff --git a/target/i386/hvf/x86_decode.c b/target/i386/hvf/x86_decode.c
index f6096ca307..ff31f4f577 100644
--- a/target/i386/hvf/x86_decode.c
+++ b/target/i386/hvf/x86_decode.c
@@ -17,11 +17,10 @@
  */
 
 #include "qemu/osdep.h"
-
+#include "panic.h"
 #include "x86_decode.h"
 #include "string.h"
 #include "vmx.h"
-#include "x86_gen.h"
 #include "x86_mmu.h"
 #include "x86_descr.h"
 
diff --git a/target/i386/hvf/x86_emu.c b/target/i386/hvf/x86_emu.c
index 8f45f01eed..44b0b83fea 100644
--- a/target/i386/hvf/x86_emu.c
+++ b/target/i386/hvf/x86_emu.c
@@ -36,7 +36,7 @@
 /
 
 #include "qemu/osdep.h"
-
+#include "panic.h"
 #include "qemu-common.h"
 #include "x86_decode.h"
 #include "x86.h"
diff --git a/target/i386/hvf/x86_flags.c b/target/i386/hvf/x86_flags.c
index b1f240ca0f..f79ff096f6 100644
--- a/target/i386/hvf/x86_flags.c
+++ b/target/i386/hvf/x86_flags.c
@@ -22,6 +22,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "panic.h"
 #include "qemu-common.h"
 
 #include "cpu.h"
diff --git a/target/i386/hvf/x86_flags.h b/target/i386/hvf/x86_flags.h
index 69d8672d24..c46a5fd8a8 100644
--- a/target/i386/hvf/x86_flags.h
+++ b/target/i386/hvf/x86_flags.h
@@ -23,7 +23,6 @@
 #ifndef __X86_FLAGS_H__
 #define __X86_FLAGS_H__
 
-#include "x86_gen.h"
 #include "cpu.h"
 void lflags_to_rflags(CPUX86State *env);
 void rflags_to_lflags(CPUX86State *env);
diff --git a/target/i386/hvf/x86_mmu.c b/target/i386/hvf/x86_mmu.c
index af11635fba..682e29774e 100644
--- a/target/i386/hvf/x86_mmu.c
+++ b/target/i386/hvf/x86_mmu.c
@@ -16,6 +16,7 @@
  * License along with this program; if not, see .
  */
 #include "qemu/osdep.h"
+#include "panic.h"
 
 #include "qemu-common.h"
 #include "x86.h"
diff --git a/target/i386/hvf/x86_mmu.h b/target/i386/hvf/x86_mmu.h
index ae02cb6916..0bd1acc94f 100644
--- a/target/i386/hvf/x86_mmu.h
+++ b/target/i386/hvf/x86_mmu.h
@@ -18,8 +18,6 @@
 #ifndef __X86_MMU_H__
 #define __X86_MMU_H__
 
-#include "x86_gen.h"
-
 #define PT_PRESENT  (1 << 0)
 #define PT_WRITE(1 << 1)
 #define PT_USER (1 << 2)
diff --git a/target/i386/hvf/x86_task.c b/target/i386/hvf/x86_task.c
index b6ce2a151b..f77edda580 100644
--- a/target/i386/hvf/x86_task.c
+++ b/target/i386/hvf/x86_task.c
@@ -7,6 +7,7 @@
 // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 // GNU General Public License for more details.
 #include "qemu/osdep.h"
+#include "panic.h"
 #include "qemu-common.h"
 #include "qemu/error-report.h"
 
-- 
2.13.6




Re: [Qemu-devel] [PATCH 41/43] windbg: implemented kd_api_search_memory

2017-10-03 Thread Ladi Prosek
On Tue, Sep 26, 2017 at 1:07 PM, Mihail Abakumov
 wrote:
> Signed-off-by: Mihail Abakumov 
> Signed-off-by: Pavel Dovgalyuk 
> Signed-off-by: Dmitriy Koltunov 
> ---
>  include/exec/windbgstub-utils.h |1 +
>  windbgstub-utils.c  |   30 ++
>  windbgstub.c|4 
>  3 files changed, 35 insertions(+)
>
> diff --git a/include/exec/windbgstub-utils.h b/include/exec/windbgstub-utils.h
> index 23cafb1a89..ba001ddb42 100755
> --- a/include/exec/windbgstub-utils.h
> +++ b/include/exec/windbgstub-utils.h
> @@ -118,6 +118,7 @@ void kd_api_write_physical_memory(CPUState *cpu, 
> PacketData *pd);
>  void kd_api_get_version(CPUState *cpu, PacketData *pd);
>  void kd_api_read_msr(CPUState *cpu, PacketData *pd);
>  void kd_api_write_msr(CPUState *cpu, PacketData *pd);
> +void kd_api_search_memory(CPUState *cpu, PacketData *pd);
>  void kd_api_unsupported(CPUState *cpu, PacketData *pd);
>
>  SizedBuf kd_gen_exception_sc(CPUState *cpu);
> diff --git a/windbgstub-utils.c b/windbgstub-utils.c
> index 26bdb1f6ea..2d3fbcc41c 100755
> --- a/windbgstub-utils.c
> +++ b/windbgstub-utils.c
> @@ -1540,6 +1540,36 @@ void kd_api_write_msr(CPUState *cpu, PacketData *pd)
>  pd->m64.ReturnStatus = STATUS_SUCCESS;
>  }
>
> +void kd_api_search_memory(CPUState *cpu, PacketData *pd)
> +{
> +DBGKD_SEARCH_MEMORY *m64c = &pd->m64.u.SearchMemory;
> +int s_len = MAX(1, ldq_p(&m64c->SearchLength));
> +int p_len = MIN(ldl_p(&m64c->PatternLength), pd->extra_size);
> +target_ulong addr = ldq_p(&m64c->SearchAddress);
> +
> +uint8_t mem[s_len - 1 + p_len];

s_len could be very large, people do things like

0:000> s -d 0x8000 L?0x7fff 

You should not allocate this buffer on the stack and preferably break
large searches down to smaller ranges, i.e. don't allocate and read
~s_len bytes all at once.

> +int err = cpu_memory_rw_debug(cpu, addr, mem, sizeof(mem), 0);
> +if (!err) {
> +int i;
> +pd->m64.ReturnStatus = STATUS_NO_MORE_ENTRIES;
> +for (i = 0; i < s_len; ++i) {
> +if (memcmp(mem + i, pd->extra, p_len) == 0) {
> +m64c->FoundAddress = addr + i;
> +m64c->FoundAddress = ldq_p(&m64c->FoundAddress);
> +pd->m64.ReturnStatus = STATUS_SUCCESS;
> +break;
> +}
> +}

Use memmem instead?

> +} else {
> +pd->m64.ReturnStatus = STATUS_UNSUCCESSFUL;
> +WINDBG_DEBUG("search_memory: No physical page mapped: " FMT_ADDR,
> + addr);
> +}
> +
> +pd->extra_size = 0;
> +}
> +
>  void kd_api_unsupported(CPUState *cpu, PacketData *pd)
>  {
>  WINDBG_ERROR("Catched unimplemented api %s",
> diff --git a/windbgstub.c b/windbgstub.c
> index 1ec4932ddc..7cff6bc514 100755
> --- a/windbgstub.c
> +++ b/windbgstub.c
> @@ -205,6 +205,10 @@ static void 
> windbg_process_manipulate_packet(ParsingContext *ctx)
>  case DbgKdClearAllInternalBreakpointsApi:
>  return;
>
> +case DbgKdSearchMemoryApi:
> +kd_api_search_memory(cpu, &ctx->data);
> +break;
> +
>  default:
>  kd_api_unsupported(cpu, &ctx->data);
>  break;
>



Re: [Qemu-devel] [PATCH 42/43] windbg: implemented kd_api_fill_memory

2017-10-03 Thread Ladi Prosek
On Tue, Sep 26, 2017 at 1:08 PM, Mihail Abakumov
 wrote:
> Signed-off-by: Mihail Abakumov 
> Signed-off-by: Pavel Dovgalyuk 
> Signed-off-by: Dmitriy Koltunov 
> ---
>  include/exec/windbgstub-utils.h |1 +
>  windbgstub-utils.c  |   36 
>  windbgstub.c|4 
>  3 files changed, 41 insertions(+)
>
> diff --git a/include/exec/windbgstub-utils.h b/include/exec/windbgstub-utils.h
> index ba001ddb42..d1a10c862e 100755
> --- a/include/exec/windbgstub-utils.h
> +++ b/include/exec/windbgstub-utils.h
> @@ -119,6 +119,7 @@ void kd_api_get_version(CPUState *cpu, PacketData *pd);
>  void kd_api_read_msr(CPUState *cpu, PacketData *pd);
>  void kd_api_write_msr(CPUState *cpu, PacketData *pd);
>  void kd_api_search_memory(CPUState *cpu, PacketData *pd);
> +void kd_api_fill_memory(CPUState *cpu, PacketData *pd);
>  void kd_api_unsupported(CPUState *cpu, PacketData *pd);
>
>  SizedBuf kd_gen_exception_sc(CPUState *cpu);
> diff --git a/windbgstub-utils.c b/windbgstub-utils.c
> index 2d3fbcc41c..3832e0b116 100755
> --- a/windbgstub-utils.c
> +++ b/windbgstub-utils.c
> @@ -1570,6 +1570,42 @@ void kd_api_search_memory(CPUState *cpu, PacketData 
> *pd)
>  pd->extra_size = 0;
>  }
>
> +void kd_api_fill_memory(CPUState *cpu, PacketData *pd)
> +{
> +DBGKD_FILL_MEMORY *m64c = &pd->m64.u.FillMemory;
> +
> +uint32_t len = ldl_p(&m64c->Length);
> +target_ulong addr = ldq_p(&m64c->Address);
> +uint16_t pattern = ldl_p(&m64c->PatternLength);
> +uint16_t flags = ldl_p(&m64c->Flags);
> +
> +uint8_t mem[len];

Same as patch 41, break len into, say, page-sized regions and call
cpu_memory_rw_debug in a loop.

> +int i, err;
> +for (i = 0; i < len; ++i) {
> +mem[i] = pd->extra[i % pattern];
> +}
> +
> +switch (flags) {
> +case DBGKD_FILL_MEMORY_VIRTUAL:
> +err = cpu_memory_rw_debug(cpu, addr, mem, len, 1);
> +if (err) {
> +pd->m64.ReturnStatus = STATUS_UNSUCCESSFUL;
> +WINDBG_DEBUG("fill_memory: No physical page mapped: " FMT_ADDR,
> +addr);
> +}
> +break;
> +
> +case DBGKD_FILL_MEMORY_PHYSICAL:
> +cpu_physical_memory_rw(addr, mem, len, 1);
> +break;
> +
> +default:
> +break;
> +}
> +
> +pd->extra_size = 0;
> +}
> +
>  void kd_api_unsupported(CPUState *cpu, PacketData *pd)
>  {
>  WINDBG_ERROR("Catched unimplemented api %s",
> diff --git a/windbgstub.c b/windbgstub.c
> index 7cff6bc514..b01ddcf009 100755
> --- a/windbgstub.c
> +++ b/windbgstub.c
> @@ -209,6 +209,10 @@ static void 
> windbg_process_manipulate_packet(ParsingContext *ctx)
>  kd_api_search_memory(cpu, &ctx->data);
>  break;
>
> +case DbgKdFillMemoryApi:
> +kd_api_fill_memory(cpu, &ctx->data);
> +break;
> +
>  default:
>  kd_api_unsupported(cpu, &ctx->data);
>  break;
>



Re: [Qemu-devel] [PATCH v4 1/2] virtio: introduce `query-virtio' QMP command

2017-10-03 Thread Eric Blake
On 10/03/2017 07:47 AM, Jan Dakinevich wrote:
> The command is intended for gathering virtio information such as status,
> feature bits, negotiation status. It is convenient and useful for debug
> purpose.
> 
> The commands returns generic virtio information for virtio such as
> common feature names and status bits names and information for all
> attached to current machine devices.
> 
> To retrieve names of device-specific features `get_feature_name'
> callback in VirtioDeviceClass also was introduced.
> 
> Cc: Denis V. Lunev 
> Signed-off-by: Jan Dakinevich 
> ---
>  hw/block/virtio-blk.c   |  21 +
>  hw/char/virtio-serial-bus.c |  15 +++
>  hw/display/virtio-gpu.c |  13 ++
>  hw/net/virtio-net.c |  35 +++
>  hw/scsi/virtio-scsi.c   |  16 +++
>  hw/virtio/Makefile.objs |   2 +
>  hw/virtio/virtio-balloon.c  |  15 +++
>  hw/virtio/virtio-stub.c |   9 
>  hw/virtio/virtio.c  | 101 
> 
>  include/hw/virtio/virtio.h  |   2 +
>  qapi-schema.json|   1 +
>  qapi/virtio.json|  94 +
>  12 files changed, 324 insertions(+)
>  create mode 100644 hw/virtio/virtio-stub.c
>  create mode 100644 qapi/virtio.json

This creates a new .json file, but does not touch MAINTAINERS.  Our idea
in splitting the .json files was to make it easier for each sub-file
that needs a specific maintainer in addition to the overall *.json line
for QAPI maintainers, so this may deserve a MAINTAINERS entry.


> +++ b/qapi/virtio.json
> @@ -0,0 +1,94 @@
> +# -*- Mode: Python -*-
> +#
> +
> +##
> +# = Virtio devices
> +##
> +
> +{ 'include': 'common.json' }
> +
> +##
> +# @VirtioInfoBit:
> +#
> +# Named virtio bit
> +#
> +# @bit: bit number
> +#
> +# @name: bit name
> +#
> +# Since: 2.11.0
> +#
> +##
> +{
> +'struct': 'VirtioInfoBit',
> +'data': {
> +'bit': 'uint64',

Why is this a 64-bit value? Are the values 0-63, or are they 1, 2, 4, 8,
...?  The documentation on 'bit number' is rather sparse.

> +'name': 'str'

Wouldn't an enum type be better than an open-ended string?

> +}
> +}
> +
> +##
> +# @VirtioInfoDevice:
> +#
> +# Information about specific virtio device
> +#
> +# @qom_path: QOM path of the device

Please make this 'qom-path' - new interfaces should prefer '-' over '_'.

> +#
> +# @feature-names: names of device-specific features
> +#
> +# @host-features: bitmask of features, provided by devices
> +#
> +# @guest-features: bitmask of features, acknowledged by guest
> +#
> +# @status: virtio device status bitmask
> +#
> +# Since: 2.11.0
> +#
> +##
> +{
> +'struct': 'VirtioInfoDevice',
> +'data': {
> +'qom_path': 'str',
> +'feature-names': ['VirtioInfoBit'],
> +'host-features': 'uint64',
> +'guest-features': 'uint64',
> +'status': 'uint64'

I'm wondering if this is the best representation (where the caller has
to parse the integer and then lookup in feature-names what each bit of
the integer represents).  But I'm not sure I have anything better off
the top of my head.

> +}
> +}
> +
> +##
> +# @VirtioInfo:
> +#
> +# Information about virtio devices
> +#
> +# @feature-names: names of common virtio features
> +#
> +# @status-names: names of bits which represents virtio device status
> +#
> +# @devices: list of per-device virtio information
> +#
> +# Since: 2.11.0
> +#
> +##
> +{
> +'struct': 'VirtioInfo',
> +'data': {
> +'feature-names': ['VirtioInfoBit'],

Why is feature-names listed at two different nestings of the return value?

> +'status-names': ['VirtioInfoBit'],
> +'devices': ['VirtioInfoDevice']
> +}
> +}
> +
> +
> +##
> +# @query-virtio:
> +#
> +# Returns generic and per-device virtio information
> +#
> +# Since: 2.11.0
> +#
> +##
> +{
> +'command': 'query-virtio',
> +'returns': 'VirtioInfo'
> +}
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [Qemu-block] [PATCH 8/8] nbd: Minimal structured read for client

2017-10-03 Thread Paolo Bonzini
On 03/10/2017 14:26, Vladimir Sementsov-Ogievskiy wrote:
> 03.10.2017 13:07, Paolo Bonzini wrote:
>> On 26/09/2017 00:19, Eric Blake wrote:
 +    /* here we deal with successful structured reply */
 +    switch (s->reply.type) {
 +    QEMUIOVector sub_qiov;
 +    case NBD_SREP_TYPE_OFFSET_DATA:
>>> This is putting a LOT of smarts directly into the receive routine.
>>> Here's where I was previously wondering (and I think Paolo as well)
>>> whether it might be better to split the efforts: the generic function
>>> reads off the chunk information and any payload, but a per-command
>>> callback function then parses the chunks.  Especially since the
>>> definition of the chunks differs on a per-command basis (yes, the NBD
>>> spec will try to not reuse an SREP chunk type across multiple commands
>>> unless the semantics are similar, but that's a bit more fragile).  This
>>> particularly matters given my statement above that you want a
>>> discriminated union, rather than a struct that contains unused fields,
>>> for handling different SREP chunk types.
>> I think there should be two kinds of replies: 1) read directly into a
>> QEMUIOVector, using structured replies only as an encapsulation of the
> 
> who should read to qiov? reply_entry, or calling coroutine?..
> reply_entry should anyway
> parse reply, to understand should it read it all or read it to qiov (or
> yield back, and then
> calling coroutine will read to qiov)..

The CMD_READ coroutine should---either directly or, in case you have a
structured reply, after reading each chunk header.

Paolo

>> payload; 2) read a chunk at a time into malloc-ed memory, yielding back
>> to the calling coroutine after receiving one complete chunk.
>>
>> In the end this probably means that you have a read_chunk_header
>> function and a read_chunk function.  READ has a loop that calls
>> read_chunk_header followed by direct reading into the QEMUIOVector,
>> while everyone else calls read_chunk.
>>
>> Maybe qio_channel_readv/writev_full could have "offset" and "bytes"
>> arguments.  Most code in iov_send_recv could be cut-and-pasted.  (When
>> sheepdog is converted to QIOChannel, iov_send_recv can go away).
>>
>> Paolo
> 
> 




Re: [Qemu-devel] [Qemu-block] [PATCH 8/8] nbd: Minimal structured read for client

2017-10-03 Thread Paolo Bonzini
On 03/10/2017 15:35, Vladimir Sementsov-Ogievskiy wrote:
>>>
>>> In the end this probably means that you have a read_chunk_header
>>> function and a read_chunk function.  READ has a loop that calls
>>> read_chunk_header followed by direct reading into the QEMUIOVector,
>>> while everyone else calls read_chunk.
>>
>> accordingly to spec, we can receive several error reply chunks to any
>> request,
>> so loop, receiving them should be common for all requests I think
> 
> as well as handling error chunks should be common..

Yes, reading error chunks should be part of read_chunk_header.

Paolo



Re: [Qemu-devel] [PULL 0/3] Usb 20170929 patches

2017-10-03 Thread Peter Maydell
On 29 September 2017 at 12:00, Gerd Hoffmann  wrote:
> The following changes since commit ab161529261928ae7f3556e3220829c34b2686ec:
>
>   Merge remote-tracking branch 
> 'remotes/dgilbert/tags/pull-migration-20170927a' into staging (2017-09-27 
> 22:44:51 +0100)
>
> are available in the git repository at:
>
>   git://git.kraxel.org/qemu tags/usb-20170929-pull-request
>
> for you to fetch changes up to 13787d59cf86bac230c4d3eec3580110f53ac113:
>
>   usb: Use angle brackets for cacard include directive (2017-09-29 12:28:26 
> +0200)
>
> 
> usb fixes.
>
> 

This fails to build from clean (x86-64 Linux host):

make[1]: *** No rule to make target '../hw/usb/host-stub.o', needed by
'qemu-system-microblaze'. Stop.

(and similar for other targets).

thanks
-- PMM



Re: [Qemu-devel] [RFC v2 1/2] machine: Add a valid_cpu_types property

2017-10-03 Thread Eduardo Habkost
On Thu, Sep 21, 2017 at 04:41:50PM -0700, Alistair Francis wrote:
> Signed-off-by: Alistair Francis 
> ---
> 
> RFC v2:
>  - Rebase on Igor's cpu_type work
>  - Use object_class_dynamic_cast()
>  - Use a NULL terminated cahr** list
>  - Do the check before the machine_class init() is called
> 
> 
>  hw/core/machine.c   | 35 +++
>  include/hw/boards.h |  1 +
>  2 files changed, 36 insertions(+)
> 
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index 80647edc2a..abebfabdb8 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -758,6 +758,41 @@ void machine_run_board_init(MachineState *machine)
>  if (nb_numa_nodes) {
>  machine_numa_finish_init(machine);
>  }
> +
> +if (machine_class->valid_cpu_types && machine->cpu_type) {
> +int i;
> +
> +for (i = 0; machine_class->valid_cpu_types[i]; i++) {
> +ObjectClass *class = object_class_by_name(machine->cpu_type);
> +
> +if (!class) {
> +break;
> +}
> +
> +if (object_class_dynamic_cast(class,
> +  
> machine_class->valid_cpu_types[i])) {
> +/* The user specificed CPU is in the valid field, we are
> + * good to go.
> + */
> +goto done;

I would move the object_class_by_name() call outside the for loop
and remove the "goto", like this:

if (machine->cpu_type && machine_class->valid_cpu_types) {
ObjectClass *class = object_class_by_name(machine->cpu_type);
int i;

/* machine->cpu_type is supposed to be always a valid QOM type */
assert(class);

for (i = 0; machine_class->valid_cpu_types[i]; i++) {
if (object_class_dynamic_cast(class,
  machine_class->valid_cpu_types[i])) {
/* Valid CPU type, we're good to go */
break;
}
}
if (!machine_class->valid_cpu_types[i]) {
error_report(...);
...
}
}

machine_class->init(machine);

> +}
> +}
> +
> +/* The user specified CPU must not be a valid CPU, print a sane
> + * error
> + */
> +error_report("Invalid CPU: %s", machine->cpu_type);
> +error_printf("The valid options are: %s",
> + machine_class->valid_cpu_types[0]);
> +for (i = 1; machine_class->valid_cpu_types[i]; i++) {
> +error_printf(", %s", machine_class->valid_cpu_types[i]);
> +}
> +error_printf("\n");

I would still like to make this share code with
query-cpu-definitions one day, but I'm OK with this
implementation.

I would just rewrite the message as "valid types are:" instead of
"valid options are:" and "Invalid CPU type:" instead of "Invalid
CPU:", because the -cpu option doesn't need to match a string in
valid_cpu_types exactly, it just needs to resolve to a type that
implements a valid type.


> +
> +exit(1);
> +}
> +
> +done:
>  machine_class->init(machine);
>  }
>  
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index 156e0a5701..191a5b3cd8 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -191,6 +191,7 @@ struct MachineClass {
>  bool has_hotpluggable_cpus;
>  bool ignore_memory_transaction_failures;
>  int numa_mem_align_shift;
> +const char **valid_cpu_types;
>  void (*numa_auto_assign_ram)(MachineClass *mc, NodeInfo *nodes,
>   int nb_nodes, ram_addr_t size);
>  
> -- 
> 2.11.0
> 
> 

-- 
Eduardo



[Qemu-devel] [PATCH] hw/ppc: use 0 instead of fdt_path_offset(fdt, "/")

2017-10-03 Thread Greg Kurz
The offset of the root node is guaranteed to be 0.

This doesn't fix anything, it's just trivial cleanup of the two
remaining places where this was done under hw/ppc.

Signed-off-by: Greg Kurz 
---
 hw/ppc/pnv.c   |3 +--
 hw/ppc/spapr.c |3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index d46d91c76f5c..84b2389ea60b 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -92,8 +92,7 @@ static int get_cpus_node(void *fdt)
 int cpus_offset = fdt_path_offset(fdt, "/cpus");
 
 if (cpus_offset < 0) {
-cpus_offset = fdt_add_subnode(fdt, fdt_path_offset(fdt, "/"),
-  "cpus");
+cpus_offset = fdt_add_subnode(fdt, 0, "cpus");
 if (cpus_offset) {
 _FDT((fdt_setprop_cell(fdt, cpus_offset, "#address-cells", 0x1)));
 _FDT((fdt_setprop_cell(fdt, cpus_offset, "#size-cells", 0x0)));
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index ff87f155d55e..352ff3d614e8 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -353,8 +353,7 @@ static int spapr_fixup_cpu_dt(void *fdt, sPAPRMachineState 
*spapr)
 
 cpus_offset = fdt_path_offset(fdt, "/cpus");
 if (cpus_offset < 0) {
-cpus_offset = fdt_add_subnode(fdt, fdt_path_offset(fdt, "/"),
-  "cpus");
+cpus_offset = fdt_add_subnode(fdt, 0, "cpus");
 if (cpus_offset < 0) {
 return cpus_offset;
 }




Re: [Qemu-devel] [PATCH 00/43] Windbg supporting

2017-10-03 Thread Ladi Prosek
Hi,

On Tue, Sep 26, 2017 at 1:04 PM, Mihail Abakumov
 wrote:
> We made the debugger module WinDbg (like GDB) for QEMU. This is the 
> replacement of the remote stub in Windows kernel. Used for remote Windows 
> kernel debugging without debugging mode.
>
> WinDbg is a multipurpose debugger for the Microsoft Windows computer 
> operating system, distributed by Microsoft. Recent versions of WinDbg have 
> been and are being distributed as part of the free Debugging Tools for 
> Windows suite.
>
> How to start debugging QEMU using WinDbg:
>   Run QEMU with next option:
> -windbg pipe:
>   QEMU will start and pause for waiting WinDbg connection.
>   Run WinDbg with next options:
> -b -k com:pipe,baud=115200,port=\\.\pipe\,resets=0
>   Wait for debugger connect to kernel.
>
> Note: You can add Symbol Search Path in WinDbg such as 
> srv*c:\tmp*http://msdl.microsoft.com/download/symbols.
>
> How it works:
> The WinDbg debugger has the possibility of connecting to a remote debug 
> service (Kdsrv.exe) in the Windows kernel. Therefore, it is possible to 
> connect to the guest system running in the QEMU emulator. Kernel debugging is 
> possible only with the enabled debugging mode, may change at the same time. 
> Our module of WinDbg debugger for QEMU is an alternative of the remote 
> debugging service in the kernel. Thus, the debugger connects to the debugging 
> module, not to the kernel of the operating system. The module obtains all the 
> necessary information answering debugger requests from the QEMU emulator. At 
> the same time for debugging there is no need to enable debugging mode in the 
> kernel. This leads to hidden debugging. Our module supports all features of 
> WinDbg regarding remote debugging, besides interception of events and 
> exceptions. Only i386 is supported now.

I wanted to try this to debug a WinXP VM running on Linux from another
VM on the same host. I used my usual windbg setup only instead of

  -serial tcp:localhost:

I had

  -windbg tcp:localhost:

in the QEMU command line of the debugging target and

  -serial tcp:localhost:,server,nowait

for the VM running windbg, but I didn't succeed even after disabling
KVM which seems to be one of the limitations.

I understand that you run QEMU on Windows. Before I dig deeper, have
you tried any other backend for -windbg or maybe running on a Linux
host? Is it expected to work?

Thank you!
Ladi

> ---
>
> Mihail Abakumov (43):
>   windbg: added empty windbgstub files
>   windbg: added windbg's KD header file
>   windbg: modified windbgkd.h
>   windbg: added '-windbg' option
>   windbg: added helper features
>   windbg: added WindbgState
>   windbg: added chardev
>   windbg: hook to wrmsr operation
>   windbg: handler of fs/gs register
>   windbg: structures for parsing data stream
>   windbg: parsing data stream
>   windbg: send data and control packets
>   windbg: handler of parsing context
>   windbg: init DBGKD_ANY_WAIT_STATE_CHANGE
>   windbg: sized data buffer
>   windbg: generate ExceptionStateChange
>   windbg: generate LoadSymbolsStateChange
>   windbg: windbg_vm_stop
>   windbg: implemented windbg_process_control_packet
>   windbg: implemented windbg_process_data_packet
>   windbg: implemented windbg_process_manipulate_packet
>   windbg: implemented kd_api_read_virtual_memory and 
> kd_api_read_virtual_memory
>   windbg: kernel's structures
>   windbg: implemented kd_api_get_context and kd_api_set_context
>   windbg: implemented kd_api_read_control_space and 
> kd_api_write_control_space
>   windbg: implemented windbg_read_context
>   windbg: implemented windbg_write_context
>   windbg: implemented windbg_read_ks_regs
>   windbg: implemented windbg_write_ks_regs
>   windbg: implemented windbg_set_sr
>   windbg: implemented windbg_set_dr
>   windbg: implemented windbg_set_dr7
>   windbg: implemented windbg_hw_breakpoint_insert and 
> windbg_hw_breakpoint_remove
>   windbg: implemented kd_api_write_breakpoint and 
> kd_api_restore_breakpoint
>   windbg: debug exception subscribing
>   windbg: implemented kd_api_continue
>   windbg: implemented kd_api_read_io_space and kd_api_write_io_space
>   windbg: implemented kd_api_read_physical_memory and 
> kd_api_write_physical_memory
>   windbg: implemented kd_api_get_version
>   windbg: implemented kd_api_read_msr and kd_api_write_msr
>   windbg: implemented kd_api_search_memory
>   windbg: implemented kd_api_fill_memory
>   windbg: implemented kd_api_query_memory
>
>
>  Makefile.target |5
>  cpus.c  |   18
>  gdbstub.c   |4
>  include/exec/windbgkd.h | 1030 ++
>  include/exec/windbgstub-utils.h |  132 +++
>  include/exec/windbgstub.h   |   21
>  include/sysemu/sysemu.h |2
>  qemu-options.h

Re: [Qemu-devel] [PATCH] qom: add helpers REGISTER_STATIC_TYPE[S]()

2017-10-03 Thread Eduardo Habkost
On Tue, Oct 03, 2017 at 02:14:46PM +0200, Igor Mammedov wrote:
> it will help to remove code duplication in places
> that currently open code registration of static
> type[s] and remove necessity to declare function
> for type_init() to call, when only static types
> need to be registered.
> 
> Signed-off-by: Igor Mammedov 
> ---
> I'm going to use it for CPU types in followup patches
> 
> CC: ehabk...@redhat.com
> ---
>  include/qemu/module.h | 10 ++
>  include/qom/object.h  | 10 ++
>  qom/object.c  |  9 +
>  3 files changed, 29 insertions(+)
> 
> diff --git a/include/qemu/module.h b/include/qemu/module.h
> index 56dd218..60dd632 100644
> --- a/include/qemu/module.h
> +++ b/include/qemu/module.h
> @@ -52,6 +52,16 @@ typedef enum {
>  #define type_init(function) module_init(function, MODULE_INIT_QOM)
>  #define trace_init(function) module_init(function, MODULE_INIT_TRACE)
>  
> +#define REGISTER_STATIC_TYPES(t, nr)\

I'm unsure about the name.  We already have a declarative way to
register machine types (DEFINE_MACHINE), maybe use "DEFINE_*" for
consistency?

Also, this function won't work if t isn't a static variable, will
it?  The "STATIC" part looks redundant.

In other words, how about "DEFINE_TYPE" and "DEFINE_TYPES"?


> +static void do_qemu_init_ ## t(void)\
> +{   \
> +type_register_static_array(t, nr);  \

qemu/module.h doesn't include qom/object.h.  I think this should
go to either qom/object.h or a new header file.

> +}   \
> +type_init(do_qemu_init_ ## t)
> +
> +#define REGISTER_STATIC_TYPE(t) \
> +REGISTER_STATIC_TYPES(t, 1)
> +
>  #define block_module_load_one(lib) module_load_one("block-", lib)
>  
>  void register_module_init(void (*fn)(void), module_init_type type);
> diff --git a/include/qom/object.h b/include/qom/object.h
> index f3e5cff..17fcadd 100644
> --- a/include/qom/object.h
> +++ b/include/qom/object.h
> @@ -789,6 +789,16 @@ Type type_register_static(const TypeInfo *info);
>  Type type_register(const TypeInfo *info);
>  
>  /**
> + * type_register_static_array:
> + * @infos: The array of the new type #TypeInfo structures.
> + * @nr_infos: number of entries in @infos
> + *
> + * @infos and all of the strings it points to should exist for the life time
> + * that the type is registered.
> + */
> +void type_register_static_array(const TypeInfo *infos, int nr_infos);

This new function is probably less controversial than the new
module.h-based code.  Maybe worth moving to a separate patch so
it can be merged earlier?

(If I were you, I would just use type_register_static_array()
inside the existing *_cpu_register_types() functions by now, so
this won't block the whole series, and worry about
REGISTER_STATIC_TYPE*/DEFINE_TYPE* later.)


> +
> +/**
>   * object_class_dynamic_cast_assert:
>   * @klass: The #ObjectClass to attempt to cast.
>   * @typename: The QOM typename of the class to cast to.
> diff --git a/qom/object.c b/qom/object.c
> index 3e18537..40b1729 100644
> --- a/qom/object.c
> +++ b/qom/object.c
> @@ -151,6 +151,15 @@ TypeImpl *type_register_static(const TypeInfo *info)
>  return type_register(info);
>  }
>  
> +void type_register_static_array(const TypeInfo *infos, int nr_infos)
> +{
> +int i;
> +
> +for (i = 0; i < nr_infos; i++) {
> +assert(type_register_static(&infos[i]));

Why the assert()?  type_register_static() is already guaranteed
to never return NULL.

This will break if compiled with -DNDEBUG: assert() won't even
evaluate the expression if NDEBUG is defined.

> +}
> +}
> +
>  static TypeImpl *type_get_by_name(const char *name)
>  {
>  if (name == NULL) {
> -- 
> 2.7.4
> 

-- 
Eduardo



Re: [Qemu-devel] [Bug 1320360] Re: usb passthrough not working anymore

2017-10-03 Thread Martin Röh
Hi,

the ticket can be close. All works fine with actual opensuse tumbleweed 
and qemu 2.10.0 :-)

Best regards

Martin

Am 03.10.2017 um 12:42 schrieb Thomas Huth:
> Triaging old bug tickets... can you still reproduce this issue with the
> latest version of QEMU? Or could we close this ticket nowadays?
> 
> ** Changed in: qemu
> Status: New => Incomplete
>

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

Title:
  usb passthrough not working anymore

Status in QEMU:
  Incomplete

Bug description:
  Hi,

  I'm using qemu 2.0.0 with opensuse 13.1 x84_64 bit as host and window7
  as guest. Til qemu version 1.6.2 USB passthrough works perfectly, but
  starting with qemu 2.0.0 passthrough stop working. I can still add the
  usb device but when I start the guest following message appears:

  "unable to execute QEMU command 'device_add': 'usb-host' is not a
  valid device model name"

  Then the guest will not start.

  I try it with different usb devices (iphone, stick, hdd), always the
  same error.

  Are there any news / hints about this ?

  Regards

  Martin

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



Re: [Qemu-devel] [PATCH v4 1/2] virtio: introduce `query-virtio' QMP command

2017-10-03 Thread Jan Dakinevich


On 10/03/2017 05:02 PM, Eric Blake wrote:
> On 10/03/2017 07:47 AM, Jan Dakinevich wrote:
>> The command is intended for gathering virtio information such as status,
>> feature bits, negotiation status. It is convenient and useful for debug
>> purpose.
>>
>> The commands returns generic virtio information for virtio such as
>> common feature names and status bits names and information for all
>> attached to current machine devices.
>>
>> To retrieve names of device-specific features `get_feature_name'
>> callback in VirtioDeviceClass also was introduced.
>>
>> Cc: Denis V. Lunev 
>> Signed-off-by: Jan Dakinevich 
>> ---
>>  hw/block/virtio-blk.c   |  21 +
>>  hw/char/virtio-serial-bus.c |  15 +++
>>  hw/display/virtio-gpu.c |  13 ++
>>  hw/net/virtio-net.c |  35 +++
>>  hw/scsi/virtio-scsi.c   |  16 +++
>>  hw/virtio/Makefile.objs |   2 +
>>  hw/virtio/virtio-balloon.c  |  15 +++
>>  hw/virtio/virtio-stub.c |   9 
>>  hw/virtio/virtio.c  | 101 
>> 
>>  include/hw/virtio/virtio.h  |   2 +
>>  qapi-schema.json|   1 +
>>  qapi/virtio.json|  94 +
>>  12 files changed, 324 insertions(+)
>>  create mode 100644 hw/virtio/virtio-stub.c
>>  create mode 100644 qapi/virtio.json
> 
> This creates a new .json file, but does not touch MAINTAINERS.  Our idea
> in splitting the .json files was to make it easier for each sub-file
> that needs a specific maintainer in addition to the overall *.json line
> for QAPI maintainers, so this may deserve a MAINTAINERS entry.
> 

Ok.

>> +++ b/qapi/virtio.json
>> @@ -0,0 +1,94 @@
>> +# -*- Mode: Python -*-
>> +#
>> +
>> +##
>> +# = Virtio devices
>> +##
>> +
>> +{ 'include': 'common.json' }
>> +
>> +##
>> +# @VirtioInfoBit:
>> +#
>> +# Named virtio bit
>> +#
>> +# @bit: bit number
>> +#
>> +# @name: bit name
>> +#
>> +# Since: 2.11.0
>> +#
>> +##
>> +{
>> +'struct': 'VirtioInfoBit',
>> +'data': {
>> +'bit': 'uint64',
> 
> Why is this a 64-bit value? Are the values 0-63, or are they 1, 2, 4, 8,
> ...?  The documentation on 'bit number' is rather sparse.

I would prefer `uint' here, but I don't see generic unsigned type (may
be, I am mistaken). I could use uint8 here, though.

> 
>> +'name': 'str'
> 
> Wouldn't an enum type be better than an open-ended string?
> 

Bit names are not known here, they are obtained from virtio device
implementations.

>> +}
>> +}
>> +
>> +##
>> +# @VirtioInfoDevice:
>> +#
>> +# Information about specific virtio device
>> +#
>> +# @qom_path: QOM path of the device
> 
> Please make this 'qom-path' - new interfaces should prefer '-' over '_'.

Ok.

>> +#
>> +# @feature-names: names of device-specific features
>> +#
>> +# @host-features: bitmask of features, provided by devices
>> +#
>> +# @guest-features: bitmask of features, acknowledged by guest
>> +#
>> +# @status: virtio device status bitmask
>> +#
>> +# Since: 2.11.0
>> +#
>> +##
>> +{
>> +'struct': 'VirtioInfoDevice',
>> +'data': {
>> +'qom_path': 'str',
>> +'feature-names': ['VirtioInfoBit'],
>> +'host-features': 'uint64',
>> +'guest-features': 'uint64',
>> +'status': 'uint64'
> 
> I'm wondering if this is the best representation (where the caller has
> to parse the integer and then lookup in feature-names what each bit of
> the integer represents).  But I'm not sure I have anything better off
> the top of my head.
> 

Consider it as way to tell caller about names of supported features.

>> +}
>> +}
>> +
>> +##
>> +# @VirtioInfo:
>> +#
>> +# Information about virtio devices
>> +#
>> +# @feature-names: names of common virtio features
>> +#
>> +# @status-names: names of bits which represents virtio device status
>> +#
>> +# @devices: list of per-device virtio information
>> +#
>> +# Since: 2.11.0
>> +#
>> +##
>> +{
>> +'struct': 'VirtioInfo',
>> +'data': {
>> +'feature-names': ['VirtioInfoBit'],
> 
> Why is feature-names listed at two different nestings of the return value?
> 

These are different feature names. First names are common and predefined
for all devices. Second names are device-specific.

>> +'status-names': ['VirtioInfoBit'],
>> +'devices': ['VirtioInfoDevice']
>> +}
>> +}
>> +
>> +
>> +##
>> +# @query-virtio:
>> +#
>> +# Returns generic and per-device virtio information
>> +#
>> +# Since: 2.11.0
>> +#
>> +##
>> +{
>> +'command': 'query-virtio',
>> +'returns': 'VirtioInfo'
>> +}
>>
> 

-- 
Best regards
Jan Dakinevich



Re: [Qemu-devel] [PATCH] hw/ppc: use 0 instead of fdt_path_offset(fdt, "/")

2017-10-03 Thread Cédric Le Goater
On 10/03/2017 04:13 PM, Greg Kurz wrote:
> The offset of the root node is guaranteed to be 0.
> 
> This doesn't fix anything, it's just trivial cleanup of the two
> remaining places where this was done under hw/ppc.
> 
> Signed-off-by: Greg Kurz 

Looks good to me.

Reviewed-by: Cédric Le Goater 

Thanks,

C.

> ---
>  hw/ppc/pnv.c   |3 +--
>  hw/ppc/spapr.c |3 +--
>  2 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index d46d91c76f5c..84b2389ea60b 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -92,8 +92,7 @@ static int get_cpus_node(void *fdt)
>  int cpus_offset = fdt_path_offset(fdt, "/cpus");
>  
>  if (cpus_offset < 0) {
> -cpus_offset = fdt_add_subnode(fdt, fdt_path_offset(fdt, "/"),
> -  "cpus");
> +cpus_offset = fdt_add_subnode(fdt, 0, "cpus");
>  if (cpus_offset) {
>  _FDT((fdt_setprop_cell(fdt, cpus_offset, "#address-cells", 
> 0x1)));
>  _FDT((fdt_setprop_cell(fdt, cpus_offset, "#size-cells", 0x0)));
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index ff87f155d55e..352ff3d614e8 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -353,8 +353,7 @@ static int spapr_fixup_cpu_dt(void *fdt, 
> sPAPRMachineState *spapr)
>  
>  cpus_offset = fdt_path_offset(fdt, "/cpus");
>  if (cpus_offset < 0) {
> -cpus_offset = fdt_add_subnode(fdt, fdt_path_offset(fdt, "/"),
> -  "cpus");
> +cpus_offset = fdt_add_subnode(fdt, 0, "cpus");
>  if (cpus_offset < 0) {
>  return cpus_offset;
>  }
> 




[Qemu-devel] [Bug 1714750] Re: 2.10.0 cannot be installed on case-insensitive file system

2017-10-03 Thread Peter Maydell
Update: Sam Protsenko has kindly written and submitted a u-boot patch which 
resolves the filename clash:
https://lists.denx.de/pipermail/u-boot/2017-September/307910.html

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

Title:
  2.10.0 cannot be installed on case-insensitive file system

Status in QEMU:
  New

Bug description:
  The https://download.qemu.org/qemu-2.10.0.tar.bz2 tarball cannot be
  unpacked on a case-insensitive file system because it has a file
  qemu-2.10.0/roms/u-boot/scripts/Kconfig and a directory
  qemu-2.10.0/roms/u-boot/scripts/kconfig. This prevents installation on
  most macOS systems since by default the file system is case
  insensitive. The 2.10.0 upgrade is blocked in Homebrew due to this
  issue. See https://github.com/Homebrew/homebrew-core/pull/17467. This
  is a regression from 2.9.0, which didn't have this problem.

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



Re: [Qemu-devel] [PATCH 0/3] blockjobs: add explicit job culling

2017-10-03 Thread John Snow


On 10/03/2017 05:20 AM, Vladimir Sementsov-Ogievskiy wrote:
> 03.10.2017 06:15, John Snow wrote:
>> For jobs that complete when a monitor isn't looking, there's no way to
>> tell what the job's final return code was. We need to allow jobs to
>> remain in the list until queried for reliable management.
>>
>> This is an RFC; tests are on the way.
>> (Tested only manually via qmp-shell for now.)
> 
> That's a cool feature!
> What about transactions support?
> 

Didn't test that yet (!) but the intent is that it will be compatible.
The jobs in the transaction, whether using grouped-completion mode or
not, will simply hang around in the list after completion.

For grouped-completion=false:

The jobs will complete individually and then remain in the list.

For grouped-completion=true:

The jobs will remain in their ready-to-commit-or-abort state until all
jobs in the transaction are ready to commit-or-abort, then all jobs will
either commit or abort. After commit-or-abort, all jobs (that were
created with manual-cull=true !) will remain in the query list.

The intended effect here is that this property changes NOTHING except
that the job will remain in the query list until it is dismissed, and
should not change anything about how it behaves during its lifetime.

One downside here is that since we have no universal "job creation
argument list" that I can't add it to all jobs universally. In the case
of transactions, though, I could at least add a property that *forces*
all jobs below to become manual-cull style jobs, and that way you'd only
have to specify it once instead of for each action.

--js

>>
>> John Snow (3):
>>    blockjob: add manual-cull property
>>    qmp: add block-job-cull command
>>    blockjob: expose manual-cull property
>>
>>   block/backup.c   | 20 +-
>>   block/commit.c   |  2 +-
>>   block/mirror.c   |  2 +-
>>   block/replication.c  |  5 +++--
>>   block/stream.c   |  2 +-
>>   block/trace-events   |  1 +
>>   blockdev.c   | 28 +
>>   blockjob.c   | 46
>> +++--
>>   include/block/block_int.h    |  8 +---
>>   include/block/blockjob.h | 21 +++
>>   include/block/blockjob_int.h |  2 +-
>>   qapi/block-core.json | 49
>> 
>>   tests/test-blockjob-txn.c    |  2 +-
>>   tests/test-blockjob.c    |  2 +-
>>   14 files changed, 155 insertions(+), 35 deletions(-)
>>
> 
> 

Oh, while I'm here, I should point out that another downside of this
patch is that it doesn't prevent "cancel" from attempting to re-enter
the job. Or rather, I had to patch that out specifically. The job
remains in a list of jobs that some portions of the code consider to be
"active" jobs. (look for any code that checks to see if the job has
started.)

A (perhaps) more provably cleaner approach would be to simply move any
completed job onto a different list upon completion, and patch
query-jobs to query both lists, and allow the cull command to remove any
jobs on that list. A downside of that approach, however, is that without
multiple job support, you may launch a second job that perhaps
overwrites the first job unless you're careful about how you manage that
data.

There are pros and cons to either way, but I'd rather not get in the
business of overhauling the blockjobs API unless it's for universal jobs.

--js



Re: [Qemu-devel] [RFC 4/5] pci: Simplify pci_bus_is_root()

2017-10-03 Thread Eduardo Habkost
On Tue, Oct 03, 2017 at 08:14:22PM +1100, David Gibson wrote:
> pci_bus_is_root() currently relies on a method in the PCIBusClass.
> But it's always known if a PCI bus is a root bus when we create it, so
> using a dynamic method is overkill.
> 
> This replaces it with an IS_ROOT bit in a new flags field, which is set on
> root buses and otherwise clear.  As a bonus this removes the special
> is_root logic from pci_expander_bridge, since it already creates its bus
> as a root bus.
> 
> Signed-off-by: David Gibson 
> 
> # Conflicts:
> # include/hw/pci/pci_bus.h

Should this be part of the commit message?

> ---
[...]
> diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
> index 77d92a3dc4..cbb3386207 100644
> --- a/include/hw/pci/pci.h
> +++ b/include/hw/pci/pci.h
> @@ -404,6 +404,11 @@ typedef AddressSpace *(*PCIIOMMUFunc)(PCIBus *, void *, 
> int);
>  #define PCI_BUS_GET_CLASS(obj) OBJECT_GET_CLASS(PCIBusClass, (obj), 
> TYPE_PCI_BUS)
>  #define TYPE_PCIE_BUS "PCIE"
>  
> +enum PCIBusFlags {
> +/* This bus is the root of a PCI domain */
> +PCI_BUS_IS_ROOT = 0x0001,
> +};
> +
>  typedef struct PCIBusClass {
>  /*< private >*/
>  BusClass parent_class;
> @@ -416,6 +421,7 @@ typedef struct PCIBusClass {
>  
>  struct PCIBus {
>  BusState qbus;
> +enum PCIBusFlags flags;

Why not a simple boolean field?  If we want to keep the struct
size smaller when adding more flags, we can use bit-fields.

>  PCIIOMMUFunc iommu_fn;
>  void *iommu_opaque;
>  uint8_t devfn_min;
> @@ -440,8 +446,12 @@ struct PCIBus {
>  Notifier machine_done;
>  };
>  
> +static inline bool pci_bus_is_root(PCIBus *bus)
> +{
> +return !!(bus->flags & PCI_BUS_IS_ROOT);
> +}
> +
>  bool pci_bus_is_express(PCIBus *bus);
> -bool pci_bus_is_root(PCIBus *bus);
>  void pci_root_bus_new_inplace(PCIBus *bus, size_t bus_size, DeviceState 
> *parent,
>const char *name,
>MemoryRegion *address_space_mem,
> -- 
> 2.13.6
> 

-- 
Eduardo



[Qemu-devel] [Bug 1327608] Re: monitor socked path is cut a 105 characters

2017-10-03 Thread Daniel Berrange
There's actually two bugs here.

First QEMU was truncating the UNIX, but because it used 'snprintf', QEMU
truncated it at 107 characters and then added a trailing NUL, instead of
truncating at 108 characters and not having a NUL (which is perfectly
fine for AF_UNIX)

Second though if you look at the path socat is using, it has truncated
it at 104 characters. So even if QEMU had correctly truncated at 108
characters, socat would still have failed.

QEMU git now just returns an immediate if the path is too long rather
than truncating, so I think we can just close this.

** Changed in: qemu
   Status: Incomplete => Fix Committed

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

Title:
  monitor socked path is cut a 105 characters

Status in QEMU:
  Fix Committed

Bug description:
  Starting a VM like so:

  /usr/bin/qemu-system-x86_64 -machine accel=kvm -monitor
  unix:/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt
  /lv-gentoosummerschool/gentoo-summerschool/gentoo-
  summerschool.img.monitor,server,nowait -name gentoo-summerschool
  -chardev
  socket,id=monitor,path=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J
  /vg-virt/lv-gentoosummerschool/gentoo-
  summerschool/monitor.sock,server,nowait -monitor chardev:monitor
  -chardev
  socket,id=serial0,path=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J
  /vg-virt/lv-gentoosummerschool/gentoo-
  summerschool/console.sock,server,nowait -serial chardev:serial0
  -enable-kvm -cpu kvm64 -smp 2 -netdev
  tap,id=net0,script=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J
  /vg-virt/lv-gentoosummerschool/gentoo-summerschool/qemu-ifup.bash
  -device e1000,netdev=net0,mac=00:00:00:00:00:02 -drive
  id=disk,file=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J
  /vg-virt/lv-gentoosummerschool/gentoo-summerschool/gentoo-
  summerschool.img,if=none -device ahci,id=ahci -device ide-
  drive,drive=disk,bus=ahci.0 -m 2048 -vga qxl -spice
  port=2002,addr=192.168.4.2,password=NO-thats-not-my-pwd -device
  virtio-serial-pci -device
  virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev
  spicevmc,id=spicechannel0,name=vdagent

  
  The path: 

  unix:/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt
  /lv-gentoosummerschool/gentoo-summerschool/gentoo-
  summerschool.img.monitor

  ...is cut like so when I try to shutdown:

  pink ~ # echo system_powerdown | socat - 
UNIX-CONNECT:/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschool/gentoo-summerschool.img.monitor
  2014/06/08 06:39:01 socat[2344] E connect(3, AF=1 
"/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschoo",
 110): No such file or directory
  pink ~ # 

  
  It does work with a sorter path like: 
  pink ~ # echo system_powerdown | socat - 
UNIX-CONNECT:'/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/my.img.monitor'
 
  QEMU 1.5.3 monitor - type 'help' for more information
  (qemu) system_powerdown
  (qemu) pink ~ #

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



Re: [Qemu-devel] [PATCH 09/38] m68k: cleanup cpu type name composition

2017-10-03 Thread Laurent Vivier
Le 02/10/2017 à 11:07, Igor Mammedov a écrit :
> use new M68K_CPU_TYPE_NAME to compose CPU type names
> and get rid of intermediate M68kCPUInfo/register_cpu_type()
> which is replaced by static TypeInfo array.
> 
> Signed-off-by: Igor Mammedov 
> ---
> CC: laur...@vivier.eu
> ---
>  target/m68k/cpu.h |  3 +++
>  target/m68k/cpu.c | 75 
> ---
>  2 files changed, 30 insertions(+), 48 deletions(-)
> 
> diff --git a/target/m68k/cpu.h b/target/m68k/cpu.h
> index d936547..afae5f6 100644
> --- a/target/m68k/cpu.h
> +++ b/target/m68k/cpu.h
> @@ -323,6 +323,9 @@ void register_m68k_insns (CPUM68KState *env);
>  
>  #define cpu_init(cpu_model) cpu_generic_init(TYPE_M68K_CPU, cpu_model)
>  
> +#define M68K_CPU_TYPE_SUFFIX "-" TYPE_M68K_CPU
> +#define M68K_CPU_TYPE_NAME(model) model M68K_CPU_TYPE_SUFFIX
> +
>  #define cpu_signal_handler cpu_m68k_signal_handler
>  #define cpu_list m68k_cpu_list
>  
> diff --git a/target/m68k/cpu.c b/target/m68k/cpu.c
> index 8c70e08..f0f90e9 100644
> --- a/target/m68k/cpu.c
> +++ b/target/m68k/cpu.c
> @@ -87,7 +87,7 @@ static ObjectClass *m68k_cpu_class_by_name(const char 
> *cpu_model)
>  ObjectClass *oc;
>  char *typename;
>  
> -typename = g_strdup_printf("%s-" TYPE_M68K_CPU, cpu_model);
> +typename = g_strdup_printf(M68K_CPU_TYPE_NAME("%s"), cpu_model);
>  oc = object_class_by_name(typename);
>  g_free(typename);
>  if (oc != NULL && (object_class_dynamic_cast(oc, TYPE_M68K_CPU) == NULL 
> ||
> @@ -202,23 +202,6 @@ static void any_cpu_initfn(Object *obj)
>  m68k_set_feature(env, M68K_FEATURE_WORD_INDEX);
>  }
>  
> -typedef struct M68kCPUInfo {
> -const char *name;
> -void (*instance_init)(Object *obj);
> -} M68kCPUInfo;
> -
> -static const M68kCPUInfo m68k_cpus[] = {
> -{ .name = "m68000", .instance_init = m68000_cpu_initfn },
> -{ .name = "m68020", .instance_init = m68020_cpu_initfn },
> -{ .name = "m68030", .instance_init = m68030_cpu_initfn },
> -{ .name = "m68040", .instance_init = m68040_cpu_initfn },
> -{ .name = "m68060", .instance_init = m68060_cpu_initfn },
> -{ .name = "m5206", .instance_init = m5206_cpu_initfn },
> -{ .name = "m5208", .instance_init = m5208_cpu_initfn },
> -{ .name = "cfv4e", .instance_init = cfv4e_cpu_initfn },
> -{ .name = "any",   .instance_init = any_cpu_initfn },
> -};
> -
>  static void m68k_cpu_realizefn(DeviceState *dev, Error **errp)
>  {
>  CPUState *cs = CPU(dev);
> @@ -295,36 +278,32 @@ static void m68k_cpu_class_init(ObjectClass *c, void 
> *data)
>  dc->vmsd = &vmstate_m68k_cpu;
>  }
>  
> -static void register_cpu_type(const M68kCPUInfo *info)
> -{
> -TypeInfo type_info = {
> -.parent = TYPE_M68K_CPU,
> -.instance_init = info->instance_init,
> -};
> -
> -type_info.name = g_strdup_printf("%s-" TYPE_M68K_CPU, info->name);
> -type_register(&type_info);
> -g_free((void *)type_info.name);
> -}
> +#define DEFINE_M68K_CPU_TYPE(cpu_model, initfn) \
> +{   \
> +.name = M68K_CPU_TYPE_NAME(cpu_model),  \
> +.instance_init = initfn,\
> +.parent = TYPE_M68K_CPU,\
> +}
>  
> -static const TypeInfo m68k_cpu_type_info = {
> -.name = TYPE_M68K_CPU,
> -.parent = TYPE_CPU,
> -.instance_size = sizeof(M68kCPU),
> -.instance_init = m68k_cpu_initfn,
> -.abstract = true,
> -.class_size = sizeof(M68kCPUClass),
> -.class_init = m68k_cpu_class_init,
> +static const TypeInfo m68k_cpus_type_infos[] = {
> +{ /* base class should be registered first */
> +.name = TYPE_M68K_CPU,
> +.parent = TYPE_CPU,
> +.instance_size = sizeof(M68kCPU),
> +.instance_init = m68k_cpu_initfn,
> +.abstract = true,
> +.class_size = sizeof(M68kCPUClass),
> +.class_init = m68k_cpu_class_init,
> +},
> +DEFINE_M68K_CPU_TYPE("m68000", m68000_cpu_initfn),
> +DEFINE_M68K_CPU_TYPE("m68020", m68020_cpu_initfn),
> +DEFINE_M68K_CPU_TYPE("m68030", m68030_cpu_initfn),
> +DEFINE_M68K_CPU_TYPE("m68040", m68040_cpu_initfn),
> +DEFINE_M68K_CPU_TYPE("m68060", m68060_cpu_initfn),
> +DEFINE_M68K_CPU_TYPE("m5206", m5206_cpu_initfn),
> +DEFINE_M68K_CPU_TYPE("m5208", m5208_cpu_initfn),
> +DEFINE_M68K_CPU_TYPE("cfv4e", cfv4e_cpu_initfn),
> +DEFINE_M68K_CPU_TYPE("any", any_cpu_initfn),
>  };
>  
> -static void m68k_cpu_register_types(void)
> -{
> -int i;
> -
> -type_register_static(&m68k_cpu_type_info);
> -for (i = 0; i < ARRAY_SIZE(m68k_cpus); i++) {
> -register_cpu_type(&m68k_cpus[i]);
> -}
> -}
> -
> -type_init(m68k_cpu_register_types)
> +type_init_from_array(m68k_cpus_type_infos)
> 

Acked-by: Laurent Vivier 




Re: [Qemu-devel] [PATCH v16 4/5] mm: support reporting free page blocks

2017-10-03 Thread Michal Hocko
On Sat 30-09-17 12:05:53, Wei Wang wrote:
> This patch adds support to walk through the free page blocks in the
> system and report them via a callback function. Some page blocks may
> leave the free list after zone->lock is released, so it is the caller's
> responsibility to either detect or prevent the use of such pages.
> 
> One use example of this patch is to accelerate live migration by skipping
> the transfer of free pages reported from the guest. A popular method used
> by the hypervisor to track which part of memory is written during live
> migration is to write-protect all the guest memory. So, those pages that
> are reported as free pages but are written after the report function
> returns will be captured by the hypervisor, and they will be added to the
> next round of memory transfer.
> 
> Signed-off-by: Wei Wang 
> Signed-off-by: Liang Li 
> Cc: Michal Hocko 
> Cc: Michael S. Tsirkin 

Acked-by: Michal Hocko 

> ---
>  include/linux/mm.h |  6 
>  mm/page_alloc.c| 91 
> ++
>  2 files changed, 97 insertions(+)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 46b9ac5..d9652c2 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1835,6 +1835,12 @@ extern void free_area_init_node(int nid, unsigned long 
> * zones_size,
>   unsigned long zone_start_pfn, unsigned long *zholes_size);
>  extern void free_initmem(void);
>  
> +extern void walk_free_mem_block(void *opaque,
> + int min_order,
> + bool (*report_pfn_range)(void *opaque,
> +  unsigned long pfn,
> +  unsigned long num));
> +
>  /*
>   * Free reserved pages within range [PAGE_ALIGN(start), end & PAGE_MASK)
>   * into the buddy system. The freed pages will be poisoned with pattern
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 6d00f74..c6bb874 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -4762,6 +4762,97 @@ void show_free_areas(unsigned int filter, nodemask_t 
> *nodemask)
>   show_swap_cache_info();
>  }
>  
> +/*
> + * Walk through a free page list and report the found pfn range via the
> + * callback.
> + *
> + * Return false if the callback requests to stop reporting. Otherwise,
> + * return true.
> + */
> +static bool walk_free_page_list(void *opaque,
> + struct zone *zone,
> + int order,
> + enum migratetype mt,
> + bool (*report_pfn_range)(void *,
> +  unsigned long,
> +  unsigned long))
> +{
> + struct page *page;
> + struct list_head *list;
> + unsigned long pfn, flags;
> + bool ret;
> +
> + spin_lock_irqsave(&zone->lock, flags);
> + list = &zone->free_area[order].free_list[mt];
> + list_for_each_entry(page, list, lru) {
> + pfn = page_to_pfn(page);
> + ret = report_pfn_range(opaque, pfn, 1 << order);
> + if (!ret)
> + break;
> + }
> + spin_unlock_irqrestore(&zone->lock, flags);
> +
> + return ret;
> +}
> +
> +/**
> + * walk_free_mem_block - Walk through the free page blocks in the system
> + * @opaque: the context passed from the caller
> + * @min_order: the minimum order of free lists to check
> + * @report_pfn_range: the callback to report the pfn range of the free pages
> + *
> + * If the callback returns false, stop iterating the list of free page 
> blocks.
> + * Otherwise, continue to report.
> + *
> + * Please note that there are no locking guarantees for the callback and
> + * that the reported pfn range might be freed or disappear after the
> + * callback returns so the caller has to be very careful how it is used.
> + *
> + * The callback itself must not sleep or perform any operations which would
> + * require any memory allocations directly (not even GFP_NOWAIT/GFP_ATOMIC)
> + * or via any lock dependency. It is generally advisable to implement
> + * the callback as simple as possible and defer any heavy lifting to a
> + * different context.
> + *
> + * There is no guarantee that each free range will be reported only once
> + * during one walk_free_mem_block invocation.
> + *
> + * pfn_to_page on the given range is strongly discouraged and if there is
> + * an absolute need for that make sure to contact MM people to discuss
> + * potential problems.
> + *
> + * The function itself might sleep so it cannot be called from atomic
> + * contexts.
> + *
> + * In general low orders tend to be very volatile and so it makes more
> + * sense to query larger ones first for various optimizations which like
> + * ballooning etc... This will reduce the overhead as well.
> + */
> +void walk_free_mem_block(void *opaque,
> +  

  1   2   3   >