On Thu, 1 Jun 2017, George Dunlap wrote:
> > On May 31, 2017, at 6:45 PM, Stefano Stabellini <sstabell...@kernel.org>
> > 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@lists.xen.org
https://lists.xen.org/xen-devel
