[Qemu-devel] [Bug 1668103] Re: Possible off-by-one error in priority handling of hw/PL190.c

We do not take patches from the bug tracker, please send it to the qemu- devel mailing list instead. See http://wiki.qemu- project.org/Contribute/SubmitAPatch for details. ** Changed in: qemu Status: Fix Committed => In Progress -- You received this bug notification because you are a

Re: [Qemu-devel] kvm bug in __rmap_clear_dirty during live migration

On 2/25/2017 2:44 PM, Herongguang (Stephen) wrote: On 2017/2/24 23:14, Paolo Bonzini wrote: On 24/02/2017 16:10, Chris Friesen wrote: On 02/23/2017 08:23 PM, Herongguang (Stephen) wrote: On 2017/2/22 22:43, Paolo Bonzini wrote: Hopefully Gaohuai and Rongguang can help with this too.

Re: [Qemu-devel] [PATCH 4/4] block/rbd: Add blockdev-add support

On Mon, Feb 27, 2017 at 02:30:41AM -0500, Jeff Cody wrote: > Signed-off-by: Jeff Cody > --- > qapi/block-core.json | 47 --- > 1 file changed, 44 insertions(+), 3 deletions(-) > > diff --git a/qapi/block-core.json

Re: [Qemu-devel] [PATCH 2/3] COLO-compare: Optimize colo_packet_compare_common

On 02/27/2017 03:28 PM, Hailiang Zhang wrote: On 2017/2/27 15:03, Zhang Chen wrote: On 02/25/2017 02:58 PM, Hailiang Zhang wrote: On 2017/2/25 11:32, Zhang Chen wrote: Add offset args for colo_packet_compare_common, optimize colo_packet_compare_icmp() and colo_packet_compare_udp() just

[Qemu-devel] [PATCH 2/4] block/rbd: code movement

Signed-off-by: Jeff Cody --- block/rbd.c | 64 +++-- 1 file changed, 45 insertions(+), 19 deletions(-) diff --git a/block/rbd.c b/block/rbd.c index 3f1a9de..c8d4eb1 100644 --- a/block/rbd.c +++ b/block/rbd.c @@ -357,6

[Qemu-devel] [PATCH 1/4] block/rbd: don't copy strings in qemu_rbd_next_tok()

This patch is prep work for parsing options for .bdrv_parse_filename, and using QDict options. The function qemu_rbd_next_tok() searched for various key/value pairs, and copied them into buffers. This will soon be an unnecessary extra step, so we will now return found strings by reference only,

[Qemu-devel] [PATCH 3/4] block/rbd: parse all options via bdrv_parse_filename

Get rid of qemu_rbd_parsename in favor of bdrv_parse_filename. This simplifies a lot of the parsing as well, as we can treat everything a bit simpler since nonexistent options are simply NULL pointers instead of empy strings. An important item to note: Ceph has many extra option values that can

[Qemu-devel] [PATCH 0/4] RBD: blockdev-add

This series adds blockdev-add for rbd. However, there is an area that will likely need to change. In the RBD driver, all options for Ceph are supported, but the qemu driver is not explicitly aware of all the options. There are a few options that the QEMU driver cares about and handles, while

[Qemu-devel] [PATCH 4/4] block/rbd: Add blockdev-add support

Signed-off-by: Jeff Cody --- qapi/block-core.json | 47 --- 1 file changed, 44 insertions(+), 3 deletions(-) diff --git a/qapi/block-core.json b/qapi/block-core.json index 5f82d35..08a1419 100644 --- a/qapi/block-core.json +++

Re: [Qemu-devel] [PATCH v3] target-s390x: Implement stfl and stfle

On 26.02.2017 19:57, Michal Marek wrote: > Dne 26.2.2017 v 12:22 Thomas Huth napsal(a): >> On 26.02.2017 00:38, Michal Marek wrote: >>> The implementation is partially cargo cult based, but it works for the >>> linux kernel use case. >>> >>> Signed-off-by: Michal Marek >>> ---

Re: [Qemu-devel] [PATCH 2/3] COLO-compare: Optimize colo_packet_compare_common

On 2017/2/27 15:03, Zhang Chen wrote: On 02/25/2017 02:58 PM, Hailiang Zhang wrote: On 2017/2/25 11:32, Zhang Chen wrote: Add offset args for colo_packet_compare_common, optimize colo_packet_compare_icmp() and colo_packet_compare_udp() just compare the IP payload. Signed-off-by: Zhang Chen

[Qemu-devel] [PATCH 2/3] vfio pci: new function to init AER capability

Enable AER opportunistically. Signed-off-by: Dou Liyang Signed-off-by: Cao jin --- hw/vfio/pci.c | 41 - hw/vfio/pci.h | 1 + 2 files changed, 37 insertions(+), 5 deletions(-) diff --git

[Qemu-devel] [PATCH 3/3] vfio-pci: process non fatal error of AER

