In D4303#90643, @andrew wrote:

Shouldn't we be using the brcm,dma-channel-mask property? It's missing from our dts, but should be added.

In D4009#86771, @wma_semihalf.com wrote:

Ok, I see. I'll try to change the code and use pmap_kextract to check which pages are mapped to avoid parsing of pagetables directly. However I still will need to access some of PMAP structures to prepare fake-pagetables for libkvm... Please let me know if that approach would be acceptable. I don't want to spend much time doing that and then find that everything is wrong :)

In D4114#86645, @royger wrote:

In D4114#86644, @onwahe-gmail-com wrote:

WRT arm intrng I'm working on, I just wonder why the one who wants to remove intr handler cannot wait until PICs are resumed?

When running on Xen all event channels are completely removed on suspend/resume, so we must clear them from the PIC. Waiting for the PIC to be resumed just adds unnecessary complexity and will leave the system in a broken state.

WRT arm intrng I'm working on, I just wonder why the one who wants to remove intr handler cannot wait until PICs are resumed?

In D4009#84903, @wma_semihalf.com wrote:

Ok, thanks for all comments. So... what are we going to do with this patch in general?
I assume that it might be impossible to avoid libkvm+minidump from using PTE tables directly. Yes, we can use a pmap_kextract in minidumps to check if a given page is mapped to the kernel, but we'd still need to create a "fake" pagetables to be compatible with libkvm. What do you think?

In D4009#83798, @jhb wrote:

One thing I would ask: is that you come up with a pmap-independent on-disk format. In my changes in D3341 I make the minidump parsing code machine-independent to support cross-debugging. This means that the libkvm bits in this new world order have to support all possible vmcore formats. If you can only support 1 that would be ideal.

Well, we (Michal and I) do not want to expose internal pmap things (pte definitions) to other files. Note that LPAE has another (third) variant of pte definitions.

Mapped buffers were tested on pandaboard (extern L2 cache) and rpi2 (intergrated L2 cache). Unmapped buffers were tested on rpi2 (quake3).

I'm going to re-test the patch (just to be sure) and then I let you know. ;) However, my testing of unmapped buffers is limited.

There is no need to check for __ARM_ARCH >= 6 in file dedicated for armv6 only. The check should be done in place where such file is included. It's not in the scope of this patch to fix it. However, as a side effect of this little change, this patch is build-able on not armv6 arm platforms too.

In D3617#78699, @onwahe-gmail-com wrote:

The unprivileged instruction encodings are described in code now. The evaluation was moved to separate function to keep abort_handler() well-arranged.

In D3617#78154, @kib wrote:

In D3617#78032, @onwahe-gmail-com wrote:

In fact, I do not know. When the problem was pointed out, I looked at how it was solved before and make the solution same. Maybe someone who remebers the time when the copyin/out functions were created for ARM could tell us the reason.

IMO, testing user provided address for VM_MAXUSER_ADDRESS seems to me easier and more clear. Maybe, once in copyin/out function implementation, they could be made more ARMv6 like. I mean.,maybe, they could be optimised better.

After thinking about this more, I now believe that both your change, and a change to check VM_MAXUSER_ADDRESS, should be made. Your change provides working STRT/LDRT in case it appear to be needed, and it is pity to lost the work done. On the other hand, VM_MAXUSER_ADDRESS would provide a faster and easier to reason about, way to validate accesses. Also, it avoids some undesirable actions in the copyin/out path, like disabling interrupts.

If you have no time to code VM_MAXUSER_ADDRESS change, I could do it.

The unprivileged instruction encodings are described in code now. The evaluation was moved to separate function to keep abort_handler() well-arranged.

In D3617#77934, @kib wrote:

Why do we need the ldrt/strt on FreeBSD, which cause such complications ? The FreeBSD UVA/KVA layout is very simple, the user/kernel is split by VM_MAXUSER_ADDRESS. copyin/copyout should be only allowed to access a buffer which is fully located below or eq VM_MAXUSER_ADDRESS.

Other architectures check that start < start + length and start + length <= VM_MAXUSER_ADDRESS (<= is correct). Then normal ldr/str instructions can be used, and additional handling of faults is not needed.

More info and ideas related to intrng can be found here -> start
The last email in this mailing thread is here -> last

In D3034#61087, @wma_semihalf.com wrote:

I guess treating PPIs are separate IRQs number will cause a huge mess. I'm starting to port fbsd on 96 core armv8 platform and the idea of 1536 vectors wasted for PPIs is outrageous.

Well, I do not like to change bus interface so fast. What about to think of PPI on each core like separate interrupt with its irq number, counter, handler, and handler argument. This way bus_setup_intr will be called only once for PPI on each core. Of course, some coding is needed in nexus and/or interrupt framework.

New version tested on beaglebone and pandaboard again. It looks that everything works (except already mentioned things you want to fix later). However, I just booted to multiuser and checked over dmesgs.

Was this tested with ARM_NEW_PMAP option?

This problem can be fixed by https://reviews.freebsd.org/D2345

Well, here are PANDABOARD boot logs if you are interested.

• kernel without patch
  panda_boot_old.txt5 KBDownload
• kernel with patch
  panda_boot_new.txt7 KBDownload

Firstly, thank you for your hard work.
Can you please update you patch for current? Here are diffs which does not apply:

It's solved correctly in https://reviews.freebsd.org/D2035.

I have just looked at some general interrupt parts of GPIO device to minimalize a little bit changes which would come with new interrupt framework.

Yep, I understand that. Considering difference between old and new pmap-v6, I debugged it this morning. It turned out that many section mappings were created already when I'm typing "procstat -av", but only few ones for currently running processes. Thus I think that the difference is mainly caused by not implemented pmap_copy() in old pmap. I.e. physical mappings are not copied during fork(). And most processes in procstat output are daemons.

Here is the output of "procstat -av" for current pmap-v6. The only mapping of libc marked with S flag is the one of last process - procstat itself. However, it's not marked always. When I type the command immediately after login, it's not marked.

I have tested the patch on pandaboard (armv6) for "make -j4 buildkernel".
I have got these results:
vm.pmap.section.mappings: 0 - not patched kernel
vm.pmap.section.mappings: 1517 - patched kernel

Do enable IPIs on other CPUs. It's IMPLEMENTATION DEFINED if masking IPI on GIC is supported.
Some small optimalization in gic_bind().

Update to address suggestions.

Well, Michal pointed me that it works in currnet. So, the true is that interrupt cells are now decoded in ofw_bus_intr_to_rl(), then again in arm_fdt_map_irq(), and then again in gic_decode_fdt(). So I was wrong. However, doing cpu_to_fdt32() three times on same data is not good too.

In fact, the opposite is correct. In present, the arguments passed to function are already in suitable format. So, all fdt32_to_cpu() calls should be removed. I remembered some debate with Michal about that that only consumer knows what kind of data come to him, so decoding should be done on his side entirely. However, in current tree, the data are decoded in ofw_bus_intr_to_rl().

Hmm, IMHO, this lockless buf ring stuff should be reconsidered much more because of presented issue. It's lockless so there is no way how to get stable snapshot of buf ring variables. A race is always present. Each read value should be considered stale at any moment. Thus what is the real issue here? Is it the order of reading, i.e. prod_tail is pre-read before cons_head? It must be that because in other cases, IMHO, nothing can help. But if it's reordering issue, what else variables are involved? These two reads are very close, but nobody ensures that it could not happen in bigger distance...