On Mon, Aug 13, 2018 at 1:58 PM Jim Mattson <jmattson@xxxxxxxxxx> wrote: > > On Mon, Aug 13, 2018 at 1:45 PM, Konrad Rzeszutek Wilk > <konrad.wilk@xxxxxxxxxx> wrote: > > On Mon, Aug 13, 2018 at 09:31:42AM -0700, Drew Schmitt wrote: > >> On Mon, Aug 13, 2018 at 6:50 AM Konrad Rzeszutek Wilk > >> <konrad.wilk@xxxxxxxxxx> wrote: > >> > > >> > On Fri, Aug 10, 2018 at 02:26:03PM -0700, Drew Schmitt wrote: > >> > > Add KVM_CAP_MSR_PLATFORM_INFO so that userspace can disable guest access > >> > > to reads of MSR_PLATFORM_INFO. > >> > > >> > Or enable it - by default it is enabled. Perhaps by default it should > >> > be disabled? > >> > >> We wanted to make this an opt-out functionality in order to not change > >> the current default behavior (which today is a guest *can* read this > >> MSR). > > > > <nods> What is the danger of disabling access to this in the first place? Disabling access to reads of this MSR gives userspace the control to "expose" this platform-dependent information to guests in a clear way. As it exists today, guests that read this MSR would get unpopulated information if userspace hadn't already set it (and prior to this patch series, only the CPUID faulting information could have been populated). This existing interface could be confusing if guests don't handle the potential for incorrect/incomplete information gracefully (e.g. zero reported for base frequency). > > Or providing by default some cooked up value ? Does it break Windows? Linux guests? > > It breaks a specific non-Windows/non-Linux guest.
