The read_config and write_config functions in the generic virtio
headers used by all drivers lead to compiler warnings resp. errors
if effective-c++ switch is enabled. Moreover, the functions require
to define the access width as parameter. We can better turn them
into template functions using the value type to read resp. write to
derive the access width.
Ref genodelabs/genode#4344
The key changes in this patch are:
* Buffer allocation is moved into a separate Buffer_pool helper. The
implementation of the buffer allocation strategy does not change.
The helper allocates a single RAM dataspace and splits it in multiple,
equally sized chunks.
* Management of main descriptor ring is enacapsulated in Descriptor_ring
helper class.
* Use separate RAM dataspaces for descriptor rings and buffers.
Previously both of them were packed into a single dataspace. This
might have been more RAM efficient, but IMO it made the code uglier and
harder to understand.
* All of the VirtIO::Queue members are now initialized on the class member
initializer list. This is possible due to previously listed changes.
* Since all VirtIO::Queue members are initalized on member initalizer
list, some additional ones can be marked as const, ex _avail, _used ring
pointers.
* Move descriptor writing code into a common method used by both
write_data and write_data_read_reply members. This avoids some code
duplication between those methods.
* Get rid of request_irq argument that most public VirtIO::Queue methods
accept. None of the existing drivers use it and I doubt this will
change any time soon.
* Use Genode namespace by default in Virtio.
This patch also fixes at least one bug that I discovered while working
on VirtIO block device driver. Namely, when chaining descriptors only the
first descriptor in the chain should be exposed in the available ring.
Issue #4347
Thanks to Piotr Tworek for the fix and his explanation as follows:
The basic idea is to try to fit payload data into the descriptor used to
send the header. If there is no payload, or the payload fits exactly
into the remaining space in the header decriptor, len should be 0 and
only one descriptor should be used. In such case the "next" and "flags"
members of the descriptor structure should be set to 0.
In case there is some extra payload data to send, but its size is
bigger than the remaining free space in the descriptor used to send the
header, len should contain the remaining size of the payload that
can't be sent via the header descriptor. The code will then chain
additional descriptors to handle this remainder.
With the len variable shadowing, the code will never queue the remaining
data.
Issue #4327
Some more advanced devices like VirtIO GPU do expect they can receive
responses to VirtIO commands they issue via VirtIO queue. Such responses
are not sent via a separate device writeable queue. Instead the driver
is expected to queue some additional descriptors and buffers which the
device can then use to provide the reply.
This patch adds support for such write-data-read-response opeartion to
Genode VirtIO::Queue implementation. The implementation is pretty simple
and does not support any fancy features like receiving the response
asynchronously. Instead the operation will use caller provided callback
to wait for the device to process the command. Once this callback
returns the write-data-read-response VirtIO::Queue function will invoke
another callback passing received response as argument.
The contents of those descriptor rings can be modified by the device.
Mark them as volatile so the compiler does not make any assumptions
about them.
Issue #4264
* The device XML information dataspace is only provided,
when the client's policy states `info="yes"`
* The device XM information gets changed to include the
physical resource names (I/O memory and IRQ addresses)
instead of virtual ids and page offset
Fix#4077
To simplify writing native VirtIO drivers for Genode add helper classes
representing VirtIO device and queue. The queue implementation should
be platform independant. The device abstraction however is closely tied
to the VirtIO transport being used (PCI/MMIO). Both PCI and MMIO
implementations expose the same public API so the actual driver logic
should be the same regardless of which transport is used.
Its also important to note that the PCI version of Virtio::Device
currently does not support MSI-X interrupts. Unfortunately my kowledge
about PCI bus is very limited and my main area of interest was to get
VirtIO drivers working on virt_qemu ARM/Aarch64 platform. As such all
the VirtIO drivers I plan to submit will work with PCI bus, but might
not use some extended capabilities.
Ref #3825
