From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH v2 1/5] VMX: fix interaction of APIC-V and Viridian emulation Date: Mon, 24 Jun 2013 14:09:50 +0100 Message-ID: <51C8451E.3060600@eu.citrix.com> References: <51C8092A02000078000DFDA0@nat28.tlf.novell.com> <51C80B7602000078000DFDAE@nat28.tlf.novell.com> <51C81B20.7040000@eu.citrix.com> <51C85D3F02000078000E003A@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: <51C85D3F02000078000E003A@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 24/06/13 13:52, Jan Beulich wrote: >>>> On 24.06.13 at 12:10, George Dunlap wrote: >> On 24/06/13 08:03, Jan Beulich wrote: >>> Viridian using a synthetic MSR for issuing EOI notifications bypasses >>> the normal in-processor handling, which would clear >>> GUEST_INTR_STATUS.SVI. Hence we need to do this in software in order >>> for future interrupts to get delivered. >>> >>> Based on analysis by Yang Z Zhang . >>> >>> Signed-off-by: Jan Beulich >> Hmm... so there are three paths which may end up calling this vmx EOI >> code -- from viridian.c:wrmsr_vidiridan_regs(), from >> vlapic.c:vlapic_reg_write(), and vmx_handle_eoi_write(). > This is the very reason why I favored patch 2 over this one for > 4.3 ... Yes, I think I didn't realize that when I looked at the patch on Friday. (It was the end of a very tiring week.) What other operating systems have you tested patch #2 with? IIRC Vista and Win7 both also have extensions, IIRC. Also, has either #1 or #2 been tested on AMD boxen? Choosing #1 involves the risk that we've missed something an will make one of those three cases *not* like real hardware, which seems fairly small. Choosing #2 involves the risk that MS may not have implemented the feature flag checking properly -- they almost surely test it *with* the feature flag much more than *without* it. Even if they do test without it, they may not test with the particular combination of flags that we are proposing. So overall, I still tend to think #1 is probably less risky. But as I said, I'm willing to go with either one. -George