On 6 December 2017 at 20:03, Brijesh Singh <[email protected]> wrote: > The debug attribute will be set when qemu attempts to access the guest > memory for debug (e.g memory access from gdbstub, memory dump commands > etc). > > When guest memory is encrypted, the debug access will need to go through > the memory encryption APIs. > > Cc: Alistair Francis <[email protected]> > Cc: Peter Maydell <[email protected]> > Cc: Edgar E. Iglesias" <[email protected]> > Cc: Richard Henderson <[email protected]> > Cc: Paolo Bonzini <[email protected]> > Signed-off-by: Brijesh Singh <[email protected]> > --- > include/exec/memattrs.h | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/include/exec/memattrs.h b/include/exec/memattrs.h > index d4a16420984b..721362e06292 100644 > --- a/include/exec/memattrs.h > +++ b/include/exec/memattrs.h > @@ -37,6 +37,8 @@ typedef struct MemTxAttrs { > unsigned int user:1; > /* Requester ID (for MSI for example) */ > unsigned int requester_id:16; > + /* Debug memory access for encrypted guest */ > + unsigned int debug:1; > } MemTxAttrs;
Can we have some more detailed semantics for this please? For instance, if a device gets a debug=1 transaction should it refuse to do things like read-clears-bits semantics or other side-effects you wouldn't expect of debugger accesses? thanks -- PMM
