qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 2/8] acpi: add vmcoreinfo device


From: Marc-André Lureau
Subject: Re: [Qemu-devel] [PATCH v4 2/8] acpi: add vmcoreinfo device
Date: Sat, 15 Jul 2017 01:30:56 +0200

Hi

On Sat, Jul 15, 2017 at 1:09 AM Michael S. Tsirkin <address@hidden> 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 <address@hidden> 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 address@hidden 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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]