Re: [Qemu-devel] [PATCH] qdev: Check for the availability of a hotplug controller before adding a device

[Thomas Huth]

On 04.10.2017 23:21, Eduardo Habkost wrote:
> On Wed, Oct 04, 2017 at 09:29:54PM +0200, Thomas Huth wrote:
>> On 04.10.2017 13:36, Igor Mammedov wrote:
>>> On Tue,  3 Oct 2017 18:46:02 +0200
>>> Thomas Huth  wrote:
>>>
 The qdev_unplug() function contains a g_assert(hotplug_ctrl) statement,
 so QEMU crashes when the user tries to device_add + device_del a device
 that does not have a corresponding hotplug controller. This could be
 provoked for a couple of devices in the past (see commit 4c93950659487c7ad
 or 84ebd3e8c7d4fe955 for example). So devices clearly need a hotplug
 controller when they are suitable for device_add.
 The code in qdev_device_add() already checks whether the bus has a proper
 hotplug controller, but for devices that do not have a corresponding bus,
 there is no appropriate check available. In that case we should check
 whether the machine itself provides a suitable hotplug controller and
 refuse to plug the device if none is available.

 Signed-off-by: Thomas Huth 
 ---
  This is the follow-up patch from my earlier try "hw/core/qdev: Do not
  allow hot-plugging without hotplug controller" ... AFAICS the function
  qdev_device_add() is now the right spot to do the check.

  hw/core/qdev.c | 28 
  include/hw/qdev-core.h |  1 +
  qdev-monitor.c |  9 +
  3 files changed, 30 insertions(+), 8 deletions(-)

 diff --git a/hw/core/qdev.c b/hw/core/qdev.c
 index 606ab53..a953ec9 100644
 --- a/hw/core/qdev.c
 +++ b/hw/core/qdev.c
 @@ -253,19 +253,31 @@ void qdev_set_legacy_instance_id(DeviceState *dev, 
 int alias_id,
  dev->alias_required_for_version = required_for_version;
  }
  
 +HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev)
 +{
 +MachineState *machine;
 +MachineClass *mc;
 +Object *m_obj = qdev_get_machine();
 +
 +if (object_dynamic_cast(m_obj, TYPE_MACHINE)) {
 +machine = MACHINE(m_obj);
 +mc = MACHINE_GET_CLASS(machine);
 +if (mc->get_hotplug_handler) {
 +return mc->get_hotplug_handler(machine, dev);
 +}
 +}
 +
 +return NULL;
 +}
 +
  HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev)
  {
 -HotplugHandler *hotplug_ctrl = NULL;
 +HotplugHandler *hotplug_ctrl;
  
  if (dev->parent_bus && dev->parent_bus->hotplug_handler) {
  hotplug_ctrl = dev->parent_bus->hotplug_handler;
 -} else if (object_dynamic_cast(qdev_get_machine(), TYPE_MACHINE)) {
 -MachineState *machine = MACHINE(qdev_get_machine());
 -MachineClass *mc = MACHINE_GET_CLASS(machine);
 -
 -if (mc->get_hotplug_handler) {
 -hotplug_ctrl = mc->get_hotplug_handler(machine, dev);
 -}
 +} else {
 +hotplug_ctrl = qdev_get_machine_hotplug_handler(dev);
  }
  return hotplug_ctrl;
  }
 diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
 index 0891461..5aa536d 100644
 --- a/include/hw/qdev-core.h
 +++ b/include/hw/qdev-core.h
 @@ -285,6 +285,7 @@ DeviceState *qdev_try_create(BusState *bus, const char 
 *name);
  void qdev_init_nofail(DeviceState *dev);
  void qdev_set_legacy_instance_id(DeviceState *dev, int alias_id,
   int required_for_version);
 +HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev);
  HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev);
  void qdev_unplug(DeviceState *dev, Error **errp);
  void qdev_simple_device_unplug_cb(HotplugHandler *hotplug_dev,
 diff --git a/qdev-monitor.c b/qdev-monitor.c
 index 8fd6df9..2891dde 100644
 --- a/qdev-monitor.c
 +++ b/qdev-monitor.c
 @@ -626,6 +626,15 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error 
 **errp)
  return NULL;
  }
  
 +/* In case we don't have a bus, there must be a machine hotplug 
 handler */
 +if (qdev_hotplug && !bus && !qdev_get_machine_hotplug_handler(dev)) {
>>> current machine hotplug handler serves both cold and hot-plug so in reality 
>>> it's
>>> just  'plug' handler.
>>>
>>> Is there a point -device/device_add devices on board that doesn't have 
>>> 'hotplug'
>>> handler that would wire device up properly?
>>
>> Sorry, I did not get that question ... do you mean whether there's any
>> code that uses qdev_device_add() to add a device without hotplug
>> controller? I don't think so. It's currently only used by
>> qmp_device_add() for the QMP/HMP command, in vl.c for -device and in the
>> USB code for xen-usb host device. So this function currently really only
>> makes sense for devices that have a hotplug controller.
> 
> I assume you 

[Qemu-devel] [PATCH qemu v5 2/2] spapr/iommu: Enable in-kernel TCE acceleration via VFIO KVM device

[Alexey Kardashevskiy]

This implements a notification for a new IOMMU group attached to
sPAPR's logical IO bus (LIOBN) to enable in-kernel TCE acceleration.

This uses new kernel KVM_CAP_SPAPR_TCE_VFIO capability to enable
in-kernel acceleration of TCE update requests which will go via
the VFIO KVM device.

Signed-off-by: Alexey Kardashevskiy 
---
 target/ppc/kvm_ppc.h |  6 ++
 hw/ppc/spapr_iommu.c | 34 ++
 target/ppc/kvm.c |  7 ++-
 hw/ppc/trace-events  |  1 +
 4 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/target/ppc/kvm_ppc.h b/target/ppc/kvm_ppc.h
index d6be38ecaf..2b985e1659 100644
--- a/target/ppc/kvm_ppc.h
+++ b/target/ppc/kvm_ppc.h
@@ -48,6 +48,7 @@ void *kvmppc_create_spapr_tce(uint32_t liobn, uint32_t 
page_shift,
 int kvmppc_remove_spapr_tce(void *table, int pfd, uint32_t window_size);
 int kvmppc_reset_htab(int shift_hint);
 uint64_t kvmppc_rma_size(uint64_t current_size, unsigned int hash_shift);
+bool kvmppc_has_cap_spapr_vfio(void);
 #endif /* !CONFIG_USER_ONLY */
 bool kvmppc_has_cap_epr(void);
 int kvmppc_define_rtas_kernel_token(uint32_t token, const char *function);
@@ -231,6 +232,11 @@ static inline bool 
kvmppc_is_mem_backend_page_size_ok(const char *obj_path)
 return true;
 }
 
+static inline bool kvmppc_has_cap_spapr_vfio(void)
+{
+return false;
+}
+
 #endif /* !CONFIG_USER_ONLY */
 
 static inline bool kvmppc_has_cap_epr(void)
diff --git a/hw/ppc/spapr_iommu.c b/hw/ppc/spapr_iommu.c
index 5ccd785d5a..34baa881f0 100644
--- a/hw/ppc/spapr_iommu.c
+++ b/hw/ppc/spapr_iommu.c
@@ -17,6 +17,7 @@
  * License along with this library; if not, see .
  */
 #include "qemu/osdep.h"
+#include 
 #include "qemu/error-report.h"
 #include "hw/hw.h"
 #include "qemu/log.h"
@@ -173,6 +174,34 @@ static void 
spapr_tce_notify_flag_changed(IOMMUMemoryRegion *iommu,
 }
 }
 
