gnumach: [PATCH] - irq as a mach device

24cff643b5ba66c39f340253a3ca210ab Mon Sep 17 00:00:00 2001 From: Damien Zammit Date: Sat, 27 Jun 2020 22:57:51 +1000 Subject: [PATCH] irq: Refactor interrupt handling as a mach device --- Makefrag.am | 4 +- device/ds_routines.c | 62 +++ de

Re: gnumach: [PATCH] - irq as a mach device

Hi, On 3/7/20 7:29 pm, Damien Zammit wrote: > I have tried to refactor the RPCs but I'm not sure how to make it a > fully-fledged "irq" mach device. I have a new version of my patch that should make this a proper mach device and I fixed the RPCs for ds_device_intr_

Re: Problems in Debian GNU/Hurd with Xorg and GCC

Hey Almudena, On 4/7/20 1:49 am, Almudena Garcia wrote: > I'm following this guide, simply Xorg seems doesn't works in my machine > https://www.debian.org/ports/hurd/hurd-install Are you running coreboot or factory bios on your T60? I think coreboot native gfx does *not* support VBE graphics ext

Re: gnumach: [PATCH] - irq as a mach device

RPC. It is required for DMA. How should I proceed with it? Do I make it an RPC on the "mem" device only? See attached for revised patch. Thanks, Damien >From 072658e23208b4337f5d43c11244333e9798bdb2 Mon Sep 17 00:00:00 2001 From: Damien Zammit Date: Sun, 5 Jul 2020

Re: gnumach: [PATCH] - irq as a mach device

On 5/7/20 11:50 am, Damien Zammit wrote: > One thing that is missing from this patch is the "vm_allocate_contiguous" RPC. > It is required for DMA. How should I proceed with it? Do I make it an RPC > on the > "mem" device only? See attached for first attemp

Re: gnumach: [PATCH] - irq as a mach device

spect > alignment and release unused pages accordingly. I think I have fixed vm_allocate_contiguous, see attached second patch. I still need to test patch 0002 with netdde/rump, for instance. Damien >From 0ab926aac6ca96169b74f337f70da8229109e45f Mon Sep 17 00:00:00 2001 From: Damien Zam

Re: Sound support for Hurd and shortfalls of ALSA

On 29/6/20 7:52 pm, Ricardo Wurmus wrote: > What is the API provided to user applications? Or would it be enough to > add support for this new API to JACK, so that all audio applications > using JACK automatically benefit from this? I'm not sure if it may be best to use the NetBSD implementation

Re: gnumach: [PATCH] - irq as a mach device

thought I could hack it but it doesn't work so I've left physical alignment as a TODO as well as pmin != 0, but included it in the RPC itself so it can be committed even if it doesn't do anything yet. Please see attached 2 new patches. Thanks, Damien >From adfad36aab3bb1f

hurd - [PATCH]: libddekit

Hello, I compiled and installed the latest master-user_level_drivers-debian branch of gnumach, (which has both fallback and new RPCs for interrupt handling). Using the attached patch, I was able to build libddekit.a and link with netdde. This enabled the new user-land driver path to work for net

libpciaccess, rumpkernel, hurd: [PATCH] - working rumpdisk support for rootfs

Hello, These patches for three different repos make rumpdisk expose a block device and boot off it. I have tried to keep the patches separate for now, but easily can be squashed. There are two known issues with this: 1. The server using libpciaccess currently needs to be faked with netfs_serv

[PATCH 1/5] libmachdev: Remove deviceUser, this lib is a deviceServer

libmachuser provides what we need --- libmachdev/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libmachdev/Makefile b/libmachdev/Makefile index 1f15ebe9..db275cce 100644 --- a/libmachdev/Makefile +++ b/libmachdev/Makefile @@ -19,13 +19,13 @@ dir := libmachdev m

[PATCH 3/5] Makeconf: Add mach_i386 defs

--- Makeconf | 4 1 file changed, 4 insertions(+) diff --git a/Makeconf b/Makeconf index f68ff6e3..b4a5dbd5 100644 --- a/Makeconf +++ b/Makeconf @@ -582,15 +582,19 @@ mach_defs_names = bootstrap exc mach mach4 \ gnumach \ task_notify \ +mach_i386_defs_names = mach_i386 mac

[PATCH 4/5] libmachdev: Implement S_i386_io_perm_create

--- libmachdev/Makefile| 2 +- libmachdev/trivfs_server.c | 56 ++ 2 files changed, 57 insertions(+), 1 deletion(-) diff --git a/libmachdev/Makefile b/libmachdev/Makefile index db275cce..15b98cf1 100644 --- a/libmachdev/Makefile +++ b/libmachdev/Makefi

[PATCH 2/5] libmachdev: Add resume for bootstrap server

