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

Re: [libvirt] Is possible that cpu_maps.xml changed during different releases?



Eric, thanks for the answer very .much, that's really helpful.
Sorry for the wrong format, I'm using outlook and possibly some setting wrong.

Thanks
--jyh

> -----Original Message-----
> From: Eric Blake [mailto:eblake redhat com]
> Sent: Thursday, November 01, 2012 11:23 PM
> To: Jiang, Yunhong
> Cc: libvir-list redhat com
> Subject: Re: [libvirt] Is possible that cpu_maps.xml changed during different
> releases?
> 
> On 10/31/2012 02:20 AM, Jiang, Yunhong wrote:
> > Hi, all
> 
> [your mailer doesn't know how to wrap long lines, which makes it awkward to
> read your message]
> 
> > 	I have two questions to the cpu_maps.xml in different releases, hope
> someone can give me some hints:
> >
> > 	a) Will it be possible that the features defined in cpu_maps.xml for one
> specific CPU model (like Nehalem) will be different? For example, one feature is
> not listed for Nehalem in release x.y, and added in release x.y+1?
> 
> XML does have the possibility to change between releases, but such changes
> will only be additive (we will never remove support for a feature once it is
> listed).
> 
> >
> > 	2) Is the format of the cpu_maps.xml fine defined or will be it changed
> during releases? I asked this because currently the features defined in the
> capabilities only list features not included in the definition in cpu_maps.xml for
> the corresponding model. So if I want to get the full features supported by the
> host, I have to parse the capabilities and the cpu_maps.xml. I didn't find the
> definition for cpu_maps.xml format, although the capabilities format is well
> defined in
> http://libvirt.org/guide/html/Application_Development_Guide-Connections-Ca
> pability_Info.html.
> 
> The format should be well-defined; again, our requirement is that upgrades
> might add new xml attributes or elements, but will never remove elements
> that have been valid in previous releases.  To some extent,
> docs/schemas/capability.rng in libvirt.git gives an RNG grammar for what
> capabilities will look like, although someone else may be able to point to a
> better documentation of what will be in cpu_maps.xml.
> 
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org



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