The HYP init bounce page is a runtime construct that ensures that the
HYP init code does not cross a page boundary. However, this is something
we can do perfectly well at build time, by aligning the code appropriately.
For arm64, we just align to 4 KB, and enforce that the code size is less
than
From: Arnd Bergmann a...@arndb.de
When building large kernels, the linker will emit lots of veneers
into the .hyp.idmap.text section, which causes it to grow beyond
one page, and that triggers the build error.
This moves the section into .rodata instead, which avoids the
veneers and is safe
On Fri, 2015-03-06 at 10:41 +, Will Deacon wrote:
As a longer term solution, would it make sense to add a user flag at VFIO
user API level to turn the IOMMU_CACHE on?
I think userspace certainly needs a way to figure out if a device is
coherent or not, otherwise it can't generate the
This patch modifies the HYP init code so it can deal with system
RAM residing at an offset which exceeds the reach of VA_BITS.
Like for EL1, this involves configuring an additional level of
translation for the ID map. However, in case of EL2, this implies
that all translations use the extra
These are the VA range patches presented as a coherent set. The bounce page
and 'HYP init code too big' error are probably not prerequisites anymore now
that I switched from merging the HYP runtime map with the HYP id map rather
than the kernel ID map, but I would strongly prefer to keep it as a
The page size and the number of translation levels, and hence the supported
virtual address range, are build-time configurables on arm64 whose optimal
values are use case dependent. However, in the current implementation, if
the system's RAM is located at a very high offset, the virtual address
On 03/06/2015 12:27 PM, Baptiste Reynal wrote:
Hi everyone,
Indeed, the NOEXEC flag is needed for our tests and VFIO should work
without it for some other devices (including xgmac). I think it is
reasonable to drop this patch serie for now.
Still we have the IOMMU_CACHE issue. To answer
On 03/05/2015 10:11 PM, Alex Williamson wrote:
On Thu, 2015-03-05 at 18:34 +0100, Eric Auger wrote:
Hi All,
Ironically, since the correction of the IOMMU_CAP_CACHE_COHERENCY bug
(https://lkml.org/lkml/2015/1/29/514) in vfio_iommu_type1.c, my Calxeda
Midway VFIO use case is not working
Add two new memslot functions to the API
kvm_flush_incoherent_memory_regions
flush all KVM_MEM_INCOHERENT memslot addresses
kvm_invalidate_incoherent_memory_regions
invalidate all KVM_MEM_INCOHERENT memslot addresses
Signed-off-by: Andrew Jones drjo...@redhat.com
---
Signed-off-by: Andrew Jones drjo...@redhat.com
---
kvm-all.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kvm-all.c b/kvm-all.c
index 507fa7204e062..924b4a0bec21c 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -305,6 +305,9 @@ static int kvm_mem_flags(MemoryRegion *mr)
if (readonly
In reply to this message I'll send two series' one for KVM and
one for QEMU. The two series' are their respective component
complements, and attempt to implement cache coherency for arm
guests using emulated devices, where the emulator (qemu) uses
cached memory for the device memory, but the guest
Userspace flags memory regions as incoherent and kvm flushes/
invalidates those regions on entry/exit from userspace.
Result before patch 6/6: restores coherency, way t sloow
Result with patch 6/6: fast again - well, we removed the code...
Andrew Jones (6):
kvm: promote
Add the kvm_*_incoherent_memory_regions calls to arm's
kvm_arch_vcpu_ioctl_run and implement the corresponding
arch flush/invalidate functions.
Signed-off-by: Andrew Jones drjo...@redhat.com
---
arch/arm/include/uapi/asm/kvm.h | 1 +
arch/arm/kvm/arm.c| 4 +++
Should do a proper update-linux-headers.sh update.
Signed-off-by: Andrew Jones drjo...@redhat.com
---
linux-headers/linux/kvm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index 12045a11c036b..d04e2d781c43b 100644
---
14 matches
Mail list logo
