Re: [Qemu-devel] [PATCH 0/5] Add qemu_vga.ndrv MacOS PPC VGA driver from QemuMacDrivers

2017-05-02 Thread David Gibson
On Tue, May 02, 2017 at 08:38:56AM +0100, Mark Cave-Ayland wrote:
> On 02/05/17 02:50, David Gibson wrote:
> 
> > On Mon, May 01, 2017 at 02:43:29PM +0100, Mark Cave-Ayland wrote:
> >> Last year Ben posted an initial set of patches for OpenBIOS which provided 
> >> a
> >> MacOS PPC VGA driver enabling MacOS guests to control the colour depth and
> >> resolution of the QEMU stdvga device. The QemuMacDrivers repository was 
> >> set up on
> >> qemu-project.org [1] but due to personal circumstances in the second half 
> >> of last
> >> year, I was unable to spend much time on it.
> >>
> >> Over the last few months I've reworked the OpenBIOS patches and applied 
> >> all the
> >> required dependencies upstream which makes it possible to enable the 
> >> driver with
> >> a fairly simple patch [2] to OpenBIOS's vga.fs (binary provided for 
> >> testing, but not
> >> to be included in the final merge).
> >>
> >> The main change I've made is that instead of serving the driver binary 
> >> directly
> >> through the VGA PCI BAR (with the relevant binary inlined within 
> >> OpenBIOS), the
> >> driver is now hosted by QEMU and is installed via the fw_cfg interface by 
> >> the
> >> OpenBIOS vga.fs driver during startup. Not only does this make it possible 
> >> to
> >> further develop the driver without also having to rebuild OpenBIOS every 
> >> time but
> >> it also leaves us with the ability to serve a proper IEEE-1275 FCode ROM 
> >> via the
> >> VGA PCI BAR later if needed.
> >>
> >> In addition to this I've added a new OpenBIOS NVRAM variable "vga-ndrv?" 
> >> which
> >> defaults to "true" but can be overidden via -prom-env to force disable the
> >> driver if any incompatibilities are found. I've tested it locally against 
> >> my
> >> OS X 10.2 and MacOS 9.2.1 images and it seems to work there, but as I don't
> >> have an exhaustive set of MacOS images available I'd be grateful for some 
> >> more
> >> testing.
> >>
> >> [1] https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg06159.html
> >> [2] https://mail.coreboot.org/pipermail/openbios/2017-May/009909.html
> >>
> >> This patchset can also be found on my github repository at
> >> https://github.com/mcayland/qemu/tree/ppc-vga-upstream.
> >>
> >> Signed-off-by: Mark Cave-Ayland 
> > 
> > Applied to ppc-for-2.10, thanks.
> 
> Hi David,
> 
> I just had a look at your ppc-for-2.10 branch and I see that you've also
> included patch 5 which is a custom made OpenBIOS binary.

Done.

> Can you drop patch 5 from the series and then I will do a manual pull
> request to update OpenBIOS and activate the new functionality once this
> is in?
> 
> 
> Many thanks,
> 
> Mark.
> 

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


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PATCH qemu v5] memory/iommu: QOM'fy IOMMU MemoryRegion

2017-05-02 Thread David Gibson
On Tue, May 02, 2017 at 06:25:50PM +0200, Cornelia Huck wrote:
> On Sat, 29 Apr 2017 22:37:07 +1000
> Alexey Kardashevskiy  wrote:
> 
> > This defines new QOM object - IOMMUMemoryRegion - with MemoryRegion
> > as a parent.
> > 
> > This moves IOMMU-related fields from MR to IOMMU MR. However to avoid
> > dymanic QOM casting in fast path (address_space_translate, etc),
> > this adds an @is_iommu boolean flag to MR and provides new helper to
> > do simple cast to IOMMU MR - memory_region_get_iommu. The flag
> > is set in the instance init callback. This defines
> > memory_region_is_iommu as memory_region_get_iommu()!=NULL.
> > 
> > This switches MemoryRegion to IOMMUMemoryRegion in most places except
> > the ones where MemoryRegion may be an alias.
> > 
> > This defines memory_region_init_iommu_type() to allow creating
> > IOMMUMemoryRegion subclasses. In order to support custom QOM type,
> > this splits memory_region_init() to object_initialize() +
> > memory_region_do_init.
> > 
> > Signed-off-by: Alexey Kardashevskiy 
> 
> >  /**
> > + * memory_region_init_iommu_type: Initialize a memory region of a custom 
> > type
> > + * that translates addresses
> > + *
> > + * An IOMMU region translates addresses and forwards accesses to a target
> > + * memory region.
> > + *
> > + * @typename: QOM class name
> > + * @iommumr: the #IOMMUMemoryRegion to be initialized
> 
> 
> I find "iommumr" terribly hard to read. Maybe iommu_mr is better? (Lots
> of times in this patch.)
> 

Fwiw, I tend to agree.

/me wonders what an IO murmurer is.

> 
> The s390 parts look fine.
> 

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


signature.asc
Description: PGP signature


Re: [Qemu-devel] [Qemu-devel RFC v3 1/5] msf2: Add Smartfusion2 System timer

2017-05-02 Thread sundeep subbaraya
Hi Alistair,

On Wed, May 3, 2017 at 3:25 AM, Alistair Francis  wrote:
> On Fri, Apr 28, 2017 at 9:51 AM, Subbaraya Sundeep
>  wrote:
>> Modelled System Timer in Microsemi's Smartfusion2 Soc.
>> Timer has two 32bit down counters and two interrupts.
>>
>> Signed-off-by: Subbaraya Sundeep 
>> ---
>>  hw/timer/Makefile.objs|   1 +
>>  hw/timer/msf2_timer.c | 250 
>> ++
>>  include/hw/timer/msf2_timer.h |  82 ++
>>  3 files changed, 333 insertions(+)
>>  create mode 100644 hw/timer/msf2_timer.c
>>  create mode 100644 include/hw/timer/msf2_timer.h
>>
>> diff --git a/hw/timer/Makefile.objs b/hw/timer/Makefile.objs
>> index dd6f27e..0bdf1e1 100644
>> --- a/hw/timer/Makefile.objs
>> +++ b/hw/timer/Makefile.objs
>> @@ -41,3 +41,4 @@ common-obj-$(CONFIG_STM32F2XX_TIMER) += stm32f2xx_timer.o
>>  common-obj-$(CONFIG_ASPEED_SOC) += aspeed_timer.o
>>
>>  common-obj-$(CONFIG_SUN4V_RTC) += sun4v-rtc.o
>> +common-obj-$(CONFIG_MSF2) += msf2_timer.o
>> diff --git a/hw/timer/msf2_timer.c b/hw/timer/msf2_timer.c
>> new file mode 100644
>> index 000..d1dbde5
>> --- /dev/null
>> +++ b/hw/timer/msf2_timer.c
>
> Hey Sundeep,
>
> File names should use '-' instead of '_'.

Ok will change.
>
>> @@ -0,0 +1,250 @@
>> +/*
>> + * Timer block model of Microsemi SmartFusion2.
>> + *
>> + * Copyright (c) 2017 Subbaraya Sundeep .
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a 
>> copy
>> + * of this software and associated documentation files (the "Software"), to 
>> deal
>> + * in the Software without restriction, including without limitation the 
>> rights
>> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
>> + * copies of the Software, and to permit persons to whom the Software is
>> + * furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be included 
>> in
>> + * all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
>> OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
>> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
>> OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
>> FROM,
>> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
>> + * THE SOFTWARE.
>> + */
>> +
>> +#include "qemu/osdep.h"
>> +#include "hw/timer/msf2_timer.h"
>> +#include "hw/sysbus.h"
>> +#include "qemu/log.h"
>> +#include "qemu/main-loop.h"
>
> Do you need to include the main-loop.h? This doesn't look right.
>
Ok I will remove it.

