On 12/8/17 3:55 AM, Peter Maydell wrote:
>> 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.
> The question was really whether we want to make this a general
> indicator of "this operation was triggered by a debugger" and
> expand that to mean "don't do things that mess with the state
> of the simulation unexpectedly", or if this is really a very
> encrypted-memory specific thing.
It can be used as a generic indicator that operation was triggered by a
debugger. There is not anything encryption specific. Having said that,
in the current patch series I have been only focused on making it work
from the gdbstub and HMP point of view. The debug=1 from gdbstub and HMP
is tested on both encrypted and non-encrypted guest. If we decide to
extend to support other callers (device model etc) then we may need to
update memory load/store functions defined in memory_ldst_inc.c to work
with debug=1.
> By the way, I don't think this:
>
>> /* Access the guest memory for debug purposes */
>> #define MEMTXATTRS_DEBUG ((MemTxAttrs) { .debug = 1 })
> is a great idea. Callers that care about the transaction
> attributes should just specify them properly. MEMTXATTRS_UNSPECIFIED
> is a fallback for the large set of places that don't care at all.
OK, I will drop the macro and update the patches in the series to set
MemTxAttr.debug = 1 when we do debugger request. thanks
--Brijesh
