Re: [Xen-devel] [PATCH v5 08/11] vpci/bars: add handlers to map the BARs

[Jan Beulich]

>>> On 12.09.17 at 13:48,  wrote:
> On Tue, Sep 12, 2017 at 04:06:13AM -0600, Jan Beulich wrote:
>> >>> On 12.09.17 at 11:54,  wrote:
>> > On Thu, Sep 07, 2017 at 03:53:07AM -0600, Jan Beulich wrote:
>> >> >>> On 14.08.17 at 16:28,  wrote:
>> >> > +
>> >> > +/*
>> >> > + * The PCI Local Bus Specification suggests writing ~0 to both the 
> high
>> >> > + * and the low part of the BAR registers before attempting to read 
> back
>> >> > + * the size.
>> >> > + *
>> >> > + * However real device BARs registers (at least the ones I've 
>> >> > tried)
>> >> > + * will return the size of the BAR just by having written ~0 to 
>> >> > one 
> half
>> >> > + * of it, independently of the value of the other half of the 
> register.
>> >> > + * Hence here Xen will switch to returning the size as soon as one 
> half
>> >> > + * of the BAR register has been written with ~0.
>> >> > + */
>> >> 
>> >> I don't believe this is correct behavior (but I'd have to play with
>> >> some hardware to see whether I can confirm the behavior you
>> >> describe): How would you place a BAR at, say, 0x1ff0?
>> > 
>> > I don't think it's 'correct' behavior either, but FreeBSD has been
>> > sizing BARs like that, and nobody noticed any issues. I just fixed it
>> > recently:
>> > 
>> > https://svnweb.freebsd.org/base/head/sys/dev/pci/pci.c?r1=312250=321863 
>> 
>> Oh, no, that old code was fine afaict. You have to view the two
>> halves of a 64-bit BAR as completely distinct registers, and
>> sizing of the full BAR can be done either by writing both, then
>> reading both, or reading/writing each half.
> 
> OK, the example in the specification seems to suggest that you should
> first write to both registers, and then read back the values.
> 
>> The problem with the
>> code in the patch here is that you don't treat the two halves as
>> fully separate registers, implying that one half being written with
>> all ones _also_ makes the other half return the sizing value
>> instead of the last written address.
> 
> Right, then I think adding a sizing_hi/sizing_lo field is the right
> answer.

That was my first thought too, but meanwhile I think these flags
are pointless and misleading, and hence should be dropped.
There's really nothing special about those sizing writes: They
simply write a special address, but to the handler this shouldn't
matter. All you need to make sure is that hardwired to zero bits
come back as zero on the following read(s), entirely independent
of what precise value was written (the r/o bits at the bottom of
the first half left aside here, of course).

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 08/11] vpci/bars: add handlers to map the BARs

[Roger Pau Monné]

On Tue, Sep 12, 2017 at 04:06:13AM -0600, Jan Beulich wrote:
> >>> On 12.09.17 at 11:54,  wrote:
> > On Thu, Sep 07, 2017 at 03:53:07AM -0600, Jan Beulich wrote:
> >> >>> On 14.08.17 at 16:28,  wrote:
> >> > +
> >> > +/*
> >> > + * The PCI Local Bus Specification suggests writing ~0 to both the 
> >> > high
> >> > + * and the low part of the BAR registers before attempting to read 
> >> > back
> >> > + * the size.
> >> > + *
> >> > + * However real device BARs registers (at least the ones I've tried)
> >> > + * will return the size of the BAR just by having written ~0 to one 
> >> > half
> >> > + * of it, independently of the value of the other half of the 
> >> > register.
> >> > + * Hence here Xen will switch to returning the size as soon as one 
> >> > half
> >> > + * of the BAR register has been written with ~0.
> >> > + */
> >> 
> >> I don't believe this is correct behavior (but I'd have to play with
> >> some hardware to see whether I can confirm the behavior you
> >> describe): How would you place a BAR at, say, 0x1ff0?
> > 
> > I don't think it's 'correct' behavior either, but FreeBSD has been
> > sizing BARs like that, and nobody noticed any issues. I just fixed it
> > recently:
> > 
> > https://svnweb.freebsd.org/base/head/sys/dev/pci/pci.c?r1=312250=321863 
> 
> Oh, no, that old code was fine afaict. You have to view the two
> halves of a 64-bit BAR as completely distinct registers, and
> sizing of the full BAR can be done either by writing both, then
> reading both, or reading/writing each half.

