[Qemu-devel] [PATCH v3 07/13] xen: Move xenstore cleanup and mkdir functions

The name of the functions moved to xen_pvdev.c: * xenstore_cleanup_dir * xen_config_cleanup * xenstore_mkdir Signed-off-by: Emil Condrea Acked-by: Anthony PERARD --- hw/xen/xen_backend.c | 49 -

Re: [Qemu-devel] [PATCH] hw/arm/pxa2xx: Set value default values for CCCR and CKEN on PXA255

Hi, Your series seems to have some coding style problems. See output below for more information: Type: series Message-id: 1477361273-1-1-git-send-email-li...@roeck-us.net Subject: [Qemu-devel] [PATCH] hw/arm/pxa2xx: Set value default values for CCCR and CKEN on PXA255 === TEST SCRIPT BEGIN

[Qemu-devel] [PATCH v3 02/13] xen: Fix coding style warnings

Fixes: * WARNING: line over 80 characters Signed-off-by: Emil Condrea --- hw/block/xen_disk.c | 3 ++- hw/char/xen_console.c| 3 ++- hw/display/xenfb.c | 6 -- hw/net/xen_nic.c | 12 hw/xen/xen_backend.c

[Qemu-devel] [PATCH v3 03/13] xen: Create a new file xen_pvdev.c

The purpose of the new file is to store generic functions shared by frontend and backends such as xenstore operations, xendevs. Signed-off-by: Quan Xu Signed-off-by: Emil Condrea --- hw/xen/Makefile.objs | 2 +- hw/xen/xen_backend.c |

Re: [Qemu-devel] [PATCH v5 15/17] ppc/pnv: Add cut down PSI bridge model and hookup external interrupt

On Sat, Oct 22, 2016 at 11:46:48AM +0200, Cédric Le Goater wrote: > From: Benjamin Herrenschmidt > > The PSI (Processor Service Interface) is one of the engines of the > "Bridge" unit which connects the different interfaces to the Power > Processor. > > This adds just

Re: [Qemu-devel] [PATCH v8 03/36] block: Introduce image file locking

