lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 5 Jan 2019 10:15:19 +0000
From:   "Wang, Wei W" <wei.w.wang@...el.com>
To:     Jim Mattson <jmattson@...gle.com>
CC:     LKML <linux-kernel@...r.kernel.org>,
        kvm list <kvm@...r.kernel.org>,
        "Paolo Bonzini" <pbonzini@...hat.com>,
        Andi Kleen <ak@...ux.intel.com>,
        "Peter Zijlstra" <peterz@...radead.org>,
        "Liang, Kan" <kan.liang@...el.com>,
        "Ingo Molnar" <mingo@...hat.com>,
        Radim Krcmár <rkrcmar@...hat.com>,
        "Xu, Like" <like.xu@...el.com>, Jann Horn <jannh@...gle.com>,
        "arei.gonglei@...wei.com" <arei.gonglei@...wei.com>
Subject: RE: [PATCH v4 04/10] KVM/x86: intel_pmu_lbr_enable

On Friday, January 4, 2019 11:54 PM, Jim Mattson wrote:
> On Fri, Jan 4, 2019 at 2:03 AM Wei Wang <wei.w.wang@...el.com> wrote:
> >
> > On 01/03/2019 11:34 PM, Jim Mattson wrote:
> > > 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?
> >
> > I'm not sure if that's the way people would do with their data centers.
> > What would be the point of decommissioning all the BDW machines when
> > there are important BDW VMs running?
> 
> TCO increases as hardware ages, while the TCO for each successive
> generation of hardware tends to be lower than its predecessor. Thus, the
> point of decommissioning all BDW hosts that are beyond their useful service
> life is to save money. Our assumption for Google Cloud is that we will always
> be able to emulate older Intel processors on newer Intel processors, so the
> running BDW VMs should not be affected by the decommissioning of BDW
> hardware. Obviously, that means that we won't offer features that don't
> have a forward migration story, such as this one.
> 
> Yes, someday Intel will drop support for some feature that we currently offer
> (like MPX, perhaps), and that will cause us some grief.

This sounds like a pretty good opportunity to convince your customers
to upgrade their VMs :)

So the solution to your above problem I have in mind currently is:
- expect QEMU's support to upgrade VMs (e.g. BDW to SKL)
- just disable the non-compatible features for non-upgraded VMs
(this could be in your SLA)

Anyway, I think it would be good to get this feature online first,
and then re-visit that future concern.

Best,
Wei
 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