All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru>
Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [PATCH] util/log: flush TB cache when log level changes
Date: Mon, 01 Feb 2021 08:46:50 +0000	[thread overview]
Message-ID: <87a6so186a.fsf@linaro.org> (raw)
In-Reply-To: <08a7b260-b787-9528-d96a-3b6d8879248b@ispras.ru>


Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru> writes:

> On 25.01.2021 14:09, Alex Bennée wrote:
>> 
>> Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru> writes:
>> 
>>> On 22.01.2021 14:42, Alex Bennée wrote:
>>>>
>>>> Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru> writes:
<snip>
>>>>>    #endif
>>>>> +    tb_flush_all();
>>>>> +
>>>>
>>>> I would call tb_flush(current_cpu) or first_cpu here. But two things:
>>>>
>>>>    - I'm not sure you have a CPU at all times qemu_set_log is called
>>>>    - It seems overly aggressive to throw away all translations every time
>>>>      the log level is changed. I would define a mask in log.h and have
>>>>      something like:
>>>
>>> Do you propose removing the parameter from tb_flush or omitting the loop
>>> from tb_flush_all?
>> 
>> No tb_flush should keep the CPU interface. In normal usage from the
>> emulation we always have a CPU to call. However for qemu_set_log you
>> will need to find a CPU to call or bail out if you can't. Maybe
>
> It the following true? We can't get rid of CPU in tb_flush, because 
> do_tb_flush must be executed in vCPU thread.
> Can one CPU break others execution in case of SMP? Can we move flush to 
> BH somehow?

The flush has to execute in the CPU context because it uses the
exclusive mechanism to ensure all other CPUs are currently quiescent
before doing the flush. Currently the exclusive mechanism is only aware
of CPU threads and extending it would be essentially re-introducing a
BQL.

>
>> something like:
>> 
>>    CPUStatus *cpu = current_cpu || first_cpu;
>>    if (cpu) {
>>        tb_flush(cpu);
>>    }
>> 
>
> Then we'll have to expose all this CPU stuff to utils and add stubs for 
> them.
>
>> my only worry is if qemu_set_log is called from outside a CPU context
>> (current_cpu will always be NULL) while first_cpu is in a exclusive
>> region. We could extend cpu_in_exclusive_context to be:
>> 
>>    cpu == current_cpu && cpu->in_exclusive_context
>> 
>> but that seems a little icky to me. Paolo, any thoughts?
>> 
>>>
>>>>     if (log_flags & LOG_TRANSLATION) {
>>>>         tb_flush();
>>>>     }
>>>>
>>>>>        /*
>>>>>         * In all cases we only log if qemu_loglevel is set.
>>>>>         * Also:
>>>>
>>>>
>> 
>> 


-- 
Alex Bennée


      reply	other threads:[~2021-02-01  8:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-22 10:03 [PATCH] util/log: flush TB cache when log level changes Pavel Dovgalyuk
2021-01-22 10:32 ` Philippe Mathieu-Daudé
2021-01-22 10:47   ` Pavel Dovgalyuk
2021-01-22 11:42 ` Alex Bennée
2021-01-22 14:05   ` Philippe Mathieu-Daudé
2021-01-25  6:52   ` Pavel Dovgalyuk
2021-01-25 11:09     ` Alex Bennée
2021-02-01  7:21       ` Pavel Dovgalyuk
2021-02-01  8:46         ` Alex Bennée [this message]

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=87a6so186a.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=pavel.dovgalyuk@ispras.ru \
    --cc=pbonzini@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.