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

[Julien Grall <julien.grall@xxxxxxx>]

Hi Stefano,

On 31/05/17 18:45, Stefano Stabellini 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.
Realistically, even if the EL0 apps are available directly in Xen 
repository, they will be built as standalone binary. So any ABI change 
will require to inspect/testing all the EL0 apps if the change is subtle.
So This sounds like to me a waste of time and resource compare to 
providing a stable and clearly defined ABI.
Cheers,

--
Julien Grall

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