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

[Roger Pau Monne <roger.pau@xxxxxxxxxx>]

On Tue, Mar 28, 2017 at 04:33:49AM -0600, Jan Beulich wrote:
> >>> 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.

OK, such ASSERTs would be added to hvm_gsi_{de}assert in patch #3 of the next
series ("x86/dpci: bind legacy PCI interrupts to PVHv2 Dom0").

Roger.

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