[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH RFC v2] vPCI: account for hidden devices


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Thu, 25 May 2023 17:02:11 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nv/Cp1Joc8laf1E+rCi3GRW0NW+O6nIj92ZsL2gumXQ=; b=YsWBonGZa45haX4ZEKoEkNXTsWeuSZYxQyYplHrNJbhEstFnsRWhFV/UEBH4UViy1wjwpF+V5uWElLivVNok3+G3VkbMn7ZJUFE/iQJWydNjTLQOD79Pleu51MQs6omSfIcwjHGvl6bUniQhV0S6o6wAZOJP6NfaVsUHEIYKHCDpSZvtWML32QYqhQcrzj/ULPgT4JbY4YyRBT408ex/dqnV4y/v8txodgJU64fVTQLBBRfXL2wuKxlSnMPg6O7AgJ+mxXAkPEma2YjZFzZ2DQw5U4VZeu0/c8tRnP5aLU3qIWgEAGPWwhf717+4B1S/Xse+/XgoNwXWhaN9GEOBdQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N4xkXM5IEIcibrohRbzzPymj83u0wLprEA9smrVs1+ZhLesJ2X8KVt8Y4zT/N+1q8HHbWtE0tjIlE0jgSxMgmUAgjdDp/drbHrC9PpU3e65VH1je8xh7NCRmRpiIhxy4g64x3dhpz16h/ljbdxIcmzh7v53Tgv6NaamAdCeb+aE5uKQMGBtHHSO1rA8OZprO+2WlxueyWWBp6rwpBZ9umDx/vXPVeyZ4pc31MV76RH9QX1RvBEMSQex8qDIyCMQ3DGrYD6re4zkRxVkitHMBXTDe3tKEt2XX031JiQOL96zsqzuicypWqUpUQTijwb/irUFT5kOz3yLUVeal6145Vw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • Delivery-date: Thu, 25 May 2023 15:02:42 +0000
  • Ironport-data: A9a23:dZ9grKnzBsrqq/OqDakb2HDo5gyrJ0RdPkR7XQ2eYbSJt1+Wr1Gzt xIcUW+AP62Lazekedl3bI/goB8PucWGytVhTQFpq3g3FCMWpZLJC+rCIxarNUt+DCFhoGFPt JxCN4aafKjYaleG+39B55C49SEUOZmgH+a6U6icfHgqH2eIcQ954Tp7gek1n4V0ttawBgKJq LvartbWfVSowFaYCEpNg064gE0p5KyaVA8w5ARkPqgW5gKGzhH5MbpETU2PByqgKmVrNrbSq 9brlNmR4m7f9hExPdKp+p6TnpoiG+O60aCm0xK6aoD66vRwjnVaPpUTbZLwXXx/mTSR9+2d/ f0W3XCGpaXFCYWX8AgVe0Ew/yiTpsSq8pefSZS0mZT7I0Er7xIAahihZa07FdRwxwp5PY1B3 achAjEQThqxvuON5ryYcPlUgdUmc8a+aevzulk4pd3YJdAPZMmaBo/stZpf1jp2gd1SF/HDY cZfcSBocBnLfxxIPBEQFY46m+CrwHL4dlW0qnrM/fZxvzeVkVw3iea8WDbWUoXiqcF9hEGXq 3iA523kKhobKMae2XyO9XfEaurnxHuqAd1NROXjnhJsqAC44DINCQYGbmKcoeXp1E/gVo8cK 2VBr0LCqoB3riRHVOLVXRe1vXqFtR40QMdLHqsx7wTl4rrZ5UOVC3YJShZFacc6r4kmSDoyz FiLktj1Qzt1v9W9UmmB/72ZqTezPyk9LmIYYyIACwwf7LHeTJobixvOSpNpFv6zh9isQDXom WnU/W45mqkZitMN2+Oj51fbjjmwp5/PCAko+gHQWWHj5QR8DGK4W7GVBZHgxa4oBO6kopOp5 xDoR+D2ADgyMKyw
  • Ironport-hdrordr: A9a23:OTt1F6hj0LPsj5b0KUk9KjDOuHBQXtgji2hC6mlwRA09TyXPrb HKoB17737JYVkqME3I9erqBEDiex3hHPxOjbX5Zo3SPjUO0VHAEGgF1+HfKlbbdBEWmNQx6U /OGZIObOEZoTJB7foTQWODYrUd/OU=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, May 25, 2023 at 04:39:51PM +0200, Jan Beulich wrote:
> On 24.05.2023 17:56, Roger Pau Monné wrote:
> > On Wed, May 24, 2023 at 03:45:58PM +0200, Jan Beulich wrote:
> >> --- a/xen/drivers/vpci/header.c
> >> +++ b/xen/drivers/vpci/header.c
> >> @@ -218,6 +218,7 @@ static int modify_bars(const struct pci_
> >>      struct vpci_header *header = &pdev->vpci->header;
> >>      struct rangeset *mem = rangeset_new(NULL, NULL, 0);
> >>      struct pci_dev *tmp, *dev = NULL;
> >> +    const struct domain *d;
> >>      const struct vpci_msix *msix = pdev->vpci->msix;
> >>      unsigned int i;
> >>      int rc;
> >> @@ -285,9 +286,11 @@ static int modify_bars(const struct pci_
> >>  
> >>      /*
> >>       * Check for overlaps with other BARs. Note that only BARs that are
> >> -     * currently mapped (enabled) are checked for overlaps.
> >> +     * currently mapped (enabled) are checked for overlaps. Note also that
> >> +     * for Dom0 we also need to include hidden, i.e. DomXEN's, devices.
> >>       */
> >> -    for_each_pdev ( pdev->domain, tmp )
> >> +for ( d = pdev->domain; ; d = dom_xen ) {//todo
> > 
> > Looking at this again, I think this is slightly more complex, as during
> > runtime dom0 will get here with pdev->domain == hardware_domain OR
> > dom_xen, and hence you also need to account that devices that have
> > pdev->domain == dom_xen need to iterate over devices that belong to
> > the hardware_domain, ie:
> > 
> > for ( d = pdev->domain; ;
> >       d = (pdev->domain == dom_xen) ? hardware_domain : dom_xen )
> 
> Right, something along these lines. To keep loop continuation expression
> and exit condition simple, I'll probably prefer
> 
> for ( d = pdev->domain != dom_xen ? pdev->domain : hardware_domain;
>       ; d = dom_xen )

LGTM.  I would add parentheses around the pdev->domain != dom_xen
condition, but that's just my personal taste.

We might want to add an

ASSERT(pdev->domain == hardware_domain || pdev->domain == dom_xen);

here, just to remind that this chunk must be revisited when adding
domU support (but you can also argue we haven't done this elsewhere),
I just feel here it's not so obvious we don't want do to this for
domUs.

> > And we likely want to limit this to devices that belong to the
> > hardware_domain or to dom_xen (in preparation for vPCI being used for
> > domUs).
> 
> I'm afraid I don't understand this remark, though.

This was looking forward to domU support, so that you already cater
for pdev->domain not being hardware_domain or dom_xen, but we might
want to leave that for later, when domU support is actually
introduced.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.