+static void spapr_tce_add_vfio_group(IOMMUMemoryRegion *iommu_mr,
+ int vfio_kvm_fd, int groupfd)
+{
+sPAPRTCETable *tcet = container_of(iommu_mr, sPAPRTCETable, iommu);
+struct kvm_vfio_spapr_tce param = {
+.tablefd = tcet->fd,
+.groupfd = groupfd,
+};
+struct kvm_device_attr attr = {
+.group = KVM_DEV_VFIO_GROUP,
+.attr = KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE,
+.addr = (uint64_t)(unsigned long),
+};
+
+if (!kvmppc_has_cap_spapr_vfio()) {
+return;
+}
+
+if (param.tablefd != -1) {
+if (ioctl(vfio_kvm_fd, KVM_SET_DEVICE_ATTR, )) {
+error_report("vfio: failed to setup fd %d for a group with fd %d: 
%s",
+ param.tablefd, param.groupfd, strerror(errno));
+return;
+}
+}
+trace_spapr_iommu_add_vfio_group(groupfd, param.tablefd);
+}
+
 static int spapr_tce_table_post_load(void *opaque, int version_id)
 {
 sPAPRTCETable *tcet = SPAPR_TCE_TABLE(opaque);
@@ -284,6 +313,10 @@ void spapr_tce_set_need_vfio(sPAPRTCETable *tcet, bool 
need_vfio)
 
 tcet->need_vfio = need_vfio;
 
+if (!need_vfio || (tcet->fd != -1 && kvmppc_has_cap_spapr_vfio())) {
+return;
+}
+
 oldtable = tcet->table;
 
 tcet->table = spapr_tce_alloc_table(tcet->liobn,
@@ -643,6 +676,7 @@ static void 
spapr_iommu_memory_region_class_init(ObjectClass *klass, void *data)
 imrc->translate = spapr_tce_translate_iommu;
 imrc->get_min_page_size = spapr_tce_get_min_page_size;
 imrc->notify_flag_changed = spapr_tce_notify_flag_changed;
+imrc->add_vfio_group = spapr_tce_add_vfio_group;
 }
 
 static const TypeInfo spapr_iommu_memory_region_info = {
diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index 171d3d8040..5438252bdc 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -136,7 +136,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
 cap_spapr_tce = kvm_check_extension(s, KVM_CAP_SPAPR_TCE);
 cap_spapr_tce_64 = kvm_check_extension(s, KVM_CAP_SPAPR_TCE_64);
 cap_spapr_multitce = kvm_check_extension(s, KVM_CAP_SPAPR_MULTITCE);
-cap_spapr_vfio = false;
+cap_spapr_vfio = kvm_vm_check_extension(s, KVM_CAP_SPAPR_TCE_VFIO);
 cap_one_reg = kvm_check_extension(s, KVM_CAP_ONE_REG);
 cap_hior = kvm_check_extension(s, KVM_CAP_PPC_HIOR);
 cap_epr = kvm_check_extension(s, KVM_CAP_PPC_EPR);
@@ -2474,6 +2474,11 @@ bool kvmppc_has_cap_mmu_hash_v3(void)
 return cap_mmu_hash_v3;
 }
 
+bool kvmppc_has_cap_spapr_vfio(void)
+{
+return cap_spapr_vfio;
+}
+
 PowerPCCPUClass *kvm_ppc_get_host_cpu_class(void)
 {
 uint32_t host_pvr = mfpvr();
diff --git a/hw/ppc/trace-events b/hw/ppc/trace-events
index 4a6a6490fa..ab70d00582 100644
--- a/hw/ppc/trace-events
+++ b/hw/ppc/trace-events
@@ -36,6 +36,7 @@ spapr_iommu_ddw_query(uint64_t buid, uint32_t cfgaddr, 
unsigned wa, uint64_t win
 spapr_iommu_ddw_create(uint64_t buid, uint32_t cfgaddr, uint64_t pg_size, 
uint64_t req_size, uint64_t start, uint32_t liobn) "buid=0x%"PRIx64" 
addr=0x%"PRIx32", 

[Qemu-devel] [PATCH qemu v5 0/2] vfio-pci, spapr: Allow in-kernel TCE ops acceleration

[Alexey Kardashevskiy]

This is my current working tree to support kernel's
"powerpc/kvm/vfio: Enable in-kernel acceleration".

Changes:
v5:
* changed IOMMU MR callbacks and reworked the whole thing as
David suggested

v4:
* rebased on the latest upstream with IOMMU MR QOM and
VFIO initialization reordering

v3:
* fixed multiple architectures with respect to IOMMU MR
* removed sPAPRIOMMUMemoryRegion

v2:
* QOM'fy of IOMMUMemoryRegion
* fix comments from v1 review


This is based on sha1
e040047a4d Greg Kurz "spapr: sanity check size of the CAS buffer".

Please comment. Thanks.



Alexey Kardashevskiy (2):
  memory/iommu/vfio: Define add_vfio_group() callback
  spapr/iommu: Enable in-kernel TCE acceleration via VFIO KVM device

 include/exec/memory.h |  4 
 target/ppc/kvm_ppc.h  |  6 ++
 hw/ppc/spapr_iommu.c  | 34 ++
 hw/vfio/common.c  | 15 +++
 target/ppc/kvm.c  |  7 ++-
 hw/ppc/trace-events   |  1 +
 6 files changed, 66 insertions(+), 1 deletion(-)

-- 
2.11.0

[Qemu-devel] [PATCH qemu v5 1/2] memory/iommu/vfio: Define add_vfio_group() callback

[Alexey Kardashevskiy]

The new callback will be called when a new VFIO IOMMU group is added.

This should cause no behavioral change, the next patch will.

Signed-off-by: Alexey Kardashevskiy 
---

This could be at the higher level - in MemoryRegionOps, makes sense?

---
 include/exec/memory.h |  4 
 hw/vfio/common.c  | 15 +++
 2 files changed, 19 insertions(+)

diff --git a/include/exec/memory.h b/include/exec/memory.h
index 5ed4042f87..64e0b4fc96 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -210,6 +210,10 @@ typedef struct IOMMUMemoryRegionClass {
 IOMMUNotifierFlag new_flags);
 /* Set this up to provide customized IOMMU replay function */
 void (*replay)(IOMMUMemoryRegion *iommu, IOMMUNotifier *notifier);
+
+/* Notifies IOMMUMR about attached VFIO IOMMU group */
+void (*add_vfio_group)(IOMMUMemoryRegion *iommu_mr, int vfio_kvm_fd,
+   int groupfd);
 } IOMMUMemoryRegionClass;
 
 typedef struct CoalescedMemoryRange CoalescedMemoryRange;
diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 7b2924c0ef..9e861e0393 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -481,6 +481,21 @@ static void vfio_listener_region_add(MemoryListener 
*listener,
 VFIOGuestIOMMU *giommu;
 IOMMUMemoryRegion *iommu_mr = IOMMU_MEMORY_REGION(section->mr);
 
+#ifdef CONFIG_KVM
+if (kvm_enabled()) {
+VFIOGroup *group;
+IOMMUMemoryRegionClass *imrc =
+IOMMU_MEMORY_REGION_GET_CLASS(iommu_mr);
+
+QLIST_FOREACH(group, >group_list, container_next) {
+if (imrc->add_vfio_group) {
+imrc->add_vfio_group(iommu_mr, vfio_kvm_device_fd,
+ group->fd);
+}
+}
+}
+#endif
+
 trace_vfio_listener_region_add_iommu(iova, end);
 /*
  * FIXME: For VFIO iommu types which have KVM acceleration to
-- 
2.11.0

Re: [Qemu-devel] [PATCH v4 2/2] vl: Deprecate auto-loading of qemu.conf

[Markus Armbruster]

Eduardo Habkost  writes:

> On Wed, Oct 04, 2017 at 09:23:08AM -0300, Eduardo Habkost wrote:
>> On Wed, Oct 04, 2017 at 07:42:17AM +0200, Markus Armbruster wrote:
>> > Eduardo Habkost  writes:
>> > 
>> > > In case there were options set in the default config file, print
>> > > a warning so users can update their scripts.
>> > >
>> > > If somebody wants to keep the config file as-is, avoid the
>> > > warning and use a command-line that will work in future QEMU
>> > > versions, they can use:
>> > >
>> > >  $QEMU -no-user-config -readconfig /etc/qemu/qemu.conf
>> > >
>> > > I was going to include the suggestion in the warning message, but
>> > > I thought it could make it more confusing.  The suggestion is
>> > > documented in qemu-doc.texi.
>> > >
>> > > Signed-off-by: Eduardo Habkost 
>> > > ---
>> > > Changes v3 -> v4:
>> > > * Use warn_report() instead of error_report("warning: ...")
>> > >   (Eric Blake)
>> > > * Document as a deprecated feature in qemu-doc.texi
>> > > * Update subject line
>> > >   (was: "vl: Print warning when a default config file is loaded")
>> > >
>> > > Changes v2 -> v3:
>> > > * Rebase (no code changes)
>> > > * Commit message update: suggest -no-user-config
>> > > ---
>> > >  vl.c  | 6 ++
>> > >  qemu-doc.texi | 8 
>> > >  2 files changed, 14 insertions(+)
>> > >
>> > > diff --git a/vl.c b/vl.c
>> > > index 3fed457921..1b0ecdf74e 100644
>> > > --- a/vl.c
>> > > +++ b/vl.c
>> > > @@ -3066,6 +3066,12 @@ static int qemu_read_default_config_file(void)
>> > >  return ret;
>> > >  }
>> > >  
>> > > +if (ret > 0) {
>> > > +loc_set_none();
>> > 
>> > Sure we need this here?
>> 
>> IIRC we needed it in the original version, but I don't remember
>> why.  I will check this.
>
> This is the result if we don't clear error location state:
>
>   $ ./x86_64-softmmu/qemu-system-x86_64 -monitor stdio -display none -device 
> foobar
>   qemu-system-x86_64: -device foobar: warning: Future QEMU versions won't 
> load /usr/local/etc/qemu/qemu.conf automatically
>   ^^
>
> However, it's probably better to do this right after the loop,
> just like we already do in the second option parsing loop:
>
> Signed-off-by: Eduardo Habkost 
> ---
> diff --git a/vl.c b/vl.c
> index f9acc17c01..a8fd247d71 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3067,7 +3067,6 @@ static int qemu_read_default_config_file(void)
>  }
>  
>  if (ret > 0) {
> -loc_set_none();
>  warn_report("Future QEMU versions won't load %s automatically",
>   CONFIG_QEMU_CONFDIR "/qemu.conf");
>  }
> @@ -3224,6 +3223,11 @@ int main(int argc, char **argv, char **envp)
>  }
>  }
>  }
> +/*
> + * Clear error location left behind by the loop.
> + * Best done right after the loop.  Do not insert code here!
> + */
> +loc_set_none();
>  
>  if (userconfig) {
>  if (qemu_read_default_config_file() < 0) {

Hmm, could this hunk be a bug fix?  Consider before the patch:

qemu_read_default_config_file()
qemu_read_config_file()
qemu_config_parse()
error_report() or error_report_err()

I suspect this uses current location left behind by the loop
inappropriately.  If true, the hunk should be a separate bug fix patch.

Re: [Qemu-devel] [Qemu-arm] [PATCH 00/20] ARM v8M: exception entry, exit and security

[Philippe Mathieu-Daudé]

On 09/22/2017 11:59 AM, Peter Maydell wrote:
> Another week, another set of v8M patches.
> This lot adds:
>  * v8M and security extension changes in exception entry and exit
>  * the Security Attribution Unit
>  * SG and BLXNS instructions
>  * secure function return
>  * and a couple of fixes for bugs in already-in-master changes
> 
> Most of this is just plodding through fairly obvious implementation,

Heavy stuff still...

> but the handling of the SG instruction is a bit funky (see commit
> messages in those patches for detail).
[...]

Re: [Qemu-devel] [Qemu-arm] [PATCH 15/20] target/arm: Fix calculation of secure mm_idx values

[Philippe Mathieu-Daudé]

On 09/22/2017 12:00 PM, Peter Maydell wrote:
> In cpu_mmu_index() we try to do this:
> if (env->v7m.secure) {
> mmu_idx += ARMMMUIdx_MSUser;
> }
> but it will give the wrong answer, because ARMMMUIdx_MSUser
> includes the 0x40 ARM_MMU_IDX_M field, and so does the
> mmu_idx we're adding to, and we'll end up with 0x8n rather
> than 0x4n. This error is then nullified by the call to
> arm_to_core_mmu_idx() which masks out the high part, but
> we're about to factor out the code that calculates the
> ARMMMUIdx values so it can be used without passing it through
> arm_to_core_mmu_idx(), so fix this bug first.
> 
> Signed-off-by: Peter Maydell 

Reviewed-by: Philippe Mathieu-Daudé 

> ---
>  target/arm/cpu.h | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 441e584..70c1f85 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -2335,14 +2335,16 @@ static inline int cpu_mmu_index(CPUARMState *env, 
> bool ifetch)
>  int el = arm_current_el(env);
>  
>  if (arm_feature(env, ARM_FEATURE_M)) {
> -ARMMMUIdx mmu_idx = el == 0 ? ARMMMUIdx_MUser : ARMMMUIdx_MPriv;
> +ARMMMUIdx mmu_idx;
>  
> -if (armv7m_nvic_neg_prio_requested(env->nvic, env->v7m.secure)) {
> -mmu_idx = ARMMMUIdx_MNegPri;
> +if (el == 0) {
> +mmu_idx = env->v7m.secure ? ARMMMUIdx_MSUser : ARMMMUIdx_MUser;
> +} else {
> +mmu_idx = env->v7m.secure ? ARMMMUIdx_MSPriv : ARMMMUIdx_MPriv;
>  }
>  
> -if (env->v7m.secure) {
> -mmu_idx += ARMMMUIdx_MSUser;
> +if (armv7m_nvic_neg_prio_requested(env->nvic, env->v7m.secure)) {
> +mmu_idx = env->v7m.secure ? ARMMMUIdx_MSNegPri : 
> ARMMMUIdx_MNegPri;
>  }
>  
>  return arm_to_core_mmu_idx(mmu_idx);
> 

Re: [Qemu-devel] [RFC PATCH 19/32] qapi: Accept double-quoted strings

[Markus Armbruster]

Marc-André Lureau  writes:

> On Mon, Oct 2, 2017 at 5:25 PM, Markus Armbruster  wrote:
>> The QAPI schema parser has always accepted only single-quoted strings,
>> even though JSON strings are double-quoted.  Accept double-quoted
>> strings as well, so you can write strings containing single quotes
>> without backslash escapes.
>>
>> Signed-off-by: Markus Armbruster 
>
> What's the motivation to allow both? If we were to switch from single
> to double quote only, that would make more sense.

Abandoning single quotes now would require us to touch pretty much every
line of code in the schemas.  I don't think correcting quotes is worth
wrecking git-blame.

Sadly, the schema language is neither JSON, nor an established extension
of JSON, nor Python.  This commit brings the schema language one step
closer to a superset of JSON.  I feel "homegrown superset" is a slightly
less bad idea than "homegrown with large overlap".

Naming the schema files .json was in bad taste.

> otherwise, patch looks good

Ready to upgrade to R-by now?

Want me to work more of my rationale into the commit message?

Re: [Qemu-devel] [PATCH 02/20] target/arm: Don't switch to target stack early in v7M exception return

[Philippe Mathieu-Daudé]

On 09/22/2017 11:59 AM, Peter Maydell wrote:
> Currently our M profile exception return code switches to the
> target stack pointer relatively early in the process, before
> it tries to pop the exception frame off the stack. This is
> awkward for v8M for two reasons:
>  * in v8M the process vs main stack pointer is not selected
>purely by the value of CONTROL.SPSEL, so updating SPSEL
>and relying on that to switch to the right stack pointer
>won't work
>  * the stack we should be reading the stack frame from and
>the stack we will eventually switch to might not be the
>same if the guest is doing strange things
> 
> Change our exception return code to use a 'frame pointer'
> to read the exception frame rather than assuming that we
> can switch the live stack pointer this early.
> 
> Signed-off-by: Peter Maydell 

Reviewed-by: Philippe Mathieu-Daudé 

> ---
>  target/arm/helper.c | 127 
> +++-
>  1 file changed, 95 insertions(+), 32 deletions(-)
> 
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index 8be78ea..f13b99d 100644
> --- a/target/arm/helper.c
> +++ b/target/arm/helper.c
> @@ -6040,16 +6040,6 @@ static void v7m_push(CPUARMState *env, uint32_t val)
>  stl_phys(cs->as, env->regs[13], val);
>  }
>  
> -static uint32_t v7m_pop(CPUARMState *env)
> -{
> -CPUState *cs = CPU(arm_env_get_cpu(env));
> -uint32_t val;
> -
> -val = ldl_phys(cs->as, env->regs[13]);
> -env->regs[13] += 4;
> -return val;
> -}
> -
>  /* Return true if we're using the process stack pointer (not the MSP) */
>  static bool v7m_using_psp(CPUARMState *env)
>  {
> @@ -6141,6 +6131,40 @@ void HELPER(v7m_bxns)(CPUARMState *env, uint32_t dest)
>  env->regs[15] = dest & ~1;
>  }
>  
> +static uint32_t *get_v7m_sp_ptr(CPUARMState *env, bool secure, bool 
> threadmode,
> +bool spsel)
> +{
> +/* Return a pointer to the location where we currently store the
> + * stack pointer for the requested security state and thread mode.
> + * This pointer will become invalid if the CPU state is updated
> + * such that the stack pointers are switched around (eg changing
> + * the SPSEL control bit).
> + * Compare the v8M ARM ARM pseudocode LookUpSP_with_security_mode().
> + * Unlike that pseudocode, we require the caller to pass us in the
> + * SPSEL control bit value; this is because we also use this
> + * function in handling of pushing of the callee-saves registers
> + * part of the v8M stack frame, and in that case the SPSEL bit
> + * comes from the exception return magic LR value.
> + */
> +bool want_psp = threadmode && spsel;
> +
> +if (secure == env->v7m.secure) {
> +/* Currently switch_v7m_sp switches SP as it updates SPSEL,
> + * so the SP we want is always in regs[13].
> + * When we decouple SPSEL from the actually selected SP
> + * we need to check want_psp against v7m_using_psp()
> + * to see whether we need regs[13] or v7m.other_sp.
> + */
> +return >regs[13];
> +} else {
> +if (want_psp) {
> +return >v7m.other_ss_psp;
> +} else {
> +return >v7m.other_ss_msp;
> +}
> +}
> +}
> +
>  static uint32_t arm_v7m_load_vector(ARMCPU *cpu)
>  {
>  CPUState *cs = CPU(cpu);
> @@ -6212,6 +6236,7 @@ static void v7m_push_stack(ARMCPU *cpu)
>  static void do_v7m_exception_exit(ARMCPU *cpu)
>  {
>  CPUARMState *env = >env;
> +CPUState *cs = CPU(cpu);
>  uint32_t excret;
>  uint32_t xpsr;
>  bool ufault = false;
> @@ -6219,6 +6244,7 @@ static void do_v7m_exception_exit(ARMCPU *cpu)
>  bool return_to_handler = false;
>  bool rettobase = false;
>  bool exc_secure = false;
> +bool return_to_secure;
>  
>  /* We can only get here from an EXCP_EXCEPTION_EXIT, and
>   * gen_bx_excret() enforces the architectural rule
> @@ -6286,6 +6312,9 @@ static void do_v7m_exception_exit(ARMCPU *cpu)
>  g_assert_not_reached();
>  }
>  
> +return_to_secure = arm_feature(env, ARM_FEATURE_M_SECURITY) &&
> +(excret & R_V7M_EXCRET_S_MASK);
> +
>  switch (excret & 0xf) {
>  case 1: /* Return to Handler */
>  return_to_handler = true;
> @@ -6315,32 +6344,66 @@ static void do_v7m_exception_exit(ARMCPU *cpu)
>  return;
>  }
>  
> -/* Switch to the target stack.  */
> +/* Set CONTROL.SPSEL from excret.SPSEL. For QEMU this currently
> + * causes us to switch the active SP, but we will change this
> + * later to not do that so we can support v8M.
> + */
>  switch_v7m_sp(env, return_to_sp_process);
> -/* Pop registers.  */
> -env->regs[0] = v7m_pop(env);
> -env->regs[1] = v7m_pop(env);
> -env->regs[2] = v7m_pop(env);
> -env->regs[3] = v7m_pop(env);
> -env->regs[12] = v7m_pop(env);
> -env->regs[14] = 

Re: [Qemu-devel] [Qemu-arm] [PATCH 20/20] nvic: Add missing code for writing SHCSR.HARDFAULTPENDED bit

[Philippe Mathieu-Daudé]

On 09/22/2017 12:00 PM, Peter Maydell wrote:
> When we added support for the new SHCSR bits in v8M in commit
> 437d59c17e9 the code to support writing to the new HARDFAULTPENDED
> bit was accidentally only added for non-secure writes; the
> secure banked version of the bit should also be writable.
> 
> Signed-off-by: Peter Maydell 
> ---
>  hw/intc/armv7m_nvic.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hw/intc/armv7m_nvic.c b/hw/intc/armv7m_nvic.c
> index bd1d5d3..22d5e6e 100644
> --- a/hw/intc/armv7m_nvic.c
> +++ b/hw/intc/armv7m_nvic.c
> @@ -1230,6 +1230,7 @@ static void nvic_writel(NVICState *s, uint32_t offset, 
> uint32_t value,

if (attrs.secure) {

if banked then arch is v8M,

>  s->sec_vectors[ARMV7M_EXCP_BUS].enabled = (value & (1 << 17)) != 
> 0;
>  s->sec_vectors[ARMV7M_EXCP_USAGE].enabled =
>  (value & (1 << 18)) != 0;
> +s->sec_vectors[ARMV7M_EXCP_HARD].pending = (value & (1 << 21)) 
> != 0;

therefore this bit is present.

Reviewed-by: Philippe Mathieu-Daudé 

>  /* SecureFault not banked, but RAZ/WI to NS */
>  s->vectors[ARMV7M_EXCP_SECURE].active = (value & (1 << 4)) != 0;
>  s->vectors[ARMV7M_EXCP_SECURE].enabled = (value & (1 << 19)) != 
> 0;
> 

Re: [Qemu-devel] [RFC PATCH 15/32] tests/qapi-schema: Improve simple union coverage

[Markus Armbruster]

Marc-André Lureau  writes:

> On Mon, Oct 2, 2017 at 5:25 PM, Markus Armbruster  wrote:
>> This demonstrates a bug in the lowering of simple unions: if more than
>> one schema uses the same built-in type T for a simple union member,
>> they all generate the same q_obj_T_wrapper into their qapi-types.h.
>> They clash when you include more than one schema's qapi-types.h.
>
> Ah, I don't remember seeing that when I splitted the schema in my
> qapi-if / conditional series.

Simple union members of built-in type are rare.  I spotted the problem
with options, then realized it's already possible with simple unions.

> Could it happen with non-built-in types ?

Yes, but multiple q_obj_T_wrapper can clash only when their T also
clash.  Name your types more wisely then.

>> Signed-off-by: Markus Armbruster 
>
> Reviewed-by: Marc-André Lureau 

Thanks!

Re: [Qemu-devel] [RFC PATCH 14/32] qapi: Rework generated code for built-in types

[Markus Armbruster]

Marc-André Lureau  writes:

> Hi
>
> On Mon, Oct 2, 2017 at 5:25 PM, Markus Armbruster  wrote:
>> qapi-types.py and qapi-visit.py generate some C code for built-in
>> types.  To make this work with multiple schemas, we generate code for
>> built-ins into .c files only when the user asks for it with -b.  The
>> user is responsible for linking exactly one set of files generated
>> with -b per program.  We generate code for built-ins into .h
>> regardless of -b, but guard it with a preprocessor symbol.
>>
>> This is cumbersome and inflexible.  Move the code generated for
>> built-in types into separate files builtin-qapi-{types,visit}.{c,h}.
>> Run qapi-types.py and qapi-visit.py without a schema argument to
>> generate them.  Drop their option -b.
>>
>> Signed-off-by: Markus Armbruster 
>
>
> Good idea!
> I think I would still prefer to see a seperate argument to generate
> builtin files (rather than absence of schema), but this is minor
> detail.

An option to generate built-ins would have to conflict with -p and the
positional argument.  I tried the stupidest solution that could possibly
work first.

> Reviewed-by: Marc-André Lureau 

Thanks!

Re: [Qemu-devel] [Qemu-arm] [PATCH 16/20] target/arm: Factor out "get mmuidx for specified security state"

[Philippe Mathieu-Daudé]

On 09/22/2017 12:00 PM, Peter Maydell wrote:
> For the SG instruction and secure function return we are going
> to want to do memory accesses using the MMU index of the CPU
> in secure state, even though the CPU is currently in non-secure
> state. Write arm_v7m_mmu_idx_for_secstate() to do this job,
> and use it in cpu_mmu_index().
> 
> Signed-off-by: Peter Maydell 

Reviewed-by: Philippe Mathieu-Daudé 

> ---
>  target/arm/cpu.h | 32 +---
>  1 file changed, 21 insertions(+), 11 deletions(-)
> 
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 70c1f85..89d49cd 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -2329,23 +2329,33 @@ static inline int arm_mmu_idx_to_el(ARMMMUIdx mmu_idx)
>  }
>  }
>  
> +/* Return the MMU index for a v7M CPU in the specified security state */
> +static inline ARMMMUIdx arm_v7m_mmu_idx_for_secstate(CPUARMState *env,
> + bool secstate)
> +{
> +int el = arm_current_el(env);
> +ARMMMUIdx mmu_idx;
> +
> +if (el == 0) {
> +mmu_idx = secstate ? ARMMMUIdx_MSUser : ARMMMUIdx_MUser;
> +} else {
> +mmu_idx = secstate ? ARMMMUIdx_MSPriv : ARMMMUIdx_MPriv;
> +}
> +
> +if (armv7m_nvic_neg_prio_requested(env->nvic, secstate)) {
> +mmu_idx = secstate ? ARMMMUIdx_MSNegPri : ARMMMUIdx_MNegPri;
> +}
> +
> +return mmu_idx;
> +}
> +
>  /* Determine the current mmu_idx to use for normal loads/stores */
>  static inline int cpu_mmu_index(CPUARMState *env, bool ifetch)
>  {
>  int el = arm_current_el(env);
>  
>  if (arm_feature(env, ARM_FEATURE_M)) {
> -ARMMMUIdx mmu_idx;
> -
> -if (el == 0) {
> -mmu_idx = env->v7m.secure ? ARMMMUIdx_MSUser : ARMMMUIdx_MUser;
> -} else {
> -mmu_idx = env->v7m.secure ? ARMMMUIdx_MSPriv : ARMMMUIdx_MPriv;
> -}
> -
> -if (armv7m_nvic_neg_prio_requested(env->nvic, env->v7m.secure)) {
> -mmu_idx = env->v7m.secure ? ARMMMUIdx_MSNegPri : 
> ARMMMUIdx_MNegPri;
> -}
> +ARMMMUIdx mmu_idx = arm_v7m_mmu_idx_for_secstate(env, 
> env->v7m.secure);
>  
>  return arm_to_core_mmu_idx(mmu_idx);
>  }
> 

Re: [Qemu-devel] [Qemu-arm] [PATCH 03/20] target/arm: Prepare for CONTROL.SPSEL being nonzero in Handler mode

[Philippe Mathieu-Daudé]

On 09/22/2017 11:59 AM, Peter Maydell wrote:
> In the v7M architecture, there is an invariant that if the CPU is
> in Handler mode then the CONTROL.SPSEL bit cannot be nonzero.
> This in turn means that the current stack pointer is always
> indicated by CONTROL.SPSEL, even though Handler mode always uses
> the Main stack pointer.
> 
> In v8M, this invariant is removed, and CONTROL.SPSEL may now
> be nonzero in Handler mode (though Handler mode still always
> uses the Main stack pointer). In preparation for this change,
> change how we handle this bit: rename switch_v7m_sp() to
> the now more accurate write_v7m_control_spsel(), and make it
> check both the handler mode state and the SPSEL bit.
> 
> Note that this implicitly changes the point at which we switch
> active SP on exception exit from before we pop the exception
> frame to after it.
> 
> Signed-off-by: Peter Maydell 

Reviewed-by: Philippe Mathieu-Daudé 

> ---
>  target/arm/cpu.h  |  8 ++-
>  hw/intc/armv7m_nvic.c |  2 +-
>  target/arm/helper.c   | 65 
> ++-
>  3 files changed, 51 insertions(+), 24 deletions(-)
> 
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 8afceca..ad6eff4 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -991,6 +991,11 @@ void pmccntr_sync(CPUARMState *env);
>  #define PSTATE_MODE_EL1t 4
>  #define PSTATE_MODE_EL0t 0
>  
> +/* Write a new value to v7m.exception, thus transitioning into or out
> + * of Handler mode; this may result in a change of active stack pointer.
> + */
> +void write_v7m_exception(CPUARMState *env, uint32_t new_exc);
> +
>  /* Map EL and handler into a PSTATE_MODE.  */
>  static inline unsigned int aarch64_pstate_mode(unsigned int el, bool handler)
>  {
> @@ -1071,7 +1076,8 @@ static inline void xpsr_write(CPUARMState *env, 
> uint32_t val, uint32_t mask)
>  env->condexec_bits |= (val >> 8) & 0xfc;
>  }
>  if (mask & XPSR_EXCP) {
> -env->v7m.exception = val & XPSR_EXCP;
> +/* Note that this only happens on exception exit */
> +write_v7m_exception(env, val & XPSR_EXCP);
>  }
>  }
>  
> diff --git a/hw/intc/armv7m_nvic.c b/hw/intc/armv7m_nvic.c
> index bc7b66d..a1041c2 100644
> --- a/hw/intc/armv7m_nvic.c
> +++ b/hw/intc/armv7m_nvic.c
> @@ -616,7 +616,7 @@ bool armv7m_nvic_acknowledge_irq(void *opaque)
>  vec->active = 1;
>  vec->pending = 0;
>  
> -env->v7m.exception = s->vectpending;
> +write_v7m_exception(env, s->vectpending);
>  
>  nvic_irq_update(s);
>  
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index f13b99d..509a1aa 100644
> --- a/target/arm/helper.c
> +++ b/target/arm/helper.c
> @@ -6052,21 +6052,44 @@ static bool v7m_using_psp(CPUARMState *env)
>  env->v7m.control[env->v7m.secure] & R_V7M_CONTROL_SPSEL_MASK;
>  }
>  
> -/* Switch to V7M main or process stack pointer.  */
> -static void switch_v7m_sp(CPUARMState *env, bool new_spsel)
> +/* Write to v7M CONTROL.SPSEL bit. This may change the current
> + * stack pointer between Main and Process stack pointers.
> + */
> +static void write_v7m_control_spsel(CPUARMState *env, bool new_spsel)
>  {
>  uint32_t tmp;
> -uint32_t old_control = env->v7m.control[env->v7m.secure];
> -bool old_spsel = old_control & R_V7M_CONTROL_SPSEL_MASK;
> +bool new_is_psp, old_is_psp = v7m_using_psp(env);
> +
> +env->v7m.control[env->v7m.secure] =
> +deposit32(env->v7m.control[env->v7m.secure],
> +  R_V7M_CONTROL_SPSEL_SHIFT,
> +  R_V7M_CONTROL_SPSEL_LENGTH, new_spsel);
> +
> +new_is_psp = v7m_using_psp(env);
>  
> -if (old_spsel != new_spsel) {
> +if (old_is_psp != new_is_psp) {
>  tmp = env->v7m.other_sp;
>  env->v7m.other_sp = env->regs[13];
>  env->regs[13] = tmp;
> +}
> +}
> +
> +void write_v7m_exception(CPUARMState *env, uint32_t new_exc)
> +{
> +/* Write a new value to v7m.exception, thus transitioning into or out
> + * of Handler mode; this may result in a change of active stack pointer.
> + */
> +bool new_is_psp, old_is_psp = v7m_using_psp(env);
> +uint32_t tmp;
>  
> -env->v7m.control[env->v7m.secure] = deposit32(old_control,
> - R_V7M_CONTROL_SPSEL_SHIFT,
> - R_V7M_CONTROL_SPSEL_LENGTH, new_spsel);
> +env->v7m.exception = new_exc;
> +
> +new_is_psp = v7m_using_psp(env);
> +
> +if (old_is_psp != new_is_psp) {
> +tmp = env->v7m.other_sp;
> +env->v7m.other_sp = env->regs[13];
> +env->regs[13] = tmp;
>  }
>  }
>  
> @@ -6149,13 +6172,11 @@ static uint32_t *get_v7m_sp_ptr(CPUARMState *env, 
> bool secure, bool threadmode,
>  bool want_psp = threadmode && spsel;
>  
>  if (secure == env->v7m.secure) {
> -/* Currently switch_v7m_sp switches SP as it updates SPSEL,
> - * so the SP we want is always in 

[Qemu-devel] [Bug 1719196] Re: [arm64 ocata] newly created instances are unable to raise network interfaces

[Sean Feole]

I was able to gather libvirt XMLs from both Newton and Ocata Instances,
see attached

sfeole@BSG-75:~$ diff xmlocata xmlnewton 
1,2c1,2
< 
< main type='kvm' id='1'>
---
> ubuntu@lundmark:/var/lib/nova/instances/358596e4-135d-461d-a514-84116440014c$ 
> sudo virsh dumpxml instance-0001
> 
4c4
<   7c0dcd78-d6b4-4575-a882-ee5d29c64fe0
---
>   358596e4-135d-461d-a514-84116440014c
7,9c7,9
<   
<   sfeole14
<   2017-10-05 00:58:15
---
>   
>   sfeole-newton
>   2017-10-05 01:40:39
18,19c18,19
< admin
< admin
---
> admin
>  uuid="8b8fcaf183954f45b3eb15b27c52ec94">admin
21c21
<   
---
>   
34c34
< hvm
---
> hvm
58c58
<   
---
>file='/var/lib/nova/instances/358596e4-135d-461d-a514-84116440014c/disk'/>
61c61
< 
---
>  file='/var/lib/nova/instances/_base/ab7429e8558ea27fb54f70eb92fbd0c1c07dd595'/>
70c70
<   
---
>file='/var/lib/nova/instances/358596e4-135d-461d-a514-84116440014c/disk.eph0'/>
82a83,93
> 
>   
>   
>function='0x0'/>
> 
> 
>   
>   
>   
>function='0x0'/>
> 
84,86c95,97
<   
<   
<   
---
>   
>   
>   
92c103
<   
---
>path='/var/lib/nova/instances/358596e4-135d-461d-a514-84116440014c/console.log'/>
95a107,111
> 
>   
>   
>   
> 
97c113
<   
---
>path='/var/lib/nova/instances/358596e4-135d-461d-a514-84116440014c/console.log'/>
108,113c124,125
< libvirt-7c0dcd78-d6b4-4575-a882-ee5d29c64fe0
< libvirt-7c0dcd78-d6b4-4575-a882-ee5d29c64fe0
<   
<   
< +64055:+117
< +64055:+117
---
> libvirt-358596e4-135d-461d-a514-84116440014c
> libvirt-358596e4-135d-461d-a514-84116440014c
sfeole@BSG-75:~$ 


** Attachment added: "xmlnotes.txt"
   
https://bugs.launchpad.net/libvirt/+bug/1719196/+attachment/4962430/+files/xmlnotes.txt

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

Title:
  [arm64 ocata] newly created instances are unable to raise network
  interfaces

Status in libvirt:
  New
Status in QEMU:
  New

Bug description:
  arm64 Ocata ,

  I'm testing to see I can get Ocata running on arm64 and using the
  openstack-base bundle to deploy it.  I have added the bundle to the
  log file attached to this bug.

  When I create a new instance via nova, the VM comes up and runs,
  however fails to raise its eth0 interface. This occurs on both
  internal and external networks.

  ubuntu@openstackaw:~$ nova list
  
+--+-+++-++
  | ID   | Name| Status | Task State | 
Power State | Networks   |
  
+--+-+++-++
  | dcaf6d51-f81e-4cbd-ac77-0c5d21bde57c | sfeole1 | ACTIVE | -  | 
Running | internal=10.5.5.3  |
  | aa0b8aee-5650-41f4-8fa0-aeccdc763425 | sfeole2 | ACTIVE | -  | 
Running | internal=10.5.5.13 |
  
+--+-+++-++
  ubuntu@openstackaw:~$ nova show aa0b8aee-5650-41f4-8fa0-aeccdc763425
  
+--+--+
  | Property | Value
|
  
+--+--+
  | OS-DCF:diskConfig| MANUAL   
|
  | OS-EXT-AZ:availability_zone  | nova 
|
  | OS-EXT-SRV-ATTR:host | awrep3   
|
  | OS-EXT-SRV-ATTR:hypervisor_hostname  | awrep3.maas  
|
  | OS-EXT-SRV-ATTR:instance_name| instance-0003
|
  | OS-EXT-STS:power_state   | 1
|
  | OS-EXT-STS:task_state| -
|
  | OS-EXT-STS:vm_state  | active   
|
  | OS-SRV-USG:launched_at   | 2017-09-24T14:23:08.00   
|
  | OS-SRV-USG:terminated_at | -
|
  | accessIPv4   |  
|
  | accessIPv6   |  
|
  | config_drive |  
|
  | 

Re: [Qemu-devel] [PATCH v2 0/4] blockjobs: add explicit job reaping

[John Snow]

"Oh boy, another email from John! I bet it's concisely worded."

Ha ha. I see my reputation precedes me.

"Holy crap dude, that's a lot of words you've typed down there!"

It's okay, skip to the "TLDR" for the conclusion I arrived at if you
don't care how I got there!

"Sigh, okay, John."

Yes!!

On 10/04/2017 02:27 PM, Kevin Wolf wrote:
> Am 04.10.2017 um 03:52 hat John Snow geschrieben:
>> For jobs that complete when a monitor isn't looking, there's no way to
>> tell what the job's final return code was. We need to allow jobs to
>> remain in the list until queried for reliable management.
> 
> Just a short summary of what I discussed with John on IRC:
> 
> Another important reason why we want to have an explicit end of block
> jobs is that job completion often makes changes to the graph. For a
> management tool that manages the block graph on a node level, it is a
> big problem if graph changes can happen at any point that can lead to
> bad race conditions. Giving the management tool control over the end of
> the block job makes it aware that graph changes happen.
> 
> This means that compared to this RFC series, we need to move the waiting
> earlier in the process:
> 
> 1. Block job is done and calls block_job_completed()
> 2. Wait for other block jobs in the same job transaction to complete
> 3. Send a (new) QMP event to the management tool to notify it that the
>job is ready to be reaped

Oh, I suppose to distinguish it from "COMPLETED" in that sense, because
it isn't actually COMPLETED anymore under your vision, so it requires a
new event in this proposal.

This becomes a bit messy, bumping up against both "READY" and a
transactional pre-completed state semantically. U, for lack of a
better word in the timeframe I'd like to complete this email in, let's
call this new theoretical state "PENDING"?

So presently, a job goes through the following life cycle:

1. CREATED --> RUNNING
2. RUNNING <--> PAUSED
3. RUNNING --> (READY | COMPLETED | CANCELED)
4. READY --> (COMPLETED | CANCELED)
5. (COMPLETED | CANCELED) --> NULL

Where we emit an event upon entering "READY", "COMPLETED" or "CANCELED".

My patchset here effectively adds a new optional terminal state:

5. (COMPLETED | CANCELED) --> (NULL | FINISHED)
6. FINISHED --> NULL

Where the last transition from FINISHED to NULL is performed via
block-job-reap, but notably we get to re-use the events for COMPLETED |
CANCELED to indicate the availability of this operation to be performed.

What happens in the case of transactionally managed jobs presently is
that jobs get stuck as they enter the COMPLETED|CANCELED state. If you
were to query them they behave as if they're RUNNING. There's no
discrete state that exists for this presently.

You can cancel these as normal, but I'm not sure if you can pause them,
actually. (Note to self, test that.) I think they have almost exactly
like any RUNNING job would.

What you're proposing here is the formalization of the pre-completion
state ("PENDING") and that in this state, a job outside of a transaction
can exist until it is manually told to finally, once and for all,
actually finish its business. We can use this as a hook to perform and
last graph changes so they will not come as a surprise to the management
application. Maybe this operation should be called "Finalize". Again,
for lack of a better term in the timeframe, I'll refer to it as such for
now.

I think importantly this actually distinguishes it from "reap" in that
the commit phase can still fail, so we can't let the job follow that
auto transition back to the NULL state. That means that we'd need both a
block-job-finalize AND a block-job-reap to accomplish both of the
following goals:

(1) Allow the management application to control graph changes [libvirt]
(2) Prevent auto transitions to NULL state for asynchronous clients [A
requirement mentioned by Virtuozzo]

It looks like this, overall:

1. CREATED --> RUNNING
2. RUNNING <--> PAUSED
3. RUNNING --> PENDING
via: auto transition
event: BLOCK_JOB_PENDING
4. PENDING --> (COMPLETED | CANCELED)
via: block-job-finalize
event: (COMPLETED | ERROR)
5. (COMPLETED | CANCELED) --> (NULL | FINISHED)
via: auto transition
event: none
6. FINISHED --> NULL
via: block-job-reap
event: none

"Hey, wait, where did the ready state go?"

Good question, I'm not sure how it fits in to something like "PENDING"
which is, I think NEARLY equivalent to a proposed pending->finalized
transition. Is it meaningful to have a job go from
running->ready->pending or running->pending->ready? I actually doubt it is.

The only difference really is that not all jobs use the READY -->
COMPLETE transition. We could implement it into those jobs if the job is
created with some kind of boolean, like

auto-complete: true/false

where this defaults to true, the legacy behavior.

For "mirror" we would just omit allowing people to set this setting
(auto-complete is effectively always 

Re: [Qemu-devel] [PATCH v6 01/22] instrument: Add documentation

[Emilio G. Cota]

On Thu, Oct 05, 2017 at 02:28:12 +0300, Lluís Vilanova wrote:
> Emilio G Cota writes:
> > I see some potential problems with this:
> > 1. Instrumenters' accesses could generate exceptions. I presume we'd want 
> > to avoid
> >this, or leave it as a debug-only kind of option.
> 
> The API takes care of telling you if the access could be performed
> successfully. If you access the instruction's memory representation at
> translation time, it should be able to perform the access, since QEMU's
> translation loop just had to do so in order to access that instruction (I 
> should
> check what happens in the corner case where another guest CPU changes the page
> table, since I'm not sure if the address translation functions I'm using in 
> QEMU
> will use the per-vCPU TLB cache or always traverse the page table).

That was my concern, I'd rather just perform the read once, that is, the read(s)
done by ops->insn_translate.

> > 2. Instrumenters won't know where the end of an instruction (for 
> > variable-length
> >   ISAs) or of a TB is (TB != basic block). For instructions one could have 
> > a loop
> >   where we read byte-by-byte and pass it to the decoder, something similar 
> > to
> >   what we have in the capstone code recently posted to the list (v4). For 
> > TBs,
> >   we really should have a way to delimit the length of the TB. This is 
> > further
> >   complicated if we want instrumentation to be inserted *before* a TB is
> >   translated.
> 
> > Some thoughts on the latter problem: if we want a tb_trans_pre callback, 
> > like
> > Pin/DynamoRIO provide, instead of doing two passes (one to delimit the TB 
> > and
> > call the tb_trans_pre callback, to then generate the translated TB), we 
> > could:
> >   - have a tb_trans_pre callback. This callback inserts an exec-time 
> > callback
> > with a user-defined pointer (let's call it **tb_info). The callback has
> > no arguments, perhaps just the pc.
> >   - have a tb_trans_post callback. This one passes a copy of the guest
> > instructions. The instrumenter then can allocate whatever data structure
> > to represent the TB (*tb_info), and copies this pointer to **tb_info, so
> > that at execution time, we can obtain tb_info _before_ the TB is 
> > executed.
> > After the callback returns, the copy of the guest instructions can be 
> > freed.
> >   This has two disadvantages:
> >   - We have an extra dereference to find tb_info
> >   - If it turns out that the TB should not be instrumented, we have 
> > generated
> > a callback for nothing.
> 
> That's precisely one of the reasons why I proposed adding instrumentation 
> points
> before and after events happen (e.g., instrument right after translating an
> instruction, where you know its size).
> 
> What you propose is actually a broader issue, how to allow instrumentors to 
> pass
> their own data to execution-time functions "after the fact". For this, I
> implemented "promises", a kind of generalization of what gen_icount() does 
> (you
> pass a value to the execution-time callback that is computed later during
> translation-time).

I see. I implemented what I suggested above, i.e. tb_trans_cb
(i.e. post_trans) passes an opaque descriptor of the TB (which can
be iterated over insn by insn) and the return value (void *) of this
cb will be passed by tb_exec_cb (i.e. pre_exec).  Perf-wise this
is pretty OK, turns out even if we don't end up caring about the
TB, the additional per-TB helper (which might not end up calling
a callback) does not introduce significant overhead at execution time.

The major hurdle I found is what to do when removing a plugin,
so that we avoid flushing potentially all translated code. What I ended up
doing is adding a per-TB list of "plugin_tb" descriptors, which
track these user pointers so that (1) each plugin gets the right
pointer, and (2) if n_plugins > 1, we still have a single helper
that dispatches the callbacks instead of n_plugin helpers.

If I understand correctly, with promises we directly generate
a callback, which has the promise(s) as one (or more) of its
arguments. This is neat and very flexible. However, it forces us to
retranslate the TB when the plugin is removed (if we're lazy we could
flush all TBs), and if we have several plugins, we end up with one
helper per callback, instead of a single one.
None of this is a huge deal though, I just think is worth considering.

Also, I'm not sure Peter and others would be happy with allowing
plugin code to generate arbitrary callbacks (IIRC arbitrary code
has already been ruled out). So perhaps a more restrictive option
like what I suggested above would be more palatable.

Cheers,

Emilio

Re: [Qemu-devel] [PATCH v6 01/22] instrument: Add documentation

[Lluís Vilanova]

Emilio G Cota writes:

> On Sat, Sep 30, 2017 at 00:46:33 +0300, Lluís Vilanova wrote:
>> Emilio G Cota writes:
>> > I'm not sure I understand this concept of filtering. Are you saying that in
>> > the first case, all memory accesses are instrumented, and then in the
>> > "access helper" we only call the user's callback if it's a memory write?
>> > And in the second case, we simply just generate a "write helper" instead
>> > of an "access helper". Am I understanding this correctly?
>> 
>> In the previous case (no filtering), the user callback is always called when 
>> a
>> memory access is *executed*, and the user then checks if the access mode is a
>> write to decide whether to increment a counter.
>> 
>> In this case (with filtering), a user callback is called when a memory 
>> access is
>> *translated*, and if the access mode is a write, the user generates a call 
>> to a
>> second callback that is executed every time a memory access is executed (only
>> that it is only generated for memory writes, the ones we care about).
>> 
>> Is this clearer?

> I get it now, thanks!

>> > FWIW my experiments so far show similar numbers for instrumenting each
>> > instruction (haven't done the per-tb yet). The difference is that I'm
>> > exposing to instrumenters a copy of the guest instructions (const void 
>> > *data,
>> > size_t size). These copies are kept around until TB's are flushed.
>> > Luckily there seems to be very little overhead in keeping these around,
>> > apart from the memory overhead -- but in terms of performance, the
>> > necessary allocations do not induce significant overhead.
>> 
>> To keep this use-case simpler, I added the memory access API I posted in this
>> series, where instrumenters can read guest memory (more general than passing 
>> a
>> copy of the current instruction).

> I see some potential problems with this:
> 1. Instrumenters' accesses could generate exceptions. I presume we'd want to 
> avoid
>this, or leave it as a debug-only kind of option.

The API takes care of telling you if the access could be performed
successfully. If you access the instruction's memory representation at
translation time, it should be able to perform the access, since QEMU's
translation loop just had to do so in order to access that instruction (I should
check what happens in the corner case where another guest CPU changes the page
table, since I'm not sure if the address translation functions I'm using in QEMU
will use the per-vCPU TLB cache or always traverse the page table).


> 2. Instrumenters won't know where the end of an instruction (for 
> variable-length
>   ISAs) or of a TB is (TB != basic block). For instructions one could have a 
> loop
>   where we read byte-by-byte and pass it to the decoder, something similar to
>   what we have in the capstone code recently posted to the list (v4). For TBs,
>   we really should have a way to delimit the length of the TB. This is further
>   complicated if we want instrumentation to be inserted *before* a TB is
>   translated.

> Some thoughts on the latter problem: if we want a tb_trans_pre callback, like
> Pin/DynamoRIO provide, instead of doing two passes (one to delimit the TB and
> call the tb_trans_pre callback, to then generate the translated TB), we could:
>   - have a tb_trans_pre callback. This callback inserts an exec-time callback
> with a user-defined pointer (let's call it **tb_info). The callback has
> no arguments, perhaps just the pc.
>   - have a tb_trans_post callback. This one passes a copy of the guest
> instructions. The instrumenter then can allocate whatever data structure
> to represent the TB (*tb_info), and copies this pointer to **tb_info, so
> that at execution time, we can obtain tb_info _before_ the TB is executed.
> After the callback returns, the copy of the guest instructions can be 
> freed.
>   This has two disadvantages:
>   - We have an extra dereference to find tb_info
>   - If it turns out that the TB should not be instrumented, we have generated
> a callback for nothing.

That's precisely one of the reasons why I proposed adding instrumentation points
before and after events happen (e.g., instrument right after translating an
instruction, where you know its size).

What you propose is actually a broader issue, how to allow instrumentors to pass
their own data to execution-time functions "after the fact". For this, I
implemented "promises", a kind of generalization of what gen_icount() does (you
pass a value to the execution-time callback that is computed later during
translation-time).


Cheers,
  Lluis

[Qemu-devel] [PATCH] linux-user: Add random ioctls

[Marco A L Barbosa]

I don't know how (and if it is necessary) to add buf field to
rand_pool_info struct. See
https://github.com/torvalds/linux/blob/5924bbecd0267d87c24110cbe2041b5075173a25/include/uapi/linux/random.h#L17

Signed-off-by: Marco A L Barbosa 
---
 linux-user/ioctls.h| 7 +++
 linux-user/syscall.c   | 1 +
 linux-user/syscall_defs.h  | 9 +
 linux-user/syscall_types.h | 4 
 4 files changed, 21 insertions(+)

diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index e6997ff230..9240a83f30 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -173,6 +173,13 @@
   IOCTL(SIOCGSTAMP, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timeval)))
   IOCTL(SIOCGSTAMPNS, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timespec)))

+  IOCTL(RNDGETENTCNT, IOC_R, MK_PTR(TYPE_INT))
+  IOCTL(RNDADDTOENTCNT, IOC_W, MK_PTR(MK_STRUCT(STRUCT_rand_pool_info)))
+  IOCTL(RNDGETPOOL, IOC_R, MK_PTR(TYPE_INT))
+  IOCTL(RNDADDENTROPY, IOC_W, MK_PTR(MK_STRUCT(STRUCT_rand_pool_info)))
+  IOCTL(RNDZAPENTCNT, 0, TYPE_NULL)
+  IOCTL(RNDCLEARPOOL, 0, TYPE_NULL)
+
   IOCTL(CDROMPAUSE, 0, TYPE_NULL)
   IOCTL(CDROMSTART, 0, TYPE_NULL)
   IOCTL(CDROMSTOP, 0, TYPE_NULL)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 9b6364a266..d4c21a557c 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -59,6 +59,7 @@ int __clone2(int (*fn)(void *), void *child_stack_base,
 #include 
 #include 
 #include 
+#include 
 #include "qemu-common.h"
 #ifdef CONFIG_TIMERFD
 #include 
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 40c5027e93..d14fdd82ce 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -1060,6 +1060,15 @@ struct target_pollfd {

 #define TARGET_SIOCGIWNAME 0x8B01  /* get name == wireless
protocol */

+/* From  */
+
+#define TARGET_RNDGETENTCNTTARGET_IOR('R', 0x00, int)
+#define TARGET_RNDADDTOENTCNT  TARGET_IOW('R', 0x01, int)
+#define TARGET_RNDGETPOOL  TARGET_IOR('R', 0x02, struct rand_pool_info)
+#define TARGET_RNDADDENTROPY   TARGET_IOW('R', 0x03, struct rand_pool_info)
+#define TARGET_RNDZAPENTCNTTARGET_IO('R', 0x04)
+#define TARGET_RNDCLEARPOOLTARGET_IO('R', 0x06)
+
 /* From  */

 #define TARGET_BLKROSET   TARGET_IO(0x12,93) /* set device read-only (0 =
read-write) */
diff --git a/linux-user/syscall_types.h b/linux-user/syscall_types.h
index 24631b09be..2e2e000424 100644
--- a/linux-user/syscall_types.h
+++ b/linux-user/syscall_types.h
@@ -266,3 +266,7 @@ STRUCT(blkpg_ioctl_arg,
TYPE_INT, /* flags */
TYPE_INT, /* datalen */
TYPE_PTRVOID) /* data */
+
+STRUCT(rand_pool_info,
+   TYPE_INT, /* entropy_count */
+   TYPE_INT) /* buf_size */
-- 
2.11.0

-- 
Marco A L Barbosa
http://malbarbo.pro.br
--

Re: [Qemu-devel] [PATCH v1 2/5] netduino2: Specify the valid CPUs

[Philippe Mathieu-Daudé]

>>> +const char *netduino_valid_cpus[] = { ARM_CPU_TYPE_NAME("cortex-m3"),
>> style nit,   ^^^ put entries on new line with 
>> typical 4 space alignment
> 
> Do you mean like this?
> 
> const char *netduino_valid_cpus[] = {
> ARM_CPU_TYPE_NAME("cortex-m3"),
> ARM_CPU_TYPE_NAME("cortex-m4"),
> NULL };

I suppose he meant:

static const char *netduino_valid_cpus[] = {
ARM_CPU_TYPE_NAME("cortex-m3"),
ARM_CPU_TYPE_NAME("cortex-m4"),
NULL
};

Re: [Qemu-devel] [PATCH v1 2/5] netduino2: Specify the valid CPUs

[Alistair Francis]

On Wed, Oct 4, 2017 at 4:02 AM, Igor Mammedov  wrote:
> On Tue, 3 Oct 2017 13:05:11 -0700
> Alistair Francis  wrote:
>
>> List all possible valid CPU options.
>>
>> Although the board only ever has a Cortex-M3 we mark the Cortex-M4 as
>> supported because the Netduino2 Plus supports the Cortex-M4 and the
>> Netduino2 Plus is similar to the Netduino2.
>>
>> Signed-off-by: Alistair Francis 
>> ---
>>
>> RFC v2:
>>  - Use a NULL terminated list
>>  - Add the Cortex-M4 for testing
>>
>>
>>  hw/arm/netduino2.c | 9 -
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/arm/netduino2.c b/hw/arm/netduino2.c
>> index f936017d4a..b68ecf2c08 100644
>> --- a/hw/arm/netduino2.c
>> +++ b/hw/arm/netduino2.c
>> @@ -34,18 +34,25 @@ static void netduino2_init(MachineState *machine)
>>  DeviceState *dev;
>>
>>  dev = qdev_create(NULL, TYPE_STM32F205_SOC);
>> -qdev_prop_set_string(dev, "cpu-type", ARM_CPU_TYPE_NAME("cortex-m3"));
>> +qdev_prop_set_string(dev, "cpu-type", machine->cpu_type);
>>  object_property_set_bool(OBJECT(dev), true, "realized", _fatal);
>>
>>  armv7m_load_kernel(ARM_CPU(first_cpu), machine->kernel_filename,
>> FLASH_SIZE);
>>  }
>>
>> +const char *netduino_valid_cpus[] = { ARM_CPU_TYPE_NAME("cortex-m3"),
> style nit,   ^^^ put entries on new line with 
> typical 4 space alignment

Do you mean like this?

const char *netduino_valid_cpus[] = {
ARM_CPU_TYPE_NAME("cortex-m3"),
ARM_CPU_TYPE_NAME("cortex-m4"),
NULL };

Thanks,
Alistair

>> +  ARM_CPU_TYPE_NAME("cortex-m4"),
>> +  NULL
>> +};
>
>> +
>>  static void netduino2_machine_init(MachineClass *mc)
>>  {
>>  mc->desc = "Netduino 2 Machine";
>>  mc->init = netduino2_init;
>>  mc->ignore_memory_transaction_failures = true;
>> +mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-m3");
>> +mc->valid_cpu_types = netduino_valid_cpus;
>>  }
>>
>>  DEFINE_MACHINE("netduino2", netduino2_machine_init)
>

Re: [Qemu-devel] [PATCH v1 3/5] xlnx-zcu102: Specify the valid CPUs

[Alistair Francis]

On Wed, Oct 4, 2017 at 9:34 AM, Eduardo Habkost  wrote:
> On Wed, Oct 04, 2017 at 03:08:16PM +0200, Igor Mammedov wrote:
>> On Wed, 4 Oct 2017 09:28:51 -0300
>> Eduardo Habkost  wrote:
>>
>> > On Wed, Oct 04, 2017 at 01:12:32PM +0200, Igor Mammedov wrote:
>> > > On Tue, 3 Oct 2017 14:41:17 -0700
>> > > Alistair Francis  wrote:
>> > >
>> > > > On Tue, Oct 3, 2017 at 1:36 PM, Eduardo Habkost  
>> > > > wrote:
>> > > > > On Tue, Oct 03, 2017 at 01:05:13PM -0700, Alistair Francis wrote:
>> > > > >> List all possible valid CPU options.
>> > > > >>
>> > > > >> Signed-off-by: Alistair Francis 
>> > > > >> ---
>> > > > >>
>> > > > >>  hw/arm/xlnx-zcu102.c | 10 ++
>> > > > >>  hw/arm/xlnx-zynqmp.c | 16 +---
>> > > > >>  include/hw/arm/xlnx-zynqmp.h |  1 +
>> > > > >>  3 files changed, 20 insertions(+), 7 deletions(-)
>> > > > >>
>> > > > >> diff --git a/hw/arm/xlnx-zcu102.c b/hw/arm/xlnx-zcu102.c
>> > > > >> index 519a16ed98..039649e522 100644
>> > > > >> --- a/hw/arm/xlnx-zcu102.c
>> > > > >> +++ b/hw/arm/xlnx-zcu102.c
>> > > > >> @@ -98,6 +98,8 @@ static void xlnx_zynqmp_init(XlnxZCU102 *s, 
>> > > > >> MachineState *machine)
>> > > > >>  object_property_add_child(OBJECT(machine), "soc", 
>> > > > >> OBJECT(>soc),
>> > > > >>_abort);
>> > > > >>
>> > > > >> +object_property_set_str(OBJECT(>soc), machine->cpu_type, 
>> > > > >> "cpu-type",
>> > > > >> +_fatal);
>> > > > >
>> > > > > Do you have plans to support other CPU types to xlnx_zynqmp in
>> > > > > the future?  If not, I wouldn't bother adding the cpu-type
>> > > > > property and the extra boilerplate code if it's always going to
>> > > > > be set to cortex-a53.
>> > > >
>> > > > No, it'll always be A53.
>> > > >
>> > > > I did think of that, but I also wanted to use the new option! I also
>> > > > think there is an advantage in sanely handling users '-cpu' option,
>> > > > before now we just ignored it, so I think it still does give a
>> > > > benefit. That'll be especially important on the Xilinx tree (sometimes
>> > > > people use our machines with a different CPU to 'benchmark' or test
>> > > > other CPUs with our CoSimulation setup). So I think it does make sense
>> > > > to keep in.
>> > > if cpu isn't user settable, one could just outright die if cpu_type
>> > > is not NULL and say that user's CLI is wrong.
>> > > (i.e. don't give users illusion that they allowed to use '-cpu')
>> >
>> > Isn't it exactly what this patch does, by setting:
>> > mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-a53");
>> > mc->valid_cpu_types = xlnx_zynqmp_valid_cpus;
>> > ?
>> >
>> > Except that "-cpu cortex-a53" won't die, which is a good thing.
>> allowing "-cpu cortex-a53" here, would allow to use feature parsing
>> which weren't allowed or were ignored before if user supplied '-cpu'.
>> so I'd more strict and refuse any -cpu and break CLI that tries to use it
>> if board has non configurable cpu type. It would be easier to relax
>> restriction later if necessary.
>>
>> using validate_cpus here just to have users for the new code,
>> doesn't seem like valid justification and at that it makes board
>> code more complex where it's not necessary and build in cpu type
>> works just fine.
>
> It's up to the board maintainer to decide what's the best option.
> Both features are independent from each other and can be
> implemented by machine core.

N!

My hope with this series is that eventually we could hit a state where
every single machine acts the same way with the -cpu option.

I really don't like what we do now where some boards use it, some
boards error and some boars just ignore the option. I think we should
agree on something and every machine should follow the same flow so
that users know what to expect when they use the -cpu option.

If this means we allow machines to specify they don't support the
option or only have a single element in the list of supported options
doesn't really matter, but all machines should do the same thing.

>
> In either case, the valid_cpu_types feature will be still very
> useful for boards like pxa270 and sa1110, which support -cpu but
> only with specific families of CPU types (grep for
> "strncmp(cpu_type").
>
>>
>> wrt centralized way to refuse -cpu if board doesn't support it,
>> (which is not really related to this series) following could be done:
>>
>> when cpu_model removal is completely done I plan to replace
>>   vl.c
>>  cpu_parse_cpu_model(machine_class->default_cpu_type, cpu_model)
>> with
>>  cpu_parse_cpu_model(DEFAULT_TARGET_CPU_TYPE, cpu_model)
>>
>> so that we could drop temporary guard
>>
>>  if (machine_class->default_cpu_type) {
>
> This sounds good to me, even if we don't reject -cpu on any
> board.
>
>
>>
>> with that it would be possible to tell from 

Re: [Qemu-devel] [PATCH] qdev: Check for the availability of a hotplug controller before adding a device

[Eduardo Habkost]

On Wed, Oct 04, 2017 at 09:29:54PM +0200, Thomas Huth wrote:
> On 04.10.2017 13:36, Igor Mammedov wrote:
> > On Tue,  3 Oct 2017 18:46:02 +0200
> > Thomas Huth  wrote:
> > 
> >> The qdev_unplug() function contains a g_assert(hotplug_ctrl) statement,
> >> so QEMU crashes when the user tries to device_add + device_del a device
> >> that does not have a corresponding hotplug controller. This could be
> >> provoked for a couple of devices in the past (see commit 4c93950659487c7ad
> >> or 84ebd3e8c7d4fe955 for example). So devices clearly need a hotplug
> >> controller when they are suitable for device_add.
> >> The code in qdev_device_add() already checks whether the bus has a proper
> >> hotplug controller, but for devices that do not have a corresponding bus,
> >> there is no appropriate check available. In that case we should check
> >> whether the machine itself provides a suitable hotplug controller and
> >> refuse to plug the device if none is available.
> >>
> >> Signed-off-by: Thomas Huth 
> >> ---
> >>  This is the follow-up patch from my earlier try "hw/core/qdev: Do not
> >>  allow hot-plugging without hotplug controller" ... AFAICS the function
> >>  qdev_device_add() is now the right spot to do the check.
> >>
> >>  hw/core/qdev.c | 28 
> >>  include/hw/qdev-core.h |  1 +
> >>  qdev-monitor.c |  9 +
> >>  3 files changed, 30 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/hw/core/qdev.c b/hw/core/qdev.c
> >> index 606ab53..a953ec9 100644
> >> --- a/hw/core/qdev.c
> >> +++ b/hw/core/qdev.c
> >> @@ -253,19 +253,31 @@ void qdev_set_legacy_instance_id(DeviceState *dev, 
> >> int alias_id,
> >>  dev->alias_required_for_version = required_for_version;
> >>  }
> >>  
> >> +HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev)
> >> +{
> >> +MachineState *machine;
> >> +MachineClass *mc;
> >> +Object *m_obj = qdev_get_machine();
> >> +
> >> +if (object_dynamic_cast(m_obj, TYPE_MACHINE)) {
> >> +machine = MACHINE(m_obj);
> >> +mc = MACHINE_GET_CLASS(machine);
> >> +if (mc->get_hotplug_handler) {
> >> +return mc->get_hotplug_handler(machine, dev);
> >> +}
> >> +}
> >> +
> >> +return NULL;
> >> +}
> >> +
> >>  HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev)
> >>  {
> >> -HotplugHandler *hotplug_ctrl = NULL;
> >> +HotplugHandler *hotplug_ctrl;
> >>  
> >>  if (dev->parent_bus && dev->parent_bus->hotplug_handler) {
> >>  hotplug_ctrl = dev->parent_bus->hotplug_handler;
> >> -} else if (object_dynamic_cast(qdev_get_machine(), TYPE_MACHINE)) {
> >> -MachineState *machine = MACHINE(qdev_get_machine());
> >> -MachineClass *mc = MACHINE_GET_CLASS(machine);
> >> -
> >> -if (mc->get_hotplug_handler) {
> >> -hotplug_ctrl = mc->get_hotplug_handler(machine, dev);
> >> -}
> >> +} else {
> >> +hotplug_ctrl = qdev_get_machine_hotplug_handler(dev);
> >>  }
> >>  return hotplug_ctrl;
> >>  }
> >> diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
> >> index 0891461..5aa536d 100644
> >> --- a/include/hw/qdev-core.h
> >> +++ b/include/hw/qdev-core.h
> >> @@ -285,6 +285,7 @@ DeviceState *qdev_try_create(BusState *bus, const char 
> >> *name);
> >>  void qdev_init_nofail(DeviceState *dev);
> >>  void qdev_set_legacy_instance_id(DeviceState *dev, int alias_id,
> >>   int required_for_version);
> >> +HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev);
> >>  HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev);
> >>  void qdev_unplug(DeviceState *dev, Error **errp);
> >>  void qdev_simple_device_unplug_cb(HotplugHandler *hotplug_dev,
> >> diff --git a/qdev-monitor.c b/qdev-monitor.c
> >> index 8fd6df9..2891dde 100644
> >> --- a/qdev-monitor.c
> >> +++ b/qdev-monitor.c
> >> @@ -626,6 +626,15 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error 
> >> **errp)
> >>  return NULL;
> >>  }
> >>  
> >> +/* In case we don't have a bus, there must be a machine hotplug 
> >> handler */
> >> +if (qdev_hotplug && !bus && !qdev_get_machine_hotplug_handler(dev)) {
> > current machine hotplug handler serves both cold and hot-plug so in reality 
> > it's
> > just  'plug' handler.
> > 
> > Is there a point -device/device_add devices on board that doesn't have 
> > 'hotplug'
> > handler that would wire device up properly?
> 
> Sorry, I did not get that question ... do you mean whether there's any
> code that uses qdev_device_add() to add a device without hotplug
> controller? I don't think so. It's currently only used by
> qmp_device_add() for the QMP/HMP command, in vl.c for -device and in the
> USB code for xen-usb host device. So this function currently really only
> makes sense for devices that have a hotplug controller.

I assume you are talking only about hotpluggable devices.  With

Re: [Qemu-devel] [PATCH v6 6/6] tests: Add check-qobject for equality tests

[Eric Blake]

On 10/04/2017 10:25 AM, Max Reitz wrote:
> Add a new test file (check-qobject.c) for unit tests that concern
> QObjects as a whole.
> 
> Its only purpose for now is to test the qobject_is_equal() function.
> 
> Signed-off-by: Max Reitz 
> ---
>  tests/Makefile.include |   4 +-
>  tests/check-qobject.c  | 325 
> +
>  tests/.gitignore   |   1 +
>  3 files changed, 329 insertions(+), 1 deletion(-)
>  create mode 100644 tests/check-qobject.c

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 v6 2/6] qapi/qlist: Add qlist_append_null() macro

[Eric Blake]

On 10/04/2017 10:25 AM, Max Reitz wrote:
> Besides the macro itself, this patch also adds a corresponding
> Coccinelle rule.
> 
> Signed-off-by: Max Reitz 
> ---
>  include/qapi/qmp/qlist.h | 3 +++
>  scripts/coccinelle/qobject.cocci | 3 +++
>  2 files changed, 6 insertions(+)

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 v2 3/3] qom: add helper macro DEFINE_TYPES()

[Eduardo Habkost]

On Wed, Oct 04, 2017 at 12:08:02PM +0200, Igor Mammedov wrote:
> DEFINE_TYPES() will help to simplify following routine patterns:
> 
>  static void foo_register_types(void)
>  {
> type_register_static(_type_info);
> type_register_static(_type_info);
> ...
>  }
> 
>  type_init(foo_register_types)
> 
> or
> 
>  static void foo_register_types(void)
>  {
> int i;
> 
> for (i = 0; i < ARRAY_SIZE(type_infos); i++) {
> type_register_static(_infos[i]);
> }
>  }
> 
>  type_init(foo_register_types)
> 
> with a single line
> 
>  DEFINE_TYPES(type_infos)
> 
> where types have static definition which could be consolidated in
> a single array of TypeInfo structures.
> It saves us ~6-10LOC per use case and would help to replace
> imperative foo_register_types() there with declarative style of
> type registration.
> 
> Signed-off-by: Igor Mammedov 

Reviewed-by: Eduardo Habkost 

I will wait for 1 day or 2 before queueing it.

-- 
Eduardo

Re: [Qemu-devel] [Qemu-block] [PATCH RFC] block: add block-insert-node QMP command

[Manos Pitsidianakis]

On Wed, Oct 04, 2017 at 08:09:24PM +0200, Max Reitz wrote:

On 2017-10-04 19:05, Manos Pitsidianakis wrote:

On Wed, Oct 04, 2017 at 02:49:27PM +0200, Max Reitz wrote:

On 2017-08-15 09:45, Manos Pitsidianakis wrote:

block-insert-node and its pair command block-remove-node provide runtime
insertion and removal of filter nodes.

block-insert-node takes a (parent, child) and (node, child) pair of
edges and unrefs the (parent, child) BdrvChild relationship and creates
a new (parent, node) child with the same BdrvChildRole.

This is a different approach than x-blockdev-change which uses the
driver
methods bdrv_add_child() and bdrv_del_child(),


Why? :-)

Can't we reuse x-blockdev-change? As far as I'm concerned, this was one
of its roles, and at least I don't want to have both x-blockdev-change
and these new commands.

I think it would be a good idea just to change bdrv_add_child() and
bdrv_del_child(): If the driver has a bdrv_{add,del}_child() callback,
invoke that.  If it doesn't, then just attach the child.

Of course, it may turn out that x-blockdev-change is lacking something
(e.g. a way to specify as what kind of child a new node is to be
attached).  Then we should either extend it so that it covers what it's
lacking, or replace it completely by these new commands.  In the latter
case, however, they would need to cover the existing use case which is
reconfiguring the quorum driver.  (And that would mean it would have to
invoke bdrv_add_child()/bdrv_del_child() when the driver has them.)

Max



I think the two use cases are this:

a) Adding/removing a replication child to an existing quorum node
b) Insert a filter between two existing nodes.


For me both are the same: Adding/removing nodes into/from the graph.

The difference is how those children are added (or removed, but it's the
same in reverse): In case of quorum, you can simply attach a new child
because it supports a variable number of children.  Another case where
this would work are all block drivers which support backing files (you
can freely attach/detach those).


Doesn't blockdev-snapshot-sync cover this? (I may be missing something).
Now that we're on this topic, quorum might be a good candidate for 
*_reopen when and if it lands on QMP: Reconfiguring the children could 
be done by reopening the BDS with new options.


In this series, it's not about adding or removing new children, but
instead "injecting" them into an edge: An existing child is replaced,
but it now serves as some child of the new one.

(I guess writing too much trying to get my point across, sorry...)

The gist is that for me it's not so much about "quorum" or "filter
nodes".  It's about adding a new child to a node vs. replacing an
existing one.


These are not directly compatible semantically, but as you said
x-blockdev-change can perform b) if bdrv_add_child()/bdrv_del_child()
are not implemented. Wouldn't that be unnecessary overloading?


