This was effectively lost while dropping PVHv1 code. Move the function
and arrange for it to be called the same way as done in PV mode. Clearly
this then needs re-introducing the XENFEAT_mmu_pt_update_preserve_ad
check that was recently removed, as that's a PV-only feature.
Signed-off-by: Jan Beulich <[email protected]>
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -261,6 +261,18 @@ int xen_vcpu_setup(int cpu)
return ((per_cpu(xen_vcpu, cpu) == NULL) ? -ENODEV : 0);
}
+void __init xen_banner(void)
+{
+ unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
+ struct xen_extraversion extra;
+ HYPERVISOR_xen_version(XENVER_extraversion, &extra);
+
+ pr_info("Booting paravirtualized kernel on %s\n", pv_info.name);
+ pr_info("Xen version: %u.%u%s%s\n",
+ version >> 16, version & 0xffff, extra.extraversion,
+ xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
+}
+
/* Check if running on Xen version (major, minor) or later */
bool xen_running_on_version_or_later(unsigned int major, unsigned int minor)
{
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -108,17 +108,6 @@ struct tls_descs {
*/
static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
-static void __init xen_banner(void)
-{
- unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
- struct xen_extraversion extra;
- HYPERVISOR_xen_version(XENVER_extraversion, &extra);
-
- pr_info("Booting paravirtualized kernel on %s\n", pv_info.name);
- pr_info("Xen version: %d.%d%s (preserve-AD)\n",
- version >> 16, version & 0xffff, extra.extraversion);
-}
-
static void __init xen_pv_init_platform(void)
{
populate_extra_pte(fix_to_virt(FIX_PARAVIRT_BOOTMAP));
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -38,6 +38,7 @@ void __init xen_pvh_init(struct boot_par
if (xen_initial_domain())
x86_init.oem.arch_setup = xen_add_preferred_consoles;
+ x86_init.oem.banner = xen_banner;
xen_efi_init(boot_params);
}
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -51,6 +51,7 @@ void __init xen_remap_memory(void);
phys_addr_t __init xen_find_free_area(phys_addr_t size);
char * __init xen_memory_setup(void);
void __init xen_arch_setup(void);
+void xen_banner(void);
void xen_enable_sysenter(void);
void xen_enable_syscall(void);
void xen_vcpu_restore(void);
On 07.09.21 12:11, Jan Beulich wrote:
> This was effectively lost while dropping PVHv1 code. Move the function
> and arrange for it to be called the same way as done in PV mode. Clearly
> this then needs re-introducing the XENFEAT_mmu_pt_update_preserve_ad
> check that was recently removed, as that's a PV-only feature.
>
> Signed-off-by: Jan Beulich <[email protected]>
>
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -261,6 +261,18 @@ int xen_vcpu_setup(int cpu)
> return ((per_cpu(xen_vcpu, cpu) == NULL) ? -ENODEV : 0);
> }
>
> +void __init xen_banner(void)
> +{
> + unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
> + struct xen_extraversion extra;
Please add a blank line here.
> + HYPERVISOR_xen_version(XENVER_extraversion, &extra);
> +
> + pr_info("Booting paravirtualized kernel on %s\n", pv_info.name);
Is this correct? I don't think the kernel needs to be paravirtualized
with PVH (at least not to the same extend as for PV).
Juergen
On 23.09.2021 16:59, Juergen Gross wrote:
> On 07.09.21 12:11, Jan Beulich wrote:
>> This was effectively lost while dropping PVHv1 code. Move the function
>> and arrange for it to be called the same way as done in PV mode. Clearly
>> this then needs re-introducing the XENFEAT_mmu_pt_update_preserve_ad
>> check that was recently removed, as that's a PV-only feature.
>>
>> Signed-off-by: Jan Beulich <[email protected]>
>>
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -261,6 +261,18 @@ int xen_vcpu_setup(int cpu)
>> return ((per_cpu(xen_vcpu, cpu) == NULL) ? -ENODEV : 0);
>> }
>>
>> +void __init xen_banner(void)
>> +{
>> + unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
>> + struct xen_extraversion extra;
>
> Please add a blank line here.
Oops.
>> + HYPERVISOR_xen_version(XENVER_extraversion, &extra);
>> +
>> + pr_info("Booting paravirtualized kernel on %s\n", pv_info.name);
>
> Is this correct? I don't think the kernel needs to be paravirtualized
> with PVH (at least not to the same extend as for PV).
What else do you suggest the message to say? Simply drop
"paravirtualized"? To some extent it is applicable imo, further
qualified by pv_info.name. And that's how it apparently was with
PVHv1.
Jan
On 23.09.21 17:10, Jan Beulich wrote:
> On 23.09.2021 16:59, Juergen Gross wrote:
>> On 07.09.21 12:11, Jan Beulich wrote:
>>> This was effectively lost while dropping PVHv1 code. Move the function
>>> and arrange for it to be called the same way as done in PV mode. Clearly
>>> this then needs re-introducing the XENFEAT_mmu_pt_update_preserve_ad
>>> check that was recently removed, as that's a PV-only feature.
>>>
>>> Signed-off-by: Jan Beulich <[email protected]>
>>>
>>> --- a/arch/x86/xen/enlighten.c
>>> +++ b/arch/x86/xen/enlighten.c
>>> @@ -261,6 +261,18 @@ int xen_vcpu_setup(int cpu)
>>> return ((per_cpu(xen_vcpu, cpu) == NULL) ? -ENODEV : 0);
>>> }
>>>
>>> +void __init xen_banner(void)
>>> +{
>>> + unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
>>> + struct xen_extraversion extra;
>>
>> Please add a blank line here.
>
> Oops.
>
>>> + HYPERVISOR_xen_version(XENVER_extraversion, &extra);
>>> +
>>> + pr_info("Booting paravirtualized kernel on %s\n", pv_info.name);
>>
>> Is this correct? I don't think the kernel needs to be paravirtualized
>> with PVH (at least not to the same extend as for PV).
>
> What else do you suggest the message to say? Simply drop
> "paravirtualized"? To some extent it is applicable imo, further
> qualified by pv_info.name. And that's how it apparently was with
> PVHv1.
The string could be selected depending on CONFIG_XEN_PV.
Juergen
On 23.09.2021 17:15, Juergen Gross wrote:
> On 23.09.21 17:10, Jan Beulich wrote:
>> On 23.09.2021 16:59, Juergen Gross wrote:
>>> On 07.09.21 12:11, Jan Beulich wrote:
>>>> This was effectively lost while dropping PVHv1 code. Move the function
>>>> and arrange for it to be called the same way as done in PV mode. Clearly
>>>> this then needs re-introducing the XENFEAT_mmu_pt_update_preserve_ad
>>>> check that was recently removed, as that's a PV-only feature.
>>>>
>>>> Signed-off-by: Jan Beulich <[email protected]>
>>>>
>>>> --- a/arch/x86/xen/enlighten.c
>>>> +++ b/arch/x86/xen/enlighten.c
>>>> @@ -261,6 +261,18 @@ int xen_vcpu_setup(int cpu)
>>>> return ((per_cpu(xen_vcpu, cpu) == NULL) ? -ENODEV : 0);
>>>> }
>>>>
>>>> +void __init xen_banner(void)
>>>> +{
>>>> + unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
>>>> + struct xen_extraversion extra;
>>>
>>> Please add a blank line here.
>>
>> Oops.
>>
>>>> + HYPERVISOR_xen_version(XENVER_extraversion, &extra);
>>>> +
>>>> + pr_info("Booting paravirtualized kernel on %s\n", pv_info.name);
>>>
>>> Is this correct? I don't think the kernel needs to be paravirtualized
>>> with PVH (at least not to the same extend as for PV).
>>
>> What else do you suggest the message to say? Simply drop
>> "paravirtualized"? To some extent it is applicable imo, further
>> qualified by pv_info.name. And that's how it apparently was with
>> PVHv1.
>
> The string could be selected depending on CONFIG_XEN_PV.
Hmm, now I'm confused: Doesn't this setting control whether the kernel
can run in PV mode? If so, that functionality being present should have
no effect on the functionality of the kernel when running in PVH mode.
So what you suggest would end up in misleading information imo.
Jan
On 23.09.21 17:19, Jan Beulich wrote:
> On 23.09.2021 17:15, Juergen Gross wrote:
>> On 23.09.21 17:10, Jan Beulich wrote:
>>> On 23.09.2021 16:59, Juergen Gross wrote:
>>>> On 07.09.21 12:11, Jan Beulich wrote:
>>>>> This was effectively lost while dropping PVHv1 code. Move the function
>>>>> and arrange for it to be called the same way as done in PV mode. Clearly
>>>>> this then needs re-introducing the XENFEAT_mmu_pt_update_preserve_ad
>>>>> check that was recently removed, as that's a PV-only feature.
>>>>>
>>>>> Signed-off-by: Jan Beulich <[email protected]>
>>>>>
>>>>> --- a/arch/x86/xen/enlighten.c
>>>>> +++ b/arch/x86/xen/enlighten.c
>>>>> @@ -261,6 +261,18 @@ int xen_vcpu_setup(int cpu)
>>>>> return ((per_cpu(xen_vcpu, cpu) == NULL) ? -ENODEV : 0);
>>>>> }
>>>>>
>>>>> +void __init xen_banner(void)
>>>>> +{
>>>>> + unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
>>>>> + struct xen_extraversion extra;
>>>>
>>>> Please add a blank line here.
>>>
>>> Oops.
>>>
>>>>> + HYPERVISOR_xen_version(XENVER_extraversion, &extra);
>>>>> +
>>>>> + pr_info("Booting paravirtualized kernel on %s\n", pv_info.name);
>>>>
>>>> Is this correct? I don't think the kernel needs to be paravirtualized
>>>> with PVH (at least not to the same extend as for PV).
>>>
>>> What else do you suggest the message to say? Simply drop
>>> "paravirtualized"? To some extent it is applicable imo, further
>>> qualified by pv_info.name. And that's how it apparently was with
>>> PVHv1.
>>
>> The string could be selected depending on CONFIG_XEN_PV.
>
> Hmm, now I'm confused: Doesn't this setting control whether the kernel
> can run in PV mode? If so, that functionality being present should have
> no effect on the functionality of the kernel when running in PVH mode.
> So what you suggest would end up in misleading information imo.
Hmm, yes, I mixed "paravirtualized" with "capable to run
paravirtualized".
So the string should depend on xen_pv_domain().
Juergen
On 23.09.2021 17:25, Juergen Gross wrote:
> On 23.09.21 17:19, Jan Beulich wrote:
>> On 23.09.2021 17:15, Juergen Gross wrote:
>>> On 23.09.21 17:10, Jan Beulich wrote:
>>>> On 23.09.2021 16:59, Juergen Gross wrote:
>>>>> On 07.09.21 12:11, Jan Beulich wrote:
>>>>>> This was effectively lost while dropping PVHv1 code. Move the function
>>>>>> and arrange for it to be called the same way as done in PV mode. Clearly
>>>>>> this then needs re-introducing the XENFEAT_mmu_pt_update_preserve_ad
>>>>>> check that was recently removed, as that's a PV-only feature.
>>>>>>
>>>>>> Signed-off-by: Jan Beulich <[email protected]>
>>>>>>
>>>>>> --- a/arch/x86/xen/enlighten.c
>>>>>> +++ b/arch/x86/xen/enlighten.c
>>>>>> @@ -261,6 +261,18 @@ int xen_vcpu_setup(int cpu)
>>>>>> return ((per_cpu(xen_vcpu, cpu) == NULL) ? -ENODEV : 0);
>>>>>> }
>>>>>>
>>>>>> +void __init xen_banner(void)
>>>>>> +{
>>>>>> + unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
>>>>>> + struct xen_extraversion extra;
>>>>>
>>>>> Please add a blank line here.
>>>>
>>>> Oops.
>>>>
>>>>>> + HYPERVISOR_xen_version(XENVER_extraversion, &extra);
>>>>>> +
>>>>>> + pr_info("Booting paravirtualized kernel on %s\n", pv_info.name);
>>>>>
>>>>> Is this correct? I don't think the kernel needs to be paravirtualized
>>>>> with PVH (at least not to the same extend as for PV).
>>>>
>>>> What else do you suggest the message to say? Simply drop
>>>> "paravirtualized"? To some extent it is applicable imo, further
>>>> qualified by pv_info.name. And that's how it apparently was with
>>>> PVHv1.
>>>
>>> The string could be selected depending on CONFIG_XEN_PV.
>>
>> Hmm, now I'm confused: Doesn't this setting control whether the kernel
>> can run in PV mode? If so, that functionality being present should have
>> no effect on the functionality of the kernel when running in PVH mode.
>> So what you suggest would end up in misleading information imo.
>
> Hmm, yes, I mixed "paravirtualized" with "capable to run
> paravirtualized".
>
> So the string should depend on xen_pv_domain().
But that's already expressed by pv_info.name then being "Xen PV".
Jan
On 23.09.21 17:31, Jan Beulich wrote:
> On 23.09.2021 17:25, Juergen Gross wrote:
>> On 23.09.21 17:19, Jan Beulich wrote:
>>> On 23.09.2021 17:15, Juergen Gross wrote:
>>>> On 23.09.21 17:10, Jan Beulich wrote:
>>>>> On 23.09.2021 16:59, Juergen Gross wrote:
>>>>>> On 07.09.21 12:11, Jan Beulich wrote:
>>>>>>> This was effectively lost while dropping PVHv1 code. Move the function
>>>>>>> and arrange for it to be called the same way as done in PV mode. Clearly
>>>>>>> this then needs re-introducing the XENFEAT_mmu_pt_update_preserve_ad
>>>>>>> check that was recently removed, as that's a PV-only feature.
>>>>>>>
>>>>>>> Signed-off-by: Jan Beulich <[email protected]>
>>>>>>>
>>>>>>> --- a/arch/x86/xen/enlighten.c
>>>>>>> +++ b/arch/x86/xen/enlighten.c
>>>>>>> @@ -261,6 +261,18 @@ int xen_vcpu_setup(int cpu)
>>>>>>> return ((per_cpu(xen_vcpu, cpu) == NULL) ? -ENODEV : 0);
>>>>>>> }
>>>>>>>
>>>>>>> +void __init xen_banner(void)
>>>>>>> +{
>>>>>>> + unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
>>>>>>> + struct xen_extraversion extra;
>>>>>>
>>>>>> Please add a blank line here.
>>>>>
>>>>> Oops.
>>>>>
>>>>>>> + HYPERVISOR_xen_version(XENVER_extraversion, &extra);
>>>>>>> +
>>>>>>> + pr_info("Booting paravirtualized kernel on %s\n", pv_info.name);
>>>>>>
>>>>>> Is this correct? I don't think the kernel needs to be paravirtualized
>>>>>> with PVH (at least not to the same extend as for PV).
>>>>>
>>>>> What else do you suggest the message to say? Simply drop
>>>>> "paravirtualized"? To some extent it is applicable imo, further
>>>>> qualified by pv_info.name. And that's how it apparently was with
>>>>> PVHv1.
>>>>
>>>> The string could be selected depending on CONFIG_XEN_PV.
>>>
>>> Hmm, now I'm confused: Doesn't this setting control whether the kernel
>>> can run in PV mode? If so, that functionality being present should have
>>> no effect on the functionality of the kernel when running in PVH mode.
>>> So what you suggest would end up in misleading information imo.
>>
>> Hmm, yes, I mixed "paravirtualized" with "capable to run
>> paravirtualized".
>>
>> So the string should depend on xen_pv_domain().
>
> But that's already expressed by pv_info.name then being "Xen PV".
True. Okay, I'm fine with just dropping "paravirtualized".
Juergen
On 29.09.2021 07:45, Juergen Gross wrote:
> On 23.09.21 17:31, Jan Beulich wrote:
>> On 23.09.2021 17:25, Juergen Gross wrote:
>>> On 23.09.21 17:19, Jan Beulich wrote:
>>>> On 23.09.2021 17:15, Juergen Gross wrote:
>>>>> On 23.09.21 17:10, Jan Beulich wrote:
>>>>>> On 23.09.2021 16:59, Juergen Gross wrote:
>>>>>>> On 07.09.21 12:11, Jan Beulich wrote:
>>>>>>>> This was effectively lost while dropping PVHv1 code. Move the function
>>>>>>>> and arrange for it to be called the same way as done in PV mode. Clearly
>>>>>>>> this then needs re-introducing the XENFEAT_mmu_pt_update_preserve_ad
>>>>>>>> check that was recently removed, as that's a PV-only feature.
>>>>>>>>
>>>>>>>> Signed-off-by: Jan Beulich <[email protected]>
>>>>>>>>
>>>>>>>> --- a/arch/x86/xen/enlighten.c
>>>>>>>> +++ b/arch/x86/xen/enlighten.c
>>>>>>>> @@ -261,6 +261,18 @@ int xen_vcpu_setup(int cpu)
>>>>>>>> return ((per_cpu(xen_vcpu, cpu) == NULL) ? -ENODEV : 0);
>>>>>>>> }
>>>>>>>>
>>>>>>>> +void __init xen_banner(void)
>>>>>>>> +{
>>>>>>>> + unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
>>>>>>>> + struct xen_extraversion extra;
>>>>>>>
>>>>>>> Please add a blank line here.
>>>>>>
>>>>>> Oops.
>>>>>>
>>>>>>>> + HYPERVISOR_xen_version(XENVER_extraversion, &extra);
>>>>>>>> +
>>>>>>>> + pr_info("Booting paravirtualized kernel on %s\n", pv_info.name);
>>>>>>>
>>>>>>> Is this correct? I don't think the kernel needs to be paravirtualized
>>>>>>> with PVH (at least not to the same extend as for PV).
>>>>>>
>>>>>> What else do you suggest the message to say? Simply drop
>>>>>> "paravirtualized"? To some extent it is applicable imo, further
>>>>>> qualified by pv_info.name. And that's how it apparently was with
>>>>>> PVHv1.
>>>>>
>>>>> The string could be selected depending on CONFIG_XEN_PV.
>>>>
>>>> Hmm, now I'm confused: Doesn't this setting control whether the kernel
>>>> can run in PV mode? If so, that functionality being present should have
>>>> no effect on the functionality of the kernel when running in PVH mode.
>>>> So what you suggest would end up in misleading information imo.
>>>
>>> Hmm, yes, I mixed "paravirtualized" with "capable to run
>>> paravirtualized".
>>>
>>> So the string should depend on xen_pv_domain().
>>
>> But that's already expressed by pv_info.name then being "Xen PV".
>
> True. Okay, I'm fine with just dropping "paravirtualized".
Done. Do you want me to also make pr_info() vs printk(KERN_INFO ...)
consistent in the function at this occasion? If so - which of the two?
Jan
On 29.09.21 09:28, Jan Beulich wrote:
> On 29.09.2021 07:45, Juergen Gross wrote:
>> On 23.09.21 17:31, Jan Beulich wrote:
>>> On 23.09.2021 17:25, Juergen Gross wrote:
>>>> On 23.09.21 17:19, Jan Beulich wrote:
>>>>> On 23.09.2021 17:15, Juergen Gross wrote:
>>>>>> On 23.09.21 17:10, Jan Beulich wrote:
>>>>>>> On 23.09.2021 16:59, Juergen Gross wrote:
>>>>>>>> On 07.09.21 12:11, Jan Beulich wrote:
>>>>>>>>> This was effectively lost while dropping PVHv1 code. Move the function
>>>>>>>>> and arrange for it to be called the same way as done in PV mode. Clearly
>>>>>>>>> this then needs re-introducing the XENFEAT_mmu_pt_update_preserve_ad
>>>>>>>>> check that was recently removed, as that's a PV-only feature.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Jan Beulich <[email protected]>
>>>>>>>>>
>>>>>>>>> --- a/arch/x86/xen/enlighten.c
>>>>>>>>> +++ b/arch/x86/xen/enlighten.c
>>>>>>>>> @@ -261,6 +261,18 @@ int xen_vcpu_setup(int cpu)
>>>>>>>>> return ((per_cpu(xen_vcpu, cpu) == NULL) ? -ENODEV : 0);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> +void __init xen_banner(void)
>>>>>>>>> +{
>>>>>>>>> + unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
>>>>>>>>> + struct xen_extraversion extra;
>>>>>>>>
>>>>>>>> Please add a blank line here.
>>>>>>>
>>>>>>> Oops.
>>>>>>>
>>>>>>>>> + HYPERVISOR_xen_version(XENVER_extraversion, &extra);
>>>>>>>>> +
>>>>>>>>> + pr_info("Booting paravirtualized kernel on %s\n", pv_info.name);
>>>>>>>>
>>>>>>>> Is this correct? I don't think the kernel needs to be paravirtualized
>>>>>>>> with PVH (at least not to the same extend as for PV).
>>>>>>>
>>>>>>> What else do you suggest the message to say? Simply drop
>>>>>>> "paravirtualized"? To some extent it is applicable imo, further
>>>>>>> qualified by pv_info.name. And that's how it apparently was with
>>>>>>> PVHv1.
>>>>>>
>>>>>> The string could be selected depending on CONFIG_XEN_PV.
>>>>>
>>>>> Hmm, now I'm confused: Doesn't this setting control whether the kernel
>>>>> can run in PV mode? If so, that functionality being present should have
>>>>> no effect on the functionality of the kernel when running in PVH mode.
>>>>> So what you suggest would end up in misleading information imo.
>>>>
>>>> Hmm, yes, I mixed "paravirtualized" with "capable to run
>>>> paravirtualized".
>>>>
>>>> So the string should depend on xen_pv_domain().
>>>
>>> But that's already expressed by pv_info.name then being "Xen PV".
>>
>> True. Okay, I'm fine with just dropping "paravirtualized".
>
> Done. Do you want me to also make pr_info() vs printk(KERN_INFO ...)
> consistent in the function at this occasion? If so - which of the two?
pr_info(), please.
Juergen