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).
> > + /*
> > + * The guest is invalidating a TLB0 entry which in in a PID
>
> in in?
>
"is in", sorry.
-Scott
--
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