--- libmachdev/ds_routines.c | 19 -- libmachdev/machdev.h | 5 +- libmachdev/trivfs_server.c | 135 - 3 files changed, 131 insertions(+), 28 deletions(-) diff --git a/libmachdev/ds_routines.c b/libmachdev/ds_routines.c index da5e47e2..d5451a92 1

[PATCH 5/5] rumpdisk: Use bootstrap resume of fs task in machdev

--- rumpdisk/block-rump.c | 38 + rumpdisk/main.c | 95 +-- 2 files changed, 123 insertions(+), 10 deletions(-) diff --git a/rumpdisk/block-rump.c b/rumpdisk/block-rump.c index 42ace30d..94df9be8 100644 --- a/rumpdisk/block-rump.c +++

rumpkernel: [PATCH 1/3] Use -fcommon in HOST_CFLAGS for GCC 10 compat

--- debian/rules | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/debian/rules b/debian/rules index 6862a30f..c9851d1e 100755 --- a/debian/rules +++ b/debian/rules @@ -6,8 +6,9 @@ export SHELL = bash #export DH_VERBOSE=1 DEB_HOST_ARCH_OS ?= $(dpkg-architecture -qDEB_HOS

rumpkernel: [PATCH 2/3] pci-userspace: Use new mach IRQ device RPC interfaces

--- debian/patches/machirqdev.diff | 173 + debian/patches/series | 1 + 2 files changed, 174 insertions(+) create mode 100644 debian/patches/machirqdev.diff diff --git a/debian/patches/machirqdev.diff b/debian/patches/machirqdev.diff new file mode 1006

rumpkernel: [PATCH 3/3] Add correct build-deps in debian/control

--- debian/control | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/debian/control b/debian/control index ea63d25c..3cce3aac 100644 --- a/debian/control +++ b/debian/control @@ -5,8 +5,9 @@ Build-Depends: debhelper (>= 8.0.0), autotools-dev, zlib1g-dev, - libpciaccess

[PATCH v2 2/5] libmachdev: Add resume for bootstrap server

--- libmachdev/ds_routines.c | 15 +++- libmachdev/machdev.h | 5 +- libmachdev/trivfs_server.c | 154 - 3 files changed, 148 insertions(+), 26 deletions(-) diff --git a/libmachdev/ds_routines.c b/libmachdev/ds_routines.c index da5e47e2..53e0c080 100

[PATCH v2 3/5] Makeconf: Add mach_i386 defs

--- Makeconf | 4 1 file changed, 4 insertions(+) diff --git a/Makeconf b/Makeconf index f68ff6e3..b4a5dbd5 100644 --- a/Makeconf +++ b/Makeconf @@ -582,15 +582,19 @@ mach_defs_names = bootstrap exc mach mach4 \ gnumach \ task_notify \ +mach_i386_defs_names = mach_i386 mac

[PATCH v2 4/5] libmachdev: Implement S_i386_io_perm_create

--- libmachdev/Makefile| 2 +- libmachdev/trivfs_server.c | 60 ++ 2 files changed, 61 insertions(+), 1 deletion(-) diff --git a/libmachdev/Makefile b/libmachdev/Makefile index db275cce..15b98cf1 100644 --- a/libmachdev/Makefile +++ b/libmachdev/Makefi

[PATCH v2 5/5] rumpdisk: Use bootstrap resume of fs task in machdev

--- rumpdisk/block-rump.c | 39 ++ rumpdisk/main.c | 95 +-- 2 files changed, 123 insertions(+), 11 deletions(-) diff --git a/rumpdisk/block-rump.c b/rumpdisk/block-rump.c index 42ace30d..474852cd 100644 --- a/rumpdisk/block-rump.c +++

[PATCH] libmachdev: Introduce startup notification for clean rumpdisk shutdown

This still does not work. I get a freeze on reboot command: root@zamhurd:~# reboot INIT: Switching to runlevel: 6 INIT: Sending processes configured via /etc/inittab the TERM signal root@zamhurd:~# Broadcast message from root@zamhurd (console) (Sun Jul 25 16:32:28 1999): The system is going down

[PATCH 1/2] libdiskfs: Refactor fsys_startup invokation for bootstrapping

--- libdiskfs/boot-start.c | 11 +++ libdiskfs/init-startup.c | 64 +--- 2 files changed, 52 insertions(+), 23 deletions(-) diff --git a/libdiskfs/boot-start.c b/libdiskfs/boot-start.c index 29b8acc6..4fbd62c5 100644 --- a/libdiskfs/boot-start.c +++ b/lib

[PATCH 2/2] libmachdev: Introduce startup notification for clean rumpdisk shutdown

