Re: [Qemu-devel] [PATCH RFC v3 02/14] intel_iommu: simplify irq region translation

> From: Peter Xu [mailto:pet...@redhat.com] > Sent: Friday, January 13, 2017 11:06 AM > > Before we have int-remap, we need to bypass interrupt write requests. > That's not necessary now - we have supported int-remap, and all the irq > region requests should be redirected there. Cleaning up the bl

Re: [Qemu-devel] [PATCH v6 4/5] migration: disallow migrate_add_blocker during migration

On Mon, 16 Jan 2017 17:01:53 +0530 Ashijeet Acharya wrote: > If a migration is already in progress and somebody attempts > to add a migration blocker, this should rightly fail. > > Add an errp parameter and a retcode return value to migrate_add_blocker. > > Signed-off-by: John Snow > Signed-of

Re: [Qemu-devel] [PATCH RFC v3 03/14] intel_iommu: renaming gpa to iova where proper

> From: Peter Xu [mailto:pet...@redhat.com] > Sent: Friday, January 13, 2017 11:06 AM > > There are lots of places in current intel_iommu.c codes that named > "iova" as "gpa". It is really confusing to use a name "gpa" in these > places (which is very easily to be understood as "Guest Physical > A

Re: [Qemu-devel] [PATCH RFC v3 01/14] IOMMU: add option to enable VTD_CAP_CM to vIOMMU capility exposoed to guest

> From: Peter Xu [mailto:pet...@redhat.com] > Sent: Friday, January 13, 2017 11:06 AM > > From: Aviv Ben-David > > This capability asks the guest to invalidate cache before each map operation. > We can use this invalidation to trap map operations in the hypervisor. > > Signed-off-by: Aviv Ben-D

Re: [Qemu-devel] [PATCH RFC v3 01/14] IOMMU: add option to enable VTD_CAP_CM to vIOMMU capility exposoed to guest

On Fri, Jan 20, 2017 at 08:32:06AM +, Tian, Kevin wrote: > > From: Peter Xu [mailto:pet...@redhat.com] > > Sent: Friday, January 13, 2017 11:06 AM > > > > From: Aviv Ben-David > > > > This capability asks the guest to invalidate cache before each map > > operation. > > We can use this inval

Re: [Qemu-devel] [PATCH RFC v3 01/14] IOMMU: add option to enable VTD_CAP_CM to vIOMMU capility exposoed to guest

> From: Peter Xu [mailto:pet...@redhat.com] > Sent: Friday, January 20, 2017 4:55 PM > > On Fri, Jan 20, 2017 at 08:32:06AM +, Tian, Kevin wrote: > > > From: Peter Xu [mailto:pet...@redhat.com] > > > Sent: Friday, January 13, 2017 11:06 AM > > > > > > From: Aviv Ben-David > > > > > > This cap

Re: [Qemu-devel] [PATCH RFC v3 02/14] intel_iommu: simplify irq region translation

On Fri, Jan 20, 2017 at 08:22:14AM +, Tian, Kevin wrote: > > From: Peter Xu [mailto:pet...@redhat.com] > > Sent: Friday, January 13, 2017 11:06 AM > > > > Before we have int-remap, we need to bypass interrupt write requests. > > That's not necessary now - we have supported int-remap, and all t

Re: [Qemu-devel] [PATCH RFC v3 01/14] IOMMU: add option to enable VTD_CAP_CM to vIOMMU capility exposoed to guest

On Fri, Jan 20, 2017 at 08:59:01AM +, Tian, Kevin wrote: [...] > > > Also for hot-add > > > device path, some check of caching mode is required. If not set, > > > should we fail hot-add operation? I don't think we have such physical > > > platform with some devices behind IOMMU while others n

Re: [Qemu-devel] [PATCH RFC v3 02/14] intel_iommu: simplify irq region translation

> From: Peter Xu [mailto:pet...@redhat.com] > Sent: Friday, January 20, 2017 5:05 PM > > On Fri, Jan 20, 2017 at 08:22:14AM +, Tian, Kevin wrote: > > > From: Peter Xu [mailto:pet...@redhat.com] > > > Sent: Friday, January 13, 2017 11:06 AM > > > > > > Before we have int-remap, we need to bypas

[Qemu-devel] [PULL v2 05/12] s390x/pci: dynamically allocate iommu

From: Yi Min Zhao When initializing a PCI device, an address space is required during PCI core initialization and before the call to the embedding object hotplug callback. To provide this AS, we allocate a S390PCIIOMMU object containing this AS. Initialization of S390PCIIOMMU object is done befor

[Qemu-devel] [PULL v2 01/12] s390x: remove double compat statement

From: Christian Borntraeger We chain our compat handler via the CCW_COMPAT macros and via the class_init function. (e.g. ccw_machine_2_7_class_options calls ccw_machine_2_8_class_options). As all class_init functions in that chain call SET_MACHINE_COMPAT for their compat settings, and SET_MACHINE

[Qemu-devel] [PULL v2 02/12] s390x: add compat machine for 2.9

Signed-off-by: Cornelia Huck Acked-by: Christian Borntraeger --- hw/s390x/s390-virtio-ccw.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c index dbf4f01165..e9a676797a 100644 --- a/hw/s390x/s390-virtio

[Qemu-devel] [PULL v2 03/12] s390x/kvm: use kvm_gsi_routing_enabled in flic

From: Fei Li Let's use kvm_gsi_routing_enabled() to check if kvm supports KVM_CAP_IRQ_ROUTING in order to avoid a needless ioctl invocation. Signed-off-by: Fei Li Signed-off-by: Cornelia Huck --- hw/intc/s390_flic_kvm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/h

[Qemu-devel] [PULL v2 00/12] s390x update

The following changes since commit 0f6bcf68a99efdc531b209551f2b760b0bdcc554: Merge remote-tracking branch 'remotes/artyom/tags/pull-sun4v-20170118' into staging (2017-01-19 18:34:13 +) are available in the git repository at: git://github.com/cohuck/qemu tags/s390x-20170120-v

[Qemu-devel] [PULL v2 07/12] s390x/pci: optimize calling s390_get_phb()

From: Yi Min Zhao A function may recursively call device search functions or may call serveral different device search function. Passing the S390pciState to search functions as an argument instead of looking up it inside the search functions lowers the number of calling s390_get_phb(). Signed-of

[Qemu-devel] [PULL v2 10/12] s390x/pci: handle PCIBridge bus number

From: Pierre Morel The PCI bus number is usually set by the host during the enumeration. In the s390 architecture we neither get a Device Tree nor have an enumeration understanding bridge devices. Let's fake the enumeration on reset and set the PCI_PRIMARY_BUS, PCI_SECONDARY_BUS and PCI_SUBORDI

[Qemu-devel] [PULL v2 04/12] s390x/pci: make S390PCIIOMMU inherit Object

From: Yi Min Zhao Currently S390PCIIOMMU is a normal struct. Let's make it inherit Object in order to take advantage of QOM. In addition, we move some stuff related to IOMMU from S390PCIBusDevice to S390PCIIOMMU. Signed-off-by: Yi Min Zhao Acked-by: Pierre Morel Signed-off-by: Cornelia Huck -

[Qemu-devel] [PULL v2 09/12] s390x/pci: use hashtable to look up zpci via fh

From: Yi Min Zhao After PCI multibus is supported, more than 32 PCI devices could be plugged. The current implementation of s390_pci_find_dev_by_fh() appears low performance if there's a huge number of PCI devices plugged. Therefore we introduce a hashtable using idx as key to store zpci device's

[Qemu-devel] [PULL v2 12/12] virtio-ccw: fix ring sizing

From: "Michael S. Tsirkin" Current code seems to assume ring size is always decreased but this is not required by spec: what spec says is just that size can not exceed the maximum. Fix it up. Signed-off-by: Michael S. Tsirkin Message-Id: <1484256243-1982-1-git-send-email-...@redhat.com> Signed-

Re: [Qemu-devel] [PATCH RFC v3 02/14] intel_iommu: simplify irq region translation

On Fri, Jan 20, 2017 at 09:15:27AM +, Tian, Kevin wrote: > > From: Peter Xu [mailto:pet...@redhat.com] > > Sent: Friday, January 20, 2017 5:05 PM > > > > On Fri, Jan 20, 2017 at 08:22:14AM +, Tian, Kevin wrote: > > > > From: Peter Xu [mailto:pet...@redhat.com] > > > > Sent: Friday, January

[Qemu-devel] [PULL v2 06/12] s390x/pci: change the device array to a list

From: Pierre Morel In order to support a greater number of devices we use a QTAILQ list of devices instead of a limited array. This leads us to change: - every lookup function s390_pci_find_xxx() for QTAILQ - the FH_MASK_INDEX to index up to 65536 devices Signed-off-by: Pierre Morel Signed-off

[Qemu-devel] [RFC PATCH v1] softfloat: Add round-to-odd rounding mode

Power ISA 3.0 introduces a few quadruple precision floating point instructions that support round-to-odd rounding mode. The round-to-odd mode is explained as under: Let Z be the intermediate arithmetic result or the operand of a convert operation. If Z can be represented exactly in the target form

[Qemu-devel] [PULL v2 08/12] s390x/pci: PCI multibus bridge handling

From: Pierre Morel When the hotplug handler detects a PCI bridge, the secondary bus has been initialized by the core PCI code. We give the secondary bus the bridge name and associate to it the IOMMU handling and hotplug/hotunplug callbacks. Signed-off-by: Pierre Morel Signed-off-by: Cornelia Hu

Re: [Qemu-devel] [PATCH RFC v3 03/14] intel_iommu: renaming gpa to iova where proper

On Fri, Jan 20, 2017 at 08:27:31AM +, Tian, Kevin wrote: > > From: Peter Xu [mailto:pet...@redhat.com] > > Sent: Friday, January 13, 2017 11:06 AM > > > > There are lots of places in current intel_iommu.c codes that named > > "iova" as "gpa". It is really confusing to use a name "gpa" in these

Re: [Qemu-devel] [PATCH RFC v3 01/14] IOMMU: add option to enable VTD_CAP_CM to vIOMMU capility exposoed to guest

> From: Peter Xu [mailto:pet...@redhat.com] > Sent: Friday, January 20, 2017 5:12 PM > > On Fri, Jan 20, 2017 at 08:59:01AM +, Tian, Kevin wrote: > > [...] > > > > > Also for hot-add > > > > device path, some check of caching mode is required. If not set, > > > > should we fail hot-add opera

[Qemu-devel] [PULL v2 11/12] s390x/pci: merge msix init functions

From: Yi Min Zhao Currently there're two functions, s390_pci_setup_msix() and s390_pci_msix_init(), for msix initialization, and being called once for each zpci device plugging. Let's integrate them. Moreover msix is mandatory in s390 architecture. So we ensure the pci device being plugged suppo

Re: [Qemu-devel] [PATCH RFC v3 01/14] IOMMU: add option to enable VTD_CAP_CM to vIOMMU capility exposoed to guest

On Fri, Jan 20, 2017 at 09:20:01AM +, Tian, Kevin wrote: > > From: Peter Xu [mailto:pet...@redhat.com] > > Sent: Friday, January 20, 2017 5:12 PM > > > > On Fri, Jan 20, 2017 at 08:59:01AM +, Tian, Kevin wrote: > > > > [...] > > > > > > > Also for hot-add > > > > > device path, some chec

Re: [Qemu-devel] [RFC PATCH v0] softfloat: Add round-to-odd rounding mode

On Thu, Jan 19, 2017 at 07:29:54AM -0800, Richard Henderson wrote: > On 01/18/2017 09:14 PM, Bharata B Rao wrote: > > Power ISA 3.0 introduces a few quadruple precision floating point > > instructions that support round-to-add rounding mode. The > > round-to-odd mode is explained as under: > > > >

Re: [Qemu-devel] [PATCH v3 2/4] compiler: rework BUG_ON using a struct

* Michael S. Tsirkin (m...@redhat.com) wrote: > There are theoretical concerns that some compilers might not trigger > build failures on attempts to define an array of size -1 and make it a > variable sized array instead. Let rewrite using a struct with a negative > bit field size instead as there

Re: [Qemu-devel] [PATCH v2 3/3] block: get max_transfer limit for char (scsi-generic) devices

On Thu, 01/19 21:51, Eric Farman wrote: > Commit 6f607174 introduced a routine to get the maximum number > of bytes for a single I/O transfer for block devices, however > scsi generic devices are character devices, not block. Add > a condition for this, such that scsi generic devices can view > th

Re: [Qemu-devel] [PULL 00/12] s390x update

On Thu, 19 Jan 2017 18:32:44 + Peter Maydell wrote: > Hi; I'm afraid this fails to build on Windows: > > /home/petmay01/linaro/qemu-for-merges/hw/s390x/s390-pci-bus.c: In > function ‘s390_pci_get_iommu’: > /home/petmay01/linaro/qemu-for-merges/hw/s390x/s390-pci-bus.c:415:20: > error: cast fr

[Qemu-devel] [PATCH 0/2] block/nfs: fix segfault and naming of runtime opts

commit 94d6a7a accidently left the naming of runtime opts and QAPI scheme inconsistent. Furthermore a NULL pointer dereference resulted in a segfault when parsing URI parameters. Peter Lieven (2): block/nfs: fix NULL pointer dereference in URI parsing block/nfs: fix naming of runtime opts bl

[Qemu-devel] [PATCH 1/2] block/nfs: fix NULL pointer dereference in URI parsing

parse_uint_full wants to put the parsed value into the variabled passed via its second argument which is NULL. Fixes: 94d6a7a76e9df9919629428f6c598e2b97d9426c Cc: qemu-sta...@nongnu.org Signed-off-by: Peter Lieven --- block/nfs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --gi

Re: [Qemu-devel] [PATCH RFC v3 03/14] intel_iommu: renaming gpa to iova where proper

> From: Peter Xu [mailto:pet...@redhat.com] > Sent: Friday, January 20, 2017 5:24 PM > > On Fri, Jan 20, 2017 at 08:27:31AM +, Tian, Kevin wrote: > > > From: Peter Xu [mailto:pet...@redhat.com] > > > Sent: Friday, January 13, 2017 11:06 AM > > > > > > There are lots of places in current intel_

[Qemu-devel] [PATCH 2/2] block/nfs: fix naming of runtime opts

commit 94d6a7a accidently left the naming of runtime opts and QAPI scheme inconsistent. As one consequence passing of parameters in the URI is broken. Sync the naming of the runtime opts to the QAPI scheme. Fixes: 94d6a7a76e9df9919629428f6c598e2b97d9426c Cc: qemu-sta...@nongnu.org Signed-off-by: P

Re: [Qemu-devel] [PATCH RFC v3 02/14] intel_iommu: simplify irq region translation

> From: Peter Xu [mailto:pet...@redhat.com] > Sent: Friday, January 20, 2017 5:28 PM > > On Fri, Jan 20, 2017 at 09:15:27AM +, Tian, Kevin wrote: > > > From: Peter Xu [mailto:pet...@redhat.com] > > > Sent: Friday, January 20, 2017 5:05 PM > > > > > > On Fri, Jan 20, 2017 at 08:22:14AM +, T

Re: [Qemu-devel] [PULL 00/12] s390x update

On 20.01.2017 10:21, Cornelia Huck wrote: > On Thu, 19 Jan 2017 18:32:44 + > Peter Maydell wrote: > >> Hi; I'm afraid this fails to build on Windows: >> >> /home/petmay01/linaro/qemu-for-merges/hw/s390x/s390-pci-bus.c: In >> function ‘s390_pci_get_iommu’: >> /home/petmay01/linaro/qemu-for-mer

Re: [Qemu-devel] [PATCH] display: cirrus: check vga bits per pixel(bpp) value

On Wed, Jan 11, 2017 at 09:43:41PM +0100, Gerd Hoffmann wrote: > On Mi, 2017-01-11 at 16:59 +0200, Alberto Garcia wrote: > > On Mon, Nov 28, 2016 at 11:52:08AM +0530, P J P wrote: > > > | > --- a/hw/display/cirrus_vga.c > > > | > +++ b/hw/display/cirrus_vga.c > > > | > @@ -272,6 +272,9 @@ static vo

Re: [Qemu-devel] [PATCH v2 3/3] block: get max_transfer limit for char (scsi-generic) devices

On Fri, 01/20 17:31, Fam Zheng wrote: > > diff --git a/block/file-posix.c b/block/file-posix.c > > index 2115155..94068ca 100644 > > --- a/block/file-posix.c > > +++ b/block/file-posix.c > > @@ -657,9 +657,11 @@ static int > > hdev_get_max_transfer_length(BlockDriverState *bs, int fd) > > int

Re: [Qemu-devel] [PULL 00/12] s390x update

On 20.01.2017 10:52, Thomas Huth wrote: > On 20.01.2017 10:21, Cornelia Huck wrote: >> On Thu, 19 Jan 2017 18:32:44 + >> Peter Maydell wrote: >> >>> Hi; I'm afraid this fails to build on Windows: >>> >>> /home/petmay01/linaro/qemu-for-merges/hw/s390x/s390-pci-bus.c: In >>> function ‘s390_pci_g

Re: [Qemu-devel] [PULL 00/12] s390x update

On Fri, 20 Jan 2017 10:52:26 +0100 Thomas Huth wrote: > On 20.01.2017 10:21, Cornelia Huck wrote: > > On Thu, 19 Jan 2017 18:32:44 + > > Peter Maydell wrote: > > > >> Hi; I'm afraid this fails to build on Windows: > >> > >> /home/petmay01/linaro/qemu-for-merges/hw/s390x/s390-pci-bus.c: In >

Re: [Qemu-devel] [PATCH RFC v3 02/14] intel_iommu: simplify irq region translation

On Fri, Jan 20, 2017 at 09:52:01AM +, Tian, Kevin wrote: [...] > btw what about guest setups a valid mapping at 0xFEEx_ in > its remapping structure, which is then programmed to virtual > device as DMA destination? Then when emulating that virtual DMA, > vtd_do_iommu_translate should simp

Re: [Qemu-devel] [PULL 00/12] s390x update

On 20.01.2017 11:00, Cornelia Huck wrote: > On Fri, 20 Jan 2017 10:52:26 +0100 > Thomas Huth wrote: > >> On 20.01.2017 10:21, Cornelia Huck wrote: >>> On Thu, 19 Jan 2017 18:32:44 + >>> Peter Maydell wrote: >>> Hi; I'm afraid this fails to build on Windows: /home/petmay01/lina

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

On 01/20/2017 04:16 AM, Michael S. Tsirkin wrote: > This is a design and an initial patch for kernel side for AER > support in VFIO. > > 0. What happens now (PCIE AER only) >Fatal errors cause a link reset. >Non fatal errors don't. >All errors stop the VM eventually, but not immediat

Re: [Qemu-devel] [PULL 00/12] s390x update

On Fri, 20 Jan 2017 11:04:29 +0100 Thomas Huth wrote: > On 20.01.2017 11:00, Cornelia Huck wrote: > > On Fri, 20 Jan 2017 10:52:26 +0100 > > Thomas Huth wrote: > > > >> On 20.01.2017 10:21, Cornelia Huck wrote: > >>> On Thu, 19 Jan 2017 18:32:44 + > >>> Peter Maydell wrote: > >>> > Hi

Re: [Qemu-devel] [PATCH v2 07/11] aspeed/smc: handle SPI flash Command mode

On 19 January 2017 at 20:35, Cédric Le Goater wrote: > On 01/19/2017 08:26 PM, Peter Maydell wrote: >> On 9 January 2017 at 16:24, Cédric Le Goater wrote: >>> The Aspeed SMC controllers have a mode (Command mode) in which >>> accesses to the flash content are no different than doing MMIOs. The >>

Re: [Qemu-devel] [PATCH 0/6] i386: Add "max" CPU model to TCG and KVM

On 19 January 2017 at 21:04, Eduardo Habkost wrote: > This is v2 of the previous series that enabled the "host" CPU > model on TCG. Now a new "max" CPU is being added, while keeping > "host" KVM-specific. > > In addition to simply adding "max" as a copy of the existing > "host" CPU model, addition

Re: [Qemu-devel] [PATCH v2 07/11] aspeed/smc: handle SPI flash Command mode

On 01/20/2017 11:13 AM, Peter Maydell wrote: > On 19 January 2017 at 20:35, Cédric Le Goater wrote: >> On 01/19/2017 08:26 PM, Peter Maydell wrote: >>> On 9 January 2017 at 16:24, Cédric Le Goater wrote: The Aspeed SMC controllers have a mode (Command mode) in which accesses to the flas

[Qemu-devel] [qemu PATCH] pc.h: move x-mach-use-reliable-get-clock compat entry to PC_COMPAT_2_8

As noticed by David Gilbert, commit 6053a86 'kvmclock: reduce kvmclock differences on migration' added 'x-mach-use-reliable-get-clock' and a compatibility entry that turns it off; however it got merged after 2.8.0 was released but the entry has gone into PC_COMPAT_2_7 where it should have gone int

Re: [Qemu-devel] kvmclock in wrong compat macro?

On Wed, Jan 18, 2017 at 04:03:08PM +, Dr. David Alan Gilbert wrote: > Hi Marcelo, >In commit 6053a86 'kvmclock: reduce kvmclock differences on migration' > you add a 'x-mach-use-reliable-get-clock' and a compatibility entry > that turns it off; if I'm reading it right though it got merged >

Re: [Qemu-devel] [RFC PATCH v1] softfloat: Add round-to-odd rounding mode

On 20 January 2017 at 09:17, Bharata B Rao wrote: > Power ISA 3.0 introduces a few quadruple precision floating point > instructions that support round-to-odd rounding mode. The > round-to-odd mode is explained as under: > > Let Z be the intermediate arithmetic result or the operand of a convert >

Re: [Qemu-devel] [PATCH v7 26/27] tcg: enable MTTCG by default for ARM on x86 hosts

Pranith Kumar writes: > Alex Bennée writes: > >> This enables the multi-threaded system emulation by default for ARMv7 >> and ARMv8 guests using the x86_64 TCG backend. This is because on the >> guest side: >> >> - The ARM translate.c/translate-64.c have been converted to >> - use MTTCG sa

Re: [Qemu-devel] [qemu PATCH] pc.h: move x-mach-use-reliable-get-clock compat entry to PC_COMPAT_2_8

* Marcelo Tosatti (mtosa...@redhat.com) wrote: > > As noticed by David Gilbert, commit 6053a86 'kvmclock: reduce kvmclock > differences on migration' added 'x-mach-use-reliable-get-clock' and a > compatibility entry that turns it off; however it got merged after 2.8.0 > was released but the entry

Re: [Qemu-devel] [PATCH v2 07/11] aspeed/smc: handle SPI flash Command mode

On 01/20/2017 11:17 AM, Cédric Le Goater wrote: > On 01/20/2017 11:13 AM, Peter Maydell wrote: >> On 19 January 2017 at 20:35, Cédric Le Goater wrote: >>> On 01/19/2017 08:26 PM, Peter Maydell wrote: On 9 January 2017 at 16:24, Cédric Le Goater wrote: > The Aspeed SMC controllers have a

Re: [Qemu-devel] [PATCH v2 3/3] block: get max_transfer limit for char (scsi-generic) devices

On 01/20/2017 04:53 AM, Fam Zheng wrote: On Fri, 01/20 17:31, Fam Zheng wrote: diff --git a/block/file-posix.c b/block/file-posix.c index 2115155..94068ca 100644 --- a/block/file-posix.c +++ b/block/file-posix.c @@ -657,9 +657,11 @@ static int hdev_get_max_transfer_length(BlockDriverState *bs

[Qemu-devel] [PULL v2 00/36] target-arm queue

o staging (2017-01-19 18:34:13 +) are available in the git repository at: git://git.linaro.org/people/pmaydell/qemu-arm.git tags/pull-target-arm-20170120 for you to fetch changes up to f29cacfb5fc0a6e93efc3f6d2900d82d625f143e: hw/arm/virt: Add board property to enable EL2 (2017-01-20 11:1

Re: [Qemu-devel] [RFC PATCH v1] softfloat: Add round-to-odd rounding mode

On Fri, Jan 20, 2017 at 10:28:22AM +, Peter Maydell wrote: > On 20 January 2017 at 09:17, Bharata B Rao wrote: > > Power ISA 3.0 introduces a few quadruple precision floating point > > instructions that support round-to-odd rounding mode. The > > round-to-odd mode is explained as under: > > >

Re: [Qemu-devel] [RFC PATCH v1] softfloat: Add round-to-odd rounding mode

On 20 January 2017 at 11:36, Bharata B Rao wrote: > On Fri, Jan 20, 2017 at 10:28:22AM +, Peter Maydell wrote: >> This isn't sufficient, because it won't do the right thing >> in the code which is picking between "round to infinity" and >> "round to largest/smallest representable number". That

Re: [Qemu-devel] [PATCH v6 kernel 3/5] virtio-balloon: speed up inflate/deflate process

* Liang Li (liang.z...@intel.com) wrote: > +static void free_extended_page_bitmap(struct virtio_balloon *vb) > +{ > + int i, bmap_count = vb->nr_page_bmap; > + > + for (i = 1; i < bmap_count; i++) { > + kfree(vb->page_bitmap[i]); > + vb->page_bitmap[i] = NULL; > +

[Qemu-devel] [Bug 1657538] Re: qemu 2.7.x 2.8 softmmu dont work on BE machine

Something else to try: Could you please check whether you get any output when you run "qemu-system-ppc -nographic" on your system? So we can make sure that it is not related to GTK or something similar... -- You received this bug notification because you are a member of qemu- devel-ml, which is s

[Qemu-devel] [Bug 1657538] Re: qemu 2.7.x 2.8 softmmu dont work on BE machine

I can not reproduce this issue. QEMU 2.8 works fine here on a POWER8 big endian host (running RHEL7). Can you still run older versions of QEMU that used to work for you in the past, to check whether it is QEMU or whether it is Ubuntu 16.10 that is causing the trouble here? Could you please also pos

Re: [Qemu-devel] Towards an ivshmem 2.0?

On Tuesday, January 17, 2017 5:46 PM, Jan Kiszka wrote: > On 2017-01-17 10:13, Wang, Wei W wrote: > > Hi Jan, > > > > On Monday, January 16, 2017 9:10 PM, Jan Kiszka wrote: > >> On 2017-01-16 13:41, Marc-André Lureau wrote: > >>> On Mon, Jan 16, 2017 at 12:37 PM Jan Kiszka >>>

[Qemu-devel] [PATCH] Introduce DEVICE_CATEGORY_CPU for CPU devices

Now that the hot-pluggable CPUs show up in the help text of "-device ?", we should group them into an appropriate category. Signed-off-by: Thomas Huth --- hw/ppc/pnv_core.c | 1 + hw/ppc/spapr_cpu_core.c | 1 + include/hw/qdev-core.h | 1 + qdev-monitor.c | 1 + target/i386/cpu.c

Re: [Qemu-devel] [PATCH v3 4/4] ARRAY_SIZE: check that argument is an array

On 20/01/2017 08:34, Markus Armbruster wrote: > Eric Blake writes: > >> On 01/19/2017 04:11 PM, Michael S. Tsirkin wrote: >> > +#define QEMU_IS_ARRAY(x) (!__builtin_types_compatible_p(typeof(x), \ > +typeof(&(x)[0]))) > #ifnde

Re: [Qemu-devel] [PATCH] bitmap: assert that start and nr are non negative

On 19/01/2017 17:43, Peter Lieven wrote: > commit e1123a3b introduced a data corruption regression > in the iscsi driver because it passed -1 as nr to bitmap_set > and bitmap_clear. Add an assertion to catch such flaws earlier. > > Suggested-by: Fam Zheng > Signed-off-by: Peter Lieven > --- >

Re: [Qemu-devel] [qemu PATCH] pc.h: move x-mach-use-reliable-get-clock compat entry to PC_COMPAT_2_8

On 18/01/2017 18:53, Marcelo Tosatti wrote: > > As noticed by David Gilbert, commit 6053a86 'kvmclock: reduce kvmclock > differences on migration' added 'x-mach-use-reliable-get-clock' and a > compatibility entry that turns it off; however it got merged after 2.8.0 > was released but the entry h

Re: [Qemu-devel] [PATCH] Introduce DEVICE_CATEGORY_CPU for CPU devices

On 20/01/2017 13:18, Thomas Huth wrote: > Now that the hot-pluggable CPUs show up in the help text of > "-device ?", we should group them into an appropriate category. > > Signed-off-by: Thomas Huth > --- > hw/ppc/pnv_core.c | 1 + > hw/ppc/spapr_cpu_core.c | 1 + > include/hw/qdev-core.h

Re: [Qemu-devel] [PATCH RFC 0/3] vfio: allow to notify unmap for very big region

On Fri, Jan 20, 2017 at 11:43:28AM +0800, Peter Xu wrote: [...] > > What I don't want to see is for this API bug to leak out into the rest > > of the QEMU code such that intel_iommu code, or iommu code in general > > subtly avoids it by artificially using a smaller range. VT-d hardware > > has a

[Qemu-devel] [PATCH v2 0/2] hw/usb/dev-hid: Make usb-tablet work with OS X/macOS guests

This series makes the Qemu usb-tablet work correctly with OS X/macOS guests without the need for a special guest driver. * The usb-tablet should not have a boot protocol of 2. Other OSes seem to ignore this, but the IOHIDFamily driver stack chokes on it for anything but conventional (relative

[Qemu-devel] [PATCH v2 2/2] hw/usb/dev-hid: add a usb-tablet Mac guest compatibility option

Darwin/OS X/macOS's HID driver stack previously did not correctly drive Qemu's simulated USB Tablet. This adds a boolean option "mac_compat" to the device which subtly changes the device's report descriptor so it behaves in a way that Mac guests can handle. Absolute pointing devices with HID Re

Re: [Qemu-devel] [PATCH] Introduce DEVICE_CATEGORY_CPU for CPU devices

On 20 January 2017 at 12:18, Thomas Huth wrote: > Now that the hot-pluggable CPUs show up in the help text of > "-device ?", we should group them into an appropriate category. > > Signed-off-by: Thomas Huth > --- > hw/ppc/pnv_core.c | 1 + > hw/ppc/spapr_cpu_core.c | 1 + > include/hw/qdev

[Qemu-devel] [PATCH v2 1/2] hw/usb/dev-hid: set bInterfaceProtocol to 0x00 for usb-tablet

This should be non-zero for boot protocol devices only, which the usb-tablet is not. A boot protocol of 0x02 specifically confuses OS X/macOS' HID driver stack, causing it to generate additional bogus HID events with relative motion in addition to the tablet's absolute coordinate events. Signe

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

; > Merge remote-tracking branch 'remotes/artyom/tags/pull-sun4v-20170118' into > staging (2017-01-19 18:34:13 +) > > are available in the git repository at: > > git://git.linaro.org/people/pmaydell/qemu-arm.git > tags/p

Re: [Qemu-devel] [PATCH] Introduce DEVICE_CATEGORY_CPU for CPU devices

On 20.01.2017 13:31, Peter Maydell wrote: > On 20 January 2017 at 12:18, Thomas Huth wrote: >> Now that the hot-pluggable CPUs show up in the help text of >> "-device ?", we should group them into an appropriate category. >> >> Signed-off-by: Thomas Huth >> --- >> hw/ppc/pnv_core.c | 1 + >

[Qemu-devel] [PATCH v2] Introduce DEVICE_CATEGORY_CPU for CPU devices

Now that CPUs show up in the help text of "-device ?", we should group them into an appropriate category. Signed-off-by: Thomas Huth --- v2: - set_bit in the TYPE_CPU and TYPE_CPU_CORES directly instead of doing this in the child classes hw/cpu/core.c | 8 include/hw/qdev

Re: [Qemu-devel] [PATCH v2 23/25] console: make screendump async

Hi On Thu, Jan 19, 2017 at 12:21 PM Gerd Hoffmann wrote: > On Mi, 2017-01-18 at 20:03 +0400, Marc-André Lureau wrote: > > +surface = qemu_console_surface(con); > > + > > +/* FIXME: async save with coroutine? it would have to copy or > > lock > > + * the surface. */ > > +ppm_save(

[Qemu-devel] [PATCH RFC v4 00/20] VT-d: vfio enablement and misc enhances

This is v4 of vt-d vfio enablement series. Sorry that v4 growed to 20 patches. Some newly added patches (which are quite necessary): [01/20] vfio: trace map/unmap for notify as well [02/20] vfio: introduce vfio_get_vaddr() [03/20] vfio: allow to notify unmap for very large region Patches from

[Qemu-devel] [PATCH RFC v4 01/20] vfio: trace map/unmap for notify as well

We traces its range, but we don't know whether it's a MAP/UNMAP. Let's dump it as well. Signed-off-by: Peter Xu --- hw/vfio/common.c | 3 ++- hw/vfio/trace-events | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/hw/vfio/common.c b/hw/vfio/common.c index 801578b..174f351

[Qemu-devel] [PATCH RFC v4 03/20] vfio: allow to notify unmap for very large region

Linux vfio driver supports to do VFIO_IOMMU_UNMAP_DMA for a very big region. This can be leveraged by QEMU IOMMU implementation to cleanup existing page mappings for an entire iova address space (by notifying with an IOTLB with extremely huge addr_mask). However current vfio_iommu_map_notify() does

[Qemu-devel] [PATCH RFC v4 04/20] IOMMU: add option to enable VTD_CAP_CM to vIOMMU capility exposoed to guest

From: Aviv Ben-David This capability asks the guest to invalidate cache before each map operation. We can use this invalidation to trap map operations in the hypervisor. Signed-off-by: Aviv Ben-David [using "caching-mode" instead of "cache-mode" to align with spec] Signed-off-by: Peter Xu ---

[Qemu-devel] [PATCH RFC v4 02/20] vfio: introduce vfio_get_vaddr()

A cleanup for vfio_iommu_map_notify(). Should have no functional change, just to make the function shorter and easier to understand. Signed-off-by: Peter Xu --- hw/vfio/common.c | 58 +--- 1 file changed, 38 insertions(+), 20 deletions(-) diff

[Qemu-devel] [PATCH RFC v4 05/20] intel_iommu: simplify irq region translation

Now we have a standalone memory region for MSI, all the irq region requests should be redirected there. Cleaning up the block with an assertion instead. Signed-off-by: Peter Xu --- hw/i386/intel_iommu.c | 28 ++-- 1 file changed, 6 insertions(+), 22 deletions(-) diff --g

[Qemu-devel] [PATCH RFC v4 08/20] intel_iommu: fix trace for addr translation

Another patch to convert the DPRINTF() stuffs. This patch focuses on the address translation path and caching. Signed-off-by: Peter Xu --- hw/i386/intel_iommu.c | 84 --- hw/i386/trace-events | 7 + 2 files changed, 39 insertions(+), 52 delet

[Qemu-devel] [PATCH RFC v4 10/20] 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 is in the range of specific IOMMU notifier, and skip those notifiers

[Qemu-devel] [PATCH RFC v4 12/20] memory: provide iommu_replay_all()

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. Signed-off-by: Peter Xu --- include/exec/memory.h | 8 memory.c | 9 + 2 files changed, 17 insertions(+) d

[Qemu-devel] [PATCH RFC v4 09/20] intel_iommu: vtd_slpt_level_shift check level

This helps in debugging incorrect level passed in. Signed-off-by: Peter Xu --- hw/i386/intel_iommu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c index 2c13b7b..6f5f68a 100644 --- a/hw/i386/intel_iommu.c +++ b/hw/i386/intel_iommu.c @@ -168,6 +

[Qemu-devel] [PATCH RFC v4 06/20] intel_iommu: renaming gpa to iova where proper

There are lots of places in current intel_iommu.c codes that named "iova" as "gpa". It is really confusing to use a name "gpa" in these places (which is very easily to be understood as "Guest Physical Address", while it's not). To make the codes (much) easier to be read, I decided to do this once a

[Qemu-devel] [PATCH RFC v4 13/20] memory: introduce memory_region_notify_one()

Generalizing the notify logic in memory_region_notify_iommu() into a single function. This can be further used in customized replay() functions for IOMMUs. Signed-off-by: Peter Xu --- include/exec/memory.h | 15 +++ memory.c | 29 ++--- 2 files ch

[Qemu-devel] [PATCH RFC v4 16/20] intel_iommu: do replay when context invalidate

Before this one we only invalidate context cache when we receive context entry invalidations. However it's possible that the invalidation also contains a domain switch (only if cache-mode is enabled for vIOMMU). In that case we need to notify all the registered components about the new mapping. Si

[Qemu-devel] [PATCH RFC v4 07/20] intel_iommu: fix trace for inv desc handling

VT-d codes are still using static DEBUG_INTEL_IOMMU macro. That's not good, and we should end the day when we need to recompile the code before getting useful debugging information for vt-d. Time to switch to the trace system. This is the first patch to do it. Generally, the rule of mine is: - f

[Qemu-devel] [PATCH RFC v4 19/20] intel_iommu: unmap existing pages before replay

Previous replay works for domain switch only if the original domain does not have mapped pages. For example, if we switch domain from A to B, it will only work if A has no existing mapping. If there is, then there's problem - current replay didn't make sure the old mappings are cleared before repla

[Qemu-devel] [PATCH RFC v4 14/20] 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 i

[Qemu-devel] [PATCH RFC v4 17/20] 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 m

[Qemu-devel] [PATCH RFC v4 11/20] memory: provide IOMMU_NOTIFIER_FOREACH macro

Signed-off-by: Peter Xu --- include/exec/memory.h | 3 +++ memory.c | 4 ++-- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/include/exec/memory.h b/include/exec/memory.h index ae4c9a9..f0cb631 100644 --- a/include/exec/memory.h +++ b/include/exec/memory.h @@ -243,6 +

[Qemu-devel] [PATCH RFC v4 20/20] intel_iommu: replay even with DSI/GLOBAL inv desc

We were capturing context entry invalidations to trap IOMMU mapping changes. This patch listens to domain/global invalidation requests too. We need this for the sake that guest operating system might send one domain/global invalidation instead of several PSIs in some cases. To better survive with

[Qemu-devel] [PATCH RFC v4 15/20] 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 regions

[Qemu-devel] [PULL 02/35] megasas: fix guest-triggered memory leak

If the guest sets the sglist size to a value >=2GB, megasas_handle_dcmd will return MFI_STAT_MEMORY_NOT_AVAILABLE without freeing the memory. Avoid this by returning only the status from map_dcmd, and loading cmd->iov_size in the caller. Reported-by: Li Qiang Signed-off-by: Paolo Bonzini --- hw

[Qemu-devel] [PULL v3 00/32] Misc patches for 2017-01-11

The following changes since commit 2ccede18bd24fce5db83fef3674563a1f256717b: Merge remote-tracking branch 'remotes/vivier/tags/m68k-for-2.9-pull-request' into staging (2017-01-16 12:41:35 +) are available in the git repository at: git://github.com/bonzini/qemu.git tags/for-upstream for

[Qemu-devel] [PATCH RFC v4 18/20] intel_iommu: enable vfio devices

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 page for iotlb invalid

[Qemu-devel] [PULL 04/35] smbios: filter based on CONFIG_SMBIOS rather than TARGET

From: Leif Lindholm -smbios command line options were accepted but silently ignored on TARGET_ARM, due to a test for TARGET_I386 in arch_init.c. Copy the mechanism of hw/pci/pci-stub.c to implement an smbios-stub instead, enabled for all targets without CONFIG_SMBIOS. Signed-off-by: Leif Lindho

  1   2   3   >