ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
amitk has joined #armlinux
rvalue has quit [Ping timeout: 268 seconds]
rvalue has joined #armlinux
mraynal has quit [Remote host closed the connection]
mraynal has joined #armlinux
lain6141 has quit [Read error: Connection reset by peer]
lain6141 has joined #armlinux
apritzel has quit [Ping timeout: 268 seconds]
jclsn has quit [Ping timeout: 256 seconds]
jclsn has joined #armlinux
tiagom has quit [Quit: WeeChat 4.2.1]
rvalue has quit [Ping timeout: 260 seconds]
Saalim_ has quit [Remote host closed the connection]
Saalim has joined #armlinux
lain6141 has quit [Quit: Leaving]
lain6141 has joined #armlinux
hanetzer has joined #armlinux
cbeznea has joined #armlinux
mvaittin has joined #armlinux
monstr has joined #armlinux
gclement has joined #armlinux
bjoto has quit [Remote host closed the connection]
bjoto has joined #armlinux
vingu1 has joined #armlinux
vingu has quit [Ping timeout: 246 seconds]
headless has joined #armlinux
monstr has quit [Ping timeout: 252 seconds]
iivanov has joined #armlinux
iivanov has quit [Client Quit]
iivanov_ has joined #armlinux
mvaittin has quit [Ping timeout: 268 seconds]
lag has quit [Ping timeout: 255 seconds]
lag has joined #armlinux
<manospitsid>
What pte mask should I set to a page if I want it to be Normal Inner Write-Back Outer Write-Back Inner-Shareable?
monstr has joined #armlinux
<ardb>
manospitsid: that depends on the contents of MAIR_ELx
<ardb>
ah hold on
<ardb>
shareable not cacheable
<manospitsid>
mair_elx is for device vs normal memory?
<ardb>
yes that is for cacheability not shareability
<manospitsid>
basically what I want is to take a page from dom0 userspace, and map it with xen to a guest. so I wrote an ioctl that calls get_user_pages_remote() to fetch the struct page for that userspace address (which is an mmap), call page_to_virt() and then __change_memory_common() with __pg_prot(PTE_SHARED)
<manospitsid>
because Xen docs say that memory that must be visible across domains must be set as Normal Inner Write-Back Outer Write-Back Inner-Shareable
<manospitsid>
But PTE_SHARED does not seem to correspond to that
<ardb>
that is the default for RAM
<ardb>
PTE_SHARED is 0b11 which is correct for SH[1:0] at bits 9:8 in the descriptor
<ardb>
page_to_virt() should give you a linear address, which already maps that page with the right attributes
<manospitsid>
yet the guest does not seem to be able to see changes in the shared page, it does some busy polling with atomics in a ring queue waiting for the host to write and times out
<ardb>
you need a cached mapping for SH[] to do anything - are you using the right memory type in the guest?
<ardb>
the stage2 mappings created by the hypervisor may interfere with this as well
<manospitsid>
most probably yeah, because with kvm it "just works"
<manospitsid>
in kvm it uses KVM_SET_USER_MEMORY_REGION
<manospitsid>
ardb: so to sum things up, RAM is Normal Inner Write-Back Outer Write-Back Inner-Shareable by default?
<ardb>
yes
<manospitsid>
hm...
<manospitsid>
xen also has this mapping: #define XENMAPSPACE_dev_mmio 5 /* device mmio region ARM only; the region is mapped in Stage-2 using the Normal Memory Inner/Outer Write-Back Cacheable memory attribute. */
<manospitsid>
but it rejects the pages
<ardb>
manospitsid: that seems appropriate - stage 2 device mappings would supersede stage 1 cacheable mappings
<manospitsid>
would I need to change the pte mask in the host kernel to change the stage 2 mapping?
<ardb>
in summary, guest stage1, host stage1 and hyp stage2 all need to agree that the mapping is cacheable in order for the shareability to work as expected
<ardb>
maz: something to add?
<ardb>
are you sure the guest is looking at the right page?
<manospitsid>
I haven't changed the guest's code, it should work like KVM: the guest sees a PCI BAR as a memory region that can have host memory mapped to it, and it receives messages from the host via virtio which inform it of host allocations with an offset in that PCI BAR.
<manospitsid>
And the guest accesses the memory via the offset
<manospitsid>
so from xen, I map the host region to the physical guest address plus offset
<manospitsid>
I think it's able to read from it because some things are processed without error
sszy has joined #armlinux
mvaittin has joined #armlinux
<ardb>
and the PCI BAR is mapped cacheable?
<manospitsid>
not sure about that, it's hard to follow all the code paths. But I can try manually passing a cached mapping flag from qemu, hold on
headless has quit [Quit: Konversation terminated!]
<manospitsid>
ardb: I suppose there's no way to manually inspect/dump all stage tables and see what's happening under the hood?
<ardb>
you can enable CONFIG_PTDUMP_DEBUGFS and look at /sys/kernel/debug/kernel_page_tables if you know the kernel VA of the BAR
<ardb>
that will give you guest stage1 at least
<ardb>
for hyp stage2 you'll need to do something xen-specific so i cannot help you there
ungeskriptet5 has joined #armlinux
<manospitsid>
yeah makes sense, thanks :)
<manospitsid>
are tables inspectable by JTAG?
ungeskriptet has quit [Ping timeout: 252 seconds]
ungeskriptet5 is now known as ungeskriptet
<ardb>
if you know where they are in physical memory, yes
* mmind00
only realizes how dependend he is on lore, when it's not working - like today ;-)
iivanov_ has quit [Remote host closed the connection]
gclement has quit [Ping timeout: 256 seconds]
headless has joined #armlinux
gclement has joined #armlinux
ungeskriptet5 has joined #armlinux
ungeskriptet has quit [Ping timeout: 256 seconds]
ungeskriptet5 is now known as ungeskriptet
prabhakarlad has quit [Ping timeout: 250 seconds]
prabhakar has quit [Ping timeout: 240 seconds]
luispm has joined #armlinux
Livio has joined #armlinux
mvaittin_ has joined #armlinux
mvaittin has quit [Ping timeout: 260 seconds]
Livio has quit [Ping timeout: 256 seconds]
tiagom has joined #armlinux
headless has quit [Quit: Konversation terminated!]
amitk_ has joined #armlinux
<linusw__>
arnd: there is something funky with ARM Kconfig in v6.9-rc1 I think.
<linusw__>
Symptom: ARCH_IXP4XX is not selectable not in menuconfig, because it depends on CPU_BIG_ENDIAN, and even the ixp4xx_defconfig which has CPU_BIG_ENDIAN set still results in little endian.
<linusw__>
Do you know what may have happened here?
amitk_ has quit [Ping timeout: 268 seconds]
<linusw__>
Hm it only happens with clang+lld I guess that one simply doesn't do big endian?
<linusw__>
Strange though, I can't seem to find where the compiler has a dependency on !CPU_BIG_ENDIAN
<arnd>
linusw__: I'm fairly sure that lld never implemented be32, only be8.
<ardb>
linusw__: CPU_BIG_ENDIAN depends on !LD_IS_LLD
<linusw__>
Yeah it's all my fault for using llvm left and right without testing, sorry
<linusw__>
ardb: there it is!
<linusw__>
thanks guys
<arnd>
I wonder if I misremembered the part about be8 working, or if we could actually change the dependency to only disallow be32
<ardb>
linusw__: you are the first IXP4xx user to complain :-)
amitk_ has joined #armlinux
<linusw__>
ardb: It's because I was testing CFI on everything. I ponder recruiting a thesis worker to fix clang for me ;)
<arnd>
linusw__: how about instead recruiting someone to make ixp4xx work in little-endian again ;-)
<linusw__>
so actually clang emits arm be32 by lld can't link it?
<arnd>
linusw__: yes, it should work with 'make LD=ld.bfd'