Yes, I think it would be. :-)

So say we have these two trees in our graph:

[ Parent BDS -> Child BDS ]
[ Filter BDS -> Child BDS ]

So here's what you can do with x-blockdev-change (in theory; in practice
it can only do that for quorum):
- Remove a child, so
   [ Parent BDS -> Child BDS ]
 is split into two trees
   [ Parent BDS ] and
   [ Child BDS ]
- Add a child, so we can merge
   [ Parent BDS ] and
   [ Filter BDS -> Child BDS ]
 into
   [ Parent BDS -> Filter BDS -> Child BDS ]



Yes, of course this would have to be done in one transaction.


However, this is only possible with quorum because usually block drivers
don't support detaching children.

And here's what you can do with your commands (from what I can see):
- Replace a child (you call it insertion, but it really is just
 replacement of an existing child with the constraint that both nodes
 involved must have the same child):
   [ Parent BDS -> Child BDS ]
   [ Filter BDS -> Child BDS ]
 to
   [ Parent BDS -> Filter BDS -> Child BDS ]
- Replace a child (you call it removal, but it really is just
 replacement of a child with its child):
   [ Parent BDS -> Filter BDS -> Child BDS ]
 to
   [ Parent BDS -> Child BDS ]

This works on all BDSs because you don't change the number of children.


The interesting thing of course is that the "change" command can
actually add and remove children; where as the "insert" and "remove"
commands can only replace children.  So that's already a bit funny (one
command does two things; two commands do one thing).


That is true, but the replacing is more in terms of inserting and 
removing a node in a BDS chain.


And then of course you can simply modify x-blockdev-change so it can do
the same thing block-insert-node and block-remove-node can do: It just
needs another mode which can be used to replace a child (and its
description already states that it is supposed to be usable for that at
some point in the future).


So after I've written all of this, I feel like the new insert-node and
remove-node commands are exactly what 

Re: [Qemu-devel] [PATCH v2 2/3] qom: introduce type_register_static_array()

[Eduardo Habkost]

On Wed, Oct 04, 2017 at 12:08:01PM +0200, Igor Mammedov wrote:
> it will help to remove code duplication of registration
> static types in places that have open coded loop to
> perform batch type registering.
> 
> Signed-off-by: Igor Mammedov 

Reviewed-by: Eduardo Habkost 

I will wait for 1 day or 2 before queueing it.

-- 
Eduardo

Re: [Qemu-devel] [PATCH v2 1/3] qom: update doc comment for type_register[_static]()

[Eduardo Habkost]

On Wed, Oct 04, 2017 at 12:08:00PM +0200, Igor Mammedov wrote:
> type_register()/type_register_static() functions in current impl.
> can't fail returning 0, also none of the users check for error
> so update doc comment to reflect current behaviour.
> 
> Suggested-by: Eduardo Habkost 
> Signed-off-by: Igor Mammedov 

Reviewed-by: Eduardo Habkost 

I'm queueing it on machine-next.

-- 
Eduardo

Re: [Qemu-devel] [PATCH v4 2/2] vl: Deprecate auto-loading of qemu.conf

[Eduardo Habkost]

On Wed, Oct 04, 2017 at 09:23:08AM -0300, Eduardo Habkost wrote:
> On Wed, Oct 04, 2017 at 07:42:17AM +0200, Markus Armbruster wrote:
> > Eduardo Habkost  writes:
> > 
> > > In case there were options set in the default config file, print
> > > a warning so users can update their scripts.
> > >
> > > If somebody wants to keep the config file as-is, avoid the
> > > warning and use a command-line that will work in future QEMU
> > > versions, they can use:
> > >
> > >  $QEMU -no-user-config -readconfig /etc/qemu/qemu.conf
> > >
> > > I was going to include the suggestion in the warning message, but
> > > I thought it could make it more confusing.  The suggestion is
> > > documented in qemu-doc.texi.
> > >
> > > Signed-off-by: Eduardo Habkost 
> > > ---
> > > Changes v3 -> v4:
> > > * Use warn_report() instead of error_report("warning: ...")
> > >   (Eric Blake)
> > > * Document as a deprecated feature in qemu-doc.texi
> > > * Update subject line
> > >   (was: "vl: Print warning when a default config file is loaded")
> > >
> > > Changes v2 -> v3:
> > > * Rebase (no code changes)
> > > * Commit message update: suggest -no-user-config
> > > ---
> > >  vl.c  | 6 ++
> > >  qemu-doc.texi | 8 
> > >  2 files changed, 14 insertions(+)
> > >
> > > diff --git a/vl.c b/vl.c
> > > index 3fed457921..1b0ecdf74e 100644
> > > --- a/vl.c
> > > +++ b/vl.c
> > > @@ -3066,6 +3066,12 @@ static int qemu_read_default_config_file(void)
> > >  return ret;
> > >  }
> > >  
> > > +if (ret > 0) {
> > > +loc_set_none();
> > 
> > Sure we need this here?
> 
> IIRC we needed it in the original version, but I don't remember
> why.  I will check this.

This is the result if we don't clear error location state:

  $ ./x86_64-softmmu/qemu-system-x86_64 -monitor stdio -display none -device 
foobar
  qemu-system-x86_64: -device foobar: warning: Future QEMU versions won't load 
/usr/local/etc/qemu/qemu.conf automatically
  ^^

However, it's probably better to do this right after the loop,
just like we already do in the second option parsing loop:

Signed-off-by: Eduardo Habkost 
---
diff --git a/vl.c b/vl.c
index f9acc17c01..a8fd247d71 100644
--- a/vl.c
+++ b/vl.c
@@ -3067,7 +3067,6 @@ static int qemu_read_default_config_file(void)
 }
 
 if (ret > 0) {
-loc_set_none();
 warn_report("Future QEMU versions won't load %s automatically",
  CONFIG_QEMU_CONFDIR "/qemu.conf");
 }
@@ -3224,6 +3223,11 @@ int main(int argc, char **argv, char **envp)
 }
 }
 }
+/*
+ * Clear error location left behind by the loop.
+ * Best done right after the loop.  Do not insert code here!
+ */
+loc_set_none();
 
 if (userconfig) {
 if (qemu_read_default_config_file() < 0) {

-- 
Eduardo

Re: [Qemu-devel] [PATCH v3 0/2] Deprecate -nodefconfig

[Eduardo Habkost]

On Wed, Oct 04, 2017 at 12:00:23AM -0300, Eduardo Habkost wrote:
> Changes v2 -> v3:
> * Move documentation to the right section of qemu-doc.texi
> 
> Changes v1 -> v2:
> * Document at "Deprecated features" section in qemu-doc.texi
>   (Daniel)
> * Remove documentation for the option from qemu-options.hx
>   (Markus)
> 
> Since 2012 (commit ba6212d8 "Eliminate cpus-x86_64.conf file") we
> have no default config files that would be disabled using
> -nodefconfig.  This series cleans up the code, updates
> documentation, and document -nodefconfig as deprecated.

Paolo, if you are OK with it I'm queueing this series on
machine-next.

-- 
Eduardo

Re: [Qemu-devel] [PATCH v4 1/2] config: qemu_config_parse() return number of config groups

[Eduardo Habkost]

On Tue, Oct 03, 2017 at 11:50:42PM -0300, Eduardo Habkost wrote:
> Change qemu_config_parse() to return the number of config groups
> in success and -EINVAL on error. This will allow callers of
> qemu_config_parse() to check if something was really loaded from
> the config file.
> 
> All existing callers of qemu_config_parse() and
> qemu_read_config_file() only check if the return value was
> negative, so the change shouldn't affect them.
> 
> Reviewed-by: Markus Armbruster 
> Reviewed-by: Eric Blake 
> Signed-off-by: Eduardo Habkost 

Paolo, if you are OK with this I'm queueing it (only 1/2 by now)
on machine-next.

-- 
Eduardo

Re: [Qemu-devel] [PATCH] qdev: Check for the availability of a hotplug controller before adding a device

[Thomas Huth]

On 04.10.2017 13:36, Igor Mammedov wrote:
> On Tue,  3 Oct 2017 18:46:02 +0200
> Thomas Huth  wrote:
> 
>> The qdev_unplug() function contains a g_assert(hotplug_ctrl) statement,
>> so QEMU crashes when the user tries to device_add + device_del a device
>> that does not have a corresponding hotplug controller. This could be
>> provoked for a couple of devices in the past (see commit 4c93950659487c7ad
>> or 84ebd3e8c7d4fe955 for example). So devices clearly need a hotplug
>> controller when they are suitable for device_add.
>> The code in qdev_device_add() already checks whether the bus has a proper
>> hotplug controller, but for devices that do not have a corresponding bus,
>> there is no appropriate check available. In that case we should check
>> whether the machine itself provides a suitable hotplug controller and
>> refuse to plug the device if none is available.
>>
>> Signed-off-by: Thomas Huth 
>> ---
>>  This is the follow-up patch from my earlier try "hw/core/qdev: Do not
>>  allow hot-plugging without hotplug controller" ... AFAICS the function
>>  qdev_device_add() is now the right spot to do the check.
>>
>>  hw/core/qdev.c | 28 
>>  include/hw/qdev-core.h |  1 +
>>  qdev-monitor.c |  9 +
>>  3 files changed, 30 insertions(+), 8 deletions(-)
>>
>> diff --git a/hw/core/qdev.c b/hw/core/qdev.c
>> index 606ab53..a953ec9 100644
>> --- a/hw/core/qdev.c
>> +++ b/hw/core/qdev.c
>> @@ -253,19 +253,31 @@ void qdev_set_legacy_instance_id(DeviceState *dev, int 
>> alias_id,
>>  dev->alias_required_for_version = required_for_version;
>>  }
>>  
>> +HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev)
>> +{
>> +MachineState *machine;
>> +MachineClass *mc;
>> +Object *m_obj = qdev_get_machine();
>> +
>> +if (object_dynamic_cast(m_obj, TYPE_MACHINE)) {
>> +machine = MACHINE(m_obj);
>> +mc = MACHINE_GET_CLASS(machine);
>> +if (mc->get_hotplug_handler) {
>> +return mc->get_hotplug_handler(machine, dev);
>> +}
>> +}
>> +
>> +return NULL;
>> +}
>> +
>>  HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev)
>>  {
>> -HotplugHandler *hotplug_ctrl = NULL;
>> +HotplugHandler *hotplug_ctrl;
>>  
>>  if (dev->parent_bus && dev->parent_bus->hotplug_handler) {
>>  hotplug_ctrl = dev->parent_bus->hotplug_handler;
>> -} else if (object_dynamic_cast(qdev_get_machine(), TYPE_MACHINE)) {
>> -MachineState *machine = MACHINE(qdev_get_machine());
>> -MachineClass *mc = MACHINE_GET_CLASS(machine);
>> -
>> -if (mc->get_hotplug_handler) {
>> -hotplug_ctrl = mc->get_hotplug_handler(machine, dev);
>> -}
>> +} else {
>> +hotplug_ctrl = qdev_get_machine_hotplug_handler(dev);
>>  }
>>  return hotplug_ctrl;
>>  }
>> diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
>> index 0891461..5aa536d 100644
>> --- a/include/hw/qdev-core.h
>> +++ b/include/hw/qdev-core.h
>> @@ -285,6 +285,7 @@ DeviceState *qdev_try_create(BusState *bus, const char 
>> *name);
>>  void qdev_init_nofail(DeviceState *dev);
>>  void qdev_set_legacy_instance_id(DeviceState *dev, int alias_id,
>>   int required_for_version);
>> +HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev);
>>  HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev);
>>  void qdev_unplug(DeviceState *dev, Error **errp);
>>  void qdev_simple_device_unplug_cb(HotplugHandler *hotplug_dev,
>> diff --git a/qdev-monitor.c b/qdev-monitor.c
>> index 8fd6df9..2891dde 100644
>> --- a/qdev-monitor.c
>> +++ b/qdev-monitor.c
>> @@ -626,6 +626,15 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error 
>> **errp)
>>  return NULL;
>>  }
>>  
>> +/* In case we don't have a bus, there must be a machine hotplug handler 
>> */
>> +if (qdev_hotplug && !bus && !qdev_get_machine_hotplug_handler(dev)) {
> current machine hotplug handler serves both cold and hot-plug so in reality 
> it's
> just  'plug' handler.
> 
> Is there a point -device/device_add devices on board that doesn't have 
> 'hotplug'
> handler that would wire device up properly?

Sorry, I did not get that question ... do you mean whether there's any
code that uses qdev_device_add() to add a device without hotplug
controller? I don't think so. It's currently only used by
qmp_device_add() for the QMP/HMP command, in vl.c for -device and in the
USB code for xen-usb host device. So this function currently really only
makes sense for devices that have a hotplug controller.

 Thomas

Re: [Qemu-devel] [PATCH v1 00/12] ARM v8.1 simd + v8.3 complex insns

[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.

Type: series
Message-id: 20171004184325.24157-1-richard.hender...@linaro.org
Subject: [Qemu-devel] [PATCH v1 00/12] ARM v8.1 simd + v8.3 complex insns

=== 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-build@min-glib
time make docker-test-mingw@fedora
time make docker-test-block@fedora
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag]   
patchew/20171004184325.24157-1-richard.hender...@linaro.org -> 
patchew/20171004184325.24157-1-richard.hender...@linaro.org
Switched to a new branch 'test'
d2c19ec997 target/arm: Decode aa32 armv8.3 2-reg-index
a347025424 target/arm: Decode aa32 armv8.3 3-same
2cd36cf971 target/arm: Decode aa64 armv8.3 fcmla
9cfb03f4ce target/arm: Decode aa64 armv8.3 fcadd
28d1be2ecd target/arm: Add ARM_FEATURE_V8_FCMA
c701cad8be target/arm: Decode aa32 armv8.1 two reg and a scalar
a461fab907 target/arm: Decode aa32 armv8.1 three same
c6e3f60eb7 target/arm: Decode aa64 armv8.1 scalar/vector x indexed element
62aae53003 target/arm: Decode aa64 armv8.1 three same extra
0ced82a183 target/arm: Decode aa64 armv8.1 scalar three same extra
e1a1d86d50 target/arm: Add ARM_FEATURE_V8_1_SIMD
506b895705 HACK: use objdump disas

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into '/var/tmp/patchew-tester-tmp-14wodfv9/src/dtc'...
Submodule path 'dtc': checked out '558cd81bdd432769b59bff01240c44f82cfb1a9d'
  BUILD   centos6
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-14wodfv9/src'
  GEN docker-src.2017-10-04-14.55.54.8524/qemu.tar
  COPYRUNNER
RUN test-quick in qemu:centos6 
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
bison-2.4.1-5.el6.x86_64
bzip2-devel-1.0.5-7.el6_0.x86_64
ccache-3.1.6-2.el6.x86_64
csnappy-devel-0-6.20150729gitd7bc683.el6.x86_64
flex-2.5.35-9.el6.x86_64
gcc-4.4.7-18.el6.x86_64
gettext-0.17-18.el6.x86_64
git-1.7.1-9.el6_9.x86_64
glib2-devel-2.28.8-9.el6.x86_64
libepoxy-devel-1.2-3.el6.x86_64
libfdt-devel-1.4.0-1.el6.x86_64
librdmacm-devel-1.0.21-0.el6.x86_64
lzo-devel-2.03-3.1.el6_5.1.x86_64
make-3.81-23.el6.x86_64
mesa-libEGL-devel-11.0.7-4.el6.x86_64
mesa-libgbm-devel-11.0.7-4.el6.x86_64
package g++ is not installed
pixman-devel-0.32.8-1.el6.x86_64
spice-glib-devel-0.26-8.el6.x86_64
spice-server-devel-0.12.4-16.el6.x86_64
tar-1.23-15.el6_8.x86_64
vte-devel-0.25.1-9.el6.x86_64
xen-devel-4.6.6-2.el6.x86_64
zlib-devel-1.2.3-29.el6.x86_64

Environment variables:
PACKAGES=bison bzip2-devel ccache csnappy-devel flex g++
 gcc gettext git glib2-devel libepoxy-devel libfdt-devel
 librdmacm-devel lzo-devel make mesa-libEGL-devel 
mesa-libgbm-devel pixman-devel SDL-devel spice-glib-devel 
spice-server-devel tar vte-devel xen-devel zlib-devel
HOSTNAME=53f02e0e3e2d
TERM=xterm
MAKEFLAGS= -j8
J=8
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
PATH=/usr/lib/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
TARGET_LIST=
SHLVL=1
HOME=/root
TEST_DIR=/tmp/qemu-test
FEATURES= dtc
DEBUG=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/tmp/qemu-test/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/tmp/qemu-test/install
BIOS directory/tmp/qemu-test/install/share/qemu
firmware path /tmp/qemu-test/install/share/qemu-firmware
binary directory  /tmp/qemu-test/install/bin
library directory /tmp/qemu-test/install/lib
module directory  /tmp/qemu-test/install/lib/qemu
libexec directory /tmp/qemu-test/install/libexec
include directory /tmp/qemu-test/install/include
config directory  /tmp/qemu-test/install/etc
local state directory   /tmp/qemu-test/install/var
Manual directory  /tmp/qemu-test/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   -DNCURSES_WIDECHAR   
-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 

Re: [Qemu-devel] [PATCH v1 00/12] ARM v8.1 simd + v8.3 complex insns

[no-reply]

Hi,

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

Type: series
Message-id: 20171004184325.24157-1-richard.hender...@linaro.org
Subject: [Qemu-devel] [PATCH v1 00/12] ARM v8.1 simd + v8.3 complex insns

=== 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'
d2c19ec997 target/arm: Decode aa32 armv8.3 2-reg-index
a347025424 target/arm: Decode aa32 armv8.3 3-same
2cd36cf971 target/arm: Decode aa64 armv8.3 fcmla
9cfb03f4ce target/arm: Decode aa64 armv8.3 fcadd
28d1be2ecd target/arm: Add ARM_FEATURE_V8_FCMA
c701cad8be target/arm: Decode aa32 armv8.1 two reg and a scalar
a461fab907 target/arm: Decode aa32 armv8.1 three same
c6e3f60eb7 target/arm: Decode aa64 armv8.1 scalar/vector x indexed element
62aae53003 target/arm: Decode aa64 armv8.1 three same extra
0ced82a183 target/arm: Decode aa64 armv8.1 scalar three same extra
e1a1d86d50 target/arm: Add ARM_FEATURE_V8_1_SIMD
506b895705 HACK: use objdump disas

=== OUTPUT BEGIN ===
Checking PATCH 1/12: HACK: use objdump disas...
Checking PATCH 2/12: target/arm: Add ARM_FEATURE_V8_1_SIMD...
Checking PATCH 3/12: target/arm: Decode aa64 armv8.1 scalar three same extra...
ERROR: Macros with complex values should be enclosed in parenthesis
#54: FILE: target/arm/advsimd_helper.c:27:
+#define SET_QC() env->vfp.xregs[ARM_VFP_FPSCR] |= CPSR_Q

total: 1 errors, 0 warnings, 227 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 4/12: target/arm: Decode aa64 armv8.1 three same extra...
Checking PATCH 5/12: target/arm: Decode aa64 armv8.1 scalar/vector x indexed 
element...
Checking PATCH 6/12: target/arm: Decode aa32 armv8.1 three same...
Checking PATCH 7/12: target/arm: Decode aa32 armv8.1 two reg and a scalar...
Checking PATCH 8/12: target/arm: Add ARM_FEATURE_V8_FCMA...
Checking PATCH 9/12: target/arm: Decode aa64 armv8.3 fcadd...
Checking PATCH 10/12: target/arm: Decode aa64 armv8.3 fcmla...
Checking PATCH 11/12: target/arm: Decode aa32 armv8.3 3-same...
Checking PATCH 12/12: target/arm: Decode aa32 armv8.3 2-reg-index...
=== 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

[Qemu-devel] [PATCH v1 12/12] target/arm: Decode aa32 armv8.3 2-reg-index

[Richard Henderson]

Signed-off-by: Richard Henderson 
---
 target/arm/translate.c | 53 ++
 1 file changed, 53 insertions(+)

diff --git a/target/arm/translate.c b/target/arm/translate.c
index 48f30e2621..50ef2f1f21 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -7693,6 +7693,53 @@ static int disas_neon_insn_cp8_3same(DisasContext *s, 
uint32_t insn)
 return 0;
 }
 
+/* ARMv8.3 reclaims a portion of the CDP2 coprocessor 8 space.  */
+
+static int disas_neon_insn_cp8_index(DisasContext *s, uint32_t insn)
+{
+int rd, rn, rm, rot, size, opr_sz;
+TCGv_ptr fpst;
+bool q;
+
+/* FIXME: this access check should not take precedence over UNDEF
+ * for invalid encodings; we will generate incorrect syndrome information
+ * for attempts to execute invalid vfp/neon encodings with FP disabled.
+ */
+if (s->fp_excp_el) {
+gen_exception_insn(s, 4, EXCP_UDEF,
+   syn_fp_access_trap(1, 0xe, false), s->fp_excp_el);
+return 0;
+}
+if (!s->vfp_enabled || !arm_dc_feature(s, ARM_FEATURE_V8_FCMA)) {
+return 1;
+}
+
+q = extract32(insn, 6, 1);
+size = extract32(insn, 23, 1);
+
+if (size == 0) { /* FIXME: fp16 support */
+return 1;
+}
+
+VFP_DREG_D(rd, insn);
+VFP_DREG_N(rn, insn);
+VFP_DREG_M(rm, insn);
+if ((rd | rn) & q) {
+return 1;
+}
+
+/* This entire space is VCMLA (indexed).  */
+rot = extract32(insn, 20, 2);
+opr_sz = (1 + q) * 8;
+fpst = get_fpstatus_ptr(1);
+tcg_gen_gvec_3_ptr(vfp_reg_offset(1, rd),
+   vfp_reg_offset(1, rn),
+   vfp_reg_offset(1, rm), fpst,
+   opr_sz, opr_sz, rot, gen_helper_gvec_fcmlas_idx);
+tcg_temp_free_ptr(fpst);
+return 0;
+}
+
 static int disas_coproc_insn(DisasContext *s, uint32_t insn)
 {
 int cpnum, is64, crn, crm, opc1, opc2, isread, rt, rt2;
@@ -8414,6 +8461,12 @@ static void disas_arm_insn(DisasContext *s, unsigned int 
insn)
 goto illegal_op;
 }
 return;
+} else if ((insn & 0x0f000f10) == 0x0e000800) {
+/* ARMv8.3 neon cdp2 coprocessor 8 extension.  */
+if (disas_neon_insn_cp8_index(s, insn)) {
+goto illegal_op;
+}
+return;
 } else if ((insn & 0x0fe0) == 0x0c40) {
 /* Coprocessor double register transfer.  */
 ARCH(5TE);
-- 
2.13.6

[Qemu-devel] [PATCH v1 11/12] target/arm: Decode aa32 armv8.3 3-same

[Richard Henderson]

Signed-off-by: Richard Henderson 
---
 target/arm/translate.c | 69 ++
 1 file changed, 69 insertions(+)

diff --git a/target/arm/translate.c b/target/arm/translate.c
index ee1e364fb5..48f30e2621 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -7630,6 +7630,69 @@ static int disas_neon_data_insn(DisasContext *s, 
uint32_t insn)
 return 0;
 }
 
+/* ARMv8.3 reclaims a portion of the LDC2/STC2 coprocessor 8 space.  */
+
+static int disas_neon_insn_cp8_3same(DisasContext *s, uint32_t insn)
+{
+void (*fn_gvec_ptr)(TCGv_ptr, TCGv_ptr, TCGv_ptr, TCGv_ptr, TCGv_i32);
+int rd, rn, rm, rot, size, opr_sz;
+TCGv_ptr fpst;
+bool q;
+
+/* FIXME: this access check should not take precedence over UNDEF
+ * for invalid encodings; we will generate incorrect syndrome information
+ * for attempts to execute invalid vfp/neon encodings with FP disabled.
+ */
+if (s->fp_excp_el) {
+gen_exception_insn(s, 4, EXCP_UDEF,
+   syn_fp_access_trap(1, 0xe, false), s->fp_excp_el);
+return 0;
+}
+if (!s->vfp_enabled) {
+return 1;
+}
+if (!arm_dc_feature(s, ARM_FEATURE_V8_FCMA)) {
+return 1;
+}
+
+q = extract32(insn, 6, 1);
+size = extract32(insn, 20, 1);
+VFP_DREG_D(rd, insn);
+VFP_DREG_N(rn, insn);
+VFP_DREG_M(rm, insn);
+if ((rd | rn | rm) & q) {
+return 1;
+}
+
+if (size == 0) { /* FIXME: fp16 support */
+return 1;
+}
+
+if (extract32(insn, 21, 1)) {
+/* VCMLA */
+rot = extract32(insn, 23, 2);
+fn_gvec_ptr = gen_helper_gvec_fcmlas;
+} else if (extract32(insn, 23, 1)) {
+/* VCADD */
+rot = extract32(insn, 24, 1);
+fn_gvec_ptr = gen_helper_gvec_fcadds;
+} else {
+/* Assuming the register fields remain, only bit 24 remains undecoded:
+ * _110x_0d0s___1000_nqm0_
+ */
+return 1;
+}
+
+opr_sz = (1 + q) * 8;
+fpst = get_fpstatus_ptr(1);
+tcg_gen_gvec_3_ptr(vfp_reg_offset(1, rd),
+   vfp_reg_offset(1, rn),
+   vfp_reg_offset(1, rm), fpst,
+   opr_sz, opr_sz, rot, fn_gvec_ptr);
+tcg_temp_free_ptr(fpst);
+return 0;
+}
+
 static int disas_coproc_insn(DisasContext *s, uint32_t insn)
 {
 int cpnum, is64, crn, crm, opc1, opc2, isread, rt, rt2;
@@ -8345,6 +8408,12 @@ static void disas_arm_insn(DisasContext *s, unsigned int 
insn)
 }
 }
 }
