date:20240112

[Kernel-packages] [Bug 2049245] [NEW] package nvidia-dkms-390 390.157-0ubuntu0.22.04.2 failed to install/upgrade: installed nvidia-dkms-390 package post-installation script subprocess returned error e

2024-01-12 Thread Miroslav Doliak

Public bug reported:

cannot select screen resolution other then 1024 X 768 after implementing
the latest ubuntu update.

ProblemType: Package
DistroRelease: Ubuntu 22.04
Package: nvidia-dkms-390 390.157-0ubuntu0.22.04.2
ProcVersionSignature: Ubuntu 6.5.0-14.14~22.04.1-generic 6.5.3
Uname: Linux 6.5.0-14-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.5
AptOrdering:
 nvidia-kernel-source-390:amd64: Install
 nvidia-kernel-common-390:amd64: Install
 nvidia-dkms-390:amd64: Install
 NULL: ConfigurePending
Architecture: amd64
CasperMD5CheckResult: pass
Date: Sat Jan 13 15:29:03 2024
ErrorMessage: installed nvidia-dkms-390 package post-installation script 
subprocess returned error exit status 10
InstallationDate: Installed on 2023-05-04 (253 days ago)
InstallationMedia: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 
(20230223)
Python3Details: /usr/bin/python3.10, Python 3.10.12, python3-minimal, 
3.10.6-1~22.04
PythonDetails: N/A
RelatedPackageVersions:
 dpkg 1.21.1ubuntu2.2
 apt  2.4.11
SourcePackage: nvidia-graphics-drivers-390
Title: package nvidia-dkms-390 390.157-0ubuntu0.22.04.2 failed to 
install/upgrade: installed nvidia-dkms-390 package post-installation script 
subprocess returned error exit status 10
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: nvidia-graphics-drivers-390 (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-package jammy need-duplicate-check

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to nvidia-graphics-drivers-390 in Ubuntu.
https://bugs.launchpad.net/bugs/2049245

Title:
  package nvidia-dkms-390 390.157-0ubuntu0.22.04.2 failed to
  install/upgrade: installed nvidia-dkms-390 package post-installation
  script subprocess returned error exit status 10

Status in nvidia-graphics-drivers-390 package in Ubuntu:
  New

Bug description:
  cannot select screen resolution other then 1024 X 768 after
  implementing the latest ubuntu update.

  ProblemType: Package
  DistroRelease: Ubuntu 22.04
  Package: nvidia-dkms-390 390.157-0ubuntu0.22.04.2
  ProcVersionSignature: Ubuntu 6.5.0-14.14~22.04.1-generic 6.5.3
  Uname: Linux 6.5.0-14-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.5
  AptOrdering:
   nvidia-kernel-source-390:amd64: Install
   nvidia-kernel-common-390:amd64: Install
   nvidia-dkms-390:amd64: Install
   NULL: ConfigurePending
  Architecture: amd64
  CasperMD5CheckResult: pass
  Date: Sat Jan 13 15:29:03 2024
  ErrorMessage: installed nvidia-dkms-390 package post-installation script 
subprocess returned error exit status 10
  InstallationDate: Installed on 2023-05-04 (253 days ago)
  InstallationMedia: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 
(20230223)
  Python3Details: /usr/bin/python3.10, Python 3.10.12, python3-minimal, 
3.10.6-1~22.04
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.21.1ubuntu2.2
   apt  2.4.11
  SourcePackage: nvidia-graphics-drivers-390
  Title: package nvidia-dkms-390 390.157-0ubuntu0.22.04.2 failed to 
install/upgrade: installed nvidia-dkms-390 package post-installation script 
subprocess returned error exit status 10
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-390/+bug/2049245/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 2043249] Re: Bluetooth AX101 Intel don't work (N100)

2024-01-12 Thread Launchpad Bug Tracker

[Expired for linux (Ubuntu) because there has been no activity for 60
days.]

** Changed in: linux (Ubuntu)
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2043249

Title:
  Bluetooth AX101 Intel don't work (N100)

Status in linux package in Ubuntu:
  Expired

Bug description:
  Hi,

  I have a chuwi minibook N100 with bluetooth AX101. The bluetooth is
  not working, the bluetooth switch in the settings menu is not
  activated because the Intel AX101 component is not recognized.
  Therefore the Intel AX101 bluetooth does not work.

  The system is Ubuntu 23.04.1 with Intel N100, 16GB of Ram and 1TB of
  disk. The wifi does work.

  Please solution.

  Thanks
  --- 
  ProblemType: Bug
  ApportVersion: 2.27.0-0ubuntu5
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  javnisa1809 F wireplumber
   /dev/snd/seq:javnisa1797 F pipewire
  CRDA: N/A
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  DistroRelease: Ubuntu 23.10
  InstallationDate: Installed on 2023-11-10 (3 days ago)
  InstallationMedia: Ubuntu 23.10.1 "Mantic Minotaur" - Release amd64 
(20231016.1)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 1b0a:2bc9 HYGD-220831-A Hy-Usb2.0-1*MIC
   Bus 001 Device 003: ID 8087:0026 Intel Corp. AX201 Bluetooth
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: {report['dmi.sys.vendor']} {report['dmi.product.name']}
  Package: linux (not installed)
  ProcEnviron:
   LANG=es_ES.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   TERM=xterm-256color
   XDG_RUNTIME_DIR=
  ProcFB: 0 i915drmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.5.0-10-generic 
