Re: RFC: Add clock/timers info in osinfo-db

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Fedora Users]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux