Re: [Xen-devel] [RFC] scf: SCF device tree and configuration documentation

[Andrii Anisov <andrii_anisov@xxxxxxxx>]

Hello Ian,


On 05.05.17 20:20, Ian Jackson wrote:
> Why wouldn't the toolstack simply choose appropriate irqs/mmio
> ranges ?  I would expect the virtual irqs/mmio ranges to not
> necessarily match the physical ones anyway.  Is choosing these ranges
> complicated ?
This could make sense. Choosing ranges should not be really complicated. 
The point here is that we need these ranges both for hypervisor and domU 
device tree generation, and we should keep the accordance. Moreover, we 
need a coprocessor device tree node for domU. Because it could describe 
some specifics beyond an iomem/irq presentation of the coprocessor.
> What I mean is that your previous proposal doesn't provide any way to
> say which guest(s) should get instances of this virtual coprocessor.
> Some guests should get none; some one; etc.
I think those guests which are configured to have a virtual 
coprocessor(s) will have some.
Those which are not configured to have - will not.
I would not set any specific limitations here. Shall I?

> Also, I am perplexed by your suggestion that a single physical coproc
> might be presented to a guest as two vcoprocs.  If your sharing
> strategy is context-switching, is this not going to result in a lot of
> context-switching, whenever the guest (which thinks it has two
> coprocs) touches one and then the other ?
I would not treat this case too specific. Any touches of the scheduled 
out virtual coprocessor would be handled by IO access emulation 
mechanism, and it is not necessary to evoke the context switch at the 
moment.
So the number of context switches is rather matter of the scheduling 
algorithm I guess.

--

*Andrii Anisov*



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