All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Oleksandr Andrushchenko <andr2000@gmail.com>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH RFC] vPCI: account for hidden devices in modify_bars()
Date: Tue, 31 Aug 2021 08:51:52 +0200	[thread overview]
Message-ID: <e87ad2a2-7ee0-a2e7-7bab-0c332aca7aec@suse.com> (raw)
In-Reply-To: <b2e8863d-217a-fc0e-3176-a20ef5ad0872@gmail.com>

On 31.08.2021 07:35, Oleksandr Andrushchenko wrote:
> Hello, Jan!
> 
> On 30.08.21 16:04, Jan Beulich wrote:
>> Hidden devices (e.g. an add-in PCI serial card used for Xen's serial
>> console) are associated with DomXEN, not Dom0. This means that while
>> looking for overlapping BARs such devices cannot be found on Dom0's
>> list of devices; DomXEN's list also needs to be scanned.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> RFC: Patch intentionally mis-formatted, as the necessary re-indentation
>>       would make the diff difficult to read. At this point I'd merely
>>       like to gather input towards possible better approaches to solve
>>       the issue (not the least because quite possibly there are further
>>       places needing changing).
>>
>> --- a/xen/drivers/vpci/header.c
>> +++ b/xen/drivers/vpci/header.c
>> @@ -206,6 +206,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;
>> @@ -265,7 +266,8 @@ 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.
>>        */
>> -    for_each_pdev ( pdev->domain, tmp )
>> +for ( d = pdev->domain; ; d = dom_xen ) {//todo
> 
> I am not quite sure this will be correct for the cases where pdev->domain != dom0,
> e.g. in the series for PCI passthrough for Arm this can be any guest. For such cases
> we'll force running the loop for dom_xen which I am not sure is desirable.

It is surely not desirable, but it also doesn't happen - see the
is_hardware_domain() check further down (keeping context below).

> Another question is why such a hidden device has its pdev->domain not set correctly,
> so we need to work this around?

Please see _setup_hwdom_pci_devices() and commit e46ea4d44dc0
("PCI: don't allow guest assignment of devices used by Xen")
introducing that temporary override. To permit limited
visibility to Dom0, these devices still need setting up in the
IOMMU for Dom0. Consequently BAR overlap detection also needs
to take these into account (i.e. the goal here is not just to
prevent triggering the ASSERT() in question).

Jan

>> @@ -308,6 +311,7 @@ static int modify_bars(const struct pci_
>>               }
>>           }
>>       }
>> +if ( !is_hardware_domain(d) ) break; }//todo
>>   
>>       ASSERT(dev);
>>   
>>
>>
> 



  reply	other threads:[~2021-08-31  6:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-30 13:04 [PATCH RFC] vPCI: account for hidden devices in modify_bars() Jan Beulich
2021-08-31  5:35 ` Oleksandr Andrushchenko
2021-08-31  6:51   ` Jan Beulich [this message]
2021-08-31  7:06     ` Oleksandr Andrushchenko
2021-08-31  7:47       ` Jan Beulich
2021-08-31  7:56         ` Oleksandr Andrushchenko
2021-08-31  8:05           ` Jan Beulich
2021-08-31  8:14             ` Oleksandr Andrushchenko
2021-08-31  8:35               ` Jan Beulich
2021-09-01  4:50                 ` Oleksandr Andrushchenko
2021-09-01  8:20                   ` Jan Beulich
2021-09-14 10:00 ` Roger Pau Monné
2021-09-14 10:12   ` Jan Beulich
2021-09-14 11:21     ` Roger Pau Monné
2021-09-14 12:05       ` Jan Beulich
2021-09-14 14:22         ` Roger Pau Monné
2021-09-14 15:16           ` Jan Beulich
2021-09-14 16:04             ` Roger Pau Monné

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=e87ad2a2-7ee0-a2e7-7bab-0c332aca7aec@suse.com \
    --to=jbeulich@suse.com \
    --cc=andr2000@gmail.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /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.