On Tue, Jan 22, 2019 at 12:14 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
>
> On Mon, Jan 21, 2019 at 03:22:06PM +0100, Fabiano Fidêncio wrote:
> > People,
> >
> > I'd like to start a discussion here as this topic is not as simple as
> > it looks like.
> >
> > My first idea would be to have something like:
> > <os>
> > <clock offset="utc|localtime">
> > <timer name="hyperv|hpet|kvm|pit|rtc|tsc"
> > tickpolicy="catchup|delay|discard|merge" arch="aarch64|x86_64|..."
> > supported="true|false"/>
> > ...
> > </clock>
> > </os>
> >
> > But Daniel raised the following points:
> > - *every* guest OS wants an RTC timer, the only question is whether
> > its better to have it synced UTC or locatime;
> > - "tickpolicy" may not actually be portable across hypervisors;
>
> Yeah, this second point is a big concern for me.
>
> The only things that are purely about guest OS support are
>
> - Whether the RTC should be synced to UTC vs localtime
> - Whether a particular timer is supported
>
> The tickpolicy is very much hypervisor dependent so I don't think
> that really belongs as a setting against the OS.
>
> Unfortunately, without tickpolicy the timers stuff becomes
> significantly less useful to apps.
>
> > Now, I'm stuck on how to properly represent those and I'd like to have
> > some feedback on the following suggestion:
> > - Create a osinfo-db/data/timer/{qemu.org,xen.org,...} and add there
> > the supported timers for which platform and add the following timers:
> > hpet, kvmclock, pit, rtc, tsc and hypervclock.
> >
> > - Once we have those timers added, we'd have to add them to the
> > specific platforms:
> > - According to https://libvirt.org/formatdomain.html, we have the
> > following list:
> > - hpet: libxl, xen, qemu
> > - kvmclock: qemu
> > - pit: qemu
> > - rtc: qemu
> > - tsc: libxl
> > - hypervclock: qemu (since 1.2.2)
> >
> > - And, finally, add those to the OSes;
> >
> > There are still a few questions that I have:
> > - Do we treat "libxl" as "xen" on osinfo-db side or is "libxl"
> > something that has to be added to the platforms?
>
> It is "xen" - libxl is a libvirt driver name, "xen" is the hypervisor
> name.
>
> > - Shall we care about "timezone" or "variable" possible clock offsets?
>
> Neither of those are relevant. timezone is just a way of saying
> the guest clock is synced to "localtime", but in a timezone that
> is diffferent from what the host OS uses. "variable" is a way
> of expressing the fact that the guest OS has adjusted their
> clock away from the original sync point.
>
> > - Are the clock offsets something that's portable across the
> > platforms? Or, IOW, would be good enough to just have the allowed
> > values as a choice and deal with that in the schema?
> > - What would be a reasonable representation for the timers? Something like ...
> > <timer id="http://qemu.org/timer/hpet";>
> > <name>hpet</name>
> > <arch>x86_64</arch>
> > <tickpolicy>catchup</tickpolicy>
> > </timer>
> > - In case, it's totally wrong, why? What would be a different way to go?
>
> "hpet" is not a QEMU invention - it is a standard defined for the
> x86 architecture, as at the other timers, so using a qemu.org
> namespace would be wrong.
>
> >
> > This seems like a *bunch* of work to be done, but if this is the way
> > to go, well, this will be the path taken.
>
> My concern with the above is that it feels like we are effectively
> re-inventing the "profiles" stuff that was previous discussed, but
> in a way that only works for timers.
>
> With both this stuff around timers, and the stuff around features,
> it feels like we really need the "profiles" concept to deal with
> the fact that what we're trying to express is tied to a pair of
> (hypervisor, guest os).
>
> Unfortunately we didn't come to an agreement on the profiles
> design concept yet.
Okay, so we should:
- Do not review Features series
- Do not move forward with the Timers series
- Get back to the Profiles discussion (Fabian, Martin, your feedback
there is more than appreciated ... it's actually needed!)
- Revisit Features/Timers after having a clear idea about the Profiles
work started by Martin Kletzander.
Does that sound like a deal?
Best Regards,
--
Fabiano Fidêncio
_______________________________________________
Libosinfo mailing list
Libosinfo@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libosinfo
