[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: [PATCH] switch to a known good/static GDT before kexec



On 02/07/2009 11:52, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

> Thinking about this raises another question. Since your patch to allow
> arbitrary numbers of VCPUs per domain, does the GDT logic in
> __context_switch() work any more? What if you have a next vcpu n for which
> !need_full_gdt(n) but where its domain does not have a vcpu_id as large as
> p->vcpu_id? Won't you end up with a GDTR pointing at a non-existent mapping
> ('off the end' of n->domain's per-domain mappings)?

Okay, having read through __context_switch() in detail with Ian Campbell, we
decided the logic there is correct. If you switch to a !need_full_gdt() vcpu
then you always switch back to the default gdt_table, so the per-domain
mappings do not matter. This also explains why kexec now needs to forcibly
lgdt -- when it forcibly switches back to idle_pg_table the per-domain
mappings will not be there and so we fault on next segment reload.

I have one more question then -- when need_full_gdt(n), why do we always
unconditionally rewrite the l1es mapping the reserved gdt entries? Shouldn't
that be done on vcpu creation only and perhaps on compat mode switch (i.e.,
isn't it wasteful to do it in the context switch path)?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.