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

[Anthony Liguori <aliguori@us.ibm.com>]

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.

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.

>  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.

-- 
Regards,

Anthony Liguori