[Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2205 bytes --]

Anthony Liguori wrote:
> Jan Kiszka wrote:
>> Anthony Liguori wrote:
>>  
>>> You get most of this pretty cheaply with qdev conversion.  If you give
>>> the rtc a default id, you can tweak all of the properties with the -set
>>> command line option.  It also provides a mechanism to change the default
>>> properties between machine types/versions which is ideal as we can
>>> introduce a kvm-specific machine type where we enable some of these
>>> things by default.
>>>
>>>     
>>
>> Hmm, the refactoring of the old command line switches to -rtc is, if I
>> understand qdev and -set correctly, widely orthogonal.
> 
> No, it isn't.  To introduce -rtc properly, you should use QemuOpts.  We
> shouldn't be introducing new options that don't conform to QemuOpts
> syntax and the best way to do that is to just use QemuOpts.

Yes, QemuOpts is a must-have for -rtc. So you agree to introduce -rtc
(in addition to the qdev-based configuration, of course)?

> 
> To communicate the QemuOpts to the rtc, I think the easiest approach is
> to convert rtc to qdev and reuse the -device logic.  Otherwise, you have
> to use statics or add new parameters to the machine init.

Agreed. And Gerd obviously already did that work for me. :)

> 
>>  Or is the policy
>> now to freeze all command line switches in favor of the -device and
>> -set?.
> 
> As much as possible, yes, I think this is the reasonable thing to do.
> 
>>  However, I will look into qdev conversion of the PC RTC.
>>
>> Besides the interface thing, I'm also interesting in comments on the
>> other core idea, the selectable RTC base clock. Do we want this knob? Do
>> we want host_clock unconditionally? Or should the other RTC that
>> currently use the host time already also gain vm_clock support over the
>> time?
>>   
> Hard to say.  Doesn't the rtc keep track of wallclock time even on power
> off?  I think using host_clock unconditionally does actually make sense.
> 

Moreover, quite a few (of not all?) other RTCs use the host time
already. Well, I would be happy to avoid that 'clock' knob. So if there
are no concerns, I will unconditionally switch MC146818 to host_clock.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]