[trustable-software] No hypervisor required...

Niall Dalton niall.dalton at gmail.com
Wed May 23 21:54:28 BST 2018


Consolidation, which drove the initial enthusiasm for hypervisors in other
worlds, is certainly a compelling use case. Using a hypervisor may or may
not be desirable depending on other concerns. "Asymmetric multiprocessing"
is a useful approach to consider as well. E.g. I've worked on fpga systems
where linux ran on the application (cortex-a) cores, an rtos on r-cores,
and bare-metal code on soft cores. In that particular case, linux was
responsible for launching the others, which then had full control of their
own hardware, and were free from interference. I think both approaches, and
some others, have their place. I think the only mistake is in pushing one
of the approaches beyond where it makes technical or other sense.


On Wed, May 23, 2018 at 1:26 PM, Feuer, Magnus <mfeuer1 at jaguarlandrover.com>
wrote:

> Paul,
>
> I would add one additional argument for using hypervisor: packaging and
> cost.
>
> Security and functional safety arguments aside, being able to run a couple
> of different OS:es as a VM on a single ECU lets the OEM cut BOM cost,
> weight, packaging, and (to some degree) power consumption.
> I know that we would harmonize on one OS but I don't think anyone of us
> are there yet, and that we currently run a mix of systems across our ECUs.
> Collating several of those ECUs into a single, hypervised unit will save
> money and engineering effort for the vehicle programs.
>
> /Magnus F.
>
>
> On Wed, May 23, 2018 at 11:22 AM, Niall Dalton <niall.dalton at gmail.com>
> wrote:
>
>>
>>
>> I have seen one implementation, where they used resource allocation, such
>>> that a specific guest OS was dedicated to once specific core of the
>>> processor, to ensure availability.  E.g., if malware took over the other
>>> guests OS's running on the other cores, the dedicated OS on the dedicated
>>> core should not be performance affected.
>>>
>>> I think this is an example of where hypervisors are better suited to
>>> resource allocation that operating systems.
>>>
>>
>>
>> ​It's possible but hard to pull off in practice. It's easier than it
>> sounds to have a diplomatic incident between VMs, even with exclusive core
>> mappings because of other implicitly shared resources in typical systems.
>> That ranges from thermal headroom (running one core hot means the other may
>> not be able to turbo), shared pipelines on threaded processors, shared
>> caches, shared branch predictors, shared memory buses, shared IO buses (a
>> PCIe lockup can run the day for everyone). We're increasingly getting
>> support for hard-partitioning of these resources but that comes with
>> caveats as well.
>>
>> In atypical systems, such as processors designed for hard-realtime, it's
>> indeed possible to have very strong lack-of-interference guarantees.
>> Essentially because the hardware is hard-partitioned. Of course this isn't
>> guaranteed for any given design. E.g. say you use the Cortex-R52 processor,
>> which is targeted at these applications. To really get freedom from
>> interference, I believe you can only use the 'tightly coupled memories' and
>> not use the external memory support. Sharing the DRAM allows interference.
>> Note that this is true even if you guarantee that accesses go to disjoint
>> addresses. You'd have to guarantee that they go to independent banks within
>> the DRAM to really be free of interference. Ignoring malware, presumably
>> hard-partitioning should include freedom from inadvertent bit flips due to
>> rapid accesses to a particular DRAM row. A sufficiently hard-partitioned
>> system is really just 'sharing the packaging and wiring'; as we push
>> towards the high performance regime, there are further interesting effects
>> such as voltage droops to contend with - systems have been known to not
>> cope wonderfully when someone lights up an accelerator on the chip, even if
>> it's not being shared.
>>
>> When it comes to the hypervisor, there are also interesting questions
>> around IO devices; not just on the iommu or not, but whether the overall
>> architecture allows vmexit-free io access, or whether this can be a source
>> of interference. In other words, a sufficiently complicated hypervisor is
>> indistinguishable from an operating system. There's also a 'conservation of
>> crud' law in effect. If the software hypervisor is exceedingly simple, such
>> as the 900 line example, the hardware is picking up the slack.​ Which is
>> simpler, and can we reason about the overall system? It's not an easy
>> question.
>>
>> I don't think it's a question of whether hypervisors have a place or not.
>> The question is, for a given system, whether they are necessary or
>> sufficient. It's not a slam dunk on either.
>>
>> As we climb the perf curve, and Cortex-R52, while a fine design, is not
>> high-performance for anyone coming from the data/compute intensive side
>> such as on self-driving, then there are additional questions around what it
>> buys you. Hard-partitioning in a compute-constrained world is hard to
>> swallow, so might be worth considering alternative designs.
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> trustable-software mailing list
>> trustable-software at lists.trustable.io
>> https://lists.trustable.io/cgi-bin/mailman/listinfo/trustable-software
>>
>>
>
>
> --
> -------------------
> *System Architect Manager*
> *Jaguar Land Rover*
>
> *Email*: mfeuer1 at jaguarlandrover.com
> *Mobile*: +1 949 294 7871
>
>
>
> Jaguar Land Rover North America, LLC
> 1419 NW 14th Ave, Portland, OR 97209
> -------------------
> Business Details:
> Jaguar Land Rover Limited
> Registered Office: Abbey Road, Whitley, Coventry CV3 4LF
> Registered in England No: 1672070
>
> This e-mail and any attachments contain confidential information for a
> specific individual and purpose.  The information is private and privileged
> and intended solely for the use of the individual to whom it is addressed.
> If you are not the intended recipient, please e-mail us immediately.  We
> apologise for any inconvenience caused but you are hereby notified that any
> disclosure, copying or distribution or the taking of any action in reliance
> on the information contained herein is strictly prohibited.
>
> This e-mail does not constitute an order for goods or services unless
> accompanied by an official purchase order.
>
> _______________________________________________
> trustable-software mailing list
> trustable-software at lists.trustable.io
> https://lists.trustable.io/cgi-bin/mailman/listinfo/trustable-software
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/trustable-software/attachments/20180523/7adb2ca5/attachment.html>


More information about the trustable-software mailing list