qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH for-2.12 v3 05/11] spapr: introduce an IRQ alloc


From: David Gibson
Subject: Re: [Qemu-devel] [PATCH for-2.12 v3 05/11] spapr: introduce an IRQ allocator using a bitmap
Date: Thu, 23 Nov 2017 22:13:09 +1100
User-agent: Mutt/1.9.1 (2017-09-22)

On Mon, Nov 20, 2017 at 01:07:42PM +0100, Greg Kurz wrote:
> On Fri, 17 Nov 2017 15:50:53 +1100
> David Gibson <address@hidden> wrote:
> 
> > On Tue, Nov 14, 2017 at 10:42:24AM +0100, Greg Kurz wrote:
> > > On Fri, 10 Nov 2017 15:20:11 +0000
> > > Cédric Le Goater <address@hidden> wrote:
> > >   
> > > > Let's define a new set of XICSFabric IRQ operations for the latest
> > > > pseries machine. These simply use a a bitmap 'irq_map' as a IRQ number
> > > > allocator.
> > > > 
> > > > The previous pseries machines keep the old set of IRQ operations using
> > > > the ICSIRQState array.
> > > > 
> > > > Signed-off-by: Cédric Le Goater <address@hidden>
> > > > ---
> > > > 
> > > >  Changes since v2 :
> > > > 
> > > >  - introduced a second set of XICSFabric IRQ operations for older
> > > >    pseries machines
> > > > 
> > > >  hw/ppc/spapr.c         | 76 
> > > > ++++++++++++++++++++++++++++++++++++++++++++++----
> > > >  include/hw/ppc/spapr.h |  3 ++
> > > >  2 files changed, 74 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > > > index 4bdceb45a14f..4ef0b73559ca 100644
> > > > --- a/hw/ppc/spapr.c
> > > > +++ b/hw/ppc/spapr.c
> > > > @@ -1681,6 +1681,22 @@ static const VMStateDescription 
> > > > vmstate_spapr_patb_entry = {
> > > >      },
> > > >  };
> > > >  
> > > > +static bool spapr_irq_map_needed(void *opaque)
> > > > +{
> > > > +    return true;  
> > > 
> > > I see that the next patch adds some code to avoid sending the
> > > bitmap if it doesn't contain state, but I guess you should also
> > > explicitly have this function to return false for older machine
> > > types (see remark below).  
> > 
> > I don't see that you should need to migrate this at all.  The machine
> > needs to reliably allocate the same interrupts each time, and that
> > means source and dest should have the same allocations without
> > migrating data.
> > 
> 
> Is this true for MSIs ? With the current code, the guest can change
> the allocation of such interrupts with the ibm,rtas-change-msi RTAS
> call. How can the dest know about that ?

Yeah, true.  The MSIs really are dynamically allocated by the guest
and so will need to have information migrated.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]