Re: [Xen-devel] Notes on stubdoms and latency on ARM

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 1 Jun 2017, George Dunlap wrote:
> > On May 31, 2017, at 6:45 PM, Stefano Stabellini <sstabellini@xxxxxxxxxx> 
> > wrote:
> > 
> > On Wed, 31 May 2017, George Dunlap wrote:
> >> On 30/05/17 18:29, Stefano Stabellini wrote:
> >>> On Fri, 26 May 2017, Volodymyr Babchuk wrote:
> >>>>>>> The other issue with stubdoms is context switch times. Volodymyr 
> >>>>>>> showed
> >>>>>>> that minios has much higher context switch times compared to EL0 apps.
> >>>>>>> It is probably due to GIC context switch, that is skipped for EL0 
> >>>>>>> apps.
> >>>>>>> Maybe we could skip GIC context switch for stubdoms too, if we knew 
> >>>>>>> that
> >>>>>>> they are not going to use the VGIC. At that point, context switch 
> >>>>>>> times
> >>>>>>> should be very similar to EL0 apps.
> >>>>>> So you are suggesting to create something like lightweight stubdom. I
> >>>>>> generally like this idea. But AFAIK, vGIC is used to deliver events
> >>>>>> from hypervisor to stubdom. Do you want to propose another mechanism?
> >>>>> 
> >>>>> There is no way out: if the stubdom needs events, then we'll have to
> >>>>> expose and context switch the vGIC. If it doesn't, then we can skip the
> >>>>> vGIC. However, we would have a similar problem with EL0 apps: I am
> >>>>> assuming that EL0 apps don't need to handle interrupts, but if they do,
> >>>>> then they might need something like a vGIC.
> >>>> Hm. Correct me, but if we want make stubdom to handle some requests
> >>>> (e.g. emulate MMIO access), then it needs events, and thus it needs
> >>>> interrupts. At least, I'm not aware about any other mechanism, that
> >>>> allows hypervisor to signal to a domain.
> >>> 
> >>> The stubdom could do polling and avoid interrupts for example, but that
> >>> would probably not be desirable.
> >>> 
> >>> 
> >>>> On other hand, EL0 app (as I see them) does not need such events.
> >>>> Basically, you just call function `handle_mmio()` right in the app.
> >>>> So, apps can live without interrupts and they still be able to handle
> >>>> request.
> >>> 
> >>> That's true.
> >> 
> >> Well if they're in a separate security zone, that's not going to work.
> >> You have to have a defined interface between things and sanitize inputs
> >> between them.
> > 
> > Why? The purpose of EL0 apps is not to do checks on VM traps in Xen but
> > in a different privilege level instead. Maybe I misunderstood what you
> > are saying? Specifically, what "inputs" do you think should be sanitized
> > in Xen before jumping into the EL0 app?
> 
> >> Furthermore, you probably want something like a stable
> >> interface with some level of backwards compatibility, which is not
> >> something the internal hypervisor interfaces are designed for.
> > 
> > I don't think we should provide that. If the user wants a stable
> > interface, she can use domains. I suggested that the code for the EL0
> > app should come out of the Xen repository directly. Like for the Xen
> > tools, they would be expected to be always in-sync.
> 
> Hmm, it sounds like perhaps I misunderstood you and Volodymyr.  I took “you 
> just call function `handle_mmio()` right in the app” to mean that the *app* 
> calls the *hypervisor* function named “handle_mmio”.  It sounds like what he 
> (or at least you) actually meant was that the *hypervisor* calls the function 
> named “handle_mmio” in the *app*?

Indeed, I certainly understood Xen calls "handle_mmio" in an EL0 app.


> But presumably the app will need to do privileged operations — change the 
> guest’s state, read / write MMIO regions, &c.  We can theoretically have Xen 
> ‘just call functions’ in the app; but we definitely *cannot* have the app 
> ‘just call functions’ inside of Xen — that is, not if you actually want any 
> additional security.

Absolutely.


> And that’s completely apart from the whole non-GPL discussion we had.  If you 
> want non-GPL apps, I think you definitely want a nice clean interface, or 
> you’ll have a hard time arguing that the resulting thing is not a derived 
> work (in spite of the separate address spaces).

That's right, I don't think EL0 apps are a good vehicle for non-GPL
components. Stubdoms are better for that.


> The two motivating factors for having apps were additional security and 
> non-GPL implementations of device models / mediators.

I think the two motivating factors are additional security and extremely
low and deterministic latency.


> Having the app being able to call into Xen undermines both.

Indeed, but there needs to be a very small set of exposed calls, such as:

- (un)mapping memory of a VM
- inject interrupts into a VM

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