Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1372962 > unrolled thread
| Started by | "Luis R. Rodriguez" <mcgrof@kernel.org> |
|---|---|
| First post | 2016-04-07 02:10 +0200 |
| Last post | 2016-04-08 12:30 +0200 |
| Articles | 20 on this page of 40 — 8 participants |
Back to article view | Back to linux.kernel
[PATCH v4 00/14] x86: remove paravirt_enabled "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-07 02:10 +0200
[PATCH v4 06/14] x86/init: use a platform legacy quirk for ebda "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-07 02:10 +0200
Re: [Xen-devel] [PATCH v4 06/14] x86/init: use a platform legacy quirk for ebda David Vrabel <david.vrabel@citrix.com> - 2016-04-07 11:50 +0200
Re: [Xen-devel] [PATCH v4 06/14] x86/init: use a platform legacy quirk for ebda "Luis R. Rodriguez" <mcgrof@suse.com> - 2016-04-07 23:10 +0200
[PATCH v4 10/14] x86/cpu/intel: remove not needed paravirt_enabled() for f00f work around "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-07 02:10 +0200
[PATCH v4 14/14] x86/paravirt: remove paravirt_enabled() "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-07 02:10 +0200
[PATCH v4 13/14] x86/init: rename ebda code file "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-07 02:10 +0200
[PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-07 02:10 +0200
Re: [Xen-devel] [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk David Vrabel <david.vrabel@citrix.com> - 2016-04-07 11:50 +0200
Re: [Xen-devel] [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-14 01:10 +0200
Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-04-07 15:00 +0200
Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-08 02:40 +0200
Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk Juergen Gross <jgross@suse.com> - 2016-04-08 07:20 +0200
Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk Juergen Gross <jgross@suse.com> - 2016-04-08 08:40 +0200
Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-08 09:00 +0200
Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk Juergen Gross <jgross@suse.com> - 2016-04-08 09:20 +0200
Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-08 09:40 +0200
Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk Juergen Gross <jgross@suse.com> - 2016-04-08 10:10 +0200
Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-04-08 14:40 +0200
Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-08 20:50 +0200
Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-08 08:40 +0200
Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-04-08 14:30 +0200
[PATCH v4 07/14] tools/lguest: force disable tboot and apm "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-07 02:10 +0200
Re: [PATCH v4 07/14] tools/lguest: force disable tboot and apm Rusty Russell <rusty@rustcorp.com.au> - 2016-04-11 06:00 +0200
[PATCH v4 03/14] tools/lguest: make lguest launcher use X86_SUBARCH_LGUEST explicitly "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-07 02:10 +0200
[PATCH v4 08/14] apm32: remove paravirt_enabled() use "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-07 02:10 +0200
Re: [PATCH v4 08/14] apm32: remove paravirt_enabled() use Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-04-07 15:10 +0200
Re: [PATCH v4 08/14] apm32: remove paravirt_enabled() use "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-08 00:40 +0200
[PATCH v4 12/14] x86, ACPI: parse ACPI_FADT_LEGACY_DEVICES "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-07 02:10 +0200
[PATCH v4 01/14] x86/boot: enumerate documentation for the x86 hardware_subarch "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-07 02:10 +0200
Re: [PATCH v4 01/14] x86/boot: enumerate documentation for the x86 hardware_subarch Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-04-07 13:30 +0200
Re: [PATCH v4 01/14] x86/boot: enumerate documentation for the x86 hardware_subarch "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-08 00:40 +0200
[PATCH v4 09/14] x86/tboot: remove paravirt_enabled() "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-07 02:10 +0200
[PATCH v4 02/14] x86/xen: use X86_SUBARCH_XEN for PV guest boots "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-07 02:20 +0200
Re: [Xen-devel] [PATCH v4 02/14] x86/xen: use X86_SUBARCH_XEN for PV guest boots David Vrabel <david.vrabel@citrix.com> - 2016-04-07 11:50 +0200
[PATCH v4 05/14] x86, ACPI: move ACPI_FADT_NO_CMOS_RTC check to ACPI boot code "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-07 02:20 +0200
Re: [Xen-devel] [PATCH v4 00/14] x86: remove paravirt_enabled Juergen Gross <jgross@suse.com> - 2016-04-07 15:30 +0200
[PATCH v4 13/14] x86/init: rename ebda code file "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-07 23:40 +0200
Re: [PATCH v4 00/14] x86: remove paravirt_enabled "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-08 03:20 +0200
Re: [PATCH v4 00/14] x86: remove paravirt_enabled Borislav Petkov <bp@alien8.de> - 2016-04-08 12:30 +0200
Page 2 of 2 — ← Prev page 1 [2]
| From | "Luis R. Rodriguez" <mcgrof@kernel.org> |
|---|---|
| Date | 2016-04-08 08:40 +0200 |
| Subject | Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk |
| Message-ID | <rlyfg-8bA-9@gated-at.bofh.it> |
| In reply to | #1373986 |
On Thu, Apr 7, 2016 at 10:18 PM, Juergen Gross <jgross@suse.com> wrote:
> On 08/04/16 02:32, Luis R. Rodriguez wrote:
>> On Thu, Apr 07, 2016 at 08:55:54AM -0400, Boris Ostrovsky wrote:
>>> On 04/06/2016 08:06 PM, Luis R. Rodriguez wrote:
>>>> We have 4 types of x86 platforms that disable RTC:
>>>>
>>>> * Intel MID
>>>> * Lguest - uses paravirt
>>>> * Xen dom-U - uses paravirt
>>>> * x86 on legacy systems annotated with an ACPI legacy flag
>>>>
>>>> We can consolidate all of these into a platform specific legacy
>>>> quirk set early in boot through i386_start_kernel() and through
>>>> x86_64_start_reservations(). This deals with the RTC quirks which
>>>> we can rely on through the hardware subarch, the ACPI check can
>>>> be dealt with separately.
>>>>
>>>> v2: split the subarch check from the ACPI check, clarify
>>>> on the ACPI change commit log why ordering works
>>>>
>>>> Suggested-by: Ingo Molnar <mingo@kernel.org>
>>>> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
>>
>> <-- snip -->
>>
>>>> diff --git a/arch/x86/kernel/platform-quirks.c b/arch/x86/kernel/platform-quirks.c
>>>> new file mode 100644
>>>> index 000000000000..1b114ac5996f
>>>> --- /dev/null
>>>> +++ b/arch/x86/kernel/platform-quirks.c
>>>> @@ -0,0 +1,18 @@
>>>> +#include <linux/kernel.h>
>>>> +#include <linux/init.h>
>>>> +
>>>> +#include <asm/setup.h>
>>>> +#include <asm/bios_ebda.h>
>>>> +
>>>> +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;
>>>> + break;
>>>> + }
>>>> +}
>>>
>>> What about Xen dom0 (aka initial domain)?
>>
>> Indeed, thanks for catching this, the hunk below removes the re-enablement of
>> the the RTC for dom0:
>>
>>>> --- a/arch/x86/xen/enlighten.c
>>>> +++ b/arch/x86/xen/enlighten.c
>>>> @@ -1192,7 +1192,6 @@ static const struct pv_info xen_info __initconst = {
>>>> #ifdef CONFIG_X86_64
>>>> .extra_user_64bit_cs = FLAT_USER_CS64,
>>>> #endif
>>>> - .features = 0,
>>>> .name = "Xen",
>>>> };
>>>> @@ -1525,8 +1524,6 @@ asmlinkage __visible void __init xen_start_kernel(void)
>>>> /* Install Xen paravirt ops */
>>>> pv_info = xen_info;
>>>> - if (xen_initial_domain())
>>>> - pv_info.features |= PV_SUPPORTED_RTC;
>>>> pv_init_ops = xen_init_ops;
>>>> if (!xen_pvh_domain()) {
>>>> pv_cpu_ops = xen_cpu_ops;
>>
>> This should then break dom0 unless of course you have the respective next
>> patch applied and that disabled the RTC due to an ACPI setting on your
>> platform. Juergen, can you check to see if that was the case for your
>> testing platform on dom0 ?
>
> Are you sure it would break?
No, suspected that it should though.
> Wouldn't it just fall back to another
> clock source, e.g. hpet?
I suppose so.
> I looked into my test system: seems as if add_rtc_cmos() is returning
> before the .legacy.rtc test.
OK thanks...
>> 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?
Luis
[toc] | [prev] | [next] | [standalone]
| From | Boris Ostrovsky <boris.ostrovsky@oracle.com> |
|---|---|
| Date | 2016-04-08 14:30 +0200 |
| Subject | Re: [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk |
| Message-ID | <rlDHY-3Fw-7@gated-at.bofh.it> |
| In reply to | #1374012 |
On 04/08/2016 02:29 AM, Luis R. Rodriguez wrote:
> On Thu, Apr 7, 2016 at 10:18 PM, Juergen Gross <jgross@suse.com> wrote:
>> On 08/04/16 02:32, Luis R. Rodriguez wrote:
>>> On Thu, Apr 07, 2016 at 08:55:54AM -0400, Boris Ostrovsky wrote:
>>>> On 04/06/2016 08:06 PM, Luis R. Rodriguez wrote:
>>>>> We have 4 types of x86 platforms that disable RTC:
>>>>>
>>>>> * Intel MID
>>>>> * Lguest - uses paravirt
>>>>> * Xen dom-U - uses paravirt
>>>>> * x86 on legacy systems annotated with an ACPI legacy flag
>>>>>
>>>>> We can consolidate all of these into a platform specific legacy
>>>>> quirk set early in boot through i386_start_kernel() and through
>>>>> x86_64_start_reservations(). This deals with the RTC quirks which
>>>>> we can rely on through the hardware subarch, the ACPI check can
>>>>> be dealt with separately.
>>>>>
>>>>> v2: split the subarch check from the ACPI check, clarify
>>>>> on the ACPI change commit log why ordering works
>>>>>
>>>>> Suggested-by: Ingo Molnar <mingo@kernel.org>
>>>>> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
>>> <-- snip -->
>>>
>>>>> diff --git a/arch/x86/kernel/platform-quirks.c b/arch/x86/kernel/platform-quirks.c
>>>>> new file mode 100644
>>>>> index 000000000000..1b114ac5996f
>>>>> --- /dev/null
>>>>> +++ b/arch/x86/kernel/platform-quirks.c
>>>>> @@ -0,0 +1,18 @@
>>>>> +#include <linux/kernel.h>
>>>>> +#include <linux/init.h>
>>>>> +
>>>>> +#include <asm/setup.h>
>>>>> +#include <asm/bios_ebda.h>
>>>>> +
>>>>> +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;
>>>>> + break;
>>>>> + }
>>>>> +}
>>>> What about Xen dom0 (aka initial domain)?
>>> Indeed, thanks for catching this, the hunk below removes the re-enablement of
>>> the the RTC for dom0:
>>>
>>>>> --- a/arch/x86/xen/enlighten.c
>>>>> +++ b/arch/x86/xen/enlighten.c
>>>>> @@ -1192,7 +1192,6 @@ static const struct pv_info xen_info __initconst = {
>>>>> #ifdef CONFIG_X86_64
>>>>> .extra_user_64bit_cs = FLAT_USER_CS64,
>>>>> #endif
>>>>> - .features = 0,
>>>>> .name = "Xen",
>>>>> };
>>>>> @@ -1525,8 +1524,6 @@ asmlinkage __visible void __init xen_start_kernel(void)
>>>>> /* Install Xen paravirt ops */
>>>>> pv_info = xen_info;
>>>>> - if (xen_initial_domain())
>>>>> - pv_info.features |= PV_SUPPORTED_RTC;
>>>>> pv_init_ops = xen_init_ops;
>>>>> if (!xen_pvh_domain()) {
>>>>> pv_cpu_ops = xen_cpu_ops;
>>> This should then break dom0 unless of course you have the respective next
>>> patch applied and that disabled the RTC due to an ACPI setting on your
>>> platform. Juergen, can you check to see if that was the case for your
>>> testing platform on dom0 ?
>> Are you sure it would break?
> No, suspected that it should though.
>
>> Wouldn't it just fall back to another
>> clock source, e.g. hpet?
> I suppose so.
>
>> I looked into my test system: seems as if add_rtc_cmos() is returning
>> before the .legacy.rtc test.
> OK thanks...
It works because the clock must have been discovered by ACPI prior to
add_rtc_cmos() call. It's PNP0b00 object, I believe. The rest of the
routine is to handle the case when RTC is not found in ACPI tables for
whatever reasons (I think).
That's why we added paravirt_has(RTC) --- dom0 should be able to handle
such cases, just like bare metal.
-boris
[toc] | [prev] | [next] | [standalone]
| From | "Luis R. Rodriguez" <mcgrof@kernel.org> |
|---|---|
| Date | 2016-04-07 02:10 +0200 |
| Subject | [PATCH v4 07/14] tools/lguest: force disable tboot and apm |
| Message-ID | <rl5Gi-3Ao-23@gated-at.bofh.it> |
| In reply to | #1372962 |
The paravirt_enabled() check is going away, the area tossed to the kernel on lguest is not zerored out, so ensure lguest force disables tboot and apm just in case the kernel file being read might have this set for whatever reason. Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> --- tools/lguest/lguest.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/tools/lguest/lguest.c b/tools/lguest/lguest.c index ff0aa580c6e1..0aa75af6e862 100644 --- a/tools/lguest/lguest.c +++ b/tools/lguest/lguest.c @@ -3357,6 +3357,12 @@ int main(int argc, char *argv[]) /* Tell the entry path not to try to reload segment registers. */ boot->hdr.loadflags |= KEEP_SEGMENTS; + /* We don't support tboot */ + boot->tboot_addr = 0; + + /* Ensure this is 0 to prevent apm from loading */ + boot->apm_bios_info.version = 0; + /* We tell the kernel to initialize the Guest. */ tell_kernel(start); -- 2.7.2
[toc] | [prev] | [next] | [standalone]
| From | Rusty Russell <rusty@rustcorp.com.au> |
|---|---|
| Date | 2016-04-11 06:00 +0200 |
| Subject | Re: [PATCH v4 07/14] tools/lguest: force disable tboot and apm |
| Message-ID | <rmBb4-7ND-9@gated-at.bofh.it> |
| In reply to | #1372970 |
"Luis R. Rodriguez" <mcgrof@kernel.org> writes: > The paravirt_enabled() check is going away, the area tossed to > the kernel on lguest is not zerored out, so ensure lguest force > disables tboot and apm just in case the kernel file being read might > have this set for whatever reason. > > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Nice, thanks! Acked-by: Rusty Russell <rusty@rustcorp.com.au> Cheers, Rusty.
[toc] | [prev] | [next] | [standalone]
| From | "Luis R. Rodriguez" <mcgrof@kernel.org> |
|---|---|
| Date | 2016-04-07 02:10 +0200 |
| Subject | [PATCH v4 03/14] tools/lguest: make lguest launcher use X86_SUBARCH_LGUEST explicitly |
| Message-ID | <rl5Gi-3Ao-19@gated-at.bofh.it> |
| In reply to | #1372962 |
Be explicit and make use of X86_SUBARCH_LGUEST directly. Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> --- tools/lguest/lguest.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/lguest/lguest.c b/tools/lguest/lguest.c index 80159e6811c2..ff0aa580c6e1 100644 --- a/tools/lguest/lguest.c +++ b/tools/lguest/lguest.c @@ -3351,8 +3351,8 @@ int main(int argc, char *argv[]) /* Boot protocol version: 2.07 supports the fields for lguest. */ boot->hdr.version = 0x207; - /* The hardware_subarch value of "1" tells the Guest it's an lguest. */ - boot->hdr.hardware_subarch = 1; + /* X86_SUBARCH_LGUEST tells the Guest it's an lguest. */ + boot->hdr.hardware_subarch = X86_SUBARCH_LGUEST; /* Tell the entry path not to try to reload segment registers. */ boot->hdr.loadflags |= KEEP_SEGMENTS; -- 2.7.2
[toc] | [prev] | [next] | [standalone]
| From | "Luis R. Rodriguez" <mcgrof@kernel.org> |
|---|---|
| Date | 2016-04-07 02:10 +0200 |
| Subject | [PATCH v4 08/14] apm32: remove paravirt_enabled() use |
| Message-ID | <rl5Gi-3Ao-21@gated-at.bofh.it> |
| In reply to | #1372962 |
There is already a check for apm_info.bios == 0, the
apm_info.bios is set from the boot_params.apm_bios_info.
Both Xen and lguest, which are also the only ones that set
paravirt_enabled to true, never set the apm_bios.info. The
Xen folks are sure force disable to 0 is not needed, we
recently forced disabled this on lguest. With this in place
the paravirt_enabled() check is simply not needed anymore.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
arch/x86/kernel/apm_32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apm_32.c b/arch/x86/kernel/apm_32.c
index 9307f182fe30..c7364bd633e1 100644
--- a/arch/x86/kernel/apm_32.c
+++ b/arch/x86/kernel/apm_32.c
@@ -2267,7 +2267,7 @@ static int __init apm_init(void)
dmi_check_system(apm_dmi_table);
- if (apm_info.bios.version == 0 || paravirt_enabled() || machine_is_olpc()) {
+ if (apm_info.bios.version == 0 || machine_is_olpc()) {
printk(KERN_INFO "apm: BIOS not found.\n");
return -ENODEV;
}
--
2.7.2
[toc] | [prev] | [next] | [standalone]
| From | Boris Ostrovsky <boris.ostrovsky@oracle.com> |
|---|---|
| Date | 2016-04-07 15:10 +0200 |
| Subject | Re: [PATCH v4 08/14] apm32: remove paravirt_enabled() use |
| Message-ID | <rlhR8-4fL-23@gated-at.bofh.it> |
| In reply to | #1372973 |
On 04/06/2016 08:06 PM, Luis R. Rodriguez wrote:
> There is already a check for apm_info.bios == 0, the
> apm_info.bios is set from the boot_params.apm_bios_info.
> Both Xen and lguest, which are also the only ones that set
> paravirt_enabled to true, never set the apm_bios.info. The
>
> Xen folks are sure force disable to 0 is not needed,
Because apm_info lives in .bss (which we recently made sure is cleared
on Xen PV). May be worth mentioning in the commit message so that we
don't forget why this is not needed.
I think you also have this statement in other patches.
-boris
> we
> recently forced disabled this on lguest. With this in place
> the paravirt_enabled() check is simply not needed anymore.
>
> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> ---
> arch/x86/kernel/apm_32.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/apm_32.c b/arch/x86/kernel/apm_32.c
> index 9307f182fe30..c7364bd633e1 100644
> --- a/arch/x86/kernel/apm_32.c
> +++ b/arch/x86/kernel/apm_32.c
> @@ -2267,7 +2267,7 @@ static int __init apm_init(void)
>
> dmi_check_system(apm_dmi_table);
>
> - if (apm_info.bios.version == 0 || paravirt_enabled() || machine_is_olpc()) {
> + if (apm_info.bios.version == 0 || machine_is_olpc()) {
> printk(KERN_INFO "apm: BIOS not found.\n");
> return -ENODEV;
> }
[toc] | [prev] | [next] | [standalone]
| From | "Luis R. Rodriguez" <mcgrof@kernel.org> |
|---|---|
| Date | 2016-04-08 00:40 +0200 |
| Subject | Re: [PATCH v4 08/14] apm32: remove paravirt_enabled() use |
| Message-ID | <rlqKK-2mQ-19@gated-at.bofh.it> |
| In reply to | #1373387 |
On Thu, Apr 07, 2016 at 09:08:36AM -0400, Boris Ostrovsky wrote:
> On 04/06/2016 08:06 PM, Luis R. Rodriguez wrote:
> >There is already a check for apm_info.bios == 0, the
> >apm_info.bios is set from the boot_params.apm_bios_info.
> >Both Xen and lguest, which are also the only ones that set
> >paravirt_enabled to true, never set the apm_bios.info. The
> >
> >Xen folks are sure force disable to 0 is not needed,
>
> Because apm_info lives in .bss (which we recently made sure is
> cleared on Xen PV). May be worth mentioning in the commit message so
> that we don't forget why this is not needed.
Thanks, I'll change that last paragraph with:
Xen folks are sure force disable to 0 is not needed because
apm_info lives in .bss, we recently forced disabled this on
lguest, and on the Xen side just to be sure Boris zeroed out
the .bss for PV guests through commit 04b6b4a56884327c1648
("xen/x86: Zero out .bss for PV guests"). With this care taken
into consideration the paravirt_enabled() check is simply not
needed anymore.
> I think you also have this statement in other patches.
Indeed, I'll highlight this on the tboot commit log as well.
Luis
[toc] | [prev] | [next] | [standalone]
| From | "Luis R. Rodriguez" <mcgrof@kernel.org> |
|---|---|
| Date | 2016-04-07 02:10 +0200 |
| Subject | [PATCH v4 12/14] x86, ACPI: parse ACPI_FADT_LEGACY_DEVICES |
| Message-ID | <rl5Gi-3Ao-27@gated-at.bofh.it> |
| In reply to | #1372962 |
ACPI 5.2.9.3 IA-PC Boot Architecture flag ACPI_FADT_LEGACY_DEVICES
can be used to determine if a system has legacy devices LPC or
ISA devices. The x86 platform already has a struct which lists
known associated legacy devices, we start off careful only
by disabling root devices we should not regress with. The struct
and device list can be expanded with time to cover more root
legacy components.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
arch/x86/kernel/acpi/boot.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 5e736e2108a1..3cada5e8505a 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -911,6 +911,11 @@ late_initcall(hpet_insert_resource);
static int __init acpi_parse_fadt(struct acpi_table_header *table)
{
+ if (!(acpi_gbl_FADT.boot_flags & ACPI_FADT_LEGACY_DEVICES)) {
+ pr_debug("ACPI: no legacy devices present\n");
+ x86_platform.legacy.devices.pnpbios = 0;
+ }
+
if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) {
pr_debug("ACPI: not registering RTC platform device\n");
x86_platform.legacy.rtc = 0;
--
2.7.2
[toc] | [prev] | [next] | [standalone]
| From | "Luis R. Rodriguez" <mcgrof@kernel.org> |
|---|---|
| Date | 2016-04-07 02:10 +0200 |
| Subject | [PATCH v4 01/14] x86/boot: enumerate documentation for the x86 hardware_subarch |
| Message-ID | <rl5Gi-3Ao-29@gated-at.bofh.it> |
| In reply to | #1372962 |
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.
These enums should only ever be used by architecture x86 code,
and all that code should be well contained and compartamentalized,
clarify that as well.
v2: updates documentation further -- be a bit more pedantic about
annotating care and use of these guys.
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
arch/x86/include/uapi/asm/bootparam.h | 36 ++++++++++++++++++++++++++++++++++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index 329254373479..d03e2e9eefca 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -157,7 +157,41 @@ struct boot_params {
__u8 _pad9[276]; /* 0xeec */
} __attribute__((packed));
-enum {
+/**
+ * enum x86_hardware_subarch - x86 hardware subarchitecture
+ *
+ * The x86 hardware_subarch and hardware_subarch_data were added as of the x86
+ * boot protocol 2.07 to help distinguish and support custom x86 boot
+ * sequences. This enum represents accepted values for the x86
+ * hardware_subarch. Custom x86 boot sequences (not X86_SUBARCH_PC) do not
+ * have or simply *cannot* make use of natural stubs like BIOS or EFI, the
+ * hardware_subarch can be used on the Linux entry path to revector to a
+ * subarchitecture stub when needed. This subarchitecture stub can be used to
+ * set up Linux boot parameters or for special care to account for nonstandard
+ * handling of page tables.
+ *
+ * These enums should only ever be used by x86 code, and the code that uses
+ * it should be well contained and compartamentalized.
+ *
+ * KVM and Xen HVM do not have a subarch as these are expected to follow
+ * standard x86 boot entries. If there is a genuine need for "hypervisor" type
+ * that should be considered separately in the future. Future guest types
+ * should seriously consider working with standard x86 boot stubs such as
+ * the BIOS or EFI boot stubs.
+ *
+ * @X86_SUBARCH_PC: Should be used if the hardware is enumerable using standard
+ * PC mechanisms (PCI, ACPI) and doesn't need a special boot flow.
+ * @X86_SUBARCH_LGUEST: Used for x86 hypervisor demo, lguest
+ * @X86_SUBARCH_XEN: Used for Xen guest types which follow the PV boot path,
+ * which start at asm startup_xen() entry point and later jump to the C
+ * xen_start_kernel() entry point.
+ * @X86_SUBARCH_INTEL_MID: Used for Intel MID (Mobile Internet Device) platform
+ * systems which do not have the PCI legacy interfaces.
+ * @X86_SUBARCH_CE4100: Used for Intel CE media processor (CE4100) SOC for
+ * for settop boxes and media devices, the use of a subarch for CE4100
+ * is more of a hack...
+ */
+enum x86_hardware_subarch {
X86_SUBARCH_PC = 0,
X86_SUBARCH_LGUEST,
X86_SUBARCH_XEN,
--
2.7.2
[toc] | [prev] | [next] | [standalone]
| From | Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
|---|---|
| Date | 2016-04-07 13:30 +0200 |
| Subject | Re: [PATCH v4 01/14] x86/boot: enumerate documentation for the x86 hardware_subarch |
| Message-ID | <rlgim-34z-7@gated-at.bofh.it> |
| In reply to | #1372975 |
On Wed, 2016-04-06 at 17:06 -0700, 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. > > These enums should only ever be used by architecture x86 code, > and all that code should be well contained and compartamentalized, > clarify that as well. Nitpick: > + * @X86_SUBARCH_PC: Should be used if the hardware is enumerable > using standard > + * PC mechanisms (PCI, ACPI) and doesn't need a special boot > flow. > + * @X86_SUBARCH_LGUEST: Used for x86 hypervisor demo, lguest > + * @X86_SUBARCH_XEN: Used for Xen guest types which follow the PV > boot path, > + * which start at asm startup_xen() entry point and later > jump to the C > + * xen_start_kernel() entry point. > + * @X86_SUBARCH_INTEL_MID: Used for Intel MID (Mobile Internet > Device) platform > + * systems which do not have the PCI legacy interfaces. > + * @X86_SUBARCH_CE4100: Used for Intel CE media processor (CE4100) > SOC for I think 'SoC' (without quotes) will be better. > + * for settop boxes and media devices, the use of a subarch > for CE4100 > + * is more of a hack... -- Andy Shevchenko <andriy.shevchenko@linux.intel.com> Intel Finland Oy
[toc] | [prev] | [next] | [standalone]
| From | "Luis R. Rodriguez" <mcgrof@kernel.org> |
|---|---|
| Date | 2016-04-08 00:40 +0200 |
| Subject | Re: [PATCH v4 01/14] x86/boot: enumerate documentation for the x86 hardware_subarch |
| Message-ID | <rlqKK-2mQ-13@gated-at.bofh.it> |
| In reply to | #1373287 |
On Thu, Apr 07, 2016 at 02:25:38PM +0300, Andy Shevchenko wrote: > On Wed, 2016-04-06 at 17:06 -0700, 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. > > > > These enums should only ever be used by architecture x86 code, > > and all that code should be well contained and compartamentalized, > > clarify that as well. > > Nitpick: > > > + * @X86_SUBARCH_PC: Should be used if the hardware is enumerable > > using standard > > + * PC mechanisms (PCI, ACPI) and doesn't need a special boot > > flow. > > + * @X86_SUBARCH_LGUEST: Used for x86 hypervisor demo, lguest > > + * @X86_SUBARCH_XEN: Used for Xen guest types which follow the PV > > boot path, > > + * which start at asm startup_xen() entry point and later > > jump to the C > > + * xen_start_kernel() entry point. > > + * @X86_SUBARCH_INTEL_MID: Used for Intel MID (Mobile Internet > > Device) platform > > + * systems which do not have the PCI legacy interfaces. > > + * @X86_SUBARCH_CE4100: Used for Intel CE media processor (CE4100) > > SOC for > > I think 'SoC' (without quotes) will be better. Amended, since I think I'll need a re-spin and since we may need to take care of the dom0 Vs domU semantics I'll also make some changes to include X86_SUBARCH_XEN documentation to annotate that PV guests can be of domU or dom0 type... Luis
[toc] | [prev] | [next] | [standalone]
| From | "Luis R. Rodriguez" <mcgrof@kernel.org> |
|---|---|
| Date | 2016-04-07 02:10 +0200 |
| Subject | [PATCH v4 09/14] x86/tboot: remove paravirt_enabled() |
| Message-ID | <rl5Gi-3Ao-31@gated-at.bofh.it> |
| In reply to | #1372962 |
There is already a check for boot_params.tboot_addr prior
to paravirt_enabled(). Both Xen and lguest, which are also the
only ones that set paravirt_enabled to true, never set the
boot_params.tboot_addr. The Xen folks are sure a force disable
to 0 is not needed, we recently forced disabled this on lguest.
With this in place this check is no longer needed.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
arch/x86/kernel/tboot.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
index e72a07f20b05..9b0185fbe3eb 100644
--- a/arch/x86/kernel/tboot.c
+++ b/arch/x86/kernel/tboot.c
@@ -74,12 +74,6 @@ void __init tboot_probe(void)
return;
}
- /* only a natively booted kernel should be using TXT */
- if (paravirt_enabled()) {
- pr_warning("non-0 tboot_addr but pv_ops is enabled\n");
- return;
- }
-
/* Map and check for tboot UUID. */
set_fixmap(FIX_TBOOT_BASE, boot_params.tboot_addr);
tboot = (struct tboot *)fix_to_virt(FIX_TBOOT_BASE);
--
2.7.2
[toc] | [prev] | [next] | [standalone]
| From | "Luis R. Rodriguez" <mcgrof@kernel.org> |
|---|---|
| Date | 2016-04-07 02:20 +0200 |
| Subject | [PATCH v4 02/14] x86/xen: use X86_SUBARCH_XEN for PV guest boots |
| Message-ID | <rl5PY-3DR-3@gated-at.bofh.it> |
| In reply to | #1372962 |
The use of subarch should have no current effect on Xen
PV guests, as such this should have no current functional
effects.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
arch/x86/xen/enlighten.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 9b8f1eacc110..40487f1ecb4c 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1661,6 +1661,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
boot_params.hdr.ramdisk_image = initrd_start;
boot_params.hdr.ramdisk_size = xen_start_info->mod_len;
boot_params.hdr.cmd_line_ptr = __pa(xen_start_info->cmd_line);
+ boot_params.hdr.hardware_subarch = X86_SUBARCH_XEN;
if (!xen_initial_domain()) {
add_preferred_console("xenboot", 0, NULL);
--
2.7.2
[toc] | [prev] | [next] | [standalone]
| From | David Vrabel <david.vrabel@citrix.com> |
|---|---|
| Date | 2016-04-07 11:50 +0200 |
| Subject | Re: [Xen-devel] [PATCH v4 02/14] x86/xen: use X86_SUBARCH_XEN for PV guest boots |
| Message-ID | <rleJA-1Ne-9@gated-at.bofh.it> |
| In reply to | #1372978 |
On 07/04/16 01:06, Luis R. Rodriguez wrote: > The use of subarch should have no current effect on Xen > PV guests, as such this should have no current functional > effects. Reviewed-by: David Vrabel <david.vrabel@citrix.com> David
[toc] | [prev] | [next] | [standalone]
| From | "Luis R. Rodriguez" <mcgrof@kernel.org> |
|---|---|
| Date | 2016-04-07 02:20 +0200 |
| Subject | [PATCH v4 05/14] x86, ACPI: move ACPI_FADT_NO_CMOS_RTC check to ACPI boot code |
| Message-ID | <rl5PY-3DR-5@gated-at.bofh.it> |
| In reply to | #1372962 |
This moves the ACPI specific check into the ACPI boot code,
it also takes advantage of the x86_platform.legacy.rtc which
is checked for already on the RTC initialization code. This
lets us remove the nasty #ifdefery and consolidate the checks
to use only one toggle to disable the RTC init code.
The works as RTC is initialized by device_initcall(add_rtc_cmos),
this will run late in boot on start_kernel() during rest_init(),
acpi_parse_fadt() gets called earlier during setup_arch().
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
arch/x86/kernel/acpi/boot.c | 4 ++++
arch/x86/kernel/rtc.c | 8 --------
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 1db7e80c26f2..5e736e2108a1 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -911,6 +911,10 @@ late_initcall(hpet_insert_resource);
static int __init acpi_parse_fadt(struct acpi_table_header *table)
{
+ if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) {
+ pr_debug("ACPI: not registering RTC platform device\n");
+ x86_platform.legacy.rtc = 0;
+ }
#ifdef CONFIG_X86_PM_TIMER
/* detect the location of the ACPI PM Timer */
diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index 62c48da3889d..ff4f4180fefd 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -189,14 +189,6 @@ static __init int add_rtc_cmos(void)
if (of_have_populated_dt())
return 0;
-#ifdef CONFIG_ACPI
- if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) {
- /* This warning can likely go away again in a year or two. */
- pr_info("ACPI: not registering RTC platform device\n");
- return -ENODEV;
- }
-#endif
-
if (!x86_platform.legacy.rtc)
return -ENODEV;
--
2.7.2
[toc] | [prev] | [next] | [standalone]
| From | Juergen Gross <jgross@suse.com> |
|---|---|
| Date | 2016-04-07 15:30 +0200 |
| Subject | Re: [Xen-devel] [PATCH v4 00/14] x86: remove paravirt_enabled |
| Message-ID | <rliau-4rG-7@gated-at.bofh.it> |
| In reply to | #1372962 |
On 07/04/16 02:06, Luis R. Rodriguez wrote:
> Now that Andy's ASM paravirt_enabled() use is merged all we need is to address
> the rest of the C code uses. This completes that work by providing proper
> semantics for platform legacy settings and quirks as suggested by Ingo, this in
> turn can also be extended later for benefit of further processing of ACPI
> 5.2.9.3 IA-PC Boot Architecture flags, which we currently don't take much
> advantage of. For instance the ACPI_FADT_NO_VGA can later be leveraged by bare
> metal x86 *and* HVMLite, as HVMLite seems to plan to set this.
>
> Also, hpa has noted both Intel MID and CE4100 can make use of disabling
> pnpbios, we can do that separately after this, but it should now be a
> trivial change, generic given this quirk stuff is all generic now.
>
> This patches goes tested by 0-day, except for the last patch, for some reason
> the branch that included that patch has had testing delayed for quite a
> while now, but I can't think of anything there that should break anything.
>
> I've also just run time tested this on bare metal only so far.
FWIW: Xen dom0 is booting with the patches applied.
Juergen
>
> Luis R. Rodriguez (14):
> x86/boot: enumerate documentation for the x86 hardware_subarch
> x86/xen: use X86_SUBARCH_XEN for PV guest boots
> tools/lguest: make lguest launcher use X86_SUBARCH_LGUEST explicitly
> x86/rtc: replace paravirt rtc check with platform legacy quirk
> x86, ACPI: move ACPI_FADT_NO_CMOS_RTC check to ACPI boot code
> x86/init: use a platform legacy quirk for ebda
> tools/lguest: force disable tboot and apm
> apm32: remove paravirt_enabled() use
> x86/tboot: remove paravirt_enabled()
> x86/cpu/intel: remove not needed paravirt_enabled() for f00f work
> around
> pnpbios: replace paravirt_enabled() check with legacy device check
> x86, ACPI: parse ACPI_FADT_LEGACY_DEVICES
> x86/init: rename ebda code file
> x86/paravirt: remove paravirt_enabled()
>
> arch/x86/Makefile | 3 ++-
> arch/x86/include/asm/paravirt.h | 11 ---------
> arch/x86/include/asm/paravirt_types.h | 6 -----
> arch/x86/include/asm/processor.h | 2 --
> arch/x86/include/asm/x86_init.h | 42 +++++++++++++++++++++++++++++++++++
> arch/x86/include/uapi/asm/bootparam.h | 36 +++++++++++++++++++++++++++++-
> arch/x86/kernel/Makefile | 6 ++++-
> arch/x86/kernel/acpi/boot.c | 9 ++++++++
> arch/x86/kernel/apm_32.c | 2 +-
> arch/x86/kernel/cpu/intel.c | 2 +-
> arch/x86/kernel/{head.c => ebda.c} | 2 +-
> arch/x86/kernel/head32.c | 2 ++
> arch/x86/kernel/head64.c | 1 +
> arch/x86/kernel/kvm.c | 8 -------
> arch/x86/kernel/paravirt.c | 1 -
> arch/x86/kernel/platform-quirks.c | 32 ++++++++++++++++++++++++++
> arch/x86/kernel/rtc.c | 15 ++-----------
> arch/x86/kernel/tboot.c | 6 -----
> arch/x86/lguest/boot.c | 3 ---
> arch/x86/xen/enlighten.c | 5 +----
> drivers/pnp/pnpbios/core.c | 3 ++-
> include/linux/pnp.h | 2 ++
> tools/lguest/lguest.c | 10 +++++++--
> 23 files changed, 146 insertions(+), 63 deletions(-)
> rename arch/x86/kernel/{head.c => ebda.c} (98%)
> create mode 100644 arch/x86/kernel/platform-quirks.c
>
[toc] | [prev] | [next] | [standalone]
| From | "Luis R. Rodriguez" <mcgrof@kernel.org> |
|---|---|
| Date | 2016-04-07 23:40 +0200 |
| Subject | [PATCH v4 13/14] x86/init: rename ebda code file |
| Message-ID | <rlpOI-1Do-27@gated-at.bofh.it> |
| In reply to | #1372962 |
This makes it clearer what this is.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
arch/x86/Makefile | 2 +-
arch/x86/kernel/Makefile | 2 +-
arch/x86/kernel/{head.c => ebda.c} | 0
3 files changed, 2 insertions(+), 2 deletions(-)
rename arch/x86/kernel/{head.c => ebda.c} (100%)
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index f9ed8a7ce2b6..6fce7f096b88 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -208,7 +208,7 @@ endif
head-y := arch/x86/kernel/head_$(BITS).o
head-y += arch/x86/kernel/head$(BITS).o
-head-y += arch/x86/kernel/head.o
+head-y += arch/x86/kernel/ebda.o
head-y += arch/x86/kernel/platform-quirks.o
libs-y += arch/x86/lib/
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 7a9e44d935de..0503f5bfb18d 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -4,7 +4,7 @@
extra-y := head_$(BITS).o
extra-y += head$(BITS).o
-extra-y += head.o
+extra-y += ebda.o
extra-y += platform-quirks.o
extra-y += vmlinux.lds
diff --git a/arch/x86/kernel/head.c b/arch/x86/kernel/ebda.c
similarity index 100%
rename from arch/x86/kernel/head.c
rename to arch/x86/kernel/ebda.c
--
2.7.2
[toc] | [prev] | [next] | [standalone]
| From | "Luis R. Rodriguez" <mcgrof@kernel.org> |
|---|---|
| Date | 2016-04-08 03:20 +0200 |
| Message-ID | <rltfA-4jT-13@gated-at.bofh.it> |
| In reply to | #1372962 |
On Wed, Apr 06, 2016 at 05:06:20PM -0700, Luis R. Rodriguez wrote: > Now that Andy's ASM paravirt_enabled() use is merged Sorry I should have provided more context, I meant that now that Andy's ASM paravirt_enabled() removal is merged: This is the ASM hack that Andy removed: https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/fsgsbase&id=58a5aac5331388a175a42b6ed2154f0559cefb21 This puts a nail on coffin for the ASM hack: https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/fsgsbase&id=0dd0036f6e07f741a1356b424b84a3164b6e59cf Luis
[toc] | [prev] | [next] | [standalone]
| From | Borislav Petkov <bp@alien8.de> |
|---|---|
| Date | 2016-04-08 12:30 +0200 |
| Message-ID | <rlBPQ-2jm-37@gated-at.bofh.it> |
| In reply to | #1373926 |
On Fri, Apr 08, 2016 at 03:14:43AM +0200, Luis R. Rodriguez wrote:
> On Wed, Apr 06, 2016 at 05:06:20PM -0700, Luis R. Rodriguez wrote:
> > Now that Andy's ASM paravirt_enabled() use is merged
>
> Sorry I should have provided more context, I meant that now
> that Andy's ASM paravirt_enabled() removal is merged:
>
> This is the ASM hack that Andy removed:
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/fsgsbase&id=58a5aac5331388a175a42b6ed2154f0559cefb21
>
> This puts a nail on coffin for the ASM hack:
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/fsgsbase&id=0dd0036f6e07f741a1356b424b84a3164b6e59cf
Ah right, that.
Thanks!
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web