# Virtual PNOR Functionality

In the abstract, the virtual PNOR function shifts mboxd away from accessing raw
flash to dynamically presenting a raw flash image to the host from a set of
backing files.

Enabling the feature virtualises both the host's access to the flash (the mbox
protocol), and the BMC's access to the flash (via some filesystem on top of the
flash device).

## Do I want to use this feature in my platform?

Maybe. It depends on how the image construction is managed, particularly the
behaviour around writes from the host. It is likely the scheme will prevent
firmware updates from being correctly applied when using flash tools on the
host.

## Use-case Requirements

Currently, the virtual PNOR implementation requires that:

- The host expect an FFS layout (OpenPOWER systems)
- The BMC provide a directory tree presenting the backing files in a hierarchy
  that reflects the partition properties in the FFS table of contents.

## Implementation Behavioural Properties

1.  The FFS ToC defines the set of valid access ranges in terms of partitions
2.  The read-only property of partitions is enforced
3.  The ToC is considered read-only
4.  Read access to valid ranges must be granted
5.  Write access to valid ranges may be granted
6.  Access ranges that are valid may map into a backing file associated with the
    partition
7.  A read of a valid access range that maps into the backing file will render
    the data held in the backing file at the appropriate offset
8.  A read of a valid access range that does not map into the backing file will
    appear erased
9.  A read of an invalid access range will appear erased
10. A write to a valid access range that maps into the backing file will update
    the data in the file at the appropriate offset
11. A write to a valid access range that does not map into the backing file will
    expand the backing file to accommodate the write.
12. A write to a valid access range may fail if the range is not marked as
    writeable. The error should be returned in response to the request to open
    the write window intersecting the read-only range.
13. A write of an invalid access range will return an error. The error should be
    returned in response to the request to open the write window covering the
    invalid range.

The clarification on when the failure occurs in points 11 and 12 is useful for
host-side error handling. Opening a write window gives the indication that
future writes are expected to succeed, but in both cases we define them as
always failing. Therefore we should not give the impression to the host that
what it is asking for can be satisfied.