zephyr

Commit Graph

Author	SHA1	Message	Date
Grygorii Strashko	e549bc702a	drivers: xen: gnttab: process gnttabs in reverse order 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>	5 months ago
Dmytro Firsov	71b9ec2c2c	drivers: xen: gnttab: remove redundant GNTTABOP_setup_table call 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>	5 months ago
Dmytro Firsov	cd31a41328	drivers: xen: gnttab: limit number of grant frames via config 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>	5 months ago
Dmytro Firsov	0e21b25245	drivers: xen: gnttab: prevent double-free for grant refs 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>	5 months ago
Dmytro Firsov	3f92a8bbdd	drivers: xen: gnttab: use correct struct for grant frames unmapping 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>	5 months ago
Mykola Kvach	62fd5ab3e1	drivers: xen: gnttab: do Xen node mapping inside driver 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>	2 years ago
Carlo Caione	2fa807bcd1	barriers: Move __DMB() to the new API Remove the arch-specific ARM-centric __DMB() macro and use the new barrier API instead. Signed-off-by: Carlo Caione <ccaione@baylibre.com>	2 years ago
Gerard Marull-Paretas	a5fd0d184a	init: remove the need for a dummy device pointer in SYS_INIT functions 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>	2 years ago
Tomislav Milkovic	0fe2c1fe90	everywhere: Fix legacy include paths 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>	3 years ago
Anas Nashif	49b36ead95	drivers: add mising braces to single line if statements Following zephyr's style guideline, all if statements, including single line statements shall have braces. Signed-off-by: Anas Nashif <anas.nashif@intel.com>	3 years ago
Dmytro Firsov	f4cea5da70	xenvm: drivers: xen: add Xen grant table driver 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>	3 years ago

11 Commits (697d0f845d26692929ea3cb15a968c64f6925856)