On 2025-04-24 06:48, Roger Pau Monné wrote:
On Thu, Apr 24, 2025 at 12:15:17PM +0200, Marek Marczykowski-Górecki wrote:
On Thu, Apr 24, 2025 at 09:59:00AM +0200, Roger Pau Monné wrote:
On Wed, Apr 23, 2025 at 04:51:16PM -0700, Lira, Victor M wrote:
[ 4.570354] Intel(R) 2.5G Ethernet Linux Driver
[ 4.579535] Copyright(c) 2018 Intel Corporation.
[ 4.588898] sky2: driver version 1.30
(XEN) [ 21.644361] d0v3 unable to fixup memory read from 0xfe91000c size 4: -1
This fault is unexpected, according to the identity mappings done at
domain build time:
d0: identity mappings for IOMMU:
[00000000a0, 00000000ff] RW
[0000009bff, 0000009fff] RW
[00000cabc9, 00000cc14c] RW
[00000cc389, 00000cc389] RW
[00000cc70a, 00000cd1fe] RW
[00000ce000, 00000cffff] RW
[00000fd000, 00000fd2ff] RW
The page at 0xfe910 should be covered by the last range above. I
think we have a bug somewhere that unexpectedly unmaps that address.
You sure? 0xfe910 is outside of [00000fd000, 00000fd2ff].
Oh, did and off-by-one when copying, it should have been:
d0: identity mappings for IOMMU:
[00000000a0, 00000000ff] RW
[0000009bff, 0000009fff] RW
[00000cabc9, 00000cc14c] RW
[00000cc389, 00000cc389] RW
[00000cc70a, 00000cd1fe] RW
[00000ce000, 00000cffff] RW
[00000fd000, 00000fd2ff] RW
[00000fd304, 00000febff] RW
Where 0xfe910 is covered by the last range.
This looks like it's okay. You think the somehow the device ranges are
unmapped?
I thought the immediate issue is that the e820 marks these addresses
reserved. That leads to pci_check_bars()->is_memory_hole() returning
false. Stefano's original patch just returned true for non-RAM memory
regions and the device worked. That would leave bar->mem rangeset
empty, IIUC. Not sure how that would remove mappings though.
That also changes the setting of bar->enabled, but I don't immediately
see how that affects mappings.
Regards,
Jason
