Re: [Qemu-devel] [PATCH 2/2] configure: use pkg-config for obtaining xen version

On 16/03/17 21:20, Stefano Stabellini wrote: > On Thu, 16 Mar 2017, Juergen Gross wrote: >> Instead of trying to guess the Xen version to use by compiling various >> test programs first just ask the system via pkg-config. Only if it >> can't return the version fall back to the test program scheme.

Re: [Qemu-devel] [PATCH v2] puv3: always compile-check debug printf

On Thu, Mar 16, 2017 at 11:11:33AM +0530, Anishka0107 wrote: > To prevent bitrot of the format string of the debug statement, files with > conditional debug statements should ensure that printf is compiled > always, > and enclosed within if(0) statements and not in #ifdef. > >

Re: [Qemu-devel] [PATCH] block: Make 'replication_state' an enum

On Fri, 03/17 10:17, Fam Zheng wrote: > BDRVReplicationState.replication_state is a name with a bit of > duplication, plus it could be an enum like BDRVReplicationState.mode, > which is be more readable and also more straightforward in a debuuger. s/is be/is/ s/debuuger/debugger/ Can I blame the

[Qemu-devel] [PATCH v4 10/11] s390x/css: ccw translation infrastructure

From: Xiao Feng Ren Implement a basic infrastructure of handling channel I/O instruction interception for passed through subchannels: 1. Branch the code path of instruction interception handling by SubChannel type. 2. For a passed-through subchannel, issue the ORB

[Qemu-devel] [PATCH v4 11/11] vfio/ccw: update sense data if a unit check is pending

Concurrent-sense data is currently not delivered. This patch stores the concurrent-sense data to the subchannel if a unit check is pending and the concurrent-sense bit is enabled. Then a TSCH can retreive the right IRB data back to the guest. Signed-off-by: Dong Jia Shi

[Qemu-devel] 答复: Re: COLO :ailover hang

hi. I test the git qemu master have the same problem. (gdb) bt #0 qio_channel_socket_readv (ioc=0x7f65911b4e50, iov=0x7f64ef3fd880, niov=1, fds=0x0, nfds=0x0, errp=0x0) at io/channel-socket.c:461 #1 0x7f658e4aa0c2 in qio_channel_read (ioc=ioc@entry=0x7f65911b4e50,

[Qemu-devel] [PATCH v4 02/11] s390x/css: add s390-squash-mcss machine option

