lkml.org 
[lkml]   [2021]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 6/9] xen/x86: generalize preferred console model from PV to PVH Dom0
Date
On 07.09.21 12:10, Jan Beulich wrote:
> Without announcing hvc0 as preferred it won't get used as long as tty0
> gets registered earlier. This is particularly problematic with there not
> being any screen output for PVH Dom0 when the screen is in graphics
> mode, as the necessary information doesn't get conveyed yet from the
> hypervisor.
>
> Follow PV's model, but be conservative and do this for Dom0 only for
> now.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Juergen Gross <jgross@suse.com>

> ---
> Prior to 418492ba40b2 ("x86/virt/xen: Use guest_late_init to detect Xen
> PVH guest") x86_init.oem.arch_setup was already used by PVH, so I assume
> the use of this hook is acceptable here.

Yes, I think so.

> Seeing that change, I wonder in how far setting xen_pvh to true only in
> xen_hvm_guest_late_init() can really work: This hook, as its name says,
> gets called pretty late; any decision taken earlier might have been
> wrong. One such wrong decision is what gets added here - preferred
> consoles won't be registered when taking that path. While adding a 2nd
> call there might work, aiui they would better be registered prior to
> parse_early_param(), i.e. before "earlyprintk=" gets evaluated.
>
> I also consider tying "detecting" PVH mode to the no-VGA and no-CMOS-RTC
> FADT flags as problematic looking forward: There may conceivably be
> "legacy free" HVM guests down the road, yet they shouldn't be mistaken
> for being PVH. Most of the XEN_X86_EMU_* controlled functionality would
> seem unsuitable for the same reason; presence/absence of
> XENFEAT_hvm_pirqs (tied to XEN_X86_EMU_USE_PIRQ) might be sufficiently
> reliable an indicator. Question there is whether the separation
> introduced by Xen commit b96b50004804 ("x86: remove XENFEAT_hvm_pirqs
> for PVHv2 guests") came early enough in the process of enabling PVHv2.

Yes, it did. The boot path not using the PVH specific entry point was
enabled with Xen 4.11, while commit b96b50004804 was in 4.9.


Juergen
[unhandled content-type:application/pgp-keys][unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2021-09-23 16:55    [W:0.242 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site