On Sat, Jun 1, 2019 at 3:50 AM Wei Wang <wei.w.wang@xxxxxxxxx> wrote: > > My question is that have we proved that this indirect info leakage > indeed happens? > The spec states that the counter will count the related events generated by > the logical CPU with AnyThread=0. I would be inclined to trust the > hardware behavior > documented in the spec unless we could prove there is a problem. I'm not disputing the spec with regards to AnyThread=0; my point is that LLC contention can be quantified using the PMU regardless of whether or not you are measuring only the logical CPU you are running on. > From the guest point of view, returning 0 means that the event counting > is running well. > That is, the guest is expecting to get some count numbers. So better not > to zero the value > when the guest does rdpmc/rdmsr to get the count in this case. > > I think we could just ensure "AnyThread=0" in the config, and create the > kernel > counter as usual. If you return non-zero in intel_pmu_set_msr(), KVM emulates a gp fault. Which as you said signals that something went wrong to the guest. However, older guests with panic_on_oops=1 (which is apparently default on RHEL 6) will panic if they get a gpfault while trying to do a wrmsr (see the "Carry on after a non-"safe" MSR access fails without !panic_on_oops" patch). I think that not panicking guests is probably preferable to communicating that we weren't able to program the event. Eric
