linux-kernel - RE: [Xen-devel] [PATCH 1/2] Xen acpi pad implement

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: <DE8DF0795D48FD4CA783C40EC829233537A2A5@SHSMSX101.ccr.corp.intel.com>
Date:	Sat, 3 Nov 2012 12:16:44 +0000
From:	"Liu, Jinsong" <jinsong.liu@...el.com>
To:	Jan Beulich <JBeulich@...e.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jan Beulich <jbeulich@...e.com>,
	"xen-devel@...ts.xen.org" <xen-devel@...ts.xen.org>
Subject: RE: [Xen-devel] [PATCH 1/2] Xen acpi pad implement

Konrad Rzeszutek Wilk wrote:
>>> From f514b97628945cfac00efb0d456f133d44754c9d Mon Sep 17 00:00:00
>>> 2001 
>> From: Liu, Jinsong <jinsong.liu@...el.com>
>> Date: Thu, 1 Nov 2012 21:02:36 +0800
>> Subject: [PATCH 1/2] Xen acpi pad implement
>> 
>> PAD is acpi Processor Aggregator Device which provides a control
>> point 
>> that enables the platform to perform specific processor configuration
>> and control that applies to all processors in the platform.
>> 
>> This patch is to implement Xen acpi pad logic. When running under Xen
>> virt platform, native pad driver would not work. Instead Xen pad
>> driver, 
>> a self-contained and very thin logic level, would take over acpi pad
>> staff. When acpi pad notify OSPM, xen pad logic intercept and parse
>> _PUR object 
>> and then hypercall to hyervisor for the rest work, say, core parking.
> 
> Two comments:
>  - Did you look at the SuSE tree? Jan mentioned that they did some
>    fixes? Did you carry them over?

I didn't look at Suse tree.

Jan, would you please tell me where can I pull Suse tree? have you implemented xen-acpi-pad logic at Suse dom0 and which points you have fixed?


>  - The init function should not make hypercalls before checking if it
>    in facts run under Xen.

OK.

>> +
>> +static const struct acpi_device_id pad_device_ids[] = {
>> +	{"ACPI000C", 0}, +	{"", 0},
>> +};
>> +
>> +static struct acpi_driver xen_acpi_pad_driver = {
>> +	.name = "processor_aggregator",
>> +	.class = ACPI_PROCESSOR_AGGREGATOR_CLASS,
>> +	.ids = pad_device_ids,
>> +	.ops = {
>> +		.add = xen_acpi_pad_add,
>> +		.remove = xen_acpi_pad_remove,
>> +	},
>> +};
>> +
>> +static int __init xen_acpi_pad_init(void)
>> +{
>> +	int ret = -ENOSYS;
>> +	unsigned int version = HYPERVISOR_xen_version(XENVER_version,
>> NULL); 
> 
> Heh. so if you run this on baremetal I wonder what will happen.
> 
>> +	unsigned int major = version >> 16;
>> +	unsigned int minor = version & 0xffff;
>> +
>> +	/* Only DOM0 is responsible for Xen acpi pad */
>> +	if (!xen_initial_domain())
>> +		return -ENODEV;
>> +
> 
> I think the check for version should happen here.

Got it, will update later.

Thanks,
Jinsong

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/