[Qemu-devel] [PATCH v1 2/3] target-ppc: implement vnegw/d instructions

Vector Integer Negate Instructions: vnegw: Vector Negate Word vnegd: Vector Negate Doubleword Signed-off-by: Nikunj A Dadhania --- target-ppc/helper.h | 2 ++ target-ppc/int_helper.c | 12 target-ppc/translate/vmx-impl.inc.c

[Qemu-devel] [PATCH v1 3/3] target-ppc: implement xxbr[qdwh] instruction

Add required helpers (GEN_XX2FORM_EO) for supporting this instruction. xxbrh: VSX Vector Byte-Reverse Halfword xxbrw: VSX Vector Byte-Reverse Word xxbrd: VSX Vector Byte-Reverse Doubleword xxbrq: VSX Vector Byte-Reverse Quadword Signed-off-by: Nikunj A Dadhania ---

[Qemu-devel] [PATCH v1 1/3] target-ppc: implement vexts[bh]2w and vexts[bhw]2d

Vector Extend Sign Instructions: vextsb2w: Vector Extend Sign Byte To Word vextsh2w: Vector Extend Sign Halfword To Word vextsb2d: Vector Extend Sign Byte To Doubleword vextsh2d: Vector Extend Sign Halfword To Doubleword vextsw2d: Vector Extend Sign Word To Doubleword Signed-off-by: Nikunj A

[Qemu-devel] [PATCH v1 0/3] POWER9 TCG enablements - part6

This series contains 11 new instructions for POWER9 ISA3.0 Vector Extend Sign Vector Integer Negate Vector Byte-Reverse Patches: 01: vextsb2w: Vector Extend Sign Byte To Word vextsh2w: Vector Extend Sign Halfword To Word vextsb2d: Vector Extend Sign Byte To Doubleword

Re: [Qemu-devel] [PATCH 0/4] POWER9 TCG enablements - part6

no-re...@patchew.org writes: > Checking PATCH 3/4: target-ppc: implement xxbr[qdwh] instruction... > ERROR: Macros with complex values should be enclosed in parenthesis > #173: FILE: target-ppc/translate/vsx-ops.inc.c:42: > +#define GEN_XX2FORM_EO(name, opc2, opc3, opc4, fl2)

[Qemu-devel] Potential Bug in vIOMMU which may result in memory wasting

Hi, Resend it here since there is code style issue with debug patch in previous email. 1. Problem description: Recently, I find a strange thing with vIOMMU in QEMU. It looks like g_hash_table_lookup() is not 100% give same result when the key is the same. And this results in redundant memory

Re: [Qemu-devel] [PATCH] replication: interrupt failover if the main device is closed

On 10/07/2016 08:21 PM, Paolo Bonzini wrote: Without this change, there is a race condition in tests/test-replication. Depending on how fast the failover job (active commit) runs, there is a chance of two bad things happening: 1) replication_done can be called after the secondary has been

[Qemu-devel] [PATCHv2 6/7] spapr_pci: Add a 64-bit MMIO window

On real hardware, and under pHyp, the PCI host bridges on Power machines typically advertise two outbound MMIO windows from the guest's physical memory space to PCI memory space: - A 32-bit window which maps onto 2GiB..4GiB in the PCI address space - A 64-bit window which maps onto a large

[Qemu-devel] [PATCHv2 4/7] spapr_pci: Delegate placement of PCI host bridges to machine type

The 'spapr-pci-host-bridge' represents the virtual PCI host bridge (PHB) for a PAPR guest. Unlike on x86, it's routine on Power (both bare metal and PAPR guests) to have numerous independent PHBs, each controlling a separate PCI domain. There are two ways of configuring the spapr-pci-host-bridge

[Qemu-devel] [PATCHv2 7/7] spapr: Improved placement of PCI host bridges in guest memory map

Currently, the MMIO space for accessing PCI on pseries guests begins at 1 TiB in guest address space. Each PCI host bridge (PHB) has a 64 GiB chunk of address space in which it places its outbound PIO and 32-bit and 64-bit MMIO windows. This scheme as several problems: - It limits guest RAM to

[Qemu-devel] [PATCHv2 5/7] spapr: Adjust placement of PCI host bridge to allow > 1TiB RAM

Currently the default PCI host bridge for the 'pseries' machine type is constructed with its IO windows in the 1TiB..(1TiB + 64GiB) range in guest memory space. This means that if > 1TiB of guest RAM is specified, the RAM will collide with the PCI IO windows, causing serious problems. Problems

[Qemu-devel] [PATCHv2 3/7] libqos: Limit spapr-pci to 32-bit MMIO for now

