This makes the Xen console just work. Before, you had to ask for it
on the kernel command line with console=hvc0
Signed-off-by: Markus Armbruster <[email protected]>
---
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 49e5358..df63185 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -25,6 +25,7 @@
#include <linux/mm.h>
#include <linux/page-flags.h>
#include <linux/highmem.h>
+#include <linux/console.h>
#include <xen/interface/xen.h>
#include <xen/interface/physdev.h>
@@ -1209,6 +1210,9 @@ asmlinkage void __init xen_start_kernel(void)
? __pa(xen_start_info->mod_start) : 0;
boot_params.hdr.ramdisk_size = xen_start_info->mod_len;
+ if (!is_initial_xendomain())
+ add_preferred_console("hvc", 0, NULL);
+
/* Start the world */
start_kernel();
}
Markus Armbruster wrote:
> This makes the Xen console just work. Before, you had to ask for it
> on the kernel command line with console=hvc0
>
I see that this has been causing issues when people expect the pvfb
driver to be the console. Should we make it a config option, which
depends on !XENFB?
J
Jeremy Fitzhardinge <[email protected]> writes:
> Markus Armbruster wrote:
>> This makes the Xen console just work. Before, you had to ask for it
>> on the kernel command line with console=hvc0
>>
>
> I see that this has been causing issues when people expect the pvfb
> driver to be the console. Should we make it a config option, which
> depends on !XENFB?
>
> J
That's not quite right, I fear: you still lose if you have it compiled
into the guest, but switched off in your domain configuration.
I'm working on a better solution.