qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] spapr: pci: clean msi info when releasing it


From: liu ping fan
Subject: Re: [Qemu-devel] [PATCH] spapr: pci: clean msi info when releasing it
Date: Fri, 9 May 2014 15:04:48 +0800

On Wed, May 7, 2014 at 3:20 PM, Alexey Kardashevskiy <address@hidden> wrote:
> On 05/07/2014 04:51 PM, Liu Ping Fan wrote:
>> In current code, we use phb->msi_table[ndev].nvec to indicate whether
>> this msi entries are used by a device or not. So when unplug a pci
>> device, we should reset nvec to zero.
>>
>> Signed-off-by: Liu Ping Fan <address@hidden>
>> ---
>>  hw/ppc/spapr_pci.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
>> index cbef095..7b1dfe1 100644
>> --- a/hw/ppc/spapr_pci.c
>> +++ b/hw/ppc/spapr_pci.c
>> @@ -316,6 +316,7 @@ static void rtas_ibm_change_msi(PowerPCCPU *cpu, 
>> sPAPREnvironment *spapr,
>>              rtas_st(rets, 0, RTAS_OUT_HW_ERROR);
>>              return;
>>          }
>> +        phb->msi_table[ndev].nvec = 0;
>>          trace_spapr_pci_msi("Released MSIs", ndev, config_addr);
>>          rtas_st(rets, 0, RTAS_OUT_SUCCESS);
>>          rtas_st(rets, 1, 0);
>
>
> ibm,change-msi is called with 0 to disable MSIs. If later the guest decides
> to reenable MSI on the same device (rmmod + modprobe in the guest can do
> that I suppose), new block will be allocated because of this patch which is
> bad.
>
> And there is no PCI hotplug for SPAPR in upstream QEMU so this patch cannot
> possibly fix it :)
>
I saw your patch [PATCH 0/6] move interrupts from spapr to xics. And
it is great to consider the reclaim of irq.  So if I call something to
free the irq after "phb->msi_table[ndev].nvec = 0", can it work ?

Thx,
Fan


>
> --
> Alexey
>



reply via email to

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