xen/arm: Query - vgic nr_spis value for domU

xen/arm: Query - vgic nr_spis value for domU

[Vijay Kilari]

Hi,

In the below snippet, nr_spis is set to 0 from domU based on this
pending_irq[] is allocated

int domain_vgic_init(struct domain *d)
{
    ....
    if ( is_hardware_domain(d) )
        d->arch.vgic.nr_spis = gic_number_lines() - 32;
    else
        d->arch.vgic.nr_spis = 0; /* We don't need SPIs for the guest */
    ...

}

Does it mean that no devices are attached to domU. So spis are required?
If so, for device pass-through (non-pci) how is it managed?

For pci-passthrough I am assigning non-zero value to nr_lpis for both
domU & dom0
and allocating pending_lpis[] because MSIx are assigned to domU
directly on ITS commands
trapped from domain.

Do you see any issue with this?

Regards
Vijay

Re: xen/arm: Query - vgic nr_spis value for domU

[Ian Campbell]

On Tue, 2015-02-24 at 14:54 +0530, Vijay Kilari wrote:
> Hi,
> 
> In the below snippet, nr_spis is set to 0 from domU based on this
> pending_irq[] is allocated
> 
> int domain_vgic_init(struct domain *d)
> {
>     ....
>     if ( is_hardware_domain(d) )
>         d->arch.vgic.nr_spis = gic_number_lines() - 32;
>     else
>         d->arch.vgic.nr_spis = 0; /* We don't need SPIs for the guest */
>     ...
> 
> }
> 
> Does it mean that no devices are attached to domU. So spis are required?
> If so, for device pass-through (non-pci) how is it managed?

Julien's non-pci passthrough series makes this configurable at domain
creation time.

> For pci-passthrough I am assigning non-zero value to nr_lpis for both
> domU & dom0
> and allocating pending_lpis[] because MSIx are assigned to domU
> directly on ITS commands
> trapped from domain.
> 
> Do you see any issue with this?

dom0 should get the underlying h/w platforms value for nr_*, including
spi and lpi

domU should get configurable nr_lpi in the same way Julien has done for
spi. Unless it is possible to make nr_lpi dynamic based on the guests
actual usage patterns (i.e. alloc on demand), that would be ok too.

Ian.

Re: xen/arm: Query - vgic nr_spis value for domU

[Julien Grall]

On 24/02/2015 09:41, Ian Campbell wrote:
> domU should get configurable nr_lpi in the same way Julien has done for
> spi. Unless it is possible to make nr_lpi dynamic based on the guests
> actual usage patterns (i.e. alloc on demand), that would be ok too.

You have to expose the number of LPI's used in GICD_TYPER.
So unless we decide to use hardware value for the guest, we would have to
set a static one at domain creation.

Regards,

-- 
Julien Grall

Re: xen/arm: Query - vgic nr_spis value for domU

[Ian Campbell]

On Tue, 2015-02-24 at 09:48 +0000, Julien Grall wrote:
> 
> On 24/02/2015 09:41, Ian Campbell wrote:
> > domU should get configurable nr_lpi in the same way Julien has done for
> > spi. Unless it is possible to make nr_lpi dynamic based on the guests
> > actual usage patterns (i.e. alloc on demand), that would be ok too.
> 
> You have to expose the number of LPI's used in GICD_TYPER.
> So unless we decide to use hardware value for the guest, we would have to
> set a static one at domain creation.

Right.

With alloc on demand it might be reasonable to expose a pretty high
number (like the h/w limit) in GICD_TYPER if the actual associated
resources aren't actually allocated until they are used.

Ian.

Re: xen/arm: Query - vgic nr_spis value for domU

[Vijay Kilari]

On Tue, Feb 24, 2015 at 3:53 PM, Ian Campbell <ian.campbell@citrix.com> wrote:
> On Tue, 2015-02-24 at 09:48 +0000, Julien Grall wrote:
>>
>> On 24/02/2015 09:41, Ian Campbell wrote:
>> > domU should get configurable nr_lpi in the same way Julien has done for
>> > spi. Unless it is possible to make nr_lpi dynamic based on the guests
>> > actual usage patterns (i.e. alloc on demand), that would be ok too.
>>
>> You have to expose the number of LPI's used in GICD_TYPER.
>> So unless we decide to use hardware value for the guest, we would have to
>> set a static one at domain creation.
>
> Right.
>
> With alloc on demand it might be reasonable to expose a pretty high
> number (like the h/w limit) in GICD_TYPER if the actual associated
> resources aren't actually allocated until they are used.

I propose to add radix tree for each domain for pending_lpis
(synonymous to pending_irq for lpis)
and allocate pending_lpi structure whenever irq_descriptor is allocated/removed
Destroy this radix tree when domain is destroyed.

Regards
Vijay

Re: xen/arm: Query - vgic nr_spis value for domU

[Julien Grall]

Hi Vijay,

On 24/02/15 10:49, Vijay Kilari wrote:
> On Tue, Feb 24, 2015 at 3:53 PM, Ian Campbell <ian.campbell@citrix.com> wrote:
>> On Tue, 2015-02-24 at 09:48 +0000, Julien Grall wrote:
>>>
>>> On 24/02/2015 09:41, Ian Campbell wrote:
>>>> domU should get configurable nr_lpi in the same way Julien has done for
>>>> spi. Unless it is possible to make nr_lpi dynamic based on the guests
>>>> actual usage patterns (i.e. alloc on demand), that would be ok too.
>>>
>>> You have to expose the number of LPI's used in GICD_TYPER.
>>> So unless we decide to use hardware value for the guest, we would have to
>>> set a static one at domain creation.
>>
>> Right.
>>
>> With alloc on demand it might be reasonable to expose a pretty high
>> number (like the h/w limit) in GICD_TYPER if the actual associated
>> resources aren't actually allocated until they are used.
> 
> I propose to add radix tree for each domain for pending_lpis
> (synonymous to pending_irq for lpis)
> and allocate pending_lpi structure whenever irq_descriptor is allocated/removed
> Destroy this radix tree when domain is destroyed.

I'm not sure what you mean by "allocating the pending_lpi whenever
irq_descriptor is allocated/removed"... The irq_desc and pending_lpi
should be allocated differently.

Anyway, I guess it will be easier to understand with your upcoming patch
series.

Regards,

-- 
Julien Grall