qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration
Date: Wed, 09 Sep 2009 22:00:48 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]