Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

all: port to Windows/arm64 #36439

Closed
vielmetti opened this issue Jan 7, 2020 · 114 comments
Closed

all: port to Windows/arm64 #36439

vielmetti opened this issue Jan 7, 2020 · 114 comments
Labels
arch-arm64 FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows
Milestone

Comments

@vielmetti
Copy link

Opening this issue to track interest and progress in a port to windows/arm64.

This is completely separate from the open issue #26148 (windows/arm32) but might be informed by it.

The specific codebase I'm motivated by for this request is for WireguardVPN, and the specific discussion to reference is https://lists.zx2c4.com/pipermail/wireguard/2020-January/004832.html & surrounding.

@toothrot toothrot added this to the Backlog milestone Jan 8, 2020
@toothrot toothrot added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 8, 2020
@carlosedp
Copy link

What is the best option for hardware to run Windows on arm64? Does it run on a RK3399 SoC board like the Pine64 Pro?

@vielmetti
Copy link
Author

@carlosedp All of the Windows 10 on Arm laptops that I am aware of to date are Qualcomm Snapdragon based. My daily driver laptop is a Lenovo Yoga C630, and there's a relatively new Microsoft Surface Pro X with a faster chip.

It looks like some work to get the boot sequence for rk3399 boards compatible with Windows lives at https://github.com/andreiw/rk3399-edk2 by @andreiw - with liberal warnings of things that still don't work.

@driver1998
Copy link

It can also run on KVM, I actually do my ARM64 dev on a KVM VM on RK3399.

@clarkezone
Copy link

clarkezone commented Jan 20, 2020

I would love to see an ARM64 version of go for Windows 10 so I can run it natively on the Surface Pro X:
image

Is what I'm currently seeing so it won't even run in emulation on this device or so it would seem.

@necrose99
Copy link

#25084 same deal.

@necrose99
Copy link

mitchellh/gox#140
platform.go and a few hax... latter.
https://github.com/golang/winstrap
ahh poohh but did not get an arm64 windows-arm build of gox... how nice.
winstrap-master_windows_arm.zip

might help...

@backerman
Copy link

I would love to see an ARM64 version of go for Windows 10 so I can run it natively on the Surface Pro X:
image

Is what I'm currently seeing so it won't even run in emulation on this device or so it would seem.

Did you use the 32- or 64- bit download? The 32-bit x86 version should run in emulation.

@necrose99
Copy link

my windows wants is any golang honeypots and RPI3/4 makes for good decoys/bait...
/topSec SBC's are less expensive to utilize emulation meh..

@anaisbetts
Copy link

@clarkezone fwiw, the 32-bit x86 version of Go's installer seems to work, at least from my limited testing (I'm not a Go user, I just wanted to build a Go app)

@bradfitz
Copy link
Contributor

bradfitz commented Mar 2, 2020

Reposting @anaisbetts's comment from elsewhere:

So, one thing to know about ARM64 on Windows is, it actually fully emulates x86 (not amd64, 32-bit apps oddly enough) for user-space apps - they Just Work (most of the time! kinda!)

So, with a bit of sleight-of-hand packaging, you can make an "ARM64" release that still mostly has x86 binaries