On Fri, 10/21 23:04, Max Reitz wrote: > > +ImageLockMode bdrv_lock_mode_from_flags(int flags) > > +{ > > +if (flags & BDRV_O_NO_LOCK) { > > +return IMAGE_LOCK_MODE_NOLOCK; > > +} else if (flags & BDRV_O_SHARED_LOCK) { > > +return IMAGE_LOCK_MODE_SHARED; > > +} else if

Re: [Qemu-devel] [PATCH v5 12/17] ppc/pnv: add a XICS native to each PowerNV chip

On Mon, Oct 24, 2016 at 05:42:52PM +0200, Cédric Le Goater wrote: > On 10/22/2016 11:46 AM, Cédric Le Goater wrote: > > It also links the XICS object to each core as it is needed to do the > > CPU setup and the ICP MMIO windows are memory mapped for each thread. > > > > Signed-off-by: Cédric Le

Re: [Qemu-devel] [PATCH v5 17/17] ppc/pnv: Add Naples chip support for LPC interrupts

On Sat, Oct 22, 2016 at 11:46:50AM +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. > > Signed-off-by: Benjamin Herrenschmidt

Re: [Qemu-devel] [PATCH v5 13/17] ppc/xics: add a xics_get_cpu_index_by_pir helper

On Sat, Oct 22, 2016 at 11:46:46AM +0200, Cédric Le Goater wrote: > We will need this helper to translate the server number of the XIVE > (which is a PIR) into an ICPState index number (which is a cpu index). > > Signed-off-by: Cédric Le Goater Looks correct as far as it goes,

Re: [Qemu-devel] [PATCH] vfio: Handle zero-length sparse mmap ranges

Hi, Your series seems to have some coding style problems. See output below for more information: Type: series Message-id: 20161025033140.15273.87118.st...@gimli.home Subject: [Qemu-devel] [PATCH] vfio: Handle zero-length sparse mmap ranges === TEST SCRIPT BEGIN === #!/bin/bash BASE=base n=1

Re: [Qemu-devel] [PATCH v8 02/36] qapi: Add ImageLockMode

On Fri, 10/21 22:45, Max Reitz wrote: > On 30.09.2016 14:09, Fam Zheng wrote: > > Signed-off-by: Fam Zheng > > --- > > qapi/block-core.json | 18 ++ > > 1 file changed, 18 insertions(+) > > > > diff --git a/qapi/block-core.json b/qapi/block-core.json > > index

Re: [Qemu-devel] [PATCH v5 11/17] ppc/xics: Add "native" XICS subclass

On Sat, Oct 22, 2016 at 11:46:44AM +0200, Cédric Le Goater wrote: > This provides access to the MMIO based Interrupt Presentation > Controllers (ICP) as found on a POWER8 system. > > A new XICSNative class is introduced to hold the MMIO region of the > ICPs. Each thread of the system has a

Re: [Qemu-devel] [PATCH] hw/arm/pxa2xx: Correctly handle external GPIO reset requests

Hi, Your series seems to have some coding style problems. See output below for more information: Subject: [Qemu-devel] [PATCH] hw/arm/pxa2xx: Correctly handle external GPIO reset requests Type: series Message-id: 1477361212-18833-1-git-send-email-li...@roeck-us.net === TEST SCRIPT BEGIN ===

Re: [Qemu-devel] [PATCH v5 14/17] ppc/xics: introduce a helper to insert a new ics

On Sat, Oct 22, 2016 at 11:46:47AM +0200, Cédric Le Goater wrote: > Interrupt Control Sources (ICS) are now maintained under a list. > > Signed-off-by: Cédric Le Goater Reviewed-by: David Gibson > --- > hw/intc/xics.c| 6 ++ >

Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support

We are able to derive significant performance from the qemu block driver as compared to nbd/iscsi/nfs. We have prototyped nfs and nbd based io tap in the past and the performance of qemu block driver is significantly better. Hence we would like to go with the vxhs driver for now. Ketan > On

[Qemu-devel] [PATCH 05/10] spapr: update spapr hotplug documentation

This updates the existing documentation to reflect recent updates to the hotplug event structure, which are in draft form but slated for inclusion in PAPR/LoPAPR. Signed-off-by: Michael Roth Reviewed-by: David Gibson ---

[Qemu-devel] [PATCH 07/10] spapr_events: add support for dedicated hotplug event source

Hotplug events were previously delivered using an EPOW interrupt and were queued by linux guests into a circular buffer. For traditional EPOW events like shutdown/resets, this isn't an issue, but for hotplug events there are cases where this buffer can be exhausted, resulting in the loss of

[Qemu-devel] [PATCH 08/10] spapr: Add DRC count indexed hotplug identifier type

From: Bharata B Rao Add support for DRC count indexed hotplug ID type which is primarily needed for memory hot unplug. This type allows for specifying the number of DRs that should be plugged/unplugged starting from a given DRC index. Signed-off-by: Bharata B Rao

[Qemu-devel] [PATCH 06/10] spapr: add hotplug interrupt machine options

This adds machine options of the form: -machine pseries,modern-hotplug-events=true -machine pseries,modern-hotplug-events=false If false, QEMU will force the use of "legacy" style hotplug events, which are surfaced through EPOW events instead of a dedicated hot plug event source, and lack

[Qemu-devel] [PATCH 01/10] spapr_ovec: initial implementation of option vector helpers

PAPR guests advertise their capabilities to the platform by passing an ibm,architecture-vec structure via an ibm,client-architecture-support hcall as described by LoPAPR v11, B.6.2.3. during early boot. Using this information, the platform enables the capabilities it supports, then encodes a

[Qemu-devel] [PATCH 00/10] spapr: option vector re-work and memory unplug support

This series is based on David's ppc-for-2.8 branch, and is also available from: https://github.com/mdroth/qemu/commits/spapr-hotplug-event-update Changes since RFC: * Submit as v1 now that PAPR Hotplug ACR is accepted * Rebase on latest ppc-for-2.8 (with device-tree refactoring) *

[Qemu-devel] [PATCH 04/10] spapr: improve ibm, architecture-vec-5 property handling

ibm,architecture-vec-5 is supposed to encode all option vector 5 bits negotiated between platform/guest. Currently we hardcode this property in the boot-time device tree to advertise a single negotiated capability, "Form 1" NUMA Affinity, regardless of whether or not CAS has been invoked or that

[Qemu-devel] [PATCH 02/10] spapr_hcall: use spapr_ovec_* interfaces for CAS options

Currently we access individual bytes of an option vector via ldub_phys() to test for the presence of a particular capability within that byte. Currently this is only done for the "dynamic reconfiguration memory" capability bit. If that bit is present, we pass a boolean value to

[Qemu-devel] [PATCH 09/10] spapr: use count+index for memory hotplug

Commit 0a417869: spapr: Move memory hotplug to RTAS_LOG_V6_HP_ID_DRC_COUNT type dropped per-DRC/per-LMB hotplugs event in favor of a bulk add via a single LMB count value. This was to avoid overrunning the guest EPOW event queue with hotplug events. This works fine, but relies on the guest

[Qemu-devel] [PATCH 03/10] spapr: add option vector handling in CAS-generated resets

In some cases, ibm,client-architecture-support calls can fail. This could happen in the current code for situations where the modified device tree segment exceeds the buffer size provided by the guest via the call parameters. In these cases, QEMU will reset, allowing an opportunity to regenerate

[Qemu-devel] [PATCH 10/10] spapr: Memory hot-unplug support

From: Bharata B Rao Add support to hot remove pc-dimm memory devices. Since we're introducing a machine-level unplug_request hook, we also had handling for CPU unplug there as well to ensure CPU unplug continues to work as it did before. Signed-off-by: Bharata B Rao

Re: [Qemu-devel] [PATCH 3/4] target-ppc: add vrldnmi and vrlwmi instructions

Richard Henderson writes: > On 10/24/2016 09:08 PM, Nikunj A Dadhania wrote: >> Richard Henderson writes: >> >>> On 10/24/2016 02:14 AM, Nikunj A Dadhania wrote: +#define EXTRACT_BITS(size) \ +static

Re: [Qemu-devel] [PATCH V7 0/2] Add option to configure guest vPMU

On 10/24/2016 03:49 AM, Andrew Jones wrote: > On Fri, Oct 21, 2016 at 05:53:00PM -0400, Wei Huang wrote: >> This patchset adds a pmu=[on/off] option to enable/disable vPMU support >> for guest VM. There are several reasons to justify this option. First, >> vPMU can be problematic for

Re: [Qemu-devel] [PATCH 3/6] target-ppc: add vextu[bhw]rx instructions

On 09/28/2016 11:15 AM, Rajalakshmi Srinivasaraghavan wrote: From: Hariharan T.S Attached updatde patch based on comments on vextu[bhw]lx. -- Thanks Rajalakshmi S >From f027eb4903b89720634423c335e3688cf1e8632d Mon Sep 17 00:00:00 2001 From: Rajalakshmi

Re: [Qemu-devel] [PATCH 2/6] target-ppc: add vextu[bhw]lx instructions

On 10/05/2016 10:51 AM, Rajalakshmi Srinivasaraghavan wrote: On 09/28/2016 10:24 PM, Richard Henderson wrote: On 09/27/2016 10:45 PM, Rajalakshmi Srinivasaraghavan wrote: +#if defined(HOST_WORDS_BIGENDIAN) +#define VEXTULX_DO(name, elem) \ +target_ulong

Re: [Qemu-devel] [PATCH 3/4] target-ppc: add vrldnmi and vrlwmi instructions

On 10/24/2016 09:08 PM, Nikunj A Dadhania wrote: Richard Henderson writes: On 10/24/2016 02:14 AM, Nikunj A Dadhania wrote: +#define EXTRACT_BITS(size) \ +static inline uint##size##_t extract_bits_u##size(uint##size##_t reg, \

Re: [Qemu-devel] [PATCH 3/4] target-ppc: add vrldnmi and vrlwmi instructions

Richard Henderson writes: > On 10/24/2016 02:14 AM, Nikunj A Dadhania wrote: >> +#define EXTRACT_BITS(size) \ >> +static inline uint##size##_t extract_bits_u##size(uint##size##_t reg, \ >> +

Re: [Qemu-devel] [PATCHv5 00/12] Cleanups to qtest PCI handling

On Mon, Oct 24, 2016 at 03:59:49PM +1100, David Gibson wrote: > This series contains a number of cleanups to the libqos code for > accessing PCI devices, and to tests which use it. > > The general aim is to improve the consistency of semantics across > functions, and reduce the amount of intimate

Re: [Qemu-devel] [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

On Sun, Oct 23, 2016 at 11:29:25AM +, Li, Liang Z wrote: > > On Fri, Oct 21, 2016 at 10:25:21AM -0700, Dave Hansen wrote: > > > On 10/20/2016 11:24 PM, Liang Li wrote: > > > > Dave Hansen suggested a new scheme to encode the data structure, > > > > because of additional complexity, it's not

Re: [Qemu-devel] Holding the BQL for emulate_ppc_hypercall

Alex Bennée writes: > Hi, > > In the MTTCG patch set one of the big patches is to remove the > requirement to hold the BQL while running code: > > tcg: drop global lock during TCG code execution > > And this broke the PPC code because emulate_ppc_hypercall can cause >

Re: [Qemu-devel] [PATCHv3 00/12] pseries: Consolidate guest device tree construction

On Tue, Oct 25, 2016 at 02:23:41PM +1100, David Gibson wrote: > On Tue, Oct 25, 2016 at 01:50:02PM +1100, David Gibson wrote: > > On Mon, Oct 24, 2016 at 04:04:31PM +1100, David Gibson wrote: > > > For historical reasons construction of the guest device tree in spapr > > > is divided between

[Qemu-devel] [PATCH] vfio: Handle zero-length sparse mmap ranges

As reported in the link below, user has a PCI device with a 4KB BAR which contains the MSI-X table. This seems to hit a corner case in the kernel where the region reports being mmap capable, but the sparse mmap information reports a zero sized range. It's not entirely clear that the kernel is

Re: [Qemu-devel] [PATCHv3 00/12] pseries: Consolidate guest device tree construction

On Tue, Oct 25, 2016 at 01:50:02PM +1100, David Gibson wrote: > On Mon, Oct 24, 2016 at 04:04:31PM +1100, David Gibson wrote: > > For historical reasons construction of the guest device tree in spapr > > is divided between spapr_create_fdt_skel() which is called at init > > time, and

[Qemu-devel] [PATCH 4/4] block/curl: Do not wait for data beyond EOF

libcurl will only give us as much data as there is, not more. The block layer will deny requests beyond the end of file for us; but since this block driver is still using a sector-based interface, we can still get in trouble if the file size is not a multiple of 512. While we have already made

Re: [Qemu-devel] Holding the BQL for emulate_ppc_hypercall

On Mon, Oct 24, 2016 at 03:44:01PM +0100, Alex Bennée wrote: > > Alex Bennée writes: > > > Hi, > > > > In the MTTCG patch set one of the big patches is to remove the > > requirement to hold the BQL while running code: > > > > tcg: drop global lock during TCG code

[Qemu-devel] [PATCH 0/4] block/curl: Fix FTP

At least for me, the FTP support of our curl block driver currently doesn't work at all. This is due to (at least) three issues, for each of which this series provides a patch (and the first patch is just a minor clean-up). 1. When establishing an FTP connection, libcurl hands us some data we do

[Qemu-devel] [PATCH 3/4] block/curl: Remember all sockets

For some connection types (like FTP, generally), more than one socket may be used (in FTP's case: control vs. data stream). As of commit 838ef602498b8d1985a231a06f5e328e2946a81d ("curl: Eliminate unnecessary use of curl_multi_socket_all"), we have to remember all of the sockets used by libcurl,

Re: [Qemu-devel] [PATCH v5 07/17] ppc/pnv: add XSCOM infrastructure

On Sat, Oct 22, 2016 at 11:46:40AM +0200, Cédric Le Goater wrote: > On a real POWER8 system, the Pervasive Interconnect Bus (PIB) serves > as a backbone to connect different units of the system. The host > firmware connects to the PIB through a bridge unit, the > Alter-Display-Unit (ADU), which

[Qemu-devel] [PATCH 1/4] block/curl: Use BDRV_SECTOR_SIZE

Currently, curl defines its own constant SECTOR_SIZE. There is no advantage over using the global BDRV_SECTOR_SIZE, so drop it. Cc: qemu-sta...@nongnu.org Signed-off-by: Max Reitz --- block/curl.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git

Re: [Qemu-devel] [PATCHv3 00/12] pseries: Consolidate guest device tree construction

On Mon, Oct 24, 2016 at 04:04:31PM +1100, David Gibson wrote: > For historical reasons construction of the guest device tree in spapr > is divided between spapr_create_fdt_skel() which is called at init > time, and spapr_build_fdt() which runs at reset time. Over time, more > and more things have

[Qemu-devel] [PATCH 2/4] block/curl: Fix return value from curl_read_cb

While commit 38bbc0a580f9f10570b1d1b5d3e92f0e6feb2970 is correct in that the callback is supposed to return the number of bytes handled; what it does not mention is that libcurl will throw an error if the callback did not "handle" all of the data passed to it. Therefore, if the callback receives

Re: [Qemu-devel] [PATCH 2/4] target-ppc: add vmul10[u, eu, cu, ecu]q instructions

On Mon, Oct 24, 2016 at 09:04:13AM -0700, Richard Henderson wrote: > On 10/24/2016 02:14 AM, Nikunj A Dadhania wrote: > > From: Vasant Hegde > > > > vmul10uq : Vector Multiply-by-10 Unsigned Quadword VX-form > > vmul10euq : Vector Multiply-by-10 Extended Unsigned

Re: [Qemu-devel] [PATCHv2 01/12] pseries: Split device tree construction from device tree load

On Mon, Oct 24, 2016 at 04:17:05PM +1100, Alexey Kardashevskiy wrote: > On 21/10/16 13:56, David Gibson wrote: > > spapr_finalize_fdt() both finishes building the device tree for the guest > > and loads it into guest memory. For future cleanups, it's going to be > > more convenient to do these

Re: [Qemu-devel] [PATCH v2] ppc: allow certain HV interrupts to be delivered to guests

On Mon, Oct 24, 2016 at 05:56:22PM +1100, Nicholas Piggin wrote: > On Mon, 24 Oct 2016 12:16:19 +1100 > David Gibson wrote: > > > On Fri, Oct 21, 2016 at 03:35:43PM +1100, Nicholas Piggin wrote: > > > On Fri, 21 Oct 2016 12:09:54 +1100 > > > David Gibson

Re: [Qemu-devel] [PATCH v5 08/17] ppc/pnv: add XSCOM handlers to PnvCore

On Sat, Oct 22, 2016 at 11:46:41AM +0200, Cédric Le Goater wrote: > Now that we are using real HW ids for the cores in PowerNV chips, we > can route the XSCOM accesses to them. We just need to attach a > specific XSCOM memory region to each core in the appropriate window > for the core number. >

Re: [Qemu-devel] [PATCH v5 00/17] ppc/pnv: booting the kernel and reaching user space

On Mon, Oct 24, 2016 at 04:33:33PM +1100, David Gibson wrote: > On Sat, Oct 22, 2016 at 11:46:33AM +0200, Cédric Le Goater wrote: > > Hello, > > > > Here is the latest version of the ppc/pnv platform patchset. PowerNV > > (as Non-Virtualized) is the "baremetal" platform using the OPAL > >

Re: [Qemu-devel] [Qemu-stable] [Qemu-ppc] [PULL 0/4] ppc patches for qemu-2.7 stable branch

On Mon, Oct 17, 2016 at 04:24:31PM -0500, Michael Roth wrote: > Quoting Peter Maydell (2016-10-17 13:45:21) > > On 17 October 2016 at 19:13, Michael Roth wrote: > > > We could do both though: use some ad-hoc way to tag for a particular > > > sub-maintainer tree/stable

[Qemu-devel] [PATCH] hw/arm/pxa2xx: Set value default values for CCCR and CKEN on PXA255

The code used default values for PXA270 to configure CCCR. For PXA255, the resulting register value is invalid (unsupported) and resulted in a division by zero in the Linux kernel. Use default values from datasheet instead. Signed-off-by: Guenter Roeck --- hw/arm/pxa2xx.c |

[Qemu-devel] [PATCH] hw/arm/pxa2xx: Correctly handle external GPIO reset requests

The internal GPIO reset, enabled with GPR_EN, only applies to GPIO pin 1. If other GPIO pins are used for reset, this is unrelated to GPR_EN, the reset is an external reset pin, and it resets the entire system. This fixes GPIO reset failures seen with various PXA270 emulations (akita, borzoi,

[Qemu-devel] [PATCH] arm: cubieboard: Add support for initrd

Signed-off-by: Guenter Roeck --- hw/arm/cubieboard.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/arm/cubieboard.c b/hw/arm/cubieboard.c index fbd78ed..dd19ba3 100644 --- a/hw/arm/cubieboard.c +++ b/hw/arm/cubieboard.c @@ -74,6 +74,7 @@ static void

[Qemu-devel] [PATCH] i.MX: Fix GPIO ISR register write

Writing the ISR register is supposed to clear interrupt status bits, not to set them. This patch makes '-M sabrelite' work without devicetree changes (Linux kernel versions 3.18 to 4.7 with imx_v6_v7_defconfig and up to v4.8 with multi_v7_defconfig; mainline has different problems).

Re: [Qemu-devel] [PATCH] nbd: Use CoQueue for free_sema instead of CoMutex

On 10/24/2016 05:36 PM, Paolo Bonzini wrote: On 24/10/2016 03:44, Changlong Xie wrote: Ping. Any comments? It's really a problem for NBD. Sorry, I haven't been sending pull requests. I'll do it this week. Thanks : ) Paolo Thanks -Xie On 10/12/2016 06:18 PM, Changlong Xie

Re: [Qemu-devel] [RESEND PATCH v3 kernel 3/7] mm: add a function to get the max pfn

> On 10/20/2016 11:24 PM, Liang Li wrote: > > Expose the function to get the max pfn, so it can be used in the > > virtio-balloon device driver. Simply include the 'linux/bootmem.h' > > is not enough, if the device driver is built to a module, directly > > refer the max_pfn lead to build failed. >

Re: [Qemu-devel] [RESEND PATCH v3 kernel 2/7] virtio-balloon: define new feature bit and page bitmap head

> On 10/20/2016 11:24 PM, Liang Li wrote: > > Add a new feature which supports sending the page information with a > > bitmap. The current implementation uses PFNs array, which is not very > > efficient. Using bitmap can improve the performance of > > inflating/deflating significantly > > Why is

Re: [Qemu-devel] [RESEND PATCH v3 kernel 1/7] virtio-balloon: rework deflate to add page to a list

> On 10/20/2016 11:24 PM, Liang Li wrote: > > Will allow faster notifications using a bitmap down the road. > > balloon_pfn_to_page() can be removed because it's useless. > > This is a pretty terse description of what's going on here. Could you try to > elaborate a bit? What *is* the current

Re: [Qemu-devel] [PATCHv3 01/12] pseries: Split device tree construction from device tree load

On 24/10/16 16:04, David Gibson wrote: > spapr_finalize_fdt() both finishes building the device tree for the guest > and loads it into guest memory. For future cleanups, it's going to be > more convenient to do these two things separately. The loading portion is > pretty trivial, so we move it

Re: [Qemu-devel] [Qemu-arm] [PATCH] char: cadence: check divider against baud rate

On Mon, Oct 24, 2016 at 6:25 AM, P J P wrote: > +-- On Mon, 24 Oct 2016, Alistair Francis wrote --+ > | > | > http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf > | > | Did the TRM have enough detail for you to figure out how the hardware >

Re: [Qemu-devel] Assertion failure on qcow2 disk with cluster_size != 64k

On Mon, Oct 24, 2016 at 2:21 PM, Eric Blake wrote: > How are you getting max_transfer == 65536? I can't reproduce it with > the following setup: > > $ qemu-img create -f qcow2 -o cluster_size=1M file 10M > $ qemu-io -f qcow2 -c 'w 7m 1k' file > $ qemu-io -f qcow2 -c 'w -z

[Qemu-devel] [PATCH 2/2] memory: Don't use memcpy for ram_device regions

With a vfio assigned device we lay down a base MemoryRegion registered as an IO region, giving us read & write accessors. If the region supports mmap, we lay down a higher priority sub-region MemoryRegion on top of the base layer initialized as a RAM device pointer to the mmap. Finally, if we

[Qemu-devel] [PATCH 1/2] memory: Replace skip_dump flag with "ram_device"

Setting skip_dump on a MemoryRegion allows us to modify one specific code path, but the restriction we're trying to address encompasses more than that. If we have a RAM MemoryRegion backed by a physical device, it not only restricts our ability to dump that region, but also affects how we should

[Qemu-devel] [PATCH 0/2] memory: Convert skip_dump to ram_device and avoid memcpy

As based on previous RFC: https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg05183.html TL;DR, this adds tracing, converts skip_dump to ram_device (named after rom_device), adds full access widths, identifies ram_device regions based on ops pointer. Paolo had suggested converting

[Qemu-devel] [Bug 1004408] Re: BUG: Soft Lockup - CPU#0 stuck for 22s! [qemu-system-x86: 31867]

Thanks for the bug report, but please report kernel bugs in the kernel bug tracker, not in the QEMU bug tracker (see http://www.linux- kvm.org/page/Bugs for details). So if the problem still persists with recent kernels, you should open a ticket there instead. ** Changed in: qemu Status:

[Qemu-devel] [Bug 977391] Re: BUG: soft lockup - CPU#8 stuck for 61s! [kvm:*] in lucid

This sounds like a kernel bug, so it should not be tracked via the QEMU bug tracker. ** No longer affects: qemu -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/977391 Title: BUG: soft lockup -

Re: [Qemu-devel] [RFC PATCH] memory: Don't use memcpy for ram marked as skip_dump

Am 22.10.2016 um 17:09 schrieb Alex Williamson: On Sat, 22 Oct 2016 11:10:59 +0200 Thorsten Kohfeldt wrote: Hi *, this came to my mind when browsing the sources in the patch's vicinity. It is just a collection of thoughts, so please don't feel offended about how I

Re: [Qemu-devel] [PATCH v9 05/12] vfio: Introduce common function to add capabilities

On Tue, 25 Oct 2016 02:57:58 +0530 Kirti Wankhede wrote: > On 10/21/2016 12:54 AM, Alex Williamson wrote: > > On Tue, 18 Oct 2016 02:52:05 +0530 > > Kirti Wankhede wrote: > > > >> Vendor driver using mediated device framework should use > >>

Re: [Qemu-devel] [PATCH v9 06/12] vfio_pci: Update vfio_pci to use vfio_info_add_capability()

On Tue, 25 Oct 2016 02:52:39 +0530 Kirti Wankhede wrote: > On 10/21/2016 12:54 AM, Alex Williamson wrote: > > On Tue, 18 Oct 2016 02:52:06 +0530 > > Kirti Wankhede wrote: > > > >> Update msix_sparse_mmap_cap() to use vfio_info_add_capability() > >>

[Qemu-devel] [Bug 995758] Re: Possibly inaccurate statement in PC Platform Docs

OK, I just read the text again, and the sentences before the one with the 0xf indeed sounded like the the start address was at the last byte. I've reworded the text now a little bit so that it should be more accurate. ** Changed in: qemu Status: Invalid => Fix Released -- You

Re: [Qemu-devel] [V7 1/1] fsdev: add IO throttle support to fsdev devices

Re-post (I had hit the send button by error :) On Sat, 22 Oct 2016 11:07:22 -0400 Pradeep Jagadeesh wrote: > Signed-off-by: Pradeep Jagadeesh > --- Hi Pradeep, I see that Berto already did a thorough review for this patch and I agree

Re: [Qemu-devel] [PATCH v9 05/12] vfio: Introduce common function to add capabilities

On 10/21/2016 12:54 AM, Alex Williamson wrote: > On Tue, 18 Oct 2016 02:52:05 +0530 > Kirti Wankhede wrote: > >> Vendor driver using mediated device framework should use >> vfio_info_add_capability() to add capabilities. >> Introduced this function to reduce code

Re: [Qemu-devel] [V7 1/1] fsdev: add IO throttle support to fsdev devices

On Sat, 22 Oct 2016 11:07:22 -0400 Pradeep Jagadeesh wrote: > Signed-off-by: Pradeep Jagadeesh > --- Hi Pradeep, I see that Berto already did a thorough review for this patch and I agree for all the suggestions he made. I have some

Re: [Qemu-devel] [PATCH v9 06/12] vfio_pci: Update vfio_pci to use vfio_info_add_capability()

On 10/21/2016 12:54 AM, Alex Williamson wrote: > On Tue, 18 Oct 2016 02:52:06 +0530 > Kirti Wankhede wrote: > >> Update msix_sparse_mmap_cap() to use vfio_info_add_capability() >> Update region type capability to use vfio_info_add_capability() >> Can't split this commit

Re: [Qemu-devel] Assertion failure on qcow2 disk with cluster_size != 64k

On 10/20/2016 07:24 PM, Ed Swierk wrote: > Shortly after I start qemu 2.7.0 with a qcow2 disk image created with > -o cluster_size=1048576, it prints the following and dies: > > block/qcow2.c:2451: qcow2_co_pwrite_zeroes: Assertion `head + count <= > s->cluster_size' failed. > > I narrowed the

[Qemu-devel] [Bug 995758] Re: Possibly inaccurate statement in PC Platform Docs

As far as I can see, the wording on the page only says that the BIOS ends at address 0xF, not that it starts execution at exactly that address. So I think that page is ok. ** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member of

Re: [Qemu-devel] vt-x support for qemu

Hi, I have the following setup. I'm running qemu in software mode, installed KVM inside qemu. And on top of that I need to run qemu again but with kvm enabled. But I'm getting the following error when I try to do that. Can somebody please help me with this? KVM internal error. Suberror: 1

[Qemu-devel] [PATCH v2 4/6] blockjob: add block_job_start

Instead of automatically starting jobs at creation time via backup_start et al, we'd like to return a job object pointer that can be started manually at later point in time. For now, add the block_job_start mechanism and start the jobs automatically as we have been doing, with conversions

[Qemu-devel] [PATCH v2 5/6] blockjob: refactor backup_start as backup_job_create

Refactor backup_start as backup_job_create, which only creates the job, but does not automatically start it. The old interface, 'backup_start', is not kept in favor of limiting the number of nearly-identical interfaces that would have to be edited to keep up with QAPI changes in the future.

[Qemu-devel] [PATCH v2 0/6] jobs: fix transactional race condition

Requires: [Qemu-devel] [PATCH 0/7] blockjobs: preliminary refactoring work, Pt 1 There are a few problems with transactional job completion right now. First, if jobs complete so quickly they complete before remaining jobs get a chance to join the transaction, the completion mode can leave well

[Qemu-devel] [PATCH v2 6/6] iotests: add transactional failure race test

Add a regression test for the case found by Vladimir. Reported-by: Vladimir Sementsov-Ogievskiy Signed-off-by: John Snow --- tests/qemu-iotests/124 | 53 ++ tests/qemu-iotests/124.out | 4 ++-- 2 files

[Qemu-devel] [PATCH v2 1/6] blockjob: fix dead pointer in txn list

From: Vladimir Sementsov-Ogievskiy Though it is not intended to be reached through normal circumstances, if we do not gracefully deconstruct the transaction QLIST, we may wind up with stale pointers in the list. The rest of this series attempts to address the

[Qemu-devel] [PATCH v2 2/6] blockjob: add .clean property

Cleaning up after we have deferred to the main thread but before the transaction has converged can be dangerous and result in deadlocks if the job cleanup invokes any BH polling loops. A job may attempt to begin cleaning up, but may induce another job to enter its cleanup routine. The second job,

[Qemu-devel] [PATCH v2 3/6] blockjob: add .start field

Add an explicit start field to specify the entrypoint. We already have ownership of the coroutine itself AND managing the lifetime of the coroutine, let's take control of creation of the coroutine, too. This will allow us to delay creation of the actual coroutine until we know we'll actually

[Qemu-devel] [Bug 1017793] Re: S3 Trio64V+ support

** Changed in: qemu Importance: Undecided => Wishlist -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1017793 Title: S3 Trio64V+ support Status in QEMU: New Bug description: Is it possible

[Qemu-devel] [Bug 1013691] Re: ppc64 + virtio-scsi: only first scsi disk shows up in the guest

** Tags added: ppc -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1013691 Title: ppc64 + virtio-scsi: only first scsi disk shows up in the guest Status in QEMU: New Bug description: When

[Qemu-devel] [Bug 1543057] Re: Warnings are treated as errors

Closing this as invalid - unless you can reproduce this with the latest release version or the current master branch again, then please feel free to open this ticket again. ** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member of qemu-

[Qemu-devel] [PATCH 7/7] acpi/ipmi: Initialize the fwinfo before fetching it

From: Corey Minyard The initialization was missed before, resulting in some bad data in the smbus case. Signed-off-by: Corey Minyard --- hw/acpi/ipmi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/acpi/ipmi.c b/hw/acpi/ipmi.c index

[Qemu-devel] [PATCH 3/7] ipmi: chassis poweroff should use qemu_system_shutdown_request()

From: Cédric Le Goater When issuing a chassis 'powerdown' control command, the routine qemu_system_shutdown_request() should be used to exit the guest. qemu_system_powerdown_request() will initiate a soft shutdown which is not what is required by the IPMI (28.3 Chassis Control

[Qemu-devel] [PATCH 2/7] ipmi_bmc_sim: Remove an unnecessary mutex

From: Corey Minyard Get rid of the unnecessary mutex, it was a vestige of something else that was not done. That way we don't have to free it. Signed-off-by: Corey Minyard Reviewed-by: Marc-André Lureau ---

[Qemu-devel] [PATCH 0/7] ipmi: Various little IPMI fixes

I've posted these before in various forms, but they haven't been picked up. These are little fixed noticed by others and myself, nothing huge, but things that needed attention. -corey

Re: [Qemu-devel] target-ppc: gdbstub breakpoints get stuck in an infinite loop on next/continue

On Mon, 2016-10-24 at 12:00 +1100, David Gibson wrote: > Ben, does it look like the other extraneous changes in bd6fefe are at > least correct, apart from being in the wrong patch? It looks like part of my big rewrite of the exception stuff, so I'd assume it's mostly correct minus a few bugs I

Re: [Qemu-devel] Assertion failure on qcow2 disk with cluster_size != 64k

On 10/21/2016 08:14 AM, Ed Swierk wrote: > On Thu, Oct 20, 2016 at 6:38 PM, Eric Blake wrote: >> On 10/20/2016 07:24 PM, Ed Swierk wrote: >>> Changing max_transfer in the normal write case to >>> MIN_NON_ZERO(alignment, MAX_WRITE_ZEROES_BOUNCE_BUFFER) appears to fix >>> the

[Qemu-devel] [PULL v2 02/16] pc: acpi: x2APIC support for SRAT table

From: Igor Mammedov Signed-off-by: Igor Mammedov Reviewed-by: Eduardo Habkost Signed-off-by: Eduardo Habkost --- hw/i386/acpi-build.c| 34 --

[Qemu-devel] [PULL v2 01/16] pc: acpi: x2APIC support for MADT table and _MAT method

From: Igor Mammedov Signed-off-by: Igor Mammedov Reviewed-by: Eduardo Habkost Signed-off-by: Eduardo Habkost --- hw/acpi/cpu.c | 5 +++ hw/i386/acpi-build.c| 78

[Qemu-devel] [PULL v2 00/16] x86 and CPU queue, 2016-10-24

Change in v2: * Removed patch: "target-i386: Print warning when mixing [+-]foo and foo=(on|off)" The following changes since commit a3ae21ec3fe036f536dc94cad735931777143103: Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging (2016-10-24 15:03:09 +0100) are

[Qemu-devel] [PATCH 6/7] ipmi: Add graceful shutdown handling to the external BMC

From: Corey Minyard I misunderstood the workings of the power settings, the power off is a force off operation and there needs to be a separate graceful shutdown operation. So replace the force off operation with a graceful shutdown. Signed-off-by: Corey Minyard

[Qemu-devel] [PATCH 5/7] ipmi: fix build config variable name for ipmi_bmc_extern.o

From: "Daniel P. Berrange" The original commit: commit 67aa56fc03bea44ccf384ea400515a8a58844a50 Author: Corey Minyard Date: Thu Dec 17 12:50:06 2015 -0600 ipmi: Add an external connection simulation interface defined a new variable

  1   2   3   4   5   >