1================= 2VMCoreInfo device 3================= 4 5The ``-device vmcoreinfo`` will create a ``fw_cfg`` entry for a guest to 6store dump details. 7 8``etc/vmcoreinfo`` 9================== 10 11A guest may use this ``fw_cfg`` entry to add information details to QEMU 12dumps. 13 14The entry of 16 bytes has the following layout, in little-endian:: 15 16 #define VMCOREINFO_FORMAT_NONE 0x0 17 #define VMCOREINFO_FORMAT_ELF 0x1 18 19 struct FWCfgVMCoreInfo { 20 uint16_t host_format; /* formats host supports */ 21 uint16_t guest_format; /* format guest supplies */ 22 uint32_t size; /* size of vmcoreinfo region */ 23 uint64_t paddr; /* physical address of vmcoreinfo region */ 24 }; 25 26Only full write (of 16 bytes) are considered valid for further 27processing of entry values. 28 29A write of 0 in ``guest_format`` will disable further processing of 30vmcoreinfo entry values & content. 31 32You may write a ``guest_format`` that is not supported by the host, in 33which case the entry data can be ignored by QEMU (but you may still 34access it through a debugger, via ``vmcoreinfo_realize::vmcoreinfo_state``). 35 36Format & content 37================ 38 39As of QEMU 2.11, only ``VMCOREINFO_FORMAT_ELF`` is supported. 40 41The entry gives location and size of an ELF note that is appended in 42qemu dumps. 43 44The note format/class must be of the target bitness and the size must 45be less than 1Mb. 46 47If the ELF note name is ``VMCOREINFO``, it is expected to be the Linux 48vmcoreinfo note (see `the kernel documentation for its format 49<https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-kernel-vmcoreinfo>`_). 50In this case, qemu dump code will read the content 51as a key=value text file, looking for ``NUMBER(phys_base)`` key 52value. The value is expected to be more accurate than architecture 53guess of the value. This is useful for KASLR-enabled guest with 54ancient tools not handling the ``VMCOREINFO`` note. 55