mirror of https://lore.kernel.org/lkml/
 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, alex.williamson@redhat.com,
	bhelgaas@google.com, aik@ozlabs.ru, 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,
	gwshan@linux.vnet.ibm.com, kevin.tian@intel.com
Subject: Re: [PATCH v2] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive
Date: Thu, 12 May 2016 13:56:45 +0800	[thread overview]
Message-ID: <6be14833-2a0f-8dd8-5bb1-b932850521f2@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160511151034.GB21753@localhost>

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 issues when we passthrough a PCI device with
>> this kind of BARs. Guest will be not able to handle the mmio
>> accesses to the BARs which leads to mmio emulations in host.
>>
>> However, not all sub-page BARs will share page with other BARs.
>> We should allow to mmap the sub-page MMIO BARs which we can
>> make sure will not share page with other BARs.
>>
>> This patch adds support for this case. And we try to add some
>> dummy resources to reserve the remaind of the page which
>> hot-add device's BAR might be assigned into.
> This is starting to look more reasonable from a safety perspective.
> At least I don't have an allergic reaction to mapping a page that may
> contain BARs from other random devices :)
>
>> Signed-off-by: Yongji Xie <xyjxie@linux.vnet.ibm.com>
>> ---
>>   drivers/vfio/pci/vfio_pci.c         |   85 ++++++++++++++++++++++++++++++++---
>>   drivers/vfio/pci/vfio_pci_private.h |    8 ++++
>>   2 files changed, 86 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
>> index 98059df..33282b8 100644
>> --- a/drivers/vfio/pci/vfio_pci.c
>> +++ b/drivers/vfio/pci/vfio_pci.c
>> @@ -110,16 +110,77 @@ static inline bool vfio_pci_is_vga(struct pci_dev *pdev)
>>   	return (pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA;
>>   }
>>   
>> +static bool vfio_pci_bar_mmap_supported(struct vfio_pci_device *vdev, int index)
>> +{
>> +	struct resource *res = vdev->pdev->resource + index;
>> +	struct vfio_pci_dummy_resource *dummy_res1 = NULL;
>> +	struct vfio_pci_dummy_resource *dummy_res2 = NULL;
>> +
>> +	if (IS_ENABLED(CONFIG_VFIO_PCI_MMAP) && res->flags & IORESOURCE_MEM &&
>> +		resource_size(res) > 0) {
>> +		if (resource_size(res) >= PAGE_SIZE)
>> +			return true;
>> +
>> +		if ((res->start & ~PAGE_MASK)) {
>> +			/*
>> +			 * Add a dummy resource to reserve the portion
>> +			 * before res->start in exclusive page in case
>> +			 * that hot-add device's bar is assigned into it.
>> +			 */
>> +			dummy_res1 = kzalloc(sizeof(*dummy_res1), GFP_KERNEL);
> Should check for kzalloc() failure here.
>
>> +			dummy_res1->resource.start = res->start & PAGE_MASK;
>> +			dummy_res1->resource.end = res->start - 1;
>> +			dummy_res1->resource.flags = res->flags;
>> +			if (request_resource(res->parent,
>> +						&dummy_res1->resource)) {
>> +				kfree(dummy_res1);
>> +				return false;
>> +			}
>> +			dummy_res1->index = index;
>> +			list_add(&dummy_res1->res_next,
>> +					&vdev->dummy_resources_list);
> The main body of this function is unnecessarily indented.  If you did
> this it would be less indented:
>
>    if (!IS_ENABLED(CONFIG_VFIO_PCI_MMAP))
>      return false;
>
>    if (!res->flags & IORESOURCE_MEM)
>      return false;
>
>    /*
>     * Not sure this is necessary; the PCI core *shouldn't* set up a
>     * resource with a type but zero size.  But there may be bugs that
>     * cause us to do that.
>     */
>    if (!resource_size(res))
>      return false;
>
>    if (resource_size(res) >= PAGE_SIZE)
>      return true;
>
>    if ((res->start & ~PAGE_MASK)) {
>      ...
>

Thanks for your comments. I'll send a v3 soon.

Regards,
Yongji

      reply	other threads:[~2016-05-12  5:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-11 11:34 Yongji Xie
2016-05-11 15:10 ` Bjorn Helgaas
2016-05-12  5:56   ` 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=6be14833-2a0f-8dd8-5bb1-b932850521f2@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=gwshan@linux.vnet.ibm.com \
    --cc=helgaas@kernel.org \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®