Make use of the non fatal error eventfd that the kernel module provide to process the AER non fatal error. Fatal error still goes into the legacy way which results in VM stop. Register the handler, wait for notification. Construct aer message and pass it to root port on notification. Root port

[Qemu-devel] [PATCH 1/3] pcie aer: verify if AER functionality is available

For devices which support AER, verify it can work or not in the system: 1. AER capable device is a PCIe device, it can't be plugged into PCI bus 2. If root port doesn't support AER, then there is no need to expose the AER capability Signed-off-by: Dou Liyang

[Qemu-devel] [PATCH 0/3] vfio-pci: support recovery of AER non fatal error

This is nearly new design of the feature, so re-number the verion from 0. About The test: Hardware problem(unsteady) still occurs like before. The test server is in another country spot A, and my contact of the country located spot B, so it is not quite convenient to find help(plug cable, or

[Qemu-devel] [PATCH] vfio pci: kernel support of error recovery only for non fatal error

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 immediately because it's detected and reported asynchronously. Interrupts are forwarded as usual. Correctable errors are not reported to guest

Re: [Qemu-devel] [PATCH 2/3] COLO-compare: Optimize colo_packet_compare_common

On 02/25/2017 03:26 PM, Hailiang Zhang wrote: On 2017/2/25 11:32, Zhang Chen wrote: Add offset args for colo_packet_compare_common, optimize colo_packet_compare_icmp() and colo_packet_compare_udp() just compare the IP payload. Signed-off-by: Zhang Chen ---

Re: [Qemu-devel] [PATCH 2/3] COLO-compare: Optimize colo_packet_compare_common

On 02/25/2017 02:58 PM, Hailiang Zhang wrote: On 2017/2/25 11:32, Zhang Chen wrote: Add offset args for colo_packet_compare_common, optimize colo_packet_compare_icmp() and colo_packet_compare_udp() just compare the IP payload. Signed-off-by: Zhang Chen ---

Re: [Qemu-devel] [PATCH v2 2/3] filter-rewriter: fix memory leak for connection in connection_track_table

On 2017/2/27 13:35, Jason Wang wrote: On 2017年02月27日 12:09, Hailiang Zhang wrote: On 2017/2/27 11:40, Jason Wang wrote: On 2017年02月27日 11:11, Hailiang Zhang wrote: On 2017/2/23 12:16, Jason Wang wrote: On 2017年02月22日 16:51, Hailiang Zhang wrote: On 2017/2/22 16:45, Hailiang Zhang

Re: [Qemu-devel] [PATCH 1/3] COLO-compare: Add minimum packet size check and some fix

On 02/25/2017 02:43 PM, Hailiang Zhang wrote: Hi, On 2017/2/25 11:32, Zhang Chen wrote: Add packet minimum size check in colo_packet_compare_udp() and colo_packet_compare_udp() like colo_packet_compare_icmp(), rename function colo_packet_compare() to colo_packet_compare_common() that we will

[Qemu-devel] exec: Respect as_tranlsate_internal length clamp

Hi! I was asked to backport a fix for a CVE to our of our powerkvm products. This one: https://exchange.xforce.ibmcloud.com/vulnerabilities/87 === qemu-cve20158817-dos (87) reported Mar 1, 2016 Qemu, built to use address_space_translate to map an address to a MemoryRegionSection, is

Re: [Qemu-devel] [PATCH 17/21] qapi: Drop unused non-strict qobject input visitor

Eric Blake writes: > On 02/24/2017 09:02 AM, Markus Armbruster wrote: >> Paolo Bonzini writes: >> >>> On 23/02/2017 22:45, Markus Armbruster wrote: The split between tests/test-qobject-input-visitor.c and tests/test-qobject-input-strict.c now

Re: [Qemu-devel] [PATCH v2 2/3] filter-rewriter: fix memory leak for connection in connection_track_table

On 2017年02月27日 12:09, Hailiang Zhang wrote: On 2017/2/27 11:40, Jason Wang wrote: On 2017年02月27日 11:11, Hailiang Zhang wrote: On 2017/2/23 12:16, Jason Wang wrote: On 2017年02月22日 16:51, Hailiang Zhang wrote: On 2017/2/22 16:45, Hailiang Zhang wrote: On 2017/2/22 16:07, Jason Wang

Re: [Qemu-devel] [PATCH 1/2] risu_ppc64le: fix the typo nb => rb

Peter Maydell writes: > On 13 February 2017 at 08:59, Nikunj A Dadhania > wrote: >> Signed-off-by: Nikunj A Dadhania >> --- >> ppc64.risu | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) > > Thanks,

Re: [Qemu-devel] [PATCH 16/21] test-qobject-input-visitor: Use strict visitor

