IRC channel logs

<damo22>youpi: i want to mmap the mem device at an offset, if i use device_open(mem) do i need to use device_map? that will give me a memory_object_t but im not sure what to do with it

<damo22>i think i need to call device_map and then vm_map it

<youpi>damo22: you can device_map then vm_map, yes, or just mmap(open("/dev/mem"))

<damo22>thanks, i figured it out, but we cant use /dev/mem for this

<damo22> /dev does not exist during bootstrap :)

<youpi>indeed

<fatal>is there am easy way to find a sources.list for gnu/hurd?

<youpi>the debian hurd ports webpage

<youpi>the configuration part shows the proper sources.list to use

<damo22>youpi: I want to know if this branch is feasible to use for upstreaming acpica work. We need to break out acpica code into a separate library but i dont know if what i have is upstreamable http://git.zammit.org/hurd-sv.git/log/?h=acpica-nothread

<fatal>so i use 'sid main' for any of the hurd installs?

<AlmuHS>fatal: https://www.debian.org/ports/hurd/hurd-install

<AlmuHS>" Installing More Packages " section

<youpi>damo22: I don't think we want to copy over libacpica

<youpi>rather just link against it

<damo22>yes, the plan is to remove ./libacpica

<damo22>but the separation of the code into hurd component and libapcica component is something i want to adjust the boundaries

<damo22>i had to put some of the structs into libacpica/acpi_init.h

<damo22>because the root table can only be found via a custom lookup

<damo22>but the question is, would acpica-tools (or whatever the project is), accept the extra code we have written?

<damo22>they would need to provide the libacpica.a library

<youpi>what extra code is there?

<damo22>acpi_init.{c,h}

<youpi>if it's just portability glue, that shouldn't be a problem

<youpi>building a .a library shouldn't be a problem either

<damo22>and the acgnu.h and acgnuex.h

<youpi>acgnu* is meant to be written such way

<youpi>so there's no way they would refuse it

<damo22>right

<youpi>acpi_init as it is is more questionable since it doesn't actually implement the thread function

<youpi>is there a reason for that?

<youpi>why not just using the pthread interfaceS?

<damo22>i got stuck with pthread locks and semaphores

<youpi>it does make sense for such kind of projects to have a posix target

<youpi>that just uses posix standard functions

<damo22>so i made it single threaded

<damo22>we really only need the irq function currently, but we need the whole aml parser

<damo22>to extract the irq

<damo22>and perhaps the sleep states

<damo22>acpi_init has hurd specific glue

<youpi>that can be pushed as os-specific functions

<youpi>just more acpi_os_* functions

<youpi>i.e. the generic posix file provides most implementations, provided that the OS port provides the most low-level functions

<damo22>i see, do i put the hurd ones in a separate file?

<youpi>yes

<damo22>if the generic posix file provides a working implementation, do i call it?

<youpi>not sure to understand the question

<youpi>I mean, why wouldn't I just answer "yes" ?

<damo22>some will need customisation

<youpi>what kind of?

<damo22>eg, the root table finder

<damo22>needs a custom implementation

<youpi>is it os-specific?

<damo22>yes

<youpi>how so?

<youpi>I mean, accessing memory, sure

<youpi>but parsing tables?

<damo22>yes the default table parser tries to use 16 bit paragraph address

<damo22>and fails on hurd

<youpi>what do you mean by "16bit paragraph address" ?

<damo22>let me find the line

<youpi>if it's just addresses that should be multiplied by 16, a generic posix version would just implement the byte-byte address

<youpi>and that's not hurd-specific at all

<youpi>only accessing the memory is really os-specific

<damo22>libacpica/tbxfroot.c:136

<damo22>i cant seem to use that function because of its memory access method

<youpi>if it's just that the acpi_os_map_memory parameter is in paragraph unit

<youpi>then just make that function respect that

<youpi>and that'll work

<youpi>completely independently of the OS

<damo22>hmm ok

<damo22>i think its in different units depending on the address

<youpi>? no parameter to tell how it's suppose dto be?

