Received-SPF: pass (google.com: domain of linux-kernel+bounces-17377-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Thu, 4 Jan 2024 17:21:19 -0800
In-Reply-To: <B042BACA-839E-4A42-9BAA-AC7E58624250@zytor.com>
Precedence: bulk
Mime-Version: 1.0
References: <2285758.taCxCBeP46@uriel> <ZZV65qJuJ67E_n9O@google.com>
 <1C37C311-CF8A-44EC-89B5-D826EF458708@zytor.com> <2451911.jE0xQCEvom@uriel> <B042BACA-839E-4A42-9BAA-AC7E58624250@zytor.com>
Message-ID: <ZZdZj7p1OcrAzDcQ@google.com>
Subject: Re: x86 SGDT emulation for Wine
From: Sean Christopherson <seanjc@google.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Elizabeth Figura <zfigura@codeweavers.com>, x86@kernel.org, 
	Linux Kernel <linux-kernel@vger.kernel.org>, Thomas Gleixner <tglx@linutronix.de>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, 
	Ricardo Neri <ricardo.neri-calderon@linux.intel.com>, wine-devel@winehq.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 04, 2024, H. Peter Anvin wrote:
> On January 3, 2024 10:35:28 PM PST, Elizabeth Figura <zfigura@codeweavers=
.com> wrote:
> >That still leaves the question of performance though. If having to exit =
the VM=20
> >that often for performance reasons isn't feasible, then that's still goi=
ng to=20
> >force us to implement from scratch an inordinate amount of kernel/librar=
y code=20
> >inside the VM just to avoid the transition. Or, more likely, conclude th=
at a=20
> >hypervisor just isn't going to work for us.
> >
> >I'm not at all familiar with the arch code, and I'm sure I'm not asking=
=20
> >anything interesting, but is it really impossible to put CPU_ENTRY_AREA_=
RO_IDT=20
> >somewhere that doesn't truncate to NULL, and to put the GDT at a fixed a=
ddress=20
> >as well?
>=20
> Putting the GDT at a fixed address is pretty much a no-go for a variety o=
f
> reasons. As I said, a prctl() to specify the desired return information *=
on
> UMIP-capable hardware* is certainly doable. However, it does not address
> things like fixed selectors that have come up.
>=20
> Note that there is no fundamental reason you cannot run the Unix user spa=
ce
> code inside the VM container, too; you only need to vmexit on an actual
> system call. KVM might be able to assist there by providing a "short-circ=
uit
> mode", allowing a system call vmexit to invoke the system call directly
> rather than having to bounce back to user space =E2=80=93 twice.

Heh, I recommend not re-opening that can of worms[1], though some of the fo=
llow-up
work[2] from the gVisor folks might be useful/relevant?

[1] https://lore.kernel.org/all/20220722230241.1944655-1-avagin@google.com
[2] https://lore.kernel.org/all/20230308073201.3102738-1-avagin@google.com