Re: [Qemu-devel] [PATCH v5 00/18] IOMMU: Enable interrupt remapping for Intel IOMMU

On 2016-05-03 07:30, Peter Xu wrote: > On Tue, May 03, 2016 at 06:38:28AM +0200, Jan Kiszka wrote: >> On 2016-05-03 05:22, Peter Xu wrote: >>> On Fri, Apr 29, 2016 at 09:52:14PM +0200, Radim Krčmář wrote: 2016-04-28 17:18+0800, Peter Xu: > On Thu, Apr 28, 2016 at 09:19:28AM +0200, Jan

Re: [Qemu-devel] [PATCH v5 00/18] IOMMU: Enable interrupt remapping for Intel IOMMU

On Tue, May 03, 2016 at 06:38:28AM +0200, Jan Kiszka wrote: > On 2016-05-03 05:22, Peter Xu wrote: > > On Fri, Apr 29, 2016 at 09:52:14PM +0200, Radim Krčmář wrote: > >> 2016-04-28 17:18+0800, Peter Xu: > >>> On Thu, Apr 28, 2016 at 09:19:28AM +0200, Jan Kiszka wrote: > Instead of fiddling

Re: [Qemu-devel] [PATCH v5 00/18] IOMMU: Enable interrupt remapping for Intel IOMMU

On 2016-05-03 05:22, Peter Xu wrote: > On Fri, Apr 29, 2016 at 09:52:14PM +0200, Radim Krčmář wrote: >> 2016-04-28 17:18+0800, Peter Xu: >>> On Thu, Apr 28, 2016 at 09:19:28AM +0200, Jan Kiszka wrote: Instead of fiddling with irq routes for the IOAPIC - where we don't need it -, I would

Re: [Qemu-devel] [PATCH v5 00/18] IOMMU: Enable interrupt remapping for Intel IOMMU

On Fri, Apr 29, 2016 at 09:52:14PM +0200, Radim Krčmář wrote: > 2016-04-28 17:18+0800, Peter Xu: > > On Thu, Apr 28, 2016 at 09:19:28AM +0200, Jan Kiszka wrote: > >> Instead of fiddling with irq routes for the IOAPIC - where we don't need > >> it -, I would suggest to do the following: Send IOAPIC

[Qemu-devel] [PATCH 2/2] Remove unnecessary CONFIG_EVENTFD preprocessor conditional to satisfy link

The file ivshmem.c unconditionally references event_notifier_init_fd() in util/event_notifier-posix.c, even if CONFIG_EVENTFD is not defined. On platforms where CONFIG_POSIX is defined, but CONFIG_EVENTFD is not defined, that results in an undefined symbol referenced from ivshmem.c and the

[Qemu-devel] [PATCH 1/2] Use libtool instead of ar to create static libraries on Darwin.

Currently, at least on Mac OS X 10.11.4 (El Capitan), Qemu fails to build for a few reasons. One of those reasons is that Apple's ld (at least ld64) does not properly process archive files created with ar (even Apple's ar). After some RTFM'ing, I came upon this tidbit, which is unfortunate.

Re: [Qemu-devel] [PATCH 2/2] Remove unnecessary CONFIG_EVENTFD preprocessor conditional to satisfy link

On 3 May 2016 at 02:25, Christopher Friedt wrote: > Ack - too late! I manually removed all of the *-softmmu/ directories > after doing a make clean, because they were still hanging around. > Rebuilding worked fine without PATCH 2/2. Oh well. If blowing away the build dirs

Re: [Qemu-devel] [PATCH 2/2] Remove unnecessary CONFIG_EVENTFD preprocessor conditional to satisfy link

