From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2eOU-0005cn-My for qemu-devel@nongnu.org; Mon, 13 Jan 2014 05:05:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W2eOO-0000Z7-IP for qemu-devel@nongnu.org; Mon, 13 Jan 2014 05:05:18 -0500 Received: from [222.73.24.84] (port=48947 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2eOO-0000PV-7L for qemu-devel@nongnu.org; Mon, 13 Jan 2014 05:05:12 -0500 Message-ID: <52D3B9F6.3070804@cn.fujitsu.com> Date: Mon, 13 Jan 2014 18:03:34 +0800 From: Qiao Nuohan MIME-Version: 1.0 References: <1388906864-1083-1-git-send-email-qiaonuohan@cn.fujitsu.com> <1388906864-1083-7-git-send-email-qiaonuohan@cn.fujitsu.com> <52CBE72E.9070805@redhat.com> In-Reply-To: <52CBE72E.9070805@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v6 06/11] dump: add API to write dump header List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: stefanha@gmail.com, qemu-devel@nongnu.org, lcapitulino@redhat.com, anderson@redhat.com, kumagai-atsushi@mxc.nes.nec.co.jp, akong@redhat.com, afaerber@suse.de Sorry for responsing late. On 01/07/2014 07:38 PM, Laszlo Ersek wrote: > The following fields in "dh" are left zero-filled: > - timestamp > - total=5Fram=5Fblocks > - device=5Fblocks > - written=5Fblocks > - current=5Fcpu > > I guess we'll either overwrite them later or it's OK to leave them all > zeroed. Yes, they are leaved all zeroed here. Tools, like crash will get exact data from dumped memory. > > Also... is it OK to write these fields to the file in host native byte > order? What happens if an i686 / x86=5F64 target is emulated on a BE host? I will add convert work in v7. > >> > + >> > + /* write sub header */ >> > + size =3D sizeof(KdumpSubHeader32); >> > + kh =3D g=5Fmalloc0(size); >> > + >> > + /* 64bit max=5Fmapnr=5F64 */ >> > + kh->max=5Fmapnr=5F64 =3D s->max=5Fmapnr; >> > + kh->phys=5Fbase =3D PHYS=5FBASE; >> > + kh->dump=5Flevel =3D DUMP=5FLEVEL; >> > + >> > + kh->offset=5Fnote =3D DISKDUMP=5FHEADER=5FBLOCKS * dh->block=5Fs= ize + size; >> > + kh->note=5Fsize =3D s->note=5Fsize; >> > + >> > + if (write=5Fbuffer(s->fd, s->flag=5Fflatten, dh->block=5Fsize, k= h, size)< 0) { >> > + ret =3D -1; >> > + goto out; >> > + } > - Same question about endianness as above. > > - Again, many fields left zeroed in "kh", but I guess that's OK. > > - I would prefer if you repeated the multiplication by > DISKDUMP=5FHEADER=5FBLOCKS verbatim in the "offset" write=5Fbuffer() argu= ment. write=5Fbuffer(s->fd, s->flag=5Fflatten, DISKDUMP=5FHEADER=5FBLOCKS * dh->b= lock=5Fsize, kh, size) ? Yes, I should change it. > > - When this write=5Fbuffer() is directed to a regular file in non-flat > mode, then the file might become sparse (you jump over a range of > offsets with lseek() in write=5Fbuffer()). If the output has been opened > by qemu itself (ie."file:....", in qmp=5Fdump=5Fguest=5Fmemory()), then d= ue > to the O=5FTRUNC we can't seek over preexistent data (and keep garbage in > the file). When libvirt pre-opens the file (to send over the fd later), > in doCoreDump(), it also passes O=5FTRUNC. OK. > Do you mean because of O=5FTRUNC=EF=BC=8Cseek will exceed the end of the fi= le that may=20 cause some problem? --=20 Regards Qiao Nuohan =