OK, the example in the specification seems to suggest that you should
first write to both registers, and then read back the values.

> The problem with the
> code in the patch here is that you don't treat the two halves as
> fully separate registers, implying that one half being written with
> all ones _also_ makes the other half return the sizing value
> instead of the last written address.

Right, then I think adding a sizing_hi/sizing_lo field is the right
answer.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 08/11] vpci/bars: add handlers to map the BARs

[Jan Beulich]

>>> On 12.09.17 at 11:54,  wrote:
> On Thu, Sep 07, 2017 at 03:53:07AM -0600, Jan Beulich wrote:
>> >>> On 14.08.17 at 16:28,  wrote:
>> > +
>> > +/*
>> > + * The PCI Local Bus Specification suggests writing ~0 to both the 
>> > high
>> > + * and the low part of the BAR registers before attempting to read 
>> > back
>> > + * the size.
>> > + *
>> > + * However real device BARs registers (at least the ones I've tried)
>> > + * will return the size of the BAR just by having written ~0 to one 
>> > half
>> > + * of it, independently of the value of the other half of the 
>> > register.
>> > + * Hence here Xen will switch to returning the size as soon as one 
>> > half
>> > + * of the BAR register has been written with ~0.
>> > + */
>> 
>> I don't believe this is correct behavior (but I'd have to play with
>> some hardware to see whether I can confirm the behavior you
>> describe): How would you place a BAR at, say, 0x1ff0?
> 
> I don't think it's 'correct' behavior either, but FreeBSD has been
> sizing BARs like that, and nobody noticed any issues. I just fixed it
> recently:
> 
> https://svnweb.freebsd.org/base/head/sys/dev/pci/pci.c?r1=312250=321863 

Oh, no, that old code was fine afaict. You have to view the two
halves of a 64-bit BAR as completely distinct registers, and
sizing of the full BAR can be done either by writing both, then
reading both, or reading/writing each half. The problem with the
code in the patch here is that you don't treat the two halves as
fully separate registers, implying that one half being written with
all ones _also_ makes the other half return the sizing value
instead of the last written address.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 08/11] vpci/bars: add handlers to map the BARs

[Roger Pau Monné]

On Thu, Sep 07, 2017 at 03:53:07AM -0600, Jan Beulich wrote:
> >>> On 14.08.17 at 16:28,  wrote:
> > +
> > +/*
> > + * The PCI Local Bus Specification suggests writing ~0 to both the high
> > + * and the low part of the BAR registers before attempting to read back
> > + * the size.
> > + *
> > + * However real device BARs registers (at least the ones I've tried)
> > + * will return the size of the BAR just by having written ~0 to one 
> > half
> > + * of it, independently of the value of the other half of the register.
> > + * Hence here Xen will switch to returning the size as soon as one half
> > + * of the BAR register has been written with ~0.
> > + */
> 
> I don't believe this is correct behavior (but I'd have to play with
> some hardware to see whether I can confirm the behavior you
> describe): How would you place a BAR at, say, 0x1ff0?

I don't think it's 'correct' behavior either, but FreeBSD has been
sizing BARs like that, and nobody noticed any issues. I just fixed it
recently:

https://svnweb.freebsd.org/base/head/sys/dev/pci/pci.c?r1=312250=321863

Roger.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 08/11] vpci/bars: add handlers to map the BARs

[Jan Beulich]

>>> On 14.08.17 at 16:28,  wrote:
> +static int vpci_modify_bar(struct domain *d, const struct vpci_bar *bar,
> +   bool map)
> +{
> +struct rangeset *mem;
> +struct map_data data = { .d = d, .map = map };
> +int rc;
> +
> +ASSERT(MAPPABLE_BAR(bar));
> +
> +mem = vpci_get_bar_memory(d, bar);
> +if ( IS_ERR(mem) )
> +return PTR_ERR(mem);
> +
> +rc = rangeset_report_ranges(mem, 0, ~0ul, vpci_map_range, );
> +rangeset_destroy(mem);
> +if ( rc )
> +return rc;
> +
> +return 0;
> +}

Please make this simply "return rc".

> +static int vpci_modify_bars(const struct pci_dev *pdev, const bool map)

We don't normally constify non-pointing-to types, and even less so
in function parameters.

