Re: [Qemu-devel] [PATCH] kvm: pass the virtual SEI syndrome to guest OS

Dear, Laszlo Thanks for your detailed explanation. On 2017/3/29 19:58, Laszlo Ersek wrote: > (This ought to be one of the longest address lists I've ever seen :) > Thanks for the CC. I'm glad Shannon is already on the CC list. For good > measure, I'm adding MST and Igor.) > > On 03/29/17

Re: [Qemu-devel] [PATCH 04/21] ppc/pnv: enable only one LPC bus

On 04/06/2017 02:01 PM, Benjamin Herrenschmidt wrote: > On Thu, 2017-04-06 at 13:50 +0200, Cédric Le Goater wrote: >> >> So, looking at hostboot, the lower level firmware, I think the >> initial >> patch is more in sync with it : >> >>

Re: [Qemu-devel] [Qemu-block] [PATCH v2 for-2.10 09/16] block/qcow2: Generalize preallocate()

On Mon, Apr 03, 2017 at 06:09:29PM +0200, Max Reitz wrote: > This patch adds two new parameters to the preallocate() function so we > will be able to use it not just for preallocating a new image but also > for preallocated image growth. > > The offset parameter allows the caller to specify a

Re: [Qemu-devel] [PATCH v2 for-2.10 08/16] block/file-posix: Preallocation for truncate

On Mon, Apr 03, 2017 at 06:09:28PM +0200, Max Reitz wrote: > By using raw_regular_truncate() in raw_truncate(), we can now easily > support preallocation. > > Signed-off-by: Max Reitz > --- > block/file-posix.c | 22 ++ > 1 file changed, 10 insertions(+),

Re: [Qemu-devel] [Qemu-block] [PATCH v2 for-2.10 07/16] block/file-posix: Generalize raw_regular_truncate

On Mon, Apr 03, 2017 at 06:09:27PM +0200, Max Reitz wrote: > Currently, raw_regular_truncate() is intended for setting the size of a > newly created file. However, we also want to use it for truncating an > existing file in which case only the newly added space (when growing) > should be

Re: [Qemu-devel] [PATCH v2 for-2.10 04/16] qemu-img: Expose PreallocMode for resizing

On Mon, Apr 03, 2017 at 06:09:24PM +0200, Max Reitz wrote: > Add a --preallocation command line option to qemu-img resize which can > be used to set the PreallocMode parameter of blk_truncate(). > > Signed-off-by: Max Reitz > --- > qemu-img.c| 33

Re: [Qemu-devel] [Qemu-block] [PATCH v2 for-2.10 01/16] block: Add PreallocMode to BD.bdrv_truncate()

On Mon, Apr 03, 2017 at 06:09:21PM +0200, Max Reitz wrote: > Add a PreallocMode parameter to the bdrv_truncate() function implemented > by each block driver. Currently, we always pass PREALLOC_MODE_OFF and no > driver accepts anything else. > > Signed-off-by: Max Reitz > --- >

Re: [Qemu-devel] [PATCH 03/21] ppc/pnv: Add support for POWER8+ LPC Controller

On 04/06/2017 04:02 AM, David Gibson wrote: > On Wed, Apr 05, 2017 at 02:41:28PM +0200, Cédric Le Goater wrote: >> From: Benjamin Herrenschmidt >> >> It adds the Naples chip which supports proper LPC interrupts via the >> LPC controller rather than via an external CPLD.

Re: [Qemu-devel] [PATCH for-2.10 05/10] s390x/css: provide introspection for virtual subchannel and device busid

On 06.04.2017 13:16, Cornelia Huck wrote: > From: Dong Jia Shi > > Expose the busids of the virtual I/O subchannel and the virtual CCW > device to ease debugging. This is needed because: > 1. subchannel id are assigned dynamically, and cannot be set from >

Re: [Qemu-devel] [PATCH for-2.10 03/10] s390x/pci: make printf always compile in debug output

On 06.04.2017 13:16, Cornelia Huck wrote: > From: Danil Antonov > > Wrapped printf calls inside debug macros (DPRINTF) in `if` statement. > This will ensure that printf function will always compile even if debug > output is turned off and, in turn, will prevent bitrot of

[Qemu-devel] [PATCH 3/3] qxl: switch display on entering VGA

Since commit cd958edb1fae85d, same size console resize is skipped. This change broke QXL incoming migration in VGA mode, qemu_spice_display_switch() is no longer called during qxl_post_load(), because default message surface is of the same size, and during displaychangelistener registration,

[Qemu-devel] [PATCH 2/3] console: add same displaychangelistener registration pre-condition

Catch an invalid state. Mainly useful for documentation purposes. Signed-off-by: Marc-André Lureau --- ui/console.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ui/console.c b/ui/console.c index 0cbe5033dd..189eecfd29 100644 --- a/ui/console.c +++

[Qemu-devel] [PATCH 1/3] console: add same surface replace pre-condition

Catch an invalid state early, before a potential use-after-free. This is mainly useful for documentation purposes. Signed-off-by: Marc-André Lureau --- ui/console.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ui/console.c b/ui/console.c index

[Qemu-devel] [PATCH 0/3] Fix incoming migration regression of QXL in VGA mode

Hi, Commit cd958edb1fae85d introduced a migration regression in QXL VGA mode. The last patch fixes it. The first two patches helped me reason about the related console code. Marc-André Lureau (3): console: add same surface replace pre-condition console: add same displaychangelistener

Re: [Qemu-devel] [PATCH v8 0/9] VT-d: vfio enablement and misc enhances

On Thu, Apr 06, 2017 at 03:08:35PM +0800, Peter Xu wrote: > This is v8 of vt-d vfio enablement series. > > v8 > - remove patches 1-9 since merged already > - add David's r-b for all the patches > - add Aviv's s-o-b in the last patch > - rename iommu to iommu_dmar [Jason] > - rename last patch

Re: [Qemu-devel] [PATCH 04/21] ppc/pnv: enable only one LPC bus

On Thu, 2017-04-06 at 13:50 +0200, Cédric Le Goater wrote: > > So, looking at hostboot, the lower level firmware, I think the > initial  > patch is more in sync with it :  > >    https://github.com/open-power/hostboot/blob/master-p8/src/usr/devt > ree/bld_devtree.C#L1038 > > David, can we keep

Re: [Qemu-devel] [PATCH v8 9/9] intel_iommu: enable remote IOTLB

On Thu, Apr 06, 2017 at 03:08:44PM +0800, Peter Xu wrote: > This patch is based on Aviv Ben-David ()'s patch > upstream: > > "IOMMU: enable intel_iommu map and unmap notifiers" > https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg01453.html > > However I

Re: [Qemu-devel] [PATCH]Enable kvmvapic only when host doesn't support VAPIC capability in KVM mode

On Wed, Apr 05, 2017 at 12:52:25AM +, Xu, Anthony wrote: > In KVM mode, enable kvmvapic only when host doesn't support > VAPIC capability. > > Save the time to set up kvmvapic in some hosts. > > > Signed-off -by: Anthony Xu > s/Signed-off -by/Signed-off-by nit: I

Re: [Qemu-devel] [PATCH v8 8/9] intel_iommu: allow dynamic switch of IOMMU region

On Thu, Apr 06, 2017 at 03:08:43PM +0800, Peter Xu wrote: > This is preparation work to finally enabled dynamic switching ON/OFF for > VT-d protection. The old VT-d codes is using static IOMMU address space, > and that won't satisfy vfio-pci device listeners. > > Let me explain. > > vfio-pci

Re: [Qemu-devel] [PATCH v8 7/9] intel_iommu: provide its own replay() callback

On Thu, Apr 06, 2017 at 03:08:42PM +0800, Peter Xu wrote: > The default replay() don't work for VT-d since vt-d will have a huge > default memory region which covers address range 0-(2^64-1). This will > normally consumes a lot of time (which looks like a dead loop). > > The solution is simple -

Re: [Qemu-devel] [PATCH v8 6/9] intel_iommu: use the correct memory region for device IOTLB notification

On Thu, Apr 06, 2017 at 03:08:41PM +0800, Peter Xu wrote: > From: Jason Wang > > We have a specific memory region for DMAR now, so it's wrong to > trigger the notifier with the root region. > > Cc: Michael S. Tsirkin > Cc: Paolo Bonzini

Re: [Qemu-devel] [PATCH v8 5/9] memory: add MemoryRegionIOMMUOps.replay() callback

On Thu, Apr 06, 2017 at 03:08:40PM +0800, Peter Xu wrote: > Originally we have one memory_region_iommu_replay() function, which is > the default behavior to replay the translations of the whole IOMMU > region. However, on some platform like x86, we may want our own replay > logic for IOMMU

Re: [Qemu-devel] [PATCH v8 4/9] memory: introduce memory_region_notify_one()

On Thu, Apr 06, 2017 at 03:08:39PM +0800, Peter Xu wrote: > Generalizing the notify logic in memory_region_notify_iommu() into a > single function. This can be further used in customized replay() > functions for IOMMUs. > > Reviewed-by: David Gibson > Signed-off-by:

Re: [Qemu-devel] [PATCH v8 3/9] memory: provide iommu_replay_all()

On Thu, Apr 06, 2017 at 03:08:38PM +0800, Peter Xu wrote: > This is an "global" version of exising memory_region_iommu_replay() - we > announce the translations to all the registered notifiers, instead of a > specific one. > > Reviewed-by: David Gibson >

Re: [Qemu-devel] [PATCH v8 2/9] memory: provide IOMMU_NOTIFIER_FOREACH macro

On Thu, Apr 06, 2017 at 03:08:37PM +0800, Peter Xu wrote: > Reviewed-by: David Gibson > Signed-off-by: Peter Xu Reviewed-by: Michael S. Tsirkin > --- > include/exec/memory.h | 3 +++ > memory.c | 4 ++-- > 2 files

Re: [Qemu-devel] [PATCH v8 1/9] memory: add section range info for IOMMU notifier

On Thu, Apr 06, 2017 at 03:08:36PM +0800, Peter Xu wrote: > In this patch, IOMMUNotifier.{start|end} are introduced to store section > information for a specific notifier. When notification occurs, we not > only check the notification type (MAP|UNMAP), but also check whether the > notified iova

Re: [Qemu-devel] [PATCH v8 0/9] VT-d: vfio enablement and misc enhances

On Thu, Apr 06, 2017 at 03:08:35PM +0800, Peter Xu wrote: > This is v8 of vt-d vfio enablement series. > > v8 > - remove patches 1-9 since merged already > - add David's r-b for all the patches > - add Aviv's s-o-b in the last patch > - rename iommu to iommu_dmar [Jason] > - rename last patch

Re: [Qemu-devel] [PATCH 04/21] ppc/pnv: enable only one LPC bus

On 04/06/2017 11:16 AM, Benjamin Herrenschmidt wrote: > On Thu, 2017-04-06 at 11:06 +0200, Cédric Le Goater wrote: >> The object will be initialized which raises some concern because we don't >> have the chip id at the moment but the object is still valid in some way. >> I think I need to remove

Re: [Qemu-devel] [PATCH v8 3/9] memory: provide iommu_replay_all()

On Thu, Apr 06, 2017 at 12:52:19PM +0200, Auger Eric wrote: > Hi Peter, > > On 06/04/2017 09:08, Peter Xu wrote: > > This is an "global" version of exising memory_region_iommu_replay() - we > s/exising/existing > > announce the translations to all the registered notifiers, instead of a > >

Re: [Qemu-devel] [RFC PATCH for-2.9] block: Ignore guest dev permissions during incoming migration

On Thu, Apr 06, 2017 at 01:22:56PM +0200, Kevin Wolf wrote: > Am 05.04.2017 um 15:22 hat Max Reitz geschrieben: > > On 04.04.2017 17:35, Kevin Wolf wrote: > > > Usually guest devices don't like other writers to the same image, so > > > they use blk_set_perm() to prevent this from happening. In the

Re: [Qemu-devel] [PATCH v8 2/9] memory: provide IOMMU_NOTIFIER_FOREACH macro

Hi, On 06/04/2017 13:12, Peter Xu wrote: > On Thu, Apr 06, 2017 at 12:45:59PM +0200, Auger Eric wrote: >> Hi Peter, >> On 06/04/2017 09:08, Peter Xu wrote: >>> Reviewed-by: David Gibson >>> Signed-off-by: Peter Xu >> Even if the commit message is

Re: [Qemu-devel] [RFC PATCH for-2.9] block: Ignore guest dev permissions during incoming migration

Am 05.04.2017 um 15:22 hat Max Reitz geschrieben: > On 04.04.2017 17:35, Kevin Wolf wrote: > > Usually guest devices don't like other writers to the same image, so > > they use blk_set_perm() to prevent this from happening. In the migration > > phase before the VM is actually running, though, they

[Qemu-devel] [PATCH for-2.10 06/10] s390x/css: consolidate the devno property for ccw devices

From: Dong Jia Shi 'devno' should rather be a property of the ccw device, instead of a property of a specific virtio-ccw device. Let's consolidate it. While we are at here, also rename CcwDevice.bus_id to CcwDevice.devno to make things clearer. Signed-off-by: Dong

[Qemu-devel] [PATCH for-2.10 05/10] s390x/css: provide introspection for virtual subchannel and device busid

From: Dong Jia Shi Expose the busids of the virtual I/O subchannel and the virtual CCW device to ease debugging. This is needed because: 1. subchannel id are assigned dynamically, and cannot be set from outside. 2. device busid could possibly be auto generated.

[Qemu-devel] [PATCH for-2.10 07/10] s390x: use enum for adapter type and standardize its naming

From: Fei Li Let's use an enum for io adapter type, and standardize its naming to CSS_IO_ADAPTER_* by changing S390_PCIPT_ADAPTER to CSS_IO_ADAPTER_PCI. Signed-off-by: Fei Li Reviewed-by: Cornelia Huck

[Qemu-devel] [PATCH for-2.10 10/10] s390x: register I/O adapters per ISC during init

From: Fei Li The I/O adapters should exist as soon as the bus/infrastructure exists, and not only when the guest is actually trying to do something with them. While the lazy allocation was not wrong, allocating at init time is cleaner, both for the architecture and

[Qemu-devel] [PATCH for-2.10 02/10] s390x/kvm: make printf always compile in debug output

From: Danil Antonov Wrapped printf calls inside debug macros (DPRINTF) in `if` statement. This will ensure that printf function will always compile even if debug output is turned off and, in turn, will prevent bitrot of the format strings. Signed-off-by: Danil Antonov

[Qemu-devel] [PATCH for-2.10 09/10] s390x/flic: cache flic in s390_get_flic

From: Fei Li s390_get_flic() is called many times to obtain the flic. This wastes a lot of time as it calls object_resolve_path() every time. Let's cache S390FLICState by defining it as static. Signed-off-by: Fei Li Signed-off-by:

[Qemu-devel] [PATCH for-2.10 03/10] s390x/pci: make printf always compile in debug output

From: Danil Antonov Wrapped printf calls inside debug macros (DPRINTF) in `if` statement. This will ensure that printf function will always compile even if debug output is turned off and, in turn, will prevent bitrot of the format strings. Signed-off-by: Danil Antonov

[Qemu-devel] [PATCH for-2.10 08/10] s390x: initialize flic before I/O subsystems

From: Fei Li Let's have a flic before we move on to initialize more specific subsystems that make use of it. Signed-off-by: Fei Li Reviewed-by: Cornelia Huck Signed-off-by: Cornelia Huck

[Qemu-devel] [PATCH for-2.10 00/10] s390x queue for 2.10

Here's the first batch of s390x changes for 2.10: - the new compat machine - several cleanups and optimizations - introspection for css ids More to come; for example, the 3270 support I'd still like some feedback on (I'll resend a rebased version). Cornelia Huck (1): s390x: introduce 2.10

[Qemu-devel] [PATCH for-2.10 01/10] s390x: introduce 2.10 compat machine

Signed-off-by: Cornelia Huck --- hw/s390x/s390-virtio-ccw.c | 17 - include/hw/compat.h| 3 +++ 2 files changed, 19 insertions(+), 1 deletion(-) diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c index 40914fde6f..5ac315ac78

[Qemu-devel] [PATCH for-2.10 04/10] s390x/css: introduce read-only property type for device ids

From: Dong Jia Shi Let's introduce a read-only property type that handles device ids of the CssDevId type used for channel devices for future use. e.g. exposing the busid of an I/O subchannel that is assigned to a ccw device. Signed-off-by: Dong Jia Shi

Re: [Qemu-devel] [RFC PATCH for-2.9] block: Ignore guest dev permissions during incoming migration

Am 04.04.2017 um 17:35 hat Kevin Wolf geschrieben: > Usually guest devices don't like other writers to the same image, so > they use blk_set_perm() to prevent this from happening. In the migration > phase before the VM is actually running, though, they don't have a > problem with writes to the

Re: [Qemu-devel] [PATCH v8 2/9] memory: provide IOMMU_NOTIFIER_FOREACH macro

On Thu, Apr 06, 2017 at 12:45:59PM +0200, Auger Eric wrote: > Hi Peter, > On 06/04/2017 09:08, Peter Xu wrote: > > Reviewed-by: David Gibson > > Signed-off-by: Peter Xu > Even if the commit message is obvious it may be requested? Do you mean we'd

Re: [Qemu-devel] [PATCH v8 5/9] memory: add MemoryRegionIOMMUOps.replay() callback

Hi Peter, On 06/04/2017 09:08, Peter Xu wrote: > Originally we have one memory_region_iommu_replay() function, which is > the default behavior to replay the translations of the whole IOMMU > region. However, on some platform like x86, we may want our own replay > logic for IOMMU regions. This

Re: [Qemu-devel] [PATCH v8 4/9] memory: introduce memory_region_notify_one()

Hi Peter, On 06/04/2017 09:08, Peter Xu wrote: > Generalizing the notify logic in memory_region_notify_iommu() into a > single function. This can be further used in customized replay() > functions for IOMMUs. > > Reviewed-by: David Gibson > Signed-off-by: Peter Xu

Re: [Qemu-devel] [PATCH v8 1/9] memory: add section range info for IOMMU notifier

On Thu, Apr 06, 2017 at 12:42:54PM +0200, Auger Eric wrote: > Hi Peter, > On 06/04/2017 09:08, Peter Xu wrote: > > In this patch, IOMMUNotifier.{start|end} are introduced to store section > > information for a specific notifier. When notification occurs, we not > > only check the notification type

Re: [Qemu-devel] [RFC PATCH 4/4] nvdimm acpi: build flush hint address structure if required

On 04/06/17 11:13 +0100, Stefan Hajnoczi wrote: > On Fri, Mar 31, 2017 at 04:41:47PM +0800, Haozhong Zhang wrote: > > > > Add an boolean option 'flush-hint' to device 'nvdimm'. If it's on, a > > flush hint address structure will be constructed for each nvdimm > > device. > > Users should not

Re: [Qemu-devel] [PATCH v8 3/9] memory: provide iommu_replay_all()

Hi Peter, On 06/04/2017 09:08, Peter Xu wrote: > This is an "global" version of exising memory_region_iommu_replay() - we s/exising/existing > announce the translations to all the registered notifiers, instead of a > specific one. > > Reviewed-by: David Gibson >

Re: [Qemu-devel] Gsoc 2017

On Sun, Apr 02, 2017 at 09:56:32PM +0530, Ashish Gahlot wrote: > After talking to my mentor on the topic PCIe-PCI bridge, I have submitted > the proposal to gsoc web. I kindly request the community to provide your > valuable feedback by posting comments. Thanks Ashish. At this stage of GSoC only

Re: [Qemu-devel] [RFC PATCH 1/4] pc-dimm: add 'reserved-size' to reserve address range after the ending address

On 04/06/17 11:24 +0100, Stefan Hajnoczi wrote: > On Fri, Mar 31, 2017 at 04:41:44PM +0800, Haozhong Zhang wrote: > > If option 'reserved-size=RSVD' is present, QEMU will reserve an > > address range of size 'RSVD' after the ending address of pc-dimm > > device. > > > > For the following example,

Re: [Qemu-devel] [PATCH v8 2/9] memory: provide IOMMU_NOTIFIER_FOREACH macro

Hi Peter, On 06/04/2017 09:08, Peter Xu wrote: > Reviewed-by: David Gibson > Signed-off-by: Peter Xu Even if the commit message is obvious it may be requested? Reviewed-by: Eric Auger > --- > include/exec/memory.h | 3 +++

Re: [Qemu-devel] [Qemu-trivial] [PATCH] virtio-gpu: replace PIXMAN_* by PIXMAN_BE_*

On Mon, Apr 03, 2017 at 09:28:02AM -0300, Philippe Mathieu-Daudé wrote: > On 04/03/2017 08:40 AM, Laurent Vivier wrote: > > This avoids a "#ifdef HOST_WORDS_BIGENDIAN" and this is the purpose > > of PIXMAN_BE_* macros. > > > > Signed-off-by: Laurent Vivier > > Reviewed-by:

Re: [Qemu-devel] [PATCH v8 1/9] memory: add section range info for IOMMU notifier

Hi Peter, On 06/04/2017 09:08, Peter Xu wrote: > In this patch, IOMMUNotifier.{start|end} are introduced to store section > information for a specific notifier. When notification occurs, we not > only check the notification type (MAP|UNMAP), but also check whether the > notified iova range

Re: [Qemu-devel] Performance problem and improvement about block drive on NFS shares with libnfs

On Sat, Apr 01, 2017 at 01:23:46PM +0800, Jaden Liang wrote: > Hello, > > I ran qemu with drive file via libnfs recently, and found some performance > problem and an improvement idea. > > I started qemu with 6 drives parameter like > nfs://127.0.0.1/dir/vm-disk-x.qcow2 > which linked to a local

Re: [Qemu-devel] how to create threads like dataplane in qemu

On Sat, Apr 01, 2017 at 11:54:35AM +0800, PERSIST wrote: > I want to create a specific thread for each process in VM so that virtio > block requests from each process can be sumbitted in the thread related to > the process. > I tried to implement it by referring to dataplane,but I can not

Re: [Qemu-devel] [PULL 0/1] PC fix for 2.9.0-rc4

On 5 April 2017 at 16:26, Paolo Bonzini wrote: > The following changes since commit 87cc4c61020addea6a001b94b662596b1896d1b3: > > Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into > staging (2017-04-04 11:40:55 +0100) > > are available in the git

Re: [Qemu-devel] [RFC PATCH 0/4] nvdimm: enable flush hint address structure

On 04/06/17 10:43 +0100, Stefan Hajnoczi wrote: > On Fri, Mar 31, 2017 at 04:41:43PM +0800, Haozhong Zhang wrote: > > This patch series constructs the flush hint address structures for > > nvdimm devices in QEMU. > > > > It's of course not for 2.9. I send it out early in order to get > > comments

Re: [Qemu-devel] [RFC PATCH 4/4] nvdimm acpi: build flush hint address structure if required

On Fri, Mar 31, 2017 at 04:41:47PM +0800, Haozhong Zhang wrote: > +/* > + * ACPI 6.0: 5.2.25.7 Flush Hint Address Structure > + */ > +static void nvdimm_build_structure_flush_hint(GArray *structures, > + DeviceState *dev, > +

[Qemu-devel] [PATCH RFC v1 1/3] target/ppc: 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: Nikunj A Dadhania ---

[Qemu-devel] [PATCH RFC v1 2/3] cputlb: handle first atomic write to the page

In case where the conditional write is the first write to the page, TLB_NOTDIRTY will be set and stop_the_world is triggered. Handle this as a special case and set the dirty bit. After that fall through to the actual atomic instruction below. Signed-off-by: Nikunj A Dadhania

Re: [Qemu-devel] [RFC PATCH 1/4] pc-dimm: add 'reserved-size' to reserve address range after the ending address

On Fri, Mar 31, 2017 at 04:41:44PM +0800, Haozhong Zhang wrote: > If option 'reserved-size=RSVD' is present, QEMU will reserve an > address range of size 'RSVD' after the ending address of pc-dimm > device. > > For the following example, > -object memory-backend-file,id=mem0,size=4G,... >

[Qemu-devel] [PATCH RFC v1 0/3] Enable MTTCG on PPC64

The series enables Multi-Threaded TCG on PPC64 Patch 01: Use atomic_cmpxchg in store conditional 02: Handle first write to page during atomic operation 03: Generate memory barriers for sync/isync and load/store conditional Patches are based on ppc-for-2.10 Tested using following:

[Qemu-devel] [PATCH RFC v1 3/3] target/ppc: Generate fence operations

Signed-off-by: Nikunj A Dadhania --- target/ppc/translate.c | 5 + 1 file changed, 5 insertions(+) diff --git a/target/ppc/translate.c b/target/ppc/translate.c index a9c733d..87b4fe4 100644 --- a/target/ppc/translate.c +++ b/target/ppc/translate.c @@ -2971,6

Re: [Qemu-devel] [RFC PATCH 4/4] nvdimm acpi: build flush hint address structure if required

On Fri, Mar 31, 2017 at 04:41:47PM +0800, Haozhong Zhang wrote: > > Add an boolean option 'flush-hint' to device 'nvdimm'. If it's on, a > flush hint address structure will be constructed for each nvdimm > device. Users should not need to set the flush hint option. NVDIMM configurations that

Re: [Qemu-devel] [RFC PATCH 0/4] nvdimm: enable flush hint address structure

On 04/06/17 17:39 +0800, Xiao Guangrong wrote: > > > On 31/03/2017 4:41 PM, Haozhong Zhang wrote: > > This patch series constructs the flush hint address structures for > > nvdimm devices in QEMU. > > > > It's of course not for 2.9. I send it out early in order to get > > comments on one point

Re: [Qemu-devel] [RFC PATCH 0/4] nvdimm: enable flush hint address structure

On Fri, Mar 31, 2017 at 04:41:43PM +0800, Haozhong Zhang wrote: > This patch series constructs the flush hint address structures for > nvdimm devices in QEMU. > > It's of course not for 2.9. I send it out early in order to get > comments on one point I'm uncertain (see the detailed explanation >

Re: [Qemu-devel] [Qemu-block] New iotest repros failures on virtio external snapshot with iothread

On Tue, Apr 04, 2017 at 03:13:44PM +0100, Alex Bennée wrote: > > Stefan Hajnoczi writes: > > > On Wed, Mar 29, 2017 at 07:01:38PM -0700, Ed Swierk wrote: > >> Parts of qemu's block code have changed a lot in recent months but are > >> not well exercised by current tests. >

Re: [Qemu-devel] [PATCH v2 07/21] kvmclock: Remove user_creatable flag

On 04.04.2017 22:24, Eduardo Habkost wrote: > kvmclock should be used by guests only when the appropriate CPUID > feature flags are set on the VCPU, and it is automatically > created by kvmclock_create() when those feature flags are set. > This means creating a kvmclock device using -device is

Re: [Qemu-devel] [PATCH v2 00/21] qdev/sysbus: Set user_creatable=false by default on sysbus

On 04/04/2017 11:24 PM, Eduardo Habkost wrote: Changes v1 -> v2 * Rewrote series name and cover letter completely to not pretend we're fixing the q35 lack-of-sysbus-whitelist bug, and explain the motivation for the series. * Previous series name was: "sysbus: Don't

Re: [Qemu-devel] [PATCH v2 05/21] fdc: Remove user_creatable flag from sysbus-fdc & SUNW, fdtwo

On 04.04.2017 22:24, Eduardo Habkost wrote: > sysbus-fdc and SUNW,fdtwo devices need IRQs to be wired and mmio > to be mapped, and can't be used with -device. Unset > user_creatable on their device classes. > > Cc: John Snow > Cc: Kevin Wolf > Cc: Max Reitz

Re: [Qemu-devel] [PATCH v2 04/21] iommu: Remove FIXME comment about user_creatable=true

On 04/04/2017 11:24 PM, Eduardo Habkost wrote: amd-iommu and intel-iommu are really meant to be used with -device, so they need user_creatable=true. Remove the FIXME comment. Cc: Marcel Apfelbaum Cc: "Michael S. Tsirkin" Signed-off-by: Eduardo Habkost

Re: [Qemu-devel] [PATCH v2 01/21] qdev: Replace cannot_instantiate_with_device_add_yet with !user_creatable

On 04/05/2017 10:42 PM, Eduardo Habkost wrote: On Wed, Apr 05, 2017 at 10:01:29PM +0300, Marcel Apfelbaum wrote: On 04/04/2017 11:24 PM, Eduardo Habkost wrote: cannot_instantiate_with_device_add_yet was introduced by commit 837d37167dc446af8a91189108b363c04609e296 to replace no_user. It was

Re: [Qemu-devel] external snapshots freezes block device since qemu 2.8

* John Snow (js...@redhat.com) wrote: > > > On 03/09/2017 07:26 AM, Dr. David Alan Gilbert wrote: > > * Piotr Rybicki (piotr.rybi...@innervision.pl) wrote: > >> Hello there. > >> > >> I discovered, that since qemu 2.8 , external snapshots (very similar to: > >>

Re: [Qemu-devel] [PATCH v2 01/21] qdev: Replace cannot_instantiate_with_device_add_yet with !user_creatable

On 04.04.2017 22:24, Eduardo Habkost wrote: > cannot_instantiate_with_device_add_yet was introduced by commit > 837d37167dc446af8a91189108b363c04609e296 to replace no_user. It > was supposed to be a temporary measure. I think you rather meant commit efec3dd631d94160288392721a5f9c39e50fb2bc

Re: [Qemu-devel] [PATCH 04/21] ppc/pnv: enable only one LPC bus

On Thu, 2017-04-06 at 11:06 +0200, Cédric Le Goater wrote: > The object will be initialized which raises some concern because we don't  > have the chip id at the moment but the object is still valid in some way.  > I think I need to remove it from the list of children of the chip or use  > a

Re: [Qemu-devel] [PATCH v3 10/13] block: Simplify bdrv_append_temp_snapshot() logic

Am 05.04.2017 um 21:47 hat Eric Blake geschrieben: > Noticed while checking Coccinelle results. Naming a label 'out:' > when it is only used on error paths is weird; meanwhile we know > that snapshot_options is NULL on success and that QDECREF(NULL) > is safe. So merge the two exit paths into

Re: [Qemu-devel] [PATCH 04/21] ppc/pnv: enable only one LPC bus

On 04/06/2017 06:23 AM, David Gibson wrote: > On Wed, Apr 05, 2017 at 02:41:29PM +0200, Cédric Le Goater wrote: >> Multi chip systems only have one LPC bus, on chip 0. The PnvLPC object >> will still be created under the PnvChip objects but only the one under >> chip 0 will be advertise in the

Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs

Am 06.04.2017 um 10:48 hat Kevin Wolf geschrieben: > Am 05.04.2017 um 23:13 hat Paolo Bonzini geschrieben: > > On 05/04/2017 13:01, Kevin Wolf wrote: > > > Am 04.04.2017 um 17:09 hat Paolo Bonzini geschrieben: > > >> On 04/04/2017 16:53, Kevin Wolf wrote: > > The big question is how this fits

[Qemu-devel] about get approximative time of execution

im working in the reconstitution of execution trace informations of the guest processor in qemu and i need an approximative time of execution of every  translation block by the guest processor . can you give me some hints about that ? thank you

Re: [Qemu-devel] [Qemu-block] [PATCH v3 12/13] fdc-test: Avoid deprecated 'change' command

Am 05.04.2017 um 22:52 hat John Snow geschrieben: > On 04/05/2017 03:47 PM, Eric Blake wrote: > > Use the preferred blockdev-change-medium command instead. > > > > Admittedly, use of 'device' is also deprecated over the newer use > > of 'id', but the test is exploiting that the name 'floppy0' is

Re: [Qemu-devel] nbd: Possible regression in 2.9 RCs

Am 05.04.2017 um 23:13 hat Paolo Bonzini geschrieben: > On 05/04/2017 13:01, Kevin Wolf wrote: > > Am 04.04.2017 um 17:09 hat Paolo Bonzini geschrieben: > >> On 04/04/2017 16:53, Kevin Wolf wrote: > The big question is how this fits into release management. We have > another important

Re: [Qemu-devel] qemu_file_rate_limit

On Thu, Apr 06, 2017 at 12:43:16PM +0430, ali saeedi wrote: > Hi > what does 'qemu_file_rate_limit' function do? > thanks It returns 1 if the stream is not full (so that we can continue send something), otherwise 0. Generally, it's used like: if (qemu_file_rate_limit(f)) { /* we can

Re: [Qemu-devel] [PATCH v6] vfio error recovery: kernel support

On 04/06/2017 06:36 AM, Michael S. Tsirkin wrote: > On Wed, Apr 05, 2017 at 04:19:10PM -0600, Alex Williamson wrote: >> On Thu, 6 Apr 2017 00:50:22 +0300 >> "Michael S. Tsirkin" wrote: >> >>> On Wed, Apr 05, 2017 at 01:38:22PM -0600, Alex Williamson wrote: The previous

Re: [Qemu-devel] [PATCH v6] vfio error recovery: kernel support

On 04/06/2017 03:38 AM, Alex Williamson wrote: > On Wed, 5 Apr 2017 16:54:33 +0800 > Cao jin wrote: > >> Sorry for late. Distracted by other problem for a while. >> >> On 03/31/2017 02:16 AM, Alex Williamson wrote: >>> On Thu, 30 Mar 2017 21:00:35 +0300 >>

Re: [Qemu-devel] [PATCH v6] vfio error recovery: kernel support

On 04/06/2017 05:56 AM, Michael S. Tsirkin wrote: > On Wed, Apr 05, 2017 at 04:54:33PM +0800, Cao jin wrote: >> Apparently, I don't have experience to induce non-fatal error, device >> error is more of a chance related with the environment(temperature, >> humidity, etc) as I understand. > > I'm

Re: [Qemu-devel] Emulating external registers

On 5 April 2017 at 22:03, Wu, Michael Y [US] (MS) wrote: > My current approach is to create a new MemoryRegion in the init function of > the g3beige source code (mac_oldworld.c). My idea is to set up some mmio to > certain address to represent those registers. For now I only

[Qemu-devel] qemu_file_rate_limit

Hi what does 'qemu_file_rate_limit' function do? thanks

Re: [Qemu-devel] [PATCH 08/21] ipmi: introduce an ipmi_bmc_sdr_find() API

On 04/06/2017 09:36 AM, Cédric Le Goater wrote: > On 04/06/2017 07:36 AM, David Gibson wrote: >> On Wed, Apr 05, 2017 at 02:41:33PM +0200, Cédric Le Goater wrote: >>> This patch exposes a new IPMI routine to query a sdr entry from the >>> sdr table maintained by the IPMI BMC simulator. The API is

Re: [Qemu-devel] [PATCH v3 03/13] s390x: Drop useless casts

On Wed, 5 Apr 2017 14:47:31 -0500 Eric Blake wrote: > An upcoming Coccinelle cleanup script wanted to reformat the casts > present in this file - but on closer look, we don't need the casts > at all because C automatically converts void* to any other pointer. > >

Re: [Qemu-devel] [PATCH 08/21] ipmi: introduce an ipmi_bmc_sdr_find() API

On 04/06/2017 07:36 AM, David Gibson wrote: > On Wed, Apr 05, 2017 at 02:41:33PM +0200, Cédric Le Goater wrote: >> This patch exposes a new IPMI routine to query a sdr entry from the >> sdr table maintained by the IPMI BMC simulator. The API is very >> similar to the internal sdr_find_entry()

Re: [Qemu-devel] [PATCH 10/21] ipmi: add SET_SENSOR_READING command

On 04/05/2017 04:41 PM, Corey Minyard wrote: > On 04/05/2017 07:41 AM, Cédric Le Goater wrote: >> SET_SENSOR_READING is a complex IPMI command (IPMI spec : "35.17 Set >> Sensor Reading And Event Status Command"). Here is a very minimum >> framework fitting the Open PowerNV platform needs. This

Re: [Qemu-devel] [PATCH 08/21] ipmi: introduce an ipmi_bmc_sdr_find() API

On Wed, Apr 05, 2017 at 02:41:33PM +0200, Cédric Le Goater wrote: > This patch exposes a new IPMI routine to query a sdr entry from the > sdr table maintained by the IPMI BMC simulator. The API is very > similar to the internal sdr_find_entry() routine and should be used > the same way to query

[Qemu-devel] [PATCH v8 9/9] intel_iommu: enable remote IOTLB

This patch is based on Aviv Ben-David ()'s patch upstream: "IOMMU: enable intel_iommu map and unmap notifiers" https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg01453.html However I removed/fixed some content, and added my own codes. Instead of translate() every

[Qemu-devel] [PATCH v8 6/9] intel_iommu: use the correct memory region for device IOTLB notification

From: Jason Wang We have a specific memory region for DMAR now, so it's wrong to trigger the notifier with the root region. Cc: Michael S. Tsirkin Cc: Paolo Bonzini Cc: Richard Henderson Cc: Eduardo Habkost

[Qemu-devel] [PATCH v8 8/9] intel_iommu: allow dynamic switch of IOMMU region

This is preparation work to finally enabled dynamic switching ON/OFF for VT-d protection. The old VT-d codes is using static IOMMU address space, and that won't satisfy vfio-pci device listeners. Let me explain. vfio-pci devices depend on the memory region listener and IOMMU replay mechanism to

[Qemu-devel] [PATCH v8 5/9] memory: add MemoryRegionIOMMUOps.replay() callback

Originally we have one memory_region_iommu_replay() function, which is the default behavior to replay the translations of the whole IOMMU region. However, on some platform like x86, we may want our own replay logic for IOMMU regions. This patch add one more hook for IOMMUOps for the callback, and

[Qemu-devel] [PATCH v8 7/9] intel_iommu: provide its own replay() callback

The default replay() don't work for VT-d since vt-d will have a huge default memory region which covers address range 0-(2^64-1). This will normally consumes a lot of time (which looks like a dead loop). The solution is simple - we don't walk over all the regions. Instead, we jump over the

[Qemu-devel] [PATCH v8 1/9] memory: add section range info for IOMMU notifier

In this patch, IOMMUNotifier.{start|end} are introduced to store section information for a specific notifier. When notification occurs, we not only check the notification type (MAP|UNMAP), but also check whether the notified iova range overlaps with the range of specific IOMMU notifier, and skip

<    1   2   3   4   >