On Mon, Aug 13, 2018 at 02:00:49PM -0700, Drew Schmitt wrote: > 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). Any chance you can add that in the commit description, and with that: > > > > Or providing by default some cooked up value ? Does it break Windows? Linux guests? > > > > It breaks a specific non-Windows/non-Linux guest. Heh. Some "other" guest. Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> Thank you!