root=UUID=3ccb0f1d-dfa9-46fa-a648-03dee97946b5 ro quiet splash vt.handoff=7
  ProcVersionSignature: Ubuntu 6.5.0-10.10-generic 6.5.3
  RelatedPackageVersions:
   linux-restricted-modules-6.5.0-10-generic N/A
   linux-backports-modules-6.5.0-10-generic  N/A
   linux-firmware20230919.git3672ccab-0ubuntu2.1
  Tags: mantic wayland-session
  Uname: Linux 6.5.0-10-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sudo users
  _MarkForUpload: True
  dmi.bios.date: 07/19/2023
  dmi.bios.release: 2.9
  dmi.bios.vendor: American Megatrends International, LLC.
  dmi.bios.version: DNN20 V2.09
  dmi.board.asset.tag: Default string
  dmi.board.name: Default string
  dmi.board.vendor: Default string
  dmi.board.version: Default string
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 10
  dmi.chassis.vendor: Default string
  dmi.chassis.version: Default string
  dmi.ec.firmware.release: 0.13
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInternational,LLC.:bvrDNN20V2.09:bd07/19/2023:br2.9:efr0.13:svnCHUWIInnovationAndTechnology(ShenZhen)co.,Ltd:pnMiniBookX:pvrDefaultstring:rvnDefaultstring:rnDefaultstring:rvrDefaultstring:cvnDefaultstring:ct10:cvrDefaultstring:skuDefaultstring:
  dmi.product.family: Default string
  dmi.product.name: MiniBook X
  dmi.product.sku: Default string
  dmi.product.version: Default string
  dmi.sys.vendor: CHUWI Innovation And Technology(ShenZhen)co.,Ltd

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2043249/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 2049242] [NEW] CIFS Mounts Keep Load Average at n+1

2024-01-12 Thread Doug Harple

Public bug reported:

Today I noticed that my two primary Ubuntu boxes were running at high
load.  After investigation, I discovered at that unmounting their CIFS
shares alleviating the high load.

I rebooted to the previous kernel, linux-modules-6.2.0-39-generic, and
saw that the load was low after everything had settled after startup.

I rebooted to the current kernel, linux-modules-6.5.0-14-generic, and
again saw the high load.

The load appears to be n+1, where n is the number of CIFS mounts.
(Based on a sample of two boxes.)

I confirmed that the default mount options (e.g. the ones not specified
in fstab) are the same between the two kernels.

