diff for duplicates of <1454017899.23148.0.camel@redhat.com>

diff --git a/a/1.txt b/N1/1.txt
index c7a17c6..7c66ecb 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -2,24 +2,24 @@ On Tue, 2016-01-26 at 13:12 +0000, Eric Auger wrote:
 > This series addresses KVM PCIe passthrough with MSI enabled on ARM/ARM64.
 > It pursues the efforts done on [1], [2], [3]. It also aims at covering the
 > same need on some PowerPC platforms.
-> 
+>?
 > On x86 all accesses to the 1MB PA region [FEE0_0000h - FEF0_000h] are directed
 > as interrupt messages: accesses to this special PA window directly target the
 > APIC configuration space and not DRAM, meaning the downstream IOMMU is bypassed.
-> 
+>?
 > This is not the case on above mentionned platforms where MSI messages emitted
 > by devices are conveyed through the IOMMU. This means an IOVA/host PA mapping
 > must exist for the MSI to reach the MSI controller. Normal way to create
 > IOVA bindings consists in using VFIO DMA MAP API. However in this case
 > the MSI IOVA is not mapped onto guest RAM but on host physical page (the MSI
 > controller frame).
-> 
+>?
 > Following first comments, the spirit of [2] is kept: the guest registers
 > an IOVA range reserved for MSI mapping. When the VFIO-PCIe driver allocates
 > its MSI vectors, it overwrites the MSI controller physical address with an IOVA,
 > allocated within the window provided by the userspace. This IOVA is mapped
 > onto the MSI controller frame physical page.
-> 
+>?
 > The series does not address yet the problematic of telling the userspace how
 > much IOVA he should provision.
 
@@ -30,36 +30,31 @@ fixups of the physical vector ourselves, implying ugly (no offense)
 paths bouncing through vfio to connect the driver and iommu backends?
 
 We know that x86 handles MSI vectors specially, so there is some
-hardware that helps the situation.  It's not just that x86 has a fixed
+hardware that helps the situation.??It's not just that x86 has a fixed
 range for MSI, it's how it manages that range when interrupt remapping
-hardware is enabled.  A device table indexed by source-ID references a
-per device table indexed by data from the MSI write itself.  So we get
+hardware is enabled.??A device table indexed by source-ID references a
+per device table indexed by data from the MSI write itself.??So we get
 much, much finer granularity, but there's still effectively an interrupt
 domain per device that's being transparently managed under the covers
 whenever we request an MSI vector for a device.
 
-So why can't we do something more like that here?  There's no predefined
+So why can't we do something more like that here???There's no predefined
 MSI vector range, so defining an interface for the user to specify that
-is unavoidable.  But why shouldn't everything else be transparent?  We
+is unavoidable.??But why shouldn't everything else be transparent???We
 could add an interface to the IOMMU API that allows us to register that
