audk/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.h

177 lines
4.1 KiB
C
Raw Normal View History

OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11 17:57:59 +01:00
/** @file
Internal definitions for the VirtIo MMIO Device driver
Copyright (C) 2013, ARM Ltd
Copyright (C) 2017, AMD Inc. All rights reserved.<BR>
OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11 17:57:59 +01:00
SPDX-License-Identifier: BSD-2-Clause-Patent
OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11 17:57:59 +01:00
**/
#ifndef _VIRTIO_MMIO_DEVICE_INTERNAL_H_
#define _VIRTIO_MMIO_DEVICE_INTERNAL_H_
#include <Protocol/VirtioDevice.h>
#include <IndustryStandard/Virtio.h>
#include <Library/DebugLib.h>
#include <Library/IoLib.h>
#include <Library/UefiLib.h>
#include <Library/VirtioMmioDeviceLib.h>
#include <Library/MemoryAllocationLib.h>
OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11 17:57:59 +01:00
#define VIRTIO_MMIO_DEVICE_SIGNATURE SIGNATURE_32 ('V', 'M', 'I', 'O')
#define VIRTIO_MMIO_DEVICE_VERSION_0_95 1
#define VIRTIO_MMIO_DEVICE_VERSION_1_00 2
OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11 17:57:59 +01:00
typedef struct {
UINT32 Signature;
UINT32 Version;
UINT16 QueueNum;
VIRTIO_DEVICE_PROTOCOL VirtioDevice;
PHYSICAL_ADDRESS BaseAddress;
OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11 17:57:59 +01:00
} VIRTIO_MMIO_DEVICE;
#define VIRTIO_MMIO_DEVICE_FROM_VIRTIO_DEVICE(Device) \
CR (Device, VIRTIO_MMIO_DEVICE, VirtioDevice, VIRTIO_MMIO_DEVICE_SIGNATURE)
#define VIRTIO_CFG_WRITE(Device, Offset, Val) \
(MmioWrite32 (Device->BaseAddress + (Offset), Val))
#define VIRTIO_CFG_READ(Device, Offset) \
(MmioRead32 (Device->BaseAddress + (Offset)))
EFI_STATUS
EFIAPI
VirtioMmioDeviceRead (
IN VIRTIO_DEVICE_PROTOCOL *This,
IN UINTN FieldOFfset,
IN UINTN FieldSize,
IN UINTN BufferSize,
OUT VOID *Buffer
OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11 17:57:59 +01:00
);
EFI_STATUS
EFIAPI
VirtioMmioDeviceWrite (
IN VIRTIO_DEVICE_PROTOCOL *This,
IN UINTN FieldOffset,
IN UINTN FieldSize,
IN UINT64 Value
OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11 17:57:59 +01:00
);
EFI_STATUS
EFIAPI
VirtioMmioGetDeviceFeatures (
IN VIRTIO_DEVICE_PROTOCOL *This,
OUT UINT64 *DeviceFeatures
OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11 17:57:59 +01:00
);
EFI_STATUS
EFIAPI
VirtioMmioGetQueueSize (
IN VIRTIO_DEVICE_PROTOCOL *This,
OUT UINT16 *QueueNumMax
);
EFI_STATUS
EFIAPI
VirtioMmioGetDeviceStatus (
IN VIRTIO_DEVICE_PROTOCOL *This,
OUT UINT8 *DeviceStatus
);
EFI_STATUS
EFIAPI
VirtioMmioSetQueueSize (
IN VIRTIO_DEVICE_PROTOCOL *This,
IN UINT16 QueueSize
OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11 17:57:59 +01:00
);
EFI_STATUS
EFIAPI
VirtioMmioSetDeviceStatus (
IN VIRTIO_DEVICE_PROTOCOL *This,
IN UINT8 DeviceStatus
OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11 17:57:59 +01:00
);
EFI_STATUS
EFIAPI
VirtioMmioSetQueueNotify (
IN VIRTIO_DEVICE_PROTOCOL *This,
IN UINT16 QueueNotify
OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11 17:57:59 +01:00
);
EFI_STATUS
EFIAPI
VirtioMmioSetQueueSel (
IN VIRTIO_DEVICE_PROTOCOL *This,
IN UINT16 Sel
OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11 17:57:59 +01:00
);
EFI_STATUS
EFIAPI
OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11 17:57:59 +01:00
VirtioMmioSetQueueAddress (
IN VIRTIO_DEVICE_PROTOCOL *This,
IN VRING *Ring,
IN UINT64 RingBaseShift
OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11 17:57:59 +01:00
);
EFI_STATUS
EFIAPI
VirtioMmioSetQueueAlignment (
IN VIRTIO_DEVICE_PROTOCOL *This,
IN UINT32 Alignment
OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11 17:57:59 +01:00
);
EFI_STATUS
EFIAPI
VirtioMmioSetPageSize (
IN VIRTIO_DEVICE_PROTOCOL *This,
IN UINT32 PageSize
OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11 17:57:59 +01:00
);
EFI_STATUS
EFIAPI
VirtioMmioSetGuestFeatures (
IN VIRTIO_DEVICE_PROTOCOL *This,
IN UINT64 Features
OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11 17:57:59 +01:00
);
EFI_STATUS
EFIAPI
VirtioMmioAllocateSharedPages (
IN VIRTIO_DEVICE_PROTOCOL *This,
IN UINTN NumPages,
OUT VOID **HostAddress
);
VOID
EFIAPI
VirtioMmioFreeSharedPages (
IN VIRTIO_DEVICE_PROTOCOL *This,
IN UINTN NumPages,
IN VOID *HostAddress
);
EFI_STATUS
EFIAPI
VirtioMmioMapSharedBuffer (
IN VIRTIO_DEVICE_PROTOCOL *This,
IN VIRTIO_MAP_OPERATION Operation,
IN VOID *HostAddress,
IN OUT UINTN *NumberOfBytes,
OUT EFI_PHYSICAL_ADDRESS *DeviceAddress,
OUT VOID **Mapping
);
EFI_STATUS
EFIAPI
VirtioMmioUnmapSharedBuffer (
IN VIRTIO_DEVICE_PROTOCOL *This,
IN VOID *Mapping
);
OvmfPkg/VirtioMmioDeviceLib: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo Devices over MMIO Why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? The UEFI driver model would encourage to create a virtio-mmio driver instead of a library. But the reasons why I created a library are: - A virtio-mmio driver would imply an additional protocol that would probably have a single attribute field: typedef struct { PHYSICAL_ADDRESS BaseAddress; } VIRTIO_MMIO_DEVICE_PROTOCOL; - There is no (easy) way to scan the available VirtIo devices on a platform. So, the UEFI firmware for this platform would need a driver to produce instances for every virtio devices it wants to expose in UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib) make the porting easier. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - typo fix in VirtioMmioInstallDevice() comment block - plug MmioDevice leak in VirtioMmioUninstallDevice() - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if QueueAddress is NULL - VirtioMmioSetQueueSize(): fix return value (it's a status code) - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus EFI_UNSUPPORTED, rather than ASSERT() - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant (FieldSize > 8) checks - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14965 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11 17:57:59 +01:00
#endif // _VIRTIO_MMIO_DEVICE_INTERNAL_H_