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: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v4 2/8] acpi: add vmcoreinfo device
Date: Sat, 15 Jul 2017 02:09:52 +0300

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.

BTW why does it pass ELF header size? Any idea?


> -- 
> Marc-André Lureau



reply via email to

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