linux-kernel - RE: [PATCH 2/2] RFC: Xen pad logic

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]

Date:	Mon, 26 Mar 2012 06:18:36 +0000
From:	"Liu, Jinsong" <jinsong.liu@...el.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	"lenb@...nel.org" <lenb@...nel.org>,
	"Brown, Len" <len.brown@...el.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"keir.xen@...il.com" <keir.xen@...il.com>,
	Jan Beulich <JBeulich@...e.com>,
	"Li, Shaohua" <shaohua.li@...el.com>
Subject: RE: [PATCH 2/2] RFC: Xen pad logic

Konrad Rzeszutek Wilk wrote:
> On Thu, Feb 23, 2012 at 01:31:25PM +0000, Liu, Jinsong wrote:
>>> From ba9abf6ee7e5fe0515e2d51b14743c8d5416285c Mon Sep 17 00:00:00
>>> 2001 
>> From: Liu, Jinsong <jinsong.liu@...el.com>
>> Date: Fri, 24 Feb 2012 02:18:02 +0800
>> Subject: [PATCH 2/2] Xen pad logic
>> 
>> This patch implement Xen pad logic, and when getting pad device
>> notification, it hypercalls to Xen hypervisor for core parking.
> 
> Can you explain to me how and what pad device is? And how it functions
> right now in baremetal? And what kind of hardware do you need to use
> this? 
> And what happens if you do not use it? Can one ignore the "pad"
> support? 
> Please assume that I've a basic understanding of ACPI.
> 
> 
> Also, what happens now, if the this patch is not implemented? What
> will/is dom0 doing without these patches (so 3.2 for example on this
> machine)? 
> Is it just idling using mwait on idle CPUs and ending up trapping in
> the hypervisor? Or is not mwaiting since the cstate.c doesn't get
> executed since we have: 
> 
>        boot_option_idle_override = IDLE_HALT;
> 
> in arch/x86/xen/setup.c ?

Pad is an ACPI device used to direct os taking some action (depend on os itsef) for the sake of power consumption. 2 objs (PUR and OST) could be declared under PAD and as bios/os interface.

PAD itself is pointless, unless it co-work with some external power control s/w (like NPTM). For example currently in baremetal, NPTM engine trigger sci to ospm, then evaluate and call sci handler, through which bios notify os with PUR value by which os could take corresponding action and feedback bios through OST. I don't think it's a problem if user don't use PAD or ignore it, it only make some external power control s/w unuseable.

As for how os handle pad notify is os business. Native kernel use round robin and mwait, considering some app workload affinity (I was told so). For xen we don't need care it since it's a question of vcpu level. For xen acpi_pad, dom0 patches used to parse PUR and hypercall to hypervisor, which in turn idle pcpu by its own algorithm.

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/