On 26.01.2010, at 15:37, Avi Kivity wrote: > On 01/26/2010 04:32 PM, Anthony Liguori wrote: >>>>> It would need to know which cpuid bits qemu supports. Only qemu knows >>>>> that. >>>> >>>> I'm not sure I understand why. Can you elaborate? >>>> >>> >>> If qemu doesn't recognize -cpu qemu64,+nx, then no amount of hardware and >>> kvm.ko support will allow the user to enable nx in a guest. >> >> >> Does -cpu host filter out flags that we don't know about? I'm pretty sure >> it doesn't. Since we're planning on moving to -cpu host by default for KVM, >> does it really matter? > > People who use discovery tools are probably setting up a migration cluster. > They aren't going to use -cpu host. > >> >> Oh, I was under the impression that the tool was meant to be software >> agnostic. IOW, here are all the virt features your hardware supports. > > That's /proc/cpuinfo, we should just extend it, maybe that's what Alex meant, > but I'd like to see something more capable.
I think we're all looking at different use-cases. First and frontmost the one type of user I'm concerned with in this case is a mortal end-user who doesn't know that much about virtualization details and doesn't care what NPT is. He just wants to have a VM running and wants to know how well it'll work. For such a user an addition to /proc/cpuinfo would be enough, if it'd include IOMMU information. Or maybe /proc/iommu? I think users should be able to run some simple command to evaluate if what they're trying to do works out. And if not, the command should give assistance on how to make things work (buy a new mainboard, set this kernel option, ...) Of course one could fit in stuff for management tools too, but that's not my main goal for this feature. Alex
