lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5475D20A.90505@redhat.com>
Date:	Wed, 26 Nov 2014 14:13:46 +0100
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Radim Krčmář <rkrcmar@...hat.com>
CC:	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	wanpeng.li@...ux.intel.com, namit@...technion.ac.il,
	hpa@...ux.intel.com, Fenghua Yu <fenghua.yu@...el.com>
Subject: Re: [CFT PATCH v2 2/2] KVM: x86: support XSAVES usage in the host



On 26/11/2014 13:07, Radim Krčmář wrote:
> 2014-11-24 17:43+0100, Paolo Bonzini:
>> Userspace is expecting non-compacted format for KVM_GET_XSAVE, but
>> struct xsave_struct might be using the compacted format.  Convert
>> in order to preserve userspace ABI.
>>
>> Likewise, userspace is passing non-compacted format for KVM_SET_XSAVE
>> but the kernel will pass it to XRSTORS, and we need to convert back.
> 
> Future instructions might force us to calling xsave/xrstor directly, so
> we could do that even now and save the explicit conversion ...
> 
> What I mean is:  we could be using the native xsave.*/xrstor.* while in
> kernel and use xsave/xrstor for communication with userspace.
> Hardware would take care of everything in the conversion.
> 
> get_xsave = native_xrstor(guest_xsave);  xsave(aligned_userspace_buffer)
> set_xsave = xrstor(aligned_userspace_buffer);  native_xsave(guest_xsave)
> 
> Could that work?

It could, though it is more like

   get_fpu()
   native_xrstor(guest_xsave)
   xsave(buffer)
   put_fpu()

and vice versa.  Also, the userspace buffer is mos likely not aligned,
so you need some kind of bounce buffer.  It can be done if the CPUID
turns out to be a bottleneck, apart from that it'd most likely be slower.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