qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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
> 
>> .
>>
> 

  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).