On 7 December 2017 at 21:20, Brijesh Singh <[email protected]> wrote:
> On 12/06/2017 04:03 PM, Peter Maydell wrote:
>> 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.
A device model (eg a UART) can be written to look at the
MemTxAttrs that it's passed and behave differently if debug=1.
> 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.
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.
thanks
-- PMM
