Thanks for the tip! I also had a quite similar idea: Hash values are calculated over the outputs of "lspci" and further files (e.g. /proc/iomem, /proc/ioports, ...) (e.g. with "sha1sum"). These hash values are linked to the hypervisor configuration. Before the hypervisor or a guest cell is started, the hash values are calculated again and compared with the hash values stored for this configuration.
In practical use, however, it is sometimes necessary to adjust the hypervisor configuration on site (in the field). The tools required for this (build essentials) and a make file could already be installed in the root file system of the target, so that the compilation of the configuration could be performed on the target. However, the current situation is that to effectively control whether the hypervisor or the guest system starts, a "real" serial port is needed; otherwise, you don't really see where a successful startup fails. Unfortunately, redirecting /dev/jailhouse to a file only works if the system does not crash. It would be better if the hypervisor directly creates a file with these outputs and completes it before the system crashed. Then, on a subsequent reboot, the contents of this file could be analyzed and the hypervisor configuration corrected. Jan-Marc [email protected] schrieb am Mittwoch, 4. Januar 2023 um 10:42:02 UTC+1: > On 03.01.23 14:39, Jan-Marc Stranz wrote: > > For the productive use of the hypervisor "Jailhouse" I am concerned > > about another topic: "Sensitivity of the hypervisor configurations to HW > > changes". > > > > I have already created the hypervisor configurations for 8 different x86 > > HW targets (evaluation boards, industrial PC's, single board computers, > > ...) for the root cell and for up to 2 guest cells. > > > > I also "cloned" some HW targets; however, I was scrupulously careful > > that the HW (RAM, PCI devices, BIOS version, ...) was identical. > > > > To duplicate an x86 HW target, in my experience, the following > > components must remain the same so that the hypervisor configurations > > already created can still be used: > > > > 1. CPU model and architecture > > 2. RAM memory size > > 3. PCI devices (including M.2 NVME SSD!) > > 4. BIOS version > > > > For mass production based on a Single Board Computer (SBC) some points > > can easily be kept (e.g. CPU model and architecture, PCI devices (except > > M.2 NVME SSD), BIOS version). > > > > On the other hand, you can't guarantee that you can always use the same > > type for the M.2 NVME SSD, for example. > > However, the change of the type of the M.2 NVME SSD, which is actually > > imperceptible for the user, will possibly be noticeable in the > > hypervisor configuration (e.g. different PCI capabilities). > > > > Another problem is the deviations that creep into memory and I/O layouts. > > > > Are there any experiences and practical solutions regarding this topic? > > I would appreciate any advice on this! > > > > As I suggested offline already: > > If you don't have control over checking new hardware combinations > /before/ they go into production, I would consider adding a > post-production check that runs 'jailhouse config create' on the device > (or outside, against what 'jailhouse config collect' provided) and > compares the generated reference config against an earlier version. On > deviations, an engineer would have to look at the details. > > Jan > > -- > Siemens AG, Technology > Competence Center Embedded Linux > > -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/6d20589e-d410-40e4-b964-24f8f2911c70n%40googlegroups.com.