This patch almost provides shutdown notification for rumpdisk, but fails at getproc() which returns 0, I struggle to figure out why. Currently: Hurd server bootstrap: ext2fs[part:2:device:/dev/wd0] ... WARNING: machdev not registered for shutdown --- libmachdev/Makefile | 6 +-- l

[PATCH 2/4] diskfs: Don't deallocate if dotdot is null in fsys-getroot.c

--- libdiskfs/fsys-getroot.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libdiskfs/fsys-getroot.c b/libdiskfs/fsys-getroot.c index 735f359a..2c0d15dd 100644 --- a/libdiskfs/fsys-getroot.c +++ b/libdiskfs/fsys-getroot.c @@ -194,7 +194,8 @@ diskfs_S_fsys_getroot (struct dis

[PATCH 4/4] rumpdisk: Install as translator when bootstrapping

NB: Not sure why this seems to have no effect on /dev/rumpdisk Am I setting the translator on the wrong port? --- rumpdisk/main.c | 29 + 1 file changed, 29 insertions(+) diff --git a/rumpdisk/main.c b/rumpdisk/main.c index 27a8ea38..68fb8be2 100644 --- a/rumpdisk

[PATCH 1/4] diskfs: Add RPC for fsys_init to bootstrap if present

--- libdiskfs/boot-start.c | 13 + 1 file changed, 13 insertions(+) diff --git a/libdiskfs/boot-start.c b/libdiskfs/boot-start.c index 29b8acc6..fa59e1b2 100644 --- a/libdiskfs/boot-start.c +++ b/libdiskfs/boot-start.c @@ -518,7 +518,9 @@ diskfs_S_fsys_init (struct diskfs_control *pt,

[PATCH 3/4] libmachdev: Introduce startup notification for clean rumpdisk shutdown

NB: Reboot still hangs on diskfs_S_startup_dosync() even though that times out and then rumpdisk shuts down cleanly. --- libmachdev/Makefile | 6 +-- libmachdev/ds_routines.c | 10 libmachdev/machdev-device_emul.h | 1 + libmachdev/machdev.h | 1 + lib

[PATCH v2] libmachdev: Introduce startup notification for clean rumpdisk shutdown

--- libmachdev/Makefile | 4 +- libmachdev/ds_routines.c | 10 +++ libmachdev/machdev-device_emul.h | 1 + libmachdev/machdev.h | 1 + libmachdev/trivfs_server.c | 116 ++- libmachdev/trivfs_server.h | 33 + r

Re: [PATCH v2] libmachdev: Introduce startup notification for clean rumpdisk shutdown

Hi, I figured out why it was hanging on reboot: netdde was frozen because pci-arbiter was not working with my setup that used x86 method of pci access for rumpdisk. When I removed the translators from /dev/netdde and /servers/bus/pci, reboot-hurd rebooted cleanly with this patch. Damien

Re: PCI arbiter crash on last qemu image

Hi there, On 15/8/20 9:49 pm, Joan Lledó wrote > I downloaded and tried the last qemu image "debian-hurd-20200731.img". > When I try to read the memory mapped content of region files in the > arbiter, it crashes and shows the message "Real-time signal 0". I am also getting this on my latest hurd

Re: PCI arbiter crash on last qemu image

Hi there, On 17/8/20 1:04 am, Joan Lledó wrote: > I found the same issue, investigating a bit more I found that in > func_files.c:201[1], the value of region->memory is 0x0, so reading from > there raises a segfault. That pointer should be filled in libpciacces, > at x86_pci.c:601[2] during the st

Re: PCI arbiter crash on last qemu image

On 18/8/20 6:51 am, Joan Lledó wrote: > El 17/8/20 a les 1:51, Damien Zammit ha escrit: >> Perhaps a better way to fix the mapping problem I encountered >> is by removing the check for previous mappings when trying to map regions, > > I could check the pointer befo

Re: PCI arbiter crash on last qemu image

Joan, On 18/8/20 6:51 am, Joan Lledó wrote: > El 17/8/20 a les 1:51, Damien Zammit ha escrit: >> Perhaps a better way to fix the mapping problem I encountered >> is by removing the check for previous mappings when trying to map regions, I have removed my latest patch from my

Re: PCI arbiter crash on last qemu image

On 22/8/20 8:38 pm, Joan Lledó wrote: > However, I think the problem here is the x86 backend, not the common > interface. If we take a look at all other backends we'll see that: > > 1.- Neither of them call its probe() from its create(). So it's the > client who must call pci_device_probe(), it's

Re: PCI arbiter crash on last qemu image

Hi Joan, I found another probe() call in hurd_pci.c that should not be there. (So I dropped a second incorrect patch). Can you please confirm this final branch looks correct? http://git.zammit.org/libpciaccess.git/log/?h=rumpdisk-upstream Thanks, Damien

Re: PCI arbiter crash on last qemu image

Hi, On 23/8/20 8:47 pm, Joan Lledó wrote: > http://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=jlledom-pciaccess-map Thanks for doing this, I tried it locally and fixed two bugs in my libpciaccess patches: diff --git a/src/x86_pci.c b/src/x86_pci.c index 1614729..1e70f35 100644 --- a/src/x86

[PATCH] libmachdev: Remove declaration for static function

This one-liner fixes libmachdev build failure. --- libmachdev/trivfs_server.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/libmachdev/trivfs_server.h b/libmachdev/trivfs_server.h index ae30a830..40ae57fe 100644 --- a/libmachdev/trivfs_server.h +++ b/libmachdev/trivfs_server.h @@ -27,7 +27

[PATCH] rumpkernel/pci-userspace: Add missing pci probe call

With the changes now provided upstream in libpciaccess: - https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/commits/master This change is now required in rumpkernel. --- debian/patches/memory-range.diff | 8 1 file changed, 8 insertions(+) diff --git a/debian/patches/memory-range

Re: PCI arbiter crash on last qemu image

On 6/9/20 11:17 pm, Samuel Thibault wrote: >> I have uploaded libpciaccess_0.16-1+hurd.5 with the latest upstream >> version. Thanks! > One issue remains, however: Xorg's vesa driver produces > > [1669282.478] (II) VESA(0): initializing int10 > [1669282.478] (EE) VESA(0): Cannot read int vect >

Re: Thinkpad T60: 8 video cards detected (same), where 2 different cards expected

On 26/10/20 10:56 am, Almudena Garcia wrote: > This is my lspci -nn I think it's a bug with the pci-arbiter listing some of your hardware four times using lspci. Damien

Re: Thinkpad T60: 8 video cards detected (same), where 2 different cards expected

On 26/10/20 4:42 pm, Damien Zammit wrote: > On 26/10/20 10:56 am, Almudena Garcia wrote: >> This is my lspci -nn > > I think it's a bug with the pci-arbiter listing some of your hardware four > times using lspci. > I just wrote a test program that iterates over all

Re: State of SATA development?

Hi Paul, On 29/10/20 5:14 am, Paul Dufresne wrote: > So, I am kind of asking... does someone have SATA working for him/her? > If so... how? I am working on rump drivers for disk currently, (slowly in my spare time). Rump is a userspace unikernel framework based on NetBSD's kernel. rumpdisk will

rumpdisk status

Hi all, I think I managed to get the rumpdisk bootstrapped translator installed on a filesystem node, but when I try to mount a second partition on the same disk it crashes the / partition. ``` root@zamhurd:~# showtrans /dev/wd0s3 /hurd/storeio -T typed part:3:device:@/dev/rumpdisk:/dev/wd0 ?2

Re: rumpdisk status

Hi, On 8/11/20 2:35 am, Samuel Thibault wrote: > Perhaps, before mounting, try to run DISK > fdisk -l /dev/wd0 root@zamhurd:~# showtrans /dev/wd0 /hurd/storeio -T typed device:@/dev/rumpdisk:/dev/wd0 root@zamhurd:~# fdisk -l /dev/wd0 ext2fs: part:2:device:/dev/wd0: warning: FILESYSTEM NOT UNMO

Re: rumpdisk status

currently, it does not reopen the same device twice, it just passes the caller a send right to the old one. Damien On 8/11/20 10:51 am, Samuel Thibault wrote: > Damien Zammit, le dim. 08 nov. 2020 10:41:47 +1100, a ecrit: >> On 8/11/20 2:35 am, Samuel Thibault wrote: >>> Perhap

[PATCH] rumpdisk: Use rump_sys_pread/pwrite instead of lseek+r/w for atomic accesses

TESTED by booting a QEMU passthrough disk via rumpdisk.static --- rumpdisk/block-rump.c | 21 - 1 file changed, 4 insertions(+), 17 deletions(-) diff --git a/rumpdisk/block-rump.c b/rumpdisk/block-rump.c index e094a199..f7444260 100644 --- a/rumpdisk/block-rump.c +++ b/rumpdi

Re: rumpdisk status

Hi, On 9/11/20 4:50 am, Samuel Thibault wrote: > But you can as well replace these two calls with a single tall to > rump_sys_pread() that avoids such issue (ditto for write). http://git.zammit.org/hurd-sv.git/log/ Even with the new pread/pwrite calls, it still seems to mix up the reads/writes b

Re: rumpdisk status

Hi, On 10/11/20 6:12 am, Samuel Thibault wrote: > Btw, is your second partition within small bounds? (e.g. within 4GiB > that can be expressed with 32bit integers) Device Boot Start End Sectors Size Id Type /dev/sdd12048 1953791 1951744 953M 82 Linux swap / Solar

Re: rumpdisk status

Hi, On 10/11/20 6:06 am, Samuel Thibault wrote: > Perhaps add prints in the rump code to determine what really returns > that error and why. Possibly it's really a constraint of wd0d, perhaps > it can only be opened once at a time. I am getting EBUSY when trying to reopen /dev/wd0d in rump_sys_op

Re: rumpdisk status

Hi, On 10/11/20 10:39 am, Samuel Thibault wrote: >> sdd2 is / that boots with rumpdisk.static >> sdd3 is the second partition I am trying to mount with the injected >> translator > > That's far... Unless rumpdisk is built with _FILE_OFFSET_BITS 64, its > off_t etc. will be 32bit, thus probably i

Re: rumpdisk status

Hi Samuel, On 10/11/20 6:21 pm, Samuel Thibault wrote: >> It seems to be compiled with -D_FILE_OFFSET_BITS=64 already by default: > > But is rumpkernel itself also built with it? > > Really, better actually *test* that offsets are getting properly > propagated. Test program output: ``` ... wd0:

Re: rumpdisk status

On 11/11/20 5:58 am, Samuel Thibault wrote: > Damien Zammit, le mar. 10 nov. 2020 21:11:31 +1100, a ecrit: >> I also printed inside rumpdisk to dump the offsets before calling >> pread/pwrite, >> these offsets are sometimes wider than 32 bits, sometimes not. > > Ok.

[PATCH v6 0/2 hurd] irqhelp + simplify ddekit

Addressed all the review points from v5. This adds an irqhelp library for simplified user irq registration. The second patch implements the use case for ddekit (netdde). TESTED: Recompiled netdde.static and copied a 2GB file inbound at 1.8MB/sec. Also tried ifdown and ifup a few times, works as b

[PATCH v6 2/2 hurd] ddekit: Use libirqhelp for interrupt registration

--- libddekit/Makefile| 2 +- libddekit/interrupt.c | 206 +- 2 files changed, 24 insertions(+), 184 deletions(-) diff --git a/libddekit/Makefile b/libddekit/Makefile index 88a0c8909..c74ec1128 100644 --- a/libddekit/Makefile +++ b/libddekit/Makefile

[PATCH v6 1/2 hurd] libirqhelp: Add library

--- Makefile | 1 + libirqhelp/Makefile | 28 libirqhelp/irqhelp.c | 378 +++ libirqhelp/irqhelp.h | 52 ++ 4 files changed, 459 insertions(+) create mode 100644 libirqhelp/Makefile create mode 100644 libirqhelp/irqhelp.c create

Re: [PATCH v6 1/2 hurd] libirqhelp: Add library

Hi, On 11/7/23 05:47, Samuel Thibault wrote: > Damien Zammit, le lun. 10 juil. 2023 09:02:10 +, a ecrit: >> +void >> +irqhelp_wait_init(struct irq *irq) >> +{ >> + if (!irq) >> +{ >> + log_error("cannot wait o

Re: [PATCH rust] Add new target for GNU/Hurd

Hi, On 11/7/23 05:53, Samuel Thibault wrote: > Sergey Bugaev, le lun. 10 juil. 2023 12:22:21 +0300, a ecrit: >> I don't think that's correct. For one thing, dev_t is __UWORD_TYPE >> (like Rust usize) since glibc commit >> 0ec48e3337506fcd33abdd86b5ab9e331564b65c, and it was u32 before that. > > U

Re: [PATCH v6 1/2 hurd] libirqhelp: Add library

Hi, On 11/7/23 05:47, Samuel Thibault wrote: > Damien Zammit, le lun. 10 juil. 2023 09:02:10 +, a ecrit: >> +void >> +irqhelp_wait_init(struct irq *irq) >> +{ >> + if (!irq) >> +{ >> + log_error("cannot wait o

[RFC PATCH hurd] pci: Add RPCs for taking and freeing io ports by BAR

The rationale behind this change is that IO ports should not be mapped as regions, because you are not supposed to access them as a byte stream, they are accessed in certain widths depending on what hardware is backing them. This would allow pci-arbiter to control which io ports are accessed and p

[PATCH hurd] libdiskfs: Support --next-task for filesystems

This standardises the format of the boot parameters so that they all use the same parameter --next-task to specify the next task in the boot order. It does assume the next task is always exec, however. This may not be a problem. --- libdiskfs/opts-std-startup.c | 6 +- 1 file changed, 5 inse

[PATCH v2 grub] hurdhelper: Add helper for loading GNU/Hurd multiboot modules

ce:wd0 noide grub> hurdmodules pci-arbiter acpi rumpdisk ext2fs exec grub> boot This could, for example, allow hurd to be booted from the grub shell manually without remembering and typing dozens of commands. Signed-off-by: Damien Zammit --- grub-core/Makefile.core.def | 8 ++ grub

Re: [PATCH hurd] libdiskfs: Support --next-task for filesystems

Hi Sergey, On 16/7/23 21:29, Sergey Bugaev wrote: > I'd be happy to share more details about the grand plan if you're > interested — and actually it'd be great to discuss this with you since > I don't know much about device drivers etc. and you might point out > some important shortcomings in my p

[PATCH v2 hurd] pci: Add RPCs for taking and freeing io ports by BAR

This would allow pci-arbiter to control which io ports are accessed and pave the way to having granular access to io ports based on pci cards exposing their IO BARs. libpciaccess has convenient api for this kind of access, it allows opening and registering io ports by BAR. Therefore, we can first

Re: [PATCH v2 hurd] pci: Add RPCs for taking and freeing io ports by BAR

Hi, On 21/7/23 03:44, Samuel Thibault wrote: > Damien Zammit, le jeu. 20 juil. 2023 10:13:10 +, a ecrit: >> + e = master->po->np->nn->ln; >> + if (strncmp (e->name, FILE_CONFIG_NAME, NAME_SIZE)) >> +/* This operation may only be addressed to the

Re: [PATCH v2 hurd] pci: Add RPCs for taking and freeing io ports by BAR

Hi Joan, On 21/7/23 06:38, Joan Lledó wrote: > I think your design is not compatible with nested arbiters. Actually it is, I have also written a patch for libpciaccess. Basically we need to reduce the number of io ports we are requesting down to just the minimum required to access a device, then

[PATCH v3 hurd] pci: Add RPCs for taking and freeing io ports by region

This would allow pci-arbiter to control which io ports are accessed and pave the way to having granular access to io ports based on pci cards exposing their IO BARs. libpciaccess has convenient api for this kind of access, it allows opening and registering io ports by BAR. Therefore, we can first

[PATCH gnumach] db_interface: Don't call db_on if MACH_KDB is off

Allows building of gnumach with --disable-kdb and --enable-ncpus > 1 --- i386/i386/db_interface.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i386/i386/db_interface.c b/i386/i386/db_interface.c index 5a4ace9f..06cbd5e0 100644 --- a/i386/i386/db_interface.c +++ b/i386/i386/d

[PATCH v2 gnumach] Add timing info to MACH_LOCK_MON lock monitoring

Booting to beginning of bootstrap with different number of cpus and checking the lock statistics where TIME is in milliseconds: Set MACH_LOCK_MON to 1 in configfrag.ac, then Configure options --enable-ncpus=8 --enable-kdb --enable-apic --disable-linux-groups -smp 1 db{0}> show all slocks SUCC

Re: [PATCH v3 hurd] pci: Add RPCs for taking and freeing io ports by region

Hi, On 22/7/23 21:17, Joan Lledó wrote: > Correct me if I'm wrong: nested arbiters would fail here, right? An > arbiter launched from a user (non-root) having permissions over the IO > file should be able to get the port and handle it to it's clients. Then > we need the fallback mechanism to RPC t

[PATCH v4 hurd] pci: Add RPC for grabbing io ports by region

This would allow pci-arbiter to control which io ports are accessed and pave the way to having granular access to io ports based on pci cards exposing their IO BARs. libpciaccess has convenient api for this kind of access, it allows opening and registering io ports by BAR. Therefore, we can first

[PATCH gnumach] cpu_number: Look up cpu kernel_id via lookup table

This speeds up smp slightly by reducing the cpu_number() complexity to have no branching, just a look up table. It also addresses the problem that CPU_NUMBER was only using raw apic_id as an approximation of the kernel_id. Other improvements were to remove unnecessary checks now that the lookup tab

[PATCH gnumach] interrupt.S: No nested interrupts during IPIs && more x86_64 smp support

--- i386/i386at/interrupt.S | 1 + x86_64/interrupt.S | 10 ++ 2 files changed, 11 insertions(+) diff --git a/i386/i386at/interrupt.S b/i386/i386at/interrupt.S index 55f4fa0f..1f661f8d 100644 --- a/i386/i386at/interrupt.S +++ b/i386/i386at/interrupt.S @@ -123,6 +123,7 @@ _no_eoi:

[PATCH gnumach] kern/thread: Only loop over cpus that exist

--- kern/thread.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kern/thread.c b/kern/thread.c index a324eed7..9bbe8342 100644 --- a/kern/thread.c +++ b/kern/thread.c @@ -57,6 +57,7 @@ #include #include #include +#include #include #include #include @@ -2570,7 +2

[PATCH gnumach] pmap: Add missing PMAP_READ_LOCK fixes uninitialized spl

--- i386/intel/pmap.c | 1 + 1 file changed, 1 insertion(+) diff --git a/i386/intel/pmap.c b/i386/intel/pmap.c index 9bcbc279..aa5522b3 100644 --- a/i386/intel/pmap.c +++ b/i386/intel/pmap.c @@ -2462,6 +2462,7 @@ void pmap_collect(pmap_t p) /* * Free the page table tree.

[PATCH gnumach] pmap: Fix out of bounds mapwindow when using full NCPUS

There are only two slots per cpu. Use only one of two per cpu. --- i386/intel/pmap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/i386/intel/pmap.c b/i386/intel/pmap.c index 0bb1a490..9bcbc279 100644 --- a/i386/intel/pmap.c +++ b/i386/intel/pmap.c @@ -1020,10 +1020,10 @

[PATCH gnumach] ast: Implement cause_ast_check() by switching cpus

If the current processor is not the one we want to run an ast on, we can bind the current thread to the processor we want, and force a thread switch to that one, then run the ast_check() on the right cpu. --- i386/i386/ast_check.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(

[PATCH 1/3 gnumach] apic: Use cpuid to read the apic id for speed

--- i386/i386/apic.c | 11 +-- i386/i386/cpu_number.h | 20 +++- i386/i386/locore.S | 2 +- i386/i386/mp_desc.c| 3 +-- x86_64/locore.S| 10 +- 5 files changed, 31 insertions(+), 15 deletions(-) diff --git a/i386/i386/apic.c b/i386/i386/apic

[PATCH 0/3 gnumach] - SMP speedup

Hi, This patchset speeds up smp a lot, but I still can't get a shell. I get random hangs during bootup, or maybe they are just a sporadic slowness. There are still problems with the scheduler, I think. Damien

[PATCH 3/3 gnumach] i386/x86_64: Add remote AST via IPI mechanism

--- i386/i386/ast_check.c | 4 i386/i386/i386asm.sym | 1 + i386/i386/locore.S | 1 + i386/i386/smp.c | 16 +--- i386/i386/smp.h | 1 + i386/i386at/idt.h | 3 +++ i386/i386at/int_init.c | 4 i386/i386at/interrupt.S | 8 x86_64/i

[PATCH 2/3 gnumach] kern/sched_prim: Cause ast on cpu coming out of idle

--- kern/sched_prim.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/kern/sched_prim.c b/kern/sched_prim.c index dd0f492b..f7557124 100644 --- a/kern/sched_prim.c +++ b/kern/sched_prim.c @@ -1266,6 +1266,8 @@ void thread_setrun( processor->state = PROCESSOR_D

Re: [PATCH 1/3 gnumach] apic: Use cpuid to read the apic id for speed

Hi, On 12/8/23 04:27, Luca wrote: > How much faster is this? did you measure also on hw? I would use RDTSC > to do it, I don't know if there are better ways. So, ~8 microseconds was reduced to ~60 nanoseconds, so roughly 100 times faster. I don't know how to do it with rdtsc. > Interestingly, Lin

[PATCH v2 gnumach] apic: Use cpuid to read the apic id for speed

--- i386/i386/apic.c | 11 +-- i386/i386/cpu_number.h | 20 +++- i386/i386/mp_desc.c| 3 +-- x86_64/locore.S| 6 +++--- 4 files changed, 28 insertions(+), 12 deletions(-) diff --git a/i386/i386/apic.c b/i386/i386/apic.c index 2bb8e3f1..3a51f506 100644 -

[PATCH 0/5 gnumach] Scheduler fixes

Hi, This patchset does not seem to make much noticable difference to speed, but I think it's an improvement. The patches can probably be cherry-picked independently if you don't want all of them. Thanks, Damien

[PATCH 2/5 gnumach] sched_prim.c: Set quantum based on priority policy (not minimum)

--- kern/sched_prim.c | 21 ++--- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/kern/sched_prim.c b/kern/sched_prim.c index d69e4990..5ee0791b 100644 --- a/kern/sched_prim.c +++ b/kern/sched_prim.c @@ -518,7 +518,6 @@ static thread_t thread_select( */

[PATCH 1/5 gnumach] sched_prim.c: Split bound processor case into two

--- kern/sched_prim.c | 32 ++-- 1 file changed, 26 insertions(+), 6 deletions(-) diff --git a/kern/sched_prim.c b/kern/sched_prim.c index be34e7dd..d69e4990 100644 --- a/kern/sched_prim.c +++ b/kern/sched_prim.c @@ -1325,12 +1325,33 @@ void thread_setrun( }

[PATCH 3/5 gnumach] sched_prim.c: Add missing MACH_HOST pset conditionals

--- kern/sched_prim.c | 29 +++-- 1 file changed, 19 insertions(+), 10 deletions(-) diff --git a/kern/sched_prim.c b/kern/sched_prim.c index 5ee0791b..5def77d4 100644 --- a/kern/sched_prim.c +++ b/kern/sched_prim.c @@ -510,6 +510,13 @@ static thread_t thread_select(

[PATCH 5/5 gnumach] sched_prim.c: Check all run queues not just master processor

--- kern/sched_prim.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/kern/sched_prim.c b/kern/sched_prim.c index bc7befe8..ce458eb5 100644 --- a/kern/sched_prim.c +++ b/kern/sched_prim.c @@ -49,6 +49,7 @@ #include #include #include +#include #include #incl

[PATCH 4/5 gnumach] sched_prim.c: Lock thread when calling thread_setrun

--- kern/sched_prim.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kern/sched_prim.c b/kern/sched_prim.c index 5def77d4..bc7befe8 100644 --- a/kern/sched_prim.c +++ b/kern/sched_prim.c @@ -1793,7 +1793,9 @@ retry: */ if ((new_thread = (thre

[RFC PATCH gnumach] percpu area using gs segment

This speeds up smp again, by storing the struct processor in a percpu area and avoiding an expensive cpu_number every call of current_processor(), as well as getting the cpu_number by an offset into the percpu area. Needs work for 64 bit and replacing other percpu arrays. --- i386/Makefrag.am

[PATCH v2 gnumach] percpu area using gs segment

This speeds up smp again, by storing the struct processor in a percpu area and avoiding an expensive cpu_number every call of current_processor(), as well as getting the cpu_number by an offset into the percpu area. Untested on 64 bit and work remains to use other percpu arrays. TESTED: on -smp 4

[PATCH gnumach] cpuboot: Use CPU_NUMBER_NO_STACK before stack is set up

--- i386/i386/cpuboot.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i386/i386/cpuboot.S b/i386/i386/cpuboot.S index 4a5823be..7d1e815c 100644 --- a/i386/i386/cpuboot.S +++ b/i386/i386/cpuboot.S @@ -119,7 +119,7 @@ _apboot: wrmsr /* Load int_stack_top[cpu]

[PATCH v3 gnumach] percpu area using gs segment

This speeds up smp again, by storing the struct processor in a percpu area and avoiding an expensive cpu_number every call of current_processor(), as well as getting the cpu_number by an offset into the percpu area. Untested on 64 bit and work remains to use other percpu arrays. TESTED: (NCPUS=8)

[PATCH v4 2/3 gnumach] percpu area using gs segment

This speeds up smp again, by storing the struct processor in a percpu area and avoiding an expensive cpu_number every call of current_processor(), as well as getting the cpu_number by an offset into the percpu area. Untested on 64 bit and work remains to use other percpu arrays. TESTED: (NCPUS=8)

[PATCH 1/3 gnumach] gdt: Cleanup gdt.h included in asm

--- i386/i386/cpuboot.S | 1 + i386/i386/cswitch.S | 1 + i386/i386/gdt.h | 3 +++ i386/i386/i386asm.sym | 9 - i386/i386/idt_inittab.S | 1 + i386/i386/locore.S | 1 + i386/i386/spl.S | 1 + x86_64/locore.S | 1 + 8 files changed, 9 insertions(+), 9

[PATCH 3/3 gnumach] percpu active_thread using gs segment

TESTED: As per previous commit --- i386/i386/cswitch.S | 2 +- i386/i386/i386asm.sym | 1 + i386/i386/locore.S| 2 +- i386/i386/pcb.c | 2 +- i386/i386/percpu.h| 2 +- kern/ipc_sched.c | 2 +- kern/machine.c| 2 +- kern/sched_prim.c | 2 +- kern/startup.c|

[PATCH 0/3 gnumach] percpu with gs

Hi, I have split out the unrelated parts as suggested. I did not include inlining of the cpu_number calls because I noticed there was some bug introduced when I did this. I have tested both uniprocessor and smp as described in the commit message of patch 2, which I repeated for all 3 patches. T

[PATCH 1/2 gnumach] cpu_number: Inline widely used simple function

TESTED: on uniprocessor and smp, both behaved as normal. --- i386/Makefrag_x86.am | 1 - i386/i386/cpu_number.c | 30 -- i386/i386/cpu_number.h | 10 -- kern/ast.h | 1 - kern/processor.h | 3 ++- kern/thread.h | 3 ++- 6 files

[PATCH v2 0/2] percpu with gs

This changeset does not have the same bug I was seeing at boot, ie. it is working, with the inline conversion as the first patch. Damien

<    1   2   3   4   5   6   7   >