The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Cao jin <caoj.fnst@cn.fujitsu.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>, <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	<kirill.shutemov@linux.intel.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: question about head_64.S
Date: Wed, 16 Jan 2019 17:44:26 +0800	[thread overview]
Message-ID: <642e4121-229f-7627-7f1d-737eb8ed4e5f@cn.fujitsu.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1901151641000.1561@nanos.tec.linutronix.de>

On 1/15/19 11:55 PM, Thomas Gleixner wrote:
> On Tue, 15 Jan 2019, Cao jin wrote:
> 
>> Hi,
>>   I have been digging into this file for a while, and I still have 2
>> questions unclear, hope to get your help.
>>
>> 1.
>> At the entry of startup_64, we set all the data segment registers to 0,
>> according to commit 08da5a2ca("x86_64: Early segment setup for VT"), it
>> is said to accelerate the decompression under VT. I don't know Intel VT,
>> but I did test under physical machine and virtual machine(with KVM, and
>> intel VT enabled in BIOS) with following patch:
>>
>> diff --git a/arch/x86/boot/compressed/head_64.S
>> b/arch/x86/boot/compressed/head_64.S
>> index 58f6a467f1fa..595f3c300173 100644
>> --- a/arch/x86/boot/compressed/head_64.S
>> +++ b/arch/x86/boot/compressed/head_64.S
>> @@ -260,12 +260,12 @@ ENTRY(startup_64)
>>          */
>>
>>         /* Setup data segments. */
>> -       xorl    %eax, %eax
>> -       movl    %eax, %ds
>> -       movl    %eax, %es
>> -       movl    %eax, %ss
>> -       movl    %eax, %fs
>> -       movl    %eax, %gs
>> +//     xorl    %eax, %eax
>> +//     movl    %eax, %ds
>> +//     movl    %eax, %es
>> +//     movl    %eax, %ss
>> +//     movl    %eax, %fs
>> +//     movl    %eax, %gs
>>
>> I don't see any obvious booting time difference, is there anything I missed?
>> Also, I don't find explicit document saying we should zero these
>> registers under VT.
> 
> The decompressor is position independent code, so all segments have to be
> set to 0.
> 

Thank you Thomas! But I've never heard that PIC is correlated with
segment register value, could you elaborate a little bit? Because as I
know, startup_64 is in long mode, and CPU will treat all segment(except
fs, gs) base as 0, no matter whatever in them. And until now, I only see
fs is touched when parsing command line, not see any explicit gs usage.

On the other hand, I test the patch above, it can boot up, so seems
segment register value here is not necessary to be 0?

> The patch you mentioned was just adding fs/gs to the list of segments
> which are cleared and the commit message is not very clear. Though if you
> dig further down then you find the original version of that patch:
> 
>   commit ffb6017563aa("[PATCH] x86-64: x86_64 - Fix FS/GS registers for VT execution")
> 
> That one has a proper explantaion.
> 

Oh, I still not reach to the real kernel itself yet. At first glance,
"but it is important to reload them in protected mode" make sense to me.

But more confusion rise up: under 64-bit boot protocol, we can have more
than one entry? startup_64 in both:

  arch/x86/kernel/head_64.S
and
  arch/x86/boot/compressed/head_64.S

can be jumped to via bootloader? Seems Documentation/x86/boot.txt
doesn't say that.

-- 
Sincerely,
Cao jin



  reply	other threads:[~2019-01-16  9:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-15 11:45 question about head_64.S Cao jin
2019-01-15 15:55 ` Thomas Gleixner
2019-01-16  9:44   ` Cao jin [this message]
2019-01-22  7:31 ` Cao jin
2019-01-22 13:08   ` Kirill A. Shutemov
2019-01-23  4:01     ` Cao jin
2019-01-23 10:03       ` Kirill A. Shutemov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=642e4121-229f-7627-7f1d-737eb8ed4e5f@cn.fujitsu.com \
    --to=caoj.fnst@cn.fujitsu.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox