Recent changes to the arm64 MMU code mean that you can no longer map
R/O memory as R/W. Mapping R/W memory now causes a cache invalidation
instruction (DC IVAC) that requires write permissions or else a fault
is generated.
Modify ivshmem-v2 to map each R/O and R/W section individually
Signed-off-by: Grant Ramsay <gramsay@enphaseenergy.com>
The ivshmem code does not use any platform-specific code; therefore,
remove the dependency to the soc interface.
No functional change intended.
Signed-off-by: Rodrigo Cataldo <rodrigo.cataldo@huawei.com>
Co-authored-by: Henri Xavier <datacomos@huawei.com>
There was a bunch of BDF lookup code in the ivshmem driver originating
from issues with not being able to have multiple PCIE_BDF_NONE entries
in DTS. Now that devices are always looked up based on VID/DID this
should not be an issue, and hence the additional code is not needed.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Use the new PCIe core infrastructure for looking up the BDF at runtime
based on the VID/DID values.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
In order to bring consistency in-tree, migrate all drivers to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
- Supporting multiple instances of ivShMem virtual devices.
- Introduces DT based configuration for ivShMem devices.
- Add DTS overlay file to test new multiple ivshmem instance capability.
- Enable BDF unspecified device initialization.
(limited to one instance. An improved version of pcie_bdf_lookup()
will come soon that fixes this limitation)
- Make PCIE DTS file macros available for a proper ivshmem device
properties parsing.
Sample for dts file:
pcie0 {
label = "PCIE_0";
#address-cells = <1>;
#size-cells = <1>;
compatible = "intel,pcie";
ranges;
ivshmem0: ivshmem@800 {
compatible = "qemu,ivshmem";
reg = <PCIE_BDF_NONE PCIE_ID(0x1af4,0x1110)>;
label = "IVSHMEM";
status = "okay";
};
};
Signed-off-by: Michael Schmidt <michael1.schmidt@intel.com>
commit id ec2b9d42af missed that ivshmem
uses pcie_msi_enable as well, thus fixing it now.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This is a fix for ACRN targets. Qemu ivshmem original specs do not
states that, if ivshmem-plain is selected, bar0 (the register bar) will
not be present. It just says that bar2 will only be sufficient.
And that is what happens on qemu: whether ivshmem-plain or
ivshmem-doorbell is selected, bar0 is always present no matter what.
This does not seem to be the case in ACRN which does not expose the
bar0 if ivshmem-plain is selected.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This basically adds support for an interrupt based ivshmem variant
called "ivshmem-doorbell".
This allows, via MSI-X, to get multiple vectors for notifications, get
assigned and ID and being able to send a message to another ID (another
VM).
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This is placed into drivers/virtualization as it does not belong to any
existing subsystem.
This is only the ivshmem-plain variant.
This device is provided by qemu or ACRN, and can be used to share memory
either between the host and the VM or between VMs. Here if zephyr is
used as a VM, it will be able to take advantage of such feature.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
