[Top][All Lists]

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

Re: [Qemu-ppc] [PATCH v5 10/36] spapr/xive: introduce a XIVE interrupt c

From: Cédric Le Goater
Subject: Re: [Qemu-ppc] [PATCH v5 10/36] spapr/xive: introduce a XIVE interrupt controller
Date: Thu, 29 Nov 2018 15:37:12 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0

[ ... ]
>>> With that approach it might make sense to embed it
>>> here, rather than subclassing it 
>> ah. why not indeed. I have to think about it. 
>>> (the old composition vs. inheritance debate).
>> he. but then the XiveRouter needs to become a QOM interface if we 
>> want to be able to define XIVE table accessors for sPAPRXive. See
>> the  spapr_xive_class_init() routine.
> Erm.. I'm not really sure what you're getting at here.

if we compose a sPAPRXive object with a XiveSource object and a XiveRouter 
object, how will the  XiveRouter object access the XIVE internal tables 
which are in the sPAPRXive object ? 

Thinking of it, I am not sure a QOM interface would solve the problem now. 
So we are stuck with inheritance.

[ ... ]

>>>> +qemu_irq spapr_xive_qirq(sPAPRXive *xive, uint32_t lisn)
>>>> +{
>>>> +    XiveSource *xsrc = &xive->source;
>>>> +
>>>> +    if (lisn >= xive->nr_irqs) {
>>>> +        return NULL;
>>>> +    }
>>>> +
>>>> +    if (!(xive->eat[lisn].w & EAS_VALID)) {
>>>> +        qemu_log_mask(LOG_GUEST_ERROR, "XIVE: invalid LISN %x\n", lisn);
>>> I don't think this is a guest error - gettint the qirq by number
>>> should generally be something qemu code does.
>> Even if the IRQ was not defined by the machine ? The EAS_VALID bit is
>> raised when the IRQ is enabled at the XIVE level, which means that the
>> IRQ number has been claimed by some device of the machine. You cannot
>> get a qirq by number for  some random IRQ number. Can you ?
> Well, you shouldn't.  The point is that it is qemu code (specifically
> the machine setup stuff) that will be calling this, and it shouldn't
> be calling it with irq numbers that haven't been
> enabled/claimed/whatever.

so it should be an assert ? 



reply via email to

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