Re: Notes on stubdoms and latency on ARM

[Julien Grall <julien.grall@arm.com>]

On 06/19/2017 07:36 PM, Volodymyr Babchuk wrote:
> Hi Stefano,

Hi,

> On 19 June 2017 at 10:54, Stefano Stabellini <sstabellini@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?

The problem would be the same with an EL0 app.

Cheers.

-- 
Julien Grall

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