qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Marc-André Lureau" <marcandre.lureau@gmail.com>
Cc: Laszlo Ersek <lersek@redhat.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	QEMU <qemu-devel@nongnu.org>, Paolo Bonzini <pbonzini@redhat.com>,
	Dave Anderson <anderson@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v4 2/8] acpi: add vmcoreinfo device
Date: Sat, 15 Jul 2017 02:40:53 +0300	[thread overview]
Message-ID: <20170715023159-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAJ+F1CJP2DSo-khn+do0YG_ALDXrqBi6wEPH=m+W59rPfRTuiA@mail.gmail.com>

On Sat, Jul 15, 2017 at 01:30:56AM +0200, Marc-André Lureau wrote:
> Hi
> 
> On Sat, Jul 15, 2017 at 1:09 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Sat, Jul 15, 2017 at 12:12:06AM +0200, Marc-André Lureau wrote:
> > > Hi
> > >
> > > On Fri, Jul 14, 2017 at 10:17 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > On Fri, Jul 14, 2017 at 10:04:31PM +0200, Laszlo Ersek wrote:
> > > >> > It worries me that the format of this seems completely undefined
> > > >> > except in the patchset cover letter.
> > > >> > I don't think we should merge this before it is.
> > > >>
> > > >> I'm not sure what you mean, this patch adds "docs/specs/vmcoreinfo.txt".
> > > >> That file is the first level contract between the guest firmware
> > > >> (generally, via the linker/loader), the guest kernel driver
> > > >> (specifically), and QEMU (also specifically).
> > > >>
> > > >> The second level contract is the guest kernel's vmcoreinfo ELF note
> > > >> (which is pointed-to by the first level contract). The layout of that is
> > > >> specified elsewhere indeed (I don't think it belongs here).
> > > >>
> > > >> We've taken care not to trust anything coming from the guest kernel.
> > > >>
> > > >> Can you clarify please?
> > > >>
> > > >> Thanks
> > > >> Laszlo
> > > >
> > > > All there is is this:
> > > >
> > > > +Version 0 content:
> > > > +
> > > > + uint64 paddr:
> > > > +  Physical address of the Linux vmcoreinfo ELF note.
> > > > + uint32 size:
> > > > +  Size of the vmcoreinfo ELF note.
> > > >
> > > > It isn't defined here what is the Linux vmcoreinfo ELF note.
> > > > You want a bit more info so people trying to use it know where to start
> > > > and what they can get out of it.
> > >
> > > QEMU is not responsible for the content of the ELF note. All there is afaik is:
> > >
> > > https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-kernel-vmcoreinfo
> > >
> > > The rest you need to dig in the kernel code and git history I think.
> >
> > We need to do a good enough job to at least make it possible for people
> > to make use of it without reading your python code.
> >
> > Documentation/kdump/kdump.txt has a bit more information.
> >
> >         All of the necessary information about the system kernel's core image is
> >         encoded in the ELF format, and stored in a reserved area of memory
> >         before a crash. The physical address of the start of the ELF header is
> >         passed to the dump-capture kernel through the elfcorehdr= boot
> >         parameter. Optionally the size of the ELF header can also be passed
> >         when using the elfcorehdr=[size[KMG]@]offset[KMG] syntax.
> >
> >
> >         With the dump-capture kernel, you can access the memory image through
> >         /proc/vmcore. This exports the dump as an ELF-format file that you can
> >         write out using file copy commands such as cp or scp. Further, you can
> >         use analysis tools such as the GNU Debugger (GDB) and the Crash tool to
> >         debug the dump file. This method ensures that the dump pages are correctly
> >         ordered.
> >
> > I know where to find it but most people likely won't be able to.
> >
> 
> What do you learn from that regarding vmcoreinfo? That is it being
> used by kdump? and that you can use gdb/crash, that we already use to
> analyse our dumps.

Some things I learn:

That its written by a dump-capture kernel (so you need to set one up
if you want it to work!).

That it's an ELF-format file, that one can use analysis tools such as
the GNU Debugger (GDB) and the Crash tool to debug the dump file.

There's more info scattered in other places.

Why do you get to document it? Because you are the one exposing it
across the hypervisor/vm boundary where it will need to be
understood by people/tools not running within guest.

So "just read the script in qemu source" is not how an interface
should be documented.

> >
> > BTW why does it pass ELF header size? Any idea?
> 
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d3bf37955d46718ee1a7f1fc69f953d2328ba7c2

Right but I mean, ELF header has two options: 32 and 64 bit, that's all.

-- 
MST

  reply	other threads:[~2017-07-14 23:41 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-14 18:20 [Qemu-devel] [PATCH v4 0/8] KASLR kernel dump support Marc-André Lureau
2017-07-14 18:20 ` [Qemu-devel] [PATCH v4 1/8] vmgenid: replace x-write-pointer-available hack Marc-André Lureau
2017-07-14 19:19   ` Michael S. Tsirkin
2017-07-14 18:20 ` [Qemu-devel] [PATCH v4 2/8] acpi: add vmcoreinfo device Marc-André Lureau
2017-07-14 19:26   ` Michael S. Tsirkin
2017-07-14 20:04     ` Laszlo Ersek
2017-07-14 20:17       ` Michael S. Tsirkin
2017-07-14 22:12         ` Marc-André Lureau
2017-07-14 23:09           ` Michael S. Tsirkin
2017-07-14 23:30             ` Marc-André Lureau
2017-07-14 23:40               ` Michael S. Tsirkin [this message]
2017-07-14 23:47                 ` Marc-André Lureau
2017-07-26 17:21                   ` Michael S. Tsirkin
2017-07-28 14:52                     ` Marc-André Lureau
2017-07-28 15:55                       ` Laszlo Ersek
2017-08-07 15:44                       ` Dave Anderson
2017-07-14 18:20 ` [Qemu-devel] [PATCH v4 3/8] stubs: add vmcoreinfo_get() stub Marc-André Lureau
2017-07-14 20:09   ` Laszlo Ersek
2017-07-14 18:20 ` [Qemu-devel] [PATCH v4 4/8] tests: add simple vmcoreinfo test Marc-André Lureau
2017-07-14 20:10   ` Laszlo Ersek
2017-07-14 18:20 ` [Qemu-devel] [PATCH v4 5/8] dump: add vmcoreinfo ELF note Marc-André Lureau
2017-07-14 18:20 ` [Qemu-devel] [PATCH v4 6/8] kdump: " Marc-André Lureau
2017-07-14 18:20 ` [Qemu-devel] [PATCH v4 7/8] scripts/dump-guest-memory.py: add vmcoreinfo Marc-André Lureau
2017-07-14 18:20 ` [Qemu-devel] [PATCH v4 8/8] MAINTAINERS: add Dump maintainers Marc-André Lureau
2017-07-14 19:59 ` [Qemu-devel] [PATCH v4 0/8] KASLR kernel dump support Michael S. Tsirkin
2017-07-14 20:21   ` Laszlo Ersek
2017-07-14 22:23     ` Michael S. Tsirkin
2017-07-14 22:31       ` Marc-André Lureau
2017-07-14 23:29         ` Michael S. Tsirkin
2017-07-18 13:29           ` Marc-André Lureau
2017-07-18 16:05             ` Ladi Prosek
2017-07-18 16:18               ` Marc-André Lureau
2017-07-19  6:06                 ` Ladi Prosek
2017-07-14 23:36 ` no-reply

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=20170715023159-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=anderson@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=lersek@redhat.com \
    --cc=marcandre.lureau@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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).