-reserved range for the IOMMU domain.  IOMMU-core (or maybe interrupt
+reserved range for the IOMMU domain.??IOMMU-core (or maybe interrupt
 remapping) code might allocate an IOVA domain for this just as you've
-done in the type1 code here.  But rather than having any interaction
+done in the type1 code here.??But rather than having any interaction
 with vfio-pci, why not do this at lower levels such that the platform
 interrupt vector allocation code automatically uses one of those IOVA
 ranges and returns the IOVA rather than the physical address for the PCI
-code to program into the device?  I think we know what needs to be done,
+code to program into the device???I think we know what needs to be done,
 but we're taking the approach of managing the space ourselves and doing
 a fixup of the device after the core code has done its job when we
 really ought to be letting the core code manage a space that we define
 and programming the device so that it doesn't need a fixup in the
-vfio-pci code.  Wouldn't it be nicer if pci_enable_msix_range() returned
+vfio-pci code.??Wouldn't it be nicer if pci_enable_msix_range() returned
 with the device properly programmed or generate an error if there's not
-enough reserved mapping space in IOMMU domain?  Can it be done?  Thanks,
+enough reserved mapping space in IOMMU domain?  Can it be done???Thanks,
 
 Alex
-
-_______________________________________________
-iommu mailing list
-iommu@lists.linux-foundation.org
-https://lists.linuxfoundation.org/mailman/listinfo/iommu
diff --git a/a/content_digest b/N1/content_digest
index 66468a8..0a300c7 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -1,45 +1,32 @@
  "ref\01453813968-2024-1-git-send-email-eric.auger@linaro.org\0"
- "ref\01453813968-2024-1-git-send-email-eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org\0"
- "From\0Alex Williamson <alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>\0"
- "Subject\0Re: [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64\0"
+ "From\0alex.williamson@redhat.com (Alex Williamson)\0"
+ "Subject\0[PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64\0"
  "Date\0Thu, 28 Jan 2016 14:51:39 -0700\0"
- "To\0Eric Auger <eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>"
-  eric.auger-qxv4g6HH51o@public.gmane.org
-  will.deacon-5wv7dgnIgG8@public.gmane.org
-  christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
-  marc.zyngier-5wv7dgnIgG8@public.gmane.org
-  linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
-  kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org
- " kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org\0"
- "Cc\0patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
-  p.fedin-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org
-  linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
- " pranav.sawargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org\0"
+ "To\0linux-arm-kernel@lists.infradead.org\0"
  "\00:1\0"
  "b\0"
  "On Tue, 2016-01-26 at 13:12 +0000, Eric Auger wrote:\n"
  "> This series addresses KVM PCIe passthrough with MSI enabled on ARM/ARM64.\n"
  "> It pursues the efforts done on [1], [2], [3]. It also aims at covering the\n"
  "> same need on some PowerPC platforms.\n"
- ">\302\240\n"
+ ">?\n"
  "> On x86 all accesses to the 1MB PA region [FEE0_0000h - FEF0_000h] are directed\n"
  "> as interrupt messages: accesses to this special PA window directly target the\n"
  "> APIC configuration space and not DRAM, meaning the downstream IOMMU is bypassed.\n"
- ">\302\240\n"
+ ">?\n"
  "> This is not the case on above mentionned platforms where MSI messages emitted\n"
  "> by devices are conveyed through the IOMMU. This means an IOVA/host PA mapping\n"
  "> must exist for the MSI to reach the MSI controller. Normal way to create\n"
  "> IOVA bindings consists in using VFIO DMA MAP API. However in this case\n"
  "> the MSI IOVA is not mapped onto guest RAM but on host physical page (the MSI\n"
  "> controller frame).\n"
- ">\302\240\n"
+ ">?\n"
  "> Following first comments, the spirit of [2] is kept: the guest registers\n"
  "> an IOVA range reserved for MSI mapping. When the VFIO-PCIe driver allocates\n"
  "> its MSI vectors, it overwrites the MSI controller physical address with an IOVA,\n"
  "> allocated within the window provided by the userspace. This IOVA is mapped\n"
  "> onto the MSI controller frame physical page.\n"
- ">\302\240\n"
+ ">?\n"
  "> The series does not address yet the problematic of telling the userspace how\n"
  "> much IOVA he should provision.\n"
  "\n"
@@ -50,38 +37,33 @@
  "paths bouncing through vfio to connect the driver and iommu backends?\n"
  "\n"
  "We know that x86 handles MSI vectors specially, so there is some\n"
- "hardware that helps the situation.\302\240\302\240It's not just that x86 has a fixed\n"
+ "hardware that helps the situation.??It's not just that x86 has a fixed\n"
  "range for MSI, it's how it manages that range when interrupt remapping\n"
- "hardware is enabled.\302\240\302\240A device table indexed by source-ID references a\n"
- "per device table indexed by data from the MSI write itself.\302\240\302\240So we get\n"
+ "hardware is enabled.??A device table indexed by source-ID references a\n"
+ "per device table indexed by data from the MSI write itself.??So we get\n"
  "much, much finer granularity, but there's still effectively an interrupt\n"
  "domain per device that's being transparently managed under the covers\n"
  "whenever we request an MSI vector for a device.\n"
  "\n"
- "So why can't we do something more like that here?\302\240\302\240There's no predefined\n"
+ "So why can't we do something more like that here???There's no predefined\n"
  "MSI vector range, so defining an interface for the user to specify that\n"
- "is unavoidable.\302\240\302\240But why shouldn't everything else be transparent?\302\240\302\240We\n"
+ "is unavoidable.??But why shouldn't everything else be transparent???We\n"
  "could add an interface to the IOMMU API that allows us to register that\n"
- "reserved range for the IOMMU domain.\302\240\302\240IOMMU-core (or maybe interrupt\n"
+ "reserved range for the IOMMU domain.??IOMMU-core (or maybe interrupt\n"
  "remapping) code might allocate an IOVA domain for this just as you've\n"
- "done in the type1 code here.\302\240\302\240But rather than having any interaction\n"
+ "done in the type1 code here.??But rather than having any interaction\n"
  "with vfio-pci, why not do this at lower levels such that the platform\n"
  "interrupt vector allocation code automatically uses one of those IOVA\n"
  "ranges and returns the IOVA rather than the physical address for the PCI\n"
- "code to program into the device?\302\240\302\240I think we know what needs to be done,\n"
+ "code to program into the device???I think we know what needs to be done,\n"
  "but we're taking the approach of managing the space ourselves and doing\n"
  "a fixup of the device after the core code has done its job when we\n"
  "really ought to be letting the core code manage a space that we define\n"
  "and programming the device so that it doesn't need a fixup in the\n"
- "vfio-pci code.\302\240\302\240Wouldn't it be nicer if pci_enable_msix_range() returned\n"
+ "vfio-pci code.??Wouldn't it be nicer if pci_enable_msix_range() returned\n"
  "with the device properly programmed or generate an error if there's not\n"
- "enough reserved mapping space in IOMMU domain?  Can it be done?\302\240\302\240Thanks,\n"
+ "enough reserved mapping space in IOMMU domain?  Can it be done???Thanks,\n"
  "\n"
- "Alex\n"
- "\n"
- "_______________________________________________\n"
- "iommu mailing list\n"
- "iommu@lists.linux-foundation.org\n"
- https://lists.linuxfoundation.org/mailman/listinfo/iommu
+ Alex
 
-f3e52d465cb197a4589ed08d45cbde9cfd1bc736fcd4bec14fadc6a31319ffe5
+1e88ded038647e4c5fd0a76f7189ed74471ded5a5ae468852e8bf874dd6600b6
