From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.81]) by mx.groups.io with SMTP id smtpd.web10.1735.1583525678260035754 for ; Fri, 06 Mar 2020 12:14:38 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=FCZuMm4H; spf=pass (domain: redhat.com, ip: 207.211.31.81, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583525677; 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=Swb7N2v39N+8LqwEDiUqpmD+A5/S19ZBvl7gu9h7U98=; b=FCZuMm4H78cEgMPvUHfgcXtscpDt0468zCoJDs1ZkXJBPIs4JFNCaCVb1a14rZfdiZ/kde SQDNyeWeW6v+1N5SN8rQWodolLEIBMcvMd27OV2jV2AZZCY0MDFUDuGrG5ujlaHa24bfLF EgadHFPn/ZJwKVAA5WzP3ELVbX4cxag= 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-289-BKzk7PW3Npyyh7XORWMvUg-1; Fri, 06 Mar 2020 15:14:35 -0500 X-MC-Unique: BKzk7PW3Npyyh7XORWMvUg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3F3E5108088A; Fri, 6 Mar 2020 20:14:34 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-130.ams2.redhat.com [10.36.117.130]) by smtp.corp.redhat.com (Postfix) with ESMTP id CC9C692D20; Fri, 6 Mar 2020 20:14:32 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v3 00/13] OvmfPkg: Support booting from Fusion-MPT SCSI controllers To: devel@edk2.groups.io, nikita.leshchenko@oracle.com Cc: liran.alon@oracle.com, aaron.young@oracle.com, jordan.l.justen@intel.com, ard.biesheuvel@linaro.org References: <20200304192257.96736-1-nikita.leshchenko@oracle.com> From: "Laszlo Ersek" Message-ID: <3a37741e-6241-5bcf-3f09-071a98868888@redhat.com> Date: Fri, 6 Mar 2020 21:14:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20200304192257.96736-1-nikita.leshchenko@oracle.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Hi Nikita, On 03/04/20 20:22, Nikita Leshenko wrote: > This series adds driver support for: > - LSI53C1030 > - SAS1068 > - SAS1068E > > These controllers are widely supported by QEMU, VirtualBox and VMWare. > This work is part of the more general agenda of enhancing OVMF boot > device support to have feature parity with SeaBIOS. > > We have also developed support for PVSCSI which we will submit in a > separate patch series. I'd like to learn more of this general agenda ("feature parity with SeaBIOS"). I have never felt the need for any SCSI controller offered by QEMU other than virtio-scsi. Because you guys are contributing Fusion-MPT and PVSCSI to OVMF, obviously such a practical need must exist ("feature parity with SeaBIOS" is vague, I'm not really buying it :) ). So I have two requests: (1) please describe the actual use case (hypervisor, guest OS, maybe performance, etc) for these drivers, in the associated bugzilla, (2) please make the inclusion of these drivers in the OVMF DSC and FDF files dependent on a new build flag (-D). It's up to you whether you want to gate PVSCSI and Fusion-MPT with the same flag, or if you want to assign separate flags to them. It's fine if the default value is TRUE, for that flag (those flags). I'm asking for them from a downstream perspective -- some distros follow a "we ship it, we support it" model, and so they must be careful with rebases to new usptream releases. I'd like to permit such downstreams to easily disable these drivers, with just -D flags, without downstream-only patches for the OVMF DSC and FDF files, that might need repeated downstream rebasing and review. Again, it's perfectly fine if the upstream defaults are TRUE. ... If you feel tempted to point out the Xen paravirt drivers: you are entirely right, but those are already covered by . Thanks! Laszlo