On Fri, Apr 12, 2019 at 11:11:38 +0100, Daniel P. Berrangé wrote:
On Fri, Apr 12, 2019 at 11:47:15AM +0200, Jiri Denemark wrote:
> On Thu, Apr 11, 2019 at 17:13:51 +0100, Daniel P. Berrangé wrote:
> > On Mon, Apr 08, 2019 at 10:42:38AM +0200, Jiri Denemark wrote:
> > > The new virHostCPUGetMSR internal API will try to read the MSR from
> > > /dev/cpu/0/msr and if it is not possible (the device does not exist or
> > > libvirt is running unprivileged), it will fallback to asking KVM for the
> > > MSR using KVM_GET_MSRS ioctl.
> >
> > Is there benefit to using /dev/cpu/0/msr, instead of always using
> > /dev/kvm ?
>
> KVM may report some bits in the IA32_ARCH_CAPABILITIES MSR even when the
> host does not set them or even support MSR at all. So for reporting host
> capabilities /dev/cpu/0/msr is IMHO better. We will still get the made
> up bits in the MSR via QEMU for host-model.
>
> For example, on my laptop which does not support IA32_ARCH_CAPABILITIES
> MSR at all I get 0x8 when asking KVM, while reading /dev/cpu/0/msr
> returns I/O error since the MSR does not exist.
Hmm, do we need to get /dev/kvm fixed in this regard ? It seems bad that
libvirt will be relying on different information about MSRs when running
as root vs non-root. Could like to even more painful bugs to triage.
Hmm, actually we read any of those only if the corresponding CPUID bit
is set, that is when the host CPU supports this MSR. So the problem with
reading something from KVM when the MSR is not supported does not exist.
However, we can still see more bits enabled when reading the MSR via
KVM. So when libvirtd is unprivileged, it will show MSR features which
can be emulated by KVM even in host capabilities (while normally we
would only see them in domain capabilities). I don't think this should
be a big deal. But I still think it's better to show the real results
read from the host CPU when possible.
Jirka