All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Daniil Tatianin <d-tatianin@yandex-team.ru>
Cc: "Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Eric Blake" <eblake@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [PATCH v4] mc146818rtc: add a way to generate RTC interrupts via QMP
Date: Wed, 29 May 2024 16:28:18 +0200	[thread overview]
Message-ID: <878qzslmkd.fsf@pond.sub.org> (raw)
In-Reply-To: <c8ef6f8f-411d-4f25-bfec-d9f2dfa4b55d@yandex-team.ru> (Daniil Tatianin's message of "Wed, 29 May 2024 15:43:50 +0300")

Daniil Tatianin <d-tatianin@yandex-team.ru> writes:

> On 5/29/24 3:36 PM, Philippe Mathieu-Daudé wrote:
>
>> On 29/5/24 14:03, Markus Armbruster wrote:
>>> Daniil Tatianin <d-tatianin@yandex-team.ru> writes:
>>>
>>>> This can be used to force-synchronize the time in guest after a long
>>>> stop-cont pause, which can be useful for serverless-type workload.
>>>>
>>>> Also add a comment to highlight the fact that this (and one other QMP
>>>> command) only works for the MC146818 RTC controller.
>>>>
>>>> Acked-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>>>> Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru>

[...]

>>>> diff --git a/include/hw/rtc/mc146818rtc.h b/include/hw/rtc/mc146818rtc.h
>>>> index 97cec0b3e8..e9dd0f9c72 100644
>>>> --- a/include/hw/rtc/mc146818rtc.h
>>>> +++ b/include/hw/rtc/mc146818rtc.h
>>>> @@ -56,5 +56,6 @@ MC146818RtcState *mc146818_rtc_init(ISABus *bus, int base_year,
>>>>   void mc146818rtc_set_cmos_data(MC146818RtcState *s, int addr, int val);
>>>>   int mc146818rtc_get_cmos_data(MC146818RtcState *s, int addr);
>>>>   void qmp_rtc_reset_reinjection(Error **errp);
>>>> +void qmp_rtc_inject_irq_broadcast(Error **errp);
>>>>     #endif /* HW_RTC_MC146818RTC_H */
>>>> diff --git a/qapi/misc-target.json b/qapi/misc-target.json
>>>> index 4e0a6492a9..7d388a3753 100644
>>>> --- a/qapi/misc-target.json
>>>> +++ b/qapi/misc-target.json
>>>> @@ -19,6 +19,25 @@
>>>>   { 'command': 'rtc-reset-reinjection',
>>>>     'if': 'TARGET_I386' }
>>>>   +##
>>>> +# @rtc-inject-irq-broadcast:
>>>> +#
>>>> +# Inject an RTC interrupt for all existing RTCs on the system.
>>>> +# The interrupt forces the guest to synchronize the time with RTC.
>>>> +# This is useful after a long stop-cont pause, which is common for
>>>> +# serverless-type workload.

[...]

>>> Make that "workloads".
>>>
>>> "For all existing RTCs" is a lie.  It's really just all mc146818s.  The
>>> command works as documented only as long as the VM has no other RTCs.
>>
>> @rtc-mc146818-force-sync-broadcast sounds clearer & safer;
>> IIUC the command goal, mentioning IRQ injection is irrelevant
>> (implementation detail).
>>
> I like this if Markus is okay with that. If we go with this, would it make sense to drop the "Bug" clause?

Putting "mc146818" right into the command name is fine with me.
Rephrasing the doc comment to say "all MC146818 RTC devices" then makes
sense, and removes the need for a "Bug: clause".

With "mc146818" in the command name, I don't see the need for
"-broadcast".  The fact that it applies to all MC146818 RTCs feels like
detail to me.  In particular since there's usually exactly one.  Still
important enough to spell out in documentation, but I doub't it's
important enough to warrant a mention in the command name.

I have doubts on replacing the commands action "inject-irq" by the
action's purpose "force-sync".  What the guest does with the IRQ is
entirely up to guest software.  Common guest software sets the system
clock from the RTC hardware clock.  But it's really up to the guest.

What about mc146818-inject-irq?

>> (I'm trying to not spread the problems we already have with
>> @rtc-reset-reinjection).

Well, we are adding to them no matter how we name the command.  We're
just more honest about it :)

[...]



      parent reply	other threads:[~2024-05-29 14:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-28  7:22 [PATCH v4] mc146818rtc: add a way to generate RTC interrupts via QMP Daniil Tatianin
2024-05-29 12:03 ` Markus Armbruster
2024-05-29 12:31   ` Daniil Tatianin
2024-05-29 12:36   ` Philippe Mathieu-Daudé
2024-05-29 12:43     ` Daniil Tatianin
2024-05-29 13:39       ` Philippe Mathieu-Daudé
2024-05-29 13:51         ` Daniil Tatianin
2024-05-29 14:34           ` Markus Armbruster
2024-05-29 15:27             ` Philippe Mathieu-Daudé
2024-06-17  8:27               ` Daniil Tatianin
2024-07-17  7:57               ` Daniil Tatianin
2024-07-22 11:31                 ` Daniil Tatianin
2024-08-15 10:22                 ` Daniil Tatianin
2024-05-29 14:28       ` Markus Armbruster [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=878qzslmkd.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=d-tatianin@yandex-team.ru \
    --cc=eblake@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /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.