[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190103171838.GB6118@tassilo.jf.intel.com>
Date: Thu, 3 Jan 2019 09:18:38 -0800
From: Andi Kleen <ak@...ux.intel.com>
To: Jim Mattson <jmattson@...gle.com>
Cc: Wei Wang <wei.w.wang@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
kvm list <kvm@...r.kernel.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Kan Liang <kan.liang@...el.com>,
Ingo Molnar <mingo@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
like.xu@...el.com, Jann Horn <jannh@...gle.com>,
arei.gonglei@...wei.com
Subject: Re: [PATCH v4 04/10] KVM/x86: intel_pmu_lbr_enable
> Yes, but then what happens?
>
> Fast forward to, say, 2021. You're decommissioning all Broadwell
> servers in your data center. You have to migrate the running VMs off
> of those Broadwell systems onto newer hardware. But, with the current
> implementation, the migration cannot happen. So, what do you do? I
> suppose you just never enable the feature in the first place. Right?
There would in theory ways to handle this.
LBRs are normally not required for running correctly, they're not like
instructions, so it would be actually quite reasonable to just return 0
and ignore writes for incompatible machines for them. Your profilers might
return some bogus data, but that is normally acceptable.
In some cases it might be also possible to emulate LBRs of
different types, but I don't think it would be worth the effort.
Yes, but the patches don't do this, so right now you should only enable it when
all systems in your migration pool have compatible LBRs.
-Andi
Powered by blists - more mailing lists