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
<manospitsid> thanks again!
cmarinas has quit [Quit: ZNC 1.8.2 - https://znc.in]
cmarinas has joined #armlinux
apritzel has joined #armlinux
* 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'
<linusw__> hehe
amitk_ has quit [Ping timeout: 268 seconds]
mvaittin__ has joined #armlinux
mvaittin_ has quit [Ping timeout: 256 seconds]
mvaittin__ has quit [Ping timeout: 256 seconds]
psydroid has joined #armlinux
qpla has joined #armlinux
headless has joined #armlinux
qpla_ has joined #armlinux
tiagom has quit [Quit: WeeChat 4.2.1]
tiagom has joined #armlinux
rfs613 has quit [Ping timeout: 264 seconds]
qpla has quit [Ping timeout: 268 seconds]
rfs613 has joined #armlinux
ars23 has joined #armlinux
ars23 has quit [Changing host]
ars23 has joined #armlinux
ars23 has quit [Client Quit]
rvalue has joined #armlinux
ars23 has joined #armlinux
ars23 has quit [Changing host]
ars23 has joined #armlinux
rvalue has quit [Ping timeout: 256 seconds]
rvalue has joined #armlinux
rvalue has quit [Ping timeout: 255 seconds]
rvalue has joined #armlinux
rvalue- has joined #armlinux
rvalue has quit [Ping timeout: 252 seconds]
rvalue- is now known as rvalue
<nathanchance> arnd: linusw__: I think we can actually update that dependency to be ‘!LD_IS_LLD || LLD_VERSION >= 170000’: https://github.com/llvm/llvm-project/commit/8cf8956897ce9bca3176c6339077b1ca17b27abc
<nathanchance> I have not actually tested it though
rvalue has quit [Ping timeout: 268 seconds]
rvalue has joined #armlinux
qpla_ has quit [Read error: Connection reset by peer]
qpla has joined #armlinux
rvalue- has joined #armlinux
gclement has quit [Ping timeout: 255 seconds]
rvalue has quit [Ping timeout: 264 seconds]
rvalue- is now known as rvalue
<ardb> this is interesting:
<ardb> """ 1. Instructions are big-endian in relocatable objects but
<ardb> little-endian in executables and shared objects."""
<ardb> modules are relocatable objects too, but I am pretty sure we don't rewrite all the instructions
qpla has quit [Quit: Leaving]
rvalue- has joined #armlinux
rvalue has quit [Ping timeout: 260 seconds]
qpla has joined #armlinux
rvalue- is now known as rvalue
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
<ardb> and looking at the context of that commit, it seems to be adding BE8 support as an alternative to the existing BE32 support
luispm has quit [Quit: Leaving]
rvalue has quit [Ping timeout: 268 seconds]
qpla has quit [Quit: Leaving]
rvalue has joined #armlinux
rvalue has quit [Ping timeout: 272 seconds]
apritzel has quit [Ping timeout: 260 seconds]
ars23 has quit [Ping timeout: 264 seconds]
rvalue has joined #armlinux
monstr has quit [Remote host closed the connection]
rvalue has quit [Ping timeout: 264 seconds]
psydroid has quit [Remote host closed the connection]
ars23 has joined #armlinux
ars23 is now known as Guest1680
psydroid has joined #armlinux
rvalue has joined #armlinux
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
rvalue has quit [Ping timeout: 268 seconds]
hanetzer has quit [Ping timeout: 246 seconds]
qpla has joined #armlinux
qpla has quit [Read error: Connection reset by peer]
qpla has joined #armlinux
apritzel has joined #armlinux
rvalue has joined #armlinux
<linusw__> I'm a bit confused by the commit message as well ... but if you mean >= 170000 can link a BE32 executable I can test it (on hardware)
rvalue has quit [Ping timeout: 252 seconds]
rvalue has joined #armlinux
puranjaymohan has quit [Excess Flood]
puranjaymohan has joined #armlinux
apritzel has quit [Ping timeout: 268 seconds]
apritzel has joined #armlinux
amitk has quit [Ping timeout: 268 seconds]
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #armlinux
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
rvalue has quit [Quit: ZNC - https://znc.in]
headless has quit [Quit: Konversation terminated!]
cbeznea has quit [Ping timeout: 264 seconds]
rvalue has joined #armlinux
gclement has joined #armlinux
Guest1680 has quit [Quit: Leaving]
gclement has quit [Quit: Leaving.]
gclement has joined #armlinux
Livio has joined #armlinux
psydroid has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
Livio has quit [Ping timeout: 264 seconds]
tiagom has quit [Ping timeout: 268 seconds]
sakman_ is now known as sakman