On 08/04/16 08:56, Luis R. Rodriguez wrote: > On Thu, Apr 7, 2016 at 11:38 PM, Juergen Gross <jgr...@suse.com> wrote: >> On 08/04/16 08:29, Luis R. Rodriguez wrote: >>> On Thu, Apr 7, 2016 at 10:18 PM, Juergen Gross <jgr...@suse.com> wrote: >>>> On 08/04/16 02:32, Luis R. Rodriguez wrote: >>>>> This highlights a semantic gap issue. From a quick cursory review, I think >>>>> we can address this temporarily by just using a check: >>>>> >>>>> void __init x86_early_init_platform_quirks(void) >>>>> { >>>>> x86_platform.legacy.rtc = 1; >>>>> >>>>> switch (boot_params.hdr.hardware_subarch) { >>>>> case X86_SUBARCH_XEN: >>>>> case X86_SUBARCH_LGUEST: >>>>> case X86_SUBARCH_INTEL_MID: >>>>> - x86_platform.legacy.rtc = 0; >>>>> + if (x86_init.mpparse.get_smp_config != x86_init_uint_noop) >>>>> + x86_platform.legacy.rtc = 0; >>>> >>>> No! Why don't you just use the explicit test xen_initial_domain() ? >>> >>> Because we don't want to sprinkle Xen specific code outside of Xen >>> code. What do you think about the second possibility I listed? >>> Otherwise, any other ideas? >> >> Don't try to guess. > > I can only do that given there is nothing at all to tell me what to > expect here with regards to RTC on Xen guest, if there is some > documentation that could help with that please let me know.
Only Xen inernals. :-) > >> In case you don't want to inject Xen internals here, just call a Xen >> function to either return the correct value, or to set all structure >> elements correctly. > > I like the later as an option, in case there are further hardware > subarch specific quirks which require internal logistics. What do > others think? > >> Thinking more about it: why not do that for all the subarchs? > > I originally had went with that approach, but Ingo made the point that > it would be best to instead move all quirk settings into one place. > That lets a reader easily tell what is going on in one place, it also > compartmentalizes the hardware subarch uses. Okay. Another idea (not sure whether this is really a good one): Add X86_SUBARCH_XEN_DOM0. As hardware_subarch is 32 bits wide I don't think the number of subarchs is a scarce resource. :-) I'd expect other quirks in future might have different settings for domU and dom0, too. >> You'd >> have the specific settings where they belong: in a subarch specific >> source. Just do the default settings in x86_early_init_platform_quirks() >> and let the subarch functions set the non-default values. > > This is a rather different approach than what I had originally tried. > Bike shed thing -- someone just has to decide. > > Left up to me, I kind of really like centralizing the quirk settings > in one place approach as it means a reader can easily tell what's > going on regardless of platform in one place for odd settings. I > prefer this given that we *already* have the semantics over hardware > subarch in a generalized fashion. We *do not* have semantics for dom0 > Vs domU -- if such a notion is generic to other virtualization That's not carved in stone - see above. :-) > environments it deserves consideration to new semantics to deal with > that, otherwise the callback for handling further quirks is best, but > I'd also highly discourage such callback to be used. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel