From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C1D8D211DCDB7 for ; Thu, 14 Mar 2019 07:28:32 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BB05131649B7; Thu, 14 Mar 2019 14:28:31 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-123-206.rdu2.redhat.com [10.10.123.206]) by smtp.corp.redhat.com (Postfix) with ESMTP id D93B25D73D; Thu, 14 Mar 2019 14:28:30 +0000 (UTC) To: "You, Benjamin" , "edk2-devel@lists.01.org" References: From: Laszlo Ersek Message-ID: Date: Thu, 14 Mar 2019 15:28:29 +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: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Thu, 14 Mar 2019 14:28:31 +0000 (UTC) Subject: Re: [staging/PRMCaseStudy]: Creating a new feature branch "PRMCaseStudy" X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 14:28:33 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 03/14/19 09:46, You, Benjamin wrote: > Hi, > > > > A new feature branch "PRMCaseStudy" is being created in edk2-staging. > > > Platform Runtime Mechanism (PRM) is an architecture for ACPI codes to call into UEFI BIOS's Runtime Services at OS runtime. Traditionally, ACPI codes call into BIOS through the invocation of Software SMIs. When applicable, PRM provides an alternative for ACPI codes to invoke UEFI Runtime Services, which runs in OS kernel space, without invoking SMM. > > This package contains proof-of-concept codes that implement the ideas of PRM. > > Resources: > > - PRM introduction: https://www.opencompute.org/events/past-summits (Please search for "UEFI Implementation Intel(r) Xeon Based OCP Platform" in the webpage, which lists pointers to video and presentation that introduce the concept of PRM) > - TianoCore: http://www.tianocore.org > - UEFI Forum: https://uefi.org/ (I've read the slides now. Hopefully I understand them sufficiently for making reasonable comments below.) While this feature looks exciting and nice from a technical standpoint, I think it would have a bad effect on operating system drivers, in particular in open source operating systems. Currently, as far as I know, the best quality OS hw drivers are those that (a) manipulate hardware directly, and (b) are developed against open hardware specs. In comparison, this feature promotes a generic OS->firmware call interface. It allows platform vendors to liberally define UEFI runtime services, and OS-level drivers to call those platform-specific UEFI runtime services through semi-standardized ACPI methods. As a result, more and more OS hw drivers (especially for platform hardware) would be written on top of ACPI, and not on top of hardware access / hardware specs. I don't think that ACPI-based OS drivers for platform hardware are a bad thing; I think that making that kind of driver development *too easy* is a bad thing. Here's why: - every such OS driver is harder to develop & debug for the OS developer, because there's another layer of software between them and the hardware that they cannot change, and can debug only with difficulties - if the semi-standardized ACPI interfaces are too heavy-weight or too coarse-grained, then they might not integrate well into the driver framework of an OS. This can lead to bad performance and/or missing features. - the *easy* availability of such a runtime OS->firmware interface will tempt hardware vendors to cut corners and add platform hacks to e.g. PCI Express or USB devices, or even to implement devices that should be PCIE or USB in the first place as platform devices. We've already seen too much of that mess. Devices with platform hacks, and platform devices, are very hard to isolate and to use from virtual machines (as assigned (aka "passthrough") devices), for example. But even without virtualization, the same kind of isolation may be necessary for hw drivers implemented in userspace. I'm totally a fan of ACPI (over DT, e.g.) for devices that *must* be platform devices. I'm very much not a fan of platform devices themselves. In summary: The runtime involvement of firmware should be minimized. The PRM approach seems to make that problem *worse* however, by widening the firmware's runtime role, through side-stepping the current problems of SMM. My apologies if I've missed details, or if my comments are otherwise misguided. Thanks Laszlo