OvmfPkg/VirtioFsDxe: DriverBinding: open VirtioDevice, install SimpleFs
Complete the Supported, Start, and Stop member functions of
EFI_DRIVER_BINDING_PROTOCOL sufficiently for exercising the UEFI driver
model:
- bind virtio-fs devices,
- produce placeholder EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instances on them.
On the "TO_START" (= Virtio) side, the VirtioFsBindingSupported() function
verifies the Virtio subsystem ID for the virtio-fs device (decimal 26 --
see
<https://github.com/oasis-tcs/virtio-spec/blob/87fa6b5d8155/virtio-fs.tex>).
Beyond that, no actual Virtio setup is performed for now. Those bits are
going to be implemented later in this series.
On the "BY_START" (= UEFI filesystem) side, the VirtioFsOpenVolume()
function -- which is the sole EFI_SIMPLE_FILE_SYSTEM_PROTOCOL member
function -- is a stub; it always returns EFI_NO_MEDIA, for now.
The "CONNECT", "DISCONNECT", and "MAP -R" UEFI Shell commands can be used
to test this patch.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-4-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
2020-12-16 22:10:40 +01:00
|
|
|
/** @file
|
|
|
|
Internal macro definitions, type definitions, and function declarations for
|
|
|
|
the Virtio Filesystem device driver.
|
|
|
|
|
|
|
|
Copyright (C) 2020, Red Hat, Inc.
|
|
|
|
|
|
|
|
SPDX-License-Identifier: BSD-2-Clause-Patent
|
|
|
|
**/
|
|
|
|
|
|
|
|
#ifndef VIRTIO_FS_DXE_H_
|
|
|
|
#define VIRTIO_FS_DXE_H_
|
|
|
|
|
|
|
|
#include <Base.h> // SIGNATURE_64()
|
2020-12-16 22:10:58 +01:00
|
|
|
#include <Guid/FileInfo.h> // EFI_FILE_INFO
|
2020-12-16 22:10:41 +01:00
|
|
|
#include <IndustryStandard/VirtioFs.h> // VIRTIO_FS_TAG_BYTES
|
OvmfPkg/VirtioFsDxe: DriverBinding: open VirtioDevice, install SimpleFs
Complete the Supported, Start, and Stop member functions of
EFI_DRIVER_BINDING_PROTOCOL sufficiently for exercising the UEFI driver
model:
- bind virtio-fs devices,
- produce placeholder EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instances on them.
On the "TO_START" (= Virtio) side, the VirtioFsBindingSupported() function
verifies the Virtio subsystem ID for the virtio-fs device (decimal 26 --
see
<https://github.com/oasis-tcs/virtio-spec/blob/87fa6b5d8155/virtio-fs.tex>).
Beyond that, no actual Virtio setup is performed for now. Those bits are
going to be implemented later in this series.
On the "BY_START" (= UEFI filesystem) side, the VirtioFsOpenVolume()
function -- which is the sole EFI_SIMPLE_FILE_SYSTEM_PROTOCOL member
function -- is a stub; it always returns EFI_NO_MEDIA, for now.
The "CONNECT", "DISCONNECT", and "MAP -R" UEFI Shell commands can be used
to test this patch.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-4-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
2020-12-16 22:10:40 +01:00
|
|
|
#include <Library/DebugLib.h> // CR()
|
|
|
|
#include <Protocol/SimpleFileSystem.h> // EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
|
|
|
|
#include <Protocol/VirtioDevice.h> // VIRTIO_DEVICE_PROTOCOL
|
2020-12-16 22:10:41 +01:00
|
|
|
#include <Uefi/UefiBaseType.h> // EFI_EVENT
|
OvmfPkg/VirtioFsDxe: DriverBinding: open VirtioDevice, install SimpleFs
Complete the Supported, Start, and Stop member functions of
EFI_DRIVER_BINDING_PROTOCOL sufficiently for exercising the UEFI driver
model:
- bind virtio-fs devices,
- produce placeholder EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instances on them.
On the "TO_START" (= Virtio) side, the VirtioFsBindingSupported() function
verifies the Virtio subsystem ID for the virtio-fs device (decimal 26 --
see
<https://github.com/oasis-tcs/virtio-spec/blob/87fa6b5d8155/virtio-fs.tex>).
Beyond that, no actual Virtio setup is performed for now. Those bits are
going to be implemented later in this series.
On the "BY_START" (= UEFI filesystem) side, the VirtioFsOpenVolume()
function -- which is the sole EFI_SIMPLE_FILE_SYSTEM_PROTOCOL member
function -- is a stub; it always returns EFI_NO_MEDIA, for now.
The "CONNECT", "DISCONNECT", and "MAP -R" UEFI Shell commands can be used
to test this patch.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-4-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
2020-12-16 22:10:40 +01:00
|
|
|
|
|
|
|
#define VIRTIO_FS_SIG SIGNATURE_64 ('V', 'I', 'R', 'T', 'I', 'O', 'F', 'S')
|
|
|
|
|
OvmfPkg/VirtioFsDxe: implement EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume()
With the help of the VirtioFsFuseOpenDir() and
VirtioFsFuseReleaseFileOrDir() functions introduced previously, we can now
open and close the root directory. So let's implement
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume().
OpenVolume() creates a new EFI_FILE_PROTOCOL object -- a reference to the
root directory of the filesystem. Thus, we have to start tracking
references to EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, lest we unbind the
virtio-fs device while files are open.
There are two methods that release an EFI_FILE_PROTOCOL object: the
Close() and the Delete() member functions. In particular, they are not
allowed to fail with regard to resource management -- they must release
resources unconditionally. Thus, for rolling back the resource accounting
that we do in EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume(), we have to
implement the first versions of EFI_FILE_PROTOCOL.Close() and
EFI_FILE_PROTOCOL.Delete() in this patch as well.
With this patch applied, the UEFI shell can enter the root directory of
the Virtio Filesystem (such as with the "FS3:" shell command), and the
"DIR" shell command exercises FUSE_OPENDIR and FUSE_RELEASEDIR, according
to the virtiofsd log. The "DIR" command reports the root directory as if
it were empty; probably because at this time, we only allow the shell to
open and to close the root directory, but not to read it.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-12-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
2020-12-16 22:10:48 +01:00
|
|
|
#define VIRTIO_FS_FILE_SIG \
|
|
|
|
SIGNATURE_64 ('V', 'I', 'O', 'F', 'S', 'F', 'I', 'L')
|
|
|
|
|
OvmfPkg/VirtioFsDxe: add helper for appending and sanitizing paths
EFI_FILE_PROTOCOL.Open() -- for opening files -- and
EFI_FILE_PROTOCOL.SetInfo() -- for renaming files -- will require us to
append a relative UEFI pathname to an absolute base pathname. In turn,
components of the resultant pathnames will have to be sent to virtiofsd,
which does not consume UEFI-style pathnames.
We're going to maintain the base pathnames in canonical POSIX format:
- absolute (starts with "/"),
- dot (.) and dot-dot (..) components resolved/removed,
- uses forward slashes,
- sequences of slashes collapsed,
- printable ASCII character set,
- CHAR8 encoding,
- no trailing slash except for the root directory itself,
- length at most VIRTIO_FS_MAX_PATHNAME_LENGTH.
Add a helper function that can append a UEFI pathname to such a base
pathname, and produce the result in conformance with the same invariants.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-17-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
2020-12-16 22:10:53 +01:00
|
|
|
//
|
|
|
|
// The following limit applies to two kinds of pathnames.
|
|
|
|
//
|
|
|
|
// - The length of a POSIX-style, canonical pathname *at rest* never exceeds
|
|
|
|
// VIRTIO_FS_MAX_PATHNAME_LENGTH. (Length is defined as the number of CHAR8
|
|
|
|
// elements in the canonical pathname, excluding the terminating '\0'.) This
|
|
|
|
// is an invariant that is ensured for canonical pathnames created, and that
|
|
|
|
// is assumed about canonical pathname inputs (which all originate
|
|
|
|
// internally).
|
|
|
|
//
|
|
|
|
// - If the length of a UEFI-style pathname *argument*, originating directly or
|
|
|
|
// indirectly from the EFI_FILE_PROTOCOL caller, exceeds
|
|
|
|
// VIRTIO_FS_MAX_PATHNAME_LENGTH, then the argument is rejected. (Length is
|
|
|
|
// defined as the number of CHAR16 elements in the UEFI-style pathname,
|
|
|
|
// excluding the terminating L'\0'.) This is a restriction that's checked on
|
|
|
|
// external UEFI-style pathname inputs.
|
|
|
|
//
|
|
|
|
// The limit is not expected to be a practical limitation; it's only supposed
|
|
|
|
// to prevent attempts at overflowing size calculations. For both kinds of
|
|
|
|
// pathnames, separate limits could be used; a common limit is used purely for
|
|
|
|
// simplicity.
|
|
|
|
//
|
|
|
|
#define VIRTIO_FS_MAX_PATHNAME_LENGTH ((UINTN)65535)
|
|
|
|
|
2020-12-16 22:11:12 +01:00
|
|
|
//
|
|
|
|
// Maximum value for VIRTIO_FS_FILE.NumFileInfo.
|
|
|
|
//
|
|
|
|
#define VIRTIO_FS_FILE_MAX_FILE_INFO 256
|
|
|
|
|
2020-12-16 22:10:41 +01:00
|
|
|
//
|
|
|
|
// Filesystem label encoded in UCS-2, transformed from the UTF-8 representation
|
|
|
|
// in "VIRTIO_FS_CONFIG.Tag", and NUL-terminated. Only the printable ASCII code
|
|
|
|
// points (U+0020 through U+007E) are supported.
|
|
|
|
//
|
|
|
|
typedef CHAR16 VIRTIO_FS_LABEL[VIRTIO_FS_TAG_BYTES + 1];
|
|
|
|
|
OvmfPkg/VirtioFsDxe: DriverBinding: open VirtioDevice, install SimpleFs
Complete the Supported, Start, and Stop member functions of
EFI_DRIVER_BINDING_PROTOCOL sufficiently for exercising the UEFI driver
model:
- bind virtio-fs devices,
- produce placeholder EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instances on them.
On the "TO_START" (= Virtio) side, the VirtioFsBindingSupported() function
verifies the Virtio subsystem ID for the virtio-fs device (decimal 26 --
see
<https://github.com/oasis-tcs/virtio-spec/blob/87fa6b5d8155/virtio-fs.tex>).
Beyond that, no actual Virtio setup is performed for now. Those bits are
going to be implemented later in this series.
On the "BY_START" (= UEFI filesystem) side, the VirtioFsOpenVolume()
function -- which is the sole EFI_SIMPLE_FILE_SYSTEM_PROTOCOL member
function -- is a stub; it always returns EFI_NO_MEDIA, for now.
The "CONNECT", "DISCONNECT", and "MAP -R" UEFI Shell commands can be used
to test this patch.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-4-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
2020-12-16 22:10:40 +01:00
|
|
|
//
|
|
|
|
// Main context structure, expressing an EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
|
|
|
|
// interface on top of the Virtio Filesystem device.
|
|
|
|
//
|
|
|
|
typedef struct {
|
|
|
|
//
|
|
|
|
// Parts of this structure are initialized / torn down in various functions
|
|
|
|
// at various call depths. The table to the right should make it easier to
|
|
|
|
// track them.
|
|
|
|
//
|
|
|
|
// field init function init depth
|
|
|
|
// ----------- ------------------ ----------
|
|
|
|
UINT64 Signature; // DriverBindingStart 0
|
|
|
|
VIRTIO_DEVICE_PROTOCOL *Virtio; // DriverBindingStart 0
|
2020-12-16 22:10:41 +01:00
|
|
|
VIRTIO_FS_LABEL Label; // VirtioFsInit 1
|
|
|
|
UINT16 QueueSize; // VirtioFsInit 1
|
|
|
|
VRING Ring; // VirtioRingInit 2
|
|
|
|
VOID *RingMap; // VirtioRingMap 2
|
2020-12-16 22:10:45 +01:00
|
|
|
UINT64 RequestId; // FuseInitSession 1
|
2020-12-16 22:11:15 +01:00
|
|
|
UINT32 MaxWrite; // FuseInitSession 1
|
2020-12-16 22:10:41 +01:00
|
|
|
EFI_EVENT ExitBoot; // DriverBindingStart 0
|
OvmfPkg/VirtioFsDxe: implement EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume()
With the help of the VirtioFsFuseOpenDir() and
VirtioFsFuseReleaseFileOrDir() functions introduced previously, we can now
open and close the root directory. So let's implement
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume().
OpenVolume() creates a new EFI_FILE_PROTOCOL object -- a reference to the
root directory of the filesystem. Thus, we have to start tracking
references to EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, lest we unbind the
virtio-fs device while files are open.
There are two methods that release an EFI_FILE_PROTOCOL object: the
Close() and the Delete() member functions. In particular, they are not
allowed to fail with regard to resource management -- they must release
resources unconditionally. Thus, for rolling back the resource accounting
that we do in EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume(), we have to
implement the first versions of EFI_FILE_PROTOCOL.Close() and
EFI_FILE_PROTOCOL.Delete() in this patch as well.
With this patch applied, the UEFI shell can enter the root directory of
the Virtio Filesystem (such as with the "FS3:" shell command), and the
"DIR" shell command exercises FUSE_OPENDIR and FUSE_RELEASEDIR, according
to the virtiofsd log. The "DIR" command reports the root directory as if
it were empty; probably because at this time, we only allow the shell to
open and to close the root directory, but not to read it.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-12-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
2020-12-16 22:10:48 +01:00
|
|
|
LIST_ENTRY OpenFiles; // DriverBindingStart 0
|
OvmfPkg/VirtioFsDxe: DriverBinding: open VirtioDevice, install SimpleFs
Complete the Supported, Start, and Stop member functions of
EFI_DRIVER_BINDING_PROTOCOL sufficiently for exercising the UEFI driver
model:
- bind virtio-fs devices,
- produce placeholder EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instances on them.
On the "TO_START" (= Virtio) side, the VirtioFsBindingSupported() function
verifies the Virtio subsystem ID for the virtio-fs device (decimal 26 --
see
<https://github.com/oasis-tcs/virtio-spec/blob/87fa6b5d8155/virtio-fs.tex>).
Beyond that, no actual Virtio setup is performed for now. Those bits are
going to be implemented later in this series.
On the "BY_START" (= UEFI filesystem) side, the VirtioFsOpenVolume()
function -- which is the sole EFI_SIMPLE_FILE_SYSTEM_PROTOCOL member
function -- is a stub; it always returns EFI_NO_MEDIA, for now.
The "CONNECT", "DISCONNECT", and "MAP -R" UEFI Shell commands can be used
to test this patch.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-4-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
2020-12-16 22:10:40 +01:00
|
|
|
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL SimpleFs; // DriverBindingStart 0
|
|
|
|
} VIRTIO_FS;
|
|
|
|
|
|
|
|
#define VIRTIO_FS_FROM_SIMPLE_FS(SimpleFsReference) \
|
|
|
|
CR (SimpleFsReference, VIRTIO_FS, SimpleFs, VIRTIO_FS_SIG);
|
|
|
|
|
2020-12-16 22:10:42 +01:00
|
|
|
//
|
|
|
|
// Structure for describing a contiguous buffer, potentially mapped for Virtio
|
|
|
|
// transfer.
|
|
|
|
//
|
|
|
|
typedef struct {
|
|
|
|
//
|
|
|
|
// The following fields originate from the owner of the buffer.
|
|
|
|
//
|
|
|
|
VOID *Buffer;
|
|
|
|
UINTN Size;
|
|
|
|
//
|
|
|
|
// All of the fields below, until the end of the structure, are
|
|
|
|
// zero-initialized when the structure is initially validated.
|
|
|
|
//
|
|
|
|
// Mapped, MappedAddress and Mapping are updated when the buffer is mapped
|
|
|
|
// for VirtioOperationBusMasterRead or VirtioOperationBusMasterWrite. They
|
|
|
|
// are again updated when the buffer is unmapped.
|
|
|
|
//
|
|
|
|
BOOLEAN Mapped;
|
|
|
|
EFI_PHYSICAL_ADDRESS MappedAddress;
|
|
|
|
VOID *Mapping;
|
|
|
|
//
|
|
|
|
// Transferred is updated after VirtioFlush() returns successfully:
|
|
|
|
// - for VirtioOperationBusMasterRead, Transferred is set to Size;
|
|
|
|
// - for VirtioOperationBusMasterWrite, Transferred is calculated from the
|
|
|
|
// UsedLen output parameter of VirtioFlush().
|
|
|
|
//
|
|
|
|
UINTN Transferred;
|
|
|
|
} VIRTIO_FS_IO_VECTOR;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Structure for describing a list of IO Vectors.
|
|
|
|
//
|
|
|
|
typedef struct {
|
|
|
|
//
|
|
|
|
// The following fields originate from the owner of the buffers.
|
|
|
|
//
|
|
|
|
VIRTIO_FS_IO_VECTOR *IoVec;
|
|
|
|
UINTN NumVec;
|
|
|
|
//
|
|
|
|
// TotalSize is calculated when the scatter-gather list is initially
|
|
|
|
// validated.
|
|
|
|
//
|
|
|
|
UINT32 TotalSize;
|
|
|
|
} VIRTIO_FS_SCATTER_GATHER_LIST;
|
|
|
|
|
OvmfPkg/VirtioFsDxe: implement EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume()
With the help of the VirtioFsFuseOpenDir() and
VirtioFsFuseReleaseFileOrDir() functions introduced previously, we can now
open and close the root directory. So let's implement
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume().
OpenVolume() creates a new EFI_FILE_PROTOCOL object -- a reference to the
root directory of the filesystem. Thus, we have to start tracking
references to EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, lest we unbind the
virtio-fs device while files are open.
There are two methods that release an EFI_FILE_PROTOCOL object: the
Close() and the Delete() member functions. In particular, they are not
allowed to fail with regard to resource management -- they must release
resources unconditionally. Thus, for rolling back the resource accounting
that we do in EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume(), we have to
implement the first versions of EFI_FILE_PROTOCOL.Close() and
EFI_FILE_PROTOCOL.Delete() in this patch as well.
With this patch applied, the UEFI shell can enter the root directory of
the Virtio Filesystem (such as with the "FS3:" shell command), and the
"DIR" shell command exercises FUSE_OPENDIR and FUSE_RELEASEDIR, according
to the virtiofsd log. The "DIR" command reports the root directory as if
it were empty; probably because at this time, we only allow the shell to
open and to close the root directory, but not to read it.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-12-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
2020-12-16 22:10:48 +01:00
|
|
|
//
|
|
|
|
// Private context structure that exposes EFI_FILE_PROTOCOL on top of an open
|
|
|
|
// FUSE file reference.
|
|
|
|
//
|
|
|
|
typedef struct {
|
|
|
|
UINT64 Signature;
|
|
|
|
EFI_FILE_PROTOCOL SimpleFile;
|
|
|
|
BOOLEAN IsDirectory;
|
2020-12-16 22:10:52 +01:00
|
|
|
BOOLEAN IsOpenForWriting;
|
OvmfPkg/VirtioFsDxe: implement EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume()
With the help of the VirtioFsFuseOpenDir() and
VirtioFsFuseReleaseFileOrDir() functions introduced previously, we can now
open and close the root directory. So let's implement
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume().
OpenVolume() creates a new EFI_FILE_PROTOCOL object -- a reference to the
root directory of the filesystem. Thus, we have to start tracking
references to EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, lest we unbind the
virtio-fs device while files are open.
There are two methods that release an EFI_FILE_PROTOCOL object: the
Close() and the Delete() member functions. In particular, they are not
allowed to fail with regard to resource management -- they must release
resources unconditionally. Thus, for rolling back the resource accounting
that we do in EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume(), we have to
implement the first versions of EFI_FILE_PROTOCOL.Close() and
EFI_FILE_PROTOCOL.Delete() in this patch as well.
With this patch applied, the UEFI shell can enter the root directory of
the Virtio Filesystem (such as with the "FS3:" shell command), and the
"DIR" shell command exercises FUSE_OPENDIR and FUSE_RELEASEDIR, according
to the virtiofsd log. The "DIR" command reports the root directory as if
it were empty; probably because at this time, we only allow the shell to
open and to close the root directory, but not to read it.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-12-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
2020-12-16 22:10:48 +01:00
|
|
|
VIRTIO_FS *OwnerFs;
|
|
|
|
LIST_ENTRY OpenFilesEntry;
|
2020-12-16 22:10:54 +01:00
|
|
|
CHAR8 *CanonicalPathname;
|
2020-12-16 22:11:08 +01:00
|
|
|
UINT64 FilePosition;
|
OvmfPkg/VirtioFsDxe: implement EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume()
With the help of the VirtioFsFuseOpenDir() and
VirtioFsFuseReleaseFileOrDir() functions introduced previously, we can now
open and close the root directory. So let's implement
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume().
OpenVolume() creates a new EFI_FILE_PROTOCOL object -- a reference to the
root directory of the filesystem. Thus, we have to start tracking
references to EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, lest we unbind the
virtio-fs device while files are open.
There are two methods that release an EFI_FILE_PROTOCOL object: the
Close() and the Delete() member functions. In particular, they are not
allowed to fail with regard to resource management -- they must release
resources unconditionally. Thus, for rolling back the resource accounting
that we do in EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume(), we have to
implement the first versions of EFI_FILE_PROTOCOL.Close() and
EFI_FILE_PROTOCOL.Delete() in this patch as well.
With this patch applied, the UEFI shell can enter the root directory of
the Virtio Filesystem (such as with the "FS3:" shell command), and the
"DIR" shell command exercises FUSE_OPENDIR and FUSE_RELEASEDIR, according
to the virtiofsd log. The "DIR" command reports the root directory as if
it were empty; probably because at this time, we only allow the shell to
open and to close the root directory, but not to read it.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-12-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
2020-12-16 22:10:48 +01:00
|
|
|
//
|
|
|
|
// In the FUSE wire protocol, every request except FUSE_INIT refers to a
|
|
|
|
// file, namely by the "VIRTIO_FS_FUSE_REQUEST.NodeId" field; that is, by the
|
|
|
|
// inode number of the file. However, some of the FUSE requests that we need
|
|
|
|
// for some of the EFI_FILE_PROTOCOL member functions require an open file
|
|
|
|
// handle *in addition* to the inode number. For simplicity, whenever a
|
|
|
|
// VIRTIO_FS_FILE object is created, primarily defined by its NodeId field,
|
|
|
|
// we also *open* the referenced file at once, and save the returned file
|
|
|
|
// handle in the FuseHandle field. This way, when an EFI_FILE_PROTOCOL member
|
|
|
|
// function must send a FUSE request that needs the file handle *in addition*
|
|
|
|
// to the inode number, FuseHandle will be at our disposal at once.
|
|
|
|
//
|
|
|
|
UINT64 NodeId;
|
|
|
|
UINT64 FuseHandle;
|
2020-12-16 22:11:12 +01:00
|
|
|
//
|
|
|
|
// EFI_FILE_INFO objects cached for an in-flight directory read.
|
|
|
|
//
|
|
|
|
// For reading through a directory stream with tolerable performance, we have
|
|
|
|
// to call FUSE_READDIRPLUS each time with such a buffer that can deliver a
|
|
|
|
// good number of variable size records (VIRTIO_FS_FUSE_DIRENTPLUS_RESPONSE
|
|
|
|
// elements). Every time we do that, we turn the whole bunch into an array of
|
|
|
|
// EFI_FILE_INFOs immediately. EFI_FILE_PROTOCOL.Read() invocations (on
|
|
|
|
// directories) will be served from this EFI_FILE_INFO cache.
|
|
|
|
//
|
|
|
|
UINT8 *FileInfoArray;
|
|
|
|
UINTN SingleFileInfoSize;
|
|
|
|
UINTN NumFileInfo;
|
|
|
|
UINTN NextFileInfo;
|
OvmfPkg/VirtioFsDxe: implement EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume()
With the help of the VirtioFsFuseOpenDir() and
VirtioFsFuseReleaseFileOrDir() functions introduced previously, we can now
open and close the root directory. So let's implement
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume().
OpenVolume() creates a new EFI_FILE_PROTOCOL object -- a reference to the
root directory of the filesystem. Thus, we have to start tracking
references to EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, lest we unbind the
virtio-fs device while files are open.
There are two methods that release an EFI_FILE_PROTOCOL object: the
Close() and the Delete() member functions. In particular, they are not
allowed to fail with regard to resource management -- they must release
resources unconditionally. Thus, for rolling back the resource accounting
that we do in EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume(), we have to
implement the first versions of EFI_FILE_PROTOCOL.Close() and
EFI_FILE_PROTOCOL.Delete() in this patch as well.
With this patch applied, the UEFI shell can enter the root directory of
the Virtio Filesystem (such as with the "FS3:" shell command), and the
"DIR" shell command exercises FUSE_OPENDIR and FUSE_RELEASEDIR, according
to the virtiofsd log. The "DIR" command reports the root directory as if
it were empty; probably because at this time, we only allow the shell to
open and to close the root directory, but not to read it.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-12-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
2020-12-16 22:10:48 +01:00
|
|
|
} VIRTIO_FS_FILE;
|
|
|
|
|
|
|
|
#define VIRTIO_FS_FILE_FROM_SIMPLE_FILE(SimpleFileReference) \
|
|
|
|
CR (SimpleFileReference, VIRTIO_FS_FILE, SimpleFile, VIRTIO_FS_FILE_SIG);
|
|
|
|
|
|
|
|
#define VIRTIO_FS_FILE_FROM_OPEN_FILES_ENTRY(OpenFilesEntryReference) \
|
|
|
|
CR (OpenFilesEntryReference, VIRTIO_FS_FILE, OpenFilesEntry, \
|
|
|
|
VIRTIO_FS_FILE_SIG);
|
|
|
|
|
2020-12-16 22:10:41 +01:00
|
|
|
//
|
|
|
|
// Initialization and helper routines for the Virtio Filesystem device.
|
|
|
|
//
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsInit (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs
|
|
|
|
);
|
|
|
|
|
|
|
|
VOID
|
|
|
|
VirtioFsUninit (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs
|
|
|
|
);
|
|
|
|
|
|
|
|
VOID
|
|
|
|
EFIAPI
|
|
|
|
VirtioFsExitBoot (
|
|
|
|
IN EFI_EVENT ExitBootEvent,
|
|
|
|
IN VOID *VirtioFsAsVoid
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:10:42 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsSgListsValidate (
|
|
|
|
IN VIRTIO_FS *VirtioFs,
|
|
|
|
IN OUT VIRTIO_FS_SCATTER_GATHER_LIST *RequestSgList,
|
|
|
|
IN OUT VIRTIO_FS_SCATTER_GATHER_LIST *ResponseSgList OPTIONAL
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsSgListsSubmit (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs,
|
|
|
|
IN OUT VIRTIO_FS_SCATTER_GATHER_LIST *RequestSgList,
|
|
|
|
IN OUT VIRTIO_FS_SCATTER_GATHER_LIST *ResponseSgList OPTIONAL
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:10:43 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsFuseNewRequest (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs,
|
|
|
|
OUT VIRTIO_FS_FUSE_REQUEST *Request,
|
|
|
|
IN UINT32 RequestSize,
|
2020-12-16 22:10:45 +01:00
|
|
|
IN VIRTIO_FS_FUSE_OPCODE Opcode,
|
2020-12-16 22:10:43 +01:00
|
|
|
IN UINT64 NodeId
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsFuseCheckResponse (
|
|
|
|
IN VIRTIO_FS_SCATTER_GATHER_LIST *ResponseSgList,
|
|
|
|
IN UINT64 RequestId,
|
|
|
|
OUT UINTN *TailBufferFill
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:10:44 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsErrnoToEfiStatus (
|
|
|
|
IN INT32 Errno
|
|
|
|
);
|
|
|
|
|
OvmfPkg/VirtioFsDxe: add helper for appending and sanitizing paths
EFI_FILE_PROTOCOL.Open() -- for opening files -- and
EFI_FILE_PROTOCOL.SetInfo() -- for renaming files -- will require us to
append a relative UEFI pathname to an absolute base pathname. In turn,
components of the resultant pathnames will have to be sent to virtiofsd,
which does not consume UEFI-style pathnames.
We're going to maintain the base pathnames in canonical POSIX format:
- absolute (starts with "/"),
- dot (.) and dot-dot (..) components resolved/removed,
- uses forward slashes,
- sequences of slashes collapsed,
- printable ASCII character set,
- CHAR8 encoding,
- no trailing slash except for the root directory itself,
- length at most VIRTIO_FS_MAX_PATHNAME_LENGTH.
Add a helper function that can append a UEFI pathname to such a base
pathname, and produce the result in conformance with the same invariants.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-17-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
2020-12-16 22:10:53 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsAppendPath (
|
|
|
|
IN CHAR8 *LhsPath8,
|
|
|
|
IN CHAR16 *RhsPath16,
|
|
|
|
OUT CHAR8 **ResultPath8,
|
|
|
|
OUT BOOLEAN *RootEscape
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:11:00 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsLookupMostSpecificParentDir (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs,
|
|
|
|
IN OUT CHAR8 *Path,
|
|
|
|
OUT UINT64 *DirNodeId,
|
|
|
|
OUT CHAR8 **LastComponent
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:11:06 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsGetBasename (
|
|
|
|
IN CHAR8 *Path,
|
|
|
|
OUT CHAR16 *Basename OPTIONAL,
|
|
|
|
IN OUT UINTN *BasenameSize
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:10:58 +01:00
|
|
|
EFI_STATUS
|
OvmfPkg/VirtioFsDxe: add helper for composing rename/move destination path
The EFI_FILE_PROTOCOL.SetInfo() member is somewhat under-specified; one of
its modes of operation is renaming/moving the file.
In order to create the destination pathname in canonical format, 2*2=4
cases have to be considered. For the sake of discussion, assume the
current canonical pathname of a VIRTIO_FS_FILE is "/home/user/f1.txt".
Then, consider the following rename/move requests from
EFI_FILE_PROTOCOL.SetInfo():
Destination requested Destination Move into Destination in
by SetInfo() relative? directory? canonical format
--------------------- ----------- ---------- -----------------------
L"\\dir\\f2.txt" no no "/dir/f2.txt"
L"\\dir\\" no yes "/dir/f1.txt"
L"dir\\f2.txt" yes no "/home/user/dir/f2.txt"
L"dir\\" yes yes "/home/user/dir/f1.txt"
Add the VirtioFsComposeRenameDestination() function, for composing the
last column from the current canonical pathname and the SetInfo() input.
The function works on the following principles:
- The prefix of the destination path is "/", if the SetInfo() rename
request is absolute.
Otherwise, the dest prefix is the "current directory" (the most specific
parent directory) of the original pathname (in the above example,
"/home/user").
- The suffix of the destination path is precisely the SetInfo() request
string, if the "move into directory" convenience format -- the trailing
backslash -- is not used. (In the above example, L"\\dir\\f2.txt" and
L"dir\\f2.txt".)
Otherwise, the suffix is the SetInfo() request, plus the original
basename (in the above example, L"\\dir\\f1.txt" and L"dir\\f1.txt").
- The complete destination is created by fusing the dest prefix and the
dest suffix, using the VirtioFsAppendPath() function.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-43-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
2020-12-16 22:11:19 +01:00
|
|
|
VirtioFsComposeRenameDestination (
|
|
|
|
IN CHAR8 *LhsPath8,
|
|
|
|
IN CHAR16 *RhsPath16,
|
|
|
|
OUT CHAR8 **ResultPath8,
|
|
|
|
OUT BOOLEAN *RootEscape
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
2020-12-16 22:10:58 +01:00
|
|
|
VirtioFsFuseAttrToEfiFileInfo (
|
|
|
|
IN VIRTIO_FS_FUSE_ATTRIBUTES_RESPONSE *FuseAttr,
|
|
|
|
OUT EFI_FILE_INFO *FileInfo
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:11:11 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsFuseDirentPlusToEfiFileInfo (
|
|
|
|
IN VIRTIO_FS_FUSE_DIRENTPLUS_RESPONSE *FuseDirent,
|
|
|
|
IN OUT EFI_FILE_INFO *FileInfo
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:11:22 +01:00
|
|
|
VOID
|
|
|
|
VirtioFsGetFuseSizeUpdate (
|
|
|
|
IN EFI_FILE_INFO *Info,
|
|
|
|
IN EFI_FILE_INFO *NewInfo,
|
|
|
|
OUT BOOLEAN *Update,
|
|
|
|
OUT UINT64 *Size
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:11:23 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsGetFuseTimeUpdates (
|
|
|
|
IN EFI_FILE_INFO *Info,
|
|
|
|
IN EFI_FILE_INFO *NewInfo,
|
|
|
|
OUT BOOLEAN *UpdateAtime,
|
|
|
|
OUT BOOLEAN *UpdateMtime,
|
|
|
|
OUT UINT64 *Atime,
|
|
|
|
OUT UINT64 *Mtime
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:11:24 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsGetFuseModeUpdate (
|
|
|
|
IN EFI_FILE_INFO *Info,
|
|
|
|
IN EFI_FILE_INFO *NewInfo,
|
|
|
|
OUT BOOLEAN *Update,
|
|
|
|
OUT UINT32 *Mode
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:10:45 +01:00
|
|
|
//
|
|
|
|
// Wrapper functions for FUSE commands (primitives).
|
|
|
|
//
|
|
|
|
|
2020-12-16 22:10:59 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsFuseLookup (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs,
|
|
|
|
IN UINT64 DirNodeId,
|
|
|
|
IN CHAR8 *Name,
|
|
|
|
OUT UINT64 *NodeId,
|
|
|
|
OUT VIRTIO_FS_FUSE_ATTRIBUTES_RESPONSE *FuseAttr
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:10:49 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsFuseForget (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs,
|
|
|
|
IN UINT64 NodeId
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:11:02 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsFuseGetAttr (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs,
|
|
|
|
IN UINT64 NodeId,
|
|
|
|
OUT VIRTIO_FS_FUSE_ATTRIBUTES_RESPONSE *FuseAttr
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:10:56 +01:00
|
|
|
EFI_STATUS
|
2020-12-16 22:11:21 +01:00
|
|
|
VirtioFsFuseSetAttr (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs,
|
|
|
|
IN UINT64 NodeId,
|
|
|
|
IN UINT64 *Size OPTIONAL,
|
|
|
|
IN UINT64 *Atime OPTIONAL,
|
|
|
|
IN UINT64 *Mtime OPTIONAL,
|
|
|
|
IN UINT32 *Mode OPTIONAL
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
2020-12-16 22:10:56 +01:00
|
|
|
VirtioFsFuseMkDir (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs,
|
|
|
|
IN UINT64 ParentNodeId,
|
|
|
|
IN CHAR8 *Name,
|
|
|
|
OUT UINT64 *NodeId
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:11:01 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsFuseRemoveFileOrDir (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs,
|
|
|
|
IN UINT64 ParentNodeId,
|
|
|
|
IN CHAR8 *Name,
|
|
|
|
IN BOOLEAN IsDir
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:10:55 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsFuseOpen (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs,
|
|
|
|
IN UINT64 NodeId,
|
|
|
|
IN BOOLEAN ReadWrite,
|
|
|
|
OUT UINT64 *FuseHandle
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:11:09 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsFuseReadFileOrDir (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs,
|
|
|
|
IN UINT64 NodeId,
|
|
|
|
IN UINT64 FuseHandle,
|
|
|
|
IN BOOLEAN IsDir,
|
|
|
|
IN UINT64 Offset,
|
|
|
|
IN OUT UINT32 *Size,
|
|
|
|
OUT VOID *Data
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:11:15 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsFuseWrite (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs,
|
|
|
|
IN UINT64 NodeId,
|
|
|
|
IN UINT64 FuseHandle,
|
|
|
|
IN UINT64 Offset,
|
|
|
|
IN OUT UINT32 *Size,
|
|
|
|
IN VOID *Data
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:11:05 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsFuseStatFs (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs,
|
|
|
|
IN UINT64 NodeId,
|
|
|
|
OUT VIRTIO_FS_FUSE_STATFS_RESPONSE *FilesysAttr
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:10:47 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsFuseReleaseFileOrDir (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs,
|
|
|
|
IN UINT64 NodeId,
|
|
|
|
IN UINT64 FuseHandle,
|
|
|
|
IN BOOLEAN IsDir
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:10:50 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsFuseFsyncFileOrDir (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs,
|
|
|
|
IN UINT64 NodeId,
|
|
|
|
IN UINT64 FuseHandle,
|
|
|
|
IN BOOLEAN IsDir
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:10:51 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsFuseFlush (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs,
|
|
|
|
IN UINT64 NodeId,
|
|
|
|
IN UINT64 FuseHandle
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:10:45 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsFuseInitSession (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:10:46 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsFuseOpenDir (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs,
|
|
|
|
IN UINT64 NodeId,
|
|
|
|
OUT UINT64 *FuseHandle
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:10:57 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsFuseOpenOrCreate (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs,
|
|
|
|
IN UINT64 ParentNodeId,
|
|
|
|
IN CHAR8 *Name,
|
|
|
|
OUT UINT64 *NodeId,
|
|
|
|
OUT UINT64 *FuseHandle
|
|
|
|
);
|
|
|
|
|
2020-12-16 22:11:18 +01:00
|
|
|
EFI_STATUS
|
|
|
|
VirtioFsFuseRename (
|
|
|
|
IN OUT VIRTIO_FS *VirtioFs,
|
|
|
|
IN UINT64 OldParentNodeId,
|
|
|
|
IN CHAR8 *OldName,
|
|
|
|
IN UINT64 NewParentNodeId,
|
|
|
|
IN CHAR8 *NewName
|
|
|
|
);
|
|
|
|
|
OvmfPkg/VirtioFsDxe: DriverBinding: open VirtioDevice, install SimpleFs
Complete the Supported, Start, and Stop member functions of
EFI_DRIVER_BINDING_PROTOCOL sufficiently for exercising the UEFI driver
model:
- bind virtio-fs devices,
- produce placeholder EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instances on them.
On the "TO_START" (= Virtio) side, the VirtioFsBindingSupported() function
verifies the Virtio subsystem ID for the virtio-fs device (decimal 26 --
see
<https://github.com/oasis-tcs/virtio-spec/blob/87fa6b5d8155/virtio-fs.tex>).
Beyond that, no actual Virtio setup is performed for now. Those bits are
going to be implemented later in this series.
On the "BY_START" (= UEFI filesystem) side, the VirtioFsOpenVolume()
function -- which is the sole EFI_SIMPLE_FILE_SYSTEM_PROTOCOL member
function -- is a stub; it always returns EFI_NO_MEDIA, for now.
The "CONNECT", "DISCONNECT", and "MAP -R" UEFI Shell commands can be used
to test this patch.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-4-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
2020-12-16 22:10:40 +01:00
|
|
|
//
|
|
|
|
// EFI_SIMPLE_FILE_SYSTEM_PROTOCOL member functions for the Virtio Filesystem
|
|
|
|
// driver.
|
|
|
|
//
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
VirtioFsOpenVolume (
|
|
|
|
IN EFI_SIMPLE_FILE_SYSTEM_PROTOCOL *This,
|
|
|
|
OUT EFI_FILE_PROTOCOL **Root
|
|
|
|
);
|
|
|
|
|
OvmfPkg/VirtioFsDxe: implement EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume()
With the help of the VirtioFsFuseOpenDir() and
VirtioFsFuseReleaseFileOrDir() functions introduced previously, we can now
open and close the root directory. So let's implement
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume().
OpenVolume() creates a new EFI_FILE_PROTOCOL object -- a reference to the
root directory of the filesystem. Thus, we have to start tracking
references to EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, lest we unbind the
virtio-fs device while files are open.
There are two methods that release an EFI_FILE_PROTOCOL object: the
Close() and the Delete() member functions. In particular, they are not
allowed to fail with regard to resource management -- they must release
resources unconditionally. Thus, for rolling back the resource accounting
that we do in EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume(), we have to
implement the first versions of EFI_FILE_PROTOCOL.Close() and
EFI_FILE_PROTOCOL.Delete() in this patch as well.
With this patch applied, the UEFI shell can enter the root directory of
the Virtio Filesystem (such as with the "FS3:" shell command), and the
"DIR" shell command exercises FUSE_OPENDIR and FUSE_RELEASEDIR, according
to the virtiofsd log. The "DIR" command reports the root directory as if
it were empty; probably because at this time, we only allow the shell to
open and to close the root directory, but not to read it.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-12-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
2020-12-16 22:10:48 +01:00
|
|
|
//
|
|
|
|
// EFI_FILE_PROTOCOL member functions for the Virtio Filesystem driver.
|
|
|
|
//
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
VirtioFsSimpleFileClose (
|
|
|
|
IN EFI_FILE_PROTOCOL *This
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
VirtioFsSimpleFileDelete (
|
|
|
|
IN EFI_FILE_PROTOCOL *This
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
VirtioFsSimpleFileFlush (
|
|
|
|
IN EFI_FILE_PROTOCOL *This
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
VirtioFsSimpleFileGetInfo (
|
|
|
|
IN EFI_FILE_PROTOCOL *This,
|
|
|
|
IN EFI_GUID *InformationType,
|
|
|
|
IN OUT UINTN *BufferSize,
|
|
|
|
OUT VOID *Buffer
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
VirtioFsSimpleFileGetPosition (
|
|
|
|
IN EFI_FILE_PROTOCOL *This,
|
|
|
|
OUT UINT64 *Position
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
VirtioFsSimpleFileOpen (
|
|
|
|
IN EFI_FILE_PROTOCOL *This,
|
|
|
|
OUT EFI_FILE_PROTOCOL **NewHandle,
|
|
|
|
IN CHAR16 *FileName,
|
|
|
|
IN UINT64 OpenMode,
|
|
|
|
IN UINT64 Attributes
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
VirtioFsSimpleFileRead (
|
|
|
|
IN EFI_FILE_PROTOCOL *This,
|
|
|
|
IN OUT UINTN *BufferSize,
|
|
|
|
OUT VOID *Buffer
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
VirtioFsSimpleFileSetInfo (
|
|
|
|
IN EFI_FILE_PROTOCOL *This,
|
|
|
|
IN EFI_GUID *InformationType,
|
|
|
|
IN UINTN BufferSize,
|
|
|
|
IN VOID *Buffer
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
VirtioFsSimpleFileSetPosition (
|
|
|
|
IN EFI_FILE_PROTOCOL *This,
|
|
|
|
IN UINT64 Position
|
|
|
|
);
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
VirtioFsSimpleFileWrite (
|
|
|
|
IN EFI_FILE_PROTOCOL *This,
|
|
|
|
IN OUT UINTN *BufferSize,
|
|
|
|
IN VOID *Buffer
|
|
|
|
);
|
|
|
|
|
OvmfPkg/VirtioFsDxe: DriverBinding: open VirtioDevice, install SimpleFs
Complete the Supported, Start, and Stop member functions of
EFI_DRIVER_BINDING_PROTOCOL sufficiently for exercising the UEFI driver
model:
- bind virtio-fs devices,
- produce placeholder EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instances on them.
On the "TO_START" (= Virtio) side, the VirtioFsBindingSupported() function
verifies the Virtio subsystem ID for the virtio-fs device (decimal 26 --
see
<https://github.com/oasis-tcs/virtio-spec/blob/87fa6b5d8155/virtio-fs.tex>).
Beyond that, no actual Virtio setup is performed for now. Those bits are
going to be implemented later in this series.
On the "BY_START" (= UEFI filesystem) side, the VirtioFsOpenVolume()
function -- which is the sole EFI_SIMPLE_FILE_SYSTEM_PROTOCOL member
function -- is a stub; it always returns EFI_NO_MEDIA, for now.
The "CONNECT", "DISCONNECT", and "MAP -R" UEFI Shell commands can be used
to test this patch.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-4-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
2020-12-16 22:10:40 +01:00
|
|
|
#endif // VIRTIO_FS_DXE_H_
|