From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751779AbdIUGh0 (ORCPT ); Thu, 21 Sep 2017 02:37:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44660 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751450AbdIUGhZ (ORCPT ); Thu, 21 Sep 2017 02:37:25 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com DA6C6A1F45 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=eric.auger@redhat.com Subject: Re: [PATCH] vfio/pci: Virtualize Maximum Payload Size To: Alex Williamson , kvm@vger.kernel.org References: <20170919164952.13200.78849.stgit@gimli.home> Cc: linux-kernel@vger.kernel.org, jcm@redhat.com From: Auger Eric Message-ID: <4d042fd8-1bbb-4419-7c4d-d6bfbcd0f898@redhat.com> Date: Thu, 21 Sep 2017 08:37:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170919164952.13200.78849.stgit@gimli.home> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 21 Sep 2017 06:37:25 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Alex, On 19/09/2017 18:58, Alex Williamson wrote: > With virtual PCI-Express chipsets, we now see userspace/guest drivers > trying to match the physical MPS setting to a virtual downstream port. > Of course a lone physical device surrounded by virtual interconnects > cannot make a correct decision for a proper MPS setting. Instead, > let's virtualize the MPS control register so that writes through to > hardware are disallowed. Userspace drivers like QEMU assume they can > write anything to the device and we'll filter out anything dangerous. > Since mismatched MPS can lead to AER and other faults, let's add it > to the kernel side rather than relying on userspace virtualization to > handle it. > > Signed-off-by: Alex Williamson Reviewed-by: Eric Auger Thanks Eric > --- > > Do we have any reason to suspect that a userspace driver has any > dependencies on the physical MPS setting or is this only tuning the > protocol layer and it's transparent to the driver? Note that per the > PCI spec, a device supporting only 128B MPS can hardwire the control > register to 000b, but it doesn't seem PCIe compliant to hardwire it to > any given value, such as would be the appearance if we exposed this as > a read-only register rather than virtualizing it. QEMU would then be > responsible for virtualizing it, which makes coordinating the upgrade > troublesome. > > drivers/vfio/pci/vfio_pci_config.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c > index 5628fe114347..91335e6de88a 100644 > --- a/drivers/vfio/pci/vfio_pci_config.c > +++ b/drivers/vfio/pci/vfio_pci_config.c > @@ -849,11 +849,13 @@ static int __init init_pci_cap_exp_perm(struct perm_bits *perm) > > /* > * Allow writes to device control fields, except devctl_phantom, > - * which could confuse IOMMU, and the ARI bit in devctl2, which > + * which could confuse IOMMU, MPS, which can break communication > + * with other physical devices, and the ARI bit in devctl2, which > * is set at probe time. FLR gets virtualized via our writefn. > */ > p_setw(perm, PCI_EXP_DEVCTL, > - PCI_EXP_DEVCTL_BCR_FLR, ~PCI_EXP_DEVCTL_PHANTOM); > + PCI_EXP_DEVCTL_BCR_FLR | PCI_EXP_DEVCTL_PAYLOAD, > + ~PCI_EXP_DEVCTL_PHANTOM); > p_setw(perm, PCI_EXP_DEVCTL2, NO_VIRT, ~PCI_EXP_DEVCTL2_ARI); > return 0; > } >