From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.120]) by mx.groups.io with SMTP id smtpd.web11.4645.1592390369013479763 for ; Wed, 17 Jun 2020 03:39:29 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=K1k4gqgt; spf=pass (domain: redhat.com, ip: 205.139.110.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592390368; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ROosaWGHQHj4LhcqeoDdXkD3HyPo9KjqmkijxZ481Ro=; b=K1k4gqgt3nYDtIniiTvnyuKwiB/xzkXLEGmWSc8pIQwPvHHQPhVfpnXxO6+NeNiz4Qwnb2 H+roJUDKUGikon9SmY7NkPOjCpqDILp1hOyLLEyALwK6a9R1fEg7h/lLfJKejuwtRuvrAS ZRovIFaIcApqzXa7QHLbGZKEBpf3CoE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-490-iMfpHBUoPyeBmSu51un3Pg-1; Wed, 17 Jun 2020 06:38:37 -0400 X-MC-Unique: iMfpHBUoPyeBmSu51un3Pg-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6220A102CC32; Wed, 17 Jun 2020 10:38:36 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-115-92.ams2.redhat.com [10.36.115.92]) by smtp.corp.redhat.com (Postfix) with ESMTP id 737E05D9D3; Wed, 17 Jun 2020 10:38:35 +0000 (UTC) Subject: Re: [RFC PATCH 1/1] OvmfPkg: Introduce LSI 53C895A SCSI Controller Driver To: Gary Lin Cc: devel@edk2.groups.io, Jordan Justen , Ard Biesheuvel References: <20200612100451.12832-1-glin@suse.com> <06577314-ae06-ed01-8c59-f533466efecc@redhat.com> <20200617020908.GC18504@GaryWorkstation> From: "Laszlo Ersek" Message-ID: <99277128-7971-0a92-047b-1c4338afdad5@redhat.com> Date: Wed, 17 Jun 2020 12:38:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20200617020908.GC18504@GaryWorkstation> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 06/17/20 04:09, Gary Lin wrote: > On Mon, Jun 15, 2020 at 01:27:22PM +0200, Laszlo Ersek wrote: >> Hello Gary, >> > Hi Laszlo, > >> On 06/12/20 12:04, Gary Lin wrote: >>> This commit introduces the driver for LSI 53C895A SCSI Controller >>> which, so that OVMF can access the devices attached to the emulated >>> "lsi" SCSI controller. >>> >>> Cc: Jordan Justen >>> Cc: Laszlo Ersek >>> Cc: Ard Biesheuvel >>> Signed-off-by: Gary Lin >>> --- >>> Although lsi is now considered obsolete in QEMU, I wrote this driver >>> mainly for learning the UEFI SCSI driver and ... FUN! The majority of >>> the code is actually borrowed from VirtioScsci and MptScsi, and I >>> mainly focus on LsiScsiPassThru(). >>> >>> If it's fine to add this driver into OvmfPkg, I'll start to split this >>> patch into smaller pieces to make it easier to review. >> >> (1) Do we have an official deprecation notice for this SCSI controller >> in QEMU? >> >> If we do, then (AIUI) the controller will be removed in QEMU in one or >> two releases, so this code would become effectively dead in the mid >> term. I wouldn't like to review and/or carry code that's soon to be >> dead. >> > I just vaguely remember that virtio-scsi is the new default over lsi and > it's not recommended to use lsi except for the old OS without virtio-scsi > driver. So the question is then whether the old OS that supports LSI but not virtio-scsi is capable of booting on UEFI in the first place. > >> (2) If there is no official deprecation notice in QEMU, then I agree it >> makes sense to include this driver. In that case, I have another >> question: >> >> Do you intend this driver for production purposes? I.e., do you expect >> users or "layered products" (libvirt, proxmox, openstack, ...) to use >> this SCSI controller for some well-defined purpose? (The MPT SCSI and PV >> SCSI drivers had a clear product-oriented modivation: >> >> https://edk2.groups.io/g/devel/message/55620 >> http://mid.mail-archive.com/a96b6b74-c35d-e291-2122-9d77f1d5f89c@oracle.com >> ) >> >> (2a) If this driver is not meant for a production environment, then >> LSI_SCSI_ENABLE should be FALSE by default (and I'll do a lighter >> review). >> >> (2b) If the driver is meant for production, then LSI_SCSI_ENABLE should >> indeed be TRUE, and I'll have to be more diligent in reviewing this. >> > I kind of wonder if the any serious use for lsi+ovmf. If the OS is so > old and only supports lsi, seabios probably serves it better. Right, my point exactly! > Anyway, > I'll try to gather more information from my colleagues to see if they > got any feedback about lsi from our customers. If not, I'll set > LSI_SCSI_ENABLE to FALSE by default. Sounds like a good approach! > >> For either (2a) or (2b), please do split up the driver into smaller >> patches, and please also add yourself to Maintainers.txt as the >> designated reviewer of the new driver. >> > Sure. Will do that. Thanks! Laszlo