Re: [Qemu-devel] [Qemu-arm] [PATCH v7 00/20] ARM SMMUv3 Emulation Support
Hi Will, On Tue, Oct 24, 2017 at 11:20:29AM +0100, Will Deacon wrote: > On Tue, Oct 24, 2017 at 11:08:02AM +0530, Linu Cherian wrote: > > On Fri Sep 01, 2017 at 07:21:03PM +0200, Eric Auger wrote: > > > This series implements the emulation code for ARM SMMUv3. > > > > > > Changes since v6: > > > - DPDK testpmd now running on guest with 2 assigned VFs > > > - Changed the instantiation method: add the following option to > > > the QEMU command line > > > -device smmuv3 # for virtio/vhost use cases > > > -device smmuv3,caching-mode # for vfio use cases (based on [1]) > > > - splitted the series into smaller patches to allow the review > > > - the VFIO integration based on "tlbi-on-map" smmuv3 driver > > > is isolated from the rest: last 2 patches, not for upstream. > > > This is shipped for testing/bench until a better solution is found. > > > - Reworked permission flag checks and event generation > > > > > > testing: > > > - in dt and ACPI modes > > > - virtio-net-pci and vhost-net devices using dma ops with various > > > guest page sizes [2] > > > - assigned VFs using dma ops [3]: > > > - AMD Overdrive and igbvf passthrough (using gsi direct mapping) > > > - Cavium ThunderX and ixgbevf passthrough (using KVM MSI routing) > > > - DPDK testpmd on guest running with VFIO user space drivers (2 igbvf) [3] > > > with guest and host page size equal (4kB) > > > > > > Known limitations: > > > - no VMSAv8-32 suport > > > - no nested stage support (S1 + S2) > > > - no support for HYP mappings > > > - register fine emulation, commands, interrupts and errors were > > > not accurately tested. Handling is sufficient to run use cases > > > described above though. > > > - interrupts and event generation not observed yet. > > > > > > Best Regards > > > > > > Eric > > > > > > > Was looking at options to get rid of the existing hacks we have > > in this implementation (last two patches) and also to reduce the > > map/unmap/translation > > overhead for the guest kernel devices. > > > > Interestingly, the nested stage translation + smmu emulation at kernel > > that we were exploring, has been already tried by Will Deacon. > > https://www.linuxplumbersconf.org/2014/ocw/system/presentations/2019/original/vsmmu-lpc14.pdf > > https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg03379.html > > > > > > It would be nice to understand, why this solution was not pursued atleast > > for vfio-pci devices. > > OR > > If you have already plans to do nested stage support in the future, would > > be interested to know > > about it. > > I don't plan to revive that code. I got something well on the way to working > for SMMUv2, but it had some pretty major issues: > > 1. A huge amount of emulation code in the kernel > 2. A horribly complicated user ABI > 3. Keeping track of internal hardware caching state was a nightmare, so >over-invalidation was rife > 4. Errata workarounds meant trapping all SMMU accesses (inc. for stage 1) > 5. I remember having issues with interrupts, but this was likely >SMMUv2-specific > 6. There was no scope for code re-use with other SMMU implementations (e.g. >SMMUv3) > > Overall, it was just an unmaintainable, non-performant > security-flaw-waiting-to-happen so I parked it. That's some of the > background behind me preferring a virtio-iommu approach, because there's > the potential for kernel acceleration using something like vhost. > > Will Thanks for the explanation.
Re: [Qemu-devel] [Qemu-arm] [PATCH v7 00/20] ARM SMMUv3 Emulation Support
ll qemu_log > (since translation requests are too many, we need control > on the type of log we want) > - SMMUTransCfg modified to suite simplicity > - Change RegInfo to uint64 register array > - Code cleanup > - Test cleanups > - Reshuffled patches > > v0 -> v1 [Prem]: > - As per SMMUv3 spec 16.0 (only is_ste_consistant() is noticeable) > - Reworked register access/update logic > - Factored out translation code for > - single point bug fix > - sharing/removal in future > - (optional) Unit tests added, with PCI test device > - S1 with 4k/64k, S1+S2 with 4k/64k > - (S1 or S2) only can be verified by Linux 4.7 driver > - (optional) Priliminary ACPI support > > v0 [Prem]: > - Implements SMMUv3 spec 11.0 > - Supported for PCIe devices, > - Command Queue and Event Queue supported > - LPAE only, S1 is supported and Tested, S2 not tested > - BE mode Translation not supported > - IRQ support (legacy, no MSI) > > Eric Auger (18): > hw/arm/smmu-common: smmu base device and datatypes > hw/arm/smmu-common: IOMMU memory region and address space setup > hw/arm/smmu-common: smmu_read/write_sysmem > hw/arm/smmu-common: VMSAv8-64 page table walk > hw/arm/smmuv3: Wired IRQ and GERROR helpers > hw/arm/smmuv3: Queue helpers > hw/arm/smmuv3: Implement MMIO write operations > hw/arm/smmuv3: Event queue recording helper > hw/arm/smmuv3: Implement translate callback > target/arm/kvm: Translate the MSI doorbell in kvm_arch_fixup_msi_route > hw/arm/smmuv3: Implement data structure and TLB invalidation > notifications > hw/arm/smmuv3: Implement IOMMU memory region replay callback > hw/arm/virt: Store the PCI host controller dt phandle > hw/arm/sysbus-fdt: Pass the VirtMachineState to the node creation > functions > hw/arm/sysbus-fdt: Pass the platform bus base address in > PlatformBusFDTData > hw/arm/sysbus-fdt: Allow smmuv3 dynamic instantiation > hw/arm/smmuv3: [not for upstream] add SMMU_CMD_TLBI_NH_VA_AM handling > hw/arm/smmuv3: [not for upstream] Add caching-mode option > > Prem Mallappa (2): > hw/arm/smmuv3: Skeleton > hw/arm/virt-acpi-build: Add smmuv3 node in IORT table > > default-configs/aarch64-softmmu.mak |1 + > hw/arm/Makefile.objs|1 + > hw/arm/smmu-common.c| 527 > hw/arm/smmu-internal.h | 105 > hw/arm/smmuv3-internal.h| 584 + > hw/arm/smmuv3.c | 1181 > +++ > hw/arm/sysbus-fdt.c | 129 +++- > hw/arm/trace-events | 48 ++ > hw/arm/virt-acpi-build.c| 63 +- > hw/arm/virt.c |6 +- > include/hw/acpi/acpi-defs.h | 15 + > include/hw/arm/smmu-common.h| 123 > include/hw/arm/smmuv3.h | 80 +++ > include/hw/arm/sysbus-fdt.h |2 + > include/hw/arm/virt.h | 15 + > target/arm/kvm.c| 27 + > target/arm/trace-events |3 + > 17 files changed, 2886 insertions(+), 24 deletions(-) > create mode 100644 hw/arm/smmu-common.c > create mode 100644 hw/arm/smmu-internal.h > create mode 100644 hw/arm/smmuv3-internal.h > create mode 100644 hw/arm/smmuv3.c > create mode 100644 include/hw/arm/smmu-common.h > create mode 100644 include/hw/arm/smmuv3.h > > -- > 2.5.5 > > -- Linu cherian
Re: [Qemu-devel] [Qemu-arm] [PATCH v7 19/20] hw/arm/smmuv3: [not for upstream] add SMMU_CMD_TLBI_NH_VA_AM handling
Hi Eric,
On Fri Sep 01, 2017 at 07:21:22PM +0200, Eric Auger wrote:
> SMMUV3 does not support any IOVA range TLBI command:
> SMMU_CMD_TLBI_NH_VA invalidates TLB entries by page.
> That's an issue when running DPDK on guest. DPDK uses
> hugepages but each time a hugepage is mapped on guest side,
> a storm of SMMU_CMD_TLBI_NH_VA commands get sent by the
> guest smmuv3 driver and trapped by QEMU for VFIO replay.
>
> Let's get prepared to handle implementation defined commands,
> SMMU_CMD_TLBI_NH_VA_VM, which invalidate a range of IOVAs.
>
> Upon this command, we notify the whole range in one host.
>
> Signed-off-by: Eric Auger <eric.au...@redhat.com>
> ---
> hw/arm/smmuv3-internal.h | 1 +
> hw/arm/smmuv3.c | 13 +
> hw/arm/trace-events | 1 +
> 3 files changed, 15 insertions(+)
>
> diff --git a/hw/arm/smmuv3-internal.h b/hw/arm/smmuv3-internal.h
> index f9f95ae..e70cf76 100644
> --- a/hw/arm/smmuv3-internal.h
> +++ b/hw/arm/smmuv3-internal.h
> @@ -289,6 +289,7 @@ enum {
> SMMU_CMD_RESUME = 0x44,
> SMMU_CMD_STALL_TERM,
> SMMU_CMD_SYNC, /* 0x46 */
> +SMMU_CMD_TLBI_NH_VA_AM = 0x8F, /* VIOMMU Impl Defined */
> };
>
> static const char *cmd_stringify[] = {
> diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
> index 9c8640f..55dc80b 100644
> --- a/hw/arm/smmuv3.c
> +++ b/hw/arm/smmuv3.c
> @@ -880,6 +880,19 @@ static int smmuv3_cmdq_consume(SMMUV3State *s)
> smmuv3_replay_iova_range(>smmu_state, addr, size);
> break;
> }
> +case SMMU_CMD_TLBI_NH_VA_AM:
> +{
> +int asid = extract32(cmd.word[1], 16, 16);
> +int am = extract32(cmd.word[1], 0, 16);
> +uint64_t low = extract32(cmd.word[2], 12, 20);
> +uint64_t high = cmd.word[3];
> +uint64_t addr = high << 32 | (low << 12);
> +size_t size = am << 12;
>
While testing dpdk, observed that there are map requests coming to
arm smmuv3 driver with size greater than 256M. Since the current
code supports only 256M( 16 + 12 bits), had to abuse the asid field
to pass the extra bits for address mask to get things working.
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 04e2d75..51b1d07 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -1418,7 +1418,10 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long
iova, size_t size,
if (smmu->options & ARM_SMMU_OPT_TLBI_ON_MAP) {
cmd.opcode = CMDQ_OP_TLBI_NH_VA_AM;
cmd.tlbi.am = size >> 12;
+ cmd.tlbi.asid = size >> 28;
granule = size;
On Qemu side,
if (cfg.disabled || cfg.bypassed) {
@@ -884,12 +899,15 @@ static int smmuv3_cmdq_consume(SMMUV3State *s)
case SMMU_CMD_TLBI_NH_VA_AM:
{
int asid = extract32(cmd.word[1], 16, 16);
int am = extract32(cmd.word[1], 0, 16);
uint64_t low = extract32(cmd.word[2], 12, 20);
uint64_t high = cmd.word[3];
uint64_t addr = high << 32 | (low << 12);
size_t size = am << 12;
+ am = am | asid << 16;
+ size = am << 12;
+
+
> +trace_smmuv3_cmdq_tlbi_nh_va_am(asid, am, addr, size);
> +smmuv3_replay_iova_range(>smmu_state, addr, size);
> +break;
> +}
> case SMMU_CMD_TLBI_NH_VAA:
> case SMMU_CMD_TLBI_EL3_ALL:
> case SMMU_CMD_TLBI_EL3_VA:
> diff --git a/hw/arm/trace-events b/hw/arm/trace-events
> index 15f84d6..fba33ac 100644
> --- a/hw/arm/trace-events
> +++ b/hw/arm/trace-events
> @@ -26,6 +26,7 @@ smmuv3_cmdq_opcode(const char *opcode) "<--- %s"
> smmuv3_cmdq_cfgi_ste(int streamid) " |_ streamid =%d"
> smmuv3_cmdq_cfgi_ste_range(int start, int end) " |_ start=0x%d -
> end=0x%d"
> smmuv3_cmdq_tlbi_nh_va(int asid, int vmid, uint64_t addr) " |_ asid =%d
> vmid =%d addr=0x%"PRIx64
> +smmuv3_cmdq_tlbi_nh_va_am(int asid, int am, size_t size, uint64_t addr) "
> |_ asid =%d am =%d size=0x%lx addr=0x%"PRIx64
> smmuv3_cmdq_consume_out(uint8_t prod_wrap, uint32_t prod, uint8_t cons_wrap,
> uint32_t cons) "prod_wrap:%d, prod:0x%x cons_wrap:%d cons:0x%x"
> smmuv3_update(bool is_empty, uint32_t prod, uint32_t cons, uint8_t
> prod_wrap, uint8_t cons_wrap) "q empty:%d prod:%d cons:%d p.wrap:%d p.cons:%d"
> smmuv3_update_check_cmd(int error) "cmdq not enabled or error :0x%x"
> --
> 2.5.5
>
>
--
Linu cherian
Re: [Qemu-devel] [Qemu-arm] [PATCH v4 0/5] virtio-iommu: VFIO integration
On Fri Oct 06, 2017 at 09:24:20AM +0200, Auger Eric wrote:
> Hi Bharat,
>
> On 06/10/2017 05:46, Bharat Bhushan wrote:
> >
> >
> >>>> Thanks
> >>>>
> >>>> Eric
> >>>>>
> >>>>> However you should be allowed to map 1 sg element of 5 pages and
> >>>>> then notify the host about this event I think. Still looking at the
> >>>>> code...
> >>>>>
> >>>>> I still can't reproduce the issue at the moment. What kind of device
> >>>>> are you assigning?
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> Eric
> >>>>>>
> >>>>>> Atleast vfio_get_vaddr called from vfio_iommu_map_notify in Qemu
> >>>>>> expects the map size to be a power of 2.
> >>>
> >>> Actually I missed the most important here ;-)
> >>>>>>
> >>>>>> if (len & iotlb->addr_mask) {
> >>> This check looks suspiscious to me. In our case the len is not
> >>> modified by the previous translation and it fails, I don't see why. It
> >>> should be valid to be able to notify 5 granules.
> >>
> >> So after discussion with Alex, looks the way we notify the host currently
> >> is
> >> wrong. we set the addr_mask to the mapping/unmapping size
> >> -1 whereas this should be a page mask instead (granule size or block
> >> size?).
> >> So if the guest maps 5 x 4kB pages we should send 5 notifications for each
> >> page and not a single one. It is unclear to me if we can notify with
> >> hugepage/block page size mask. Peter may confirm/infirm this. in vsmmuv3
> >> code I notify by granule or block size.
> >>
> >> Bharat, please can you add this to your TODO list?
> >>
> >> Linu, thanks a lot for the time you spent debugging this issue.
> >> Curiously on my side, it is really seldom hit but it is ...
> >
> > Thanks Linu and Eric, I added this to my todo list.
> > While I am still not able to reproduce the issue. I tried with e1000 and
> > now try with ixgbe device. May I know which device can be used to reproduce
> > this issue?
>
> On my side I used an i350T2 device (igb) to reproduce the issue.
Myself used a Thunderx NIC which is an on chip PCI device.
--
Linu cherian
Re: [Qemu-devel] [Qemu-arm] [PATCH v4 0/5] virtio-iommu: VFIO integration
Hi Eric,
On Wed Sep 27, 2017 at 11:24:01AM +0200, Auger Eric wrote:
> Hi Linu,
>
> On 27/09/2017 11:21, Linu Cherian wrote:
> > On Wed Sep 27, 2017 at 10:55:07AM +0200, Auger Eric wrote:
> >> Hi Linu,
> >>
> >> On 27/09/2017 10:30, Bharat Bhushan wrote:
> >>> Hi,
> >>>
> >>>> -Original Message-
> >>>> From: Linu Cherian [mailto:linuc.dec...@gmail.com]
> >>>> Sent: Wednesday, September 27, 2017 1:11 PM
> >>>> To: Bharat Bhushan <bharat.bhus...@nxp.com>
> >>>> Cc: eric.au...@redhat.com; eric.auger@gmail.com;
> >>>> peter.mayd...@linaro.org; alex.william...@redhat.com; m...@redhat.com;
> >>>> qemu-...@nongnu.org; qemu-devel@nongnu.org; kevin.t...@intel.com;
> >>>> marc.zyng...@arm.com; t...@semihalf.com; will.dea...@arm.com;
> >>>> drjo...@redhat.com; robin.mur...@arm.com; christoffer.d...@linaro.org;
> >>>> bharatb.ya...@gmail.com
> >>>> Subject: Re: [Qemu-arm] [PATCH v4 0/5] virtio-iommu: VFIO integration
> >>>>
> >>>> Hi,
> >>>>
> >>>> On Wed Sep 27, 2017 at 12:03:15PM +0530, Bharat Bhushan wrote:
> >>>>> This patch series integrates VFIO/VHOST with virtio-iommu.
> >>>>>
> >>>>> This version is mainly about rebasing on v4 version on virtio-iommu
> >>>>> device framework from Eric Augur and addresing review comments.
> >>>>>
> >>>>> This patch series allows PCI pass-through using virtio-iommu.
> >>>>>
> >>>>> This series is based on:
> >>>>> - virtio-iommu kernel driver by Jean-Philippe Brucker
> >>>>> [1] [RFC] virtio-iommu version 0.4
> >>>>> git://linux-arm.org/virtio-iommu.git branch viommu/v0.4
> >>
> >> Just to make sure, do you use the v0.4 virtio-iommu driver from above
> >> branch?
> >>
> >> Thanks
> >
> > I am using git://linux-arm.org/linux-jpb.git branch virtio-iommu/v0.4.
> > Hope you are referring to the same.
>
> Yes that's the right one. I will also investigate on my side this afternoon.
>
> Thanks
>
> Eric
With the below workaround, atleast ping works for me.
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 249964a..2904617 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
.attach_dev = viommu_attach_dev,
.map= viommu_map,
.unmap = viommu_unmap,
- .map_sg = viommu_map_sg,
+ .map_sg = default_iommu_map_sg,
.iova_to_phys = viommu_iova_to_phys,
.add_device = viommu_add_device,
.remove_device = viommu_remove_device,
Looks like the qemu backend doesnt have support to handle the map requests from
virtio_iommu_map_sg, since it merges multiple map requests into one with
mapsize larger than page size(for eg. 0x5000).
Atleast vfio_get_vaddr called from vfio_iommu_map_notify in Qemu expects
the map size to be a power of 2.
if (len & iotlb->addr_mask) {
error_report("iommu has granularity incompatible with target AS");
return false;
}
Just trying to understand how this is not hitting in your case.
--
Linu cherian
Re: [Qemu-devel] [Qemu-arm] [PATCH v7 00/20] ARM SMMUv3 Emulation Support
On Thu Sep 28, 2017 at 09:54:20AM +0200, Auger Eric wrote: > Hi Linu, Peter, > > On 28/09/2017 09:13, Peter Xu wrote: > > On Thu, Sep 28, 2017 at 12:13:12PM +0530, Linu Cherian wrote: > >> Hi Eric, > >> > >> > >> On Fri Sep 01, 2017 at 07:21:03PM +0200, Eric Auger wrote: > >>> This series implements the emulation code for ARM SMMUv3. > >>> > >>> Changes since v6: > >>> - DPDK testpmd now running on guest with 2 assigned VFs > >>> - Changed the instantiation method: add the following option to > >>> the QEMU command line > >>> -device smmuv3 # for virtio/vhost use cases > >>> -device smmuv3,caching-mode # for vfio use cases (based on [1]) > >>> - splitted the series into smaller patches to allow the review > >>> - the VFIO integration based on "tlbi-on-map" smmuv3 driver > >>> is isolated from the rest: last 2 patches, not for upstream. > >>> This is shipped for testing/bench until a better solution is found. > >>> - Reworked permission flag checks and event generation > >>> e testing: > >>> - in dt and ACPI modes > >>> - virtio-net-pci and vhost-net devices using dma ops with various > >>> guest page sizes [2] > >>> - assigned VFs using dma ops [3]: > >>> - AMD Overdrive and igbvf passthrough (using gsi direct mapping) > >>> - Cavium ThunderX and ixgbevf passthrough (using KVM MSI routing) > >>> - DPDK testpmd on guest running with VFIO user space drivers (2 igbvf) [3] > >>> with guest and host page size equal (4kB) > >>> > >>> Known limitations: > >>> - no VMSAv8-32 suport > >>> - no nested stage support (S1 + S2) > >>> - no support for HYP mappings > >>> - register fine emulation, commands, interrupts and errors were > >>> not accurately tested. Handling is sufficient to run use cases > >>> described above though. > >>> - interrupts and event generation not observed yet. > >> > >> While testing with vfio-pci, observed that the below two Qemu command, > >> results in two different behaviour. Is this expected by design ? > >> > >> Case 1: > >> # -device vfio-pci,host=0002:01:00.3 -device smmuv3,caching-mode > >> Here iommu is not attached to the pci bus in Qemu backend, since > >> pci_setup_iommu is not called before vfio_realize. > >> > >> Case 2: > >> # -device smmuv3,caching-mode -device vfio-pci,host=0002:01:00.3 > >> This works as expected, iommu is attached to the pci bus. > > > > Not sure about SMMU, but VT-d should have similar issue - the vIOMMU > > device needs to be created before the rest of the devices. > > Yes this is an expected limitation right now. I should have documented > it though. As you noticed, the pci_set_iommu() is called on virtio-iommu > realize and it relies on the fact the PCIe devices already are realized. > > Maybe we could relax this constraint by calling the pci_set_iommu in a > machine init done notifier. > > Thanks > > Eric Thanks for confirming. > > > > > > Now for VT-d the ordering of devices should be assured by Libvirt: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1427005 > > > > For your reference only. Thanks, > > -- Linu cherian
Re: [Qemu-devel] [Qemu-arm] [PATCH v7 00/20] ARM SMMUv3 Emulation Support
t; - Code cleanup > - Test cleanups > - Reshuffled patches > > v0 -> v1 [Prem]: > - As per SMMUv3 spec 16.0 (only is_ste_consistant() is noticeable) > - Reworked register access/update logic > - Factored out translation code for > - single point bug fix > - sharing/removal in future > - (optional) Unit tests added, with PCI test device > - S1 with 4k/64k, S1+S2 with 4k/64k > - (S1 or S2) only can be verified by Linux 4.7 driver > - (optional) Priliminary ACPI support > > v0 [Prem]: > - Implements SMMUv3 spec 11.0 > - Supported for PCIe devices, > - Command Queue and Event Queue supported > - LPAE only, S1 is supported and Tested, S2 not tested > - BE mode Translation not supported > - IRQ support (legacy, no MSI) > > Eric Auger (18): > hw/arm/smmu-common: smmu base device and datatypes > hw/arm/smmu-common: IOMMU memory region and address space setup > hw/arm/smmu-common: smmu_read/write_sysmem > hw/arm/smmu-common: VMSAv8-64 page table walk > hw/arm/smmuv3: Wired IRQ and GERROR helpers > hw/arm/smmuv3: Queue helpers > hw/arm/smmuv3: Implement MMIO write operations > hw/arm/smmuv3: Event queue recording helper > hw/arm/smmuv3: Implement translate callback > target/arm/kvm: Translate the MSI doorbell in kvm_arch_fixup_msi_route > hw/arm/smmuv3: Implement data structure and TLB invalidation > notifications > hw/arm/smmuv3: Implement IOMMU memory region replay callback > hw/arm/virt: Store the PCI host controller dt phandle > hw/arm/sysbus-fdt: Pass the VirtMachineState to the node creation > functions > hw/arm/sysbus-fdt: Pass the platform bus base address in > PlatformBusFDTData > hw/arm/sysbus-fdt: Allow smmuv3 dynamic instantiation > hw/arm/smmuv3: [not for upstream] add SMMU_CMD_TLBI_NH_VA_AM handling > hw/arm/smmuv3: [not for upstream] Add caching-mode option > > Prem Mallappa (2): > hw/arm/smmuv3: Skeleton > hw/arm/virt-acpi-build: Add smmuv3 node in IORT table > > default-configs/aarch64-softmmu.mak |1 + > hw/arm/Makefile.objs|1 + > hw/arm/smmu-common.c| 527 > hw/arm/smmu-internal.h | 105 > hw/arm/smmuv3-internal.h| 584 + > hw/arm/smmuv3.c | 1181 > +++ > hw/arm/sysbus-fdt.c | 129 +++- > hw/arm/trace-events | 48 ++ > hw/arm/virt-acpi-build.c| 63 +- > hw/arm/virt.c |6 +- > include/hw/acpi/acpi-defs.h | 15 + > include/hw/arm/smmu-common.h| 123 > include/hw/arm/smmuv3.h | 80 +++ > include/hw/arm/sysbus-fdt.h |2 + > include/hw/arm/virt.h | 15 + > target/arm/kvm.c| 27 + > target/arm/trace-events |3 + > 17 files changed, 2886 insertions(+), 24 deletions(-) > create mode 100644 hw/arm/smmu-common.c > create mode 100644 hw/arm/smmu-internal.h > create mode 100644 hw/arm/smmuv3-internal.h > create mode 100644 hw/arm/smmuv3.c > create mode 100644 include/hw/arm/smmu-common.h > create mode 100644 include/hw/arm/smmuv3.h > > -- > 2.5.5 > > -- Linu cherian
Re: [Qemu-devel] [Qemu-arm] [PATCH v4 0/5] virtio-iommu: VFIO integration
On Wed Sep 27, 2017 at 10:55:07AM +0200, Auger Eric wrote:
> Hi Linu,
>
> On 27/09/2017 10:30, Bharat Bhushan wrote:
> > Hi,
> >
> >> -Original Message-
> >> From: Linu Cherian [mailto:linuc.dec...@gmail.com]
> >> Sent: Wednesday, September 27, 2017 1:11 PM
> >> To: Bharat Bhushan <bharat.bhus...@nxp.com>
> >> Cc: eric.au...@redhat.com; eric.auger@gmail.com;
> >> peter.mayd...@linaro.org; alex.william...@redhat.com; m...@redhat.com;
> >> qemu-...@nongnu.org; qemu-devel@nongnu.org; kevin.t...@intel.com;
> >> marc.zyng...@arm.com; t...@semihalf.com; will.dea...@arm.com;
> >> drjo...@redhat.com; robin.mur...@arm.com; christoffer.d...@linaro.org;
> >> bharatb.ya...@gmail.com
> >> Subject: Re: [Qemu-arm] [PATCH v4 0/5] virtio-iommu: VFIO integration
> >>
> >> Hi,
> >>
> >> On Wed Sep 27, 2017 at 12:03:15PM +0530, Bharat Bhushan wrote:
> >>> This patch series integrates VFIO/VHOST with virtio-iommu.
> >>>
> >>> This version is mainly about rebasing on v4 version on virtio-iommu
> >>> device framework from Eric Augur and addresing review comments.
> >>>
> >>> This patch series allows PCI pass-through using virtio-iommu.
> >>>
> >>> This series is based on:
> >>> - virtio-iommu kernel driver by Jean-Philippe Brucker
> >>> [1] [RFC] virtio-iommu version 0.4
> >>> git://linux-arm.org/virtio-iommu.git branch viommu/v0.4
>
> Just to make sure, do you use the v0.4 virtio-iommu driver from above
> branch?
>
> Thanks
I am using git://linux-arm.org/linux-jpb.git branch virtio-iommu/v0.4.
Hope you are referring to the same.
>
> Eric
> >>>
> >>> - virtio-iommu device emulation by Eric Augur.
> >>>[RFC v4 00/16] VIRTIO-IOMMU device
> >>>https://github.com/eauger/qemu/tree/v2.10.0-virtio-iommu-v4
> >>>
> >>> Changes are available at : https://github.com/bharaty/qemu.git
> >>> virtio-iommu-vfio-integration-v4
> >>>
> >>
> >> # With the above sources, was trying to test the vfio-pci device assigned
> >> to
> >> guest using Qemu.
> >> # Both guest and host kernels are configured with 4k as page size.
> >> # releavant qemu command snippet,
> >> -device virtio-iommu-device -device virtio-blk-device,drive=hd0 \
> >> -net none -device vfio-pci,host=xxx
> >>
> >>
> >> On guest booting, observed mutliple messages as below,
> >>
> >> qemu-system-aarch64: iommu has granularity incompatible with target AS
> >>
> >> # On adding necessary prints, 0x5000 is len, 0x4fff is address mask
> >> and the code expects the address mask to be 0xfff.
> >
> > I have not seen these errors, I am also using 4K page-size on both host and
> > guest. Can you share compete qemu command and log.
> >
> > Thanks
> > -Bharat
> >
> >>
> >> if (len & iotlb->addr_mask) {
> >> error_report
> >>
> >> # vfio_dma_map is failing due to this error.
> >>
> >> Any pointers ?
> >>
> >>
> >>> v3->v4:
> >>> - Rebase to v4 version from Eric
> >>> - Fixes from Eric with DPDK in VM
> >>> - Logical division in multiple patches
> >>>
> >>> v2->v3:
> >>> - This series is based on "[RFC v3 0/8] VIRTIO-IOMMU device"
> >>>Which is based on top of v2.10-rc0 that
> >>> - Fixed issue with two PCI devices
> >>> - Addressed review comments
> >>>
> >>> v1->v2:
> >>> - Added trace events
> >>> - removed vSMMU3 link in patch description
> >>>
> >>> Bharat Bhushan (5):
> >>> target/arm/kvm: Translate the MSI doorbell in
> >> kvm_arch_fixup_msi_route
> >>> virtio-iommu: Add iommu notifier for map/unmap
> >>> virtio-iommu: Call iommu notifier for attach/detach
> >>> virtio-iommu: add iommu replay
> >>> virtio-iommu: add iommu notifier memory-region
> >>>
> >>> hw/virtio/trace-events | 5 ++
> >>> hw/virtio/virtio-iommu.c | 181
> >> ++-
> >>> include/hw/virtio/virtio-iommu.h | 6 ++
> >>> target/arm/kvm.c | 27 ++
> >>> target/arm/trace-events | 3 +
> >>> 5 files changed, 219 insertions(+), 3 deletions(-)
> >>>
> >>> --
> >>> 1.9.3
> >>>
> >>>
> >>
> >> --
> >> Linu cherian
--
Linu cherian
Re: [Qemu-devel] [Qemu-arm] [PATCH v4 0/5] virtio-iommu: VFIO integration
On Wed Sep 27, 2017 at 10:55:07AM +0200, Auger Eric wrote:
> Hi Linu,
>
> On 27/09/2017 10:30, Bharat Bhushan wrote:
> > Hi,
> >
> >> -Original Message-
> >> From: Linu Cherian [mailto:linuc.dec...@gmail.com]
> >> Sent: Wednesday, September 27, 2017 1:11 PM
> >> To: Bharat Bhushan <bharat.bhus...@nxp.com>
> >> Cc: eric.au...@redhat.com; eric.auger@gmail.com;
> >> peter.mayd...@linaro.org; alex.william...@redhat.com; m...@redhat.com;
> >> qemu-...@nongnu.org; qemu-devel@nongnu.org; kevin.t...@intel.com;
> >> marc.zyng...@arm.com; t...@semihalf.com; will.dea...@arm.com;
> >> drjo...@redhat.com; robin.mur...@arm.com; christoffer.d...@linaro.org;
> >> bharatb.ya...@gmail.com
> >> Subject: Re: [Qemu-arm] [PATCH v4 0/5] virtio-iommu: VFIO integration
> >>
> >> Hi,
> >>
> >> On Wed Sep 27, 2017 at 12:03:15PM +0530, Bharat Bhushan wrote:
> >>> This patch series integrates VFIO/VHOST with virtio-iommu.
> >>>
> >>> This version is mainly about rebasing on v4 version on virtio-iommu
> >>> device framework from Eric Augur and addresing review comments.
> >>>
> >>> This patch series allows PCI pass-through using virtio-iommu.
> >>>
> >>> This series is based on:
> >>> - virtio-iommu kernel driver by Jean-Philippe Brucker
> >>> [1] [RFC] virtio-iommu version 0.4
> >>> git://linux-arm.org/virtio-iommu.git branch viommu/v0.4
>
> Just to make sure, do you use the v0.4 virtio-iommu driver from above
> branch?
Yes, Eric i have that.
>From guest kernel,
0.00] Linux version 4.13.0-rc1-gd1949df
.
.
] virtio_iommu virtio0: aperture: 0x0-0x
[0.927886] virtio_iommu virtio0: page mask: 0x40201000
[0.931682] virtio_iommu virtio0: probe successful
Guest kernel source is on this commit,
commit d1949dfbf5c0d181b290625c28c5359284686e3a
Author: Jean-Philippe Brucker <jean-philippe.bruc...@arm.com>
Date: Mon Jul 17 19:01:07 2017 +0100
iommu/virtio-iommu: add MSI window probe
Using the probe request, extract RESV_MEM information. When we encounter a
MSI doorbell region, set it up as a IOMMU_RESV_MSI region. This will tell
other subsystems that there is no need to map the MSI doorbell in the
virtio-iommu, because MSIs bypass it.
Signed-off-by: Jean-Philippe Brucker <jean-philippe.bruc...@arm.com>
with CONFIG_VIRTIO_IOMMU=y in config.
>
> Thanks
>
> Eric
> >>>
> >>> - virtio-iommu device emulation by Eric Augur.
> >>>[RFC v4 00/16] VIRTIO-IOMMU device
> >>>https://github.com/eauger/qemu/tree/v2.10.0-virtio-iommu-v4
> >>>
> >>> Changes are available at : https://github.com/bharaty/qemu.git
> >>> virtio-iommu-vfio-integration-v4
> >>>
> >>
> >> # With the above sources, was trying to test the vfio-pci device assigned
> >> to
> >> guest using Qemu.
> >> # Both guest and host kernels are configured with 4k as page size.
> >> # releavant qemu command snippet,
> >> -device virtio-iommu-device -device virtio-blk-device,drive=hd0 \
> >> -net none -device vfio-pci,host=xxx
> >>
> >>
> >> On guest booting, observed mutliple messages as below,
> >>
> >> qemu-system-aarch64: iommu has granularity incompatible with target AS
> >>
> >> # On adding necessary prints, 0x5000 is len, 0x4fff is address mask
> >> and the code expects the address mask to be 0xfff.
> >
> > I have not seen these errors, I am also using 4K page-size on both host and
> > guest. Can you share compete qemu command and log.
> >
> > Thanks
> > -Bharat
> >
> >>
> >> if (len & iotlb->addr_mask) {
> >> error_report
> >>
> >> # vfio_dma_map is failing due to this error.
> >>
> >> Any pointers ?
> >>
> >>
> >>> v3->v4:
> >>> - Rebase to v4 version from Eric
> >>> - Fixes from Eric with DPDK in VM
> >>> - Logical division in multiple patches
> >>>
> >>> v2->v3:
> >>> - This series is based on "[RFC v3 0/8] VIRTIO-IOMMU device"
> >>>Which is based on top of v2.10-rc0 that
> >>> - Fixed issue with two PCI devices
> >>> - Addressed review comments
> >>>
> >>> v1->v2:
> >>> - Added trace events
> >>> - removed vSMMU3 link in patch description
> >>>
> >>> Bharat Bhushan (5):
> >>> target/arm/kvm: Translate the MSI doorbell in
> >> kvm_arch_fixup_msi_route
> >>> virtio-iommu: Add iommu notifier for map/unmap
> >>> virtio-iommu: Call iommu notifier for attach/detach
> >>> virtio-iommu: add iommu replay
> >>> virtio-iommu: add iommu notifier memory-region
> >>>
> >>> hw/virtio/trace-events | 5 ++
> >>> hw/virtio/virtio-iommu.c | 181
> >> ++-
> >>> include/hw/virtio/virtio-iommu.h | 6 ++
> >>> target/arm/kvm.c | 27 ++
> >>> target/arm/trace-events | 3 +
> >>> 5 files changed, 219 insertions(+), 3 deletions(-)
> >>>
> >>> --
> >>> 1.9.3
> >>>
> >>>
> >>
> >> --
> >> Linu cherian
--
Linu cherian
Re: [Qemu-devel] [Qemu-arm] [PATCH v4 0/5] virtio-iommu: VFIO integration
On Wed Sep 27, 2017 at 08:30:51AM +, Bharat Bhushan wrote:
> Hi,
>
> > -Original Message-
> > From: Linu Cherian [mailto:linuc.dec...@gmail.com]
> > Sent: Wednesday, September 27, 2017 1:11 PM
> > To: Bharat Bhushan <bharat.bhus...@nxp.com>
> > Cc: eric.au...@redhat.com; eric.auger@gmail.com;
> > peter.mayd...@linaro.org; alex.william...@redhat.com; m...@redhat.com;
> > qemu-...@nongnu.org; qemu-devel@nongnu.org; kevin.t...@intel.com;
> > marc.zyng...@arm.com; t...@semihalf.com; will.dea...@arm.com;
> > drjo...@redhat.com; robin.mur...@arm.com; christoffer.d...@linaro.org;
> > bharatb.ya...@gmail.com
> > Subject: Re: [Qemu-arm] [PATCH v4 0/5] virtio-iommu: VFIO integration
> >
> > Hi,
> >
> > On Wed Sep 27, 2017 at 12:03:15PM +0530, Bharat Bhushan wrote:
> > > This patch series integrates VFIO/VHOST with virtio-iommu.
> > >
> > > This version is mainly about rebasing on v4 version on virtio-iommu
> > > device framework from Eric Augur and addresing review comments.
> > >
> > > This patch series allows PCI pass-through using virtio-iommu.
> > >
> > > This series is based on:
> > > - virtio-iommu kernel driver by Jean-Philippe Brucker
> > > [1] [RFC] virtio-iommu version 0.4
> > > git://linux-arm.org/virtio-iommu.git branch viommu/v0.4
> > >
> > > - virtio-iommu device emulation by Eric Augur.
> > >[RFC v4 00/16] VIRTIO-IOMMU device
> > >https://github.com/eauger/qemu/tree/v2.10.0-virtio-iommu-v4
> > >
> > > Changes are available at : https://github.com/bharaty/qemu.git
> > > virtio-iommu-vfio-integration-v4
> > >
> >
> > # With the above sources, was trying to test the vfio-pci device assigned to
> > guest using Qemu.
> > # Both guest and host kernels are configured with 4k as page size.
> > # releavant qemu command snippet,
> > -device virtio-iommu-device -device virtio-blk-device,drive=hd0 \
> > -net none -device vfio-pci,host=xxx
> >
> >
> > On guest booting, observed mutliple messages as below,
> >
> > qemu-system-aarch64: iommu has granularity incompatible with target AS
> >
> > # On adding necessary prints, 0x5000 is len, 0x4fff is address mask
> > and the code expects the address mask to be 0xfff.
>
> I have not seen these errors, I am also using 4K page-size on both host and
> guest. Can you share compete qemu command and log.
Qemu cmd:
qemu-system-aarch64 -machine virt,gic_version=3 -cpu host -enable-kvm -nographic
-smp 8 -m 1024 -kernel /boot/Image --append "console=ttyAMA0 root=/dev/vda rw"
-drive if=none,file=/home/ubuntu/fs_images/ubu1604.img,id=hd0,format=raw
-device virtio-iommu-device -device virtio-blk-device,drive=hd0 -net none
-device vfio-pci,host=0002:01:00.3
Qemu log:
qemu-system-aarch64: iommu has granularity incompatible with target AS
qemu-system-aarch64: iommu has granularity incompatible with target AS
qemu-system-aarch64: iommu has granularity incompatible with target AS
qemu-system-aarch64: iommu has granularity incompatible with target AS
qemu-system-aarch64: iommu has granularity incompatible with target AS
qemu-system-aarch64: iommu has granularity incompatible with target AS
...
>
> Thanks
> -Bharat
>
> >
> > if (len & iotlb->addr_mask) {
> > error_report
> >
> > # vfio_dma_map is failing due to this error.
> >
> > Any pointers ?
> >
> >
> > > v3->v4:
> > > - Rebase to v4 version from Eric
> > > - Fixes from Eric with DPDK in VM
> > > - Logical division in multiple patches
> > >
> > > v2->v3:
> > > - This series is based on "[RFC v3 0/8] VIRTIO-IOMMU device"
> > >Which is based on top of v2.10-rc0 that
> > > - Fixed issue with two PCI devices
> > > - Addressed review comments
> > >
> > > v1->v2:
> > > - Added trace events
> > > - removed vSMMU3 link in patch description
> > >
> > > Bharat Bhushan (5):
> > > target/arm/kvm: Translate the MSI doorbell in
> > kvm_arch_fixup_msi_route
> > > virtio-iommu: Add iommu notifier for map/unmap
> > > virtio-iommu: Call iommu notifier for attach/detach
> > > virtio-iommu: add iommu replay
> > > virtio-iommu: add iommu notifier memory-region
> > >
> > > hw/virtio/trace-events | 5 ++
> > > hw/virtio/virtio-iommu.c | 181
> > ++-
> > > include/hw/virtio/virtio-iommu.h | 6 ++
> > > target/arm/kvm.c | 27 ++
> > > target/arm/trace-events | 3 +
> > > 5 files changed, 219 insertions(+), 3 deletions(-)
> > >
> > > --
> > > 1.9.3
> > >
> > >
> >
> > --
> > Linu cherian
--
Linu cherian
Re: [Qemu-devel] [Qemu-arm] [PATCH v4 0/5] virtio-iommu: VFIO integration
Hi,
On Wed Sep 27, 2017 at 12:03:15PM +0530, Bharat Bhushan wrote:
> This patch series integrates VFIO/VHOST with virtio-iommu.
>
> This version is mainly about rebasing on v4 version on
> virtio-iommu device framework from Eric Augur and
> addresing review comments.
>
> This patch series allows PCI pass-through using virtio-iommu.
>
> This series is based on:
> - virtio-iommu kernel driver by Jean-Philippe Brucker
> [1] [RFC] virtio-iommu version 0.4
> git://linux-arm.org/virtio-iommu.git branch viommu/v0.4
>
> - virtio-iommu device emulation by Eric Augur.
>[RFC v4 00/16] VIRTIO-IOMMU device
>https://github.com/eauger/qemu/tree/v2.10.0-virtio-iommu-v4
>
> Changes are available at : https://github.com/bharaty/qemu.git
> virtio-iommu-vfio-integration-v4
>
# With the above sources, was trying to test the vfio-pci device assigned to
guest using Qemu.
# Both guest and host kernels are configured with 4k as page size.
# releavant qemu command snippet,
-device virtio-iommu-device -device virtio-blk-device,drive=hd0 \
-net none -device vfio-pci,host=xxx
On guest booting, observed mutliple messages as below,
qemu-system-aarch64: iommu has granularity incompatible with target AS
# On adding necessary prints, 0x5000 is len, 0x4fff is address mask
and the code expects the address mask to be 0xfff.
if (len & iotlb->addr_mask) {
error_report
# vfio_dma_map is failing due to this error.
Any pointers ?
> v3->v4:
> - Rebase to v4 version from Eric
> - Fixes from Eric with DPDK in VM
> - Logical division in multiple patches
>
> v2->v3:
> - This series is based on "[RFC v3 0/8] VIRTIO-IOMMU device"
>Which is based on top of v2.10-rc0 that
> - Fixed issue with two PCI devices
> - Addressed review comments
>
> v1->v2:
> - Added trace events
> - removed vSMMU3 link in patch description
>
> Bharat Bhushan (5):
> target/arm/kvm: Translate the MSI doorbell in kvm_arch_fixup_msi_route
> virtio-iommu: Add iommu notifier for map/unmap
> virtio-iommu: Call iommu notifier for attach/detach
> virtio-iommu: add iommu replay
> virtio-iommu: add iommu notifier memory-region
>
> hw/virtio/trace-events | 5 ++
> hw/virtio/virtio-iommu.c | 181
> ++-
> include/hw/virtio/virtio-iommu.h | 6 ++
> target/arm/kvm.c | 27 ++
> target/arm/trace-events | 3 +
> 5 files changed, 219 insertions(+), 3 deletions(-)
>
> --
> 1.9.3
>
>
--
Linu cherian
Re: [Qemu-devel] [Qemu-arm] [PATCH v7 13/20] hw/arm/smmuv3: Implement IOMMU memory region replay callback
Hi Eric,
On Fri Sep 01, 2017 at 07:21:16PM +0200, Eric Auger wrote:
> memory_region_iommu_replay() is used for VFIO integration.
>
> However its default implementation is not adapted to SMMUv3
> IOMMU memory region. Indeed the input address range is too
> huge and its execution is too slow as it calls the translate()
> callback on each granule.
>
> Let's implement the replay callback which hierarchically walk
> over the page table structure and notify only the segments
> that are populated with valid entries.
>
> Signed-off-by: Eric Auger <eric.au...@redhat.com>
> ---
> hw/arm/smmuv3.c | 36
> hw/arm/trace-events | 1 +
> 2 files changed, 37 insertions(+)
>
> diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
> index 8e7d10d..c43bd93 100644
> --- a/hw/arm/smmuv3.c
> +++ b/hw/arm/smmuv3.c
> @@ -657,6 +657,41 @@ static int smmuv3_notify_entry(IOMMUTLBEntry *entry,
> void *private)
> return 0;
> }
>
> +/* Unmap the whole notifier's range */
> +static void smmuv3_unmap_notifier_range(IOMMUNotifier *n)
> +{
> +IOMMUTLBEntry entry;
> +hwaddr size = n->end - n->start + 1;
> +
> +entry.target_as = _space_memory;
> +entry.iova = n->start & ~(size - 1);
> +entry.perm = IOMMU_NONE;
> +entry.addr_mask = size - 1;
> +
> +memory_region_notify_one(n, );
> +}
> +
> +static void smmuv3_replay(IOMMUMemoryRegion *mr, IOMMUNotifier *n)
> +{
> +SMMUTransCfg cfg = {};
> +int ret;
> +
> +trace_smmuv3_replay(mr->parent_obj.name, n, n->start, n->end);
> +smmuv3_unmap_notifier_range(n);
> +
> +ret = smmuv3_decode_config(mr, );
> +if (ret) {
> +error_report("%s error decoding the configuration for iommu mr=%s",
> + __func__, mr->parent_obj.name);
> +}
>
On an invalid config being found, shouldnt we return rather than proceeding with
page table walk. For example on an invalid Stream table entry.
+
> +if (cfg.disabled || cfg.bypassed) {
> +return;
> +}
> +/* walk the page tables and replay valid entries */
> +smmu_page_walk(, 0, (1ULL << (64 - cfg.tsz)) - 1, false,
> + smmuv3_notify_entry, n);
> +}
> static void smmuv3_notify_iova_range(IOMMUMemoryRegion *mr, IOMMUNotifier *n,
> uint64_t iova, size_t size)
> {
> @@ -1095,6 +1130,7 @@ static void
> smmuv3_iommu_memory_region_class_init(ObjectClass *klass,
>
> imrc->translate = smmuv3_translate;
> imrc->notify_flag_changed = smmuv3_notify_flag_changed;
> +imrc->replay = smmuv3_replay;
> }
>
> static const TypeInfo smmuv3_type_info = {
> diff --git a/hw/arm/trace-events b/hw/arm/trace-events
> index 4ac264d..15f84d6 100644
> --- a/hw/arm/trace-events
> +++ b/hw/arm/trace-events
> @@ -46,5 +46,6 @@ smmuv3_cfg_stage(int s, uint32_t oas, uint32_t tsz,
> uint64_t ttbr, bool aa64, ui
> smmuv3_notify_flag_add(const char *iommu) "ADD SMMUNotifier node for iommu
> mr=%s"
> smmuv3_notify_flag_del(const char *iommu) "DEL SMMUNotifier node for iommu
> mr=%s"
> smmuv3_replay_mr(const char *name) "iommu mr=%s"
> +smmuv3_replay(const char *name, void *n, hwaddr start, hwaddr end) "iommu
> mr=%s notifier=%p [0x%"PRIx64",0x%"PRIx64"]"
> smmuv3_notify_entry(hwaddr iova, hwaddr pa, hwaddr mask, int perm)
> "iova=0x%"PRIx64" pa=0x%" PRIx64" mask=0x%"PRIx64" perm=%d"
> smmuv3_notify_iova_range(const char *name, uint64_t iova, size_t size, void
> *n) "iommu mr=%s iova=0x%"PRIx64" size=0x%lx n=%p"
> --
> 2.5.5
>
>
--
Linu cherian
Re: [Qemu-devel] [Qemu-arm] [PATCH v7 00/20] ARM SMMUv3 Emulation Support
- single point bug fix > - sharing/removal in future > - (optional) Unit tests added, with PCI test device > - S1 with 4k/64k, S1+S2 with 4k/64k > - (S1 or S2) only can be verified by Linux 4.7 driver > - (optional) Priliminary ACPI support > > v0 [Prem]: > - Implements SMMUv3 spec 11.0 > - Supported for PCIe devices, > - Command Queue and Event Queue supported > - LPAE only, S1 is supported and Tested, S2 not tested > - BE mode Translation not supported > - IRQ support (legacy, no MSI) > > Eric Auger (18): > hw/arm/smmu-common: smmu base device and datatypes > hw/arm/smmu-common: IOMMU memory region and address space setup > hw/arm/smmu-common: smmu_read/write_sysmem > hw/arm/smmu-common: VMSAv8-64 page table walk > hw/arm/smmuv3: Wired IRQ and GERROR helpers > hw/arm/smmuv3: Queue helpers > hw/arm/smmuv3: Implement MMIO write operations > hw/arm/smmuv3: Event queue recording helper > hw/arm/smmuv3: Implement translate callback > target/arm/kvm: Translate the MSI doorbell in kvm_arch_fixup_msi_route > hw/arm/smmuv3: Implement data structure and TLB invalidation > notifications > hw/arm/smmuv3: Implement IOMMU memory region replay callback > hw/arm/virt: Store the PCI host controller dt phandle > hw/arm/sysbus-fdt: Pass the VirtMachineState to the node creation > functions > hw/arm/sysbus-fdt: Pass the platform bus base address in > PlatformBusFDTData > hw/arm/sysbus-fdt: Allow smmuv3 dynamic instantiation > hw/arm/smmuv3: [not for upstream] add SMMU_CMD_TLBI_NH_VA_AM handling > hw/arm/smmuv3: [not for upstream] Add caching-mode option > > Prem Mallappa (2): > hw/arm/smmuv3: Skeleton > hw/arm/virt-acpi-build: Add smmuv3 node in IORT table > > default-configs/aarch64-softmmu.mak |1 + > hw/arm/Makefile.objs|1 + > hw/arm/smmu-common.c| 527 > hw/arm/smmu-internal.h | 105 > hw/arm/smmuv3-internal.h| 584 + > hw/arm/smmuv3.c | 1181 > +++ > hw/arm/sysbus-fdt.c | 129 +++- > hw/arm/trace-events | 48 ++ > hw/arm/virt-acpi-build.c| 63 +- > hw/arm/virt.c |6 +- > include/hw/acpi/acpi-defs.h | 15 + > include/hw/arm/smmu-common.h| 123 > include/hw/arm/smmuv3.h | 80 +++ > include/hw/arm/sysbus-fdt.h |2 + > include/hw/arm/virt.h | 15 + > target/arm/kvm.c| 27 + > target/arm/trace-events |3 + > 17 files changed, 2886 insertions(+), 24 deletions(-) > create mode 100644 hw/arm/smmu-common.c > create mode 100644 hw/arm/smmu-internal.h > create mode 100644 hw/arm/smmuv3-internal.h > create mode 100644 hw/arm/smmuv3.c > create mode 100644 include/hw/arm/smmu-common.h > create mode 100644 include/hw/arm/smmuv3.h > > -- > 2.5.5 > > -- Linu cherian
Re: [Qemu-devel] [Qemu-arm] [PATCH v7 05/20] hw/arm/smmuv3: Skeleton
On Fri Sep 08, 2017 at 05:18:19PM +0200, Auger Eric wrote: > Hi Linu, > > On 08/09/2017 12:52, Linu Cherian wrote: > > Hi Eric, > > > > On Fri Sep 01, 2017 at 07:21:08PM +0200, Eric Auger wrote: > >> From: Prem Mallappa <prem.malla...@broadcom.com> > >> > >> This patch implements a skeleton for the smmuv3 device. > >> Datatypes and register definitions are introduced. The MMIO > >> region, the interrupts and the queue are initialized (PRI is > >> not supported). > >> > >> Only the MMIO read operation is implemented here. > >> > >> Signed-off-by: Prem Mallappa <prem.malla...@broadcom.com> > >> Signed-off-by: Eric Auger <eric.au...@redhat.com> > >> > >> --- > >> v6 -> v7: > >> - split into several patches > >> > >> v5 -> v6: > >> - Use IOMMUMemoryregion > >> - regs become uint32_t and fix 64b MMIO access (.impl) > >> - trace_smmuv3_write/read_mmio take the size param > >> > >> v4 -> v5: > >> - change smmuv3_translate proto (IOMMUAccessFlags flag) > >> - has_stagex replaced by is_ste_stagex > >> - smmu_cfg_populate removed > >> - added smmuv3_decode_config and reworked error management > >> - remwork the naming of IOMMU mrs > >> - fix SMMU_CMDQ_CONS offset > >> > >> v3 -> v4 > >> - smmu_irq_update > >> - fix hash key allocation > >> - set smmu_iommu_ops > >> - set SMMU_REG_CR0, > >> - smmuv3_translate: ret.perm not set in bypass mode > >> - use trace events > >> - renamed STM2U64 into L1STD_L2PTR and STMSPAN into L1STD_SPAN > >> - rework smmu_find_ste > >> - fix tg2granule in TT0/0b10 corresponds to 16kB > >> > >> v2 -> v3: > >> - move creation of include/hw/arm/smmuv3.h to this patch to fix compil > >> issue > >> - compilation allowed > >> - fix sbus allocation in smmu_init_pci_iommu > >> - restructure code into headers > >> - misc cleanups > >> --- > >> hw/arm/Makefile.objs | 2 +- > >> hw/arm/smmuv3-internal.h | 201 +++ > >> hw/arm/smmuv3.c | 239 > >> +++ > >> hw/arm/trace-events | 3 + > >> include/hw/arm/smmuv3.h | 79 > >> 5 files changed, 523 insertions(+), 1 deletion(-) > >> create mode 100644 hw/arm/smmuv3-internal.h > >> create mode 100644 hw/arm/smmuv3.c > >> create mode 100644 include/hw/arm/smmuv3.h > >> > >> diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs > >> index 5b2d38d..a7c808b 100644 > >> --- a/hw/arm/Makefile.objs > >> +++ b/hw/arm/Makefile.objs > >> @@ -19,4 +19,4 @@ obj-$(CONFIG_FSL_IMX31) += fsl-imx31.o kzm.o > >> obj-$(CONFIG_FSL_IMX6) += fsl-imx6.o sabrelite.o > >> obj-$(CONFIG_ASPEED_SOC) += aspeed_soc.o aspeed.o > >> obj-$(CONFIG_MPS2) += mps2.o > >> -obj-$(CONFIG_ARM_SMMUV3) += smmu-common.o > >> +obj-$(CONFIG_ARM_SMMUV3) += smmu-common.o smmuv3.o > >> diff --git a/hw/arm/smmuv3-internal.h b/hw/arm/smmuv3-internal.h > >> new file mode 100644 > >> index 000..488acc8 > >> --- /dev/null > >> +++ b/hw/arm/smmuv3-internal.h > >> @@ -0,0 +1,201 @@ > >> +/* > >> + * ARM SMMUv3 support - Internal API > >> + * > >> + * Copyright (C) 2014-2016 Broadcom Corporation > >> + * Copyright (c) 2017 Red Hat, Inc. > >> + * Written by Prem Mallappa, Eric Auger > >> + * > >> + * This program is free software; you can redistribute it and/or modify > >> + * it under the terms of the GNU General Public License as published by > >> + * the Free Software Foundation, either version 2 of the License, or > >> + * (at your option) any later version. > >> + * > >> + * This program is distributed in the hope that it will be useful, > >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of > >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > >> + * GNU General Public License for more details. > >> + * > >> + * You should have received a copy of the GNU General Public License along > >> + * with this program; if not, see <http://www.gnu.org/licenses/>. > >> + */ > >> + > >> +#ifndef HW_ARM_SMMU_V3_INTERNAL_H > >> +#define HW_ARM_SMMU_V3_INTERNAL_H > >> + > >> +#include "trace.h&qu
Re: [Qemu-devel] [Qemu-arm] [PATCH v7 05/20] hw/arm/smmuv3: Skeleton
= 0x%"PRIx64
> +
> +#hw/arm/smmuv3.c
> +smmuv3_read_mmio(hwaddr addr, uint64_t val, unsigned size) "addr:
> 0x%"PRIx64" val:0x%"PRIx64" size: 0x%x"
> diff --git a/include/hw/arm/smmuv3.h b/include/hw/arm/smmuv3.h
> new file mode 100644
> index 000..0c8973d
> --- /dev/null
> +++ b/include/hw/arm/smmuv3.h
> @@ -0,0 +1,79 @@
> +/*
> + * Copyright (C) 2014-2016 Broadcom Corporation
> + * Copyright (c) 2017 Red Hat, Inc.
> + * Written by Prem Mallappa, Eric Auger
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation, either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef HW_ARM_SMMUV3_H
> +#define HW_ARM_SMMUV3_H
> +
> +#include "hw/arm/smmu-common.h"
> +
> +#define TYPE_SMMUV3_IOMMU_MEMORY_REGION "smmuv3-iommu-memory-region"
> +
> +#define SMMU_NREGS0x200
> +
> +typedef struct SMMUQueue {
> + hwaddr base;
> + uint32_t prod;
> + uint32_t cons;
> + union {
> + struct {
> + uint8_t prod:1;
> + uint8_t cons:1;
> + };
> + uint8_t unused;
> + } wrap;
> +
> + uint16_t entries; /* Number of entries */
> + uint8_t ent_size; /* Size of entry in bytes */
> + uint8_t shift; /* Size in log2 */
> +} SMMUQueue;
> +
> +typedef struct SMMUV3State {
> +SMMUState smmu_state;
> +
> +/* Local cache of most-frequently used registers */
> +#define SMMU_FEATURE_2LVL_STE (1 << 0)
> +uint32_t features;
> +uint16_t sid_size;
> +uint16_t sid_split;
> +uint64_t strtab_base;
> +
> +uint32_tregs[SMMU_NREGS];
> +
> +qemu_irq irq[4];
> +SMMUQueuecmdq, evtq;
> +
> +} SMMUV3State;
> +
> +typedef enum {
> +SMMU_IRQ_EVTQ,
> +SMMU_IRQ_PRIQ,
> +SMMU_IRQ_CMD_SYNC,
> +SMMU_IRQ_GERROR,
> +} SMMUIrq;
> +
> +typedef struct {
> +SMMUBaseClass smmu_base_class;
> +} SMMUV3Class;
> +
> +#define TYPE_SMMU_V3_DEV "smmuv3"
> +#define SMMU_V3_DEV(obj) OBJECT_CHECK(SMMUV3State, (obj), TYPE_SMMU_V3_DEV)
> +#define SMMU_V3_DEVICE_GET_CLASS(obj) \
> +OBJECT_GET_CLASS(SMMUBaseClass, (obj), TYPE_SMMU_V3_DEV)
> +
> +#endif
> --
> 2.5.5
>
>
--
Linu cherian
Re: [Qemu-devel] [Qemu-arm] [PATCH v3 0/2] virtio-iommu: VFIO integration
Hi, On Mon Aug 21, 2017 at 04:18:52PM +0530, Bharat Bhushan wrote: > This V3 version is mainly about rebasing on v3 version on Virtio-iommu device > framework from Eric Augur and addresing review comments. > > This patch series allows PCI pass-through using virtio-iommu. > > This series is based on: > - virtio-iommu specification written by Jean-Philippe Brucker >[RFC 0/3] virtio-iommu: a paravirtualized IOMMU, > > - virtio-iommu driver by Jean-Philippe Brucker >[RFC PATCH linux] iommu: Add virtio-iommu driver > > - virtio-iommu device emulation by Eric Augur. >[RFC v3 0/8] VIRTIO-IOMMU device > > PCI device pass-through and virtio-net-pci is tested with these changes using > dma-ops > Facing issues while trying to test with VFIO. vfio_dma_map fails as below, qemu-system-aarch64: vfio_dma_map(0x1ff0da0, 0xfdfc7000, 0x1000, 0x79acc000) = -22 (Invalid argument) Very likely this seem to be an issue with map size. Kernel PAGE_SIZE is 64k on my host and hence the map size for the physical SMMU also will start with 64k. Qemu source: https://github.com/eauger/qemu.git + this patch series on branch v2.10.0-rc0-virtio-iommu-rfcv3 Linux source: git://linux-arm.org/linux-jpb.git on branch virtio-iommu/v0.1 Any pointers ? The other related questions i had, 1. In, virtio_iommu_device_realize in qemu, s->config.page_sizes = TARGET_PAGE_MASK; Same is being taken as pgsize_bitmap in virtio_iommu guest kernel driver. In, viommu_probe virtio_cread(vdev, struct virtio_iommu_config, page_sizes, >pgsize_bitmap); Should s->config.page_sizes be initialized with page bitmap instead of page mask ? 2. Should we not populate the supported page sizes based on host kernel size and SMMU hardware capability rather than based on the machine emulated on qemu? Atleast that makes sense for VFIO case. > This patch series does not implement RESV_MEM changes proposal by > Jean-Philippe > "https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg01796.html; > > v2->v3: > - This series is based on "[RFC v3 0/8] VIRTIO-IOMMU device" >Which is based on top of v2.10-rc0 that > - Fixed issue with two PCI devices > - Addressed review comments > > v1->v2: > - Added trace events > - removed vSMMU3 link in patch description > > Bharat Bhushan (2): > target/arm/kvm: Translate the MSI doorbell in kvm_arch_fixup_msi_route > virtio-iommu: vfio integration with virtio-iommu > > hw/virtio/trace-events | 5 ++ > hw/virtio/virtio-iommu.c | 163 > +++ > include/hw/virtio/virtio-iommu.h | 6 ++ > target/arm/kvm.c | 27 +++ > target/arm/trace-events | 3 + > 5 files changed, 204 insertions(+) > > -- > 1.9.3 > > -- Linu cherian
Re: [Qemu-devel] [Qemu-arm] [RFC v6 8/9] hw/arm/smmuv3: VFIO integration
dev) {
> +if (new == IOMMU_NOTIFIER_NONE) {
> +trace_smmuv3_notify_flag_del(iommu->parent_obj.name);
> +QLIST_REMOVE(node, next);
> +g_free(node);
> +}
> +return;
> +}
> +}
> +}
>
> static inline void smmu_update_base_reg(SMMUV3State *s, uint64_t *base,
> uint64_t val)
> @@ -1125,6 +1382,8 @@ static void
> smmuv3_iommu_memory_region_class_init(ObjectClass *klass,
> IOMMUMemoryRegionClass *imrc = IOMMU_MEMORY_REGION_CLASS(klass);
>
> imrc->translate = smmuv3_translate;
> +imrc->notify_flag_changed = smmuv3_notify_flag_changed;
> +imrc->replay = smmuv3_replay;
> }
>
> static const TypeInfo smmuv3_type_info = {
> diff --git a/hw/arm/trace-events b/hw/arm/trace-events
> index f9b9cbe..8228e26 100644
> --- a/hw/arm/trace-events
> +++ b/hw/arm/trace-events
> @@ -27,6 +27,7 @@ smmuv3_cmdq_opcode(const char *opcode) "<--- %s"
> smmuv3_cmdq_cfgi_ste(int streamid) " |_ streamid =%d"
> smmuv3_cmdq_cfgi_ste_range(int start, int end) " |_ start=0x%d -
> end=0x%d"
> smmuv3_cmdq_tlbi_nh_va(int asid, int vmid, uint64_t addr) " |_ asid =%d
> vmid =%d addr=0x%"PRIx64
> +smmuv3_cmdq_tlbi_nh_va_am(int asid, int am, size_t size, uint64_t addr) "
> |_ asid =%d am =%d size=0x%lx addr=0x%"PRIx64
> smmuv3_cmdq_consume_sev(void) "CMD_SYNC CS=SEV not supported, ignoring"
> smmuv3_cmdq_consume_out(uint8_t prod_wrap, uint32_t prod, uint8_t cons_wrap,
> uint32_t cons) "prod_wrap:%d, prod:0x%x cons_wrap:%d cons:0x%x"
> smmuv3_update(bool is_empty, uint32_t prod, uint32_t cons, uint8_t
> prod_wrap, uint8_t cons_wrap) "q empty:%d prod:%d cons:%d p.wrap:%d p.cons:%d"
> @@ -50,3 +51,16 @@ smmuv3_dump_ste(int i, uint32_t word0, int j, uint32_t
> word1) "STE[%2d]: 0x%x\t
> smmuv3_dump_cd(int i, uint32_t word0, int j, uint32_t word1) "CD[%2d]:
> 0x%x\t CD[%2d]: 0x%x"
> smmuv3_dump_cmd(int i, uint32_t word0, int j, uint32_t word1) "CMD[%2d]:
> 0x%x\t CMD[%2d]: 0x%x"
> smmuv3_cfg_stage(int s, uint32_t oas, uint32_t tsz, uint64_t ttbr, bool
> aa64, uint32_t granule_sz, int initial_level) "TransCFG stage:%d oas:%d
> tsz:%d ttbr:0x%"PRIx64" aa64:%d granule_sz:%d, initial_level = %d"
> +
> +smmuv3_replay(uint16_t sid, bool enabled) "sid=%d, enabled=%d"
> +smmuv3_replay_hook(hwaddr iova, hwaddr pa, hwaddr mask, int perm)
> "iova=0x%"PRIx64" pa=0x%" PRIx64" mask=0x%"PRIx64" perm=%d"
> +smmuv3_map_hook(hwaddr iova, hwaddr pa, hwaddr mask, int perm)
> "iova=0x%"PRIx64" pa=0x%" PRIx64" mask=0x%"PRIx64" perm=%d"
> +smmuv3_notify_flag_add(const char *iommu) "ADD SMMUNotifier node for iommu
> mr=%s"
> +smmuv3_notify_flag_del(const char *iommu) "DEL SMMUNotifier node for iommu
> mr=%s"
> +smmuv3_replay_single(const char *name, uint64_t iova, void *n) "iommu mr=%s
> iova=0x%"PRIx64" n=%p"
> +smmuv3_replay_range(const char *name, uint64_t iova, size_t size, void *n)
> "iommu mr=%s iova=0x%"PRIx64" size=0x%lx n=%p"
> +smmuv3_replay_all(const char *name) "iommu mr=%s"
> +smmuv3_notify_all(const char *name, uint64_t iova) "iommu mr=%s
> iova=0x%"PRIx64
> +smmuv3_unmap_notifier(uint8_t bus, uint8_t slot, uint8_t fn, uint64_t iova,
> uint64_t size) "Device %02x:%02x.%x start 0x%"PRIx64" size 0x%"PRIx64
> +smmuv3_context_device_invalidate(uint32_t sid) "sid=%d"
> +
> --
> 2.5.5
>
>
--
Linu cherian
Re: [Qemu-devel] [Qemu-arm] [RFC v6 8/9] hw/arm/smmuv3: VFIO integration
; > smmuv3_cmdq_cfgi_ste(int streamid) " |_ streamid =%d" > smmuv3_cmdq_cfgi_ste_range(int start, int end) " |_ start=0x%d - > end=0x%d" > smmuv3_cmdq_tlbi_nh_va(int asid, int vmid, uint64_t addr) " |_ asid =%d > vmid =%d addr=0x%"PRIx64 > +smmuv3_cmdq_tlbi_nh_va_am(int asid, int am, size_t size, uint64_t addr) " > |_ asid =%d am =%d size=0x%lx addr=0x%"PRIx64 > smmuv3_cmdq_consume_sev(void) "CMD_SYNC CS=SEV not supported, ignoring" > smmuv3_cmdq_consume_out(uint8_t prod_wrap, uint32_t prod, uint8_t cons_wrap, > uint32_t cons) "prod_wrap:%d, prod:0x%x cons_wrap:%d cons:0x%x" > smmuv3_update(bool is_empty, uint32_t prod, uint32_t cons, uint8_t > prod_wrap, uint8_t cons_wrap) "q empty:%d prod:%d cons:%d p.wrap:%d p.cons:%d" > @@ -50,3 +51,16 @@ smmuv3_dump_ste(int i, uint32_t word0, int j, uint32_t > word1) "STE[%2d]: 0x%x\t > smmuv3_dump_cd(int i, uint32_t word0, int j, uint32_t word1) "CD[%2d]: > 0x%x\t CD[%2d]: 0x%x" > smmuv3_dump_cmd(int i, uint32_t word0, int j, uint32_t word1) "CMD[%2d]: > 0x%x\t CMD[%2d]: 0x%x" > smmuv3_cfg_stage(int s, uint32_t oas, uint32_t tsz, uint64_t ttbr, bool > aa64, uint32_t granule_sz, int initial_level) "TransCFG stage:%d oas:%d > tsz:%d ttbr:0x%"PRIx64" aa64:%d granule_sz:%d, initial_level = %d" > + > +smmuv3_replay(uint16_t sid, bool enabled) "sid=%d, enabled=%d" > +smmuv3_replay_hook(hwaddr iova, hwaddr pa, hwaddr mask, int perm) > "iova=0x%"PRIx64" pa=0x%" PRIx64" mask=0x%"PRIx64" perm=%d" > +smmuv3_map_hook(hwaddr iova, hwaddr pa, hwaddr mask, int perm) > "iova=0x%"PRIx64" pa=0x%" PRIx64" mask=0x%"PRIx64" perm=%d" > +smmuv3_notify_flag_add(const char *iommu) "ADD SMMUNotifier node for iommu > mr=%s" > +smmuv3_notify_flag_del(const char *iommu) "DEL SMMUNotifier node for iommu > mr=%s" > +smmuv3_replay_single(const char *name, uint64_t iova, void *n) "iommu mr=%s > iova=0x%"PRIx64" n=%p" > +smmuv3_replay_range(const char *name, uint64_t iova, size_t size, void *n) > "iommu mr=%s iova=0x%"PRIx64" size=0x%lx n=%p" > +smmuv3_replay_all(const char *name) "iommu mr=%s" > +smmuv3_notify_all(const char *name, uint64_t iova) "iommu mr=%s > iova=0x%"PRIx64 > +smmuv3_unmap_notifier(uint8_t bus, uint8_t slot, uint8_t fn, uint64_t iova, > uint64_t size) "Device %02x:%02x.%x start 0x%"PRIx64" size 0x%"PRIx64 > +smmuv3_context_device_invalidate(uint32_t sid) "sid=%d" > + > -- > 2.5.5 > > -- Linu cherian
Re: [Qemu-devel] [Qemu-arm] [RFC v3 0/8] VIRTIO-IOMMU device
On Thu Aug 17, 2017 at 05:26:53PM +0200, Auger Eric wrote: > Hi Linu, Jean, > > On 17/08/2017 15:39, Jean-Philippe Brucker wrote: > > Hi Linu, > > > > On 17/08/17 12:26, Linu Cherian wrote: > >> Hi Eric, > >> > >> On Tue Aug 01, 2017 at 11:33:06AM +0200, Eric Auger wrote: > >>> This series implements the virtio-iommu device. > >>> > >>> This v3 mostly is a rebase on top of v2.10-rc0 that uses > >>> IOMMUMmeoryRegion plus some small fixes. > >>> > >>> This is a proof of concept based on the virtio-iommu specification > >>> written by Jean-Philippe Brucker [1]. > >>> > >>> The device gets instantiated using the "-device virtio-iommu-device" > >>> option. It currently works with ARM virt machine only, as the machine > >>> must handle the dt binding between the virtio-mmio "iommu" node and > >>> the PCI host bridge node. > >>> > >>> ACPI booting is not yet supported. > >>> > >>> Best Regards > >>> > >>> Eric > >>> > >>> This series can be found at: > >>> https://github.com/eauger/qemu/tree/v2.10.0-rc0-virtio-iommu-rfcv3 > >>> > >>> References: > >>> [1] [RFC 0/3] virtio-iommu: a paravirtualized IOMMU, > >>> [2] [RFC PATCH linux] iommu: Add virtio-iommu driver > >>> [3] [RFC PATCH kvmtool 00/15] Add virtio-iommu > >>> > >>> Testing: > >>> - >= 4.12 guest kernel + virtio-iommu driver [2] > >>> - guest using a virtio-net-pci device: > >>> ,vhost=off,iommu_platform,disable-modern=off,disable-legacy=on > >> > >> Was trying to test this out and facing issues. > >> Guest and Host Kernel - git://linux-arm.org/linux-jpb.git, Branch > >> virtio-iommu/v0.4 > >> Qemu - As mentioned above. > > > > Could you try branch virtio-iommu/v0.1? It contains the UAPI headers > > compatible with this RFC. > Thank you Jean. Yes the QEMU virtio-iommu device is based on the first > user API written in [2]. I plan to rebase on v0.4 in short delay. Jean > can I rebase on virtio-iommu/v0.4 or shall I wait a bit more? > > Thanks Yes, virtio-iommu/v0.1 works for me. Thanks. > > Eric > > > > Thanks, > > Jean > > -- Linu cherian
Re: [Qemu-devel] [Qemu-arm] [RFC v3 0/8] VIRTIO-IOMMU device
ommu spec revision. > > v1 -> v2: > - fix redifinition of viommu_as typedef > > > Eric Auger (8): > update-linux-headers: import virtio_iommu.h > linux-headers: Update for virtio-iommu > virtio_iommu: add skeleton > virtio-iommu: Decode the command payload > virtio_iommu: Add the iommu regions > virtio-iommu: Implement the translation and commands > hw/arm/virt: Add 2.10 machine type > hw/arm/virt: Add virtio-iommu the virt board > > hw/arm/virt.c | 116 - > hw/virtio/Makefile.objs | 1 + > hw/virtio/trace-events| 14 + > hw/virtio/virtio-iommu.c | 670 > ++ > include/hw/arm/virt.h | 5 + > include/hw/virtio/virtio-iommu.h | 61 +++ > include/standard-headers/linux/virtio_ids.h | 1 + > include/standard-headers/linux/virtio_iommu.h | 142 ++ > linux-headers/linux/virtio_iommu.h| 1 + > scripts/update-linux-headers.sh | 3 + > 10 files changed, 1005 insertions(+), 9 deletions(-) > create mode 100644 hw/virtio/virtio-iommu.c > create mode 100644 include/hw/virtio/virtio-iommu.h > create mode 100644 include/standard-headers/linux/virtio_iommu.h > create mode 100644 linux-headers/linux/virtio_iommu.h > > -- > 2.5.5 > > -- Linu cherian
