On Fri, Apr 28, 2017 at 4:28 PM, Marc-André Lureau <marcandre.lur...@gmail.com> wrote: > Hi > > On Fri, Apr 28, 2017 at 6:12 PM Ladi Prosek <lpro...@redhat.com> wrote: >> >> On Mon, Apr 24, 2017 at 3:03 PM, Marc-André Lureau >> <marcandre.lur...@redhat.com> wrote: >> > The VM coreinfo (vmcoreinfo) device is an emulated device which >> > exposes a 4k memory range to the guest to store various informations >> > useful to debug the guest OS. (it is greatly inspired by the VMGENID >> > device implementation) >> > >> > This is an early-boot alternative to the qemu-ga VMDUMP_INFO event >> > proposed in "[PATCH 00/21] WIP: dump: add kaslr support". >> > >> > If deemed more appropriate, we can consider writing to fw_cfg directly >> > instead of guest memory, now that qemu 2.9 supports it again. >> > >> > The proof-of-concept kernel module: >> > https://github.com/elmarco/vmgenid-test/blob/master/qemuvmci-test.c >> >> Here's a proof-of-concept Windows driver: >> >> https://github.com/ladipro/kvm-guest-drivers-windows/tree/vmcoreinfo/vmcoreinfo >> >> I just wanted to be sure that it's possible to evaluate the ADDR >> method in Windows. >> >> From a practical point of view it is unfortunate that this would be a >> completely new device. For Windows guests it means another driver >> binary and all the overhead associated with deploying it on VMs. Would >> it be too crazy to add this functionality to the pvpanic device? The >> mechanics could stay the same but it would be done under the existing >> ACPI\QEMU0001 device. > > > pvpanic is under _SB.PCI0.ISA, that could be problematic > > and _STA is a name field. > > Someone with more experience with ACPI could tell us if that make sense to > merge both and how. > > Can't you handle 2 ACPI devices in the same windows driver instead?
It can be done but it's uncommon for one driver to drive two different devices so it would probably be confusing. >> > +Storage Format: >> > +--------------- >> > + >> > +The content is expected to use little-endian format. >> > + >> > +In order to implement an OVMF "SDT Header Probe Suppressor", the >> > contents of >> > +the vmcoreinfo blob has 40 bytes of padding: >> > + >> > ++-----------------------------------+ >> > +| SSDT with OEM Table ID = VMCOREIN | >> > ++-----------------------------------+ >> > +| ... | TOP OF PAGE >> > +| VCIA dword object ----------------|-----> >> > +---------------------------+ >> > +| ... | | fw-allocated array for >> > | >> > +| _STA method referring to VCIA | | "etc/vmcoreinfo" >> > | >> > +| ... | >> > +---------------------------+ >> > +| ADDR method referring to VCIA | | 0: OVMF SDT Header probe >> > | >> > +| ... | | suppressor >> > | >> > ++-----------------------------------+ | 40: uint32 version field >> > | >> > + | 44: info contents >> > | >> > + | .... >> > | >> > + >> > +---------------------------+ >> > + END OF PAGE >> > + >> > +Version 0 content: >> > + >> > + uint64 paddr: >> > + Physical address of the Linux vmcoreinfo ELF note. >> >> Or physical address of the Windows crash dump header :p > > > Is there support for Windows crash dump in qemu? Not yet :) We want to add it soon-ish. For QEMU (or libvirt?) to be able to create Windows crash dump out of a raw guest physical memory dump, it needs to know the "header", a page-sized datastructure which Windows exposes via a kernel API. So the idea is that we would use the same mechanism as Linux for its KASLR dump support. >> >> Do we want to have an additional discriminator field to tell what kind >> of information was written by the guest or would Windows use a >> different version? >> > > I guess a different version would be ok. > > Thanks a lot for looking at it! > -- > Marc-André Lureau Thank you! Ladi
