All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Oleksandr Andrushchenko <andr2000@gmail.com>
Cc: julien@xen.org, sstabellini@kernel.org,
	oleksandr_tyshchenko@epam.com, volodymyr_babchuk@epam.com,
	Artem_Mygaiev@epam.com, roger.pau@citrix.com,
	bertrand.marquis@arm.com, rahul.singh@arm.com,
	Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 5/9] vpci/header: Implement guest BAR register handlers
Date: Mon, 6 Sep 2021 16:31:47 +0200	[thread overview]
Message-ID: <1848521d-4179-f5ee-e3af-f4e6738f60e6@suse.com> (raw)
In-Reply-To: <20210903100831.177748-6-andr2000@gmail.com>

On 03.09.2021 12:08, Oleksandr Andrushchenko wrote:
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -400,12 +400,72 @@ static void bar_write(const struct pci_dev *pdev, unsigned int reg,
>  static void guest_bar_write(const struct pci_dev *pdev, unsigned int reg,
>                              uint32_t val, void *data)
>  {
> +    struct vpci_bar *bar = data;
> +    bool hi = false;
> +
> +    if ( bar->type == VPCI_BAR_MEM64_HI )
> +    {
> +        ASSERT(reg > PCI_BASE_ADDRESS_0);
> +        bar--;
> +        hi = true;
> +    }
> +    else
> +        val &= PCI_BASE_ADDRESS_MEM_MASK;
> +    bar->guest_addr &= ~(0xffffffffull << (hi ? 32 : 0));
> +    bar->guest_addr |= (uint64_t)val << (hi ? 32 : 0);

What you store here is not the address that's going to be used, as
you don't mask off the low bits (to account for the BAR's size).
When a BAR gets written with all ones, all writable bits get these
ones stored. The address of the BAR, aiui, really changes to
(typically) close below 4Gb (in the case of a 32-bit BAR), which
is why memory / I/O decoding should be off while sizing BARs.
Therefore you shouldn't look for the specific "all writable bits
are ones" pattern (or worse, as you presently do, the "all bits
outside of the type specifier are ones" one) on the read path.
Instead mask the value appropriately here, and simply return back
the stored value from the read path.

>  }
>  
>  static uint32_t guest_bar_read(const struct pci_dev *pdev, unsigned int reg,
>                                 void *data)
>  {
> -    return 0xffffffff;
> +    struct vpci_bar *bar = data;
> +    uint32_t val;
> +    bool hi = false;
> +
> +    switch ( bar->type )
> +    {
> +    case VPCI_BAR_MEM64_HI:
> +        ASSERT(reg > PCI_BASE_ADDRESS_0);
> +        bar--;
> +        hi = true;
> +        /* fallthrough */
> +    case VPCI_BAR_MEM64_LO:
> +    {

Please don't add braces to case blocks when they're not needed.

> +        if ( hi )
> +            val = bar->guest_addr >> 32;
> +        else
> +            val = bar->guest_addr & 0xffffffff;
> +        if ( (val & PCI_BASE_ADDRESS_MEM_MASK_32) ==  PCI_BASE_ADDRESS_MEM_MASK_32 )

This is wrong when falling through to here from VPCI_BAR_MEM64_HI:
All 32 bits need to be looked at. Yet as per the comment further
up I think it isn't right anyway to apply the mask here.

Also: Stray double blanks.

> +        {
> +            /* Guests detects BAR's properties and sizes. */
> +            if ( hi )
> +                val = bar->size >> 32;
> +            else
> +                val = 0xffffffff & ~(bar->size - 1);
> +        }
> +        if ( !hi )
> +        {
> +            val |= PCI_BASE_ADDRESS_MEM_TYPE_64;
> +            val |= bar->prefetchable ? PCI_BASE_ADDRESS_MEM_PREFETCH : 0;
> +        }
> +        bar->guest_addr &= ~(0xffffffffull << (hi ? 32 : 0));
> +        bar->guest_addr |= (uint64_t)val << (hi ? 32 : 0);
> +        break;
> +    }
> +    case VPCI_BAR_MEM32:

Please separate non-fall-through case blocks by a blank line.

> @@ -522,6 +582,13 @@ static int add_bar_handlers(struct pci_dev *pdev, bool is_hwdom)
>              if ( rc )
>                  return rc;
>          }
> +        /*
> +         * It is neither safe nor secure to initialize guest's view of the BARs
> +         * with real values which are used by the hardware domain, so assign
> +         * all zeros to guest's view of the BARs, so the guest can perform
> +         * proper PCI device enumeration and assign BARs on its own.
> +         */
> +        bars[i].guest_addr = 0;

I'm afraid I don't understand the comment: Without memory decoding
enabled, the BARs are simple registers (with a few r/o bits).

> --- a/xen/include/xen/pci_regs.h
> +++ b/xen/include/xen/pci_regs.h
> @@ -103,6 +103,7 @@
>  #define  PCI_BASE_ADDRESS_MEM_TYPE_64	0x04	/* 64 bit address */
>  #define  PCI_BASE_ADDRESS_MEM_PREFETCH	0x08	/* prefetchable? */
>  #define  PCI_BASE_ADDRESS_MEM_MASK	(~0x0fUL)
> +#define  PCI_BASE_ADDRESS_MEM_MASK_32	(~0x0fU)

Please don't introduce an identical constant that's merely of
different type. (uint32_t)PCI_BASE_ADDRESS_MEM_MASK at the use
site (if actually still needed as per the comment above) would
seem more clear to me.

Jan



  reply	other threads:[~2021-09-06 14:32 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
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 [this message]
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=1848521d-4179-f5ee-e3af-f4e6738f60e6@suse.com \
    --to=jbeulich@suse.com \
    --cc=Artem_Mygaiev@epam.com \
    --cc=andr2000@gmail.com \
    --cc=bertrand.marquis@arm.com \
    --cc=julien@xen.org \
    --cc=oleksandr_andrushchenko@epam.com \
    --cc=oleksandr_tyshchenko@epam.com \
    --cc=rahul.singh@arm.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=volodymyr_babchuk@epam.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.