Hi Julien,

On 20 June 2017 at 03:45, Julien Grall <julien.gr...@arm.com> wrote:
>> On 19 June 2017 at 10:54, Stefano Stabellini <sstabell...@kernel.org>
>> wrote:
>>
>>>> But given the conversation so far, it seems likely that that is mainly
>>>> due to the fact that context switching on ARM has not been optimized.
>>>
>>>
>>> True. However, Volodymyr took the time to demonstrate the performance of
>>> EL0 apps vs. stubdoms with a PoC, which is much more than most Xen
>>> contributors do. Nodoby provided numbers for a faster ARM context switch
>>> yet. I don't know on whom should fall the burden of proving that a
>>> lighter context switch can match the EL0 app numbers. I am not sure it
>>> would be fair to ask Volodymyr to do it.
>>
>> Thanks. Actually, we discussed this topic internally today. Main
>> concern today is not a SMCs and OP-TEE (I will be happy to do this
>> right in XEN), but vcopros and GPU virtualization. Because of legal
>> issues, we can't put this in XEN. And because of vcpu framework nature
>> we will need multiple calls to vgpu driver per one vcpu context
>> switch.
>> I'm going to create worst case scenario, where multiple vcpu are
>> active and there are no free pcpu, to see how credit or credit2
>> scheduler will call my stubdom.
>> Also, I'm very interested in Julien's idea about stubdom without GIC.
>> Probably, I'll try to hack something like that to see how it will
>> affect overall switching latency
>
> This can only work if your stubdomain does not require interrupt. However,
> if you are dealing with devices you likely need interrupts, am I correct?
Ah yes, you are correct. I thought about OP-TEE use case, when there
are no interrupts. In case of co-processor virtualization we probably
will need interrupts.

> The problem would be the same with an EL0 app.
In case of EL0 there will be no problem, because EL0 can't handle
interrupts :) XEN should receive interrupt and invoke app. Yes, this
is another problem with apps, if we want to use them as devices
drivers.

-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babc...@gmail.com

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

Reply via email to