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