This *might* also be slowing down external (USB  disk access.  I'm still
investigating that.

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: linux-image-6.5.0-14-generic 6.5.0-14.14~22.04.1
ProcVersionSignature: Ubuntu 6.5.0-14.14~22.04.1-generic 6.5.3
Uname: Linux 6.5.0-14-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
Date: Fri Jan 12 19:47:25 2024
InstallationDate: Installed on 2020-10-01 (1198 days ago)
InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: linux-signed-hwe-6.5
UpgradeStatus: Upgraded to jammy on 2023-01-01 (376 days ago)

** Affects: linux-signed-hwe-6.5 (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug jammy third-party-packages wayland-session

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed-hwe-6.5 in Ubuntu.
https://bugs.launchpad.net/bugs/2049242

Title:
  CIFS Mounts Keep Load Average at n+1

Status in linux-signed-hwe-6.5 package in Ubuntu:
  New

Bug description:
  Today I noticed that my two primary Ubuntu boxes were running at high
  load.  After investigation, I discovered at that unmounting their CIFS
  shares alleviating the high load.

  I rebooted to the previous kernel, linux-modules-6.2.0-39-generic, and
  saw that the load was low after everything had settled after startup.

  I rebooted to the current kernel, linux-modules-6.5.0-14-generic, and
  again saw the high load.

  The load appears to be n+1, where n is the number of CIFS mounts.
  (Based on a sample of two boxes.)

  I confirmed that the default mount options (e.g. the ones not
  specified in fstab) are the same between the two kernels.

  This *might* also be slowing down external (USB  disk access.  I'm
  still investigating that.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: linux-image-6.5.0-14-generic 6.5.0-14.14~22.04.1
  ProcVersionSignature: Ubuntu 6.5.0-14.14~22.04.1-generic 6.5.3
  Uname: Linux 6.5.0-14-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.5
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Jan 12 19:47:25 2024
  InstallationDate: Installed on 2020-10-01 (1198 days ago)
  InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: linux-signed-hwe-6.5
  UpgradeStatus: Upgraded to jammy on 2023-01-01 (376 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-6.5/+bug/2049242/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 2049242] Re: CIFS Mounts Keep Load Average at n+1

2024-01-12 Thread Doug Harple

Mount options (all names and IPs redacted):

# mount | grep mount-name | sed -e's/,/\n,/g'
//server-name/mount-name on /mnt/mount-name type cifs (rw
,relatime
,vers=3.1.1
,cache=strict
,username=client-name
,domain=domain-name
,uid=0
,noforceuid
,gid=0
,noforcegid
,addr=192.1.1.123
,file_mode=0600
,dir_mode=0700
,seal
,soft
,nounix
,serverino
,mapposix
,mfsymlinks
,rsize=4194304
,wsize=4194304
,bsize=1048576
,echo_interval=60
,actimeo=1
,closetimeo=1)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed-hwe-6.5 in Ubuntu.
https://bugs.launchpad.net/bugs/2049242

Title:
  CIFS Mounts Keep Load Average at n+1

Status in linux-signed-hwe-6.5 package in Ubuntu:
  New

Bug description:
  Today I noticed that my two primary Ubuntu boxes were running at high
  load.  After investigation, I discovered at that unmounting their CIFS
  shares alleviating the high load.

  I rebooted to the previous kernel, linux-modules-6.2.0-39-generic, and
  saw that the load was low after everything had settled after startup.

  I rebooted to the current kernel, linux-modules-6.5.0-14-generic, and
  again saw the high load.

  The load appears to be n+1, where n is the number of CIFS mounts.
  (Based on a sample of two boxes.)

  I confirmed that the default mount options (e.g. the ones not
  specified in fstab) are the same between the two kernels.

  This *might* also be slowing down external (USB  disk access.  I'm
  still investigating that.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: linux-image-6.5.0-14-generic 6.5.0-14.14~22.04.1
  ProcVersionSignature: Ubuntu 6.5.0-14.14~22.04.1-generic 6.5.3
  Uname: Linux 6.5.0-14-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.5
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Jan 12 19:47:25 2024
  InstallationDate: Installed on 2020-10-01 (1198 days ago)
  InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: linux-signed-hwe-6.5
  UpgradeStatus: Upgraded to jammy on 2023-01-01 (376 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-6.5/+bug/2049242/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 2045505] Re: Kernel cannot detect HDMI connection

2024-01-12 Thread Launchpad Bug Tracker

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: linux-signed-hwe-6.2 (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed-hwe-6.2 in Ubuntu.
https://bugs.launchpad.net/bugs/2045505

Title:
  Kernel cannot detect HDMI connection

Status in linux-signed-hwe-6.2 package in Ubuntu:
  Confirmed

Bug description:
  Hie,

  I have the same problem than
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1994144
  with my computer HP 17-cn2119 under Kubuntu 22.04. I tried also Kubuntu 23.04 
and 23.10, xorg and wayland, same problem. I also tested openSuse 15.5 and 
there was the same issue.

  Screen and HDMI cable worked with the previous computer HP 17-p128nf, and 
work actually on Windows 11 (dualboot).
  Seems to be a Linux problem.

  Thank you for your help

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: linux-image-6.2.0-37-generic 6.2.0-37.38~22.04.1
  ProcVersionSignature: Ubuntu 6.2.0-37.38~22.04.1-generic 6.2.16
  Uname: Linux 6.2.0-37-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.5
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: KDE
  Date: Sun Dec  3 15:09:53 2023
  InstallationDate: Installed on 2023-12-03 (0 days ago)
  InstallationMedia: Kubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 
(20230807.1)
  SourcePackage: linux-signed-hwe-6.2
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-6.2/+bug/2045505/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 2045505] Re: Kernel cannot detect HDMI connection

2024-01-12 Thread Ángel

I have been helping troubleshoot the same issue where HDMI stopped working on a
Ubuntu 22.04 that had just been upgraded. You beat me to reporting it.
The issue was finally determined to be caused by a kernel version upgrade.
Booting from the previous kernel (as selected on GRUB) the problem is gone.

guillaume2a, try installing linux-image-6.2.0-36-generic and *booting*
that kernel version (it will probably not be chosen as default). I
expect your HDMI screen will work with that one.

--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed-hwe-6.2 in Ubuntu.
https://bugs.launchpad.net/bugs/2045505

Title:
Kernel cannot detect HDMI connection

Status in linux-signed-hwe-6.2 package in Ubuntu:
New

Bug description:
Hie,

I have the same problem than
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1994144
with my computer HP 17-cn2119 under Kubuntu 22.04. I tried also Kubuntu 23.04
and 23.10, xorg and wayland, same problem. I also tested openSuse 15.5 and
there was the same issue.

Screen and HDMI cable worked with the previous computer HP 17-p128nf, and
work actually on Windows 11 (dualboot).
Seems to be a Linux problem.

Thank you for your help

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: linux-image-6.2.0-37-generic 6.2.0-37.38~22.04.1
ProcVersionSignature: Ubuntu 6.2.0-37.38~22.04.1-generic 6.2.16
Uname: Linux 6.2.0-37-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: KDE
Date: Sun Dec 3 15:09:53 2023
InstallationDate: Installed on 2023-12-03 (0 days ago)
InstallationMedia: Kubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64
(20230807.1)
SourcePackage: linux-signed-hwe-6.2
UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-6.2/+bug/2045505/+subscriptions

--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 2042853] Re: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough

2024-01-12 Thread Boris Barth

I re-added the tags "verification-done-lunar-linux 
verification-done-mantic-linux" manually as they were deleted by the bridge 
(bugproxy) when syncing the target milestone. 
This problem of disappearing tags has been seen lately also in other bugs / LP 
items. IBM is currently investigating what's causing this.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2042853

Title:
  [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Lunar:
  Fix Committed
Status in linux source package in Mantic:
  Fix Committed
Status in linux source package in Noble:
  Fix Committed

Bug description:
  SRU Justification:

  [Impact]

   * Today no s390x-specific vfio-pci devices (zPCI) can be passed
 from a KVM host to a KVM guest (incl. secure execution guests
 in the context of confidential computing).

   * s390x PCI passthrough needs various changes in the s390x kernel zPCI
 code (incl. the new s390x-specific Kernel config option
 'CONFIG_VFIO_PCI_ZDEV_KVM') that were introduced with kernel 6.0
 and got backported to 22.04/jammy as part of LP: #1853306.

   * Lunar an newer Ubuntu releases have the code already included from
 upstream (incl. the Kernel option 'CONFIG_VFIO_PCI_ZDEV_KVM'), but the
 config option is not set, hence zPCI pass-through is still not possible.

  [Fix]

   * To be able to make use of VFIO zPCI pass-through on s390x running newer
 Ubuntu releases (especially needed in the context of secure execution)
 the (s390x-specific) Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM' needs
 to be enabled and set to 'y'.

  [Test Case]

   * Hardware used: z14 or greater LPAR, PCI-attached devices
 (RoCE VFs, ISM devices, NVMe drive)

   * Setup: Both the kernel and QEMU features are needed for the feature
 to function (an upstream QEMU can be used to verify the kernel early),
 and the facility is only available on z14 or newer.
 When any of those pieces is missing,
 the interpretation facility will not be used.
 When both the kernel and QEMU features are included in their respective
 packages, and running in an LPAR on a z14 or newer machine,
 this feature will be enabled automatically.
 Existing supported devices should behave as before with no changes
 required by an end-user (e.g. no changes to libvirt domain definitions)
 -- but will now make use of the interpretation facility.
 Additionally, ISM devices will now be eligible for vfio-pci passthrough
 (where before QEMU would exit on error if attempting to provide an ISM
 device for vfio-pci passthrough, preventing the guest from starting)

   * Testing will include the following scenarios, repeated each for RoCE,
 ISM and NVMe:

 1) Testing of basic device passthrough (create a VM with a vfio-pci
device as part of the libvirt domain definition, passing through
a RoCE VF, an ISM device, or an NVMe drive. Verify that the device
is available in the guest and functioning)
 2) Testing of device hotplug/unplug (create a VM with a vfio-pci device,
virsh detach-device to remove the device from the running guest,
verify the device is removed from the guest, then virsh attach-device
to hotplug the device to the guest again, verify the device functions
in the guest)
 3) Host power off testing: Power off the device from the host, verify
