Re: [Qemu-devel] [PATCH 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU
On Fri, Feb 19, 2016 at 05:38:48PM +0100, Radim Krčmář wrote: > 2016-02-19 07:46+0100, Jan Kiszka: > > - Rita Sinha is currently working on integrating my old patches with the > > split-irqchip to get KVM working (as an Outreachy project). It's > > probably a bit unfortunate to consider a different horse that late in to > > project. What do you think, how could we benefit from each other? > > > > - Radim was telling me to look on this as well. How do your efforts > > correlate? > > I wasn't aware of Peter's project ... > > Peter, my goal is to support x2APIC to get closer to supporting more > than 255 VCPUs. Please Cc me in future discussions/patches! Sure! Peter
Re: [Qemu-devel] [PATCH 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU
On 2016-02-19 10:29, Peter Xu wrote: >> Would be helpful for more convenient import and experiments. E.g. I >> could quickly through my test setup at them and tell you if they work >> for it. > > I have put codes onto github for better reference: > > https://github.com/xzpeter/qemu/tree/vt-d-intr Just a quick feedback: Interrupts of the root cell (the Linux that hands over the control to the hypervisor) get stuck when starting Jailhouse. What basically happens there is that Linux boots up with DMAR off but IR on, then Jailhouse takes over, turning IR off for a moment, reconfigures things so that it gains control, and then reenables IR (and also turns on DMAR). After that, interrupts no longer arrive at that guest, which is now L2. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU
2016-02-19 07:46+0100, Jan Kiszka: > - Rita Sinha is currently working on integrating my old patches with the > split-irqchip to get KVM working (as an Outreachy project). It's > probably a bit unfortunate to consider a different horse that late in to > project. What do you think, how could we benefit from each other? > > - Radim was telling me to look on this as well. How do your efforts > correlate? I wasn't aware of Peter's project ... Peter, my goal is to support x2APIC to get closer to supporting more than 255 VCPUs. Please Cc me in future discussions/patches! Thanks.
Re: [Qemu-devel] [PATCH 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU
2016-02-19 12:43+0100, Jan Kiszka: > On 2016-02-19 12:34, Peter Xu wrote: >> On Fri, Feb 19, 2016 at 10:58:12AM +0100, Paolo Bonzini wrote: >>> >>> The source ID can be passed to the IOMMU using the MemTxAttrs mechanism. >> >> I see that MemTxAttrs is not enabled yet? It's dropped in all the >> accessors like memory_region_write_accessor()? > > That would be a pity. How much work remains to fix that? Putting Peter > Maydell on CC who apparently started this extension. memory_region_dispatch_write() uses write_with_attrs, so I think we only need to use one for MSI region and add attributes to direct writers (like HPET and IOAPIC, because normal PCI devices should be passing correct attributes). > ... >>> FWIW, Radim was thinking of interrupt remapping in the kvm-ioapic, which >>> we have decided to set aside. > >> Does it mean that we are planning not to support kernel_irqchip for >> IR? Any quick reason? > > The reason to split up the kernel irqchip is to reduce code complexity > and, thus, attack surface of the kernel-side interface towards the > guest. So, extending the "classic" in-kernel support with yet another > feature is not really supporting that goal. A fear of regressions after forcing people to switch from kernel ioapic to qemu ioapic is the only argument for in-kernel support. We'd like to use split irqchip even without IR.
Re: [Qemu-devel] [PATCH 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU
On 2016-02-19 12:39, Peter Xu wrote: > On Fri, Feb 19, 2016 at 11:15:06AM +0100, Jan Kiszka wrote: >> On 2016-02-19 10:58, Paolo Bonzini wrote: >>> 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, Rita, Paolo, > > One more thing to ask: do we have any plan to move on the work to > support vhost/pass-through devices? Do you think we need these too? We need them eventually as well, but - unless some of them just work by chance (unlikely) - that was not in the scope if the ongoing project, rather a potential add-on for later. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU
On 2016-02-19 12:34, Peter Xu wrote: > On Fri, Feb 19, 2016 at 10:58:12AM +0100, Paolo Bonzini wrote: >> >> The source ID can be passed to the IOMMU using the MemTxAttrs mechanism. > > I see that MemTxAttrs is not enabled yet? It's dropped in all the > accessors like memory_region_write_accessor()? That would be a pity. How much work remains to fix that? Putting Peter Maydell on CC who apparently started this extension. ... >> FWIW, Radim was thinking of interrupt remapping in the kvm-ioapic, which >> we have decided to set aside. > > Does it mean that we are planning not to support kernel_irqchip for > IR? Any quick reason? The reason to split up the kernel irqchip is to reduce code complexity and, thus, attack surface of the kernel-side interface towards the guest. So, extending the "classic" in-kernel support with yet another feature is not really supporting that goal. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU
On Fri, Feb 19, 2016 at 11:15:06AM +0100, Jan Kiszka wrote: > On 2016-02-19 10:58, Paolo Bonzini wrote: > > 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, Rita, Paolo, One more thing to ask: do we have any plan to move on the work to support vhost/pass-through devices? Do you think we need these too? Thanks. Peter
Re: [Qemu-devel] [PATCH 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU
On Fri, Feb 19, 2016 at 10:58:12AM +0100, 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. :) Yes, it's nobody's bad except myself if the outreachy link is public for such a long time. I'd need to ask more and do more pre-search on anything I may work on in the future. > > >> 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. Yes. I have not taken SID verification into consideration, as mentioned in the cover letter and code comments. I'd say that if without the MemTxAttrs you mentioned below, current v1 patch does not suite to add this feature. > > The source ID can be passed to the IOMMU using the MemTxAttrs mechanism. I see that MemTxAttrs is not enabled yet? It's dropped in all the accessors like memory_region_write_accessor()? > > >>> So what I was planning is that, this series will be the start. And > >>> the above two is the first-step goal (and I may need kvm-ioapic as > >>> well though). > >> > >> KVM support is actually a key thing, that's why we started the project > >> on integrating the patches with the split irqchip work. There was a > >> consensus with Paolo long ago that full in-kernel irqchip will no longer > >> gain any additional support that is needed for IR. > > Agreed. > > > Do you have any link to the discussion? I am just curious about it, > > thanks in advance. > > I couldn't find anything in k...@vger.kernel.org, sorry. > > - Radim was telling me to look on this as well. How do your efforts > correlate? > > FWIW, Radim was thinking of interrupt remapping in the kvm-ioapic, which > we have decided to set aside. Does it mean that we are planning not to support kernel_irqchip for IR? Any quick reason? Thanks. Peter
Re: [Qemu-devel] [PATCH 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU
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
Re: [Qemu-devel] [PATCH 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU
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. The source ID can be passed to the IOMMU using the MemTxAttrs mechanism. >>> So what I was planning is that, this series will be the start. And >>> the above two is the first-step goal (and I may need kvm-ioapic as >>> well though). >> >> KVM support is actually a key thing, that's why we started the project >> on integrating the patches with the split irqchip work. There was a >> consensus with Paolo long ago that full in-kernel irqchip will no longer >> gain any additional support that is needed for IR. Agreed. > Do you have any link to the discussion? I am just curious about it, > thanks in advance. I couldn't find anything in k...@vger.kernel.org, sorry. - Radim was telling me to look on this as well. How do your efforts correlate? FWIW, Radim was thinking of interrupt remapping in the kvm-ioapic, which we have decided to set aside. Paolo
Re: [Qemu-devel] [PATCH 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU
On Fri, Feb 19, 2016 at 09:34:40AM +0100, Jan Kiszka wrote: > On 2016-02-19 08:43, Peter Xu wrote: > > Hi, Jan, > > > > On Fri, Feb 19, 2016 at 07:46:26AM +0100, Jan Kiszka wrote: > >> Hi Peter, > >> > >> On 2016-02-19 04:30, Peter Xu wrote: > >>> This patchset provide very basic functionalities for interrupt > >>> remapping (IR) support of the emulated Intel IOMMU device. > >> > >> Interesting. Some questions: > >> > >> - Were you aware of > >> http://git.kiszka.org/?p=qemu.git;a=shortlog;h=refs/heads/queues/vtd-intremap, > >> and can you comment on how this relates to your approach? Mine included > >> HPET support, e.g. > > > > No. I do not know we have existing works related. I'd say that I am > > one of those who are not fan of duplicating works. If I know that > > there is existing ones, I would have asked you first. > > > > 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. > > > > > Whatever, I am sorry that finally we got some duplicated work. :-( > > > > I have not go deeper into your codes yet, I'd say that most of the > > logic is alike, since lots of works are to follow the spec. And the > > implementation is slightly different (actually I just got this > > memory region idea from Paolo yesterday... instead of a worse one to > > declare a specific func ops for MSIs). > > 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? What I understand is that, for interrupt remapping, IRT (Interrupt Remapping Table) is shared within the whole device tree managed by specific IOMMU (or say, IRE is shared between different source IDs), which is kinda different from DMAR. The patch should basically work at least on my machine, and please feel free to try it if you want. I just created one public tree on github, link will be pasted below. Also please refer to the cover letter for the command line to boot the guest. I have not done any thorough tests, since I just want to first post it out in case there is anything not right, and both luckily & unluckily... I got to know that there are people working on it before going deeper. :( > > My design introduces a per-source MSI (DMA) target region so that the > IOMMU can do proper remapping by deriving the source device ID from the > targeted region. Then you only need to give the special sources like > IOAPIC and HPET their only regions, and you are done. My thought explained as above. Please let me know if I was wrong. > > > > > What I was going to do is to at least support: > > > > - vhost > > - pass through devices > > vhost, i.e. virtio, has still problems as current virtio guest drivers > assume that their devices are not under control of any IOMMU unit. I > didn't trace the latest news here, but we were once discussing to > initially exclude virtio devices in DMAR scope descriptions in ACPI > and/or introduce some feature negotiation between guest and host to > identify and reject legacy guest drivers without IOMMU-awareness. > > > > > So what I was planning is that, this series will be the start. And > > the above two is the first-step goal (and I may need kvm-ioapic as > > well though). > > KVM support is actually a key thing, that's why we started the project > on integrating the patches with the split irqchip work. There was a > consensus with Paolo long ago that full in-kernel irqchip will no longer > gain any additional support that is needed for IR. Do you have any link to the discussion? I am just curious about it, thanks in advance. > > > > > With the above, we should be able to run DPDK applications in guests > > with either pass-through or vhost-user devices (these should be the > > two scenario which is most possibly to be used AFAIU). This is what > > I was trying to do. HPET is not with high priority in my todo list. > > > >> > >> - Rita Sinha is currently working on integrating my old patches with the > >> split-irqchip to get KVM working (as an Outreachy project). It's > >> probably a bit unfortunate to consider a different horse that late in to > >> project. What do you think, how could we benefit from each other? > > > > I'd say that I am still new to QEMU community. So this is the first > > time I encountered this kind of problem... Do you have any > >
Re: [Qemu-devel] [PATCH 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU
On 2016-02-19 08:43, Peter Xu wrote: > Hi, Jan, > > On Fri, Feb 19, 2016 at 07:46:26AM +0100, Jan Kiszka wrote: >> Hi Peter, >> >> On 2016-02-19 04:30, Peter Xu wrote: >>> This patchset provide very basic functionalities for interrupt >>> remapping (IR) support of the emulated Intel IOMMU device. >> >> Interesting. Some questions: >> >> - Were you aware of >> http://git.kiszka.org/?p=qemu.git;a=shortlog;h=refs/heads/queues/vtd-intremap, >> and can you comment on how this relates to your approach? Mine included >> HPET support, e.g. > > No. I do not know we have existing works related. I'd say that I am > one of those who are not fan of duplicating works. If I know that > there is existing ones, I would have asked you first. > > 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. > > Whatever, I am sorry that finally we got some duplicated work. :-( > > I have not go deeper into your codes yet, I'd say that most of the > logic is alike, since lots of works are to follow the spec. And the > implementation is slightly different (actually I just got this > memory region idea from Paolo yesterday... instead of a worse one to > declare a specific func ops for MSIs). 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? My design introduces a per-source MSI (DMA) target region so that the IOMMU can do proper remapping by deriving the source device ID from the targeted region. Then you only need to give the special sources like IOAPIC and HPET their only regions, and you are done. > > What I was going to do is to at least support: > > - vhost > - pass through devices vhost, i.e. virtio, has still problems as current virtio guest drivers assume that their devices are not under control of any IOMMU unit. I didn't trace the latest news here, but we were once discussing to initially exclude virtio devices in DMAR scope descriptions in ACPI and/or introduce some feature negotiation between guest and host to identify and reject legacy guest drivers without IOMMU-awareness. > > So what I was planning is that, this series will be the start. And > the above two is the first-step goal (and I may need kvm-ioapic as > well though). KVM support is actually a key thing, that's why we started the project on integrating the patches with the split irqchip work. There was a consensus with Paolo long ago that full in-kernel irqchip will no longer gain any additional support that is needed for IR. > > With the above, we should be able to run DPDK applications in guests > with either pass-through or vhost-user devices (these should be the > two scenario which is most possibly to be used AFAIU). This is what > I was trying to do. HPET is not with high priority in my todo list. > >> >> - Rita Sinha is currently working on integrating my old patches with the >> split-irqchip to get KVM working (as an Outreachy project). It's >> probably a bit unfortunate to consider a different horse that late in to >> project. What do you think, how could we benefit from each other? > > I'd say that I am still new to QEMU community. So this is the first > time I encountered this kind of problem... Do you have any > suggestion? > >> >> - Radim was telling me to look on this as well. How do your efforts >> correlate? > > Same as above. Do you have any suggestion on how we'd move on? Specifically you and Rita should exchange your knowledge on both designs (here on the list, of course) and try to find an optimal path. We are unfortunately a bit time-constrained /wrt Outreachy as that project ends in a couple of weeks. By then, we should have first results for the KVM integration - not necessarily the perfect ones, but something working and following the "right" direction. > > One question about your tree: have you posted patches before? and > what's the relationship between your tree and current QEMU master? I never posted the patches as they never left the state of "hacks" as you can quickly spot. However, I think the design is not a hack, but maybe there is indeed something even smarter. Rita has rebased the patches recently, maybe you can share your state, Rita? I did this before, because I'm using them since day #1 to do regular testing of our Jailhouse hypervisor inside QEMU/KVM. For that purpose they work very reliably for IOAPIC, HPET and emulated PCI devices. > >> >>> >>> By default, IR is disabled to be better compatible with
Re: [Qemu-devel] [PATCH 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU
Hi, Jan, On Fri, Feb 19, 2016 at 07:46:26AM +0100, Jan Kiszka wrote: > Hi Peter, > > On 2016-02-19 04:30, Peter Xu wrote: > > This patchset provide very basic functionalities for interrupt > > remapping (IR) support of the emulated Intel IOMMU device. > > Interesting. Some questions: > > - Were you aware of > http://git.kiszka.org/?p=qemu.git;a=shortlog;h=refs/heads/queues/vtd-intremap, > and can you comment on how this relates to your approach? Mine included > HPET support, e.g. No. I do not know we have existing works related. I'd say that I am one of those who are not fan of duplicating works. If I know that there is existing ones, I would have asked you first. 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... Whatever, I am sorry that finally we got some duplicated work. :-( I have not go deeper into your codes yet, I'd say that most of the logic is alike, since lots of works are to follow the spec. And the implementation is slightly different (actually I just got this memory region idea from Paolo yesterday... instead of a worse one to declare a specific func ops for MSIs). What I was going to do is to at least support: - vhost - pass through devices So what I was planning is that, this series will be the start. And the above two is the first-step goal (and I may need kvm-ioapic as well though). With the above, we should be able to run DPDK applications in guests with either pass-through or vhost-user devices (these should be the two scenario which is most possibly to be used AFAIU). This is what I was trying to do. HPET is not with high priority in my todo list. > > - Rita Sinha is currently working on integrating my old patches with the > split-irqchip to get KVM working (as an Outreachy project). It's > probably a bit unfortunate to consider a different horse that late in to > project. What do you think, how could we benefit from each other? I'd say that I am still new to QEMU community. So this is the first time I encountered this kind of problem... Do you have any suggestion? > > - Radim was telling me to look on this as well. How do your efforts > correlate? Same as above. Do you have any suggestion on how we'd move on? One question about your tree: have you posted patches before? and what's the relationship between your tree and current QEMU master? > > > > > By default, IR is disabled to be better compatible with current > > QEMU. To enable IR, we can using the following command to boot a > > IR-supported VM with basic network (still do not support kvm-ioapic, > > so we need to specify kernel_irqchip=off here): > > > > $ qemu-system-x86_64 -M q35,iommu=on,int_remap=on,kernel_irqchip=off \ > > -enable-kvm -m 1024 -s \ > > -monitor telnet::,server,nowait \ > > -netdev user,id=user.0,hostfwd=tcp::-:22 \ > > -device virtio-net-pci,netdev=user.0 \ > > /var/lib/libvirt/images/vm1.qcow2 > > > > When guest boots, we can verify whether IR enabled by grepping the > > dmesg like: > > > > [root@localhost ~]# journalctl -k | grep "DMAR-IR" > > Feb 19 11:21:23 localhost.localdomain kernel: DMAR-IR: IOAPIC id 0 under > > DRHD base 0xfed9 IOMMU 0 > > Feb 19 11:21:23 localhost.localdomain kernel: DMAR-IR: Enabled IRQ > > remapping in xapic mode > > > > Currently only two devices are supported: > > > > - Emulated IOAPIC device > > - PCI Devices > > > > TODO List: > > > > - kvm-ioapic support > > - vhost support > > - pass through device support > > - EIM support > > - IR fault reporting > > - source-id validation for IRTE > > - IRTE cache and better queued invalidation > > - migration support (for IOMMU as general?) > > - more? > > > > Peter Xu (13): > > q35: add "int-remap" flag to enable intr > > acpi: enable INTR for DMAR report structure > > intel_iommu: allow queued invalidation for IR > > intel_iommu: set IR bit for ECAP register > > acpi: add DMAR scope definition for root IOAPIC > > intel_iommu: define interrupt remap table addr register > > intel_iommu: handle interrupt remap enable > > intel_iommu: define several structs for IOMMU IR > > intel_iommu: provide helper function vtd_get_iommu > > ioapic-common: add iommu for IOAPICCommonState > > intel_iommu: add IR translation faults defines > > intel_iommu: ioapic: IR support for emulated IOAPIC > > intel_iommu: Add support for PCI MSI remap > > > > hw/core/machine.c | 20 ++ > > hw/i386/acpi-build.c | 41 +++- > > hw/i386/intel_iommu.c | 397 > > +- > > hw/i386/intel_iommu_internal.h| 25 +++ > > hw/intc/ioapic.c | 36 +++- > > hw/intc/ioapic_common.c | 2 + > > hw/pci-host/q35.c | 6 +- > > include/hw/acpi/acpi-defs.h | 15 ++ > > include/hw/boards.h | 1 + > >
Re: [Qemu-devel] [PATCH 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU
Hi Peter, On 2016-02-19 04:30, Peter Xu wrote: > This patchset provide very basic functionalities for interrupt > remapping (IR) support of the emulated Intel IOMMU device. Interesting. Some questions: - Were you aware of http://git.kiszka.org/?p=qemu.git;a=shortlog;h=refs/heads/queues/vtd-intremap, and can you comment on how this relates to your approach? Mine included HPET support, e.g. - Rita Sinha is currently working on integrating my old patches with the split-irqchip to get KVM working (as an Outreachy project). It's probably a bit unfortunate to consider a different horse that late in to project. What do you think, how could we benefit from each other? - Radim was telling me to look on this as well. How do your efforts correlate? > > By default, IR is disabled to be better compatible with current > QEMU. To enable IR, we can using the following command to boot a > IR-supported VM with basic network (still do not support kvm-ioapic, > so we need to specify kernel_irqchip=off here): > > $ qemu-system-x86_64 -M q35,iommu=on,int_remap=on,kernel_irqchip=off \ > -enable-kvm -m 1024 -s \ > -monitor telnet::,server,nowait \ > -netdev user,id=user.0,hostfwd=tcp::-:22 \ > -device virtio-net-pci,netdev=user.0 \ >/var/lib/libvirt/images/vm1.qcow2 > > When guest boots, we can verify whether IR enabled by grepping the > dmesg like: > > [root@localhost ~]# journalctl -k | grep "DMAR-IR" > Feb 19 11:21:23 localhost.localdomain kernel: DMAR-IR: IOAPIC id 0 under DRHD > base 0xfed9 IOMMU 0 > Feb 19 11:21:23 localhost.localdomain kernel: DMAR-IR: Enabled IRQ remapping > in xapic mode > > Currently only two devices are supported: > > - Emulated IOAPIC device > - PCI Devices > > TODO List: > > - kvm-ioapic support > - vhost support > - pass through device support > - EIM support > - IR fault reporting > - source-id validation for IRTE > - IRTE cache and better queued invalidation > - migration support (for IOMMU as general?) > - more? > > Peter Xu (13): > q35: add "int-remap" flag to enable intr > acpi: enable INTR for DMAR report structure > intel_iommu: allow queued invalidation for IR > intel_iommu: set IR bit for ECAP register > acpi: add DMAR scope definition for root IOAPIC > intel_iommu: define interrupt remap table addr register > intel_iommu: handle interrupt remap enable > intel_iommu: define several structs for IOMMU IR > intel_iommu: provide helper function vtd_get_iommu > ioapic-common: add iommu for IOAPICCommonState > intel_iommu: add IR translation faults defines > intel_iommu: ioapic: IR support for emulated IOAPIC > intel_iommu: Add support for PCI MSI remap > > hw/core/machine.c | 20 ++ > hw/i386/acpi-build.c | 41 +++- > hw/i386/intel_iommu.c | 397 > +- > hw/i386/intel_iommu_internal.h| 25 +++ > hw/intc/ioapic.c | 36 +++- > hw/intc/ioapic_common.c | 2 + > hw/pci-host/q35.c | 6 +- > include/hw/acpi/acpi-defs.h | 15 ++ > include/hw/boards.h | 1 + > include/hw/i386/intel_iommu.h | 121 > include/hw/i386/ioapic_internal.h | 3 + > include/hw/pci/msi.h | 4 + > 12 files changed, 651 insertions(+), 20 deletions(-) > Is there a git tree with your patches somewhere? Thanks, Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] [PATCH 00/13] IOMMU: Enable interrupt remapping for Intel IOMMU
This patchset provide very basic functionalities for interrupt remapping (IR) support of the emulated Intel IOMMU device. By default, IR is disabled to be better compatible with current QEMU. To enable IR, we can using the following command to boot a IR-supported VM with basic network (still do not support kvm-ioapic, so we need to specify kernel_irqchip=off here): $ qemu-system-x86_64 -M q35,iommu=on,int_remap=on,kernel_irqchip=off \ -enable-kvm -m 1024 -s \ -monitor telnet::,server,nowait \ -netdev user,id=user.0,hostfwd=tcp::-:22 \ -device virtio-net-pci,netdev=user.0 \ /var/lib/libvirt/images/vm1.qcow2 When guest boots, we can verify whether IR enabled by grepping the dmesg like: [root@localhost ~]# journalctl -k | grep "DMAR-IR" Feb 19 11:21:23 localhost.localdomain kernel: DMAR-IR: IOAPIC id 0 under DRHD base 0xfed9 IOMMU 0 Feb 19 11:21:23 localhost.localdomain kernel: DMAR-IR: Enabled IRQ remapping in xapic mode Currently only two devices are supported: - Emulated IOAPIC device - PCI Devices TODO List: - kvm-ioapic support - vhost support - pass through device support - EIM support - IR fault reporting - source-id validation for IRTE - IRTE cache and better queued invalidation - migration support (for IOMMU as general?) - more? Peter Xu (13): q35: add "int-remap" flag to enable intr acpi: enable INTR for DMAR report structure intel_iommu: allow queued invalidation for IR intel_iommu: set IR bit for ECAP register acpi: add DMAR scope definition for root IOAPIC intel_iommu: define interrupt remap table addr register intel_iommu: handle interrupt remap enable intel_iommu: define several structs for IOMMU IR intel_iommu: provide helper function vtd_get_iommu ioapic-common: add iommu for IOAPICCommonState intel_iommu: add IR translation faults defines intel_iommu: ioapic: IR support for emulated IOAPIC intel_iommu: Add support for PCI MSI remap hw/core/machine.c | 20 ++ hw/i386/acpi-build.c | 41 +++- hw/i386/intel_iommu.c | 397 +- hw/i386/intel_iommu_internal.h| 25 +++ hw/intc/ioapic.c | 36 +++- hw/intc/ioapic_common.c | 2 + hw/pci-host/q35.c | 6 +- include/hw/acpi/acpi-defs.h | 15 ++ include/hw/boards.h | 1 + include/hw/i386/intel_iommu.h | 121 include/hw/i386/ioapic_internal.h | 3 + include/hw/pci/msi.h | 4 + 12 files changed, 651 insertions(+), 20 deletions(-) -- 2.4.3
