On Thu, Oct 17, 2013 at 11:37:48AM +0100, Jan Beulich wrote:
> >>> On 17.10.13 at 12:23, Gleb Natapov wrote:
> > On Thu, Oct 17, 2013 at 10:51:52AM +0100, Jan Beulich wrote:
> >> >>> On 17.10.13 at 11:41, Gleb Natapov wrote:
> >> > KVM obviously knows the complete state of virtual CPU. It can fig
>>> On 17.10.13 at 12:23, Gleb Natapov wrote:
> On Thu, Oct 17, 2013 at 10:51:52AM +0100, Jan Beulich wrote:
>> >>> On 17.10.13 at 11:41, Gleb Natapov wrote:
>> > KVM obviously knows the complete state of virtual CPU. It can figure the
>> > situation above by looking at CS descriptor, not need to
On Thu, Oct 17, 2013 at 10:51:52AM +0100, Jan Beulich wrote:
> >>> On 17.10.13 at 11:41, Gleb Natapov wrote:
> > On Thu, Oct 17, 2013 at 10:33:33AM +0100, Jan Beulich wrote:
> >> >>> On 17.10.13 at 11:27, Gleb Natapov wrote:
> >> > On Wed, Oct 16, 2013 at 05:13:40PM +0100, Jan Beulich wrote:
> >>
>>> On 17.10.13 at 11:41, Gleb Natapov wrote:
> On Thu, Oct 17, 2013 at 10:33:33AM +0100, Jan Beulich wrote:
>> >>> On 17.10.13 at 11:27, Gleb Natapov wrote:
>> > On Wed, Oct 16, 2013 at 05:13:40PM +0100, Jan Beulich wrote:
>> >> > It preserves *less* state, because the upper 32 bits of rip are n
On Thu, Oct 17, 2013 at 10:33:33AM +0100, Jan Beulich wrote:
> >>> On 17.10.13 at 11:27, Gleb Natapov wrote:
> > On Wed, Oct 16, 2013 at 05:13:40PM +0100, Jan Beulich wrote:
> >> > It preserves *less* state, because the upper 32 bits of rip are now
> >> > corrupted. Any 64-bit application that act
>>> On 17.10.13 at 11:27, Gleb Natapov wrote:
> On Wed, Oct 16, 2013 at 05:13:40PM +0100, Jan Beulich wrote:
>> > It preserves *less* state, because the upper 32 bits of rip are now
>> > corrupted. Any 64-bit application that actually looks at the FP
>> > rip/rdp fields now get the WRONG VALUES.
>
On Wed, Oct 16, 2013 at 05:13:40PM +0100, Jan Beulich wrote:
> > It preserves *less* state, because the upper 32 bits of rip are now
> > corrupted. Any 64-bit application that actually looks at the FP
> > rip/rdp fields now get the WRONG VALUES.
>
> But again - this isn't being done for ordinary 6
>>> On 16.10.13 at 20:43, Linus Torvalds wrote:
> So having looked at this some more, I would *really* prefer a
> different solution. The overwriting of the rip/rdp data just really
> annoys me.
>
> Is there any reason to not just do it like the following instead:
>
> - get rid of the "word_siz
On Wed, Oct 16, 2013 at 9:13 AM, Jan Beulich wrote:
>
> But again - this isn't being done for ordinary 64-bit applications,
> this is only happening for KVM guests. And there not being a
> protocol for telling the caller whether a certain context hold
> 64-bit offsets or selector/offset pairs shou
On 10/16/2013 09:07 AM, Jan Beulich wrote:
>
>> Furthermore, you define X86_FEATURE_NO_FPU_SEL, but you don't set it
>> anywhere. At least that bit needs to be factored out into a separate patch.
>
> That's already being done in get_cpu_cap(), as it's part of
> x86_capability[9].
>
Ah, sorry,
>>> On 16.10.13 at 17:50, Linus Torvalds wrote:
> On Wed, Oct 16, 2013 at 8:36 AM, Jan Beulich wrote:
>>
>> In that case we use a 32-bit operand size [F]XRSTOR, and hence
>> the upper halves get treated as selectors, and the offsets get
>> zero-extended from the low halves, i.e. we preserve even
>>> On 16.10.13 at 17:39, "H. Peter Anvin" wrote:
> On 10/16/2013 05:00 AM, Jan Beulich wrote:
>> Having had reports of certain Windows versions, when put in some
>> special driver verification mode, blue-screening due to the FPU state
>> having changed across interrupt handler runs (resulting fro
On Wed, Oct 16, 2013 at 8:36 AM, Jan Beulich wrote:
>
> In that case we use a 32-bit operand size [F]XRSTOR, and hence
> the upper halves get treated as selectors, and the offsets get
> zero-extended from the low halves, i.e. we preserve even more
> state for such a 64-bit environment now too (alb
On 10/16/2013 05:00 AM, Jan Beulich wrote:
> Having had reports of certain Windows versions, when put in some
> special driver verification mode, blue-screening due to the FPU state
> having changed across interrupt handler runs (resulting from a host/
> hypervisor side context switch somewhere in
>>> On 16.10.13 at 17:19, Linus Torvalds wrote:
> On Wed, Oct 16, 2013 at 5:00 AM, Jan Beulich wrote:
>>
>> The basic idea here is to either use a priori information on the
>> intended state layout (in the case of 32-bit processes) or "sense" the
>> proper layout (in the case of KVM guests) by in
On Wed, Oct 16, 2013 at 5:00 AM, Jan Beulich wrote:
>
> The basic idea here is to either use a priori information on the
> intended state layout (in the case of 32-bit processes) or "sense" the
> proper layout (in the case of KVM guests) by inspecting the already
> saved FPU rip/rdp, and reading t
Having had reports of certain Windows versions, when put in some
special driver verification mode, blue-screening due to the FPU state
having changed across interrupt handler runs (resulting from a host/
hypervisor side context switch somewhere in the middle of the guest
interrupt handler execution
17 matches
Mail list logo
