Commits · 08f835083da12cc63407732edd2ed33df6015d4b · Kirill Smelkov / linux

06 Feb, 2019 40 commits

UBUNTU: SAUCE: KVM: Move code fragments, cleanup and re-indent · 08f83508

Juerg Haefliger authored Nov 28, 2018

BugLink: https://bugs.launchpad.net/bugs/1811646

To match upstream stable v4.4 and v4.9, respectively, so that future
cherry-picking results in fewer conflicts.

No functional changes.
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>

08f83508

UBUNTU: SAUCE: [Fix] x86/KVM/VMX: Add L1D flush logic · 4ad43721

Juerg Haefliger authored Nov 28, 2018

BugLink: https://bugs.launchpad.net/bugs/1811646

Enable L1D flushing for AMD which was missed in the backport of
c595ceee ("x86/KVM/VMX: Add L1D flush logic").

Fixes: 57880666 ("x86/KVM/VMX: Add L1D flush logic")
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>

4ad43721

kvm: vmx: Scrub hardware GPRs at VM-exit · 2c34f16e

Jim Mattson authored Jan 03, 2018

BugLink: https://bugs.launchpad.net/bugs/1811646

Guest GPR values are live in the hardware GPRs at VM-exit.  Do not
leave any guest values in hardware GPRs after the guest GPR values are
saved to the vcpu_vmx structure.

This is a partial mitigation for CVE 2017-5715 and CVE 2017-5753.
Specifically, it defeats the Project Zero PoC for CVE 2017-5715.
Suggested-by: Eric Northup <digitaleric@google.com>
Signed-off-by: Jim Mattson <jmattson@google.com>
Reviewed-by: Eric Northup <digitaleric@google.com>
Reviewed-by: Benjamin Serebrin <serebrin@google.com>
Reviewed-by: Andrew Honig <ahonig@google.com>
[Paolo: Add AMD bits, Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 0cb5b306)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>

2c34f16e

kvm: svm: Ensure an IBPB on all affected CPUs when freeing a vmcb · 022453db

Jim Mattson authored May 22, 2018

BugLink: https://bugs.launchpad.net/bugs/1811646

Previously, we only called indirect_branch_prediction_barrier on the
logical CPU that freed a vmcb. This function should be called on all
logical CPUs that last loaded the vmcb in question.

Fixes: 15d45071 ("KVM/x86: Add IBPB support")
Reported-by: Neel Natu <neelnatu@google.com>
Signed-off-by: Jim Mattson <jmattson@google.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(backported from commit fd65d314)
[juergh: Adjusted context.]
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>

022453db

KVM: VMX: fixes for vmentry_l1d_flush module parameter · eddf7123

Paolo Bonzini authored Aug 22, 2018

BugLink: https://bugs.launchpad.net/bugs/1811646

commit 0027ff2a upstream.

Two bug fixes:

1) missing entries in the l1d_param array; this can cause a host crash
if an access attempts to reach the missing entry. Future-proof the get
function against any overflows as well.  However, the two entries
VMENTER_L1D_FLUSH_EPT_DISABLED and VMENTER_L1D_FLUSH_NOT_REQUIRED must
not be accepted by the parse function, so disable them there.

2) invalid values must be rejected even if the CPU does not have the
bug, so test for them before checking boot_cpu_has(X86_BUG_L1TF)

... and a small refactoring, since the .cmd field is redundant with
the index in the array.
Reported-by: Bandan Das <bsd@redhat.com>
Cc: stable@vger.kernel.org
Fixes: a7b9020bSigned-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 8729412c linux-stable)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>

eddf7123

KVM: x86: SVM: Call x86_spec_ctrl_set_guest/host() with interrupts disabled · 7090ddd8

Thomas Gleixner authored Aug 12, 2018

BugLink: https://bugs.launchpad.net/bugs/1811646

commit 024d83ca upstream.

Mikhail reported the following lockdep splat:

WARNING: possible irq lock inversion dependency detected
CPU 0/KVM/10284 just changed the state of lock:
  000000000d538a88 (&st->lock){+...}, at:
  speculative_store_bypass_update+0x10b/0x170

but this lock was taken by another, HARDIRQ-safe lock
in the past:

(&(&sighand->siglock)->rlock){-.-.}

   and interrupts could create inverse lock ordering between them.

Possible interrupt unsafe locking scenario:

    CPU0                    CPU1
    ----                    ----
   lock(&st->lock);
                           local_irq_disable();
                           lock(&(&sighand->siglock)->rlock);
                           lock(&st->lock);
    <Interrupt>
     lock(&(&sighand->siglock)->rlock);
     *** DEADLOCK ***

