[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56EA8B14.4070808@linux.vnet.ibm.com>
Date: Thu, 17 Mar 2016 18:46:44 +0800
From: Yongji Xie <xyjxie@...ux.vnet.ibm.com>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-pci@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
linux-doc@...r.kernel.org, bhelgaas@...gle.com, corbet@....net,
aik@...abs.ru, alex.williamson@...hat.com,
benh@...nel.crashing.org, paulus@...ba.org, mpe@...erman.id.au,
warrier@...ux.vnet.ibm.com, zhong@...ux.vnet.ibm.com,
nikunj@...ux.vnet.ibm.com
Subject: Re: [RFC PATCH v4 0/7] vfio-pci: Allow to mmap sub-page MMIO BARs and
MSI-X table
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
Powered by blists - more mailing lists