On 14.06.2011, at 21:37, Scott Wood wrote:
> On Tue, 14 Jun 2011 12:41:03 +0200
> Alexander Graf <agraf@xxxxxxx> wrote:
>
>>
>> On 03.06.2011, at 01:17, Scott Wood wrote:
>>
>>> +static void kvmppc_e500_stlbe_invalidate(struct kvmppc_vcpu_e500 *vcpu_e500,
>>> + int tlbsel, int esel)
>>> +{
>>> + struct tlbe *gtlbe = &vcpu_e500->gtlb_arch[tlbsel][esel];
>>> + struct vcpu_id_table *idt = vcpu_e500->idt;
>>> + unsigned int pr, tid, ts, pid;
>>> + u32 val, eaddr;
>>> + unsigned long flags;
>>> +
>>> + ts = get_tlb_ts(gtlbe);
>>> + tid = get_tlb_tid(gtlbe);
>>> +
>>> + preempt_disable();
>>> +
>>> + /* One guest ID may be mapped to two shadow IDs */
>>> + for (pr = 0; pr < 2; pr++) {
>>> + /*
>>> + * The shadow PID can have a valid mapping on at most one
>>> + * host CPU. In the common case, it will be valid on this
>>
>> Not sure I understand this part. Who ensures that a shadow pid is only valid on a single CPU?
>
> vcpu_e500->idt->id[...]->pentry can only point to one place at a time. Any
> other shadow PIDs (e.g. on other host CPUs) that it used to point to are
> now invalid, and will not be re-used if the vcpu returns to that host CPU
> (other than by having that host CPU reset its shadow PIDs once
> they're exhausted, invalidating everything).
>
> The linkage must match in both directions in local_sid_lookup(), or a new
> shadow ID will be allocated (and the old one put out of use when pentry is
> updated).
Ah, and since the other direction is vcpu local, there's no need to do anything atomically. Very nice indeed.
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