(I'm not sure what the performance cost of that is, though.)

@zx2c4
Copy link
Contributor

zx2c4 commented May 13, 2020

One reason why windows/arm isn't sufficient is that several important APIs -- such as all of setupapi.dll, for example -- are unavailable in wow mode, which means we need actual arm64 binaries.

It's quite possible to get windows running on arm64 in qemu, by the way.

@taxilian
Copy link

taxilian commented Jun 6, 2020

I'd love to see this as well, wanting to build some tools for my surface pro x

@zx2c4
Copy link
Contributor

zx2c4 commented Jun 7, 2020

@jstarks Any word on this?

@jstarks
Copy link

jstarks commented Jun 7, 2020

We (the OS team at Microsoft) would love to see this, too, and we would be open to contributing the code for the port. Unfortunately, we're not in a position to commit to long-term maintenance of the code or associated builder right now, so we are hesitant to send out any patches.

If Google or the Golang community would be interested in taking on the ongoing maintenance cost, we would be happy to collaborate on the development.

@zx2c4
Copy link
Contributor

zx2c4 commented Jun 7, 2020

@jstarks Just like we (Alex, me, Google employees) are already helping to maintain the other 3 Windows ports (386, amd64, arm), I don't see any reason why we couldn't do the same for arm64. I've got Windows running in QEMU/arm64 now for Wintun development, and that works well.

@bradfitz
Copy link
Contributor

bradfitz commented Jun 7, 2020

@jstarks Just like we (Alex, me, Google employees) are already helping to maintain the other 3 Windows ports (386, amd64, arm), I don't see any reason why we couldn't do the same for arm64.

windows/arm is actually a counterexample. Its builder disappeared and it bit rot. We're not not even sure it works anymore. There have been reports it doesn't.

In any case, @jstarks, the builders are the main issue, more than maintenance. If we have reliable & plentiful builders, the Go team & community can help keep it working. But absent builders it'll just rot.

How does Microsoft test? Does windows/arm{,64} run on Azure perhaps?

@zx2c4
Copy link
Contributor

zx2c4 commented Jun 7, 2020

windows/arm is actually a counterexample. Its builder disappeared and it bit rot. We're not not even sure it works anymore. There have been reports it doesn't.

The arm port works. @rozmansi got WireGuard/Wintun ported to it. Unfortunately, WOW has its limitations and we really need arm64 to access the APIs that we need (setupapi.dll, for example).

@zx2c4
Copy link
Contributor

zx2c4 commented Jun 7, 2020

How does Microsoft test? Does windows/arm{,64} run on Azure perhaps?

I'd too be interested to learn if Microsoft has some nice solutions for this.

But in case not, @rozmansi and I can probably help getting the QEMU setup via TCG running smoothly in gcloud like the current set of builders. Or if we actually need additional performance, we could look if ec2's arm64 VMs support nested KVM, or grab a ThunderX machine from Scaleway and run KVM over there.

@bradfitz
Copy link
Contributor

bradfitz commented Jun 7, 2020

The arm port works.

On which branch? Go 1.14 only or even master? (And the fact that we even have to ask is a ridiculous situation to be in.)

@zx2c4
Copy link
Contributor

zx2c4 commented Jun 7, 2020

The arm port works.

On which branch? Go 1.14 only or even master? (And the fact that we even have to ask is a ridiculous situation to be in.)

Haven't looked at git master in sometime. Could give it a whirl I suppose.

@bradfitz
Copy link
Contributor

bradfitz commented Jun 7, 2020

But in case not, @rozmansi and I can probably help getting the QEMU setup via TCG running smoothly in gcloud like the current set of builders.

Go is moving towards having all its arm & arm64 builders on Amazon. EC2 has nice ARM instance types nowadays.

If you can get windows/arm and windows/arm64 booting in qemu[/kvm] there, that'd be great. Then it's just a question of Windows licensing, which perhaps @jstarks et al could help with.

@jstarks
Copy link

jstarks commented Jun 8, 2020

This sounds promising. I'll check on what options are available and if there are licensing implications.

@zx2c4
Copy link
Contributor

zx2c4 commented Jun 8, 2020

image

@rozmansi's overall setup works pretty well for me. EC2 doesn't pass down the vmx bit, but TCG really is fast enough for testing things.

@rsc
Copy link
Contributor

rsc commented Apr 26, 2021

I submitted a stack of CLs to add cgo support to windows/arm64 on Friday evening, ending at b8fed48. With those, I believe the windows/arm64 support for Go 1.17 is completed.

Closing this issue.

@rsc rsc closed this as completed Apr 26, 2021
@rsc rsc modified the milestones: Backlog, Go1.17 Apr 26, 2021
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/314430 mentions this issue: dashboard: add compile-only TryBot coverage for windows/arm64 port

gopherbot pushed a commit to golang/build that referenced this issue Apr 27, 2021
The windows/arm64 port has been completed in golang.org/issue/36439
recently. Add pre-submit compile-only coverage via a misc-compile
TryBot for the new port. It can be upgraded to a normal TryBot that
also executes tests after a windows/arm64 builder becomes available.

Tested locally by running 'buildall.bash windows-arm64' on a recent
Go tip commit (CL 313849), which passed.

For golang/go#36439.
Updates golang/go#42604.

Change-Id: Ie4988a876aa18392a583eb407c6c3621eb30a4f8
Reviewed-on: https://go-review.googlesource.com/c/build/+/314430
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
@zx2c4
Copy link
Contributor

zx2c4 commented May 5, 2021

I submitted a stack of CLs to add cgo support to windows/arm64 on Friday evening, ending at b8fed48. With those, I believe the windows/arm64 support for Go 1.17 is completed.

Closing this issue.

That's terrific. Thanks for working on that. I'll make a note to test that out in the coming weeks.

Any plans on doing the same for windows/arm? Then there'd be fully deployable capacity across all Windows platforms.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/344069 mentions this issue: internal/dl: change GOARCH=arm64 pretty string from ARMv8 to ARM64

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/344070 mentions this issue: internal/dl: highlight Windows ARM64 installer

gopherbot pushed a commit to golang/website that referenced this issue Aug 23, 2021
ARM64 makes for a better pretty string for the "arm64" architecture.
It's more clear that it's 64-bit, and it's closer to what we almost
always say.

Thanks to Cherry for making this suggestion.

For golang/go#38485.
For golang/go#36439.

Change-Id: I89c175ea2bafce6f191ae797ed982c73962ee5da
Reviewed-on: https://go-review.googlesource.com/c/website/+/344069
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
gopherbot pushed a commit to golang/website that referenced this issue Aug 23, 2021
The windows/arm64 port is new to Go 1.17 and one of its key features.
Highlight the Windows ARM64 installer, just like the Windows AMD64
installer is highlighted. (Keep the zip archives and 386 installer
not highlighted.)

For golang/go#36439.

Change-Id: Ib57e80465d0ca090d165e14e3c4afdb2efca0c11
Reviewed-on: https://go-review.googlesource.com/c/website/+/344070
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
@jeremyd2019
Copy link

Hi,

I have been working with MSYS2 on getting packages there built for Windows on ARM64 (using clang's mingw-w64 target like llvm-mingw does). I am curious if it would be possible to 'bootstrap' an ARM64 package of Go there (and/or if I can contribute to making that work, though I have 0 experience with Go).

Also, I am very interested in what options/licensing you figured out for Windows ARM64. We are currently using a QC710 to build, but I have been trying to figure out some sort of cloud hosting situation...

@jeremyd2019
Copy link

I am curious if it would be possible to 'bootstrap' an ARM64 package of Go there (and/or if I can contribute to making that work, though I have 0 experience with Go).

Amazingly, it Just Worked. I'm used to having to fight packages much more to get them to build 😀

@necrose99
Copy link

git clone @ github.com/mh-cbon/go-msi

go mod init github.com/mh-cbon/go-msi && go mod tidy && gox -osarch="windows/arm64"

can build on stock win11 ... go-msi_windows_arm64.exe is produced.

point being might be able to msi/msix an installer as well ..

passionSeven added a commit to passionSeven/website that referenced this issue Oct 18, 2022
ARM64 makes for a better pretty string for the "arm64" architecture.
It's more clear that it's 64-bit, and it's closer to what we almost
always say.

Thanks to Cherry for making this suggestion.

For golang/go#38485.
For golang/go#36439.

Change-Id: I89c175ea2bafce6f191ae797ed982c73962ee5da
Reviewed-on: https://go-review.googlesource.com/c/website/+/344069
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
passionSeven added a commit to passionSeven/website that referenced this issue Oct 18, 2022
The windows/arm64 port is new to Go 1.17 and one of its key features.
Highlight the Windows ARM64 installer, just like the Windows AMD64
installer is highlighted. (Keep the zip archives and 386 installer
not highlighted.)

For golang/go#36439.

Change-Id: Ib57e80465d0ca090d165e14e3c4afdb2efca0c11
Reviewed-on: https://go-review.googlesource.com/c/website/+/344070
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
imiric pushed a commit to grafana/xk6 that referenced this issue Nov 16, 2022
Releasing v0.8.0 failed[1] because of:

> failed to build for windows_arm64: exit status 2: cmd/go: unsupported
> GOOS/GOARCH pair windows/arm64

Apparently this was unsupported in Go <1.17[2], but I'm not sure why it
succeeded with the v0.7.0 release, which used 1.16...

[1]: https://github.com/grafana/xk6/actions/runs/3481621020/jobs/5822947099

[2]: golang/go#36439
cbwest3-ntnx pushed a commit to cbwest3-ntnx/win that referenced this issue Jan 13, 2023
Updates: golang/go#36439
Updates: golang/go#44020

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
cbwest3-ntnx pushed a commit to cbwest3-ntnx/win that referenced this issue Jan 13, 2023
Updates: golang/go#36439
Updates: golang/go#44020

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
cbwest3-ntnx pushed a commit to cbwest3-ntnx/win that referenced this issue Jan 17, 2023
Updates: golang/go#36439
Updates: golang/go#44020

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
cbwest3 pushed a commit to cbwest3/win that referenced this issue Feb 1, 2023
Updates: golang/go#36439
Updates: golang/go#44020

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
@golang golang locked and limited conversation to collaborators Apr 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-arm64 FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows
Projects
None yet
Development

No branches or pull requests