On 09/06/2017 07:30, Wanpeng Li wrote:
> 2017-06-08 19:52 GMT+08:00 Paolo Bonzini :
>>
>> 3) add an async_page_fault member to vcpu->arch.exception
>
> Do you think we should also add an async_page_fault field to
> x86_exception, then pass down to kvm_inject_page_fault()
On 09/06/2017 07:30, Wanpeng Li wrote:
> 2017-06-08 19:52 GMT+08:00 Paolo Bonzini :
>>
>> 3) add an async_page_fault member to vcpu->arch.exception
>
> Do you think we should also add an async_page_fault field to
> x86_exception, then pass down to kvm_inject_page_fault() through
>
2017-06-08 19:52 GMT+08:00 Paolo Bonzini :
>
> 3) add an async_page_fault member to vcpu->arch.exception
Do you think we should also add an async_page_fault field to
x86_exception, then pass down to kvm_inject_page_fault() through
x86_exception? Maybe we should modify
2017-06-08 19:52 GMT+08:00 Paolo Bonzini :
>
> 3) add an async_page_fault member to vcpu->arch.exception
Do you think we should also add an async_page_fault field to
x86_exception, then pass down to kvm_inject_page_fault() through
x86_exception? Maybe we should modify
On 08/06/2017 14:32, Wanpeng Li wrote:
>>> I change the
>>> condition to "nr == PF_VECTOR && error_code == 0" to intercept async_pf,
>>> however,
>>> the below bug will be splatted:
>> Right, because error_code == 0 is a valid error code.
>>
>> For stable releases, this should be enough:
>
>
On 08/06/2017 14:32, Wanpeng Li wrote:
>>> I change the
>>> condition to "nr == PF_VECTOR && error_code == 0" to intercept async_pf,
>>> however,
>>> the below bug will be splatted:
>> Right, because error_code == 0 is a valid error code.
>>
>> For stable releases, this should be enough:
>
>
2017-06-08 19:52 GMT+08:00 Paolo Bonzini :
>
>
> On 08/06/2017 11:30, Wanpeng Li wrote:
>> However, I found that "nr == PF_VECTOR && vmx->apf_reason != 0" never be true
>> in nested_vmx_check_exception(). SVM depends on the similar stuff in
>> nested_svm_intercept() which
2017-06-08 19:52 GMT+08:00 Paolo Bonzini :
>
>
> On 08/06/2017 11:30, Wanpeng Li wrote:
>> However, I found that "nr == PF_VECTOR && vmx->apf_reason != 0" never be true
>> in nested_vmx_check_exception(). SVM depends on the similar stuff in
>> nested_svm_intercept() which makes me confusing how it
On 08/06/2017 11:30, Wanpeng Li wrote:
> However, I found that "nr == PF_VECTOR && vmx->apf_reason != 0" never be true
> in nested_vmx_check_exception(). SVM depends on the similar stuff in
> nested_svm_intercept() which makes me confusing how it can works. In
> addition,
>
On 08/06/2017 11:30, Wanpeng Li wrote:
> However, I found that "nr == PF_VECTOR && vmx->apf_reason != 0" never be true
> in nested_vmx_check_exception(). SVM depends on the similar stuff in
> nested_svm_intercept() which makes me confusing how it can works. In
> addition,
>
INFO: task gnome-terminal-:1734 blocked for more than 120 seconds.
Not tainted 4.12.0-rc4+ #8
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
gnome-terminal- D0 1734 1015 0x
Call Trace:
__schedule+0x3cd/0xb30
schedule+0x40/0x90
INFO: task gnome-terminal-:1734 blocked for more than 120 seconds.
Not tainted 4.12.0-rc4+ #8
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
gnome-terminal- D0 1734 1015 0x
Call Trace:
__schedule+0x3cd/0xb30
schedule+0x40/0x90
12 matches
Mail list logo