On Fri, Jun 14, 2013 at 03:06:52PM +0200, Jiri Denemark wrote: > Hi Don, > > I'm sorry for the delay... NP. > > On Fri, May 31, 2013 at 13:04:17 -0600, Don Dugger wrote: > > On Thu, May 30, 2013 at 01:48:32PM +0200, Jiri Denemark wrote: > > > On Tue, May 28, 2013 at 16:11:57 -0600, Don Dugger wrote: > > > > The virConnectGetCapabilities API describes the host capabilities > > > > by returning an XML description that includes the CPU model name > > > > and a set of CPU features. The problem is that any features that > > > > are part of the CPU model are not explicitly listed, they are > > > > assumed to be part of the definition of that CPU model. This > > > > makes it extremely difficult for the caller of this API to check > > > > for the presence of a specific CPU feature, the caller would have > > > > to know what features are part of which CPU models, a very > > > > daunting task. > > > > > > > > This patch solves this problem by having the API return a model > > > > name, as it currently does, but it will also explicitly list all > > > > of the CPU features that are present. This would make it much > > > > easier for a caller of this API to check for specific features. > > > > > > It's actually the desired behavior and not a bug. We went that way for > > > several reasons. First, given how QEMU/KVM works, the fact that a > > > CPU feature is detected by libvirt in host CPU and reported in > > > capabilities XML does not mean that the feature will be available to > > > guests. This is the reason why we have virConnectCompareCPU. You can > > > create a guest CPU definition you would like to see in a guest and call > > > virConnectCompareCPU on it to check if that guest CPU can be run on that > > > particular host. And providing all features in capabilities XML would > > > just make the XML larger with no practical benefit. > > > > The fact that host CPU features at not necessarily available to a guest > > has no impact on whether or not we report all features that the host > > supports, that issue remains in either case. > > I was just trying to say that it doesn't provide anything more than > "it's supported by the host CPU", which gives mostly no value in the > context of libvirt. Can you explain more what the use case is in which a > virt client would need to know what specific feature are supported by > host CPU? I feel like we should avoid people from being under the > impression that they can actually use the CPU capabilities for checking > whether a host can run guests that require specific CPU features. The specific use case I'm trying to address is a cloud environment where, with hundreds of hosts, you might want to schedule an instance to a host that supports a particular HW acceleration, like AES/NI. I agree, what I `really` want is an API that shows the capabilities of a specific guest that could be created on the host but, absent that API, at least knowing that a host doesn't support the feature is more information than I can get right now. I'm willing to walk before I run and start from knowing what capabilities the `host` has (and create a new API to report on actual guests in the not too distant future). Independent from my use case I still think this API is wrong in that it is effectively obfuscating by omission. Given that there's no good way, given a model name, to know what features are in that model then, if the API is going to report anything, it should report all features. It can still give the model name, I completely support that, but I see nothing wrong with reporting the model name and, in addition, the list of all features supported by the host. It comes down to, other than a minor size issue in the resulting XML file, what's the advantage of reporting features relative to model? If we report all features then people that care about the model will still have that info and people that care about specific features will now have a usable list of features they can rely upon. > > Moreover, there's one thing that makes this issue even more complicated. > As the CPU model is the most useful part of host CPU capabilities (it > should be the best CPU model supported by the host), I wanted to extend > the probing code to select the right model even if it's missing some > features that we expect to be supported by that model. In other words, > if host CPU is, e.g., SandyBridge but has some basic feature disabled, > we would detect it as the best model which did not have the disabled > feature, which is not optimal. We'd ideally detect the CPU as > SandyBridge with just the feature disabled. That is, another reason for > having feature list relative to the CPU model. On the other hand, it > might be hard or even impossible to do without breaking compatibility > and perhaps even doubtful without involving emulator, which would make > it impossible to do within capabilities XML. If I understand you, you're proposing that you report the host as being a SandyBridge when it doesn't support all SandyBridge features? I don't like that idea as it seems really confusing. Taken to the extreme, this would mean you could take a Nehalem host and report it as a SanyBridge that lacks some features. I don't see the point of that. > > Jirka > -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale n0ano@xxxxxxxxx Ph: 303/443-3786 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list