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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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.

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