From: Xiao Feng Ren We want to support real (i.e. not virtual) channel devices even for guests that do not support MCSS-E (where guests may see devices from any channel subsystem image at once). As all virtio-ccw devices are in css 0xfe (and show up in the default

[Qemu-devel] [PATCH v4 09/11] s390x/css: introduce and realize ccw-request callback

From: Xiao Feng Ren Introduce a new callback on subchannel to handle ccw-request. Realize the callback in vfio-ccw device. Besides, resort to the event notifier handler to handling the ccw-request results. 1. Pread the I/O results via MMIO region. 2. Update the scsw

[Qemu-devel] [PATCH v4 06/11] vfio/ccw: vfio based subchannel passthrough driver

From: Xiao Feng Ren We use the IOMMU_TYPE1 of VFIO to realize the subchannels passthrough, implement a vfio based subchannels passthrough driver called "vfio-ccw". Support qemu parameters in the style of: "-device vfio-ccw,sysfsdev=$mdev_file_path,devno=xx.x.'

[Qemu-devel] [PATCH v4 08/11] vfio/ccw: get irqs info and set the eventfd fd

vfio-ccw resorts to the eventfd mechanism to communicate with userspace. We fetch the irqs info via the ioctl VFIO_DEVICE_GET_IRQ_INFO, register a event notifier to get the eventfd fd which is sent to kernel via the ioctl VFIO_DEVICE_SET_IRQS, then we can implement read operation once kernel sends

[Qemu-devel] [PATCH v4 15/16] vfio: ccw: introduce support for ccw0

Although Linux does not use format-0 channel command words (CCW0) these are a non-optional part of the platform spec, and for the sake of platform compliance, and possibly some non-Linux guests, we have to support CCW0. Making the kernel execute a format 0 channel program is too much hassle

[Qemu-devel] [PATCH v4 05/11] s390x/css: device support for s390-ccw passthrough

In order to support subchannels pass-through, we introduce a s390 subchannel device called "s390-ccw" to hold the real subchannel info. The s390-ccw devices inherit from the abstract CcwDevice which connect to the existing virtual-css-bus. Signed-off-by: Dong Jia Shi

[Qemu-devel] [PATCH v4 16/16] MAINTAINERS: Add vfio-ccw maintainers

Add Cornelia Huck and myself as the vfio-ccw driver maintainers. Signed-off-by: Dong Jia Shi --- MAINTAINERS | 10 ++ 1 file changed, 10 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index c776906..01a6675 100644 --- a/MAINTAINERS +++ b/MAINTAINERS

[Qemu-devel] [PATCH v4 07/11] vfio/ccw: get io region info

vfio-ccw provides an MMIO region for I/O operations. We fetch its information via ioctls here, then we can use it performing I/O instructions and retrieving I/O results later on. Signed-off-by: Dong Jia Shi --- hw/vfio/ccw.c | 52

[Qemu-devel] [PATCH v4 12/16] vfio: ccw: return I/O results asynchronously

Introduce a singlethreaded workqueue to handle the I/O interrupts. With the work added to this queue, we store the I/O results to the io_region of the subchannel, then signal the userspace program to handle the results. Signed-off-by: Dong Jia Shi ---

[Qemu-devel] [PATCH v4 14/16] docs: add documentation for vfio-ccw

Add file Documentation/s390/vfio-ccw.txt that includes details of vfio-ccw. Acked-by: Pierre Morel Signed-off-by: Dong Jia Shi --- Documentation/s390/00-INDEX | 2 + Documentation/s390/vfio-ccw.txt | 303

[Qemu-devel] [PATCH v4 03/11] s390x/css: realize css_sch_build_schib

From: Xiao Feng Ren The S390 virtual css support already has a mechanism to build virtual Sub-Channel Information Block and provide virtual subchannels to the guest. However, to pass-through subchannels to a guest, we need to introduce a new mechanism to build its

[Qemu-devel] [PATCH v4 04/11] s390x/css: realize css_create_sch

The S390 virtual css support already has a mechanism to create a virtual subchannel and provide it to the guest. However, to pass-through subchannels to a guest, we need to introduce a new mechanism to create the subchannel according to the real device information. Thus we reconstruct

[Qemu-devel] [PATCH v4 13/16] vfio: ccw: introduce a finite state machine

The current implementation doesn't check if the subchannel is in a proper device state when handling an event. Let's introduce a finite state machine to manage the state/event change. Signed-off-by: Dong Jia Shi --- drivers/s390/cio/Makefile | 2 +-

[Qemu-devel] [PATCH v4 10/16] vfio: ccw: realize VFIO_DEVICE_RESET ioctl

Introduce VFIO_DEVICE_RESET ioctl for vfio-ccw to make it possible to hot-reset the device. We try to achieve a reset by first disabling the subchannel and then enabling it again: this should clear all state at the subchannel. Signed-off-by: Dong Jia Shi ---

[Qemu-devel] [PATCH v4 01/11] vfio: linux-headers update for vfio-ccw

This is a placeholder for a linux-headers update. Signed-off-by: Dong Jia Shi --- linux-headers/linux/vfio.h | 17 + linux-headers/linux/vfio_ccw.h | 28 2 files changed, 45 insertions(+) create mode 100644

[Qemu-devel] [PATCH v4 04/16] vfio: ccw: basic implementation for vfio_ccw driver

To make vfio support subchannel devices, we need a css driver for the vfio subchannels. This patch adds a basic vfio-ccw subchannel driver for this purpose. To enable VFIO for vfio-ccw, enable S390_CCW_IOMMU config option and configure VFIO as required. Acked-by: Pierre Morel

[Qemu-devel] [PATCH v4 00/11] basic channel IO passthrough infrastructure based on vfio

The patch series introduce a basic channel I/O passthrough infrastructure based on vfio. - Focus on supporting dasd-eckd(cu_type/dev_type = 0x3990/0x3390) as the target device. - Support new qemu parameters in the style of: -machine s390-ccw-virtio(,s390-squash-mcss=on|off) \ -device

[Qemu-devel] [PATCH v4 11/16] vfio: ccw: realize VFIO_DEVICE_G(S)ET_IRQ_INFO ioctls

Realize VFIO_DEVICE_GET_IRQ_INFO ioctl to retrieve VFIO_CCW_IO_IRQ information. Realize VFIO_DEVICE_SET_IRQS ioctl to set an eventfd fd for VFIO_CCW_IO_IRQ. Once a write operation to the ccw_io_region was performed, trigger a signal on this fd. Reviewed-by: Pierre Morel

[Qemu-devel] [PATCH v4 08/16] vfio: ccw: handle ccw command request

We implement the basic ccw command handling infrastructure here: 1. Translate the ccw commands. 2. Issue the translated ccw commands to the device. 3. Once we get the execution result, update the guest SCSW with it. Acked-by: Pierre Morel Signed-off-by: Dong Jia Shi

[Qemu-devel] [PATCH v4 02/16] s390: cio: export more interfaces

Export the common I/O interfaces those are needed by an I/O subchannel driver to actually talk to the subchannel. Reviewed-by: Pierre Morel Signed-off-by: Dong Jia Shi Cc: Sebastian Ott Cc: Peter Oberparleiter

[Qemu-devel] [PATCH v4 09/16] vfio: ccw: realize VFIO_DEVICE_GET_REGION_INFO ioctl

Introduce device information about vfio-ccw: VFIO_DEVICE_FLAGS_CCW. Realize VFIO_DEVICE_GET_REGION_INFO ioctl for vfio-ccw. Reviewed-by: Pierre Morel Signed-off-by: Dong Jia Shi --- drivers/s390/cio/vfio_ccw_ops.c | 78

[Qemu-devel] [PATCH v4 05/16] vfio: ccw: introduce channel program interfaces

Introduce ccwchain structure and helper functions that can be used to handle a channel program issued from a virtual machine. The following limitations apply: 1. Supports only prefetch enabled mode. 2. Supports idal(c64) ccw chaining. 3. Supports 4k idaw. 4. Supports ccw1. 5. Supports direct ccw

[Qemu-devel] [PATCH v4 07/16] vfio: ccw: introduce ccw_io_region

To provide user-space a set of interfaces to: 1. pass in a ccw program to perform an I/O operation. 2. read back I/O results of the completed I/O operations. We introduce an MMIO region for the vfio-ccw device here. This region is defined to content: 1. areas to store arguments that an ssch

[Qemu-devel] [PATCH v4 06/16] vfio: ccw: register vfio_ccw to the mediated device framework

To make vfio support subchannel devices, we need to leverage the mediated device framework to create a mediated device for the subchannel device. This registers the subchannel device to the mediated device framework during probe to enable mediated device creation. Reviewed-by: Pierre Morel

[Qemu-devel] [PATCH v4 03/16] vfio: ccw: define device_api strings

Define vfio-ccw device API strings. CCW vendor driver using mediated device framework should use this string for device_api attribute. Reviewed-by: Pierre Morel Signed-off-by: Dong Jia Shi --- include/uapi/linux/vfio.h | 1 + 1 file

[Qemu-devel] [PATCH v4 00/16] basic vfio-ccw infrastructure

vfio-ccw: the basic infrastructure == Introduction Here we describe the vfio support for I/O subchannel devices for Linux/s390. Motivation for vfio-ccw is to passthrough subchannels to a virtual machine, while vfio is the means. Different than other

[Qemu-devel] [PATCH v4 01/16] s390: cio: introduce cio_cancel_halt_clear

For future code reuse purpose, this decouples the cio code with the ccw device specific parts from ccw_device_cancel_halt_clear, and makes a new common I/O interface named cio_cancel_halt_clear. Reviewed-by: Pierre Morel Signed-off-by: Dong Jia Shi

Re: [Qemu-devel] [PATCH v1 1/1] vmstate: fix failed iotests case 68 and 91

在 2017/3/16 16:01, Juan Quintela 写道: QingFeng Hao wrote: This problem affects s390x only if we are running without KVM. Basically, S390CPU.irqstate is unused if we do not use KVM, and thus no buffer is allocated. This causes size=0, first_elem=NULL and n_elems=1 in

[Qemu-devel] [PATCH] block: Make 'replication_state' an enum

BDRVReplicationState.replication_state is a name with a bit of duplication, plus it could be an enum like BDRVReplicationState.mode, which is be more readable and also more straightforward in a debuuger. Rename it, and improve the type while at it. Signed-off-by: Fam Zheng ---

[Qemu-devel] colo doc problem

hi http://git.qemu-project.org/?p=qemu.gita=blobf=docs/COLO-FT.txth=e289be2f419578645475b36861e4303ff624cb0fhb=HEAD docs/COLO-FT 138 {'execute':'qmp_capabilities'} 139 { 'execute': 'nbd-server-start', 140 'arguments': {'addr': {'type': 'inet', 'data': {'host': 'xx.xx.xx.xx',

Re: [Qemu-devel] [PATCH for-2.10 6/8] ppc/pnv: Add cut down PSI bridge model and hookup external interrupt

On Thu, Mar 16, 2017 at 02:52:17PM +0100, Cédric Le Goater wrote: > On 03/15/2017 07:16 AM, David Gibson wrote: > > On Wed, Mar 08, 2017 at 11:52:49AM +0100, Cédric Le Goater wrote: > >> From: Benjamin Herrenschmidt > >> > >> The PSI (Processor Service Interface)

[Qemu-devel] [PATCH for-2.9] block: Propagate error in bdrv_open_backing_file

Signed-off-by: Fam Zheng --- block.c | 1 + 1 file changed, 1 insertion(+) diff --git a/block.c b/block.c index cb57370..6621167 100644 --- a/block.c +++ b/block.c @@ -2025,6 +2025,7 @@ int bdrv_open_backing_file(BlockDriverState *bs, QDict *parent_options,

Re: [Qemu-devel] [PATCH kernel v8 4/4] virtio-balloon: VIRTIO_BALLOON_F_HOST_REQ_VQ

On Thu, Mar 16, 2017 at 03:08:47PM +0800, Wei Wang wrote: > From: Liang Li > > Add a new vq, host request vq. The host uses the vq to send > requests to the guest. Upon getting a request, the guest responds > what the host needs via this vq. > > The patch implements the

Re: [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers

On Thu, 03/16 16:48, Ed Swierk wrote: > On Tue, Mar 14, 2017 at 8:36 AM, Fam Zheng wrote: > > diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c > > index e7466d3..4939f1f 100644 > > --- a/hw/scsi/virtio-scsi.c > > +++ b/hw/scsi/virtio-scsi.c > > ... > > bool

Re: [Qemu-devel] [PATCH kernel v8 3/4] mm: add inerface to offer info about unused pages

On Thu, Mar 16, 2017 at 03:08:46PM +0800, Wei Wang wrote: > +/* > + * The record_unused_pages() function is used to record the system unused > + * pages. The unused pages can be skipped to transfer during live migration. > + * Though the unused pages are dynamically changing, dirty page logging >

Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs"

On Mon, Mar 13, 2017 at 2:57 AM, Daniel P. Berrange wrote: > On Tue, Mar 07, 2017 at 05:27:55PM -0800, ashish mittal wrote: >> Thanks! There is one more input I need some help with! >> >> VxHS network library opens a fixed number of connection channels to a >> given host, and

Re: [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers

On Tue, Mar 14, 2017 at 8:36 AM, Fam Zheng wrote: > After the AioContext lock push down, there is a race between > virtio_scsi_dataplane_start and those "assert(s->ctx && > s->dataplane_started)", because the latter doesn't isn't wrapped in > aio_context_acquire. > > Reproducer

Re: [Qemu-devel] [PATCH v2 2/2] virtio-scsi: Fix acquire/release in dataplane handlers

On Tue, Mar 14, 2017 at 8:36 AM, Fam Zheng wrote: > diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c > index e7466d3..4939f1f 100644 > --- a/hw/scsi/virtio-scsi.c > +++ b/hw/scsi/virtio-scsi.c > ... > bool virtio_scsi_handle_event_vq(VirtIOSCSI *s, VirtQueue *vq) > {

Re: [Qemu-devel] [PATCH 08/31] ram: Move iterations_prev into RAMState

On 03/16/2017 09:26 AM, Dr. David Alan Gilbert wrote: * Juan Quintela (quint...@redhat.com) wrote: Signed-off-by: Juan Quintela --- migration/ram.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/migration/ram.c b/migration/ram.c index

Re: [Qemu-devel] [PATCH 14/31] ram: Move iterations into RAMState

On 03/16/2017 05:04 PM, Dr. David Alan Gilbert wrote: * Juan Quintela (quint...@redhat.com) wrote: Signed-off-by: Juan Quintela --- migration/ram.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) Reviewed-by: Dr. David Alan Gilbert

Re: [Qemu-devel] [PATCH 05/31] ram: Move bytes_xfer_prev into RAMState

On 03/16/2017 09:22 AM, Dr. David Alan Gilbert wrote: * Juan Quintela (quint...@redhat.com) wrote: Signed-off-by: Juan Quintela Reviewed-by: Dr. David Alan Gilbert Reviewed-by: Philippe Mathieu-Daudé --- migration/ram.c | 13

Re: [Qemu-devel] [PATCH 07/31] ram: Move xbzrle_cache_miss_prev into RAMState

On 03/16/2017 09:24 AM, Dr. David Alan Gilbert wrote: * Juan Quintela (quint...@redhat.com) wrote: Signed-off-by: Juan Quintela --- migration/ram.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/migration/ram.c b/migration/ram.c index

Re: [Qemu-devel] [PATCH 04/31] ram: Move start time into RAMState

On 03/16/2017 09:21 AM, Dr. David Alan Gilbert wrote: * Juan Quintela (quint...@redhat.com) wrote: Signed-off-by: Juan Quintela Reviewed-by: Dr. David Alan Gilbert Reviewed-by: Philippe Mathieu-Daudé --- migration/ram.c | 20

Re: [Qemu-devel] [PATCH 06/31] ram: Move num_dirty_pages_period into RAMState

On 03/16/2017 09:23 AM, Dr. David Alan Gilbert wrote: * Juan Quintela (quint...@redhat.com) wrote: Signed-off-by: Juan Quintela Reviewed-by: Dr. David Alan Gilbert Reviewed-by: Philippe Mathieu-Daudé (This series could be

Re: [Qemu-devel] [PATCH 02/31] ram: Add dirty_rate_high_cnt to RAMState

On 03/16/2017 09:20 AM, Dr. David Alan Gilbert wrote: * Juan Quintela (quint...@redhat.com) wrote: We need to add a parameter to several functions to make this work. Signed-off-by: Juan Quintela --- migration/ram.c | 23 --- 1 file changed, 12

Re: [Qemu-devel] [PATCH 03/31] ram: move bitmap_sync_count into RAMState

On 03/16/2017 09:21 AM, Dr. David Alan Gilbert wrote: * Juan Quintela (quint...@redhat.com) wrote: Signed-off-by: Juan Quintela Reviewed-by: Dr. David Alan Gilbert Reviewed-by: Philippe Mathieu-Daudé --- migration/ram.c | 22

Re: [Qemu-devel] [PATCH 01/31] ram: move more fields into RAMState

On 03/16/2017 09:09 AM, Dr. David Alan Gilbert wrote: * Juan Quintela (quint...@redhat.com) wrote: last_seen_block, last_sent_block, last_offset, last_version and ram_bulk_stage are globals that are really related together. Signed-off-by: Juan Quintela ---

Re: [Qemu-devel] [PATCH v2 0/3] block: pause block jobs for bdrv_drain_begin/end

Hi, This series seems to have some coding style problems. See output below for more information: Type: series Subject: [Qemu-devel] [PATCH v2 0/3] block: pause block jobs for bdrv_drain_begin/end Message-id: 20170316212351.13797-1-js...@redhat.com === TEST SCRIPT BEGIN === #!/bin/bash

Re: [Qemu-devel] [PATCH kernel v8 3/4] mm: add inerface to offer info about unused pages

On Thu, 16 Mar 2017 15:08:46 +0800 Wei Wang wrote: > From: Liang Li > > This patch adds a function to provides a snapshot of the present system > unused pages. An important usage of this function is to provide the > unsused pages to the Live

[Qemu-devel] [PATCH v2 0/3] block: pause block jobs for bdrv_drain_begin/end

Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1367369#c8 It's possible to wedge QEMU if the guest tries to reset a virtio-pci device as QEMU is also using the drive for a blockjob. This patchset aims to allow us to safely pause/resume jobs attached to individual nodes in a manner similar

[Qemu-devel] [PATCH v2 2/3] block-backend: add drained_begin / drained_end ops

Allow block backends to forward drain requests to their devices/users. The initial intended purpose for this patch is to allow BBs to forward requests along to BlockJobs, which will want to pause if their associated BB has entered a drained region. Signed-off-by: John Snow ---

[Qemu-devel] [PATCH v2 3/3] blockjob: add devops to blockjob backends

This lets us hook into drained_begin and drained_end requests from the backend level, which is particularly useful for making sure that all jobs associated with a particular node (whether the source or the target) receive a drain request. Suggested-by: Kevin Wolf Signed-off-by:

[Qemu-devel] [PATCH v2 1/3] blockjob: add block_job_start_shim

The purpose of this shim is to allow us to pause pre-started jobs. The purpose of *that* is to allow us to buffer a pause request that will be able to take effect before the job ever does any work, allowing us to create jobs during a quiescent state (under which they will be automatically paused),

Re: [Qemu-devel] [Qemu-stable] [PATCH for-2.9] thread-pool: add missing qemu_bh_cancel in completion function

> Am 16.03.2017 um 17:18 schrieb Paolo Bonzini : > > > > On 16/03/2017 17:02, Peter Lieven wrote: >> commit 3c80ca15 fixed a deadlock scenarion with nested aio_poll invocations. >> >> However, the rescheduling of the completion BH introcuded unnecessary >> spinning >> in

Re: [Qemu-devel] [PATCH 22/31] ram: move migration_bitmap_mutex into RAMState

* Juan Quintela (quint...@redhat.com) wrote: > Signed-off-by: Juan Quintela > --- > migration/ram.c | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/migration/ram.c b/migration/ram.c > index 7f56b5f..c14293c 100644 > ---

Re: [Qemu-devel] [PATCH 2/2] configure: use pkg-config for obtaining xen version

On Thu, 16 Mar 2017, Juergen Gross wrote: > Instead of trying to guess the Xen version to use by compiling various > test programs first just ask the system via pkg-config. Only if it > can't return the version fall back to the test program scheme. That's OK, but why did you remove the Xen

Re: [Qemu-devel] [PATCH 1/2] xen: use 5 digit xen versions

On Thu, 16 Mar 2017, Juergen Gross wrote: > Today qemu is using e.g. the value 480 for Xen version 4.8.0. As some > Xen version tests are using ">" relations this scheme will lead to > problems when Xen version 4.10.0 is being reached. > > Instead of the 3 digit schem use a 5 digit scheme (e.g.

Re: [Qemu-devel] [PATCH 21/31] ram: Everything was init to zero, so use memset

* Juan Quintela (quint...@redhat.com) wrote: > And then init only things that are not zero by default. > > Signed-off-by: Juan Quintela Reviewed-by: Dr. David Alan Gilbert > --- > migration/ram.c | 25 +++-- > 1 file changed, 3

Re: [Qemu-devel] [PATCH 19/31] ram: move xbzrle_overflows into RAMState

* Juan Quintela (quint...@redhat.com) wrote: > Once there, remove the now unused AccountingInfo struct and var. > > Signed-off-by: Juan Quintela > --- > migration/ram.c | 21 + > 1 file changed, 5 insertions(+), 16 deletions(-) > > diff --git

[Qemu-devel] [PATCH v3 9/9] xen/9pfs: build and register Xen 9pfs backend

Signed-off-by: Stefano Stabellini Reviewed-by: Greg Kurz CC: anthony.per...@citrix.com CC: jgr...@suse.com CC: Aneesh Kumar K.V CC: Greg Kurz --- hw/9pfs/Makefile.objs| 1 + hw/xen/xen_backend.c

[Qemu-devel] [PATCH v3 6/9] xen/9pfs: receive requests from the frontend

Upon receiving an event channel notification from the frontend, schedule the bottom half. From the bottom half, read one request from the ring, create a pdu and call pdu_submit to handle it. For now, only handle one request per ring at a time. Signed-off-by: Stefano Stabellini

[Qemu-devel] [PATCH v3 7/9] xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshal

Implement xen_9pfs_init_in/out_iov_from_pdu and xen_9pfs_pdu_vmarshal/vunmarshall by creating new sg pointing to the data on the ring. This is safe as we only handle one request per ring at any given time. Signed-off-by: Stefano Stabellini CC: anthony.per...@citrix.com CC:

Re: [Qemu-devel] [PATCH v1 2/2] reduce qemu's heap Rss size from 12252kB to 2752KB

> > memory_region_finalize. > > Let me know if you think otherwise. > > Yes, you can replace memory_region_del_subregion in > memory_region_finalize > with special code that does > > assert(!mr->enabled); > assert(subregion->container == mr); > subregion->container = NULL; >

[Qemu-devel] [PATCH v3 1/9] xen: do not build backends for targets that do not support xen

Change Makefile.objs to use CONFIG_XEN instead of CONFIG_XEN_BACKEND, so that the Xen backends are only built for targets that support Xen. Set CONFIG_XEN in the toplevel Makefile to ensure that files that are built only once pick up Xen support properly. Signed-off-by: Stefano Stabellini

Re: [Qemu-devel] [PATCH 14/31] ram: Move iterations into RAMState

* Juan Quintela (quint...@redhat.com) wrote: > Signed-off-by: Juan Quintela > --- > migration/ram.c | 12 +++- > 1 file changed, 7 insertions(+), 5 deletions(-) Reviewed-by: Dr. David Alan Gilbert > > diff --git a/migration/ram.c

[Qemu-devel] [PATCH v3 8/9] xen/9pfs: send responses back to the frontend

Once a request is completed, xen_9pfs_push_and_notify gets called. In xen_9pfs_push_and_notify, update the indexes (data has already been copied to the sg by the common code) and send a notification to the frontend. Schedule the bottom-half to check if we already have any other requests pending.

[Qemu-devel] [PATCH v3 5/9] xen/9pfs: connect to the frontend

Write the limits of the backend to xenstore. Connect to the frontend. Upon connection, allocate the rings according to the protocol specification. Initialize a QEMUBH to schedule work upon receiving an event channel notification from the frontend. Signed-off-by: Stefano Stabellini

[Qemu-devel] [PATCH v3 2/9] xen: import ring.h from xen

Do not use the ring.h header installed on the system. Instead, import the header into the QEMU codebase. This avoids problems when QEMU is built against a Xen version too old to provide all the ring macros. Signed-off-by: Stefano Stabellini CC: anthony.per...@citrix.com CC:

[Qemu-devel] [PATCH v3 3/9] 9p: introduce a type for the 9p header

Use the new type in virtio-9p-device. Signed-off-by: Stefano Stabellini CC: anthony.per...@citrix.com CC: jgr...@suse.com CC: Aneesh Kumar K.V CC: Greg Kurz --- hw/9pfs/9p.h | 6 ++

[Qemu-devel] [PATCH v3 4/9] xen/9pfs: introduce Xen 9pfs backend

Introduce the Xen 9pfs backend: add struct XenDevOps to register as a Xen backend and add struct V9fsTransport to register as v9fs transport. All functions are empty stubs for now. Signed-off-by: Stefano Stabellini Reviewed-by: Greg Kurz CC:

[Qemu-devel] [PATCH v3 0/9] xen/9pfs: introduce the Xen 9pfs backend

Hi all, This patch series implements a new transport for 9pfs, aimed at Xen systems. The transport is based on a traditional Xen frontend and backend drivers pair. This patch series implements the backend, which typically runs in Dom0. I sent another series to implement the frontend in Linux

Re: [Qemu-devel] [RFC patch 2/3] block-backend: add drained_begin / drained_end ops

On 03/16/2017 01:25 PM, Kevin Wolf wrote: > Am 16.03.2017 um 01:46 hat John Snow geschrieben: >> Signed-off-by: John Snow >> >> --- >> >> RFC questions: >> >> - Does the presence of blk->quiesce_counter relieve the burden of needing >> blk->public.io_limits_disabled? I could

Re: [Qemu-devel] Make qemu_thread_create return a flag to indicate if it succeeded

* Alex Bennée (alex.ben...@linaro.org) wrote: > > Achilles Benetopoulos writes: > > > I am interested in working on the BiteSized Task mentioned in the > > subject line. However, I have a question: Since the current behaviour > > of qemu_thread_create is to fail in the

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

* Peter Maydell (peter.mayd...@linaro.org) wrote: > On 16 March 2017 at 15:46, Daniel P. Berrange wrote: > > On Thu, Mar 16, 2017 at 03:23:45PM +, Peter Maydell wrote: > >> OK, here's a concrete proposal for deprecating/dropping out of > >> date host OS and architecture

Re: [Qemu-devel] [PULL 11/24] tcg: enable thread-per-vCPU

Le 16/03/2017 à 18:31, Alex Bennée a écrit : > > Laurent Vivier writes: > >> Le 27/02/2017 à 15:38, Alex Bennée a écrit : >>> >>> Laurent Vivier writes: >>> Le 24/02/2017 à 12:20, Alex Bennée a écrit : > There are a couple of changes that occur at

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

On Thu, Mar 16, 2017 at 06:01:35PM +, Peter Maydell wrote: > On 16 March 2017 at 15:23, Peter Maydell wrote: > > (Technically right this instant 'mips' and 's390' would be in the > > 'dump' list, since I don't personally have access yet. But we have > > a plan for

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

On 16 March 2017 at 15:23, Peter Maydell wrote: > (Technically right this instant 'mips' and 's390' would be in the > 'dump' list, since I don't personally have access yet. But we have > a plan for s390, and it turns out there is a mips machine in the > gcc compile farm

Re: [Qemu-devel] [PULL for-2.9 0/7] cirrus: more blitter security fixes.

wing changes since commit 1883ff34b540daacae948f493b0ba525edf5f642: > > Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging > (2017-03-15 18:44:05 +) > > are available in the git repository at: > > > git://git.kraxel.org/qemu tags/pull-cirrus-20170316-1

Re: [Qemu-devel] [RFC patch 3/3] blockjob: add devops to blockjob backends

Am 16.03.2017 um 01:46 hat John Snow geschrieben: > This lets us hook into drained_begin and drained_end requests from the > backend level, which is particularly useful for making sure that all > jobs associated with a particular node (whether the source or the target) > receive a drain request. >

Re: [Qemu-devel] [PULL 11/24] tcg: enable thread-per-vCPU

Laurent Vivier writes: > Le 27/02/2017 à 15:38, Alex Bennée a écrit : >> >> Laurent Vivier writes: >> >>> Le 24/02/2017 à 12:20, Alex Bennée a écrit : There are a couple of changes that occur at the same time here: - introduce a single

Re: [Qemu-devel] [RFC patch 2/3] block-backend: add drained_begin / drained_end ops

Am 16.03.2017 um 01:46 hat John Snow geschrieben: > Signed-off-by: John Snow > > --- > > RFC questions: > > - Does the presence of blk->quiesce_counter relieve the burden of needing > blk->public.io_limits_disabled? I could probably eliminate this counter > entirely and

Re: [Qemu-devel] Benchmarking linux-user performance

On Tue, Mar 14, 2017 at 17:06:57 +, Dr. David Alan Gilbert wrote: > * Emilio G. Cota (c...@braap.org) wrote: > > It seems that a good benchmark to take translation overhead into account > > would be gcc/perlbench from SPEC (see [1]; ~20% of exec time is spent > > on translation).

Re: [Qemu-devel] Make qemu_thread_create return a flag to indicate if it succeeded

On Thu, Mar 16, 2017 at 06:55:47PM +0200, Achilles Benetopoulos wrote: > I am interested in working on the BiteSized Task mentioned in the > subject line. However, I have a question: Since the current behaviour > of qemu_thread_create is to fail in the case of an error, then it > seems logical to

Re: [Qemu-devel] Make qemu_thread_create return a flag to indicate if it succeeded

Achilles Benetopoulos writes: > I am interested in working on the BiteSized Task mentioned in the > subject line. However, I have a question: Since the current behaviour > of qemu_thread_create is to fail in the case of an error, then it > seems logical to make the

Re: [Qemu-devel] [PATCH v2] qemu-ga: obey LISTEN_PID when using systemd socket activation

On Thu, Mar 16, 2017 at 05:36:40PM +0100, Paolo Bonzini wrote: > qemu-ga's socket activation support was not obeying the LISTEN_PID > environment variable, which avoids that a process uses a socket-activation > file descriptor meant for its parent. > > Mess can for example ensue if a process

Re: [Qemu-devel] [PATCH] qemu-ga: obey LISTEN_PID when using systemd socket activation

On Thu, Mar 16, 2017 at 05:15:35PM +0100, Paolo Bonzini wrote: > qemu-ga's socket activation support was not obeying the LISTEN_PID > environment variable, which avoids that a process uses a socket-activation > file descriptor meant for its parent. > > Mess can for example ensue if a process

Re: [Qemu-devel] [PATCH] qemu-ga: obey LISTEN_PID when using systemd socket activation

On Thu, Mar 16, 2017 at 05:34:30PM +0100, Paolo Bonzini wrote: > > > On 16/03/2017 17:19, Daniel P. Berrange wrote: > > On Thu, Mar 16, 2017 at 05:15:35PM +0100, Paolo Bonzini wrote: > >> qemu-ga's socket activation support was not obeying the LISTEN_PID > >> environment variable, which avoids

Re: [Qemu-devel] [Qemu-ppc] qemu-system-ppc video artifacts since "tcg: drop global lock during TCG code execution"

On 16/03/2017 16:34, Gerd Hoffmann wrote: > Well, not *that* simple. vga checks the dirty bitmap with scanline > granularity, like that: > > foreach (scanline) { > if (get_dirty(scanline)) > update_scanline() > } > reset_dirty(framebuffer) > > I suspect simply transforming

[Qemu-devel] Make qemu_thread_create return a flag to indicate if it succeeded

I am interested in working on the BiteSized Task mentioned in the subject line. However, I have a question: Since the current behaviour of qemu_thread_create is to fail in the case of an error, then it seems logical to make the caller exit (in the patched version) if the return value of the call

Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

On 16/03/2017 16:55, Peter Maydell wrote: >> IOW, I think there is a reasonable 3 tier set here >> >> 1. Stuff we actively test builds & thus guarantee will work for >> any QEMU release going forward. >> >> 2. Stuff we don't actively test, but generally assume is mostly >> working, and

Re: [Qemu-devel] [PULL 0/6] Migration fixes

ags/for_upstream' into staging > (2017-03-15 18:44:05 +) > > are available in the git repository at: > > git://github.com/juanquintela/qemu.git tags/migration/20170316 > > for you to fetch changes up to 8679638b0e231f97ad3456c681bf569ca7f7f6d

[Qemu-devel] [PATCH v2] qemu-ga: obey LISTEN_PID when using systemd socket activation

qemu-ga's socket activation support was not obeying the LISTEN_PID environment variable, which avoids that a process uses a socket-activation file descriptor meant for its parent. Mess can for example ensue if a process forks a children before consuming the socket-activation file descriptor and

Re: [Qemu-devel] [PATCH] qemu-ga: obey LISTEN_PID when using systemd socket activation

On 16/03/2017 17:19, Daniel P. Berrange wrote: > On Thu, Mar 16, 2017 at 05:15:35PM +0100, Paolo Bonzini wrote: >> qemu-ga's socket activation support was not obeying the LISTEN_PID >> environment variable, which avoids that a process uses a socket-activation >> file descriptor meant for its

[Qemu-devel] [PATCH] 9pfs: don't try to flush self and avoid QEMU hang on reset

According to the 9P spec [*], when a client wants to cancel a pending I/O request identified by a given tag (uint16), it must send a Tflush message and wait for the server to respond with a Rflush message before reusing this tag for another I/O. The server may still send a completion message for

  1   2   3   4   >