There is a master-x86_64 GNU Mach branch. As of 2012-11-20, it only supports the Xen platform.

IRC, freenode, #hurd, 2011-10-16

<youpi> it'd be really good to have a 64bit kernel, no need to care about
  addressing space :)
<braunr> yes a 64 bits kernel would be nice
<braunr> i guess it wouldn't be too hard to have a special mach kernel for
  64 bits processors, but 32 bits userland only
<youpi> well, it means tinkering with mig
<braunr> like old sparc systems :p
<youpi> to build the 32bit interface, not the 64bit one
<braunr> ah yes
<braunr> hm
<braunr> i'm not sure
<braunr> mig would assume a 32 bits kernel, like now
<youpi> and you'll have all kinds of discrepancies in vm_size_t & such
<braunr> yes
<braunr> the 64 bits type should be completely internal
<braunr> types*
<braunr> but it would be far less work than changing all the userspace bits
  for 64 bit (ofc we'll do that some day but in the meanwhile ..)
<youpi> yes
<youpi> and it'd boost userland addrespace to 4GiB
<braunr> yes
<youpi> leaving time for a 64bit userland :)

IRC, freenode, #hurd, 2012-10-03

<braunr> youpi: just so you know in case you try the master-x86_64 with
  grub
<braunr> youpi: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689509
<youpi> ok, thx
<braunr> the squeeze version is fine but i had to patch the wheezy/sid one
<youpi> I actually hadn't hoped to boot into 64bit directly from grub
<braunr> youpi: there is code in viengoos that could be reused
<braunr> i've been thinking about it for a time now
<youpi> ok
<braunr> the two easiest ways are 1/ the viengoos one (a -m32 object file
  converted with objcopy as an embedded loader)
<braunr> and 2/ establishing an identity mapping using 4x1 GB large pages
  and switching to long mode, then jumping to c code to complete the
  initialization
<braunr> i think i'll go the second way with x15, so you'll have the two :)

IRC, freenode, #hurd, 2012-12-12

In context of memory management.

<tschwinge> Or with a 64-bit one?  ;-P
<braunr> tschwinge: i think we all had that idea in mind :)
<pinotree> tschwinge: patches welcome :P
<youpi> tschwinge: sure, please help us settle down with the mig stuff
<youpi> what was blocking me was just deciding how to do it
<braunr> hum, what's blocking x86_64, except time to work on it ?
<youpi> deciding the mig types & such things
<youpi> i.e. the RPC ABI
<braunr> ok
<braunr> easy answer: keep it the same
<youpi> sorry, let me rephrase
<youpi> decide what ABI is supposed to be on a 64bit system, so as to know
  which way to rewrite the types of the kernel MIG part to support 64/32
  conversion
<braunr> can't this be done in two steps ?
<youpi> well, it'd mean revamping the whole kernel twice
<youpi> as the types at stake are referenced in the whole RPC code
<braunr> the first step i imagine would simply imply having an x86_64
  kernel for 32-bits userspace, without any type change (unless restricting
  to 32-bits when a type is automatically enlarged on 64-bits)
<youpi> it's not so simple
<youpi> the RPC code is tricky
<youpi> and there are alignments things that RPC code uses
<youpi> which become different when build with a 64bit compiler
<pinotree> there are also things like int[N] for io_stat_struct and so on
<braunr> i see
<youpi> making the code wrong for 32
<youpi> thus having to change the types
<youpi> pinotree: yes
<pinotree> (doesn't mig support structs, or it is too clumsy to be used in
  practice?)
<braunr> pinotree: what's the problem with that (i explcitely said changing
  int to e.g. int32_t)
<youpi> that won't fly for some of the calls
<youpi> e.g. getting a thread state
<braunr> pinotree: no it doesn't support struct
<pinotree> braunr: that some types in struct stat are long, for instance
<braunr> pinotree: same thing with longs
<braunr> youpi: why wouldn't it ?
<youpi> that wouldn't work on a 64bit system
<youpi> so we can't make it int32_t in the interface definition
<braunr> i understand the alignment issues and that the mig code adjusts
  the generated code, but not the content of what is transfered
<braunr> well of course
<braunr> i'm talking about the first step here
<braunr> which targets a 32-bits userspace only
<youpi> ok, so we agree
<youpi> the second step would have to revamp the whole RPC code again
<braunr> i imagine the first to be less costly
<braunr> well, actually no
<braunr> you're right, the mig stuff would be easy on the application side,
  but more complicated on the kernel side, since it would really mean
  dealing with 64-bits values there
<braunr> (unless we keep a 3/1 split instead of giving the full 4g to
  applications)