All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>
To: "Jan Beulich" <jbeulich@suse.com>,
	"Oleksandr Andrushchenko" <andr2000@gmail.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Cc: "julien@xen.org" <julien@xen.org>,
	"sstabellini@kernel.org" <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <Oleksandr_Tyshchenko@epam.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Artem Mygaiev <Artem_Mygaiev@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Rahul Singh <rahul.singh@arm.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 3/9] vpci/header: Move register assignments from init_bars
Date: Tue, 7 Sep 2021 10:04:59 +0000	[thread overview]
Message-ID: <218da10d-2280-4f15-4ede-b5fadcb8c59d@epam.com> (raw)
In-Reply-To: <4007d84d-9e76-32df-58f6-af5ff26fdf6e@suse.com>


On 06.09.21 16:53, Jan Beulich wrote:
> On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>
>> This is in preparation for dynamic assignment of the vpci register
>> handlers depending on the domain: hwdom or guest.
> I guess why exactly this is going to help is going to be seen in
> subsequent patches. To aid review (i.e. to not force reviewers to
> peek ahead) it would imo be helpful if you outlined how the result
> is going to help.

Sure, will do next time. The need for this step is that is it easier to have

all related functionality (BARs here) put at one place and when the subsequent

patches add decisions on which handlers to install, e.g. hwdom or guest handlers,

this function is extended to accept a one more parameter, is_hwdom, and all

the assignment logic is put here. Of course I could have all the "if (is_hwdom)"'s

put at the original location, but dedicated function looked cleaner to me.

>   After all ...
>
>> --- a/xen/drivers/vpci/header.c
>> +++ b/xen/drivers/vpci/header.c
>> @@ -445,6 +445,55 @@ static void rom_write(const struct pci_dev *pdev, unsigned int reg,
>>           rom->addr = val & PCI_ROM_ADDRESS_MASK;
>>   }
>>   
>> +static int add_bar_handlers(struct pci_dev *pdev)
> ... this function name, for example, isn't Dom0-specific, so one
> might expect the function body to gain conditionals. Yet then the
> question is why these conditionals can't live in the original
> function.

Answered above. I think it makes code cleaner and easier for modification

as handlers' assignment for BARs becomes grouped as it is done for MSI/MSI-X.


