Re: [Xen-devel] [PATCH v2 3/7] x86/hvm: convert gsi_assert_count into a variable size array

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.03.17 at 11:59, <roger.pau@xxxxxxxxxx> wrote:
> On Tue, Mar 28, 2017 at 03:49:23AM -0600, Jan Beulich wrote:
>> >>> On 28.03.17 at 11:34, <roger.pau@xxxxxxxxxx> wrote:
>> > On Tue, Mar 28, 2017 at 03:10:27AM -0600, Jan Beulich wrote:
>> >> >>> On 28.03.17 at 10:40, <roger.pau@xxxxxxxxxx> wrote:
>> >> > On Tue, Mar 28, 2017 at 01:25:44AM -0600, Jan Beulich wrote:
>> >> For our DomU model there are four lines. Physical machines often
>> >> declare more in ACPI, and I'm not sure there's a theoretical upper
>> >> limit.
>> > 
>> > In any case, I'm not sure this is relevant to PVH Dom0, where Xen should 
>> > simply
>> > bind GSIs, but has no idea of all the interrupt routing behind them. This 
>> > is
>> > relevant to DomUs because in that case Xen acts as a PCI interrupt router
>> > AFAICT.
>> 
>> Good point. But is all this refcounting code being bypassed for Dom0?
>> If so, you wouldn't need to extend the array here. If not, overflows
>> may still matter.
> 
> It's not really bypassed for Dom0 (Xen still needs to keep track of pending
> interrupts), but it's more simple.
> 
> As said above a GSI is either pending (gsi_assert_count[gsi] == 1) or not
> (gsi_assert_count[gsi] == 0). I could maybe use a bitmap for that and avoid
> touching gsi_assert_count at all, but then I will have to introduce more
> changes.

I don't think there's a need, indeed. But I'd appreciate if you
would add ASSERT()s to that effect.

Jan


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