The code path which connects those locks is:

   speculative_store_bypass_update()
   ssb_prctl_set()
   do_seccomp()
   do_syscall_64()

In svm_vcpu_run() speculative_store_bypass_update() is called with
interupts enabled via x86_virt_spec_ctrl_set_guest/host().

This is actually a false positive, because GIF=0 so interrupts are
disabled even if IF=1; however, we can easily move the invocations of
x86_virt_spec_ctrl_set_guest/host() into the interrupt disabled region to
cure it, and it's a good idea to keep the GIF=0/IF=1 area as small
and self-contained as possible.

Fixes: 1f50ddb4 ("x86/speculation: Handle HT correctly on AMD")
Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: kvm@vger.kernel.org
Cc: x86@kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit cd4574c1 linux-stable)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>

7090ddd8

KVM: X86: Allow userspace to define the microcode version · 14f4f72d

Wanpeng Li authored Feb 28, 2018

BugLink: https://bugs.launchpad.net/bugs/1811646

commit 518e7b94 upstream

Linux (among the others) has checks to make sure that certain features
aren't enabled on a certain family/model/stepping if the microcode version
isn't greater than or equal to a known good version.

By exposing the real microcode version, we're preventing buggy guests that
don't check that they are running virtualized (i.e., they should trust the
hypervisor) from disabling features that are effectively not buggy.
Suggested-by: Filippo Sironi <sironi@amazon.de>
Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: Liran Alon <liran.alon@oracle.com>
Cc: Nadav Amit <nadav.amit@gmail.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(backported from commit 7a1eac80 linux-stable)
[juergh: Adjusted context.]
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>

14f4f72d

KVM: SVM: Add MSR-based feature support for serializing LFENCE · 439c0459

Tom Lendacky authored Feb 24, 2018

BugLink: https://bugs.launchpad.net/bugs/1811646

commit d1d93fa9 upstream

In order to determine if LFENCE is a serializing instruction on AMD
processors, MSR 0xc0011029 (MSR_F10H_DECFG) must be read and the state
of bit 1 checked.  This patch will add support to allow a guest to
properly make this determination.

Add the MSR feature callback operation to svm.c and add MSR 0xc0011029
to the list of MSR-based features.  If LFENCE is serializing, then the
feature is supported, allowing the hypervisor to set the value of the
MSR that guest will see.  Support is also added to write (hypervisor only)
and read the MSR value for the guest.  A write by the guest will result in
a #GP.  A read by the guest will return the value as set by the host.  In
this way, the support to expose the feature to the guest is controlled by
the hypervisor.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(backported from commit 1a155ef3 linux-stable)
[juergh: Adjusted context.]
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>

439c0459

kvm: x86: IA32_ARCH_CAPABILITIES is always supported · 99571c1b

Jim Mattson authored May 09, 2018

BugLink: https://bugs.launchpad.net/bugs/1811646

commit 1eaafe91 upstream.

If there is a possibility that a VM may migrate to a Skylake host,
then the hypervisor should report IA32_ARCH_CAPABILITIES.RSBA[bit 2]
as being set (future work, of course). This implies that
CPUID.(EAX=7,ECX=0):EDX.ARCH_CAPABILITIES[bit 29] should be
set. Therefore, kvm should report this CPUID bit as being supported
whether or not the host supports it.  Userspace is still free to clear
the bit if it chooses.

For more information on RSBA, see Intel's white paper, "Retpoline: A
Branch Target Injection Mitigation" (Document Number 337131-001),
currently available at https://bugzilla.kernel.org/show_bug.cgi?id=199511.

Since the IA32_ARCH_CAPABILITIES MSR is emulated in kvm, there is no
dependency on hardware support for this feature.
Signed-off-by: Jim Mattson <jmattson@google.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Fixes: 28c1c9fa ("KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES")
Cc: stable@vger.kernel.org
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 9baf2bc5 linux-stable)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>

99571c1b

KVM/VMX: Optimize vmx_vcpu_run() and svm_vcpu_run() by marking the RDMSR path as unlikely() · 9eb2034f

Paolo Bonzini authored Feb 22, 2018

BugLink: https://bugs.launchpad.net/bugs/1811646

commit 946fbbc1 upstream.

vmx_vcpu_run() and svm_vcpu_run() are large functions, and giving
branch hints to the compiler can actually make a substantial cycle
difference by keeping the fast path contiguous in memory.

