Re: x86 SGDT emulation for Wine

[Sean Christopherson <seanjc@google.com>]

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 
> >that often for performance reasons isn't feasible, then that's still going to 
> >force us to implement from scratch an inordinate amount of kernel/library code 
> >inside the VM just to avoid the transition. Or, more likely, conclude that a 
> >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 
> >anything interesting, but is it really impossible to put CPU_ENTRY_AREA_RO_IDT 
> >somewhere that doesn't truncate to NULL, and to put the GDT at a fixed address 
> >as well?
> 
> Putting the GDT at a fixed address is pretty much a no-go for a variety of
> 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.
> 
> Note that there is no fundamental reason you cannot run the Unix user space
> 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-circuit
> mode", allowing a system call vmexit to invoke the system call directly
> rather than having to bounce back to user space – twice.

Heh, I recommend not re-opening that can of worms[1], though some of the follow-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