1================= 2VMCoreInfo device 3================= 4 5The `-device vmcoreinfo` will create a fw_cfg entry for a guest to 6store dump details. 7 8etc/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 Documentation/ABI/testing/sysfs-kernel-vmcoreinfo 49in Linux source). In this case, qemu dump code will read the content 50as a key=value text file, looking for "NUMBER(phys_base)" key 51value. The value is expected to be more accurate than architecture 52guess of the value. This is useful for KASLR-enabled guest with 53ancient tools not handling the VMCOREINFO note. 54