[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 3/3] msi: Handle remappable format interrupt
From: |
Chao Gao |
Subject: |
Re: [Qemu-devel] [PATCH v3 3/3] msi: Handle remappable format interrupt request |
Date: |
Tue, 12 Dec 2017 02:35:16 +0800 |
User-agent: |
Mutt/1.8.0 (2017-02-23) |
On Mon, Dec 11, 2017 at 06:07:48PM +0000, Anthony PERARD wrote:
>On Fri, Nov 17, 2017 at 02:24:25PM +0800, Chao Gao wrote:
>> According to VT-d spec Interrupt Remapping and Interrupt Posting ->
>> Interrupt Remapping -> Interrupt Request Formats On Intel 64
>> Platforms, fields of MSI data register have changed. This patch
>> avoids wrongly regarding a remappable format interrupt request as
>> an interrupt binded with a pirq.
>>
>> Signed-off-by: Chao Gao <address@hidden>
>> Signed-off-by: Lan Tianyu <address@hidden>
>> ---
>> v3:
>> - clarify the interrupt format bit is Intel-specific, then it is
>> improper to define MSI_ADDR_IF_MASK in a common header.
>> ---
>> hw/i386/xen/xen-hvm.c | 10 +++++++++-
>> hw/pci/msi.c | 5 +++--
>> hw/pci/msix.c | 4 +++-
>> hw/xen/xen_pt_msi.c | 2 +-
>> include/hw/xen/xen.h | 2 +-
>> stubs/xen-hvm.c | 2 +-
>> 6 files changed, 18 insertions(+), 7 deletions(-)
>>
>> diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
>> index 8028bed..52dc8af 100644
>> --- a/hw/i386/xen/xen-hvm.c
>> +++ b/hw/i386/xen/xen-hvm.c
>> @@ -145,8 +145,16 @@ void xen_piix_pci_write_config_client(uint32_t address,
>> uint32_t val, int len)
>> }
>> }
>>
>> -int xen_is_pirq_msi(uint32_t msi_data)
>> +int xen_is_pirq_msi(uint32_t msi_addr_lo, uint32_t msi_data)
>> {
>> + /* If the MSI address is configured in remapping format, the MSI will
>> not
>> + * be remapped into a pirq. This 'if' test excludes Intel-specific
>> + * remappable msi.
>> + */
>> +#define MSI_ADDR_IF_MASK 0x00000010
>
>I don't think that is the right place for a define, they also exist
>outside of the context of the function.
yes.
>That define would be better at the top of this file, I think.(There is
will do.
Thanks
Chao
>probably a better place in the common headers, but I'm not sure were.)