>
>> +{
>> +    unsigned int i;
>> +    struct vpci_header *header = &pdev->vpci->header;
>> +    struct vpci_bar *bars = header->bars;
>> +    int rc;
>> +
>> +    /* Setup a handler for the command register. */
>> +    rc = vpci_add_register(pdev->vpci, vpci_hw_read16, cmd_write, PCI_COMMAND,
>> +                           2, header);
>> +    if ( rc )
>> +        return rc;
>> +
>> +    if ( pdev->ignore_bars )
>> +        return 0;
>> +
>> +    for ( i = 0; i < PCI_HEADER_NORMAL_NR_BARS + 1; i++ )
>> +    {
>> +        if ( (bars[i].type == VPCI_BAR_IO) || (bars[i].type == VPCI_BAR_EMPTY) )
>> +            continue;
>> +
>> +        if ( bars[i].type == VPCI_BAR_ROM )
>> +        {
>> +            unsigned int rom_reg;
>> +            uint8_t header_type = pci_conf_read8(pdev->sbdf,
>> +                                                 PCI_HEADER_TYPE) & 0x7f;
>> +            if ( header_type == PCI_HEADER_TYPE_NORMAL )
>> +                rom_reg = PCI_ROM_ADDRESS;
>> +            else
>> +                rom_reg = PCI_ROM_ADDRESS1;
>> +            rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rom_write,
>> +                                   rom_reg, 4, &bars[i]);
>> +            if ( rc )
>> +                return rc;
> I'm not the maintainer of this code, but if I was I'd ask for this and ...
>
>> +        }
>> +        else
>> +        {
>> +            uint8_t reg = PCI_BASE_ADDRESS_0 + i * 4;
>> +
>> +            /* This is either VPCI_BAR_MEM32 or VPCI_BAR_MEM64_{LO|HI}. */
>> +            rc = vpci_add_register(pdev->vpci, vpci_hw_read32, bar_write, reg,
>> +                                   4, &bars[i]);
>> +            if ( rc )
>> +                return rc;
> ... this to be moved ...
>
>> +        }
> ... here to reduce redundancy.
>
>> @@ -553,11 +580,13 @@ static int init_bars(struct pci_dev *pdev)
>>           rom->addr = addr;
>>           header->rom_enabled = pci_conf_read32(pdev->sbdf, rom_reg) &
>>                                 PCI_ROM_ADDRESS_ENABLE;
>> +    }
>>   
>> -        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, rom_write, rom_reg,
>> -                               4, rom);
>> -        if ( rc )
>> -            rom->type = VPCI_BAR_EMPTY;
>> +    rc = add_bar_handlers(pdev);
>> +    if ( rc )
>> +    {
>> +        pci_conf_write16(pdev->sbdf, PCI_COMMAND, cmd);
>> +        return rc;
>>       }
> Seeing this moved (hence perhaps more a question to Roger than to
> you) restoring of the command register - why is it that the error
> path(s) here care(s) about restoring this, but ...
>
>>       return (cmd & PCI_COMMAND_MEMORY) ? modify_bars(pdev, cmd, false) : 0;
> ... ones in modify_bars() (and downwards) don't? I was wondering
> whether the restore could actually be done prior to the two calls
> (or, in the original code, the one call), or perhaps even right
> after the last call to pci_size_mem_bar(). At the very least the
> comment further up suggests memory decode only gets disabled for
> sizing BARs, which we're done with at this point.

For all the above: what this patch does is a pure code move.

I had no intention to alter it in any other way rather than that.

If you think the code needs to be functionally modified I think this

deserves a dedicated work to be submitted, but IMO this patch

shouldn't touch anything.

>
> Jan
>
Thank you,