> +static uint32_t vpci_cmd_read(struct pci_dev *pdev, unsigned int reg,
> +  const void *data)
> +{
> +uint8_t seg = pdev->seg, bus = pdev->bus;
> +uint8_t slot = PCI_SLOT(pdev->devfn), func = PCI_FUNC(pdev->devfn);
> +
> +return pci_conf_read16(seg, bus, slot, func, reg);
> +}

I can see why you may want to have the slot and func local
variables, but at least seg and bus look pretty pointless to have
here.

> +static void vpci_cmd_write(struct pci_dev *pdev, unsigned int reg,
> +   uint32_t cmd, void *data)
> +{
> +uint16_t current_cmd;
> +uint8_t seg = pdev->seg, bus = pdev->bus;
> +uint8_t slot = PCI_SLOT(pdev->devfn), func = PCI_FUNC(pdev->devfn);
> +
> +current_cmd = pci_conf_read16(seg, bus, slot, func, reg);

Would you mind making this the initializer of the variable?

> +/*
> + * Let the guest play with all the bits directly except for the
> + * memory decoding one.
> + */
> +if ( (cmd ^ current_cmd) & PCI_COMMAND_MEMORY )
> +{
> +/* Memory space access change. */
> +int rc = vpci_modify_bars(pdev, cmd & PCI_COMMAND_MEMORY);
> +
> +if ( rc )
> +{
> +gdprintk(XENLOG_ERR,
> + "%04x:%02x:%02x.%u:unable to %smap BARs: %d\n",
> + seg, bus, slot, func,
> + cmd & PCI_COMMAND_MEMORY ? "" : "un", rc);

Perhaps gprintk(), and perhaps XENLOG_WARNING (depending on
the device it may not be that big of a problem)?

> +return;

I think you should not bail here when it is an unmap that failed -
you'd better disable memory decode in that case.

> +static uint32_t vpci_bar_read(struct pci_dev *pdev, unsigned int reg,
> +  const void *data)
> +{
> +const struct vpci_bar *bar = data;
> +uint32_t val;
> +bool hi = false;
> +
> +ASSERT(bar->type == VPCI_BAR_MEM32 || bar->type == VPCI_BAR_MEM64_LO ||
> +   bar->type == VPCI_BAR_MEM64_HI);
> +
> +if ( bar->type == VPCI_BAR_MEM64_HI )
> +{
> +ASSERT(reg > PCI_BASE_ADDRESS_0);
> +bar--;
> +hi = true;
> +}
> +
> +if ( bar->sizing )
> +val = ~(bar->size - 1) >> (hi ? 32 : 0);

I'm not going to insist on it, but "-bar->size" is certainly easier to
read, and may also produce shorter code (unless the compiler
does the transformation itself anyway).

> +static void vpci_bar_write(struct pci_dev *pdev, unsigned int reg,
> +   uint32_t val, void *data)
> +{
> +struct vpci_bar *bar = data;
> +uint8_t seg = pdev->seg, bus = pdev->bus;
> +uint8_t slot = PCI_SLOT(pdev->devfn), func = PCI_FUNC(pdev->devfn);
> +bool hi = false;
> +
> +if ( pci_conf_read16(seg, bus, slot, func, PCI_COMMAND) &
> + PCI_COMMAND_MEMORY )
> +{
> + gdprintk(XENLOG_WARNING,
> +  "%04x:%02x:%02x.%u: ignored BAR write with memory decoding 
> enabled\n",
> +  seg, bus, slot, func);

I'd again suggest gprintk().

> +return;
> +}
> +
> +if ( bar->type == VPCI_BAR_MEM64_HI )
> +{
> +ASSERT(reg > PCI_BASE_ADDRESS_0);
> +bar--;
> +hi = true;
> +}
> +
> +if ( !hi )
> +val &= PCI_BASE_ADDRESS_MEM_MASK;

This could be the else to the earlier if().

> +
> +/*
> + * The PCI Local Bus Specification suggests writing ~0 to both the high
> + * and the low part of the BAR registers before attempting to read back
> + * the size.
> + *
> + * However real device BARs registers (at least the ones I've tried)
> + * will return the size of the BAR just by having written ~0 to one half
> + * of it, independently of the value of the other half of the register.
> + * Hence here Xen will switch to returning the size as soon as one half
> + * of the BAR register has been written with ~0.
> + */

I don't believe this is correct behavior (but I'd have to play with
some hardware to see whether I can confirm the behavior you
describe): How would you place a BAR at, say, 0x1ff0?

> +if ( val == (hi ? 0x : (uint32_t)PCI_BASE_ADDRESS_MEM_MASK) 

[Xen-devel] [PATCH v5 08/11] vpci/bars: add handlers to map the BARs

[Roger Pau Monne]

Introduce a set of handlers that trap accesses to the PCI BARs and the command
register, in order to snoop BAR sizing and BAR relocation.

The command handler is used to detect changes to bit 2 (response to
memory space accesses), and maps/unmaps the BARs of the device into
the guest p2m. A rangeset is used in order to figure out which memory
to map/unmap. This makes it easier to keep track of the possible
overlaps with other BARs, and will also simplify MSI-X support, where
certain regions of a BAR might be used for the MSI-X table or PBA.

The BAR register handlers are used to detect attempts by the guest to size or
relocate the BARs.

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
Changes since v4:
 - Expand commit message to mention the reason behind the usage of
   rangesets.
 - Fix comment related to the inclusiveness of rangesets.
 - Fix off-by-one error in the calculation of the end of memory
   regions.
 - Store the state of the BAR (mapped/unmapped) in the vpci_bar
   enabled field, previously was only used by ROMs.
 - Fix double negation of return code.
 - Modify vpci_cmd_write so it has a single call to pci_conf_write16.
 - Print a warning when trying to write to the BAR with memory
   decoding enabled (and ignore the write).
 - Remove header_type local variable, it's used only once.
 - Move the read of the command register.
 - Restore previous command register value in the exit paths.
 - Only set address to INVALID_PADDR if the initial BAR value matches
~0 & PCI_BASE_ADDRESS_MEM_MASK.
 - Don't disable the enabled bit in the expansion ROM register, memory
   decoding is already disabled and takes precedence.
 - Don't use INVALID_PADDR, just set the initial BAR address to the
   value found in the hardware.
 - Introduce rom_enabled to store the status of the
   PCI_ROM_ADDRESS_ENABLE bit.
 - Reorder fields of the structure to prevent holes.

Changes since v3:
 - Propagate previous changes: drop xen_ prefix and use u8/u16/u32
   instead of the previous half_word/word/double_word.
 - Constify some of the paramerters.
 - s/VPCI_BAR_MEM/VPCI_BAR_MEM32/.
 - Simplify the number of fields stored for each BAR, a single address
   field is stored and contains the address of the BAR both on Xen and
   in the guest.
 - Allow the guest to move the BARs around in the physical memory map.
 - Add support for expansion ROM BARs.
 - Do not cache the value of the command register.
 - Remove a label used in vpci_cmd_write.
 - Fix the calculation of the sizing mask in vpci_bar_write.
 - Check the memory decode bit in order to decide if a BAR is
   positioned or not.
 - Disable memory decoding before sizing the BARs in Xen.
 - When mapping/unmapping BARs check if there's overlap between BARs,
   in order to avoid unmapping memory required by another BAR.
 - Introduce a macro to check whether a BAR is mappable or not.
 - Add a comment regarding the lack of support for SR-IOV.
 - Remove the usage of the GENMASK macro.

Changes since v2:
 - Detect unset BARs and allow the hardware domain to position them.
---
 xen/drivers/vpci/Makefile |   2 +-
 xen/drivers/vpci/header.c | 453 ++
 xen/include/xen/vpci.h|  29 +++
 3 files changed, 483 insertions(+), 1 deletion(-)
 create mode 100644 xen/drivers/vpci/header.c

diff --git a/xen/drivers/vpci/Makefile b/xen/drivers/vpci/Makefile
index 840a906470..241467212f 100644
--- a/xen/drivers/vpci/Makefile
+++ b/xen/drivers/vpci/Makefile
@@ -1 +1 @@
-obj-y += vpci.o
+obj-y += vpci.o header.o
diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
new file mode 100644
index 00..9b44c8441a
--- /dev/null
+++ b/xen/drivers/vpci/header.c
@@ -0,0 +1,453 @@
+/*
+ * Generic functionality for handling accesses to the PCI header from the
+ * configuration space.
+ *
+ * Copyright (C) 2017 Citrix Systems R
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see .
+ */
+
+#include 
+#include 
+#include 
+
+#define MAPPABLE_BAR(x) \
+((x)->type == VPCI_BAR_MEM32 || (x)->type ==