With this optimization, the retpoline-guest/retpoline-host case is
about 50 cycles faster.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jim Mattson <jmattson@google.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: KarimAllah Ahmed <karahmed@amazon.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: kvm@vger.kernel.org
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20180222154318.20361-3-pbonzini@redhat.comSigned-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f750e151 linux-stable)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>

9eb2034f

X86/nVMX: Properly set spec_ctrl and pred_cmd before merging MSRs · 431b849c

KarimAllah Ahmed authored Feb 10, 2018

BugLink: https://bugs.launchpad.net/bugs/1811646

commit 206587a9 upstream.

These two variables should check whether SPEC_CTRL and PRED_CMD are
supposed to be passed through to L2 guests or not. While
msr_write_intercepted_l01 would return 'true' if it is not passed through.

So just invert the result of msr_write_intercepted_l01 to implement the
correct semantics.
Signed-off-by: KarimAllah Ahmed <karahmed@amazon.de>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Jim Mattson <jmattson@google.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan.van.de.ven@intel.com
Cc: dave.hansen@intel.com
Cc: kvm@vger.kernel.org
Cc: sironi@amazon.de
Fixes: 086e7d4118cc ("KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL")
Link: http://lkml.kernel.org/r/1518305967-31356-5-git-send-email-dwmw@amazon.co.ukSigned-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 96652962 linux-stable)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>

431b849c

kvm: nVMX: VMCLEAR an active shadow VMCS after last use · cea54838

Jim Mattson authored Oct 28, 2016

BugLink: https://bugs.launchpad.net/bugs/1811646

After a successful VM-entry with the "VMCS shadowing" VM-execution
control set, the shadow VMCS referenced by the VMCS link pointer field
in the current VMCS becomes active on the logical processor.

A VMCS that is made active on more than one logical processor may become
corrupted. Therefore, before an active VMCS can be migrated to another
logical processor, the first logical processor must execute a VMCLEAR
for the active VMCS. VMCLEAR both ensures that all VMCS data are written
to memory and makes the VMCS inactive.
Signed-off-by: Jim Mattson <jmattson@google.com>
Reviewed-By: David Matlack <dmatlack@google.com>
Message-Id: <1477668579-22555-1-git-send-email-jmattson@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(backported from commit 355f4fb1)
[juergh:
 - Adjusted for already present alloc_loaded_vmcs().
 - Adjusted context.]
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>

cea54838

KVM: x86: avoid vmalloc(0) in the KVM_SET_CPUID · 750d62d4

Paolo Bonzini authored Jun 01, 2016

BugLink: https://bugs.launchpad.net/bugs/1811646

This causes an ugly dmesg splat.  Beautified syzkaller testcase:

    #include <unistd.h>
    #include <sys/syscall.h>
    #include <sys/ioctl.h>
    #include <fcntl.h>
    #include <linux/kvm.h>

    long r[8];

    int main()
    {
        struct kvm_cpuid2 c = { 0 };
        r[2] = open("/dev/kvm", O_RDWR);
        r[3] = ioctl(r[2], KVM_CREATE_VM, 0);
        r[4] = ioctl(r[3], KVM_CREATE_VCPU, 0x8);
        r[7] = ioctl(r[4], KVM_SET_CPUID, &c);
        return 0;
    }
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
(cherry picked from commit 83676e92)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>

750d62d4

UBUNTU: [Packaging] getabis -- support parsing a simple version · 11e04bcf

Andy Whitcroft authored Dec 04, 2018

BugLink: http://bugs.launchpad.net/bugs/1806380Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

11e04bcf

UBUNTU: [Packaging] getabis -- handle all known package combinations · 7a440069

Andy Whitcroft authored Dec 04, 2018

Traditionally we have tried to download all and any packages we can
find.  If we have any packages we just assume that what we got is a
consistent set and use it.  This leads to incomplete sets being
committed on network failure.

Firstly detect and differentiate transport errors and valid missing
packages.  Secondly switch to analysing known good package set
combinations; this relies on the presumption that the publisher
only publishes all or none of a binary package set.  This lets us
throw errors when we are unable to find an internally consistent
set of packages.

BugLink: http://bugs.launchpad.net/bugs/1806380Signed-off-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

7a440069

UBUNTU: [Config] buildinfo -- add retpoline version markers · 6a59a04a

Andy Whitcroft authored Jan 31, 2019

BugLink: http://bugs.launchpad.net/bugs/1806380Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

6a59a04a

UBUNTU: [Packaging] buildinfo -- add buildinfo support to getabis · 9e1691b7