that the device is unplugged from the guest as part of the poweroff
 4) Guest power off testing: Power off the device from within the guest,
verify that the device is unusable in the guest,
power the device back on within the guest and verify that the device
is once again usable.
 5) Guest reboot testing: (create a VM with a vfio-pci device,
verify the device is in working condition, reboot the guest,
verify that the device is still usable after reboot)

  [Regression Potential]

   * The regression potential is moderate, since the code is upstream
 for quite a while and already enabled in jammy.

   * The general way on using passthrough has not changed, with this
 change (config option) it's now just possible to passthrough
 zPCI on top.

   * CCW devices are not affected.

   * And this is s390x-specific anyway, so no other architectures are
  affected.

  [Other]

   * The enabling of the kernel config option is exactly the same for L, M
 and U/N, but I submitted separate patches due to slightly different context
 and offsets.
  __

  === Description by mjros...@us.ibm.com  ===

  LP#1853306 / IBM bug 182254 backported the necessary kernel pieces to
  enable enhanced interpretation of PCI passthrough on s390.  It also

[Kernel-packages] [Bug 2049226] Re: package nvidia-dkms-390 390.157-0ubuntu0.22.04.2 failed to install/upgrade: installed nvidia-dkms-390 package post-installation script subprocess returned error exi

2024-01-12 Thread Launchpad Bug Tracker

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: nvidia-graphics-drivers-390 (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to nvidia-graphics-drivers-390 in Ubuntu.
https://bugs.launchpad.net/bugs/2049226

Title:
  package nvidia-dkms-390 390.157-0ubuntu0.22.04.2 failed to
  install/upgrade: installed nvidia-dkms-390 package post-installation
  script subprocess returned error exit status 10

Status in nvidia-graphics-drivers-390 package in Ubuntu:
  Confirmed

Bug description:
  After software update only one screen is working with reduced
  resolution

  ProblemType: Package
  DistroRelease: Ubuntu 22.04
  Package: nvidia-dkms-390 390.157-0ubuntu0.22.04.2
  ProcVersionSignature: Ubuntu 6.5.0-14.14~22.04.1-generic 6.5.3
  Uname: Linux 6.5.0-14-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.5
  Architecture: amd64
  CasperMD5CheckResult: pass
  Date: Fri Jan 12 18:55:09 2024
  ErrorMessage: installed nvidia-dkms-390 package post-installation script 
subprocess returned error exit status 10
  InstallationDate: Installed on 2022-04-23 (628 days ago)
  InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 
(20220419)
  Python3Details: /usr/bin/python3.10, Python 3.10.12, python3-minimal, 
3.10.6-1~22.04
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.21.1ubuntu2.2
   apt  2.4.11
  SourcePackage: nvidia-graphics-drivers-390
  Title: package nvidia-dkms-390 390.157-0ubuntu0.22.04.2 failed to 
install/upgrade: installed nvidia-dkms-390 package post-installation script 
subprocess returned error exit status 10
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-390/+bug/2049226/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 2042853] Re: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough

2024-01-12 Thread Boris Barth

** Tags added: verification-done-lunar-linux verification-done-mantic-
linux

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2042853

Title:
  [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Lunar:
  Fix Committed
Status in linux source package in Mantic:
  Fix Committed
Status in linux source package in Noble:
  Fix Committed

Bug description:
  SRU Justification:

  [Impact]

   * Today no s390x-specific vfio-pci devices (zPCI) can be passed
 from a KVM host to a KVM guest (incl. secure execution guests
 in the context of confidential computing).

   * s390x PCI passthrough needs various changes in the s390x kernel zPCI
 code (incl. the new s390x-specific Kernel config option
 'CONFIG_VFIO_PCI_ZDEV_KVM') that were introduced with kernel 6.0
 and got backported to 22.04/jammy as part of LP: #1853306.

   * Lunar an newer Ubuntu releases have the code already included from
 upstream (incl. the Kernel option 'CONFIG_VFIO_PCI_ZDEV_KVM'), but the
 config option is not set, hence zPCI pass-through is still not possible.

  [Fix]

   * To be able to make use of VFIO zPCI pass-through on s390x running newer
 Ubuntu releases (especially needed in the context of secure execution)
 the (s390x-specific) Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM' needs
 to be enabled and set to 'y'.

  [Test Case]

   * Hardware used: z14 or greater LPAR, PCI-attached devices
 (RoCE VFs, ISM devices, NVMe drive)

   * Setup: Both the kernel and QEMU features are needed for the feature
 to function (an upstream QEMU can be used to verify the kernel early),
 and the facility is only available on z14 or newer.
 When any of those pieces is missing,
 the interpretation facility will not be used.
 When both the kernel and QEMU features are included in their respective
 packages, and running in an LPAR on a z14 or newer machine,
 this feature will be enabled automatically.
 Existing supported devices should behave as before with no changes
 required by an end-user (e.g. no changes to libvirt domain definitions)
 -- but will now make use of the interpretation facility.
 Additionally, ISM devices will now be eligible for vfio-pci passthrough
 (where before QEMU would exit on error if attempting to provide an ISM
 device for vfio-pci passthrough, preventing the guest from starting)

   * Testing will include the following scenarios, repeated each for RoCE,
 ISM and NVMe:

 1) Testing of basic device passthrough (create a VM with a vfio-pci
device as part of the libvirt domain definition, passing through
a RoCE VF, an ISM device, or an NVMe drive. Verify that the device
is available in the guest and functioning)
 2) Testing of device hotplug/unplug (create a VM with a vfio-pci device,
virsh detach-device to remove the device from the running guest,
verify the device is removed from the guest, then virsh attach-device
to hotplug the device to the guest again, verify the device functions
in the guest)
 3) Host power off testing: Power off the device from the host, verify
