On 2016-04-15 18:51, Hristo Iliev wrote:
On Tue, 12 Apr 2016 14:50:55 -0600 Will Marler <w...@wmarler.com> wrote:

"options kvm ignore_msrs=1"

On the wiki page as it stands now there is a warning, "Silently ignoring
unknown MSR accesses could potentially break other software within the VM
or other VMs." I'm not clear on all of the ramifications, though it came up
on the mailing list before. I basically decided "not important enough for
me to do it" and forgot all the details. But I wouldn't remove this warning
or suggest this as a performance gain unless the risks have been eliminated
(or are only applicable to specific edge cases or something).

As I've probably said before, I wrote this section of the wiki. ignore_msrs=1
stops KVM from injecting #GPs when unknown MSRs are accessed and simply makes
the reads return 0 and turns the writes into no-ops. While it stops certain
software from crashing as a result of the unexpected protection faults, it
could result in the same software silently making wrong decisions based on the
zero return value and it might break legitimate software that is already
properly handling the faults. It basically replaces a well-defined exception
with a junk value.

In my case, I'm doing CPUID passthrough with my Haswell-E CPU and the unknown
MSRs are always Intel power and frequency management registers, which are
supposed to exist on the real Haswell chip. Ignoring them workes for the
NVIDIA tool, but I would not make a general case out of a specific one,
therefore the warning.

Regards,
Hristo
_______________________________________________
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users
I've changed it to make it clearer that it doesn't simply apply to Geforce Experience, as others have suggested, and reworded the warning to mention that it should /normally/ be safe to do this.

Nicolas
_______________________________________________
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users

Reply via email to