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

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

> On Jun 1, 2017, at 11:52 AM, George Dunlap <george.dunlap@xxxxxxxxxx> 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*?
> 
> 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.

And here I mean, “call Xen functions directly”, not “make well-defined 
hypercalls”.

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