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.
Ah, right. When we deliver the MSI, it's in remappable format, so there is no destination ID at all... Okay, I can take this in v3. Thanks. -- peterx
