The email addresses for the reviewers of the MptScsi and
PvScsi are no longer valid. Disable the MptScsi and PvScsi
drivers in all DSC files until new maintainers/reviewers can
be identified.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Sebastien Boeuf <sebastien.boeuf@intel.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
---
OvmfPkg/AmdSev/AmdSevX64.dsc | 4 ++--
OvmfPkg/CloudHv/CloudHvX64.dsc | 4 ++--
OvmfPkg/IntelTdx/IntelTdxX64.dsc | 4 ++--
OvmfPkg/Microvm/MicrovmX64.dsc | 4 ++--
OvmfPkg/OvmfPkgIa32.dsc | 4 ++--
OvmfPkg/OvmfPkgIa32X64.dsc | 4 ++--
OvmfPkg/OvmfPkgX64.dsc | 4 ++--
7 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index 726521c94381..90e8a213ef77 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -43,8 +43,8 @@ [Defines]
#
# Device drivers
#
- DEFINE PVSCSI_ENABLE = TRUE
- DEFINE MPT_SCSI_ENABLE = TRUE
+ DEFINE PVSCSI_ENABLE = FALSE
+ DEFINE MPT_SCSI_ENABLE = FALSE
DEFINE LSI_SCSI_ENABLE = FALSE
#
diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.dsc
index 0bfe542f8a88..f0d700f14477 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.dsc
+++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
@@ -49,8 +49,8 @@ [Defines]
#
# Device drivers
#
- DEFINE PVSCSI_ENABLE = TRUE
- DEFINE MPT_SCSI_ENABLE = TRUE
+ DEFINE PVSCSI_ENABLE = FALSE
+ DEFINE MPT_SCSI_ENABLE = FALSE
DEFINE LSI_SCSI_ENABLE = FALSE
#
diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
index 144d50aa9dba..71b1cf8e7090 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
@@ -34,8 +34,8 @@ [Defines]
#
# Device drivers
#
- DEFINE PVSCSI_ENABLE = TRUE
- DEFINE MPT_SCSI_ENABLE = TRUE
+ DEFINE PVSCSI_ENABLE = FALSE
+ DEFINE MPT_SCSI_ENABLE = FALSE
DEFINE LSI_SCSI_ENABLE = FALSE
#
diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc
index 61db9b6e4c83..52498bbe90a8 100644
--- a/OvmfPkg/Microvm/MicrovmX64.dsc
+++ b/OvmfPkg/Microvm/MicrovmX64.dsc
@@ -47,8 +47,8 @@ [Defines]
#
# Device drivers
#
- DEFINE PVSCSI_ENABLE = TRUE
- DEFINE MPT_SCSI_ENABLE = TRUE
+ DEFINE PVSCSI_ENABLE = FALSE
+ DEFINE MPT_SCSI_ENABLE = FALSE
DEFINE LSI_SCSI_ENABLE = FALSE
#
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index e708411076ca..725a01ae9a20 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -50,8 +50,8 @@ [Defines]
#
# Device drivers
#
- DEFINE PVSCSI_ENABLE = TRUE
- DEFINE MPT_SCSI_ENABLE = TRUE
+ DEFINE PVSCSI_ENABLE = FALSE
+ DEFINE MPT_SCSI_ENABLE = FALSE
DEFINE LSI_SCSI_ENABLE = FALSE
#
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 0b036d8bb53f..adc813ba2e1e 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -49,8 +49,8 @@ [Defines]
#
# Device drivers
#
- DEFINE PVSCSI_ENABLE = TRUE
- DEFINE MPT_SCSI_ENABLE = TRUE
+ DEFINE PVSCSI_ENABLE = FALSE
+ DEFINE MPT_SCSI_ENABLE = FALSE
DEFINE LSI_SCSI_ENABLE = FALSE
#
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 8ad04b50f74f..6e68f60dc90f 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -49,8 +49,8 @@ [Defines]
#
# Device drivers
#
- DEFINE PVSCSI_ENABLE = TRUE
- DEFINE MPT_SCSI_ENABLE = TRUE
+ DEFINE PVSCSI_ENABLE = FALSE
+ DEFINE MPT_SCSI_ENABLE = FALSE
DEFINE LSI_SCSI_ENABLE = FALSE
#
--
2.32.0.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#91861): https://edk2.groups.io/g/devel/message/91861
Mute This Topic: https://groups.io/mt/92635541/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-On Tue, Jul 26, 2022 at 12:46:39PM -0700, Michael D Kinney wrote: > The email addresses for the reviewers of the MptScsi and > PvScsi are no longer valid. Disable the MptScsi and PvScsi > drivers in all DSC files until new maintainers/reviewers can > be identified. Hi Michael, This seems likely to be the reason for the following regression report in Debian: https://bugs.debian.org/1016359 I'm trying to decide whether or not this is something we should force back on for our users to avoid the regression, and/or if we need to actively move users off of it (mark it deprecated, etc). Do you know if there are known issues with this code, other than the lack of reviewers? Is there a plan to remove this code at some point? -dann > Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> > Cc: Jiewen Yao <jiewen.yao@intel.com> > Cc: Jordan Justen <jordan.l.justen@intel.com> > Cc: Gerd Hoffmann <kraxel@redhat.com> > Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> > Cc: Brijesh Singh <brijesh.singh@amd.com> > Cc: Erdem Aktas <erdemaktas@google.com> > Cc: James Bottomley <jejb@linux.ibm.com> > Cc: Jiewen Yao <jiewen.yao@intel.com> > Cc: Min Xu <min.m.xu@intel.com> > Cc: Tom Lendacky <thomas.lendacky@amd.com> > Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> > --- > OvmfPkg/AmdSev/AmdSevX64.dsc | 4 ++-- > OvmfPkg/CloudHv/CloudHvX64.dsc | 4 ++-- > OvmfPkg/IntelTdx/IntelTdxX64.dsc | 4 ++-- > OvmfPkg/Microvm/MicrovmX64.dsc | 4 ++-- > OvmfPkg/OvmfPkgIa32.dsc | 4 ++-- > OvmfPkg/OvmfPkgIa32X64.dsc | 4 ++-- > OvmfPkg/OvmfPkgX64.dsc | 4 ++-- > 7 files changed, 14 insertions(+), 14 deletions(-) > > diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc > index 726521c94381..90e8a213ef77 100644 > --- a/OvmfPkg/AmdSev/AmdSevX64.dsc > +++ b/OvmfPkg/AmdSev/AmdSevX64.dsc > @@ -43,8 +43,8 @@ [Defines] > # > # Device drivers > # > - DEFINE PVSCSI_ENABLE = TRUE > - DEFINE MPT_SCSI_ENABLE = TRUE > + DEFINE PVSCSI_ENABLE = FALSE > + DEFINE MPT_SCSI_ENABLE = FALSE > DEFINE LSI_SCSI_ENABLE = FALSE > > # > diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.dsc > index 0bfe542f8a88..f0d700f14477 100644 > --- a/OvmfPkg/CloudHv/CloudHvX64.dsc > +++ b/OvmfPkg/CloudHv/CloudHvX64.dsc > @@ -49,8 +49,8 @@ [Defines] > # > # Device drivers > # > - DEFINE PVSCSI_ENABLE = TRUE > - DEFINE MPT_SCSI_ENABLE = TRUE > + DEFINE PVSCSI_ENABLE = FALSE > + DEFINE MPT_SCSI_ENABLE = FALSE > DEFINE LSI_SCSI_ENABLE = FALSE > > # > diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc > index 144d50aa9dba..71b1cf8e7090 100644 > --- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc > +++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc > @@ -34,8 +34,8 @@ [Defines] > # > # Device drivers > # > - DEFINE PVSCSI_ENABLE = TRUE > - DEFINE MPT_SCSI_ENABLE = TRUE > + DEFINE PVSCSI_ENABLE = FALSE > + DEFINE MPT_SCSI_ENABLE = FALSE > DEFINE LSI_SCSI_ENABLE = FALSE > > # > diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc > index 61db9b6e4c83..52498bbe90a8 100644 > --- a/OvmfPkg/Microvm/MicrovmX64.dsc > +++ b/OvmfPkg/Microvm/MicrovmX64.dsc > @@ -47,8 +47,8 @@ [Defines] > # > # Device drivers > # > - DEFINE PVSCSI_ENABLE = TRUE > - DEFINE MPT_SCSI_ENABLE = TRUE > + DEFINE PVSCSI_ENABLE = FALSE > + DEFINE MPT_SCSI_ENABLE = FALSE > DEFINE LSI_SCSI_ENABLE = FALSE > > # > diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc > index e708411076ca..725a01ae9a20 100644 > --- a/OvmfPkg/OvmfPkgIa32.dsc > +++ b/OvmfPkg/OvmfPkgIa32.dsc > @@ -50,8 +50,8 @@ [Defines] > # > # Device drivers > # > - DEFINE PVSCSI_ENABLE = TRUE > - DEFINE MPT_SCSI_ENABLE = TRUE > + DEFINE PVSCSI_ENABLE = FALSE > + DEFINE MPT_SCSI_ENABLE = FALSE > DEFINE LSI_SCSI_ENABLE = FALSE > > # > diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc > index 0b036d8bb53f..adc813ba2e1e 100644 > --- a/OvmfPkg/OvmfPkgIa32X64.dsc > +++ b/OvmfPkg/OvmfPkgIa32X64.dsc > @@ -49,8 +49,8 @@ [Defines] > # > # Device drivers > # > - DEFINE PVSCSI_ENABLE = TRUE > - DEFINE MPT_SCSI_ENABLE = TRUE > + DEFINE PVSCSI_ENABLE = FALSE > + DEFINE MPT_SCSI_ENABLE = FALSE > DEFINE LSI_SCSI_ENABLE = FALSE > > # > diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc > index 8ad04b50f74f..6e68f60dc90f 100644 > --- a/OvmfPkg/OvmfPkgX64.dsc > +++ b/OvmfPkg/OvmfPkgX64.dsc > @@ -49,8 +49,8 @@ [Defines] > # > # Device drivers > # > - DEFINE PVSCSI_ENABLE = TRUE > - DEFINE MPT_SCSI_ENABLE = TRUE > + DEFINE PVSCSI_ENABLE = FALSE > + DEFINE MPT_SCSI_ENABLE = FALSE > DEFINE LSI_SCSI_ENABLE = FALSE > > # -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#96985): https://edk2.groups.io/g/devel/message/96985 Mute This Topic: https://groups.io/mt/92635541/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Mon, Dec 05, 2022 at 04:36:15PM -0700, dann frazier wrote: > On Tue, Jul 26, 2022 at 12:46:39PM -0700, Michael D Kinney wrote: > > The email addresses for the reviewers of the MptScsi and > > PvScsi are no longer valid. Disable the MptScsi and PvScsi > > drivers in all DSC files until new maintainers/reviewers can > > be identified. > > Hi Michael, > > This seems likely to be the reason for the following regression > report in Debian: > > https://bugs.debian.org/1016359 I'm not so sure about that. > > - DEFINE PVSCSI_ENABLE = TRUE > > - DEFINE MPT_SCSI_ENABLE = TRUE > > + DEFINE PVSCSI_ENABLE = FALSE > > + DEFINE MPT_SCSI_ENABLE = FALSE > > DEFINE LSI_SCSI_ENABLE = FALSE The bug report talks about lsilogic and virtio-scsi. lsilogic was already disabled by default before this patch. virtio-scsi support is included and there are no plans to change that because it is a rather essential driver. It works just fine upstream, and there isn't even a config switch to disable it. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#97011): https://edk2.groups.io/g/devel/message/97011 Mute This Topic: https://groups.io/mt/92635541/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Tue, Dec 06, 2022 at 06:56:49AM +0100, Gerd Hoffmann wrote: > On Mon, Dec 05, 2022 at 04:36:15PM -0700, dann frazier wrote: > > On Tue, Jul 26, 2022 at 12:46:39PM -0700, Michael D Kinney wrote: > > > The email addresses for the reviewers of the MptScsi and > > > PvScsi are no longer valid. Disable the MptScsi and PvScsi > > > drivers in all DSC files until new maintainers/reviewers can > > > be identified. > > > > Hi Michael, > > > > This seems likely to be the reason for the following regression > > report in Debian: > > > > https://bugs.debian.org/1016359 > > I'm not so sure about that. > > > > - DEFINE PVSCSI_ENABLE = TRUE > > > - DEFINE MPT_SCSI_ENABLE = TRUE > > > + DEFINE PVSCSI_ENABLE = FALSE > > > + DEFINE MPT_SCSI_ENABLE = FALSE > > > DEFINE LSI_SCSI_ENABLE = FALSE > > The bug report talks about lsilogic and virtio-scsi. > > lsilogic was already disabled by default before this patch. > > virtio-scsi support is included and there are no plans to change > that because it is a rather essential driver. It works just fine > upstream, and there isn't even a config switch to disable it. Thanks Gerd - I'll work with the users to clarify via the bug (thanks for responding there as well btw). -dann -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#97038): https://edk2.groups.io/g/devel/message/97038 Mute This Topic: https://groups.io/mt/92635541/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Greetings All! As I can see LSI_SCSI_ENABLE related to LSI LSI_53C895A_PCI_DEVICE_ID Vid/Did 0x1000:0x0012. I guess it is some old Megaraid adapter. A patch mentioned above set MPT_SCSI_ENABLE=FALSE, that removed support for LSI 53C1030 and SAS1068. These SCSI controllers were emulated by VMware, Parallels and I guess VitualBox. This is generic setup for VMware VMs, as far as I remember. So the booting of such VMs (probably migrated from VMware and others) was definitely broken. Regards, Mike. On Tue, Dec 6, 2022 at 5:38 PM dann frazier <dann.frazier@canonical.com> wrote: > > On Tue, Dec 06, 2022 at 06:56:49AM +0100, Gerd Hoffmann wrote: > > On Mon, Dec 05, 2022 at 04:36:15PM -0700, dann frazier wrote: > > > On Tue, Jul 26, 2022 at 12:46:39PM -0700, Michael D Kinney wrote: > > > > The email addresses for the reviewers of the MptScsi and > > > > PvScsi are no longer valid. Disable the MptScsi and PvScsi > > > > drivers in all DSC files until new maintainers/reviewers can > > > > be identified. > > > > > > Hi Michael, > > > > > > This seems likely to be the reason for the following regression > > > report in Debian: > > > > > > https://bugs.debian.org/1016359 > > > > I'm not so sure about that. > > > > > > - DEFINE PVSCSI_ENABLE = TRUE > > > > - DEFINE MPT_SCSI_ENABLE = TRUE > > > > + DEFINE PVSCSI_ENABLE = FALSE > > > > + DEFINE MPT_SCSI_ENABLE = FALSE > > > > DEFINE LSI_SCSI_ENABLE = FALSE > > > > The bug report talks about lsilogic and virtio-scsi. > > > > lsilogic was already disabled by default before this patch. > > > > virtio-scsi support is included and there are no plans to change > > that because it is a rather essential driver. It works just fine > > upstream, and there isn't even a config switch to disable it. > > Thanks Gerd - I'll work with the users to clarify via the bug (thanks > for responding there as well btw). > > -dann > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#97039): https://edk2.groups.io/g/devel/message/97039 Mute This Topic: https://groups.io/mt/92635541/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Hi, > A patch mentioned above set MPT_SCSI_ENABLE=FALSE, that removed > support for LSI 53C1030 and SAS1068. > These SCSI controllers were emulated by VMware, Parallels and I guess > VitualBox. > This is generic setup for VMware VMs, as far as I remember. > So the booting of such VMs (probably migrated from VMware and others) > was definitely broken. Yes. Problem is there is no maintainer for the driver. There used to be one, but the email address started bouncing. So we updated Maintainers.txt and flipped the switch to not build the unmaintained drivers by default. If debian is fine with shipping unmaintained software to its users you can flip the config switches of course, at least as long as the drivers are still in the tree. The drivers are at risk of being removed though in case we don't find a new maintainer within a year or two. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#97067): https://edk2.groups.io/g/devel/message/97067 Mute This Topic: https://groups.io/mt/92635541/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Wed, 7 Dec 2022 at 08:41, Gerd Hoffmann <kraxel@redhat.com> wrote: > > Hi, > > > A patch mentioned above set MPT_SCSI_ENABLE=FALSE, that removed > > support for LSI 53C1030 and SAS1068. > > These SCSI controllers were emulated by VMware, Parallels and I guess > > VitualBox. > > This is generic setup for VMware VMs, as far as I remember. > > So the booting of such VMs (probably migrated from VMware and others) > > was definitely broken. > > Yes. Problem is there is no maintainer for the driver. There used to > be one, but the email address started bouncing. So we updated > Maintainers.txt and flipped the switch to not build the unmaintained > drivers by default. > > If debian is fine with shipping unmaintained software to its users you > can flip the config switches of course, at least as long as the drivers > are still in the tree. The drivers are at risk of being removed though > in case we don't find a new maintainer within a year or two. > Indeed. These options can be set from the command line when building the image, so the distro wrapper scripts can just en/disable the features they desire. As for maintenance: indeed, lack of maintainership generally also means lack of testing coverage, and if something breaks, we won't notice, and if we do, we may not be able to fix it without running the risk of breaking something else. So at some point, these drivers will be removed rather than kept alive by the core team unless someone steps up. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#97079): https://edk2.groups.io/g/devel/message/97079 Mute This Topic: https://groups.io/mt/92635541/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Wed, 2022-12-07 at 15:09 +0100, Ard Biesheuvel wrote: > So at some point, these drivers will be removed rather than kept > alive by the core team unless someone steps up. How important is keeping them alive? I can volunteer to "maintain" them which I anticipate won't be much effort (plus I'm used to looking after obsolete SCSI equipment). The hardware is obsolete, so the mechanics of their emulation isn't going to change, the only potential risk is changes in the guest to host transmission layer that breaks something. On the other hand, I've got to say I use virtio-scsi in all my VM testing environments, so the maintenance will likely only be reacting when someone else reports a problem. James -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#97082): https://edk2.groups.io/g/devel/message/97082 Mute This Topic: https://groups.io/mt/92635541/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Wed, Dec 07, 2022 at 09:14:39AM -0500, James Bottomley wrote: > On Wed, 2022-12-07 at 15:09 +0100, Ard Biesheuvel wrote: > > So at some point, these drivers will be removed rather than kept > > alive by the core team unless someone steps up. > > How important is keeping them alive? Most common use case is probably bootimg images created on other hypervisors on qemu. Otherwise there is little reason to use something which is not virtio-scsi. > I can volunteer to "maintain" > them which I anticipate won't be much effort (plus I'm used to looking > after obsolete SCSI equipment). The hardware is obsolete, so the > mechanics of their emulation isn't going to change, the only potential > risk is changes in the guest to host transmission layer that breaks > something. Yes, I don't expect it being much effort, but knowing oldish scsi stuff certainly helps understanding the driver code if needed. If you want step up sent a patch updating Maintainers.txt accordingly. > On the other hand, I've got to say I use virtio-scsi in all > my VM testing environments, Same here ;) take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#97088): https://edk2.groups.io/g/devel/message/97088 Mute This Topic: https://groups.io/mt/92635541/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Wed, 7 Dec 2022 at 17:02, Gerd Hoffmann <kraxel@redhat.com> wrote: > > On Wed, Dec 07, 2022 at 09:14:39AM -0500, James Bottomley wrote: > > On Wed, 2022-12-07 at 15:09 +0100, Ard Biesheuvel wrote: > > > So at some point, these drivers will be removed rather than kept > > > alive by the core team unless someone steps up. > > > > How important is keeping them alive? > > Most common use case is probably bootimg images created on other > hypervisors on qemu. Otherwise there is little reason to use > something which is not virtio-scsi. > > > I can volunteer to "maintain" > > them which I anticipate won't be much effort (plus I'm used to looking > > after obsolete SCSI equipment). The hardware is obsolete, so the > > mechanics of their emulation isn't going to change, the only potential > > risk is changes in the guest to host transmission layer that breaks > > something. > Thanks James, that would be very helpful. > Yes, I don't expect it being much effort, but knowing oldish scsi stuff > certainly helps understanding the driver code if needed. If you want > step up sent a patch updating Maintainers.txt accordingly. > Having the informed opinion of a domain expert should allow us to diagnose issued related to these drivers with more confidence, and also give us insight in how obsolete those drivers actually are. I can send the patch if you prefer. > > On the other hand, I've got to say I use virtio-scsi in all > > my VM testing environments, > > Same here ;) > > take care, > Gerd > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#97089): https://edk2.groups.io/g/devel/message/97089 Mute This Topic: https://groups.io/mt/92635541/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Wed, 2022-12-07 at 17:04 +0100, Ard Biesheuvel wrote: > On Wed, 7 Dec 2022 at 17:02, Gerd Hoffmann <kraxel@redhat.com> wrote: > > > > On Wed, Dec 07, 2022 at 09:14:39AM -0500, James Bottomley wrote: > > > On Wed, 2022-12-07 at 15:09 +0100, Ard Biesheuvel wrote: > > > > So at some point, these drivers will be removed rather than > > > > kept > > > > alive by the core team unless someone steps up. > > > > > > How important is keeping them alive? > > > > Most common use case is probably bootimg images created on other > > hypervisors on qemu. Otherwise there is little reason to use > > something which is not virtio-scsi. > > > > > I can volunteer to "maintain" them which I anticipate won't be > > > much effort (plus I'm used to looking after obsolete SCSI > > > equipment). The hardware is obsolete, so the mechanics of their > > > emulation isn't going to change, the only potential risk is > > > changes in the guest to host transmission layer that breaks > > > something. > > > > Thanks James, that would be very helpful. > > > Yes, I don't expect it being much effort, but knowing oldish scsi > > stuff certainly helps understanding the driver code if needed. If > > you want step up sent a patch updating Maintainers.txt accordingly. > > > > Having the informed opinion of a domain expert should allow us to > diagnose issued related to these drivers with more confidence, and > also give us insight in how obsolete those drivers actually are. > > I can send the patch if you prefer. Sure, who can resist someone else doing all the work. I note we do have a maintained LSI driver: OvmfPkg/LsiScsiDxe. It seems to be based on the 53c896 which is really only a marginal subset of the 1030 ... if I'm remembering correctly the 1030 did Low Voltage Differential (so a faster SCSI Parallel bus), but since that's a SCSI Bus protocol, it should have no real impact on the utility of the emulation. Is the LsiScsiDxe usable by Debian? James -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#97092): https://edk2.groups.io/g/devel/message/97092 Mute This Topic: https://groups.io/mt/92635541/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Wed, Dec 07, 2022 at 11:22:10AM -0500, James Bottomley wrote:
> On Wed, 2022-12-07 at 17:04 +0100, Ard Biesheuvel wrote:
> > On Wed, 7 Dec 2022 at 17:02, Gerd Hoffmann <kraxel@redhat.com> wrote:
> > >
> > > On Wed, Dec 07, 2022 at 09:14:39AM -0500, James Bottomley wrote:
> > > > On Wed, 2022-12-07 at 15:09 +0100, Ard Biesheuvel wrote:
> > > > > So at some point, these drivers will be removed rather than
> > > > > kept
> > > > > alive by the core team unless someone steps up.
> > > >
> > > > How important is keeping them alive?
> > >
> > > Most common use case is probably bootimg images created on other
> > > hypervisors on qemu. Otherwise there is little reason to use
> > > something which is not virtio-scsi.
> > >
> > > > I can volunteer to "maintain" them which I anticipate won't be
> > > > much effort (plus I'm used to looking after obsolete SCSI
> > > > equipment). The hardware is obsolete, so the mechanics of their
> > > > emulation isn't going to change, the only potential risk is
> > > > changes in the guest to host transmission layer that breaks
> > > > something.
> > >
> >
> > Thanks James, that would be very helpful.
> >
> > > Yes, I don't expect it being much effort, but knowing oldish scsi
> > > stuff certainly helps understanding the driver code if needed. If
> > > you want step up sent a patch updating Maintainers.txt accordingly.
> > >
> >
> > Having the informed opinion of a domain expert should allow us to
> > diagnose issued related to these drivers with more confidence, and
> > also give us insight in how obsolete those drivers actually are.
> >
> > I can send the patch if you prefer.
>
> Sure, who can resist someone else doing all the work.
>
> I note we do have a maintained LSI driver: OvmfPkg/LsiScsiDxe. It
> seems to be based on the 53c896 which is really only a marginal subset
> of the 1030 ... if I'm remembering correctly the 1030 did Low Voltage
> Differential (so a faster SCSI Parallel bus), but since that's a SCSI
> Bus protocol, it should have no real impact on the utility of the
> emulation. Is the LsiScsiDxe usable by Debian?
I tried it, but it doesn't seem to enumerate any blk devices.
The driver loads and reports that it is managing a device:
Shell> drivers
T D
D Y C I
R P F A
V VERSION E G G #D #C DRIVER NAME IMAGE NAME
== ======== = = = == == =================================== ==========
[...]
6E 00000010 D - - 1 - LSI 53C895A SCSI Controller Driver LsiScsiDxe
[...]
But no blk devices. Using the same VM config and just swapping the
controller from lsilogic to virtio-scsi, yields the expected blk
devices.
To be clear, I'm unaware of OVMF ever working with this device in
Debian.
-dann
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#97103): https://edk2.groups.io/g/devel/message/97103
Mute This Topic: https://groups.io/mt/92635541/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
Hi Dann, The purpose of this first step was due to lack of support/maintainers/reviewers. If there are issues, then we need to find maintainers/reviewers starting with those that are using and depend on these features. If there are no issues from disabling these by default, then the 2nd step would be deleting the code and the flags. Are these features actually being used? Thanks, Mike > -----Original Message----- > From: dann frazier <dann.frazier@canonical.com> > Sent: Monday, December 5, 2022 3:36 PM > To: devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com> > Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Yao, Jiewen <jiewen.yao@intel.com>; Justen, Jordan L > <jordan.l.justen@intel.com>; Gerd Hoffmann <kraxel@redhat.com>; Boeuf, Sebastien <sebastien.boeuf@intel.com>; Brijesh Singh > <brijesh.singh@amd.com>; Aktas, Erdem <erdemaktas@google.com>; James Bottomley <jejb@linux.ibm.com>; Xu, Min M > <min.m.xu@intel.com>; Tom Lendacky <thomas.lendacky@amd.com> > Subject: Re: [edk2-devel] [Patch 1/2] OvmfPkg: Change default to disable MptScsi and PvScsi > > On Tue, Jul 26, 2022 at 12:46:39PM -0700, Michael D Kinney wrote: > > The email addresses for the reviewers of the MptScsi and > > PvScsi are no longer valid. Disable the MptScsi and PvScsi > > drivers in all DSC files until new maintainers/reviewers can > > be identified. > > Hi Michael, > > This seems likely to be the reason for the following regression > report in Debian: > > https://bugs.debian.org/1016359 > > I'm trying to decide whether or not this is something we should > force back on for our users to avoid the regression, and/or if we need > to actively move users off of it (mark it deprecated, etc). Do you know > if there are known issues with this code, other than the lack of > reviewers? Is there a plan to remove this code at some point? > > -dann > > > Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> > > Cc: Jiewen Yao <jiewen.yao@intel.com> > > Cc: Jordan Justen <jordan.l.justen@intel.com> > > Cc: Gerd Hoffmann <kraxel@redhat.com> > > Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> > > Cc: Brijesh Singh <brijesh.singh@amd.com> > > Cc: Erdem Aktas <erdemaktas@google.com> > > Cc: James Bottomley <jejb@linux.ibm.com> > > Cc: Jiewen Yao <jiewen.yao@intel.com> > > Cc: Min Xu <min.m.xu@intel.com> > > Cc: Tom Lendacky <thomas.lendacky@amd.com> > > Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> > > --- > > OvmfPkg/AmdSev/AmdSevX64.dsc | 4 ++-- > > OvmfPkg/CloudHv/CloudHvX64.dsc | 4 ++-- > > OvmfPkg/IntelTdx/IntelTdxX64.dsc | 4 ++-- > > OvmfPkg/Microvm/MicrovmX64.dsc | 4 ++-- > > OvmfPkg/OvmfPkgIa32.dsc | 4 ++-- > > OvmfPkg/OvmfPkgIa32X64.dsc | 4 ++-- > > OvmfPkg/OvmfPkgX64.dsc | 4 ++-- > > 7 files changed, 14 insertions(+), 14 deletions(-) > > > > diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc > > index 726521c94381..90e8a213ef77 100644 > > --- a/OvmfPkg/AmdSev/AmdSevX64.dsc > > +++ b/OvmfPkg/AmdSev/AmdSevX64.dsc > > @@ -43,8 +43,8 @@ [Defines] > > # > > # Device drivers > > # > > - DEFINE PVSCSI_ENABLE = TRUE > > - DEFINE MPT_SCSI_ENABLE = TRUE > > + DEFINE PVSCSI_ENABLE = FALSE > > + DEFINE MPT_SCSI_ENABLE = FALSE > > DEFINE LSI_SCSI_ENABLE = FALSE > > > > # > > diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.dsc > > index 0bfe542f8a88..f0d700f14477 100644 > > --- a/OvmfPkg/CloudHv/CloudHvX64.dsc > > +++ b/OvmfPkg/CloudHv/CloudHvX64.dsc > > @@ -49,8 +49,8 @@ [Defines] > > # > > # Device drivers > > # > > - DEFINE PVSCSI_ENABLE = TRUE > > - DEFINE MPT_SCSI_ENABLE = TRUE > > + DEFINE PVSCSI_ENABLE = FALSE > > + DEFINE MPT_SCSI_ENABLE = FALSE > > DEFINE LSI_SCSI_ENABLE = FALSE > > > > # > > diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc > > index 144d50aa9dba..71b1cf8e7090 100644 > > --- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc > > +++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc > > @@ -34,8 +34,8 @@ [Defines] > > # > > # Device drivers > > # > > - DEFINE PVSCSI_ENABLE = TRUE > > - DEFINE MPT_SCSI_ENABLE = TRUE > > + DEFINE PVSCSI_ENABLE = FALSE > > + DEFINE MPT_SCSI_ENABLE = FALSE > > DEFINE LSI_SCSI_ENABLE = FALSE > > > > # > > diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc > > index 61db9b6e4c83..52498bbe90a8 100644 > > --- a/OvmfPkg/Microvm/MicrovmX64.dsc > > +++ b/OvmfPkg/Microvm/MicrovmX64.dsc > > @@ -47,8 +47,8 @@ [Defines] > > # > > # Device drivers > > # > > - DEFINE PVSCSI_ENABLE = TRUE > > - DEFINE MPT_SCSI_ENABLE = TRUE > > + DEFINE PVSCSI_ENABLE = FALSE > > + DEFINE MPT_SCSI_ENABLE = FALSE > > DEFINE LSI_SCSI_ENABLE = FALSE > > > > # > > diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc > > index e708411076ca..725a01ae9a20 100644 > > --- a/OvmfPkg/OvmfPkgIa32.dsc > > +++ b/OvmfPkg/OvmfPkgIa32.dsc > > @@ -50,8 +50,8 @@ [Defines] > > # > > # Device drivers > > # > > - DEFINE PVSCSI_ENABLE = TRUE > > - DEFINE MPT_SCSI_ENABLE = TRUE > > + DEFINE PVSCSI_ENABLE = FALSE > > + DEFINE MPT_SCSI_ENABLE = FALSE > > DEFINE LSI_SCSI_ENABLE = FALSE > > > > # > > diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc > > index 0b036d8bb53f..adc813ba2e1e 100644 > > --- a/OvmfPkg/OvmfPkgIa32X64.dsc > > +++ b/OvmfPkg/OvmfPkgIa32X64.dsc > > @@ -49,8 +49,8 @@ [Defines] > > # > > # Device drivers > > # > > - DEFINE PVSCSI_ENABLE = TRUE > > - DEFINE MPT_SCSI_ENABLE = TRUE > > + DEFINE PVSCSI_ENABLE = FALSE > > + DEFINE MPT_SCSI_ENABLE = FALSE > > DEFINE LSI_SCSI_ENABLE = FALSE > > > > # > > diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc > > index 8ad04b50f74f..6e68f60dc90f 100644 > > --- a/OvmfPkg/OvmfPkgX64.dsc > > +++ b/OvmfPkg/OvmfPkgX64.dsc > > @@ -49,8 +49,8 @@ [Defines] > > # > > # Device drivers > > # > > - DEFINE PVSCSI_ENABLE = TRUE > > - DEFINE MPT_SCSI_ENABLE = TRUE > > + DEFINE PVSCSI_ENABLE = FALSE > > + DEFINE MPT_SCSI_ENABLE = FALSE > > DEFINE LSI_SCSI_ENABLE = FALSE > > > > # -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#97000): https://edk2.groups.io/g/devel/message/97000 Mute This Topic: https://groups.io/mt/92635541/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Mon, Dec 5, 2022 at 6:25 PM Kinney, Michael D <michael.d.kinney@intel.com> wrote: > > Hi Dann, > > The purpose of this first step was due to lack of support/maintainers/reviewers. > > If there are issues, then we need to find maintainers/reviewers starting with > those that are using and depend on these features. > > If there are no issues from disabling these by default, then the 2nd step > would be deleting the code and the flags. > > Are these features actually being used? Apparently - assuming I've correctly connected the dots: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016359 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#97002): https://edk2.groups.io/g/devel/message/97002 Mute This Topic: https://groups.io/mt/92635541/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
© 2016 - 2026 Red Hat, Inc.