From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:39154)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jitendra.kolhe@hpe.com>) id 1akrBR-0006e6-4J
	for qemu-devel@nongnu.org; Tue, 29 Mar 2016 06:47:38 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jitendra.kolhe@hpe.com>) id 1akrBM-0004fs-KV
	for qemu-devel@nongnu.org; Tue, 29 Mar 2016 06:47:37 -0400
Received: from g2t4621.austin.hp.com ([15.73.212.80]:33236)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jitendra.kolhe@hpe.com>) id 1akrBM-0004dt-FY
	for qemu-devel@nongnu.org; Tue, 29 Mar 2016 06:47:32 -0400
References: <1459138565-6244-1-git-send-email-jitendra.kolhe@hpe.com>
	<20160328094945-mutt-send-email-mst@redhat.com>
	<56FA5385.1030608@redhat.com>
From: Jitendra Kolhe <jitendra.kolhe@hpe.com>
Message-ID: <56FA5D33.2020802@hpe.com>
Date: Tue, 29 Mar 2016 16:17:15 +0530
MIME-Version: 1.0
In-Reply-To: <56FA5385.1030608@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v2] migration: skip sending ram pages
 released by virtio-balloon driver.
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>
Cc: JBottomley@Odin.com, ehabkost@redhat.com, crosthwaite.peter@gmail.com, simhan@hpe.com, armbru@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org, lcapitulino@redhat.com, borntraeger@de.ibm.com, mohan_parthasarathy@hpe.com, stefanha@redhat.com, amit.shah@redhat.com, den@openvz.org, dgilbert@redhat.com, rth@twiddle.net

On 3/29/2016 3:35 PM, Paolo Bonzini wrote:
> 
> 
> On 28/03/2016 08:59, Michael S. Tsirkin wrote:
>>>> +    qemu_mutex_lock_balloon_bitmap();
>>>>      for (;;) {
>>>>          size_t offset = 0;
>>>>          uint32_t pfn;
>>>>          elem = virtqueue_pop(vq, sizeof(VirtQueueElement));
>>>>          if (!elem) {
>>>> +            qemu_mutex_unlock_balloon_bitmap();
>>>>              return;
>>>>          }
>>>>  
>>>> @@ -242,6 +245,7 @@ static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
>>>>              addr = section.offset_within_region;
>>>>              balloon_page(memory_region_get_ram_ptr(section.mr) + addr,
>>>>                           !!(vq == s->dvq));
>>>> +            qemu_balloon_bitmap_update(addr, !!(vq == s->dvq));
>>>>              memory_region_unref(section.mr);
>>>>          }
>>>>  
>> So the assumption here is that offset_within_region equals
>> ram ptr if region is get_system_memory.
>>
>> And I'm not sure that's always right.
>>
>> Paolo?
> 
> Indeed.  It is correct for the main system RAM, but hot-plugged RAM
> would also have a zero-based section.offset_within_region.  You need to
> add memory_region_get_ram_addr(section.mr), just like the call to
> balloon_page adds memory_region_get_ram_ptr(section.mr).
> 
> Paolo
> 

Thanks, that's useful. 
I am only interested in the offset from memory region base. 
Would below guest PA to host offset work, as we do in
address_space_translate_internal()?
(Guest pa - section.offset_within_address_space + 
section.offset_within_region)

- Jitendra