> Hmm. Right. But it's also hypervisor dependent right? > So, the tickpolicy is something that we'd have to properly have mapped > what's supported on each hypervisor and then what can be used by each > guest OS. Right? Yes, I think so. Martin On Mon, Jan 21, 2019 at 8:23 PM Fabiano Fidêncio <fabiano@xxxxxxxxxxxx> wrote: > > On Mon, Jan 21, 2019 at 4:42 PM Martin Sivak <msivak@xxxxxxxxxx> wrote: > > > > Hi, > > > > Couple of points: > > - do we already handle hypervisor and rachitecture differences > > elsewhere in libosinfo? > > (it might affect RAM sizes as well for > > example) > > Devices are, for example, listed by hypervisors. > Resources (as RAM), for example, listed by architecture. > > Something that deal with both at the same time, no (or at least not > that I remember). > > > - a timer might be supported in more than one hypervisor (your timer > > example does not express that) > > Actually, it does. > Each timer definition would have to be added to the hypervisor itself > (hypervisors are "platforms" for osinfo-db) and my suggestion is: > - Define a timer (in the same way a device is defined); > - Add the timer definition to the platform; > - Add the timer definition to the OS; > > > - the tickpolicy setting is not a property of a timer only, but > > depends on the guestos as well > > > > Hmm. Right. But it's also hypervisor dependent right? > So, the tickpolicy is something that we'd have to properly have mapped > what's supported on each hypervisor and then what can be used by each > guest OS. Right? > > > 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> > > > > Although hat's not the way to go (as, in, having a supported-by field) > and this is the most tricky part to have set/defined properly. > > Dan, any suggestion here? > > [snip] > > Best Regards, > -- > Fabiano Fidêncio _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
