From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [RFC] Linux save_fl PVOP for Xen Date: Fri, 17 Apr 2015 11:26:24 +0100 Message-ID: <5530DFD0.2080604@citrix.com> References: <5530021C.4070905@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5530021C.4070905@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper , Xen-devel List , David Vrabel , Konrad Wilk , Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org On 16/04/15 19:40, Andrew Cooper wrote: > Having recently got some Broadwell hardware, our automatic test system > discovered that 32bit PV guests would reliably blow up while attempting > to boot. > > It turns out that the save_fl PVOP is at fault. The comment is false, > as setup_smap() uses it to check that the Alignment Check flag is clear. > > As the Xen PVOP leaves everything other than %ah worth of eflags > uninitialised, the BUG_ON(eflags & X86_EFLAGS_AC) in setup_smap() is > unconditional undefined behaviour on all versions of Linux since SMAP > support was introduced. I'm somewhat surprised this ever worked... > I had developed a patch (see below) and was writing up the commit > message, but it would appear that this PVOP is also used by PVHVM > domains, which invalidates an assumption underlying the fix (insofar > that 'pushf' would unconditionally have IF set). PVHVM uses native save/restore flags. > 2) Change setup_smap() to use something like native_safe_fl(). Unlikely > to get traction upstream, and fragile to similar changes in the future. This one liner seems preferred to me. Can you try it and see if the x86 maintainers agree? David