On Mon, May 2, 2016 at 9:18 PM, Peter Maydell wrote: > On 3 May 2016 at 02:14, Christopher Friedt wrote: >> On Mon, May 2, 2016 at 9:01 PM, Peter Maydell >> wrote: >>> [ccing somebody else who ran into this, since I've

[Qemu-devel] [PATCH 0/2] Resolve link errors on Mac OS X

Hi list, I recently tried to build Qemu on Mac and ran into a couple of trivial issues that I've provided patches for. I suppose that normally people just use 'brew install qemu', but there is really no reason that it can't be built from source, particularly for those modifying Qemu regularly.

Re: [Qemu-devel] [PATCH 2/2] Remove unnecessary CONFIG_EVENTFD preprocessor conditional to satisfy link

On 3 May 2016 at 02:14, Christopher Friedt wrote: > On Mon, May 2, 2016 at 9:01 PM, Peter Maydell > wrote: >> [ccing somebody else who ran into this, since I've figured out why.] >> >> On 3 May 2016 at 01:47, Christopher Friedt

Re: [Qemu-devel] [PATCH 2/2] Remove unnecessary CONFIG_EVENTFD preprocessor conditional to satisfy link

On Mon, May 2, 2016 at 9:01 PM, Peter Maydell wrote: > [ccing somebody else who ran into this, since I've figured out why.] > > On 3 May 2016 at 01:47, Christopher Friedt wrote: >> The file ivshmem.c unconditionally references

[Qemu-devel] [PATCH 1/2v2] [RESENT-INLINE] Use libtool instead of ar to create static libraries on Darwin.

Currently, at least on Mac OS X 10.11.4 (El Capitan), Qemu fails to build for a few reasons. One of those reasons is that Apple's ld (at least ld64) does not properly process archive files created with ar (even Apple's ar). After some RTFM'ing, I came upon this tidbit, which is unfortunate.

Re: [Qemu-devel] [PATCH 1/2] Use libtool instead of ar to create static libraries on Darwin.

On Mon, May 2, 2016 at 9:04 PM, Fam Zheng wrote: > Cc'ing Peter Maydell, who must have better ideas than me on building on Mac. > > On Mon, 05/02 20:47, Christopher Friedt wrote: >> >> Currently, at least on Mac OS X 10.11.4 (El Capitan), Qemu fails to build >> for a few

Re: [Qemu-devel] [PATCH 1/2] Use libtool instead of ar to create static libraries on Darwin.

On Mon, May 2, 2016 at 8:53 PM, Peter Maydell wrote: > On 3 May 2016 at 01:47, Christopher Friedt wrote: >> >> Currently, at least on Mac OS X 10.11.4 (El Capitan), Qemu fails >> to build for a few reasons. > > I guess this is a new-in-ElCapitan

Re: [Qemu-devel] [PATCH 1/2] Use libtool instead of ar to create static libraries on Darwin.

Cc'ing Peter Maydell, who must have better ideas than me on building on Mac. On Mon, 05/02 20:47, Christopher Friedt wrote: > > Currently, at least on Mac OS X 10.11.4 (El Capitan), Qemu fails to build for > a few reasons. > > One of those reasons is that Apple's ld (at least ld64) does not

Re: [Qemu-devel] [PATCH 2/2] Remove unnecessary CONFIG_EVENTFD preprocessor conditional to satisfy link

[ccing somebody else who ran into this, since I've figured out why.] On 3 May 2016 at 01:47, Christopher Friedt wrote: > The file ivshmem.c unconditionally references event_notifier_init_fd() > in util/event_notifier-posix.c, even if CONFIG_EVENTFD is not defined. Yes,

[Qemu-devel] [PATCH 1/2] [RESENT-INLINE] Use libtool instead of ar to create static libraries on Darwin.

Currently, at least on Mac OS X 10.11.4 (El Capitan), Qemu fails to build for a few reasons. One of those reasons is that Apple's ld (at least ld64) does not properly process archive files created with ar (even Apple's ar). After some RTFM'ing, I came upon this tidbit, which is unfortunate.

[Qemu-devel] [PATCH 2/2] [RESENT-INLINE] Remove unnecessary CONFIG_EVENTFD preprocessor conditional to satisfy link

The file ivshmem.c unconditionally references event_notifier_init_fd() in util/event_notifier-posix.c, even if CONFIG_EVENTFD is not defined. On platforms where CONFIG_POSIX is defined, but CONFIG_EVENTFD is not defined, that results in an undefined symbol referenced from ivshmem.c and the link

[Qemu-devel] [PATCH 0/2][RESENT-INLINE] Resolve link errors on Mac OS X

Hi list, I recently tried to build Qemu on Mac and ran into a couple of trivial issues that I've provided patches for. I suppose that normally people just use 'brew install qemu', but there is really no reason that it can't be built from source, particularly for those modifying Qemu regularly.

Re: [Qemu-devel] [PATCH] exec.c: Ensure right alignment also for file backed ram

On Fri, 04/29 10:26, Dominik Dingel wrote: > On Fri, 29 Apr 2016 15:32:22 +0800 > Fam Zheng wrote: > > > On Mon, 04/25 13:55, Dominik Dingel wrote: > > > While in the anonymous ram case we already take care of the right > > > alignment > > > such an alignment gurantee does not

Re: [Qemu-devel] [PATCH 1/2] Use libtool instead of ar to create static libraries on Darwin.

On 3 May 2016 at 01:47, Christopher Friedt wrote: > > Currently, at least on Mac OS X 10.11.4 (El Capitan), Qemu fails > to build for a few reasons. I guess this is a new-in-ElCapitan thing? I run Yosemite, which is fine. thanks -- PMM

Re: [Qemu-devel] [PATCH] Allow users to specify the vmdk virtual hardware version.

On Mon, 05/02 04:30, Janne Karhunen wrote: > >> if (qemu_opt_get_bool_del(opts, BLOCK_OPT_COMPAT6, false)) { > >> -flags |= BLOCK_FLAG_COMPAT6; > > > > Please remove BLOCK_FLAG_COMPAT6 from include/block/block_int.h| as well. > > Wasn't it removed? > > -#define BLOCK_FLAG_COMPAT6

Re: [Qemu-devel] [PATCH] bcm2835_property: use cached values when querying framebuffer

On 2 May 2016 at 22:21, Sylvain Garrigues wrote: > Hello, > > Shall we commit this patch? Hi; this is on my list of patches to deal with, but QEMU is still in code freeze for the upcoming 2.6 release. When we reopen the tree after release it will go in shortly after that.

Re: [Qemu-devel] tcg: How 'CPUState::current_tb' is used?

On 2 May 2016 at 21:18, Sergey Fedorov wrote: > On 02/05/16 22:54, Sergey Fedorov wrote: > > Hi, > > I can't figure out how this field is used. The comment says it's "Currently > executing TB", but actually it's the first TB in a chain of TBs executed. > Grep shows the only

Re: [Qemu-devel] [PATCH] bcm2835_property: use cached values when querying framebuffer

Hello, Shall we commit this patch? Very best, Sylvain > Le 22 avr. 2016 à 14:42, Sylvain Garrigues a > écrit : > > As the framebuffer settings are copied into the result message before it is > reconfigured, inconsistent behavior can happen when, for instance,

Re: [Qemu-devel] [Bug 1547526] Re: Java program does not execute on SPARC Solaris 8

*** This bug is a duplicate of bug 1450881 *** https://bugs.launchpad.net/bugs/1450881 Oh nice! Thank you. -- Leandro Sehnem Heck On Mon, May 2, 2016 at 6:17 PM, Bastian Koppelmann < kbast...@mail.uni-paderborn.de> wrote: > *** This bug is a duplicate of bug 1450881 *** >

Re: [Qemu-devel] [PATCH v4 04/14] onenand: Switch to byte-based block access

On 05/02/2016 03:16 PM, Eric Blake wrote: >> First of all, why signed? More importantly, though, sec is an int. I'm >> not sure if we should cast it to uint64_t before shifting (I'm unsure >> because this device seems to supports only sizes that fit in a uint32_t >> anyway), but if we don't,

Re: [Qemu-devel] [Bug 1547526] Re: Java program does not execute on SPARC Solaris 8

On 05/02/2016 09:50 PM, Leandro Heck wrote: > *** This bug is a duplicate of bug 1450881 *** > https://bugs.launchpad.net/bugs/1450881 > > Hi Mark, do you know when qemu 2.6 will be released? > Hi Leandro, please take a look here: http://wiki.qemu.org/Planning/2.6 Cheers, Bastian

Re: [Qemu-devel] [PATCH v4 04/14] onenand: Switch to byte-based block access

On 05/02/2016 09:35 AM, Kevin Wolf wrote: > Am 29.04.2016 um 22:08 hat Eric Blake geschrieben: >> Sector-based blk_write() should die; switch to byte-based >> blk_pwrite() instead. Likewise for blk_read(). >> >> Signed-off-by: Eric Blake >> >> --- >> Not compile tested - I'm

Re: [Qemu-devel] [PATCH v4 03/14] nand: Switch to byte-based block access

On 05/02/2016 09:35 AM, Kevin Wolf wrote: > Am 29.04.2016 um 22:08 hat Eric Blake geschrieben: >> Sector-based blk_write() should die; switch to byte-based >> blk_pwrite() instead. Likewise for blk_read(). >> >> This file is doing some complex computations to map various >> flash page sizes (256,

Re: [Qemu-devel] tcg: How 'CPUState::current_tb' is used?

On 02/05/16 22:54, Sergey Fedorov wrote: > Hi, > > I can't figure out how this field is used. The comment says it's > "Currently executing TB", but actually it's the first TB in a chain of > TBs executed. Grep shows the only place it is really checked is > tb_invalidate_phys_page_range(). That

Re: [Qemu-devel] [Bug 1547526] Re: Java program does not execute on SPARC Solaris 8

*** This bug is a duplicate of bug 1450881 *** https://bugs.launchpad.net/bugs/1450881 Hi Mark, do you know when qemu 2.6 will be released? -- Leandro Sehnem Heck On Fri, Apr 15, 2016 at 4:49 AM, Mark Cave-Ayland < mark.cave-ayl...@ilande.co.uk> wrote: > *** This bug is a duplicate of bug

[Qemu-devel] tcg: How CPUState::current_tb is used?

Hi, I can't figure out how this field is used. The comment says it's "Currently executing TB", but actually it's the first TB in a chain of TBs executed. Grep shows the only place it is really checked is tb_invalidate_phys_page_range(). That code seems to be introduced long ago in: commit

Re: [Qemu-devel] [PATCH v3 18/18] qapi: Add parameter to visit_end_*

On 05/02/2016 12:20 PM, Markus Armbruster wrote: > Eric Blake writes: > >> Rather than making the dealloc visitor track of stack of pointers >> remembered during visit_start_* in order to free them during >> visit_end_*, it's a lot easier to just make all callers pass the >>

Re: [Qemu-devel] [PATCH v3 15/18] qapi: Add new clone visitor

On 05/02/2016 11:54 AM, Markus Armbruster wrote: > > qapi-types.h grows by 492 lines (19KiB, +19%). Roughly one non-blank > line per non-simple type, including list types. It's included all over > the place. > > qapi-types.c grows by 4212 lines (92KiB, +90%). > > Is it a good idea to

[Qemu-devel] [RFC PATCH v3 0/3] Add vGPU support

This series adds vGPU support to v4.6 Linux host kernel. Purpose of this series is to provide a common interface for vGPU management that can be used by different GPU drivers. This series introduces vGPU core module that create and manage vGPU devices, VFIO based driver for vGPU devices that are

[Qemu-devel] [RFC PATCH v3 2/3] VFIO driver for vGPU device

VFIO driver registers with vGPU core driver. vGPU core driver creates vGPU device and calls probe routine of vGPU VFIO driver. This vGPU VFIO driver adds vGPU device to VFIO core module. Main aim of this module is to manage all VFIO APIs for each vGPU device. Those are: - get region information

[Qemu-devel] [ANNOUNCE] QEMU 2.6.0-rc4 is now available

Hello, On behalf of the QEMU Team, I'd like to announce the availability of the fifth release candidate for the QEMU 2.6 release. This release is meant for testing purposes and should not be used in a production environment. http://wiki.qemu.org/download/qemu-2.6.0-rc4.tar.bz2 The final

[Qemu-devel] [RFC PATCH v3 1/3] vGPU Core driver

Design for vGPU Driver: Main purpose of vGPU driver is to provide a common interface for vGPU management that can be used by differnt GPU drivers. This module would provide a generic interface to create the device, add it to vGPU bus, add device to IOMMU group and then add it to vfio group. High

[Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu

VFIO Type1 IOMMU driver is designed for the devices which are IOMMU capable. vGPU device are only using IOMMU TYPE1 API, the underlying hardware can be managed by an IOMMU domain. To use most of the code of IOMMU driver for vGPU devices, type1 IOMMU driver is modified to support vGPU devices. This

Re: [Qemu-devel] [PATCH v3 18/18] qapi: Add parameter to visit_end_*

Eric Blake writes: > Rather than making the dealloc visitor track of stack of pointers > remembered during visit_start_* in order to free them during > visit_end_*, it's a lot easier to just make all callers pass the > same pointer to visit_end_*. The generated code has

[Qemu-devel] GTK+ interface doesn't translate keycodes properly with Wayland backend (Fwd: [Xen-users] xen_kbdfront: unhandled keycode 0x0)

Here's my original thread forwarded from the xen-users mailing list, but I think I've traced the problem to Qemu. I'm no expert, but it looks like GTK+ key events come in at the ui/gtk.c:gd_key_event callback function, which calls ui/gtk.c:gd_map_keycode to translate the GTK+ keycode into the

[Qemu-devel] [PATCH] rbd:change error_setg() to error_setg_errno()

>From 1c63c246f47a1a65d8740d7ce3725fe3820c0a37 Mon Sep 17 00:00:00 2001 From: Vikhyat Umrao Date: Mon, 2 May 2016 21:47:31 +0530 Subject: [PATCH] rbd:change error_setg() to error_setg_errno() Ceph RBD block driver does not use error_setg_errno() where it is possible to use.

Re: [Qemu-devel] [PATCH v3 15/18] qapi: Add new clone visitor

Eric Blake writes: > We have a couple places in the code base that want to deep-clone > one QAPI object into another, and they were resorting to serializing > the struct out to QObject then reparsing it. A much more efficient > version can be done by adding a new clone

Re: [Qemu-devel] [PATCH 11/18] vhost-user: add shutdown support

On Mon, May 02, 2016 at 03:04:30PM +0300, Michael S. Tsirkin wrote: > On Mon, May 02, 2016 at 01:29:18PM +0200, Marc-André Lureau wrote: > > Hi > > > > On Mon, May 2, 2016 at 12:45 PM, Michael S. Tsirkin wrote: > > > 1. Graceful disconnect > > > - One should be able to do

Re: [Qemu-devel] [PATCH v2] fixup! tcg/mips: Make direct jump patching thread-safe

On 05/02/2016 07:35 AM, Sergey Fedorov wrote: From: Sergey Fedorov Signed-off-by: Sergey Fedorov Signed-off-by: Sergey Fedorov --- This patch is based on a commit: e601ccb62016 ("cpu-exec: Move TB chaining into

Re: [Qemu-devel] [PATCH] fixup! tcg/mips: Make direct jump patching thread-safe

On 02/05/16 00:27, Sergey Fedorov wrote: > From: Sergey Fedorov > > Signed-off-by: Sergey Fedorov > Signed-off-by: Sergey Fedorov Please ignore this patch, the correct one is v2. Kind regards, Sergey > --- > >

[Qemu-devel] [PATCH v2] fixup! tcg/mips: Make direct jump patching thread-safe

From: Sergey Fedorov Signed-off-by: Sergey Fedorov Signed-off-by: Sergey Fedorov --- This patch is based on a commit: e601ccb62016 ("cpu-exec: Move TB chaining into tb_find_fast()") from:

Re: [Qemu-devel] [PATCH 11/18] vhost-user: add shutdown support

On Mon, May 02, 2016 at 01:45:31PM +0300, Michael S. Tsirkin wrote: > On Sun, May 01, 2016 at 02:04:42PM -0700, Yuanhan Liu wrote: > > On Sun, May 01, 2016 at 02:37:19PM +0300, Michael S. Tsirkin wrote: > > > On Fri, Apr 29, 2016 at 10:48:35AM -0700, Yuanhan Liu wrote: > > > > > But, I > > > > >

Re: [Qemu-devel] [PATCH] block: Don't lose FUA flag during ZERO_WRITE fallback

On 05/02/2016 09:42 AM, Eric Blake wrote: > On 05/02/2016 09:35 AM, Kevin Wolf wrote: >> Am 30.04.2016 um 23:48 hat Eric Blake geschrieben: >>> NBD has situations where it can support FUA but not ZERO_WRITE; >>> when that happens, the generic block layer fallback was losing >>> the FUA flag. The

Re: [Qemu-devel] [Nbd] Is NBD_CMD_FLAG_FUA valid during NBD_CMD_FLUSH?

On 03/31/2016 02:34 PM, Eric Blake wrote: > On 03/31/2016 02:17 PM, Alex Bligh wrote: >> OK so I actually went and researched what my answer was last time I >> was asked ( :-) ): >> >> Here was my conclusion last time after trawling through lkml >> on the subject: >> >> From

Re: [Qemu-devel] [BUG 2.6] Broken CONFIG_TPM?

On 29 April 2016 at 08:42, Markus Armbruster wrote: > Stefan Weil writes: > >> A compilation test with clang -Weverything reported this problem: >> >> config-host.h:112:20: warning: '$' in identifier >> [-Wdollar-in-identifier-extension] >> >> The line

Re: [Qemu-devel] [PATCH] Revert "acpi: mark PMTIMER as unlocked"

On 2 May 2016 at 13:32, Gerd Hoffmann wrote: > On Fr, 2016-04-15 at 12:10 +0200, Paolo Bonzini wrote: >> >> On 15/04/2016 08:43, Gerd Hoffmann wrote: >> > This reverts commit 7070e085d490c396f9237c8f10bf8b6e69cd0066. >> > >> > Commit message claims locking is not needed, but

Re: [Qemu-devel] [PATCH v2] migration: Promote improved autoconverge commands out of experimental state

On 04/21/2016 02:07 PM, Jason J. Herne wrote: The new autoconverge throttling commands have been tested for a release now. It is time to move them out of the experimental state. ping. Signed-off-by: Jason J. Herne --- hmp.c | 28

[Qemu-devel] [RFC 38/42] tests: acpi: add CPU hotplug testcase

Test with "-smp 2,cores=3,sockets=2,maxcpus=6" to capture sparse APIC ID values that default AMD CPU has in above configuration. Signed-off-by: Igor Mammedov --- tests/bios-tables-test.c | 28 1 file changed, 28 insertions(+) diff --git

Re: [Qemu-devel] [PATCH 03/19] block: Respect backing bs in bdrv_refresh_filename

Am 26.04.2016 um 23:32 hat Max Reitz geschrieben: > Basically, bdrv_refresh_filename() should respect all children of a > BlockDriverState. However, generally those children are driver-specific, > so this function cannot handle the general case. On the other hand, > there are only few drivers

Re: [Qemu-devel] [PATCH 06/19] block: Make bdrv_default_refresh_format_filename public

Am 26.04.2016 um 23:32 hat Max Reitz geschrieben: > In order to allow block drivers to use that function, it needs to be > public. In order to be useful, it needs to take a parameter which allows > the caller to specify whether the runtime options allowed by the block > driver are actually

Re: [Qemu-devel] [PATCH 16/19] block/nbd: Implement bdrv_dirname()

Am 26.04.2016 um 23:32 hat Max Reitz geschrieben: > The idea behind this implementation is that the export name might be > interpreted as a path (which is the only apparent interpretation of > relative filenames for NBD paths). > > The default implementation of bdrv_dirname() would handle that

Re: [Qemu-devel] [Qemu-discuss] iolimits for virtio-9p

On 2 May 2016 at 14:57, Greg Kurz wrote: > On Thu, 28 Apr 2016 11:45:41 +0200 > Pradeep Kiruvale wrote: > > > On 27 April 2016 at 19:12, Greg Kurz wrote: > > > > > On Wed, 27 Apr 2016 16:39:58 +0200 > > > Pradeep

Re: [Qemu-devel] [PATCH] block: Don't lose FUA flag during ZERO_WRITE fallback

On 05/02/2016 09:35 AM, Kevin Wolf wrote: > Am 30.04.2016 um 23:48 hat Eric Blake geschrieben: >> NBD has situations where it can support FUA but not ZERO_WRITE; >> when that happens, the generic block layer fallback was losing >> the FUA flag. The problem of losing flags unrelated to >>

Re: [Qemu-devel] [PATCH 02/19] block: Add BDS.backing_overridden

Am 26.04.2016 um 23:32 hat Max Reitz geschrieben: > If the backing file is overridden, this most probably does change the > guest-visible data of a BDS. Therefore, we will need to consider this in > bdrv_refresh_filename(). > > Adding a new field to the BDS is not nice, but it is very simple and

Re: [Qemu-devel] [PATCH for 2.7 v2 1/1] qcow2: improve qcow2_co_write_zeroes()

Am 27.04.2016 um 09:08 hat Denis V. Lunev geschrieben: > There is a possibility that qcow2_co_write_zeroes() will be called by > with the partial block. This could be synthetically triggered with > qemu-io -c "write -z 32k 4k" > and can happen in the real life in qemu-nbd. The latter happens

[Qemu-devel] [PATCH 3/4] acpi: refactor pxb crs computation

Instead of always passing both IO and MEM ranges when computing CRS ranges, define a new CrsRangeSet structure that include them both. This is done before introducing a third type of range, 64-bit MEM, so it will be easier to pass them all around. Signed-off-by: Marcel Apfelbaum

Re: [Qemu-devel] [PATCH] block: Don't lose FUA flag during ZERO_WRITE fallback

Am 30.04.2016 um 23:48 hat Eric Blake geschrieben: > NBD has situations where it can support FUA but not ZERO_WRITE; > when that happens, the generic block layer fallback was losing > the FUA flag. The problem of losing flags unrelated to > ZERO_WRITE has been latent in bdrv_co_do_write_zeroes()

Re: [Qemu-devel] [PATCH v4 03/14] nand: Switch to byte-based block access

Am 29.04.2016 um 22:08 hat Eric Blake geschrieben: > Sector-based blk_write() should die; switch to byte-based > blk_pwrite() instead. Likewise for blk_read(). > > This file is doing some complex computations to map various > flash page sizes (256, 512, and 2048) atop generic uses of > 512-byte

Re: [Qemu-devel] [PATCH] block: Fix typo in comment

Am 26.04.2016 um 12:12 hat Wei Jiangang geschrieben: > s/imlement/implement/ > > Signed-off-by: Wei Jiangang Thanks, applied to block-next. Kevin

[Qemu-devel] [PATCH 0/4] pci: better support for 64-bit MMIO allocation

Hi, First two patches allocate (max_reserved_ram - max_addr_cpu_addressable) range for PCI hotplug (for PC Machines) instead of the previous 64-bit PCI window that included only the ranges allocated by the firmware. The next two patches fix 64-bit CRS computations. Thank you, Marcel Marcel

[Qemu-devel] [PATCH 4/4] hw/apci: handle 64-bit MMIO regions correctly

In build_crs(), the calculation and merging of the ranges already happens in 64-bit, but the entry boundaries are silently truncated to 32-bit in the call to aml_dword_memory(). Fix it by handling the 64-bit MMIO ranges separately. This fixes 64-bit BARs behind PXBs. Signed-off-by: Marcel

Re: [Qemu-devel] [PATCH v4 04/14] onenand: Switch to byte-based block access

Am 29.04.2016 um 22:08 hat Eric Blake geschrieben: > Sector-based blk_write() should die; switch to byte-based > blk_pwrite() instead. Likewise for blk_read(). > > Signed-off-by: Eric Blake > > --- > Not compile tested - I'm not sure what else I'd need in my environment > to

[Qemu-devel] [PATCH 2/4] pci: reserve 64 bit MMIO range for PCI hotplug

Using the firmware assigned MMIO ranges for 64-bit PCI window leads to zero space for hot-plugging PCI devices over 4G. PC machines can use the whole CPU addressable range after the space reserved for memory-hotplug. Signed-off-by: Marcel Apfelbaum --- hw/pci/pci.c | 16

[Qemu-devel] [PATCH 1/4] hw/pc: extract reserved memory end computation to a standalone function

This code will be reused when calculating 64-bit MMIO hotplug ranges. Signed-off-by: Marcel Apfelbaum --- hw/i386/pc.c | 29 + include/hw/i386/pc.h | 1 + 2 files changed, 22 insertions(+), 8 deletions(-) diff --git a/hw/i386/pc.c

Re: [Qemu-devel] [PATCH v4 06/14] sd: Switch to byte-based block access

Am 29.04.2016 um 22:08 hat Eric Blake geschrieben: > Sector-based blk_write() should die; switch to byte-based > blk_pwrite() instead. Likewise for blk_read(). > > Greatly simplifies the code, now that we let the block layer > take care of alignment and read-modify-write on our behalf :) > >

[Qemu-devel] [RFC 00/42] ACPI CPU hotplug refactoring to support more than 255 CPUs and PXM/OST methods

Current ACPI interface for CPU hotplug supports hotadding only upto 255 CPUs and lacks means to convey additional information needed for _PXM and _OST methods support. Also being bitmap based with bit position specifying APIC ID it doesn't scale up for 32-bit APIC IDs that would with x2APIC

[Qemu-devel] [RFC 14/42] tests: acpi: check legacy CPU hotplug AML is present for 2.6 machine type

it should help to notice regression if legacy CPU hotplug unintentionally disappears in old machine types. Signed-off-by: Igor Mammedov --- tests/acpi-test-data/pc/DSDT.cphp_legacy | Bin 0 -> 5502 bytes tests/bios-tables-test.c | 13 + 2 files

Re: [Qemu-devel] [PATCH v3 12/18] qapi: Add qobject_to_json_pretty_prefix()

On 05/02/2016 07:56 AM, Markus Armbruster wrote: > Eric Blake writes: > >> The next patch will add pretty indentation to the JSON visitor. >> But in order to support pretty output in the type_any() callback, >> we need to prefix every line of the QObject visitor by the current

Re: [Qemu-devel] [PATCH v3 07/18] qapi: Add json output visitor

On 05/02/2016 03:15 AM, Markus Armbruster wrote: > Title: s/json/JSON/ > > Eric Blake writes: > >> We have several places that want to go from qapi to JSON; right now, >> they have to create an intermediate QObject to do the work. That >> also has the drawback that the JSON

Re: [Qemu-devel] [PATCH v3 07/18] qapi: Add json output visitor

Eric Blake writes: > We have several places that want to go from qapi to JSON; right now, > they have to create an intermediate QObject to do the work. That > also has the drawback that the JSON formatting of a QDict will > rearrange keys (according to a deterministic, but

[Qemu-devel] [RFC 02/42] acpi: add aml_refof()

Signed-off-by: Igor Mammedov --- hw/acpi/aml-build.c | 8 include/hw/acpi/aml-build.h | 1 + 2 files changed, 9 insertions(+) diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c index 0ecd386..6484161 100644 --- a/hw/acpi/aml-build.c +++

[Qemu-devel] [RFC 06/42] pc: acpi: cpu-hotplug: make AML CPU_foo defines local to cpu_hotplug_acpi_table.c

now as those defines are used only locally inside of cpu_hotplug_acpi_table.c, move them out of header file. Signed-off-by: Igor Mammedov --- hw/acpi/cpu_hotplug_acpi_table.c | 7 +++ include/hw/acpi/cpu_hotplug.h| 7 --- 2 files changed, 7 insertions(+), 7

Re: [Qemu-devel] [PATCH v3 10/18] vmstate: Use new JSON output visitor

On 05/02/2016 07:26 AM, Markus Armbruster wrote: > Eric Blake writes: > >> Rather than using a QJSON object and converting the QString result >> to a char *, we can use the new JSON output visitor and get directly >> to a char *. >> >> The conversions are a bit tricky in place

[Qemu-devel] [PATCH] docs/atomics.txt: Update pointer to linux macro

Add a missing end brace and update doc to point to the latest access macro. ACCESS_ONCE() is deprecated. Signed-off-by: Pranith Kumar --- docs/atomics.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/atomics.txt b/docs/atomics.txt index

Re: [Qemu-devel] [PATCH v4 00/14] block: kill sector-based blk_write/read

On 05/02/2016 01:27 AM, Kevin Wolf wrote: > Am 29.04.2016 um 22:08 hat Eric Blake geschrieben: >> 2.7 material, depends on Kevin's block-next: >> git://repo.or.cz/qemu/kevin.git block-next >> >> Previously posted as part of a larger NBD series [1] (at v3, explaining >> why this is v4), but these

Re: [Qemu-devel] [PATCH v3 12/18] qapi: Add qobject_to_json_pretty_prefix()

Eric Blake writes: > The next patch will add pretty indentation to the JSON visitor. > But in order to support pretty output in the type_any() callback, > we need to prefix every line of the QObject visitor by the current > indentation in the JSON visitor. Hence, a new

Re: [Qemu-devel] [PATCH v3 14/18] qemu-img: Use new JSON output formatter

Eric Blake writes: > Now that we can pretty-print straight to JSON from a visitor, > we can eliminate the temporary conversion into QObject inside > qemu-img. > > The changes to qemu-iotests 043 expected output demonstrates > the fact that output is now done in qapi

Re: [Qemu-devel] [PATCH v9 04/11] block: use the block job list in bdrv_close()

On Fri 29 Apr 2016 04:38:58 PM CEST, Kevin Wolf wrote: > This is essentially the same as I'm doing here: > http://repo.or.cz/qemu/kevin.git/commitdiff/6b545b21e3dfe2e3927cfb6bbdcc1b233c67630c Oh, I see. > I think I like having a separate block_job_cancel_sync_all() function > like I did instead

[Qemu-devel] [RFC 23/42] tests: pc-cpu-test: turn on cpu-hotplug explicily

Machine types before 2.7 have legacy CPU hotplug enabled by defaut to not regress existing setups where it's always enabled. But since 2.7 CPU hotplug is disabled y default and requires explicit enabling using 'cpu-hotplug' parameter in '-machine' option. So turn it on for cpu-hotplug testcase to

Re: [Qemu-devel] [PATCH v3 10/18] vmstate: Use new JSON output visitor

Eric Blake writes: > Rather than using a QJSON object and converting the QString result > to a char *, we can use the new JSON output visitor and get directly > to a char *. > > The conversions are a bit tricky in place (in places, we have to > copy an integer to an int64_t

Re: [Qemu-devel] [PATCH v9 03/11] block: use the block job list in qmp_query_block_jobs()

On Fri 29 Apr 2016 04:32:41 PM CEST, Kevin Wolf wrote: > However, I'd like to give you a heads-up that this will technically > conflict with my series that removes BlockDriverState.blk because that > changes the bdrv_next() signature. > > Nothing dramatic, but I guess it would make sense to

Re: [Qemu-devel] [PATCH v3 08/18] qjson: Simplify by using json-output-visitor

Markus Armbruster writes: > Eric Blake writes: > >> Instead of rolling our own limited JSON outputter, we can just >> wrap the more full-featured JSON output Visitor. >> >> This slightly changes the output (different spacing), but the >> result is still

Re: [Qemu-devel] [Qemu-discuss] iolimits for virtio-9p

On Thu, 28 Apr 2016 11:45:41 +0200 Pradeep Kiruvale wrote: > On 27 April 2016 at 19:12, Greg Kurz wrote: > > > On Wed, 27 Apr 2016 16:39:58 +0200 > > Pradeep Kiruvale wrote: > > > > > On 27 April 2016 at 10:38,

[Qemu-devel] [RFC 39/42] tests: acpi: add expected tables for CPU hotplug case

Signed-off-by: Igor Mammedov --- tests/acpi-test-data/pc/APIC.cphp | Bin 0 -> 160 bytes tests/acpi-test-data/pc/DSDT.cphp | Bin 0 -> 6415 bytes tests/acpi-test-data/q35/APIC.cphp | Bin 0 -> 160 bytes tests/acpi-test-data/q35/DSDT.cphp | Bin 0 -> 9177 bytes 4 files

[Qemu-devel] [RFC 42/42] DO NOT APPLY: simulate CPU unplug when executin cpu-add on a present CPU

Signed-off-by: Igor Mammedov --- hw/i386/pc.c | 8 include/qom/cpu.h | 2 +- qom/cpu.c | 6 +++--- 3 files changed, 12 insertions(+), 4 deletions(-) diff --git a/hw/i386/pc.c b/hw/i386/pc.c index 2d29b5e..7072fb5 100644 --- a/hw/i386/pc.c +++

[Qemu-devel] [RFC 36/42] acpi: cpuhp: add cpu._OST handling

Signed-off-by: Igor Mammedov --- hw/acpi/cpu.c | 83 +++ hw/acpi/ich9.c| 3 ++ hw/acpi/piix4.c | 3 ++ include/hw/acpi/cpu.h | 4 +++ qapi-schema.json | 2 +- trace-events | 2 ++ 6

[Qemu-devel] [RFC 35/42] acpi: cpuhp: provide cpu._PXM method if running in numa mode

Having proximity in SRAT table is not enough in case of linux guest as it discards SRAT table information after it's done with booting. So hotplugged CPUs will go to 1st node as kernel doesn't know to what node they belong to anymore. So do the same as with hotplugged memory and provide _PXM

Re: [Qemu-devel] [PATCH v3 08/18] qjson: Simplify by using json-output-visitor

Eric Blake writes: > Instead of rolling our own limited JSON outputter, we can just > wrap the more full-featured JSON output Visitor. > > This slightly changes the output (different spacing), but the > result is still equivalent JSON contents. > > Signed-off-by: Eric Blake

[Qemu-devel] [RFC 27/42] acpi: add CPU devices AML to DSDT

Signed-off-by: Igor Mammedov --- hw/acpi/cpu.c | 38 ++ hw/i386/acpi-build.c | 2 ++ include/hw/acpi/cpu.h | 3 +++ 3 files changed, 43 insertions(+) diff --git a/hw/acpi/cpu.c b/hw/acpi/cpu.c index 2b4feb0..6dab4d6 100644 ---

[Qemu-devel] [RFC 41/42] tests: acpi: cpuhp: add expected SRAT tables and update DSDT with _PXM support

Signed-off-by: Igor Mammedov --- tests/acpi-test-data/pc/DSDT.cphp | Bin 6415 -> 6614 bytes tests/acpi-test-data/pc/SRAT.cphp | Bin 0 -> 304 bytes tests/acpi-test-data/q35/DSDT.cphp | Bin 9177 -> 9376 bytes tests/acpi-test-data/q35/SRAT.cphp | Bin 0 -> 304 bytes 4

[Qemu-devel] [RFC 32/42] pc: set X86CPU.node property if QEMU starts with numa enabled

Signed-off-by: Igor Mammedov --- hw/i386/pc.c | 43 --- 1 file changed, 36 insertions(+), 7 deletions(-) diff --git a/hw/i386/pc.c b/hw/i386/pc.c index 2dba916..2d29b5e 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -1672,11 +1672,27

[Qemu-devel] [RFC 40/42] tests: acpi: extend CPU hotplug test with NUMA support

Signed-off-by: Igor Mammedov --- tests/bios-tables-test.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c index 670e6a8..1cf6a07 100644 --- a/tests/bios-tables-test.c +++ b/tests/bios-tables-test.c

[Qemu-devel] [RFC 24/42] pc: acpi: cpuhp-legacy: switch ProcessorID to possible_cpus idx

In legacy cpu-hotplug ProcessorID == APIC ID is used in MADT and cpu-hotplug AML. It was fine as both are 8bit and unique. Spec depricated Processor() with corresponding ProcessorID and advises to use Device() and UID instead of it. However UID is just 32bit and it can't fit ARM's arch_id(MPIDR)

  1   2   >