lstopo, lstopo --output-format xml These commands might be helpful

On Tue, Mar 21, 2017 at 02:35:24PM +0000, Richard W.M. Jones wrote: Yeah, but we don't really parse more than the cpu frequency from that file. We could theoretically add some "local hypervisor" driver that could expose only host-related APIs and would have no hypervisor capabilities, but that seems hacky. test:///default is purposefully not touching the host, it would have to be something like local:// or none:///local So when you install virsh, it uses libvirt-libs and all the stuff that's used for parsing and providing that information is already there (almost, though), so it seems possible to provide the information. However, that doesn't really fit into how virsh is trying to work/look. You could use the internals directly, or parse the cpu_map.xml yourself, but that's not supported and so on. We could provide a helper in /usr/libexec that would tell you the capabilities, but there's still one caveat. You want to describe the CPU model for QEMU to emulate it as closely as possible. Long story short, for that we were trying to mimic QEMU's behaviour and due to various inconsistencies the best thing to do was ask the QEMU binary itself directly about this stuff. So if you currently want to use libvirt for this, I can't think of a reliable way to do it without QEMU. We can get "close enough" without QEMU, but so can you: - uname() to have the architecture, - check the flags from /proc/cpuinfo: - ARM => Features: - x86 => flags: - do a mapping between cpuinfo flags and QEMU features (my guess is there's around 10 features that might have different spelling) - get all the topology from /sys/devices/system/{node,cpu}, there's lot more info nowadays in newer kernels exposed in there, so you don't need to go searching anywhere else much Of course this will only work on linux, but I'm guessing that's not a problem in this case, right?