8:52 a.m.
On Tue, Sep 22, 2009 at 02:25:54PM +0100, Daniel P. Berrange wrote:
On Tue, Sep 22, 2009 at 02:41:08PM +0200, Daniel Veillard wrote:
> IMHO the worst is that the definition of the names.
> First there is gonna be a bunch of them and second their name if you
> rely just on the procinfo output may not be sufficient in the absolute.
No, we should't rely on /proc/cpuinfo because that is Linux specific.
For Xen and VMWare drivers we want a naming scheme for flags that is
OS agnostic, in particular so Xen works on Solaris and VMWare works
nicely on Windows.
For VMWare I expect the flag list and CPU descriptions to come
from the driver, which can probably extract them from ESX itself.
That's why I think we should define a naming scheme for all flags
in
libvirt, albeit not hardcoded in the source, or XML schema, but in an
external data file that can be easily extended when new CPUs come out.
I don't see how that's gonna scale. Just with the set of processors
suppoorted by QEmu and the number of flags they may each export or not.
Sure an external file would make maintainance way easier, but still...
> Registries are an nightmare by definition, and we should not
add
> a registry of features in libvirt, nor try to assert any semantic to
> those names. So I'm afraid we are good for just sampling/dumping
> /proc/cpuinfo and leave the mess to the kernel. The feature list will
> grow quite long but that's fine IMHO.
We can actually keep the feature list very short. The key is that we
expose a named CPU model which covers 95% of the host PCU features.
We then justneed to list CPU features which are not explicitly part
of that CPU moidel - which should be a mere handful - certainly less
than 10.
how do you know those lists and subsets, and how are you gonna keep
them on the long term. If you take a processor definition from 5 years ago
and want to make sure none of the new CPU features are not used what's
the scenario in practice ? Would the application hagve to know the logic
behind the name we would be defining for the processor type ? Would it
have to have that knowledge to know that based on that processor type
then such and such flags are not set ?
If we export names which are managed by libvirt, then it becomes
libvirt responsability to define the matrix of flags names and their
semantic. And that's really something I'm afraid of.
I prefer to delegate to the kernel or virtualization layers (via the
drivers) to provide those flags and semantics, ultimately they end up
being maintained either by the chip founders themselves or the
hypervisors implementors (VMWare).
> > Secondly, drivers which support detailed CPU specification
have to advertise
> > it in guest capabilities. In case <features> are meant to be hypervisor
> > features, than it could look like:
> >
> > <guest>
> > ...
> > <features>
> > <cpu/>
> > </features>
> > </guest>
>
> Somehow we will get the same mess, I assume QEmu interface can provide
> that list, right ?
> I'm also wondering if it's not possibly dependant on the machine, I
> hope not, i.e. that the emulated CPU features are not also dependent on
> the emaulated hardware...
CPU features are really just a artifact of the CPU model.
Hopefully ... but my experience with embedded (some time ago admitedly)
made clear that such or such processor feature may be activated or not
depending on how they got wired. Even nowadays your CPU may have support
for things which gets desactivated by the BIOS for example. Not that
simple IMHO.
The existing 'acpi' and 'apic' flags are not CPU
features - they are
chipset features, so out of scope for this discussion
Okay
> Something like
> <guest>
> <cpu model="foo">
> <features>fpu vme de pse tsc msr pae mce cx8 apic</features>
> </cpu>
> <cpu model="bar">
> <features>fpu vme de pse tsc msr pae mce cx8 apic mtrr pge
mca</features>
> </cpu>
> </guest>
>
> hoping it doesn't go per machine !
Exposing flags as a big string like this is really not nice for applications.
Having different representations for capabilities XML description of a CPU
vs the guest XML description of a CPU is also undesirable, thus I think thta
the capabilities XML should essentially follow whatever schema we decide to
use for the guest XML
yes I agree we should unify both formats. The flag list as a single
string isn't fun for applications, granted, something more structured
would be better.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/