[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171108095854.b7gqsc44x4jl7b4b@gmail.com>
Date: Wed, 8 Nov 2017 10:58:54 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Juergen Gross <jgross@...e.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, kvm@...r.kernel.org,
xen-devel@...ts.xenproject.org, tglx@...utronix.de,
mingo@...hat.com, hpa@...or.com, boris.ostrovsky@...cle.com,
pbonzini@...hat.com, rkrcmar@...hat.com, rjw@...ysocki.net,
len.brown@...el.com, pavel@....cz
Subject: Re: [PATCH 2/3] x86: add guest_late_init hook to hypervisor_x86
structure
* Juergen Gross <jgross@...e.com> wrote:
> On 08/11/17 10:40, Ingo Molnar wrote:
> >
> > * Juergen Gross <jgross@...e.com> wrote:
> >
> >>> Plus add a default empty function (which hypervisors can override). This avoids
> >>> all the hidden conditions and wrappery.
> >>
> >> Hmm, x86_hyper is just a pointer being NULL on bare metal. So we would
> >> have to add a pre-filled struct with dummy functions and in case a
> >> hypervisor is detected we'd need to copy all non-NULL pointers of the
> >> hypervisor specific struct to the pre-filled one.
> >
> > Ok, I missed that detail - but yeah, since this is mostly about boot code,
> > where readability is king, I still think it would be an overall improvement.
> >
> > This is the pattern we are trying to use with x86_platform ops for example, and
> > doing:
> >
> > git grep -w x86_platform arch/x86
> >
> > gives a pretty clear idea about how it's used - while if it was all within
> > wrappers it would be a lot more difficult to discover all the callsites.
> >
> > Admittedly it's not done totally consistently:
> >
> > arch/x86/kernel/apic/probe_32.c: if (x86_platform.apic_post_init)
> > arch/x86/kernel/apic/probe_64.c: if (x86_platform.apic_post_init)
> > arch/x86/kernel/ebda.c: if (!x86_platform.legacy.reserve_bios_regions)
> > arch/x86/kernel/platform-quirks.c: if (x86_platform.set_legacy_features)
> > arch/x86/platform/intel-mid/device_libs/platform_mrfld_rtc.c: if (!x86_platform.legacy.rtc)
> >
> > ... but the _idea_ behind it is consistent ;-)
> >
> >> In case there are no objections I can add a patch to modify the current
> >> way x86_hyper is used to the pre-filled variant.
> >
> > Yeah, sounds good to me!
>
> Okay. With you mentioning x86_platform: should I make x86_hyper a member
> of x86_platform (e.g. x86_platform.hyper.) ?
>
> I think this would fit quite nice.
Yeah, seems like a good idea!
Thanks,
Ingo
Powered by blists - more mailing lists