The Xen extends domain grant tables every time domain requests gnttab
basing on gnttab idx. If idx > xen_current_max_gnttab_idx the Xen extends
grant table so that idx <= xen_current_max_gnttab_idx. The growing grant
tables on every hypercall is a bit costly operation and it also results in
the bunch of log messages:
(XEN) xen-source/xen/common/grant_table.c:1909:d0v0 Expanding d0 \
grant table from 1 to 2 frames
This patch changes gnttab processing from gnttab max_idx to low_idx, so the
first hypercall has the largest index, ensuring that the grant table will
grow only once. It also reduces number of log messages.
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Initially this driver was a port from mini-os. Michal Orzel
(@orzelmichal) pointed that it contains incorrect grant table
initialization sequence and redundant calls. Driver mapped grant table
frames via loop of XENMEM_add_to_physmap calls and then tried to do the
same but via GNTTABOP_setup_table operation. After completion of latter
it did not even use provided frames list. This did not cause any major
issues, since XENMEM_add_to_physmap correctly map gnttab frames that
were used.
Remove redundant GNTTABOP_setup_table call from grant table driver to
clean up its initialization sequence.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Xen allocates a region that should be used as a place for grant table
mapping and passes it via the device tree. By design, this region may
be quite large (up to 4096+ frames/pages), but the number of frames is
usually limited by the max_grant_frames domain parameter (usually 32 or
64).
Linux maps these frames on demand and when reaches mentioned limit
it just stops expanding. At the same time, previous implementation of
Zephyr gnttab driver calculated the number of grant frames by dividing
whole region by page size and tried to map it during init. If the
region specified in the device tree was larger than the
max_grant_frames set by Xen, it would fail on ASSERT, since Xen would
return an error.
To address these issues CONFIG_NR_GRANT_FRAMES was introduced. It
allows to limit size of grant table and map only required number of
pages. Additionally, a check for max_grant_frames Xen limit was
introduced to initialization - if this value will be less than
CONFIG_NR_GRANT_FRAMES, k_panic() will be called.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Grant references are allocated via simple O(1) allocator - idx of first
free gref is always stored in the "0" list entry (e.g. list[0] == "A").
Next free gref (e.g. B) will be stored inside list entry with the index
of previous (list[A] == B) and so on. This allows to find free gref
instantly if available. However, current implementation allows a user
to perform a double-free of some taken grefs since it doesn't store any
information about entries being currently claimed. This may cause
gref_list to break.
Add GNTTAB_GREF_USED value and mark all taken grefs with it to prevent
double free in put_grant_entry().
These changes also required updates for allocator and semaphore init
sequences, since we can not use put_free_entry() during driver
initialization anymore.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Previously the driver's 'gnttab_unmap_refs()' signature used incorrect
struct - the same one that is used for mapping. Since 'host_addr'
membber, that is used to point to required frame is first in both
structures it somehow worked.
Fix mistake and use 'struct gnttab_unmap_grant_ref' for grant frames
unmapping hypercalls.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
Move memory mapping of Xen node to Grant Table driver system init
function. After moving mapping we don't need anymore records of
xen-xen node into 'mmu_regions' array, so they were deleted from
all SoCs: Rcar Gen3/Gen4 and XenVM.
We need at least 16M of virtual address space to map memory of Xen
node, so the virtual memory sized has been increased to 32 MB, it
should be enough for basic use-cases and mapping of 16M mem region
of Xen node.
Unfortunately, after moving we also need to increase number of XLAT
tables. The previous code was more efficient if we talking about
usage of XLAT tables, because it mapped grant tables using a higher-
order table that allows mapping blocks of 2MB. And after the changes
is maps every 4KB page, so we need more XLAT tables.
Increase number of grant frames, it is needed to sync stage 1 and stage 2
memory mappings, previously we map only one page on stage 2 and further
usage of unmap regions can cause MMU translation errors.
Perform mapping stage 1 before mapping for stage 2 (add to physmap),
because right after stage 1 we can try to access memory and if it is
unmap in stage 2, error will be received during translation.
Note: Xen Grant Table driver doesn't use Zephyr Device Model.
Authored-by: Mykola Kvach <mykola_kvach@epam.com>
Co-authored-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
The init infrastructure, found in `init.h`, is currently used by:
- `SYS_INIT`: to call functions before `main`
- `DEVICE_*`: to initialize devices
They are all sorted according to an initialization level + a priority.
`SYS_INIT` calls are really orthogonal to devices, however, the required
function signature requires a `const struct device *dev` as a first
argument. The only reason for that is because the same init machinery is
used by devices, so we have something like:
```c
struct init_entry {
int (*init)(const struct device *dev);
/* only set by DEVICE_*, otherwise NULL */
const struct device *dev;
}
```
As a result, we end up with such weird/ugly pattern:
```c
static int my_init(const struct device *dev)
{
/* always NULL! add ARG_UNUSED to avoid compiler warning */
ARG_UNUSED(dev);
...
}
```
This is really a result of poor internals isolation. This patch proposes
a to make init entries more flexible so that they can accept sytem
initialization calls like this:
```c
static int my_init(void)
{
...
}
```
This is achieved using a union:
```c
union init_function {
/* for SYS_INIT, used when init_entry.dev == NULL */
int (*sys)(void);
/* for DEVICE*, used when init_entry.dev != NULL */
int (*dev)(const struct device *dev);
};
struct init_entry {
/* stores init function (either for SYS_INIT or DEVICE*)
union init_function init_fn;
/* stores device pointer for DEVICE*, NULL for SYS_INIT. Allows
* to know which union entry to call.
*/
const struct device *dev;
}
```
This solution **does not increase ROM usage**, and allows to offer clean
public APIs for both SYS_INIT and DEVICE*. Note that however, init
machinery keeps a coupling with devices.
**NOTE**: This is a breaking change! All `SYS_INIT` functions will need
to be converted to the new signature. See the script offered in the
following commit.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
init: convert SYS_INIT functions to the new signature
Conversion scripted using scripts/utils/migrate_sys_init.py.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
manifest: update projects for SYS_INIT changes
Update modules with updated SYS_INIT calls:
- hal_ti
- lvgl
- sof
- TraceRecorderSource
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: devicetree: devices: adjust test
Adjust test according to the recently introduced SYS_INIT
infrastructure.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: kernel: threads: adjust SYS_INIT call
Adjust to the new signature: int (*init_fn)(void);
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Any project with Kconfig option CONFIG_LEGACY_INCLUDE_PATH set to n
couldn't be built because some files were missing zephyr/ prefix in
includes
Re-run the migrate_includes.py script to fix all legacy include paths
Signed-off-by: Tomislav Milkovic <milkovic@byte-lab.com>
Following zephyr's style guideline, all if statements, including single
line statements shall have braces.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This commit introduces driver for granting access for own grant
table and for mapping/unmapping foreign gref. Grant tables are used
for data exchange between Xen domains via shared memory page(s) (e.g.
for sharing ring buffer with driver data) This functionality is
widely used and needed for implementing PV backend/frontend drivers.
Signed-off-by: Dmytro Firsov <dmytro_firsov@epam.com>
