evel On Behalf Of
Paolo Bonzini
Sent: Tuesday, May 17, 2022 7:12 AM
To: Ivan Shcherbakov ; qemu-devel@nongnu.org
Subject: Re: [PATCH] whpx: Added support for saving/restoring VM state
On 5/16/22 20:44, Ivan Shcherbakov wrote:
> Passing it to x86_cpu_xrstor_all_areas()/x86_cpu_xsave_all_area
Hi Paolo,
>What are the differences? Is it using the XSAVEC/XSAVES ("compacted") format?
I am not very familiar with the format internals, so I briefly checked whether
I could reuse the general logic from the HVF port. Here's what I got on a
booted Linux VM:
WHvGetVirtualProcessorXsaveState()
the XSAVE format differences between the WHPX API and
QEMU, the XSAVE state captured from WHPX is not reflected in the X86CPU
structure, and is instead saved to the snapshots "as is".
Signed-off-by: Ivan Shcherbakov
---
target/i386/cpu.h| 2 +-
target/i386/whpx/w
hat due to the XSAVE format differences between the WHPX API and
QEMU, the XSAVE state captured from WHPX is not reflected in the X86CPU
structure, and is instead saved to the snapshots "as is".
Signed-off-by: Ivan Shcherbakov
---
target/i386/cpu.h| 2 +-
target/
stepping when debugging
WHPX-accelerated guests with gdb.
It enables reliable debugging of the Linux kernel in both single-CPU and SMP
modes.
Signed-off-by: Ivan Shcherbakov
---
gdbstub.c | 10 +-
include/sysemu/accel-ops.h| 1 +
include/sysemu/runstate.h
Hi Alex,
Is there anything I could do to get the WHPX debugging support accepted into
QEMU? Would the proposed callback AccelOpsClass work for you, or would you
prefer another approach?
Best,
Ivan
-Original Message-
From: Qemu-devel On Behalf Of
Ivan Shcherbakov
Sent: Monday
ber to AccelOpsClass would be a safer bet. But again, if you think
another way to do it is better, I am very open to it.
Best regards,
Ivan
-Original Message-
From: Alex Bennée
Sent: Monday, February 28, 2022 2:28 AM
To: Ivan Shcherbakov
Cc: 'Peter Maydell' ; 'Pa
suggestions. You obviously know the QEMU codebase
much better, so I'm happy to refactor it so that it blends in well with the
rest of the code.
Best,
Ivan
-Original Message-
From: Qemu-devel On Behalf Of
Ivan Shcherbakov
Sent: Thursday, February 24, 2022 7:54 AM
To: 'Alex Bennée
> I haven't looked at the rest of the patch -- but can you explain where
> whpx is different from how other accelerators handle debug such that
> it needs to know whether gdb is connected or not ?
This mainly comes from the way single-stepping is handled. WHPX needs to know
whether you want to t
with gdb.
It enables reliable debugging of the Linux kernel in both single-CPU and SMP
modes.
Signed-off-by: Ivan Shcherbakov
---
gdbstub.c| 10 +
include/exec/gdbstub.h | 8 +
target/i386/whpx/whpx-all.c | 763 ++-
targ
This adds support for breakpoints and stepping when debugging
WHPX-accelerated guests with gdb.
It enables reliable debugging of the Linux kernel in both single-CPU and SMP
modes.
Signed-off-by: Ivan Shcherbakov
---
gdbstub.c| 10 +
include/exec/gdbstub.h
guest context.
Signed-off-by: Ivan Shcherbakov
---
target/i386/whpx/whpx-all.c | 49 +++--
1 file changed, 41 insertions(+), 8 deletions(-)
diff --git a/target/i386/whpx/whpx-all.c b/target/i386/whpx/whpx-all.c
index edd4fafbdf..8a8b5d55d1 100644
--- a/target/i386
flag in env->hflags (see x86_update_hflags() in
target/i386/cpu.c).
Without it, the code in gdbstub.c would only use the 32-bit register values
when debugging 64-bit targets, making debugging effectively impossible.
Signed-off-by: Ivan Shcherbakov
---
target/i386/whpx/whpx-all.c | 2 ++
1 f
13 matches
Mail list logo
