On 03/06/2024 3:59 pm, Matthew Barnes wrote: > xen-hvmcrash would previously save records, overwrite the instruction > pointer with a bogus value, and then restore them to crash a domain > just enough to cause the guest OS to memdump. > > This approach is found to be unreliable when tested on a guest running > Windows 10 x64, with some executions doing nothing at all. > > Another approach would be to trigger NMIs. This approach is found to be > unreliable when tested on Linux (Ubuntu 22.04), as Linux will ignore > NMIs if it is not configured to handle such. > > Injecting a double fault abort to all vCPUs is found to be more > reliable at crashing and invoking memdumps from Windows and Linux > domains.
Why every CPU? We never did that before, and I don't see any it ought to be necessary now either. > diff --git a/tools/misc/xen-hvmcrash.c b/tools/misc/xen-hvmcrash.c > index 1d058fa40a47..8ef1beb388f8 100644 > --- a/tools/misc/xen-hvmcrash.c > +++ b/tools/misc/xen-hvmcrash.c > @@ -38,22 +38,21 @@ > #include <sys/stat.h> > #include <arpa/inet.h> > > +#define XC_WANT_COMPAT_DEVICEMODEL_API Please don't introduce this. We want to purge it from the codebase, not propagate it. You want to open and use a libxendevicemodel handle. (Sadly you also need a xenctrl handle too, until we sort out the userspace ABIs). > #include <xenctrl.h> > #include <xen/xen.h> > #include <xen/domctl.h> > #include <xen/hvm/save.h> > > +#define X86_ABORT_DF 8 #include <xen/asm/x86-defns.h> and use X86_EXC_DF. ~Andrew
