From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH][RFC] Support S3 for MSI interrupt in latest kernel dom0 Date: Wed, 17 Dec 2008 15:19:05 +0000 Message-ID: <49492679.76E4.0078.0@novell.com> References: <49491F2B.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Yunhong Jiang , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 17.12.08 16:06 >>> >On 17/12/2008 14:47, "Jan Beulich" wrote: > >>> Could Xen remember the MSI state automatically, as it does for IO-APIC >>> presumably already? It knows what vectors are routed where at least, = even if >>> dom0 has to reprogram the PCI device itself. >>=20 >> That is what the map_guest_pirq() re-invocation is intended for - use = the >> already known (stored) MSI state to re-setup the device accordingly >> (after all, msi_compose_msg() only depends on the vector information >> to be able to reconstruct address and data fields). > >Why wait for map_guest_pirq() to be invoked to do this? Otherwise we need a new hypercall here, since Xen cannot do this completely on its own (it has to wait for Dom0 to bring the device out of any suspend state it may itself be in). And it would allow restoring the old mechanism in your (2.6.18) Dom0, just without the unmap-pirq portion during suspend - instead of needing another full re- implementation cycle. Jan