qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: robert.foley@linaro.org, Paolo Bonzini <pbonzini@redhat.com>,
	qemu-devel@nongnu.org, robhenry@microsoft.com,
	aaron@os.amperecomputing.com, cota@braap.org,
	kuhn.chenqun@huawei.com, peter.puhov@linaro.org
Subject: Re: [PATCH v1 5/9] cputlb: ensure we re-fill the TLB if it has reset
Date: Tue, 02 Jun 2020 17:56:56 +0100	[thread overview]
Message-ID: <87h7vt76ef.fsf@linaro.org> (raw)
In-Reply-To: <d27ce2e9-f6a3-0f54-83ed-888d731002fb@linaro.org>


Richard Henderson <richard.henderson@linaro.org> writes:

> On 6/2/20 8:46 AM, Alex Bennée wrote:
>> Any write to a device might cause a re-arrangement of memory
>> triggering a TLB flush and potential re-size of the TLB invalidating
>> previous entries. This would cause users of qemu_plugin_get_hwaddr()
>> to see the warning:
>> 
>>   invalid use of qemu_plugin_get_hwaddr
>> 
>> because of the failed tlb_lookup which should always succeed. We catch
>> this case by checking to see if the list of entries has been cleared
>> and if so triggering a re-fill.
>> 
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> ---
>>  accel/tcg/cputlb.c | 14 ++++++++++++++
>>  1 file changed, 14 insertions(+)
>> 
>> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
>> index eb2cf9de5e6..b7d329f7155 100644
>> --- a/accel/tcg/cputlb.c
>> +++ b/accel/tcg/cputlb.c
>> @@ -1091,6 +1091,20 @@ static void io_writex(CPUArchState *env, CPUIOTLBEntry *iotlbentry,
>>                                 MMU_DATA_STORE, mmu_idx, iotlbentry->attrs, r,
>>                                 retaddr);
>>      }
>> +
>> +    /*
>> +     * The memory_region_dispatch may have triggered a flush/resize
>> +     * so for plugins we need to ensure we have reset the tlb_entry
>> +     * so any later lookup is correct.
>> +     */
>> +#ifdef CONFIG_PLUGIN
>> +    if (env_tlb(env)->d[mmu_idx].n_used_entries == 0) {
>> +        int size = op & MO_SIZE;
>> +        tlb_fill(env_cpu(env), addr, size, MMU_DATA_STORE,
>> +                 mmu_idx, retaddr);
>
> Ouch.  What if the target has a soft tlb fill, so this requires a call into the
> OS, so this fill actually raises another exception?  This will not be happy fun
> making.
>
> I recall I had objections to recording this translation, saying that "we can
> always get it back again".  Clearly I was wrong, and we should just preserve
> the required CPUTLBEntry details before they're lost by a device.

Maybe we could just RCU the old TLB if it gets flushed thus ensuring the
whole TLB is preserved until after the critical section (i.e. between
the actual store and looking it up). However I don't know if the
MemoryRegion will be similarly preserved.

Paolo?

>
>
> r~


-- 
Alex Bennée


  reply	other threads:[~2020-06-02 16:58 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-02 15:46 [PATCH v1 0/9] plugins/next (bug fixes, hwprofile, lockstep) Alex Bennée
2020-06-02 15:46 ` [PATCH v1 1/9] plugins: new lockstep plugin for debugging TCG changes Alex Bennée
2020-06-02 15:46 ` [PATCH v1 2/9] qemu-plugin.h: add missing include <stddef.h> to define size_t Alex Bennée
2020-06-02 15:46 ` [PATCH v1 3/9] scripts/clean-includes: Mark 'qemu/qemu-plugin.h' as special header Alex Bennée
2020-06-02 15:46 ` [PATCH v1 4/9] tests/plugin: correctly honour io_count Alex Bennée
2020-06-02 17:07   ` Philippe Mathieu-Daudé
2020-06-02 15:46 ` [PATCH v1 5/9] cputlb: ensure we re-fill the TLB if it has reset Alex Bennée
2020-06-02 16:34   ` Richard Henderson
2020-06-02 16:56     ` Alex Bennée [this message]
2020-06-02 15:46 ` [PATCH v1 6/9] hw/virtio/pci: include vdev name in registered PCI sections Alex Bennée
2020-06-02 15:59   ` Philippe Mathieu-Daudé
2020-06-04 11:35   ` Michael S. Tsirkin
2020-06-02 15:46 ` [PATCH v1 7/9] plugins: add API to return a name for a IO device Alex Bennée
2020-06-02 16:06   ` Clement Deschamps
2020-06-08  3:45   ` Emilio G. Cota
2020-06-08  6:20     ` Philippe Mathieu-Daudé
2020-06-08  8:06     ` Alex Bennée
2020-06-09  4:09       ` Emilio G. Cota
2020-06-09 11:09         ` Alex Bennée
2020-06-10  2:32           ` Emilio G. Cota
2020-06-02 15:46 ` [PATCH v1 8/9] plugins: new hwprofile plugin Alex Bennée
2020-06-02 19:16   ` Robert Foley
2020-06-03 11:43     ` Alex Bennée
2020-06-03 15:42       ` Robert Foley
2020-06-03 17:26         ` Alex Bennée
2020-06-03 15:48   ` Peter Maydell
2020-06-03 17:23     ` Alex Bennée
2020-06-02 15:46 ` [PATCH v1 9/9] .travis.yml: allow failure for unreliable hosts Alex Bennée
2020-06-03  8:18   ` Philippe Mathieu-Daudé
2020-06-03 12:40     ` Philippe Mathieu-Daudé
2020-06-11 11:20   ` Thomas Huth
2020-06-02 17:03 ` [PATCH v1 0/9] plugins/next (bug fixes, hwprofile, lockstep) no-reply
2020-06-02 19:16 ` no-reply

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=87h7vt76ef.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=aaron@os.amperecomputing.com \
    --cc=cota@braap.org \
    --cc=kuhn.chenqun@huawei.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.puhov@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=robert.foley@linaro.org \
    --cc=robhenry@microsoft.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).