|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Re: [PATCH] switch to a known good/static GDTbeforekexec
>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 02.07.09 21:59 >>>
>On 02/07/2009 13:38, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:
>
>>>> 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)?
>>>
>>> While that's correct, we're talking about a single memory write here (plus
>>> the setup code), which I think is no more wasteful than adding the extra
>>> checking that would be needed to see whether we switch between
>>> compat and !compat (including the !need_full_gdt(p) case, where we
>>> don't know what kind of mapping we currently have).
>>
>> Hm yes, fair enough.
>
>Actually no, I'm not sure what extra checking you think you'd need? You'd
>create the per-vcpu mapping when a vcpu is created and when it changes
>to/from compat mode, and that would be it wouldn't it? You'd only delete
>code from __context_switch(); not add different code to it?
While you're right that my explanation wasn't really correct, moving this
back to the vCPU creation/mode-switching functions doesn't work because
the GDT is now per-CPU (and it's that patch where this code got added to
context switch): The installed mapping depends on the *physical* CPU the
code is running on. So the extra dependency that might be added here
would be to check whether the physical CPU the vCPU is running on
changed, but afair v->processor gets set before entering context_switch(),
so we'd have to additionally capture and store the last used value. Would
you think that's worth it?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|