On 2013-09-02 20:20, Jan Kiszka wrote:
> On 2013-09-02 20:09, Gleb Natapov wrote:
>> On Mon, Sep 02, 2013 at 07:58:30PM +0200, Jan Kiszka wrote:
>>> On 2013-09-02 15:16, Gleb Natapov wrote:
>>>> On Thu, Aug 08, 2013 at 04:26:30PM +0200, Jan Kiszka wrote:
>>>>> We need to update EFER.NX before building the nEPT state via
>>>>> nested_ept_init_mmu_context. Otherwise, we risk to create an MMU context
>>>>> that claims to have NX disabled while the guest EPT used NX. This will
>>>>> cause spurious faults for L2.
>>>>>
>>>> Hmm, I do not see how nested ept mmu depends on guests EFER.NX setting.
>>>> It just sets mmu->nx to true.
>>>
>>> Don't ask me for the details behind this, but update_permission_bitmask
>>> called by kvm_init_shadow_ept_mmu is using it e.g. And the
>> It uses it only in !ept case though and never looks at a guest setting
>> as far as I can tell. Is it possible that this was an artifact of all
>> nEPT code and the latest one does not need this patch?
>
> Hmm, possibly. Let me recheck, hope I can find the reproduction pattern
> again...
Yeah, drop it. Things work fine without it, and I just found an old
version of nEPT where kvm_init_shadow_EPT_mmu did this:
context->nx = is_nx(vcpu); /* TODO: ? */
Obviously, this patch was a workaround for that issue.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
