[PATCH] xen/riscv: fix build issue for bullseye-riscv64 container
Address compilation error on bullseye-riscv64 container:
undefined reference to `guest_physmap_remove_page`
Since there is no current implementation of `guest_physmap_remove_page()`,
a stub function has been added.
Signed-off-by: Oleksii Kurochko
Reported-by: Andrew Cooper
---
xen/arch/riscv/stubs.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
index b67d99729f..3285d18899 100644
--- a/xen/arch/riscv/stubs.c
+++ b/xen/arch/riscv/stubs.c
@@ -381,6 +381,12 @@ int arch_get_paging_mempool_size(struct domain *d,
uint64_t *size)
BUG_ON("unimplemented");
}
+int guest_physmap_remove_page(struct domain *d, gfn_t gfn, mfn_t mfn,
+ unsigned int page_order)
+{
+BUG_ON("unimplemented");
+}
+
/* delay.c */
void udelay(unsigned long usecs)
--
2.45.2
Xen Project Releases Version 4.19
Hello everyone, It's with great pleasure that I announce our 4.19 PR release. I want to thank the whole community for their efforts in getting this release published! *Please find the PR article attached here <https://www.linuxfoundation.org/press/xen-project-announces-performance-and-security-advancements-with-release-of-4.19?utm_content=302230092_medium=social_source=twitter_channel=tw-14706299 >* Please find the tarball and its signature at: https://downloads.xenproject.org/release/xen/4.19.0/ You can also check out the tag in xen.git: git://xenbits.xen.org/xen.git RELEASE-4.19.0 Git checkout and build instructions can be found at: https://wiki.xenproject.org/wiki/Xen_Project_4.19_Release_Notes#Build_Requirements Release notes can be found at: https://wiki.xenproject.org/wiki/Xen_Project_4.19_Release_Notes A summary for 4.19 release documents can be found at: https://wiki.xenproject.org/wiki/Category:Xen_4.19 *Some notable features:* - *Security Enhancements:* - Published 13 new Xen Security Advisories (XSAs) to mitigate vulnerabilities. - Adoption of additional MISRA-C rules for improved code quality. - *Arm* - Introduction of dynamic node programming using overlay dtbo. - FF-A notification support - *x86 Architecture:* - Introduce a new x2APIC driver that uses Cluster Logical addressing mode for IPIs and physical addressing mode for external interrupts. - Deprecate support for XeonPhi in 4.19, with the firm plan to remove support in 4.20. *PVH:* - PVH dom0 has now moved to "supported with caveats" status - PVH/HVM can now map foreign pages, which should for example allow QEMU stubdomains to run as PVH - Boot time speedup due to the IOMMU changes - Don't expose pIRQ support to HVM guests by default. The feature (XENFEAT_hvm_pirqs) can now be enabled on a per-domain basis *Other updates:* - Add a new 9pfs backend running as a daemon in dom0. First user is Xenstore-stubdom now being able to support full Xenstore trace capability. - libxl support for backendtype=tap with tapback. - Increase the maximum number of CPUs Xen can be built for from 4095 to 16383. - When building with Systemd support (./configure --enable- systemd), remove libsystemd as a build dependency. Systemd Notify support is retained, now using a standalone library implementation. - xenalyze no longer requires `--svm-mode` when analyzing traces generated on AMD CPUs. - Code symbol annotations and MISRA compliance improvements. *CI updates:* - Minimum fixes to rebuild the containers, following the HEREDOC problems. - Rebuild containers to have testing with up-to-date LTS distros. - Few build system checks, and strip the obsolete contents of the build containers. Aside from the updates mentioned, I would also like to note that we are still actively working on the PPC and RISC-V ports. Best regards, Oleksii Come join the conversation on Matrix: XenProject: https://matrix.to/#/#XenProject:matrix.org XenDevel: https://matrix.to/#/#XenDevel:matrix.org XenSocial: https://matrix.to/#/#XenSocial:matrix.org
Re: [PATCH v3 5/9] xen/riscv: introduce asm/pmap.h header
On Tue, 2024-07-30 at 14:15 +0200, Jan Beulich wrote:
> On 30.07.2024 13:39, oleksii.kuroc...@gmail.com wrote:
> > On Tue, 2024-07-30 at 09:56 +0200, Jan Beulich wrote:
> > > On 29.07.2024 18:22, oleksii.kuroc...@gmail.com wrote:
> > > > On Mon, 2024-07-29 at 16:29 +0200, Jan Beulich wrote:
> > > > > On 24.07.2024 17:31, Oleksii Kurochko wrote:
> > > > > > --- /dev/null
> > > > > > +++ b/xen/arch/riscv/include/asm/pmap.h
> > > > > > @@ -0,0 +1,33 @@
> > > > > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > > > > +#ifndef ASM_PMAP_H
> > > > > > +#define ASM_PMAP_H
> > > > > > +
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +
> > > > > > +static inline void arch_pmap_map(unsigned int slot, mfn_t
> > > > > > mfn)
> > > > > > +{
> > > > > > + pte_t *entry = _fixmap[slot];
> > > > > > + pte_t pte;
> > > > > > +
> > > > > > + ASSERT(!pte_is_valid(*entry));
> > > > > > +
> > > > > > + pte = mfn_to_xen_entry(mfn, PAGE_HYPERVISOR_RW);
> > > > > > + write_pte(entry, pte);
> > > > > > +}
> > > > >
> > > > > Perhaps add a comment to clarify why it's safe to omit a TLB
> > > > > flush
> > > > > here.
> > > > > Note that arch_pmap_unmap() having one is a necessary but not
> > > > > sufficient
> > > > > condition to that. In principle hardware may also cache
> > > > > "negative"
> > > > > TLB
> > > > > entries; I have no idea how RISC-V behaves in this regard, or
> > > > > whether
> > > > > that aspect is actually left to implementations.
> > > > what do you mean by "negative" TLB? an old TLB entry which
> > > > should
> > > > be
> > > > invalidated?
> > >
> > > No, I mean TLB entries saying "no valid translation here". I.e.
> > > avoiding
> > > recurring walks of something that was once found to have no
> > > translation.
> > But we can't modify an existent entry because we have
> > "ASSERT(!pte_is_valid(*entry))" in pmap_map() function and we are
> > doing
> > TLB flush during pmap_unmap().
>
> You _always_ modify an existing entry. That may be a not-present one,
> but
> that's still an entry. And that's part of why I think you still
> didn't
> understand what I said. A particular implementation, if permitted by
> the
> spec, may very well put in place a TLB entry when the result of a
> page
> walk was a non-present entry. So ...
>
> > So when we will be in pmap_map() we are
> > sure that there is no TLB entry for the new pte.
>
> ..., can you point me at the part of the spec saying that such
> "negative"
> TLB entries are not permitted?
I double-checked the spec and it seems to me you are right and it could
be an issue. Absense of "negative" TLB entrues will be guaranted only
in the case when Svvptc extension is present (
https://github.com/riscv/riscv-svvptc/blob/main/svvptc.adoc?plain=1#L85
):
Depending on the microarchitecture, some possible ways to facilitate
implementation of Svvptc include: not having any address-translation
caches, not
storing Invalid PTEs in the address-translation caches, automatically
evicting
Invalid PTEs using a bounded timer, or making address-translation
caches
coherent with store instructions that modify PTEs.
If the mentioned above extension isn't present. Also there is the
following words in the spec
(
https://github.com/riscv/riscv-isa-manual/blob/main/src/supervisor.adoc?plain=1#L1213
):
For the special cases of increasing the permissions on a leaf PTE and
changing an invalid
PTE to a valid leaf, software may choose to execute the SFENCE.VMA
lazily. After
modifying the PTE but before executing SFENCE.VMA, either the new or
old permissions
will be used. In the latter case, a page-fault exception might occur,
at which point software
should execute SFENCE.VMA in accordance with the previous bullet point.
Probably in the future we will need also similar to work Linux kernel
does:
https://patchwork.kernel.org/project/linux-mips/cover/20240131155929.169961-1-alexgh...@rivosinc.com/
So I'll add flush_xen_tlb_range_va_local(FIXMAP_ADDR(slot), PAGE_SIZE)
in arch_pmap_map.
~ Oleksii
Re: [PATCH v3 4/9] xen/riscv: setup fixmap mapping
On Tue, 2024-07-30 at 14:11 +0200, Jan Beulich wrote:
> On 30.07.2024 13:25, oleksii.kuroc...@gmail.com wrote:
> > On Tue, 2024-07-30 at 09:49 +0200, Jan Beulich wrote:
> > > On 29.07.2024 18:11, oleksii.kuroc...@gmail.com wrote:
> > > > On Mon, 2024-07-29 at 15:35 +0200, Jan Beulich wrote:
> > > > > On 24.07.2024 17:31, Oleksii Kurochko wrote:
> > > > > > @@ -81,6 +82,14 @@ static inline void
> > > > > > flush_page_to_ram(unsigned
> > > > > > long mfn, bool sync_icache)
> > > > > > BUG_ON("unimplemented");
> > > > > > }
> > > > > >
> > > > > > +/* Write a pagetable entry. */
> > > > > > +static inline void write_pte(pte_t *p, pte_t pte)
> > > > > > +{
> > > > > > + RISCV_FENCE(rw, rw);
> > > > > > + *p = pte;
> > > > > > + RISCV_FENCE(rw, rw);
> > > > > > +}
> > > > >
> > > > > Why the first of the two fences?
> > > > To ensure that writes have completed with the old mapping.
> > >
> > > Wait: There can certainly be uncompleted writes, but those must
> > > have
> > > walked the page tables already, or else a (synchronous) fault
> > > could
> > > not be delivered on the originating store instruction. Or am I
> > > misunderstanding how paging (and associated faults) work on RISC-
> > > V?
> > I am not sure that I correctly understand the part regarding (
> > synchronous ) fault. Could you please come up with an example?
> >
> > If something during page table walk will go wrong then a fault will
> > be
> > raised.
>
> On the very insn, with subsequent insns not having started executing
> (from an architectural perspective, i.e. leaving aside speculation).
> That is what my use of "synchronous" meant.
>
> > My initial intension was to be sure if I will be writing to an
> > actively
> > in-use page table that other cores can see at the time then fences
> > above are required. It is not the case for now as we have only one
> > CPUs
> > but I assume that it will be a case when SMP will be enabled and
> > more
> > then one CPU will be able to work with the same page table.
>
> Would that first fence really help there? The other CPU could use
> the page tables in the window between the fence and the write. My
> understanding of the need for fences is for them to be used at times
> where ordering of memory accesses matters. For the moment I don't
> see this as an aspect for the 1st fence here, but I may be
> overlooking something.
AFAIU there are cases when we need the first fence, i.e. when superpage
breakup is happening and IIUC in this case we would first do a fence (
assuming pages are already allocated ), one fence between each
superpage breakup and its PTE, and one after each regular PTE write.
But in this case the first fence could be outside write_pte() function.
So we could eliminate the first fence in write_pte() and place it
outside the function ( if it will be needed for some cases ), thus
eliminating double fences.
~ Oleksii
Re: [PATCH] x86: drop Xeon Phi support
On Tue, 2024-07-30 at 13:07 +0200, Jan Beulich wrote:
> Do as was decided in Lisbon. Reportedly Xen hasn't been working very
> well on those processors anyway.
>
> Signed-off-by: Jan Beulich
> ---
> One file I left untouched is the test harness'es predicates.c: Those
> tests are imo fine to retain. Plus of course the dependencies in
> gen-cpuid.py also want leaving in place imo (unless we were to remove
> the respective 4 lines from the public header).
>
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -11,6 +11,8 @@ The format is based on [Keep a Changelog
> ### Added
>
> ### Removed
> + - On x86:
> + - Support for running on Xeon Phi processors.
Acked-By: Oleksii Kurochko
~ Oleksii
>
> ##
> [4.19.0](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;
> h=RELEASE-4.19.0) - 2024-07-29
>
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -30,6 +30,7 @@ if the related features are marked as su
> ### x86-64
>
> Status: Supported
> + Status, Xeon Phi: Not supported.
>
> ### ARM v7 + Virtualization Extensions
>
> --- a/tools/tests/x86_emulator/Makefile
> +++ b/tools/tests/x86_emulator/Makefile
> @@ -16,7 +16,7 @@ vpath %.c $(XEN_ROOT)/xen/lib/x86
>
> CFLAGS += $(CFLAGS_xeninclude)
>
> -SIMD := 3dnow sse sse2 sse4 avx avx2 xop avx512f avx512bw avx512dq
> avx512er avx512vbmi avx512fp16
> +SIMD := 3dnow sse sse2 sse4 avx avx2 xop avx512f avx512bw avx512dq
> avx512vbmi avx512fp16
> FMA := fma4 fma
> SG := avx2-sg avx512f-sg
> AES := ssse3-aes avx-aes avx2-vaes avx512bw-vaes
> @@ -80,9 +80,6 @@ avx512bw-flts :=
> avx512dq-vecs := $(avx512f-vecs)
> avx512dq-ints := $(avx512f-ints)
> avx512dq-flts := $(avx512f-flts)
> -avx512er-vecs := 64
> -avx512er-ints :=
> -avx512er-flts := 4 8
> avx512vbmi-vecs := $(avx512bw-vecs)
> avx512vbmi-ints := $(avx512bw-ints)
> avx512vbmi-flts := $(avx512bw-flts)
> --- a/tools/tests/x86_emulator/evex-disp8.c
> +++ b/tools/tests/x86_emulator/evex-disp8.c
> @@ -524,37 +524,6 @@ static const struct test avx512dq_512[]
> INSN(inserti32x8, 66, 0f3a, 3a, el_8, d, vl),
> };
>
> -static const struct test avx512er_512[] = {
> - INSN(exp2, 66, 0f38, c8, vl, sd, vl),
> - INSN(rcp28, 66, 0f38, ca, vl, sd, vl),
> - INSN(rcp28, 66, 0f38, cb, el, sd, el),
> - INSN(rsqrt28, 66, 0f38, cc, vl, sd, vl),
> - INSN(rsqrt28, 66, 0f38, cd, el, sd, el),
> -};
> -
> -static const struct test avx512pf_512[] = {
> - INSNX(gatherpf0d, 66, 0f38, c6, 1, vl, sd, el),
> - INSNX(gatherpf0q, 66, 0f38, c7, 1, vl, sd, el),
> - INSNX(gatherpf1d, 66, 0f38, c6, 2, vl, sd, el),
> - INSNX(gatherpf1q, 66, 0f38, c7, 2, vl, sd, el),
> - INSNX(scatterpf0d, 66, 0f38, c6, 5, vl, sd, el),
> - INSNX(scatterpf0q, 66, 0f38, c7, 5, vl, sd, el),
> - INSNX(scatterpf1d, 66, 0f38, c6, 6, vl, sd, el),
> - INSNX(scatterpf1q, 66, 0f38, c7, 6, vl, sd, el),
> -};
> -
> -static const struct test avx512_4fmaps_512[] = {
> - INSN(4fmaddps, f2, 0f38, 9a, el_4, d, vl),
> - INSN(4fmaddss, f2, 0f38, 9b, el_4, d, vl),
> - INSN(4fnmaddps, f2, 0f38, aa, el_4, d, vl),
> - INSN(4fnmaddss, f2, 0f38, ab, el_4, d, vl),
> -};
> -
> -static const struct test avx512_4vnniw_512[] = {
> - INSN(p4dpwssd, f2, 0f38, 52, el_4, d, vl),
> - INSN(p4dpwssds, f2, 0f38, 53, el_4, d, vl),
> -};
> -
> static const struct test avx512_bf16_all[] = {
> INSN(cvtne2ps2bf16, f2, 0f38, 72, vl, d, vl),
> INSN(cvtneps2bf16, f3, 0f38, 72, vl, d, vl),
> @@ -1110,11 +1079,6 @@ void evex_disp8_test(void *instr, struct
> RUN(avx512dq, 128);
> RUN(avx512dq, no128);
> RUN(avx512dq, 512);
> - RUN(avx512er, 512);
> -#define cpu_has_avx512pf cpu_has_avx512f
> - RUN(avx512pf, 512);
> - RUN(avx512_4fmaps, 512);
> - RUN(avx512_4vnniw, 512);
> RUN(avx512_bf16, all);
> RUN(avx512_bitalg, all);
> RUN(avx512_ifma, all);
> --- a/tools/tests/x86_emulator/test_x86_emulator.c
> +++ b/tools/tests/x86_emulator/test_x86_emulator.c
> @@ -39,7 +39,6 @@ asm ( ".pushsection .test, \"ax\", @prog
> #include "avx512bw-vpclmulqdq.h"
> #include "avx512bw-gf.h"
> #include "avx512dq.h"
> -#include "avx512er.h"
> #include "avx512vbmi.h"
> #include "avx512vbmi2-vpclmulqdq.h"
> #include "avx512fp16.h"
> @@ -147,11 +146,6 @@ static bool simd_check_avx512dq_vl(void)
> return cpu_has_avx512dq && cpu_has_avx512vl;
> }
>
> -static bool simd_check_avx512er(void)
> -{
> - return cpu_has_avx512er;
> -}
> -
> static bool simd_check_avx512bw(void)
> {
>
Re: [PATCH v3 7/9] xen/riscv: introduce and init SBI RFENCE extension
On Tue, 2024-07-30 at 11:17 +0200, Jan Beulich wrote: > On 30.07.2024 10:44, oleksii.kuroc...@gmail.com wrote: > > On Mon, 2024-07-29 at 17:52 +0200, Jan Beulich wrote: > > > On 24.07.2024 17:31, Oleksii Kurochko wrote: > > > > > > > > > > +/* > > > > + * Send SFENCE_VMA to a set of target HARTs. > > > > + * > > > > + * @param hart_mask mask representing set of target HARTs > > > > + * @param start virtual address start > > > > + * @param size virtual address size > > > > > > Are these really virtual addresses, not somehow a bias and a > > > number > > > of bits (CPUs) or elements? From the rest of the patch I can't > > > deduce > > > what these two parameters express. > > According to SBI doc start is an virtual address: > > https://github.com/riscv-non-isa/riscv-sbi-doc/blob/master/src/ext-rfence.adoc?plain=1#L44 > > Oh, so these are describing the VA range to be flushed. Okay. > > > and hart_mask is: > > • unsigned long hart_mask is a scalar bit-vector containing hartids > > Biased by hart_mask_base in the actual SBI call. What word "biased" mean here? > > > > > + > > > > +static void sbi_cpumask_to_hartmask(const struct cpumask > > > > *cmask, > > > > + struct cpumask *hmask) > > > > > > I doubt it is valud to re-use struct cpumask for hart maps. > > Why not? Would it be better to use unsigned long *hmask? > > It's not only better, but imo a requirement. Unless there's a > guarantee > by the spec that hart IDs for any subset of harts are sequential and > starting from 0, you just can't assume they fall in the [0,NR_CPUS) > or > really [0,nr_cpu_ids) range. Yet without that you simply can't > (ab)use > struct cpumask (and btw it wants to be cpumask_t everywhere). It is guarantee that hart ID 0 will be present but not that they are numbered contiguously: ``` Hart IDs might not necessarily be numbered contiguously in a multiprocessor system, but at least one hart must have a hart ID of zero. Hart IDs must be unique within the execution environment. ``` I have to rework then this things around sbi_cpumask_to_hartmask(). > > You may want to take a look at struct physid_mask that we have on x86 > for the equivalent purpose. Thanks I will look at. > > > > + continue; > > > > > > > > > Can you really sensibly continue in such a case? > > I think yes, the worst thing we will have is that the "bad" CPU > > won't > > be used. > > But it might be better to switch to BUG_ON() as if we are inised > > the > > "if CONFIG_NR_CPUS <= cpu" then it could tell us that something > > went > > wrong. > > Again - your problem here isn't the range of "cpu". What you instead > want to check is ... > > > > > + } > > > > + > > > > + hart = > > > > cpuid_to_hartid_map(pcpu_info[cpu].processor_id); > > the hart ID that you get back. If that's INVALID_HARTID, you're in > fact in trouble. > > > > What does "_map" in the function/macro name signify? > > It is interconnections/correllation between Xen's CPU id and Hart's > > id. > > Well. What the function does internally is consult the map. Yet > that's > not relevant to any caller? They only care about the translation from > one ID space to the other? No matter whether a map, radix tree, > rbtree, > or what not is used behind the scenes? Agree, the "_map" in cpuid_to_hartid_map() is useless. Thanks. ~ Oleksii
Re: [PATCH v3 5/9] xen/riscv: introduce asm/pmap.h header
On Tue, 2024-07-30 at 09:56 +0200, Jan Beulich wrote:
> On 29.07.2024 18:22, oleksii.kuroc...@gmail.com wrote:
> > On Mon, 2024-07-29 at 16:29 +0200, Jan Beulich wrote:
> > > On 24.07.2024 17:31, Oleksii Kurochko wrote:
> > > > --- /dev/null
> > > > +++ b/xen/arch/riscv/include/asm/pmap.h
> > > > @@ -0,0 +1,33 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > > +#ifndef ASM_PMAP_H
> > > > +#define ASM_PMAP_H
> > > > +
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +
> > > > +static inline void arch_pmap_map(unsigned int slot, mfn_t mfn)
> > > > +{
> > > > + pte_t *entry = _fixmap[slot];
> > > > + pte_t pte;
> > > > +
> > > > + ASSERT(!pte_is_valid(*entry));
> > > > +
> > > > + pte = mfn_to_xen_entry(mfn, PAGE_HYPERVISOR_RW);
> > > > + write_pte(entry, pte);
> > > > +}
> > >
> > > Perhaps add a comment to clarify why it's safe to omit a TLB
> > > flush
> > > here.
> > > Note that arch_pmap_unmap() having one is a necessary but not
> > > sufficient
> > > condition to that. In principle hardware may also cache
> > > "negative"
> > > TLB
> > > entries; I have no idea how RISC-V behaves in this regard, or
> > > whether
> > > that aspect is actually left to implementations.
> > what do you mean by "negative" TLB? an old TLB entry which should
> > be
> > invalidated?
>
> No, I mean TLB entries saying "no valid translation here". I.e.
> avoiding
> recurring walks of something that was once found to have no
> translation.
But we can't modify an existent entry because we have
"ASSERT(!pte_is_valid(*entry))" in pmap_map() function and we are doing
TLB flush during pmap_unmap(). So when we will be in pmap_map() we are
sure that there is no TLB entry for the new pte.
>
> > > > +static inline void arch_pmap_unmap(unsigned int slot)
> > > > +{
> > > > + pte_t pte = {};
> > > > +
> > > > + write_pte(_fixmap[slot], pte);
> > > > +
> > > > + flush_xen_tlb_range_va_local(FIXMAP_ADDR(slot),
> > > > PAGE_SIZE);
> > > > +}
> > >
> > > For both functions, even if mainly for documentation purposes, it
> > > may
> > > be desirable to mark them __init. It's again a necessary (but not
> > > sufficient) condition here, to validly use local TLB flushes
> > > only.
> > Does __init in this context means that it will be called only by
> > boot
> > cpu at the start and that is it?
>
> No, and I said so in my reply. __init is indicative of the function
> not
> being suitable for runtime use, but it is not enough to indicate the
> function is also unsuitable for use as soon as a 2nd CPU is being
> brought
> up. Yet for the latter we have no proper annotation. Hence my
> suggestion
> to use the former to have at least a limited indicator.
>
> An alternative might be to add ASSERT(system_state <
> SYS_STATE_smp_boot).
> That, however, exists in common/pmap.c already anyway.
>
> Yet another alternative would be a clarifying comment.
Thanks for clarifying. I will stick to the first option with __init.
~ Oleksii
Re: [PATCH v3 4/9] xen/riscv: setup fixmap mapping
On Tue, 2024-07-30 at 09:49 +0200, Jan Beulich wrote:
> On 29.07.2024 18:11, oleksii.kuroc...@gmail.com wrote:
> > On Mon, 2024-07-29 at 15:35 +0200, Jan Beulich wrote:
> > > On 24.07.2024 17:31, Oleksii Kurochko wrote:
> > > > @@ -81,6 +82,14 @@ static inline void
> > > > flush_page_to_ram(unsigned
> > > > long mfn, bool sync_icache)
> > > > BUG_ON("unimplemented");
> > > > }
> > > >
> > > > +/* Write a pagetable entry. */
> > > > +static inline void write_pte(pte_t *p, pte_t pte)
> > > > +{
> > > > + RISCV_FENCE(rw, rw);
> > > > + *p = pte;
> > > > + RISCV_FENCE(rw, rw);
> > > > +}
> > >
> > > Why the first of the two fences?
> > To ensure that writes have completed with the old mapping.
>
> Wait: There can certainly be uncompleted writes, but those must have
> walked the page tables already, or else a (synchronous) fault could
> not be delivered on the originating store instruction. Or am I
> misunderstanding how paging (and associated faults) work on RISC-V?
I am not sure that I correctly understand the part regarding (
synchronous ) fault. Could you please come up with an example?
If something during page table walk will go wrong then a fault will be
raised.
My initial intension was to be sure if I will be writing to an actively
in-use page table that other cores can see at the time then fences
above are required. It is not the case for now as we have only one CPUs
but I assume that it will be a case when SMP will be enabled and more
then one CPU will be able to work with the same page table.
>>> And isn't having the 2nd here going
>> to badly affect batch updates of page tables?
>> By batch you mean update more then one pte?
>> It yes, then it will definitely affect. It could be dropped here but
>> could we do something to be sure that someone won't miss to add
>> fence/barrier?
> Well, imo you first want to spell out where the responsibilities for
> fencing lies. Then follow the spelled out rules in all new code you
> add.
It makes sense. It would we nice if someone can help me with that.
>
> > > > + }
> > > > +
> > > > + BUG_ON(pte_is_valid(*pte));
> > > > +
> > > > + tmp = paddr_to_pte(LINK_TO_LOAD((unsigned
> > > > long)_fixmap),
> > > > PTE_TABLE);
> > >
> > > I'm a little puzzled by the use of LINK_TO_LOAD() (and
> > > LOAD_TO_LINK()
> > > a
> > > little further up) here. Don't you have functioning __pa() and
> > > __va()?
> > No, they haven't been introduced yet.
>
> So you're building up more technical debt, as the use of said two
> constructs really should be limited to very early setup. Aiui once
> you have functioning __va() / __pa() the code here would want
> changing?
Ideally yes, it would want to changed.
Would it be the better solution to define __va() and __pa() using
LOAD_TO_LINK()/LINK_TO_LOAD() so when "real" __va() and __pa() will be
ready so only definitions of __va() and __pa() should be changed.
~ Oleksii
Re: [PATCH v3 7/9] xen/riscv: introduce and init SBI RFENCE extension
On Mon, 2024-07-29 at 17:52 +0200, Jan Beulich wrote:
> On 24.07.2024 17:31, Oleksii Kurochko wrote:
>
>
> > +/*
> > + * Send SFENCE_VMA to a set of target HARTs.
> > + *
> > + * @param hart_mask mask representing set of target HARTs
> > + * @param start virtual address start
> > + * @param size virtual address size
>
> Are these really virtual addresses, not somehow a bias and a number
> of bits (CPUs) or elements? From the rest of the patch I can't deduce
> what these two parameters express.
According to SBI doc start is an virtual address:
https://github.com/riscv-non-isa/riscv-sbi-doc/blob/master/src/ext-rfence.adoc?plain=1#L44
and hart_mask is:
• unsigned long hart_mask is a scalar bit-vector containing hartids
>
> > + */
> > +void sbi_remote_sfence_vma(const unsigned long *hart_mask,
>
> Maybe better hart_mask[]? It's not clear to me though what the upper
> bound of the array is.
Theoretically it is ULONGMAX but we don't looking more then
CONFIG_NR_CPUS.
>
> > +
> > +static void sbi_cpumask_to_hartmask(const struct cpumask *cmask,
> > + struct cpumask *hmask)
>
> I doubt it is valud to re-use struct cpumask for hart maps.
Why not? Would it be better to use unsigned long *hmask?
>
> > +{
> > + u32 cpu;
>
> uint32_t or yet better unsigned int please.
>
> > + unsigned long hart = INVALID_HARTID;
> > +
> > + if (!cmask || !hmask)
> > + return;
> > +
> > + cpumask_clear(hmask);
> > + for_each_cpu(cpu, cmask)
> > + {
> > + if ( CONFIG_NR_CPUS <= cpu )
> > + {
> > + printk(XENLOG_ERR "SBI: invalid hart=%lu for
> > cpu=%d\n",
>
> %u for the CPU please.
>
> > + hart, cpu);
>
> "hart" wasn't set yet and hence is invalid or at least misleading to
> log.
That why it will print INVALID_HARTID which user will identify as
invalid hartid.
Do you mean that there is no any sense to message "invalid hart=%lu" as
it is obviously invalid?
>
> Nit: Indentation.
>
> > + continue;
>
>
> Can you really sensibly continue in such a case?
I think yes, the worst thing we will have is that the "bad" CPU won't
be used.
But it might be better to switch to BUG_ON() as if we are inised the
"if CONFIG_NR_CPUS <= cpu" then it could tell us that something went
wrong.
>
> > + }
> > +
> > + hart = cpuid_to_hartid_map(pcpu_info[cpu].processor_id);
>
> What does "_map" in the function/macro name signify?
It is interconnections/correllation between Xen's CPU id and Hart's id.
~ Oleksii
Re: [PATCH v11 4/5] xen/riscv: enable GENERIC_BUG_FRAME
On Mon, 2024-07-29 at 15:00 +0200, Jan Beulich wrote:
> On 24.07.2024 17:31, Oleksii Kurochko wrote:
> > To have working BUG(), WARN(), ASSERT, run_in_exception_handler()
> > it is needed to enable GENERIC_BUG_FRAME.
> >
> > ebreak is used as BUG_insn so when macros from are
> > used, an exception with BREAKPOINT cause will be generated.
> >
> > ebreak triggers a debug trap, which starts in debug mode and is
> > then filtered by every mode. A debugger will first handle the
> > debug trap and check if ebreak was set by it or not. If not,
> > CAUSE_BREAKPOINT will be generated for the mode where the ebreak
> > instruction was executed.
>
> Here and in the similar code comment you talk about an external
> debugger, requiring debug mode, which is an optional feature. In
> my earlier comments what I was referring to was pure software
> debugging. I continue to fail to see how properly distinguishing
> ebreak uses for breakpoints from ebreak uses for e.g. BUG() and
> WARN() is going to be feasible.
I am using GDB now and everything working well.
>
> > @@ -103,7 +104,39 @@ static void do_unexpected_trap(const struct
> > cpu_user_regs *regs)
> >
> > void do_trap(struct cpu_user_regs *cpu_regs)
> > {
> > - do_unexpected_trap(cpu_regs);
> > + register_t pc = cpu_regs->sepc;
> > + unsigned long cause = csr_read(CSR_SCAUSE);
> > +
> > + switch ( cause )
> > + {
> > + /*
> > + * ebreak is used as BUG_insn so when macros from
> > are
> > + * used, an exception with BREAKPOINT cause will be generated.
> > + *
> > + * ebreak triggers a debug trap, which starts in debug mode
> > and is
> > + * then filtered by every mode. A debugger will first handle
> > the
> > + * debug trap and check if ebreak was set by it or not. If
> > not,
> > + * CAUSE_BREAKPOINT will be generated for the mode where the
> > ebreak
> > + * instruction was executed.
> > + */
> > + case CAUSE_BREAKPOINT:
> > + if ( do_bug_frame(cpu_regs, pc) >= 0 )
> > + {
> > + if ( !(is_kernel_text(pc) || is_kernel_inittext(pc)) )
> > + {
> > + printk("Something wrong with PC: %#lx\n", pc);
> > + die();
> > + }
> > +
> > + cpu_regs->sepc += GET_INSN_LENGTH(*(uint16_t *)pc);
> > + }
> > +
> > + break;
>
> Wouldn't you better fall through here, with the "break" moved into
> the if()'s body?
It makes sense to me. Thanks.
~ Oleksii
Re: [PATCH v3 6/9] xen/riscv: introduce functionality to work with cpu info
On Mon, 2024-07-29 at 17:28 +0200, Jan Beulich wrote:
> On 24.07.2024 17:31, Oleksii Kurochko wrote:
> > --- a/xen/arch/riscv/include/asm/processor.h
> > +++ b/xen/arch/riscv/include/asm/processor.h
> > @@ -12,8 +12,39 @@
> >
> > #ifndef __ASSEMBLY__
> >
> > -/* TODO: need to be implemeted */
> > -#define smp_processor_id() 0
> > +#include
> > +#include
> > +
> > +register struct pcpu_info *tp asm ("tp");
> > +
> > +struct pcpu_info {
> > + unsigned int processor_id;
> > +};
> > +
> > +/* tp points to one of these */
> > +extern struct pcpu_info pcpu_info[NR_CPUS];
> > +
> > +#define get_processor_id() (tp->processor_id)
> > +#define set_processor_id(id) do { \
> > + tp->processor_id = id; \
>
> Nit: Parentheses around id please.
>
> > +} while(0)
>
> While often we omit the blanks inside the parentheses for such
> constructs, the one ahead of the opening paren should still be there.
>
> > +static inline unsigned int smp_processor_id(void)
> > +{
> > + unsigned int id;
> > +
> > + id = get_processor_id();
> > +
> > + /*
> > + * Technically the hartid can be greater than what a uint can
> > hold.
> > + * If such a system were to exist, we will need to change
> > + * the smp_processor_id() API to be unsigned long instead of
> > + * unsigned int.
> > + */
> > + BUG_ON(id > UINT_MAX);
>
> Compilers may complaing about this condition being always false. But:
> Why
> do you check against UINT_MAX, not against NR_CPUS?
Because HART id theoretically could be greater then what unsigned int
can provide thereby NR_CPUS could be also greater then unsigned int (
or it can't ? ).
Generally I agree it would be better to compare it with NR_CPUS.
> It's not the hart ID
> your retrieving get_processor_id(), but Xen's, isn't it?
You are right it is Xen's CPU id.
> Even if I'm
> missing something here, ...
>
> > --- a/xen/arch/riscv/include/asm/smp.h
> > +++ b/xen/arch/riscv/include/asm/smp.h
> > @@ -5,6 +5,8 @@
> > #include
> > #include
> >
> > +#define INVALID_HARTID UINT_MAX
>
> ... this implies that the check above would need to use >=.
>
> > @@ -14,6 +16,14 @@ DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);
> > */
> > #define park_offline_cpus false
> >
> > +void smp_setup_processor_id(unsigned long boot_cpu_hartid);
> > +
> > +/*
> > + * Mapping between linux logical cpu index and hartid.
> > + */
> > +extern unsigned long __cpuid_to_hartid_map[NR_CPUS];
> > +#define cpuid_to_hartid_map(cpu) __cpuid_to_hartid_map[cpu]
>
> May I please ask that there be no new variables with double
> underscores
> at the front or any other namespacing violations?
I just couldn't come up with better naming for __cpuid_to_hartid_map[]
to show that it is private array. I will update the namings here.
> > --- a/xen/arch/riscv/setup.c
> > +++ b/xen/arch/riscv/setup.c
> > @@ -40,6 +40,19 @@ void __init noreturn start_xen(unsigned long
> > bootcpu_id,
> > {
> > remove_identity_mapping();
> >
> > + /*
> > + * tp register contains an address of physical cpu
> > information.
> > + * So write physical CPU info of boot cpu to tp register
> > + * It will be used later by get_processor_id() to get
> > process_id ( look at
>
> process_id?
I meant processor_id here.
>
>
> > +};
> > +
> > +void __init smp_setup_processor_id(unsigned long boot_cpu_hartid)
> > +{
> > + cpuid_to_hartid_map(0) = boot_cpu_hartid;
> > +}
>
> The function name suggests this can be used for all CPUs, but the
> code is pretty clear abut this being for the boot CPU only.
Then I will rename it to setup_bootcpu_id(...).
Thanks.
~ Oleksii
Re: [PATCH v3 5/9] xen/riscv: introduce asm/pmap.h header
On Mon, 2024-07-29 at 16:29 +0200, Jan Beulich wrote:
> On 24.07.2024 17:31, Oleksii Kurochko wrote:
> > Introduces arch_pmap_{un}map functions and select HAS_PMAP
> > for CONFIG_RISCV.
> >
> > Additionaly it was necessary to introduce functions:
> > - mfn_from_xen_entry
> > - mfn_to_pte
> >
> > Also flush_xen_tlb_range_va_local() and flush_xen_tlb_one_local()
> > are introduced and use in arch_pmap_unmap().
>
> Just flush_xen_tlb_one_local() would suffice for the purposes here.
> flush_xen_tlb_range_va_local() will need some kind of cutoff, to
> avoid looping for an excessivly long time.
>
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/pmap.h
> > @@ -0,0 +1,33 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef ASM_PMAP_H
> > +#define ASM_PMAP_H
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +static inline void arch_pmap_map(unsigned int slot, mfn_t mfn)
> > +{
> > + pte_t *entry = _fixmap[slot];
> > + pte_t pte;
> > +
> > + ASSERT(!pte_is_valid(*entry));
> > +
> > + pte = mfn_to_xen_entry(mfn, PAGE_HYPERVISOR_RW);
> > + write_pte(entry, pte);
> > +}
>
> Perhaps add a comment to clarify why it's safe to omit a TLB flush
> here.
> Note that arch_pmap_unmap() having one is a necessary but not
> sufficient
> condition to that. In principle hardware may also cache "negative"
> TLB
> entries; I have no idea how RISC-V behaves in this regard, or whether
> that aspect is actually left to implementations.
what do you mean by "negative" TLB? an old TLB entry which should be
invalidated?
>
> > +static inline void arch_pmap_unmap(unsigned int slot)
> > +{
> > + pte_t pte = {};
> > +
> > + write_pte(_fixmap[slot], pte);
> > +
> > + flush_xen_tlb_range_va_local(FIXMAP_ADDR(slot), PAGE_SIZE);
> > +}
>
> For both functions, even if mainly for documentation purposes, it may
> be desirable to mark them __init. It's again a necessary (but not
> sufficient) condition here, to validly use local TLB flushes only.
Does __init in this context means that it will be called only by boot
cpu at the start and that is it?
>
> > --- a/xen/arch/riscv/mm.c
> > +++ b/xen/arch/riscv/mm.c
> > @@ -382,3 +382,18 @@ int map_pages_to_xen(unsigned long virt,
> > BUG_ON("unimplemented");
> > return -1;
> > }
> > +
> > +static inline pte_t mfn_from_pte(mfn_t mfn)
> > +{
> > + unsigned long pte = mfn_x(mfn) << PTE_PPN_SHIFT;
> > + return (pte_t){ .pte = pte };
> > +}
>
> My earlier naming related comment may not have been here, but it
> was certainly meant to apply to any similar functions: A function
> of this name should imo take a pte_t and produce an mfn_t. IOW I'd
> expect this function to be pte_from_mfn(). However, I question it
> being
> a good idea to do it this way. The resulting pte_t isn't valid yet,
> aiui,
> as it still needs at least the access controls filled in. Such a
> partial
> pte_t would better not be floating around at any time, imo. IOW the
> function likely wants to take a 2nd parameter.
Thanks. I'll double check the namings and update the prototype of this
function.
~ Oleksii
Re: [PATCH v3 4/9] xen/riscv: setup fixmap mapping
On Mon, 2024-07-29 at 15:35 +0200, Jan Beulich wrote:
> On 24.07.2024 17:31, Oleksii Kurochko wrote:
> > Introduce a function to set up fixmap mappings and L0 page
> > table for fixmap.
> >
> > Additionally, defines were introduced in riscv/config.h to
> > calculate the FIXMAP_BASE address.
> > This involved introducing BOOT_FDT_VIRT_{START, SIZE} and
> > XEN_VIRT_SIZE, XEN_VIRT_END.
> >
> > Also, the check of Xen size was updated in the riscv/lds.S
> > script to use XEN_VIRT_SIZE instead of a hardcoded constant.
> >
> > Signed-off-by: Oleksii Kurochko
>
> Yet set_fixmap() isn't introduced here, so effectively it's all dead
> code. This could do with mentioning, as I at least would expect
> set_fixmap() to be usable once fixmaps are properly set up.
>
> > --- a/xen/arch/riscv/include/asm/config.h
> > +++ b/xen/arch/riscv/include/asm/config.h
> > @@ -66,6 +66,14 @@
> > #define SLOTN_ENTRY_BITS (HYP_PT_ROOT_LEVEL * VPN_BITS +
> > PAGE_SHIFT)
> > #define SLOTN(slot) (_AT(vaddr_t, slot) <<
> > SLOTN_ENTRY_BITS)
> >
> > +#define XEN_VIRT_SIZE MB(2)
> > +
> > +#define BOOT_FDT_VIRT_START (XEN_VIRT_START + XEN_VIRT_SIZE)
> > +#define BOOT_FDT_VIRT_SIZE MB(4)
> > +
> > +#define FIXMAP_BASE (BOOT_FDT_VIRT_START +
> > BOOT_FDT_VIRT_SIZE)
> > +#define FIXMAP_ADDR(n) (FIXMAP_BASE + (n) * PAGE_SIZE)
> > +
> > #if RV_STAGE1_MODE == SATP_MODE_SV39
> > #define XEN_VIRT_START 0xC000
> > #elif RV_STAGE1_MODE == SATP_MODE_SV48
>
> Related to my earlier comment: Is there a particular reason that what
> you add cannot live _below_ the XEN_VIRT_START definitions, so things
> actually appear in order?
It can leave _below_ the XEN_VIRT_START definitions, I just wanted to
be in sync with table above.
But I'll move everything below the XEN_VIRT_START as it is used in
newly introduced definitions.
>
>
>
> > @@ -81,6 +82,14 @@ static inline void flush_page_to_ram(unsigned
> > long mfn, bool sync_icache)
> > BUG_ON("unimplemented");
> > }
> >
> > +/* Write a pagetable entry. */
> > +static inline void write_pte(pte_t *p, pte_t pte)
> > +{
> > + RISCV_FENCE(rw, rw);
> > + *p = pte;
> > + RISCV_FENCE(rw, rw);
> > +}
>
> Why the first of the two fences?
To ensure that writes have completed with the old mapping.
> And isn't having the 2nd here going
> to badly affect batch updates of page tables?
By batch you mean update more then one pte?
It yes, then it will definitely affect. It could be dropped here but
could we do something to be sure that someone won't miss to add
fence/barrier?
>
> > + * x is the highest page table level for currect MMU mode (
> > for example,
> > + * for Sv39 has 3 page tables so the x = 2 (L2 -> L1 -> L0) ).
> > + *
> > + * In this cycle we want to find L1 page table because as L0
> > page table
> > + * xen_fixmap[] will be used.
> > + *
> > + * i is defined ( HYP_PT_ROOT_LEVEL - 1 ) becuase pte for L2 (
> > in
> > + * case of Sv39 ) has been recieved above.
> > + */
> > + for ( i = HYP_PT_ROOT_LEVEL - 1; i != 0; i-- )
>
> I think the subtracting of 1 is unhelpful here. Think of another
> case where
> you want to walk down to L0. How would you express that with a
> similar for()
> construct. It would imo be more natural to use
>
> for ( i = HYP_PT_ROOT_LEVEL; i > 1; i-- )
Then the first one _i_ will be initialized as L2, not L1. As an option
we then have to use ...
>
> here (and then in that hypothetical other case
>
> for ( i = HYP_PT_ROOT_LEVEL; i > 0; i-- )
>
> ), and then the last part of the comment likely wouldn't be needed
> either.
> However, considering ...
>
> > + {
> > + BUG_ON(!pte_is_valid(*pte));
> > +
> > + pte = (pte_t *)LOAD_TO_LINK(pte_to_paddr(*pte));
> > + pte = [pt_index(i, FIXMAP_ADDR(0))];
>
> ... the use of i here, it may instead want to be
... should be ( i - 1 ).
I am okay with such refactoring.
>
> for ( i = HYP_PT_ROOT_LEVEL; i-- > 1; )
>
> > + }
> > +
> > + BUG_ON(pte_is_valid(*pte));
> > +
> > + tmp = paddr_to_pte(LINK_TO_LOAD((unsigned long)_fixmap),
> > PTE_TABLE);
>
> I'm a little puzzled by the use of LINK_TO_LOAD() (and LOAD_TO_LINK()
> a
> little further up) here. Don't you have functioning __pa() and
> __va()?
No, they haven't been introduced yet.
~ Oleksii
Re: [PATCH] CHANGELOG.md: Finalize changes in 4.19 release cycle
On Mon, 2024-07-29 at 13:56 +0200, Jan Beulich wrote: > On 29.07.2024 13:52, Oleksii Kurochko wrote: > > Signed-off-by: Oleksii Kurochko > > Acked-by: Jan Beulich > (for whatever that's worth) > Thanks. ~ Oleksii
[PATCH] CHANGELOG.md: Finalize changes in 4.19 release cycle
Signed-off-by: Oleksii Kurochko --- Changes in V3: - update "Changed". Move "Code symbol annotations and MISRA compliance improvements" to generic part. - Sort "Added section". Per-arch changes go first. - Drop implementation related details for Arm and PPC in "Changed". - drop PPC and RISCV changes as nothing usable at the moment we have and only minor fixes and improvements were done. --- Changes in V2: - Make CI items started with uppercase letters. --- CHANGELOG.md | 9 + 1 file changed, 9 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index f8fbe82df6..f143a924ef 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -23,11 +23,20 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) using a standalone library implementation. - xenalyze no longer requires `--svm-mode` when analyzing traces generated on AMD CPUs + - Code symbol annotations and MISRA compliance improvements. + - CI updates: + - Minimum fixes to rebuild the containers, following the HEREDOC problems. + - Rebuild containers to have testing with up-to-date LTS distros. + - Few build system checks, and strip the obsolete contents of + the build containers. ### Added - On x86: - Introduce a new x2APIC driver that uses Cluster Logical addressing mode for IPIs and Physical addressing mode for external interrupts. + - On Arm: + - FF-A notification support. + - Introduction of dynamic node programming using overlay dtbo. - Add a new 9pfs backend running as a daemon in dom0. First user is Xenstore-stubdom now being able to support full Xenstore trace capability. - libxl support for backendtype=tap with tapback. -- 2.45.2
Re: [PATCH for 4.19] CHANGELOG.md: Finalize changes in 4.19 release cycle
On Mon, 2024-07-29 at 10:11 +0200, Jan Beulich wrote: > On 29.07.2024 09:31, Oleksii Kurochko wrote: > > Signed-off-by: Oleksii Kurochko > > Since no-one else cared to reply so far, I will (I tried to avoid > doing so, > because - I'm sorry for that - feedback is mostly negative, in part > following > what I said for some 4.18 entries last time already, iirc): Any feedback is good! > > > --- a/CHANGELOG.md > > +++ b/CHANGELOG.md > > @@ -15,6 +15,17 @@ The format is based on [Keep a > > Changelog](https://keepachangelog.com/en/1.0.0/) > > - Reduce IOMMU setup time for hardware domain. > > - Allow HVM/PVH domains to map foreign pages. > > - Declare PVH dom0 supported with caveats. > > + - On Arm: > > + - Reworking the logic so all the MMU-off code is now self- > > contained for > > + secondary boot CPUs on arm64. > > This is an implementation detail aiui nothing people using Xen would > actually > stumble across or notice. Imo such doesn't belong here. Same goes for > the > entire PPC part of this hunk further down. > > > + - Code symbol annotations and MISRA compliance improvements. > > This isn't Arm-specific, is it? Agree, this is not Arm-specific, so I will move it to "Changed". > > > + - Addressing issues of the static shared memory feature. > > Along the lines of the above, I don't think individual features' bug > fixes > want/need mentioning here. > > > @@ -23,6 +34,11 @@ The format is based on [Keep a > > Changelog](https://keepachangelog.com/en/1.0.0/) > > using a standalone library implementation. > > - xenalyze no longer requires `--svm-mode` when analyzing traces > > generated on AMD CPUs > > + - CI updates: > > + - Minimum fixes to rebuild the containers, following the > > HEREDOC problems. > > + - Rebuild containers to have testing with up-to-date LTS > > distros. > > + - Few build system checks, and strip the obsolete contents of > > + the build containers. > > This again doesn't concern people using Xen, does it? What about people who are building Xen themselves? This part of the changelog informs them that we have verified Xen builds with the latest up-to-date LTS. > > > @@ -31,6 +47,14 @@ The format is based on [Keep a > > Changelog](https://keepachangelog.com/en/1.0.0/) > > - Add a new 9pfs backend running as a daemon in dom0. First user > > is > > Xenstore-stubdom now being able to support full Xenstore trace > > capability. > > - libxl support for backendtype=tap with tapback. > > + - On Arm: > > + - FF-A notification support. > > + - Introduction of dynamic node programming using overlay dtbo. > > This is fine to have. I wonder though if the per-arch sections > wouldn't > better sit next to each other (all at the top or all at the bottom). I didn't get you here. Everything in "### Added" is sorted per-arch. > > > + - On PPC: > > + - Basic exception handler implementation. > > + - On RISCV: > > + - Identity mapping implementation. > > + - Introduction of architecture-specific headers. > > These again don't concern people using Xen, do they? Well, I agree that PPC/RISCV is far away from being used but still it shows that progress is going on. Do we have the document which tell what should be in CHANGELOG and what shouldn't? ~ Oleksii
Re: [XEN for-4.19] SUPPORT.md: Define support lifetime
Hi Julien, On Sat, 2024-07-27 at 11:45 +0100, Julien Grall wrote: > From: Julien Grall > > Signed-off-by: Julien Grall > --- > SUPPORT.md | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/SUPPORT.md b/SUPPORT.md > index 77d2a7a7db1a..8b998d9bc7b7 100644 > --- a/SUPPORT.md > +++ b/SUPPORT.md > @@ -9,13 +9,13 @@ for the definitions of the support status levels > etc. > > # Release Support > > - Xen-Version: 4.19-rc > - Initial-Release: n/a > - Supported-Until: TBD > - Security-Support-Until: Unreleased - not yet security-supported > + Xen-Version: 4.19 > + Initial-Release: 2024-07-29 > + Supported-Until: 2026-01-29 > + Security-Support-Until: 2027-07-29 I am not sure that it is critical but I am still waiting for CHANGELOG changes review. If it won't reviewed/merged today we can't cut off the release today so the date should be changed. ( But I hope we will be able to review and merge CHANGELOG changes [1] ) Release-Acked-By: Oleksii Kurochko [1] https://lore.kernel.org/xen-devel/0c93b49ac00fa92721035b4f9eb2ae76175fe886.1722237887.git.oleksii.kuroc...@gmail.com/T/#u ~ Oleksii > > Release Notes > -: href="https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release_Notes > ">RN > +: href="https://wiki.xenproject.org/wiki/Xen_Project_4.19_Release_Notes > ">RN > > # Feature Support >
[PATCH for 4.19] CHANGELOG.md: Finalize changes in 4.19 release cycle
Signed-off-by: Oleksii Kurochko --- Changes in V2: - Make CI items started with uppercase letters. --- CHANGELOG.md | 24 1 file changed, 24 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index f8fbe82df6..a8b56b9632 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -15,6 +15,17 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) - Reduce IOMMU setup time for hardware domain. - Allow HVM/PVH domains to map foreign pages. - Declare PVH dom0 supported with caveats. + - On Arm: + - Reworking the logic so all the MMU-off code is now self-contained for + secondary boot CPUs on arm64. + - Code symbol annotations and MISRA compliance improvements. + - Addressing issues of the static shared memory feature. + - On PPC: + - Minor fixes and improvements: + - Add .text.exceptions section for exception vectors. + - Replace debug printing code with printk. + - Address violations of MISRA C:2012 Rule 11.8. + - Ensure ELF sections' physical load addresses start at 0x0. - xl/libxl configures vkb=[] for HVM domains with priority over vkb_device. - Increase the maximum number of CPUs Xen can be built for from 4095 to 16383. @@ -23,6 +34,11 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) using a standalone library implementation. - xenalyze no longer requires `--svm-mode` when analyzing traces generated on AMD CPUs + - CI updates: + - Minimum fixes to rebuild the containers, following the HEREDOC problems. + - Rebuild containers to have testing with up-to-date LTS distros. + - Few build system checks, and strip the obsolete contents of + the build containers. ### Added - On x86: @@ -31,6 +47,14 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) - Add a new 9pfs backend running as a daemon in dom0. First user is Xenstore-stubdom now being able to support full Xenstore trace capability. - libxl support for backendtype=tap with tapback. + - On Arm: + - FF-A notification support. + - Introduction of dynamic node programming using overlay dtbo. + - On PPC: + - Basic exception handler implementation. + - On RISCV: + - Identity mapping implementation. + - Introduction of architecture-specific headers. ### Removed - caml-stubdom. It hasn't built since 2014, was pinned to Ocaml 4.02, and has -- 2.45.2
[PATCH] CHANGELOG.md: Finalize changes in 4.19 release cycle
Signed-off-by: Oleksii Kurochko --- CHANGELOG.md | 24 1 file changed, 24 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index f8fbe82df6..39e8737e61 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -15,6 +15,17 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) - Reduce IOMMU setup time for hardware domain. - Allow HVM/PVH domains to map foreign pages. - Declare PVH dom0 supported with caveats. + - On Arm: + - Reworking the logic so all the MMU-off code is now self-contained for + secondary boot CPUs on arm64. + - Code symbol annotations and MISRA compliance improvements. + - Addressing issues of the static shared memory feature. + - On PPC: + - Minor fixes and improvements: + - Add .text.exceptions section for exception vectors. + - Replace debug printing code with printk. + - Address violations of MISRA C:2012 Rule 11.8. + - Ensure ELF sections' physical load addresses start at 0x0. - xl/libxl configures vkb=[] for HVM domains with priority over vkb_device. - Increase the maximum number of CPUs Xen can be built for from 4095 to 16383. @@ -23,6 +34,11 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) using a standalone library implementation. - xenalyze no longer requires `--svm-mode` when analyzing traces generated on AMD CPUs + - CI updates: + - minimum fixes to rebuild the containers, following the HEREDOC problems. + - rebuild containers to have testing with up-to-date LTS distros. + - few build system checks, and strip the obsolete contents of + the build containers. ### Added - On x86: @@ -31,6 +47,14 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) - Add a new 9pfs backend running as a daemon in dom0. First user is Xenstore-stubdom now being able to support full Xenstore trace capability. - libxl support for backendtype=tap with tapback. + - On Arm: + - FF-A notification support. + - Introduction of dynamic node programming using overlay dtbo. + - On PPC: + - Basic exception handler implementation. + - On RISCV: + - Identity mapping implementation. + - Introduction of architecture-specific headers. ### Removed - caml-stubdom. It hasn't built since 2014, was pinned to Ocaml 4.02, and has -- 2.45.2
Re: [PATCH for-4.19] hotplug: Restore block-tap phy compatibility (again)
On Wed, 2024-07-24 at 11:50 +, Anthony PERARD wrote: > On Tue, Jul 23, 2024 at 07:31:58PM +0200, > oleksii.kuroc...@gmail.com wrote: > > On Tue, 2024-07-23 at 11:04 -0400, Jason Andryuk wrote: > > > Oleksii, this is a fix (for an incomplete fix) for 4.19. > > > 76a484193d > > > broke compatibility for block-tap with the blktap2 kernel model > > > (when > > > adding support for tapback). This finishes restoring blktap2 > > > support. > > > > > > I realize it's late in the release if you don't want to take it. > > It's pretty late but I just wanted to clarify: > > 1. Is so critical that we should have this in 4.19? > > I don't think it's critical enough to justify delaying the release. > blktap2 is I think an out-of-tree kernel module so probably not very > used. > We might want to at least put a note in "known issue" about blktap2 > support by the "block-tap" script been broken. It was merged and I think it won't delay a release as this feature is disabled by default. ~ Oleksii > > > 2. If we won't take it now, then will it be backported anyway? > > Yes, we want to backport that as soon as 4.19 tree is open for > backports, to have the fix in 4.19.1. > > Cheers, >
[PATCH v3 7/9] xen/riscv: introduce and init SBI RFENCE extension
Introduces functions to work with SBI RFENCE extenstion
which will be used to do various version of fences for
remote ( not local ) CPU.
Except that sbi_init() function and auxiliary functions and
macros definitions are introduced to proper initialization and
checking availability of SBI extenstions.
At the moment, it is only done for RFENCE.
sbi_remote_sfence_vma() is introduced to send SFENCE_VMA to
a set of target HARTs and based on that flush_xen_tlb_range_va()
will be implemented.
Signed-off-by: Oleksii Kurochko
---
Changes in V3:
- new patch.
---
xen/arch/riscv/include/asm/sbi.h | 57 +++
xen/arch/riscv/sbi.c | 256 +++
xen/arch/riscv/setup.c | 3 +
3 files changed, 316 insertions(+)
diff --git a/xen/arch/riscv/include/asm/sbi.h b/xen/arch/riscv/include/asm/sbi.h
index 0e6820a4ed..0985fbb1aa 100644
--- a/xen/arch/riscv/include/asm/sbi.h
+++ b/xen/arch/riscv/include/asm/sbi.h
@@ -14,6 +14,38 @@
#define SBI_EXT_0_1_CONSOLE_PUTCHAR0x1
+#define SBI_EXT_BASE0x10
+#define SBI_EXT_RFENCE 0x52464E43
+
+/* SBI function IDs for BASE extension */
+#define SBI_EXT_BASE_GET_SPEC_VERSION 0x0
+#define SBI_EXT_BASE_GET_IMP_ID 0x1
+#define SBI_EXT_BASE_GET_IMP_VERSION0x2
+#define SBI_EXT_BASE_PROBE_EXT 0x3
+
+/* SBI function IDs for RFENCE extension */
+#define SBI_EXT_RFENCE_REMOTE_FENCE_I 0x0
+#define SBI_EXT_RFENCE_REMOTE_SFENCE_VMA0x1
+#define SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID 0x2
+#define SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA 0x3
+#define SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA_VMID 0x4
+#define SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA 0x5
+#define SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA_ASID 0x6
+
+#define SBI_SPEC_VERSION_MAJOR_SHIFT24
+#define SBI_SPEC_VERSION_MAJOR_MASK 0x7f
+#define SBI_SPEC_VERSION_MINOR_MASK 0xff
+
+/* SBI return error codes */
+#define SBI_SUCCESS 0
+#define SBI_ERR_FAILURE -1
+#define SBI_ERR_NOT_SUPPORTED -2
+#define SBI_ERR_INVALID_PARAM -3
+#define SBI_ERR_DENIED -4
+#define SBI_ERR_INVALID_ADDRESS -5
+
+#define SBI_SPEC_VERSION_DEFAULT0x1
+
struct sbiret {
long error;
long value;
@@ -31,4 +63,29 @@ struct sbiret sbi_ecall(unsigned long ext, unsigned long fid,
*/
void sbi_console_putchar(int ch);
+/*
+ * Check underlying SBI implementation has RFENCE
+ *
+ * @return 1 for supported AND 0 for not-supported
+ */
+int sbi_has_rfence(void);
+
+/*
+ * Send SFENCE_VMA to a set of target HARTs.
+ *
+ * @param hart_mask mask representing set of target HARTs
+ * @param start virtual address start
+ * @param size virtual address size
+ */
+void sbi_remote_sfence_vma(const unsigned long *hart_mask,
+ unsigned long start,
+ unsigned long size);
+
+/*
+ * Initialize SBI library
+ *
+ * @return 0 on success, otherwise negative errno on failure
+ */
+int sbi_init(void);
+
#endif /* __ASM_RISCV_SBI_H__ */
diff --git a/xen/arch/riscv/sbi.c b/xen/arch/riscv/sbi.c
index 0ae166c861..04d878d1e2 100644
--- a/xen/arch/riscv/sbi.c
+++ b/xen/arch/riscv/sbi.c
@@ -10,8 +10,18 @@
* Copyright (c) 2021-2023 Vates SAS.
*/
+#include
+#include
+#include
+#include
+#include
+
+#include
#include
+static unsigned long sbi_spec_version = SBI_SPEC_VERSION_DEFAULT;
+static unsigned long sbi_fw_id, sbi_fw_version;
+
struct sbiret sbi_ecall(unsigned long ext, unsigned long fid,
unsigned long arg0, unsigned long arg1,
unsigned long arg2, unsigned long arg3,
@@ -38,7 +48,253 @@ struct sbiret sbi_ecall(unsigned long ext, unsigned long
fid,
return ret;
}
+static int sbi_err_map_xen_errno(int err)
+{
+switch ( err )
+{
+case SBI_SUCCESS:
+return 0;
+case SBI_ERR_DENIED:
+return -EACCES;
+case SBI_ERR_INVALID_PARAM:
+return -EINVAL;
+case SBI_ERR_INVALID_ADDRESS:
+return -EFAULT;
+case SBI_ERR_NOT_SUPPORTED:
+case SBI_ERR_FAILURE:
+default:
+return -EOPNOTSUPP;
+};
+}
+
void sbi_console_putchar(int ch)
{
sbi_ecall(SBI_EXT_0_1_CONSOLE_PUTCHAR, 0, ch, 0, 0, 0, 0, 0);
}
+
+static unsigned long sbi_major_version(void)
+{
+return (sbi_spec_version >> SBI_SPEC_VERSION_MAJOR_SHIFT) &
+SBI_SPEC_VERSION_MAJOR_MASK;
+}
+
+static unsigned long sbi_minor_version(void)
+{
+return sbi_spec_version & SBI_SPEC_VERSION_MINOR_MASK;
+}
+
+static long sbi_ext_base_func(long fid)
+{
+struct sbiret ret;
+
+ret = sbi_ecall(SBI_EXT_BASE, fid, 0, 0, 0, 0, 0, 0);
+if (!ret.error)
+return ret.value;
+else
+return ret.error;
+}
+
+static void sbi_cpumask_to_hartmask(const struct cpumask *cmask,
+ struct cpumask *hmask)
+{
+u32 cpu;
+unsigned long hart = INVALID_HARTID;
+
+if (!cmask || !hmask)
+return;
+
+cpuma
[PATCH v3 8/9] xen/riscv: page table handling
Introduces an implementation of map_pages_to_xen() which requires multiple
functions to work with page tables/entries:
- xen_pt_update()
- xen_pt_mapping_level()
- xen_pt_update_entry()
- xen_pt_next_level()
- xen_pt_check_entry()
During the mentioned above function it is necessary to create Xen tables
or map/unmap them. For that it were introduced the following functions:
- create_xen_table()
- xen_map_table()
- xen_unmap_table()
Also it was introduced various internal macros for convience started with
_PAGE_* which almost duplicate the bits in PTE except _PAGE_BLOCK which
actually doesn't present in PTE which indicates that page larger then 4k
is needed. RISC-V doesn't have a specific bit in PTE and it detect if it
is a superpage or not only by using pte.x and pte.r. From the RISC-V spec:
```
...
4. Otherwise, the PTE is valid. If pte.r = 1 or pte.x = 1, go to step 5.
Otherwise, this PTE is a pointer to the next level of the page table.
... .
5. A leaf PTE has been found.
...
...
```
Except that it was introduced flush_xen_tlb_range_va() for TLB flushing
accross CPUs when PTE for requested mapping was properly updated.
Signed-off-by: Oleksii Kurochko
---
Changes in V3:
- new patch. ( Technically it is reworked version of the generic approach
which I tried to suggest in the previous version )
---
xen/arch/riscv/Kconfig | 1 +
xen/arch/riscv/Makefile| 1 +
xen/arch/riscv/include/asm/flushtlb.h | 15 +
xen/arch/riscv/include/asm/mm.h| 2 +
xen/arch/riscv/include/asm/page-bits.h | 36 +++
xen/arch/riscv/include/asm/page.h | 73 -
xen/arch/riscv/mm.c| 9 -
xen/arch/riscv/pt.c| 410 +
8 files changed, 537 insertions(+), 10 deletions(-)
create mode 100644 xen/arch/riscv/pt.c
diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig
index 0112aa8778..9827a12d34 100644
--- a/xen/arch/riscv/Kconfig
+++ b/xen/arch/riscv/Kconfig
@@ -2,6 +2,7 @@ config RISCV
def_bool y
select FUNCTION_ALIGNMENT_16B
select GENERIC_BUG_FRAME
+ select GENERIC_PT
select HAS_DEVICE_TREE
select HAS_PMAP
diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index 334fd24547..d058ea4e95 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
obj-y += entry.o
obj-y += mm.o
+obj-y += pt.o
obj-$(CONFIG_RISCV_64) += riscv64/
obj-y += sbi.o
obj-y += setup.o
diff --git a/xen/arch/riscv/include/asm/flushtlb.h
b/xen/arch/riscv/include/asm/flushtlb.h
index cf66e90773..90c65b153f 100644
--- a/xen/arch/riscv/include/asm/flushtlb.h
+++ b/xen/arch/riscv/include/asm/flushtlb.h
@@ -5,6 +5,8 @@
#include
#include
+#include
+
/* Flush TLB of local processor for address va. */
static inline void flush_xen_tlb_one_local(vaddr_t va)
{
@@ -27,6 +29,19 @@ static inline void flush_xen_tlb_range_va_local(vaddr_t va,
}
}
+/*
+ * Flush a range of VA's hypervisor mappings from the TLB of all
+ * processors in the inner-shareable domain.
+ */
+static inline void flush_xen_tlb_range_va(vaddr_t va,
+ unsigned long size)
+{
+if ( sbi_has_rfence() )
+sbi_remote_sfence_vma(NULL, va, size);
+else
+BUG_ON("IPI support is need for remote TLB flush");
+}
+
/*
* Filter the given set of CPUs, removing those that definitely flushed their
* TLB since @page_timestamp.
diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index a0bdc2bc3a..a7550e77a7 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -42,6 +42,8 @@ static inline void *maddr_to_virt(paddr_t ma)
#define virt_to_mfn(va) __virt_to_mfn(va)
#define mfn_to_virt(mfn)__mfn_to_virt(mfn)
+#define pte_get_mfn(pte) maddr_to_mfn(pte_to_paddr(pte))
+
struct page_info
{
/* Each frame can be threaded onto a doubly-linked list. */
diff --git a/xen/arch/riscv/include/asm/page-bits.h
b/xen/arch/riscv/include/asm/page-bits.h
index 8f1f474371..8e40a607d8 100644
--- a/xen/arch/riscv/include/asm/page-bits.h
+++ b/xen/arch/riscv/include/asm/page-bits.h
@@ -3,6 +3,42 @@
#ifndef __RISCV_PAGE_BITS_H__
#define __RISCV_PAGE_BITS_H__
+/*
+ * PTE format:
+ * | XLEN-1 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
+ * PFN reserved for SW D A G U X W R V
+ */
+
+#define _PAGE_PRESENT BIT(0, UL)
+#define _PAGE_READ BIT(1, UL)/* Readable */
+#define _PAGE_WRITE BIT(2, UL)/* Writable */
+#define _PAGE_EXEC BIT(3, UL)/* Executable */
+#define _PAGE_USER BIT(4, UL)/* User */
+#define _PAGE_GLOBALBIT(5, UL)/* Global */
+#define _PAGE_ACCESSED BIT(6, UL)/* Set by hardware on any access */
+#define _PAGE_DIRTY BIT(7, UL)/* Set by hardware on any write */
+#define _PAGE_SOFT BIT(8, UL)/
[PATCH v11 2/5] xen/riscv: introduce decode_cause() stuff
The patch introduces stuff needed to decode a reason of an
exception.
Signed-off-by: Oleksii Kurochko
Acked-by: Alistair Francis
Acked-by: Jan Beulich
---
Changes in V11:
- Nothing changed. Only rebase.
---
Changes in V10:
- add Acked-by: Jan Beulich
---
Changes in V9:
- This patch was reverted as breaks both release and randconfig builds.
I don't see the failures now. ( probably it was because of printk usage
which was not ready at that moment ).
- drop inclusion of and
- add for CAUSE_* in decode_trap_cause().
---
Changes in V8:
- fix typo in return string from decode_reserved_interrupt_cause
- add Acked-by: Alistair Francis
---
Changes in V7:
- Nothing changed. Only rebase.
---
Changes in V6:
- Remove usage of LINK_TO_LOAD() due to the MMU being enabled first.
- Change early_printk() to printk()
---
Changes in V5:
- Remove from riscv/traps/c as nothing would require
inclusion.
- decode_reserved_interrupt_cause(), decode_interrupt_cause(), decode_cause,
do_unexpected_trap()
were made as static they are expected to be used only in traps.c
- use LINK_TO_LOAD() for addresses which can be linker time relative.
---
Changes in V4:
- fix string in decode_reserved_interrupt_cause()
---
Changes in V3:
- Nothing changed
---
Changes in V2:
- Make decode_trap_cause() more optimization friendly.
- Merge the pathc which introduces do_unexpected_trap() to the current one.
---
xen/arch/riscv/traps.c | 80 +-
1 file changed, 79 insertions(+), 1 deletion(-)
diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c
index 5415cf8d90..37cec40dfa 100644
--- a/xen/arch/riscv/traps.c
+++ b/xen/arch/riscv/traps.c
@@ -9,13 +9,91 @@
#include
#include
+#include
#include
-void do_trap(struct cpu_user_regs *cpu_regs)
+static const char *decode_trap_cause(unsigned long cause)
+{
+static const char *const trap_causes[] = {
+[CAUSE_MISALIGNED_FETCH] = "Instruction Address Misaligned",
+[CAUSE_FETCH_ACCESS] = "Instruction Access Fault",
+[CAUSE_ILLEGAL_INSTRUCTION] = "Illegal Instruction",
+[CAUSE_BREAKPOINT] = "Breakpoint",
+[CAUSE_MISALIGNED_LOAD] = "Load Address Misaligned",
+[CAUSE_LOAD_ACCESS] = "Load Access Fault",
+[CAUSE_MISALIGNED_STORE] = "Store/AMO Address Misaligned",
+[CAUSE_STORE_ACCESS] = "Store/AMO Access Fault",
+[CAUSE_USER_ECALL] = "Environment Call from U-Mode",
+[CAUSE_SUPERVISOR_ECALL] = "Environment Call from S-Mode",
+[CAUSE_MACHINE_ECALL] = "Environment Call from M-Mode",
+[CAUSE_FETCH_PAGE_FAULT] = "Instruction Page Fault",
+[CAUSE_LOAD_PAGE_FAULT] = "Load Page Fault",
+[CAUSE_STORE_PAGE_FAULT] = "Store/AMO Page Fault",
+[CAUSE_FETCH_GUEST_PAGE_FAULT] = "Instruction Guest Page Fault",
+[CAUSE_LOAD_GUEST_PAGE_FAULT] = "Load Guest Page Fault",
+[CAUSE_VIRTUAL_INST_FAULT] = "Virtualized Instruction Fault",
+[CAUSE_STORE_GUEST_PAGE_FAULT] = "Guest Store/AMO Page Fault",
+};
+
+if ( cause < ARRAY_SIZE(trap_causes) && trap_causes[cause] )
+return trap_causes[cause];
+return "UNKNOWN";
+}
+
+static const char *decode_reserved_interrupt_cause(unsigned long irq_cause)
+{
+switch ( irq_cause )
+{
+case IRQ_M_SOFT:
+return "M-mode Software Interrupt";
+case IRQ_M_TIMER:
+return "M-mode Timer Interrupt";
+case IRQ_M_EXT:
+return "M-mode External Interrupt";
+default:
+return "UNKNOWN IRQ type";
+}
+}
+
+static const char *decode_interrupt_cause(unsigned long cause)
+{
+unsigned long irq_cause = cause & ~CAUSE_IRQ_FLAG;
+
+switch ( irq_cause )
+{
+case IRQ_S_SOFT:
+return "Supervisor Software Interrupt";
+case IRQ_S_TIMER:
+return "Supervisor Timer Interrupt";
+case IRQ_S_EXT:
+return "Supervisor External Interrupt";
+default:
+return decode_reserved_interrupt_cause(irq_cause);
+}
+}
+
+static const char *decode_cause(unsigned long cause)
+{
+if ( cause & CAUSE_IRQ_FLAG )
+return decode_interrupt_cause(cause);
+
+return decode_trap_cause(cause);
+}
+
+static void do_unexpected_trap(const struct cpu_user_regs *regs)
{
+unsigned long cause = csr_read(CSR_SCAUSE);
+
+printk("Unhandled exception: %s\n", decode_cause(cause));
+
die();
}
+void do_trap(struct cpu_user_regs *cpu_regs)
+{
+do_unexpected_trap(cpu_regs);
+}
+
void vcpu_show_execution_state(struct vcpu *v)
{
BUG_ON("unimplemented");
--
2.45.2
[PATCH v7 2/9] xen/common: Move Arm's bootfdt.c to common
From: Shawn Anastasio
Move Arm's bootfdt.c to xen/common so that it can be used by other
device tree architectures like PPC and RISCV.
Suggested-by: Julien Grall
Signed-off-by: Shawn Anastasio
Acked-by: Julien Grall
Signed-off-by: Oleksii Kurochko
---
Changes in V7:
- Nothing changed. Only rebase.
---
Changes in V6:
- update the version of the patch to v6.
---
Changes in V5:
- add xen/include/xen/bootfdt.h to MAINTAINERS file.
- drop message "Early device tree parsing and".
- After rebase on top of the current staging the following changes were done:
- init bootinfo variable in with
BOOTINFO_INIT;
- update the code of dt_unreserved_regions():
CONFIG_STATIC_SHM related changes and getting of reserved_mem
bootinfo_get_shmem() ??
- update the code of meminfo_overlap_check():
add check ( INVALID_PADDR == bank_start ) to if case.
- update the code of check_reserved_regions_overlap():
CONFIG_STATIC_SHM related changes.
- struct bootinfo was updated ( CONFIG_STATIC_SHM changes )
- add shared_meminfo ( because of CONFIG_STATIC_SHM )
- struct struct membanks was update with __struct group so is
neeeded to be included in bootfdt.h
- move BOOTINFO_ACPI_INIT, BOOTINFO_SHMEM_INIT, BOOTINFO_INIT to generic
bootfdt.h
- bootinfo_get_reserved_mem(), bootinfo_get_mem(), bootinfo_get_acpi(),
bootinfo_get_shmem() and bootinfo_get_shmem_extra() were moved to
xen/bootfdt.h
- s/arm32/CONFIG_SEPARATE_XENHEAP/
- add inclusion of because there are function in
which
are using container_of().
---
Changes in v4:
- create new xen/include/bootinfo.h rather than relying on arch's
asm/setup.h to provide required definitions for bootinfo.c
- build bootinfo.c as .init.o
- clean up and sort bootinfo.c's #includes
- use CONFIG_SEPARATE_XENHEAP rather than CONFIG_ARM_32 to guard
xenheap-specific behavior of populate_boot_allocator
- (MAINTAINERS) include all of common/device-tree rather than just
bootinfo.c
---
xen/arch/arm/Makefile| 1 -
xen/arch/arm/bootfdt.c | 622 --
xen/arch/arm/include/asm/setup.h | 13 -
xen/common/device-tree/Makefile | 1 +
xen/common/device-tree/bootfdt.c | 635 +++
xen/include/xen/bootfdt.h| 14 +
6 files changed, 650 insertions(+), 636 deletions(-)
delete mode 100644 xen/arch/arm/bootfdt.c
create mode 100644 xen/common/device-tree/bootfdt.c
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 45dc29ea53..da9c979dc4 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -10,7 +10,6 @@ obj-$(CONFIG_TEE) += tee/
obj-$(CONFIG_HAS_VPCI) += vpci.o
obj-$(CONFIG_HAS_ALTERNATIVE) += alternative.o
-obj-y += bootfdt.init.o
obj-y += cpuerrata.o
obj-y += cpufeature.o
obj-y += decode.o
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
deleted file mode 100644
index 6e060111d9..00
--- a/xen/arch/arm/bootfdt.c
+++ /dev/null
@@ -1,622 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * Early Device Tree
- *
- * Copyright (C) 2012-2014 Citrix Systems, Inc.
- */
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-static void __init __maybe_unused build_assertions(void)
-{
-/*
- * Check that no padding is between struct membanks "bank" flexible array
- * member and struct meminfo "bank" member
- */
-BUILD_BUG_ON((offsetof(struct membanks, bank) !=
- offsetof(struct meminfo, bank)));
-/* Ensure "struct membanks" is 8-byte aligned */
-BUILD_BUG_ON(alignof(struct membanks) != 8);
-}
-
-static bool __init device_tree_node_is_available(const void *fdt, int node)
-{
-const char *status;
-int len;
-
-status = fdt_getprop(fdt, node, "status", );
-if ( !status )
-return true;
-
-if ( len > 0 )
-{
-if ( !strcmp(status, "ok") || !strcmp(status, "okay") )
-return true;
-}
-
-return false;
-}
-
-static bool __init device_tree_node_matches(const void *fdt, int node,
-const char *match)
-{
-const char *name;
-size_t match_len;
-
-name = fdt_get_name(fdt, node, NULL);
-match_len = strlen(match);
-
-/* Match both "match" and "match@..." patterns but not
- "match-foo". */
-return strncmp(name, match, match_len) == 0
-&& (name[match_len] == '@' || name[match_len] == '\0');
-}
-
-static bool __init device_tree_node_compatible(const void *fdt, int node,
- const char *match)
-{
-int len, l;
-const void *prop;
-
-prop = fdt_getprop(fdt, node, "compatible", );
-if ( prop == NULL )
-return false;
-
-while ( len > 0 ) {
-if (
[PATCH v3 4/9] xen/riscv: setup fixmap mapping
Introduce a function to set up fixmap mappings and L0 page
table for fixmap.
Additionally, defines were introduced in riscv/config.h to
calculate the FIXMAP_BASE address.
This involved introducing BOOT_FDT_VIRT_{START, SIZE} and
XEN_VIRT_SIZE, XEN_VIRT_END.
Also, the check of Xen size was updated in the riscv/lds.S
script to use XEN_VIRT_SIZE instead of a hardcoded constant.
Signed-off-by: Oleksii Kurochko
---
Changes in V3:
- s/XEN_SIZE/XEN_VIRT_SIZE
- drop usage of XEN_VIRT_END.
- sort newly introduced defines in config.h by address
- code style fixes
- drop runtime check of that pte is valid as it was checked in L1 page table
finding cycle by BUG_ON().
- update implementation of write_pte() with FENCE rw, rw.
- add BUILD_BUG_ON() to check that amount of entries aren't bigger then
entries in page table.
- drop set_fixmap, clear_fixmap declarations as they aren't used and defined
now
- update the commit message.
- s/__ASM_FIXMAP_H/ASM_FIXMAP_H
- add SPDX-License-Identifier: GPL-2.0
---
xen/arch/riscv/include/asm/config.h | 8 +
xen/arch/riscv/include/asm/fixmap.h | 44 +++
xen/arch/riscv/include/asm/mm.h | 2 ++
xen/arch/riscv/include/asm/page.h | 9 ++
xen/arch/riscv/mm.c | 47 +
xen/arch/riscv/setup.c | 2 ++
xen/arch/riscv/xen.lds.S| 2 +-
7 files changed, 113 insertions(+), 1 deletion(-)
create mode 100644 xen/arch/riscv/include/asm/fixmap.h
diff --git a/xen/arch/riscv/include/asm/config.h
b/xen/arch/riscv/include/asm/config.h
index 50583aafdc..f517684cbb 100644
--- a/xen/arch/riscv/include/asm/config.h
+++ b/xen/arch/riscv/include/asm/config.h
@@ -66,6 +66,14 @@
#define SLOTN_ENTRY_BITS(HYP_PT_ROOT_LEVEL * VPN_BITS + PAGE_SHIFT)
#define SLOTN(slot) (_AT(vaddr_t, slot) << SLOTN_ENTRY_BITS)
+#define XEN_VIRT_SIZE MB(2)
+
+#define BOOT_FDT_VIRT_START (XEN_VIRT_START + XEN_VIRT_SIZE)
+#define BOOT_FDT_VIRT_SIZE MB(4)
+
+#define FIXMAP_BASE (BOOT_FDT_VIRT_START + BOOT_FDT_VIRT_SIZE)
+#define FIXMAP_ADDR(n) (FIXMAP_BASE + (n) * PAGE_SIZE)
+
#if RV_STAGE1_MODE == SATP_MODE_SV39
#define XEN_VIRT_START 0xC000
#elif RV_STAGE1_MODE == SATP_MODE_SV48
diff --git a/xen/arch/riscv/include/asm/fixmap.h
b/xen/arch/riscv/include/asm/fixmap.h
new file mode 100644
index 00..d3f5ee4944
--- /dev/null
+++ b/xen/arch/riscv/include/asm/fixmap.h
@@ -0,0 +1,44 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * fixmap.h: compile-time virtual memory allocation
+ */
+#ifndef ASM_FIXMAP_H
+#define ASM_FIXMAP_H
+
+#include
+#include
+#include
+
+#include
+
+/* Fixmap slots */
+#define FIX_PMAP_BEGIN (0) /* Start of PMAP */
+#define FIX_PMAP_END (FIX_PMAP_BEGIN + NUM_FIX_PMAP - 1) /* End of PMAP */
+#define FIX_MISC (FIX_PMAP_END + 1) /* Ephemeral mappings of hardware */
+
+#define FIX_LAST FIX_MISC
+
+#define FIXADDR_START FIXMAP_ADDR(0)
+#define FIXADDR_TOP FIXMAP_ADDR(FIX_LAST)
+
+#ifndef __ASSEMBLY__
+
+/*
+ * Direct access to xen_fixmap[] should only happen when {set,
+ * clear}_fixmap() is unusable (e.g. where we would end up to
+ * recursively call the helpers).
+ */
+extern pte_t xen_fixmap[];
+
+#define fix_to_virt(slot) ((void *)FIXMAP_ADDR(slot))
+
+static inline unsigned int virt_to_fix(vaddr_t vaddr)
+{
+BUG_ON(vaddr >= FIXADDR_TOP || vaddr < FIXADDR_START);
+
+return ((vaddr - FIXADDR_START) >> PAGE_SHIFT);
+}
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* ASM_FIXMAP_H */
diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index 25af9e1aaa..a0bdc2bc3a 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -255,4 +255,6 @@ static inline unsigned int arch_get_dma_bitsize(void)
return 32; /* TODO */
}
+void setup_fixmap_mappings(void);
+
#endif /* _ASM_RISCV_MM_H */
diff --git a/xen/arch/riscv/include/asm/page.h
b/xen/arch/riscv/include/asm/page.h
index c831e16417..0cc2f37cf8 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -11,6 +11,7 @@
#include
#include
+#include
#define VPN_MASK(PAGETABLE_ENTRIES - 1UL)
@@ -81,6 +82,14 @@ static inline void flush_page_to_ram(unsigned long mfn, bool
sync_icache)
BUG_ON("unimplemented");
}
+/* Write a pagetable entry. */
+static inline void write_pte(pte_t *p, pte_t pte)
+{
+RISCV_FENCE(rw, rw);
+*p = pte;
+RISCV_FENCE(rw, rw);
+}
+
#endif /* __ASSEMBLY__ */
#endif /* _ASM_RISCV_PAGE_H */
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index 7d09e781bf..35724505ec 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
@@ -49,6 +50,9 @@ stage1_pgtbl_root[PAGETABLE_ENTRIES];
pte_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
stage1_pgtbl_nonroot[P
[PATCH v3 0/9] RISCV device tree mapping
Current patch series introduces device tree mapping for RISC-V and necessary things for that such as: - Fixmap mapping - pmap - Xen page table processing Also, it introduces common stuff for working with fdt which is based on the patches from [1]: [PATCH v4 2/6] xen/device-tree: Move Arm's setup.c bootinfo functions to common [PATCH v4 3/6] xen/common: Move Arm's bootfdt.c All changes which were done on top of Shawn's patches please find in "Changes" section of each patch. Also there is another one depenency: RISCV basic exception handling implementation [2] [1] https://lore.kernel.org/xen-devel/cover.1712893887.git.sanasta...@raptorengineering.com/ [2] https://lore.kernel.org/xen-devel/cover.1720799487.git.oleksii.kuroc...@gmail.com/T/#t --- Changes in v3: - Introduce SBI RFENCE extension support. - Introduce and initialize pcpu_info[] and __cpuid_to_hartid_map[] and functionality to work with this arrays. - Make page table handling arch specific instead of trying to make it generic. - All other changes are patch specific so please look at the patch. --- Changes in v2: - Update the cover letter message - introduce fixmap mapping - introduce pmap - introduce CONFIG_GENREIC_PT - update use early_fdt_map() after MMU is enabled. --- Oleksii Kurochko (7): xen/riscv: enable CONFIG_HAS_DEVICE_TREE xen/riscv: setup fixmap mapping xen/riscv: introduce asm/pmap.h header xen/riscv: introduce functionality to work with cpu info xen/riscv: introduce and init SBI RFENCE extension xen/riscv: page table handling xen/riscv: introduce early_fdt_map() Shawn Anastasio (2): xen/device-tree: Move Arm's setup.c bootinfo functions to common xen/common: Move Arm's bootfdt.c to common MAINTAINERS|2 + xen/arch/arm/Makefile |1 - xen/arch/arm/bootfdt.c | 622 --- xen/arch/arm/include/asm/setup.h | 198 +-- xen/arch/arm/setup.c | 432 - xen/arch/riscv/Kconfig |3 + xen/arch/riscv/Makefile|3 + xen/arch/riscv/include/asm/config.h|8 + xen/arch/riscv/include/asm/fixmap.h| 44 + xen/arch/riscv/include/asm/flushtlb.h | 37 + xen/arch/riscv/include/asm/mm.h|6 + xen/arch/riscv/include/asm/page-bits.h | 36 + xen/arch/riscv/include/asm/page.h | 84 +- xen/arch/riscv/include/asm/pmap.h | 33 + xen/arch/riscv/include/asm/processor.h | 35 +- xen/arch/riscv/include/asm/sbi.h | 57 + xen/arch/riscv/include/asm/smp.h | 10 + xen/arch/riscv/mm.c| 120 +- xen/arch/riscv/pt.c| 410 + xen/arch/riscv/sbi.c | 256 +++ xen/arch/riscv/setup.c | 27 + xen/arch/riscv/smp.c |4 + xen/arch/riscv/smpboot.c | 12 + xen/arch/riscv/xen.lds.S |2 +- xen/common/Makefile|2 +- xen/common/device-tree/Makefile|3 + xen/common/device-tree/bootfdt.c | 635 +++ xen/common/device-tree/bootinfo.c | 459 + xen/common/device-tree/device_tree.c | 2253 xen/common/device_tree.c | 2253 xen/include/xen/bootfdt.h | 209 +++ 31 files changed, 4740 insertions(+), 3516 deletions(-) delete mode 100644 xen/arch/arm/bootfdt.c create mode 100644 xen/arch/riscv/include/asm/fixmap.h create mode 100644 xen/arch/riscv/include/asm/pmap.h create mode 100644 xen/arch/riscv/pt.c create mode 100644 xen/arch/riscv/smp.c create mode 100644 xen/arch/riscv/smpboot.c create mode 100644 xen/common/device-tree/Makefile create mode 100644 xen/common/device-tree/bootfdt.c create mode 100644 xen/common/device-tree/bootinfo.c create mode 100644 xen/common/device-tree/device_tree.c delete mode 100644 xen/common/device_tree.c create mode 100644 xen/include/xen/bootfdt.h -- 2.45.2
[PATCH v3 5/9] xen/riscv: introduce asm/pmap.h header
Introduces arch_pmap_{un}map functions and select HAS_PMAP
for CONFIG_RISCV.
Additionaly it was necessary to introduce functions:
- mfn_from_xen_entry
- mfn_to_pte
Also flush_xen_tlb_range_va_local() and flush_xen_tlb_one_local()
are introduced and use in arch_pmap_unmap().
Signed-off-by: Oleksii Kurochko
---
Changes in V3:
- rename argument of function mfn_to_xen_entry(..., attr -> flags ).
- update the code of mfn_to_xen_entry() to use flags argument.
- add blank in mfn_from_pte() in return line.
- introduce flush_xen_tlb_range_va_local() and use it inside
arch_pmap_{un}map().
- s/__ASM_PMAP_H__/ASM_PMAP_H
- add SPDX-License-Identifier: GPL-2.0
---
xen/arch/riscv/Kconfig| 1 +
xen/arch/riscv/include/asm/flushtlb.h | 22 ++
xen/arch/riscv/include/asm/page.h | 2 ++
xen/arch/riscv/include/asm/pmap.h | 33 +++
xen/arch/riscv/mm.c | 15
5 files changed, 73 insertions(+)
create mode 100644 xen/arch/riscv/include/asm/pmap.h
diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig
index 259eea8d3b..0112aa8778 100644
--- a/xen/arch/riscv/Kconfig
+++ b/xen/arch/riscv/Kconfig
@@ -3,6 +3,7 @@ config RISCV
select FUNCTION_ALIGNMENT_16B
select GENERIC_BUG_FRAME
select HAS_DEVICE_TREE
+ select HAS_PMAP
config RISCV_64
def_bool y
diff --git a/xen/arch/riscv/include/asm/flushtlb.h
b/xen/arch/riscv/include/asm/flushtlb.h
index 7ce32bea0b..cf66e90773 100644
--- a/xen/arch/riscv/include/asm/flushtlb.h
+++ b/xen/arch/riscv/include/asm/flushtlb.h
@@ -5,6 +5,28 @@
#include
#include
+/* Flush TLB of local processor for address va. */
+static inline void flush_xen_tlb_one_local(vaddr_t va)
+{
+asm volatile ( "sfence.vma %0" :: "r" (va) : "memory" );
+}
+
+/*
+ * Flush a range of VA's hypervisor mappings from the TLB of the local
+ * processor.
+ */
+static inline void flush_xen_tlb_range_va_local(vaddr_t va,
+unsigned long size)
+{
+vaddr_t end = va + size;
+
+while ( va < end )
+{
+flush_xen_tlb_one_local(va);
+va += PAGE_SIZE;
+}
+}
+
/*
* Filter the given set of CPUs, removing those that definitely flushed their
* TLB since @page_timestamp.
diff --git a/xen/arch/riscv/include/asm/page.h
b/xen/arch/riscv/include/asm/page.h
index 0cc2f37cf8..2308cefb0a 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -52,6 +52,8 @@ typedef struct {
#endif
} pte_t;
+pte_t mfn_to_xen_entry(mfn_t mfn, unsigned int access_bits);
+
static inline pte_t paddr_to_pte(paddr_t paddr,
unsigned int permissions)
{
diff --git a/xen/arch/riscv/include/asm/pmap.h
b/xen/arch/riscv/include/asm/pmap.h
new file mode 100644
index 00..068d0794b1
--- /dev/null
+++ b/xen/arch/riscv/include/asm/pmap.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef ASM_PMAP_H
+#define ASM_PMAP_H
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static inline void arch_pmap_map(unsigned int slot, mfn_t mfn)
+{
+pte_t *entry = _fixmap[slot];
+pte_t pte;
+
+ASSERT(!pte_is_valid(*entry));
+
+pte = mfn_to_xen_entry(mfn, PAGE_HYPERVISOR_RW);
+write_pte(entry, pte);
+}
+
+static inline void arch_pmap_unmap(unsigned int slot)
+{
+pte_t pte = {};
+
+write_pte(_fixmap[slot], pte);
+
+flush_xen_tlb_range_va_local(FIXMAP_ADDR(slot), PAGE_SIZE);
+}
+
+#endif /* ASM_PMAP_H */
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index 35724505ec..959b6fc63e 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -382,3 +382,18 @@ int map_pages_to_xen(unsigned long virt,
BUG_ON("unimplemented");
return -1;
}
+
+static inline pte_t mfn_from_pte(mfn_t mfn)
+{
+unsigned long pte = mfn_x(mfn) << PTE_PPN_SHIFT;
+return (pte_t){ .pte = pte };
+}
+
+inline pte_t mfn_to_xen_entry(mfn_t mfn, unsigned int access_bits)
+{
+pte_t pte = mfn_from_pte(mfn);
+
+pte.pte |= access_bits;
+
+return pte;
+}
--
2.45.2
[PATCH v3 6/9] xen/riscv: introduce functionality to work with cpu info
struct pcpu_info is introduced to store pcpu related information.
At the moment, it is only processor_id but in the fututre it will be
guest cpu information and some temporary variables which will be
used during save/restore of vcpu registers.
set_processor_id() and get_processor_id() are introduced to set and
get processor id which is stored in pcpu_info.
__cpuid_to_hartid_map[NR_CPUS] is introduced to store the mapping
between Xen logical CPU and hartid ( physical CPU id ) and auxiliary
macros cpuid_to_hartid_map() for convience access to __cpuid_to_hartid_map[].
smp_processor_id() is defined properly as it is enough to information to
define it now instead of seting it to "dummy" 0.
Also, tp registers is initialized to point to pcpu_info[0];
set_processor_id is set to 0 as Xen is running on logical cpu 0 and
save physical CPU id for current logical CPU id in __cpuid_to_hartid_map[].
Signed-off-by: Oleksii Kurochko
---
Changes in V3:
- new patch.
---
xen/arch/riscv/Makefile| 2 ++
xen/arch/riscv/include/asm/processor.h | 35 --
xen/arch/riscv/include/asm/smp.h | 10
xen/arch/riscv/setup.c | 13 ++
xen/arch/riscv/smp.c | 4 +++
xen/arch/riscv/smpboot.c | 12 +
6 files changed, 74 insertions(+), 2 deletions(-)
create mode 100644 xen/arch/riscv/smp.c
create mode 100644 xen/arch/riscv/smpboot.c
diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile
index 81b77b13d6..334fd24547 100644
--- a/xen/arch/riscv/Makefile
+++ b/xen/arch/riscv/Makefile
@@ -4,6 +4,8 @@ obj-y += mm.o
obj-$(CONFIG_RISCV_64) += riscv64/
obj-y += sbi.o
obj-y += setup.o
+obj-y += smp.o
+obj-y += smpboot.o
obj-y += stubs.o
obj-y += traps.o
obj-y += vm_event.o
diff --git a/xen/arch/riscv/include/asm/processor.h
b/xen/arch/riscv/include/asm/processor.h
index 3ae164c265..4c3e45fd17 100644
--- a/xen/arch/riscv/include/asm/processor.h
+++ b/xen/arch/riscv/include/asm/processor.h
@@ -12,8 +12,39 @@
#ifndef __ASSEMBLY__
-/* TODO: need to be implemeted */
-#define smp_processor_id() 0
+#include
+#include
+
+register struct pcpu_info *tp asm ("tp");
+
+struct pcpu_info {
+unsigned int processor_id;
+};
+
+/* tp points to one of these */
+extern struct pcpu_info pcpu_info[NR_CPUS];
+
+#define get_processor_id() (tp->processor_id)
+#define set_processor_id(id)do { \
+tp->processor_id = id; \
+} while(0)
+
+static inline unsigned int smp_processor_id(void)
+{
+unsigned int id;
+
+id = get_processor_id();
+
+/*
+ * Technically the hartid can be greater than what a uint can hold.
+ * If such a system were to exist, we will need to change
+ * the smp_processor_id() API to be unsigned long instead of
+ * unsigned int.
+ */
+BUG_ON(id > UINT_MAX);
+
+return id;
+}
/* On stack VCPU state */
struct cpu_user_regs
diff --git a/xen/arch/riscv/include/asm/smp.h b/xen/arch/riscv/include/asm/smp.h
index b1ea91b1eb..3fff27a8a5 100644
--- a/xen/arch/riscv/include/asm/smp.h
+++ b/xen/arch/riscv/include/asm/smp.h
@@ -5,6 +5,8 @@
#include
#include
+#define INVALID_HARTID UINT_MAX
+
DECLARE_PER_CPU(cpumask_var_t, cpu_sibling_mask);
DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);
@@ -14,6 +16,14 @@ DECLARE_PER_CPU(cpumask_var_t, cpu_core_mask);
*/
#define park_offline_cpus false
+void smp_setup_processor_id(unsigned long boot_cpu_hartid);
+
+/*
+ * Mapping between linux logical cpu index and hartid.
+ */
+extern unsigned long __cpuid_to_hartid_map[NR_CPUS];
+#define cpuid_to_hartid_map(cpu) __cpuid_to_hartid_map[cpu]
+
#endif
/*
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 13f0e8c77d..37b234360c 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -40,6 +40,19 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
{
remove_identity_mapping();
+/*
+ * tp register contains an address of physical cpu information.
+ * So write physical CPU info of boot cpu to tp register
+ * It will be used later by get_processor_id() to get process_id ( look at
+ * ):
+ * #define get_processor_id()(tp->processor_id)
+ */
+asm volatile ("mv tp, %0" : : "r"((unsigned long)_info[0]));
+
+set_processor_id(0);
+
+smp_setup_processor_id(bootcpu_id);
+
trap_init();
#ifdef CONFIG_SELF_TESTS
diff --git a/xen/arch/riscv/smp.c b/xen/arch/riscv/smp.c
new file mode 100644
index 00..006a062ad7
--- /dev/null
+++ b/xen/arch/riscv/smp.c
@@ -0,0 +1,4 @@
+#include
+
+/* tp points to one of these per cpu */
+struct pcpu_info pcpu_info[NR_CPUS];
\ No newline at end of file
diff --git a/xen/arch/riscv/smpboot.c b/xen/arch/riscv/smpboot.c
new file mode 100644
index 00..a90401ffd4
--- /dev/null
+++ b/xen/arch/riscv/smpboot.c
@@ -0,0 +1,12 @@
+#include
+#include
+#include
+
+unsigned long __cpui
[PATCH v11 1/5] xen/riscv: use printk() instead of early_printk()
As common code is available it is better to use printk() instead
of early_printk().
Also the printing of "Hello from RISC-V world" is dropped as
it is useless and "All set up is enough".
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
Changes in V11:
- Nothing changed. Only rebase.
---
Changes in V10:
- add Acked-by: Jan Beulich
---
Changes in V9:
- new patch
---
xen/arch/riscv/setup.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 8bb5bdb2ae..e3cb0866d5 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -23,9 +23,7 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
{
remove_identity_mapping();
-early_printk("Hello from C env\n");
-
-early_printk("All set up\n");
+printk("All set up\n");
for ( ;; )
asm volatile ("wfi");
--
2.45.2
[PATCH v3 9/9] xen/riscv: introduce early_fdt_map()
Introduce function which allows to map FDT to Xen.
Also, initialization of device_tree_flattened happens using early_fdt_map.
Signed-off-by: Oleksii Kurochko
---
Changes in V3:
- Code style fixes
- s/SZ_2M/MB(2)
- fix condition to check if early_fdt_map() in setup.c return NULL or not.
---
Changes in V2:
- rework early_fdt_map to use map_pages_to_xen()
- move call early_fdt_map() to C code after MMU is enabled.
---
xen/arch/riscv/include/asm/mm.h | 2 ++
xen/arch/riscv/mm.c | 55 +
xen/arch/riscv/setup.c | 9 ++
3 files changed, 66 insertions(+)
diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index a7550e77a7..56375bf833 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -259,4 +259,6 @@ static inline unsigned int arch_get_dma_bitsize(void)
void setup_fixmap_mappings(void);
+void *early_fdt_map(paddr_t fdt_paddr);
+
#endif /* _ASM_RISCV_MM_H */
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index ecb0f15fa8..3ca2cc1950 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -1,13 +1,16 @@
/* SPDX-License-Identifier: GPL-2.0-only */
+#include
#include
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
#include
#include
@@ -388,3 +391,55 @@ inline pte_t mfn_to_xen_entry(mfn_t mfn, unsigned int
access_bits)
return pte;
}
+
+void * __init early_fdt_map(paddr_t fdt_paddr)
+{
+/* We are using 2MB superpage for mapping the FDT */
+paddr_t base_paddr = fdt_paddr & XEN_PT_LEVEL_MAP_MASK(1);
+paddr_t offset;
+void *fdt_virt;
+uint32_t size;
+int rc;
+
+/*
+ * Check whether the physical FDT address is set and meets the minimum
+ * alignment requirement. Since we are relying on MIN_FDT_ALIGN to be at
+ * least 8 bytes so that we always access the magic and size fields
+ * of the FDT header after mapping the first chunk, double check if
+ * that is indeed the case.
+ */
+BUILD_BUG_ON(MIN_FDT_ALIGN < 8);
+if ( !fdt_paddr || fdt_paddr % MIN_FDT_ALIGN )
+return NULL;
+
+/* The FDT is mapped using 2MB superpage */
+BUILD_BUG_ON(BOOT_FDT_VIRT_START % MB(2));
+
+rc = map_pages_to_xen(BOOT_FDT_VIRT_START, maddr_to_mfn(base_paddr),
+ MB(2) >> PAGE_SHIFT,
+ PAGE_HYPERVISOR_RO | _PAGE_BLOCK);
+if ( rc )
+panic("Unable to map the device-tree.\n");
+
+offset = fdt_paddr % XEN_PT_LEVEL_SIZE(1);
+fdt_virt = (void *)BOOT_FDT_VIRT_START + offset;
+
+if ( fdt_magic(fdt_virt) != FDT_MAGIC )
+return NULL;
+
+size = fdt_totalsize(fdt_virt);
+if ( size > BOOT_FDT_VIRT_SIZE )
+return NULL;
+
+if ( (offset + size) > MB(2) )
+{
+rc = map_pages_to_xen(BOOT_FDT_VIRT_START + MB(2),
+ maddr_to_mfn(base_paddr + MB(2)),
+ MB(2) >> PAGE_SHIFT,
+ PAGE_HYPERVISOR_RO | _PAGE_BLOCK);
+if ( rc )
+panic("Unable to map the device-tree\n");
+}
+
+return fdt_virt;
+}
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 497e273081..e5f32a142a 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -2,6 +2,7 @@
#include
#include
+#include
#include
#include
@@ -64,6 +65,14 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
setup_fixmap_mappings();
+device_tree_flattened = early_fdt_map(dtb_addr);
+if ( !device_tree_flattened )
+panic("Invalid device tree blob at physical address %#lx.\n"
+ "The DTB must be 8-byte aligned and must not exceed %lld "
+ "bytes in size.\n\n"
+ "Please check your bootloader.\n",
+ dtb_addr, BOOT_FDT_VIRT_SIZE);
+
printk("All set up\n");
for ( ;; )
--
2.45.2
[PATCH v11 5/5] xen/riscv: test basic exception handling stuff
Introduces testing of some macros from .
Also wraps this testing into SELF_TESTS config to not produce
a noise in the log related to functionality testing ( in the
current case, it is macros from xen/bug.h ) when CONFIG_SELF_TESTS
is disabled.
Signed-off-by: Oleksii Kurochko
Acked-by: Alistair Francis
---
xen/arch/riscv/setup.c | 20
1 file changed, 20 insertions(+)
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index a6a29a1508..4defad68f4 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -19,6 +19,22 @@ void arch_get_xen_caps(xen_capabilities_info_t *info)
unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
__aligned(STACK_SIZE);
+#ifdef CONFIG_SELF_TESTS
+static void test_run_in_exception(const struct cpu_user_regs *regs)
+{
+printk("If you see this message, ");
+printk("run_in_exception_handler is most likely working\n");
+}
+
+static void test_macros_from_bug_h(void)
+{
+run_in_exception_handler(test_run_in_exception);
+WARN();
+printk("If you see this message, ");
+printk("WARN is most likely working\n");
+}
+#endif
+
void __init noreturn start_xen(unsigned long bootcpu_id,
paddr_t dtb_addr)
{
@@ -26,6 +42,10 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
trap_init();
+#ifdef CONFIG_SELF_TESTS
+test_macros_from_bug_h();
+#endif
+
printk("All set up\n");
for ( ;; )
--
2.45.2
[PATCH v3 3/9] xen/riscv: enable CONFIG_HAS_DEVICE_TREE
Enable build of generic functionality for working with device tree for RISC-V. Also, a collection of functions for parsing memory map and other boot information from a device tree are available now. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in V3: - add Acked-by: Jan Beulich - update the commit message --- Changes in V2: - move 'select HAS_DEVICE_TREE' to CONFIG_RISCV. --- Changes in V1: - new patch --- xen/arch/riscv/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig index f531e96657..259eea8d3b 100644 --- a/xen/arch/riscv/Kconfig +++ b/xen/arch/riscv/Kconfig @@ -2,6 +2,7 @@ config RISCV def_bool y select FUNCTION_ALIGNMENT_16B select GENERIC_BUG_FRAME + select HAS_DEVICE_TREE config RISCV_64 def_bool y -- 2.45.2
[PATCH v11 0/5] RISCV basic exception handling implementation
ic implementation
of macros from bug.h]
- Update commit messages
---
Changes in V2:
- take the latest riscv_encoding.h from OpenSBI, update it with Xen
related changes, and update the commit message with "Origin:"
tag and the commit message itself.
- add "Origin:" tag to the commit messag of the patch
[xen/riscv: add header].
- Remove the patch [xen/riscv: add early_printk_hnum() function] as the
functionality provided by the patch isn't used now.
- Refactor prcoess.h: move structure offset defines to asm-offsets.c,
change register_t to unsigned long.
- Refactor entry.S to use offsets defined in asm-offsets.C
- Rename {__,}handle_exception to handle_trap() and do_trap() to be more
consistent with RISC-V spec.
- Merge the pathc which introduces do_unexpected_trap() with the patch
[xen/riscv: introduce exception handlers implementation].
- Rename setup_trap_handler() to trap_init() and update correspondingly
the patches in the patch series.
- Refactor bug.h, remove bug_instr_t type from it.
- Refactor decode_trap_cause() function to be more optimization-friendly.
- Add two new empty headers: and as they are needed to
include which provides ARRAY_SIZE and other macros.
- Code style fixes.
---
Oleksii Kurochko (5):
xen/riscv: use printk() instead of early_printk()
xen/riscv: introduce decode_cause() stuff
xen/riscv: introduce trap_init()
xen/riscv: enable GENERIC_BUG_FRAME
xen/riscv: test basic exception handling stuff
xen/arch/riscv/Kconfig | 1 +
xen/arch/riscv/include/asm/traps.h | 1 +
xen/arch/riscv/setup.c | 25 +-
xen/arch/riscv/traps.c | 125 -
xen/common/bug.c | 1 +
5 files changed, 150 insertions(+), 3 deletions(-)
--
2.45.2
[PATCH v11 4/5] xen/riscv: enable GENERIC_BUG_FRAME
To have working BUG(), WARN(), ASSERT, run_in_exception_handler()
it is needed to enable GENERIC_BUG_FRAME.
ebreak is used as BUG_insn so when macros from are
used, an exception with BREAKPOINT cause will be generated.
ebreak triggers a debug trap, which starts in debug mode and is
then filtered by every mode. A debugger will first handle the
debug trap and check if ebreak was set by it or not. If not,
CAUSE_BREAKPOINT will be generated for the mode where the ebreak
instruction was executed.
Also, is needed to be included for the reason that panic() and
printk() are used in common/bug.c and RISC-V fails if it is not included.
Signed-off-by: Oleksii Kurochko
---
Changes in V11:
- update the commit message
- change "%lx" to "%#x" for PC register printing.
- drop +1 in argument of is_kernel_text(pc) and is_kernel_inittext(pc).
- drop return for case CAUSE_BREAKPOINT.
- add break to default and add a blank like above it.
- add a comment CAUSE_BREAKPOINT is handled instead of illegal instruction.
---
Changes in V10:
- put 'select GENERIC_BUG_FRAME' in "Config RISCV".
- rework do_trap() to not fetch an instruction in case when the cause of trap
is BUG_insn.
- drop read_instr() and is_valid_bug_insn().
- update the commit message.
---
Changes in V9:
- Rebase on the top of current staging.
- use GENERIC_BUG_FRAME as now we have common code available.
- add xen/lib.h to bug.c to fix a compilation error around printk.
- update the commit message.
- update the code of read_instr() in traps.c
- fold two-s if into 1 in do_trap.
---
Changes in V8:
- remove Pointless initializer of id.
- make bug_frames[] array constant.
- remove cast_to_bug_frame(addr).
- rename is_valig_bugaddr to is_valid_bug_insn().
- add check that read_instr is used only on xen code
- update the commit message.
---
Changes in V7:
- move to this patch the definition of cast_to_bug_frame() from the previous
patch.
- update the comment in bug.h.
- update the comment above do_bug_frame().
- fix code style.
- add comment to read_instr func.
- add space for bug_frames in lds.S.
---
Changes in V6:
- Avoid LINK_TO_LOAD() as bug.h functionality expected to be used
after MMU is enabled.
- Change early_printk() to printk()
---
Changes in V5:
- Remove "#include " from as there is no any need in
it anymore
- Update macros GET_INSN_LENGTH: remove UL and 'unsigned int len;' from it
- Remove " include " from risc/setup.c. it is not needed in the
current version of
the patch
- change an argument type from vaddr_t to uint32_t for is_valid_bugaddr and
introduce read_instr() to
read instruction properly as the length of qinstruction can be either 32 or
16 bits.
- Code style fixes
- update the comments before do_bug_frame() in riscv/trap.c
- Refactor is_valid_bugaddr() function.
- introduce macros cast_to_bug_frame(addr) to hide casts.
- use LINK_TO_LOAD() for addresses which are linker time relative.
---
Changes in V4:
- Updates in RISC-V's :
* Add explanatory comment about why there is only defined for 32-bits length
instructions and 16/32-bits BUG_INSN_{16,32}.
* Change 'unsigned long' to 'unsigned int' inside GET_INSN_LENGTH().
* Update declaration of is_valid_bugaddr(): switch return type from int to
bool
and the argument from 'unsigned int' to 'vaddr'.
- Updates in RISC-V's traps.c:
* replace /xen and /asm includes
* update definition of is_valid_bugaddr():switch return type from int to
bool
and the argument from 'unsigned int' to 'vaddr'. Code style inside
function
was updated too.
* do_bug_frame() refactoring:
* local variables start and bug became 'const struct bug_frame'
* bug_frames[] array became 'static const struct bug_frame[] = ...'
* remove all casts
* remove unneeded comments and add an explanatory comment that the
do_bug_frame()
will be switched to a generic one.
* do_trap() refactoring:
* read 16-bits value instead of 32-bits as compressed instruction can
be used and it might happen than only 16-bits may be accessible.
* code style updates
* re-use instr variable instead of re-reading instruction.
- Updates in setup.c:
* add blank line between xen/ and asm/ includes.
---
Changes in V3:
- Rebase the patch "xen/riscv: introduce an implementation of macros
from " on top of patch series [introduce generic implementation
of macros from bug.h]
---
Changes in V2:
- Remove __ in define namings
- Update run_in_exception_handler() with
register void *fn_ asm(__stringify(BUG_FN_REG)) = (fn);
- Remove bug_instr_t type and change it's usage to uint32_t
---
xen/arch/riscv/Kconfig | 1 +
xen/arch/riscv/traps.c | 35 ++-
xen/common/bug.c | 1 +
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/xen/arch/riscv/Kconfig
[PATCH v11 3/5] xen/riscv: introduce trap_init()
Note that trap_init() isn't declared with the __init attribute to
avoid removing __init when multi-CPU support for Xen is added.
Signed-off-by: Oleksii Kurochko
Reviewed-by: Alistair Francis
Acked-by: Jan Beulich
---
Changes in V11:
- update the commit message
- add Acked-by: Jan Beulich
---
Changes in V10:
- update the commit message
---
Changes in V9:
- drop inclusion of in setup.c
- drop #include
- ...
- introduce stub for
void arch_get_xen_caps(xen_capabilities_info_t *info);
- resolve rebase conflicts.
---
Changes in V8:
- nothing changed. only rebase was done.
---
Changes in V7:
- #define cast_to_bug_frame(addr) ((const struct bug_frame *)(addr)).
- remove unnecessary comments in trap_init() function.
---
Changes in V6:
- trap_init() is now called after enabling the MMU.
- Add additional explanatory comments.
---
Changes in V5:
- Nothing changed
---
Changes in V4:
- Nothing changed
---
Changes in V3:
- Nothing changed
---
Changes in V2:
- Rename setup_trap_handler() to trap_init().
- Add Reviewed-by to the commit message.
---
xen/arch/riscv/include/asm/traps.h | 1 +
xen/arch/riscv/setup.c | 3 +++
xen/arch/riscv/traps.c | 12
3 files changed, 16 insertions(+)
diff --git a/xen/arch/riscv/include/asm/traps.h
b/xen/arch/riscv/include/asm/traps.h
index 3fef318478..c30118e095 100644
--- a/xen/arch/riscv/include/asm/traps.h
+++ b/xen/arch/riscv/include/asm/traps.h
@@ -9,6 +9,7 @@
void do_trap(struct cpu_user_regs *cpu_regs);
void handle_trap(void);
+void trap_init(void);
#endif /* __ASSEMBLY__ */
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index e3cb0866d5..a6a29a1508 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -8,6 +8,7 @@
#include
#include
+#include
void arch_get_xen_caps(xen_capabilities_info_t *info)
{
@@ -23,6 +24,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
{
remove_identity_mapping();
+trap_init();
+
printk("All set up\n");
for ( ;; )
diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c
index 37cec40dfa..cb18b30ff2 100644
--- a/xen/arch/riscv/traps.c
+++ b/xen/arch/riscv/traps.c
@@ -12,6 +12,18 @@
#include
#include
+/*
+ * Initialize the trap handling.
+ *
+ * The function is called after MMU is enabled.
+ */
+void trap_init(void)
+{
+unsigned long addr = (unsigned long)_trap;
+
+csr_write(CSR_STVEC, addr);
+}
+
static const char *decode_trap_cause(unsigned long cause)
{
static const char *const trap_causes[] = {
--
2.45.2
Re: [PATCH for-4.19] hotplug: Restore block-tap phy compatibility (again)
On Tue, 2024-07-23 at 14:05 -0400, Jason Andryuk wrote:
> On 2024-07-23 13:34, Andrew Cooper wrote:
> > On 23/07/2024 6:31 pm, oleksii.kuroc...@gmail.com wrote:
> > > On Tue, 2024-07-23 at 11:04 -0400, Jason Andryuk wrote:
> > > > On 2024-07-23 11:04, Anthony PERARD wrote:
> > > > > On Mon, Jul 15, 2024 at 07:46:31PM -0400, Jason Andryuk
> > > > > wrote:
> > > > > > "$dev" needs to be set correctly for backendtype=phy as
> > > > > > well as
> > > > > > backendtype=tap. Move the setting into the conditional, so
> > > > > > it
> > > > > > can be
> > > > > > handled properly for each.
> > > > > >
> > > > > > (dev could be captured during tap-ctl allocate for blktap
> > > > > > module,
> > > > > > but it
> > > > > > would not be set properly for the find_device case. The
> > > > > > backendtype=tap
> > > > > > case would need to be handled regardless.)
> > > > > >
> > > > > > Fixes: 6fcdc84927 ("hotplug: Restore block-tap phy
> > > > > > compatibility")
> > > > > Do you mean f16ac12bd418 ("hotplug: Restore block-tap phy
> > > > > compatibility") ?
> > > > Yes! Thanks for checking that - I must have grabbed the hash
> > > > from a
> > > > local branch.
> > > >
> > > > > > Fixes: 76a484193d ("hotplug: Update block-tap")
> > > > > >
> > > > > > Signed-off-by: Jason Andryuk
> > > > > With the fixes tag fix:
> > > > > Reviewed-by: Anthony PERARD
> > > > Thanks again.
> > > >
> > > > Oleksii, this is a fix (for an incomplete fix) for 4.19.
> > > > 76a484193d
> > > > broke compatibility for block-tap with the blktap2 kernel model
> > > > (when
> > > > adding support for tapback). This finishes restoring blktap2
> > > > support.
> > > >
> > > > I realize it's late in the release if you don't want to take
> > > > it.
> > > It's pretty late but I just wanted to clarify:
> > > 1. Is so critical that we should have this in 4.19?
> > > 2. If we won't take it now, then will it be backported anyway?
> >
> > 2) Yes it will get backported. In fact I'm about to commit it to
> > staging.
> >
> > 1) It's a bug in a new feature for 4.19, so if we don't take this
> > bugfix
> > then we'll have to strip it from the release notes.
>
> It's a bug in the old feature. The new feature - tapback daemon
> support, backendtype=tap - works with what's in the 4.19 tree. It's
> the
> old kernel module support - backendtype=phy,script=block-tap - that
> was
> broken when adding tapback support. This patch fixes the old
> support.
>
> The change is localized in the block-tap script and requires explicit
> configuration (script=block-tap) to use. So it seems to me to be a
> lower risk to take it even though it is late in the cycle.
Agree, if it is by default is disabled then I think we can have this
patch in 4.19:
Release-Acked-by: Oleksii Kurochko
~ Oleksii
Re: [PATCH for-4.19] hotplug: Restore block-tap phy compatibility (again)
On Tue, 2024-07-23 at 11:04 -0400, Jason Andryuk wrote:
> On 2024-07-23 11:04, Anthony PERARD wrote:
> > On Mon, Jul 15, 2024 at 07:46:31PM -0400, Jason Andryuk wrote:
> > > "$dev" needs to be set correctly for backendtype=phy as well as
> > > backendtype=tap. Move the setting into the conditional, so it
> > > can be
> > > handled properly for each.
> > >
> > > (dev could be captured during tap-ctl allocate for blktap module,
> > > but it
> > > would not be set properly for the find_device case. The
> > > backendtype=tap
> > > case would need to be handled regardless.)
> > >
> > > Fixes: 6fcdc84927 ("hotplug: Restore block-tap phy
> > > compatibility")
> >
> > Do you mean f16ac12bd418 ("hotplug: Restore block-tap phy
> > compatibility") ?
>
> Yes! Thanks for checking that - I must have grabbed the hash from a
> local branch.
>
> > > Fixes: 76a484193d ("hotplug: Update block-tap")
> > >
> > > Signed-off-by: Jason Andryuk
> >
> > With the fixes tag fix:
> > Reviewed-by: Anthony PERARD
>
> Thanks again.
>
> Oleksii, this is a fix (for an incomplete fix) for 4.19. 76a484193d
> broke compatibility for block-tap with the blktap2 kernel model (when
> adding support for tapback). This finishes restoring blktap2
> support.
>
> I realize it's late in the release if you don't want to take it.
It's pretty late but I just wanted to clarify:
1. Is so critical that we should have this in 4.19?
2. If we won't take it now, then will it be backported anyway?
~ Oleksii
Re: [PATCH v2 5/8] xen/riscv: introduce asm/pmap.h header
On Tue, 2024-07-23 at 19:25 +0200, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-07-23 at 16:49 +0100, Julien Grall wrote:
> > Hi Oleksii,
> >
> > On 23/07/2024 16:36, oleksii.kuroc...@gmail.com wrote:
> > > On Tue, 2024-07-23 at 12:02 +0200, Jan Beulich wrote:
> > > > On 23.07.2024 10:55, oleksii.kuroc...@gmail.com wrote:
> > > > > On Tue, 2024-07-23 at 10:36 +0200, Jan Beulich wrote:
> > > > > > On 23.07.2024 10:02, Oleksii Kurochko wrote:
> > > > > > > On Mon, Jul 22, 2024 at 7:27 PM Julien Grall
> > > > > > >
> > > > > > > wrote:
> > > > > > > > > > On 22/07/2024 15:44, Oleksii Kurochko wrote:
> > > > > > > > > /* Map a 4k page in a fixmap entry */
> > > > > > > > > void set_fixmap(unsigned map, mfn_t mfn,
> > > > > > > > > unsigned
> > > > > > > > > int
> > > > > > > > > flags)
> > > > > > > > > {
> > > > > > > > > pte_t pte;
> > > > > > > > >
> > > > > > > > > pte = mfn_to_xen_entry(mfn, flags);
> > > > > > > > > pte.pte |= PTE_LEAF_DEFAULT;
> > > > > > > > > write_pte(_fixmap[pt_index(0,
> > > > > > > > > FIXMAP_ADDR(map))],
> > > > > > > > > pte);
> > > > > > > >
> > > > > > > > It would be saner to check if you are not overwriting
> > > > > > > > any
> > > > > > > > existing
> > > > > > > > mapping as otherwise you will probably need a TLB
> > > > > > > > flush.
> > > > > > > >
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > /* Remove a mapping from a fixmap entry */
> > > > > > > > > void clear_fixmap(unsigned map)
> > > > > > > > > {
> > > > > > > > > pte_t pte = {0};
> > > > > > > > > write_pte(_fixmap[pt_index(0,
> > > > > > > > > FIXMAP_ADDR(map))],
> > > > > > > > > pte);
> > > > > > > >
> > > > > > > > Don't you need a TLB flush?
> > > > > > > >
> > > > > > > Inside write_pte() there is "sfence.vma".
> > > > > >
> > > > > > That's just a fence though, not a TLB flush.
> > > > > From the privileged doc:
> > > > > ```
> > > > > SFENCE.VMA is also used to invalidate entries in the
> > > > > address-translation cache associated with a hart (see
> > > > > Section
> > > > > 4.3.2).
> > > > > ...
> > > > > The SFENCE.VMA is used to flush any local hardware caches
> > > > > related to
> > > > > address translation.
> > > > > It is specified as a fence rather than a TLB flush to
> > > > > provide
> > > > > cleaner
> > > > > semantics with respect to
> > > > > which instructions are affected by the flush operation
> > > > > and
> > > > > to
> > > > > support a
> > > > > wider variety of dynamic
> > > > > caching structures and memory-management schemes.
> > > > > SFENCE.VMA is
> > > > > also
> > > > > used by higher
> > > > > privilege levels to synchronize page table writes and the
> > > > > address
> > > > > translation hardware.
> > > > > ...
> > > > > ```
> > > > > I read this as SFENCE.VMA is used not only for ordering of
> > > > > load/stores,
> > > > > but also to flush TLB ( which is a type of more general term
> > > > > as
> > > > > address-translation cache, IIUIC ).
> > I have to admit, I am a little because concerned with calling
> > sfence.vma
> > in write_pte() (this may only be because I am not very familiar
> > with
> > RISC-V).
> >
> > We have cases where multiple entry will be written in a single
> > map_pages_to_xen
Re: [PATCH v2 5/8] xen/riscv: introduce asm/pmap.h header
On Tue, 2024-07-23 at 16:49 +0100, Julien Grall wrote:
> Hi Oleksii,
>
> On 23/07/2024 16:36, oleksii.kuroc...@gmail.com wrote:
> > On Tue, 2024-07-23 at 12:02 +0200, Jan Beulich wrote:
> > > On 23.07.2024 10:55, oleksii.kuroc...@gmail.com wrote:
> > > > On Tue, 2024-07-23 at 10:36 +0200, Jan Beulich wrote:
> > > > > On 23.07.2024 10:02, Oleksii Kurochko wrote:
> > > > > > On Mon, Jul 22, 2024 at 7:27 PM Julien Grall
> > > > > >
> > > > > > wrote:
> > > > > > > > > On 22/07/2024 15:44, Oleksii Kurochko wrote:
> > > > > > > > /* Map a 4k page in a fixmap entry */
> > > > > > > > void set_fixmap(unsigned map, mfn_t mfn, unsigned
> > > > > > > > int
> > > > > > > > flags)
> > > > > > > > {
> > > > > > > > pte_t pte;
> > > > > > > >
> > > > > > > > pte = mfn_to_xen_entry(mfn, flags);
> > > > > > > > pte.pte |= PTE_LEAF_DEFAULT;
> > > > > > > > write_pte(_fixmap[pt_index(0,
> > > > > > > > FIXMAP_ADDR(map))],
> > > > > > > > pte);
> > > > > > >
> > > > > > > It would be saner to check if you are not overwriting any
> > > > > > > existing
> > > > > > > mapping as otherwise you will probably need a TLB flush.
> > > > > > >
> > > > > > > > }
> > > > > > > >
> > > > > > > > /* Remove a mapping from a fixmap entry */
> > > > > > > > void clear_fixmap(unsigned map)
> > > > > > > > {
> > > > > > > > pte_t pte = {0};
> > > > > > > > write_pte(_fixmap[pt_index(0,
> > > > > > > > FIXMAP_ADDR(map))],
> > > > > > > > pte);
> > > > > > >
> > > > > > > Don't you need a TLB flush?
> > > > > > >
> > > > > > Inside write_pte() there is "sfence.vma".
> > > > >
> > > > > That's just a fence though, not a TLB flush.
> > > > From the privileged doc:
> > > > ```
> > > > SFENCE.VMA is also used to invalidate entries in the
> > > > address-translation cache associated with a hart (see
> > > > Section
> > > > 4.3.2).
> > > > ...
> > > > The SFENCE.VMA is used to flush any local hardware caches
> > > > related to
> > > > address translation.
> > > > It is specified as a fence rather than a TLB flush to
> > > > provide
> > > > cleaner
> > > > semantics with respect to
> > > > which instructions are affected by the flush operation and
> > > > to
> > > > support a
> > > > wider variety of dynamic
> > > > caching structures and memory-management schemes.
> > > > SFENCE.VMA is
> > > > also
> > > > used by higher
> > > > privilege levels to synchronize page table writes and the
> > > > address
> > > > translation hardware.
> > > > ...
> > > > ```
> > > > I read this as SFENCE.VMA is used not only for ordering of
> > > > load/stores,
> > > > but also to flush TLB ( which is a type of more general term as
> > > > address-translation cache, IIUIC ).
> I have to admit, I am a little because concerned with calling
> sfence.vma
> in write_pte() (this may only be because I am not very familiar with
> RISC-V).
>
> We have cases where multiple entry will be written in a single
> map_pages_to_xen() call. So wouldn't this means that the local TLBs
> would be nuked for every write rather than once?
Yes, it will be nuked. It is bad from perfomance point of view.
I just wanted to be sure that I won't miss to put sfence.vma when it is
necessary and then reworked that a little bit after. But it seems it
would be better not to call sfence.vma in write_pte() just from the
start.
>
>
> > >
> > > Oh, I see. Kind of unexpected for an instruction of that name.
> > > Yet
> > > note
> > > how they talk about the local hart only. You need a wider scope
> > > TLB
> > > flush here.
> >
Re: [PATCH v2 5/8] xen/riscv: introduce asm/pmap.h header
On Tue, 2024-07-23 at 12:02 +0200, Jan Beulich wrote:
> On 23.07.2024 10:55, oleksii.kuroc...@gmail.com wrote:
> > On Tue, 2024-07-23 at 10:36 +0200, Jan Beulich wrote:
> > > On 23.07.2024 10:02, Oleksii Kurochko wrote:
> > > > On Mon, Jul 22, 2024 at 7:27 PM Julien Grall
> > > > wrote:
> > > > > > > On 22/07/2024 15:44, Oleksii Kurochko wrote:
> > > > > > /* Map a 4k page in a fixmap entry */
> > > > > > void set_fixmap(unsigned map, mfn_t mfn, unsigned int
> > > > > > flags)
> > > > > > {
> > > > > > pte_t pte;
> > > > > >
> > > > > > pte = mfn_to_xen_entry(mfn, flags);
> > > > > > pte.pte |= PTE_LEAF_DEFAULT;
> > > > > > write_pte(_fixmap[pt_index(0,
> > > > > > FIXMAP_ADDR(map))],
> > > > > > pte);
> > > > >
> > > > > It would be saner to check if you are not overwriting any
> > > > > existing
> > > > > mapping as otherwise you will probably need a TLB flush.
> > > > >
> > > > > > }
> > > > > >
> > > > > > /* Remove a mapping from a fixmap entry */
> > > > > > void clear_fixmap(unsigned map)
> > > > > > {
> > > > > > pte_t pte = {0};
> > > > > > write_pte(_fixmap[pt_index(0,
> > > > > > FIXMAP_ADDR(map))],
> > > > > > pte);
> > > > >
> > > > > Don't you need a TLB flush?
> > > > >
> > > > Inside write_pte() there is "sfence.vma".
> > >
> > > That's just a fence though, not a TLB flush.
> > From the privileged doc:
> > ```
> > SFENCE.VMA is also used to invalidate entries in the
> > address-translation cache associated with a hart (see Section
> > 4.3.2).
> > ...
> > The SFENCE.VMA is used to flush any local hardware caches
> > related to
> > address translation.
> > It is specified as a fence rather than a TLB flush to provide
> > cleaner
> > semantics with respect to
> > which instructions are affected by the flush operation and to
> > support a
> > wider variety of dynamic
> > caching structures and memory-management schemes. SFENCE.VMA is
> > also
> > used by higher
> > privilege levels to synchronize page table writes and the
> > address
> > translation hardware.
> > ...
> > ```
> > I read this as SFENCE.VMA is used not only for ordering of
> > load/stores,
> > but also to flush TLB ( which is a type of more general term as
> > address-translation cache, IIUIC ).
>
> Oh, I see. Kind of unexpected for an instruction of that name. Yet
> note
> how they talk about the local hart only. You need a wider scope TLB
> flush here.
Could you please clarify why it is needed wider?
Arm Xen flushed only local TLB.
RISC-V Linux kernel for fixmap also uses: local_flush_tlb_page().
~ Oleksii
Re: [PATCH v2 4/8] xen/riscv: setup fixmap mapping
On Tue, 2024-07-23 at 14:33 +0100, Julien Grall wrote:
> On 23/07/2024 14:27, oleksii.kuroc...@gmail.com wrote:
> > Hello Julien,
>
> Hi Oleksii,
>
>
> > On Sun, 2024-07-21 at 09:46 +0100, Julien Grall wrote:
> > > > diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
> > > > index 7d09e781bf..d69a174b5d 100644
> > > > --- a/xen/arch/riscv/mm.c
> > > > +++ b/xen/arch/riscv/mm.c
> > > > @@ -49,6 +49,9 @@ stage1_pgtbl_root[PAGETABLE_ENTRIES];
> > > > pte_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
> > > > stage1_pgtbl_nonroot[PGTBL_INITIAL_COUNT *
> > > > PAGETABLE_ENTRIES];
> > > >
> > > > +pte_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
> > > > +xen_fixmap[PAGETABLE_ENTRIES];
> > >
> > > Can you add a BUILD_BUG_ON() to check that the number of entries
> > > in
> > > the
> > > fixmap will never be above PAGETABLE_ENTRIES?
> > I just realized that we don't have the information about how many
> > entries has been used. Am I confusing something?
>
> I think we do. It is FIX_LAST.
Sure. We have FIX_LAST. Thanks
~ Oleksii
Re: [PATCH v2 4/8] xen/riscv: setup fixmap mapping
On Mon, 2024-07-22 at 19:04 +0200, oleksii.kuroc...@gmail.com wrote:
> On Mon, 2024-07-22 at 17:25 +0200, Jan Beulich wrote:
> > On 22.07.2024 16:36, Oleksii wrote:
> > > On Mon, 2024-07-22 at 14:42 +0200, Jan Beulich wrote:
> > > > On 12.07.2024 18:22, Oleksii Kurochko wrote:
> > > > > --- a/xen/arch/riscv/include/asm/config.h
> > > > > +++ b/xen/arch/riscv/include/asm/config.h
> > > > > @@ -74,11 +74,20 @@
> > > > > #error "unsupported RV_STAGE1_MODE"
> > > > > #endif
> > > > >
> > > > > +#define XEN_SIZE MB(2)
> > > > > +#define XEN_VIRT_END (XEN_VIRT_START + XEN_SIZE)
> > > > > +
> > > > > +#define BOOT_FDT_VIRT_START XEN_VIRT_END
> > > > > +#define BOOT_FDT_VIRT_SIZE MB(4)
> > > > > +
> > > > > #define DIRECTMAP_SLOT_END 509
> > > > > #define DIRECTMAP_SLOT_START 200
> > > > > #define DIRECTMAP_VIRT_START SLOTN(DIRECTMAP_SLOT_START)
> > > > > #define DIRECTMAP_SIZE (SLOTN(DIRECTMAP_SLOT_END) -
> > > > > SLOTN(DIRECTMAP_SLOT_START))
> > > > >
> > > > > +#define FIXMAP_BASE (BOOT_FDT_VIRT_START +
> > > > > BOOT_FDT_VIRT_SIZE)
> > > > > +#define FIXMAP_ADDR(n) (FIXMAP_BASE + (n) *
> > > > > PAGE_SIZE)
> > > >
> > > > Why exactly do you insert this here, and not adjacent to
> > > > BOOT_FDT_VIRT_*,
> > > > which it actually is adjacent with?
> > > I tried to follow alphabetical order.
> >
> > Oh, X before B (just making fun) ... Anyway, my take here is that
> > sorting
> > by address is going to be more helpful.
> >
> > > > > --- a/xen/arch/riscv/mm.c
> > > > > +++ b/xen/arch/riscv/mm.c
> > > > > @@ -49,6 +49,9 @@ stage1_pgtbl_root[PAGETABLE_ENTRIES];
> > > > > pte_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
> > > > > stage1_pgtbl_nonroot[PGTBL_INITIAL_COUNT *
> > > > > PAGETABLE_ENTRIES];
> > > > >
> > > > > +pte_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
> > > > > +xen_fixmap[PAGETABLE_ENTRIES];
> > > >
> > > > Any reason this cannot be static?
> > > It will be used by pmap:
> > > static inline void arch_pmap_map(unsigned int slot, mfn_t mfn)
> > > {
> > > pte_t *entry = _fixmap[slot];
> > > pte_t pte;
> > >
> > > ASSERT(!pte_is_valid(*entry));
> > >
> > > pte = mfn_to_xen_entry(mfn, PAGE_HYPERVISOR_RW);
> > > pte.pte |= PTE_LEAF_DEFAULT;
> > > write_pte(entry, pte);
> > > }
> > >
> > > static inline void arch_pmap_unmap(unsigned int slot)
> > > {
> > > pte_t pte = {};
> > >
> > > write_pte(_fixmap[slot], pte);
> > > }
> >
> > Yet as asked there - shouldn't that be set_fixmap() and
> > clear_fixmap()?
> It should be, I'll rework that in the next patch version.
It couldn't be set_fixmap() and clear_fixmap() as I am going to
implement them using map_pages_to_xen() because:
...
/*
* We cannot use set_fixmap() here. We use PMAP when the domain map
* page infrastructure is not yet initialized, so
map_pages_to_xen() called
* by set_fixmap() needs to map pages on demand, which then calls
pmap()
* again, resulting in a loop. Modify the PTEs directly instead.
The same
* is true for pmap_unmap().
*/
arch_pmap_map(slot, mfn);
...
~ Oleksii
Re: [PATCH v2 4/8] xen/riscv: setup fixmap mapping
Hello Julien,
On Sun, 2024-07-21 at 09:46 +0100, Julien Grall wrote:
> > diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
> > index 7d09e781bf..d69a174b5d 100644
> > --- a/xen/arch/riscv/mm.c
> > +++ b/xen/arch/riscv/mm.c
> > @@ -49,6 +49,9 @@ stage1_pgtbl_root[PAGETABLE_ENTRIES];
> > pte_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
> > stage1_pgtbl_nonroot[PGTBL_INITIAL_COUNT * PAGETABLE_ENTRIES];
> >
> > +pte_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
> > +xen_fixmap[PAGETABLE_ENTRIES];
>
> Can you add a BUILD_BUG_ON() to check that the number of entries in
> the
> fixmap will never be above PAGETABLE_ENTRIES?
I just realized that we don't have the information about how many
entries has been used. Am I confusing something?
~ Oleksii
Re: [PATCH v2 4/8] xen/riscv: setup fixmap mapping
Hi Julien, On Sun, 2024-07-21 at 09:46 +0100, Julien Grall wrote: > > +/* Fixmap slots */ > > +#define FIX_PMAP_BEGIN (0) /* Start of PMAP */ > > +#define FIX_PMAP_END (FIX_PMAP_BEGIN + NUM_FIX_PMAP - 1) /* End of > > PMAP */ > > ... here is seems to be inclusive. Furthermore if you had 32-bit > address > space, it is also quite easy to have to create a region right at the > top > of it. So when END is exclusive, it would become 0. > > So on Arm, we decided to start to get rid of "end". I would consider > to > do the same on RISC-V for new functions. I assume that you wrote here just as an example of confusion occurs because of using *_END but just to be clear I have to leave FIXMAP_MAP_END as-is because it is used now by common code. ~ Oleksii
Xen 4.19-rc4
Hi all, Xen 4.19-rc4 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.19.0-rc4 For your convenience there is also a tarball and the signature at: https://downloads.xenproject.org/release/xen/4.19.0-rc4/xen-4.19.0-rc4.tar.gz And the signature is at: https://downloads.xenproject.org/release/xen/4.19.0-rc4/xen-4.19.0-rc4.tar.gz.sig Please send bug reports and test reports to xen-devel@lists.xenproject.org<mailto:xen-devel@lists.xenproject.org>. When sending bug reports, please CC relevant maintainers and me (oleskii.kuroc...@gmail.com<mailto:oleskii.kuroc...@gmail.com). Best regards, Oleksii
Re: [PATCH for-4.19] x86/altcall: fix clang code-gen when using altcall in loop constructs
On Tue, 2024-07-23 at 11:31 +0200, Roger Pau Monne wrote:
> Yet another clang code generation issue when using altcalls.
>
> The issue this time is with using loop constructs around
> alternative_{,v}call
> instances using parameter types smaller than the register size.
>
> Given the following example code:
>
> static void bar(bool b)
> {
> unsigned int i;
>
> for ( i = 0; i < 10; i++ )
> {
> int ret_;
> register union {
> bool e;
> unsigned long r;
> } di asm("rdi") = { .e = b };
> register unsigned long si asm("rsi");
> register unsigned long dx asm("rdx");
> register unsigned long cx asm("rcx");
> register unsigned long r8 asm("r8");
> register unsigned long r9 asm("r9");
> register unsigned long r10 asm("r10");
> register unsigned long r11 asm("r11");
>
> asm volatile ( "call %c[addr]"
> : "+r" (di), "=r" (si), "=r" (dx),
> "=r" (cx), "=r" (r8), "=r" (r9),
> "=r" (r10), "=r" (r11), "=a" (ret_)
> : [addr] "i" (&(func)), "g" (func)
> : "memory" );
> }
> }
>
> See: https://godbolt.org/z/qvxMGd84q
>
> Clang will generate machine code that only resets the low 8 bits of
> %rdi
> between loop calls, leaving the rest of the register possibly
> containing
> garbage from the use of %rdi inside the called function. Note also
> that clang
> doesn't truncate the input parameters at the callee, thus breaking
> the psABI.
>
> Fix this by turning the `e` element in the anonymous union into an
> array that
> consumes the same space as an unsigned long, as this forces clang to
> reset the
> whole %rdi register instead of just the low 8 bits.
>
> Fixes: 2ce562b2a413 ('x86/altcall: use a union as register type for
> function parameters on clang')
> Suggested-by: Jan Beulich
> Signed-off-by: Roger Pau Monné
> ---
> Adding Oleksii as to whether this could be considered for 4.19: it's
> strictly
> limited to clang builds, plus will need to be backported anyway.
> ---
I am okay to have this change in 4.19 but then it should be reviewed
and merged ASAP as the tree was tagged few minutes ago and I expected
that it will be the last one RC in this release cycle:
Release-Acked-By: Oleksii Kurochko
~ Oleksii
> xen/arch/x86/include/asm/alternative.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/x86/include/asm/alternative.h
> b/xen/arch/x86/include/asm/alternative.h
> index 0d3697f1de49..e63b45927643 100644
> --- a/xen/arch/x86/include/asm/alternative.h
> +++ b/xen/arch/x86/include/asm/alternative.h
> @@ -185,10 +185,10 @@ extern void alternative_branches(void);
> */
> #define ALT_CALL_ARG(arg,
> n) \
> register union
> { \
> - typeof(arg)
> e; \
> + typeof(arg) e[sizeof(long) /
> sizeof(arg)]; \
> unsigned long
> r; \
> } a ## n ## _ asm ( ALT_CALL_arg ## n ) =
> { \
> - .e = ({ BUILD_BUG_ON(sizeof(arg) > sizeof(void *)); (arg);
> }) \
> + .e[0] = ({ BUILD_BUG_ON(sizeof(arg) > sizeof(void *));
> (arg); })\
> }
> #else
> #define ALT_CALL_ARG(arg, n) \
Re: [PATCH v2 5/8] xen/riscv: introduce asm/pmap.h header
On Tue, 2024-07-23 at 10:36 +0200, Jan Beulich wrote:
> On 23.07.2024 10:02, Oleksii Kurochko wrote:
> > On Mon, Jul 22, 2024 at 7:27 PM Julien Grall
> > wrote:
> > > > > On 22/07/2024 15:44, Oleksii Kurochko wrote:
> > > > /* Map a 4k page in a fixmap entry */
> > > > void set_fixmap(unsigned map, mfn_t mfn, unsigned int
> > > > flags)
> > > > {
> > > > pte_t pte;
> > > >
> > > > pte = mfn_to_xen_entry(mfn, flags);
> > > > pte.pte |= PTE_LEAF_DEFAULT;
> > > > write_pte(_fixmap[pt_index(0, FIXMAP_ADDR(map))],
> > > > pte);
> > >
> > > It would be saner to check if you are not overwriting any
> > > existing
> > > mapping as otherwise you will probably need a TLB flush.
> > >
> > > > }
> > > >
> > > > /* Remove a mapping from a fixmap entry */
> > > > void clear_fixmap(unsigned map)
> > > > {
> > > > pte_t pte = {0};
> > > > write_pte(_fixmap[pt_index(0, FIXMAP_ADDR(map))],
> > > > pte);
> > >
> > > Don't you need a TLB flush?
> > >
> > Inside write_pte() there is "sfence.vma".
>
> That's just a fence though, not a TLB flush.
>From the privileged doc:
```
SFENCE.VMA is also used to invalidate entries in the
address-translation cache associated with a hart (see Section 4.3.2).
...
The SFENCE.VMA is used to flush any local hardware caches related to
address translation.
It is specified as a fence rather than a TLB flush to provide cleaner
semantics with respect to
which instructions are affected by the flush operation and to support a
wider variety of dynamic
caching structures and memory-management schemes. SFENCE.VMA is also
used by higher
privilege levels to synchronize page table writes and the address
translation hardware.
...
```
I read this as SFENCE.VMA is used not only for ordering of load/stores,
but also to flush TLB ( which is a type of more general term as
address-translation cache, IIUIC ).
Also, Linux kernel uses sfence.vma to flush TLB:
https://elixir.bootlin.com/linux/v6.0/source/arch/riscv/include/asm/tlbflush.h#L23
~ Oleksii
Re: [PATCH v2 5/8] xen/riscv: introduce asm/pmap.h header
Hi Julien,
On Mon, Jul 22, 2024 at 7:27 PM Julien Grall wrote:
> Hi,
>
> >> On 22/07/2024 15:44, Oleksii Kurochko wrote:
> >>> On Mon, 2024-07-22 at 14:54 +0200, Jan Beulich wrote:
> >>>> On 12.07.2024 18:22, Oleksii Kurochko wrote:
> >>>>> --- /dev/null
> >>>>> +++ b/xen/arch/riscv/include/asm/pmap.h
> >>>>> @@ -0,0 +1,28 @@
> >>>>> +#ifndef __ASM_PMAP_H__
> >>>>> +#define __ASM_PMAP_H__
> >>>>> +
> >>>>> +#include
> >>>>> +#include
> >>>>> +
> >>>>> +#include
> >>>>> +
> >>>>> +static inline void arch_pmap_map(unsigned int slot, mfn_t mfn)
> >>>>> +{
> >>>>> +pte_t *entry = _fixmap[slot];
> >>>>> +pte_t pte;
> >>>>> +
> >>>>> +ASSERT(!pte_is_valid(*entry));
> >>>>> +
> >>>>> +pte = mfn_to_xen_entry(mfn, PAGE_HYPERVISOR_RW);
> >>>>> +pte.pte |= PTE_LEAF_DEFAULT;
> >>>>> +write_pte(entry, pte);
> >>>>> +}
> >>>>> +
> >>>>> +static inline void arch_pmap_unmap(unsigned int slot)
> >>>>> +{
> >>>>> +pte_t pte = {};
> >>>>> +
> >>>>> +write_pte(_fixmap[slot], pte);
> >>>>> +}
> >>>>
> >>>> Why are these not using set_fixmap() / clear_fixmap()
> >>>> respectively?
> >>> They haven't been introduced yet. And I thought that these fucntion
> >>> are
> >>> used only in pmap_{un}map() and that is the reason why I decided to
> >>> not
> >>> introduce them. But while writing the answer on another comment, I
> >>> found other places where set_fixmap() / clear_fixmap() are used, so
> >>> I
> >>> will introduce them and reuse here.
> >>
> >> I am guessing you are going to implement set_fixmap()/clear_fixmap()
> >> using map_pages_to_xen(). If so, for early boot you are going to end
> >> up
> >> in a circular loop because map_pages_to_xen() will likely use pmap()
> >> which will call set_fixmap().
> > I am going to implement that in the following way as I faced the
> > described by you issue when I first time tried to implement it using
> > map_pages_to_xen():
> What's wrong with keeping the arch_pmap_*() as-is and call
> map_pages_to_xen() in the fixmap?
>
> At least this would be consistent with what other architectures does and
> less risky (see below).
>
Then I misunderstood you, if not to use {set/clear}_fixmap() in arch_pmap()
then everything should be fine.
Then I think it is needed to add the comment also above arch_pmap_*()
function why it isn't used {set/clear}_fixmap()
inside. ( or update the commit message )
>
> > /* Map a 4k page in a fixmap entry */
> > void set_fixmap(unsigned map, mfn_t mfn, unsigned int flags)
> > {
> > pte_t pte;
> >
> > pte = mfn_to_xen_entry(mfn, flags);
> > pte.pte |= PTE_LEAF_DEFAULT;
> > write_pte(_fixmap[pt_index(0, FIXMAP_ADDR(map))], pte);
>
> It would be saner to check if you are not overwriting any existing
> mapping as otherwise you will probably need a TLB flush.
>
> > }
> >
> > /* Remove a mapping from a fixmap entry */
> > void clear_fixmap(unsigned map)
> > {
> > pte_t pte = {0};
> > write_pte(_fixmap[pt_index(0, FIXMAP_ADDR(map))], pte);
>
> Don't you need a TLB flush?
>
Inside write_pte() there is "sfence.vma".
But probably it would be better to add flush_xen_tlb_range_va_local() or
something similar here in case if someone will decide to update write_pte().
~ Oleksii
Re: [PATCH v2 5/8] xen/riscv: introduce asm/pmap.h header
On Mon, 2024-07-22 at 15:48 +0100, Julien Grall wrote:
> Hi,
>
> On 22/07/2024 15:44, Oleksii Kurochko wrote:
> > On Mon, 2024-07-22 at 14:54 +0200, Jan Beulich wrote:
> > > On 12.07.2024 18:22, Oleksii Kurochko wrote:
> > > > --- /dev/null
> > > > +++ b/xen/arch/riscv/include/asm/pmap.h
> > > > @@ -0,0 +1,28 @@
> > > > +#ifndef __ASM_PMAP_H__
> > > > +#define __ASM_PMAP_H__
> > > > +
> > > > +#include
> > > > +#include
> > > > +
> > > > +#include
> > > > +
> > > > +static inline void arch_pmap_map(unsigned int slot, mfn_t mfn)
> > > > +{
> > > > + pte_t *entry = _fixmap[slot];
> > > > + pte_t pte;
> > > > +
> > > > + ASSERT(!pte_is_valid(*entry));
> > > > +
> > > > + pte = mfn_to_xen_entry(mfn, PAGE_HYPERVISOR_RW);
> > > > + pte.pte |= PTE_LEAF_DEFAULT;
> > > > + write_pte(entry, pte);
> > > > +}
> > > > +
> > > > +static inline void arch_pmap_unmap(unsigned int slot)
> > > > +{
> > > > + pte_t pte = {};
> > > > +
> > > > + write_pte(_fixmap[slot], pte);
> > > > +}
> > >
> > > Why are these not using set_fixmap() / clear_fixmap()
> > > respectively?
> > They haven't been introduced yet. And I thought that these fucntion
> > are
> > used only in pmap_{un}map() and that is the reason why I decided to
> > not
> > introduce them. But while writing the answer on another comment, I
> > found other places where set_fixmap() / clear_fixmap() are used, so
> > I
> > will introduce them and reuse here.
>
> I am guessing you are going to implement set_fixmap()/clear_fixmap()
> using map_pages_to_xen(). If so, for early boot you are going to end
> up
> in a circular loop because map_pages_to_xen() will likely use pmap()
> which will call set_fixmap().
I am going to implement that in the following way as I faced the
described by you issue when I first time tried to implement it using
map_pages_to_xen():
/* Map a 4k page in a fixmap entry */
void set_fixmap(unsigned map, mfn_t mfn, unsigned int flags)
{
pte_t pte;
pte = mfn_to_xen_entry(mfn, flags);
pte.pte |= PTE_LEAF_DEFAULT;
write_pte(_fixmap[pt_index(0, FIXMAP_ADDR(map))], pte);
}
/* Remove a mapping from a fixmap entry */
void clear_fixmap(unsigned map)
{
pte_t pte = {0};
write_pte(_fixmap[pt_index(0, FIXMAP_ADDR(map))], pte);
}
~ Oleksii
>
> There is a big comment in common/pmap.c which explain why arch_pmap_*
> was introduced rather than calling *_fixmap() directly:
>
> /*
> * We cannot use set_fixmap() here. We use PMAP when the domain
> map
> * page infrastructure is not yet initialized, so
> map_pages_to_xen() called
> * by set_fixmap() needs to map pages on demand, which then
> calls
> pmap()
> * again, resulting in a loop. Modify the PTEs directly instead.
> The same
> * is true for pmap_unmap().
> */
>
> Cheers,
>
Re: [PATCH v2 4/8] xen/riscv: setup fixmap mapping
On Mon, 2024-07-22 at 17:25 +0200, Jan Beulich wrote:
> On 22.07.2024 16:36, Oleksii wrote:
> > On Mon, 2024-07-22 at 14:42 +0200, Jan Beulich wrote:
> > > On 12.07.2024 18:22, Oleksii Kurochko wrote:
> > > > --- a/xen/arch/riscv/include/asm/config.h
> > > > +++ b/xen/arch/riscv/include/asm/config.h
> > > > @@ -74,11 +74,20 @@
> > > > #error "unsupported RV_STAGE1_MODE"
> > > > #endif
> > > >
> > > > +#define XEN_SIZE MB(2)
> > > > +#define XEN_VIRT_END (XEN_VIRT_START + XEN_SIZE)
> > > > +
> > > > +#define BOOT_FDT_VIRT_START XEN_VIRT_END
> > > > +#define BOOT_FDT_VIRT_SIZE MB(4)
> > > > +
> > > > #define DIRECTMAP_SLOT_END 509
> > > > #define DIRECTMAP_SLOT_START 200
> > > > #define DIRECTMAP_VIRT_START SLOTN(DIRECTMAP_SLOT_START)
> > > > #define DIRECTMAP_SIZE (SLOTN(DIRECTMAP_SLOT_END) -
> > > > SLOTN(DIRECTMAP_SLOT_START))
> > > >
> > > > +#define FIXMAP_BASE (BOOT_FDT_VIRT_START +
> > > > BOOT_FDT_VIRT_SIZE)
> > > > +#define FIXMAP_ADDR(n) (FIXMAP_BASE + (n) *
> > > > PAGE_SIZE)
> > >
> > > Why exactly do you insert this here, and not adjacent to
> > > BOOT_FDT_VIRT_*,
> > > which it actually is adjacent with?
> > I tried to follow alphabetical order.
>
> Oh, X before B (just making fun) ... Anyway, my take here is that
> sorting
> by address is going to be more helpful.
>
> > > > --- a/xen/arch/riscv/mm.c
> > > > +++ b/xen/arch/riscv/mm.c
> > > > @@ -49,6 +49,9 @@ stage1_pgtbl_root[PAGETABLE_ENTRIES];
> > > > pte_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
> > > > stage1_pgtbl_nonroot[PGTBL_INITIAL_COUNT * PAGETABLE_ENTRIES];
> > > >
> > > > +pte_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
> > > > +xen_fixmap[PAGETABLE_ENTRIES];
> > >
> > > Any reason this cannot be static?
> > It will be used by pmap:
> > static inline void arch_pmap_map(unsigned int slot, mfn_t mfn)
> > {
> > pte_t *entry = _fixmap[slot];
> > pte_t pte;
> >
> > ASSERT(!pte_is_valid(*entry));
> >
> > pte = mfn_to_xen_entry(mfn, PAGE_HYPERVISOR_RW);
> > pte.pte |= PTE_LEAF_DEFAULT;
> > write_pte(entry, pte);
> > }
> >
> > static inline void arch_pmap_unmap(unsigned int slot)
> > {
> > pte_t pte = {};
> >
> > write_pte(_fixmap[slot], pte);
> > }
>
> Yet as asked there - shouldn't that be set_fixmap() and
> clear_fixmap()?
It should be, I'll rework that in the next patch version.
~ Oleksii
Re: [PATCH v10 4/5] xen/riscv: enable GENERIC_BUG_FRAME
On Mon, 2024-07-22 at 17:32 +0200, Jan Beulich wrote:
> On 22.07.2024 16:09, Oleksii wrote:
> > On Mon, 2024-07-22 at 13:02 +0200, Jan Beulich wrote:
> > > On 12.07.2024 18:18, Oleksii Kurochko wrote:
> > > > ---
> > > > Changes in V10:
> > > > - put 'select GENERIC_BUG_FRAME' in "Config RISCV".
> > > > - rework do_trap() to not fetch an instruction in case when
> > > > the
> > > > cause of trap
> > > > is BUG_insn.
> > >
> > > It's BUG_insn here, but then ...
> > >
> > > > @@ -103,7 +104,29 @@ static void do_unexpected_trap(const
> > > > struct
> > > > cpu_user_regs *regs)
> > > >
> > > > void do_trap(struct cpu_user_regs *cpu_regs)
> > > > {
> > > > - do_unexpected_trap(cpu_regs);
> > > > + register_t pc = cpu_regs->sepc;
> > > > + unsigned long cause = csr_read(CSR_SCAUSE);
> > > > +
> > > > + switch ( cause )
> > > > + {
> > > > + case CAUSE_BREAKPOINT:
> > >
> > > ... BREAKPOINT here? Generally I'd deem something named
> > > "breakpoint"
> > > as
> > > debugging related (and hence continuable). I'd have expected
> > > CAUSE_ILLEGAL_INSTRUCTION here, but likely I'm missing something.
> > Agree, that is is confusing, but BUG_insn is defined as ebreak
> > instruction ( Linux kernel uses also ebreak ) and it generates
> > CAUSE_BREAKPOINT.
>
> I'm curious: How do you / does a debugger tell a breakpoint set on
> such an EBREAK insn (e.g. as a result of a use of WARN_ON()) from
> the original, unmodified insn? If there's a breakpoint, you want
> to forward to the debugger. Whereas if there's no breakpoint, you
> want to process the WARN_ON() normally.
I don't know details of debug spec but AFAIU ebreak triggers a debug
trap, which starts in debug mode and is then filtered by every mode as
it goes towards user-mode. So first GDB will handle this debug trap and
will check if this ebreak was set by him or not.
~ Oleksii
Re: [PATCH v2 5/8] xen/riscv: introduce asm/pmap.h header
On Mon, 2024-07-22 at 14:54 +0200, Jan Beulich wrote:
> On 12.07.2024 18:22, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/pmap.h
> > @@ -0,0 +1,28 @@
> > +#ifndef __ASM_PMAP_H__
> > +#define __ASM_PMAP_H__
> > +
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +static inline void arch_pmap_map(unsigned int slot, mfn_t mfn)
> > +{
> > + pte_t *entry = _fixmap[slot];
> > + pte_t pte;
> > +
> > + ASSERT(!pte_is_valid(*entry));
> > +
> > + pte = mfn_to_xen_entry(mfn, PAGE_HYPERVISOR_RW);
> > + pte.pte |= PTE_LEAF_DEFAULT;
> > + write_pte(entry, pte);
> > +}
> > +
> > +static inline void arch_pmap_unmap(unsigned int slot)
> > +{
> > + pte_t pte = {};
> > +
> > + write_pte(_fixmap[slot], pte);
> > +}
>
> Why are these not using set_fixmap() / clear_fixmap() respectively?
They haven't been introduced yet. And I thought that these fucntion are
used only in pmap_{un}map() and that is the reason why I decided to not
introduce them. But while writing the answer on another comment, I
found other places where set_fixmap() / clear_fixmap() are used, so I
will introduce them and reuse here.
>
> > --- a/xen/arch/riscv/mm.c
> > +++ b/xen/arch/riscv/mm.c
> > @@ -370,3 +370,17 @@ int map_pages_to_xen(unsigned long virt,
> > BUG_ON("unimplemented");
> > return -1;
> > }
> > +
> > +static inline pte_t mfn_to_pte(mfn_t mfn)
>
> This name suggests (to me) that you're getting _the_ (single) PTE for
> a given MFN. However, what the function is doing is make a PTE using
> the given MFN. On x86 at least the common way to name such a function
> would be pte_from_mfn().
If it is a common way then I will rename it. Thanks.
~ Oleksii
>
> > +{
> > + unsigned long pte = mfn_x(mfn) << PTE_PPN_SHIFT;
> > + return (pte_t){ .pte = pte};
>
> Nit: Blank missing.
>
> Jan
Re: [PATCH v2 6/8] xen/riscv: introduce generic Xen page table handling
Hi Julien,
On Sun, 2024-07-21 at 10:02 +0100, Julien Grall wrote:
> Hi,
>
> On 12/07/2024 17:22, Oleksii Kurochko wrote:
> > At least, between Arm and RISC-V most of the code related to Xen
> > page
> > table handling are common.
> >
> > This GENERIC_PT code is based on Arm's arm/mmu/pt.c except some
> > minor
> > changes such as introduction of the following functions:
> > * get_root_page()
> > * xen_pt_check_contig()
> > * set_pte_table_bit()
> > * sanity_arch_specific_pte_checks()
> > * get_contig_bit()
> > * set_pte_permissions()
> > * flush_xen_tlb_range_va()
> > It was done because not every functions has the generic pte_flags
> > and
> > it could be a different positions of the PTE bits in a PTE.
> While I am always in favor of trying to avoid code duplication, I am
> not
> sure the page-tables are one that should be.
Probably it wasn't the best one abstraction provided. But I think that
there are still some function which could be generic:
- xen_{un}map_table()
- map_pages_to_xen
- probably some page table walking?
But I am okay, if not to abstract that, I just wanted to here an
opinion if it is a sense to work in this direction or not.
I will then move everything to RISC-V specific folder and clean up some
places related to Arm.
~ Oleksii
>
> For instance, you don't have the concept of contiguous page in RISC-V
> (I
> see you introduce dummy flags, but IMHO this is a bit of a hack). All
> the code was also written in a way to avoid temporary conflict
> mappings.
> This is to avoid using Break-Before-Make. But on newer hardware this
> could be relaxed.
>
> I am interested to know what the others thinks.
>
> Cheers,
>
Re: [PATCH v2 5/8] xen/riscv: introduce asm/pmap.h header
Hi Julien,
On Sun, 2024-07-21 at 09:51 +0100, Julien Grall wrote:
> Hi Oleksii,
>
> On 12/07/2024 17:22, Oleksii Kurochko wrote:
> > Introduces arch_pmap_{un}map functions and select HAS_PMAP
> > for CONFIG_RISCV.
> >
> > Additionaly it was necessary to introduce functions:
> > - mfn_to_xen_entry
> > - mfn_to_pte
> >
> > Signed-off-by: Oleksii Kurochko
> > ---
> > Changes in V2:
> > - newly introduced patch
> > ---
> > xen/arch/riscv/Kconfig | 1 +
> > xen/arch/riscv/include/asm/page.h | 2 ++
> > xen/arch/riscv/include/asm/pmap.h | 28
> >
> > xen/arch/riscv/mm.c | 14 ++
> > 4 files changed, 45 insertions(+)
> > create mode 100644 xen/arch/riscv/include/asm/pmap.h
> >
> > diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig
> > index 259eea8d3b..0112aa8778 100644
> > --- a/xen/arch/riscv/Kconfig
> > +++ b/xen/arch/riscv/Kconfig
> > @@ -3,6 +3,7 @@ config RISCV
> > select FUNCTION_ALIGNMENT_16B
> > select GENERIC_BUG_FRAME
> > select HAS_DEVICE_TREE
> > + select HAS_PMAP
> >
> > config RISCV_64
> > def_bool y
> > diff --git a/xen/arch/riscv/include/asm/page.h
> > b/xen/arch/riscv/include/asm/page.h
> > index cbbf3656d1..339074d502 100644
> > --- a/xen/arch/riscv/include/asm/page.h
> > +++ b/xen/arch/riscv/include/asm/page.h
> > @@ -51,6 +51,8 @@ typedef struct {
> > #endif
> > } pte_t;
> >
> > +pte_t mfn_to_xen_entry(mfn_t mfn, unsigned int attr);
> > +
> > static inline pte_t paddr_to_pte(paddr_t paddr,
> > unsigned int permissions)
> > {
> > diff --git a/xen/arch/riscv/include/asm/pmap.h
> > b/xen/arch/riscv/include/asm/pmap.h
> > new file mode 100644
> > index 00..eb4c48515c
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/pmap.h
> > @@ -0,0 +1,28 @@
> > +#ifndef __ASM_PMAP_H__
> > +#define __ASM_PMAP_H__
> > +
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +static inline void arch_pmap_map(unsigned int slot, mfn_t mfn)
> > +{
> > + pte_t *entry = _fixmap[slot];
> > + pte_t pte;
> > +
> > + ASSERT(!pte_is_valid(*entry));
> > +
> > + pte = mfn_to_xen_entry(mfn, PAGE_HYPERVISOR_RW);
> > + pte.pte |= PTE_LEAF_DEFAULT;
> > + write_pte(entry, pte);
> > +}
> > +
> > +static inline void arch_pmap_unmap(unsigned int slot)
> > +{
> > + pte_t pte = {};
> > +
> > + write_pte(_fixmap[slot], pte);
> > +}
> > +
> > +#endif /* __ASM_PMAP_H__ */
> > diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
> > index d69a174b5d..445319af08 100644
> > --- a/xen/arch/riscv/mm.c
> > +++ b/xen/arch/riscv/mm.c
> > @@ -370,3 +370,17 @@ int map_pages_to_xen(unsigned long virt,
> > BUG_ON("unimplemented");
> > return -1;
> > }
> > +
> > +static inline pte_t mfn_to_pte(mfn_t mfn)
> > +{
> > + unsigned long pte = mfn_x(mfn) << PTE_PPN_SHIFT;
> > + return (pte_t){ .pte = pte};
> > +}
> > +
> > +inline pte_t mfn_to_xen_entry(mfn_t mfn, unsigned int attr)
> > +{
> > + /* there is no attr field in RISC-V's pte */
> > + (void) attr;
>
> Surely you have a way to say indicate whether an entry is
> readable/writable?
Sure, there is a way. But probably I misinterpreted attr for Arm and
decided not to use them here. By that I mean, that Arm has MT_NORMAL,
MT_DEVICE which RISC-V doesn't have.
If it is about readable/writable then for sure, I will start to use
attr.
~ Oleksii
>
> > +
> > + return mfn_to_pte(mfn);
> > +}
>
> Cheers,
>
Re: [PATCH v2 4/8] xen/riscv: setup fixmap mapping
On Mon, 2024-07-22 at 14:42 +0200, Jan Beulich wrote:
> On 12.07.2024 18:22, Oleksii Kurochko wrote:
> > --- a/xen/arch/riscv/include/asm/config.h
> > +++ b/xen/arch/riscv/include/asm/config.h
> > @@ -74,11 +74,20 @@
> > #error "unsupported RV_STAGE1_MODE"
> > #endif
> >
> > +#define XEN_SIZE MB(2)
> > +#define XEN_VIRT_END (XEN_VIRT_START + XEN_SIZE)
> > +
> > +#define BOOT_FDT_VIRT_START XEN_VIRT_END
> > +#define BOOT_FDT_VIRT_SIZE MB(4)
> > +
> > #define DIRECTMAP_SLOT_END 509
> > #define DIRECTMAP_SLOT_START 200
> > #define DIRECTMAP_VIRT_START SLOTN(DIRECTMAP_SLOT_START)
> > #define DIRECTMAP_SIZE (SLOTN(DIRECTMAP_SLOT_END) -
> > SLOTN(DIRECTMAP_SLOT_START))
> >
> > +#define FIXMAP_BASE (BOOT_FDT_VIRT_START +
> > BOOT_FDT_VIRT_SIZE)
> > +#define FIXMAP_ADDR(n) (FIXMAP_BASE + (n) * PAGE_SIZE)
>
> Why exactly do you insert this here, and not adjacent to
> BOOT_FDT_VIRT_*,
> which it actually is adjacent with?
I tried to follow alphabetical order.
> Then ...
>
> > #define FRAMETABLE_SCALE_FACTOR (PAGE_SIZE/sizeof(struct
> > page_info))
> > #define FRAMETABLE_SIZE_IN_SLOTS (((DIRECTMAP_SIZE / SLOTN(1)) /
> > FRAMETABLE_SCALE_FACTOR) + 1)
>
> ... this would also stay next to DIRECTMAP_*, which it uses.
>
> > --- a/xen/arch/riscv/include/asm/page.h
> > +++ b/xen/arch/riscv/include/asm/page.h
> > @@ -81,6 +81,13 @@ static inline void flush_page_to_ram(unsigned
> > long mfn, bool sync_icache)
> > BUG_ON("unimplemented");
> > }
> >
> > +/* Write a pagetable entry. */
> > +static inline void write_pte(pte_t *p, pte_t pte)
> > +{
> > + *p = pte;
> > + asm volatile ("sfence.vma");
>
> When they don't have operands, asm()-s are volatile anyway (being
> explicit
> about this may still be desirable, yes). But: Can you get away
> without
> operands here? Don't you need a memory clobber for the fence to
> actually
> remain where it is needed?
It should be "::memory" here. Thanks.
>
> Also, nit (style): Blanks missing.
>
> > --- a/xen/arch/riscv/mm.c
> > +++ b/xen/arch/riscv/mm.c
> > @@ -49,6 +49,9 @@ stage1_pgtbl_root[PAGETABLE_ENTRIES];
> > pte_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
> > stage1_pgtbl_nonroot[PGTBL_INITIAL_COUNT * PAGETABLE_ENTRIES];
> >
> > +pte_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
> > +xen_fixmap[PAGETABLE_ENTRIES];
>
> Any reason this cannot be static?
It will be used by pmap:
static inline void arch_pmap_map(unsigned int slot, mfn_t mfn)
{
pte_t *entry = _fixmap[slot];
pte_t pte;
ASSERT(!pte_is_valid(*entry));
pte = mfn_to_xen_entry(mfn, PAGE_HYPERVISOR_RW);
pte.pte |= PTE_LEAF_DEFAULT;
write_pte(entry, pte);
}
static inline void arch_pmap_unmap(unsigned int slot)
{
pte_t pte = {};
write_pte(_fixmap[slot], pte);
}
~ Oleksii
Re: [PATCH v2 4/8] xen/riscv: setup fixmap mapping
Hi Julien,
On Sun, 2024-07-21 at 09:46 +0100, Julien Grall wrote:
> Hi Oleksii,
>
> On 12/07/2024 17:22, Oleksii Kurochko wrote:
> > Introduce a function to set up fixmap mappings and L0 page
> > table for fixmap.
> >
> > Additionally, defines were introduced in riscv/config.h to
> > calculate the FIXMAP_BASE address.
> > This involved introducing BOOT_FDT_VIRT_{START, SIZE} and
> > XEN_SIZE, XEN_VIRT_END.
> >
> > Also, the check of Xen size was updated in the riscv/lds.S
> > script to use XEN_SIZE instead of a hardcoded constant.
> >
> > Signed-off-by: Oleksii Kurochko
> > ---
> > Changes in V2:
> > - newly introduced patch
> > ---
> > xen/arch/riscv/include/asm/config.h | 9 ++
> > xen/arch/riscv/include/asm/fixmap.h | 48
> > +
> > xen/arch/riscv/include/asm/mm.h | 2 ++
> > xen/arch/riscv/include/asm/page.h | 7 +
> > xen/arch/riscv/mm.c | 35 +
> > xen/arch/riscv/setup.c | 2 ++
> > xen/arch/riscv/xen.lds.S | 2 +-
> > 7 files changed, 104 insertions(+), 1 deletion(-)
> > create mode 100644 xen/arch/riscv/include/asm/fixmap.h
> >
> > diff --git a/xen/arch/riscv/include/asm/config.h
> > b/xen/arch/riscv/include/asm/config.h
> > index 50583aafdc..3275477c17 100644
> > --- a/xen/arch/riscv/include/asm/config.h
> > +++ b/xen/arch/riscv/include/asm/config.h
> > @@ -74,11 +74,20 @@
> > #error "unsupported RV_STAGE1_MODE"
> > #endif
> >
> > +#define XEN_SIZE MB(2)
>
> NIT: I would name it XEN_VIRT_SIZE to be consistent with the
> start/end.
>
> > +#define XEN_VIRT_END (XEN_VIRT_START + XEN_SIZE)
> Can we get away with not introducing *_END and just use START, SIZE?
> The
> reason I am asking is with "end" it is never clear whether it is
> inclusive or exclusive. For instance, here you use an exclusive range
> but ...
>
> > +
> > +#define BOOT_FDT_VIRT_START XEN_VIRT_END
> > +#define BOOT_FDT_VIRT_SIZE MB(4)
> > +
> > #define DIRECTMAP_SLOT_END 509
> > #define DIRECTMAP_SLOT_START 200
> > #define DIRECTMAP_VIRT_START SLOTN(DIRECTMAP_SLOT_START)
> > #define DIRECTMAP_SIZE (SLOTN(DIRECTMAP_SLOT_END) -
> > SLOTN(DIRECTMAP_SLOT_START))
> >
> > +#define FIXMAP_BASE (BOOT_FDT_VIRT_START +
> > BOOT_FDT_VIRT_SIZE)
> > +#define FIXMAP_ADDR(n) (FIXMAP_BASE + (n) * PAGE_SIZE)
> > +
> > #define FRAMETABLE_SCALE_FACTOR (PAGE_SIZE/sizeof(struct
> > page_info))
> > #define FRAMETABLE_SIZE_IN_SLOTS (((DIRECTMAP_SIZE / SLOTN(1)) /
> > FRAMETABLE_SCALE_FACTOR) + 1)
> >
> > diff --git a/xen/arch/riscv/include/asm/fixmap.h
> > b/xen/arch/riscv/include/asm/fixmap.h
> > new file mode 100644
> > index 00..fcfb82d69c
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/fixmap.h
> > @@ -0,0 +1,48 @@
> > +/*
> > + * fixmap.h: compile-time virtual memory allocation
> > + */
> > +#ifndef __ASM_FIXMAP_H
> > +#define __ASM_FIXMAP_H
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +/* Fixmap slots */
> > +#define FIX_PMAP_BEGIN (0) /* Start of PMAP */
> > +#define FIX_PMAP_END (FIX_PMAP_BEGIN + NUM_FIX_PMAP - 1) /* End of
> > PMAP */
>
> ... here is seems to be inclusive. Furthermore if you had 32-bit
> address
> space, it is also quite easy to have to create a region right at the
> top
> of it. So when END is exclusive, it would become 0.
>
> So on Arm, we decided to start to get rid of "end". I would consider
> to
> do the same on RISC-V for new functions.
I will refactor the code and get rid of "end".
>
> > +#define FIX_MISC (FIX_PMAP_END + 1) /* Ephemeral mappings of
> > hardware */
>
> Are you going to use this fixmap? If not, then I would consider to
> remove it.
Yes, it used now in copy_from_paddr():
/**
* copy_from_paddr - copy data from a physical address
* @dst: destination virtual address
* @paddr: source physical address
* @len: length to copy
*/
void __init copy_from_paddr(void *dst, paddr_t paddr, unsigned long
len)
{
void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
while (len) {
unsigned long l, s;
s = paddr & (PAGE_SIZE-1);
l = min(PAGE_SIZE - s, len);
set_fixmap(FIXMAP_MISC, maddr_to_mfn(paddr),
PAGE_HYPERVISOR_WC);
memcpy(d
Re: [PATCH v10 4/5] xen/riscv: enable GENERIC_BUG_FRAME
On Mon, 2024-07-22 at 13:02 +0200, Jan Beulich wrote:
> On 12.07.2024 18:18, Oleksii Kurochko wrote:
> > To have working BUG(), WARN(), ASSERT, run_in_exception_handler()
> > it is needed to enable GENERIC_BUG_FRAME.
> >
> > Also, is needed to be included for the reason that
> > panic() and
> > printk() are used in common/bug.c and RISC-V fails if it is not
> > included
> > with the following errors:
> > common/bug.c:69:9: error: implicit declaration of function
> > 'printk'
> > [-Werror=implicit-function-declaration]
> > 69 | printk("Xen WARN at %s%s:%d\n", prefix,
> > filename,
> > lineno);
> > | ^~
> > common/bug.c:77:9: error: implicit declaration of function
> > 'panic'
> > [-Werror=implicit-function-declaration]
> > 77 | panic("Xen BUG at %s%s:%d\n", prefix, filename,
> > lineno);
>
> I don't think the diagnostics themselves are needed here.
>
> > Signed-off-by: Oleksii Kurochko
> > ---
> > Changes in V10:
> > - put 'select GENERIC_BUG_FRAME' in "Config RISCV".
> > - rework do_trap() to not fetch an instruction in case when the
> > cause of trap
> > is BUG_insn.
>
> It's BUG_insn here, but then ...
>
> > @@ -103,7 +104,29 @@ static void do_unexpected_trap(const struct
> > cpu_user_regs *regs)
> >
> > void do_trap(struct cpu_user_regs *cpu_regs)
> > {
> > - do_unexpected_trap(cpu_regs);
> > + register_t pc = cpu_regs->sepc;
> > + unsigned long cause = csr_read(CSR_SCAUSE);
> > +
> > + switch ( cause )
> > + {
> > + case CAUSE_BREAKPOINT:
>
> ... BREAKPOINT here? Generally I'd deem something named "breakpoint"
> as
> debugging related (and hence continuable). I'd have expected
> CAUSE_ILLEGAL_INSTRUCTION here, but likely I'm missing something.
Agree, that is is confusing, but BUG_insn is defined as ebreak
instruction ( Linux kernel uses also ebreak ) and it generates
CAUSE_BREAKPOINT.
>
> > + if ( do_bug_frame(cpu_regs, pc) >= 0 )
> > + {
> > + if ( !pc ||
>
> In how far does this really need special casing? Isn't that case
> covered by
>
> > + !(is_kernel_text(pc + 1) || is_kernel_inittext(pc
> > + 1)) )
>
> ... these checks anyway?
Good point. We could drop it.
> And btw, why the "+ 1" in both function arguments?
There is no need for them anymore, just missed to drop +1.
~ Oleksii
>
> > + {
> > + printk("Something wrong with PC: 0x%lx\n", pc);
>
> Nit: %#lx please in situations like this.
>
> > + die();
> > + }
> > +
> > + cpu_regs->sepc += GET_INSN_LENGTH(*(uint16_t *)pc);
> > + return;
>
> This isn't needed, is it? You'd return anyway by ...
>
> > + }
> > +
> > + break;
>
> going through here to ...
>
> > + default:
> > + do_unexpected_trap(cpu_regs);
> > + }
> > }
>
> ... here.
>
> Two further nits for the default case: Please have a break statement
> there as well, and please have a blank line immediately up from it.
>
> Jan
Re: [PATCH v2 8/8] xen/riscv: introduce early_fdt_map()
On Mon, 2024-07-15 at 10:52 +0200, Jan Beulich wrote:
> On 12.07.2024 18:22, Oleksii Kurochko wrote:
> > --- a/xen/arch/riscv/include/asm/mm.h
> > +++ b/xen/arch/riscv/include/asm/mm.h
> > @@ -266,4 +266,6 @@ static inline unsigned int
> > arch_get_dma_bitsize(void)
> >
> > void setup_fixmap_mappings(void);
> >
> > +void* early_fdt_map(paddr_t fdt_paddr);
>
> Please can you take care to address comments on earlier versions
> before
> submitting a new one?
Sorry, missed that Nit comment where you suggested to switch
space/block and *.
>
> > @@ -435,3 +438,55 @@ inline pte_t mfn_to_xen_entry(mfn_t mfn,
> > unsigned int attr)
> >
> > return mfn_to_pte(mfn);
> > }
> > +
> > +void * __init early_fdt_map(paddr_t fdt_paddr)
> > +{
> > + /* We are using 2MB superpage for mapping the FDT */
> > + paddr_t base_paddr = fdt_paddr & XEN_PT_LEVEL_MAP_MASK(1);
> > + paddr_t offset;
> > + void *fdt_virt;
> > + uint32_t size;
> > + int rc;
> > +
> > + /*
> > + * Check whether the physical FDT address is set and meets the
> > minimum
> > + * alignment requirement. Since we are relying on
> > MIN_FDT_ALIGN to be at
> > + * least 8 bytes so that we always access the magic and size
> > fields
> > + * of the FDT header after mapping the first chunk, double
> > check if
> > + * that is indeed the case.
> > + */
> > + BUILD_BUG_ON(MIN_FDT_ALIGN < 8);
> > + if ( !fdt_paddr || fdt_paddr % MIN_FDT_ALIGN )
> > + return NULL;
> > +
> > + /* The FDT is mapped using 2MB superpage */
> > + BUILD_BUG_ON(BOOT_FDT_VIRT_START % SZ_2M);
>
> May I suggest that you use MB(2) instead of SZ_2M (not just here)? I
> think
> I had voiced opposition to the introduction of xen/sizes.h about 10
> years
> back, yet sadly it still landed in the tree. I for one think that our
> KB(),
> MB(), and GB() constructs are superior, and (I hope) free of Misra
> issues
> (unlike SZ_2G).
>
> > + rc = map_pages_to_xen(BOOT_FDT_VIRT_START,
> > maddr_to_mfn(base_paddr),
> > + SZ_2M >> PAGE_SHIFT,
> > + PAGE_HYPERVISOR_RO | _PAGE_BLOCK);
> > + if ( rc )
> > + panic("Unable to map the device-tree.\n");
> > +
> > + offset = fdt_paddr % XEN_PT_LEVEL_SIZE(1);
> > + fdt_virt = (void *)BOOT_FDT_VIRT_START + offset;
> > +
> > + if ( fdt_magic(fdt_virt) != FDT_MAGIC )
> > + return NULL;
> > +
> > + size = fdt_totalsize(fdt_virt);
> > + if ( size > BOOT_FDT_VIRT_SIZE )
> > + return NULL;
> > +
> > + if ( (offset + size) > SZ_2M )
> > + {
> > + rc = map_pages_to_xen(BOOT_FDT_VIRT_START + SZ_2M,
> > + maddr_to_mfn(base_paddr + SZ_2M),
> > + SZ_2M >> PAGE_SHIFT,
> > + PAGE_HYPERVISOR_RO | _PAGE_BLOCK);
> > + if ( rc )
> > + panic("Unable to map the device-tree\n");
> > + }
>
> Why this two part mapping? And why are you mapping perhaps much more
> than "size"?
I wasn't able to find if RISC-V has a requirement for alignment of FDT
address so I decided to follow Arm where FDT is required to be placed
on a 8-byte boundary, so FDT can cross a 2MB boundary, so the second
2MB page should be mapped if the FDT is crossing the 2MB boundary.
>
> > @@ -48,6 +49,14 @@ void __init noreturn start_xen(unsigned long
> > bootcpu_id,
> >
> > setup_fixmap_mappings();
> >
> > + device_tree_flattened = early_fdt_map(dtb_addr);
> > + if ( device_tree_flattened )
>
> Is this condition perhaps inverted?
Yes, you are right. It should be inverted.
Thanks.
~ Oleksii
>
> > + panic("Invalid device tree blob at physical address
> > %#lx.\n"
> > + "The DTB must be 8-byte aligned and must not exceed
> > %lld "
> > + "bytes in size.\n\n"
> > + "Please check your bootloader.\n",
> > + dtb_addr, BOOT_FDT_VIRT_SIZE);
> > +
> > printk("All set up\n");
> >
> > for ( ;; )
>
Re: [PATCH v6 1/8] xen/device-tree: Move Arm's setup.c bootinfo functions to common
Hi Michal, On Mon, 2024-07-15 at 12:15 +0200, Michal Orzel wrote: > Hi Oleksii, > > In general, the patch looks ok (apart from Jan comments). Just a > couple of remarks. > > On 12/07/2024 18:22, Oleksii Kurochko wrote: > > > > > > From: Shawn Anastasio > > > > Arm's setup.c contains a collection of functions for parsing memory > > map > > and other boot information from a device tree. Since these routines > > are > > generally useful on any architecture that supports device tree > > booting, > > move them into xen/common/device-tree. > > > > Suggested-by: Julien Grall > > Signed-off-by: Shawn Anastasio > > Signed-off-by: Oleksii Kurochko > > --- > > Changes in V6: > > - update the version of the patch to v6, to show that it is based > > on the work done by Shawn in the patch v4. > > --- > > Changes in V5: > > - add xen/include/xen/bootfdt.h to MAINTAINERS file. > > - drop message "Early device tree parsing and". > > - After rebase on top of the current staging the following changes > > were done: > > - init bootinfo variable in with > > BOOTINFO_INIT; > > - update the code of dt_unreserved_regions(): > > CONFIG_STATIC_SHM related changes and getting of > > reserved_mem > > bootinfo_get_shmem() ?? > > - update the code of meminfo_overlap_check(): > > add check ( INVALID_PADDR == bank_start ) to if case. > > - update the code of check_reserved_regions_overlap(): > > CONFIG_STATIC_SHM related changes. > > - struct bootinfo was updated ( CONFIG_STATIC_SHM changes ) > > - add shared_meminfo ( because of CONFIG_STATIC_SHM ) > > - struct struct membanks was update with __struct group so > > is > > neeeded to be included in bootfdt.h > > - move BOOTINFO_ACPI_INIT, BOOTINFO_SHMEM_INIT, BOOTINFO_INIT to > > generic bootfdt.h > > - bootinfo_get_reserved_mem(), bootinfo_get_mem(), > > bootinfo_get_acpi(), > > bootinfo_get_shmem() and bootinfo_get_shmem_extra() were moved > > to xen/bootfdt.h > > - s/arm32/CONFIG_SEPARATE_XENHEAP/ > > - add inclusion of because there are function in > > which > > are using container_of(). > > --- > > Changes in v4: > > - create new xen/include/bootinfo.h rather than relying on arch's > > asm/setup.h to provide required definitions for bootinfo.c > > - build bootinfo.c as .init.o > > - clean up and sort bootinfo.c's #includes > > - use CONFIG_SEPARATE_XENHEAP rather than CONFIG_ARM_32 to guard > > xenheap-specific behavior of populate_boot_allocator > > - (MAINTAINERS) include all of common/device-tree rather than > > just > > bootinfo.c > > --- > > MAINTAINERS | 2 + > > xen/arch/arm/include/asm/setup.h | 187 +--- > > xen/arch/arm/setup.c | 432 -- > > -- > > xen/common/Makefile | 1 + > > xen/common/device-tree/Makefile | 1 + > > xen/common/device-tree/bootinfo.c | 459 > > ++ > > xen/include/xen/bootfdt.h | 196 + > > 7 files changed, 660 insertions(+), 618 deletions(-) > > create mode 100644 xen/common/device-tree/Makefile > > create mode 100644 xen/common/device-tree/bootinfo.c > > create mode 100644 xen/include/xen/bootfdt.h > > > > [...] > > > diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h > > new file mode 100644 > > index 00..7cd45b3d4b > > --- /dev/null > > +++ b/xen/include/xen/bootfdt.h > > @@ -0,0 +1,196 @@ > > +#ifndef __XEN_BOOTFDT_H__ > AFAIR, to avoid violating MISRA rule 21.1, we should avoid > introducing new macros with double underscore. I will update that in the next patch version. > > > +#define __XEN_BOOTFDT_H__ > > + > > +#include > > +#include > > +#include > > + > > +#define MIN_FDT_ALIGN 8 > > +#define MAX_FDT_SIZE SZ_2M > 2M blob limit is Arm64 specific. What will be the limit on RISCV? > Shouldn't it be moved to some arch specific file? Agree, good point. I should drop that definition here and make it arch specific. I have to update my patch series where I am introducing BOOTFDT_MAX_SIZE ( or something similar ) in riscv/config.h. Thanks. ~ Oleksii
Xen 4.19-rc3
Hi all, Xen 4.19-rc3 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.19.0-rc3 For your convenience there is also a tarball and the signature at: https://downloads.xenproject.org/release/xen/4.19.0-rc3/xen-4.19.0-rc3.tar.gz And the signature is at: https://downloads.xenproject.org/release/xen/4.19.0-rc3/xen-4.19.0-rc3.tar.gz.sig Please send bug reports and test reports to xen-devel@lists.xenproject.org<mailto:xen-devel@lists.xenproject.org>. When sending bug reports, please CC relevant maintainers and me (oleskii.kuroc...@gmail.com<mailto:oleskii.kuroc...@gmail.com). Best regards, Oleksii
Re: [PATCH 10/12] CI: Introduce debian:11/12-riscv64 containers
On Fri, 2024-07-12 at 13:30 +0100, Andrew Cooper wrote: > On 12/07/2024 12:39 pm, Oleksii wrote: > > On Thu, 2024-07-11 at 12:15 +0100, Andrew Cooper wrote: > > > For starters, they're slightly smaller: > > > > > > $ docker image list > > > registry.gitlab.com/xen-project/xen/debian 12- > > > riscv64 > > > 772MB > > > registry.gitlab.com/xen-project/xen/debian 11- > > > riscv64 > > > 422MB > > Do we really need both 11-riscv64 and 12-riscv64? > > Need? No, not strictly. > > Want? Yes, absolutely. > > You always want at least 2 different toolchains worth of testing, or > what you will find happens is that you end up accidentally depending > on > a quirk of the single compiler your using, and that you discover this > at > some point in the future, rather than now(ish) when CI says no. > > At the moment, the RISC-V builds are very trivial and quick, so it > makes > a lot of sense to have a second toolchain. Before too much longer, > you'll want to get Clang working too. Agree, I should consider to add Clang. I will do that in the one of my nearest patch series. ~ Oleksii
[no subject]
Hi all, Xen 4.19-rc3 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.19.0-rc3 For your convenience there is also a tarball and the signature at: https://downloads.xenproject.org/release/xen/4.19.0-rc3/xen-4.19.0-rc3.tar.gz And the signature is at: https://downloads.xenproject.org/release/xen/4.19.0-rc3/xen-4.19.0-rc3.tar.gz.sig Please send bug reports and test reports to xen-devel@lists.xenproject.org<mailto:xen-devel@lists.xenproject.org>. When sending bug reports, please CC relevant maintainers and me (oleskii.kuroc...@gmail.com<mailto:oleskii.kuroc...@gmail.com). Best regards, Oleksii
[PATCH v2 0/8] RISCV device tree mapping
Current patch series introduces device tree mapping for RISC-V and necessary things for that such as: - Fixmap mapping - pmap - Xen page table processing Also, it introduces common stuff for working with fdt which is based on the patches from [1]: [PATCH v4 2/6] xen/device-tree: Move Arm's setup.c bootinfo functions to common [PATCH v4 3/6] xen/common: Move Arm's bootfdt.c All changes which were done on top of Shawn's patches please find in "Changes" section of each patch. Also there is another one depenency: RISCV basic exception handling implementation [2] [1] https://lore.kernel.org/xen-devel/cover.1712893887.git.sanasta...@raptorengineering.com/ [2] https://lore.kernel.org/xen-devel/cover.1720799487.git.oleksii.kuroc...@gmail.com/T/#t --- Changes in v2: - Update the cover letter message - introduce fixmap mapping - introduce pmap - introduce CONFIG_GENREIC_PT - update use early_fdt_map() after MMU is enabled. --- Oleksii Kurochko (6): xen/riscv: enable CONFIG_HAS_DEVICE_TREE xen/riscv: setup fixmap mapping xen/riscv: introduce asm/pmap.h header xen/riscv: introduce generic Xen page table handling xen/riscv: select CONFIG_GENREIC_PT xen/riscv: introduce early_fdt_map() Shawn Anastasio (2): xen/device-tree: Move Arm's setup.c bootinfo functions to common xen/common: Move Arm's bootfdt.c to common MAINTAINERS| 2 + xen/arch/arm/Makefile | 1 - xen/arch/arm/bootfdt.c | 622 xen/arch/arm/include/asm/setup.h | 200 +--- xen/arch/arm/setup.c | 432 - xen/arch/riscv/Kconfig | 3 + xen/arch/riscv/include/asm/config.h| 9 + xen/arch/riscv/include/asm/fixmap.h| 48 ++ xen/arch/riscv/include/asm/mm.h| 13 + xen/arch/riscv/include/asm/page-bits.h | 45 ++ xen/arch/riscv/include/asm/page.h | 82 +++- xen/arch/riscv/include/asm/pmap.h | 28 ++ xen/arch/riscv/mm.c| 167 ++- xen/arch/riscv/setup.c | 11 + xen/arch/riscv/xen.lds.S | 2 +- xen/common/Kconfig | 5 + xen/common/Makefile| 2 + xen/common/device-tree/Makefile| 2 + xen/common/device-tree/bootfdt.c | 635 + xen/common/device-tree/bootinfo.c | 459 ++ xen/common/mmu/pt.c| 441 + xen/include/xen/bootfdt.h | 210 xen/include/xen/mm.h | 24 + 23 files changed, 2181 insertions(+), 1262 deletions(-) delete mode 100644 xen/arch/arm/bootfdt.c create mode 100644 xen/arch/riscv/include/asm/fixmap.h create mode 100644 xen/arch/riscv/include/asm/pmap.h create mode 100644 xen/common/device-tree/Makefile create mode 100644 xen/common/device-tree/bootfdt.c create mode 100644 xen/common/device-tree/bootinfo.c create mode 100644 xen/common/mmu/pt.c create mode 100644 xen/include/xen/bootfdt.h -- 2.45.2
[PATCH v2 7/8] xen/riscv: select CONFIG_GENREIC_PT
Enable GENERIC_PT functionalities for RISC-V and also introduce some
RISC-V specific functions necessary to make the GENERIC_PT code
work and compilable.
Signed-off-by: Oleksii Kurochko
---
Changes in V2:
- newly introduced patch
---
xen/arch/riscv/Kconfig | 1 +
xen/arch/riscv/include/asm/mm.h| 9
xen/arch/riscv/include/asm/page-bits.h | 45
xen/arch/riscv/include/asm/page.h | 73 +-
xen/arch/riscv/mm.c| 63 +++---
5 files changed, 184 insertions(+), 7 deletions(-)
diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig
index 0112aa8778..9827a12d34 100644
--- a/xen/arch/riscv/Kconfig
+++ b/xen/arch/riscv/Kconfig
@@ -2,6 +2,7 @@ config RISCV
def_bool y
select FUNCTION_ALIGNMENT_16B
select GENERIC_BUG_FRAME
+ select GENERIC_PT
select HAS_DEVICE_TREE
select HAS_PMAP
diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index a0bdc2bc3a..c54546c275 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -42,6 +42,8 @@ static inline void *maddr_to_virt(paddr_t ma)
#define virt_to_mfn(va) __virt_to_mfn(va)
#define mfn_to_virt(mfn)__mfn_to_virt(mfn)
+#define pte_get_mfn(pte) maddr_to_mfn(pte_to_paddr(pte))
+
struct page_info
{
/* Each frame can be threaded onto a doubly-linked list. */
@@ -238,6 +240,13 @@ static inline bool arch_mfns_in_directmap(unsigned long
mfn, unsigned long nr)
#define PFN_ORDER(pg) ((pg)->v.free.order)
+/*
+ * Generic code that works with page tables expects the page table
+ * levels to be numbered in the order L0 -> L1 -> ...;
+ * RISC-V uses the opposite enumeration: Lx -> L1 -> L0
+ */
+#define convert_level(level) (HYP_PT_ROOT_LEVEL - level)
+
extern unsigned char cpu0_boot_stack[];
void setup_initial_pagetables(void);
diff --git a/xen/arch/riscv/include/asm/page-bits.h
b/xen/arch/riscv/include/asm/page-bits.h
index 8f1f474371..1d3a0adda6 100644
--- a/xen/arch/riscv/include/asm/page-bits.h
+++ b/xen/arch/riscv/include/asm/page-bits.h
@@ -3,6 +3,51 @@
#ifndef __RISCV_PAGE_BITS_H__
#define __RISCV_PAGE_BITS_H__
+/*
+ * PTE format:
+ * | XLEN-1 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
+ * PFN reserved for SW D A G U X W R V
+ */
+
+#define _PAGE_PRESENT BIT(0, UL)
+#define _PAGE_READ BIT(1, UL)/* Readable */
+#define _PAGE_WRITE BIT(2, UL)/* Writable */
+#define _PAGE_EXEC BIT(3, UL)/* Executable */
+#define _PAGE_USER BIT(4, UL)/* User */
+#define _PAGE_GLOBALBIT(5, UL)/* Global */
+#define _PAGE_ACCESSED BIT(6, UL)/* Set by hardware on any access */
+#define _PAGE_DIRTY BIT(7, UL)/* Set by hardware on any write */
+#define _PAGE_SOFT BIT(8, UL)/* Reserved for software */
+
+/*
+ * There is no such bits in PTE format for RISC-V.
+ * Most of the definition below are just to make PT generic code happy,
+ * except _PAGE_BLOCK which is used to map 2 MB page table entries.
+ */
+#define _PAGE_BLOCK BIT(9, UL)
+#define _PAGE_CONTIGBIT(10, UL)
+#define _PAGE_POPULATE BIT(11, UL)
+#define MT_NORMAL BIT(12, UL)
+
+/* Set of bits to preserve across pte_modify() */
+#define _PAGE_CHG_MASK (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ | \
+ _PAGE_WRITE | _PAGE_EXEC | \
+ _PAGE_USER | _PAGE_GLOBAL))
+
+#define PAGE_AI_MASK(x) ((x) & _PAGE_CHG_MASK)
+
+#define _PAGE_W_BIT 2
+#define _PAGE_XN_BIT3
+#define _PAGE_RO_BIT1
+
+/* TODO: move to somewhere generic part/header ? */
+#define _PAGE_XN(1U << _PAGE_XN_BIT)
+#define _PAGE_RO(1U << _PAGE_RO_BIT)
+#define _PAGE_W (1U << _PAGE_W_BIT)
+#define PAGE_XN_MASK(x) (((x) >> _PAGE_XN_BIT) & 0x1U)
+#define PAGE_RO_MASK(x) (((x) >> _PAGE_RO_BIT) & 0x1U)
+#define PAGE_W_MASK(x) (((x) >> _PAGE_W_BIT) & 0x1U)
+
#define PAGE_SHIFT 12 /* 4 KiB Pages */
#define PADDR_BITS 56 /* 44-bit PPN */
diff --git a/xen/arch/riscv/include/asm/page.h
b/xen/arch/riscv/include/asm/page.h
index 339074d502..bb2da05693 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -33,6 +33,7 @@
#define PTE_LEAF_DEFAULT(PTE_VALID | PTE_READABLE | PTE_WRITABLE)
#define PTE_TABLE (PTE_VALID)
+#define PAGE_HYPERVISOR_RO (PTE_VALID | PTE_READABLE)
#define PAGE_HYPERVISOR_RW (PTE_VALID | PTE_READABLE | PTE_WRITABLE)
#define PAGE_HYPERVISOR PAGE_HYPERVISOR_RW
@@ -42,13 +43,68 @@
#define pt_index(lvl, va) (pt_linear_offset((lvl), (va)) & VPN_MASK)
-/* Page Table entry */
+#define FIRST_SIZE (XEN_PT_LEVEL_SIZE(2))
+
+#define TABLE_OFFSET(offs) (_AT(unsigned int, offs) & ((_AC(1, U) <<
PAGETAB
[PATCH v2 8/8] xen/riscv: introduce early_fdt_map()
Introduce function which allows to map FDT to Xen.
Also, initialization of device_tree_flattened happens using early_fdt_map.
Signed-off-by: Oleksii Kurochko
---
Changes in V2:
- rework early_fdt_map to use map_pages_to_xen()
- move call early_fdt_map() to C code after MMU is enabled.
---
xen/arch/riscv/include/asm/mm.h | 2 ++
xen/arch/riscv/mm.c | 55 +
xen/arch/riscv/setup.c | 9 ++
3 files changed, 66 insertions(+)
diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index c54546c275..a12ef5bb63 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -266,4 +266,6 @@ static inline unsigned int arch_get_dma_bitsize(void)
void setup_fixmap_mappings(void);
+void* early_fdt_map(paddr_t fdt_paddr);
+
#endif /* _ASM_RISCV_MM_H */
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index 44f36359c8..428c26b636 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -1,13 +1,16 @@
/* SPDX-License-Identifier: GPL-2.0-only */
+#include
#include
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
#include
#include
@@ -435,3 +438,55 @@ inline pte_t mfn_to_xen_entry(mfn_t mfn, unsigned int attr)
return mfn_to_pte(mfn);
}
+
+void * __init early_fdt_map(paddr_t fdt_paddr)
+{
+/* We are using 2MB superpage for mapping the FDT */
+paddr_t base_paddr = fdt_paddr & XEN_PT_LEVEL_MAP_MASK(1);
+paddr_t offset;
+void *fdt_virt;
+uint32_t size;
+int rc;
+
+/*
+ * Check whether the physical FDT address is set and meets the minimum
+ * alignment requirement. Since we are relying on MIN_FDT_ALIGN to be at
+ * least 8 bytes so that we always access the magic and size fields
+ * of the FDT header after mapping the first chunk, double check if
+ * that is indeed the case.
+ */
+BUILD_BUG_ON(MIN_FDT_ALIGN < 8);
+if ( !fdt_paddr || fdt_paddr % MIN_FDT_ALIGN )
+return NULL;
+
+/* The FDT is mapped using 2MB superpage */
+BUILD_BUG_ON(BOOT_FDT_VIRT_START % SZ_2M);
+
+rc = map_pages_to_xen(BOOT_FDT_VIRT_START, maddr_to_mfn(base_paddr),
+ SZ_2M >> PAGE_SHIFT,
+ PAGE_HYPERVISOR_RO | _PAGE_BLOCK);
+if ( rc )
+panic("Unable to map the device-tree.\n");
+
+offset = fdt_paddr % XEN_PT_LEVEL_SIZE(1);
+fdt_virt = (void *)BOOT_FDT_VIRT_START + offset;
+
+if ( fdt_magic(fdt_virt) != FDT_MAGIC )
+return NULL;
+
+size = fdt_totalsize(fdt_virt);
+if ( size > BOOT_FDT_VIRT_SIZE )
+return NULL;
+
+if ( (offset + size) > SZ_2M )
+{
+rc = map_pages_to_xen(BOOT_FDT_VIRT_START + SZ_2M,
+ maddr_to_mfn(base_paddr + SZ_2M),
+ SZ_2M >> PAGE_SHIFT,
+ PAGE_HYPERVISOR_RO | _PAGE_BLOCK);
+if ( rc )
+panic("Unable to map the device-tree\n");
+}
+
+return fdt_virt;
+}
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 13f0e8c77d..21628b7300 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -2,6 +2,7 @@
#include
#include
+#include
#include
#include
@@ -48,6 +49,14 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
setup_fixmap_mappings();
+device_tree_flattened = early_fdt_map(dtb_addr);
+if ( device_tree_flattened )
+panic("Invalid device tree blob at physical address %#lx.\n"
+ "The DTB must be 8-byte aligned and must not exceed %lld "
+ "bytes in size.\n\n"
+ "Please check your bootloader.\n",
+ dtb_addr, BOOT_FDT_VIRT_SIZE);
+
printk("All set up\n");
for ( ;; )
--
2.45.2
[PATCH v6 2/8] xen/common: Move Arm's bootfdt.c to common
From: Shawn Anastasio
Move Arm's bootfdt.c to xen/common so that it can be used by other
device tree architectures like PPC and RISCV.
Suggested-by: Julien Grall
Signed-off-by: Shawn Anastasio
Acked-by: Julien Grall
Signed-off-by: Oleksii Kurochko
---
Changes in V6:
- update the version of the patch to v6, to show that it is based
on the work done by Shawn in the patch v4.
---
Changes in v5:
- add guard #ifdef CONFIG_STATIC_SHM around inclusion of
in common/device-tree/bootfdt.c.
- add stub for process_shm_node() in case CONFIG_STATIC_SHM isn't enabled.
- add guard around #ifdef CONFIG_STATIC_SHM aroud early_print_info_shmem() in
early_print_info().
---
Changes in v4:
- move function prototypes to patch 2's xen/include/bootfdt.h
- clean up #includes
---
xen/arch/arm/Makefile| 1 -
xen/arch/arm/bootfdt.c | 622 --
xen/arch/arm/include/asm/setup.h | 13 -
xen/common/device-tree/Makefile | 1 +
xen/common/device-tree/bootfdt.c | 635 +++
xen/include/xen/bootfdt.h| 14 +
6 files changed, 650 insertions(+), 636 deletions(-)
delete mode 100644 xen/arch/arm/bootfdt.c
create mode 100644 xen/common/device-tree/bootfdt.c
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 45dc29ea53..da9c979dc4 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -10,7 +10,6 @@ obj-$(CONFIG_TEE) += tee/
obj-$(CONFIG_HAS_VPCI) += vpci.o
obj-$(CONFIG_HAS_ALTERNATIVE) += alternative.o
-obj-y += bootfdt.init.o
obj-y += cpuerrata.o
obj-y += cpufeature.o
obj-y += decode.o
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
deleted file mode 100644
index 6e060111d9..00
--- a/xen/arch/arm/bootfdt.c
+++ /dev/null
@@ -1,622 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * Early Device Tree
- *
- * Copyright (C) 2012-2014 Citrix Systems, Inc.
- */
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-static void __init __maybe_unused build_assertions(void)
-{
-/*
- * Check that no padding is between struct membanks "bank" flexible array
- * member and struct meminfo "bank" member
- */
-BUILD_BUG_ON((offsetof(struct membanks, bank) !=
- offsetof(struct meminfo, bank)));
-/* Ensure "struct membanks" is 8-byte aligned */
-BUILD_BUG_ON(alignof(struct membanks) != 8);
-}
-
-static bool __init device_tree_node_is_available(const void *fdt, int node)
-{
-const char *status;
-int len;
-
-status = fdt_getprop(fdt, node, "status", );
-if ( !status )
-return true;
-
-if ( len > 0 )
-{
-if ( !strcmp(status, "ok") || !strcmp(status, "okay") )
-return true;
-}
-
-return false;
-}
-
-static bool __init device_tree_node_matches(const void *fdt, int node,
-const char *match)
-{
-const char *name;
-size_t match_len;
-
-name = fdt_get_name(fdt, node, NULL);
-match_len = strlen(match);
-
-/* Match both "match" and "match@..." patterns but not
- "match-foo". */
-return strncmp(name, match, match_len) == 0
-&& (name[match_len] == '@' || name[match_len] == '\0');
-}
-
-static bool __init device_tree_node_compatible(const void *fdt, int node,
- const char *match)
-{
-int len, l;
-const void *prop;
-
-prop = fdt_getprop(fdt, node, "compatible", );
-if ( prop == NULL )
-return false;
-
-while ( len > 0 ) {
-if ( !dt_compat_cmp(prop, match) )
-return true;
-l = strlen(prop) + 1;
-prop += l;
-len -= l;
-}
-
-return false;
-}
-
-void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cells,
-uint32_t size_cells, paddr_t *start,
-paddr_t *size)
-{
-uint64_t dt_start, dt_size;
-
-/*
- * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit.
- * Thus, there is an implicit cast from uint64_t to paddr_t.
- */
-dt_start = dt_next_cell(address_cells, cell);
-dt_size = dt_next_cell(size_cells, cell);
-
-if ( dt_start != (paddr_t)dt_start )
-{
-printk("Physical address greater than max width supported\n");
-WARN();
-}
-
-if ( dt_size != (paddr_t)dt_size )
-{
-printk("Physical size greater than max width supported\n");
-WARN();
-}
-
-/*
- * Xen will truncate the address/size if it is greater than the maximum
- * supported width and it will give an appropriate warning.
- */
-*start = dt_start;
-*size = dt_size;
-}
-
-static int __init device_tree_get_meminfo(const void *fdt, int nod
[PATCH v6 1/8] xen/device-tree: Move Arm's setup.c bootinfo functions to common
From: Shawn Anastasio
Arm's setup.c contains a collection of functions for parsing memory map
and other boot information from a device tree. Since these routines are
generally useful on any architecture that supports device tree booting,
move them into xen/common/device-tree.
Suggested-by: Julien Grall
Signed-off-by: Shawn Anastasio
Signed-off-by: Oleksii Kurochko
---
Changes in V6:
- update the version of the patch to v6, to show that it is based
on the work done by Shawn in the patch v4.
---
Changes in V5:
- add xen/include/xen/bootfdt.h to MAINTAINERS file.
- drop message "Early device tree parsing and".
- After rebase on top of the current staging the following changes were done:
- init bootinfo variable in with
BOOTINFO_INIT;
- update the code of dt_unreserved_regions():
CONFIG_STATIC_SHM related changes and getting of reserved_mem
bootinfo_get_shmem() ??
- update the code of meminfo_overlap_check():
add check ( INVALID_PADDR == bank_start ) to if case.
- update the code of check_reserved_regions_overlap():
CONFIG_STATIC_SHM related changes.
- struct bootinfo was updated ( CONFIG_STATIC_SHM changes )
- add shared_meminfo ( because of CONFIG_STATIC_SHM )
- struct struct membanks was update with __struct group so is
neeeded to be included in bootfdt.h
- move BOOTINFO_ACPI_INIT, BOOTINFO_SHMEM_INIT, BOOTINFO_INIT to generic
bootfdt.h
- bootinfo_get_reserved_mem(), bootinfo_get_mem(), bootinfo_get_acpi(),
bootinfo_get_shmem() and bootinfo_get_shmem_extra() were moved to
xen/bootfdt.h
- s/arm32/CONFIG_SEPARATE_XENHEAP/
- add inclusion of because there are function in
which
are using container_of().
---
Changes in v4:
- create new xen/include/bootinfo.h rather than relying on arch's
asm/setup.h to provide required definitions for bootinfo.c
- build bootinfo.c as .init.o
- clean up and sort bootinfo.c's #includes
- use CONFIG_SEPARATE_XENHEAP rather than CONFIG_ARM_32 to guard
xenheap-specific behavior of populate_boot_allocator
- (MAINTAINERS) include all of common/device-tree rather than just
bootinfo.c
---
MAINTAINERS | 2 +
xen/arch/arm/include/asm/setup.h | 187 +---
xen/arch/arm/setup.c | 432
xen/common/Makefile | 1 +
xen/common/device-tree/Makefile | 1 +
xen/common/device-tree/bootinfo.c | 459 ++
xen/include/xen/bootfdt.h | 196 +
7 files changed, 660 insertions(+), 618 deletions(-)
create mode 100644 xen/common/device-tree/Makefile
create mode 100644 xen/common/device-tree/bootinfo.c
create mode 100644 xen/include/xen/bootfdt.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 2b0c894527..505915b6b6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -295,9 +295,11 @@ M: Stefano Stabellini
M: Julien Grall
S: Supported
F: xen/common/libfdt/
+F: xen/common/device-tree/
F: xen/common/device_tree.c
F: xen/common/dt-overlay.c
F: xen/include/xen/libfdt/
+F: xen/include/xen/bootfdt.h
F: xen/include/xen/device_tree.h
F: xen/drivers/passthrough/device_tree.c
diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index c34179da93..051e796716 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -3,159 +3,9 @@
#include
#include
+#include
#include
-#define MIN_FDT_ALIGN 8
-#define MAX_FDT_SIZE SZ_2M
-
-#define NR_MEM_BANKS 256
-#define NR_SHMEM_BANKS 32
-
-#define MAX_MODULES 32 /* Current maximum useful modules */
-
-typedef enum {
-BOOTMOD_XEN,
-BOOTMOD_FDT,
-BOOTMOD_KERNEL,
-BOOTMOD_RAMDISK,
-BOOTMOD_XSM,
-BOOTMOD_GUEST_DTB,
-BOOTMOD_UNKNOWN
-} bootmodule_kind;
-
-enum membank_type {
-/*
- * The MEMBANK_DEFAULT type refers to either reserved memory for the
- * device/firmware (when the bank is in 'reserved_mem') or any RAM (when
- * the bank is in 'mem').
- */
-MEMBANK_DEFAULT,
-/*
- * The MEMBANK_STATIC_DOMAIN type is used to indicate whether the memory
- * bank is bound to a static Xen domain. It is only valid when the bank
- * is in reserved_mem.
- */
-MEMBANK_STATIC_DOMAIN,
-/*
- * The MEMBANK_STATIC_HEAP type is used to indicate whether the memory
- * bank is reserved as static heap. It is only valid when the bank is
- * in reserved_mem.
- */
-MEMBANK_STATIC_HEAP,
-/*
- * The MEMBANK_FDT_RESVMEM type is used to indicate whether the memory
- * bank is from the FDT reserve map.
- */
-MEMBANK_FDT_RESVMEM,
-};
-
-/* Indicates the maximum number of characters(\0 included) for shm_id */
-#define MAX_SHM_ID_LENGTH 16
-
-struct shmem_membank_extra {
-char shm_id[MAX_SHM_ID_LENGTH];
-unsigned int nr_shm_borrowers;
-};
-
-struct membank {
-paddr_t start;
-paddr_t size;
-union {
-
[PATCH v2 6/8] xen/riscv: introduce generic Xen page table handling
At least, between Arm and RISC-V most of the code related to Xen page
table handling are common.
This GENERIC_PT code is based on Arm's arm/mmu/pt.c except some minor
changes such as introduction of the following functions:
* get_root_page()
* xen_pt_check_contig()
* set_pte_table_bit()
* sanity_arch_specific_pte_checks()
* get_contig_bit()
* set_pte_permissions()
* flush_xen_tlb_range_va()
It was done because not every functions has the generic pte_flags and
it could be a different positions of the PTE bits in a PTE.
Signed-off-by: Oleksii Kurochko
---
Changes in V2:
- newly introduced patch
---
xen/common/Kconfig | 5 +
xen/common/Makefile | 1 +
xen/common/mmu/pt.c | 441 +++
xen/include/xen/mm.h | 24 +++
4 files changed, 471 insertions(+)
create mode 100644 xen/common/mmu/pt.c
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 565ceda741..6534b77cc9 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -47,6 +47,11 @@ config ARCH_MAP_DOMAIN_PAGE
config GENERIC_BUG_FRAME
bool
+config GENERIC_PT
+ bool
+ help
+ Introduces common function to work with page table when MMU is
enabled.
+
config HAS_ALTERNATIVE
bool
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 21359bab02..e1fb6a5fe8 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_ARGO) += argo.o
obj-y += bitmap.o
obj-bin-$(CONFIG_SELF_TESTS) += bitops.init.o
obj-$(CONFIG_GENERIC_BUG_FRAME) += bug.o
+obj-$(CONFIG_GENERIC_PT) += mmu/pt.o
obj-$(CONFIG_HYPFS_CONFIG) += config_data.o
obj-$(CONFIG_CORE_PARKING) += core_parking.o
obj-y += cpu.o
diff --git a/xen/common/mmu/pt.c b/xen/common/mmu/pt.c
new file mode 100644
index 00..7e488eba24
--- /dev/null
+++ b/xen/common/mmu/pt.c
@@ -0,0 +1,441 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Sanity check of the entry */
+static bool xen_pt_check_entry(pte_t entry, mfn_t mfn, unsigned int level,
+ unsigned int flags)
+{
+/* Sanity check when modifying an entry. */
+if ( (flags & _PAGE_PRESENT) && mfn_eq(mfn, INVALID_MFN) )
+{
+/* We don't allow modifying an invalid entry. */
+if ( !pte_is_valid(entry) )
+{
+printk("Modifying invalid entry is not allowed.\n");
+return false;
+}
+
+/* We don't allow modifying a table entry */
+if ( !pte_is_mapping(entry, level) )
+{
+printk("Modifying a table entry is not allowed.\n");
+return false;
+}
+
+if ( !sanity_arch_specific_pte_checks(entry) )
+{
+printk("sanity check failed\n");
+return false;
+}
+}
+/* Sanity check when inserting a mapping */
+else if ( flags & _PAGE_PRESENT )
+{
+/* We should be here with a valid MFN. */
+ASSERT(!mfn_eq(mfn, INVALID_MFN));
+
+/*
+ * We don't allow replacing any valid entry.
+ *
+ * Note that the function xen_pt_update() relies on this
+ * assumption and will skip the TLB flush. The function will need
+ * to be updated if the check is relaxed.
+ */
+if ( pte_is_valid(entry) )
+{
+if ( pte_is_mapping(entry, level) )
+printk("Changing MFN for a valid entry is not allowed
(%#"PRI_mfn" -> %#"PRI_mfn").\n",
+ mfn_x(pte_get_mfn(entry)), mfn_x(mfn));
+else
+printk("Trying to replace a table with a mapping.\n");
+return false;
+}
+}
+/* Sanity check when removing a mapping. */
+else if ( (flags & (_PAGE_PRESENT|_PAGE_POPULATE)) == 0 )
+{
+/* We should be here with an invalid MFN. */
+ASSERT(mfn_eq(mfn, INVALID_MFN));
+
+/* We don't allow removing a table */
+if ( pte_is_table(entry, level) )
+{
+printk("Removing a table is not allowed.\n");
+return false;
+}
+
+if ( get_contig_bit(entry) )
+{
+printk("Removing entry with contiguous bit set is not allowed.\n");
+return false;
+}
+}
+/* Sanity check when populating the page-table. No check so far. */
+else
+{
+ASSERT(flags & _PAGE_POPULATE);
+/* We should be here with an invalid MFN */
+ASSERT(mfn_eq(mfn, INVALID_MFN));
+}
+
+return true;
+}
+
+static pte_t *xen_map_table(mfn_t mfn)
+{
+/*
+ * During early boot, map_domain_page() may be unusable. Use the
+ * PMAP to map temporarily a page-table.
+ */
+if ( system_state == SYS_STATE_early_boot )
+return pmap_map(mfn);
+
+return map_domain_page(mfn);
+}
+
+static void xen_unmap_table(const pt
[PATCH v2 4/8] xen/riscv: setup fixmap mapping
Introduce a function to set up fixmap mappings and L0 page
table for fixmap.
Additionally, defines were introduced in riscv/config.h to
calculate the FIXMAP_BASE address.
This involved introducing BOOT_FDT_VIRT_{START, SIZE} and
XEN_SIZE, XEN_VIRT_END.
Also, the check of Xen size was updated in the riscv/lds.S
script to use XEN_SIZE instead of a hardcoded constant.
Signed-off-by: Oleksii Kurochko
---
Changes in V2:
- newly introduced patch
---
xen/arch/riscv/include/asm/config.h | 9 ++
xen/arch/riscv/include/asm/fixmap.h | 48 +
xen/arch/riscv/include/asm/mm.h | 2 ++
xen/arch/riscv/include/asm/page.h | 7 +
xen/arch/riscv/mm.c | 35 +
xen/arch/riscv/setup.c | 2 ++
xen/arch/riscv/xen.lds.S| 2 +-
7 files changed, 104 insertions(+), 1 deletion(-)
create mode 100644 xen/arch/riscv/include/asm/fixmap.h
diff --git a/xen/arch/riscv/include/asm/config.h
b/xen/arch/riscv/include/asm/config.h
index 50583aafdc..3275477c17 100644
--- a/xen/arch/riscv/include/asm/config.h
+++ b/xen/arch/riscv/include/asm/config.h
@@ -74,11 +74,20 @@
#error "unsupported RV_STAGE1_MODE"
#endif
+#define XEN_SIZEMB(2)
+#define XEN_VIRT_END(XEN_VIRT_START + XEN_SIZE)
+
+#define BOOT_FDT_VIRT_START XEN_VIRT_END
+#define BOOT_FDT_VIRT_SIZE MB(4)
+
#define DIRECTMAP_SLOT_END 509
#define DIRECTMAP_SLOT_START200
#define DIRECTMAP_VIRT_STARTSLOTN(DIRECTMAP_SLOT_START)
#define DIRECTMAP_SIZE (SLOTN(DIRECTMAP_SLOT_END) -
SLOTN(DIRECTMAP_SLOT_START))
+#define FIXMAP_BASE (BOOT_FDT_VIRT_START + BOOT_FDT_VIRT_SIZE)
+#define FIXMAP_ADDR(n) (FIXMAP_BASE + (n) * PAGE_SIZE)
+
#define FRAMETABLE_SCALE_FACTOR (PAGE_SIZE/sizeof(struct page_info))
#define FRAMETABLE_SIZE_IN_SLOTS (((DIRECTMAP_SIZE / SLOTN(1)) /
FRAMETABLE_SCALE_FACTOR) + 1)
diff --git a/xen/arch/riscv/include/asm/fixmap.h
b/xen/arch/riscv/include/asm/fixmap.h
new file mode 100644
index 00..fcfb82d69c
--- /dev/null
+++ b/xen/arch/riscv/include/asm/fixmap.h
@@ -0,0 +1,48 @@
+/*
+ * fixmap.h: compile-time virtual memory allocation
+ */
+#ifndef __ASM_FIXMAP_H
+#define __ASM_FIXMAP_H
+
+#include
+#include
+#include
+
+#include
+
+/* Fixmap slots */
+#define FIX_PMAP_BEGIN (0) /* Start of PMAP */
+#define FIX_PMAP_END (FIX_PMAP_BEGIN + NUM_FIX_PMAP - 1) /* End of PMAP */
+#define FIX_MISC (FIX_PMAP_END + 1) /* Ephemeral mappings of hardware */
+
+#define FIX_LAST FIX_MISC
+
+#define FIXADDR_START FIXMAP_ADDR(0)
+#define FIXADDR_TOP FIXMAP_ADDR(FIX_LAST)
+
+#ifndef __ASSEMBLY__
+
+/*
+ * Direct access to xen_fixmap[] should only happen when {set,
+ * clear}_fixmap() is unusable (e.g. where we would end up to
+ * recursively call the helpers).
+ */
+extern pte_t xen_fixmap[];
+
+/* Map a page in a fixmap entry */
+extern void set_fixmap(unsigned int map, mfn_t mfn, unsigned int attributes);
+/* Remove a mapping from a fixmap entry */
+extern void clear_fixmap(unsigned int map);
+
+#define fix_to_virt(slot) ((void *)FIXMAP_ADDR(slot))
+
+static inline unsigned int virt_to_fix(vaddr_t vaddr)
+{
+BUG_ON(vaddr >= FIXADDR_TOP || vaddr < FIXADDR_START);
+
+return ((vaddr - FIXADDR_START) >> PAGE_SHIFT);
+}
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __ASM_FIXMAP_H */
diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h
index 25af9e1aaa..a0bdc2bc3a 100644
--- a/xen/arch/riscv/include/asm/mm.h
+++ b/xen/arch/riscv/include/asm/mm.h
@@ -255,4 +255,6 @@ static inline unsigned int arch_get_dma_bitsize(void)
return 32; /* TODO */
}
+void setup_fixmap_mappings(void);
+
#endif /* _ASM_RISCV_MM_H */
diff --git a/xen/arch/riscv/include/asm/page.h
b/xen/arch/riscv/include/asm/page.h
index c831e16417..cbbf3656d1 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -81,6 +81,13 @@ static inline void flush_page_to_ram(unsigned long mfn, bool
sync_icache)
BUG_ON("unimplemented");
}
+/* Write a pagetable entry. */
+static inline void write_pte(pte_t *p, pte_t pte)
+{
+*p = pte;
+asm volatile ("sfence.vma");
+}
+
#endif /* __ASSEMBLY__ */
#endif /* _ASM_RISCV_PAGE_H */
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index 7d09e781bf..d69a174b5d 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -49,6 +49,9 @@ stage1_pgtbl_root[PAGETABLE_ENTRIES];
pte_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
stage1_pgtbl_nonroot[PGTBL_INITIAL_COUNT * PAGETABLE_ENTRIES];
+pte_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
+xen_fixmap[PAGETABLE_ENTRIES];
+
#define HANDLE_PGTBL(curr_lvl_num) \
index = pt_index(curr_lvl_num, page_addr); \
if ( pte_is_valid(pgtbl[index]) ) \
@@ -191,6 +194,38 @
[PATCH v2 5/8] xen/riscv: introduce asm/pmap.h header
Introduces arch_pmap_{un}map functions and select HAS_PMAP
for CONFIG_RISCV.
Additionaly it was necessary to introduce functions:
- mfn_to_xen_entry
- mfn_to_pte
Signed-off-by: Oleksii Kurochko
---
Changes in V2:
- newly introduced patch
---
xen/arch/riscv/Kconfig| 1 +
xen/arch/riscv/include/asm/page.h | 2 ++
xen/arch/riscv/include/asm/pmap.h | 28
xen/arch/riscv/mm.c | 14 ++
4 files changed, 45 insertions(+)
create mode 100644 xen/arch/riscv/include/asm/pmap.h
diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig
index 259eea8d3b..0112aa8778 100644
--- a/xen/arch/riscv/Kconfig
+++ b/xen/arch/riscv/Kconfig
@@ -3,6 +3,7 @@ config RISCV
select FUNCTION_ALIGNMENT_16B
select GENERIC_BUG_FRAME
select HAS_DEVICE_TREE
+ select HAS_PMAP
config RISCV_64
def_bool y
diff --git a/xen/arch/riscv/include/asm/page.h
b/xen/arch/riscv/include/asm/page.h
index cbbf3656d1..339074d502 100644
--- a/xen/arch/riscv/include/asm/page.h
+++ b/xen/arch/riscv/include/asm/page.h
@@ -51,6 +51,8 @@ typedef struct {
#endif
} pte_t;
+pte_t mfn_to_xen_entry(mfn_t mfn, unsigned int attr);
+
static inline pte_t paddr_to_pte(paddr_t paddr,
unsigned int permissions)
{
diff --git a/xen/arch/riscv/include/asm/pmap.h
b/xen/arch/riscv/include/asm/pmap.h
new file mode 100644
index 00..eb4c48515c
--- /dev/null
+++ b/xen/arch/riscv/include/asm/pmap.h
@@ -0,0 +1,28 @@
+#ifndef __ASM_PMAP_H__
+#define __ASM_PMAP_H__
+
+#include
+#include
+
+#include
+
+static inline void arch_pmap_map(unsigned int slot, mfn_t mfn)
+{
+pte_t *entry = _fixmap[slot];
+pte_t pte;
+
+ASSERT(!pte_is_valid(*entry));
+
+pte = mfn_to_xen_entry(mfn, PAGE_HYPERVISOR_RW);
+pte.pte |= PTE_LEAF_DEFAULT;
+write_pte(entry, pte);
+}
+
+static inline void arch_pmap_unmap(unsigned int slot)
+{
+pte_t pte = {};
+
+write_pte(_fixmap[slot], pte);
+}
+
+#endif /* __ASM_PMAP_H__ */
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index d69a174b5d..445319af08 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -370,3 +370,17 @@ int map_pages_to_xen(unsigned long virt,
BUG_ON("unimplemented");
return -1;
}
+
+static inline pte_t mfn_to_pte(mfn_t mfn)
+{
+unsigned long pte = mfn_x(mfn) << PTE_PPN_SHIFT;
+return (pte_t){ .pte = pte};
+}
+
+inline pte_t mfn_to_xen_entry(mfn_t mfn, unsigned int attr)
+{
+/* there is no attr field in RISC-V's pte */
+(void) attr;
+
+return mfn_to_pte(mfn);
+}
--
2.45.2
[PATCH v2 3/8] xen/riscv: enable CONFIG_HAS_DEVICE_TREE
Signed-off-by: Oleksii Kurochko --- Changes in V2: - move 'select HAS_DEVICE_TREE' to CONFIG_RISCV. --- Changes in V1: - new patch --- xen/arch/riscv/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig index f531e96657..259eea8d3b 100644 --- a/xen/arch/riscv/Kconfig +++ b/xen/arch/riscv/Kconfig @@ -2,6 +2,7 @@ config RISCV def_bool y select FUNCTION_ALIGNMENT_16B select GENERIC_BUG_FRAME + select HAS_DEVICE_TREE config RISCV_64 def_bool y -- 2.45.2
[PATCH v10 0/5]RISCV basic exception handling implementation
ic implementation
of macros from bug.h]
- Update commit messages
---
Changes in V2:
- take the latest riscv_encoding.h from OpenSBI, update it with Xen
related changes, and update the commit message with "Origin:"
tag and the commit message itself.
- add "Origin:" tag to the commit messag of the patch
[xen/riscv: add header].
- Remove the patch [xen/riscv: add early_printk_hnum() function] as the
functionality provided by the patch isn't used now.
- Refactor prcoess.h: move structure offset defines to asm-offsets.c,
change register_t to unsigned long.
- Refactor entry.S to use offsets defined in asm-offsets.C
- Rename {__,}handle_exception to handle_trap() and do_trap() to be more
consistent with RISC-V spec.
- Merge the pathc which introduces do_unexpected_trap() with the patch
[xen/riscv: introduce exception handlers implementation].
- Rename setup_trap_handler() to trap_init() and update correspondingly
the patches in the patch series.
- Refactor bug.h, remove bug_instr_t type from it.
- Refactor decode_trap_cause() function to be more optimization-friendly.
- Add two new empty headers: and as they are needed to
include which provides ARRAY_SIZE and other macros.
- Code style fixes.
---
Oleksii Kurochko (5):
xen/riscv: use printk() instead of early_printk()
xen/riscv: introduce decode_cause() stuff
xen/riscv: introduce trap_init()
xen/riscv: enable GENERIC_BUG_FRAME
xen/riscv: test basic exception handling stuff
xen/arch/riscv/Kconfig | 1 +
xen/arch/riscv/include/asm/traps.h | 1 +
xen/arch/riscv/setup.c | 25 ++-
xen/arch/riscv/traps.c | 115 -
xen/common/bug.c | 1 +
5 files changed, 140 insertions(+), 3 deletions(-)
--
2.45.2
[PATCH v10 2/5] xen/riscv: introduce decode_cause() stuff
The patch introduces stuff needed to decode a reason of an
exception.
Signed-off-by: Oleksii Kurochko
Acked-by: Alistair Francis
Acked-by: Jan Beulich
---
Changes in V10:
- add Acked-by: Jan Beulich
---
Changes in V9:
- This patch was reverted as breaks both release and randconfig builds.
I don't see the failures now. ( probably it was because of printk usage
which was not ready at that moment ).
- drop inclusion of and
- add for CAUSE_* in decode_trap_cause().
---
Changes in V8:
- fix typo in return string from decode_reserved_interrupt_cause
- add Acked-by: Alistair Francis
---
Changes in V7:
- Nothing changed. Only rebase.
---
Changes in V6:
- Remove usage of LINK_TO_LOAD() due to the MMU being enabled first.
- Change early_printk() to printk()
---
Changes in V5:
- Remove from riscv/traps/c as nothing would require
inclusion.
- decode_reserved_interrupt_cause(), decode_interrupt_cause(), decode_cause,
do_unexpected_trap()
were made as static they are expected to be used only in traps.c
- use LINK_TO_LOAD() for addresses which can be linker time relative.
---
Changes in V4:
- fix string in decode_reserved_interrupt_cause()
---
Changes in V3:
- Nothing changed
---
Changes in V2:
- Make decode_trap_cause() more optimization friendly.
- Merge the pathc which introduces do_unexpected_trap() to the current one.
---
xen/arch/riscv/traps.c | 80 +-
1 file changed, 79 insertions(+), 1 deletion(-)
diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c
index 5415cf8d90..37cec40dfa 100644
--- a/xen/arch/riscv/traps.c
+++ b/xen/arch/riscv/traps.c
@@ -9,13 +9,91 @@
#include
#include
+#include
#include
-void do_trap(struct cpu_user_regs *cpu_regs)
+static const char *decode_trap_cause(unsigned long cause)
+{
+static const char *const trap_causes[] = {
+[CAUSE_MISALIGNED_FETCH] = "Instruction Address Misaligned",
+[CAUSE_FETCH_ACCESS] = "Instruction Access Fault",
+[CAUSE_ILLEGAL_INSTRUCTION] = "Illegal Instruction",
+[CAUSE_BREAKPOINT] = "Breakpoint",
+[CAUSE_MISALIGNED_LOAD] = "Load Address Misaligned",
+[CAUSE_LOAD_ACCESS] = "Load Access Fault",
+[CAUSE_MISALIGNED_STORE] = "Store/AMO Address Misaligned",
+[CAUSE_STORE_ACCESS] = "Store/AMO Access Fault",
+[CAUSE_USER_ECALL] = "Environment Call from U-Mode",
+[CAUSE_SUPERVISOR_ECALL] = "Environment Call from S-Mode",
+[CAUSE_MACHINE_ECALL] = "Environment Call from M-Mode",
+[CAUSE_FETCH_PAGE_FAULT] = "Instruction Page Fault",
+[CAUSE_LOAD_PAGE_FAULT] = "Load Page Fault",
+[CAUSE_STORE_PAGE_FAULT] = "Store/AMO Page Fault",
+[CAUSE_FETCH_GUEST_PAGE_FAULT] = "Instruction Guest Page Fault",
+[CAUSE_LOAD_GUEST_PAGE_FAULT] = "Load Guest Page Fault",
+[CAUSE_VIRTUAL_INST_FAULT] = "Virtualized Instruction Fault",
+[CAUSE_STORE_GUEST_PAGE_FAULT] = "Guest Store/AMO Page Fault",
+};
+
+if ( cause < ARRAY_SIZE(trap_causes) && trap_causes[cause] )
+return trap_causes[cause];
+return "UNKNOWN";
+}
+
+static const char *decode_reserved_interrupt_cause(unsigned long irq_cause)
+{
+switch ( irq_cause )
+{
+case IRQ_M_SOFT:
+return "M-mode Software Interrupt";
+case IRQ_M_TIMER:
+return "M-mode Timer Interrupt";
+case IRQ_M_EXT:
+return "M-mode External Interrupt";
+default:
+return "UNKNOWN IRQ type";
+}
+}
+
+static const char *decode_interrupt_cause(unsigned long cause)
+{
+unsigned long irq_cause = cause & ~CAUSE_IRQ_FLAG;
+
+switch ( irq_cause )
+{
+case IRQ_S_SOFT:
+return "Supervisor Software Interrupt";
+case IRQ_S_TIMER:
+return "Supervisor Timer Interrupt";
+case IRQ_S_EXT:
+return "Supervisor External Interrupt";
+default:
+return decode_reserved_interrupt_cause(irq_cause);
+}
+}
+
+static const char *decode_cause(unsigned long cause)
+{
+if ( cause & CAUSE_IRQ_FLAG )
+return decode_interrupt_cause(cause);
+
+return decode_trap_cause(cause);
+}
+
+static void do_unexpected_trap(const struct cpu_user_regs *regs)
{
+unsigned long cause = csr_read(CSR_SCAUSE);
+
+printk("Unhandled exception: %s\n", decode_cause(cause));
+
die();
}
+void do_trap(struct cpu_user_regs *cpu_regs)
+{
+do_unexpected_trap(cpu_regs);
+}
+
void vcpu_show_execution_state(struct vcpu *v)
{
BUG_ON("unimplemented");
--
2.45.2
[PATCH v10 5/5] xen/riscv: test basic exception handling stuff
Signed-off-by: Oleksii Kurochko
Acked-by: Alistair Francis
---
Changes in V10:
- wrap test_macros_from_bug_h() under "#ifdef CONFIG_SELF_TESTS"
- update the commit title to: "xen/riscv: test basic exception handling stuff"
---
Changes in V9:
- s/early_printk/printk as common code is now available
---
Changes in V8:
- Nothing changed. Only rebase.
---
Changes in V6:
- Nothing changed. Only rebase.
---
Changes in V6:
- Nothing changed
---
Changes in V5:
- Nothing changed
---
Changes in V4:
- Add Acked-by: Alistair Francis
---
Changes in V3:
- Nothing changed
---
Changes in V2:
- Nothing changed
---
xen/arch/riscv/setup.c | 20
1 file changed, 20 insertions(+)
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index a6a29a1508..4defad68f4 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -19,6 +19,22 @@ void arch_get_xen_caps(xen_capabilities_info_t *info)
unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
__aligned(STACK_SIZE);
+#ifdef CONFIG_SELF_TESTS
+static void test_run_in_exception(const struct cpu_user_regs *regs)
+{
+printk("If you see this message, ");
+printk("run_in_exception_handler is most likely working\n");
+}
+
+static void test_macros_from_bug_h(void)
+{
+run_in_exception_handler(test_run_in_exception);
+WARN();
+printk("If you see this message, ");
+printk("WARN is most likely working\n");
+}
+#endif
+
void __init noreturn start_xen(unsigned long bootcpu_id,
paddr_t dtb_addr)
{
@@ -26,6 +42,10 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
trap_init();
+#ifdef CONFIG_SELF_TESTS
+test_macros_from_bug_h();
+#endif
+
printk("All set up\n");
for ( ;; )
--
2.45.2
[PATCH v10 4/5] xen/riscv: enable GENERIC_BUG_FRAME
To have working BUG(), WARN(), ASSERT, run_in_exception_handler()
it is needed to enable GENERIC_BUG_FRAME.
Also, is needed to be included for the reason that panic() and
printk() are used in common/bug.c and RISC-V fails if it is not included
with the following errors:
common/bug.c:69:9: error: implicit declaration of function 'printk'
[-Werror=implicit-function-declaration]
69 | printk("Xen WARN at %s%s:%d\n", prefix, filename,
lineno);
| ^~
common/bug.c:77:9: error: implicit declaration of function 'panic'
[-Werror=implicit-function-declaration]
77 | panic("Xen BUG at %s%s:%d\n", prefix, filename,
lineno);
Signed-off-by: Oleksii Kurochko
---
Changes in V10:
- put 'select GENERIC_BUG_FRAME' in "Config RISCV".
- rework do_trap() to not fetch an instruction in case when the cause of trap
is BUG_insn.
- drop read_instr() and is_valid_bug_insn().
- update the commit message.
---
Changes in V9:
- Rebase on the top of current staging.
- use GENERIC_BUG_FRAME as now we have common code available.
- add xen/lib.h to bug.c to fix a compilation error around printk.
- update the commit message.
- update the code of read_instr() in traps.c
- fold two-s if into 1 in do_trap.
---
Changes in V8:
- remove Pointless initializer of id.
- make bug_frames[] array constant.
- remove cast_to_bug_frame(addr).
- rename is_valig_bugaddr to is_valid_bug_insn().
- add check that read_instr is used only on xen code
- update the commit message.
---
Changes in V7:
- move to this patch the definition of cast_to_bug_frame() from the previous
patch.
- update the comment in bug.h.
- update the comment above do_bug_frame().
- fix code style.
- add comment to read_instr func.
- add space for bug_frames in lds.S.
---
Changes in V6:
- Avoid LINK_TO_LOAD() as bug.h functionality expected to be used
after MMU is enabled.
- Change early_printk() to printk()
---
Changes in V5:
- Remove "#include " from as there is no any need in
it anymore
- Update macros GET_INSN_LENGTH: remove UL and 'unsigned int len;' from it
- Remove " include " from risc/setup.c. it is not needed in the
current version of
the patch
- change an argument type from vaddr_t to uint32_t for is_valid_bugaddr and
introduce read_instr() to
read instruction properly as the length of qinstruction can be either 32 or
16 bits.
- Code style fixes
- update the comments before do_bug_frame() in riscv/trap.c
- Refactor is_valid_bugaddr() function.
- introduce macros cast_to_bug_frame(addr) to hide casts.
- use LINK_TO_LOAD() for addresses which are linker time relative.
---
Changes in V4:
- Updates in RISC-V's :
* Add explanatory comment about why there is only defined for 32-bits length
instructions and 16/32-bits BUG_INSN_{16,32}.
* Change 'unsigned long' to 'unsigned int' inside GET_INSN_LENGTH().
* Update declaration of is_valid_bugaddr(): switch return type from int to
bool
and the argument from 'unsigned int' to 'vaddr'.
- Updates in RISC-V's traps.c:
* replace /xen and /asm includes
* update definition of is_valid_bugaddr():switch return type from int to
bool
and the argument from 'unsigned int' to 'vaddr'. Code style inside
function
was updated too.
* do_bug_frame() refactoring:
* local variables start and bug became 'const struct bug_frame'
* bug_frames[] array became 'static const struct bug_frame[] = ...'
* remove all casts
* remove unneeded comments and add an explanatory comment that the
do_bug_frame()
will be switched to a generic one.
* do_trap() refactoring:
* read 16-bits value instead of 32-bits as compressed instruction can
be used and it might happen than only 16-bits may be accessible.
* code style updates
* re-use instr variable instead of re-reading instruction.
- Updates in setup.c:
* add blank line between xen/ and asm/ includes.
---
Changes in V3:
- Rebase the patch "xen/riscv: introduce an implementation of macros
from " on top of patch series [introduce generic implementation
of macros from bug.h]
---
Changes in V2:
- Remove __ in define namings
- Update run_in_exception_handler() with
register void *fn_ asm(__stringify(BUG_FN_REG)) = (fn);
- Remove bug_instr_t type and change it's usage to uint32_t
---
xen/arch/riscv/Kconfig | 1 +
xen/arch/riscv/traps.c | 25 -
xen/common/bug.c | 1 +
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig
index b4b354a778..f531e96657 100644
--- a/xen/arch/riscv/Kconfig
+++ b/xen/arch/riscv/Kconfig
@@ -1,6 +1,7 @@
config RISCV
def_bool y
select FUNCTION_ALIGNMENT_16B
+ select GENERIC_BUG_FRAME
config RISCV_64
def_bool y
diff --git a/xen/arch/riscv/traps.c b/xen/arch
[PATCH v10 1/5] xen/riscv: use printk() instead of early_printk()
As common code is available it is better to use printk() instead
of early_printk().
Also the printing of "Hello from RISC-V world" is dropped as
it is useless and "All set up is enough".
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
Changes in V10:
- add Acked-by: Jan Beulich
---
Changes in V9:
- new patch
---
xen/arch/riscv/setup.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 8bb5bdb2ae..e3cb0866d5 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -23,9 +23,7 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
{
remove_identity_mapping();
-early_printk("Hello from C env\n");
-
-early_printk("All set up\n");
+printk("All set up\n");
for ( ;; )
asm volatile ("wfi");
--
2.45.2
[PATCH v10 3/5] xen/riscv: introduce trap_init()
trap_init() wasn't declared with the __init attribute to avoid removing
__init when multi-CPU support for Xen is added.
Signed-off-by: Oleksii Kurochko
Reviewed-by: Alistair Francis
---
Changes in V10:
- update the commit message
---
Changes in V9:
- drop inclusion of in setup.c
- drop #include
- ...
- introduce stub for
void arch_get_xen_caps(xen_capabilities_info_t *info);
- resolve rebase conflicts.
---
Changes in V8:
- nothing changed. only rebase was done.
---
Changes in V7:
- #define cast_to_bug_frame(addr) ((const struct bug_frame *)(addr)).
- remove unnecessary comments in trap_init() function.
---
Changes in V6:
- trap_init() is now called after enabling the MMU.
- Add additional explanatory comments.
---
Changes in V5:
- Nothing changed
---
Changes in V4:
- Nothing changed
---
Changes in V3:
- Nothing changed
---
Changes in V2:
- Rename setup_trap_handler() to trap_init().
- Add Reviewed-by to the commit message.
---
xen/arch/riscv/include/asm/traps.h | 1 +
xen/arch/riscv/setup.c | 3 +++
xen/arch/riscv/traps.c | 12
3 files changed, 16 insertions(+)
diff --git a/xen/arch/riscv/include/asm/traps.h
b/xen/arch/riscv/include/asm/traps.h
index 3fef318478..c30118e095 100644
--- a/xen/arch/riscv/include/asm/traps.h
+++ b/xen/arch/riscv/include/asm/traps.h
@@ -9,6 +9,7 @@
void do_trap(struct cpu_user_regs *cpu_regs);
void handle_trap(void);
+void trap_init(void);
#endif /* __ASSEMBLY__ */
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index e3cb0866d5..a6a29a1508 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -8,6 +8,7 @@
#include
#include
+#include
void arch_get_xen_caps(xen_capabilities_info_t *info)
{
@@ -23,6 +24,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
{
remove_identity_mapping();
+trap_init();
+
printk("All set up\n");
for ( ;; )
diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c
index 37cec40dfa..cb18b30ff2 100644
--- a/xen/arch/riscv/traps.c
+++ b/xen/arch/riscv/traps.c
@@ -12,6 +12,18 @@
#include
#include
+/*
+ * Initialize the trap handling.
+ *
+ * The function is called after MMU is enabled.
+ */
+void trap_init(void)
+{
+unsigned long addr = (unsigned long)_trap;
+
+csr_write(CSR_STVEC, addr);
+}
+
static const char *decode_trap_cause(unsigned long cause)
{
static const char *const trap_causes[] = {
--
2.45.2
Re: [PATCH 11/12] CI: Swap to debian for riscv64 build and test
On Thu, 2024-07-11 at 12:15 +0100, Andrew Cooper wrote: > The containers are both much smaller, with stable toolchains over > time, and > this at least means we're not doing all testing with a single > compiler. > > Rename the jobs to follow to sort coherently ($DISTRO-$VERSION-$ARCH- > *) and > reposition the jobs to optimise starting the smoke test. > > Signed-off-by: Andrew Cooper LGTM: Oleksii Kurochko ~ Oleksii > --- > CC: Anthony PERARD > CC: Juergen Gross > CC: Roger Pau Monné > CC: Jan Beulich > CC: Stefano Stabellini > CC: Julien Grall > CC: Oleksii Kurochko > CC: Shawn Anastasio > --- > .../archlinux/current-riscv64.dockerfile | 22 - > automation/gitlab-ci/build.yaml | 83 +++-- > -- > automation/gitlab-ci/test.yaml | 4 +- > automation/scripts/containerize | 3 +- > 4 files changed, 52 insertions(+), 60 deletions(-) > delete mode 100644 automation/build/archlinux/current- > riscv64.dockerfile > > diff --git a/automation/build/archlinux/current-riscv64.dockerfile > b/automation/build/archlinux/current-riscv64.dockerfile > deleted file mode 100644 > index f7770bf82a78.. > --- a/automation/build/archlinux/current-riscv64.dockerfile > +++ /dev/null > @@ -1,22 +0,0 @@ > -# syntax=docker/dockerfile:1 > -FROM --platform=linux/amd64 archlinux > -LABEL maintainer.name="The Xen Project" \ > - maintainer.email="xen-devel@lists.xenproject.org" > - > -# Packages needed for the build > -RUN pacman --noconfirm --needed -Syu \ > - base-devel \ > - git \ > - inetutils \ > - riscv64-linux-gnu-binutils \ > - riscv64-linux-gnu-gcc \ > - riscv64-linux-gnu-glibc \ > - # For test phase > - qemu-system-riscv > - > -# Add compiler path > -ENV CROSS_COMPILE=riscv64-linux-gnu- > - > -RUN useradd --create-home user > -USER user > -WORKDIR /build > diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab- > ci/build.yaml > index e081664c4e95..4b9d80cc5632 100644 > --- a/automation/gitlab-ci/build.yaml > +++ b/automation/gitlab-ci/build.yaml > @@ -357,6 +357,13 @@ debian-12-ppc64le-gcc-debug: > KBUILD_DEFCONFIG: ppc64_defconfig > HYPERVISOR_ONLY: y > > +debian-12-riscv64-gcc-debug: > + extends: .gcc-riscv64-cross-build-debug > + variables: > + CONTAINER: debian:12-riscv64 > + KBUILD_DEFCONFIG: tiny64_defconfig > + HYPERVISOR_ONLY: y > + > # Arm32 cross-build > > debian-bookworm-gcc-arm32: > @@ -458,41 +465,6 @@ alpine-3.18-gcc-debug-arm64-earlyprintk: > CONFIG_EARLY_UART_CHOICE_PL011=y > CONFIG_EARLY_UART_BASE_ADDRESS=0x900 > > -# RISC-V 64 cross-build > -.riscv-fixed-randconfig: > - variables: > - EXTRA_FIXED_RANDCONFIG: | > - CONFIG_BOOT_TIME_CPUPOOLS=n > - CONFIG_COVERAGE=n > - CONFIG_EXPERT=y > - CONFIG_GRANT_TABLE=n > - CONFIG_MEM_ACCESS=n > - CONFIG_PERF_COUNTERS=n > - CONFIG_LIVEPATCH=n > - CONFIG_XSM=n > - > -archlinux-current-gcc-riscv64: > - extends: .gcc-riscv64-cross-build > - variables: > - CONTAINER: archlinux:current-riscv64 > - KBUILD_DEFCONFIG: tiny64_defconfig > - HYPERVISOR_ONLY: y > - > -archlinux-current-gcc-riscv64-debug: > - extends: .gcc-riscv64-cross-build-debug > - variables: > - CONTAINER: archlinux:current-riscv64 > - KBUILD_DEFCONFIG: tiny64_defconfig > - HYPERVISOR_ONLY: y > - > -archlinux-current-gcc-riscv64-randconfig: > - extends: .gcc-riscv64-cross-build > - variables: > - CONTAINER: archlinux:current-riscv64 > - KBUILD_DEFCONFIG: tiny64_defconfig > - RANDCONFIG: y > - <<: *riscv-fixed-randconfig > - > # Yocto test jobs > yocto-qemuarm64: > extends: .yocto-test-arm64 > @@ -739,3 +711,44 @@ debian-12-ppc64le-gcc: > KBUILD_DEFCONFIG: ppc64_defconfig > HYPERVISOR_ONLY: y > > +# RISC-V 64 cross-build > +debian-11-riscv64-gcc: > + extends: .gcc-riscv64-cross-build > + variables: > + CONTAINER: debian:11-riscv64 > + KBUILD_DEFCONFIG: tiny64_defconfig > + HYPERVISOR_ONLY: y > + > +debian-11-riscv64-gcc-debug: > + extends: .gcc-riscv64-cross-build-debug > + variables: > + CONTAINER: debian:11-riscv64 > + KBUILD_DEFCONFIG: tiny64_defconfig > + HYPERVISOR_ONLY: y > + > +debian-12-riscv64-gcc: > + extends: .gcc-riscv64-cross-build > + variables: > + CONTAINER: debian:12-riscv64 > + KBUILD_DEFCONFIG: tiny64_defconfig > + HYPERVISOR_ONLY: y > + > +.riscv-fixed-randconfig: > + variables: > + EXTRA_FIXED_RANDCONFIG: | > + CON
Re: [PATCH 10/12] CI: Introduce debian:11/12-riscv64 containers
On Thu, 2024-07-11 at 12:15 +0100, Andrew Cooper wrote:
> For starters, they're slightly smaller:
>
> $ docker image list
> registry.gitlab.com/xen-project/xen/debian 12-riscv64
> 772MB
> registry.gitlab.com/xen-project/xen/debian 11-riscv64
> 422MB
Do we really need both 11-riscv64 and 12-riscv64?
Generally this patch LGTM: Reviewed-by: Oleksii Kurochko
~ Oleksii
> registry.gitlab.com/xen-project/xen/archlinux current-riscv64
> 2.32GB
>
> They also not rolling distros, so will be more predicatable testing
> for the
> stable trees in the future.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Anthony PERARD
> CC: Juergen Gross
> CC: Roger Pau Monné
> CC: Jan Beulich
> CC: Stefano Stabellini
> CC: Julien Grall
> CC: Oleksii Kurochko
> CC: Shawn Anastasio
> ---
> automation/build/debian/11-riscv64.dockerfile | 33 +
> automation/build/debian/12-riscv64.dockerfile | 36
> +++
> 2 files changed, 69 insertions(+)
> create mode 100644 automation/build/debian/11-riscv64.dockerfile
> create mode 100644 automation/build/debian/12-riscv64.dockerfile
>
> diff --git a/automation/build/debian/11-riscv64.dockerfile
> b/automation/build/debian/11-riscv64.dockerfile
> new file mode 100644
> index ..1c99bc89ea1a
> --- /dev/null
> +++ b/automation/build/debian/11-riscv64.dockerfile
> @@ -0,0 +1,33 @@
> +# syntax=docker/dockerfile:1
> +FROM --platform=linux/amd64 debian:bullseye-slim
> +LABEL maintainer.name="The Xen Project"
> +LABEL maintainer.email="xen-devel@lists.xenproject.org"
> +
> +ENV DEBIAN_FRONTEND=noninteractive
> +ENV CROSS_COMPILE=riscv64-linux-gnu-
> +ENV XEN_TARGET_ARCH=riscv64
> +
> +RUN < +#!/bin/bash
> + set -e
> +
> + useradd --create-home user
> +
> + apt-get -y update
> +
> + DEPS=(
> + # Xen
> + bison
> + build-essential
> + checkpolicy
> + flex
> + gcc-riscv64-linux-gnu
> + python3-minimal
> + )
> +
> + apt-get -y --no-install-recommends install "${DEPS[@]}"
> + rm -rf /var/lib/apt/lists/*
> +EOF
> +
> +USER user
> +WORKDIR /build
> diff --git a/automation/build/debian/12-riscv64.dockerfile
> b/automation/build/debian/12-riscv64.dockerfile
> new file mode 100644
> index ..03fd4b03059b
> --- /dev/null
> +++ b/automation/build/debian/12-riscv64.dockerfile
> @@ -0,0 +1,36 @@
> +# syntax=docker/dockerfile:1
> +FROM --platform=linux/amd64 debian:bookworm-slim
> +LABEL maintainer.name="The Xen Project"
> +LABEL maintainer.email="xen-devel@lists.xenproject.org"
> +
> +ENV DEBIAN_FRONTEND=noninteractive
> +ENV CROSS_COMPILE=riscv64-linux-gnu-
> +ENV XEN_TARGET_ARCH=riscv64
> +
> +RUN < +#!/bin/bash
> + set -e
> +
> + useradd --create-home user
> +
> + apt-get -y update
> +
> + DEPS=(
> + # Xen
> + bison
> + build-essential
> + checkpolicy
> + flex
> + gcc-riscv64-linux-gnu
> + python3-minimal
> +
> + # Qemu for test phase
> + qemu-system-riscv64
> + )
> +
> + apt-get -y --no-install-recommends install "${DEPS[@]}"
> + rm -rf /var/lib/apt/lists/*
> +EOF
> +
> +USER user
> +WORKDIR /build
Re: [PATCH for-4.19 v2 00/12] CI: part 3 (slimline, and PPC/RISCV fixes)
Release-Acked-By: Oleksii Kurochko
~ Oleksii
On Thu, 2024-07-11 at 12:15 +0100, Andrew Cooper wrote:
> Patch 1 fixes a bug in the containerize script
>
> Patches 2-5 remove useless/obsolete testing
>
> Patch 6 fixes a bug with the archlinux testing configuration
>
> Patches 7-9 adjust the PPC64 testing
>
> Patches 10-11 adjust the RISCV64 testing
>
> Patch 12 refreshes the custom GCC-IBT container
>
>
> All changes here follow best-guidance for dockerfiles (non-root,
> heredocs for
> improved legibility), and naming consistency improvements discussed
> previously
> on the Committers call. Breifly that's:
>
> $DISTRO-$VERSION(numeric)-$ARCH-*
>
> which sort more nicely and don't require e.g. people to remember
> which order
> buster/bullseye/bookworm are in terms of debain release.
>
> For x86, this involves inserting an $ARCH of x86_64. Right now,
> x86_64 is
> implied by the absence, and all other variations have to state one.
>
>
> Still to come:
>
> * OpenSUSE container fixes (resolves the final rolling distro vs
> allowed_failure problem)
> * Ubuntu/debian rename/trim
> * Add new jobs for latest releases (Ubuntu, Alpine, Fedora)
>
> Andrew Cooper (12):
> CI: Fix CONTAINER_UID0=1 scripts/containerize
>
> CI: Remove useless/misleading randconfig jobs
> CI: Drop Debian Jessie dockerfiles
> CI: Drop Debian Stretch testing
> CI: Drop Ubuntu Trusty testing
>
> CI: Mark Archlinux/x86 as allowing failures
>
> CI: Introduce a debian:12-ppc64le container
> CI: Use debian:12-ppc64le for both build and test
> CI: Refresh bullseye-ppc64le as debian:11-ppc64le
>
> CI: Introduce debian:11/12-riscv64 containers
> CI: Swap to debian for riscv64 build and test
>
> CI: Refresh and upgrade the GCC-IBT container
>
> .../archlinux/current-riscv64.dockerfile | 22 --
> automation/build/debian/11-ppc64le.dockerfile | 33 +++
> automation/build/debian/11-riscv64.dockerfile | 33 +++
> automation/build/debian/12-ppc64le.dockerfile | 36 +++
> automation/build/debian/12-riscv64.dockerfile | 36 +++
> ...ockerfile => 12-x86_64-gcc-ibt.dockerfile} | 81 +++---
> .../build/debian/bullseye-ppc64le.dockerfile | 32 ---
> .../build/debian/jessie-i386.dockerfile | 55 -
> automation/build/debian/jessie.dockerfile | 52
> .../build/debian/stretch-i386.dockerfile | 57 -
> automation/build/debian/stretch.dockerfile | 60 -
> automation/build/ubuntu/trusty.dockerfile | 51
> automation/gitlab-ci/build.yaml | 233 +++-
> --
> automation/gitlab-ci/test.yaml | 13 +-
> automation/scripts/containerize | 15 +-
> automation/scripts/qemu-smoke-ppc64le.sh | 4 +-
> .../qemu-system-ppc64/8.1.0-ppc64.dockerfile | 38 ---
> 17 files changed, 282 insertions(+), 569 deletions(-)
> delete mode 100644 automation/build/archlinux/current-
> riscv64.dockerfile
> create mode 100644 automation/build/debian/11-ppc64le.dockerfile
> create mode 100644 automation/build/debian/11-riscv64.dockerfile
> create mode 100644 automation/build/debian/12-ppc64le.dockerfile
> create mode 100644 automation/build/debian/12-riscv64.dockerfile
> rename automation/build/debian/{buster-gcc-ibt.dockerfile => 12-
> x86_64-gcc-ibt.dockerfile} (50%)
> delete mode 100644 automation/build/debian/bullseye-
> ppc64le.dockerfile
> delete mode 100644 automation/build/debian/jessie-i386.dockerfile
> delete mode 100644 automation/build/debian/jessie.dockerfile
> delete mode 100644 automation/build/debian/stretch-i386.dockerfile
> delete mode 100644 automation/build/debian/stretch.dockerfile
> delete mode 100644 automation/build/ubuntu/trusty.dockerfile
> delete mode 100644 automation/tests-artifacts/qemu-system-
> ppc64/8.1.0-ppc64.dockerfile
>
Re: [PATCH v1 5/5] xen/riscv: map FDT
On Thu, 2024-07-11 at 13:44 +0100, Julien Grall wrote: > Hi Oleksii, Hi Julien, > > On 11/07/2024 13:29, Oleksii wrote: > > On Thu, 2024-07-11 at 12:54 +0100, Julien Grall wrote: > > > Hi, > > > > > > On 11/07/2024 12:28, Oleksii wrote: > > > > Add Julien as he asked basically the same question in another > > > > thread. > > > > > > Thanks! > > > > > > > > > > > On Thu, 2024-07-11 at 12:50 +0200, Jan Beulich wrote: > > > > > On 11.07.2024 12:26, Oleksii wrote: > > > > > > On Thu, 2024-07-11 at 11:54 +0200, Jan Beulich wrote: > > > > > > > On 11.07.2024 11:40, Oleksii wrote: > > > > > > > > On Wed, 2024-07-10 at 14:38 +0200, Jan Beulich wrote: > > > > > > > > > On 03.07.2024 12:42, Oleksii Kurochko wrote: > > > > > > Does it make sense now? > > > > > > > > > > I think so, yet at the same time it only changes the > > > > > question: > > > > > Why is > > > > > it > > > > > that you absolutely need to use setup_initial_mapping()? > > > > There is no strict requirement to use setup_initial_mapping(). > > > > That > > > > function is available to me at the moment, and I haven't found > > > > a > > > > better > > > > option other than reusing what I currently have. > > > > > > I am not very familiar with the code base for RISC-V, but looking > > > at > > > the > > > context in the patch, it seems you will still have the identity > > > mapping > > > mapped until start_xen(). > > We have identity mapping only for a small piece of .text section: > > . = ALIGN(IDENT_AREA_SIZE); > > _ident_start = .; > > *(.text.ident) > > _ident_end = .; > > > > All other will be identically mapped only in case of linker address > > is > > equal to load address. > > > > > > > > I assume we don't exactly know where the loader will put Xen in > > > memory. > > > Which means that the region may clash with your defined runtime > > > regions > > > (such as the FDT). Did I misunderstand anything? > > I am not really get what is the issue here. > > > > If we are speaking about physical regions then loader will > > guarantee > > that Xen and FDT regions don't overlap. > > Sure. But I was referring to... > > > > > If we are speaking about virtual regions then Xen will check that > > nothing is overlaped. > > ... this part. The more regions you mapped with MMU off, the more > work > you have to do to ensure nothing will clash. Yes, agree here. Then I have to look at what I need now to introduce map_pages_to_xen(). Thanks for clarifying. > > > And the virtual regions are mapped so high so I > > am not sure that loader will put something there. ( FDT in Xen is > > mapped to 0xc020 ) > Never say never :). On Arm, some 64-bit HW (such as ADLink AVA > platform) > has the RAM starting very high and load Xen around 8TB. For Arm, we > still decided to put a limit (10TB) where Xen can be loaded but this > is > mainly done for convenience (otherwise it is a bit more complicated > to > get off the identity mapping). Oh, it is very high. I couldn't even expect. ~ Oleksii > > We still have a check in place to ensure that Xen is not loaded above > 10TB. If you map the FDT within the same L1. > > Cheers, >
Re: [PATCH v1 5/5] xen/riscv: map FDT
On Thu, 2024-07-11 at 12:54 +0100, Julien Grall wrote: > Hi, > > On 11/07/2024 12:28, Oleksii wrote: > > Add Julien as he asked basically the same question in another > > thread. > > Thanks! > > > > > On Thu, 2024-07-11 at 12:50 +0200, Jan Beulich wrote: > > > On 11.07.2024 12:26, Oleksii wrote: > > > > On Thu, 2024-07-11 at 11:54 +0200, Jan Beulich wrote: > > > > > On 11.07.2024 11:40, Oleksii wrote: > > > > > > On Wed, 2024-07-10 at 14:38 +0200, Jan Beulich wrote: > > > > > > > On 03.07.2024 12:42, Oleksii Kurochko wrote: > > > > Does it make sense now? > > > > > > I think so, yet at the same time it only changes the question: > > > Why is > > > it > > > that you absolutely need to use setup_initial_mapping()? > > There is no strict requirement to use setup_initial_mapping(). That > > function is available to me at the moment, and I haven't found a > > better > > option other than reusing what I currently have. > > I am not very familiar with the code base for RISC-V, but looking at > the > context in the patch, it seems you will still have the identity > mapping > mapped until start_xen(). We have identity mapping only for a small piece of .text section: . = ALIGN(IDENT_AREA_SIZE); _ident_start = .; *(.text.ident) _ident_end = .; All other will be identically mapped only in case of linker address is equal to load address. > > I assume we don't exactly know where the loader will put Xen in > memory. > Which means that the region may clash with your defined runtime > regions > (such as the FDT). Did I misunderstand anything? I am not really get what is the issue here. If we are speaking about physical regions then loader will guarantee that Xen and FDT regions don't overlap. If we are speaking about virtual regions then Xen will check that nothing is overlaped. And the virtual regions are mapped so high so I am not sure that loader will put something there. ( FDT in Xen is mapped to 0xc020 ). Could you please clarify what I am missing? > > That's one of the reason on Arm we are trying to enable the MMU very > early. The only thing we setup is a mapping for Xen (and earlyprintk) > all the rest will be mapped once the MMU is on. It makes sense. Then I have to introduce map_pages_to_xen() first and then early_fdt_map(). ~ Oleksii > > With that, the only thing you need to take care off the runtime Xen > address overlapping with the identity mapping.
Re: [PATCH v9 4/5] xen/riscv: enable GENERIC_BUG_FRAME
On Thu, 2024-07-11 at 11:25 +0200, Jan Beulich wrote:
> On 11.07.2024 10:50, Oleksii wrote:
> > On Wed, 2024-07-10 at 12:01 +0200, Jan Beulich wrote:
> > > On 02.07.2024 13:23, Oleksii Kurochko wrote:
> > > > @@ -101,8 +102,38 @@ static void do_unexpected_trap(const
> > > > struct
> > > > cpu_user_regs *regs)
> > > > die();
> > > > }
> > > >
> > > > +static bool is_valid_bug_insn(uint32_t insn)
> > > > +{
> > > > + return insn == BUG_INSN_32 ||
> > > > + (insn & COMPRESSED_INSN_MASK) == BUG_INSN_16;
> > > > +}
> > > > +
> > > > +/* Should be used only on Xen code */
> > > > +static uint32_t read_instr(unsigned long pc)
> > > > +{
> > > > + uint16_t instr16 = *(uint16_t *)pc;
> > > > +
> > > > + ASSERT(is_kernel_text(pc + 1) || is_kernel_inittext(pc +
> > > > 1));
> > > > +
> > > > + if ( GET_INSN_LENGTH(instr16) == 2 )
> > > > + return instr16;
> > > > +
> > > > + ASSERT(is_kernel_text(pc + 3) || is_kernel_inittext(pc +
> > > > 3));
> > > > +
> > > > + return *(uint32_t *)pc;
> > > > +}
> > >
> > > Related to the point made further down: If either of these
> > > assertions
> > > fails,
> > > won't we come back again right here? If either of the
> > > is_kernel_*text()
> > > wasn't working quite right, wouldn't we be at risk of entering an
> > > infinite
> > > loop (presumably not quite infinite because of the stack
> > > overflowing
> > > at some
> > > point)?
> > It is really possible to have infinite loop here so it should be
> > better
> > to use 'if' with die() or panic().
> >
> > >
> > > > void do_trap(struct cpu_user_regs *cpu_regs)
> > > > {
> > > > + register_t pc = cpu_regs->sepc;
> > > > + uint32_t instr = read_instr(pc);
> > > > +
> > > > + if ( ( is_valid_bug_insn(instr) ) && (
> > > > do_bug_frame(cpu_regs,
> > > > pc) >= 0 ) )
> > >
> > > No consideration of the kind of exception? I'd expect it is one
> > > very
> > > specific one which the BUG insn would raise, and then there's no
> > > point
> > > fetching the insn when it's a different kind of exception.
> > Good point.
> >
> > We should have 0x3 ( breakpoint exception ) in scause register. We
> > can
> > just check that without reading instruction and then also
> > is_valid_bug_insn could be dropped too.
>
> Just that then you'll also lose the is_kernel_*text() checking, which
> I
> understand is there to remind you/us that one this becomes reachable
> from non-Xen code, adjustments are going to be needed.
One thing I wrote incorrectly is that we still need fetch instruction
or at least 16 bits to identify the length of instruction to set proper
sepc:
cpu_regs->sepc += GET_INSN_LENGTH(instr);
We could write that in the following way:
cpu_regs->sepc += GET_INSN_LENGTH(*(uint16_t *)pc);
Would it be okay?
~ Oleksii
Re: [PATCH v1 5/5] xen/riscv: map FDT
On Thu, 2024-07-11 at 11:50 +0100, Julien Grall wrote: > Hi, Hi Julien, > > On 11/07/2024 10:40, Oleksii wrote: > > On Wed, 2024-07-10 at 14:38 +0200, Jan Beulich wrote: > > > On 03.07.2024 12:42, Oleksii Kurochko wrote: > > > > Except mapping of FDT, it is also printing command line passed > > > > by > > > > a DTB and initialize bootinfo from a DTB. > > > > > > I'm glad the description isn't empty here. However, ... > > > > > > > --- a/xen/arch/riscv/riscv64/head.S > > > > +++ b/xen/arch/riscv/riscv64/head.S > > > > @@ -41,6 +41,9 @@ FUNC(start) > > > > > > > > jal setup_initial_pagetables > > > > > > > > + mv a0, s1 > > > > + jal fdt_map > > > > + > > > > /* Calculate proper VA after jump from 1:1 mapping */ > > > > la a0, .L_primary_switched > > > > sub a0, a0, s2 > > > > > > ... it could do with clarifying why this needs calling from > > > assembly > > > code. Mapping the FDT clearly looks like something that wants > > > doing > > > from start_xen(), i.e. from C code. > > fdt_map() expected to work while MMU is off as it is using > > setup_initial_mapping() which is working with physical address. > > Somewhat related to what Jan is asking. You only seem to part the FDT > in > start_xen(). So why do you need to call fdt_map() that early? Let's continue our discussion in another thread ( I added you there ). But the answer on your question is here: https://lore.kernel.org/xen-devel/cover.1720002425.git.oleksii.kuroc...@gmail.com/T/#m2890200a53c6ea2101e0f9e9ea77f589bd187e26 And here:https://lore.kernel.org/xen-devel/cover.1720002425.git.oleksii.kuroc...@gmail.com/T/#m4e20792121b97465db7081cc4c1e27bdb15cdd51 Let me know if the link above answers your question. ~ Oleksii
Re: [PATCH v1 5/5] xen/riscv: map FDT
Add Julien as he asked basically the same question in another thread.
On Thu, 2024-07-11 at 12:50 +0200, Jan Beulich wrote:
> On 11.07.2024 12:26, Oleksii wrote:
> > On Thu, 2024-07-11 at 11:54 +0200, Jan Beulich wrote:
> > > On 11.07.2024 11:40, Oleksii wrote:
> > > > On Wed, 2024-07-10 at 14:38 +0200, Jan Beulich wrote:
> > > > > On 03.07.2024 12:42, Oleksii Kurochko wrote:
> > > > > > Except mapping of FDT, it is also printing command line
> > > > > > passed
> > > > > > by
> > > > > > a DTB and initialize bootinfo from a DTB.
> > > > >
> > > > > I'm glad the description isn't empty here. However, ...
> > > > >
> > > > > > --- a/xen/arch/riscv/riscv64/head.S
> > > > > > +++ b/xen/arch/riscv/riscv64/head.S
> > > > > > @@ -41,6 +41,9 @@ FUNC(start)
> > > > > >
> > > > > > jal setup_initial_pagetables
> > > > > >
> > > > > > + mv a0, s1
> > > > > > + jal fdt_map
> > > > > > +
> > > > > > /* Calculate proper VA after jump from 1:1 mapping
> > > > > > */
> > > > > > la a0, .L_primary_switched
> > > > > > sub a0, a0, s2
> > > > >
> > > > > ... it could do with clarifying why this needs calling from
> > > > > assembly
> > > > > code. Mapping the FDT clearly looks like something that wants
> > > > > doing
> > > > > from start_xen(), i.e. from C code.
> > > > fdt_map() expected to work while MMU is off as it is using
> > > > setup_initial_mapping() which is working with physical address.
> > >
> > > Hmm, interesting. When the MMU is off, what does "map" mean? Yet
> > > then
> > > it feels I'm misunderstanding what you're meaning to tell me ...
> > Let's look at examples of the code:
> > 1. The first thing issue will be here:
> > void* __init early_fdt_map(paddr_t fdt_paddr)
> > {
> > unsigned long dt_phys_base = fdt_paddr;
> > unsigned long dt_virt_base;
> > unsigned long dt_virt_size;
> >
> > BUILD_BUG_ON(MIN_FDT_ALIGN < 8);
> > if ( !fdt_paddr || fdt_paddr % MIN_FDT_ALIGN || fdt_paddr %
> > SZ_2M
> > ||
> > fdt_totalsize(fdt_paddr) > BOOT_FDT_VIRT_SIZE )
> > MMU doesn't now about virtual address of fdt_paddr as fdt_paddr
> > wasn't
> > mapped.
> >
> > 2. In setup_initial_mapping() we have HANDLE_PGTBL() where pgtbl is
> > a
> > pointer to physical address ( which also should be mapped in MMU
> > if we
> > want to access it after MMU is enabled ):
> > #define
> > HANDLE_PGTBL(curr_lvl_num)
> > \
> > index = pt_index(curr_lvl_num,
> > page_addr);
> > \
> > if ( pte_is_valid(pgtbl[index])
> > )
> > \
> >
> > {
> > \
> > /* Find L{ 0-3 } table
> > */
> > \
> > pgtbl = (pte_t
> > *)pte_to_paddr(pgtbl[index]);
> > \
> >
> > }
> > \
> >
> > else
> > \
> >
> > {
> > \
> > /* Allocate new L{0-3} page table
> > */
> > \
> > if ( mmu_desc->pgtbl_count == PGTBL_INITIAL_COUNT
> > )
> > \
> >
> > {
> > \
> > early_printk("(XEN) No initial table
> > available\n");
> > \
> > /* panic(), BUG() or ASSERT() aren't ready now.
> > */
> > \
> >
> > die();
> > \
> >
> > }
> > \
> > mmu_desc-
> > >pgtbl_count++;
> >
Re: [PATCH v1 5/5] xen/riscv: map FDT
On Thu, 2024-07-11 at 11:54 +0200, Jan Beulich wrote:
> On 11.07.2024 11:40, Oleksii wrote:
> > On Wed, 2024-07-10 at 14:38 +0200, Jan Beulich wrote:
> > > On 03.07.2024 12:42, Oleksii Kurochko wrote:
> > > > Except mapping of FDT, it is also printing command line passed
> > > > by
> > > > a DTB and initialize bootinfo from a DTB.
> > >
> > > I'm glad the description isn't empty here. However, ...
> > >
> > > > --- a/xen/arch/riscv/riscv64/head.S
> > > > +++ b/xen/arch/riscv/riscv64/head.S
> > > > @@ -41,6 +41,9 @@ FUNC(start)
> > > >
> > > > jal setup_initial_pagetables
> > > >
> > > > + mv a0, s1
> > > > + jal fdt_map
> > > > +
> > > > /* Calculate proper VA after jump from 1:1 mapping */
> > > > la a0, .L_primary_switched
> > > > sub a0, a0, s2
> > >
> > > ... it could do with clarifying why this needs calling from
> > > assembly
> > > code. Mapping the FDT clearly looks like something that wants
> > > doing
> > > from start_xen(), i.e. from C code.
> > fdt_map() expected to work while MMU is off as it is using
> > setup_initial_mapping() which is working with physical address.
>
> Hmm, interesting. When the MMU is off, what does "map" mean? Yet then
> it feels I'm misunderstanding what you're meaning to tell me ...
Let's look at examples of the code:
1. The first thing issue will be here:
void* __init early_fdt_map(paddr_t fdt_paddr)
{
unsigned long dt_phys_base = fdt_paddr;
unsigned long dt_virt_base;
unsigned long dt_virt_size;
BUILD_BUG_ON(MIN_FDT_ALIGN < 8);
if ( !fdt_paddr || fdt_paddr % MIN_FDT_ALIGN || fdt_paddr % SZ_2M
||
fdt_totalsize(fdt_paddr) > BOOT_FDT_VIRT_SIZE )
MMU doesn't now about virtual address of fdt_paddr as fdt_paddr wasn't
mapped.
2. In setup_initial_mapping() we have HANDLE_PGTBL() where pgtbl is a
pointer to physical address ( which also should be mapped in MMU if we
want to access it after MMU is enabled ):
#define HANDLE_PGTBL(curr_lvl_num)
\
index = pt_index(curr_lvl_num, page_addr);
\
if ( pte_is_valid(pgtbl[index]) )
\
{
\
/* Find L{ 0-3 } table */
\
pgtbl = (pte_t *)pte_to_paddr(pgtbl[index]);
\
}
\
else
\
{
\
/* Allocate new L{0-3} page table */
\
if ( mmu_desc->pgtbl_count == PGTBL_INITIAL_COUNT )
\
{
\
early_printk("(XEN) No initial table available\n");
\
/* panic(), BUG() or ASSERT() aren't ready now. */
\
die();
\
}
\
mmu_desc->pgtbl_count++;
\
pgtbl[index] = paddr_to_pte((unsigned long)mmu_desc-
>next_pgtbl,\
PTE_VALID);
\
pgtbl = mmu_desc->next_pgtbl;
\
mmu_desc->next_pgtbl += PAGETABLE_ENTRIES;
\
}
So we can't use setup_initial_mapping() when MMU is enabled as there is
a part of the code which uses physical address which are not mapped.
We have only mapping for for liner_start <-> load_start and the small
piece of code in text section ( _ident_start ):
setup_initial_mapping(_desc,
linker_start,
linker_end,
load_start);
if ( linker_start == load_start )
return;
ident_start = (unsigned long)turn_on_mmu _PT_LEVEL_MAP_MASK(0);
ident_end = ident_start + PAGE_SIZE;
setup_initial_mapping(_desc,
ident_start,
ident_end,
ident_start);
We can use setup_initial_mapping() when MMU is enabled only in case
when linker_start is equal to load_start.
As an option we can consider for as a candidate for identaty mapping
also section .bss.page_aligned where root and nonroot page tables are
located.
Does it make sense now?
~ Oleksii
Re: [PATCH v1 1/5] xen/device-tree: Move Arm's setup.c bootinfo functions to common
On Thu, 2024-07-11 at 11:21 +0200, Jan Beulich wrote: > On 11.07.2024 11:00, Oleksii wrote: > > On Wed, 2024-07-10 at 12:23 +0200, Jan Beulich wrote: > > > On 03.07.2024 12:42, Oleksii Kurochko wrote: > > > > From: Shawn Anastasio > > > > > > > > Arm's setup.c contains a collection of functions for parsing > > > > memory > > > > map > > > > and other boot information from a device tree. Since these > > > > routines > > > > are > > > > generally useful on any architecture that supports device tree > > > > booting, > > > > move them into xen/common/device-tree. > > > > > > > > Suggested-by: Julien Grall > > > > Signed-off-by: Shawn Anastasio > > > > > > > > Signed-off-by: Oleksii Kurochko > > > > --- > > > > Changes in V5: > > > > - add xen/include/xen/bootfdt.h to MAINTAINERS file. > > > > - drop message "Early device tree parsing and". > > > > - After rebase on top of the current staging the following > > > > changes > > > > were done: > > > > - init bootinfo variable in > > > > with > > > > BOOTINFO_INIT; > > > > - update the code of dt_unreserved_regions(): > > > > CONFIG_STATIC_SHM related changes and getting of > > > > reserved_mem > > > > bootinfo_get_shmem() ?? > > > > - update the code of meminfo_overlap_check(): > > > > add check ( INVALID_PADDR == bank_start ) to if case. > > > > - update the code of check_reserved_regions_overlap(): > > > > CONFIG_STATIC_SHM related changes. > > > > - struct bootinfo was updated ( CONFIG_STATIC_SHM changes ) > > > > - add shared_meminfo ( because of CONFIG_STATIC_SHM ) > > > > - struct struct membanks was update with __struct group so > > > > is > > > > neeeded to be included in bootfdt.h > > > > - move BOOTINFO_ACPI_INIT, BOOTINFO_SHMEM_INIT, > > > > BOOTINFO_INIT to > > > > generic bootfdt.h > > > > - bootinfo_get_reserved_mem(), bootinfo_get_mem(), > > > > bootinfo_get_acpi(), > > > > bootinfo_get_shmem() and bootinfo_get_shmem_extra() were > > > > moved > > > > to xen/bootfdt.h > > > > - s/arm32/CONFIG_SEPARATE_XENHEAP/ > > > > - add inclusion of because there are function > > > > in > > > > which > > > > are using container_of(). > > > > > > Just to mention it: This is confusing. The series is tagged "v1". > > > I > > > understand > > > you took Shawn's work, which had already undergone revisions. But > > > then imo you > > > want to at least clarify how your v1 relates to his v4 or v5, > > > i.e. > > > then making > > > clear to the reader whether all of the changes above were > > > actually > > > done by you > > > on top of an earlier v4, or whether you took the earlier v5 > > > verbatim. > > That is why I wrote "Changes in v5" to show that these changes were > > done on top of v4 version of Shawn's series, so what is mentioned > > in v5 > > here it is what was done by me. > > Except that what you sent is v1, not v5. > > > I'll reword that and probably I shouldn't drop "Changes in > > v4,3,2,1" > > from Shawn's patch. > > I don't think you should drop anything. You want to clarify > relationship > of the version of your series with that of Shawn's earlier one. Or > you'd > want to continue numbering from what the previous series had, yet > that > may then also end up confusing if Shawn resumed work there. Oh, I understood now what you meant. The Patch should be with the name: [PATCH *v5* 1/5] xen/device-tree: Move Arm's setup.c bootinfo functions to common I will update that. Thanks. ~ Oleksii
Re: [PATCH v1 5/5] xen/riscv: map FDT
On Wed, 2024-07-10 at 14:38 +0200, Jan Beulich wrote:
> On 03.07.2024 12:42, Oleksii Kurochko wrote:
> > Except mapping of FDT, it is also printing command line passed by
> > a DTB and initialize bootinfo from a DTB.
>
> I'm glad the description isn't empty here. However, ...
>
> > --- a/xen/arch/riscv/riscv64/head.S
> > +++ b/xen/arch/riscv/riscv64/head.S
> > @@ -41,6 +41,9 @@ FUNC(start)
> >
> > jal setup_initial_pagetables
> >
> > + mv a0, s1
> > + jal fdt_map
> > +
> > /* Calculate proper VA after jump from 1:1 mapping */
> > la a0, .L_primary_switched
> > sub a0, a0, s2
>
> ... it could do with clarifying why this needs calling from assembly
> code. Mapping the FDT clearly looks like something that wants doing
> from start_xen(), i.e. from C code.
fdt_map() expected to work while MMU is off as it is using
setup_initial_mapping() which is working with physical address.
>
> > @@ -33,15 +35,34 @@ static void test_macros_from_bug_h(void)
> > printk("WARN is most likely working\n");
> > }
> >
> > +void __init fdt_map(paddr_t dtb_addr)
> > +{
> > + device_tree_flattened = early_fdt_map(dtb_addr);
> > + if ( !device_tree_flattened )
> > + {
> > + printk("wrong FDT\n");
> > + die();
> > + }
> > +}
> > +
> > void __init noreturn start_xen(unsigned long bootcpu_id,
> > paddr_t dtb_addr)
> > {
> > + size_t fdt_size;
> > + const char *cmdline;
> > +
> > remove_identity_mapping();
> >
> > trap_init();
> >
> > test_macros_from_bug_h();
> >
> > + fdt_size = boot_fdt_info(device_tree_flattened, dtb_addr);
>
> You don't use the return value anywhere below. What use is the local
> var
> then?
I returned just for debug ( to see what is the fdt size ), it can be
dropped now.
~ Oleksii
>
> Jan
>
> > + cmdline = boot_fdt_cmdline(device_tree_flattened);
> > + printk("Command line: %s\n", cmdline);
> > + cmdline_parse(cmdline);
> > +
> > printk("All set up\n");
> >
> > for ( ;; )
>
Re: [PATCH v1 4/5] xen/riscv: introduce device tree maping function
On Wed, 2024-07-10 at 12:38 +0200, Jan Beulich wrote:
> On 03.07.2024 12:42, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
> > ---
> > xen/arch/riscv/include/asm/config.h | 6 +
> > xen/arch/riscv/include/asm/mm.h | 2 ++
> > xen/arch/riscv/mm.c | 37
> > +
> > 3 files changed, 40 insertions(+), 5 deletions(-)
>
> I don't think a change like this can come without any description.
>
> > --- a/xen/arch/riscv/include/asm/config.h
> > +++ b/xen/arch/riscv/include/asm/config.h
> > @@ -74,6 +74,9 @@
> > #error "unsupported RV_STAGE1_MODE"
> > #endif
> >
> > +#define XEN_SIZE MB(2)
> > +#define XEN_VIRT_END (XEN_VIRT_START + XEN_SIZE)
>
> Probably wants accompanying by an assertion in the linker script. Or
> else
> how would one notice when Xen grows bigger than this?
I use XEN_SIZE in the linker script here:
ASSERT(_end - _start <= MB(2), "Xen too large for early-boot
assumptions")
>
> > @@ -99,6 +102,9 @@
> > #define VMAP_VIRT_START SLOTN(VMAP_SLOT_START)
> > #define VMAP_VIRT_SIZE GB(1)
> >
> > +#define BOOT_FDT_VIRT_START XEN_VIRT_END
> > +#define BOOT_FDT_VIRT_SIZE MB(4)
>
> Is the 4 selected arbitrarily, or derived from something?
Yes, it was chosen arbitrarily. I just checked that I don't have any
DTBs larger than 2 MB, but decided to add a little extra space and
doubled it to an additional 2 MB.
>
> Also maybe better to keep these #define-s sorted by address? (As to
> "keep":
> I didn't check whether they currently are.)
>
> > --- a/xen/arch/riscv/include/asm/mm.h
> > +++ b/xen/arch/riscv/include/asm/mm.h
> > @@ -255,4 +255,6 @@ static inline unsigned int
> > arch_get_dma_bitsize(void)
> > return 32; /* TODO */
> > }
> >
> > +void* early_fdt_map(paddr_t fdt_paddr);
>
> Nit: * and blank want to change places.
>
> > --- a/xen/arch/riscv/mm.c
> > +++ b/xen/arch/riscv/mm.c
> > @@ -1,5 +1,6 @@
> > /* SPDX-License-Identifier: GPL-2.0-only */
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -7,7 +8,9 @@
> > #include
> > #include
> > #include
> > +#include
>
> This wants to move up, to retain sorting.
>
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -20,7 +23,7 @@ struct mmu_desc {
> > unsigned int pgtbl_count;
> > pte_t *next_pgtbl;
> > pte_t *pgtbl_base;
> > -};
> > +} mmu_desc = { CONFIG_PAGING_LEVELS, 0, NULL, 0 };
>
> __initdata and static?
>
> > @@ -39,9 +42,11 @@ static unsigned long __ro_after_init
> > phys_offset;
> > * isn't 2 MB aligned.
> > *
> > * CONFIG_PAGING_LEVELS page tables are needed for the identity
> > mapping,
> > - * except that the root page table is shared with the initial
> > mapping
> > + * except that the root page table is shared with the initial
> > mapping.
> > + *
> > + * CONFIG_PAGING_LEVELS page tables are needed for device tree
> > mapping.
> > */
> > -#define PGTBL_INITIAL_COUNT ((CONFIG_PAGING_LEVELS - 1) * 2 + 1)
> > +#define PGTBL_INITIAL_COUNT ((CONFIG_PAGING_LEVELS - 1) * 3 + 1 +
> > 1)
>
> Considering what would happen if two or three more of such
> requirements
> were added, maybe better
>
> #define PGTBL_INITIAL_COUNT (CONFIG_PAGING_LEVELS * 3 - 1)
>
> ? However, why is it CONFIG_PAGING_LEVELS that's needed, and not
> CONFIG_PAGING_LEVELS - 1? The top level table is the same as the
> identity map's, isn't it?
The top level table is the same, but I just wanted to be sure that if
DTB size is bigger then 2Mb then we need 2xL0 page tables.
Am I missing something?
~ Oleksii
>
> > @@ -296,6 +299,30 @@ unsigned long __init calc_phys_offset(void)
> > return phys_offset;
> > }
> >
> > +void* __init early_fdt_map(paddr_t fdt_paddr)
>
> See earlier remark regarding * placement.
>
> Jan
Re: [PATCH v1 1/5] xen/device-tree: Move Arm's setup.c bootinfo functions to common
On Wed, 2024-07-10 at 12:23 +0200, Jan Beulich wrote: > On 03.07.2024 12:42, Oleksii Kurochko wrote: > > From: Shawn Anastasio > > > > Arm's setup.c contains a collection of functions for parsing memory > > map > > and other boot information from a device tree. Since these routines > > are > > generally useful on any architecture that supports device tree > > booting, > > move them into xen/common/device-tree. > > > > Suggested-by: Julien Grall > > Signed-off-by: Shawn Anastasio > > Signed-off-by: Oleksii Kurochko > > --- > > Changes in V5: > > - add xen/include/xen/bootfdt.h to MAINTAINERS file. > > - drop message "Early device tree parsing and". > > - After rebase on top of the current staging the following changes > > were done: > > - init bootinfo variable in with > > BOOTINFO_INIT; > > - update the code of dt_unreserved_regions(): > > CONFIG_STATIC_SHM related changes and getting of > > reserved_mem > > bootinfo_get_shmem() ?? > > - update the code of meminfo_overlap_check(): > > add check ( INVALID_PADDR == bank_start ) to if case. > > - update the code of check_reserved_regions_overlap(): > > CONFIG_STATIC_SHM related changes. > > - struct bootinfo was updated ( CONFIG_STATIC_SHM changes ) > > - add shared_meminfo ( because of CONFIG_STATIC_SHM ) > > - struct struct membanks was update with __struct group so > > is > > neeeded to be included in bootfdt.h > > - move BOOTINFO_ACPI_INIT, BOOTINFO_SHMEM_INIT, BOOTINFO_INIT to > > generic bootfdt.h > > - bootinfo_get_reserved_mem(), bootinfo_get_mem(), > > bootinfo_get_acpi(), > > bootinfo_get_shmem() and bootinfo_get_shmem_extra() were moved > > to xen/bootfdt.h > > - s/arm32/CONFIG_SEPARATE_XENHEAP/ > > - add inclusion of because there are function in > > which > > are using container_of(). > > Just to mention it: This is confusing. The series is tagged "v1". I > understand > you took Shawn's work, which had already undergone revisions. But > then imo you > want to at least clarify how your v1 relates to his v4 or v5, i.e. > then making > clear to the reader whether all of the changes above were actually > done by you > on top of an earlier v4, or whether you took the earlier v5 verbatim. That is why I wrote "Changes in v5" to show that these changes were done on top of v4 version of Shawn's series, so what is mentioned in v5 here it is what was done by me. I'll reword that and probably I shouldn't drop "Changes in v4,3,2,1" from Shawn's patch. ~ Oleksii
Re: [PATCH for-4.20 v2] automation: Use a different ImageBuilder repository URL
On Thu, 2024-07-11 at 10:14 +0200, Michal Orzel wrote: > Hi Oleksii, > > On 11/07/2024 10:11, Oleksii wrote: > > > > > > On Wed, 2024-07-10 at 10:44 +0100, Andrew Cooper wrote: > > > On 10/07/2024 10:37 am, Michal Orzel wrote: > > > > Switch to using > > > > https://gitlab.com/xen-project/imagebuilder.git which > > > > should be considered official ImageBuilder repo. > > > > > > > > Take the opportunity to truncate the git history when cloning > > > > using > > > > --depth 1. > > > > > > > > Signed-off-by: Michal Orzel > > > > Reviewed-by: Stefano Stabellini > > > > > > Given the current overhaul I'm (still) doing for CI in 4.19, I'd > > > suggest > > > taking this. > > > > -git clone https://gitlab.com/ViryaOS/imagebuilder > > +git clone https://gitlab.com/xen-project/imagebuilder.git > > > > But is it the same imagebuilders and only location is changed? > That's the same project but the repo under xen-project is more up-to- > date and we decided > that it should be considered the official repo location. Then I am okay to have this change in 4.19: Release-Acked-By: Oleksii Kurochko ~ Oleksii
Re: [PATCH v9 5/5] xen/riscv: test basic handling stuff
On Wed, 2024-07-10 at 12:07 +0200, Jan Beulich wrote:
> On 10.07.2024 12:06, Jan Beulich wrote:
> > On 02.07.2024 13:23, Oleksii Kurochko wrote:
> > > Signed-off-by: Oleksii Kurochko
> > > Acked-by: Alistair Francis
> > > ---
> > > xen/arch/riscv/setup.c | 16
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
> > > index a6a29a1508..4f06203b46 100644
> > > --- a/xen/arch/riscv/setup.c
> > > +++ b/xen/arch/riscv/setup.c
> > > @@ -19,6 +19,20 @@ void arch_get_xen_caps(xen_capabilities_info_t
> > > *info)
> > > unsigned char __initdata cpu0_boot_stack[STACK_SIZE]
> > > __aligned(STACK_SIZE);
> > >
> > > +static void test_run_in_exception(const struct cpu_user_regs
> > > *regs)
> > > +{
> > > + printk("If you see this message, ");
> > > + printk("run_in_exception_handler is most likely working\n");
> > > +}
> > > +
> > > +static void test_macros_from_bug_h(void)
> > > +{
> > > + run_in_exception_handler(test_run_in_exception);
> > > + WARN();
> > > + printk("If you see this message, ");
> > > + printk("WARN is most likely working\n");
> > > +}
> >
> > While for the moment this may be okay, in the longer run WARN()
> > will cause
> > quite a bit of output that you don't want on every boot. The
> > further plans
> > here will want mentioning in the description.
> >
> > Additionally as part of re-basing I think you would have wanted to
> > put this
> > under the (relatively new) SELF_TESTS Kconfig control.
I will consider SELF_TESTS Kconfig, there is not a lot of sense to
print that every boot.
>
> Oh, and: Is it possible there's a word ("exception"?) missing from
> the title?
Yes, I missed that. I will update the title to: " test basic exception
handling stuff ". Thanks.
~ Oleksii
Re: [PATCH v9 4/5] xen/riscv: enable GENERIC_BUG_FRAME
On Wed, 2024-07-10 at 12:01 +0200, Jan Beulich wrote:
> On 02.07.2024 13:23, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
> > ---
> > xen/arch/riscv/Kconfig | 1 +
> > xen/arch/riscv/traps.c | 31 +++
> > xen/common/bug.c | 1 +
> > 3 files changed, 33 insertions(+)
> >
> > diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig
> > index b4b354a778..74ad019fe7 100644
> > --- a/xen/arch/riscv/Kconfig
> > +++ b/xen/arch/riscv/Kconfig
> > @@ -5,6 +5,7 @@ config RISCV
> > config RISCV_64
> > def_bool y
> > select 64BIT
> > + select GENERIC_BUG_FRAME
>
> Any particular reason to put this here, and not higher up with RISCV?
Yes, you are right it would be better to put it inside "config RISCV".
>
> > @@ -101,8 +102,38 @@ static void do_unexpected_trap(const struct
> > cpu_user_regs *regs)
> > die();
> > }
> >
> > +static bool is_valid_bug_insn(uint32_t insn)
> > +{
> > + return insn == BUG_INSN_32 ||
> > + (insn & COMPRESSED_INSN_MASK) == BUG_INSN_16;
> > +}
> > +
> > +/* Should be used only on Xen code */
> > +static uint32_t read_instr(unsigned long pc)
> > +{
> > + uint16_t instr16 = *(uint16_t *)pc;
> > +
> > + ASSERT(is_kernel_text(pc + 1) || is_kernel_inittext(pc + 1));
> > +
> > + if ( GET_INSN_LENGTH(instr16) == 2 )
> > + return instr16;
> > +
> > + ASSERT(is_kernel_text(pc + 3) || is_kernel_inittext(pc + 3));
> > +
> > + return *(uint32_t *)pc;
> > +}
>
> Related to the point made further down: If either of these assertions
> fails,
> won't we come back again right here? If either of the
> is_kernel_*text()
> wasn't working quite right, wouldn't we be at risk of entering an
> infinite
> loop (presumably not quite infinite because of the stack overflowing
> at some
> point)?
It is really possible to have infinite loop here so it should be better
to use 'if' with die() or panic().
>
> > void do_trap(struct cpu_user_regs *cpu_regs)
> > {
> > + register_t pc = cpu_regs->sepc;
> > + uint32_t instr = read_instr(pc);
> > +
> > + if ( ( is_valid_bug_insn(instr) ) && ( do_bug_frame(cpu_regs,
> > pc) >= 0 ) )
>
> No consideration of the kind of exception? I'd expect it is one very
> specific one which the BUG insn would raise, and then there's no
> point
> fetching the insn when it's a different kind of exception.
Good point.
We should have 0x3 ( breakpoint exception ) in scause register. We can
just check that without reading instruction and then also
is_valid_bug_insn could be dropped too.
>
> Further, nit: Certainly no need for the parentheses on the lhs of the
> &&.
> Having them on the rhs is a matter of taste, so okay, but then the
> blanks immediately inside will want dropping.
>
>
> > --- a/xen/common/bug.c
> > +++ b/xen/common/bug.c
> > @@ -1,6 +1,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
>
> Unrelated change? Or did you simply forget to mention in the
> description
> why it's needed?
I added it to "Changes in ..." which I forgot to add, but I will add an
explanation to the description. It is better place for it.
is needed to be included for the reason that panic() and
printk() is used in common/bug.c and RISC-V fails if it is not included
with the following errors:
common/bug.c:69:9: error: implicit declaration of function 'printk'
[-Werror=implicit-function-declaration]
69 | printk("Xen WARN at %s%s:%d\n", prefix, filename,
lineno);
| ^~
common/bug.c:77:9: error: implicit declaration of function 'panic'
[-Werror=implicit-function-declaration]
77 | panic("Xen BUG at %s%s:%d\n", prefix, filename,
lineno);
>
> ~ Oleksii
Re: [PATCH v9 3/5] xen/riscv: introduce trap_init()
On Wed, 2024-07-10 at 11:50 +0200, Jan Beulich wrote: > On 02.07.2024 13:23, Oleksii Kurochko wrote: > > --- a/xen/arch/riscv/traps.c > > +++ b/xen/arch/riscv/traps.c > > @@ -12,6 +12,18 @@ > > #include > > #include > > > > +/* > > + * Initialize the trap handling. > > + * > > + * The function is called after MMU is enabled. > > + */ > > +void trap_init(void) > > It may be deliberate that this isn't __init, but for the present > needs it > certainly could be. This is the kind of thing that imo want saying in > the > description (which sadly once again is entirely empty). I just missed to add __init so I have to added it in the next patch version. Thanks for finding that. ~ Oleksii
Re: [PATCH v9 1/5] xen/riscv: use printk() instead of early_printk()
On Wed, 2024-07-10 at 11:46 +0200, Jan Beulich wrote: > On 02.07.2024 13:23, Oleksii Kurochko wrote: > > As common code is available it is better to use printk() instead > > of early_printk(). > > IOW the function is not just available (allowing linking to succeed), > but is also fully functional (i.e. the line is making it out, and > hence > CI, which iirc is looking for that string, is going to be "happy")? > If > so: > Acked-by: Jan Beulich I ran our gitlab CI and it works well on my side: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/1355999714 ~ Oleksii
Re: [PATCH for-4.20 v2] automation: Use a different ImageBuilder repository URL
On Wed, 2024-07-10 at 10:44 +0100, Andrew Cooper wrote: > On 10/07/2024 10:37 am, Michal Orzel wrote: > > Switch to using > > https://gitlab.com/xen-project/imagebuilder.git which > > should be considered official ImageBuilder repo. > > > > Take the opportunity to truncate the git history when cloning using > > --depth 1. > > > > Signed-off-by: Michal Orzel > > Reviewed-by: Stefano Stabellini > > Given the current overhaul I'm (still) doing for CI in 4.19, I'd > suggest > taking this. -git clone https://gitlab.com/ViryaOS/imagebuilder +git clone https://gitlab.com/xen-project/imagebuilder.git But is it the same imagebuilders and only location is changed? ~ Oleksii > > It will mean an 8-month improvement in switching over fully. > > ~Andrew
Re: [PATCH for-4.19?] stubdom: Remove more leftovers of caml-stubdom
On Tue, 2024-07-09 at 13:39 +0100, Andrew Cooper wrote:
> Fixes: e536a497545f ("stubdom: Remove caml-stubdom")
> Signed-off-by: Andrew Cooper
> ---
> CC: Juergen Gross
> CC: Oleksii Kurochko
>
> For 4.19. This is additional tidying to a removal in 4.19, which
> will
> otherwise need backporting if it misses 4.19.
Release-Acked-By: Oleksii Kurochko
~ Oleksii
> ---
> config/Stubdom.mk.in | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/config/Stubdom.mk.in b/config/Stubdom.mk.in
> index 5990fc4e04f9..b399d77740e8 100644
> --- a/config/Stubdom.mk.in
> +++ b/config/Stubdom.mk.in
> @@ -26,9 +26,6 @@ LWIP_URL := @LWIP_URL@
> GRUB_VERSION := @GRUB_VERSION@
> GRUB_URL := @GRUB_URL@
>
> -OCAML_VERSION := @OCAML_VERSION@
> -OCAML_URL := @OCAML_URL@
> -
> GMP_VERSION := @GMP_VERSION@
> GMP_URL := @GMP_URL@
>
>
> base-commit: c4ebeb79d10a25e8d48a71cdd381898265267e67
Xen 4.19-rc2
Hi all, Xen 4.19-rc2 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.19.0-rc2 For your convenience there is also a tarball and the signature at: https://downloads.xenproject.org/release/xen/4.19.0-rc2/xen-4.19.0-rc2.tar.gz And the signature is at: https://downloads.xenproject.org/release/xen/4.19.0-rc2/xen-4.19.0-rc2.tar.gz.sig Please send bug reports and test reports to xen-devel@lists.xenproject.org<mailto:xen-devel@lists.xenproject.org>. When sending bug reports, please CC relevant maintainers and me (oleskii.kuroc...@gmail.com<mailto:oleskii.kuroc...@gmail.com). Best regards, Oleksii
Re: [PATCH for-4.19 0/6] CI: Fixes, part 2
On Fri, 2024-07-05 at 16:20 +0100, Andrew Cooper wrote: > Work to fix a few build system checks, and to strip the obsolete > contents of > the build containers, prior to adding new containers (will be part > 3). > > Andrew Cooper (6): > build: Regenerate ./configure with Autoconf 2.71 > build: Fix the version of python checked for by ./configure > CI: Refresh the Coverity Github Action configuration > build: Drop openssl as a build dependency > build: Drop libiconv as a build dependecy > build: Drop xorg-x11 as a build dependency > > .cirrus.yml | 2 +- > .github/workflows/coverity.yml | 36 +- > README | 2 - > .../build/debian/bookworm-arm64v8.dockerfile | 2 - > .../build/debian/bookworm-i386.dockerfile | 2 - > automation/build/debian/bookworm.dockerfile | 2 - > .../build/debian/jessie-i386.dockerfile | 2 - > automation/build/debian/jessie.dockerfile | 2 - > .../build/debian/stretch-i386.dockerfile | 2 - > automation/build/debian/stretch.dockerfile | 2 - > automation/build/fedora/29.dockerfile | 1 - > automation/build/ubuntu/bionic.dockerfile | 2 - > automation/build/ubuntu/focal.dockerfile | 2 - > automation/build/ubuntu/trusty.dockerfile | 2 - > automation/build/ubuntu/xenial.dockerfile | 2 - > .../kernel/5.19-arm64v8.dockerfile | 1 - > .../tests-artifacts/kernel/6.1.19.dockerfile | 1 - > config/Tools.mk.in | 1 - > configure | 1006 +-- > docs/configure | 990 +-- > stubdom/configure | 2293 -- > tools/config.h.in | 15 +- > tools/configure | 6397 +-- > -- > tools/configure.ac | 4 +- > 24 files changed, 6136 insertions(+), 4635 deletions(-) > Release-Acked-by: Oleksii Kurochko ~ Oleksii
Re: [PATCH for-4.19 v2] x86/physdev: Return pirq that irq was already mapped to
On Mon, 2024-07-08 at 11:32 +0100, Andrew Cooper wrote:
> On 08/07/2024 9:04 am, Jiqian Chen wrote:
> > Fix bug introduced by 0762e2502f1f ("x86/physdev: factor out the
> > code to allocate and
> > map a pirq"). After that re-factoring, when pirq<0 and
> > current_pirq>0, it means
> > caller want to allocate a free pirq for irq but irq already has a
> > mapped pirq, then
> > it returns the negative pirq, so it fails. However, the logic
> > before that
> > re-factoring is different, it should return the current_pirq that
> > irq was already
> > mapped to and make the call success.
> >
> > Fixes: 0762e2502f1f ("x86/physdev: factor out the code to allocate
> > and map a pirq")
> >
> > Signed-off-by: Jiqian Chen
> > Signed-off-by: Huang Rui
> > Signed-off-by: Jiqian Chen
> > Reviewed-by: Jan Beulich
>
> As a minor note, we treat Fixes: as a tag like all the others, so
> tend
> not to have a blank line between it an the SoB.
>
> Can be fixed on commit - no need to resend.
Release-Acked-By: Oleksii Kurochko
~ Oleksii