that the device is unplugged from the guest as part of the poweroff
 4) Guest power off testing: Power off the device from within the guest,
verify that the device is unusable in the guest,
power the device back on within the guest and verify that the device
is once again usable.
 5) Guest reboot testing: (create a VM with a vfio-pci device,
verify the device is in working condition, reboot the guest,
verify that the device is still usable after reboot)

  [Regression Potential]

   * The regression potential is moderate, since the code is upstream
 for quite a while and already enabled in jammy.

   * The general way on using passthrough has not changed, with this
 change (config option) it's now just possible to passthrough
 zPCI on top.

   * CCW devices are not affected.

   * And this is s390x-specific anyway, so no other architectures are
  affected.

  [Other]

   * The enabling of the kernel config option is exactly the same for L, M
 and U/N, but I submitted separate patches due to slightly different context
 and offsets.
  __

  === Description by mjros...@us.ibm.com  ===

  LP#1853306 / IBM bug 182254 backported the necessary kernel pieces to
  enable enhanced interpretation of PCI passthrough on s390.  It also
  included a kernel config update for CONFIG_VFIO_PCI_ZDEV_KVM=y which
  is necessary to activate this kernel feature.

  For lunar and mantic, the kernel code did not require backporting due
  to the base kernel version already containing it,

[Kernel-packages] [Bug 2044657] Re: Multiple data corruption issues in zfs

2024-01-12 Thread Matthew Bradley

>Should we quickly do such a minimal backport to get that fix out
quickly

Unequivocally, yes. It has been several weeks and users of ZFS across
multiple releases are still exposed to a data corruption bug. The fix
should go out asap, especially when it's only a single-line fix.

This bug has already been fixed in every other OS supporting ZFS. Even
if the bug is rare on older versions of ZFS, it's extremely troubling to
users when data corruption fixes aren't rolled out in a timely manor.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
https://bugs.launchpad.net/bugs/2044657

Title:
  Multiple data corruption issues in zfs

Status in zfs-linux package in Ubuntu:
  Fix Released
Status in zfs-linux source package in Xenial:
  Confirmed
Status in zfs-linux source package in Bionic:
  Confirmed
Status in zfs-linux source package in Focal:
  Confirmed
Status in zfs-linux source package in Jammy:
  Confirmed
Status in zfs-linux source package in Lunar:
  Confirmed
Status in zfs-linux source package in Mantic:
  Incomplete
Status in zfs-linux source package in Noble:
  Fix Released

Bug description:
  [ Impact ]

   * Multiple data corruption issues have been identified and fixed in
  ZFS. Some of them, at varying real-life reproducibility frequency have
  been deterimed to affect very old zfs releases. Recommendation is to
  upgrade to 2.2.2 or 2.1.14 or backport dnat patch alone. This is to
  ensure users get other potentially related fixes and runtime tunables
  to possibly mitigate other bugs that are related and are being fixed
  upstream for future releases.

   * For jammy the 2.1.14 upgrade will bring HWE kernel support and also
  compatiblity/support for hardened kernel builds that mitigate SLS
  (straight-line-speculation).

  [ Test Plan ]

   * !!! Danger !!! use reproducer from
  https://zfsonlinux.topicbox.com/groups/zfs-discuss/T12876116b8607cdb
  and confirm if that issue is resolved or not. Do not run on production
  ZFS pools / systems.

   * autopkgtest pass (from https://ubuntu-archive-
  team.ubuntu.com/proposed-migration/ )

   * adt-matrix pass (from https://kernel.ubuntu.com/adt-matrix/ )

   * kernel regression zfs testsuite pass (from Kernel team RT test
  results summary, private)

   * zsys integration test pass (upgrade of zsys installed systems for
  all releases)

   * zsys install test pass (for daily images of LTS releases only that
  have such installer support, as per iso tracker test case)

   * LXD (ping LXD team to upgrade vendored in tooling to 2.2.2 and
  2.1.14, and test LXD on these updated kernels)

  
  [ Where problems could occur ]

   * Upgrade to 2.1.14 on jammy with SLS mitigations compatiblity will 
introduce slight slow down on amd64 (for hw accelerated assembly code-paths 
only in the encryption primitives)
   
   * Uncertain of the perfomance impact of the extra checks in dnat patch fix 
itself. Possibly affecting speed of operation, at the benefit of correctness.

  [ Other Info ]
   
   * https://github.com/openzfs/zfs/pull/15571 is most current consideration of 
affairs

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2044657/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 2040522] Re: gVNIC DQO-QPL feature

2024-01-12 Thread John Cabaj

** Changed in: linux-gcp (Ubuntu Jammy)
 Assignee: (unassigned) => John Cabaj (john-cabaj)

** Changed in: linux-gcp (Ubuntu Mantic)
 Assignee: (unassigned) => John Cabaj (john-cabaj)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-gcp in Ubuntu.
https://bugs.launchpad.net/bugs/2040522

Title:
  gVNIC DQO-QPL feature

