On 2016/6/21 9:50, Bjorn Helgaas wrote:
On Thu, Jun 02, 2016 at 01:46:49PM +0800, Yongji Xie wrote:
Now we use the IORESOURCE_STARTALIGN to identify bridge resources
in __assign_resources_sorted(). That's quite fragile. We can't
make sure that the PCI devices' resourc
On 2016/6/21 9:57, Bjorn Helgaas wrote:
On Thu, Jun 02, 2016 at 01:46:50PM +0800, Yongji Xie wrote:
When using resource_alignment kernel parameter, the current
implement reassigns the alignment by changing resources' size
which can potentially break some drivers. For example, the driver
On 2016/6/21 9:43, Bjorn Helgaas wrote:
On Thu, Jun 02, 2016 at 01:46:48PM +0800, Yongji Xie wrote:
The resource_alignment will releases memory resources allocated
by firmware so that kernel can reassign new resources later on.
But this will cause the problem that no resources can be
allocated
On 2016/6/21 10:26, Bjorn Helgaas wrote:
On Thu, Jun 02, 2016 at 01:46:51PM +0800, Yongji Xie wrote:
When vfio passthrough a PCI device of which MMIO BARs are
smaller than PAGE_SIZE, guest will not handle the mmio
accesses to the BARs which leads to mmio emulations in host.
This is because
On 2016/6/21 10:16, Yongji Xie wrote:
On 2016/6/21 9:43, Bjorn Helgaas wrote:
On Thu, Jun 02, 2016 at 01:46:48PM +0800, Yongji Xie wrote:
The resource_alignment will releases memory resources allocated
by firmware so that kernel can reassign new resources later on.
But this will cause the
From: Xie Yongji
Our system encountered a problem recently, the khungtaskd detected
some process hang on mmap_sem. But the odd thing was that one task which
is not on mmap_sem.wait_list still sleeps in rwsem_down_read_failed().
Through code inspection, we found a potential bug can lead to this.
On Thu, 29 Nov 2018 at 21:45, Peter Zijlstra wrote:
>
> On Thu, Nov 29, 2018 at 02:12:32PM +0100, Peter Zijlstra wrote:
> >
> > +Cc davidlohr and waiman
>
> > Urgh; so the case where the cmpxchg() fails because it already has a
> > wakeup in progress, which then 'violates' our expectation of when
On Mon, 17 Dec 2018 at 19:37, Peter Zijlstra wrote:
>
> On Mon, Dec 10, 2018 at 11:12:52PM +0800, Yongji Xie wrote:
> > Hi Peter,
> >
> > Please let me know If there is any progress on this issue. Thank you!
>
> Right, sorry, my brain was filled with snot and didn&#x
On Fri, 30 Nov 2018 at 06:17, Peter Zijlstra wrote:
>
> On Thu, Nov 29, 2018 at 01:34:21PM -0800, Davidlohr Bueso wrote:
> > I messed up something such that waiman was not in the thread. Ccing.
> >
> > > On Thu, 29 Nov 2018, Waiman Long wrote:
> > >
> > > > That can be costly for x86 which will no
On Tue, Jan 9, 2024 at 7:10 PM Maxime Coquelin
wrote:
>
> Virtio-net driver control queue implementation is not safe
> when used with VDUSE. If the VDUSE application does not
> reply to control queue messages, it currently ends up
> hanging the kernel thread sending this command.
>
> Some work is
On Tue, Jan 9, 2024 at 7:10 PM Maxime Coquelin
wrote:
>
> This patch adds Virtio-net device type to the supported
> devices types.
>
> Initialization fails if the device does not support
> VIRTIO_F_VERSION_1 feature, in order to guarantee the
> configuration space is read-only. It also fails with
On Mon, Aug 5, 2024 at 4:24 PM Jason Wang wrote:
>
> On Mon, Aug 5, 2024 at 4:21 PM Jason Wang wrote:
> >
> > Barry said [1]:
> >
> > """
> > mm doesn't support non-blockable __GFP_NOFAIL allocation. Because
> > __GFP_NOFAIL without direct reclamation may just result in a busy
> > loop within non
On Tue, Aug 6, 2024 at 10:28 AM Jason Wang wrote:
>
> On Mon, Aug 5, 2024 at 6:42 PM Yongji Xie wrote:
> >
> > On Mon, Aug 5, 2024 at 4:24 PM Jason Wang wrote:
> > >
> > > On Mon, Aug 5, 2024 at 4:21 PM Jason Wang wrote:
> > > >
> > >
On Wed, Aug 7, 2024 at 10:39 AM Jason Wang wrote:
>
> On Tue, Aug 6, 2024 at 11:10 AM Yongji Xie wrote:
> >
> > On Tue, Aug 6, 2024 at 10:28 AM Jason Wang wrote:
> > >
> > > On Mon, Aug 5, 2024 at 6:42 PM Yongji Xie wrote:
> > > >
> >
On Mon, Aug 5, 2024 at 4:21 PM Jason Wang wrote:
>
> Barry said [1]:
>
> """
> mm doesn't support non-blockable __GFP_NOFAIL allocation. Because
> __GFP_NOFAIL without direct reclamation may just result in a busy
> loop within non-sleepable contexts.
> ""“
>
> Unfortuantely, we do that under read
On Wed, Aug 7, 2024 at 12:38 PM Jason Wang wrote:
>
> On Wed, Aug 7, 2024 at 11:13 AM Yongji Xie wrote:
> >
> > On Wed, Aug 7, 2024 at 10:39 AM Jason Wang wrote:
> > >
> > > On Tue, Aug 6, 2024 at 11:10 AM Yongji Xie
> > > wrote:
> > >
On Thu, Aug 8, 2024 at 10:58 AM Jason Wang wrote:
>
> On Wed, Aug 7, 2024 at 2:52 PM Yongji Xie wrote:
> >
> > On Mon, Aug 5, 2024 at 4:21 PM Jason Wang wrote:
> > >
> > > Barry said [1]:
> > >
> > > """
> > > mm doe
On Thu, Aug 8, 2024 at 1:50 PM Jason Wang wrote:
>
> On Wed, Aug 7, 2024 at 2:54 PM Yongji Xie wrote:
> >
> > On Wed, Aug 7, 2024 at 12:38 PM Jason Wang wrote:
> > >
> > > On Wed, Aug 7, 2024 at 11:13 AM Yongji Xie
> > > wrote:
> > > >
On Mon, Aug 12, 2024 at 3:00 PM Jason Wang wrote:
>
> On Thu, Aug 8, 2024 at 6:52 PM Yongji Xie wrote:
> >
> > On Thu, Aug 8, 2024 at 10:58 AM Jason Wang wrote:
> > >
> > > On Wed, Aug 7, 2024 at 2:52 PM Yongji Xie wrote:
> > > >
> >
Hi David and Kevin,
On 2016/5/5 17:54, David Laight wrote:
From: Tian, Kevin
Sent: 05 May 2016 10:37
...
Acutually, we are not aimed at accessing MSI-X table from
guest. So I think it's safe to passthrough MSI-X table if we
can make sure guest kernel would not touch MSI-X table in
normal cod
On 2016/5/5 17:36, Tian, Kevin wrote:
From: Yongji Xie
Sent: Tuesday, May 03, 2016 3:34 PM
On 2016/5/3 14:22, Tian, Kevin wrote:
From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com]
Sent: Tuesday, May 03, 2016 2:08 PM
On 2016/5/3 13:34, Tian, Kevin wrote:
From: Yongji Xie
Sent: Wednesday
On 2016/5/5 20:15, Tian, Kevin wrote:
From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com]
Sent: Thursday, May 05, 2016 7:43 PM
Hi David and Kevin,
On 2016/5/5 17:54, David Laight wrote:
From: Tian, Kevin
Sent: 05 May 2016 10:37
...
Acutually, we are not aimed at accessing MSI-X table
On 2016/5/3 10:59, Tian, Kevin wrote:
From: Yongji Xie
Sent: Wednesday, April 27, 2016 8:22 PM
Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio
page may be shared with other BARs. This will cause some
performance issues
On 2016/5/3 13:34, Tian, Kevin wrote:
From: Yongji Xie
Sent: Wednesday, April 27, 2016 8:43 PM
This patch enables mmapping MSI-X tables if hardware supports
interrupt remapping which can ensure that a given pci device
can only shoot the MSIs assigned for it.
With MSI-X table mmapped, we also
On 2016/5/3 14:22, Tian, Kevin wrote:
From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com]
Sent: Tuesday, May 03, 2016 2:08 PM
On 2016/5/3 13:34, Tian, Kevin wrote:
From: Yongji Xie
Sent: Wednesday, April 27, 2016 8:43 PM
This patch enables mmapping MSI-X tables if hardware supports
On 2016/5/3 14:11, Tian, Kevin wrote:
From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com]
Sent: Tuesday, May 03, 2016 1:52 PM
+
+ if (!(res->start & ~PAGE_MASK)) {
+ /*
+* Add shadow resource for sub-page bar who
esources to reserve the remaind of the page which
hot-add device's BAR might be assigned into.
Signed-off-by: Yongji Xie
---
drivers/vfio/pci/vfio_pci.c | 85 ---
drivers/vfio/pci/vfio_pci_private.h |8
2 files changed, 86 insertions(+)
On 2016/5/11 23:10, Bjorn Helgaas wrote:
On Wed, May 11, 2016 at 07:34:19PM +0800, Yongji Xie wrote:
Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio
page may be shared with other BARs. This will cause some
performance iss
e BAR. And
it's hard to access this BAR in userspace because we have
no way to get the BAR's location in a page.
Signed-off-by: Yongji Xie
---
drivers/vfio/pci/vfio_pci.c | 70 +++
drivers/vfio/pci/vfio_pci_private.h |8
2 files chang
On 2016/5/20 6:33, Alex Williamson wrote:
On Thu, 12 May 2016 18:20:51 +0800
Yongji Xie wrote:
Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio
page may be shared with other BARs. This will cause some
performance issues
On 2016/5/23 23:20, Alex Williamson wrote:
On Mon, 23 May 2016 11:45:34 +0800
Yongji Xie wrote:
On 2016/5/20 6:33, Alex Williamson wrote:
On Thu, 12 May 2016 18:20:51 +0800
Yongji Xie wrote:
Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs beca
On 2016/5/25 4:55, Bjorn Helgaas wrote:
On Wed, Apr 27, 2016 at 08:43:26PM +0800, Yongji Xie wrote:
We introduce a new pci_bus_flags, PCI_BUS_FLAGS_MSI_REMAP
which indicates all devices on the bus are protected by the
hardware which supports IRQ remapping(intel naming).
This changelog is
On 2016/5/25 5:04, Bjorn Helgaas wrote:
On Wed, Apr 27, 2016 at 08:43:28PM +0800, Yongji Xie wrote:
On ARM HW the capability of IRQ remapping is abstracted on
MSI controller side. MSI_FLAG_IRQ_REMAPPING is used to advertise
this [1].
To have a universal flag to test this capability for
On 2016/5/25 5:11, Bjorn Helgaas wrote:
On Wed, Apr 27, 2016 at 08:43:27PM +0800, Yongji Xie wrote:
The capability of IRQ remapping is abstracted on IOMMU side on
some archs. There is a existing flag IOMMU_CAP_INTR_REMAP for this.
To have a universal flag to test this capability for different
On 2016/4/27 0:40, Alex Williamson wrote:
On Mon, 25 Apr 2016 18:05:53 +0800
Yongji Xie wrote:
Hi Alex,
Any comment?
TBH, I shuffled this to the bottom of the review pile because you're
depending on a patch series for ARM MSI mapping that's still very much
in flux. You've
use firmware
setup and not to reassign any resources.
To solve this problem, this patch ignores resource_alignment
if PCI_PROBE_ONLY was set.
Signed-off-by: Yongji Xie
---
drivers/pci/pci.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index
ption "noresize" for the parameter to
solve this problem.
Signed-off-by: Yongji Xie
---
Documentation/kernel-parameters.txt |5 -
drivers/pci/pci.c | 35 +--
2 files changed, 29 insertions(+), 11 deletions(-)
diff --git a/Docum
to enforce the
alignment of all MMIO BARs to be at least PAGE_SIZE so that
one BAR's mmio page would not be shared with other BARs.
And we also define a macro PCIBIOS_MIN_ALIGNMENT to enable this
automatically on PPC64 platform which can easily hit this issue
because its PAGE_SIZE is 64KB.
S
PCI BARs; patch 4
modified resource_alignment to support syntax which can be used to
enforce the alignment of all MMIO BARs to be at least PAGE_SIZE.
Yongji Xie (4):
PCI: Ignore resource_alignment if PCI_PROBE_ONLY was set
PCI: Do not Use IORESOURCE_STARTALIGN to identify bridge resources
PCI: A
ridge resources.
Signed-off-by: Yongji Xie
---
drivers/pci/setup-bus.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 55641a3..216ddbc 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -390,6 +
shadow resource to reserve the remaind of the page which hot-add
device's BAR might be assigned into.
Signed-off-by: Yongji Xie
---
drivers/vfio/pci/vfio_pci.c | 58 ++-
drivers/vfio/pci/vfio_pci_private.h |8 +
2 files changed, 59 insertions(+)
.
Signed-off-by: Yongji Xie
---
drivers/iommu/iommu.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 0e3b009..5d2b6f6 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -813,6 +813,16 @@ struct iommu_group
Any IODA host bridge have the capability of IRQ remapping.
So we set PCI_BUS_FLAGS_MSI_REMAP when this kind of host birdge
is detected.
Signed-off-by: Yongji Xie
---
arch/powerpc/platforms/powernv/pci-ioda.c |8
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/platforms
we introduce a new bus_flags
PCI_BUS_FLAGS_MSI_REMAP to test this capability on PCI side
for different archs.
The patch 3 are based on the proposed patchset[1].
[1] http://www.spinics.net/lists/kvm/msg130256.html
Yongji Xie (5):
PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag
iommu: Set
: Yongji Xie
---
drivers/vfio/pci/vfio_pci.c |7 +--
drivers/vfio/pci/vfio_pci_rdwr.c |3 ++-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 98059df..7eba77d 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b
.
[1] http://www.spinics.net/lists/kvm/msg130256.html
Signed-off-by: Yongji Xie
---
drivers/pci/msi.c | 12
drivers/pci/probe.c |3 +++
include/linux/msi.h |6 +-
3 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index
ists/kvm/msg130256.html
Signed-off-by: Yongji Xie
---
include/linux/pci.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 27df4a6..d619228 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -193,6 +193,7 @@ typedef unsigned short _
On 2015/12/17 4:04, Alex Williamson wrote:
On Fri, 2015-12-11 at 16:53 +0800, Yongji Xie wrote:
Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio page
may be shared with other BARs.
But we should allow to mmap these sub-p
On 2015/12/17 4:14, Alex Williamson wrote:
On Fri, 2015-12-11 at 16:53 +0800, Yongji Xie wrote:
Current vfio-pci implementation disallows to mmap MSI-X table in
case that user get to touch this directly.
However, EEH mechanism could ensure that a given pci device
can only shoot the MSIs
On 2015/12/18 5:46, Alex Williamson wrote:
On Thu, 2015-12-17 at 18:26 +0800, yongji xie wrote:
On 2015/12/17 4:04, Alex Williamson wrote:
On Fri, 2015-12-11 at 16:53 +0800, Yongji Xie wrote:
Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs beca
AGE_SIZE.
Signed-off-by: Yongji Xie
---
drivers/vfio/pci/vfio_pci.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 7e9f497..09b3805 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@
because its PAGE_SIZE is 64KB.
Signed-off-by: Yongji Xie
---
Documentation/kernel-parameters.txt |4
arch/powerpc/include/asm/pci.h | 11 +++
drivers/pci/pci.c | 17 +
drivers/pci/pci.h |7 ++-
include/linux/pci.h
64 arch code.
- Remove flags: VFIO_DEVICE_FLAGS_PCI_PAGE_ALIGNED
VFIO_DEVICE_FLAGS_PCI_MSIX_MMAP
- Add a Kconfig option to support for mmapping MSI-X table.
[1] https://lkml.org/lkml/2015/11/23/748
Yongji Xie (3):
PCI: Add support for enforcing all MMIO BARs to be page aligned
vfio-pci: Allow to mmap sub-pag
upport for mmapping MSI-X table.
Signed-off-by: Yongji Xie
---
drivers/vfio/pci/Kconfig|4
drivers/vfio/pci/vfio_pci.c |6 --
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig
index 02912f1..67b0a2c 100644
---
On 2016/1/5 4:47, Alex Williamson wrote:
On Thu, 2015-12-31 at 16:50 +0800, Yongji Xie wrote:
When vfio passthrough a PCI device of which MMIO BARs
are smaller than PAGE_SIZE, guest will not handle the
mmio accesses to the BARs which leads to mmio emulations
in host.
This is because vfio will
n(vma, pfn, PAGE_ALIGN(size));
...
}
Here we can easily find the pfn is changed but not recovered
before untrack_pfn() is called. That's incorrect.
Signed-off-by: Yongji Xie
---
mm/memory.c |1 +
1 file changed, 1 insertion(+)
diff --git a/mm/memory.c b/mm/memory.c
index 0
On 2016/3/10 10:19, Alexey Kardashevskiy wrote:
On 03/07/2016 06:48 PM, Yongji Xie wrote:
When using resource_alignment kernel parameter, the current
implement reassigns the alignment by changing resources' size
which can potentially break some drivers.
How can this possibly break any d
Ping.
On 2016/3/7 15:48, Yongji Xie wrote:
Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs and MSI-X table. This is because
sub-page BARs' mmio page may be shared with other BARs and MSI-X table
should not be accessed directly from the guest for
On 2016/3/17 0:30, Alex Williamson wrote:
On Mon, 7 Mar 2016 15:48:36 +0800
Yongji Xie wrote:
Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio
page may be shared with other BARs.
But we should allow to mmap these sub-p
On 2016/3/16 22:10, Bjorn Helgaas wrote:
On Wed, Mar 16, 2016 at 06:51:56PM +0800, Yongji Xie wrote:
Ping.
This is mainly VFIO stuff, and Alex had some security concerns, so I'm
not going to spend much time looking at this until he's satisfied.
When I do, I'll be look
On 2016/3/17 20:40, Alex Williamson wrote:
On Thu, 17 Mar 2016 19:28:34 +0800
Yongji Xie wrote:
On 2016/3/17 0:30, Alex Williamson wrote:
On Mon, 7 Mar 2016 15:48:35 +0800
Yongji Xie wrote:
When vfio passthrough a PCI device of which MMIO BARs
are smaller than PAGE_SIZE, guest will not
On 2016/3/17 0:31, Alex Williamson wrote:
[cc+ Eric, Will]
On Mon, 7 Mar 2016 15:48:37 +0800
Yongji Xie wrote:
Current vfio-pci implementation disallows to mmap MSI-X
table in case that user get to touch this directly.
But we should allow to mmap these MSI-X tables if IOMMU
supports
On 2016/3/17 0:30, Alex Williamson wrote:
On Mon, 7 Mar 2016 15:48:35 +0800
Yongji Xie wrote:
When vfio passthrough a PCI device of which MMIO BARs
are smaller than PAGE_SIZE, guest will not handle the
mmio accesses to the BARs which leads to mmio emulations
in host.
This is because vfio
On 2016/3/17 0:32, Alex Williamson wrote:
On Mon, 7 Mar 2016 15:48:38 +0800
Yongji Xie wrote:
This patch adds IOMMU_CAP_INTR_REMAP for IODA host bridge so that
we can mmap MSI-X table in vfio driver.
Signed-off-by: Yongji Xie
---
arch/powerpc/platforms/powernv/pci-ioda.c | 17
On 2016/4/6 22:45, Alex Williamson wrote:
On Tue, 5 Apr 2016 21:46:44 +0800
Yongji Xie wrote:
This patch enables mmapping MSI-X tables if
hardware supports interrupt remapping which
can ensure that a given pci device can only
shoot the MSIs assigned for it.
Signed-off-by: Yongji Xie
Hi Eric,
On 2016/4/7 22:23, Eric Auger wrote:
Hi Yongji,
On 04/07/2016 01:38 PM, Yongji Xie wrote:
On 2016/4/6 22:45, Alex Williamson wrote:
On Tue, 5 Apr 2016 21:46:44 +0800
Yongji Xie wrote:
This patch enables mmapping MSI-X tables if
hardware supports interrupt remapping which
can
Hi Eric,
On 2016/4/8 17:10, Eric Auger wrote:
Hi Yongji,
On 04/08/2016 10:14 AM, Yongji Xie wrote:
Hi Eric,
On 2016/4/7 22:23, Eric Auger wrote:
Hi Yongji,
On 04/07/2016 01:38 PM, Yongji Xie wrote:
On 2016/4/6 22:45, Alex Williamson wrote:
On Tue, 5 Apr 2016 21:46:44 +0800
Yongji Xie wrote
stead of doing it on PPC64 arch code.
- Remove flags: VFIO_DEVICE_FLAGS_PCI_PAGE_ALIGNED
VFIO_DEVICE_FLAGS_PCI_MSIX_MMAP
- Add a Kconfig option to support for mmapping MSI-X table.
[1] http://www.spinics.net/lists/kvm/msg127812.html
Yongji Xie (7):
PCI: Ignore resource_alignment if PCI_PROBE_ONLY was set
PCI: D
use firmware setup and not to
reassign any resources.
To solve this problem, this patch ignores
resource_alignment if PCI_PROBE_ONLY was set.
Signed-off-by: Yongji Xie
---
drivers/pci/pci.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index
ridge resources.
Signed-off-by: Yongji Xie
---
drivers/pci/setup-bus.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 7796d0a..bffcf1e 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -391,6 +
lignment of all MMIO BARs to be at
least PAGE_SIZE so that one BAR's mmio page would
not be shared with other BARs.
And we also define a macro PCIBIOS_MIN_ALIGNMENT
to enable this automatically on PPC64 platform
which can easily hit this issue because its
PAGE_SIZE is 64KB.
Signe
will never be assigned into the
hole. So we add shadow resources and put them
into the hole in this patch. With these two
guarantees, I think it should be safe to mmap
sub-page BAR.
Signed-off-by: Yongji Xie
---
drivers/vfio/pci/vfio_pci.c | 58 +
is
capability, like this patch does.
Compared with IOMMU_CAP_INTR_REMAP, this
flag is more common. Any arch can set/use this
easily. And it can provide a better granularity
(pci_bus_type -> pci_bus).
[1] http://www.spinics.net/lists/kvm/msg130262.html
Signed-off-by: Yongji Xie
---
arch/powerpc/p
This patch enables mmapping MSI-X tables if
hardware supports interrupt remapping which
can ensure that a given pci device can only
shoot the MSIs assigned for it.
Signed-off-by: Yongji Xie
---
drivers/vfio/pci/vfio_pci.c |9 +++--
drivers/vfio/pci/vfio_pci_private.h |1
t;noresize" for the
parameter to solve this problem.
Signed-off-by: Yongji Xie
---
Documentation/kernel-parameters.txt |5 -
drivers/pci/pci.c | 37 +--
2 files changed, 31 insertions(+), 11 deletions(-)
diff --git a/Docum
On 2016/4/6 8:55, Gavin Shan wrote:
On Tue, Apr 05, 2016 at 09:43:30PM +0800, Yongji Xie wrote:
Now we use the IORESOURCE_STARTALIGN to identify
bridge resources in __assign_resources_sorted().
That's quite fragile. We can't make sure that
the PCI devices' resourc
On 2016/4/6 8:48, Gavin Shan wrote:
On Tue, Apr 05, 2016 at 09:43:29PM +0800, Yongji Xie wrote:
The resource_alignment will releases memory
resources allocated by firmware so that kernel
can reassign new resources later on. But this
will cause the problem that no resources can be
allocated by
On 2016/4/6 8:11, Gavin Shan wrote:
On Tue, Apr 05, 2016 at 09:46:43PM +0800, Yongji Xie wrote:
I'm trying to find a proper way to indicate
the capability of interrupt remapping on PPC64
because we need this to determine whether it is
safe to mmap MSI-X table in VFIO driver.
There
On 2016/4/6 8:00, Gavin Shan wrote:
On Tue, Apr 05, 2016 at 09:46:44PM +0800, Yongji Xie wrote:
This patch enables mmapping MSI-X tables if
hardware supports interrupt remapping which
can ensure that a given pci device can only
shoot the MSIs assigned for it.
Signed-off-by: Yongji Xie
parameter to enforce all MMIO BARs to be page aligned
on PCI core code instead of doing it on PPC64 arch code.
- Remove flags: VFIO_DEVICE_FLAGS_PCI_PAGE_ALIGNED
[1] http://www.spinics.net/lists/kvm/msg127812.html
[2] http://www.spinics.net/lists/kvm/msg130256.html
Yongji Xie (10):
PCI: Ignore
use firmware
setup and not to reassign any resources.
To solve this problem, this patch ignores resource_alignment
if PCI_PROBE_ONLY was set.
Signed-off-by: Yongji Xie
---
drivers/pci/pci.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index
ridge resources.
Signed-off-by: Yongji Xie
---
drivers/pci/setup-bus.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 7796d0a..45fc484 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -391,6 +
lignment of all MMIO BARs to be at least PAGE_SIZE so that
one BAR's mmio page would not be shared with other BARs.
And we also define a macro PCIBIOS_MIN_ALIGNMENT to enable this
automatically on PPC64 platform which can easily hit this issue
because its PAGE_SIZE is 64KB.
Signe
ption "noresize" for the parameter to
solve this problem.
Signed-off-by: Yongji Xie
---
Documentation/kernel-parameters.txt |5 -
drivers/pci/pci.c | 35 +--
2 files changed, 29 insertions(+), 11 deletions(-)
diff --git a/Docum
will never be assigned
into the hole. So we add shadow resources and put them into the
hole in this patch. With these two guarantees, I think it should
be safe to mmap sub-page BAR.
Signed-off-by: Yongji Xie
---
drivers/vfio/pci/vfio_pci.c | 58 +
.
Signed-off-by: Yongji Xie
---
drivers/iommu/iommu.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 0e3b009..5d2b6f6 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -813,6 +813,16 @@ struct iommu_group
sg130256.html
Signed-off-by: Yongji Xie
---
include/linux/pci.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 27df4a6..d619228 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -193,6 +193,7 @@ typedef unsigned short _
: Yongji Xie
---
drivers/vfio/pci/vfio_pci.c |7 +--
drivers/vfio/pci/vfio_pci_rdwr.c |3 ++-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index dc1779c..b08abe0 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b
Any IODA host bridge have the capability of IRQ remapping.
So we set PCI_BUS_FLAGS_MSI_REMAP when this kind of host birdge
is detected.
Signed-off-by: Yongji Xie
---
arch/powerpc/platforms/powernv/pci-ioda.c |8
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/platforms
.
[1] http://www.spinics.net/lists/kvm/msg130256.html
Signed-off-by: Yongji Xie
---
drivers/pci/msi.c | 12
drivers/pci/probe.c |3 +++
include/linux/msi.h |6 +-
3 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index
On 2016/4/18 19:30, David Laight wrote:
From: Yongji Xie
Sent: 18 April 2016 11:59
We introduce a new pci_bus_flags, PCI_BUS_FLAGS_MSI_REMAP
which indicates all devices on the bus are protected by the
hardware which supports IRQ remapping(intel naming).
This flag will be used to know whether
On 2016/4/23 2:38, Andrew Morton wrote:
On Fri, 22 Apr 2016 18:31:28 +0800 Yongji Xie wrote:
We used generic hooks in remap_pfn_range to help archs to
track pfnmap regions. The code is something like:
int remap_pfn_range()
{
...
track_pfn_remap(vma, &prot, pfn,
ck_pfn(vma, pfn, PAGE_ALIGN(size));
...
}
Here we can easily find the pfn is changed but not recovered
before untrack_pfn() is called. That's incorrect.
Signed-off-by: Yongji Xie
---
mm/memory.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/memory.c b/mm
Hi Alex,
Any comment?
Thanks,
Yongji
On 2016/4/18 18:53, Yongji Xie wrote:
Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs and MSI-X table. This is because
sub-page BARs' mmio page may be shared with other BARs and MSI-X table
should not be
On 2016/4/26 13:41, Alexey Kardashevskiy wrote:
On 04/18/2016 08:56 PM, Yongji Xie wrote:
When vfio passthrough a PCI device of which MMIO BARs are
smaller than PAGE_SIZE, guest will not handle the mmio
accesses to the BARs which leads to mmio emulations in host.
This is because vfio will not
Hi, Alex
On 2016/6/23 6:04, Alex Williamson wrote:
On Mon, 30 May 2016 21:06:37 +0800
Yongji Xie wrote:
Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio
page may be shared with other BARs. This will cause some
performanc
Hi, Alex
On 2016/6/24 0:12, Alex Williamson wrote:
On Mon, 30 May 2016 21:06:37 +0800
Yongji Xie wrote:
Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio
page may be shared with other BARs. This will cause some
performanc
Hi Gavin,
On 2016/7/1 8:28, Gavin Shan wrote:
On Thu, Jun 30, 2016 at 06:53:07PM +0800, Yongji Xie wrote:
PCI resources allocator will use firmware setup and not try to
reassign resource when PCI_PROBE_ONLY or IORESOURCE_PCI_FIXED
is set.
The enforced alignment in
Hi Gavin,
On 2016/7/1 8:39, Gavin Shan wrote:
On Thu, Jun 30, 2016 at 06:53:08PM +0800, Yongji Xie wrote:
VF BARs are read-only zeroes according to SRIOV spec,
the normal way(writing BARs) of allocating resources wouldn't
be applied to VFs. The VFs' resources would be allocated
when
Hi Gavin,
On 2016/7/1 14:05, Gavin Shan wrote:
On Fri, Jul 01, 2016 at 01:27:17PM +0800, Yongji Xie wrote:
On Thu, Jun 30, 2016 at 06:53:08PM +0800, Yongji Xie wrote:
VF BARs are read-only zeroes according to SRIOV spec,
the normal way(writing BARs) of allocating resources wouldn'
1 - 100 of 168 matches
Mail list logo
