[osv-dev] [PATCH] build: support driver profiles
This patch introduces new build mechanism that allows creating custom kernel with specific list of device drivers intended to target given hypervisor. Such kernel benefits from smaller size and better security as all unneeded code is removed. This patch partially addresses the modularization/librarization functionality as explained by the issue #1110 and this part of the roadmap - https://github.com/cloudius-systems/osv/wiki/Roadmap#modularizationlibrarization. This idea was also mentioned in the P99 OSv presentation - see slide 11. In essence, we introduce new build script and makefile parameter: `drivers_profile`. This new parameter is intended to specify a drivers profile which is simply a list of device drivers to be linked into kernel with some extra functionality like PCI or ACPI these drivers depend on. Each profile is specified in a tiny make include file (*.mk) under new conf/profiles/$(arch) directory and included by the main makefile as requested by drivers_profile parameter. The main makefile has number of new ifeq conditions that add given driver object file to the linked objects list depending on the value (0 or 1) of given conf_drivers_* variable specified in the relevant profile file. Sometimes it is necessary to conditionally enable/disable given code depending on the drivers selected. The good example of it is arch-setup.cc which actually registers individual drivers and this is where we need some kind of #if-way of registering given driver. To that end, this patch adds new script gen-drivers-config-header and new rule to the makefile, which automatically generates driver-config.h header file under build/$(mode)/gen/include/osv. The driver-config.h is comprised of the #define CONF_drivers_* macros that specify if given driver is enabled or not (1, 0) and is included by relatively few source file like arch-setup.cc. The extra benefit of this approach is that every time we change value of drivers_profile, all relevant files are recompiled and new kernel linked. Most of the patch are changes to the relevant source file to include new #if CONF_drivers_* conditional logic, changes to the main makefile to conditionality link specific object files and new makefile include file under conf/profiles/. The benefits of using drivers are most profound when building kernel with most symbols hidden. Below you can see examples of some build commands along with the kernel size produced: ./scripts/build fs=rofs conf_hide_symbols=1 image=native-example #all 3632K build/release/kernel-stripped.elf ./scripts/build fs=rofs conf_hide_symbols=1 image=native-example drivers_profile=virtio-pci 3380K build/release/kernel-stripped.elf ./scripts/build fs=rofs conf_hide_symbols=1 image=native-example drivers_profile=vmware 3308K build/release/kernel-stripped.elf ./scripts/build fs=rofs conf_hide_symbols=1 image=native-example drivers_profile=virtio-mmio 3120K build/release/kernel-stripped.elf ./scripts/build fs=rofs conf_hide_symbols=1 image=native-example drivers_profile=base #most drivers out 3036K build/release/kernel-stripped.elf Partially addresses #1110 Signed-off-by: Waldemar Kozaczuk --- Makefile | 109 -- arch/aarch64/arch-dtb.cc | 7 ++ arch/aarch64/arch-setup.cc| 41 +- arch/aarch64/boot.S | 3 + arch/aarch64/cpuid.cc | 5 ++ arch/aarch64/xen.cc | 1 + arch/x64/apic.cc | 1 + arch/x64/arch-setup.cc| 74 + arch/x64/cpuid.cc | 15 arch/x64/entry-xen.S | 5 ++ arch/x64/power.cc | 9 +++ arch/x64/smp.cc | 9 +++ arch/x64/xen.cc | 1 + conf/profiles/README.md | 71 + conf/profiles/aarch64/all.mk | 5 ++ conf/profiles/aarch64/base.mk | 26 ++ conf/profiles/aarch64/microvm.mk | 1 + conf/profiles/aarch64/virtio-mmio.mk | 4 + conf/profiles/aarch64/virtio-pci.mk | 6 ++ conf/profiles/aarch64/xen.mk | 2 + conf/profiles/x64/all.mk | 8 ++ conf/profiles/x64/base.mk | 74 + conf/profiles/x64/cloud_hypervisor.mk | 2 + conf/profiles/x64/hyperv.mk | 6 ++ conf/profiles/x64/microvm.mk | 1 + conf/profiles/x64/vbox.mk | 8 ++ conf/profiles/x64/virtio-mmio.mk | 4 + conf/profiles/x64/virtio-pci.mk | 10 +++ conf/profiles/x64/vmware.mk | 10 +++ conf/profiles/x64/xen.mk | 6 ++ core/xen_intr.cc | 1 + drivers/acpi.cc | 9 ++- drivers/hpet.cc | 9 +++ drivers/pci-generic.cc| 5 ++ drivers/virtio-blk.cc | 5 ++ drivers/virtio-fs.cc | 5 ++ drivers/virtio-net.cc
[osv-dev] [PATCH] PVH boot: move the code to a separate file
This patch moves the PVH boot logic handling code out of xen.cc
into a new file pvh-boot.cc. This is necessary to support
building kernels with a specific set of device drivers.
Signed-off-by: Waldemar Kozaczuk
---
Makefile | 1 +
arch/x64/pvh-boot.cc | 40
arch/x64/xen.cc | 38 --
3 files changed, 41 insertions(+), 38 deletions(-)
create mode 100644 arch/x64/pvh-boot.cc
diff --git a/Makefile b/Makefile
index 2f249ee4..59cc6de4 100644
--- a/Makefile
+++ b/Makefile
@@ -916,6 +916,7 @@ objects += arch/x64/apic-clock.o
objects += arch/x64/entry-xen.o
objects += arch/x64/vmlinux.o
objects += arch/x64/vmlinux-boot64.o
+objects += arch/x64/pvh-boot.o
objects += $(acpi)
endif # x64
diff --git a/arch/x64/pvh-boot.cc b/arch/x64/pvh-boot.cc
new file mode 100644
index ..406d39f8
--- /dev/null
+++ b/arch/x64/pvh-boot.cc
@@ -0,0 +1,40 @@
+#include "arch-setup.hh"
+#include
+
+struct hvm_start_info* hvm_xen_start_info __attribute__((section(".data")));
+
+#define OSV_MULTI_BOOT_INFO_ADDR 0x1000
+#define OSV_E820_TABLE_ADDR 0x2000
+
+extern "C"
+void hvm_xen_extract_boot_params()
+{
+// Set location of multiboot info struct at arbitrary place in lower memory
+// to copy to (happens to be the same as in boot16.S)
+osv_multiboot_info_type* mb_info =
reinterpret_cast(OSV_MULTI_BOOT_INFO_ADDR);
+
+// Copy command line pointer from boot params
+mb_info->mb.cmdline = hvm_xen_start_info->cmdline_paddr;
+
+// Copy e820 information from boot params
+mb_info->mb.mmap_length = 0;
+mb_info->mb.mmap_addr = OSV_E820_TABLE_ADDR;
+
+struct hvm_memmap_table_entry *source_e820_table = reinterpret_cast(hvm_xen_start_info->memmap_paddr);
+struct e820ent *dest_e820_table = reinterpret_cast(mb_info->mb.mmap_addr);
+
+for (uint32_t e820_index = 0; e820_index <
hvm_xen_start_info->memmap_entries; e820_index++) {
+dest_e820_table[e820_index].ent_size = 20;
+dest_e820_table[e820_index].type = source_e820_table[e820_index].type;
+dest_e820_table[e820_index].addr = source_e820_table[e820_index].addr;
+dest_e820_table[e820_index].size = source_e820_table[e820_index].size;
+mb_info->mb.mmap_length += sizeof(e820ent);
+}
+
+// Save ACPI RDSP address in the field of the osv_multiboot_info_type
structure
+// Ideally, we would wanted to save it under the acpi::pvh_rsdp_paddr but
it is
+// to early in the boot process as it would have been overwritten later in
premain().
+mb_info->pvh_rsdp = hvm_xen_start_info->rsdp_paddr;
+
+reset_bootchart(mb_info);
+}
diff --git a/arch/x64/xen.cc b/arch/x64/xen.cc
index 4e905653..d642c4fa 100644
--- a/arch/x64/xen.cc
+++ b/arch/x64/xen.cc
@@ -12,20 +12,17 @@
#include "processor.hh"
#include "cpuid.hh"
#include "exceptions.hh"
-#include "arch-setup.hh"
#include
#include
#include
#include
#include
-#include
shared_info_t *HYPERVISOR_shared_info;
uint8_t xen_features[XENFEAT_NR_SUBMAPS * 32];
// make sure xen_start_info is not in .bss, or it will be overwritten
// by init code, as xen_init() is called before .bss initialization
struct start_info* xen_start_info __attribute__((section(".data")));
-struct hvm_start_info* hvm_xen_start_info __attribute__((section(".data")));
namespace xen {
@@ -225,39 +222,4 @@ void xen_init(struct start_info* si)
xen_start_info = si;
}
-#define OSV_MULTI_BOOT_INFO_ADDR 0x1000
-#define OSV_E820_TABLE_ADDR 0x2000
-
-extern "C"
-void hvm_xen_extract_boot_params()
-{
-// Set location of multiboot info struct at arbitrary place in lower memory
-// to copy to (happens to be the same as in boot16.S)
-osv_multiboot_info_type* mb_info =
reinterpret_cast(OSV_MULTI_BOOT_INFO_ADDR);
-
-// Copy command line pointer from boot params
-mb_info->mb.cmdline = hvm_xen_start_info->cmdline_paddr;
-
-// Copy e820 information from boot params
-mb_info->mb.mmap_length = 0;
-mb_info->mb.mmap_addr = OSV_E820_TABLE_ADDR;
-
-struct hvm_memmap_table_entry *source_e820_table = reinterpret_cast(hvm_xen_start_info->memmap_paddr);
-struct e820ent *dest_e820_table = reinterpret_cast(mb_info->mb.mmap_addr);
-
-for (uint32_t e820_index = 0; e820_index <
hvm_xen_start_info->memmap_entries; e820_index++) {
-dest_e820_table[e820_index].ent_size = 20;
-dest_e820_table[e820_index].type = source_e820_table[e820_index].type;
-dest_e820_table[e820_index].addr = source_e820_table[e820_index].addr;
-dest_e820_table[e820_index].size = source_e820_table[e820_index].size;
-mb_info->mb.mmap_length += sizeof(e820ent);
-}
-
-// Save ACPI RDSP address in the field of the osv_multiboot_info_type
structure
-// Ideally, we would wanted to save it under the acpi::pvh_rsdp_paddr but
it is
-// to early in the boot process as it would have been overwritten
[osv-dev] [PATCH] cpuid: make internal functions static
Signed-off-by: Waldemar Kozaczuk
---
arch/x64/cpuid.cc | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x64/cpuid.cc b/arch/x64/cpuid.cc
index 45c0fea4..29bc8d6e 100644
--- a/arch/x64/cpuid.cc
+++ b/arch/x64/cpuid.cc
@@ -68,7 +68,7 @@ cpuid_bit cpuid_bits[] = {
constexpr unsigned nr_cpuid_bits = sizeof(cpuid_bits) / sizeof(*cpuid_bits);
-void process_cpuid_bit(features_type& features, const cpuid_bit& b)
+static void process_cpuid_bit(features_type& features, const cpuid_bit& b)
{
bool subleaf = b.leaf == 7;
auto base = b.leaf & 0xf000;
@@ -96,7 +96,7 @@ void process_cpuid_bit(features_type& features, const
cpuid_bit& b)
features.*(b.flag) = (w >> b.bit) & 1;
}
-void process_xen_bits(features_type )
+static void process_xen_bits(features_type )
{
signature sig = { 0x566e6558, 0x65584d4d, 0x4d4d566e };
@@ -110,13 +110,13 @@ void process_xen_bits(features_type )
}
}
-void process_hyperv_bits(features_type ) {
+static void process_hyperv_bits(features_type ) {
if(hyperv_identify() && hyperv_is_timecount_available()) {
features.hyperv_clocksource = true;
}
}
-void process_cpuid(features_type& features)
+static void process_cpuid(features_type& features)
{
for (unsigned i = 0; i < nr_cpuid_bits; ++i) {
process_cpuid_bit(features, cpuid_bits[i]);
--
2.31.1
--
You received this message because you are subscribed to the Google Groups "OSv
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/osv-dev/20220209021834.514667-1-jwkozaczuk%40gmail.com.