Currently the functions in pci-spapr.c (like pci-pc.c on which it's based) don't distinguish between 32-bit and 64-bit PCI MMIO. At the moment, the qemu side implementation is a bit weird and has a single MMIO window straddling 32-bit and 64-bit regions, but we're likely to change that in future.

Re: [Qemu-devel] [PATCH 0/7] IGNORE, SORRY (was: Improve PCI IO window orgnaization for pseries)

On Wed, Oct 12, 2016 at 03:29:45PM +1100, David Gibson wrote: > The current way we organize the IO windows into PCI space for the > pseries machine type has several problems. > > - It makes it difficult to create very large MMIO spaces which is > necessary for certain PCI devices with very

[Qemu-devel] [PATCHv2 1/7] libqos: Isolate knowledge of spapr memory map to qpci_init_spapr()

The libqos code for accessing PCI on the spapr machine type uses IOBASE() and MMIOBASE() macros to determine the address in the CPU memory map of the windows to PCI address space. This is a detail of the implementation of PCI in the machine type, it's not specified by the PAPR standard. Real

[Qemu-devel] x86 Instruction Testing?

Hello, I'm a student researcher with the University of Arizona's Computer Science Department. I'm writing to ask if any executable that you use to test QEMU systematically tests all, or at least a large portion, of the x86 instruction set? We're working on a project that involves dynamic taint

[Qemu-devel] [Bug 1319100] Re: qemu-arm-static bug in signal handling causes mono and java to hang

Did this fix end up making it into QEMU 2.7? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1319100 Title: qemu-arm-static bug in signal handling causes mono and java to hang Status in QEMU: Fix

Re: [Qemu-devel] [PATCH] char: serial: check divider value against baud base

Dear, Thank you very much for your support. And will you assign a CVE-ID for the issue? Best regards, Huawei PSIRT -邮件原件- 发件人: P J P [mailto:ppan...@redhat.com] 发送时间: 2016年10月12日 0:28 收件人: Qemu Developers 抄送: Michael S. Tsirkin; Paolo Bonzini; Huawei PSIRT; Prasad J Pandit 主题: [PATCH]

[Qemu-devel] [PATCHv2 0/7] Improve PCI IO window orgnaization for pseries

The current way we organize the IO windows into PCI space for the pseries machine type has several problems. - It makes it difficult to create very large MMIO spaces which is necessary for certain PCI devices with very large BARs. This problem has been known for a while. - More

[Qemu-devel] [PATCHv2 2/7] libqos: Correct error in PCI hole sizing for spapr

In pci-spapr.c (as in pci-pc.c from which it was derived), the pci_hole_start/pci_hole_size and pci_iohole_start/pci_iohole_size pairs[1] essentially define the region of PCI (not CPU) addresses in which MMIO or PIO BARs respectively will be allocated. The size value is relative to the start

[Qemu-devel] [PATCH v3] block/replication: Clarify 'top-id' parameter usage

The replication driver only supports the 'top-id' parameter for the secondary side; it must not be supplied for the primary side. Reviewed-by: Eric Blake Signed-off-by: Changlong Xie --- block/replication.c | 5 + qapi/block-core.json | 3 ++-

[Qemu-devel] [PATCH 1/7] libqos: Isolate knowledge of spapr memory map to qpci_init_spapr()

The libqos code for accessing PCI on the spapr machine type uses IOBASE() and MMIOBASE() macros to determine the address in the CPU memory map of the windows to PCI address space. This is a detail of the implementation of PCI in the machine type, it's not specified by the PAPR standard. Real

[Qemu-devel] [PATCH 5/7] spapr: Adjust placement of PCI host bridge to allow > 1TiB RAM

Currently the default PCI host bridge for the 'pseries' machine type is constructed with its IO windows in the 1TiB..(1TiB + 64GiB) range in guest memory space. This means that if > 1TiB of guest RAM is specified, the RAM will collide with the PCI IO windows, causing serious problems. Problems

[Qemu-devel] [PATCH 0/7] Improve PCI IO window orgnaization for pseries

The current way we organize the IO windows into PCI space for the pseries machine type has several problems. - It makes it difficult to create very large MMIO spaces which is necessary for certain PCI devices with very large BARs. This problem has been known for a while. - More

[Qemu-devel] [PATCH 7/7] spapr: Improved placement of PCI host bridges in guest memory map

Currently, the MMIO space for accessing PCI on pseries guests begins at 1 TiB in guest address space. Each PCI host bridge (PHB) has a 64 GiB chunk of address space in which it places its outbound PIO and 32-bit and 64-bit MMIO windows. This scheme as several problems: - It limits guest RAM to

[Qemu-devel] [PATCH 3/7] libqos: Limit spapr-pci to 32-bit MMIO for now

Currently the functions in pci-spapr.c (like pci-pc.c on which it's based) don't distinguish between 32-bit and 64-bit PCI MMIO. At the moment, the qemu side implementation is a bit weird and has a single MMIO window straddling 32-bit and 64-bit regions, but we're likely to change that in future.

[Qemu-devel] [PATCH 2/7] libqos: Correct error in PCI hole sizing for spapr

In pci-spapr.c (as in pci-pc.c from which it was derived), the pci_hole_start/pci_hole_size and pci_iohole_start/pci_iohole_size pairs[1] essentially define the region of PCI (not CPU) addresses in which MMIO or PIO BARs respectively will be allocated. The size value is relative to the start

[Qemu-devel] [PATCH 6/7] spapr_pci: Add a 64-bit MMIO window

On real hardware, and under pHyp, the PCI host bridges on Power machines typically advertise two outbound MMIO windows from the guest's physical memory space to PCI memory space: - A 32-bit window which maps onto 2GiB..4GiB in the PCI address space - A 64-bit window which maps onto a large

[Qemu-devel] [PATCH 4/7] spapr_pci: Delegate placement of PCI host bridges to machine type

The 'spapr-pci-host-bridge' represents the virtual PCI host bridge (PHB) for a PAPR guest. Unlike on x86, it's routine on Power (both bare metal and PAPR guests) to have numerous independent PHBs, each controlling a separate PCI domain. There are two ways of configuring the spapr-pci-host-bridge

[Qemu-devel] [PATCH] 9pfs: fix integer overflow issue in xattr read/write

From: Li Qiang In 9pfs xattr read/write function, it mix to use unsigned/signed ,32/64 bits integers. This will causes oob read/write issues. This patch fix this. Signed-off-by: Li Qiang --- hw/9pfs/9p.c | 29 + 1 file changed,

Re: [Qemu-devel] [PATCH RFC] vfio-pci: put device in INTx disable state in pre_reset

On 10/12/2016 10:25 AM, Alex Williamson wrote: On Mon, 10 Oct 2016 17:12:43 +0800 Cao jin wrote: Current code cleared the PCI_COMMAND_INTX_DISABLE, which indicates device/function could asserts its INTx# signal. PCI local spec says: A value of 0 enables the

Re: [Qemu-devel] [dpdk-dev] [PATCH 1/2] vhost: enable any layout feature

On Tue, Oct 11, 2016 at 02:57:49PM +0800, Yuanhan Liu wrote: > > > > > > There was an example: the vhost enqueue optmization patchset from > > > > > > Zhihong [0] uses memset, and it introduces more than 15% drop (IIRC) Though it doesn't matter now, but I have verified it yesterday (with and

Re: [Qemu-devel] [PATCH V2] colo-proxy: fix memory leak

On 10/11/2016 10:32 PM, Eric Blake wrote: On 10/11/2016 02:33 AM, Zhang Chen wrote: Fix memory leak in colo-compare.c and filter-rewriter.c Report by Coverity. This part is fine. v2: - use traces instead of fprintf in colo-compare.c v1: - initial patch ...but this part should

Re: [Qemu-devel] [PATCH RFC] vfio-pci: put device in INTx disable state in pre_reset

On Mon, 10 Oct 2016 17:12:43 +0800 Cao jin wrote: > Current code cleared the PCI_COMMAND_INTX_DISABLE, which indicates > device/function could asserts its INTx# signal. > > PCI local spec says: > A value of 0 enables the assertion of its INTx# signal. > A value of 1

[Qemu-devel] [PATCH] mmap-alloc: check before use for ptr pointer

If ptr mmap failed, we don't need to do a superfluous calculation for offset variable by ptr (MAP_FAILED). Signed-off-by: Gonglei --- util/mmap-alloc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/util/mmap-alloc.c b/util/mmap-alloc.c index

Re: [Qemu-devel] [PATCH v8 4/6] docs: Add Documentation for Mediated devices

> From: Kirti Wankhede [mailto:kwankh...@nvidia.com] > Sent: Wednesday, October 12, 2016 4:45 AM > >> +* mdev_supported_types: > >> +List of current supported mediated device types and its details are > >> added > >> +in this directory in following format: > >> + > >> +|- > >> +|---

Re: [Qemu-devel] [PATCH 00/16] target-sparc improvements

On 10/11/2016 04:42 PM, Mark Cave-Ayland wrote: I'm fairly sure that I've tested an earlier version of this patchset, however just to confirm is it just that you want a Tested-by from me of this branch based upon the v6 atomics patch? If so I can run it against all of my SPARC/SPARC64 test

Re: [Qemu-devel] [PATCH v3 0/7] Runtime pagesize computation

On 10/11/2016 03:18 PM, Peter Maydell wrote: On 11 October 2016 at 12:20, Richard Henderson wrote: On 10/11/2016 12:08 PM, Peter Maydell wrote: I would ideally have liked to finalize things much later, but this is in practice hugely difficult because so many things (in

Re: [Qemu-devel] [PATCH v2] tests: Run qtest cases in parallel

On Fri, 09/30 13:25, Marc-André Lureau wrote: > In any case > Reviewed-by: Marc-André Lureau Paolo, are you happy with taking this patch? Fam

Re: [Qemu-devel] [PATCH] qcow2: Support BDRV_REQ_MAY_UNMAP

On Wed, 09/28 15:04, Fam Zheng wrote: > Handling this is similar to what is done to the L2 entry in the case of > compressed clusters. Kevin, Max, is there anything else I need to do before this patch can be applied? Fam

Re: [Qemu-devel] [PATCH v3 0/5] generic docker run patches

On Tue, 10/11 17:16, Alex Bennée wrote: > Hi Fam, > > I've re-based the series for the generic run target. The aim being to > allow a developer to run tests against any generic docker target even > if it is not in the list of approved targets: > > make docker-run TEST=test-quick

Re: [Qemu-devel] [PATCH v4] timer: a9gtimer: remove loop to auto-increment comparator

On Tue, 10/11 22:44, P J P wrote: > +-- On Mon, 10 Oct 2016, no-re...@ec2-52-6-146-230.compute-1.amazonaws.com > wrote --+ > | Your series failed automatic build test. Please find the testing commands > and > | their output below. If you have docker installed, you can probably > reproduce it >

Re: [Qemu-devel] [PATCH v3 0/7] Runtime pagesize computation

Hi, Your series seems to have some coding style problems. See output below for more information: Message-id: 1476205699-28857-1-git-send-email-peter.mayd...@linaro.org Subject: [Qemu-devel] [PATCH v3 0/7] Runtime pagesize computation Type: series === TEST SCRIPT BEGIN === #!/bin/bash BASE=base

Re: [Qemu-devel] [PATCH] char: serial: check divider value against baud base

Hi, Your series seems to have some coding style problems. See output below for more information: Subject: [Qemu-devel] [PATCH] char: serial: check divider value against baud base Message-id: 1476203260-5290-1-git-send-email-ppan...@redhat.com Type: series === TEST SCRIPT BEGIN === #!/bin/bash

Re: [Qemu-devel] Potential Bug in vIOMMU which may result in memory wasting

Hi, Your series seems to have some coding style problems. See output below for more information: Message-id: a2975661238fb949b60364ef0f2c257436dbd...@shsmsx102.ccr.corp.intel.com Subject: [Qemu-devel] Potential Bug in vIOMMU which may result in memory wasting Type: series === TEST SCRIPT BEGIN

Re: [Qemu-devel] [Questions] NBD issue or CoMutex->holder issue?

On 10/11/2016 06:47 PM, Paolo Bonzini wrote: the free_sema->queue head, so set free_sema->holder as >revelant coroutine. NBD is using the CoMutex in a way that wasn't anticipated. The simplest fix is to change it to CoQueue, which is like a condition variable. Instead of locking if in_flight

Re: [Qemu-devel] [PATCH v2 2/2] block/replication: Clarify 'top-id' parameter usage

On 10/11/2016 10:54 PM, Eric Blake wrote: The replication driver only supports the 'top-id' parameter for the secondary side; it must not be supplied for the primary side. Will apply in next version. Thanks -Xie

Re: [Qemu-devel] [PATCH v2 1/2] block/replication: prefect the logic to acquire 'top_id'

On 10/11/2016 10:52 PM, Eric Blake wrote: On 10/11/2016 05:46 AM, Changlong Xie wrote: Only g_strdup(top_id) if 'top_id' is not NULL, although there is no memory leak here Signed-off-by: Changlong Xie --- block/replication.c | 4 ++-- 1 file changed, 2

Re: [Qemu-devel] [PATCH 0/3] Improvements for the boot-sector tester

On Wed, Oct 12, 2016 at 12:05:24AM +0300, Michael S. Tsirkin wrote: > On Tue, Oct 11, 2016 at 05:19:34PM +0200, Thomas Huth wrote: > > Here are two patches that try to improve the situation with the > > slow pxe-test on ppc64 a little bit, and one patch that fixes > > a potential race condition

Re: [Qemu-devel] [QEMU PATCH v5 1/6] migration: alternative way to set instance_id in SaveStateEntry

On Tue, Oct 11, 2016 at 11:17:35AM -0500, Michael Roth wrote: > Quoting David Gibson (2016-10-10 00:31:20) > > On Fri, Oct 07, 2016 at 09:07:49AM +0100, Dr. David Alan Gilbert wrote: > > > * David Gibson (da...@gibson.dropbear.id.au) wrote: > > > > On Wed, Oct 05, 2016 at 09:44:57AM -0700, Jianjun

Re: [Qemu-devel] [PATCH v8 6/6] Add common functions for SET_IRQS and GET_REGION_INFO ioctls

On Tue, 11 Oct 2016 01:58:37 +0530 Kirti Wankhede wrote: > Add common functions for SET_IRQS and to add capability buffer for > GET_REGION_INFO ioctls Clearly should be two (or more) separate patches since SET_IRQS and REGION_INFO are unrelated changes. Each of the two

Re: [Qemu-devel] [PATCH v8 3/6] vfio iommu: Add support for mediated devices

On Tue, 11 Oct 2016 01:58:34 +0530 Kirti Wankhede wrote: > VFIO IOMMU drivers are designed for the devices which are IOMMU capable. > Mediated device only uses IOMMU APIs, the underlying hardware can be > managed by an IOMMU domain. > > Aim of this change is: > - To use

Re: [Qemu-devel] [PATCH 00/29] target-sparc: add Niagara OpenSPARC T1 sun4v emulation

On 01/10/16 11:05, Artyom Tarasenko wrote: > This patch series adds a Niagara OpenSPARC T1 sun4v machine. > The most important new feature: it can boot Solaris 10 / sparc64. > The machine uses a firmware released by Sun as a part of the OpenSPARC > project. > > The series are available under: >

Re: [Qemu-devel] [PATCH 00/16] target-sparc improvements

On 10/10/16 16:16, Richard Henderson wrote: > The two main goals in this patch set are: > > * Make use of the new MO_ALIGN_* flags, to allow less use of >check_align, and support partially misaligned fp memory ops. > > * More cleanups for ASIs, in the end using the new atomic ops. > >

Re: [Qemu-devel] [ipxe-devel] [PATCH 0/6] ipxe: update roms

Hi, This caused a regression for me on i7 920. https://bugs.archlinux.org/task/50778 I bisected qemu and came to the patch that introduced the above. Then after some more help on irc (fixing up parserom.pl and compiling with NO_WERROR=1) biscted ipxe and came to

Re: [Qemu-devel] [PATCH 0/3] Improvements for the boot-sector tester

On Tue, Oct 11, 2016 at 05:19:34PM +0200, Thomas Huth wrote: > Here are two patches that try to improve the situation with the > slow pxe-test on ppc64 a little bit, and one patch that fixes > a potential race condition between tests that run in parallel > by using a random filename instead of an

Re: [Qemu-devel] [PATCH 0/6] qdev class properties + abstract class support on device-list-properties

Hi, Your series failed automatic build test. Please find the testing commands and their output below. If you have docker installed, you can probably reproduce it locally. Message-id: 1476218479-3592-1-git-send-email-ehabk...@redhat.com Subject: [Qemu-devel] [PATCH 0/6] qdev class properties +

Re: [Qemu-devel] [PATCH v8 4/6] docs: Add Documentation for Mediated devices

On 10/11/2016 7:44 PM, Daniel P. Berrange wrote: > On Tue, Oct 11, 2016 at 01:58:35AM +0530, Kirti Wankhede wrote: >> Add file Documentation/vfio-mediated-device.txt that include details of >> mediated device framework. >> >> Signed-off-by: Kirti Wankhede >> Signed-off-by:

[Qemu-devel] [PATCH 6/6] qdev: Warning about using object_class_property_add() in new code

The only remaining user of object_class_property_add() is arm_cpu_post_init(), but removing it may take some work. While we don't change it, warn people to not use the function in new code. Cc: Peter Maydell Cc: qemu-...@nongnu.org Signed-off-by: Eduardo Habkost

[Qemu-devel] [PATCH 5/6] qmp: Support abstract classes on device-list-properties

When an abstract class is used on device-list-properties, we can simply return the class properties registered for the class. This will be useful if management software needs to query for CPU options that are supported by all CPU models, for example. Signed-off-by: Eduardo Habkost

[Qemu-devel] [PATCH 3/6] qdev: Register static properties as class properties

Instead of registering qdev static properties on instance_init, register them as class properties, at qdev_class_set_props(). qdev_property_add_legacy() was replaced by an equivalent qdev_class_property_add_legacy() function. qdev_property_add_static(), on the other hand, can't be eliminated yet

[Qemu-devel] [PATCH 4/6] qom: object_class_property_iter_init() function

The new function will allow us to iterate over class properties using the same logic we use for object properties. Unit test included. Signed-off-by: Eduardo Habkost --- include/qom/object.h | 14 ++ qom/object.c | 11 +--

[Qemu-devel] [PATCH 0/6] qdev class properties + abstract class support on device-list-properties

This series allows abstract classes to be used on device-list-properties, which will return all class properties registered for the class. Patches 1-3 change qdev to register all static properties as class properties instead of instance properties. Patches 4-5 change device-list-properties so it

[Qemu-devel] [PATCH 2/6] qdev: Extract property-default code to qdev_property_set_to_default()

The code that registers qdev properties will be split from the code that initializes default values on instance_init, so move it to a separate function. Signed-off-by: Eduardo Habkost --- hw/core/qdev.c | 41 + 1 file changed, 29

Re: [Qemu-devel] [PATCH 0/4] Allow blockdev-add for SSH

Hi, Your series failed automatic build test. Please find the testing commands and their output below. If you have docker installed, you can probably reproduce it locally. Message-id: 1476171437-11830-1-git-send-email-ashijeetacha...@gmail.com Subject: [Qemu-devel] [PATCH 0/4] Allow blockdev-add

Re: [Qemu-devel] [PATCH v8 2/6] vfio: VFIO based driver for Mediated devices

On 10/11/2016 9:25 AM, Alex Williamson wrote: > On Tue, 11 Oct 2016 01:58:33 +0530 > Kirti Wankhede wrote: > >> vfio_mdev driver registers with mdev core driver. >> MDEV core driver creates mediated device and calls probe routine of >> vfio_mdev driver for each device. >>

[Qemu-devel] [PATCH v6 35/35] target-alpha: Emulate LL/SC using cmpxchg helpers

Emulating LL/SC with cmpxchg is not correct, since it can suffer from the ABA problem. However, portable parallel code is written assuming only cmpxchg which means that in practice this is a viable alternative. Signed-off-by: Richard Henderson --- linux-user/main.c|

[Qemu-devel] [PATCH v6 34/35] target-alpha: Introduce MMU_PHYS_IDX

Rather than using helpers for physical accesses, use a mmu index. The primary cleanup is with store-conditional on physical addresses. Signed-off-by: Richard Henderson --- target-alpha/cpu.h| 18 +--- target-alpha/helper.c | 8 ++ target-alpha/helper.h

[Qemu-devel] [PATCH v6 30/35] target-arm: emulate aarch64's LL/SC using cmpxchg helpers

From: "Emilio G. Cota" Emulating LL/SC with cmpxchg is not correct, since it can suffer from the ABA problem. Portable parallel code, however, is written assuming only cmpxchg--and not LL/SC--is available. This means that in practice emulating LL/SC with cmpxchg is a viable

Re: [Qemu-devel] [PATCH v3 0/7] Runtime pagesize computation

On 11 October 2016 at 12:20, Richard Henderson wrote: > On 10/11/2016 12:08 PM, Peter Maydell wrote: >> I would ideally have liked to finalize things much later, but >> this is in practice hugely difficult because so many things >> (in particular all the address space/memory

[Qemu-devel] [PATCH v6 31/35] linux-user: remove handling of ARM's EXCP_STREX

From: "Emilio G. Cota" The exception is not emitted anymore. Reviewed-by: Alex Bennée Signed-off-by: Emilio G. Cota Signed-off-by: Richard Henderson Message-Id: <1467054136-10430-29-git-send-email-c...@braap.org> ---

Re: [Qemu-devel] [PATCH v8 1/6] vfio: Mediated device Core driver

On 10/11/2016 9:21 AM, Alex Williamson wrote: > On Tue, 11 Oct 2016 01:58:32 +0530 > Kirti Wankhede wrote: >> --- >> drivers/vfio/Kconfig | 1 + >> drivers/vfio/Makefile| 1 + >> drivers/vfio/mdev/Kconfig| 12 ++ >>

[Qemu-devel] [PATCH v6 32/35] linux-user: remove handling of aarch64's EXCP_STREX

From: "Emilio G. Cota" The exception is not emitted anymore. Reviewed-by: Alex Bennée Signed-off-by: Emilio G. Cota Signed-off-by: Richard Henderson Message-Id: <1467054136-10430-30-git-send-email-c...@braap.org> ---

[Qemu-devel] [PATCH v6 26/35] tests: add atomic_add-bench

From: "Emilio G. Cota" With this microbenchmark we can measure the overhead of emulating atomic instructions with a configurable degree of contention. The benchmark spawns $n threads, each performing $o atomic ops (additions) in a loop. Each atomic operation is performed on a

[Qemu-devel] [PATCH v6 33/35] target-arm: remove EXCP_STREX + cpu_exclusive_{test, info}

From: "Emilio G. Cota" The exception is not emitted anymore; remove it and the associated TCG variables. Reviewed-by: Alex Bennée Signed-off-by: Emilio G. Cota Signed-off-by: Richard Henderson Message-Id:

[Qemu-devel] [PATCH v6 24/35] target-i386: emulate XCHG using atomic helper

From: "Emilio G. Cota" Signed-off-by: Emilio G. Cota Message-Id: <1467054136-10430-19-git-send-email-c...@braap.org> Signed-off-by: Richard Henderson --- target-i386/translate.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-)

[Qemu-devel] [PATCH v6 25/35] target-i386: remove helper_lock()

From: "Emilio G. Cota" It's been superseded by the atomic helpers. The use of the atomic helpers provides a significant performance and scalability improvement. Below is the result of running the atomic_add-test microbenchmark with: $ x86_64-linux-user/qemu-x86_64

[Qemu-devel] [PATCH v6 29/35] target-arm: emulate SWP with atomic_xchg helper

From: "Emilio G. Cota" Signed-off-by: Emilio G. Cota Message-Id: <1467054136-10430-25-git-send-email-c...@braap.org> Signed-off-by: Richard Henderson --- target-arm/translate.c | 26 ++ 1 file changed, 14 insertions(+),

[Qemu-devel] [PATCH v6 23/35] target-i386: emulate LOCK'ed BTX ops using atomic helpers

From: "Emilio G. Cota" [rth: Avoid redundant qemu_ld in locked case. Fix previously unnoticed incorrect zero-extension of address in register-offset case.] Signed-off-by: Emilio G. Cota Message-Id: <1467054136-10430-18-git-send-email-c...@braap.org>

[Qemu-devel] [PATCH v6 21/35] target-i386: emulate LOCK'ed NEG using cmpxchg helper

From: "Emilio G. Cota" [rth: Move redundant qemu_load out of cmpxchg loop.] Signed-off-by: Emilio G. Cota Message-Id: <1467054136-10430-16-git-send-email-c...@braap.org> Signed-off-by: Richard Henderson --- target-i386/translate.c | 38

[Qemu-devel] [PATCH v6 28/35] target-arm: emulate LL/SC using cmpxchg helpers

From: "Emilio G. Cota" Emulating LL/SC with cmpxchg is not correct, since it can suffer from the ABA problem. Portable parallel code, however, is written assuming only cmpxchg--and not LL/SC--is available. This means that in practice emulating LL/SC with cmpxchg is a viable

[Qemu-devel] [PATCH v6 16/35] tcg: Emit barriers with parallel_cpus

Reviewed-by: Alex Bennée Signed-off-by: Richard Henderson --- tcg/tcg-op.c | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/tcg/tcg-op.c b/tcg/tcg-op.c index cdd61d6..bb2bfee 100644 --- a/tcg/tcg-op.c +++ b/tcg/tcg-op.c

[Qemu-devel] [PATCH v6 22/35] target-i386: emulate LOCK'ed XADD using atomic helper

From: "Emilio G. Cota" [rth: Move load of reg value to common location.] Signed-off-by: Emilio G. Cota Message-Id: <1467054136-10430-17-git-send-email-c...@braap.org> Signed-off-by: Richard Henderson --- target-i386/translate.c | 15

[Qemu-devel] [PATCH v6 13/35] tcg: Add atomic helpers

Add all of cmpxchg, op_fetch, fetch_op, and xchg. Handle both endian-ness, and sizes up to 8. Handle expanding non-atomically, when emulating in serial. Signed-off-by: Richard Henderson --- Makefile.objs | 2 +- Makefile.target | 1 + atomic_template.h |

[Qemu-devel] [PATCH v6 12/35] cputlb: Tidy some macros

TGT_LE and TGT_BE are not size dependent and do not need to be redefined. The others are no longer used at all. Reviewed-by: Alex Bennée Signed-off-by: Richard Henderson --- cputlb.c | 8 softmmu_template.h | 22

[Qemu-devel] [PATCH v6 27/35] target-arm: Rearrange aa32 load and store functions

Stop specializing on TARGET_LONG_BITS == 32; unconditionally allocate a temp and expand with tcg_gen_extu_i32_tl. Split out gen_aa32_addr, gen_aa32_frob64, gen_aa32_ld_i32 and gen_aa32_st_i32 as separate interfaces. Reviewed-by: Alex Bennée Signed-off-by: Richard

[Qemu-devel] [PATCH v6 20/35] target-i386: emulate LOCK'ed NOT using atomic helper

From: "Emilio G. Cota" [rth: Avoid qemu_load that's redundant with the atomic op.] Signed-off-by: Emilio G. Cota Message-Id: <1467054136-10430-15-git-send-email-c...@braap.org> Signed-off-by: Richard Henderson --- target-i386/translate.c | 26

[Qemu-devel] [PATCH v6 14/35] tcg: Add atomic128 helpers

Force the use of cmpxchg16b on x86_64. Wikipedia suggests that only very old AMD64 (circa 2004) did not have this instruction. Further, it's required by Windows 8 so no new cpus will ever omit it. If we truely care about these, then we could check this at startup time and then avoid executing

[Qemu-devel] [PATCH v6 11/35] cputlb: Move most of iotlb code out of line

Saves 2k code size off of a cold path. Reviewed-by: Alex Bennée Signed-off-by: Richard Henderson --- cputlb.c | 37 + softmmu_template.h | 52 ++-- 2 files

[Qemu-devel] [PATCH v6 18/35] target-i386: emulate LOCK'ed OP instructions using atomic helpers

From: "Emilio G. Cota" [rth: Eliminate some unnecessary temporaries.] Signed-off-by: Emilio G. Cota Message-Id: <1467054136-10430-13-git-send-email-c...@braap.org> Signed-off-by: Richard Henderson --- target-i386/translate.c | 76

[Qemu-devel] [PATCH v6 19/35] target-i386: emulate LOCK'ed INC using atomic helper

From: "Emilio G. Cota" [rth: Merge gen_inc_locked back into gen_inc to share cc update.] Signed-off-by: Emilio G. Cota Message-Id: <1467054136-10430-14-git-send-email-c...@braap.org> Signed-off-by: Richard Henderson ---

[Qemu-devel] [PATCH v6 17/35] target-i386: emulate LOCK'ed cmpxchg using cmpxchg helpers

From: "Emilio G. Cota" The diff here is uglier than necessary. All this does is to turn FOO into: if (s->prefix & PREFIX_LOCK) { BAR } else { FOO } where FOO is the original implementation of an unlocked cmpxchg. [rth: Adjust unlocked cmpxchg to use movcond instead of

[Qemu-devel] [PATCH v6 15/35] tcg: Add CONFIG_ATOMIC64

Allow qemu to build on 32-bit hosts without 64-bit atomic ops. Even if we only allow 32-bit hosts to multi-thread emulate 32-bit guests, we still need some way to handle the 32-bit guest using a 64-bit atomic operation. Do so by dropping back to single-step. Signed-off-by: Richard Henderson

[Qemu-devel] [PATCH v6 10/35] cputlb: Remove includes from softmmu_template.h

We already include exec/address-spaces.h and exec/memory.h in cputlb.c; the include of qemu/timer.h appears to be a fossil. Reviewed-by: Alex Bennée Signed-off-by: Richard Henderson --- softmmu_template.h | 4 1 file changed, 4 deletions(-) diff

[Qemu-devel] [PATCH v6 08/35] cputlb: Replace SHIFT with DATA_SIZE

Reviewed-by: Alex Bennée Signed-off-by: Richard Henderson --- cputlb.c | 16 softmmu_template.h | 7 ++- 2 files changed, 10 insertions(+), 13 deletions(-) diff --git a/cputlb.c b/cputlb.c index 3c99c34..5575b73 100644

[Qemu-devel] [PATCH v6 09/35] cputlb: Move probe_write out of softmmu_template.h

Reviewed-by: Alex Bennée Signed-off-by: Richard Henderson --- cputlb.c | 21 + softmmu_template.h | 23 --- 2 files changed, 21 insertions(+), 23 deletions(-) diff --git a/cputlb.c b/cputlb.c index

[Qemu-devel] [PATCH v6 01/35] atomics: add atomic_xor

From: "Emilio G. Cota" This paves the way for upcoming work. Reviewed-by: Alex Bennée Signed-off-by: Emilio G. Cota Signed-off-by: Richard Henderson Message-Id: <1467054136-10430-8-git-send-email-c...@braap.org> ---

[Qemu-devel] [PATCH v6 07/35] linux-user: enable parallel code generation on clone

From: Alex Bennée The variable parallel_cpus controls the generation of thread aware atomic code. We only need to set it once we clone our first thread. At this point any existing translations need to be thrown away. Signed-off-by: Alex Bennée

[Qemu-devel] [PATCH v6 05/35] int128: Add int128_make128

Allows Int128 to be used more generally, rather than having to begin with 64-bit inputs and accumulate. Reviewed-by: Alex Bennée Signed-off-by: Richard Henderson --- include/qemu/int128.h | 20 +++- 1 file changed, 15 insertions(+), 5

[Qemu-devel] [PATCH v6 03/35] exec: Avoid direct references to Int128 parts

Reviewed-by: Alex Bennée Signed-off-by: Richard Henderson --- exec.c| 4 ++-- include/qemu/int128.h | 10 ++ 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/exec.c b/exec.c index c8389f9..cc2997e 100644 ---

[Qemu-devel] [PATCH v6 04/35] int128: Use __int128 if available

Reviewed-by: Alex Bennée Signed-off-by: Richard Henderson --- include/qemu/int128.h | 135 +- tests/test-int128.c | 22 2 files changed, 145 insertions(+), 12 deletions(-) diff --git

  1   2   3   4   >