Eric Blake writes: > On 02/23/2017 03:45 PM, Markus Armbruster wrote: >> The qobject input visitor comes in a strict and a non-strict variant. >> This test is the non-strict variant's last user. > > Well, depending on Paolo's proposed addition. Needs a commit message tweak if

Re: [Qemu-devel] [PATCH 2/2] risu_ppc64le: distinguish real illegal instruction

Peter Maydell writes: > On 13 February 2017 at 08:59, Nikunj A Dadhania > wrote: >> While executing qemu_ppc64le, found an issue that the real illegal >> instructions are handled as risu_op which results in wrong info at the >> master end.

Re: [Qemu-devel] [PATCH 12/21] qapi: Improve qobject input visitor error reporting

Eric Blake writes: > On 02/23/2017 03:45 PM, Markus Armbruster wrote: >> Error messages refer to nodes of the QObject being visited by name. >> Trouble is the names are sometimes less than helpful: >> > >> Improve error messages by referring to nodes by path instead, as >>

[Qemu-devel] [PATCHv2 7/9] target/ppc: Manage external HPT via virtual hypervisor

The pseries machine type implements the behaviour of a PAPR compliant hypervisor, without actually executing such a hypervisor on the virtual CPU. To do this we need some hooks in the CPU code to make hypervisor facilities get redirected to the machine instead of emulated internally. For

[Qemu-devel] [PATCHv2 6/9] target/ppc: Eliminate htab_base and htab_mask variables

CPUPPCState includes fields htab_base and htab_mask which store the base address (GPA) and size (as a mask) of the guest's hashed page table (HPT). These are set when the SDR1 register is updated. Keeping these in sync with the SDR1 is actually a little bit fiddly, and probably not useful for

[Qemu-devel] [PATCHv2 8/9] target/ppc: Remove the function ppc_hash64_set_sdr1()

From: Suraj Jitindar Singh The function ppc_hash64_set_sdr1 basically checked the htabsize and set an error if it was too big, otherwise it just stored the value in SPR_SDR1. Given that the only function which calls ppc_hash64_set_sdr1() is ppc_store_sdr1(), why not

[Qemu-devel] [PATCHv2 1/9] target/ppc: Fix KVM-HV HPTE accessors

When a 'pseries' guest is running with KVM-HV, the guest's hashed page table (HPT) is stored within the host kernel, so it is not directly accessible to qemu. Most of the time, qemu doesn't need to access it: we're using the hardware MMU, and KVM itself implements the guest hypercalls for

[Qemu-devel] [PATCHv2 4/9] target/ppc: SDR1 is a hypervisor resource

At present the SDR1 register - the base of the system's hashed page table (HPT) - is represented as an SPR with supervisor read and write permission. However, on CPUs which have a hypervisor mode, the SDR1 is a hypervisor only resource. Change the permission checking on the SPR to reflect this.

[Qemu-devel] [PATCHv2 5/9] target/ppc: Cleanup HPTE accessors for 64-bit hash MMU

Accesses to the hashed page table (HPT) are complicated by the fact that the HPT could be in one of three places: 1) Within guest memory - when we're emulating a full guest CPU at the hardware level (e.g. powernv, mac99, g3beige) 2) Within qemu, but outside guest memory - when we're

[Qemu-devel] [PATCHv2 9/9] target/ppc: Correct SDR1 masking

SDR_64_HTABORG, which indicates the bits of the SDR1 register to use for the base of a 64-bit machine's hashed page table (HPT) isn't correct. It includes the top 46 bits of the register, but in fact the top 4 bits must be zero (according to the ISA v2.07). No actual implementation has supported

[Qemu-devel] [PATCHv2 3/9] target/ppc: Merge cpu_ppc_set_vhyp() with cpu_ppc_set_papr()

cpu_ppc_set_papr() sets up various aspects of CPU state for use with PAPR paravirtualized guests. However, it doesn't set the virtual hypervisor, so callers must also call cpu_ppc_set_vhyp() so that PAPR hypercalls are handled properly. This is a bit silly, so fold setting the virtual hypervisor

[Qemu-devel] [PATCHv2 0/9] Cleanups to handling of hash MMU

This series has an assortment of cleanups to the handling of the hash based MMU for 64-bit ppc machines. In particular it better handles the case of "external" hash table - this is used on the pseries machine type, which being a paravirtualized platform has the hashed page table - along with

[Qemu-devel] [PATCHv2 2/9] pseries: Minor cleanups to HPT management hypercalls

* Standardize on 'ptex' instead of 'pte_index' for HPTE index variables for consistency and brevity * Avoid variables named 'index'; shadowing index(3) from libc can lead to surprising bugs if the variable is removed, because compiler errors might not appear for remaining references *

[Qemu-devel] [PATCH v6 6/8] target/ppc: add ov32 flag for multiply low insns

