On 07.10.2013 11:55, Paolo Bonzini wrote:
Il 07/10/2013 11:49, Peter Lieven ha scritto:
It's in general not easy to do this if you take non-x86 targets into
account.
What about the dirty way to zero out all non zero pages at the beginning of
ram_load?
I'm not sure I follow?
sth like this for
Il 07/10/2013 11:49, Peter Lieven ha scritto:
>> It's in general not easy to do this if you take non-x86 targets into
>> account.
> What about the dirty way to zero out all non zero pages at the beginning of
> ram_load?
I'm not sure I follow?
Paolo
--
To unsubscribe from this list: send the line
On 07.10.2013 11:37, Paolo Bonzini wrote:
Il 07/10/2013 08:38, Peter Lieven ha scritto:
On 06.10.2013 15:57, Zhang Haoyu wrote:
>From my testing this has been fixed in the saucy version (1.5.0) of
qemu. It is fixed by this patch:
f1c72795af573b24a7da5eb52375c9aba8a37972
However later in the
Il 07/10/2013 08:38, Peter Lieven ha scritto:
> On 06.10.2013 15:57, Zhang Haoyu wrote:
>>> >From my testing this has been fixed in the saucy version (1.5.0) of
>> qemu. It is fixed by this patch:
>>> f1c72795af573b24a7da5eb52375c9aba8a37972
>>>
>>> However later in the history this commit was reve
On 06.10.2013 15:57, Zhang Haoyu wrote:
>From my testing this has been fixed in the saucy version (1.5.0) of
qemu. It is fixed by this patch:
f1c72795af573b24a7da5eb52375c9aba8a37972
However later in the history this commit was reverted, and again broke
this. The other commit that fixes this
>>From my testing this has been fixed in the saucy version (1.5.0) of
qemu. It is fixed by this patch:
>f1c72795af573b24a7da5eb52375c9aba8a37972
>
>However later in the history this commit was reverted, and again broke
this. The other commit that fixes this is:
>211ea74022f51164a7729030b28eec90b6c9
