linux-kernel - RE: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt platform

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 for Android: free password hash cracker in your pocket

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

Message-ID: <DE8DF0795D48FD4CA783C40EC829233510CE6F@SHSMSX101.ccr.corp.intel.com>
Date:	Wed, 28 Mar 2012 10:48:53 +0000
From:	"Liu, Jinsong" <jinsong.liu@...el.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	Konrad Rzeszutek Wilk <konrad@...nok.org>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	"keir.xen@...il.com" <keir.xen@...il.com>,
	Jan Beulich <JBeulich@...e.com>
Subject: RE: [Xen-devel] [PATCH 1/3] PAD helper for native and paravirt
 platform

>>> 
>>> Liu,
>>> 
>>> With this patch: "  xen/enlighten: Expose MWAIT and MWAIT_LEAF if
>>> hypervisor OKs it." which is now in 3.4-rc0:
>>> (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blobdiff;f=arch/x86/xen/enlighten.c;h=b132ade26f778f2cfec7c2d5c7b6db48afe424d5;hp=4172af8ceeb363d06912af15bf89e8508752b794;hb=d4c6fa73fe984e504d52f3d6bba291fd76fe49f7;hpb=aab008db8063364dc3c8ccf4981c21124866b395)
>>> it means that now that the drivers/acpi/acpi_pad.c can run
>>> as is under Xen (as the MWAIT_LEAF is exposed) What is the impact
>>> of that? Is the monitor call causing a trap to the hypervisor which
>>> will ignore the call? Or will it have some more worrysome
>>> consequences? 
>>> 
>> 
>> IMO this patch doesn't affect acpi_pad logic (both native and xen
>> acpi_pad). 
> 
> You are sure? The acpi_pad logic will now be activated so the native
> driver 
> will run under Xen. My question is - what is the impact of that?

I know what you mean now. What I mean is, w/ xen_acpi_pad patches, native acpi_pad only work under baremetal and xen_acpi_pad work under Xen (so no problem exposing mwait). What you mean is, w/o xen_acpi_pad patches, native acpi_pad will be actived under Xen and then risk occur ... I agree.

But just curious, what's the purpose and benefit of exposing mwait to dom0? I remember xen against doing so before.

> 
> My assumption is that the __monitor call will trap and we end up in
> the hypervisor - so that is not so bad, but not sure.

Have you added code to hypervisor side (do_invalid_op)? if not, I think it would be problem (break dom0). Dom0 __monitor would trigger UD, then not handled by hypervisor, and bounce back to dom0 kernel, and kill itself.

But the point is, if exposing mwait, it would be risk for all logic which executed __monitor. So need add native_monitor/ xen_monitor.

> 
> But what I wonder is if what is the impact of the _OST call by the
> native driver? 
> 
> Say the firmware tells us - please offline 4 CPUS (we have eight). We
> enter 'acpi_pad_handle_notify' -  create four threads, and each
> thread calls __monitor (which ends up in the hypervisor - and the
> hypervisor might not persue the __monitor call).
> 
> During this time, the Linux kernel calls the _OST with 4 CPUs and ..
> 
> what then? What happens if the _OST values are actually ignored (as
> it seems 
> it would be in this case?) Is that OK? Or is that going to lead to the
> firmware turning off some of the cores anyhow?

Hmm, if __monitor was tolerated silently as you assume, it would bring problem for _OST.

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/