[Lguest] [Xen-devel] [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk

[David Vrabel]

* 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.

Xen parts:

Reviewed-by: David Vrabel <***@citrix.com>

David

[David Vrabel]

Since we are removing paravirt_enabled() replace it with a
logical equivalent. Even though PNPBIOS is x86 specific we
add an arch-specific type call, which can be implemented by
any architecture to show how other legacy attribute devices
can later be also checked for with other ACPI legacy attribute
flags.
This implicates the first ACPI 5.2.9.3 IA-PC Boot Architecture
ACPI_FADT_LEGACY_DEVICES flag device, and shows how to add more.

[...]

+struct x86_legacy_devices {
+ int pnpbios;
+};

It's not clear why pnpbios needs a new structure and why this structure
of devices does not have the bit for the rtc device.

David

[David Vrabel]

--- a/arch/x86/kernel/platform-quirks.c
+++ b/arch/x86/kernel/platform-quirks.c
@@ -7,8 +7,12 @@
void __init x86_early_init_platform_quirks(void)
{
x86_platform.legacy.rtc = 1;
+ x86_platform.legacy.ebda_search = 0;

You should make the default the setting for regular PC hardware, as you
have done for the .rtc bit.

David

[David Vrabel]

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 <***@citrix.com>

David

[Rusty Russell]

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.

Nice, thanks!

Acked-by: Rusty Russell <***@rustcorp.com.au>

Cheers,
Rusty.

[Andy Shevchenko]

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.
using standard
+ * PC mechanisms (PCI, ACPI) and doesn't need a special boot
flow.
boot path,
+ *  which start at asm startup_xen() entry point and later
jump to the C
+ *  xen_start_kernel() entry point.
Device) platform
+ * systems which do not have the PCI legacy interfaces.
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...