From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH RFC 0/3] VMX: fix interaction of Viridian emulation with advanced features Date: Fri, 21 Jun 2013 17:25:30 +0100 Message-ID: <51C47E7A.6000703@eu.citrix.com> References: <51C4479D02000078000DF94F@nat28.tlf.novell.com> <51C477FF02000078000DFAD8@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51C477FF02000078000DFAD8@nat28.tlf.novell.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: Jan Beulich Cc: Keir Fraser , Eddie Dong , xen-devel , paul.durrant@citrix.com, Jun Nakajima , Yang Z Zhang List-Id: xen-devel@lists.xenproject.org On 21/06/13 14:57, Jan Beulich wrote: >>>> On 21.06.13 at 12:31, "Jan Beulich" wrote: >> 1: VMX: fix interaction of APIC-V and Viridian emulation >> 2: VMX/Viridian: suppress MSR-based APIC suggestion when having APIC-V >> 3: Viridian: populate CPUID leaf 6 >> >> The concepts patch 1 bases upon have been tested to fix the Win2008 >> boot hang previously reported, but the specific patch here so far hasn't >> got validated. Additionally I will also want to know whether patch 2 >> alone would also suffice to address the problem (it should in theory, but >> so far it was only tested when at the same time also not setting >> CPUID3A_MSR_APIC_ACCESS) - if it does, that might be a candidate >> to still go into 4.3. > George, > > the tests meanwhile completed successfully, i.e. both patch 1 > and patch 2 alone address the issue. I'd therefore like to propose > patch 2 as an immediate non-intrusive fix for 4.3, whereas I'd be > fine deferring the first one until after 4.3; deferring the third one > seems obvious as it is not fixing any known bug. > > Paul, would you btw feel like reviewing/acking patches 2 and 3? Just to clarify -- #1 makes it so that the software EOI does what the hardware EOI would do if it were used instead? It's a bit hard to tell which one of 1 or 2 is the lowest risk from a release perspective -- my instinct is to go with #1 (assuming I've understood it correctly), as it relies on expected behavior of the hardware, not on expected behavior of Windows. But I think whichever you think is best is fine with me, as long as you get an Ack from Paul for #2. -George