From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 3 of 4] VIOAPIC: Emulate a version 0x20 IOAPIC Date: Wed, 08 Feb 2012 09:12:15 +0000 Message-ID: References: <20120208170515.GA71900@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120208170515.GA71900@ocelot.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tim Deegan , Andrew Cooper Cc: xen-devel@lists.xensource.com, jbeulich@suse.com List-Id: xen-devel@lists.xenproject.org On 08/02/2012 17:05, "Tim Deegan" wrote: > At 16:45 +0000 on 08 Feb (1328719538), Andrew Cooper wrote: >> Currently, hvm emulates a version 0x11 IOAPIC. However, depending on >> the HVM guests {IO,L}APIC setup, it may take fewer traps into Xen by >> directly using the VIOAPIC EOI register present in version 0x20, >> rather than resorting to the legacy method of flipping the trigger >> mode for the relevent RTE. >> >> Currently, all required functionality is already present in the code, >> except that it is covered by VIOAPIC_IS_IOSAPIC which is never defined. >> >> Signed-off-by: Andrew Cooper > > This probably ought to introduce a hvm save record to say which kind of > IOAPIC the VM was booted with, so that after a live migration the OS > doesn't get confused. :( > > It seems unlikely that any OSes rely on the IOAPIC version (and the > behaviour of that register) being static after boot, but better safe > than sorry - there might be some confusion in resume from S3 or similar. Yes, so unless there is actually a demonstrable win from bumping the version, we should just not bother, and cull the IS_IOSAPIC code sections. -- Keir