From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Laurent Desnogues <laurent.desnogues@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [PATCH] memory: Replace DEBUG_UNASSIGNED printf calls by trace events
Date: Fri, 20 Sep 2019 16:39:24 +0200 [thread overview]
Message-ID: <a4c4f869-710d-930d-54f3-d43882cbb869@redhat.com> (raw)
In-Reply-To: <CAFEAcA9KAc4viUy1X6f=f9Xm=_+H_JDJh1+USOHyPG76v5f_jw@mail.gmail.com>
On 9/20/19 4:35 PM, Peter Maydell wrote:
> On Fri, 20 Sep 2019 at 15:29, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
>>
>> 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.
>
> No, and in fact most don't (only 8 out of 21 architectures have the hook).
> In some cases that might be that nobody's got around to it; in other
> cases if the RAZ/WI default and no guest CPU exception is what you want,
> there's no real need to write a hook function.
OK!
>>>> 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).
>
> If my grep is correct we currently use the syntax already in
> gt64120_read, gt64120_write, pflash_io_read, pflash_io_write,
> pflash_data_read and pflash_data_write trace events.
If you use 'git blame' you'll notice I added all of them, so better
let's get a proper confirmation from Stefan :)
I plan to use them more, I find them helpful to directly see the access
size looking at the value width.
Regards,
Phil.
next prev parent reply other threads:[~2019-09-20 14:53 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é
2019-09-20 14:35 ` Peter Maydell
2019-09-20 14:39 ` Philippe Mathieu-Daudé [this message]
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=a4c4f869-710d-930d-54f3-d43882cbb869@redhat.com \
--to=philmd@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).