For Multiply Word: SO, OV, and OV32 bits reflects overflow of the 32-bit result For Multiply DoubleWord: SO, OV, and OV32 bits reflects overflow of the 64-bit result Signed-off-by: Nikunj A Dadhania Reviewed-by: Richard Henderson ---

Re: [Qemu-devel] [PATCH 4/6] target/ppc: Cleanup HPTE accessors for 64-bit hash MMU

On Thu, Feb 23, 2017 at 04:02:54PM +1100, Alexey Kardashevskiy wrote: > On 23/02/17 13:09, David Gibson wrote: > > Accesses to the hashed page table (HPT) are complicated by the fact that > > the HPT could be in one of three places: > >1) Within guest memory - when we're emulating a full guest

[Qemu-devel] [PATCH v6 7/8] target/ppc: add ov32 flag in divide operations

Add helper_div_compute_ov() in the int_helper for updating the overflow flags. For Divide Word: SO, OV, and OV32 bits reflects overflow of the 32-bit result For Divide DoubleWord: SO, OV, and OV32 bits reflects overflow of the 64-bit result Signed-off-by: Nikunj A Dadhania

[Qemu-devel] [PATCH v6 4/8] target/ppc: update overflow flags for add/sub

* SO and OV reflects overflow of the 64-bit result in 64-bit mode and overflow of the low-order 32-bit result in 32-bit mode * OV32 reflects overflow of the low-order 32-bit independent of the mode Signed-off-by: Nikunj A Dadhania --- target/ppc/translate.c | 11

[Qemu-devel] [PATCH v6 5/8] target/ppc: use tcg ops for neg instruction

Signed-off-by: Nikunj A Dadhania Reviewed-by: Richard Henderson --- target/ppc/translate.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/target/ppc/translate.c b/target/ppc/translate.c index 16f422f..d4d9941 100644 ---

[Qemu-devel] [PATCH v6 2/8] target/ppc: update ca32 in arithmetic add

Adds routine to compute ca32 - gen_op_arith_compute_ca32 For 64-bit mode use the compute ca32 routine. While for 32-bit mode, CA and CA32 will have same value. Signed-off-by: Nikunj A Dadhania Reviewed-by: Richard Henderson ---

[Qemu-devel] [PATCH v6 8/8] target/ppc: add mcrxrx instruction

mcrxrx: Move to CR from XER Extended Signed-off-by: Nikunj A Dadhania Reviewed-by: Richard Henderson --- target/ppc/translate.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/target/ppc/translate.c

[Qemu-devel] [PATCH v6 3/8] target/ppc: update ca32 in arithmetic substract

Signed-off-by: Nikunj A Dadhania Reviewed-by: Richard Henderson --- target/ppc/translate.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/target/ppc/translate.c b/target/ppc/translate.c index eba83ef..e083082 100644

[Qemu-devel] [PATCH v6 0/8] POWER9 TCG enablements - part15

This series contains implentation of CA32 and OV32 bits added to the ISA 3.0. Various fixed-point arithmetic instructions are updated to take care of the newer flags. Finally the last patch adds new instruction mcrxrx, that helps reading the carry (CA and CA32) and the overflow (OV and OV32)

[Qemu-devel] [PATCH v6 1/8] target/ppc: support for 32-bit carry and overflow

POWER ISA 3.0 adds CA32 and OV32 status in 64-bit mode. Add the flags and corresponding defines. Moreover, CA32 is updated when CA is updated and OV32 is updated when OV is updated. Arithmetic instructions: * Addition and Substractions: addic, addic., subfic, addc, subfc, adde,

[Qemu-devel] [PATCH v2] memory: Introduce DEVICE_HOST_ENDIAN for ram device

At the moment ram device's memory regions are DEVICE_NATIVE_ENDIAN. It's incorrect. This memory region is backed by a MMIO area in host, so the uint64_t data that MemoryRegionOps read from/write to this area should be host-endian rather than target-endian. Hence, current code does not work when

Re: [Qemu-devel] [PATCH] memory: make ram device read/write endian sensitive

on 2017/2/27 11:25, Alexey Kardashevskiy wrote: On 27/02/17 13:25, Michael Roth wrote: Quoting Alexey Kardashevskiy (2017-02-22 22:20:25) On 21/02/17 17:46, Yongji Xie wrote: At the moment ram device's memory regions are NATIVE_ENDIAN. This does not work on PPC64 because VFIO PCI device is

Re: [Qemu-devel] [PATCH v2 2/3] filter-rewriter: fix memory leak for connection in connection_track_table

On 2017/2/27 11:40, Jason Wang wrote: On 2017年02月27日 11:11, Hailiang Zhang wrote: On 2017/2/23 12:16, Jason Wang wrote: On 2017年02月22日 16:51, Hailiang Zhang wrote: On 2017/2/22 16:45, Hailiang Zhang wrote: On 2017/2/22 16:07, Jason Wang wrote: On 2017年02月22日 11:46, zhanghailiang

