From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41650) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3ptJ-0007hN-LO for qemu-devel@nongnu.org; Tue, 01 Dec 2015 13:43:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a3ptF-0001Ep-BV for qemu-devel@nongnu.org; Tue, 01 Dec 2015 13:43:05 -0500 Received: from mail-qg0-x234.google.com ([2607:f8b0:400d:c04::234]:34576) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3ptF-0001El-7f for qemu-devel@nongnu.org; Tue, 01 Dec 2015 13:43:01 -0500 Received: by qgeb1 with SMTP id b1so13032379qge.1 for ; Tue, 01 Dec 2015 10:43:00 -0800 (PST) Sender: Richard Henderson References: <1448740611-3096-1-git-send-email-ehabkost@redhat.com> <1448740611-3096-2-git-send-email-ehabkost@redhat.com> <565C3089.4070101@redhat.com> <565DD45B.3070505@twiddle.net> <20151201171550.GN23717@thinpad.lan.raisama.net> <565DD6E9.1040906@twiddle.net> <565DD875.7090108@redhat.com> <20151201183441.GO23717@thinpad.lan.raisama.net> From: Richard Henderson Message-ID: <565DEA31.4090707@twiddle.net> Date: Tue, 1 Dec 2015 10:42:57 -0800 MIME-Version: 1.0 In-Reply-To: <20151201183441.GO23717@thinpad.lan.raisama.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [for-2.6 PATCH 1/3] target-i386: Define structs for layout of xsave area List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost , Paolo Bonzini Cc: Huaitong Han , qemu-devel@nongnu.org, kvm@vger.kernel.org On 12/01/2015 10:34 AM, Eduardo Habkost wrote: > BTW, if we are going to implement xsave in TCG, the > X86CPU<->xsave translation logic in kvm_{get,put}_xsave() could > be moved to generic code and reused by TCG instead of being > reimplemented. That's not trivial. In particular, stq_p isn't what the tcg helper needs to use, but rather cpu_stq_data_ra. Given the differing parameters, we'd have to resort to some sort of macro-ization. It's probably easiest to simply keep the two implementations separate. r~