-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
Comments
What is the best option for hardware to run Windows on arm64? Does it run on a RK3399 SoC board like the Pine64 Pro? |
@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. |
It can also run on KVM, I actually do my ARM64 dev on a KVM VM on RK3399. |
#25084 same deal. |
mitchellh/gox#140 might help... |
my windows wants is any golang honeypots and RPI3/4 makes for good decoys/bait... |
@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) |
Reposting @anaisbetts's comment from elsewhere:
(I'm not sure what the performance cost of that is, though.) |
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. |
I'd love to see this as well, wanting to build some tools for my surface pro x |
@jstarks Any word on this? |
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. |
@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. |
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? |
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). |
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. |
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. |
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. |
This sounds promising. I'll check on what options are available and if there are licensing implications. |
@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. |
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. |
Change https://golang.org/cl/314430 mentions this issue: |
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 <[email protected]> Trust: Alexander Rakoczy <[email protected]> Reviewed-by: Carlos Amedee <[email protected]> Reviewed-by: Heschi Kreinick <[email protected]> Reviewed-by: Alexander Rakoczy <[email protected]>
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. |
Change https://golang.org/cl/344069 mentions this issue: |
Change https://golang.org/cl/344070 mentions this issue: |
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 <[email protected]> Run-TryBot: Dmitri Shuralyov <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Heschi Kreinick <[email protected]>
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 <[email protected]> Run-TryBot: Dmitri Shuralyov <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Carlos Amedee <[email protected]> Reviewed-by: Heschi Kreinick <[email protected]>
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... |
Amazingly, it Just Worked. I'm used to having to fight packages much more to get them to build 😀 |
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 .. |
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 <[email protected]> Run-TryBot: Dmitri Shuralyov <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Heschi Kreinick <[email protected]>
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 <[email protected]> Run-TryBot: Dmitri Shuralyov <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Carlos Amedee <[email protected]> Reviewed-by: Heschi Kreinick <[email protected]>
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
Updates: golang/go#36439 Updates: golang/go#44020 Signed-off-by: Jason A. Donenfeld <[email protected]>
Updates: golang/go#36439 Updates: golang/go#44020 Signed-off-by: Jason A. Donenfeld <[email protected]>
Updates: golang/go#36439 Updates: golang/go#44020 Signed-off-by: Jason A. Donenfeld <[email protected]>
Updates: golang/go#36439 Updates: golang/go#44020 Signed-off-by: Jason A. Donenfeld <[email protected]>
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.
The text was updated successfully, but these errors were encountered: