lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 23 Sep 2021 17:25:30 +0200 From: Juergen Gross <jgross@...e.com> To: Jan Beulich <jbeulich@...e.com> Cc: Stefano Stabellini <sstabellini@...nel.org>, lkml <linux-kernel@...r.kernel.org>, "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>, Boris Ostrovsky <boris.ostrovsky@...cle.com> Subject: Re: [PATCH 7/9] xen/x86: hook up xen_banner() also for PVH 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 <jbeulich@...e.com> >>>>> >>>>> --- 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 Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3092 bytes) Download attachment "OpenPGP_signature" of type "application/pgp-signature" (496 bytes)
Powered by blists - more mailing lists