<youpi>I'm really surprised

<damo22>yeah

<youpi>please show an example

<youpi>possibly that's just misunderstanding

<youpi>also, I'd *really* recommend just discussing such matter with upstram

<youpi>here I'm just provding guesswork

<damo22>ok

<youpi>upstream does know what they liek

<youpi>discussing with me is more or less moot

<youpi>I can provide advice

<youpi>but in the end it's upstream that manages

<damo22>acpi_os_map_memory(0x40e, 2)

<damo22>then it multiplies that address by 16

<youpi>where?

<damo22>tbfxroot.c:136

<youpi>possibly it's just a bug in libacpici

<youpi>no, I mean where does it multiply it by 16?

<youpi>ah, just above

<youpi>then what is the problem

<youpi>acpi_os_unmap_memory takes the address in bytes there

<youpi>so I don't see the problem

<damo22>is the EBDA pointer stored in paragraph units at address 0x40e?

<youpi>apparently it's in paragraph yes

<damo22>im confused why the acpi table lookup fails with their function then

<damo22>let me try with my new memory map function

<damo22>yes it fails

<damo22>#2 0x08054b50 in acpi_tb_scan_memory_for_rsdp (

<damo22> start_address=0x1006c00 <error: Cannot access memory at address 0x1006c00>, length=1024)

<damo22> at ../../libacpica/tbxfroot.c:243

<damo22>#3 0x08054cbf in acpi_find_root_pointer (table_address=0x1001d48) at ../../libacpica/tbxfroot.c:157

<damo22>i think the mapping does not extend far enough with their function and they assume they have access to it

<damo22>youpi: vm_map assigned a virtual address that is inaccessible

<damo22>vm_map (mach_task_self (), &vaddr, size + pa_offset, 0, 1, memobj, 0, 0, VM_PROT_READ | VM_PROT_WRITE, VM_PROT_READ | VM_PROT_WRITE, VM_INHERIT_SHARE);

<damo22>235 return (void *)(vaddr + pa_offset);

<damo22>(gdb) x vaddr

<damo22>0x1014000: Cannot access memory at address 0x1014000

<damo22>is mask 0 correct?

<damo22>does device_map ( ) offset need to be page aligned?

<damo22>something is fishy with vm_map on phys=654336

<damo22>(even after page aligning it)

<youpi>damo22: yes, mask 0 is correct

<youpi>use vminfo to check whether the address is correct

<youpi>strictly speaking, "Cannot access memory" doesn't mean the address is incorrect

<youpi>it can also mean that the kernel refused to map the page

<youpi>e.g. because memmmap returned -1

<youpi>is that address really not marked as available in e820 ?

<youpi>really, put prints here and there to check what is actually happening

<youpi>that's how I usually proceed and it's terribly efficient

<youpi>making hypotheses etc. takes a long time while just putting a print, rebuild, reboot, check, you have the answer immediately

<damo22>is it possible to device_map and vm_map an address that is in a hole in e820?

<youpi>that should be possible yes

<youpi>the test in memmmap is supposed to implement that

<youpi>if that doesn't work it's a bug, and use prints to check what actually hppens

<youpi>really, use prints

<damo22>ok

<youpi>in the dmesg I have with qemu:

<youpi>biosmem: 00000000000009fc00:0000000000000a0000, reserved

<youpi>so 9efc00 is supposed to be reserved

<youpi>now it's not page aligned

<youpi>so possibly the allocator erroneously rounds biosmem: 000000000000000000:00000000000009fc00, available

<youpi>and we should rather modify the e820 table to round down the reserved part

<youpi>so that memmmap knows we won't ever use page 9f000

<youpi>again, print print print

<damo22>XXX: addr in available range

<damo22>XXX: Cant map this, its marked as available

<youpi>check the range

<youpi>most probably it's the page-round concern

<youpi>mini-os implemented such rounding only very late, to proplerly support pvh :)

<damo22>XXX: addr(0x9f000) in available range [0x0, 0x9fc00]

<damo22>XXX: Cant map this, its marked as available