Re: [Qemu-devel] [PATCH v2 3/3] filter-rewriter: skip net_checksum_calculate() while offset = 0

On 02/27/2017 09:36 AM, Hailiang Zhang wrote: On 2017/2/24 16:08, Zhang Chen wrote: On 02/22/2017 11:46 AM, zhanghailiang wrote: While the offset of packets's sequence for primary side and secondary side is zero, it is unnecessary to call net_checksum_calculate() to recalculate the

Re: [Qemu-devel] [PATCH v2 2/3] filter-rewriter: fix memory leak for connection in connection_track_table

On 2017年02月27日 11:11, Hailiang Zhang wrote: On 2017/2/23 12:16, Jason Wang wrote: On 2017年02月22日 16:51, Hailiang Zhang wrote: On 2017/2/22 16:45, Hailiang Zhang wrote: On 2017/2/22 16:07, Jason Wang wrote: On 2017年02月22日 11:46, zhanghailiang wrote: After a net connection is closed, we

Re: [Qemu-devel] [PATCH] memory: make ram device read/write endian sensitive

On 27/02/17 13:25, Michael Roth wrote: > Quoting Alexey Kardashevskiy (2017-02-22 22:20:25) >> On 21/02/17 17:46, Yongji Xie wrote: >>> At the moment ram device's memory regions are NATIVE_ENDIAN. This does >>> not work on PPC64 because VFIO PCI device is little endian but PPC64 >>> always defines

Re: [Qemu-devel] [PATCH v2 2/3] filter-rewriter: fix memory leak for connection in connection_track_table

On 2017/2/23 12:16, Jason Wang wrote: On 2017年02月22日 16:51, Hailiang Zhang wrote: On 2017/2/22 16:45, Hailiang Zhang wrote: On 2017/2/22 16:07, Jason Wang wrote: On 2017年02月22日 11:46, zhanghailiang wrote: After a net connection is closed, we didn't clear its releated resources in

Re: [Qemu-devel] [PATCH] memory: make ram device read/write endian sensitive

Quoting Alexey Kardashevskiy (2017-02-22 22:20:25) > On 21/02/17 17:46, Yongji Xie wrote: > > At the moment ram device's memory regions are NATIVE_ENDIAN. This does > > not work on PPC64 because VFIO PCI device is little endian but PPC64 > > always defines static macro TARGET_WORDS_BIGENDIAN. > >

Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 03/10] target/ppc: support for 32-bit carry and overflow

On Fri, Feb 24, 2017 at 05:30:23PM +1100, Richard Henderson wrote: > On 02/24/2017 03:50 PM, David Gibson wrote: > > Although I guess they'd shrink right down again if we put an > > env->xer_mask in. Thoughts on that option Richard? > > Why would xer_mask shrink the code? I can't see that we'd

Re: [Qemu-devel] [PATCH RFC v3 11/15] vfio: ccw: realize VFIO_DEVICE_G(S)ET_IRQ_INFO ioctls

* Alex Williamson [2017-02-24 16:27:24 -0700]: > On Fri, 17 Feb 2017 09:29:35 +0100 > Dong Jia Shi wrote: > > > Realize VFIO_DEVICE_GET_IRQ_INFO ioctl to retrieve > > VFIO_CCW_IO_IRQ information. > > > > Realize VFIO_DEVICE_SET_IRQS

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 16/22] ppc/xics: register the reset handler of ICP objects

On Fri, Feb 24, 2017 at 12:27:35PM +0100, Cédric Le Goater wrote: > On 02/23/2017 03:42 AM, David Gibson wrote: > > On Thu, Feb 16, 2017 at 02:47:39PM +0100, Cédric Le Goater wrote: > >> The reset of the ICP objects is currently handled by XICS but this can > >> be done for each individual ICP. >

Re: [Qemu-devel] using fdt_setprop() to set properties to empty values

On Fri, Feb 24, 2017 at 10:35:35AM +, Peter Maydell wrote: > On 24 February 2017 at 00:16, David Gibson > wrote: > > Ok, I've pushed libfdt upstream patches to (a) make passing NULL to > > setprop() with zero length explicitly safe and (b) add an > >

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 12/22] ppc/xics: extend the QOM interface to handle ICPs

On Fri, Feb 24, 2017 at 12:15:21PM +0100, Cédric Le Goater wrote: > On 02/23/2017 03:39 AM, David Gibson wrote: > > On Thu, Feb 16, 2017 at 02:47:35PM +0100, Cédric Le Goater wrote: > >> Let's add two new handlers for ICPs. One is to get an ICP object from > >> a server number and a second is to

Re: [Qemu-devel] [Qemu-ppc] [PATCH qemu] sysemu: support up to 1024 vCPUs

On Fri, Feb 24, 2017 at 10:13:50AM +0100, Greg Kurz wrote: > On Fri, 24 Feb 2017 15:55:31 +1100 > Alexey Kardashevskiy wrote: > > > From: Greg Kurz > > > > Some systems can already provide more than 255 hardware threads. > > > > Bumping the QEMU limit

