Cc: berra...@redhat.com
Liang
> -Original Message-
> From: Li, Liang Z
> Sent: Tuesday, May 03, 2016 2:39 PM
> To: qemu-devel@nongnu.org
> Cc: quint...@redhat.com; amit.s...@redhat.com; dgilb...@redhat.com; Li,
> Liang Z
> Subject: [PATCH] migration: Fix multi-thread compression bug
>
>
On 04/29/2016 01:34 AM, Eduardo Habkost wrote:
(CCing some additional Intel people)
On Wed, Apr 27, 2016 at 04:13:06PM +0800, Xiao Guangrong wrote:
From: Eduardo Habkost
Introduce Skylake-Client cpu mode which inherits the features from
Broadwell and supports some additional features that a
Recently, a bug related to multiple thread compression feature for
live migration is reported. The destination side will be blocked
during live migration if there are heavy workload in host and
memory intensive workload in guest, this is most likely to happen
when there is one decompression thread.
On 2016-05-03 08:00, Peter Xu wrote:
> On Tue, May 03, 2016 at 07:40:50AM +0200, Jan Kiszka wrote:
>> 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
On Tue, May 03, 2016 at 07:40:50AM +0200, Jan Kiszka wrote:
> 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+08
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 Kisz
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 wit
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 s
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
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
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. Lu
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 fixed it then it seems
p
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 figured out why.]
>>>
>>> On 3 May 2016 at 01:47, Christopher Friedt wrote:
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.
In
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 wrote:
>>> The file ivshmem.c unconditionally references event_noti
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 event_notifier_init_fd()
>> in util/event_notifier-posix.c, even if CO
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. Luc
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 reasons.
>>
>> One of tho
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 thing? I run Yosemite, which is
> fine.
I think yo
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 pro
[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, but ivshmem.c is only buil
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. Luc
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
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.
In
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 exist for file bac
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
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
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.
thanks
-- PMM
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 place it is really chec
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, you set
> with
> a single messa
*** 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 ***
> https://bugs.l
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, wouldn
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
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 not sure what else I'
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,
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 code
*** 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 1
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 ea1
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
>> same pointer to visit
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 generate
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 cr
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 fro
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 release
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
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
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 access to the
> same poin
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
>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. This patch replaces er
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 visitor.
>
> Note that we
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 vmstop, disconnect, conn
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 tb_find_fast()")
from:
https://github.com/rth7680/qemu.git tcg-next
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
> ---
>
> tcg/mips/tcg-target.inc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
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:
https://github.com/rth7680/qemu.git tcg-next
tcg/mips/tcg-target.inc.c | 2 +-
1 file cha
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
> > > > > wo
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 p
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 https://sourceforge.net
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 of code looks like this:
>>
>> #define CONFI
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 that appears
>> > to n
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 +-
migration/migra
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 a/tests/bios-tables-test.c b/
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 which
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 signific
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 jus
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 Kiruvale wrote:
> > >
> > > > On 27 April 2016 at 10:38, Alberto Garcia 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 problem of losing flags unrelated to
>> ZERO_WRIT
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
>
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 un
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
---
hw/i386/acp
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() s
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 s
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
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 Apf
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 Apfelba
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 actually test this
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 ++--
1 file
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 b/hw/i386/pc.c
index 2ac97c
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 :)
>
> Sig
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
support
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 changed, 13 insertions
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
>> indentation in t
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 formatting of a QDic
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 unpredictable,
> hash)
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
+++ b/hw/acpi/aml-build.c
@@ -1416,6 +1416
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 deletions(-)
diff --git a
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 (in places, we have
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 ef285e3..bba771e 100644
---
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 ar
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 function
> qobject_to_json
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 declaration order,
> rather th
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 o
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
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 temporary to get the r
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 decide
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 equivalent JSON contents.
>>
>> Signed-off
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, Alberto Garcia wrote:
> > >
> > > > On Wed, Apr 27, 2016 at 09:29:02AM +0200, Prad
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 changed, 0 insertions(+),
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
+++ b/hw/i386/pc.c
@@ -1063,6 +1063
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 files changed, 96 insertio
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 method
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
The file comment
1 - 100 of 148 matches
Mail list logo