+} else if ((insn & 0x0e000f10) == 0x0c000800) {
+/* ARMv8.3 neon ldc2/stc2 coprocessor 8 extension.  */
+if (disas_neon_insn_cp8_3same(s, insn)) {
+goto illegal_op;
+}
+return;
 } else if ((insn & 0x0fe0) == 0x0c40) {
 /* Coprocessor double register transfer.  */
 ARCH(5TE);
-- 
2.13.6

[Qemu-devel] [PATCH v1 08/12] target/arm: Add ARM_FEATURE_V8_FCMA

[Richard Henderson]

Signed-off-by: Richard Henderson 
---
 target/arm/cpu.h | 1 +
 linux-user/elfload.c | 1 +
 target/arm/cpu.c | 1 +
 target/arm/cpu64.c   | 1 +
 4 files changed, 4 insertions(+)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index c5c9cef834..fdf72534d0 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1313,6 +1313,7 @@ enum arm_features {
 ARM_FEATURE_M_SECURITY, /* M profile Security Extension */
 ARM_FEATURE_JAZELLE, /* has (trivial) Jazelle implementation */
 ARM_FEATURE_V8_1_SIMD, /* has ARMv8.1-SIMD */
+ARM_FEATURE_V8_FCMA, /* has complex number part of v8.3 extensions.  */
 };
 
 static inline int arm_feature(CPUARMState *env, int feature)
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 003d9420b7..788e46229b 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -541,6 +541,7 @@ static uint32_t get_elf_hwcap(void)
 GET_FEATURE(ARM_FEATURE_V8_SHA256, ARM_HWCAP_A64_SHA2);
 GET_FEATURE(ARM_FEATURE_CRC, ARM_HWCAP_A64_CRC32);
 GET_FEATURE(ARM_FEATURE_V8_1_SIMD, ARM_HWCAP_A64_ASIMDRDM);
+GET_FEATURE(ARM_FEATURE_V8_FCMA, ARM_HWCAP_A64_FCMA);
 #undef GET_FEATURE
 
 return hwcaps;
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 276c996e9f..722d2806a7 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1604,6 +1604,7 @@ static void arm_any_initfn(Object *obj)
 set_feature(>env, ARM_FEATURE_V8_PMULL);
 set_feature(>env, ARM_FEATURE_CRC);
 set_feature(>env, ARM_FEATURE_V8_1_SIMD);
+set_feature(>env, ARM_FEATURE_V8_FCMA);
 cpu->midr = 0x;
 }
 #endif
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index b05c904ad2..96320ac0d6 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -227,6 +227,7 @@ static void aarch64_any_initfn(Object *obj)
 set_feature(>env, ARM_FEATURE_V8_PMULL);
 set_feature(>env, ARM_FEATURE_CRC);
 set_feature(>env, ARM_FEATURE_V8_1_SIMD);
+set_feature(>env, ARM_FEATURE_V8_FCMA);
 cpu->ctr = 0x80038003; /* 32 byte I and D cacheline size, VIPT icache */
 cpu->dcz_blocksize = 7; /*  512 bytes */
 }
-- 
2.13.6

[Qemu-devel] [PATCH v1 09/12] target/arm: Decode aa64 armv8.3 fcadd

[Richard Henderson]

Signed-off-by: Richard Henderson 
---
 target/arm/helper.h |  5 
 target/arm/advsimd_helper.c | 66 +
 target/arm/translate-a64.c  | 33 ++-
 3 files changed, 103 insertions(+), 1 deletion(-)

diff --git a/target/arm/helper.h b/target/arm/helper.h
index 67583b3c2e..350e2fa0e1 100644
--- a/target/arm/helper.h
+++ b/target/arm/helper.h
@@ -551,6 +551,11 @@ DEF_HELPER_FLAGS_5(gvec_qrdmlah_s32, TCG_CALL_NO_RWG,
 DEF_HELPER_FLAGS_5(gvec_qrdmlsh_s32, TCG_CALL_NO_RWG,
void, ptr, ptr, ptr, ptr, i32)
 
+DEF_HELPER_FLAGS_5(gvec_fcadds, TCG_CALL_NO_RWG,
+   void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_fcaddd, TCG_CALL_NO_RWG,
+   void, ptr, ptr, ptr, ptr, i32)
+
 #ifdef TARGET_AARCH64
 #include "helper-a64.h"
 #endif
diff --git a/target/arm/advsimd_helper.c b/target/arm/advsimd_helper.c
index b0f4b02a12..fe2e0cbcef 100644
--- a/target/arm/advsimd_helper.c
+++ b/target/arm/advsimd_helper.c
@@ -24,6 +24,18 @@
 #include "tcg/tcg-gvec-desc.h"
 
 
+/* Note that vector data is stored in host-endian 64-bit chunks,
+   so addressing units smaller than that needs a host-endian fixup.  */
+#ifdef HOST_WORDS_BIGENDIAN
+#define H1(x)  ((x) ^ 7)
+#define H2(x)  ((x) ^ 3)
+#define H4(x)  ((x) ^ 1)
+#else
+#define H1(x)  (x)
+#define H2(x)  (x)
+#define H4(x)  (x)
+#endif
+
 #define SET_QC() env->vfp.xregs[ARM_VFP_FPSCR] |= CPSR_Q
 
 static void clear_tail(void *vd, uintptr_t opr_sz, uintptr_t max_sz)
@@ -177,3 +189,57 @@ void HELPER(gvec_qrdmlsh_s32)(void *vd, void *vn, void *vm,
 }
 clear_tail(d, opr_sz, simd_maxsz(desc));
 }
+
+void HELPER(gvec_fcadds)(void *vd, void *vn, void *vm,
+ void *vfpst, uint32_t desc)
+{
+uintptr_t opr_sz = simd_oprsz(desc);
+float32 *d = vd;
+float32 *n = vn;
+float32 *m = vm;
+float_status *fpst = vfpst;
+uint32_t neg_real = extract32(desc, SIMD_DATA_SHIFT, 1);
+uint32_t neg_imag = neg_real ^ 1;
+uintptr_t i;
+
+neg_real <<= 31;
+neg_imag <<= 31;
+
+for (i = 0; i < opr_sz / 4; i += 2) {
+float32 e0 = n[H4(i)];
+float32 e1 = m[H4(i + 1)] ^ neg_imag;
+float32 e2 = n[H4(i + 1)];
+float32 e3 = m[H4(i)] ^ neg_real;
+
+d[H4(i)] = float32_add(e0, e1, fpst);
+d[H4(i + 1)] = float32_add(e2, e3, fpst);
+}
+clear_tail(d, opr_sz, simd_maxsz(desc));
+}
+
+void HELPER(gvec_fcaddd)(void *vd, void *vn, void *vm,
+ void *vfpst, uint32_t desc)
+{
+uintptr_t opr_sz = simd_oprsz(desc);
+float64 *d = vd;
+float64 *n = vn;
+float64 *m = vm;
+float_status *fpst = vfpst;
+uint64_t neg_real = extract64(desc, SIMD_DATA_SHIFT, 1);
+uint64_t neg_imag = neg_real ^ 1;
+uintptr_t i;
+
+neg_real <<= 63;
+neg_imag <<= 63;
+
+for (i = 0; i < opr_sz / 8; i += 2) {
+float64 e0 = n[i];
+float64 e1 = m[i + 1] ^ neg_imag;
+float64 e2 = n[i + 1];
+float64 e3 = m[i] ^ neg_real;
+
+d[i] = float64_add(e0, e1, fpst);
+d[i + 1] = float64_add(e2, e3, fpst);
+}
+clear_tail(d, opr_sz, simd_maxsz(desc));
+}
diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index b02aad8cd7..f13a945c43 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -9890,7 +9890,8 @@ static void disas_simd_three_reg_same_extra(DisasContext 
*s, uint32_t insn)
 int size = extract32(insn, 22, 2);
 bool u = extract32(insn, 29, 1);
 bool is_q = extract32(insn, 30, 1);
-int feature;
+int feature, data;
+TCGv_ptr fpst;
 
 if (!u) {
 unallocated_encoding(s);
@@ -9906,6 +9907,14 @@ static void disas_simd_three_reg_same_extra(DisasContext 
*s, uint32_t insn)
 }
 feature = ARM_FEATURE_V8_1_SIMD;
 break;
+case 0xc: /* FCADD, #90 */
+case 0xe: /* FCADD, #270 */
+if (size != 2 && (size != 3 || !is_q)) { /* FIXME: fp16 support */
+unallocated_encoding(s);
+return;
+}
+feature = ARM_FEATURE_V8_FCMA;
+break;
 default:
 unallocated_encoding(s);
 return;
@@ -9952,6 +9961,28 @@ static void disas_simd_three_reg_same_extra(DisasContext 
*s, uint32_t insn)
0, fn_gvec_ptr);
 break;
 
+case 0xc: /* FCADD, #90 */
+case 0xe: /* FCADD, #270 */
+switch (size) {
+case 2:
+fn_gvec_ptr = gen_helper_gvec_fcadds;
+break;
+case 3:
+fn_gvec_ptr = gen_helper_gvec_fcaddd;
+break;
+default:
+g_assert_not_reached();
+}
+data = extract32(opcode, 1, 1);
+fpst = get_fpstatus_ptr();
+tcg_gen_gvec_3_ptr(vec_full_reg_offset(s, rd),
+   vec_full_reg_offset(s, rn),
+   vec_full_reg_offset(s, rm), fpst,
+  

[Qemu-devel] [PATCH v1 06/12] target/arm: Decode aa32 armv8.1 three same

[Richard Henderson]

Signed-off-by: Richard Henderson 
---
 target/arm/translate.c | 83 ++
 1 file changed, 64 insertions(+), 19 deletions(-)

diff --git a/target/arm/translate.c b/target/arm/translate.c
index ab1a12a1b8..0cd58710b3 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -25,6 +25,7 @@
 #include "disas/disas.h"
 #include "exec/exec-all.h"
 #include "tcg-op.h"
+#include "tcg-op-gvec.h"
 #include "qemu/log.h"
 #include "qemu/bitops.h"
 #include "arm_ldst.h"
@@ -5334,9 +5335,9 @@ static void gen_neon_narrow_op(int op, int u, int size,
 #define NEON_3R_VPMAX 20
 #define NEON_3R_VPMIN 21
 #define NEON_3R_VQDMULH_VQRDMULH 22
-#define NEON_3R_VPADD 23
+#define NEON_3R_VPADD_VQRDMLAH 23
 #define NEON_3R_SHA 24 /* SHA1C,SHA1P,SHA1M,SHA1SU0,SHA256H{2},SHA256SU1 */
-#define NEON_3R_VFM 25 /* VFMA, VFMS : float fused multiply-add */
+#define NEON_3R_VFM_VQRDMLSH 25 /* VFMA, VFMS : float fused multiply-add */
 #define NEON_3R_FLOAT_ARITH 26 /* float VADD, VSUB, VPADD, VABD */
 #define NEON_3R_FLOAT_MULTIPLY 27 /* float VMLA, VMLS, VMUL */
 #define NEON_3R_FLOAT_CMP 28 /* float VCEQ, VCGE, VCGT */
@@ -5368,9 +5369,9 @@ static const uint8_t neon_3r_sizes[] = {
 [NEON_3R_VPMAX] = 0x7,
 [NEON_3R_VPMIN] = 0x7,
 [NEON_3R_VQDMULH_VQRDMULH] = 0x6,
-[NEON_3R_VPADD] = 0x7,
+[NEON_3R_VPADD_VQRDMLAH] = 0x7,
 [NEON_3R_SHA] = 0xf, /* size field encodes op type */
-[NEON_3R_VFM] = 0x5, /* size bit 1 encodes op */
+[NEON_3R_VFM_VQRDMLSH] = 0x7, /* For VFM, size bit 1 encodes op */
 [NEON_3R_FLOAT_ARITH] = 0x5, /* size bit 1 encodes op */
 [NEON_3R_FLOAT_MULTIPLY] = 0x5, /* size bit 1 encodes op */
 [NEON_3R_FLOAT_CMP] = 0x5, /* size bit 1 encodes op */
@@ -5556,6 +5557,7 @@ static const uint8_t neon_2rm_sizes[] = {
 
 static int disas_neon_data_insn(DisasContext *s, uint32_t insn)
 {
+void (*fn_gvec_ptr)(TCGv_ptr, TCGv_ptr, TCGv_ptr, TCGv_ptr, TCGv_i32);
 int op;
 int q;
 int rd, rn, rm;
@@ -5600,12 +5602,12 @@ static int disas_neon_data_insn(DisasContext *s, 
uint32_t insn)
 if (q && ((rd | rn | rm) & 1)) {
 return 1;
 }
-/*
- * The SHA-1/SHA-256 3-register instructions require special treatment
- * here, as their size field is overloaded as an op type selector, and
- * they all consume their input in a single pass.
- */
-if (op == NEON_3R_SHA) {
+switch (op) {
+case NEON_3R_SHA:
+/* The SHA-1/SHA-256 3-register instructions require special
+ * treatment here, as their size field is overloaded as an
+ * op type selector, and they all consume their input in a
+ * single pass.  */
 if (!q) {
 return 1;
 }
@@ -5642,6 +5644,53 @@ static int disas_neon_data_insn(DisasContext *s, 
uint32_t insn)
 tcg_temp_free_i32(tmp2);
 tcg_temp_free_i32(tmp3);
 return 0;
+
+case NEON_3R_VPADD_VQRDMLAH:
+if (!u) {
+break;  /* VPADD */
+}
+/* VQRDMLAH */
+switch (size) {
+case 1:
+fn_gvec_ptr = gen_helper_gvec_qrdmlah_s16;
+break;
+case 2:
+fn_gvec_ptr = gen_helper_gvec_qrdmlah_s32;
+break;
+default:
+return 1;
+}
+do_vqrdmlx:
+if (arm_dc_feature(s, ARM_FEATURE_V8_1_SIMD)) {
+int opr_sz = (1 + q) * 8;
+tcg_gen_gvec_3_ptr(vfp_reg_offset(1, rd),
+   vfp_reg_offset(1, rn),
+   vfp_reg_offset(1, rm), cpu_env,
+   opr_sz, opr_sz, 0, fn_gvec_ptr);
+return 0;
+}
+return 1;
+
+case NEON_3R_VFM_VQRDMLSH:
+if (!u) {
+/* VFM, VFMS */
+if ((5 & (1 << size)) == 0) {
+return 1;
+}
+break;
+}
+/* VQRDMLSH */
+switch (size) {
+case 1:
+fn_gvec_ptr = gen_helper_gvec_qrdmlsh_s16;
+break;
+case 2:
+fn_gvec_ptr = gen_helper_gvec_qrdmlsh_s32;
+break;
+default:
+return 1;
+}
+goto do_vqrdmlx;
 }
 if (size == 3 && op != NEON_3R_LOGIC) {
 /* 64-bit element instructions. */
@@ -5727,11 +5776,7 @@ static int disas_neon_data_insn(DisasContext *s, 
uint32_t insn)
 rm = rtmp;
 }
 break;
-case NEON_3R_VPADD:
-if (u) {
-return 1;
-}
-/* Fall through */
+case NEON_3R_VPADD_VQRDMLAH:
 case NEON_3R_VPMAX:
 case NEON_3R_VPMIN:
   

[Qemu-devel] [PATCH v1 05/12] target/arm: Decode aa64 armv8.1 scalar/vector x indexed element

[Richard Henderson]

Signed-off-by: Richard Henderson 
---
 target/arm/translate-a64.c | 46 --
 1 file changed, 40 insertions(+), 6 deletions(-)

diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index 0ea47a9dff..b02aad8cd7 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -10749,12 +10749,23 @@ static void disas_simd_indexed(DisasContext *s, 
uint32_t insn)
 is_long = true;
 /* fall through */
 case 0xc: /* SQDMULH */
-case 0xd: /* SQRDMULH */
 if (u) {
 unallocated_encoding(s);
 return;
 }
 break;
+case 0xd: /* SQRDMULH / SQRDMLAH */
+if (u && !arm_dc_feature(s, ARM_FEATURE_V8_1_SIMD)) {
+unallocated_encoding(s);
+return;
+}
+break;
+case 0xf: /* SQRDMLSH */
+if (!u || !arm_dc_feature(s, ARM_FEATURE_V8_1_SIMD)) {
+unallocated_encoding(s);
+return;
+}
+break;
 case 0x8: /* MUL */
 if (u || is_scalar) {
 unallocated_encoding(s);
@@ -10941,13 +10952,36 @@ static void disas_simd_indexed(DisasContext *s, 
uint32_t insn)
tcg_op, tcg_idx);
 }
 break;
-case 0xd: /* SQRDMULH */
+case 0xd: /* SQRDMULH / SQRDMLAH */
+if (u) { /* SQRDMLAH */
+read_vec_element_i32(s, tcg_res, rd, pass,
+ is_scalar ? size : MO_32);
+if (size == 1) {
+gen_helper_neon_qrdmlah_s16(tcg_res, cpu_env,
+tcg_op, tcg_idx, tcg_res);
+} else {
+gen_helper_neon_qrdmlah_s32(tcg_res, cpu_env,
+tcg_op, tcg_idx, tcg_res);
+}
+} else { /* SQRDMULH */
+if (size == 1) {
+gen_helper_neon_qrdmulh_s16(tcg_res, cpu_env,
+tcg_op, tcg_idx);
+} else {
+gen_helper_neon_qrdmulh_s32(tcg_res, cpu_env,
+tcg_op, tcg_idx);
+}
+}
+break;
+case 0xf: /* SQRDMLSH */
+read_vec_element_i32(s, tcg_res, rd, pass,
+ is_scalar ? size : MO_32);
 if (size == 1) {
-gen_helper_neon_qrdmulh_s16(tcg_res, cpu_env,
-tcg_op, tcg_idx);
+gen_helper_neon_qrdmlsh_s16(tcg_res, cpu_env,
+tcg_op, tcg_idx, tcg_res);
 } else {
-gen_helper_neon_qrdmulh_s32(tcg_res, cpu_env,
-tcg_op, tcg_idx);
+gen_helper_neon_qrdmlsh_s32(tcg_res, cpu_env,
+tcg_op, tcg_idx, tcg_res);
 }
 break;
 default:
-- 
2.13.6

[Qemu-devel] [PATCH v1 07/12] target/arm: Decode aa32 armv8.1 two reg and a scalar

[Richard Henderson]

Signed-off-by: Richard Henderson 
---
 target/arm/translate.c | 36 ++--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/target/arm/translate.c b/target/arm/translate.c
index 0cd58710b3..ee1e364fb5 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -6941,10 +6941,42 @@ static int disas_neon_data_insn(DisasContext *s, 
uint32_t insn)
 }
 neon_store_reg64(cpu_V0, rd + pass);
 }
+break;
+case 14: /* VQRDMLAH scalar */
+case 15: /* VQRDMLSH scalar */
+if (!arm_dc_feature(s, ARM_FEATURE_V8_1_SIMD)) {
+return 1;
+}
+if (u && ((rd | rn) & 1)) {
+return 1;
+}
+tmp2 = neon_get_scalar(size, rm);
+for (pass = 0; pass < (u ? 4 : 2); pass++) {
+void (*fn)(TCGv_i32, TCGv_env, TCGv_i32,
+   TCGv_i32, TCGv_i32);
 
-
+tmp = neon_load_reg(rn, pass);
+tmp3 = neon_load_reg(rd, pass);
+if (op == 14) {
+if (size == 1) {
+fn = gen_helper_neon_qrdmlah_s16;
+} else {
+fn = gen_helper_neon_qrdmlah_s32;
+}
+} else {
+if (size == 1) {
+fn = gen_helper_neon_qrdmlsh_s16;
+} else {
+fn = gen_helper_neon_qrdmlsh_s32;
+}
+}
+fn(tmp, cpu_env, tmp, tmp2, tmp3);
+tcg_temp_free_i32(tmp3);
+neon_store_reg(rd, pass, tmp);
+}
+tcg_temp_free_i32(tmp2);
 break;
-default: /* 14 and 15 are RESERVED */
+default:
 return 1;
 }
 }
-- 
2.13.6

[Qemu-devel] [PATCH v1 03/12] target/arm: Decode aa64 armv8.1 scalar three same extra

[Richard Henderson]

Signed-off-by: Richard Henderson 
---
 target/arm/helper.h |   4 ++
 target/arm/advsimd_helper.c | 105 
 target/arm/translate-a64.c  |  90 +
 target/arm/Makefile.objs|   2 +-
 4 files changed, 200 insertions(+), 1 deletion(-)
 create mode 100644 target/arm/advsimd_helper.c

diff --git a/target/arm/helper.h b/target/arm/helper.h
index 64afbac59f..ec098d8337 100644
--- a/target/arm/helper.h
+++ b/target/arm/helper.h
@@ -350,8 +350,12 @@ DEF_HELPER_FLAGS_1(neon_rbit_u8, TCG_CALL_NO_RWG_SE, i32, 
i32)
 
 DEF_HELPER_3(neon_qdmulh_s16, i32, env, i32, i32)
 DEF_HELPER_3(neon_qrdmulh_s16, i32, env, i32, i32)
+DEF_HELPER_4(neon_qrdmlah_s16, i32, env, i32, i32, i32)
+DEF_HELPER_4(neon_qrdmlsh_s16, i32, env, i32, i32, i32)
 DEF_HELPER_3(neon_qdmulh_s32, i32, env, i32, i32)
 DEF_HELPER_3(neon_qrdmulh_s32, i32, env, i32, i32)
+DEF_HELPER_4(neon_qrdmlah_s32, i32, env, s32, s32, s32)
+DEF_HELPER_4(neon_qrdmlsh_s32, i32, env, s32, s32, s32)
 
 DEF_HELPER_1(neon_narrow_u8, i32, i64)
 DEF_HELPER_1(neon_narrow_u16, i32, i64)
diff --git a/target/arm/advsimd_helper.c b/target/arm/advsimd_helper.c
new file mode 100644
index 00..583c2b0dce
--- /dev/null
+++ b/target/arm/advsimd_helper.c
@@ -0,0 +1,105 @@
+/*
+ *  ARM AdvSIMD Vector Operations
+ *
+ *  Copyright (c) 2017 Linaro
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "cpu.h"
+#include "exec/exec-all.h"
+#include "exec/helper-proto.h"
+#include "tcg/tcg-gvec-desc.h"
+
+
+#define SET_QC() env->vfp.xregs[ARM_VFP_FPSCR] |= CPSR_Q
+
+static uint16_t inl_qrdmlah_s16(CPUARMState *env, int16_t src1,
+int16_t src2, int16_t src3)
+{
+/* Simplify:
+ * = ((a3 << 16) + ((e1 * e2) << 1) + (1 << 15)) >> 16
+ * = ((a3 << 15) + (e1 * e2) + (1 << 14)) >> 15
+ */
+int32_t ret = (int32_t)src1 * src2;
+ret = ((int32_t)src3 << 15) + ret + (1 << 14);
+ret >>= 15;
+if (ret != (int16_t)ret) {
+SET_QC();
+ret = (ret < 0 ? -0x8000 : 0x7fff);
+}
+return ret;
+}
+
+uint32_t HELPER(neon_qrdmlah_s16)(CPUARMState *env, uint32_t src1,
+  uint32_t src2, uint32_t src3)
+{
+uint16_t e1 = inl_qrdmlah_s16(env, src1, src2, src3);
+uint16_t e2 = inl_qrdmlah_s16(env, src1 >> 16, src2 >> 16, src3 >> 16);
+return deposit32(e1, 16, 16, e2);
+}
+
+static uint16_t inl_qrdmlsh_s16(CPUARMState *env, int16_t src1,
+int16_t src2, int16_t src3)
+{
+/* Similarly, using subtraction:
+ * = ((a3 << 16) - ((e1 * e2) << 1) + (1 << 15)) >> 16
+ * = ((a3 << 15) - (e1 * e2) + (1 << 14)) >> 15
+ */
+int32_t ret = (int32_t)src1 * src2;
+ret = ((int32_t)src3 << 15) - ret + (1 << 14);
+ret >>= 15;
+if (ret != (int16_t)ret) {
+SET_QC();
+ret = (ret < 0 ? -0x8000 : 0x7fff);
+}
+return ret;
+}
+
+uint32_t HELPER(neon_qrdmlsh_s16)(CPUARMState *env, uint32_t src1,
+  uint32_t src2, uint32_t src3)
+{
+uint16_t e1 = inl_qrdmlsh_s16(env, src1, src2, src3);
+uint16_t e2 = inl_qrdmlsh_s16(env, src1 >> 16, src2 >> 16, src3 >> 16);
+return deposit32(e1, 16, 16, e2);
+}
+
+uint32_t HELPER(neon_qrdmlah_s32)(CPUARMState *env, int32_t src1,
+  int32_t src2, int32_t src3)
+{
+/* Simplify similarly to int_qrdmlah_s16 above.  */
+int64_t ret = (int64_t)src1 * src2;
+ret = ((int64_t)src3 << 31) + ret + (1 << 30);
+ret >>= 31;
+if (ret != (int32_t)ret) {
+SET_QC();
+ret = (ret < 0 ? INT32_MIN : INT32_MAX);
+}
+return ret;
+}
+
+uint32_t HELPER(neon_qrdmlsh_s32)(CPUARMState *env, int32_t src1,
+  int32_t src2, int32_t src3)
+{
+/* Simplify similarly to int_qrdmlsh_s16 above.  */
+int64_t ret = (int64_t)src1 * src2;
+ret = ((int64_t)src3 << 31) - ret + (1 << 30);
+ret >>= 31;
+if (ret != (int32_t)ret) {
+SET_QC();
+ret = (ret < 0 ? INT32_MIN : INT32_MAX);
+}
+return ret;
+}
diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index a4380bbb15..182853e3bb 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -7596,6 

[Qemu-devel] [PATCH v1 01/12] HACK: use objdump disas

[Richard Henderson]

---
 disas.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/disas.c b/disas.c
index d6a1eb9c8e..69069a85ca 100644
--- a/disas.c
+++ b/disas.c
@@ -231,7 +231,7 @@ void target_disas(FILE *out, CPUState *cpu, target_ulong 
code,
 s.info.disassembler_options = (char *)"any";
 s.info.print_insn = print_insn_ppc;
 #endif
-if (s.info.print_insn == NULL) {
+if (1 || s.info.print_insn == NULL) {
 s.info.print_insn = print_insn_od_target;
 }
 
-- 
2.13.6

[Qemu-devel] [PATCH v1 02/12] target/arm: Add ARM_FEATURE_V8_1_SIMD

[Richard Henderson]

Signed-off-by: Richard Henderson 
---
 target/arm/cpu.h | 1 +
 linux-user/elfload.c | 9 +
 target/arm/cpu.c | 1 +
 target/arm/cpu64.c   | 1 +
 4 files changed, 12 insertions(+)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 69cb49acc3..c5c9cef834 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1312,6 +1312,7 @@ enum arm_features {
 ARM_FEATURE_VBAR, /* has cp15 VBAR */
 ARM_FEATURE_M_SECURITY, /* M profile Security Extension */
 ARM_FEATURE_JAZELLE, /* has (trivial) Jazelle implementation */
+ARM_FEATURE_V8_1_SIMD, /* has ARMv8.1-SIMD */
 };
 
 static inline int arm_feature(CPUARMState *env, int feature)
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 79062882ba..003d9420b7 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -512,6 +512,14 @@ enum {
 ARM_HWCAP_A64_SHA1  = 1 << 5,
 ARM_HWCAP_A64_SHA2  = 1 << 6,
 ARM_HWCAP_A64_CRC32 = 1 << 7,
+ARM_HWCAP_A64_ATOMICS   = 1 << 8,
+ARM_HWCAP_A64_FPHP  = 1 << 9,
+ARM_HWCAP_A64_ASIMDHP   = 1 << 10,
+ARM_HWCAP_A64_CPUID = 1 << 11,
+ARM_HWCAP_A64_ASIMDRDM  = 1 << 12,
+ARM_HWCAP_A64_JSCVT = 1 << 13,
+ARM_HWCAP_A64_FCMA  = 1 << 14,
+ARM_HWCAP_A64_LRCPC = 1 << 15,
 };
 
 #define ELF_HWCAP get_elf_hwcap()
@@ -532,6 +540,7 @@ static uint32_t get_elf_hwcap(void)
 GET_FEATURE(ARM_FEATURE_V8_SHA1, ARM_HWCAP_A64_SHA1);
 GET_FEATURE(ARM_FEATURE_V8_SHA256, ARM_HWCAP_A64_SHA2);
 GET_FEATURE(ARM_FEATURE_CRC, ARM_HWCAP_A64_CRC32);
+GET_FEATURE(ARM_FEATURE_V8_1_SIMD, ARM_HWCAP_A64_ASIMDRDM);
 #undef GET_FEATURE
 
 return hwcaps;
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 4300de66e2..276c996e9f 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1603,6 +1603,7 @@ static void arm_any_initfn(Object *obj)
 set_feature(>env, ARM_FEATURE_V8_SHA256);
 set_feature(>env, ARM_FEATURE_V8_PMULL);
 set_feature(>env, ARM_FEATURE_CRC);
+set_feature(>env, ARM_FEATURE_V8_1_SIMD);
 cpu->midr = 0x;
 }
 #endif
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 670c07ab6e..b05c904ad2 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -226,6 +226,7 @@ static void aarch64_any_initfn(Object *obj)
 set_feature(>env, ARM_FEATURE_V8_SHA256);
 set_feature(>env, ARM_FEATURE_V8_PMULL);
 set_feature(>env, ARM_FEATURE_CRC);
+set_feature(>env, ARM_FEATURE_V8_1_SIMD);
 cpu->ctr = 0x80038003; /* 32 byte I and D cacheline size, VIPT icache */
 cpu->dcz_blocksize = 7; /*  512 bytes */
 }
-- 
2.13.6

[Qemu-devel] [PATCH v1 04/12] target/arm: Decode aa64 armv8.1 three same extra

[Richard Henderson]

Signed-off-by: Richard Henderson 
---
 target/arm/helper.h |  9 +
 target/arm/advsimd_helper.c | 74 +++
 target/arm/translate-a64.c  | 84 +
 3 files changed, 167 insertions(+)

diff --git a/target/arm/helper.h b/target/arm/helper.h
index ec098d8337..67583b3c2e 100644
--- a/target/arm/helper.h
+++ b/target/arm/helper.h
@@ -542,6 +542,15 @@ DEF_HELPER_2(dc_zva, void, env, i64)
 DEF_HELPER_FLAGS_2(neon_pmull_64_lo, TCG_CALL_NO_RWG_SE, i64, i64, i64)
 DEF_HELPER_FLAGS_2(neon_pmull_64_hi, TCG_CALL_NO_RWG_SE, i64, i64, i64)
 
+DEF_HELPER_FLAGS_5(gvec_qrdmlah_s16, TCG_CALL_NO_RWG,
+   void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_qrdmlsh_s16, TCG_CALL_NO_RWG,
+   void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_qrdmlah_s32, TCG_CALL_NO_RWG,
+   void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_qrdmlsh_s32, TCG_CALL_NO_RWG,
+   void, ptr, ptr, ptr, ptr, i32)
+
 #ifdef TARGET_AARCH64
 #include "helper-a64.h"
 #endif
diff --git a/target/arm/advsimd_helper.c b/target/arm/advsimd_helper.c
index 583c2b0dce..b0f4b02a12 100644
--- a/target/arm/advsimd_helper.c
+++ b/target/arm/advsimd_helper.c
@@ -26,6 +26,16 @@
 
 #define SET_QC() env->vfp.xregs[ARM_VFP_FPSCR] |= CPSR_Q
 
