On Fri, Apr 08, 2016 at 08:37:44AM -0400, Boris Ostrovsky wrote: > On 04/08/2016 03:59 AM, Juergen Gross wrote: > >On 08/04/16 09:36, Luis R. Rodriguez wrote: > >>On Fri, Apr 8, 2016 at 12:13 AM, Juergen Gross <jgross@xxxxxxxx> wrote: > >>>On 08/04/16 08:56, Luis R. Rodriguez wrote: > >>>>On Thu, Apr 7, 2016 at 11:38 PM, Juergen Gross <jgross@xxxxxxxx> wrote: > >>>> > >>>>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. :-) > >>This would mean bumping the x86 boot protocol, we shouldn't take that > >>lightly, but given that in this case the new subarch would really only > >>be set by the kernel (or future loaders for perhaps HVMLite) I'd think > >>this is not such an intrusive alternative. > >I think adding an own subarch for dom0 isn't that bad. It really is > >different from domU as dom0 has per default access to the real hardware > >(or at least to most of it). > > Can we do this (overwrite quirks) in x86_init_ops.arch_setup? I'd > really like to avoid adding a what essentially is a sub-subarch. I'm going with this. Will respin. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
