[Qemu-devel] [PATCH 3/3] pseries: Improve tracing of CPU compatibility negotiation

[David Gibson]

This makes some improvements to the debug tracepoints around the
negotiation of CPU compatibility mode during CAS.  The traces are
reorganized to emphasise what the inputs and outputs of the process are,
then distinguish the internal state of the two possible negotiation paths
(current and pre-2.8 machine type compatibility).

Signed-off-by: David Gibson 
---
 hw/ppc/spapr_hcall.c | 14 --
 hw/ppc/trace-events  |  6 --
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index a790da7..cea5d99 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -1109,7 +1109,6 @@ static uint32_t cas_check_pvr_pre_2_9(PowerPCCPU *cpu, 
target_ulong *addr,
 break; /* Terminator record */
 }
 
-trace_spapr_cas_pvr_try(pvr);
 if (!max_lvl &&
 ((cpu->env.spr[SPR_PVR] & pvr_mask) == (pvr & pvr_mask))) {
 cpu_match = true;
@@ -1120,10 +1119,10 @@ static uint32_t cas_check_pvr_pre_2_9(PowerPCCPU *cpu, 
target_ulong *addr,
 } else if (!cpu_match) {
 cas_handle_compat_cpu(pcc, pvr, max_lvl, _lvl, _pvr);
 }
+trace_cas_check_pvr_pre_2_9(pvr, pvr_mask, cpu_match,
+compat_lvl, compat_pvr);
 }
 
-trace_spapr_cas_pvr(cpu->compat_pvr, cpu_match, compat_pvr);
-
 return compat_pvr;
 }
 
@@ -1158,6 +1157,7 @@ static uint32_t cas_check_pvr(PowerPCCPU *cpu, 
target_ulong *addr,
 best_compat = pvr;
 }
 }
+trace_cas_check_pvr(pvr, pvr_mask, explicit_match, best_compat);
 }
 
 if ((best_compat == 0) && (!explicit_match || max_compat)) {
@@ -1168,9 +1168,6 @@ static uint32_t cas_check_pvr(PowerPCCPU *cpu, 
target_ulong *addr,
 return 0;
 }
 
-/* Parsing finished */
-trace_spapr_cas_pvr(cpu->compat_pvr, explicit_match, best_compat);
-
 return best_compat;
 }
 
