~p-pisati/ubuntu/+source/linux-aws/+git/focal:cranky/aws

Last commit made on 2020-03-24
Get this branch:
git clone -b cranky/aws https://git.launchpad.net/~p-pisati/ubuntu/+source/linux-aws/+git/focal
Only Paolo Pisati can upload to this branch. If you are Paolo Pisati please log in for upload directions.

Branch merges

Branch information

Recent commits

3cfac9a... by Paolo Pisati

UBUNTU: Ubuntu-aws-5.4.0-1006.6

Signed-off-by: Paolo Pisati <email address hidden>

c47172e... by Paolo Pisati

UBUNTU: [Config] updateconfigs following Ubuntu-5.4.0-20.24 rebase

Signed-off-by: Paolo Pisati <email address hidden>

332be45... by Paolo Pisati

UBUNTU: link-to-tracker: update tracking bug

BugLink: https://bugs.launchpad.net/bugs/1868342
Properties: no-test-build
Signed-off-by: Paolo Pisati <email address hidden>

e7eb9b6... by Paolo Pisati

UBUNTU: Start new release

Ignore: yes
Signed-off-by: Paolo Pisati <email address hidden>

60e81c2... by Paolo Pisati

UBUNTU: [Packaging] update helper scripts

BugLink: https://bugs.launchpad.net/bugs/1786013
Signed-off-by: Paolo Pisati <email address hidden>

e729b79... by Frank van der Linden <email address hidden>

UBUNTU SAUCE [aws]: xen: Only restore the ACPI SCI interrupt in xen_restore_pirqs.

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

Restoring all PIRQs, which is the right thing to do, was causing problems
on larger instances. This is a horrible workaround until this issue is fully
understood.

Signed-off-by: Frank van der Linden <email address hidden>
Reviewed-by: Alakesh Haloi <email address hidden>
Reviewed-by: Anchal Agarwal <email address hidden>
Reviewed-by: Qian Lu <email address hidden>
Signed-off-by: Seth Forshee <email address hidden>

bfa753a... by Frank van der Linden <email address hidden>

UBUNTU SAUCE [aws]: xen: restore pirqs on resume from hibernation.

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

The hibernation code unlinks event channels from these (legacy) IRQs, so they
must be reinitialized on wakeup, much like in the Xen suspend/resume case.

Signed-off-by: Frank van der Linden <email address hidden>
Reviewed-by: Cristian Gafton <email address hidden>
Reviewed-by: Anchal Agarwal <email address hidden>
Reviewed-by: Alakesh Haloi <email address hidden>
Signed-off-by: Seth Forshee <email address hidden>

9f8901f... by Eduardo Valentin <email address hidden>

UBUNTU SAUCE [aws]: block: xen-blkfront: consider new dom0 features on restore

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

On regular start, the instance will perform a regular boot, in which rootfs
is mounted accordingly to the xen-blkback features (in particular
feature-barrier and feature-flush-cache). That will setup the journal
accordingly to the provided features on SB.
On a start from hibernation, the instance boots, detects that a hibernation
image is present, push the image to memory and jumps back where it was. There
is no regular mount of the rootfs, it uses the data structures already in
the previous saved memory image.
Now, When the instance hibernates, it may move from its original dom0 to a new dom0
when it is restarted.
So, given the above, if the xen-blkback features change then the guest
can be in trouble. And I see the original assumption was that the
dom0 environment would be preserved. I did a couple of experiments,
and I confirm that these particular features change quite a lot across
hibernation attempts:
[ 2343.157903] blkfront: xvda: barrier or flush: disabled; persistent grants: disabled; indirect descriptors: enabled;
[ 2444.712339] blkfront: xvda: barrier or flush: disabled; persistent grants: disabled; indirect descriptors: enabled;
[ 2537.105884] blkfront: xvda: flush diskcache: enabled; persistent grants: disabled; indirect descriptors: enabled;
[ 2636.641298] blkfront: xvda: barrier or flush: disabled; persistent grants: disabled; indirect descriptors: enabled;
[ 2729.868349] blkfront: xvda: flush diskcache: enabled; persistent grants: disabled; indirect descriptors: enabled;
[ 2827.118979] blkfront: xvda: flush diskcache: enabled; persistent grants: disabled; indirect descriptors: enabled;
[ 2924.812599] blkfront: xvda: flush diskcache: enabled; persistent grants: disabled; indirect descriptors: enabled;
[ 3018.063399] blkfront: xvda: flush diskcache: enabled; persistent grants: disabled; indirect descriptors: enabled;
[ 3116.685040] blkfront: xvda: flush diskcache: enabled; persistent grants: disabled; indirect descriptors: enabled;
[ 3209.164475] blkfront: xvda: barrier or flush: disabled; persistent grants: disabled; indirect descriptors: enabled;
[ 3317.981362] blkfront: xvda: barrier or flush: disabled; persistent grants: disabled; indirect descriptors: enabled;
[ 3415.939725] blkfront: xvda: flush diskcache: enabled; persistent grants: disabled; indirect descriptors: enabled;
[ 3514.202478] blkfront: xvda: barrier or flush: disabled; persistent grants: disabled; indirect descriptors: enabled;
[ 3619.355791] blkfront: xvda: barrier or flush: disabled; persistent grants: disabled; indirect descriptors: enabled;

