[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#975269: marked as done (buster-pu: package linux/TBD - arm64 stolen time support)

Your message dated Fri, 05 Aug 2022 20:17:17 +0100
with message-id <b4ef52ba579802678e1b437463282cc1e879eb5f.camel@adam-barratt.org.uk>
and subject line Re: Bug#975269: buster-pu: package linux/TBD - arm64 stolen time support
has caused the Debian Bug report #975269,
regarding buster-pu: package linux/TBD - arm64 stolen time support
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
975269: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975269
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian.org@packages.debian.org
Usertags: pu
X-Debbugs-Cc: noahm@debian.org

There are two parts to the proposed changes:

1. Support in arm64 KVM code for reporting stolen time to guests.
2. Support in arm64 paravirtualised guest code for requesting stolen
   time from the hypervisor and reporting it to user-space.

I think part 1 is not suitable for a stable update, but part 2 might
be.

[ Reason ]

Noah Meyerhans wrote in bug #969443:
> When used in virtual machine environments, Linux on amd64 is able to report
> "steal time" to the guest.  This functionality has been supported by Linux
> on amd64 for years, but was only added to arm64 with Linux 5.5.
> 
> As Debian and arm64 are increasingly used in virtual environments, including
> cloud environments, the ability to report steal time is increasingly
> important for system monitoring and performance analysis.  Thus, I'd like to
> request that CPU steal time accounting support for arm64 be backported to
> buster, if possible.

[ Impact ]

Without this, it's difficult to determine when VM performance is being
affected by stolen time.

[ Tests ]

Noah has tested the changes (at least part 2) in an arm64 KVM
environment with steal time reporting, presumably AWS EC2.

[ Risks ]

There is a potential to regress VM host and/or guest support on arm64
and armhf, depending on which part(s) are applied.

[ Changes ]

1. * KVM: arm64: Document PV-time interface
   * KVM: arm/arm64: Factor out hypercall handling from PSCI
   * KVM: arm64: Implement PV_TIME_FEATURES call
   * KVM: Implement kvm_put_guest()
   * KVM: arm64: Support stolen time reporting via shared
   * KVM: Allow kvm_device_ops to be const
   * KVM: arm64: Provide VCPU attributes for stolen time
2. * arm/arm64: smccc/psci: add arm_smccc_1_1_get_conduit()
   * arm/arm64: Provide a wrapper for SMCCC 1.1 calls
   * arm/arm64: Make use of the SMCCC 1.1 wrapper
   * arm64: Retrieve stolen time as paravirtualized guest

The actual patches are visible at
<https://salsa.debian.org/kernel-team/linux/-/merge_requests/268>.

Ben.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-2-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

--- End Message ---
--- Begin Message --- 
On Thu, 2020-11-19 at 18:58 +0000, Ben Hutchings wrote:
> There are two parts to the proposed changes:
> 
> 1. Support in arm64 KVM code for reporting stolen time to guests.
> 2. Support in arm64 paravirtualised guest code for requesting stolen
>    time from the hypervisor and reporting it to user-space.
> 
> I think part 1 is not suitable for a stable update, but part 2 might
> be.
> 

Apologies for the fact that this somehow apparently never got a
response.

Given the timing, I think it probably makes more sense for this to be
part of an LTS update now.

Regards,

Adan

--- End Message ---
Reply to: