Hi,
These patches implement device memory mapping in the arbiter by using the new
gnumach RPC
On Wed, Aug 18, 2021 at 8:43 PM Joan Lledó wrote:
> El 18/8/21 a les 0:02, Sergey Bugaev ha escrit:
> > To me it sounds like libpciaccess should have a Hurd-specific API
> > addition that would let the user get the memory object
>
> That's a solution and can be done. But I'd like to know more abou
On Wed, Aug 18, 2021 at 8:34 PM Joan Lledó wrote:
> El 18/8/21 a les 0:13, Sergey Bugaev ha escrit:
> > you can no longer get the underlying memory object with vm_region ()
>
> How so? reading the docs I understood it does:
>
> https://www.gnu.org/software/hurd/gnumach-doc/Memory-Attributes.html
>
El 18/8/21 a les 0:02, Sergey Bugaev ha escrit:
To me it sounds like libpciaccess should have a Hurd-specific API
addition that would let the user get the memory object
That's a solution and can be done. But I'd like to know more about
vm_region first. It seems it can return the object, and
El 18/8/21 a les 0:13, Sergey Bugaev ha escrit:
you can no longer get the underlying memory object with vm_region ()
How so? reading the docs I understood it does:
https://www.gnu.org/software/hurd/gnumach-doc/Memory-Attributes.html
"The port object_name identifies the memory object associ
On Tue, Aug 17, 2021 at 9:14 PM Joan Lledó wrote:
> > The underlying question is getting the memory object of a given memory
> > range, like vm_region does.
>
> Yes, I see that could be useful. Is vm_region not workig for proxies?
>
> > We need to be careful since we don't want any process to be
On Tue, Aug 17, 2021 at 12:38 AM Samuel Thibault
wrote:
> The root pci-arbiter uses libpciaccess' x86 backend to access PCI
On Tue, Aug 17, 2021 at 9:47 PM Joan Lledó wrote:
> Yes, and the arbiter can play two roles: root arbiter, which uses x86
> module in libpciacces; and nested arbiter, which
Hi,
I'm sorry I can't follow your discussion, I only know about the small
part of the kernel I worked on.
El 16/8/21 a les 23:07, Sergey Bugaev ha escrit:
I don't think I understand enough about the situation. It would help
if you or Joan were to kindly give me some more context :)
Basicall
Hi,
El 16/8/21 a les 20:16, Samuel Thibault ha escrit:
Ok but I meant that the device_map interface already has has an "offset"
Ok, now I got it, yes I think that's better. I'll do that.
Actually I'm thinking that this is just another case of mremap().
I need help on this part, why is mrem
Sergey Bugaev, le mar. 17 août 2021 00:30:34 +0300, a ecrit:
> On Tue, Aug 17, 2021 at 12:10 AM Samuel Thibault
> wrote:
> > Yes, and we want to implement nesting: providing a sub-hurd with a
> > partial view of the PCI space.
>
> Interesting. But I still don't think I understand what the problem
On Tue, Aug 17, 2021 at 12:10 AM Samuel Thibault
wrote:
> Yes, and we want to implement nesting: providing a sub-hurd with a
> partial view of the PCI space.
Interesting. But I still don't think I understand what the problem you
are running into.
boot(1) already emulates Mach devices; it would i
Sergey Bugaev, le mar. 17 août 2021 00:07:29 +0300, a ecrit:
> On Mon, Aug 16, 2021 at 11:43 PM Samuel Thibault
> wrote:
> > Here, possibly proxies can indeed work properly. But please do look at
> > what Joan's situation is to make sure it does.
>
> I don't think I understand enough about the si
On Mon, Aug 16, 2021 at 11:43 PM Samuel Thibault
wrote:
> Here, possibly proxies can indeed work properly. But please do look at
> what Joan's situation is to make sure it does.
I don't think I understand enough about the situation. It would help
if you or Joan were to kindly give me some more co
I'm fine with using proxies if that happens to be optimized.
But I'm sad seeing FIXME, XXX, etc. in various places that people don't
take the time to implement, and they work around them.
This week-end, I at last managed to get rid of the horrible rmh
kludge in glibc that hurt us several times, a
On Mon, Aug 16, 2021 at 10:28 PM Samuel Thibault
wrote:
> Sergey Bugaev, le lun. 16 août 2021 21:59:47 +0300, a ecrit:
> > IMO the proper way to get mremap () is vm_remap ()
>
> But that doesn't answer Joan's need for getting a memory object, to be
> able to put a proxy memory object on top of it
Sergey Bugaev, le lun. 16 août 2021 21:59:47 +0300, a ecrit:
> On Mon, Aug 16, 2021 at 9:17 PM Samuel Thibault
> wrote:
> > > > I'd rather see a
> > > > hurd-specific libpciaccess function to get the pager.
> > >
> > > That's better, but we'd have to add that function in both hurd_pci.c and
> > >
On Mon, Aug 16, 2021 at 9:17 PM Samuel Thibault wrote:
> > > I'd rather see a
> > > hurd-specific libpciaccess function to get the pager.
> >
> > That's better, but we'd have to add that function in both hurd_pci.c and
> > x86_pci.c. I don't like the idea of adding Hurd specific code to x86_module
Joan Lledó, le lun. 16 août 2021 10:53:47 +0200, a ecrit:
> El 5/8/21 a les 1:26, Samuel Thibault ha escrit:
>
> > Is it not possible to avoid having to call memory_object_proxy_valid?
> > maybe better fix device_map into supporting non-zero offset,
>
> I think it'd be a better solution to move t
Hi,
El 5/8/21 a les 1:26, Samuel Thibault ha escrit:
Is it not possible to avoid having to call memory_object_proxy_valid?
maybe better fix device_map into supporting non-zero offset,
I think it'd be a better solution to move the call to
memory_object_proxy_valid() and the start value overwr
Hi
El 9/8/21 a les 19:45, Samuel Thibault ha escrit:
I pushed the start/len start, along with a fix for the length. Could
you proofread that part?
I ran it and works fine
Joan Lledó, le lun. 09 août 2021 23:30:47 +0200, a ecrit:
> El 9/8/21 a les 19:45, Samuel Thibault ha escrit:
> > I pushed the start/len start, along with a fix for the length. Could
> > you proofread that part?
>
> It seems all right for me.
Thanks!
The change definitely deserved a second pair
hi
El 9/8/21 a les 19:45, Samuel Thibault ha escrit:
I pushed the start/len start, along with a fix for the length. Could
you proofread that part?
It seems all right for me. I'll test this and check you other comments
next weekend or the following.
Hello,
Joan Lledó, le dim. 20 juin 2021 14:59:25 +0200, a ecrit:
> http://git.savannah.gnu.org/cgit/hurd/gnumach.git/log/?h=jlledom-memory-object-proxy
I pushed the start/len start, along with a fix for the length. Could
you proofread that part?
Samuel
Joan Lledó, le dim. 20 juin 2021 14:59:25 +0200, a ecrit:
> + /* Find out whther pager is already a proxy */
> + memory_object_proxy_valid (pager, &pager_is_proxy);
>
> + starts[0] = pager_is_proxy ? 0 : region->base_addr;
Is it not possible to avoid having to call memory_object_proxy_valid?
I
Hello,
Joan Lledó, le sam. 19 juin 2021 11:50:09 +0200, a ecrit:
> do you prefer diff patches by email
That's simpler for discussing over the code, yes.
Samuel
Any thoughts on this?
El 19/6/21 a les 11:50, Joan Lledó ha escrit:
Hi Hurd,
I finally got memory mapping working in the pci arbiter. That means any
user with the proper permissions can map the device region files
generated by an arbiter. This is also working for nested arbiters.
For this I
Hi,
El 20/6/21 a les 3:25, Damien Zammit ha escrit:
Hi Joan,
On 19/6/21 7:50 pm, Joan Lledó wrote:
How does that interact with existing pci access for example, I think the AHCI
rump driver
works with DMA so do we need to also adjust the pci-userspace part of
rumpkernel?
I couldn't say, I
Hi Joan,
On 19/6/21 7:50 pm, Joan Lledó wrote:
> I finally got memory mapping working in the pci arbiter. That means any
> user with the proper permissions can map the device region files
> generated by an arbiter. This is also working for nested arbiters.
How does that interact with existing p
Hi Hurd,
I finally got memory mapping working in the pci arbiter. That means any
user with the proper permissions can map the device region files
generated by an arbiter. This is also working for nested arbiters.
For this I made changes in libpciaccess, gnumach, and the Hurd:
pci-arbiter and
29 matches
Mail list logo
