linux-kernel - Re: [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56B90D64.8050100@oracle.com>
Date:	Mon, 8 Feb 2016 16:49:24 -0500
From:	Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:	"Luis R. Rodriguez" <mcgrof@...e.com>,
	Andy Lutomirski <luto@...capital.net>
Cc:	"Luis R. Rodriguez" <mcgrof@...nel.org>, cocci@...teme.lip6.fr,
	Juergen Gross <jgross@...e.com>, mcb30@...e.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrey Ryabinin <aryabinin@...tuozzo.com>,
	Joerg Roedel <joro@...tes.org>,
	Robert Moore <robert.moore@...el.com>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Xen Devel <xen-devel@...ts.xensource.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Jan Beulich <JBeulich@...e.com>, Lv Zheng <lv.zheng@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	long.wanglong@...wei.com, Fengguang Wu <fengguang.wu@...el.com>,
	qiuxishi@...wei.com, Borislav Petkov <bp@...en8.de>,
	Andrey Ryabinin <ryabinin.a.a@...il.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	david.e.box@...el.com, X86 ML <x86@...nel.org>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH v2 3/3] paravirt: rename paravirt_enabled to
 paravirt_legacy



On 02/06/2016 03:59 AM, Luis R. Rodriguez wrote:
> The enumeration of legacy crap by ACPI boot flags seems to provide enough
> details to suit our needs if we really wanted to zero down on the specifics of
> what paravirt_legacy() means, there are these flags:
>
> /* Masks for FADT IA-PC Boot Architecture Flags (boot_flags) [Vx]=Introduced in this FADT revision */
> #define ACPI_FADT_LEGACY_DEVICES    (1)         /* 00: [V2] System has LPC or ISA bus devices */
> #define ACPI_FADT_8042              (1<<1)      /* 01: [V3] System has an 8042 controller on port 60/64 */
> #define ACPI_FADT_NO_VGA            (1<<2)      /* 02: [V4] It is not safe to probe for VGA hardware */
> #define ACPI_FADT_NO_MSI            (1<<3)      /* 03: [V4] Message Signaled Interrupts (MSI) must not be enabled */
> #define ACPI_FADT_NO_ASPM           (1<<4)      /* 04: [V4] PCIe ASPM control must not be enabled */
> #define ACPI_FADT_NO_CMOS_RTC       (1<<5)      /* 05: [V5] No CMOS real-time clock present */
>
> I checked and I didn't see qemu using any of the ACPI boot flags,
> but I suspected qemu instances must use a series of legacy crap.
> Likewise for KVM.
>
> coreboot defines legacy free when you don't have any of the above flags set:
> #define ACPI_FADT_LEGACY_FREE   0x00    /* No legacy devices (including 8042) *
>
> Would it be sufficient to just stick to "pv legacy" equivalent
> of requiring just ACPI_FADT_LEGACY_DEVICES and ACPI_FADT_8042 ?

I believe unprivileged PV guests may be compiled without CONFIG_ACPI if 
you are talking about requiring (or manually setting) these flags.

-boris

>
> I should point out It turns out ACPI_FADT_NO_CMOS_RTC matches lguest's and it
> seems that's the only reason we have that RTC PV flag and the features pv
> field... with the linker table + x86 subarch use it should be relatively simple
> to remove paravirt_has_feature() paravirt_has() and PV_SUPPORTED_RTC. lguest
> would just be the only subarch that opts out.
>
>    Luis