Hi James,
On 2/22/19 2:38 PM, James Dong wrote:
Tried this patch, and the same DMAR fault message came out.
Guess it is because of the iommu code path for hotplug devices. If a hotplug
device is rescanned after removal, iommu_bus_notifier will be called as part
of the notifier chains to handle
Baolu:
Sorry that my last reply email seems not text format. Resend it now.
Thanks for your comments and your patch. Please find below our responses to
each of your comments:
> What does "I/O operation won't work" exactly mean here? Do you see any
> IOMMU fault message? Or, something doesn't wor
Baolu:
Thanks for your comments and your patch. Please find below our responses to
each of your comments:
> What does "I/O operation won't work" exactly mean here? Do you see any
> IOMMU fault message? Or, something doesn't work as expected?
Yes, DMAR fault messages as following came out:
[ 354
Hi
On 2/22/19 1:06 PM, Lu Baolu wrote:
Do you mind checking this?
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 6ecdcf8fc8c0..f62f30bc1339 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2632,6 +2632,9 @@ static struct dmar_domain
Hi,
On 2/22/19 10:44 AM, James Dong wrote:
With specific Linux command line option such as "iommu=pt", some types
of hotplug devices will be assigned to the static 1:1 iommu domain by
default during kernel init.
If such a hotplug device is rescanned after being removed, for example,
with follow
With specific Linux command line option such as "iommu=pt", some types
of hotplug devices will be assigned to the static 1:1 iommu domain by
default during kernel init.
If such a hotplug device is rescanned after being removed, for example,
with following sample commands:
echo 1 > /sys/bus/pci/d
This adds helpers to attach or detach a domain to a
group. This will replace iommu_attach_group() which
only works for non-mdev devices.
If a domain is attaching to a group which includes the
mediated devices, it should attach to the iommu device
(a pci device which represents the mdev in iommu sc
This adds support to return the default pasid associated with
an auxiliary domain. The PCI device which is bound with this
domain should use this value as the pasid for all DMA requests
of the subset of device which is isolated and protected with
this domain.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevi
When multiple domains per device has been enabled by the
device driver, the device will tag the default PASID for
the domain to all DMA traffics out of the subset of this
device; and the IOMMU should translate the DMA requests
in PASID granularity.
This adds the intel_iommu_aux_attach/detach_devic
This adds the support to determine the isolation type
of a mediated device group by checking whether it has
an iommu device. If an iommu device exists, an iommu
domain will be allocated and then attached to the iommu
device. Otherwise, keep the same behavior as it is.
Cc: Ashok Raj
Cc: Jacob Pan
A parent device might create different types of mediated
devices. For example, a mediated device could be created
by the parent device with full isolation and protection
provided by the IOMMU. One usage case could be found on
Intel platforms where a mediated device is an assignable
subset of a PCI,
This adds the iommu ops entries for aux-domain per-device
feature query and enable/disable.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by: Sanjay Kumar
Signed-off-by: Liu Yi L
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 159
incl
Sharing a physical PCI device in a finer-granularity way
is becoming a consensus in the industry. IOMMU vendors
are also engaging efforts to support such sharing as well
as possible. Among the efforts, the capability of support
finer-granularity DMA isolation is a common requirement
due to the secu
This moves intel_iommu_enable_pasid() out of the scope of
CONFIG_INTEL_IOMMU_SVM with more and more features requiring
pasid function.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 22 +++---
drivers/iommu/intel-svm.c |
Hi,
The Mediate Device is a framework for fine-grained physical device
sharing across the isolated domains. Currently the mdev framework
is designed to be independent of the platform IOMMU support. As the
result, the DMA isolation relies on the mdev parent device in a
vendor specific way.
There a
This part of code could be used by both normal and aux
domain specific attach entries. Hence move them into a
common function to avoid duplication.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 60 ++---
1
On 02/21/19 at 06:13pm, Borislav Petkov wrote:
> On Wed, Feb 20, 2019 at 05:41:46PM +0800, Dave Young wrote:
> > Previously Joerg posted below patch, maybe he has some idea. Joerg?
>
> Isn't it clear from the commit message?
Then, does it answered your question?
256M is set as a default value in
Hi,
On 2/15/19 4:14 AM, Alex Williamson wrote:
On Wed, 13 Feb 2019 12:02:52 +0800
Lu Baolu wrote:
Hi,
The Mediate Device is a framework for fine-grained physical device
sharing across the isolated domains. Currently the mdev framework
is designed to be independent of the platform IOMMU suppo
Hello Jean-Philippe,
Jean-Philippe Brucker writes:
> Makes sense, though I think other virtio devices have been developed a
> little more organically: device and driver code got upstreamed first,
> and then the specification describing their interface got merged into
> the standard. For example
Michael S. Tsirkin writes:
> On Mon, Jan 21, 2019 at 11:29:05AM +, Jean-Philippe Brucker wrote:
>> Hi,
>>
>> On 18/01/2019 15:51, Michael S. Tsirkin wrote:
>> >
>> > On Tue, Jan 15, 2019 at 12:19:52PM +, Jean-Philippe Brucker wrote:
>> >> Implement the virtio-iommu driver, following spe
From: lantianyu1...@gmail.com Sent: Monday, February
11, 2019 6:20 AM
> + /*
> + * Hyper-V doesn't provide irq remapping function for
> + * IO-APIC and so IO-APIC only accepts 8-bit APIC ID.
> + * Cpu's APIC ID is read from ACPI MADT table and APIC IDs
> + * in the MADT ta
On Wed, Feb 20, 2019 at 05:41:46PM +0800, Dave Young wrote:
> Previously Joerg posted below patch, maybe he has some idea. Joerg?
Isn't it clear from the commit message?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
__
From: lantianyu1...@gmail.com Sent: Monday, February
11, 2019 6:20 AM
>
> Hyper-V doesn't provide irq remapping for IO-APIC. To enable x2apic,
> set x2apic destination mode to physcial mode when x2apic is available
> and Hyper-V IOMMU driver makes sure cpus assigned with IO-APIC irqs have
> 8-bi
On 2/20/19 7:05 AM, Geert Uytterhoeven wrote:
> A change made in the final version of IOMMU debugfs support replaced the
> public function iommu_debugfs_new_driver_dir() by the public dentry
> iommu_debugfs_dir in , but forgot to update both the
> implementation in iommu-debugfs.c, and the patch de
Hi Bjorn,
Please help to review this patch series.
Thank you.
Regards,
Srinath.
On Fri, Jan 25, 2019 at 3:44 PM Srinath Mannam
wrote:
>
> Few SOCs have limitation that their PCIe host can't allow few inbound
> address ranges. Allowed inbound address ranges are listed in dma-ranges
> DT property
25 matches
Mail list logo
