k
>> based on
>> qemu? or an independent tool (CRIU migration?) for live-migration?
>> Maybe i could fix the migration problem for ivshmem in qemu now,
>> based on softdirty mechanism.
>>
>>> Documentation/vm/soft-dirty.txt and pagemap.txt in case you aren't
>>> familiar. To
>>
>>
>> I have read them cursorily, it is useful for pre-copy indeed. But it seems
>> that
>> it can not meet my need for snapshot.
>>
>>> make softdirty usable for live migration, I've added an API to atomically
>>> test-and-clear the bit and write protect the page.
>>
>>
>> How can i find the API? Is it been merged in kernel's master branch
>> already?
>>
>>
>> Thanks,
>> zhanghailiang
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> .
>>
>
--
Andres Lagar-Cavilla | Google Kernel Team | andre...@google.com
FWIW this one bites me. The bug report seems fairly abandoned ... has
this been fixed elsewhere perhaps?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1062411
Title:
QEMU fails during migration and
I meant "bites me too" ...
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1062411
Title:
QEMU fails during migration and reports "qemu: VQ 0 size 0x80 Guest
index 0x2d6 inconsistent with Host inde
On Nov 15, 2012, at 9:33 AM, Stefano Stabellini
wrote:
> On Wed, 14 Nov 2012, Andres Lagar-Cavilla wrote:
>> Stefano, and Xen-qemu team, I have a question.
>>
>> The standard Xen-qemu workflow has Xen manage the physmap for a VM, and
>> allocate all the ba
Stefano, and Xen-qemu team, I have a question.
The standard Xen-qemu workflow has Xen manage the physmap for a VM, and
allocate all the backing memory for valid pfns, regardless of whether they are
MMIO, RAM, etc. On save/migrate, when using upstream qemu, a special monitor
command is used to s
> At 17:14 + on 15 Mar (1331831693), Stefano Stabellini wrote:
>> On Thu, 15 Mar 2012, Julien Grall wrote:
>> > When an IOREQ_TYPE_INVALIDATE is sent to QEMU, it invalidates all
>> entry
>> > of the map cache even if it's locked.
>> >
>> > QEMU is not able to know that entry was invalidated, so
> On Thu, 15 Mar 2012, Julien Grall wrote:
>> When an IOREQ_TYPE_INVALIDATE is sent to QEMU, it invalidates all entry
>> of the map cache even if it's locked.
>>
>> QEMU is not able to know that entry was invalidated, so when an IO
>> access is requested a segfault occured.
>
> The problem here is