Re: [Qemu-devel] [PATCH v2 3/3] filter-rewriter: skip net_checksum_calculate() while offset = 0

On 2017/2/24 16:08, Zhang Chen wrote: On 02/22/2017 11:46 AM, zhanghailiang wrote: While the offset of packets's sequence for primary side and secondary side is zero, it is unnecessary to call net_checksum_calculate() to recalculate the checksume value of packets. Signed-off-by:

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 08/22] ppc/xics: use the QOM interface to resend irqs

On Fri, Feb 24, 2017 at 12:12:54PM +0100, Cédric Le Goater wrote: > On 02/23/2017 03:29 AM, David Gibson wrote: > > On Thu, Feb 16, 2017 at 02:47:31PM +0100, Cédric Le Goater wrote: > >> Signed-off-by: Cédric Le Goater > >> --- > >> hw/intc/xics.c | 26 ++ >

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 04/22] ppc/xics: add an InterruptStatsProvider interface to ICS and ICP objects

On Fri, Feb 24, 2017 at 11:52:01AM +0100, Cédric Le Goater wrote: > On 02/23/2017 03:15 AM, David Gibson wrote: > > On Thu, Feb 16, 2017 at 02:47:27PM +0100, Cédric Le Goater wrote: > >> This is, again, to reduce the use of the list of ICS objects. Let's > >> make each individual ICS and ICP

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 08/22] ppc/xics: use the QOM interface to resend irqs

