summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/PvScsiDxe
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: Update code to be more C11 compliant by using __func__Rebecca Cran2023-04-101-2/+2
| | | | | | | | | | | | | __FUNCTION__ is a pre-standard extension that gcc and Visual C++ among others support, while __func__ was standardized in C99. Since it's more standard, replace __FUNCTION__ with __func__ throughout OvmfPkg. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
* OvmfPkg: Apply uncrustify changesMichael Kubacki2021-12-072-217/+228
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the OvmfPkg package Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Andrew Fish <afish@apple.com>
* OvmfPkg/PvScsiDxe: Refactor setup of rings to separate functionLiran Alon2020-04-011-51/+58
| | | | | | | | | | | | | | | | | | | | | Previous to this change, PvScsiFreeRings() was not undoing all operations that was done by PvScsiInitRings(). This is because PvScsiInitRings() was both preparing rings (Allocate memory and map it for device DMA) and setup the rings against device by issueing a device command. While PvScsiFreeRings() only unmaps the rings and free their memory. Driver do not have a functional error as it makes sure to reset device before every call site to PvScsiFreeRings(). However, this is not intuitive. Therefore, prefer to refactor the setup of the ring against device to a separate function than PvScsiInitRings(). Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200331225637.123318-1-liran.alon@oracle.com> [lersek@redhat.com: rename FreeDMACommBuffer label to FreeDmaCommBuffer] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PvScsiDxe: Fix VS2019 build error because of implicit castLiran Alon2020-04-011-1/+5
| | | | | | | | | | | | | | | | | | | | | | | Sean reported that VS2019 build produce the following build error: INFO - PvScsi.c INFO - Generating code INFO - d:\a\1\s\OvmfPkg\PvScsiDxe\PvScsi.c(459): error C2220: the following warning is treated as an error INFO - d:\a\1\s\OvmfPkg\PvScsiDxe\PvScsi.c(459): warning C4244: '=': conversion from 'const UINT16' to 'UINT8', possible loss of data This result from an implicit cast from PVSCSI Response->ScsiStatus (Which is UINT16) to Packet->TargetResponse (Which is UINT8). Fix this issue by adding an appropriate explicit cast and verify with assert that this truncation do not result in loss of data. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2651 Reported-by: Sean Brogan <sean.brogan@microsoft.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200331110452.51992-1-liran.alon@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: rewrap VS2019 diags in commit msg for PatchCheck.py]
* OvmfPkg/PvScsiDxe: Enable device 64-bit DMA addressesLiran Alon2020-03-301-0/+23
| | | | | | | | | | | Enable PCI dual-address cycle attribute to signal device supports 64-bit DMA addresses. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-18-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
* OvmfPkg/PvScsiDxe: Reset device on ExitBootServices()Liran Alon2020-03-302-1/+43
| | | | | | | | | | | | This causes the device to forget about the request/completion rings. We allocated said rings in EfiBootServicesData type memory, and code executing after ExitBootServices() is permitted to overwrite it. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-17-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
* OvmfPkg/PvScsiDxe: Support sending SCSI request and receive responseLiran Alon2020-03-303-3/+459
| | | | | | | | | | | | | Implement EXT_SCSI_PASS_THRU.PassThru(). Machines should be able to boot after this commit. Tested with Ubuntu 16.04 guest. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-16-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PvScsiDxe: Introduce DMA communication bufferLiran Alon2020-03-302-2/+58
| | | | | | | | | | | | | | | | | | | In case device is constrained by IOMMU or guest is running under AMD SEV, input/output buffers provided to device (DataBuffer and SenseData) needs to be explicitly mapped to device by PciIo->Map(). To avoid the overhead of mapping/unmapping the DataBuffer and SenseData to the device for every SCSI requst (and to simplify code), introduce a single DMA communication buffer that will be mapped to device on initialization. When a SCSI request needs to be sent to device, the DataBuffer and SenseData will be copied from/to the DMA communication buffer as required. This will be done by the following commits. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-15-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PvScsiDxe: Setup requests and completions ringsLiran Alon2020-03-303-0/+237
| | | | | | | | | | | | | | | | These rings are shared memory buffers between host and device in which a cyclic buffer is managed to send request descriptors from host to device and receive completion descriptors from device to host. Note that because device may be constrained by IOMMU or guest may be run under AMD SEV, we make sure to map these rings to device by using PciIo->Map(). Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-14-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PvScsiDxe: Reset adapter on initLiran Alon2020-03-301-0/+114
| | | | | | | | | | | The following commits will complete the implementation of device initialization. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-13-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
* OvmfPkg/PvScsiDxe: Enable MMIO-Space & Bus-Mastering in PCI attributesLiran Alon2020-03-301-1/+11
| | | | | | | | | | | Enable MMIO-Space & Bus-Mastering PCI attributes when device is started. Note that original PCI attributes are restored when device is stopped. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-11-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
* OvmfPkg/PvScsiDxe: Backup/Restore PCI attributes on Init/UnInitLiran Alon2020-03-302-1/+54
| | | | | | | | | | | | This commit doesn't change semantics. It is done as a preparation for future commits which will modify PCI attributes. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-10-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
* OvmfPkg/PvScsiDxe: Open PciIo protocol for later useLiran Alon2020-03-302-1/+29
| | | | | | | | | | | This will give us an exclusive access to the PciIo of this device after it was started and until it will be stopped. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-9-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
* OvmfPkg/PvScsiDxe: Translate Target & LUN to/from DevicePathLiran Alon2020-03-301-2/+59
| | | | | | | | | | | Implement EXT_SCSI_PASS_THRU.BuildDevicePath() and EXT_SCSI_PASS_THRU.GetTargetLun(). Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-8-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
* OvmfPkg/PvScsiDxe: Report the number of targets and LUNsLiran Alon2020-03-303-2/+127
| | | | | | | | | | | | | | | | | | | | | | Implement EXT_SCSI_PASS_THRU.GetNextTarget() and EXT_SCSI_PASS_THRU.GetNextTargetLun(). ScsiBusDxe scans all MaxTarget * MaxLun possible devices. This can take unnecessarily long for large number of targets. To deal with this, VirtioScsiDxe has defined PCDs to limit the MaxTarget & MaxLun to desired values which gives sufficient performance. It is very important in virtio-scsi as it can have very big MaxTarget & MaxLun. Even though a common PVSCSI device has a default MaxTarget=64 and MaxLun=0, we implement similar mechanism as virtio-scsi for completeness. This may be useful in the future when PVSCSI will have bigger values for MaxTarget and MaxLun. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-7-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
* OvmfPkg/PvScsiDxe: Install stubbed EXT_SCSI_PASS_THRULiran Alon2020-03-303-3/+241
| | | | | | | | | | Support dynamic insertion and removal of the protocol. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-6-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
* OvmfPkg/PvScsiDxe: Probe PCI devices and look for PvScsiLiran Alon2020-03-302-1/+53
| | | | | | | | | | | | | PvScsiControllerSupported() is called on handles passed in by the ConnectController() boot service and if the handle is the PVSCSI controller, the function would return success. A success return value will attach our driver to the device. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-5-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
* OvmfPkg/PvScsiDxe: Report name of driverLiran Alon2020-03-301-2/+57
| | | | | | | | | | | Install Component Name protocols to have a nice display name for the driver in places such as UEFI shell. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-4-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
* OvmfPkg/PvScsiDxe: Install DriverBinding protocolLiran Alon2020-03-302-1/+66
| | | | | | | | | | | In order to probe and connect to the PvScsi device we need this protocol. Currently it does nothing. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-3-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
* OvmfPkg/PvScsiDxe: Create empty driverLiran Alon2020-03-302-0/+53
In preparation for support booting from PvScsi devices, create a basic scaffolding for a driver. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-2-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>