From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) by mx.groups.io with SMTP id smtpd.web10.1005.1583531570800730041 for ; Fri, 06 Mar 2020 13:52:50 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@oracle.com header.s=corp-2020-01-29 header.b=G09anBa+; spf=pass (domain: oracle.com, ip: 141.146.126.78, mailfrom: liran.alon@oracle.com) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 026LqKNe002617; Fri, 6 Mar 2020 21:52:50 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=bV14+4gDRe3pH1RdseT5h+oqR+dfdnLdmOoT6tXtGOQ=; b=G09anBa+fIou8LS26e7O36dnFunKekcEErGYLQKica8eWJeJpQqGWiNJcoRHx6ee/62g 9qoHLEE3CuPpJD0phZ7+iBrLkTjOMolSJE2Mecx51BJfwhZTnP7zCYcMWbojaHUuoRVz L8FKNK0SGEy0QVaJGwTMxHHjKMDUbKqJyEVokzeBpIRCVjKJmZVJF8e3wLG2e1tkQTOz mlqh7DcErO8Mm8zxyFWzEu8q0wCxBs2sVNRE/Fer7zEPmIrCqqXX+nGFeThgI90pObuT ELYqU3mx+39CyHBmtdmrEk5HPbe61W7xEUY/naGlqIO/Ydw56zLAvR0FFJGKG2SGQQsr dw== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2120.oracle.com with ESMTP id 2yffwrdq3g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 06 Mar 2020 21:52:49 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 026Lkpei085771; Fri, 6 Mar 2020 21:52:49 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3020.oracle.com with ESMTP id 2yg1s1wn5w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 06 Mar 2020 21:52:49 +0000 Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 026Lql8d009023; Fri, 6 Mar 2020 21:52:47 GMT Received: from Lirans-MacBook-Pro.local (/79.183.35.100) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 06 Mar 2020 13:52:47 -0800 Subject: Re: [edk2-devel] [PATCH v3 00/13] OvmfPkg: Support booting from Fusion-MPT SCSI controllers To: Laszlo Ersek , devel@edk2.groups.io, nikita.leshchenko@oracle.com Cc: aaron.young@oracle.com, jordan.l.justen@intel.com, ard.biesheuvel@linaro.org References: <20200304192257.96736-1-nikita.leshchenko@oracle.com> <3a37741e-6241-5bcf-3f09-071a98868888@redhat.com> From: Liran Alon Message-ID: Date: Fri, 6 Mar 2020 23:52:42 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <3a37741e-6241-5bcf-3f09-071a98868888@redhat.com> X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9552 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 mlxlogscore=999 suspectscore=0 malwarescore=0 adultscore=0 spamscore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2003060126 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9552 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 spamscore=0 impostorscore=0 malwarescore=0 mlxlogscore=999 mlxscore=0 suspectscore=0 phishscore=0 clxscore=1015 bulkscore=0 adultscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2003060126 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Hi Lazlo, On 06/03/2020 22:14, Laszlo Ersek wrote: > 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 :) ). The motivation behind supporting booting from these devices is being able to run VMs that originally run on other hypervisors, such as VMware ESXi, on top of QEMU/KVM without any changes to the image (In contrast to approaches such as virt-v2v, Amazon CloudEndure or Google Velostrata). This technology was developed in Ravello Systems (Acquired by Oracle), which offered a product to run VMware-based images on top of any public cloud without any modification to the VMs. This is also why you would also see QEMU PVSCSI device emulation and SeaBIOS PVSCSI driver were contributed by Ravello as-well. Similar work to Ravello was done by Virtuozzo for Hyper-V based VMs (See their enhancements to QEMU of emulating Hyper-V PV devices). They also have EDK2 drivers for these devices that are not upstream. Having said that, it is true that these two patch-series provide feature parity with SeaBIOS. I do believe that it makes sense OVMF will support booting from any storage device that QEMU is able to emulate. Especially if SeaBIOS is already able to boot from that device as-well. > > 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, I don't think the description we have written in the relevant BugZilla tickets should change much. It's still true that these are contributed as part of feature-parity with SeaBIOS and allowing to boot from these devices. How one use this depends on it's own use-case. It could be to be able to boot VMware-based VMs as-is under QEMU/KVM, but it could also be used to boot a VM with a PVSCSI controller that was originally created with QEMU/KVM. This is similar to upstream commit c137d9508169 ("OvmfPkg/QemuVideoDxe: VMWare SVGA device support") which added support for VMware-SVGA GPU. > > (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 > . Funny. I was about to point out that the Xen PV drivers are not conditioned by any flag! :) OK. I think it's appropriate we will add a separate flag for each device and make them both TRUE by default (As I think should be appropriate for any device built-in by default into QEMU). Thanks, -Liran > > Thanks! > Laszlo >