Re: [Qemu-devel] [RFC v2 3/3] intel_iommu: add scalable-mode option to make scalable mode work

2019-02-28 Thread Yi Sun
On 19-03-01 15:04:14, Peter Xu wrote:

[...]

> > @@ -3540,6 +3555,15 @@ static void vtd_init(IntelIOMMUState *s)
> >  s->cap |= VTD_CAP_CM;
> >  }
> >  
> > +/* TODO: read cap/ecap from host to decide which cap to be exposed. */
> > +if (s->scalable_mode) {
> > +if (!s->dma_drain) {
> > +error_report("Need to set dma_drain for scalable mode");
> > +exit(1);
> > +}
> 
> This patch looks mostly good to me, only that can we move this check
> to vtd_decide_config()?  That's where most similar checks are done.
>
I think that is fine. Thanks!



Re: [Qemu-devel] [RFC v2 1/3] intel_iommu: scalable mode emulation

2019-02-28 Thread Yi Sun
On 19-03-01 14:52:19, Peter Xu wrote:
> On Thu, Feb 28, 2019 at 09:47:55PM +0800, Yi Sun wrote:
> > From: "Liu, Yi L" 
> > 
> > Intel(R) VT-d 3.0 spec introduces scalable mode address translation to
> > replace extended context mode. This patch extends current emulator to
> > support Scalable Mode which includes root table, context table and new
> > pasid table format change. Now intel_iommu emulates both legacy mode
> > and scalable mode (with legacy-equivalent capability set).
> > 
> > The key points are below:
> > 1. Extend root table operations to support both legacy mode and scalable
> >mode.
> > 2. Extend context table operations to support both legacy mode and
> >scalable mode.
> > 3. Add pasid tabled operations to support scalable mode.
> > 
> > Signed-off-by: Liu, Yi L 
> > [Yi Sun is co-developer to contribute much to refine the whole commit.]
> > Signed-off-by: Yi Sun 
> 
> Hi, Yi,
> 
> The Patch looks very good to me already, though I still have some
> trivial comments below.
> 
Thanks for the review!

> [...]
> 
> > -static inline bool vtd_ce_present(VTDContextEntry *context)
> > +static inline bool vtd_ce_present(VTDContextEntry *ce)
> >  {
> > -return context->lo & VTD_CONTEXT_ENTRY_P;
> > +return ce->lo & VTD_CONTEXT_ENTRY_P;
> 
> The renaming seems not needed.
> 
Ok.

> >  }
> >  
> > -static int vtd_get_context_entry_from_root(VTDRootEntry *root, uint8_t 
> > index,
> > +static int vtd_get_context_entry_from_root(IntelIOMMUState *s,
> > +   VTDRootEntry *re,
> > +   uint8_t index,
> > VTDContextEntry *ce)
> >  {
> > -dma_addr_t addr;
> > +dma_addr_t addr, ce_size;
> >  
> >  /* we have checked that root entry is present */
> > -addr = (root->val & VTD_ROOT_ENTRY_CTP) + index * sizeof(*ce);
> > -if (dma_memory_read(_space_memory, addr, ce, sizeof(*ce))) {
> > +ce_size = s->root_scalable ? VTD_CTX_ENTRY_SCALABLE_SIZE :
> > +  VTD_CTX_ENTRY_LEGACY_SIZE;
> > +
> > +if (s->root_scalable && index > UINT8_MAX / 2) {
> > +index = index & (~VTD_DEVFN_CHECK_MASK);
> > +addr = re->hi & VTD_ROOT_ENTRY_CTP;
> > +} else {
> > +addr = re->lo & VTD_ROOT_ENTRY_CTP;
> > +}
> > +
> > +addr = addr + index * ce_size;
> > +if (dma_memory_read(_space_memory, addr, ce, ce_size)) {
> >  return -VTD_FR_CONTEXT_TABLE_INV;
> >  }
> > +
> >  ce->lo = le64_to_cpu(ce->lo);
> >  ce->hi = le64_to_cpu(ce->hi);
> > +if (s->root_scalable) {
> 
> (or use ce_size which might be more obvious)
> 
Ok, thanks.

> > +ce->val[2] = le64_to_cpu(ce->val[2]);
> > +ce->val[3] = le64_to_cpu(ce->val[3]);
> > +}
> >  return 0;
> >  }
> 
> [...]
> 
> > +static inline int vtd_ce_get_rid2pasid_entry(IntelIOMMUState *s,
> > + VTDContextEntry *ce,
> > + VTDPASIDEntry *pe)
> > +{
> > +uint32_t pasid;
> > +dma_addr_t pasid_dir_base;
> > +int ret = 0;
> > +
> > +pasid = VTD_CE_GET_RID2PASID(ce);
> > +pasid_dir_base = VTD_CE_GET_PASID_DIR_TABLE(ce);
> > +ret = vtd_get_pasid_entry_from_pasid(s, pasid_dir_base, pasid, pe);
> > +
> > +return ret;
> > +}
> > +
> > +static inline int vtd_ce_get_pasid_fpd(IntelIOMMUState *s,
> > +   VTDContextEntry *ce,
> > +   bool *pe_fpd_set)
> 
> Many functions are defined as inlined (even some functions that may
> not be that short IMHO) and many of them are not.  Could you share how
> you decide which function should be inlined?
> 
Sorry for that. It is caused by some historical reasons and I forgot
to refine them. I will go through the codes and remove unnecessary
'inline'.

For me, the function with simple flow (a few codes, without complex
calling stack, without circle) should be declared as 'inline' to
improve performance. 

> [...]
> 
> >  static inline bool vtd_ce_type_check(X86IOMMUState *x86_iommu,
> >   VTDContextEntry *ce)
> >  {
> > +IntelIOMMUState *s = INTEL_IOMMU_DEVICE(x86_iommu);
> > +
> > +if (s->root_scalable) {
> > +/*
> > + * Translation Type locates in context entry only when VTD is in
> > + * legacy mode. For scalable mode, need to return true to avoid
> > + * unnecessary fault.
> > + */
> > +return true;
> > +}
> 
> Do you think we can move this check directly into caller of
> vtd_ce_type_check() which is vtd_dev_to_context_entry()?  Then:
> 
>   if (scalable_mode)
> vtd_ce_rid2pasid_check()
>   else
> vtd_ce_type_check()
> 
> You can comment on function vtd_ce_type_check() that this only checks
> legacy context entries, since calling vtd_ce_type_check() upon an
> scalable mode context entry does not make much sense itself already.
> 
A good 

Re: [Qemu-devel] [RFC v2 2/3] intel_iommu: add 256 bits qi_desc support

2019-02-28 Thread Yi Sun
On 19-03-01 14:59:00, Peter Xu wrote:
> On Thu, Feb 28, 2019 at 09:47:56PM +0800, Yi Sun wrote:
> > From: "Liu, Yi L" 
> > 
> > Per Intel(R) VT-d 3.0, the qi_desc is 256 bits in Scalable
> > Mode. This patch adds emulation of 256bits qi_desc.
> > 
> > Signed-off-by: Liu, Yi L 
> > [Yi Sun is co-developer to rebase and refine the patch.]
> > Signed-off-by: Yi Sun 
> 
> [...]
> 
> > @@ -2501,7 +2507,12 @@ static void vtd_handle_iqt_write(IntelIOMMUState *s)
> >  {
> >  uint64_t val = vtd_get_quad_raw(s, DMAR_IQT_REG);
> >  
> > -s->iq_tail = VTD_IQT_QT(val);
> > +if (s->iq_dw && val & VTD_IQT_QT_256_RSV_BIT) {
> 
> Nit: Let's do (val & VTD_IQT_QT_256_RSV_BIT) to be clear.  With that:
> 
Sure. Thanks!

> Reviewed-by: Peter Xu 
> 
> Regards,
> 
> -- 
> Peter Xu



[Qemu-devel] [PATCH] qom: remove type_initialize() in object_new_with_type()

2019-02-28 Thread Wei Yang
Here is the abstraction of current call flow of object_new_with_type()

object_initialize_with_type
type_initialize
object_initialize_with_type
type_initialize

This is not necessary to spread type_initialize in two places.

Signed-off-by: Wei Yang 
---
 qom/object.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/qom/object.c b/qom/object.c
index b8c732063b..6252cca418 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -585,7 +585,6 @@ static Object *object_new_with_type(Type type)
 Object *obj;
 
 g_assert(type != NULL);
-type_initialize(type);
 
 obj = g_malloc(type->instance_size);
 object_initialize_with_type(obj, type->instance_size, type);
-- 
2.19.1




Re: [Qemu-devel] [PATCH v2 08/16] tests/tcg/arm: add ARMv6-M UNDEFINED 32-bit instruction test

2019-02-28 Thread Alex Bennée


Philippe Mathieu-Daudé  writes:

> On 2/28/19 9:25 PM, Alex Bennée wrote:
>> From: Stefan Hajnoczi 
>>
>> Test that 32-bit instructions declared UNDEFINED in the ARMv6-M
>> Reference Manual really do raise an exception.  Also test that the 6
>> 32-bit instructions defined in the ARMv6-M Reference Manual do not raise
>> an exception.
>>
>> Based-on: <20181029194519.15628-1-stefa...@redhat.com>
>
> ^ cut 'Based-on' from git history?

Yeah - we really only need the Message ID.

>
>> Signed-off-by: Stefan Hajnoczi 
>> Message-Id: <20181129185113.30353-1-stefa...@redhat.com>
>> [AJB: integrated into system tests]
>> Signed-off-by: Alex Bennée 
>>
>> ---
>> v2
>>   - added to series
>>   - used softmmu-target Makefile with single compile/link step
>>   - launches with -kernel
>>   - drop .hex file
>> ---
>>  tests/tcg/arm/Makefile.softmmu-target |  29 +
>>  tests/tcg/arm/test-armv6m-undef.S | 154 ++
>>  tests/tcg/arm/test-armv6m-undef.ld|  21 
>>  3 files changed, 204 insertions(+)
>>  create mode 100644 tests/tcg/arm/Makefile.softmmu-target
>>  create mode 100644 tests/tcg/arm/test-armv6m-undef.S
>>  create mode 100644 tests/tcg/arm/test-armv6m-undef.ld
>>
>> diff --git a/tests/tcg/arm/Makefile.softmmu-target 
>> b/tests/tcg/arm/Makefile.softmmu-target
>> new file mode 100644
>> index 00..49d48d8a1c
>> --- /dev/null
>> +++ b/tests/tcg/arm/Makefile.softmmu-target
>> @@ -0,0 +1,29 @@
>> +# -*- Mode: makefile -*-
>> +#
>> +# ARM SoftMMU tests - included from tests/tcg/Makefile
>> +#
>> +
>> +ifeq ($(TARGET_ABI_DIR),arm)
>> +
>> +ARM_SRC=$(SRC_PATH)/tests/tcg/arm
>> +
>> +# Set search path for all sources
>> +VPATH   += $(ARM_SRC)
>> +
>> +ARM_TESTS=test-armv6m-undef
>> +
>> +TESTS += $(ARM_TESTS)
>> +
>> +CFLAGS+=-Wl,--build-id=none -x assembler-with-cpp
>> +LDFLAGS+=-nostdlib -N -static
>> +
>> +%: %.S %.ld
>> +$(CC) $(CFLAGS) $(ASFLAGS) $< -o $@ $(LDFLAGS) -T $(ARM_SRC)/$@.ld
>> +
>> +# Specific Test Rules
>> +
>> +test-armv6m-undef: EXTRA_CFLAGS+=-mcpu=cortex-m0
>> +
>> +run-test-armv6m-undef: QEMU_OPTS+=-semihosting -M microbit -kernel
>> +
>> +endif
>> diff --git a/tests/tcg/arm/test-armv6m-undef.S 
>> b/tests/tcg/arm/test-armv6m-undef.S
>> new file mode 100644
>> index 00..d18ca56b4a
>> --- /dev/null
>> +++ b/tests/tcg/arm/test-armv6m-undef.S
>> @@ -0,0 +1,154 @@
>> +/*
>> + * Test ARMv6-M UNDEFINED 32-bit instructions
>> + *
>> + * Copyright 2018 Red Hat Inc.
>> + *
>> + * This work is licensed under the terms of the GNU GPL, version 2
>> + * or later. See the COPYING file in the top-level directory.
>> + */
>> +
>> +/*
>> + * Test that UNDEFINED 32-bit instructions fault as expected.  This is an
>> + * interesting test because ARMv6-M shares code with its more fully-featured
>> + * siblings and it's necessary to verify that its limited instruction set is
>> + * emulated correctly.
>> + *
>> + * The emulator must be invoked with -semihosting so that the test case can
>> + * terminate with exit code 0 on success or 1 on failure.
>> + *
>> + * Failures can be debugged with -d in_asm,int,exec,cpu and the
>> + * gdbstub (-S -s).
>> + */
>> +
>> +.syntax unified
>> +.cpu cortex-m0
>> +.thumb
>> +
>> +/*
>> + * Memory map
>> + */
>> +#define SRAM_BASE 0x2000
>> +#define SRAM_SIZE (16 * 1024)
>> +
>> +/*
>> + * Semihosting interface on ARM T32
>> + * See "Semihosting for AArch32 and AArch64 Version 2.0 Documentation" by 
>> ARM
>> + */
>> +#define semihosting_call bkpt 0xab
>> +#define SYS_EXIT 0x18
>> +
>> +vector_table:
>> +.word SRAM_BASE + SRAM_SIZE /* 0. SP_main */
>> +.word exc_reset_thumb   /* 1. Reset */
>> +.word 0 /* 2. NMI */
>> +.word exc_hard_fault_thumb  /* 3. HardFault */
>> +.rept 7
>> +.word 0 /* 4-10. Reserved */
>> +.endr
>> +.word 0 /* 11. SVCall */
>> +.word 0 /* 12. Reserved */
>> +.word 0 /* 13. Reserved */
>> +.word 0 /* 14. PendSV */
>> +.word 0 /* 15. SysTick */
>> +.rept 32
>> +.word 0 /* 16-47. External Interrupts */
>> +.endr
>> +
>> +exc_reset:
>> +.equ exc_reset_thumb, exc_reset + 1
>> +.global exc_reset_thumb
>> +/* The following 32-bit UNDEFINED instructions are tested by executing
>> + * them.  The HardFault exception handler should execute and return to
>> + * the next test case.  If no exception is raised the test fails.
>> + */
>> +
>> +/* Table A5-9 32-bit Thumb encoding */
>> +.short 0b11101000
>> +.short 0b
>> +b not_reached
>> +.short 0b11101000
>> +.short 0b1000
>> +b not_reached
>> +.short 0b1000
>> +.short 0b
>> +b not_reached
>> +.short 0b1000
>> +.short 0b1000
>> +b not_reached
>> +.short 0b

Re: [Qemu-devel] [RFC v2 0/3] intel_iommu: support scalable mode

2019-02-28 Thread Tian, Kevin
> From: Yi Sun [mailto:yi.y@linux.intel.com]
> Sent: Friday, March 1, 2019 3:13 PM
> 
> On 19-03-01 15:07:34, Peter Xu wrote:
> > On Thu, Feb 28, 2019 at 09:47:54PM +0800, Yi Sun wrote:
> > > Intel vt-d rev3.0 [1] introduces a new translation mode called
> > > 'scalable mode', which enables PASID-granular translations for
> > > first level, second level, nested and pass-through modes. The
> > > vt-d scalable mode is the key ingredient to enable Scalable I/O
> > > Virtualization (Scalable IOV) [2] [3], which allows sharing a
> > > device in minimal possible granularity (ADI - Assignable Device
> > > Interface). As a result, previous Extended Context (ECS) mode
> > > is deprecated (no production ever implements ECS).
> > >
> > > This patch set emulates a minimal capability set of VT-d scalable
> > > mode, equivalent to what is available in VT-d legacy mode today:
> > > 1. Scalable mode root entry, context entry and PASID table
> > > 2. Seconds level translation under scalable mode
> > > 3. Queued invalidation (with 256 bits descriptor)
> > > 4. Pass-through mode
> > >
> > > Corresponding intel-iommu driver support will be included in
> > > kernel 5.0:
> > > https://www.spinics.net/lists/kernel/msg2985279.html
> > >
> > > We will add emulation of full scalable mode capability along with
> > > guest iommu driver progress later, e.g.:
> > > 1. First level translation
> > > 2. Nested translation
> > > 3. Per-PASID invalidation descriptors
> > > 4. Page request services for handling recoverable faults
> > >
> > > To verify the patches, below cases were tested according to Peter Xu's
> > > suggestions.
> > > 
> > > +-++---
> -+
> > > | |  w/ Device Passthr
> > >  | w/o Device
> Passthr |
> > > | 
> > > +---++-
> --++
> > > | | virtio-net-pci, vhost=on  | virtio-net-pci, vhost=off 
> > >  | virtio-
> net-pci, vhost=on  | virtio-net-pci, vhost=off  |
> > > | 
> > > +---++-
> --++
> > > | | netperf | kernel bld | data cp| netperf | kernel bld | 
> > > data cp |
> netperf | kernel bld | data cp| netperf | kernel bld | data cp |
> > > 
> > > +-+---++--
> -++
> > > | Legacy  | Pass| Pass   | Pass   | Pass| Pass   | 
> > > Pass| Pass|
> Pass   | Pass   | Pass| Pass   | Pass|
> > > 
> > > +-+---++--
> -++
> > > | Scalable| Pass| Pass   | Pass   | Pass| Pass   | 
> > > Pass| Pass|
> Pass   | Pass   | Pass| Pass   | Pass|
> > > 
> > > +-+---++--
> -++
> >
> > Hi, Yi,
> >
> > Thanks very much for the thorough test matrix!
> >
> Thanks for the review and comments! :)
> 
> > The last thing I'd like to confirm is have you tested device
> > assignment with v2?  And note that when you test with virtio devices
> 
> Yes, I tested a MDEV assignment which can walk the Scalable Mode
> patches flows (both kernel and qemu).

not just MDEV. You should also try physical PCI endpoint device.

> 
> > you should not need caching-mode=on (but caching-mode=on should not
> > break anyone though).
> >
> For virtio-net-pci without device assignment, I did not use
> "caching-mode=on".
> 
> > I've still got some comments here and there but it looks very good at
> > least to me overall.
> >
> > Thanks,
> >
> > --
> > Peter Xu


Re: [Qemu-devel] [PATCH v2 07/16] tests/tcg/xtensa: enable system tests

2019-02-28 Thread Alex Bennée


Max Filippov  writes:

> Hi Alex,
>
> On Thu, Feb 28, 2019 at 12:25 PM Alex Bennée  wrote:
>
> [...]
>
>> diff --git a/tests/tcg/xtensa/Makefile.softmmu-target 
>> b/tests/tcg/xtensa/Makefile.softmmu-target
>> new file mode 100644
>> index 00..1a4014506f
>> --- /dev/null
>> +++ b/tests/tcg/xtensa/Makefile.softmmu-target
>> @@ -0,0 +1,40 @@
>> +#
>> +# Xtensa softmmu tests
>> +#
>> +
>> +ifneq ($(TARGET_WORDS_BIGENDIAN),y)
>
> I've recently posted a series that makes it possible to run
> TCG tests on wider variety of xtensa cores, including
> big-endian cores:
> http://lists.nongnu.org/archive/html/qemu-devel/2019-02/msg04843.html

Ahh I missed that, will have a look.

--
Alex Bennée



Re: [Qemu-devel] [PATCH v3 4/9] {monitor, hw/pvrdma}: Expose device internals via monitor interface

2019-02-28 Thread Markus Armbruster
Marcel Apfelbaum  writes:

> Hi Yuval,
>
> On 2/27/19 4:06 PM, Yuval Shaia wrote:
>> Allow interrogating device internals through HMP interface.
>> The exposed indicators can be used for troubleshooting by developers or
>> sysadmin.
>> There is no need to expose these attributes to a management system (e.x.
>> libvirt) because (1) most of them are not "device-management' related
>> info and (2) there is no guarantee the interface is stable.
>>
>> Signed-off-by: Yuval Shaia 
>> ---
>>   hmp-commands-info.hx  | 16 
>>   hw/rdma/rdma_backend.c| 70 ++-
>>   hw/rdma/rdma_rm.c |  7 
>>   hw/rdma/rdma_rm_defs.h| 27 +-
>>   hw/rdma/vmw/pvrdma.h  |  5 +++
>>   hw/rdma/vmw/pvrdma_hmp.h  | 21 +++
>>   hw/rdma/vmw/pvrdma_main.c | 77 +++
>>   monitor.c | 10 +
>>   8 files changed, 215 insertions(+), 18 deletions(-)
>>   create mode 100644 hw/rdma/vmw/pvrdma_hmp.h
>>
>> diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
>> index cbee8b944d..9153c33974 100644
>> --- a/hmp-commands-info.hx
>> +++ b/hmp-commands-info.hx
>> @@ -524,6 +524,22 @@ STEXI
>>   Show CPU statistics.
>>   ETEXI
>>   +#if defined(CONFIG_PVRDMA)
>> +{
>> +.name   = "pvrdmacounters",
>> +.args_type  = "",
>> +.params = "",
>> +.help   = "show pvrdma device counters",
>> +.cmd= hmp_info_pvrdmacounters,
>> +},
>> +
>> +STEXI
>> +@item info pvrdmacounters
>> +@findex info pvrdmacounters
>> +Show pvrdma device counters.
>> +ETEXI
>> +#endif
>> +
>>   #if defined(CONFIG_SLIRP)
>>   {
>>   .name   = "usernet",
[...]
>> diff --git a/hw/rdma/vmw/pvrdma_main.c b/hw/rdma/vmw/pvrdma_main.c
>> index b6061f4b6e..85101368c5 100644
>> --- a/hw/rdma/vmw/pvrdma_main.c
>> +++ b/hw/rdma/vmw/pvrdma_main.c
>> @@ -14,6 +14,7 @@
>>*/
>> #include "qemu/osdep.h"
>> +#include "qemu/units.h"
>>   #include "qapi/error.h"
>>   #include "hw/hw.h"
>>   #include "hw/pci/pci.h"
>> @@ -25,6 +26,7 @@
>>   #include "cpu.h"
>>   #include "trace.h"
>>   #include "sysemu/sysemu.h"
>> +#include "monitor/monitor.h"
>> #include "../rdma_rm.h"
>>   #include "../rdma_backend.h"
>> @@ -32,10 +34,13 @@
>> #include 
>>   #include "pvrdma.h"
>> +#include "pvrdma_hmp.h"
>>   #include "standard-headers/rdma/vmw_pvrdma-abi.h"
>>   #include 
>> "standard-headers/drivers/infiniband/hw/vmw_pvrdma/pvrdma_dev_api.h"
>>   #include "pvrdma_qp_ops.h"
>>   +GSList *devices;

"devices" is far too generic for an external identifier.  Are you
missing a 'static' here?  Even if static, I'd recommend "rdma_devices".

>> +
>>   static Property pvrdma_dev_properties[] = {
>>   DEFINE_PROP_STRING("netdev", PVRDMADev, backend_eth_device_name),
>>   DEFINE_PROP_STRING("ibdev", PVRDMADev, backend_device_name),
>> @@ -55,6 +60,71 @@ static Property pvrdma_dev_properties[] = {
[...]
>> +}
>> +
>> +void pvrdma_dump_counters(Monitor *mon)
>> +{
>> +g_slist_foreach(devices, pvrdma_dump_device_counters, mon);
>> +}

Note for later: does nothing when @devices is empty.

>> +
>>   static void free_dev_ring(PCIDevice *pci_dev, PvrdmaRing *ring,
>> void *ring_state)
>>   {
>> @@ -304,6 +374,8 @@ static void pvrdma_fini(PCIDevice *pdev)
>> rdma_info_report("Device %s %x.%x is down", pdev->name,
>>PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
>> +
>> +devices = g_slist_remove(devices, pdev);
>>   }
>> static void pvrdma_stop(PVRDMADev *dev)
>> @@ -394,6 +466,7 @@ static void pvrdma_regs_write(void *opaque, hwaddr addr, 
>> uint64_t val,
>>   if (val == 0) {
>>   trace_pvrdma_regs_write(addr, val, "REQUEST", "");
>>   pvrdma_exec_cmd(dev);
>> +dev->stats.commands++;
>>   }
>>   break;
>>   default:
>> @@ -612,9 +685,13 @@ static void pvrdma_realize(PCIDevice *pdev, Error 
>> **errp)
>>   goto out;
>>   }
>>   +memset(>stats, 0, sizeof(dev->stats));
>> +
>>   dev->shutdown_notifier.notify = pvrdma_shutdown_notifier;
>>   qemu_register_shutdown_notifier(>shutdown_notifier);
>>   +devices = g_slist_append(devices, pdev);
>> +
>>   out:
>>   if (rc) {
>>   pvrdma_fini(pdev);

Note for later: @devices contains the realized "pvrdma" devices.

You could find these devices with object_child_foreach_recursive()
instead of maintaining a separate list.

>> diff --git a/monitor.c b/monitor.c
>> index defa129319..53ecb5bc70 100644
>> --- a/monitor.c
>> +++ b/monitor.c
>> @@ -85,6 +85,9 @@
>>   #include "sysemu/iothread.h"
>>   #include "qemu/cutils.h"
>>   #include "tcg/tcg.h"
>> +#ifdef CONFIG_PVRDMA
>> +#include "hw/rdma/vmw/pvrdma_hmp.h"
>> +#endif
>> #if defined(TARGET_S390X)
>>   #include "hw/s390x/storage-keys.h"
>> @@ -1362,6 +1365,13 @@ static void hmp_info_cpustats(Monitor *mon, const 
>> QDict *qdict)
>>   

Re: [Qemu-devel] [RFC v2 0/3] intel_iommu: support scalable mode

2019-02-28 Thread Yi Sun
On 19-03-01 15:07:34, Peter Xu wrote:
> On Thu, Feb 28, 2019 at 09:47:54PM +0800, Yi Sun wrote:
> > Intel vt-d rev3.0 [1] introduces a new translation mode called
> > 'scalable mode', which enables PASID-granular translations for
> > first level, second level, nested and pass-through modes. The
> > vt-d scalable mode is the key ingredient to enable Scalable I/O
> > Virtualization (Scalable IOV) [2] [3], which allows sharing a
> > device in minimal possible granularity (ADI - Assignable Device
> > Interface). As a result, previous Extended Context (ECS) mode
> > is deprecated (no production ever implements ECS).
> > 
> > This patch set emulates a minimal capability set of VT-d scalable
> > mode, equivalent to what is available in VT-d legacy mode today:
> > 1. Scalable mode root entry, context entry and PASID table
> > 2. Seconds level translation under scalable mode
> > 3. Queued invalidation (with 256 bits descriptor)
> > 4. Pass-through mode
> > 
> > Corresponding intel-iommu driver support will be included in
> > kernel 5.0:
> > https://www.spinics.net/lists/kernel/msg2985279.html
> > 
> > We will add emulation of full scalable mode capability along with
> > guest iommu driver progress later, e.g.:
> > 1. First level translation
> > 2. Nested translation
> > 3. Per-PASID invalidation descriptors
> > 4. Page request services for handling recoverable faults
> > 
> > To verify the patches, below cases were tested according to Peter Xu's
> > suggestions.
> > 
> > +-+++
> > | |  w/ Device Passthr  
> >| w/o Device Passthr |
> > | 
> > +---++---++
> > | | virtio-net-pci, vhost=on  | virtio-net-pci, vhost=off   
> >| virtio-net-pci, vhost=on  | virtio-net-pci, vhost=off  |
> > | 
> > +---++---++
> > | | netperf | kernel bld | data cp| netperf | kernel bld | data 
> > cp | netperf | kernel bld | data cp| netperf | kernel bld | data cp |
> > 
> > +-+---++---++
> > | Legacy  | Pass| Pass   | Pass   | Pass| Pass   | Pass 
> >| Pass| Pass   | Pass   | Pass| Pass   | Pass|
> > 
> > +-+---++---++
> > | Scalable| Pass| Pass   | Pass   | Pass| Pass   | Pass 
> >| Pass| Pass   | Pass   | Pass| Pass   | Pass|
> > 
> > +-+---++---++
> 
> Hi, Yi,
> 
> Thanks very much for the thorough test matrix!
> 
Thanks for the review and comments! :)

> The last thing I'd like to confirm is have you tested device
> assignment with v2?  And note that when you test with virtio devices

Yes, I tested a MDEV assignment which can walk the Scalable Mode
patches flows (both kernel and qemu).

> you should not need caching-mode=on (but caching-mode=on should not
> break anyone though).
> 
For virtio-net-pci without device assignment, I did not use
"caching-mode=on".
 
> I've still got some comments here and there but it looks very good at
> least to me overall.
> 
> Thanks,
> 
> -- 
> Peter Xu



Re: [Qemu-devel] [RFC v2 0/3] intel_iommu: support scalable mode

2019-02-28 Thread Peter Xu
On Thu, Feb 28, 2019 at 09:47:54PM +0800, Yi Sun wrote:
> Intel vt-d rev3.0 [1] introduces a new translation mode called
> 'scalable mode', which enables PASID-granular translations for
> first level, second level, nested and pass-through modes. The
> vt-d scalable mode is the key ingredient to enable Scalable I/O
> Virtualization (Scalable IOV) [2] [3], which allows sharing a
> device in minimal possible granularity (ADI - Assignable Device
> Interface). As a result, previous Extended Context (ECS) mode
> is deprecated (no production ever implements ECS).
> 
> This patch set emulates a minimal capability set of VT-d scalable
> mode, equivalent to what is available in VT-d legacy mode today:
> 1. Scalable mode root entry, context entry and PASID table
> 2. Seconds level translation under scalable mode
> 3. Queued invalidation (with 256 bits descriptor)
> 4. Pass-through mode
> 
> Corresponding intel-iommu driver support will be included in
> kernel 5.0:
> https://www.spinics.net/lists/kernel/msg2985279.html
> 
> We will add emulation of full scalable mode capability along with
> guest iommu driver progress later, e.g.:
> 1. First level translation
> 2. Nested translation
> 3. Per-PASID invalidation descriptors
> 4. Page request services for handling recoverable faults
> 
> To verify the patches, below cases were tested according to Peter Xu's
> suggestions.
> 
> +-+++
> | |  w/ Device Passthr
>  | w/o Device Passthr |
> | 
> +---++---++
> | | virtio-net-pci, vhost=on  | virtio-net-pci, vhost=off 
>  | virtio-net-pci, vhost=on  | virtio-net-pci, vhost=off  |
> | 
> +---++---++
> | | netperf | kernel bld | data cp| netperf | kernel bld | data 
> cp | netperf | kernel bld | data cp| netperf | kernel bld | data cp |
> 
> +-+---++---++
> | Legacy  | Pass| Pass   | Pass   | Pass| Pass   | Pass   
>  | Pass| Pass   | Pass   | Pass| Pass   | Pass|
> 
> +-+---++---++
> | Scalable| Pass| Pass   | Pass   | Pass| Pass   | Pass   
>  | Pass| Pass   | Pass   | Pass| Pass   | Pass|
> 
> +-+---++---++

Hi, Yi,

Thanks very much for the thorough test matrix!

The last thing I'd like to confirm is have you tested device
assignment with v2?  And note that when you test with virtio devices
you should not need caching-mode=on (but caching-mode=on should not
break anyone though).

I've still got some comments here and there but it looks very good at
least to me overall.

Thanks,

-- 
Peter Xu



Re: [Qemu-devel] [RFC v2 3/3] intel_iommu: add scalable-mode option to make scalable mode work

2019-02-28 Thread Peter Xu
On Thu, Feb 28, 2019 at 09:47:57PM +0800, Yi Sun wrote:
> This patch adds an option to provide flexibility for user to expose
> Scalable Mode to guest. User could expose Scalable Mode to guest by
> the config as below:
> 
> "-device intel-iommu,caching-mode=on,scalable-mode=on"
> 
> The Linux iommu driver has supported scalable mode. Please refer below
> patch set:
> 
> https://www.spinics.net/lists/kernel/msg2985279.html
> 
> Signed-off-by: Liu, Yi L 
> Signed-off-by: Yi Sun 
> ---
> v2:
> - rename "scalable-mode" to "x-scalable-mode".
> - remove caching_mode check when scalable_mode is set.
> - check dma_drain check when scalable_mode is set. This is requested
>   by spec.
> - remove redundant macros.
> ---
>  hw/i386/intel_iommu.c  | 24 
>  hw/i386/intel_iommu_internal.h |  4 
>  include/hw/i386/intel_iommu.h  |  3 ++-
>  3 files changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> index d1eb0c5..ec7722d 100644
> --- a/hw/i386/intel_iommu.c
> +++ b/hw/i386/intel_iommu.c
> @@ -1733,6 +1733,9 @@ static void vtd_root_table_setup(IntelIOMMUState *s)
>  {
>  s->root = vtd_get_quad_raw(s, DMAR_RTADDR_REG);
>  s->root_extended = s->root & VTD_RTADDR_RTT;
> +if (s->scalable_mode) {
> +s->root_scalable = s->root & VTD_RTADDR_SMT;
> +}
>  s->root &= VTD_RTADDR_ADDR_MASK(s->aw_bits);
>  
>  trace_vtd_reg_dmar_root(s->root, s->root_extended);
> @@ -2442,6 +2445,17 @@ static bool vtd_process_inv_desc(IntelIOMMUState *s)
>  }
>  break;
>  
> +/*
> + * TODO: the entity of below two cases will be implemented in future 
> series.
> + * To make guest (which integrates scalable mode support patch set in
> + * iommu driver) work, just return true is enough so far.
> + */
> +case VTD_INV_DESC_PC:
> +break;
> +
> +case VTD_INV_DESC_PIOTLB:
> +break;
> +
>  case VTD_INV_DESC_WAIT:
>  trace_vtd_inv_desc("wait", inv_desc.hi, inv_desc.lo);
>  if (!vtd_process_wait_desc(s, _desc)) {
> @@ -3006,6 +3020,7 @@ static Property vtd_properties[] = {
>  DEFINE_PROP_UINT8("aw-bits", IntelIOMMUState, aw_bits,
>VTD_HOST_ADDRESS_WIDTH),
>  DEFINE_PROP_BOOL("caching-mode", IntelIOMMUState, caching_mode, FALSE),
> +DEFINE_PROP_BOOL("x-scalable-mode", IntelIOMMUState, scalable_mode, 
> FALSE),
>  DEFINE_PROP_BOOL("dma-drain", IntelIOMMUState, dma_drain, true),
>  DEFINE_PROP_END_OF_LIST(),
>  };
> @@ -3540,6 +3555,15 @@ static void vtd_init(IntelIOMMUState *s)
>  s->cap |= VTD_CAP_CM;
>  }
>  
> +/* TODO: read cap/ecap from host to decide which cap to be exposed. */
> +if (s->scalable_mode) {
> +if (!s->dma_drain) {
> +error_report("Need to set dma_drain for scalable mode");
> +exit(1);
> +}

This patch looks mostly good to me, only that can we move this check
to vtd_decide_config()?  That's where most similar checks are done.

> +s->ecap |= VTD_ECAP_SMTS | VTD_ECAP_SRS | VTD_ECAP_SLTS;
> +}
> +
>  vtd_reset_caches(s);
>  
>  /* Define registers with default values and bit semantics */
> diff --git a/hw/i386/intel_iommu_internal.h b/hw/i386/intel_iommu_internal.h
> index 016fa4c..1160618 100644
> --- a/hw/i386/intel_iommu_internal.h
> +++ b/hw/i386/intel_iommu_internal.h
> @@ -190,7 +190,9 @@
>  #define VTD_ECAP_EIM(1ULL << 4)
>  #define VTD_ECAP_PT (1ULL << 6)
>  #define VTD_ECAP_MHMV   (15ULL << 20)
> +#define VTD_ECAP_SRS(1ULL << 31)
>  #define VTD_ECAP_SMTS   (1ULL << 43)
> +#define VTD_ECAP_SLTS   (1ULL << 46)
>  
>  /* CAP_REG */
>  /* (offset >> 4) << 24 */
> @@ -345,6 +347,8 @@ typedef union VTDInvDesc VTDInvDesc;
>  #define VTD_INV_DESC_IEC0x4 /* Interrupt Entry Cache
> Invalidate Descriptor */
>  #define VTD_INV_DESC_WAIT   0x5 /* Invalidation Wait Descriptor 
> */
> +#define VTD_INV_DESC_PIOTLB 0x6 /* PASID-IOTLB Invalidate Desc */
> +#define VTD_INV_DESC_PC 0x7 /* PASID-cache Invalidate Desc */
>  #define VTD_INV_DESC_NONE   0   /* Not an Invalidate Descriptor 
> */
>  
>  /* Masks for Invalidation Wait Descriptor*/
> diff --git a/include/hw/i386/intel_iommu.h b/include/hw/i386/intel_iommu.h
> index 2877c94..c11e3d5 100644
> --- a/include/hw/i386/intel_iommu.h
> +++ b/include/hw/i386/intel_iommu.h
> @@ -227,7 +227,8 @@ struct IntelIOMMUState {
>  uint8_t womask[DMAR_REG_SIZE];  /* WO (write only - read returns 0) */
>  uint32_t version;
>  
> -bool caching_mode;  /* RO - is cap CM enabled? */
> +bool caching_mode;  /* RO - is cap CM enabled? */
> +bool scalable_mode; /* RO - is Scalable Mode supported? */
>  
>  dma_addr_t root;  

Re: [Qemu-devel] [RFC v2 2/3] intel_iommu: add 256 bits qi_desc support

2019-02-28 Thread Peter Xu
On Thu, Feb 28, 2019 at 09:47:56PM +0800, Yi Sun wrote:
> From: "Liu, Yi L" 
> 
> Per Intel(R) VT-d 3.0, the qi_desc is 256 bits in Scalable
> Mode. This patch adds emulation of 256bits qi_desc.
> 
> Signed-off-by: Liu, Yi L 
> [Yi Sun is co-developer to rebase and refine the patch.]
> Signed-off-by: Yi Sun 

[...]

> @@ -2501,7 +2507,12 @@ static void vtd_handle_iqt_write(IntelIOMMUState *s)
>  {
>  uint64_t val = vtd_get_quad_raw(s, DMAR_IQT_REG);
>  
> -s->iq_tail = VTD_IQT_QT(val);
> +if (s->iq_dw && val & VTD_IQT_QT_256_RSV_BIT) {

Nit: Let's do (val & VTD_IQT_QT_256_RSV_BIT) to be clear.  With that:

Reviewed-by: Peter Xu 

Regards,

-- 
Peter Xu



Re: [Qemu-devel] [PATCH v2] slirp: check for ioctlsocket error and 0-length udp payload.

2019-02-28 Thread no-reply
Patchew URL: https://patchew.org/QEMU/20190301064809.3074-1-llyzs@gmail.com/



Hi,

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

Message-id: 20190301064809.3074-1-llyzs@gmail.com
Subject: [Qemu-devel] [PATCH v2] slirp: check for ioctlsocket error and 
0-length udp payload.
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag]   patchew/20190301064809.3074-1-llyzs@gmail.com -> 
patchew/20190301064809.3074-1-llyzs@gmail.com
Switched to a new branch 'test'
0987e4851f slirp: check for ioctlsocket error and 0-length udp payload.

=== OUTPUT BEGIN ===
ERROR: code indent should never use tabs
#23: FILE: slirp/socket.c:532:
+^I  if (ioctlsocket(so->s, FIONREAD, ) != 0) {$

ERROR: suspect code indent for conditional statements (10, 14)
#23: FILE: slirp/socket.c:532:
+ if (ioctlsocket(so->s, FIONREAD, ) != 0) {
+ DEBUG_MISC((dfd," ioctlsocket errno = %d-%s\n",

ERROR: code indent should never use tabs
#24: FILE: slirp/socket.c:533:
+^I  DEBUG_MISC((dfd," ioctlsocket errno = %d-%s\n",$

ERROR: space required after that ',' (ctx:VxV)
#24: FILE: slirp/socket.c:533:
+ DEBUG_MISC((dfd," ioctlsocket errno = %d-%s\n",
 ^

ERROR: code indent should never use tabs
#25: FILE: slirp/socket.c:534:
+^I^I^I  errno,strerror(errno)));$

ERROR: space required after that ',' (ctx:VxV)
#25: FILE: slirp/socket.c:534:
+ errno,strerror(errno)));
   ^

ERROR: code indent should never use tabs
#26: FILE: slirp/socket.c:535:
+^I  return;$

ERROR: code indent should never use tabs
#27: FILE: slirp/socket.c:536:
+^I  }$

ERROR: code indent should never use tabs
#28: FILE: slirp/socket.c:537:
+^I  if (n == 0) {$

ERROR: suspect code indent for conditional statements (10, 14)
#28: FILE: slirp/socket.c:537:
+ if (n == 0) {
+ return;

ERROR: code indent should never use tabs
#29: FILE: slirp/socket.c:538:
+^I  return;$

ERROR: code indent should never use tabs
#30: FILE: slirp/socket.c:539:
+^I  }$

total: 12 errors, 0 warnings, 22 lines checked

Commit 0987e4851f60 (slirp: check for ioctlsocket error and 0-length udp 
payload.) has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20190301064809.3074-1-llyzs@gmail.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] [RFC v2 1/3] intel_iommu: scalable mode emulation

2019-02-28 Thread Peter Xu
On Thu, Feb 28, 2019 at 09:47:55PM +0800, Yi Sun wrote:
> From: "Liu, Yi L" 
> 
> Intel(R) VT-d 3.0 spec introduces scalable mode address translation to
> replace extended context mode. This patch extends current emulator to
> support Scalable Mode which includes root table, context table and new
> pasid table format change. Now intel_iommu emulates both legacy mode
> and scalable mode (with legacy-equivalent capability set).
> 
> The key points are below:
> 1. Extend root table operations to support both legacy mode and scalable
>mode.
> 2. Extend context table operations to support both legacy mode and
>scalable mode.
> 3. Add pasid tabled operations to support scalable mode.
> 
> Signed-off-by: Liu, Yi L 
> [Yi Sun is co-developer to contribute much to refine the whole commit.]
> Signed-off-by: Yi Sun 

Hi, Yi,

The Patch looks very good to me already, though I still have some
trivial comments below.

[...]

> -static inline bool vtd_ce_present(VTDContextEntry *context)
> +static inline bool vtd_ce_present(VTDContextEntry *ce)
>  {
> -return context->lo & VTD_CONTEXT_ENTRY_P;
> +return ce->lo & VTD_CONTEXT_ENTRY_P;

The renaming seems not needed.

>  }
>  
> -static int vtd_get_context_entry_from_root(VTDRootEntry *root, uint8_t index,
> +static int vtd_get_context_entry_from_root(IntelIOMMUState *s,
> +   VTDRootEntry *re,
> +   uint8_t index,
> VTDContextEntry *ce)
>  {
> -dma_addr_t addr;
> +dma_addr_t addr, ce_size;
>  
>  /* we have checked that root entry is present */
> -addr = (root->val & VTD_ROOT_ENTRY_CTP) + index * sizeof(*ce);
> -if (dma_memory_read(_space_memory, addr, ce, sizeof(*ce))) {
> +ce_size = s->root_scalable ? VTD_CTX_ENTRY_SCALABLE_SIZE :
> +  VTD_CTX_ENTRY_LEGACY_SIZE;
> +
> +if (s->root_scalable && index > UINT8_MAX / 2) {
> +index = index & (~VTD_DEVFN_CHECK_MASK);
> +addr = re->hi & VTD_ROOT_ENTRY_CTP;
> +} else {
> +addr = re->lo & VTD_ROOT_ENTRY_CTP;
> +}
> +
> +addr = addr + index * ce_size;
> +if (dma_memory_read(_space_memory, addr, ce, ce_size)) {
>  return -VTD_FR_CONTEXT_TABLE_INV;
>  }
> +
>  ce->lo = le64_to_cpu(ce->lo);
>  ce->hi = le64_to_cpu(ce->hi);
> +if (s->root_scalable) {

(or use ce_size which might be more obvious)

> +ce->val[2] = le64_to_cpu(ce->val[2]);
> +ce->val[3] = le64_to_cpu(ce->val[3]);
> +}
>  return 0;
>  }

[...]

> +static inline int vtd_ce_get_rid2pasid_entry(IntelIOMMUState *s,
> + VTDContextEntry *ce,
> + VTDPASIDEntry *pe)
> +{
> +uint32_t pasid;
> +dma_addr_t pasid_dir_base;
> +int ret = 0;
> +
> +pasid = VTD_CE_GET_RID2PASID(ce);
> +pasid_dir_base = VTD_CE_GET_PASID_DIR_TABLE(ce);
> +ret = vtd_get_pasid_entry_from_pasid(s, pasid_dir_base, pasid, pe);
> +
> +return ret;
> +}
> +
> +static inline int vtd_ce_get_pasid_fpd(IntelIOMMUState *s,
> +   VTDContextEntry *ce,
> +   bool *pe_fpd_set)

Many functions are defined as inlined (even some functions that may
not be that short IMHO) and many of them are not.  Could you share how
you decide which function should be inlined?

[...]

>  static inline bool vtd_ce_type_check(X86IOMMUState *x86_iommu,
>   VTDContextEntry *ce)
>  {
> +IntelIOMMUState *s = INTEL_IOMMU_DEVICE(x86_iommu);
> +
> +if (s->root_scalable) {
> +/*
> + * Translation Type locates in context entry only when VTD is in
> + * legacy mode. For scalable mode, need to return true to avoid
> + * unnecessary fault.
> + */
> +return true;
> +}

Do you think we can move this check directly into caller of
vtd_ce_type_check() which is vtd_dev_to_context_entry()?  Then:

  if (scalable_mode)
vtd_ce_rid2pasid_check()
  else
vtd_ce_type_check()

You can comment on function vtd_ce_type_check() that this only checks
legacy context entries, since calling vtd_ce_type_check() upon an
scalable mode context entry does not make much sense itself already.

[...]

>  /* Return whether the device is using IOMMU translation. */
> @@ -1322,9 +1636,24 @@ static bool vtd_do_iommu_translate(VTDAddressSpace 
> *vtd_as, PCIBus *bus,
> cc_entry->context_cache_gen);
>  ce = cc_entry->context_entry;
>  is_fpd_set = ce.lo & VTD_CONTEXT_ENTRY_FPD;
> +if (!is_fpd_set && s->root_scalable) {
> +ret_fr = vtd_ce_get_pasid_fpd(s, , _fpd_set);
> +if (ret_fr) {
> +ret_fr = -ret_fr;
> +if (is_fpd_set && vtd_is_qualified_fault(ret_fr)) {

I noticed that I can't find how's vtd_qualified_faults defined and how

[Qemu-devel] [PATCH v2] slirp: check for ioctlsocket error and 0-length udp payload.

2019-02-28 Thread Vic Lee
Sometimes sorecvfrom() is called from slirp.c because revents == G_IO_IN,
but there is 0 bytes available and recvfrom could be blocking indefinitely.
This is likely due to 0-length udp payload. This also adds an error
checking for ioctlsocket.

Signed-off-by: Vic Lee 
---
 slirp/socket.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/slirp/socket.c b/slirp/socket.c
index 4876ea3f31..03266128b1 100644
--- a/slirp/socket.c
+++ b/slirp/socket.c
@@ -529,6 +529,15 @@ sorecvfrom(struct socket *so)
   int n;
 #endif
 
+ if (ioctlsocket(so->s, FIONREAD, ) != 0) {
+ DEBUG_MISC((dfd," ioctlsocket errno = %d-%s\n",
+ errno,strerror(errno)));
+ return;
+ }
+ if (n == 0) {
+ return;
+ }
+
  m = m_get(so->slirp);
  if (!m) {
  return;
@@ -552,7 +561,6 @@ sorecvfrom(struct socket *so)
   */
  len = M_FREEROOM(m);
  /* if (so->so_fport != htons(53)) { */
- ioctlsocket(so->s, FIONREAD, );
 
  if (n > len) {
n = (m->m_data - m->m_dat) + m->m_len + n + 1;
-- 
2.20.1




Re: [Qemu-devel] [PATCH v1 14/33] s390x/tcg: Implement VECTOR LOAD MULTIPLE

2019-02-28 Thread Richard Henderson
On 2/28/19 11:05 AM, David Hildenbrand wrote:
> So for writing from helpers, I can use probe_write(). What about testing
> write access from TCG code?
> 
> I could do a load, followed by a store of the loaded value. This should
> work in most cases (but eventually could be observed by somebody really
> wanting to observe it - which is highly unlikely).

I would call a helper for probe_write.


r~



[Qemu-devel] [PATCH] Fix coredump when using virtio-vga

2019-02-28 Thread 08005325
From: Michael Qiu 

When using command -device virtio-vga,virgl=on
the default max_outputs is 0, this will lead coredump,

(con=0x0, hw_ops=0x564452e0 ,
 opaque=0x5754ec60) at ui/console.c:1872
(vpci_dev=0x5754ec60, errp=0x7fffdbb8)
 at qemu/hw/display/virtio-vga.c:160
(pci_dev=0x5754ec60, errp=0x7fffdbb8)
 at hw/virtio/virtio-pci.c:1786
...

This patch force ths max_outputs to 1 when it not greater
than 0.

Signed-off-by: Michael Qiu 
---
 hw/display/virtio-gpu-pci.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/hw/display/virtio-gpu-pci.c b/hw/display/virtio-gpu-pci.c
index bdcd33c..59b571d 100644
--- a/hw/display/virtio-gpu-pci.c
+++ b/hw/display/virtio-gpu-pci.c
@@ -46,6 +46,11 @@ static void virtio_gpu_pci_realize(VirtIOPCIProxy *vpci_dev, 
Error **errp)
 int i;
 Error *local_error = NULL;
 
+if (g->conf.max_outputs <= 0) {
+qemu_log("WARNING: virtio gpu max_outputs must greater than 1");
+g->conf.max_outputs = 1;
+}
+
 qdev_set_parent_bus(vdev, BUS(_dev->bus));
 virtio_pci_force_virtio_1(vpci_dev);
 object_property_set_bool(OBJECT(vdev), true, "realized", _error);
-- 
1.8.3.1




Re: [Qemu-devel] [PATCH] Fix coredump when using virtio-vga

2019-02-28 Thread Gerd Hoffmann
On Fri, Mar 01, 2019 at 12:13:08PM +0800, 08005...@163.com wrote:
> From: Michael Qiu 
> 
> When using command -device virtio-vga,virgl=on
> the default max_outputs is 0, this will lead coredump,

The default is 1.

> @@ -46,6 +46,11 @@ static void virtio_gpu_pci_realize(VirtIOPCIProxy 
> *vpci_dev, Error **errp)
>  int i;
>  Error *local_error = NULL;
>  
> +if (g->conf.max_outputs <= 0) {
> +qemu_log("WARNING: virtio gpu max_outputs must greater than 1");
> +g->conf.max_outputs = 1;
> +}

There already is a sanity check in virtio_gpu_device_realize().
You can extend that to also throw an error in case max_outputs
is 0.  Fixing things up and continuing is a bad idea.  Yes there
are places in the qemu code base still doing that, for backward
compatibility with old versions, but we should not add new
instances of this.

cheers,
  Gerd




Re: [Qemu-devel] Questions about EDID

2019-02-28 Thread Gerd Hoffmann
On Thu, Feb 28, 2019 at 11:53:43AM -0500, G 3 wrote:
> On Thu, Feb 28, 2019 at 12:01 AM Mark Cave-Ayland <
> mark.cave-ayl...@ilande.co.uk> wrote:
> 
> > On 27/02/2019 05:27, Gerd Hoffmann wrote:
> >
> > > On Tue, Feb 26, 2019 at 04:11:06PM -0500, G 3 wrote:
> > >> When I use edid=on, I do see a lot of extra resolutions available in
> > Mac OS
> > >> 9 and Mac OS X, just not the resolution I want to use. Is there some
> > kind
> > >> of rule like the resolution value has to be divisible by a certain
> > number?
> > >
> > > qemu doesn't have such a requirement.
> > > Might be the guest drivers have.
> > > Try making width/height multiple of 8 or 16.
> >
> > Right, at the moment all the MacOS driver does is parse the resolution
> > list from the
> > EDID and add them to the dropdown list - it doesn't support the xres and
> > yres properties.
> >
> 
> Gerd, could the xres +yres numbers be added to the list of resolutions
> then?

That is already the case:

qemu-edid -x 1234 -y 567 | edid-decode
[ ... ]
First detailed timing is preferred timing
Established timings supported:
  640x480@60Hz
  800x600@60Hz
  1024x768@60Hz
Standard timings supported:
  2048x1152@60Hz
  1920x1080@60Hz
Detailed mode: Clock 73.170 MHz, 485 mm x 223 mm
   1234 1542 1579 1665 hborder 0
   
567  569  571  586 vborder 0
^^^
   -hsync -vsync 
[ ... ]

cheers,
  Gerd




Re: [Qemu-devel] Questions about EDID

2019-02-28 Thread Gerd Hoffmann
  Hi,

> > Well, not really.  EDID is about monitor capabilities.  The monitor will
> > see 8 bit per color channel, no matter whenever your GPU composes that
> > signal using a 8bpp mode + color palette or 24bpp mode with direct
> > color.
> 
> Hmmm okay. Perhaps it might still be worth hooking -g XxYxD to also put X and 
> Y into
> xres and yres within the EDID so at least everything is consistent between 
> OpenBIOS
> and the client driver when it eventually loads?

That makes sense, sure.  Will be a bit tricky due to (I think) only ppc
and sparc actually looking at -g right now, to make sure current
behavior of the other archs doesn't change when -g is not specified.

cheers,
  Gerd




[Qemu-devel] [PATCHv2] slirp: check for ioctlsocket error and 0-length udp payload.

2019-02-28 Thread llyzs
Sometimes sorecvfrom() is called from slirp.c because revents == G_IO_IN,
but there is 0 bytes available and recvfrom could be blocking indefinitely.
This is likely due to 0-length udp payload. This also adds an error
checking for ioctlsocket.

Signed-off-by: Vic Lee 
---
 slirp/socket.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/slirp/socket.c b/slirp/socket.c
index c01d8696af..a624d829e3 100644
--- a/slirp/socket.c
+++ b/slirp/socket.c
@@ -549,6 +549,15 @@ sorecvfrom(struct socket *so)
   int n;
 #endif

+ if (ioctlsocket(so->s, FIONREAD, ) != 0) {
+ DEBUG_MISC((dfd," ioctlsocket errno = %d-%s\n",
+ errno,strerror(errno)));
+ return;
+ }
+ if (n == 0) {
+ return;
+ }
+
  m = m_get(so->slirp);
  if (!m) {
  return;
@@ -572,7 +581,6 @@ sorecvfrom(struct socket *so)
   */
  len = M_FREEROOM(m);
  /* if (so->so_fport != htons(53)) { */
- ioctlsocket(so->s, FIONREAD, );

  if (n > len) {
n = (m->m_data - m->m_dat) + m->m_len + n + 1;
-- 
2.20.1



Re: [Qemu-devel] [PATCH] socket: fix blocking udp recvfrom.

2019-02-28 Thread Samuel Thibault
llyzs, le ven. 01 mars 2019 12:27:31 +0800, a ecrit:
> I believe this is because UDP packet can have 0 length payload.

Ah, right, that one makes sense indeed.

> I also found out that sometimes ioctlsocket() call can return error
> (probably caused by my unstable wifi linux driver), in which case we
> can also return immediately.

We should check for the value returned by ioctlsocket() then, otherwise
the value of n is undefined.

Samuel



[Qemu-devel] [QEMU-PPC] [PATCH 2/2] target/ppc/spapr: Enable mitigations by default for pseries-4.0 machine type

2019-02-28 Thread Suraj Jitindar Singh
There are currently 3 mitigations the availability of which is controlled
by the spapr-caps mechanism, cap-cfpc, cap-sbbc, and cap-ibs. Enable these
mitigations by default for the pseries-4.0 machine type.

By now machine firmware should have been upgraded to allow these
settings.

Signed-off-by: Suraj Jitindar Singh 
---
 hw/ppc/spapr.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 708e18dcdf..b103d2677e 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -4314,9 +4314,9 @@ static void spapr_machine_class_init(ObjectClass *oc, 
void *data)
 smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_OFF;
 smc->default_caps.caps[SPAPR_CAP_VSX] = SPAPR_CAP_ON;
 smc->default_caps.caps[SPAPR_CAP_DFP] = SPAPR_CAP_ON;
-smc->default_caps.caps[SPAPR_CAP_CFPC] = SPAPR_CAP_BROKEN;
-smc->default_caps.caps[SPAPR_CAP_SBBC] = SPAPR_CAP_BROKEN;
-smc->default_caps.caps[SPAPR_CAP_IBS] = SPAPR_CAP_BROKEN;
+smc->default_caps.caps[SPAPR_CAP_CFPC] = SPAPR_CAP_WORKAROUND;
+smc->default_caps.caps[SPAPR_CAP_SBBC] = SPAPR_CAP_WORKAROUND;
+smc->default_caps.caps[SPAPR_CAP_IBS] = SPAPR_CAP_WORKAROUND;
 smc->default_caps.caps[SPAPR_CAP_HPT_MAXPAGESIZE] = 16; /* 64kiB */
 smc->default_caps.caps[SPAPR_CAP_NESTED_KVM_HV] = SPAPR_CAP_OFF;
 smc->default_caps.caps[SPAPR_CAP_LARGE_DECREMENTER] = SPAPR_CAP_ON;
@@ -4396,6 +4396,9 @@ static void spapr_machine_3_1_class_options(MachineClass 
*mc)
 mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("power8_v2.0");
 smc->update_dt_enabled = false;
 smc->dr_phb_enabled = false;
+smc->default_caps.caps[SPAPR_CAP_CFPC] = SPAPR_CAP_BROKEN;
+smc->default_caps.caps[SPAPR_CAP_SBBC] = SPAPR_CAP_BROKEN;
+smc->default_caps.caps[SPAPR_CAP_IBS] = SPAPR_CAP_BROKEN;
 smc->default_caps.caps[SPAPR_CAP_LARGE_DECREMENTER] = SPAPR_CAP_OFF;
 }
 
-- 
2.13.6




[Qemu-devel] [QEMU-PPC] [PATCH 0/2] Enable mitigations by default for pseries-4.0 machine type

2019-02-28 Thread Suraj Jitindar Singh
This series is based on the ppc-for-4.0 branch with my large-decrementer
and count-cache-flush series applied.

Suraj Jitindar Singh (2):
  target/ppc/tcg: make spapr_caps apply cap-[cfpc/sbbc/ibs] non-fatal
for tcg
  target/ppc/spapr: Enable mitigations by default for pseries-4.0
machine type

 hw/ppc/spapr.c  |  9 ++---
 hw/ppc/spapr_caps.c | 33 -
 2 files changed, 30 insertions(+), 12 deletions(-)

-- 
2.13.6




[Qemu-devel] [QEMU-PPC] [PATCH 1/2] target/ppc/tcg: make spapr_caps apply cap-[cfpc/sbbc/ibs] non-fatal for tcg

2019-02-28 Thread Suraj Jitindar Singh
The spapr_caps cap-cfpc, cap-sbbc and cap-ibs are used to control the
availability of certain mitigations to the guest. These haven't been
implemented under TCG, it is unlikely they ever will be, and it is unclear
as to whether they even need to be.

As such, make failure to apply these capabilities under TCG non-fatal.
Instead we print a warning message to the user but still allow the guest
to continue.

Signed-off-by: Suraj Jitindar Singh 
---
 hw/ppc/spapr_caps.c | 33 -
 1 file changed, 24 insertions(+), 9 deletions(-)

diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
index f03f2f64e7..b68d767d63 100644
--- a/hw/ppc/spapr_caps.c
+++ b/hw/ppc/spapr_caps.c
@@ -239,17 +239,22 @@ sPAPRCapPossible cap_cfpc_possible = {
 static void cap_safe_cache_apply(sPAPRMachineState *spapr, uint8_t val,
  Error **errp)
 {
+Error *local_err = NULL;
 uint8_t kvm_val =  kvmppc_get_cap_safe_cache();
 
 if (tcg_enabled() && val) {
-/* TODO - for now only allow broken for TCG */
-error_setg(errp,
-"Requested safe cache capability level not supported by tcg, try a different 
value for cap-cfpc");
+/* TCG only supports broken, allow other values and print a warning */
+error_setg(_err,
+   "TCG doesn't support requested feature, cap-cfpc=%s",
+   cap_cfpc_possible.vals[val]);
 } else if (kvm_enabled() && (val > kvm_val)) {
 error_setg(errp,
 "Requested safe cache capability level not supported by kvm, try cap-cfpc=%s",
cap_cfpc_possible.vals[kvm_val]);
 }
+
+if (local_err != NULL)
+warn_report_err(local_err);
 }
 
 sPAPRCapPossible cap_sbbc_possible = {
@@ -262,17 +267,22 @@ sPAPRCapPossible cap_sbbc_possible = {
 static void cap_safe_bounds_check_apply(sPAPRMachineState *spapr, uint8_t val,
 Error **errp)
 {
+Error *local_err = NULL;
 uint8_t kvm_val =  kvmppc_get_cap_safe_bounds_check();
 
 if (tcg_enabled() && val) {
-/* TODO - for now only allow broken for TCG */
-error_setg(errp,
-"Requested safe bounds check capability level not supported by tcg, try a 
different value for cap-sbbc");
+/* TCG only supports broken, allow other values and print a warning */
+error_setg(_err,
+   "TCG doesn't support requested feature, cap-sbbc=%s",
+   cap_sbbc_possible.vals[val]);
 } else if (kvm_enabled() && (val > kvm_val)) {
 error_setg(errp,
 "Requested safe bounds check capability level not supported by kvm, try 
cap-sbbc=%s",
cap_sbbc_possible.vals[kvm_val]);
 }
+
+if (local_err != NULL)
+warn_report_err(local_err);
 }
 
 sPAPRCapPossible cap_ibs_possible = {
@@ -288,17 +298,22 @@ sPAPRCapPossible cap_ibs_possible = {
 static void cap_safe_indirect_branch_apply(sPAPRMachineState *spapr,
uint8_t val, Error **errp)
 {
+Error *local_err = NULL;
 uint8_t kvm_val = kvmppc_get_cap_safe_indirect_branch();
 
 if (tcg_enabled() && val) {
-/* TODO - for now only allow broken for TCG */
-error_setg(errp,
-"Requested safe indirect branch capability level not supported by tcg, try a 
different value for cap-ibs");
+/* TCG only supports broken, allow other values and print a warning */
+error_setg(_err,
+   "TCG doesn't support requested feature, cap-ibs=%s",
+   cap_ibs_possible.vals[val]);
 } else if (kvm_enabled() && (val > kvm_val)) {
 error_setg(errp,
 "Requested safe indirect branch capability level not supported by kvm, try 
cap-ibs=%s",
cap_ibs_possible.vals[kvm_val]);
 }
+
+if (local_err != NULL)
+warn_report_err(local_err);
 }
 
 #define VALUE_DESC_TRISTATE " (broken, workaround, fixed)"
-- 
2.13.6




Re: [Qemu-devel] [PATCH] socket: fix blocking udp recvfrom.

2019-02-28 Thread llyzs
Hi,

I believe this is because UDP packet can have 0 length payload. I
quote some resources here:
https://stackoverflow.com/questions/12505892/under-linux-can-recv-ever-return-0-on-udp
https://stackoverflow.com/questions/5307031/how-to-detect-receipt-of-a-0-length-udp-datagram

I also found out that sometimes ioctlsocket() call can return error
(probably caused by my unstable wifi linux driver), in which case we
can also return immediately.

I will submit a new version of the patch according to your suggestions.

On Fri, 1 Mar 2019 at 04:51, Samuel Thibault  wrote:
>
> Hello,
>
> llyzs, le jeu. 28 févr. 2019 19:59:12 +0800, a ecrit:
> > Sometimes sorecvfrom() is called from slirp.c because revents == G_IO_IN,
> > however inside sorecvfrom() function, ioctlsocket() returns 0 bytes 
> > available
> > and recvfrom could be blocking indefinitely. This adds a non-blocking flag 
> > to
> > recvfrom and checks data availability.
>
> When ioctlsocket() returns 0 bytes available, we could as well just
> immediately return, without even calling recvfrom. We could just move
> that ioctlsocket call above the m_get() call, so we can just return
> without having to clean up anything.
>
> This however still looks weird. AFAIK, G_IO_IN means that we can make
> one recv call and be sure that it won't block. Do you have an idea why
> it wouldn't necessarily be the case?
>
> Samuel



Re: [Qemu-devel] [QEMU-PPC] [PATCH 2/2] target/ppc/spapr: Add SPAPR_CAP_CCF_ASSIST

2019-02-28 Thread Suraj Jitindar Singh
On Fri, 2019-03-01 at 14:19 +1100, Suraj Jitindar Singh wrote:
> Introduce a new spapr_cap SPAPR_CAP_CCF_ASSIST to be used to indicate
> the requirement for a hw-assisted version of the count cache flush
> workaround.
> 
> The count cache flush workaround is a software workaround which can
> be
> used to flush the count cache on context switch. Some revisions of
> hardware may have a hardware accelerated flush, in which case the
> software flush can be shortened. This cap is used to set the
> availability of such hardware acceleration for the count cache flush
> routine.
> 
> The availability of such hardware acceleration is indicated by the
> H_CPU_CHAR_BCCTR_FLUSH_ASSIST flag being set in the characteristics
> returned from the KVM_PPC_GET_CPU_CHAR ioctl.
> 
> Signed-off-by: Suraj Jitindar Singh 
> ---
>  hw/ppc/spapr.c |  2 ++
>  hw/ppc/spapr_caps.c| 25 +
>  hw/ppc/spapr_hcall.c   |  3 +++
>  include/hw/ppc/spapr.h |  5 -
>  target/ppc/kvm.c   | 14 ++
>  target/ppc/kvm_ppc.h   |  6 ++
>  6 files changed, 54 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 1df324379f..708e18dcdf 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -2086,6 +2086,7 @@ static const VMStateDescription vmstate_spapr =
> {
>  _spapr_cap_nested_kvm_hv,
>  _spapr_dtb,
>  _spapr_cap_large_decr,
> +_spapr_cap_ccf_assist,
>  NULL
>  }
>  };
> @@ -4319,6 +4320,7 @@ static void
> spapr_machine_class_init(ObjectClass *oc, void *data)
>  smc->default_caps.caps[SPAPR_CAP_HPT_MAXPAGESIZE] = 16; /* 64kiB
> */
>  smc->default_caps.caps[SPAPR_CAP_NESTED_KVM_HV] = SPAPR_CAP_OFF;
>  smc->default_caps.caps[SPAPR_CAP_LARGE_DECREMENTER] =
> SPAPR_CAP_ON;
> +smc->default_caps.caps[SPAPR_CAP_CCF_ASSIST] = SPAPR_CAP_OFF;
>  spapr_caps_add_properties(smc, _abort);
>  smc->irq = _irq_xics;
>  smc->dr_phb_enabled = true;
> diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
> index 74a48a423a..f03f2f64e7 100644
> --- a/hw/ppc/spapr_caps.c
> +++ b/hw/ppc/spapr_caps.c
> @@ -436,6 +436,21 @@ static void
> cap_large_decr_cpu_apply(sPAPRMachineState *spapr,
>  ppc_store_lpcr(cpu, lpcr);
>  }
>  
> +static void cap_ccf_assist_apply(sPAPRMachineState *spapr, uint8_t
> val,
> + Error **errp)
> +{
> +uint8_t kvm_val = kvmppc_get_cap_count_cache_flush_assist();
> +
> +if (tcg_enabled() && val) {
> +/* TODO - for now only allow broken for TCG */
> +error_setg(errp,
> +"Requested count cache flush assist capability level not supported
> by tcg, try cap-ccf-assist=off");
> +} else if (kvm_enabled() && (val > kvm_val)) {
> +error_setg(errp,
> +"Requested count cache flush assist capability level not supported
> by kvm, try cap-ccf-assist=off");
> +}

Actually, this should probably be non-fatal if the count cache flush
routine isn't enabled

> +}
> +
>  sPAPRCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
>  [SPAPR_CAP_HTM] = {
>  .name = "htm",
> @@ -525,6 +540,15 @@ sPAPRCapabilityInfo
> capability_table[SPAPR_CAP_NUM] = {
>  .apply = cap_large_decr_apply,
>  .cpu_apply = cap_large_decr_cpu_apply,
>  },
> +[SPAPR_CAP_CCF_ASSIST] = {
> +.name = "ccf-assist",
> +.description = "Count Cache Flush Assist via HW
> Instruction",
> +.index = SPAPR_CAP_CCF_ASSIST,
> +.get = spapr_cap_get_bool,
> +.set = spapr_cap_set_bool,
> +.type = "bool",
> +.apply = cap_ccf_assist_apply,
> +},
>  };
>  
>  static sPAPRCapabilities default_caps_with_cpu(sPAPRMachineState
> *spapr,
> @@ -659,6 +683,7 @@ SPAPR_CAP_MIG_STATE(sbbc, SPAPR_CAP_SBBC);
>  SPAPR_CAP_MIG_STATE(ibs, SPAPR_CAP_IBS);
>  SPAPR_CAP_MIG_STATE(nested_kvm_hv, SPAPR_CAP_NESTED_KVM_HV);
>  SPAPR_CAP_MIG_STATE(large_decr, SPAPR_CAP_LARGE_DECREMENTER);
> +SPAPR_CAP_MIG_STATE(ccf_assist, SPAPR_CAP_CCF_ASSIST);
>  
>  void spapr_caps_init(sPAPRMachineState *spapr)
>  {
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index 4aa8036fc0..8bfdddc964 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -1693,6 +1693,7 @@ static target_ulong
> h_get_cpu_characteristics(PowerPCCPU *cpu,
>  uint8_t safe_cache = spapr_get_cap(spapr, SPAPR_CAP_CFPC);
>  uint8_t safe_bounds_check = spapr_get_cap(spapr,
> SPAPR_CAP_SBBC);
>  uint8_t safe_indirect_branch = spapr_get_cap(spapr,
> SPAPR_CAP_IBS);
> +uint8_t count_cache_flush_assist = spapr_get_cap(spapr,
> SPAPR_CAP_CCF_ASSIST);
>  
>  switch (safe_cache) {
>  case SPAPR_CAP_WORKAROUND:
> @@ -1733,6 +1734,8 @@ static target_ulong
> h_get_cpu_characteristics(PowerPCCPU *cpu,
>  break;
>  case SPAPR_CAP_WORKAROUND:
>  behaviour |= H_CPU_BEHAV_FLUSH_COUNT_CACHE;
> +if (count_cache_flush_assist)
> +characteristics |= H_CPU_CHAR_BCCTR_FLUSH_ASSIST;
>

Re: [Qemu-devel] [PATCH RESEND v4] drive-mirror: add incremental mode

2019-02-28 Thread 滴滴云
> CC-ing John because of the keyword "incremental".
Ok
>
>On 14.02.19 07:43, mahaocong wrote:
>> From: mahaocong 
>>
>> This patch adds possibility to start mirroring with user-created-bitmap.
>> On full mode, mirror create a non-named-bitmap by scanning whole block-
>> chain, and on top mode, mirror create a bitmap by scanning the top block
>> layer. So I think I can copy a user-created-bitmap and use it as the
>> initial state of the mirror, the same as incremental mode drive-backup,
>> and I call this new mode as incremental mode drive-mirror.
>>
>> A possible usage scene of incremental mode mirror is live migration.
>> For maintain the block data and recover after a malfunction, someone may
>> backup data to ceph or other distributed storage. On qemu incremental
>> backup, we need to create a new bitmap and attach to block device before
>> the first backup job. Then the bitmap records the change after the backup
>> job. If we want to migration this vm, we can migrate block data between
>> source and destionation by using drive-mirror directly, or use backup data
>> and backup-bitmap to reduce the data should be synchronize. To do this,
>> we should first create a new image in destination and set backing file
>> as backup image, then set backup-bitmap as the initial state of incremental
>> mode drive-mirror, and synchronize dirty block starting with the state set
>> by the last incremental backup job. When the mirror complete, we get an
>> active layer on destination, and its backing file is backup image on ceph.
>> Then we can do live copy data from backing files into overlay images by
>> using block-stream, or do backup continually.
>>
>> In this scene, It seems that If the guest os doesn't write too many data
>> after the last backup, the incremental mode may transmit less data than
>> full mode or top mode. However, if the write data is too many, there is
>> no advantage on incremental mode compare with other mode.
>>
>> This scene can be described as following steps:
>> 1.create rbd image in ceph, and map nbd device with rbd image.
>> 2.create a new bitmap and attach to block device.
>> 3.do full mode backup on nbd device and thus sync it to the rbd image.
>> 4.severl times incremental mode backup.
>> 5.create new image in destination and set its backing file as backup image.
>> 6.do live-migration, and migrate block data by incremental mode drive-
>> mirror with bitmap created from step 2.
>>
>> Signed-off-by: Ma Haocong 
>> ---
>
>So one important point about incremental backups is that you can
>actually do them incrementally: The bitmap is effectively cleared at the
>beginning of the backup process (a successor bitmap is installed that is
>cleared and receives all changes; at the end of the backup, it either
>replaces the old bitmap (on success) or is merged into it (on failure)).
> Therefore, you can do the next incremental backup by using the same bitmap.
>
>How would this work with mirroring?  Instead of clearing the bitmap at
>the start of the process, it'd need to be cleared at the end (because we
>reach synchronization between source and target then).  But how would
>error handling work?
>
>I suppose the named bitmap would need to be copied to act as the dirty
>bitmap for the mirror job (at the start of the job).  If a failure
>occurs, the copy is simply discarded.  On success, the named bitmap is
>cleared when the job is completed.  Hm, that seems to make sense.  Did I
>forget anything, John?
>
>In any case, I don't think this patch implemented anything to this
>regard...?  So it doesn't really implement incremental mirroring.
>However, I think it should, if possible.
>
>Max

I think you are right, the bitmap will be cleared at the end of mirroring,
Therefore, I can't use the same bitmap to do the next incremental mirror,
as the incremental backup does. So, it is not a real incremental mirror.

In our scene, the main purpose is to let mirror job use the same bitmap as
backup job. As bitmap used by backup job tracks dirty data since last time
backup job happened, with this patch, if mirror job uses the backup bitmap,
mirrored data is less than before, and then time spend by mirror job is
shortened. To get the full data, a stream job can pull the backup data into
the mirrored data. If mirror job is used in live migration, with this patch,
time spend by migration is shorten, transferred data is reduced, resources
used by qemu process on source host can be released earlier.

So, this patch is an optimization to our live migration, although it is not
appropriate to call it an incremental mode mirroring.

Thanks

Ma haocong 



[Qemu-devel] [PATCH v7] i386, acpi: check acpi_memory_hotplug capacity in pre_plug

2019-02-28 Thread Wei Yang
Currently we do device realization like below:

   hotplug_handler_pre_plug()
   dc->realize()
   hotplug_handler_plug()

Before we do device realization and plug, we should allocate necessary
resources and check if memory-hotplug-support property is enabled.

At the piix4 and ich9, the memory-hotplug-support property is checked at
plug stage. This means that device has been realized and mapped into guest
address space 'pc_dimm_plug()' by the time acpi plug handler is called,
where it might fail and crash QEMU due to reaching g_assert_not_reached()
(piix4) or error_abort (ich9).

Fix it by checking if memory hotplug is enabled at pre_plug stage
where we can gracefully abort hotplug request.

Signed-off-by: Wei Yang 
CC: Igor Mammedov 
CC: Eric Blake 
Signed-off-by: Wei Yang 

---
v7:
   * fix code style
v6:
   * fix the check in piix4_device_pre_plug_cb
v5:
   * rebase on latest upstream
   * remove a comment before hotplug_handler_pre_plug
   * fix alignment for ich9_pm_device_pre_plug_cb
v4:
   * fix code alignment of piix4_device_pre_plug_cb
v3:
   * replace acpi_memory_hotplug with memory-hotplug-support in changelog
   * fix code alignment of ich9_pm_device_pre_plug_cb
   * print which device type memory-hotplug-support is disabled in
 ich9_pm_device_pre_plug_cb and piix4_device_pre_plug_cb
v2:
   * (imamm...@redhat.com)
 - Almost the whole third paragraph
   * apply this change to ich9
   * use hotplug_handler_pre_plug() instead of open-coding check
---
 hw/acpi/ich9.c | 15 +--
 hw/acpi/piix4.c| 13 ++---
 hw/i386/pc.c   |  2 ++
 hw/isa/lpc_ich9.c  |  1 +
 include/hw/acpi/ich9.h |  2 ++
 5 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index c5d8646abc..e53dfe1ee3 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -483,13 +483,24 @@ void ich9_pm_add_properties(Object *obj, ICH9LPCPMRegs 
*pm, Error **errp)
  NULL);
 }
 
+void ich9_pm_device_pre_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev,
+Error **errp)
+{
+ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev);
+
+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM) &&
+!lpc->pm.acpi_memory_hotplug.is_enabled)
+error_setg(errp,
+   "memory hotplug is not enabled: %s.memory-hotplug-support "
+   "is not set", object_get_typename(OBJECT(lpc)));
+}
+
 void ich9_pm_device_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev,
 Error **errp)
 {
 ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev);
 
-if (lpc->pm.acpi_memory_hotplug.is_enabled &&
-object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
 if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
 nvdimm_acpi_plug_cb(hotplug_dev, dev);
 } else {
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index df8c0db909..c5a4b3f9fe 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -374,9 +374,17 @@ static void piix4_pm_powerdown_req(Notifier *n, void 
*opaque)
 static void piix4_device_pre_plug_cb(HotplugHandler *hotplug_dev,
 DeviceState *dev, Error **errp)
 {
+PIIX4PMState *s = PIIX4_PM(hotplug_dev);
+
 if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
 acpi_pcihp_device_pre_plug_cb(hotplug_dev, dev, errp);
-} else if (!object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM) &&
+} else if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
+if (!s->acpi_memory_hotplug.is_enabled) {
+error_setg(errp,
+"memory hotplug is not enabled: %s.memory-hotplug-support "
+"is not set", object_get_typename(OBJECT(s)));
+}
+} else if (
!object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
 error_setg(errp, "acpi: device pre plug request for not supported"
" device type: %s", object_get_typename(OBJECT(dev)));
@@ -388,8 +396,7 @@ static void piix4_device_plug_cb(HotplugHandler 
*hotplug_dev,
 {
 PIIX4PMState *s = PIIX4_PM(hotplug_dev);
 
-if (s->acpi_memory_hotplug.is_enabled &&
-object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
 if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
 nvdimm_acpi_plug_cb(hotplug_dev, dev);
 } else {
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 578f772e7c..64d9e756fa 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -2083,6 +2083,8 @@ static void pc_memory_pre_plug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 return;
 }
 
+hotplug_handler_pre_plug(pcms->acpi_dev, dev, errp);
+
 if (is_nvdimm && !pcms->acpi_nvdimm_state.is_enabled) {
 error_setg(errp, "nvdimm is not enabled: missing 'nvdimm' in '-M'");
 return;
diff --git a/hw/isa/lpc_ich9.c 

Re: [Qemu-devel] [PATCH] migration: Cleanup during exit

2019-02-28 Thread Peter Xu
On Thu, Feb 28, 2019 at 12:28:22PM +, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > On Thu, Feb 28, 2019 at 11:40:19AM +, Dr. David Alan Gilbert wrote:
> > > * Peter Xu (pet...@redhat.com) wrote:
> > > > On Wed, Feb 27, 2019 at 04:49:00PM +, Dr. David Alan Gilbert (git) 
> > > > wrote:
> > > > > From: "Dr. David Alan Gilbert" 
> > > > > 
> > > > > Currently we cleanup the migration object as we exit main after the
> > > > > main_loop finishes; however if there's a migration running things
> > > > > get messy and we can end up with the migration thread still trying
> > > > > to access freed structures.
> > > > > 
> > > > > We now take a ref to the object around the migration thread itself,
> > > > > so the act of dropping the ref during exit doesn't cause us to lose
> > > > > the state until the thread quits.
> > > > > 
> > > > > Cancelling the migration during migration also tries to get the thread
> > > > > to quit.
> > > > > 
> > > > > We do this a bit earlier; so hopefully migration gets out of the way
> > > > > before all the devices etc are freed.
> > > > 
> > > > So does it mean that even with the patch it's still possible the
> > > > migration thread will be accessing device structs that have already
> > > > been freed which can still crash QEMU?
> > > 
> > > Possibly yes; I'm not sure how to go to the next stage and stop that
> > > case; the consensus seems to be we don't want to explicitly block
> > > during the exit process, so doing a join on the migration thread doesn't
> > > seem to be wanted.
> > 
> > Essentially the many  *_cleanup() calls at the end of main() in vl.c
> > are only ever safe if all background threads have stopped using the
> > resources that are being freed. This isn't the case with migration
> > currently. I also worry about other threads that might be running
> > in QEMU, SPICE in particular as it touchs many device backends.
> > 
> > Aborting the migration & joining the migration threads is the natural
> > way to address this. Cancelling appears to require the main loop to
> > still be running, so would require main_loop_should_exit() to issue
> > the cancel & return false unless it has completed. This would delay
> > shutdown for as long as it takes migration to abort.
> 
> ish - cancelling performs a shutdown(2) on the fd, that should be enough
> in most cases to kick the migration thread into falling out without
> main loop interaction; I think...

Dave, could you hint me on when shutdown() will not suffice (say,
we'll hang death if we do join() upon the migration thread)?

> 
> > FWIW, even the bdrv_close_all() call during shutdown can delay things
> > for a considerable time if draining the backends isn't a quick op,
> > which could be the case if there are storage problems (blocked local
> > I/O, or interrupted network - rbd/ceph/nfs clients). So I'm not sure
> > that stopping migration is inherantly worse than what's already
> > possible with block cleanup, in terms of delaying things.
> > 
> > A slightly more hacky approach would be to pthread_cancel() all the
> > migration threads. Normally we'd never use pthread_cancel() as it
> > is incredibly hard to ensure all memory used by the threads is
> > freed. Since we're about to exit the process though, this cleanup
> > does not matter. The risk, however, is that one of the threads is
> > holding a mutex which then blocks the rest of the *cleanup functions,
> > so this still feels dangerous.
> > 
> > Overall to me a clean cancel & join of the migration threads feels
> > like the only safe option, unless we just remove all notion of
> > cleanup from QEMU & delete all the _cleanup functions in main()
> > and let the OS free all memory.
> 
> That's actually my preference; I think trying to do clean tidy ups
> here is very racy and doesn't gain much.  However, for things like
> storage there may be locks that have to be properly dropped and
> bitmaps and things to be stored/sync'd - so just exiting probably
> isn't safe either.

I'm unsure about whether I caught the whole idea but I feel like we
can't drop all the cleanup hooks since what if we want to do something
else than "freeing memories"?  Or anything that the OS can't do for us
but we want to try to do before the process quits.  If that operation
hangs we'll probably face a similar hang issue.

Regarding pthread_cancel() - it will only work if the thread reaches
cancellation points, right?  Then does it mean that it still cannot
guarantee the thread will quit very soon and we still have chance that
we'll wait forever when join()?  One major reason that the thread will
be waiting should be the migration streams but AFAIU shutdown() (as
Dave has mentioned) should solve this problem properly, then I'm
unsuer how pthread_cancel() can help much comparing to shutdown()...

My understanding (probably not correct, but I'll just speak loud...)
is that we will never have a way to guarantee a process to quit
cleanly all the 

[Qemu-devel] [QEMU-PPC] [PATCH 2/2] target/ppc/spapr: Add SPAPR_CAP_CCF_ASSIST

2019-02-28 Thread Suraj Jitindar Singh
Introduce a new spapr_cap SPAPR_CAP_CCF_ASSIST to be used to indicate
the requirement for a hw-assisted version of the count cache flush
workaround.

The count cache flush workaround is a software workaround which can be
used to flush the count cache on context switch. Some revisions of
hardware may have a hardware accelerated flush, in which case the
software flush can be shortened. This cap is used to set the
availability of such hardware acceleration for the count cache flush
routine.

The availability of such hardware acceleration is indicated by the
H_CPU_CHAR_BCCTR_FLUSH_ASSIST flag being set in the characteristics
returned from the KVM_PPC_GET_CPU_CHAR ioctl.

Signed-off-by: Suraj Jitindar Singh 
---
 hw/ppc/spapr.c |  2 ++
 hw/ppc/spapr_caps.c| 25 +
 hw/ppc/spapr_hcall.c   |  3 +++
 include/hw/ppc/spapr.h |  5 -
 target/ppc/kvm.c   | 14 ++
 target/ppc/kvm_ppc.h   |  6 ++
 6 files changed, 54 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 1df324379f..708e18dcdf 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2086,6 +2086,7 @@ static const VMStateDescription vmstate_spapr = {
 _spapr_cap_nested_kvm_hv,
 _spapr_dtb,
 _spapr_cap_large_decr,
+_spapr_cap_ccf_assist,
 NULL
 }
 };
@@ -4319,6 +4320,7 @@ static void spapr_machine_class_init(ObjectClass *oc, 
void *data)
 smc->default_caps.caps[SPAPR_CAP_HPT_MAXPAGESIZE] = 16; /* 64kiB */
 smc->default_caps.caps[SPAPR_CAP_NESTED_KVM_HV] = SPAPR_CAP_OFF;
 smc->default_caps.caps[SPAPR_CAP_LARGE_DECREMENTER] = SPAPR_CAP_ON;
+smc->default_caps.caps[SPAPR_CAP_CCF_ASSIST] = SPAPR_CAP_OFF;
 spapr_caps_add_properties(smc, _abort);
 smc->irq = _irq_xics;
 smc->dr_phb_enabled = true;
diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
index 74a48a423a..f03f2f64e7 100644
--- a/hw/ppc/spapr_caps.c
+++ b/hw/ppc/spapr_caps.c
@@ -436,6 +436,21 @@ static void cap_large_decr_cpu_apply(sPAPRMachineState 
*spapr,
 ppc_store_lpcr(cpu, lpcr);
 }
 
+static void cap_ccf_assist_apply(sPAPRMachineState *spapr, uint8_t val,
+ Error **errp)
+{
+uint8_t kvm_val = kvmppc_get_cap_count_cache_flush_assist();
+
+if (tcg_enabled() && val) {
+/* TODO - for now only allow broken for TCG */
+error_setg(errp,
+"Requested count cache flush assist capability level not supported by tcg, try 
cap-ccf-assist=off");
+} else if (kvm_enabled() && (val > kvm_val)) {
+error_setg(errp,
+"Requested count cache flush assist capability level not supported by kvm, try 
cap-ccf-assist=off");
+}
+}
+
 sPAPRCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
 [SPAPR_CAP_HTM] = {
 .name = "htm",
@@ -525,6 +540,15 @@ sPAPRCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
 .apply = cap_large_decr_apply,
 .cpu_apply = cap_large_decr_cpu_apply,
 },
+[SPAPR_CAP_CCF_ASSIST] = {
+.name = "ccf-assist",
+.description = "Count Cache Flush Assist via HW Instruction",
+.index = SPAPR_CAP_CCF_ASSIST,
+.get = spapr_cap_get_bool,
+.set = spapr_cap_set_bool,
+.type = "bool",
+.apply = cap_ccf_assist_apply,
+},
 };
 
 static sPAPRCapabilities default_caps_with_cpu(sPAPRMachineState *spapr,
@@ -659,6 +683,7 @@ SPAPR_CAP_MIG_STATE(sbbc, SPAPR_CAP_SBBC);
 SPAPR_CAP_MIG_STATE(ibs, SPAPR_CAP_IBS);
 SPAPR_CAP_MIG_STATE(nested_kvm_hv, SPAPR_CAP_NESTED_KVM_HV);
 SPAPR_CAP_MIG_STATE(large_decr, SPAPR_CAP_LARGE_DECREMENTER);
+SPAPR_CAP_MIG_STATE(ccf_assist, SPAPR_CAP_CCF_ASSIST);
 
 void spapr_caps_init(sPAPRMachineState *spapr)
 {
diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 4aa8036fc0..8bfdddc964 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -1693,6 +1693,7 @@ static target_ulong h_get_cpu_characteristics(PowerPCCPU 
*cpu,
 uint8_t safe_cache = spapr_get_cap(spapr, SPAPR_CAP_CFPC);
 uint8_t safe_bounds_check = spapr_get_cap(spapr, SPAPR_CAP_SBBC);
 uint8_t safe_indirect_branch = spapr_get_cap(spapr, SPAPR_CAP_IBS);
+uint8_t count_cache_flush_assist = spapr_get_cap(spapr, 
SPAPR_CAP_CCF_ASSIST);
 
 switch (safe_cache) {
 case SPAPR_CAP_WORKAROUND:
@@ -1733,6 +1734,8 @@ static target_ulong h_get_cpu_characteristics(PowerPCCPU 
*cpu,
 break;
 case SPAPR_CAP_WORKAROUND:
 behaviour |= H_CPU_BEHAV_FLUSH_COUNT_CACHE;
+if (count_cache_flush_assist)
+characteristics |= H_CPU_CHAR_BCCTR_FLUSH_ASSIST;
 break;
 default: /* broken */
 assert(safe_indirect_branch == SPAPR_CAP_BROKEN);
diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index 80d33ea284..493a44700d 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -76,8 +76,10 @@ typedef enum {
 #define SPAPR_CAP_NESTED_KVM_HV 0x07
 /* Large Decrementer */
 #define SPAPR_CAP_LARGE_DECREMENTER 0x08
+/* Count 

[Qemu-devel] [QEMU-PPC] [PATCH 1/2] target/ppc/spapr: Add workaround option to SPAPR_CAP_IBS

2019-02-28 Thread Suraj Jitindar Singh
The spapr_cap SPAPR_CAP_IBS is used to indicate the level of capability
for mitigations for indirect branch speculation. Currently the available
values are broken (default), fixed-ibs (fixed by serialising indirect
branches) and fixed-ccd (fixed by diabling the count cache).

Introduce a new value for this capability denoted workaround, meaning that
software can work around the issue by flushing the count cache on
context switch. This option is available if the hypervisor sets the
H_CPU_BEHAV_FLUSH_COUNT_CACHE flag in the cpu behaviours returned from
the KVM_PPC_GET_CPU_CHAR ioctl.

Signed-off-by: Suraj Jitindar Singh 
---
 hw/ppc/spapr_caps.c| 21 ++---
 hw/ppc/spapr_hcall.c   |  5 +
 include/hw/ppc/spapr.h |  7 +++
 target/ppc/kvm.c   |  8 +++-
 4 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
index 920224d0c2..74a48a423a 100644
--- a/hw/ppc/spapr_caps.c
+++ b/hw/ppc/spapr_caps.c
@@ -276,11 +276,13 @@ static void cap_safe_bounds_check_apply(sPAPRMachineState 
*spapr, uint8_t val,
 }
 
 sPAPRCapPossible cap_ibs_possible = {
-.num = 4,
+.num = 5,
 /* Note workaround only maintained for compatibility */
-.vals = {"broken", "workaround", "fixed-ibs", "fixed-ccd"},
-.help = "broken - no protection, fixed-ibs - indirect branch 
serialisation,"
-" fixed-ccd - cache count disabled",
+.vals = {"broken", "workaround", "fixed-ibs", "fixed-ccd", "fixed-na"},
+.help = "broken - no protection, workaround - count cache flush"
+", fixed-ibs - indirect branch serialisation,"
+" fixed-ccd - cache count disabled,"
+" fixed-na - fixed in hardware (no longer applicable)",
 };
 
 static void cap_safe_indirect_branch_apply(sPAPRMachineState *spapr,
@@ -288,15 +290,11 @@ static void 
cap_safe_indirect_branch_apply(sPAPRMachineState *spapr,
 {
 uint8_t kvm_val = kvmppc_get_cap_safe_indirect_branch();
 
-if (val == SPAPR_CAP_WORKAROUND) { /* Can only be Broken or Fixed */
-error_setg(errp,
-"Requested safe indirect branch capability level \"workaround\" not valid, try 
cap-ibs=%s",
-   cap_ibs_possible.vals[kvm_val]);
-} else if (tcg_enabled() && val) {
+if (tcg_enabled() && val) {
 /* TODO - for now only allow broken for TCG */
 error_setg(errp,
 "Requested safe indirect branch capability level not supported by tcg, try a 
different value for cap-ibs");
-} else if (kvm_enabled() && val && (val != kvm_val)) {
+} else if (kvm_enabled() && (val > kvm_val)) {
 error_setg(errp,
 "Requested safe indirect branch capability level not supported by kvm, try 
cap-ibs=%s",
cap_ibs_possible.vals[kvm_val]);
@@ -489,7 +487,8 @@ sPAPRCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
 [SPAPR_CAP_IBS] = {
 .name = "ibs",
 .description =
-"Indirect Branch Speculation (broken, fixed-ibs, fixed-ccd)",
+"Indirect Branch Speculation (broken, workaround, fixed-ibs,"
+"fixed-ccd, fixed-na)",
 .index = SPAPR_CAP_IBS,
 .get = spapr_cap_get_string,
 .set = spapr_cap_set_string,
diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 476bad6271..4aa8036fc0 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -1723,12 +1723,17 @@ static target_ulong 
h_get_cpu_characteristics(PowerPCCPU *cpu,
 }
 
 switch (safe_indirect_branch) {
+case SPAPR_CAP_FIXED_NA:
+break;
 case SPAPR_CAP_FIXED_CCD:
 characteristics |= H_CPU_CHAR_CACHE_COUNT_DIS;
 break;
 case SPAPR_CAP_FIXED_IBS:
 characteristics |= H_CPU_CHAR_BCCTRL_SERIALISED;
 break;
+case SPAPR_CAP_WORKAROUND:
+behaviour |= H_CPU_BEHAV_FLUSH_COUNT_CACHE;
+break;
 default: /* broken */
 assert(safe_indirect_branch == SPAPR_CAP_BROKEN);
 break;
diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index 3cd47fb6e8..80d33ea284 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -85,12 +85,17 @@ typedef enum {
 /* Bool Caps */
 #define SPAPR_CAP_OFF   0x00
 #define SPAPR_CAP_ON0x01
+
 /* Custom Caps */
+
+/* Generic */
 #define SPAPR_CAP_BROKEN0x00
 #define SPAPR_CAP_WORKAROUND0x01
 #define SPAPR_CAP_FIXED 0x02
+/* SPAPR_CAP_IBS (cap-ibs) */
 #define SPAPR_CAP_FIXED_IBS 0x02
 #define SPAPR_CAP_FIXED_CCD 0x03
+#define SPAPR_CAP_FIXED_NA  0x10 /* Lets leave a bit of a gap... */
 
 typedef struct sPAPRCapabilities sPAPRCapabilities;
 struct sPAPRCapabilities {
@@ -340,9 +345,11 @@ struct sPAPRMachineState {
 #define H_CPU_CHAR_HON_BRANCH_HINTS PPC_BIT(5)
 #define H_CPU_CHAR_THR_RECONF_TRIG  PPC_BIT(6)
 #define H_CPU_CHAR_CACHE_COUNT_DIS  PPC_BIT(7)
+#define H_CPU_CHAR_BCCTR_FLUSH_ASSIST   

Re: [Qemu-devel] [PATCH v6] i386, acpi: check acpi_memory_hotplug capacity in pre_plug

2019-02-28 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/20190301025140.4351-1-richardw.y...@linux.intel.com/



Hi,

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

Message-id: 20190301025140.4351-1-richardw.y...@linux.intel.com
Subject: [Qemu-devel] [PATCH v6] i386, acpi: check acpi_memory_hotplug capacity 
in pre_plug
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag]   
patchew/20190301025140.4351-1-richardw.y...@linux.intel.com -> 
patchew/20190301025140.4351-1-richardw.y...@linux.intel.com
Switched to a new branch 'test'
a0dcf8b1ea i386, acpi: check acpi_memory_hotplug capacity in pre_plug

=== OUTPUT BEGIN ===
ERROR: space required before the open parenthesis '('
#77: FILE: hw/acpi/piix4.c:382:
+if(!s->acpi_memory_hotplug.is_enabled) {

ERROR: code indent should never use tabs
#81: FILE: hw/acpi/piix4.c:386:
+^I}$

total: 2 errors, 0 warnings, 76 lines checked

Commit a0dcf8b1eac5 (i386, acpi: check acpi_memory_hotplug capacity in 
pre_plug) has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20190301025140.4351-1-richardw.y...@linux.intel.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

[Qemu-devel] [PATCH v6] i386, acpi: check acpi_memory_hotplug capacity in pre_plug

2019-02-28 Thread Wei Yang
Currently we do device realization like below:

   hotplug_handler_pre_plug()
   dc->realize()
   hotplug_handler_plug()

Before we do device realization and plug, we should allocate necessary
resources and check if memory-hotplug-support property is enabled.

At the piix4 and ich9, the memory-hotplug-support property is checked at
plug stage. This means that device has been realized and mapped into guest
address space 'pc_dimm_plug()' by the time acpi plug handler is called,
where it might fail and crash QEMU due to reaching g_assert_not_reached()
(piix4) or error_abort (ich9).

Fix it by checking if memory hotplug is enabled at pre_plug stage
where we can gracefully abort hotplug request.

Signed-off-by: Wei Yang 
CC: Igor Mammedov 
CC: Eric Blake 
Signed-off-by: Wei Yang 

---
v6:
   * fix the check in piix4_device_pre_plug_cb
v5:
   * rebase on latest upstream
   * remove a comment before hotplug_handler_pre_plug
   * fix alignment for ich9_pm_device_pre_plug_cb
v4:
   * fix code alignment of piix4_device_pre_plug_cb
v3:
   * replace acpi_memory_hotplug with memory-hotplug-support in changelog
   * fix code alignment of ich9_pm_device_pre_plug_cb
   * print which device type memory-hotplug-support is disabled in
 ich9_pm_device_pre_plug_cb and piix4_device_pre_plug_cb
v2:
   * (imamm...@redhat.com)
 - Almost the whole third paragraph
   * apply this change to ich9
   * use hotplug_handler_pre_plug() instead of open-coding check
---
 hw/acpi/ich9.c | 15 +--
 hw/acpi/piix4.c| 13 ++---
 hw/i386/pc.c   |  2 ++
 hw/isa/lpc_ich9.c  |  1 +
 include/hw/acpi/ich9.h |  2 ++
 5 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index c5d8646abc..e53dfe1ee3 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -483,13 +483,24 @@ void ich9_pm_add_properties(Object *obj, ICH9LPCPMRegs 
*pm, Error **errp)
  NULL);
 }
 
+void ich9_pm_device_pre_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev,
+Error **errp)
+{
+ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev);
+
+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM) &&
+!lpc->pm.acpi_memory_hotplug.is_enabled)
+error_setg(errp,
+   "memory hotplug is not enabled: %s.memory-hotplug-support "
+   "is not set", object_get_typename(OBJECT(lpc)));
+}
+
 void ich9_pm_device_plug_cb(HotplugHandler *hotplug_dev, DeviceState *dev,
 Error **errp)
 {
 ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev);
 
-if (lpc->pm.acpi_memory_hotplug.is_enabled &&
-object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
 if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
 nvdimm_acpi_plug_cb(hotplug_dev, dev);
 } else {
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index df8c0db909..068ee4e2a1 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -374,9 +374,17 @@ static void piix4_pm_powerdown_req(Notifier *n, void 
*opaque)
 static void piix4_device_pre_plug_cb(HotplugHandler *hotplug_dev,
 DeviceState *dev, Error **errp)
 {
+PIIX4PMState *s = PIIX4_PM(hotplug_dev);
+
 if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
 acpi_pcihp_device_pre_plug_cb(hotplug_dev, dev, errp);
-} else if (!object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM) &&
+} else if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
+if(!s->acpi_memory_hotplug.is_enabled) {
+error_setg(errp,
+"memory hotplug is not enabled: %s.memory-hotplug-support "
+"is not set", object_get_typename(OBJECT(s)));
+   }
+} else if (
!object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
 error_setg(errp, "acpi: device pre plug request for not supported"
" device type: %s", object_get_typename(OBJECT(dev)));
@@ -388,8 +396,7 @@ static void piix4_device_plug_cb(HotplugHandler 
*hotplug_dev,
 {
 PIIX4PMState *s = PIIX4_PM(hotplug_dev);
 
-if (s->acpi_memory_hotplug.is_enabled &&
-object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
 if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
 nvdimm_acpi_plug_cb(hotplug_dev, dev);
 } else {
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 578f772e7c..64d9e756fa 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -2083,6 +2083,8 @@ static void pc_memory_pre_plug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 return;
 }
 
+hotplug_handler_pre_plug(pcms->acpi_dev, dev, errp);
+
 if (is_nvdimm && !pcms->acpi_nvdimm_state.is_enabled) {
 error_setg(errp, "nvdimm is not enabled: missing 'nvdimm' in '-M'");
 return;
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index 

[Qemu-devel] [QEMU-PPC] [PATCH v3 3/4] target/ppc: Implement large decrementer support for KVM

2019-02-28 Thread Suraj Jitindar Singh
Implement support to allow KVM guests to take advantage of the large
decrementer introduced on POWER9 cpus.

To determine if the host can support the requested large decrementer
size, we check it matches that specified in the ibm,dec-bits device-tree
property. We also need to enable it in KVM by setting the LPCR_LD bit in
the LPCR. Note that to do this we need to try and set the bit, then read
it back to check the host allowed us to set it, if so we can use it but
if we were unable to set it the host cannot support it and we must not
use the large decrementer.

Signed-off-by: Suraj Jitindar Singh 
Signed-off-by: Cédric Le Goater 
---
 hw/ppc/spapr_caps.c  | 17 +++--
 target/ppc/kvm.c | 39 +++
 target/ppc/kvm_ppc.h | 12 
 3 files changed, 66 insertions(+), 2 deletions(-)

diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
index 32f68cbd9e..1e76685199 100644
--- a/hw/ppc/spapr_caps.c
+++ b/hw/ppc/spapr_caps.c
@@ -406,8 +406,16 @@ static void cap_large_decr_apply(sPAPRMachineState *spapr,
 "Large decrementer only supported on POWER9, try -cpu POWER9");
 return;
 }
-} else {
-error_setg(errp, "No large decrementer support, try 
cap-large-decr=off");
+} else if (kvm_enabled()) {
+int kvm_nr_bits = kvmppc_get_cap_large_decr();
+
+if (!kvm_nr_bits) {
+error_setg(errp, "No large decrementer support, try 
cap-large-decr=off");
+} else if (pcc->lrg_decr_bits != kvm_nr_bits) {
+error_setg(errp,
+"KVM large decrementer size (%d) differs to model (%d), try 
-cap-large-decr=off",
+kvm_nr_bits, pcc->lrg_decr_bits);
+}
 }
 }
 
@@ -418,6 +426,11 @@ static void cap_large_decr_cpu_apply(sPAPRMachineState 
*spapr,
 CPUPPCState *env = >env;
 target_ulong lpcr = env->spr[SPR_LPCR];
 
+if (kvm_enabled()) {
+if (kvmppc_enable_cap_large_decr(cpu, val))
+error_setg(errp, "No large decrementer support, try 
cap-large-decr=off");
+}
+
 if (val)
 lpcr |= LPCR_LD;
 else
diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index d01852fe31..3f650c8fc4 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -91,6 +91,7 @@ static int cap_ppc_safe_cache;
 static int cap_ppc_safe_bounds_check;
 static int cap_ppc_safe_indirect_branch;
 static int cap_ppc_nested_kvm_hv;
+static int cap_large_decr;
 
 static uint32_t debug_inst_opcode;
 
@@ -124,6 +125,7 @@ static bool kvmppc_is_pr(KVMState *ks)
 
 static int kvm_ppc_register_host_cpu_type(MachineState *ms);
 static void kvmppc_get_cpu_characteristics(KVMState *s);
+static int kvmppc_get_dec_bits(void);
 
 int kvm_arch_init(MachineState *ms, KVMState *s)
 {
@@ -151,6 +153,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
 cap_resize_hpt = kvm_vm_check_extension(s, KVM_CAP_SPAPR_RESIZE_HPT);
 kvmppc_get_cpu_characteristics(s);
 cap_ppc_nested_kvm_hv = kvm_vm_check_extension(s, KVM_CAP_PPC_NESTED_HV);
+cap_large_decr = kvmppc_get_dec_bits();
 /*
  * Note: setting it to false because there is not such capability
  * in KVM at this moment.
@@ -1927,6 +1930,15 @@ uint64_t kvmppc_get_clockfreq(void)
 return kvmppc_read_int_cpu_dt("clock-frequency");
 }
 
+static int kvmppc_get_dec_bits(void)
+{
+int nr_bits = kvmppc_read_int_cpu_dt("ibm,dec-bits");
+
+if (nr_bits > 0)
+return nr_bits;
+return 0;
+}
+
 static int kvmppc_get_pvinfo(CPUPPCState *env, struct kvm_ppc_pvinfo *pvinfo)
  {
  PowerPCCPU *cpu = ppc_env_get_cpu(env);
@@ -2442,6 +2454,33 @@ bool kvmppc_has_cap_spapr_vfio(void)
 return cap_spapr_vfio;
 }
 
+int kvmppc_get_cap_large_decr(void)
+{
+return cap_large_decr;
+}
+
+int kvmppc_enable_cap_large_decr(PowerPCCPU *cpu, int enable)
+{
+CPUState *cs = CPU(cpu);
+uint64_t lpcr;
+
+kvm_get_one_reg(cs, KVM_REG_PPC_LPCR_64, );
+/* Do we need to modify the LPCR? */
+if (!!(lpcr & LPCR_LD) != !!enable) {
+if (enable)
+lpcr |= LPCR_LD;
+else
+lpcr &= ~LPCR_LD;
+kvm_set_one_reg(cs, KVM_REG_PPC_LPCR_64, );
+kvm_get_one_reg(cs, KVM_REG_PPC_LPCR_64, );
+
+if (!!(lpcr & LPCR_LD) != !!enable)
+return -1;
+}
+
+return 0;
+}
+
 PowerPCCPUClass *kvm_ppc_get_host_cpu_class(void)
 {
 uint32_t host_pvr = mfpvr();
diff --git a/target/ppc/kvm_ppc.h b/target/ppc/kvm_ppc.h
index bdfaa4e70a..a79835bd14 100644
--- a/target/ppc/kvm_ppc.h
+++ b/target/ppc/kvm_ppc.h
@@ -64,6 +64,8 @@ int kvmppc_get_cap_safe_bounds_check(void);
 int kvmppc_get_cap_safe_indirect_branch(void);
 bool kvmppc_has_cap_nested_kvm_hv(void);
 int kvmppc_set_cap_nested_kvm_hv(int enable);
+int kvmppc_get_cap_large_decr(void);
+int kvmppc_enable_cap_large_decr(PowerPCCPU *cpu, int enable);
 int kvmppc_enable_hwrng(void);
 int kvmppc_put_books_sregs(PowerPCCPU *cpu);
 PowerPCCPUClass *kvm_ppc_get_host_cpu_class(void);
@@ -332,6 +334,16 

[Qemu-devel] [QEMU-PPC] [PATCH v3 2/4] target/ppc: Implement large decrementer support for TCG

2019-02-28 Thread Suraj Jitindar Singh
Prior to POWER9 the decrementer was a 32-bit register which decremented
with each tick of the timebase. From POWER9 onwards the decrementer can
be set to operate in a mode called large decrementer where it acts as a
n-bit decrementing register which is visible as a 64-bit register, that
is the value of the decrementer is sign extended to 64 bits (where n is
implementation dependant).

The mode in which the decrementer operates is controlled by the LPCR_LD
bit in the logical paritition control register (LPCR).

>From POWER9 onwards the HDEC (hypervisor decrementer) was enlarged to
h-bits, also sign extended to 64 bits (where h is implementation
dependant). Note this isn't configurable and is always enabled.

On POWER9 the large decrementer and hdec are both 56 bits, as
represented by the lrg_decr_bits cpu class property. Since they are the
same size we only add one property for now, which could be extended in
the case they ever differ in the future.

We also add the lrg_decr_bits property for POWER5+/7/8 since it is used
to determine the size of the hdec, which is only generated on the
POWER5+ processor and later. On these processors it is 32 bits.

Signed-off-by: Suraj Jitindar Singh 
Signed-off-by: Cédric Le Goater 
---
 hw/ppc/ppc.c| 85 -
 hw/ppc/spapr.c  |  8 
 hw/ppc/spapr_caps.c | 31 ++-
 target/ppc/cpu-qom.h|  1 +
 target/ppc/cpu.h|  8 ++--
 target/ppc/mmu-hash64.c |  2 +-
 target/ppc/translate.c  |  2 +-
 target/ppc/translate_init.inc.c |  4 ++
 8 files changed, 108 insertions(+), 33 deletions(-)

diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c
index d1e3d4cd20..9145aeddcb 100644
--- a/hw/ppc/ppc.c
+++ b/hw/ppc/ppc.c
@@ -744,11 +744,10 @@ bool ppc_decr_clear_on_delivery(CPUPPCState *env)
 return ((tb_env->flags & flags) == PPC_DECR_UNDERFLOW_TRIGGERED);
 }
 
-static inline uint32_t _cpu_ppc_load_decr(CPUPPCState *env, uint64_t next)
+static inline int64_t _cpu_ppc_load_decr(CPUPPCState *env, uint64_t next)
 {
 ppc_tb_t *tb_env = env->tb_env;
-uint32_t decr;
-int64_t diff;
+int64_t decr, diff;
 
 diff = next - qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
 if (diff >= 0) {
@@ -758,27 +757,47 @@ static inline uint32_t _cpu_ppc_load_decr(CPUPPCState 
*env, uint64_t next)
 }  else {
 decr = -muldiv64(-diff, tb_env->decr_freq, NANOSECONDS_PER_SECOND);
 }
-LOG_TB("%s: %08" PRIx32 "\n", __func__, decr);
+LOG_TB("%s: %016" PRIx64 "\n", __func__, decr);
 
 return decr;
 }
 
-uint32_t cpu_ppc_load_decr (CPUPPCState *env)
+target_ulong cpu_ppc_load_decr (CPUPPCState *env)
 {
 ppc_tb_t *tb_env = env->tb_env;
+uint64_t decr;
 
 if (kvm_enabled()) {
 return env->spr[SPR_DECR];
 }
 
-return _cpu_ppc_load_decr(env, tb_env->decr_next);
+decr = _cpu_ppc_load_decr(env, tb_env->decr_next);
+
+/*
+ * If large decrementer is enabled then the decrementer is signed extened
+ * to 64 bits, otherwise it is a 32 bit value.
+ */
+if (env->spr[SPR_LPCR] & LPCR_LD)
+return decr;
+return (uint32_t) decr;
 }
 
-uint32_t cpu_ppc_load_hdecr (CPUPPCState *env)
+target_ulong cpu_ppc_load_hdecr (CPUPPCState *env)
 {
+PowerPCCPU *cpu = ppc_env_get_cpu(env);
+PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
 ppc_tb_t *tb_env = env->tb_env;
+uint64_t hdecr;
 
-return _cpu_ppc_load_decr(env, tb_env->hdecr_next);
+hdecr =  _cpu_ppc_load_decr(env, tb_env->hdecr_next);
+
+/*
+ * If we have a large decrementer (POWER9 or later) then hdecr is sign
+ * extended to 64 bits, otherwise it is 32 bits.
+ */
+if (pcc->lrg_decr_bits > 32)
+return hdecr;
+return (uint32_t) hdecr;
 }
 
 uint64_t cpu_ppc_load_purr (CPUPPCState *env)
@@ -832,13 +851,21 @@ static void __cpu_ppc_store_decr(PowerPCCPU *cpu, 
uint64_t *nextp,
  QEMUTimer *timer,
  void (*raise_excp)(void *),
  void (*lower_excp)(PowerPCCPU *),
- uint32_t decr, uint32_t value)
+ target_ulong decr, target_ulong value,
+ int nr_bits)
 {
 CPUPPCState *env = >env;
 ppc_tb_t *tb_env = env->tb_env;
 uint64_t now, next;
+bool negative;
+
+/* Truncate value to decr_width and sign extend for simplicity */
+value &= ((1ULL << nr_bits) - 1);
+negative = !!(value & (1ULL << (nr_bits - 1)));
+if (negative)
+value |= (0xULL << nr_bits);
 
-LOG_TB("%s: %08" PRIx32 " => %08" PRIx32 "\n", __func__,
+LOG_TB("%s: " TARGET_FMT_lx " => " TARGET_FMT_lx "\n", __func__,
 decr, value);
 
 if (kvm_enabled()) {
@@ -860,15 +887,15 @@ static void __cpu_ppc_store_decr(PowerPCCPU *cpu, 
uint64_t *nextp,
  * an edge interrupt, so raise it here too.

[Qemu-devel] [QEMU-PPC] [PATCH v3 4/4] target/ppc/spapr: Enable the large decrementer for pseries-4.0

2019-02-28 Thread Suraj Jitindar Singh
Enable the large decrementer by default for the pseries-4.0 machine type.
It is disabled again by default_caps_with_cpu() for pre-POWER9 cpus
since they don't support the large decrementer.

Signed-off-by: Suraj Jitindar Singh 
---
 hw/ppc/spapr.c  | 3 ++-
 hw/ppc/spapr_caps.c | 5 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 9942b270df..1df324379f 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -4318,7 +4318,7 @@ static void spapr_machine_class_init(ObjectClass *oc, 
void *data)
 smc->default_caps.caps[SPAPR_CAP_IBS] = SPAPR_CAP_BROKEN;
 smc->default_caps.caps[SPAPR_CAP_HPT_MAXPAGESIZE] = 16; /* 64kiB */
 smc->default_caps.caps[SPAPR_CAP_NESTED_KVM_HV] = SPAPR_CAP_OFF;
-smc->default_caps.caps[SPAPR_CAP_LARGE_DECREMENTER] = SPAPR_CAP_OFF;
+smc->default_caps.caps[SPAPR_CAP_LARGE_DECREMENTER] = SPAPR_CAP_ON;
 spapr_caps_add_properties(smc, _abort);
 smc->irq = _irq_xics;
 smc->dr_phb_enabled = true;
@@ -4394,6 +4394,7 @@ static void spapr_machine_3_1_class_options(MachineClass 
*mc)
 mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("power8_v2.0");
 smc->update_dt_enabled = false;
 smc->dr_phb_enabled = false;
+smc->default_caps.caps[SPAPR_CAP_LARGE_DECREMENTER] = SPAPR_CAP_OFF;
 }
 
 DEFINE_SPAPR_MACHINE(3_1, "3.1", false);
diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
index 1e76685199..920224d0c2 100644
--- a/hw/ppc/spapr_caps.c
+++ b/hw/ppc/spapr_caps.c
@@ -536,6 +536,11 @@ static sPAPRCapabilities 
default_caps_with_cpu(sPAPRMachineState *spapr,
 
 caps = smc->default_caps;
 
+if (!ppc_type_check_compat(cputype, CPU_POWERPC_LOGICAL_3_00,
+   0, spapr->max_compat_pvr)) {
+caps.caps[SPAPR_CAP_LARGE_DECREMENTER] = SPAPR_CAP_OFF;
+}
+
 if (!ppc_type_check_compat(cputype, CPU_POWERPC_LOGICAL_2_07,
0, spapr->max_compat_pvr)) {
 caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_OFF;
-- 
2.13.6




[Qemu-devel] [QEMU-PPC] [PATCH v3 1/4] target/ppc/spapr: Add SPAPR_CAP_LARGE_DECREMENTER

2019-02-28 Thread Suraj Jitindar Singh
Add spapr_cap SPAPR_CAP_LARGE_DECREMENTER to be used to control the
availability of the large decrementer for a guest.

Signed-off-by: Suraj Jitindar Singh 
---
 hw/ppc/spapr.c |  2 ++
 hw/ppc/spapr_caps.c| 17 +
 include/hw/ppc/spapr.h |  5 -
 3 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 6f9208476a..d068982a5e 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2077,6 +2077,7 @@ static const VMStateDescription vmstate_spapr = {
 _spapr_irq_map,
 _spapr_cap_nested_kvm_hv,
 _spapr_dtb,
+_spapr_cap_large_decr,
 NULL
 }
 };
@@ -4309,6 +4310,7 @@ static void spapr_machine_class_init(ObjectClass *oc, 
void *data)
 smc->default_caps.caps[SPAPR_CAP_IBS] = SPAPR_CAP_BROKEN;
 smc->default_caps.caps[SPAPR_CAP_HPT_MAXPAGESIZE] = 16; /* 64kiB */
 smc->default_caps.caps[SPAPR_CAP_NESTED_KVM_HV] = SPAPR_CAP_OFF;
+smc->default_caps.caps[SPAPR_CAP_LARGE_DECREMENTER] = SPAPR_CAP_OFF;
 spapr_caps_add_properties(smc, _abort);
 smc->irq = _irq_xics;
 smc->dr_phb_enabled = true;
diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
index 64f98ae68d..3f90f5823e 100644
--- a/hw/ppc/spapr_caps.c
+++ b/hw/ppc/spapr_caps.c
@@ -390,6 +390,13 @@ static void cap_nested_kvm_hv_apply(sPAPRMachineState 
*spapr,
 }
 }
 
+static void cap_large_decr_apply(sPAPRMachineState *spapr,
+ uint8_t val, Error **errp)
+{
+if (val)
+error_setg(errp, "No large decrementer support, try 
cap-large-decr=off");
+}
+
 sPAPRCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
 [SPAPR_CAP_HTM] = {
 .name = "htm",
@@ -468,6 +475,15 @@ sPAPRCapabilityInfo capability_table[SPAPR_CAP_NUM] = {
 .type = "bool",
 .apply = cap_nested_kvm_hv_apply,
 },
+[SPAPR_CAP_LARGE_DECREMENTER] = {
+.name = "large-decr",
+.description = "Allow Large Decrementer",
+.index = SPAPR_CAP_LARGE_DECREMENTER,
+.get = spapr_cap_get_bool,
+.set = spapr_cap_set_bool,
+.type = "bool",
+.apply = cap_large_decr_apply,
+},
 };
 
 static sPAPRCapabilities default_caps_with_cpu(sPAPRMachineState *spapr,
@@ -596,6 +612,7 @@ SPAPR_CAP_MIG_STATE(cfpc, SPAPR_CAP_CFPC);
 SPAPR_CAP_MIG_STATE(sbbc, SPAPR_CAP_SBBC);
 SPAPR_CAP_MIG_STATE(ibs, SPAPR_CAP_IBS);
 SPAPR_CAP_MIG_STATE(nested_kvm_hv, SPAPR_CAP_NESTED_KVM_HV);
+SPAPR_CAP_MIG_STATE(large_decr, SPAPR_CAP_LARGE_DECREMENTER);
 
 void spapr_caps_init(sPAPRMachineState *spapr)
 {
diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index 86b0488d29..3cd47fb6e8 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -74,8 +74,10 @@ typedef enum {
 #define SPAPR_CAP_HPT_MAXPAGESIZE   0x06
 /* Nested KVM-HV */
 #define SPAPR_CAP_NESTED_KVM_HV 0x07
+/* Large Decrementer */
+#define SPAPR_CAP_LARGE_DECREMENTER 0x08
 /* Num Caps */
-#define SPAPR_CAP_NUM   (SPAPR_CAP_NESTED_KVM_HV + 1)
+#define SPAPR_CAP_NUM   (SPAPR_CAP_LARGE_DECREMENTER + 1)
 
 /*
  * Capability Values
@@ -843,6 +845,7 @@ extern const VMStateDescription vmstate_spapr_cap_cfpc;
 extern const VMStateDescription vmstate_spapr_cap_sbbc;
 extern const VMStateDescription vmstate_spapr_cap_ibs;
 extern const VMStateDescription vmstate_spapr_cap_nested_kvm_hv;
+extern const VMStateDescription vmstate_spapr_cap_large_decr;
 
 static inline uint8_t spapr_get_cap(sPAPRMachineState *spapr, int cap)
 {
-- 
2.13.6




Re: [Qemu-devel] [PATCH v5] i386, acpi: check acpi_memory_hotplug capacity in pre_plug

2019-02-28 Thread Wei Yang
On Thu, Feb 28, 2019 at 03:12:21PM +0100, Igor Mammedov wrote:
>On Thu, 28 Feb 2019 09:13:25 +0800
>Wei Yang  wrote:
>
>> On Wed, Feb 27, 2019 at 07:04:02PM +0100, Igor Mammedov wrote:
>> >On Mon, 25 Feb 2019 09:15:34 +0800
>> >Wei Yang  wrote:
>> >  
>> >> On Mon, Feb 25, 2019 at 09:07:08AM +0800, Wei Yang wrote:  
>> >> >Currently we do device realization like below:
>> >> >
>> >> >   hotplug_handler_pre_plug()
>> >> >   dc->realize()
>> >> >   hotplug_handler_plug()
>> >> >
>> >> >Before we do device realization and plug, we should allocate necessary
>> >> >resources and check if memory-hotplug-support property is enabled.
>> >> >
>> >> >At the piix4 and ich9, the memory-hotplug-support property is checked at
>> >> >plug stage. This means that device has been realized and mapped into 
>> >> >guest
>> >> >address space 'pc_dimm_plug()' by the time acpi plug handler is called,
>> >> >where it might fail and crash QEMU due to reaching g_assert_not_reached()
>> >> >(piix4) or error_abort (ich9).
>> >> >
>> >> >Fix it by checking if memory hotplug is enabled at pre_plug stage
>> >> >where we can gracefully abort hotplug request.
>> >> >
>> >> >Signed-off-by: Wei Yang 
>> >> >CC: Igor Mammedov 
>> >> >CC: Eric Blake 
>> >> >Signed-off-by: Wei Yang 
>> >> >
>> >> >---
>> >> >v5:
>> >> >   * rebase on latest upstream
>> >> >   * remove a comment before hotplug_handler_pre_plug
>> >> >   * fix alignment for ich9_pm_device_pre_plug_cb
>> >> >v4:
>> >> >   * fix code alignment of piix4_device_pre_plug_cb
>> >> >v3:
>> >> >   * replace acpi_memory_hotplug with memory-hotplug-support in changelog
>> >> >   * fix code alignment of ich9_pm_device_pre_plug_cb
>> >> >   * print which device type memory-hotplug-support is disabled in
>> >> > ich9_pm_device_pre_plug_cb and piix4_device_pre_plug_cb
>> >> >v2:
>> >> >   * (imamm...@redhat.com)
>> >> > - Almost the whole third paragraph
>> >> >   * apply this change to ich9
>> >> >   * use hotplug_handler_pre_plug() instead of open-coding check
>> >> >---
>> >> > hw/acpi/ich9.c | 15 +--
>> >> > hw/acpi/piix4.c| 13 ++---
>> >> > hw/i386/pc.c   |  2 ++
>> >> > hw/isa/lpc_ich9.c  |  1 +
>> >> > include/hw/acpi/ich9.h |  2 ++
>> >> > 5 files changed, 28 insertions(+), 5 deletions(-)
>> >> >
>> >> >diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
>> >> >index c5d8646abc..e53dfe1ee3 100644
>> >> >--- a/hw/acpi/ich9.c
>> >> >+++ b/hw/acpi/ich9.c
>> >> >@@ -483,13 +483,24 @@ void ich9_pm_add_properties(Object *obj, 
>> >> >ICH9LPCPMRegs *pm, Error **errp)
>> >> >  NULL);
>> >> > }
>> >> > 
>> >> >+void ich9_pm_device_pre_plug_cb(HotplugHandler *hotplug_dev, 
>> >> >DeviceState *dev,
>> >> >+Error **errp)
>> >> >+{
>> >> >+ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev);
>> >> >+
>> >> >+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM) &&
>> >> >+!lpc->pm.acpi_memory_hotplug.is_enabled)
>> >> >+error_setg(errp,
>> >> >+   "memory hotplug is not enabled: 
>> >> >%s.memory-hotplug-support "
>> >> >+   "is not set", object_get_typename(OBJECT(lpc)));
>> >> >+}
>> >> >+
>> >> > void ich9_pm_device_plug_cb(HotplugHandler *hotplug_dev, DeviceState 
>> >> > *dev,
>> >> > Error **errp)
>> >> > {
>> >> > ICH9LPCState *lpc = ICH9_LPC_DEVICE(hotplug_dev);
>> >> > 
>> >> >-if (lpc->pm.acpi_memory_hotplug.is_enabled &&
>> >> >-object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
>> >> >+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
>> >> > if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) {
>> >> > nvdimm_acpi_plug_cb(hotplug_dev, dev);
>> >> > } else {
>> >> >diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
>> >> >index df8c0db909..8b9654e437 100644
>> >> >--- a/hw/acpi/piix4.c
>> >> >+++ b/hw/acpi/piix4.c
>> >> >@@ -374,9 +374,16 @@ static void piix4_pm_powerdown_req(Notifier *n, 
>> >> >void *opaque)
>> >> > static void piix4_device_pre_plug_cb(HotplugHandler *hotplug_dev,
>> >> > DeviceState *dev, Error **errp)
>> >> 
>> >> Hmm, I found one interesting thing.
>> >> 
>> >> This function is introduced in
>> >> 
>> >> commit ec266f408882fd38475f72c4e864ed576228643b
>> >> pci/pcihp: perform check for bus capability in pre_plug handler
>> >> 
>> >> This is just implemented in piix4, but don't has the counterpart in ich9.
>> >> 
>> >> So I suggest to have a follow up patch to create the counterpart for ich9 
>> >> and
>> >> then apply this patch on top of that.  
>> >not sure what do you mean, could you be more specific?
>> >  
>> 
>> Let me reply here.
>> 
>> Everything starts from device_set_realized().
>> 
>> device_set_realized()
>>hotplug_handler_pre_plug()
>>dc->realize()
>>hotplug_handler_plug()
>> 
>> There is two choice of HotplugHandler :
>> 
>> * dev's bus 

[Qemu-devel] [PATCH] hw/arm/acpi: enable SHPC native hot plug

2019-02-28 Thread Heyi Guo
After the introduction of generic PCIe root port and PCIe-PCI bridge,
we will also have SHPC controller on ARM, so just enalbe SHPC native
hot plug.

Cc: Shannon Zhao 
Cc: Peter Maydell 
Cc: "Michael S. Tsirkin" 
Cc: Igor Mammedov 
Signed-off-by: Heyi Guo 
Signed-off-by: Heyi Guo 
---
 hw/arm/virt-acpi-build.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 04b62c7..7849ec5 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -265,7 +265,12 @@ static void acpi_dsdt_add_pci(Aml *scope, const 
MemMapEntry *memmap,
 aml_create_dword_field(aml_arg(3), aml_int(8), "CDW3"));
 aml_append(ifctx, aml_store(aml_name("CDW2"), aml_name("SUPP")));
 aml_append(ifctx, aml_store(aml_name("CDW3"), aml_name("CTRL")));
-aml_append(ifctx, aml_store(aml_and(aml_name("CTRL"), aml_int(0x1D), NULL),
+
+/*
+ * Allow OS control for all 5 features:
+ * PCIeHotplug SHPCHotplug PME AER PCIeCapability.
+ */
+aml_append(ifctx, aml_store(aml_and(aml_name("CTRL"), aml_int(0x1F), NULL),
 aml_name("CTRL")));
 
 ifctx1 = aml_if(aml_lnot(aml_equal(aml_arg(1), aml_int(0x1;
-- 
1.8.3.1




Re: [Qemu-devel] [PATCH v4 9/9] target/mips: Add support for DSPRAM

2019-02-28 Thread Philippe Mathieu-Daudé
Hi Yongbok, Aleksandar.

(I believe this is the v6 of this patched, included in a v4 series).

On 2/26/19 1:55 PM, Aleksandar Markovic wrote:
> From: Yongbok Kim 
> 
> The optional Data Scratch Pad RAM (DSPRAM) block provides a general scratch 
> pad RAM
> used for temporary storage of data. The DSPRAM provides a connection to 
> on-chip
> memory or memory-mapped registers, which are accessed in parallel with the L1 
> data
> cache to minimize access latency

I made some comments around, but the most important is simply:

"please move create_dspram() into mips_cps".

Now I also made high level review (long mail, sorry), thus I Cc'ed
Peter/Luc/Alistair who worked on multi-core object design in QEMU.

> 
> Signed-off-by: Yongbok Kim 
> Signed-off-by: Aleksandar Markovic 
> ---
>  default-configs/mips-softmmu-common.mak |  1 +
>  hw/mips/cps.c   |  3 ++-
>  hw/mips/mips_malta.c| 31 +++
>  hw/misc/Makefile.objs   |  1 +
>  include/hw/mips/cps.h   |  2 ++
>  target/mips/cpu.h   |  5 +
>  target/mips/internal.h  |  1 +
>  target/mips/op_helper.c | 10 ++
>  target/mips/translate.c |  8 
>  target/mips/translate_init.inc.c|  2 ++
>  10 files changed, 63 insertions(+), 1 deletion(-)
> 
> diff --git a/default-configs/mips-softmmu-common.mak 
> b/default-configs/mips-softmmu-common.mak
> index ded7498..d3f85b0 100644
> --- a/default-configs/mips-softmmu-common.mak
> +++ b/default-configs/mips-softmmu-common.mak
> @@ -35,6 +35,7 @@ CONFIG_ISA_TESTDEV=y
>  CONFIG_EMPTY_SLOT=y
>  CONFIG_MIPS_CPS=y
>  CONFIG_MIPS_ITU=y
> +CONFIG_MIPS_DSPRAM=y
>  CONFIG_I2C=y
>  CONFIG_R4K=y
>  CONFIG_MALTA=y
> diff --git a/hw/mips/cps.c b/hw/mips/cps.c
> index fc97f59..97e2232 100644
> --- a/hw/mips/cps.c
> +++ b/hw/mips/cps.c
> @@ -102,7 +102,8 @@ static void mips_cps_realize(DeviceState *dev, Error 
> **errp)
>  object_property_set_bool(OBJECT(>itu), saar_present, 
> "saar-present",
>   );
>  if (saar_present) {
> -qdev_prop_set_ptr(DEVICE(>itu), "saar", (void 
> *)>CP0_SAAR);
> +qdev_prop_set_ptr(DEVICE(>itu), "saar",
> +  (void *) >CP0_SAAR[0]);

No need to cast.

>  }
>  object_property_set_bool(OBJECT(>itu), true, "realized", );
>  if (err != NULL) {
> diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
> index 7a403ef..306d701 100644
> --- a/hw/mips/mips_malta.c
> +++ b/hw/mips/mips_malta.c
> @@ -1170,6 +1170,36 @@ static void create_cps(MaltaState *s, const char 
> *cpu_type,
>  *cbus_irq = NULL;
>  }
>  
> +static void create_dspram(void)
> +{
> +MIPSCPU *cpu = MIPS_CPU(first_cpu);
> +CPUMIPSState *env = >env;
> +bool dspram_present = (bool) env->dspramp;
> +Error *err = NULL;
> +
> +env->dspram = g_new0(MIPSDSPRAMState, 1);
> +
> +/* DSPRAM */
> +if (dspram_present) {
> +if (!(bool) env->saarp) {
> +error_report("%s: DSPRAM requires SAAR registers", __func__);
> +exit(1);

I recommend you to give this function a 'Error **errp' argument and set
errp here, and call it with errp=_fatal. This will help further
improvement of the DSPRAM as QOM and add qtesting.

> +}
> +object_initialize(env->dspram, sizeof(MIPSDSPRAMState),
> +  TYPE_MIPS_DSPRAM);
> +qdev_set_parent_bus(DEVICE(env->dspram), sysbus_get_default());
> +qdev_prop_set_ptr(DEVICE(env->dspram), "saar",
> +  (void *) >CP0_SAAR[1]);

Again, you can drop the cast.

> +object_property_set_bool(OBJECT(env->dspram), true, "realized", 
> );
> +if (err != NULL) {
> +error_report("%s: DSPRAM initialisation failed", __func__);
> +exit(1);

This now becomes error_propagate().

> +}
> +memory_region_add_subregion(get_system_memory(), 0,

Here you map the DSPRAM at 0x0 of the whole system memory... This is
currently not wrong, because the model is limited, but this doesn't
scale at all. Also it is not obvious base address 0x0 is the reset value
of the SAAR register. Can you add a comment?

> +sysbus_mmio_get_region(SYS_BUS_DEVICE(env->dspram), 0));
> +}
> +}
> +
>  static void mips_create_cpu(MaltaState *s, const char *cpu_type,
>  qemu_irq *cbus_irq, qemu_irq *i8259_irq)
>  {
> @@ -1178,6 +1208,7 @@ static void mips_create_cpu(MaltaState *s, const char 
> *cpu_type,
>  } else {
>  create_cpu_without_cps(cpu_type, cbus_irq, i8259_irq);
>  }
> +create_dspram();

Well, the DSPRAM is definitively not a machine feature, but a SoC one.

The current implementation doesn't differency between
Cluster/Core/Thread. QEMU is not very clear about that (yet).
Recently the TYPE_CPU_CLUSTER got introduced.


[Qemu-devel] [PATCH v5 0/2] CODING_STYLE: trivial update

2019-02-28 Thread Wei Yang
The first one is suggested by Igor Mammedov to provide rule for multiline
code.

The second is a trivial fix to make example code all indented with 4 spaces.

v5:
  * mostly address function variants
v4:
  * one exception case for function
v3:
  * fix typo in both changelog and example
v2:
  * adjust Patch 1 as suggested by Eric

Wei Yang (2):
  CODING_STYLE: specify the indent rule for multiline code
  CODING_STYLE: indent example code as all others

 CODING_STYLE | 47 +++
 1 file changed, 43 insertions(+), 4 deletions(-)

-- 
2.19.1




[Qemu-devel] [PATCH v5 2/2] CODING_STYLE: indent example code as all others

2019-02-28 Thread Wei Yang
All the example code are indented with four spaces except this one.

Fix this by adding four spaces here.

Signed-off-by: Wei Yang 
Reviewed-by: Eric Blake 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Igor Mammedov 
---
 CODING_STYLE | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/CODING_STYLE b/CODING_STYLE
index e175e6ea9a..465acf8bee 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -147,10 +147,10 @@ block to a separate function altogether.
 When comparing a variable for (in)equality with a constant, list the
 constant on the right, as in:
 
-if (a == 1) {
-/* Reads like: "If a equals 1" */
-do_something();
-}
+if (a == 1) {
+/* Reads like: "If a equals 1" */
+do_something();
+}
 
 Rationale: Yoda conditions (as in 'if (1 == a)') are awkward to read.
 Besides, good compilers already warn users when '==' is mis-typed as '=',
-- 
2.19.1




[Qemu-devel] [PATCH v5 1/2] CODING_STYLE: specify the indent rule for multiline code

2019-02-28 Thread Wei Yang
We didn't specify the indent rule for multiline code here, which may
mislead users. And in current code, the code use various styles.

Add this rule in CODING_STYLE to make sure this is clear to every one.

Signed-off-by: Wei Yang 
Suggested-by: Igor Mammedov 

---
v5:
   * different rules -> various styles
   * describe function variants separately
   * take struct out
v4:
   * widths -> width
   * add an exception example for function
v3:
   * misleading -> mislead
   * add comma after arg2 in example
v2:
   * rephrase changelog suggested by Eric Blake
 - remove one redundant line
 - fix some awkward grammar
 - add { ; at the end of example
---
 CODING_STYLE | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/CODING_STYLE b/CODING_STYLE
index ec075dedc4..e175e6ea9a 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -29,6 +29,45 @@ Spaces of course are superior to tabs because:
 
 Do not leave whitespace dangling off the ends of lines.
 
+1.1 Multiline Indent
+
+There are several places where indent is necessary:
+
+ - if/else
+ - while/for
+ - function definition & call
+
+When breaking up a long line to fit within line width, we need a proper indent
+for the following lines.
+
+In case of if/else, while/for, align the secondary lines just after the
+opening parenthesis of the first.
+
+For example:
+
+if (a == 1 &&
+b == 2) {
+
+while (a == 1 &&
+   b == 2) {
+
+In case of function, there are several variants:
+
+* 4 spaces indent from the beginning
+* align the secondary lines just after the opening parenthesis of the
+  first
+
+For example:
+
+do_something(x, y,
+z);
+
+do_something(x, y,
+ z);
+
+do_something(x, do_another(y,
+   z);
+
 2. Line width
 
 Lines should be 80 characters; try not to make them longer.
-- 
2.19.1




Re: [Qemu-devel] [PATCH v2 0/3] PCDIMM cleanup

2019-02-28 Thread Wei Yang
On Thu, Feb 28, 2019 at 02:57:07PM +0100, Igor Mammedov wrote:
>On Thu, 28 Feb 2019 08:46:10 +0800
>Wei Yang  wrote:
>
>> On Wed, Feb 27, 2019 at 06:27:49PM +0100, Igor Mammedov wrote:
>> >On Wed, 27 Feb 2019 13:59:20 +
>> >Wei Yang  wrote:
>> >  
>> >> On Wed, Feb 27, 2019 at 02:12:42PM +0100, Igor Mammedov wrote:  
>> >> >On Mon, 25 Feb 2019 12:47:14 +
>> >> >Wei Yang  wrote:
>> >> >
>> >> >> >> To me, this is a general rule for PCDIMM, they are hotpluggable.
>> >> >> >>   
>> >> >> >yes, PCDIMMs are hotpluggable but apci device (piix4pm/ich9/...) 
>> >> >> >handling hotplug
>> >> >> >should ignore any non-hotpluggable one. If you remove check and then 
>> >> >> >later
>> >> >> >someone else would add non-hotpluggable memory device or make 
>> >> >> >PC-DIMMs or its
>> >> >> >variant of non-hotpluggable one, acpi device handling will break.
>> >> >> >Hence I'd prefer to keep the check.  
>> >> >> >   
>> >> >> 
>> >> >> Ok, if we'd support un-hotpluggable mem device, we could retain this
>> >> >> check. But this maybe not a proper place.
>> >> >> 
>> >> >> Based on my understanding, at this point, every thing has been done
>> >> >> properly. If this check pass, we will send an acpi interrupt to notify
>> >> >> the guest. In case this is an un-hotpluggable device, every thing looks
>> >> >> good but no effect in guest. Because we skip the notification.
>> >> >> 
>> >> >> Maybe we need to move the check in pre-plug?
>> >> >And what would happen then and afterwards?
>> >> >
>> >> >Point is to make one of the handlers in chain to ignore plug event
>> >> >(i.e. do not generate SCI event) while the rest of handlers complete
>> >> >successfully mapping device in address space and whatever else.
>> >> >
>> >> 
>> >> This will have a well prepared device in system but guest is not
>> >> notified, right?  
>> >yes, it's theoretically possible to move check up the call stack
>> >to machine level and not call secondary hotplug handler on non hotplugged
>> >device but that again depends on what secondary hotplug handler does.
>> >I'd rather keep logic independent here unless there is good reason not
>> >to do so.
>> >
>> >  
>> >> My idea to move the check in pre-plug will result the qemu return when
>> >> it see no SCI event will be generated, so there is no device created.
>> >> 
>> >> I guess current behavior is a designed decision?  
>> >I'd say so.
>> >PS:
>> >QEMU's hotplug_hadler API is misnamed at this point as it handles both
>> >cold (basic device wiring) and hotplug (processing hotplug).
>> >Maybe we should rename it but I'm not irritated enough by it to do so.
>> >  
>> 
>> After re-read the code, I found something more.
>> 
>> First let me describe my understanding a bit.
>> 
>> To hotplug a device, several part are related:
>> 
>> * device itself
>> * machine's hotplug_handler
>> * bus's hotplug_handler
>> * acpi configuration
>> 
>> Currently, some checks are mixed, which makes the logic not that clear.
>> 
>> Let's come back to the problem in this thread.
>> 
>> The check in concern is the device's hotpluggable property. And when we look
>> into device_set_realized, this property is already checked at the very
>> beginning. This means when we go all the way down to acpi_memory_plug_cb(), 
>> if
>> this device is un-hotpluggable, it is must not a hotplugged device. And the
>> acpi_send_event() will not be triggered.
>> 
>> Based on my understanding, mdev->dimm and mdev->is_enabld looks still
>> necessary to be set for a un-hotplugged device. For both hotpluggable and
>> un-hotpluggable device. Skip these two steps if the device is not 
>> hotpluggable
>> looks not consistent with others?
>it might be inconsistent and broken since we don't actually have
>a nonhotpluggable memory device yet. But I'd would fix it when such device
>is added (it might depend on being added device whether it needs to be tracked
>by acpi memory hotplug path or if it uses other means in which case check
>is correct)
>

Ok, got your point.

-- 
Wei Yang
Help you, Help me



Re: [Qemu-devel] [PULL 40/50] spapr_events: add support for phb hotplug events

2019-02-28 Thread Michael Roth
Quoting Thomas Huth (2019-02-28 12:40:52)
> On 26/02/2019 05.52, David Gibson wrote:
> > From: Michael Roth 
> > 
> > Extend the existing EPOW event format we use for PCI
> > devices to emit PHB plug/unplug events.
> > 
> > Signed-off-by: Michael Roth 
> > Reviewed-by: David Gibson 
> > Signed-off-by: Greg Kurz 
> > Message-Id: 
> > <155059671405.1466090.535964535260503283.st...@bahia.lab.toulouse-stg.fr.ibm.com>
> > Signed-off-by: David Gibson 
> > ---
> >  hw/ppc/spapr_events.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/hw/ppc/spapr_events.c b/hw/ppc/spapr_events.c
> > index b9c7ecb9e9..ab9a1f0063 100644
> > --- a/hw/ppc/spapr_events.c
> > +++ b/hw/ppc/spapr_events.c
> > @@ -526,6 +526,9 @@ static void spapr_hotplug_req_event(uint8_t hp_id, 
> > uint8_t hp_action,
> >  case SPAPR_DR_CONNECTOR_TYPE_CPU:
> >  hp->hotplug_type = RTAS_LOG_V6_HP_TYPE_CPU;
> >  break;
> > +case SPAPR_DR_CONNECTOR_TYPE_PHB:
> > +hp->hotplug_type = RTAS_LOG_V6_HP_TYPE_PHB;
> > +break;
> >  default:
> >  /* we shouldn't be signaling hotplug events for resources
> >   * that don't support them
> 
> I think this patch (or something else in this PULL request) broke CPU
> hot-plugging with older machine types:
> 
> $ QTEST_QEMU_BINARY=ppc64-softmmu/qemu-system-ppc64 ./tests/cpu-plug-test 
> -m=slow
> /ppc64/cpu-plug/pseries-3.1/device-add/2x3x1=6: OK
> /ppc64/cpu-plug/pseries-2.12-sxxm/device-add/2x3x1=6: OK
> /ppc64/cpu-plug/pseries-3.0/device-add/2x3x1=6: OK
> /ppc64/cpu-plug/pseries-2.10/device-add/2x3x1=6: OK
> /ppc64/cpu-plug/pseries-2.11/device-add/2x3x1=6: OK
> /ppc64/cpu-plug/pseries-2.12/device-add/2x3x1=6: OK
> /ppc64/cpu-plug/pseries-2.9/device-add/2x3x1=6: OK
> /ppc64/cpu-plug/pseries-2.7/device-add/2x3x1=6: **
> ERROR:/home/thuth/devel/qemu/hw/ppc/spapr_events.c:313:rtas_event_log_to_source:
>  assertion failed: (source->enabled)
> Broken pipe
> /home/thuth/devel/qemu/tests/libqtest.c:143: kill_qemu() detected QEMU death 
> from signal 6 (Aborted) (core dumped)
> Aborted (core dumped)
> 
> Could you please have a look?

Bisected to:

  commit b8165118f52ce5ee88565d3cec83d30374efdc96
  Author: David Hildenbrand 
  Date:   Mon Feb 18 10:21:58 2019 +0100
  
  spapr: support memory unplug for qtest
  
  Fake availability of OV5_HP_EVT, so we can test memory unplug in qtest.

Which makes sense since OV5_HP_EVT assumes that
spapr->spapr->use_hotplug_event_source == true, which isn't the default for
2.7 and below.

If I revert that I think I hit the bug it was meant to fix:

  mdroth@sif:~/w/qemu-build3$ make V=1 check-qtest-ppc64
  ...
  PASS 1 device-plug-test /ppc64/device-plug/pci-unplug-request
  PASS 2 device-plug-test /ppc64/device-plug/spapr-cpu-unplug-request
  **
  ERROR:/home/mdroth/w/qemu3.git/tests/device-plug-test.c:28:device_del_finish: 
assertion failed: (qdict_haskey(resp, "return"))
  ERROR - Bail out! 
ERROR:/home/mdroth/w/qemu3.git/tests/device-plug-test.c:28:device_del_finish: 
assertion failed: (qdict_haskey(resp, "return"))
  Aborted (core dumped)
  /home/mdroth/w/qemu3.git/tests/Makefile.include:875: recipe for target 
'check-qtest-ppc64' failed
  make: *** [check-qtest-ppc64] Error 1
  mdroth@sif:~/w/qemu-build3$

Which is probably due to this check in spapr_machine_device_unplug_request():

if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
if (spapr_ovec_test(sms->ov5_cas, OV5_HP_EVT)) {
spapr_memory_unplug_request(hotplug_dev, dev, errp);
} else {
/* NOTE: this means there is a window after guest reset, prior to
 * CAS negotiation, where unplug requests will fail due to the
 * capability not being detected yet. This is a bit different than
 * the case with PCI unplug, where the events will be queued and
 * eventually handled by the guest after boot
 */
error_setg(errp, "Memory hot unplug not supported for this guest");
}



This spapr-cpu-unplug-request test is failing because
spapr_ovec_test(sms->ov5_cas, OV5_HP_EVT) relies on the CAS-negotiated OV5 bit,
which wouldn't have happened with qtest. If we want to make these tests run in
this scenario we probably need a different approach than the original patch.

> 
>  Thomas
> 



Re: [Qemu-devel] [PATCH v4 1/2] CODING_STYLE: specify the indent rule for multiline code

2019-02-28 Thread Wei Yang
On Thu, Feb 28, 2019 at 03:36:14PM +0100, Igor Mammedov wrote:
>On Mon, 25 Feb 2019 09:25:29 +0800
>Wei Yang  wrote:
>
>> We didn't specify the indent rule for multiline code here, which may
>> mislead users. And in current code, the code use different rules.
>diffrent from what? I'd use "various styles"
>
>> 
>> Add this rule in CODING_STYLE to make sure this is clear to every one.
>> 
>> Signed-off-by: Wei Yang 
>> Suggested-by: Igor Mammedov 
>> 
>> ---
>> v4:
>>* widths -> width
>>* add an exception example for function
>> v3:
>>* misleading -> mislead
>>* add comma after arg2 in example
>> v2:
>>* rephrase changelog suggested by Eric Blake
>>  - remove one redundant line
>>  - fix some awkward grammar
>>  - add { ; at the end of example
>> ---
>>  CODING_STYLE | 29 +
>>  1 file changed, 29 insertions(+)
>> 
>> diff --git a/CODING_STYLE b/CODING_STYLE
>> index ec075dedc4..1bccf4f865 100644
>> --- a/CODING_STYLE
>> +++ b/CODING_STYLE
>> @@ -29,6 +29,35 @@ Spaces of course are superior to tabs because:
>>  
>>  Do not leave whitespace dangling off the ends of lines.
>>  
>> +1.1 Multiline Indent
>> +
>> +There are several places where indent is necessary:
>> +
>> + - struct definition
>> + - if/else
>> + - while/for
>> + - function definition & call
>> +
>> +When breaking up a long line to fit within line width, align the secondary
>> +lines just after the opening parenthesis of the first.
> Probably it's not true for struct/function, they could use 4 spaces indent
> relative to previous line. I'd drop struct as it just follow generic block
> 4 spaces rule. And describe possible function variants separately
>

That sounds reasonable. Let me adjust this.

>
>> +
>> +For example:
>> +
>> +if (a == 1 &&
>> +b == 2) {
>> +
>> +while (a == 1 &&
>> +   b == 2) {
>> +
>> +do_something(arg1, arg2,
>> + arg3);
>> +
>> +One exception for function is indenting following lines relative to function
>> +name start:
>it's not really exception and used not only with functions, it's basically
>generic 4 spaces indent. Another variant I've seen used is
>foo(x, y(z,
> h);
>and variations of that
>
>
>> +
>> +do_something(arg1, arg2,
>> +arg3);
>> +
>>  2. Line width
>>  
>>  Lines should be 80 characters; try not to make them longer.

-- 
Wei Yang
Help you, Help me



Re: [Qemu-devel] Qemu build failure with uninitialized variables when "-Wmaybe-uninitialized" is open

2019-02-28 Thread Wei, Danmei
I got it. Many thanks.

Thanks,
Danmei

-Original Message-
From: Thomas Huth [mailto:th...@redhat.com] 
Sent: Friday, March 1, 2019 12:42 AM
To: Wei, Danmei ; qemu-devel@nongnu.org
Cc: Hao, Xudong 
Subject: Re: [Qemu-devel] Qemu build failure with uninitialized variables when 
"-Wmaybe-uninitialized" is open

On 28/02/2019 04.00, Wei, Danmei wrote:
> Hi,
> 
> When we build qemu with "-Wmaybe-uninitialized" on, and got the following 
> error information.
>   CC  qobject/json-streamer.o
>   CC  qobject/json-parser.o
>   CC  qobject/block-qdict.o
> qobject/block-qdict.c: In function 'qdict_array_split':
> qobject/block-qdict.c:259:25: error: 'subqdict' may be used uninitialized in 
> this function [-Werror=maybe-uninitialized]
>  qlist_append_obj(*dst, subqobj ?: QOBJECT(subqdict));
>  ^
> cc1: all warnings being treated as errors
> make: *** [qobject/block-qdict.o] Error 1
> 
> It is because of the uninitialized variable subqdict function 
> qdict_array_split.
> Thanks to confirm it.
> 
> Below is the ENV Setting:
> OS: RHEL OS 7.6
> Qemu Version: commit c102d9471f8f02d9fbea72ec4505d7089173f470
> CFLAGS Setting in env: export CFLAGS="-g -O3 -Wmaybe-uninitialized"

Don't build QEMU with -O3 and -Wmaybe-uninitialized and -Werror together. -O3 
produces lots of false warnings with -Wmaybe-uninitialized, so we currently 
don't support building QEMU with that combination. You should at least add 
"-Wno-error=maybe-uninitialized" if you want to build that way.

 Thomas


Re: [Qemu-devel] [PATCH v2 07/16] tests/tcg/xtensa: enable system tests

2019-02-28 Thread Max Filippov
Hi Alex,

On Thu, Feb 28, 2019 at 12:25 PM Alex Bennée  wrote:

[...]

> diff --git a/tests/tcg/xtensa/Makefile.softmmu-target 
> b/tests/tcg/xtensa/Makefile.softmmu-target
> new file mode 100644
> index 00..1a4014506f
> --- /dev/null
> +++ b/tests/tcg/xtensa/Makefile.softmmu-target
> @@ -0,0 +1,40 @@
> +#
> +# Xtensa softmmu tests
> +#
> +
> +ifneq ($(TARGET_WORDS_BIGENDIAN),y)

I've recently posted a series that makes it possible to run
TCG tests on wider variety of xtensa cores, including
big-endian cores:
http://lists.nongnu.org/archive/html/qemu-devel/2019-02/msg04843.html

-- 
Thanks.
-- Max



Re: [Qemu-devel] [PATCH v2 07/16] tests/tcg/xtensa: enable system tests

2019-02-28 Thread Philippe Mathieu-Daudé
On 3/1/19 12:24 AM, Max Filippov wrote:
> On Thu, Feb 28, 2019 at 2:54 PM Philippe Mathieu-Daudé
>  wrote:
> 
>> BTW is this simulator downloadable? I see the Zephyr project also uses
>> it, and I looked for it on https://ip.cadence.com/swdev but couldnt find
>> a (public) link.
> 
> There's a site https://www.tensilicatools.com/
> with tools for various end-user-programmable xtensa cores,
> but I'm pretty sure that neither dc232b nor dc233c are available
> there.

Thanks!

Phil.



Re: [Qemu-devel] [PATCH v2 07/16] tests/tcg/xtensa: enable system tests

2019-02-28 Thread Max Filippov
On Thu, Feb 28, 2019 at 2:54 PM Philippe Mathieu-Daudé
 wrote:
> Max: I think it should be quite easy to port your simulator to Alex's
> new Makefile.

I agree.

> BTW is this simulator downloadable? I see the Zephyr project also uses
> it, and I looked for it on https://ip.cadence.com/swdev but couldnt find
> a (public) link.

There's a site https://www.tensilicatools.com/
with tools for various end-user-programmable xtensa cores,
but I'm pretty sure that neither dc232b nor dc233c are available
there.

-- 
Thanks.
-- Max



Re: [Qemu-devel] [PATCH v2 10/16] tests/tcg: split cris tests into bare and libc directories

2019-02-28 Thread Philippe Mathieu-Daudé
On 3/1/19 12:07 AM, Philippe Mathieu-Daudé wrote:
> Hi Alex,
> 
> On 2/28/19 9:25 PM, Alex Bennée wrote:
>> Bare tests are standalone assembly tests that don't require linking to
>> any libc and hence can be built with kernel only compilers. The libc
>> tests need a compiler capable of building properly linked userspace
>> binaries. As we don't have such a cross compiler at the moment we
>> won't be building those tests.
>>
>> Signed-off-by: Alex Bennée 
>>
>> ---
>> v2
>>   - split between bare/libc instead of system/user
>> ---
>>  tests/tcg/cris/{ => bare}/check_addcv17.s |  0
>>  tests/tcg/cris/{ => bare}/check_addi.s|  0
>>  tests/tcg/cris/{ => bare}/check_addiv32.s |  0
>>  tests/tcg/cris/{ => bare}/check_addm.s|  0
>>  tests/tcg/cris/{ => bare}/check_addq.s|  0
>>  tests/tcg/cris/{ => bare}/check_addr.s|  0
>>  tests/tcg/cris/{ => bare}/check_addxc.s   |  0
>>  tests/tcg/cris/{ => bare}/check_addxm.s   |  0
>>  tests/tcg/cris/{ => bare}/check_addxr.s   |  0
>>  tests/tcg/cris/{ => bare}/check_andc.s|  0
>>  tests/tcg/cris/{ => bare}/check_andm.s|  0
>>  tests/tcg/cris/{ => bare}/check_andq.s|  0
>>  tests/tcg/cris/{ => bare}/check_andr.s|  0
>>  tests/tcg/cris/{ => bare}/check_asr.s |  0
>>  tests/tcg/cris/{ => bare}/check_ba.s  |  0
>>  tests/tcg/cris/{ => bare}/check_bas.s |  0
>>  tests/tcg/cris/{ => bare}/check_bcc.s |  0
>>  tests/tcg/cris/{ => bare}/check_boundc.s  |  0
>>  tests/tcg/cris/{ => bare}/check_boundr.s  |  0
>>  tests/tcg/cris/{ => bare}/check_btst.s|  0
>>  tests/tcg/cris/{ => bare}/check_clearfv32.s   |  0
>>  tests/tcg/cris/{ => bare}/check_clrjmp1.s |  0
>>  tests/tcg/cris/{ => bare}/check_cmp-2.s   |  0
>>  tests/tcg/cris/{ => bare}/check_cmpc.s|  0
>>  tests/tcg/cris/{ => bare}/check_cmpm.s|  0
>>  tests/tcg/cris/{ => bare}/check_cmpq.s|  0
>>  tests/tcg/cris/{ => bare}/check_cmpr.s|  0
>>  tests/tcg/cris/{ => bare}/check_cmpxc.s   |  0
>>  tests/tcg/cris/{ => bare}/check_cmpxm.s   |  0
>>  tests/tcg/cris/{ => bare}/check_dstep.s   |  0
>>  tests/tcg/cris/{ => bare}/check_jsr.s |  0
>>  tests/tcg/cris/{ => bare}/check_lapc.s|  0
>>  tests/tcg/cris/{ => bare}/check_lsl.s |  0
>>  tests/tcg/cris/{ => bare}/check_lsr.s |  0
>>  tests/tcg/cris/{ => bare}/check_mcp.s |  0
>>  tests/tcg/cris/{ => bare}/check_movdelsr1.s   |  0
>>  tests/tcg/cris/{ => bare}/check_movecr.s  |  0
>>  tests/tcg/cris/{ => bare}/check_movei.s   |  0
>>  tests/tcg/cris/{ => bare}/check_movemr.s  |  0
>>  tests/tcg/cris/{ => bare}/check_movemrv32.s   |  0
>>  tests/tcg/cris/{ => bare}/check_mover.s   |  0
>>  tests/tcg/cris/{ => bare}/check_moverm.s  |  0
>>  tests/tcg/cris/{ => bare}/check_movmp.s   |  0
>>  tests/tcg/cris/{ => bare}/check_movpmv32.s|  0
>>  tests/tcg/cris/{ => bare}/check_movpr.s   |  0
>>  tests/tcg/cris/{ => bare}/check_movprv32.s|  0
>>  tests/tcg/cris/{ => bare}/check_movscr.s  |  0
>>  tests/tcg/cris/{ => bare}/check_movsm.s   |  0
>>  tests/tcg/cris/{ => bare}/check_movsr.s   |  0
>>  tests/tcg/cris/{ => bare}/check_movucr.s  |  0
>>  tests/tcg/cris/{ => bare}/check_movum.s   |  0
>>  tests/tcg/cris/{ => bare}/check_movur.s   |  0
>>  tests/tcg/cris/{ => bare}/check_mulv32.s  |  0
>>  tests/tcg/cris/{ => bare}/check_mulx.s|  0
>>  tests/tcg/cris/{ => bare}/check_neg.s |  0
>>  tests/tcg/cris/{ => bare}/check_not.s |  0
>>  tests/tcg/cris/{ => bare}/check_orc.s |  0
>>  tests/tcg/cris/{ => bare}/check_orm.s |  0
>>  tests/tcg/cris/{ => bare}/check_orq.s |  0
>>  tests/tcg/cris/{ => bare}/check_orr.s |  0
>>  tests/tcg/cris/{ => bare}/check_ret.s |  0
>>  tests/tcg/cris/{ => bare}/check_scc.s |  0
>>  tests/tcg/cris/{ => bare}/check_subc.s|  0
>>  tests/tcg/cris/{ => bare}/check_subm.s|  0
>>  tests/tcg/cris/{ => bare}/check_subq.s|  0
>>  tests/tcg/cris/{ => bare}/check_subr.s|  0
>>  tests/tcg/cris/{ => bare}/check_xarith.s  |  0
>>  tests/tcg/cris/{ => bare}/crt.s   |  0
>>  tests/tcg/cris/{ => bare}/sys.c   |  0
> 
> Here you move the current sys.c which includes stdio/stdlib/unistd to
> bare ...
> 
>>  tests/tcg/cris/{ => bare}/testutils.inc   |  0
>>  tests/tcg/cris/{ => libc}/check_abs.c |  0
>>  tests/tcg/cris/{ => libc}/check_addc.c|  0
>>  tests/tcg/cris/{ => libc}/check_addcm.c   |  0
>>  tests/tcg/cris/{ => libc}/check_addo.c|  0
>>  tests/tcg/cris/{ => libc}/check_addoq.c   |  0
>>  tests/tcg/cris/{ => libc}/check_bound.c   |  0
>>  tests/tcg/cris/{ => libc}/check_ftag.c|  0
>>  .../{ => libc}/check_gcctorture_pr28634-1.c   |  0
>>  .../{ => libc}/check_gcctorture_pr28634.c |  0
>>  .../{ => 

Re: [Qemu-devel] [PATCH v2 10/16] tests/tcg: split cris tests into bare and libc directories

2019-02-28 Thread Philippe Mathieu-Daudé
Hi Alex,

On 2/28/19 9:25 PM, Alex Bennée wrote:
> Bare tests are standalone assembly tests that don't require linking to
> any libc and hence can be built with kernel only compilers. The libc
> tests need a compiler capable of building properly linked userspace
> binaries. As we don't have such a cross compiler at the moment we
> won't be building those tests.
> 
> Signed-off-by: Alex Bennée 
> 
> ---
> v2
>   - split between bare/libc instead of system/user
> ---
>  tests/tcg/cris/{ => bare}/check_addcv17.s |  0
>  tests/tcg/cris/{ => bare}/check_addi.s|  0
>  tests/tcg/cris/{ => bare}/check_addiv32.s |  0
>  tests/tcg/cris/{ => bare}/check_addm.s|  0
>  tests/tcg/cris/{ => bare}/check_addq.s|  0
>  tests/tcg/cris/{ => bare}/check_addr.s|  0
>  tests/tcg/cris/{ => bare}/check_addxc.s   |  0
>  tests/tcg/cris/{ => bare}/check_addxm.s   |  0
>  tests/tcg/cris/{ => bare}/check_addxr.s   |  0
>  tests/tcg/cris/{ => bare}/check_andc.s|  0
>  tests/tcg/cris/{ => bare}/check_andm.s|  0
>  tests/tcg/cris/{ => bare}/check_andq.s|  0
>  tests/tcg/cris/{ => bare}/check_andr.s|  0
>  tests/tcg/cris/{ => bare}/check_asr.s |  0
>  tests/tcg/cris/{ => bare}/check_ba.s  |  0
>  tests/tcg/cris/{ => bare}/check_bas.s |  0
>  tests/tcg/cris/{ => bare}/check_bcc.s |  0
>  tests/tcg/cris/{ => bare}/check_boundc.s  |  0
>  tests/tcg/cris/{ => bare}/check_boundr.s  |  0
>  tests/tcg/cris/{ => bare}/check_btst.s|  0
>  tests/tcg/cris/{ => bare}/check_clearfv32.s   |  0
>  tests/tcg/cris/{ => bare}/check_clrjmp1.s |  0
>  tests/tcg/cris/{ => bare}/check_cmp-2.s   |  0
>  tests/tcg/cris/{ => bare}/check_cmpc.s|  0
>  tests/tcg/cris/{ => bare}/check_cmpm.s|  0
>  tests/tcg/cris/{ => bare}/check_cmpq.s|  0
>  tests/tcg/cris/{ => bare}/check_cmpr.s|  0
>  tests/tcg/cris/{ => bare}/check_cmpxc.s   |  0
>  tests/tcg/cris/{ => bare}/check_cmpxm.s   |  0
>  tests/tcg/cris/{ => bare}/check_dstep.s   |  0
>  tests/tcg/cris/{ => bare}/check_jsr.s |  0
>  tests/tcg/cris/{ => bare}/check_lapc.s|  0
>  tests/tcg/cris/{ => bare}/check_lsl.s |  0
>  tests/tcg/cris/{ => bare}/check_lsr.s |  0
>  tests/tcg/cris/{ => bare}/check_mcp.s |  0
>  tests/tcg/cris/{ => bare}/check_movdelsr1.s   |  0
>  tests/tcg/cris/{ => bare}/check_movecr.s  |  0
>  tests/tcg/cris/{ => bare}/check_movei.s   |  0
>  tests/tcg/cris/{ => bare}/check_movemr.s  |  0
>  tests/tcg/cris/{ => bare}/check_movemrv32.s   |  0
>  tests/tcg/cris/{ => bare}/check_mover.s   |  0
>  tests/tcg/cris/{ => bare}/check_moverm.s  |  0
>  tests/tcg/cris/{ => bare}/check_movmp.s   |  0
>  tests/tcg/cris/{ => bare}/check_movpmv32.s|  0
>  tests/tcg/cris/{ => bare}/check_movpr.s   |  0
>  tests/tcg/cris/{ => bare}/check_movprv32.s|  0
>  tests/tcg/cris/{ => bare}/check_movscr.s  |  0
>  tests/tcg/cris/{ => bare}/check_movsm.s   |  0
>  tests/tcg/cris/{ => bare}/check_movsr.s   |  0
>  tests/tcg/cris/{ => bare}/check_movucr.s  |  0
>  tests/tcg/cris/{ => bare}/check_movum.s   |  0
>  tests/tcg/cris/{ => bare}/check_movur.s   |  0
>  tests/tcg/cris/{ => bare}/check_mulv32.s  |  0
>  tests/tcg/cris/{ => bare}/check_mulx.s|  0
>  tests/tcg/cris/{ => bare}/check_neg.s |  0
>  tests/tcg/cris/{ => bare}/check_not.s |  0
>  tests/tcg/cris/{ => bare}/check_orc.s |  0
>  tests/tcg/cris/{ => bare}/check_orm.s |  0
>  tests/tcg/cris/{ => bare}/check_orq.s |  0
>  tests/tcg/cris/{ => bare}/check_orr.s |  0
>  tests/tcg/cris/{ => bare}/check_ret.s |  0
>  tests/tcg/cris/{ => bare}/check_scc.s |  0
>  tests/tcg/cris/{ => bare}/check_subc.s|  0
>  tests/tcg/cris/{ => bare}/check_subm.s|  0
>  tests/tcg/cris/{ => bare}/check_subq.s|  0
>  tests/tcg/cris/{ => bare}/check_subr.s|  0
>  tests/tcg/cris/{ => bare}/check_xarith.s  |  0
>  tests/tcg/cris/{ => bare}/crt.s   |  0
>  tests/tcg/cris/{ => bare}/sys.c   |  0

Here you move the current sys.c which includes stdio/stdlib/unistd to
bare ...

>  tests/tcg/cris/{ => bare}/testutils.inc   |  0
>  tests/tcg/cris/{ => libc}/check_abs.c |  0
>  tests/tcg/cris/{ => libc}/check_addc.c|  0
>  tests/tcg/cris/{ => libc}/check_addcm.c   |  0
>  tests/tcg/cris/{ => libc}/check_addo.c|  0
>  tests/tcg/cris/{ => libc}/check_addoq.c   |  0
>  tests/tcg/cris/{ => libc}/check_bound.c   |  0
>  tests/tcg/cris/{ => libc}/check_ftag.c|  0
>  .../{ => libc}/check_gcctorture_pr28634-1.c   |  0
>  .../{ => libc}/check_gcctorture_pr28634.c |  0
>  .../{ => libc}/check_glibc_kernelversion.c|  0
>  tests/tcg/cris/{ => libc}/check_hello.c   |  0
>  tests/tcg/cris/{ => libc}/check_int64.c   |  0
>  tests/tcg/cris/{ 

[Qemu-devel] [RFC PATCH v4 5/5] target/ppc: support single stepping with KVM HV

2019-02-28 Thread Fabiano Rosas
The hardware singlestep mechanism in POWER works via a Trace Interrupt
(0xd00) that happens after any instruction executes, whenever MSR_SE =
1 (PowerISA Section 6.5.15 - Trace Interrupt).

However, with kvm_hv, the Trace Interrupt happens inside the guest and
KVM has no visibility of it. Therefore, when the gdbstub uses the
KVM_SET_GUEST_DEBUG ioctl to enable singlestep, KVM simply ignores it.

This patch takes advantage of the Trace Interrupt to perform the step
inside the guest, but uses a breakpoint at the Trace Interrupt handler
to return control to KVM. The exit is treated by KVM as a regular
breakpoint and it returns to the host (and QEMU eventually).

Before signalling GDB, QEMU sets the Next Instruction Pointer to the
instruction following the one being stepped and restores the MSR,
SRR0, SRR1 values from before the step, effectively skipping the
interrupt handler execution and hiding the trace interrupt breakpoint
from GDB.

This approach works with both of GDB's 'scheduler-locking' options
(off, step).

Note:

- kvm_arch_set_singlestep happens after GDB asks for a single step,
  while the vcpus are stopped.

- kvm_handle_singlestep executes after the step, during the handling
  of the Emulation Assist Interrupt (breakpoint).

Signed-off-by: Fabiano Rosas 
---
 target/ppc/cpu.h |  16 
 target/ppc/excp_helper.c |  13 +++
 target/ppc/gdbstub.c |  35 +++
 target/ppc/kvm.c | 195 +--
 4 files changed, 252 insertions(+), 7 deletions(-)

diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
index 26604ddf98..fb1bf1e9d7 100644
--- a/target/ppc/cpu.h
+++ b/target/ppc/cpu.h
@@ -1171,6 +1171,11 @@ struct CPUPPCState {
 uint32_t tm_vscr;
 uint64_t tm_dscr;
 uint64_t tm_tar;
+
+/* Used for software single step */
+target_ulong sstep_msr;
+target_ulong sstep_srr0;
+target_ulong sstep_srr1;
 };
 
 #define SET_FIT_PERIOD(a_, b_, c_, d_)  \
@@ -1266,6 +1271,7 @@ struct PPCVirtualHypervisorClass {
 OBJECT_GET_CLASS(PPCVirtualHypervisorClass, (obj), \
  TYPE_PPC_VIRTUAL_HYPERVISOR)
 
+target_ulong ppc_get_trace_int_handler_addr(CPUState *cs);
 void ppc_cpu_do_interrupt(CPUState *cpu);
 bool ppc_cpu_exec_interrupt(CPUState *cpu, int int_req);
 void ppc_cpu_dump_state(CPUState *cpu, FILE *f, fprintf_function cpu_fprintf,
@@ -1281,6 +1287,12 @@ int ppc_cpu_gdb_write_register_apple(CPUState *cpu, 
uint8_t *buf, int reg);
 void ppc_gdb_gen_spr_xml(PowerPCCPU *cpu);
 const char *ppc_gdb_get_dynamic_xml(CPUState *cs, const char *xml_name);
 #endif
+uint32_t ppc_gdb_read_insn(CPUState *cs, target_ulong addr);
+uint32_t ppc_gdb_get_op(uint32_t insn);
+uint32_t ppc_gdb_get_xop(uint32_t insn);
+uint32_t ppc_gdb_get_spr(uint32_t insn);
+uint32_t ppc_gdb_get_rt(uint32_t insn);
+
 int ppc64_cpu_write_elf64_note(WriteCoreDumpFunction f, CPUState *cs,
int cpuid, void *opaque);
 int ppc32_cpu_write_elf32_note(WriteCoreDumpFunction f, CPUState *cs,
@@ -2227,6 +2239,10 @@ enum {
 PPC2_ISA300)
 };
 
+#define XOP_RFID 18
+#define XOP_MFMSR 83
+#define XOP_MTSPR 467
+
 /*/
 /* Memory access type :
  * may be needed for precise access rights control and precise exceptions.
diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
index beafcf1ebd..cf8c86de91 100644
--- a/target/ppc/excp_helper.c
+++ b/target/ppc/excp_helper.c
@@ -112,6 +112,8 @@ static uint64_t ppc_excp_vector_offset(CPUState *cs, int 
ail)
 uint64_t offset = 0;
 
 switch (ail) {
+case AIL_NONE:
+break;
 case AIL_0001_8000:
 offset = 0x18000;
 break;
@@ -768,6 +770,17 @@ static inline void powerpc_excp(PowerPCCPU *cpu, int 
excp_model, int excp)
 check_tlb_flush(env, false);
 }
 
+target_ulong ppc_get_trace_int_handler_addr(CPUState *cs)
+{
+PowerPCCPU *cpu = POWERPC_CPU(cs);
+CPUPPCState *env = >env;
+int ail;
+
+ail = (env->spr[SPR_LPCR] & LPCR_AIL) >> LPCR_AIL_SHIFT;
+return env->excp_vectors[POWERPC_EXCP_TRACE] |
+ppc_excp_vector_offset(cs, ail);
+}
+
 void ppc_cpu_do_interrupt(CPUState *cs)
 {
 PowerPCCPU *cpu = POWERPC_CPU(cs);
diff --git a/target/ppc/gdbstub.c b/target/ppc/gdbstub.c
index fbf3821f4b..a5b2705ade 100644
--- a/target/ppc/gdbstub.c
+++ b/target/ppc/gdbstub.c
@@ -380,3 +380,38 @@ const char *ppc_gdb_get_dynamic_xml(CPUState *cs, const 
char *xml_name)
 return NULL;
 }
 #endif
+
+uint32_t ppc_gdb_read_insn(CPUState *cs, target_ulong addr)
+{
+PowerPCCPU *cpu = POWERPC_CPU(cs);
+CPUPPCState *env = >env;
+uint32_t insn;
+
+cpu_memory_rw_debug(cs, addr, (uint8_t *), sizeof(insn), 0);
+
+if (msr_le) {
+return ldl_le_p();
+} else {
+return ldl_be_p();
+}
+}
+
+uint32_t ppc_gdb_get_op(uint32_t insn)
+{
+return extract32(insn, 26, 6);
+}
+
+uint32_t ppc_gdb_get_xop(uint32_t insn)

[Qemu-devel] [RFC PATCH v4 2/5] kvm-all: Introduce kvm_set_singlestep

2019-02-28 Thread Fabiano Rosas
For single stepping (via KVM) of a guest vcpu to work, KVM needs not
only to support the SET_GUEST_DEBUG ioctl but to also recognize the
KVM_GUESTDBG_SINGLESTEP bit in the control field of the
kvm_guest_debug struct.

This patch adds support for querying the single step capability so
that QEMU can decide what to do for the platforms that do not have
such support.

This will allow architecture-specific implementations of a fallback
mechanism for single stepping in cases where KVM does not support it.

Signed-off-by: Fabiano Rosas 
---
 accel/kvm/kvm-all.c | 16 
 accel/stubs/kvm-stub.c  |  4 
 exec.c  |  2 +-
 include/sysemu/kvm.h|  3 +++
 stubs/Makefile.objs |  1 +
 stubs/kvm-arch-set-singlestep.c |  8 
 6 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 stubs/kvm-arch-set-singlestep.c

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index fd92b6f375..d3ac5a9e5c 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -2267,6 +2267,13 @@ bool kvm_arm_supports_user_irq(void)
 return kvm_check_extension(kvm_state, KVM_CAP_ARM_USER_IRQ);
 }
 
+/* Whether the KVM_SET_GUEST_DEBUG ioctl supports single stepping */
+int kvm_has_guestdbg_singlestep(void)
+{
+/* return kvm_check_extension(kvm_state, KVM_CAP_GUEST_DEBUG_SSTEP); */
+return 0;
+}
+
 #ifdef KVM_CAP_SET_GUEST_DEBUG
 struct kvm_sw_breakpoint *kvm_find_sw_breakpoint(CPUState *cpu,
  target_ulong pc)
@@ -2316,6 +2323,15 @@ int kvm_update_guest_debug(CPUState *cpu, unsigned long 
reinject_trap)
 return data.err;
 }
 
+void kvm_set_singlestep(CPUState *cs, int enabled)
+{
+if (kvm_has_guestdbg_singlestep()) {
+kvm_update_guest_debug(cs, 0);
+} else {
+kvm_arch_set_singlestep(cs, enabled);
+}
+}
+
 int kvm_insert_breakpoint(CPUState *cpu, target_ulong addr,
   target_ulong len, int type)
 {
diff --git a/accel/stubs/kvm-stub.c b/accel/stubs/kvm-stub.c
index 02d5170031..69bd07f50e 100644
--- a/accel/stubs/kvm-stub.c
+++ b/accel/stubs/kvm-stub.c
@@ -79,6 +79,10 @@ int kvm_update_guest_debug(CPUState *cpu, unsigned long 
reinject_trap)
 return -ENOSYS;
 }
 
+void kvm_set_singlestep(CPUState *cs, int enabled)
+{
+}
+
 int kvm_insert_breakpoint(CPUState *cpu, target_ulong addr,
   target_ulong len, int type)
 {
diff --git a/exec.c b/exec.c
index 518064530b..8817513e26 100644
--- a/exec.c
+++ b/exec.c
@@ -1236,7 +1236,7 @@ void cpu_single_step(CPUState *cpu, int enabled)
 if (cpu->singlestep_enabled != enabled) {
 cpu->singlestep_enabled = enabled;
 if (kvm_enabled()) {
-kvm_update_guest_debug(cpu, 0);
+kvm_set_singlestep(cpu, enabled);
 } else {
 /* must flush all the translated code to avoid inconsistencies */
 /* XXX: only flush what is necessary */
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index a6d1cd190f..e1ef2f5b99 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -214,6 +214,7 @@ int kvm_has_pit_state2(void);
 int kvm_has_many_ioeventfds(void);
 int kvm_has_gsi_routing(void);
 int kvm_has_intx_set_mask(void);
+int kvm_has_guestdbg_singlestep(void);
 
 int kvm_init_vcpu(CPUState *cpu);
 int kvm_cpu_exec(CPUState *cpu);
@@ -246,6 +247,7 @@ bool kvm_memcrypt_enabled(void);
  */
 int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len);
 
+void kvm_arch_set_singlestep(CPUState *cpu, int enabled);
 
 #ifdef NEED_CPU_H
 #include "cpu.h"
@@ -258,6 +260,7 @@ int kvm_remove_breakpoint(CPUState *cpu, target_ulong addr,
   target_ulong len, int type);
 void kvm_remove_all_breakpoints(CPUState *cpu);
 int kvm_update_guest_debug(CPUState *cpu, unsigned long reinject_trap);
+void kvm_set_singlestep(CPUState *cs, int enabled);
 
 int kvm_on_sigbus_vcpu(CPUState *cpu, int code, void *addr);
 int kvm_on_sigbus(int code, void *addr);
diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
index 269dfa5832..884f9b2268 100644
--- a/stubs/Makefile.objs
+++ b/stubs/Makefile.objs
@@ -12,6 +12,7 @@ stub-obj-y += get-vm-name.o
 stub-obj-y += iothread.o
 stub-obj-y += iothread-lock.o
 stub-obj-y += is-daemonized.o
+stub-obj-y += kvm-arch-set-singlestep.o
 stub-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
 stub-obj-y += machine-init-done.o
 stub-obj-y += migr-blocker.o
diff --git a/stubs/kvm-arch-set-singlestep.c b/stubs/kvm-arch-set-singlestep.c
new file mode 100644
index 00..ba6e0323d6
--- /dev/null
+++ b/stubs/kvm-arch-set-singlestep.c
@@ -0,0 +1,8 @@
+#include "qemu/osdep.h"
+#include "qemu/error-report.h"
+#include "sysemu/kvm.h"
+
+void kvm_arch_set_singlestep(CPUState *cpu, int enabled)
+{
+warn_report("KVM does not support single stepping");
+}
-- 
2.20.1




[Qemu-devel] [RFC PATCH v4 3/5] target/ppc: Move handling of hardware breakpoints to a separate function

2019-02-28 Thread Fabiano Rosas
This is in preparation for a refactoring of the kvm_handle_debug
function in the next patch.

Signed-off-by: Fabiano Rosas 
---
 target/ppc/kvm.c | 47 ---
 1 file changed, 28 insertions(+), 19 deletions(-)

diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index d01852fe31..941c4e7523 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -1593,35 +1593,44 @@ void kvm_arch_update_guest_debug(CPUState *cs, struct 
kvm_guest_debug *dbg)
 }
 }
 
+static int kvm_handle_hw_breakpoint(CPUState *cs,
+struct kvm_debug_exit_arch *arch_info)
+{
+int handle = 0;
+int n;
+int flag = 0;
+
+if (nb_hw_breakpoint + nb_hw_watchpoint > 0) {
+if (arch_info->status & KVMPPC_DEBUG_BREAKPOINT) {
+n = find_hw_breakpoint(arch_info->address, GDB_BREAKPOINT_HW);
+if (n >= 0) {
+handle = 1;
+}
+} else if (arch_info->status & (KVMPPC_DEBUG_WATCH_READ |
+KVMPPC_DEBUG_WATCH_WRITE)) {
+n = find_hw_watchpoint(arch_info->address,  );
+if (n >= 0) {
+handle = 1;
+cs->watchpoint_hit = _watchpoint;
+hw_watchpoint.vaddr = hw_debug_points[n].addr;
+hw_watchpoint.flags = flag;
+}
+}
+}
+return handle;
+}
+
 static int kvm_handle_debug(PowerPCCPU *cpu, struct kvm_run *run)
 {
 CPUState *cs = CPU(cpu);
 CPUPPCState *env = >env;
 struct kvm_debug_exit_arch *arch_info = >debug.arch;
 int handle = 0;
-int n;
-int flag = 0;
 
 if (cs->singlestep_enabled) {
 handle = 1;
 } else if (arch_info->status) {
-if (nb_hw_breakpoint + nb_hw_watchpoint > 0) {
-if (arch_info->status & KVMPPC_DEBUG_BREAKPOINT) {
-n = find_hw_breakpoint(arch_info->address, GDB_BREAKPOINT_HW);
-if (n >= 0) {
-handle = 1;
-}
-} else if (arch_info->status & (KVMPPC_DEBUG_WATCH_READ |
-KVMPPC_DEBUG_WATCH_WRITE)) {
-n = find_hw_watchpoint(arch_info->address,  );
-if (n >= 0) {
-handle = 1;
-cs->watchpoint_hit = _watchpoint;
-hw_watchpoint.vaddr = hw_debug_points[n].addr;
-hw_watchpoint.flags = flag;
-}
-}
-}
+handle = kvm_handle_hw_breakpoint(cs, arch_info);
 } else if (kvm_find_sw_breakpoint(cs, arch_info->address)) {
 handle = 1;
 } else {
-- 
2.20.1




[Qemu-devel] [RFC PATCH v4 0/5] target/ppc: single step for KVM HV

2019-02-28 Thread Fabiano Rosas
Single stepping via GDB/gdbstub is currently not working with KVM
HV. When asking for a single step (stepi), KVM simply ignores the
request and execution continues.

This has the direct effect of breaking GDB's 'step', 'stepi', 'next',
'nexti' commands. The 'continue' command is also affected since
continuing right after a breakpoint requires that GDB first perform a
single step so that the breakpoint can be re-inserted before
continuing - in this case the breakpoint is not re-inserted and it
won't hit again.

The issue here is that single stepping in POWER makes use of an
interrupt (Trace Interrupt [1]) that does not reach the hypervisor, so
while the single step would happen if properly triggered, it would not
cause an exit to KVM so there would be no way of handing control back
to GDB. Aside from that, the guest kernel is not prepared to deal with
such an interrupt in kernel mode (when not using KGDB, or some other
debugging facility) and it causes an Oops.

This series implements a "software single step" approach that makes
use of: i) the Trace Interrupt to perform the step inside the guest
and ii) a breakpoint at the Trace Interrupt handler address to cause a
vm exit (Emulation Assist) so that we can return control to QEMU.

With (i), we basically get the single step for free, without having to
discover what are the possible targets of instructions that divert
execution.

With (ii), we hide the single step from the guest and keep all of the
step logic in QEMU.

Supported scenarios:

- Stepping of multiple vcpus;
- GDB scheduler locking on and off [2];
- single stepping of kernel code with QEMU while stepping with GDB
  inside the guest (user space, KGDB).

1- PowerISA Section 6.5.15 - Trace Interrupt
2- https://sourceware.org/gdb/onlinedocs/gdb/All_002dStop-Mode.html

v1 -> v2:
 - split in more patches to facilitate review
 - use extract32 for decoding instruction instead of open-coding
 - add more people to CC

 https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg03738.html

v2 -> v3:
 - take Alternate Interrupt Location (AIL) into consideration when
   calculating the Trace Interrupt handler address (this allows single
   stepping in SLOF code);

 - check for a new KVM_GUEST_DEBUG_SSTEP capability (still to be
   submitted to kernel ml);

 - handle other vcpus (not currently stepping) hitting the single step
   breakpoint - by ignoring the breakpoint;

 - handle simultaneous single step by GDB inside guest - by first
   performing our step into the trace interrupt handler itself and
   returning to the guest afterwards;

 - handle single stepping when at the first trace interrupt handler
   instruction - by displacing the breakpoint to the next instruction;

 - restore MSR, SRR0, SRR1 after the step, taking into consideration
   possible mtspr, mtmsr instructions;

 - use stubs for arch-specific code that will not be implemented by
   other architectures at this point;

 https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg04269.html

v3 -> v4:
 - patch 1: fix uninitialized 'offset' variable;

 - patch 2: squash with patch 7/7 (now 5/5);
fix exception vector offset calculation when AIL == 0;

 - patch 3: squash with 4/7 (now 2/5);

 - patch 7: introduce ppc_gdb_get_{op,xop,rt,spr} functions;

introduce ppc_gdb_read_insn function;

define constants for mfmsr, rfid, mtspr extended opcodes;

fix bug where instructions would not be properly
recognized in SLOF due to guest endianness being different
from host's;

pass arch_info->address directly into functions that only
need the address;

improve indentation by returning early when possible.

 https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg04627.html


Fabiano Rosas (5):
  target/ppc: Move exception vector offset computation into a function
  kvm-all: Introduce kvm_set_singlestep
  target/ppc: Move handling of hardware breakpoints to a separate
function
  target/ppc: Refactor kvm_handle_debug
  target/ppc: support single stepping with KVM HV

 accel/kvm/kvm-all.c |  16 ++
 accel/stubs/kvm-stub.c  |   4 +
 exec.c  |   2 +-
 include/sysemu/kvm.h|   3 +
 stubs/Makefile.objs |   1 +
 stubs/kvm-arch-set-singlestep.c |   8 +
 target/ppc/cpu.h|  16 ++
 target/ppc/excp_helper.c|  43 +++--
 target/ppc/gdbstub.c|  35 
 target/ppc/kvm.c| 312 ++--
 10 files changed, 374 insertions(+), 66 deletions(-)
 create mode 100644 stubs/kvm-arch-set-singlestep.c

--
2.20.1




[Qemu-devel] [RFC PATCH v4 1/5] target/ppc: Move exception vector offset computation into a function

2019-02-28 Thread Fabiano Rosas
Signed-off-by: Fabiano Rosas 
Reviewed-by: Alexey Kardashevskiy 
---
 target/ppc/excp_helper.c | 30 +++---
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
index 39bedbb11d..beafcf1ebd 100644
--- a/target/ppc/excp_helper.c
+++ b/target/ppc/excp_helper.c
@@ -107,6 +107,24 @@ static int powerpc_reset_wakeup(CPUState *cs, CPUPPCState 
*env, int excp,
 return POWERPC_EXCP_RESET;
 }
 
+static uint64_t ppc_excp_vector_offset(CPUState *cs, int ail)
+{
+uint64_t offset = 0;
+
+switch (ail) {
+case AIL_0001_8000:
+offset = 0x18000;
+break;
+case AIL_C000___4000:
+offset = 0xc0004000ull;
+break;
+default:
+cpu_abort(cs, "Invalid AIL combination %d\n", ail);
+break;
+}
+
+return offset;
+}
 
 /* Note that this function should be greatly optimized
  * when called with a constant excp, from ppc_hw_interrupt
@@ -708,17 +726,7 @@ static inline void powerpc_excp(PowerPCCPU *cpu, int 
excp_model, int excp)
 /* Handle AIL */
 if (ail) {
 new_msr |= (1 << MSR_IR) | (1 << MSR_DR);
-switch(ail) {
-case AIL_0001_8000:
-vector |= 0x18000;
-break;
-case AIL_C000___4000:
-vector |= 0xc0004000ull;
-break;
-default:
-cpu_abort(cs, "Invalid AIL combination %d\n", ail);
-break;
-}
+vector |= ppc_excp_vector_offset(cs, ail);
 }
 
 #if defined(TARGET_PPC64)
-- 
2.20.1




[Qemu-devel] [RFC PATCH v4 4/5] target/ppc: Refactor kvm_handle_debug

2019-02-28 Thread Fabiano Rosas
There are four scenarios being handled in this function:

- single stepping
- hardware breakpoints
- software breakpoints
- fallback (no debug supported)

A future patch will add code to handle specific single step and
software breakpoints cases so let's split each scenario into its own
function now to avoid hurting readability.

Signed-off-by: Fabiano Rosas 
Reviewed-by: Alexey Kardashevskiy 
---
 target/ppc/kvm.c | 86 
 1 file changed, 50 insertions(+), 36 deletions(-)

diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index 941c4e7523..9392fba192 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -1620,52 +1620,66 @@ static int kvm_handle_hw_breakpoint(CPUState *cs,
 return handle;
 }
 
+static int kvm_handle_singlestep(void)
+{
+return 1;
+}
+
+static int kvm_handle_sw_breakpoint(void)
+{
+return 1;
+}
+
 static int kvm_handle_debug(PowerPCCPU *cpu, struct kvm_run *run)
 {
 CPUState *cs = CPU(cpu);
 CPUPPCState *env = >env;
 struct kvm_debug_exit_arch *arch_info = >debug.arch;
-int handle = 0;
 
 if (cs->singlestep_enabled) {
-handle = 1;
-} else if (arch_info->status) {
-handle = kvm_handle_hw_breakpoint(cs, arch_info);
-} else if (kvm_find_sw_breakpoint(cs, arch_info->address)) {
-handle = 1;
-} else {
-/* QEMU is not able to handle debug exception, so inject
- * program exception to guest;
- * Yes program exception NOT debug exception !!
- * When QEMU is using debug resources then debug exception must
- * be always set. To achieve this we set MSR_DE and also set
- * MSRP_DEP so guest cannot change MSR_DE.
- * When emulating debug resource for guest we want guest
- * to control MSR_DE (enable/disable debug interrupt on need).
- * Supporting both configurations are NOT possible.
- * So the result is that we cannot share debug resources
- * between QEMU and Guest on BOOKE architecture.
- * In the current design QEMU gets the priority over guest,
- * this means that if QEMU is using debug resources then guest
- * cannot use them;
- * For software breakpoint QEMU uses a privileged instruction;
- * So there cannot be any reason that we are here for guest
- * set debug exception, only possibility is guest executed a
- * privileged / illegal instruction and that's why we are
- * injecting a program interrupt.
- */
+return kvm_handle_singlestep();
+}
+
+if (arch_info->status) {
+return kvm_handle_hw_breakpoint(cs, arch_info);
+}
 
-cpu_synchronize_state(cs);
-/* env->nip is PC, so increment this by 4 to use
- * ppc_cpu_do_interrupt(), which set srr0 = env->nip - 4.
- */
-env->nip += 4;
-cs->exception_index = POWERPC_EXCP_PROGRAM;
-env->error_code = POWERPC_EXCP_INVAL;
-ppc_cpu_do_interrupt(cs);
+if (kvm_find_sw_breakpoint(cs, arch_info->address)) {
+return kvm_handle_sw_breakpoint();
 }
 
-return handle;
+/*
+ * QEMU is not able to handle debug exception, so inject
+ * program exception to guest;
+ * Yes program exception NOT debug exception !!
+ * When QEMU is using debug resources then debug exception must
+ * be always set. To achieve this we set MSR_DE and also set
+ * MSRP_DEP so guest cannot change MSR_DE.
+ * When emulating debug resource for guest we want guest
+ * to control MSR_DE (enable/disable debug interrupt on need).
+ * Supporting both configurations are NOT possible.
+ * So the result is that we cannot share debug resources
+ * between QEMU and Guest on BOOKE architecture.
+ * In the current design QEMU gets the priority over guest,
+ * this means that if QEMU is using debug resources then guest
+ * cannot use them;
+ * For software breakpoint QEMU uses a privileged instruction;
+ * So there cannot be any reason that we are here for guest
+ * set debug exception, only possibility is guest executed a
+ * privileged / illegal instruction and that's why we are
+ * injecting a program interrupt.
+ */
+cpu_synchronize_state(cs);
+/*
+ * env->nip is PC, so increment this by 4 to use
+ * ppc_cpu_do_interrupt(), which set srr0 = env->nip - 4.
+ */
+env->nip += 4;
+cs->exception_index = POWERPC_EXCP_PROGRAM;
+env->error_code = POWERPC_EXCP_INVAL;
+ppc_cpu_do_interrupt(cs);
+
+return 0;
 }
 
 int kvm_arch_handle_exit(CPUState *cs, struct kvm_run *run)
-- 
2.20.1




Re: [Qemu-devel] [PATCH v2 08/16] tests/tcg/arm: add ARMv6-M UNDEFINED 32-bit instruction test

2019-02-28 Thread Philippe Mathieu-Daudé
On 2/28/19 9:25 PM, Alex Bennée wrote:
> From: Stefan Hajnoczi 
> 
> Test that 32-bit instructions declared UNDEFINED in the ARMv6-M
> Reference Manual really do raise an exception.  Also test that the 6
> 32-bit instructions defined in the ARMv6-M Reference Manual do not raise
> an exception.
> 
> Based-on: <20181029194519.15628-1-stefa...@redhat.com>

^ cut 'Based-on' from git history?

> Signed-off-by: Stefan Hajnoczi 
> Message-Id: <20181129185113.30353-1-stefa...@redhat.com>
> [AJB: integrated into system tests]
> Signed-off-by: Alex Bennée 
> 
> ---
> v2
>   - added to series
>   - used softmmu-target Makefile with single compile/link step
>   - launches with -kernel
>   - drop .hex file
> ---
>  tests/tcg/arm/Makefile.softmmu-target |  29 +
>  tests/tcg/arm/test-armv6m-undef.S | 154 ++
>  tests/tcg/arm/test-armv6m-undef.ld|  21 
>  3 files changed, 204 insertions(+)
>  create mode 100644 tests/tcg/arm/Makefile.softmmu-target
>  create mode 100644 tests/tcg/arm/test-armv6m-undef.S
>  create mode 100644 tests/tcg/arm/test-armv6m-undef.ld
> 
> diff --git a/tests/tcg/arm/Makefile.softmmu-target 
> b/tests/tcg/arm/Makefile.softmmu-target
> new file mode 100644
> index 00..49d48d8a1c
> --- /dev/null
> +++ b/tests/tcg/arm/Makefile.softmmu-target
> @@ -0,0 +1,29 @@
> +# -*- Mode: makefile -*-
> +#
> +# ARM SoftMMU tests - included from tests/tcg/Makefile
> +#
> +
> +ifeq ($(TARGET_ABI_DIR),arm)
> +
> +ARM_SRC=$(SRC_PATH)/tests/tcg/arm
> +
> +# Set search path for all sources
> +VPATH+= $(ARM_SRC)
> +
> +ARM_TESTS=test-armv6m-undef
> +
> +TESTS += $(ARM_TESTS)
> +
> +CFLAGS+=-Wl,--build-id=none -x assembler-with-cpp
> +LDFLAGS+=-nostdlib -N -static
> +
> +%: %.S %.ld
> + $(CC) $(CFLAGS) $(ASFLAGS) $< -o $@ $(LDFLAGS) -T $(ARM_SRC)/$@.ld
> +
> +# Specific Test Rules
> +
> +test-armv6m-undef: EXTRA_CFLAGS+=-mcpu=cortex-m0
> +
> +run-test-armv6m-undef: QEMU_OPTS+=-semihosting -M microbit -kernel
> +
> +endif
> diff --git a/tests/tcg/arm/test-armv6m-undef.S 
> b/tests/tcg/arm/test-armv6m-undef.S
> new file mode 100644
> index 00..d18ca56b4a
> --- /dev/null
> +++ b/tests/tcg/arm/test-armv6m-undef.S
> @@ -0,0 +1,154 @@
> +/*
> + * Test ARMv6-M UNDEFINED 32-bit instructions
> + *
> + * Copyright 2018 Red Hat Inc.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2
> + * or later. See the COPYING file in the top-level directory.
> + */
> +
> +/*
> + * Test that UNDEFINED 32-bit instructions fault as expected.  This is an
> + * interesting test because ARMv6-M shares code with its more fully-featured
> + * siblings and it's necessary to verify that its limited instruction set is
> + * emulated correctly.
> + *
> + * The emulator must be invoked with -semihosting so that the test case can
> + * terminate with exit code 0 on success or 1 on failure.
> + *
> + * Failures can be debugged with -d in_asm,int,exec,cpu and the
> + * gdbstub (-S -s).
> + */
> +
> +.syntax unified
> +.cpu cortex-m0
> +.thumb
> +
> +/*
> + * Memory map
> + */
> +#define SRAM_BASE 0x2000
> +#define SRAM_SIZE (16 * 1024)
> +
> +/*
> + * Semihosting interface on ARM T32
> + * See "Semihosting for AArch32 and AArch64 Version 2.0 Documentation" by ARM
> + */
> +#define semihosting_call bkpt 0xab
> +#define SYS_EXIT 0x18
> +
> +vector_table:
> +.word SRAM_BASE + SRAM_SIZE /* 0. SP_main */
> +.word exc_reset_thumb   /* 1. Reset */
> +.word 0 /* 2. NMI */
> +.word exc_hard_fault_thumb  /* 3. HardFault */
> +.rept 7
> +.word 0 /* 4-10. Reserved */
> +.endr
> +.word 0 /* 11. SVCall */
> +.word 0 /* 12. Reserved */
> +.word 0 /* 13. Reserved */
> +.word 0 /* 14. PendSV */
> +.word 0 /* 15. SysTick */
> +.rept 32
> +.word 0 /* 16-47. External Interrupts */
> +.endr
> +
> +exc_reset:
> +.equ exc_reset_thumb, exc_reset + 1
> +.global exc_reset_thumb
> +/* The following 32-bit UNDEFINED instructions are tested by executing
> + * them.  The HardFault exception handler should execute and return to
> + * the next test case.  If no exception is raised the test fails.
> + */
> +
> +/* Table A5-9 32-bit Thumb encoding */
> +.short 0b11101000
> +.short 0b
> +b not_reached
> +.short 0b11101000
> +.short 0b1000
> +b not_reached
> +.short 0b1000
> +.short 0b
> +b not_reached
> +.short 0b1000
> +.short 0b1000
> +b not_reached
> +.short 0b
> +.short 0b
> +b not_reached
> +
> +/* Table A5-10 Branch and miscellaneous control instructions */
> +.short 0b0111
> +.short 0b1010
> +b not_reached
> +
> +/* 

Re: [Qemu-devel] [PATCH v2 07/16] tests/tcg/xtensa: enable system tests

2019-02-28 Thread Philippe Mathieu-Daudé
On 2/28/19 9:25 PM, Alex Bennée wrote:
> Signed-off-by: Alex Bennée 
> 
> ---
> v2
>   - use cross CC for linker
>   - fix up test selection to skip linker.ld.S
> ---
>  tests/tcg/xtensa/Makefile| 93 
>  tests/tcg/xtensa/Makefile.softmmu-target | 40 ++
>  2 files changed, 40 insertions(+), 93 deletions(-)
>  delete mode 100644 tests/tcg/xtensa/Makefile
>  create mode 100644 tests/tcg/xtensa/Makefile.softmmu-target
> 
> diff --git a/tests/tcg/xtensa/Makefile b/tests/tcg/xtensa/Makefile
> deleted file mode 100644
> index 2f5691f75b..00
> --- a/tests/tcg/xtensa/Makefile
> +++ /dev/null
> @@ -1,93 +0,0 @@
> --include ../../../config-host.mak
> -
> -CORE=dc232b
> -CROSS=xtensa-$(CORE)-elf-
> -
> -ifndef XT
> -SIM = ../../../xtensa-softmmu/qemu-system-xtensa
> -SIMFLAGS = -M sim -cpu $(CORE) -nographic -semihosting -icount 6 $(EXTFLAGS) 
> -kernel
> -SIMDEBUG = -s -S
> -else
> -SIM = xt-run
> -SIMFLAGS = --xtensa-core=DC_B_232L --exit_with_target_code $(EXTFLAGS)
> -SIMDEBUG = --gdbserve=0

Max: I think it should be quite easy to port your simulator to Alex's
new Makefile.
One possibility is adding tests/tcg/xtensa/Makefile.xt-run which set few
variables, include Makefile.softmmu-target and overwrite variables if
necessary.

BTW is this simulator downloadable? I see the Zephyr project also uses
it, and I looked for it on https://ip.cadence.com/swdev but couldnt find
a (public) link.

> -endif
> -
> -HOST_CC = gcc
> -CC  = $(CROSS)gcc
> -AS  = $(CROSS)gcc -x assembler-with-cpp
> -LD  = $(CROSS)ld
> -
> -XTENSA_SRC_PATH = $(SRC_PATH)/tests/tcg/xtensa
> -INCLUDE_DIRS = $(XTENSA_SRC_PATH) $(SRC_PATH)/target/xtensa/core-$(CORE)
> -XTENSA_INC = $(addprefix -I,$(INCLUDE_DIRS))
> -
> -LDFLAGS = -Tlinker.ld
> -
> -CRT= crt.o vectors.o
> -
> -TESTCASES += test_b.tst
> -TESTCASES += test_bi.tst
> -#TESTCASES += test_boolean.tst
> -TESTCASES += test_break.tst
> -TESTCASES += test_bz.tst
> -TESTCASES += test_cache.tst
> -TESTCASES += test_clamps.tst
> -TESTCASES += test_extui.tst
> -TESTCASES += test_fail.tst
> -TESTCASES += test_interrupt.tst
> -TESTCASES += test_loop.tst
> -TESTCASES += test_mac16.tst
> -TESTCASES += test_max.tst
> -TESTCASES += test_min.tst
> -TESTCASES += test_mmu.tst
> -TESTCASES += test_mul16.tst
> -TESTCASES += test_mul32.tst
> -TESTCASES += test_nsa.tst
> -TESTCASES += test_phys_mem.tst
> -ifdef XT
> -TESTCASES += test_pipeline.tst
> -endif
> -TESTCASES += test_quo.tst
> -TESTCASES += test_rem.tst
> -TESTCASES += test_rst0.tst
> -TESTCASES += test_s32c1i.tst
> -TESTCASES += test_sar.tst
> -TESTCASES += test_sext.tst
> -TESTCASES += test_shift.tst
> -TESTCASES += test_sr.tst
> -TESTCASES += test_timer.tst
> -TESTCASES += test_windowed.tst
> -
> -all: build
> -
> -linker.ld: $(XTENSA_SRC_PATH)/linker.ld.S
> - $(HOST_CC) $(XTENSA_INC) -E -P $< -o $@
> -
> -%.o: $(XTENSA_SRC_PATH)/%.c
> - $(CC) $(XTENSA_INC) $(CFLAGS) -c $< -o $@
> -
> -%.o: $(XTENSA_SRC_PATH)/%.S
> - $(CC) $(XTENSA_INC) $(ASFLAGS) -c $< -o $@
> -
> -%.tst: %.o linker.ld $(XTENSA_SRC_PATH)/macros.inc $(CRT) Makefile
> - $(LD) $(LDFLAGS) $(NOSTDFLAGS) $(CRT) $< -o $@
> -
> -build: $(TESTCASES)
> -
> -check: $(addprefix run-, $(TESTCASES))
> -
> -run-%.tst: %.tst
> - $(SIM) $(SIMFLAGS) ./$<
> -
> -run-test_fail.tst: test_fail.tst
> - ! $(SIM) $(SIMFLAGS) ./$<
> -
> -debug-%.tst: %.tst
> - $(SIM) $(SIMDEBUG) $(SIMFLAGS) ./$<
> -
> -host-debug-%.tst: %.tst
> - gdb --args $(SIM) $(SIMFLAGS) ./$<
> -
> -clean:
> - $(RM) -fr $(TESTCASES) $(CRT) linker.ld
> diff --git a/tests/tcg/xtensa/Makefile.softmmu-target 
> b/tests/tcg/xtensa/Makefile.softmmu-target
> new file mode 100644
> index 00..1a4014506f
> --- /dev/null
> +++ b/tests/tcg/xtensa/Makefile.softmmu-target
> @@ -0,0 +1,40 @@
> +#
> +# Xtensa softmmu tests
> +#
> +
> +ifneq ($(TARGET_WORDS_BIGENDIAN),y)
> +
> +XTENSA_SRC = $(SRC_PATH)/tests/tcg/xtensa
> +XTENSA_ALL = $(filter-out $(XTENSA_SRC)/linker.ld.S,$(wildcard 
> $(XTENSA_SRC)/*.S))
> +XTENSA_TESTS = $(patsubst $(XTENSA_SRC)/%.S, %, $(XTENSA_ALL))
> +# Filter out common blobs and broken tests
> +XTENSA_BROKEN_TESTS  = crt vectors test_boolean test_pipeline test_fail
> +XTENSA_USABLE_TESTS = $(filter-out $(XTENSA_BROKEN_TESTS), $(XTENSA_TESTS))
> +
> +# add to the list of tests
> +TESTS += $(XTENSA_USABLE_TESTS)
> +VPATH += $(XTENSA_SRC)
> +
> +CORE=dc232b
> +QEMU_OPTS+=-M sim -cpu $(CORE) -nographic -semihosting -icount 6 $(EXTFLAGS) 
> -kernel
> +
> +INCLUDE_DIRS = $(SRC_PATH)/target/xtensa/core-$(CORE)
> +XTENSA_INC = $(addprefix -I,$(INCLUDE_DIRS))
> +
> +LDFLAGS = -Tlinker.ld -nostartfiles -nostdlib
> +
> +CRT= crt.o vectors.o
> +
> +linker.ld: linker.ld.S
> + $(CC) $(XTENSA_INC) -E -P $< -o $@
> +
> +$(XTENSA_USABLE_TESTS): linker.ld macros.inc $(CRT) Makefile.softmmu-target
> +
> +# special rule for common blobs
> +%.o: %.S
> + $(CC) $(XTENSA_INC) $(ASFLAGS) -c $< -o $@
> +
> +%: %.S
> + 

Re: [Qemu-devel] [PATCH v2 4/6] mips: Express dependencies of the Boston machine with kconfig

2019-02-28 Thread Paul Burton
On Mon, Feb 04, 2019 at 09:26:07PM +0100, Philippe Mathieu-Daudé wrote:
> Boston is built around a Xilinx FPGA, which includes a PCIe root port
> and an UART. An Intel EG20T PCH connects the I/O peripherals, but only
> the SATA bus is emulated.
> 
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Paul Burton 

Thanks,
Paul

> ---
>  default-configs/mips64el-softmmu.mak | 4 
>  hw/mips/Kconfig  | 5 +
>  2 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/default-configs/mips64el-softmmu.mak 
> b/default-configs/mips64el-softmmu.mak
> index 23445cfcf9..c6f1f9c9aa 100644
> --- a/default-configs/mips64el-softmmu.mak
> +++ b/default-configs/mips64el-softmmu.mak
> @@ -4,8 +4,4 @@ include mips-softmmu-common.mak
>  CONFIG_IDE_VIA=y
>  CONFIG_FULONG=y
>  CONFIG_VT82C686=y
> -CONFIG_AHCI=y
>  CONFIG_MIPS_BOSTON=y
> -CONFIG_FITLOADER=y
> -CONFIG_PCI_EXPRESS=y
> -CONFIG_PCI_EXPRESS_XILINX=y
> diff --git a/hw/mips/Kconfig b/hw/mips/Kconfig
> index ee6290d497..2940ff39ab 100644
> --- a/hw/mips/Kconfig
> +++ b/hw/mips/Kconfig
> @@ -49,3 +49,8 @@ config MIPS_CPS
>  
>  config MIPS_BOSTON
>  bool
> +select FITLOADER
> +select MIPS_CPS
> +select PCI_EXPRESS_XILINX
> +select AHCI
> +select SERIAL
> -- 
> 2.20.1
> 



Re: [Qemu-devel] [PATCH v2 05/16] tests/tcg/mips: fix hello-mips compilation

2019-02-28 Thread Philippe Mathieu-Daudé
Hi Alex,

On 2/28/19 9:25 PM, Alex Bennée wrote:
> The compilation flags for proper building are in the source tree. We
> also fix exit to 0 so the result is counted as a success.
> 
> Signed-off-by: Alex Bennée 
> ---
>  tests/tcg/mips/Makefile.target | 11 ---
>  tests/tcg/mips/hello-mips.c|  2 +-
>  2 files changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/tests/tcg/mips/Makefile.target b/tests/tcg/mips/Makefile.target
> index 086625f533..1a994d5525 100644
> --- a/tests/tcg/mips/Makefile.target
> +++ b/tests/tcg/mips/Makefile.target
> @@ -8,15 +8,12 @@ MIPS_SRC=$(SRC_PATH)/tests/tcg/mips
>  # Set search path for all sources
>  VPATH+= $(MIPS_SRC)
>  
> +# hello-mips is 32 bit only

Correct.

> +ifeq ($(findstring 64,$(TARGET_NAME)),)
>  MIPS_TESTS=hello-mips
>  
>  TESTS += $(MIPS_TESTS)
>  
> -hello-mips: CFLAGS+=-ffreestanding
> +hello-mips: CFLAGS+=-mno-abicalls -fno-PIC -mabi=32

As suggested in the header.

>  hello-mips: LDFLAGS+=-nostdlib
> -
> -# For MIPS32 and 64 we have a bunch of extra tests in sub-directories
> -# however they are intended for system tests.
> -
> -run-hello-mips: hello-mips
> - $(call skip-test, $<, "BROKEN")
> +endif
> diff --git a/tests/tcg/mips/hello-mips.c b/tests/tcg/mips/hello-mips.c
> index c7052fdf2e..4e1cf501af 100644
> --- a/tests/tcg/mips/hello-mips.c
> +++ b/tests/tcg/mips/hello-mips.c
> @@ -60,5 +60,5 @@ static inline int write(int fd, const char *buf, int len)
>  void __start(void)
>  {
>  write (1, "Hello, World!\n", 14);
> -exit1 (42);

I understand 42 is to check SYS_exit1 worked, and this is not another
qemu-user exit. But we were previously never checked the exit code for
42. Neither are we checking 'Hello, World' on stdout.

> +exit1(0);
>  }
> 



Re: [Qemu-devel] [PATCH v3 7/7] ui/cocoa: Perform UI operations only on the main thread

2019-02-28 Thread G 3
On Mon, Feb 25, 2019 at 5:24 AM Peter Maydell 
wrote:

> The OSX Mojave release is more picky about enforcing the Cocoa API
> restriction that only the main thread may perform UI calls. To
> accommodate this we need to restructure the Cocoa code:
>  * the special OSX main() creates a second thread and uses
>that to call the vl.c qemu_main(); the original main
>thread goes into the OSX event loop
>  * the refresh, switch and update callbacks asynchronously
>tell the main thread to do the necessary work
>  * the refresh callback no longer does the "get events from the
>UI event queue and handle them" loop, since we now use
>the stock OSX event loop. Instead our NSApplication sendEvent
>method will either deal with them or pass them on to OSX
>
> All these things have to be changed in one commit, to avoid
> breaking bisection.
>
> Note that since we use dispatch_get_main_queue(), this bumps
> our minimum version requirement to OSX 10.10 Yosemite (released
> in 2014, unsupported by Apple since 2017).
>
> I think eliminating support for Macintosh operating systems older than
10.10 is a mistake. These operating systems may be old but are far from
useless. They are fully capable of handling QEMU. I do believe that fixing
support for Mac OS 10.14 and maintaining support for older versions of Mac
OS is possible. Calling methods and functions on the main thread can be
done using performSelectorOnMainThread.

Thank you.


[Qemu-devel] [PULL v2 00/40] target/xtensa queue

2019-02-28 Thread Max Filippov
Hi Peter,

please pull the following batch of target/xtensa updates.
Changes v1->v2:
- fix build with clang.

The following changes since commit 1c3d45df5e94042d5fb2bb31416072563ab30e49:

  Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2019-02-04' into 
staging (2019-02-05 12:46:18 +)

are available in the git repository at:

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

for you to fetch changes up to de0cebd93089ff2ebf2ebf9d287381eb73cbb9aa:

  tests/tcg/xtensa: add FPU2000 coprocessor tests (2019-02-28 04:43:24 -0800)


target/xtensa: FLIX support, various fixes and test improvements

- add FLIX (flexible length instructions extension) support;
- make testsuite runnable on wider range of xtensa cores;
- add floating point opcode tests;
- don't add duplicate 'static' in import_core.sh script;
- fix undefined opcodes detection in test_mmuhifi_c3 overlay.


Max Filippov (40):
  target/xtensa/import_core.sh: don't add duplicate 'static'
  target/xtensa: don't specify windowed registers manually
  target/xtensa: get rid of gen_callw[i]
  target/xtensa: fixup test_mmuhifi_c3 overlay
  target/xtensa: move xtensa_finalize_config to xtensa_core_class_init
  target/xtensa: don't require opcode table sorting
  target/xtensa: allow multiple names for single opcode
  target/xtensa: implement wide branches and loops
  target/xtensa: sort FLIX instruction opcodes
  target/xtensa: add generic instruction post-processing
  target/xtensa: move WINDOW_BASE SR update to postprocessing
  target/xtensa: only rotate window in the retw helper
  target/xtensa: reorganize register handling in translators
  target/xtensa: reorganize access to MAC16 registers
  target/xtensa: reorganize access to boolean registers
  target/xtensa: break circular register dependencies
  target/xtensa: prioritize load/store in FLIX bundles
  target/xtensa: implement PREFCTL SR
  tests/tcg/xtensa: indicate failed tests
  tests/tcg/xtensa: support configurations w/o vecbase
  tests/tcg/xtensa: support configs with LITBASE
  tests/tcg/xtensa: don't use optional opcodes in generic code
  tests/tcg/xtensa: fix endianness issues in test_b
  tests/tcg/xtensa: enable boolean tests
  tests/tcg/xtensa: conditionalize debug option tests
  tests/tcg/xtensa: conditionalize cache option tests
  tests/tcg/xtensa: add straightforward conditionals
  tests/tcg/xtensa: conditionalize interrupt tests
  tests/tcg/xtensa: conditionalize timer/CCOUNT tests
  tests/tcg/xtensa: conditionalize and expand SR tests
  tests/tcg/xtensa: fix SR tests for big endian configs
  tests/tcg/xtensa: conditionalize and fix s32c1i tests
  tests/tcg/xtensa: conditionalize windowed register tests
  tests/tcg/xtensa: conditionalize MMU-related tests
  tests/tcg/xtensa: add test for FLIX
  tests/tcg/xtensa: add LSCI/LSCX group tests
  tests/tcg/xtensa: add FP0 group arithmetic tests
  tests/tcg/xtensa: add FP0 group conversion tests
  tests/tcg/xtensa: add FP1 group tests
  tests/tcg/xtensa: add FPU2000 coprocessor tests

 .../core-test_mmuhifi_c3/xtensa-modules.inc.c  | 1322 ++--
 target/xtensa/cpu.h|   40 +-
 target/xtensa/helper.c |   94 +-
 target/xtensa/helper.h |5 +-
 target/xtensa/import_core.sh   |2 +-
 target/xtensa/overlay_tool.h   |1 -
 target/xtensa/translate.c  | 2114 ++--
 target/xtensa/win_helper.c |   22 +-
 tests/tcg/xtensa/Makefile  |   13 +-
 tests/tcg/xtensa/linker.ld.S   |   67 +-
 tests/tcg/xtensa/macros.inc|   41 +-
 tests/tcg/xtensa/test_b.S  |   40 +-
 tests/tcg/xtensa/test_boolean.S|4 +
 tests/tcg/xtensa/test_break.S  |   27 +-
 tests/tcg/xtensa/test_cache.S  |   62 +-
 tests/tcg/xtensa/test_clamps.S |4 +
 tests/tcg/xtensa/test_flix.S   |   60 +
 tests/tcg/xtensa/test_fp0_arith.S  |  173 ++
 tests/tcg/xtensa/test_fp0_conv.S   |  304 +++
 tests/tcg/xtensa/test_fp1.S|  141 ++
 tests/tcg/xtensa/test_fp_cpenable.S|   27 +
 tests/tcg/xtensa/test_interrupt.S  |   88 +-
 tests/tcg/xtensa/test_loop.S   |4 +
 tests/tcg/xtensa/test_lsc.S|  122 ++
 tests/tcg/xtensa/test_mac16.S  |4 +
 tests/tcg/xtensa/test_max.S|4 +
 tests/tcg/xtensa/test_mi

[Qemu-devel] [PATCH v2 09/40] target/xtensa: sort FLIX instruction opcodes

2019-02-28 Thread Max Filippov
Opcodes in different slots may read and write same resources (registers,
states). In the absence of resource dependency loops it must be possible
to sort opcodes to avoid interference.

Record resources used by each opcode in the bundle. Build opcode
dependency graph and use topological sort to order its nodes. In case of
success translate opcodes in sort order. In case of failure report and
raise invalid opcode exception.

Signed-off-by: Max Filippov 
---
Changes v1->v2:
- fix build with clang

 target/xtensa/cpu.h   |   2 +
 target/xtensa/translate.c | 227 --
 2 files changed, 221 insertions(+), 8 deletions(-)

diff --git a/target/xtensa/cpu.h b/target/xtensa/cpu.h
index db8ee70a0386..c59f79e56326 100644
--- a/target/xtensa/cpu.h
+++ b/target/xtensa/cpu.h
@@ -373,6 +373,8 @@ enum {
 XTENSA_OP_EXIT_TB_0 = 0x800,
 
 XTENSA_OP_NAME_ARRAY = 0x8000,
+
+XTENSA_OP_CONTROL_FLOW = 0x1,
 };
 
 typedef struct XtensaOpcodeOps {
diff --git a/target/xtensa/translate.c b/target/xtensa/translate.c
index e832b3af..bda4e9469b86 100644
--- a/target/xtensa/translate.c
+++ b/target/xtensa/translate.c
@@ -846,6 +846,157 @@ static inline unsigned xtensa_op0_insn_len(DisasContext 
*dc, uint8_t op0)
 return xtensa_isa_length_from_chars(dc->config->isa, );
 }
 
+struct opcode_arg_info {
+uint32_t resource;
+int index;
+};
+
+struct slot_prop {
+XtensaOpcodeOps *ops;
+uint32_t arg[MAX_OPCODE_ARGS];
+uint32_t raw_arg[MAX_OPCODE_ARGS];
+struct opcode_arg_info in[MAX_OPCODE_ARGS];
+struct opcode_arg_info out[MAX_OPCODE_ARGS];
+unsigned n_in;
+unsigned n_out;
+uint32_t op_flags;
+};
+
+enum resource_type {
+RES_REGFILE,
+RES_STATE,
+RES_MAX,
+};
+
+static uint32_t encode_resource(enum resource_type r, unsigned g, unsigned n)
+{
+assert(r < RES_MAX && g < 256 && n < 65536);
+return (r << 24) | (g << 16) | n;
+}
+
+/*
+ * a depends on b if b must be executed before a,
+ * because a's side effects will destroy b's inputs.
+ */
+static bool op_depends_on(const struct slot_prop *a,
+  const struct slot_prop *b)
+{
+unsigned i = 0;
+unsigned j = 0;
+
+if (a->op_flags & XTENSA_OP_CONTROL_FLOW) {
+return true;
+}
+while (i < a->n_out && j < b->n_in) {
+if (a->out[i].resource < b->in[j].resource) {
+++i;
+} else if (a->out[i].resource > b->in[j].resource) {
+++j;
+} else {
+return true;
+}
+}
+return false;
+}
+
+/*
+ * Calculate evaluation order for slot opcodes.
+ * Build opcode order graph and output its nodes in topological sort order.
+ * An edge a -> b in the graph means that opcode a must be followed by
+ * opcode b.
+ */
+static bool tsort(struct slot_prop *slot,
+  struct slot_prop *sorted[],
+  unsigned n)
+{
+struct tsnode {
+unsigned n_in_edge;
+unsigned n_out_edge;
+unsigned out_edge[MAX_INSN_SLOTS];
+} node[MAX_INSN_SLOTS];
+
+unsigned in[MAX_INSN_SLOTS];
+unsigned i, j;
+unsigned n_in = 0;
+unsigned n_out = 0;
+unsigned n_edge = 0;
+unsigned in_idx;
+
+for (i = 0; i < n; ++i) {
+node[i].n_in_edge = 0;
+node[i].n_out_edge = 0;
+}
+
+for (i = 0; i < n; ++i) {
+unsigned n_out_edge = 0;
+
+for (j = 0; j < n; ++j) {
+if (i != j && op_depends_on(slot + j, slot + i)) {
+node[i].out_edge[n_out_edge] = j;
+++node[j].n_in_edge;
+++n_out_edge;
+++n_edge;
+}
+}
+node[i].n_out_edge = n_out_edge;
+}
+
+for (i = 0; i < n; ++i) {
+if (!node[i].n_in_edge) {
+in[n_in] = i;
+++n_in;
+}
+}
+
+for (in_idx = 0; in_idx < n_in; ++in_idx) {
+i = in[in_idx];
+sorted[n_out] = slot + i;
+++n_out;
+for (j = 0; j < node[i].n_out_edge; ++j) {
+--n_edge;
+if (--node[node[i].out_edge[j]].n_in_edge == 0) {
+in[n_in] = node[i].out_edge[j];
+++n_in;
+}
+}
+}
+return n_edge == 0;
+}
+
+static void opcode_add_resource(struct slot_prop *op,
+uint32_t resource, char direction,
+int index)
+{
+switch (direction) {
+case 'm':
+case 'i':
+assert(op->n_in < ARRAY_SIZE(op->in));
+op->in[op->n_in].resource = resource;
+op->in[op->n_in].index = index;
+++op->n_in;
+/* fall through */
+case 'o':
+if (direction == 'm' || direction == 'o') {
+assert(op->n_out < ARRAY_SIZE(op->out));
+op->out[op->n_out].resource = resource;
+op->out[op->n_out].index = index;
+++op->n_out;
+}
+break;
+default:
+g_assert_not_reached();
+

Re: [Qemu-devel] [PATCH] Use wide-character ncurses functions.

2019-02-28 Thread no-reply
Patchew URL: https://patchew.org/QEMU/20190228204638.4928-1-ekoh...@gmail.com/



Hi,

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

Message-id: 20190228204638.4928-1-ekoh...@gmail.com
Subject: [Qemu-devel] [PATCH] Use wide-character ncurses functions.
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag]   patchew/20190228204638.4928-1-ekoh...@gmail.com -> 
patchew/20190228204638.4928-1-ekoh...@gmail.com
Switched to a new branch 'test'
5379fb5216 Use wide-character ncurses functions.

=== OUTPUT BEGIN ===
ERROR: do not use C99 // comments
#47: FILE: ui/curses.c:53:
+// 0x0_

ERROR: do not use C99 // comments
#53: FILE: ui/curses.c:59:
+// 0x1_

ERROR: do not use C99 // comments
#59: FILE: ui/curses.c:65:
+// 0x2_

ERROR: do not use C99 // comments
#63: FILE: ui/curses.c:69:
+// 0x3_

ERROR: do not use C99 // comments
#67: FILE: ui/curses.c:73:
+// 0x4_

ERROR: do not use C99 // comments
#71: FILE: ui/curses.c:77:
+// 0x5_

ERROR: do not use C99 // comments
#75: FILE: ui/curses.c:81:
+// 0x6_

ERROR: do not use C99 // comments
#79: FILE: ui/curses.c:85:
+// 0x7_

ERROR: do not use C99 // comments
#83: FILE: ui/curses.c:89:
+// 0x8_

ERROR: do not use C99 // comments
#89: FILE: ui/curses.c:95:
+// 0x9_

ERROR: do not use C99 // comments
#95: FILE: ui/curses.c:101:
+// 0xA_

ERROR: do not use C99 // comments
#101: FILE: ui/curses.c:107:
+// 0xB_

ERROR: do not use C99 // comments
#107: FILE: ui/curses.c:113:
+// 0xC_

ERROR: do not use C99 // comments
#113: FILE: ui/curses.c:119:
+// 0xD_

ERROR: do not use C99 // comments
#119: FILE: ui/curses.c:125:
+// 0xE_

ERROR: do not use C99 // comments
#125: FILE: ui/curses.c:131:
+// 0xF_

total: 16 errors, 0 warnings, 177 lines checked

Commit 5379fb5216b5 (Use wide-character ncurses functions.) has style problems, 
please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20190228204638.4928-1-ekoh...@gmail.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

[Qemu-devel] [PATCH] Use wide-character ncurses functions.

2019-02-28 Thread Eddie Kohler
Hi,

QEMU is unable to display all VGA characters to console output; for
instance, the smiley (VGA character 0x01) is printed just as
\001. However, QEMU links with the wide-character ncurses library,
which can output all VGA characters (since they have Unicode
equivalents). The attached patch switches QEMU to use wide-character
functions, using the VGA character Unicode equivalents from
Wikipedia. It works for me, and I'm hoping something like it would be
acceptable for QEMU.

Thanks for any comments,
Eddie Kohler

***

All VGA console characters have Unicode equivalents, and most
modern terminals can display them.

Signed-off-by: Eddie Kohler 
---
 ui/curses.c | 143 +---
 1 file changed, 92 insertions(+), 51 deletions(-)

diff --git a/ui/curses.c b/ui/curses.c
index 6e0091c3b2..a07528770f 100644
--- a/ui/curses.c
+++ b/ui/curses.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #endif
+#include 
 
 #include "qapi/error.h"
 #include "qemu-common.h"
@@ -48,25 +49,106 @@ static WINDOW *screenpad = NULL;
 static int width, height, gwidth, gheight, invalidate;
 static int px, py, sminx, sminy, smaxx, smaxy;
 
-static chtype vga_to_curses[256];
+static const wchar_t vga_to_wchar[256] = {
+// 0x0_
+L' ', L'\u263A', L'\u263B', L'\u2665',
+L'\u2666', L'\u2663', L'\u2660', L'\u2022',
+L'\u25D8', L'\u25CB', L'\u25D9', L'\u2642',
+L'\u2640', L'\u266A', L'\u266B', L'\u263C',
+
+// 0x1_
+L'\u25BA', L'\u25C4', L'\u2195', L'\u203C',
+L'\u00B6', L'\u00A7', L'\u25AC', L'\u21A8',
+L'\u2191', L'\u2193', L'\u2192', L'\u2190',
+L'\u221F', L'\u2194', L'\u25B2', L'\u25BC',
+
+// 0x2_
+L' ', L'!', L'"', L'#', L'$', L'%', L'&', L'\'',
+L'(', L')', L'*', L'+', L',', L'-', L'.', L'/',
+
+// 0x3_
+L'0', L'1', L'2', L'3', L'4', L'5', L'6', L'7',
+L'8', L'9', L':', L';', L'<', L'=', L'>', L'?',
+
+// 0x4_
+L'@', L'A', L'B', L'C', L'D', L'E', L'F', L'G',
+L'H', L'I', L'J', L'K', L'L', L'M', L'N', L'O',
+
+// 0x5_
+L'P', L'Q', L'R', L'S', L'T', L'U', L'V', L'W',
+L'X', L'Y', L'Z', L'[', L'\\', L']', L'^', L'_',
+
+// 0x6_
+L'`', L'a', L'b', L'c', L'd', L'e', L'f', L'g',
+L'h', L'i', L'j', L'k', L'l', L'm', L'n', L'o',
+
+// 0x7_
+L'p', L'q', L'r', L's', L't', L'u', L'v', L'w',
+L'x', L'y', L'z', L'{', L'|', L'}', L'~', L'\u2302',
+
+// 0x8_
+L'\u00C7', L'\u00FC', L'\u00E9', L'\u00E2',
+L'\u00E4', L'\u00E0', L'\u00E5', L'\u00E7',
+L'\u00EA', L'\u00EB', L'\u00E8', L'\u00EF',
+L'\u00EE', L'\u00EC', L'\u00C4', L'\u00C5',
+
+// 0x9_
+L'\u00C9', L'\u00E6', L'\u00C6', L'\u00F4',
+L'\u00F6', L'\u00F2', L'\u00FB', L'\u00F9',
+L'\u00FF', L'\u00D6', L'\u00DC', L'\u00A2',
+L'\u00A3', L'\u00A5', L'\u20A7', L'\u0192',
+
+// 0xA_
+L'\u00E1', L'\u00ED', L'\u00F3', L'\u00FA',
+L'\u00F1', L'\u00D1', L'\u00AA', L'\u00BA',
+L'\u00BF', L'\u2310', L'\u00AC', L'\u00BD',
+L'\u00BC', L'\u00A1', L'\u00AB', L'\u00BB',
+
+// 0xB_
+L'\u2591', L'\u2592', L'\u2593', L'\u2502',
+L'\u2524', L'\u2561', L'\u2562', L'\u2556',
+L'\u2555', L'\u2563', L'\u2551', L'\u2557',
+L'\u255D', L'\u255C', L'\u255B', L'\u2510',
+
+// 0xC_
+L'\u2514', L'\u2534', L'\u252C', L'\u251C',
+L'\u2500', L'\u253C', L'\u255E', L'\u255F',
+L'\u255A', L'\u2554', L'\u2569', L'\u2566',
+L'\u2560', L'\u2550', L'\u256C', L'\u2567',
+
+// 0xD_
+L'\u2568', L'\u2564', L'\u2565', L'\u2559',
+L'\u2558', L'\u2552', L'\u2553', L'\u256B',
+L'\u256A', L'\u2518', L'\u250C', L'\u2588',
+L'\u2584', L'\u258C', L'\u2590', L'\u2580',
+
+// 0xE_
+L'\u03B1', L'\u00DF', L'\u0393', L'\u03C0',
+L'\u03A3', L'\u03C3', L'\u00B5', L'\u03C4',
+L'\u03A6', L'\u0398', L'\u03A9', L'\u03B4',
+L'\u221E', L'\u03C6', L'\u03B5', L'\u2229',
+
+// 0xF_
+L'\u2261', L'\u00B1', L'\u2265', L'\u2264',
+L'\u2320', L'\u2321', L'\u00F7', L'\u2248',
+L'\u00B0', L'\u2219', L'\u00B7', L'\u221A',
+L'\u207F', L'\u00B2', L'\u25A0', L'\u00A0'
+};
 
 static void curses_update(DisplayChangeListener *dcl,
   int x, int y, int w, int h)
 {
 console_ch_t *line;
-chtype curses_line[width];
+cchar_t curses_line[width];
 
 line = screen + y * width;
 for (h += y; y < h; y ++, line += width) {
 for (x = 0; x < width; x++) {
-chtype ch = line[x] & 0xff;
-chtype at = line[x] & ~0xff;
-if (vga_to_curses[ch]) {
-ch = vga_to_curses[ch];
-}
-curses_line[x] = ch | at;
+curses_line[x].attr = line[x] & ~0xff;
+curses_line[x].chars[0] = vga_to_wchar[line[x] & 0xff];
+curses_line[x].chars[1] = L'\0';
 }
-mvwaddchnstr(screenpad, y, 0, curses_line, width);
+mvwadd_wchnstr(screenpad, y, 0, curses_line, width);
 }
 
 pnoutrefresh(screenpad, py, px, sminy, sminx, smaxy - 1, 

Re: [Qemu-devel] [PATCH v3 1/7] ui/cocoa: Ensure we have the iothread lock when calling into QEMU

2019-02-28 Thread G 3
On Mon, Feb 25, 2019 at 5:24 AM Peter Maydell 
wrote:

> The Cocoa UI should run on the main thread; this is enforced
> in OSX Mojave. In order to be able to run on the main thread,
> we need to make sure we hold the iothread lock whenever we
> call into various QEMU UI midlayer functions.
>
> Signed-off-by: Peter Maydell 
> Reviewed-by: Roman Bolshakov 
> Tested-by: Roman Bolshakov 
> Message-id: 20190214102816.3393-2-peter.mayd...@linaro.org
> ---
> Changes since v2: add with_iothread_lock wrap to the
> qmp_stop()/qmp_cont() calls
> ---
>  ui/cocoa.m | 91 ++
>  1 file changed, 65 insertions(+), 26 deletions(-)
>
> diff --git a/ui/cocoa.m b/ui/cocoa.m
> index e2567d6946..f1171c4865 100644
> --- a/ui/cocoa.m
> +++ b/ui/cocoa.m
> @@ -129,6 +129,21 @@
>  NSTextField *pauseLabel;
>  NSArray * supportedImageFileTypes;
>
> +// Utility function to run specified code block with iothread lock held
> +typedef void (^CodeBlock)(void);
>

Please don't use blocks. It would lock Mac OS X users into having to use
CLang. GCC does not support this non-standard extension.

C function pointers and Objective-C's selectors could work in place of
blocks.

Thank you.


Re: [Qemu-devel] [PATCH] socket: fix blocking udp recvfrom.

2019-02-28 Thread Samuel Thibault
Hello,

llyzs, le jeu. 28 févr. 2019 19:59:12 +0800, a ecrit:
> Sometimes sorecvfrom() is called from slirp.c because revents == G_IO_IN,
> however inside sorecvfrom() function, ioctlsocket() returns 0 bytes available
> and recvfrom could be blocking indefinitely. This adds a non-blocking flag to
> recvfrom and checks data availability.

When ioctlsocket() returns 0 bytes available, we could as well just
immediately return, without even calling recvfrom. We could just move
that ioctlsocket call above the m_get() call, so we can just return
without having to clean up anything.

This however still looks weird. AFAIK, G_IO_IN means that we can make
one recv call and be sure that it won't block. Do you have an idea why
it wouldn't necessarily be the case?

Samuel



Re: [Qemu-devel] [PATCH v2 00/16] Enabling tcg/tests for cris and system mode xtensa & arm

2019-02-28 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/20190228202537.4638-1-alex.ben...@linaro.org/



Hi,

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

Message-id: 20190228202537.4638-1-alex.ben...@linaro.org
Subject: [Qemu-devel] [PATCH v2 00/16] Enabling tcg/tests for cris and system 
mode xtensa & arm
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag]   patchew/20190228202537.4638-1-alex.ben...@linaro.org 
-> patchew/20190228202537.4638-1-alex.ben...@linaro.org
Switched to a new branch 'test'
3817cc66f8 .travis.yml: add softmmu check-tcg tests
5454ef35e8 .travis.yml: separate softfloat from check-tcg
1c72e41070 tests/tcg: enable cris base user-mode tests
74bfebc2ba tests/tcg/cris: align mul operations
c156c31322 tests/tcg/cris: comment out the ccs test
a85ea55327 tests/tcg/cris: cleanup sys.c
3748808883 tests/tcg: split cris tests into bare and libc directories
057b9b0114 tests/docker: add fedora-cris-cross compilers
a0e211db55 tests/tcg/arm: add ARMv6-M UNDEFINED 32-bit instruction test
8dd8472bdd tests/tcg/xtensa: enable system tests
98cf445f43 tests/docker: add debian-xtensa-cross image
a98cb156ea tests/tcg/mips: fix hello-mips compilation
f87abb1245 tests/tcg: add gdb runner variant
8f6ab4e934 tests/tcg: add QEMU_OPT option for test runner
73feb4fff8 tests/tcg: enable tcg tests for softmmu
05b1080f7b tests/tcg: add softmmu awareness to Makefile

=== OUTPUT BEGIN ===
1/16 Checking commit 05b1080f7b30 (tests/tcg: add softmmu awareness to Makefile)
2/16 Checking commit 73feb4fff8c8 (tests/tcg: enable tcg tests for softmmu)
3/16 Checking commit 8f6ab4e9345c (tests/tcg: add QEMU_OPT option for test 
runner)
4/16 Checking commit f87abb12456e (tests/tcg: add gdb runner variant)
5/16 Checking commit a98cb156ea9b (tests/tcg/mips: fix hello-mips compilation)
6/16 Checking commit 98cf445f439f (tests/docker: add debian-xtensa-cross image)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#18: 
new file mode 100644

total: 0 errors, 1 warnings, 42 lines checked

Patch 6/16 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
7/16 Checking commit 8dd8472bdd63 (tests/tcg/xtensa: enable system tests)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#12: 
deleted file mode 100644

total: 0 errors, 1 warnings, 40 lines checked

Patch 7/16 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
8/16 Checking commit a0e211db55c0 (tests/tcg/arm: add ARMv6-M UNDEFINED 32-bit 
instruction test)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#21: 
new file mode 100644

total: 0 errors, 1 warnings, 204 lines checked

Patch 8/16 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
9/16 Checking commit 057b9b0114ea (tests/docker: add fedora-cris-cross 
compilers)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#11: 
new file mode 100644

total: 0 errors, 1 warnings, 8 lines checked

Patch 9/16 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
10/16 Checking commit 37488088838b (tests/tcg: split cris tests into bare and 
libc directories)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#19: 
rename from tests/tcg/cris/check_addcv17.s

ERROR: space prohibited between function name and open parenthesis '('
#432: FILE: tests/tcg/cris/libc/sys.c:6:
+void exit (int status) {

ERROR: code indent should never use tabs
#433: FILE: tests/tcg/cris/libc/sys.c:7:
+^Iregister unsigned int callno asm ("r9") = 1; /* NR_exit */$

ERROR: code indent should never use tabs
#434: FILE: tests/tcg/cris/libc/sys.c:8:
+^Iasm volatile ("break 13\n"$

ERROR: code indent should never use tabs
#435: FILE: tests/tcg/cris/libc/sys.c:9:
+^I^I  :$

ERROR: code indent should never use tabs
#436: FILE: tests/tcg/cris/libc/sys.c:10:
+^I^I  : "r" (callno)$

ERROR: code indent should never use tabs
#437: FILE: tests/tcg/cris/libc/sys.c:11:
+^I^I  : "memory" );$

ERROR: space prohibited before that close parenthesis ')'
#437: FILE: tests/tcg/cris/libc/sys.c:11:
+ : "memory" );

ERROR: code indent should never use tabs
#438: FILE: tests/tcg/cris/libc/sys.c:12:
+^Iwhile(1);$

ERROR: space required before the open parenthesis '('
#438: FILE: tests/tcg/cris/libc/sys.c:12:
+   while(1);

Re: [Qemu-devel] [PATCH] slirp: Fix build with gcc 9

2019-02-28 Thread Samuel Thibault
Hello,

Peter Maydell, le jeu. 28 févr. 2019 18:14:40 +, a ecrit:
> My guess is that this got a packed attribute mistakenly
> by analogy with the struct slirp_arphdr which is used in
> the ArpTable struct -- but that struct really is used to
> match on-the-wire data, and this one is not.

This looks like cargo-culted indeed. Greg, please repost with the size
constraint, we do not need it.

Samuel



[Qemu-devel] [PATCH v2 16/16] .travis.yml: add softmmu check-tcg tests

2019-02-28 Thread Alex Bennée
Signed-off-by: Alex Bennée 
---
 .travis.yml | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/.travis.yml b/.travis.yml
index 71b3c4a7a3..90c5908ae1 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -255,6 +255,12 @@ matrix:
 - ./configure ${CONFIG} --extra-cflags="-g3 -O0 -fsanitize=thread 
-fuse-ld=gold" || { cat config.log && exit 1; }
 
 
+# Run check-tcg against linux-user
 - env:
 - CONFIG="--disable-system"
 - TEST_CMD="make -j3 check-tcg V=1"
+
+# Run check-tcg against softmmu targets
+- env:
+- CONFIG="--target-list=xtensa-softmmu,arm-softmmu"
+- TEST_CMD="make -j3 check-tcg V=1"
-- 
2.20.1




[Qemu-devel] [PATCH v2 14/16] tests/tcg: enable cris base user-mode tests

2019-02-28 Thread Alex Bennée
This converts the existing Makefile into a Makefile.target and updates
it so it can be called by the tcg build system. The original Makefile
didn't set -cpu except for the v17 tests however that has broken (I
assume because linux-user is a "max" cpu) so here I force it to be
crisv17.

I've also replicated the GNU simulator targets (run-FOO-on-sim).

Signed-off-by: Alex Bennée 
---
 tests/docker/Makefile.include   |   1 +
 tests/tcg/cris/Makefile | 168 
 tests/tcg/cris/Makefile.include |   6 ++
 tests/tcg/cris/Makefile.target  |  58 +++
 4 files changed, 65 insertions(+), 168 deletions(-)
 delete mode 100644 tests/tcg/cris/Makefile
 create mode 100644 tests/tcg/cris/Makefile.include
 create mode 100644 tests/tcg/cris/Makefile.target

diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index 83d43c50e4..60314d293a 100644
--- a/tests/docker/Makefile.include
+++ b/tests/docker/Makefile.include
@@ -116,6 +116,7 @@ docker-image-tricore-cross: docker-image-debian9
 DOCKER_PARTIAL_IMAGES += debian-alpha-cross debian-hppa-cross 
debian-m68k-cross debian-sh4-cross
 DOCKER_PARTIAL_IMAGES += debian-sparc64-cross debian-mips64-cross 
debian-riscv64-cross
 DOCKER_PARTIAL_IMAGES += debian-tricore-cross debian-powerpc-cross 
fedora-i386-cross
+DOCKER_PARTIAL_IMAGES += fedora-cris-cross
 
 # Rules for building linux-user powered images
 #
diff --git a/tests/tcg/cris/Makefile b/tests/tcg/cris/Makefile
deleted file mode 100644
index 664b30ce81..00
--- a/tests/tcg/cris/Makefile
+++ /dev/null
@@ -1,168 +0,0 @@
--include ../../../config-host.mak
-
-CROSS=crisv32-axis-linux-gnu-
-SIM=../../../cris-linux-user/qemu-cris -L ./
-SIMG=cris-axis-linux-gnu-run --sysroot=./
-
-CC  = $(CROSS)gcc
-#AS  = $(CROSS)as
-AS = $(CC) -x assembler-with-cpp
-SIZE= $(CROSS)size
-LD  = $(CC)
-OBJCOPY = $(CROSS)objcopy
-
-# we rely on GCC inline:ing the stuff we tell it to in many places here.
-CFLAGS  = -Winline -Wall -g -O2 -static
-NOSTDFLAGS = -nostartfiles -nostdlib
-ASFLAGS += -g -Wa,-I,$(SRC_PATH)/tests/tcg/cris/
-LDLIBS  =
-NOSTDLIBS = -lgcc
-
-CRT= crt.o
-SYS= sys.o
-TESTCASES += check_abs.tst
-TESTCASES += check_addc.tst
-TESTCASES += check_addcm.tst
-TESTCASES += check_addcv17.tst
-TESTCASES += check_addo.tst
-TESTCASES += check_addoq.tst
-TESTCASES += check_addi.tst
-TESTCASES += check_addiv32.tst
-TESTCASES += check_addm.tst
-TESTCASES += check_addr.tst
-TESTCASES += check_addq.tst
-TESTCASES += check_addxc.tst
-TESTCASES += check_addxm.tst
-TESTCASES += check_addxr.tst
-TESTCASES += check_andc.tst
-TESTCASES += check_andm.tst
-TESTCASES += check_andr.tst
-TESTCASES += check_andq.tst
-TESTCASES += check_asr.tst
-TESTCASES += check_ba.tst
-TESTCASES += check_bas.tst
-TESTCASES += check_bcc.tst
-TESTCASES += check_bound.tst
-TESTCASES += check_boundc.tst
-TESTCASES += check_boundr.tst
-TESTCASES += check_btst.tst
-TESTCASES += check_clearfv32.tst
-TESTCASES += check_cmpc.tst
-TESTCASES += check_cmpr.tst
-TESTCASES += check_cmpq.tst
-TESTCASES += check_cmpm.tst
-TESTCASES += check_cmpxc.tst
-TESTCASES += check_cmpxm.tst
-TESTCASES += check_cmp-2.tst
-TESTCASES += check_clrjmp1.tst
-TESTCASES += check_dstep.tst
-TESTCASES += check_ftag.tst
-TESTCASES += check_int64.tst
-# check_jsr is broken.
-#TESTCASES += check_jsr.tst
-TESTCASES += check_mcp.tst
-TESTCASES += check_movei.tst
-TESTCASES += check_mover.tst
-TESTCASES += check_moverm.tst
-TESTCASES += check_moveq.tst
-TESTCASES += check_movemr.tst
-TESTCASES += check_movemrv32.tst
-TESTCASES += check_movecr.tst
-TESTCASES += check_movmp.tst
-TESTCASES += check_movpr.tst
-TESTCASES += check_movprv32.tst
-TESTCASES += check_movdelsr1.tst
-TESTCASES += check_movpmv32.tst
-TESTCASES += check_movsr.tst
-TESTCASES += check_movsm.tst
-TESTCASES += check_movscr.tst
-TESTCASES += check_movur.tst
-TESTCASES += check_movum.tst
-TESTCASES += check_movucr.tst
-TESTCASES += check_mulx.tst
-TESTCASES += check_mulv32.tst
-TESTCASES += check_neg.tst
-TESTCASES += check_not.tst
-TESTCASES += check_lz.tst
-TESTCASES += check_lapc.tst
-TESTCASES += check_lsl.tst
-TESTCASES += check_lsr.tst
-TESTCASES += check_orc.tst
-TESTCASES += check_orm.tst
-TESTCASES += check_orr.tst
-TESTCASES += check_orq.tst
-TESTCASES += check_ret.tst
-TESTCASES += check_swap.tst
-TESTCASES += check_scc.tst
-TESTCASES += check_subc.tst
-TESTCASES += check_subq.tst
-TESTCASES += check_subr.tst
-TESTCASES += check_subm.tst
-TESTCASES += check_glibc_kernelversion.tst
-TESTCASES += check_xarith.tst
-
-TESTCASES += check_hello.ctst
-TESTCASES += check_stat1.ctst
-TESTCASES += check_stat2.ctst
-TESTCASES += check_stat3.ctst
-TESTCASES += check_stat4.ctst
-TESTCASES += check_openpf1.ctst
-TESTCASES += check_openpf2.ctst
-TESTCASES += check_openpf3.ctst
-TESTCASES += check_openpf5.ctst
-TESTCASES += check_mapbrk.ctst
-TESTCASES += check_mmap1.ctst
-TESTCASES += check_mmap2.ctst
-TESTCASES += check_mmap3.ctst
-TESTCASES += 

[Qemu-devel] [PATCH v2 10/16] tests/tcg: split cris tests into bare and libc directories

2019-02-28 Thread Alex Bennée
Bare tests are standalone assembly tests that don't require linking to
any libc and hence can be built with kernel only compilers. The libc
tests need a compiler capable of building properly linked userspace
binaries. As we don't have such a cross compiler at the moment we
won't be building those tests.

Signed-off-by: Alex Bennée 

---
v2
  - split between bare/libc instead of system/user
---
 tests/tcg/cris/{ => bare}/check_addcv17.s |  0
 tests/tcg/cris/{ => bare}/check_addi.s|  0
 tests/tcg/cris/{ => bare}/check_addiv32.s |  0
 tests/tcg/cris/{ => bare}/check_addm.s|  0
 tests/tcg/cris/{ => bare}/check_addq.s|  0
 tests/tcg/cris/{ => bare}/check_addr.s|  0
 tests/tcg/cris/{ => bare}/check_addxc.s   |  0
 tests/tcg/cris/{ => bare}/check_addxm.s   |  0
 tests/tcg/cris/{ => bare}/check_addxr.s   |  0
 tests/tcg/cris/{ => bare}/check_andc.s|  0
 tests/tcg/cris/{ => bare}/check_andm.s|  0
 tests/tcg/cris/{ => bare}/check_andq.s|  0
 tests/tcg/cris/{ => bare}/check_andr.s|  0
 tests/tcg/cris/{ => bare}/check_asr.s |  0
 tests/tcg/cris/{ => bare}/check_ba.s  |  0
 tests/tcg/cris/{ => bare}/check_bas.s |  0
 tests/tcg/cris/{ => bare}/check_bcc.s |  0
 tests/tcg/cris/{ => bare}/check_boundc.s  |  0
 tests/tcg/cris/{ => bare}/check_boundr.s  |  0
 tests/tcg/cris/{ => bare}/check_btst.s|  0
 tests/tcg/cris/{ => bare}/check_clearfv32.s   |  0
 tests/tcg/cris/{ => bare}/check_clrjmp1.s |  0
 tests/tcg/cris/{ => bare}/check_cmp-2.s   |  0
 tests/tcg/cris/{ => bare}/check_cmpc.s|  0
 tests/tcg/cris/{ => bare}/check_cmpm.s|  0
 tests/tcg/cris/{ => bare}/check_cmpq.s|  0
 tests/tcg/cris/{ => bare}/check_cmpr.s|  0
 tests/tcg/cris/{ => bare}/check_cmpxc.s   |  0
 tests/tcg/cris/{ => bare}/check_cmpxm.s   |  0
 tests/tcg/cris/{ => bare}/check_dstep.s   |  0
 tests/tcg/cris/{ => bare}/check_jsr.s |  0
 tests/tcg/cris/{ => bare}/check_lapc.s|  0
 tests/tcg/cris/{ => bare}/check_lsl.s |  0
 tests/tcg/cris/{ => bare}/check_lsr.s |  0
 tests/tcg/cris/{ => bare}/check_mcp.s |  0
 tests/tcg/cris/{ => bare}/check_movdelsr1.s   |  0
 tests/tcg/cris/{ => bare}/check_movecr.s  |  0
 tests/tcg/cris/{ => bare}/check_movei.s   |  0
 tests/tcg/cris/{ => bare}/check_movemr.s  |  0
 tests/tcg/cris/{ => bare}/check_movemrv32.s   |  0
 tests/tcg/cris/{ => bare}/check_mover.s   |  0
 tests/tcg/cris/{ => bare}/check_moverm.s  |  0
 tests/tcg/cris/{ => bare}/check_movmp.s   |  0
 tests/tcg/cris/{ => bare}/check_movpmv32.s|  0
 tests/tcg/cris/{ => bare}/check_movpr.s   |  0
 tests/tcg/cris/{ => bare}/check_movprv32.s|  0
 tests/tcg/cris/{ => bare}/check_movscr.s  |  0
 tests/tcg/cris/{ => bare}/check_movsm.s   |  0
 tests/tcg/cris/{ => bare}/check_movsr.s   |  0
 tests/tcg/cris/{ => bare}/check_movucr.s  |  0
 tests/tcg/cris/{ => bare}/check_movum.s   |  0
 tests/tcg/cris/{ => bare}/check_movur.s   |  0
 tests/tcg/cris/{ => bare}/check_mulv32.s  |  0
 tests/tcg/cris/{ => bare}/check_mulx.s|  0
 tests/tcg/cris/{ => bare}/check_neg.s |  0
 tests/tcg/cris/{ => bare}/check_not.s |  0
 tests/tcg/cris/{ => bare}/check_orc.s |  0
 tests/tcg/cris/{ => bare}/check_orm.s |  0
 tests/tcg/cris/{ => bare}/check_orq.s |  0
 tests/tcg/cris/{ => bare}/check_orr.s |  0
 tests/tcg/cris/{ => bare}/check_ret.s |  0
 tests/tcg/cris/{ => bare}/check_scc.s |  0
 tests/tcg/cris/{ => bare}/check_subc.s|  0
 tests/tcg/cris/{ => bare}/check_subm.s|  0
 tests/tcg/cris/{ => bare}/check_subq.s|  0
 tests/tcg/cris/{ => bare}/check_subr.s|  0
 tests/tcg/cris/{ => bare}/check_xarith.s  |  0
 tests/tcg/cris/{ => bare}/crt.s   |  0
 tests/tcg/cris/{ => bare}/sys.c   |  0
 tests/tcg/cris/{ => bare}/testutils.inc   |  0
 tests/tcg/cris/{ => libc}/check_abs.c |  0
 tests/tcg/cris/{ => libc}/check_addc.c|  0
 tests/tcg/cris/{ => libc}/check_addcm.c   |  0
 tests/tcg/cris/{ => libc}/check_addo.c|  0
 tests/tcg/cris/{ => libc}/check_addoq.c   |  0
 tests/tcg/cris/{ => libc}/check_bound.c   |  0
 tests/tcg/cris/{ => libc}/check_ftag.c|  0
 .../{ => libc}/check_gcctorture_pr28634-1.c   |  0
 .../{ => libc}/check_gcctorture_pr28634.c |  0
 .../{ => libc}/check_glibc_kernelversion.c|  0
 tests/tcg/cris/{ => libc}/check_hello.c   |  0
 tests/tcg/cris/{ => libc}/check_int64.c   |  0
 tests/tcg/cris/{ => libc}/check_lz.c  |  0
 tests/tcg/cris/{ => libc}/check_mapbrk.c  |  0
 tests/tcg/cris/{ => libc}/check_mmap1.c   |  0
 tests/tcg/cris/{ => libc}/check_mmap2.c   |  0
 tests/tcg/cris/{ => libc}/check_mmap3.c   |  0
 tests/tcg/cris/{ => libc}/check_moveq.c   |  0
 tests/tcg/cris/{ => 

[Qemu-devel] [PATCH v2 12/16] tests/tcg/cris: comment out the ccs test

2019-02-28 Thread Alex Bennée
Evidently upstream gcc doesn't like this opcode.

Signed-off-by: Alex Bennée 
---
 tests/tcg/cris/bare/check_btst.s | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/tests/tcg/cris/bare/check_btst.s b/tests/tcg/cris/bare/check_btst.s
index e39fc8f4d6..485deb2006 100644
--- a/tests/tcg/cris/bare/check_btst.s
+++ b/tests/tcg/cris/bare/check_btst.s
@@ -85,12 +85,12 @@
  checkr3 
 
  ; check that X gets cleared and that only the NZ flags are touched.
- move.d0xff, $r0
- move $r0, $ccs
- btst r3,r3
- move $ccs, $r0
- and.d 0xff, $r0
- cmp.d 0xe3, $r0
- test_cc 0 1 0 0
+ ;; move.d 0xff, $r0
+ ;; move $r0, $ccs
+ ;; btst r3,r3
+ ;; move $ccs, $r0
+ ;; and.d 0xff, $r0
+ ;; cmp.d  0xe3, $r0
+ ;; test_cc 0 1 0 0
 
  quit
-- 
2.20.1




[Qemu-devel] [PATCH v2 15/16] .travis.yml: separate softfloat from check-tcg

2019-02-28 Thread Alex Bennée
While used by TCG it is not explicitly part of TCG and the tests can
be run standalone in a minimal build.

Signed-off-by: Alex Bennée 
---
 .travis.yml| 6 ++
 tests/Makefile.include | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index cca57f4314..71b3c4a7a3 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -85,6 +85,12 @@ matrix:
 - CONFIG="--disable-user"
 
 
+# Just build tools and run minimal unit and softfloat checks
+- env:
+- BASE_CONFIG="--enable-tools"
+- CONFIG="--disable-user --disable-system"
+- TEST_CMD="make check-unit check-softfloat -j3"
+
 - env:
 - CONFIG="--enable-debug --enable-debug-tcg --disable-user"
 
diff --git a/tests/Makefile.include b/tests/Makefile.include
index f39b96e250..fb31cc5edf 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -1059,7 +1059,7 @@ clean-tcg-tests-%:
 build-tcg: $(BUILD_TCG_TARGET_RULES)
 
 .PHONY: check-tcg
-check-tcg: check-softfloat $(RUN_TCG_TARGET_RULES)
+check-tcg: $(RUN_TCG_TARGET_RULES)
 
 .PHONY: clean-tcg
 clean-tcg: $(CLEAN_TCG_TARGET_RULES)
-- 
2.20.1




[Qemu-devel] [PATCH v2 08/16] tests/tcg/arm: add ARMv6-M UNDEFINED 32-bit instruction test

2019-02-28 Thread Alex Bennée
From: Stefan Hajnoczi 

Test that 32-bit instructions declared UNDEFINED in the ARMv6-M
Reference Manual really do raise an exception.  Also test that the 6
32-bit instructions defined in the ARMv6-M Reference Manual do not raise
an exception.

Based-on: <20181029194519.15628-1-stefa...@redhat.com>
Signed-off-by: Stefan Hajnoczi 
Message-Id: <20181129185113.30353-1-stefa...@redhat.com>
[AJB: integrated into system tests]
Signed-off-by: Alex Bennée 

---
v2
  - added to series
  - used softmmu-target Makefile with single compile/link step
  - launches with -kernel
  - drop .hex file
---
 tests/tcg/arm/Makefile.softmmu-target |  29 +
 tests/tcg/arm/test-armv6m-undef.S | 154 ++
 tests/tcg/arm/test-armv6m-undef.ld|  21 
 3 files changed, 204 insertions(+)
 create mode 100644 tests/tcg/arm/Makefile.softmmu-target
 create mode 100644 tests/tcg/arm/test-armv6m-undef.S
 create mode 100644 tests/tcg/arm/test-armv6m-undef.ld

diff --git a/tests/tcg/arm/Makefile.softmmu-target 
b/tests/tcg/arm/Makefile.softmmu-target
new file mode 100644
index 00..49d48d8a1c
--- /dev/null
+++ b/tests/tcg/arm/Makefile.softmmu-target
@@ -0,0 +1,29 @@
+# -*- Mode: makefile -*-
+#
+# ARM SoftMMU tests - included from tests/tcg/Makefile
+#
+
+ifeq ($(TARGET_ABI_DIR),arm)
+
+ARM_SRC=$(SRC_PATH)/tests/tcg/arm
+
+# Set search path for all sources
+VPATH  += $(ARM_SRC)
+
+ARM_TESTS=test-armv6m-undef
+
+TESTS += $(ARM_TESTS)
+
+CFLAGS+=-Wl,--build-id=none -x assembler-with-cpp
+LDFLAGS+=-nostdlib -N -static
+
+%: %.S %.ld
+   $(CC) $(CFLAGS) $(ASFLAGS) $< -o $@ $(LDFLAGS) -T $(ARM_SRC)/$@.ld
+
+# Specific Test Rules
+
+test-armv6m-undef: EXTRA_CFLAGS+=-mcpu=cortex-m0
+
+run-test-armv6m-undef: QEMU_OPTS+=-semihosting -M microbit -kernel
+
+endif
diff --git a/tests/tcg/arm/test-armv6m-undef.S 
b/tests/tcg/arm/test-armv6m-undef.S
new file mode 100644
index 00..d18ca56b4a
--- /dev/null
+++ b/tests/tcg/arm/test-armv6m-undef.S
@@ -0,0 +1,154 @@
+/*
+ * Test ARMv6-M UNDEFINED 32-bit instructions
+ *
+ * Copyright 2018 Red Hat Inc.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2
+ * or later. See the COPYING file in the top-level directory.
+ */
+
+/*
+ * Test that UNDEFINED 32-bit instructions fault as expected.  This is an
+ * interesting test because ARMv6-M shares code with its more fully-featured
+ * siblings and it's necessary to verify that its limited instruction set is
+ * emulated correctly.
+ *
+ * The emulator must be invoked with -semihosting so that the test case can
+ * terminate with exit code 0 on success or 1 on failure.
+ *
+ * Failures can be debugged with -d in_asm,int,exec,cpu and the
+ * gdbstub (-S -s).
+ */
+
+.syntax unified
+.cpu cortex-m0
+.thumb
+
+/*
+ * Memory map
+ */
+#define SRAM_BASE 0x2000
+#define SRAM_SIZE (16 * 1024)
+
+/*
+ * Semihosting interface on ARM T32
+ * See "Semihosting for AArch32 and AArch64 Version 2.0 Documentation" by ARM
+ */
+#define semihosting_call bkpt 0xab
+#define SYS_EXIT 0x18
+
+vector_table:
+.word SRAM_BASE + SRAM_SIZE /* 0. SP_main */
+.word exc_reset_thumb   /* 1. Reset */
+.word 0 /* 2. NMI */
+.word exc_hard_fault_thumb  /* 3. HardFault */
+.rept 7
+.word 0 /* 4-10. Reserved */
+.endr
+.word 0 /* 11. SVCall */
+.word 0 /* 12. Reserved */
+.word 0 /* 13. Reserved */
+.word 0 /* 14. PendSV */
+.word 0 /* 15. SysTick */
+.rept 32
+.word 0 /* 16-47. External Interrupts */
+.endr
+
+exc_reset:
+.equ exc_reset_thumb, exc_reset + 1
+.global exc_reset_thumb
+/* The following 32-bit UNDEFINED instructions are tested by executing
+ * them.  The HardFault exception handler should execute and return to
+ * the next test case.  If no exception is raised the test fails.
+ */
+
+/* Table A5-9 32-bit Thumb encoding */
+.short 0b11101000
+.short 0b
+b not_reached
+.short 0b11101000
+.short 0b1000
+b not_reached
+.short 0b1000
+.short 0b
+b not_reached
+.short 0b1000
+.short 0b1000
+b not_reached
+.short 0b
+.short 0b
+b not_reached
+
+/* Table A5-10 Branch and miscellaneous control instructions */
+.short 0b0111
+.short 0b1010
+b not_reached
+
+/* The following are valid 32-bit instructions that must not raise a
+ * HardFault.
+ */
+
+/* B4.2.3 Move to Special Register (moves to IPSR are ignored) */
+msr ipsr, r0
+b 1f
+b not_reached
+1:
+/* B4.2.2 Move from Special Register */
+mrs r0, ipsr
+b 1f
+b not_reached
+1:
+/* A6.7.13 Branch with Link (immediate) */
+bl 1f
+1:
+b 1f
+b 

[Qemu-devel] [PATCH v2 11/16] tests/tcg/cris: cleanup sys.c

2019-02-28 Thread Alex Bennée
This is a mini library which provides helper functions to the tests
which are all currently written in assembly. A bunch of minor changes:

  - removed libc related headers (fedora-cris-cross is a system compiler)
  - re-organised the functions to avoid forward declarations
  - cleaned up brace usage
  - restored exit for _fail case
  - removed tabs and fixed indentation

Signed-off-by: Alex Bennée 
---
 tests/tcg/cris/bare/sys.c | 96 +++
 tests/tcg/cris/libc/sys.c | 23 ++
 2 files changed, 62 insertions(+), 57 deletions(-)

diff --git a/tests/tcg/cris/bare/sys.c b/tests/tcg/cris/bare/sys.c
index 21f08c0747..aa342335d6 100644
--- a/tests/tcg/cris/bare/sys.c
+++ b/tests/tcg/cris/bare/sys.c
@@ -1,59 +1,59 @@
-#include 
-#include 
-#include 
-
-static inline int mystrlen(char *s) {
-   int i = 0;
-   while (s[i])
-   i++;
-   return i;
+/*
+ * Helper functions for CRIS system tests
+ *
+ * There is no libc and only a limited set of headers.
+ */
+
+#include 
+
+void exit(int status)
+{
+register unsigned int callno asm ("r9") = 1; /* NR_exit */
+
+asm volatile ("break 13\n"
+  : /* no outputs */
+  : "r" (callno)
+  : "memory" );
+while(1);
 }
 
-void pass(void) {
-   char s[] = "passed.\n";
-   write (1, s, sizeof (s) - 1);
-   exit (0);
-}
+size_t write(int fd, const void *buf, size_t count)
+{
+register unsigned int callno asm ("r9") = 4; /* NR_write */
+register unsigned int r10 asm ("r10") = fd;
+register const void *r11 asm ("r11") = buf;
+register size_t r12 asm ("r12") = count;
+register unsigned int r asm ("r10");
 
-void _fail(char *reason) {
-   char s[] = "\nfailed: ";
-   int len = mystrlen(reason);
-   write (1, s, sizeof (s) - 1);
-   write (1, reason, len);
-   write (1, "\n", 1);
-// exit (1);
-}
+asm volatile ("break 13\n"
+  : "=r" (r)
+  : "r" (callno), "0" (r10), "r" (r11), "r" (r12)
+  : "memory");
 
-void *memset (void *s, int c, size_t n) {
-   char *p = s;
-   int i;
-   for (i = 0; i < n; i++)
-   p[i] = c;
-   return p;
+return r;
 }
 
-void exit (int status) {
-   register unsigned int callno asm ("r9") = 1; /* NR_exit */
-
-   asm volatile ("break 13\n"
- :
- : "r" (callno)
- : "memory" );
-   while(1)
-   ;
+static inline int mystrlen(char *s)
+{
+int i = 0;
+while (s[i]) {
+i++;
+}
+return i;
 }
 
-ssize_t write (int fd, const void *buf, size_t count) {
-   register unsigned int callno asm ("r9") = 4; /* NR_write */
-   register unsigned int r10 asm ("r10") = fd;
-   register const void *r11 asm ("r11") = buf;
-   register size_t r12 asm ("r12") = count;
-   register unsigned int r asm ("r10");
 
-   asm volatile ("break 13\n"
-: "=r" (r)
-: "r" (callno), "0" (r10), "r" (r11), "r" (r12)
-: "memory");
+void pass(void) {
+char s[] = "passed.\n";
+write(1, s, sizeof (s) - 1);
+exit(0);
+}
 
-   return r;
+void _fail(char *reason) {
+char s[] = "\nfailed: ";
+int len = mystrlen(reason);
+write(1, s, sizeof (s) - 1);
+write(1, reason, len);
+write(1, "\n", 1);
+exit(1);
 }
diff --git a/tests/tcg/cris/libc/sys.c b/tests/tcg/cris/libc/sys.c
index b8e759eee3..6ec4e77b22 100644
--- a/tests/tcg/cris/libc/sys.c
+++ b/tests/tcg/cris/libc/sys.c
@@ -3,16 +3,18 @@
  */
 
 
-void exit (int status) {
+void exit(int status)
+{
register unsigned int callno asm ("r9") = 1; /* NR_exit */
asm volatile ("break 13\n"
  :
  : "r" (callno)
- : "memory" );
+ : "memory");
while(1);
 }
 
-ssize_t write (int fd, const void *buf, size_t count) {
+ssize_t write(int fd, const void *buf, size_t count)
+{
register unsigned int callno asm ("r9") = 4; /* NR_write */
register unsigned int r10 asm ("r10") = fd;
register const void *r11 asm ("r11") = buf;
@@ -27,29 +29,32 @@ ssize_t write (int fd, const void *buf, size_t count) {
return r;
 }
 
-static inline int mystrlen(char *s) {
+static inline int mystrlen(char *s)
+{
int i = 0;
while (s[i])
i++;
return i;
 }
 
-void pass(void) {
+void pass(void)
+{
char s[] = "passed.\n";
-   write (1, s, sizeof (s) - 1);
+   write (1, s, sizeof(s) - 1);
exit (0);
 }
 
-void _fail(char *reason) {
+void _fail(char *reason)
+{
char s[] = "\nfailed: ";
int len = mystrlen(reason);
write (1, s, sizeof (s) - 1);
write (1, reason, len);
write (1, "\n", 1);
-// exit (1);
 }
 
-void *memset (void *s, int c, size_t n) {
+void *memset(void *s, int c, size_t n)
+{
 

[Qemu-devel] [PATCH v2 04/16] tests/tcg: add gdb runner variant

2019-02-28 Thread Alex Bennée
With this you can launch a test in gdb with:

  cd $(BUILD)/tests
  make -f $(SRC)/tests/tcg/Makefile gdb-$(TEST_NAME)

Signed-off-by: Alex Bennée 
---
 tests/tcg/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tests/tcg/Makefile b/tests/tcg/Makefile
index 097e6374ea..47f4298e68 100644
--- a/tests/tcg/Makefile
+++ b/tests/tcg/Makefile
@@ -113,6 +113,9 @@ RUN_TESTS+=$(EXTRA_RUNS)
 run-%: %
$(call run-test, $<, $(QEMU) $(QEMU_OPTS) $<, "$< on $(TARGET_NAME)")
 
+gdb-%: %
+   gdb --args $(QEMU) $(QEMU_OPTS) $<
+
 .PHONY: run
 run: $(RUN_TESTS)
 
-- 
2.20.1




[Qemu-devel] [PATCH v2 13/16] tests/tcg/cris: align mul operations

2019-02-28 Thread Alex Bennée
To avoid:

  Error: dangerous MULS/MULU location; give it higher alignment

Signed-off-by: Alex Bennée 
---
 tests/tcg/cris/bare/check_mulx.s | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/tests/tcg/cris/bare/check_mulx.s b/tests/tcg/cris/bare/check_mulx.s
index d43241a6f5..a7a1f82a82 100644
--- a/tests/tcg/cris/bare/check_mulx.s
+++ b/tests/tcg/cris/bare/check_mulx.s
@@ -3,6 +3,8 @@
 
  .include "testutils.inc"
  start
+
+ .align 4
  moveq -1,r3
  moveq 2,r4
  muls.d r4,r3
@@ -11,6 +13,7 @@
  move mof,r3
  checkr3 
 
+ .align 4
  moveq -1,r3
  moveq 2,r4
  mulu.d r4,r3
@@ -19,6 +22,7 @@
  move mof,r3
  checkr3 1
 
+ .align 4
  moveq 2,r3
  moveq -1,r4
  muls.d r4,r3
@@ -27,6 +31,7 @@
  move mof,r3
  checkr3 
 
+ .align 4
  moveq 2,r3
  moveq -1,r4
  mulu.d r4,r3
@@ -98,6 +103,7 @@
  checkr3 1fffe
  move mof,r3
  checkr3 0
+ nop
 
  moveq 2,r3
  move.d 0x,r4
@@ -138,6 +144,7 @@
  checkr3 fdbdade2
  move mof,r3
  checkr3 
+ nop
 
  move.d 0x5432f789,r4
  move.d 0x78134452,r3
@@ -146,6 +153,7 @@
  checkr3 420fade2
  move mof,r3
  checkr3 0
+ nop
 
  move.d 0xff,r3
  moveq 2,r4
@@ -186,6 +194,7 @@
  checkr3 1
  move mof,r3
  checkr3 0
+ nop
 
  moveq -1,r4
  move.d r4,r3
@@ -194,6 +203,7 @@
  checkr3 fe01
  move mof,r3
  checkr3 0
+ nop
 
  move.d 0xfeda49ff,r4
  move.d r4,r3
@@ -202,6 +212,7 @@
  checkr3 1
  move mof,r3
  checkr3 0
+ nop
 
  move.d 0xfeda49ff,r4
  move.d r4,r3
-- 
2.20.1




[Qemu-devel] [PATCH v2 05/16] tests/tcg/mips: fix hello-mips compilation

2019-02-28 Thread Alex Bennée
The compilation flags for proper building are in the source tree. We
also fix exit to 0 so the result is counted as a success.

Signed-off-by: Alex Bennée 
---
 tests/tcg/mips/Makefile.target | 11 ---
 tests/tcg/mips/hello-mips.c|  2 +-
 2 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/tests/tcg/mips/Makefile.target b/tests/tcg/mips/Makefile.target
index 086625f533..1a994d5525 100644
--- a/tests/tcg/mips/Makefile.target
+++ b/tests/tcg/mips/Makefile.target
@@ -8,15 +8,12 @@ MIPS_SRC=$(SRC_PATH)/tests/tcg/mips
 # Set search path for all sources
 VPATH  += $(MIPS_SRC)
 
+# hello-mips is 32 bit only
+ifeq ($(findstring 64,$(TARGET_NAME)),)
 MIPS_TESTS=hello-mips
 
 TESTS += $(MIPS_TESTS)
 
-hello-mips: CFLAGS+=-ffreestanding
+hello-mips: CFLAGS+=-mno-abicalls -fno-PIC -mabi=32
 hello-mips: LDFLAGS+=-nostdlib
-
-# For MIPS32 and 64 we have a bunch of extra tests in sub-directories
-# however they are intended for system tests.
-
-run-hello-mips: hello-mips
-   $(call skip-test, $<, "BROKEN")
+endif
diff --git a/tests/tcg/mips/hello-mips.c b/tests/tcg/mips/hello-mips.c
index c7052fdf2e..4e1cf501af 100644
--- a/tests/tcg/mips/hello-mips.c
+++ b/tests/tcg/mips/hello-mips.c
@@ -60,5 +60,5 @@ static inline int write(int fd, const char *buf, int len)
 void __start(void)
 {
 write (1, "Hello, World!\n", 14);
-exit1 (42);
+exit1(0);
 }
-- 
2.20.1




[Qemu-devel] [PATCH v2 07/16] tests/tcg/xtensa: enable system tests

2019-02-28 Thread Alex Bennée
Signed-off-by: Alex Bennée 

---
v2
  - use cross CC for linker
  - fix up test selection to skip linker.ld.S
---
 tests/tcg/xtensa/Makefile| 93 
 tests/tcg/xtensa/Makefile.softmmu-target | 40 ++
 2 files changed, 40 insertions(+), 93 deletions(-)
 delete mode 100644 tests/tcg/xtensa/Makefile
 create mode 100644 tests/tcg/xtensa/Makefile.softmmu-target

diff --git a/tests/tcg/xtensa/Makefile b/tests/tcg/xtensa/Makefile
deleted file mode 100644
index 2f5691f75b..00
--- a/tests/tcg/xtensa/Makefile
+++ /dev/null
@@ -1,93 +0,0 @@
--include ../../../config-host.mak
-
-CORE=dc232b
-CROSS=xtensa-$(CORE)-elf-
-
-ifndef XT
-SIM = ../../../xtensa-softmmu/qemu-system-xtensa
-SIMFLAGS = -M sim -cpu $(CORE) -nographic -semihosting -icount 6 $(EXTFLAGS) 
-kernel
-SIMDEBUG = -s -S
-else
-SIM = xt-run
-SIMFLAGS = --xtensa-core=DC_B_232L --exit_with_target_code $(EXTFLAGS)
-SIMDEBUG = --gdbserve=0
-endif
-
-HOST_CC = gcc
-CC  = $(CROSS)gcc
-AS  = $(CROSS)gcc -x assembler-with-cpp
-LD  = $(CROSS)ld
-
-XTENSA_SRC_PATH = $(SRC_PATH)/tests/tcg/xtensa
-INCLUDE_DIRS = $(XTENSA_SRC_PATH) $(SRC_PATH)/target/xtensa/core-$(CORE)
-XTENSA_INC = $(addprefix -I,$(INCLUDE_DIRS))
-
-LDFLAGS = -Tlinker.ld
-
-CRT= crt.o vectors.o
-
-TESTCASES += test_b.tst
-TESTCASES += test_bi.tst
-#TESTCASES += test_boolean.tst
-TESTCASES += test_break.tst
-TESTCASES += test_bz.tst
-TESTCASES += test_cache.tst
-TESTCASES += test_clamps.tst
-TESTCASES += test_extui.tst
-TESTCASES += test_fail.tst
-TESTCASES += test_interrupt.tst
-TESTCASES += test_loop.tst
-TESTCASES += test_mac16.tst
-TESTCASES += test_max.tst
-TESTCASES += test_min.tst
-TESTCASES += test_mmu.tst
-TESTCASES += test_mul16.tst
-TESTCASES += test_mul32.tst
-TESTCASES += test_nsa.tst
-TESTCASES += test_phys_mem.tst
-ifdef XT
-TESTCASES += test_pipeline.tst
-endif
-TESTCASES += test_quo.tst
-TESTCASES += test_rem.tst
-TESTCASES += test_rst0.tst
-TESTCASES += test_s32c1i.tst
-TESTCASES += test_sar.tst
-TESTCASES += test_sext.tst
-TESTCASES += test_shift.tst
-TESTCASES += test_sr.tst
-TESTCASES += test_timer.tst
-TESTCASES += test_windowed.tst
-
-all: build
-
-linker.ld: $(XTENSA_SRC_PATH)/linker.ld.S
-   $(HOST_CC) $(XTENSA_INC) -E -P $< -o $@
-
-%.o: $(XTENSA_SRC_PATH)/%.c
-   $(CC) $(XTENSA_INC) $(CFLAGS) -c $< -o $@
-
-%.o: $(XTENSA_SRC_PATH)/%.S
-   $(CC) $(XTENSA_INC) $(ASFLAGS) -c $< -o $@
-
-%.tst: %.o linker.ld $(XTENSA_SRC_PATH)/macros.inc $(CRT) Makefile
-   $(LD) $(LDFLAGS) $(NOSTDFLAGS) $(CRT) $< -o $@
-
-build: $(TESTCASES)
-
-check: $(addprefix run-, $(TESTCASES))
-
-run-%.tst: %.tst
-   $(SIM) $(SIMFLAGS) ./$<
-
-run-test_fail.tst: test_fail.tst
-   ! $(SIM) $(SIMFLAGS) ./$<
-
-debug-%.tst: %.tst
-   $(SIM) $(SIMDEBUG) $(SIMFLAGS) ./$<
-
-host-debug-%.tst: %.tst
-   gdb --args $(SIM) $(SIMFLAGS) ./$<
-
-clean:
-   $(RM) -fr $(TESTCASES) $(CRT) linker.ld
diff --git a/tests/tcg/xtensa/Makefile.softmmu-target 
b/tests/tcg/xtensa/Makefile.softmmu-target
new file mode 100644
index 00..1a4014506f
--- /dev/null
+++ b/tests/tcg/xtensa/Makefile.softmmu-target
@@ -0,0 +1,40 @@
+#
+# Xtensa softmmu tests
+#
+
+ifneq ($(TARGET_WORDS_BIGENDIAN),y)
+
+XTENSA_SRC = $(SRC_PATH)/tests/tcg/xtensa
+XTENSA_ALL = $(filter-out $(XTENSA_SRC)/linker.ld.S,$(wildcard 
$(XTENSA_SRC)/*.S))
+XTENSA_TESTS = $(patsubst $(XTENSA_SRC)/%.S, %, $(XTENSA_ALL))
+# Filter out common blobs and broken tests
+XTENSA_BROKEN_TESTS  = crt vectors test_boolean test_pipeline test_fail
+XTENSA_USABLE_TESTS = $(filter-out $(XTENSA_BROKEN_TESTS), $(XTENSA_TESTS))
+
+# add to the list of tests
+TESTS += $(XTENSA_USABLE_TESTS)
+VPATH += $(XTENSA_SRC)
+
+CORE=dc232b
+QEMU_OPTS+=-M sim -cpu $(CORE) -nographic -semihosting -icount 6 $(EXTFLAGS) 
-kernel
+
+INCLUDE_DIRS = $(SRC_PATH)/target/xtensa/core-$(CORE)
+XTENSA_INC = $(addprefix -I,$(INCLUDE_DIRS))
+
+LDFLAGS = -Tlinker.ld -nostartfiles -nostdlib
+
+CRT= crt.o vectors.o
+
+linker.ld: linker.ld.S
+   $(CC) $(XTENSA_INC) -E -P $< -o $@
+
+$(XTENSA_USABLE_TESTS): linker.ld macros.inc $(CRT) Makefile.softmmu-target
+
+# special rule for common blobs
+%.o: %.S
+   $(CC) $(XTENSA_INC) $(ASFLAGS) -c $< -o $@
+
+%: %.S
+   $(CC) $(XTENSA_INC) $(ASFLAGS) $< -o $@ $(LDFLAGS) $(NOSTDFLAGS) $(CRT)
+
+endif
-- 
2.20.1




[Qemu-devel] [PATCH v2 06/16] tests/docker: add debian-xtensa-cross image

2019-02-28 Thread Alex Bennée
From: Philippe Mathieu-Daudé 

Xtensa cpu supported:
- dc232b
- dc233c
- csp

Signed-off-by: Philippe Mathieu-Daudé 
Signed-off-by: Alex Bennée 

---
v2
  - the compiler only works for system tests (no libc)
---
 .../dockerfiles/debian-xtensa-cross.docker| 31 +++
 tests/tcg/xtensa/Makefile.include | 11 +++
 2 files changed, 42 insertions(+)
 create mode 100644 tests/docker/dockerfiles/debian-xtensa-cross.docker
 create mode 100644 tests/tcg/xtensa/Makefile.include

diff --git a/tests/docker/dockerfiles/debian-xtensa-cross.docker 
b/tests/docker/dockerfiles/debian-xtensa-cross.docker
new file mode 100644
index 00..afd2ab9163
--- /dev/null
+++ b/tests/docker/dockerfiles/debian-xtensa-cross.docker
@@ -0,0 +1,31 @@
+#
+# Docker cross-compiler target
+#
+# This docker target builds on the debian stretch base image,
+# using a prebuilt toolchains for Xtensa cores from:
+# https://github.com/foss-xtensa/toolchain/releases
+#
+FROM debian:stretch-slim
+
+RUN apt-get update && \
+DEBIAN_FRONTEND=noninteractive apt install -yy eatmydata
+RUN DEBIAN_FRONTEND=noninteractive eatmydata \
+apt-get install -y --no-install-recommends \
+bison \
+build-essential \
+ca-certificates \
+curl \
+flex \
+gettext \
+git \
+python-minimal
+
+ENV CPU_LIST csp dc232b dc233c
+ENV TOOLCHAIN_RELEASE 2018.02
+
+RUN for cpu in $CPU_LIST; do \
+curl -#SL 
http://github.com/foss-xtensa/toolchain/releases/download/$TOOLCHAIN_RELEASE/x86_64-$TOOLCHAIN_RELEASE-xtensa-$cpu-elf.tar.gz
 \
+| tar -xzC /opt; \
+done
+
+ENV PATH 
$PATH:/opt/$TOOLCHAIN_RELEASE/xtensa-dc232b-elf/bin:/opt/$TOOLCHAIN_RELEASE/xtensa-dc233c-elf/bin:/opt/$TOOLCHAIN_RELEASE/xtensa-csp-elf/bin
diff --git a/tests/tcg/xtensa/Makefile.include 
b/tests/tcg/xtensa/Makefile.include
new file mode 100644
index 00..423c00a5d3
--- /dev/null
+++ b/tests/tcg/xtensa/Makefile.include
@@ -0,0 +1,11 @@
+# Makefile.include for xtensa targets
+#
+# The compilers can only be used for building system tests
+
+ifeq ($(CONFIG_SOFTMMU),y)
+DOCKER_IMAGE=debian-xtensa-cross
+
+# default to the dc232b cpu
+DOCKER_CROSS_COMPILER=/opt/2018.02/xtensa-dc232b-elf/bin/xtensa-dc232b-elf-gcc
+DOCKER_CROSS_LINKER=/opt/2018.02/xtensa-dc232b-elf/bin/xtensa-dc232b-elf-ld
+endif
-- 
2.20.1




[Qemu-devel] [PATCH v2 03/16] tests/tcg: add QEMU_OPT option for test runner

2019-02-28 Thread Alex Bennée
This will allow tests to modify the QEMU invocation with for example
different -cpu stazas without having to define a whole new set of
runner types.

Signed-off-by: Alex Bennée 
Reviewed-by: Richard Henderson 

---
v2
  - default QEMU_OPTS to --monitor none for system emulation
---
 tests/tcg/Makefile | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tests/tcg/Makefile b/tests/tcg/Makefile
index 55feab0f67..097e6374ea 100644
--- a/tests/tcg/Makefile
+++ b/tests/tcg/Makefile
@@ -54,10 +54,13 @@ LDFLAGS=
 # The QEMU for this TARGET
 ifdef CONFIG_USER_ONLY
 QEMU=../qemu-$(TARGET_NAME)
+QEMU_OPTS=
 else
 QEMU=../qemu-system-$(TARGET_NAME)
+QEMU_OPTS=--monitor none
 endif
 
+
 # If TCG debugging is enabled things are a lot slower
 ifeq ($(CONFIG_DEBUG_TCG),y)
 TIMEOUT=45
@@ -108,7 +111,7 @@ RUN_TESTS=$(patsubst %,run-%, $(TESTS))
 RUN_TESTS+=$(EXTRA_RUNS)
 
 run-%: %
-   $(call run-test, $<, $(QEMU) $<, "$< on $(TARGET_NAME)")
+   $(call run-test, $<, $(QEMU) $(QEMU_OPTS) $<, "$< on $(TARGET_NAME)")
 
 .PHONY: run
 run: $(RUN_TESTS)
-- 
2.20.1




[Qemu-devel] [PATCH v2 09/16] tests/docker: add fedora-cris-cross compilers

2019-02-28 Thread Alex Bennée
Signed-off-by: Alex Bennée 
---
 tests/docker/dockerfiles/fedora-cris-cross.docker | 8 
 1 file changed, 8 insertions(+)
 create mode 100644 tests/docker/dockerfiles/fedora-cris-cross.docker

diff --git a/tests/docker/dockerfiles/fedora-cris-cross.docker 
b/tests/docker/dockerfiles/fedora-cris-cross.docker
new file mode 100644
index 00..b168ada615
--- /dev/null
+++ b/tests/docker/dockerfiles/fedora-cris-cross.docker
@@ -0,0 +1,8 @@
+#
+# Cross compiler for cris system tests
+#
+
+FROM fedora:latest
+ENV PACKAGES gcc-cris-linux-gnu
+RUN dnf install -y $PACKAGES
+RUN rpm -q $PACKAGES | sort > /packages.txt
-- 
2.20.1




[Qemu-devel] [PATCH v2 00/16] Enabling tcg/tests for cris and system mode xtensa & arm

2019-02-28 Thread Alex Bennée
Hi,

This is the second version of my system tests for TCG. We actually
only enable system tests for ARM and Xtensa but the framework is all
there for adding the others. I thought I'd get this out for comment
before starting on some softmmu tests for my demacro series. Also in
this set:

  - add cris linux-user to check-tcg
  - fixup some mips hello-world
  - gdb test runner
  - .travis.yml tweaks

checkpatch complains a bit due to the motion of the cris tests. I
actually clean-up the errors in the next patch but didn't want to
merge them together in-case something got missed in the noise.

The following patches need review
  patch 0004/tests tcg add gdb runner variant.patch
  patch 0005/tests tcg mips fix hello mips compilation.patch
  patch 0007/tests tcg xtensa enable system tests.patch
  patch 0009/tests docker add fedora cris cross compilers.patch
  patch 0010/tests tcg split cris tests into bare and libc dir.patch
  patch 0011/tests tcg cris cleanup sys.c.patch
  patch 0012/tests tcg cris comment out the ccs test.patch
  patch 0013/tests tcg cris align mul operations.patch
  patch 0014/tests tcg enable cris base user mode tests.patch
  patch 0015/.travis.yml separate softfloat from check tcg.patch
  patch 0016/.travis.yml add softmmu check tcg tests.patch

Alex Bennée (14):
  tests/tcg: add softmmu awareness to Makefile
  tests/tcg: enable tcg tests for softmmu
  tests/tcg: add QEMU_OPT option for test runner
  tests/tcg: add gdb runner variant
  tests/tcg/mips: fix hello-mips compilation
  tests/tcg/xtensa: enable system tests
  tests/docker: add fedora-cris-cross compilers
  tests/tcg: split cris tests into bare and libc directories
  tests/tcg/cris: cleanup sys.c
  tests/tcg/cris: comment out the ccs test
  tests/tcg/cris: align mul operations
  tests/tcg: enable cris base user-mode tests
  .travis.yml: separate softfloat from check-tcg
  .travis.yml: add softmmu check-tcg tests

Philippe Mathieu-Daudé (1):
  tests/docker: add debian-xtensa-cross image

Stefan Hajnoczi (1):
  tests/tcg/arm: add ARMv6-M UNDEFINED 32-bit instruction test

 .travis.yml   |  12 ++
 Makefile.target   |   2 -
 tests/Makefile.include|   9 +-
 tests/docker/Makefile.include |   1 +
 .../dockerfiles/debian-xtensa-cross.docker|  31 
 .../dockerfiles/fedora-cris-cross.docker  |   8 +
 tests/tcg/Makefile|  25 ++-
 tests/tcg/Makefile.include|   2 +-
 tests/tcg/arm/Makefile.softmmu-target |  29 +++
 tests/tcg/arm/test-armv6m-undef.S | 154 
 tests/tcg/arm/test-armv6m-undef.ld|  21 +++
 tests/tcg/cris/Makefile   | 168 --
 tests/tcg/cris/Makefile.include   |   6 +
 tests/tcg/cris/Makefile.target|  58 ++
 tests/tcg/cris/{ => bare}/check_addcv17.s |   0
 tests/tcg/cris/{ => bare}/check_addi.s|   0
 tests/tcg/cris/{ => bare}/check_addiv32.s |   0
 tests/tcg/cris/{ => bare}/check_addm.s|   0
 tests/tcg/cris/{ => bare}/check_addq.s|   0
 tests/tcg/cris/{ => bare}/check_addr.s|   0
 tests/tcg/cris/{ => bare}/check_addxc.s   |   0
 tests/tcg/cris/{ => bare}/check_addxm.s   |   0
 tests/tcg/cris/{ => bare}/check_addxr.s   |   0
 tests/tcg/cris/{ => bare}/check_andc.s|   0
 tests/tcg/cris/{ => bare}/check_andm.s|   0
 tests/tcg/cris/{ => bare}/check_andq.s|   0
 tests/tcg/cris/{ => bare}/check_andr.s|   0
 tests/tcg/cris/{ => bare}/check_asr.s |   0
 tests/tcg/cris/{ => bare}/check_ba.s  |   0
 tests/tcg/cris/{ => bare}/check_bas.s |   0
 tests/tcg/cris/{ => bare}/check_bcc.s |   0
 tests/tcg/cris/{ => bare}/check_boundc.s  |   0
 tests/tcg/cris/{ => bare}/check_boundr.s  |   0
 tests/tcg/cris/{ => bare}/check_btst.s|  14 +-
 tests/tcg/cris/{ => bare}/check_clearfv32.s   |   0
 tests/tcg/cris/{ => bare}/check_clrjmp1.s |   0
 tests/tcg/cris/{ => bare}/check_cmp-2.s   |   0
 tests/tcg/cris/{ => bare}/check_cmpc.s|   0
 tests/tcg/cris/{ => bare}/check_cmpm.s|   0
 tests/tcg/cris/{ => bare}/check_cmpq.s|   0
 tests/tcg/cris/{ => bare}/check_cmpr.s|   0
 tests/tcg/cris/{ => bare}/check_cmpxc.s   |   0
 tests/tcg/cris/{ => bare}/check_cmpxm.s   |   0
 tests/tcg/cris/{ => bare}/check_dstep.s   |   0
 tests/tcg/cris/{ => bare}/check_jsr.s |   0
 tests/tcg/cris/{ => bare}/check_lapc.s|   0
 tests/tcg/cris/{ => bare}/check_lsl.s |   0
 tests/tcg/cris/{ => bare}/check_lsr.s |   0
 tests/tcg/cris/{ => bare}/check_mcp.s |   0
 tests/tcg/cris/{ => bare}/check_movdelsr1.s   |   0
 tests/tcg/cris/{ => bare}/check_movecr.s  |   0
 tests/tcg/cris/{ => bare}/check_movei.s   |   0
 tests/tcg/cris/{ => bare}/check_movemr.s  |   0
 tests/tcg/cris/{ => 

[Qemu-devel] [PATCH v2 01/16] tests/tcg: add softmmu awareness to Makefile

2019-02-28 Thread Alex Bennée
Signed-off-by: Alex Bennée 
Reviewed-by: Richard Henderson 
---
 tests/tcg/Makefile | 17 -
 tests/tcg/Makefile.include |  2 +-
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/tests/tcg/Makefile b/tests/tcg/Makefile
index bf06415390..55feab0f67 100644
--- a/tests/tcg/Makefile
+++ b/tests/tcg/Makefile
@@ -26,7 +26,7 @@
 #
 # We also accept SPEED=slow to enable slower running tests
 #
-# We also expect to be in the tests build dir for the FOO-linux-user.
+# We also expect to be in the tests build dir for the FOO-(linux-user|softmmu).
 #
 
 -include ../../config-host.mak
@@ -52,7 +52,11 @@ QEMU_CFLAGS=
 LDFLAGS=
 
 # The QEMU for this TARGET
+ifdef CONFIG_USER_ONLY
 QEMU=../qemu-$(TARGET_NAME)
+else
+QEMU=../qemu-system-$(TARGET_NAME)
+endif
 
 # If TCG debugging is enabled things are a lot slower
 ifeq ($(CONFIG_DEBUG_TCG),y)
@@ -61,6 +65,7 @@ else
 TIMEOUT=15
 endif
 
+ifdef CONFIG_USER_ONLY
 # The order we include is important. We include multiarch, base arch
 # and finally arch if it's not the same as base arch.
 -include $(SRC_PATH)/tests/tcg/multiarch/Makefile.target
@@ -77,6 +82,16 @@ endif
 
 %: %.c
$(CC) $(CFLAGS) $(EXTRA_CFLAGS) $< -o $@ $(LDFLAGS)
+else
+# For softmmu targets we include a different Makefile fragement as the
+# build options for bare programs are usually pretty different. They
+# are expected to provide their own build recipes.
+-include $(SRC_PATH)/tests/tcg/$(TARGET_BASE_ARCH)/Makefile.softmmu-target
+ifneq ($(TARGET_BASE_ARCH),$(TARGET_NAME))
+-include $(SRC_PATH)/tests/tcg/$(TARGET_NAME)/Makefile.softmmu-target
+endif
+
+endif
 
 all: $(TESTS)
 
diff --git a/tests/tcg/Makefile.include b/tests/tcg/Makefile.include
index c581bd6ffc..73b5626fc5 100644
--- a/tests/tcg/Makefile.include
+++ b/tests/tcg/Makefile.include
@@ -67,7 +67,7 @@ endif
 ifneq ($(GUEST_BUILD),)
 guest-tests: $(GUEST_BUILD)
 
-run-guest-tests: guest-tests qemu-$(TARGET_NAME)
+run-guest-tests: guest-tests qemu-$(subst 
y,system-,$(CONFIG_SOFTMMU))$(TARGET_NAME)
$(call quiet-command, \
(cd tests && $(MAKE) -f $(TCG_MAKE) SPEED=$(SPEED) run), \
"RUN", "tests for $(TARGET_NAME)")
-- 
2.20.1




[Qemu-devel] [PATCH v2 02/16] tests/tcg: enable tcg tests for softmmu

2019-02-28 Thread Alex Bennée
Signed-off-by: Alex Bennée 
Reviewed-by: Richard Henderson 
---
 Makefile.target| 2 --
 tests/Makefile.include | 7 +++
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index 3b79e7074c..61b8be31a2 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -37,9 +37,7 @@ PROGS=$(QEMU_PROG) $(QEMU_PROGW)
 STPFILES=
 
 # Makefile Tests
-ifdef CONFIG_USER_ONLY
 include $(SRC_PATH)/tests/tcg/Makefile.include
-endif
 
 config-target.h: config-target.h-timestamp
 config-target.h-timestamp: config-target.mak
diff --git a/tests/Makefile.include b/tests/Makefile.include
index 2187b0c5aa..f39b96e250 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -1030,10 +1030,9 @@ endif
 
 # Per guest TCG tests
 
-LINUX_USER_TARGETS=$(filter %-linux-user,$(TARGET_DIRS))
-BUILD_TCG_TARGET_RULES=$(patsubst %,build-tcg-tests-%, $(LINUX_USER_TARGETS))
-CLEAN_TCG_TARGET_RULES=$(patsubst %,clean-tcg-tests-%, $(LINUX_USER_TARGETS))
-RUN_TCG_TARGET_RULES=$(patsubst %,run-tcg-tests-%, $(LINUX_USER_TARGETS))
+BUILD_TCG_TARGET_RULES=$(patsubst %,build-tcg-tests-%, $(TARGET_DIRS))
+CLEAN_TCG_TARGET_RULES=$(patsubst %,clean-tcg-tests-%, $(TARGET_DIRS))
+RUN_TCG_TARGET_RULES=$(patsubst %,run-tcg-tests-%, $(TARGET_DIRS))
 
 ifeq ($(HAVE_USER_DOCKER),y)
 # Probe for the Docker Builds needed for each build
-- 
2.20.1




[Qemu-devel] [PATCH v4] spapr-rtas: add ibm, get-vpd RTAS interface

2019-02-28 Thread Maxiwell S. Garcia
This adds a handler for ibm,get-vpd RTAS calls, allowing pseries guest
to collect host information. It is disabled by default to avoid unwanted
information leakage. To enable it, use:

‘-M pseries,host-serial={passthrough|string},host-model={passthrough|string}’

Only the SE and TM keywords are returned at the moment.
SE for Machine or Cabinet Serial Number and
TM for Machine Type and Model

The SE and TM keywords are controlled by 'host-serial' and 'host-model'
options, respectively. In the case of 'passthrough', the SE shows the
host 'system-id' information and the TM shows the host 'model' information.

Powerpc-utils tools can dispatch RTAS calls to retrieve host
information using this ibm,get-vpd interface. The 'host-serial'
and 'host-model' nodes of device-tree hold the same information but
in a static manner, which is useless after a migration operation.

Signed-off-by: Maxiwell S. Garcia 
---
 hw/ppc/spapr_rtas.c| 121 +
 include/hw/ppc/spapr.h |  17 +-
 2 files changed, 137 insertions(+), 1 deletion(-)

Update v4:
* Allows enable/disable host-serial and host-model options individually

diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
index 7a2cb786a3..785c453eb6 100644
--- a/hw/ppc/spapr_rtas.c
+++ b/hw/ppc/spapr_rtas.c
@@ -287,6 +287,123 @@ static void rtas_ibm_set_system_parameter(PowerPCCPU *cpu,
 rtas_st(rets, 0, ret);
 }
 
+static inline int vpd_st(target_ulong addr, target_ulong len,
+ const void *val, uint16_t val_len)
+{
+hwaddr phys = ppc64_phys_to_real(addr);
+if (len < val_len) {
+return RTAS_OUT_PARAM_ERROR;
+}
+cpu_physical_memory_write(phys, val, val_len);
+return RTAS_OUT_SUCCESS;
+}
+
+static inline void vpd_ret(target_ulong rets, const int status,
+   const int next_seq_number, const int bytes_returned)
+{
+rtas_st(rets, 0, status);
+rtas_st(rets, 1, next_seq_number);
+rtas_st(rets, 2, bytes_returned);
+}
+
+static void rtas_ibm_get_vpd_register_keywords(sPAPRMachineState *sm)
+{
+sm->rtas_vpd_keywords = g_malloc0(sizeof(uint8_t) *
+RTAS_IBM_VPD_KEYWORDS_MAX);
+
+int i = 0;
+if (sm->host_serial && !g_str_equal(sm->host_serial, "none")) {
+sm->rtas_vpd_keywords[i++] = RTAS_IBM_VPD_KEYWORD_SE;
+}
+if (sm->host_model && !g_str_equal(sm->host_model, "none")) {
+sm->rtas_vpd_keywords[i++] = RTAS_IBM_VPD_KEYWORD_TM;
+}
+}
+
+static void rtas_ibm_get_vpd(PowerPCCPU *cpu,
+ sPAPRMachineState *spapr,
+ uint32_t token, uint32_t nargs,
+ target_ulong args,
+ uint32_t nret, target_ulong rets)
+{
+target_ulong loc_code_addr;
+target_ulong work_area_addr;
+target_ulong work_area_size;
+target_ulong seq_number;
+unsigned char loc_code = 0;
+unsigned int next_seq_number = 1;
+int status = RTAS_IBM_GET_VPD_PARAMETER_ERROR;
+int ret = RTAS_OUT_PARAM_ERROR;
+char *buf = NULL;
+char *vpd_field = NULL;
+unsigned int vpd_field_len = 0;
+
+/* RTAS not authorized if no keywords have been registered */
+if (!spapr->rtas_vpd_keywords[0]) {
+vpd_ret(rets, RTAS_OUT_NOT_AUTHORIZED, 1, 0);
+return;
+}
+
+loc_code_addr = rtas_ld(args, 0);
+work_area_addr = rtas_ld(args, 1);
+work_area_size = rtas_ld(args, 2);
+seq_number = rtas_ld(args, 3);
+
+/* Specific Location Code is not supported and seq_number */
+/* must be checked to avoid out of bound index error */
+cpu_physical_memory_read(loc_code_addr, _code, 1);
+if ((loc_code != 0) || (seq_number <= 0) ||
+(seq_number > RTAS_IBM_VPD_KEYWORDS_MAX)) {
+vpd_ret(rets, RTAS_IBM_GET_VPD_PARAMETER_ERROR, 1, 0);
+return;
+}
+
+switch (spapr->rtas_vpd_keywords[seq_number - 1]) {
+case RTAS_IBM_VPD_KEYWORD_SE:
+if (g_str_equal(spapr->host_serial, "passthrough")) {
+/* -M host-serial=passthrough */
+if (kvmppc_get_host_serial()) {
+/* LoPAPR: SE for Machine or Cabinet Serial Number */
+vpd_field = g_strdup_printf("SE %s", buf);
+}
+} else {
+vpd_field = g_strdup_printf("SE %s", spapr->host_serial);
+}
+break;
+case RTAS_IBM_VPD_KEYWORD_TM:
+if (g_str_equal(spapr->host_model, "passthrough")) {
+/* -M host-model=passthrough */
+if (kvmppc_get_host_model()) {
+/* LoPAPR: TM for Machine Type and Model */
+vpd_field = g_strdup_printf("TM %s", buf);
+}
+} else {
+vpd_field = g_strdup_printf("TM %s", spapr->host_model);
+}
+break;
+}
+
+if (vpd_field) {
+vpd_field_len = strlen(vpd_field);
+ret = vpd_st(work_area_addr, work_area_size,
+ vpd_field, 

Re: [Qemu-devel] [PATCH v1 33/33] s390x/tcg: Implement VECTOR UNPACK *

2019-02-28 Thread David Hildenbrand
On 28.02.19 19:22, Richard Henderson wrote:
> On 2/28/19 2:54 AM, David Hildenbrand wrote:
>> Hmm, as v2 and v3 are handled concatenated it is not that easy. I am not
>> sure if we can handle this without a temporary vector.
>>
>> I thought about packing them first interleaved
>>
>> v2 = [v2e0, v2e1]
>> v3 = [v3e0, ve31]
>> v1 = [v2e0_packed, v3e0_packed, v2e1_packed, v3e1_packed]
>>
>> And then restoring the right order
>>
>> v1 = [v2e0_packed, v2e1_packed, v3e0_packed, v3e1_packed]
>>
>> But than the second operation seems to be the problem. That shuffling
>> would have to be hard coded as far as I can see. (shuffling with MO_8 is
>> nasty -> 14 element shave to be exchanged, in my opinion needing
>> eventually 14 temporary variables)
> 
> I suppose you could do it in registers.
> 
>   load_element_i64(t1, v2, 0);
>   for (i = 1; i < N; i++) {
> load_element_i64(t3, v2, i, es);
> tcg_gen_deposit_i64(t1, t1, t3, i << es, 1 << es);
>   }
>   // repeat for v3 into t2
>   // store t1,t2 into v1.
> 
> Now you have only 3 temporaries, which is manageable.
> 
> The only question, when it comes to MO_8, is whether the code expansion of 
> this
> is reasonable (16 byte loads, 15 deposits, 2 stores -- minimum 33 insns,
> probably 48 for x86_64 host), or whether a helper function would be better in
> the end.  But then the same is true for all of the other merge & unpack
> operations wrt MO_8.

And it would only apply when dst==src. Will have a try what looks "less
ugly" :) Thanks!

> 
> 
> r~
> 


-- 

Thanks,

David / dhildenb



Re: [Qemu-devel] [PATCH v1 14/33] s390x/tcg: Implement VECTOR LOAD MULTIPLE

2019-02-28 Thread David Hildenbrand
On 28.02.19 18:15, Richard Henderson wrote:
> On 2/28/19 12:36 AM, David Hildenbrand wrote:
>> On 27.02.19 17:02, Richard Henderson wrote:
>>> On 2/26/19 3:38 AM, David Hildenbrand wrote:
 Also fairly easy to implement. One issue we have is that exceptions will
 result in some vectors already being modified. At least handle it
 consistently per vector by using a temporary vector. Good enough for
 now, add a FIXME.

 Signed-off-by: David Hildenbrand 
 ---
  target/s390x/insn-data.def  |  2 ++
  target/s390x/translate_vx.inc.c | 26 ++
  2 files changed, 28 insertions(+)
>>>
>>> I suppose the fixme is good enough.  For the record, I think you could do 
>>> the
>>> check with just two loads -- the first and last quadword.  After that, none 
>>> of
>>> the other loads can fault, and you can store everything else into the
>>> destination vectors as you read them.
>>
>> Aren't such approaches prone to races if other VCPUs invalidate page
>> tables/TLB entries?
> 
> No, because...
> 
>> (or am I messing up things and the MMU of this VCPU won't be touched
>> while in this block and once we touched all applicable pages, it cannot
>> fail anymore?)
> 
> Correct.
> 
> If vcpu 1 does a global invalidate, the time at which vcpu 2 acknowledges that
> invalidate is somewhat fluid.  VCPU 2 will see an interrupt, exit at a TB
> boundary, and then acknowledge.
> 
> VCPU 1 has to wait for the ack before it knows the operation is complete.
> 
> Thus no race within any given instruction's execution.

Okay, rings a bell, thanks! :)

So for writing from helpers, I can use probe_write(). What about testing
write access from TCG code?

I could do a load, followed by a store of the loaded value. This should
work in most cases (but eventually could be observed by somebody really
wanting to observe it - which is highly unlikely).


-- 

Thanks,

David / dhildenb



Re: [Qemu-devel] [PULL 00/16] target-arm queue

2019-02-28 Thread Peter Maydell
On Thu, 28 Feb 2019 at 11:08, Peter Maydell  wrote:
>
> The following changes since commit adf2e451f357e993f173ba9b4176dbf3e65fee7e:
>
>   Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging 
> (2019-02-26 19:04:47 +)
>
> are available in the Git repository at:
>
>   https://git.linaro.org/people/pmaydell/qemu-arm.git 
> tags/pull-target-arm-20190228-1
>
> for you to fetch changes up to 1c9af3a9e05c1607a36df4943f8f5393d7621a91:
>
>   linux-user: Enable HWCAP_ASIMDFHM, HWCAP_JSCVT (2019-02-28 11:03:05 +)
>
> 
> target-arm queue:
>  * add MHU and dual-core support to Musca boards
>  * refactor some VFP insns to be gated by ID registers
>  * Revert "arm: Allow system registers for KVM guests to be changed by QEMU 
> code"
>  * Implement ARMv8.2-FHM extension
>  * Advertise JSCVT via HWCAP for linux-user
>


Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.0
for any user-visible changes.

-- PMM



Re: [Qemu-devel] [PULL 40/50] spapr_events: add support for phb hotplug events

2019-02-28 Thread Thomas Huth
On 26/02/2019 05.52, David Gibson wrote:
> From: Michael Roth 
> 
> Extend the existing EPOW event format we use for PCI
> devices to emit PHB plug/unplug events.
> 
> Signed-off-by: Michael Roth 
> Reviewed-by: David Gibson 
> Signed-off-by: Greg Kurz 
> Message-Id: 
> <155059671405.1466090.535964535260503283.st...@bahia.lab.toulouse-stg.fr.ibm.com>
> Signed-off-by: David Gibson 
> ---
>  hw/ppc/spapr_events.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/hw/ppc/spapr_events.c b/hw/ppc/spapr_events.c
> index b9c7ecb9e9..ab9a1f0063 100644
> --- a/hw/ppc/spapr_events.c
> +++ b/hw/ppc/spapr_events.c
> @@ -526,6 +526,9 @@ static void spapr_hotplug_req_event(uint8_t hp_id, 
> uint8_t hp_action,
>  case SPAPR_DR_CONNECTOR_TYPE_CPU:
>  hp->hotplug_type = RTAS_LOG_V6_HP_TYPE_CPU;
>  break;
> +case SPAPR_DR_CONNECTOR_TYPE_PHB:
> +hp->hotplug_type = RTAS_LOG_V6_HP_TYPE_PHB;
> +break;
>  default:
>  /* we shouldn't be signaling hotplug events for resources
>   * that don't support them

I think this patch (or something else in this PULL request) broke CPU
hot-plugging with older machine types:

$ QTEST_QEMU_BINARY=ppc64-softmmu/qemu-system-ppc64 ./tests/cpu-plug-test 
-m=slow
/ppc64/cpu-plug/pseries-3.1/device-add/2x3x1=6: OK
/ppc64/cpu-plug/pseries-2.12-sxxm/device-add/2x3x1=6: OK
/ppc64/cpu-plug/pseries-3.0/device-add/2x3x1=6: OK
/ppc64/cpu-plug/pseries-2.10/device-add/2x3x1=6: OK
/ppc64/cpu-plug/pseries-2.11/device-add/2x3x1=6: OK
/ppc64/cpu-plug/pseries-2.12/device-add/2x3x1=6: OK
/ppc64/cpu-plug/pseries-2.9/device-add/2x3x1=6: OK
/ppc64/cpu-plug/pseries-2.7/device-add/2x3x1=6: **
ERROR:/home/thuth/devel/qemu/hw/ppc/spapr_events.c:313:rtas_event_log_to_source:
 assertion failed: (source->enabled)
Broken pipe
/home/thuth/devel/qemu/tests/libqtest.c:143: kill_qemu() detected QEMU death 
from signal 6 (Aborted) (core dumped)
Aborted (core dumped)

Could you please have a look?

 Thomas



Re: [Qemu-devel] [PATCH] virtio-blk: dataplane: release AioContext before blk_set_aio_context

2019-02-28 Thread Sergio Lopez
On Thu, Feb 28, 2019 at 06:22:02PM +0100, Kevin Wolf wrote:
> Am 28.02.2019 um 18:04 hat Sergio Lopez geschrieben:
> > On Thu, Feb 28, 2019 at 04:50:53PM +0100, Kevin Wolf wrote:
> > > Am 28.02.2019 um 16:01 hat Sergio Lopez geschrieben:
> > > > On Wed, Feb 27, 2019 at 06:37:14PM +0100, Kevin Wolf wrote:
> > > > > Am 27.02.2019 um 17:52 hat Sergio Lopez geschrieben:
> > > > > > Stopping the dataplane requires calling to blk_set_aio_context, 
> > > > > > which
> > > > > > may need to wait for a running job to be completed or paused.
> > > > > > 
> > > > > > As stopping the dataplane is something that can be triggered from a 
> > > > > > vcpu
> > > > > > thread (due to the Guest requesting to stop the device), while the 
> > > > > > job
> > > > > > itself may be managed by an iothread, holding the AioContext will 
> > > > > > lead
> > > > > > to a deadlock, where the first one is waiting for the job to pause 
> > > > > > or
> > > > > > finish, while the second can't make any progress as it's waiting 
> > > > > > for the
> > > > > > AioContext to be released:
> > > > > > 
> > > > > >  Thread 6 (LWP 90472)
> > > > > >  #0  0x55a6f8497aee in blk_root_drained_end
> > > > > >  #1  0x55a6f84a7926 in bdrv_parent_drained_end
> > > > > >  #2  0x55a6f84a799f in bdrv_do_drained_end
> > > > > >  #3  0x55a6f84a82ab in bdrv_drained_end
> > > > > >  #4  0x55a6f8498be8 in blk_drain
> > > > > >  #5  0x55a6f84a22cd in mirror_drain
> > > > > >  #6  0x55a6f8457708 in block_job_detach_aio_context
> > > > > >  #7  0x55a6f84538f1 in bdrv_detach_aio_context
> > > > > >  #8  0x55a6f8453a96 in bdrv_set_aio_context
> > > > > >  #9  0x55a6f84999f8 in blk_set_aio_context
> > > > > >  #10 0x55a6f81802c8 in virtio_blk_data_plane_stop
> > > > > >  #11 0x55a6f83cfc95 in virtio_bus_stop_ioeventfd
> > > > > >  #12 0x55a6f83d1f81 in virtio_pci_common_write
> > > > > >  #13 0x55a6f83d1f81 in virtio_pci_common_write
> > > > > >  #14 0x55a6f8148d62 in memory_region_write_accessor
> > > > > >  #15 0x55a6f81459c9 in access_with_adjusted_size
> > > > > >  #16 0x55a6f814a608 in memory_region_dispatch_write
> > > > > >  #17 0x55a6f80f1f98 in flatview_write_continue
> > > > > >  #18 0x55a6f80f214f in flatview_write
> > > > > >  #19 0x55a6f80f6a7b in address_space_write
> > > > > >  #20 0x55a6f80f6b15 in address_space_rw
> > > > > >  #21 0x55a6f815da08 in kvm_cpu_exec
> > > > > >  #22 0x55a6f8132fee in qemu_kvm_cpu_thread_fn
> > > > > >  #23 0x55a6f8551306 in qemu_thread_start
> > > > > >  #24 0x7f9bdf5b9dd5 in start_thread
> > > > > >  #25 0x7f9bdf2e2ead in clone
> > > > > > 
> > > > > >  Thread 8 (LWP 90467)
> > > > > >  #0  0x7f9bdf5c04ed in __lll_lock_wait
> > > > > >  #1  0x7f9bdf5bbde6 in _L_lock_941
> > > > > >  #2  0x7f9bdf5bbcdf in __GI___pthread_mutex_lock
> > > > > >  #3  0x55a6f8551447 in qemu_mutex_lock_impl
> > > > > >  #4  0x55a6f854be77 in co_schedule_bh_cb
> > > > > >  #5  0x55a6f854b781 in aio_bh_poll
> > > > > >  #6  0x55a6f854b781 in aio_bh_poll
> > > > > >  #7  0x55a6f854f01b in aio_poll
> > > > > >  #8  0x55a6f825a488 in iothread_run
> > > > > >  #9  0x55a6f8551306 in qemu_thread_start
> > > > > >  #10 0x7f9bdf5b9dd5 in start_thread
> > > > > >  #11 0x7f9bdf2e2ead in clone
> > > > > > 
> > > > > >  (gdb) thread 8
> > > > > >  [Switching to thread 8 (Thread 0x7f9bd6dae700 (LWP 90467))]
> > > > > >  #3  0x55a6f8551447 in qemu_mutex_lock_impl 
> > > > > > (mutex=0x55a6fac8fea0,
> > > > > >  file=0x55a6f8730c3f "util/async.c", line=511) at 
> > > > > > util/qemu-thread-posix.c:66
> > > > > >  66 err = pthread_mutex_lock(>lock);
> > > > > >  (gdb) up 3
> > > > > >  #3  0x55a6f8551447 in qemu_mutex_lock_impl 
> > > > > > (mutex=0x55a6fac8fea0,
> > > > > >  file=0x55a6f8730c3f "util/async.c", line=511) at 
> > > > > > util/qemu-thread-posix.c:66
> > > > > >  66 err = pthread_mutex_lock(>lock);
> > > > > >  (gdb) p mutex.lock.__data.__owner
> > > > > >  $6 = 90472
> > > > > > 
> > > > > > Signed-off-by: Sergio Lopez 
> > > > > > ---
> > > > > >  hw/block/dataplane/virtio-blk.c | 3 +--
> > > > > >  1 file changed, 1 insertion(+), 2 deletions(-)
> > > > > > 
> > > > > > diff --git a/hw/block/dataplane/virtio-blk.c 
> > > > > > b/hw/block/dataplane/virtio-blk.c
> > > > > > index 8c37bd314a..358e6ae89b 100644
> > > > > > --- a/hw/block/dataplane/virtio-blk.c
> > > > > > +++ b/hw/block/dataplane/virtio-blk.c
> > > > > > @@ -280,12 +280,11 @@ void virtio_blk_data_plane_stop(VirtIODevice 
> > > > > > *vdev)
> > > > > >  
> > > > > >  aio_context_acquire(s->ctx);
> > > > > >  aio_wait_bh_oneshot(s->ctx, virtio_blk_data_plane_stop_bh, s);
> > > > > > +aio_context_release(s->ctx);
> > > > > >  
> > > > > >  /* Drain and switch bs back to the QEMU main loop */
> > > > > >  blk_set_aio_context(s->conf->conf.blk, qemu_get_aio_context());
> > > > > >  
> > > > 

Re: [Qemu-devel] [PATCH v6 0/3] nbd: support for authorization control on TLS connections

2019-02-28 Thread Eric Blake
On 2/27/19 10:20 AM, Daniel P. Berrangé wrote:
> This series provides the NBD parts of the authorization control series
> previously posted as:
> 
>   v1: https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg04482.html
>   v2: https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg05727.html
>   v3: https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg01639.html
>   v4: https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg04319.html
> 
> Then separated for merge:
> 
>   v5: https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg07347.html
> 
> The core authz framework is now merged & these patches have all had
> positive review. Thus these NBD parts are ready to go into the NBD
> maintainer's tree, should the maintainer consider them acceptable.

Thanks; series is queued for my next pull request.

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



Re: [Qemu-devel] [PATCH] usb-mtp: Fix build with gcc 9

2019-02-28 Thread Peter Maydell
On Thu, 28 Feb 2019 at 17:57, Greg Kurz  wrote:
>
> Build fails with gcc 9:
>
>   CC  hw/usb/dev-mtp.o
> hw/usb/dev-mtp.c: In function ‘usb_mtp_write_metadata’:
> hw/usb/dev-mtp.c:1754:36: error: taking address of packed member of ‘struct 
> ’ may result in an unaligned pointer value 
> [-Werror=address-of-packed-member]
>  1754 | dataset->filename);
>   | ~~~^~
> cc1: all warnings being treated as errors
>
> The way the MTP protocol encodes strings with a leading 8-bit unsigned
> integer containing the string length causes the @filename field of the
> packed ObjectInfo structure to be unaligned.
>
> Use a temporary buffer for the utf16 filename instead of passing the
> dataset->filename pointer around.
>
> Signed-off-by: Greg Kurz 
> ---
>  hw/usb/dev-mtp.c |   18 +++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
> index 4ee4fc5a893a..8a0ef7f9f4a8 100644
> --- a/hw/usb/dev-mtp.c
> +++ b/hw/usb/dev-mtp.c
> @@ -1692,13 +1692,25 @@ static void usb_mtp_write_metadata(MTPState *s, 
> uint64_t dlen)
>  MTPObject *o;
>  MTPObject *p = usb_mtp_object_lookup(s, s->dataset.parent_handle);
>  uint32_t next_handle = s->next_handle;
> +uint16_t *utf16_filename;
> +uint8_t filename_len;
>
>  assert(!s->write_pending);
>  assert(p != NULL);
>
> -filename = utf16_to_str(MIN(dataset->length,
> -dlen - offsetof(ObjectInfo, filename)),
> -dataset->filename);
> +/*
> + * MTP Specification 3.2.3 Strings
> + * Strings in PTP (and thus MTP) consist of standard 2-byte Unicode
> + * characters as defined by ISO 10646. Strings begin with a single, 8-bit
> + * unsigned integer that identifies the number of characters to follow 
> (not
> + * bytes).
> + *
> + * This causes dataset->filename to be unaligned.
> + */
> +filename_len = MIN(dataset->length, dlen - offsetof(ObjectInfo, 
> filename));
> +utf16_filename = g_memdup(dataset->filename, filename_len * 2);
> +filename = utf16_to_str(filename_len, utf16_filename);
> +g_free(utf16_filename);

I think there's an underlying problem with this code which we
should deal with differently. The 'dataset' local in this
file is (I think) pointing at on-the-wire information from
the USB device, but we're treating it as an array of
host-order uint16_t values. Is this really correct on a
big-endian host ? Do we do the right thing if we are
passed a malicious USB packet that ends halfway through a
utf16_t character, or do we index off the end of the packet
data ?

I think that we should define the "filename" field in
ObjectInfo to be a uint8_t array, make utf16_to_str()
take a uint8_t* for its data array, and have it do the
reading of data from the array with lduw_he_p(), which
can handle accessing unaligned data.

We should also check what the endianness of other fields in
the ObjectInfo struct is (eg "format" and "size" and see
whether we should be doing byte swapping here.

PS: it is a bit confusing that in this function the local
variable "dataset" is a pointer to a struct of entirely
different type to the one that s->dataset is.

thanks
-- PMM



Re: [Qemu-devel] [PATCH v6 1/3] qemu-nbd: add support for authorization of TLS clients

2019-02-28 Thread Eric Blake
On 2/28/19 12:18 PM, Daniel P. Berrangé wrote:

>> It doesn't hold up this patch, but I note that with the qemu QMP command
>> changes you make in 2/3, you document that the object can be
>> created/removed on the fly, and the server will adjust which clients can
>> then subsequently connect. Is there any need for the same sort of
>> runtime configurability in qemu-nbd, and if so, how would we accomplish
>> it?  Perhaps by having a command-line option to parse --tls-authz from a
>> file, where you can send SIGHUP to qemu-nbd to force it to re-read the
>> file?  Or am I worrying about something unlikely to be needed in practice?
> 
> Well the QAuthZListFile object type can store its contents in an external
> file that gets auto-reloaded upon inotify triggers from the main loop.
> The QAuthZPAM type can also be fairly dynamic depending on its backend.
> I think any single process is unlikely  to need to switch between
> different object types, so this is good enough dynamic support.

That, and QMP nbd-server-start can serve up multiple exports, while
qemu-nbd serves exactly one export.

I also note that my work on incremental backups has raised the topic
that we someday want to support multiple parallel NBD servers.  Right
now, you are limited to exactly one (even though it can server multiple
exports), which makes serving different content to different clients
harder than if you could have different servers on separate ports with
per-server settings on which clients to allow.  Or, if we have tls-authz
items per-export instead of per-server, so that different clients see a
different subset of available exports when doing NBD_OPT_LIST.

> 
> I can't help thinking we should add QMP to qemu-nbd one day though

Yeah, as QMP nbd server gets more powerful, we may eventually need a
similar monitor interface into controlling a long-running qemu-nbd
process...

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



Re: [Qemu-devel] [PATCH v1 33/33] s390x/tcg: Implement VECTOR UNPACK *

2019-02-28 Thread Richard Henderson
On 2/28/19 2:54 AM, David Hildenbrand wrote:
> Hmm, as v2 and v3 are handled concatenated it is not that easy. I am not
> sure if we can handle this without a temporary vector.
> 
> I thought about packing them first interleaved
> 
> v2 = [v2e0, v2e1]
> v3 = [v3e0, ve31]
> v1 = [v2e0_packed, v3e0_packed, v2e1_packed, v3e1_packed]
> 
> And then restoring the right order
> 
> v1 = [v2e0_packed, v2e1_packed, v3e0_packed, v3e1_packed]
> 
> But than the second operation seems to be the problem. That shuffling
> would have to be hard coded as far as I can see. (shuffling with MO_8 is
> nasty -> 14 element shave to be exchanged, in my opinion needing
> eventually 14 temporary variables)

I suppose you could do it in registers.

  load_element_i64(t1, v2, 0);
  for (i = 1; i < N; i++) {
load_element_i64(t3, v2, i, es);
tcg_gen_deposit_i64(t1, t1, t3, i << es, 1 << es);
  }
  // repeat for v3 into t2
  // store t1,t2 into v1.

Now you have only 3 temporaries, which is manageable.

The only question, when it comes to MO_8, is whether the code expansion of this
is reasonable (16 byte loads, 15 deposits, 2 stores -- minimum 33 insns,
probably 48 for x86_64 host), or whether a helper function would be better in
the end.  But then the same is true for all of the other merge & unpack
operations wrt MO_8.


r~



Re: [Qemu-devel] [PATCH v6 1/3] qemu-nbd: add support for authorization of TLS clients

2019-02-28 Thread Eric Blake
On 2/27/19 10:43 AM, Eric Blake wrote:

>>  @example
>>  qemu-nbd \
>>--object tls-creds-x509,id=tls0,endpoint=server,dir=/path/to/qemutls \
>> -  --tls-creds tls0 -t -x subset -p 10810 \
>> +  --object 'authz-simple,id=auth0,identity=CN=laptop.example.com,,\
>> +O=Example Org,,L=London,,ST=London,,C=GB' \
> 
> A long line may be necessary here, unless the whitespace in the
> identity= parameter inserted by the line continuation is harmless.  Long
> lines in man pages are annoying, but even worse is an example that
> copies-and-pastes incorrectly.  I may just s/^ *O/O/.

I've just confirmed that whitespace in the identity= parameter is
harmless, via this change:

diff --git i/tests/qemu-iotests/233 w/tests/qemu-iotests/233
index 6adade45353..5e5fe1e8cdb 100755
--- i/tests/qemu-iotests/233
+++ w/tests/qemu-iotests/233
@@ -131,7 +131,8 @@ nbd_server_stop

 nbd_server_start_tcp_socket \
 --object
tls-creds-x509,dir=${tls_dir}/server1,endpoint=server,id=tls0,verify-peer=yes
\
---object "authz-simple,identity=CN=localhost,,O=Cthulu Dark Lord
Enterprises client1,,L=R'lyeh,,C=South Pacific,id=authz0" \
+--object "authz-simple,id=authz0,identity=CN=localhost,, \
+  O=Cthulu Dark Lord Enterprises client1,,L=R'lyeh,,C=South Pacific" \
 --tls-authz authz0 \
 --tls-creds tls0 \
 -f $IMGFMT "$TEST_IMG" 2>> "$TEST_DIR/server.log"


So I'll go ahead and tweak the patch along those lines.

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



  1   2   3   4   >