[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH gnumach] Add vm_pages_phys
From: |
Sergey Bugaev |
Subject: |
Re: [PATCH gnumach] Add vm_pages_phys |
Date: |
Wed, 31 Jan 2024 19:35:18 +0300 |
On Wed, Jan 31, 2024 at 2:44 PM Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > I see you used kmem_alloc_pageable() over kmem_alloc() that I
> > suggested. Why is that?
>
> Because I have seen it used so in other places,
> notably host_ipc_marequest_info, host_slab_info,
> host_virtual_physical_table_info
Yes, exactly because those functions don't hold VM locks :)
Look at mach_vm_object_pages_phys()/_mach_vm_object_pages() for an
example function that does (and actually does something close to what
you're implementing here?)
> > My understanding is the point of kmem_alloc()
> > is to be used in cases like this, when you don't want the routine
> > itself to fault while holding locks on VM objects/maps.
>
> That's quite subtle. Is that documented somewhere?
I don't think it is. There are a couple of /* can't fault while we
hold locks */ comments in ipc/mach_port.c, but there they do things
slightly differently: they allocate memory with vm_allocate(), and
then wire it with vm_map_pageable(). I don't know what the differences
between doing that vs kmem_alloc() are. There's also
kmem_alloc_wired() which does a very similar thing; the difference
appears to be that kmem_alloc_wired() uses kernel_object, while
kmem_alloc() creates a fresh anonymous VM object; apparently the
former prevents the allocated memory from being copied with
vm_map_copyin(), which means that memory basically cannot be sent in a
message. But I don't really understand how this works in detail.
Sergey