qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v5 01/23] memattrs: add debug attribute


From: Brijesh Singh
Subject: Re: [Qemu-devel] [PATCH v5 01/23] memattrs: add debug attribute
Date: Thu, 7 Dec 2017 15:20:14 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0


On 12/06/2017 04:03 PM, Peter Maydell wrote:
On 6 December 2017 at 20:03, Brijesh Singh <address@hidden> 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 <address@hidden>
Cc: Peter Maydell <address@hidden>
Cc: Edgar E. Iglesias" <address@hidden>
Cc: Richard Henderson <address@hidden>
Cc: Paolo Bonzini <address@hidden>
Signed-off-by: Brijesh Singh <address@hidden>
---
  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?


Sure, I will add more details. The flag is mainly used to distinguish the debug vs non debug access when using address_space_read/write/rw().

If a debug=1 is set then flatview_read(), flatview_write(), flatview_rw() will use the encryption APIs when accessing the guest RAM case. Since the MMIO regions are not encrypted with guest-specific keys hence we don't need to do anything special for the MMIO cases.


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?


Sorry I am not able to understand "if a device gets a debug=1 transition" comment, Can you please explain me a bit more. If you give me example on how to trigger this type of request with debug=1 then I can look into the code and see what we can do when memory encryption is enabled. The things like read-clears-bits semantics will be tricky.


thanks
-- PMM




reply via email to

[Prev in Thread] Current Thread [Next in Thread]