From: Paolo Bonzini <pbonzini@redhat.com>
To: "Herongguang (Stephen)" <herongguang.he@huawei.com>,
qemu-devel@nongnu.org, quintela@redhat.com, amit.shah@redhat.com
Cc: arei.gonglei@huawei.com, "Huangweidong (C)" <weidong.huang@huawei.com>
Subject: Re: [Qemu-devel] [RFC/PATCH] migration: SMRAM dirty bitmap not fetched from kvm-kmod and not send to destination
Date: Fri, 23 Sep 2016 10:59:41 +0200 [thread overview]
Message-ID: <ec58b357-61cf-5a4d-cb44-edbdefb4920c@redhat.com> (raw)
In-Reply-To: <57E4ED02.3060204@huawei.com>
On 23/09/2016 10:51, Herongguang (Stephen) wrote:
>
>
> On 2016/9/23 15:17, Paolo Bonzini wrote:
>>
>>
>> On 22/09/2016 15:16, Herongguang (Stephen) wrote:
>>> I have some concern:
>>> 1. For example, vhost does not know about as_id, I wonder if guests in
>>> SMM can operate disk or ether card, as in
>>> that case vhost would not logging dirty pages correctly, without knowing
>>> as_id.
>>
>> In the end memory is logged by ram_addr_t, not by address space. So if
>> vhost_sync_dirty_bitmap is called on the right region everything works.
>>
>> Guests in SMM can operate on storage devices, but storage devices cannot
>> write to 0xA0000-0xBFFFF so that's safe.
> You are right, as vhost does not have a smram address space listener. So
> is this a qemu's flaw that virtual devices can not write to SMRAM?
No, it's how it works in real hardware. However, it is a (minor) bug
that vhost doesn't have the equivalent of kvm_set_phys_mem's call to
kvm_physical_sync_dirty_bitmap.
> Fine, your patch is simpler than I thought and functions right.
Great!
> Reviewed-by: He Rongguang <herongguang.he@huawei.com>
Also Tested-by?
Thanks,
Paolo
>
>> .
>>
>
next prev parent reply other threads:[~2016-09-23 8:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-14 7:55 [Qemu-devel] [RFC/PATCH] migration: SMRAM dirty bitmap not fetched from kvm-kmod and not send to destination Herongguang (Stephen)
2016-09-14 9:05 ` Paolo Bonzini
2016-09-22 13:16 ` Herongguang (Stephen)
2016-09-23 1:11 ` Herongguang (Stephen)
2016-09-23 7:17 ` Paolo Bonzini
2016-09-23 8:51 ` Herongguang (Stephen)
2016-09-23 8:59 ` Paolo Bonzini [this message]
2016-09-23 9:14 ` Herongguang (Stephen)
2016-09-25 11:33 ` Herongguang (Stephen)
2016-09-26 7:15 ` Paolo Bonzini
2016-09-22 7:51 ` [Qemu-devel] [RFC/PATCH 2] kvm: x86: handle KVM_SET_VCPU_EVENTS/KVM_VCPUEVENT_VALID_SMM properly Herongguang (Stephen)
2016-09-22 9:29 ` Paolo Bonzini
2016-09-22 13:19 ` Herongguang (Stephen)
2016-09-22 7:56 ` [Qemu-devel] [RFC/PATCH 3] kvm: fix events.flags (KVM_VCPUEVENT_VALID_SMM) overwritten by 0 Herongguang (Stephen)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ec58b357-61cf-5a4d-cb44-edbdefb4920c@redhat.com \
--to=pbonzini@redhat.com \
--cc=amit.shah@redhat.com \
--cc=arei.gonglei@huawei.com \
--cc=herongguang.he@huawei.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=weidong.huang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).