Andy Whitcroft authored Aug 10, 2018

BugLink: http://bugs.launchpad.net/bugs/1806380Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

9e1691b7

UBUNTU: [Packaging] buildinfo -- add compiler information to the flavour ABI · 50551364

Andy Whitcroft authored Aug 08, 2018

In getabis we extract the compiler information from an arbitrary .ko.
As we will not have those when only using buildinfo ABI information we
need to collect the compiler information during the build.

50551364

UBUNTU: [Packaging] buildinfo -- add firmware information to the flavour ABI · 2f5dda5c

Andy Whitcroft authored Aug 08, 2018

In getabis we extract the firmware information from each of the .kos.
As we will not have those when only using buildinfo ABI information we
need to collect the firmware information during the build.

2f5dda5c

UBUNTU: [Packaging] buildinfo -- add basic build information · bfde3f18

Andy Whitcroft authored Feb 04, 2018

bfde3f18

UBUNTU: [Packaging] ABI -- accumulate abi information at the end of the build · fc1d8f88

Andy Whitcroft authored May 10, 2018

fc1d8f88

UBUNTU: [Packaging] commonise debhelper invocation · 9cb8e0ac

Andy Whitcroft authored Apr 20, 2018

9cb8e0ac

UBUNTU: [Packaging] limit preparation to linux-libc-dev in headers · a347495a

Andy Whitcroft authored Apr 16, 2018

a347495a

UBUNTU: [Packaging] Only install cloud init files when do_tools_common=true · 6d88ed7f

Marcelo Henrique Cerri authored Apr 04, 2018

Skip the inclusion of init file into the -cloud-tools-common package
when do_tools_common is false. That's necessary in order to support
linux-azure, that ships hyper-v tools but does not ship the common bits.

BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

6d88ed7f

UBUNTU: [debian] prep linux-libc-dev only if do_libc_dev_package=true · 3c448b0a

Kamal Mostafa authored Dec 13, 2017

Required for do_libc_dev_package=false to not break the build.

BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

3c448b0a

UBUNTU: [Packaging] add acpidbg · b0a53480

Andy Whitcroft authored Dec 17, 2018

BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

b0a53480

UBUNTU: [Packaging] skip cloud tools packaging when not building package · 2eafe44c

Seth Forshee authored Mar 15, 2018

Currently 3-binary-indep.mk performs cloud packaging steps if
do_tools_common is true, which can cause errors if the
cloud-tools package isn't defined in the control file. Make these
steps depend on do_cloud_tools and do_tools_hyperv as appropriate.

BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

2eafe44c

UBUNTU: [Packaging] signing should be conditional · 4f6629ff

Andy Whitcroft authored Dec 17, 2018

4f6629ff

UBUNTU: [Packaging] Add linux-tools-host package for VM host tools · 375d93f1

Seth Forshee authored Apr 05, 2018

BugLink: http://bugs.launchpad.net/bugs/1764794
OldBugLink: http://bugs.launchpad.net/bugs/1734130

IBM has requested that we package the kvm_stat tool from the
kernel source tree. This is a python script and thus is not
kernel-version specific. Because of this, and in order to avoid
adding a python dependency, this tool is not added to any
existing tools package.

Instead, create a new linux-tools-host package to contain tools
useful on VM hosts which will currently only contain kvm_stat.
Don't build this package unless specified in the architecture
rules file; it should only be built in the master kernel and in
a single architecture for any given series.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

375d93f1

UBUNTU: [debian] do not force do_tools_common · 286e4fe8

Kamal Mostafa authored Dec 13, 2017

286e4fe8

UBUNTU: [Debian] do_common_tools should always be on · b31a53ee

Andy Whitcroft authored Apr 02, 2015

do_common_tools is a mode specifier, it is on when we want tools and off
when we do not want tools. It is intended to be flipped by the bootstrap
modes. Whether those common tools are actually built is determined by
whether we are calling binary or binary-arch not related to whether we
want those packages to have content.

Enable this unconditionally. This allows us to build the indep packages
on any arch is needed.

b31a53ee

UBUNTU: [debian] support for ship_extras_package=false · 773ead84

Kamal Mostafa authored Dec 13, 2017

If optional .mk variable 'ship_extras_package' is explicitly set to false,
then do not construct the linux-image-extra package; instead just log all
of the "extra" modules which were pointlessly built yet won't be shipped.
This feature may be useful for config debugging and for custom kernel
development.

BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>

(cherry-picked from commit f16de3c17fcbbcf01c81f2897e4b8fe4a5ca470c bionic)
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>