Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 15 May 2017, George Dunlap wrote:
> On Fri, May 12, 2017 at 7:47 PM, Volodymyr Babchuk
> <vlad.babchuk@xxxxxxxxx> wrote:
> >> Regarding modules (#3): The problem that loadable modules were
> >> primarily introduced to solve in Linux wasn't "How to deal with
> >> proprietary drivers", or even "how to deal with out-of-tree drivers".
> >> The problem was, "How to we allow software providers to 1) have a
> >> single kernel binary, which 2) has drivers for all the different
> >> systems on which it needs to run, but 3) not take a massive amount of
> >> memory or space on systems, given that any given system will not need
> >> the vast majority of drivers?"
> >>
> >> Suppose hypothetically that we decided that the mediators you describe
> >> need to run in the hypervisor.  As long as Kconfig is sufficient for
> >> people to enable or disable what they need to make a functional and
> >> efficient system, then there's no need to introduce modules.  If we
> >> reached a point where people wanted a single binary that could do
> >> either or OP-TEE mediator or the Google mediator, or both, or neither,
> >> but didn't to include all of them in the core binary (perhaps because
> >> of memory constraints), then loadable modules would be a good solution
> >> to consider.  But either way, if we decided they should run in the
> >> hypervisor, then all things being equal it would still be better to
> >> have both implementations in-tree.
> >>
> >> There are a couple of reasons for the push-back on loadable modules.
> >> The first is the extra complication and infrastructure it adds.  But
> >> the second is that people have a strong temptation to use them for
> >> out-of-tree and proprietary code, both of which we'd like to avoid if
> >> possible.  If there comes a point in time where loadable modules are
> >> the only reasonable solution to the problem, I will support having
> >> them; but until that time I will look for other solutions if I can.
> >>
> >> Does that make sense?
> > Yes, thank you. Legal questions is not my best side. Looks like I was
> > too quick, when proposed modules as a solution to our needs. Sorry, I
> > had to investigate this topic further before talking about it.
> >
> > So, let's get back to native apps. We had internal discussion about
> > possible use cases and want to share our conclusions.
> >
> > 1. Emulators. As Stefano pointed, this is ideal use case for small,
> > fast native apps that are accounted in a calling vcpu time slice.
> >
> > 2. Virtual coprocessor backend/driver. The part that does actual job:
> > makes coprocessor to save or restore context. It is also small,
> > straightforward app, but it should have access to a real HW.
> >
> > 3. TEE mediators. They need so much privileges, so there actually are
> > no sense in putting them into native apps. For example, to work
> > properly OP-TEE mediator needs to: pin guest pages, map guest pages to
> > perform IPA->MPA translation, send vIRQs to guests, issue real SMCs.
> 
> As I think I've said elsewhere, apart from "issue real SMCs", all of
> that functionality is already available to device models running in
> domain 0, in the sense that there are interfaces which cause Xen to
> make those things happen: when the devicemodel maps a page, that
> increases the refcount and effectively pins it; the devicemodel
> accesses *all* guest pages in terms of guest memory addresses, but (I
> believe) can ask Xen for a p->m translation of a particular page in
> memory; and it can set vIRQs pending to the guest.  It seems likely
> that a suitable hypervisor interface could be made to expose SMC
> functionality to device models as well.

I'll repeat here for convenience. The discussion started from the need
for something that has lower latency, and more importantly, more
deterministic latency, than a dom0 device model. A dom0 device model
cannot guarantee even the weakest of latency requirements.

On ARM there are no dom0 device models today, and given their critical
limitations, I prefer to introduce something different from the start.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel