[Top][All Lists]
[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
- [Qemu-devel] [PATCH 0/5] Refactor and enhance RTC configuration, Jan Kiszka, 2009/09/09
- [Qemu-devel] [PATCH 3/5] Introduce QEMU_CLOCK_HOST, Jan Kiszka, 2009/09/09
- [Qemu-devel] [PATCH 1/5] Rename QEMU_TIMER_* to QEMU_CLOCK_*, Jan Kiszka, 2009/09/09
- [Qemu-devel] [PATCH 4/5] Refactor RTC command line switches, Jan Kiszka, 2009/09/09
- [Qemu-devel] [PATCH 5/5] Enable host-clock-based RTC, Jan Kiszka, 2009/09/09
- [Qemu-devel] [PATCH 2/5] win32: Drop dead dyntick timer code, Jan Kiszka, 2009/09/09
- [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration, Anthony Liguori, 2009/09/09
- Re: [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration, Jamie Lokier, 2009/09/09
- Re: [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration, Jan Kiszka, 2009/09/11
- Re: [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration, Dor Laor, 2009/09/13
- [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration, Jan Kiszka, 2009/09/13
- [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration, Anthony Liguori, 2009/09/14