Re: [PATCH gnumach] Align mach_msg_type_t and mach_msg_type_long_t with the same alignment as uintptr_t.

[Sergey Bugaev]

Hi,

this seems to break the x86_64 --disable-user32 gnumach build for me:

vm/memory_object_user.user.c: In function ‘memory_object_init’:
vm/memory_object_user.user.c:128:9: error: static assertion failed:
"Request expected to be 80 bytes"
  128 | _Static_assert(sizeof(Request) == 80, "Request
expected to be 80 bytes");
  | ^~
vm/memory_object_user.user.c: In function ‘memory_object_terminate’:
vm/memory_object_user.user.c:197:9: error: static assertion failed:
"Request expected to be 64 bytes"
  197 | _Static_assert(sizeof(Request) == 64, "Request
expected to be 64 bytes");
  | ^~
vm/memory_object_user.user.c: In function ‘memory_object_copy’:
vm/memory_object_user.user.c:304:9: error: static assertion failed:
"Request expected to be 96 bytes"
  304 | _Static_assert(sizeof(Request) == 96, "Request
expected to be 96 bytes");
  | ^~
vm/memory_object_user.user.c: In function ‘memory_object_data_request’:
vm/memory_object_user.user.c:412:9: error: static assertion failed:
"Request expected to be 96 bytes"
  412 | _Static_assert(sizeof(Request) == 96, "Request
expected to be 96 bytes");
  | ^~
vm/memory_object_user.user.c: In function ‘memory_object_data_unlock’:
vm/memory_object_user.user.c:520:9: error: static assertion failed:
"Request expected to be 96 bytes"
  520 | _Static_assert(sizeof(Request) == 96, "Request
expected to be 96 bytes");
  | ^~
vm/memory_object_user.user.c: In function ‘memory_object_lock_completed’:
vm/memory_object_user.user.c:609:9: error: static assertion failed:
"Request expected to be 80 bytes"
  609 | _Static_assert(sizeof(Request) == 80, "Request
expected to be 80 bytes");
  | ^~
vm/memory_object_user.user.c: In function ‘memory_object_supply_completed’:
vm/memory_object_user.user.c:737:9: error: static assertion failed:
"Request expected to be 112 bytes"
  737 | _Static_assert(sizeof(Request) == 112, "Request
expected to be 112 bytes");
  | ^~
vm/memory_object_user.user.c: In function ‘memory_object_data_return’:
vm/memory_object_user.user.c:872:9: error: static assertion failed:
"Request expected to be 120 bytes"
  872 | _Static_assert(sizeof(Request) == 120, "Request
expected to be 120 bytes");
  | ^~
vm/memory_object_user.user.c: In function ‘memory_object_change_completed’:
vm/memory_object_user.user.c:944:9: error: static assertion failed:
"Request expected to be 64 bytes"
  944 | _Static_assert(sizeof(Request) == 64, "Request
expected to be 64 bytes");
  | ^~

Reverting (or rather, rebasing out) this commit helped. Does this
perhaps need matching changes in MIG?

And a meta question: is GNU MIG only intended to be usable with the
latest commit of GNU Mach? It certainly generates typed IPC, so it
can't be used with OSF/Apple's Mach. But is it expected to only ever
support whatever 64-bit ABI gnumach *currently* has, or should it
attempt to do some feature detection / whatever? In particular having
MIG generate working code no matter what Mach commit I'm on would be
nice :)

Sergey

Participating in Google Summer of Code

[ABHINAV C YADAV]

Dear sir,

I'm Abhinav C Yadav, a student from India. I'd like to work on porting Rust
to GNU/Hurd as part of the Google Summer of Code project.

I would like to know more about this, could you please assist me?

Thank you

GSoC'2023: Porting Rust to GNU/Hurd: GNU

[Madhu patel]

Hi,

I'm interested in working on the project `Porting Rust to GNU/Hurd` in the
GNU organization through GSoC'2023.

I am Madhu Patel, a fourth-year B.Tech. student in Computer Science at
IGDTUW, with a CGPA of 8.7/10. I have previously interned at Adobe India,
Rabvik Innovations, and FM solutions, and I am currently a research intern
at IIT Roorkee. I am also working on a research paper on Linux Kernel
Evolution for the USENIX publication. Moreover, my research paper on Stock
Price Prediction was recently accepted at the IEEE Conference. You can find
more information about my work on my LinkedIn and GitHub profiles.

Please suggest a few initial tasks I can work on during the application
period and attach them to my application. I have already prepared a
timeline/planner, great if you could have a look at it and suggest any
enhancements. Additionally, I have signed in to the mailing lists, and IRCs
and done the initial tasks as described on the project page [1]
.

Thanks,
Madhu Patel
LinkedIn  | Github

[PATCH v3 gnumach] x86_64: add 64-bit syscall entry point

[Luca Dariz]

While theoretically we could still use the same call gate as for
32-bit userspace, it doesn't seem very common, and gcc seems to not
encode properly the instruction. Instead we use syscall/sysret as
other kernels (e.g. XNU,Linux). This version still has some
limitations, but should be enough to start working on the 64-bit user
space.

* i386/i386/i386asm.sym: add more constants to fill pcb->iss
* i386/i386/ldt.c: configure 64-bit syscall entry point. We can just
  check for the SEP bit as MSR are always available on x86_64.
* i386/i386/ldt.h: swap CS/DS segments order if !USER32 as required by
  sysret
* i386/i386/locore.h: add syscall64 and MSR definitions
* i386/include/mach/i386/syscall_sw.h: remove old BSD_TRAP
* x86_64/Makefrag.am: selectively install syscall_sw.h depending on
  USER32
* x86_64/include/syscall_sw.h: add entry point template from user
  space
* x86_64/locore.S: implement syscall64 entry point
---
 i386/i386/i386asm.sym   |  15 +++
 i386/i386/ldt.c |  15 ++-
 i386/i386/ldt.h |   9 +-
 i386/i386/locore.h  |  30 ++
 i386/include/mach/i386/syscall_sw.h |  12 +--
 x86_64/Makefrag.am  |   7 +-
 x86_64/include/syscall_sw.h |  40 
 x86_64/locore.S | 150 
 8 files changed, 263 insertions(+), 15 deletions(-)
 create mode 100644 x86_64/include/syscall_sw.h

diff --git a/i386/i386/i386asm.sym b/i386/i386/i386asm.sym
index 8317db6c..1b9b40bb 100644
--- a/i386/i386/i386asm.sym
+++ b/i386/i386/i386asm.sym
@@ -52,6 +52,8 @@ expr  CALL_SINGLE_FUNCTION_BASE
 
 offset ApicLocalUnit   lu  apic_id APIC_ID
 
+offset pcb pcb iss
+
 offset thread  th  pcb
 offset thread  th  task
 offset thread  th  recover
@@ -82,16 +84,29 @@ sizei386_kernel_state   iks
 
 size   i386_exception_link iel
 
+offset i386_saved_stater   gs
+offset i386_saved_stater   fs
 offset i386_saved_stater   cs
 offset i386_saved_stater   uesp
 offset i386_saved_stater   eax
+offset i386_saved_stater   ebx
+offset i386_saved_stater   ecx
+offset i386_saved_stater   edx
+offset i386_saved_stater   ebp
 offset i386_saved_stater   trapno
 offset i386_saved_stater   err
 offset i386_saved_stater   efl R_EFLAGS
 offset i386_saved_stater   eip
 offset i386_saved_stater   cr2
 offset i386_saved_stater   edi
+offset i386_saved_stater   esi
 #ifdef __x86_64__
+offset i386_saved_stater   r8
+offset i386_saved_stater   r9
+offset i386_saved_stater   r10
+offset i386_saved_stater   r12
+offset i386_saved_stater   r13
+offset i386_saved_stater   r14
 offset i386_saved_stater   r15
 #endif
 
diff --git a/i386/i386/ldt.c b/i386/i386/ldt.c
index b86a0e3c..8b7add38 100644
--- a/i386/i386/ldt.c
+++ b/i386/i386/ldt.c
@@ -31,6 +31,7 @@
 #include 
 
 #include 
+#include 
 
 #include "vm_param.h"
 #include "seg.h"
@@ -65,10 +66,22 @@ ldt_fill(struct real_descriptor *myldt, struct 
real_descriptor *mygdt)
ACC_PL_K|ACC_LDT, 0);
 #endif /* MACH_PV_DESCRIPTORS */
 
-   /* Initialize the 32bit LDT descriptors.  */
+   /* Initialize the syscall entry point */
+#if defined(__x86_64__) && ! defined(USER32)
+if (!CPU_HAS_FEATURE(CPU_FEATURE_SEP))
+panic("syscall support is missing on 64 bit");
+/* Enable 64-bit syscalls */
+wrmsr(MSR_REG_EFER, rdmsr(MSR_REG_EFER) | MSR_EFER_SCE);
+wrmsr(MSR_REG_LSTAR, (vm_offset_t)syscall64);
+wrmsr(MSR_REG_STAR, long)USER_CS - 16) << 16) | (long)KERNEL_CS) 
<< 32);
+wrmsr(MSR_REG_FMASK, 0);  // ?
+#else /* defined(__x86_64__) && ! defined(USER32) */
fill_ldt_gate(myldt, USER_SCALL,
  (vm_offset_t)&syscall, KERNEL_CS,
  ACC_PL_U|ACC_CALL_GATE, 0);
+#endif /* defined(__x86_64__) && ! defined(USER32) */
+
+   /* Initialize the 32bit LDT descriptors.  */
fill_ldt_descriptor(myldt, USER_CS,
VM_MIN_USER_ADDRESS,
VM_MAX_USER_ADDRESS-VM_MIN_USER_ADDRESS-4096,
diff --git a/i386/i386/ldt.h b/i386/i386/ldt.h
index b15f11a5..51867f47 100644
--- a/i386/i386/ldt.h
+++ b/i386/i386/ldt.h
@@ -43,11 +43,16 @@
  * User descriptors for Mach - 32-bit flat address space
  */
 #defineUSER_SCALL  0x07/* system call gate */
-#ifdef __x86_64__
+#if defined(__x86_64__) && ! defined(USER32)
 /* Call gate needs two entries */
-#endif
+
+/* The sysret instruction puts some constraints on the user segment indexes */
+#defineUSER_CS 0x1f/* user code s

Re: GSoC'2023: Porting Rust to GNU/Hurd: GNU

[Samuel Thibault]

Hello,

Madhu patel, le jeu. 09 mars 2023 01:44:50 +0530, a ecrit:
> Please suggest a few initial tasks I can work on during the application period
> and attach them to my application.

We have posted information on
https://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/rust/

Samuel

Re: Participating in Google Summer of Code

[Samuel Thibault]

Hello,

ABHINAV C YADAV, le mar. 07 mars 2023 22:35:07 +0530, a ecrit:
> I would like to know more about this, could you please assist me?

We have put information on:

https://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/rust/

Samuel

Re: GSoC'2023: Porting Rust to GNU/Hurd: GNU

[Madhu patel]

Hi,
I have gone through the page, and I meet some requirements as mentioned. I
have good knowledge of C and am currently in the process of learning Rust.
At the moment, I am working on [1]
.
Can you recommend any other skills or areas of knowledge that I could
acquire in order to make a better contribution to this project?

Thanks.
Madhu






On Thu, Mar 9, 2023 at 4:45 AM Samuel Thibault 
wrote:

> Hello,
>
> Madhu patel, le jeu. 09 mars 2023 01:44:50 +0530, a ecrit:
> > Please suggest a few initial tasks I can work on during the application
> period
> > and attach them to my application.
>
> We have posted information on
> https://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/rust/
>
> Samuel
>

[image: Mailtrack]

Sender
notified by
Mailtrack

09/03/23,
13:00:58

Re: [PATCH gnumach] Align mach_msg_type_t and mach_msg_type_long_t with the same alignment as uintptr_t.

[Flávio Cruz]

Hi

On Wed, Mar 8, 2023 at 4:37 AM Sergey Bugaev  wrote:

> Hi,
>
> this seems to break the x86_64 --disable-user32 gnumach build for me:
>
> vm/memory_object_user.user.c: In function ‘memory_object_init’:
> vm/memory_object_user.user.c:128:9: error: static assertion failed:
> "Request expected to be 80 bytes"
>   128 | _Static_assert(sizeof(Request) == 80, "Request
> expected to be 80 bytes");
>   | ^~
> vm/memory_object_user.user.c: In function ‘memory_object_terminate’:
> vm/memory_object_user.user.c:197:9: error: static assertion failed:
> "Request expected to be 64 bytes"
>   197 | _Static_assert(sizeof(Request) == 64, "Request
> expected to be 64 bytes");
>   | ^~
> vm/memory_object_user.user.c: In function ‘memory_object_copy’:
> vm/memory_object_user.user.c:304:9: error: static assertion failed:
> "Request expected to be 96 bytes"
>   304 | _Static_assert(sizeof(Request) == 96, "Request
> expected to be 96 bytes");
>   | ^~
> vm/memory_object_user.user.c: In function ‘memory_object_data_request’:
> vm/memory_object_user.user.c:412:9: error: static assertion failed:
> "Request expected to be 96 bytes"
>   412 | _Static_assert(sizeof(Request) == 96, "Request
> expected to be 96 bytes");
>   | ^~
> vm/memory_object_user.user.c: In function ‘memory_object_data_unlock’:
> vm/memory_object_user.user.c:520:9: error: static assertion failed:
> "Request expected to be 96 bytes"
>   520 | _Static_assert(sizeof(Request) == 96, "Request
> expected to be 96 bytes");
>   | ^~
> vm/memory_object_user.user.c: In function ‘memory_object_lock_completed’:
> vm/memory_object_user.user.c:609:9: error: static assertion failed:
> "Request expected to be 80 bytes"
>   609 | _Static_assert(sizeof(Request) == 80, "Request
> expected to be 80 bytes");
>   | ^~
> vm/memory_object_user.user.c: In function ‘memory_object_supply_completed’:
> vm/memory_object_user.user.c:737:9: error: static assertion failed:
> "Request expected to be 112 bytes"
>   737 | _Static_assert(sizeof(Request) == 112, "Request
> expected to be 112 bytes");
>   | ^~
> vm/memory_object_user.user.c: In function ‘memory_object_data_return’:
> vm/memory_object_user.user.c:872:9: error: static assertion failed:
> "Request expected to be 120 bytes"
>   872 | _Static_assert(sizeof(Request) == 120, "Request
> expected to be 120 bytes");
>   | ^~
> vm/memory_object_user.user.c: In function ‘memory_object_change_completed’:
> vm/memory_object_user.user.c:944:9: error: static assertion failed:
> "Request expected to be 64 bytes"
>   944 | _Static_assert(sizeof(Request) == 64, "Request
> expected to be 64 bytes");
>   | ^~
>
> Reverting (or rather, rebasing out) this commit helped. Does this
> perhaps need matching changes in MIG?
>

I suspect you have to rebuild MiG because it needs to get the new
definitions
for mach_msg_type_t and mach_msg_type_long_t. Let me know if you still run
into problems.


>
> And a meta question: is GNU MIG only intended to be usable with the
> latest commit of GNU Mach? It certainly generates typed IPC, so it
> can't be used with OSF/Apple's Mach. But is it expected to only ever
> support whatever 64-bit ABI gnumach *currently* has, or should it
> attempt to do some feature detection / whatever? In particular having
> MIG generate working code no matter what Mach commit I'm on would be
> nice :)
>

Yes, that would be nice but I'm not sure if we can avoid this when we are
changing the base data types used to encode the messages. I think we just
need to get the gnumach ABI in a more stable place and then it should work
like i686, where it should never break.


> Sergey
>