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.

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;
 } MemTxAttrs;
 
 /* Bus masters which don't specify any attributes will get this,
-- 
2.17.1

* 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
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

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
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

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
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK