David, please note below the highlighted code.
On Wed, Feb 24, 2016 at 09:32:59AM +0100, Ingo Molnar wrote:
>
> * Luis R. Rodriguez wrote:
> For hard coded platform quirks I'd suggest we add x86_platform.quirks flags.
> For
> example the F00F hack for Xen could be done via:
>
> x86_plat
On Wed, Mar 02, 2016 at 01:43:42AM +0100, Luis R. Rodriguez wrote:
> On Wed, Feb 24, 2016 at 09:32:59AM +0100, Ingo Molnar wrote:
> There's only one problem with this strategy I can think so far which differs
> from my original approach, which is partly why I actually started looking at
> this stuf
On Wed, Feb 24, 2016 at 09:32:59AM +0100, Ingo Molnar wrote:
> And if also add the legacy RTC flag, it becomes:
>
> void early_init_hardcoded_platform_quirks(void)
> {
> x86_platform.legacy.ebda_search = 0;
> x86_platform.quirks.idt_remap = 1;
> x86_platform.legacy.rtc = 1;
>
>
* Andy Lutomirski wrote:
> On Feb 24, 2016 12:33 AM, "Ingo Molnar" wrote:
> >
> > For hard coded platform quirks I'd suggest we add x86_platform.quirks
> > flags. For
> > example the F00F hack for Xen could be done via:
> >
> > x86_platform.quirks.idt_remap = 0;
> >
>
> Don't we uncon
On Wed, Feb 24, 2016 at 5:18 PM, Luis R. Rodriguez wrote:
>
> On Feb 24, 2016 8:40 AM, "Andy Lutomirski" wrote:
>>
>> On Feb 24, 2016 12:33 AM, "Ingo Molnar" wrote:
>> >
>> > For hard coded platform quirks I'd suggest we add x86_platform.quirks
>> > flags. For
>> > example the F00F hack for Xen
On Feb 24, 2016 8:40 AM, "Andy Lutomirski" wrote:
>
> On Feb 24, 2016 12:33 AM, "Ingo Molnar" wrote:
> >
> > For hard coded platform quirks I'd suggest we add x86_platform.quirks
flags. For
> > example the F00F hack for Xen could be done via:
> >
> > x86_platform.quirks.idt_remap = 0;
> >
On Feb 24, 2016 12:33 AM, "Ingo Molnar" wrote:
>
> For hard coded platform quirks I'd suggest we add x86_platform.quirks flags.
> For
> example the F00F hack for Xen could be done via:
>
> x86_platform.quirks.idt_remap = 0;
>
Don't we unconditionally remap the IDT? I think Kees did it f
* Luis R. Rodriguez wrote:
> > > > +enum x86_hardware_subarch {
> > > > X86_SUBARCH_PC = 0,
> > > > X86_SUBARCH_LGUEST,
> > > > X86_SUBARCH_XEN,
> > >
> > > No, this is really backwards.
> > >
> > > While I agree that we want to get rid of paravirt_enabled(), we _dont_
On Tue, Feb 23, 2016 at 11:34:09AM +0100, Luis R. Rodriguez wrote:
> On Tue, Feb 23, 2016 at 09:51:19AM +0100, Ingo Molnar wrote:
> >
> > * Luis R. Rodriguez wrote:
> >
> > > Although hardware_subarch has been in place since the x86 boot
> > > protocol 2.07 it hasn't been used much. Enumerate cu
On Tue, Feb 23, 2016 at 09:51:19AM +0100, Ingo Molnar wrote:
>
> * Luis R. Rodriguez wrote:
>
> > Although hardware_subarch has been in place since the x86 boot
> > protocol 2.07 it hasn't been used much. Enumerate current possible
> > values to avoid misuses and help with semantics later at boo
* Luis R. Rodriguez wrote:
> Although hardware_subarch has been in place since the x86 boot
> protocol 2.07 it hasn't been used much. Enumerate current possible
> values to avoid misuses and help with semantics later at boot
> time should this be used further.
>
> v2: fix typos
>
> Cc: Andy Sh
Although hardware_subarch has been in place since the x86 boot
protocol 2.07 it hasn't been used much. Enumerate current possible
values to avoid misuses and help with semantics later at boot
time should this be used further.
v2: fix typos
Cc: Andy Shevchenko
Signed-off-by: Luis R. Rodriguez
--
12 matches
Mail list logo