On Fri, Feb 24, 2017 at 06:34:06PM +0100, Cédric Le Goater wrote: > >>> @@ -592,10 +593,11 @@ static void ics_simple_reset(DeviceState *dev) > >>> > >>> static int ics_simple_post_load(ICSState *ics, int version_id) > >>> { > >>> +XICSInterface *xi = XICS_INTERFACE(qdev_get_machine()); >

[Qemu-devel] [PATCH] blk: Add discard=sparse mode

By default, on discard requests, the posix block backend punches holes but re-fallocates them to keep the allocated size intact. In some situations it is however convenient, when using sparse disk images, to see disk image sizes shrink on discard requests. This commit adds a discard=sparse mode

Re: [Qemu-devel] [PATCH v2 00/28] 9pfs: local: fix vulnerability to symlink attacks

On Sun, 26 Feb 2017 23:41:32 +0100 Greg Kurz wrote: > This series tries to fix CVE-2016-9602 reported by Jann Horn of Google > Project Zero: > > https://bugzilla.redhat.com/show_bug.cgi?id=1413929 > > This vulnerability affects all accesses to the underlying filesystem in > the

Re: [Qemu-devel] [PATCH 37/43] spapr: reuse machine->possible_cpus instead of cores[]

On Fri, Feb 24, 2017 at 02:29:21PM +0100, Igor Mammedov wrote: > On Sat, 25 Feb 2017 00:03:57 +1100 > David Gibson wrote: > > > On Wed, Feb 22, 2017 at 12:05:55PM +0100, Igor Mammedov wrote: > > > Replace SPAPR specific cores[] array with generic > > >

[Qemu-devel] [Bug 1668103] Re: Possible off-by-one error in priority handling of hw/PL190.c

"Fix committed" doesn't seem right -- that's only when a patch is actually committed to QEMU's git tree... -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1668103 Title: Possible off-by-one error in

[Qemu-devel] [PATCH v2 27/28] 9pfs: local: open2: don't follow symlinks

The local_open2() callback is vulnerable to symlink attacks because it calls: (1) open() which follows symbolic links for all path elements but the rightmost one (2) local_set_xattr()->setxattr() which follows symbolic links for all path elements (3) local_set_mapped_file_attr() which

[Qemu-devel] [PATCH v2 23/28] 9pfs: local: chown: don't follow symlinks

The local_chown() callback is vulnerable to symlink attacks because it calls: (1) lchown() which follows symbolic links for all path elements but the rightmost one (2) local_set_xattr()->setxattr() which follows symbolic links for all path elements (3) local_set_mapped_file_attr() which

[Qemu-devel] [PATCH v2 28/28] 9pfs: local: drop unused code

Now that the all callbacks have been converted to use "at" syscalls, we can drop this code. Signed-off-by: Greg Kurz Reviewed-by: Stefan Hajnoczi --- hw/9pfs/9p-local.c | 198 1 file changed, 198

[Qemu-devel] [PATCH v2 20/28] 9pfs: local: improve error handling in link op

When using the mapped-file security model, we also have to create a link for the metadata file if it exists. In case of failure, we should rollback. That's what this patch does. Signed-off-by: Greg Kurz Reviewed-by: Stefan Hajnoczi --- v2: - use

[Qemu-devel] [PATCH v2 26/28] 9pfs: local: mkdir: don't follow symlinks

The local_mkdir() callback is vulnerable to symlink attacks because it calls: (1) mkdir() which follows symbolic links for all path elements but the rightmost one (2) local_set_xattr()->setxattr() which follows symbolic links for all path elements (3) local_set_mapped_file_attr() which

[Qemu-devel] [PATCH v2 19/28] 9pfs: local: rename: use renameat

The local_rename() callback is vulnerable to symlink attacks because it uses rename() which follows symbolic links in all path elements but the rightmost one. This patch simply transforms local_rename() into a wrapper around local_renameat() which is symlink-attack safe. This partly fixes

[Qemu-devel] [PATCH v2 25/28] 9pfs: local: mknod: don't follow symlinks

The local_mknod() callback is vulnerable to symlink attacks because it calls: (1) mknod() which follows symbolic links for all path elements but the rightmost one (2) local_set_xattr()->setxattr() which follows symbolic links for all path elements (3) local_set_mapped_file_attr() which

[Qemu-devel] [PATCH v2 18/28] 9pfs: local: renameat: don't follow symlinks

The local_renameat() callback is currently a wrapper around local_rename() which is vulnerable to symlink attacks. This patch rewrites local_renameat() to have its own implementation, based on local_opendir_nofollow() and renameat(). This partly fixes CVE-2016-9602. Signed-off-by: Greg Kurz

[Qemu-devel] [PATCH v2 21/28] 9pfs: local: link: don't follow symlinks

The local_link() callback is vulnerable to symlink attacks because it calls: (1) link() which follows symbolic links for all path elements but the rightmost one (2) local_create_mapped_attr_dir()->mkdir() which follows symbolic links for all path elements but the rightmost one This patch

[Qemu-devel] [PATCH v2 13/28] 9pfs: local: utimensat: don't follow symlinks

The local_utimensat() callback is vulnerable to symlink attacks because it calls qemu_utimens()->utimensat(AT_SYMLINK_NOFOLLOW) which follows symbolic links in all path elements but the rightmost one or qemu_utimens()->utimes() which follows symbolic links for all path elements. This patch

[Qemu-devel] [PATCH v2 16/28] 9pfs: local: readlink: don't follow symlinks

The local_readlink() callback is vulnerable to symlink attacks because it calls: (1) open(O_NOFOLLOW) which follows symbolic links for all path elements but the rightmost one (2) readlink() which follows symbolic links for all path elements but the rightmost one This patch converts

Re: [Qemu-devel] [PATCH v4 4/5] slirp: VMStatify socket level

Samuel Thibault, on dim. 26 févr. 2017 21:34:27 +0100, wrote: > since we'll want to change the size of the field Ah, no, sorry, it was forced to be 16bit, so at least the size is fine. But I guess we don't want to change the values to have cross-OS compatibility without changing the version.

[Qemu-devel] [PATCH v2 15/28] 9pfs: local: truncate: don't follow symlinks

The local_truncate() callback is vulnerable to symlink attacks because it calls truncate() which follows symbolic links in all path elements. This patch converts local_truncate() to rely on open_nofollow() and ftruncate() instead. This partly fixes CVE-2016-9602. Signed-off-by: Greg Kurz

[Qemu-devel] [PATCH v2 12/28] 9pfs: local: remove: don't follow symlinks

The local_remove() callback is vulnerable to symlink attacks because it calls: (1) lstat() which follows symbolic links in all path elements but the rightmost one (2) remove() which follows symbolic links in all path elements but the rightmost one This patch converts local_remove() to

[Qemu-devel] [PATCH v2 11/28] 9pfs: local: unlinkat: don't follow symlinks

The local_unlinkat() callback is vulnerable to symlink attacks because it calls remove() which follows symbolic links in all path elements but the rightmost one. This patch converts local_unlinkat() to rely on opendir_nofollow() and unlinkat() instead. Most of the code is moved to a separate

[Qemu-devel] [PATCH v2 10/28] 9pfs: local: lremovexattr: don't follow symlinks

The local_lremovexattr() callback is vulnerable to symlink attacks because it calls lremovexattr() which follows symbolic links in all path elements but the rightmost one. This patch introduces a helper to emulate the non-existing fremovexattrat() function: it is implemented with /proc/self/fd

[Qemu-devel] [PATCH v2 24/28] 9pfs: local: symlink: don't follow symlinks

The local_symlink() callback is vulnerable to symlink attacks because it calls: (1) symlink() which follows symbolic links for all path elements but the rightmost one (2) open(O_NOFOLLOW) which follows symbolic links for all path elements but the rightmost one (3)

[Qemu-devel] [PATCH v2 09/28] 9pfs: local: lsetxattr: don't follow symlinks

The local_lsetxattr() callback is vulnerable to symlink attacks because it calls lsetxattr() which follows symbolic links in all path elements but the rightmost one. This patch introduces a helper to emulate the non-existing fsetxattrat() function: it is implemented with /proc/self/fd which

[Qemu-devel] [PATCH v2 08/28] 9pfs: local: llistxattr: don't follow symlinks

The local_llistxattr() callback is vulnerable to symlink attacks because it calls llistxattr() which follows symbolic links in all path elements but the rightmost one. This patch introduces a helper to emulate the non-existing flistxattrat() function: it is implemented with /proc/self/fd which

[Qemu-devel] [PATCH v2 22/28] 9pfs: local: chmod: don't follow symlinks

The local_chmod() callback is vulnerable to symlink attacks because it calls: (1) chmod() which follows symbolic links for all path elements (2) local_set_xattr()->setxattr() which follows symbolic links for all path elements (3) local_set_mapped_file_attr() which calls in turn local_fopen()

[Qemu-devel] [PATCH v2 14/28] 9pfs: local: statfs: don't follow symlinks

The local_statfs() callback is vulnerable to symlink attacks because it calls statfs() which follows symbolic links in all path elements. This patch converts local_statfs() to rely on open_nofollow() and fstatfs() instead. This partly fixes CVE-2016-9602. Signed-off-by: Greg Kurz

[Qemu-devel] [PATCH v2 06/28] 9pfs: local: open/opendir: don't follow symlinks

The local_open() and local_opendir() callbacks are vulnerable to symlink attacks because they call: (1) open(O_NOFOLLOW) which follows symbolic links in all path elements but the rightmost one (2) opendir() which follows symbolic links in all path elements This patch converts both callbacks

[Qemu-devel] [PATCH v2 07/28] 9pfs: local: lgetxattr: don't follow symlinks

The local_lgetxattr() callback is vulnerable to symlink attacks because it calls lgetxattr() which follows symbolic links in all path elements but the rightmost one. This patch introduces a helper to emulate the non-existing fgetxattrat() function: it is implemented with /proc/self/fd which

[Qemu-devel] [PATCH v2 17/28] 9pfs: local: lstat: don't follow symlinks

The local_lstat() callback is vulnerable to symlink attacks because it calls: (1) lstat() which follows symbolic links in all path elements but the rightmost one (2) getxattr() which follows symbolic links in all path elements (3) local_mapped_file_attr()->local_fopen()->openat(O_NOFOLLOW)

[Qemu-devel] [PATCH v2 02/28] 9pfs: remove side-effects in local_init()

If this function fails, it should not modify *ctx. Signed-off-by: Greg Kurz Reviewed-by: Stefan Hajnoczi --- v2: - s/iocl/ioctl in comment --- hw/9pfs/9p-local.c | 37 +++-- 1 file changed, 19 insertions(+), 18 deletions(-)

[Qemu-devel] [PATCH v2 03/28] 9pfs: remove side-effects in local_open() and local_opendir()

If these functions fail, they should not change *fs. Let's use local variables to fix this. Signed-off-by: Greg Kurz Reviewed-by: Stefan Hajnoczi --- hw/9pfs/9p-local.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git

[Qemu-devel] [PATCH v2 04/28] 9pfs: introduce openat_nofollow() helper

When using the passthrough security mode, symbolic links created by the guest are actual symbolic links on the host file system. Since the resolution of symbolic links during path walk is supposed to occur on the client side. The server should hence never receive any path pointing to an actual

[Qemu-devel] [PATCH v2 05/28] 9pfs: local: keep a file descriptor on the shared folder

This patch opens the shared folder and caches the file descriptor, so that it can be used to do symlink-safe path walk. Signed-off-by: Greg Kurz Reviewed-by: Stefan Hajnoczi --- v2: - introduce LocalData type --- hw/9pfs/9p-local.c | 30

[Qemu-devel] [PATCH v2 01/28] 9pfs: local: move xattr security ops to 9p-xattr.c

These functions are always called indirectly. It really doesn't make sense for them to sit in a header file. Signed-off-by: Greg Kurz Reviewed-by: Stefan Hajnoczi --- hw/9pfs/9p-xattr.c | 61 hw/9pfs/9p-xattr.h |

[Qemu-devel] [PATCH v2 00/28] Series short description

This series tries to fix CVE-2016-9602 reported by Jann Horn of Google Project Zero: https://bugzilla.redhat.com/show_bug.cgi?id=1413929 This vulnerability affects all accesses to the underlying filesystem in the "local" backend code. If QEMU is started with: -fsdev

Re: [Qemu-devel] [PULL 0/5] slirp updates

On 26 February 2017 at 20:27, Samuel Thibault wrote: > The following changes since commit 685783c5b69c83c942d1fc21679311eeb8f79ab9: > > Merge remote-tracking branch 'remotes/thibault/tags/samuel-thibault' into > staging (2017-02-26 16:38:40 +) > > are

  1   2   >