| Message ID | 2ba88b512ec667eff66b2ece2177330a28e657c0.1605316268.git.ashish.kalra@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add QEMU debug support for SEV guests | expand |
* Ashish Kalra (Ashish.Kalra@amd.com) wrote: > From: Brijesh Singh <brijesh.singh@amd.com> > > From: Brijesh Singh <brijesh.singh@amd.com> > > Extend the MemTxAttrs to include a 'debug' flag. The flag can be used as > general indicator that operation was triggered by the debugger. > > A subsequent patch will set the debug=1 when issuing a memory access > from the gdbstub or HMP commands. This is a prerequisite to support > debugging an encrypted guest. When a request with debug=1 is seen, the > encryption APIs will be used to access the guest memory. Is this also the flag that would be used for memory dumping? > Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> > Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> > --- > include/exec/memattrs.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/exec/memattrs.h b/include/exec/memattrs.h > index 95f2d20d55..c8b56389d6 100644 > --- a/include/exec/memattrs.h > +++ b/include/exec/memattrs.h > @@ -49,6 +49,8 @@ typedef struct MemTxAttrs { > unsigned int target_tlb_bit0 : 1; > unsigned int target_tlb_bit1 : 1; > unsigned int target_tlb_bit2 : 1; > + /* Memory access request from the debugger */ > + unsigned int debug:1; It might be good to clarify that this is for QEMU debug features, not guest side debug features (e.g. CPU debug facilities/registers) Dave > } MemTxAttrs; > > /* Bus masters which don't specify any attributes will get this, > -- > 2.17.1 >
On Mon, 16 Nov 2020 at 19:28, Ashish Kalra <Ashish.Kalra@amd.com> wrote: > > From: Brijesh Singh <brijesh.singh@amd.com> > > From: Brijesh Singh <brijesh.singh@amd.com> > > Extend the MemTxAttrs to include a 'debug' flag. The flag can be used as > general indicator that operation was triggered by the debugger. > > A subsequent patch will set the debug=1 when issuing a memory access > from the gdbstub or HMP commands. This is a prerequisite to support > debugging an encrypted guest. When a request with debug=1 is seen, the > encryption APIs will be used to access the guest memory. So, what counts as "debug" here, and why are debug requests special? If "debug=1" means "can actually get at the guest memory", why wouldn't every device model want to use it? thanks -- PMM
* Peter Maydell (peter.maydell@linaro.org) wrote: > On Mon, 16 Nov 2020 at 19:28, Ashish Kalra <Ashish.Kalra@amd.com> wrote: > > > > From: Brijesh Singh <brijesh.singh@amd.com> > > > > From: Brijesh Singh <brijesh.singh@amd.com> > > > > Extend the MemTxAttrs to include a 'debug' flag. The flag can be used as > > general indicator that operation was triggered by the debugger. > > > > A subsequent patch will set the debug=1 when issuing a memory access > > from the gdbstub or HMP commands. This is a prerequisite to support > > debugging an encrypted guest. When a request with debug=1 is seen, the > > encryption APIs will be used to access the guest memory. > > So, what counts as "debug" here, and why are debug requests > special? If "debug=1" means "can actually get at the guest memory", > why wouldn't every device model want to use it? SEV has a flag that the guest-owner can set on a VM to enable debug; it's rare for it to be enabled; so it's not suitable for use by normal devices. It's only there for debug if the guest owner allows you to. Dave > thanks > -- PMM >
On Tue, 1 Dec 2020 at 11:51, Dr. David Alan Gilbert <dgilbert@redhat.com> wrote: > > * Peter Maydell (peter.maydell@linaro.org) wrote: > > On Mon, 16 Nov 2020 at 19:28, Ashish Kalra <Ashish.Kalra@amd.com> wrote: > > > > > > From: Brijesh Singh <brijesh.singh@amd.com> > > > > > > From: Brijesh Singh <brijesh.singh@amd.com> > > > > > > Extend the MemTxAttrs to include a 'debug' flag. The flag can be used as > > > general indicator that operation was triggered by the debugger. > > > > > > A subsequent patch will set the debug=1 when issuing a memory access > > > from the gdbstub or HMP commands. This is a prerequisite to support > > > debugging an encrypted guest. When a request with debug=1 is seen, the > > > encryption APIs will be used to access the guest memory. > > > > So, what counts as "debug" here, and why are debug requests > > special? If "debug=1" means "can actually get at the guest memory", > > why wouldn't every device model want to use it? > > SEV has a flag that the guest-owner can set on a VM to enable debug; > it's rare for it to be enabled; so it's not suitable for use by normal > devices. It's only there for debug if the guest owner allows you to. So if I do a memory transaction with debug=1 then I should expect that it might come back with a failure status (meaning "this VM doesn't permit debug") and I should handle that error ? thanks -- PMM
* Peter Maydell (peter.maydell@linaro.org) wrote: > On Tue, 1 Dec 2020 at 11:51, Dr. David Alan Gilbert <dgilbert@redhat.com> wrote: > > > > * Peter Maydell (peter.maydell@linaro.org) wrote: > > > On Mon, 16 Nov 2020 at 19:28, Ashish Kalra <Ashish.Kalra@amd.com> wrote: > > > > > > > > From: Brijesh Singh <brijesh.singh@amd.com> > > > > > > > > From: Brijesh Singh <brijesh.singh@amd.com> > > > > > > > > Extend the MemTxAttrs to include a 'debug' flag. The flag can be used as > > > > general indicator that operation was triggered by the debugger. > > > > > > > > A subsequent patch will set the debug=1 when issuing a memory access > > > > from the gdbstub or HMP commands. This is a prerequisite to support > > > > debugging an encrypted guest. When a request with debug=1 is seen, the > > > > encryption APIs will be used to access the guest memory. > > > > > > So, what counts as "debug" here, and why are debug requests > > > special? If "debug=1" means "can actually get at the guest memory", > > > why wouldn't every device model want to use it? > > > > SEV has a flag that the guest-owner can set on a VM to enable debug; > > it's rare for it to be enabled; so it's not suitable for use by normal > > devices. It's only there for debug if the guest owner allows you to. > > So if I do a memory transaction with debug=1 then I should expect > that it might come back with a failure status (meaning "this VM > doesn't permit debug") and I should handle that error ? I think that's probably true. Dave > thanks > -- PMM >
diff --git a/include/exec/memattrs.h b/include/exec/memattrs.h index 95f2d20d55..c8b56389d6 100644 --- a/include/exec/memattrs.h +++ b/include/exec/memattrs.h @@ -49,6 +49,8 @@ typedef struct MemTxAttrs { unsigned int target_tlb_bit0 : 1; unsigned int target_tlb_bit1 : 1; unsigned int target_tlb_bit2 : 1; + /* Memory access request from the debugger */ + unsigned int debug:1; } MemTxAttrs; /* Bus masters which don't specify any attributes will get this,