From: ori@eigenstate.org
To: ftrvxmtrx@gmail.com
To: 9front@9front.org
Subject: Re: [9front] VMX improvements + AVX
Date: Fri, 04 Dec 2020 16:19:02 -0800 [thread overview]
Message-ID: <5BA0FE28F1C6A68B4421AB3D0FA98F13@eigenstate.org> (raw)
In-Reply-To: <52CB3E735527EF01CDF9E2641E3A406B@gmail.com>
Quoth Sigrid Solveig Haflnudttir <ftrvxmtrx@gmail.com>:
> Hello. I made some changes to /sys/src/9/^(pc pc64) and
> /sys/src/cmd/vmx to get better support for Linux and OpenBSD emulation
> and before I push it (or not) I'd like to get more eyes (and hands) on
> it. 386 kernel should not be affected by the change at all, this is
> about amd64 specifically.
>
> Changes were tested on two machines I have, with AVX enabled/disabled.
> No problems were found with extensive use, nor any performance issues
> detected.
This fixes the 'xgetbv' trap that I was getting with OpenBSD. Thanks!
That's been something that I've wanted to get to, and I'm thrilled
that I don't need to.
> On the host Go is using AVX successfully with this change. I'm
> writing optimized routines related to video playback so that's yet
> another reason why this work has been done in the first place.
It's also probably worth noting that the compilers for 9legacy
have some support for more recent XMM/YMM registers:
https://github.com/0intro/plan9-contrib/commit/94fe116949ba36db8216abed83dbad8fb84ecdf7.patch
We've diverged a bit so the merge would be a pain in the ass,
and we'd need to get the disassembly done -- but at least some
of the code has been written.
> * AVX/AVX2 support on amd64 for both 9front kernel itself + VMX
> guests. Enabled by setting "*avx=" in plan9.ini.
As mentioned in gridchat: I think we can remove this knob, or
at least turn it on by default and have '*noavx=' for debugging
> * Make vmx(1) report to guest it's running under a hypervisor.
I'm skimming the code, but don't see anything obvious. How are
you reporting to the guest?
> * Provide "fast strings" (through msr) properly to guests.
> * Rework cpuid in vmx(1).
> * A bit better timing by using tsc offset feature. Clock is still
> wrong but at least not THAT much. Proper kvm clock implementation
> in the future will address that.
I'll pull up the spec soon enough and try to make a bit more sense
of this code, but it looks awesome so far. Thanks!
next prev parent reply other threads:[~2020-12-05 0:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-04 15:39 Sigrid Solveig Haflínudóttir
2020-12-04 21:15 ` james palmer
2020-12-04 22:25 ` Kurt H Maier
2020-12-05 0:19 ` ori [this message]
2020-12-10 12:23 ` Stuart Morrow
2020-12-10 15:09 ` ori
2020-12-18 2:22 ` magma698hfsp273p9f
2020-12-18 4:41 ` ori
2021-01-21 0:58 ` Nemo's books (WAS: Re: [9front] VMX improvements + AVX) magma698hfsp273p9f
2021-01-21 3:37 ` Roman Shaposhnik
2021-01-21 3:58 ` sl
2021-01-23 7:31 ` [9front] Re: Nemo's books magma698hfsp273p9f
2021-01-23 12:47 ` Eckard Brauer
2021-01-21 4:07 ` Nemo's books (WAS: Re: [9front] VMX improvements + AVX) Anthony Martin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5BA0FE28F1C6A68B4421AB3D0FA98F13@eigenstate.org \
--to=ori@eigenstate.org \
--cc=9front@9front.org \
--cc=ftrvxmtrx@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).