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 18:24:12 +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:
>> The aim of this series is to allow using the emulated PC RTC (MC146818)
>> as a reliable time source for guests. This is particularly useful if the
>> host runs NTP or has otherwise access to an accurate clock while the
>> guest has not (no network, impossible to add an NTP implementation
>> etc.).
>>
>> To achieve this, the command line switch -rtc is introduced. It takes
>> the option 'clock' to switch between the currently used base ('vm') and
>> the new QEMU_CLOCK_HOST ('host'). At this chance, -rtc is also used to
>> deprecate all the other RTC-related stand-alone switches.
>>
>> First tests indicate that this approach works as expected and could
>> increase the usefulness of the virtual RTC enormously. However, there
>> might be pitfalls I've missed so far. Feedback would be welcome!
>>   
> 
> 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. Or is the policy
now to freeze all command line switches in favor of the -device and
-set?. 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?

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux




reply via email to

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