Hi, Couple of points: - do we already handle hypervisor and rachitecture differences elsewhere in libosinfo? (it might affect RAM sizes as well for example) - a timer might be supported in more than one hypervisor (your timer example does not express that) - the tickpolicy setting is not a property of a timer only, but depends on the guestos as well So if your timers (and devices, features in general) support hypervisor support fields (supported-by-hv="xen,qemu") and/or architecture support (supported-by-arch="x86_64,i386,ppc") then you could express timers in the same way as devices and let the guest os reference the timer device with catchup policy defined: Example (might not be the best form for XML or the db): <timer id="http://qemu.org/timer/hpet";> <name>hpet</name> <arch>x86_64</arch> // The same element repeated with disjunct supported-by attributes (matrix) <allowed-tickpolicy supported-by-hv="xen" supported-by-arch="all">catchup,delay</allowed-tickpolicy> <allowed-tickpolicy supported-by-hv="kvm" supported-by-arch="x86_64,ppc">catchup,delay,merge</allowed-tickpolicy> </timer> <os> <timers> <timer id="http://qemu.org/timer/hpet"; tickpolicy="catchup" supported-by-hv="xen"/> <timer id="http://qemu.org/timer/hpet"; tickpolicy="merge" supported-by-hv="kvm"/> </timers> </os> Martin On Mon, Jan 21, 2019 at 3:22 PM Fabiano Fidêncio <fidencio@xxxxxxxxxx> 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; > > 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? > - Shall we care about "timezone" or "variable" possible clock offsets? > - 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? > > 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. > > Best Regards, > -- > Fabiano Fidêncio _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
