On Mon, Jun 17, 2013 at 10:27:36AM +0200, Jiri Denemark wrote: > On Fri, Jun 14, 2013 at 12:32:35 -0600, Don Dugger wrote: > > On Fri, Jun 14, 2013 at 03:06:52PM +0200, Jiri Denemark wrote: > > > 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. > > Hmm, fair enough. Let's wait a few days for Daniel to return from > vacation in case he wants to express his opinion here. So, any progress here? > > > > 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. > > Yes and no :-) I'd like to report the CPU as a SandyBridge if it really > is a SandyBridge but lacks a feature that we require to be present for > us to detect the CPU as a SandyBridge. There are (or at least were) > features that can actually be disabled on the host, e.g., by BIOS and I > remember that doing so may result in that particular feature to be > disabled in CPUID. For example, if NX (not sure if that's the right > example that is actually masked from CPUID) is disabled, than the CPU > still is a SandyBridge but libvirt would detect it as something generic > and old as NX is part of all modern CPU models libvirt supports. > However, as I said, this could be hard or even impossible to do in a > compatible manner. > > 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