Paul Mackerras <paulus@xxxxxxxxx> writes:
> On Sun, Jun 29, 2014 at 04:47:33PM +0530, Aneesh Kumar K.V wrote:
>> We want to use virtual page class key protection mechanism for
>> indicating a MMIO mapped hpte entry or a guest hpte entry that is swapped out
>> in the host. Those hptes will be marked valid, but have virtual page
>> class key set to 30 or 31. These virtual page class numbers are
>> configured in AMR to deny read/write. To accomodate such a change, add
>> new functions that map, unmap and check whether a hpte is mapped in the
>> host. This patch still use HPTE_V_VALID and HPTE_V_ABSENT and don't use
>> virtual page class keys. But we want to differentiate in the code
>> where we explicitly check for HPTE_V_VALID with places where we want to
>> check whether the hpte is host mapped. This patch enables a closer
>> review for such a change.
>
> [...]
>
>> /* Check for pending invalidations under the rmap chain lock */
>> if (kvm->arch.using_mmu_notifiers &&
>> mmu_notifier_retry(kvm, mmu_seq)) {
>> - /* inval in progress, write a non-present HPTE */
>> - pteh |= HPTE_V_ABSENT;
>> - pteh &= ~HPTE_V_VALID;
>> + /*
>> + * inval in progress in host, write host unmapped pte.
>> + */
>> + host_unmapped_hpte = 1;
>
> This isn't right. We already have HPTE_V_VALID set here, and you now
> don't clear it here, and it doesn't get cleared by the
> __kvmppc_unmap_host_hpte() call below either.
Ok missed that. Will fix that in the next update. In the earlier version
I had kvmppc_unmap_host_hpte always clearing V_VALID.
-aneesh
--
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
