On Tue, Jan 22, 2019 at 12:23:54PM +0100, Fabiano Fidêncio wrote:
> 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?
Yeah, I think so.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
_______________________________________________
Libosinfo mailing list
Libosinfo@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libosinfo