Status in linux-gcp package in Ubuntu:
  New
Status in linux-gcp source package in Focal:
  Won't Fix
Status in linux-gcp source package in Jammy:
  In Progress
Status in linux-gcp source package in Lunar:
  Won't Fix
Status in linux-gcp source package in Mantic:
  In Progress

Bug description:
  [Impact]

  * Google requested inclusion of gVNIC DQO-QPL feature.

  [Fix]

  * Mantic: all clean cherry-picks from upstream
  * Jammy: 22 clean cherry-picks, 8 backports from upstream

  [Test Case]

  * Compile tested
  * Boot tested
  * Tested by Google

  [Where things could go wrong]

  * Low chance of regression. Almost all changes isolated to Google Ethernet 
drivers.
  * All changes upstream as of v6.6.

  [Other Info]

  * SF #00366697

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-gcp/+bug/2040522/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 2042853] Re: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough

2024-01-12 Thread bugproxy

** Tags added: verification-done

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2042853

Title:
  [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Lunar:
  Fix Committed
Status in linux source package in Mantic:
  Fix Committed
Status in linux source package in Noble:
  Fix Committed

Bug description:
  SRU Justification:

  [Impact]

   * Today no s390x-specific vfio-pci devices (zPCI) can be passed
 from a KVM host to a KVM guest (incl. secure execution guests
 in the context of confidential computing).

   * s390x PCI passthrough needs various changes in the s390x kernel zPCI
 code (incl. the new s390x-specific Kernel config option
 'CONFIG_VFIO_PCI_ZDEV_KVM') that were introduced with kernel 6.0
 and got backported to 22.04/jammy as part of LP: #1853306.

   * Lunar an newer Ubuntu releases have the code already included from
 upstream (incl. the Kernel option 'CONFIG_VFIO_PCI_ZDEV_KVM'), but the
 config option is not set, hence zPCI pass-through is still not possible.

  [Fix]

   * To be able to make use of VFIO zPCI pass-through on s390x running newer
 Ubuntu releases (especially needed in the context of secure execution)
 the (s390x-specific) Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM' needs
 to be enabled and set to 'y'.

  [Test Case]

   * Hardware used: z14 or greater LPAR, PCI-attached devices
 (RoCE VFs, ISM devices, NVMe drive)

   * Setup: Both the kernel and QEMU features are needed for the feature
 to function (an upstream QEMU can be used to verify the kernel early),
 and the facility is only available on z14 or newer.
 When any of those pieces is missing,
 the interpretation facility will not be used.
 When both the kernel and QEMU features are included in their respective
 packages, and running in an LPAR on a z14 or newer machine,
 this feature will be enabled automatically.
 Existing supported devices should behave as before with no changes
 required by an end-user (e.g. no changes to libvirt domain definitions)
 -- but will now make use of the interpretation facility.
 Additionally, ISM devices will now be eligible for vfio-pci passthrough
 (where before QEMU would exit on error if attempting to provide an ISM
 device for vfio-pci passthrough, preventing the guest from starting)

   * Testing will include the following scenarios, repeated each for RoCE,
 ISM and NVMe:

 1) Testing of basic device passthrough (create a VM with a vfio-pci
device as part of the libvirt domain definition, passing through
a RoCE VF, an ISM device, or an NVMe drive. Verify that the device
is available in the guest and functioning)
 2) Testing of device hotplug/unplug (create a VM with a vfio-pci device,
virsh detach-device to remove the device from the running guest,
verify the device is removed from the guest, then virsh attach-device
to hotplug the device to the guest again, verify the device functions
in the guest)
 3) Host power off testing: Power off the device from the host, verify
that the device is unplugged from the guest as part of the poweroff
 4) Guest power off testing: Power off the device from within the guest,
verify that the device is unusable in the guest,
power the device back on within the guest and verify that the device
is once again usable.
 5) Guest reboot testing: (create a VM with a vfio-pci device,
verify the device is in working condition, reboot the guest,
verify that the device is still usable after reboot)

  [Regression Potential]

   * The regression potential is moderate, since the code is upstream
 for quite a while and already enabled in jammy.

   * The general way on using passthrough has not changed, with this
 change (config option) it's now just possible to passthrough
 zPCI on top.

   * CCW devices are not affected.

   * And this is s390x-specific anyway, so no other architectures are
  affected.

  [Other]

   * The enabling of the kernel config option is exactly the same for L, M
 and U/N, but I submitted separate patches due to slightly different context
 and offsets.
  __

  === Description by mjros...@us.ibm.com  ===

  LP#1853306 / IBM bug 182254 backported the necessary kernel pieces to
  enable enhanced interpretation of PCI passthrough on s390.  It also
  included a kernel config update for CONFIG_VFIO_PCI_ZDEV_KVM=y which
  is necessary to activate this kernel feature.

  For lunar and mantic, the kernel code did not require backporting due
  to the base kernel version already containing it, but the kernel
  config option still needs to

[Kernel-packages] [Bug 2042853] Re: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough

2024-01-12 Thread bugproxy

** Tags removed: targetmilestone-inin--- verification-done-lunar-linux 
verification-done-mantic-linux
** Tags added: targetmilestone-inin2304

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2042853