Oleksandr

  reply	other threads:[~2021-09-07 10:05 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-03 10:08 [PATCH 0/9] PCI devices passthrough on Arm, part 3 Oleksandr Andrushchenko
2021-09-03 10:08 ` [PATCH 1/9] vpci: Make vpci registers removal a dedicated function Oleksandr Andrushchenko
2021-09-03 10:08 ` [PATCH 2/9] vpci: Add hooks for PCI device assign/de-assign Oleksandr Andrushchenko
2021-09-06 13:23   ` Jan Beulich
2021-09-07  8:33     ` Oleksandr Andrushchenko
2021-09-07  8:44       ` Jan Beulich
2021-09-03 10:08 ` [PATCH 3/9] vpci/header: Move register assignments from init_bars Oleksandr Andrushchenko
2021-09-06 13:53   ` Jan Beulich
2021-09-07 10:04     ` Oleksandr Andrushchenko [this message]
2021-09-03 10:08 ` [PATCH 4/9] vpci/header: Add and remove register handlers dynamically Oleksandr Andrushchenko
2021-09-06 14:11   ` Jan Beulich
2021-09-07 10:11     ` Oleksandr Andrushchenko
2021-09-07 10:43       ` Jan Beulich
2021-09-07 11:10         ` Oleksandr Andrushchenko
2021-09-07 11:49           ` Jan Beulich
2021-09-07 12:16             ` Oleksandr Andrushchenko
2021-09-07 12:20               ` Jan Beulich
2021-09-07 12:23                 ` Oleksandr Andrushchenko
2021-09-10 21:14   ` Stefano Stabellini
2021-09-03 10:08 ` [PATCH 5/9] vpci/header: Implement guest BAR register handlers Oleksandr Andrushchenko
2021-09-06 14:31   ` Jan Beulich
2021-09-07 13:33     ` Oleksandr Andrushchenko
2021-09-07 16:30       ` Jan Beulich
2021-09-07 17:39         ` Oleksandr Andrushchenko
2021-09-08  9:27           ` Jan Beulich
2021-09-08  9:43             ` Oleksandr Andrushchenko
2021-09-08 10:03               ` Jan Beulich
2021-09-08 13:33                 ` Oleksandr Andrushchenko
2021-09-08 14:46                   ` Jan Beulich
2021-09-08 15:14                     ` Oleksandr Andrushchenko
2021-09-08 15:29                       ` Jan Beulich
2021-09-08 15:35                         ` Oleksandr Andrushchenko
2021-09-03 10:08 ` [PATCH 6/9] vpci/header: Handle p2m range sets per BAR Oleksandr Andrushchenko
2021-09-06 14:47   ` Jan Beulich
2021-09-08 14:31     ` Oleksandr Andrushchenko
2021-09-08 15:00       ` Jan Beulich
2021-09-09  5:22         ` Oleksandr Andrushchenko
2021-09-09  8:24           ` Jan Beulich
2021-09-09  9:12             ` Oleksandr Andrushchenko
2021-09-09  9:39               ` Jan Beulich
2021-09-09 10:03                 ` Oleksandr Andrushchenko
2021-09-09 10:46                   ` Jan Beulich
2021-09-09 11:30                     ` Oleksandr Andrushchenko
2021-09-09 11:51                       ` Jan Beulich
2021-09-03 10:08 ` [PATCH 7/9] vpci/header: program p2m with guest BAR view Oleksandr Andrushchenko
2021-09-06 14:51   ` Jan Beulich
2021-09-09  6:13     ` Oleksandr Andrushchenko
2021-09-09  8:26       ` Jan Beulich
2021-09-09  9:16         ` Oleksandr Andrushchenko
2021-09-09  9:40           ` Jan Beulich
2021-09-09  9:53             ` Oleksandr Andrushchenko
2021-09-03 10:08 ` [PATCH 8/9] vpci/header: Reset the command register when adding devices Oleksandr Andrushchenko
2021-09-06 14:55   ` Jan Beulich
2021-09-07  7:43     ` Oleksandr Andrushchenko
2021-09-07  8:00       ` Jan Beulich
2021-09-07  8:18         ` Oleksandr Andrushchenko
2021-09-07  8:49           ` Jan Beulich
2021-09-07  9:07             ` Oleksandr Andrushchenko
2021-09-07  9:19               ` Jan Beulich
2021-09-07  9:52                 ` Oleksandr Andrushchenko
2021-09-07 10:06                   ` Jan Beulich
2021-09-09  8:39                     ` Oleksandr Andrushchenko
2021-09-09  8:43                       ` Jan Beulich
2021-09-09  8:50                         ` Oleksandr Andrushchenko
2021-09-09  9:21                           ` Jan Beulich
2021-09-09 11:48                             ` Oleksandr Andrushchenko
2021-09-09 11:53                               ` Jan Beulich
2021-09-09 12:42                                 ` Oleksandr Andrushchenko
2021-09-09 12:47                                   ` Jan Beulich
2021-09-09 12:48                                     ` Oleksandr Andrushchenko
2021-09-09 13:17                                     ` Oleksandr Andrushchenko
2021-09-09 11:48                             ` Oleksandr Andrushchenko
2021-09-03 10:08 ` [PATCH 9/9] vpci/header: Use pdev's domain instead of vCPU Oleksandr Andrushchenko
2021-09-06 14:57   ` Jan Beulich
2021-09-09  4:23     ` Oleksandr Andrushchenko

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=218da10d-2280-4f15-4ede-b5fadcb8c59d@epam.com \
    --to=oleksandr_andrushchenko@epam.com \
    --cc=Artem_Mygaiev@epam.com \
    --cc=Oleksandr_Tyshchenko@epam.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=andr2000@gmail.com \
    --cc=bertrand.marquis@arm.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=rahul.singh@arm.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --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.