Now, considering the above, this patch fixes the following scenario:
a. Instance boots and sets up bio queue on a dom0 A with softbarrier supported.
b. hibernates
c. When asked to restore, the instance is back on dom0 B with unsupported
softbarrier.
d. Restoration goes well until next journal commit is issued. Remember that
it is still using the previous image rootfs data structures, therefore
is gonna request a softbarrier.
e. The bio will error out and throw a "operation not supported" message
and cause the journal to fail, and it will decide to remount
the rootfs as RO.
[ 1138.909290] print_req_error: operation not supported error, dev xvda, sector 4470400, flags 6008
[ 1139.025685] Aborting journal on device xvda1-8.
[ 1139.029758] print_req_error: operation not supported error, dev xvda, sector 4460544, flags 26008
[ 1139.326119] Buffer I/O error on dev xvda1, logical block 0, lost sync page write
[ 1139.331398] EXT4-fs error (device xvda1): ext4_journal_check_start:61: Detected aborted journal
[ 1139.337296] EXT4-fs (xvda1): Remounting filesystem read-only
[ 1139.341006] EXT4-fs (xvda1): previous I/O error to superblock detected
[ 1139.345704] print_req_error: operation not supported error, dev xvda, sector 4096, flags 26008

The fix is essentially to read xenbus to query the new xen
blkback capabilities and update them into the request queue.

Reviewed-by: Balbir Singh <email address hidden>
Reviewed-by: Vallish Vaidyeshwara <email address hidden>
Signed-off-by: Eduardo Valentin <email address hidden>
Signed-off-by: Seth Forshee <email address hidden>

eadd2c0... by Anchal Agarwal <email address hidden>

UBUNTU SAUCE [aws]: ACPICA: Enable sleep button on ACPI legacy wake

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

Currently we do not see sleep_enable bit set after guest resumes from
hibernation. Hibernation is triggered in guest on receiving a sleep
trigger from the hypervisor(S4 state). We see that power button is enabled
on wake up however sleep button isn't. This causes 2nd sleep trigger to fail
since PMEN register does not have bit 9 set in its register on resume which
is expected by hypervisor to be set before it can send an SCI interrupt to
the guest.
Expected PMEN=0x320 on fresh boot however, after resume PMEN=0x120

Signed-off-by: Anchal Agarwal <email address hidden>
Reviewed-by: Balbir Singh <email address hidden>
Reviewed-by: Frank van der Linden <email address hidden>
Signed-off-by: Seth Forshee <email address hidden>

6f135bb... by Andrea Righi

UBUNTU SAUCE [aws]: PM / hibernate: set image_size to 0 by default

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

The main bottleneck during hibernation is writing the image to disk.
Set image_size to 0 by default so that the kernel is forced to make the
image as small as possible and reduce in this way the amount of I/O.

Signed-off-by: Andrea Righi <email address hidden>
Signed-off-by: Seth Forshee <email address hidden>