Re: [RFC 0/6] vSMMU initialization
On Wed, Jul 15, 2015 at 06:28:54PM +0100, Varun Sethi wrote: On Fri, Jun 12, 2015 at 03:20:04PM +0100, Baptiste Reynal wrote: The ARM SMMU has support for 2-stages address translations, allowing a virtual address to be translated at two levels: - Stage 1 translates a virtual address (VA) into an intermediate physical address (IPA) - Stage 2 translates an IPA into a physical address (PA) Will Deacon introduced a virtual SMMU interface for KVM, which gives a virtual machine the possibility to use an IOMMU with native drivers. While the VM will program the first stage of translation (stage 1), the interface will program the second (stage 2) on the physical SMMU. Please note that I have no plans to merge the kernel-side of this at the moment. It was merely an exploratory tool to see what a non-PV vSMMU implementation might look like and certainly not intended to be used in anger. How do you see the context fault reporting work for the PV interface? We could have an interrupt, for the PV IOMMU and have the hypervisor inject that, no? Can you please elaborate on the PV IOMMU interface. I want to understand how context fault information would be communicated to the guest. I replied to this the other day! My assumption is that we'd have an irq and some memory region to describe the fault in as general a way as possible. Whether that memory region looks like MMIO registers or something like a virtio ring buffer is an implementation detail to be resolved by prototyping. Will ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC 0/6] vSMMU initialization
Hi Will, -Original Message- From: Will Deacon [mailto:will.dea...@arm.com] Sent: Tuesday, July 14, 2015 4:34 PM To: Sethi Varun-B16395 Cc: Baptiste Reynal; iommu@lists.linux-foundation.org; t...@virtualopensystems.com; qemu-de...@nongnu.org Subject: Re: [RFC 0/6] vSMMU initialization On Tue, Jul 14, 2015 at 03:21:03AM +0100, Varun Sethi wrote: Hi Will, Hi Varun, On Fri, Jun 12, 2015 at 03:20:04PM +0100, Baptiste Reynal wrote: The ARM SMMU has support for 2-stages address translations, allowing a virtual address to be translated at two levels: - Stage 1 translates a virtual address (VA) into an intermediate physical address (IPA) - Stage 2 translates an IPA into a physical address (PA) Will Deacon introduced a virtual SMMU interface for KVM, which gives a virtual machine the possibility to use an IOMMU with native drivers. While the VM will program the first stage of translation (stage 1), the interface will program the second (stage 2) on the physical SMMU. Please note that I have no plans to merge the kernel-side of this at the moment. It was merely an exploratory tool to see what a non-PV vSMMU implementation might look like and certainly not intended to be used in anger. How do you see the context fault reporting work for the PV interface? We could have an interrupt, for the PV IOMMU and have the hypervisor inject that, no? Can you please elaborate on the PV IOMMU interface. I want to understand how context fault information would be communicated to the guest. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 0/6] vSMMU initialization
On Tue, Jul 14, 2015 at 1:04 PM, Will Deacon will.dea...@arm.com wrote: On Tue, Jul 14, 2015 at 03:21:03AM +0100, Varun Sethi wrote: Hi Will, Hi Varun, On Fri, Jun 12, 2015 at 03:20:04PM +0100, Baptiste Reynal wrote: The ARM SMMU has support for 2-stages address translations, allowing a virtual address to be translated at two levels: - Stage 1 translates a virtual address (VA) into an intermediate physical address (IPA) - Stage 2 translates an IPA into a physical address (PA) Will Deacon introduced a virtual SMMU interface for KVM, which gives a virtual machine the possibility to use an IOMMU with native drivers. While the VM will program the first stage of translation (stage 1), the interface will program the second (stage 2) on the physical SMMU. Please note that I have no plans to merge the kernel-side of this at the moment. It was merely an exploratory tool to see what a non-PV vSMMU implementation might look like and certainly not intended to be used in anger. How do you see the context fault reporting work for the PV interface? We could have an interrupt, for the PV IOMMU and have the hypervisor inject that, no? Currently the vSMMU interface does seem quiet restrictive and it may simplify things by having PV iommu interface. But, do you see this even true in case of SMMUv3? Varun, may I know what do you mean by more restrictive ? Do you have in mind any use case which should apply to the PV interface and not the vSMMU ? I think SMMUv3 is *far* more amenable to the vSMMU approach, largely because it moves many of the data structures into memory, but also because it has support for things like ATS and PRI, so sharing page tables with the CPU becomes a real possibility (and is something that doesn't work well with a PV model). Just wondering if we can give more control with respect memory transaction attributes to the guest. Also, would it make sense to give guest control of the fault handling attributes i.e. fault/terminate model. I'd like to see the basics prototyped before we start trying to design for these more advanced use-cases. I'm confident there are plenty of things we haven't even considered at the moment. Hi Will, From my current understanding, vSMMU and PV interface seems complementary and have different target. While the PV interface targets broad compatibility with hardware and page table abstraction, the vSMMU relies on specific hardware capabilities for better performances (with dual-stage support and future ATS/PRI). As no PV interface exists for now, we decided to focus our effort on the vSMMU. Unless PV interface is strictly needed, we'd like to continue with the implementation of the vSMMU. In my opinion, both solutions are complementary and can co-exist once someone shows interest for the PV. Will Best regards, Baptiste ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 0/6] vSMMU initialization
On Wed, Jul 15, 2015 at 02:38:15PM +0100, Baptiste Reynal wrote: On Tue, Jul 14, 2015 at 1:04 PM, Will Deacon will.dea...@arm.com wrote: I think SMMUv3 is *far* more amenable to the vSMMU approach, largely because it moves many of the data structures into memory, but also because it has support for things like ATS and PRI, so sharing page tables with the CPU becomes a real possibility (and is something that doesn't work well with a PV model). Just wondering if we can give more control with respect memory transaction attributes to the guest. Also, would it make sense to give guest control of the fault handling attributes i.e. fault/terminate model. I'd like to see the basics prototyped before we start trying to design for these more advanced use-cases. I'm confident there are plenty of things we haven't even considered at the moment. From my current understanding, vSMMU and PV interface seems complementary and have different target. While the PV interface targets broad compatibility with hardware and page table abstraction, the vSMMU relies on specific hardware capabilities for better performances (with dual-stage support and future ATS/PRI). As no PV interface exists for now, we decided to focus our effort on the vSMMU. Unless PV interface is strictly needed, we'd like to continue with the implementation of the vSMMU. On the contrary, I'm not going to merge vSMMU code unless there are strong technical reasons against PV. I don't see your performance argument (I would actually expect the vSMMU to be *slower* with SMMUv2) and I really don't want fragmentation where user ABI is concerned. Also, your argument about focussing on vSMMU because PV doesn't exist yet doesn't make sense. Mainline doesn't support either of these for ARM. In my opinion, both solutions are complementary and can co-exist once someone shows interest for the PV. I think you have this the wrong way around. We should start with PV (one portable interface) and only add vSMMU interfaces where there are good reasons to do so. Will ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC 0/6] vSMMU initialization
Hi Baptiste, -Original Message- From: Baptiste Reynal [mailto:b.rey...@virtualopensystems.com] Sent: Wednesday, July 15, 2015 7:08 PM To: Will Deacon Cc: Sethi Varun-B16395; iommu@lists.linux-foundation.org; t...@virtualopensystems.com; qemu-de...@nongnu.org Subject: Re: [RFC 0/6] vSMMU initialization On Tue, Jul 14, 2015 at 1:04 PM, Will Deacon will.dea...@arm.com wrote: On Tue, Jul 14, 2015 at 03:21:03AM +0100, Varun Sethi wrote: Hi Will, Hi Varun, On Fri, Jun 12, 2015 at 03:20:04PM +0100, Baptiste Reynal wrote: The ARM SMMU has support for 2-stages address translations, allowing a virtual address to be translated at two levels: - Stage 1 translates a virtual address (VA) into an intermediate physical address (IPA) - Stage 2 translates an IPA into a physical address (PA) Will Deacon introduced a virtual SMMU interface for KVM, which gives a virtual machine the possibility to use an IOMMU with native drivers. While the VM will program the first stage of translation (stage 1), the interface will program the second (stage 2) on the physical SMMU. Please note that I have no plans to merge the kernel-side of this at the moment. It was merely an exploratory tool to see what a non-PV vSMMU implementation might look like and certainly not intended to be used in anger. How do you see the context fault reporting work for the PV interface? We could have an interrupt, for the PV IOMMU and have the hypervisor inject that, no? Currently the vSMMU interface does seem quiet restrictive and it may simplify things by having PV iommu interface. But, do you see this even true in case of SMMUv3? Varun, may I know what do you mean by more restrictive ? Do you have in mind any use case which should apply to the PV interface and not the vSMMU ? [varun] What I meant was that vSMMU allows for setting up of the stage 1 translation, but doesn't specifically allow access to other SMMU hardware functionality. We can certainly extend the vSMMU interface for providing additional functionality to the guest VM. I do agree with Will, that for extending the vSMMU interface prototyping is necessary. We need to come up with specific use cases for that. For controlling stage 1 translation PV interface may be a bit simpler, but then we would need a generic interface to bind to most IOMMUs in the host. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 0/6] vSMMU initialization
On Tue, Jul 14, 2015 at 03:21:03AM +0100, Varun Sethi wrote: Hi Will, Hi Varun, On Fri, Jun 12, 2015 at 03:20:04PM +0100, Baptiste Reynal wrote: The ARM SMMU has support for 2-stages address translations, allowing a virtual address to be translated at two levels: - Stage 1 translates a virtual address (VA) into an intermediate physical address (IPA) - Stage 2 translates an IPA into a physical address (PA) Will Deacon introduced a virtual SMMU interface for KVM, which gives a virtual machine the possibility to use an IOMMU with native drivers. While the VM will program the first stage of translation (stage 1), the interface will program the second (stage 2) on the physical SMMU. Please note that I have no plans to merge the kernel-side of this at the moment. It was merely an exploratory tool to see what a non-PV vSMMU implementation might look like and certainly not intended to be used in anger. How do you see the context fault reporting work for the PV interface? We could have an interrupt, for the PV IOMMU and have the hypervisor inject that, no? Currently the vSMMU interface does seem quiet restrictive and it may simplify things by having PV iommu interface. But, do you see this even true in case of SMMUv3? I think SMMUv3 is *far* more amenable to the vSMMU approach, largely because it moves many of the data structures into memory, but also because it has support for things like ATS and PRI, so sharing page tables with the CPU becomes a real possibility (and is something that doesn't work well with a PV model). Just wondering if we can give more control with respect memory transaction attributes to the guest. Also, would it make sense to give guest control of the fault handling attributes i.e. fault/terminate model. I'd like to see the basics prototyped before we start trying to design for these more advanced use-cases. I'm confident there are plenty of things we haven't even considered at the moment. Will ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC 0/6] vSMMU initialization
Hi Will, -Original Message- From: iommu-boun...@lists.linux-foundation.org [mailto:iommu- boun...@lists.linux-foundation.org] On Behalf Of Will Deacon Sent: Friday, June 12, 2015 7:53 PM To: Baptiste Reynal Cc: iommu@lists.linux-foundation.org; t...@virtualopensystems.com; qemu-de...@nongnu.org Subject: Re: [RFC 0/6] vSMMU initialization On Fri, Jun 12, 2015 at 03:20:04PM +0100, Baptiste Reynal wrote: The ARM SMMU has support for 2-stages address translations, allowing a virtual address to be translated at two levels: - Stage 1 translates a virtual address (VA) into an intermediate physical address (IPA) - Stage 2 translates an IPA into a physical address (PA) Will Deacon introduced a virtual SMMU interface for KVM, which gives a virtual machine the possibility to use an IOMMU with native drivers. While the VM will program the first stage of translation (stage 1), the interface will program the second (stage 2) on the physical SMMU. Please note that I have no plans to merge the kernel-side of this at the moment. It was merely an exploratory tool to see what a non-PV vSMMU implementation might look like and certainly not intended to be used in anger. How do you see the context fault reporting work for the PV interface? Currently the vSMMU interface does seem quiet restrictive and it may simplify things by having PV iommu interface. But, do you see this even true in case of SMMUv3? Just wondering if we can give more control with respect memory transaction attributes to the guest. Also, would it make sense to give guest control of the fault handling attributes i.e. fault/terminate model. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 0/6] vSMMU initialization
On Fri, Jun 12, 2015 at 03:20:04PM +0100, Baptiste Reynal wrote: The ARM SMMU has support for 2-stages address translations, allowing a virtual address to be translated at two levels: - Stage 1 translates a virtual address (VA) into an intermediate physical address (IPA) - Stage 2 translates an IPA into a physical address (PA) Will Deacon introduced a virtual SMMU interface for KVM, which gives a virtual machine the possibility to use an IOMMU with native drivers. While the VM will program the first stage of translation (stage 1), the interface will program the second (stage 2) on the physical SMMU. Please note that I have no plans to merge the kernel-side of this at the moment. It was merely an exploratory tool to see what a non-PV vSMMU implementation might look like and certainly not intended to be used in anger. Will ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
