Re: [PATCH] When switching to a vm8086 task, load segments as 16-bit (v2)

2009-08-12 Thread Avi Kivity

On 08/11/2009 11:57 PM, Anthony Liguori wrote:

According to 16.2.5 in the SDM, eflags.vm in the tss is consulted before loading
and new segments.  If eflags.vm == 1, then the segments are treated as 16-bit
segments.  The LDTR and TR are not normally available in vm86 mode so if they
happen to somehow get loaded, they need to be treated as 32-bit segments.

This fixes an invalid vmentry failure in a custom OS that was happening after
a task switch into vm8086 mode.  Since the segments were being mistakenly
treated as 32-bit, we loaded garbage state.
   


Applied, thanks.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] When switching to a vm8086 task, load segments as 16-bit (v2)

2009-08-12 Thread Avi Kivity

On 08/11/2009 11:57 PM, Anthony Liguori wrote:

According to 16.2.5 in the SDM, eflags.vm in the tss is consulted before loading
and new segments.  If eflags.vm == 1, then the segments are treated as 16-bit
segments.  The LDTR and TR are not normally available in vm86 mode so if they
happen to somehow get loaded, they need to be treated as 32-bit segments.

This fixes an invalid vmentry failure in a custom OS that was happening after
a task switch into vm8086 mode.  Since the segments were being mistakenly
treated as 32-bit, we loaded garbage state.
   


I'm getting a Vista x64 installer failure on reboot with this.  One 
possibility is that -get_rflags() is returning the mangled flags state 
(we add vm86 for real mode), which confuses the new code.


--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] When switching to a vm8086 task, load segments as 16-bit (v2)

2009-08-12 Thread Avi Kivity

On 08/12/2009 03:11 PM, Avi Kivity wrote:

On 08/11/2009 11:57 PM, Anthony Liguori wrote:
According to 16.2.5 in the SDM, eflags.vm in the tss is consulted 
before loading
and new segments.  If eflags.vm == 1, then the segments are treated 
as 16-bit
segments.  The LDTR and TR are not normally available in vm86 mode so 
if they
happen to somehow get loaded, they need to be treated as 32-bit 
segments.


This fixes an invalid vmentry failure in a custom OS that was 
happening after
a task switch into vm8086 mode.  Since the segments were being 
mistakenly

treated as 32-bit, we loaded garbage state.


I'm getting a Vista x64 installer failure on reboot with this.  One 
possibility is that -get_rflags() is returning the mangled flags 
state (we add vm86 for real mode), which confuses the new code.




That's indeed the case, I'm testing a patch now.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



Re: [PATCH] When switching to a vm8086 task, load segments as 16-bit (v2)

2009-08-12 Thread Anthony Liguori

Avi Kivity wrote:

On 08/12/2009 03:11 PM, Avi Kivity wrote:

On 08/11/2009 11:57 PM, Anthony Liguori wrote:
According to 16.2.5 in the SDM, eflags.vm in the tss is consulted 
before loading
and new segments.  If eflags.vm == 1, then the segments are treated 
as 16-bit
segments.  The LDTR and TR are not normally available in vm86 mode 
so if they
happen to somehow get loaded, they need to be treated as 32-bit 
segments.


This fixes an invalid vmentry failure in a custom OS that was 
happening after
a task switch into vm8086 mode.  Since the segments were being 
mistakenly

treated as 32-bit, we loaded garbage state.


I'm getting a Vista x64 installer failure on reboot with this.  One 
possibility is that -get_rflags() is returning the mangled flags 
state (we add vm86 for real mode), which confuses the new code.




That's indeed the case, I'm testing a patch now.


While the code looks nicer with the second patch, the fact that 
get_rflags() does a vmcs_read() seems 7 times more than before seems 
unfortunate.


--
Regards,

Anthony Liguori

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] When switching to a vm8086 task, load segments as 16-bit (v2)

2009-08-12 Thread Avi Kivity

On 08/12/2009 04:15 PM, Anthony Liguori wrote:
While the code looks nicer with the second patch, the fact that 
get_rflags() does a vmcs_read() seems 7 times more than before seems 
unfortunate.


We can add kvm_rflags_read(), see kvm_cache_regs.h.  In any case, it's 
purely academic since task switches are rare and incredibly slow anyway 
(you have to vmcs_write() the entire register set for one).


--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] When switching to a vm8086 task, load segments as 16-bit (v2)

2009-08-12 Thread Anthony Liguori

Avi Kivity wrote:

On 08/12/2009 04:15 PM, Anthony Liguori wrote:
While the code looks nicer with the second patch, the fact that 
get_rflags() does a vmcs_read() seems 7 times more than before seems 
unfortunate.


We can add kvm_rflags_read(), see kvm_cache_regs.h.  In any case, it's 
purely academic since task switches are rare and incredibly slow 
anyway (you have to vmcs_write() the entire register set for one).


Fair enough.

--
Regards,

Anthony Liguori

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html