[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 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
signature.asc
Description: OpenPGP digital signature
- [Qemu-devel] [PATCH 3/5] Introduce QEMU_CLOCK_HOST, (continued)
- [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
- [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration, Jan Kiszka, 2009/09/14
- Re: [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration, Markus Armbruster, 2009/09/09
Re: [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration, Gerd Hoffmann, 2009/09/10
[Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration, Blue Swirl, 2009/09/09