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

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

> 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*?

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.

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).

The two motivating factors for having apps were additional security and non-GPL 
implementations of device models / mediators.  Having the app being able to 
call into Xen undermines both.

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