We use a __stringify construction at paravirt_patch_64.c. It's better practice to include the stringify header directly Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> --- arch/x86/kernel/paravirt_patch_64.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/paravirt_patch_64.c b/arch/x86/kernel/paravirt_patch_64.c index cbfc4f3..7d904e1 100644 --- a/arch/x86/kernel/paravirt_patch_64.c +++ b/arch/x86/kernel/paravirt_patch_64.c @@ -1,5 +1,6 @@ #include <asm/paravirt.h> #include <asm/asm-offsets.h> +#include <linux/stringify.h> DEF_NATIVE(pv_irq_ops, irq_disable, "cli"); DEF_NATIVE(pv_irq_ops, irq_enable, "sti"); -- 1.4.4.2
Hi, This small series provides some more fixes towards the goal to have the PARAVIRT selectable for x86_64. After that, just some more small steps are needed. The first fix is not even specific for PARAVIRT, and it's actually preventing the whole tree from booting.
Glauber de Oliveira Costa
2008-Jan-18 12:03 UTC
[PATCH 1/10] add missing parameter for lookup_address
lookup_address() receives two parameters, but efi_64.c call
is passing only one. It's actually preventing the tree from compiling
Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com>
---
arch/x86/kernel/efi_64.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/efi_64.c b/arch/x86/kernel/efi_64.c
index f420819..1f8bbd9 100644
--- a/arch/x86/kernel/efi_64.c
+++ b/arch/x86/kernel/efi_64.c
@@ -45,9 +45,10 @@ static void __init early_mapping_set_exec(unsigned long
start,
int executable)
{
pte_t *kpte;
+ int level;
while (start < end) {
- kpte = lookup_address((unsigned long)__va(start));
+ kpte = lookup_address((unsigned long)__va(start), &level);
BUG_ON(!kpte);
if (executable)
set_pte(kpte, pte_mkexec(*kpte));
--
1.4.4.2
Glauber de Oliveira Costa
2008-Jan-18 12:04 UTC
[PATCH 8/10] add asm_offset PARAVIRT constants
This patch adds the constant PARAVIRT needs in asm_offsets_64.c Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> --- arch/x86/kernel/asm-offsets_64.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/asm-offsets_64.c b/arch/x86/kernel/asm-offsets_64.c index 2b32719..494e1e0 100644 --- a/arch/x86/kernel/asm-offsets_64.c +++ b/arch/x86/kernel/asm-offsets_64.c @@ -61,6 +61,20 @@ int main(void) ENTRY(data_offset); BLANK(); #undef ENTRY +#ifdef CONFIG_PARAVIRT + BLANK(); + OFFSET(PARAVIRT_enabled, pv_info, paravirt_enabled); + OFFSET(PARAVIRT_PATCH_pv_cpu_ops, paravirt_patch_template, pv_cpu_ops); + OFFSET(PARAVIRT_PATCH_pv_irq_ops, paravirt_patch_template, pv_irq_ops); + OFFSET(PV_IRQ_irq_disable, pv_irq_ops, irq_disable); + OFFSET(PV_IRQ_irq_enable, pv_irq_ops, irq_enable); + OFFSET(PV_CPU_iret, pv_cpu_ops, iret); + OFFSET(PV_CPU_irq_enable_syscall_ret, pv_cpu_ops, irq_enable_syscall_ret); + OFFSET(PV_CPU_swapgs, pv_cpu_ops, swapgs); + OFFSET(PV_MMU_read_cr2, pv_mmu_ops, read_cr2); +#endif + + #ifdef CONFIG_IA32_EMULATION #define ENTRY(entry) DEFINE(IA32_SIGCONTEXT_ ## entry, offsetof(struct sigcontext_ia32, entry)) ENTRY(ax); -- 1.4.4.2
* Glauber de Oliveira Costa <gcosta@redhat.com> wrote:> > This small series provides some more fixes towards the goal to have > the PARAVIRT selectable for x86_64. After that, just some more small > steps are needed.thanks, applied.> The first fix is not even specific for PARAVIRT, and it's actually > preventing the whole tree from booting.on CONFIG_EFI, indeed :) Ingo
On Jan 18, 2008 8:02 PM, Ingo Molnar <mingo@elte.hu> wrote:> > * Zachary Amsden <zach@vmware.com> wrote: > > > > but in exchange you broke all of 32-bit with CONFIG_PARAVIRT=y. > > > Which means you did not even build-test it on 32-bit, let alone boot > > > test it... > > > > Why are we rushing so much to do 64-bit paravirt that we are breaking > > working configurations? If the developement is going to be this > > chaotic, it should be done and tested out of tree until it can > > stabilize. > > what you see is a open feedback cycle conducted on lkml. People send > patches for arch/x86, and we tell them if it breaks something. The bug > was found before i pushed out the x86.git devel tree (and the fix is > below - but this shouldnt matter to you because the bug never hit a > public x86.git tree). > > Ingo >Other than this, it seems to build and boot fine. Do you want me to resend ? -- Glauber de Oliveira Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act."
* Glauber de Oliveira Costa <glommer@gmail.com> wrote:> On Jan 18, 2008 8:02 PM, Ingo Molnar <mingo@elte.hu> wrote: > > > > * Zachary Amsden <zach@vmware.com> wrote: > > > > > > but in exchange you broke all of 32-bit with CONFIG_PARAVIRT=y. > > > > Which means you did not even build-test it on 32-bit, let alone boot > > > > test it... > > > > > > Why are we rushing so much to do 64-bit paravirt that we are breaking > > > working configurations? If the developement is going to be this > > > chaotic, it should be done and tested out of tree until it can > > > stabilize. > > > > what you see is a open feedback cycle conducted on lkml. People send > > patches for arch/x86, and we tell them if it breaks something. The bug > > was found before i pushed out the x86.git devel tree (and the fix is > > below - but this shouldnt matter to you because the bug never hit a > > public x86.git tree). > > > > Ingo > > > Other than this, it seems to build and boot fine. > > Do you want me to resend ?no, this was the only small problem i found, your series looks good to me and is included in latest x86.git. Ingo