Re: [PATCH v3 0/5] Support Secure Boot for multiboot2 Xen
On 2/22/21 11:16 PM, Jan Beulich wrote: > It is on my list of things to look at. While probably not a good excuse, > my looking at previous versions of this makes we somewhat hesitant to > open any of these patch mails ... But I mean to get to it. > > Jan > Thanks for this response. I did comb through your v2 feedback point-by-point and incorporate it into the code, so I do hope that ends up helping. Best, Bob
Re: [PATCH v3 4/5] xen/x86: add some addresses to the Multiboot2 header
On 2/23/21 1:04 AM, Roger Pau Monné wrote: > On Thu, Jan 21, 2021 at 04:51:43PM -0800, Bobby Eshleman wrote: >> From: Daniel Kiper >> >> In comparison to ELF the PE format is not supported by the Multiboot2 >> protocol. So, if we wish to load xen.mb.efi using this protocol we have >> to add MULTIBOOT2_HEADER_TAG_ADDRESS and MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS >> tags into Multiboot2 header. >> >> Additionally, put MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS and >> MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64 tags close to each >> other to make the header more readable. >> >> The Multiboot2 protocol spec can be found at >> https://www.gnu.org/software/grub/manual/multiboot2/ >> >> Signed-off-by: Daniel Kiper >> Signed-off-by: Bobby Eshleman >> --- >> xen/arch/x86/boot/head.S | 19 +++ >> 1 file changed, 15 insertions(+), 4 deletions(-) >> >> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S >> index 189d91a872..f2edd182a5 100644 >> --- a/xen/arch/x86/boot/head.S >> +++ b/xen/arch/x86/boot/head.S >> @@ -94,6 +94,13 @@ multiboot2_header: >> /* Align modules at page boundry. */ >> mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED) >> >> +/* The address tag. */ >> +mb2ht_init MB2_HT(ADDRESS), MB2_HT(REQUIRED), \ >> + sym_offs(multiboot2_header), /* header_addr */ \ >> + sym_offs(start), /* load_addr */ \ >> + sym_offs(__bss_start), /* load_end_addr */ \ >> + sym_offs(__2M_rwdata_end)/* bss_end_addr */ > > Shouldn't this only be present when a PE binary is built? > > You seem to unconditionally add this to the header, even when the > resulting binary will be in ELF format? > > According to the spec: "This information does not need to be provided > if the kernel image is in ELF format", and hence Xen shouldn't require > the loader to understand this tag unless it's strictly required, as > the presence of the tag forces the bootloader to use the presented > information in order to load the kernel, regardless of the underlying > binary format. > > Thanks, Roger. > Ah yes, this is true. It may have made more sense to do this with v2 trying to step us in the direction of a single unified binary, but it certainly isn't required with v3. Thanks, Bob
Re: [PATCH for-next 3/6] xen/sched: Fix build when NR_CPUS == 1
On 2/25/21 7:24 AM, Connor Davis wrote: > Return from cpu_schedule_up when either cpu is 0 or > NR_CPUS == 1. This fixes the following: > > core.c: In function 'cpu_schedule_up': > core.c:2769:19: error: array subscript 1 is above array bounds > of 'struct vcpu *[1]' [-Werror=array-bounds] > 2769 | if ( idle_vcpu[cpu] == NULL ) > | > > Signed-off-by: Connor Davis > --- > xen/common/sched/core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c > index 9745a77eee..f5ec65bf9b 100644 > --- a/xen/common/sched/core.c > +++ b/xen/common/sched/core.c > @@ -2763,7 +2763,7 @@ static int cpu_schedule_up(unsigned int cpu) > cpumask_set_cpu(cpu, &sched_res_mask); > > /* Boot CPU is dealt with later in scheduler_init(). */ > -if ( cpu == 0 ) > +if ( cpu == 0 || NR_CPUS == 1 ) > return 0; > > if ( idle_vcpu[cpu] == NULL ) > Interesting. I wonder when this changed in GCC. I haven't yet seen this issue compiling with: NR_CPUS=1 ARCH=riscv64 riscv64-unknown-linux-gnu-gcc (GCC) 10.1.0 Which version of GCC are you seeing emit this? - Bob
Re: [XEN PATCH v6 18/31] xen: move include/asm-* to include/arch-*/asm
Hey Anthony, > diff --git a/MAINTAINERS b/MAINTAINERS > index 8a52a03969fe..03a5553116a8 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > -F: xen/include/asm-arm/ > +F: xen/include/arch-arm/ ... snip ... > -F: xen/include/asm-x86/ > +F: xen/include/arch-x86/ It looks like riscv will also need the same in its "xen/include/asm-riscv/" F entry. Thanks -- Bobby Eshleman SE at Vates SAS
Re: [XEN PATCH v6 29/31] build: build everything from the root dir, use obj=$subdir
On 7/1/21 7:10 AM, Anthony PERARD wrote: > A subdirectory is now built by setting "$(obj)" instead of changing > directory. "$(obj)" should always be set when using "Rules.mk" and > thus a shortcut "$(build)" is introduced and should be used. > > A new variable "$(need-builtin)" is introduce. It is to be used > whenever a "built_in.o" is wanted from a subdirectory. "built_in.o" > isn't the main target anymore, and thus only needs to depends on the > objects that should be part of "built_in.o". > > Introduce $(srctree) and $(objtree) to replace $(BASEDIR) in cases a > relative path is better. > > DEPS is updated as the existing macro to deal with it doesn't know > about $(obj). > > There's some changes in "Rules.mk" which in addition to deal with > "$(obj)" also make it's looks more like "Makefile.build" from Linux > v5.12. > > test/Makefile doesn't need special handling in order to build > everything under test/, Rules.mk will visit test/livepatch via > $(subdir-y), thus "tests" "all" and "build" target are removed. > "subtree-force-update" target isn't useful so it is removed as well. > > test/livepatch/Makefile doesn't need default target anymore, Rules.mk > will build everything in $(extra-y) and thus all *.livepatch. > > Signed-off-by: Anthony PERARD Acked-by: Bob Eshleman Thanks, Bobby
Re: [XEN PATCH v6 31/31] build,riscv: tell the build system about riscv64/head.S
On 7/1/21 7:10 AM, Anthony PERARD wrote: > This allows to `make arch/riscv/riscv64/head.o`. > > Example of rune on a fresh copy of the repository: > make XEN_TARGET_ARCH=riscv64 CROSS_COMPILE=riscv64-linux-gnu- > KBUILD_DEFCONFIG=tiny64_defconfig arch/riscv/riscv64/head.o > > Signed-off-by: Anthony PERARD > --- > xen/arch/riscv/riscv64/Makefile | 1 + > 1 file changed, 1 insertion(+) > create mode 100644 xen/arch/riscv/riscv64/Makefile > > diff --git a/xen/arch/riscv/riscv64/Makefile b/xen/arch/riscv/riscv64/Makefile > new file mode 100644 > index ..15a4a65f6615 > --- /dev/null > +++ b/xen/arch/riscv/riscv64/Makefile > @@ -0,0 +1 @@ > +extra-y += head.o > Acked-by: Bob Eshleman -- Bobby Eshleman SE at Vates SAS
Re: [PATCH 1/4] build: use common stubs for debugger_trap_* functions if !CONFIG_CRASH_DEBUG
On 7/14/21 2:34 AM, Jan Beulich wrote: > > ... we strive to have new insertions be sorted alphabetically. When > the existing section to insert into isn't suitably sorted yet, what > I normally do is try to find a place where at least the immediately > adjacent neighbors then fit the sorting goal. > > Sorry, all just nits, but their scope is about the entire patch. > No worries at all, I welcome the corrections (I need to learn the proper style somehow). >> --- /dev/null >> +++ b/xen/include/xen/debugger.h ... >> + >> +static inline bool debugger_trap_fatal( >> +unsigned int vector, const struct cpu_user_regs *regs) > > I'm afraid the concept of a vector may not be arch-independent. > The only way I can imagine it not being arch-independent is if it is thought of as a trap number or id, instead of implying an entry in a vectored trap table. I don't really understand this subsystem, so I'm probably missing context. Are you suggesting a rename or a different approach entirely? > > Jan > Thanks Jan, everything besides the vector thing are incorporated in the v2 I've just sent out. -- Bobby Eshleman SE at Vates SAS
Re: [PATCH v3 2/5] xen/x86: manually build xen.mb.efi binary
Jan, I mulled over your feedback and I think I can now see your reservations with this series. I'm wondering if the long-term goal of using the xen mb1/mb2 binary as the basis for creating a EFI loadable mb1/mb2 payload is actually the wrong approach. After all, I do not see a feasible way to maintain the comprehensive sectioning, the proper reloc table, the proper debug directory, etc... that is found in the current xen.efi using the approach in this series, which would mean maintaining a third binary forever. What is your intuition WRT the idea that instead of trying add a PE/COFF hdr in front of Xen's mb2 bin, we instead go the route of introducing valid mb2 entry points into xen.efi? At the end of the day, our goal is just to have a binary that meets these requirements: * Is verifiable with shim (PE/COFF) * May boot on BIOS platforms via grub2 * May boot on EFI platforms via grub2 or EFI loader Thanks -- Bobby Eshleman SE at Vates SAS
Re: [PATCH v3 5/5] automation: Add container for riscv64 builds
On 5/14/21 11:53 AM, Connor Davis wrote: > + > +# There is a regression in GDB that causes an assertion error > +# when setting breakpoints, use this commit until it is fixed! > +RUN git clone --recursive -j$(nproc) --progress > https://github.com/riscv/riscv-gnu-toolchain && \ > +cd riscv-gnu-toolchain/riscv-gdb && \ > +git checkout 1dd588507782591478882a891f64945af9e2b86c && \ > +cd .. && \ > +./configure --prefix=/opt/riscv && \ > +make linux -j$(nproc) && \ > +rm -R /riscv-gnu-toolchai What do you think about using the RISCV tool chain from the Arch repos now? I've also discovered that the sym table error avoided by the commit pin can be worked around by removing already loaded symbols with `file` (no args) prior to calling `file path/to/file` to load new ones. So if people did still want to use the container for development, they could still use the gdb installed by pacman (with the symbols caveat). -- Bobby Eshleman SE at Vates SAS
Re: [PATCH v3 4/5] xen: Add files needed for minimal riscv build
On 5/14/21 11:53 AM, Connor Davis wrote: > Add arch-specific makefiles and configs needed to build for > riscv64. Also add a minimal head.S that is a simple infinite loop. > head.o can be built with > > $ make XEN_TARGET_ARCH=riscv64 SUBSYSTEMS=xen -C xen TARGET=head.o > I recently realized that the Linux kernel build uses `ARCH=riscv` with 32 vs 64 being differentiated by Kconfig opts (and __riscv_xlen). I think `riscv64` was inherited by `arm64`. This is something I'd like to eventually change the Xen build to (i.e., `XEN_TARGET_ARCH=riscv make`) would it be possible for us to get that in this series? ... > diff --git a/xen/include/asm-riscv/config.h b/xen/include/asm-riscv/config.h > new file mode 100644 > index 00..84cb436dc1 > --- /dev/null > +++ b/xen/include/asm-riscv/config.h > @@ -0,0 +1,110 @@ > +/** > + * config.h > + * > + * A Linux-style configuration list. > + */ > + > +#ifndef __RISCV_CONFIG_H__ > +#define __RISCV_CONFIG_H__ > + ... > + > +#ifdef CONFIG_RISCV_64 > + > +/* > + * RISC-V Layout: > + * 0x - 0x003f (256GB, L2 slots [0-255]) > + * Unmapped > + * 0x0040 - 0xffbf > + * Inaccessible: sv39 only supports 39-bit sign-extended VAs. > + * 0xffc0 - 0xffc0001f (2MB, L2 slot [256]) > + * Unmapped > + * 0xffc00020 - 0xffc0003f (2MB, L2 slot [256]) > + * Xen text, data, bss > + * 0xffc00040 - 0xffc0005f (2MB, L2 slot [256]) > + * Fixmap: special-purpose 4K mapping slots > + * 0xffc00060 - 0xffc0009f (4MB, L2 slot [256]) > + * Early boot mapping of FDT > + * 0xffc000a0 - 0xffc000bf (2MB, L2 slot [256]) > + * Early relocation address, used when relocating Xen and later > + * for livepatch vmap (if compiled in) > + * 0xffc04000 - 0xffc07fff (1GB, L2 slot [257]) > + * VMAP: ioremap and early_ioremap > + * 0xffc08000 - 0xffc13fff (3GB, L2 slots [258..260]) > + * Unmapped > + * 0xffc14000 - 0xffc1bfff (2GB, L2 slots [261..262]) > + * Frametable: 48 bytes per page for 133GB of RAM > + * 0xffc1c000 - 0xffe1bfff (128GB, L2 slots [263..390]) > + * 1:1 direct mapping of RAM > + * 0xffe1c000 - 0x (121GB, L2 slots [391..511]) > + * Unmapped > + */ > + What is the benefit of moving the layout up to 0xffc0? -- Bobby Eshleman SE at Vates SAS
Re: [PATCH v3 4/5] xen: Add files needed for minimal riscv build
On 5/14/21 4:47 PM, Connor Davis wrote: > > On 5/14/21 3:53 PM, Bob Eshleman wrote: >> On 5/14/21 11:53 AM, Connor Davis wrote: >> >>> + >>> +#ifdef CONFIG_RISCV_64 >>> + >>> +/* >>> + * RISC-V Layout: >>> + * 0x - 0x003f (256GB, L2 slots [0-255]) >>> + * Unmapped >>> + * 0x0040 - 0xffbf >>> + * Inaccessible: sv39 only supports 39-bit sign-extended VAs. >>> + * 0xffc0 - 0xffc0001f (2MB, L2 slot [256]) >>> + * Unmapped >>> + * 0xffc00020 - 0xffc0003f (2MB, L2 slot [256]) >>> + * Xen text, data, bss >>> + * 0xffc00040 - 0xffc0005f (2MB, L2 slot [256]) >>> + * Fixmap: special-purpose 4K mapping slots >>> + * 0xffc00060 - 0xffc0009f (4MB, L2 slot [256]) >>> + * Early boot mapping of FDT >>> + * 0xffc000a0 - 0xffc000bf (2MB, L2 slot [256]) >>> + * Early relocation address, used when relocating Xen and later >>> + * for livepatch vmap (if compiled in) >>> + * 0xffc04000 - 0xffc07fff (1GB, L2 slot [257]) >>> + * VMAP: ioremap and early_ioremap >>> + * 0xffc08000 - 0xffc13fff (3GB, L2 slots [258..260]) >>> + * Unmapped >>> + * 0xffc14000 - 0xffc1bfff (2GB, L2 slots [261..262]) >>> + * Frametable: 48 bytes per page for 133GB of RAM >>> + * 0xffc1c000 - 0xffe1bfff (128GB, L2 slots [263..390]) >>> + * 1:1 direct mapping of RAM >>> + * 0xffe1c000 - 0x (121GB, L2 slots [391..511]) >>> + * Unmapped >>> + */ >>> + >> What is the benefit of moving the layout up to 0xffc0? > > I thought it made the most sense to use the upper half since Xen is privileged > > and privileged code is typically mapped in the upper half, at least on x86. > I'm happy to > > move it down if that would be preferred. > > I do like the idea of following norms, but I think I prefer following the ARM norm over the x86 norm unless there is a technical reason not to. Just due to ARM and RISC-V having much more overlap than x86 and RISC-V. In this case, all things being equal, I'd prefer following the ARM model and use the lower half. I definitely like adding the note on the inaccessible region. Thanks, -- Bobby Eshleman SE at Vates SAS
Re: [PATCH v4 3/4] xen: Add files needed for minimal riscv build
On 5/25/21 1:48 AM, Jan Beulich wrote: > On 24.05.2021 16:34, Connor Davis wrote: >> Add arch-specific makefiles and configs needed to build for >> riscv. Also add a minimal head.S that is a simple infinite loop. >> head.o can be built with >> >> $ make XEN_TARGET_ARCH=riscv SUBSYSTEMS=xen -C xen tiny64_defconfig >> $ make XEN_TARGET_ARCH=riscv SUBSYSTEMS=xen -C xen TARGET=head.o >> >> No other TARGET is supported at the moment. >> >> Signed-off-by: Connor Davis >> --- >> config/riscv.mk | 4 +++ >> xen/Makefile| 8 +++-- >> xen/arch/riscv/Kconfig | 47 + >> xen/arch/riscv/Kconfig.debug| 0 >> xen/arch/riscv/Makefile | 0 >> xen/arch/riscv/Rules.mk | 0 >> xen/arch/riscv/arch.mk | 14 >> xen/arch/riscv/asm-offsets.c| 0 >> xen/arch/riscv/configs/tiny64_defconfig | 13 +++ >> xen/arch/riscv/head.S | 6 >> xen/include/asm-riscv/config.h | 47 + >> 11 files changed, 137 insertions(+), 2 deletions(-) >> create mode 100644 config/riscv.mk >> create mode 100644 xen/arch/riscv/Kconfig >> create mode 100644 xen/arch/riscv/Kconfig.debug >> create mode 100644 xen/arch/riscv/Makefile >> create mode 100644 xen/arch/riscv/Rules.mk >> create mode 100644 xen/arch/riscv/arch.mk >> create mode 100644 xen/arch/riscv/asm-offsets.c >> create mode 100644 xen/arch/riscv/configs/tiny64_defconfig >> create mode 100644 xen/arch/riscv/head.S >> create mode 100644 xen/include/asm-riscv/config.h > > I think this wants to be accompanied by an addition to ./MAINTAINERS > right away, such that future RISC-V patches can be acked by the > respective designated maintainers, rather than falling under "THE REST". > Question is whether you / we have settled yet who's to become arch > maintainer there. > > Jan > I'd like to volunteer myself for this, as I'm slated to continue with the port indefinitely and would at least like to review patches. If Connor has the time, I think it makes sense for him to be listed there too. Until we have others (it's just us two right now), it'll be a lot of us reviewing each other's arch-specific work (in addition to reviewers elsewhere in the Xen project, of course). -Bobby -- Bobby Eshleman SE at Vates SAS
Re: [PATCH v8 2/2] xen: Add files needed for minimal riscv build
On 6/3/21 7:14 PM, Connor Davis wrote: > Add arch-specific makefiles and configs needed to build for > riscv. Also add a minimal head.S that is a simple infinite loop. > head.o can be built with > > $ make XEN_TARGET_ARCH=riscv64 SUBSYSTEMS=xen -C xen tiny64_defconfig > $ make XEN_TARGET_ARCH=riscv64 SUBSYSTEMS=xen -C xen TARGET=riscv64/head.o > > No other TARGET is supported at the moment. > > Signed-off-by: Connor Davis > Reviewed-by: Alistair Francis > --- > MAINTAINERS | 9 + > config/riscv64.mk | 5 +++ > xen/Makefile| 8 +++-- > xen/arch/riscv/Kconfig | 48 + > xen/arch/riscv/Kconfig.debug| 0 > xen/arch/riscv/Makefile | 2 ++ > xen/arch/riscv/Rules.mk | 0 > xen/arch/riscv/arch.mk | 14 > xen/arch/riscv/configs/tiny64_defconfig | 13 +++ > xen/arch/riscv/riscv64/asm-offsets.c| 0 > xen/arch/riscv/riscv64/head.S | 6 > xen/include/asm-riscv/config.h | 47 > 12 files changed, 150 insertions(+), 2 deletions(-) > create mode 100644 config/riscv64.mk > create mode 100644 xen/arch/riscv/Kconfig > create mode 100644 xen/arch/riscv/Kconfig.debug > create mode 100644 xen/arch/riscv/Makefile > create mode 100644 xen/arch/riscv/Rules.mk > create mode 100644 xen/arch/riscv/arch.mk > create mode 100644 xen/arch/riscv/configs/tiny64_defconfig > create mode 100644 xen/arch/riscv/riscv64/asm-offsets.c > create mode 100644 xen/arch/riscv/riscv64/head.S > create mode 100644 xen/include/asm-riscv/config.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index d46b08a0d2..5a1f92422a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -456,6 +456,15 @@ F: tools/libs/light/libxl_nonetbuffer.c > F: tools/hotplug/Linux/remus-netbuf-setup > F: tools/hotplug/Linux/block-drbd-probe > > +RISCV > +M: Bob Eshleman > +M: Alistair Francis > +R: Connor Davis > +S: Supported > +F: config/riscv64.mk > +F: xen/arch/riscv/ > +F: xen/include/asm-riscv/ > + > RTDS SCHEDULER > M: Dario Faggioli > M: Meng Xu > diff --git a/config/riscv64.mk b/config/riscv64.mk > new file mode 100644 > index 00..a5a21e5fa2 > --- /dev/null > +++ b/config/riscv64.mk > @@ -0,0 +1,5 @@ > +CONFIG_RISCV := y > +CONFIG_RISCV_64 := y > +CONFIG_RISCV_$(XEN_OS) := y > + > +CONFIG_XEN_INSTALL_SUFFIX := > diff --git a/xen/Makefile b/xen/Makefile > index 7ce7692354..89879fad4c 100644 > --- a/xen/Makefile > +++ b/xen/Makefile > @@ -26,7 +26,9 @@ MAKEFLAGS += -rR > EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi > > ARCH=$(XEN_TARGET_ARCH) > -SRCARCH=$(shell echo $(ARCH) | sed -e 's/x86.*/x86/' -e > s'/arm\(32\|64\)/arm/g') > +SRCARCH=$(shell echo $(ARCH) | \ > + sed -e 's/x86.*/x86/' -e s'/arm\(32\|64\)/arm/g' \ > + -e s'/riscv.*/riscv/g') > > # Don't break if the build process wasn't called from the top level > # we need XEN_TARGET_ARCH to generate the proper config > @@ -35,7 +37,8 @@ include $(XEN_ROOT)/Config.mk > # Set ARCH/SUBARCH appropriately. > export TARGET_SUBARCH := $(XEN_TARGET_ARCH) > export TARGET_ARCH := $(shell echo $(XEN_TARGET_ARCH) | \ > -sed -e 's/x86.*/x86/' -e s'/arm\(32\|64\)/arm/g') > +sed -e 's/x86.*/x86/' -e s'/arm\(32\|64\)/arm/g' > \ > +-e s'/riscv.*/riscv/g') > > # Allow someone to change their config file > export KCONFIG_CONFIG ?= .config > @@ -335,6 +338,7 @@ _clean: delete-unfresh-files > $(MAKE) $(clean) xsm > $(MAKE) $(clean) crypto > $(MAKE) $(clean) arch/arm > + $(MAKE) $(clean) arch/riscv > $(MAKE) $(clean) arch/x86 > $(MAKE) $(clean) test > $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) > SRCARCH=$(SRCARCH) clean > diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig > new file mode 100644 > index 00..468e250c86 > --- /dev/null > +++ b/xen/arch/riscv/Kconfig > @@ -0,0 +1,48 @@ > +config RISCV > + def_bool y > + > +config RISCV_64 > + def_bool y > + select 64BIT > + > +config ARCH_DEFCONFIG > + string > + default "arch/riscv/configs/tiny64_defconfig" > + > +menu "Architecture Features" > + > +source "arch/Kconfig" > + > +endmenu > + > +menu "ISA Selection" > + > +choice > +
Re: [PATCH for-next 3/6] xen/sched: Fix build when NR_CPUS == 1
On 2/25/21 7:01 PM, Connor Davis wrote: > On Thu, Feb 25, 2021 at 02:55:45PM -0800, Bob Eshleman wrote: >> riscv64-unknown-linux-gnu-gcc (GCC) 10.1.0 >> >> Which version of GCC are you seeing emit this? > > The one from cloned from github.com/riscv/riscv-gnu-toolchain > in the docker container uses 10.2.0 > > Connor > The commit I pinned in the container is actually for GDB only, since more recent versions broke when used with QEMU at the time of writing the dockerfile (this last June). Since I built the container some months ago and no commit pinning for the compiler, it still contains 10.1.0 for me. It _shouldn't_ be necessary... but since there is a lot of dev done on riscv-gcc, it might be worth talking about pinning the compiler version in the container. -Bob
Re: [PATCH for-next 5/6] xen: Add files needed for minimal riscv build
On 2/25/21 3:14 PM, Andrew Cooper wrote: > > Well - this is orders of magnitude more complicated than it ought to > be. An empty head.S doesn't (well - shouldn't) need the overwhelming > majority of this. > > Do you know how all of this is being pulled in? Is it from attempting > to compile common/ by any chance? > > Now is also an excellent opportunity to nuke the x86isms which have > escaped into common code (debugger and xenoprof in particular), and > rethink some of our common/arch split. > > When it comes to header files specifically, I want to start using > xen/arch/$ARCH/include/asm/ and retrofit this to x86 and ARM. It has > two important properties - first, that you don't need to symlink the > tree to make compilation work, and second that patches touching multiple > architectures have hunks ordered in a more logical way. > > ~Andrew > I think we may have envisioned different things here I was under the impression that we wanted to implicate common, so that changes there that broke the RISC-V build would present themselves on CI... and to demonstrate which "arch_*" calls common expects to exist. It sounds like you'd prefer no common to start and none of the arch_* calls it relies on?
Re: [PATCH for-next 0/6] Minimal build for RISCV
On 2/25/21 7:23 AM, Connor Davis wrote: > Hi all, > > This series introduces a minimal build for RISCV. It is based on Bobby's > previous work from last year[0]. I have worked to rebase onto current Xen, > as well as update the various header files borrowed from Linux. > > This series provides the patches necessary to get a minimal build > working. The build is "minimal" in the sense that 1) it uses a > minimal config and 2) files, functions, and variables are included if > and only if they are required for a successful build based on the > config. It doesn't run at all, as the functions just have stub > implementations. > > My hope is that this can serve as a useful example for future ports as > well as inform the community of exactly what is imposed by common code > onto new architectures. > > The first 4 patches are mods to non-RISCV bits that enable building a > config with: > > !CONFIG_HAS_NS16550 > !CONFIG_HAS_PASSTHROUGH > NR_CPUS == 1 > !CONFIG_GRANT_TABLE > > respectively. The fifth patch adds the RISCV files, and the last patch > adds a docker container for doing the build. To build from the docker > container (after creating it locally), you can run the following: > > $ make XEN_TARGET_ARCH=riscv64 SUBSYSTEMS=xen > Thanks for getting this out! Looking forward to continue working with you on this. Great job on fixing these up and fixing the rebase! For anyone interested in peeking in on how other RISC-V developments are advancing, the out-of-tree repo is located here: https://gitlab.com/xen-on-risc-v/xen The parallel work has been on getting dom0 up and running. We're just beyond making domain_create/construct_dom0 calls work (and getting all of common and _init calls involved working appropriately), and are currently on mapping in and launching the dom0 created (this is being done on branch riscv-create-dom0 and be forewarned, there is still a good amount of churn there). I'm not sure on the optimal way to keep the ML informed about how things are going... as I'm not sure I foresee many intermediate patches between this initial build and seeing a dom0 console... save for common fixes and questions. I think Connor and I are both on the IRC. Any suggestions, of course, are welcome. Best, Bob
Re: [PATCH for-next 5/6] xen: Add files needed for minimal riscv build
>> On 2/25/21 3:14 PM, Andrew Cooper wrote: >> >> It sounds like you'd prefer no common to start and none of the >> arch_* calls it relies on? > > We definitely want "stuff compiled under RISC-V" to be caught in CI, but > that doesn't mean "wedge all of common in with stubs to begin with". > > Honestly - I want to see the build issues/failures in common, to help us > fix the rough corners on Kconfig system and include hierarchy. > > In light of this patch, there are definitely some things which should be > fixed as prerequisites, rather than forcing yet-more x86-isms into every > new arch. > > ~Andrew > Ah I see. There's more that could be Kconfig'd away and if they can't be Kconfig'd away, their should be some commits to make it so they can be. But things like, for example, `arch_domain_create()` would still be stubbed, because this is and always will be required. -Bobby
Re: HOWTO enable Xen on my board based on STM32MP1
On 3/10/21 1:29 AM, Gurrieri Stefano wrote: > Hello, > > I'm working on the platform STM32MP1 based on cortex-A7 dual core. This is an > armv7-A that has the "Hardware virtualization support". > My current Linux BSP is built using Yocto Project... but now, I'm asking how > to enable XEN on my platform? Is there a procedure to follow to try to > experiment? > > Thanks a lot! > Greetings, > Stefano Hey Stefano, I'd start with https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions and telling U-Boot to modify the fdt as described in the link. That should give you a good idea how to get UART from Xen and how to tell it about where your dom0 kernel/initrd are located. Best, Bobby
Working Group for Secure Boot
Hey all, We would like to start a working group for secure boot support in Xen to coordinate the various interested parties and set out a plan for the feature and its implications for the whole Xen system. The end goal is a full implementation that restricts the interfaces dom0 has to affect Xen, akin to Linux's lockdown LSM. This implicates important parts of the ABI (e.g., /dev/xen/privcmd/) and so will require input from the greater community. I'm not familiar with how working groups function in the Xen project, so this email also opens the floor for suggestions as to how this might be managed. We'd love to hear from anyone interested in such a group and how the community as a whole feels about such an effort. Best regards. --- Bobby Eshleman SE at Vates SAS
Re: Working Group for Secure Boot
Awesome, it's great to see this interest. I'll wait until early next week to give more people a chance to pitch in, then start bugging everybody about availability to schedule a meeting. I'll put together a small agenda then to get the ball rolling. Thanks all.
Re: Working Group for Secure Boot
Hey everyone, I think most who are interested have acked the thread at this point and I've CC'd everyone (please add anyone if I've missed them). I'd like to suggest we have a first group call to set out an agenda, define scope, and start identifying the direction the project would like to go for secure boot. I'll prepare the call similar to how community calls are handled, with a public cryptpad for agenda items and such. Which of these dates work best for you? Which absolutely do not work? Mon. March 29th, 16:00 UTC Wed. March 31st, 16:00 UTC Mon. April 5th, 16:00 UTC Given the Xen community call is at 16:00 UTC, I figure that probably best captures our geographic spread. Feel free to suggest alternative dates/times if none of the above work. We can host the meeting on Jitsi which works quite well from any web browser. I'll send out a invite link when we've decided on a suitable date and time. Thanks. -- Bobby Eshleman SE at Vates SAS
Re: Working Group for Secure Boot
On 3/16/21 1:07 PM, Roman Shaposhnik wrote: > WFIW: all 3 time slots work for me. > > Looking forward to this! > > Thanks, > Roman. > Thanks Roman, same here! -- Bobby Eshleman SE at Vates SAS
Re: Working Group for Secure Boot
Hey all, It looks like the following date works best: Mon. March 29th, 16:00 UTC The meeting place URL: https://meet.vates.fr/xen-lockdown Feel free to let us know if the time presents a conflict. -- Bobby Eshleman SE at Vates SAS
Secure Boot / Lockdown WG Meeting
Hey all, I just wanted to send this out as a new email thread in case anyone missed the reply on the previous thread. It looks like the following date works best: Mon. March 29th, 16:00 UTC https://meet.vates.fr/xen-lockdown Feel free to let us know if the time presents a conflict. -- Bobby Eshleman SE at Vates SAS
Xen Secure Boot and Lockdown WG Meeting Summary - Mon, March 29, 2021
# Xen Secure Boot and Lockdown This document summarizes the Xen Secure Boot and Lockdown WG meeting that occurred on Mon, March 29, 2021. We identified a list of requirements for locking down a Xen system that (at least) requires the following: ## Verified Boot Chain Various projects are underway already to support a verified boot chain that includes Xen and dom0. 1. via the EFI loader 1. Xen already supports verification of itself, the dom0 kernel, and the dom0 initrd, via a PE32+ bundle and the EFI loader. 2. Trenchboot 3. Add PE/COFF header to mb2 Xen (patches on ML, needs revision), allowing shim + grub2. ## Linux Lockdown in Dom0 1. Needs further testing, but seems to at least nominally work with QubesOS 1. QubesOS may be benefiting from outsourcing otherwise locked down functionality to stubdoms 3. Integrity checking for initrd 1. Not an issue for bundled xen.efi ## Xen Lockdown in Dom0 1. Live patching 2. Kexec 1. Will dom0 kexec need extending? Probably just "plumbing" to work for Xen. 3. /priv/cmd 1. Violations of SB include: 1. set_trap_table 2. mmu_update 3. ... more ... (TODO: add to this list) 4. PCI Passthrough 1. usage of unstable Xen interfaces 2. PCI BARs mapping in guest 3. Interrupt routing setup 4. See other QEMU-related issues below 5. QEMU 1. I/O permissions 2. resets may be an issue 6. Xen command line 1. What parts are safe? and unsafe? 2. Allow safe options from unmeasured source The living version of this document, to be used to coordinate future work, is found here: https://cryptpad.fr/pad/#/2/pad/edit/IrfCfGH3l1Z2oUGlbBS2kiz6/ Please feel free to add to / edit the above document! The raw meeting notes can be found here: https://cryptpad.fr/pad/#/2/pad/edit/YHfyA-IbuEa3SLe-hsKVEjRC/ -- Bobby Eshleman SE at Vates SAS
