[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen and safety certification, Minutes of the meeting on Apr 4th
> Hi Stefano > > On 10.05.18 22:51, Stefano Stabellini wrote: > > On Thu, 10 May 2018, Praveen Kumar wrote: > >>> Yeah, you are right. It looks like turning Dom0 into a DomU is not > >>> good enough. Maybe for this option to be viable we would actually > >>> have to terminate (or pause and never unpause?) dom0 after boot. > >> > >> Just a thought ! > >> How about keeping Dom0 still be there, but DomUs given Dom0 > >> privilege, with restricted permission on mission critical resources ? > >> And if anyhow Dom0 crashes, the best contended among the existing > >> DomUs take the ownership of Dom0 ? > > > > I don't think this is easily doable, also it wouldn't solve the issue > > of removing dom0 from the system. But see below. > > > > > >>>> However, you surely need an entity to handle domain crash. You > >>>> don't > >> want to > >>>> reboot your platform (and therefore you safety critical domain) for > >>>> a > >> crashed > >>>> UI, right? So how this is going to be handled in your option? > >> > >>> We need to understand the certification requirements better to know > >>> the answer to this. I am guessing that UI crashes are not handled > >>> from the certification point of view -- maybe we only need to > >>> demonstrate that the system is not affected by them? > >> > >> Where can we find the certification requirements details ? > > > ISO26262: https://www.iso.org/standard/51362.html > IEC61508: https://webstore.iec.ch/publication/5517 > > > Yes, I think we need to understand the requirements better to figure > > out the right way forward for Dom0. > > > > For instance, here is another idea: we could have Xen boot multiple > > domains at boot time from device tree, as suggested in the dom0-less > > approach. All of the domains booted from Xen are "mission-critical". > > The first domain could still be dom0. Once booted, Dom0 can start > > other VMs, however, Xen would restrict Dom0 from doing any operations > > affecting the first set of mission-critical domains. > > Does the first domain have to be dom0? Would it be possible to have domains boot in parallel (especially if allocated to separate CPU cores) such that a simple OS (like FreeRTOS) would complete booting before dom0/Linux? In other words, does the hypervisor have any dependencies on dom0 having performed certain functions (interrupt configuration, MMU table initialization, timers, etc.) before it can create and start additional VMs? > > This way, we would get the flexibility of being able to start/stop > > domains at run time, but at the same time we might still be able to > > avoid certifications for Dom0, because Dom0 cannot affect the mission > > critical applications. > Such dom0 shall have no mission-critical domains memory access, no HW > access (SMMU, DVFS Power, etc.), and so on. EL3 software (optee or similar > on ARM) shall also be safety certified and not controlled from dom0 > > > > Is this approach actually feasible? We need to read the requirements > > to know. I am hoping Artem will chime in on this :-) > > > > I think this approach is feasible indeed, if we can prove isolation and fault > tolerance for FuSa parts of the system. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |