Re: [Qemu-devel] [PATCH v2 12/13] intel_iommu: ioapic: IR support for emulated IOAPIC

[Jan Kiszka]

On 2016-04-13 03:06, Peter Xu wrote:
> On Tue, Apr 12, 2016 at 08:39:21PM -0700, Jan Kiszka wrote:
>> On 2016-04-12 20:33, Peter Xu wrote:
>>> On Tue, Apr 12, 2016 at 08:39:02AM -0700, Jan Kiszka wrote:
>>>> On 2016-04-12 02:02, Peter Xu wrote:
>>>
>>> [...]
>>>
>>>>> Yes, I should consider other x86 platforms like AMD. Thanks to point
>>>>> out. It seems that there are many places in the patchset that lacks
>>>>> thorough consideration about this. Will try to fix them in next
>>>>> version.
>>>>>
>>>>> Regarding to the above MSI solution: I'd say it is a good way to
>>>>> hide everything else behind.  However, since we introduced one extra
>>>>> layer (MSI) which actually does not exist, not sure there would be
>>>>> problem too.  Also, I feel it a little bit hacky if we "create" one
>>>>> MSI out of the air...  For example, if someone tries to capture MSIs
>>>>> from QEMU inside in the APIC memory writes, he will see something he
>>>>> cannot explain if he never knows this hack's there.  Considering the
>>>>> above, I would prefer hooks, or better to provide a callback (a
>>>>> function pointer that others like AMD can override) to do the
>>>>> translation.  How do you think?
>>>>
>>>> The HPET does send MSIs, and I'm not sure how much different the
>>>> IOAPIC's message actually is. In any case, modelling it as MSI is
>>>> neither adding incorrectness nor making the code more complex (in fact,
>>>> the contrary is true!). Last but not least, it would be trivial to
>>>> filter out non-PCI MSI sources if we wanted to trace only PCI - because
>>>> we need to identify the origin anyway for remapping purposes. So,
>>>> explicit hooking looks like the wrong way to me.
>>>
>>> I am just not sure about the difference between IOAPIC's messages
>>> and MSI ones. For now, they seems very alike. However, I am not sure
>>> whether it would be not alike in the future. E.g., if one day, we
>>> extend APIC bus to support more than 255 CPUs (could it? I do not
>>> know for sure), here if we are with this "MSI layer", we would not
>>> be able to do that, since MSI only support 8 bits for destination ID
>>> field. That's my only worry now. If you (or Radim? or anyone more
>>> experienced on this than me) can confirm that this would never be a
>>> problem, I'd be glad to take the MSI way.
>>
>> That's one of the reason why we need IR: >255 is only possible this way,
>> because it requires x2APIC and that requires IR (see Intel spec). So,
>> IOAPIC messages will then always travel via VT-d. No need to worry at all.
> 
> One thing I am curious about: I see that in vtd spec 5.1.5.1:
> 
> "RTE bits 10:8 is programmed to 000b (Fixed) to force the SHV
> (SubHandle Valid) field as Clear in the interrupt address
> generated."
> 
> So... In real IOMMU hardwares, IOAPIC interrupt will finally be
> translated to MSI as well? am I understanding it correctly?

It will be translated into something that the IR unit can receive -
whatever that is technically. Logically, there is no difference to MSIs
received from PCI devices.

> 
> Btw, if to use the way you suggested, the patch content would
> possibly be very alike the one you and Rita has posted, which is:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg01933.html
> 
> I will only pick up those lines I needed in supporting IOAPIC. If
> so, do you mind I add your s-o-b as well above mine (maybe add
> Rita's too)?

If a patch is almost identical, add your [Peter: my changes...] line and
your signed of to it. If it is more modified, claim authorship and just
refer to the original authors in the commit log.

Jan