<damo22>biosmem: 000000000000000000:00000000000009fc00, available

<damo22>is the memmmap supposed to allow mappings for "available" e820?

<youpi>no

<youpi>but biosmem is supposed to round boundaries

<youpi>since the 9f000 page is not supposed to ever be used

<luckyluke>about mig and 32-bit rpc on 64 bit gnumach, it seems one big cleanup would be the assumption that on kernel side ipc_port_t (actually struct ipc_port*) has the same representation as mach_port_t. I see this is encoded in mig itself, so it should be moved to the .defs files adding an explicit conversion helper, instead of a cast. Does this make sense? Or is this assumption required also for something else?

<luckyluke>btw, this would just add the flexibility of defining data types indipendently from the specific representation of pointers

<youpi>luckyluke: I'm not sure to understand

<youpi>in the message, a port is just the number

<youpi>not the pointer

<luckyluke>In mig there is special treatment for mach_port_t when generating the kernel-side code. It basically relies on the fact that mach_port_t can be converted to ipc_port_t with a cast

<youpi>?

<youpi>it's rather supposed to look up the port number

<youpi>to turn that into a kernel pointer

<luckyluke>That's what I would like to implement, but currently the conversion is done directly between these two types

<youpi>there's something else

<youpi>there's no way userland could be passing kernel poniters

<youpi>that would be a huge security issue

<youpi>it's really port numbers

<youpi>and there's something somewhere that converts from port number to kernel pointer

<youpi>it's probably ipc_kmsg_copyin_body that does the port number / kernel pointer conversion

<youpi>in the if (is_port) part

<youpi>("name" designates the port number)

<luckyluke>ah, I didn't see that part yet, thanks for the tip

<luckyluke>here it seems that the port name (as seen by userspace) is overwritten with the kernel port, which is then casted to ipc_port_t in the mig-generated code

<luckyluke>so this also would imply that mach_port_t needs to be large enough to hold a kernel pointer

<luckyluke>unless I'm missing something on the structure conversion...

<youpi>that can answer a question we were having: how large mach_port should be on 64bit

<youpi>making it 64bit would simplify using the existing code

<luckyluke>it would also require to re-compile the existing 32-bit userland with the new mach headers, and probably enhance mig to handle this mixed case

<youpi>?

<youpi>I mean 64bit for 64bit kernel

<youpi>not for 32bit userland

<youpi>and we'd use a conversion layer of course

<youpi>we'll have to have one anyway

<luckyluke>do you mean to have mach_port_t of different sizes for userland and kernel?

<youpi>yes

<youpi>just like we'll have different sizes for various types anyway

<youpi>e.g. vm_offset_t etc.

<luckyluke>uhm, at what layer should this conversion happen? in ipc_kmsg_copyin_body()?

<youpi>or before, or after, I don't know

<luckyluke>I suppose this also means dealing with the different structure padding

<youpi>one has to have a look at the whole picture to see how well it fits

<youpi>(there's also the copyout for the other way)

<youpi>yes

<damo22>youpi: Do you think i need to truncate the start and end offsets in biosmem_map_build() ?

<damo22>what is biosmem_map_build_simple() for? it looks like a memory map that has only 2 entries

<damo22>biosmem: 000000000000000000:00000000000009f000, available

<damo22>biosmem: 00000000000009f000:00000000000009f400, reserved

<damo22>biosmem: 0000000000000f0000:000000000000100000, reserved

<damo22>no

<damo22>this is better:

<damo22>biosmem: 000000000000000000:00000000000009f000, available

<damo22>biosmem: 0000000000000f0000:000000000000100000, reserved

<damo22>fixed!

<Pellescours>yay, and the vm_map now works for acpi tables ?

<damo22>yea without custom lookup

<damo22>im going to fix up my branch and force push

<damo22>woot i was able to use protonmail bridge to push patches

<youpi>damo22: the simple build is for the case when bios doesn't provide a e820 table

<youpi>and only the legacy bios information

<damo22>oh

IRC channel logs

2022-02-12.log