On Mon, Oct 02, 2023 at 08:56:50AM -0700, Sean Christopherson wrote: > On Mon, Oct 02, 2023, Ingo Molnar wrote: > > > > * Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > > > On Fri, Sep 29, 2023 at 03:46:55PM +0000, Sean Christopherson wrote: > > > > > > > > I will firmly reject anything that takes the PMU away from the host > > > > > entirely through. > > > > > > > > Why? What is so wrong with supporting use cases where the platform owner *wants* > > > > to give up host PMU and NMI watchdog functionality? If disabling host PMU usage > > > > were complex, highly invasive, and/or difficult to maintain, then I can understand > > > > the pushback. > > > > > > Because it sucks. > > > > > You're forcing people to choose between no host PMU or a slow guest PMU. > > Nowhere did I say that we wouldn't take patches to improve the existing vPMU > support. Nowhere did I talk about vPMU -- I explicitly mentioned pass-through. > > > worse it's not a choice based in technical reality. > > The technical reality is that context switching the PMU between host and guest > requires reading and writing far too many MSRs for KVM to be able to context > switch at every VM-Enter and every VM-Exit. And PMIs skidding past VM-Exit adds > another layer of complexity to deal with. I'm not sure what you're suggesting here. It will have to save/restore all those MSRs anyway. Suppose it switches between vCPUs. > > > It's a choice out of lazyness, disabling host PMU is not a requirement > > > for pass-through. > > The requirement isn't passthrough access, the requirements are that the guest's > PMU has accuracy that is on par with bare metal, and that exposing a PMU to the > guest doesn't have a meaningful impact on guest performance. Given you don't think that trapping MSR accesses is viable, what else besides pass-through did you have in mind? > > Not just a choice of laziness, but it will clearly be forced upon users > > by external entities: > > > > "Pass ownership of the PMU to the guest and have no host PMU, or you > > won't have sane guest PMU support at all. If you disagree, please open > > a support ticket, which we'll ignore." > > We don't have sane guest PMU support today. Because KVM is too damn hard to use, rebooting a machine is *sooo* much easier -- and I'm really not kidding here. Anyway, you want pass-through, but that doesn't mean host cannot use PMU when vCPU thread is not running. > If y'all are willing to let KVM redefined exclude_guest to be KVM's outer run > loop, then I'm all for exploring that option. But that idea got shot down over > a year ago[*]. I never saw that idea in that thread. You virt people keep talking like I know how KVM works -- I'm not joking when I say I have no clue about virt. Sometimes I get a little clue after y'all keep bashing me over the head, but it quickly erases itself. > Or at least, that was my reading of things. Maybe it was just a > misunderstanding because we didn't do a good job of defining the behavior. This might be the case. I don't particularly care where the guest boundary lies -- somewhere in the vCPU thread. Once the thread is gone, PMU is usable again etc.. Re-reading parts of that linked thread, I see mention of PT_MODE_HOST_GUEST -- see I knew we had something there, but I can never remember all that nonsense. Worst part is that I can't find the relevant perf code when I grep for that string :/ Anyway, what I don't like is KVM silently changing all events to ::exclude_guest=1. I would like all (pre-existing) ::exclude_guest=0 events to hard error when they run into a vCPU with pass-through on (PERF_EVENT_STATE_ERROR). I would like event-creation to error out on ::exclude_guest=0 events when a vCPU with pass-through exists -- with minimal scope (this probably means all CPU events, but only relevant vCPU events). It also means ::exclude_guest should actually work -- it often does not today -- the IBS thing for example totally ignores it. Anyway, none of this means host cannot use PMU because virt muck wants it.
