On 6 December 2017 at 20:03, Brijesh Singh <brijesh.singh@xxxxxxx> 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 <alistair.francis@xxxxxxxxxx>
> Cc: Peter Maydell <peter.maydell@xxxxxxxxxx>
> Cc: Edgar E. Iglesias" <edgar.iglesias@xxxxxxxxxx>
> Cc: Richard Henderson <richard.henderson@xxxxxxxxxx>
> Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
> Signed-off-by: Brijesh Singh <brijesh.singh@xxxxxxx>
> ---
> 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
