Re: [PATCH kvmtool v2] Add emulation for CFI compatible flash memory
On Thu, 20 Feb 2020 10:24:13 + Alexandru Elisei wrote: Hi, > On 2/19/20 5:26 PM, Andre Przywara wrote: > > On Mon, 17 Feb 2020 17:20:43 + > > Alexandru Elisei wrote: > > > > Hi, > > > >> I guess the device hasn't been tested with Linux. This is what I'm getting > >> when > >> trying to boot a Linux guest using the command: > > It was actually developed with a Linux guest, because that's more verbatim > > and easier to debug. > > > > And I just tested this again with Linux and it worked for me: > > The flash image you provided is 2 MB. The flash image that I used is 10 MB (it > shows in the log that I sent). I guess you ran a different test. What I stated below ... I guess there is some miscommunication here: I tested with Linux, just not with odd flash sizes. Which I agree should be either handled correctly or denied by kvmtool. > > > [2.164992] physmap-flash 2.flash: physmap platform flash device: > > [mem 0x0002-0x0021] > > [2.166539] 2.flash: Found 2 x16 devices at 0x0 in 32-bit bank. > > Manufacturer ID 0x00 Chip ID 0x00 > > ... > > # mtd_debug info /dev/mtd0 > > mtd.type = MTD_NORFLASH > > mtd.flags = MTD_CAP_NORFLASH > > mtd.size = 2097152 (2M) > > mtd.erasesize = 65536 (64K) > > mtd.writesize = 1 > > mtd.oobsize = 0 > > regions = 1 > > > > I think what you are seeing are problems when you give a non-power-of-2 > > sized flash image. The current patch does not really support this (since > > it's hardly a thing in the real world). I originally wanted to expand any > > "uneven" size to the next power-of-2, but this doesn't work easily with > > mmap. > > I would expect that if kvmtool allows the user to specify a non-power-of-2 > flash > image size, then it should know how to deal with it and not present a broken > device to a linux guest if that size is forbidden by the spec. Or it is > allowed by > the specification and kvmtool doesn't know how to deal with it? I don't know, I would guess physical flash has always a power-of-2 size, at least on a per-chip base. So the "spec" doesn't even consider the other case. > Instead of expanding the file provided by the user to fit a bigger flash, how > about you use the highest power of two size that is smaller than the flash > size? The original idea was to avoid cutting off the flash file, but this doesn't really work easily, or at least is not worth the effort. So I was suggesting the trimming you mentioned in the next sentence ;-) v > > So I now changed the code to downgrade, so you get 8MB with any file > > ranging from [8MB, 16MB(, for instance. > > That fixed the Linux problems with those files for me. > > > >> $ ./lkvm run -c4 -m4096 -k /path/to/kernel -d /path/to/disk -p > >> root="/dev/vda2" -F > >> flash.img > >> > >> [ 0.659167] physmap-flash 200.flash: physmap platform flash device: > >> [mem > >> 0x0200-0x029f] > >> [ 0.660444] Number of erase regions: 1 > >> [ 0.661036] Primary Vendor Command Set: 0001 (Intel/Sharp Extended) > >> [ 0.661688] Primary Algorithm Table at 0031 > >> [ 0.662168] Alternative Vendor Command Set: (None) > >> [ 0.662711] No Alternate Algorithm Table > >> [ 0.663120] Vcc Minimum: 4.5 V > >> [ 0.663450] Vcc Maximum: 5.5 V > >> [ 0.663779] No Vpp line > >> [ 0.664039] Typical byte/word write timeout: 2 µs > >> [ 0.664590] Maximum byte/word write timeout: 2 µs > >> [ 0.665240] Typical full buffer write timeout: 2 µs > >> [ 0.665775] Maximum full buffer write timeout: 2 µs > >> [ 0.666373] Typical block erase timeout: 2 ms > >> [ 0.666828] Maximum block erase timeout: 2 ms > >> [ 0.667282] Chip erase not supported > >> [ 0.667659] Device size: 0x80 bytes (8 MiB) > >> [ 0.668137] Flash Device Interface description: 0x0006 > >> [ 0.668697] - Unknown > >> [ 0.668963] Max. bytes in buffer write: 0x40 > >> [ 0.669407] Number of Erase Block Regions: 1 > >> [ 0.669865] Erase Region #0: BlockSize 0x8000 bytes, 160 blocks > >> [ 0.672299] 200.flash: Found 2 x16 devices at 0x0 in 32-bit bank. > >> Manufacturer ID 0x00 Chip ID 0x00 > >> [ 0.681328] NOR chip too large to fit in mapping. Attempting to cope... > >> [ 0.682046] Intel/Sharp Extended Query Table at 0x0031 > >> [ 0.682645] Using buffer write method > >> [ 0.683031] Sum of regions (a0) != total size of set of interleaved > >> chips > >> (100) > >> [ 0.683854] gen_probe: No supported Vendor Command Set found > >> [ 0.684441] physmap-flash 200.flash: map_probe failed > >> > >> I also defined DEBUG_CFI in drivers/mtd/chips/cfi_probe.c. > >> > >> The Flash Device Interface description that we provide is wrong, it should > >> 0x05. > >> More details below. > >> > >> On 2/7/20 12:19 PM, Andre Przywara wrote: > >>> From: Raphael Gault > >>> > >>> The EDK II UEFI firmware implementation requires some
Re: [PATCH 0/3] KVM: arm64: Ask the compiler to __always_inline functions used by KVM at HYP
On Thu, 20 Feb 2020 at 18:33, James Morse wrote: > > Hi Ard, > > On 20/02/2020 17:04, Ard Biesheuvel wrote: > > On Thu, 20 Feb 2020 at 17:58, James Morse wrote: > >> It turns out KVM relies on the inline hint being honoured by the compiler > >> in quite a few more places than expected. Something about the Shadow Call > >> Stack support[0] causes the compiler to avoid inline-ing and to place > >> these functions outside the __hyp_text. This ruins KVM's day. > >> > >> Add the simon-says __always_inline annotation to all the static > >> inlines that KVM calls from HYP code. > > > This isn't quite as yuck as I expected, fortunately, but it does beg > > the question whether we shouldn't simply map the entire kernel at EL2 > > instead? > > If the kernel is big enough to need internal veneers (the 128M range?), these > would > certainly go horribly wrong because its running somewhere other than the > relocation-time > address. We would need a way of telling the linker to keep the bits of KVM > close together... > Ah, of course, there is that as well ... ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH 0/3] KVM: arm64: Ask the compiler to __always_inline functions used by KVM at HYP
Hi Ard, On 20/02/2020 17:04, Ard Biesheuvel wrote: > On Thu, 20 Feb 2020 at 17:58, James Morse wrote: >> It turns out KVM relies on the inline hint being honoured by the compiler >> in quite a few more places than expected. Something about the Shadow Call >> Stack support[0] causes the compiler to avoid inline-ing and to place >> these functions outside the __hyp_text. This ruins KVM's day. >> >> Add the simon-says __always_inline annotation to all the static >> inlines that KVM calls from HYP code. > This isn't quite as yuck as I expected, fortunately, but it does beg > the question whether we shouldn't simply map the entire kernel at EL2 > instead? If the kernel is big enough to need internal veneers (the 128M range?), these would certainly go horribly wrong because its running somewhere other than the relocation-time address. We would need a way of telling the linker to keep the bits of KVM close together... Thanks, James ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH 0/3] KVM: arm64: Ask the compiler to __always_inline functions used by KVM at HYP
On Thu, 20 Feb 2020 at 17:58, James Morse wrote: > > Hello! > > It turns out KVM relies on the inline hint being honoured by the compiler > in quite a few more places than expected. Something about the Shadow Call > Stack support[0] causes the compiler to avoid inline-ing and to place > these functions outside the __hyp_text. This ruins KVM's day. > > Add the simon-says __always_inline annotation to all the static > inlines that KVM calls from HYP code. > > This series based on v5.6-rc2. > This isn't quite as yuck as I expected, fortunately, but it does beg the question whether we shouldn't simply map the entire kernel at EL2 instead? ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
[PATCH 3/3] arm64: Ask the compiler to __always_inline functions used by KVM at HYP
KVM uses some of the static-inline helpers like icache_is_vipt() from
its HYP code. This assumes the function is inlined so that the code is
mapped to EL2. The compiler may decide not to inline these, and the
out-of-line version may not be in the __hyp_text section.
Add the additional __always_ hint to these static-inlines that are used
by KVM.
Signed-off-by: James Morse
---
arch/arm64/include/asm/cache.h | 2 +-
arch/arm64/include/asm/cacheflush.h | 2 +-
arch/arm64/include/asm/cpufeature.h | 8
arch/arm64/include/asm/io.h | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h
index 806e9dc2a852..a4d1b5f771f6 100644
--- a/arch/arm64/include/asm/cache.h
+++ b/arch/arm64/include/asm/cache.h
@@ -69,7 +69,7 @@ static inline int icache_is_aliasing(void)
return test_bit(ICACHEF_ALIASING, &__icache_flags);
}
-static inline int icache_is_vpipt(void)
+static __always_inline int icache_is_vpipt(void)
{
return test_bit(ICACHEF_VPIPT, &__icache_flags);
}
diff --git a/arch/arm64/include/asm/cacheflush.h
b/arch/arm64/include/asm/cacheflush.h
index 665c78e0665a..e6cca3d4acf7 100644
--- a/arch/arm64/include/asm/cacheflush.h
+++ b/arch/arm64/include/asm/cacheflush.h
@@ -145,7 +145,7 @@ extern void copy_to_user_page(struct vm_area_struct *,
struct page *,
#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1
extern void flush_dcache_page(struct page *);
-static inline void __flush_icache_all(void)
+static __always_inline void __flush_icache_all(void)
{
if (cpus_have_const_cap(ARM64_HAS_CACHE_DIC))
return;
diff --git a/arch/arm64/include/asm/cpufeature.h
b/arch/arm64/include/asm/cpufeature.h
index 42ce41eef274..2a746b99e937 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -435,13 +435,13 @@ cpuid_feature_extract_signed_field(u64 features, int
field)
return cpuid_feature_extract_signed_field_width(features, field, 4);
}
-static inline unsigned int __attribute_const__
+static __always_inline unsigned int __attribute_const__
cpuid_feature_extract_unsigned_field_width(u64 features, int field, int width)
{
return (u64)(features << (64 - width - field)) >> (64 - width);
}
-static inline unsigned int __attribute_const__
+static __always_inline unsigned int __attribute_const__
cpuid_feature_extract_unsigned_field(u64 features, int field)
{
return cpuid_feature_extract_unsigned_field_width(features, field, 4);
@@ -564,7 +564,7 @@ static inline bool system_supports_mixed_endian(void)
return val == 0x1;
}
-static inline bool system_supports_fpsimd(void)
+static __always_inline bool system_supports_fpsimd(void)
{
return !cpus_have_const_cap(ARM64_HAS_NO_FPSIMD);
}
@@ -575,7 +575,7 @@ static inline bool system_uses_ttbr0_pan(void)
!cpus_have_const_cap(ARM64_HAS_PAN);
}
-static inline bool system_supports_sve(void)
+static __always_inline bool system_supports_sve(void)
{
return IS_ENABLED(CONFIG_ARM64_SVE) &&
cpus_have_const_cap(ARM64_SVE);
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 4e531f57147d..6facd1308e7c 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -34,7 +34,7 @@ static inline void __raw_writew(u16 val, volatile void
__iomem *addr)
}
#define __raw_writel __raw_writel
-static inline void __raw_writel(u32 val, volatile void __iomem *addr)
+static __always_inline void __raw_writel(u32 val, volatile void __iomem *addr)
{
asm volatile("str %w0, [%1]" : : "rZ" (val), "r" (addr));
}
@@ -69,7 +69,7 @@ static inline u16 __raw_readw(const volatile void __iomem
*addr)
}
#define __raw_readl __raw_readl
-static inline u32 __raw_readl(const volatile void __iomem *addr)
+static __always_inline u32 __raw_readl(const volatile void __iomem *addr)
{
u32 val;
asm volatile(ALTERNATIVE("ldr %w0, [%1]",
--
2.24.1
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
[PATCH 2/3] KVM: arm64: define our own swab32() to avoid a uapi static inline
KVM uses swab32() when mediating GIC MMIO accesses if the GICV is badly
aligned, and the host and guest differ in endianness.
arm64 doesn't provide a __arch_swab32(), so __fswab32() is always backed
by the macro implementation that the compiler reduces to a single
instruction. But the static-inline causes problems for KVM if the compiler
chooses not to inline this function, it may not be located in the
__hyp_text where __vgic_v2_perform_cpuif_access() needs it.
Create our own __kvm_swab32() macro that calls ___constant_swab32()
directly. This way we know it will always be inlined.
Signed-off-by: James Morse
---
arch/arm64/include/asm/kvm_hyp.h | 7 +++
arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c | 4 ++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index a3a6a2ba9a63..fe57f60f06a8 100644
--- a/arch/arm64/include/asm/kvm_hyp.h
+++ b/arch/arm64/include/asm/kvm_hyp.h
@@ -47,6 +47,13 @@
#define read_sysreg_el2(r) read_sysreg_elx(r, _EL2, _EL1)
#define write_sysreg_el2(v,r) write_sysreg_elx(v, r, _EL2, _EL1)
+/*
+ * Without an __arch_swab32(), we fall back to ___constant_swab32(), but the
+ * static inline can allow the compiler to out-of-line this. KVM always wants
+ * the macro version as its always inlined.
+ */
+#define __kvm_swab32(x)___constant_swab32(x)
+
int __vgic_v2_perform_cpuif_access(struct kvm_vcpu *vcpu);
void __vgic_v3_save_state(struct kvm_vcpu *vcpu);
diff --git a/arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c
b/arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c
index 29ee1feba4eb..4f3a087e36d5 100644
--- a/arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c
+++ b/arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c
@@ -69,14 +69,14 @@ int __hyp_text __vgic_v2_perform_cpuif_access(struct
kvm_vcpu *vcpu)
u32 data = vcpu_get_reg(vcpu, rd);
if (__is_be(vcpu)) {
/* guest pre-swabbed data, undo this for writel() */
- data = swab32(data);
+ data = __kvm_swab32(data);
}
writel_relaxed(data, addr);
} else {
u32 data = readl_relaxed(addr);
if (__is_be(vcpu)) {
/* guest expects swabbed data */
- data = swab32(data);
+ data = __kvm_swab32(data);
}
vcpu_set_reg(vcpu, rd, data);
}
--
2.24.1
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
[PATCH 1/3] KVM: arm64: Ask the compiler to __always_inline functions used at HYP
On non VHE CPUs, KVM's __hyp_text contains code run at EL2 while the rest
of the kernel runs at EL1. This code lives in its own section with start
and end markers so we can map it to EL2.
The compiler may decide not to inline static-inline functions from the
header file. It may also decide not to put these out-of-line functions
in the same section, meaning they aren't mapped when called at EL2.
Clang-9 does exactly this with __kern_hyp_va() and a few others when
x18 is reserved for the shadow call stack. Add the additional __always_
hint to all the static-inlines that are called from a hyp file.
Signed-off-by: James Morse
kvm_get_hyp_vector() pulls in all the regular per-cpu accessors
and this_cpu_has_cap(), fortunately its only called for VHE.
---
arch/arm64/include/asm/arch_gicv3.h | 2 +-
arch/arm64/include/asm/cpufeature.h | 2 +-
arch/arm64/include/asm/kvm_emulate.h | 48 ++--
arch/arm64/include/asm/kvm_mmu.h | 3 +-
arch/arm64/include/asm/virt.h| 2 +-
5 files changed, 29 insertions(+), 28 deletions(-)
diff --git a/arch/arm64/include/asm/arch_gicv3.h
b/arch/arm64/include/asm/arch_gicv3.h
index 25fec4bde43a..a358e97572c1 100644
--- a/arch/arm64/include/asm/arch_gicv3.h
+++ b/arch/arm64/include/asm/arch_gicv3.h
@@ -32,7 +32,7 @@ static inline void gic_write_eoir(u32 irq)
isb();
}
-static inline void gic_write_dir(u32 irq)
+static __always_inline void gic_write_dir(u32 irq)
{
write_sysreg_s(irq, SYS_ICC_DIR_EL1);
isb();
diff --git a/arch/arm64/include/asm/cpufeature.h
b/arch/arm64/include/asm/cpufeature.h
index 92ef9539874a..42ce41eef274 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -581,7 +581,7 @@ static inline bool system_supports_sve(void)
cpus_have_const_cap(ARM64_SVE);
}
-static inline bool system_supports_cnp(void)
+static __always_inline bool system_supports_cnp(void)
{
return IS_ENABLED(CONFIG_ARM64_CNP) &&
cpus_have_const_cap(ARM64_HAS_CNP);
diff --git a/arch/arm64/include/asm/kvm_emulate.h
b/arch/arm64/include/asm/kvm_emulate.h
index 688c63412cc2..f658dda12364 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -36,7 +36,7 @@ void kvm_inject_undef32(struct kvm_vcpu *vcpu);
void kvm_inject_dabt32(struct kvm_vcpu *vcpu, unsigned long addr);
void kvm_inject_pabt32(struct kvm_vcpu *vcpu, unsigned long addr);
-static inline bool vcpu_el1_is_32bit(struct kvm_vcpu *vcpu)
+static __always_inline bool vcpu_el1_is_32bit(struct kvm_vcpu *vcpu)
{
return !(vcpu->arch.hcr_el2 & HCR_RW);
}
@@ -127,7 +127,7 @@ static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu,
u64 vsesr)
vcpu->arch.vsesr_el2 = vsesr;
}
-static inline unsigned long *vcpu_pc(const struct kvm_vcpu *vcpu)
+static __always_inline unsigned long *vcpu_pc(const struct kvm_vcpu *vcpu)
{
return (unsigned long *)_gp_regs(vcpu)->regs.pc;
}
@@ -153,17 +153,17 @@ static inline void vcpu_write_elr_el1(const struct
kvm_vcpu *vcpu, unsigned long
*__vcpu_elr_el1(vcpu) = v;
}
-static inline unsigned long *vcpu_cpsr(const struct kvm_vcpu *vcpu)
+static __always_inline unsigned long *vcpu_cpsr(const struct kvm_vcpu *vcpu)
{
return (unsigned long *)_gp_regs(vcpu)->regs.pstate;
}
-static inline bool vcpu_mode_is_32bit(const struct kvm_vcpu *vcpu)
+static __always_inline bool vcpu_mode_is_32bit(const struct kvm_vcpu *vcpu)
{
return !!(*vcpu_cpsr(vcpu) & PSR_MODE32_BIT);
}
-static inline bool kvm_condition_valid(const struct kvm_vcpu *vcpu)
+static __always_inline bool kvm_condition_valid(const struct kvm_vcpu *vcpu)
{
if (vcpu_mode_is_32bit(vcpu))
return kvm_condition_valid32(vcpu);
@@ -181,13 +181,13 @@ static inline void vcpu_set_thumb(struct kvm_vcpu *vcpu)
* coming from a read of ESR_EL2. Otherwise, it may give the wrong result on
* AArch32 with banked registers.
*/
-static inline unsigned long vcpu_get_reg(const struct kvm_vcpu *vcpu,
+static __always_inline unsigned long vcpu_get_reg(const struct kvm_vcpu *vcpu,
u8 reg_num)
{
return (reg_num == 31) ? 0 : vcpu_gp_regs(vcpu)->regs.regs[reg_num];
}
-static inline void vcpu_set_reg(struct kvm_vcpu *vcpu, u8 reg_num,
+static __always_inline void vcpu_set_reg(struct kvm_vcpu *vcpu, u8 reg_num,
unsigned long val)
{
if (reg_num != 31)
@@ -264,12 +264,12 @@ static inline bool vcpu_mode_priv(const struct kvm_vcpu
*vcpu)
return mode != PSR_MODE_EL0t;
}
-static inline u32 kvm_vcpu_get_hsr(const struct kvm_vcpu *vcpu)
+static __always_inline u32 kvm_vcpu_get_hsr(const struct kvm_vcpu *vcpu)
{
return vcpu->arch.fault.esr_el2;
}
-static inline int kvm_vcpu_get_condition(const struct kvm_vcpu *vcpu)
+static __always_inline int kvm_vcpu_get_condition(const struct kvm_vcpu
[PATCH 0/3] KVM: arm64: Ask the compiler to __always_inline functions used by KVM at HYP
Hello! It turns out KVM relies on the inline hint being honoured by the compiler in quite a few more places than expected. Something about the Shadow Call Stack support[0] causes the compiler to avoid inline-ing and to place these functions outside the __hyp_text. This ruins KVM's day. Add the simon-says __always_inline annotation to all the static inlines that KVM calls from HYP code. This series based on v5.6-rc2. [0] https://lore.kernel.org/linux-arm-kernel/20200219000817.195049-1-samitolva...@google.com/ Thanks, James Morse (3): KVM: arm64: Ask the compiler to __always_inline functions used at HYP KVM: arm64: define our own swab32() to avoid a uapi static inline arm64: Ask the compiler to __always_inline functions used by KVM at HYP arch/arm64/include/asm/arch_gicv3.h | 2 +- arch/arm64/include/asm/cache.h | 2 +- arch/arm64/include/asm/cacheflush.h | 2 +- arch/arm64/include/asm/cpufeature.h | 10 ++--- arch/arm64/include/asm/io.h | 4 +- arch/arm64/include/asm/kvm_emulate.h | 48 arch/arm64/include/asm/kvm_hyp.h | 7 arch/arm64/include/asm/kvm_mmu.h | 3 +- arch/arm64/include/asm/virt.h| 2 +- arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c | 4 +- 10 files changed, 46 insertions(+), 38 deletions(-) -- 2.24.1 ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
On 20/02/2020 2:01 pm, Marc Zyngier wrote: On 2020-02-20 13:32, Robin Murphy wrote: On 20/02/2020 1:15 pm, Marc Zyngier wrote: Hi Marek, On 2020-02-20 12:44, Marek Szyprowski wrote: Hi Marc, On 10.02.2020 15:13, Marc Zyngier wrote: KVM/arm was merged just over 7 years ago, and has lived a very quiet life so far. It mostly works if you're prepared to deal with its limitations, it has been a good prototype for the arm64 version, but it suffers a few problems: - It is incomplete (no debug support, no PMU) - It hasn't followed any of the architectural evolutions - It has zero users (I don't count myself here) - It is more and more getting in the way of new arm64 developments That is a bit sad information. Mainline Exynos finally got everything that was needed to run it on the quite popular Samsung Exynos5422-based Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is being used. We also use it internally at Samsung. Something like "too little, too late" springs to mind, but let's be constructive. Is anyone using it in a production environment, where they rely on the latest mainline kernel having KVM support? The current proposal is to still have KVM support in 5.6, as well as ongoing support for stable kernels. If that's not enough, can you please explain your precise use case? Presumably there's no *technical* reason why the stable subset of v7 support couldn't be stripped down and brought back private to arch/arm if somebody really wants and is willing to step up and look after it? There is no technical reason at all, just a maintenance effort. The main killer is the whole MMU code, which I'm butchering with NV, and that I suspect Will will also turn upside down with his stuff. Not to mention the hypercall interface that will need a complete overhaul. If we wanted to decouple the two, we'd need to make the MMU code, the hypercalls, arm.c and a number of other bits private to 32bit. Right, the prospective kvm-arm maintainer's gameplan would essentially be an equivalent "move virt/kvm/arm to arch/arm/kvm" patch, but then ripping out all the Armv8 and GICv3 gubbins instead. Yes, there would then be lots of *similar* code to start with, but it would only diverge further as v8 architecture development continues independently. Anyway, I just thought it seemed worth saying out loud, to reassure folks that a realistic middle-ground between "yay bye!" and "oh no the end of the world!" does exist, namely "someone else's problem" :) Robin. ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH 2/5] KVM: arm64: Refactor filtering of ID registers
On Sun, 16 Feb 2020 18:53:21 +
Marc Zyngier wrote:
Hi,
> Our current ID register filtering is starting to be a mess of if()
> statements, and isn't going to get any saner.
>
> Let's turn it into a switch(), which has a chance of being more
> readable.
Indeed, much better now.
> Signed-off-by: Marc Zyngier
Reviewed-by: Andre Przywara
Thanks,
Andre
> ---
> arch/arm64/kvm/sys_regs.c | 22 +++---
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index da82c4b03aab..682fedd7700f 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -9,6 +9,7 @@
> * Christoffer Dall
> */
>
> +#include
> #include
> #include
> #include
> @@ -1070,6 +1071,8 @@ static bool access_arch_timer(struct kvm_vcpu *vcpu,
> return true;
> }
>
> +#define FEATURE(x) (GENMASK_ULL(x##_SHIFT + 3, x##_SHIFT))
> +
> /* Read a sanitised cpufeature ID register by sys_reg_desc */
> static u64 read_id_reg(const struct kvm_vcpu *vcpu,
> struct sys_reg_desc const *r, bool raz)
> @@ -1078,13 +1081,18 @@ static u64 read_id_reg(const struct kvm_vcpu *vcpu,
>(u32)r->CRn, (u32)r->CRm, (u32)r->Op2);
> u64 val = raz ? 0 : read_sanitised_ftr_reg(id);
>
> - if (id == SYS_ID_AA64PFR0_EL1 && !vcpu_has_sve(vcpu)) {
> - val &= ~(0xfUL << ID_AA64PFR0_SVE_SHIFT);
> - } else if (id == SYS_ID_AA64ISAR1_EL1 && !vcpu_has_ptrauth(vcpu)) {
> - val &= ~((0xfUL << ID_AA64ISAR1_APA_SHIFT) |
> - (0xfUL << ID_AA64ISAR1_API_SHIFT) |
> - (0xfUL << ID_AA64ISAR1_GPA_SHIFT) |
> - (0xfUL << ID_AA64ISAR1_GPI_SHIFT));
> + switch (id) {
> + case SYS_ID_AA64PFR0_EL1:
> + if (!vcpu_has_sve(vcpu))
> + val &= ~FEATURE(ID_AA64PFR0_SVE);
> + break;
> + case SYS_ID_AA64ISAR1_EL1:
> + if (!vcpu_has_ptrauth(vcpu))
> + val &= ~(FEATURE(ID_AA64ISAR1_APA) |
> + FEATURE(ID_AA64ISAR1_API) |
> + FEATURE(ID_AA64ISAR1_GPA) |
> + FEATURE(ID_AA64ISAR1_GPI));
> + break;
> }
>
> return val;
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
On 2020-02-20 13:32, Robin Murphy wrote: On 20/02/2020 1:15 pm, Marc Zyngier wrote: Hi Marek, On 2020-02-20 12:44, Marek Szyprowski wrote: Hi Marc, On 10.02.2020 15:13, Marc Zyngier wrote: KVM/arm was merged just over 7 years ago, and has lived a very quiet life so far. It mostly works if you're prepared to deal with its limitations, it has been a good prototype for the arm64 version, but it suffers a few problems: - It is incomplete (no debug support, no PMU) - It hasn't followed any of the architectural evolutions - It has zero users (I don't count myself here) - It is more and more getting in the way of new arm64 developments That is a bit sad information. Mainline Exynos finally got everything that was needed to run it on the quite popular Samsung Exynos5422-based Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is being used. We also use it internally at Samsung. Something like "too little, too late" springs to mind, but let's be constructive. Is anyone using it in a production environment, where they rely on the latest mainline kernel having KVM support? The current proposal is to still have KVM support in 5.6, as well as ongoing support for stable kernels. If that's not enough, can you please explain your precise use case? Presumably there's no *technical* reason why the stable subset of v7 support couldn't be stripped down and brought back private to arch/arm if somebody really wants and is willing to step up and look after it? There is no technical reason at all, just a maintenance effort. The main killer is the whole MMU code, which I'm butchering with NV, and that I suspect Will will also turn upside down with his stuff. Not to mention the hypercall interface that will need a complete overhaul. If we wanted to decouple the two, we'd need to make the MMU code, the hypercalls, arm.c and a number of other bits private to 32bit. M. -- Jazz is not dead. It just smells funny... ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
On 20/02/2020 1:15 pm, Marc Zyngier wrote: Hi Marek, On 2020-02-20 12:44, Marek Szyprowski wrote: Hi Marc, On 10.02.2020 15:13, Marc Zyngier wrote: KVM/arm was merged just over 7 years ago, and has lived a very quiet life so far. It mostly works if you're prepared to deal with its limitations, it has been a good prototype for the arm64 version, but it suffers a few problems: - It is incomplete (no debug support, no PMU) - It hasn't followed any of the architectural evolutions - It has zero users (I don't count myself here) - It is more and more getting in the way of new arm64 developments That is a bit sad information. Mainline Exynos finally got everything that was needed to run it on the quite popular Samsung Exynos5422-based Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is being used. We also use it internally at Samsung. Something like "too little, too late" springs to mind, but let's be constructive. Is anyone using it in a production environment, where they rely on the latest mainline kernel having KVM support? The current proposal is to still have KVM support in 5.6, as well as ongoing support for stable kernels. If that's not enough, can you please explain your precise use case? Presumably there's no *technical* reason why the stable subset of v7 support couldn't be stripped down and brought back private to arch/arm if somebody really wants and is willing to step up and look after it? Robin. ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
On 20/02/20 14:15, Marc Zyngier wrote: >> That is a bit sad information. Mainline Exynos finally got everything >> that was needed to run it on the quite popular Samsung Exynos5422-based >> Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is >> being used. We also use it internally at Samsung. > > Something like "too little, too late" springs to mind, but let's be > constructive. Is anyone using it in a production environment, where > they rely on the latest mainline kernel having KVM support? Depends if you consider "production environment" somebody playing at home with a SBC. But it's true that, these days, most of those that support EL2 do support ARM64, even if they are used with a 32-bit userland. Paolo ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
Hi Marek, On 2020-02-20 12:44, Marek Szyprowski wrote: Hi Marc, On 10.02.2020 15:13, Marc Zyngier wrote: KVM/arm was merged just over 7 years ago, and has lived a very quiet life so far. It mostly works if you're prepared to deal with its limitations, it has been a good prototype for the arm64 version, but it suffers a few problems: - It is incomplete (no debug support, no PMU) - It hasn't followed any of the architectural evolutions - It has zero users (I don't count myself here) - It is more and more getting in the way of new arm64 developments That is a bit sad information. Mainline Exynos finally got everything that was needed to run it on the quite popular Samsung Exynos5422-based Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is being used. We also use it internally at Samsung. Something like "too little, too late" springs to mind, but let's be constructive. Is anyone using it in a production environment, where they rely on the latest mainline kernel having KVM support? The current proposal is to still have KVM support in 5.6, as well as ongoing support for stable kernels. If that's not enough, can you please explain your precise use case? M. -- Jazz is not dead. It just smells funny... ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
Hi Marc, On 10.02.2020 15:13, Marc Zyngier wrote: > KVM/arm was merged just over 7 years ago, and has lived a very quiet > life so far. It mostly works if you're prepared to deal with its > limitations, it has been a good prototype for the arm64 version, > but it suffers a few problems: > > - It is incomplete (no debug support, no PMU) > - It hasn't followed any of the architectural evolutions > - It has zero users (I don't count myself here) > - It is more and more getting in the way of new arm64 developments That is a bit sad information. Mainline Exynos finally got everything that was needed to run it on the quite popular Samsung Exynos5422-based Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is being used. We also use it internally at Samsung. > So here it is: unless someone screams and shows that they rely on > KVM/arm to be maintained upsteam, I'll remove 32bit host support > form the tree. One of the reasons that makes me confident nobody is > using it is that I never receive *any* bug report. Yes, it is perfect. > But if you depend on KVM/arm being available in mainline, please shout. > > To reiterate: 32bit guest support for arm64 stays, of course. Only > 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to > arm64, and cleanup all the now unnecessary abstractions. > > The patches have been generated with the -D option to avoid spamming > everyone with huge diffs, and there is a kvm-arm/goodbye branch in > my kernel.org repository. > > Marc Zyngier (5): >arm: Unplug KVM from the build system >arm: Remove KVM from config files >arm: Remove 32bit KVM host support >arm: Remove HYP/Stage-2 page-table support >arm: Remove GICv3 vgic compatibility macros > > Documentation/virt/kvm/arm/hyp-abi.txt |5 + > arch/arm/Kconfig |2 - > arch/arm/Makefile |1 - > arch/arm/configs/axm55xx_defconfig |2 - > arch/arm/include/asm/arch_gicv3.h | 114 -- > arch/arm/include/asm/kvm_arm.h | 239 > arch/arm/include/asm/kvm_asm.h | 77 -- > arch/arm/include/asm/kvm_coproc.h | 36 - > arch/arm/include/asm/kvm_emulate.h | 372 -- > arch/arm/include/asm/kvm_host.h| 459 > arch/arm/include/asm/kvm_hyp.h | 127 --- > arch/arm/include/asm/kvm_mmu.h | 435 --- > arch/arm/include/asm/kvm_ras.h | 14 - > arch/arm/include/asm/pgtable-3level.h | 20 - > arch/arm/include/asm/pgtable.h |9 - > arch/arm/include/asm/sections.h|6 +- > arch/arm/include/asm/stage2_pgtable.h | 75 -- > arch/arm/include/asm/virt.h| 12 - > arch/arm/include/uapi/asm/kvm.h| 314 - > arch/arm/kernel/asm-offsets.c | 11 - > arch/arm/kernel/vmlinux-xip.lds.S |8 - > arch/arm/kernel/vmlinux.lds.S |8 - > arch/arm/kernel/vmlinux.lds.h | 10 - > arch/arm/kvm/Kconfig | 59 - > arch/arm/kvm/Makefile | 43 - > arch/arm/kvm/coproc.c | 1455 > arch/arm/kvm/coproc.h | 130 --- > arch/arm/kvm/coproc_a15.c | 39 - > arch/arm/kvm/coproc_a7.c | 42 - > arch/arm/kvm/emulate.c | 166 --- > arch/arm/kvm/guest.c | 387 --- > arch/arm/kvm/handle_exit.c | 175 --- > arch/arm/kvm/hyp/Makefile | 34 - > arch/arm/kvm/hyp/banked-sr.c | 70 -- > arch/arm/kvm/hyp/cp15-sr.c | 72 -- > arch/arm/kvm/hyp/entry.S | 121 -- > arch/arm/kvm/hyp/hyp-entry.S | 295 - > arch/arm/kvm/hyp/s2-setup.c| 22 - > arch/arm/kvm/hyp/switch.c | 242 > arch/arm/kvm/hyp/tlb.c | 68 -- > arch/arm/kvm/hyp/vfp.S | 57 - > arch/arm/kvm/init.S| 157 --- > arch/arm/kvm/interrupts.S | 36 - > arch/arm/kvm/irq.h | 16 - > arch/arm/kvm/reset.c | 86 -- > arch/arm/kvm/trace.h | 86 -- > arch/arm/kvm/vgic-v3-coproc.c | 27 - > arch/arm/mach-exynos/Kconfig |2 +- > arch/arm/mm/mmu.c | 26 - > 49 files changed, 7 insertions(+), 6262 deletions(-) > delete mode 100644 arch/arm/include/asm/kvm_arm.h > delete mode 100644 arch/arm/include/asm/kvm_asm.h > delete mode 100644 arch/arm/include/asm/kvm_coproc.h > delete mode 100644 arch/arm/include/asm/kvm_emulate.h > delete mode 100644 arch/arm/include/asm/kvm_host.h > delete mode 100644 arch/arm/include/asm/kvm_hyp.h > delete mode 100644 arch/arm/include/asm/kvm_mmu.h > delete mode 100644 arch/arm/include/asm/kvm_ras.h > delete mode 100644 arch/arm/include/asm/stage2_pgtable.h > delete mode 100644 arch/arm/include/uapi/asm/kvm.h >
Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
On 2020-02-19 13:53, Stefan Agner wrote: On 2020-02-10 15:13, Marc Zyngier wrote: KVM/arm was merged just over 7 years ago, and has lived a very quiet life so far. It mostly works if you're prepared to deal with its limitations, it has been a good prototype for the arm64 version, but it suffers a few problems: - It is incomplete (no debug support, no PMU) - It hasn't followed any of the architectural evolutions - It has zero users (I don't count myself here) - It is more and more getting in the way of new arm64 developments So here it is: unless someone screams and shows that they rely on KVM/arm to be maintained upsteam, I'll remove 32bit host support form the tree. One of the reasons that makes me confident nobody is using it is that I never receive *any* bug report. Yes, it is perfect. Not entirely true: https://lore.kernel.org/m/e2f7196ca6c70c55463a45b490f67...@agner.ch And I thank you for that. This bug was actually hitting both arm and arm64, and triggered by a bogus DT (that KVM should have handled in a nicer way). What I was trying to say is that nobody reports bugs that are specific to 32bit KVM/arm. But, after that was fixed, it actually was perfect :-D https://blog.printk.io/2016/09/kvm-with-kvmtool-on-armv7/ Hey, neat! not sure how useful, but neat nonetheless... ;-) That said, I never used it in a real-world application, so from my side removing it is fine. Thanks, M. -- Jazz is not dead. It just smells funny... ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
On 2020-02-19 15:46, Jan Kiszka wrote: On 19.02.20 16:09, Arnd Bergmann wrote: On Mon, Feb 10, 2020 at 3:13 PM Marc Zyngier wrote: KVM/arm was merged just over 7 years ago, and has lived a very quiet life so far. It mostly works if you're prepared to deal with its limitations, it has been a good prototype for the arm64 version, but it suffers a few problems: - It is incomplete (no debug support, no PMU) - It hasn't followed any of the architectural evolutions - It has zero users (I don't count myself here) - It is more and more getting in the way of new arm64 developments So here it is: unless someone screams and shows that they rely on KVM/arm to be maintained upsteam, I'll remove 32bit host support form the tree. One of the reasons that makes me confident nobody is using it is that I never receive *any* bug report. Yes, it is perfect. But if you depend on KVM/arm being available in mainline, please shout. To reiterate: 32bit guest support for arm64 stays, of course. Only 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to arm64, and cleanup all the now unnecessary abstractions. The patches have been generated with the -D option to avoid spamming everyone with huge diffs, and there is a kvm-arm/goodbye branch in my kernel.org repository. Just one more thought before it's gone: is there any shared code (header files?) that is used by the jailhouse hypervisor? If there is, are there any plans to merge that into the mainline kernel for arm32 in the near future? I'm guessing the answer to at least one of those questions is 'no', so we don't need to worry about it, but it seems better to ask. Good that you mention it: There is one thing we share on ARM (and ARM64), and that is the hypervisor enabling stub, to install our own vectors. If that was to be removed as well, we would have to patch it back downstream. So far, we only carry few EXPORT_SYMBOL patches for essential enabling. I actually have a few extra patches on top of the series, one of them actually removing the ability to register new vectors (mostly because I don't like leaving unused stuff behind), see [1]. I'll post an update so that we can discuss whether we want this particular to stay or not. That said, I was also starting to think about how long we will continue to support Jailhouse on 32-bit ARM. We currently have no supported SoC there that comes with an SMMU, and I doubt to see one still showing up. So, Jailhouse on ARM is really just a testing/demo case, maybe useful (but I didn't get concrete feedback) for cleaner collaborative AMP for real-time purposes, without security concerns. I assume 32-bit ARM will never be part of what would be proposed of Jailhouse for upstream. I guess we all come to the same conclusion... M. [1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=kvm-arm/goodbye=0943dd119105b65197adffda52c402cce28da56d -- Jazz is not dead. It just smells funny... ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH kvmtool v2] Add emulation for CFI compatible flash memory
Hi, On 2/19/20 5:26 PM, Andre Przywara wrote: > On Mon, 17 Feb 2020 17:20:43 + > Alexandru Elisei wrote: > > Hi, > >> I guess the device hasn't been tested with Linux. This is what I'm getting >> when >> trying to boot a Linux guest using the command: > It was actually developed with a Linux guest, because that's more verbatim > and easier to debug. > > And I just tested this again with Linux and it worked for me: The flash image you provided is 2 MB. The flash image that I used is 10 MB (it shows in the log that I sent). I guess you ran a different test. > [2.164992] physmap-flash 2.flash: physmap platform flash device: [mem > 0x0002-0x0021] > [2.166539] 2.flash: Found 2 x16 devices at 0x0 in 32-bit bank. > Manufacturer ID 0x00 Chip ID 0x00 > ... > # mtd_debug info /dev/mtd0 > mtd.type = MTD_NORFLASH > mtd.flags = MTD_CAP_NORFLASH > mtd.size = 2097152 (2M) > mtd.erasesize = 65536 (64K) > mtd.writesize = 1 > mtd.oobsize = 0 > regions = 1 > > I think what you are seeing are problems when you give a non-power-of-2 sized > flash image. The current patch does not really support this (since it's > hardly a thing in the real world). I originally wanted to expand any "uneven" > size to the next power-of-2, but this doesn't work easily with mmap. I would expect that if kvmtool allows the user to specify a non-power-of-2 flash image size, then it should know how to deal with it and not present a broken device to a linux guest if that size is forbidden by the spec. Or it is allowed by the specification and kvmtool doesn't know how to deal with it? Instead of expanding the file provided by the user to fit a bigger flash, how about you use the highest power of two size that is smaller than the flash size? > So I now changed the code to downgrade, so you get 8MB with any file ranging > from [8MB, 16MB(, for instance. > That fixed the Linux problems with those files for me. > >> $ ./lkvm run -c4 -m4096 -k /path/to/kernel -d /path/to/disk -p >> root="/dev/vda2" -F >> flash.img >> >> [ 0.659167] physmap-flash 200.flash: physmap platform flash device: >> [mem >> 0x0200-0x029f] >> [ 0.660444] Number of erase regions: 1 >> [ 0.661036] Primary Vendor Command Set: 0001 (Intel/Sharp Extended) >> [ 0.661688] Primary Algorithm Table at 0031 >> [ 0.662168] Alternative Vendor Command Set: (None) >> [ 0.662711] No Alternate Algorithm Table >> [ 0.663120] Vcc Minimum: 4.5 V >> [ 0.663450] Vcc Maximum: 5.5 V >> [ 0.663779] No Vpp line >> [ 0.664039] Typical byte/word write timeout: 2 µs >> [ 0.664590] Maximum byte/word write timeout: 2 µs >> [ 0.665240] Typical full buffer write timeout: 2 µs >> [ 0.665775] Maximum full buffer write timeout: 2 µs >> [ 0.666373] Typical block erase timeout: 2 ms >> [ 0.666828] Maximum block erase timeout: 2 ms >> [ 0.667282] Chip erase not supported >> [ 0.667659] Device size: 0x80 bytes (8 MiB) >> [ 0.668137] Flash Device Interface description: 0x0006 >> [ 0.668697] - Unknown >> [ 0.668963] Max. bytes in buffer write: 0x40 >> [ 0.669407] Number of Erase Block Regions: 1 >> [ 0.669865] Erase Region #0: BlockSize 0x8000 bytes, 160 blocks >> [ 0.672299] 200.flash: Found 2 x16 devices at 0x0 in 32-bit bank. >> Manufacturer ID 0x00 Chip ID 0x00 >> [ 0.681328] NOR chip too large to fit in mapping. Attempting to cope... >> [ 0.682046] Intel/Sharp Extended Query Table at 0x0031 >> [ 0.682645] Using buffer write method >> [ 0.683031] Sum of regions (a0) != total size of set of interleaved >> chips >> (100) >> [ 0.683854] gen_probe: No supported Vendor Command Set found >> [ 0.684441] physmap-flash 200.flash: map_probe failed >> >> I also defined DEBUG_CFI in drivers/mtd/chips/cfi_probe.c. >> >> The Flash Device Interface description that we provide is wrong, it should >> 0x05. >> More details below. >> >> On 2/7/20 12:19 PM, Andre Przywara wrote: >>> From: Raphael Gault >>> >>> The EDK II UEFI firmware implementation requires some storage for the EFI >>> variables, which is typically some flash storage. >>> Since this is already supported on the EDK II side, we add a CFI flash >>> emulation to kvmtool. >>> This is backed by a file, specified via the --flash or -F command line >>> option. Any flash writes done by the guest will immediately be reflected >>> into this file (kvmtool mmap's the file). >>> >>> This implements a CFI flash using the "Intel/Sharp extended command >>> set", as specified in: >>> - JEDEC JESD68.01 >>> - JEDEC JEP137B >>> - Intel Application Note 646 >>> Some gaps in those specs have been filled by looking at real devices and >>> other implementations (QEMU, Linux kernel driver). >>> >>> At the moment this relies on DT to advertise the base address of the >>> flash memory (mapped into the MMIO address space) and is only enabled >>> for ARM/ARM64. The emulation itself is architecture agnostic,
