IRC channel logs


back to list of 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 :)
<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
<fatal>so i use 'sid main' for any of the hurd installs?
<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?
<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
<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?
<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?
<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>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
<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
<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>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
<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>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>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>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>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)
<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>this is better:
<damo22>biosmem: 000000000000000000:00000000000009f000, available
<damo22>biosmem: 0000000000000f0000:000000000000100000, reserved
<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