+static void clear_tail(void *vd, uintptr_t opr_sz, uintptr_t max_sz)
+{
+uint64_t *d = vd + opr_sz;
+uintptr_t i;
+
+for (i = opr_sz; i < max_sz; i += 8) {
+*d++ = 0;
+}
+}
+
 static uint16_t inl_qrdmlah_s16(CPUARMState *env, int16_t src1,
 int16_t src2, int16_t src3)
 {
@@ -51,6 +61,22 @@ uint32_t HELPER(neon_qrdmlah_s16)(CPUARMState *env, uint32_t 
src1,
 return deposit32(e1, 16, 16, e2);
 }
 
+void HELPER(gvec_qrdmlah_s16)(void *vd, void *vn, void *vm,
+  void *ve, uint32_t desc)
+{
+uintptr_t opr_sz = simd_oprsz(desc);
+int16_t *d = vd;
+int16_t *n = vn;
+int16_t *m = vm;
+CPUARMState *env = ve;
+uintptr_t i;
+
+for (i = 0; i < opr_sz / 2; ++i) {
+d[i] = inl_qrdmlah_s16(env, n[i], m[i], d[i]);
+}
+clear_tail(d, opr_sz, simd_maxsz(desc));
+}
+
 static uint16_t inl_qrdmlsh_s16(CPUARMState *env, int16_t src1,
 int16_t src2, int16_t src3)
 {
@@ -76,6 +102,22 @@ uint32_t HELPER(neon_qrdmlsh_s16)(CPUARMState *env, 
uint32_t src1,
 return deposit32(e1, 16, 16, e2);
 }
 
+void HELPER(gvec_qrdmlsh_s16)(void *vd, void *vn, void *vm,
+  void *ve, uint32_t desc)
+{
+uintptr_t opr_sz = simd_oprsz(desc);
+int16_t *d = vd;
+int16_t *n = vn;
+int16_t *m = vm;
+CPUARMState *env = ve;
+uintptr_t i;
+
+for (i = 0; i < opr_sz / 2; ++i) {
+d[i] = inl_qrdmlsh_s16(env, n[i], m[i], d[i]);
+}
+clear_tail(d, opr_sz, simd_maxsz(desc));
+}
+
 uint32_t HELPER(neon_qrdmlah_s32)(CPUARMState *env, int32_t src1,
   int32_t src2, int32_t src3)
 {
@@ -90,6 +132,22 @@ uint32_t HELPER(neon_qrdmlah_s32)(CPUARMState *env, int32_t 
src1,
 return ret;
 }
 
+void HELPER(gvec_qrdmlah_s32)(void *vd, void *vn, void *vm,
+  void *ve, uint32_t desc)
+{
+uintptr_t opr_sz = simd_oprsz(desc);
+int32_t *d = vd;
+int32_t *n = vn;
+int32_t *m = vm;
+CPUARMState *env = ve;
+uintptr_t i;
+
+for (i = 0; i < opr_sz / 4; ++i) {
+d[i] = helper_neon_qrdmlah_s32(env, n[i], m[i], d[i]);
+}
+clear_tail(d, opr_sz, simd_maxsz(desc));
+}
+
 uint32_t HELPER(neon_qrdmlsh_s32)(CPUARMState *env, int32_t src1,
   int32_t src2, int32_t src3)
 {
@@ -103,3 +161,19 @@ uint32_t HELPER(neon_qrdmlsh_s32)(CPUARMState *env, 
int32_t src1,
 }
 return ret;
 }
+
+void HELPER(gvec_qrdmlsh_s32)(void *vd, void *vn, void *vm,
+  void *ve, uint32_t desc)
+{
+uintptr_t opr_sz = simd_oprsz(desc);
+int32_t *d = vd;
+int32_t *n = vn;
+int32_t *m = vm;
+CPUARMState *env = ve;
+uintptr_t i;
+
+for (i = 0; i < opr_sz / 4; ++i) {
+d[i] = helper_neon_qrdmlsh_s32(env, n[i], m[i], d[i]);
+}
+clear_tail(d, opr_sz, simd_maxsz(desc));
+}
diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index 182853e3bb..0ea47a9dff 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -9874,6 +9874,89 @@ static void disas_simd_three_reg_same(DisasContext *s, 
uint32_t insn)
 }
 }
 
+/* AdvSIMD three same extra
+ *  31   30  29 28   24 23  22  21 20  16  15 1411  10 9  5 4  0
+ * +---+---+---+---+--+---+--+---++---+++
+ * | 0 | Q | U | 0 1 1 1 0 | size | 0 |  Rm  | 1 | opcode | 1 | Rn | Rd |
+ * +---+---+---+---+--+---+--+---++---+++
+ */
+static void 

[Qemu-devel] [PATCH v1 10/12] target/arm: Decode aa64 armv8.3 fcmla

[Richard Henderson]

Signed-off-by: Richard Henderson 
---
 target/arm/helper.h |   8 +++
 target/arm/advsimd_helper.c |  86 
 target/arm/translate-a64.c  | 119 ++--
 3 files changed, 176 insertions(+), 37 deletions(-)

diff --git a/target/arm/helper.h b/target/arm/helper.h
index 350e2fa0e1..de3cc43a7a 100644
--- a/target/arm/helper.h
+++ b/target/arm/helper.h
@@ -556,6 +556,14 @@ DEF_HELPER_FLAGS_5(gvec_fcadds, TCG_CALL_NO_RWG,
 DEF_HELPER_FLAGS_5(gvec_fcaddd, TCG_CALL_NO_RWG,
void, ptr, ptr, ptr, ptr, i32)
 
+DEF_HELPER_FLAGS_5(gvec_fcmlas, TCG_CALL_NO_RWG,
+   void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_fcmlas_idx, TCG_CALL_NO_RWG,
+   void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_fcmlad, TCG_CALL_NO_RWG,
+   void, ptr, ptr, ptr, ptr, i32)
+
+
 #ifdef TARGET_AARCH64
 #include "helper-a64.h"
 #endif
diff --git a/target/arm/advsimd_helper.c b/target/arm/advsimd_helper.c
index fe2e0cbcef..acb452df1b 100644
--- a/target/arm/advsimd_helper.c
+++ b/target/arm/advsimd_helper.c
@@ -243,3 +243,89 @@ void HELPER(gvec_fcaddd)(void *vd, void *vn, void *vm,
 }
 clear_tail(d, opr_sz, simd_maxsz(desc));
 }
+
+void HELPER(gvec_fcmlas)(void *vd, void *vn, void *vm,
+ void *vfpst, uint32_t desc)
+{
+uintptr_t opr_sz = simd_oprsz(desc);
+float32 *d = vd;
+float32 *n = vn;
+float32 *m = vm;
+float_status *fpst = vfpst;
+intptr_t flip = extract32(desc, SIMD_DATA_SHIFT, 1);
+uint32_t neg_imag = extract32(desc, SIMD_DATA_SHIFT + 1, 1);
+uint32_t neg_real = flip ^ neg_imag;
+uintptr_t i;
+
+neg_real <<= 31;
+neg_imag <<= 31;
+
+for (i = 0; i < opr_sz / 4; i += 2) {
+float32 e0 = n[H4(i + flip)];
+float32 e1 = m[H4(i + flip)] ^ neg_real;
+float32 e2 = e0;
+float32 e3 = m[H4(i + 1 - flip)] ^ neg_imag;
+
+d[H4(i)] = float32_muladd(e0, e1, d[H4(i)], 0, fpst);
+d[H4(i + 1)] = float32_muladd(e2, e3, d[H4(i + 1)], 0, fpst);
+}
+clear_tail(d, opr_sz, simd_maxsz(desc));
+}
+
+void HELPER(gvec_fcmlas_idx)(void *vd, void *vn, void *vm,
+ void *vfpst, uint32_t desc)
+{
+uintptr_t opr_sz = simd_oprsz(desc);
+float32 *d = vd;
+float32 *n = vn;
+float32 *m = vm;
+float_status *fpst = vfpst;
+intptr_t flip = extract32(desc, SIMD_DATA_SHIFT, 1);
+uint32_t neg_imag = extract32(desc, SIMD_DATA_SHIFT + 1, 1);
+uint32_t neg_real = flip ^ neg_imag;
+uintptr_t i;
+float32 e1 = m[H4(flip)];
+float32 e3 = m[H4(1 - flip)];
+
+neg_real <<= 31;
+neg_imag <<= 31;
+e1 ^= neg_real;
+e3 ^= neg_imag;
+
+for (i = 0; i < opr_sz / 4; i += 2) {
+float32 e0 = n[H4(i + flip)];
+float32 e2 = e0;
+
+d[H4(i)] = float32_muladd(e0, e1, d[H4(i)], 0, fpst);
+d[H4(i + 1)] = float32_muladd(e2, e3, d[H4(i + 1)], 0, fpst);
+}
+clear_tail(d, opr_sz, simd_maxsz(desc));
+}
+
+void HELPER(gvec_fcmlad)(void *vd, void *vn, void *vm,
+ void *vfpst, uint32_t desc)
+{
+uintptr_t opr_sz = simd_oprsz(desc);
+float64 *d = vd;
+float64 *n = vn;
+float64 *m = vm;
+float_status *fpst = vfpst;
+intptr_t flip = extract32(desc, SIMD_DATA_SHIFT, 1);
+uint64_t neg_imag = extract32(desc, SIMD_DATA_SHIFT + 1, 1);
+uint64_t neg_real = flip ^ neg_imag;
+uintptr_t i;
+
+neg_real <<= 63;
+neg_imag <<= 63;
+
+for (i = 0; i < opr_sz / 8; i += 2) {
+float64 e0 = n[i + flip];
+float64 e1 = m[i + flip] ^ neg_real;
+float64 e2 = e0;
+float64 e3 = m[i + 1 - flip] ^ neg_imag;
+
+d[i] = float64_muladd(e0, e1, d[i], 0, fpst);
+d[i + 1] = float64_muladd(e2, e3, d[i + 1], 0, fpst);
+}
+clear_tail(d, opr_sz, simd_maxsz(desc));
+}
diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index f13a945c43..b57217 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -9907,6 +9907,10 @@ static void disas_simd_three_reg_same_extra(DisasContext 
*s, uint32_t insn)
 }
 feature = ARM_FEATURE_V8_1_SIMD;
 break;
+case 0x8: /* FCMLA, #0 */
+case 0x9: /* FCMLA, #90 */
+case 0xa: /* FCMLA, #180 */
+case 0xb: /* FCMLA, #270 */
 case 0xc: /* FCADD, #90 */
 case 0xe: /* FCADD, #270 */
 if (size != 2 && (size != 3 || !is_q)) { /* FIXME: fp16 support */
@@ -9961,6 +9965,24 @@ static void disas_simd_three_reg_same_extra(DisasContext 
*s, uint32_t insn)
0, fn_gvec_ptr);
 break;
 
+case 0x8: /* FCMLA, #0 */
+case 0x9: /* FCMLA, #90 */
+case 0xa: /* FCMLA, #180 */
+case 0xb: /* FCMLA, #270 */
+switch (size) {
+case 2:
+fn_gvec_ptr = gen_helper_gvec_fcmlas;
+break;
+case 3:
+   

[Qemu-devel] [PATCH v1 00/12] ARM v8.1 simd + v8.3 complex insns

[Richard Henderson]

This patch set depends on v3 of native-vector-registers;
for ease of review the whole tree is at

  git://github.com/rth7680/qemu.git tgt-arm-cplx

I have successfully tested all insns for AArch64 via RISU.
I have successfully tested everything but VCMLA for AArch32.

The insn that doesn't match up is

  fef3c848  vcmla.f32  q14, , d8[0], #270

for which FoundationModel is *not* signalling illegal insn.
I'm not really sure what it is doing -- perhaps treating the
insn as a coprocessor 8 nop?  I'll have to investigate further.

In the meantime, it's surely time for a round 1 review.


r~


Richard Henderson (12):
  HACK: use objdump disas
  target/arm: Add ARM_FEATURE_V8_1_SIMD
  target/arm: Decode aa64 armv8.1 scalar three same extra
  target/arm: Decode aa64 armv8.1 three same extra
  target/arm: Decode aa64 armv8.1 scalar/vector x indexed element
  target/arm: Decode aa32 armv8.1 three same
  target/arm: Decode aa32 armv8.1 two reg and a scalar
  target/arm: Add ARM_FEATURE_V8_FCMA
  target/arm: Decode aa64 armv8.3 fcadd
  target/arm: Decode aa64 armv8.3 fcmla
  target/arm: Decode aa32 armv8.3 3-same
  target/arm: Decode aa32 armv8.3 2-reg-index

 target/arm/cpu.h|   2 +
 target/arm/helper.h |  26 
 disas.c |   2 +-
 linux-user/elfload.c|  10 ++
 target/arm/advsimd_helper.c | 331 +
 target/arm/cpu.c|   2 +
 target/arm/cpu64.c  |   2 +
 target/arm/translate-a64.c  | 350 +++-
 target/arm/translate.c  | 241 +++---
 target/arm/Makefile.objs|   2 +-
 10 files changed, 912 insertions(+), 56 deletions(-)
 create mode 100644 target/arm/advsimd_helper.c

-- 
2.13.6

Re: [Qemu-devel] [PATCH v2 0/7] xen: xen-domid-restrict improvements

[no-reply]

Hi,

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

Type: series
Message-id: 1507132392-25051-1-git-send-email-ian.jack...@eu.citrix.com
Subject: [Qemu-devel] [PATCH v2 0/7] xen: xen-domid-restrict improvements

=== 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'
8fc7e0869d RFC configure: do_compiler: Dump some extra info under bash
549a4a2c37 os-posix: Provide new -runasid option
bc877af3d3 xen: destroy_hvm_domain: Try xendevicemodel_shutdown
b892ad5fbe xen: move xc_interface compatibility fallback further up the file
2d97091d63 xen: destroy_hvm_domain: Move reason into a variable
e0cf362a93 xen: defer call to xen_restrict until after os_setup_post
4339894b1d xen: restrict: use xentoolcore_restrict_all
77c78f244f xen: link against xentoolcore

=== OUTPUT BEGIN ===
Checking PATCH 1/8: xen: link against xentoolcore...
Checking PATCH 2/8: xen: restrict: use xentoolcore_restrict_all...
Checking PATCH 3/8: xen: defer call to xen_restrict until after os_setup_post...
Checking PATCH 4/8: xen: destroy_hvm_domain: Move reason into a variable...
Checking PATCH 5/8: xen: move xc_interface compatibility fallback further up 
the file...
Checking PATCH 6/8: xen: destroy_hvm_domain: Try xendevicemodel_shutdown...
Checking PATCH 7/8: os-posix: Provide new -runasid option...
ERROR: consider using qemu_strtoul in preference to strtoul
#42: FILE: os-posix.c:160:
+lv = strtoul(optarg, , 0); /* can't qemu_strtoul, want *ep=='.' */

total: 1 errors, 0 warnings, 80 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 8/8: RFC configure: do_compiler: Dump some extra info under 
bash...
=== 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] [PATCH v2 0/4] blockjobs: add explicit job reaping

[Kevin Wolf]

Am 04.10.2017 um 03:52 hat John Snow geschrieben:
> For jobs that complete when a monitor isn't looking, there's no way to
> tell what the job's final return code was. We need to allow jobs to
> remain in the list until queried for reliable management.

Just a short summary of what I discussed with John on IRC:

Another important reason why we want to have an explicit end of block
jobs is that job completion often makes changes to the graph. For a
management tool that manages the block graph on a node level, it is a
big problem if graph changes can happen at any point that can lead to
bad race conditions. Giving the management tool control over the end of
the block job makes it aware that graph changes happen.

This means that compared to this RFC series, we need to move the waiting
earlier in the process:

1. Block job is done and calls block_job_completed()
2. Wait for other block jobs in the same job transaction to complete
3. Send a (new) QMP event to the management tool to notify it that the
   job is ready to be reaped
4. On block-job-reap, call the .commit/.abort callbacks of the jobs in
   the transaction. They will do most of the work that is currently done
   in the completion callbacks, in particular any graph changes. If we
   need to allow error cases, we can add a .prepare_completion callback
   that can still let the whole transaction fail.
5. Send the final QMP completion event for each job in the transaction
   with the final error code. This is the existing BLOCK_JOB_COMPLETED
   or BLOCK_JOB_CANCELLED event.

The current RFC still executes .commit/.abort before block-job-reap, so
the graph changes happen too early to be under control of the management
tool.

> RFC:
> The next version will add tests for transactions.
> Kevin, can you please take a look at bdrv_is_root_node and how it is
> used with respect to do_drive_backup? I suspect that in this case that
> "is root" should actually be "true", but a node in use by a job has
> two roles; child_root and child_job, so it starts returning false here.
> 
> That's fine because we prevent a collision that way, but it makes the
> error messages pretty bad and misleading. Do you have a quick suggestion?
> (Should I just amend the loop to allow non-root nodes as long as they
> happen to be jobs so that the job creation code can check permissions?)

We kind of sidestepped this problem by deciding that there is no real
reason for the backup job to require the source to be a root node.

I'm not completely sure how we could easily get a better message while
still requiring a root node (and I suppose there are other places that
rightfully still require a root node). Ignoring children with child_job
feels ugly, but might be the best option.

Note that this will not make the conflicting command work suddenly,
because every node that has a child_job parent also has op blockers for
everything, but the error message should be less confusing than "is not
a root node".

Kevin

Re: [Qemu-devel] [Qemu-block] [PATCH RFC] block: add block-insert-node QMP command

[Max Reitz]

On 2017-10-04 19:05, Manos Pitsidianakis wrote:
> On Wed, Oct 04, 2017 at 02:49:27PM +0200, Max Reitz wrote:
>> On 2017-08-15 09:45, Manos Pitsidianakis wrote:
>>> block-insert-node and its pair command block-remove-node provide runtime
>>> insertion and removal of filter nodes.
>>>
>>> block-insert-node takes a (parent, child) and (node, child) pair of
>>> edges and unrefs the (parent, child) BdrvChild relationship and creates
>>> a new (parent, node) child with the same BdrvChildRole.
>>>
>>> This is a different approach than x-blockdev-change which uses the
>>> driver
>>> methods bdrv_add_child() and bdrv_del_child(),
>>
>> Why? :-)
>>
>> Can't we reuse x-blockdev-change? As far as I'm concerned, this was one
>> of its roles, and at least I don't want to have both x-blockdev-change
>> and these new commands.
>>
>> I think it would be a good idea just to change bdrv_add_child() and
>> bdrv_del_child(): If the driver has a bdrv_{add,del}_child() callback,
>> invoke that.  If it doesn't, then just attach the child.
>>
>> Of course, it may turn out that x-blockdev-change is lacking something
>> (e.g. a way to specify as what kind of child a new node is to be
>> attached).  Then we should either extend it so that it covers what it's
>> lacking, or replace it completely by these new commands.  In the latter
>> case, however, they would need to cover the existing use case which is
>> reconfiguring the quorum driver.  (And that would mean it would have to
>> invoke bdrv_add_child()/bdrv_del_child() when the driver has them.)
>>
>> Max
>>
> 
> I think the two use cases are this:
> 
> a) Adding/removing a replication child to an existing quorum node
> b) Insert a filter between two existing nodes.

For me both are the same: Adding/removing nodes into/from the graph.

The difference is how those children are added (or removed, but it's the
same in reverse): In case of quorum, you can simply attach a new child
because it supports a variable number of children.  Another case where
this would work are all block drivers which support backing files (you
can freely attach/detach those).

In this series, it's not about adding or removing new children, but
instead "injecting" them into an edge: An existing child is replaced,
but it now serves as some child of the new one.

(I guess writing too much trying to get my point across, sorry...)

The gist is that for me it's not so much about "quorum" or "filter
nodes".  It's about adding a new child to a node vs. replacing an
existing one.

> These are not directly compatible semantically, but as you said
> x-blockdev-change can perform b) if bdrv_add_child()/bdrv_del_child()
> are not implemented. Wouldn't that be unnecessary overloading?

Yes, I think it would be. :-)

So say we have these two trees in our graph:

[ Parent BDS -> Child BDS ]
[ Filter BDS -> Child BDS ]

So here's what you can do with x-blockdev-change (in theory; in practice
it can only do that for quorum):
- Remove a child, so
[ Parent BDS -> Child BDS ]
  is split into two trees
[ Parent BDS ] and
[ Child BDS ]
- Add a child, so we can merge
[ Parent BDS ] and
[ Filter BDS -> Child BDS ]
  into
[ Parent BDS -> Filter BDS -> Child BDS ]

However, this is only possible with quorum because usually block drivers
don't support detaching children.

And here's what you can do with your commands (from what I can see):
- Replace a child (you call it insertion, but it really is just
  replacement of an existing child with the constraint that both nodes
  involved must have the same child):
[ Parent BDS -> Child BDS ]
[ Filter BDS -> Child BDS ]
  to
[ Parent BDS -> Filter BDS -> Child BDS ]
- Replace a child (you call it removal, but it really is just
  replacement of a child with its child):
[ Parent BDS -> Filter BDS -> Child BDS ]
  to
[ Parent BDS -> Child BDS ]

This works on all BDSs because you don't change the number of children.


The interesting thing of course is that the "change" command can
actually add and remove children; where as the "insert" and "remove"
commands can only replace children.  So that's already a bit funny (one
command does two things; two commands do one thing).

And then of course you can simply modify x-blockdev-change so it can do
the same thing block-insert-node and block-remove-node can do: It just
needs another mode which can be used to replace a child (and its
description already states that it is supposed to be usable for that at
some point in the future).


So after I've written all of this, I feel like the new insert-node and
remove-node commands are exactly what x-blockdev-change should do when
asked to replace a node.  The only difference is that x-blockdev-change
would allow you to replace any node with anything, without the
constraints that block-insert-node and block-remove-node exact.

(And node replacement with x-blockdev-change would work by specifying
all three parameters.)

Not sure if that makes sense, I hope it does. 

Re: [Qemu-devel] [PATCH] s390x/tcg: initialize machine check queue

[Richard Henderson]

On 10/04/2017 12:25 PM, Cornelia Huck wrote:
> Just as for external interrupts and I/O interrupts, we need to
> initialize mchk_index during cpu reset.
> 
> Signed-off-by: Cornelia Huck 
> ---
> 
> Trying a device_add with a ccw device under tcg currently insta-crashes
> qemu. Probably nobody ever tried the crw machine check support that I
> hacked in...
> 
> Needs more work to avoid a guest kernel panic next; but let's pick the
> low-hanging fruit first.
> 
> ---
>  target/s390x/cpu.c | 2 ++
>  1 file changed, 2 insertions(+)

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH] hw/s390x/sclp: Mark the sclp device with user_creatable = false

[Thomas Huth]

On 04.10.2017 17:18, Pierre Morel wrote:
> On 04/10/2017 15:53, Thomas Huth wrote:
>> The "sclp" device is just an internal device that can not be instantiated
>> by the users. If they try to use it, they only get a simple error
>> message:
>>
>> $ qemu-system-s390x -nographic -device sclp
>> qemu-system-s390x: Option '-device s390-sclp-event-facility' cannot be
>> handled by this machine
>>
>> Since sclp_init() tries to create a TYPE_SCLP_EVENT_FACILITY which is
>> a non-pluggable sysbus device, there is really no way that the "sclp"
>> device can be used by the user, so let's set the user_creatable = false
>> accordingly.
>>
>> Signed-off-by: Thomas Huth 
>> ---
>>   hw/s390x/sclp.c | 5 +
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
>> index 30aefbf..9be0cb8 100644
>> --- a/hw/s390x/sclp.c
>> +++ b/hw/s390x/sclp.c
>> @@ -606,6 +606,11 @@ static void sclp_class_init(ObjectClass *oc, void
>> *data)
>>   dc->realize = sclp_realize;
>>   dc->hotpluggable = false;
>>   set_bit(DEVICE_CATEGORY_MISC, dc->categories);
>> +    /*
>> + * Reason: Creates TYPE_SCLP_EVENT_FACILITY in sclp_init
>> + * which is a non-pluggable sysbus device
>> + */
>> +    dc->user_creatable = false;
>>
>>   sc->read_SCP_info = read_SCP_info;
>>   sc->read_storage_element0_info = read_storage_element0_info;
>>
> 
> I must miss something.
> Why is the sclp device not a SYS_BUS_DEVICE ?
> The problem seems to come from the heterogeneity of the sclp and sclp
> generated devices.

I wonder whether it should rather be the other way round: Why is
TYPE_SCLP_EVENT_FACILITY a sysbus device? Sysbus is an abstraction for
simple on-board devices, while TYPE_SCLP_EVENT_FACILITY seems rather to
be a pseudo-device... so it should rather simply be of TYPE_DEVICE
instead? Or do I miss something?

 Thomas

Re: [Qemu-devel] [Qemu-block] [PATCH RFC] block: add block-insert-node QMP command

[Manos Pitsidianakis]

On Wed, Oct 04, 2017 at 02:49:27PM +0200, Max Reitz wrote:

On 2017-08-15 09:45, Manos Pitsidianakis wrote:

block-insert-node and its pair command block-remove-node provide runtime
insertion and removal of filter nodes.

block-insert-node takes a (parent, child) and (node, child) pair of
edges and unrefs the (parent, child) BdrvChild relationship and 
creates

a new (parent, node) child with the same BdrvChildRole.

This is a different approach than x-blockdev-change which uses the driver
methods bdrv_add_child() and bdrv_del_child(),


Why? :-)

Can't we reuse x-blockdev-change? As far as I'm concerned, this was one
of its roles, and at least I don't want to have both x-blockdev-change
and these new commands.

I think it would be a good idea just to change bdrv_add_child() and
bdrv_del_child(): If the driver has a bdrv_{add,del}_child() callback,
invoke that.  If it doesn't, then just attach the child.

Of course, it may turn out that x-blockdev-change is lacking something
(e.g. a way to specify as what kind of child a new node is to be
attached).  Then we should either extend it so that it covers what it's
lacking, or replace it completely by these new commands.  In the latter
case, however, they would need to cover the existing use case which is
reconfiguring the quorum driver.  (And that would mean it would have to
invoke bdrv_add_child()/bdrv_del_child() when the driver has them.)

Max



I think the two use cases are this:

a) Adding/removing a replication child to an existing quorum node
b) Insert a filter between two existing nodes.

These are not directly compatible semantically, but as you said 
x-blockdev-change can perform b) if bdrv_add_child()/bdrv_del_child() 
are not implemented. Wouldn't that be unnecessary overloading?


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH v1 1/2] scsi-disk: support reporting of rotation rate

[Daniel P. Berrange]

On Wed, Oct 04, 2017 at 05:49:44PM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
> > The Linux kernel will query the SCSI "Block device characteristics"
> > VPD to determine the rotations per minute of the disk. If this has
> > the value 1, it is taken to be an SSD and so Linux sets the
> > 'rotational' flag to 0 for the I/O queue and will stop using that
> > disk as a source of random entropy. Other operating systems may
> > also take into account rotation rate when setting up default
> > behaviour.
> > 
> > Mgmt apps should be able to set the rotation rate for virtualized
> > block devices, based on characteristics of the host storage in use,
> > so that the guest OS gets sensible behaviour out of the box. This
> > patch thus adds a 'rotation-rate' parameter for 'scsi-hd' and
> > 'scsi-block' device types. For the latter, this parameter will be
> > ignored unless the host device has TYPE_DISK.
> > 
> > Signed-off-by: Daniel P. Berrange 
> > ---
> >  hw/scsi/scsi-disk.c | 20 
> >  1 file changed, 20 insertions(+)
> > 
> > diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
> > index 6e841fb5ff..a518080e7d 100644
> > --- a/hw/scsi/scsi-disk.c
> > +++ b/hw/scsi/scsi-disk.c
> > @@ -104,6 +104,14 @@ typedef struct SCSIDiskState
> >  char *product;
> >  bool tray_open;
> >  bool tray_locked;
> > +/*
> > + * 0x- rotation rate not reported
> > + * 0x0001- non-rotating medium (SSD)
> > + * 0x0002-0x0400 - reserved
> > + * 0x0401-0xffe  - rotations per minute
> > + * 0x- reserved
> > + */
> > +uint16_t rotation_rate;
> >  } SCSIDiskState;
> >  
> >  static bool scsi_handle_rw_error(SCSIDiskReq *r, int error, bool 
> > acct_failed);
> > @@ -605,6 +613,7 @@ static int scsi_disk_emulate_inquiry(SCSIRequest *req, 
> > uint8_t *outbuf)
> >  outbuf[buflen++] = 0x83; // device identification
> >  if (s->qdev.type == TYPE_DISK) {
> >  outbuf[buflen++] = 0xb0; // block limits
> > +outbuf[buflen++] = 0xb1; /* block device characteristics */
> >  outbuf[buflen++] = 0xb2; // thin provisioning
> >  }
> >  break;
> > @@ -747,6 +756,15 @@ static int scsi_disk_emulate_inquiry(SCSIRequest *req, 
> > uint8_t *outbuf)
> >  outbuf[43] = max_io_sectors & 0xff;
> >  break;
> >  }
> > +case 0xb1: /* block device characteristics */
> > +{
> > +buflen = 8;
> > +outbuf[4] = (s->rotation_rate >> 8) & 0xff;
> > +outbuf[5] = s->rotation_rate & 0xff;
> > +outbuf[6] = 0;
> > +outbuf[7] = 0;
> > +break;
> > +}
> >  case 0xb2: /* thin provisioning */
> >  {
> >  buflen = 8;
> > @@ -2911,6 +2929,7 @@ static Property scsi_hd_properties[] = {
> > DEFAULT_MAX_UNMAP_SIZE),
> >  DEFINE_PROP_UINT64("max_io_size", SCSIDiskState, max_io_size,
> > DEFAULT_MAX_IO_SIZE),
> > +DEFINE_PROP_UINT16("rotation_rate", SCSIDiskState, rotation_rate, 0),
> >  DEFINE_BLOCK_CHS_PROPERTIES(SCSIDiskState, qdev.conf),
> >  DEFINE_PROP_END_OF_LIST(),
> >  };
> > @@ -2982,6 +3001,7 @@ static const TypeInfo scsi_cd_info = {
> >  static Property scsi_block_properties[] = {
> >  DEFINE_BLOCK_ERROR_PROPERTIES(SCSIDiskState, qdev.conf), \
> >  DEFINE_PROP_DRIVE("drive", SCSIDiskState, qdev.conf.blk),
> > +DEFINE_PROP_UINT16("rotation_rate", SCSIDiskState, rotation_rate, 0),
> >  DEFINE_PROP_END_OF_LIST(),
> >  };
> 
> Are you sure you want this as a property of SCSIDiskState etc rather
> than a property on the underlying drive?
> Then if virtio devices etc wanted to pick this up later they could
> without needing extra parameters.

That would make 'rotation_rate' available for everything, regardless
of whether its used/supported by the frontend device. I was trying to
restrict this to only the places where its appropriate, so only disks,
not cdroms for example.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH v1 1/2] scsi-disk: support reporting of rotation rate

[Dr. David Alan Gilbert]

