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
13 matches
Mail list logo
