Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1544108 > unrolled thread

Re: [PATCH] x86/head: Refactor 32-bit pgtable setup

Started byIngo Molnar <mingo@kernel.org>
First post2016-12-18 09:50 +0100
Last post2016-12-19 15:10 +0100
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH] x86/head: Refactor 32-bit pgtable setup Ingo Molnar <mingo@kernel.org> - 2016-12-18 09:50 +0100
    Re: [PATCH] x86/head: Refactor 32-bit pgtable setup Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-12-19 15:10 +0100

#1544108 — Re: [PATCH] x86/head: Refactor 32-bit pgtable setup

FromIngo Molnar <mingo@kernel.org>
Date2016-12-18 09:50 +0100
SubjectRe: [PATCH] x86/head: Refactor 32-bit pgtable setup
Message-ID<sPFkl-5jX-1@gated-at.bofh.it>
* Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:

> On 12/08/2016 11:33 PM, Ingo Molnar wrote:
> > * Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
> >
> >> The new Xen PVH entry point requires page tables to be setup by the
> >> kernel since it is entered with paging disabled.
> >>
> >> Pull the common code out of head_32.S so that mk_early_pgtbl_32 can be
> >> invoked from both the new Xen entry point and the existing startup_32
> >> code.
> >>
> >> Convert resulting common code to C.
> >>
> >> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> >> ---
> >> This is replacement for https://lkml.org/lkml/2016/10/14/434, with
> >> assembly code re-written in C as requested by Ingo.
> >>
> >>
> >>  arch/x86/include/asm/pgtable_32.h |  32 ++++++++++
> >>  arch/x86/kernel/head32.c          |  62 +++++++++++++++++++
> >>  arch/x86/kernel/head_32.S         | 122 +++-----------------------------------
> >>  3 files changed, 101 insertions(+), 115 deletions(-)
> > Whee, I love it! And the code is so much more readable!
> >
> > Did you have any particular robustness problems (difficult to resolve crashes) 
> > while developing it, or was it reasonably straightforward to do?
> 
> There was nothing particularly difficult beyond understanding current
> code. That, of course, is not to say that there were no crashes but
> developing this on a guest gives you pretty good insight into why/where
> you crashed.
> 
> This was tested on bare-metal (in case you are wondering), but obviously
> more testing is always good.

Ok, cool!

Would you like to carry this with your other Xen dependencies? If yes:

   Acked-by: Ingo Molnar <mingo@kernel.org>

If not then I can pick it up and get it to Linus in v4.10.

Thanks,

	Ingo

[toc] | [next] | [standalone]


#1544547

FromBoris Ostrovsky <boris.ostrovsky@oracle.com>
Date2016-12-19 15:10 +0100
Message-ID<sQ6Nz-lK-13@gated-at.bofh.it>
In reply to#1544108
On 12/18/2016 03:44 AM, Ingo Molnar wrote:
> * Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
>
>> On 12/08/2016 11:33 PM, Ingo Molnar wrote:
>>> * Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote:
>>>
>>>> The new Xen PVH entry point requires page tables to be setup by the
>>>> kernel since it is entered with paging disabled.
>>>>
>>>> Pull the common code out of head_32.S so that mk_early_pgtbl_32 can be
>>>> invoked from both the new Xen entry point and the existing startup_32
>>>> code.
>>>>
>>>> Convert resulting common code to C.
>>>>
>>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>>> ---
>>>> This is replacement for https://lkml.org/lkml/2016/10/14/434, with
>>>> assembly code re-written in C as requested by Ingo.
>>>>
>>>>
>>>>  arch/x86/include/asm/pgtable_32.h |  32 ++++++++++
>>>>  arch/x86/kernel/head32.c          |  62 +++++++++++++++++++
>>>>  arch/x86/kernel/head_32.S         | 122 +++-----------------------------------
>>>>  3 files changed, 101 insertions(+), 115 deletions(-)
>>> Whee, I love it! And the code is so much more readable!
>>>
>>> Did you have any particular robustness problems (difficult to resolve crashes) 
>>> while developing it, or was it reasonably straightforward to do?
>> There was nothing particularly difficult beyond understanding current
>> code. That, of course, is not to say that there were no crashes but
>> developing this on a guest gives you pretty good insight into why/where
>> you crashed.
>>
>> This was tested on bare-metal (in case you are wondering), but obviously
>> more testing is always good.
> Ok, cool!
>
> Would you like to carry this with your other Xen dependencies? If yes:
>
>    Acked-by: Ingo Molnar <mingo@kernel.org>
>
> If not then I can pick it up and get it to Linus in v4.10.


I don't think my series will get into 4.10 since it is has a dependency
on hypervisor code that is still being reviewed.

If you could take it via your tree it would be great. Thanks!

-boris

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web