Title:
  [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Lunar:
  Fix Committed
Status in linux source package in Mantic:
  Fix Committed
Status in linux source package in Noble:
  Fix Committed

Bug description:
  SRU Justification:

  [Impact]

   * Today no s390x-specific vfio-pci devices (zPCI) can be passed
 from a KVM host to a KVM guest (incl. secure execution guests
 in the context of confidential computing).

   * s390x PCI passthrough needs various changes in the s390x kernel zPCI
 code (incl. the new s390x-specific Kernel config option
 'CONFIG_VFIO_PCI_ZDEV_KVM') that were introduced with kernel 6.0
 and got backported to 22.04/jammy as part of LP: #1853306.

   * Lunar an newer Ubuntu releases have the code already included from
 upstream (incl. the Kernel option 'CONFIG_VFIO_PCI_ZDEV_KVM'), but the
 config option is not set, hence zPCI pass-through is still not possible.

  [Fix]

   * To be able to make use of VFIO zPCI pass-through on s390x running newer
 Ubuntu releases (especially needed in the context of secure execution)
 the (s390x-specific) Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM' needs
 to be enabled and set to 'y'.

  [Test Case]

   * Hardware used: z14 or greater LPAR, PCI-attached devices
 (RoCE VFs, ISM devices, NVMe drive)

   * Setup: Both the kernel and QEMU features are needed for the feature
 to function (an upstream QEMU can be used to verify the kernel early),
 and the facility is only available on z14 or newer.
 When any of those pieces is missing,
 the interpretation facility will not be used.
 When both the kernel and QEMU features are included in their respective
 packages, and running in an LPAR on a z14 or newer machine,
 this feature will be enabled automatically.
 Existing supported devices should behave as before with no changes
 required by an end-user (e.g. no changes to libvirt domain definitions)
 -- but will now make use of the interpretation facility.
 Additionally, ISM devices will now be eligible for vfio-pci passthrough
 (where before QEMU would exit on error if attempting to provide an ISM
 device for vfio-pci passthrough, preventing the guest from starting)

   * Testing will include the following scenarios, repeated each for RoCE,
 ISM and NVMe:

 1) Testing of basic device passthrough (create a VM with a vfio-pci
device as part of the libvirt domain definition, passing through
a RoCE VF, an ISM device, or an NVMe drive. Verify that the device
is available in the guest and functioning)
 2) Testing of device hotplug/unplug (create a VM with a vfio-pci device,
virsh detach-device to remove the device from the running guest,
verify the device is removed from the guest, then virsh attach-device
to hotplug the device to the guest again, verify the device functions
in the guest)
 3) Host power off testing: Power off the device from the host, verify
that the device is unplugged from the guest as part of the poweroff
 4) Guest power off testing: Power off the device from within the guest,
verify that the device is unusable in the guest,
power the device back on within the guest and verify that the device
is once again usable.
 5) Guest reboot testing: (create a VM with a vfio-pci device,
verify the device is in working condition, reboot the guest,
verify that the device is still usable after reboot)

  [Regression Potential]

   * The regression potential is moderate, since the code is upstream
 for quite a while and already enabled in jammy.

   * The general way on using passthrough has not changed, with this
 change (config option) it's now just possible to passthrough
 zPCI on top.

   * CCW devices are not affected.

   * And this is s390x-specific anyway, so no other architectures are
  affected.

  [Other]

   * The enabling of the kernel config option is exactly the same for L, M
 and U/N, but I submitted separate patches due to slightly different context
 and offsets.
  __

  === Description by mjros...@us.ibm.com  ===

  LP#1853306 / IBM bug 182254 backported the necessary kernel pieces to
  enable enhanced interpretation of PCI passthrough on s390.  It also
  included a kernel config update for CONFIG_VFIO_PCI_ZDEV_KVM=y which
  is necessary to activate this kernel feature.

  For lunar and mantic, the kernel code did not require

[Kernel-packages] [Bug 2042853] Re: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough

2024-01-12 Thread Frank Heimes

Thanks for the verification @mjrosato !

** Tags added: verification-done-lunar-linux verification-done-mantic-
linux

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2042853

Title:
  [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Lunar:
  Fix Committed
Status in linux source package in Mantic:
  Fix Committed
Status in linux source package in Noble:
  Fix Committed

Bug description:
  SRU Justification:

  [Impact]

   * Today no s390x-specific vfio-pci devices (zPCI) can be passed
 from a KVM host to a KVM guest (incl. secure execution guests
 in the context of confidential computing).

   * s390x PCI passthrough needs various changes in the s390x kernel zPCI
 code (incl. the new s390x-specific Kernel config option
 'CONFIG_VFIO_PCI_ZDEV_KVM') that were introduced with kernel 6.0
 and got backported to 22.04/jammy as part of LP: #1853306.

   * Lunar an newer Ubuntu releases have the code already included from
 upstream (incl. the Kernel option 'CONFIG_VFIO_PCI_ZDEV_KVM'), but the
 config option is not set, hence zPCI pass-through is still not possible.

  [Fix]

   * To be able to make use of VFIO zPCI pass-through on s390x running newer
 Ubuntu releases (especially needed in the context of secure execution)
 the (s390x-specific) Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM' needs
 to be enabled and set to 'y'.

  [Test Case]

   * Hardware used: z14 or greater LPAR, PCI-attached devices
 (RoCE VFs, ISM devices, NVMe drive)

   * Setup: Both the kernel and QEMU features are needed for the feature
 to function (an upstream QEMU can be used to verify the kernel early),
 and the facility is only available on z14 or newer.
 When any of those pieces is missing,
 the interpretation facility will not be used.
 When both the kernel and QEMU features are included in their respective
 packages, and running in an LPAR on a z14 or newer machine,
 this feature will be enabled automatically.
 Existing supported devices should behave as before with no changes
 required by an end-user (e.g. no changes to libvirt domain definitions)
 -- but will now make use of the interpretation facility.
 Additionally, ISM devices will now be eligible for vfio-pci passthrough
 (where before QEMU would exit on error if attempting to provide an ISM
 device for vfio-pci passthrough, preventing the guest from starting)

   * Testing will include the following scenarios, repeated each for RoCE,
 ISM and NVMe:

 1) Testing of basic device passthrough (create a VM with a vfio-pci
device as part of the libvirt domain definition, passing through
a RoCE VF, an ISM device, or an NVMe drive. Verify that the device
is available in the guest and functioning)
 2) Testing of device hotplug/unplug (create a VM with a vfio-pci device,
virsh detach-device to remove the device from the running guest,
verify the device is removed from the guest, then virsh attach-device
to hotplug the device to the guest again, verify the device functions
in the guest)
 3) Host power off testing: Power off the device from the host, verify
that the device is unplugged from the guest as part of the poweroff
 4) Guest power off testing: Power off the device from within the guest,
verify that the device is unusable in the guest,
power the device back on within the guest and verify that the device
is once again usable.
 5) Guest reboot testing: (create a VM with a vfio-pci device,
verify the device is in working condition, reboot the guest,
verify that the device is still usable after reboot)

  [Regression Potential]

   * The regression potential is moderate, since the code is upstream
 for quite a while and already enabled in jammy.

   * The general way on using passthrough has not changed, with this
 change (config option) it's now just possible to passthrough
 zPCI on top.

   * CCW devices are not affected.

   * And this is s390x-specific anyway, so no other architectures are
  affected.

  [Other]

   * The enabling of the kernel config option is exactly the same for L, M
 and U/N, but I submitted separate patches due to slightly different context
 and offsets.
  __

  === Description by mjros...@us.ibm.com  ===

  LP#1853306 / IBM bug 182254 backported the necessary kernel pieces to
  enable enhanced interpretation of PCI passthrough on s390.  It also
  included a kernel config update for CONFIG_VFIO_PCI_ZDEV_KVM=y which
  is necessary to activate this kernel feature.

  For lunar and mantic, the kernel code did not require backporting due
  to the base

[Kernel-packages] [Bug 2042853] Re: [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough

2024-01-12 Thread bugproxy

--- Comment From mjros...@us.ibm.com 2024-01-12 13:06 EDT---
Verified with the kernels in -proposed for both mantic and lunar that zPCI 
interpretation is now enabled and usable.  Thanks!

** Tags removed: verification-needed-lunar-linux verification-needed-
mantic-linux

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2042853

Title:
  [UBUNTU 23.04] Kernel config option missing for s390x PCI passthrough

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Lunar:
  Fix Committed
Status in linux source package in Mantic:
  Fix Committed
Status in linux source package in Noble:
  Fix Committed

Bug description:
  SRU Justification:

  [Impact]

   * Today no s390x-specific vfio-pci devices (zPCI) can be passed
 from a KVM host to a KVM guest (incl. secure execution guests
 in the context of confidential computing).

   * s390x PCI passthrough needs various changes in the s390x kernel zPCI
 code (incl. the new s390x-specific Kernel config option
 'CONFIG_VFIO_PCI_ZDEV_KVM') that were introduced with kernel 6.0
 and got backported to 22.04/jammy as part of LP: #1853306.

   * Lunar an newer Ubuntu releases have the code already included from
 upstream (incl. the Kernel option 'CONFIG_VFIO_PCI_ZDEV_KVM'), but the
 config option is not set, hence zPCI pass-through is still not possible.

  [Fix]

   * To be able to make use of VFIO zPCI pass-through on s390x running newer
 Ubuntu releases (especially needed in the context of secure execution)
 the (s390x-specific) Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM' needs
 to be enabled and set to 'y'.

  [Test Case]

   * Hardware used: z14 or greater LPAR, PCI-attached devices
 (RoCE VFs, ISM devices, NVMe drive)

   * Setup: Both the kernel and QEMU features are needed for the feature
 to function (an upstream QEMU can be used to verify the kernel early),
 and the facility is only available on z14 or newer.
 When any of those pieces is missing,
 the interpretation facility will not be used.
 When both the kernel and QEMU features are included in their respective
 packages, and running in an LPAR on a z14 or newer machine,
 this feature will be enabled automatically.
 Existing supported devices should behave as before with no changes
 required by an end-user (e.g. no changes to libvirt domain definitions)
 -- but will now make use of the interpretation facility.
 Additionally, ISM devices will now be eligible for vfio-pci passthrough
 (where before QEMU would exit on error if attempting to provide an ISM
 device for vfio-pci passthrough, preventing the guest from starting)

   * Testing will include the following scenarios, repeated each for RoCE,
 ISM and NVMe:

 1) Testing of basic device passthrough (create a VM with a vfio-pci
device as part of the libvirt domain definition, passing through
a RoCE VF, an ISM device, or an NVMe drive. Verify that the device
is available in the guest and functioning)
 2) Testing of device hotplug/unplug (create a VM with a vfio-pci device,
virsh detach-device to remove the device from the running guest,
verify the device is removed from the guest, then virsh attach-device
to hotplug the device to the guest again, verify the device functions
in the guest)
 3) Host power off testing: Power off the device from the host, verify
that the device is unplugged from the guest as part of the poweroff
 4) Guest power off testing: Power off the device from within the guest,
verify that the device is unusable in the guest,
power the device back on within the guest and verify that the device
is once again usable.
 5) Guest reboot testing: (create a VM with a vfio-pci device,
verify the device is in working condition, reboot the guest,
verify that the device is still usable after reboot)

  [Regression Potential]

   * The regression potential is moderate, since the code is upstream
 for quite a while and already enabled in jammy.

   * The general way on using passthrough has not changed, with this
 change (config option) it's now just possible to passthrough
 zPCI on top.

   * CCW devices are not affected.

   * And this is s390x-specific anyway, so no other architectures are
  affected.

  [Other]

   * The enabling of the kernel config option is exactly the same for L, M
 and U/N, but I submitted separate patches due to slightly different context
 and offsets.
  __

  === Description by mjros...@us.ibm.com  ===

  LP#1853306 / IBM bug 182254 backported the necessary kernel pieces to
  enable enhanced interpretation of PCI passthrough on s390.  It also
  included a kernel config update for

90 matches

Mail list logo