On Tue, 3 Mar 2015, Ian Campbell wrote:
> On Tue, 2015-03-03 at 12:00 +, Stefano Stabellini wrote:
> > > > > > +/* An edge triggered interrupt should now be pending. */
> > > > > > +t->ppi_state.pending = true;
> > > > > > +vcpu_unblock(t->v);
> > > >
> > > > I was goin
On Tue, 2015-03-03 at 12:18 +, Ian Campbell wrote:
> > > > > > +/* Xen s/w state */
> > > > > > +unsigned long inprogress:1;
> > > > > > +};
> > > >
> > > > Using a uint32_t bitmask would be more in line the rest of the code
> > > > style, but it is just a matter of taste.
> > >
> > >
On Tue, 2015-03-03 at 12:00 +, Stefano Stabellini wrote:
> > > > > +/* An edge triggered interrupt should now be pending. */
> > > > > +t->ppi_state.pending = true;
> > > > > +vcpu_unblock(t->v);
> > >
> > > I was going to say that this is trouble because
> > > local_ev
On Tue, 3 Mar 2015, Ian Campbell wrote:
> On Tue, 2015-03-03 at 11:38 +, Stefano Stabellini wrote:
> > > gic_set_irq_properties(desc, cpumask_of(smp_processor_id()),
> > > GIC_PRI_IRQ);
> > >
> > > -/* Use vcpu0 to retrieve the pending_irq struct. Given that we only
> > > - * ro
On Tue, 3 Mar 2015, Ian Campbell wrote:
> On Mon, 2015-03-02 at 18:42 +, Stefano Stabellini wrote:
> > On Tue, 10 Feb 2015, Ian Campbell wrote:
> > > Stefano,
> > >
> > > do you have any comments on the viability of the general approach here
> > > before I go off and start addressing the revie
On Mon, 2015-03-02 at 18:42 +, Stefano Stabellini wrote:
> On Tue, 10 Feb 2015, Ian Campbell wrote:
> > Stefano,
> >
> > do you have any comments on the viability of the general approach here
> > before I go off and start addressing the review comments?
>
> I think that the general approach i
On Tue, 2015-03-03 at 11:38 +, Stefano Stabellini wrote:
> > gic_set_irq_properties(desc, cpumask_of(smp_processor_id()),
> > GIC_PRI_IRQ);
> >
> > -/* Use vcpu0 to retrieve the pending_irq struct. Given that we only
> > - * route SPIs to guests, it doesn't make any difference.
On Mon, 26 Jan 2015, Ian Campbell wrote:
> ... instead of artificially masking the timer interrupt in the timer
> state and relying on the guest to unmask (which it isn't required to
> do per the h/w spec, although Linux does)
>
> To do this introduce the concept of routing a PPI to the currently
On Tue, 10 Feb 2015, Ian Campbell wrote:
> Stefano,
>
> do you have any comments on the viability of the general approach here
> before I go off and start addressing the review comments?
I think that the general approach is OK
> Cheers,
> Ian.
>
> On Mon, 2015-01-26 at 15:55 +, Ian Campbel
Stefano,
do you have any comments on the viability of the general approach here
before I go off and start addressing the review comments?
Cheers,
Ian.
On Mon, 2015-01-26 at 15:55 +, Ian Campbell wrote:
> ... instead of artificially masking the timer interrupt in the timer
> state and relying
On 27/01/15 13:34, Ian Campbell wrote:
>>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>>> index 31fb81a..9074aca 100644
>>> --- a/xen/arch/arm/gic-v2.c
>>> +++ b/xen/arch/arm/gic-v2.c
>>> @@ -156,6 +156,45 @@ static void gicv2_save_state(struct vcpu *v)
>>> writel_gich(0, GICH_
On Tue, 2015-01-27 at 13:16 +, Julien Grall wrote:
> Hi Ian,
>
> On 26/01/15 15:55, Ian Campbell wrote:
> > ... instead of artificially masking the timer interrupt in the timer
> > state and relying on the guest to unmask (which it isn't required to
> > do per the h/w spec, although Linux does
Hi Ian,
On 26/01/15 15:55, Ian Campbell wrote:
> ... instead of artificially masking the timer interrupt in the timer
> state and relying on the guest to unmask (which it isn't required to
> do per the h/w spec, although Linux does)
>
> To do this introduce the concept of routing a PPI to the cur
... instead of artificially masking the timer interrupt in the timer
state and relying on the guest to unmask (which it isn't required to
do per the h/w spec, although Linux does)
To do this introduce the concept of routing a PPI to the currently
running VCPU. For such interrupts irq_get_domain re
14 matches
Mail list logo
