All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yongji Xie <xyjxie@linux.vnet.ibm.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-doc@vger.kernel.org, bhelgaas@google.com, corbet@lwn.net,
	aik@ozlabs.ru, alex.williamson@redhat.com,
	benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au,
	warrier@linux.vnet.ibm.com, zhong@linux.vnet.ibm.com,
	nikunj@linux.vnet.ibm.com
Subject: Re: [RFC PATCH v4 0/7] vfio-pci: Allow to mmap sub-page MMIO BARs and MSI-X table
Date: Thu, 17 Mar 2016 18:46:44 +0800	[thread overview]
Message-ID: <56EA8B14.4070808@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160316141013.GA21809@localhost>

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 looking hard at the resource_alignment kernel
> parameter.  I'm opposed to kernel parameters in general because
> they're very difficult for users to use correctly, and they lead to
> kernel code paths that are rarely tested and hard to maintain.  So
> I'll be looking for an excuse to reject changes in that area.
>
> The changelog for 2/7 says it "replaces IORESOURCE_STARTALIGN with
> IORESOURCE_WINDOW."  But even a glance at the patch itself shows that
> IORESOURCE_WINDOW is *added* to some places, and it doesn't *replace*
> IORESOURCE_STARTALIGN.

There is a problem with my statement. I mean we can use
IORESOURCE_WINDOW to identify bridge resources instead of
IORESOURCE_STARTALIGN here.

> The changelog for 4/7 says:
>
>    This is because vfio will not allow to passthrough one BAR's mmio
>    page which may be shared with other BARs.  To solve this performance
>    issue ...
>
> with no mention at all of the actual *reason* vfio doesn't allow that
> passthrough.  If I understand correctly, that reason has to do with
> security, so your justification must be much stronger than "solving a
> performance issue."

OK. I will try to make my justification become stronger.

Thanks,
Yongji Xie


      reply	other threads:[~2016-03-17 10:47 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-07  7:48 [RFC PATCH v4 0/7] vfio-pci: Allow to mmap sub-page MMIO BARs and MSI-X table Yongji Xie
2016-03-07  7:48 ` [RFC PATCH v4 1/7] PCI: Add a new option for resource_alignment to reassign alignment Yongji Xie
2016-03-10  2:19   ` Alexey Kardashevskiy
2016-03-10  4:47     ` Yongji Xie
2016-03-07  7:48 ` [RFC PATCH v4 2/7] PCI: Use IORESOURCE_WINDOW to identify bridge resources Yongji Xie
2016-03-07  7:48 ` [RFC PATCH v4 3/7] PCI: Ignore resource_alignment if PCI_PROBE_ONLY was set Yongji Xie
2016-03-16 16:31   ` Alex Williamson
2016-03-17 11:35     ` Yongji Xie
2016-03-07  7:48 ` [RFC PATCH v4 4/7] PCI: Modify resource_alignment to support multiple devices Yongji Xie
2016-03-16 16:30   ` Alex Williamson
2016-03-17 11:28     ` Yongji Xie
2016-03-17 12:40       ` Alex Williamson
2016-03-18 15:04         ` Yongji Xie
2016-03-07  7:48 ` [RFC PATCH v4 5/7] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive Yongji Xie
2016-03-16 16:30   ` Alex Williamson
2016-03-17 11:29     ` Yongji Xie
2016-03-07  7:48 ` [RFC PATCH v4 6/7] vfio-pci: Allow to mmap MSI-X table if IOMMU_CAP_INTR_REMAP was set Yongji Xie
2016-03-16 16:31   ` Alex Williamson
2016-03-17 11:32     ` Yongji Xie
2016-03-07  7:48 ` [RFC PATCH v4 7/7] powerpc/powernv/pci-ioda: Add IOMMU_CAP_INTR_REMAP for IODA host bridge Yongji Xie
2016-03-16 16:32   ` Alex Williamson
2016-03-17 11:38     ` Yongji Xie
2016-03-17 12:48       ` Alex Williamson
2016-03-18 11:51         ` Yongji Xie
2016-03-18 11:51           ` Yongji Xie
2016-03-16 10:51 ` [RFC PATCH v4 0/7] vfio-pci: Allow to mmap sub-page MMIO BARs and MSI-X table Yongji Xie
2016-03-16 14:10   ` Bjorn Helgaas
2016-03-17 10:46     ` Yongji Xie [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56EA8B14.4070808@linux.vnet.ibm.com \
    --to=xyjxie@linux.vnet.ibm.com \
    --cc=aik@ozlabs.ru \
    --cc=alex.williamson@redhat.com \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=corbet@lwn.net \
    --cc=helgaas@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=nikunj@linux.vnet.ibm.com \
    --cc=paulus@samba.org \
    --cc=warrier@linux.vnet.ibm.com \
    --cc=zhong@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.