From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34513) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBys1-0001Br-Ep for qemu-devel@nongnu.org; Sun, 25 Mar 2012 21:37:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SByrz-00015s-9P for qemu-devel@nongnu.org; Sun, 25 Mar 2012 21:37:17 -0400 Received: from [222.73.24.84] (port=32611 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SByry-0000y7-Ua for qemu-devel@nongnu.org; Sun, 25 Mar 2012 21:37:15 -0400 Message-ID: <4F6FC8CC.5010902@cn.fujitsu.com> Date: Mon, 26 Mar 2012 09:39:24 +0800 From: Wen Congyang MIME-Version: 1.0 References: <4F680037.9090101@cn.fujitsu.com> <20120323.184022.246504000.d.hatayama@jp.fujitsu.com> In-Reply-To: <20120323.184022.246504000.d.hatayama@jp.fujitsu.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [PATCH 11/11 v10] introduce a new monitor command 'dump-guest-memory' to dump guest's memory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: HATAYAMA Daisuke Cc: jan.kiszka@siemens.com, qemu-devel@nongnu.org, lcapitulino@redhat.com, anderson@redhat.com, anthony@codemonkey.ws, eblake@redhat.com At 03/23/2012 05:40 PM, HATAYAMA Daisuke Wrote: > From: Wen Congyang > Subject: [PATCH 11/11 v10] introduce a new monitor command 'dump-guest-memory' to dump guest's memory > Date: Tue, 20 Mar 2012 11:57:43 +0800 > >> +/* get the memory's offset in the vmcore */ >> +static target_phys_addr_t get_offset(target_phys_addr_t phys_addr, >> + DumpState *s) >> +{ >> + RAMBlock *block; >> + target_phys_addr_t offset = s->memory_offset; >> + int64_t size_in_block, start; >> + >> + if (s->has_filter) { >> + if (phys_addr < s->begin || phys_addr >= s->begin + s->length) { >> + return -1; >> + } >> + } >> + >> + QLIST_FOREACH(block, &ram_list.blocks, next) { >> + if (s->has_filter) { >> + if (block->offset >= s->begin + s->length || >> + block->offset + block->length <= s->begin) { >> + /* This block is out of the range */ >> + continue; >> + } >> + >> + if (s->begin <= block->offset) { >> + start = block->offset; >> + } else { >> + start = s->begin; >> + } >> + >> + size_in_block = block->length - (start - block->offset); >> + if (s->begin + s->length < block->offset + block->length) { >> + size_in_block -= block->offset + block->length - >> + (s->begin + s->length); >> + } >> + } else { >> + start = block->offset; >> + size_in_block = block->length; >> + } >> + >> + if (phys_addr >= start && phys_addr < start + size_in_block) { >> + return phys_addr - start + offset; >> + } >> + >> + offset += size_in_block; >> + } >> + >> + return -1; >> +} > > OK. -1 is assigned to offset when the corresponding memory is filtered > and so not contained in dumpfile. But please give -1 a name. I want > the name to tell me the data is filterred. > > Also, I couldn't imagine get_offset() does filtering processing. This > is important for the purspective of dump because there's data not > saved in dumpfile. Could you claify this in some way? By moving > filtering processing to the outside, or splitting it into anotehr > funciton. offset should not be -1. I remove the PT_LOAD in the function memory_mapping_filter(). In the previous patchset, Luiz said he wants to squash the filtering feature to this patch. Thanks Wen Congyang > > Thanks. > HATAYAMA, Daisuke > >