>> +
>> +#ifndef MSF2_TIMER_ERR_DEBUG
>> +#define MSF2_TIMER_ERR_DEBUG  0
>> +#endif
>> +
>> +#define DB_PRINT_L(lvl, fmt, args...) do { \
>> +if (MSF2_TIMER_ERR_DEBUG >= lvl) { \
>> +qemu_log("%s: " fmt, __func__, ## args); \
>> +} \
>> +} while (0);
>> +
>> +#define DB_PRINT(fmt, args...) DB_PRINT_L(1, fmt, ## args)
>> +
>> +static void timer_update_irq(struct Msf2Timer *st)
>> +{
>> +bool isr, ier;
>> +
>> +isr = !!(st->regs[R_TIM_RIS] & TIMER_RIS_ACK);
>> +ier = !!(st->regs[R_TIM_CTRL] & TIMER_CTRL_INTR);
>> +
>> +qemu_set_irq(st->irq, (ier && isr));
>> +}
>> +
>> +static void timer_update(struct Msf2Timer *st)
>> +{
>> +uint64_t count;
>> +
>> +DB_PRINT("timer=%d\n", st->nr);
>
> Maybe make this a little more explict. Something like "Updating timer: %d"?
>
Yeah will change that.
>> +
>> +if (!(st->regs[R_TIM_CTRL] & TIMER_CTRL_ENBL)) {
>> +ptimer_stop(st->ptimer);
>> +return;
>> +}
>> +
>> +count = st->regs[R_TIM_LOADVAL];
>> +ptimer_set_limit(st->ptimer, count, 1);
>> +ptimer_run(st->ptimer, 1);
>> +}
>> +
>> +static uint64_t
>> +timer_read(void *opaque, hwaddr addr, unsigned int size)
>> +{
>> +MSF2TimerState *t = opaque;
>> +struct Msf2Timer *st;
>> +uint32_t r = 0;
>
> Call the ret instead of r and it should be a uint64_t.
>
I will change to ret. I guess uint32_t is fine because same is used
for returning values in 32 bit registers.

>> +unsigned int timer = 0;
>
> Isn't the timer normally an int? Try to use the same type throughout the code.
>
Ok will use int.

>> +int isr;
>> +int ier;
>> +
>> +addr >>= 2;
>> +/*
>> + * Two independent timers has same base address.
>> + * Based on addr passed figure out which timer is being used.
>> + */
>> +if (addr >= R_TIM1_MAX) {
>> +timer = 1;
>> +addr -= R_TIM1_MAX;
>> +}
>> +
>> +st = >timers[timer];
>> +
>> +switch (addr) {
>> +case R_TIM_VAL:
>> +r = ptimer_get_count(st->ptimer);
>> +DB_PRINT("msf2_timer t=%d read 

Re: [Qemu-devel] [PATCH] maintainers: add maintainer for replay* files

2017-05-02 Thread Pavel Dovgalyuk
Indeed. I missed these ones.

⁣Отправлено с помощью BlueMail ​

На 2 Май 2017 г., 17:37, в 17:37, Stefan Hajnoczi  
написал:п>On Tue, May 02, 2017 at 09:16:49AM +0300, Pavel Dovgalyuk wrote:
>> Updating MAINTAINERS to set Pavel Dovgalyuk as record/replay
>maintainer.
>>
>> Signed-off-by: Pavel Dovgalyuk 
>> ---
>>  MAINTAINERS |9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index a1d2b3a4d3..8be1c74ac5 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -1546,6 +1546,15 @@ F: net/colo*
>>  F: net/filter-rewriter.c
>>  F: net/filter-mirror.c
>>
>> +Record/replay
>> +M: Pavel Dovgalyuk 
>> +W: http://wiki.qemu.org/Features/record-replay
>> +S: Supported
>> +F: replay/*
>> +F: block/blkreplay.c
>> +F: net/filter-replay.c
>> +F: include/sysemu/replay.h
>
>+ F: docs/replay.txt
>+ F: stubs/replay.c
>
>Are these missing?


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

2017-05-02 Thread 858585 jemmy
On Mon, Apr 10, 2017 at 9:52 PM, Stefan Hajnoczi  wrote:
> On Sat, Apr 08, 2017 at 09:17:58PM +0800, 858585 jemmy wrote:
>> On Fri, Apr 7, 2017 at 7:34 PM, Stefan Hajnoczi  wrote:
>> > On Fri, Apr 07, 2017 at 09:30:33AM +0800, 858585 jemmy wrote:
>> >> On Thu, Apr 6, 2017 at 10:02 PM, Stefan Hajnoczi  
>> >> wrote:
>> >> > On Wed, Apr 05, 2017 at 05:27:58PM +0800, jemmy858...@gmail.com wrote:
>> >> >
>> >> > A proper solution is to refactor the synchronous code to make it
>> >> > asynchronous.  This might require invoking the system call from a
>> >> > thread pool worker.
>> >> >
>> >>
>> >> yes, i agree with you, but this is a big change.
>> >> I will try to find how to optimize this code, maybe need a long time.
>> >>
>> >> this patch is not a perfect solution, but can alleviate the problem.
>> >
>> > Let's try to understand the problem fully first.
>> >
>>
>> when migrate the vm with high speed, i find vnc response slowly sometime.
>> not only vnc response slowly, virsh console aslo response slowly sometime.
>> and the guest os block io performance is also reduce.
>>
>> the bug can be reproduce by this command:
>> virsh migrate-setspeed 165cf436-312f-47e7-90f2-f8aa63f34893 900
>> virsh migrate --live 165cf436-312f-47e7-90f2-f8aa63f34893
>> --copy-storage-inc qemu+ssh://10.59.163.38/system
>>
>> and --copy-storage-all have no problem.
>> virsh migrate --live 165cf436-312f-47e7-90f2-f8aa63f34893
>> --copy-storage-all qemu+ssh://10.59.163.38/system
>>
>> compare the difference between --copy-storage-inc and
>> --copy-storage-all. i find out the reason is
>> mig_save_device_bulk invoke bdrv_is_allocated, but bdrv_is_allocated
>> is synchronous and maybe wait
>> for a long time.
>>
>> i write this code to measure the time used by  brdrv_is_allocated()
>>
>>  279 static int max_time = 0;
>>  280 int tmp;
>>
>>  288 clock_gettime(CLOCK_MONOTONIC_RAW, );
>>  289 ret = bdrv_is_allocated(blk_bs(bb), cur_sector,
>>  290 MAX_IS_ALLOCATED_SEARCH, 
>> _sectors);
>>  291 clock_gettime(CLOCK_MONOTONIC_RAW, );
>>  292
>>  293
>>  294 tmp =  (ts2.tv_sec - ts1.tv_sec)*10L
>>  295+ (ts2.tv_nsec - ts1.tv_nsec);
>>  296 if (tmp > max_time) {
>>  297max_time=tmp;
>>  298fprintf(stderr, "max_time is %d\n", max_time);
>>  299 }
>>
>> the test result is below:
>>
>>  max_time is 37014
>>  max_time is 1075534
>>  max_time is 17180913
>>  max_time is 28586762
>>  max_time is 49563584
>>  max_time is 103085447
>>  max_time is 110836833
>>  max_time is 120331438
>>
>> bdrv_is_allocated is called after qemu_mutex_lock_iothread.
>> and the main thread is also call qemu_mutex_lock_iothread.
>> so cause the main thread maybe wait for a long time.
>>
>>if (bmds->shared_base) {
>> qemu_mutex_lock_iothread();
>> aio_context_acquire(blk_get_aio_context(bb));
>> /* Skip unallocated sectors; intentionally treats failure as
>>  * an allocated sector */
>> while (cur_sector < total_sectors &&
>>!bdrv_is_allocated(blk_bs(bb), cur_sector,
>>   MAX_IS_ALLOCATED_SEARCH, _sectors)) {
>> cur_sector += nr_sectors;
>> }
>> aio_context_release(blk_get_aio_context(bb));
>> qemu_mutex_unlock_iothread();
>> }
>>
>> #0  0x7f107322f264 in __lll_lock_wait () from /lib64/libpthread.so.0
>> #1  0x7f107322a508 in _L_lock_854 () from /lib64/libpthread.so.0
>> #2  0x7f107322a3d7 in pthread_mutex_lock () from /lib64/libpthread.so.0
>> #3  0x00949ecb in qemu_mutex_lock (mutex=0xfc51a0) at
>> util/qemu-thread-posix.c:60
>> #4  0x00459e58 in qemu_mutex_lock_iothread () at 
>> /root/qemu/cpus.c:1516
>> #5  0x00945322 in os_host_main_loop_wait (timeout=28911939) at
>> util/main-loop.c:258
>> #6  0x009453f2 in main_loop_wait (nonblocking=0) at 
>> util/main-loop.c:517
>> #7  0x005c76b4 in main_loop () at vl.c:1898
>> #8  0x005ceb77 in main (argc=49, argv=0x7fff921182b8,
>> envp=0x7fff92118448) at vl.c:4709
>
> The following patch moves bdrv_is_allocated() into bb's AioContext.  It
> will execute without blocking other I/O activity.
>
> Compile-tested only.
>
> diff --git a/migration/block.c b/migration/block.c
> index 7734ff7..a5572a4 100644
> --- a/migration/block.c
> +++ b/migration/block.c
> @@ -263,6 +263,29 @@ static void blk_mig_read_cb(void *opaque, int ret)
>  blk_mig_unlock();
>  }
>
> +typedef struct {
> +int64_t *total_sectors;
> +int64_t *cur_sector;
> +BlockBackend *bb;
> +QemuEvent event;
> +} MigNextAllocatedClusterData;
> +
> +static void coroutine_fn mig_next_allocated_cluster(void *opaque)
> +{
> +MigNextAllocatedClusterData *data = opaque;
> +int nr_sectors;
> +
> +/* Skip unallocated 

Re: [Qemu-devel] [PATCH v6 00/25] tcg cross-tb optimizations

2017-05-02 Thread Richard Henderson

On 05/02/2017 12:22 PM, Richard Henderson wrote:

Changes since v5:

...

   * Alpha frontend patch rewritten; the former patch appears to
 drop clock interrupts, not exiting the kernel's idle loop.
 I never *really* figured out why, since both patches seem
 to annotate the same TBs in the same way.


There's definitely something odd going on.

With a rebuild from scratch, the same symptoms have re-appeared for Alpha.  So 
it really had nothing to do with the original patch.  I'm at a bit of a loss...



r~



Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/5] hw/ppc: removing spapr_drc_detach_cb opaques

2017-05-02 Thread Bharata B Rao
On Tue, May 2, 2017 at 1:13 PM, Daniel Henrique Barboza <
danie...@linux.vnet.ibm.com> wrote:

>
>
> On 05/02/2017 12:40 AM, Bharata B Rao wrote:
>
> On Sun, Apr 30, 2017 at 10:55 PM, Daniel Henrique Barboza <
> danie...@linux.vnet.ibm.com> wrote:
>
>> Following up the previous detach_cb change, this patch removes the
>> detach_cb_opaque entirely from the code.
>>
>> The reason is that the drc->detach_cb_opaque object can't be
>> restored in the post load of the upcoming DRC migration and no detach
>> callbacks actually need this opaque. 'spapr_core_release' is
>> receiving it as NULL, 'spapr_phb_remove_pci_device_cb' is receiving
>> a phb object as opaque but is't using it. These were trivial removal
>> cases.
>>
>> However, the LM removal callback 'spapr_lmb_release' is receiving
>> and using the opaque object, a 'sPAPRDIMMState' struct. This struct
>> holds the number of LMBs the DIMM object contains and the callback
>> was using this counter as a countdown to check if all LMB DRCs were
>> release before proceeding to the DIMM unplug. To remove the need of
>> this callback we have choices such as:
>>
>> - migrate the 'sPAPRDIMMState' struct. This would require creating a
>> QTAILQ to store all DIMMStates and an additional 'dimm_id' field to
>> associate the DIMMState with the DIMM object. We could attach this
>> QTAILQ to the 'sPAPRPHBState' and retrieve it later in the callback.
>>
>> - fetch the state of the LMB DRCs directly by scanning the state of
>> them and, if all of them are released, proceed with the DIMM unplug.
>>
>> The second approach was chosen. The new 'spapr_all_lmbs_drcs_released'
>> function scans all LMBs of a given DIMM device to see if their DRC
>> state are inactive. If all of them are inactive return 'true', 'false'
>> otherwise. This function is being called inside the 'spapr_lmb_release'
>> callback, replacing the role of the 'sPAPRDIMMState' opaque. The
>> 'sPAPRDIMMState' struct was removed from the code given that there are
>> no more uses for it.
>>
>> After all these changes, there are no roles left for the
>> 'detach_cb_opaque'
>> attribute of the 'sPAPRDRConnector' as well, so we can safely remove
>> it from the code too.
>>
>> Signed-off-by: Daniel Henrique Barboza 
>> ---
>>  hw/ppc/spapr.c | 46 ++
>> +++-
>>  hw/ppc/spapr_drc.c | 16 +---
>>  hw/ppc/spapr_pci.c |  4 ++--
>>  include/hw/ppc/spapr_drc.h |  6 ++
>>  4 files changed, 42 insertions(+), 30 deletions(-)
>>
>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
>> index bc11757..8b9a6cf 100644
>> --- a/hw/ppc/spapr.c
>> +++ b/hw/ppc/spapr.c
>> @@ -1887,21 +1887,43 @@ static void spapr_drc_reset(void *opaque)
>>  }
>>  }
>>
>> -typedef struct sPAPRDIMMState {
>> -uint32_t nr_lmbs;
>> -} sPAPRDIMMState;
>> +static bool spapr_all_lmbs_drcs_released(PCDIMMDevice *dimm)
>> +{
>> +Error *local_err = NULL;
>> +PCDIMMDeviceClass *ddc = PC_DIMM_GET_CLASS(dimm);
>> +MemoryRegion *mr = ddc->get_memory_region(dimm);
>> +uint64_t size = memory_region_size(mr);
>> +
>> +uint64_t addr;
>> +addr = object_property_get_int(OBJECT(dimm), PC_DIMM_ADDR_PROP,
>> _err);
>> +if (local_err) {
>> +error_propagate(_abort, local_err);
>> +return false;
>> +}
>> +uint32_t nr_lmbs = size / SPAPR_MEMORY_BLOCK_SIZE;
>>
>> -static void spapr_lmb_release(DeviceState *dev, void *opaque)
>> +sPAPRDRConnector *drc;
>> +int i = 0;
>> +for (i = 0; i < nr_lmbs; i++) {
>> +drc = spapr_dr_connector_by_id(SPAPR_DR_CONNECTOR_TYPE_LMB,
>> +addr / SPAPR_MEMORY_BLOCK_SIZE);
>> +g_assert(drc);
>> +if (drc->indicator_state != SPAPR_DR_INDICATOR_STATE_INACTIVE) {
>> +return false;
>> +}
>> +addr += SPAPR_MEMORY_BLOCK_SIZE;
>> +}
>> +return true;
>> +}
>> +
>> +static void spapr_lmb_release(DeviceState *dev)
>>  {
>> -sPAPRDIMMState *ds = (sPAPRDIMMState *)opaque;
>>  HotplugHandler *hotplug_ctrl;
>>
>> -if (--ds->nr_lmbs) {
>> +if (!spapr_all_lmbs_drcs_released(PC_DIMM(dev))) {
>>  return;
>>  }
>>
>
> I am concerned about the number of times we walk the DRC list
> corresponding to each DIMM device. When a DIMM device is being removed,
> spapr_lmb_release() will be invoked for each of the LMBs of that DIMM. Now
> in this scheme, we end up walking through all the DRC objects of the DIMM
> from every LMB's release function.
>
>
> Hi Bharata,
>
>
> I agree, this is definitely a poorer performance than simply decrementing
> ds->nr_lmbs.
> The reasons why I went on with it:
>
> - hot unplug isn't an operation that happens too often, so it's not
> terrible
> to have a delay increase here;
>
> - it didn't increased the unplug delay in an human noticeable way, at
> least in
> my tests;
>
> - apart from migrating the information, there is nothing much we can do in
> the
> callback side 

Re: [Qemu-devel] [PATCH] hw/virtio: fix vhost user fails to startup when MQ

2017-05-02 Thread Yang, Zhiyong
Hi,Maxime:

> -Original Message-
> From: Maxime Coquelin [mailto:maxime.coque...@redhat.com]
> Sent: Tuesday, May 2, 2017 8:23 PM
> To: Yang, Zhiyong ; qemu-devel@nongnu.org
> Cc: m...@redhat.com
> Subject: Re: [Qemu-devel] [PATCH] hw/virtio: fix vhost user fails to startup 
> when
> MQ
> 
> 
> 
> On 04/28/2017 09:09 AM, Zhiyong Yang wrote:
> > Qemu2.7~2.9 and vhost user for dpdk 17.02 release work together to
> > cause failures of new connection when negotiating to set MQ.
> > (one queue pair works well).
> > Because there exist some bugs in qemu code when introducing
> > VHOST_USER_PROTOCOL_F_REPLY_ACK to qemu. When
> vhost_user_set_mem_table
> > is invoked to deal with the vhost message VHOST_USER_SET_MEM_TABLE for
> > the second time, qemu indeed doesn't send the messge (The message
> > needs to be sent only once)but still will be waiting for dpdk's reply
> > ack, then, qemu is always freezing, while DPDK is always waiting for
> > next vhost message from qemu.
> >The patch aims to fix the bug, MQ can work well.
> >The same bug is found in function vhost_user_net_set_mtu, it is
> > fixed at the same time.
> >DPDK related patch is as following:
> >http://www.dpdk.org/dev/patchwork/patch/23955/
> >
> > Signed-off-by: Zhiyong Yang 
> > ---
> >   hw/virtio/vhost-user.c | 18 +++---
> >   1 file changed, 11 insertions(+), 7 deletions(-)
> >
> > diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c index
> > 9334a8a..c2c54ce 100644
> > --- a/hw/virtio/vhost-user.c
> > +++ b/hw/virtio/vhost-user.c
> > @@ -205,10 +205,11 @@ static int vhost_user_write(struct vhost_dev *dev,
> VhostUserMsg *msg,
> >   /*
> >* For non-vring specific requests, like VHOST_USER_SET_MEM_TABLE,
> >* we just need send it once in the first time. For later such
> > - * request, we just ignore it.
> > + * request, we just ignore it. In this case, return value is 1 which is
> > + * different from 0 that stands for message written successfully.
> >*/
> >   if (vhost_user_one_time_request(msg->request) && dev->vq_index != 0) {
> > -return 0;
> > +return 1;
> 
> I personally prefer the fix I suggested in the DPDK mail thread, as returning 
> a
> random positive value does look like a workaround:

I think that for vhost_user_write(), it's behaving in a different way for some 
specific vhost messages.  
So, it should not return the same returen value 0 which stands for success. 

> 
> "
> I think the problem must be fixed generally and not per request.
> Maybe in vhost_user_write() if one-time request, just clear the
> VHOST_USER_NEED_REPLY flag. Then, in process_message_reply(), return early
> if this flag isn't set.
> "
It's another choise. Either this one nor that one,  not a big deal. :)
Fixing these  existing bugs is the most important.

thanks
Zhiyong Yang



[Qemu-devel] [PATCH v2] target-ppc: Enable open-pic timers to count and generate interrupts

2017-05-02 Thread Aaron Larson

Previous QEMU open-pic implemented the 4 open-pic timers including all
timer registers, but the timers did not "count" or generate any
interrupts.  The patch makes the timers both count and generate
interrupts.  The timer clock frequency is fixed at 100MHZ.

Signed-off-by: Aaron Larson 
---
 hw/intc/openpic.c | 135 ++
 1 file changed, 117 insertions(+), 18 deletions(-)

diff --git a/hw/intc/openpic.c b/hw/intc/openpic.c
index 4349e45..e0556f1 100644
--- a/hw/intc/openpic.c
+++ b/hw/intc/openpic.c
@@ -45,6 +45,7 @@
 #include "qemu/bitops.h"
 #include "qapi/qmp/qerror.h"
 #include "qemu/log.h"
+#include "qemu/timer.h"
 
 //#define DEBUG_OPENPIC
 
@@ -54,8 +55,10 @@ static const int debug_openpic = 1;
 static const int debug_openpic = 0;
 #endif
 
+static int get_current_cpu(void);
 #define DPRINTF(fmt, ...) do { \
 if (debug_openpic) { \
+printf("Core%d: ", get_current_cpu()); \
 printf(fmt , ## __VA_ARGS__); \
 } \
 } while (0)
@@ -246,9 +249,25 @@ typedef struct IRQSource {
 #define IDR_EP  0x8000  /* external pin */
 #define IDR_CI  0x4000  /* critical interrupt */
 
+/* Conversion between openpic clock ticks and nanosecs.  Ideally this clock
+   frequency would follow the openpic spec, for now hard code to 100mz.
+   A 100mhz clock, divided by 8, or 25mhz
+   25,000,000 ticks/sec, 25,000/ms, 25/us, 1 tick/40ns
+*/
+#define CONV_FACTOR 40LL
+static inline uint64_t ns_to_ticks(uint64_t ns)   { return ns   / CONV_FACTOR; 
}
+static inline uint64_t ticks_to_ns(uint64_t tick) { return tick * CONV_FACTOR; 
}
+
 typedef struct OpenPICTimer {
 uint32_t tccr;  /* Global timer current count register */
 uint32_t tbcr;  /* Global timer base count register */
+int   n_IRQ;
+bool  qemu_timer_active; /* Is the qemu_timer is running? 
*/
+struct QEMUTimer *qemu_timer;   /* May be NULL if not created. */
+struct OpenPICState  *opp;  /* Device timer is part of. */
+/* The QEMU_CLOCK_VIRTUAL time (in ns) corresponding to the last
+   current_count written or read, only defined if qemu_timer_active. */
+uint64_t  originTime;
 } OpenPICTimer;
 
 typedef struct OpenPICMSI {
@@ -795,37 +814,102 @@ static uint64_t openpic_gbl_read(void *opaque, hwaddr 
addr, unsigned len)
 return retval;
 }
 
+static void openpic_tmr_set_tmr(OpenPICTimer *tmr, uint32_t val, bool enabled);
+
+static void qemu_timer_cb(void *opaque)
+{
+OpenPICTimer *tmr = opaque;
+OpenPICState *opp = tmr->opp;
+uint32_tn_IRQ = tmr->n_IRQ;
+uint32_t val =   tmr->tbcr & ~TBCR_CI;
+uint32_t tog = ((tmr->tccr & TCCR_TOG) ^ TCCR_TOG);  /* invert toggle. */
+
+DPRINTF("%s n_IRQ=%d\n", __func__, n_IRQ);
+/* Reload current count from base count and setup timer. */
+tmr->tccr = val | tog;
+openpic_tmr_set_tmr(tmr, val, /*enabled=*/true);
+/* Raise the interrupt. */
+opp->src[n_IRQ].destmask = read_IRQreg_idr(opp, n_IRQ);
+openpic_set_irq(opp, n_IRQ, 1);
+openpic_set_irq(opp, n_IRQ, 0);
+}
+
+/* If enabled is true, arranges for an interrupt to be raised val clocks into
+   the future, if enabled is false cancels the timer. */
+static void openpic_tmr_set_tmr(OpenPICTimer *tmr, uint32_t val, bool enabled)
+{
+/* If timer doesn't exist, create it. */
+if (tmr->qemu_timer == NULL) {
+tmr->qemu_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, _timer_cb, 
tmr);
+DPRINTF("Created timer for n_IRQ %d\n", tmr->n_IRQ);
+}
+uint64_t ns = ticks_to_ns(val & ~TCCR_TOG);
+/* A count of zero causes a timer to be set to expire immediately.  This
+   effectively stops the simulation so we don't honor that configuration.
+   On real hardware, this would generate an interrupt on every clock cycle
+   if the interrupt was unmasked. */
+if ((ns == 0) || !enabled) {
+tmr->qemu_timer_active = false;
+tmr->tccr = tmr->tccr & TCCR_TOG;
+timer_del(tmr->qemu_timer); /* set timer to never expire. */
+} else {
+tmr->qemu_timer_active = true;
+uint64_t now = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
+tmr->originTime = now;
+timer_mod(tmr->qemu_timer, now + ns); /* set timer expiration. */
+}
+}
+
+/* Returns the currrent tccr value, i.e., timer value (in clocks) with
+   appropriate TOG. */
+static uint64_t openpic_tmr_get_timer(OpenPICTimer *tmr)
+{
+uint64_t retval;
+if (!tmr->qemu_timer_active) {
+retval = tmr->tccr;
+} else {
+uint64_t now = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
+uint64_t used = now - tmr->originTime;  /* nsecs */
+uint32_t used_ticks = (uint32_t)ns_to_ticks(used);
+uint32_t count = (tmr->tccr & ~TCCR_TOG) - used_ticks;
+retval = (uint32_t)((tmr->tccr & TCCR_TOG) | (count & ~TCCR_TOG));
+}
+return retval;
+}
+
 static void 

Re: [Qemu-devel] [PATCH 0/2] VFIO: Make 8-byte accesses atomic

2017-05-02 Thread Alex Williamson
On Tue, 2 May 2017 23:41:01 -0300
jos...@linux.vnet.ibm.com wrote:

> On Fri, Apr 21, 2017 at 12:06:15PM +0200, Paolo Bonzini wrote:
> > 
> > 
> > On 20/04/2017 18:03, Alex Williamson wrote:  
> > > On Thu, 20 Apr 2017 00:19:23 -0700
> > > Richard Henderson  wrote:
> > >   
> > >> On 04/19/2017 12:44 PM, Jose Ricardo Ziviani wrote:  
> > >>> This patchset has two patches:
> > >>> [1] 8-byte writes to non-mapped MMIO are broken into pairs of 4-byte 
> > >>> writes, this patch makes such pairs atomic.
> > >>>
> > >>> [2] Enable 8-byte accesses in vfio_region_write and vfio_region_read.
> > >>>
> > >>> Patches based on master.
> > >>>
> > >>> Jose Ricardo Ziviani (2):
> > >>>   vfio: Set MemoryRegionOps:max_access_size and min_access_size
> > >>>   vfio: enable 8-byte reads/writes to vfio
> > >>>
> > >>>  hw/vfio/common.c | 14 ++
> > >>>  1 file changed, 14 insertions(+)
> > >>>
> > >>
> > >> I think these patches need to be squashed to be bisectable.  
> > > 
> > > No, I think it's fine.  The point of patch 1/2 is to indicate that the
> > > hardware supports 8-byte accesses, which will still be broken into 2
> > > 4-byte accesses because we don't yet set the implemented width beyond
> > > the default.  The important part is that the mutex will now group the 4
> > > byte access pair together rather than letting them get re-ordered.
> > > Patch 2/2 then implements native 8-byte access.  I appreciate them
> > > being separate for this subtle nuance, but maybe I'm not seeing the
> > > same issue as you.  Thanks,  
> > '
> > I agree, the patches looks fine as is.
> > 
> > Paolo
> >   
> 
> Hello!
> 
> Thank you all for your review but I have a quick question: is it ok for
> merge? :)

Yes, I've got it in a local branch, I'll send a pull request this
week.  Thanks,

Alex



Re: [Qemu-devel] [PATCH V3 05/10] net/net.c: Add vnet header length to SocketReadState

2017-05-02 Thread Zhang Chen



On 05/02/2017 12:53 PM, Jason Wang wrote:



On 2017年04月28日 17:47, Zhang Chen wrote:

Address Jason Wang's comments add vnet header length to SocketReadState.


Instead of saying this, you can add "Suggested-by: Jason Wang 
" above your sign-off.


OK.




So we change net_fill_rstate() to read
struct  {int size; int vnet_hdr_len; const uint8_t buf[];}.


This makes me thinking about the backward compatibility. I think we'd 
better try to keep it as much as possible. E.g how about pack 
vnet_hdr_len into higher bits of size?




Do you means split uint32_t size to uint16_t size and uint16_t 
vnet_hdr_len ?

If yes, we also can't keep compatibility with old version.
Old code send a uint32_t size, we read it as uint16_t size is always wrong.

Thanks
Zhang Chen



Thanks



Signed-off-by: Zhang Chen 
---
  include/net/net.h |  4 +++-
  net/net.c | 24 ++--
  2 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/include/net/net.h b/include/net/net.h
index 402d913..865cb98 100644
--- a/include/net/net.h
+++ b/include/net/net.h
@@ -115,9 +115,11 @@ typedef struct NICState {
  } NICState;
struct SocketReadState {
-int state; /* 0 = getting length, 1 = getting data */
+/* 0 = getting length, 1 = getting vnet header length, 2 = 
getting data */

+int state;
  uint32_t index;
  uint32_t packet_len;
+uint32_t vnet_hdr_len;
  uint8_t buf[NET_BUFSIZE];
  SocketReadStateFinalize *finalize;
  };
diff --git a/net/net.c b/net/net.c
index f69260f..5a6b5ac 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1639,8 +1639,12 @@ int net_fill_rstate(SocketReadState *rs, const 
uint8_t *buf, int size)

  unsigned int l;
while (size > 0) {
-/* reassemble a packet from the network */
-switch (rs->state) { /* 0 = getting length, 1 = getting data */
+/* Reassemble a packet from the network.
+ * 0 = getting length.
+ * 1 = getting vnet header length.
+ * 2 = getting data.
+ */
+switch (rs->state) {
  case 0:
  l = 4 - rs->index;
  if (l > size) {
@@ -1658,6 +1662,22 @@ int net_fill_rstate(SocketReadState *rs, const 
uint8_t *buf, int size)

  }
  break;
  case 1:
+l = 4 - rs->index;
+if (l > size) {
+l = size;
+}
+memcpy(rs->buf + rs->index, buf, l);
+buf += l;
+size -= l;
+rs->index += l;
+if (rs->index == 4) {
+/* got vnet header length */
+rs->vnet_hdr_len = ntohl(*(uint32_t *)rs->buf);
+rs->index = 0;
+rs->state = 2;
+}
+break;
+case 2:
  l = rs->packet_len - rs->index;
  if (l > size) {
  l = size;




.



--
Thanks
Zhang Chen






Re: [Qemu-devel] [PATCH 0/2] VFIO: Make 8-byte accesses atomic

2017-05-02 Thread joserz
On Fri, Apr 21, 2017 at 12:06:15PM +0200, Paolo Bonzini wrote:
> 
> 
> On 20/04/2017 18:03, Alex Williamson wrote:
> > On Thu, 20 Apr 2017 00:19:23 -0700
> > Richard Henderson  wrote:
> > 
> >> On 04/19/2017 12:44 PM, Jose Ricardo Ziviani wrote:
> >>> This patchset has two patches:
> >>> [1] 8-byte writes to non-mapped MMIO are broken into pairs of 4-byte 
> >>> writes, this patch makes such pairs atomic.
> >>>
> >>> [2] Enable 8-byte accesses in vfio_region_write and vfio_region_read.
> >>>
> >>> Patches based on master.
> >>>
> >>> Jose Ricardo Ziviani (2):
> >>>   vfio: Set MemoryRegionOps:max_access_size and min_access_size
> >>>   vfio: enable 8-byte reads/writes to vfio
> >>>
> >>>  hw/vfio/common.c | 14 ++
> >>>  1 file changed, 14 insertions(+)
> >>>  
> >>
> >> I think these patches need to be squashed to be bisectable.
> > 
> > No, I think it's fine.  The point of patch 1/2 is to indicate that the
> > hardware supports 8-byte accesses, which will still be broken into 2
> > 4-byte accesses because we don't yet set the implemented width beyond
> > the default.  The important part is that the mutex will now group the 4
> > byte access pair together rather than letting them get re-ordered.
> > Patch 2/2 then implements native 8-byte access.  I appreciate them
> > being separate for this subtle nuance, but maybe I'm not seeing the
> > same issue as you.  Thanks,
> '
> I agree, the patches looks fine as is.
> 
> Paolo
> 

Hello!

Thank you all for your review but I have a quick question: is it ok for
merge? :)

Thanks




Re: [Qemu-devel] [PATCH v6 10/13] s390x/css: introduce and realize ccw-request callback

2017-05-02 Thread Dong Jia Shi
* Cornelia Huck  [2017-05-02 18:04:07 +0200]:

> On Tue, 2 May 2017 10:15:19 +0800
> Dong Jia Shi  wrote:
> 
> > * Auger Eric  [2017-05-01 19:28:23 +0200]:
> 
> > > >  static void vfio_ccw_io_notifier_handler(void *opaque)
> > > >  {
> > > >  VFIOCCWDevice *vcdev = opaque;
> > > > +struct ccw_io_region *region = vcdev->io_region;
> > > > +S390CCWDevice *cdev = S390_CCW_DEVICE(vcdev);
> > > > +CcwDevice *ccw_dev = CCW_DEVICE(cdev);
> > > > +SubchDev *sch = ccw_dev->sch;
> > > > +SCSW *s = >curr_status.scsw;
> > > > +IRB irb;
> > > >  
> > > >  if (!event_notifier_test_and_clear(>io_notifier)) {
> > > >  return;
> > > >  }
> > > > +
> > > > +if (pread(vcdev->vdev.fd, region,
> > > > +  vcdev->io_region_size, vcdev->io_region_offset) == -1) {
> > > is it possible to read less bytes than requested?
> > Currently, impossible. The kernel side returns either the full region,
> > or an error.
> > But we surely could make it more friendly for a partial return. I will
> > add a check for that case, and generate a channel program check for it.
> 
> I think a channel-control check would be more appropriate here.

Hi Conny,

After reading PoP 14-43, I think you are right.

Quotation from PoP:
--8<---
Channel-control check is caused by any machine
malfunction affecting channel-subsystem controls.
... ...

Channel-control check may also indicate that an
error has been detected in the information trans-
ferred to or from main storage during an I/O opera-
tion.
... ...

Detection of the channel-control-check condition
causes the current operation, if any, to be terminated
immediately. The subchannel is made status pending
with primary and alert status or with primary, second-
ary, and alert status as a function of the type of termi-
nation, the current subchannel state, and the device
status presented, if any. When the channel sub-
system recognizes a channel-control-check condi-
tion, any previously existing intermediate interruption
condition may or may not be recognized by the chan-
nel subsystem.
-->8---

So I decide to add this piece of code:
if (size != vcdev->io_region_size) {
/* Information transfer error, generate channel-control check. */
s->ctrl &= ~SCSW_ACTL_START_PEND;
s->cstat = SCSW_CSTAT_CHN_CTRL_CHK;
s->ctrl &= ~SCSW_CTRL_MASK_STCTL;
s->ctrl |= SCSW_STCTL_PRIMARY | SCSW_STCTL_SECONDARY |
   SCSW_STCTL_ALERT | SCSW_STCTL_STATUS_PEND;
goto read_err;
}

-- 
Dong Jia Shi




Re: [Qemu-devel] [PATCH V3 04/10] net/filter-mirror.c: Add filter-mirror and filter-redirector vnet support.

2017-05-02 Thread Zhang Chen



On 05/02/2017 12:47 PM, Jason Wang wrote:



On 2017年04月28日 17:47, Zhang Chen wrote:

In this patch, we change the send packet format from
struct {int size; const uint8_t buf[];} to {int size; int 
vnet_hdr_len; const uint8_t buf[];}.
make other module(like colo-compare) know how to parse net packet 
correctly.


Signed-off-by: Zhang Chen 
---
  net/filter-mirror.c | 28 +++-
  1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/net/filter-mirror.c b/net/filter-mirror.c
index 72fa7c2..bb9ecf3 100644
--- a/net/filter-mirror.c
+++ b/net/filter-mirror.c
@@ -43,12 +43,14 @@ typedef struct MirrorState {
  SocketReadState rs;
  } MirrorState;
  -static int filter_mirror_send(CharBackend *chr_out,
+static int filter_mirror_send(MirrorState *s,
const struct iovec *iov,
int iovcnt)
  {
+NetFilterState *nf = NETFILTER(s);
  int ret = 0;
  ssize_t size = 0;
+ssize_t vnet_hdr_len;
  uint32_t len = 0;
  char *buf;
  @@ -58,14 +60,30 @@ static int filter_mirror_send(CharBackend 
*chr_out,

  }
len = htonl(size);
-ret = qemu_chr_fe_write_all(chr_out, (uint8_t *), sizeof(len));
+ret = qemu_chr_fe_write_all(>chr_out, (uint8_t *), 
sizeof(len));

+if (ret != sizeof(len)) {
+goto err;
+}
+
+/*
+ * We send vnet header len make other module(like colo-compare)
+ * know how to parse net packet correctly.
+ */
+if (qemu_get_using_vnet_hdr(nf->netdev)) {
+vnet_hdr_len = qemu_get_vnet_hdr_len(nf->netdev);
+} else {
+vnet_hdr_len = qemu_get_vnet_hdr_len(nf->netdev->peer);
+}


Any reason to query peer here?


That's depend on using NetClientState, If we using nf->netdev that need 
to query,
Otherwise we query nf->netdev->peer, then we can get the real 
vnet_hdr_len in my test.


Thanks
Zhang Chen




+
+len = htonl(vnet_hdr_len);
+ret = qemu_chr_fe_write_all(>chr_out, (uint8_t *), 
sizeof(len));

  if (ret != sizeof(len)) {
  goto err;
  }
buf = g_malloc(size);
  iov_to_buf(iov, iovcnt, 0, buf, size);
-ret = qemu_chr_fe_write_all(chr_out, (uint8_t *)buf, size);
+ret = qemu_chr_fe_write_all(>chr_out, (uint8_t *)buf, size);
  g_free(buf);
  if (ret != size) {
  goto err;
@@ -141,7 +159,7 @@ static ssize_t 
filter_mirror_receive_iov(NetFilterState *nf,

  MirrorState *s = FILTER_MIRROR(nf);
  int ret;
  -ret = filter_mirror_send(>chr_out, iov, iovcnt);
+ret = filter_mirror_send(s, iov, iovcnt);
  if (ret) {
  error_report("filter_mirror_send failed(%s)", strerror(-ret));
  }
@@ -164,7 +182,7 @@ static ssize_t 
filter_redirector_receive_iov(NetFilterState *nf,

  int ret;
if (qemu_chr_fe_get_driver(>chr_out)) {
-ret = filter_mirror_send(>chr_out, iov, iovcnt);
+ret = filter_mirror_send(s, iov, iovcnt);
  if (ret) {
  error_report("filter_mirror_send failed(%s)", 
strerror(-ret));

  }


Do we need to strip vnet_hdr_len in redirector_to_filter() ?

Thanks



.



--
Thanks
Zhang Chen






Re: [Qemu-devel] [PATCH V3 01/10] net: Add vnet_hdr_len related callback in NetClientInfo

2017-05-02 Thread Zhang Chen



On 05/02/2017 12:46 PM, Jason Wang wrote:



On 2017年04月28日 17:47, Zhang Chen wrote:

Add get_vnet_hdr_len and get_using_vnet_hdr callback
that make we get vnet_hdr_len easily.

Signed-off-by: Zhang Chen 
---
  include/net/net.h |  6 ++
  net/net.c | 18 ++
  2 files changed, 24 insertions(+)

diff --git a/include/net/net.h b/include/net/net.h
index 99b28d5..402d913 100644
--- a/include/net/net.h
+++ b/include/net/net.h
@@ -57,7 +57,9 @@ typedef RxFilterInfo 
*(QueryRxFilter)(NetClientState *);

  typedef bool (HasUfo)(NetClientState *);
  typedef bool (HasVnetHdr)(NetClientState *);
  typedef bool (HasVnetHdrLen)(NetClientState *, int);
+typedef int (GetVnetHdrLen)(NetClientState *);
  typedef void (UsingVnetHdr)(NetClientState *, bool);
+typedef bool (GetUsingVnetHdr)(NetClientState *);
  typedef void (SetOffload)(NetClientState *, int, int, int, int, int);
  typedef void (SetVnetHdrLen)(NetClientState *, int);
  typedef int (SetVnetLE)(NetClientState *, bool);
@@ -79,7 +81,9 @@ typedef struct NetClientInfo {
  HasUfo *has_ufo;
  HasVnetHdr *has_vnet_hdr;
  HasVnetHdrLen *has_vnet_hdr_len;
+GetVnetHdrLen *get_vnet_hdr_len;
  UsingVnetHdr *using_vnet_hdr;
+GetUsingVnetHdr *get_using_vnet_hdr;
  SetOffload *set_offload;
  SetVnetHdrLen *set_vnet_hdr_len;
  SetVnetLE *set_vnet_le;
@@ -155,7 +159,9 @@ void qemu_format_nic_info_str(NetClientState *nc, 
uint8_t macaddr[6]);

  bool qemu_has_ufo(NetClientState *nc);
  bool qemu_has_vnet_hdr(NetClientState *nc);
  bool qemu_has_vnet_hdr_len(NetClientState *nc, int len);
+int qemu_get_vnet_hdr_len(NetClientState *nc);
  void qemu_using_vnet_hdr(NetClientState *nc, bool enable);
+bool qemu_get_using_vnet_hdr(NetClientState *nc);
  void qemu_set_offload(NetClientState *nc, int csum, int tso4, int 
tso6,

int ecn, int ufo);
  void qemu_set_vnet_hdr_len(NetClientState *nc, int len);
diff --git a/net/net.c b/net/net.c
index 0ac3b9e..f69260f 100644
--- a/net/net.c
+++ b/net/net.c
@@ -466,6 +466,15 @@ bool qemu_has_vnet_hdr_len(NetClientState *nc, 
int len)

  return nc->info->has_vnet_hdr_len(nc, len);
  }
  +int qemu_get_vnet_hdr_len(NetClientState *nc)
+{
+if (!nc || !nc->info->get_vnet_hdr_len) {
+return false;
+}
+
+return nc->info->get_vnet_hdr_len(nc);
+}
+
  void qemu_using_vnet_hdr(NetClientState *nc, bool enable)
  {
  if (!nc || !nc->info->using_vnet_hdr) {
@@ -475,6 +484,15 @@ void qemu_using_vnet_hdr(NetClientState *nc, 
bool enable)

  nc->info->using_vnet_hdr(nc, enable);
  }
  +bool qemu_get_using_vnet_hdr(NetClientState *nc)
+{
+if (!nc || !nc->info->get_using_vnet_hdr) {
+return false;
+}
+
+return nc->info->get_using_vnet_hdr(nc);
+}


Looks like we can do this simply by:

Introduce two common fields in NetClientState:

bool using_vnet_hdr;
int vnet_hdr_len;

And set them during qemu_using_vnet_hdr() and qemu_set_vnet_hdr_len(). 
Then we can query them directly without introducing any new callbacks.


Good idea~
I will implement in next version.

Thanks
Zhang Chen



Thanks


+
  void qemu_set_offload(NetClientState *nc, int csum, int tso4, int 
tso6,

int ecn, int ufo)
  {




.



--
Thanks
Zhang Chen






Re: [Qemu-devel] Subject: [PATCH] target-ppc: Add global timer group A to open-pic.

2017-05-02 Thread alarson
David Gibson  wrote on 04/25/2017 11:34:41 
PM:

Thanks for the review David.  I'll send an updated patch soon with all
your comments addressed and all other s/0/NULL or false/ as
appropriate and a better commit message.

Just to clarify my concern; the patch causes the QEMU openpic timer to
be hard coded at 100MHZ.  This is common, but the openpic spec has
numerous ways the clock could be driven and the actual frequency
depends on target board configuration.  Given that no other users are
apparently using the QEMU openpic timer, it is probably ok, but I did
want to point out the deficiency.



Re: [Qemu-devel] [PATCH qemu v5] memory/iommu: QOM'fy IOMMU MemoryRegion

2017-05-02 Thread Alexey Kardashevskiy
On 03/05/17 02:25, Cornelia Huck wrote:
> On Sat, 29 Apr 2017 22:37:07 +1000
> Alexey Kardashevskiy  wrote:
> 
>> This defines new QOM object - IOMMUMemoryRegion - with MemoryRegion
>> as a parent.
>>
>> This moves IOMMU-related fields from MR to IOMMU MR. However to avoid
>> dymanic QOM casting in fast path (address_space_translate, etc),
>> this adds an @is_iommu boolean flag to MR and provides new helper to
>> do simple cast to IOMMU MR - memory_region_get_iommu. The flag
>> is set in the instance init callback. This defines
>> memory_region_is_iommu as memory_region_get_iommu()!=NULL.
>>
>> This switches MemoryRegion to IOMMUMemoryRegion in most places except
>> the ones where MemoryRegion may be an alias.
>>
>> This defines memory_region_init_iommu_type() to allow creating
>> IOMMUMemoryRegion subclasses. In order to support custom QOM type,
>> this splits memory_region_init() to object_initialize() +
>> memory_region_do_init.
>>
>> Signed-off-by: Alexey Kardashevskiy 
> 
>>  /**
>> + * memory_region_init_iommu_type: Initialize a memory region of a custom 
>> type
>> + * that translates addresses
>> + *
>> + * An IOMMU region translates addresses and forwards accesses to a target
>> + * memory region.
>> + *
>> + * @typename: QOM class name
>> + * @iommumr: the #IOMMUMemoryRegion to be initialized
> 
> 
> I find "iommumr" terribly hard to read. Maybe iommu_mr is better? (Lots
> of times in this patch.)
> 

Terribly? Really? :) Seriously, since linux uses underscores in typenames,
I kind of developed resistance to underscores in variable names which look
like typenames (even though c allows using same token for a type and a
variable). May be just "iommu"? I need one more vote for "iommu" vs.
"iommumr" vs. "iommu_mr" to respin v6 :)


> 
> The s390 parts look fine.
> 


-- 
Alexey



Re: [Qemu-devel] [PATCH RFC] xen/mapcache: store dma information in revmapcache entries for debugging

2017-05-02 Thread no-reply
Hi,

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

Subject: [Qemu-devel] [PATCH RFC] xen/mapcache: store dma information in 
revmapcache entries for debugging
Message-id: alpine.DEB.2.10.1705021646310.8859@sstabellini-ThinkPad-X260
Type: series

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

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

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

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

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
868ff55 xen/mapcache: store dma information in revmapcache entries for debugging

=== OUTPUT BEGIN ===
Checking PATCH 1/1: xen/mapcache: store dma information in revmapcache entries 
for debugging...
ERROR: braces {} are necessary for all arms of this statement
#123: FILE: hw/i386/xen/xen-mapcache.c:431:
+if (!reventry->dma)
[...]

total: 1 errors, 0 warnings, 89 lines checked

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

=== OUTPUT END ===

Test command exited with code: 1


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

[Qemu-devel] [PATCH RFC] xen/mapcache: store dma information in revmapcache entries for debugging

2017-05-02 Thread Stefano Stabellini
The Xen mapcache is able to create long term mappings, they are called
"locked" mappings. The third parameter of the xen_map_cache call
specifies if a mapping is a "locked" mapping.


>From the QEMU point of view there are two kinds of long term mappings:

[a] device memory mappings, such as option roms and video memory
[b] dma mappings, created by dma_memory_map & friends

After certain operations, ballooning a VM in particular, Xen asks QEMU
kindly to destroy all mappings. However, certainly [a] mappings are
present and cannot be removed. That's not a problem as they are not
affected by balloonning. The *real* problem is that if there are any
mappings of type [b], any outstanding dma operations could fail. This is
a known shortcoming. In other words, when Xen asks QEMU to destroy all
mappings, it is an error if any [b] mappings exist.

However today we have no way of distinguishing [a] from [b]. Because of
that, we cannot even print a decent warning.

This patch introduces a new "dma" bool field to MapCacheRev entires, to
remember if a given mapping is for dma or is a long term device memory
mapping. When xen_invalidate_map_cache is called, we print a warning if
any [b] mappings exist. We ignore [a] mappings.

Mappings created by qemu_map_ram_ptr are assumed to be [a], while
mappings created by address_space_map->qemu_ram_ptr_length are assumed
to be [b].

The goal of the patch is to make debugging and system understanding
easier.

Signed-off-by: Stefano Stabellini 

diff --git a/exec.c b/exec.c
index eac6085..85769e1 100644
--- a/exec.c
+++ b/exec.c
@@ -2084,10 +2084,10 @@ void *qemu_map_ram_ptr(RAMBlock *ram_block, ram_addr_t 
addr)
  * In that case just map until the end of the page.
  */
 if (block->offset == 0) {
-return xen_map_cache(addr, 0, 0);
+return xen_map_cache(addr, 0, 0, false);
 }
 
-block->host = xen_map_cache(block->offset, block->max_length, 1);
+block->host = xen_map_cache(block->offset, block->max_length, 1, 
false);
 }
 return ramblock_ptr(block, addr);
 }
@@ -2117,10 +2117,10 @@ static void *qemu_ram_ptr_length(RAMBlock *ram_block, 
ram_addr_t addr,
  * In that case just map the requested area.
  */
 if (block->offset == 0) {
-return xen_map_cache(addr, *size, 1);
+return xen_map_cache(addr, *size, 1, true);
 }
 
-block->host = xen_map_cache(block->offset, block->max_length, 1);
+block->host = xen_map_cache(block->offset, block->max_length, 1, true);
 }
 
 return ramblock_ptr(block, addr);
diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
index 31debdf..fa4282a 100644
--- a/hw/i386/xen/xen-mapcache.c
+++ b/hw/i386/xen/xen-mapcache.c
@@ -62,6 +62,7 @@ typedef struct MapCacheRev {
 hwaddr paddr_index;
 hwaddr size;
 QTAILQ_ENTRY(MapCacheRev) next;
+bool dma;
 } MapCacheRev;
 
 typedef struct MapCache {
@@ -202,7 +203,7 @@ static void xen_remap_bucket(MapCacheEntry *entry,
 }
 
 static uint8_t *xen_map_cache_unlocked(hwaddr phys_addr, hwaddr size,
-   uint8_t lock)
+   uint8_t lock, bool dma)
 {
 MapCacheEntry *entry, *pentry = NULL;
 hwaddr address_index;
@@ -289,6 +290,7 @@ tryagain:
 if (lock) {
 MapCacheRev *reventry = g_malloc0(sizeof(MapCacheRev));
 entry->lock++;
+reventry->dma = dma;
 reventry->vaddr_req = mapcache->last_entry->vaddr_base + 
address_offset;
 reventry->paddr_index = mapcache->last_entry->paddr_index;
 reventry->size = entry->size;
@@ -300,12 +302,12 @@ tryagain:
 }
 
 uint8_t *xen_map_cache(hwaddr phys_addr, hwaddr size,
-   uint8_t lock)
+   uint8_t lock, bool dma)
 {
 uint8_t *p;
 
 mapcache_lock();
-p = xen_map_cache_unlocked(phys_addr, size, lock);
+p = xen_map_cache_unlocked(phys_addr, size, lock, dma);
 mapcache_unlock();
 return p;
 }
@@ -426,8 +428,10 @@ void xen_invalidate_map_cache(void)
 mapcache_lock();
 
 QTAILQ_FOREACH(reventry, >locked_entries, next) {
-DPRINTF("There should be no locked mappings at this time, "
-"but "TARGET_FMT_plx" -> %p is present\n",
+if (!reventry->dma)
+continue;
+fprintf(stderr, "Locked DMA mapping while invalidating mapcache!"
+" "TARGET_FMT_plx" -> %p is present\n",
 reventry->paddr_index, reventry->vaddr_req);
 }
 
diff --git a/include/sysemu/xen-mapcache.h b/include/sysemu/xen-mapcache.h
index b8c93b9..01daaad 100644
--- a/include/sysemu/xen-mapcache.h
+++ b/include/sysemu/xen-mapcache.h
@@ -17,7 +17,7 @@ typedef hwaddr (*phys_offset_to_gaddr_t)(hwaddr start_addr,
 void xen_map_cache_init(phys_offset_to_gaddr_t f,
 void *opaque);
 uint8_t *xen_map_cache(hwaddr phys_addr, hwaddr size,
-

Re: [Qemu-devel] [PATCH 4/4] x86: Support feature=force on the command-line

2017-05-02 Thread Eduardo Habkost
On Tue, May 02, 2017 at 04:42:02PM -0500, Eric Blake wrote:
[...]
> > -if (value) {
> > -cpu->env.features[fp->w] |= fp->mask;
> > -} else {
> > -cpu->env.features[fp->w] &= ~fp->mask;
> > +switch (value->type) {
> > +case QTYPE_QBOOL:
> > +if (value->u.q_bool) {
> > +cpu->env.features[fp->w] |= fp->mask;
> > +} else {
> > +cpu->env.features[fp->w] &= ~fp->mask;
> > +}
> > +cpu->env.forced_features[fp->w] &= ~fp->mask;
> > +cpu->env.user_features[fp->w] |= fp->mask;
> > +break;
> 
> Isn't the break supposed to be indented four more spaces?
> 
[...]

I will fix it in v2. Thanks!

-- 
Eduardo



Re: [Qemu-devel] [PATCH 2/4] string-input-visitor: Support alternate types

2017-05-02 Thread Eduardo Habkost
On Tue, May 02, 2017 at 04:37:03PM -0500, Eric Blake wrote:
> On 05/02/2017 03:31 PM, Eduardo Habkost wrote:
> > When parsing alternates from a string, there are some limitations in
> > what we can do, but it is a valid use case in some situations. We can
> > support booleans, integer types, and enums.
> > 
> > This will be used to support 'feature=force' in -cpu options, while
> > keeping 'feature=on|off|true|false' represented as boolean values.
> > 
> > Signed-off-by: Eduardo Habkost 
> > ---
> 
> >  
> > +/* Support for alternates on string-input-visitor is limited, because
> > + * the input string doesn't have any type information.
> > + *
> > + * Supported alternate member types:
> > + * 1) enums
> > + * 2) integer types
> > + * 3) booleans (but only if the there's no enum variant
> > + *containing "on", "off", "true", or "false" as members)
> > + *
> > + * UNSUPPORTED alternate member types:
> > + * 1) strings
> > + * 2) complex types
> > + */
> > +static void start_alternate(Visitor *v, const char *name,
> > +GenericAlternate **obj, size_t size,
> > +unsigned long supported_qtypes, Error **errp)
> > +{
> > +StringInputVisitor *siv = to_siv(v);
> > +QType t = QTYPE_QSTRING;
> 
> Why do you document string as unsupported, and yet default to
> QTYPE_QSTRING?  I don't see how a string is fundamentally different from
> an enum (no alternate can have both at the same time, an alternate with
> either type will have QTYPE_QSTRING set in supported_qtypes).

Strings are indistinguishable from enums inside
start_alternate(), that's true. But I wanted to explicitly
document 'str' as unsupported by string-input-visitor because
some string values would necessarily overlap with the string
representation of other variants.

> 
> > +
> > +if (supported_qtypes & BIT(QTYPE_QBOOL)) {
> > +if (try_parse_bool(siv->string, NULL) == 0) {
> > +t = QTYPE_QBOOL;
> > +}
> > +}
> > +
> > +if (supported_qtypes & BIT(QTYPE_QINT)) {
> > +if (parse_str(siv, name, NULL) == 0) {
> > +t = QTYPE_QINT;
> > +}
> > +}
> > +
> > +*obj = g_malloc0(size);
> > +(*obj)->type = t;
> 
> Should you raise an error if you couldn't match the input with
> supported_qtypes, rather than just blindly returning QTYPE_QSTRING?

The generated visitors calling visit_start_alternate() already
generate a (more specific and more useful) error message when
they see unsupported types.

-- 
Eduardo



Re: [Qemu-devel] [PATCH 1/4] visitor: Add 'supported_qtypes' parameter to visit_start_alternate()

2017-05-02 Thread Eduardo Habkost
On Tue, May 02, 2017 at 04:29:32PM -0500, Eric Blake wrote:
> On 05/02/2017 03:31 PM, Eduardo Habkost wrote:
> > This will allow visitors to make decisions based on the supported qtypes
> > of a given alternate type. The new parameter can replace the old
> > 'promote_int' argument, as qobject-input-visitor can simply check if
> > QTYPE_QINT is set in supported_qtypes.
> > 
> > Signed-off-by: Eduardo Habkost 
> > ---
> 
> > @@ -416,7 +417,7 @@ void visit_end_list(Visitor *v, void **list);
> >   */
> >  void visit_start_alternate(Visitor *v, const char *name,
> > GenericAlternate **obj, size_t size,
> > -   bool promote_int, Error **errp);
> > +   unsigned long supported_qtypes, Error **errp);
> 
> Why unsigned long (which is platform-dependent in size)? At the moment,
> even unsigned char happens to be long enough, although I probably would
> have used uint32_t.
> 
> Oh, I see, it's because you use the BIT() macros from bitops.h, which
> are hardcoded to unsigned long.

Yep. But I don't see a problem with using uint32_t or a simple
int.

> 
> > +++ b/scripts/qapi-visit.py
> > @@ -161,20 +161,21 @@ void visit_type_%(c_name)s(Visitor *v, const char 
> > *name, %(c_name)s *obj, Error
> >  
> >  
> >  def gen_visit_alternate(name, variants):
> > -promote_int = 'true'
> > +qtypes = ['BIT(%s)' % (var.type.alternate_qtype())
> > +  for var in variants.variants]
> > +supported_qtypes = '|'.join(qtypes)
> 
> Do you want ' | '.join(qtypes), so that at least the generated code
> still follows recommended operator spacing? (The line is long no matter
> what, though, and that's not worth worrying about.)

I can do that in v2.

> 
> >  ret = ''
> > -for var in variants.variants:
> > -if var.type.alternate_qtype() == 'QTYPE_QINT':
> > -promote_int = 'false'
> >  
> >  ret += mcgen('''
> >  
> >  void visit_type_%(c_name)s(Visitor *v, const char *name, %(c_name)s **obj, 
> > Error **errp)
> >  {
> >  Error *err = NULL;
> > +unsigned long supported_qtypes = %(supported_qtypes)s;
> >  
> > +assert(QTYPE__MAX < BITS_PER_LONG);
> 
> Do we really have to generate a separate copy of this assert in every
> generated function?  Especially when we know it is true by construction,
> that seems like a lot.  Having the assertion once in a .c file rather
> than generated in multiple functions might be acceptable, though.

I will probably do this as a single QEMU_BUILD_BUG_ON near
visit_start_alternate().

> 
> > +++ b/qapi/qobject-input-visitor.c
> 
> > @@ -349,7 +351,7 @@ static void qobject_input_start_alternate(Visitor *v, 
> > const char *name,
> >  }
> >  *obj = g_malloc0(size);
> >  (*obj)->type = qobject_type(qobj);
> > -if (promote_int && (*obj)->type == QTYPE_QINT) {
> > +if (!(supported_qtypes & BIT(QTYPE_QINT)) && (*obj)->type == 
> > QTYPE_QINT) {
> 
> Experimenting, does this read any better:
> 
> if (!extract32(supported_qtypes, QTYPE_QINT, 1) && ...
> 
> which would be another argument for uint32_t instead of unsigned long in
> the signature.

I am more used to see this written as "if (s & (1UL << n))" than
as "if (extract32(s, n, 1))", so I'm not sure.

I see some extract32(..., ..., 1) cases in the tree, so it's not
as unusual as I thought. I will probably give it a try.

> 
> The idea makes sense, but I'm still not necessarily sold on using a long.

Thanks!

-- 
Eduardo



Re: [Qemu-devel] [PATCH 04/13] arm: Clean up handling of no-MPU PMSA CPUs

2017-05-02 Thread Alistair Francis
On Tue, Apr 25, 2017 at 5:07 AM, Peter Maydell  wrote:
> ARM CPUs come in two flavours:
>  * proper MMU ("VMSA")
>  * only an MPU ("PMSA")
> For PMSA, the MPU may be implemented, or not (in which case there
> is default "always acts the same" behaviour, but it isn't guest
> programmable).
>
> QEMU is a bit confused about how we indicate this: we have an
> ARM_FEATURE_MPU, but it's not clear whether this indicates
> "PMSA, not VMSA" or "PMSA and MPU present" , and sometimes we
> use it for one purpose and sometimes the other.
>
> Currently trying to implement a PMSA-without-MPU core won't
> work correctly because we turn off the ARM_FEATURE_MPU bit
> and then a lot of things which should still exist get
> turned off too.
>
> As the first step in cleaning this up, rename the feature
> bit to ARM_FEATURE_PMSA, which indicates a PMSA CPU (with
> or without MPU).
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Alistair Francis 

Thanks,

Alistair

> ---
>  target/arm/cpu.h |  2 +-
>  target/arm/cpu.c | 12 ++--
>  target/arm/helper.c  | 12 ++--
>  target/arm/machine.c |  2 +-
>  4 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 253565b..0718955 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -1179,7 +1179,7 @@ enum arm_features {
>  ARM_FEATURE_V6K,
>  ARM_FEATURE_V7,
>  ARM_FEATURE_THUMB2,
> -ARM_FEATURE_MPU,/* Only has Memory Protection Unit, not full MMU.  */
> +ARM_FEATURE_PMSA,   /* no MMU; may have Memory Protection Unit */
>  ARM_FEATURE_VFP3,
>  ARM_FEATURE_VFP_FP16,
>  ARM_FEATURE_NEON,
> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> index b357aee..f17e279 100644
> --- a/target/arm/cpu.c
> +++ b/target/arm/cpu.c
> @@ -586,7 +586,7 @@ static void arm_cpu_post_init(Object *obj)
>   _abort);
>  }
>
> -if (arm_feature(>env, ARM_FEATURE_MPU)) {
> +if (arm_feature(>env, ARM_FEATURE_PMSA)) {
>  qdev_property_add_static(DEVICE(obj), _cpu_has_mpu_property,
>   _abort);
>  if (arm_feature(>env, ARM_FEATURE_V7)) {
> @@ -682,7 +682,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
> **errp)
>
>  if (arm_feature(env, ARM_FEATURE_V7) &&
>  !arm_feature(env, ARM_FEATURE_M) &&
> -!arm_feature(env, ARM_FEATURE_MPU)) {
> +!arm_feature(env, ARM_FEATURE_PMSA)) {
>  /* v7VMSA drops support for the old ARMv5 tiny pages, so we
>   * can use 4K pages.
>   */
> @@ -758,10 +758,10 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
> **errp)
>  }
>
>  if (!cpu->has_mpu) {
> -unset_feature(env, ARM_FEATURE_MPU);
> +unset_feature(ARM_FEATURE_PMSA);
>  }
>
> -if (arm_feature(env, ARM_FEATURE_MPU) &&
> +if (arm_feature(env, ARM_FEATURE_PMSA) &&
>  arm_feature(env, ARM_FEATURE_V7)) {
>  uint32_t nr = cpu->pmsav7_dregion;
>
> @@ -861,7 +861,7 @@ static void arm946_initfn(Object *obj)
>
>  cpu->dtb_compatible = "arm,arm946";
>  set_feature(>env, ARM_FEATURE_V5);
> -set_feature(>env, ARM_FEATURE_MPU);
> +set_feature(>env, ARM_FEATURE_PMSA);
>  set_feature(>env, ARM_FEATURE_DUMMY_C15_REGS);
>  cpu->midr = 0x41059461;
>  cpu->ctr = 0x0f004006;
> @@ -1073,7 +1073,7 @@ static void cortex_r5_initfn(Object *obj)
>  set_feature(>env, ARM_FEATURE_THUMB_DIV);
>  set_feature(>env, ARM_FEATURE_ARM_DIV);
>  set_feature(>env, ARM_FEATURE_V7MP);
> -set_feature(>env, ARM_FEATURE_MPU);
> +set_feature(>env, ARM_FEATURE_PMSA);
>  cpu->midr = 0x411fc153; /* r1p3 */
>  cpu->id_pfr0 = 0x0131;
>  cpu->id_pfr1 = 0x001;
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index 791332c..404bfdb 100644
> --- a/target/arm/helper.c
> +++ b/target/arm/helper.c
> @@ -485,7 +485,7 @@ static void contextidr_write(CPUARMState *env, const 
> ARMCPRegInfo *ri,
>  {
>  ARMCPU *cpu = arm_env_get_cpu(env);
>
> -if (raw_read(env, ri) != value && !arm_feature(env, ARM_FEATURE_MPU)
> +if (raw_read(env, ri) != value && !arm_feature(env, ARM_FEATURE_PMSA)
>  && !extended_addresses_enabled(env)) {
>  /* For VMSA (when not using the LPAE long descriptor page table
>   * format) this register includes the ASID, so do a TLB flush.
> @@ -4615,7 +4615,7 @@ void register_cp_regs_for_features(ARMCPU *cpu)
>  define_arm_cp_regs(cpu, v6k_cp_reginfo);
>  }
>  if (arm_feature(env, ARM_FEATURE_V7MP) &&
> -!arm_feature(env, ARM_FEATURE_MPU)) {
> +!arm_feature(env, ARM_FEATURE_PMSA)) {
>  define_arm_cp_regs(cpu, v7mp_cp_reginfo);
>  }
>  if (arm_feature(env, ARM_FEATURE_V7)) {
> @@ -4969,7 +4969,7 @@ void register_cp_regs_for_features(ARMCPU *cpu)
>  }
>  }
>
> -if (arm_feature(env, ARM_FEATURE_MPU)) {

Re: [Qemu-devel] [PATCH 05/13] arm: Don't clear ARM_FEATURE_PMSA for no-mpu configs

2017-05-02 Thread Alistair Francis
On Tue, Apr 25, 2017 at 5:07 AM, Peter Maydell  wrote:
> Fix the handling of QOM properties for PMSA CPUs with no MPU:
>
> Allow no-MPU to be specified by either:
>  * has-mpu = false
>  * pmsav7_dregion = 0
> and make setting one imply the other. Don't clear the PMSA
> feature bit in this situation.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Alistair Francis 

Thanks,

Alistair

> ---
>  target/arm/cpu.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> index f17e279..8e57498 100644
> --- a/target/arm/cpu.c
> +++ b/target/arm/cpu.c
> @@ -757,8 +757,14 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
> **errp)
>  cpu->id_pfr1 &= ~0xf000;
>  }
>
> +/* MPU can be configured out of a PMSA CPU either by setting has-mpu
> + * to false or by setting pmsav7-dregion to 0.
> + */
>  if (!cpu->has_mpu) {
> -unset_feature(ARM_FEATURE_PMSA);
> +cpu->pmsav7_dregion = 0;
> +}
> +if (cpu->pmsav7_dregion == 0) {
> +cpu->has_mpu = false;
>  }
>
>  if (arm_feature(env, ARM_FEATURE_PMSA) &&
> --
> 2.7.4
>
>



Re: [Qemu-devel] [PATCH 02/13] arm: Add support for M profile CPUs having different MMU index semantics

2017-05-02 Thread Alistair Francis
On Tue, Apr 25, 2017 at 5:06 AM, Peter Maydell  wrote:
> The M profile CPU's MPU has an awkward corner case which we
> would like to implement with a different MMU index.
>
> We can avoid having to bump the number of MMU modes ARM
> uses, because some of our existing MMU indexes are only
> used by non-M-profile CPUs, so we can borrow one.
> To avoid that getting too confusing, clean up the code
> to try to keep the two meanings of the index separate.
>
> Instead of ARMMMUIdx enum values being identical to core QEMU
> MMU index values, they are now the core index values with some
> high bits set. Any particular CPU always uses the same high
> bits (so eventually A profile cores and M profile cores will
> use different bits). New functions arm_to_core_mmu_idx()
> and core_to_arm_mmu_idx() convert between the two.
>
> In general core index values are stored in 'int' types, and
> ARM values are stored in ARMMMUIdx types.
>
> Signed-off-by: Peter Maydell 

This looks ok to me. I'm a little worried it will make SMMU or some
ARMv9 (or whatever the next thing is) work more complicated as we have
this.

Thanks,

Alistair

> ---
>  target/arm/cpu.h   |  71 -
>  target/arm/translate.h |   2 +-
>  target/arm/helper.c| 151 
> -
>  target/arm/op_helper.c |   3 +-
>  target/arm/translate-a64.c |  18 --
>  target/arm/translate.c |  10 +--
>  6 files changed, 156 insertions(+), 99 deletions(-)
>
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 1055bfe..e1f4856 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -2037,6 +2037,16 @@ static inline bool arm_excp_unmasked(CPUState *cs, 
> unsigned int excp_idx,
>   * for the accesses done as part of a stage 1 page table walk, rather than
>   * having to walk the stage 2 page table over and over.)
>   *
> + * The ARMMMUIdx and the mmu index value used by the core QEMU TLB code
> + * are not quite the same -- different CPU types (most notably M profile
> + * vs A/R profile) would like to use MMU indexes with different semantics,
> + * but since we don't ever need to use all of those in a single CPU we
> + * can avoid setting NB_MMU_MODES to more than 8. The lower bits of
> + * ARMMMUIdx are the core TLB mmu index, and the higher bits are always
> + * the same for any particular CPU.
> + * Variables of type ARMMUIdx are always full values, and the core
> + * index values are in variables of type 'int'.
> + *
>   * Our enumeration includes at the end some entries which are not "true"
>   * mmu_idx values in that they don't have corresponding TLBs and are only
>   * valid for doing slow path page table walks.
> @@ -2045,28 +2055,61 @@ static inline bool arm_excp_unmasked(CPUState *cs, 
> unsigned int excp_idx,
>   * of the AT/ATS operations.
>   * The values used are carefully arranged to make mmu_idx => EL lookup easy.
>   */
> +#define ARM_MMU_IDX_A 0x10 /* A profile (and M profile, for the moment) */
> +#define ARM_MMU_IDX_NOTLB 0x20 /* does not have a TLB */
> +
> +#define ARM_MMU_IDX_TYPE_MASK (~0x7)
> +#define ARM_MMU_IDX_COREIDX_MASK 0x7
> +
>  typedef enum ARMMMUIdx {
> -ARMMMUIdx_S12NSE0 = 0,
> -ARMMMUIdx_S12NSE1 = 1,
> -ARMMMUIdx_S1E2 = 2,
> -ARMMMUIdx_S1E3 = 3,
> -ARMMMUIdx_S1SE0 = 4,
> -ARMMMUIdx_S1SE1 = 5,
> -ARMMMUIdx_S2NS = 6,
> +ARMMMUIdx_S12NSE0 = 0 | ARM_MMU_IDX_A,
> +ARMMMUIdx_S12NSE1 = 1 | ARM_MMU_IDX_A,
> +ARMMMUIdx_S1E2 = 2 | ARM_MMU_IDX_A,
> +ARMMMUIdx_S1E3 = 3 | ARM_MMU_IDX_A,
> +ARMMMUIdx_S1SE0 = 4 | ARM_MMU_IDX_A,
> +ARMMMUIdx_S1SE1 = 5 | ARM_MMU_IDX_A,
> +ARMMMUIdx_S2NS = 6 | ARM_MMU_IDX_A,
>  /* Indexes below here don't have TLBs and are used only for AT system
>   * instructions or for the first stage of an S12 page table walk.
>   */
> -ARMMMUIdx_S1NSE0 = 7,
> -ARMMMUIdx_S1NSE1 = 8,
> +ARMMMUIdx_S1NSE0 = 0 | ARM_MMU_IDX_NOTLB,
> +ARMMMUIdx_S1NSE1 = 1 | ARM_MMU_IDX_NOTLB,
>  } ARMMMUIdx;
>
> +/* Bit macros for the core-mmu-index values for each index,
> + * for use when calling tlb_flush_by_mmuidx() and friends.
> + */
> +typedef enum ARMMMUIdxBit {
> +ARMMMUIdxBit_S12NSE0 = 1 << 0,
> +ARMMMUIdxBit_S12NSE1 = 1 << 1,
> +ARMMMUIdxBit_S1E2 = 1 << 2,
> +ARMMMUIdxBit_S1E3 = 1 << 3,
> +ARMMMUIdxBit_S1SE0 = 1 << 4,
> +ARMMMUIdxBit_S1SE1 = 1 << 5,
> +ARMMMUIdxBit_S2NS = 1 << 6,
> +} ARMMMUIdxBit;
> +
>  #define MMU_USER_IDX 0
>
> +static inline int arm_to_core_mmu_idx(ARMMMUIdx mmu_idx)
> +{
> +return mmu_idx & ARM_MMU_IDX_COREIDX_MASK;
> +}
> +
> +static inline ARMMMUIdx core_to_arm_mmu_idx(CPUARMState *env, int mmu_idx)
> +{
> +return mmu_idx | ARM_MMU_IDX_A;
> +}
> +
>  /* Return the exception level we're running at if this is our mmu_idx */
>  static inline int arm_mmu_idx_to_el(ARMMMUIdx mmu_idx)
>  {
> -assert(mmu_idx < ARMMMUIdx_S2NS);
> -return mmu_idx & 3;
> +   

Re: [Qemu-devel] [PATCH v3 3/4] qmp: refactor duplicate code

2017-05-02 Thread Eric Blake
On 05/02/2017 09:29 AM, Pradeep Jagadeesh wrote:
> This patchset factor out the duplicate qmp throttle interface code
> that was present in both block and fsdev device files.

Instead of adding the duplicate code in patch 2 then cleaning it out
here, you should refactor this patch to be first (fix existing code in
blockdev.c to make use of the new interfaces), then add the new fsdev
code that uses this code right away.

> 
> Signed-off-by: Pradeep Jagadeesh 
> ---
>  blockdev.c  | 53 +++--
>  fsdev/qemu-fsdev-throttle.c | 51 +---
>  fsdev/qemu-fsdev.c  |  1 -
>  hmp.c   | 34 
>  include/qemu/throttle-options.h |  5 
>  util/Makefile.objs  |  1 +
>  util/throttle-options.c | 58 
> +
>  7 files changed, 85 insertions(+), 118 deletions(-)
>  create mode 100644 util/throttle-options.c
> 

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



signature.asc
Description: OpenPGP digital signature


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

2017-05-02 Thread Eric Blake
On 05/02/2017 09:29 AM, Pradeep Jagadeesh wrote:
> This patchset enables qmp interfaces for the fsdev
> devices. This provides two interfaces one 
> for querying info of all the fsdev devices. The second one
> to set the IO limits for the required fsdev device.
> 
> Signed-off-by: Pradeep Jagadeesh 
> ---

> +++ b/fsdev/qemu-fsdev-throttle.c
> @@ -29,6 +29,102 @@ static void fsdev_throttle_write_timer_cb(void *opaque)
>  qemu_co_enter_next(>throttled_reqs[true]);
>  }
>  
> +void fsdev_set_io_throttle(IOThrottle *arg, FsThrottle *fst, Error **errp)
> +{
> +ThrottleConfig cfg;
> +
> +throttle_config_init();
> +cfg.buckets[THROTTLE_BPS_TOTAL].avg = arg->bps;
> +cfg.buckets[THROTTLE_BPS_READ].avg  = arg->bps_rd;
> +cfg.buckets[THROTTLE_BPS_WRITE].avg = arg->bps_wr;
> +
> +cfg.buckets[THROTTLE_OPS_TOTAL].avg = arg->iops;
> +cfg.buckets[THROTTLE_OPS_READ].avg  = arg->iops_rd;
> +cfg.buckets[THROTTLE_OPS_WRITE].avg = arg->iops_wr;
> +
> +if (arg->has_bps_max) {
> +cfg.buckets[THROTTLE_BPS_TOTAL].max = arg->bps_max;
> +}

Should the bulk of this be replaced by a call to a common IOThrottle
helper function, rather than open-coded duplication?


> +
> +void fsdev_get_io_throttle(FsThrottle *fst, IOThrottle **fs9pcfg,
> +   char *fsdevice, Error **errp)
> +{
> +
> +ThrottleConfig cfg = fst->cfg;
> +IOThrottle *fscfg = g_malloc0(sizeof(*fscfg));
> +
> +fscfg->has_id = true;
> +fscfg->id = g_strdup(fsdevice);
> +fscfg->bps = cfg.buckets[THROTTLE_BPS_TOTAL].avg;
> +fscfg->bps_rd = cfg.buckets[THROTTLE_BPS_READ].avg;
> +fscfg->bps_wr = cfg.buckets[THROTTLE_BPS_WRITE].avg;

Shouldn't you be setting has_bps, has_bps_rd, has_bps_wr, and so on, to
true?


> +++ b/fsdev/qemu-fsdev-throttle.h
> @@ -19,7 +19,14 @@
>  #include "qemu/main-loop.h"
>  #include "qemu/coroutine.h"
>  #include "qapi/error.h"
> +#include "qapi/qmp/qerror.h"
>  #include "qemu/throttle.h"
> +#include "qapi/qmp/types.h"
> +#include "qapi-visit.h"
> +#include "qapi/qobject-output-visitor.h"
> +#include "qapi/util.h"
> +#include "qmp-commands.h"
> +#include "qemu/throttle-options.h"
>  
>  typedef struct FsThrottle {
>  ThrottleState ts;
> @@ -36,4 +43,10 @@ void coroutine_fn fsdev_co_throttle_request(FsThrottle *, 
> bool ,
>  struct iovec *, int);
>  
>  void fsdev_throttle_cleanup(FsThrottle *);
> +
> +void fsdev_set_io_throttle(IOThrottle *, FsThrottle *, Error **);

Even though it's not necessary per C, we tend to spell parameter names
in function declarations as it aids legibility.  (Seeing 'Error **' is
weird compared to the usual 'Error **errp')


> @@ -1570,6 +1571,80 @@ void hmp_block_set_io_throttle(Monitor *mon, const 
> QDict *qdict)
>  hmp_handle_error(mon, );
>  }
>  
> +#ifdef CONFIG_VIRTFS
> +
> +void hmp_fsdev_set_io_throttle(Monitor *mon, const QDict *qdict)
> +{
> +Error *err = NULL;
> +IOThrottle throttle = {
> +.has_id = true,
> +.id = (char *) qdict_get_str(qdict, "id"),
> +.bps = qdict_get_int(qdict, "bps"),
> +.bps_rd = qdict_get_int(qdict, "bps_rd"),
> +.bps_wr = qdict_get_int(qdict, "bps_wr"),
> +.iops = qdict_get_int(qdict, "iops"),
> +.iops_rd = qdict_get_int(qdict, "iops_rd"),
> +.iops_wr = qdict_get_int(qdict, "iops_wr"),

Again, don't you need to be setting .has_bps=true and so on?


> +++ b/qapi/fsdev.json
> @@ -0,0 +1,84 @@
> +# -*- Mode: Python -*-
> +
> +##
> +# == QAPI fsdev definitions
> +##
> +
> +# QAPI common definitions
> +{ 'include': 'iothrottle.json' }
> +
> +##
> +# @fsdev-set-io-throttle:
> +#
> +# Change I/O limits for a 9p/fsdev device.
> +#
> +# I/O limits can be enabled by setting throttle value to non-zero number.
> +#
> +# I/O limits can be disabled by setting all throttle values to 0.
> +#
> +# Returns: Nothing on success
> +#  If @device is not a valid fsdev device, DeviceNotFound
> +#
> +# Since: 2.10
> +#
> +# Example:
> +#
> +# -> { "execute": "fsdev-set-io-throttle",
> +#  "arguments": { "id": "id0-1-0",
> +# "bps": 100,
> +# "bps_rd": 0,
> +# "bps_wr": 0,
> +# "iops": 0,
> +# "iops_rd": 0,
> +# "iops_wr": 0,
> +# "bps_max": 800,
> +# "bps_rd_max": 0,
> +# "bps_wr_max": 0,
> +# "iops_max": 0,
> +# "iops_rd_max": 0,
> +# "iops_wr_max": 0,
> +# "bps_max_length": 60,
> +# "iops_size": 0 } }
> +# <- { "returns": {} }
> +##
> +{ 'command': 'fsdev-set-io-throttle', 'boxed': true,
> +  'data': 'IOThrottle' }

This part looks okay.

> +##
> +# @query-fsdev-io-throttle:
> +#
> +# Returns: a list of @IOThrottle describing io throttle values of each fsdev 
> 

Re: [Qemu-devel] [PATCH 01/13] arm: Use the mmu_idx we're passed in arm_cpu_do_unaligned_access()

2017-05-02 Thread Alistair Francis
On Tue, Apr 25, 2017 at 5:06 AM, Peter Maydell  wrote:
> When identifying the DFSR format for an alignment fault, use
> the mmu index that we are passed, rather than calling cpu_mmu_index()
> to get the mmu index for the current CPU state. This doesn't actually
> make any difference since the only cases where the current MMU index
> differs from the index used for the load are the "unprivileged
> load/store" instructions, and in that case the mmu index may
> differ but the translation regime is the same (apart from the
> "use from Hyp mode" case which is UNPREDICTABLE).
> However it's the more logical thing to do.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Alistair Francis 

Thanks,

Alistair

> ---
>  target/arm/op_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/arm/op_helper.c b/target/arm/op_helper.c
> index 156b825..de24815 100644
> --- a/target/arm/op_helper.c
> +++ b/target/arm/op_helper.c
> @@ -208,7 +208,7 @@ void arm_cpu_do_unaligned_access(CPUState *cs, vaddr 
> vaddr,
>  /* the DFSR for an alignment fault depends on whether we're using
>   * the LPAE long descriptor format, or the short descriptor format
>   */
> -if (arm_s1_regime_using_lpae_format(env, cpu_mmu_index(env, false))) {
> +if (arm_s1_regime_using_lpae_format(env, mmu_idx)) {
>  env->exception.fsr = (1 << 9) | 0x21;
>  } else {
>  env->exception.fsr = 0x1;
> --
> 2.7.4
>
>



Re: [Qemu-devel] [PATCH v3 1/4] Throttle: Create IOThrottle structure

2017-05-02 Thread Eric Blake
On 05/02/2017 09:29 AM, Pradeep Jagadeesh wrote:
> This patchset introduces a new io throttle structure. This will be
> used in both block and fsdev devices.
> 
> Signed-off-by: Pradeep Jagadeesh 
> ---
>  qapi/block-core.json | 76 ++
>  qapi/iothrottle.json | 86 
> 
>  2 files changed, 89 insertions(+), 73 deletions(-)
>  create mode 100644 qapi/iothrottle.json
> 

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [Qemu-devel RFC v3 1/5] msf2: Add Smartfusion2 System timer

2017-05-02 Thread Alistair Francis
On Fri, Apr 28, 2017 at 9:51 AM, Subbaraya Sundeep
 wrote:
> Modelled System Timer in Microsemi's Smartfusion2 Soc.
> Timer has two 32bit down counters and two interrupts.
>
> Signed-off-by: Subbaraya Sundeep 
> ---
>  hw/timer/Makefile.objs|   1 +
>  hw/timer/msf2_timer.c | 250 
> ++
>  include/hw/timer/msf2_timer.h |  82 ++
>  3 files changed, 333 insertions(+)
>  create mode 100644 hw/timer/msf2_timer.c
>  create mode 100644 include/hw/timer/msf2_timer.h
>
> diff --git a/hw/timer/Makefile.objs b/hw/timer/Makefile.objs
> index dd6f27e..0bdf1e1 100644
> --- a/hw/timer/Makefile.objs
> +++ b/hw/timer/Makefile.objs
> @@ -41,3 +41,4 @@ common-obj-$(CONFIG_STM32F2XX_TIMER) += stm32f2xx_timer.o
>  common-obj-$(CONFIG_ASPEED_SOC) += aspeed_timer.o
>
>  common-obj-$(CONFIG_SUN4V_RTC) += sun4v-rtc.o
> +common-obj-$(CONFIG_MSF2) += msf2_timer.o
> diff --git a/hw/timer/msf2_timer.c b/hw/timer/msf2_timer.c
> new file mode 100644
> index 000..d1dbde5
> --- /dev/null
> +++ b/hw/timer/msf2_timer.c

Hey Sundeep,

File names should use '-' instead of '_'.

> @@ -0,0 +1,250 @@
> +/*
> + * Timer block model of Microsemi SmartFusion2.
> + *
> + * Copyright (c) 2017 Subbaraya Sundeep .
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a 
> copy
> + * of this software and associated documentation files (the "Software"), to 
> deal
> + * in the Software without restriction, including without limitation the 
> rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> + * THE SOFTWARE.
> + */
> +
> +#include "qemu/osdep.h"
> +#include "hw/timer/msf2_timer.h"
> +#include "hw/sysbus.h"
> +#include "qemu/log.h"
> +#include "qemu/main-loop.h"

Do you need to include the main-loop.h? This doesn't look right.

> +
> +#ifndef MSF2_TIMER_ERR_DEBUG
> +#define MSF2_TIMER_ERR_DEBUG  0
> +#endif
> +
> +#define DB_PRINT_L(lvl, fmt, args...) do { \
> +if (MSF2_TIMER_ERR_DEBUG >= lvl) { \
> +qemu_log("%s: " fmt, __func__, ## args); \
> +} \
> +} while (0);
> +
> +#define DB_PRINT(fmt, args...) DB_PRINT_L(1, fmt, ## args)
> +
> +static void timer_update_irq(struct Msf2Timer *st)
> +{
> +bool isr, ier;
> +
> +isr = !!(st->regs[R_TIM_RIS] & TIMER_RIS_ACK);
> +ier = !!(st->regs[R_TIM_CTRL] & TIMER_CTRL_INTR);
> +
> +qemu_set_irq(st->irq, (ier && isr));
> +}
> +
> +static void timer_update(struct Msf2Timer *st)
> +{
> +uint64_t count;
> +
> +DB_PRINT("timer=%d\n", st->nr);

Maybe make this a little more explict. Something like "Updating timer: %d"?

> +
> +if (!(st->regs[R_TIM_CTRL] & TIMER_CTRL_ENBL)) {
> +ptimer_stop(st->ptimer);
> +return;
> +}
> +
> +count = st->regs[R_TIM_LOADVAL];
> +ptimer_set_limit(st->ptimer, count, 1);
> +ptimer_run(st->ptimer, 1);
> +}
> +
> +static uint64_t
> +timer_read(void *opaque, hwaddr addr, unsigned int size)
> +{
> +MSF2TimerState *t = opaque;
> +struct Msf2Timer *st;
> +uint32_t r = 0;

Call the ret instead of r and it should be a uint64_t.

> +unsigned int timer = 0;

Isn't the timer normally an int? Try to use the same type throughout the code.

> +int isr;
> +int ier;
> +
> +addr >>= 2;
> +/*
> + * Two independent timers has same base address.
> + * Based on addr passed figure out which timer is being used.
> + */
> +if (addr >= R_TIM1_MAX) {
> +timer = 1;
> +addr -= R_TIM1_MAX;
> +}
> +
> +st = >timers[timer];
> +
> +switch (addr) {
> +case R_TIM_VAL:
> +r = ptimer_get_count(st->ptimer);
> +DB_PRINT("msf2_timer t=%d read counter=%x\n", timer, r);

Put a 0x in front of hex values.

Also %x isn't the correct type for uint64_t, it's something similar to PRIx.

> +break;
> +
> +case R_TIM_MIS:
> +isr = !!(st->regs[R_TIM_RIS] & TIMER_RIS_ACK);
> +ier = !!(st->regs[R_TIM_CTRL] & TIMER_CTRL_INTR);
> +r = ier && isr;

This should be a bitwise AND.

> +break;
> +
> +default:
> +if (addr < ARRAY_SIZE(st->regs)) {
> +r 

Re: [Qemu-devel] [virtio-dev] [PATCH v18 0/2] virtio-crypto: virtio crypto device specification

2017-05-02 Thread Halil Pasic

Hi Gonglei!

I've started reviewing but it's going to take some time because
I've missed the previous version (vacation) and v16 was a long
time ago, so I have to re-check and re-learn things.

My first impression is, it reads much better that v16 but still
has some space for improvement.

One idea would be adding some references defining the
crypto services and algorithms. IMHO it would make the
spec a bit rounder, although from pragmatical perspective
I think we can safely assume, that the target audience is able
to figure out the stuff without.

Cheers,
Halil


On 04/22/2017 08:23 AM, Gonglei wrote:
> As a non-native English speaker, I sincerely hope you
> give me more suggestions about English style and/or
> grammar for the spec. Thanks!
> 
> 
> v18 -> v17:
>  - fix many English grammar problems suggested by Stefan, Thanks a lot!
> 
> v17 -> v16:
>  - Some grammar fixes [Stefan, Halil, Michael]
>  - add a section named "Supported crypto services" in order to explain bit
>numbers and valuse clearly. [Halil, Cornelia]
>  - avoid word reptition [Halil]
>  - rename non-session mode to stateless mode [Halil]
>  - change descriptions for all elements in struct virtio_crypto_config [Halil]
>  - add Halil as a reviewer in the ackonwledgement part, thanks for his work.
>  - other fixes here and there.
> 
> Changes since v15:
>  - use feature bits for non-session mode in order to keep compatibility with
>pre-existing code. [Halil & Michael]
>  - introduce VIRTIO_CRYPTO_F_ NON_SESSION_MODE feature bit to control all 
> other
>non-session mode feature bits.
>  - fix some typos. [Stefan]
>  - introduce struct virtio_crypto_op_data_req_mux to support both session
>and non-session based crypto operations and keep compatibility with
>pre-existing code.
> 
> Changes since v14:
>  - drop VIRTIO_CRYPTO_S_STARTED status [Halil & Cornelia]
>  - correct a sentence about dataqueue and controlq in the first paragraph. 
> [Halil]
>  - change a MAY to MUST about max_dataqueues. [Halil]
>  - add non-session mode support
>a) add four features for different crypto services to identify wheather 
> support session mode.
>b) rewrite some
> 
> For pervious versions of virtio crypto spec, Pls see:
> 
> [v14]:
> https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg02212.html
> 
> [v13]:
> https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg07348.html
> 
> For more information, please see:
>  http://qemu-project.org/Features/VirtioCrypto
> 
> 
> Gonglei (2):
>   virtio-crypto: Add virtio crypto device specification
>   virtio-crypto: Add conformance clauses
> 
>  acknowledgements.tex |2 +
>  conformance.tex  |   29 ++
>  content.tex  |2 +
>  virtio-crypto.tex| 1309 
> ++
>  4 files changed, 1342 insertions(+)
>  create mode 100644 virtio-crypto.tex
> 




Re: [Qemu-devel] [PATCH 4/4] x86: Support feature=force on the command-line

2017-05-02 Thread Eric Blake
On 05/02/2017 03:31 PM, Eduardo Habkost wrote:
> Introduce a new CPUFeatureSetting QAPI data type, and use it to support
> feature=force on -cpu.
> 
> Signed-off-by: Eduardo Habkost 
> ---
>  qapi-schema.json  | 32 +
>  target/i386/cpu.h |  2 ++
>  target/i386/cpu.c | 55 
> +--
>  tests/test-x86-cpuid-compat.c | 14 ++-
>  4 files changed, 90 insertions(+), 13 deletions(-)
> 
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 01b087fa16..d716409114 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -4250,6 +4250,38 @@
>  { 'command': 'query-machines', 'returns': ['MachineInfo'] }
>  
>  ##
> +# @CPUFeatureSettingEnum:
> +#
> +# Additional valid values for a CPUFeatureSetting property.
> +#
> +# @force: Force feature to be enabled, even if the accelerator
> +# reports the feature as unavailable. Should be used only
> +# for testing or debugging purposes.
> +#
> +# Since: 2.10
> +##
> +{ 'enum': 'CPUFeatureSettingEnum',
> +  'data': ['force'] }
> +
> +##
> +# @CPUFeatureSetting:
> +#
> +# Values for a CPU feature property.
> +#
> +# @bool: If false, the feature is forcibly disabled.
> +#If true, QEMU will try to enable the feature. QEMU will
> +#refuse to start if the feature is unavailable and
> +#'enforce' mode is enabled in the CPU.
> +#
> +# @enum: See @CPUFeatureSettingEnum.
> +#
> +# Since: 2.10
> +##
> +{ 'alternate': 'CPUFeatureSetting',
> +  'data': { 'bool': 'bool',
> +'enum': 'CPUFeatureSettingEnum' } }
> +

Looks reasonable; I'm glad the suggestion for using an alternate worked.


> -if (value) {
> -cpu->env.features[fp->w] |= fp->mask;
> -} else {
> -cpu->env.features[fp->w] &= ~fp->mask;
> +switch (value->type) {
> +case QTYPE_QBOOL:
> +if (value->u.q_bool) {
> +cpu->env.features[fp->w] |= fp->mask;
> +} else {
> +cpu->env.features[fp->w] &= ~fp->mask;
> +}
> +cpu->env.forced_features[fp->w] &= ~fp->mask;
> +cpu->env.user_features[fp->w] |= fp->mask;
> +break;

Isn't the break supposed to be indented four more spaces?

> +case QTYPE_QSTRING:
> +switch (value->u.q_enum) {
> +case CPU_FEATURE_SETTING_ENUM_FORCE:
> +cpu->env.features[fp->w] |= fp->mask;
> +cpu->env.forced_features[fp->w] |= fp->mask;
> +break;

and again

> +default:
> +error_setg(errp, QERR_INVALID_PARAMETER_TYPE, name,
> +   "CPUFeatureSetting");
> +}
> +break;

and again

> +default:
> +error_setg(errp, QERR_INVALID_PARAMETER_TYPE, name,
> +   "CPUFeatureSetting");
>  }
> -cpu->env.user_features[fp->w] |= fp->mask;
> +
> +qapi_free_CPUFeatureSetting(value);
>  }
>  

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



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH 2/4] string-input-visitor: Support alternate types

2017-05-02 Thread Eric Blake
On 05/02/2017 03:31 PM, Eduardo Habkost wrote:
> When parsing alternates from a string, there are some limitations in
> what we can do, but it is a valid use case in some situations. We can
> support booleans, integer types, and enums.
> 
> This will be used to support 'feature=force' in -cpu options, while
> keeping 'feature=on|off|true|false' represented as boolean values.
> 
> Signed-off-by: Eduardo Habkost 
> ---

>  
> +/* Support for alternates on string-input-visitor is limited, because
> + * the input string doesn't have any type information.
> + *
> + * Supported alternate member types:
> + * 1) enums
> + * 2) integer types
> + * 3) booleans (but only if the there's no enum variant
> + *containing "on", "off", "true", or "false" as members)
> + *
> + * UNSUPPORTED alternate member types:
> + * 1) strings
> + * 2) complex types
> + */
> +static void start_alternate(Visitor *v, const char *name,
> +GenericAlternate **obj, size_t size,
> +unsigned long supported_qtypes, Error **errp)
> +{
> +StringInputVisitor *siv = to_siv(v);
> +QType t = QTYPE_QSTRING;

Why do you document string as unsupported, and yet default to
QTYPE_QSTRING?  I don't see how a string is fundamentally different from
an enum (no alternate can have both at the same time, an alternate with
either type will have QTYPE_QSTRING set in supported_qtypes).

> +
> +if (supported_qtypes & BIT(QTYPE_QBOOL)) {
> +if (try_parse_bool(siv->string, NULL) == 0) {
> +t = QTYPE_QBOOL;
> +}
> +}
> +
> +if (supported_qtypes & BIT(QTYPE_QINT)) {
> +if (parse_str(siv, name, NULL) == 0) {
> +t = QTYPE_QINT;
> +}
> +}
> +
> +*obj = g_malloc0(size);
> +(*obj)->type = t;

Should you raise an error if you couldn't match the input with
supported_qtypes, rather than just blindly returning QTYPE_QSTRING?

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



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH 1/4] visitor: Add 'supported_qtypes' parameter to visit_start_alternate()

2017-05-02 Thread Eric Blake
On 05/02/2017 03:31 PM, Eduardo Habkost wrote:
> This will allow visitors to make decisions based on the supported qtypes
> of a given alternate type. The new parameter can replace the old
> 'promote_int' argument, as qobject-input-visitor can simply check if
> QTYPE_QINT is set in supported_qtypes.
> 
> Signed-off-by: Eduardo Habkost 
> ---

> @@ -416,7 +417,7 @@ void visit_end_list(Visitor *v, void **list);
>   */
>  void visit_start_alternate(Visitor *v, const char *name,
> GenericAlternate **obj, size_t size,
> -   bool promote_int, Error **errp);
> +   unsigned long supported_qtypes, Error **errp);

Why unsigned long (which is platform-dependent in size)? At the moment,
even unsigned char happens to be long enough, although I probably would
have used uint32_t.

Oh, I see, it's because you use the BIT() macros from bitops.h, which
are hardcoded to unsigned long.

> +++ b/scripts/qapi-visit.py
> @@ -161,20 +161,21 @@ void visit_type_%(c_name)s(Visitor *v, const char 
> *name, %(c_name)s *obj, Error
>  
>  
>  def gen_visit_alternate(name, variants):
> -promote_int = 'true'
> +qtypes = ['BIT(%s)' % (var.type.alternate_qtype())
> +  for var in variants.variants]
> +supported_qtypes = '|'.join(qtypes)

Do you want ' | '.join(qtypes), so that at least the generated code
still follows recommended operator spacing? (The line is long no matter
what, though, and that's not worth worrying about.)

>  ret = ''
> -for var in variants.variants:
> -if var.type.alternate_qtype() == 'QTYPE_QINT':
> -promote_int = 'false'
>  
>  ret += mcgen('''
>  
>  void visit_type_%(c_name)s(Visitor *v, const char *name, %(c_name)s **obj, 
> Error **errp)
>  {
>  Error *err = NULL;
> +unsigned long supported_qtypes = %(supported_qtypes)s;
>  
> +assert(QTYPE__MAX < BITS_PER_LONG);

Do we really have to generate a separate copy of this assert in every
generated function?  Especially when we know it is true by construction,
that seems like a lot.  Having the assertion once in a .c file rather
than generated in multiple functions might be acceptable, though.

> +++ b/qapi/qobject-input-visitor.c

> @@ -349,7 +351,7 @@ static void qobject_input_start_alternate(Visitor *v, 
> const char *name,
>  }
>  *obj = g_malloc0(size);
>  (*obj)->type = qobject_type(qobj);
> -if (promote_int && (*obj)->type == QTYPE_QINT) {
> +if (!(supported_qtypes & BIT(QTYPE_QINT)) && (*obj)->type == QTYPE_QINT) 
> {

Experimenting, does this read any better:

if (!extract32(supported_qtypes, QTYPE_QINT, 1) && ...

which would be another argument for uint32_t instead of unsigned long in
the signature.

The idea makes sense, but I'm still not necessarily sold on using a long.

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



signature.asc
Description: OpenPGP digital signature


[Qemu-devel] [Bug 1687653] Re: QEMU-KVM / detect_zeroes causes KVM to start unlimited number of threads on Guest-Sided High-IO with big Blocksize

2017-05-02 Thread Florian Strankowski
Just to make this clear: This bug affects only LVM-backed storages.
File-based-storage is not affected. LVM-Thin and also LVM-Thick.

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

Title:
  QEMU-KVM / detect_zeroes causes KVM to start unlimited number of
  threads on Guest-Sided High-IO with big Blocksize

Status in QEMU:
  Confirmed
Status in Ubuntu:
  New

Bug description:
  QEMU-KVM in combination with "detect_zeroes=on" makes a Guest able to
  DoS the Host. This is possible if the Host itself has "detect_zeroes"
  enabled and the Guest writes a large Chunk of data with a huge
  blocksize onto the drive.

  E.g.: dd if=/dev/zero of=/tmp/DoS bs=1G count=1 oflag=direct

  All QEMU-Versions after implementation of detect_zeroes are affected.
  Prior are unaffected. This is absolutely critical, please fix this
  ASAP!

  #

  Provided by Dominik Csapak:

  source, bs   , count ,O_DIRECT, behaviour

  urandom   , bs 1M, count 1024,O_DIRECT: OK
  file  , bs 1M, count 1024,O_DIRECT: OK
  /dev/zero , bs 1M, count 1024,O_DIRECT: OK
  zero file , bs 1M, count 1024,O_DIRECT: OK
  /dev/zero , bs 1G, count1,O_DIRECT: NOT OK
  zero file , bs 1G, count1,O_DIRECT: NOT OK
  zero file , bs 1G, count1, no O_DIRECT: NOT OK
  rand file , bs 1G, count1,O_DIRECT: OK
  rand file , bs 1G, count1, no O_DIRECT: OK

  discard on:

  urandom   , bs 1M, count 1024,O_DIRECT: OK
  rand file , bs 1M, count 1024,O_DIRECT: OK
  /dev/zero , bs 1M, count 1024,O_DIRECT: OK
  zero file , bs 1M, count 1024,O_DIRECT: OK
  /dev/zero , bs 1G, count1,O_DIRECT: NOT OK
  zero file , bs 1G, count1,O_DIRECT: NOT OK
  zero file , bs 1G, count1, no O_DIRECT: NOT OK
  rand file , bs 1G, count1,O_DIRECT: OK
  rand file , bs 1G, count1, no O_DIRECT: OK

  detect_zeros off:

  urandom   , bs 1M, count 1024,O_DIRECT: OK
  rand file , bs 1M, count 1024,O_DIRECT: OK
  /dev/zero , bs 1M, count 1024,O_DIRECT: OK
  zero file , bs 1M, count 1024,O_DIRECT: OK
  /dev/zero , bs 1G, count1,O_DIRECT: OK
  zero file , bs 1G, count1,O_DIRECT: OK
  zero file , bs 1G, count1, no O_DIRECT: OK
  rand file , bs 1G, count1,O_DIRECT: OK
  rand file , bs 1G, count1, no O_DIRECT: OK

  #

  Provided by Florian Strankowski

  bs   -count   -io-threads

  512K -2048-2
  1M   -1024-2
  2M   - 512-4
  4M   - 256-6
  8M   - 128-10
  16M  -  64-18
  32M  -  32-uncountable

  Please refer to further information here:

  https://bugzilla.proxmox.com/show_bug.cgi?id=1368

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



Re: [Qemu-devel] [PATCH 0/4] x86: Support "-cpu feature=force"

2017-05-02 Thread Eduardo Habkost
On Tue, May 02, 2017 at 01:46:22PM -0700, no-re...@patchew.org wrote:
[...]
>   TESTtests/qapi-schema/qapi-schema-test.out
>   TESTtests/qapi-schema/quoted-structural-chars.out
>   TESTtests/qapi-schema/redefined-builtin.out
>   TESTtests/qapi-schema/redefined-command.out
> Files /tmp/qemu-test/src/tests/qapi-schema/qapi-schema-test.out and 
> tests/qapi-schema/qapi-schema-test.test.out differ
> make: *** [check-tests/qapi-schema/qapi-schema-test.json] Error 1
> make: *** Waiting for unfinished jobs

Oh, I didn't know we had a qapi-schema-test.out file that had to
be manually kept in sync. I will fix this in v2.

> tests/docker/Makefile.include:118: recipe for target 'docker-run' failed
> make[1]: *** [docker-run] Error 2
> make[1]: Leaving directory '/var/tmp/patchew-tester-tmp-mqqq0zgw/src'
> tests/docker/Makefile.include:149: recipe for target 
> 'docker-run-test-quick@centos6' failed
> make: *** [docker-run-test-quick@centos6] Error 2
> === OUTPUT END ===
> 
> Test command exited with code: 2
> 
> 
> ---
> Email generated automatically by Patchew [http://patchew.org/].
> Please send your feedback to patchew-de...@freelists.org

-- 
Eduardo



Re: [Qemu-devel] [PATCH 0/4] x86: Support "-cpu feature=force"

2017-05-02 Thread no-reply
Hi,

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

Type: series
Subject: [Qemu-devel] [PATCH 0/4] x86: Support "-cpu feature=force"
Message-id: 20170502203115.22233-1-ehabk...@redhat.com

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

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

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

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

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
8ffc6d4 x86: Support feature=force on the command-line
9418a88 tests: Add [+-]feature and feature=on|off test cases
f6954a1 string-input-visitor: Support alternate types
ea7dc8d visitor: Add 'supported_qtypes' parameter to visit_start_alternate()

=== OUTPUT BEGIN ===
Checking PATCH 1/4: visitor: Add 'supported_qtypes' parameter to 
visit_start_alternate()...
Checking PATCH 2/4: string-input-visitor: Support alternate types...
Checking PATCH 3/4: tests: Add [+-]feature and feature=on|off test cases...
ERROR: line over 90 characters
#59: FILE: tests/test-x86-cpuid-compat.c:104:
+static uint32_t get_feature_word(QList *features, uint32_t eax, uint32_t ecx, 
const char *reg)

WARNING: line over 80 characters
#65: FILE: tests/test-x86-cpuid-compat.c:110:
+if (eax == qint_get_int(qobject_to_qint(qdict_get(w, 
"cpuid-input-eax")))

WARNING: line over 80 characters
#67: FILE: tests/test-x86-cpuid-compat.c:112:
+|| ecx == qint_get_int(qobject_to_qint(qdict_get(w, 
"cpuid-input-ecx"

ERROR: line over 90 characters
#68: FILE: tests/test-x86-cpuid-compat.c:113:
+&& !strcmp(qstring_get_str(qobject_to_qstring(qdict_get(w, 
"cpuid-register"))), reg)) {

WARNING: line over 80 characters
#86: FILE: tests/test-x86-cpuid-compat.c:131:
+value = get_feature_word(present, args->input_eax, args->input_ecx, 
args->reg);

WARNING: line over 80 characters
#87: FILE: tests/test-x86-cpuid-compat.c:132:
+value |= get_feature_word(filtered, args->input_eax, args->input_ecx, 
args->reg);

total: 2 errors, 4 warnings, 130 lines checked

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

Checking PATCH 4/4: x86: Support feature=force on the command-line...
WARNING: line over 80 characters
#186: FILE: tests/test-x86-cpuid-compat.c:135:
+value |= get_feature_word(filtered, args->input_eax, args->input_ecx, 
args->reg);

total: 0 errors, 1 warnings, 168 lines checked

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

Test command exited with code: 1


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

Re: [Qemu-devel] [PATCH 0/4] x86: Support "-cpu feature=force"

2017-05-02 Thread no-reply
Hi,

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

Type: series
Subject: [Qemu-devel] [PATCH 0/4] x86: Support "-cpu feature=force"
Message-id: 20170502203115.22233-1-ehabk...@redhat.com

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] patchew/20170502203115.22233-1-ehabk...@redhat.com -> 
patchew/20170502203115.22233-1-ehabk...@redhat.com
Switched to a new branch 'test'
8ffc6d4 x86: Support feature=force on the command-line
9418a88 tests: Add [+-]feature and feature=on|off test cases
f6954a1 string-input-visitor: Support alternate types
ea7dc8d visitor: Add 'supported_qtypes' parameter to visit_start_alternate()

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

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

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

[Qemu-devel] [PATCH] fixup! tests: Add [+-]feature and feature=on|off test cases

2017-05-02 Thread Eduardo Habkost
On Tue, May 02, 2017 at 05:31:15PM -0300, Eduardo Habkost wrote:
> Introduce a new CPUFeatureSetting QAPI data type, and use it to support
> feature=force on -cpu.
> 
> Signed-off-by: Eduardo Habkost 

I will include this in v2 to fix the coding style issues.

Signed-off-by: Eduardo Habkost 
---
 tests/test-x86-cpuid-compat.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/tests/test-x86-cpuid-compat.c b/tests/test-x86-cpuid-compat.c
index 9940f4de1c..02f56ad0e8 100644
--- a/tests/test-x86-cpuid-compat.c
+++ b/tests/test-x86-cpuid-compat.c
@@ -103,16 +103,24 @@ typedef struct FeatureTestArgs {
 } FeatureTestArgs;
 
 /* Get the value for a feature word in a X86CPUFeatureWordInfo list */
-static uint32_t get_feature_word(QList *features, uint32_t eax, uint32_t ecx, 
const char *reg)
+static uint32_t get_feature_word(QList *features, uint32_t eax, uint32_t ecx,
+ const char *reg)
 {
 const QListEntry *e;
 
 for (e = qlist_first(features); e; e = qlist_next(e)) {
 QDict *w = qobject_to_qdict(qlist_entry_obj(e));
-if (eax == qint_get_int(qobject_to_qint(qdict_get(w, 
"cpuid-input-eax")))
-&& (!qdict_haskey(w, "cpuid-input-ecx")
-|| ecx == qint_get_int(qobject_to_qint(qdict_get(w, 
"cpuid-input-ecx"
-&& !strcmp(qstring_get_str(qobject_to_qstring(qdict_get(w, 
"cpuid-register"))), reg)) {
+const char *rreg =
+qstring_get_str(qobject_to_qstring(qdict_get(w, 
"cpuid-register")));
+uint32_t reax =
+qint_get_int(qobject_to_qint(qdict_get(w, "cpuid-input-eax")));
+bool has_ecx = qdict_haskey(w, "cpuid-input-ecx");
+uint32_t recx = 0;
+
+if (has_ecx) {
+recx = qint_get_int(qobject_to_qint(qdict_get(w, 
"cpuid-input-ecx")));
+}
+if (eax == reax && (!has_ecx || ecx == recx) && !strcmp(rreg, reg)) {
 return qint_get_int(qobject_to_qint(qdict_get(w, "features")));
 }
 }
-- 
2.11.0.259.g40922b1

-- 
Eduardo



[Qemu-devel] [PATCH 3/4] tests: Add [+-]feature and feature=on|off test cases

2017-05-02 Thread Eduardo Habkost
Add test code to ensure features are enabled/disabled correctly in the
command-line. The test case use the "feature-words" and
"filtered-features" properties to check if the features were
enabled/disabled correctly.

Signed-off-by: Eduardo Habkost 
---
 tests/test-x86-cpuid-compat.c | 107 ++
 1 file changed, 107 insertions(+)

diff --git a/tests/test-x86-cpuid-compat.c b/tests/test-x86-cpuid-compat.c
index 79a2e69a28..00ee8a264f 100644
--- a/tests/test-x86-cpuid-compat.c
+++ b/tests/test-x86-cpuid-compat.c
@@ -1,6 +1,7 @@
 #include "qemu/osdep.h"
 #include "qemu-common.h"
 #include "qapi/qmp/qlist.h"
+#include "qapi/qmp/qstring.h"
 #include "qapi/qmp/qdict.h"
 #include "qapi/qmp/qint.h"
 #include "qapi/qmp/qbool.h"
@@ -68,6 +69,9 @@ static void test_cpuid_prop(const void *data)
 g_free(path);
 }
 
+/* Add simple test that ensure that a given (integer) property has
+ * the right value after running QEMU using cmdline
+ */
 static void add_cpuid_test(const char *name, const char *cmdline,
const char *property, int64_t expected_value)
 {
@@ -78,6 +82,83 @@ static void add_cpuid_test(const char *name, const char 
*cmdline,
 qtest_add_data_func(name, args, test_cpuid_prop);
 }
 
+
+/* Parameters to a add_feature_test() test case */
+typedef struct FeatureTestArgs {
+/* cmdline to start QEMU */
+const char *cmdline;
+/*
+ * cpuid-input-eax and cpuid-input-ecx values to look for,
+ * in "feature-words" and "filtered-features" properties.
+ */
+uint32_t input_eax, input_ecx;
+/* The register name to look for, in the X86CPUFeatureWordInfo array */
+const char *reg;
+/* The bit to check in X86CPUFeatureWordInfo.features */
+int bitnr;
+/* The expected value for the bit in (X86CPUFeatureWordInfo.features) */
+bool expected_value;
+} FeatureTestArgs;
+
+/* Get the value for a feature word in a X86CPUFeatureWordInfo list */
+static uint32_t get_feature_word(QList *features, uint32_t eax, uint32_t ecx, 
const char *reg)
+{
+const QListEntry *e;
+
+for (e = qlist_first(features); e; e = qlist_next(e)) {
+QDict *w = qobject_to_qdict(qlist_entry_obj(e));
+if (eax == qint_get_int(qobject_to_qint(qdict_get(w, 
"cpuid-input-eax")))
+&& (!qdict_haskey(w, "cpuid-input-ecx")
+|| ecx == qint_get_int(qobject_to_qint(qdict_get(w, 
"cpuid-input-ecx"
+&& !strcmp(qstring_get_str(qobject_to_qstring(qdict_get(w, 
"cpuid-register"))), reg)) {
+return qint_get_int(qobject_to_qint(qdict_get(w, "features")));
+}
+}
+return 0;
+}
+
+static void test_feature_flag(const void *data)
+{
+const FeatureTestArgs *args = data;
+char *path;
+QList *present, *filtered;
+uint32_t value;
+
+qtest_start(args->cmdline);
+path = get_cpu0_qom_path();
+present = qobject_to_qlist(qom_get(path, "feature-words"));
+filtered = qobject_to_qlist(qom_get(path, "filtered-features"));
+value = get_feature_word(present, args->input_eax, args->input_ecx, 
args->reg);
+value |= get_feature_word(filtered, args->input_eax, args->input_ecx, 
args->reg);
+qtest_end();
+
+g_assert(!!(value & (1U << args->bitnr)) == args->expected_value);
+
+QDECREF(present);
+QDECREF(filtered);
+g_free(path);
+}
+
+/* Add test case to ensure that a given feature flag is set in
+  * either "feature-words" or "filtered-features", when running QEMU
+  * using cmdline
+  */
+static FeatureTestArgs *add_feature_test(const char *name, const char *cmdline,
+ uint32_t eax, uint32_t ecx,
+ const char *reg, int bitnr,
+ bool expected_value)
+{
+FeatureTestArgs *args = g_new0(FeatureTestArgs, 1);
+args->cmdline = cmdline;
+args->input_eax = eax;
+args->input_ecx = ecx;
+args->reg = reg;
+args->bitnr = bitnr;
+args->expected_value = expected_value;
+qtest_add_data_func(name, args, test_feature_flag);
+return args;
+}
+
 #ifdef CONFIG_HAS_GLIB_SUBPROCESS_TESTS
 static void test_plus_minus_subprocess(void)
 {
@@ -229,5 +310,31 @@ int main(int argc, char **argv)
"-machine pc-i440fx-2.7 -cpu 486,+xstore",
"xlevel2", 0);
 
+/* Test feature parsing */
+add_feature_test("x86/cpuid/features/plus",
+ "-cpu 486,+arat",
+ 6, 0, "EAX", 2, true);
+add_feature_test("x86/cpuid/features/minus",
+ "-cpu pentium,-mmx",
+ 1, 0, "EDX", 23, false);
+add_feature_test("x86/cpuid/features/on",
+ "-cpu 486,arat=on",
+ 6, 0, "EAX", 2, true);
+add_feature_test("x86/cpuid/features/off",
+ "-cpu pentium,mmx=off",
+ 1, 0, "EDX", 23, false);
+

[Qemu-devel] [PATCH 1/4] visitor: Add 'supported_qtypes' parameter to visit_start_alternate()

2017-05-02 Thread Eduardo Habkost
This will allow visitors to make decisions based on the supported qtypes
of a given alternate type. The new parameter can replace the old
'promote_int' argument, as qobject-input-visitor can simply check if
QTYPE_QINT is set in supported_qtypes.

Signed-off-by: Eduardo Habkost 
---
 include/qapi/visitor.h   |  5 +++--
 include/qapi/visitor-impl.h  |  2 +-
 scripts/qapi-visit.py| 14 --
 qapi/qapi-visit-core.c   |  7 ---
 qapi/qapi-clone-visitor.c|  3 ++-
 qapi/qapi-dealloc-visitor.c  |  3 ++-
 qapi/qobject-input-visitor.c |  6 --
 qapi/trace-events|  2 +-
 8 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/include/qapi/visitor.h b/include/qapi/visitor.h
index 1a1b62012b..8c2bff4a05 100644
--- a/include/qapi/visitor.h
+++ b/include/qapi/visitor.h
@@ -408,7 +408,8 @@ void visit_end_list(Visitor *v, void **list);
  * the qtype of the next thing to be visited, stored in (*@obj)->type.
  * Other visitors will leave @obj unchanged.
  *
- * If @promote_int, treat integers as QTYPE_FLOAT.
+ * @supported_qtypes is a bit mask indicating which QTypes are supported
+ * by the alternate.
  *
  * If successful, this must be paired with visit_end_alternate() with
  * the same @obj to clean up, even if visiting the contents of the
@@ -416,7 +417,7 @@ void visit_end_list(Visitor *v, void **list);
  */
 void visit_start_alternate(Visitor *v, const char *name,
GenericAlternate **obj, size_t size,
-   bool promote_int, Error **errp);
+   unsigned long supported_qtypes, Error **errp);
 
 /*
  * Finish visiting an alternate type.
diff --git a/include/qapi/visitor-impl.h b/include/qapi/visitor-impl.h
index e87709db5c..50c2b2feef 100644
--- a/include/qapi/visitor-impl.h
+++ b/include/qapi/visitor-impl.h
@@ -71,7 +71,7 @@ struct Visitor
  * optional for output visitors. */
 void (*start_alternate)(Visitor *v, const char *name,
 GenericAlternate **obj, size_t size,
-bool promote_int, Error **errp);
+unsigned long supported_qtypes, Error **errp);
 
 /* Optional, needed for dealloc visitor */
 void (*end_alternate)(Visitor *v, void **obj);
diff --git a/scripts/qapi-visit.py b/scripts/qapi-visit.py
index 5737aefa05..ebf7e67109 100644
--- a/scripts/qapi-visit.py
+++ b/scripts/qapi-visit.py
@@ -161,20 +161,21 @@ void visit_type_%(c_name)s(Visitor *v, const char *name, 
%(c_name)s *obj, Error
 
 
 def gen_visit_alternate(name, variants):
-promote_int = 'true'
+qtypes = ['BIT(%s)' % (var.type.alternate_qtype())
+  for var in variants.variants]
+supported_qtypes = '|'.join(qtypes)
 ret = ''
-for var in variants.variants:
-if var.type.alternate_qtype() == 'QTYPE_QINT':
-promote_int = 'false'
 
 ret += mcgen('''
 
 void visit_type_%(c_name)s(Visitor *v, const char *name, %(c_name)s **obj, 
Error **errp)
 {
 Error *err = NULL;
+unsigned long supported_qtypes = %(supported_qtypes)s;
 
+assert(QTYPE__MAX < BITS_PER_LONG);
 visit_start_alternate(v, name, (GenericAlternate **)obj, sizeof(**obj),
-  %(promote_int)s, );
+  supported_qtypes, );
 if (err) {
 goto out;
 }
@@ -183,7 +184,7 @@ void visit_type_%(c_name)s(Visitor *v, const char *name, 
%(c_name)s **obj, Error
 }
 switch ((*obj)->type) {
 ''',
- c_name=c_name(name), promote_int=promote_int)
+ c_name=c_name(name), supported_qtypes=supported_qtypes)
 
 for var in variants.variants:
 ret += mcgen('''
@@ -375,6 +376,7 @@ h_comment = '''
 
 fdef.write(mcgen('''
 #include "qemu/osdep.h"
+#include "qemu/bitmap.h"
 #include "qemu-common.h"
 #include "qapi/error.h"
 #include "%(prefix)sqapi-visit.h"
diff --git a/qapi/qapi-visit-core.c b/qapi/qapi-visit-core.c
index 43a09d147d..784ba1b756 100644
--- a/qapi/qapi-visit-core.c
+++ b/qapi/qapi-visit-core.c
@@ -106,15 +106,16 @@ void visit_end_list(Visitor *v, void **obj)
 
 void visit_start_alternate(Visitor *v, const char *name,
GenericAlternate **obj, size_t size,
-   bool promote_int, Error **errp)
+   unsigned long supported_qtypes,
+   Error **errp)
 {
 Error *err = NULL;
 
 assert(obj && size >= sizeof(GenericAlternate));
 assert(!(v->type & VISITOR_OUTPUT) || *obj);
-trace_visit_start_alternate(v, name, obj, size, promote_int);
+trace_visit_start_alternate(v, name, obj, size, supported_qtypes);
 if (v->start_alternate) {
-v->start_alternate(v, name, obj, size, promote_int, );
+v->start_alternate(v, name, obj, size, supported_qtypes, );
 }
 if (v->type & VISITOR_INPUT) {
 assert(v->start_alternate && !err != !*obj);
diff --git 

[Qemu-devel] [PATCH 2/4] string-input-visitor: Support alternate types

2017-05-02 Thread Eduardo Habkost
When parsing alternates from a string, there are some limitations in
what we can do, but it is a valid use case in some situations. We can
support booleans, integer types, and enums.

This will be used to support 'feature=force' in -cpu options, while
keeping 'feature=on|off|true|false' represented as boolean values.

Signed-off-by: Eduardo Habkost 
---
 qapi/string-input-visitor.c | 71 ++
 tests/test-string-input-visitor.c   | 89 +
 tests/qapi-schema/qapi-schema-test.json |  8 +++
 3 files changed, 158 insertions(+), 10 deletions(-)

diff --git a/qapi/string-input-visitor.c b/qapi/string-input-visitor.c
index c089491c24..bf8f58748b 100644
--- a/qapi/string-input-visitor.c
+++ b/qapi/string-input-visitor.c
@@ -19,6 +19,7 @@
 #include "qemu/option.h"
 #include "qemu/queue.h"
 #include "qemu/range.h"
+#include "qemu/bitops.h"
 
 
 struct StringInputVisitor
@@ -278,21 +279,34 @@ static void parse_type_size(Visitor *v, const char *name, 
uint64_t *obj,
 *obj = val;
 }
 
+static int try_parse_bool(const char *s, bool *result)
+{
+if (!strcasecmp(s, "on") ||
+!strcasecmp(s, "yes") ||
+!strcasecmp(s, "true")) {
+if (result) {
+*result = true;
+}
+return 0;
+}
+if (!strcasecmp(s, "off") ||
+!strcasecmp(s, "no") ||
+!strcasecmp(s, "false")) {
+if (result) {
+*result = false;
+}
+return 0;
+}
+
+return -1;
+}
+
 static void parse_type_bool(Visitor *v, const char *name, bool *obj,
 Error **errp)
 {
 StringInputVisitor *siv = to_siv(v);
 
-if (!strcasecmp(siv->string, "on") ||
-!strcasecmp(siv->string, "yes") ||
-!strcasecmp(siv->string, "true")) {
-*obj = true;
-return;
-}
-if (!strcasecmp(siv->string, "off") ||
-!strcasecmp(siv->string, "no") ||
-!strcasecmp(siv->string, "false")) {
-*obj = false;
+if (try_parse_bool(siv->string, obj) == 0) {
 return;
 }
 
@@ -326,6 +340,42 @@ static void parse_type_number(Visitor *v, const char 
*name, double *obj,
 *obj = val;
 }
 
+/* Support for alternates on string-input-visitor is limited, because
+ * the input string doesn't have any type information.
+ *
+ * Supported alternate member types:
+ * 1) enums
+ * 2) integer types
+ * 3) booleans (but only if the there's no enum variant
+ *containing "on", "off", "true", or "false" as members)
+ *
+ * UNSUPPORTED alternate member types:
+ * 1) strings
+ * 2) complex types
+ */
+static void start_alternate(Visitor *v, const char *name,
+GenericAlternate **obj, size_t size,
+unsigned long supported_qtypes, Error **errp)
+{
+StringInputVisitor *siv = to_siv(v);
+QType t = QTYPE_QSTRING;
+
+if (supported_qtypes & BIT(QTYPE_QBOOL)) {
+if (try_parse_bool(siv->string, NULL) == 0) {
+t = QTYPE_QBOOL;
+}
+}
+
+if (supported_qtypes & BIT(QTYPE_QINT)) {
+if (parse_str(siv, name, NULL) == 0) {
+t = QTYPE_QINT;
+}
+}
+
+*obj = g_malloc0(size);
+(*obj)->type = t;
+}
+
 static void string_input_free(Visitor *v)
 {
 StringInputVisitor *siv = to_siv(v);
@@ -353,6 +403,7 @@ Visitor *string_input_visitor_new(const char *str)
 v->visitor.next_list = next_list;
 v->visitor.check_list = check_list;
 v->visitor.end_list = end_list;
+v->visitor.start_alternate = start_alternate;
 v->visitor.free = string_input_free;
 
 v->string = str;
diff --git a/tests/test-string-input-visitor.c 
b/tests/test-string-input-visitor.c
index 79313a7f7a..1e867d62c9 100644
--- a/tests/test-string-input-visitor.c
+++ b/tests/test-string-input-visitor.c
@@ -290,6 +290,91 @@ static void test_visitor_in_enum(TestInputVisitorData 
*data,
 }
 }
 
+static void test_visitor_in_alt_bool_enum(TestInputVisitorData *data,
+ const void *unused)
+{
+Error *err = NULL;
+Visitor *v;
+AltBoolEnum *be = NULL;
+
+v = visitor_input_test_init(data, "true");
+visit_type_AltBoolEnum(v, NULL, , );
+g_assert(!err);
+g_assert_cmpint(be->type, ==, QTYPE_QBOOL);
+g_assert(be->u.b);
+qapi_free_AltBoolEnum(be);
+
+v = visitor_input_test_init(data, "off");
+visit_type_AltBoolEnum(v, NULL, , );
+g_assert(!err);
+g_assert_cmpint(be->type, ==, QTYPE_QBOOL);
+g_assert(!be->u.b);
+qapi_free_AltBoolEnum(be);
+
+v = visitor_input_test_init(data, "value2");
+visit_type_AltBoolEnum(v, NULL, , );
+g_assert(!err);
+g_assert_cmpint(be->type, ==, QTYPE_QSTRING);
+g_assert_cmpint(be->u.e, ==, ENUM_ONE_VALUE2);
+qapi_free_AltBoolEnum(be);
+
+v = visitor_input_test_init(data, "value100");
+visit_type_AltBoolEnum(v, NULL, , );
+error_free_or_abort();
+qapi_free_AltBoolEnum(be);
+

[Qemu-devel] [PATCH 4/4] x86: Support feature=force on the command-line

2017-05-02 Thread Eduardo Habkost
Introduce a new CPUFeatureSetting QAPI data type, and use it to support
feature=force on -cpu.

Signed-off-by: Eduardo Habkost 
---
 qapi-schema.json  | 32 +
 target/i386/cpu.h |  2 ++
 target/i386/cpu.c | 55 +--
 tests/test-x86-cpuid-compat.c | 14 ++-
 4 files changed, 90 insertions(+), 13 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index 01b087fa16..d716409114 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -4250,6 +4250,38 @@
 { 'command': 'query-machines', 'returns': ['MachineInfo'] }
 
 ##
+# @CPUFeatureSettingEnum:
+#
+# Additional valid values for a CPUFeatureSetting property.
+#
+# @force: Force feature to be enabled, even if the accelerator
+# reports the feature as unavailable. Should be used only
+# for testing or debugging purposes.
+#
+# Since: 2.10
+##
+{ 'enum': 'CPUFeatureSettingEnum',
+  'data': ['force'] }
+
+##
+# @CPUFeatureSetting:
+#
+# Values for a CPU feature property.
+#
+# @bool: If false, the feature is forcibly disabled.
+#If true, QEMU will try to enable the feature. QEMU will
+#refuse to start if the feature is unavailable and
+#'enforce' mode is enabled in the CPU.
+#
+# @enum: See @CPUFeatureSettingEnum.
+#
+# Since: 2.10
+##
+{ 'alternate': 'CPUFeatureSetting',
+  'data': { 'bool': 'bool',
+'enum': 'CPUFeatureSettingEnum' } }
+
+##
 # @CpuDefinitionInfo:
 #
 # Virtual CPU definition.
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index c4602ca80d..7a34998e0a 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1149,6 +1149,8 @@ typedef struct CPUX86State {
 FeatureWordArray features;
 /* Features that were explicitly enabled/disabled */
 FeatureWordArray user_features;
+/* Features set to 'force' */
+FeatureWordArray forced_features;
 uint32_t cpuid_model[12];
 
 /* MTRRs */
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 13c0985f11..6c24b92cee 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -3463,7 +3463,7 @@ static int x86_cpu_filter_features(X86CPU *cpu)
 uint32_t host_feat =
 x86_cpu_get_supported_feature_word(w, false);
 uint32_t requested_features = env->features[w];
-env->features[w] &= host_feat;
+env->features[w] &= host_feat | env->forced_features[w];
 cpu->filtered_features[w] = requested_features & ~env->features[w];
 if (cpu->filtered_features[w]) {
 rv = 1;
@@ -3705,9 +3705,19 @@ static void x86_cpu_get_bit_prop(Object *obj, Visitor 
*v, const char *name,
 {
 X86CPU *cpu = X86_CPU(obj);
 BitProperty *fp = opaque;
-uint32_t f = cpu->env.features[fp->w];
-bool value = (f & fp->mask) == fp->mask;
-visit_type_bool(v, name, , errp);
+bool bvalue = (cpu->env.features[fp->w] & fp->mask) == fp->mask;
+bool forced = (cpu->env.forced_features[fp->w] & fp->mask) == fp->mask;
+CPUFeatureSetting *value = g_new0(CPUFeatureSetting, 1);
+
+if (!forced) {
+value->type = QTYPE_QBOOL;
+value->u.q_bool = bvalue;
+} else {
+value->type = QTYPE_QSTRING;
+value->u.q_enum = CPU_FEATURE_SETTING_ENUM_FORCE;
+}
+visit_type_CPUFeatureSetting(v, name, , errp);
+qapi_free_CPUFeatureSetting(value);
 }
 
 static void x86_cpu_set_bit_prop(Object *obj, Visitor *v, const char *name,
@@ -3717,25 +3727,46 @@ static void x86_cpu_set_bit_prop(Object *obj, Visitor 
*v, const char *name,
 X86CPU *cpu = X86_CPU(obj);
 BitProperty *fp = opaque;
 Error *local_err = NULL;
-bool value;
+CPUFeatureSetting *value = NULL;
 
 if (dev->realized) {
 qdev_prop_set_after_realize(dev, name, errp);
 return;
 }
 
-visit_type_bool(v, name, , _err);
+visit_type_CPUFeatureSetting(v, name, , _err);
 if (local_err) {
 error_propagate(errp, local_err);
 return;
 }
 
-if (value) {
-cpu->env.features[fp->w] |= fp->mask;
-} else {
-cpu->env.features[fp->w] &= ~fp->mask;
+switch (value->type) {
+case QTYPE_QBOOL:
+if (value->u.q_bool) {
+cpu->env.features[fp->w] |= fp->mask;
+} else {
+cpu->env.features[fp->w] &= ~fp->mask;
+}
+cpu->env.forced_features[fp->w] &= ~fp->mask;
+cpu->env.user_features[fp->w] |= fp->mask;
+break;
+case QTYPE_QSTRING:
+switch (value->u.q_enum) {
+case CPU_FEATURE_SETTING_ENUM_FORCE:
+cpu->env.features[fp->w] |= fp->mask;
+cpu->env.forced_features[fp->w] |= fp->mask;
+break;
+default:
+error_setg(errp, QERR_INVALID_PARAMETER_TYPE, name,
+   "CPUFeatureSetting");
+}
+break;
+default:
+error_setg(errp, QERR_INVALID_PARAMETER_TYPE, name,
+   "CPUFeatureSetting");
 }
-

[Qemu-devel] [PATCH 0/4] x86: Support "-cpu feature=force"

2017-05-02 Thread Eduardo Habkost
This series implements "-cpu feature=force", to allow a feature
to be forcefully enabled even if the underlying accelerator
report it as unsupported. This feature should be used only for
testing and debugging.

We use a new QAPI alternate type to keep command-line
compatibility, and to keep compatibility with code that reads the
existing feature QOM properties and expects boolean values.

Eduardo Habkost (4):
  visitor: Add 'supported_qtypes' parameter to visit_start_alternate()
  string-input-visitor: Support alternate types
  tests: Add [+-]feature and feature=on|off test cases
  x86: Support feature=force on the command-line

 qapi-schema.json|  32 +
 include/qapi/visitor.h  |   5 +-
 include/qapi/visitor-impl.h |   2 +-
 scripts/qapi-visit.py   |  14 ++--
 target/i386/cpu.h   |   2 +
 qapi/qapi-visit-core.c  |   7 +-
 qapi/qapi-clone-visitor.c   |   3 +-
 qapi/qapi-dealloc-visitor.c |   3 +-
 qapi/qobject-input-visitor.c|   6 +-
 qapi/string-input-visitor.c |  71 ---
 target/i386/cpu.c   |  55 +++
 tests/test-string-input-visitor.c   |  89 
 tests/test-x86-cpuid-compat.c   | 119 
 qapi/trace-events   |   2 +-
 tests/qapi-schema/qapi-schema-test.json |   8 +++
 15 files changed, 379 insertions(+), 39 deletions(-)

-- 
2.11.0.259.g40922b1




Re: [Qemu-devel] [PATCH v6 00/25] tcg cross-tb optimizations

2017-05-02 Thread no-reply
Hi,

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

Type: series
Subject: [Qemu-devel] [PATCH v6 00/25] tcg cross-tb optimizations
Message-id: 20170502192300.2124-1-...@twiddle.net

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

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

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

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

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 - [tag update]  
patchew/149373610338.5144.9635049015143453288.st...@bahia.lan -> 
patchew/149373610338.5144.9635049015143453288.st...@bahia.lan
Switched to a new branch 'test'
7aa8166 target/mips: optimize indirect branches
13b0c04 target/mips: optimize cross-page direct jumps in softmmu
c56c077 tcg/mips: implement goto_ptr
80167d9 target/aarch64: optimize indirect branches
0cbe645 target/aarch64: optimize cross-page direct jumps in softmmu
3854c1f target/alpha: Use tcg_gen_lookup_and_goto_ptr
29b76c6 target/hppa: Use tcg_gen_lookup_and_goto_ptr
f904940 target/s390: Use tcg_gen_lookup_and_goto_ptr
4312937 tcg/arm: Implement goto_ptr
20d8e07 tcg/arm: Clarify tcg_out_bx for arm4 host
fcae688 tcg/s390: Implement goto_ptr
feff310 tcg/sparc: Implement goto_ptr
e11e15b tcg/aarch64: Implement goto_ptr
aba9561 tcg/ppc: Implement goto_ptr
3d86def tb-hash: improve tb_jmp_cache hash function in user mode
85c8bca target/i386: optimize indirect branches
56cde2c target/i386: optimize cross-page direct jumps in softmmu
642d3a1 target/i386: introduce gen_jr helper to generate lookup_and_goto_ptr
66cbfb4 target/arm: optimize indirect branches
ac54831 target/arm: optimize cross-page direct jumps in softmmu
4eda0de tcg/i386: implement goto_ptr
d977fcc tcg: Introduce goto_ptr opcode and tcg_gen_lookup_and_goto_ptr
da662a3 qemu/atomic: Loosen restrictions for 64-bit ILP32 hosts
4401168 tcg/sparc: Use the proper compilation flags for 32-bit
7c59ccb target/nios2: Fix 64-bit ilp32 compilation

=== OUTPUT BEGIN ===
Checking PATCH 1/25: target/nios2: Fix 64-bit ilp32 compilation...
Checking PATCH 2/25: tcg/sparc: Use the proper compilation flags for 32-bit...
Checking PATCH 3/25: qemu/atomic: Loosen restrictions for 64-bit ILP32 hosts...
WARNING: architecture specific defines should be avoided
#37: FILE: include/qemu/atomic.h:104:
+#if defined(__x86_64__) || defined(__sparc__)

total: 0 errors, 1 warnings, 87 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Checking PATCH 4/25: tcg: Introduce goto_ptr opcode and 
tcg_gen_lookup_and_goto_ptr...
Checking PATCH 5/25: tcg/i386: implement goto_ptr...
Checking PATCH 6/25: target/arm: optimize cross-page direct jumps in softmmu...
Checking PATCH 7/25: target/arm: optimize indirect branches...
Checking PATCH 8/25: target/i386: introduce gen_jr helper to generate 
lookup_and_goto_ptr...
Checking PATCH 9/25: target/i386: optimize cross-page direct jumps in softmmu...
Checking PATCH 10/25: target/i386: optimize indirect branches...
Checking PATCH 11/25: tb-hash: improve tb_jmp_cache hash function in user 
mode...
Checking PATCH 12/25: tcg/ppc: Implement goto_ptr...
Checking PATCH 13/25: tcg/aarch64: Implement goto_ptr...
Checking PATCH 14/25: tcg/sparc: Implement goto_ptr...
Checking PATCH 15/25: tcg/s390: Implement goto_ptr...
Checking PATCH 16/25: tcg/arm: Clarify tcg_out_bx for arm4 host...
Checking PATCH 17/25: tcg/arm: Implement goto_ptr...
Checking PATCH 18/25: target/s390: Use tcg_gen_lookup_and_goto_ptr...
ERROR: return is not a function, parentheses are not required
#23: FILE: target/s390x/translate.c:613:
+return (s->singlestep_enabled ||

total: 1 errors, 0 warnings, 31 lines checked

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

Checking PATCH 19/25: target/hppa: Use tcg_gen_lookup_and_goto_ptr...
Checking PATCH 20/25: target/alpha: Use tcg_gen_lookup_and_goto_ptr...
ERROR: return is not a function, parentheses are not required
#29: FILE: target/alpha/translate.c:463:
+return ((ctx->tb->cflags & CF_LAST_IO)

total: 1 errors, 0 warnings, 100 lines checked

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

Checking PATCH 21/25: target/aarch64: optimize cross-page direct jumps in 
softmmu...
Checking PATCH 22/25: target/aarch64: optimize indirect branches...
Checking PATCH 23/25: tcg/mips: implement goto_ptr...

Re: [Qemu-devel] [PATCH v4 1/1] numa: equally distribute memory on nodes

2017-05-02 Thread Eduardo Habkost
On Tue, May 02, 2017 at 06:29:55PM +0200, Laurent Vivier wrote:
[...]
> diff --git a/numa.c b/numa.c
> index 6fc2393..750fd95 100644
> --- a/numa.c
> +++ b/numa.c
> @@ -294,6 +294,42 @@ static void validate_numa_cpus(void)
>  g_free(seen_cpus);
>  }
>  
> +void numa_legacy_auto_assign_ram(MachineClass *mc, NodeInfo *nodes,
> + int nb_nodes, ram_addr_t size)
> +{
> +int i;
> +uint64_t usedmem = 0;
> +
> +/* Align each node according to the alignment
> + * requirements of the machine class
> + */
> +
> +for (i = 0; i < nb_nodes - 1; i++) {
> +nodes[i].node_mem = (size / nb_nodes) &
> +~((1 << mc->numa_mem_align_shift) - 1);
> +usedmem += nodes[i].node_mem;
> +}
> +nodes[i].node_mem = size - usedmem;
> +}
> +
> +void numa_default_auto_assign_ram(MachineClass *mc, NodeInfo *nodes,
> +  int nb_nodes, ram_addr_t size)
> +{
> +int i;
> +uint64_t usedmem = 0, node_mem;
> +uint64_t granularity = size / nb_nodes;
> +uint64_t propagate = 0;
> +
> +for (i = 0; i < nb_nodes - 1; i++) {
> +node_mem = (granularity + propagate) &
> +   ~((1 << mc->numa_mem_align_shift) - 1);
> +propagate = granularity + propagate - node_mem;
> +nodes[i].node_mem = node_mem;
> +usedmem += node_mem;
> +}
> +nodes[i].node_mem = ram_size - usedmem;

I believe you meant 'size - usedmem' here.

I can fix this while applying the patch, if that's OK. The rest
of the patch looks good to me.

> +}
> +
>  void parse_numa_opts(MachineClass *mc)
>  {
>  int i;
> @@ -336,17 +372,8 @@ void parse_numa_opts(MachineClass *mc)
>  }
>  }
>  if (i == nb_numa_nodes) {
> -uint64_t usedmem = 0;
> -
> -/* Align each node according to the alignment
> - * requirements of the machine class
> - */
> -for (i = 0; i < nb_numa_nodes - 1; i++) {
> -numa_info[i].node_mem = (ram_size / nb_numa_nodes) &
> -~((1 << mc->numa_mem_align_shift) - 
> 1);
> -usedmem += numa_info[i].node_mem;
> -}
> -numa_info[i].node_mem = ram_size - usedmem;
> +assert(mc->numa_auto_assign_ram);
> +mc->numa_auto_assign_ram(mc, numa_info, nb_numa_nodes, ram_size);
>  }
>  
>  numa_total = 0;
> -- 
> 2.9.3
> 

-- 
Eduardo



Re: [Qemu-devel] [PATCH] scripts/qmp/qom-set: fix the value argument passed to srv.command()

2017-05-02 Thread Philippe Mathieu-Daudé

On 05/02/2017 11:41 AM, Greg Kurz wrote:

When invoking the script with -s, we end up passing a bogus value
to QEMU:

$ ./scripts/qmp/qom-set -s /var/tmp/qmp-sock-exp /machine.accel kvm
{}
$ ./scripts/qmp/qom-get -s /var/tmp/qmp-sock-exp /machine.accel
/var/tmp/qmp-sock-exp

This happens because sys.argv[2] isn't necessarily the command line
argument that holds the value. It is sys.argv[4] when -s was also
passed.

Actually, the code already has a variable to handle that. This patch
simply uses it.

Signed-off-by: Greg Kurz 


Reviewed-by: Philippe Mathieu-Daudé 


---
 scripts/qmp/qom-set |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/qmp/qom-set b/scripts/qmp/qom-set
index 54ecfecc531e..94e27789224c 100755
--- a/scripts/qmp/qom-set
+++ b/scripts/qmp/qom-set
@@ -61,4 +61,4 @@ else:
 srv = QEMUMonitorProtocol(socket_path)
 srv.connect()

-print srv.command('qom-set', path=path, property=prop, value=sys.argv[2])
+print srv.command('qom-set', path=path, property=prop, value=value)






Re: [Qemu-devel] [PATCH v3 8/8] tpm: Added support for TPM emulator

2017-05-02 Thread Stefan Berger

On 05/02/2017 02:50 PM, Marc-André Lureau wrote:

Hi

On Tue, May 2, 2017 at 10:25 PM Patrick Ohly > wrote:


On Tue, 2017-05-02 at 13:19 -0400, Stefan Berger wrote:
> On 05/02/2017 01:09 PM, Marc-André Lureau wrote:
> > On Tue, May 2, 2017 at 8:59 PM Stefan Berger
>
> > wrote:
> >
> >> And who is going to implement that qemu-swtpm? Obviously this
discussion
> >> doesn't contribute to progress if nobody is doing that in the
end.
> >>
> > The same persons who try to push for that emulated TPM code.
The easiest
> > approach would be to copy/adapt the swtpm code in qemu, if the
licence is
> > compatible. I can help with that if there is a consensus it's
a better
> > approach.
>
>
> It's a matter of time and at least I don't have time for that.

Neither do I, and nor (I believe) does Amarnath. The approach with
using
the existing swtpm project seemed attractive to us exactly because it
avoids having to write and maintain more than just the glue code
between
the two projects.


The main argument is not about having more or less code in qemu to 
maintain, but yes this is a concern (although giving up that 
maintenance to a seperate project with mostly Stefan-alone isn't a 
much better alternative). btw, is the project actually used by 
something else than qemu? (I am not talking about 
developpers/testing). If not, then it makes sense to make it part of qemu.


The intention would be to use it for RunC as well (plus higher layers 
afterwards): https://github.com/opencontainers/runc/pull/1082




But it's mostly a technical reason, to avoid having to rely on a 
foreign protocol and project with all the compatibility constrains.


I understand. Ideally swtpm-0.1 would be equivalent to 1.0 with all 
features available and no further protocol extensions necessary. In 
practice that may look different.




In the end, we may decide to start with a separate project, and change 
it in the future if it's problematic (that would break some cases, 
such as being able to freely switch the helper). Tbh, I am not so 
happy with the code quality of swtpm, and I haven't looked closely at 
libtpms. Having a qemu-swtpm as part of qemu would probably help 
improve it too, and bring a few more developers for maintainance...


libtpms combines a few source codes with some glue around it. The coding 
style is different for TPM 1.2 and TPM 2 code for example and the code 
bases are in the 10s of thousands of line. In the case of TPM 2 it 
'lives from' TCG code drops and thus there is no reformatting of source 
code etc.


If someone wants to get started on qemu-swtpm that's certainly cool but 
over the years it's just been quite difficult to find developers for it 
to share the burden. All that said, someone should state whether this 
series is a go or no-go because of the external project it requires.




[Qemu-devel] [PATCH v6 22/25] target/aarch64: optimize indirect branches

2017-05-02 Thread Richard Henderson
From: "Emilio G. Cota" 

Measurements:

[Baseline performance is that before applying this and the previous commit]

-NBench, aarch64-softmmu. Host: Intel 
i7-4790K @ 4.00GHz

 1.7x 
+-+--+-+
  | 
 |
  |   cross 
 |
 1.6x 
+cross+jr....+-+
  | #++#
 |
  | #  #
 |
 1.5x 
+-+...*..#...+-+
  | *+++*  #
 |
  | *   *  #
 |
 1.4x 
+-+...*...*..#...+-+
  | *   *  #
 |
  | #   *   *  #
 |
 1.3x 
+-++++#...*...*..#...+-+
  |  *++*   #   *   *  #
 |
  |  *  *   #   *   *  #
 |
 1.2x 
+-+*..*...#...*...*..#...+-+
  |  *  *   #   *   *  #
 |
  |  *  *   #   *   *  #
 |
 1.1x 
+-+...+++#..#..*..*...#...*...*..#...+-+
  |   #  *  *   #   *   *  #
 |
  | *  *  #  *  *   #   *   *  #  ###   
+++###  *  *   # |
   1x 
+-++-++-###++-*++*++#++*++*+-+#+++*+++*++#++*++*-+#++*++#++###-++*++*-+#++*+-*+++#+-++-+
  | *###  *  *  #   *  *  #  *  *   #  *++*###  *   *  #  *  *  #  
*   *  #  *  *++#   *  *  #  *  *   # |
  | *   *++#  *  *  #   *  *  #  *  *   #  *  *  #  *   *  #  *  *  #  
*   *  #  *  *  #   *  *  #  *  *   # |
 0.9x 
+-+---*###--###---###----###--*###--###--*###--###---###-----+-+
  ASSIGNMENT BITFIELD   FOURFP EMULATION   HUFFMAN   LU DECOMPOSITIONNEURAL 
NUMERIC SORSTRING SORThmean
  png: http://imgur.com/qO9ubtk
NB. cross here represents the previous commit.

-SPECint06 (test set), aarch64-linux-user. Host: 
Intel i7-4790K @ 4.00GHz

 1.5x 
+-+--+-+
  |   
*  |
  |   
*+++*   jr |
  |   * 
  *  |
 1.4x 
+-+.*...*.++++-+
  |   * 
  *  |   |
  |  ** 
  *  |   |
  |  *   ** 
  ** |
 1.3x 
+-+*...**...**.|.*...+-+
  |   +++*   ** 
  ** | * |
  |  *   *   ** 
  **+++* |
  |   

[Qemu-devel] [PATCH v6 21/25] target/aarch64: optimize cross-page direct jumps in softmmu

2017-05-02 Thread Richard Henderson
From: "Emilio G. Cota" 

Perf numbers in next commit's log.

Signed-off-by: Emilio G. Cota 
Signed-off-by: Richard Henderson 
---
 target/arm/translate-a64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index 24de30d..1e28094 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -373,7 +373,7 @@ static inline void gen_goto_tb(DisasContext *s, int n, 
uint64_t dest)
 } else if (s->singlestep_enabled) {
 gen_exception_internal(EXCP_DEBUG);
 } else {
-tcg_gen_exit_tb(0);
+tcg_gen_lookup_and_goto_ptr(cpu_pc);
 s->is_jmp = DISAS_TB_JUMP;
 }
 }
-- 
2.9.3




Re: [Qemu-devel] [PATCH v5++ 1/3] tcg/mips: implement goto_ptr

2017-05-02 Thread Aurelien Jarno
On 2017-05-02 18:21, Richard Henderson wrote:
> On 04/30/2017 04:52 PM, Aurelien Jarno wrote:
> > +/* jmp to the given host address (could be epilogue) */
> > +tcg_out_opc_reg(s, OPC_JR, 0, a0, 0);
> > +tcg_out_nop(s);
> 
> Any particular reason not to do the zeroing in the delay slot...
> 
> > +s->code_gen_epilogue = s->code_ptr;
> > +tcg_out_mov(s, TCG_TYPE_REG, TCG_REG_V0, TCG_REG_ZERO);
> 
> ... instead of here?

There is no particular reason in the current usage of goto_ptr. It's
just that in the future we might want to use code_gen_epilogue for
other reasons or use the tcg_out_opc_reg to do other things. It's
probably better to have a consistent behaviour across all TCG
targets.

That said if you prefer, I am find sending a v2 with the zeroing moved
to the delay slot.

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



Re: [Qemu-devel] [PATCH 01/14] target/sh4: split ctx->flags into ctx->tbflags and ctx->envflags

2017-05-02 Thread Aurelien Jarno
On 2017-05-02 09:16, Philippe Mathieu-Daudé wrote:
> Hi Aurelien,
> 
> On 05/01/2017 07:10 PM, Aurelien Jarno wrote:
> > There is a confusion (and not only in the SH4 target) between tb->flags,
> > env->flags and ctx->flags. To avoid it, split ctx->flags into
> > ctx->tbflags and ctx->envflags. ctx->tbflags stays unchanged during the
> > whole TB translation, while ctx->envflags evolves and is kept in sync
> > with env->flags using TCG instructions. ctx->envflags now only contains
> > the part that of env->flags that is contained in the TB state, i.e. the
> > DELAY_SLOT* flags.
> 
> I agree with your split, but I'd rather put the 2nd part of your commit
> description as comments in the struct DisasContext declaration, if you mind
> :)

Thanks for the review. I'll do that in the v2, although at some point it
should probably go to some higher level documentation, as it is often a
source of confusion.

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



[Qemu-devel] [PATCH v6 18/25] target/s390: Use tcg_gen_lookup_and_goto_ptr

2017-05-02 Thread Richard Henderson
Signed-off-by: Richard Henderson 
---
 target/s390x/translate.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/target/s390x/translate.c b/target/s390x/translate.c
index 01c6217..f7c2123 100644
--- a/target/s390x/translate.c
+++ b/target/s390x/translate.c
@@ -608,11 +608,16 @@ static void gen_op_calc_cc(DisasContext *s)
 set_cc_static(s);
 }
 
-static int use_goto_tb(DisasContext *s, uint64_t dest)
+static bool use_exit_tb(DisasContext *s)
 {
-if (unlikely(s->singlestep_enabled) ||
-(s->tb->cflags & CF_LAST_IO) ||
-(s->tb->flags & FLAG_MASK_PER)) {
+return (s->singlestep_enabled ||
+(s->tb->cflags & CF_LAST_IO) ||
+(s->tb->flags & FLAG_MASK_PER));
+}
+
+static bool use_goto_tb(DisasContext *s, uint64_t dest)
+{
+if (unlikely(use_exit_tb(s))) {
 return false;
 }
 #ifndef CONFIG_USER_ONLY
@@ -5426,8 +5431,10 @@ void gen_intermediate_code(CPUS390XState *env, struct 
TranslationBlock *tb)
 /* Exit the TB, either by raising a debug exception or by return.  */
 if (do_debug) {
 gen_exception(EXCP_DEBUG);
-} else {
+} else if (use_exit_tb()) {
 tcg_gen_exit_tb(0);
+} else {
+tcg_gen_lookup_and_goto_ptr(psw_addr);
 }
 break;
 default:
-- 
2.9.3




[Qemu-devel] [PATCH v6 15/25] tcg/s390: Implement goto_ptr

2017-05-02 Thread Richard Henderson
Signed-off-by: Richard Henderson 
---
 tcg/s390/tcg-target.h |  2 +-
 tcg/s390/tcg-target.inc.c | 24 +---
 2 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/tcg/s390/tcg-target.h b/tcg/s390/tcg-target.h
index 6b7bcfb..957f0c0 100644
--- a/tcg/s390/tcg-target.h
+++ b/tcg/s390/tcg-target.h
@@ -92,7 +92,7 @@ extern uint64_t s390_facilities;
 #define TCG_TARGET_HAS_mulsh_i32  0
 #define TCG_TARGET_HAS_extrl_i64_i32  0
 #define TCG_TARGET_HAS_extrh_i64_i32  0
-#define TCG_TARGET_HAS_goto_ptr   0
+#define TCG_TARGET_HAS_goto_ptr   1
 
 #define TCG_TARGET_HAS_div2_i64   1
 #define TCG_TARGET_HAS_rot_i641
diff --git a/tcg/s390/tcg-target.inc.c b/tcg/s390/tcg-target.inc.c
index a679280..5d7083e 100644
--- a/tcg/s390/tcg-target.inc.c
+++ b/tcg/s390/tcg-target.inc.c
@@ -1741,9 +1741,14 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 
 switch (opc) {
 case INDEX_op_exit_tb:
-/* return value */
-tcg_out_movi(s, TCG_TYPE_PTR, TCG_REG_R2, args[0]);
-tgen_gotoi(s, S390_CC_ALWAYS, tb_ret_addr);
+/* Reuse the zeroing that exists for goto_ptr.  */
+a0 = args[0];
+if (a0 == 0) {
+tgen_gotoi(s, S390_CC_ALWAYS, s->code_gen_epilogue);
+} else {
+tcg_out_movi(s, TCG_TYPE_PTR, TCG_REG_R2, a0);
+tgen_gotoi(s, S390_CC_ALWAYS, tb_ret_addr);
+}
 break;
 
 case INDEX_op_goto_tb:
@@ -1767,6 +1772,10 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 s->tb_jmp_reset_offset[args[0]] = tcg_current_code_size(s);
 break;
 
+case INDEX_op_goto_ptr:
+tcg_out_insn(s, RR, BCR, S390_CC_ALWAYS, args[0]);
+break;
+
 OP_32_64(ld8u):
 /* ??? LLC (RXY format) is only present with the extended-immediate
facility, whereas LLGC is always present.  */
@@ -2241,6 +2250,7 @@ static const TCGTargetOpDef s390_op_defs[] = {
 { INDEX_op_exit_tb, { } },
 { INDEX_op_goto_tb, { } },
 { INDEX_op_br, { } },
+{ INDEX_op_goto_ptr, { "r" } },
 
 { INDEX_op_ld8u_i32, { "r", "r" } },
 { INDEX_op_ld8s_i32, { "r", "r" } },
@@ -2439,6 +2449,14 @@ static void tcg_target_qemu_prologue(TCGContext *s)
 /* br %r3 (go to TB) */
 tcg_out_insn(s, RR, BCR, S390_CC_ALWAYS, tcg_target_call_iarg_regs[1]);
 
+/*
+ * Return path for goto_ptr. Set return value to 0, a-la exit_tb,
+ * and fall through to the rest of the epilogue.
+ */
+s->code_gen_epilogue = s->code_ptr;
+tcg_out_movi(s, TCG_TYPE_PTR, TCG_REG_R2, 0);
+
+/* TB epilogue */
 tb_ret_addr = s->code_ptr;
 
 /* lmg %r6,%r15,fs+48(%r15) (restore registers) */
-- 
2.9.3




[Qemu-devel] [PATCH v6 11/25] tb-hash: improve tb_jmp_cache hash function in user mode

2017-05-02 Thread Richard Henderson
From: "Emilio G. Cota" 

Optimizations to cross-page chaining and indirect branches make
performance more sensitive to the hit rate of tb_jmp_cache.
The constraint of reserving some bits for the page number
lowers the achievable quality of the hashing function.

However, user-mode does not have this requirement. Thus,
with this change we use for user-mode a hashing function that
is both faster and of better quality than the previous one.

Measurements:

Note: baseline (i.e. speedup == 1x) is QEMU v2.9.0.

-   SPECint06 (test set), x86_64-linux-user. Host: 
Intel i7-6700K @ 4.00GHz

 2.2x 
+-+--+-+
  | 
 |
  | jr  
 |
   2x +jr+multhash
++...+-+
  |jr+hash  
|$$$ |
  | 
|$+$ |
  |
### $ |
 1.8x 
+-+..#|#.$...+-+
  |  
++#+# $ |
  |   
|# # $ |
 1.6x 
+-+***.#.$++$$$..+-+
  | $$$  
*+* # $ |$+$|
  |   ++$$$   ### $  * 
* # $  +++|$ $|
  | ++###+$   # # $  * 
* # $   ###   ## $|
 1.4x 
+-+...***+#.$.***.#.$..*.*.#.$...#+#$$.*++*|#.$..+-+
  | *+* # $ * * # $  * 
* # $   # # $ *  *+# $|
  | * * # $   + * * # $  * 
* # $ *** # $ *  * # $   ###$$|
 1.2x 
+-+...*.*.#.$.***##$$.*.*.#.$..*.*.#.$.*.*.#.$.*..*.#.$.***+#+$..+-+
  | * * # $ *+* # $ * * # $   +++* 
* # $ ++###$$ * * # $ *  * # $ * * # $|
  |***##$$  * * # $ * * # $ * * # $ ***##$$  ++###   * 
* # $ *** #+$ * * # $ *  * # $ * * # $|
  |*+*+#+$ ***##$$$ * * # $ * * # $ * * # $ *+* # $ ++$$ ***+#   * 
* # $ * * # $ * * # $ *  * # $ * * # $|
   1x 
+-++-*+*+#+$+*+*+#-+$+*+*-#+$+*+*+#+$+*+*+#+$+*-*+#+$+***++#+$+*+*+#$$+*+*+#+$+*+*+#+$+*+*-#+$+*+-*+#+$+*+*+#+$-++-+
  |* * # $ * * #  $ * * # $ * * # $ * * # $ * * # $ * *  # $ * * # $ * 
* # $ * * # $ * * # $ *  * # $ * * # $|
  |* * # $ * * #  $ * * # $ * * # $ * * # $ * * # $ * *  # $ * * # $ * 
* # $ * * # $ * * # $ *  * # $ * * # $|
 0.8x 
+-+--***##$$-***##$$$-***##$$-***##$$-***##$$-***##$$-***###$$-***##$$-***##$$-***##$$-***##$$-##$$-***##$$--+-+
 astar   bzip2  gcc   gobmk h264ref   hmmlibquantum  mcf 
omnetpperlbench   sjengxalancbmk   hmean
  png: http://imgur.com/4UXTrEc

Here I also tried the hash function suggested by Paolo ("multhash"):

  return ((uint64_t) (pc * 2654435761) >> 32) & (TB_JMP_CACHE_SIZE - 1);

As you can see it is just as good as the other new function ("hash"),
which is what I ended up going with.

-  SPECint06 (train set), x86_64-linux-user. Host: 
Intel i7-6700K @ 4.00GHz

 2.6x 
+-+--+-+
  | 
 |
  | jr  
 ### |
 2.4x 
+jr+hash...#.#...+-+
  | 
 # # |
  | 
 # # |
 2.2x 

[Qemu-devel] [PATCH v6 24/25] target/mips: optimize cross-page direct jumps in softmmu

2017-05-02 Thread Richard Henderson
From: Aurelien Jarno 

Cc: Yongbok Kim 
Signed-off-by: Aurelien Jarno 
Message-Id: <20170430145254.25616-3-aurel...@aurel32.net>
Signed-off-by: Richard Henderson 
---
 target/mips/translate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/mips/translate.c b/target/mips/translate.c
index 3022f34..1a7ac07 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -4233,7 +4233,7 @@ static inline void gen_goto_tb(DisasContext *ctx, int n, 
target_ulong dest)
 save_cpu_state(ctx, 0);
 gen_helper_raise_exception_debug(cpu_env);
 }
-tcg_gen_exit_tb(0);
+tcg_gen_lookup_and_goto_ptr(cpu_PC);
 }
 }
 
-- 
2.9.3




[Qemu-devel] [PATCH v6 25/25] target/mips: optimize indirect branches

2017-05-02 Thread Richard Henderson
From: Aurelien Jarno 

Cc: Yongbok Kim 
Signed-off-by: Aurelien Jarno 
Message-Id: <20170430145254.25616-4-aurel...@aurel32.net>
Signed-off-by: Richard Henderson 
---
 target/mips/translate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/mips/translate.c b/target/mips/translate.c
index 1a7ac07..559f8fe 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -10725,7 +10725,7 @@ static void gen_branch(DisasContext *ctx, int 
insn_bytes)
 save_cpu_state(ctx, 0);
 gen_helper_raise_exception_debug(cpu_env);
 }
-tcg_gen_exit_tb(0);
+tcg_gen_lookup_and_goto_ptr(cpu_PC);
 break;
 default:
 fprintf(stderr, "unknown branch 0x%x\n", proc_hflags);
-- 
2.9.3




[Qemu-devel] [PATCH v6 23/25] tcg/mips: implement goto_ptr

2017-05-02 Thread Richard Henderson
From: Aurelien Jarno 

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Aurelien Jarno 
Message-Id: <20170430145254.25616-2-aurel...@aurel32.net>
Signed-off-by: Richard Henderson 
---
 tcg/mips/tcg-target.h |  2 +-
 tcg/mips/tcg-target.inc.c | 13 +
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/tcg/mips/tcg-target.h b/tcg/mips/tcg-target.h
index e3240cf..d75cb63 100644
--- a/tcg/mips/tcg-target.h
+++ b/tcg/mips/tcg-target.h
@@ -130,7 +130,7 @@ extern bool use_mips32r2_instructions;
 #define TCG_TARGET_HAS_muluh_i321
 #define TCG_TARGET_HAS_mulsh_i321
 #define TCG_TARGET_HAS_bswap32_i32  1
-#define TCG_TARGET_HAS_goto_ptr 0
+#define TCG_TARGET_HAS_goto_ptr 1
 
 #if TCG_TARGET_REG_BITS == 64
 #define TCG_TARGET_HAS_add2_i32 0
diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index 01ac7b2..9e5b9f4 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -1747,6 +1747,11 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 tcg_out_nop(s);
 s->tb_jmp_reset_offset[a0] = tcg_current_code_size(s);
 break;
+case INDEX_op_goto_ptr:
+/* jmp to the given host address (could be epilogue) */
+tcg_out_opc_reg(s, OPC_JR, 0, a0, 0);
+tcg_out_nop(s);
+break;
 case INDEX_op_br:
 tcg_out_brcond(s, TCG_COND_EQ, TCG_REG_ZERO, TCG_REG_ZERO,
arg_label(a0));
@@ -2160,6 +2165,7 @@ static const TCGTargetOpDef mips_op_defs[] = {
 { INDEX_op_exit_tb, { } },
 { INDEX_op_goto_tb, { } },
 { INDEX_op_br, { } },
+{ INDEX_op_goto_ptr, { "r" } },
 
 { INDEX_op_ld8u_i32, { "r", "r" } },
 { INDEX_op_ld8s_i32, { "r", "r" } },
@@ -2451,6 +2457,13 @@ static void tcg_target_qemu_prologue(TCGContext *s)
 /* delay slot */
 tcg_out_mov(s, TCG_TYPE_PTR, TCG_AREG0, tcg_target_call_iarg_regs[0]);
 
+/*
+ * Return path for goto_ptr. Set return value to 0, a-la exit_tb,
+ * and fall through to the rest of the epilogue.
+ */
+s->code_gen_epilogue = s->code_ptr;
+tcg_out_mov(s, TCG_TYPE_REG, TCG_REG_V0, TCG_REG_ZERO);
+
 /* TB epilogue */
 tb_ret_addr = s->code_ptr;
 for (i = 0; i < ARRAY_SIZE(tcg_target_callee_save_regs); i++) {
-- 
2.9.3




[Qemu-devel] [PATCH v6 13/25] tcg/aarch64: Implement goto_ptr

2017-05-02 Thread Richard Henderson
Measurements:

  SPECint06 (test set), x86_64-linux-user. Host: APM 64-bit 
ARMv8 (Atlas/A57) @ 2.4 GHz

 1.45x 
+-+-+-+
   |  * 
 |
   |  +++ *   * 
   +goto-ptr |
  1.4x 
+-+...**...*+-+
   | *+++**   *
+++   |
 1.35x 
+-+...*...**...*...*+-+
   | *   **   *   
*+++*  |
   | *   **   *   * 
  *  |
  1.3x 
+-+...*...**...*...*...*+-+
   | *   **   *   * 
  *  |
   | *   **   *   * 
  ** |
 1.25x 
+-+...*...*...**...*...*...**...*...*...+-+
   | *   *   *   **   *   * 
  **+++*   *   * |
  1.2x 
+-+...*...*...*...**...*...*...**...*...*...*...+-+
   | *   *   *   **   *   * 
  **   *   *   * |
   | *   *   *   **   *   * 
  **   *   *   *   * |
 1.15x 
+-+...*...*...*...**...*...*...**...*...*...*...*...*...+-+
   | *   *   *   **   *   * 
  *+++ *   *   *   *   *   * |
   | *   *   *   **   *   * 
  *   **   *   *   *   *   * |
  1.1x 
+-+...*...*...*...**...*...*...*...*...*...*...**...*...*...*...*...*...+-+
   | *   *   *   **   *   *   *   *   *   * 
  *   *   **   *   *   *   *   * |
 1.05x 
+-+...*...*...*...**...*...*...*...*...*...*...*...*...**...*...*...*...*...*...+-+
   | *   *   *   *   **   *   *   *   *   *   * 
  *   *   **   *   *   *   *   * |
   | *   *   *   *   *   **   *   *   *   *   *   *   *   * 
  *   *   **   *   *   *   *   * |
1x 
+-+---*---*---**---*---*---*---*---*---**---*---*---+-+
  astar   bzip2 gccgobmk h264ref   hmmlibquantum mcf 
omnetpperlbenchsjenxalancbmk   hmean
  png: http://imgur.com/en9HE8L

Tested-by: Emilio G. Cota 
Signed-off-by: Richard Henderson 
---
 tcg/aarch64/tcg-target.h |  2 +-
 tcg/aarch64/tcg-target.inc.c | 22 --
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/tcg/aarch64/tcg-target.h b/tcg/aarch64/tcg-target.h
index b82eac4..55a46ac 100644
--- a/tcg/aarch64/tcg-target.h
+++ b/tcg/aarch64/tcg-target.h
@@ -77,7 +77,7 @@ typedef enum {
 #define TCG_TARGET_HAS_mulsh_i320
 #define TCG_TARGET_HAS_extrl_i64_i320
 #define TCG_TARGET_HAS_extrh_i64_i320
-#define TCG_TARGET_HAS_goto_ptr 0
+#define TCG_TARGET_HAS_goto_ptr 1
 
 #define TCG_TARGET_HAS_div_i64  1
 #define TCG_TARGET_HAS_rem_i64  1
diff --git a/tcg/aarch64/tcg-target.inc.c b/tcg/aarch64/tcg-target.inc.c
index 290de6d..5f18545 100644
--- a/tcg/aarch64/tcg-target.inc.c
+++ b/tcg/aarch64/tcg-target.inc.c
@@ -1357,8 +1357,13 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
 
 switch (opc) {
 case INDEX_op_exit_tb:
-tcg_out_movi(s, TCG_TYPE_I64, TCG_REG_X0, a0);
-tcg_out_goto(s, tb_ret_addr);
+/* Reuse the zeroing that exists for goto_ptr.  */
+if (a0 == 0) {
+tcg_out_goto(s, s->code_gen_epilogue);
+} else {
+tcg_out_movi(s, TCG_TYPE_I64, TCG_REG_X0, a0);
+tcg_out_goto(s, tb_ret_addr);
+}
 break;
 
 case INDEX_op_goto_tb:
@@ -1374,6 +1379,10 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
 s->tb_jmp_reset_offset[a0] = tcg_current_code_size(s);
 break;
 
+case 

[Qemu-devel] [PATCH v6 20/25] target/alpha: Use tcg_gen_lookup_and_goto_ptr

2017-05-02 Thread Richard Henderson
Signed-off-by: Richard Henderson 
---
 target/alpha/translate.c | 54 +---
 1 file changed, 47 insertions(+), 7 deletions(-)

diff --git a/target/alpha/translate.c b/target/alpha/translate.c
index df5d695..c2941ae 100644
--- a/target/alpha/translate.c
+++ b/target/alpha/translate.c
@@ -89,6 +89,9 @@ typedef enum {
updated the PC for the next instruction to be executed.  */
 EXIT_PC_STALE,
 
+/* We are exiting the TB due to page crossing or space constraints.  */
+EXIT_FALLTHRU,
+
 /* We are ending the TB with a noreturn function call, e.g. longjmp.
No following code will be executed.  */
 EXIT_NORETURN,
@@ -455,11 +458,17 @@ static bool in_superpage(DisasContext *ctx, int64_t addr)
 #endif
 }
 
+static bool use_exit_tb(DisasContext *ctx)
+{
+return ((ctx->tb->cflags & CF_LAST_IO)
+|| ctx->singlestep_enabled
+|| singlestep);
+}
+
 static bool use_goto_tb(DisasContext *ctx, uint64_t dest)
 {
 /* Suppress goto_tb in the case of single-steping and IO.  */
-if ((ctx->tb->cflags & CF_LAST_IO)
-|| ctx->singlestep_enabled || singlestep) {
+if (unlikely(use_exit_tb(ctx))) {
 return false;
 }
 #ifndef CONFIG_USER_ONLY
@@ -492,7 +501,12 @@ static ExitStatus gen_bdirect(DisasContext *ctx, int ra, 
int32_t disp)
 return EXIT_GOTO_TB;
 } else {
 tcg_gen_movi_i64(cpu_pc, dest);
-return EXIT_PC_UPDATED;
+if (use_exit_tb(ctx)) {
+return EXIT_PC_UPDATED;
+} else {
+tcg_gen_lookup_and_goto_ptr(cpu_pc);
+return EXIT_GOTO_TB;
+}
 }
 }
 
@@ -2421,7 +2435,12 @@ static ExitStatus translate_one(DisasContext *ctx, 
uint32_t insn)
 if (ra != 31) {
 tcg_gen_movi_i64(ctx->ir[ra], ctx->pc);
 }
-ret = EXIT_PC_UPDATED;
+if (use_exit_tb(ctx)) {
+ret = EXIT_PC_UPDATED;
+} else {
+tcg_gen_lookup_and_goto_ptr(cpu_pc);
+ret = EXIT_GOTO_TB;
+}
 break;
 
 case 0x1B:
@@ -2677,7 +2696,12 @@ static ExitStatus translate_one(DisasContext *ctx, 
uint32_t insn)
 tcg_gen_andi_i64(tmp, vb, 1);
 tcg_gen_st8_i64(tmp, cpu_env, offsetof(CPUAlphaState, pal_mode));
 tcg_gen_andi_i64(cpu_pc, vb, ~3);
-ret = EXIT_PC_UPDATED;
+if (use_exit_tb(ctx)) {
+ret = EXIT_PC_UPDATED;
+} else {
+tcg_gen_lookup_and_goto_ptr(cpu_pc);
+ret = EXIT_GOTO_TB;
+}
 break;
 #else
 goto invalid_opc;
@@ -2978,7 +3002,7 @@ void gen_intermediate_code(CPUAlphaState *env, struct 
TranslationBlock *tb)
 || num_insns >= max_insns
 || singlestep
 || ctx.singlestep_enabled)) {
-ret = EXIT_PC_STALE;
+ret = EXIT_FALLTHRU;
 }
 } while (ret == NO_EXIT);
 
@@ -3000,8 +3024,24 @@ void gen_intermediate_code(CPUAlphaState *env, struct 
TranslationBlock *tb)
 tcg_gen_exit_tb(0);
 }
 break;
+case EXIT_FALLTHRU:
+if (ctx.singlestep_enabled) {
+tcg_gen_movi_i64(cpu_pc, ctx.pc);
+gen_excp_1(EXCP_DEBUG, 0);
+} else if (use_exit_tb()) {
+tcg_gen_movi_i64(cpu_pc, ctx.pc);
+tcg_gen_exit_tb(0);
+} else if (use_goto_tb(, ctx.pc)) {
+tcg_gen_goto_tb(0);
+tcg_gen_movi_i64(cpu_pc, ctx.pc);
+tcg_gen_exit_tb((uintptr_t)ctx.tb);
+} else {
+tcg_gen_movi_i64(cpu_pc, ctx.pc);
+tcg_gen_lookup_and_goto_ptr(cpu_pc);
+}
+break;
 default:
-abort();
+g_assert_not_reached();
 }
 
 gen_tb_end(tb, num_insns);
-- 
2.9.3




[Qemu-devel] [PATCH v6 17/25] tcg/arm: Implement goto_ptr

2017-05-02 Thread Richard Henderson
Signed-off-by: Richard Henderson 
---
 tcg/arm/tcg-target.h |  2 +-
 tcg/arm/tcg-target.inc.c | 25 +
 2 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/tcg/arm/tcg-target.h b/tcg/arm/tcg-target.h
index c114df7..5ef1086 100644
--- a/tcg/arm/tcg-target.h
+++ b/tcg/arm/tcg-target.h
@@ -123,7 +123,7 @@ extern bool use_idiv_instructions;
 #define TCG_TARGET_HAS_mulsh_i320
 #define TCG_TARGET_HAS_div_i32  use_idiv_instructions
 #define TCG_TARGET_HAS_rem_i32  0
-#define TCG_TARGET_HAS_goto_ptr 0
+#define TCG_TARGET_HAS_goto_ptr 1
 
 enum {
 TCG_AREG0 = TCG_REG_R6,
diff --git a/tcg/arm/tcg-target.inc.c b/tcg/arm/tcg-target.inc.c
index 590c57d..9f5cb66 100644
--- a/tcg/arm/tcg-target.inc.c
+++ b/tcg/arm/tcg-target.inc.c
@@ -1655,8 +1655,14 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 
 switch (opc) {
 case INDEX_op_exit_tb:
-tcg_out_movi32(s, COND_AL, TCG_REG_R0, args[0]);
-tcg_out_goto(s, COND_AL, tb_ret_addr);
+/* Reuse the zeroing that exists for goto_ptr.  */
+a0 = args[0];
+if (a0 == 0) {
+tcg_out_goto(s, COND_AL, s->code_gen_epilogue);
+} else {
+tcg_out_movi32(s, COND_AL, TCG_REG_R0, args[0]);
+tcg_out_goto(s, COND_AL, tb_ret_addr);
+}
 break;
 case INDEX_op_goto_tb:
 if (s->tb_jmp_insn_offset) {
@@ -1671,6 +1677,9 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 }
 s->tb_jmp_reset_offset[args[0]] = tcg_current_code_size(s);
 break;
+case INDEX_op_goto_ptr:
+tcg_out_bx(s, COND_AL, args[0]);
+break;
 case INDEX_op_br:
 tcg_out_goto_label(s, COND_AL, arg_label(args[0]));
 break;
@@ -1961,6 +1970,7 @@ static const TCGTargetOpDef arm_op_defs[] = {
 { INDEX_op_exit_tb, { } },
 { INDEX_op_goto_tb, { } },
 { INDEX_op_br, { } },
+{ INDEX_op_goto_ptr, { "r" } },
 
 { INDEX_op_ld8u_i32, { "r", "r" } },
 { INDEX_op_ld8s_i32, { "r", "r" } },
@@ -2136,9 +2146,16 @@ static void tcg_target_qemu_prologue(TCGContext *s)
 tcg_out_mov(s, TCG_TYPE_PTR, TCG_AREG0, tcg_target_call_iarg_regs[0]);
 
 tcg_out_bx(s, COND_AL, tcg_target_call_iarg_regs[1]);
-tb_ret_addr = s->code_ptr;
 
-/* Epilogue.  We branch here via tb_ret_addr.  */
+/*
+ * Return path for goto_ptr. Set return value to 0, a-la exit_tb,
+ * and fall through to the rest of the epilogue.
+ */
+s->code_gen_epilogue = s->code_ptr;
+tcg_out_movi(s, TCG_TYPE_PTR, TCG_REG_R0, 0);
+
+/* TB epilogue */
+tb_ret_addr = s->code_ptr;
 tcg_out_dat_rI(s, COND_AL, ARITH_ADD, TCG_REG_CALL_STACK,
TCG_REG_CALL_STACK, stack_addend, 1);
 
-- 
2.9.3




[Qemu-devel] [PATCH v6 19/25] target/hppa: Use tcg_gen_lookup_and_goto_ptr

2017-05-02 Thread Richard Henderson
Signed-off-by: Richard Henderson 
---
 target/hppa/translate.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/target/hppa/translate.c b/target/hppa/translate.c
index 9e8c233..e10abc5 100644
--- a/target/hppa/translate.c
+++ b/target/hppa/translate.c
@@ -517,7 +517,7 @@ static void gen_goto_tb(DisasContext *ctx, int which,
 if (ctx->singlestep_enabled) {
 gen_excp_1(EXCP_DEBUG);
 } else {
-tcg_gen_exit_tb(0);
+tcg_gen_lookup_and_goto_ptr(cpu_iaoq_f);
 }
 }
 }
@@ -1510,7 +1510,7 @@ static ExitStatus do_ibranch(DisasContext *ctx, TCGv dest,
 } else if (is_n && use_nullify_skip(ctx)) {
 /* The (conditional) branch, B, nullifies the next insn, N,
and we're allowed to skip execution N (no single-step or
-   tracepoint in effect).  Since the exit_tb that we must use
+   tracepoint in effect).  Since the goto_ptr that we must use
for the indirect branch consumes no special resources, we
can (conditionally) skip B and continue execution.  */
 /* The use_nullify_skip test implies we have a known control path.  */
@@ -1527,7 +1527,7 @@ static ExitStatus do_ibranch(DisasContext *ctx, TCGv dest,
 if (link != 0) {
 tcg_gen_movi_tl(cpu_gr[link], ctx->iaoq_n);
 }
-tcg_gen_exit_tb(0);
+tcg_gen_lookup_and_goto_ptr(cpu_iaoq_f);
 return nullify_end(ctx, NO_EXIT);
 } else {
 cond_prep(>null_cond);
@@ -3885,7 +3885,7 @@ void gen_intermediate_code(CPUHPPAState *env, struct 
TranslationBlock *tb)
 if (ctx.singlestep_enabled) {
 gen_excp_1(EXCP_DEBUG);
 } else {
-tcg_gen_exit_tb(0);
+tcg_gen_lookup_and_goto_ptr(cpu_iaoq_f);
 }
 break;
 default:
-- 
2.9.3




[Qemu-devel] [PATCH v6 16/25] tcg/arm: Clarify tcg_out_bx for arm4 host

2017-05-02 Thread Richard Henderson
In theory this would re-enable usage of QEMU on an armv4 host.
Whether this is worthwhile is debatable -- we've been unconditionally
issuing the armv5t BX instruction in the prologue since 2011 without
complaint.  Possibly we should simply require an armv6 host.

Signed-off-by: Richard Henderson 
---
 tcg/arm/tcg-target.inc.c | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/tcg/arm/tcg-target.inc.c b/tcg/arm/tcg-target.inc.c
index e75a6d4..590c57d 100644
--- a/tcg/arm/tcg-target.inc.c
+++ b/tcg/arm/tcg-target.inc.c
@@ -329,11 +329,6 @@ static const uint8_t tcg_cond_to_arm_cond[] = {
 [TCG_COND_GTU] = COND_HI,
 };
 
-static inline void tcg_out_bx(TCGContext *s, int cond, int rn)
-{
-tcg_out32(s, (cond << 28) | 0x012fff10 | rn);
-}
-
 static inline void tcg_out_b(TCGContext *s, int cond, int32_t offset)
 {
 tcg_out32(s, (cond << 28) | 0x0a00 |
@@ -402,6 +397,18 @@ static inline void tcg_out_mov_reg(TCGContext *s, int 
cond, int rd, int rm)
 }
 }
 
+static inline void tcg_out_bx(TCGContext *s, int cond, TCGReg rn)
+{
+/* Unless the C portion of QEMU is compiled as thumb, we don't
+   actually need true BX semantics; merely a branch to an address
+   held in a register.  */
+if (use_armv5t_instructions) {
+tcg_out32(s, (cond << 28) | 0x012fff10 | rn);
+} else {
+tcg_out_mov_reg(s, cond, TCG_REG_PC, rn);
+}
+}
+
 static inline void tcg_out_dat_imm(TCGContext *s,
 int cond, int opc, int rd, int rn, int im)
 {
@@ -977,7 +984,7 @@ static inline void tcg_out_st8(TCGContext *s, int cond,
  * with the code buffer limited to 16MB we wouldn't need the long case.
  * But we also use it for the tail-call to the qemu_ld/st helpers, which does.
  */
-static inline void tcg_out_goto(TCGContext *s, int cond, tcg_insn_unit *addr)
+static void tcg_out_goto(TCGContext *s, int cond, tcg_insn_unit *addr)
 {
 intptr_t addri = (intptr_t)addr;
 ptrdiff_t disp = tcg_pcrel_diff(s, addr);
@@ -987,15 +994,9 @@ static inline void tcg_out_goto(TCGContext *s, int cond, 
tcg_insn_unit *addr)
 return;
 }
 
+assert(use_armv5t_instructions || (addri & 1) == 0);
 tcg_out_movi32(s, cond, TCG_REG_TMP, addri);
-if (use_armv5t_instructions) {
-tcg_out_bx(s, cond, TCG_REG_TMP);
-} else {
-if (addri & 1) {
-tcg_abort();
-}
-tcg_out_mov_reg(s, cond, TCG_REG_PC, TCG_REG_TMP);
-}
+tcg_out_bx(s, cond, TCG_REG_TMP);
 }
 
 /* The call case is mostly used for helpers - so it's not unreasonable
-- 
2.9.3




[Qemu-devel] [PATCH v6 07/25] target/arm: optimize indirect branches

2017-05-02 Thread Richard Henderson
From: "Emilio G. Cota" 

Speed up indirect branches by jumping to the target if it is valid.

Softmmu measurements (see later commit for user-mode results):

Note: baseline (i.e. speedup == 1x) is QEMU v2.9.0.

- Impact on Boot time

| setup  | ARM debian jessie boot+shutdown time | stddev |
|+--+|
| v2.9.0 | 8.84 |   0.07 |
| +cross | 8.85 |   0.03 |
| +jr| 8.83 |   0.06 |

-NBench, arm-softmmu (debian jessie guest). Host: 
Intel i7-4790K @ 4.00GHz

  1.3x 
+-+-+-+
   |
 |
   |   cross    
 |
 1.25x 
+cross+jr..#++#.+-+
   |  #  #  
 |
   | +++#  #  #  #  
 |
   |  +++  #  #  #  
 |
  1.2x 
+-+...*..*..#..#..#.+-+
   |    #*  *  #  #  #  
     |
   |  *  *  #*  *  #  #  #  
   #  #  |
 1.15x 
+-+*..*..#*..*..#..#..#.#..#+-+
   |  *  *  #*  *  #  #  #  
   #  #  |
   |  *  *  #    *  *  #  #  #  
   #  #  |
   |  *  *  #  #  #  *  *  #  #  #  
   #  #  |
  1.1x 
+-+*..*..#..#..#..*..*..#..#..#.#..#.#..#...+-+
   |  *  *  #  #  #  *  *  #  #  #  
   #  # #  # |
   |  *  *  #  #  #  *  *  #  #  #  
   #  # #  # |
 1.05x 
+-+....*..*..#..#..#..*..*..#..#..#.#..#..+++*..#...+-+
   |*  #  *  *  #  #  #  *  *  #  *  #  
   #  #   +++ |###  *   *  # |
   |*+++*  #  *  *  #  #  #  *  *  #  *+++*  #  
  #  *###  *  *  #  *   *  # |
   | *###  +++  *   *  #  *  *  #  *  #  *  *  #  *   *  #  
*  *  #  * | *++#  *  *  #  *   *  # |
1x 
+-++-+*+++*-+#++++#++*+-+*++#+-*++*++#-+*+++*-+#++*++*++#++*+-+*++#+-*++*++#-+*+++*-+#++*++*++#++*+-+*++#+-++-+
   | *   *  #  *  *  #  *   *  #  *  *  #  *   *  #  *  *  #  *   *  #  
*  *  #  *   *  #  *  *  #  *   *  # |
   | *   *  #  *  *  #  *   *  #  *  *  #  *   *  #  *  *  #  *   *  #  
*  *  #  *   *  #  *  *  #  *   *  # |
 0.95x 
+-+---*###--###--*###--###--*###--###--*###--###--*###--###--*###---+-+
   ASSIGNMENT BITFIELD   FOURFP EMULATION   HUFFMAN   LU DECOMPOSITIONEURAL 
NNUMERIC SOSTRING SORT hmean
  png: http://imgur.com/eOLmZNR

NB. 'cross' represents the previous commit.

Signed-off-by: Emilio G. Cota 
Message-Id: <1493263764-18657-8-git-send-email-c...@braap.org>
[rth: Replace gen_jr global variable with DISAS_EXIT state.]
Signed-off-by: Richard Henderson 
---
 target/arm/translate.c | 25 -
 target/arm/translate.h |  4 
 2 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/target/arm/translate.c b/target/arm/translate.c
index facb52f..f879da6 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -1178,7 +1178,7 @@ static void gen_exception_internal_insn(DisasContext *s, 
int offset, int excp)
 gen_set_condexec(s);
 gen_set_pc_im(s, s->pc - offset);
 gen_exception_internal(excp);
-s->is_jmp = DISAS_JUMP;
+s->is_jmp = DISAS_EXC;
 }
 
 static void gen_exception_insn(DisasContext *s, int offset, int excp,
@@ -1187,14 +1187,14 @@ static void gen_exception_insn(DisasContext *s, int 
offset, int excp,
 gen_set_condexec(s);
 gen_set_pc_im(s, s->pc - offset);
 gen_exception(excp, syn, target_el);
- 

[Qemu-devel] [PATCH v6 10/25] target/i386: optimize indirect branches

2017-05-02 Thread Richard Henderson
From: "Emilio G. Cota" 

Speed up indirect branches by jumping to the target if it is valid.

Softmmu measurements (see later commit for user-mode numbers):

Note: baseline (i.e. speedup == 1x) is QEMU v2.9.0.

-  SPECint06 (test set), x86_64-softmmu (Ubuntu 16.04 guest). 
Host: Intel i7-4790K @ 4.00GHz

 2.4x 
+-+--+-+
  | 
 |
  |   cross 
 |
 2.2x 
+cross+jr..+++...+-+
  | 
  |  |
  | 
  +++ |  |
   2x 
+-+..|..|+-+
  | 
   |  |  |
  | 
   |  |  |
 1.8x 
+-+..|...+-+
  | 
   |# |# |
  | 
  |# |
 1.6x 
+-+*.|*.|#...+-+
  | 
 * |* |# |
  | 
 * |* |# |
 1.4x 
+-+...+++..*.|*.|#...+-+
  |  ++ 
 * |*++# +++ |
  |+++|  |  
#++# *++*  #  +++ |  |
 1.2x 
+-+..###.+++|..|.....#.*..*..#...|.###...+-+
  |+++   #    #  ***###  
*++*  # *  *  ##++#  |#  +++#++#|
  |### +++  *++* #  *++*  #  ++#  #  *|* |# +++  *  
*  # *  *  #  ***  #  *| *|#    #|
   1x 
+-++-*++*++#++***###++*++*+#++*+-*++#+++#++***++#+-*+*++#-+##++*++*-+#+*++*-+#++*+*++#++*-+*+#++*++*++#-++-+
  |*  *  #  * *  #  *  * #  *  *  # *  *  #  * *  #  *|* |#  *++* #  *  
*  # *  *  #  * *  #  *  * #  *  *  #|
  |*  *  #  * *  #  *  * #  *  *  # *  *  #  * *  #  *+*++#  *  * #  *  
*  # *  *  #  * *  #  *  * #  *  *  #|
 0.8x 
+-+--###--***###--##--###-###--***###--***###--##--###-###--***###--##--###--+-+
 astar   bzip2  gcc   gobmk h264ref   hmmlibquantum  mcf 
omnetpperlbench   sjengxalancbmk   hmean
  png: http://imgur.com/DU36YFU

NB. 'cross' represents the previous commit.

Reviewed-by: Alex Bennée 
Reviewed-by: Richard Henderson 
Signed-off-by: Emilio G. Cota 
Message-Id: <1493263764-18657-11-git-send-email-c...@braap.org>
Signed-off-by: Richard Henderson 
---
 target/i386/translate.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/target/i386/translate.c b/target/i386/translate.c
index ea113fe..674ec96 100644
--- a/target/i386/translate.c
+++ b/target/i386/translate.c
@@ -4996,7 +4996,7 @@ static target_ulong disas_insn(CPUX86State *env, 
DisasContext *s,
 gen_push_v(s, cpu_T1);
 gen_op_jmp_v(cpu_T0);
 gen_bnd_jmp(s);
-gen_eob(s);
+gen_jr(s, cpu_T0);
 break;
 case 3: /* lcall Ev */
 gen_op_ld_v(s, ot, cpu_T1, cpu_A0);
@@ -5014,7 +5014,8 @@ static target_ulong disas_insn(CPUX86State *env, 
DisasContext *s,
   tcg_const_i32(dflag - 1),
   tcg_const_i32(s->pc - s->cs_base));
 }
-gen_eob(s);
+tcg_gen_ld_tl(cpu_tmp4, cpu_env, offsetof(CPUX86State, eip));
+gen_jr(s, cpu_tmp4);
 break;
 case 4: /* jmp Ev */
 if (dflag == MO_16) {
@@ -5022,7 +5023,7 @@ static target_ulong 

[Qemu-devel] [PATCH v6 12/25] tcg/ppc: Implement goto_ptr

2017-05-02 Thread Richard Henderson
Signed-off-by: Richard Henderson 
---
 tcg/ppc/tcg-target.h | 2 +-
 tcg/ppc/tcg-target.inc.c | 7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/tcg/ppc/tcg-target.h b/tcg/ppc/tcg-target.h
index a9aa974..5f4a40a 100644
--- a/tcg/ppc/tcg-target.h
+++ b/tcg/ppc/tcg-target.h
@@ -82,7 +82,7 @@ extern bool have_isa_3_00;
 #define TCG_TARGET_HAS_muls2_i320
 #define TCG_TARGET_HAS_muluh_i321
 #define TCG_TARGET_HAS_mulsh_i321
-#define TCG_TARGET_HAS_goto_ptr 0
+#define TCG_TARGET_HAS_goto_ptr 1
 
 #if TCG_TARGET_REG_BITS == 64
 #define TCG_TARGET_HAS_add2_i32 0
diff --git a/tcg/ppc/tcg-target.inc.c b/tcg/ppc/tcg-target.inc.c
index 64f67d2..8d50f18 100644
--- a/tcg/ppc/tcg-target.inc.c
+++ b/tcg/ppc/tcg-target.inc.c
@@ -1932,6 +1932,7 @@ static void tcg_target_qemu_prologue(TCGContext *s)
 
 /* Epilogue */
 tcg_debug_assert(tb_ret_addr == s->code_ptr);
+s->code_gen_epilogue = tb_ret_addr;
 
 tcg_out_ld(s, TCG_TYPE_PTR, TCG_REG_R0, TCG_REG_R1, FRAME_SIZE+LR_OFFSET);
 for (i = 0; i < ARRAY_SIZE(tcg_target_callee_save_regs); ++i) {
@@ -1986,6 +1987,11 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc, 
const TCGArg *args,
 #endif
 s->tb_jmp_reset_offset[args[0]] = tcg_current_code_size(s);
 break;
+case INDEX_op_goto_ptr:
+tcg_out32(s, MTSPR | RS(args[0]) | CTR);
+tcg_out_movi(s, TCG_TYPE_PTR, TCG_REG_R3, 0);
+tcg_out32(s, BCCTR | BO_ALWAYS);
+break;
 case INDEX_op_br:
 {
 TCGLabel *l = arg_label(args[0]);
@@ -2555,6 +2561,7 @@ static const TCGTargetOpDef ppc_op_defs[] = {
 { INDEX_op_exit_tb, { } },
 { INDEX_op_goto_tb, { } },
 { INDEX_op_br, { } },
+{ INDEX_op_goto_ptr, { "r" } },
 
 { INDEX_op_ld8u_i32, { "r", "r" } },
 { INDEX_op_ld8s_i32, { "r", "r" } },
-- 
2.9.3




[Qemu-devel] [PATCH v6 09/25] target/i386: optimize cross-page direct jumps in softmmu

2017-05-02 Thread Richard Henderson
From: "Emilio G. Cota" 

Instead of unconditionally exiting to the exec loop, use the
gen_jr helper to jump to the target if it is valid.

Perf impact: see next commit's log.

Reviewed-by: Richard Henderson 
Signed-off-by: Emilio G. Cota 
Message-Id: <1493263764-18657-10-git-send-email-c...@braap.org>
Signed-off-by: Richard Henderson 
---
 target/i386/translate.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/i386/translate.c b/target/i386/translate.c
index f0e48dc..ea113fe 100644
--- a/target/i386/translate.c
+++ b/target/i386/translate.c
@@ -2154,9 +2154,9 @@ static inline void gen_goto_tb(DisasContext *s, int 
tb_num, target_ulong eip)
 gen_jmp_im(eip);
 tcg_gen_exit_tb((uintptr_t)s->tb + tb_num);
 } else {
-/* jump to another page: currently not optimized */
+/* jump to another page */
 gen_jmp_im(eip);
-gen_eob(s);
+gen_jr(s, cpu_tmp0);
 }
 }
 
-- 
2.9.3




[Qemu-devel] [PATCH v6 04/25] tcg: Introduce goto_ptr opcode and tcg_gen_lookup_and_goto_ptr

2017-05-02 Thread Richard Henderson
From: "Emilio G. Cota" 

Instead of exporting goto_ptr directly to TCG frontends, export
tcg_gen_lookup_and_goto_ptr(), which calls goto_ptr with the pointer
returned by the lookup_tb_ptr() helper. This is the only use case
we have for goto_ptr and lookup_tb_ptr, so having this function is
very convenient. Furthermore, it trivially allows us to avoid calling
the lookup helper if goto_ptr is not implemented by the backend.

Reviewed-by: Alex Bennée 
Signed-off-by: Emilio G. Cota 
Message-Id: <1493263764-18657-2-git-send-email-c...@braap.org>
Message-Id: <1493263764-18657-3-git-send-email-c...@braap.org>
Message-Id: <1493263764-18657-4-git-send-email-c...@braap.org>
Message-Id: <1493263764-18657-5-git-send-email-c...@braap.org>
[rth: Squashed 4 related commits.]
Signed-off-by: Richard Henderson 
---
 cpu-exec.c   |  6 ++
 include/exec/exec-all.h  |  2 ++
 tcg-runtime.c| 32 
 tcg/README   |  8 
 tcg/aarch64/tcg-target.h |  1 +
 tcg/arm/tcg-target.h |  1 +
 tcg/i386/tcg-target.h|  1 +
 tcg/ia64/tcg-target.h|  1 +
 tcg/mips/tcg-target.h|  1 +
 tcg/ppc/tcg-target.h |  1 +
 tcg/s390/tcg-target.h|  1 +
 tcg/sparc/tcg-target.h   |  1 +
 tcg/tcg-op.c | 13 +
 tcg/tcg-op.h | 11 +++
 tcg/tcg-opc.h|  1 +
 tcg/tcg-runtime.h|  2 ++
 tcg/tcg.c|  5 +
 tcg/tcg.h|  1 +
 tcg/tci/tcg-target.h |  1 +
 19 files changed, 86 insertions(+), 4 deletions(-)

diff --git a/cpu-exec.c b/cpu-exec.c
index 63a56d0..5b181c1 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -309,10 +309,8 @@ static bool tb_cmp(const void *p, const void *d)
 return false;
 }
 
-static TranslationBlock *tb_htable_lookup(CPUState *cpu,
-  target_ulong pc,
-  target_ulong cs_base,
-  uint32_t flags)
+TranslationBlock *tb_htable_lookup(CPUState *cpu, target_ulong pc,
+   target_ulong cs_base, uint32_t flags)
 {
 tb_page_addr_t phys_pc;
 struct tb_desc desc;
diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
index bcde1e6..87ae10b 100644
--- a/include/exec/exec-all.h
+++ b/include/exec/exec-all.h
@@ -368,6 +368,8 @@ struct TranslationBlock {
 void tb_free(TranslationBlock *tb);
 void tb_flush(CPUState *cpu);
 void tb_phys_invalidate(TranslationBlock *tb, tb_page_addr_t page_addr);
+TranslationBlock *tb_htable_lookup(CPUState *cpu, target_ulong pc,
+   target_ulong cs_base, uint32_t flags);
 
 #if defined(USE_DIRECT_JUMP)
 
diff --git a/tcg-runtime.c b/tcg-runtime.c
index 4c60c96..7fa90ce 100644
--- a/tcg-runtime.c
+++ b/tcg-runtime.c
@@ -27,6 +27,9 @@
 #include "exec/helper-proto.h"
 #include "exec/cpu_ldst.h"
 #include "exec/exec-all.h"
+#include "exec/tb-hash.h"
+#include "disas/disas.h"
+#include "exec/log.h"
 
 /* 32-bit helpers */
 
@@ -141,6 +144,35 @@ uint64_t HELPER(ctpop_i64)(uint64_t arg)
 return ctpop64(arg);
 }
 
+void *HELPER(lookup_tb_ptr)(CPUArchState *env, target_ulong addr)
+{
+CPUState *cpu = ENV_GET_CPU(env);
+TranslationBlock *tb;
+target_ulong cs_base, pc;
+uint32_t flags;
+
+tb = atomic_rcu_read(>tb_jmp_cache[tb_jmp_cache_hash_func(addr)]);
+if (likely(tb)) {
+cpu_get_tb_cpu_state(env, , _base, );
+if (likely(tb->pc == addr && tb->cs_base == cs_base &&
+   tb->flags == flags)) {
+goto found;
+}
+tb = tb_htable_lookup(cpu, addr, cs_base, flags);
+if (likely(tb)) {
+atomic_set(>tb_jmp_cache[tb_jmp_cache_hash_func(addr)], tb);
+goto found;
+}
+}
+return tcg_ctx.code_gen_epilogue;
+ found:
+qemu_log_mask_and_addr(CPU_LOG_EXEC, addr,
+   "Chain %p [%d: " TARGET_FMT_lx "] %s\n",
+   tb->tc_ptr, cpu->cpu_index, addr,
+   lookup_symbol(addr));
+return tb->tc_ptr;
+}
+
 void HELPER(exit_atomic)(CPUArchState *env)
 {
 cpu_loop_exit_atomic(ENV_GET_CPU(env), GETPC());
diff --git a/tcg/README b/tcg/README
index a9858c2..bf49e82 100644
--- a/tcg/README
+++ b/tcg/README
@@ -477,6 +477,14 @@ current TB was linked to this TB. Otherwise execute the 
next
 instructions. Only indices 0 and 1 are valid and tcg_gen_goto_tb may be issued
 at most once with each slot index per TB.
 
+* lookup_and_goto_ptr tb_addr
+
+Look up a TB address ('tb_addr') and jump to it if valid. If not valid,
+jump to the TCG epilogue to go back to the exec loop.
+
+This operation is optional. If the TCG backend does not implement the
+goto_ptr opcode, emitting this op is equivalent to emitting exit_tb(0).
+
 * qemu_ld_i32/i64 t0, t1, flags, memidx
 * qemu_st_i32/i64 t0, t1, flags, memidx
 
diff 

[Qemu-devel] [PATCH v6 03/25] qemu/atomic: Loosen restrictions for 64-bit ILP32 hosts

2017-05-02 Thread Richard Henderson
We need to coordinate with the TCG_OVERSIZED_GUEST test in cputlb.c,
and allow 64-bit atomics even though sizeof(void *) == 4.

Reviewed-by: Alex Bennée 
Signed-off-by: Richard Henderson 
---
 include/qemu/atomic.h | 34 ++
 1 file changed, 26 insertions(+), 8 deletions(-)

diff --git a/include/qemu/atomic.h b/include/qemu/atomic.h
index 878fa07..e07c797 100644
--- a/include/qemu/atomic.h
+++ b/include/qemu/atomic.h
@@ -88,6 +88,24 @@
 #define smp_read_barrier_depends()   barrier()
 #endif
 
+/* Sanity check that the size of an atomic operation isn't "overly large".
+ * Despite the fact that e.g. i686 has 64-bit atomic operations, we do not
+ * want to use them because we ought not need them, and this lets us do a
+ * bit of sanity checking that other 32-bit hosts might build.
+ *
+ * That said, we have a problem on 64-bit ILP32 hosts in that in order to
+ * sync with TCG_OVERSIZED_GUEST, this must match TCG_TARGET_REG_BITS.
+ * We'd prefer not want to pull in everything else TCG related, so handle
+ * those few cases by hand.
+ *
+ * Note that x32 is fully detected with __x64_64__ + _ILP32, and that for
+ * Sparc we always force the use of sparcv9 in configure.
+ */
+#if defined(__x86_64__) || defined(__sparc__)
+# define ATOMIC_REG_SIZE  8
+#else
+# define ATOMIC_REG_SIZE  sizeof(void *)
+#endif
 
 /* Weak atomic operations prevent the compiler moving other
  * loads/stores past the atomic operation load/store. However there is
@@ -104,7 +122,7 @@
 
 #define atomic_read(ptr)  \
 ({\
-QEMU_BUILD_BUG_ON(sizeof(*ptr) > sizeof(void *)); \
+QEMU_BUILD_BUG_ON(sizeof(*ptr) > ATOMIC_REG_SIZE); \
 atomic_read__nocheck(ptr);\
 })
 
@@ -112,7 +130,7 @@
 __atomic_store_n(ptr, i, __ATOMIC_RELAXED)
 
 #define atomic_set(ptr, i)  do {  \
-QEMU_BUILD_BUG_ON(sizeof(*ptr) > sizeof(void *)); \
+QEMU_BUILD_BUG_ON(sizeof(*ptr) > ATOMIC_REG_SIZE); \
 atomic_set__nocheck(ptr, i);  \
 } while(0)
 
@@ -130,27 +148,27 @@
 
 #define atomic_rcu_read(ptr)  \
 ({\
-QEMU_BUILD_BUG_ON(sizeof(*ptr) > sizeof(void *)); \
+QEMU_BUILD_BUG_ON(sizeof(*ptr) > ATOMIC_REG_SIZE); \
 typeof_strip_qual(*ptr) _val; \
 atomic_rcu_read__nocheck(ptr, &_val); \
 _val; \
 })
 
 #define atomic_rcu_set(ptr, i) do {   \
-QEMU_BUILD_BUG_ON(sizeof(*ptr) > sizeof(void *)); \
+QEMU_BUILD_BUG_ON(sizeof(*ptr) > ATOMIC_REG_SIZE); \
 __atomic_store_n(ptr, i, __ATOMIC_RELEASE);   \
 } while(0)
 
 #define atomic_load_acquire(ptr)\
 ({  \
-QEMU_BUILD_BUG_ON(sizeof(*ptr) > sizeof(void *));   \
+QEMU_BUILD_BUG_ON(sizeof(*ptr) > ATOMIC_REG_SIZE);  \
 typeof_strip_qual(*ptr) _val;   \
 __atomic_load(ptr, &_val, __ATOMIC_ACQUIRE);\
 _val;   \
 })
 
 #define atomic_store_release(ptr, i)  do {  \
-QEMU_BUILD_BUG_ON(sizeof(*ptr) > sizeof(void *));   \
+QEMU_BUILD_BUG_ON(sizeof(*ptr) > ATOMIC_REG_SIZE);  \
 __atomic_store_n(ptr, i, __ATOMIC_RELEASE); \
 } while(0)
 
@@ -162,7 +180,7 @@
 })
 
 #define atomic_xchg(ptr, i)({   \
-QEMU_BUILD_BUG_ON(sizeof(*ptr) > sizeof(void *));   \
+QEMU_BUILD_BUG_ON(sizeof(*ptr) > ATOMIC_REG_SIZE);  \
 atomic_xchg__nocheck(ptr, i);   \
 })
 
@@ -175,7 +193,7 @@
 })
 
 #define atomic_cmpxchg(ptr, old, new)({ \
-QEMU_BUILD_BUG_ON(sizeof(*ptr) > sizeof(void *));   \
+QEMU_BUILD_BUG_ON(sizeof(*ptr) > ATOMIC_REG_SIZE);  \
 atomic_cmpxchg__nocheck(ptr, old, new); \
 })
 
-- 
2.9.3




[Qemu-devel] [PATCH v6 06/25] target/arm: optimize cross-page direct jumps in softmmu

2017-05-02 Thread Richard Henderson
From: "Emilio G. Cota" 

Instead of unconditionally exiting to the exec loop, use the
lookup_and_goto_ptr helper to jump to the target if it is valid.

Perf impact: see next commit's log.

Reviewed-by: Alex Bennée 
Reviewed-by: Richard Henderson 
Signed-off-by: Emilio G. Cota 
Message-Id: <1493263764-18657-7-git-send-email-c...@braap.org>
Signed-off-by: Richard Henderson 
---
 target/arm/translate.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/target/arm/translate.c b/target/arm/translate.c
index 0b5a0bc..facb52f 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -4153,8 +4153,12 @@ static inline void gen_goto_tb(DisasContext *s, int n, 
target_ulong dest)
 gen_set_pc_im(s, dest);
 tcg_gen_exit_tb((uintptr_t)s->tb + n);
 } else {
+TCGv addr = tcg_temp_new();
+
 gen_set_pc_im(s, dest);
-tcg_gen_exit_tb(0);
+tcg_gen_extu_i32_tl(addr, cpu_R[15]);
+tcg_gen_lookup_and_goto_ptr(addr);
+tcg_temp_free(addr);
 }
 }
 
-- 
2.9.3




[Qemu-devel] [PATCH v6 14/25] tcg/sparc: Implement goto_ptr

2017-05-02 Thread Richard Henderson
Signed-off-by: Richard Henderson 
---
 tcg/sparc/tcg-target.h |  2 +-
 tcg/sparc/tcg-target.inc.c | 11 ++-
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/tcg/sparc/tcg-target.h b/tcg/sparc/tcg-target.h
index 9348ddd..854a0af 100644
--- a/tcg/sparc/tcg-target.h
+++ b/tcg/sparc/tcg-target.h
@@ -123,7 +123,7 @@ extern bool use_vis3_instructions;
 #define TCG_TARGET_HAS_muls2_i321
 #define TCG_TARGET_HAS_muluh_i320
 #define TCG_TARGET_HAS_mulsh_i320
-#define TCG_TARGET_HAS_goto_ptr 0
+#define TCG_TARGET_HAS_goto_ptr 1
 
 #define TCG_TARGET_HAS_extrl_i64_i321
 #define TCG_TARGET_HAS_extrh_i64_i321
diff --git a/tcg/sparc/tcg-target.inc.c b/tcg/sparc/tcg-target.inc.c
index 3785d77..18afce2 100644
--- a/tcg/sparc/tcg-target.inc.c
+++ b/tcg/sparc/tcg-target.inc.c
@@ -1003,7 +1003,11 @@ static void tcg_target_qemu_prologue(TCGContext *s)
 /* delay slot */
 tcg_out_nop(s);
 
-/* No epilogue required.  We issue ret + restore directly in the TB.  */
+/* Epilogue for goto_ptr.  */
+s->code_gen_epilogue = s->code_ptr;
+tcg_out_arithi(s, TCG_REG_G0, TCG_REG_I7, 8, RETURN);
+/* delay slot */
+tcg_out_movi_imm13(s, TCG_REG_O0, 0);
 
 #ifdef CONFIG_SOFTMMU
 build_trampolines(s);
@@ -1288,6 +1292,10 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
 tcg_out_nop(s);
 s->tb_jmp_reset_offset[a0] = tcg_current_code_size(s);
 break;
+case INDEX_op_goto_ptr:
+tcg_out_arithi(s, TCG_REG_G0, a0, 0, JMPL);
+tcg_out_nop(s);
+break;
 case INDEX_op_br:
 tcg_out_bpcc(s, COND_A, BPCC_PT, arg_label(a0));
 tcg_out_nop(s);
@@ -1513,6 +1521,7 @@ static const TCGTargetOpDef sparc_op_defs[] = {
 { INDEX_op_exit_tb, { } },
 { INDEX_op_goto_tb, { } },
 { INDEX_op_br, { } },
+{ INDEX_op_goto_ptr, { "r" } },
 
 { INDEX_op_ld8u_i32, { "r", "r" } },
 { INDEX_op_ld8s_i32, { "r", "r" } },
-- 
2.9.3




[Qemu-devel] [PATCH v6 01/25] target/nios2: Fix 64-bit ilp32 compilation

2017-05-02 Thread Richard Henderson
Avoid a "cast from pointer to integer of different size" warning
by using the proper host type.

Reviewed-by: Alex Bennée 
Signed-off-by: Richard Henderson 
---
 target/nios2/translate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/nios2/translate.c b/target/nios2/translate.c
index cfec479..2f3c2e5 100644
--- a/target/nios2/translate.c
+++ b/target/nios2/translate.c
@@ -164,7 +164,7 @@ static void gen_goto_tb(DisasContext *dc, int n, uint32_t 
dest)
 if (use_goto_tb(dc, dest)) {
 tcg_gen_goto_tb(n);
 tcg_gen_movi_tl(dc->cpu_R[R_PC], dest);
-tcg_gen_exit_tb((tcg_target_long)tb + n);
+tcg_gen_exit_tb((uintptr_t)tb + n);
 } else {
 tcg_gen_movi_tl(dc->cpu_R[R_PC], dest);
 tcg_gen_exit_tb(0);
-- 
2.9.3




[Qemu-devel] [PATCH v6 08/25] target/i386: introduce gen_jr helper to generate lookup_and_goto_ptr

2017-05-02 Thread Richard Henderson
From: "Emilio G. Cota" 

This helper will be used by subsequent changes.

Reviewed-by: Alex Bennée 
Signed-off-by: Emilio G. Cota 
Message-Id: <1493263764-18657-9-git-send-email-c...@braap.org>
Signed-off-by: Richard Henderson 
---
 target/i386/translate.c | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/target/i386/translate.c b/target/i386/translate.c
index 1d1372f..f0e48dc 100644
--- a/target/i386/translate.c
+++ b/target/i386/translate.c
@@ -141,6 +141,7 @@ typedef struct DisasContext {
 } DisasContext;
 
 static void gen_eob(DisasContext *s);
+static void gen_jr(DisasContext *s, TCGv dest);
 static void gen_jmp(DisasContext *s, target_ulong eip);
 static void gen_jmp_tb(DisasContext *s, target_ulong eip, int tb_num);
 static void gen_op(DisasContext *s1, int op, TCGMemOp ot, int d);
@@ -2509,7 +2510,8 @@ static void gen_bnd_jmp(DisasContext *s)
If INHIBIT, set HF_INHIBIT_IRQ_MASK if it isn't already set.
If RECHECK_TF, emit a rechecking helper for #DB, ignoring the state of
S->TF.  This is used by the syscall/sysret insns.  */
-static void gen_eob_worker(DisasContext *s, bool inhibit, bool recheck_tf)
+static void
+do_gen_eob_worker(DisasContext *s, bool inhibit, bool recheck_tf, TCGv jr)
 {
 gen_update_cc_op(s);
 
@@ -2530,12 +2532,27 @@ static void gen_eob_worker(DisasContext *s, bool 
inhibit, bool recheck_tf)
 tcg_gen_exit_tb(0);
 } else if (s->tf) {
 gen_helper_single_step(cpu_env);
+} else if (!TCGV_IS_UNUSED(jr)) {
+TCGv vaddr = tcg_temp_new();
+
+tcg_gen_add_tl(vaddr, jr, cpu_seg_base[R_CS]);
+tcg_gen_lookup_and_goto_ptr(vaddr);
+tcg_temp_free(vaddr);
 } else {
 tcg_gen_exit_tb(0);
 }
 s->is_jmp = DISAS_TB_JUMP;
 }
 
+static inline void
+gen_eob_worker(DisasContext *s, bool inhibit, bool recheck_tf)
+{
+TCGv unused;
+
+TCGV_UNUSED(unused);
+do_gen_eob_worker(s, inhibit, recheck_tf, unused);
+}
+
 /* End of block.
If INHIBIT, set HF_INHIBIT_IRQ_MASK if it isn't already set.  */
 static void gen_eob_inhibit_irq(DisasContext *s, bool inhibit)
@@ -2549,6 +2566,12 @@ static void gen_eob(DisasContext *s)
 gen_eob_worker(s, false, false);
 }
 
+/* Jump to register */
+static void gen_jr(DisasContext *s, TCGv dest)
+{
+do_gen_eob_worker(s, false, false, dest);
+}
+
 /* generate a jump to eip. No segment change must happen before as a
direct call to the next block may occur */
 static void gen_jmp_tb(DisasContext *s, target_ulong eip, int tb_num)
-- 
2.9.3




[Qemu-devel] [PATCH v6 05/25] tcg/i386: implement goto_ptr

2017-05-02 Thread Richard Henderson
From: "Emilio G. Cota" 

Suggested-by: Richard Henderson 
Reviewed-by: Richard Henderson 
Signed-off-by: Emilio G. Cota 
Message-Id: <1493263764-18657-6-git-send-email-c...@braap.org>
[rth: Reuse goto_ptr epilogue for exit_tb 0.]
Signed-off-by: Richard Henderson 
---
 tcg/i386/tcg-target.h |  2 +-
 tcg/i386/tcg-target.inc.c | 24 ++--
 2 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/tcg/i386/tcg-target.h b/tcg/i386/tcg-target.h
index 59d9835..73a15f7 100644
--- a/tcg/i386/tcg-target.h
+++ b/tcg/i386/tcg-target.h
@@ -107,7 +107,7 @@ extern bool have_popcnt;
 #define TCG_TARGET_HAS_muls2_i321
 #define TCG_TARGET_HAS_muluh_i320
 #define TCG_TARGET_HAS_mulsh_i320
-#define TCG_TARGET_HAS_goto_ptr 0
+#define TCG_TARGET_HAS_goto_ptr 1
 
 #if TCG_TARGET_REG_BITS == 64
 #define TCG_TARGET_HAS_extrl_i64_i320
diff --git a/tcg/i386/tcg-target.inc.c b/tcg/i386/tcg-target.inc.c
index 5918008..01e3b4e 100644
--- a/tcg/i386/tcg-target.inc.c
+++ b/tcg/i386/tcg-target.inc.c
@@ -1882,8 +1882,13 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 
 switch (opc) {
 case INDEX_op_exit_tb:
-tcg_out_movi(s, TCG_TYPE_PTR, TCG_REG_EAX, a0);
-tcg_out_jmp(s, tb_ret_addr);
+/* Reuse the zeroing that exists for goto_ptr.  */
+if (a0 == 0) {
+tcg_out_jmp(s, s->code_gen_epilogue);
+} else {
+tcg_out_movi(s, TCG_TYPE_PTR, TCG_REG_EAX, a0);
+tcg_out_jmp(s, tb_ret_addr);
+}
 break;
 case INDEX_op_goto_tb:
 if (s->tb_jmp_insn_offset) {
@@ -1906,6 +1911,10 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 }
 s->tb_jmp_reset_offset[a0] = tcg_current_code_size(s);
 break;
+case INDEX_op_goto_ptr:
+/* jmp to the given host address (could be epilogue) */
+tcg_out_modrm(s, OPC_GRP5, EXT5_JMPN_Ev, a0);
+break;
 case INDEX_op_br:
 tcg_out_jxx(s, JCC_JMP, arg_label(a0), 0);
 break;
@@ -2277,6 +2286,7 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 
 static const TCGTargetOpDef *tcg_target_op_def(TCGOpcode op)
 {
+static const TCGTargetOpDef r = { .args_ct_str = { "r" } };
 static const TCGTargetOpDef ri_r = { .args_ct_str = { "ri", "r" } };
 static const TCGTargetOpDef re_r = { .args_ct_str = { "re", "r" } };
 static const TCGTargetOpDef qi_r = { .args_ct_str = { "qi", "r" } };
@@ -2299,6 +2309,9 @@ static const TCGTargetOpDef *tcg_target_op_def(TCGOpcode 
op)
 = { .args_ct_str = { "L", "L", "L", "L" } };
 
 switch (op) {
+case INDEX_op_goto_ptr:
+return 
+
 case INDEX_op_ld8u_i32:
 case INDEX_op_ld8u_i64:
 case INDEX_op_ld8s_i32:
@@ -2567,6 +2580,13 @@ static void tcg_target_qemu_prologue(TCGContext *s)
 tcg_out_modrm(s, OPC_GRP5, EXT5_JMPN_Ev, tcg_target_call_iarg_regs[1]);
 #endif
 
+/*
+ * Return path for goto_ptr. Set return value to 0, a-la exit_tb,
+ * and fall through to the rest of the epilogue.
+ */
+s->code_gen_epilogue = s->code_ptr;
+tcg_out_movi(s, TCG_TYPE_REG, TCG_REG_EAX, 0);
+
 /* TB epilogue */
 tb_ret_addr = s->code_ptr;
 
-- 
2.9.3




[Qemu-devel] [PATCH v6 00/25] tcg cross-tb optimizations

2017-05-02 Thread Richard Henderson
Changes since v5:
  * MIPS patches from Aurelien.
  * AArch64 patches from Emilio.
  * ARM32 backend support for goto_ptr
  * Alpha frontend patch rewritten; the former patch appears to
drop clock interrupts, not exiting the kernel's idle loop.
I never *really* figured out why, since both patches seem
to annotate the same TBs in the same way.
  * Front end patchs for hppa and s390.


r~


Aurelien Jarno (3):
  tcg/mips: implement goto_ptr
  target/mips: optimize cross-page direct jumps in softmmu
  target/mips: optimize indirect branches

Emilio G. Cota (10):
  tcg: Introduce goto_ptr opcode and tcg_gen_lookup_and_goto_ptr
  tcg/i386: implement goto_ptr
  target/arm: optimize cross-page direct jumps in softmmu
  target/arm: optimize indirect branches
  target/i386: introduce gen_jr helper to generate lookup_and_goto_ptr
  target/i386: optimize cross-page direct jumps in softmmu
  target/i386: optimize indirect branches
  tb-hash: improve tb_jmp_cache hash function in user mode
  target/aarch64: optimize cross-page direct jumps in softmmu
  target/aarch64: optimize indirect branches

Richard Henderson (12):
  target/nios2: Fix 64-bit ilp32 compilation
  tcg/sparc: Use the proper compilation flags for 32-bit
  qemu/atomic: Loosen restrictions for 64-bit ILP32 hosts
  tcg/ppc: Implement goto_ptr
  tcg/aarch64: Implement goto_ptr
  tcg/sparc: Implement goto_ptr
  tcg/s390: Implement goto_ptr
  tcg/arm: Clarify tcg_out_bx for arm4 host
  tcg/arm: Implement goto_ptr
  target/s390: Use tcg_gen_lookup_and_goto_ptr
  target/hppa: Use tcg_gen_lookup_and_goto_ptr
  target/alpha: Use tcg_gen_lookup_and_goto_ptr

 configure|  6 ++---
 cpu-exec.c   |  6 ++---
 include/exec/exec-all.h  |  2 ++
 include/exec/tb-hash.h   | 12 ++
 include/qemu/atomic.h| 34 +---
 target/alpha/translate.c | 54 ++--
 target/arm/translate-a64.c   |  5 ++--
 target/arm/translate.c   | 21 +
 target/arm/translate.h   |  4 
 target/hppa/translate.c  |  8 +++
 target/i386/translate.c  | 43 +++
 target/mips/translate.c  |  4 ++--
 target/nios2/translate.c |  2 +-
 target/s390x/translate.c | 17 ++
 tcg-runtime.c| 32 ++
 tcg/README   |  8 +++
 tcg/aarch64/tcg-target.h |  1 +
 tcg/aarch64/tcg-target.inc.c | 22 --
 tcg/arm/tcg-target.h |  1 +
 tcg/arm/tcg-target.inc.c | 54 +---
 tcg/i386/tcg-target.h|  1 +
 tcg/i386/tcg-target.inc.c| 24 ++--
 tcg/ia64/tcg-target.h|  1 +
 tcg/mips/tcg-target.h|  1 +
 tcg/mips/tcg-target.inc.c| 13 +++
 tcg/ppc/tcg-target.h |  1 +
 tcg/ppc/tcg-target.inc.c |  7 ++
 tcg/s390/tcg-target.h|  1 +
 tcg/s390/tcg-target.inc.c| 24 +---
 tcg/sparc/tcg-target.h   |  1 +
 tcg/sparc/tcg-target.inc.c   | 11 -
 tcg/tcg-op.c | 13 +++
 tcg/tcg-op.h | 11 +
 tcg/tcg-opc.h|  1 +
 tcg/tcg-runtime.h|  2 ++
 tcg/tcg.c|  5 
 tcg/tcg.h|  1 +
 tcg/tci/tcg-target.h |  1 +
 38 files changed, 378 insertions(+), 77 deletions(-)

-- 
2.9.3




[Qemu-devel] [PATCH v6 02/25] tcg/sparc: Use the proper compilation flags for 32-bit

2017-05-02 Thread Richard Henderson
We have required a v9 cpu since 9b9c37c36439ee0452632253dac7a31897f27f70.
However, the flags we were using did not reliably enable v8plus, which
meant that the compiler didn't know it could inline 64-bit atomics.

Reviewed-by: Alex Bennée 
Signed-off-by: Richard Henderson 
---
 configure | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index 48a9370..d404374 100755
--- a/configure
+++ b/configure
@@ -1206,12 +1206,12 @@ case "$cpu" in
LDFLAGS="-m64 $LDFLAGS"
;;
 sparc)
-   LDFLAGS="-m32 $LDFLAGS"
-   CPU_CFLAGS="-m32 -mcpu=ultrasparc"
+   CPU_CFLAGS="-m32 -mv8plus -mcpu=ultrasparc"
+   LDFLAGS="-m32 -mv8plus $LDFLAGS"
;;
 sparc64)
-   LDFLAGS="-m64 $LDFLAGS"
CPU_CFLAGS="-m64 -mcpu=ultrasparc"
+   LDFLAGS="-m64 $LDFLAGS"
;;
 s390)
CPU_CFLAGS="-m31"
-- 
2.9.3




[Qemu-devel] crash in vhost-user-bridge on migration

2017-05-02 Thread Dr. David Alan Gilbert
Hi,
  I've started playing with vhost-user-bridge and have it
basically up and going, but I've just tried migration and
I've got a reliable crash for it; I'm not that sure I've
got it set up right, so suggestions please:

This is with qemu head, on an f26 host running an f25-ish
guest.

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

#0  0x55c414112ce4 in vring_avail_idx (vq=0x55c41582fd68, vq=0x55c41582fd68)
at /home/dgilbert/git/qemu/contrib/libvhost-user/libvhost-user.c:940
No locals.
#1  virtqueue_num_heads (idx=0, vq=0x55c41582fd68, dev=0x55c41582fc20)
at /home/dgilbert/git/qemu/contrib/libvhost-user/libvhost-user.c:960
num_heads = 
#2  vu_queue_get_avail_bytes (dev=0x55c41582fc20, vq=0x55c41582fd68, 
in_bytes=in_bytes@entry=0x7fffd035d7c0, 
out_bytes=out_bytes@entry=0x7fffd035d7c4, 
max_in_bytes=max_in_bytes@entry=0, 
max_out_bytes=max_out_bytes@entry=0) at 
/home/dgilbert/git/qemu/contrib/libvhost-user/libvhost-user.c:1034
idx = 0
total_bufs = 0
in_total = 0
out_total = 0
rc = 
#3  0x55c414112fbd in vu_queue_avail_bytes (dev=, 
vq=, in_bytes=0, out_bytes=0)
at /home/dgilbert/git/qemu/contrib/libvhost-user/libvhost-user.c:1116
in_total = 0
out_total = 0
#4  0x55c4141114da in vubr_backend_recv_cb (sock=, 
ctx=0x55c41582fc20)
at /home/dgilbert/git/qemu/tests/vhost-user-bridge.c:276
vubr = 0x55c41582fc20
dev = 0x55c41582fc20
vq = 0x55c41582fd68
elem = 0x0
mhdr_sg = {{iov_base = 0x0, iov_len = 0} , {iov_base 
= 0x0, iov_len = 140512740079088}, {
   .}

mhdr = {hdr = {flags = 0 '\000', gso_type = 0 '\000', hdr_len = 0, 
gso_size = 0, csum_start = 0, 
csum_offset = 0}, num_buffers = 0}
mhdr_cnt = 0
hdrlen = 0
i = 0
hdr = {flags = 0 '\000', gso_type = 0 '\000', hdr_len = 0, gso_size = 
0, csum_start = 0, csum_offset = 0}
__PRETTY_FUNCTION__ = "vubr_backend_recv_cb"
#5  0x55c414110ad3 in dispatcher_wait (timeout=20, dispr=0x55c4158300b8)
at /home/dgilbert/git/qemu/tests/vhost-user-bridge.c:154
e = 0x55c415830180

That's from the destination bridge; I'm running both on a single
host and that's happening when I just do a :
   migrate_set_speed 1G
   migrate tcp:localhost:

The destination qemu spits out:
qemu-system-x86_64: Failed to set msg fds.
qemu-system-x86_64: vhost VQ 0 ring restore failed: -1: Resource temporarily 
unavailable (11)
qemu-system-x86_64: Failed to set msg fds.
qemu-system-x86_64: vhost VQ 1 ring restore failed: -1: Resource temporarily 
unavailable (11)

but I'm not sure if that's before or after the seg of the bridge.

I've got:
  a) One qemu that just has the -net socket / -net user setup as per the docs - 
but I've got
 two lots of sockets for either side
  b) Two qemus for the guests, teh second with just the -incoming
  c) The two vhost-user-bridge instances - the destination being pointed at the 
second set of sockets.

My test is run by doing:
#!/bin/bash -x
SESS=vhost
tmux -L $SESS new-session -d
tmux -L $SESS set-option -g set-remain-on-exit on
# Start a router using the system qemu
tmux -L $SESS new-window -n router qemu-system-x86_64 -M none -nographic -net 
socket,vlan=0,udp=localhost:,localaddr=localhost: -net 
socket,vlan=0,udp=localhost:4445,localaddr=localhost:5556 -net user,vlan=0
# Start source vhost bridge
tmux -L $SESS new-window -n srcvhostbr ./tests/vhost-user-bridge -u 
/tmp/vubrsrc.sock
tmux -L $SESS new-window -n source "./x86_64-softmmu/qemu-system-x86_64 
-enable-kvm -m 1G -smp 2 -object 
memory-backend-file,id=mem,size=1G,mem-path=/dev/shm,share=on -numa 
node,memdev=mem -mem-prealloc -chardev socket,id=char0,path=/tmp/vubrsrc.sock 
-netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce -device 
virtio-net-pci,netdev=mynet1 /home/vmimages/f25.qcow2 -net none"
# Start dest vhost bridge
tmux -L $SESS new-window -n destvhostbr ./tests/vhost-user-bridge -u 
/tmp/vubrdst.sock -l 127.0.0.1:4445 -r 127.0.0.1:5556
tmux -L $SESS new-window -n dest "./x86_64-softmmu/qemu-system-x86_64 
-enable-kvm -m 1G -smp 2 -object 
memory-backend-file,id=mem,size=1G,mem-path=/dev/shm,share=on -numa 
node,memdev=mem -mem-prealloc -chardev socket,id=char0,path=/tmp/vubrdst.sock 
-netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce -device 
virtio-net-pci,netdev=mynet1 /home/vmimages/f25.qcow2 -net none -incoming 
tcp::"

(I've got a few added printf's so the lines might be off by a few).

Thanks,

Dave
--
Dr. David Alan Gilbert / 

Re: [Qemu-devel] [PATCH] RFC: vmcoreinfo device

2017-05-02 Thread Marc-André Lureau
Hi

On Tue, May 2, 2017 at 11:17 AM Igor Mammedov  wrote:

> On Fri, 28 Apr 2017 14:28:38 +
> Marc-André Lureau  wrote:
>
> > Hi
> >
> > On Fri, Apr 28, 2017 at 6:12 PM Ladi Prosek  wrote:
> >
> > > On Mon, Apr 24, 2017 at 3:03 PM, Marc-André Lureau
> > >  wrote:
> > > > The VM coreinfo (vmcoreinfo) device is an emulated device which
> > > > exposes a 4k memory range to the guest to store various informations
> > > > useful to debug the guest OS. (it is greatly inspired by the VMGENID
> > > > device implementation)
> > > >
> > > > This is an early-boot alternative to the qemu-ga VMDUMP_INFO event
> > > > proposed in "[PATCH 00/21] WIP: dump: add kaslr support".
> > > >
> > > > If deemed more appropriate, we can consider writing to fw_cfg
> directly
> > > > instead of guest memory, now that qemu 2.9 supports it again.
> > > >
> > > > The proof-of-concept kernel module:
> > > > https://github.com/elmarco/vmgenid-test/blob/master/qemuvmci-test.c
> > >
> > > Here's a proof-of-concept Windows driver:
> > >
> > >
> https://github.com/ladipro/kvm-guest-drivers-windows/tree/vmcoreinfo/vmcoreinfo
> > >
> > > I just wanted to be sure that it's possible to evaluate the ADDR
> > > method in Windows.
> > >
> > > From a practical point of view it is unfortunate that this would be a
> > > completely new device. For Windows guests it means another driver
> > > binary and all the overhead associated with deploying it on VMs. Would
> > > it be too crazy to add this functionality to the pvpanic device? The
> > > mechanics could stay the same but it would be done under the existing
> > > ACPI\QEMU0001 device.
> > >
> >
> > pvpanic is under _SB.PCI0.ISA, that could be problematic
> >
> > and _STA is a name field.
> >
> > Someone with more experience with ACPI could tell us if that make sense
> to
> > merge both and how.
> >
> > Can't you handle 2 ACPI devices in the same windows driver instead?
> we use QEMU0001 to reserve IO ports for pvpanic device,
> ASL wise there shouldn't problems with adding _ADDR method to it
>
> but then we probably should fold vmcoreinfo into pvpanic device
> as well (QEMU and linux driver)
>
>
pvpanic is x86-only afaict. While I think vmcoreinfo would work fine with
any acpi-able arch.

I think I would rather modify the windows driver to support both pvpanic &
vmcoreinfo, even if it's not typical for driver to implement several
devices.

>
> > > +Storage Format:
> > > > +---
> > > > +
> > > > +The content is expected to use little-endian format.
> > > > +
> > > > +In order to implement an OVMF "SDT Header Probe Suppressor", the
> > > contents of
> > > > +the vmcoreinfo blob has 40 bytes of padding:
> > > > +
> > > > ++---+
> > > > +| SSDT with OEM Table ID = VMCOREIN |
> > > > ++---+
> > > > +| ...   |   TOP OF PAGE
> > > > +| VCIA dword object |->
> > > +---+
> > > > +| ...   |   | fw-allocated array for
> > > |
> > > > +| _STA method referring to VCIA |   | "etc/vmcoreinfo"
> > > |
> > > > +| ...   |
> > >  +---+
> > > > +| ADDR method referring to VCIA |   |  0: OVMF SDT Header
> probe
> > > |
> > > > +| ...   |   | suppressor
> > > |
> > > > ++---+   | 40: uint32 version
> field
> > > |
> > > > +| 44: info contents
> > >  |
> > > > +| 
> > > |
> > > > +
> > > +---+
> > > > +END OF PAGE
> > > > +
> > > > +Version 0 content:
> > > > +
> > > > + uint64 paddr:
> > > > +  Physical address of the Linux vmcoreinfo ELF note.
> > >
> > > Or physical address of the Windows crash dump header :p
> > >
> >
> > Is there support for Windows crash dump in qemu?
> >
> >
> > > Do we want to have an additional discriminator field to tell what kind
> > > of information was written by the guest or would Windows use a
> > > different version?
> > >
> > >
> > I guess a different version would be ok.
> >
> > Thanks a lot for looking at it!
>
> --
Marc-André Lureau


Re: [Qemu-devel] [PATCH v3 8/8] tpm: Added support for TPM emulator

2017-05-02 Thread Marc-André Lureau
Hi

On Tue, May 2, 2017 at 10:25 PM Patrick Ohly  wrote:

> On Tue, 2017-05-02 at 13:19 -0400, Stefan Berger wrote:
> > On 05/02/2017 01:09 PM, Marc-André Lureau wrote:
> > > On Tue, May 2, 2017 at 8:59 PM Stefan Berger <
> stef...@linux.vnet.ibm.com>
> > > wrote:
> > >
> > >> And who is going to implement that qemu-swtpm? Obviously this
> discussion
> > >> doesn't contribute to progress if nobody is doing that in the end.
> > >>
> > > The same persons who try to push for that emulated TPM code. The
> easiest
> > > approach would be to copy/adapt the swtpm code in qemu, if the licence
> is
> > > compatible. I can help with that if there is a consensus it's a better
> > > approach.
> >
> >
> > It's a matter of time and at least I don't have time for that.
>
> Neither do I, and nor (I believe) does Amarnath. The approach with using
> the existing swtpm project seemed attractive to us exactly because it
> avoids having to write and maintain more than just the glue code between
> the two projects.
>

The main argument is not about having more or less code in qemu to
maintain, but yes this is a concern (although giving up that maintenance to
a seperate project with mostly Stefan-alone isn't a much better
alternative). btw, is the project actually used by something else than
qemu? (I am not talking about developpers/testing). If not, then it makes
sense to make it part of qemu.

But it's mostly a technical reason, to avoid having to rely on a foreign
protocol and project with all the compatibility constrains.

In the end, we may decide to start with a separate project, and change it
in the future if it's problematic (that would break some cases, such as
being able to freely switch the helper). Tbh, I am not so happy with the
code quality of swtpm, and I haven't looked closely at libtpms. Having a
qemu-swtpm as part of qemu would probably help improve it too, and bring a
few more developers for maintainance...


-- 
Marc-André Lureau


Re: [Qemu-devel] [Qemu-ppc] [PATCH 0/5] Add qemu_vga.ndrv MacOS PPC VGA driver from QemuMacDrivers

2017-05-02 Thread Mark Cave-Ayland
On 02/05/17 16:52, Howard Spoelstra wrote:

> Hi,
> 
> I successfully tested this patch set with a build for OSX.
> Installed versions of Mac OS 9.04, 9.1, 9.22, 10.0, 10.1, 10.2, 10.3
> and 10.4 all work. As do three images pulled from running systems with
> 10.2, 10.3, 10.4 installed, including classic.
> 
> Best,
> Howard

Great news - thanks a lot for the comprehensive test coverage!


ATB,

Mark.




Re: [Qemu-devel] [PATCH v3 8/8] tpm: Added support for TPM emulator

2017-05-02 Thread Patrick Ohly
On Tue, 2017-05-02 at 13:19 -0400, Stefan Berger wrote:
> On 05/02/2017 01:09 PM, Marc-André Lureau wrote:
> > On Tue, May 2, 2017 at 8:59 PM Stefan Berger 
> > wrote:
> >
> >> And who is going to implement that qemu-swtpm? Obviously this discussion
> >> doesn't contribute to progress if nobody is doing that in the end.
> >>
> > The same persons who try to push for that emulated TPM code. The easiest
> > approach would be to copy/adapt the swtpm code in qemu, if the licence is
> > compatible. I can help with that if there is a consensus it's a better
> > approach.
> 
> 
> It's a matter of time and at least I don't have time for that.

Neither do I, and nor (I believe) does Amarnath. The approach with using
the existing swtpm project seemed attractive to us exactly because it
avoids having to write and maintain more than just the glue code between
the two projects.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.






Re: [Qemu-devel] cpu_io_recompile, icount, and re-issued instructions

2017-05-02 Thread Michael Eager

On 05/02/2017 12:59 AM, Paolo Bonzini wrote:



On 01/05/2017 03:57, Michael Eager wrote:



I'm seeing incorrect values when there is a write to a memory-mapped I/O
device when icount is set.  What I see happening is that a TB with ~20
instructions is executed which contains a write to the MM I/O address.
When it gets to the io_write routine, can_do_io is false, which results
in a call to cpu_io_recompile.

cpu_io_recompile does what it (sort of) says it is supposed to do: it
builds a new TB with the I/O instruction as the last instruction in the
block, then re-issues the TB.  The problem is that the new TB contains
the instructions before the I/O instruction, so they are executed a
second time.


They shouldn't.  When called from cpu_io_recompile,
cpu_restore_state_from_tb should compute the I/O instruction's target PC
from the host PC (stored in retaddr).

Then what happens is the following:

- cpu_io_recompile generates a new TB ending with the I/O instruction.
This new TB has a hash table conflict with the old TB (same
PC/cs_base/flags) the old TB is implicitly removed

- cpu_io_recompile calls cpu_loop_exit_noexc, which goes back to the
execution loop with updated PC

- because the PC is different, a new TB is looked up for the I/O
instruction's PC.  The TB probably is not there and translation starts
again, this time at the I/O instruction

- the new TB, when executed, causes cpu_io_recompile to fire again.
This is the inefficient part mentioned in cpu_io_recompile

- cpu_io_recompile now compiles a one-instruction TB and goes back to
the execution loop

- finally the execution loop executes the one-instruction TB for the I/O
instruction, then it can go on


Thanks for the explanation.

The old QEMU source base I'm working with predates the refactoring of 
cpu_restore_state
by a couple months (sigh).  It also doesn't have the patches which changed the 
argument
from env to cpu.  I tried to cherry-pick the patches but there are too many 
conflicts.

I patched the old code to do what I suggested: a new TB for the already executed
instructions and a TB for the I/O instruction.  It works and has the small 
advantage
of not requiring a second trip through cpu_io_recompile.  But it will be a merge
conflict when we (eventually) upgrade to more recent QEMU sources.


--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077



Re: [Qemu-devel] [Research] Strato HiDrive as a Dropbox Replacement?

2017-05-02 Thread Michal Suchánek
On Tue, 2 May 2017 15:11:20 +0200
Kai Wagner  wrote:

> On 05/02/2017 03:01 PM, Kai Dupke wrote:
> > On 05/02/2017 02:48 PM, Lenz Grimmer wrote:  
> >> I don't, as none of these services store my data in encrypted form
> >> by default...  
> > Any service you know where this (encryption) is handled properly?  
> https://www.teamdrive.com/en/downloads/ -> Commercial and not open,
> but to answer your questions -> yes.

Presumably anything using Ceph which includes Amazon according to this
article http://searchstorage.techtarget.com/definition/Ceph

Thanks

Michal


pgp1juDp9TyBA.pgp
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH v3 8/8] tpm: Added support for TPM emulator

2017-05-02 Thread Stefan Berger

On 05/02/2017 01:09 PM, Marc-André Lureau wrote:

Hi

On Tue, May 2, 2017 at 8:59 PM Stefan Berger 
wrote:


On 05/02/2017 12:05 PM, Marc-André Lureau wrote:

Hi

On Tue, May 2, 2017 at 3:53 PM Amarnath Valluri <
amarnath.vall...@intel.com> wrote:


This change introduces a new TPM backend driver that can communicate with
swtpm(software TPM emulator) using unix domain socket interface.

Swtpm uses two unix sockets, one for plain TPM commands and responses,
and one
for out-of-band control messages.



Let's not forget to mention the external protocol this backend rely on:
https://github.com/stefanberger/swtpm/wiki/Control-Channel-Specification

The protocol documentation is quite limited.

(I still question the need to rely on a public protocol, and a seperate
helper process project. If we had a qemu-swtpm, we could more easily evolve
the protocol in the future)


And who is going to implement that qemu-swtpm? Obviously this discussion
doesn't contribute to progress if nobody is doing that in the end.


The same persons who try to push for that emulated TPM code. The easiest
approach would be to copy/adapt the swtpm code in qemu, if the licence is
compatible. I can help with that if there is a consensus it's a better
approach.



It's a matter of time and at least I don't have time for that. 
Nevertheless, I would suggest to reach that consensus so that we know 
what will happen to at least 8/8 of this series.





Re: [Qemu-devel] [PATCH v3 8/8] tpm: Added support for TPM emulator

2017-05-02 Thread Marc-André Lureau
Hi

On Tue, May 2, 2017 at 8:59 PM Stefan Berger 
wrote:

> On 05/02/2017 12:05 PM, Marc-André Lureau wrote:
>
> Hi
>
> On Tue, May 2, 2017 at 3:53 PM Amarnath Valluri <
> amarnath.vall...@intel.com> wrote:
>
>> This change introduces a new TPM backend driver that can communicate with
>> swtpm(software TPM emulator) using unix domain socket interface.
>>
>> Swtpm uses two unix sockets, one for plain TPM commands and responses,
>> and one
>> for out-of-band control messages.
>>
>>
> Let's not forget to mention the external protocol this backend rely on:
> https://github.com/stefanberger/swtpm/wiki/Control-Channel-Specification
>
> The protocol documentation is quite limited.
>
> (I still question the need to rely on a public protocol, and a seperate
> helper process project. If we had a qemu-swtpm, we could more easily evolve
> the protocol in the future)
>
>
> And who is going to implement that qemu-swtpm? Obviously this discussion
> doesn't contribute to progress if nobody is doing that in the end.
>

The same persons who try to push for that emulated TPM code. The easiest
approach would be to copy/adapt the swtpm code in qemu, if the licence is
compatible. I can help with that if there is a consensus it's a better
approach.
-- 
Marc-André Lureau


Re: [Qemu-devel] [PATCH 1/1] monitor: increase amount of data for monitor to read

2017-05-02 Thread Denis V. Lunev
On 05/02/2017 07:48 PM, Daniel P. Berrange wrote:
> On Tue, May 02, 2017 at 05:36:30PM +0100, Dr. David Alan Gilbert wrote:
>> * Markus Armbruster (arm...@redhat.com) wrote:
>>> "Denis V. Lunev"  writes:
>>>
 On 05/02/2017 05:43 PM, Markus Armbruster wrote:
> "Denis V. Lunev"  writes:
>
>> Right now QMP and HMP monitors read 1 byte at a time from the socket, 
>> which
>> is very inefficient. With 100+ VMs on the host this easily reasults in
>> a lot of unnecessary system calls and CPU usage in the system.
>>
>> This patch changes the amount of data to read to 4096 bytes, which 
>> matches
>> buffer size on the channel level. Fortunately, monitor protocol is
>> synchronous right now thus we should not face side effects in reality.
> Can you explain briefly why this relies on "synchronous"?  I've spent
> all of two seconds on the question myself...
 Each command is processed in sequence as it appears in the
 channel. The answer to the command is sent and only after that
 next command is processed.
>>> Yes, that's how QMP works.
>>>
 Theoretically tith asynchronous processing we can have some side
 effects due to changed buffer size.
>>> What kind of side effects do you have in mind?
>>>
>>> It's quite possible that this obviously inefficient way to read had some
>>> deep reason back when it was created.  Hmm, git-blame is our friend:
>>>
>>> commit c62313bbdc48f72e93fa8196f2fff96ba35e4e9d
>>> Author: Jan Kiszka 
>>> Date:   Fri Dec 4 14:05:29 2009 +0100
>>>
>>> monitor: Accept input only byte-wise
>>> 
>>> This allows to suspend command interpretation and execution
>>> synchronously, e.g. during migration.
>>> 
>>> Signed-off-by: Jan Kiszka 
>>> Signed-off-by: Anthony Liguori 
>> I don't think I understand why that's a problem; if we read more bytes,
>> we're not going to interpret them and execute them until after the previous
>> command returns are we?
> Actually it sees we might do, due to the way the "migrate" command works
> in HMP when you don't give the '-d' flag.
>
> Most monitors commands will block the caller until they are finished,
> but "migrate" is different. The hmp_migrate() method will return
> immediately, but we call monitor_suspend() to block processing of
> further commands. If another command has already been read off
> the wire though (due to "monitor_read" having a buffer that contains
> multiple commands), we would in fact start processing this command
> despite having suspended the monitor.
>
> This is only a problem, however, if the client app has issued "migrate"
> followed by another command, at the same time without waiting for the
> respond to "migrate". So in practice the only way you'd hit the bug
> is probably if you just cut+paste a big chunk of commands into the
> monitor at once without waiting for completion and one of the commands
> was "migrate" without "-d".
>
> Still, I think we would need to figure out a proper fix for this before
> we could increase the buffer size.
>
> Regards,
> Daniel

There is one thing, which simplifies things a lot.
- suspend_cnt can be increased only from 2 places:
  1) monitor_event(), which is called for real HMP monitor only

  2) monitor_suspend(), which can increment suspend_cnt
  only if mon->rs != NULL, which also means that the
  monitor is specifically configured HMP monitor.

So, we can improve the patch (for now) with the following
tweak:

static int monitor_can_read(void *opaque)
{
Monitor *mon = opaque;
   
if (monitor_is_qmp(mon))
return 4096;   
return (mon->suspend_cnt == 0) ? 1 : 0;
}

This will solve my case completely and does not break any
backward compatibility.

Den




Re: [Qemu-devel] [PATCH 1/1] monitor: increase amount of data for monitor to read

2017-05-02 Thread Dr. David Alan Gilbert
* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Tue, May 02, 2017 at 05:36:30PM +0100, Dr. David Alan Gilbert wrote:
> > * Markus Armbruster (arm...@redhat.com) wrote:
> > > "Denis V. Lunev"  writes:
> > > 
> > > > On 05/02/2017 05:43 PM, Markus Armbruster wrote:
> > > >> "Denis V. Lunev"  writes:
> > > >>
> > > >>> Right now QMP and HMP monitors read 1 byte at a time from the socket, 
> > > >>> which
> > > >>> is very inefficient. With 100+ VMs on the host this easily reasults in
> > > >>> a lot of unnecessary system calls and CPU usage in the system.
> > > >>>
> > > >>> This patch changes the amount of data to read to 4096 bytes, which 
> > > >>> matches
> > > >>> buffer size on the channel level. Fortunately, monitor protocol is
> > > >>> synchronous right now thus we should not face side effects in reality.
> > > >> Can you explain briefly why this relies on "synchronous"?  I've spent
> > > >> all of two seconds on the question myself...
> > > > Each command is processed in sequence as it appears in the
> > > > channel. The answer to the command is sent and only after that
> > > > next command is processed.
> > > 
> > > Yes, that's how QMP works.
> > > 
> > > > Theoretically tith asynchronous processing we can have some side
> > > > effects due to changed buffer size.
> > > 
> > > What kind of side effects do you have in mind?
> > > 
> > > It's quite possible that this obviously inefficient way to read had some
> > > deep reason back when it was created.  Hmm, git-blame is our friend:
> > > 
> > > commit c62313bbdc48f72e93fa8196f2fff96ba35e4e9d
> > > Author: Jan Kiszka 
> > > Date:   Fri Dec 4 14:05:29 2009 +0100
> > > 
> > > monitor: Accept input only byte-wise
> > > 
> > > This allows to suspend command interpretation and execution
> > > synchronously, e.g. during migration.
> > > 
> > > Signed-off-by: Jan Kiszka 
> > > Signed-off-by: Anthony Liguori 
> > 
> > I don't think I understand why that's a problem; if we read more bytes,
> > we're not going to interpret them and execute them until after the previous
> > command returns are we?
> 
> Actually it sees we might do, due to the way the "migrate" command works
> in HMP when you don't give the '-d' flag.
> 
> Most monitors commands will block the caller until they are finished,
> but "migrate" is different. The hmp_migrate() method will return
> immediately, but we call monitor_suspend() to block processing of
> further commands. If another command has already been read off
> the wire though (due to "monitor_read" having a buffer that contains
> multiple commands), we would in fact start processing this command
> despite having suspended the monitor.

Ah OK; yes that's painful.

> This is only a problem, however, if the client app has issued "migrate"
> followed by another command, at the same time without waiting for the
> respond to "migrate". So in practice the only way you'd hit the bug
> is probably if you just cut+paste a big chunk of commands into the
> monitor at once without waiting for completion and one of the commands
> was "migrate" without "-d".

That's probably not unusual for scripts;  doing something like:
  migrate  
  info migrate

isn't that unusual.

> Still, I think we would need to figure out a proper fix for this before
> we could increase the buffer size.

Nod, it's a bit grim.

Dave

> 
> Regards,
> Daniel
> -- 
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK



[Qemu-devel] [PATCH v17 22/23] qemu-iotests: Add test case 153 for image locking

2017-05-02 Thread Fam Zheng
Signed-off-by: Fam Zheng 
---
 tests/qemu-iotests/153 | 233 +++
 tests/qemu-iotests/153.out | 390 +
 tests/qemu-iotests/group   |   1 +
 3 files changed, 624 insertions(+)
 create mode 100755 tests/qemu-iotests/153
 create mode 100644 tests/qemu-iotests/153.out

diff --git a/tests/qemu-iotests/153 b/tests/qemu-iotests/153
new file mode 100755
index 000..0b45d78
--- /dev/null
+++ b/tests/qemu-iotests/153
@@ -0,0 +1,233 @@
+#!/bin/bash
+#
+# Test image locking
+#
+# Copyright 2016, 2017 Red Hat, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+#
+
+# creator
+owner=f...@redhat.com
+
+seq="$(basename $0)"
+echo "QA output created by $seq"
+
+here="$PWD"
+tmp=/tmp/$$
+status=1   # failure is the default!
+
+_cleanup()
+{
+_cleanup_test_img
+rm -f "${TEST_IMG}.base"
+rm -f "${TEST_IMG}.convert"
+rm -f "${TEST_IMG}.a"
+rm -f "${TEST_IMG}.b"
+rm -f "${TEST_IMG}.lnk"
+}
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+. ./common.qemu
+
+size=32M
+
+_check_ofd()
+{
+_make_test_img $size >/dev/null
+if $QEMU_IMG_PROG info --image-opts 
"driver=file,locking=on,filename=$TEST_IMG" 2>&1 |
+grep -q 'falling back to POSIX file'; then
+return 1
+else
+return 0
+fi
+}
+
+_check_ofd || _notrun "OFD lock not available"
+
+_supported_fmt qcow2
+_supported_proto file
+_supported_os Linux
+
+_run_cmd()
+{
+echo
+(echo "$@"; "$@" 2>&1 1>/dev/null) | _filter_testdir
+}
+
+function _do_run_qemu()
+{
+(
+if ! test -t 0; then
+while read cmd; do
+echo $cmd
+done
+fi
+echo quit
+) | $QEMU -nographic -monitor stdio -serial none "$@" 1>/dev/null
+}
+
+function _run_qemu_with_images()
+{
+_do_run_qemu \
+$(for i in $@; do echo "-drive if=none,file=$i"; done) 2>&1 \
+| _filter_testdir | _filter_qemu
+}
+
+echo "== readonly=off,force-share=on should be rejected =="
+_run_qemu_with_images null-co://,readonly=off,force-share=on
+
+for opts1 in "" "read-only=on" "read-only=on,force-share=on"; do
+echo
+echo "== Creating base image =="
+TEST_IMG="${TEST_IMG}.base" _make_test_img $size
+
+echo
+echo "== Creating test image =="
+$QEMU_IMG create -f $IMGFMT "${TEST_IMG}" -b ${TEST_IMG}.base | 
_filter_img_create
+
+echo
+echo "== Launching QEMU, opts: '$opts1' =="
+_launch_qemu -drive file="${TEST_IMG}",if=none,$opts1
+h=$QEMU_HANDLE
+
+for opts2 in "" "read-only=on" "read-only=on,force-share=on"; do
+echo
+echo "== Launching another QEMU, opts: '$opts2' =="
+echo "quit" | \
+$QEMU -nographic -monitor stdio \
+-drive file="${TEST_IMG}",if=none,$opts2 2>&1 1>/dev/null | \
+_filter_testdir | _filter_qemu
+done
+
+for L in "" "-U"; do
+
+echo
+echo "== Running utility commands $L =="
+_run_cmd $QEMU_IO $L -c "read 0 512" "${TEST_IMG}"
+_run_cmd $QEMU_IO $L -r -c "read 0 512" "${TEST_IMG}"
+_run_cmd $QEMU_IO -c "open $L ${TEST_IMG}" -c "read 0 512"
+_run_cmd $QEMU_IO -c "open -r $L ${TEST_IMG}" -c "read 0 512"
+_run_cmd $QEMU_IMG info$L "${TEST_IMG}"
+_run_cmd $QEMU_IMG check   $L "${TEST_IMG}"
+_run_cmd $QEMU_IMG compare $L "${TEST_IMG}" "${TEST_IMG}"
+_run_cmd $QEMU_IMG map $L "${TEST_IMG}"
+_run_cmd $QEMU_IMG amend -o "" $L "${TEST_IMG}"
+_run_cmd $QEMU_IMG commit  $L "${TEST_IMG}"
+_run_cmd $QEMU_IMG resize  $L "${TEST_IMG}" $size
+_run_cmd $QEMU_IMG rebase  $L "${TEST_IMG}" -b "${TEST_IMG}.base"
+_run_cmd $QEMU_IMG snapshot -l $L "${TEST_IMG}"
+_run_cmd $QEMU_IMG convert $L "${TEST_IMG}" "${TEST_IMG}.convert"
+_run_cmd $QEMU_IMG dd  $L if="${TEST_IMG}" 
of="${TEST_IMG}.convert" bs=512 count=1
+_run_cmd $QEMU_IMG bench   $L -c 1 "${TEST_IMG}"
+_run_cmd $QEMU_IMG bench   $L -w -c 1 "${TEST_IMG}"
+done
+_send_qemu_cmd $h "{ 'execute': 'quit', }" ""
+echo
+echo "Round done"
+_cleanup_qemu
+done
+
+for opt1 in $test_opts; do
+for opt2 in $test_opts; do
+echo
+echo "== 

Re: [Qemu-devel] [PATCH v3 8/8] tpm: Added support for TPM emulator

2017-05-02 Thread Stefan Berger

On 05/02/2017 12:05 PM, Marc-André Lureau wrote:

Hi

On Tue, May 2, 2017 at 3:53 PM Amarnath Valluri 
> wrote:


This change introduces a new TPM backend driver that can
communicate with
swtpm(software TPM emulator) using unix domain socket interface.

Swtpm uses two unix sockets, one for plain TPM commands and
responses, and one
for out-of-band control messages.


Let's not forget to mention the external protocol this backend rely on:
https://github.com/stefanberger/swtpm/wiki/Control-Channel-Specification

The protocol documentation is quite limited.

(I still question the need to rely on a public protocol, and a 
seperate helper process project. If we had a qemu-swtpm, we could more 
easily evolve the protocol in the future)


And who is going to implement that qemu-swtpm? Obviously this discussion 
doesn't contribute to progress if nobody is doing that in the end.


Re: [Qemu-devel] Writing a C library to generate qemu command lines and configuration files

2017-05-02 Thread Markus Armbruster
Paolo Bonzini  writes:

> On 02/05/2017 16:59, Richard W.M. Jones wrote:
>>> To answer your question: you have to double comma after '=', or else it
>>> terminates the value.  There is no other quoting.
>>
>> Hmm, is that really right?

I should avoid absolutes when it comes to QemuOpts...

>> It seems to me that any comma must be
>> doubled.  For example:
>> 
>> $ qemu-system-x86_64 -name foo,bar -writeconfig - -hda die
>> qemu-system-x86_64: -name foo,bar: Invalid parameter 'bar'
>
> That's because, as you found out, "-name" is not a simple option but a
> compound one; "-name foo" is short for "-name guest=foo" (compare
> "-device e1000").
>
> The grammar mentioned in util/keyval.c says that you have to double
> comma in a value, *and* comma is completely invalid in a key.
>
> If you have '=', you have to double commas after it and cannot use it
> before.
>
> If you have no '=' at all, then you have to double comma too.

Yes.  My description wasn't precise enough, sorry.

Please take note that the grammar in util/keyval.c does *not* produce
the exact QemuOpts language.  It's close, but it doesn't reproduce all
corner cases.  Anything it does produce should have the same meaning in
QemuOpts.

> Paolo
>
>> $ qemu-system-x86_64 -name foo,,bar -writeconfig - -hda die
>> # qemu config file
>> 
>> [name]
>>   guest = "foo,bar"



Re: [Qemu-devel] [PATCH v5 10/10] test-qga: Actually test 0xff sync bytes

2017-05-02 Thread Michael Roth
Quoting Michael Roth (2017-05-02 11:46:36)
> Quoting Eric Blake (2017-04-27 16:58:21)
> > Commit 62c39b3 introduced test-qga, and at face value, appears
> > to be testing the 'guest-sync' behavior that is recommended for
> > guests in sending 0xff to QGA to force the parser to reset.  But
> > this aspect of the test has never actually done anything: the
> > qmp_fd() call chain converts its string argument into QObject,
> > then converts that QObject back to the actual string that is
> > sent over the wire - and the conversion process silently drops
> > the 0xff byte from the string sent to QGA, thus never resetting
> > the QGA parser.
> > 
> > An upcoming patch will get rid of the wasteful round trip
> > through QObject, at which point the string in test-qga will be
> > directly sent over the wire.
> > 
> > But fixing qmp_fd() to actually send 0xff over the wire is not
> > all we have to do - the actual QMP parser loudly complains that
> > 0xff is not valid JSON, and sends an error message _prior_ to
> > actually parsing the 'guest-sync' or 'guest-sync-delimited'
> > command.  With 'guest-sync', we cannot easily tell if this error
> > message is a result of our command - which is WHY we invented
> > the 'guest-sync-delimited' command.  So for the testsuite, fix
> > things to only check 0xff behavior on 'guest-sync-delimited',
> > and to loop until we've consumed all garbage prior to the
> > requested delimiter, which matches the documented actions that
> > a real QGA client is supposed to do.
> 
> The full re-sync sequence is actually to perform that process,
> check if the response matches the client-provided sync token,
> and then repeat the procedure if it doesn't (in the odd case
> that a previous client initiated a guest-sync-delimited
> sequence and never consumed the response). The current
> implementation only performs one iteration so it's not quite
> a full implementation of the documentation procedure.

Well, to be more accurate it's a full implementation of the
documented procedure, it's just that the procedure isn't
fully documented properly. I'll send a patch to address that.

> 
> For the immediate purpose of improving the handling to deal
> with the 0xFF-generated error the patch seems sound though,
> maybe just something worth noting in the commit msg or
> comments so that we might eventually test the full procedure.
> 
> In any case:
> 
> Reviewed-by: Michael Roth 
> 
> > 
> > Ideally, we'd fix the QGA JSON parser to silently ignore 0xff
> > rather than sending an error message back, at which point we
> > could enhance this test for 'guest-sync' as well as for
> > 'guest-sync-delimited'.  But for the sake of this patch, our
> > testing of 'guest-sync' is no worse than it was pre-patch,
> > because we have never been sending 0xff over the wire in the
> > first place.
> > 
> > Signed-off-by: Eric Blake 
> > Reviewed-by: Markus Armbruster 
> > 
> > ---
> > v5: add R-b
> > v4: no change
> > v3: use inline \xff byte rather than %c, add comment
> > ---
> >  tests/libqtest.c |  8 
> >  tests/test-qga.c | 34 +++---
> >  2 files changed, 35 insertions(+), 7 deletions(-)
> > 
> > diff --git a/tests/libqtest.c b/tests/libqtest.c
> > index 512c150..84ecbd2 100644
> > --- a/tests/libqtest.c
> > +++ b/tests/libqtest.c
> > @@ -446,6 +446,14 @@ void qmp_fd_sendv(int fd, const char *fmt, va_list ap)
> >  va_list ap_copy;
> >  QObject *qobj;
> > 
> > +/* qobject_from_jsonv() silently eats leading 0xff as invalid
> > + * JSON, but we want to test sending them over the wire to force
> > + * resyncs */
> > +if (*fmt == '\377') {
> > +socket_send(fd, fmt, 1);
> > +fmt++;
> > +}
> > +
> >  /* Going through qobject ensures we escape strings properly.
> >   * This seemingly unnecessary copy is required in case va_list
> >   * is an array type.
> > diff --git a/tests/test-qga.c b/tests/test-qga.c
> > index c780f00..438c2e7 100644
> > --- a/tests/test-qga.c
> > +++ b/tests/test-qga.c
> > @@ -146,14 +146,23 @@ static void test_qga_sync_delimited(gconstpointer fix)
> >  QDict *ret;
> >  gchar *cmd;
> > 
> > -cmd = g_strdup_printf("%c{'execute': 'guest-sync-delimited',"
> > -  " 'arguments': {'id': %u } }", 0xff, r);
> > +cmd = g_strdup_printf("\xff{'execute': 'guest-sync-delimited',"
> > +  " 'arguments': {'id': %u } }", r);
> >  qmp_fd_send(fixture->fd, cmd);
> >  g_free(cmd);
> > 
> > -v = read(fixture->fd, , 1);
> > -g_assert_cmpint(v, ==, 1);
> > -g_assert_cmpint(c, ==, 0xff);
> > +/*
> > + * Read and ignore garbage until resynchronized.
> > + *
> > + * TODO: The server shouldn't emit so much garbage (among other
> > + * things, it loudly complains about the client's \xff being
> > + * invalid JSON, even though it is a documented part of the
> > + 

[Qemu-devel] [PATCH v17 21/23] file-posix: Add image locking to perm operations

2017-05-02 Thread Fam Zheng
This extends the permission bits of op blocker API to external using
Linux OFD locks.

Each permission in @perm and @shared_perm is represented by a locked
byte in the image file.  Requesting a permission in @perm is translated
to a shared lock of the corresponding byte; rejecting to share the same
permission is translated to a shared lock of a separate byte. With that,
we use 2x number of bytes of distinct permission types.

virtlockd in libvirt locks the first byte, so we do locking from a
higher offset.

Suggested-by: Kevin Wolf 
Signed-off-by: Fam Zheng 
---
 block/file-posix.c | 276 -
 1 file changed, 275 insertions(+), 1 deletion(-)

diff --git a/block/file-posix.c b/block/file-posix.c
index 261563d..f1f924b 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -129,12 +129,23 @@ do { \
 
 #define MAX_BLOCKSIZE  4096
 
+/* Posix file locking bytes. Libvirt takes byte 0, we start from higher bytes,
+ * leaving a few more bytes for its future use. */
+#define RAW_LOCK_PERM_BASE 100
+#define RAW_LOCK_SHARED_BASE   200
+
 typedef struct BDRVRawState {
 int fd;
+int lock_fd;
+bool use_lock;
 int type;
 int open_flags;
 size_t buf_align;
 
+/* The current permissions. */
+uint64_t perm;
+uint64_t shared_perm;
+
 #ifdef CONFIG_XFS
 bool is_xfs:1;
 #endif
@@ -411,6 +422,7 @@ static int raw_open_common(BlockDriverState *bs, QDict 
*options,
 BlockdevAioOptions aio, aio_default;
 int fd, ret;
 struct stat st;
+OnOffAuto locking;
 
 opts = qemu_opts_create(_runtime_opts, NULL, 0, _abort);
 qemu_opts_absorb_qdict(opts, options, _err);
@@ -440,6 +452,37 @@ static int raw_open_common(BlockDriverState *bs, QDict 
*options,
 }
 s->use_linux_aio = (aio == BLOCKDEV_AIO_OPTIONS_NATIVE);
 
+locking = qapi_enum_parse(OnOffAuto_lookup, qemu_opt_get(opts, "locking"),
+  ON_OFF_AUTO__MAX, ON_OFF_AUTO_AUTO, _err);
+if (local_err) {
+error_propagate(errp, local_err);
+ret = -EINVAL;
+goto fail;
+}
+switch (locking) {
+case ON_OFF_AUTO_ON:
+s->use_lock = true;
+#ifndef F_OFD_SETLK
+fprintf(stderr,
+"File lock requested but OFD locking syscall is unavailable, "
+"falling back to POSIX file locks.\n"
+"Due to the implementation, locks can be lost 
unexpectedly.\n");
+#endif
+break;
+case ON_OFF_AUTO_OFF:
+s->use_lock = false;
+break;
+case ON_OFF_AUTO_AUTO:
+#ifdef F_OFD_SETLK
+s->use_lock = true;
+#else
+s->use_lock = false;
+#endif
+break;
+default:
+abort();
+}
+
 s->open_flags = open_flags;
 raw_parse_flags(bdrv_flags, >open_flags);
 
@@ -455,6 +498,21 @@ static int raw_open_common(BlockDriverState *bs, QDict 
*options,
 }
 s->fd = fd;
 
+s->lock_fd = -1;
+if (s->use_lock) {
+fd = qemu_open(filename, s->open_flags);
+if (fd < 0) {
+ret = -errno;
+error_setg_errno(errp, errno, "Could not open '%s' for locking",
+ filename);
+qemu_close(s->fd);
+goto fail;
+}
+s->lock_fd = fd;
+}
+s->perm = 0;
+s->shared_perm = BLK_PERM_ALL;
+
 #ifdef CONFIG_LINUX_AIO
  /* Currently Linux does AIO only for files opened with O_DIRECT */
 if (s->use_linux_aio && !(s->open_flags & O_DIRECT)) {
@@ -542,6 +600,161 @@ static int raw_open(BlockDriverState *bs, QDict *options, 
int flags,
 return raw_open_common(bs, options, flags, 0, errp);
 }
 
+typedef enum {
+RAW_PL_PREPARE,
+RAW_PL_COMMIT,
+RAW_PL_ABORT,
+} RawPermLockOp;
+
+#define PERM_FOREACH(i) \
+for ((i) = 0; (1ULL << (i)) <= BLK_PERM_ALL; i++)
+
+/* Lock bytes indicated by @perm_lock_bits and @shared_perm_lock_bits in the
+ * file; if @unlock == true, also unlock the unneeded bytes.
+ * @shared_perm_lock_bits is the mask of all permissions that are NOT shared.
+ */
+static int raw_apply_lock_bytes(BDRVRawState *s,
+uint64_t perm_lock_bits,
+uint64_t shared_perm_lock_bits,
+bool unlock, Error **errp)
+{
+int ret;
+int i;
+
+PERM_FOREACH(i) {
+int off = RAW_LOCK_PERM_BASE + i;
+if (perm_lock_bits & (1ULL << i)) {
+ret = qemu_lock_fd(s->lock_fd, off, 1, false);
+if (ret) {
+error_setg(errp, "Failed to lock byte %d", off);
+return ret;
+}
+} else if (unlock) {
+ret = qemu_unlock_fd(s->lock_fd, off, 1);
+if (ret) {
+error_setg(errp, "Failed to unlock byte %d", off);
+return ret;
+}
+}
+}
+PERM_FOREACH(i) {
+int off = RAW_LOCK_SHARED_BASE + i;
+

Re: [Qemu-devel] [PATCH 1/1] monitor: increase amount of data for monitor to read

2017-05-02 Thread Daniel P. Berrange
On Tue, May 02, 2017 at 05:36:30PM +0100, Dr. David Alan Gilbert wrote:
> * Markus Armbruster (arm...@redhat.com) wrote:
> > "Denis V. Lunev"  writes:
> > 
> > > On 05/02/2017 05:43 PM, Markus Armbruster wrote:
> > >> "Denis V. Lunev"  writes:
> > >>
> > >>> Right now QMP and HMP monitors read 1 byte at a time from the socket, 
> > >>> which
> > >>> is very inefficient. With 100+ VMs on the host this easily reasults in
> > >>> a lot of unnecessary system calls and CPU usage in the system.
> > >>>
> > >>> This patch changes the amount of data to read to 4096 bytes, which 
> > >>> matches
> > >>> buffer size on the channel level. Fortunately, monitor protocol is
> > >>> synchronous right now thus we should not face side effects in reality.
> > >> Can you explain briefly why this relies on "synchronous"?  I've spent
> > >> all of two seconds on the question myself...
> > > Each command is processed in sequence as it appears in the
> > > channel. The answer to the command is sent and only after that
> > > next command is processed.
> > 
> > Yes, that's how QMP works.
> > 
> > > Theoretically tith asynchronous processing we can have some side
> > > effects due to changed buffer size.
> > 
> > What kind of side effects do you have in mind?
> > 
> > It's quite possible that this obviously inefficient way to read had some
> > deep reason back when it was created.  Hmm, git-blame is our friend:
> > 
> > commit c62313bbdc48f72e93fa8196f2fff96ba35e4e9d
> > Author: Jan Kiszka 
> > Date:   Fri Dec 4 14:05:29 2009 +0100
> > 
> > monitor: Accept input only byte-wise
> > 
> > This allows to suspend command interpretation and execution
> > synchronously, e.g. during migration.
> > 
> > Signed-off-by: Jan Kiszka 
> > Signed-off-by: Anthony Liguori 
> 
> I don't think I understand why that's a problem; if we read more bytes,
> we're not going to interpret them and execute them until after the previous
> command returns are we?

Actually it sees we might do, due to the way the "migrate" command works
in HMP when you don't give the '-d' flag.

Most monitors commands will block the caller until they are finished,
but "migrate" is different. The hmp_migrate() method will return
immediately, but we call monitor_suspend() to block processing of
further commands. If another command has already been read off
the wire though (due to "monitor_read" having a buffer that contains
multiple commands), we would in fact start processing this command
despite having suspended the monitor.

This is only a problem, however, if the client app has issued "migrate"
followed by another command, at the same time without waiting for the
respond to "migrate". So in practice the only way you'd hit the bug
is probably if you just cut+paste a big chunk of commands into the
monitor at once without waiting for completion and one of the commands
was "migrate" without "-d".

Still, I think we would need to figure out a proper fix for this before
we could increase the buffer size.

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



[Qemu-devel] [PATCH v17 18/23] block: Reuse bs as backing hd for drive-backup sync=none

2017-05-02 Thread Fam Zheng
Opening the backing image for the second time is bad, especially here
when it is also in use as the active image as the source. The
drive-backup job itself doesn't read from target->backing for COW,
instead it gets data from the write notifier, so it's not a big problem.
However, exporting the target to NBD etc. won't work, because of the
likely stale metadata cache.

Use BDRV_O_NO_BACKING in this case and manually set up the backing
BdrvChild.

Cc: qemu-sta...@nongnu.org
Signed-off-by: Fam Zheng 
---
 blockdev.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/blockdev.c b/blockdev.c
index 4d8cded..654a880 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -3155,6 +3155,7 @@ static BlockJob *do_drive_backup(DriveBackup *backup, 
BlockJobTxn *txn,
 Error *local_err = NULL;
 int flags;
 int64_t size;
+bool set_backing_hd = false;
 
 if (!backup->has_speed) {
 backup->speed = 0;
@@ -3205,6 +3206,8 @@ static BlockJob *do_drive_backup(DriveBackup *backup, 
BlockJobTxn *txn,
 }
 if (backup->sync == MIRROR_SYNC_MODE_NONE) {
 source = bs;
+flags |= BDRV_O_NO_BACKING;
+set_backing_hd = true;
 }
 
 size = bdrv_getlength(bs);
@@ -3231,7 +3234,9 @@ static BlockJob *do_drive_backup(DriveBackup *backup, 
BlockJobTxn *txn,
 }
 
 if (backup->format) {
-options = qdict_new();
+if (!options) {
+options = qdict_new();
+}
 qdict_put(options, "driver", qstring_from_str(backup->format));
 }
 
@@ -3242,6 +3247,14 @@ static BlockJob *do_drive_backup(DriveBackup *backup, 
BlockJobTxn *txn,
 
 bdrv_set_aio_context(target_bs, aio_context);
 
+if (set_backing_hd) {
+bdrv_set_backing_hd(target_bs, source, _err);
+if (local_err) {
+bdrv_unref(target_bs);
+goto out;
+}
+}
+
 if (backup->has_bitmap) {
 bmap = bdrv_find_dirty_bitmap(bs, backup->bitmap);
 if (!bmap) {
-- 
2.9.3




Re: [Qemu-devel] [PATCH v17 18/23] block: Reuse bs as backing hd for drive-backup sync=none

2017-05-02 Thread Fam Zheng
On Wed, 05/03 00:35, Fam Zheng wrote:
> Opening the backing image for the second time is bad, especially here
> when it is also in use as the active image as the source. The
> drive-backup job itself doesn't read from target->backing for COW,
> instead it gets data from the write notifier, so it's not a big problem.
> However, exporting the target to NBD etc. won't work, because of the
> likely stale metadata cache.
> 
> Use BDRV_O_NO_BACKING in this case and manually set up the backing
> BdrvChild.
> 
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Fam Zheng 

Actually Cc qemu-stable. (git-publish does unified Cc for each patch in a whole
series, hence the noise. Sorry.)

Fam



[Qemu-devel] [PATCH v17 17/23] tests: Disable image lock in test-replication

2017-05-02 Thread Fam Zheng
The COLO block replication architecture requires one disk to be shared
between primary and secondary, in the test both processes use posix file
protocol (instead of over NBD) so it is affected by image locking.
Disable the lock.

Signed-off-by: Fam Zheng 
---
 tests/test-replication.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tests/test-replication.c b/tests/test-replication.c
index 3016c6f..cebeb79 100644
--- a/tests/test-replication.c
+++ b/tests/test-replication.c
@@ -179,7 +179,8 @@ static BlockBackend *start_primary(void)
 char *cmdline;
 
 cmdline = g_strdup_printf("driver=replication,mode=primary,node-name=xxx,"
-  "file.driver=qcow2,file.file.filename=%s"
+  "file.driver=qcow2,file.file.filename=%s,"
+  "file.file.locking=off"
   , p_local_disk);
 opts = qemu_opts_parse_noisily(_drive_opts, cmdline, false);
 g_free(cmdline);
@@ -310,7 +311,9 @@ static BlockBackend *start_secondary(void)
 Error *local_err = NULL;
 
 /* add s_local_disk and forge S_LOCAL_DISK_ID */
-cmdline = g_strdup_printf("file.filename=%s,driver=qcow2", s_local_disk);
+cmdline = g_strdup_printf("file.filename=%s,driver=qcow2,"
+  "file.locking=off",
+  s_local_disk);
 opts = qemu_opts_parse_noisily(_drive_opts, cmdline, false);
 g_free(cmdline);
 
@@ -331,8 +334,10 @@ static BlockBackend *start_secondary(void)
 /* add S_(ACTIVE/HIDDEN)_DISK and forge S_ID */
 cmdline = g_strdup_printf("driver=replication,mode=secondary,top-id=%s,"
   "file.driver=qcow2,file.file.filename=%s,"
+  "file.file.locking=off,"
   "file.backing.driver=qcow2,"
   "file.backing.file.filename=%s,"
+  "file.backing.file.locking=off,"
   "file.backing.backing=%s"
   , S_ID, s_active_disk, s_hidden_disk
   , S_LOCAL_DISK_ID);
-- 
2.9.3




Re: [Qemu-devel] [PATCH v5 10/10] test-qga: Actually test 0xff sync bytes

2017-05-02 Thread Michael Roth
Quoting Eric Blake (2017-04-27 16:58:21)
> Commit 62c39b3 introduced test-qga, and at face value, appears
> to be testing the 'guest-sync' behavior that is recommended for
> guests in sending 0xff to QGA to force the parser to reset.  But
> this aspect of the test has never actually done anything: the
> qmp_fd() call chain converts its string argument into QObject,
> then converts that QObject back to the actual string that is
> sent over the wire - and the conversion process silently drops
> the 0xff byte from the string sent to QGA, thus never resetting
> the QGA parser.
> 
> An upcoming patch will get rid of the wasteful round trip
> through QObject, at which point the string in test-qga will be
> directly sent over the wire.
> 
> But fixing qmp_fd() to actually send 0xff over the wire is not
> all we have to do - the actual QMP parser loudly complains that
> 0xff is not valid JSON, and sends an error message _prior_ to
> actually parsing the 'guest-sync' or 'guest-sync-delimited'
> command.  With 'guest-sync', we cannot easily tell if this error
> message is a result of our command - which is WHY we invented
> the 'guest-sync-delimited' command.  So for the testsuite, fix
> things to only check 0xff behavior on 'guest-sync-delimited',
> and to loop until we've consumed all garbage prior to the
> requested delimiter, which matches the documented actions that
> a real QGA client is supposed to do.

The full re-sync sequence is actually to perform that process,
check if the response matches the client-provided sync token,
and then repeat the procedure if it doesn't (in the odd case
that a previous client initiated a guest-sync-delimited
sequence and never consumed the response). The current
implementation only performs one iteration so it's not quite
a full implementation of the documentation procedure.

For the immediate purpose of improving the handling to deal
with the 0xFF-generated error the patch seems sound though,
maybe just something worth noting in the commit msg or
comments so that we might eventually test the full procedure.

In any case:

Reviewed-by: Michael Roth 

> 
> Ideally, we'd fix the QGA JSON parser to silently ignore 0xff
> rather than sending an error message back, at which point we
> could enhance this test for 'guest-sync' as well as for
> 'guest-sync-delimited'.  But for the sake of this patch, our
> testing of 'guest-sync' is no worse than it was pre-patch,
> because we have never been sending 0xff over the wire in the
> first place.
> 
> Signed-off-by: Eric Blake 
> Reviewed-by: Markus Armbruster 
> 
> ---
> v5: add R-b
> v4: no change
> v3: use inline \xff byte rather than %c, add comment
> ---
>  tests/libqtest.c |  8 
>  tests/test-qga.c | 34 +++---
>  2 files changed, 35 insertions(+), 7 deletions(-)
> 
> diff --git a/tests/libqtest.c b/tests/libqtest.c
> index 512c150..84ecbd2 100644
> --- a/tests/libqtest.c
> +++ b/tests/libqtest.c
> @@ -446,6 +446,14 @@ void qmp_fd_sendv(int fd, const char *fmt, va_list ap)
>  va_list ap_copy;
>  QObject *qobj;
> 
> +/* qobject_from_jsonv() silently eats leading 0xff as invalid
> + * JSON, but we want to test sending them over the wire to force
> + * resyncs */
> +if (*fmt == '\377') {
> +socket_send(fd, fmt, 1);
> +fmt++;
> +}
> +
>  /* Going through qobject ensures we escape strings properly.
>   * This seemingly unnecessary copy is required in case va_list
>   * is an array type.
> diff --git a/tests/test-qga.c b/tests/test-qga.c
> index c780f00..438c2e7 100644
> --- a/tests/test-qga.c
> +++ b/tests/test-qga.c
> @@ -146,14 +146,23 @@ static void test_qga_sync_delimited(gconstpointer fix)
>  QDict *ret;
>  gchar *cmd;
> 
> -cmd = g_strdup_printf("%c{'execute': 'guest-sync-delimited',"
> -  " 'arguments': {'id': %u } }", 0xff, r);
> +cmd = g_strdup_printf("\xff{'execute': 'guest-sync-delimited',"
> +  " 'arguments': {'id': %u } }", r);
>  qmp_fd_send(fixture->fd, cmd);
>  g_free(cmd);
> 
> -v = read(fixture->fd, , 1);
> -g_assert_cmpint(v, ==, 1);
> -g_assert_cmpint(c, ==, 0xff);
> +/*
> + * Read and ignore garbage until resynchronized.
> + *
> + * TODO: The server shouldn't emit so much garbage (among other
> + * things, it loudly complains about the client's \xff being
> + * invalid JSON, even though it is a documented part of the
> + * handshake.
> + */
> +do {
> +v = read(fixture->fd, , 1);
> +g_assert_cmpint(v, ==, 1);
> +} while (c != 0xff);
> 
>  ret = qmp_fd_receive(fixture->fd);
>  g_assert_nonnull(ret);
> @@ -172,8 +181,19 @@ static void test_qga_sync(gconstpointer fix)
>  QDict *ret;
>  gchar *cmd;
> 
> -cmd = g_strdup_printf("%c{'execute': 'guest-sync',"
> -  " 'arguments': {'id': %u } 

[Qemu-devel] [PATCH v17 20/23] osdep: Fall back to posix lock when OFD lock is unavailable

2017-05-02 Thread Fam Zheng
Signed-off-by: Fam Zheng 
---
 util/osdep.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/util/osdep.c b/util/osdep.c
index 3de4a18..a2863c8 100644
--- a/util/osdep.c
+++ b/util/osdep.c
@@ -38,6 +38,14 @@ extern int madvise(caddr_t, size_t, int);
 #include "qemu/error-report.h"
 #include "monitor/monitor.h"
 
+#ifdef F_OFD_SETLK
+#define QEMU_SETLK F_OFD_SETLK
+#define QEMU_GETLK F_OFD_GETLK
+#else
+#define QEMU_SETLK F_SETLK
+#define QEMU_GETLK F_GETLK
+#endif
+
 static bool fips_enabled = false;
 
 static const char *hw_version = QEMU_HW_VERSION;
@@ -143,7 +151,6 @@ static int qemu_parse_fdset(const char *param)
 
 static int qemu_lock_fcntl(int fd, int64_t start, int64_t len, int fl_type)
 {
-#ifdef F_OFD_SETLK
 int ret;
 struct flock fl = {
 .l_whence = SEEK_SET,
@@ -151,11 +158,8 @@ static int qemu_lock_fcntl(int fd, int64_t start, int64_t 
len, int fl_type)
 .l_len= len,
 .l_type   = fl_type,
 };
-ret = fcntl(fd, F_OFD_SETLK, );
+ret = fcntl(fd, QEMU_SETLK, );
 return ret == -1 ? -errno : 0;
-#else
-return -ENOTSUP;
-#endif
 }
 
 int qemu_lock_fd(int fd, int64_t start, int64_t len, bool exclusive)
@@ -170,7 +174,6 @@ int qemu_unlock_fd(int fd, int64_t start, int64_t len)
 
 int qemu_lock_fd_test(int fd, int64_t start, int64_t len, bool exclusive)
 {
-#ifdef F_OFD_SETLK
 int ret;
 struct flock fl = {
 .l_whence = SEEK_SET,
@@ -178,15 +181,12 @@ int qemu_lock_fd_test(int fd, int64_t start, int64_t len, 
bool exclusive)
 .l_len= len,
 .l_type   = exclusive ? F_WRLCK : F_RDLCK,
 };
-ret = fcntl(fd, F_OFD_GETLK, );
+ret = fcntl(fd, QEMU_GETLK, );
 if (ret == -1) {
 return -errno;
 } else {
 return fl.l_type == F_UNLCK ? 0 : -EAGAIN;
 }
-#else
-return -ENOTSUP;
-#endif
 }
 #endif
 
-- 
2.9.3




[Qemu-devel] [PATCH v17 15/23] file-posix: Add 'locking' option

2017-05-02 Thread Fam Zheng
Making this option available even before implementing it will let
converting tests easier: in coming patches they can specify the option
already when necessary, before we actually write code to lock the
images.

Signed-off-by: Fam Zheng 
---
 block/file-posix.c   | 5 +
 qapi/block-core.json | 4 
 2 files changed, 9 insertions(+)

diff --git a/block/file-posix.c b/block/file-posix.c
index 1941fb6..261563d 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -392,6 +392,11 @@ static QemuOptsList raw_runtime_opts = {
 .type = QEMU_OPT_STRING,
 .help = "host AIO implementation (threads, native)",
 },
+{
+.name = "locking",
+.type = QEMU_OPT_STRING,
+.help = "file locking mode (on/off/auto, default: auto)",
+},
 { /* end of list */ }
 },
 };
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 1cf29a1..29d3040 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -2127,11 +2127,15 @@
 #
 # @filename:path to the image file
 # @aio: AIO backend (default: threads) (since: 2.8)
+# @locking: whether to enable file locking. If set to 'auto', only enable
+#   when Open File Descriptor (OFD) locking API is available
+#   (default: auto, since 2.10)
 #
 # Since: 2.9
 ##
 { 'struct': 'BlockdevOptionsFile',
   'data': { 'filename': 'str',
+'*locking': 'OnOffAuto',
 '*aio': 'BlockdevAioOptions' } }
 
 ##
-- 
2.9.3




[Qemu-devel] [PATCH v17 23/23] tests: Add POSIX image locking test case 182

2017-05-02 Thread Fam Zheng
Signed-off-by: Fam Zheng 
---
 tests/qemu-iotests/182 | 73 ++
 tests/qemu-iotests/182.out |  8 +
 tests/qemu-iotests/group   |  1 +
 3 files changed, 82 insertions(+)
 create mode 100755 tests/qemu-iotests/182
 create mode 100644 tests/qemu-iotests/182.out

diff --git a/tests/qemu-iotests/182 b/tests/qemu-iotests/182
new file mode 100755
index 000..ddc2f18
--- /dev/null
+++ b/tests/qemu-iotests/182
@@ -0,0 +1,73 @@
+#!/bin/bash
+#
+# Test image locking for POSIX locks
+#
+# Copyright 2017 Red Hat, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+#
+
+# creator
+owner=f...@redhat.com
+
+seq="$(basename $0)"
+echo "QA output created by $seq"
+
+here="$PWD"
+tmp=/tmp/$$
+status=1   # failure is the default!
+
+_cleanup()
+{
+_cleanup_test_img
+}
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+. ./common.qemu
+
+_supported_fmt qcow2
+_supported_proto file
+_supported_os Linux
+
+size=32M
+
+_make_test_img $size
+
+_run_cmd()
+{
+echo
+(echo "$@"; "$@" 1>/dev/null) >&2 | _filter_testdir
+}
+
+echo "Starting QEMU"
+_launch_qemu -drive file=$TEST_IMG,if=none,id=drive0,file.locking=on \
+-device virtio-blk-pci,drive=drive0
+
+echo
+echo "Starting a second QEMU using the same image should fail"
+echo 'quit' | $QEMU -monitor stdio \
+-drive file=$TEST_IMG,if=none,id=drive0,file.locking=on \
+-device virtio-blk-pci,drive=drive0 2>&1 | _filter_testdir 2>&1 |
+sed -e '/falling back to POSIX file/d' \
+-e '/locks can be lost unexpectedly/d'
+
+_cleanup_qemu
+
+# success, all done
+echo "*** done"
+rm -f $seq.full
+status=0
diff --git a/tests/qemu-iotests/182.out b/tests/qemu-iotests/182.out
new file mode 100644
index 000..b4b8f77
--- /dev/null
+++ b/tests/qemu-iotests/182.out
@@ -0,0 +1,8 @@
+QA output created by 182
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=33554432
+Starting QEMU
+
+Starting a second QEMU using the same image should fail
+qemu-system-x86_64: -drive 
file=TEST_DIR/t.qcow2,if=none,id=drive0,file.locking=on: Failed to get "write" 
lock
+Is another process using the image?
+*** done
diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index c8ae60e..a4549d8 100644
--- a/tests/qemu-iotests/group
+++ b/tests/qemu-iotests/group
@@ -171,3 +171,4 @@
 175 auto quick
 176 rw auto backing
 181 rw auto migration
+182 rw auto quick
-- 
2.9.3




  1   2   3   4   >