On Mon, Mar 23, 2015 at 07:06:00PM +0530, Bharata B Rao wrote:
> Support hot removal of CPU for sPAPR guests by sending the hot
> unplug notification to the guest via EPOW interrupt.
>
> Signed-off-by: Bharata B Rao
> ---
> hw/ppc/spapr.c| 78
> ++
On Mon, Mar 23, 2015 at 07:06:01PM +0530, Bharata B Rao wrote:
> Release the vCPU objects after CPU hot unplug so that vCPU fd
> can be parked and reused.
>
> Signed-off-by: Bharata B Rao
I think this patch is simple enough it should just be folded in with
the previous one.
> ---
> hw/ppc/spap
On Mon, Mar 23, 2015 at 07:06:02PM +0530, Bharata B Rao wrote:
> Initialize a hotplug memory region under which all the hotplugged
> memory is accommodated. Also enable memory hotplug by setting
> CONFIG_MEM_HOTPLUG.
>
> Modelled on i386 memory hotplug.
>
> Signed-off-by: Bharata B Rao
> ---
>
On Mon, Mar 23, 2015 at 07:05:57PM +0530, Bharata B Rao wrote:
> From: Gu Zheng
>
> In order to deal well with the kvm vcpus (which can not be removed without any
> protection), we do not close KVM vcpu fd, just record and mark it as stopped
> into a list, so that we can reuse it for the appendin
On Mon, Mar 23, 2015 at 07:05:59PM +0530, Bharata B Rao wrote:
> XICS is setup for each CPU during initialization. Provide a routine
> to undo the same when CPU is unplugged.
>
> This allows reboot of a VM that has undergone CPU hotplug and unplug
> to work correctly.
>
> Signed-off-by: Bharata B
On Mon, Mar 23, 2015 at 07:05:58PM +0530, Bharata B Rao wrote:
> When supporting CPU hot removal by parking the vCPU fd and reusing
> it during hotplug again, there can be cases where we try to reenable
> KVM_CAP_IRQ_XICS CAP for the vCPU for which it was already enabled.
> Introduce a boolean memb
On Wed, Mar 25, 2015 at 10:42:32AM +0800, Fam Zheng wrote:
> Block jobs are confusingly inconsistent between with and without
> throttling: if user sets a bps limit, starts a block job, then stops
> vm, the block job will not make any progress; in contrary, if user
> unsets the bps limit, the bloc
On Wed, 03/25 08:16, Alberto Garcia wrote:
> On Wed, Mar 25, 2015 at 10:42:32AM +0800, Fam Zheng wrote:
>
> > Block jobs are confusingly inconsistent between with and without
> > throttling: if user sets a bps limit, starts a block job, then stops
> > vm, the block job will not make any progress;
Currently, throttle timers won't make any progress when VCPU is not
running, which would stall the request queue in utils, qtest, vm
suspending, and live migration, without special handling.
Block jobs are confusingly inconsistent between with and without
throttling: if user sets a bps limit, stop
With qemu 2.2.0 I see now the usb dongle but using it give me some problem seen
on the host:
libusb: error [submit_control_transfer] submiturb failed error -1 errno=22
Disabling caps and seccomp change nothing.
I strace the process and I see:
26170 ioctl(20, USBDEVFS_SUBMITURB, 0x7f00c0539eb0) = -
On Wed, Mar 25, 2015 at 12:36:38PM +1100, David Gibson wrote:
> On Mon, Mar 23, 2015 at 07:05:46PM +0530, Bharata B Rao wrote:
> > Reorganize CPU device tree generation code so that it be reused from
> > hotplug path. CPU dt entries are now generated from spapr_finalize_fdt()
> > instead of spapr_c
Hi mjt,
On 03/21/2015 02:44 PM, Stefan Weil wrote:
With a mask value of 0x0040, the result will never be 1.
This fixes a Coverity warning.
Signed-off-by: Stefan Weil
---
target-tricore/op_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target-tricore/op_help
I was looking at block jobs' AioContext and realized that the block job
coroutines are actually started in main loop.
I'm confused because 5a7e7a0bad17c96e03f55ed7019e2d7545e21a96 and friends in
the series [1] seem to move the coroutines to the BDS's iothreads, but it
didn't do that.
(Although af
On Wed, Mar 25, 2015 at 01:39:02PM +1100, David Gibson wrote:
> On Mon, Mar 23, 2015 at 07:05:52PM +0530, Bharata B Rao wrote:
> > ppc machine init functions create individual CPU threads. Change this
> > for sPAPR by switching to socket creation. CPUs are created recursively
> > by socket and core
On Wed, Mar 25, 2015 at 02:03:45PM +1100, David Gibson wrote:
> On Mon, Mar 23, 2015 at 07:05:53PM +0530, Bharata B Rao wrote:
> > Support CPU hotplug via device-add command. Set up device tree
> > entries for the hotplugged CPU core and use the exising EPOW event
> > infrastructure to send CPU hot
On Wed, Mar 25, 2015 at 02:23:29PM +1100, David Gibson wrote:
> On Mon, Mar 23, 2015 at 07:05:55PM +0530, Bharata B Rao wrote:
> > Currently CPUState.cpu_index is monotonically increasing and a newly
> > created CPU always gets the next higher index. The next available
> > index is calculated by co
On Wed, Mar 25, 2015 at 02:25:09PM +1100, David Gibson wrote:
> On Mon, Mar 23, 2015 at 07:05:56PM +0530, Bharata B Rao wrote:
> > Move cpu_exec_init() call from instance_init to realize. This allows
> > any failures from cpu_exec_init() to be handled appropriately.
> >
> > Also add cpu_exec_exit(
Paolo Bonzini writes:
> On 24/03/2015 17:49, Markus Armbruster wrote:
>>> But what about migration from newer to older QEMU? Libvirt even
>>> supports QEMU versions where the only way to specify disks is "-hda
>>> XYZ", so it is _impossible_ to honor the format=raw specifier.
>>
>> If you migra
Signed-off-by: Markus Armbruster
---
blockdev-nbd.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/blockdev-nbd.c b/blockdev-nbd.c
index b29e456..85cda4c 100644
--- a/blockdev-nbd.c
+++ b/blockdev-nbd.c
@@ -47,8 +47,9 @@ void qmp_nbd_server_start(SocketAddress *addr, Err
On Wed, Mar 25, 2015 at 04:24:39PM +1100, David Gibson wrote:
> On Mon, Mar 23, 2015 at 07:05:58PM +0530, Bharata B Rao wrote:
> > When supporting CPU hot removal by parking the vCPU fd and reusing
> > it during hotplug again, there can be cases where we try to reenable
> > KVM_CAP_IRQ_XICS CAP for
Hi all,
We found that, sometimes, the content of VM's memory is inconsistent between
Source side and Destination side
when we check it just after finishing migration but before VM continue to Run.
We use a patch like bellow to find this issue, you can find it from affix,
and Steps to reproduce:
Block replication is a very important feature which is used for
continuous checkpoints(for example: COLO).
Usage:
Please refer to docs/block-replication.txt
You can get the patch here:
https://github.com/wencongyang/qemu-colo/commits/block-replication-v2
Changs Log:
V2:
1. Redesign the secondary
Signed-off-by: Wen Congyang
Signed-off-by: Paolo Bonzini
Signed-off-by: Yang Hongyang
Signed-off-by: zhanghailiang
Signed-off-by: Gonglei
---
docs/block-replication.txt | 147 +
1 file changed, 147 insertions(+)
create mode 100644 docs/block-replic
When opening BDS, we need to create backup jobs for
image-fleecing.
Signed-off-by: Wen Congyang
Signed-off-by: zhanghailiang
Signed-off-by: Gonglei
Cc: Jeff Cody
---
block/Makefile.objs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/Makefile.objs b/block/Makefile.ob
Signed-off-by: Wen Congyang
Signed-off-by: zhanghailiang
Signed-off-by: Gonglei
---
block/quorum.c | 79 ++
1 file changed, 79 insertions(+)
diff --git a/block/quorum.c b/block/quorum.c
index d087135..eee829d 100644
--- a/block/quorum.c
+
If the child is not ready, read/write/getlength/flush will
return -errno. It is not critical error, and can be ignored:
1. read/write:
Just not report the error event.
2. getlength:
just ignore it. If all children's getlength return -errno,
and be ignored, return -EIO.
3. flush:
Just ig
Signed-off-by: Wen Congyang
Signed-off-by: zhanghailiang
Signed-off-by: Gonglei
---
block/nbd.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/block/nbd.c b/block/nbd.c
index 3faf865..753b322 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -
Signed-off-by: Wen Congyang
Signed-off-by: zhanghailiang
Signed-off-by: Gonglei
---
block.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/block.c b/block.c
index bd7fa9c..3af5ad4 100644
--- a/block.c
+++ b/block.c
@@ -6368,6 +6368,12 @@ BlockAcctStats *bdrv_get_stats(B
Usage:
-drive file=xxx,id=Y, \
-drive
file=,id=X,backing_reference.drive_id=Y,backing_reference.hidden-disk.*
It will create such backing chain:
{virtio-blk dev 'Y'}
{virtio-blk dev 'X'}
|
Signed-off-by: Wen Congyang
Signed-off-by: zhanghailiang
Signed-off-by: Gonglei
---
block/qcow2.c | 447 +-
block/qcow2.h | 6 +
2 files changed, 452 insertions(+), 1 deletion(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index 32bdf75.
The secondary qemu starts later than the primary qemu, so we
cannot connect to nbd server in bdrv_open().
Signed-off-by: Wen Congyang
Signed-off-by: zhanghailiang
Signed-off-by: Gonglei
---
block/nbd.c | 122 +---
1 file changed, 108 inse
Signed-off-by: Wen Congyang
Signed-off-by: zhanghailiang
Signed-off-by: Gonglei
Cc: Jeff Cody
---
block/backup.c| 12
include/block/block_int.h | 1 +
include/qemu/hbitmap.h| 8
util/hbitmap.c| 19 +++
4 files changed, 40 inse
Signed-off-by: Wen Congyang
Signed-off-by: zhanghailiang
Signed-off-by: Gonglei
---
block.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/block.c b/block.c
index 3af5ad4..548cafa 100644
--- a/block.c
+++ b/block.c
@@ -1399,6 +1399,14 @@ static int
bdrv_open_backing_reference_fil
Signed-off-by: Wen Congyang
Signed-off-by: zhanghailiang
Signed-off-by: Gonglei
Cc: Luiz Capitulino
Cc: Michael Roth
---
block.c | 39 +++
include/block/block.h | 4
include/block/block_int.h | 11 +++
qapi/block.json
Signed-off-by: Wen Congyang
Signed-off-by: zhanghailiang
Signed-off-by: Gonglei
---
block.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/block.c b/block.c
index 0ff5cf8..b4d629e 100644
--- a/block.c
+++ b/block.c
@@ -1247,6 +1247,20 @@ out:
* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:
> Hi all,
>
> We found that, sometimes, the content of VM's memory is inconsistent between
> Source side and Destination side
> when we check it just after finishing migration but before VM continue to Run.
>
> We use a patch like bellow to
zhanghailiang wrote:
> Hi all,
>
> We found that, sometimes, the content of VM's memory is inconsistent between
> Source side and Destination side
> when we check it just after finishing migration but before VM continue to Run.
>
> We use a patch like bellow to find this issue, you can find it fr
On 25/03/2015 01:10, Peter Maydell wrote:
> So why do only the ARM boards get fixes here?
> (Why did we allow ourselves to break half our boards
> in commit 0b183fc871 in the first place?)
Because the patches to convert them were in my stolen laptop. :/
Paolo
On 03/25/2015 05:50 PM, Juan Quintela wrote:
> zhanghailiang wrote:
>> Hi all,
>>
>> We found that, sometimes, the content of VM's memory is inconsistent between
>> Source side and Destination side
>> when we check it just after finishing migration but before VM continue to
>> Run.
>>
>> We use
Markus Armbruster writes:
[...]
> * "allwinner-a10"
>
>"-nodefaults -serial null -device allwinner-a10" doesn't explode,
>which means I can't exclude the possibility that this might actually
>do something useful for someone. I'd say we treat it just like
>"pc87312": leave alone n
Review on v1 has gone quiet, so here's v2 which addresses the feedback
received for v1. Thanks to all who have taken the time to review it so
far.
This patchset primarily adds support for FPU and MIPS SIMD Architecture
(MSA) in MIPS KVM guests to QEMU. It depends on the KVM patchset which I
recent
The DPRINTFs in cpu_mips_io_interrupts_pending() and kvm_arch_pre_run()
are particularly noisy during normal execution, and also not
particularly helpful. Remove them so that more important debug messages
can be more easily seen.
Signed-off-by: James Hogan
Reviewed-by: Leon Alrae
Cc: Paolo Bonzi
Implement saving and restoring to KVM state of the Config CP0 registers
(namely Config, Config1, Config2, Config3, Config4, and Config5). These
control the features available to a guest, and a few of the fields will
soon be writeable by a guest so QEMU needs to know about them so as not
to clobber
This patch updates the linux headers based solely on the changes in my
"MIPS: KVM: Guest FPU & SIMD (MSA) support" KVM patchset. It is provided
for reference since those changes haven't been merged yet. The stored
headers will need to be synced after my KVM patches are merged and
before the rest of
On Wed, 2015-03-25 at 09:18 +0800, Chen, Tiejun wrote:
> Actually my problem is that, I need to add a new parameter, 'flag', like
> this, xc_assign_device(xxx,xxx,flag). So if I don't refine xc.c, tools
> can't be compiled successfully. Or maybe you're suggesting I may isolate
> this file while
Implement saving and restoring to KVM state of the Processor ID (PRid)
CP0 register. This allows QEMU to control the PRid exposed to the guest
instead of using the default set by KVM.
Signed-off-by: James Hogan
Reviewed-by: Leon Alrae
Cc: Paolo Bonzini
Cc: Aurelien Jarno
---
target-mips/kvm.c
Rename kvm_mips_{get,put}_one_reg64() to kvm_mips_{get,put}_one_ureg64()
since they take an int64_t pointer, and add separate signed 64-bit
accessors. These will be used for double precision floating point
registers.
Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: Leon Alrae
Cc: Aurelien Jarno
Add KVM register access functions for the uint32_t type. This is
required for FP and MSA control registers, which are represented as
unsigned 32-bit integers.
Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: Leon Alrae
Cc: Aurelien Jarno
---
target-mips/kvm.c | 29
The KVM_REG_MIPS_COUNT_* definitions are now included in
linux-headers/asm-mips/kvm.h since commit b061808d39fa ("linux-headers:
update linux headers to kvm/next"), therefore the duplicate definitions
in target-mips/kvm.c can now be dropped.
The MIPS_C0_{32,64} macros are also updated to utilise d
Support the new KVM_CAP_MIPS_FPU capability, which allows the host's FPU
to be exposed to the KVM guest.
The capability is enabled if the guest core has an FPU according to its
Config1 register. Various config bits are now writeable so that KVM is
aware of the configuration (Config1.FP) and so tha
Support the new KVM_CAP_MIPS_MSA capability, which allows MIPS SIMD
Architecture (MSA) to be exposed to the KVM guest.
The capability is enabled if the guest core has MSA according to its
Config3 register. Various config bits are now writeable so that KVM is
aware of the configuration (Config3.MSA
As part of commit e325b49a320b493cc5d69e263751ff716dc458fe,
order in which resources are destroyed was changed for fixing
a seg fault. Due to this change, CQ will never get destroyed as
CQ should be destroyed after QP destruction. Seg fault is caused
improper cleanup when connection fails. Fixing c
Libseccomp version updated to 2.2.0 and arch restriction to x86/x86_64
is now removed. It's supposed to work on armv7l as well.
Related bug: https://bugs.launchpad.net/qemu/+bug/1363641
Signed-off-by: Eduardo Otubo
---
configure | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff -
On Wed, 2015-03-25 at 09:10 +0800, Chen, Tiejun wrote:
> +But when given as a string the B option describes the type
> +of device to enable. Not this behavior is only supported with upstream
"Note" and "the upstream..."
> +=item "igd"
> +
> +Enables graphics device PCI passthrough but force set
The following changes since commit 054903a832b865eb5432d79b5c9d1e1ff31b58d7:
Update version for v2.3.0-rc1 release (2015-03-24 16:34:16 +)
are available in the git repository at:
git://github.com/otubo/qemu.git tags/pull-seccomp-20150325
for you to fetch changes up to
On Tue, 24 Mar 2015 18:48:02 +0800
Zhu Guihua wrote:
>
> On 03/24/2015 06:31 PM, Igor Mammedov wrote:
> > On Tue, 24 Mar 2015 17:38:53 +0800
> > Zhu Guihua wrote:
> >
> >> On 03/16/2015 10:59 PM, Igor Mammedov wrote:
> >>> On Mon, 16 Mar 2015 16:58:18 +0800
> >>> Zhu Guihua wrote:
> >>>
>
On 25/03/2015 09:10, Markus Armbruster wrote:
>> Based on my reading of the code, libvirt will actually ignore the
>> allow_disk_format_probing setting, and not do anything about the format
>> when driving such an old QEMU. By contrast, if you specify a format and
>> libvirt invokes an old qemu-
On 25/03/2015 09:18, Markus Armbruster wrote:
> Signed-off-by: Markus Armbruster
> ---
> blockdev-nbd.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/blockdev-nbd.c b/blockdev-nbd.c
> index b29e456..85cda4c 100644
> --- a/blockdev-nbd.c
> +++ b/blockdev-nbd.c
>
> As part of commit e325b49a320b493cc5d69e263751ff716dc458fe,
> order in which resources are destroyed was changed for fixing
> a seg fault. Due to this change, CQ will never get destroyed as
> CQ should be destroyed after QP destruction. Seg fault is caused
> improper cleanup when connection fails
On Wed, 25 Mar 2015 14:13:23 +0800
Zhu Guihua wrote:
>
> On 03/24/2015 06:26 PM, Igor Mammedov wrote:
> > On Tue, 24 Mar 2015 17:34:29 +0800
> > Zhu Guihua wrote:
> >
> >> On 03/23/2015 08:47 PM, Igor Mammedov wrote:
> >>> On Mon, 23 Mar 2015 18:59:28 +0800
> >>> Zhu Guihua wrote:
> >>>
>
"Li, Liang Z" wrote:
>> >> > Right now, we don't have an interface to detect that cases and got
>> >> > back to the iterative stage.
>> >>
>> >> How about go back to the iterative stage when detect that the
>> >> pending_size is larger Than max_size, like this:
>> >>
>> >> +/* do f
Am 25.03.2015 um 11:50 hat Juan Quintela geschrieben:
> "Li, Liang Z" wrote:
> >> >> > Right now, we don't have an interface to detect that cases and got
> >> >> > back to the iterative stage.
> >> >>
> >> >> How about go back to the iterative stage when detect that the
> >> >> pending_size is lar
On Mon, 23 Mar 2015 17:32:21 +0100
Andreas Färber wrote:
> Am 23.03.2015 um 16:11 schrieb Peter Maydell:
> > On 23 March 2015 at 14:39, Paolo Bonzini wrote:
> >> On 23/03/2015 13:24, Peter Maydell wrote:
> >>> * cpu_physical_memory_rw are obsolete and should be replaced
> >>>with uses of th
"Dr. David Alan Gilbert (git)" wrote:
> From: "Dr. David Alan Gilbert"
>
> Passing multiple -incoming options used to crash qemu (due to
> an invalid state transition incoming->incoming). Instead we now
> take the last -incoming option, e.g.:
>
> qemu-system-x86_64 -nographic -incoming tcp::
On 25 March 2015 at 01:43, Sergey Fedorov wrote:
> On 24.03.2015 18:30, Sergey Fedorov wrote:
>> So if I understand you correctly, it would be suitable to implement a
>> model like Juno ARM Development Platform in order to get AArch64 VE
>> model with SMP support in system mode?
>
> As you can gue
Hi Peter,
>> So why do only the ARM boards get fixes here?
> ...ah, I see you've submitted patches for other boards too,
> you just didn't put them together into a single series. Sorry.
Some other architectures were already fixed (x86 and ppc) and I'll be
working through the other arches shortly.
Padmanabh Ratnakar wrote:
> As part of commit e325b49a320b493cc5d69e263751ff716dc458fe,
> order in which resources are destroyed was changed for fixing
> a seg fault. Due to this change, CQ will never get destroyed as
> CQ should be destroyed after QP destruction. Seg fault is caused
> improper cl
* Liang Li (liang.z...@intel.com) wrote:
> From: Juan Quintela
>
> Compression code (still not on tree) want to call this funtion from
> outside the migration thread, so we can't write to last_sent_block.
>
> Instead of reverting full patch:
>
> [PULL 07/11] save_block_hdr: we can recalculate
>
On 25/03/2015 09:31, Fam Zheng wrote:
> I was looking at block jobs' AioContext and realized that the block job
> coroutines are actually started in main loop.
>
> I'm confused because 5a7e7a0bad17c96e03f55ed7019e2d7545e21a96 and friends in
> the series [1] seem to move the coroutines to the BDS
Hi guys,
could anybody help out? Is there a guide on how to implement new CPU's in QEMU
(or that at least helps in that task) or on how to debug this kind of stuff?
Cheers,
Duarte
On Sunday 22 March 2015 11:13:37 Duarte Silva wrote:
> Hi guys,
>
> I have been struggling to get some binaries co
On 2015/3/25 17:46, Dr. David Alan Gilbert wrote:
* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:
Hi all,
We found that, sometimes, the content of VM's memory is inconsistent between
Source side and Destination side
when we check it just after finishing migration but before VM continue
On 2015/3/25 17:50, Juan Quintela wrote:
zhanghailiang wrote:
Hi all,
We found that, sometimes, the content of VM's memory is inconsistent between
Source side and Destination side
when we check it just after finishing migration but before VM continue to Run.
We use a patch like bellow to fin
On 25/03/2015 00:41, Peter Maydell wrote:
> On 24 March 2015 at 20:00, Paolo Bonzini wrote:
>> I agree with that. I just want to keep ld/st*_phys _in addition_ as the
>> short forms of address_space_ld/st*, and keep ld/st*_phys instead of
>> address_space_ld/st* for those uses that have cs->as
* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:
> On 2015/3/25 17:46, Dr. David Alan Gilbert wrote:
> >* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:
> >>Hi all,
> >>
> >>We found that, sometimes, the content of VM's memory is inconsistent
> >>between Source side and Destination s
commit 9b70c1790acacae54d559d38ca69186a85040bb8
virtio-serial: switch to standard-headers
changes virtio_console_config size from 8 to 12 bytes:
it adds an optional 4 byte emerg_wr field.
As this crosses a power of two boundary, this changes the PCI BAR size,
which breaks migration compatibil
On 25 March 2015 at 11:34, Paolo Bonzini wrote:
>
>
> On 25/03/2015 00:41, Peter Maydell wrote:
>> On 24 March 2015 at 20:00, Paolo Bonzini wrote:
>>> I agree with that. I just want to keep ld/st*_phys _in addition_ as the
>>> short forms of address_space_ld/st*, and keep ld/st*_phys instead of
On 03/25/2015 07:41 AM, Michael S. Tsirkin wrote:
> commit 9b70c1790acacae54d559d38ca69186a85040bb8
> virtio-serial: switch to standard-headers
>
> changes virtio_console_config size from 8 to 12 bytes:
> it adds an optional 4 byte emerg_wr field.
>
> As this crosses a power of two boundary,
Liang Li wrote:
> Implement the core logic of the multiple thread compression. At this
> point, multiple thread compression can't co-work with xbzrle yet.
>
> Signed-off-by: Liang Li
> Signed-off-by: Yang Zhang
> ---
> arch_init.c | 184
> ++
On 25/03/2015 12:43, Peter Maydell wrote:
> I was trying to avoid leaving us with yet another half-finished
> set of API transitions: because many of our CPUs are in this
> odd-fixes state, it's unlikely anybody will get round to
> updating them in the near future, so we'll be carrying a
> duplic
On 2015/3/25 19:36, Dr. David Alan Gilbert wrote:
* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:
On 2015/3/25 17:46, Dr. David Alan Gilbert wrote:
* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:
Hi all,
We found that, sometimes, the content of VM's memory is inconsistent betw
Liang Li wrote:
> Implement the core logic of multiple thread decompression,
> the decompression can work now.
>
> Signed-off-by: Liang Li
> Signed-off-by: Yang Zhang
> ---
> arch_init.c | 50 --
> 1 file changed, 48 insertions(+), 2 deletions(-)
On Tue, Mar 24, 2015 at 04:33:48PM +0100, Alberto Garcia wrote:
> On Tue, Mar 24, 2015 at 03:03:07PM +, Stefan Hajnoczi wrote:
>
> > > +typedef struct ThrottleGroup {
> > > +char *name; /* This is constant during the lifetime of the group */
> >
> > Is this also protected by throttle_grou
On Tue, Mar 24, 2015 at 06:48:37PM +0100, Alberto Garcia wrote:
> On Tue, Mar 24, 2015 at 04:31:45PM +, Stefan Hajnoczi wrote:
>
> > > +/* get next bs round in round robin style */
> > > +token = throttle_group_next_bs(token);
> > > +while (token != start &&
> > > + qemu
On Wed, 03/25 12:25, Paolo Bonzini wrote:
>
>
> On 25/03/2015 09:31, Fam Zheng wrote:
> > I was looking at block jobs' AioContext and realized that the block job
> > coroutines are actually started in main loop.
> >
> > I'm confused because 5a7e7a0bad17c96e03f55ed7019e2d7545e21a96 and friends in
> > > > +typedef struct ThrottleGroup {
> > > > +char *name; /* This is constant during the lifetime of the group */
> > >
> > > Is this also protected by throttle_groups_lock?
> > >
> > > I guess throttle_groups_lock must be held in order to read this
> > > field - otherwise there is a risk
On 16/03/2015 07:19, Wen Congyang wrote:
> On 03/13/2015 05:05 PM, Fam Zheng wrote:
>> On Fri, 03/13 17:01, Wen Congyang wrote:
>>> On 03/11/2015 02:49 PM, Fam Zheng wrote:
On Wed, 03/11 14:44, Wen Congyang wrote:
> On 03/03/2015 03:59 PM, Fam Zheng wrote:
>> On Tue, 03/03 15:53, Wen
On 25/03/2015 10:36, Wen Congyang wrote:
> +static QemuOptsList quorum_children_common_opts = {
> +.name = "qcow2 children",
.name should be "quorum children".
Paolo
> +.head = QTAILQ_HEAD_INITIALIZER(quorum_children_common_opts.head),
> +.desc = {
> +{
> +.name
On 25/03/2015 10:36, Wen Congyang wrote:
> The secondary qemu starts later than the primary qemu, so we
> cannot connect to nbd server in bdrv_open().
>
> Signed-off-by: Wen Congyang
> Signed-off-by: zhanghailiang
> Signed-off-by: Gonglei
> ---
> block/nbd.c | 122
>
On 25/03/2015 10:36, Wen Congyang wrote:
> Signed-off-by: Wen Congyang
> Signed-off-by: zhanghailiang
> Signed-off-by: Gonglei
> Cc: Luiz Capitulino
> Cc: Michael Roth
> ---
> block.c | 39 +++
> include/block/block.h | 4
> in
On 25/03/2015 10:36, Wen Congyang wrote:
> Signed-off-by: Wen Congyang
> Signed-off-by: zhanghailiang
> Signed-off-by: Gonglei
> ---
> block/quorum.c | 79
> ++
> 1 file changed, 79 insertions(+)
>
> diff --git a/block/quorum.c b/block
On 25/03/2015 10:36, Wen Congyang wrote:
> Signed-off-by: Wen Congyang
> Signed-off-by: zhanghailiang
> Signed-off-by: Gonglei
> ---
> block/nbd.c | 49 +
> 1 file changed, 49 insertions(+)
>
> diff --git a/block/nbd.c b/block/nbd.c
> index 3fa
On 25/03/2015 10:36, Wen Congyang wrote:
>
> +void backup_do_checkpoint(BlockJob *job, Error **errp)
> +{
> +BackupBlockJob *backup_job = container_of(job, BackupBlockJob, common);
> +
> +if (job->driver != &backup_job_driver) {
> +error_setg(errp, "It is not backup job");
> +
On Fri, Mar 13, 2015 at 03:22:01PM -0400, John Snow wrote:
> This is a re-send of patches 7 & 8 from an earlier series,
> "[PATCH v2 0/8] ahci: add more IO tests" which ultimately got bounced
> back because I used some glib functions that were too new.
>
> v2:
> - Patchew caught a pathing problem
On 25/03/2015 10:36, Wen Congyang wrote:
> Block replication is a very important feature which is used for
> continuous checkpoints(for example: COLO).
>
> Usage:
> Please refer to docs/block-replication.txt
>
> You can get the patch here:
> https://github.com/wencongyang/qemu-colo/commits/bloc
On Fri, Mar 13, 2015 at 05:50:52PM -0400, John Snow wrote:
> Currently, the AHCI device tries to re-map guest memory every time
> the low or high address registers are written to, whether or not the
> AHCI device is currently active. If the other register has stale
> information in it, this may lea
On 25/03/2015 00:20, Andreas Färber wrote:
>>> >> -g_test_add(testpath, FirmwareTestFixture, NULL, setup_fixture,
>>> >> +char *path = g_strdup_printf("/%s%s", qtest_get_arch(), testpath);
>>> >> +g_test_add(path, FirmwareTestFixture, NULL, setup_fixture,
>>> >> test_
On 10/03/2015 03:01, Zhang Haoyu wrote:
> My test results show that when using thin-provisioning qcow2
> image(created by qemu-img create -f qcow2 preallocation=metadata),
> even the unallocated sectors will be transferred to destination, so
> much data is transferred, so the qcow2 image in dest
On Mon, Mar 23, 2015 at 03:29:22PM +, Stefan Hajnoczi wrote:
> v3:
> * Use Paolo's much cleaner rewrite of the omap intc loop [Paolo]
> * Rebased on qemu.git/master
>
> v2:
> * Audit coccinelle patch and split out two cases where ctz32(0) == 32 must be
>handled [Peter]
> * Cc qemu-sta.
On 25/03/2015 11:21, Wen Congyang wrote:
> > What kind of load were you having when reproducing this issue?
> > Just to confirm, you have been able to reproduce this without COLO
> > patches, right?
>
> I can reproduce it without COLO patches.
Thanks. Please try doing mprotect (using qemu_ram_
Hi Duarte,
On 22/03/15 11:13, Duarte Silva wrote:
> Hi guys,
>
> I have been struggling to get some binaries compiled for NetLogic XLP
> processor to run under QEMU. I have tried a bunch of things (most going back
> and forth) and always get the following error message:
>
> qemu: uncaught targ
1 - 100 of 279 matches
Mail list logo
