[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yv/mcxPsJGZYV2tU@google.com>
Date: Fri, 19 Aug 2022 19:37:23 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: Vishal Annapurve <vannapurve@...gle.com>
Cc: Peter Gonda <pgonda@...gle.com>, kvm list <kvm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Marc Orr <marcorr@...gle.com>,
Michael Roth <michael.roth@....com>,
Tom Lendacky <thomas.lendacky@....com>,
Joerg Roedel <joro@...tes.org>,
Mingwei Zhang <mizhang@...gle.com>,
Paolo Bonzini <pbonzini@...hat.com>, andrew.jones@...ux.dev
Subject: Re: [V3 10/11] KVM: selftests: Add ucall pool based implementation
On Fri, Aug 19, 2022, Vishal Annapurve wrote:
> On Wed, Aug 10, 2022 at 8:20 AM Peter Gonda <pgonda@...gle.com> wrote:
> > void ucall(uint64_t cmd, int nargs, ...)
> > {
> > - struct ucall uc = {};
> > + struct ucall *uc;
> > + struct ucall tmp = {};
>
> This steps seems to result in generating instructions that need SSE
> support on x86:
> struct ucall tmp = {};
> movaps %xmm0,0x20(%rsp)
> movaps %xmm0,0x30(%rsp)
> movaps %xmm0,0x40(%rsp)
> movaps %xmm0,0x50(%rsp)
>
> This initialization will need proper compilation flags to generate
> instructions according to VM configuration.
Can you be more specific as to why generating SSE instructiions is problematic?
The compiler emitting fancy instructions for struct initialization is not out of
the ordinary.
Powered by blists - more mailing lists