| Message ID | 20230126122406.14627-1-jgross@suse.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | tools/helpers: don't log errors when trying to load PVH xenstore-stubdom | expand |
On 26.01.2023 13:24, Juergen Gross wrote: > When loading a Xenstore stubdom the loader doesn't know whether the > lo be loaded kernel is a PVH or a PV one. So it tries to load it as > a PVH one first, and if this fails it is loading it as a PV kernel. > > This results in errors being logged in case the stubdom is a PV kernel. > > Suppress those errors by setting the minimum logging level to > "critical" while trying to load the kernel as PVH. And if the PV loading also fails and PVH was actually expected, then the messages will be heavily misleading? Shouldn't you instead accumulate the PVH messages, and throw them away only in case PV loading actually worked (or issue them at lower severity, in case they're actually of interest)? Jan
On 26.01.23 13:42, Jan Beulich wrote: > On 26.01.2023 13:24, Juergen Gross wrote: >> When loading a Xenstore stubdom the loader doesn't know whether the >> lo be loaded kernel is a PVH or a PV one. So it tries to load it as >> a PVH one first, and if this fails it is loading it as a PV kernel. >> >> This results in errors being logged in case the stubdom is a PV kernel. >> >> Suppress those errors by setting the minimum logging level to >> "critical" while trying to load the kernel as PVH. > > And if the PV loading also fails and PVH was actually expected, then the > messages will be heavily misleading? Shouldn't you instead accumulate the > PVH messages, and throw them away only in case PV loading actually worked > (or issue them at lower severity, in case they're actually of interest)? I think this would add a lot of code for little gain. What I could do is to repeat the PVH load attempt with full logging if the PV load fails, too. Juergen
diff --git a/tools/helpers/init-xenstore-domain.c b/tools/helpers/init-xenstore-domain.c index 04e351ca29..c323cf7456 100644 --- a/tools/helpers/init-xenstore-domain.c +++ b/tools/helpers/init-xenstore-domain.c @@ -31,6 +31,8 @@ static int memory; static int maxmem; static xen_pfn_t console_gfn; static xc_evtchn_port_or_error_t console_evtchn; +static xentoollog_level minmsglevel = XTL_PROGRESS; +static void *logger; static struct option options[] = { { "kernel", 1, NULL, 'k' }, @@ -141,8 +143,11 @@ static int build(xc_interface *xch) goto err; } + /* Try PVH first, suppress errors by setting min level high. */ dom->container_type = XC_DOM_HVM_CONTAINER; + xtl_stdiostream_set_minlevel(logger, XTL_CRITICAL); rv = xc_dom_parse_image(dom); + xtl_stdiostream_set_minlevel(logger, minmsglevel); if ( rv ) { dom->container_type = XC_DOM_PV_CONTAINER; @@ -412,8 +417,6 @@ int main(int argc, char** argv) char buf[16], be_path[64], fe_path[64]; int rv, fd; char *maxmem_str = NULL; - xentoollog_level minmsglevel = XTL_PROGRESS; - xentoollog_logger *logger = NULL; while ( (opt = getopt_long(argc, argv, "v", options, NULL)) != -1 ) { @@ -456,9 +459,7 @@ int main(int argc, char** argv) return 2; } - logger = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, - minmsglevel, 0); - + logger = xtl_createlogger_stdiostream(stderr, minmsglevel, 0); xch = xc_interface_open(logger, logger, 0); if ( !xch ) {
When loading a Xenstore stubdom the loader doesn't know whether the lo be loaded kernel is a PVH or a PV one. So it tries to load it as a PVH one first, and if this fails it is loading it as a PV kernel. This results in errors being logged in case the stubdom is a PV kernel. Suppress those errors by setting the minimum logging level to "critical" while trying to load the kernel as PVH. Fixes: f89955449c5a ("tools/init-xenstore-domain: support xenstore pvh stubdom") Signed-off-by: Juergen Gross <jgross@suse.com> --- tools/helpers/init-xenstore-domain.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)