@@ -1188,6 +1185,9 @@ static target_ulong 
h_client_architecture_support(PowerPCCPU *cpu,
 bool guest_radix;
 Error *local_err = NULL;
 
+trace_cas_check_pvr_start(cpu->compat_pvr, cpu->max_compat,
+  cpu->env.spr[SPR_PVR]);
+
 if (smc->pre_2_9_cas_pvr) {
 cas_pvr = cas_check_pvr_pre_2_9(cpu, , _err);
 } else {
@@ -1198,6 +1198,8 @@ static target_ulong 
h_client_architecture_support(PowerPCCPU *cpu,
 return H_HARDWARE;
 }
 
+trace_cas_check_pvr_complete(cpu->compat_pvr, cas_pvr);
+
 /* Update CPUs */
 if (cpu->compat_pvr != cas_pvr) {
 ppc_set_compat_all(cas_pvr, _err);
diff --git a/hw/ppc/trace-events b/hw/ppc/trace-events
index 43d265f..5329740 100644
--- a/hw/ppc/trace-events
+++ b/hw/ppc/trace-events
@@ -14,8 +14,10 @@ spapr_cas_failed(unsigned long n) "DT diff buffer is too 
small: %ld bytes"
 spapr_cas_continue(unsigned long n) "Copy changes to the guest: %ld bytes"
 
 # hw/ppc/spapr_hcall.c
-spapr_cas_pvr_try(uint32_t pvr) "%x"
-spapr_cas_pvr(uint32_t cur_pvr, bool explicit_match, uint32_t new_pvr) 
"current=%x, explicit_match=%u, new=%x"
+cas_check_pvr_pre_2_9(uint32_t pvr, uint32_t mask, bool match, unsigned lvl, 
uint32_t compat_pvr) "0x%08x/0x%08x match=%d lvl=%d compat_pvr=0x%x"
+cas_check_pvr(uint32_t pvr, uint32_t pvr_mask, bool explicit_match, uint32_t 
best_compat) "0x%08x/0x%08x explicit_match=%d best_compat=0x%08x"
+cas_check_pvr_start(uint32_t compat_pvr, uint32_t max_compat, uint32_t 
phys_pvr) "Initial compat PVR 0x%08x, max compat 0x%08x (real PVR 0x%08x)"
+cas_check_pvr_complete(uint32_t old_pvr, uint32_t new_pvr) "Compatibility PVR 
was 0x%08x, now 0x%08x"
 
 # hw/ppc/spapr_iommu.c
 spapr_iommu_put(uint64_t liobn, uint64_t ioba, uint64_t tce, uint64_t ret) 
"liobn=%"PRIx64" ioba=0x%"PRIx64" tce=0x%"PRIx64" ret=%"PRId64
-- 
2.9.4

[Qemu-devel] [PATCH 1/3] pseries: Split CAS PVR negotiation out into a separate function

[David Gibson]

Guests of the qemu machine type go through a feature negotiation process
known as "client architecture support" (CAS) during early boot.  This does
a number of things, one of which is finding a CPU compatibility mode which
can be supported by both guest and host.

In fact the CPU negotiation is probably the single most complex part of the
CAS process, so this splits it out into a helper function.  We've recently
made some mistakes in maintaining backward compatibility for old machine
types here.  Splitting this out will also make it easier to fix this.

This also adds a possibly useful error message if the negotiation fails
(i.e. if there isn't a CPU mode that's suitable for both guest and host).

Signed-off-by: David Gibson 
---
 hw/ppc/spapr_hcall.c | 49 -
 1 file changed, 32 insertions(+), 17 deletions(-)

diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 2daace4..77d2d66 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -1044,19 +1044,13 @@ static target_ulong h_signal_sys_reset(PowerPCCPU *cpu,
 }
 }
 
-static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
-  sPAPRMachineState *spapr,
-  target_ulong opcode,
-  target_ulong *args)
+static uint32_t cas_check_pvr(PowerPCCPU *cpu, target_ulong *addr,
+  Error **errp)
 {
-target_ulong list = ppc64_phys_to_real(args[0]);
-target_ulong ov_table;
 bool explicit_match = false; /* Matched the CPU's real PVR */
 uint32_t max_compat = cpu->max_compat;
 uint32_t best_compat = 0;
 int i;
-sPAPROptionVector *ov1_guest, *ov5_guest, *ov5_cas_old, *ov5_updates;
-bool guest_radix;
 
 /*
  * We scan the supplied table of PVRs looking for two things
@@ -1066,9 +1060,9 @@ static target_ulong 
h_client_architecture_support(PowerPCCPU *cpu,
 for (i = 0; i < 512; ++i) {
 uint32_t pvr, pvr_mask;
 
-pvr_mask = ldl_be_phys(_space_memory, list);
-pvr = ldl_be_phys(_space_memory, list + 4);
-list += 8;
+pvr_mask = ldl_be_phys(_space_memory, *addr);
+pvr = ldl_be_phys(_space_memory, *addr + 4);
+*addr += 8;
 
 if (~pvr_mask & pvr) {
 break; /* Terminator record */
@@ -1087,17 +1081,38 @@ static target_ulong 
h_client_architecture_support(PowerPCCPU *cpu,
 /* We couldn't find a suitable compatibility mode, and either
  * the guest doesn't support "raw" mode for this CPU, or raw
  * mode is disabled because a maximum compat mode is set */
-return H_HARDWARE;
+error_setg(errp, "Couldn't negotiate a suitable PVR during CAS");
+return 0;
 }
 
 /* Parsing finished */
 trace_spapr_cas_pvr(cpu->compat_pvr, explicit_match, best_compat);
 
-/* Update CPUs */
-if (cpu->compat_pvr != best_compat) {
-Error *local_err = NULL;
+return best_compat;
+}
 
-ppc_set_compat_all(best_compat, _err);
+static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
+  sPAPRMachineState *spapr,
+  target_ulong opcode,
+  target_ulong *args)
+{
+/* Working address in data buffer */
+target_ulong addr = ppc64_phys_to_real(args[0]);
+target_ulong ov_table;
+uint32_t cas_pvr;
+sPAPROptionVector *ov1_guest, *ov5_guest, *ov5_cas_old, *ov5_updates;
+bool guest_radix;
+Error *local_err = NULL;
+
+cas_pvr = cas_check_pvr(cpu, , _err);
+if (local_err) {
+error_report_err(local_err);
+return H_HARDWARE;
+}
+
+/* Update CPUs */
+if (cpu->compat_pvr != cas_pvr) {
+ppc_set_compat_all(cas_pvr, _err);
 if (local_err) {
 error_report_err(local_err);
 return H_HARDWARE;
@@ -1105,7 +1120,7 @@ static target_ulong 
h_client_architecture_support(PowerPCCPU *cpu,
 }
 
 /* For the future use: here @ov_table points to the first option vector */
-ov_table = list;
+ov_table = addr;
 
 ov1_guest = spapr_ovec_parse_vector(ov_table, 1);
 ov5_guest = spapr_ovec_parse_vector(ov_table, 5);
-- 
2.9.4

[Qemu-devel] [PATCH 0/3] pseries: Reverse behaviour change for older machine types

[David Gibson]

152ef80 "pseries: Rewrite CAS PVR compatibility logic" incorrectly
introduced a guest-visible behaviour change into existing versioned
machine type.  Patch 2/2 corrects this change, while 1/2 is a
preliminary clean up to make that easier.

Unfortunately, this bug is already in the released qemu-2.9.0.  Once
this is ready to merge for master, I'll make a backport to apply for
2.9.1 as well.

Changes since RFC:
 * Corrected serious bug in vector address calculation which would
   have broken all the rest of the CAS process
 * Added a third patch with tracing cleanup
 * Correct error in commit message

David Gibson (3):
  pseries: Split CAS PVR negotiation out into a separate function
  pseries: Restore PVR negotiation logic for pre-2.9 machine types
  pseries: Improve tracing of CPU compatibility negotiation

 hw/ppc/spapr.c |   3 ++
 hw/ppc/spapr_hcall.c   | 141 ++---
 hw/ppc/trace-events|   6 ++-
 include/hw/ppc/spapr.h |   1 +
 4 files changed, 131 insertions(+), 20 deletions(-)

-- 
2.9.4

Re: [Qemu-devel] [PATCH v10] migration: spapr: migrate pending_events of spapr state

[David Gibson]

On Mon, May 15, 2017 at 10:26:46PM -0500, Michael Roth wrote:
> Quoting Daniel Henrique Barboza (2017-05-15 08:10:52)
> > From: Jianjun Duan 
> > 
> > In racing situations between hotplug events and migration operation,
> > a rtas hotplug event could have not yet be delivered to the source
> > guest when migration is started. In this case the pending_events of
> > spapr state need be transmitted to the target so that the hotplug
> > event can be finished on the target.
> > 
> > All the different fields of the events are encoded as defined by
> > PAPR. We can migrate them as uint8_t binary stream without any
> > concerns about data padding or endianess.
> > 
> > pending_events is put in a subsection in the spapr state VMSD to make
> > sure migration across different versions is not broken.
> > 
> > Signed-off-by: Jianjun Duan 
> > Signed-off-by: Daniel Henrique Barboza 
> 
> I'd also be a little weary of treating this patch as totally standalone.
> There's pros/cons, but, without migrated DRC state, migrated hotplug
> events won't necessarilly be handled better than the current behavior of
> just dropping them.

True, but alone it should at least stop powerdown messages being lost
on migration, which is also possible AFAICT.

> 
> > ---
> >  hw/ppc/spapr.c | 33 +
> >  hw/ppc/spapr_events.c  | 24 +---
> >  include/hw/ppc/spapr.h |  3 ++-
> >  3 files changed, 48 insertions(+), 12 deletions(-)
> > 
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index 80d12d0..8cfdc71 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -1437,6 +1437,38 @@ static bool version_before_3(void *opaque, int 
> > version_id)
> >  return version_id < 3;
> >  }
> > 
> > +static bool spapr_pending_events_needed(void *opaque)
> > +{
> > +sPAPRMachineState *spapr = (sPAPRMachineState *)opaque;
> > +return !QTAILQ_EMPTY(>pending_events);
> > +}
> > +
> > +static const VMStateDescription vmstate_spapr_event_entry = {
> > +.name = "spapr_event_log_entry",
> > +.version_id = 1,
> > +.minimum_version_id = 1,
> > +.fields = (VMStateField[]) {
> > +VMSTATE_INT32(log_type, sPAPREventLogEntry),
> > +VMSTATE_BOOL(exception, sPAPREventLogEntry),
> > +VMSTATE_UINT32(data_size, sPAPREventLogEntry),
> > +VMSTATE_VARRAY_UINT32_ALLOC(data, sPAPREventLogEntry, data_size,
> > +0, vmstate_info_uint8, uint8_t),
> > +VMSTATE_END_OF_LIST()
> > +},
> > +};
> > +
> > +static const VMStateDescription vmstate_spapr_pending_events = {
> > +.name = "spapr_pending_events",
> > +.version_id = 1,
> > +.minimum_version_id = 1,
> > +.needed = spapr_pending_events_needed,
> > +.fields = (VMStateField[]) {
> > +VMSTATE_QTAILQ_V(pending_events, sPAPRMachineState, 1,
> > + vmstate_spapr_event_entry, sPAPREventLogEntry, 
> > next),
> > +VMSTATE_END_OF_LIST()
> > +},
> > +};
> > +
> >  static bool spapr_ov5_cas_needed(void *opaque)
> >  {
> >  sPAPRMachineState *spapr = opaque;
> > @@ -1535,6 +1567,7 @@ static const VMStateDescription vmstate_spapr = {
> >  .subsections = (const VMStateDescription*[]) {
> >  _spapr_ov5_cas,
> >  _spapr_patb_entry,
> > +_spapr_pending_events,
> >  NULL
> >  }
> >  };
> > diff --git a/hw/ppc/spapr_events.c b/hw/ppc/spapr_events.c
> > index f0b28d8..70c7cfc 100644
> > --- a/hw/ppc/spapr_events.c
> > +++ b/hw/ppc/spapr_events.c
> > @@ -342,7 +342,8 @@ static int rtas_event_log_to_irq(sPAPRMachineState 
> > *spapr, int log_type)
> >  return source->irq;
> >  }
> > 
> > -static void rtas_event_log_queue(int log_type, void *data, bool exception)
> > +static void rtas_event_log_queue(int log_type, void *data, bool exception,
> > + int data_size)
> >  {
> >  sPAPRMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
> >  sPAPREventLogEntry *entry = g_new(sPAPREventLogEntry, 1);
> > @@ -351,6 +352,7 @@ static void rtas_event_log_queue(int log_type, void 
> > *data, bool exception)
> >  entry->log_type = log_type;
> >  entry->exception = exception;
> >  entry->data = data;
> > +entry->data_size = data_size;
> >  QTAILQ_INSERT_TAIL(>pending_events, entry, next);
> >  }
> > 
> > @@ -445,6 +447,7 @@ static void spapr_powerdown_req(Notifier *n, void 
> > *opaque)
> >  struct rtas_event_log_v6_mainb *mainb;
> >  struct rtas_event_log_v6_epow *epow;
> >  struct epow_log_full *new_epow;
> > +uint32_t data_size;
> > 
> >  new_epow = g_malloc0(sizeof(*new_epow));
> >  hdr = _epow->hdr;
> > @@ -453,14 +456,13 @@ static void spapr_powerdown_req(Notifier *n, void 
> > *opaque)
> >  mainb = _epow->mainb;
> >  epow = _epow->epow;
> > 
> > +data_size = sizeof(*new_epow);
> >  hdr->summary = 

[Qemu-devel] [PATCH 2/3] pseries: Restore PVR negotiation logic for pre-2.9 machine types

[David Gibson]

"pseries" guests go through a hypervisor<->guest feature negotiation during
early boot.  Part of this is finding a CPU compatibility mode which works
for both.

In 152ef80 "pseries: Rewrite CAS PVR compatibility logic" this logic was
changed to strongly prefer architecture defined CPU compatibility modes,
rather than CPU "raw" modes.  However, this change was made universally,
which introduces a guest visible change for the previously existing machine
types (pseries-2.8 and earlier).  That's never supposed to happen.

This corrects the behaviour, reverting to the old PVR negotiation logic
for machine types prior to pseries-2.9.

Fixes: 152ef803ceb1959e2380a1da7736b935b109222e
Reported-by: Andrea Bolognani 
Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
---
 hw/ppc/spapr.c |  3 ++
 hw/ppc/spapr_hcall.c   | 90 +-
 include/hw/ppc/spapr.h |  1 +
 3 files changed, 93 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 35dceb0..ad8ddf2 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -3313,9 +3313,12 @@ static void 
spapr_machine_2_8_instance_options(MachineState *machine)
 
 static void spapr_machine_2_8_class_options(MachineClass *mc)
 {
+sPAPRMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
+
 spapr_machine_2_9_class_options(mc);
 SET_MACHINE_COMPAT(mc, SPAPR_COMPAT_2_8);
 mc->numa_mem_align_shift = 23;
+smc->pre_2_9_cas_pvr = true;
 }
 
 DEFINE_SPAPR_MACHINE(2_8, "2.8", false);
diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 77d2d66..a790da7 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -1044,6 +1044,89 @@ static target_ulong h_signal_sys_reset(PowerPCCPU *cpu,
 }
 }
 
+/*
+ * Old logic for PVR negotiation, used old <2.9 machine types for
+ * compatibility with old qemu versions
+ */
+#define get_compat_level(cpuver) (  \
+((cpuver) == CPU_POWERPC_LOGICAL_2_05) ? 2050 : \
+((cpuver) == CPU_POWERPC_LOGICAL_2_06) ? 2060 :  \
+((cpuver) == CPU_POWERPC_LOGICAL_2_06_PLUS) ? 2061 :\
+((cpuver) == CPU_POWERPC_LOGICAL_2_07) ? 2070 : 0)
+
+static void cas_handle_compat_cpu(PowerPCCPUClass *pcc, uint32_t pvr,
+  unsigned max_lvl, unsigned *compat_lvl,
+  unsigned *compat_pvr)
+{
+unsigned lvl = get_compat_level(pvr);
+bool is205, is206, is207;
+
+if (!lvl) {
+return;
+}
+
+/* If it is a logical PVR, try to determine the highest level */
+is205 = (pcc->pcr_supported & PCR_COMPAT_2_05) &&
+(lvl == get_compat_level(CPU_POWERPC_LOGICAL_2_05));
+is206 = (pcc->pcr_supported & PCR_COMPAT_2_06) &&
+((lvl == get_compat_level(CPU_POWERPC_LOGICAL_2_06)) ||
+ (lvl == get_compat_level(CPU_POWERPC_LOGICAL_2_06_PLUS)));
+is207 = (pcc->pcr_supported & PCR_COMPAT_2_07) &&
+(lvl == get_compat_level(CPU_POWERPC_LOGICAL_2_07));
+
+if (is205 || is206 || is207) {
+if (!max_lvl) {
+/* User did not set the level, choose the highest */
+if (*compat_lvl <= lvl) {
+*compat_lvl = lvl;
+*compat_pvr = pvr;
+}
+} else if (max_lvl >= lvl) {
+/* User chose the level, don't set higher than this */
+*compat_lvl = lvl;
+*compat_pvr = pvr;
+}
+}
+}
+
+static uint32_t cas_check_pvr_pre_2_9(PowerPCCPU *cpu, target_ulong *addr,
+  Error **errp)
+{
+PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
+int counter;
+unsigned max_lvl = get_compat_level(cpu->max_compat);
+bool cpu_match = false;
+unsigned compat_lvl = 0, compat_pvr = 0;
+
+for (counter = 0; counter < 512; ++counter) {
+uint32_t pvr, pvr_mask;
+
+pvr_mask = ldl_be_phys(_space_memory, *addr);
+pvr = ldl_be_phys(_space_memory, *addr + 4);
+*addr += 8;
+
+if (~pvr_mask & pvr) {
+break; /* Terminator record */
+}
+
+trace_spapr_cas_pvr_try(pvr);
+if (!max_lvl &&
+((cpu->env.spr[SPR_PVR] & pvr_mask) == (pvr & pvr_mask))) {
+cpu_match = true;
+compat_pvr = 0;
+} else if (pvr == cpu->compat_pvr) {
+cpu_match = true;
+compat_pvr = cpu->compat_pvr;
+} else if (!cpu_match) {
+cas_handle_compat_cpu(pcc, pvr, max_lvl, _lvl, _pvr);
+}
+}
+
+trace_spapr_cas_pvr(cpu->compat_pvr, cpu_match, compat_pvr);
+
+return compat_pvr;
+}
+
 static uint32_t cas_check_pvr(PowerPCCPU *cpu, target_ulong *addr,
   Error **errp)
 {
@@ -1096,6 +1179,7 @@ static target_ulong 
h_client_architecture_support(PowerPCCPU *cpu,
   target_ulong opcode,
   

Re: [Qemu-devel] [Qemu-ppc] [RFC 1/2] pseries: Split CAS PVR negotiation out into a separate function

[David Gibson]

On Wed, May 17, 2017 at 05:56:57PM +0200, Greg Kurz wrote:
> On Wed, 17 May 2017 16:35:46 +1000
> David Gibson  wrote:
> 
> > Guests of the qemu machine type go through a feature negotiation process
> > known as "client architecture support" (CAS) during early boot.  This does
> > a number of things, one of which is finding a CPU compatibility mode which
> > can be supported by both guest and host.
> > 
> > In fact the CPU negotiation is probably the single most complex part of the
> > CAS process, so this splits it out into a helper function.  We've recently
> > made some mistakes in maintaining backward compatibility for old machine
> > types here.  Splitting this out will also make it easier to fix this.
> > 
> > This also adds a possibly useful error message if the negotiation fails
> > (i.e. if there is CPU mode that's suitable for both guest and host).
> 
> s/if there is/if there isn't a/ ?

Oops, I'll correct that.

> 
> > 
> > Signed-off-by: David Gibson 
> > ---
> >  hw/ppc/spapr_hcall.c | 43 +++
> >  1 file changed, 27 insertions(+), 16 deletions(-)
> > 
> > diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> > index 0d608d6..007ae8d 100644
> > --- a/hw/ppc/spapr_hcall.c
> > +++ b/hw/ppc/spapr_hcall.c
> > @@ -1047,19 +1047,13 @@ static target_ulong h_signal_sys_reset(PowerPCCPU 
> > *cpu,
> >  }
> >  }
> >  
> > -static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
> > -  sPAPRMachineState *spapr,
> > -  target_ulong opcode,
> > -  target_ulong *args)
> > +static uint32_t cas_check_pvr(PowerPCCPU *cpu, target_ulong list,
> > +  Error **errp)
> >  {
> > -target_ulong list = ppc64_phys_to_real(args[0]);
> > -target_ulong ov_table;
> >  bool explicit_match = false; /* Matched the CPU's real PVR */
> >  uint32_t max_compat = cpu->max_compat;
> >  uint32_t best_compat = 0;
> >  int i;
> > -sPAPROptionVector *ov1_guest, *ov5_guest, *ov5_cas_old, *ov5_updates;
> > -bool guest_radix;
> >  
> >  /*
> >   * We scan the supplied table of PVRs looking for two things
> > @@ -1090,26 +1084,43 @@ static target_ulong 
> > h_client_architecture_support(PowerPCCPU *cpu,
> >  /* We couldn't find a suitable compatibility mode, and either
> >   * the guest doesn't support "raw" mode for this CPU, or raw
> >   * mode is disabled because a maximum compat mode is set */
> > -return H_HARDWARE;
> > +error_setg(errp, "Couldn't negotiate a suitable PVR during CAS");
> > +return 0;
> >  }
> >  
> >  /* Parsing finished */
> >  trace_spapr_cas_pvr(cpu->compat_pvr, explicit_match, best_compat);
> >  
> > -/* Update CPUs */
> > -if (cpu->compat_pvr != best_compat) {
> > -Error *local_err = NULL;
> > +return best_compat;
> > +}
> > +
> > +static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
> > +  sPAPRMachineState *spapr,
> > +  target_ulong opcode,
> > +  target_ulong *args)
> > +{
> > +/* @ov_table points to the first option vector */
> > +target_ulong ov_table = ppc64_phys_to_real(args[0]);
> > +uint32_t cas_pvr;
> > +sPAPROptionVector *ov1_guest, *ov5_guest, *ov5_cas_old, *ov5_updates;
> > +bool guest_radix;
> > +Error *local_err = NULL;
> >  
> > -ppc_set_compat_all(best_compat, _err);
> > +cas_pvr = cas_check_pvr(cpu, ov_table, _err);
> 
> Shouldn't cas_check_pvr() take a target_ulong * so that we can get
> the address of the first option vector...
> 
> > +if (local_err) {
> > +error_report_err(local_err);
> > +return H_HARDWARE;
> > +}
> > +
> > +/* Update CPUs */
> > +if (cpu->compat_pvr != cas_pvr) {
> > +ppc_set_compat_all(cas_pvr, _err);
> >  if (local_err) {
> >  error_report_err(local_err);
> >  return H_HARDWARE;
> >  }
> >  }
> >  
> > -/* For the future use: here @ov_table points to the first option 
> > vector */
> > -ov_table = list;
> > -
> 
> ... and address Laurent's comment ?

Yes, I completely misread what was happening with the pvr_list vs. the
option vectors.  I'll correct that.

> 
> >  ov1_guest = spapr_ovec_parse_vector(ov_table, 1);
> >  ov5_guest = spapr_ovec_parse_vector(ov_table, 5);
> >  if (spapr_ovec_test(ov5_guest, OV5_MMU_BOTH)) {
> 



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


signature.asc

Re: [Qemu-devel] [RFC 0/2] pseries: Correct behaviour change for older machine types

[David Gibson]

On Wed, May 17, 2017 at 10:52:05AM +0200, Andrea Bolognani wrote:
> On Wed, 2017-05-17 at 16:35 +1000, David Gibson wrote:
> > 152ef80 "pseries: Rewrite CAS PVR compatibility logic" incorrectly
> > introduced a guest-visible behaviour change into existing versioned
> > machine type.  Patch 2/2 corrects this change, while 1/2 is a
> > preliminary clean up to make that easier.
> > 
> > Unfortunately, this bug is already in the released qemu-2.9.0.  Once
> > this is ready to merge for master, I'll make a backport to apply for
> > 2.9.1 as well.
> > 
> > David Gibson (2):
> >   pseries: Split CAS PVR negotiation out into a separate function
> >   pseries: Restore PVR negotiation logic for pre-2.9 machine types
> > 
> >  hw/ppc/spapr.c |   3 ++
> >  hw/ppc/spapr_hcall.c   | 131 
> >+++--
> >  include/hw/ppc/spapr.h |   1 +
> >  3 files changed, 119 insertions(+), 16 deletions(-)
> 
> I gave it a spin and I can no longer reproduce the issue,
> so for the entire series:
> 
> Tested-by: Andrea Bolognani 

I'm actually kind of astonished it worked at all given the bug that
Laurent pointed out.

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [Qemu-ppc] [PATCH v10] migration: spapr: migrate pending_events of spapr state

[David Gibson]

On Wed, May 17, 2017 at 05:31:44PM -0300, Daniel Henrique Barboza wrote:
> 
> 
> On 05/16/2017 09:04 AM, Daniel Henrique Barboza wrote:
> > 
> > 
> > On 05/16/2017 01:25 AM, David Gibson wrote:
> > > On Mon, May 15, 2017 at 10:10:52AM -0300, Daniel Henrique Barboza wrote:
> > > > From: Jianjun Duan 
> > > > 
> > > > In racing situations between hotplug events and migration operation,
> > > > a rtas hotplug event could have not yet be delivered to the source
> > > > guest when migration is started. In this case the pending_events of
> > > > spapr state need be transmitted to the target so that the hotplug
> > > > event can be finished on the target.
> > > > 
> > > > All the different fields of the events are encoded as defined by
> > > > PAPR. We can migrate them as uint8_t binary stream without any
> > > > concerns about data padding or endianess.
> > > > 
> > > > pending_events is put in a subsection in the spapr state VMSD to make
> > > > sure migration across different versions is not broken.
> > > > 
> > > > Signed-off-by: Jianjun Duan 
> > > > Signed-off-by: Daniel Henrique Barboza 
> > > Ok, thanks for splitting this out, but you don't seem to have
> > > addressed the other comments I had on this patch as presented before.
> > 
> > Sorry, I haven't noticed you had previous comments on this patch. I'll
> > address
> > them and re-send.
> > 
> > 
> > Daniel
> > 
> > > 
> > > > ---
> > > >   hw/ppc/spapr.c | 33 +
> > > >   hw/ppc/spapr_events.c  | 24 +---
> > > >   include/hw/ppc/spapr.h |  3 ++-
> > > >   3 files changed, 48 insertions(+), 12 deletions(-)
> > > > 
> > > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > > > index 80d12d0..8cfdc71 100644
> > > > --- a/hw/ppc/spapr.c
> > > > +++ b/hw/ppc/spapr.c
> > > > @@ -1437,6 +1437,38 @@ static bool version_before_3(void
> > > > *opaque, int version_id)
> > > >   return version_id < 3;
> > > >   }
> > > >   +static bool spapr_pending_events_needed(void *opaque)
> > > > +{
> > > > +sPAPRMachineState *spapr = (sPAPRMachineState *)opaque;
> > > > +return !QTAILQ_EMPTY(>pending_events);
> > > > +}
> > > > +
> > > > +static const VMStateDescription vmstate_spapr_event_entry = {
> > > > +.name = "spapr_event_log_entry",
> > > > +.version_id = 1,
> > > > +.minimum_version_id = 1,
> > > > +.fields = (VMStateField[]) {
> > > > +VMSTATE_INT32(log_type, sPAPREventLogEntry),
> > > > +VMSTATE_BOOL(exception, sPAPREventLogEntry),
> > > I'd like some more information to convince me there isn't redundant
> > > data here.
> I'll quote David's v9 review here for reference:
> 
> "So, at the moment, AFAICT every event is marked as exception == true,
> so this doesn't actually tell us anything.   If that becomes not the
> case in future, can the exception flag be derived from the log_type or
> information in the even buffer? "
> 
> I've checked the code and we're just using exception == true.  The two
> event logs that we currently support are RTAS_LOG_TYPE_EPOW and
> RTAS_LOG_TYPE_HOTPLUG, both are being added in the queue by
> calling rtas_event_log_queue() with exception == true.
> 
> This boolean is passed as a parameter in the functions
> rtas_event_log_contains
> and rtas_event_log_dequeue. The former is called once with exception=true
> inside check_exception, the latter is called once with exception=true in
> check_exception
> and exception=false in event_scan.
> 
> I didn't find anywhere in the code where, once set as true, we change this
> boolean
> to false. So in my opinion we can discard this boolean from the migration
> and,
> in post_load, set it to true if log_type is RTAS_LOG_TYPE_EPOW or
> RTAS_LOG_TYPE_HOTPLUG. This would mean that when we implement more event
> log types we will need to also change the post_load to reflect the
> change.

This actually suggests we should just remove the exception flag as a
preliminary cleanup.

> 
> 
> 
> PS: I've read the LoPAPR document [1] and it says in section 10.2.3 page
> 289:
> 
> "Hot Plug Events, when implemented, are reported through the event-scan RTAS
> call."
> 
> Why are we setting the RTAS_LOG_TYPE_HOTPLUG as exception==true and
> therefore
> reporting it in check_exception instead? Does the sPAPR spec differ from the
> LoPAPR
> in this regard?
> 
> [1] 
> https://openpowerfoundation.org/wp-content/uploads/2016/05/LoPAPR_DRAFT_v11_24March2016_cmt1.pdf
> 
> 
> Thanks,
> 
> Daniel
> 
> > > > +VMSTATE_UINT32(data_size, sPAPREventLogEntry),
> > > > +VMSTATE_VARRAY_UINT32_ALLOC(data, sPAPREventLogEntry,
> > > > data_size,
> > > > +0, vmstate_info_uint8, uint8_t),
> > > And I think this should be VBUFFER rather than VARRAY to avoid the
> > > data type change.
> > > 
> > > > +VMSTATE_END_OF_LIST()
> > > > +},
> > > > +};
> > > > +
> > > > +static const 

Re: [Qemu-devel] (no subject)

[no-reply]

Hi,

This series seems to have some coding style problems. See output below for
more information:

Subject: [Qemu-devel] (no subject)
Type: series
Message-id: 536fb79a-5753-4143-a5a6-7a189ef5137e@ONE.local

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
32d5d78 (no subject)

=== OUTPUT BEGIN ===
Checking PATCH 1/1: (no subject)...
ERROR: space prohibited before that '++' (ctx:WxB)
#34: FILE: hw/gpio/bcm2835_gpio.c:58:
+for (i = 0; i < 10; i ++) {
   ^

ERROR: space prohibited between function name and open parenthesis '('
#37: FILE: hw/gpio/bcm2835_gpio.c:60:
+if (index < sizeof (s->fsel)) {

ERROR: space prohibited before that '++' (ctx:WxB)
#46: FILE: hw/gpio/bcm2835_gpio.c:70:
+for (i = 0; i < 10; i ++) {
   ^

ERROR: space prohibited between function name and open parenthesis '('
#49: FILE: hw/gpio/bcm2835_gpio.c:72:
+if (index < sizeof (s->fsel)) {

ERROR: space prohibited after that '~' (ctx:WxW)
#100: FILE: hw/gpio/bcm2835_gpio.c:115:
+uint32_t changes = val & ~ *lev;
  ^

ERROR: space prohibited before that '++' (ctx:WxB)
#105: FILE: hw/gpio/bcm2835_gpio.c:119:
+for (i = 0; i < count; i ++) {
  ^

ERROR: space prohibited before that '++' (ctx:WxB)
#121: FILE: hw/gpio/bcm2835_gpio.c:136:
+for (i = 0; i < count; i ++) {
  ^

ERROR: space prohibited after that '~' (ctx:WxW)
#129: FILE: hw/gpio/bcm2835_gpio.c:143:
+*lev &= ~ val;
 ^

ERROR: switch and case should be at the same indent
#141: FILE: hw/gpio/bcm2835_gpio.c:152:
 switch (offset) {
+case GPFSEL0:
+case GPFSEL1:
+case GPFSEL2:
+case GPFSEL3:
+case GPFSEL4:
+case GPFSEL5:
[...]
+case GPSET0:
+case GPSET1:
[...]
+case GPCLR0:
+case GPCLR1:
[...]
+case GPLEV0:
[...]
+case GPLEV1:
[...]
+case GPEDS0:
+case GPEDS1:
+case GPREN0:
+case GPREN1:
+case GPFEN0:
+case GPFEN1:
+case GPHEN0:
+case GPHEN1:
+case GPLEN0:
+case GPLEN1:
+case GPAREN0:
+case GPAREN1:
+case GPAFEN0:
+case GPAFEN1:
+case GPPUD:
+case GPPUDCLK0:
+case GPPUDCLK1:
[...]
+default:

ERROR: space prohibited after that '-' (ctx:WxW)
#200: FILE: hw/gpio/bcm2835_gpio.c:169:
+if (s->panel.socket != - 1) {
^

ERROR: space prohibited after that '-' (ctx:WxW)
#208: FILE: hw/gpio/bcm2835_gpio.c:177:
+if (s->panel.socket != - 1) {
^

ERROR: switch and case should be at the same indent
#252: FILE: hw/gpio/bcm2835_gpio.c:219:
 switch (offset) {
+case GPFSEL0:
+case GPFSEL1:
+case GPFSEL2:
+case GPFSEL3:
+case GPFSEL4:
+case GPFSEL5:
[...]
+case GPSET0:
[...]
+case GPSET1:
[...]
+case GPCLR0:
[...]
+case GPCLR1:
[...]
+case GPLEV0:
+case GPLEV1:
[...]
+case GPEDS0:
+case GPEDS1:
+case GPREN0:
+case GPREN1:
+case GPFEN0:
+case GPFEN1:
+case GPHEN0:
+case GPHEN1:
+case GPLEN0:
+case GPLEN1:
+case GPAREN0:
+case GPAREN1:
+case GPAFEN0:
+case GPAFEN1:
+case GPPUD:
+case GPPUDCLK0:
+case GPPUDCLK1:
[...]
+default:

ERROR: space prohibited after that '-' (ctx:WxW)
#308: FILE: hw/gpio/bcm2835_gpio.c:230:
+if (s->panel.socket != - 1) {
^

WARNING: line over 80 characters
#310: FILE: hw/gpio/bcm2835_gpio.c:232:
+senddatatopanel(>panel, Data, true); //John Bradley dummy 
GPIO Panel

ERROR: do not use C99 // comments
#310: FILE: hw/gpio/bcm2835_gpio.c:232:
+senddatatopanel(>panel, Data, true); //John Bradley dummy 
GPIO Panel

ERROR: space prohibited after that '-' (ctx:WxW)
#315: FILE: hw/gpio/bcm2835_gpio.c:237:
+if (s->panel.socket != - 1) {
^

WARNING: line over 80 characters
#318: FILE: hw/gpio/bcm2835_gpio.c:240:
+senddatatopanel(>panel, Data, true); //John Bradley dummy 
GPIO Panel

ERROR: do not use C99 // comments
#318: FILE: hw/gpio/bcm2835_gpio.c:240:
+

Re: [Qemu-devel] (no subject)

[no-reply]

Hi,

This series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.

Subject: [Qemu-devel] (no subject)
Type: series
Message-id: 536fb79a-5753-4143-a5a6-7a189ef5137e@ONE.local

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=8
time make docker-test-quick@centos6
time make docker-test-mingw@fedora
time make docker-test-build@min-glib
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] patchew/536fb79a-5753-4143-a5a6-7a189ef5137e@ONE.local -> 
patchew/536fb79a-5753-4143-a5a6-7a189ef5137e@ONE.local
Switched to a new branch 'test'
32d5d78 (no subject)

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into '/var/tmp/patchew-tester-tmp-1zdsj2xe/src/dtc'...
Submodule path 'dtc': checked out '558cd81bdd432769b59bff01240c44f82cfb1a9d'
  BUILD   centos6
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-1zdsj2xe/src'
  ARCHIVE qemu.tgz
  ARCHIVE dtc.tgz
  COPYRUNNER
RUN test-quick in qemu:centos6 
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
ccache-3.1.6-2.el6.x86_64
epel-release-6-8.noarch
gcc-4.4.7-17.el6.x86_64
git-1.7.1-4.el6_7.1.x86_64
glib2-devel-2.28.8-5.el6.x86_64
libfdt-devel-1.4.0-1.el6.x86_64
make-3.81-23.el6.x86_64
package g++ is not installed
pixman-devel-0.32.8-1.el6.x86_64
tar-1.23-15.el6_8.x86_64
zlib-devel-1.2.3-29.el6.x86_64

Environment variables:
PACKAGES=libfdt-devel ccache tar git make gcc g++ zlib-devel 
glib2-devel SDL-devel pixman-devel epel-release
HOSTNAME=d9b60ec0a426
TERM=xterm
MAKEFLAGS= -j8
HISTSIZE=1000
J=8
USER=root
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
MAIL=/var/spool/mail/root
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LANG=en_US.UTF-8
TARGET_LIST=
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
TEST_DIR=/tmp/qemu-test
LOGNAME=root
LESSOPEN=||/usr/bin/lesspipe.sh %s
FEATURES= dtc
DEBUG=
G_BROKEN_FILENAMES=1
CCACHE_HASHDIR=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/var/tmp/qemu-build/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/var/tmp/qemu-build/install
BIOS directory/var/tmp/qemu-build/install/share/qemu
binary directory  /var/tmp/qemu-build/install/bin
library directory /var/tmp/qemu-build/install/lib
module directory  /var/tmp/qemu-build/install/lib/qemu
libexec directory /var/tmp/qemu-build/install/libexec
include directory /var/tmp/qemu-build/install/include
config directory  /var/tmp/qemu-build/install/etc
local state directory   /var/tmp/qemu-build/install/var
Manual directory  /var/tmp/qemu-build/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /tmp/qemu-test/src
C compilercc
Host C compiler   cc
C++ compiler  
Objective-C compiler cc
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
QEMU_CFLAGS   -I/usr/include/pixman-1   -I$(SRC_PATH)/dtc/libfdt -pthread 
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -fPIE -DPIE -m64 -mcx16 
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels 
-Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security 
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration 
-Wold-style-definition -Wtype-limits -fstack-protector-all
LDFLAGS   -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g 
make  make
install   install
pythonpython -B
smbd  /usr/sbin/smbd
module supportno
host CPU  x86_64
host big endian   no
target list   x86_64-softmmu aarch64-softmmu
tcg debug enabled no
gprof enabled no
sparse enabledno
strip binariesyes
profiler  no
static build  no
pixmansystem
SDL support   yes (1.2.14)
GTK support   no 
GTK GL supportno
VTE support   no 
TLS priority  NORMAL
GNUTLS supportno
GNUTLS rndno
libgcrypt no
libgcrypt kdf no
nettleno 
nettle kdfno
libtasn1  no
curses supportno
virgl support no
curl support  no
mingw32 support   no
Audio drivers oss
Block whitelist (rw) 
Block whitelist (ro) 
VirtFS supportno
VNC support   yes
VNC SASL support  no
VNC JPEG support  no
VNC PNG support   no
xen support   no
brlapi supportno
bluez  supportno
Documentation no
PIE   yes
vde support   no
netmap supportno
Linux AIO support no
ATTR/XATTR support yes
Install blobs yes
KVM support   yes

[Qemu-devel] (no subject)

[John Bradley]

>From 836daaff38940535548043f2e8f2e3df7a62d473 Mon Sep 17 00:00:00 2001
From: John Bradley 
Date: Wed, 17 May 2017 18:57:21 +0100
Subject: [PATCH] [PATCH] Add code to connect with
 https://github.com/flypie/GDummyPanel The code uses GNU Sockets & Windows
 sockets as on MINGW GNU no available. This is inteded as a Demo for RFC.

Signed-off-by: John Bradley 
---
 hw/gpio/bcm2835_gpio.c | 330 +++--
 include/hw/gpio/bcm2835_gpio.h |   5 +
 include/qemu/PanelEmu.h|  54 +++
 util/Makefile.objs |   1 +
 util/PanelEmu.c| 329 
 5 files changed, 577 insertions(+), 142 deletions(-)
 create mode 100644 include/qemu/PanelEmu.h
 create mode 100644 util/PanelEmu.c

diff --git a/hw/gpio/bcm2835_gpio.c b/hw/gpio/bcm2835_gpio.c
index acc2e3cf9e..14bd059861 100644
--- a/hw/gpio/bcm2835_gpio.c
+++ b/hw/gpio/bcm2835_gpio.c
@@ -19,6 +19,8 @@
 #include "hw/sd/sd.h"
 #include "hw/gpio/bcm2835_gpio.h"
 
+
+
 #define GPFSEL0   0x00
 #define GPFSEL1   0x04
 #define GPFSEL2   0x08
@@ -53,9 +55,9 @@ static uint32_t gpfsel_get(BCM2835GpioState *s, uint8_t reg)
 {
 int i;
 uint32_t value = 0;
-for (i = 0; i < 10; i++) {
+for (i = 0; i < 10; i ++) {
 uint32_t index = 10 * reg + i;
-if (index < sizeof(s->fsel)) {
+if (index < sizeof (s->fsel)) {
 value |= (s->fsel[index] & 0x7) << (3 * i);
 }
 }
@@ -65,9 +67,9 @@ static uint32_t gpfsel_get(BCM2835GpioState *s, uint8_t reg)
 static void gpfsel_set(BCM2835GpioState *s, uint8_t reg, uint32_t value)
 {
 int i;
-for (i = 0; i < 10; i++) {
+for (i = 0; i < 10; i ++) {
 uint32_t index = 10 * reg + i;
-if (index < sizeof(s->fsel)) {
+if (index < sizeof (s->fsel)) {
 int fsel = (value >> (3 * i)) & 0x7;
 s->fsel[index] = fsel;
 }
@@ -75,24 +77,24 @@ static void gpfsel_set(BCM2835GpioState *s, uint8_t reg, 
uint32_t value)
 
 /* SD controller selection (48-53) */
 if (s->sd_fsel != 0
-&& (s->fsel[48] == 0) /* SD_CLK_R */
-&& (s->fsel[49] == 0) /* SD_CMD_R */
-&& (s->fsel[50] == 0) /* SD_DATA0_R */
-&& (s->fsel[51] == 0) /* SD_DATA1_R */
-&& (s->fsel[52] == 0) /* SD_DATA2_R */
-&& (s->fsel[53] == 0) /* SD_DATA3_R */
-) {
+&& (s->fsel[48] == 0) /* SD_CLK_R */
+&& (s->fsel[49] == 0) /* SD_CMD_R */
+&& (s->fsel[50] == 0) /* SD_DATA0_R */
+&& (s->fsel[51] == 0) /* SD_DATA1_R */
+&& (s->fsel[52] == 0) /* SD_DATA2_R */
+&& (s->fsel[53] == 0) /* SD_DATA3_R */
+) {
 /* SDHCI controller selected */
 sdbus_reparent_card(s->sdbus_sdhost, s->sdbus_sdhci);
 s->sd_fsel = 0;
 } else if (s->sd_fsel != 4
-&& (s->fsel[48] == 4) /* SD_CLK_R */
-&& (s->fsel[49] == 4) /* SD_CMD_R */
-&& (s->fsel[50] == 4) /* SD_DATA0_R */
-&& (s->fsel[51] == 4) /* SD_DATA1_R */
-&& (s->fsel[52] == 4) /* SD_DATA2_R */
-&& (s->fsel[53] == 4) /* SD_DATA3_R */
-) {
+   && (s->fsel[48] == 4) /* SD_CLK_R */
+   && (s->fsel[49] == 4) /* SD_CMD_R */
+   && (s->fsel[50] == 4) /* SD_DATA0_R */
+   && (s->fsel[51] == 4) /* SD_DATA1_R */
+   && (s->fsel[52] == 4) /* SD_DATA2_R */
+   && (s->fsel[53] == 4) /* SD_DATA3_R */
+   ) {
 /* SDHost controller selected */
 sdbus_reparent_card(s->sdbus_sdhci, s->sdbus_sdhost);
 s->sd_fsel = 4;
@@ -108,13 +110,13 @@ static int gpfsel_is_out(BCM2835GpioState *s, int index)
 }
 
 static void gpset(BCM2835GpioState *s,
-uint32_t val, uint8_t start, uint8_t count, uint32_t *lev)
+  uint32_t val, uint8_t start, uint8_t count, uint32_t *lev)
 {
-uint32_t changes = val & ~*lev;
+uint32_t changes = val & ~ *lev;
 uint32_t cur = 1;
 
 int i;
-for (i = 0; i < count; i++) {
+for (i = 0; i < count; i ++) {
 if ((changes & cur) && (gpfsel_is_out(s, start + i))) {
 qemu_set_irq(s->out[start + i], 1);
 }
@@ -125,132 +127,165 @@ static void gpset(BCM2835GpioState *s,
 }
 
 static void gpclr(BCM2835GpioState *s,
-uint32_t val, uint8_t start, uint8_t count, uint32_t *lev)
+  uint32_t val, uint8_t start, uint8_t count, uint32_t *lev)
 {
 uint32_t changes = val & *lev;
 uint32_t cur = 1;
 
 int i;
-for (i = 0; i < count; i++) {
+for (i = 0; i < count; i ++) {
 if ((changes & cur) && (gpfsel_is_out(s, start + i))) {
 qemu_set_irq(s->out[start + i], 0);
 }
 cur <<= 1;
 }
 
-*lev &= ~val;
+*lev &= ~ val;
 }
 
-static uint64_t bcm2835_gpio_read(void *opaque, hwaddr offset,
-unsigned size)
+static 

Re: [Qemu-devel] [RFC PATCH v1 6/6] spapr: Fix migration of Radix guests

[Bharata B Rao]

On Wed, May 17, 2017 at 05:20:31PM +1000, David Gibson wrote:
> On Wed, May 17, 2017 at 12:45:39PM +0530, Bharata B Rao wrote:
> > On Wed, May 17, 2017 at 05:00:49PM +1000, David Gibson wrote:
> > > On Wed, May 17, 2017 at 09:19:22AM +0530, Bharata B Rao wrote:
> > > > Fix migration of radix guests by ensuring that we issue
> > > > KVM_PPC_CONFIGURE_V3_MMU for radix case post migration.
> > > > 
> > > > Reported-by: Nageswara R Sastry 
> > > > Signed-off-by: Bharata B Rao 
> > > > ---
> > > >  hw/ppc/spapr.c | 15 +++
> > > >  hw/ppc/spapr_hcall.c   |  1 +
> > > >  include/hw/ppc/spapr.h |  1 +
> > > >  3 files changed, 17 insertions(+)
> > > > 
> > > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > > > index 05abfc1..dd1d687 100644
> > > > --- a/hw/ppc/spapr.c
> > > > +++ b/hw/ppc/spapr.c
> > > > @@ -1443,6 +1443,20 @@ static int spapr_post_load(void *opaque, int 
> > > > version_id)
> > > >  err = spapr_rtc_import_offset(>rtc, spapr->rtc_offset);
> > > >  }
> > > >  
> > > > +if (spapr->patb_entry) {
> > > > +if (kvmppc_has_cap_mmu_radix() && kvm_enabled()) {
> > > > +err = kvmppc_configure_v3_mmu(POWERPC_CPU(first_cpu),
> > > > +  spapr->patb_flags &
> > > > +  SPAPR_PROC_TABLE_RADIX,
> > > > +  spapr->patb_flags &
> > > > +  SPAPR_PROC_TABLE_GTSE,
> > > 
> > > You should be able to work out the things you need here from
> > > patb_entry without adding the new patb_flags field.
> > 
> > kvmppc_configure_v3_mmu() needs two bools: radix and gtse. The radix
> > bit can be implied from patb_entry, I needed patb_flags to get the
> > gtse value. Not immediately obvious of how to get gtse bit from patb_entry,
> > but let me take a relook.
> 
> Oh, sorry, you can't get GTSE from the patb_entry, but you can get it
> from the LPCR.

So I need to get GTSE from LPCR at the target after the LPCR has been updated
from the incoming stream (via vmstate_ppc_cpu vmsd). However we are also
in the middle of processing the incoming stream here (via spapr_post_load).
Can we be sure that spapr_post_load() processing happens after all
SPRs (and hence LPCR) have been updated via vmstate_ppc_cpu vmsd handlers ?

Also, in addition to issuing KVM_PPC_CONFIGURE_V3_MMU, should we be
walking all the CPUs and setting the LPCR_UPRT and LPCR_GTSE bits like how
H_REGISTER_PROC_TBL does ?

Regards,
Bharata.

Re: [Qemu-devel] [virtio-dev] Re: [PATCH v2 00/16] Vhost-pci for inter-VM communication

[Wei Wang]

On 05/17/2017 02:22 PM, Jason Wang wrote:



On 2017年05月17日 14:16, Jason Wang wrote:



On 2017年05月16日 15:12, Wei Wang wrote:




Hi:

Care to post the driver codes too?

OK. It may take some time to clean up the driver code before post it 
out. You can first

have a check of the draft at the repo here:
https://github.com/wei-w-wang/vhost-pci-driver

Best,
Wei


Interesting, looks like there's one copy on tx side. We used to have 
zerocopy support for tun for VM2VM traffic. Could you please try to 
compare it with your vhost-pci-net by:


We can analyze from the whole data path - from VM1's network stack to 
send packets -> VM2's
network stack to receive packets. The number of copies are actually the 
same for both.


vhost-pci: 1-copy happen in VM1's driver xmit(), which copes packets 
from its network stack to VM2's
RX ring buffer. (we call it "zerocopy" because there is no intermediate 
copy between VMs)
zerocopy enabled vhost-net: 1-copy happen in tun's recvmsg, which copies 
packets from VM1's TX ring

buffer to VM2's RX ring buffer.

That being said, we compared to vhost-user, instead of vhost_net, 
because vhost-user is the one

that is used in NFV, which we think is a major use case for vhost-pci.



- make sure zerocopy is enabled for vhost_net
- comment skb_orphan_frags() in tun_net_xmit()

Thanks



You can even enable tx batching for tun by ethtool -C tap0 rx-frames 
N. This will greatly improve the performance according to my test.




Thanks, but would this hurt latency?

Best,
Wei

Re: [Qemu-devel] [Bug 1691379] [NEW] NetBSD evbmips64el port installation doesn't work with qemu-system-mips64el.

[Kamil Rytarowski]

On 17.05.2017 19:58, Kamil Rytarowski wrote:
> On 17.05.2017 10:10, Thomas Huth wrote:
>> On 17.05.2017 09:52, Utkarsh Anand wrote:
>>> Public bug reported:
>>>
>>> I successfully installed the NetBSD evbmips64el port on gxemul but was
>>> unable to install it on qemu. Trying to boot it on qemu takes me to the
>>> 'db>' prompt. Here's the output and backtrace:
>>>
>>> panic: pcib_isa_intr_string: bogus isa irq 0x0
>>> kernel: breakpoint trap
>>> Stopped in pid 0.1 (system) at  netbsd:cpu_Debugger+0x4:jr  ra
>>> bdslot: nop
>>> db> bt
>>> 0x805977f0: cpu_Debugger+4 
>>> (63061,9000180003f8,6,804c2290) ra 8030acd0 sz 0
>>> 0x805977f0: vpanic+158 (63061,9000180003f8,6,804c2290) 
>>> ra 8030ad7c sz 64
>>> 0x80597830: panic+34 (63061,803d65b0,0,40) ra 
>>> 80109784 sz 96
>>> 0x80597890: pcib_isa_intr_string+6c (63061,803d65b0,0,40) 
>>> ra 80149bfc sz 16
>>> 0x805978a0: uhci_pci_attach+16c (63061,803d65b0,0,40) ra 
>>> 802f0400 sz 176
>>> 0x80597950: config_attach_loc+1c8 (63061,803d65b0,0,40) ra 
>>> 802f053c sz 64
>>> 0x80597990: config_found_sm_loc+5c (63061,803d65b0,0,40) ra 
>>> 80121354 sz 64
>>> 0x805979d0: pci_probe_device+524 (63061,803d65b0,0,0) ra 
>>> 80121548 sz 288
>>> 0x80597af0: pci_enumerate_bus+1d0 (63061,803d65b0,0,0) ra 
>>> 8012167c sz 160
>>> 0x80597b90: pcirescan+5c (63061,803d65b0,0,0) ra 
>>> 801218c4 sz 32
>>> 0x80597bb0: pciattach+19c (63061,803d65b0,0,0) ra 
>>> 802f0400 sz 80
>>> 0x80597c00: config_attach_loc+1c8 (63061,803d65b0,0,0) ra 
>>> 802f053c sz 64
>>> 0x80597c40: config_found_sm_loc+5c (63061,803d65b0,0,0) ra 
>>> 80108934 sz 64
>>> 0x80597c80: gt_attach+7c (63061,803d65b0,0,0) ra 
>>> 802f0400 sz 112   
>>> 0x80597cf0: config_attach_loc+1c8 (63061,803d65b0,0,0) ra 
>>> 802f053c sz 64
>>> 0x80597d30: config_found_sm_loc+5c (63061,803d65b0,0,0) ra 
>>> 801086ac sz 64
>>> 0x80597d70: mainbus_attach+dc (63061,803d65b0,0,0) ra 
>>> 802f0400 sz 96
>>> 0x80597dd0: config_attach_loc+1c8 (63061,803d65b0,0,0) ra 
>>> 80104bf8 sz 64
>>> 0x80597e10: cpu_configure+28 (63061,803d65b0,0,0) ra 
>>> 803d5f30 sz 16
>>> 0x80597e20: main+3a0 (63061,803d65b0,0,0) ra 
>>> 801000dc sz 128   
>>> 0x80597ea0: kernel_text+dc (63061,803d65b0,0,0) ra 0 sz 0
>>> User-level: pid 0.1
>>>
>>> Here's the command that I used:
>>>
>>> Build evbmips64el from source and then launch it from qemu (replace the
>>> paths relative to your system):
>>>
>>> qemu-system-mips64el -cdrom
>>> /extra/evbmips64/distrib/evbmips/cdroms/installcd/NetBSD-7.99.71
>>> -evbmips-mips64el.iso -hda /extra/evbmips64.img -kernel
>>> /extra/evbmips64/releasedir/evbmips/installation/netbsd-INSTALL_MALTA64
>>> -nographic -M malta
>>>
>>> (I've decompressed the kernel)
>>>
>>> Here's the output for qemu-system-mips64el --version :
>>>
>>> QEMU emulator version 2.7.1(qemu-2.7.1-6.fc25), Copyright (c) 2003-2016
>>> Fabrice Bellard and the QEMU Project developers
>>>
>>> This doesn't look like a NetBSD bug. I've attached a screenshot of the
>>> working installation using gxemul in the attachments.
>>
>> When reporting such issues, please always use the latest release of QEMU
>> first, so could you please try again with the latest upstream release of
>> QEMU (currently v2.9.0)? Thanks!
>>
>>  Thomas
>>
> 
> 7.99.71 is the most recent kernel ABI version (NetBSD-current).
> 
> Release engineering builds of NetBSD-current are hosted on nyftp.netbsd.org.
> 
> kernel:
> 
> http://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201705170540Z/evbmips-mips64el/installation/
> 
> installation medium:
> 
> http://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201705170540Z/images/
> 
> [In future there will be need to switch 201705170540Z to a newer
> snapshot, as this one will be removed.]
> 
> I will have to a look tonight and try to reproduce locally (and take
> MIPS 64-bit crash course).
> 

I've reproduced it locally with qemu/NetBSD-7.99.71 ver. 2.9 git HEAD
(rev. cdece0467c7cf8e3).

464 const char *
465 pcib_isa_intr_string(void *v, int irq, char *buf, size_t len)
466 {
467 if (irq == 0 || irq >= ICU_LEN || irq == 2)
468 panic("%s: bogus isa irq 0x%x", __func__, irq);
469
470 snprintf(buf, len, "isa irq %d", irq);
471 return buf;
472 }

Generates: "panic: pcib_isa_intr_string: bogus isa irq 0x0".

https://nxr.netbsd.org/xref/src/sys/arch/evbmips/malta/pci/pcib.c?r=1.18#464

I will try to see if it ever worked (older NetBSD kernel / older qemu)
and if so, 

Re: [Qemu-devel] [PATCH v3 0/5] mc146818rtc: fix Windows VM clock faster

[Xiao Guangrong]

On 05/10/2017 05:53 PM, Paolo Bonzini wrote:



On 10/05/2017 10:32, guangrong.x...@gmail.com wrote:

From: Xiao Guangrong 

Changelog in v3:
Thanks to Paolo's the elaborate review comments, this version
simplifies the logic of periodic_timer_update() significantly
that includes:
1) introduce rtc_periodic_clock_ticks() that takes both regA and
regB into account and returns the period clock
2) count the clocks since last interrupt by always using current
clock subtracts the clock when last interrupt happened
3) improve the assert() logic

Paolo, all you comments have been reflected in this version except
globally using s->period because in the current code, only x86 is
using s->period so that we should obey this rule to keep compatible
migration. I have added the comment to explain this suitable in the
code:

 /*
  * as the old QEMUs only used s->period for the case that
  * LOST_TICK_POLICY_SLEW is used, in order to keep the
  * compatible migration, we obey the rule as old QEMUs.
  */
 s->period = period;
If anything i missed, please let me know. :)


Looks great.  Thanks for following up quickly on the reviews.



Paolo, if it is okay to you, could you please consider to merge this
patchset? ;)

Re: [Qemu-devel] [RFC PATCH] target/s390x/cpu_models: Set some additional feature bits for the "qemu" CPU

[Thomas Huth]

On 17.05.2017 18:26, Aurelien Jarno wrote:
> On 2017-05-17 17:35, Thomas Huth wrote:
>> Currently we only present the plain z900 feature bits to the guest,
>> but QEMU already emulates some additional features (but not all of
>> the next CPU generation, so we can not use the next CPU level as
>> default yet). Since newer Linux kernels are checking the feature bits
>> and refuse to work if a required feature is missing, we should present
>> as much of the supported features as possible when we are running
>> with the default "qemu" CPU.
>> This patch now adds the "stfle", "extended immediate" and "stckf"
>> facility bits to the "qemu" CPU, which are already supported facilities.
>> It is unfortunately still not enough to run e.g. recent Fedora kernels,
>> but at least it's a first step into the right direction.
> 
> This indeed looks like a step in a good direction. At least it makes the
> recently added STFLE emulation useful :-).
> 
>> Signed-off-by: Thomas Huth 
>> ---
>>  target/s390x/cpu_models.c | 29 ++---
>>  1 file changed, 26 insertions(+), 3 deletions(-)
>>
>> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
>> index 8d27363..18789ab 100644
>> --- a/target/s390x/cpu_models.c
>> +++ b/target/s390x/cpu_models.c
>> @@ -658,6 +658,24 @@ static void check_compatibility(const S390CPUModel 
>> *max_model,
>>"available in the configuration: ");
>>  }
>>  
>> +/**
>> + * The base TCG CPU model "qemu" is based on the z900. However, we already
>> + * can also emulate some additional features of later CPU generations, so
>> + * we add these additional feature bits here.
>> + */
>> +static void add_qemu_cpu_model_features(S390FeatBitmap fbm)
>> +{
>> +int i, feats[] = {
>> +S390_FEAT_STFLE,
>> +S390_FEAT_EXTENDED_IMMEDIATE,
>> +S390_FEAT_STORE_CLOCK_FAST
> 
> According to my list, QEMU also fully implements the following
> facilities:
> 
> S390_FEAT_LONG_DISPLACEMENT
> S390_FEAT_GENERAL_INSTRUCTIONS_EXT
> S390_FEAT_EXECUTE_EXT
> S390_FEAT_STFLE_45

Ok, thanks, I'll respin and add them to the list!

>> +};
>> +
>> +for (i = 0; i < ARRAY_SIZE(feats); i++) {
>> +set_bit(feats[i], fbm);
>> +}
>> +}
>> +
>>  static S390CPUModel *get_max_cpu_model(Error **errp)
>>  {
>>  static S390CPUModel max_model;
>> @@ -670,10 +688,11 @@ static S390CPUModel *get_max_cpu_model(Error **errp)
>>  if (kvm_enabled()) {
>>  kvm_s390_get_host_cpu_model(_model, errp);
>>  } else {
>> -/* TCG emulates a z900 */
>> +/* TCG emulates a z900 (with some additional features) */
>>  max_model.def = _cpu_defs[0];
>>  bitmap_copy(max_model.features, max_model.def->default_feat,
>>  S390_FEAT_MAX);
>> +add_qemu_cpu_model_features(max_model.features);
>>  }
>>  if (!*errp) {
>>  cached = true;
>> @@ -925,11 +944,15 @@ static void s390_host_cpu_model_initfn(Object *obj)
>>  
>>  static void s390_qemu_cpu_model_initfn(Object *obj)
>>  {
>> +static S390CPUDef s390_qemu_cpu_defs;
>>  S390CPU *cpu = S390_CPU(obj);
>>  
>>  cpu->model = g_malloc0(sizeof(*cpu->model));
>> -/* TCG emulates a z900 */
>> -cpu->model->def = _cpu_defs[0];
>> +/* TCG emulates a z900 (with some additional features) */
>> +memcpy(_qemu_cpu_defs, _cpu_defs[0], 
>> sizeof(s390_qemu_cpu_defs));
>> +add_qemu_cpu_model_features(s390_qemu_cpu_defs.default_feat);
>> +add_qemu_cpu_model_features(s390_qemu_cpu_defs.full_feat);
>> +cpu->model->def = _qemu_cpu_defs;
>>  bitmap_copy(cpu->model->features, cpu->model->def->default_feat,
>>  S390_FEAT_MAX);
>>  }
> 
> Otherwise it looks fine to me.
> 
> Reviewed-by: Aurelien Jarno 

Thanks!

 Thomas

Re: [Qemu-devel] [RFC PATCH] target/s390x/cpu_models: Set some additional feature bits for the "qemu" CPU

[Thomas Huth]

On 17.05.2017 18:49, David Hildenbrand wrote:
> On 17.05.2017 17:35, Thomas Huth wrote:
>> Currently we only present the plain z900 feature bits to the guest,
>> but QEMU already emulates some additional features (but not all of
>> the next CPU generation, so we can not use the next CPU level as
>> default yet). Since newer Linux kernels are checking the feature bits
>> and refuse to work if a required feature is missing, we should present
>> as much of the supported features as possible when we are running
>> with the default "qemu" CPU.
>> This patch now adds the "stfle", "extended immediate" and "stckf"
>> facility bits to the "qemu" CPU, which are already supported facilities.
>> It is unfortunately still not enough to run e.g. recent Fedora kernels,
>> but at least it's a first step into the right direction.
>>
> 
> Three things:
> 
> 1. Should we care about backwards compatibility? I think so. This should
> be fixed up using compat machine properties. (qemu model is a
> migration-safe model and could e.g. be used in KVM setups, too).

Theoretically, I agree, but do we really care about backwards
compatibility at this point in time? All major distro kernels (except
Debian, I think) currently do not work in QEMU, so there is currently
not that much that can be migrated...
And currently, the "qemu" CPU is the very same as the "z900" CPU, so you
might also get along with simply using "-cpu z900" on the destination
instead, I guess.

> 2. I would recommend to not enable STFLE for now. Why?
> 
> It is/was an indication that the system is running on a z9 (and
> implicitly has the basic features). This was not only done because
> people were lazy, but because this bit was implicitly connected to other
> machine properties.

Uh, that's ugly!

> One popular example is the "DAT-enhancement facility 2". It introduced
> the "LOAD PAGE TABLE ENTRY ADDRESS" instruction, but no facility bit was
> introduced. SO there is no way to check if the instruction is available
> and actually working.

Does the Linux kernel use this instruction at all? I just grep'ed
through the kernel sources and did not find it. If the Linux kernel does
not use it, I think we should ignore this interdependency and just
provide the STFLE feature bit to the guest - since recent Linux kernels
depend on it.

> Please note that we added a feature representation for this facility,
> because this would allow us later on to at least model removal of such a
> facility (if HW actually would drop it) on a CPU model level.

What about STFLE bit 78, according to my version of the POP, it says:

"The enhanced-DAT facility 2 is installed in the
 z/Architecture architectural mode."

?

> 3. This introduces some inconsistency. s390x/cpu_models.c:set_feature()
> explicitly tests for such inconsistencies.
> 
> So your QEMU CPU model would have a feature, but you would not be able
> to run that model using QEMU when manually specifying it on the command
> line. Especially, expanding the "qemu" model and feeding it back to QEMU
> will fail.

I've checked that I can also successfully disable the features again at
the command line, using "-cpu qemu,eimm=false" for example, so not sure
what exactly you're talking about here. Could you please elaborate?

> So I am not sure if we should introduce such inconsistencies at that
> point. Rather fix up the basics and then move the CPU model to a
> consistent model.

I think we're very far away from being able to use the next official CPU
model generation in QEMU TCG, so having at least something that let's us
run other recent distro kernels apart from the Debian ones would be very
helpful. I also understand the "qemu" CPU this way: "Simply give me the
best CPU features that TCG currently can provide". If you want to have a
"consistent" CPU state, you can simply use an official model like "z900"
instead.

 Thomas

Re: [Qemu-devel] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.

[Eric Blake]

On 05/17/2017 01:09 PM, John Bradley via Qemu-devel wrote:
> Also available at 
> 
> https://www.dropbox.com/s/gwuquw0kirstw7a/0001-Add-Markus-Armbrusters-code-for-Broadcom-Perhiperals.patch?dl=0
> 
> Following suggestions split my original patch up. This the largest monolithic 
> chunk is 
> additional BCM device support from Markus Armbruster.
> 
> 
>>From 0b39a04030d5a2cea4fcd2159d365580ca155b78 Mon Sep 17 00:00:00 2001
> From: John Bradley 
> Date: Wed, 17 May 2017 18:57:21 +0100
> Subject: [PATCH] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.
> 
> Signed-off-by: John Bradley 
> ---

After a break from the keyboard (always a good idea), I've re-read my
comments on this thread so far.  As usual, email is a lousy medium for
conveying emotion and intent, and I can see how my curt replies merely
pointing out ways that you can improve your patch can easily be
misconstrued as negative advice or rejection of the idea in general.  So
let me take this time to apologize if I've come across as over-harsh,
and give you a big thanks for your efforts to contribute; your additions
have the potential to make qemu better.  I hope that we do not scare you
off with advice on improving your contributions up to community
standard, but that you feel welcome to contribute to the community, as
well as using the give-and-take iteration of review to make your first
patch great.  Writing a first patch series can be especially daunting
when you are new to an unfamiliar process, and while we were all once at
your point, it takes effort to remember that not everyone is as familiar
with open source ways, and how it felt on our own first patch submission.

A big hint: the great way to get a patch accepted on ANY project is to
first offer reviews on other patches being submitted to the list.
Review backlog is always present, but it gets especially bad if there
are more contributors than reviewers.  Plus, reviewing code that other
people write can give you a feel for what constitutes a typical patch
for the project, which will let you model your own submissions in the
same style.

Good luck!

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



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH 1/1] Improve Cocoa modifier key handling

[G 3]

On May 13, 2017, at 11:58 AM, qemu-devel-requ...@nongnu.org wrote:



I had two problems with QEMU on macOS:
 1) Sometimes when alt-tabbing to QEMU it would act as if the 'a' key
was pressed so I'd get 'a'.
 2) Using Sikuli to programatically send keys to the QEMU window text
like "foo_bar" would come out as "fooa-bar".

They looked similar and after much digging the problem turned out  
to be

the same. When QEMU's ui/cocoa.m received an NSFlagsChanged NSEvent it
looked at the keyCode to determine what modifier key changed. This
usually works fine but sometimes the keyCode is 0 and the app should
instead be looking at the modifierFlags bitmask. Key code 0 is the 'a'
key.

I added code that handles keyCode == 0 differently. It checks the
modifierFlags and if they differ from QEMU's idea of which modifier
keys are currently pressed it toggles those changed keys.

This fixes my problems and seems work fine.

The patch itself is an attachment.

Ian
-- next part --
A non-text attachment was scrubbed...
Name: 0001-Improve-Cocoa-modifier-key-handling.patch
Type: application/octet-stream
Size: 4920 bytes
Desc: not available
URL: 


Could you send your patch via email to the qemu developer list? I am  
interested in testing it. Attachments don't work here.

Re: [Qemu-devel] [PULL 00/13] pci, virtio, vhost: fixes

[Michael S. Tsirkin]

On Wed, May 17, 2017 at 03:29:33PM -0700, no-re...@patchew.org wrote:
> Hi,
> 
> This series seems to have some coding style problems. See output below for
> more information:
> 
> Message-id: 1495057396-13387-1-git-send-email-...@redhat.com
> Subject: [Qemu-devel] [PULL 00/13] pci, virtio, vhost: fixes
> Type: series
> 
> === TEST SCRIPT BEGIN ===
> #!/bin/bash
> 
> BASE=base
> n=1
> total=$(git log --oneline $BASE.. | wc -l)
> failed=0
> 
> git config --local diff.renamelimit 0
> git config --local diff.renames True
> 
> commits="$(git log --format=%H --reverse $BASE..)"
> for c in $commits; do
> echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
> if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; 
> then
> failed=1
> echo
> fi
> n=$((n+1))
> done
> 
> exit $failed
> === TEST SCRIPT END ===
> 
> Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
> Switched to a new branch 'test'
> 17bfbca exec: abstract address_space_do_translate()
> 8bb02e7 pci: deassert intx when pci device unrealize
> 1e14278 virtio: allow broken device to notify guest
> dc29a74 Revert "hw/pci: disable pci-bridge's shpc by default"
> 3398123 acpi-defs: clean up open brace usage
> c25b309 ACPI: don't call acpi_pcihp_device_plug_cb on xen
> 02d833c iommu: Don't crash if machine is not PC_MACHINE
> 013b6f7 pc: add 2.10 machine type
> f8df4b9 pc/fwcfg: unbreak migration from qemu-2.5 and qemu-2.6 during 
> firmware boot
> 39fbfab libvhost-user: fix crash when rings aren't ready
> 1b9f61d hw/virtio: fix vhost user fails to startup when MQ
> e03f60a hw/arm/virt: generate 64-bit addressable ACPI objects
> 6fc4238 hw/acpi-defs: replace leading X with x_ in FADT field names
> 
> === OUTPUT BEGIN ===
> Checking PATCH 1/13: hw/acpi-defs: replace leading X with x_ in FADT field 
> names...
> Checking PATCH 2/13: hw/arm/virt: generate 64-bit addressable ACPI objects...
> ERROR: open brace '{' following struct go on the same line
> #157: FILE: include/hw/acpi/acpi-defs.h:239:
> +struct AcpiXsdtDescriptorRev2
> +{
> 
> total: 1 errors, 0 warnings, 125 lines checked
> 
> Your patch has style problems, please review.  If any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
> 
> Checking PATCH 3/13: hw/virtio: fix vhost user fails to startup when MQ...
> Checking PATCH 4/13: libvhost-user: fix crash when rings aren't ready...
> Checking PATCH 5/13: pc/fwcfg: unbreak migration from qemu-2.5 and qemu-2.6 
> during firmware boot...
> Checking PATCH 6/13: pc: add 2.10 machine type...
> Checking PATCH 7/13: iommu: Don't crash if machine is not PC_MACHINE...
> Checking PATCH 8/13: ACPI: don't call acpi_pcihp_device_plug_cb on xen...
> Checking PATCH 9/13: acpi-defs: clean up open brace usage...
> Checking PATCH 10/13: Revert "hw/pci: disable pci-bridge's shpc by default"...
> Checking PATCH 11/13: virtio: allow broken device to notify guest...
> Checking PATCH 12/13: pci: deassert intx when pci device unrealize...
> Checking PATCH 13/13: exec: abstract address_space_do_translate()...
> WARNING: line over 80 characters
> #46: FILE: exec.c:479:
> +section = address_space_translate_internal(d, addr, , plen, 
> is_mmio);
> 
> total: 0 errors, 1 warnings, 142 lines checked

Not by a lot, and seems much clearer this way, so I think it's ok to ignore.

> Your patch has style problems, please review.  If any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
> === OUTPUT END ===
> 
> Test command exited with code: 1
> 
> 
> ---
> Email generated automatically by Patchew [http://patchew.org/].
> Please send your feedback to patchew-de...@freelists.org

Re: [Qemu-devel] [PULL 00/13] pci, virtio, vhost: fixes

[no-reply]

Hi,

This series seems to have some coding style problems. See output below for
more information:

Message-id: 1495057396-13387-1-git-send-email-...@redhat.com
Subject: [Qemu-devel] [PULL 00/13] pci, virtio, vhost: fixes
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
17bfbca exec: abstract address_space_do_translate()
8bb02e7 pci: deassert intx when pci device unrealize
1e14278 virtio: allow broken device to notify guest
dc29a74 Revert "hw/pci: disable pci-bridge's shpc by default"
3398123 acpi-defs: clean up open brace usage
c25b309 ACPI: don't call acpi_pcihp_device_plug_cb on xen
02d833c iommu: Don't crash if machine is not PC_MACHINE
013b6f7 pc: add 2.10 machine type
f8df4b9 pc/fwcfg: unbreak migration from qemu-2.5 and qemu-2.6 during firmware 
boot
39fbfab libvhost-user: fix crash when rings aren't ready
1b9f61d hw/virtio: fix vhost user fails to startup when MQ
e03f60a hw/arm/virt: generate 64-bit addressable ACPI objects
6fc4238 hw/acpi-defs: replace leading X with x_ in FADT field names

=== OUTPUT BEGIN ===
Checking PATCH 1/13: hw/acpi-defs: replace leading X with x_ in FADT field 
names...
Checking PATCH 2/13: hw/arm/virt: generate 64-bit addressable ACPI objects...
ERROR: open brace '{' following struct go on the same line
#157: FILE: include/hw/acpi/acpi-defs.h:239:
+struct AcpiXsdtDescriptorRev2
+{

total: 1 errors, 0 warnings, 125 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 3/13: hw/virtio: fix vhost user fails to startup when MQ...
Checking PATCH 4/13: libvhost-user: fix crash when rings aren't ready...
Checking PATCH 5/13: pc/fwcfg: unbreak migration from qemu-2.5 and qemu-2.6 
during firmware boot...
Checking PATCH 6/13: pc: add 2.10 machine type...
Checking PATCH 7/13: iommu: Don't crash if machine is not PC_MACHINE...
Checking PATCH 8/13: ACPI: don't call acpi_pcihp_device_plug_cb on xen...
Checking PATCH 9/13: acpi-defs: clean up open brace usage...
Checking PATCH 10/13: Revert "hw/pci: disable pci-bridge's shpc by default"...
Checking PATCH 11/13: virtio: allow broken device to notify guest...
Checking PATCH 12/13: pci: deassert intx when pci device unrealize...
Checking PATCH 13/13: exec: abstract address_space_do_translate()...
WARNING: line over 80 characters
#46: FILE: exec.c:479:
+section = address_space_translate_internal(d, addr, , plen, 
is_mmio);

total: 0 errors, 1 warnings, 142 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@freelists.org

Re: [Qemu-devel] [RFC] qmp: Return 'user_creatable' & 'hotpluggable' fields on qom-list-types

[Eduardo Habkost]

On Wed, May 17, 2017 at 05:00:29PM -0500, Eric Blake wrote:
> On 05/17/2017 04:25 PM, Eduardo Habkost wrote:
> > Currently there's no way for QMP clients to get a list of device types
> > that are really usable with -device.  This information would be useful
> > for management software and test scripts (like the device-crash-test
> > script I have submitted recently).  Interestingly, the "info qdm" HMP
> > command provides this information, but no QMP command does.
> > 
> > Add two new fields to the return value of qom-list-types:
> > "user-creatable-device" and "hotpluggable-device".  Also, add extra
> > arguments for filtering the list of types based on the new fields.
> > 
> > I'm not sure about the naming of the new command arguments.  Maybe the
> > names are too long, but I believe that "user-creatable-devices-only=false"
> > would have more obvious semantics than "user-creatable-devices=false"
> > (the latter looks ambiguous: it could mean "return only
> > non-user-creatable devices" or "return all devices").
> 
> Since this is still RFC, here's a bikeshed idea:
> 
> "just-user-creatable":false
> 
> is shorter, and still conveys whether we care about just user_creatable
> devices or all devices.
> 

We have a "user-creatable" QOM type name for backend object
types, so I believe the -device suffix is important here.

> > +++ b/qapi-schema.json
> > @@ -3034,12 +3034,24 @@
> >  #
> >  # @name: the type name found in the search
> >  #
> > +# @user-creatable-device: If true, the type is a user-creatable device that
> > +# can be used with the "-device" command-line 
> > option.
> > +# Note that this does not guarantee that the device
> > +# is going to be accepted by all machine-types.
> > +# (since 2.10)
> > +#
> > +# @hotpluggable-device: If true, the type is a hotpluggable device that can
> > +#   be plugged using the "device_add" monitor command.
> > +#   Note that this does not guarantee that the device 
> > can
> > +#   be hotplugged on any machine-type. (since 2.10)
> 
> Do we need the '-device' suffix in both names?  I'm not opposed to it,
> but don't know if it is adding any useful information.

If we keep the -device suffix in "user-creatable-device", adding
the suffix to "hotpluggable" would make it more consistent.

> 
> 
> >  ##
> >  { 'command': 'qom-list-types',
> > -  'data': { '*implements': 'str', '*abstract': 'bool' },
> > +  'data': { '*implements': 'str', '*abstract': 'bool',
> > +'*user-creatable-devices-only': 'bool', 
> > '*hotpluggable-devices-only': 'bool' },
> 
> Long line, try to keep it under 80 columns.

I will fix it. Thanks.

-- 
Eduardo

Re: [Qemu-devel] [RFC] qmp: Return 'user_creatable' & 'hotpluggable' fields on qom-list-types

[Eric Blake]

On 05/17/2017 04:25 PM, Eduardo Habkost wrote:
> Currently there's no way for QMP clients to get a list of device types
> that are really usable with -device.  This information would be useful
> for management software and test scripts (like the device-crash-test
> script I have submitted recently).  Interestingly, the "info qdm" HMP
> command provides this information, but no QMP command does.
> 
> Add two new fields to the return value of qom-list-types:
> "user-creatable-device" and "hotpluggable-device".  Also, add extra
> arguments for filtering the list of types based on the new fields.
> 
> I'm not sure about the naming of the new command arguments.  Maybe the
> names are too long, but I believe that "user-creatable-devices-only=false"
> would have more obvious semantics than "user-creatable-devices=false"
> (the latter looks ambiguous: it could mean "return only
> non-user-creatable devices" or "return all devices").

Since this is still RFC, here's a bikeshed idea:

"just-user-creatable":false

is shorter, and still conveys whether we care about just user_creatable
devices or all devices.

> +++ b/qapi-schema.json
> @@ -3034,12 +3034,24 @@
>  #
>  # @name: the type name found in the search
>  #
> +# @user-creatable-device: If true, the type is a user-creatable device that
> +# can be used with the "-device" command-line option.
> +# Note that this does not guarantee that the device
> +# is going to be accepted by all machine-types.
> +# (since 2.10)
> +#
> +# @hotpluggable-device: If true, the type is a hotpluggable device that can
> +#   be plugged using the "device_add" monitor command.
> +#   Note that this does not guarantee that the device can
> +#   be hotplugged on any machine-type. (since 2.10)

Do we need the '-device' suffix in both names?  I'm not opposed to it,
but don't know if it is adding any useful information.


>  ##
>  { 'command': 'qom-list-types',
> -  'data': { '*implements': 'str', '*abstract': 'bool' },
> +  'data': { '*implements': 'str', '*abstract': 'bool',
> +'*user-creatable-devices-only': 'bool', 
> '*hotpluggable-devices-only': 'bool' },

Long line, try to keep it under 80 columns.

The idea looks reasonable to me.

-- 
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] [RFC] qmp: Return 'user_creatable' & 'hotpluggable' fields on qom-list-types

[no-reply]

Hi,

This series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.

Message-id: 20170517212547.4767-1-ehabk...@redhat.com
Subject: [Qemu-devel] [RFC] qmp: Return 'user_creatable' & 'hotpluggable' 
fields on qom-list-types
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=8
time make docker-test-quick@centos6
time make docker-test-mingw@fedora
time make docker-test-build@min-glib
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
0107b33 qmp: Return 'user_creatable' & 'hotpluggable' fields on qom-list-types

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into '/var/tmp/patchew-tester-tmp-69d8vqp2/src/dtc'...
Submodule path 'dtc': checked out '558cd81bdd432769b59bff01240c44f82cfb1a9d'
  BUILD   centos6
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-69d8vqp2/src'
  ARCHIVE qemu.tgz
  ARCHIVE dtc.tgz
  COPYRUNNER
RUN test-quick in qemu:centos6 
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
ccache-3.1.6-2.el6.x86_64
epel-release-6-8.noarch
gcc-4.4.7-17.el6.x86_64
git-1.7.1-4.el6_7.1.x86_64
glib2-devel-2.28.8-5.el6.x86_64
libfdt-devel-1.4.0-1.el6.x86_64
make-3.81-23.el6.x86_64
package g++ is not installed
pixman-devel-0.32.8-1.el6.x86_64
tar-1.23-15.el6_8.x86_64
zlib-devel-1.2.3-29.el6.x86_64

Environment variables:
PACKAGES=libfdt-devel ccache tar git make gcc g++ zlib-devel 
glib2-devel SDL-devel pixman-devel epel-release
HOSTNAME=dc6ec9f535c9
TERM=xterm
MAKEFLAGS= -j8
HISTSIZE=1000
J=8
USER=root
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
MAIL=/var/spool/mail/root
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LANG=en_US.UTF-8
TARGET_LIST=
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
TEST_DIR=/tmp/qemu-test
LOGNAME=root
LESSOPEN=||/usr/bin/lesspipe.sh %s
FEATURES= dtc
DEBUG=
G_BROKEN_FILENAMES=1
CCACHE_HASHDIR=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/var/tmp/qemu-build/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/var/tmp/qemu-build/install
BIOS directory/var/tmp/qemu-build/install/share/qemu
binary directory  /var/tmp/qemu-build/install/bin
library directory /var/tmp/qemu-build/install/lib
module directory  /var/tmp/qemu-build/install/lib/qemu
libexec directory /var/tmp/qemu-build/install/libexec
include directory /var/tmp/qemu-build/install/include
config directory  /var/tmp/qemu-build/install/etc
local state directory   /var/tmp/qemu-build/install/var
Manual directory  /var/tmp/qemu-build/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /tmp/qemu-test/src
C compilercc
Host C compiler   cc
C++ compiler  
Objective-C compiler cc
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
QEMU_CFLAGS   -I/usr/include/pixman-1   -I$(SRC_PATH)/dtc/libfdt -pthread 
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -fPIE -DPIE -m64 -mcx16 
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels 
-Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security 
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration 
-Wold-style-definition -Wtype-limits -fstack-protector-all
LDFLAGS   -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g 
make  make
install   install
pythonpython -B
smbd  /usr/sbin/smbd
module supportno
host CPU  x86_64
host big endian   no
target list   x86_64-softmmu aarch64-softmmu
tcg debug enabled no
gprof enabled no
sparse enabledno
strip binariesyes
profiler  no
static build  no
pixmansystem
SDL support   yes (1.2.14)
GTK support   no 
GTK GL supportno
VTE support   no 
TLS priority  NORMAL
GNUTLS supportno
GNUTLS rndno
libgcrypt no
libgcrypt kdf no
nettleno 
nettle kdfno
libtasn1  no
curses supportno
virgl support no
curl support  no
mingw32 support   no
Audio drivers oss
Block whitelist (rw) 
Block whitelist (ro) 
VirtFS supportno
VNC support   yes
VNC SASL support  no
VNC JPEG support  no
VNC PNG support   no
xen support   no
brlapi supportno
bluez  supportno
Documentation no
PIE   yes
vde support   no
netmap supportno
Linux AIO support no
ATTR/XATTR support yes
Install blobs yes
KVM support   yes
HAX support   no
RDMA support  no
TCG interpreter   

Re: [Qemu-devel] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.

[Eric Blake]

On 05/17/2017 04:25 PM, John Bradley wrote:
> Well unfortunately Eric. I don't understand your "top posted" slang.

To learn what top-posting is:
http://lmgtfy.com/?q=what+is+top-posting

and why we don't like it on technical lists:
http://www.caliburn.nl/topposting.html

Or more humorously:

A: Yes.
> >Q: Are you sure?
>> >>A: Because it reverses the logical flow of conversation.
>>> >>>Q: Why is top posting frowned upon?

> 
> As for his "intent", it is quite irrelevant as I have gone over the code line 
> by line and what every he intended to do, he has succeed, as far as I can 
> tell , in matching you standards, to such an extent that I am happy that 

You are correct that the GPL gives us legal rights to use Andrew's code
without his permission.  And yes, YOU can fork qemu, and take whatever
GPL patches you want without attribution, and you are probably still
just fine legally (as long as you still abide by the GPL in that you
distribute sources to anyone that has your binary).

But our project rules do not allow us to live by just GPL (in part,
because the license of qemu is sometimes tricky to determine due to a
mix of GPLv2-only code and non-GPL code, even though most new code is
GPLv2+).  Also, if we ever had a reason to change license (supposing it
is even possible, although it might require ripping out or
reimplementing portions of the code base), having S-o-b means that we
cannot be accused of applying a license that someone did not agree to.

Therefore, it is easier, pragmatically, even if not legally necessary,
to enforce proper chain of authorship by getting Signed-off-by: tags on
ALL patches, especially where a patch asserts a copyright owner, insofar
as the original copyright owner is still alive and able to assent to the
action.  It is not just about legalities, it is also about risk-avoidance.

It may sound like we are being hard-nosed (and so be it), but there's a
reason that we list proper Signed-off-by: rules as our number 1 item on
the SubmitAPatch page.
http://wiki.qemu.org/Contribute/SubmitAPatch

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



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PULL 06/13] pc: add 2.10 machine type

[Michael S. Tsirkin]

From: Peter Xu 

CC: "Michael S. Tsirkin" 
CC: Paolo Bonzini 
CC: Richard Henderson 
CC: Eduardo Habkost 
Signed-off-by: Peter Xu 
Reviewed-by: Eduardo Habkost 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 include/hw/i386/pc.h |  3 +++
 hw/i386/pc_piix.c| 15 ---
 hw/i386/pc_q35.c | 13 +++--
 3 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index d0183c4..e447f5d 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -382,6 +382,9 @@ int e820_add_entry(uint64_t, uint64_t, uint32_t);
 int e820_get_num_entries(void);
 bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
 
+#define PC_COMPAT_2_9 \
+HW_COMPAT_2_9 \
+
 #define PC_COMPAT_2_8 \
 HW_COMPAT_2_8 \
 {\
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index a11190b..8f3d85c 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -437,21 +437,30 @@ static void pc_i440fx_machine_options(MachineClass *m)
 m->default_display = "std";
 }
 
-static void pc_i440fx_2_9_machine_options(MachineClass *m)
+static void pc_i440fx_2_10_machine_options(MachineClass *m)
 {
 pc_i440fx_machine_options(m);
 m->alias = "pc";
 m->is_default = 1;
 }
 
+DEFINE_I440FX_MACHINE(v2_10, "pc-i440fx-2.10", NULL,
+  pc_i440fx_2_10_machine_options);
+
+static void pc_i440fx_2_9_machine_options(MachineClass *m)
+{
+pc_i440fx_2_10_machine_options(m);
+m->is_default = 0;
+m->alias = NULL;
+SET_MACHINE_COMPAT(m, PC_COMPAT_2_9);
+}
+
 DEFINE_I440FX_MACHINE(v2_9, "pc-i440fx-2.9", NULL,
   pc_i440fx_2_9_machine_options);
 
 static void pc_i440fx_2_8_machine_options(MachineClass *m)
 {
 pc_i440fx_2_9_machine_options(m);
-m->is_default = 0;
-m->alias = NULL;
 SET_MACHINE_COMPAT(m, PC_COMPAT_2_8);
 }
 
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 0a61a20..cf9a788 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -301,19 +301,28 @@ static void pc_q35_machine_options(MachineClass *m)
 m->max_cpus = 288;
 }
 
-static void pc_q35_2_9_machine_options(MachineClass *m)
+static void pc_q35_2_10_machine_options(MachineClass *m)
 {
 pc_q35_machine_options(m);
 m->alias = "q35";
 }
 
+DEFINE_Q35_MACHINE(v2_10, "pc-q35-2.10", NULL,
+   pc_q35_2_10_machine_options);
+
+static void pc_q35_2_9_machine_options(MachineClass *m)
+{
+pc_q35_2_10_machine_options(m);
+m->alias = NULL;
+SET_MACHINE_COMPAT(m, PC_COMPAT_2_9);
+}
+
 DEFINE_Q35_MACHINE(v2_9, "pc-q35-2.9", NULL,
pc_q35_2_9_machine_options);
 
 static void pc_q35_2_8_machine_options(MachineClass *m)
 {
 pc_q35_2_9_machine_options(m);
-m->alias = NULL;
 SET_MACHINE_COMPAT(m, PC_COMPAT_2_8);
 }
 
-- 
MST

[Qemu-devel] [PULL 13/13] exec: abstract address_space_do_translate()

[Michael S. Tsirkin]

From: Peter Xu 

This function is an abstraction helper for address_space_translate() and
address_space_get_iotlb_entry(). It does the lookup of address into
memory region section, then does proper IOMMU translation if necessary.
Refactor the two existing functions to use it.

This fixes vhost when IOMMU is disabled by guest.

Tested-by: Maxime Coquelin 
Signed-off-by: Peter Xu 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 exec.c | 103 +++--
 1 file changed, 69 insertions(+), 34 deletions(-)

diff --git a/exec.c b/exec.c
index eac6085..f942eb2 100644
--- a/exec.c
+++ b/exec.c
@@ -463,18 +463,20 @@ address_space_translate_internal(AddressSpaceDispatch *d, 
hwaddr addr, hwaddr *x
 }
 
 /* Called from RCU critical section */
-IOMMUTLBEntry address_space_get_iotlb_entry(AddressSpace *as, hwaddr addr,
-bool is_write)
+static MemoryRegionSection address_space_do_translate(AddressSpace *as,
+  hwaddr addr,
+  hwaddr *xlat,
+  hwaddr *plen,
+  bool is_write,
+  bool is_mmio)
 {
-IOMMUTLBEntry iotlb = {0};
+IOMMUTLBEntry iotlb;
 MemoryRegionSection *section;
 MemoryRegion *mr;
 
 for (;;) {
 AddressSpaceDispatch *d = atomic_rcu_read(>dispatch);
-section = address_space_lookup_region(d, addr, false);
-addr = addr - section->offset_within_address_space
-   + section->offset_within_region;
+section = address_space_translate_internal(d, addr, , plen, 
is_mmio);
 mr = section->mr;
 
 if (!mr->iommu_ops) {
@@ -482,55 +484,88 @@ IOMMUTLBEntry address_space_get_iotlb_entry(AddressSpace 
*as, hwaddr addr,
 }
 
 iotlb = mr->iommu_ops->translate(mr, addr, is_write);
+addr = ((iotlb.translated_addr & ~iotlb.addr_mask)
+| (addr & iotlb.addr_mask));
+*plen = MIN(*plen, (addr | iotlb.addr_mask) - addr + 1);
 if (!(iotlb.perm & (1 << is_write))) {
-iotlb.target_as = NULL;
-break;
+goto translate_fail;
 }
 
-addr = ((iotlb.translated_addr & ~iotlb.addr_mask)
-| (addr & iotlb.addr_mask));
 as = iotlb.target_as;
 }
 
-return iotlb;
+*xlat = addr;
+
+return *section;
+
+translate_fail:
+return (MemoryRegionSection) { .mr = _mem_unassigned };
 }
 
 /* Called from RCU critical section */
-MemoryRegion *address_space_translate(AddressSpace *as, hwaddr addr,
-  hwaddr *xlat, hwaddr *plen,
-  bool is_write)
+IOMMUTLBEntry address_space_get_iotlb_entry(AddressSpace *as, hwaddr addr,
+bool is_write)
 {
-IOMMUTLBEntry iotlb;
-MemoryRegionSection *section;
-MemoryRegion *mr;
+MemoryRegionSection section;
+hwaddr xlat, plen;
 
-for (;;) {
-AddressSpaceDispatch *d = atomic_rcu_read(>dispatch);
-section = address_space_translate_internal(d, addr, , plen, true);
-mr = section->mr;
+/* Try to get maximum page mask during translation. */
+plen = (hwaddr)-1;
 
-if (!mr->iommu_ops) {
-break;
-}
+/* This can never be MMIO. */
+section = address_space_do_translate(as, addr, , ,
+ is_write, false);
 
-iotlb = mr->iommu_ops->translate(mr, addr, is_write);
-addr = ((iotlb.translated_addr & ~iotlb.addr_mask)
-| (addr & iotlb.addr_mask));
-*plen = MIN(*plen, (addr | iotlb.addr_mask) - addr + 1);
-if (!(iotlb.perm & (1 << is_write))) {
-mr = _mem_unassigned;
-break;
-}
+/* Illegal translation */
+if (section.mr == _mem_unassigned) {
+goto iotlb_fail;
+}
 
-as = iotlb.target_as;
+/* Convert memory region offset into address space offset */
+xlat += section.offset_within_address_space -
+section.offset_within_region;
+
+if (plen == (hwaddr)-1) {
+/*
+ * We use default page size here. Logically it only happens
+ * for identity mappings.
+ */
+plen = TARGET_PAGE_SIZE;
 }
 
+/* Convert to address mask */
+plen -= 1;
+
+return (IOMMUTLBEntry) {
+.target_as = section.address_space,
+.iova = addr & ~plen,
+.translated_addr = xlat & ~plen,
+.addr_mask = plen,
+/* IOTLBs are for DMAs, and DMA only allows on RAMs. */
+.perm = IOMMU_RW,
+};
+
+iotlb_fail:
+return (IOMMUTLBEntry) 

Re: [Qemu-devel] [Qemu-block] [PATCH 07/18] throttle-groups: only start one coroutine from drained_begin

[Alberto Garcia]

On Thu 11 May 2017 04:41:57 PM CEST, Paolo Bonzini wrote:
> Starting all waiting coroutines from bdrv_drain_all is unnecessary;
> throttle_group_co_io_limits_intercept calls schedule_next_request as
> soon as the coroutine restarts, which in turn will restart the next
> request if possible.
>
> If we only start the first request and let the coroutines dance from
> there the code is simpler and there is more reuse between
> throttle_group_config, throttle_group_restart_blk and timer_cb.  The
> next patch will benefit from this.
>
> We also stop accessing from throttle_group_restart_blk the
> blkp->throttled_reqs CoQueues even when there was no
> attached throttling group.  This worked but is not pretty.
>
> The only thing that can interrupt the dance is the QEMU_CLOCK_VIRTUAL
> timer when switching from one block device to the next, because the
> timer is set to "now + 1" but QEMU_CLOCK_VIRTUAL might not be running.
> Set that timer to point in the present ("now") rather than the future
> and things work.
>
> Signed-off-by: Paolo Bonzini 

Reviewed-by: Alberto Garcia 

Berto

[Qemu-devel] [PULL 09/13] acpi-defs: clean up open brace usage

[Michael S. Tsirkin]

patchew has been saying:
ERROR: open brace '{' following struct go on the same line

Fix up acpi-defs.h to follow this rule.

Signed-off-by: Michael S. Tsirkin 
---
 include/hw/acpi/acpi-defs.h | 34 --
 1 file changed, 12 insertions(+), 22 deletions(-)

diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
index 91bae7f..72be675 100644
--- a/include/hw/acpi/acpi-defs.h
+++ b/include/hw/acpi/acpi-defs.h
@@ -81,8 +81,8 @@ typedef struct AcpiRsdpDescriptor AcpiRsdpDescriptor;
 uint32_t asl_compiler_revision;  /* ASL compiler revision number */
 
 
-struct AcpiTableHeader /* ACPI common table header */
-{
+/* ACPI common table header */
+struct AcpiTableHeader {
 ACPI_TABLE_HEADER_DEF
 } QEMU_PACKED;
 typedef struct AcpiTableHeader AcpiTableHeader;
@@ -224,8 +224,7 @@ typedef struct AcpiSerialPortConsoleRedirection
 /*
  * ACPI 1.0 Root System Description Table (RSDT)
  */
-struct AcpiRsdtDescriptorRev1
-{
+struct AcpiRsdtDescriptorRev1 {
 ACPI_TABLE_HEADER_DEF   /* ACPI common table header */
 uint32_t table_offset_entry[0];  /* Array of pointers to other */
 /* ACPI tables */
@@ -235,8 +234,7 @@ typedef struct AcpiRsdtDescriptorRev1 
AcpiRsdtDescriptorRev1;
 /*
  * ACPI 2.0 eXtended System Description Table (XSDT)
  */
-struct AcpiXsdtDescriptorRev2
-{
+struct AcpiXsdtDescriptorRev2 {
 ACPI_TABLE_HEADER_DEF   /* ACPI common table header */
 uint64_t table_offset_entry[0];  /* Array of pointers to other */
 /* ACPI tables */
@@ -246,8 +244,7 @@ typedef struct AcpiXsdtDescriptorRev2 
AcpiXsdtDescriptorRev2;
 /*
  * ACPI 1.0 Firmware ACPI Control Structure (FACS)
  */
-struct AcpiFacsDescriptorRev1
-{
+struct AcpiFacsDescriptorRev1 {
 uint32_t signature;   /* ACPI Signature */
 uint32_t length; /* Length of structure, in bytes */
 uint32_t hardware_signature; /* Hardware configuration signature */
@@ -273,8 +270,7 @@ typedef struct AcpiFacsDescriptorRev1 
AcpiFacsDescriptorRev1;
 
 /* Master MADT */
 
-struct AcpiMultipleApicTable
-{
+struct AcpiMultipleApicTable {
 ACPI_TABLE_HEADER_DEF /* ACPI common table header */
 uint32_t local_apic_address; /* Physical address of local APIC */
 uint32_t flags;
@@ -310,8 +306,7 @@ typedef struct AcpiMultipleApicTable AcpiMultipleApicTable;
 
 /* Sub-structures for MADT */
 
-struct AcpiMadtProcessorApic
-{
+struct AcpiMadtProcessorApic {
 ACPI_SUB_HEADER_DEF
 uint8_t  processor_id;   /* ACPI processor id */
 uint8_t  local_apic_id;  /* Processor's local APIC id */
@@ -319,8 +314,7 @@ struct AcpiMadtProcessorApic
 } QEMU_PACKED;
 typedef struct AcpiMadtProcessorApic AcpiMadtProcessorApic;
 
-struct AcpiMadtIoApic
-{
+struct AcpiMadtIoApic {
 ACPI_SUB_HEADER_DEF
 uint8_t  io_apic_id; /* I/O APIC ID */
 uint8_t  reserved;   /* Reserved - must be zero */
@@ -473,8 +467,7 @@ typedef struct Acpi20Hpet Acpi20Hpet;
  * SRAT (NUMA topology description) table
  */
 
-struct AcpiSystemResourceAffinityTable
-{
+struct AcpiSystemResourceAffinityTable {
 ACPI_TABLE_HEADER_DEF
 uint32_treserved1;
 uint32_treserved2[2];
@@ -486,8 +479,7 @@ typedef struct AcpiSystemResourceAffinityTable 
AcpiSystemResourceAffinityTable;
 #define ACPI_SRAT_PROCESSOR_x2APIC   2
 #define ACPI_SRAT_PROCESSOR_GICC 3
 
-struct AcpiSratProcessorAffinity
-{
+struct AcpiSratProcessorAffinity {
 ACPI_SUB_HEADER_DEF
 uint8_t proximity_lo;
 uint8_t local_apic_id;
@@ -509,8 +501,7 @@ struct AcpiSratProcessorX2ApicAffinity {
 } QEMU_PACKED;
 typedef struct AcpiSratProcessorX2ApicAffinity AcpiSratProcessorX2ApicAffinity;
 
-struct AcpiSratMemoryAffinity
-{
+struct AcpiSratMemoryAffinity {
 ACPI_SUB_HEADER_DEF
 uint32_tproximity;
 uint16_treserved1;
@@ -522,8 +513,7 @@ struct AcpiSratMemoryAffinity
 } QEMU_PACKED;
 typedef struct AcpiSratMemoryAffinity AcpiSratMemoryAffinity;
 
-struct AcpiSratProcessorGiccAffinity
-{
+struct AcpiSratProcessorGiccAffinity {
 ACPI_SUB_HEADER_DEF
 uint32_tproximity;
 uint32_tacpi_processor_uid;
-- 
MST

[Qemu-devel] [PULL 11/13] virtio: allow broken device to notify guest

[Michael S. Tsirkin]

From: Greg Kurz 

According to section 2.1.2 of the virtio-1 specification:

"The device SHOULD set DEVICE_NEEDS_RESET when it enters an error state that
a reset is needed. If DRIVER_OK is set, after it sets DEVICE_NEEDS_RESET,
the device MUST send a device configuration change notification to the
driver."

Commit "f5ed36635d8f virtio: stop virtqueue processing if device is broken"
introduced a virtio_error() call that just does that:

- internally mark the device as broken
- set the DEVICE_NEEDS_RESET bit in the status
- send a configuration change notification

Unfortunately, virtio_notify_vector(), called by virtio_notify_config(),
returns right away when the device is marked as broken and the notification
isn't sent in this case.

The spec doesn't say whether a broken device can send notifications
in other situations or not. But since the driver isn't supposed to do
anything but to reset the device, it makes sense to keep the check in
virtio_notify_config().

Marking the device as broken AFTER the configuration change notification was
sent is enough to fix the issue.

Signed-off-by: Greg Kurz 
Reviewed-by: Cornelia Huck 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Stefan Hajnoczi 
---
 hw/virtio/virtio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 03592c5..890b4d7 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -2451,12 +2451,12 @@ void GCC_FMT_ATTR(2, 3) virtio_error(VirtIODevice 
*vdev, const char *fmt, ...)
 error_vreport(fmt, ap);
 va_end(ap);
 
-vdev->broken = true;
-
 if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
 virtio_set_status(vdev, vdev->status | VIRTIO_CONFIG_S_NEEDS_RESET);
 virtio_notify_config(vdev);
 }
+
+vdev->broken = true;
 }
 
 static void virtio_memory_listener_commit(MemoryListener *listener)
-- 
MST

[Qemu-devel] [PULL 08/13] ACPI: don't call acpi_pcihp_device_plug_cb on xen

[Michael S. Tsirkin]

From: Bruce Rogers 

Commit f0c9d64a exposed the issue that with a xenfv machine using
pci passthrough, acpi pci hotplug code was being executed by mistake.
Guard calls to acpi_pcihp_device_plug_cb (and corresponding
acpi_pcihp_device_unplug_cb) with a check for xen_enabled(). Without
this check I am seeing an error that the bus doesn't have the
acpi-pcihp-bsel property set.

Signed-off-by: Bruce Rogers 
Reviewed-by: Igor Mammedov 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/acpi/piix4.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index a553a7e..c409374 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -385,7 +385,10 @@ static void piix4_device_plug_cb(HotplugHandler 
*hotplug_dev,
 dev, errp);
 }
 } else if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
-acpi_pcihp_device_plug_cb(hotplug_dev, >acpi_pci_hotplug, dev, 
errp);
+if (!xen_enabled()) {
+acpi_pcihp_device_plug_cb(hotplug_dev, >acpi_pci_hotplug, dev,
+  errp);
+}
 } else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
 if (s->cpu_hotplug_legacy) {
 legacy_acpi_cpu_plug_cb(hotplug_dev, >gpe_cpu, dev, errp);
@@ -408,8 +411,10 @@ static void piix4_device_unplug_request_cb(HotplugHandler 
*hotplug_dev,
 acpi_memory_unplug_request_cb(hotplug_dev, >acpi_memory_hotplug,
   dev, errp);
 } else if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
-acpi_pcihp_device_unplug_cb(hotplug_dev, >acpi_pci_hotplug, dev,
-errp);
+if (!xen_enabled()) {
+acpi_pcihp_device_unplug_cb(hotplug_dev, >acpi_pci_hotplug, dev,
+errp);
+}
 } else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU) &&
!s->cpu_hotplug_legacy) {
 acpi_cpu_unplug_request_cb(hotplug_dev, >cpuhp_state, dev, errp);
-- 
MST

[Qemu-devel] [PULL 12/13] pci: deassert intx when pci device unrealize

[Michael S. Tsirkin]

From: "Herongguang (Stephen)" 

If a pci device is not reset by VM (by writing into config space)
and unplugged by VM, after that when VM reboots, qemu may assert:
pcibus_reset: Assertion `bus->irq_count[i] == 0' failed

Cc: qemu-sta...@nongnu.org
Signed-off-by: herongguang 
Reviewed-by: Marcel Apfelbaum 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/pci/pci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 259483b..98ccc27 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -1083,6 +1083,7 @@ static void pci_qdev_unrealize(DeviceState *dev, Error 
**errp)
 pc->exit(pci_dev);
 }
 
+pci_device_deassert_intx(pci_dev);
 do_pci_unregister_device(pci_dev);
 }
 
-- 
MST

[Qemu-devel] [PULL 02/13] hw/arm/virt: generate 64-bit addressable ACPI objects

[Michael S. Tsirkin]

From: Ard Biesheuvel 

Our current ACPI table generation code limits the placement of ACPI
tables to 32-bit addressable memory, in order to be able to emit the
root pointer (RSDP) and root table (RSDT) using table types from the
ACPI 1.0 days.

Since ARM was not supported by ACPI before version 5.0, it makes sense
to lift this restriction. This is not crucial for mach-virt, which is
guaranteed to have some memory available below the 4 GB mark, but it
is a nice to have for QEMU machines that do not have any 32-bit
addressable memory, which is not uncommon for real world 64-bit ARM
systems.

Since we already emit a version of the RSDP root pointer that has a
secondary 64-bit wide address field for the 64-bit root table (XSDT),
all we need to do is replace the RSDT generation with the generation
of an XSDT table, and use a different slot in the FADT table to refer
to the DSDT.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Andrew Jones 
Acked-by: Laszlo Ersek 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
Acked-by: Peter Maydell 
---
 include/hw/acpi/acpi-defs.h | 11 +++
 include/hw/acpi/aml-build.h |  3 +++
 hw/acpi/aml-build.c | 27 +++
 hw/arm/virt-acpi-build.c| 26 +-
 4 files changed, 54 insertions(+), 13 deletions(-)

diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
index 93e1eba..91bae7f 100644
--- a/include/hw/acpi/acpi-defs.h
+++ b/include/hw/acpi/acpi-defs.h
@@ -233,6 +233,17 @@ struct AcpiRsdtDescriptorRev1
 typedef struct AcpiRsdtDescriptorRev1 AcpiRsdtDescriptorRev1;
 
 /*
+ * ACPI 2.0 eXtended System Description Table (XSDT)
+ */
+struct AcpiXsdtDescriptorRev2
+{
+ACPI_TABLE_HEADER_DEF   /* ACPI common table header */
+uint64_t table_offset_entry[0];  /* Array of pointers to other */
+/* ACPI tables */
+} QEMU_PACKED;
+typedef struct AcpiXsdtDescriptorRev2 AcpiXsdtDescriptorRev2;
+
+/*
  * ACPI 1.0 Firmware ACPI Control Structure (FACS)
  */
 struct AcpiFacsDescriptorRev1
diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
index 00c21f1..eb07c2d 100644
--- a/include/hw/acpi/aml-build.h
+++ b/include/hw/acpi/aml-build.h
@@ -381,6 +381,9 @@ void acpi_build_tables_cleanup(AcpiBuildTables *tables, 
bool mfre);
 void
 build_rsdt(GArray *table_data, BIOSLinker *linker, GArray *table_offsets,
const char *oem_id, const char *oem_table_id);
+void
+build_xsdt(GArray *table_data, BIOSLinker *linker, GArray *table_offsets,
+   const char *oem_id, const char *oem_table_id);
 
 int
 build_append_named_dword(GArray *array, const char *name_format, ...)
diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
index c6f2032..4ddfb68 100644
--- a/hw/acpi/aml-build.c
+++ b/hw/acpi/aml-build.c
@@ -1599,6 +1599,33 @@ build_rsdt(GArray *table_data, BIOSLinker *linker, 
GArray *table_offsets,
  (void *)rsdt, "RSDT", rsdt_len, 1, oem_id, oem_table_id);
 }
 
+/* Build xsdt table */
+void
+build_xsdt(GArray *table_data, BIOSLinker *linker, GArray *table_offsets,
+   const char *oem_id, const char *oem_table_id)
+{
+int i;
+unsigned xsdt_entries_offset;
+AcpiXsdtDescriptorRev2 *xsdt;
+const unsigned table_data_len = (sizeof(uint64_t) * table_offsets->len);
+const unsigned xsdt_entry_size = sizeof(xsdt->table_offset_entry[0]);
+const size_t xsdt_len = sizeof(*xsdt) + table_data_len;
+
+xsdt = acpi_data_push(table_data, xsdt_len);
+xsdt_entries_offset = (char *)xsdt->table_offset_entry - table_data->data;
+for (i = 0; i < table_offsets->len; ++i) {
+uint64_t ref_tbl_offset = g_array_index(table_offsets, uint32_t, i);
+uint64_t xsdt_entry_offset = xsdt_entries_offset + xsdt_entry_size * i;
+
+/* xsdt->table_offset_entry to be filled by Guest linker */
+bios_linker_loader_add_pointer(linker,
+ACPI_BUILD_TABLE_FILE, xsdt_entry_offset, xsdt_entry_size,
+ACPI_BUILD_TABLE_FILE, ref_tbl_offset);
+}
+build_header(linker, table_data,
+ (void *)xsdt, "XSDT", xsdt_len, 1, oem_id, oem_table_id);
+}
+
 void build_srat_memory(AcpiSratMemoryAffinity *numamem, uint64_t base,
uint64_t len, int node, MemoryAffinityFlags flags)
 {
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 0835e59..6e5f339 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -364,12 +364,12 @@ static void acpi_dsdt_add_power_button(Aml *scope)
 
 /* RSDP */
 static GArray *
-build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned rsdt_tbl_offset)
+build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned xsdt_tbl_offset)
 {
 AcpiRsdpDescriptor *rsdp = acpi_data_push(rsdp_table, sizeof *rsdp);
-unsigned rsdt_pa_size = 

[Qemu-devel] [PULL 07/13] iommu: Don't crash if machine is not PC_MACHINE

[Michael S. Tsirkin]

From: Eduardo Habkost 

Currently it's possible to crash QEMU using "-device *-iommu" and
"-machine none":

  $ qemu-system-x86_64 -machine none -device amd-iommu
  qemu/hw/i386/amd_iommu.c:1140:amdvi_realize: Object 0x55627dafbc90 is not an 
instance of type generic-pc-machine
  Aborted (core dumped)
  $ qemu-system-x86_64 -machine none -device intel-iommu
  qemu/hw/i386/intel_iommu.c:2972:vtd_realize: Object 0x56292ec0bc90 is not an 
instance of type generic-pc-machine
  Aborted (core dumped)

Fix amd-iommu and intel-iommu to ensure the current machine is really a
TYPE_PC_MACHINE instance at their realize methods.

Resulting error messages:

  $ qemu-system-x86_64 -machine none -device amd-iommu
  qemu-system-x86_64: -device amd-iommu: Machine-type 'none' not supported by 
amd-iommu
  $ qemu-system-x86_64 -machine none -device intel-iommu
  qemu-system-x86_64: -device intel-iommu: Machine-type 'none' not supported by 
intel-iommu

Signed-off-by: Eduardo Habkost 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/i386/amd_iommu.c   | 15 ++-
 hw/i386/intel_iommu.c | 14 --
 2 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
index f86a40a..516ebae 100644
--- a/hw/i386/amd_iommu.c
+++ b/hw/i386/amd_iommu.c
@@ -21,6 +21,7 @@
  */
 #include "qemu/osdep.h"
 #include "hw/i386/amd_iommu.h"
+#include "qapi/error.h"
 #include "qemu/error-report.h"
 #include "trace.h"
 
@@ -1137,7 +1138,19 @@ static void amdvi_realize(DeviceState *dev, Error **err)
 int ret = 0;
 AMDVIState *s = AMD_IOMMU_DEVICE(dev);
 X86IOMMUState *x86_iommu = X86_IOMMU_DEVICE(dev);
-PCIBus *bus = PC_MACHINE(qdev_get_machine())->bus;
+MachineState *ms = MACHINE(qdev_get_machine());
+MachineClass *mc = MACHINE_GET_CLASS(ms);
+PCMachineState *pcms =
+PC_MACHINE(object_dynamic_cast(OBJECT(ms), TYPE_PC_MACHINE));
+PCIBus *bus;
+
+if (!pcms) {
+error_setg(err, "Machine-type '%s' not supported by amd-iommu",
+   mc->name);
+return;
+}
+
+bus = pcms->bus;
 s->iotlb = g_hash_table_new_full(amdvi_uint64_hash,
  amdvi_uint64_equal, g_free, g_free);
 
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 02f047c..a12b176 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -2969,11 +2969,21 @@ static bool vtd_decide_config(IntelIOMMUState *s, Error 
**errp)
 
 static void vtd_realize(DeviceState *dev, Error **errp)
 {
-PCMachineState *pcms = PC_MACHINE(qdev_get_machine());
-PCIBus *bus = pcms->bus;
+MachineState *ms = MACHINE(qdev_get_machine());
+MachineClass *mc = MACHINE_GET_CLASS(ms);
+PCMachineState *pcms =
+PC_MACHINE(object_dynamic_cast(OBJECT(ms), TYPE_PC_MACHINE));
+PCIBus *bus;
 IntelIOMMUState *s = INTEL_IOMMU_DEVICE(dev);
 X86IOMMUState *x86_iommu = X86_IOMMU_DEVICE(dev);
 
+if (!pcms) {
+error_setg(errp, "Machine-type '%s' not supported by intel-iommu",
+   mc->name);
+return;
+}
+
+bus = pcms->bus;
 VTD_DPRINTF(GENERAL, "");
 x86_iommu->type = TYPE_INTEL;
 
-- 
MST

[Qemu-devel] [PULL 03/13] hw/virtio: fix vhost user fails to startup when MQ

[Michael S. Tsirkin]

From: Zhiyong Yang 

 Qemu2.7~2.9 and vhost user for dpdk 17.02 release work together
to cause failures of new connection when negotiating to set MQ.
(one queue pair works well).
   Because there exist some bugs in qemu code when introducing
VHOST_USER_PROTOCOL_F_REPLY_ACK to qemu. When vhost_user_set_mem_table
is invoked to deal with the vhost message VHOST_USER_SET_MEM_TABLE
for the second time, qemu indeed doesn't send the messge (The message
needs to be sent only once)but still will be waiting for dpdk's reply
ack, then, qemu is always freezing, while DPDK is always waiting for
next vhost message from qemu.
  The patch aims to fix the bug, MQ can work well.
  The same bug is found in function vhost_user_net_set_mtu, it is fixed
at the same time.
  DPDK related patch is as following:
  http://www.dpdk.org/dev/patchwork/patch/23955/

Signed-off-by: Zhiyong Yang 
Cc: qemu-sta...@nongnu.org
Fixes: ca525ce5618b ("vhost-user: Introduce a new protocol feature REPLY_ACK.")
Reviewed-by: Maxime Coquelin 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
Tested-by: Jens Freimann 
Reviewed-by: Marc-André Lureau 
---
 hw/virtio/vhost-user.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
index 9334a8a..32a95a8 100644
--- a/hw/virtio/vhost-user.c
+++ b/hw/virtio/vhost-user.c
@@ -163,22 +163,26 @@ fail:
 }
 
 static int process_message_reply(struct vhost_dev *dev,
- VhostUserRequest request)
+ VhostUserMsg msg)
 {
-VhostUserMsg msg;
+VhostUserMsg msg_reply;
 
-if (vhost_user_read(dev, ) < 0) {
+if ((msg.flags & VHOST_USER_NEED_REPLY_MASK) == 0) {
+return 0;
+}
+
+if (vhost_user_read(dev, _reply) < 0) {
 return -1;
 }
 
-if (msg.request != request) {
+if (msg_reply.request != msg.request) {
 error_report("Received unexpected msg type."
  "Expected %d received %d",
- request, msg.request);
+ msg.request, msg_reply.request);
 return -1;
 }
 
-return msg.payload.u64 ? -1 : 0;
+return msg_reply.payload.u64 ? -1 : 0;
 }
 
 static bool vhost_user_one_time_request(VhostUserRequest request)
@@ -208,6 +212,7 @@ static int vhost_user_write(struct vhost_dev *dev, 
VhostUserMsg *msg,
  * request, we just ignore it.
  */
 if (vhost_user_one_time_request(msg->request) && dev->vq_index != 0) {
+msg->flags &= ~VHOST_USER_NEED_REPLY_MASK;
 return 0;
 }
 
@@ -320,7 +325,7 @@ static int vhost_user_set_mem_table(struct vhost_dev *dev,
 }
 
 if (reply_supported) {
-return process_message_reply(dev, msg.request);
+return process_message_reply(dev, msg);
 }
 
 return 0;
@@ -712,7 +717,7 @@ static int vhost_user_net_set_mtu(struct vhost_dev *dev, 
uint16_t mtu)
 
 /* If reply_ack supported, slave has to ack specified MTU is valid */
 if (reply_supported) {
-return process_message_reply(dev, msg.request);
+return process_message_reply(dev, msg);
 }
 
 return 0;
-- 
MST

[Qemu-devel] [PULL 10/13] Revert "hw/pci: disable pci-bridge's shpc by default"

[Michael S. Tsirkin]

From: Marcel Apfelbaum 

This reverts commit dc0ae767700c156894e36fab89a745a2dc4173de.

Disabling the shpc controller has an undesired side effect.
The PCI bridge remains with no attached devices at boot time,
and the guest operating systems do not allocate any resources
for it, leaving the bridge unusable. Note that the behaviour
is dictated by the pci bridge specification.

Revert the commit and leave the shpc controller even if is not
actually used by any architecture. Slot 0 remains unusable at boot time.

Keep shpc off for QEMU 2.9 machines.

Signed-off-by: Marcel Apfelbaum 
Reviewed-by: Paolo Bonzini 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 include/hw/compat.h| 6 +-
 hw/pci-bridge/pci_bridge_dev.c | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/include/hw/compat.h b/include/hw/compat.h
index 846b90e..55b1765 100644
--- a/include/hw/compat.h
+++ b/include/hw/compat.h
@@ -2,7 +2,11 @@
 #define HW_COMPAT_H
 
 #define HW_COMPAT_2_9 \
-/* empty */
+{\
+.driver   = "pci-bridge",\
+.property = "shpc",\
+.value= "off",\
+},
 
 #define HW_COMPAT_2_8 \
 {\
diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c
index 647ad80..5dbd933 100644
--- a/hw/pci-bridge/pci_bridge_dev.c
+++ b/hw/pci-bridge/pci_bridge_dev.c
@@ -163,7 +163,7 @@ static Property pci_bridge_dev_properties[] = {
 DEFINE_PROP_ON_OFF_AUTO(PCI_BRIDGE_DEV_PROP_MSI, PCIBridgeDev, msi,
 ON_OFF_AUTO_AUTO),
 DEFINE_PROP_BIT(PCI_BRIDGE_DEV_PROP_SHPC, PCIBridgeDev, flags,
-PCI_BRIDGE_DEV_F_SHPC_REQ, false),
+PCI_BRIDGE_DEV_F_SHPC_REQ, true),
 DEFINE_PROP_END_OF_LIST(),
 };
 
-- 
MST

[Qemu-devel] [PULL 05/13] pc/fwcfg: unbreak migration from qemu-2.5 and qemu-2.6 during firmware boot

[Michael S. Tsirkin]

From: Igor Mammedov 

Since 2.7 commit (b2a575a Add optionrom compatible with fw_cfg DMA version)
regressed migration during firmware exection time by
abusing fwcfg.dma_enabled property to decide loading
dma version of option rom AND by mistake disabling DMA
for 2.6 and earlier globally instead of only for option rom.

so 2.6 machine type guest is broken when it already runs
firmware in DMA mode but migrated to qemu-2.7(pc-2.6)
at that time;

a) qemu-2.6:pc2.6 (fwcfg.dma=on,firmware=dma,oprom=ioport)
b) qemu-2.7:pc2.6 (fwcfg.dma=off,firmware=ioport,oprom=ioport)

  to:   a b
from
a   OK   FAIL
b   OK   OK

So we currently have broken forward migration from
qemu-2.6 to qemu-2.[789] that however could be fixed
for 2.10 by re-enabling DMA for 2.[56] machine types
and allowing dma capable option rom only since 2.7.
As result qemu should end up with:

c) qemu-2.10:pc2.6 (fwcfg.dma=on,firmware=dma,oprom=ioport)

   to:  a bc
from
a  OK   FAIL  OK
b  OK   OKOK
c  OK   FAIL  OK

where forward migration from qemu-2.6 to qemu-2.10 should
work again leaving only qemu-2.[789]:pc-2.6 broken.

Reported-by: Eduardo Habkost 
Analyzed-by: Laszlo Ersek 
Signed-off-by: Igor Mammedov 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Eduardo Habkost 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 include/hw/i386/pc.h | 7 +++
 hw/i386/pc.c | 9 -
 hw/i386/pc_piix.c| 1 +
 hw/i386/pc_q35.c | 1 +
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 416aaa5..d0183c4 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -151,6 +151,9 @@ struct PCMachineClass {
 bool save_tsc_khz;
 /* generate legacy CPU hotplug AML */
 bool legacy_cpu_hotplug;
+
+/* use DMA capable linuxboot option rom */
+bool linuxboot_dma_enabled;
 };
 
 #define TYPE_PC_MACHINE "generic-pc-machine"
@@ -438,10 +441,6 @@ bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
 #define PC_COMPAT_2_6 \
 HW_COMPAT_2_6 \
 {\
-.driver   = "fw_cfg_io",\
-.property = "dma_enabled",\
-.value= "off",\
-},{\
 .driver   = TYPE_X86_CPU,\
 .property = "cpuid-0xb",\
 .value= "off",\
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index f3b372a..8063241 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1047,12 +1047,10 @@ static void load_linux(PCMachineState *pcms,
 fw_cfg_add_i32(fw_cfg, FW_CFG_SETUP_SIZE, setup_size);
 fw_cfg_add_bytes(fw_cfg, FW_CFG_SETUP_DATA, setup, setup_size);
 
-if (fw_cfg_dma_enabled(fw_cfg)) {
+option_rom[nb_option_roms].bootindex = 0;
+option_rom[nb_option_roms].name = "linuxboot.bin";
+if (pcmc->linuxboot_dma_enabled && fw_cfg_dma_enabled(fw_cfg)) {
 option_rom[nb_option_roms].name = "linuxboot_dma.bin";
-option_rom[nb_option_roms].bootindex = 0;
-} else {
-option_rom[nb_option_roms].name = "linuxboot.bin";
-option_rom[nb_option_roms].bootindex = 0;
 }
 nb_option_roms++;
 }
@@ -2321,6 +2319,7 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
  * to be used at the moment, 32K should be enough for a while.  */
 pcmc->acpi_data_size = 0x2 + 0x8000;
 pcmc->save_tsc_khz = true;
+pcmc->linuxboot_dma_enabled = true;
 mc->get_hotplug_handler = pc_get_hotpug_handler;
 mc->cpu_index_to_socket_id = pc_cpu_index_to_socket_id;
 mc->possible_cpu_arch_ids = pc_possible_cpu_arch_ids;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 9f102aa..a11190b 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -474,6 +474,7 @@ static void pc_i440fx_2_6_machine_options(MachineClass *m)
 PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
 pc_i440fx_2_7_machine_options(m);
 pcmc->legacy_cpu_hotplug = true;
+pcmc->linuxboot_dma_enabled = false;
 SET_MACHINE_COMPAT(m, PC_COMPAT_2_6);
 }
 
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index dd792a8..0a61a20 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -335,6 +335,7 @@ static void pc_q35_2_6_machine_options(MachineClass *m)
 PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
 pc_q35_2_7_machine_options(m);
 pcmc->legacy_cpu_hotplug = true;
+pcmc->linuxboot_dma_enabled = false;
 SET_MACHINE_COMPAT(m, PC_COMPAT_2_6);
 }
 
-- 
MST

[Qemu-devel] [PULL 04/13] libvhost-user: fix crash when rings aren't ready

[Michael S. Tsirkin]

From: Marc-André Lureau 

Calling libvhost-user functions like vu_queue_get_avail_bytes() when the
queue doesn't yet have addresses will result in the crashes like the
following:

Program received signal SIGSEGV, Segmentation fault.
0x55c414112ce4 in vring_avail_idx (vq=0x55c41582fd68, vq=0x55c41582fd68)
at /home/dgilbert/git/qemu/contrib/libvhost-user/libvhost-user.c:940
940vq->shadow_avail_idx = vq->vring.avail->idx;
(gdb) p vq
$1 = (VuVirtq *) 0x55c41582fd68
(gdb) p vq->vring
$2 = {num = 0, desc = 0x0, avail = 0x0, used = 0x0, log_guest_addr = 0, flags = 
0}

at /home/dgilbert/git/qemu/contrib/libvhost-user/libvhost-user.c:940
No locals.
at /home/dgilbert/git/qemu/contrib/libvhost-user/libvhost-user.c:960
num_heads = 
out_bytes=out_bytes@entry=0x7fffd035d7c4, max_in_bytes=max_in_bytes@entry=0,
max_out_bytes=max_out_bytes@entry=0) at 
/home/dgilbert/git/qemu/contrib/libvhost-user/libvhost-user.c:1034

Add a pre-condition checks on vring.avail before accessing it.

Fix documentation and return type of vu_queue_empty() while at it.

Signed-off-by: Marc-André Lureau 
Tested-by: Dr. David Alan Gilbert 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 contrib/libvhost-user/libvhost-user.h |  6 +++---
 contrib/libvhost-user/libvhost-user.c | 26 --
 2 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/contrib/libvhost-user/libvhost-user.h 
b/contrib/libvhost-user/libvhost-user.h
index 156b50e..af02a31 100644
--- a/contrib/libvhost-user/libvhost-user.h
+++ b/contrib/libvhost-user/libvhost-user.h
@@ -327,13 +327,13 @@ void vu_queue_set_notification(VuDev *dev, VuVirtq *vq, 
int enable);
 bool vu_queue_enabled(VuDev *dev, VuVirtq *vq);
 
 /**
- * vu_queue_enabled:
+ * vu_queue_empty:
  * @dev: a VuDev context
  * @vq: a VuVirtq queue
  *
- * Returns: whether the queue is empty.
+ * Returns: true if the queue is empty or not ready.
  */
-int vu_queue_empty(VuDev *dev, VuVirtq *vq);
+bool vu_queue_empty(VuDev *dev, VuVirtq *vq);
 
 /**
  * vu_queue_notify:
diff --git a/contrib/libvhost-user/libvhost-user.c 
b/contrib/libvhost-user/libvhost-user.c
index 61e1657..9efb9da 100644
--- a/contrib/libvhost-user/libvhost-user.c
+++ b/contrib/libvhost-user/libvhost-user.c
@@ -1031,6 +1031,11 @@ vu_queue_get_avail_bytes(VuDev *dev, VuVirtq *vq, 
unsigned int *in_bytes,
 idx = vq->last_avail_idx;
 
 total_bufs = in_total = out_total = 0;
+if (unlikely(dev->broken) ||
+unlikely(!vq->vring.avail)) {
+goto done;
+}
+
 while ((rc = virtqueue_num_heads(dev, vq, idx)) > 0) {
 unsigned int max, num_bufs, indirect = 0;
 struct vring_desc *desc;
@@ -1121,11 +1126,16 @@ vu_queue_avail_bytes(VuDev *dev, VuVirtq *vq, unsigned 
int in_bytes,
 
 /* Fetch avail_idx from VQ memory only when we really need to know if
  * guest has added some buffers. */
-int
+bool
 vu_queue_empty(VuDev *dev, VuVirtq *vq)
 {
+if (unlikely(dev->broken) ||
+unlikely(!vq->vring.avail)) {
+return true;
+}
+
 if (vq->shadow_avail_idx != vq->last_avail_idx) {
-return 0;
+return false;
 }
 
 return vring_avail_idx(vq) == vq->last_avail_idx;
@@ -1174,7 +1184,8 @@ vring_notify(VuDev *dev, VuVirtq *vq)
 void
 vu_queue_notify(VuDev *dev, VuVirtq *vq)
 {
-if (unlikely(dev->broken)) {
+if (unlikely(dev->broken) ||
+unlikely(!vq->vring.avail)) {
 return;
 }
 
@@ -1291,7 +1302,8 @@ vu_queue_pop(VuDev *dev, VuVirtq *vq, size_t sz)
 struct vring_desc *desc;
 int rc;
 
-if (unlikely(dev->broken)) {
+if (unlikely(dev->broken) ||
+unlikely(!vq->vring.avail)) {
 return NULL;
 }
 
@@ -1445,7 +1457,8 @@ vu_queue_fill(VuDev *dev, VuVirtq *vq,
 {
 struct vring_used_elem uelem;
 
-if (unlikely(dev->broken)) {
+if (unlikely(dev->broken) ||
+unlikely(!vq->vring.avail)) {
 return;
 }
 
@@ -1474,7 +1487,8 @@ vu_queue_flush(VuDev *dev, VuVirtq *vq, unsigned int 
count)
 {
 uint16_t old, new;
 
-if (unlikely(dev->broken)) {
+if (unlikely(dev->broken) ||
+unlikely(!vq->vring.avail)) {
 return;
 }
 
-- 
MST

[Qemu-devel] [PULL 00/13] pci, virtio, vhost: fixes

[Michael S. Tsirkin]

This includes the previous pull request which still
does not appear to be in - not rebased so merging twice
will not cause conflicts. Note that patch 08 makes checkpatch
complain, patch 9 fixes that.

The following changes since commit 76d20ea0f1b26ebd5da2f5fb2fdf3250cde887bb:

  Merge remote-tracking branch 'armbru/tags/pull-qapi-2017-05-04-v3' into 
staging (2017-05-09 15:49:14 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream

for you to fetch changes up to a764040cc831cfe5b8bf1c80e8341b9bf2de3ce8:

  exec: abstract address_space_do_translate() (2017-05-18 00:35:15 +0300)


pci, virtio, vhost: fixes

A bunch of fixes that missed the release.
Most notably we are reverting shpc back to enabled by default state
as guests uses that as an indicator that hotplug is supported
(even though it's unused). Unfortunately we can't fix this
on the stable branch since that would break migration.

Signed-off-by: Michael S. Tsirkin 


Ard Biesheuvel (2):
  hw/acpi-defs: replace leading X with x_ in FADT field names
  hw/arm/virt: generate 64-bit addressable ACPI objects

Bruce Rogers (1):
  ACPI: don't call acpi_pcihp_device_plug_cb on xen

Eduardo Habkost (1):
  iommu: Don't crash if machine is not PC_MACHINE

Greg Kurz (1):
  virtio: allow broken device to notify guest

Herongguang (Stephen) (1):
  pci: deassert intx when pci device unrealize

Igor Mammedov (1):
  pc/fwcfg: unbreak migration from qemu-2.5 and qemu-2.6 during firmware 
boot

Marc-André Lureau (1):
  libvhost-user: fix crash when rings aren't ready

Marcel Apfelbaum (1):
  Revert "hw/pci: disable pci-bridge's shpc by default"

Michael S. Tsirkin (1):
  acpi-defs: clean up open brace usage

Peter Xu (2):
  pc: add 2.10 machine type
  exec: abstract address_space_do_translate()

Zhiyong Yang (1):
  hw/virtio: fix vhost user fails to startup when MQ

 contrib/libvhost-user/libvhost-user.h |   6 +-
 include/hw/acpi/acpi-defs.h   |  45 +++
 include/hw/acpi/aml-build.h   |   3 +
 include/hw/compat.h   |   6 +-
 include/hw/i386/pc.h  |  10 ++--
 contrib/libvhost-user/libvhost-user.c |  26 +++--
 exec.c| 103 +++---
 hw/acpi/aml-build.c   |  27 +
 hw/acpi/piix4.c   |  11 +++-
 hw/arm/virt-acpi-build.c  |  26 -
 hw/i386/acpi-build.c  |   4 +-
 hw/i386/amd_iommu.c   |  15 -
 hw/i386/intel_iommu.c |  14 -
 hw/i386/pc.c  |   9 ++-
 hw/i386/pc_piix.c |  16 +-
 hw/i386/pc_q35.c  |  14 -
 hw/pci-bridge/pci_bridge_dev.c|   2 +-
 hw/pci/pci.c  |   1 +
 hw/virtio/vhost-user.c|  21 ---
 hw/virtio/virtio.c|   4 +-
 tests/bios-tables-test.c  |   4 +-
 21 files changed, 253 insertions(+), 114 deletions(-)

[Qemu-devel] [PULL 01/13] hw/acpi-defs: replace leading X with x_ in FADT field names

[Michael S. Tsirkin]

From: Ard Biesheuvel 

At the request of Michael, replace the leading capital X in the FADT
field name Xfacs and Xdsdt with lower case x + underscore.

Cc: Michael S. Tsirkin 
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 include/hw/acpi/acpi-defs.h | 4 ++--
 hw/i386/acpi-build.c| 4 ++--
 tests/bios-tables-test.c| 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
index 293ee45..93e1eba 100644
--- a/include/hw/acpi/acpi-defs.h
+++ b/include/hw/acpi/acpi-defs.h
@@ -144,8 +144,8 @@ typedef struct AcpiTableHeader AcpiTableHeader;
 /* ARM-Specific Boot Flags (see below for individual flags) (ACPI 5.1) */ \
 uint16_t arm_boot_flags; \
 uint8_t minor_revision;  /* FADT Minor Revision (ACPI 5.1) */ \
-uint64_t Xfacs;  /* 64-bit physical address of FACS */ \
-uint64_t Xdsdt;  /* 64-bit physical address of DSDT */ \
+uint64_t x_facs;  /* 64-bit physical address of FACS */ \
+uint64_t x_dsdt;  /* 64-bit physical address of DSDT */ \
 /* 64-bit Extended Power Mgt 1a Event Reg Blk address */ \
 struct AcpiGenericAddress xpm1a_event_block; \
 /* 64-bit Extended Power Mgt 1b Event Reg Blk address */ \
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 1d8c645..c75f73e 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -341,7 +341,7 @@ build_fadt(GArray *table_data, BIOSLinker *linker, 
AcpiPmInfo *pm,
 AcpiFadtDescriptorRev3 *fadt = acpi_data_push(table_data, sizeof(*fadt));
 unsigned fw_ctrl_offset = (char *)>firmware_ctrl - table_data->data;
 unsigned dsdt_entry_offset = (char *)>dsdt - table_data->data;
-unsigned xdsdt_entry_offset = (char *)>Xdsdt - table_data->data;
+unsigned xdsdt_entry_offset = (char *)>x_dsdt - table_data->data;
 
 /* FACS address to be filled by Guest linker */
 bios_linker_loader_add_pointer(linker,
@@ -354,7 +354,7 @@ build_fadt(GArray *table_data, BIOSLinker *linker, 
AcpiPmInfo *pm,
 ACPI_BUILD_TABLE_FILE, dsdt_entry_offset, sizeof(fadt->dsdt),
 ACPI_BUILD_TABLE_FILE, dsdt_tbl_offset);
 bios_linker_loader_add_pointer(linker,
-ACPI_BUILD_TABLE_FILE, xdsdt_entry_offset, sizeof(fadt->Xdsdt),
+ACPI_BUILD_TABLE_FILE, xdsdt_entry_offset, sizeof(fadt->x_dsdt),
 ACPI_BUILD_TABLE_FILE, dsdt_tbl_offset);
 
 build_header(linker, table_data,
diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
index 9c96a67..bdef3b9 100644
--- a/tests/bios-tables-test.c
+++ b/tests/bios-tables-test.c
@@ -175,8 +175,8 @@ static void test_acpi_fadt_table(test_data *data)
 ACPI_READ_FIELD(fadt_table->reset_value, addr);
 ACPI_READ_FIELD(fadt_table->arm_boot_flags, addr);
 ACPI_READ_FIELD(fadt_table->minor_revision, addr);
-ACPI_READ_FIELD(fadt_table->Xfacs, addr);
-ACPI_READ_FIELD(fadt_table->Xdsdt, addr);
+ACPI_READ_FIELD(fadt_table->x_facs, addr);
+ACPI_READ_FIELD(fadt_table->x_dsdt, addr);
 ACPI_READ_GENERIC_ADDRESS(fadt_table->xpm1a_event_block, addr);
 ACPI_READ_GENERIC_ADDRESS(fadt_table->xpm1b_event_block, addr);
 ACPI_READ_GENERIC_ADDRESS(fadt_table->xpm1a_control_block, addr);
-- 
MST

Re: [Qemu-devel] [PULL 0/9] pci, virtio, vhost: fixes

[Michael S. Tsirkin]

On Mon, May 15, 2017 at 04:04:33PM +0300, Michael S. Tsirkin wrote:
> On Mon, May 15, 2017 at 01:58:40PM +0100, Stefan Hajnoczi wrote:
> > On Wed, May 10, 2017 at 10:07:58PM +0300, Michael S. Tsirkin wrote:
> > > The following changes since commit 
> > > 76d20ea0f1b26ebd5da2f5fb2fdf3250cde887bb:
> > > 
> > >   Merge remote-tracking branch 'armbru/tags/pull-qapi-2017-05-04-v3' into 
> > > staging (2017-05-09 15:49:14 -0400)
> > > 
> > > are available in the git repository at:
> > > 
> > >   git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream
> > > 
> > > for you to fetch changes up to 8b12e48950a3d59188489b2ff6c5ad9cc09e9866:
> > > 
> > >   acpi-defs: clean up open brace usage (2017-05-10 22:04:23 +0300)
> > > 
> > > 
> > > pci, virtio, vhost: fixes
> > > 
> > > A bunch of fixes that missed the release.
> > > 
> > > Signed-off-by: Michael S. Tsirkin 
> > 
> > Please resend with the checkpatch.pl issue fixed.
> 
> 
> There's no issue - new patch followed surrounding code which
> was not refactored to match checkpatch.
> Last patch of the series refactors all of that file to match.
> 
> We do not need to worry abut bisect for checkpatch issues IMHO.

Ping - is this going to get merged? I'm preparing the next pull request
meanwhile ...

> -- 
> MST

Re: [Qemu-devel] [PATCH V2] Revert "hw/pci: disable pci-bridge's shpc by default"

[Michael S. Tsirkin]

On Thu, May 11, 2017 at 01:25:29PM +0300, Marcel Apfelbaum wrote:
> This reverts commit dc0ae767700c156894e36fab89a745a2dc4173de.
> 
> Disabling the shpc controller has an undesired side effect.
> The PCI bridge remains with no attached devices at boot time,
> and the guest operating systems do not allocate any resources
> for it, leaving the bridge unusable. Note that the behaviour
> is dictated by the pci bridge specification.
> 
> Revert the commit and leave the shpc controller even if is not
> actually used by any architecture. Slot 0 remains unusable at boot time.
> 
> Keep shpc off for QEMU 2.9 machines.
> 
> Signed-off-by: Marcel Apfelbaum 

Applied, thanks!

> ---
> 
> V1 -> V2:
>  - Keep shpc off for QEMU 2.9 machines
>  - Rebased on Michael's tree to get QEMU 2.10 machine types
> 
> Thanks,
> Marcel
> 
>  hw/pci-bridge/pci_bridge_dev.c | 2 +-
>  include/hw/compat.h| 6 +-
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c
> index 647ad80..5dbd933 100644
> --- a/hw/pci-bridge/pci_bridge_dev.c
> +++ b/hw/pci-bridge/pci_bridge_dev.c
> @@ -163,7 +163,7 @@ static Property pci_bridge_dev_properties[] = {
>  DEFINE_PROP_ON_OFF_AUTO(PCI_BRIDGE_DEV_PROP_MSI, PCIBridgeDev, msi,
>  ON_OFF_AUTO_AUTO),
>  DEFINE_PROP_BIT(PCI_BRIDGE_DEV_PROP_SHPC, PCIBridgeDev, flags,
> -PCI_BRIDGE_DEV_F_SHPC_REQ, false),
> +PCI_BRIDGE_DEV_F_SHPC_REQ, true),
>  DEFINE_PROP_END_OF_LIST(),
>  };
>  
> diff --git a/include/hw/compat.h b/include/hw/compat.h
> index 846b90e..55b1765 100644
> --- a/include/hw/compat.h
> +++ b/include/hw/compat.h
> @@ -2,7 +2,11 @@
>  #define HW_COMPAT_H
>  
>  #define HW_COMPAT_2_9 \
> -/* empty */
> +{\
> +.driver   = "pci-bridge",\
> +.property = "shpc",\
> +.value= "off",\
> +},
>  
>  #define HW_COMPAT_2_8 \
>  {\
> -- 
> 2.9.3

Re: [Qemu-devel] [PATCH] Add BCM2835 devices to Arm hardware.

[Eric Blake]

On 05/17/2017 04:05 PM, John Bradley via Qemu-devel wrote:
>>From 0b39a04030d5a2cea4fcd2159d365580ca155b78 Mon Sep 17 00:00:00 2001
> From: John Bradley 
> Date: Wed, 17 May 2017 18:57:21 +0100
> Subject: [PATCH] Add BCM2835 devices to Arm hardware.
> 

The subject line is not typical; you are missing a 'category: ' prefix,
and most commits don't end in '.'.  I'd suggest:

bcm2835: Add new Arm device

Your commit message is sparse. While the subject does a good one-line
summary of WHAT, the commit body is where you state WHY and/or go into
more details.


> Signed-off-by: John Bradley 
> ---
> hw/arm/bcm2835.c | 114 +++
> 1 file changed, 114 insertions(+)

Adding a new .c file without touching any Makefile snippets is pointless
- your new code does not compile.  Therefore, we cannot validate that it
is useful.  Also, it pays to double-check that MAINTAINERS will cover
the new file (if not, you need to add a section, as we are trying to
avoid adding new files without a listed maintainer).

I'm doing a rough code review (as I can't compile this in isolation, and
don't know what the prerequisites are - but at least this patch is small
enough to be reviewable):

> 
> diff --git a/hw/arm/bcm2835.c b/hw/arm/bcm2835.c
> new file mode 100644
> index 00..e5744c1620
> --- /dev/null
> +++ b/hw/arm/bcm2835.c
> @@ -0,0 +1,114 @@
> +/*
> + * Raspberry Pi emulation (c) 2012 Gregory Estrade
> + * Upstreaming code cleanup [including bcm2835_*] (c) 2013 Jan Petrous

Then where is Jan Petrous' Signed-off-by:?

> + *
> + * Rasperry Pi 2 emulation and refactoring Copyright (c) 2015, Microsoft
> + * Written by Andrew Baumann

Then where is Andrew Baumann's Signed-off-by:?

> + *
> + * This code is licensed under the GNU GPLv2 and later.

That's not the usual spelling for GPLv2+ as used in other files,
although we haven't been very consistent so it's probably okay.

$ git grep 'or later' | wc
6039704   58672
$ git grep 'and later' | wc
 71 7346032



> + */
> +
> +#include "qemu/osdep.h"
> +#include "cpu.h"
> +#include "hw/arm/bcm2835.h"
> +#include "hw/arm/raspi_platform.h"
> +#include "hw/sysbus.h"
> +#include "exec/address-spaces.h"
> +
> +
> +/* Peripheral base address seen by the CPU */
> +#define BCM2835_PERI_BASE   0x2000
> +
> +static void bcm2835_init(Object *obj)
> +{
> +BCM2835State *s = BCM2835(obj);
> +
> +object_initialize(>cpus[0], sizeof(s->cpus[0]), "arm1176-" 
> TYPE_ARM_CPU);
> +object_property_add_child(obj, "cpu", OBJECT(>cpus[0]), _abort);
> +
> +object_initialize(>peripherals, sizeof(s->peripherals),
> +  TYPE_BCM2835_PERIPHERALS);
> +object_property_add_child(obj, "peripherals", OBJECT(>peripherals),
> +  _abort);

Does this use of error_abort even compile without an #include
"qapi/error.h"?


> +static void bcm2835_realize(DeviceState *dev, Error **errp)
> +{
> +BCM2835State *s = BCM2835(dev);
> +Object *obj;
> +Error *err = NULL;
> +
> +/* common peripherals from bcm2835 */
> +obj = object_property_get_link(OBJECT(dev), "ram", );
> +if (obj == NULL) {

I personally prefer 'if (!obj)' (less typing), but your use of '(obj ==
NULL)' is fine.

> +error_setg(errp, "%s: required ram link not found: %s",
> +   __func__, error_get_pretty(err));

error_setg() already includes __func__ as part of its boilerplate; your
explicit use of __func__ is redundant and makes your error look stupid.

It looks like you are trying to add details to an existing error -
rather than calling error_setg(, error_get_pretty(err)), you should
instead use:

obj = (, errp);
if (obj == NULL) {
error_prepend(errp, "required ram link not found: ");

> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
> +
> +sysbus_mmio_map_overlap(SYS_BUS_DEVICE(>peripherals), 0,
> +BCM2835_PERI_BASE, 1);
> +
> +object_property_set_bool(OBJECT(>cpus[0]), true, "realized", );
> +if (err) {
> +error_report_err(err);
> +exit(1);

It's weird to mix error_propagate() (return the error to the caller to
deal with) and error_report_err() (report the error to the end user and
exit) in the same function.  You should probably NOT be using
error_report_err() or exit().

-- 
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] [RFC] qmp: Return 'user_creatable' & 'hotpluggable' fields on qom-list-types

[Eduardo Habkost]

On Wed, May 17, 2017 at 02:28:25PM -0700, no-re...@patchew.org wrote:
[...]
>   CC  qmp.o
>   CC  hmp.o
> /var/tmp/patchew-tester-tmp-3wn9eneh/src/qmp.c: In function 
> ‘qom_list_types_tramp’:
> /var/tmp/patchew-tester-tmp-3wn9eneh/src/qmp.c:452:22: error: ‘DeviceClass 
> {aka struct DeviceClass}’ has no member named ‘user_creatable’
>  bool uc = dc ? dc->user_creatable : false;
>   ^~
> /var/tmp/patchew-tester-tmp-3wn9eneh/src/rules.mak:69: recipe for target 
> 'qmp.o' failed
> make: *** [qmp.o] Error 1
> make: *** Waiting for unfinished jobs

This patch is based on Stefan's staging branch, that's why it
won't build properly on qemu.git master.

-- 
Eduardo

Re: [Qemu-devel] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.

[John Bradley via Qemu-devel]

Well unfortunately Eric. I don't understand your "top posted" slang.

As for his "intent", it is quite irrelevant as I have gone over the code line 
by line and what every he intended to do, he has succeed, as far as I can tell 
, in matching you standards, to such an extent that I am happy that 


 
John Bradley
Tel: 07896 839635
Skype: flypie125
125B Grove Street
Edge Hill 
Liverpool L7 7AF


On Wednesday, 17 May 2017, 22:15, Eric Blake  wrote:



On 05/17/2017 03:53 PM, John Bradley wrote:
> Andrew Baumann has and others have release the code under GNU General Public 
> License version 2 (GPLv2), the same as QEMU that allows me to added it to 
> QEMU as it is under the same license, by signing it off this is what I am 
> certifying. 

See this document linked from the SubmitAPatch link (it describes the
kernel meaning of S-o-b tags, although the qemu meaning is the same):

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=f6f94e2ab1b33f0082ac22d71f66385a60d8157f#n297

Yes, your Signed-off-by: asserts that you are okay releasing your
portions of the patch (bullets a, d) and that you chased down that
portions that you did not write are properly licensed (bullet b), but
what you are missing is that when you modify someone else's patch, we
also need that someone's assertion of intent that their work (whether or
not modified by you) meets the same standards (bullet c).  In other
words, when modifying a patch, S-o-b lines should be additive in nature,
rather than replacing his by yours (or, if his is missing in the source
you originally copied from, then we really need to Andrew to chime in
and add one); this is so that there is a full chain of custody on who
wrote portions of the commit.


>  John BradleyTel: 07896 839635Skype: flypie125 125B Grove StreetEdge Hill 
> Liverpool L7 7AF 

Your mailer is sending very poor formatting when rendered as plain text
(and we frown on html mail on this list).

> 
> On Wednesday, 17 May 2017, 20:11, Eric Blake  wrote:
>  
> 
>  On 05/17/2017 01:34 PM, John Bradley wrote:
>> This is especial true as I meant Andrew Baumann 0xabu (Andrew Baumann)
> 
> Top-posting is not nice on technical lists.

And yet, in spite of me mentioning it, you still top-posted. :(


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



Well unfortunately Eric. I don't understand your "top posted" slang.

As for 
his "intent", it is quite irrelevant as I have gone over the code line 
by line and what every he intended to do, he has succeed, as far as I 
can tell , in matching you standards, to such an extent that I am happy 
that he has succeeded in reaching your standards and am happy to certify that 
he has.

As for my mailer it is Yahoos and again as far as I can tell it is full RFC822 
compliant, so perhaps you should adjust you obviously defective mail reader.

Re: [Qemu-devel] [RFC] qmp: Return 'user_creatable' & 'hotpluggable' fields on qom-list-types

[no-reply]

Hi,

This series failed build test on s390x host. Please find the details below.

Message-id: 20170517212547.4767-1-ehabk...@redhat.com
Type: series
Subject: [Qemu-devel] [RFC] qmp: Return 'user_creatable' & 'hotpluggable' 
fields on qom-list-types

=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing to a commit that has the patches applied on top of "base"
# branch
set -e
echo "=== ENV ==="
env
echo "=== PACKAGES ==="
rpm -qa
echo "=== TEST BEGIN ==="
CC=$HOME/bin/cc
INSTALL=$PWD/install
BUILD=$PWD/build
echo -n "Using CC: "
realpath $CC
mkdir -p $BUILD $INSTALL
SRC=$PWD
cd $BUILD
$SRC/configure --cc=$CC --prefix=$INSTALL
make -j4
# XXX: we need reliable clean up
# make check -j4 V=1
make install
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] patchew/20170517212547.4767-1-ehabk...@redhat.com -> 
patchew/20170517212547.4767-1-ehabk...@redhat.com
Switched to a new branch 'test'
0107b33 qmp: Return 'user_creatable' & 'hotpluggable' fields on qom-list-types

=== OUTPUT BEGIN ===
=== ENV ===
XDG_SESSION_ID=55410
SHELL=/bin/sh
USER=fam
PATCHEW=/home/fam/patchew/patchew-cli -s http://patchew.org --nodebug
PATH=/usr/bin:/bin
PWD=/var/tmp/patchew-tester-tmp-3wn9eneh/src
LANG=en_US.UTF-8
HOME=/home/fam
SHLVL=2
LOGNAME=fam
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1012/bus
XDG_RUNTIME_DIR=/run/user/1012
_=/usr/bin/env
=== PACKAGES ===
gpg-pubkey-873529b8-54e386ff
xz-libs-5.2.2-2.fc24.s390x
libxshmfence-1.2-3.fc24.s390x
giflib-4.1.6-15.fc24.s390x
trousers-lib-0.3.13-6.fc24.s390x
ncurses-base-6.0-6.20160709.fc25.noarch
gmp-6.1.1-1.fc25.s390x
libidn-1.33-1.fc25.s390x
slang-2.3.0-7.fc25.s390x
libsemanage-2.5-8.fc25.s390x
pkgconfig-0.29.1-1.fc25.s390x
alsa-lib-1.1.1-2.fc25.s390x
yum-metadata-parser-1.1.4-17.fc25.s390x
python3-slip-dbus-0.6.4-4.fc25.noarch
python2-cssselect-0.9.2-1.fc25.noarch
python-fedora-0.8.0-2.fc25.noarch
createrepo_c-libs-0.10.0-6.fc25.s390x
initscripts-9.69-1.fc25.s390x
wget-1.18-2.fc25.s390x
dhcp-client-4.3.5-1.fc25.s390x
parted-3.2-21.fc25.s390x
flex-2.6.0-3.fc25.s390x
colord-libs-1.3.4-1.fc25.s390x
python-osbs-client-0.33-3.fc25.noarch
perl-Pod-Simple-3.35-1.fc25.noarch
python2-simplejson-3.10.0-1.fc25.s390x
brltty-5.4-2.fc25.s390x
librados2-10.2.4-2.fc25.s390x
tcp_wrappers-7.6-83.fc25.s390x
libcephfs_jni1-10.2.4-2.fc25.s390x
nettle-devel-3.3-1.fc25.s390x
bzip2-devel-1.0.6-21.fc25.s390x
libuuid-2.28.2-2.fc25.s390x
pango-1.40.4-1.fc25.s390x
python3-dnf-1.1.10-6.fc25.noarch
cryptsetup-libs-1.7.4-1.fc25.s390x
texlive-kpathsea-doc-svn41139-33.fc25.1.noarch
netpbm-10.77.00-3.fc25.s390x
openssh-7.4p1-4.fc25.s390x
texlive-kpathsea-bin-svn40473-33.20160520.fc25.1.s390x
texlive-graphics-svn41015-33.fc25.1.noarch
texlive-dvipdfmx-def-svn40328-33.fc25.1.noarch
texlive-mfware-svn40768-33.fc25.1.noarch
texlive-texlive-scripts-svn41433-33.fc25.1.noarch
texlive-euro-svn22191.1.1-33.fc25.1.noarch
texlive-etex-svn37057.0-33.fc25.1.noarch
texlive-iftex-svn29654.0.2-33.fc25.1.noarch
texlive-palatino-svn31835.0-33.fc25.1.noarch
texlive-texlive-docindex-svn41430-33.fc25.1.noarch
texlive-xunicode-svn30466.0.981-33.fc25.1.noarch
texlive-koma-script-svn41508-33.fc25.1.noarch
texlive-pst-grad-svn15878.1.06-33.fc25.1.noarch
texlive-pst-blur-svn15878.2.0-33.fc25.1.noarch
texlive-jknapltx-svn19440.0-33.fc25.1.noarch
netpbm-progs-10.77.00-3.fc25.s390x
texinfo-6.1-4.fc25.s390x
openssl-devel-1.0.2k-1.fc25.s390x
python2-sssdconfig-1.15.2-1.fc25.noarch
gdk-pixbuf2-2.36.6-1.fc25.s390x
mesa-libEGL-13.0.4-3.fc25.s390x
pcre-cpp-8.40-6.fc25.s390x
pcre-utf16-8.40-6.fc25.s390x
glusterfs-extra-xlators-3.10.1-1.fc25.s390x
mesa-libGL-devel-13.0.4-3.fc25.s390x
nss-devel-3.29.3-1.1.fc25.s390x
libaio-0.3.110-6.fc24.s390x
libfontenc-1.1.3-3.fc24.s390x
lzo-2.08-8.fc24.s390x
isl-0.14-5.fc24.s390x
libXau-1.0.8-6.fc24.s390x
linux-atm-libs-2.5.1-14.fc24.s390x
libXext-1.3.3-4.fc24.s390x
libXxf86vm-1.1.4-3.fc24.s390x
bison-3.0.4-4.fc24.s390x
perl-srpm-macros-1-20.fc25.noarch
gawk-4.1.3-8.fc25.s390x
libwayland-client-1.12.0-1.fc25.s390x
perl-Exporter-5.72-366.fc25.noarch
perl-version-0.99.17-1.fc25.s390x
fftw-libs-double-3.3.5-3.fc25.s390x
libssh2-1.8.0-1.fc25.s390x
ModemManager-glib-1.6.4-1.fc25.s390x
newt-python3-0.52.19-2.fc25.s390x
python-munch-2.0.4-3.fc25.noarch
python-bugzilla-1.2.2-4.fc25.noarch
libedit-3.1-16.20160618cvs.fc25.s390x
python-pycurl-7.43.0-4.fc25.s390x
createrepo_c-0.10.0-6.fc25.s390x
device-mapper-multipath-libs-0.4.9-83.fc25.s390x
yum-3.4.3-510.fc25.noarch
dhcp-common-4.3.5-1.fc25.noarch
dracut-config-rescue-044-78.fc25.s390x
teamd-1.26-1.fc25.s390x
mozjs17-17.0.0-16.fc25.s390x
libselinux-2.5-13.fc25.s390x
libgo-devel-6.3.1-1.fc25.s390x
NetworkManager-libnm-1.4.4-3.fc25.s390x
python2-pyparsing-2.1.10-1.fc25.noarch
cairo-gobject-1.14.8-1.fc25.s390x
ethtool-4.8-1.fc25.s390x
xorg-x11-proto-devel-7.7-20.fc25.noarch
brlapi-0.6.5-2.fc25.s390x

[Qemu-devel] [RFC] qmp: Return 'user_creatable' & 'hotpluggable' fields on qom-list-types

[Eduardo Habkost]

Currently there's no way for QMP clients to get a list of device types
that are really usable with -device.  This information would be useful
for management software and test scripts (like the device-crash-test
script I have submitted recently).  Interestingly, the "info qdm" HMP
command provides this information, but no QMP command does.

Add two new fields to the return value of qom-list-types:
"user-creatable-device" and "hotpluggable-device".  Also, add extra
arguments for filtering the list of types based on the new fields.

I'm not sure about the naming of the new command arguments.  Maybe the
names are too long, but I believe that "user-creatable-devices-only=false"
would have more obvious semantics than "user-creatable-devices=false"
(the latter looks ambiguous: it could mean "return only
non-user-creatable devices" or "return all devices").

Signed-off-by: Eduardo Habkost 
---
 qapi-schema.json | 25 +++--
 qmp.c| 39 ++-
 2 files changed, 57 insertions(+), 7 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index 80603cfc51..c0a56fc3a2 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -3034,12 +3034,24 @@
 #
 # @name: the type name found in the search
 #
+# @user-creatable-device: If true, the type is a user-creatable device that
+# can be used with the "-device" command-line option.
+# Note that this does not guarantee that the device
+# is going to be accepted by all machine-types.
+# (since 2.10)
+#
+# @hotpluggable-device: If true, the type is a hotpluggable device that can
+#   be plugged using the "device_add" monitor command.
+#   Note that this does not guarantee that the device can
+#   be hotplugged on any machine-type. (since 2.10)
+#
 # Since: 1.1
 #
 # Notes: This command is experimental and may change syntax in future releases.
 ##
 { 'struct': 'ObjectTypeInfo',
-  'data': { 'name': 'str' } }
+  'data': { 'name': 'str', 'user-creatable-device': 'bool',
+'hotpluggable-device': 'bool' } }
 
 ##
 # @qom-list-types:
@@ -3050,12 +3062,21 @@
 #
 # @abstract: if true, include abstract types in the results
 #
+# @user-creatable-devices-only: If true, return only user-creatable device 
types
+#   (See @ObjectTypeInfo.user-creatable-device)
+#   (since 2.10)
+#
+# @hotpluggable-devices-only: If true, return only hotpluggable device types
+# (See @ObjectTypeInfo.hotpluggable-device)
+# (since 2.10)
+#
 # Returns: a list of @ObjectTypeInfo or an empty list if no results are found
 #
 # Since: 1.1
 ##
 { 'command': 'qom-list-types',
-  'data': { '*implements': 'str', '*abstract': 'bool' },
+  'data': { '*implements': 'str', '*abstract': 'bool',
+'*user-creatable-devices-only': 'bool', 
'*hotpluggable-devices-only': 'bool' },
   'returns': [ 'ObjectTypeInfo' ] }
 
 ##
diff --git a/qmp.c b/qmp.c
index f656940769..4f350e4ea2 100644
--- a/qmp.c
+++ b/qmp.c
@@ -436,29 +436,58 @@ void qmp_change(const char *device, const char *target,
 }
 }
 
+typedef struct QOMListTypesArgs {
+bool user_creatable_devices_only;
+bool hotpluggable_devices_only;
+ObjectTypeInfoList **pret;
+} QOMListTypesArgs;
+
 static void qom_list_types_tramp(ObjectClass *klass, void *data)
 {
-ObjectTypeInfoList *e, **pret = data;
+QOMListTypesArgs *args = data;
+ObjectTypeInfoList *e;
 ObjectTypeInfo *info;
+DeviceClass *dc = DEVICE_CLASS(object_class_dynamic_cast(klass,
+ TYPE_DEVICE));
+bool uc = dc ? dc->user_creatable : false;
+bool hp = dc ? uc && dc->hotpluggable : false;
+
+if ((args->user_creatable_devices_only && !uc) ||
+(args->hotpluggable_devices_only && !hp)) {
+return;
+}
 
 info = g_malloc0(sizeof(*info));
 info->name = g_strdup(object_class_get_name(klass));
+info->user_creatable_device = uc;
+info->hotpluggable_device = hp;
 
 e = g_malloc0(sizeof(*e));
 e->value = info;
-e->next = *pret;
-*pret = e;
+e->next = *args->pret;
+*args->pret = e;
 }
 
 ObjectTypeInfoList *qmp_qom_list_types(bool has_implements,
const char *implements,
bool has_abstract,
bool abstract,
+   bool has_user_creatable_devices_only,
+   bool user_creatable_devices_only,
+   bool has_hotpluggable_devices_only,
+   bool hotpluggable_devices_only,
Error **errp)
 {
 ObjectTypeInfoList *ret 

Re: [Qemu-devel] [PATCH] Add BCM2835 devices to Arm hardware.

[Eric Blake]

On 05/17/2017 04:05 PM, John Bradley via Qemu-devel wrote:
>>From 0b39a04030d5a2cea4fcd2159d365580ca155b78 Mon Sep 17 00:00:00 2001
> From: John Bradley 
> Date: Wed, 17 May 2017 18:57:21 +0100
> Subject: [PATCH] Add BCM2835 devices to Arm hardware.
> 
> Signed-off-by: John Bradley 
> ---
> hw/arm/bcm2835.c | 114 +++
> 1 file changed, 114 insertions(+)
> 

> +#include "qemu/osdep.h"
> +#include "cpu.h"
> +#include "hw/arm/bcm2835.h"

This file does not exist in master. Since it is obvious that this patch
depends on other patches you have pending, you should submit everything
as a patch series (where the patch adding bcm2835.h would be labeled
1/2, and this patch labeled 2/2, as well as with a 0/2 cover letter - or
0/N for however many N patches you plan to submit).  Posting each
dependent patch as a top-level thread with no documentation on how they
interrelate is just going to waste reviewer's time, as well as trigger
more bot-related compile failure messages to you, that could have been
prevented if it had been properly submitted as a series.

It looks like you are not using 'git send-email' to send your patches.
That makes it highly likely that your patches will be corrupted to the
point that they cannot be applied by automated tooling.  While a one-off
patch submission can usually be manually beaten into correct form by the
maintainer, it is much harder to offload this burden onto others when
you plan to submit a series - so you should really fix your workflow to
get 'git send-email' working properly.

-- 
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] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.

[Eric Blake]

On 05/17/2017 03:53 PM, John Bradley wrote:
> Andrew Baumann has and others have release the code under GNU General Public 
> License version 2 (GPLv2), the same as QEMU that allows me to added it to 
> QEMU as it is under the same license, by signing it off this is what I am 
> certifying. 

See this document linked from the SubmitAPatch link (it describes the
kernel meaning of S-o-b tags, although the qemu meaning is the same):

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=f6f94e2ab1b33f0082ac22d71f66385a60d8157f#n297

Yes, your Signed-off-by: asserts that you are okay releasing your
portions of the patch (bullets a, d) and that you chased down that
portions that you did not write are properly licensed (bullet b), but
what you are missing is that when you modify someone else's patch, we
also need that someone's assertion of intent that their work (whether or
not modified by you) meets the same standards (bullet c).  In other
words, when modifying a patch, S-o-b lines should be additive in nature,
rather than replacing his by yours (or, if his is missing in the source
you originally copied from, then we really need to Andrew to chime in
and add one); this is so that there is a full chain of custody on who
wrote portions of the commit.


>  John BradleyTel: 07896 839635Skype: flypie125 125B Grove StreetEdge Hill 
> Liverpool L7 7AF 

Your mailer is sending very poor formatting when rendered as plain text
(and we frown on html mail on this list).

> 
> On Wednesday, 17 May 2017, 20:11, Eric Blake  wrote:
>  
> 
>  On 05/17/2017 01:34 PM, John Bradley wrote:
>> This is especial true as I meant Andrew Baumann 0xabu (Andrew Baumann)
> 
> Top-posting is not nice on technical lists.

And yet, in spite of me mentioning it, you still top-posted. :(

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



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH] Add BCM2835 devices to Arm hardware.

[John Bradley via Qemu-devel]

>From 0b39a04030d5a2cea4fcd2159d365580ca155b78 Mon Sep 17 00:00:00 2001
From: John Bradley 
Date: Wed, 17 May 2017 18:57:21 +0100
Subject: [PATCH] Add BCM2835 devices to Arm hardware.

Signed-off-by: John Bradley 
---
hw/arm/bcm2835.c | 114 +++
1 file changed, 114 insertions(+)

diff --git a/hw/arm/bcm2835.c b/hw/arm/bcm2835.c
new file mode 100644
index 00..e5744c1620
--- /dev/null
+++ b/hw/arm/bcm2835.c
@@ -0,0 +1,114 @@
+/*
+ * Raspberry Pi emulation (c) 2012 Gregory Estrade
+ * Upstreaming code cleanup [including bcm2835_*] (c) 2013 Jan Petrous
+ *
+ * Rasperry Pi 2 emulation and refactoring Copyright (c) 2015, Microsoft
+ * Written by Andrew Baumann
+ *
+ * This code is licensed under the GNU GPLv2 and later.
+ */
+
+#include "qemu/osdep.h"
+#include "cpu.h"
+#include "hw/arm/bcm2835.h"
+#include "hw/arm/raspi_platform.h"
+#include "hw/sysbus.h"
+#include "exec/address-spaces.h"
+
+
+/* Peripheral base address seen by the CPU */
+#define BCM2835_PERI_BASE   0x2000
+
+static void bcm2835_init(Object *obj)
+{
+BCM2835State *s = BCM2835(obj);
+
+object_initialize(>cpus[0], sizeof(s->cpus[0]), "arm1176-" 
TYPE_ARM_CPU);
+object_property_add_child(obj, "cpu", OBJECT(>cpus[0]), _abort);
+
+object_initialize(>peripherals, sizeof(s->peripherals),
+  TYPE_BCM2835_PERIPHERALS);
+object_property_add_child(obj, "peripherals", OBJECT(>peripherals),
+  _abort);
+object_property_add_alias(obj, "board-rev", OBJECT(>peripherals),
+  "board-rev", _abort);
+object_property_add_alias(obj, "vcram-size", OBJECT(>peripherals),
+  "vcram-size", _abort);
+qdev_set_parent_bus(DEVICE(>peripherals), sysbus_get_default());
+}
+
+static void bcm2835_realize(DeviceState *dev, Error **errp)
+{
+BCM2835State *s = BCM2835(dev);
+Object *obj;
+Error *err = NULL;
+
+/* common peripherals from bcm2835 */
+obj = object_property_get_link(OBJECT(dev), "ram", );
+if (obj == NULL) {
+error_setg(errp, "%s: required ram link not found: %s",
+   __func__, error_get_pretty(err));
+return;
+}
+
+object_property_add_const_link(OBJECT(>peripherals), "ram", obj, );
+if (err) {
+error_propagate(errp, err);
+return;
+}
+
+object_property_set_bool(OBJECT(>peripherals), true, "realized", );
+if (err) {
+error_propagate(errp, err);
+return;
+}
+
+object_property_add_alias(OBJECT(s), "sd-bus", OBJECT(>peripherals),
+  "sd-bus", );
+if (err) {
+error_propagate(errp, err);
+return;
+}
+
+sysbus_mmio_map_overlap(SYS_BUS_DEVICE(>peripherals), 0,
+BCM2835_PERI_BASE, 1);
+
+object_property_set_bool(OBJECT(>cpus[0]), true, "realized", );
+if (err) {
+error_report_err(err);
+exit(1);
+}
+
+sysbus_connect_irq(SYS_BUS_DEVICE(>peripherals), 0,
+   qdev_get_gpio_in(DEVICE(>cpus[0]), ARM_CPU_IRQ));
+sysbus_connect_irq(SYS_BUS_DEVICE(>peripherals), 1,
+   qdev_get_gpio_in(DEVICE(>cpus[0]), ARM_CPU_FIQ));
+}
+
+static Property bcm2835_props[] = {
+DEFINE_PROP_UINT32("enabled-cpus", BCM2835State, enabled_cpus, 
BCM2835_NCPUS),
+DEFINE_PROP_END_OF_LIST()
+};
+
+static void bcm2835_class_init(ObjectClass *oc, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(oc);
+
+dc->props = bcm2835_props;
+dc->realize = bcm2835_realize;
+}
+
+static const TypeInfo bcm2835_type_info = {
+.name = TYPE_BCM2835,
+.parent = TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(BCM2835State),
+.instance_init = bcm2835_init,
+.class_init = bcm2835_class_init,
+};
+
+static void bcm2835_register_types(void)
+{
+type_register_static(_type_info);
+}
+
+type_init(bcm2835_register_types)


 
John Bradley
Tel: 07896 839635
Skype: flypie125
125B Grove Street
Edge Hill 
Liverpool L7 7AF

Re: [Qemu-devel] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.

[John Bradley via Qemu-devel]

Andrew Baumann has and others have release the code under GNU General Public 
License version 2 (GPLv2), the same as QEMU that allows me to added it to QEMU 
as it is under the same license, by signing it off this is what I am 
certifying. 
 John BradleyTel: 07896 839635Skype: flypie125 125B Grove StreetEdge Hill 
Liverpool L7 7AF 

On Wednesday, 17 May 2017, 20:11, Eric Blake  wrote:
 

 On 05/17/2017 01:34 PM, John Bradley wrote:
> This is especial true as I meant Andrew Baumann 0xabu (Andrew Baumann)

Top-posting is not nice on technical lists.

> 0xabu (Andrew Baumann)
>  0xabu has 3 repositories available. Follow their code on GitHub.  |  |

Using github requires the use of non-free (as in freedom) Javascript.
That's why this list prefers that all patches be sent through the list
as emails, not as github pull requests.  I'm not going to look at what
0xabu's repository contains, but rather at what you send through the
list. But part of the contract of Signed-off-by is that you have
permission to post the patch and agree to the license in use - which
means that if your work is a modified version of Andrew Baumann's work,
then you need Andrew Baumann's sign-off before you can add yours.

Other hints for better patch submission may be found here:
http://wiki.qemu.org/Contribute/SubmitAPatch

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


   

Re: [Qemu-devel] [PATCH 0/3] block: fix 'savevm' hang with -object iothread

[Paolo Bonzini]

- Original Message -
> From: "Stefan Hajnoczi" 
> To: qemu-devel@nongnu.org
> Cc: "Kevin Wolf" , "Paolo Bonzini" , 
> "Fam Zheng" , "Stefan
> Hajnoczi" , qemu-bl...@nongnu.org
> Sent: Wednesday, May 17, 2017 7:09:38 PM
> Subject: [Qemu-devel] [PATCH 0/3] block: fix 'savevm' hang with -object 
> iothread
> 
> The 'savevm' command hangs when -object iothread is used.  See patches for
> details, but basically the vmstate read/write code didn't conform to the
> latest block layer locking rules.

Thanks for the fixes.

Reviewed-by: Paolo Bonzini 

> Stefan Hajnoczi (3):
>   block: count bdrv_co_rw_vmstate() requests
>   block: use BDRV_POLL_WHILE() in bdrv_rw_vmstate()
>   migration: avoid recursive AioContext locking in save_vmstate()
> 
>  block/io.c | 21 +
>  migration/savevm.c | 12 +++-
>  2 files changed, 24 insertions(+), 9 deletions(-)
> 
> --
> 2.9.3
> 
> 
> 

Re: [Qemu-devel] [PATCH 2/3] block: use BDRV_POLL_WHILE() in bdrv_rw_vmstate()

[Paolo Bonzini]

> I'm surprised at how many separate hangs we actually had!

Note that I have seen quite a few before, though I am not sure about
the details and the reproducibility.  The release/acquire was hidden
behind RFifoLock contention callbacks instead of BDRV_POLL_WHILE.

Paolo

> > 
> > Signed-off-by: Stefan Hajnoczi 
> > ---
> >  block/io.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> Reviewed-by: Eric Blake 
> 
> > 
> > diff --git a/block/io.c b/block/io.c
> > index cc56e90..f0041cd 100644
> > --- a/block/io.c
> > +++ b/block/io.c
> > @@ -2031,9 +2031,7 @@ bdrv_rw_vmstate(BlockDriverState *bs, QEMUIOVector
> > *qiov, int64_t pos,
> >  Coroutine *co = qemu_coroutine_create(bdrv_co_rw_vmstate_entry,
> >  );
> >  
> >  bdrv_coroutine_enter(bs, co);
> > -while (data.ret == -EINPROGRESS) {
> > -aio_poll(bdrv_get_aio_context(bs), true);
> > -}
> > +BDRV_POLL_WHILE(bs, data.ret == -EINPROGRESS);
> >  return data.ret;
> >  }
> 
> Do we have other culprits (not necessarily for vmsave, but for other
> situations), where we should be using BDRV_POLL_WHILE in separate
> patches? For example, a quick grep show that at least hw/9pfs/9p.c makes
> a direct call to aio_poll(,true) in a while loop.
> 
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.   +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
> 
> 

Re: [Qemu-devel] [PATCH 6/6] spapr: fix migration of ICP objects from/to older QEMU

[Greg Kurz]

On Wed, 17 May 2017 14:18:16 +1000
David Gibson  wrote:

> On Mon, May 15, 2017 at 06:11:27PM +0200, Cédric Le Goater wrote:
> > >>> +int smt = kvmppc_smt_threads();
> > >>> +int nr_servers = DIV_ROUND_UP(max_cpus * smt, smp_threads);
> > >>
> > >> may be we should reintroduce nr_servers at the machine level ? 
> > >>  
> > > 
> > > I had reintroduced it but then I realized it was only used in this
> > > function.  
> > 
> > nr_servers is also used when the device tree is populated with the 
> > interrupt controller nodes. No big deal.  
> 
> Which is guest visible, so we should really make that stay the same
> for older machine types.  I'd like to avoid re-introducing nr_servers
> as a property if we can, but maybe we can't.
> 

Yes we can :) or at least maybe, if you can shed light on a guest
visible change introduced by this commit in 2.8:

commit 9b9a19080a6e548b91420ce7925f2ac81ef63ae8
Author: David Gibson 
Date:   Thu Oct 20 16:07:56 2016 +1100

pseries: Move construction of /interrupt-controller fdt node


It changes the "ibm,interrupt-server-ranges" property in the device
tree from

{0, cpu_to_be32(max_cpus)}

to

{0, cpu_to_be32(xics->nr_servers)}

ie, {0, cpu_to_be32(DIV_ROUND_UP(max_cpus * smt, smp_threads))}

And indeed, if I start QEMU with

 -smp cores=2,threads=4,maxcpus=16 -machine type=pseries-2.7,accel=kvm

the following is exposed to the guest with 2.7:

ibm,interrupt-server-ranges
  0010

and with 2.8 we get:

ibm,interrupt-server-ranges
  0020

LoPAPR B.6.9.1.1 says that the range (ie, the second number) "shall be the
number of contiguous server#s supported by the unit (this also corresponds
to the number of “reg” entries)". I'm inclined to think this maps to max_cpus
but I may be wrong... any clues ?

Cheers,

--
Greg


pgpIaBt1hlddS.pgp
Description: OpenPGP digital signature

Re: [Qemu-devel] [Qemu-ppc] [PATCH v10] migration: spapr: migrate pending_events of spapr state

[Daniel Henrique Barboza]

On 05/16/2017 09:04 AM, Daniel Henrique Barboza wrote:



On 05/16/2017 01:25 AM, David Gibson wrote:

On Mon, May 15, 2017 at 10:10:52AM -0300, Daniel Henrique Barboza wrote:

From: Jianjun Duan 

In racing situations between hotplug events and migration operation,
a rtas hotplug event could have not yet be delivered to the source
guest when migration is started. In this case the pending_events of
spapr state need be transmitted to the target so that the hotplug
event can be finished on the target.

All the different fields of the events are encoded as defined by
PAPR. We can migrate them as uint8_t binary stream without any
concerns about data padding or endianess.

pending_events is put in a subsection in the spapr state VMSD to make
sure migration across different versions is not broken.

Signed-off-by: Jianjun Duan 
Signed-off-by: Daniel Henrique Barboza 

Ok, thanks for splitting this out, but you don't seem to have
addressed the other comments I had on this patch as presented before.


Sorry, I haven't noticed you had previous comments on this patch. I'll 
address

them and re-send.


Daniel




---
  hw/ppc/spapr.c | 33 +
  hw/ppc/spapr_events.c  | 24 +---
  include/hw/ppc/spapr.h |  3 ++-
  3 files changed, 48 insertions(+), 12 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 80d12d0..8cfdc71 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1437,6 +1437,38 @@ static bool version_before_3(void *opaque, 
int version_id)

  return version_id < 3;
  }
  +static bool spapr_pending_events_needed(void *opaque)
+{
+sPAPRMachineState *spapr = (sPAPRMachineState *)opaque;
+return !QTAILQ_EMPTY(>pending_events);
+}
+
+static const VMStateDescription vmstate_spapr_event_entry = {
+.name = "spapr_event_log_entry",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_INT32(log_type, sPAPREventLogEntry),
+VMSTATE_BOOL(exception, sPAPREventLogEntry),

I'd like some more information to convince me there isn't redundant
data here.

I'll quote David's v9 review here for reference:

"So, at the moment, AFAICT every event is marked as exception == true,
so this doesn't actually tell us anything.   If that becomes not the
case in future, can the exception flag be derived from the log_type or
information in the even buffer? "

I've checked the code and we're just using exception == true.  The two
event logs that we currently support are RTAS_LOG_TYPE_EPOW and
RTAS_LOG_TYPE_HOTPLUG, both are being added in the queue by
calling rtas_event_log_queue() with exception == true.

This boolean is passed as a parameter in the functions 
rtas_event_log_contains

and rtas_event_log_dequeue. The former is called once with exception=true
inside check_exception, the latter is called once with exception=true in 
check_exception

and exception=false in event_scan.

I didn't find anywhere in the code where, once set as true, we change 
this boolean
to false. So in my opinion we can discard this boolean from the 
migration and,

in post_load, set it to true if log_type is RTAS_LOG_TYPE_EPOW or
RTAS_LOG_TYPE_HOTPLUG. This would mean that when we implement more event
log types we will need to also change the post_load to reflect the change.



PS: I've read the LoPAPR document [1] and it says in section 10.2.3 page 
289:


"Hot Plug Events, when implemented, are reported through the event-scan 
RTAS call."


Why are we setting the RTAS_LOG_TYPE_HOTPLUG as exception==true and 
therefore
reporting it in check_exception instead? Does the sPAPR spec differ from 
the LoPAPR

in this regard?

[1] 
https://openpowerfoundation.org/wp-content/uploads/2016/05/LoPAPR_DRAFT_v11_24March2016_cmt1.pdf



Thanks,

Daniel


+VMSTATE_UINT32(data_size, sPAPREventLogEntry),
+VMSTATE_VARRAY_UINT32_ALLOC(data, sPAPREventLogEntry, 
data_size,

+0, vmstate_info_uint8, uint8_t),

And I think this should be VBUFFER rather than VARRAY to avoid the
data type change.


+VMSTATE_END_OF_LIST()
+},
+};
+
+static const VMStateDescription vmstate_spapr_pending_events = {
+.name = "spapr_pending_events",
+.version_id = 1,
+.minimum_version_id = 1,
+.needed = spapr_pending_events_needed,
+.fields = (VMStateField[]) {
+VMSTATE_QTAILQ_V(pending_events, sPAPRMachineState, 1,
+ vmstate_spapr_event_entry, 
sPAPREventLogEntry, next),

+VMSTATE_END_OF_LIST()
+},
+};
+
  static bool spapr_ov5_cas_needed(void *opaque)
  {
  sPAPRMachineState *spapr = opaque;
@@ -1535,6 +1567,7 @@ static const VMStateDescription vmstate_spapr = {
  .subsections = (const VMStateDescription*[]) {
  _spapr_ov5_cas,
  _spapr_patb_entry,
+_spapr_pending_events,
  NULL
  }
  };
diff --git 

Re: [Qemu-devel] [PATCH 3/3] migration: avoid recursive AioContext locking in save_vmstate()

[Eric Blake]

On 05/17/2017 12:09 PM, Stefan Hajnoczi wrote:
> AioContext was designed to allow nested acquire/release calls.  It uses
> a recursive mutex so callers don't need to worry about nesting...or so
> we thought.
> 
> BDRV_POLL_WHILE() is used to wait for block I/O requests.  It releases
> the AioContext temporarily around aio_poll().  This gives IOThreads a
> chance to acquire the AioContext to process I/O completions.
> 
> It turns out that recursive locking and BDRV_POLL_WHILE() don't mix.
> BDRV_POLL_WHILE() only releases the AioContext once, so the IOThread
> will not be able to acquire the AioContext if it was acquired
> multiple times.
> 
> Instead of trying to release AioContext n times in BDRV_POLL_WHILE(),
> this patch simply avoids nested locking in save_vmstate().  It's the
> simplest fix and we should step back to consider the big picture with
> all the recent changes to block layer threading.
> 
> This patch is the final fix to solve 'savevm' hanging with -object
> iothread.
> 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  migration/savevm.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 

Reviewed-by: Eric Blake 

-- 
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 2/3] block: use BDRV_POLL_WHILE() in bdrv_rw_vmstate()

[Eric Blake]

On 05/17/2017 12:09 PM, Stefan Hajnoczi wrote:
> Calling aio_poll() directly may have been fine previously, but this is
> the future, man!

lol

>  The difference between an aio_poll() loop and
> BDRV_POLL_WHILE() is that BDRV_POLL_WHILE() releases the AioContext
> around aio_poll().
> 
> This allows the IOThread to run fd handlers or BHs to complete the
> request.  Failure to release the AioContext causes deadlocks.
> 
> Using BDRV_POLL_WHILE() partially fixes a 'savevm' hang with -object
> iothread.

I'm surprised at how many separate hangs we actually had!

> 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  block/io.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

Reviewed-by: Eric Blake 

> 
> diff --git a/block/io.c b/block/io.c
> index cc56e90..f0041cd 100644
> --- a/block/io.c
> +++ b/block/io.c
> @@ -2031,9 +2031,7 @@ bdrv_rw_vmstate(BlockDriverState *bs, QEMUIOVector 
> *qiov, int64_t pos,
>  Coroutine *co = qemu_coroutine_create(bdrv_co_rw_vmstate_entry, 
> );
>  
>  bdrv_coroutine_enter(bs, co);
> -while (data.ret == -EINPROGRESS) {
> -aio_poll(bdrv_get_aio_context(bs), true);
> -}
> +BDRV_POLL_WHILE(bs, data.ret == -EINPROGRESS);
>  return data.ret;
>  }

Do we have other culprits (not necessarily for vmsave, but for other
situations), where we should be using BDRV_POLL_WHILE in separate
patches? For example, a quick grep show that at least hw/9pfs/9p.c makes
a direct call to aio_poll(,true) in a while loop.

-- 
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 1/3] block: count bdrv_co_rw_vmstate() requests

[Eric Blake]

On 05/17/2017 12:09 PM, Stefan Hajnoczi wrote:
> Call bdrv_inc/dec_in_flight() for vmstate reads/writes.  This seems
> unnecessary at first glance because vmstate reads/writes are done
> synchronously while the guest is stopped.  But we need the bdrv_wakeup()
> in bdrv_dec_in_flight() so the main loop sees request completion.
> Besides, it's cleaner to count vmstate reads/writes like ordinary
> read/write requests.
> 
> The bdrv_wakeup() partially fixes a 'savevm' hang with -object iothread.
> 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  block/io.c | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)

Reviewed-by: Eric Blake 

-- 
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 2/2] postcopy: Require RAMBlocks that are whole pages

[Juan Quintela]

"Dr. David Alan Gilbert (git)"  wrote:
> From: "Dr. David Alan Gilbert" 
>
> It turns out that it's legal to create a VM with RAMBlocks that aren't
> a multiple of the pagesize in use; e.g. a 1025M main memory using
> 2M host pages.  That breaks postcopy's atomic placement of pages,
> so disallow it.
>
> Signed-off-by: Dr. David Alan Gilbert 

Reviewed-by: Juan Quintela 


>  }
>  
>  /* We don't support postcopy with shared RAM yet */
> -if (qemu_ram_foreach_block(test_range_shared, NULL)) {
> +if (qemu_ram_foreach_block(test_ramblock_postcopiable, NULL)) {

When I was looking at this code, I still don't know why
qemu_ram_foreach_block() don't pass the block directly.  It needs it
almost all callers.

When I saw it I was about to change it, but got sidetracked on other
things :-p

Later, Juan.

Re: [Qemu-devel] [PATCH 1/2] migration: Fix non-multiple of page size migration

[Juan Quintela]

"Dr. David Alan Gilbert (git)"  wrote:
> From: "Dr. David Alan Gilbert" 
>
> Unfortunately it's legal to create a VM with a RAM size that's
> not a multiple of the underlying host page or huge page size.
> Recently I'd changed things to always send host sized pages,
> and that breaks if we have say a 1025MB guest on 2MB hugepages.
>
> Unfortunately we can't just make that illegal since it would break
> migration from/to existing oddly configured VMs.
>
> Symptom: qemu-system-x86_64: Illegal RAM offset 4010
>  as it transmits the fraction of the hugepage after the end
>  of the RAMBlock (may also cause a crash on the source
>  - possibly due to clearing bits after the bitmap)
>
> Reported-by:  Yumei Huang 
> Red Hat bug: https://bugzilla.redhat.com/show_bug.cgi?id=1449037
>
> Signed-off-by: Dr. David Alan Gilbert 


Reviewed-by: Juan Quintela 

We should really require for new machine types that ramblocks be
multiples of the page size.  This is just asking for trouble.

Re: [Qemu-devel] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.

[Eric Blake]

On 05/17/2017 01:34 PM, John Bradley wrote:
> This is especial true as I meant Andrew Baumann 0xabu (Andrew Baumann)

Top-posting is not nice on technical lists.

> 0xabu (Andrew Baumann)
>  0xabu has 3 repositories available. Follow their code on GitHub.  |   |

Using github requires the use of non-free (as in freedom) Javascript.
That's why this list prefers that all patches be sent through the list
as emails, not as github pull requests.  I'm not going to look at what
0xabu's repository contains, but rather at what you send through the
list. But part of the contract of Signed-off-by is that you have
permission to post the patch and agree to the license in use - which
means that if your work is a modified version of Andrew Baumann's work,
then you need Andrew Baumann's sign-off before you can add yours.

Other hints for better patch submission may be found here:
http://wiki.qemu.org/Contribute/SubmitAPatch

-- 
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] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.

[John Snow]

On 05/17/2017 02:27 PM, Eric Blake wrote:
> On 05/17/2017 01:09 PM, John Bradley via Qemu-devel wrote:
>> Also available at 
>>
>> https://www.dropbox.com/s/gwuquw0kirstw7a/0001-Add-Markus-Armbrusters-code-for-Broadcom-Perhiperals.patch?dl=0
> 
> This content belongs...
> 
>>
>> Following suggestions split my original patch up. This the largest 
>> monolithic chunk is 
>> additional BCM device support from Markus Armbruster.
>>
>>
>> >From 0b39a04030d5a2cea4fcd2159d365580ca155b78 Mon Sep 17 00:00:00 2001
>> From: John Bradley 
>> Date: Wed, 17 May 2017 18:57:21 +0100
>> Subject: [PATCH] Add Markus Armbrusters code for Broadcom Perhiperals for 
>> ARM.

Also, though your patch body says `Subject: [PATCH]`, your actual email
subject does not. It should so that the build bot and maintenance tools
can find it appropriately.

The next version of this that gets sent should also carry the 'v2' tag.

--js

>>
>> Signed-off-by: John Bradley 
> 
> I would expect that if some of this code was written by Markus, then it
> would carry his Signed-off-by.  Or, maybe you just mean that you are
> splitting your patch according to the device Markus gave (in which case,
> a Suggested-by: tag may be appropriate).  Either way, I don't see why
> Markus' name has to be in the subject line (the patch subject should be
> WHAT changed, not WHO suggested the change).
> 
>> ---
> 
> ...here, after the --- separator.  It is useful to reviewers, but should
> not end up as part of the actual commit message.
> 
>> hw/arm/Makefile.objs |2 +-
>> hw/arm/bcm2835.c |  114 
>> hw/arm/bcm2835_peripherals.c |  104 
>> hw/misc/Makefile.objs|2 +
>> hw/misc/bcm2835_mphi.c   |  163 ++
>> hw/misc/bcm2835_power.c  |  106 
>> hw/timer/Makefile.objs   |2 +
>> hw/timer/bcm2835_st.c|  202 +++
>> hw/timer/bcm2835_timer.c |  224 +++
>> hw/usb/Makefile.objs |4 +-
>> hw/usb/bcm2835_usb.c |  604 +++
>> hw/usb/bcm2835_usb_regs.h| 1061 
>> ++
> 
> That's still rather large to review in one chunk, especially while
> touching other files.   It can probably still be split up further.
> 
>> include/hw/arm/bcm2835.h |   37 ++
>> include/hw/arm/bcm2835_peripherals.h |   10 +
>> include/hw/intc/bcm2835_control.h|   53 ++
>> include/hw/misc/bcm2835_mphi.h   |   28 +
>> include/hw/misc/bcm2835_power.h  |   22 +
>> include/hw/timer/bcm2835_st.h|   25 +
>> include/hw/timer/bcm2835_timer.h |   32 +
>> include/hw/usb/bcm2835_usb.h |   78 +++
>> 20 files changed, 2871 insertions(+), 2 deletions(-)
>> create mode 100644 hw/arm/bcm2835.c
>> create mode 100644 hw/misc/bcm2835_mphi.c
>> create mode 100644 hw/misc/bcm2835_power.c
>> create mode 100644 hw/timer/bcm2835_st.c
>> create mode 100644 hw/timer/bcm2835_timer.c
>> create mode 100644 hw/usb/bcm2835_usb.c
>> create mode 100644 hw/usb/bcm2835_usb_regs.h
>> create mode 100644 include/hw/arm/bcm2835.h
>> create mode 100644 include/hw/intc/bcm2835_control.h
>> create mode 100644 include/hw/misc/bcm2835_mphi.h
>> create mode 100644 include/hw/misc/bcm2835_power.h
>> create mode 100644 include/hw/timer/bcm2835_st.h
>> create mode 100644 include/hw/timer/bcm2835_timer.h
>> create mode 100644 include/hw/usb/bcm2835_usb.h
>>
> 

Re: [Qemu-devel] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.

[John Bradley via Qemu-devel]

This is especial true as I meant Andrew Baumann 0xabu (Andrew Baumann)

  
|  
|   
|   
|   ||

   |

  |
|  
||  
0xabu (Andrew Baumann)
 0xabu has 3 repositories available. Follow their code on GitHub.  |   |

  |

  |

 

 John BradleyTel: 07896 839635Skype: flypie125 125B Grove StreetEdge Hill 
Liverpool L7 7AF 

On Wednesday, 17 May 2017, 19:27, Eric Blake  wrote:
 

 On 05/17/2017 01:09 PM, John Bradley via Qemu-devel wrote:
> Also available at 
> 
> https://www.dropbox.com/s/gwuquw0kirstw7a/0001-Add-Markus-Armbrusters-code-for-Broadcom-Perhiperals.patch?dl=0

This content belongs...

> 
> Following suggestions split my original patch up. This the largest monolithic 
> chunk is 
> additional BCM device support from Markus Armbruster.
> 
> 
>>From 0b39a04030d5a2cea4fcd2159d365580ca155b78 Mon Sep 17 00:00:00 2001
> From: John Bradley 
> Date: Wed, 17 May 2017 18:57:21 +0100
> Subject: [PATCH] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.
> 
> Signed-off-by: John Bradley 

I would expect that if some of this code was written by Markus, then it
would carry his Signed-off-by.  Or, maybe you just mean that you are
splitting your patch according to the device Markus gave (in which case,
a Suggested-by: tag may be appropriate).  Either way, I don't see why
Markus' name has to be in the subject line (the patch subject should be
WHAT changed, not WHO suggested the change).

> ---

...here, after the --- separator.  It is useful to reviewers, but should
not end up as part of the actual commit message.

> hw/arm/Makefile.objs                |    2 +-
> hw/arm/bcm2835.c                    |  114 
> hw/arm/bcm2835_peripherals.c        |  104 
> hw/misc/Makefile.objs                |    2 +
> hw/misc/bcm2835_mphi.c              |  163 ++
> hw/misc/bcm2835_power.c              |  106 
> hw/timer/Makefile.objs              |    2 +
> hw/timer/bcm2835_st.c                |  202 +++
> hw/timer/bcm2835_timer.c            |  224 +++
> hw/usb/Makefile.objs                |    4 +-
> hw/usb/bcm2835_usb.c                |  604 +++
> hw/usb/bcm2835_usb_regs.h            | 1061 ++

That's still rather large to review in one chunk, especially while
touching other files.  It can probably still be split up further.

> include/hw/arm/bcm2835.h            |  37 ++
> include/hw/arm/bcm2835_peripherals.h |  10 +
> include/hw/intc/bcm2835_control.h    |  53 ++
> include/hw/misc/bcm2835_mphi.h      |  28 +
> include/hw/misc/bcm2835_power.h      |  22 +
> include/hw/timer/bcm2835_st.h        |  25 +
> include/hw/timer/bcm2835_timer.h    |  32 +
> include/hw/usb/bcm2835_usb.h        |  78 +++
> 20 files changed, 2871 insertions(+), 2 deletions(-)
> create mode 100644 hw/arm/bcm2835.c
> create mode 100644 hw/misc/bcm2835_mphi.c
> create mode 100644 hw/misc/bcm2835_power.c
> create mode 100644 hw/timer/bcm2835_st.c
> create mode 100644 hw/timer/bcm2835_timer.c
> create mode 100644 hw/usb/bcm2835_usb.c
> create mode 100644 hw/usb/bcm2835_usb_regs.h
> create mode 100644 include/hw/arm/bcm2835.h
> create mode 100644 include/hw/intc/bcm2835_control.h
> create mode 100644 include/hw/misc/bcm2835_mphi.h
> create mode 100644 include/hw/misc/bcm2835_power.h
> create mode 100644 include/hw/timer/bcm2835_st.h
> create mode 100644 include/hw/timer/bcm2835_timer.h
> create mode 100644 include/hw/usb/bcm2835_usb.h
> 

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


   

Re: [Qemu-devel] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.

[Eric Blake]

On 05/17/2017 01:09 PM, John Bradley via Qemu-devel wrote:
> Also available at 
> 
> https://www.dropbox.com/s/gwuquw0kirstw7a/0001-Add-Markus-Armbrusters-code-for-Broadcom-Perhiperals.patch?dl=0

This content belongs...

> 
> Following suggestions split my original patch up. This the largest monolithic 
> chunk is 
> additional BCM device support from Markus Armbruster.
> 
> 
>>From 0b39a04030d5a2cea4fcd2159d365580ca155b78 Mon Sep 17 00:00:00 2001
> From: John Bradley 
> Date: Wed, 17 May 2017 18:57:21 +0100
> Subject: [PATCH] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.
> 
> Signed-off-by: John Bradley 

I would expect that if some of this code was written by Markus, then it
would carry his Signed-off-by.  Or, maybe you just mean that you are
splitting your patch according to the device Markus gave (in which case,
a Suggested-by: tag may be appropriate).  Either way, I don't see why
Markus' name has to be in the subject line (the patch subject should be
WHAT changed, not WHO suggested the change).

> ---

...here, after the --- separator.  It is useful to reviewers, but should
not end up as part of the actual commit message.

> hw/arm/Makefile.objs |2 +-
> hw/arm/bcm2835.c |  114 
> hw/arm/bcm2835_peripherals.c |  104 
> hw/misc/Makefile.objs|2 +
> hw/misc/bcm2835_mphi.c   |  163 ++
> hw/misc/bcm2835_power.c  |  106 
> hw/timer/Makefile.objs   |2 +
> hw/timer/bcm2835_st.c|  202 +++
> hw/timer/bcm2835_timer.c |  224 +++
> hw/usb/Makefile.objs |4 +-
> hw/usb/bcm2835_usb.c |  604 +++
> hw/usb/bcm2835_usb_regs.h| 1061 ++

That's still rather large to review in one chunk, especially while
touching other files.   It can probably still be split up further.

> include/hw/arm/bcm2835.h |   37 ++
> include/hw/arm/bcm2835_peripherals.h |   10 +
> include/hw/intc/bcm2835_control.h|   53 ++
> include/hw/misc/bcm2835_mphi.h   |   28 +
> include/hw/misc/bcm2835_power.h  |   22 +
> include/hw/timer/bcm2835_st.h|   25 +
> include/hw/timer/bcm2835_timer.h |   32 +
> include/hw/usb/bcm2835_usb.h |   78 +++
> 20 files changed, 2871 insertions(+), 2 deletions(-)
> create mode 100644 hw/arm/bcm2835.c
> create mode 100644 hw/misc/bcm2835_mphi.c
> create mode 100644 hw/misc/bcm2835_power.c
> create mode 100644 hw/timer/bcm2835_st.c
> create mode 100644 hw/timer/bcm2835_timer.c
> create mode 100644 hw/usb/bcm2835_usb.c
> create mode 100644 hw/usb/bcm2835_usb_regs.h
> create mode 100644 include/hw/arm/bcm2835.h
> create mode 100644 include/hw/intc/bcm2835_control.h
> create mode 100644 include/hw/misc/bcm2835_mphi.h
> create mode 100644 include/hw/misc/bcm2835_power.h
> create mode 100644 include/hw/timer/bcm2835_st.h
> create mode 100644 include/hw/timer/bcm2835_timer.h
> create mode 100644 include/hw/usb/bcm2835_usb.h
> 

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



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.

[John Bradley via Qemu-devel]

Also available at 

https://www.dropbox.com/s/gwuquw0kirstw7a/0001-Add-Markus-Armbrusters-code-for-Broadcom-Perhiperals.patch?dl=0

Following suggestions split my original patch up. This the largest monolithic 
chunk is 
additional BCM device support from Markus Armbruster.


>From 0b39a04030d5a2cea4fcd2159d365580ca155b78 Mon Sep 17 00:00:00 2001
From: John Bradley 
Date: Wed, 17 May 2017 18:57:21 +0100
Subject: [PATCH] Add Markus Armbrusters code for Broadcom Perhiperals for ARM.

Signed-off-by: John Bradley 
---
hw/arm/Makefile.objs |2 +-
hw/arm/bcm2835.c |  114 
hw/arm/bcm2835_peripherals.c |  104 
hw/misc/Makefile.objs|2 +
hw/misc/bcm2835_mphi.c   |  163 ++
hw/misc/bcm2835_power.c  |  106 
hw/timer/Makefile.objs   |2 +
hw/timer/bcm2835_st.c|  202 +++
hw/timer/bcm2835_timer.c |  224 +++
hw/usb/Makefile.objs |4 +-
hw/usb/bcm2835_usb.c |  604 +++
hw/usb/bcm2835_usb_regs.h| 1061 ++
include/hw/arm/bcm2835.h |   37 ++
include/hw/arm/bcm2835_peripherals.h |   10 +
include/hw/intc/bcm2835_control.h|   53 ++
include/hw/misc/bcm2835_mphi.h   |   28 +
include/hw/misc/bcm2835_power.h  |   22 +
include/hw/timer/bcm2835_st.h|   25 +
include/hw/timer/bcm2835_timer.h |   32 +
include/hw/usb/bcm2835_usb.h |   78 +++
20 files changed, 2871 insertions(+), 2 deletions(-)
create mode 100644 hw/arm/bcm2835.c
create mode 100644 hw/misc/bcm2835_mphi.c
create mode 100644 hw/misc/bcm2835_power.c
create mode 100644 hw/timer/bcm2835_st.c
create mode 100644 hw/timer/bcm2835_timer.c
create mode 100644 hw/usb/bcm2835_usb.c
create mode 100644 hw/usb/bcm2835_usb_regs.h
create mode 100644 include/hw/arm/bcm2835.h
create mode 100644 include/hw/intc/bcm2835_control.h
create mode 100644 include/hw/misc/bcm2835_mphi.h
create mode 100644 include/hw/misc/bcm2835_power.h
create mode 100644 include/hw/timer/bcm2835_st.h
create mode 100644 include/hw/timer/bcm2835_timer.h
create mode 100644 include/hw/usb/bcm2835_usb.h

diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 4c5c4ee76c..35b2da24f5 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -11,7 +11,7 @@ obj-y += armv7m.o exynos4210.o pxa2xx.o pxa2xx_gpio.o 
pxa2xx_pic.o
obj-$(CONFIG_DIGIC) += digic.o
obj-y += omap1.o omap2.o strongarm.o
obj-$(CONFIG_ALLWINNER_A10) += allwinner-a10.o cubieboard.o
-obj-$(CONFIG_RASPI) += bcm2835_peripherals.o bcm2836.o raspi.o
+obj-$(CONFIG_RASPI) += bcm2835.o bcm2835_peripherals.o bcm2836.o raspi.o
obj-$(CONFIG_STM32F205_SOC) += stm32f205_soc.o
obj-$(CONFIG_XLNX_ZYNQMP) += xlnx-zynqmp.o xlnx-ep108.o
obj-$(CONFIG_FSL_IMX25) += fsl-imx25.o imx25_pdk.o
diff --git a/hw/arm/bcm2835.c b/hw/arm/bcm2835.c
new file mode 100644
index 00..e5744c1620
--- /dev/null
+++ b/hw/arm/bcm2835.c
@@ -0,0 +1,114 @@
+/*
+ * Raspberry Pi emulation (c) 2012 Gregory Estrade
+ * Upstreaming code cleanup [including bcm2835_*] (c) 2013 Jan Petrous
+ *
+ * Rasperry Pi 2 emulation and refactoring Copyright (c) 2015, Microsoft
+ * Written by Andrew Baumann
+ *
+ * This code is licensed under the GNU GPLv2 and later.
+ */
+
+#include "qemu/osdep.h"
+#include "cpu.h"
+#include "hw/arm/bcm2835.h"
+#include "hw/arm/raspi_platform.h"
+#include "hw/sysbus.h"
+#include "exec/address-spaces.h"
+
+
+/* Peripheral base address seen by the CPU */
+#define BCM2835_PERI_BASE   0x2000
+
+static void bcm2835_init(Object *obj)
+{
+BCM2835State *s = BCM2835(obj);
+
+object_initialize(>cpus[0], sizeof(s->cpus[0]), "arm1176-" 
TYPE_ARM_CPU);
+object_property_add_child(obj, "cpu", OBJECT(>cpus[0]), _abort);
+
+object_initialize(>peripherals, sizeof(s->peripherals),
+  TYPE_BCM2835_PERIPHERALS);
+object_property_add_child(obj, "peripherals", OBJECT(>peripherals),
+  _abort);
+object_property_add_alias(obj, "board-rev", OBJECT(>peripherals),
+  "board-rev", _abort);
+object_property_add_alias(obj, "vcram-size", OBJECT(>peripherals),
+  "vcram-size", _abort);
+qdev_set_parent_bus(DEVICE(>peripherals), sysbus_get_default());
+}
+
+static void bcm2835_realize(DeviceState *dev, Error **errp)
+{
+BCM2835State *s = BCM2835(dev);
+Object *obj;
+Error *err = NULL;
+
+/* common peripherals from bcm2835 */
+obj = object_property_get_link(OBJECT(dev), "ram", );
+if (obj == NULL) {
+error_setg(errp, "%s: required ram link not found: %s",
+   __func__, error_get_pretty(err));
+return;
+}
+
+object_property_add_const_link(OBJECT(>peripherals), "ram", obj, );
+if (err) {
+error_propagate(errp, err);
+return;
+}
+
+

[Qemu-devel] [PULL 3/3] ramblock: add new hmp command "info ramblock"

[Dr. David Alan Gilbert (git)]

From: Peter Xu 

To dump information about ramblocks. It looks like:

(qemu) info ramblock
  Block NamePSize  Offset   Used
  Total
/objects/mem2 MiB  0x 0x8000 
0x8000
vga.vram4 KiB  0x8006 0x0100 
0x0100
/rom@etc/acpi/tables4 KiB  0x810b 0x0002 
0x0020
 pc.bios4 KiB  0x8000 0x0004 
0x0004
  :00:03.0/e1000.rom4 KiB  0x8107 0x0004 
0x0004
  pc.rom4 KiB  0x8004 0x0002 
0x0002
:00:02.0/vga.rom4 KiB  0x8106 0x0001 
0x0001
   /rom@etc/table-loader4 KiB  0x812b 0x1000 
0x1000
  /rom@etc/acpi/rsdp4 KiB  0x812b1000 0x1000 
0x1000

Ramblock is something hidden internally in QEMU implementation, and this
command should only be used by mostly QEMU developers on RAM stuff. It
is not a command suitable for QMP interface. So only HMP interface is
provided for it.

Reviewed-by: Dr. David Alan Gilbert 
Signed-off-by: Peter Xu 
Message-Id: <1494562661-9063-4-git-send-email-pet...@redhat.com>
Signed-off-by: Dr. David Alan Gilbert 
---
 exec.c | 22 ++
 hmp-commands-info.hx   | 14 ++
 hmp.c  |  6 ++
 hmp.h  |  1 +
 include/exec/ramlist.h |  1 +
 5 files changed, 44 insertions(+)

diff --git a/exec.c b/exec.c
index 50519ae2ab..821bef3476 100644
--- a/exec.c
+++ b/exec.c
@@ -71,6 +71,8 @@
 #include "qemu/mmap-alloc.h"
 #endif
 
+#include "monitor/monitor.h"
+
 //#define DEBUG_SUBPAGE
 
 #if !defined(CONFIG_USER_ONLY)
@@ -1333,6 +1335,26 @@ void qemu_mutex_unlock_ramlist(void)
 qemu_mutex_unlock(_list.mutex);
 }
 
+void ram_block_dump(Monitor *mon)
+{
+RAMBlock *block;
+char *psize;
+
+rcu_read_lock();
+monitor_printf(mon, "%24s %8s  %18s %18s %18s\n",
+   "Block Name", "PSize", "Offset", "Used", "Total");
+RAMBLOCK_FOREACH(block) {
+psize = size_to_str(block->page_size);
+monitor_printf(mon, "%24s %8s  0x%016" PRIx64 " 0x%016" PRIx64
+   " 0x%016" PRIx64 "\n", block->idstr, psize,
+   (uint64_t)block->offset,
+   (uint64_t)block->used_length,
+   (uint64_t)block->max_length);
+g_free(psize);
+}
+rcu_read_unlock();
+}
+
 #ifdef __linux__
 /*
  * FIXME TOCTTOU: this iterates over memory backends' mem-path, which
diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
index a53f105c52..ae169011b1 100644
--- a/hmp-commands-info.hx
+++ b/hmp-commands-info.hx
@@ -788,6 +788,20 @@ Display the latest dump status.
 ETEXI
 
 {
+.name   = "ramblock",
+.args_type  = "",
+.params = "",
+.help   = "Display system ramblock information",
+.cmd= hmp_info_ramblock,
+},
+
+STEXI
+@item info ramblock
+@findex ramblock
+Dump all the ramblocks of the system.
+ETEXI
+
+{
 .name   = "hotpluggable-cpus",
 .args_type  = "",
 .params = "",
diff --git a/hmp.c b/hmp.c
index 524e5890de..e0ba13cb12 100644
--- a/hmp.c
+++ b/hmp.c
@@ -39,6 +39,7 @@
 #include "qemu-io.h"
 #include "qemu/cutils.h"
 #include "qemu/error-report.h"
+#include "exec/ramlist.h"
 #include "hw/intc/intc.h"
 
 #ifdef CONFIG_SPICE
@@ -2738,6 +2739,11 @@ void hmp_info_dump(Monitor *mon, const QDict *qdict)
 qapi_free_DumpQueryResult(result);
 }
 
+void hmp_info_ramblock(Monitor *mon, const QDict *qdict)
+{
+ram_block_dump(mon);
+}
+
 void hmp_hotpluggable_cpus(Monitor *mon, const QDict *qdict)
 {
 Error *err = NULL;
diff --git a/hmp.h b/hmp.h
index 37bb65a850..d8b94ce9dc 100644
--- a/hmp.h
+++ b/hmp.h
@@ -140,6 +140,7 @@ void hmp_rocker_ports(Monitor *mon, const QDict *qdict);
 void hmp_rocker_of_dpa_flows(Monitor *mon, const QDict *qdict);
 void hmp_rocker_of_dpa_groups(Monitor *mon, const QDict *qdict);
 void hmp_info_dump(Monitor *mon, const QDict *qdict);
+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);
 
diff --git a/include/exec/ramlist.h b/include/exec/ramlist.h
index f1c6b45df9..2e2ac6cb99 100644
--- a/include/exec/ramlist.h
+++ b/include/exec/ramlist.h
@@ -73,5 +73,6 @@ void ram_block_notifier_remove(RAMBlockNotifier *n);
 void ram_block_notify_add(void *host, size_t size);
 void ram_block_notify_remove(void *host, size_t size);
 
+void ram_block_dump(Monitor *mon);
 
 #endif /* RAMLIST_H */
-- 
2.13.0

[Qemu-devel] [PULL 2/3] utils: provide size_to_str()

[Dr. David Alan Gilbert (git)]

From: Peter Xu 

Moving the algorithm from print_type_size() into size_to_str() so that
other component can also leverage it. With that, refactor
print_type_size().

The assert() in that logic is removed though, since even UINT64_MAX
would not overflow.

Signed-off-by: Peter Xu 
Message-Id: <1494562661-9063-3-git-send-email-pet...@redhat.com>
Reviewed-by: Markus Armbruster 
Signed-off-by: Dr. David Alan Gilbert 
---
 include/qemu-common.h|  1 +
 qapi/string-output-visitor.c | 22 ++
 util/cutils.c| 25 +
 3 files changed, 32 insertions(+), 16 deletions(-)

diff --git a/include/qemu-common.h b/include/qemu-common.h
index d218821c14..387ef520bf 100644
--- a/include/qemu-common.h
+++ b/include/qemu-common.h
@@ -145,6 +145,7 @@ void qemu_hexdump(const char *buf, FILE *fp, const char 
*prefix, size_t size);
 int parse_debug_env(const char *name, int max, int initial);
 
 const char *qemu_ether_ntoa(const MACAddr *mac);
+char *size_to_str(uint64_t val);
 void page_size_init(void);
 
 /* returns non-zero if dump is in progress, otherwise zero is
diff --git a/qapi/string-output-visitor.c b/qapi/string-output-visitor.c
index 94ac8211d1..53c2175d81 100644
--- a/qapi/string-output-visitor.c
+++ b/qapi/string-output-visitor.c
@@ -211,10 +211,8 @@ static void print_type_size(Visitor *v, const char *name, 
uint64_t *obj,
 Error **errp)
 {
 StringOutputVisitor *sov = to_sov(v);
-static const char suffixes[] = { 'B', 'K', 'M', 'G', 'T', 'P', 'E' };
-uint64_t div, val;
-char *out;
-int i;
+uint64_t val;
+char *out, *psize;
 
 if (!sov->human) {
 out = g_strdup_printf("%"PRIu64, *obj);
@@ -223,19 +221,11 @@ static void print_type_size(Visitor *v, const char *name, 
uint64_t *obj,
 }
 
 val = *obj;
-
-/* The exponent (returned in i) minus one gives us
- * floor(log2(val * 1024 / 1000).  The correction makes us
- * switch to the higher power when the integer part is >= 1000.
- */
-frexp(val / (1000.0 / 1024.0), );
-i = (i - 1) / 10;
-assert(i < ARRAY_SIZE(suffixes));
-div = 1ULL << (i * 10);
-
-out = g_strdup_printf("%"PRIu64" (%0.3g %c%s)", val,
-  (double)val/div, suffixes[i], i ? "iB" : "");
+psize = size_to_str(val);
+out = g_strdup_printf("%"PRIu64" (%s)", val, psize);
 string_output_set(sov, out);
+
+g_free(psize);
 }
 
 static void print_type_bool(Visitor *v, const char *name, bool *obj,
diff --git a/util/cutils.c b/util/cutils.c
index 50ad179dc5..1534682083 100644
--- a/util/cutils.c
+++ b/util/cutils.c
@@ -619,3 +619,28 @@ const char *qemu_ether_ntoa(const MACAddr *mac)
 
 return ret;
 }
+
+/*
+ * Return human readable string for size @val.
+ * @val can be anything that uint64_t allows (no more than "16 EiB").
+ * Use IEC binary units like KiB, MiB, and so forth.
+ * Caller is responsible for passing it to g_free().
+ */
+char *size_to_str(uint64_t val)
+{
+static const char *suffixes[] = { "", "Ki", "Mi", "Gi", "Ti", "Pi", "Ei" };
+unsigned long div;
+int i;
+
+/*
+ * The exponent (returned in i) minus one gives us
+ * floor(log2(val * 1024 / 1000).  The correction makes us
+ * switch to the higher power when the integer part is >= 1000.
+ * (see e41b509d68afb1f for more info)
+ */
+frexp(val / (1000.0 / 1024.0), );
+i = (i - 1) / 10;
+div = 1ULL << (i * 10);
+
+return g_strdup_printf("%0.3g %sB", (double)val / div, suffixes[i]);
+}
-- 
2.13.0

[Qemu-devel] [PULL 0/3] hmp queue

[Dr. David Alan Gilbert (git)]

From: "Dr. David Alan Gilbert" <dgilb...@redhat.com>

The following changes since commit cdece0467c7cf8e3f4b3c3f0b13bf2c4fea9:

  block/win32: fix 'ret not initialized' warning (2017-05-16 15:34:18 +0100)

are available in the git repository at:

  git://github.com/dagrh/qemu.git tags/pull-hmp-20170517

for you to fetch changes up to be9b23c4a539090da30b482015ee660850e8bb5f:

  ramblock: add new hmp command "info ramblock" (2017-05-17 17:31:16 +0100)


HMP pull


Peter Xu (3):
  ramblock: add RAMBLOCK_FOREACH()
  utils: provide size_to_str()
  ramblock: add new hmp command "info ramblock"

 exec.c   | 44 +---
 hmp-commands-info.hx | 14 ++
 hmp.c|  6 ++
 hmp.h|  1 +
 include/exec/ramlist.h   |  6 ++
 include/qemu-common.h|  1 +
 migration/ram.c  | 13 +++--
 qapi/string-output-visitor.c | 22 ++
 util/cutils.c| 25 +
 9 files changed, 99 insertions(+), 33 deletions(-)

[Qemu-devel] [PULL 1/3] ramblock: add RAMBLOCK_FOREACH()

[Dr. David Alan Gilbert (git)]

From: Peter Xu 

So that it can simplifies the iterators.

Reviewed-by: Dr. David Alan Gilbert 
Signed-off-by: Peter Xu 
Message-Id: <1494562661-9063-2-git-send-email-pet...@redhat.com>
Signed-off-by: Dr. David Alan Gilbert 
---
 exec.c | 22 +++---
 include/exec/ramlist.h |  5 +
 migration/ram.c| 13 +++--
 3 files changed, 23 insertions(+), 17 deletions(-)

diff --git a/exec.c b/exec.c
index eac6085760..50519ae2ab 100644
--- a/exec.c
+++ b/exec.c
@@ -978,7 +978,7 @@ static RAMBlock *qemu_get_ram_block(ram_addr_t addr)
 if (block && addr - block->offset < block->max_length) {
 return block;
 }
-QLIST_FOREACH_RCU(block, _list.blocks, next) {
+RAMBLOCK_FOREACH(block) {
 if (addr - block->offset < block->max_length) {
 goto found;
 }
@@ -1578,12 +1578,12 @@ static ram_addr_t find_ram_offset(ram_addr_t size)
 return 0;
 }
 
-QLIST_FOREACH_RCU(block, _list.blocks, next) {
+RAMBLOCK_FOREACH(block) {
 ram_addr_t end, next = RAM_ADDR_MAX;
 
 end = block->offset + block->max_length;
 
-QLIST_FOREACH_RCU(next_block, _list.blocks, next) {
+RAMBLOCK_FOREACH(next_block) {
 if (next_block->offset >= end) {
 next = MIN(next, next_block->offset);
 }
@@ -1609,7 +1609,7 @@ unsigned long last_ram_page(void)
 ram_addr_t last = 0;
 
 rcu_read_lock();
-QLIST_FOREACH_RCU(block, _list.blocks, next) {
+RAMBLOCK_FOREACH(block) {
 last = MAX(last, block->offset + block->max_length);
 }
 rcu_read_unlock();
@@ -1659,7 +1659,7 @@ void qemu_ram_set_idstr(RAMBlock *new_block, const char 
*name, DeviceState *dev)
 pstrcat(new_block->idstr, sizeof(new_block->idstr), name);
 
 rcu_read_lock();
-QLIST_FOREACH_RCU(block, _list.blocks, next) {
+RAMBLOCK_FOREACH(block) {
 if (block != new_block &&
 !strcmp(block->idstr, new_block->idstr)) {
 fprintf(stderr, "RAMBlock \"%s\" already registered, abort!\n",
@@ -1693,7 +1693,7 @@ size_t qemu_ram_pagesize_largest(void)
 RAMBlock *block;
 size_t largest = 0;
 
-QLIST_FOREACH_RCU(block, _list.blocks, next) {
+RAMBLOCK_FOREACH(block) {
 largest = MAX(largest, qemu_ram_pagesize(block));
 }
 
@@ -1839,7 +1839,7 @@ static void ram_block_add(RAMBlock *new_block, Error 
**errp)
  * QLIST (which has an RCU-friendly variant) does not have insertion at
  * tail, so save the last element in last_block.
  */
-QLIST_FOREACH_RCU(block, _list.blocks, next) {
+RAMBLOCK_FOREACH(block) {
 last_block = block;
 if (block->max_length < new_block->max_length) {
 break;
@@ -2021,7 +2021,7 @@ void qemu_ram_remap(ram_addr_t addr, ram_addr_t length)
 int flags;
 void *area, *vaddr;
 
-QLIST_FOREACH_RCU(block, _list.blocks, next) {
+RAMBLOCK_FOREACH(block) {
 offset = addr - block->offset;
 if (offset < block->max_length) {
 vaddr = ramblock_ptr(block, offset);
@@ -2167,7 +2167,7 @@ RAMBlock *qemu_ram_block_from_host(void *ptr, bool 
round_offset,
 goto found;
 }
 
-QLIST_FOREACH_RCU(block, _list.blocks, next) {
+RAMBLOCK_FOREACH(block) {
 /* This case append when the block is not mapped. */
 if (block->host == NULL) {
 continue;
@@ -2200,7 +2200,7 @@ RAMBlock *qemu_ram_block_by_name(const char *name)
 {
 RAMBlock *block;
 
-QLIST_FOREACH_RCU(block, _list.blocks, next) {
+RAMBLOCK_FOREACH(block) {
 if (!strcmp(name, block->idstr)) {
 return block;
 }
@@ -3424,7 +3424,7 @@ int qemu_ram_foreach_block(RAMBlockIterFunc func, void 
*opaque)
 int ret = 0;
 
 rcu_read_lock();
-QLIST_FOREACH_RCU(block, _list.blocks, next) {
+RAMBLOCK_FOREACH(block) {
 ret = func(block->idstr, block->host, block->offset,
block->used_length, opaque);
 if (ret) {
diff --git a/include/exec/ramlist.h b/include/exec/ramlist.h
index c59880de82..f1c6b45df9 100644
--- a/include/exec/ramlist.h
+++ b/include/exec/ramlist.h
@@ -4,6 +4,7 @@
 #include "qemu/queue.h"
 #include "qemu/thread.h"
 #include "qemu/rcu.h"
+#include "qemu/rcu_queue.h"
 
 typedef struct RAMBlockNotifier RAMBlockNotifier;
 
@@ -54,6 +55,10 @@ typedef struct RAMList {
 } RAMList;
 extern RAMList ram_list;
 
+/* Should be holding either ram_list.mutex, or the RCU lock. */
+#define  RAMBLOCK_FOREACH(block)  \
+QLIST_FOREACH_RCU(block, _list.blocks, next)
+
 void qemu_mutex_lock_ramlist(void);
 void qemu_mutex_unlock_ramlist(void);
 
diff --git a/migration/ram.c b/migration/ram.c
index 293d27ce83..d88afeaddd 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -648,7 +648,7 @@ uint64_t ram_pagesize_summary(void)
 RAMBlock *block;
 uint64_t summary = 0;
 
-

Re: [Qemu-devel] [Bug 1691379] [NEW] NetBSD evbmips64el port installation doesn't work with qemu-system-mips64el.

[Kamil Rytarowski]

On 17.05.2017 10:10, Thomas Huth wrote:
> On 17.05.2017 09:52, Utkarsh Anand wrote:
>> Public bug reported:
>>
>> I successfully installed the NetBSD evbmips64el port on gxemul but was
>> unable to install it on qemu. Trying to boot it on qemu takes me to the
>> 'db>' prompt. Here's the output and backtrace:
>>
>> panic: pcib_isa_intr_string: bogus isa irq 0x0
>> kernel: breakpoint trap
>> Stopped in pid 0.1 (system) at  netbsd:cpu_Debugger+0x4:jr  ra
>> bdslot: nop
>> db> bt
>> 0x805977f0: cpu_Debugger+4 
>> (63061,9000180003f8,6,804c2290) ra 8030acd0 sz 0
>> 0x805977f0: vpanic+158 (63061,9000180003f8,6,804c2290) 
>> ra 8030ad7c sz 64
>> 0x80597830: panic+34 (63061,803d65b0,0,40) ra 
>> 80109784 sz 96
>> 0x80597890: pcib_isa_intr_string+6c (63061,803d65b0,0,40) ra 
>> 80149bfc sz 16
>> 0x805978a0: uhci_pci_attach+16c (63061,803d65b0,0,40) ra 
>> 802f0400 sz 176
>> 0x80597950: config_attach_loc+1c8 (63061,803d65b0,0,40) ra 
>> 802f053c sz 64
>> 0x80597990: config_found_sm_loc+5c (63061,803d65b0,0,40) ra 
>> 80121354 sz 64
>> 0x805979d0: pci_probe_device+524 (63061,803d65b0,0,0) ra 
>> 80121548 sz 288
>> 0x80597af0: pci_enumerate_bus+1d0 (63061,803d65b0,0,0) ra 
>> 8012167c sz 160
>> 0x80597b90: pcirescan+5c (63061,803d65b0,0,0) ra 
>> 801218c4 sz 32
>> 0x80597bb0: pciattach+19c (63061,803d65b0,0,0) ra 
>> 802f0400 sz 80
>> 0x80597c00: config_attach_loc+1c8 (63061,803d65b0,0,0) ra 
>> 802f053c sz 64
>> 0x80597c40: config_found_sm_loc+5c (63061,803d65b0,0,0) ra 
>> 80108934 sz 64
>> 0x80597c80: gt_attach+7c (63061,803d65b0,0,0) ra 
>> 802f0400 sz 112   
>> 0x80597cf0: config_attach_loc+1c8 (63061,803d65b0,0,0) ra 
>> 802f053c sz 64
>> 0x80597d30: config_found_sm_loc+5c (63061,803d65b0,0,0) ra 
>> 801086ac sz 64
>> 0x80597d70: mainbus_attach+dc (63061,803d65b0,0,0) ra 
>> 802f0400 sz 96
>> 0x80597dd0: config_attach_loc+1c8 (63061,803d65b0,0,0) ra 
>> 80104bf8 sz 64
>> 0x80597e10: cpu_configure+28 (63061,803d65b0,0,0) ra 
>> 803d5f30 sz 16
>> 0x80597e20: main+3a0 (63061,803d65b0,0,0) ra 
>> 801000dc sz 128   
>> 0x80597ea0: kernel_text+dc (63061,803d65b0,0,0) ra 0 sz 0
>> User-level: pid 0.1
>>
>> Here's the command that I used:
>>
>> Build evbmips64el from source and then launch it from qemu (replace the
>> paths relative to your system):
>>
>> qemu-system-mips64el -cdrom
>> /extra/evbmips64/distrib/evbmips/cdroms/installcd/NetBSD-7.99.71
>> -evbmips-mips64el.iso -hda /extra/evbmips64.img -kernel
>> /extra/evbmips64/releasedir/evbmips/installation/netbsd-INSTALL_MALTA64
>> -nographic -M malta
>>
>> (I've decompressed the kernel)
>>
>> Here's the output for qemu-system-mips64el --version :
>>
>> QEMU emulator version 2.7.1(qemu-2.7.1-6.fc25), Copyright (c) 2003-2016
>> Fabrice Bellard and the QEMU Project developers
>>
>> This doesn't look like a NetBSD bug. I've attached a screenshot of the
>> working installation using gxemul in the attachments.
> 
> When reporting such issues, please always use the latest release of QEMU
> first, so could you please try again with the latest upstream release of
> QEMU (currently v2.9.0)? Thanks!
> 
>  Thomas
> 

7.99.71 is the most recent kernel ABI version (NetBSD-current).

Release engineering builds of NetBSD-current are hosted on nyftp.netbsd.org.

kernel:

http://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201705170540Z/evbmips-mips64el/installation/

installation medium:

http://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201705170540Z/images/

[In future there will be need to switch 201705170540Z to a newer
snapshot, as this one will be removed.]

I will have to a look tonight and try to reproduce locally (and take
MIPS 64-bit crash course).



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 13/17] qdev: use appropriate getter/setters type

[Markus Armbruster]

Marc-André Lureau  writes:

> Based on underlying property type, use the appropriate getters/setters.

How did you find the ones that need changing?

> Signed-off-by: Marc-André Lureau 
> ---
>  hw/i386/acpi-build.c  | 12 ++--
>  hw/pci-host/gpex.c|  2 +-
>  hw/pci-host/q35.c |  2 +-
>  hw/pci-host/xilinx-pcie.c |  2 +-
>  target/i386/cpu.c |  2 +-
>  5 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index 767da5d78e..1707fae9bf 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -149,21 +149,21 @@ static void acpi_get_pm_info(AcpiPmInfo *pm)
>  /* Fill in optional s3/s4 related properties */
>  o = object_property_get_qobject(obj, ACPI_PM_PROP_S3_DISABLED, NULL);
>  if (o) {
> -pm->s3_disabled = qnum_get_int(qobject_to_qnum(o), _abort);
> +pm->s3_disabled = qnum_get_uint(qobject_to_qnum(o), _abort);
>  } else {
>  pm->s3_disabled = false;
>  }
>  qobject_decref(o);
>  o = object_property_get_qobject(obj, ACPI_PM_PROP_S4_DISABLED, NULL);
>  if (o) {
> -pm->s4_disabled = qnum_get_int(qobject_to_qnum(o), _abort);
> +pm->s4_disabled = qnum_get_uint(qobject_to_qnum(o), _abort);
>  } else {
>  pm->s4_disabled = false;
>  }
>  qobject_decref(o);
>  o = object_property_get_qobject(obj, ACPI_PM_PROP_S4_VAL, NULL);
>  if (o) {
> -pm->s4_val = qnum_get_int(qobject_to_qnum(o), _abort);
> +pm->s4_val = qnum_get_uint(qobject_to_qnum(o), _abort);
>  } else {
>  pm->s4_val = false;
>  }

The getter and setter of properties ACPI_PM_PROP_S3_DISABLED,
ACPI_PM_PROP_S4_DISABLED and ACPI_PM_PROP_S4_VAL use visit_type_uint8().

object_property_get_qobject() uses this getter below the hood with a
QObject output visitor, to get the value into a QObject.  Since the
getter uses visit_type_uint8(), the QObject is a QNum with QNUM_U64.

The appropriate way to extract the QNum's value is qnum_get_uint().

Okay.

> @@ -499,7 +499,7 @@ static void build_append_pci_bus_devices(Aml 
> *parent_scope, PCIBus *bus,
>  
>  bsel = object_property_get_qobject(OBJECT(bus), ACPI_PCIHP_PROP_BSEL, 
> NULL);
>  if (bsel) {
> -int64_t bsel_val = qnum_get_int(qobject_to_qnum(bsel), _abort);
> +uint64_t bsel_val = qnum_get_uint(qobject_to_qnum(bsel), 
> _abort);
>  
>  aml_append(parent_scope, aml_name_decl("BSEL", aml_int(bsel_val)));
>  notify_method = aml_method("DVNT", 2, AML_NOTSERIALIZED);

Similar argument, only slightly more tricky, as the getter dereferences
a pointer.

> @@ -609,7 +609,7 @@ static void build_append_pci_bus_devices(Aml 
> *parent_scope, PCIBus *bus,
>  
>  /* If bus supports hotplug select it and notify about local events */
>  if (bsel) {
> -int64_t bsel_val = qnum_get_int(qobject_to_qnum(bsel), _abort);
> +uint64_t bsel_val = qnum_get_uint(qobject_to_qnum(bsel), 
> _abort);
>  aml_append(method, aml_store(aml_int(bsel_val), aml_name("BNUM")));
>  aml_append(method,
>  aml_call2("DVNT", aml_name("PCIU"), aml_int(1) /* Device Check 
> */)

Likewise (@bsel is the same as above).

> @@ -2590,7 +2590,7 @@ static bool acpi_get_mcfg(AcpiMcfgInfo *mcfg)
>  
>  o = object_property_get_qobject(pci_host, PCIE_HOST_MCFG_SIZE, NULL);
>  assert(o);
> -mcfg->mcfg_size = qnum_get_int(qobject_to_qnum(o), _abort);
> +mcfg->mcfg_size = qnum_get_uint(qobject_to_qnum(o), _abort);
>  qobject_decref(o);
>  return true;
>  }

Similar argument.

I suspect the hunk I challenged in PATCH 09 actually belongs here.

> diff --git a/hw/pci-host/gpex.c b/hw/pci-host/gpex.c
> index 66055ee5cc..8d3a64008c 100644
> --- a/hw/pci-host/gpex.c
> +++ b/hw/pci-host/gpex.c
> @@ -94,7 +94,7 @@ static void gpex_host_initfn(Object *obj)
>  
>  object_initialize(root, sizeof(*root), TYPE_GPEX_ROOT_DEVICE);
>  object_property_add_child(obj, "gpex_root", OBJECT(root), NULL);
> -qdev_prop_set_uint32(DEVICE(root), "addr", PCI_DEVFN(0, 0));
> +qdev_prop_set_int32(DEVICE(root), "addr", PCI_DEVFN(0, 0));
>  qdev_prop_set_bit(DEVICE(root), "multifunction", false);
>  }
>  

"addr" is a property of TYPE_PCI_DEVICE, defined with
DEFINE_PROP_PCI_DEVFN().  It's int32_t, even though only 8 bits are
used.  Okay.

> diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
> index 5438be8253..3cbe8cfcea 100644
> --- a/hw/pci-host/q35.c
> +++ b/hw/pci-host/q35.c
> @@ -173,7 +173,7 @@ static void q35_host_initfn(Object *obj)
>  
>  object_initialize(>mch, sizeof(s->mch), TYPE_MCH_PCI_DEVICE);
>  object_property_add_child(OBJECT(s), "mch", OBJECT(>mch), NULL);
> -qdev_prop_set_uint32(DEVICE(>mch), "addr", PCI_DEVFN(0, 0));
> +qdev_prop_set_int32(DEVICE(>mch), "addr", PCI_DEVFN(0, 0));
>  qdev_prop_set_bit(DEVICE(>mch), "multifunction", 

Re: [Qemu-devel] [PATCH v2] ui: egl-headless requires dmabuf support

[Philippe Mathieu-Daudé]

On 05/17/2017 09:27 AM, Gerd Hoffmann wrote:

Reported-by: Thomas Huth 
Signed-off-by: Gerd Hoffmann 


Reviewed-by: Philippe Mathieu-Daudé 


---
 vl.c | 4 ++--
 ui/Makefile.objs | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/vl.c b/vl.c
index 5c9b40eb1c..2d7aeec186 100644
--- a/vl.c
+++ b/vl.c
@@ -2129,7 +2129,7 @@ static DisplayType select_display(const char *p)
 exit(1);
 }
 } else if (strstart(p, "egl-headless", )) {
-#ifdef CONFIG_OPENGL
+#ifdef CONFIG_OPENGL_DMABUF
 request_opengl = 1;
 display_opengl = 1;
 display = DT_EGL;
@@ -4668,7 +4668,7 @@ int main(int argc, char **argv, char **envp)
 qemu_spice_display_init();
 }

-#ifdef CONFIG_OPENGL
+#ifdef CONFIG_OPENGL_DMABUF
 if (display_type == DT_EGL) {
 egl_headless_init();
 }
diff --git a/ui/Makefile.objs b/ui/Makefile.objs
index aac6ae8bef..3369451285 100644
--- a/ui/Makefile.objs
+++ b/ui/Makefile.objs
@@ -33,7 +33,7 @@ common-obj-y += shader.o
 common-obj-y += console-gl.o
 common-obj-y += egl-helpers.o
 common-obj-y += egl-context.o
-common-obj-y += egl-headless.o
+common-obj-$(CONFIG_OPENGL_DMABUF) += egl-headless.o
 ifeq ($(CONFIG_GTK_GL),y)
 common-obj-$(CONFIG_GTK) += gtk-gl-area.o
 else

Re: [Qemu-devel] [PATCH v2] .gdbinit: load QEMU sub-commands when gdb starts

[Philippe Mathieu-Daudé]

On 05/17/2017 09:40 AM, Stefan Hajnoczi wrote:

The scripts/qemu-gdb.py file is not easily discoverable.  Add a .gdbinit
file so GDB either loads qemu-gdb.py automatically or prints a message
informing the user how to enable them (some systems disable ./.gdbinit
loading for security reasons).

Symlink .gdbinit and the scripts directory in order to make out-of-tree
builds work.  The scripts directory is used to find the qemu-gdb.py file
specified by a relative path in .gdbinit.

Suggested-by: Eric Blake 
Signed-off-by: Stefan Hajnoczi 


Reviewed-by: Philippe Mathieu-Daudé 


---
v2:
 * Support out-of-tree builds [Daniel, Markus]

 configure | 1 +
 .gdbinit  | 8 
 2 files changed, 9 insertions(+)
 create mode 100644 .gdbinit

diff --git a/configure b/configure
index 57b5ae6..04f7272 100755
--- a/configure
+++ b/configure
@@ -6382,6 +6382,7 @@ FILES="$FILES pc-bios/spapr-rtas/Makefile"
 FILES="$FILES pc-bios/s390-ccw/Makefile"
 FILES="$FILES roms/seabios/Makefile roms/vgabios/Makefile"
 FILES="$FILES pc-bios/qemu-icon.bmp"
+FILES="$FILES .gdbinit scripts" # scripts needed by relative path in .gdbinit
 for bios_file in \
 $source_path/pc-bios/*.bin \
 $source_path/pc-bios/*.lid \
diff --git a/.gdbinit b/.gdbinit
new file mode 100644
index 000..9d322fc
--- /dev/null
+++ b/.gdbinit
@@ -0,0 +1,8 @@
+# GDB may have ./.gdbinit loading disabled by default.  In that case you can
+# follow the instructions it prints.  They boil down to adding the following to
+# your home directory's ~/.gdbinit file:
+#
+#   add-auto-load-safe-path /path/to/qemu/.gdbinit
+
+# Load QEMU-specific sub-commands and settings
+source scripts/qemu-gdb.py

Re: [Qemu-devel] [PATCH v4 2/3] net/rocker: Plug memory leak in pci_rocker_init()

[Philippe Mathieu-Daudé]

Hi Mao,

On 05/17/2017 08:12 AM, Mao Zhongyi wrote:

pci_rocker_init() leaks a World when the name more than 9 chars,
then return a negative value directly, doesn't make a correct
cleanup. So add a new goto label to fix it.

Cc: jasow...@redhat.com
Cc: j...@resnulli.us
Cc: f4...@amsat.org
Cc: arm...@redhat.com
Signed-off-by: Mao Zhongyi 
---
 hw/net/rocker/rocker.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/net/rocker/rocker.c b/hw/net/rocker/rocker.c
index b2b6dc7..a382a6f 100644
--- a/hw/net/rocker/rocker.c
+++ b/hw/net/rocker/rocker.c
@@ -1371,7 +1371,8 @@ static int pci_rocker_init(PCIDevice *dev)
 fprintf(stderr,


While here can you update fprintf -> qemu_log_mask?


 "rocker: name too long; please shorten to at most %d chars\n",
 MAX_ROCKER_NAME_LEN);
-return -EINVAL;
+err = -EINVAL;
+goto err_name_too_long;
 }

 if (memcmp(>fp_start_macaddr, , sizeof(zero)) == 0) {
@@ -1430,6 +1431,7 @@ static int pci_rocker_init(PCIDevice *dev)

 return 0;

+err_name_too_long:
 err_duplicate:
 rocker_msix_uninit(r);
 err_msix_init:

[Qemu-devel] [PATCH 2/3] block: use BDRV_POLL_WHILE() in bdrv_rw_vmstate()

[Stefan Hajnoczi]

Calling aio_poll() directly may have been fine previously, but this is
the future, man!  The difference between an aio_poll() loop and
BDRV_POLL_WHILE() is that BDRV_POLL_WHILE() releases the AioContext
around aio_poll().

This allows the IOThread to run fd handlers or BHs to complete the
request.  Failure to release the AioContext causes deadlocks.

Using BDRV_POLL_WHILE() partially fixes a 'savevm' hang with -object
iothread.

Signed-off-by: Stefan Hajnoczi 
---
 block/io.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/block/io.c b/block/io.c
index cc56e90..f0041cd 100644
--- a/block/io.c
+++ b/block/io.c
@@ -2031,9 +2031,7 @@ bdrv_rw_vmstate(BlockDriverState *bs, QEMUIOVector *qiov, 
int64_t pos,
 Coroutine *co = qemu_coroutine_create(bdrv_co_rw_vmstate_entry, );
 
 bdrv_coroutine_enter(bs, co);
-while (data.ret == -EINPROGRESS) {
-aio_poll(bdrv_get_aio_context(bs), true);
-}
+BDRV_POLL_WHILE(bs, data.ret == -EINPROGRESS);
 return data.ret;
 }
 }
-- 
2.9.3

[Qemu-devel] [PATCH 1/3] block: count bdrv_co_rw_vmstate() requests

[Stefan Hajnoczi]

Call bdrv_inc/dec_in_flight() for vmstate reads/writes.  This seems
unnecessary at first glance because vmstate reads/writes are done
synchronously while the guest is stopped.  But we need the bdrv_wakeup()
in bdrv_dec_in_flight() so the main loop sees request completion.
Besides, it's cleaner to count vmstate reads/writes like ordinary
read/write requests.

The bdrv_wakeup() partially fixes a 'savevm' hang with -object iothread.

Signed-off-by: Stefan Hajnoczi 
---
 block/io.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/block/io.c b/block/io.c
index fdd7485..cc56e90 100644
--- a/block/io.c
+++ b/block/io.c
@@ -1988,17 +1988,24 @@ bdrv_co_rw_vmstate(BlockDriverState *bs, QEMUIOVector 
*qiov, int64_t pos,
bool is_read)
 {
 BlockDriver *drv = bs->drv;
+int ret = -ENOTSUP;
+
+bdrv_inc_in_flight(bs);
 
 if (!drv) {
-return -ENOMEDIUM;
+ret = -ENOMEDIUM;
 } else if (drv->bdrv_load_vmstate) {
-return is_read ? drv->bdrv_load_vmstate(bs, qiov, pos)
-   : drv->bdrv_save_vmstate(bs, qiov, pos);
+if (is_read) {
+ret = drv->bdrv_load_vmstate(bs, qiov, pos);
+} else {
+ret = drv->bdrv_save_vmstate(bs, qiov, pos);
+}
 } else if (bs->file) {
-return bdrv_co_rw_vmstate(bs->file->bs, qiov, pos, is_read);
+ret = bdrv_co_rw_vmstate(bs->file->bs, qiov, pos, is_read);
 }
 
-return -ENOTSUP;
+bdrv_dec_in_flight(bs);
+return ret;
 }
 
 static void coroutine_fn bdrv_co_rw_vmstate_entry(void *opaque)
-- 
2.9.3

[Qemu-devel] [PATCH 0/3] block: fix 'savevm' hang with -object iothread

[Stefan Hajnoczi]

The 'savevm' command hangs when -object iothread is used.  See patches for
details, but basically the vmstate read/write code didn't conform to the latest
block layer locking rules.

Stefan Hajnoczi (3):
  block: count bdrv_co_rw_vmstate() requests
  block: use BDRV_POLL_WHILE() in bdrv_rw_vmstate()
  migration: avoid recursive AioContext locking in save_vmstate()

 block/io.c | 21 +
 migration/savevm.c | 12 +++-
 2 files changed, 24 insertions(+), 9 deletions(-)

-- 
2.9.3

[Qemu-devel] [PATCH 3/3] migration: avoid recursive AioContext locking in save_vmstate()

[Stefan Hajnoczi]

AioContext was designed to allow nested acquire/release calls.  It uses
a recursive mutex so callers don't need to worry about nesting...or so
we thought.

BDRV_POLL_WHILE() is used to wait for block I/O requests.  It releases
the AioContext temporarily around aio_poll().  This gives IOThreads a
chance to acquire the AioContext to process I/O completions.

It turns out that recursive locking and BDRV_POLL_WHILE() don't mix.
BDRV_POLL_WHILE() only releases the AioContext once, so the IOThread
will not be able to acquire the AioContext if it was acquired
multiple times.

Instead of trying to release AioContext n times in BDRV_POLL_WHILE(),
this patch simply avoids nested locking in save_vmstate().  It's the
simplest fix and we should step back to consider the big picture with
all the recent changes to block layer threading.

This patch is the final fix to solve 'savevm' hanging with -object
iothread.

Signed-off-by: Stefan Hajnoczi 
---
 migration/savevm.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/migration/savevm.c b/migration/savevm.c
index 7f66d58..a70ba20 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -2153,6 +2153,14 @@ int save_vmstate(const char *name)
 goto the_end;
 }
 
+/* The bdrv_all_create_snapshot() call that follows acquires the AioContext
+ * for itself.  BDRV_POLL_WHILE() does not support nested locking because
+ * it only releases the lock once.  Therefore synchronous I/O will deadlock
+ * unless we release the AioContext before bdrv_all_create_snapshot().
+ */
+aio_context_release(aio_context);
+aio_context = NULL;
+
 ret = bdrv_all_create_snapshot(sn, bs, vm_state_size, );
 if (ret < 0) {
 error_report("Error while creating snapshot on '%s'",
@@ -2163,7 +2171,9 @@ int save_vmstate(const char *name)
 ret = 0;
 
  the_end:
-aio_context_release(aio_context);
+if (aio_context) {
+aio_context_release(aio_context);
+}
 if (saved_vm_running) {
 vm_start();
 }
-- 
2.9.3

Re: [Qemu-devel] [PATCH v4 4/4] fsdev: QMP interface for throttling

[Eric Blake]

On 05/17/2017 11:29 AM, Greg Kurz wrote:

>>
>> First point: is fsdev a Linux-only feature, or can it be compiled on
>> BSD?  If it is Linux-only, then compiling a stub for Windows will still
>> leave BSD broken, and your #ifdef is wrong.  Fixing compilation on mingw
>> is nice, but not the only platform to worry about.
>>
> 
> fsdev compilation currently depends on CONFIG_VIRTFS which is a Linux-only
> feature for the moment. There was a tentative to support it on Windows hosts
> two years ago but it stayed at the RFC stage.
> 
> But even on Linux hosts, the current fsdev implementation also depends on
> the target supporting PCI and VIRTIO. We have a fsdev/qemu-fsdev-dummy.c
> file to put stubs so that we don't pull all the code for such targets.
> 
> Maybe this could be reused for the above stubs as well ?

That helps.  The stub should live in qemu-fsdev-dummy.c (where it
shouldn't need any #ifdef, because that file is only compiled when the
condition is false), and...

> 
>> Second point: if fsdev is indeed a platform-specific feature, then we
>> don't want to advertise the QMP commands that are useless when running
>> on a platform that doesn't support it. Anywhere you have to add a stub
>> for compilation means you ALSO need to patch monitor.c to unregister the
>> command from being advertised as a valid QMP command.  (If you used
>> #ifdef __LINUX__ to guard the working version, and #ifndef __LINUX__ to
>> declare the stub, then the monitor.c needs an #ifndef section within
>> qmp_unregister_commands_hack() to tell QMP to not advertise the stubs.)

monitor.c should wrap the unregister under #ifndef CONFIG_VIRTFS (rather
than a particular platform name).

-- 
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 v1] target/s390x: Add support for the TEST BLOCK instruction

[David Hildenbrand]

On 17.05.2017 18:05, Thomas Huth wrote:
> On 16.05.2017 21:06, Richard Henderson wrote:
>> On 05/16/2017 02:28 AM, Thomas Huth wrote:
>>> +void HELPER(testblock)(CPUS390XState *env, uint64_t addr)
>>> +{
>>> +CPUState *cs = CPU(s390_env_get_cpu(env));
>>> +int i;
>>> +
>>> +addr = get_address(env, 0, 0, addr) & ~0xfffULL;
>>> +for (i = 0; i < TARGET_PAGE_SIZE; i += 8) {
>>> +stq_phys(cs->as, addr + i, 0);
>>> +}
>>> +env->cc_op = 0;
>>> +}
>>
>> This needs several changes: check that the physical page does indeed
>> exist, "low address protection", return the cc code.
> 
> Ok, ... but if we care about "low address protection", shouldn't we also
> add that to the other CPU instructions, too? (As far as I can see, it is
> not supported by the TCG code at all yet)

The same should be true for storage key checks, right? I think there are
a lot of such checks missing.


-- 

Thanks,

David

Re: [Qemu-devel] [PATCH 2/5] migration: Create block capability

[Juan Quintela]

Eric Blake  wrote:
> On 05/17/2017 10:38 AM, Juan Quintela wrote:
>> Create one capability for block migration and one parameter for
>> incremental block migration.
>> 
>> Signed-off-by: Juan Quintela 
>> 
>> ---
>> 
>> @@ -1207,6 +1242,26 @@ void qmp_migrate(const char *uri, bool has_blk, bool 
>> blk,
>>  return;
>>  }
>>  
>> +if (((has_blk && blk) || (has_inc && inc))
>> +&& (migrate_use_block() || migrate_use_block_incremental())) {
>> +error_setg(errp, "Command options are incompatible with current "
>> +   "migration capabilities");
>> +return;
>> +}
>> +
>> +if ((has_blk && blk) || (has_inc & inc)) {
>> +migrate_set_block_enabled(true, _err);
>> +if (local_err) {
>> +error_propagate(errp, local_err);
>> +return;
>> +}
>> +s->must_remove_block_options = true;
>> +}
>
> You wrote:
> if (A && B) {
>   error;
> }
> if (A) {
>   stuff;
> }
>
> I might have done:
>
> if (A) {
>   if (B) {
> error;
>   }
>   stuff;
> }
>
> but it's the same either way.

One less line, and as I have to respin due to the last patch.

>> +++ b/qapi-schema.json
>> @@ -894,11 +894,18 @@
>>  # @release-ram: if enabled, qemu will free the migrated ram pages on the 
>> source
>>  #during postcopy-ram migration. (since 2.9)
>>  #
>> +# @block: If enabled, QEMU will also migrate the contents of all block
>> +#  devices.  Default is disabled.  A possible alternative are
>
> s/are/uses/

done

>> +#  mirror jobs to a builtin NBD server on the destination, which
>> +#  are more flexible.
>
> s/are more flexible/offers more flexibility/

done

>> +#  (Since 2.10)
>> +#
>>  # Since: 1.2
>>  ##
>>  { 'enum': 'MigrationCapability',
>>'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
>> -   'compress', 'events', 'postcopy-ram', 'x-colo', 'release-ram'] }
>> +   'compress', 'events', 'postcopy-ram', 'x-colo', 'release-ram',
>> +   'block' ] }
>>  
>
> The grammar touchups can be done in preparing the pull request, if there
> is no other reason for a respin.
>
> Reviewed-by: Eric Blake 

Thanks, Juan.

Re: [Qemu-devel] [PATCH] Memory: use memory address space for cpu-memory

[Xu, Anthony]

> > If cpu-memory address space is same as memory address space,
> > use memory address space for cpu-memory address space.
> >
> > any memory region change causeaddress space to rebuild PhysPageMap,
> > rebuilding PhysPageMap is very expensive.
> >
> > removing cpu-memory address space reduces the guest boot time and
> > memory usage.
> >
> > Signed-off-by: Anthony Xu 
> > ---
> >  cpus.c | 9 +++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/cpus.c b/cpus.c
> > index 740b8dc..15c7a6a 100644
> > --- a/cpus.c
> > +++ b/cpus.c
> > @@ -1748,8 +1748,13 @@ void qemu_init_vcpu(CPUState *cpu)
> >  /* If the target cpu hasn't set up any address spaces itself,
> >   * give it the default one.
> >   */
> > -AddressSpace *as = address_space_init_shareable(cpu->memory,
> > -"cpu-memory");
> > +AddressSpace *as;
> > +if (cpu->memory == address_space_memory.root) {
> > +address_space_memory.ref_count++;
> probably this would cause reference leak when vcpu is destroyed

I thought address_space_destroy is called when vcpu is unplugged,
seems that's not the case, then ref_count++ is not needed.

Any other comments?


Thanks,
Anthony

[Qemu-devel] [PATCH 2/2] postcopy: Require RAMBlocks that are whole pages

[Dr. David Alan Gilbert (git)]

From: "Dr. David Alan Gilbert" 

It turns out that it's legal to create a VM with RAMBlocks that aren't
a multiple of the pagesize in use; e.g. a 1025M main memory using
2M host pages.  That breaks postcopy's atomic placement of pages,
so disallow it.

Signed-off-by: Dr. David Alan Gilbert 
---
 migration/postcopy-ram.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
index cdadaf6578..e8f43e7bd1 100644
--- a/migration/postcopy-ram.c
+++ b/migration/postcopy-ram.c
@@ -96,14 +96,24 @@ static bool ufd_version_check(int ufd)
 
 /* Callback from postcopy_ram_supported_by_host block iterator.
  */
-static int test_range_shared(const char *block_name, void *host_addr,
+static int test_ramblock_postcopiable(const char *block_name, void *host_addr,
  ram_addr_t offset, ram_addr_t length, void 
*opaque)
 {
-if (qemu_ram_is_shared(qemu_ram_block_by_name(block_name))) {
+RAMBlock *rb = qemu_ram_block_by_name(block_name);
+size_t pagesize = qemu_ram_pagesize(rb);
+
+if (qemu_ram_is_shared(rb)) {
 error_report("Postcopy on shared RAM (%s) is not yet supported",
  block_name);
 return 1;
 }
+
+if (length % pagesize) {
+error_report("Postcopy requires RAM blocks to be a page size multiple,"
+ " block %s is 0x" RAM_ADDR_FMT " bytes with a "
+ "page size of 0x%zx", block_name, length, pagesize);
+return 1;
+}
 return 0;
 }
 
@@ -140,7 +150,7 @@ bool postcopy_ram_supported_by_host(void)
 }
 
 /* We don't support postcopy with shared RAM yet */
-if (qemu_ram_foreach_block(test_range_shared, NULL)) {
+if (qemu_ram_foreach_block(test_ramblock_postcopiable, NULL)) {
 goto out;
 }
 
-- 
2.13.0

[Qemu-devel] [PATCH 1/2] migration: Fix non-multiple of page size migration

[Dr. David Alan Gilbert (git)]

From: "Dr. David Alan Gilbert" 

Unfortunately it's legal to create a VM with a RAM size that's
not a multiple of the underlying host page or huge page size.
Recently I'd changed things to always send host sized pages,
and that breaks if we have say a 1025MB guest on 2MB hugepages.

Unfortunately we can't just make that illegal since it would break
migration from/to existing oddly configured VMs.

Symptom: qemu-system-x86_64: Illegal RAM offset 4010
 as it transmits the fraction of the hugepage after the end
 of the RAMBlock (may also cause a crash on the source
 - possibly due to clearing bits after the bitmap)

Reported-by:  Yumei Huang 
Red Hat bug: https://bugzilla.redhat.com/show_bug.cgi?id=1449037

Signed-off-by: Dr. David Alan Gilbert 
---
 migration/ram.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/migration/ram.c b/migration/ram.c
index 293d27ce83..cea8924c02 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -1305,6 +1305,8 @@ static int ram_save_target_page(RAMState *rs, 
PageSearchStatus *pss,
  * a host page in which case the remainder of the hostpage is sent.
  * Only dirty target pages are sent. Note that the host page size may
  * be a huge page for this block.
+ * The saving stops at the boundary of the used_length of the block
+ * if the RAMBlock isn't a multiple of the host page size.
  *
  * Returns the number of pages written or negative on error
  *
@@ -1328,7 +1330,8 @@ static int ram_save_host_page(RAMState *rs, 
PageSearchStatus *pss,
 
 pages += tmppages;
 pss->page++;
-} while (pss->page & (pagesize_bits - 1));
+} while ((pss->page & (pagesize_bits - 1)) &&
+ offset_in_ramblock(pss->block, pss->page << TARGET_PAGE_BITS));
 
 /* The offset we leave with is the last one we looked at */
 pss->page--;
-- 
2.13.0

[Qemu-devel] [PATCH 0/2] Migration+huge page fixes

[Dr. David Alan Gilbert (git)]

From: "Dr. David Alan Gilbert" 

Hi,
  The attached patch-pair fix migration in the case
where you are using huge pages but you have a RAM size
which is not a multiple of the huge page size.
It's unfortunately legal so there might be VMs out there
that already have it, and it turns out it used to work,
but it broke, probably when I added the support for hugepages
in postcopy.

Here I:
   a) Fix it for normal migration
   b) Ban it for postcopy, since postcopy+hugepage was new
 recently anyway and it's a non-trivial fix.

Dave

Dr. David Alan Gilbert (2):
  migration: Fix non-multiple of page size migration
  postcopy: Require RAMBlocks that are whole pages

 migration/postcopy-ram.c | 16 +---
 migration/ram.c  |  5 -
 2 files changed, 17 insertions(+), 4 deletions(-)

-- 
2.13.0

Re: [Qemu-devel] [RFC PATCH] target/s390x/cpu_models: Set some additional feature bits for the "qemu" CPU

[David Hildenbrand]

On 17.05.2017 17:35, Thomas Huth wrote:
> Currently we only present the plain z900 feature bits to the guest,
> but QEMU already emulates some additional features (but not all of
> the next CPU generation, so we can not use the next CPU level as
> default yet). Since newer Linux kernels are checking the feature bits
> and refuse to work if a required feature is missing, we should present
> as much of the supported features as possible when we are running
> with the default "qemu" CPU.
> This patch now adds the "stfle", "extended immediate" and "stckf"
> facility bits to the "qemu" CPU, which are already supported facilities.
> It is unfortunately still not enough to run e.g. recent Fedora kernels,
> but at least it's a first step into the right direction.
> 

Three things:

1. Should we care about backwards compatibility? I think so. This should
be fixed up using compat machine properties. (qemu model is a
migration-safe model and could e.g. be used in KVM setups, too).

2. I would recommend to not enable STFLE for now. Why?

It is/was an indication that the system is running on a z9 (and
implicitly has the basic features). This was not only done because
people were lazy, but because this bit was implicitly connected to other
machine properties.

One popular example is the "DAT-enhancement facility 2". It introduced
the "LOAD PAGE TABLE ENTRY ADDRESS" instruction, but no facility bit was
introduced. SO there is no way to check if the instruction is available
and actually working.

I heard rumors that if the STFLE is available, this is also an
indication for DAT-enhancement facility 2. target/s390x/kvm.c uses the
same heuristic in kvm_s390_get_host_cpu_model().

Please note that we added a feature representation for this facility,
because this would allow us later on to at least model removal of such a
facility (if HW actually would drop it) on a CPU model level.

3. This introduces some inconsistency. s390x/cpu_models.c:set_feature()
explicitly tests for such inconsistencies.

So your QEMU CPU model would have a feature, but you would not be able
to run that model using QEMU when manually specifying it on the command
line. Especially, expanding the "qemu" model and feeding it back to QEMU
will fail.

So I am not sure if we should introduce such inconsistencies at that
point. Rather fix up the basics and then move the CPU model to a
consistent model.


> Signed-off-by: Thomas Huth 
> ---
>  target/s390x/cpu_models.c | 29 ++---
>  1 file changed, 26 insertions(+), 3 deletions(-)
> 
> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
> index 8d27363..18789ab 100644
> --- a/target/s390x/cpu_models.c
> +++ b/target/s390x/cpu_models.c
> @@ -658,6 +658,24 @@ static void check_compatibility(const S390CPUModel 
> *max_model,
>"available in the configuration: ");
>  }
>  
> +/**
> + * The base TCG CPU model "qemu" is based on the z900. However, we already
> + * can also emulate some additional features of later CPU generations, so
> + * we add these additional feature bits here.
> + */
> +static void add_qemu_cpu_model_features(S390FeatBitmap fbm)
> +{
> +int i, feats[] = {
> +S390_FEAT_STFLE,
> +S390_FEAT_EXTENDED_IMMEDIATE,
> +S390_FEAT_STORE_CLOCK_FAST
> +};
> +
> +for (i = 0; i < ARRAY_SIZE(feats); i++) {
> +set_bit(feats[i], fbm);
> +}
> +}
> +
>  static S390CPUModel *get_max_cpu_model(Error **errp)
>  {
>  static S390CPUModel max_model;
> @@ -670,10 +688,11 @@ static S390CPUModel *get_max_cpu_model(Error **errp)
>  if (kvm_enabled()) {
>  kvm_s390_get_host_cpu_model(_model, errp);
>  } else {
> -/* TCG emulates a z900 */
> +/* TCG emulates a z900 (with some additional features) */
>  max_model.def = _cpu_defs[0];
>  bitmap_copy(max_model.features, max_model.def->default_feat,
>  S390_FEAT_MAX);
> +add_qemu_cpu_model_features(max_model.features);
>  }
>  if (!*errp) {
>  cached = true;
> @@ -925,11 +944,15 @@ static void s390_host_cpu_model_initfn(Object *obj)
>  
>  static void s390_qemu_cpu_model_initfn(Object *obj)
>  {
> +static S390CPUDef s390_qemu_cpu_defs;
>  S390CPU *cpu = S390_CPU(obj);
>  
>  cpu->model = g_malloc0(sizeof(*cpu->model));
> -/* TCG emulates a z900 */
> -cpu->model->def = _cpu_defs[0];
> +/* TCG emulates a z900 (with some additional features) */
> +memcpy(_qemu_cpu_defs, _cpu_defs[0], 
> sizeof(s390_qemu_cpu_defs));
> +add_qemu_cpu_model_features(s390_qemu_cpu_defs.default_feat);
> +add_qemu_cpu_model_features(s390_qemu_cpu_defs.full_feat);
> +cpu->model->def = _qemu_cpu_defs;
>  bitmap_copy(cpu->model->features, cpu->model->def->default_feat,
>  S390_FEAT_MAX);
>  }
> 


-- 

Thanks,

David

Re: [Qemu-devel] [PATCH 6/6] spec/vhost-user spec: Add IOMMU support

[Michael S. Tsirkin]

On Thu, May 11, 2017 at 02:32:46PM +0200, Maxime Coquelin wrote:
> This patch specifies and implements the master/slave communication
> to support device IOTLB in slave.
> 
> The vhost_iotlb_msg structure introduced for kernel backends is
> re-used, making the design close between the two backends.
> 
> An exception is the use of the secondary channel to enable the
> slave to send IOTLB miss requests to the master.
> 
> Signed-off-by: Maxime Coquelin 
> ---
>  docs/specs/vhost-user.txt | 75 
> +++
>  hw/virtio/vhost-user.c| 31 
>  2 files changed, 106 insertions(+)
> 
> diff --git a/docs/specs/vhost-user.txt b/docs/specs/vhost-user.txt
> index 5fa7016..4a1f0c3 100644
> --- a/docs/specs/vhost-user.txt
> +++ b/docs/specs/vhost-user.txt
> @@ -97,6 +97,23 @@ Depending on the request type, payload can be:
> log offset: offset from start of supplied file descriptor
> where logging starts (i.e. where guest address 0 would be logged)
>  
> + * An IOTLB message
> +   -
> +   | iova | size | user address | permissions flags | type |
> +   -
> +
> +   IOVA: a 64-bit guest I/O virtual address
> +   Size: a 64-bit size
> +   User address: a 64-bit user address
> +   Permissions flags: a 8-bit bit field:
> +- Bit 0: Read access
> +- Bit 1: Write access
> +   Type: a 8-bit IOTLB message type:
> +- 1: IOTLB miss
> +- 2: IOTLB update
> +- 3: IOTLB invalidate
> +- 4: IOTLB access fail
> +
>  In QEMU the vhost-user message is implemented with the following struct:
>  
>  typedef struct VhostUserMsg {
> @@ -109,6 +126,7 @@ typedef struct VhostUserMsg {
>  struct vhost_vring_addr addr;
>  VhostUserMemory memory;
>  VhostUserLog log;
> +struct vhost_iotlb_msg iotlb;
>  };
>  } QEMU_PACKED VhostUserMsg;
>  
> @@ -253,6 +271,31 @@ Once the source has finished migration, rings will be 
> stopped by
>  the source. No further update must be done before rings are
>  restarted.
>  
> +IOMMU support
> +-
> +
> +When the VIRTIO_F_IOMMU_PLATFORM feature has been negotiated, the master has
> +to send IOTLB entries update & invalidation by sending VHOST_USER_IOTLB_MSG
> +requests to the slave with a struct vhost_iotlb_msg payload. For update 
> events,
> +the iotlb payload has to be filled with the update message type (2), the I/O
> +virtual address, the size, the user virtual address, and the permissions
> +flags. For invalidation events, the iotlb payload has to be filled with the
> +invalidation message type (3), the I/O virtual address and the size. On
> +success, the slave is expected to reply with a zero payload, non-zero
> +otherwise.
> +
> +When the VHOST_USER_PROTOCOL_F_SLAVE_REQ is supported by the slave, and the
> +master initiated the slave to master communication channel using the
> +VHOST_USER_SET_SLAVE_REQ_FD request, the slave can send IOTLB miss and access
> +failure events by sending VHOST_USER_SLAVE_IOTLB_MSG requests to the master
> +with a struct vhost_iotlb_msg payload. For miss events, the iotlb payload has
> +to be filled with the miss message type (1), the I/O virtual address and the
> +permissions flags. For access failure event, the iotlb payload has to be
> +filled with the access failure message type (4), the I/O virtual address and
> +the permissions flags.

I don't think slave should cache invalid entries. If it does not,
how can it detect access failure as opposed to a miss?

> For synchronization purpose, the slave may rely on the
> +reply-ack feature, so the master may send a reply when operation is completed

What does completed mean in this context?

> +if the reply-ack feature is negotiated and slaves requests a reply.
> +

This is not very clear to me.

So slave sends an access to master. Master finds a pte that
overlaps. What does it send to guest? Initial PTE?
All PTEs to cover the request? Part of the PTE that overlaps
the request?


>  Slave communication
>  ---
>  
> @@ -514,6 +557,38 @@ Master message types
>If VHOST_USER_PROTOCOL_F_REPLY_ACK is negotiated, slave must respond
>with zero for success, non-zero otherwise.
>  
> + * VHOST_USER_IOTLB_MSG
> +
> +  Id: 22
> +  Equivalent ioctl: N/A (equivalent to VHOST_IOTLB_MSG message type)
> +  Master payload: struct vhost_iotlb_msg
> +  Slave payload: u64
> +
> +  Send IOTLB messages with struct vhost_iotlb_msg as payload.
> +  Master sends such requests to update and invalidate entries in the 
> device
> +  IOTLB. The slave has to acknowledge the request with sending zero as 
> u64
> +  payload for success, non-zero otherwise.
> +  This request should be send only when VIRTIO_F_IOMMU_PLATFORM feature
> +  has been successfully negotiated.
> +
> +Slave message types
> +---
> 

Re: [Qemu-devel] [PATCH 3/6] vhost: Update rings information for IOTLB earlier

[Michael S. Tsirkin]

On Fri, May 12, 2017 at 01:21:18PM +0200, Maxime Coquelin wrote:
> 
> 
> On 05/11/2017 07:33 PM, Michael S. Tsirkin wrote:
> > On Thu, May 11, 2017 at 02:32:43PM +0200, Maxime Coquelin wrote:
> > > Vhost-kernel backend need to receive IOTLB entries for rings
> > > information early, but vhost-user need the same information
> > > earlier, before VHOST_USER_SET_VRING_ADDR is sent.
> > 
> > Weird. What does VHOST_USER_SET_VRING_ADDR have to do with it?
> > 
> > According to
> > Starting and stopping rings
> > in vhost user spec, vhost user does not access
> > anything until ring is started and enabled.
> > 
> > 
> > > This patch also trigger IOTLB miss for all rings informations
> > > for robustness, even if in practice these adresses are on the
> > > same page.
> 
> Actually, the DPDK vhost-user backend is compliant with the spec,
> but when handling VHOST_USER_SET_VRING_ADDR request, it translates the
> guest addresses into backend VAs, and check they are valid. I will make the
> commit message clearer about this in next revision.
> 
> The check could be done later, for example when the ring are started,
> but it wouldn't change the need to trigger a miss at some point.

I think it should be done later, yes. As long as ring is not
started addresses should not be interpreted.

> Or it could be done in the processing threads, the first time the
> addresses are used, but it would add a check for every burst of packets
> processed.

We don't want that, I agree.

> > > 
> > > Signed-off-by: Maxime Coquelin 
> > > ---
> > >   hw/virtio/vhost.c | 19 +++
> > >   1 file changed, 11 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
> > > index 748e331..817f6d0 100644
> > > --- a/hw/virtio/vhost.c
> > > +++ b/hw/virtio/vhost.c
> > > @@ -799,7 +799,17 @@ static int vhost_virtqueue_set_addr(struct vhost_dev 
> > > *dev,
> > >   .log_guest_addr = vq->used_phys,
> > >   .flags = enable_log ? (1 << VHOST_VRING_F_LOG) : 0,
> > >   };
> > > -int r = dev->vhost_ops->vhost_set_vring_addr(dev, );
> > > +int r;
> > > +
> > > +/* Update rings information for IOTLB to work correctly,
> > > + * vhost-kernel & vhost-user backends require for this.*/
> > 
> > Any requirements must be in the spec. Pls add them there.
> > Pls fix comment style as you move code.
> Sure.
> 
> Thanks,
> Maxime

Re: [Qemu-devel] [Qemu-ppc] [RFC 2/2] pseries: Restore PVR negotiation logic for pre-2.9 machine types

[Greg Kurz]

On Wed, 17 May 2017 16:35:47 +1000
David Gibson  wrote:

> "pseries" guests go through a hypervisor<->guest feature negotiation during
> early boot.  Part of this is finding a CPU compatibility mode which works
> for both.
> 
> In 152ef80 "pseries: Rewrite CAS PVR compatibility logic" this logic was
> changed to strongly prefer architecture defined CPU compatibility modes,
> rather than CPU "raw" modes.  However, this change was made universally,
> which introduces a guest visible change for the previously existing machine
> types (pseries-2.8 and earlier).  That's never supposed to happen.
> 
> This corrects the behaviour, reverting to the old PVR negotiation logic
> for machine types prior to pseries-2.9.
> 
> Fixes: 152ef803ceb1959e2380a1da7736b935b109222e
> Reported-by: Andrea Bolognani 
> Signed-off-by: David Gibson 
> ---
>  hw/ppc/spapr.c |  3 ++
>  hw/ppc/spapr_hcall.c   | 90 
> +-
>  include/hw/ppc/spapr.h |  1 +
>  3 files changed, 93 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index a9471b9..913355f 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -3308,9 +3308,12 @@ static void 
> spapr_machine_2_8_instance_options(MachineState *machine)
>  
>  static void spapr_machine_2_8_class_options(MachineClass *mc)
>  {
> +sPAPRMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
> +
>  spapr_machine_2_9_class_options(mc);
>  SET_MACHINE_COMPAT(mc, SPAPR_COMPAT_2_8);
>  mc->numa_mem_align_shift = 23;
> +smc->pre_2_9_cas_pvr = true;
>  }
>  
>  DEFINE_SPAPR_MACHINE(2_8, "2.8", false);
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index 007ae8d..4937019 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -1047,6 +1047,89 @@ static target_ulong h_signal_sys_reset(PowerPCCPU *cpu,
>  }
>  }
>  
> +/*
> + * Old logic for PVR negotiation, used old <2.9 machine types for

s/used old/used by old/

> + * compatibility with old qemu versions
> + */
> +#define get_compat_level(cpuver) (  \
> +((cpuver) == CPU_POWERPC_LOGICAL_2_05) ? 2050 : \
> +((cpuver) == CPU_POWERPC_LOGICAL_2_06) ? 2060 :  \
> +((cpuver) == CPU_POWERPC_LOGICAL_2_06_PLUS) ? 2061 :\
> +((cpuver) == CPU_POWERPC_LOGICAL_2_07) ? 2070 : 0)
> +
> +static void cas_handle_compat_cpu(PowerPCCPUClass *pcc, uint32_t pvr,
> +  unsigned max_lvl, unsigned *compat_lvl,
> +  unsigned *compat_pvr)
> +{
> +unsigned lvl = get_compat_level(pvr);
> +bool is205, is206, is207;
> +
> +if (!lvl) {
> +return;
> +}
> +
> +/* If it is a logical PVR, try to determine the highest level */
> +is205 = (pcc->pcr_supported & PCR_COMPAT_2_05) &&
> +(lvl == get_compat_level(CPU_POWERPC_LOGICAL_2_05));
> +is206 = (pcc->pcr_supported & PCR_COMPAT_2_06) &&
> +((lvl == get_compat_level(CPU_POWERPC_LOGICAL_2_06)) ||
> + (lvl == get_compat_level(CPU_POWERPC_LOGICAL_2_06_PLUS)));
> +is207 = (pcc->pcr_supported & PCR_COMPAT_2_07) &&
> +(lvl == get_compat_level(CPU_POWERPC_LOGICAL_2_07));
> +
> +if (is205 || is206 || is207) {
> +if (!max_lvl) {
> +/* User did not set the level, choose the highest */
> +if (*compat_lvl <= lvl) {
> +*compat_lvl = lvl;
> +*compat_pvr = pvr;
> +}
> +} else if (max_lvl >= lvl) {
> +/* User chose the level, don't set higher than this */
> +*compat_lvl = lvl;
> +*compat_pvr = pvr;
> +}
> +}
> +}
> +
> +static uint32_t cas_check_pvr_pre_2_9(PowerPCCPU *cpu, target_ulong list,

Same remark as for cas_check_pvr() in patch 1.

> +  Error **errp)
> +{
> +PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
> +int counter;
> +unsigned max_lvl = get_compat_level(cpu->max_compat);
> +bool cpu_match = false;
> +unsigned compat_lvl = 0, compat_pvr = 0;
> +
> +for (counter = 0; counter < 512; ++counter) {
> +uint32_t pvr, pvr_mask;
> +
> +pvr_mask = ldl_be_phys(_space_memory, list);
> +pvr = ldl_be_phys(_space_memory, list + 4);
> +list += 8;
> +
> +if (~pvr_mask & pvr) {
> +break; /* Terminator record */
> +}
> +
> +trace_spapr_cas_pvr_try(pvr);
> +if (!max_lvl &&
> +((cpu->env.spr[SPR_PVR] & pvr_mask) == (pvr & pvr_mask))) {
> +cpu_match = true;
> +compat_pvr = 0;
> +} else if (pvr == cpu->compat_pvr) {
> +cpu_match = true;
> +compat_pvr = cpu->compat_pvr;
> +} else if (!cpu_match) {
> +cas_handle_compat_cpu(pcc, pvr, max_lvl, _lvl, 
> _pvr);
> +}
> +}
> +
> +trace_spapr_cas_pvr(cpu->compat_pvr, 

Re: [Qemu-devel] [RFC PATCH] target/s390x/cpu_models: Set some additional feature bits for the "qemu" CPU

[Aurelien Jarno]

On 2017-05-17 17:35, Thomas Huth wrote:
> Currently we only present the plain z900 feature bits to the guest,
> but QEMU already emulates some additional features (but not all of
> the next CPU generation, so we can not use the next CPU level as
> default yet). Since newer Linux kernels are checking the feature bits
> and refuse to work if a required feature is missing, we should present
> as much of the supported features as possible when we are running
> with the default "qemu" CPU.
> This patch now adds the "stfle", "extended immediate" and "stckf"
> facility bits to the "qemu" CPU, which are already supported facilities.
> It is unfortunately still not enough to run e.g. recent Fedora kernels,
> but at least it's a first step into the right direction.

This indeed looks like a step in a good direction. At least it makes the
recently added STFLE emulation useful :-).

> Signed-off-by: Thomas Huth 
> ---
>  target/s390x/cpu_models.c | 29 ++---
>  1 file changed, 26 insertions(+), 3 deletions(-)
> 
> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
> index 8d27363..18789ab 100644
> --- a/target/s390x/cpu_models.c
> +++ b/target/s390x/cpu_models.c
> @@ -658,6 +658,24 @@ static void check_compatibility(const S390CPUModel 
> *max_model,
>"available in the configuration: ");
>  }
>  
> +/**
> + * The base TCG CPU model "qemu" is based on the z900. However, we already
> + * can also emulate some additional features of later CPU generations, so
> + * we add these additional feature bits here.
> + */
> +static void add_qemu_cpu_model_features(S390FeatBitmap fbm)
> +{
> +int i, feats[] = {
> +S390_FEAT_STFLE,
> +S390_FEAT_EXTENDED_IMMEDIATE,
> +S390_FEAT_STORE_CLOCK_FAST

According to my list, QEMU also fully implements the following
facilities:

S390_FEAT_LONG_DISPLACEMENT
S390_FEAT_GENERAL_INSTRUCTIONS_EXT
S390_FEAT_EXECUTE_EXT
S390_FEAT_STFLE_45

> +};
> +
> +for (i = 0; i < ARRAY_SIZE(feats); i++) {
> +set_bit(feats[i], fbm);
> +}
> +}
> +
>  static S390CPUModel *get_max_cpu_model(Error **errp)
>  {
>  static S390CPUModel max_model;
> @@ -670,10 +688,11 @@ static S390CPUModel *get_max_cpu_model(Error **errp)
>  if (kvm_enabled()) {
>  kvm_s390_get_host_cpu_model(_model, errp);
>  } else {
> -/* TCG emulates a z900 */
> +/* TCG emulates a z900 (with some additional features) */
>  max_model.def = _cpu_defs[0];
>  bitmap_copy(max_model.features, max_model.def->default_feat,
>  S390_FEAT_MAX);
> +add_qemu_cpu_model_features(max_model.features);
>  }
>  if (!*errp) {
>  cached = true;
> @@ -925,11 +944,15 @@ static void s390_host_cpu_model_initfn(Object *obj)
>  
>  static void s390_qemu_cpu_model_initfn(Object *obj)
>  {
> +static S390CPUDef s390_qemu_cpu_defs;
>  S390CPU *cpu = S390_CPU(obj);
>  
>  cpu->model = g_malloc0(sizeof(*cpu->model));
> -/* TCG emulates a z900 */
> -cpu->model->def = _cpu_defs[0];
> +/* TCG emulates a z900 (with some additional features) */
> +memcpy(_qemu_cpu_defs, _cpu_defs[0], 
> sizeof(s390_qemu_cpu_defs));
> +add_qemu_cpu_model_features(s390_qemu_cpu_defs.default_feat);
> +add_qemu_cpu_model_features(s390_qemu_cpu_defs.full_feat);
> +cpu->model->def = _qemu_cpu_defs;
>  bitmap_copy(cpu->model->features, cpu->model->def->default_feat,
>  S390_FEAT_MAX);
>  }

Otherwise it looks fine to me.

Reviewed-by: Aurelien Jarno 

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

Re: [Qemu-devel] [PATCH v8 0/3] ramblock: add hmp command "info ramblock"

[Dr. David Alan Gilbert]

* Peter Xu (pet...@redhat.com) wrote:
> v8:

Queued for HMP


> - patch 1: add r-b for Dave
> - patch 2: use "uint64_t" for size_to_str() parameter, remove assert()
>   since it's useless now [Dave]
> - drop patch 4
> 
> v7:
> - patch 1: removed Dave's r-b since the patch conflicted during rebase
> - patch 2: add r-b for Markus, with the nice function comment that
>   provided [Markus]
> - patch 3: add r-b for Dave
> - patch 4 (new): added new patch to remove assert in size_to_str(),
>   assuming that would be better.
> 
> v6
> - patch 2: instead of create a new size_to_str(), abstract the logic
>   out from print_type_size(), refactor it, to make sure
>   print_type_size() dumps exactly the same thing as before. (a simple
>   test with info qtree is done)
> - let suffixes be an array of strings [Markus]
> 
> v5
> - add r-b for Dave on first patch (which I forgot in v4, so I got it
>   again)
> - add one more patch to introduce size_to_str() as patch 2 [Dave]
> - let the last patch use the new interface
> 
> v4:
> - move page_size_to_str() into util/cutil.c [Dave]
> 
> v3:
> - cast the three PRIx64 addresses using (uint64_t) [Fam]
> - add more comment in patch 2 to emphasize that this command is only
>   suitable for HMP, not QMP [Markus]
> 
> v2:
> - replace "lx" with "PRIx64" in three places
> 
> Sometimes I would like to know ramblock info for a VM. This command
> would help. It provides a way to dump ramblock info. Currently the
> list is by default sorted by size, though I think it's good enough.
> 
> Please review, thanks.
> 
> Peter Xu (3):
>   ramblock: add RAMBLOCK_FOREACH()
>   utils: provide size_to_str()
>   ramblock: add new hmp command "info ramblock"
> 
>  exec.c   | 44 
> +---
>  hmp-commands-info.hx | 14 ++
>  hmp.c|  6 ++
>  hmp.h|  1 +
>  include/exec/ramlist.h   |  6 ++
>  include/qemu-common.h|  1 +
>  migration/ram.c  | 13 +++--
>  qapi/string-output-visitor.c | 22 ++
>  util/cutils.c| 25 +
>  9 files changed, 99 insertions(+), 33 deletions(-)
> 
> -- 
> 2.7.4
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH v4 4/4] fsdev: QMP interface for throttling

[Greg Kurz]

On Wed, 17 May 2017 10:28:33 -0500
Eric Blake  wrote:

> On 05/17/2017 09:53 AM, Pradeep Jagadeesh wrote:
> 
> >>> +#ifdef _WIN64
> >>> +
> >>> +void qmp_fsdev_set_io_throttle(IOThrottle *arg, Error **errp)
> >>> +{
> >>> +  return;
> >>> +}
> >>> +
> >>> +IOThrottleList *qmp_query_fsdev_io_throttle(Error **errp)
> >>> +{
> >>> +abort();
> >>> +}
> >>> +
> >>> +#endif  
> >>
> >> I think you're missing an addition to monitor.c
> >> qmp_unregister_commands_hack() if you intend for this command to be
> >> available only on non-windows platforms (and is your #ifdef the correct
> >> name, or is this a Linux-only feature rather than a non-windows feature).  
> > I had to add this one here because, I was getting some error when I
> > cross compile for Windows. But I do not have any idea about, do I need
> > to add in monitor.c or not.  
> 
> First point: is fsdev a Linux-only feature, or can it be compiled on
> BSD?  If it is Linux-only, then compiling a stub for Windows will still
> leave BSD broken, and your #ifdef is wrong.  Fixing compilation on mingw
> is nice, but not the only platform to worry about.
> 

fsdev compilation currently depends on CONFIG_VIRTFS which is a Linux-only
feature for the moment. There was a tentative to support it on Windows hosts
two years ago but it stayed at the RFC stage.

But even on Linux hosts, the current fsdev implementation also depends on
the target supporting PCI and VIRTIO. We have a fsdev/qemu-fsdev-dummy.c
file to put stubs so that we don't pull all the code for such targets.

Maybe this could be reused for the above stubs as well ?

> Second point: if fsdev is indeed a platform-specific feature, then we
> don't want to advertise the QMP commands that are useless when running
> on a platform that doesn't support it. Anywhere you have to add a stub
> for compilation means you ALSO need to patch monitor.c to unregister the
> command from being advertised as a valid QMP command.  (If you used
> #ifdef __LINUX__ to guard the working version, and #ifndef __LINUX__ to
> declare the stub, then the monitor.c needs an #ifndef section within
> qmp_unregister_commands_hack() to tell QMP to not advertise the stubs.)
> 



pgpb1VkvTR2t8.pgp
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 08/17] qapi: update the qobject visitor to use QUInt

[Markus Armbruster]

Markus Armbruster  writes:

> On the subject: there is no such thing as "QUInt".  I guess you mean
> "uint type" (like in PATCH 06's subject).  Could also say "QNUM_U64".
>
> Apropos subject: humor me, and start your subjects with a capital
> letter, like this:
>
> qapi: Update the qobject visitor ...
>
> Marc-André Lureau  writes:
>
>> Switch to use QNum/uint where appropriate to remove i64 limitation.
>>
>> The input visitor will cast i64 input to u64 for compatibility
>> reasons (existing json QMP client already use negative i64 for large
>> u64, and expect an implicit cast in qemu).
>>
>> Signed-off-by: Marc-André Lureau 
>> ---
>>  qapi/qobject-input-visitor.c| 13 +++--
>>  qapi/qobject-output-visitor.c   |  3 +--
>>  tests/test-qobject-output-visitor.c | 21 -
>>  3 files changed, 28 insertions(+), 9 deletions(-)
>>
>> diff --git a/qapi/qobject-input-visitor.c b/qapi/qobject-input-visitor.c
>> index 785949ebab..72cefcf677 100644
>> --- a/qapi/qobject-input-visitor.c
>> +++ b/qapi/qobject-input-visitor.c
>> @@ -420,9 +420,9 @@ static void qobject_input_type_int64_keyval(Visitor *v, 
>> const char *name,
>>  static void qobject_input_type_uint64(Visitor *v, const char *name,
>>uint64_t *obj, Error **errp)
>>  {
>> -/* FIXME: qobject_to_qnum mishandles values over INT64_MAX */
>>  QObjectInputVisitor *qiv = to_qiv(v);
>>  QObject *qobj = qobject_input_get_object(qiv, name, true, errp);
>> +Error *err = NULL;
>>  QNum *qnum;
>>  
>>  if (!qobj) {
>> @@ -435,7 +435,16 @@ static void qobject_input_type_uint64(Visitor *v, const 
>> char *name,
>>  return;
>>  }
>>  
>> -*obj = qnum_get_int(qnum, errp);
>> +/* XXX: compatibility case, accept negative values as u64 */
>
> What does "XXX" signify?
>
>> +*obj = qnum_get_int(qnum, );
>> +
>
> Shouldn't the comment go right here?

Nope, I misread the code.

We first try qnum_get_int().  Works for integers between -2^63 and
2^63-1.  The assignment to *obj adds 2^64 to negative ones.

When it doesn't work, we try qnum_get_uint().  Works for integers
between 0 and 2^64-1, but only integers between 2^63 and 2^64-1 can
occur.

>> +if (err) {
>> +error_free(err);
>> +err = NULL;
>> +*obj = qnum_get_uint(qnum, );
>> +}
>> +
>> +error_propagate(errp, err);
>>  }

Let's do this the other way round:

*obj = qnum_get_uint(qnum, );
if (err) {
/* Need to accept negative values for backward compatibility */
error_free(err);
err = NULL;
*obj = qnum_get_int(qnum, );
}

error_propagate(errp, err);

This way, the backward compatibility code is entirely contained in the
conditional.

It's also how I misread the code :)

[...]

Re: [Qemu-devel] [PATCH 3/5] migration: Remove use of old MigrationParams

[Juan Quintela]

Eric Blake  wrote:
> On 05/17/2017 10:38 AM, Juan Quintela wrote:
>> We have change in the previous patch to use migration capabilities for
>> it.  Notice that we continue using the old command line flags from
>> migrate command from the time being.  Remove the set_params method as
>> now it is empty.
>> 
>> For savevm, one can't do a:
>> 
>> savevm -b/-i foo
>> 
>> but now one can do:
>> 
>> migrate_set_capability block on
>> savevm foo
>> 
>> And we can't use block migration. We could disable block capability
>> unconditionally, but it would not be much better.
>> 
>> Signed-off-by: Juan Quintela 
>> 
>> ---
>> - Maintain shared/enabled dependency (Xu suggestion)
>> - Now we maintain the dependency on the setter functions
>> - improve error messages
>> 
>> Signed-off-by: Juan Quintela 
>
> This second S-o-b gets stripped, but the one that counts is in place
> (I've made the same mistake before, as well - doing 'git commit --amend
> -s' on a commit where I already had a --- separator)

And this time I *really* remove the -s from my git-format-patch alias.
I dropped that last week on the terminal, rebooted the machine and
. magic ... got the old alias O:-)

> Reviewed-by: Eric Blake 

Thanks

[Qemu-devel] [PATCH 2/2] migration: Make savevm.c target independent

[Juan Quintela]

It only needed TARGET_PAGE_SIZE/BITS/BITS_MIN values, so just export
them from exec.h

Signed-off-by: Juan Quintela 
---
 Makefile.target|  2 +-
 exec.c |  9 +
 include/exec/target_page.h |  2 ++
 migration/Makefile.objs|  2 +-
 migration/savevm.c | 14 +++---
 5 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index 465a633..ce8dfe4 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -146,7 +146,7 @@ obj-$(CONFIG_KVM) += kvm-all.o
 obj-y += memory.o cputlb.o
 obj-y += memory_mapping.o
 obj-y += dump.o
-obj-y += migration/ram.o migration/savevm.o
+obj-y += migration/ram.o
 LIBS := $(libs_softmmu) $(LIBS)
 
 # Hardware support
diff --git a/exec.c b/exec.c
index e9a201a..447ac63 100644
--- a/exec.c
+++ b/exec.c
@@ -3387,6 +3387,15 @@ size_t qemu_target_page_size(void)
 return TARGET_PAGE_SIZE;
 }
 
+int qemu_target_page_bits(void)
+{
+return TARGET_PAGE_BITS;
+}
+
+int qemu_target_page_bits_min(void)
+{
+return TARGET_PAGE_BITS_MIN;
+}
 #endif
 
 /*
diff --git a/include/exec/target_page.h b/include/exec/target_page.h
index 0961591..e3a19cc 100644
--- a/include/exec/target_page.h
+++ b/include/exec/target_page.h
@@ -16,5 +16,7 @@
 #define EXEC_TARGET_PAGE_H
 
 size_t qemu_target_page_size(void);
+int qemu_target_page_bits(void);
+int qemu_target_page_bits_min(void);
 
 #endif
diff --git a/migration/Makefile.objs b/migration/Makefile.objs
index 3272415..90f8c1f 100644
--- a/migration/Makefile.objs
+++ b/migration/Makefile.objs
@@ -1,5 +1,5 @@
 common-obj-y += migration.o socket.o fd.o exec.o
-common-obj-y += tls.o channel.o
+common-obj-y += tls.o channel.o savevm.o
 common-obj-y += colo-comm.o colo.o colo-failover.o
 common-obj-y += vmstate.o vmstate-types.o page_cache.o
 common-obj-y += qemu-file.o
diff --git a/migration/savevm.c b/migration/savevm.c
index 8763700..d971e5e 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -27,7 +27,6 @@
  */
 
 #include "qemu/osdep.h"
-#include "cpu.h"
 #include "hw/boards.h"
 #include "hw/hw.h"
 #include "hw/qdev.h"
@@ -288,7 +287,7 @@ static void configuration_pre_save(void *opaque)
 
 state->len = strlen(current_name);
 state->name = current_name;
-state->target_page_bits = TARGET_PAGE_BITS;
+state->target_page_bits = qemu_target_page_bits();
 }
 
 static int configuration_pre_load(void *opaque)
@@ -299,7 +298,7 @@ static int configuration_pre_load(void *opaque)
  * predates the variable-target-page-bits support and is using the
  * minimum possible value for this CPU.
  */
-state->target_page_bits = TARGET_PAGE_BITS_MIN;
+state->target_page_bits = qemu_target_page_bits_min();
 return 0;
 }
 
@@ -314,9 +313,9 @@ static int configuration_post_load(void *opaque, int 
version_id)
 return -EINVAL;
 }
 
-if (state->target_page_bits != TARGET_PAGE_BITS) {
+if (state->target_page_bits != qemu_target_page_bits()) {
 error_report("Received TARGET_PAGE_BITS is %d but local is %d",
- state->target_page_bits, TARGET_PAGE_BITS);
+ state->target_page_bits, qemu_target_page_bits());
 return -EINVAL;
 }
 
@@ -332,7 +331,8 @@ static int configuration_post_load(void *opaque, int 
version_id)
  */
 static bool vmstate_target_page_bits_needed(void *opaque)
 {
-return TARGET_PAGE_BITS > TARGET_PAGE_BITS_MIN;
+return qemu_target_page_bits()
+> qemu_target_page_bits_min();
 }
 
 static const VMStateDescription vmstate_target_page_bits = {
@@ -1138,7 +1138,7 @@ void qemu_savevm_state_complete_precopy(QEMUFile *f, bool 
iterable_only)
 }
 
 vmdesc = qjson_new();
-json_prop_int(vmdesc, "page_size", TARGET_PAGE_SIZE);
+json_prop_int(vmdesc, "page_size", qemu_target_page_size());
 json_start_array(vmdesc, "devices");
 QTAILQ_FOREACH(se, _state.handlers, entry) {
 
-- 
2.9.3

Re: [Qemu-devel] [PATCH 9/9] migration: migration.h was not needed

[Dr. David Alan Gilbert]

* Dr. David Alan Gilbert (dgilb...@redhat.com) wrote:
> * Juan Quintela (quint...@redhat.com) wrote:
> > This files don't use any function from migration.h, so drop it.
> > 
> > Signed-off-by: Juan Quintela 
> 
> Acked-by: Dr. David Alan Gilbert 

Oops, I meant:

Reviewed-by: Dr. David Alan Gilbert 

> > ---
> >  block/qed.c | 1 -
> >  hw/i386/pc_q35.c| 1 -
> >  hw/virtio/vhost-user.c  | 1 -
> >  hw/virtio/vhost-vsock.c | 1 -
> >  hw/virtio/virtio.c  | 1 -
> >  monitor.c   | 1 -
> >  6 files changed, 6 deletions(-)
> > 
> > diff --git a/block/qed.c b/block/qed.c
> > index fd76817..8d899fd 100644
> > --- a/block/qed.c
> > +++ b/block/qed.c
> > @@ -19,7 +19,6 @@
> >  #include "trace.h"
> >  #include "qed.h"
> >  #include "qapi/qmp/qerror.h"
> > -#include "migration/migration.h"
> >  #include "sysemu/block-backend.h"
> >  
> >  static const AIOCBInfo qed_aiocb_info = {
> > diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> > index 66303a7..a58785b 100644
> > --- a/hw/i386/pc_q35.c
> > +++ b/hw/i386/pc_q35.c
> > @@ -46,7 +46,6 @@
> >  #include "hw/ide/ahci.h"
> >  #include "hw/usb.h"
> >  #include "qemu/error-report.h"
> > -#include "migration/migration.h"
> >  #include "sysemu/numa.h"
> >  
> >  /* ICH9 AHCI has 6 ports */
> > diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
> > index 9334a8a..ebc8ccf 100644
> > --- a/hw/virtio/vhost-user.c
> > +++ b/hw/virtio/vhost-user.c
> > @@ -17,7 +17,6 @@
> >  #include "sysemu/kvm.h"
> >  #include "qemu/error-report.h"
> >  #include "qemu/sockets.h"
> > -#include "migration/migration.h"
> >  
> >  #include 
> >  #include 
> > diff --git a/hw/virtio/vhost-vsock.c b/hw/virtio/vhost-vsock.c
> > index b481562..49e0022 100644
> > --- a/hw/virtio/vhost-vsock.c
> > +++ b/hw/virtio/vhost-vsock.c
> > @@ -17,7 +17,6 @@
> >  #include "qapi/error.h"
> >  #include "hw/virtio/virtio-bus.h"
> >  #include "hw/virtio/virtio-access.h"
> > -#include "migration/migration.h"
> >  #include "qemu/error-report.h"
> >  #include "hw/virtio/vhost-vsock.h"
> >  #include "qemu/iov.h"
> > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > index 03592c5..2d2b6bf 100644
> > --- a/hw/virtio/virtio.c
> > +++ b/hw/virtio/virtio.c
> > @@ -21,7 +21,6 @@
> >  #include "hw/virtio/virtio.h"
> >  #include "qemu/atomic.h"
> >  #include "hw/virtio/virtio-bus.h"
> > -#include "migration/migration.h"
> >  #include "hw/virtio/virtio-access.h"
> >  #include "sysemu/dma.h"
> >  
> > diff --git a/monitor.c b/monitor.c
> > index 078cba5..fa295c4 100644
> > --- a/monitor.c
> > +++ b/monitor.c
> > @@ -49,7 +49,6 @@
> >  #include "disas/disas.h"
> >  #include "sysemu/balloon.h"
> >  #include "qemu/timer.h"
> > -#include "migration/migration.h"
> >  #include "sysemu/hw_accel.h"
> >  #include "qemu/acl.h"
> >  #include "sysemu/tpm.h"
> > -- 
> > 2.9.3
> > 
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

[Qemu-devel] [PATCH 1/2] exec: Create include for target_page_size()

[Juan Quintela]

That is the only function that we need from exec.c, and having to
include the whole sysemu.h for this.

Signed-off-by: Juan Quintela 
---
 exec.c |  1 +
 include/exec/target_page.h | 20 
 include/sysemu/sysemu.h|  1 -
 migration/migration.c  |  1 +
 migration/postcopy-ram.c   |  1 +
 migration/savevm.c |  1 +
 6 files changed, 24 insertions(+), 1 deletion(-)
 create mode 100644 include/exec/target_page.h

diff --git a/exec.c b/exec.c
index eac6085..e9a201a 100644
--- a/exec.c
+++ b/exec.c
@@ -24,6 +24,7 @@
 #include "qemu/cutils.h"
 #include "cpu.h"
 #include "exec/exec-all.h"
+#include "exec/target_page.h"
 #include "tcg.h"
 #include "hw/qdev-core.h"
 #if !defined(CONFIG_USER_ONLY)
diff --git a/include/exec/target_page.h b/include/exec/target_page.h
new file mode 100644
index 000..0961591
--- /dev/null
+++ b/include/exec/target_page.h
@@ -0,0 +1,20 @@
+
+ /*
+ * QEMU exec target page sizes
+ *
+ * Copyright IBM, Corp. 2008
+ *
+ * Authors:
+ *  Anthony Liguori   
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef EXEC_TARGET_PAGE_H
+#define EXEC_TARGET_PAGE_H
+
+size_t qemu_target_page_size(void);
+
+#endif
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 765358e..ed8fe3b 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -67,7 +67,6 @@ int qemu_reset_requested_get(void);
 void qemu_system_killed(int signal, pid_t pid);
 void qemu_system_reset(bool report);
 void qemu_system_guest_panicked(GuestPanicInformation *info);
-size_t qemu_target_page_size(void);
 
 void qemu_add_exit_notifier(Notifier *notify);
 void qemu_remove_exit_notifier(Notifier *notify);
diff --git a/migration/migration.c b/migration/migration.c
index 75a728a..4429a8c 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -37,6 +37,7 @@
 #include "qom/cpu.h"
 #include "exec/memory.h"
 #include "exec/address-spaces.h"
+#include "exec/target_page.h"
 #include "io/channel-buffer.h"
 #include "io/channel-tls.h"
 #include "migration/colo.h"
diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
index 64f09e1..82f719a 100644
--- a/migration/postcopy-ram.c
+++ b/migration/postcopy-ram.c
@@ -19,6 +19,7 @@
 #include "qemu/osdep.h"
 
 #include "qemu-common.h"
+#include "exec/target_page.h"
 #include "migration/migration.h"
 #include "migration/qemu-file.h"
 #include "postcopy-ram.h"
diff --git a/migration/savevm.c b/migration/savevm.c
index 8565103..8763700 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -43,6 +43,7 @@
 #include "qemu/queue.h"
 #include "sysemu/cpus.h"
 #include "exec/memory.h"
+#include "exec/target_page.h"
 #include "qmp-commands.h"
 #include "trace.h"
 #include "qemu/bitops.h"
-- 
2.9.3

Re: [Qemu-devel] [PATCH 5/9] migration: Move qjson.h to migration/

[Dr. David Alan Gilbert]

* Juan Quintela (quint...@redhat.com) wrote:
> It is only used for migration code.
> 
> Signed-off-by: Juan Quintela 

Reviewed-by: Dr. David Alan Gilbert 

> ---
>  migration/qjson.c| 2 +-
>  {include/migration => migration}/qjson.h | 0
>  migration/vmstate.c  | 2 +-
>  3 files changed, 2 insertions(+), 2 deletions(-)
>  rename {include/migration => migration}/qjson.h (100%)
> 
> diff --git a/migration/qjson.c b/migration/qjson.c
> index f345904..9d7f6eb 100644
> --- a/migration/qjson.c
> +++ b/migration/qjson.c
> @@ -25,7 +25,7 @@
>  
>  #include "qemu/osdep.h"
>  #include "qapi/qmp/qstring.h"
> -#include "migration/qjson.h"
> +#include "qjson.h"
>  
>  struct QJSON {
>  QString *str;
> diff --git a/include/migration/qjson.h b/migration/qjson.h
> similarity index 100%
> rename from include/migration/qjson.h
> rename to migration/qjson.h
> diff --git a/migration/vmstate.c b/migration/vmstate.c
> index 7b4a607..66c50ee 100644
> --- a/migration/vmstate.c
> +++ b/migration/vmstate.c
> @@ -7,7 +7,7 @@
>  #include "qemu/error-report.h"
>  #include "qemu/queue.h"
>  #include "trace.h"
> -#include "migration/qjson.h"
> +#include "qjson.h"
>  
>  static void vmstate_subsection_save(QEMUFile *f, const VMStateDescription 
> *vmsd,
>  void *opaque, QJSON *vmdesc);
> -- 
> 2.9.3
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

[Qemu-devel] [PATCH 0/2] Make migration/ram.c target independent

[Juan Quintela]

Hi

Only reason that ram.c is compiled by target is because it use
TARGET_PAGE_BITS.  As we already have a function to export
TARGET_PAGE_SIZE, do the same.
After this, we can make it target independent.

Please, review.

Later, Juan.




Juan Quintela (2):
  exec: Create include for target_page_size()
  migration: Make savevm.c target independent

 Makefile.target|  2 +-
 exec.c | 10 ++
 include/exec/target_page.h | 22 ++
 include/sysemu/sysemu.h|  1 -
 migration/Makefile.objs|  2 +-
 migration/migration.c  |  1 +
 migration/postcopy-ram.c   |  1 +
 migration/savevm.c | 15 ---
 8 files changed, 44 insertions(+), 10 deletions(-)
 create mode 100644 include/exec/target_page.h

-- 
2.9.3

Re: [Qemu-devel] [PATCH v1] target/s390x: Add support for the TEST BLOCK instruction

[Thomas Huth]

On 16.05.2017 21:06, Richard Henderson wrote:
> On 05/16/2017 02:28 AM, Thomas Huth wrote:
>> +void HELPER(testblock)(CPUS390XState *env, uint64_t addr)
>> +{
>> +CPUState *cs = CPU(s390_env_get_cpu(env));
>> +int i;
>> +
>> +addr = get_address(env, 0, 0, addr) & ~0xfffULL;
>> +for (i = 0; i < TARGET_PAGE_SIZE; i += 8) {
>> +stq_phys(cs->as, addr + i, 0);
>> +}
>> +env->cc_op = 0;
>> +}
> 
> This needs several changes: check that the physical page does indeed
> exist, "low address protection", return the cc code.

Ok, ... but if we care about "low address protection", shouldn't we also
add that to the other CPU instructions, too? (As far as I can see, it is
not supported by the TCG code at all yet)

>> +DEF_HELPER_2(testblock, void, env, i64)
> 
> With cc returned, this becomes
> 
>   DEF_HELPER_FLAGS_2(testblock, TCG_CALL_NO_RWG, i32, env, i64)

Ok, thanks ... I'm still learning the details of writing TCG code ... ;-)

 Thomas