aligned.
> If not, this will expose part of next resource to userspace.
>
> ---
> pci-arbiter/netfs_impl.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/pci-arbiter/netfs_impl.c b/pci-arbiter/netfs_impl.c
> index 4bb5c97a..82e618a7 100644
Proxied memory was not rounded up to page size, causing
error with vm_map'ing the underlying memory.
WARNING: Assumes pci memory resources are at least page aligned.
If not, this will expose part of next resource to userspace.
---
pci-arbiter/netfs_impl.c | 8 +++-
1 file chang
start of all pci memory resources are at least page aligned.
>
> ---
> pci-arbiter/netfs_impl.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/pci-arbiter/netfs_impl.c b/pci-arbiter/netfs_impl.c
> index 4bb5c97a..50e527cf 100644
> ---
Proxied memory was not rounded up to page size, causing
error with vm_map'ing the underlying memory.
WARNING: Could be security risk if assumption is incorrect:
Assumes start of all pci memory resources are at least page aligned.
---
pci-arbiter/netfs_impl.c | 11 ++-
1 file ch
@@ The [[concept|concepts]] of translators creates its own
problems, too:
* [[ftpfs]]
* [[magic]]
* [[mtab]]
+* [[pci-arbiter]]
* [[remap]]
* [[unionfs]]
* [[nfs]]
diff --git a/hurd/translator/pci-arbiter.mdwn b/hurd/translator/pci-arbiter.mdwn
new file mode 100644
index ..359531b7
Applied, thanks!
Flavio Cruz, le ven. 29 déc. 2023 11:12:09 -0500, a ecrit:
> ---
> pci-arbiter/pci-ops.c | 10 +++
> pfinet/iioctl-ops.c | 10 +++
> pfinet/io-ops.c | 64 +--
> pfinet/main.c | 2 +-
> pfinet/p
---
pci-arbiter/pci-ops.c | 10 +++
pfinet/iioctl-ops.c | 10 +++
pfinet/io-ops.c | 64 +--
pfinet/main.c | 2 +-
pfinet/pfinet-ops.c | 4 +--
pfinet/socket-ops.c | 32 +++---
pfinet/tunnel.c | 24
Hello,
Joan Lledó, le mer. 05 juil. 2023 21:38:11 +0200, a ecrit:
> On the other hand, in the past we discussed how to make IO spaces available
> for users through the arbiter [1]. It seems the way to go is adding a new RPC
> that checks for permissions, calls i386_io_perm_create() and returns the
Applied, thanks!
Joan Lledó, le mer. 05 juil. 2023 21:38:12 +0200, a ecrit:
> From: Joan Lledó
>
> * pci-arbiter/netfs_impl.c:
> * get_filemap_region(): Return MACH_PORT_NULL and set errno to EOPNOTSUPP
> when the client tries to map a IO region file.
> ---
> pci-arb
Hello,
Time ago I sent some patches to implement mapping region and ROM files using
mmap(). However, a BAR region can represent either memory or I/O space, and
only the former should be allowed to be mapped, since I/O BARs don't contain
physical memory addresses, but I/O addresses. I attached a sm
From: Joan Lledó
* pci-arbiter/netfs_impl.c:
* get_filemap_region(): Return MACH_PORT_NULL and set errno to EOPNOTSUPP
when the client tries to map a IO region file.
---
pci-arbiter/netfs_impl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/pci-arbiter/netfs_impl.c b/pci-arbiter
On Sat, Jul 01, 2023 at 02:55:48PM +0200, Samuel Thibault wrote:
> acpi actually needs to access PCI, while pci-arbiter will not be making
> use of ACPI, so we need to start acpi first.
>
> Signed-off-by: Samuel Thibault
Reviewed-by: Daniel Kiper
Daniel
acpi actually needs to access PCI, while pci-arbiter will not be making
use of ACPI, so we need to start acpi first.
Signed-off-by: Samuel Thibault
diff --git a/util/grub.d/10_hurd.in b/util/grub.d/10_hurd.in
index b317a4b14..7d1e46391 100644
--- a/util/grub.d/10_hurd.in
+++ b/util/grub.d
rating the fsys_startup call from the server demuxer loop
> into two separate functions that the caller can decide
> when to call.
> ---
> libmachdev/machdev.h | 3 ++-
> libmachdev/trivfs_server.c | 18 ++++++++--
> pci-arb
Applied, thanks!
Damien Zammit, le jeu. 08 sept. 2022 09:31:31 +, a ecrit:
> ---
> pci-arbiter/options.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/pci-arbiter/options.c b/pci-arbiter/options.c
> index 73f74ca3..e0455f41 100644
> --- a/
This fixes a known race condition in bootstrapping by
separating the fsys_startup call from the server demuxer loop
into two separate functions that the caller can decide
when to call.
---
libmachdev/machdev.h | 3 ++-
libmachdev/trivfs_server.c | 18 --
pci-arbiter/main.c
---
pci-arbiter/options.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pci-arbiter/options.c b/pci-arbiter/options.c
index 73f74ca3..e0455f41 100644
--- a/pci-arbiter/options.c
+++ b/pci-arbiter/options.c
@@ -382,7 +382,7 @@ netfs_append_args (char **argz, size_t * argz_len
Joan Lledó, le mar. 16 août 2022 18:44:40 +0200, a ecrit:
> El 16/8/22 a les 18:10, Samuel Thibault ha escrit:
> > ? Any memory allocated by a process will be freed when the process shuts
> > down.
>
> Yes, I know, just wondering if there was a good practice about malloc/free
> in the Hurd.
For g
Hi,
El 16/8/22 a les 18:10, Samuel Thibault ha escrit:
? Any memory allocated by a process will be freed when the process shuts
down.
Yes, I know, just wondering if there was a good practice about
malloc/free in the Hurd.
Joan Lledó, le mar. 16 août 2022 10:38:28 +0200, a ecrit:
> I just though... shouldn't this allocated memory be freed somewhere when the
> arbiter shuts down?
? Any memory allocated by a process will be freed when the process shuts
down.
Samuel
a les 19:37, Samuel Thibault ha escrit:
Mmm, but doesn't libpciaccess allow to map the BAR?Then pci-arbiter
could create a read-only memory proxy of the mapping?
Yes, the arbiter exposes the BAR regions as files called "region0",
"region1", etc. And they can be mapped t
Samuel Thibault, le lun. 15 août 2022 20:20:16 +0200, a ecrit:
> Joan Lledó, le lun. 15 août 2022 20:07:09 +0200, a ecrit:
> > El 15/8/22 a les 19:37, Samuel Thibault ha escrit:
> > > Mmm, but doesn't libpciaccess allow to map the BAR?Then pci-arbiter
> > > could cr
ointer.
But it doesn't provide the ROM physical address, which I would need to
map it in the arbiter space though pci_device_map_range(), like in
http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/pci-arbiter/device_map.c#n41
Joan Lledó, le lun. 15 août 2022 20:07:09 +0200, a ecrit:
> El 15/8/22 a les 19:37, Samuel Thibault ha escrit:
> > Mmm, but doesn't libpciaccess allow to map the BAR?Then pci-arbiter
> > could create a read-only memory proxy of the mapping?
>
> Yes, the arbiter expose
Hi,
El 15/8/22 a les 19:37, Samuel Thibault ha escrit:
Mmm, but doesn't libpciaccess allow to map the BAR?Then pci-arbiter
could create a read-only memory proxy of the mapping?
Yes, the arbiter exposes the BAR regions as files called "region0",
"region1", etc. And t
o for BAR
> regions, but (AFAIK) libpciaccess doesn't provide a way for a client to get
> the ROM physical address, only the ROM size is available.
Mmm, but doesn't libpciaccess allow to map the BAR? Then pci-arbiter
could create a read-only memory proxy of the mapping?
Samuel
Helllo Hurd,
I wrote a patch to allow mapping ROM files from the arbiter file system.
In order to achieve this, the arbiter first allocates and copies the entire
device ROM in its space the first time it's accessed, and returns a proxy to
that memory region when a client requests a ROM filema
Applied, thanks!
Damien Zammit, le dim. 27 févr. 2022 07:52:02 +, a ecrit:
> Perhaps some logic needs to be added to prevent
> concurrent pci accesses by multiple clients
> since some pci commands are non-atomic (?)
Indeed, actually libpciaccess doesn't seem to have any support for
thread saf
(?)
TESTED via booting a rump disk
---
pci-arbiter/main.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/pci-arbiter/main.c b/pci-arbiter/main.c
index ec97856d..0ed5b1c2 100644
--- a/pci-arbiter/main.c
+++ b/pci-arbiter/main.c
@@ -97,20 +97,13 @@ pci_device_open (mach_port_t
On Tue, Feb 22, 2022 at 12:49:03AM +0100, Samuel Thibault wrote:
> Samuel Thibault, le dim. 20 févr. 2022 20:23:03 +0100, a ecrit:
> > This adds pci-arbiter and rumpdisk as bootstrap modules whenever they are
> > available. This opens the path for fully-userland disk suppor
Samuel Thibault, le dim. 20 févr. 2022 20:23:03 +0100, a ecrit:
> This adds pci-arbiter and rumpdisk as bootstrap modules whenever they are
> available. This opens the path for fully-userland disk support.
I forgot:
Signed-off-by: Samuel Thibault
> diff --git a/util/grub.d/10_hurd.
This adds pci-arbiter and rumpdisk as bootstrap modules whenever they are
available. This opens the path for fully-userland disk support.
diff --git a/util/grub.d/10_hurd.in b/util/grub.d/10_hurd.in
index 3663d360e..2ab3a97e6 100644
--- a/util/grub.d/10_hurd.in
+++ b/util/grub.d/10_hurd.in
Joan Lledó, le sam. 08 janv. 2022 13:15:37 +0100, a ecrit:
> From: Joan Lledó
>
> Use a internal array of pointers instead
Applied, thanks!
Samuel
> * pci-arbiter/device_map.h:
> * Update device_map_region() prototype
> * Now it receives an output address as paramet
I updated the comment
From: Joan Lledó
Use a internal array of pointers instead
* pci-arbiter/device_map.h:
* Update device_map_region() prototype
* Now it receives an output address as parameter
* pci-arbiter/device_map.c:
* Update device_map_region() definition to match the new prototype
* Support for
Joan Lledó, le ven. 07 janv. 2022 12:09:55 +0100, a ecrit:
> > Rather >= ?
>
> No, libpciaccess accepts using the legacy method for addrress up to 0x10
> included.
Odd for the base part, but ok :)
But can't se just use the non-legacy mapping in all cases? That'd make
the code simpler.
Samu
Hello,
Joan Lledó, le ven. 07 janv. 2022 12:09:56 +0100, a ecrit:
> - err = pci_device_map_range (device, region->base_addr, region->size,
> - PCI_DEV_MAP_FLAG_WRITABLE, ®ion->memory);
> + /* Use the legacy call for regions under 1MB */
> + if (region->
From: Joan Lledó
Use a internal array of pointers instead
* pci-arbiter/device_map.h:
* Update device_map_region() prototype
* Now it receives an output address as parameter
* pci-arbiter/device_map.c:
* Update device_map_region() definition to match the new prototype
* Support for
Hi,
> Rather >= ?
No, libpciaccess accepts using the legacy method for addrress up to 0x10
included.
> Also, why this address? Putting a comment there would be welcome to explain
> the magic number.
I'm taking the condition from here:
https://gitlab.freedesktop.org/xorg/lib/libpciaccess
Joan Lledó, le mer. 05 janv. 2022 13:08:02 +0100, a ecrit:
> - if (region->memory == 0)
> + if (*addr == 0)
> {
> - err = pci_device_map_range (device, region->base_addr, region->size,
> - PCI_DEV_MAP_FLAG_WRITABLE, ®ion->memory);
> + if (region->base_
From: Joan Lledó
Use a internal array of pointers instead
* pci-arbiter/device_map.h:
* Update device_map_region() prototype
* Now it receives an output address as parameter
* pci-arbiter/device_map.c:
* Update device_map_region() definition to match the new prototype
* Support for
Damien Zammit, le dim. 26 déc. 2021 22:38:56 +1100, a ecrit:
> This locks all memory in bootstrap processes so that
> disk driver dependencies don't get swapped out.
Applied, thanks!
> ---
> pci-arbiter/main.c | 9 +
> rumpdisk/main.c| 8
> 2 files
This locks all memory in bootstrap processes so that
disk driver dependencies don't get swapped out.
---
pci-arbiter/main.c | 9 +
rumpdisk/main.c| 8
2 files changed, 17 insertions(+)
diff --git a/pci-arbiter/main.c b/pci-arbiter/main.c
index 510e7dbc..602a545c 1
From: Joan Lledó
* pci-arbiter/Makefile:
* Add device_map.c to sources
* pci-arbiter/device_map.c:
* pci-arbiter/device_map.h:
* New module for device mapping
* Relies on libpciaccess mapping methods
* pci-arbiter/func_files.c:
* io_region_file(): Use the new
Neat!
:D
Joan Lledó, le dim. 12 déc. 2021 14:08:17 +0100, a ecrit:
> From: Joan Lledó
>
> * pci-arbiter/Makefile:
> * Add device_map.c to sources
> * pci-arbiter/device_map.c:
> * pci-arbiter/device_map.h:
> * New module for device mapping
> * Relies
From: Joan Lledó
* pci-arbiter/Makefile:
* Add device_map.c to sources
* pci-arbiter/device_map.c:
* pci-arbiter/device_map.h:
* New module for device mapping
* Relies on libpciaccess mapping methods
* pci-arbiter/func_files.c:
* io_region_file(): Use the new
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
the issue you're trying to solve?
We are looking for another way to get the pager at [4] and get rid of
that structure.
As I understand it, there's the PCI arbiter, which is a translator
that arbitrates access to PCI, which is a hardware bus that various
devices can be connected to.
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
t think I understand what the problem you
> are running into.
Please look at the actual source code, I'm sorry I just don't have time
to spend on paraphrasing the thorough story.
The root pci-arbiter uses libpciaccess' x86 backend to access PCI, and
x86_pci.c which uses mmap(/dev/me
s; it would itself use
libpciaccess (or the PCI arbiter directly, since it doesn't need
portability?) to get access to the host's devices that are to be
passed through to the subhurd. Then it'd return whatever memory
objects it got from the host's PCI arbiter — or proxies to
hink I understand enough about the situation. It would help
> if you or Joan were to kindly give me some more context :)
>
> As I understand it, there's the PCI arbiter, which is a translator
> that arbitrates access to PCI, which is a hardware bus that various
> devices can b
ive me some more context :)
As I understand it, there's the PCI arbiter, which is a translator
that arbitrates access to PCI, which is a hardware bus that various
devices can be connected to. The hardware devices connected via PCI
are available (to the PCI arbiter) as Mach devices, and in partic
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
elease the pager when dev == NULL? otherwise
pci_device_x86_read_rom would leak the pager?
Yes. Or not passing a pager to device_map() if dev == NULL, is not going
to be used anyway.
I'm a bit afraid of the struct pci_user_data passing between
libpciaccess and pci-arbiter
Me too.
I'
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
the struct pci_user_data passing between
libpciaccess and pci-arbiter: if we ever want to extend the structure
the compatibility will be hard to achieve. I'd rather see a
hurd-specific libpciaccess function to get the pager.
Apart from these, the principles look good to me!
BTW, you can d
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
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
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
El 17/4/21 a les 12:44, Damien Zammit ha escrit:
Can you try rebasing on master and see if you have the same issues?
After merging the last changes the arbiter hangs at startup, so it
doesn't live enough to be killed. I think it's probably another effect
of the same bug in my version of
El 17/4/21 a les 14:14, Samuel Thibault ha escrit:
Do you mean that without your changes there is no pci arbiter kill?
Yes
kernel b/c it's the part I'm less
> competent. I'm attaching a patch with the changes I made on the memory
> object proxy logic. Could you guys take a look and tell me if you see any
> problem?
Do you mean that without your changes there is no pci arbiter kill?
Samuel
Hi,
On 17/4/21 8:12 pm, Joan Lledó wrote:
> I spent too much time on this and still haven't found the problem, need
> some help. I suspect the problem is in the kernel b/c it's the part I'm
> less competent. I'm attaching a patch with the changes I made on the
> memory object proxy logic. Could
Hi,
El 7/3/21 a les 20:33, Samuel Thibault ha escrit:
You could e.g. put mach_prints in glibc's sysdeps/mach/hurd/kill.c's
SIGKILL case.
Possibly better also add a mach_print in hurd/hurdsig.c SIGKILL on
_hurd_orphaned.
I tried but I saw nothing, is it supposed to show the messages in the
c
---
pci-arbiter/netfs_impl.c | 39 ++-
pci-arbiter/pci-ops.c| 2 +-
2 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/pci-arbiter/netfs_impl.c b/pci-arbiter/netfs_impl.c
index b987a0bc..2748c382 100644
--- a/pci-arbiter/netfs_impl.c
+++ b
* pci-arbiter/Makefile
Add machdev lib and simplify
* pci-arbiter/main.c
(pci_device_{open,close,shutdown}): New methods
(netfs_server_func): Thread the demuxer loop
(pcifs_startup): Custom startup method
(main): Use machdev for server and detach worker threads
* pci-arbiter/options.{c,h}
Add disk
* pci-arbiter/Makefile
Add machdev lib and simplify
* pci-arbiter/main.c
(pci_device_{open,close,shutdown}): New methods
(netfs_server_func): Thread the demuxer loop
(pcifs_startup): Custom startup method
(main): Use machdev for server and detach worker threads
* pci-arbiter/options.{c,h}
Add disk
* pci-arbiter/netfs_impl.c
(get_dirents): Fix count and size detection
(netfs_attempt_lookup): Strip trailing slashes and leading dot slashes
* pci-arbiter/pci-ops.c
(check_permissions): Use the overridable method instead
---
pci-arbiter/netfs_impl.c | 41
Hi
El 7/3/21 a les 20:33, Samuel Thibault ha escrit:
Joan Lledó, le dim. 07 mars 2021 20:08:21 +0100, a ecrit:
is not there any process that kills the arbiter after a while of not
being used?
That shouldn't be happening.
and how could I know who is sending the SIGKILL?
How do you notice t
Joan Lledó, le dim. 07 mars 2021 20:08:21 +0100, a ecrit:
> is not there any process that kills the arbiter after a while of not
> being used?
That shouldn't be happening.
> and how could I know who is sending the SIGKILL?
How do you notice that it's a SIGKILL?
You could e.g. put mach_prints in
Hi Hurd,
I've observed how my instance of the pci arbiter receives a SIGKILL
about a minute after start, it could be my fault as I've being messing
around with gnumach, libpciaccess and the arbiter itself, but just to
confirm: is not there any process that kills the arbiter after a
This looks good!
Could you write a commit log?
Samuel
Damien Zammit, le dim. 07 mars 2021 17:39:06 +1100, a ecrit:
> ---
> pci-arbiter/Makefile | 7 +-
> pci-arbiter/main.c| 147 +++---
> pci-arbiter/options.c | 19 +
&g
Damien Zammit, le dim. 07 mars 2021 17:39:05 +1100, a ecrit:
> - if (max_entries < 0)
> -count = dir->dir->num_entries;
> + count = nentries - first_entry;
> + if (max_entries > 0 && count > max_entries)
> +count = max_entries;
It was previously considering max_entries == 0 meaning rea
---
pci-arbiter/main.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/pci-arbiter/main.c b/pci-arbiter/main.c
index 4a10b264..ddea5aa7 100644
--- a/pci-arbiter/main.c
+++ b/pci-arbiter/main.c
@@ -62,7 +62,7 @@ pci_device_open (mach_port_t reply_port
---
pci-arbiter/netfs_impl.c | 42 ++--
pci-arbiter/pci-ops.c| 6 +++---
pci-arbiter/pcifs.c | 18 +++--
3 files changed, 42 insertions(+), 24 deletions(-)
diff --git a/pci-arbiter/netfs_impl.c b/pci-arbiter/netfs_impl.c
index b987a0bc
---
pci-arbiter/Makefile | 7 +-
pci-arbiter/main.c| 147 +++---
pci-arbiter/options.c | 19 +
pci-arbiter/options.h | 8 +++
pci-arbiter/pcifs.h | 3 +
pci-arbiter/startup-ops.c | 2 +
6 files changed, 174 insertions(+), 12
Damien Zammit, le mar. 02 mars 2021 22:41:36 +1100, a ecrit:
> @@ -108,6 +226,11 @@ main (int argc, char **argv)
>if (err)
> error (1, err, "Setting permissions");
>
> + err = pthread_create (&nt, NULL, netfs_server_func, NULL);
> + if (err)
> +error (1, err, "Creating netfs loop t
Damien Zammit, le mar. 02 mars 2021 22:41:33 +1100, a ecrit:
> The only problem I can see is the uid=0 faking the cred by allowing
> netfs to install ports that have no cred at all,
Yes, that's dirty for now, we probably want something cleaner otherwise
we'll have to carry unconfortable tricks.
>
leged_ports(NULL, &dev_master);
> + err = device_open (dev_master, mode, name, devp);
> + *devicePoly = MACH_MSG_TYPE_MOVE_SEND;
> + return D_SUCCESS;
This needs to propagate any error.
> diff --git a/pci-arbiter/netfs_impl.c b/pci-arbiter/netfs_impl.c
> index b
---
pci-arbiter/Makefile | 7 +-
pci-arbiter/main.c| 140 --
pci-arbiter/netfs_impl.c | 39 +++
pci-arbiter/options.c | 19 ++
pci-arbiter/options.h | 8 +++
pci-arbiter/pci-ops.c | 6 +-
pci-arbiter/pcifs.c
Hi all,
This has been a work in progress for some time.
I am hoping it does not need much reworking.
The only problem I can see is the uid=0 faking the cred by allowing
netfs to install ports that have no cred at all, perhaps we need
a new RPC for obtaining a temporary uid=0 cred during bootstr
tatically linked ones in the
> pci/disk servers?
>
> Well, I'd rather first make sure about concurrent pci-arbiter processes
>
> Then
>
> > ahcisata0 channel 0: setting WDCTL_RST failed for drive 0
> > ./noide: line 4: 535871 Segmentation fault (core dumped)
> /extr
ones in the
> pci/disk servers?
Well, I'd rather first make sure about concurrent pci-arbiter processes
Then
> ahcisata0 channel 0: setting WDCTL_RST failed for drive 0
> ./noide: line 4: 535871 Segmentation fault (core dumped)
> /extra/qemu/bin/qemu-system-i386
This is
Hi all,
I got the arbiter to play nice with rumpdisk!
But as soon as you log in it crashes the disk and qemu, I think probably
because there is a mismatched
libpciaccess.so in userspace versus the statically linked ones in the pci/disk
servers?
I'm not sure yet.
--
PCI device_open (mem)
PC
1 - 100 of 263 matches
Mail list logo
