>>> Keir Fraser <keir@xxxxxxxxxxxxx> 13.07.07 18:26 >>>
>On 13/7/07 17:16, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>
>> Is there any reason (other than having things inherited this way from Linux)
>> that
>> we cannot call identify_cpu() for the boot CPU at the end of early_cpu_init()
>> rather than explicitly from __start_xen()? And if not, it would seem
>> reasonable
>> to me to at once move the two CR4 twiddling pieces out of __start_xen, too.
>>
>> (I'm not asking because I want to beautify the code, but because I want the
>> identify to happen earlier, namely I want to fully set up the VESA console as
>> early as possible, but there I'd like to be able to set MTRRs, which in turn
>> depends on identify_cpu() having executed.
>
>Isn't it a fairly safe bet that the BIOS will have done this for us and, if
>not, that the penalty is a performance loss (probably using WB or UC instead
>of WC) rather than a correctness issue? And hence, if we bother to update
>the MTRRs at all, then it can at least be left until later in the boot?
I've never seen a BIOS set the frame buffer to WC (or anything other than
uncachable), presumably not the least because the address space may get
laid out anew by the OS. And the performance loss in our case is quite
significant (though I assume WC would at best help a little, I'm considering
other approaches, too): Scrolling a 1280x1024x16 screen takes, on the test
system I'm primarily trying this out on, on the order of a second. This is
because we will want to not disturb what dom0 may have written to the
screen, and hence we can't simply redraw. And I'm not certain I want to
special case boot time here (although I may have no other option - delay
in that order can easily lead to other failures [like CPUs not properly coming
up]).
Of course, I could make the two stage vesafb initialization as it is right now
a three stage one, doing just the MTRR request in the last. But I wanted to
avoid making the code more spaghetti like than necessary just because of
this little feature...
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home