On 2016-02-19 10:58, Paolo Bonzini wrote: > > > On 19/02/2016 10:29, Peter Xu wrote: >> On Fri, Feb 19, 2016 at 09:34:40AM +0100, Jan Kiszka wrote: >>> On 2016-02-19 08:43, Peter Xu wrote: >>>> Actually there are several people within my working team knows that >>>> I would be working on this, and I believe none of us do know your >>>> work too... Or there must be someone telling me so... >>> >>> I guess we would have to match sets of people know to find out who >>> forgot to mention the outreachy project ;) - anyway, this can always happen. > > I knew about the outreachy project and forgot to mention it... but then, > I only learnt about your effort yesterday. :) > >>> I didn't look into your approach in all details yet, and Rita also just >>> started, she told me. So one question on yours - which looks appealing >>> from the invasiveness POV - is how you determine the MSI source with >>> only a single target region? I do find your changes on the IOAPIC, but >>> none on the PCI infrastructure, which is confusing given that you say >>> that works, no? >> >> Do we need to know the source of the MSI interrupt to >> translate/deliver it? Maybe I got something missing, but could you >> explain why we need it? > > I think you're not verifying the SVT, SID and SQ fields in the IRTE.
Exactly. > > The source ID can be passed to the IOMMU using the MemTxAttrs mechanism. Ah, that's a nice new channel, resolving the need for using/passing source-specific target memory regions for this. At least for PCI devices, it should already be populated with the required information, others (IOAPIC, HPET) probably require additional work to pass what I defined as Q35_PSEUDO_BUS_PLATFORM, Q35_PSEUDO_DEVFN_IOAPIC/HPET. Jan
signature.asc
Description: OpenPGP digital signature
