[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 2/2] xen/pci: replace call to is_memory_hole to pci_check_bar
- To: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Rahul Singh <rahul.singh@xxxxxxx>
- From: Julien Grall <julien@xxxxxxx>
- Date: Thu, 8 Sep 2022 22:41:07 +0100
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Paul Durrant <paul@xxxxxxx>
- Delivery-date: Thu, 08 Sep 2022 21:41:22 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
Hi Stefano,
On 08/09/2022 21:59, Stefano Stabellini wrote:
+/*
+ * TODO: BAR addresses and Root Complex window addresses are not guaranteed
+ * to be page aligned. We should check for alignment but this is not the
+ * right place for alignment check.
+ */
+static int is_bar_valid(const struct dt_device_node *dev,
+ uint64_t addr, uint64_t len, void *data)
+{
+ struct pdev_bar_check *bar_data = data;
+ unsigned long s = bar_data->start;
+ unsigned long e = bar_data->end;
+
+ if ( (s >= addr) && (e <= (addr + len - 1)) )
+ bar_data->is_valid = true;
"s" and "e" are "unsigned long" while "addr" and "len" are uint64_t. Is
that OK?
Good catch. No, physical address on Arm32 can be up to 40 bits.
Specifically, considering a potential arm32 case, shouldn't "s" and "e"
be uint64_t as well? Which means pdev_bar_check.start and end should be
uint64_t?
They should be paddr_t which will be 64-bit on both arm32 and arm64.
Cheers,
--
Julien Grall
|