qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Eric Blake <eblake@redhat.com>
Cc: Laurent Desnogues <laurent.desnogues@gmail.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [PATCH] memory: Replace DEBUG_UNASSIGNED printf calls by trace events
Date: Fri, 20 Sep 2019 16:29:39 +0200	[thread overview]
Message-ID: <f817b9a4-272e-c4c0-a4c4-5b5ebd7fd917@redhat.com> (raw)
In-Reply-To: <CAFEAcA981SOP7UqgXYcTt1s29TfiUwxWc9GoJd+m+BO4WHrz_g@mail.gmail.com>

On 9/20/19 4:19 PM, Peter Maydell wrote:
> On Fri, 20 Sep 2019 at 15:12, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
>>
>> Now that the unassigned_access CPU hooks have been removed,
>> the unassigned_mem_read/write functions are only used for
>> debugging purpose.
>> Simplify by converting them to in-place trace events.
>>
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>> ---
>> Based-on: <20190920125008.13604-1-peter.maydell@linaro.org>
>> https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg04668.html
>> https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03705.html
>>
>> I first wrote:
>>
>>   These functions are declared using the CPUReadMemoryFunc/
>>   CPUWriteMemoryFunc prototypes. Since it is confusing to
>>   have such prototype only use for debugging, convert them
>>   to in-place trace events.
>>
>> But it doesn't provide helpful information and is rather confusing.
>>
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>> @@ -1437,7 +1418,8 @@ MemTxResult memory_region_dispatch_read(MemoryRegion *mr,
>>      MemTxResult r;
>>
>>      if (!memory_region_access_valid(mr, addr, size, false, attrs)) {
>> -        *pval = unassigned_mem_read(mr, addr, size);
>> +        trace_memory_region_invalid_read(size, addr);
>> +        *pval = 0; /* FIXME now this value shouldn't be accessed in guest */
> 
> This FIXME comment is not entirely correct.
> 
> Unassigned memory will RAZ/WI and the 0 will be seen by:
>  * guest CPUs which don't implement a do_transaction_failed hook
>    (or which have a hook that doesn't always raise an exception)

OK, I thought targets always had to implement do_transaction_failed.

>  * other transaction masters, such as DMA controllers, if they
>    choose to ignore the MemTxResult (or use an API that doesn't
>    expose the MemTxResult)

Didn't think about this one. OK.

I'll replace my FIXME by your 2 comments to make it clear.

>> diff --git a/trace-events b/trace-events
>> index 823a4ae64e..83dbeb4b46 100644
>> --- a/trace-events
>> +++ b/trace-events
>> @@ -62,6 +62,8 @@ memory_region_tb_read(int cpu_index, uint64_t addr, uint64_t value, unsigned siz
>>  memory_region_tb_write(int cpu_index, uint64_t addr, uint64_t value, unsigned size) "cpu %d addr 0x%"PRIx64" value 0x%"PRIx64" size %u"
>>  memory_region_ram_device_read(int cpu_index, void *mr, uint64_t addr, uint64_t value, unsigned size) "cpu %d mr %p addr 0x%"PRIx64" value 0x%"PRIx64" size %u"
>>  memory_region_ram_device_write(int cpu_index, void *mr, uint64_t addr, uint64_t value, unsigned size) "cpu %d mr %p addr 0x%"PRIx64" value 0x%"PRIx64" size %u"
>> +memory_region_invalid_read(unsigned size, uint64_t addr) "invalid read size %u addr 0x%"PRIx64
>> +memory_region_invalid_write(unsigned size, uint64_t addr, int fmt_width, uint64_t value) "invalid write size %u addr 0x%"PRIx64" value 0x%0*"PRIx64
> 
> Do all our trace backends support format strings which use the
> "dynamic format width specified via '*'" syntax ?

I thought I read a comment about it between Eric/Stefan but I can't find
it, maybe I dreamed it. (Cc'ed Eric).

Regards,

Phil.


  reply	other threads:[~2019-09-20 14:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-20 14:12 [PATCH] memory: Replace DEBUG_UNASSIGNED printf calls by trace events Philippe Mathieu-Daudé
2019-09-20 14:17 ` Paolo Bonzini
2019-09-20 14:20   ` Peter Maydell
2019-10-08 20:40     ` Palmer Dabbelt
2019-10-08 20:41       ` Alistair Francis
2019-10-08 20:52         ` Alistair Francis
2019-09-20 14:19 ` Peter Maydell
2019-09-20 14:29   ` Philippe Mathieu-Daudé [this message]
2019-09-20 14:35     ` Peter Maydell
2019-09-20 14:39       ` Philippe Mathieu-Daudé
2019-09-20 15:01         ` Eric Blake
2019-09-20 16:03           ` Philippe Mathieu-Daudé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f817b9a4-272e-c4c0-a4c4-5b5ebd7fd917@redhat.com \
    --to=philmd@redhat.com \
    --cc=eblake@redhat.com \
    --cc=laurent.desnogues@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).