* Daniel P. Berrange (berra...@redhat.com) wrote:
> The Linux kernel will query the SCSI "Block device characteristics"
> VPD to determine the rotations per minute of the disk. If this has
> the value 1, it is taken to be an SSD and so Linux sets the
> 'rotational' flag to 0 for the I/O queue and will stop using that
> disk as a source of random entropy. Other operating systems may
> also take into account rotation rate when setting up default
> behaviour.
> 
> Mgmt apps should be able to set the rotation rate for virtualized
> block devices, based on characteristics of the host storage in use,
> so that the guest OS gets sensible behaviour out of the box. This
> patch thus adds a 'rotation-rate' parameter for 'scsi-hd' and
> 'scsi-block' device types. For the latter, this parameter will be
> ignored unless the host device has TYPE_DISK.
> 
> Signed-off-by: Daniel P. Berrange 
> ---
>  hw/scsi/scsi-disk.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
> index 6e841fb5ff..a518080e7d 100644
> --- a/hw/scsi/scsi-disk.c
> +++ b/hw/scsi/scsi-disk.c
> @@ -104,6 +104,14 @@ typedef struct SCSIDiskState
>  char *product;
>  bool tray_open;
>  bool tray_locked;
> +/*
> + * 0x- rotation rate not reported
> + * 0x0001- non-rotating medium (SSD)
> + * 0x0002-0x0400 - reserved
> + * 0x0401-0xffe  - rotations per minute
> + * 0x- reserved
> + */
> +uint16_t rotation_rate;
>  } SCSIDiskState;
>  
>  static bool scsi_handle_rw_error(SCSIDiskReq *r, int error, bool 
> acct_failed);
> @@ -605,6 +613,7 @@ static int scsi_disk_emulate_inquiry(SCSIRequest *req, 
> uint8_t *outbuf)
>  outbuf[buflen++] = 0x83; // device identification
>  if (s->qdev.type == TYPE_DISK) {
>  outbuf[buflen++] = 0xb0; // block limits
> +outbuf[buflen++] = 0xb1; /* block device characteristics */
>  outbuf[buflen++] = 0xb2; // thin provisioning
>  }
>  break;
> @@ -747,6 +756,15 @@ static int scsi_disk_emulate_inquiry(SCSIRequest *req, 
> uint8_t *outbuf)
>  outbuf[43] = max_io_sectors & 0xff;
>  break;
>  }
> +case 0xb1: /* block device characteristics */
> +{
> +buflen = 8;
> +outbuf[4] = (s->rotation_rate >> 8) & 0xff;
> +outbuf[5] = s->rotation_rate & 0xff;
> +outbuf[6] = 0;
> +outbuf[7] = 0;
> +break;
> +}
>  case 0xb2: /* thin provisioning */
>  {
>  buflen = 8;
> @@ -2911,6 +2929,7 @@ static Property scsi_hd_properties[] = {
> DEFAULT_MAX_UNMAP_SIZE),
>  DEFINE_PROP_UINT64("max_io_size", SCSIDiskState, max_io_size,
> DEFAULT_MAX_IO_SIZE),
> +DEFINE_PROP_UINT16("rotation_rate", SCSIDiskState, rotation_rate, 0),
>  DEFINE_BLOCK_CHS_PROPERTIES(SCSIDiskState, qdev.conf),
>  DEFINE_PROP_END_OF_LIST(),
>  };
> @@ -2982,6 +3001,7 @@ static const TypeInfo scsi_cd_info = {
>  static Property scsi_block_properties[] = {
>  DEFINE_BLOCK_ERROR_PROPERTIES(SCSIDiskState, qdev.conf), \
>  DEFINE_PROP_DRIVE("drive", SCSIDiskState, qdev.conf.blk),
> +DEFINE_PROP_UINT16("rotation_rate", SCSIDiskState, rotation_rate, 0),
>  DEFINE_PROP_END_OF_LIST(),
>  };

Are you sure you want this as a property of SCSIDiskState etc rather
than a property on the underlying drive?
Then if virtio devices etc wanted to pick this up later they could
without needing extra parameters.

Dave

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

Re: [Qemu-devel] [PATCH v1 3/5] xlnx-zcu102: Specify the valid CPUs

[Eduardo Habkost]

On Wed, Oct 04, 2017 at 03:08:16PM +0200, Igor Mammedov wrote:
> On Wed, 4 Oct 2017 09:28:51 -0300
> Eduardo Habkost  wrote:
> 
> > On Wed, Oct 04, 2017 at 01:12:32PM +0200, Igor Mammedov wrote:
> > > On Tue, 3 Oct 2017 14:41:17 -0700
> > > Alistair Francis  wrote:
> > >   
> > > > On Tue, Oct 3, 2017 at 1:36 PM, Eduardo Habkost  
> > > > wrote:  
> > > > > On Tue, Oct 03, 2017 at 01:05:13PM -0700, Alistair Francis wrote:
> > > > >> List all possible valid CPU options.
> > > > >>
> > > > >> Signed-off-by: Alistair Francis 
> > > > >> ---
> > > > >>
> > > > >>  hw/arm/xlnx-zcu102.c | 10 ++
> > > > >>  hw/arm/xlnx-zynqmp.c | 16 +---
> > > > >>  include/hw/arm/xlnx-zynqmp.h |  1 +
> > > > >>  3 files changed, 20 insertions(+), 7 deletions(-)
> > > > >>
> > > > >> diff --git a/hw/arm/xlnx-zcu102.c b/hw/arm/xlnx-zcu102.c
> > > > >> index 519a16ed98..039649e522 100644
> > > > >> --- a/hw/arm/xlnx-zcu102.c
> > > > >> +++ b/hw/arm/xlnx-zcu102.c
> > > > >> @@ -98,6 +98,8 @@ static void xlnx_zynqmp_init(XlnxZCU102 *s, 
> > > > >> MachineState *machine)
> > > > >>  object_property_add_child(OBJECT(machine), "soc", 
> > > > >> OBJECT(>soc),
> > > > >>_abort);
> > > > >>
> > > > >> +object_property_set_str(OBJECT(>soc), machine->cpu_type, 
> > > > >> "cpu-type",
> > > > >> +_fatal);
> > > > >
> > > > > Do you have plans to support other CPU types to xlnx_zynqmp in
> > > > > the future?  If not, I wouldn't bother adding the cpu-type
> > > > > property and the extra boilerplate code if it's always going to
> > > > > be set to cortex-a53.
> > > > 
> > > > No, it'll always be A53.
> > > > 
> > > > I did think of that, but I also wanted to use the new option! I also
> > > > think there is an advantage in sanely handling users '-cpu' option,
> > > > before now we just ignored it, so I think it still does give a
> > > > benefit. That'll be especially important on the Xilinx tree (sometimes
> > > > people use our machines with a different CPU to 'benchmark' or test
> > > > other CPUs with our CoSimulation setup). So I think it does make sense
> > > > to keep in.  
> > > if cpu isn't user settable, one could just outright die if cpu_type
> > > is not NULL and say that user's CLI is wrong.
> > > (i.e. don't give users illusion that they allowed to use '-cpu')  
> > 
> > Isn't it exactly what this patch does, by setting:
> > mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-a53");
> > mc->valid_cpu_types = xlnx_zynqmp_valid_cpus;
> > ?
> > 
> > Except that "-cpu cortex-a53" won't die, which is a good thing.
> allowing "-cpu cortex-a53" here, would allow to use feature parsing
> which weren't allowed or were ignored before if user supplied '-cpu'.
> so I'd more strict and refuse any -cpu and break CLI that tries to use it
> if board has non configurable cpu type. It would be easier to relax
> restriction later if necessary.
> 
> using validate_cpus here just to have users for the new code,
> doesn't seem like valid justification and at that it makes board
> code more complex where it's not necessary and build in cpu type
> works just fine.

It's up to the board maintainer to decide what's the best option.
Both features are independent from each other and can be
implemented by machine core.

In either case, the valid_cpu_types feature will be still very
useful for boards like pxa270 and sa1110, which support -cpu but
only with specific families of CPU types (grep for
"strncmp(cpu_type").

> 
> wrt centralized way to refuse -cpu if board doesn't support it,
> (which is not really related to this series) following could be done:
> 
> when cpu_model removal is completely done I plan to replace
>   vl.c
>  cpu_parse_cpu_model(machine_class->default_cpu_type, cpu_model)
> with
>  cpu_parse_cpu_model(DEFAULT_TARGET_CPU_TYPE, cpu_model)
> 
> so that we could drop temporary guard
> 
>  if (machine_class->default_cpu_type) {

This sounds good to me, even if we don't reject -cpu on any
board.


> 
> with that it would be possible to tell from machine_run_board_init()
> that board doesn't provide cpu but user provided '-cpu'
> so we would be able to:
>   if ((machine_class->default_cpu_type == NULL) &&
>   (machine->cpu_type != NULL))
>   error_fatal("machine doesn't support -cpu option");

I won't complain too much if a board maintainer really wants to
make the board reject -cpu completely, but it's up to them.

Personally, I'd prefer to have all boards setting
default_cpu_type even if they support only one CPU model, so
clients don't need a special case for boards that don't support
-cpu.

-- 
Eduardo

Re: [Qemu-devel] [PATCH] checkpatch: fix incompatibility with old perl

[Daniel P. Berrange]

On Wed, Oct 04, 2017 at 06:44:20PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Do not use '/r' modifier which was introduced in perl 5.14.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  scripts/checkpatch.pl | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Reviewed-by: Daniel P. Berrange 


> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 3c0a28e644..0c41f1212f 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -1432,7 +1432,8 @@ sub process {
>   qr/%[-+ 
> *.0-9]*([hljztL]|ll|hh)?(x|X|"\s*PRI[xX][^"]*"?)/;
>  
>   # don't consider groups splitted by [.:/ ], 
> like 2A.20:12ab
> - my $tmpline = $rawline =~ s/($hex[.:\/ 
> ])+$hex//gr;
> + my $tmpline = $rawline;
> + $tmpline =~ s/($hex[.:\/ ])+$hex//g;
>  
>   if ($tmpline =~ /(?   ERROR("Hex numbers must be prefixed 
> with '0x'\n" .

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH v2 00/10] cleanup qemu-iotests

[Kevin Wolf]

Am 12.09.2017 um 16:44 hat Paolo Bonzini geschrieben:
> The purpose of this series is to separate the "check" sources from
> the tests.  After these patches, common.config is reduced to simple
> shell initialization, and common.rc is only included by the tests.
> 
> Along the way, a lot of dead code is removed too.
> 
> In v2, the following patches:
> 
>   qemu-iotests: do not do useless search for QEMU_*_PROG
>   qemu-iotests: do not search for binaries in the current directory
>   qemu-iotests: include common.env and common.config early
> 
> have been replaced by "qemu-iotests: cleanup and fix search for programs",
> which also preserves the behavior of searching for programs as symlinks
> in the current directory.

Thanks, applied to the block branch.

Kevin

[Qemu-devel] [PATCH] s390x/tcg: initialize machine check queue

[Cornelia Huck]

Just as for external interrupts and I/O interrupts, we need to
initialize mchk_index during cpu reset.

Signed-off-by: Cornelia Huck 
---

Trying a device_add with a ccw device under tcg currently insta-crashes
qemu. Probably nobody ever tried the crw machine check support that I
hacked in...

Needs more work to avoid a guest kernel panic next; but let's pick the
low-hanging fruit first.

---
 target/s390x/cpu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
index 4e1823a3e0..3fdf9bae70 100644
--- a/target/s390x/cpu.c
+++ b/target/s390x/cpu.c
@@ -111,6 +111,7 @@ static void s390_cpu_initial_reset(CPUState *s)
 for (i = 0; i < ARRAY_SIZE(env->io_index); i++) {
 env->io_index[i] = -1;
 }
+env->mchk_index = -1;
 
 /* tininess for underflow is detected before rounding */
 set_float_detect_tininess(float_tininess_before_rounding,
@@ -148,6 +149,7 @@ static void s390_cpu_full_reset(CPUState *s)
 for (i = 0; i < ARRAY_SIZE(env->io_index); i++) {
 env->io_index[i] = -1;
 }
+env->mchk_index = -1;
 
 /* tininess for underflow is detected before rounding */
 set_float_detect_tininess(float_tininess_before_rounding,
-- 
2.13.6

[Qemu-devel] [PATCH 6/8] xen: destroy_hvm_domain: Try xendevicemodel_shutdown

[Ian Jackson]

xc_interface_open etc. is not going to work if we have dropped
privilege, but xendevicemodel_shutdown will if everything is new
enough.

xendevicemodel_shutdown is only availabe in Xen 4.10 and later, so
provide a stub for earlier versions.

Signed-off-by: Ian Jackson 
---
v2: Add compatibility stub for Xen < 4.10.
Fix coding style.

Signed-off-by: Ian Jackson 
---
 hw/i386/xen/xen-hvm.c   | 10 ++
 include/hw/xen/xen_common.h |  7 +++
 2 files changed, 17 insertions(+)

diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 83420cd..25b8b14 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -1386,9 +1386,19 @@ void destroy_hvm_domain(bool reboot)
 {
 xc_interface *xc_handle;
 int sts;
+int rc;
 
 unsigned int reason = reboot ? SHUTDOWN_reboot : SHUTDOWN_poweroff;
 
+if (xen_dmod) {
+rc = xendevicemodel_shutdown(xen_dmod, xen_domid, reason);
+if (!rc) {
+return;
+}
+perror("xendevicemodel_shutdown failed");
+/* well, try the old thing then */
+}
+
 xc_handle = xc_interface_open(0, 0, 0);
 if (xc_handle == NULL) {
 fprintf(stderr, "Cannot acquire xenctrl handle\n");
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 8efdb8a..1d6fb57 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -108,6 +108,13 @@ static inline int xentoolcore_restrict_all(domid_t domid)
 return -1;
 }
 
+static inline int xendevicemodel_shutdown(xendevicemodel_handle *dmod,
+  domid_t domid, unsigned int reason)
+{
+errno = ENOTTY;
+return -1;
+}
+
 #else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 41000 */
 
 #include 
-- 
2.1.4

[Qemu-devel] [PATCH 3/8] xen: defer call to xen_restrict until after os_setup_post

[Ian Jackson]

We need to restrict *all* the control fds that qemu opens.  Looking in
/proc/PID/fd shows there are many; their allocation seems scattered
throughout Xen support code in qemu.

We must postpone the restrict call until roughly the same time as qemu
changes its uid, chroots (if applicable), and so on.

There doesn't seem to be an appropriate hook already.  The RunState
change hook fires at different times depending on exactly what mode
qemu is operating in.

And it appears that no-one but the Xen code wants a hook at this phase
of execution.  So, introduce a bare call to a new function
xen_setup_post, just after os_setup_post.  Also provide the
appropriate stub for when Xen compilation is disabled.

Signed-off-by: Ian Jackson 
---
 hw/i386/xen/xen-hvm.c   |  8 
 hw/xen/xen-common.c | 13 +
 include/sysemu/sysemu.h |  2 ++
 stubs/xen-hvm.c |  5 +
 vl.c|  1 +
 5 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index d9ccd5d..7b60ec6 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -1254,14 +1254,6 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 goto err;
 }
 
-if (xen_domid_restrict) {
-rc = xen_restrict(xen_domid);
-if (rc < 0) {
-error_report("failed to restrict: error %d", errno);
-goto err;
-}
-}
-
 xen_create_ioreq_server(xen_domid, >ioservid);
 
 state->exit.notify = xen_exit_notifier;
diff --git a/hw/xen/xen-common.c b/hw/xen/xen-common.c
index 632a938..4056420 100644
--- a/hw/xen/xen-common.c
+++ b/hw/xen/xen-common.c
@@ -117,6 +117,19 @@ static void xen_change_state_handler(void *opaque, int 
running,
 }
 }
 
+void xen_setup_post(void)
+{
+int rc;
+
+if (xen_domid_restrict) {
+rc = xen_restrict(xen_domid);
+if (rc < 0) {
+perror("xen: failed to restrict");
+exit(1);
+}
+}
+}
+
 static int xen_init(MachineState *ms)
 {
 xen_xc = xc_interface_open(0, 0, 0);
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index b213696..b064a55 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -93,6 +93,8 @@ void qemu_remove_machine_init_done_notifier(Notifier *notify);
 
 void qemu_announce_self(void);
 
+void xen_setup_post(void);
+
 extern int autostart;
 
 typedef enum {
diff --git a/stubs/xen-hvm.c b/stubs/xen-hvm.c
index 3ca6c51..9701feb 100644
--- a/stubs/xen-hvm.c
+++ b/stubs/xen-hvm.c
@@ -13,6 +13,7 @@
 #include "hw/xen/xen.h"
 #include "exec/memory.h"
 #include "qmp-commands.h"
+#include "sysemu/sysemu.h"
 
 int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
 {
@@ -61,3 +62,7 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
 {
 }
+
+void xen_setup_post(void)
+{
+}
diff --git a/vl.c b/vl.c
index fb1f05b..9e7d541 100644
--- a/vl.c
+++ b/vl.c
@@ -4793,6 +4793,7 @@ int main(int argc, char **argv, char **envp)
 }
 
 os_setup_post();
+xen_setup_post();
 
 main_loop();
 replay_disable_events();
-- 
2.1.4

[Qemu-devel] [PATCH 4/8] xen: destroy_hvm_domain: Move reason into a variable

[Ian Jackson]

We are going to want to reuse this.

No functional change.

Signed-off-by: Ian Jackson 
Reviewed-by: Anthony PERARD 
---
 hw/i386/xen/xen-hvm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 7b60ec6..83420cd 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -1387,12 +1387,13 @@ void destroy_hvm_domain(bool reboot)
 xc_interface *xc_handle;
 int sts;
 
+unsigned int reason = reboot ? SHUTDOWN_reboot : SHUTDOWN_poweroff;
+
 xc_handle = xc_interface_open(0, 0, 0);
 if (xc_handle == NULL) {
 fprintf(stderr, "Cannot acquire xenctrl handle\n");
 } else {
-sts = xc_domain_shutdown(xc_handle, xen_domid,
- reboot ? SHUTDOWN_reboot : SHUTDOWN_poweroff);
+sts = xc_domain_shutdown(xc_handle, xen_domid, reason);
 if (sts != 0) {
 fprintf(stderr, "xc_domain_shutdown failed to issue %s, "
 "sts %d, %s\n", reboot ? "reboot" : "poweroff",
-- 
2.1.4

[Qemu-devel] [PATCH 2/8] xen: restrict: use xentoolcore_restrict_all

[Ian Jackson]

And insist that it works.

Drop individual use of xendevicemodel_restrict and
xenforeignmemory_restrict.  These are not actually effective in this
version of qemu, because qemu has a large number of fds open onto
various Xen control devices.

The restriction arrangements are still not right, because the
restriction needs to be done very late - after qemu has opened all of
its control fds.

xentoolcore_restrict_all and xentoolcore.h are available in Xen 4.10
and later, only.  Provide a compatibility stub.  And drop the
compatibility stubs for the old functions.

Signed-off-by: Ian Jackson 
---
v2: Modify the compatibility code, too.
Bump this patch ahead of "defer call to xen_restrict until running"
Retain call to xentoolcore_restrict_all

Signed-off-by: Ian Jackson 
---
 include/hw/xen/xen_common.h | 46 +++--
 1 file changed, 11 insertions(+), 35 deletions(-)

diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 86c7f26..3f44a63 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -91,6 +91,16 @@ static inline void 
*xenforeignmemory_map2(xenforeignmemory_handle *h,
 return xenforeignmemory_map(h, dom, prot, pages, arr, err);
 }
 
+static inline int xentoolcore_restrict_all(domid_t domid)
+{
+errno = ENOTTY;
+return -1;
+}
+
+#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 41000 */
+
+#include 
+
 #endif
 
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40900
@@ -218,20 +228,6 @@ static inline int xendevicemodel_set_mem_type(
 return xc_hvm_set_mem_type(dmod, domid, mem_type, first_pfn, nr);
 }
 
-static inline int xendevicemodel_restrict(
-xendevicemodel_handle *dmod, domid_t domid)
-{
-errno = ENOTTY;
-return -1;
-}
-
-static inline int xenforeignmemory_restrict(
-xenforeignmemory_handle *fmem, domid_t domid)
-{
-errno = ENOTTY;
-return -1;
-}
-
 #else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40900 */
 
 #undef XC_WANT_COMPAT_DEVICEMODEL_API
@@ -290,28 +286,8 @@ static inline int xen_modified_memory(domid_t domid, 
uint64_t first_pfn,
 static inline int xen_restrict(domid_t domid)
 {
 int rc;
-
-/* Attempt to restrict devicemodel operations */
-rc = xendevicemodel_restrict(xen_dmod, domid);
+rc = xentoolcore_restrict_all(domid);
 trace_xen_domid_restrict(rc ? errno : 0);
-
-if (rc < 0) {
-/*
- * If errno is ENOTTY then restriction is not implemented so
- * there's no point in trying to restrict other types of
- * operation, but it should not be treated as a failure.
- */
-if (errno == ENOTTY) {
-return 0;
-}
-
-return rc;
-}
-
-/* Restrict foreignmemory operations */
-rc = xenforeignmemory_restrict(xen_fmem, domid);
-trace_xen_domid_restrict(rc ? errno : 0);
-
 return rc;
 }
 
-- 
2.1.4

[Qemu-devel] [PATCH v2 0/*] xen: xen-domid-restrict improvements

[Ian Jackson]

(Resending this because 1. I got the CC for xen-devel wrong; 2. I got
the subject wrong: there are actually 8 patches; 3. I mangled
Anthony's name in theheaders.  Sorry for the noise.)

I have been working on trying to get qemu, when running as a Xen
device model, to _actually_ not have power equivalent to root.

I think I have achieved this, with some limitations (which will be
discussed in my series against xen.git.

However, there are changes to qemu needed.  In particular

 * The -xen-domid-restrict option does not work properly right now.
   It only restricts a small subset of the descriptors qemu has open.
   I am introducing a new library call in the Xen libraries for this,
   xentoolcore_restrict_all.

 * We need to call a different function on domain shutdown.

 * The restriction operation needs to be done at a slightly different
   time, necessitating a new hook.

 * Additionally, in the future, we intend to be able to set aside
   a uid range for these qemus to run in, and that involves being
   able to tell qemu to drop privilege by numeric uid and gid.

Thanks very much to Anthony Perard for his review of the first, RFC,
version, and for helping out with configure.

At least the first patch of this, "xen: link against xentoolcore",
will very likely be necessary, since the corresponding xen.git series
is likely to make Xen 4.10.

Ian.

[Qemu-devel] [PATCH 7/8] os-posix: Provide new -runasid option

[Ian Jackson]

This allows the caller to specify a uid and gid to use, even if there
is no corresponding password entry.  This will be useful in certain
Xen configurations.

Signed-off-by: Ian Jackson 
---
v2: Coding style fixes.
---
 os-posix.c  | 31 +++
 qemu-options.hx | 12 
 2 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/os-posix.c b/os-posix.c
index 92e9d85..d63680b 100644
--- a/os-posix.c
+++ b/os-posix.c
@@ -43,6 +43,8 @@
 #endif
 
 static struct passwd *user_pwd;
+static uid_t user_uid = (uid_t)-1;
+static gid_t user_gid = (gid_t)-1;
 static const char *chroot_dir;
 static int daemonize;
 static int daemon_pipe;
@@ -134,6 +136,9 @@ void os_set_proc_name(const char *s)
  */
 void os_parse_cmd_args(int index, const char *optarg)
 {
+unsigned long lv;
+char *ep;
+int rc;
 switch (index) {
 #ifdef CONFIG_SLIRP
 case QEMU_OPTION_smb:
@@ -150,6 +155,22 @@ void os_parse_cmd_args(int index, const char *optarg)
 exit(1);
 }
 break;
+case QEMU_OPTION_runasid:
+errno = 0;
+lv = strtoul(optarg, , 0); /* can't qemu_strtoul, want *ep=='.' */
+user_uid = lv; /* overflow here is ID in C99 */
+if (errno || *ep != '.' || user_uid != lv || user_uid == (uid_t)-1) {
+fprintf(stderr, "Could not obtain uid from \"%s\"", optarg);
+exit(1);
+}
+lv = 0;
+rc = qemu_strtoul(ep + 1, 0, 0, );
+user_gid = lv; /* overflow here is ID in C99 */
+if (rc || user_gid != lv || user_gid == (gid_t)-1) {
+fprintf(stderr, "Could not obtain gid from \"%s\"", optarg);
+exit(1);
+}
+break;
 case QEMU_OPTION_chroot:
 chroot_dir = optarg;
 break;
@@ -166,17 +187,19 @@ void os_parse_cmd_args(int index, const char *optarg)
 
 static void change_process_uid(void)
 {
-if (user_pwd) {
-if (setgid(user_pwd->pw_gid) < 0) {
+if (user_pwd || user_uid != (uid_t)-1) {
+if (setgid(user_pwd ? user_pwd->pw_gid : user_gid) < 0) {
 fprintf(stderr, "Failed to setgid(%d)\n", user_pwd->pw_gid);
 exit(1);
 }
-if (initgroups(user_pwd->pw_name, user_pwd->pw_gid) < 0) {
+if ((user_pwd
+ ? initgroups(user_pwd->pw_name, user_pwd->pw_gid)
+ : setgroups(1, _gid)) < 0) {
 fprintf(stderr, "Failed to initgroups(\"%s\", %d)\n",
 user_pwd->pw_name, user_pwd->pw_gid);
 exit(1);
 }
-if (setuid(user_pwd->pw_uid) < 0) {
+if (setuid(user_pwd ? user_pwd->pw_uid : user_gid) < 0) {
 fprintf(stderr, "Failed to setuid(%d)\n", user_pwd->pw_uid);
 exit(1);
 }
diff --git a/qemu-options.hx b/qemu-options.hx
index 9f6e2ad..34a5329 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3968,6 +3968,18 @@ Immediately before starting guest execution, drop root 
privileges, switching
 to the specified user.
 ETEXI
 
+#ifndef _WIN32
+DEF("runasid", HAS_ARG, QEMU_OPTION_runasid, \
+"-runasid uid.gid change to numeric uid and gid just before starting 
the VM\n",
+QEMU_ARCH_ALL)
+#endif
+STEXI
+@item -runasid @var{uid}.@var{gid}
+@findex -runasid
+Immediately before starting guest execution, drop root privileges, switching
+to the specified uid and gid.
+ETEXI
+
 DEF("prom-env", HAS_ARG, QEMU_OPTION_prom_env,
 "-prom-env variable=value\n"
 "set OpenBIOS nvram variables\n",
-- 
2.1.4

[Qemu-devel] [PATCH 5/8] xen: move xc_interface compatibility fallback further up the file

[Ian Jackson]

We are going to want to use the dummy xendevicemodel_handle type in
new stub functions in the CONFIG_XEN_CTRL_INTERFACE_VERSION < 41000
section.  So we need to provide that definition, or (as applicable)
include the appropriate header, earlier in the file.

(Ideally the newer compatibility layers would be at the bottom of the
file, so that they can naturally benefit from the compatibility layers
for earlier version.  But that's rather too much for this series.)

No functional change.

Signed-off-by: Ian Jackson 
---
v2: New patch in v2 of the series
---
 include/hw/xen/xen_common.h | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 3f44a63..8efdb8a 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -78,6 +78,17 @@ static inline void *xenforeignmemory_map(xc_interface *h, 
uint32_t dom,
 
 extern xenforeignmemory_handle *xen_fmem;
 
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40900
+
+typedef xc_interface xendevicemodel_handle;
+
+#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40900 */
+
+#undef XC_WANT_COMPAT_DEVICEMODEL_API
+#include 
+
+#endif
+
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 41000
 
 #define XEN_COMPAT_PHYSMAP
@@ -105,8 +116,6 @@ static inline int xentoolcore_restrict_all(domid_t domid)
 
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40900
 
-typedef xc_interface xendevicemodel_handle;
-
 static inline xendevicemodel_handle *xendevicemodel_open(
 struct xentoollog_logger *logger, unsigned int open_flags)
 {
@@ -228,11 +237,6 @@ static inline int xendevicemodel_set_mem_type(
 return xc_hvm_set_mem_type(dmod, domid, mem_type, first_pfn, nr);
 }
 
-#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40900 */
-
-#undef XC_WANT_COMPAT_DEVICEMODEL_API
-#include 
-
 #endif
 
 extern xendevicemodel_handle *xen_dmod;
-- 
2.1.4

[Qemu-devel] [Bug 1721221] Re: PCI-E passthrough of Nvidia GTX GFX card to Win 10 guest fails with "kvm_set_phys_mem: error registering slot: Invalid argument"

[Joe Clifford]

More noise... OK, so I've tested the Windows 10 guest VM using the same
criteria but eliminating PCI-E pass-through and using virtio-vga
graphics instead, and the the guest boots up fine so perhaps my
assumption is correct.

Let me know if you need to see the memory I/O regions or dmesg of my
host etc.

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

Title:
  PCI-E passthrough of Nvidia GTX GFX card to Win 10 guest fails with
  "kvm_set_phys_mem: error registering slot: Invalid argument"

Status in QEMU:
  New

Bug description:
  Problem: 
  Passthrough of a PCI-E Nvidia GTX 970 GFX card to a Windows 10 guest from a 
Debian Stretch host fails after recent changes to kvm in QEMU master/trunk. 
Before this recent commit, everything worked as expected.

  QEMU Version:
  Master/trunk pulled from github 4/10/17 ( git reflog: d147f7e815 HEAD@{0} )

  Host:
  Debian Stretch kernel SMP Debian 4.9.30-2+deb9u5 (2017-09-19) x86_64 GNU/Linux

  Guest:
  Windows 10 Professional

  Issue is with this commit:
  https://github.com/qemu/qemu/commit/f357f564be0bd45245b3ccfbbe20ace08fe83ca8

  Subsequent commit does not help:
  
https://github.com/qemu/qemu/commit/3110cdbd8a4845c5b5fb861b0a664c56d993dd3c#diff-7b7a17f6e8ba4195198dd685073f43cb

  Error output from qemu: 
  (qemu) kvm_set_phys_mem: error registering slot: Invalid argument

  QEMU commandline used:

  ./sources/qemu/x86_64-softmmu/qemu-system-x86_64 -machine q35,accel=kvm 
-serial none -parallel none -name Windows \
  -enable-kvm -cpu host,kvm=off,hv_vendor_id=sugoidesu,-hypervisor -smp 
6,sockets=1,cores=3,threads=2 \
  -m 8G -mem-path /dev/hugepages -mem-prealloc -balloon none \
  -drive 
if=pflash,format=raw,readonly,file=vms/ovmf-x64/ovmf-x64/OVMF_CODE-pure-efi.fd \
  -drive if=pflash,format=raw,file=vms/ovmf-x64/ovmf-x64/OVMF_VARS-pure-efi.fd \
  -rtc clock=host,base=localtime \
  -readconfig ./vms/q35-virtio-graphical.cfg \
  -object iothread,id=iothread0 -object iothread,id=iothread1 -object 
iothread,id=iothread2 -object iothread,id=iothread3 \
  -device virtio-scsi-pci,iothread=iothread0,id=scsi0 -device 
virtio-scsi-pci,iothread=iothread1,id=scsi1 -device 
virtio-scsi-pci,iothread=iothread2,id=scsi2 -device 
virtio-scsi-pci,iothread=iothread3,id=scsi3 \
  -device scsi-hd,bus=scsi0.0,drive=drive0,bootindex=1 -device 
scsi-hd,bus=scsi1.0,drive=drive1 -device scsi-hd,bus=scsi2.0,drive=drive2 
-device scsi-hd,bus=scsi3.0,drive=drive3 -device 
scsi-hd,bus=scsi1.0,drive=drive4 -device scsi-hd,bus=scsi2.0,drive=drive5 
-device scsi-hd,bus=scsi3.0,drive=drive6 -device 
scsi-hd,bus=scsi1.0,drive=drive7 -device scsi-hd,bus=scsi2.0,drive=drive8 
-device scsi-hd,bus=scsi3.0,drive=drive9 \
  -drive 
if=none,id=drive0,file=vms/w10p64.qcow2,format=qcow2,cache=none,discard=unmap \
  -drive 
if=none,id=drive1,file=vms/w10p64-2.qcow2,format=qcow2,cache=none,discard=unmap 
\
  -drive if=none,id=drive2,file=/dev/mapper/w10p64-3,format=raw,cache=none \
  -drive if=none,id=drive3,file=vms/w10p64-4.qcow2,format=qcow2,cache=none \
  -drive if=none,id=drive4,file=vms/w10p64-5.qcow2,format=qcow2,cache=none \
  -drive 
if=none,id=drive5,file=vms/w10p64-6.qcow2,format=qcow2,cache=none,discard=unmap 
\
  -drive if=none,id=drive6,file=/dev/mapper/w10p64-7,format=raw,cache=none \
  -drive 
if=none,id=drive7,file=vms/w10p64-8.qcow2,format=qcow2,cache=none,discard=unmap 
\
  -device vfio-pci,host=01:00.0,multifunction=on,x-vga=on \
  -device vfio-pci,host=01:00.1,multifunction=on \
  -netdev type=tap,id=net1,ifname=tap1,script=no,downscript=no,vhost=on \
  -device 
virtio-net-pci,netdev=net1,mac=52:54:00:18:32:c9,bus=pcie.2,addr=00.0,ioeventfd=on
 \
  -device usb-host,bus=usb.0,hostbus=3,hostport=2.1 \
  -device usb-host,hostbus=3,hostport=2.2 \
  -device usb-host,bus=ich9-ehci-1.0,hostbus=3,hostport=2.4 \
  -object input-linux,id=kbd1,evdev=/dev/input/event0,grab_all=yes,repeat=on \
  -drive if=none,id=drive8,file=vms/w10p64.qcow2-9,format=qcow2,discard=unmap \
  -drive 
if=none,id=drive9,file=vms/w10p64-10.qcow2,format=qcow2,cache=none,discard=unmap
 \
  -device usb-host,bus=usb.0,hostbus=3,hostport=9 \
  -monitor stdio

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

[Qemu-devel] [PATCH 8/8] RFC configure: do_compiler: Dump some extra info under bash

[Ian Jackson]

This makes it much easier to find a particular thing in config.log.

The information may be lacking in other shells, resulting in harmless
empty output.  (This is why we don't use the proper ${FUNCNAME[*]}
array syntax - other shells will choke on that.)

The extra output is only printed if configure is run with bash.  The
something), it is necessary to say   bash ./configure  to get the extra
debug info in the log.

Signed-off-by: Ian Jackson 
---
 configure | 4 
 1 file changed, 4 insertions(+)

diff --git a/configure b/configure
index 6f691df..21a2b15 100755
--- a/configure
+++ b/configure
@@ -60,6 +60,10 @@ do_compiler() {
 # is compiler binary to execute.
 local compiler="$1"
 shift
+echo >>config.log "
+funcs: ${FUNCNAME}
+lines: ${BASH_LINENO}
+files: ${BASH_SOURCE}"
 echo $compiler "$@" >> config.log
 $compiler "$@" >> config.log 2>&1 || return $?
 # Test passed. If this is an --enable-werror build, rerun
-- 
2.1.4

[Qemu-devel] [PATCH 1/8] xen: link against xentoolcore

[Ian Jackson]

From: Anthony PERARD 

Xen libraries 4.10 will include a new xentoolcore library, without
which xendevicemodel et al will not work.

Signed-off-by: Ian Jackson 
---
 configure | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index fd7e3a5..6f691df 100755
--- a/configure
+++ b/configure
@@ -2072,7 +2072,7 @@ if test "$xen" != "no" ; then
   $($pkg_config --modversion xencontrol | sed 's/\./ /g') )"
 xen=yes
 xen_pc="xencontrol xenstore xenguest xenforeignmemory xengnttab"
-xen_pc="$xen_pc xenevtchn xendevicemodel"
+xen_pc="$xen_pc xenevtchn xendevicemodel xentoolcore"
 QEMU_CFLAGS="$QEMU_CFLAGS $($pkg_config --cflags $xen_pc)"
 libs_softmmu="$($pkg_config --libs $xen_pc) $libs_softmmu"
 LDFLAGS="$($pkg_config --libs $xen_pc) $LDFLAGS"
@@ -2104,18 +2104,20 @@ EOF
 cat > $TMPC <
+#include 
 int main(void) {
   xenforeignmemory_handle *xfmem;
 
   xfmem = xenforeignmemory_open(0, 0);
   xenforeignmemory_map2(xfmem, 0, 0, 0, 0, 0, 0, 0);
+  xentoolcore_restrict_all(0);
 
   return 0;
 }
 EOF
-compile_prog "" "$xen_libs -lxendevicemodel $xen_stable_libs"
+compile_prog "" "$xen_libs -lxendevicemodel $xen_stable_libs 
-lxentoolcore"
   then
-  xen_stable_libs="-lxendevicemodel $xen_stable_libs"
+  xen_stable_libs="-lxendevicemodel $xen_stable_libs -lxentoolcore"
   xen_ctrl_version=41000
   xen=yes
 elif
-- 
2.1.4

Re: [Qemu-devel] [PULL 44/50] scripts: let checkpatch.pl process an entire GIT branch

[Alex Williamson]

On Wed, 4 Oct 2017 16:11:07 +0200
Paolo Bonzini  wrote:

> On 04/10/2017 15:17, Alex Williamson wrote:
> > Yes, it works with the new --patch option.  I use stgit which does
> > not add a filename extension to the patch name on export, nor have I
> > ever known patch files to have any accepted standard file extension.
> > checkpatch.pl has always assumed it's operating on a patch file, as
> > implied by the name of the script, with an option to check regular
> > files.  I'd suggest maintaining behavior consistent with the script name
> > using more comprehensive heuristics than a non-standard file extension.
> > Thanks,  
> 
> We are already limiting source files to only a handful of extensions, 
> perhaps we can reuse that in the DWIM mode selection code.  While at it,
> do not match "../foo" as a branch name:
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 3c0a28e644..9eca0f8458 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -11,6 +11,8 @@ use warnings;
>  my $P = $0;
>  $P =~ s@.*/@@g;
>  
> +our $SrcFile= qr{\.(?:h|c|cpp|s|S|pl|py|sh)$};
> +
>  my $V = '0.31';
>  
>  use Getopt::Long qw(:config no_auto_abbrev);
> @@ -101,30 +103,29 @@ if ($#ARGV < 0) {
>  }
>  
>  if (!defined $chk_branch && !defined $chk_patch && !defined $file) {
> - $chk_branch = $ARGV[0] =~ /\.\./ ? 1 : 0;
> - $chk_patch = $chk_branch ? 0 :
> - $ARGV[0] =~ /\.patch$/ || $ARGV[0] eq "-" ? 1 : 0;
> - $file = $chk_branch || $chk_patch ? 0 : 1;
> + $chk_branch = $ARGV[0] =~ /.\.\./ ? 1 : 0;
> + $file = $ARGV[0] =~ /$SrcFile/ ? 1 : 0;
> + $chk_patch = $chk_branch || $file ? 0 : 1;
>  } elsif (!defined $chk_branch && !defined $chk_patch) {
>   if ($file) {
>   $chk_branch = $chk_patch = 0;
>   } else {
> - $chk_branch = $ARGV[0] =~ /\.\./ ? 1 : 0;
> + $chk_branch = $ARGV[0] =~ /.\.\./ ? 1 : 0;
>   $chk_patch = $chk_branch ? 0 : 1;
>   }
>  } elsif (!defined $chk_branch && !defined $file) {
>   if ($chk_patch) {
>   $chk_branch = $file = 0;
>   } else {
> - $chk_branch = $ARGV[0] =~ /\.\./ ? 1 : 0;
> + $chk_branch = $ARGV[0] =~ /.\.\./ ? 1 : 0;
>   $file = $chk_branch ? 0 : 1;
>   }
>  } elsif (!defined $chk_patch && !defined $file) {
>   if ($chk_branch) {
>   $chk_patch = $file = 0;
>   } else {
> - $chk_patch = $ARGV[0] =~ /\.patch$/ || $ARGV[0] eq "-" ? 1 : 0;
> - $file = $chk_patch ? 0 : 1;
> + $file = $ARGV[0] =~ /$SrcFile/ ? 1 : 0;
> + $chk_patch = $file ? 0 : 1;
>   }
>  } elsif (!defined $chk_branch) {
>   $chk_branch = $chk_patch || $file ? 0 : 1;
> @@ -1442,7 +1443,7 @@ sub process {
>   }
>  
>  # check we are in a valid source file if not then ignore this hunk
> - next if ($realfile !~ /\.(h|c|cpp|s|S|pl|py|sh)$/);
> + next if ($realfile !~ /$SrcFile/);
>  
>  #90 column limit
>   if ($line =~ /^\+/ &&

Thanks Paolo

Tested-by: Alex Williamson 

[Qemu-devel] [Bug 1721221] Re: PCI-E passthrough of Nvidia GTX GFX card to Win 10 guest fails with "kvm_set_phys_mem: error registering slot: Invalid argument"

[Joe Clifford]

Apologies, the title of this bug might be very misleading. I've made a
huge assumption that PCI-E GFX card pass-through was triggering the bug,
purely because a Debian Stretch guest VM on the same host, using the
same build of QEMU, which uses virtio-vga for graphics and the same
version of OVMF firmware, boots up fine.

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

Title:
  PCI-E passthrough of Nvidia GTX GFX card to Win 10 guest fails with
  "kvm_set_phys_mem: error registering slot: Invalid argument"

Status in QEMU:
  New

Bug description:
  Problem: 
  Passthrough of a PCI-E Nvidia GTX 970 GFX card to a Windows 10 guest from a 
Debian Stretch host fails after recent changes to kvm in QEMU master/trunk. 
Before this recent commit, everything worked as expected.

  QEMU Version:
  Master/trunk pulled from github 4/10/17 ( git reflog: d147f7e815 HEAD@{0} )

  Host:
  Debian Stretch kernel SMP Debian 4.9.30-2+deb9u5 (2017-09-19) x86_64 GNU/Linux

  Guest:
  Windows 10 Professional

  Issue is with this commit:
  https://github.com/qemu/qemu/commit/f357f564be0bd45245b3ccfbbe20ace08fe83ca8

  Subsequent commit does not help:
  
https://github.com/qemu/qemu/commit/3110cdbd8a4845c5b5fb861b0a664c56d993dd3c#diff-7b7a17f6e8ba4195198dd685073f43cb

  Error output from qemu: 
  (qemu) kvm_set_phys_mem: error registering slot: Invalid argument

  QEMU commandline used:

  ./sources/qemu/x86_64-softmmu/qemu-system-x86_64 -machine q35,accel=kvm 
-serial none -parallel none -name Windows \
  -enable-kvm -cpu host,kvm=off,hv_vendor_id=sugoidesu,-hypervisor -smp 
6,sockets=1,cores=3,threads=2 \
  -m 8G -mem-path /dev/hugepages -mem-prealloc -balloon none \
  -drive 
if=pflash,format=raw,readonly,file=vms/ovmf-x64/ovmf-x64/OVMF_CODE-pure-efi.fd \
  -drive if=pflash,format=raw,file=vms/ovmf-x64/ovmf-x64/OVMF_VARS-pure-efi.fd \
  -rtc clock=host,base=localtime \
  -readconfig ./vms/q35-virtio-graphical.cfg \
  -object iothread,id=iothread0 -object iothread,id=iothread1 -object 
iothread,id=iothread2 -object iothread,id=iothread3 \
  -device virtio-scsi-pci,iothread=iothread0,id=scsi0 -device 
virtio-scsi-pci,iothread=iothread1,id=scsi1 -device 
virtio-scsi-pci,iothread=iothread2,id=scsi2 -device 
virtio-scsi-pci,iothread=iothread3,id=scsi3 \
  -device scsi-hd,bus=scsi0.0,drive=drive0,bootindex=1 -device 
scsi-hd,bus=scsi1.0,drive=drive1 -device scsi-hd,bus=scsi2.0,drive=drive2 
-device scsi-hd,bus=scsi3.0,drive=drive3 -device 
scsi-hd,bus=scsi1.0,drive=drive4 -device scsi-hd,bus=scsi2.0,drive=drive5 
-device scsi-hd,bus=scsi3.0,drive=drive6 -device 
scsi-hd,bus=scsi1.0,drive=drive7 -device scsi-hd,bus=scsi2.0,drive=drive8 
-device scsi-hd,bus=scsi3.0,drive=drive9 \
  -drive 
if=none,id=drive0,file=vms/w10p64.qcow2,format=qcow2,cache=none,discard=unmap \
  -drive 
if=none,id=drive1,file=vms/w10p64-2.qcow2,format=qcow2,cache=none,discard=unmap 
\
  -drive if=none,id=drive2,file=/dev/mapper/w10p64-3,format=raw,cache=none \
  -drive if=none,id=drive3,file=vms/w10p64-4.qcow2,format=qcow2,cache=none \
  -drive if=none,id=drive4,file=vms/w10p64-5.qcow2,format=qcow2,cache=none \
  -drive 
if=none,id=drive5,file=vms/w10p64-6.qcow2,format=qcow2,cache=none,discard=unmap 
\
  -drive if=none,id=drive6,file=/dev/mapper/w10p64-7,format=raw,cache=none \
  -drive 
if=none,id=drive7,file=vms/w10p64-8.qcow2,format=qcow2,cache=none,discard=unmap 
\
  -device vfio-pci,host=01:00.0,multifunction=on,x-vga=on \
  -device vfio-pci,host=01:00.1,multifunction=on \
  -netdev type=tap,id=net1,ifname=tap1,script=no,downscript=no,vhost=on \
  -device 
virtio-net-pci,netdev=net1,mac=52:54:00:18:32:c9,bus=pcie.2,addr=00.0,ioeventfd=on
 \
  -device usb-host,bus=usb.0,hostbus=3,hostport=2.1 \
  -device usb-host,hostbus=3,hostport=2.2 \
  -device usb-host,bus=ich9-ehci-1.0,hostbus=3,hostport=2.4 \
  -object input-linux,id=kbd1,evdev=/dev/input/event0,grab_all=yes,repeat=on \
  -drive if=none,id=drive8,file=vms/w10p64.qcow2-9,format=qcow2,discard=unmap \
  -drive 
if=none,id=drive9,file=vms/w10p64-10.qcow2,format=qcow2,cache=none,discard=unmap
 \
  -device usb-host,bus=usb.0,hostbus=3,hostport=9 \
  -monitor stdio

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

Re: [Qemu-devel] [PATCH] s390x/sclp: mark sclp-cpu-hotplug as non-usercreatable

[Thomas Huth]

On 04.10.2017 17:46, Cornelia Huck wrote:
> A TYPE_SCLP_CPU_HOTPLUG device for handling cpu hotplug events
> is already created by the sclp event facility. Adding a second
> TYPE_SCLP_CPU_HOTPLUG device via -device sclp-cpu-hotplug creates
> an ambiguity in raise_irq_cpu_hotplug(), leading to a crash once
> a cpu is hotplugged.
> 
> To fix this, disallow creating a sclp-cpu-hotplug device manually.
> 
> Signed-off-by: Cornelia Huck 
> ---
>  hw/s390x/sclpcpu.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/hw/s390x/sclpcpu.c b/hw/s390x/sclpcpu.c
> index 023d059a46..3ee890b392 100644
> --- a/hw/s390x/sclpcpu.c
> +++ b/hw/s390x/sclpcpu.c
> @@ -82,6 +82,12 @@ static void cpu_class_init(ObjectClass *oc, void *data)
>  k->get_receive_mask = receive_mask;
>  k->read_event_data = read_event_data;
>  set_bit(DEVICE_CATEGORY_MISC, dc->categories);
> +/*
> + * Reason: raise_irq_cpu_hotplug() depends on an unique
> + * TYPE_SCLP_CPU_HOTPLUG device, which is already created
> + * by the sclp event facility
> + */
> +dc->user_creatable = false;
>  }

Reviewed-by: Thomas Huth 

[Qemu-devel] [PATCH 4/8] xen: destroy_hvm_domain: Move reason into a variable

[Ian Jackson]

We are going to want to reuse this.

No functional change.

Signed-off-by: Ian Jackson 
Reviewed-by: Anthony PERARD 
---
 hw/i386/xen/xen-hvm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 7b60ec6..83420cd 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -1387,12 +1387,13 @@ void destroy_hvm_domain(bool reboot)
 xc_interface *xc_handle;
 int sts;
 
+unsigned int reason = reboot ? SHUTDOWN_reboot : SHUTDOWN_poweroff;
+
 xc_handle = xc_interface_open(0, 0, 0);
 if (xc_handle == NULL) {
 fprintf(stderr, "Cannot acquire xenctrl handle\n");
 } else {
-sts = xc_domain_shutdown(xc_handle, xen_domid,
- reboot ? SHUTDOWN_reboot : SHUTDOWN_poweroff);
+sts = xc_domain_shutdown(xc_handle, xen_domid, reason);
 if (sts != 0) {
 fprintf(stderr, "xc_domain_shutdown failed to issue %s, "
 "sts %d, %s\n", reboot ? "reboot" : "poweroff",
-- 
2.1.4

[Qemu-devel] [PATCH 5/8] xen: move xc_interface compatibility fallback further up the file

[Ian Jackson]

We are going to want to use the dummy xendevicemodel_handle type in
new stub functions in the CONFIG_XEN_CTRL_INTERFACE_VERSION < 41000
section.  So we need to provide that definition, or (as applicable)
include the appropriate header, earlier in the file.

(Ideally the newer compatibility layers would be at the bottom of the
file, so that they can naturally benefit from the compatibility layers
for earlier version.  But that's rather too much for this series.)

No functional change.

Signed-off-by: Ian Jackson 
---
v2: New patch in v2 of the series
---
 include/hw/xen/xen_common.h | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 3f44a63..8efdb8a 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -78,6 +78,17 @@ static inline void *xenforeignmemory_map(xc_interface *h, 
uint32_t dom,
 
 extern xenforeignmemory_handle *xen_fmem;
 
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40900
+
+typedef xc_interface xendevicemodel_handle;
+
+#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40900 */
+
+#undef XC_WANT_COMPAT_DEVICEMODEL_API
+#include 
+
+#endif
+
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 41000
 
 #define XEN_COMPAT_PHYSMAP
@@ -105,8 +116,6 @@ static inline int xentoolcore_restrict_all(domid_t domid)
 
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40900
 
-typedef xc_interface xendevicemodel_handle;
-
 static inline xendevicemodel_handle *xendevicemodel_open(
 struct xentoollog_logger *logger, unsigned int open_flags)
 {
@@ -228,11 +237,6 @@ static inline int xendevicemodel_set_mem_type(
 return xc_hvm_set_mem_type(dmod, domid, mem_type, first_pfn, nr);
 }
 
-#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40900 */
-
-#undef XC_WANT_COMPAT_DEVICEMODEL_API
-#include 
-
 #endif
 
 extern xendevicemodel_handle *xen_dmod;
-- 
2.1.4

[Qemu-devel] [PATCH 7/8] os-posix: Provide new -runasid option

[Ian Jackson]

This allows the caller to specify a uid and gid to use, even if there
is no corresponding password entry.  This will be useful in certain
Xen configurations.

Signed-off-by: Ian Jackson 
---
v2: Coding style fixes.
---
 os-posix.c  | 31 +++
 qemu-options.hx | 12 
 2 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/os-posix.c b/os-posix.c
index 92e9d85..d63680b 100644
--- a/os-posix.c
+++ b/os-posix.c
@@ -43,6 +43,8 @@
 #endif
 
 static struct passwd *user_pwd;
+static uid_t user_uid = (uid_t)-1;
+static gid_t user_gid = (gid_t)-1;
 static const char *chroot_dir;
 static int daemonize;
 static int daemon_pipe;
@@ -134,6 +136,9 @@ void os_set_proc_name(const char *s)
  */
 void os_parse_cmd_args(int index, const char *optarg)
 {
+unsigned long lv;
+char *ep;
+int rc;
 switch (index) {
 #ifdef CONFIG_SLIRP
 case QEMU_OPTION_smb:
@@ -150,6 +155,22 @@ void os_parse_cmd_args(int index, const char *optarg)
 exit(1);
 }
 break;
+case QEMU_OPTION_runasid:
+errno = 0;
+lv = strtoul(optarg, , 0); /* can't qemu_strtoul, want *ep=='.' */
+user_uid = lv; /* overflow here is ID in C99 */
+if (errno || *ep != '.' || user_uid != lv || user_uid == (uid_t)-1) {
+fprintf(stderr, "Could not obtain uid from \"%s\"", optarg);
+exit(1);
+}
+lv = 0;
+rc = qemu_strtoul(ep + 1, 0, 0, );
+user_gid = lv; /* overflow here is ID in C99 */
+if (rc || user_gid != lv || user_gid == (gid_t)-1) {
+fprintf(stderr, "Could not obtain gid from \"%s\"", optarg);
+exit(1);
+}
+break;
 case QEMU_OPTION_chroot:
 chroot_dir = optarg;
 break;
@@ -166,17 +187,19 @@ void os_parse_cmd_args(int index, const char *optarg)
 
 static void change_process_uid(void)
 {
-if (user_pwd) {
-if (setgid(user_pwd->pw_gid) < 0) {
+if (user_pwd || user_uid != (uid_t)-1) {
+if (setgid(user_pwd ? user_pwd->pw_gid : user_gid) < 0) {
 fprintf(stderr, "Failed to setgid(%d)\n", user_pwd->pw_gid);
 exit(1);
 }
-if (initgroups(user_pwd->pw_name, user_pwd->pw_gid) < 0) {
+if ((user_pwd
+ ? initgroups(user_pwd->pw_name, user_pwd->pw_gid)
+ : setgroups(1, _gid)) < 0) {
 fprintf(stderr, "Failed to initgroups(\"%s\", %d)\n",
 user_pwd->pw_name, user_pwd->pw_gid);
 exit(1);
 }
-if (setuid(user_pwd->pw_uid) < 0) {
+if (setuid(user_pwd ? user_pwd->pw_uid : user_gid) < 0) {
 fprintf(stderr, "Failed to setuid(%d)\n", user_pwd->pw_uid);
 exit(1);
 }
diff --git a/qemu-options.hx b/qemu-options.hx
index 9f6e2ad..34a5329 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3968,6 +3968,18 @@ Immediately before starting guest execution, drop root 
privileges, switching
 to the specified user.
 ETEXI
 
+#ifndef _WIN32
+DEF("runasid", HAS_ARG, QEMU_OPTION_runasid, \
+"-runasid uid.gid change to numeric uid and gid just before starting 
the VM\n",
+QEMU_ARCH_ALL)
+#endif
+STEXI
+@item -runasid @var{uid}.@var{gid}
+@findex -runasid
+Immediately before starting guest execution, drop root privileges, switching
+to the specified uid and gid.
+ETEXI
+
 DEF("prom-env", HAS_ARG, QEMU_OPTION_prom_env,
 "-prom-env variable=value\n"
 "set OpenBIOS nvram variables\n",
-- 
2.1.4

[Qemu-devel] [PATCH 1/8] xen: link against xentoolcore

[Ian Jackson]

From: Anthony PERARD 

Xen libraries 4.10 will include a new xentoolcore library, without
which xendevicemodel et al will not work.

Signed-off-by: Ian Jackson 
---
 configure | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index fd7e3a5..6f691df 100755
--- a/configure
+++ b/configure
@@ -2072,7 +2072,7 @@ if test "$xen" != "no" ; then
   $($pkg_config --modversion xencontrol | sed 's/\./ /g') )"
 xen=yes
 xen_pc="xencontrol xenstore xenguest xenforeignmemory xengnttab"
-xen_pc="$xen_pc xenevtchn xendevicemodel"
+xen_pc="$xen_pc xenevtchn xendevicemodel xentoolcore"
 QEMU_CFLAGS="$QEMU_CFLAGS $($pkg_config --cflags $xen_pc)"
 libs_softmmu="$($pkg_config --libs $xen_pc) $libs_softmmu"
 LDFLAGS="$($pkg_config --libs $xen_pc) $LDFLAGS"
@@ -2104,18 +2104,20 @@ EOF
 cat > $TMPC <
+#include 
 int main(void) {
   xenforeignmemory_handle *xfmem;
 
   xfmem = xenforeignmemory_open(0, 0);
   xenforeignmemory_map2(xfmem, 0, 0, 0, 0, 0, 0, 0);
+  xentoolcore_restrict_all(0);
 
   return 0;
 }
 EOF
-compile_prog "" "$xen_libs -lxendevicemodel $xen_stable_libs"
+compile_prog "" "$xen_libs -lxendevicemodel $xen_stable_libs 
-lxentoolcore"
   then
-  xen_stable_libs="-lxendevicemodel $xen_stable_libs"
+  xen_stable_libs="-lxendevicemodel $xen_stable_libs -lxentoolcore"
   xen_ctrl_version=41000
   xen=yes
 elif
-- 
2.1.4

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

[Eric Blake]

On 10/04/2017 09:26 AM, Jan Dakinevich wrote:

> +{
> +'struct': 'VirtioInfo',
> +'data': {
> +'feature-names': ['VirtioInfoBit'],

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

>>>
>>> These are different feature names. First names are common and predefined
>>> for all devices. Second names are device-specific.
>>
>> If you can turn these into enums (union'd enums?) then you might
>> be able to get rid of a lot of your array filling/naming conversion
>> boilerplate. (Not sure if it's worth it, but it's worth looking).
>>
> 
> I would be happy to drop this boilerplate, but how enum could help here?
> To respond my requirement it should be something like set, not enum.
> Even so, having set, I would have been needed to declare mapping between
> names in set type and bit numbers within feature bitmask.

Instead of returning a bitmask ("mask":123) as well as an array naming
those bits
([{"bit":1,"name":"bit1"},{"bit":2","name":"bit2"},{"bit":4,"name":"bit4},...]),
you could omit the bit numbers and just return an array of named bits
(["bit1", "bit2", "bit4"]).  An enum lets you declare up front what
named bits are supported (and code can introspect when new named bits
are supported in newer qemu).

Perhaps it's easier to first take a step back, and show what the desired
output might be like, and then we can figure out how to represent that
output in QAPI.

-- 
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 8/8] RFC configure: do_compiler: Dump some extra info under bash

[Ian Jackson]

This makes it much easier to find a particular thing in config.log.

The information may be lacking in other shells, resulting in harmless
empty output.  (This is why we don't use the proper ${FUNCNAME[*]}
array syntax - other shells will choke on that.)

The extra output is only printed if configure is run with bash.  The
something), it is necessary to say   bash ./configure  to get the extra
debug info in the log.

Signed-off-by: Ian Jackson 
---
 configure | 4 
 1 file changed, 4 insertions(+)

diff --git a/configure b/configure
index 6f691df..21a2b15 100755
--- a/configure
+++ b/configure
@@ -60,6 +60,10 @@ do_compiler() {
 # is compiler binary to execute.
 local compiler="$1"
 shift
+echo >>config.log "
+funcs: ${FUNCNAME}
+lines: ${BASH_LINENO}
+files: ${BASH_SOURCE}"
 echo $compiler "$@" >> config.log
 $compiler "$@" >> config.log 2>&1 || return $?
 # Test passed. If this is an --enable-werror build, rerun
-- 
2.1.4

[Qemu-devel] [PATCH v2 0/7] xen: xen-domid-restrict improvements

[Ian Jackson]

I have been working on trying to get qemu, when running as a Xen
device model, to _actually_ not have power equivalent to root.

I think I have achieved this, with some limitations (which will be
discussed in my series against xen.git.

However, there are changes to qemu needed.  In particular

 * The -xen-domid-restrict option does not work properly right now.
   It only restricts a small subset of the descriptors qemu has open.
   I am introducing a new library call in the Xen libraries for this,
   xentoolcore_restrict_all.

 * We need to call a different function on domain shutdown.

 * The restriction operation needs to be done at a slightly different
   time, necessitating a new hook.

 * Additionally, in the future, we intend to be able to set aside
   a uid range for these qemus to run in, and that involves being
   able to tell qemu to drop privilege by numeric uid and gid.

Thanks very much to Anthony Perard for his review of the first, RFC,
version, and for helping out with configure.

At least the first patch of this, "xen: link against xentoolcore",
will very likely be necessary, since the corresponding xen.git series
is likely to make Xen 4.10.

Ian.

Re: [Qemu-devel] [PATCH v1 2/2] ide: support reporting of rotation rate

[John Snow]

On 10/04/2017 07:40 AM, Daniel P. Berrange wrote:
> The Linux kernel will query the ATA IDENTITY DEVICE data, word 217
> to determine the rotations per minute of the disk. If this has
> the value 1, it is taken to be an SSD and so Linux sets the
> 'rotational' flag to 0 for the I/O queue and will stop using that
> disk as a source of random entropy. Other operating systems may
> also take into account rotation rate when setting up default
> behaviour.
> 
> Mgmt apps should be able to set the rotation rate for virtualized
> block devices, based on characteristics of the host storage in use,
> so that the guest OS gets sensible behaviour out of the box. This
> patch thus adds a 'rotation-rate' parameter for 'ide-hd' device
> types.
> 
> Signed-off-by: Daniel P. Berrange 
> ---
>  hw/ide/core.c | 1 +
>  hw/ide/qdev.c | 1 +
>  include/hw/ide/internal.h | 8 
>  3 files changed, 10 insertions(+)
> 
> diff --git a/hw/ide/core.c b/hw/ide/core.c
> index 5f1cd3b91f..a04766aee7 100644
> --- a/hw/ide/core.c
> +++ b/hw/ide/core.c
> @@ -208,6 +208,7 @@ static void ide_identify(IDEState *s)
>  if (dev && dev->conf.discard_granularity) {
>  put_le16(p + 169, 1); /* TRIM support */
>  }
> +put_le16(p + 217, dev->rotation_rate); /* Nominal media rotation rate */
>  
>  ide_identify_size(s);
>  s->identify_set = 1;
> diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
> index d60ac25be0..a5181b4448 100644
> --- a/hw/ide/qdev.c
> +++ b/hw/ide/qdev.c
> @@ -299,6 +299,7 @@ static Property ide_hd_properties[] = {
>  DEFINE_BLOCK_CHS_PROPERTIES(IDEDrive, dev.conf),
>  DEFINE_PROP_BIOS_CHS_TRANS("bios-chs-trans",
>  IDEDrive, dev.chs_trans, BIOS_ATA_TRANSLATION_AUTO),
> +DEFINE_PROP_UINT16("rotation_rate", IDEDrive, dev.rotation_rate, 0),
>  DEFINE_PROP_END_OF_LIST(),
>  };
>  
> diff --git a/include/hw/ide/internal.h b/include/hw/ide/internal.h
> index e641012b48..31851b44d1 100644
> --- a/include/hw/ide/internal.h
> +++ b/include/hw/ide/internal.h
> @@ -508,6 +508,14 @@ struct IDEDevice {
>  char *serial;
>  char *model;
>  uint64_t wwn;
> +/*
> + * 0x- rotation rate not reported
> + * 0x0001- non-rotating medium (SSD)
> + * 0x0002-0x0400 - reserved
> + * 0x0401-0xffe  - rotations per minute
> + * 0x- reserved
> + */
> +uint16_t rotation_rate;
>  };
>  
>  /* These are used for the error_status field of IDEBus */
> 

With Eric's comment addressed:

Reviewed-by: John Snow 

It'd be nice if we could have a magic autodetect value, but this is a
strict improvement anyway.

(Actually, probably most of the identify data needs to be audited, but
the perceived cost:benefit ratio doesn't look too favorable.)

Re: [Qemu-devel] [PATCH 1/6] tests: Add basic migration precopy test

[Eric Blake]

On 10/04/2017 05:39 AM, Juan Quintela wrote:
> Signed-off-by: Juan Quintela 
> ---
>  tests/Makefile.include |   3 +
>  tests/migration-test.c | 497 
> +
>  2 files changed, 500 insertions(+)
>  create mode 100644 tests/migration-test.c

New file; should it be mentioned in MAINTAINERS?

At least you picked a name that matches .gitignore's existing '*.test'
exclusion when the binary is built in-tree.

-- 
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 3/8] xen: defer call to xen_restrict until after os_setup_post

[Ian Jackson]

We need to restrict *all* the control fds that qemu opens.  Looking in
/proc/PID/fd shows there are many; their allocation seems scattered
throughout Xen support code in qemu.

We must postpone the restrict call until roughly the same time as qemu
changes its uid, chroots (if applicable), and so on.

There doesn't seem to be an appropriate hook already.  The RunState
change hook fires at different times depending on exactly what mode
qemu is operating in.

And it appears that no-one but the Xen code wants a hook at this phase
of execution.  So, introduce a bare call to a new function
xen_setup_post, just after os_setup_post.  Also provide the
appropriate stub for when Xen compilation is disabled.

Signed-off-by: Ian Jackson 
---
 hw/i386/xen/xen-hvm.c   |  8 
 hw/xen/xen-common.c | 13 +
 include/sysemu/sysemu.h |  2 ++
 stubs/xen-hvm.c |  5 +
 vl.c|  1 +
 5 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index d9ccd5d..7b60ec6 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -1254,14 +1254,6 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 goto err;
 }
 
-if (xen_domid_restrict) {
-rc = xen_restrict(xen_domid);
-if (rc < 0) {
-error_report("failed to restrict: error %d", errno);
-goto err;
-}
-}
-
 xen_create_ioreq_server(xen_domid, >ioservid);
 
 state->exit.notify = xen_exit_notifier;
diff --git a/hw/xen/xen-common.c b/hw/xen/xen-common.c
index 632a938..4056420 100644
--- a/hw/xen/xen-common.c
+++ b/hw/xen/xen-common.c
@@ -117,6 +117,19 @@ static void xen_change_state_handler(void *opaque, int 
running,
 }
 }
 
+void xen_setup_post(void)
+{
+int rc;
+
+if (xen_domid_restrict) {
+rc = xen_restrict(xen_domid);
+if (rc < 0) {
+perror("xen: failed to restrict");
+exit(1);
+}
+}
+}
+
 static int xen_init(MachineState *ms)
 {
 xen_xc = xc_interface_open(0, 0, 0);
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index b213696..b064a55 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -93,6 +93,8 @@ void qemu_remove_machine_init_done_notifier(Notifier *notify);
 
 void qemu_announce_self(void);
 
+void xen_setup_post(void);
+
 extern int autostart;
 
 typedef enum {
diff --git a/stubs/xen-hvm.c b/stubs/xen-hvm.c
index 3ca6c51..9701feb 100644
--- a/stubs/xen-hvm.c
+++ b/stubs/xen-hvm.c
@@ -13,6 +13,7 @@
 #include "hw/xen/xen.h"
 #include "exec/memory.h"
 #include "qmp-commands.h"
+#include "sysemu/sysemu.h"
 
 int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
 {
@@ -61,3 +62,7 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
 {
 }
+
+void xen_setup_post(void)
+{
+}
diff --git a/vl.c b/vl.c
index fb1f05b..9e7d541 100644
--- a/vl.c
+++ b/vl.c
@@ -4793,6 +4793,7 @@ int main(int argc, char **argv, char **envp)
 }
 
 os_setup_post();
+xen_setup_post();
 
 main_loop();
 replay_disable_events();
-- 
2.1.4

Re: [Qemu-devel] kvm_set_phys_mem: assertion failed

[Laszlo Ersek]

Hi,

On 09/21/17 16:28, Auger Eric wrote:
> Hi David,
> On 20/09/2017 16:34, David Hildenbrand wrote:
>> On 20.09.2017 16:31, Gerd Hoffmann wrote:
>>>   Hi,
>>>
 Dropping from os section:

 >>> type="pflash">/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-
 efi.fd
 >>> template="/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-
 efi.fd">/var/lib/libvirt/qemu/nvram/fedora-org-drm-qxl-
 base_VARS.fd
>>>
>>> Bad idea I guess.
>>>
 1) Does the assert trigger right at startup? Or how is it triggered?
>>>
>>> Yes, right at startup, before OVMF is done initializing.
>>> So probably something in OVMF triggers it.
>>
>> I'll try to include ovmf to reproduce it.
>>
>>>
 2) Does your setup work when dopping the assertion?
>>>
>>> Can try tomorrow.
> I encounter the problem on ARM too. My setup works when dropping the
> assertion.
> 
> Thanks
> 
> Eric
>>
>> I think that assertion might not be stable, because properties (romd
>> mode) might not be stable and can change. So if it works without the
>> assert, dropping it is the right thing to do.

There seems to be a new issue report on LaunchPad about the same
(f357f564be0b) commit, stating that the removal of the assertion does
not help:

https://bugs.launchpad.net/qemu/+bug/1721221

(Just trying to connect the dots here; I have no comments on the commit
otherwise. CC'ing Joe who has filed the LP report.)

Thanks
Laszlo

[Qemu-devel] [PATCH 6/8] xen: destroy_hvm_domain: Try xendevicemodel_shutdown

[Ian Jackson]

xc_interface_open etc. is not going to work if we have dropped
privilege, but xendevicemodel_shutdown will if everything is new
enough.

xendevicemodel_shutdown is only availabe in Xen 4.10 and later, so
provide a stub for earlier versions.

Signed-off-by: Ian Jackson 
---
v2: Add compatibility stub for Xen < 4.10.
Fix coding style.

Signed-off-by: Ian Jackson 
---
 hw/i386/xen/xen-hvm.c   | 10 ++
 include/hw/xen/xen_common.h |  7 +++
 2 files changed, 17 insertions(+)

diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 83420cd..25b8b14 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -1386,9 +1386,19 @@ void destroy_hvm_domain(bool reboot)
 {
 xc_interface *xc_handle;
 int sts;
+int rc;
 
 unsigned int reason = reboot ? SHUTDOWN_reboot : SHUTDOWN_poweroff;
 
+if (xen_dmod) {
+rc = xendevicemodel_shutdown(xen_dmod, xen_domid, reason);
+if (!rc) {
+return;
+}
+perror("xendevicemodel_shutdown failed");
+/* well, try the old thing then */
+}
+
 xc_handle = xc_interface_open(0, 0, 0);
 if (xc_handle == NULL) {
 fprintf(stderr, "Cannot acquire xenctrl handle\n");
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 8efdb8a..1d6fb57 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -108,6 +108,13 @@ static inline int xentoolcore_restrict_all(domid_t domid)
 return -1;
 }
 
+static inline int xendevicemodel_shutdown(xendevicemodel_handle *dmod,
+  domid_t domid, unsigned int reason)
+{
+errno = ENOTTY;
+return -1;
+}
+
 #else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 41000 */
 
 #include 
-- 
2.1.4

Re: [Qemu-devel] [PATCH] checkpatch: fix incompatibility with old perl

[Alex Williamson]

On Wed,  4 Oct 2017 18:44:20 +0300
Vladimir Sementsov-Ogievskiy  wrote:

> Do not use '/r' modifier which was introduced in perl 5.14.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---

Fixes: 3e5875afc0f ("checkpatch: check trace-events code style")
Tested-by: Alex Williamson 

Thanks

>  scripts/checkpatch.pl | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 3c0a28e644..0c41f1212f 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -1432,7 +1432,8 @@ sub process {
>   qr/%[-+ 
> *.0-9]*([hljztL]|ll|hh)?(x|X|"\s*PRI[xX][^"]*"?)/;
>  
>   # don't consider groups splitted by [.:/ ], 
> like 2A.20:12ab
> - my $tmpline = $rawline =~ s/($hex[.:\/ 
> ])+$hex//gr;
> + my $tmpline = $rawline;
> + $tmpline =~ s/($hex[.:\/ ])+$hex//g;
>  
>   if ($tmpline =~ /(?   ERROR("Hex numbers must be prefixed 
> with '0x'\n" .

[Qemu-devel] [PATCH] s390x/sclp: mark sclp-cpu-hotplug as non-usercreatable

[Cornelia Huck]

A TYPE_SCLP_CPU_HOTPLUG device for handling cpu hotplug events
is already created by the sclp event facility. Adding a second
TYPE_SCLP_CPU_HOTPLUG device via -device sclp-cpu-hotplug creates
an ambiguity in raise_irq_cpu_hotplug(), leading to a crash once
a cpu is hotplugged.

To fix this, disallow creating a sclp-cpu-hotplug device manually.

Signed-off-by: Cornelia Huck 
---
 hw/s390x/sclpcpu.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/hw/s390x/sclpcpu.c b/hw/s390x/sclpcpu.c
index 023d059a46..3ee890b392 100644
--- a/hw/s390x/sclpcpu.c
+++ b/hw/s390x/sclpcpu.c
@@ -82,6 +82,12 @@ static void cpu_class_init(ObjectClass *oc, void *data)
 k->get_receive_mask = receive_mask;
 k->read_event_data = read_event_data;
 set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+/*
+ * Reason: raise_irq_cpu_hotplug() depends on an unique
+ * TYPE_SCLP_CPU_HOTPLUG device, which is already created
+ * by the sclp event facility
+ */
+dc->user_creatable = false;
 }
 
 static const TypeInfo sclp_cpu_info = {
-- 
2.13.6

[Qemu-devel] [PATCH 2/8] xen: restrict: use xentoolcore_restrict_all

[Ian Jackson]

And insist that it works.

Drop individual use of xendevicemodel_restrict and
xenforeignmemory_restrict.  These are not actually effective in this
version of qemu, because qemu has a large number of fds open onto
various Xen control devices.

The restriction arrangements are still not right, because the
restriction needs to be done very late - after qemu has opened all of
its control fds.

xentoolcore_restrict_all and xentoolcore.h are available in Xen 4.10
and later, only.  Provide a compatibility stub.  And drop the
compatibility stubs for the old functions.

Signed-off-by: Ian Jackson 
---
v2: Modify the compatibility code, too.
Bump this patch ahead of "defer call to xen_restrict until running"
Retain call to xentoolcore_restrict_all

Signed-off-by: Ian Jackson 
---
 include/hw/xen/xen_common.h | 46 +++--
 1 file changed, 11 insertions(+), 35 deletions(-)

diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 86c7f26..3f44a63 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -91,6 +91,16 @@ static inline void 
*xenforeignmemory_map2(xenforeignmemory_handle *h,
 return xenforeignmemory_map(h, dom, prot, pages, arr, err);
 }
 
+static inline int xentoolcore_restrict_all(domid_t domid)
+{
+errno = ENOTTY;
+return -1;
+}
+
+#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 41000 */
+
+#include 
+
 #endif
 
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40900
@@ -218,20 +228,6 @@ static inline int xendevicemodel_set_mem_type(
 return xc_hvm_set_mem_type(dmod, domid, mem_type, first_pfn, nr);
 }
 
-static inline int xendevicemodel_restrict(
-xendevicemodel_handle *dmod, domid_t domid)
-{
-errno = ENOTTY;
-return -1;
-}
-
-static inline int xenforeignmemory_restrict(
-xenforeignmemory_handle *fmem, domid_t domid)
-{
-errno = ENOTTY;
-return -1;
-}
-
 #else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40900 */
 
 #undef XC_WANT_COMPAT_DEVICEMODEL_API
@@ -290,28 +286,8 @@ static inline int xen_modified_memory(domid_t domid, 
uint64_t first_pfn,
 static inline int xen_restrict(domid_t domid)
 {
 int rc;
-
-/* Attempt to restrict devicemodel operations */
-rc = xendevicemodel_restrict(xen_dmod, domid);
+rc = xentoolcore_restrict_all(domid);
 trace_xen_domid_restrict(rc ? errno : 0);
-
-if (rc < 0) {
-/*
- * If errno is ENOTTY then restriction is not implemented so
- * there's no point in trying to restrict other types of
- * operation, but it should not be treated as a failure.
- */
-if (errno == ENOTTY) {
-return 0;
-}
-
-return rc;
-}
-
-/* Restrict foreignmemory operations */
-rc = xenforeignmemory_restrict(xen_fmem, domid);
-trace_xen_domid_restrict(rc ? errno : 0);
-
 return rc;
 }
 
-- 
2.1.4

[Qemu-devel] [Bug 1721221] Re: PCI-E passthrough of Nvidia GTX GFX card to Win 10 guest fails with "kvm_set_phys_mem: error registering slot: Invalid argument"

[Laszlo Ersek (Red Hat)]

There's another bug report / discussion thread on qemu-devel about the
same commit:

1505913885.24609.8.camel@redhat.com">http://mid.mail-archive.com/1505913885.24609.8.camel@redhat.com

I'll add a note to that thread about this LP report too.

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

Title:
  PCI-E passthrough of Nvidia GTX GFX card to Win 10 guest fails with
  "kvm_set_phys_mem: error registering slot: Invalid argument"

Status in QEMU:
  New

Bug description:
  Problem: 
  Passthrough of a PCI-E Nvidia GTX 970 GFX card to a Windows 10 guest from a 
Debian Stretch host fails after recent changes to kvm in QEMU master/trunk. 
Before this recent commit, everything worked as expected.

  QEMU Version:
  Master/trunk pulled from github 4/10/17 ( git reflog: d147f7e815 HEAD@{0} )

  Host:
  Debian Stretch kernel SMP Debian 4.9.30-2+deb9u5 (2017-09-19) x86_64 GNU/Linux

  Guest:
  Windows 10 Professional

  Issue is with this commit:
  https://github.com/qemu/qemu/commit/f357f564be0bd45245b3ccfbbe20ace08fe83ca8

  Subsequent commit does not help:
  
https://github.com/qemu/qemu/commit/3110cdbd8a4845c5b5fb861b0a664c56d993dd3c#diff-7b7a17f6e8ba4195198dd685073f43cb

  Error output from qemu: 
  (qemu) kvm_set_phys_mem: error registering slot: Invalid argument

  QEMU commandline used:

  ./sources/qemu/x86_64-softmmu/qemu-system-x86_64 -machine q35,accel=kvm 
-serial none -parallel none -name Windows \
  -enable-kvm -cpu host,kvm=off,hv_vendor_id=sugoidesu,-hypervisor -smp 
6,sockets=1,cores=3,threads=2 \
  -m 8G -mem-path /dev/hugepages -mem-prealloc -balloon none \
  -drive 
if=pflash,format=raw,readonly,file=vms/ovmf-x64/ovmf-x64/OVMF_CODE-pure-efi.fd \
  -drive if=pflash,format=raw,file=vms/ovmf-x64/ovmf-x64/OVMF_VARS-pure-efi.fd \
  -rtc clock=host,base=localtime \
  -readconfig ./vms/q35-virtio-graphical.cfg \
  -object iothread,id=iothread0 -object iothread,id=iothread1 -object 
iothread,id=iothread2 -object iothread,id=iothread3 \
  -device virtio-scsi-pci,iothread=iothread0,id=scsi0 -device 
virtio-scsi-pci,iothread=iothread1,id=scsi1 -device 
virtio-scsi-pci,iothread=iothread2,id=scsi2 -device 
virtio-scsi-pci,iothread=iothread3,id=scsi3 \
  -device scsi-hd,bus=scsi0.0,drive=drive0,bootindex=1 -device 
scsi-hd,bus=scsi1.0,drive=drive1 -device scsi-hd,bus=scsi2.0,drive=drive2 
-device scsi-hd,bus=scsi3.0,drive=drive3 -device 
scsi-hd,bus=scsi1.0,drive=drive4 -device scsi-hd,bus=scsi2.0,drive=drive5 
-device scsi-hd,bus=scsi3.0,drive=drive6 -device 
scsi-hd,bus=scsi1.0,drive=drive7 -device scsi-hd,bus=scsi2.0,drive=drive8 
-device scsi-hd,bus=scsi3.0,drive=drive9 \
  -drive 
if=none,id=drive0,file=vms/w10p64.qcow2,format=qcow2,cache=none,discard=unmap \
  -drive 
if=none,id=drive1,file=vms/w10p64-2.qcow2,format=qcow2,cache=none,discard=unmap 
\
  -drive if=none,id=drive2,file=/dev/mapper/w10p64-3,format=raw,cache=none \
  -drive if=none,id=drive3,file=vms/w10p64-4.qcow2,format=qcow2,cache=none \
  -drive if=none,id=drive4,file=vms/w10p64-5.qcow2,format=qcow2,cache=none \
  -drive 
if=none,id=drive5,file=vms/w10p64-6.qcow2,format=qcow2,cache=none,discard=unmap 
\
  -drive if=none,id=drive6,file=/dev/mapper/w10p64-7,format=raw,cache=none \
  -drive 
if=none,id=drive7,file=vms/w10p64-8.qcow2,format=qcow2,cache=none,discard=unmap 
\
  -device vfio-pci,host=01:00.0,multifunction=on,x-vga=on \
  -device vfio-pci,host=01:00.1,multifunction=on \
  -netdev type=tap,id=net1,ifname=tap1,script=no,downscript=no,vhost=on \
  -device 
virtio-net-pci,netdev=net1,mac=52:54:00:18:32:c9,bus=pcie.2,addr=00.0,ioeventfd=on
 \
  -device usb-host,bus=usb.0,hostbus=3,hostport=2.1 \
  -device usb-host,hostbus=3,hostport=2.2 \
  -device usb-host,bus=ich9-ehci-1.0,hostbus=3,hostport=2.4 \
  -object input-linux,id=kbd1,evdev=/dev/input/event0,grab_all=yes,repeat=on \
  -drive if=none,id=drive8,file=vms/w10p64.qcow2-9,format=qcow2,discard=unmap \
  -drive 
if=none,id=drive9,file=vms/w10p64-10.qcow2,format=qcow2,cache=none,discard=unmap
 \
  -device usb-host,bus=usb.0,hostbus=3,hostport=9 \
  -monitor stdio

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

Re: [Qemu-devel] [PATCH] Revert: checkpatch: check trace-events code style

[Vladimir Sementsov-Ogievskiy]

04.10.2017 17:59, Alex Williamson wrote:

On Wed, 4 Oct 2017 12:59:04 +0300
Vladimir Sementsov-Ogievskiy  wrote:


04.10.2017 01:00, Alex Williamson wrote:

Commit c3e5875afc0f ("checkpatch: check trace-events code style")
introduces a regression as reported:

https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg05820.html

Bareword found where operator expected at ./scripts/checkpatch.pl line 1350, near 
"s/($hex[.:\/ ])+$hex//gr"
syntax error at ./scripts/checkpatch.pl line 1350, near "s/($hex[.:\/ 
])+$hex//gr"
Execution of ./scripts/checkpatch.pl aborted due to compilation errors.

$ perl -v

This is perl, v5.10.1 (*) built for x86_64-linux-thread-multi

v5.10.1 is 8 years old.
most possibly the error relates to  /r modifier, which was added int
perl 5.14, so, possible solution would be

@@ -1432,7 +1432,8 @@ sub process {
   qr/%[-+
*.0-9]*([hljztL]|ll|hh)?(x|X|"\s*PRI[xX][^"]*"?)/;

   # don't consider groups splitted by [.:/ ], like
2A.20:12ab
-    my $tmpline = $rawline =~ s/($hex[.:\/ ])+$hex//gr;
+    my $tmpline = $rawline;
+    my $tmpline =~ s/($hex[.:\/ ])+$hex//g;


of course, last line should be without "my". I've sent a fixed patch.



   if ($tmpline =~ /(?
Yes, that fixes it.


As no fix or discussion has resulted, revert the original patch.

Sorry for no answer on your report

No worries, this seems to have gotten the job done.  Please post the
patch above and I withdraw my revert.  Thanks,

Alex


Cc: Vladimir Sementsov-Ogievskiy 
Cc: Stefan Hajnoczi 
Fixes: c3e5875afc0f ("checkpatch: check trace-events code style")
Signed-off-by: Alex Williamson 
---
   scripts/checkpatch.pl |   19 ---
   1 file changed, 19 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 3c0a28e644aa..f7e785d12a49 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1422,25 +1422,6 @@ sub process {
$rpt_cleaners = 1;
}
   
-# checks for trace-events files

-   if ($realfile =~ /trace-events$/ && $line =~ /^\+/) {
-   if ($rawline =~ /%[-+ 0]*#/) {
-   ERROR("Don't use '#' flag of printf format ('%#') in 
" .
- "trace-events, use '0x' prefix instead\n" 
. $herecurr);
-   } else {
-   my $hex =
-   qr/%[-+ 
*.0-9]*([hljztL]|ll|hh)?(x|X|"\s*PRI[xX][^"]*"?)/;
-
-   # don't consider groups splitted by [.:/ ], 
like 2A.20:12ab
-   my $tmpline = $rawline =~ s/($hex[.:\/ 
])+$hex//gr;
-
-   if ($tmpline =~ /(?   
  





--
Best regards,
Vladimir

Re: [Qemu-devel] [PATCH v1 2/2] ide: support reporting of rotation rate

[Eric Blake]

On 10/04/2017 06:40 AM, Daniel P. Berrange wrote:
> The Linux kernel will query the ATA IDENTITY DEVICE data, word 217
> to determine the rotations per minute of the disk. If this has
> the value 1, it is taken to be an SSD and so Linux sets the
> 'rotational' flag to 0 for the I/O queue and will stop using that
> disk as a source of random entropy. Other operating systems may
> also take into account rotation rate when setting up default
> behaviour.
> 
> Mgmt apps should be able to set the rotation rate for virtualized
> block devices, based on characteristics of the host storage in use,
> so that the guest OS gets sensible behaviour out of the box. This
> patch thus adds a 'rotation-rate' parameter for 'ide-hd' device
> types.
> 
> Signed-off-by: Daniel P. Berrange 
> ---
>  hw/ide/core.c | 1 +

> +++ b/include/hw/ide/internal.h
> @@ -508,6 +508,14 @@ struct IDEDevice {
>  char *serial;
>  char *model;
>  uint64_t wwn;
> +/*
> + * 0x- rotation rate not reported
> + * 0x0001- non-rotating medium (SSD)
> + * 0x0002-0x0400 - reserved
> + * 0x0401-0xffe  - rotations per minute

s/0xffe/0xfffe/

> + * 0x- reserved
> + */
> +uint16_t rotation_rate;
>  };
>  
>  /* These are used for the error_status field of IDEBus */
> 

-- 
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] checkpatch: fix incompatibility with old perl

[Vladimir Sementsov-Ogievskiy]

Do not use '/r' modifier which was introduced in perl 5.14.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 scripts/checkpatch.pl | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 3c0a28e644..0c41f1212f 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1432,7 +1432,8 @@ sub process {
qr/%[-+ 
*.0-9]*([hljztL]|ll|hh)?(x|X|"\s*PRI[xX][^"]*"?)/;
 
# don't consider groups splitted by [.:/ ], 
like 2A.20:12ab
-   my $tmpline = $rawline =~ s/($hex[.:\/ 
])+$hex//gr;
+   my $tmpline = $rawline;
+   $tmpline =~ s/($hex[.:\/ ])+$hex//g;
 
if ($tmpline =~ /(?

Re: [Qemu-devel] [PATCH v1 1/2] scsi-disk: support reporting of rotation rate

[Eric Blake]

On 10/04/2017 06:40 AM, Daniel P. Berrange wrote:
> The Linux kernel will query the SCSI "Block device characteristics"
> VPD to determine the rotations per minute of the disk. If this has
> the value 1, it is taken to be an SSD and so Linux sets the
> 'rotational' flag to 0 for the I/O queue and will stop using that
> disk as a source of random entropy. Other operating systems may
> also take into account rotation rate when setting up default
> behaviour.
> 
> Mgmt apps should be able to set the rotation rate for virtualized
> block devices, based on characteristics of the host storage in use,
> so that the guest OS gets sensible behaviour out of the box. This
> patch thus adds a 'rotation-rate' parameter for 'scsi-hd' and
> 'scsi-block' device types. For the latter, this parameter will be
> ignored unless the host device has TYPE_DISK.
> 
> Signed-off-by: Daniel P. Berrange 
> ---
>  hw/scsi/scsi-disk.c | 20 
>  1 file changed, 20 insertions(+)

>  bool tray_locked;
> +/*
> + * 0x- rotation rate not reported
> + * 0x0001- non-rotating medium (SSD)
> + * 0x0002-0x0400 - reserved
> + * 0x0401-0xffe  - rotations per minute

s/0xffe/0xfffe/

> + * 0x- reserved
> + */
> +uint16_t rotation_rate;
>  } SCSIDiskState;
>  
>  static bool scsi_handle_rw_error(SCSIDiskReq *r, int error, bool 
> acct_failed);
> @@ -605,6 +613,7 @@ static int scsi_disk_emulate_inquiry(SCSIRequest *req, 
> uint8_t *outbuf)
>  outbuf[buflen++] = 0x83; // device identification
>  if (s->qdev.type == TYPE_DISK) {
>  outbuf[buflen++] = 0xb0; // block limits
> +outbuf[buflen++] = 0xb1; /* block device characteristics */

This function is awkward - it is a non-local audit to see whether we are
 at risk of overflowing any buffers due to the new output.  But from
what I can see, I think you're safe.

-- 
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 v2 6/8] s390x: refactor error handling for HSCH handler

[Halil Pasic]

Simplify the error handling of the HSCH.  Let the code detecting the
condition tell (in a less ambiguous way) how it's to be handled. No
changes in behavior.

Signed-off-by: Halil Pasic 
---
 hw/s390x/css.c | 18 +-
 include/hw/s390x/css.h |  2 +-
 target/s390x/ioinst.c  | 23 ---
 3 files changed, 10 insertions(+), 33 deletions(-)

diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index 1839f40408..6da3e4ea61 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -1272,28 +1272,24 @@ IOInstEnding css_do_csch(SubchDev *sch)
 return do_subchannel_work(sch);
 }
 
-int css_do_hsch(SubchDev *sch)
+IOInstEnding css_do_hsch(SubchDev *sch)
 {
 SCSW *s = >curr_status.scsw;
 PMCW *p = >curr_status.pmcw;
-int ret;
 
 if (~(p->flags) & (PMCW_FLAGS_MASK_DNV | PMCW_FLAGS_MASK_ENA)) {
-ret = -ENODEV;
-goto out;
+return (IOInstEnding){.cc = 3};
 }
 
 if (((s->ctrl & SCSW_CTRL_MASK_STCTL) == SCSW_STCTL_STATUS_PEND) ||
 (s->ctrl & (SCSW_STCTL_PRIMARY |
 SCSW_STCTL_SECONDARY |
 SCSW_STCTL_ALERT))) {
-ret = -EINPROGRESS;
-goto out;
+return (IOInstEnding){.cc = 1};
 }
 
 if (s->ctrl & (SCSW_FCTL_HALT_FUNC | SCSW_FCTL_CLEAR_FUNC)) {
-ret = -EBUSY;
-goto out;
+return (IOInstEnding){.cc = 2};
 }
 
 /* Trigger the halt function. */
@@ -1306,11 +1302,7 @@ int css_do_hsch(SubchDev *sch)
 }
 s->ctrl |= SCSW_ACTL_HALT_PEND;
 
-do_subchannel_work(sch);
-ret = 0;
-
-out:
-return ret;
+return do_subchannel_work(sch);
 }
 
 static void css_update_chnmon(SubchDev *sch)
diff --git a/include/hw/s390x/css.h b/include/hw/s390x/css.h
index 6ca077..a4064711e2 100644
--- a/include/hw/s390x/css.h
+++ b/include/hw/s390x/css.h
@@ -214,7 +214,7 @@ bool css_schid_final(int m, uint8_t cssid, uint8_t ssid, 
uint16_t schid);
 int css_do_msch(SubchDev *sch, const SCHIB *schib);
 IOInstEnding css_do_xsch(SubchDev *sch);
 IOInstEnding css_do_csch(SubchDev *sch);
-int css_do_hsch(SubchDev *sch);
+IOInstEnding css_do_hsch(SubchDev *sch);
 IOInstEnding css_do_ssch(SubchDev *sch, ORB *orb);
 int css_do_tsch_get_irb(SubchDev *sch, IRB *irb, int *irb_len);
 void css_do_tsch_update_subch(SubchDev *sch);
diff --git a/target/s390x/ioinst.c b/target/s390x/ioinst.c
index b12b3d1d41..12102bab0f 100644
--- a/target/s390x/ioinst.c
+++ b/target/s390x/ioinst.c
@@ -78,8 +78,6 @@ void ioinst_handle_hsch(S390CPU *cpu, uint64_t reg1)
 {
 int cssid, ssid, schid, m;
 SubchDev *sch;
-int ret = -ENODEV;
-int cc;
 
 if (ioinst_disassemble_sch_ident(reg1, , , , )) {
 program_interrupt(>env, PGM_OPERAND, 4);
@@ -87,24 +85,11 @@ void ioinst_handle_hsch(S390CPU *cpu, uint64_t reg1)
 }
 trace_ioinst_sch_id("hsch", cssid, ssid, schid);
 sch = css_find_subch(m, cssid, ssid, schid);
-if (sch && css_subch_visible(sch)) {
-ret = css_do_hsch(sch);
-}
-switch (ret) {
-case -ENODEV:
-cc = 3;
-break;
-case -EBUSY:
-cc = 2;
-break;
-case 0:
-cc = 0;
-break;
-default:
-cc = 1;
-break;
+if (!sch || !css_subch_visible(sch)) {
+setcc(cpu, 3);
+return;
 }
-setcc(cpu, cc);
+setcc(cpu, css_do_hsch(sch).cc);
 }
 
 static int ioinst_schib_valid(SCHIB *schib)
-- 
2.13.5

[Qemu-devel] [PATCH v2 7/8] s390x: refactor error handling for MSCH handler

[Halil Pasic]

Simplify the error handling of the MSCH.  Let the code detecting the
condition tell (in a less ambiguous way) how it's to be handled. No
changes in behavior.

Signed-off-by: Halil Pasic 
---
 hw/s390x/css.c | 18 +-
 include/hw/s390x/css.h |  2 +-
 target/s390x/ioinst.c  | 23 ---
 3 files changed, 10 insertions(+), 33 deletions(-)

diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index 6da3e4ea61..98d0a6123b 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -1168,28 +1168,24 @@ static void copy_schib_from_guest(SCHIB *dest, const 
SCHIB *src)
 }
 }
 
-int css_do_msch(SubchDev *sch, const SCHIB *orig_schib)
+IOInstEnding css_do_msch(SubchDev *sch, const SCHIB *orig_schib)
 {
 SCSW *s = >curr_status.scsw;
 PMCW *p = >curr_status.pmcw;
 uint16_t oldflags;
-int ret;
 SCHIB schib;
 
 if (!(sch->curr_status.pmcw.flags & PMCW_FLAGS_MASK_DNV)) {
-ret = 0;
-goto out;
+return (IOInstEnding){.cc = 0};
 }
 
 if (s->ctrl & SCSW_STCTL_STATUS_PEND) {
-ret = -EINPROGRESS;
-goto out;
+return (IOInstEnding){.cc = 1};
 }
 
 if (s->ctrl &
 (SCSW_FCTL_START_FUNC|SCSW_FCTL_HALT_FUNC|SCSW_FCTL_CLEAR_FUNC)) {
-ret = -EBUSY;
-goto out;
+return (IOInstEnding){.cc = 1};
 }
 
 copy_schib_from_guest(, orig_schib);
@@ -1216,11 +1212,7 @@ int css_do_msch(SubchDev *sch, const SCHIB *orig_schib)
 && (p->flags & PMCW_FLAGS_MASK_ENA) == 0) {
 sch->disable_cb(sch);
 }
-
-ret = 0;
-
-out:
-return ret;
+return (IOInstEnding){.cc = 0};
 }
 
 IOInstEnding css_do_xsch(SubchDev *sch)
diff --git a/include/hw/s390x/css.h b/include/hw/s390x/css.h
index a4064711e2..e3685e73d9 100644
--- a/include/hw/s390x/css.h
+++ b/include/hw/s390x/css.h
@@ -211,7 +211,7 @@ void css_conditional_io_interrupt(SubchDev *sch);
 
 int css_do_stsch(SubchDev *sch, SCHIB *schib);
 bool css_schid_final(int m, uint8_t cssid, uint8_t ssid, uint16_t schid);
-int css_do_msch(SubchDev *sch, const SCHIB *schib);
+IOInstEnding css_do_msch(SubchDev *sch, const SCHIB *schib);
 IOInstEnding css_do_xsch(SubchDev *sch);
 IOInstEnding css_do_csch(SubchDev *sch);
 IOInstEnding css_do_hsch(SubchDev *sch);
diff --git a/target/s390x/ioinst.c b/target/s390x/ioinst.c
index 12102bab0f..0c256baa70 100644
--- a/target/s390x/ioinst.c
+++ b/target/s390x/ioinst.c
@@ -111,8 +111,6 @@ void ioinst_handle_msch(S390CPU *cpu, uint64_t reg1, 
uint32_t ipb)
 SubchDev *sch;
 SCHIB schib;
 uint64_t addr;
-int ret = -ENODEV;
-int cc;
 CPUS390XState *env = >env;
 uint8_t ar;
 
@@ -131,24 +129,11 @@ void ioinst_handle_msch(S390CPU *cpu, uint64_t reg1, 
uint32_t ipb)
 }
 trace_ioinst_sch_id("msch", cssid, ssid, schid);
 sch = css_find_subch(m, cssid, ssid, schid);
-if (sch && css_subch_visible(sch)) {
-ret = css_do_msch(sch, );
-}
-switch (ret) {
-case -ENODEV:
-cc = 3;
-break;
-case -EBUSY:
-cc = 2;
-break;
-case 0:
-cc = 0;
-break;
-default:
-cc = 1;
-break;
+if (!sch || !css_subch_visible(sch)) {
+setcc(cpu, 3);
+return;
 }
-setcc(cpu, cc);
+setcc(cpu, css_do_msch(sch, ).cc);
 }
 
 static void copy_orb_from_guest(ORB *dest, const ORB *src)
-- 
2.13.5

Re: [Qemu-devel] [PATCH] hw/s390x/sclp: Mark the sclp device with user_creatable = false

[Cornelia Huck]

On Wed, 4 Oct 2017 17:18:57 +0200
Pierre Morel  wrote:

> On 04/10/2017 15:53, Thomas Huth wrote:
> > The "sclp" device is just an internal device that can not be instantiated
> > by the users. If they try to use it, they only get a simple error message:
> > 
> > $ qemu-system-s390x -nographic -device sclp
> > qemu-system-s390x: Option '-device s390-sclp-event-facility' cannot be
> > handled by this machine
> > 
> > Since sclp_init() tries to create a TYPE_SCLP_EVENT_FACILITY which is
> > a non-pluggable sysbus device, there is really no way that the "sclp"
> > device can be used by the user, so let's set the user_creatable = false
> > accordingly.
> > 
> > Signed-off-by: Thomas Huth 
> > ---
> >   hw/s390x/sclp.c | 5 +
> >   1 file changed, 5 insertions(+)
> > 
> > diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
> > index 30aefbf..9be0cb8 100644
> > --- a/hw/s390x/sclp.c
> > +++ b/hw/s390x/sclp.c
> > @@ -606,6 +606,11 @@ static void sclp_class_init(ObjectClass *oc, void 
> > *data)
> >   dc->realize = sclp_realize;
> >   dc->hotpluggable = false;
> >   set_bit(DEVICE_CATEGORY_MISC, dc->categories);
> > +/*
> > + * Reason: Creates TYPE_SCLP_EVENT_FACILITY in sclp_init
> > + * which is a non-pluggable sysbus device
> > + */
> > +dc->user_creatable = false;
> > 
> >   sc->read_SCP_info = read_SCP_info;
> >   sc->read_storage_element0_info = read_storage_element0_info;
> >   
> 
> I must miss something.
> Why is the sclp device not a SYS_BUS_DEVICE ?
> The problem seems to come from the heterogeneity of the sclp and sclp 
> generated devices.
> 

I think the problem is 'not pluggable' rather than whether it is or
is not a sysbus device, no?

[Qemu-devel] [PATCH v2 8/8] s390x: factor out common ioinst handler logic

[Halil Pasic]

Some of ioinst the handlers look very much the same: they basically
delegate the work to the appropriate css function (doing some always the
same stuff before and after the call to the appropriate css function).
Let us create a template and get rid of some code.

Signed-off-by: Halil Pasic 
Suggested-by: Marc Hartmayer 
---
 target/s390x/ioinst.c | 59 ---
 1 file changed, 14 insertions(+), 45 deletions(-)

diff --git a/target/s390x/ioinst.c b/target/s390x/ioinst.c
index 0c256baa70..9c7d6a222c 100644
--- a/target/s390x/ioinst.c
+++ b/target/s390x/ioinst.c
@@ -38,7 +38,10 @@ int ioinst_disassemble_sch_ident(uint32_t value, int *m, int 
*cssid, int *ssid,
 return 0;
 }
 
-void ioinst_handle_xsch(S390CPU *cpu, uint64_t reg1)
+/* many ionst handlers look the same: they just delegate to a some css func */
+static void ioinst_handler_template_sch(S390CPU *cpu, uint64_t reg1,
+  const char *iname,
+  IOInstEnding (*handler_css)(SubchDev *))
 {
 int cssid, ssid, schid, m;
 SubchDev *sch;
@@ -47,49 +50,28 @@ void ioinst_handle_xsch(S390CPU *cpu, uint64_t reg1)
 program_interrupt(>env, PGM_OPERAND, 4);
 return;
 }
-trace_ioinst_sch_id("xsch", cssid, ssid, schid);
+trace_ioinst_sch_id(iname, cssid, ssid, schid);
 sch = css_find_subch(m, cssid, ssid, schid);
 if (!sch || !css_subch_visible(sch)) {
 setcc(cpu, 3);
 return;
 }
-setcc(cpu, css_do_xsch(sch).cc);
+setcc(cpu, handler_css(sch).cc);
 }
 
-void ioinst_handle_csch(S390CPU *cpu, uint64_t reg1)
+void ioinst_handle_xsch(S390CPU *cpu, uint64_t reg1)
 {
-int cssid, ssid, schid, m;
-SubchDev *sch;
+ioinst_handler_template_sch(cpu, reg1, "xsch", css_do_xsch);
+}
 
-if (ioinst_disassemble_sch_ident(reg1, , , , )) {
-program_interrupt(>env, PGM_OPERAND, 4);
-return;
-}
-trace_ioinst_sch_id("csch", cssid, ssid, schid);
-sch = css_find_subch(m, cssid, ssid, schid);
-if (!sch || !css_subch_visible(sch)) {
-setcc(cpu, 3);
-return;
-}
-setcc(cpu, css_do_csch(sch).cc);
+void ioinst_handle_csch(S390CPU *cpu, uint64_t reg1)
+{
+ioinst_handler_template_sch(cpu, reg1, "csch", css_do_csch);
 }
 
 void ioinst_handle_hsch(S390CPU *cpu, uint64_t reg1)
 {
-int cssid, ssid, schid, m;
-SubchDev *sch;
-
-if (ioinst_disassemble_sch_ident(reg1, , , , )) {
-program_interrupt(>env, PGM_OPERAND, 4);
-return;
-}
-trace_ioinst_sch_id("hsch", cssid, ssid, schid);
-sch = css_find_subch(m, cssid, ssid, schid);
-if (!sch || !css_subch_visible(sch)) {
-setcc(cpu, 3);
-return;
-}
-setcc(cpu, css_do_hsch(sch).cc);
+ioinst_handler_template_sch(cpu, reg1, "hsch", css_do_hsch);
 }
 
 static int ioinst_schib_valid(SCHIB *schib)
@@ -707,20 +689,7 @@ void ioinst_handle_schm(S390CPU *cpu, uint64_t reg1, 
uint64_t reg2,
 
 void ioinst_handle_rsch(S390CPU *cpu, uint64_t reg1)
 {
-int cssid, ssid, schid, m;
-SubchDev *sch;
-
-if (ioinst_disassemble_sch_ident(reg1, , , , )) {
-program_interrupt(>env, PGM_OPERAND, 4);
-return;
-}
-trace_ioinst_sch_id("rsch", cssid, ssid, schid);
-sch = css_find_subch(m, cssid, ssid, schid);
-if (!sch || !css_subch_visible(sch)) {
-setcc(cpu, 3);
-return;
-}
-setcc(cpu, css_do_rsch(sch).cc);
+   ioinst_handler_template_sch(cpu, reg1, "rsch", css_do_rsch);
 }
 
 #define RCHP_REG1_RES(_reg) (_reg & 0xff00ff00)
-- 
2.13.5

[Qemu-devel] [PATCH v2 5/8] s390x: refactor error handling for CSCH handler

[Halil Pasic]

Simplify the error handling of the cSCH.  Let the code detecting the
condition tell (in a less ambiguous way) how it's to be handled. No
changes in behavior.

Signed-off-by: Halil Pasic 
---
 hw/s390x/css.c | 12 +++-
 include/hw/s390x/css.h |  2 +-
 target/s390x/ioinst.c  | 14 --
 3 files changed, 8 insertions(+), 20 deletions(-)

diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index 175624d1c8..1839f40408 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -1256,26 +1256,20 @@ IOInstEnding css_do_xsch(SubchDev *sch)
 return (IOInstEnding){.cc = 0};
 }
 
-int css_do_csch(SubchDev *sch)
+IOInstEnding css_do_csch(SubchDev *sch)
 {
 SCSW *s = >curr_status.scsw;
 PMCW *p = >curr_status.pmcw;
-int ret;
 
 if (~(p->flags) & (PMCW_FLAGS_MASK_DNV | PMCW_FLAGS_MASK_ENA)) {
-ret = -ENODEV;
-goto out;
+return (IOInstEnding){.cc = 3};
 }
 
 /* Trigger the clear function. */
 s->ctrl &= ~(SCSW_CTRL_MASK_FCTL | SCSW_CTRL_MASK_ACTL);
 s->ctrl |= SCSW_FCTL_CLEAR_FUNC | SCSW_ACTL_CLEAR_PEND;
 
-do_subchannel_work(sch);
-ret = 0;
-
-out:
-return ret;
+return do_subchannel_work(sch);
 }
 
 int css_do_hsch(SubchDev *sch)
diff --git a/include/hw/s390x/css.h b/include/hw/s390x/css.h
index 4c89d77893..6ca077 100644
--- a/include/hw/s390x/css.h
+++ b/include/hw/s390x/css.h
@@ -213,7 +213,7 @@ int css_do_stsch(SubchDev *sch, SCHIB *schib);
 bool css_schid_final(int m, uint8_t cssid, uint8_t ssid, uint16_t schid);
 int css_do_msch(SubchDev *sch, const SCHIB *schib);
 IOInstEnding css_do_xsch(SubchDev *sch);
-int css_do_csch(SubchDev *sch);
+IOInstEnding css_do_csch(SubchDev *sch);
 int css_do_hsch(SubchDev *sch);
 IOInstEnding css_do_ssch(SubchDev *sch, ORB *orb);
 int css_do_tsch_get_irb(SubchDev *sch, IRB *irb, int *irb_len);
diff --git a/target/s390x/ioinst.c b/target/s390x/ioinst.c
index 85f5be6ca3..b12b3d1d41 100644
--- a/target/s390x/ioinst.c
+++ b/target/s390x/ioinst.c
@@ -60,8 +60,6 @@ void ioinst_handle_csch(S390CPU *cpu, uint64_t reg1)
 {
 int cssid, ssid, schid, m;
 SubchDev *sch;
-int ret = -ENODEV;
-int cc;
 
 if (ioinst_disassemble_sch_ident(reg1, , , , )) {
 program_interrupt(>env, PGM_OPERAND, 4);
@@ -69,15 +67,11 @@ void ioinst_handle_csch(S390CPU *cpu, uint64_t reg1)
 }
 trace_ioinst_sch_id("csch", cssid, ssid, schid);
 sch = css_find_subch(m, cssid, ssid, schid);
-if (sch && css_subch_visible(sch)) {
-ret = css_do_csch(sch);
-}
-if (ret == -ENODEV) {
-cc = 3;
-} else {
-cc = 0;
+if (!sch || !css_subch_visible(sch)) {
+setcc(cpu, 3);
+return;
 }
-setcc(cpu, cc);
+setcc(cpu, css_do_csch(sch).cc);
 }
 
 void ioinst_handle_hsch(S390CPU *cpu, uint64_t reg1)
-- 
2.13.5

[Qemu-devel] [PATCH v2 1/8] s390x/css: be more consistent if broken beyond repair

[Halil Pasic]

Calling do_subchannel_work with no function control flags set in SCSW is
a programming error. Currently the handle this differently in
do_subchannel_work_virtual and do_subchannel_work_passthrough. Let's be
consistent and guard with a common assert against this programming error.

Signed-off-by: Halil Pasic 
---
 hw/s390x/css.c | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index c59be1aad1..4f47dbc8b0 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -1067,9 +1067,6 @@ int do_subchannel_work_virtual(SubchDev *sch)
 } else if (s->ctrl & SCSW_FCTL_START_FUNC) {
 /* Triggered by both ssch and rsch. */
 sch_handle_start_func_virtual(sch);
-} else {
-/* Cannot happen. */
-return 0;
 }
 css_inject_io_interrupt(sch);
 return 0;
@@ -1077,22 +1074,17 @@ int do_subchannel_work_virtual(SubchDev *sch)
 
 int do_subchannel_work_passthrough(SubchDev *sch)
 {
-int ret;
+int ret = 0;
 SCSW *s = >curr_status.scsw;
 
 if (s->ctrl & SCSW_FCTL_CLEAR_FUNC) {
 /* TODO: Clear handling */
 sch_handle_clear_func(sch);
-ret = 0;
 } else if (s->ctrl & SCSW_FCTL_HALT_FUNC) {
 /* TODO: Halt handling */
 sch_handle_halt_func(sch);
-ret = 0;
 } else if (s->ctrl & SCSW_FCTL_START_FUNC) {
 ret = sch_handle_start_func_passthrough(sch);
-} else {
-/* Cannot happen. */
-return -ENODEV;
 }
 
 return ret;
@@ -1100,11 +1092,11 @@ int do_subchannel_work_passthrough(SubchDev *sch)
 
 static int do_subchannel_work(SubchDev *sch)
 {
-if (sch->do_subchannel_work) {
-return sch->do_subchannel_work(sch);
-} else {
+if (!sch->do_subchannel_work) {
 return -EINVAL;
 }
+g_assert(sch->curr_status.scsw.ctrl & SCSW_CTRL_MASK_FCTL);
+return sch->do_subchannel_work(sch);
 }
 
 static void copy_pmcw_to_guest(PMCW *dest, const PMCW *src)
-- 
2.13.5

[Qemu-devel] [PATCH v2 0/8] improve error handling for IO instr

[Halil Pasic]

This is the v2 of my infamous nameless series (archive link:
https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg06076.html).

Abstract
===

The basic idea is: tell how to handle an unusual condition where it's
identified, instead of mapping it to an errno (more or less arbitrarily),
then possibly mapping these errnos around, to finally (mentally) map the
errno back to the condition and take appropriate action.

According to Dong Jia the patch-set also has a functional value: for ccw
pass-through, he is planing to pass-through the instruction completion
information (cc or interruption condition) from the kernel, and this
patch set can pretty much be seen as a preparation for that.

Changelog
=

There was a fair amount of discussion regarding during the review of v1.
For certain issues we have decided to address them differently (e.g. use
unit-exception for VFIO if extra constraints are not respected, get rid
of the addressing check, assert if do_subchannel_work called without
improperly) and for some we decided to not address them for now (e.g.
use if callbacks are null).

Although this was not part of the v1 discussion, I have also decided to
go back to return values (opposed to adding new state to SubchDev). There
are multiple reasons for doing so: 
* Most of, but not all IO instructions
operate on a subchannel, thus having the instruction ending control in
SubchDev is a bit weird. 
* Get both the compiler and the good habits on ours side (e.g. non-void
control reaches end of non-void function warning (-Wreturn-type), no
overwrites possible, instead of having to check a certain member of a
certain struct after a function call just don't ignore return values).

v1 -> v2:
* use assert if do_subchannel_work without any functions being
  accepted 
* generate unit-exception if ccw-vfio can't handle an otherwise
  good channel program (due to extra limitations) 
* keep using return values opposed to recording into SubchDev
* split out 'add infrastructure' from 'refactor first handler'
* reworded some commit messanges and comments
* rebased on top of current master
* dropped r-b's and acks because of the magnitude of the
  changes

Testing
===

Regarding vfio-ccw Dong Jia did some quick testing with an equivalent
version. Regarding virtual ccw I did only some rudimentary testing.
Should the series be deemed promising more testing would make
sense.

Halil Pasic (8):
  s390x/css: be more consistent if broken beyond repair
  s390x/css: IO instr handler ending control
  s390x: improve error handling for SSCH and RSCH
  s390x: refactor error handling for XSCH handler
  s390x: refactor error handling for CSCH handler
  s390x: refactor error handling for HSCH handler
  s390x: refactor error handling for MSCH handler
  s390x: factor out common ioinst handler logic

 hw/s390x/css.c  | 162 --
 hw/s390x/s390-ccw.c |  11 ++-
 hw/vfio/ccw.c   |  30 ++--
 include/hw/s390x/css.h  |  44 +---
 include/hw/s390x/s390-ccw.h |   2 +-
 target/s390x/ioinst.c   | 169 +++-
 6 files changed, 131 insertions(+), 287 deletions(-)

-- 
2.13.5