On Wed, Dec 19, 2018 at 08:15:36PM +0100, Cédric Le Goater wrote:
> [ ... ]
>
> >>> +static qemu_irq spapr_qirq_dual(sPAPRMachineState *spapr, int irq)
> >>> +{
> >>> +return spapr_irq_current(spapr)->qirq(spapr, irq);
> >>> +}
> >>
> >> This still makes me really nervous - I'd really prefer t
[ ... ]
>>> +static qemu_irq spapr_qirq_dual(sPAPRMachineState *spapr, int irq)
>>> +{
>>> +return spapr_irq_current(spapr)->qirq(spapr, irq);
>>> +}
>>
>> This still makes me really nervous - I'd really prefer to have qirqs
>> independent of the backend, rather than relying on *every* irq usi
On 12/17/18 7:07 AM, David Gibson wrote:
> On Tue, Dec 11, 2018 at 11:38:22PM +0100, Cédric Le Goater wrote:
>> The 'dual' sPAPR IRQ backend supports both interrupt mode, XIVE
>> exploitation mode and the legacy compatibility mode (XICS). both modes
>> are not supported at the same time.
>>
>> The
On Tue, Dec 11, 2018 at 11:38:22PM +0100, Cédric Le Goater wrote:
> The 'dual' sPAPR IRQ backend supports both interrupt mode, XIVE
> exploitation mode and the legacy compatibility mode (XICS). both modes
> are not supported at the same time.
>
> The machine starts with the legacy mode and a new i
The 'dual' sPAPR IRQ backend supports both interrupt mode, XIVE
exploitation mode and the legacy compatibility mode (XICS). both modes
are not supported at the same time.
The machine starts with the legacy mode and a new interrupt mode can
then be negotiated by the CAS process. In this case, the n
